The term “analytics” gets thrown around a bit by WFM vendors as they have solutions that are advertised an a “analytics reporting system” or something similar. Wondering what that means, exactly, and how that is different from the reporting inherent in the vendor’s application? We’re going to take a look at reporting and analytics to do a little compare-and-contrast to help you understand the differences and be able to talk intelligently about them. First off – Let’s give a brief definition of a “report.” I know, you deal with reports everyday and already know what they are, but for the purposes of this discussion, having a definition gives a bit of scope to the discussion.
REPORT – Defined as a prepackaged display of read-only data to the user, either on a screen or on paper.
There are two things important about this definition:
- Data is read-only. If you are viewing data in the application and you can edit it directly where you are, then that’s not a report. That’s a screen for editing data with functionality programmed into it.
- Report can be printed but doesn’t have to be. Obviously paper reports are going to be read-only. But there may be reports that allow the user to drill down into the data to see more detail. As long as it is read-only, it is still a report.
With that in mind, let’s take a look at reports that are inherent in your WFM application (and by that, I mean your Kronos or RedPrairie or Infor or…whatever system). Reports that are delivered inside of the application are, for the most part, detailed in nature. By that, I mean that they are designed to show the detail of individual transactions – something like an employee timecard report or a department schedule report or a payroll summary report (summing up the time records for a period of time and a group of an employees). The latter may sound like something more than a detail report, since it involves summing up data, but the sums are pulling simply from the detail records.
These reports are detail in nature because the databases holding the information are structured for OLTP. That stands for “OnLine Transactional Processing” – a techy way of indicating that the entire system, starting from the database on up, is designed to be fast at handling large numbers of detail transactions, not for high level reporting of large sets of data.
That high level reporting is where “analytics” comes in. OLAP – or “OnLine Analytical Processing” – systems have databases that are structured differently, in a way that lets the application report with large sets of data much more quickly than an OTLP system. If OLAP systems had to handle the processing of large numbers of transactions (like punches), they would struggle and be very slow, just like OLTP systems are when they attempt to provide reports of large data sets.
Each system is designed to do a particular function quickly and efficiently. When you are dealing with the extremely large quantities of transactional data elements (i.e. every WFM system out there!), you don’t get the luxury of having wonderful system performance for both processing and high level reporting – you have to choose one or the other. Vendors intentionally design the core WFM systems deal with the processing of detail transactions efficiently and develop separate analytical systems to report against the large sets of data and manipulate the sets to drive intelligent decision making.
Why does this matter?
When you work with WFM systems, whether during an implementation or supporting it afterwards, reporting is a constant need and, more often than not, a frequent source of frustration. Users complain about reports running slowly, not getting at the data they want, or a litany of other issues. It can be sore point, to say the least.
But while there is no silver bullet that solves every single reporting issue, one very good place to start is making sure that you are going to and utilizing the best system for getting the report out that you need. If you start out in the wrong system, the process of getting the report will be frustrating and the users won’t be happy when you are done. To make data extraction and reporting much more of a positive process, start out by thinking about the nature of the data to be reported and how it has to get from individual transactions to the report. Then identify the right system to begin working with to report the data. Here is a handy & simple guide to help you determine which system is going to best for providing the report you need:
| Reporting Need | System To Use |
| -Transactional detail listing
-Data over short period of time for limited number of employees |
Core WFM System |
| -Large sets of data – with long time periods and/or large numbers of employees
-Data that requires complex calculations, like trending metrics |
WFM Analytics System |
Using this chart as a rule of thumb will help you start off in the right place. And there are, of course, going to be reports that don’t fit neatly into either category. For those situations, work with your WFM experts who understand and know the systems and their capabilities to determine where to go to tackle the extraction of data for the report.
