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.
Funny because it’s true and interesting because the solution is so complex to what seems like such a simple problem. Why can’t everyone just think like a developer? ;-}
Great points Naomi – bringing some standardization to all the terms and definitions & etc would help everyone. The accountants have GAAP, double-entry accounting, and all sorts of financial regulations that govern their data and process definitions (or at least confine the variations to a small range). I don’t think we have that to the same extent in the HR world – so without that sort of externally-drive discipline, getting broad-based acceptance on a domain model might take a while. But I’m all for it!
Steve, thanks so much for your encouragement. We are making progress on having a more or less converging HRM domain model, at least across the HRM software vendor community, many of which are clients and/or licensees of my domain model “starter kit,” collaborating with the HR-XML Consortium, or simply arriving at a common destination just because great modeling applied to HRM gets you there, eventually. I hope to see, in my time, the death of employee status codes, job code tables whose entries outnumber employees, mass change programs of all flavors and many more of the worst artifacts of our early days flat file, miles of procedural logic, COBOL programs.