I came across this quite a few years ago as we started to tinker around with core HR systems needing to integrate with more systems than just payroll and benefits, and as analytics engines started to take off en masse. Back in the first part of the millenium as talent applications started to get a serious look from the industry, the idea was that core HR applications could be the system of record for everything. While some philosophical disputes existed back then (and continue to be pervasive), I think we fairly successfully resolved that core HR should not be the system of record for everything.
The easy stuff is around transactional systems. We would never assume that core HR would be the system of record for things like employee taxes or benefit deductions. It’s unlikely (assuming point solutions) that you’d want anything but the talent systems to be the master of performance and scores since the transactions take place outside of core HR. We’ve pretty much determined that the core transactional system is going to be the system of record for almost all data elements, and I think this is a good thing.
The problem is that early in the day, we had it easy from an integration standpoint. We really didn’t have that many systems, and so you really had core HR data going outbound to payroll and benefits, and you might have had recruiting inbound. There was little doubt that Payroll had the outbound file to the GL and all the other payroll “stuff” like NACHA and taxes. Clearly, integration has gotten a bit more complex over the years. Rather than the obvious choices we had a decade ago, I now get to hear little debates about whether all the data from TM should be sent back so that you can run reports, and so that all data can be interfaced to other areas from core HR. The answer is a big strong “NO!”
There are a couple things at play here. Let’s talk about analytics first. The idea in today’s world is that you’re supposed to have a data warehouse. Sure, this was aspirational for many of you 3-5 years ago, but if you don’t have one today, you’re flat out lagging the adoption curve. A data warehouse usually has this thing called an ETL tool which assumes you are going to bring data into the warehouse environment from many sources. Bringing data into the core HR system and then into the data warehouse is simply counter intuitive. You don’t need to do it. Certainly I have no objection to bringing in small amounts of data that may be meaningful for HR transactions in core HR, but bringing overt data in large quantities is really unnecessary.
Second, let’s talk about integration to other systems. I’ll be the first to admit that if you have SOA up and running, you are ahead of the curve. In fact, if you are in HR, you are at least 2 years of the curve, and maybe 3-5 years ahead of mass adoption. The simple idea remains that integration should continue to grow simpler over time and not require the level of strenuous effort that is took in the past when we managed dozens of flat files. However, I have a philosophical problem with trying to manage integration out of core HR. The fact is simply that you are distributing information which core HR may not own. The management and quality of the data cannot be guaranteed in a non-system of record, and your data owners for the element cannot be expected to manage data quality in 2 separate systems.
The whole idea of core HR as a data hub keeps popping up, and I see the whole discussion as problematic. It stinks from a governance perspective, and it stinks from a technology perspective. Well, now you know where I stand at least.