An A-Z Guide to Planning, Managing, and Executing an SAP BW Project Part 2

1. An A-Z Guide to Planning, Managing, and Executing an SAP BW ProjectPart 2 Dr. Bjarne Berg Lenoir-Rhyne College.

2. What We Covered So Far (in Part 1)… • Writing The business case • Defining the scope • Writing the milestone plan • Timelines and staffing plan • Budgeting • On-boarding and training • Writing the workplan • Monitoring progress • Monitoring quality and a formal approval process • The user acceptance group and their role

3. What We’ll Cover (Part 2)… • Approach • The blueprinting phase • The realization phase • The implementation phase • Wrap-up

4. What We’ll Cover (Part 2)… • The approach • Methodology • Lessons learned • Requirements and approvals • The blueprinting phase • The realization phase • The implementation phase • Wrap-up

5. What Do Users Really Want? Source: SAP

6. Project Preparation: Some Key Observations Project charter: Represents an agreement on, and commitment to, the deliverables of the project, as well as the time constraints, resources, standards, and budget of the project. Project plan: This is the first cut. It focuses on milestones and work packages. Scope: Sets the initial definition of the project. Project team organization: Sets the ‘who’ of the project. This decides who will be involved and what is their goal. Standards and procedures: Sets the ‘why’ and ‘how’ of the project. Standardizing how meetings are run, documents are handled, etc means that everyone understands what is going on. Source: Pauline Woods-Wilson (This is what we covered in Part 1)

7. A Brief Look at ASAP • ASAP for BW is based on many of the same ideas and approaches that are found in the ASAP methodology for R/3 • We will take a look at some core differences….

8. What is ASAP?

9. What are the Core SAP Benefits? Source: CEO Survey - Monash University • The main reasons for SAP BW and R/3 implementations are to provide better access to information • The BW system being built cannot be slower, less user-friendly or harder to learn than the one it is replacing!

10. Critical Success Factors to a BW Project Source: Lee Schlenker These are lessons learned the hard way!! Don’t re-invent the wheel but learn from others.

11. SAP Solution Manager Source: SAP

12. A Process Look at Getting Functional Specifications There is more than one way to collect this information, however, a formal process should exist to capture requirements and to communicate what is being developed. We will now examine the most common form of RAD (Rapid Application Development).

13. Rapid Application Development (RAD) • Be flexible and consider using a RAD (Rapid Application development) approach to the initial information requirement gathering. Typical ways to conduct this include: • Ask for 1-2 days of uninterrupted time and provide lunch on-site • Remove cell phones, PDA and pagers and emails • Invite power users, casual users, today's report writers, and managers • Keep a rapid pace and a manageable number of attendees (no more than 20) • Focus on shared information needs and conduct multiple sessions if needed • Don't get trapped in details; give people a chance to provide feedback in writing and follow up later with individuals

14. Rapid Application Development (cont.) • Benefits include: • Increased user involvement and less disruption to the business • More likely to avoid individual opinions and get more group consensus • You can use the session as an information sharing event and give a brief overview of what you are attempting to do

15. Getting the Functional Specifications • Avoid creating a total inventory of all reports in the organization. The "top-5" (most used) sales, distribution, inventory etc. reports from each department will cover the vast majority of the reporting needs. • A single BW "report" may satisfy dozens of today's static reports. It is therefore impossible to map each individual legacy report to a single BW report. Avoid attempting to replicate each report based on what you might have in place today. Accept new ways of accessing data.

16. Getting the Functional Specs (cont.) • Create a form that captures the core requirements in a structured format Create a simple form called "information request form" and use it to gather the core relevant information about each report being requested by the business community. This should include at least the following fields: - Contact info about the requestor - Data currency (yesterday/today) - Department - Security requirements - Name of report - How is this reporting done today - Purpose of report - Comments - Description of report - Type of users (mgr./analyst/casual) - Number of users expected - Frequency of report (daily/monthly)

17. Sample Information Request Form • Document requirements in a standardized format • Prioritize requirements • Consolidate requirements • Support follow-up discussions and reviews. P1 of 2

18. Sample Information Request Form • Other uses: • Post form on the intranet and thereby give stakeholders an easy way to communicate with the project team. • Use the comment section for security requirements, or add a separate section for this. • Note the section for dispositioning the requirement P2 of 2

19. Report Dispositioning: What Goes in BW and What Stays in R/3? • There are many tools that can report on R/3 data and you might have static reports that truly belongs in R/3 and which would not be cost effective to move to BW • Make cost-effective decisions; just because the report is not in BW does not mean it cannot be in a portal or on the web • Not all reports belong in BW; avoid using BW as a "dumping group" • You need to make conscious decisions on what reporting needs you are going to meet and how you want to accomplish this We will now take a look at an approach to a formal report dispositioning that has been used by a few companies.

20. Key Questions for Report Dispositioning • Is this really a reporting need or a "want"? • Is the data going to be in BW at a frequency that solves the user's request (intraday reporting)? • Is the data needed for this report already in our BW scope? • Are there already a report available in R/3 ? • Does standard BW content exist? • Is it less expensive to create in R/3? • Are there a significant number of users? • Is the reporting need resource-intensive? • Is BW cost effective in the long run (ownership)?

21. Team starts by reviewing documentation tool for An example of how to decide which reports should be in R/3 or the legacy system (printed version is easier to read) documentation completeness cu Review requirements and identify corresponding Data Model (InfoCube/ODS) D1a D1 Communicate to Is this a true Is report No Yes bus. leader documentation reporting need complete? Yes D4 No D2 D2.5 D3 Is the report Is this Does data exist Significant No No No system an Intraday in "in-scope" models number resource report? Infocube/ODS of users? Request additional No intensive? input from Business Team member Yes Yes R/3 is selected as Yes Reporting Tool R/3 is selected as and documented A2 Reporting Tool in doc. tool Total Cost of and documented Ownership Responsible Analysis Team member acquires/documents additional information R/3 is selected as Communicate final Reporting Tool D8 and documented disposition No Is BW cost in doc. tool effective? Yes BW is selected as D5 Communicate final Reporting Tool Does Yes disposition and documented No Yes Standard R/3 in the documentation tool content D9 exist? BW is selected as R/3 Tool D6 reporting tool and Change Selection D7 Does Request is submitted if Communicate final Process Is it less the scope changed Standard BW disposition No expensive to content create in No exist? R/3? Standard Report R/3 Writer Yes Yes ABAP/ BW is selected as BW is selected as Communicate final R/3 is selected as Query Other Custom Reporting Tool and Reporting Tool and disposition Reporting Tool documented in doc. documented in doc. and documented tool tool in doc. tool A3 Sub-Process Report Consolidation & eliminate if appropriate (winnowing) Communicate final Communicate final Communicate final disposition disposition disposition R/3 team make final disposition BW Team to forward completed detailed report specifications A4 based on selected Reporting Tool - BW or R/3 Baseline reports

22. Many requirements can be met by a single BW report + + = Now That You Have Identified the In-Scope Reports, What’s Next? • Obtain a copy of each of the current reports that are “in-scope” (not all). • Legacy reports may be a great source to document the data needs; they can be used to illustrate how data is currently being summarized and viewed in the organization • Consolidate the requirements and look for "low-hanging fruit" • Create a physical folder with paper copies of "in-scope" legacy reports; make sure that the development team has access to them and reduce the time spent in meetings with the business community

23. Flow Overview Reports Business Reporting Requirements BW Reports An example from a very large manufacturing company

24. An Example

25. An Example

26. KPI & Scorecard Formatted • Simple • Easy to view • Limited nav • Aggregates Flat Reporting • Formatted • Print • Form based • Static • Predictable access OLAP Reporting • Drill Down • Slice and Dice • Analyse • Data Mining • Search and discover OR OR Consider Multiple Ways of Displaying the Same Data!! Deliver reports in a consistent manner to users (one version of the "truth"), but use different mechanisms to do so. • Managers and executives tends to prefer simple and directed interfaces • Casual users tends to prefer predictable structured access to the data • Analysts and power users tends to prefer high flexibility and unstructured access to the data. Don't underestimate the user's need to access the information in various ways.

27. What We’ll Cover (Part 2)… • The approach • The blueprinting phase • Leveraging the standard content • Modeling your solution • Deliverables • The realization phase • The implementation phase • Wrap-up

28. Blueprinting Phase: Some Key Observations Getting the right requirements: Finding out the detailed functional specs of what the users really need and not just what they want. Deciding what will be developed in BW and what will be maintained as R/3 reports. Map the functional requirements to the standard content and see what can be leveraged and what needs to be extended. Create detailed technical specifications and designs of infocubes, masterdata, ODSs and high-level architectural designs. Create user acceptance group(s) and have them review and give feedback on the system as it is developed.

29. The Blueprinting Phase: Leveraging Standard Content • As a guiding principle we map requirements to standard content before we start customizing. • However, we may also have external data sources that require custom ODSs and InfoCubes. • Some observations on higher level objects……. An example from a large manufacturing company BW Content available: • InfoObjects 11,772 • ODS objects 349 • InfoCube 605 • MultiCubes 121 • Roles 861 • Queries 3,299 • Workbooks 1,979

30. The Blueprinting Phase: Modeling Your Solution Storage Storage Requirements + BW InfoCubes Standard content A real example from a very large manufacturing company

31. Modeling Your Solution 1. Write functional requirements 2. Create a model based on pre-delivered BW content 3. Map your requirements to the delivered content and identify gaps.

32. What We’ll Cover (Part 2)… • The approach • The blueprinting phase • The realization phase • Building ODSs and InfoCubes • Planning, Managing and executing system test • Planning, Managing and executing integration and performance test • Issue resolution, logs, sign-off and approvals • The implementation phase • Wrap-up

33. Realization Phase: Some Key Observations Development Programs: Provide details of added programming structures End User Training Material Configuration and Testing Plans: Define how the configuration will be implemented and how it will be tested Source: Pauline Woods-Wilson

34. Building ODSs and InfoCubes TIPS 1 Review the functional requirements and 6 Do not allow exceptions to the naming the technical design conventions 2 Make sure you have established data 7 Make sure that “putting out fires” do not stewards for the masterdata and assigned take precedence and becomes the “defaulted” the masterdata to specific developers architecture and standard. 3 Have your ETL developers report 8 Try new ideas in a sandbox environment functionally to an individual who is and do not contaminate the development responsible for creating process chains environment. 4 Avoid nested ODS layers and keep the 9 Keep details for multi-use in the ODS and architecture as pristine as possible do not design the ODS based on a the needs of a single infoCube. 5 Make your transformations as part of 10 Developers must perform unit test on all update rules into infocubes if you need their work and personally sign-off on their to be able to reconcile to the source storage object. system. Keep the details in the ODS.

35. The BW Test Methodology Methodology used for System and Integration tests Test Strategy Test Plan Test Execution Problem Resolution R/3 and BW testing is not different from a methodology standpoint, but the execution is….

36. System Test: Planning Activities "There's no time to stop for gas, we're already late" Business analysts are responsible for planning, coordinating and executing the system testing of queries.

37. System Test Scheduling: Example • Each team has dedicated time in the test room. • Food will be provided (pastry, doughnuts etc) • At least 2 testers (preferably 3) should be assigned to test each query • All test results to be logged

38. System Test: Checklist • Preparations • Functional requirements complete • Prioritize data source/cubes/ODS/queries for testing • Identify critical path for testing • Queries developed and available in BW test environment • Modify test script to suit each track • Track specific test plans created using existing test template • Test cases written

39. System Test: Checklist (cont.) • People • Individuals (testers) to perform the test identified • Testers invited to complete BW web-based training • Availability of testers ensured • Roles to be used by testers determined • Security roles tested • User ID’s for testers created and available • Logisitics • Familiarize test results recording tools – LN database, issues log • Identify test location, and ensure availability of logistics (rooms, computers, sapgui, network connections, phone, etc..) • Plan for problem resolution

40. Integration Test: Planning • Progress meeting • Held daily to monitor progress and resolve common issues • Attendees: • Business analysts, back-end developers, query developers, test coordinator, and Test Problem Report (TPR) administrator • Purpose: • Discuss common issues, monitor progress, discuss plan changes • Duration: • 30 minutes

41. Performance Testing • Performance test execution • Identify queries to be performance tuned • Determine cutoff load for load test – e.g. 40% of actual users (not named) • Schedule queries to run in background • Execute each query while load scripts are running to simulate “real” users • Monitor BW system continuously • Attempt tuning at query level • Perform analysis based on benchmarks • Build aggregates, indexes, etc. if needed • Record findings in a formal tracking tool available to all • Meet with developers everyday to discuss issues/progress • Problem resolution

42. Test Signoffs • Signoff procedure • Document test feedback and update logs • Review open issues • Prioritize outstanding issues • Agree on scope decisions and resolutions • Obtain approvals from business representatives or steering committee

43. What We’ll Cover (Part 2)… • The approach • The blueprinting phase • The realization phase • The implementation phase • Executing cut-over to production • Conducting end-user and power user training • Establishing end-user support organization • Post-implementation review and next steps • Wrap-up

44. Final Preparation Phase: Some Key Observations The Cutover Plan and the Technical Operations Manual describe the details on how to move to the production environment and go live The Stress & Volume Tests confirm the production hardware’s capabilities The End User Training document describes the delivery of the necessary levels of SAP training prior to going live Source: Pauline Woods-Wilson

45. Conducting End-User and Power User Training • Types of training: • Web-based • All users • Training • Tutorials • Instructor-led • On-site • Power users • Executives • Vendor-based • Developers • Support staff

46. Establishing End-User Support Organization Getting Power Users involved early is important to the overall success of a Data Warehousing project To help support businesses that have already gone live, a strong local community of “ambassadors” is needed. If you don’t have them, on-going projects may get “bogged down” with basic support of reports.

47. ONTINUE ONTINUE HANGE HANGE C C C C BOTTOM - UP TOP - DOWN APPROACH APPROACH Focus on a bottom up - Building a global data approach where the DW project warehouse for will prioritize supporting and and proceed sourcing data delivering DW solutions, but from legacy systems driven where businesses are actively from a top - down approach involved in developing reports. where reports are also created centrally. A BW Data Warehouse Approach at a Company BW Data Warehouse Alternatives Should a set of Ambassadors be part of the rollout-strategy? How can this be done with minimal organizational disruption? [company X] The core issue was if the support organization should be centralized, or if the local organizations should be involved.

48. Some Benchmark Indications Regarding Ambassadors Can you use a BW ambassador in your user organization? Increased business involvement increases the probability for data warehouse project success.

49. Go-Live: Some Key Observations The last deliverable for the implementation ensures high system performance through monitoring and feedback Source: Pauline Woods-Wilson We need to execute issue resolution plans and contingency plans A “lessons learned” session should be held at the end of the project to assure organizational awareness and education The support organization will take over the system after a pre-determined time period. Some team members may transition into their new roles as support staff This is a critical time when a “SWAT” team that quickly addresses user concerns can make all the difference in how the system is received among the users

50. Go-live: Post-Implementation Review The Information Paradox: John Thorp