The document provides guidance on requirements gathering and implementation for an SAP BI project. It outlines key steps including establishing business sponsorship, defining scope, prototyping reports, testing, training users, and obtaining sign-off. Requirements gathering involves workshops to specify report needs in detail. Reports are then developed, tested, and prototyped for user feedback before final development and testing prior to go-live. The roles of business and technical teams are also defined.

1. SAP BI Requirements Gathering and Implementation Frank Silva, Sept 05,2009

2. To be Successful: Business Sponsorship BI Architecture (Business, Data, Technical, Project, BI Organization) Best practices Business/BI Commitment and involvement Business ownership of BI products delivered Well defined process for requirement gathering (eliciting), development, testing and deployment Right Teams (Business, Operational Systems, BI, Implementation) Business knowledge in functional area Business knowledge in reporting needs Business knowledge in BI and reporting tools Learn as much as possible the needs of the users Help the business teams help you

3. Working with Right Teams Business Perspective Operational Systems Perspective (e.g. CRM, FI) Data Warehousing and BI Perspective Implementation Perspective

4. Scoping Collect a complete inventory of reports Reports generated through current BI BI inputs related to Excel reports (Spreadmarts) Ad-hoc queries from current BI environment Reports from the SAP BI standard content Brand new reports (new requirements) Identify priorities Identify Scope

5. SAP NetWeaver BI Demo BI/Business commitment, Critical Success Factors, Scope, goals and times-lines Approach to requirements gathering, development and deployment, sign-offs and freezing reports Team functions – Expectations, goals and objectives, RASCI Introduction to SAP NetWeaver BI, Portal/Concepts/Reports Things to consider about reporting SAP NetWeaver BI is not the only reporting solution! Filling up RDD (specifications/mockup first and then RDD) RDD – Report Definition Document

6. Requirements Gathering Workshop ( Mock-Up Prototype ) Complete specifications (Ref: Report Specification Worksheet) – Global Filters, Prompts, Default Report, Measures (Key Figures), and Free Characteristics. Reports with (a) similar structure/format, (b) slight variations or (c) different filter conditions but with identical format may be combined into a single report. Identify business definitions for all characteristics and key figures (including derived key figures e.g. Gross Profit Std., Fill Rate) Identify data relationships. Help the business teams help you. Guide them through out the session.

7. RDD Review Sessions Review RDDs to make sure that all required specs are captured and recorded. Make sure that security requirements are reviewed and agreed upon.

8. Report Development BI Developer is fully responsible for report development Develop reports as per RDD A well representative sample of data is expected in BID at this stage Coordinate closely with BI BSA/BI Modeler on any issues come across during report development Caution: Before start developing reports make sure that business metadata (business terminology/definitions) are completed.

9. Unit Testing BI Developer is fully responsible for Unit Testing, which normally happens in parallel with development. Unit testing is a verification and validation method in which a developer tests individual units to make sure that those units are fit for use. A unit is the smallest testable part of an application e.g. query. Ensure that the query meets its design specified in RDD. The output results reflect the data in ECD.

10. First Prototype Every BI project typically requires prototyping and rebuilding user requirements. There is nothing business people like more than to see their requirements turn into a tangible deliverable. A prototype accomplishes this goal. The purpose of prototypes is not to see the accuracy of data extracted from the development environment. This is done under unit and integrated testing and later by the business at UAT testing. The environment is usually loaded with small, clean and well representative set of data . The main purpose is to try out visual interfaces, functionality and to make sure that the presented report objects meet their expectations. You do not want to have your prototype results tarnished because of dirty or missing data. Testing the technology for performance is not a valid purpose for a prototype. It is not a stress-test environment.

11. Second Prototype (Optional) Follow the same procedure as the first one. Compare reports against previously updated RDD (Version 2). Note down changes required. Make required changes in the query and update RDD (Version 3).

12. Sign-off and Freeze Reports Both business and BI are committed to this sign-off Set expectations right at the scoping/demo stages by explaining the entire process including sign-off and freezing reports Obtain business sign-off on prototype Inform sponsors/Report Owners/SAP ECC Consultant/Expert (SAP Functional contact) about the freeze

13. Integration Testing Integration testing is a technical BI task. In SAP BI world the following units are tested in an ‘integrated fashion.’ Entire flow of data from Data Source, InfoPackage (transactions, attributes, hierarchy, text), PSA object, InfoObject, DTP (from PSA to DSO, from DSO to InfoCube), DSO, InfoCube, MultiProvider, Security Role, Process Chain, notifications, NetWeaver Portal (startup screens, folders and report lists) and finally check whether reports get data from sources as expected. It is performed to make sure that all BI objects work together in harmony to bring required business information accurately to the users. The performance testing, stress testing and recovery testing may also be performed during integration testing.

14. User Training Provide complete training to the potential users in the business in order to utilize the BI reporting tool effectively in their day-to-day information needs. Provide a good manual and a cheat-sheet (based on related inforprovider). Have training on a related specific InfoProvider rather than on a generic training model Presence of Functional BSA, BI BSA and key user participation is important to answer business and tool related questions. On-site training (atleast for key users) is preferred vs webcasts or net meetings. Note : At this stage the business users can start preparing the scripts for the UAT. All this work will be coordinated by the Functional BSA.

15. User Acceptance Testing (UAT) Once the application is ready to be released the crucial step is User Acceptance Testing (UAT). In this step a group representing a ‘cross section of end users’ tests the application. The user acceptance testing is done using real world scenarios and perceptions relevant to the end users. Therefore the UAT scripts/exit criteria are created by business users and expressed in a business language. Acceptance testing generally involves running a suite of tests on the ‘completed system.’ This means during UAT when operational systems accumulate data it will be transferred to BI environment through scheduled extractions for users to validate through reports. Obtain final sign-off on reports.

16. Key Points to Take Home Follow a sound BI project methodology . Project Duration - ideally not more than 3 months. Clearly define the roles and responsibilities of project team (RASCI) Follow a sound methodology for gathering requirements and implement such requirements keeping user satisfaction as the primary key measure of success. Lead and guide the business team throughout the process – sometimes business doesn’t know what information they want (SAP BI has got tones of information), how reports should be compiled, capabilities of BI tools and how reports are delivered to them. Train business users adequately enough to handle BI reporting tools. Focus on deliverables in scope - These deliverables need to be owned by the business teams, not the BI team. Foster ownership – Reports are owned by the business, not BI. Sign-off on scope, prototype and UAT is important. Help the business teams help you. Guide them through out the process.

17. RASCI