Lies, Damns Lies, and Metrics – – With Apologies To Mark Twain – – Part II

In my last post, I began discussing the importance and use of metrics in the running of the HRM business and it’s HRM delivery system (HRMDS), to include those metrics needed in the service level agreements for shared services and when any part of the HRM business and/or HRM delivery system is outsourced. And please note that SaaS is outsourcing, albeit IT outsourcing. I also emphasized the importance of staying focused on business outcomes, both HRM’s and those of the organization as a whole, so that running the HRM business and the HRMDS don’t become ends in themselves.

As promised, this post introduces the precisely organized and stable HRM domain model that’s needed to provide a consistent terminology and meaningful partitioning for discussing the HRM processes for which we want to define metrics and outcomes. We’ll also need a taxonomy for categorizing and defining the most appropriate set of HRM and HRMDS metrics for your organization, and I’ll suggest such a taxonomy in my next post.

This diagram presents the seven highest level processes in the HRM domain along with their next level, modeled decomposition. Then, via bulleted examples in colloquial terminology (as opposed to the formal modeling terminology of the HRM processes) of some of the work products produced at that second level, these diagrams provide a rough definition of the scope of those processes. This formally modeled view of the HRM domain has been very stable over the last 20+ years even as many of the lower level processes and accompanying data design (really the entire HRM object model, which is the focus of our HRM Business Model “Starter Kit”) and enabling architecture have evolved in important ways.

Nothing in this HRM domain model suggests the specifics of people, work flows and technology that, taken together, give life to the domain via an HRM delivery system, nor does this model presuppose any specific organization’s HRM policies, practices or plans. Instead, it provides the structure within which we design and then execute organization-specific HRM policies, practices and plans. Furthermore, and here’s where trying to create a one page diagram drove me nuts, there is a clearly implied but not shown here companion object model which is critical to developing a deeper understanding of these processes and to creating a highly technology-enabled HRM delivery system. For example, the fact that contingent workers are addressed within Staff The Organizational Structure must be supported in the accompanying object model by a person rather than employee-centered design. We’ll leave discussion of the desired HRM object model for another series of posts, but you may want to reread the January/February, 2004 and May, 2007 columns in HRO Today for some preliminary insights into this topic.

If you already have a well-defined and stable HRM domain model in use throughout your organization, by all means use that instead of the model introduced here. But one advantage of this particular model, which was developed using rigorous data, process and object modeling techniques, is that it’s quite similar (we won’t digress here to the chicken and egg discussion) to the underlying object models of many HRM software vendor’s (or BPO provider’s proprietary) next generation, service-oriented architecture (SOA) software. For developing an organized view of HRM and HRMDS metrics, it’s sufficient to consider the HRM domain model at its highest two levels, either yours or mine.

So, to get started with our HRM/HRMDS metrics, set up a giant spreadsheet with the HRM domain model’s two highest level processes arrayed as columns, where there’s a summary column for each highest level process and then more detailed columns for that process’ decomposition. The next post in this series, part III of IV, will suggest a metrics taxonomy (i.e. categorization scheme) that will array itself as the rows. Then we’ll have a structure within to consider for which of these cells metrics should be proposed, which metrics would work best, who should be responsible for setting the target values, what actions should be taken as a result of those metrics hitting or not hitting their target values, who should be responsible for producing the metrics and accountable for achieving the target values (two very different roles), which metrics should become a part of any shared services/outsourcing SLAs, etc.

The bottom line. What we’re building, step by step, is a consulting tool, the same one I use with my end-user clients, to help ensure that we have the right metrics in place for running the HRMDS, the HRM business and, of greatest importance, for measuring progress toward the agreed business outcomes. Even when you outsource an HRM process, although some of the needed HRMDS metrics are of more interest to the outsourcing provider than to their customer, an understanding of the complete landscape of needed metrics helps the buyer decide what to include in the relevant service level agreements (SLAs), what will be the buyer’s responsibility, and what analytics will be needed, regardless of who delivers them, to run your business and achieve its agreed-upon outcomes. And all of this applies to the SLAs for shared services.