“We need the new system to produce 300 reports.”
“That’s a lot of reports. Why so many?”
“Because that’s the number of reports we have now.”

Almost every BI professional will, at some point in their career, have had a conversation with a client that goes something like that. In most business transformation projects, a common expectation is that reporting will continue to function in the new world in much the same way as it has done in the old world. The reporting delivery system may change, but the reports themselves must look and act just as they do now. And they must be exportable to Excel, of course.

Project managers and other stakeholders may have little interest in challenging this assumption. For them, preserving the layout and content of reports helps to drive the validation exercise of the new system. The business has an existing report from the old system and a near-identical report from the new system. If the data matches up, this goes a long way towards proving that the new system is running correctly and that legacy data conversion has been a success. What’s not to like?

Well, for the end consumers of those reports, the obvious question – following months of requirements workshops, acceptance testing and the general upheaval of change – will be “why did we go through all of that to end up with the same reports we already had?” Because although managers may assume that the safest way to keep their team on side is to keep giving them what they’re familiar with, the reality is that with change comes the expectation of something new – and better. In seeking to avoid risk altogether, the end result will likely be uninspiring.

Secondly, any new reporting system is likely to bring with it new functionality that wasn’t there in the old world. Sophisticated reporting packages like IBM Cognos and SAP BusinessObjects are firm favourites for enterprise-level business transformation projects, but if all they’re made to do is generate canned list reports, end users will remain none the wiser as to the rich potential they now have at their disposal. This is only further exacerbated if they are encouraged by management to continue exporting the new reports to Excel.

Even disregarding these points, however, the crucial reason why existing business reporting practice should be challenged is that it makes financial sense. Simply put, it pays to be radical in reporting.

Generating three hundred canned reports every day might sound like an extreme example, but it is actually very common in businesses whose operational systems have remained the same for many years. Over that time, new reports get created each time a particular need is identified that cannot be satisfied by an existing report. This is often a symptom of a legacy reporting system that can only produce static reports without any user input. Many of these reports will run off the back of a batch job – indeed, the report data itself may need to be generated by its own batch job. Gradually the report stack grows larger and larger, with each report serving a very narrow purpose. However, each one of those reports has a particular user base who, if asked, will say that they need it in any future system. This is an entirely reasonable position to take: if a report is used in order to help a user fulfill their role, of course they will want that same report to exist in future. But reasonable though it may be, it must nevertheless be challenged.

First of all, it is possible that the report exists only to validate a given system process. If that process no longer exists in the new world, it makes little sense to continue producing a report to validate it. Second, the report may only make sense in the context of the old system. Mainframes are notorious for their batch-like behaviour, and reports are often used to check one batch against another batch. If the new system is online 24/7 with few (if any) batch processes taking place, such validation reports will likely be redundant. In fact, trying to re-create them in a new system whose paradigm is fundamentally different could cause all manner of development headaches, wasting valuable time and resources to produce something of next to no value. Third, the legion-like nature of legacy reports is often caused by the inflexibility of the system that produced them. Modern reporting packages are geared around the concept of user interaction, which means that a single report with a set of prompts can serve many masters. Multiple reports can be consolidated into just one by adding a prompt that allows a user to pick the dimension they want to group the data by.

Through a process of rationalisation, it is possible to cut down the report stack significantly by just taking the time to understand what the report is for, what data it contains and who uses it. The goal of any report should be to answer a question. If you know what that question is, the design of the report and the various use cases will flow naturally. Establishing this at the beginning will lead to fewer reports being needed, thereby reducing time spent on development, testing and user acceptance. What is more, users will be presented with new world reports that are relevant, tailored to their needs and which exhibit new functionality that was previously lacking. This ensures its own reward in terms of ongoing support: as new requirements arise, users will feel empowered to simply request additions or modifications to their existing reports rather than demanding entirely new ones.

It is never easy to challenge existing assumptions, and in this regard reporting is no different to any other business function undergoing transformation. But adopting a radical stance from the beginning will deliver far greater efficiency savings – not only for the initial project but also for the client in the long term.