09-09-09, the date had its own significance around the globe. But I am late to justify its significance, my bad. But still I found a way to relate it with this blog of mine. It highlights ‘09’ BI-significant execution steps that according to me can bring up a comprehensive feasibility study by a Functional/Techno-Functional member of the team.
My previous (first) blog was on ‘Requirement Gathering process for SAP BI/BW Implementation’. To continue, I would like to share critical information based the functional assignments I got involved with. I would make a fare assumption that the initial (multiple) discussions for requirements gathering are complete with the end users/client functional team.
01 of 09: Read the End User's mind & ‘If I wear (in) Management shoes'
Derive inferences from the requirement gathering discussions and try to understand what end-users are actually doing and what the management expects them to do. How effectively you can reduce the amount of effort/time of the end-user and how efficiently the information provided by end-users can be used by the management team. Middle-management/Power users can be the best target for providing ‘analytical' aspects of the information provided.
02 of 09: Be documentation-ready
Detailed and efficient documentation helps us jump to decisions/ideas quickly. This may include BI Reporting format. Reporting format should include KeyFigures, Characteristics, Free Characteristics, Input variables, Variable types (multiple values, mandatory/optional, etc.), Arithmetic calculations (if any) for the KeyFigures, Assumptions (if any) for the report, Global restrictions, restrictions on characteristics, etc. This should give you an exact (mock) report that would like after your developments are complete. Other documentation that may include are documents for logic, information flow, requirements document/functional specs.
03 of 09: Search the Standard library ‘smartly’
BI & ECC provides a huge standard content library which can be readily used with/without minor modifications. Yes, there are scenarios/requirements where a lot of (custom) development is required since companies carry out business differently. In spite of those, BI has a smart content which allows us to extract ‘basic’, ‘very crucial’ data with their standard datasources. Imagine if Inventory were to be custom developed! Also, with BI InfoCubes, DSOs, queries minor modifications to these will allow us cut development time and facilitate faster delivery. One thing to note here is that it helps focusing on what it (datasources) brings, since field names (from R/3 tables and datasources ) may differ, but functionally it may serve your requirement purpose.
04 of 09: Element Dictionary
Once the search for Standard Content is complete, we can summarize everything in a document showing fields as per the BI Reporting format (fields gathered from requirement), fields from standard content datasources, calculations/logic involved (if any), master/transaction data indicator, fields from custom extractor, etc. This will give a complete picture for the BI Data Modeling that we will paper-design in the next step.
05 of 09: BI Data Modeling (Paper-Design)
Things should never go directly to the execution team, if this step is not performed with utmost concern. It is best & most crucial pit-stop where Technical Team & Functional Team will be discuss in detail and come up with an ideal (most optimal) BI Data Model. Functional Team needs to justify each requirement with the help of results derived from Steps 03 & 04 above. Technical team will come up with views for data loading, data volume, aggregation, levels of data storage, performance, flexibility in design, etc. The result of this step is BI Data Model designed on paper giving every single detail which can be used by the execution team for designing the model. This brainstorming discussion may help us come up with some doubts/issues in regards to the requirements. This is the stage at which the Functional Team can take it up back to the user for clarifications.
06 of 09: Little things that matter much
Few things such as presentation, fonts, color coding, result rows, decimal places, line item dimensions, calculations (design level/query level), etc. can be taken up at this stage. This step could also be clubbed with the previous step (Step 05) or it can be a second level of Step 05. That is if the doubts/issues with the requirements are cleared from the user, then it can be discussed and taken further in the BI Data Modeling (Paper-Design).
07 of 09: What-If Analysis
A rigid data model may be robust but would not serve the maintenance/change requirements that the client/user may come up. What-If they want to include the Secondary Sales in my current design of Primary Sales? What-If the data load for the level 1 fails? What-If user wants Region from the Customer master and not from transaction data? Is my design capable of handling small changes? Discussing these questions may help you analyze the step further. It is always agreed that once the requirements are gathered defined by the scope they are frozen as per the blueprint prepared. But slight degree of flexibility in design will always help us in maintenance activities.
08 of 09: Feasibility Document
A feasibility document summarizing the above (only in brief) gives a clear picture of what is doable, what not, activities involved, etc. It may as well include activity wise breakup for number of days, expected deliverable at each stage, final delivery.
09 of 09: Execution Plan
Nothing is useful unless you bring it to shape and make it up and running. Plan the activities with the Technical & Functional team and bring up a plan giving a tentative plan for activities and deadlines for each task. Number of people involved at each stage is a good way to judge parallelism. Set up proper escalation points and individual responsibilities to achieve the final ‘end-user’ deliverable.
