We talk an awful lot in HR about Analytics and Reporting. Whilst Analytics is of course the trend and the way things are headed, it is important to remember that many organisations are still getting to grips with running basic reports. This is the precise reason I write this blog, to provide confidence to HR Professionals who are getting to grips with the basics and to remind us that we have to start somewhere.
So do not fear if you’re not using the latest Einstein technology for predictive analytics, or if you don’t know your “objects” from your “fields” as here we look at taking that first step in gathering your data to assess where you are as an organisation.
Object Driven Reporting or Custom Reports… what’s the difference?
Broadly speaking, there are two options in report writing. Object Driven Reporting uses a tool (for example Business Objects, Cognos…) where a list of “objects” are defined within a Universe on which they sit. In that Universe are dimensions (fields) that you can pull into a report. The Universe is therefore the place that and links objects and fields and draws them out into a report.
Sometimes a field might not exist in the universe which can be frustrating when writing a report. The field exists in the system and the data model – but it cannot be taken out. In this case there are tools available which let you create the fields putting the SQL code in behind it to pull the object out. You can also change the names of the objects and override the universe should you wish to; however if you edit a report you sometimes have to recreate the SQL code. A tip here is to never underestimate the time it takes when asking a report writer “to just add in another field” as this could take much longer than you anticipate.
Another type of reporting is SSRS/SQL services reporting, or jasper or power BI. Your system is a database that stores data on tables; and these tools find the data based on the specific SQL language to query the results. To do this you need to know SQL and you’d need to decide how important that report is – because if you don’t know SQL you will have to invest in someone (probably IT or an external consultant) to get the data to build the report. In larger organisations, someone in IT would normally have that skill so you can always ask them: but you will need to tell them the fields and the calculations. IT can will go into the data model or data dictionary to pick out the fields but another barrier is IT are not HR and might not understand HR language. A good example is the HR person might want the start date of the “last absence” and it might include holidays – so you need to be crystal clear about exactly what you are asking for. My belief is that HR and IT should be able to work in collaboration but there is a clear language barrier which must be overcome to understand one another.
What Reporting Option should I go for?
Most HR Systems come with an option to be hosted by the vendor: where multiple customers will have their system on the same server. This causes an issue if you want to access the back end of your system to use SQL as it doesn’t sit on your server and is on a shared cluster, meaning that Object driven reporting is better as the vendor will manage those connections. A limitation however is that visuals aren’t as nice, and you can’t suck the data out regularly and feed it in your active directory. So from an IT perspective it is often preferred to be hosted so you don’t have to manager the IT infrastructure in house, but in doing that you can’t always access your data through the database.
If you’re a hosted customer using Object driven reports but you wish to do fancy things with your data using SQL an option would be to use a big broad Object driven report to pull out all of the data and then put it into a data warehouse system; from there that you can then use Power BI and SQL on that data, but make sure that the Object driven report feeds the warehouse regularly to ensure accuracy.
What is a Data Model?
The data model is accessible by whoever in your organisation has access to the Service Desk and it will be provided at implementation. The data model should be a live document and if you contact your supplier they should give you access to the model as customers. Beware that table names aren’t always obvious so it takes time digging around to find what the fields are when looking for Objects.
What reports should I be running?
People often ask me what reports they should be running. I say you should split this into two:
Firstly, operational reports to support with delivery of the HR/Payroll function and any reports you can use like payroll changes for checking or data quality reports to see that things have been entered correctly.
Secondly, you should look from an organisation wide perspective depending on what your Performance Indicators are to be running traditional reports, like headcount, turnover, absence rates in areas, spending reports and so on. Our advice is to then layer that data over each other so you can see in one function you might have got a pocket where there is a high volume of sickness, high OT and some grievances; you could conclude then that this is an “unhappy” area. This is a manual operation but does do the job. Another option is to look at the performance of the organisation through layered data: taking performance data, like production per hour layered over your employee survey for example. You might have a team saying they are all happy where there are lots of grievances, so you know that there is something clearly at odds!
The first step when thinking about reports is to people performance information: all about the people. So how well do we recruit, how well do we retain and are people happy at work. I think that before you worry about analytics or predictive analytics, see where your people are at using layered reporting. Most organisations I meet aren’t doing this yet, let alone using real analytics.
Should HR reporting sit in HR?
Tough question…. I think this depends on the level of competency. Be honest about where you are and think about whether you understand the database and the language. If you do then absolutely in HR! Or consider if you would like to learn this. If you don’t have that support or do want SQL then I feel this is more for IT but recommend you have a very clear process of defining what you want the report to do, look like and calculate. You must give IT the chance of getting it right as they aren’t mind readers and again there are language barriers and the terminology in the system! There is nothing more frustrating for Report Writers than having a report “tweaked” when it has been built.
Sometimes of course it is a simple job but as I mentioned previously adding that extra field could take about an hour or more to do considering the calculation. Be clear from the outset of what you are trying to achieve from the report. Tell the report writer the questions that you want answering to open dialogue and between you, so the writer can work out what you are trying to achieve rather than saying “ I want this field and that field” and so on. Again working in collaboration is imperative to make sure you in HR get what you want, and the report writer provides the service to you that he/she wants to. Work backwards from your outcome to figure out together what the report will need to look like.
This blog was written by Louise Johnston, Customer Success Manager at Phase 3.
