There are many good surprises in life, but being surprised by the results of your new business intelligence (BI) application is not one of them. No one is happy when new reports don't deliver the results the business users were expecting. After one of these unpleasant surprises, an IT group typically revisits the report with the business users and discovers that something was forgotten in the business requirements and specifications phase - most likely a business transformation or a piece of data. Forgotten business transformations may include filters, conditional processing or business rules applied to the data to produce the correct results.

Ouch! The IT group is frustrated because the business users neglected to tell them about these items. The business users are frustrated because they think IT messed up.

How did the business users omit a crucial part of the analytical process that produces their reports? Business users often do not remember some of the mundane or repetitive tasks that they perform in order to complete their analysis, such as a macro they wrote a long time ago. Or, a power user may have set up the reporting or analysis workflow for the business users and never knew what was going on under the covers.

It is the kind of mistake that should never happen more than once, but unfortunately, it does. A BI project encounters unexpected or forgotten requirements after the developers loaded the production data, assumed the reports were completed and were about to go live. In the worst cases, the gaps appear after the BI application has already gone live.

Regardless of who is at fault, unbudgeted time must be spent correcting the problems and restoring the business users' lost faith in the BI applications. This is a costly and embarrassing situation that IT needs to plan for in every project involving business users' analytical processing and reporting.

Don't be Fooled Again

How do you avoid these surprises? Conventional wisdom is to work closely with the business users to gather requirements, document specifications, develop the reports iteratively, conduct user acceptance testing and have a sign-off during systems testing. But following these steps won't eliminate all the unpleasant surprises. You need to add two arrows to your development quiver: data profiling and analytical profiling.

With data profiling you examine the state of your source system data to assess its quality, integrity and consistency. It ensures your data integration works properly and avoids most nasty data surprises. Data profiling tools are available to automate the process. (See my column in the January 2006 issue of DM Review for more on data profiling.)

In addition to examining the data, you've got to examine the processes. This is where analytical profiling comes into play. Analytical profiling is the methodology used to examine the business users' process in reporting and analyzing data. The business users' process needs to include the entire workflow of gathering, transforming, reporting and analyzing data.

Unlike data profiling, there is no push-button tool to do this analysis for you. Fire up your brain and make room in your calendar. In order to understand analytical processes, developers need to roll up their sleeves and reverse-engineer the business users' analytical process. You're probably not going to get the details by merely talking to business users; you need to actually step through the workflow that they use to develop reports and perform their business analysis with them.

Assume nothing. During this investigation you need to question each step that the business user takes and ask what data is used and how it is manipulated. You need to examine all the files and tables used in these steps. When looking at Microsoft Excel files or Microsoft Access tables, for example, look for all the macros and processes that are invoked to generate the numbers. Ask the user what business rules these steps represent.

New and Improved

Replacing existing reports or analytics with a new application that has better data and a defined process doesn't guarantee that it will actually improve upon what the user has today. Always remember that it doesn't matter if it is better from an IT perspective; it must obviously be different and better from the business users' perspective. Assuming that nothing was forgotten in the analytical process, your new number may be more correct, but if the business user has been successfully running the business with old data, the burden of proof is on the new BI application, not the existing report.

Business requirements and specifications may look great on paper, but they won't make the user happy; only the correct analytics will. Do yourself and your business users a favor by performing analytical profiling. Walk in your business users' shoes and actually work with them in their analysis workflow. It is a worthwhile investment and will help avoid unpleasant surprises.


Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access