2. © 2004 Wellesley Information Services. All rights reserved. Dr. Bjarne Berg Lenoir-Rhyne College. An A-Z Guide to Planning, Managing, and Executing an SAP BW Project Part 2

3. 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

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

5. 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

6. 5 Source: SAP What Do Users Really Want?

7. 6 Project Preparation: Some Key Observations Core Activities 1.1 Initial Project Planning 1.2 Project Procedures 1.3 Training Preparation 1.4 Project Kickoff 1.5 Technical Requirements Planning 1.6 Quality Check Project Preparation Project plan: This is the first cut. It focuses on milestones and work packages. 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. 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)

8. 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….

9. 8 What is ASAP?

10. 9 What are the Core SAP Benefits? 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! Source: CEO Survey - Monash University

11. 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.

12. 11 SAP Solution Manager Source: SAP

13. 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).

14. 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

15. 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

16. 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.

17. 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)

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

19. 18 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 Sample Information Request Form

20. 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.

21. 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)?

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

23. 22 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 ++ = Many requirements can be met by a single BW report

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

25. 24 An Example

26. 25 An Example

27. 26 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. Flat Reporting Formatted Formatted Print Print Form based Form based Static Static Predictable access Predictable access OLAP Reporting Drill Down Drill Down Slice and Dice Slice and Dice Analyse Analyse Data Mining Data Mining Search and discover Search and discover KPI & Scorecard Formatted Simple Simple Easy to view Easy to view Limited nav Limited nav Aggregates Aggregates Don't underestimate the user's need to access the information in various ways. OR Consider Multiple Ways of Displaying the Same Data!!

28. 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

29. 28 Blueprinting Phase: Some Key Observations Core Activities 2.1 Project Management Business Blueprint 2.2 Organizational Change Management 2.3 Project Team Training Business Blueprint 2.4 Develop System Environment 2.5 Organizational Structure Definition 2.6 Business Process Definition 2.7 Quality Check Business Blueprint Deciding what will be developed in BW and what will be maintained as R/3 reports. Getting the right requirements: Finding out the detailed functional specs of what the users really need and not just what they want. Map the functional requirements to the standard content and see what can be leveraged and what needs to be extended. Create user acceptance group(s) and have them review and give feedback on the system as it is developed. Create detailed technical specifications and designs of infocubes, masterdata, ODSs and high-level architectural designs.

30. 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……. BW Content available: InfoObjects 11,772 ODS objects349 InfoCube605 MultiCubes121 Roles861 Queries3,299 Workbooks1,979 An example from a large manufacturing company

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

32. 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.

33. 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

34. 33 Realization Phase: Some Key Observations Core Activities 3.1 Project Management Realization 3.2 Organizational Change Management 3.3 Training Realization 3.4 Baseline Configuration and reviews 3.5 System Management 3.6 Final Configuration and Confirmation 3.7 Prepare & Coordinate interface development 3.8 Develop Data Conversion Programs (if any) 3.9 Develop Queries 3.10 Develop User interface enhancements 3.11 Determine additional reporting requirements 3.12 Create structured reports 3.13 Establish Authorization Concept 3.14 Establish Data Archiving plan (if applicable) 3.15 Final Integration Test 3.16 Quality Check Realization Configuration and Testing Plans: Define how the configuration will be implemented and how it will be tested Development Programs: Provide details of added programming structures End User Training Material Source: Pauline Woods-Wilson

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

36. 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….

37. 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.

38. 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

39. 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

40. 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

41. 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

42. 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

43. 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

44. 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

45. 44 Final Preparation Phase: Some Key Observations Core Activities 4.1 Project Management Final Preparation 4.2 Training Final Preparation 4.3 Acceptance Testing 4.4 System Management 4.5 Detailed Project Planning 4.6 Cutover 4.7 Quality Check Final Preparation The Cutover Plan and the Technical Operations Manual describe the details on how to move to the production environment and go live The End User Training document describes the delivery of the necessary levels of SAP training prior to going live The Stress & Volume Tests confirm the production hardware’s capabilities Source: Pauline Woods-Wilson

46. 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

47. 46 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. Establishing End-User Support Organization

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

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

50. 49 Go-Live: Some Key Observations Core Activities 5.1 Production Support 5.2 Project End 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

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

52. 51 What We’ll Cover (Part 2)… The approach The blueprinting phase The realization phase The implementation phase Wrap-up

53. 52 7 Key Points to Take Home Keep the team relatively small and focused Size your projects based on the team experience Make the implementations interactive instead of “Big-Bang” Do not cram all reports into BW (some belong in R/3) Follow a proven methodology Track quality and create a formal approval process Involve power users and ambassadors in the development

54. 53 Resources a) Rapid Development by Steve McConnell Paperback: 680 pages ; Publisher: Microsoft Press; ISBN: 1556159005 b) Start to Finish Guide to IT Project Management by Jeremy Kadlec Digital: 109 pages. Publisher: NetImpress; ISBN: B0000W86H2 Download it at:

55. 54 Your Turn!!! How to contact me: bergb@lrc.edu