Would that we had a shared vocabulary. Good HRM domain models are the essential first step to producing excellent results.
One of the biggest challenges in any attempt to apply IT to the HRM business is that we don’t yet have an industry-independent, geographically independent vocabulary for discussing HRM’s 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, business rules, and relevant metrics, it’s little wonder that the HR community is challenged to compare HRM software and/or outsourcing offerings, let alone to discuss process change or data analysis.
This was a big enough problem when most attempts to automate HRM were confined to the back office, and the rest of the organization was largely unaffected. When self-service went mainstream, the lack of an industry standard vocabulary forced each in-house HR systems/shared services/operations group to agree on some version of a common terminology, at least for purposes of rolling out self-service. Still, errors of interpretation, business rules left to the imagination of widely dispersed “reviewers and approvers,” extra time spent communicating, and all forms of general annoyance and lost productivity were largely invisible because the attendant time and costs were never aggregated. And then along came broadly-based HRM BPO, where the development and execution of a legally binding service level agreement required an agreed vocabulary and revealed, in the aggregate, the associated pricing.
If we’re ever going to use technology to achieve both efficiency and effectiveness in HRM and HRM service delivery (via shared services and/or outsourcing), then we must have an agreed upon HRM domain model complete with clear and consistent terminology and definitions that describe the overall subject matter under consideration (HRM for us) from the perspective of the business events to be serviced, the processes with their business rules 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.
For those of you coming from a software background, you know that I’m talking about the highest levels of an HRM business object model before all sense of the forest is lost in the trees of decomposition. For those of you coming from an HR subject matter expertise 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 accounts for each head, when to count them, and how to explain what you’re doing. For shared services or outsourcing providers, such a domain model is absolutely essential to writing a clear enough service level agreement to enable a positive and durable client relationship (unless of course you can’t deliver against a clear SLA).
In a perfect world, an HRM domain model—at least at the higher levels of detail—would have long since been developed, vetted, and provided “free” to all by a professional association. In that same perfect world, I would be 25 again and know what I know now. Meanwhile, I’ve made a very good business out of licensing my HRM domain model.
In the early days of packaged software, I advised clients to request the vendor’s data model as the best way to quickly understand the assumptions the vendor made about the HRM domain and, therefore, to test how good a fit those assumptions would be for the customer’s needs. If there was no person entity, then there would certainly be no way to distinguish properly between persons who were our employees and those who were non-employee workers. If there was a one-to-one relationship between an employee and a position, then there would certainly be no way to properly support having an individual employee work in each of two part-time positions to secure full-time employment and benefits.
Good HRM domain models are the essential first step to producing effective and efficient process designs, software, outsourced service offerings, delivery system designs, clear internal or external service level agreements, and many other positive outcomes. Poor domain models or no domain models produce just as poor results for everyone. It does my heart good to see that some of today’s newer software products and BPO offerings are based on carefully developed and correct domain models, but it’s been a very long time coming.
