In Full Bloom

In Search Of HRM/HRMDS/HR Tech “Best” Practices: Istanbul To Venice

Venice Lingers In The Mind Like A Love Song

Istanbul was Constantinople, now it’s Istanbul.

Ron and I will be traveling from 4/30 through 5/17/10 from Istanbul to Venice, soaking up “best” practices in HRM, the HRM delivery system and HR technology every step of the way. I’ll be doing some tweeting from “the road,” @InFullBloomUS, but I may not have time to blog for a while.

Did you ever wonder how gondoliers are scheduled to their gondolas? How the bath attendants in Turkey are licensed? What TOTAL COMPENSATION PLANs are used, not to mention what KSAOC profiles, EMPLOYEE engagement techniques and workforce development programs, to achieve shipboard perfection in service levels? Are you concerned about the impact of Greece’s debt crisis on the Greek workforce and Greek HRM? What about how (or if?) all of these approaches/issues are automated in the developing countries along the Adriatic coast?

I can’t promise that I’ll return with the definitive answers to all of these questions, but I certainly hope to be carrying a lifetime’s worth of travel memories. And the best part of this trip will be some quality time with The Wallace. Can you even imagine what he has to put up with on a day-to-day basis? “Talk” to you from the road.

By the way, to all the 2nd story men who are reading this blog, our life sitter will be in residence while we’re on the road, as always. And you don’t want to mess with her fella.

More Of Naomi’s Killer Scenarios: Retroactive Processing

Once upon a time, the concept of retroactive payroll processing was invented to handle the all too often situation of a personnel action (that’s what they were called when I was young) that was presented to “the system” after the date on which is should have taken effect. Without a retroactive processing capability in payroll, someone would hand calculate the delta for every element of gross pay and every deduction between what had been calculated — and this could involve many pay periods — and what should have been calculated. They would then determine how to handle that delta in terms of making specific changes to the current payroll calculations, adding a little to gross pay here and/or taking a little away from specific deductions there. Annoying yes, but an entirely doable manual process when the odd personnel action was late.

But what about all that hand calculating when a LABOR AGREEMENT was finally signed six months after the end date of the previous agreement and with all provisions made retroactive to that end date? Or when it was discovered, six months into the year, that the health care plan deduction amounts table was in error? Or when, at year-end, it was discovered that the FICA calculation had run amuck? As the workload grew from all this hand calculating and manual adjusting, a clever programmer, whose name has been lost in the mists of time, saw the possibility of creating a payroll application which could do much of this in an automated way. With a little effective dating here, and a little re-entrant code there, the first, modestly capable, retroactive processing payroll — one of my preferred behaviors — was born.

But, as with so many great inventions, it became obvious very quickly that these early efforts could only handle some very specific and limited retroactive processing scenarios (or Use Cases). What if there were intervening rule changes between the date on which the delayed personnel action should have been processed and when it was actually processed? What if there were ripple effects that weren’t just about payroll calculations, to include the domino effects when succession plans are executed? What if there wasn’t just one error in the health care plan deduction amounts table but an error there and in the corresponding eligibility criteria so that employees were ending up in the wrong plans as well as having the wrong amounts deducted for those plans? To make further progress in retroactive processing, to decide how far to go/at what cost/with what business case, we needed some way of organizing the many possible scenarios.

With too many different flavors of retroactive processing to count, let alone to provide written scenarios here, this taxonomy, which I’ve been using for nearly twenty years, provides a framework for the discussion — and for developing scenarios for those flavors that are relevant to your business. Retroactive processing may be needed to accommodate:

A single late event with no intervening rules changes or ripple affects — with and without $ affects;
A single late event with no intervening rules changes but with a ripple affect — with and without $ affects;
A single late event with intervening rules changes but no ripple affects — with and without $ affects;
A single late event with intervening rules changes and ripple affects — with and without $ affects; and
A group of late events under thesel eight conditions.
A single incorrect event with no intervening rules changes or ripple affects — with and without $ affects;
A single incorrect event with no intervening rules changes but with a ripple affect — with and without $ affects;
A single incorrect event with intervening rules changes but no ripple affects — with and without $ affects;
A single incorrect event with intervening rules changes and ripple affects — with and without $ affects; and
A group of incorrect events under these eight conditions.
A single late rules change with no intervening rules changes or ripple affects — with and without $ affects;
A single late rules change with no intervening rules changes but with a ripple affect — with and without $ affects;
A single late rules change with intervening rules changes but no ripple affects — with and without $ affects;
A single late rules change with intervening rules changes and ripple affects — with and without $ affects; and
A group of late rules changes under these eight conditions.
A single incorrect rules change with no intervening rules changes or ripple affects — with and without $ affects;
A single incorrect rules change with no intervening rules changes but with a ripple affect — with and without $ affects;
A single incorrect rules change with an intervening rules change but no ripple affects — with and without $ affects;
A single incorrect rules change with intervening rules changes and ripple affects — with and without $ affects; and
A group of incorrect rules changes under these eight conditions.

This is another one of those situations where no one in their right mind would attempt to automate every possible scenario because the cost of doing so would far outweigh the benefits of being able to handle something that rarely happens or whose cost to correct manually is quite reasonable. But this taxomony should be translated by end-users into “killer” scenarios that test any HCM software of interest for its retroactive processing capabilities — far beyond payroll of course — as they would impact the real world needs of that end-user. And HCM software vendors will want to ensure that their products do a great job of handling those retroactive processing scenarios that are appropriate to their scope and target markets.

Now how many verb tenses will you need to write those scenarios? And what scenarios have you encountered that don’t have a home in my taxonomy? There’s a bottle of Tres Generaciones waiting for you if you’re able to propose an HRM scenario for which the taxonomy doesn’t provide a home.

The Future Of HRM Software: Effective Dating

Tempus Fugit!

Did you think this was going to be a guide to finding the man/woman of your dreams? Wrong!

If you ask any HRM software vendor or BPO provider if their software is effective-dated, the universal response will be yes. And they’re telling the truth. Even the sorriest HRM software allows for the effective-dating of SOME data changes. But when I ask if software is effective-dated, this post describes the standard against which I’m measuring not only the vendor/provider’s answers but also what I’m checking out via deep software dives.

The Basics

First, the basics. I’m expecting to find systemic and easily used effective dating for all platform components, i.e. for each software object or Web service, for each “chunk” of data (e.g. row in a relational table or object with its methods and attributes in an object data base), or for each “chunk” of procedural code (although we really don’t want to see procedural code in the applications but rather confined to the application development tools that support models-driven development), which allows for:

breaks in time and insertions to correct history (while noting insertion date, i.e. distinguishing between the effective date and the actual date that a row or object was created);
“fully” (within practical limits) automated retroactive and prospective processing, including complex event handling, to include the ripple effects of intermediate data and/or business rule changes;
repositioning the data base and application logic to a specific date or elapsed time period;
sufficient granularity of effective dating (which really means sufficient normalization of relational tables, sufficiently small Web services, etc.) to ensure that whatever dated changes occur are truly independent of all other changes;
consistent effective dating across all platform components; and
easily understood and consistently applied default dates to ease the customer and operational experience and to prevent errors.

Every relevant row in a derived physical relational table or relevant object in an object data base should be described by effective date(s) where these dates (and the associated time of day) are based upon a global concept of date and time (i.e. Coordinated Universal Time, the successor to Greenwich Mean Time for this purpose). When properly done, effective dating provides a natural audit trail, but the specific audit trail requirements by industry, contract and/or regulation may well (and do) impose additional design considerations.

The Nuances

With the basics covered, there are many more aspects to effective-dating that must be addressed:

Effective and correction dating consistency — even though some tables or objects could function without effective dating and/or correction dating (used to preserve the audit trail of changes), I prefer that vendors treat all tables or objects alike, i.e. with the same effective and correction dating attributes and behaviors. This is much easier for the user to understand and use than having different patterns of effective dating for different platform components. Rather than conserving computing resources, which was an earlier and necessary design principle, good design is now all about user productivity and effectiveness.
Default dates — the software should presume that today’s date is the effective date/start date and that there is no end date for each action unless another date is given. However, where this doesn’t make sense, e.g. where today’s date isn’t an appropriate elapsed time from another date (e.g. where hire date is before the approved budget date for the target POSITION*), the user should be prompted for a valid effective or start date. Similarly, where open-ended doesn’t make sense for the end date, e.g. an open-ended assignment of a HUMAN RESOURCE to a project-type WORK UNIT of specific duration, the user should be prompted for the end date. In all cases, there must be enough embedded intelligence to guide users to sensible effective dating decisions with clear explanations of the ripple effect of their choices.
Prospective and retroactive processing — this is the ability of the entire set of HRMDS platform components to operate as of some future date (i.e. to model a future state, e.g. of an organizational change or a proposed TOTAL COMPENSATION PLAN design change) or, more commonly, calculate and account for/distribute the effects of a retroactive change with payroll impacts. Retroactive payroll processing capabilities involve knowing what was, calculating what should have been, applying the right business rules to each delta, and addressing all of these changes in the current or future periods.
Effective-dated event processing — the software should process retroactive, current and future-dated business events against the business rules (including all edits), embedded intelligence, and entity as well as reference data that are or were or will be applicable for the event’s effective date. Such event processing, if prospective, should also consider pending future-dated events that are waiting to take effect.
Forecasting and simulation — it should be possible for the HRM delivery system’s platform to forecast the impact if a particular action or group of actions were taken, e.g. what would we incur in overtime next month if we change work schedules as follows? What would be our diversity profile if we make these workforce movements? What would be our training backlog for the first line supervisor program (e.g. the backlog of eligible people for whom there are not yet any available training slots) if we have the following training schedule? This ability to forecast should be both point in time (e.g. what would be our headcount as of year-end if we do the following…?) and period of time (e.g. what would be our sales revenues over the period x to y if we deploy ten more sales people with a mastery level of the following KSAOCs?).
Multiple chronological perspectives at one time — data and processes must be viewed from proposed, pending, current, historical and retroactive chronological perspectives. Entity and reference data (or objects) must be synchronized with the relevant, effective-dated business rules. Payroll processing is usually retrospective (if not retroactive), although it’s important to be able to run a payroll prospectively in order to forecast the impact of business rule changes. New events must be viewed against current and pending entity and reference data (or objects).
Historical data — What event-based historical data is needed? For how long? At what cost? How accessible must it be? Who will decide? What happens when historical data is not compatible with today’s object model structures? How do we “revise” history? We must insert what should have been when it was detected (the date/time of processing) but with an effective date of when it should have happened. Therefore, we must be able to distinguish among what we thought should have happened, what in reality did happen (although, perhaps, in error), and what has now been done to make the correct thing happen. It’s impossible to even discuss these issues without 17 verb tenses.
Case management data — some business events are interrelated in very predictable, cause and effect, ways. Where those events have a case-like resolution process, it can be quite useful to use finite state-processing to capture and process the many steps involved in the resolution. Think environmental, health and safety incidents (a.k.a. EHS INCIDENTs), HRM GRIEVANCE/COMPLAINT, individual being taken through the evaluation process for a specific POSITION, and a TOTAL COMPENSATION PLAN claim.

Using these notes to establish the baseline, it’s clear that every HRM software application is NOT fully effective-dated. To check this out, some easily detected limitations include:

undated, presumed static attributes, e.g. gender;
undated and either replaced or overlaid user-developed “code” in vendor-provided programming languages;
security of access that’s attached to a person and for which there’s no ability for that person to process retrospective business events; and
dare I say it, undated metadata and/or business rules.

Don’t take my word for this. Check out your own packaged software. And do give me your comments on who’s doing a great job on this — and who’s NOT.

* When you see an HRM concept in all capital letters, this is a reference to one of the major object classes from my domain model “starter kit.” With more vendors/providers using the “starter kit,” I thought I would begin using that formal terminology, where appropriate, to link the content of my posts to their work in modeling the domain for fun and profit.

The Future Of HRM Software: Naomi’s Preferred Behaviors

Who Can Forget This Teaching Moment? Susan Boyle Sings Out

Having done the first post in this series, on interrogatory configuration, without even realizing that I wanted to do an entire series, I then did a setup post to launch what I hope will be considerable discussion of the desired architectural characteristics (a.k.a. Naomi’s preferred HRMDS platform behaviors) of great HRM software. No one HRM software package, or even custom application, may need all of these behaviors or need them to the high standard that I’m setting in these posts. But “if we shoot for the stars, we’ll at least reach the moon,” one of my Mom’s favorite motivational aphorisms.

Preferred Behaviors

Preferred behaviors are the systemic, object model and/or architecturally-produced application software (i.e. platform) capabilities that:

improve materially the HRMDS cost/quality of service delivery for both the end-user and vendor/provider;
improve materially the ease/cost/elapsed time of the sales cycle and initial/ongoing implementations, again for both the end-user and the vendor/provider;
provide substantial agility in the face of new business requirements;
enhance customer acceptance and usability;
enable the cost-effective and customer-pleasing use of the software in a variety of deployment business models, from licensing and in-house implementation to SaaS through comprehensive HRM BPO — although I freely admit that my emphasis over the last several years — and some might say my bias — has been on true SaaS and SaaS-based BPO;
make SaaS and BPO economically viable — I believe that we have passed the tipping point on HRM SaaS for new development (the vendor perspective) and new implementations (the customer perspective), but the very large installed base of older licensed/on-premise (or even hosted “in the cloud”) ERPs/HRMSs will dominate HR/IT spend with maintenance fees for many years;
can be accomplished via different designs and technology choices, which is why they are presented here with minimal design detail (although I may have an opinion) and no technology preferences;
are, in many if not most cases, highly interrelated such that they must be addressed in groups; and
represent a combination of best practices in software engineering and the software development life cycle, insight gained via modeling the HRM domain and seeing its systemic patterns of complexity that could be addressed architecturally, and lessons learned through my own experiences and those of valued colleagues.

When I’m asked by end-users and vendors/providers what I look for when I’m exploring software, it’s always that combination of a correct object model (for the relevant domain scope that’s being addressed) and these preferred behaviors along with the relevant features/functions. Just as human beauty is a shallow thing that whithers with age, application software features/functions are the surface beauty that can show up very well in a demo but which don’t necessarily sustain you as your business needs change, markets mature, etc. Character, on the other hand, is a much deeper quality that ages very well — and such are great architecture and object models.

In my Preferred Behaviors “Starter Kit,” I include a lot of behavioral scenarios (where Use Cases are much more formally structured and rigorously presented but address the same topics) to provide examples, further clarifications, relevant business situations, etc. that:

enhance understanding of the preferred behavior;
begin the discussion of the business value, and therefore the business case, for the preferred behavior;
link the preferred behavior to the underlying HRM domain model to show where this behavior is needed to IT-enable specific aspects of the domain model;
link the preferred behavior to more colloquial expressions or understanding of the current state of HRM practice or automation; and/or
add my personal opinion/point of view/comments to the discussion.

As I write about these preferred behaviors, I’m going to do some companion “killer” scenario posts that provide scenarios you can use to determine how deeply a specific vendor’s architecture addresses the desired behavior as well as, for the vendor community, to provide a basis for determining how deeply you need to do so in order to be competitive. If you thought I was opinionated before, this series clinches the deal.

More Of Naomi’s “Killer” Scenarios: KSAOC-Centric Strategic HRM

: Figure 1: KSAOC-Centric, Strategic HRM

One of the great debates in HR circles is over what is strategic and what is merely administrative with respect to human resource management (HRM) processes. That which is strategic, often referred to as talent management, is considered worthy of executive attention, academic research, attendance at expensive conferences, and the writing of numerous articles. That which is merely administrative is beneath the attention of senior management except when cutting costs or, heaven forbid, when something goes wrong. And all of this discussion goes on without a rigorous or consistent definition of either strategic or administration HRM, let alone explaining their many interconnections or why we should care.

Strategic HRM is not hard to define. It consists of the processes (and, by extension, the data) that make a difference where it matters, by increasing materially the revenues and/or profits of the organization (or, for public sector organizations, by increasing materially the degree to which the mission is accomplished). Strategic HRM accomplishes this via the effective and efficient performance of individuals, of teams, and of other organizational units, where workforce performance can be enhanced by methods generally under the control of HR leadership. Thus, strategic HRM focuses on specific levers of individual and organizational performance, including:

Better definition and organization of work roles;
More accurate modeling of work role-specific KSAOCs, (i.e. knowledge, skills, abilities, behaviors, etc.);
Improved generation, selection, deployment, motivation and retention of KSAOC-rich persons;
More flexibility to deploy KSAOC-rich non-employee workers, e.g. consultants and contractors;
Improved generation, collection, sharing and deployment of organizational knowledge;
More effective deployment of electronic performance support systems, e.g. knowledge bases, analytics, and performance coaching applications;
Greater motivation of the workforce toward desired behaviors, outcomes and KSAOC growth via targeted total compensation plans and work environment programs;
Improved forecasting and development of needed KSAOCs;
Improved design and execution of performance management and leadership development programs;
Creation of a work environment that removes barriers to and encourages effective and innovative performance;
More effective relations with labor organizations and with the workforce; and
Better day-to-day coaching, mentoring, assignment, development and career planning, and performance management.

Give Me That KSAOC Religion!

Not surprisingly, KSAOCs are at the heart of strategic HRM – finding them, acquiring them, motivating them, developing them, removing barriers to unleashing them etc. – and KSAOCs must be at the heart of your HRM processes and data if you’re trying to do anything strategic about HRM. What should also be clear is the interconnectedness between these strategic HRM processes and the bedrock, system of record objects on which they are totally dependent, including JOB, POSITION, WORK UNIT, WORK LOCATION, TOTAL COMPENSATION PLAN, the PERSON object hierarchy, and the list goes on. The larger the swath of strategic HRM that you’re trying to implement, to technology-enable, in order to accomplish needed business outcomes, the more inextricably entertwined are these strategic processes with the structural, often administrative underpinnings upon which they depend.

For example, recording the termination of an employee is clearly administrative record-keeping, but determining which managers are having disproportionately high turnover, when other variables are accounted for, is very important information for driving the design of supervisory and manager developmental programs. Keeping track of employee eligibility and enrollment in various health and welfare benefit plans is certainly an administrative responsibility, but determining to what extent the design of these same plans is enabling or working against our retention of top performers is essential to managing organizational performance. In fact, we can find strategic data connections inside nearly all our humble administrative transactions, and therein lies a very real challenge for the design of your HRM delivery system.

Another really good example, and one which is so familiar as to lull us into a false sense of security, is managing headcount. It’s on the backs of such administrative transactions as hires, terminations, promotions, and transfers that headcount reports are made. But what’s really important about headcount management is to understand what KSAOCs are coming and going through the organization. Are we losing critical KSAOCs at twice the rate at which we’re replacing them? Are the confirmed deadwood staying even as our best and brightest walk out the door? Are offers made but not yet accepted turning into offers never accepted for reasons that could be avoided? And why are some managers’ staff self-identifying for every posted opportunity? Is it a rush to get away from said managers or that those managers are encouraging career development at their own expense? So many questions whose answers depend on having the data surrounding those administrative transactions designed to support these more strategic questions.

“Killer” Scenarios For KSAOC-Centric HRM

Whether you’re evaluating HRM software for in-house implementation or evaluating the HRM delivery systems of HRM BPO providers, you won’t get strategic HRM support unless your vendor or provider has a KSAOC-centered platform. Figure 1 above (click to enlarge) provides a collection of “killer” scenarios for determining to what extent your HRM software vendor’s products or HRM BPO provider’s platform provide a KSAOC-centric approach to all of the covered/in-scope HRM processes. For each of the seven highest level HRM processes, the phrases shown in Figure 1 are examples of what goes on in those processes that can only be completed by having an agreed upon vocabulary for KSAOCs with which to replace the “…”. Furthermore, the relationships among these highest level processes are all about KSAOCs – organizing the work around them, attracting a workforce which has them, developing them in the workforce, incenting their use via total compensation plan design, creating an environment which is conducive to their use, focusing relationships with labor organizations to obtain them, and leading the workforce every day to deploy them, to name just a few.

Now that the connection between KSAOCs and strategic HRM is clear, let’s NOT lose this connection through the short-sighted use of HRM software silos, whether your own or those of a BPO provider. And don’t let the design and automation, again whether your own or those of a BPO provider, of those administrative processes hobble your ability to achieve the important business results that only strategic HRM can produce. When we owned the entire HRM delivery system, we only had to negotiate with ourselves, which was hard enough to do, when we realized that we had failed to design the initial data, processes and transactions to serve more than an administrative purpose. But when we have outsourced a good chunk of that HRM delivery system, we have to negotiate with our outsourcing provider(s) to redo those early data, process and transaction designs in order to achieve our HRM business outcomes. Of course, if we never defined those business outcomes in the first place, or if we failed to link those outcomes to the needed HRM delivery system capabilities, then we don’t even know what strategic HRM processes are needed, let alone by what metrics we would measure their delivery. If we’ve never made the journey down the Yellow Brick Road, shame on us!

Product Update: PeopleSoft 9.1 Talent Management

I’ve pulled the original post while discussions are underway with Oracle to address their specific concerns about its completeness, correctness and factual basis.

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.

M&A Observations: NorthgateArinso Acquires Convergys’ HRO Business

There’s been a lot of commentary on this deal, so well may you ask what more there is to say. But just like with the Workday 10 release on which I just posted, I think there are several aspects of the NorthgateArinso/Convergys HRO deal that deserve further attention. Against a backdrop of why Convergys HRO failed and what that failure means for this deal, I think there are four topics worthy of further discussion:

the upside and challenges for NorthgateArinso;
the implications for the HR outsourcing competitive landscape;
the implications for current and prospective HR outsourcing customers and for the HR leaders of these firms,; and
the impact this should have on our thinking about M&A/investments/liquidity events/etc. across the HRM software and services industry.

A tall order for one blog post, but it’s an important subject since nearly all HR organizations outsource some to many of their HRM (including payroll and benefits administration) processes — with more to come, in my opinion.

Why Convergys HRO Failed

Before we can talk about this particular deal and its broader implications in these four areas, it’s important to understand why Convergys needed to sell it’s HRO assets. Convergys’ HRO business had been for sale for quite a while even as they worked very hard to improve their financials, improve scale and repeatability, renegotiate no-win contracts, etc. I’ve said that Convergys was doomed in the HRO business because of three, easily observed from the outside looking in but very difficult to correct strategic errors.

First, I believe that Convergys got into HRO, at least in part, because they were thinking that it was an obvious extension of their call center business and expertise at a time when shared services initiatives in very large HR organizations put a high premium on efficient, phone-based customer care. Perhaps they thought that HRO was more like the call center business than it is, just as others who jumped into HRO, and are no more, thought HRO was just like ITO or a simple expansion of benefits administration. These and several other misguided underestimations of just how hard it is to do the heavy lifting of HR data administration, payroll, employee and manager self service, etc have taken their toll: ACS has disappeared into Xerox, Exult disappeared into Hewitt and almost took Hewitt down before they refocused on benefits administration, and Fidelity has just disappeared from this business altogether except for some benefits administration and their forte in 401K administration. Our industry has paid a huge price for this underestimation, except for the small number of investors/executives who made out like bandits. In my opinion, call-based customer service in HRM is too costly (despite labor arbitrage), too error-prone, too buried in bad accents, and too hard to manage to have been anything other than a stopgap on the road to intelligent self . And Convergys was too slow to implement truly intelligent self service as a full (nearly full?) replacement for not only their call centers but many other essentially manual HRM processes. There’s a lesson here for everyone in the HR outsourcing business, and that’s the importance of moving as quickly as possible to intelligent self service. Younger workers demand it; others may need encouragement to get with the program. But no outsourcer can prosper if they’re being eaten alive by call center-based services and manual processes.

Second, SAP is just not a great platform for HRO unless, like NorthgateArinso with euHReka, you wrap it with multi-tenancy, add enormous and cost-effective configuration experience and tools, and provide a much improved self service capability. We can understand that Convergys was going after a class of customer, e.g. Dupont and Johnson & Johnson, which would probably have rejected outright any attempts to impose a more streamlined/standardized approach to their use of SAP, but it’s hard to understand how Convergys expected to profit from such clients even once they were implemented fully, especially given the next strategic error. But I should also note here that I don’t think the outcome would have been any different if Convergys had chosen PeopleSoft or Oracle’s EBS HCM for their platform without having any particular expertise or IP based on them. None of these products were built to support the economies of scale necessary in both implementing and operating an HRM BPO business without the BPO provider being able to surround the ERP/HRMS with a lot of IP, discipline, and proprietary technology. And it takes years of disciplined implementation experience to build up those assets.

Third, whatever profit there was to be made in these deals, whatever IP there was to gain, went substantially to Deloitte. Without any of the needed ERP/HRMS implementation KSAOCs, let alone the transformational/change management ones (real or perceived), Convergys partnered for all of that work with Deloitte. I thought this was a bad idea from the start — and said so. Deloitte made a ton of up-front money and built further experience and reuseable IP, while Convergys got stuck with the heavy lifting of operations, of the day-to-day delivery of whatever Deloitte had implemented. And Deloitte had no more incentive (well, perhaps a little more) than most traditional time and material SIs doing ERP implementations to steer customers aggressively toward standardization where there’s no business case for anything but. Meaning no disrespect to Deloitte, but there’s a smart, fast way to implement SAP and then there’s the approach still in use by some of the traditional, so-called transformational SIs. HRM BPO absolutely requires the smart, fast implementation no matter how great or appropriate the underlying platform.

I’m sure there were many other reasons why, in spite of yeoman efforts by the Convergys HRO team to turn their business into a winner, they just couldn’t get to the needed margins, let alone do so under the glare of public company financial scrutiny. But one of the great advantages NorthgateArinso has right now — and that many other HCM software and services firms have or are pursuing — is the ability to work out the long term foundations of a successful business without the demands of being a public company.

What Does This Deal Mean For NorthgateArinso?

Of course this deal puts NorthgateArinso squarely on the HRM BPO map in the US, much more so than they’ve been before. It certainly gives them some marquee clients and additional and quite substantial global delivery/operational assets. It will also give them a body of new SAP implementation work, as well as some PeopleSoft support work, to feed their very capable implementation teams. There may even be situations in which a Convergys client or two will be interested in euHReka’s enhanced user experience, but that would require those clients to redo their implementations to be much more standardized or live with a euHReka overlay on top of their Deloitte-style SAP implementation. Will all of this combine to put NorthgateArinso onto the very short list of providers that qualify for the even shorter list (VERY short list) of end-to-end, Fortune 100+ deals in the pipeline? Will this persuade the sourcing advisors to say NorthgateArinso in the same breath as IBM for these types of deals? There’s been a lot of positive press on the upside of this deal, but I don’t think it’s all upside.

The first challenge is that Convergys’ customers are pretty wildly different than NorthgateArinso’s, not only as to size and globalness but also as to expectations when dealing with service providers. Second, without transformational consulting capabilities, NorthgateArinso is going to be tripping over that cast of characters prowling the halls at the likes of Dupont and Johnson & Johnson, advising them on everything from leadership development to total compensation plan design. Those folks will not be tempering their advise based upon the cost/complexity of implementing it but rather on the value proposition for doing it. Third, those changes are going to go thud, ka-ching when they run into each SAP implementation on which these customers are running, and those same customers will now be blaming NorthgateArinso for the cost and elapsed time to make these types of changes. Fourth, the broader issue is how will NorthgateArinso accommodate cost-effectively the needs of these customers for frequent, complex changes in their business practices and plans when each of them is running, separately, in an individually configured instance of SAP. Yes, Convergys worked very hard to ensure as much standardization as they could in these implementations, but I don’t believe for a minute that they got as far in this direction as NorthgateArinso is used to going with euHReka for their “native” HRM BPO clients. Fifth, and then there is the noise level/demand on NorthgateArinso’s executives of some Florida politicians making hay out of the sole source renewal of Convergys’ HRO deal with the state of Florida (a deal that was never appreciated for its many good points) just before all of this work fell into the “foreign” hands of NorthgateArinso. The Florida nonsense alone could be very distracting. Add up all these challenges, and they may amount to nothing more than the ongoing distraction of NorthgateArinso’s management by a few big name clients when they’re trying to build a scalable business around a standardized platform and processes. But it remains to be seen whether distraction or disciplined focus will characterize the Convergys part of NorthgateArinso’s business a year from now.

What Does This Deal Mean For NGA’s Competitors/The Competitive Landscape?

Naming names, I think this gives NorthgateArinso a considerable leg up among the likes of IBM, Accenture, Xerox/ACS and the wannabe Indian firms (none of whom have made much North American headway in truly integrated, multi-process HRM BPO for the highest end of the market), but they should be VERY careful what they wish for. Some to many of those folks may sign up for global payroll and/or benefits with a willingness to standardize processes and even business rules where there’s no competitive advantage to differentiation — assuming you’ve got the consulting chops to get them there organizationally. But will those same folks sign up for a very standardized, SAP-based platform when so many of them already have their own ERP licenses? And even if NorthgateArinso chooses not to compete for more Convergys-like customers, they’re still going to complicate the sales cycles of these competitors for a certain range of pursuits.

And what about ADP’s GlobalView and Patersons when it comes to global payroll? I think this deal gives NorthgateArinso a considerable leg up in competing with both of these firms, but they and ADP are still trapped in the underlying cost of service of their SAP foundations except where they escape the trap for small populations by using other payroll platforms and integrating (some might say aggregating) on the back end. Patersons may be able to do all of this at lower cost but clearly without the street cred/name recognition of an ADP and without the much broader service offering and global resources of a NorthgateArinso.

What Does This Deal Mean For HR Leaders/HR Outsourcing Customers/Prospects?

If what you really want in a provider is someone to run your mess for less or do some slightly classier sounding version of lift and shift, forget NorthgateArinso. Their future for larger, global deals is their euHReka platform — at least I hope it is. Taking on more of the deal types that nearly drowned Convergys may sound glamorous, but there’s just no way to service them cost-effectively, and buyers aren’t willing to pay the true cost of customized, one-off platforms. HRM BPO is a multi-tenant, highly automated, platform-based business where it’s successful, and NorthgateArinso means to continue its success. For complex middle market or larger global enterprises, NorthgateArinso has a lot to offer you if you’re willing to move off of whatever conglomeration of stuff you’re running now and onto their euHReka platform. But although NorthgateArinso can add new functionality into euHReka — and does — which isn’t in their delivered SAP platform, euHReka customers are tied to SAP’s aging underpinnings for the foreseeable. That wouldn’t be as much of a concern to me if SAP’s own next gen product strategy were more clear or if newer platforms weren’t gaining momentum. I may be the only person who thinks so, but I expect Workday to emerge as a BPO platform, Patersons to deliver increased amounts of HRM, and even the highest of the high end customers to wake up to what matters in HRM — and it isn’t having wacky workflows, arcane business rules, or impediments to full self service.

What Does This Deal Mean For M&A/Investments/Liquidity Events In Our Industry?

With all the private equity ownership of HRM software and services companies (e.g. StepStone’s announced MBO funded by HgCapital of their talent management software business), sooner or later we’re going to see these owners prepare for their liquidity events. We can hope that all this money, including KKR’s investment in NorthgateArinso, is very patient, but these folks are usually invested for returns rather than because they have a passion for improving the practice of human resource management. So I’ll be keeping a weather eye on the level of ongoing euHReka innovation, on the extent to which NorthgateArinso adds the type of consulting chops that are going to be needed to work with larger/more complex clients, and on the other important area of essential investment in their global HRO business. Ongoing investment means future benefit to their customers and a long term commitment by KKR.

Conclusion

As I tweeted on 3/7/10 right after this deal was announced, I like this deal because it:

puts NorthgateArinso into high end HRO;
gives NorthgateArinso a much faster ramp into North American HRO;
provides NorthgateArinso with a new set of customers for ongoing SAP work;
gives Convergys HRO customers a future upgrade path as their SAP platforms age (and, I should have tweeted, a life after Convergys);
gives NorthgateArinso more possible euHReka work immediately for those customers which would prefer this to native SAP self service; and
gives Convergys customers a very committed and capable new provider.

All in, this is a good deal not only for NorthgateArinso but also for our industry. Well done!

Update/Correction 4/6/2010:

In the discussion above about why Convergys HRO failed, why it needed to be acquired, my third point was that there were fundamental flaws in how Convergys shared responsibilities for the implementation of these mega-clients with Deloitte. It may well be that (1) I ascribed to Deloitte a larger role in the software-intensive aspects of the ERP implementation work than they in fact had, with their actual role being more about process redesign and change management than about ERP implementation or overall program management; (2) the actual implementation work was more directly managed/orchestrated by Convergys and staffed with an array of subcontracted “arms and legs,” some portion of which were from Deloitte; and (3) while Deloitte did make a profit on their work, that work was done on a more fixed price basis with any created IP belonging to Convergys. It has also been pointed out that Deloitte is currently the audit firm for KKR, the private equity firm that owns NorthgateArinso (and now owns Convergys IPO), which subsumes the question of Deloitte’s having any further involvement with this business.

Product Update: Workday 10

You may well wonder why I’m writing about this when Workday’s newest release (yes, those releases are coming three times a year when PeopleSoft releases are coming every 3 years) has already been covered by several of the top enterprise software analysts, including Altimeter’s Ray Wang, InformationWeek’s Doug Henschen and Strativa’s Frank Scavo, and many more have full research notes in preparation. I’ll defer to my colleagues and their detailed debriefings on what’s new in Workday 10, but there are a few less frequently discussed points about Workday in general and this release specifically that I’l like to mention.

First, when you subscribe Workday’s HCM product, at whatever that subscription costs monthly, you get ALL the HCM functionality, to include ALL the new talent management functionality in Workday 10. I’m going to repeat this for absolute clarity. There are no separate talent management modules to subscribe, and your subscription pricing doesn’t change just because Workday keeps releasing, three times per year, lots of relevant new talent management functionality. I suppose a customer’s pricing might change when their agreed subscription period is up for renewal, but that’s an issue to be addressed by your clever contracts people during the sales cycle. With a lot of core talent management (so not talent acquisition nor learning) now delivered in 10, and an announced roadmap, through two more 2010 releases and beyond, that’s packed with more core talent management functionality, this is a substantial advantage for Workday customers.

Second, not only is there no additional charge to Workday’s HCM customers for all of the new (and more to come) core talent management functionality, but all of this core talent management functionality is totally integrated with their system of record. This saves Workday customers from a lot of otherwise costly, error-prone, and inherently unstable integrations (dare I say interfacing?) across their system of record and talent management modules when those are obtained from different vendors. And for those of you using an ERP/HRMS whose talent management functionality (for which you may well have paid separately, by module) has been built (at least initially) in silos, you know that, even though it all comes from the same vendor, the integration can be less than perfect.

Third, at least within the HRM software industry, Workday is one of only two firms with which I’m familiar that practice models-driven development. Meta4, another global HRMS vendor, is the other, but they don’t yet market their products in the US. With Workday 10’s considerable new functionality across HCM and payroll, not to mention the financial management applications, they appear to be reaping the savings in time, quality and cost to market of this most contemporary approach to software requirements definition, design and development. In models-driven development, the desired system’s conceptual objects, the attributes and methods of those objects, their relationships and behaviors, as well as many other aspects of the business processes under study, are described by business analysts using the formalisms of the selected modeling tools/language. In the case of both Workday and Meta4, they have built their own proprietary tools tailored to the types of business applications that they are building. Where models-driven development makes the leap, is that the models, embedded in these tools, become the applications. Without putting my foot too far down my throat should this be read by some of my Enterprise Irregular or other heavy weight software archtecture/engineering/methodology colleagues, let me just say that I believe Workday’s ability to move from domain models to delivered applications without the usual hand-coding of those applications is a critical part of their “secret sauce.”

Fourth, in addition to their three times a year and everyone’s on the same version big releases, Workday is able to do weekly “patches” to take care of the kinds of smaller needs that arise when you’re rolling out an integrated system of record/talent management suite to global, enterprise-class customers. But those weekly “patches” are also the vehicle for deploying needed changes from the never-ending parade of regulatory and legislative changes, the pace of which has escalated tremendously in the US over the last year or two — and with a lot more to come. Not as glamorous as talent management, HRM legs and regs are enough to put insomiacs to sleep, but they are the heavy lifting that must be done as cheaply and easily as possible or they suck the air out of our efforts to do the more valuable work of HRM. Can you even imagine the systems implications of the recent health care legislation? How many HRMS vendors are wishing they had much more agile ways to develop and deploy the needed changes to their software? Wishing that their software was on firmer foundations to start with before they have to bend/fold/mutilate it to administer all of the new rules? And what about the end-user payroll and benefits staff who are going to be slammed with manual workarounds to compensate for the shortcomings of their HRMS? However, I do think they need a better name for this process because “patch” implies fixes to correct errors whereas this is also the vehicle for adding/changing small amounts of functionality which is localized and easily consumed without formal roll-out or change management.

Summary: More functionality for your current subscription dollars coming every few months. Real integration across your system of record and core talent management (as noted above, Workday does not today do external talent acquisition at the deep level of their newest partner, MrTed, nor do they today do learning management at the deep level of a true LMS). Models-driven development, with all that implies about improved agility, cost, quality and time-to-market. And a solid process for delivering all the legs and regs that regulatory activism at every level of government appears to be generating. Can Workday 10 stand up to all of my “killer” scenarios? Does it deliver on all of my preferred architectural behaviors? Of course not. They don’t call them “killer” for nothing, and there’s not yet a hint of interrogatory configuration (to mention just one preferred behavior) in Workday’s story. But there’s a lot to admire in Workday’s software, and I do.

HRM SaaS InFullBloom vs Everything Else: The Musical!

Since my singing finale to last year’s closing keynote at the HR Technology Conference (if you missed it, you missed it because no YouTube versions have popped up — yet), many colleagues have asked me about my next such performance. And no, the picture (that’s me in the foreground) isn’t from HR Tech but rather from my long ago Cancun club singing phase.

I won’t be the closing act for this year’s conference (although I’ve got some vendor-sponsored events lined up at which my singing may be de riguer), but I have been working on a little musical number that expresses my strong belief that SaaS, when done right (i.e. when InFullBloom) is the future of HRM software — really of all business applications software.

HRM SaaS InFullBloom isn’t merely subscribed and vendor-hosted in a purely multi-tenant deployment; that’s just the table stakes. HRM SaaS InFullBloom (aka Bloomin’ SaaS) incorporates the best of what multi-tenancy, a correct HRM object model, and modern software engineering techniques can enable, including:

full deployment in the cloud so as to reap the maximum economic benefits of that industrial model for IT;
the inheritance of business rules, content, really all types of embedded intelligence across tenants as well as within tenants — and with full capabilities to include 3rd party embedded intelligence for those tenants who have subscribed it while providing the needed metering/billing to ensure that those 3rd parties are paid for the use of their IP;
the aggregation of useful, shareable data within tenants as well as across tenants (obviously with the right permissions and incentives in place), to enable both benchmarking and the sharing of such data as applicant, recruiting source and total compensation plan design;
frequent (at least several times a year), everyone-gets-it functionality enhancement releases (along with those legs & regs) with opt-in by tenant for much of what’s delivered;
configuration available to nearly everything, from business rules and work flows to user experience and valid values and on to every type of embedded intelligence, that expresses the different ways in which organizations design their HRM policies, programs, plans and practices, to include supporting tenant-specific extensions to delivered object attributes and methods;
interrogatory configuration, for the initial implementation, for each new release roll-out, and as individual tenant’s business needs change;
self-provisioning, to the maximum practical extent, which, when combined with interrogatory configuration, takes a huge chunk out of the time and cost, not only of implementations but also of the entire sales to go-live cycle;
models-driven development, which is critical to reducing dramatically the cost and time to deliver new functionality while improving the quality of what’s delivered;
“wrapping” each relevant object with the boolean expression of its applicability (e.g. across all tenants or within a tenant to specific work locations or work units) and then with an outer “wrapper” of full effective-dating — yes, full effective-dating, and that means fully automated retroactive processing as well as prospective, otherwise known as forecasting or simulation, processing;
global treatments (where that’s relevant to the vendor’s target market) of HRM data, processes and regulatory compliance;
global calculation engine (again, where that’s relevant to the vendor’s target market) whose metadata determines whether and how the engine calculates a payroll, calculates leave accruals or does 401K discrimination testing; and
that list goes on.

If you recognize this list, then you’ve gotten wind of my preferred HRM software architectural behaviors “starter kit,” which is part of the IP I license to vendors. Obviously a topic that’s near and dear to my heart and one on which I plan to post extensively, behavior by behavior as well as on the power of specific combinations, in terms of both vendor and customer benefits.

But first, I needed a theme song that expressed my view that, once buyers/end-users have been exposed to Bloomin’ SaaS, they’ll be turning up their noses at everything else. I’m sure you’ll want to learn all the words so that you can join in at the first opportunity, perhaps right back in Cancun. And remember: everything else is the farm; Bloomin’ SaaS is Paree.

http://www.firstworldwar.com/audio/howyagonna.htm

Penned in the wake of American’s entry into World War One, How ‘Ya Gonna Keep ‘Em Down on the Farm? (After They’ve Seen Paree) was written by Joe Young and Sam M. Lewis with music by Walter Donaldson, and was published in 1918. A huge popular success at the time the song was performed by a great many artists in the immediate post-war years. Reproduced below are the lyrics to the song. Use the player above to listen to a version performed by Harry Fay in 1918.

How ‘Ya Gonna Keep ‘Em Down on the Farm
(After They’ve Seen Paree)

Reuben, Reuben, I’ve been thinking
Said his wifey dear
Now that all is peaceful and calm
The boys will soon be back on the farm
Mister Reuben started winking and slowly rubbed his chin
He pulled his chair up close to mother
And he asked her with a grin

Chorus (sung twice after each verse):
How ya gonna keep ’em down on the farm
After they’ve seen Paree’
How ya gonna keep ’em away from Broadway
Jazzin around and paintin’ the town
How ya gonna keep ’em away from harm, that’s a mystery
They’ll never want to see a rake or plow
And who the deuce can parleyvous a cow?
How ya gonna keep ’em down on the farm
After they’ve seen Paree’

Rueben, Rueben, you’re mistaken
Said his wifey dear
Once a farmer, always a jay
And farmers always stick to the hay
Mother Reuben, I’m not fakin
Tho you may think it strange
But wine and women play the mischief
With a boy who’s loose with change

Chorus (sung twice after each verse):
How ya gonna keep ’em down on the farm
After they’ve seen Paree’
How ya gonna keep ’em away from Broadway
Jazzin around and paintin’ the town
How ya gonna keep ’em away from harm, that’s a mystery
Imagine Reuben when he meets his Pa
He’ll kiss his cheek and holler “OO-LA-LA!
How ya gonna keep ’em down on the farm
After they’ve seen Paree’?

About

Post Chronology

InFullBloom Archives

Categories

Selected Publications

Speaking Engagements

Adventures of Bloom & Wallace

Admin

Blogroll