systematicHR

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.