HRMS Data Gone Bad: the Dark Side of Reporting

HRMS data and reporting are often seen as a key benefits of having an HRMS. We hear of how analytics based upon HRMS data allows for better business decision making. However, what happens when this data doesn’t function as designed? Are there times when you might wish you didn’t have HRMS reporting at all?

One of the key issues with HRMS reporting is when the underlying data is not correct. If HR is not keeping the system up to date, then any reports are merely compiling and highlighting bad data. The end result in such cases is that rather than adding value, reporting becomes a distrusted source. Or even worse, a business decision could be based upon bad data!

Unintended Consequences

A global HRMS environment adds another layer of complexity when it comes to HRMS data and reporting too. Often systems deliver data in a format where it will be imported into Excel for further manipulations. I’ve seen instances of files going back and forth from the US to Europe, with unexpected results. For example, imagine a file of employees with hire dates, as this particular set of employees is celebrating 10 year anniversaries with the company. HR distributes the details to the various managers who celebrate team success stories by announcing these anniversaries within their teams. Except…the anniversary dates are not correct! Dates are formatted differently in the regions, 10/1 is October 1st in the US while it is seen as January 10th in Europe. It’s seen as an embarrassing mistake due to an HRMS data and reporting error.

If HR is not keeping the system up to date, then any reports are merely compiling and highlighting bad data.

HRMS data can sometimes take on a life of its own when those unaccustomed to data handling extract it and forward it on to others. I’ve recently seen a case where an HRMS went down for a few hours, and while data was entered, it was not saved. There was still an audit record however, so the database administrator (DBA) extracted the relevant employee data into a report and sent it to all and sundry, to alert them of the issue. As the DBA was not familiar with the data, he didn’t realize that the users had been informally using certain columns for dual purposes, such as repurposing an unused field to provide comments such as ‘not suitable for rehire’. When the DBA only pulled data based on the column headers, the report suddenly released a lot more data than was originally intended. These examples show the power that HRMS data has and reporting can have, and how their dark sides can have many unintended consequences.