In a previous post, I focused on the most fundamental metrics for measuring the impact of changes in HRM, presumably intended as improvements, on revenues and profitability. Hopefully, I succeeded in offering no-nonsense, strictly financial metrics. Focusing on changes in revenues and profitability per agreed measures of workforce effort provides a starting point for thinking about what drives those changes and what as well as how HRM changes/improvements affect those drivers.
That was a good start toward getting clear about the terminology we should use to discuss the linkages between HRM and business outcomes, but it was only a start. I’ve always believed that a major reason why HR executives don’t have more clout is the lack of a precise and universal vocabulary with which to discuss HRM issues and to make their connections to business outcomes. Just ask a room full of HR folks to define employee, position and job, and you’ll know what I mean by the lack of a precise and universal vocabulary.
Vocabulary does shape thinking, and vice verse, which is one of the reasons I so love the Yiddish language. No language (to my knowledge) is richer in ways to describe the burdens of life or the failures and weaknesses of men, evolved no doubt from the burdens of having lived in peril for 10,000 years and having had plenty of time to observe their own failures and weaknesses as well as those of their oppressors. But we at the intersection of HRM and IT, and those we serve, are equally influenced by the vocabulary we use to describe our burdens and failures or weaknesses, and we need an equally rich as well as precise and universal terminology for discussing what we’ve accomplished and where we’re headed. Yiddish would be great for this, but I’m no longer sufficiently fluent nor has that wonderful language evolved sufficiently to cover the intersection of 21st century HRM and IT. So we’ll proceed in English.
Total Cost Of Ownership (TCO)
This is the metric used by both software vendors and their IT customers (but which could also be used by in-house or contracted custom software developers and their IT management) to consider all of the costs associated with acquiring and deploying (regardless of the underlying business model) the functionality of a packaged software application or custom software development. It includes the direct costs of (1) software development, acquisition, subscription, maintenance and upgrades, (2) software implementation and ongoing support, (3) software operations with its allocated costs of aggregate operations, e.g. hardware, networks, data storage, backup and recovery capabilities, and (4) all the other costs associated with implementing and operating a collection of software functionality over some agreed period of time.
Even as the movement of our industry to SaaS has changed rather dramatically what’s included in TCO from the customer’s perspective, there’s still an awful lot being written about TCO in the age of SaaS. In my view, far too much emphasis has been placed on this metric by the vendors, custom developers and IT organizations given that there’s no indication here of how or if business outcomes are achieved, i.e. of what you get for the $$. Frankly, it’s one of those metrics that are relatively easy to calculate and are used, therefore, in place of more valuable but far more difficult to calculate metrics.
We can develop TCO, for a specific HRM delivery system (HRMDS), by adding up the direct and indirect costs of the bits and pieces in the current state HRMDS over an agreed upon period of time. Labor arbitrage often can be applied to both the automated and manual components of the HRMDS to achieve initially large savings. Next level TCO savings can be achieved by substituting well done automated components for manual ones and then by bringing as much standardization as possible to those automated and manual components. But all the TCO savings in the world, however achieved (and care must be taken not to destroy value creation via HRM in the name of reduced administrative costs), will not improve materially the client organization’s business outcomes — and tha’s the essential flaw in TCO. Moreover, focusing on TCO to the exclusion of other, more outcomes-focused metrics, may actually reduce more important outcomes even as you’re reducing TCO, a undesirable unattractive outcome even on the administrative cost side of the equation.
Total Cost Of Service Delivery (TCSD)
This far more useful metric, in my view, adds to the data center operations and software-focused total cost of ownership the additional people and process costs that are needed to deliver to end-users (i.e. to employees, managers, specialist users of all kinds) specific HRM process outcomes, e.g. completion of a performance review, completion of a new hire event, or completion of a payroll process. This metric becomes particularly important in the BPO business because that total cost of service delivery, at least for in-scope processes, is the responsibility of the BPO provider and has a huge impact on their financial success or failure.
Using total cost of service delivery also provides a much stronger business case for further automation as well as for labor and facilities arbitrage. Where service delivery is very heavily automated and entirely self service, total cost of service delivery approaches total cost of ownership, which is a good thing, and can help us make informed decisions about investments in software and self service versus investments in call centers and human processors. However, this still doesn’t give us a measure of what we’re getting in business outcomes for the $$ spent.
We can develop TCSD, for a specific HRMDS, specific patterns of customer usage, with some care in defining what constitutes a service, and with measuring the relative satisfaction with these same services, if we already know our TCO. By adding what lies on the customer’s “side of the mirror” for different types of customers and specific services, and with what level of servicing satisfaction, we can create a metric which is far less amenable to reduction purely via HRMDS labor arbitrage or even standardization but which is very amenable to more complete and correct automation and, especially, to more intelligent self service. While this greater automation can take advantage of labor arbitrage, an emphasis on configuration capabilities and tools, and appropriate kinds of standardization, making a significant improvement in TCSD requires that we understand what’s happening on the customer’s “side of the mirror” before and after an interaction with the HRMDS.
Total Cost Of Delivering Agreed Process Outcomes (TCPO)
Even more useful is this measure of not only the cost of service delivery but reported against the agreed upon (including contractual SLAs) outcome measures, to include various measures of general service quality (e.g. error rates, response times, customer satisfaction, and issue escalation) as well as various measures of specific process results (e.g. cost of hire and elapsed time to fill, % of performance reviews completed by their due date and the % which passed managerial review). With these process outcome measures, which get much more difficult to define and then report against as you go from the general to the specific, we begin to get at what value the customer is receiving at some level of investment. Since some version of these outcomes is often the basis upon which BPO or shared services revenues are accrued, this measure also helps us understand what we’re actually spending to achieve those revenues when everything is considered.
If we take TCSD and add the costs on the customer’s “side of the mirror” for a given process outcome, then we’re beginning to get a complete picture of what it really takes to achieve that outcome. This also allows us to improve service levels by putting more of the work of achieving process outcomes inside the HRMDS, ideally inside the software platform, where we can ensure greater availability, consistency, adherence to business rules, litigation avoidance, etc. This is the complete picture we want when we talk about not only the total cost to achieve specific error rates, response times, customer satisfaction, and issue escalation but also to achieve target values for cost of hire and elapsed time to fill, % of performance reviews completed by their due date and the % which passed managerial review.
Total Cost Of Delivering Business Outcomes (TCBO)
But the most important HRM metric, and the most difficult to assess, is the total cost of delivering business outcomes. TCBO connects TCSD and TCPO with specific business outcomes, e.g. the total cost of delivering one highly qualified, good fit new hire or the total cost of delivering, per salesman, target growth in sales revenues via a new incentive compensation plan and related sales training. The new idea here is that, to the business owner, what matters are the business outcomes, and being able to predict those outcomes, rather than the process activities or even process outcomes.
When you work toward this view of the HRMDS, many of the investments needed to achieve truly world class HRM practices as well as a world class HRM delivery system, e.g. proactive, intelligent self service, can be justified on the basis of the expected improvement in needed business outcomes. If some agreed version of revenue or profitability per some agreed version of FTEs is our most basic private sector goal for investments in HRM/HRMDS, then changes in same are the business case for those investments.
You can’t begin to develop this metric unless the HR organization has done some version of strategic HRMDS planning which aligns their organization’s overall business outcomes with the relevant HRM business outcomes and goes from there to the implied HRMDS capabilities. But unless the HR organization does this work, they’ll be guilty (and so may their BPO providers, if any, however unfairly) of reducing benefits administration costs without tackling the real cost of those benefits along with their impact of hiring, engagement, etc. Of they’ll be guilty of reducing the time and cost to hire without reducing the elapsed time to productivity or increasing the quality of hire, etc.
After the obvious initial cost savings around TCO and even after the much more important improvements in TCSD, both of which are easily forgotten and become “table stakes,” and even after big improvements in TCPO, what is durable are ongoing improvements in business outcomes and the role played in achieving these outcomes by HRM and the HRMDS. Clearly, we’ve still got some work to do.
[If you’d like to learn a lot more about how your can “Follow The Yellow Brick Road” to linking investments in HRM (and the HRM delivery system) to needed business outcomes, have I got some posts for you — but remember to read them in reverse order:
Follow The Yellow Brick Road Part IV/Finale: The HRM Delivery System!
If you feel like you’ve been stranded along the way or that we’ve (or you’ve) been off on various scenic detours, my apologies for not providing the final installment of our Yellow Brick Road travelogue as quickly as I had hoped. Life just keeps happening; we keep up as best we can. And if you’re just […]
Follow The Yellow Brick Road Part III: HRM Strategies, Outcomes And Design
My apologies for the long detour from the Yellow Brick Road while I attended to heavy business travel, client deliverables, more shoulder rehab, and the final business details for closing on M/V SmartyPants. More on SmartyPants in a later next post, complete with pictures. For now, we’ve got a lot more work to do along […]
Follow The Yellow Brick Road Part II: Vision, Strategy And Outcomes
In Part I of our journey down the yellow brick road to great HRM and HRM delivery systems, I set the stage in terms of the environment in which our organizations must operate and what they must do to be successful. By now you should have decided for your own organization – or will do this shortly […]
Follow The Yellow Brick Road Part I: Business Environment And Challenges
In my 2/9/2010 post, I announced that I would be publishing my strategic HRM delivery systems planning methodology on this blog, so I thought I’d better get started. Although there’s a very geeky set of materials to guide me on these projects, I call the version of my methodology intended for clients, “follow the yellow […]