The perils of HR out-sourcing to an IAM solution

Over the years, I’ve been called in a few times when HR and/or payroll functions are being outsourced (or share-serviced, which is much the same thing), and this includes a migration to a new HR platform. Typically I have been brought in far too late in the proceedings when cost-cutting and service-simplification decisions have already been made that have a profound impact on the IAM solution’s potential to function as before. Here are some things to think about if you find yourself in this situation.

It’s not just about attributes

It usually goes like this: I walk in to be presented with a finished “design” that focuses only on attribute mappings. They will have started from a list of all the source attributes the IAM solution is using in the current HR system, and then mapped them to the equivalent attribute in the new HR system. Job done, right?

Er, I have a few questions…

Are they migrating identifying numbers?

Will the ID numbers that the IAM solution uses as primary keys stay the same? Or will they be imported to a different field on the same object type to allow join back?

The types of identifiers I might be concered about are Person number, Organization Unit number, Position number and Location code. Maybe others, depending on the solution. If they’re not migrating the numbers I need a CSV file mapping old to new identifiers, and that’s a mandatory.

Are they migrating all data?

The worst problem I encountered was when a decision had been made to “simplify” (aka “throw away”) perfectly good location data. The original HR system linked position location to the site the person worked at. The receiving HR team didn’t see the point of knowing anything other than a person’s state, which related to public holiday and pay conditions. Unfortunately my IAM system used the site code, in a geographically dispersed organisation, to determine where to create the home folder as part of user provisioning, and by refusing to migrate the locations as before, they completely broke this functionality.

There may also be problems if historical employee data is not migrated, meaning the IAM solution may lose its data source for post-termination actions, and also may be completely unable to recognise a returning employee and so will treat them as a brand new person in the organisation.

What format will the data be in/be maintained in?

If there’s any talk of “data cleansing” before, or as part of, the migration this needs to be checked out – it may just be code for throwing away data you were using, as in the example above.

However it may be the ongoing maintenance you need to worry about – particularly when well-formed data that was limited to pick-lists, or controlled by validation rules in the past, is being migrated to the dreaded “free text” fields. If the IAM solution was relying on these fields there will be trouble ahead, and it might be difficult to detect and unpick.

When will data be available?

There was one time that the person tasked with doing the integration design before I was finally brought in had actually thought about the lifecycle events – ie., what happens before the start date, on the start date, before the termination date etc. That was the exception – in every other case the attribute mapping has been it, and I’ve had to ask questions such as “when will the new employee’s details be available?” and “when do they get marked as active or terminated?”

The worst scenarios are when payroll is the specific goal of the out-sourcing. Payroll will not need a new starter’s details in their system in time for the start date, as long as they’re in there by the first pay date – and this could be up to a few weeks after they actually start work! Nothing kills an IAM solution’s main goal of rapid provisioning worse that this. If this issue can’t be resolved with process change then you may be in a nasty situation of trying to tap into the recruitment system, or allow identities to be created directly in the IAM solution, and then all the ongoing problems with joining to the HR system record when it does eventually show up. Apart from how undesirable this is as an architecture, it would be a much bigger re-design job than “just changing the data source”.

I had an unexpected variation on this one time: we were assured that the person and job details were entered ahead of the start date, and that we should use the “Employee Status” field to determine account status, as had been the practise up until then. What we didn’t find out until well into testing was that this status field didn’t toggle over to “Active” until the start of the day in California, and we’re in Australia! So the new starter’s account wasn’t getting activated until about 3 in the afternoon. I switched to using the start and end date fields and generating my own status value after that.

Similar questions must also be asked about when the termination date will be entered, and the status changed to “Terminated” or similar. If the IAM solution is responsible for any RBAC involving position or job function, then the timing of these changes could be significant too.

Are there environment and access limitations?

Particularly when moving to a commercially hosted platform, there will be limitations on the number of environments offered. I’ve had to struggle with moving from Dev, Test, Training and Prod HR systems on-prem, to having only Production and Training offered by the service provider. This is a complete pain, particularly when you’re doing write-backs to the HR system so it’s not really feasible to have both your Dev and Test solutions sharing the Training HR instance. Invariably unsastisfactory kludges are the result, and the risk of failing to pick up errors in the Dev environment is greatly increased. (Fortunately I have not had a situation where only Production has been agreed on – that would be a disaster.)

The other one I encountered was a service provider saying that there were daily limits on API calls and going over those limits would invite additional charges. As well as having to lengthen data sync times from those the customer had been used to, this also played havoc with dev and test, when you are often doing more data imports and exports than under normal operations. I think in the end the customer managed to negotiate something for the dev/test period, but it was certainly an unexpected additional pain.

Technical Connectivity and API

When I get called in to these jobs the focus is primarily on the technical changes needed in the IAM solution, that’s why they needed me. This will be a whole minefield in it’s own right: there will be completely different API or data exchange methods to understand and integrate with, there may be connectivity issues involving firewall rules and certificates, and then there will be the types of problems listed above, where you figure out something the IAM solution does today just won’t work in the future state and you have to re-design chunks of the solution. And all of it will need complete regression testing.

The question I hate at this point is “how long will it take?” to which the correct answer is “I’ll tell you when I’m done”. Why are people never happy with that? A couple of times it’s because I’ve been brought in literally weeks before the cut-over. Next time that happens I’ll turn around and walk out.

The Cut-Over

At some point there will be a cut over to the new HR system. If you’re lucky the date is flexible, but I’ve experienced the hard and fast date that is not being changed for anything, especially not the concerns around a parasitic IAM solution, and that isn’t fun.

When the cut-over happens you will have to do a final full import from the old HR system, wait until you’re allowed access to the new one (could be days later), then run full imports from the new HR system, sync everything up or run all your rules and reconciliations (depending on the size of the data set this step itself could take hours to days), and then start looking at any unexpected data changes. If at that point you realise the IAM solution is about to strip everyone’s group memberships because all the organizational identifiers have changed, then you’re in a lot of trouble.

Ideally you will have the opportunity to test the cut-over, with real data, before hand – but this can be difficult to arrange. The Test environment should be fully occupied by the tester who is regression testing your changed solution, and that’s very important! If the environment has to be shared between solution testing and cut-over testing then additional time has to be allowed, including rebuilding the test environment between these activities!

One time, I found out that the HR department themselves were doing trial cut-overs and I managed to hook into that. I had a sandpit environment built with VM copies of the current IAM solution and AD, which I could restore back to base whenever I liked. I ran and re-ran the cut-over many times before the (very hard and immovable) date. This saved me when I came down with shingles in the middle of the cut-over period so wasn’t exactly at my best, but had documented my process well enough to just blindly follow.

In summary

This post ended up longer than I thought it would – there really are a lot of factors to consider, often in the face of a general attitude that you’re just “swapping out” a data source, and how hard can that be?

Outsourcing of HR and Payroll functions seems to be pretty popular these days, but the needs of an IAM solution will never be high on the agenda, if they’re even considered at all. At the end of the day we are outside the core functions of HR and paryoll, parasitically hanging off the HR system, leeching data for our automation rules which are only there to benefit IT and why should they care about that…

I continue to hope, probaby in vain, that whoever plans these sorts of changes will consider the bigger picture. If IAM automation has led to cost savings in IT, but you lose those by fundamentally changing something it depends on, then what have you achieved other than shifting a cost burden from one part of the organisation to another?