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 joining this roadtrip, you can catch up by reading Part I, Part II and Part III before continuing here.

When last we met, we were busily rethinking every aspect of human resource management, from organizational designs and governance to the specific business rules of each HRM program/plan/practice, from the perspective of what’s needed to achieve the agreed HRM outcomes.  And we had previously linked those HRM outcomes to achieving the organization’s overall business outcomes.  Now it’s time to put everything we’ve done up to now to work in designing the HRM delivery system (HRMDS) that’s needed to make operational human resource management as we wish it to be rather than as it has been. 

The Customer View

To do that, it helps to consider the HRMDS from three separate perspectives — the customer view, the platform view and the operating model view.   The customer view consists of all the various means by which we expect customers to interact with the HRMDS, to include wireless and wired, smart phone and PC online experiences plus everything that gets done by phone, in person, via snail mail or email, etc.  And although I believe very strongly in intelligent self service, therefore in automating to the max the customer’s view of the HRMDS, there remain many good reasons to reserve specific event-based interactions for phone or in-person treatment as well as many work situations/geographies in which fully intelligent self service just cannot be (or cannot yet be) implemented or supported, however desirable such self service may be.  When you consider that the human resource management subject matter domain involves processes which are invoked by more than 2,000 different business events (although some are closely related), and that more than 80% of these business events are initiated by managers, employees, position seekers etc., it becomes absolutely obvious that servicing these customers where they live — rather than just focusing on servicing the HR, payroll, development, benefits, etc. specialists — must be a critical design principle for any HRMDS.  The goal is obviously to have a completely integrated customer view, because this makes the customer more productive than if they have to deal with myriad protocols and remember (or be “coached”) to do things differently in each one of them.  However, the reality is that each organization’s HRMDS consists of many different components, built up over the years and/or obtained from different sources, such that there are bound to be differences in the ways in which the customer view presents itself.  One goal of strategic HRMDS planning is to reduce systematically these differences through greater integration of the underlying components (ideal) and/or adding an integrating customer view layer on top of the underlying components (more often the case).

The Platform View

The HRMDS platform view pulls together all of the software, databases, and technology infrastructure that are needed to deliver and sustain the customer view as well as to carry out needed security, privacy, compliance, operational and similar “out of sight” but essential support processes.  There’s a lot of outsourcing going on here, at a minimum for the design through development and support of the packaged software (applications, database, operating system, etc.) that’s at the heart of the platform view.  We may also be outsourcing small amounts or whole swaths of the customer and platform views, and even the operating model views, for entire processes, and then integrating them (or not) into our customer view.  For example, when you outsource background checking or payroll processing, you expect the provider to deliver the results of those processes using their own platform view, customer view and operating model view.  What you expect is that you will invoke these outsourced processes from the appropriate points in your HRMDS, that the provider has the software, databases, operating capabilities etc. with which to execute their assigned processes and then bring those results back into your HRMDS at the appropriate points, and that this back and forth will be carried out according to the service level agreements in place for the relationship between your organization and that outsourcing provider.  But regardless of what components of the platform are proprietary, which ones are obtained from vendors/providers, which ones are operated within our own technology environment and which ones are operated by 3rd parties, the sum of all these parts must be a platform capable of delivering HRM as we have designed it and to the standard needed to achieve the HRM business outcomes to which we’re committed.

The Operating Model View

It’s the HRMDS operating model view that populates, organizationally, the roles and work units needed to design, build, implement, operate, monitor, improve, etc. the HRM delivery system.  From customer service reps in a call center environment, to the project management office for the HRMDS, to the data center folks (your own or those of various 3rd parties), everyone who plays a role in the life cycle and operations of your HRMDS “lives” here.  And this perspective makes very clear that, when you outsource any aspect of the HRMDS — and everyone does — the responsibility for governance over the many moving parts rests squarely with you, the end-user HR leadership which is the owner of your HRMDS.  And the more 3rd parties with whom you have to negotiate and administer various types of product/service agreements, the more 3rd parties whose products/services have to be integrated within the HRMDS customer and platform views, the more 3rd parties whose products/services have to be understood and deployed by your organization, the greater the expertise needed and workload carried by this HRMDS governance role.  Even when much of the software and databases are delivered via true SaaS (or SaaS InFullBloom), there’s still a great deal of the operating model for which the end-user HR leadership is responsible — and which is delegated or outsourced at your peril.  Before leaving the operating model, there’s one more very important point to be made.  When the HRMDS is heavily manual, when its platform view is a mess, when it’s underlying software isn’t very capable or is under pressure from regulatory activism, when things go bump in the night, it’s the operating model that takes up the slack, that steps in to deliver needed processes.  More automation means a lighter load for the operating model — and that’s a very good thing.

The Magic Happens Here

If you’ve traveled this far along the Yellow Brick Road in the company of a great HRMDS architect, then she’s been making copious notes along the away about the HRMDS implications of every decision made about organizational and HRM outcomes, processes, and related considerations as well as about the organization’s decision-making processes, culture, risk-taking profile, etc.  She’s noted the makeup and location of the work and workforce to get a good idea about what’s practical in terms of the customer view’s mix of intelligent self service as well as what’s important for mano a mano treatment.  She’s noted which HRM processes need maximum, immediate, and highly configurable leverage via the HRMDS because of their direct impact on achieving organizational outcomes and which HRM processes, while important and complex, could be handled by 3rd parties to some industry standard rather than being tailored precisely to your organization’s needs.  She’s noted a whole range of complexity factors as they apply to your organization, from degrees of globalization to industry-specific compliance requirements, and has used these complexity factors to eliminate potential platform component vendors/providers which just can’t meet your needs.  And she’s done all of this against a backdrop of considerable knowledge of your current HRMDS, especially of its platform and customer views, so that she can size the delta between what you have and what you need even as she’s considering how to close those gaps and the business case for doing so.  This is where the magic happens, where very skilled HRMDS architects and analysts pull together all the pieces to develop a concept for your next generation HRMDS, whether it’s a small or large leap from your current one, and the outcomes-based business case for making the investments to get there.  It’s not really magic, just a lot of experience, knowledge and heavy analytical lifting. 

Final Thoughts On The Journey

When I launched this blog, my intent was to share what I’ve learned about great HRM delivery systems, from planning to implementation to operations and everything in-between, with a special emphasis on the enterprise applications software that’s at the heart of a great HRMDS.  I didn’t know then that we’d be sharing not only down the journey toward great HRM delivery systems but also my own life’s journey.  The big learning for me is that, in the world of social technology, it’s simply not possible to do one without the other.