Post Chronology

May 2024

InFullBloom Archives


Speaking Engagements

Predict and Prepare sponsored by Workday 12/16

The Bill Kutik Radio Show® #171, 2/15
The Bill Kutik Radio Show® #160, 8/14
The Bill Kutik Radio Show® #145, 1/14
Workday Predict and Prepare Webinar, 12/10/2013
The Bill Kutik Radio Show® #134, 8/13
CXOTalk: Naomi Bloom, Nenshad Bardoliwalla, and Michael Krigsman, 3/15/2013
Drive Thru HR, 12/17/12
The Bill Kutik Radio Show® #110, 8/12
Webinar Sponsored by Workday: "Follow the Yellow Brick Road to Business Value," 5/3/12 Audio/Whitepaper
Webinar Sponsored by Workday: "Predict and Prepare," 12/7/11
HR Happy Hour - Episode 118 - 'Work and the Future of Work', 9/23/11
The Bill Kutik Radio Show® #87, 9/11
Keynote, Connections Ultimate Partner Forum, 3/9-12/11
"Convergence in Bloom" Webcast and accompanying white paper, sponsored by ADP, 9/21/10
The Bill Kutik Radio Show® #63, 9/10
Keynote for Workforce Management's first ever virtual HR technology conference, 6/8/10
Knowledge Infusion Webinar, 6/3/10
Webinar Sponsored by Workday: "Predict and Prepare," 12/8/09
Webinar Sponsored by Workday: "Preparing to Lead the Recovery," 11/19/09 Audio/Powerpoint
"Enterprise unplugged: Riffing on failure and performance," a Michael Krigsman podcast 11/9/09
The Bill Kutik Radio Show® #39, 10/09
Workday SOR Webinar, 8/25/09
The Bill Kutik Radio Show® #15, 10/08

Keynote, HR Tech Europe, Amsterdam, 10/25-26/12
Master Panel, HR Technology, Chicago, 10/9/012
Keynote, Workforce Magazine HR Tech Week, 6/6/12
Webcast Sponsored by Workday: "Building a Solid Business Case for HR Technology Change," 5/31/12
Keynote, Saba Global Summit, Miami, 3/19-22/12
Workday Rising, Las Vegas, 10/24-27/11
HR Technology, Las Vegas 10/3-5/11
HR Florida, Orlando 8/29-31/11
Boussias Communications HR Effectiveness Forum, Athens, Greece 6/16-17/11
HR Demo Show, Las Vegas 5/24-26/11
Workday Rising, 10/11/10
HRO Summit, 10/22/09
HR Technology, Keynote and Panel, 10/2/09

Adventures of Bloom & Wallace

a work in progress

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

Objects To The Left Of Us, Objects To The Right

Objects To The Left Of Us, Objects To The Right


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!


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.

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

  • […] Model Errors Part I — Job And Position Part 1 of a 2 part series from Naomi Bloom. (Here is part 2.) Bloom is the industry’s very own Grace Hopper. She’s done more to educate the […]

  • You and I have been singing the song so long that I forget that this discussion still needs to be had because of all the legacy systems still holding back progress.

    One advantage of rigorous object modeling is that a correct model dramatically simplifies transactions. When Person and Position are independent entities, transferring someone is a matter of updating the relationship between Person and Position.

    In our model, we have some different semantics than you use because we chose to focus on the relationships. We call the association (object model term) between objects like Person and Position a relationship and ascribe a standard set of attributes (dates, timestamps, and relationship type) to this special association. We find this nomenclature reflects associations very common in HR.

    Thanks for opening the dialog.

    Gary Durbin

    • Naomi Bloom

      Gary, I so wish this discussion weren’t needed, but it is. And not just because of the legacy systems. You’d cry if you saw some of the new software making mistakes that date back generations just because their architects/designers haven’t studied the history of our industry. Very sad.

  • Anthony

    How many organisations understand the need for HR master data management in the context of an environment with different technologies covering payroll, recruitment, learning and development, talent management, succession planning, work force planning?

  • Anthony

    Organisations also tend to forget that the HR data exists in the context of an organisation design (formal or informal) and the crux is the content required in terms of job architecture actually enables the organisation!!! and some more on this subject

    • Naomi Bloom

      I so wish that organizations did understand HR master data — really master object in today’s world — management, but we are still “Waiting for Godot” on this one.

  • Anthony

    The first part of the journey is however understanding what HR functional requirements are, unpacking these from data upwards and designing the end game….doesn’t just happen. How do we achieve integrated HR….see Tony

    Regardless of technology being built correctly, business needs to build content correctly too!

  • Great read Naomi. All I can add is that I feel lucky that my first dip into HR technology (after I did my 10,000 hours in CRM) was with an oracle based tool from NgA in the UK that inducted me into the HR data model and did split out position from job and person. And secondly I feel lucky enough to have been involved in a Workday project where we absolutely needed to find a solution that ticked many points you mention, and they did plus more. Looking forward to the next post!

  • John Eckersley

    Well Naomi, you know you’re preaching to the converted as far as I’m concerned. As for old-fashioned dress standards adopted by backward organisations – well that’s for another time perhaps.

    Trouble is, as you’ve observed in the past, if the fact that this stuff is so important is lost on the “techies” within (some) vendors who are supposed to know about it, it’s of limited interest to many (not all) HR folk – even though it’s a vital component in getting a system that’ll do what they need.

    Fascinating stuff though, and I’m glad to see it all again – looking forward to the rest.

    • Naomi Bloom

      The good news is that many chief architects at vendors in our space are trying to do the right thing, although many are impeded by the technical debt of older/incorrect data designs. The bad news is that the buyers rarely have a clue unless they just happen to have a terrific IT person on their team.

  • Cory Scott


    I have enjoyed your opines for years. We just purchased SuccessFactors as our new HRMS and this topic of position mgt vs. just managing the people for whatever job is one of our hot topics as we make our plans. Do we convert from Peoplesoft directly or do we convert our data model to a more robust object model like you are outlining is vitally salient to my thinking. Thus, you have my attention so please continue with your review of the right way to set up the data in our cloud application.

    Cory Scott
    Corning. Inc

    • Naomi Bloom

      Cory, nothing makes me happier than knowing that my work is useful to end-users. Although I’m no longer doing direct client consulting, if a call would be helpful in sorting out some of your key object model issues — and please do clean up as much as you can as part of your SFSF implementation — I’d be happy to do that call. My email is naomibloom [a]

Leave a Reply