Lies, Damn Lies, and Metrics–with apologies to Mark Twain. Part II
In last month’s column, we began discussing the importance and use of metrics in the running of the HRM business and its HRM delivery system to include those metrics needed in the service level agreement when any part of the HRM business and/or HRM delivery system is outsourced. We also emphasized the importance of staying focused on business outcomes, both HRMs and those of the organization as a whole, so that running the HRM business and HRM delivery system (HRMDS) does not become an end in itself. As promised, this months column introduces the precisely organized and stable HRM domain model that’s needed to provide consistent terminology for discussing the HRM processes for which we want to define metrics and outcomes. You’ll also need a taxonomy for categorizing and defining the most appropriate set of HRM and HRMDS metrics for your organization, and well present a suggested one in next months column.
The diagrams on the opposing page (see figure) present the seven highest level processes in the HRM domain along with their next level decomposition. Then, via bulleted examples of the types of work products produced at that second level, these diagrams provide a rough definition of the scope of those processes. It may be of interest to know that the extremely high-level representation of the HRM domain shown here was extracted from Bloom & Wallace’s HRM Business Model Starter Kit that’s been licensed throughout the HRM software and services industry. This Starter Kits highest level view of the HRM domain, which is presented in the diagrams, has been very stable for more than twenty years, even as many of the lower level processes and accompanying data design have evolved in important ways, and even as we’ve applied more and more integrated automation to the delivery of this domain.
Nothing in this 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 your own organizations very specific HRM policies, practices, or plans. Instead, the model provides the structure within which we design and then execute organization-specific HRM policies, practices, and plans. Furthermore there is a clearly implied but not shown companion data model which is critical to developing a deeper understanding of these processes and to creating the HRM delivery system. For example, the fact that contingent workers are addressed within Staff The Organizational Structure must be supported in the accompanying data model by a person rather than employee-centered design. Well leave discussion of the desired HRM data model for another series of columns, but you may want to reread the April and May 2003 columns 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 its entirely compatible with what you’ll be seeing in every major HRM vendors (or BPO providers proprietary) next generation, service-oriented architecture HRM software. That’s because, to systems professionals, the HRM Business Model Starter Kit functions as an object model starter kit. For our purpose, its sufficient to consider the domain model at its highest level–either yours or the one presented here–as a tool for ensuring that we don’t overlook any part of the domain in designing our HRM and HRMDS metrics.
To get started with metrics, set up a giant spreadsheet with the HRM domain model arrayed as columns–where there’s a summary column for each highest level process and then more detailed columns for that process’s decomposition. Next months column will suggest a metrics taxonomy (i.e., categorization) that will array itself as the rows. Then we can begin to consider which of these cells metrics should be proposed, which metrics would work best, who should be responsible for producing the metrics and accountable for achieving the target values (two very different roles), and which metrics should become a part of any outsourcing SLA, etc.? What were building is a rigorous tool for ensuring that you have the right metrics in place for running the HRMDS, the HRM domains business, and, of greatest importance, for achieving the needed business outcomes. When you outsource an HRM process, or a set of integrated HRM processes, some of the needed metrics are of more interest to the outsourcing provider than to their customer. An understanding of the complete landscape of needed metrics will help you decide what to include in your service level agreements, what will be your own responsibility, and what analytics will be needed–regardless of who delivers them to run your business and achieve its agreed upon outcomes.
