Cloud HR Implementation Tips: Focus on Integration and Migration

PARIS

 Most discussions on implementing a new HR system, which for the past years has meant a cloud-based one, tend to focus on the functional side of things, that is business requirements as covered by a single system. Discussing what processes will be re engineered or moved as-is, what system to evaluate and select or even how to overcome change resistance are often considered as nobler than the nitty-gritty  technical aspects usually referred to as “integration”, although I prefer interface since that is what it is: interfacing to third-party.

In the brave new world of cloud systems, the assumption touted by most vendors has been that the integration conundrum would be solved by the native vendors in a much more satisfactory way than it was in the dinosaur era of traditional ERP. Well, nothing is farther from the truth if only for two simple facts:

1. In my 20-year experience of the HRIS world, I have yet to seen a company (and certainly not a global one) using a single platform for all its HR needs. 

2. From time immemorial HRIS vendors have each had their own data model and despite all the talk about convergence that is still the same basic reality. 

So, how should you go about integration when embarking on a new HRIS project? First you need to realize that there are several tasks/phases that make up implementation activities. This post will focus on the ones mentioned in the title: Integration and Migration. Second, these two tasks tend to be considered as "technical" but the business impact is such that it would be counterproductive for SMEs or the business side of things to relinquish full control

INTEGRATION
Deciding what is in scope and what is out is one of the most challenging issues in any HRIS project. If you overindulge yourself you may bite off more than you can chew, a recipe for disaster. But leaving too much out (Recruiting*, Payroll, Time Management*) means interfacing to all these different systems and that's where the big headache starts: How to make different systems with different data models talk to each other in a meaningful way?

Particularly vexing is the situation faced by many companies  which have never had a single global HR system of record and whose users realize that moving to the cloud means having, at least, two systems where they previously had one: the old single HR-cum-payroll system now becomes a modern, cloud-based HR system interfaced to payroll. Where I used to create my positions, hire employees, define their compensation, and produce their payrolls in one tool, now  I have to do it using two user experiences. Toggling back and forth between two tools may be considered by many as a step back.

To ensure user adoption and minimize risk, pay particular attention to the following:

• What data to move to the new HR tool and what should remain in the legacy tool (see the below table for help on deciding which is which)? You can decide that structural data (organizations and jobs/positions) stay where they are, but employee data are moved to the new tool: analyze the pros and cons of each carefully. Particularly wrenching is when the new system offers some data or feature that your local tools cannot accommodate and in order not to break down what has worked fine for so long, you have to let go of a feature you were hoping to use (and loved in the demo when you evaluated vendors.)
  
  
  
  
  
• What direction should the flow go? Is your new tool going to be the master for all things HR? Will some data be updated in the legacy tool and fed back into the HR system of record? Will some process flow change directions over the course of the project? That could be useful to minimize risk but it is bound to add to complexity.
  
• What am I to do if my legacy, local tool is better at some feature than the new one? For instance, in my local tool, in the Address section, I have a City field with a picklist (often the result of heavy customization) , but the new tool doesn't offer a list of values to choose from (welcome to the wonderful SaaS world!) If a user misspells a city name or use a local one (say, Köln instead of Cologne) the downstream  system won't recognize it and will throw in an error: no address means no employee. And if this employee is a manager all the workflows that require his or her approvals will be stuck. The business impact of such a situation can be quite serious.
  
• How often do you expect to send data via the interface?  Once a day? Several times a day? Once a week? This is hardly an academic issue. If you update your employee data several times a day, you may want to just send the most recent file. Some interfacing tools allow you to send just what has changed (the "delta" file in our jargon), while others will send the whole file. 
  
• A far from unimportant question is whether you will interface straight from the new system to the legacy tool or whether you will go through a third tool in between. I have worked on several SAP-to-cloud conversion projects and often the customer would rather retain a mini HR master that would be fed from the new HRIS and, in turn, would feed the downstream system (both HR or non HR such as finance or expenses.) The advantage of such a scheme is to lower the risk and the interface complexity since you focus only on one type of interfaces and don't have to rebuild all the other "pipes."
  

MIGRATION
Since I'm writing this piece having dummies in mind, I may be stating the obvious for many but I am still surprised at how many people confuse the two terms and activities. Although the two may overlap they are fundamentally different: both relate to sending data from one tool to the other, but they do it at different phases of the project: Migration is about loading data before you go live (it is therefore a one-off exercize) whereas Integration sends data on a constant basis after Go Live.  

As with Integration, some major decisions have to be made, carefully weighing thepros and cons of each:

• The first one is about history: I have spent countless hours/days/meetings with stakeholders to analyse and explain history decisions: Many users, loath to leave their comfort zone, expect to get in the new systems all the contracts an employee has ever had, all the jobs he's ever held etc. Technically it can be done, but it is complex and expensive, so you have to explain to them that the costs far outweigh the benefits, and that it is better to just load active employees and the most current job, or at least not going back more than a year. But, again, analyze your business carefully: if your business has high seasonal turnover, and the regulatory environment in the country/ies you operate in, require you guarantee that full seniority is maintained, then you may have to load terminated employees as well.
  
• A key aspect is the source of the data: If you already have a global HR system of record (think Oracle or SAP) much of your data will most likely be stored in that legacy system (although not for all your countries, some smaller ones may be outside.)  The good news is data conversion from one tool to another is much easier to do than from multiple sources. The bad news is that in reality SAP and Oracle (both EBS and PeopleSoft) are ancient technologies, and often do not hold a lot of local data: For instance, they may hold your permanent employees, but temporary employees are managed in the local tools. You will then have to migrate them from these ones: multiple tools means added complexity, cost, energy and ...time, that commodity so precious in any global HR system project. Hard decisions to make here, based on the real (not perceived) value of having, say, banking details in one single global system or in local ones: if your employees are used to self service then the former makes sense; if HR will continue to update it directly, then it can remain in the  local tool.
  
• A key part of the Migration exercize is to validate that the data has traveled safely, hence the importance of checking it. Remember GIGO? Garbage In, Garbage Out? If your data is w in the source system, it is highly unlikely it will arrive cleaned in  the target tool. Do yourself a favor and clean up your data in your upstream tool.
  
• I have written a lot on system evaluation, and this is where bad decisions made at that phase will impact your implementation: If you have been negligent or ignorant about your business, and not realized how much historical data you will need,  you may be in for a big surprise when you reach out to your vendor (systems integrator) and are hit with the additional costs of a change request. So, as in anything else in life, the earlier you think about all possible options, the better it would be. Of course, many customers make the buying decision with scant regard to implementation and  live to  be sorry at their shortsightedness.

As you can see from the above examples, the impact of misguided integration and migration decisions can hamstring your business quite significantly. Undervalue these twin sisters at your own peril. To paraphrase a well-know expression, Integration and Migration are too serious issues to be left to IT: HR, as the face of the business, should own it and pay particular attention to it in order to maximize chances of success. 

*The blogger positively hates the New Age terms of Talent Acquisition and Workforce Management

**The blogger, in his Advisor/Consultant/Project Managercapacity, is currently busy with the post-design phase of one of the largest Workday projects in the world for which he has been clocking in an impressive amount of frequent-flyer miles.