Real time reporting doesn’t exist

Submitted on: Fri, 04.04.2014 02:03am - Gary Owen |


The concept of “real time” reporting comes up often when we are talking to new prospects. It’s an understandable concern for any reporting solution. With as much time and energy as we’ve spent in the arena of reporting, we’ve developed a pretty deep understanding of real time reporting and how it applies to different kinds of data.

First things first, there is no such thing as real time reporting. It sounds like a bold statement but we all know this intuitively and actually operate as though it is truth. Does your transactional database reach out and modify the piece of paper sitting on your desk after it comes off the printer? Of course not, that’s a silly question. We all presume that a report is only valid for a short window of time after it’s printed.

This same concept is true in a digital realm. When we display a report on our computer screens, it begins to age unless we click the “refresh” option. It isn’t possible to achieve true “real time” reporting unless we extend the transactional boundary surrounding every piece of data put into the database to the reports displayed on screen for every user. The implications for this type of requirement are actually quite staggering. Expanding the transactional boundary means that we will not process an order unless all the reports currently open can be updated with new information immediately. If the report data on a traveling sales rep's iPad wasn’t immediately updated should we not process that sales order? Another silly question, but from a software developer’s perspective a real possibility and something that could be achieved if the needs of the business demand it (hmmm…what if that sales rep was actually stationed on an orbiting space station and the data being updated was their remaining air supply…)

Almost any business user would put the operational needs of the business ahead of reporting needs. Analytic reporting needs shouldn’t supersede the functional day-to-day needs of the business. This often comes up as a performance concern for prospects. They want to know if running reports will slow down their production database. The last thing they want is users running reports to prevent other users from entering orders, printing pick tickets, and entering receivables.

So if there is no such thing as real time reporting, what is the real need behind the request? We believe what they are really looking for is control over the age of their data. Certain data needs to be updated at certain times, varying from monthly, to weekly, daily, hourly, or on-demand. When we hear real time reporting as a requirement, we typically interpret it as a request for on-demand style reporting, which means when I run this report I need to see it with the most recent data. Typically this on-demand request is driven by users that are functioning in operational vs. analytical roles and they are depending on the results of the report to give them a list of action items.

For example, one person might need to run a report of all the past due invoices so they know which customers to call and verify they received their bill. This list needs to be up-to-date as of right now as a large batch of checks was just posted. On the other hand, an executive looking at AR trends might be just fine with seeing that balance as of the end of the day, or week, or by comparing quarterly totals.

An example at the other extreme is inventory turns data. Because inventory turnover is something that changes very slowly over time it is typically only calculated at month-end boundaries. There is little point of updating these numbers more frequently except to catch and reflect back-dated transactions or other adjustments.

What we have learned over the years working with distributors is that different users have different needs for each data set, and that the right tools need to be applied to the right areas at the right time without creating an undue burden on the computer and software systems themselves.