Introduction

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.

Wrapup

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.