Reports and online views are organized presentation of information for ready comprehension and decision making. They form a major part of usable outputs of IT systems as the basis for managing the operations in an enterprise. Yet, these outputs taken as a whole or individually are not subject to any kind of design rigor, except for their formats! Targeting this concern, this and a following blog introduce some basic concepts and build simple practices towards optimally designing this system of outputs.
Today, reports are now viewable online and views are printable offline. Dashboards are a special kind of views that use graphic metaphors instead of rows and columns. The discussion here refers to reports and is equally applicable to other forms of ouputs. And the principles and practices outlined apply to reports that are planned ground up and developed for use and not to those reports that are designed and retrieved totally on-the-fly with a query-report engine or an analytics engine.
These ‘canned’ reports build up to a sizeable number in any application and have an abiding tendency to multiply weed-like much beyond the original plans. One only has to look at any ERP roll-out to see it in real, though this dangerous ‘disease’ is not limited to ERP solutions alone. Why is it a ‘disease’ and dangerous at that? Multiply the number of reports by number of recipient users and total them up to get total number of instances of these reports perused. Now multiply the number of instances of perused reports by 10 minutes (or some other number, less or more) which could be the average time any user spends with a report instance. This is the (crudely estimated) amount of time, possibly of the senior management, soaked up by these reports. Individually may not be very significant, but could collectively be quite substantial. In fact, it is simple to paralyze an organization without setting off alarms in any quarters – all that needs to be done is to ‘helpfully’ over-provision users in different parts of the organization with any number of reports!
The obvious remedy, common sense tells us, is to strongly question the need for any report and remove the redundancies. Before we look at the remedy more closely, let us look at what are these reports like and what are they generally used for:
a) Dump or Log or Scroll reports: these are records of every transaction processed by the application. There may be additional records showing the trail of events before and after the transactions. These reports are mainly used for statutory reasons, audit purposes, as historical archive and, sometimes, for information recovery (When the primary purpose is information recovery, the Dump may not be human-readable and is usually processed by a system utility. It is no longer considered as a report).
b) Transaction Reports: these are reports of transactions filtered by some selection criteria, sorted, summed up and formatted. Prior period data may be included for comparison. These reports are of informative kind: which product sold how much in which region, which parts were supplied by a vendor, which orders were processed by a machine shop, etc. A drill-down facility may be available to track down the details of a transaction across functional silos. Usually these reports do not process the data beyond reporting them as such, except for some totaling or calculating percentages. Useful for managers to monitor operations under their supervision.
c) Summary Reports: these reports abstract out the transactions and focus more on various kinds of summaries of transactions. Of course, the drill-down may show underlying transactions. These reports are used by senior managers to monitor the performance of their areas of operation at an aggregate level. Dashboards could be placed under this type.
d) Processing Reports: these reports, as the name implies, may include significant amount of processing on underlying data. This processing is distinct from merely crunching the data for presentation by way of charts and graphs. Senior managers may use these reports to look at scenarios that are not intrinsically modeled in the enterprise applications. A typical example is to pull out raw data and apply some adjustment rules and produce final adjusted numbers. The downside to these reports is the danger of mixing up processing with presentation. In this way, processing is fragmented and is not standard across reports, leading to problems of reconciling different reports that work on the same data. For example, two reports on resource utilization may differ depending on how they process the utilization data. One may round off to nearest weeks and the other may process the data as is, in terms of days, without any round-off.
Often in ERP rollouts, loading good amount of processing logic into reports is a common practice, fearing the formidable alternative of customizing the ERP.
It is another matter that when the enterprise model is complex as with ERP solutions, reports (not limited to processing reports) may differ simply on where they pull their data from (ignoring for a moment differences in processing the data as mentioned above) and enormous efforts are wasted on reconciling the different reports. Going back to the example of reporting on utilization of human resources, the report pulling data from the HR function would not easily match with the report pulling data from the Projects function.
e) Exception Reports: these reports, different from alerts, draw the attention of operating personnel and managers especially to deviations from the established operating norms. It is easy to envisage exception reports in every aspect of operations. Example: A report recommending replenishment of specific stock items.
And some of them are not directly related to the operations. For instance, exception reporting is very effective in spotlighting data validation and integrity errors for subsequent data correction. Security aspects like attempted security breaches are usually reported as exceptions.
The above taxonomy of reports is sufficient for the purpose of discussion here even if it is not all-inclusive. The report types are not mutually exclusive. A report on ageing of customer’s pending bill payments could be first considered as an exception report in as far as it is highlighting abnormal situation for follow-up. It may also qualify as a Summary Report. The function overrides the form.
Reports usually push for some organizational responses. Transaction and Summary Reports focus on performance of one or more entities and their interplay and provide the basis for some broad-based follow-up actions. Exception Reports provoke pointed actions to handle specific deviations. Dump Reports do not trigger any immediate response.
With this background, we are ready to go back to the ‘disease’ and the common-sense remedy we talked about earlier.
At this point, it is more interesting to look at reports or views, taken as a whole or individually, in an enlarged perspective of how aligned they are to the business and not merely for the purposes of curbing the excesses. The impact of closely aligning the outputs to the needs of the business would be positively beneficial, given that the organization depends mainly on these reports and views for life-signs and to manage its head to tail.
As mentioned at the outset, surprisingly, from a software engineering (or is it information engineering?) perspective, this important piece of an organization’s information systems has not been subject to much design rigor, formal or otherwise to optimally arrange for business alignment.
Will set off on this un-rutted path in a soon-to-be blog.