Post Chronology

May 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

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.

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

Leave a Reply