Persistent HRM Object Model Errors Part II — Separating Position From Worker

Objects To The Left Of Us, Objects To The Right

Introduction

I’ve been on the warpath about flawed HR technology object models (and their predecessors, flawed data models) for longer than most of you have been sentient.  My pique on this subject goes way back to the late 80’s and a now infamous consulting gig at then PeopleSoft in its early days when I expressed my concerns about the flaws in their data model (some of which have surely been addressed, but whose core flaws ran really deep).  I loved the technology leap that PeopleSoft made when they came to market in the late 80’s, and I loved the vision Row Henson, then their HRM product strategist, had for HRM and her HRMS products, but I deplored the fact that they had not produced a contemporary data model of HRM as the basis for their then next generation software.  Fortunately, Dave Duffield and his leadership team didn’t hold my data model dinging against me, except perhaps for their sales leader.

Over the following decades, I wrote and spoke publicly about this subject often enough that folks were beginning to get bored with my preaching (did you think I hadn’t noticed?).  But all of the HR technology built throughout the 80’s and 90’s, and even much of what came to market early in the new century, continued to be built upon flawed model foundations (and some vendors still weren’t using formal models in their designs, if you can even believe that).  But instead of just wringing my hands, I began licensing my HRM Object Model “Starter Kit” across the vendor community from the mid-90’s, along with the recommended architectural behaviors, in hopes that would make a dent in improving HR technology underpinnings — and it did.

Then, in response to many requests, iIn May 2012, I published a blog post that covered the basics of objects and object modeling — the very basic basics.  Assuming you’ve all been studying this topic since then (if you hadn’t already done so), it seems like a good time to note that simply applying the right modeling techniques does not get you to correct and complete HRM object models.  Au contraire.  I’ve watched many, very smart HRM enterprise software architecture and modeling teams do their best, but it’s a rare team that doesn’t make one or more of the same errors, and they’re doozies.  And while I’ve covered all of these potential errors in my HRM Object Model “Starter Kit,” which is great for licensees (please note that I no longer license this material) but not so great for everyone else, I decided to highlight the most challenging ones through a series of blog posts for the benefit of those vendors — and their customers — who didn’t license my “Starter Kit” (and even for those who have a license but may not have modeled correctly these specific challenges).

I should also add that, if a vendor’s applications are created/maintained via a robust, models-driven, metadata-based, effective-dated, definitional development environment, etc., it’s a lot easier to adjust the models and resulting applications over time than in a traditional, procedural logic approach to applications development — and this agility really matters.  Throw in a “Blooming SaaS” architecture and fundamentally great functionality, and you’re really cookin’.  Since it’s so important that the object model be fundamentally correct and complete (for the desired scope of functionality) in any software you may choose to use, and the only way to get at this as a prospect/customer, short of reviewing object diagrams (which are impenetrable for all but the fully initiated), is to use case-based (aka scenario-based) product evaluation, that’s clearly the only way to go. 

My first post in this series focused on the difference between job and position, and I urge you to read that before proceeding.

Separating Position From Worker

Work and workers are two fundamentally different concepts, and getting them right, along with their appropriate attributes and methods as well as relationships, goes to the heart of having an effective enterprise HRM application.  For example:

• We interview position seekers for one or more specific positions (whether empty or filled but expecting to be emptied).
• We design employee career paths as a series of positions to be held.
• We develop succession plans for specific positions to include named employee, contingent worker, or position seeker (in this case a person who may not be known otherwise to the organization but who is created by the organization as a position seeker during succession planning).
• We hire, transfer, and promote employees into positions.
• We terminate and retire employees from positions.
• We contract for contingent workers and assign them to specific positions.
• An employee or contingent worker may do the work of one or more positions at the same time, or a single position’s work may be done by one or more employees or contingent workers.
• An employee or contingent worker may self-identify as a position seeker by applying for a specific position.

No one should be using an HRMS, let alone any talent management applications (and you know I feel strongly that these really deserve full integration as HRMS/TM, unless there are distinctly different and quite separate objects to describe:

• The nature of the work to be done and how it’s organized into positions defined by jobs;
• Those roles in the person object class structure (so those types of persons) which have done, are doing and/or could do work for the organization via their explicit, transaction-created relationship to one or more positions as employee, contingent worker, and/or position seeker; and
• How specific workers are related to specific positions, e.g. a worker may be the named successor for a position that’s occupied currently even as that same position is associated with one or more employees via their career plans, or the usual work schedule for this position (which is associated directly with that position) may be 9:00 AM to 5:00 PM daily but, when filled by Naomi, the actual work schedule will be a negotiated 10:00 AM to 4:00 PM because of her incredible productivity and associated with the relationship between Naomi and that position.

As a side note, I’ve been updating my HRM object model thinking to allow for the mix of human and humanoid robot workers, but that’s a topic for another day.  Let’s stick with the basics here, focusing on human workers.

Within the person object class hierarchy, there are person objects which have nothing to do with the work of the organization, e.g. shareholder, person designee (someone designated by an employee who is participating in a total compensation plan for which having a designated recipient of provided benefits is a part of that plan’s design), or customer.  But there are other person roles through which the work of the organization gets done:

• The obvious employee role (both current or past as defined according to the appropriate geopolitical jurisdiction having that responsibility, e.g. in the US, who is or is not an employee is defined by the IRS);
• The vendor employee role (an individual who does the direct work of the organization, not through an outsourcing of process or the purchase of results/products but rather through the carrying out of tasks within the organization itself and who is not an employee but rather a contractor of some flavor, again according to the appropriate geopolitical jurisdiction having that responsibility e.g. in the US, who is or is not an employee is defined by the IRS); and
• The position seeker role, which could be an employee or contingent worker who has self-identified to fill a specific position (or expressed a broader interest in working in a job, work until or work location of the organization), or has been designated as a named successor via a succession plan for a specific position, or someone of whom we’ve never heard before who either has self-identified as or been designated as a position seeker (where this is usually subject to the organization’s own business rules).

[Please note that a single physical person can of course fill one to many of these person roles either serially  or concurrently, position seekers may be applying for work generally with the organization, at a particular work location, for any position defined by a particular job, and these are just a few of MANY more complications that I’ve left out to keep this post from eating all of Florida.]

As noted in my first post in this series, jobs are templates from which positions are created.  Jobs describe broadly the nature of the work being done, in terms of what I call duties and responsibilities, as well as the KSAOCs (knowledge, skill, ability and other deployment-related characteristics, so these include surrogates like work experience and education, attitudes and behaviors, work schedule and environment preferences, etc.) and level of mastery thereof that are needed to do that work.

But work gets done via workers “sitting” in positions and carrying out the duties and responsibilities of those positions.  Positions, once created from a job template, must be given a work location (which could well be telecommuting), a negotiated work schedule (if different from the usual one), and their association with (place in) one or more work units.  Although they inherit a lot of their attributes and methods from job, positions may be assigned more specific duties and responsibilities, more specific KSAOCs and/or the weight and rating accorded to those KSAOCs.  Positions may also be given the rules by which accounting for the costs associated with those positions will be done (i.e. when cost accounting isn’t done on a time and attendance basis), rules for any position controls (whether headcount or budgetary) that will be applied when filling those positions, and rules for establishing the fit/recruiting sources/evaluation process/etc. when filling these positions should they need filling (i.e. succession plans, sourcing rules, etc.).

So what’s the big deal here?  Keeping position attributes and methods (nature of the work, desired profile of the worker, budget for the work, duration of the position, planned work schedule, and more) quite separate from the characteristics of the worker (preferred work schedule, agreed term of employment, negotiated hiring bonus, agreed accommodation in view of a disability but regardless of position, etc.) seems like a no brainer, but I assure you that many legacy on-premise systems still in use don’t do this very well or completely.  And, even when the software can do this right, implementations carry forward lousy coding structures that go back decades to a time before we had great object models.  And if you think it’s a muddle now, just wait until you’re generating predictive, embedded analytics at in-memory speed to inform managerial decisions on the basis of truly muddled data stored in outdated and/or just plain wrong data or object structures.  Yikes!

Wrapup

So that I don’t violate every principle Bill Kutik has tried to teach me about reader attention spans, I’ve just done the separating position from worker thingy here.  But please stay tuned as I work through a whole list of persistent object model errors — and let’s not even consider any vendor who’s still working with purely data models because they’re so far out of date in the art and science of software engineering that they’re probably wearing tie-dies and bell-bottoms around the office when such garb is really only appropriate for attending aging rocker or folky concerts.

• Job and Position
• Separating Position From Worker
• Employee Status Code
• Decomposing Total Compensation Plan Into Reuseable “Legos”
• Addressing Multiple, Concurrent Worker To Position Relationships
• Balancing Total Compensation Plan With Work Environment ProgramCrafting The KSAOC UmbrellaCommunity MembersProfessional Network and Networking As KSAOCsSeparating Work Unit From Work LocationSeparating Work Unit From Legal Entity

If I get that far, and you’re still interested, I’ll keep writing on this topic.  Meanwhile, if you’re a customer, starting checking your current portfolio of HRM software for the proper separation and implementation of job and position.  Lots more relevant use cases for work and worker can be found here here here and here.