The Business Value of Clear SAP BI Requirements
Once upon a time, there was a SAP BW consultant, newly assigned to a Global SAP BW project that was on its 40th country deployment. Like all good stories, this one has an evil villain and a superhero. The villain in this case, turns out to be unclear BI requirements. The superhero turns out to be a crusty, affectionate, curmudgeonly developer. Strangely, for a miserly developer, this curmudgeon was not miserly with words, particularly when it comes to developing BI requirements.
Frugality with Words Does Not Mean Clarity of Requirements
Meaning of Clear SAP BI Requirements
You might wonder what all this has to do with writing clear BI requirements.
I did too, and after giving our superhero the Columbo treatment in hopes of finding out just what the difference is between ‘clear’ requirements and ‘unclear’ requirements really means, our superhero was able to narrow down what he means to the following key characteristics:
- Understandability:
You have a fresh new requirement document in your hand and the developer is looking at it.
The question is, does the developer understand what the written requirement for each column of data means, or does he have to stop and go ask the customer additional questions.
If the developer has additional questions, then the requirement, by definition, is not clear.
The result is additional meetings and conference calls and as a result, development delays while the developer clarifies the requirements so he can simply do his job. Ultimately, this extra effort reduces the value as envisioned in the original business case, because you're incurring extra, unplanned cost. - Choice:
When more than 1 key figure can satisfy the requirement and the business intelligence requirement document does not specify what the correct choice is, then the requirement is not clear.
The developer can guess and usually guess wrong and the error will not be discovered until customer testing.
The result will be project delays and rework. - Build Order:
When there is a requirement to develop certain Key Figures that are dependent upon the existence of other Key Figures, it is necessary to build the independent Key Figures before you can build the dependent Key Figures.
It is most convenient to the developer, and a good engineering practice, hint-hint, to specify the Independent Key Figures in the requirement document before the dependent Key Figures.
A properly ordered SAP BI requirement document will specify the independent key figures first, the restricted key figures second and finally the calculated key figures last. - Variable Order:
All variables need to be fully defined, and variables that must be populated in a specific sequence must be defined. - Dependencies:
All dependencies must be documented.
For example, to arrive at a net sales figure may be a complex task, full of assumptions, and depending on how you model it, your answer may vary.
All the assumptions must be verified prior to development.
For example, if Net Sales is specified as a single Key Figure in the requirement document but during requirement validation the developer discovers that Net Sales is a calculation dependent upon 22 CO-PA variables that must be summed up to derive a Net Sales figure, then you know the requirement document was in error.
You also know that those 22 CO-PA variables must also exist in the BW data flow before you can calculate Net Sales and you also know that Net Sales is a calculated Key Figure that must come late in the requirement document. - Complete Math Formula Definitions:
All mathematical formulas need to be fully documented, along with any assumptions or complex transformations needed to arrive at an answer.
There is a concept called the stubby pencil check - if you can’t do it with a pencil and paper, you probably don’t have it completely defined. - Object Naming:
Have you sat down and detailed the Long Descriptions and Technical Names for all the objects in your report. - Overall Development Model:
The approach taken on the BW project to development is also a factor in determining what is clear enough.
If all your requirements are "White Listed" and require no development effort, then perhaps you can squeeze those 182 reports into that very short 6 week phase.
Introduce just one new development however, and the single release project model will promptly blow up in your face.
What you really now have on your hands are 2 parallel projects going on at the same time (a white listed template roll out project and a full up development project).
If the functional requirements are gathered by a different person or team from the BW development team, there is an unavoidable need to have very detailed specifications.
On smaller projects, where you may have only one developer, you may have much less detail available and far fewer development dollars available to gather requirements.
The SAP rule of thumb is get something in the users hand quickly to get real requirements versus striving for perfectly clear requirements, this implies a multi-release water fall process is needed. - Cost of Clarification:
Whether the Business Intelligence requirement gatherer fully details the requirements or whether the developer details the requirements, either way someone has to detail the requirements.
The real question is who has the skills to detail the requirements so that the developer has no questions and can do his job.
If the direct customer interface cheats on the requirements to get their end of phase completion check mark, then naturally the time burden will fall on the developer.
Keep in mind that clarifying requirements will use developer time and delay the Detailed Design and Development Phase. - Filter Definitions:
Does the requirement document fully specify what variables will appear in the filter popup when the query is ran?
Does the requirement document specify what are required fields and what are optional fields?
Did you define the number of decimal places and the filter sequence order?
If not, the requirement is not clear. - Navigation:
Does the requirement document specify which characteristics will be filter or navigational attributes. - Authorizations:
Do the pop-up select filters include the mandatory authorization relevant objects to limit access to the report data? - Detailed Layout:
Does the requirement document specify what the default report layout should be.
If not, expect costly rework once the customer gets their hands on it and decides that they would like to have a “small” change. - Having agreement between the source system and BW:
One typical requirement is to be able to validate the data in the source system, whether it is SAP or a combination of source systems, with the results in SAP BW.
However, there are many possible reasons why the data might not match, some intentional, (i.e., adding or combining data in the ETL process) and some unintentional, meaning something is wrong. - Naming Conventions:
Does your organization have a detailed object naming convention and does the requirement document follow it. - Requirements Review:
Has your requirement gathering expert sat down with your developer and reviewed the requirement document together?
If this basic practice has not been done, most likely the requirements are not yet clear. - Ask Questions and Have Meetings:
Don’t assume you know what’s going on without actually asking.
Just go ask the developer what he’s doing or hold a periodic meeting and get an update from all sides.
When you don’t ask questions or if you assume too much or don’t talk to everyone, you can’t have a complete picture. Avoid the “everything is fine” to “how can we suddenly be so far behind” awkward moment and just go ask.
Make Life Easier for Everyone with Clear SAP BI Requirements Specifications
If your old curmudgeonly developer is off doing the job right, you might not see anything happening for a week or 2 while he clarifies the requirements.
Rather than running around saying “nothing’s happening. nothing’s happening what are we gonna do” don’t panic, he might actually know a thing or two.
Wait for the magic to happen. Soon huge chunks of code will get dropped in that works correctly the first time out of the gate.
5 minutes of screening at the desk on BWD (Business Warehouse Development System) avoids 2 days of screaming on BWQ (Business Warehouse Quality System) which avoids 5 days of screaming on BWP (Business Warehouse Production).
Bottom Line:
If your approach to BW includes handing off requirements to a developer, and if that developer has to stop work to seek clarification on the requirements in order to actually do the development, then the requirements were not clear enough.
High Quality SAP BI Requirements
If you get the items mentioned in our list above right, you will achieve high quality requirements specifications and possibly get the superhero badge. Do it right long enough and they might call you a curmudgeon too! You might want to start the process by getting our highly acclaimed BW requirements template, FREELY available by clicking the button below
Do you have other techniques you use to develop SAP BW/BI specifications? We would love to hear about them in the comments below.
People Who Read This Also Read:
10 SAP BW Project Estimation Best Practices To Roll Out Today
Define Your SAP Webi Requirements
12 SAP CRM Content Management System Requirements
3 Keys To Effective Dashboard Design
Business Process Requirements Specification Template
