How often does it happen that a new Business Intelligence project is build according to well documented specifications, only for the business user to find out that the result doesn’t meet his needs?
In SAP Business Intelligence projects, this is still quite often the case. Most of the SAP clients are accustomed to working with a waterfall approach, where requirements are written down in detail, before realization start. For business users who are not familiar with the tooling at hand, it is not an easy task to do.
This results in reports which are not using the full potential of the tooling at hand, and reports that do require improvements to be really useful. Often though, due to time and budget restraints, a project leaves no room for making these improvements. Unfortunately, that leaves a product which is not satisfactory and thus less useful for the business users.
A solution to this dilemma of time and budget versus quality in the area of business intelligence, is prototyping. If this is build in the project plan as a deliverable, it will improve the quality of the end result considerable.
A prototype in the sense of a SAP Business Intelligence report is a report which still has some rough edges, but enough features of the end product to show a broader audience. It can be used to show stakeholders the direction the report is taking, so they can add comments are propose changes. Usually, a prototype is built in close cooperation between a business architect with some authority and reporting knowledge and a BI tool developer.
With SAP Business Intelligence the whole dataflow is taken into account, starting at the source system (usually SAP ECC), going through staging and enrichments in the data warehouse (SAP BW) ending up in the data marts (SAP BW). After all this preparation, it can than be used in a report (i.e. Business Objects). Given all this effort, a developer will want to focus in his prototype on the validity of the data. Usually a business users takes this as a given and wants to focus on the information the reports shows. For a developer it is the challenge to balance these priorities.
One of the objections I have heard about prototyping is that it can result in a complete change of a report, so a lot of effort has been wasted. But according to me, a report without use for the business is not worth supporting in a productive environment, so there is no loss.
The second objection regarding prototyping is of course that it can be taken too far. That means the prototyping phase ends when the report is finished. For me as a Business Intelligence project manager that is unacceptable because it means a project is not in control. The solution I always use when this is about to happen is give more management attention to the people working on the prototype. Start building in strict conditions i.e. the number of prototype sessions left. Thus speeding up the process.
In conclusion, based on my experience, it is important to develop reports using prototyping. Be sure to plan enough time for the first reports in a new implementation for prototyping and make sure the lessons learned there are translated into guidelines and development rules for the following reports.
