Post Chronology

June 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 I — Job And Position

Objects To The Left Of Us, Objects To The Right

Objects To The Left Of Us, Objects To The Right


In 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 seemed like a good time to note that simply applying the right modeling techniques does not get you to the right HRM object models.  Au contraire.

I’ve watched 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 handled 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 thought I’d highlight the most challenging ones here for the benefit of those vendors — and their customers — who haven’t licensed my “Starter Kit” and even those who have a license but may not have tackled (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, 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.

Separating Job And Position

These 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.  Furthermore, 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 both position and job are core object classes and modeled properly.  Only at the lowest (and I do mean lowest) end of the market can you get away with using one or the other as a conflation of both.

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.  Jobs, therefore, are the place where regulations that govern work are “hooked up” at each organization to that work.  Jobs, more important than even the nature of the work they describe, can be evaluated in terms of appropriate levels and types of total compensation, thus creating eligibility for specific total compensation plans for the employees sitting in positions for which a specific job was the template.  Jobs are strictly an HRM construct that let’s us group together positions doing similar work, not only for regulatory purposes, like employment equity and regulated work hours and conditions (e.g. FLSA in the USA), but also for workforce planning, labor relations, compensation management, and many, many more strategic HRM processes.

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, a work schedule, and their association with (place in) one or more work units.  They 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 of positions should they need filling (i.e. succession plans, sourcing rules, etc.).

So what’s the big deal here?  There are a ton of organizations that think they can avoid the discipline of using positions by mushing job and position into their flawed HRMS’ job code table.  You know the one.  The job code table with 10,000 entries for 7,000 workers?  The job code table with job descriptions like “VP — Finance,” “VP — Engineering,” and “VP — HR,” when VP is clearly the job for which there are three very different positions created.  Many organizations have been dragging around these piles of job code table poop for longer than most of my readers have been sentient, and it’s clearly time to clean up this mess.  But you can’t clean it up unless your HRMS handles these objects properly — and very separately.  So, a job may be the template for one or more positions, but a position inherits its basic components from one and only one job.


So that I don’t violate every principle Bill Kutik has tried to teach me about reader attention spans, I’ll just do the job/position thingy here.  But please stay tuned as I work through the following 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 when attending aging rocker or folky concerts — in subsequent posts:

  • 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 Program
  • Crafting The KSAOC Umbrella
  • Community Members
  • Professional Network and Networking As KSAOCs
  • Separating Work Unit From Work Location
  • Separating 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 job and position can be found here and here.

2 comments to Persistent HRM Object Model Errors Part I — Job And Position

  • […] Persistent HRM Object 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 industry about great software development practice than anyone else. (Here’s her tutorial on object models.) Anyhow, in these two pieces, Naomi proposes an approach to the underlying HR Data that clearly distinguishes the worker from the work. That makes it possible to build effective HRM enterprise software. […]

Leave a Reply