The Tower Of Babel In HRM: Where Is Our Domain Object Model?

One of the biggest challenges in any attempt to apply information technology to the human resource management (HRM) business is that we don’t yet have an industry, geographic and vendor neutral vocabulary for discussing its major concepts, let alone the details.  Is my candidate your applicant?  Is my contractor your contingent worker?  Is my total compensation plan your total rewards program?  Where does compensation leave off and benefits begin?  And let’s not even get started on how job and position are used and misused within HRM.  

Without clear and consistent terms and definitions for HRM concepts, events, data, and processes, as well as their relationships and the relevant metrics, it’s little wonder that the HR community is challenged to discuss process innovation or data analysis let alone to compare HRM software from different vendors.  Pieter Brueghel the Elder captures our dilemma perfectly in this famous painting of the Tower of Babel (1563).

If you’ve found yourself on the receiving end of this confusion, let me offer a very simple but hard to execute solution.  What’s clearly needed is a domain model, which is a formal description of the HRM domain, complete with clear and consistent terminology and definitions.  A domain model describes the domain (the overall subject matter under consideration) from the perspective of the business events that are addressed, the processes that address those business events, the data created by and used by those processes, the relationships among these events, data and processes, and the metrics needed to measure not only activity levels and timings but also the far more important business outcomes.  And it does this with the precision and specificity needed to support process innovation, software design through development and implementation, and every form of HRM practice/policy/plan design.

If you come from a software background, you know that I’m talking about the highest levels of a logical HRM object model before all sense of the forest is lost in the trees of decomposition.  If you come from an HRM subject matter background, you know that I’m talking about exactly the kind of clarity that you’ve spent your lives trying to achieve just to do a headcount report that knows what kinds of heads to count.  And for everyone involved in HRM delivery system planning, design and/or operations, whether in-house or outsourced, I’m talking about the very precise language needed to define service delivery models and service level agreements.  Our colleagues in financial management are pretty far along here, which is why you never hear jokes about the CFO who couldn’t explain the difference between an asset and a liability.

In a perfect world, such a domain model, at least at the higher levels of detail, would be developed, vetted and provided “free” to all by a professional association.  In that same perfect world, I would be twenty-five again and know what I know now.  The really scary thing is that much of today’s HRM software isn’t based on domain object models at all but rather on the much older techniques of separate process and data modeling (we’re talking early 80’s techniques here) or, G-d forbid, no models at all (“we know the domain so well that we’re able to develop our software intuitively!”). 

In the early days of packaged HRM software, I advised clients to request the vendor’s data model as the best way to see quickly (long before we could use scenarios to reveal them through a modern UI)the assumptions the vendor was making about the HRM domain and, therefore, to test how good a fit those assumptions would be to the customer’s needs.  If there were no person object, there would be no way to distinguish properly between persons who were our employees and those who were non-employee workers.  If there were a one-to-one relationship between an employee and a position, then there would be no way to support properly the common practice of having an individual work part-time in each of two part-time positions in order to secure full-time employment and benefits.  Those of you who read my post on the work and worker “killer” scenarios and know a little about object modeling will have seen that those scenarios were designed to reveal, among other things, today’s software’s underlying object model through its self service UI.

The bottom line.  An HRM software vendor’s domain object model tells you a great deal about that vendor’s understanding of and assumptions about the domain – and here’s the real point – with what cost-effectiveness and speed they’ll be able to meet your needs and support changes to their software over time.  Good domain models are a necessary (but not sufficient) condition for good HRM software.  HRM software vendors with poor domain object models or worse, no such models, should not be on your shortlist.  And if you’re already running such software, you may want to check out my post on planning for its retirement.