The intersection between HR strategy and HR technology

systematicHR Avatar

I love talking about and manipulating data.  One of my favorite moments of the month is when I get together with one of the premier data people in HR and we just talk data for 30 minutes just for kicks.  It’s fun talking data with someone who gets data, but often, we’re not really doing that.  The number of really high quality data people in HR seems to be rather low.  In fact, it’s really quite problematic that we can’t find enough people to fun our analytics engines that have a great depth in HR functionality and an understanding of how analytics works.  I was working with a Fortune 100 company very recently where their top HR analytics person globally did not have any real idea how a data warehouse worked.  Unfortunately, we seem to have started pulling in the best we have, which means a functionally good person, but not technically.  I have seen some organizations start pulling in great data people from outside of HR, but they are obviously hampered by their lack of functional understanding.

When we talk about analytics and a super-user, it’s nice if we can assume there is a good grounding in HR.  If we also think about how a data warehouse works, I think we can simplify analytics core capabilities in 3 easy concepts that I’ll call  trending, drilling and slicing.  These are all based on a data mart or what is also called a star schema.  I won’t go into the technical details, but it enables the trending, drilling and slicing that sets OLAP analytics apart from operational reporting.  Here’s a quick and simple primer of how the technology can be used in functional terms.

  1. Trending:  Time is pretty much a standard dimension in the fact/dimension schema in a data mart.  Trending is the simplest concept and it simply allows the ability to easily look backwards in time whether it’s in daily, weekly, monthly, quarterly, or annual chunks.  Theoretically, you should even be able to take a graph report that is has an annualized trend and click on any year to see the representative quarters or months within that year.  But that’s part of the next concept, drilling.
  2. Drilling: Drilling can really be done for any dimension represented in the schema.  You can take the example above where we drill into smaller and smaller chunks of time, but the most commonly used form of drilling is through the organizational model.  Let’s say you’re looking at a simple turnover report by division – you should be able to click on any division and see the layer below (say regions), and then click any of those and see the next layer of departments.  You could even drill based on the people manager hierarchy if that works better.  Either way, drilling means the ability to simply reveal a lower (or higher) level of detail.
  3. Slicing: The ability to cut data based on ad hoc parameters is also one of the wonderful things about OLPA analytics.  Let’s say you’re looking at that same turnover report and you find that one particular division has a particularly high turnover rate.  In order to diagnose what is going on, you decide to run several slices of turnover within that division.  The first is turnover by job, second by average hours of training by employee, third by compa-ratio, and lastly by engagement scores.  Being able to easily view your data by slicing data with alternative data views is what allows us to be smart – it lets us diagnose, but you can also see the applications for decision support.  In a similar vein, lets say you wanted to know what the contributors of low turnover are, you could simply run the same analysis backwards.

You can see the problem with analytics.  The number of HR people that can translate data from a technical standpoint and understand HR functionally are actually pretty few.  However, we are getting to the point where vendors are automatically bundling in great analytics tools with their applications or where our enterprises are getting around to implementing data warehouse solutions for HR (now that they are done with finance and operations).  The problem is that we’ve always been functional and we have not necessarily invested in creating the capability we will need to be powerful decision support contributors.  If you don’t have the tools now, you’re going to have them very soon – don’t assume the tools will do it all for you – you still need the right people.

systematicHR Avatar

4 responses to “Trend, Drill, Slice”

  1. […] This post was mentioned on Twitter by William Tincup and Bret Starr, Wes Wu. Wes Wu said: Trend, Drill, Slice: I love talking about and manipulating data.  One of my favorite moments of the month is whe… […]

  2. Naomi Bloom Avatar

    Wes, I totally agree about needing people with the right KSAOCs to make use of analytics tools, let along to decide what analytics, especially predictive analytics, are important. And these KSAOCs are in very short supply among those with HRM domain expertise. But I’m a little surprised that you didn’t mention, from a technology perspective, the huge change in analytics approach effected by in-memory production databases. When done right, i.e. architected from scratch to rely on in-memory rather than having it done as an afterthought, not only is it possible to calculate predictive and other types of analytics quickly enough to embed them, point of sale, in the decision-making event flow but it’s also possible to eliminate entirely the concepts of data marts and warehouses. As for trending, drilling and slicing, it’s all done as a byproduct of the business process that the user is trying to execute as long as — and here’s the catch — the business analyst setting up the application was smart/knowledgeable enough to know what analytics to configure and then embed and where to embed them. I wish I had been smart enough myself to have added your KSAOC thoughts above to my post on this topic

  3. Andrew Marritt Avatar
    Andrew Marritt


    Wonderful and very perceptive post. I would add less emphasis to the database technology side of things (though of course understanding the data is a critical aspect) and add usability / data communication as a core skill.

    The more pressing concern that you raised is the lack of skills within HR. I think there are several underlying issues: that good analysts aren’t attracted to HR where there is little real career path for folk who want to stay technical, secondly there is almost a badge of honour about not understanding data in some quarters which results in an increased emphasis on intuition.

    Of all the skills that good analysts need I think the hardest to train is an affinity with data, how to manipulate and transform it in valid ways. I think I’m right in noting that you and I both come from an economics background and I certainly find the econometric training a great grounding. I think if you understand the data you can start to see the necessary models of the underlying system. HR data like much economic data is observational and ‘dirty’.

    If I was hiring an analyst I would be looking first for advanced statistics or econometrics skills first. As we move towards forecasting and prediction we start to extend the model from the one you discuss to extensions where solid statistical techniques are needed.

  4. […] HR FEBRUARY 23, 2011 Trend, Drill, Slice If we also think about how a data warehouse works, I think we can simplify analytics core […]