Designing an HR System with Analytics in Mind
I firmly believe in rolling up my sleeves and getting stuff done regardless of how senior my job title may sound. So, after realizing that my team has spent 8+ hours in meetings trying to align on event reason codes for system design. I decided it was time for me to sit with the file and go through it line by line with them.
I am thrilled I did that because it allowed me to flow between the high-level system architecture and the nuanced data details and event triggers. I was also going cross-eyed and seeing stars by the time we finished with the data sheets 3+ hours later.
I am sharing my train of thought during parts of last night’s conversation in hopes that it will help someone else think about how to design their system to better facilitate data collection and analytical insights in the future. Throughout the whole process last night, my mantra was, “2024 Lydia will thank 2023 Lydia for doing this.”
Employee Type/Class
As an analytics practitioner, how often did you get tripped up by the 3+ data fields in your HRIS that capture a variety of employment classes and types? Here’s how I started breaking down the categorization and data hierarchy last night:
Layer 1 (call it whatever you want; I call it Worker Type in my head): This is where you distinguish how your organization thinks about its worker groups. For example, it can be as simple as Contingent, Employee, and Intern. Sometimes, you might want to add in Seasonal for some extra flare. This is the first layer of data that will determine how you group your employees for future analytics and insights.
Layer 2 (I call this Stuff I Need for Finance in my head; you can call it Employee Type): This is the part where the categorization will determine how the cost of labor is calculated in the system and how the Comp module in the system will be designed at a high level. Usually, it is Salaried, Hourly, and Not Applicable (for your contingent workers), but again, you can get creative here. Just make sure it’s mutually exclusive. This field will drive the difference in how you calculate the cost of labor a few years later when someone from Finance wants a forecast.
Layer 3 (I call this the “what did we agree on and how do we pay you” category; I’ve also seen it being called Work Agreement Type): This is more system flow design and less analytics for most organizations, but this is where I would place the categorization of Exempt, Non-Exempt, etc. to signal to the time tracking and payroll modules later on as to which time-off and time tracking policies to apply to the worker. It can also be helpful with analytics, especially if you do detailed Strategic Workforce Planning and love a good forecast. This classification can help you get precise on how to apply formulas and calculations.
Leave Type / Reason
I have yet to hear an HR person say, “I love designing leaves of absence programs.” That said, it is inevitable that every HR system must account for leave types and reasons. While Leave Types can be as easy as Paid vs. Unpaid, I would always advise to design your system reasons with a little more nuance than that, and here’s why:
Each Leave Type is meant to serve as a system trigger for the workflow that will occur down the line. For example, how your internal policy handles Caregiver Leaves may differ from how it manages Disability Leaves. For that reason, when you set up the Leave Types, you should consult your internal policy first and at least set up the same number of Leave Types as your policy outlines.
Leave administration is typically handled outside of the core HR system. So, Leave Type might be your system’s only opportunity to capture why someone may not be a current active worker, understand how many temporary backfills you might need to forecast for, and engage in position management conversations with people managers when required. Given that, it’s usually better to go into more detail on your Leave Type than just leaving it as Paid and Unpaid.
Termination Reason
This is not an exit survey/interview replacement. You do not need 10+ Resignation reason codes. Your core system is meant to categorize and maintain records for terminations, not help you understand the detailed reasons why someone left. That should have been done during the worker’s time with the organization and not within a single system reason line upon departure.
I understand we all have different feelings about the usefulness of exit surveys and interviews. I’m saying that Termination Reasons in the system are meant to give you a first-level indicator of why someone is no longer with the organization (i.e., did they resign, retire, or go back to school?). Any further analysis of potential reasons and predictors for turnover should be done through other systemic research and analytical means. It should not be squeezed into the Termination Reason area of your system design.
Job Change Activities
Every organization will look at these differently. My advice here is to write down how you would define the following. Sharing my thought process below for perspective:
Data Change: I think of this as your job has not changed, but someone in HR needs to update a piece of information related to your job for record-keeping and tracking purposes (e.g., the name of your business unit, the cost center of your department, etc.)
Job Change: Something about your job has changed, either in scope, role, level, department, etc., and it may or may not come with a total reward change as well
Transfer: you have either changed your employment type (e.g., contingent to employee) or the business unit you work for entirely
Hire vs. Rehire
This is a relatively simple one. Just define what you would consider as a rehire and if that is the event reason that will trigger a continuation of service date calculations or any other system activities. Otherwise, system users might not use the reasons accurately every time, which means someone must fix all the company service date issues down the road, and likely your analytics person will stare at you when you ask them for perspective on whether there is value in creating an alum community for recruiting purposes.