Using Report Specs for Requirements
Originally posted 7/07
Time and time again BI Consultants are asked to come in and migrate some reports from one tool into Oracle BI. Find out why using a modern BI tool for a simple UI replacement project is akin to hiring a Ninja to trim your hedges.
When a company purchases a new BI/Reporting software platform it is eager to get their existing reports migrated from their legacy reporting or BI tool into the new platform. Well over half of the projects I have worked on are of this sort, usually wanting to migrate a set of pre-existing and defined reports. In some cases the tool is used in conjunction with other tools, but for many smaller companies it becomes the platform of choice and all reporting must be done in the new tool ASAP.
The most common types of conversions we encounter are:
- Cognos and BO migration. Having been very late to the Web world, companies are sold on the power and ease of use of the OBI platform and its Web front end. These projects are generally rather large, as Cognos / BO typically have been in a company for a while and a large quantity of reports have been developed. Not to mention they have the most installed sites.
- Oracle Discoverer. More and more in the Oracle world, migration from Oracle Discoverer is occurring. As Discoverer is not a long term solution for Oracle, if you have it, you should be considering switching to OBI EE right now.
- Excel / Access. The need to migrate from Excel and MS Access to a more user friendly and scalable platform will always be with us. In this scenario, the customer does not have much going in the way of BI and is looking to get on the BI Bus.
Ok, so migrating from the old tool to the new one isn’t a problem, is it? Of course not. But how you approach the migration will determine the value you extract out of it.
The Message of BI
To many people, the terms BI and Reporting are synonymous. Although there are certainly reports as part of BI, BI goes beyond a set of reports. Ad-hoc analysis, alignment with and automation of business processes, use of the computing power to help users make better, faster, more reliable decisions are what BI is striving for. “Invisible BI” is a term that Larry Barbetta (former general manager of nQuire/Siebel Analytics) coined, and is one that I particularly love. The ultimate UI is no UI. Sounds a lot like Jeet Kune Do – the Bruce Lee martial arts “style of no style”.
Focusing on building reports misses out on the other aspects of BI, some of the more powerful and beneficial aspects mentioned above.
Do we need reports? Yes. But we’ve had reports for decades now. People will always need to have their base data to support the summary information they receive. No matter how intelligent your BI system, no matter how much work offloaded to it, human nature will want to verify that the details are there if they are needed. Operational reports are quite useful, as they show lists of things, such as a work queue.
But what about building the more powerful aspects of BI into your system? How can you do that when your design is driven off of 20 old reports that you used for requirements? Reverse engineering a report will result in a portion of a design that supports only that one report, and can not be leveraged for other aspects and functionality. By focusing on providing flexible and reliable access to your information, you will enable much more than a set of static reports.
What are BI requirements? What do we want out of them? In practice, what we want to focus on is process, supporting information, channel and lastly format.
Process – What do your users do as part of their job functions? Where in that process would BI come into play? When they go to the BI tool, what are they looking for? What do they do afterwards once their BI session is done? What is the timeliness of the data as it corresponds to the process? Does the process require an ad-hoc query? Process is the framework for the whole requirements gathering process.
Supporting Information – What information is needed to support those processes? Forgetting about what they currently have, what data and metrics do they need if they really thought long and hard about how to improve the processes for which they are responsible. This gets down to the nitty-gritty data details and definitions.
Channel – How would this supporting information best be integrated into the process? Is a traditional dashboard the best technique, or perhaps an alert or email. Can the process be automated all together to gain significant efficiencies?
Format – When receiving the information, how is it best conveyed? Here is where the reports come in to play, as does visualization and many UI design techniques. But all reports are not equal – less is more when it comes to BI. Can the metrics and reports focus in on the actionable information to eliminate much of the noise in a large report?
Reports for Requirements
By focusing in on just reports, as you can see much is left out.
As a consultant, all too often I have gone into a client that claims to have already completed requirements. Upon reviewing their requirements document, what I find is 80 pages of screenshots of PDFs and Excel XLS. This is not remotely close to what is required from the requirements phase, and we must redo the requirements when the project starts. If you are one of my future clients, please realize that report specs are not adequate to build a BI system, or even a decent reporting system for that matter.
Think about what happens when a project starts with 20 report specs and is successfully delivered. Three weeks later, a user needs a new report for a new customer request or a change in the business. Then what are you going to do for that 21st report? Simply put, you will be stuck. Your solution lasted a whole 3 weeks before being obsolete. Time to revisit the success criteria.
Furthermore, think about the effort involved when there are 800 reports and not 20. The manual effort to reverse engineer a large quantity of reports, with every single one having duplicate information on it, is staggering not only in its sheer size but its gross inefficiencies.
Instead, focus on a good BI requirements gathering process. You’ll end up with more relevant, robust and detailed information all for less work. And you will be able to use those requirements for developing a flexible and scalable system, one where the 21st report is simply an ad-hoc query saved and published into a Dashboard.
A rather obvious thing to watch out for are the differences in various tools. When migrating from one BI tool to a new BI tool, there will most likely be some special chart format or UI widget that the BI tool does not support. That is just the nature of the game.
Care must be taken when communicating with the user community about the new UI and its capabilities. When it comes to dashboards, reports and charts, many times people care too much about the UI – they focus in on the little, often times insignificant things. These small disappointments to a user can build up over time to the point where their view on the project becomes negative, and soon they will start to clamor for ‘doing it the way we’ve always done it’. This is a situation that you do not want to be in.
Every effort should be taken to hammer home the message that the new tool has significant advantages over the old tool(s) – why else would it have been selected? If at all possible, have key users involved in evaluating the BI tool’s UI and helping to see the tradeoffs of missing a chart type vs. other aspects of the platform. Do not dwell on the specific features that it cannot handle.
Finally, during the requirements phase, deflect the conversation away from reports and focus on the data needed to do their jobs. Later during the design phase is an ideal time to being prototyping a new UI with dashboards and reports. Consider the UI design to be ‘here is how we can jointly design a UI that meets your needs based off of the data elements we have defined.” Having them involved in the new reports design, using the new tool, will make them feel that they have been part of the process and that the ultimate solution meets their needs. If it doesn’t perfectly meet their needs, they will better understand why as they were a part of the design.
It’s the Information, Stupid
To run a business, you need to focus on the information, not the format and colors of a report. Sure, conditional formats and charts help convey meaning and highlight certain important items. But focus on the reason why they are going to the BI environment in the first place -the majority of the effort should be on the data definitions and not the layout of the UI. To steal from a Holiday time slogan, “It’s the reason for the season”.
I once had a client who was so concerned about the UI that they hired a UI design firm to design the world’s most perfect UI. Unfortunately, the tool could only support 15% of what they wanted. In the process, the UI specialists created mockups that were pure fantasy and shared them with users, who of course received a very different looking system. Expectation setting is very important, not just in BI but in life in general.
As part of this super-UI, the goal was to get everyone to one of 500 dashboards in 2 clicks. Everyone didn’t need 500 dashboards, but that was ignored. Unfortunately, the metrics in these dashboards were mostly basic counts of cases. This was a clear example of missing the point of BI all together – their dashboards may have saved them 2 clicks, but their manual processes still required hours of rote report viewing per week. There was no intelligence in the metrics whatsoever.
I think if you offer business users the deal of “I’ll save you 4 hours of reporting viewing and manual work per week, but it will cost you 2 extra clicks to get to it”, I think most people would take that offer. In the end, the cover sheet of the TPS reports really isn’t the most important thing.
Furthermore, as we all know, software is replaced every few years. The BI tool you have right now will be gone within 5 years – that’s just the nature of the business.
However, if you focus on your data and build a robust data warehouse, your investment will not be lost when you replace your current tool with a new tool. Remember, the BI tool sits on top of the data warehouse. It is the top of the informational pyramid – perhaps 15% of the effort. If you apply your effort on the tool, that effort will be lost. Additionally, you may have more than one tool that needs good, solid information. Those other tools can also benefit from a shared data warehouse that contains the information it should in a flexible format.
I’ve saved a very different sort of argument for last. Let’s face it, these enterprise wide BI platforms are not cheap. OBI EE I know is not cheap.
But it has tremendous capabilities that go far beyond a pretty UI. If all you are doing is reproducing some reports (what I like to call JBOR: Just a Bunch of Reports), then you have purchased the wrong tool, and spent a lot more money than you should have. Using OBI EE for a simple UI replacement project is akin to hiring a Ninja to trim your hedges. Can a Ninja cut the hedges with his sword? Sure. But you are really missing out on what a Ninja can do for you (I won’t get into it), and you are probably paying an awful lot for it.