systematicHR

The intersection between HR strategy and HR technology

, , ,

Core HR is not a Hub

systematicHR Avatar

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.

systematicHR Avatar

5 responses to “Core HR is not a Hub”

  1. […] This post was mentioned on Twitter by William Tincup, Wes Wu. Wes Wu said: Core HR is not a Hub: I came across this quite a few years ago as we started to tinker around with core HR syste… http://bit.ly/hFGn1N […]

  2. […] Core HR is not a Hub Systematic HR Wednesday, February 9, 2011 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.  Let’s talk about analytics first.  The easy stuff is around transactional systems.  You don’t need to do it.  READ MORE […]

  3. Michael Krupa Avatar

    How do you define the Core HR system? What is your definition of an integrated HCM system that tracks HR, Comp, Benefits and Payroll? What if your integrated HCM system also handles Performance, Salary Planning and Recruiting? I have an in-house developed Manager Self Service application that feeds transactions to my “Core HR” system. I have a SaaS based salary planning system that feeds transactions to my “Core HR” system. I also have an HR Data Warehouse. I can’t imagine having to develop, test and support ETL programs from 3 separate data sources when all that data is in my core HR system. From my perspective, there are absolutely no cost benefit advantages to developing, testing and supporting three ETL data sources versus one data source when the data is available in my core HR system.

  4. systematicHR Avatar

    Michael, I think that’s quite a fair comment. My question back to you, is to what degree you lock down data in your core HR system if that data is not the system of record? What I often find is that even the companies with the most mature data management programs don’t necessarily have strict enforcement when it comes to updating data in core HR that core HR does not own.

    IMHO, the best theoretical model is one where you get the data from its source. I’ll concede that the best theoretical model is not the best practical model in all cases given resource and time constraints.

  5. Michael Krupa Avatar

    Great question and the answer is probably too complicated for a blog comment. However I can say that we don’t have the ability to update the same type of data in multiple systems. So if we load data such as performance ratings into our Core HR system, the ratings cannot be updated in the Core HR system. They are for reference, reporting, interfacing only. I’m careful with my cost/benefit solutions but I don’t design solutions that could come back to bite you later either.

    I’m not in disagreement with you on the theoretical model but down in the trenches where time is money, theory and practice don’t always see eye to eye.