An A-Z guide to planning, managing, and executing a Global SAP NetWeaver BI project - Part 2

1. An A-Z guide to planning, managing, and executing a Global SAP NetWeaver BI project - Part 2 Dr. Bjarne Berg Director SAP BI

2. What We’ve Covered So Far (in Part 1)… • Writing your Global SAP BI business case • Defining the scope of your implementation • Writing a milestone plan • Developing your global staffing plan • Budgeting • Comprehensive On-boarding and training • Writing your workplan • Monitoring the progress and risks of your global project • Monitoring quality / instituting a formal approval process • Why you need an SAP BI “user acceptance group”

3. What We’ll Cover Now (In Part 2)… • Final Preparatory steps • Methodology details • SAP BI Global Lessons learned • Requirements and approvals • The Blueprinting Phase • The Realization Phase • The Implementation Phase • Wrap-up

4. What We’ll Cover… • Final Preparatory steps • Methodology • SAP BI Global Lessons learned • Requirements and approvals • The Blueprinting Phase • The Realization Phase • The Implementation Phase • Wrap-up

5. 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. It decides who will be involved, and what their goal is. Standards and procedures: Sets the ‘why’ and ‘how’ of the project. Standardizes how meetings are run, how documents are handled, etc. so everyone understands what is going on. Source: Pauline Woods-Wilson This is what we covered in Part 1…

6. What is ASAP?

7. The ASAP Approach (from Part-1)

8. In- scope? Make enhancements Activate standard content Request for modifications Yes No Load infocube User acceptance session Test In-future scope? No Review data quality issues Deploy Create 2-3 sample queries Rejection Alternative Approach For Smaller Projects (I.E. 1st Go-live) Keep the scope focused and use a simple approach: No functional or technical specs are used in this approach. The user acceptance session is used to refine requirements

9. Critical Success Factors for Global SAP BI Projects Individual Organizational Technological Methodology The best people End users on the team Platform sizing Proper scope Backfilling Communication with Testing tools Leadership and users commitment Few locations (keep it focused and have many rollouts) Documentation and Integ ration testing Budget for training internal before releasing consulting and changes training Good SAP Breadth and depth of Do not modify code Overseas contacts consultants training Source: Lee Schlenker These are lessons learned the hard way… Don’t re-invent the wheel--learn from others.

10. SAP Solution Manager Was added in 2004 Source: SAP AG

11. SAP BI Best Practices – some hints This tool is still being enhanced, but has several BI-specific project accelerators that you won’t find in SAP Solution Manager. It has been available for 4 years. The current release is version 1.7 (as of August 2007) You can access SAP BI Best Practices for BI at: http://help.sap.com/bp_biv170/index.htm

12. Option – Workplans Based on Deliverables The best practice documents are organized around scenarios, which simplify the collection of tools Source: SAP – Aug, 2007

13. SAP BI Best Practices – What Versions Does It Support? SAP BI 7.0 The SAP Best Practices tool was developed for SAP BI 3.5, and later updated for SAP BI 7.0. SAP BI 3.5 Source: SAP – Jan, 2007 While install recommendations are based on SAP BI 3.5/ or BI 7.0, most management tools, accelerators, and the sample work plan are not version-specific

14. Rapid Application Development (RAD) • Be flexible and consider using a RAD (Rapid Application development) approach for the initial information requirements gathering task. Typical ways to conduct this include: • Ask for 1-2 days of uninterrupted time at each location, and provide lunch on-site (global requirements gathering take 2-3 times more time -- plan for it) • Invite power users, casual users, today's report writers, and managers • Remove cell phones, PDA, pagers, and email access • 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 You can use the session as an information sharing event, and give a brief overview of what you are attempting to do

15. What We’ll Cover… • Final Preparatory steps • The Blueprinting Phase • Some Global Case Studies • Leveraging the standard content • Modeling your solution • Deliverables • The Realization Phase • The Implementation Phase • Wrap-up

16. Let’s Look at a Global BI Project Example A case study • Fortune 100 company with operations around the world • 230 systems identified as “mission critical” • 23 installations of SAP R/3 on 6 continents • Other ERP systems: • JD Edwards • Custom-developed Oracle systems

17. Global Data Warehouse Initiatives A case study These were the DW initiatives that corporate HQ knew about

18. Rationale for a “Bottom-Up” Global SAP BI Approach

19. Global SAP BI Activities, Priorities and Architecture

20. An Approach to BI Global Architecture Development BISC (Business Information Supply Chain) Responsibilities

21. The project delivered local SAP BI solutions and packaged solutions for decision support as a first priority, and the Global Data Warehouse as a second priority. A “fixed departure approach” was applied with focus on delivering solutions rather than projects and software; specific BI solutions were developed according to a pre-defined schedule where local business units were invited or encouraged to participate. “Bottom-Up Fixed Departure” CHANGE Departure II - 3 months Departure IV - 3 months Departure I - 3 months Departure III - 3 months SAP BI Global Rollout Approach

22. A Global Rollout – a Different European Example In this case, the company created both a local and global BI system for CRM data UK North West (Den Haag) Local AMC/Dev Spiridon/CRM Local AMC/Dev Spiridon/CRM BW others Ireland Spiridon CRM CRM (one client) others Switzerland Global Development Spiridon/CRM Mid South (Wien) Netherlands Local AMC/Dev e.p@ss/CRM BW e.p@ss CRM BW others South West (Madrid) Turkey Austria Local AMC/Dev Spiridon/CRM BW Belgium Spiridon CRM Portugal Spain Source: Siemens Corp information 2004

23. Fortune-500 Retailer Very large global telecom Co. Global oil co. Global oil co. BW version 3.1c 3.1c 3.0b 3.2 5-20 million Largest cubes have 18.8 35 million rows 120 million records in transactional records million, 18.4 million, and sales, and 230GB in Largest Volume in FI cubes 11.2 million records Sales and finance each. Keep scope and Should not have gone Data movement is Custom coding cannot development effort “live” on 1.2a, should the most complex overcome the BW focused, use more have used more than part of BW. The extractors. Integration than one one presentation tool. project would not with non-R/3 data was Lessons presentation tool, have accepted as technically easy, but The extract and load learned don’t underestimate many enhancements conceptually hard. process is the most if done again. the extract and load The team members must complex, strong BW You need a really . have solid BI skills effort experience is essential strong BI architect Standardized global Creation of corporate SAP R/3 was being Custom global reporting reporting enterprise-wide data installed, and SAP has a too-high cost Business warehouse BW is the reporting of ownership and is too drivers strategy for all key hard to manage. Want performance content and features. indicators Very happy with Overall happy. Have Very happy with the Is being rolled out to more subsidiaries and management is pleased with results implementation accomplished in 6 speed of delivery and Success added 3 more months what would user satisfaction countries last year have taken 5 years. Some Lessons Learned From Other Global Implementations The major findings highlight the need for specialized BI skills and very strong scope control…

24. Global Examples Summary • A conceptual architecture is the first step and the physical architecture is a product of this. It should be driven by the user needs and the types of interfaces needed, and not by an internal IT exercise. • SAP BI can now be used as an enterprise Data Warehouse and a Global rollout can be accomplished. • There are two core ways to succeed, but both require strong central control and support.

25. A Process Look at Getting Functional Specifications Build storage Construct Create a contact Create a tool to Gather Disposition Consolidate objects and reports and group and contact collect info information the info. requirements load programs navigation list for business requests and requests requests to and write using the features input and business input tool. Plan traveling BW or R/3 functional specs requirements There is more than one way to collect this information. However, a formal process should exist to capture requirements & communicate what is being developed. We will now examine the most common form of RAD (Rapid Application Development).

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

27. Getting the Global Functional Specifications (cont.) • Create a form that captures the business’ core requirements in a structured format Create a simple 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)

28. Sample Info Request Form: • Document requirements in a standardized format and allow for a large comment section • Prioritize requirements • Consolidate requirements • Support follow-up discussions and reviews. P1 of 2

29. Sample Info Request Form: • Other uses: • Post the form on the Intranet, thereby giving stakeholders an easy way to communicate with the project team • Use the Comment section for language and security requirements, or add a separate section for this. • Note the section for dispositioning the requirement P2 of 2

30. An Example

31. An Example

32. 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 data Analysts and power users tend to prefer high flexibility and unstructured access to data 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 Consider Multiple Country Views of Displaying the Same Data!! Don't underestimate different users in various countries and their need to access the information in various ways -- one size does not fit all!

33. Blueprinting Phase: Some Key Observations Getting the right requirements: Finding out the detailed functional specs of what users really need and not just what they want. Deciding what will be developed in SAP BI 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.

34. 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 belong in R/3, which would not be cost effective to move to SAP BW • Make cost-effective decisions; just because the report is not in SAP BI does not mean it cannot be added to a Portal or viewed on the Web • Not all reports belong in SAP BW; avoid using SAP BI as a "dumping group" • You need to make conscious decisions on what reporting needs you are going to meet, and how you will accomplish this We will now take a look at an approach to formal report dispositioning that has been used by a few companies.

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

36. Team starts by reviewing documentation tool for An example of how to decide which reports should be in R/3 or the legacy system (refer to printed version) 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 BI 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 - BI or R/3 Baseline reports

37. Many requirements can be met by a single SAP BI 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 report across your organization) • Legacy reports are often a great way to document the data needs • They can be used to illustrate how data is currently being summarized and viewed • Consolidate the requirements, and look for "low-hanging fruit" • Create a physical folder with paper copies of these legacy reports • Make sure that the development team has access to them -- this will reduce the time spent in meetings with the business community

38. * Rapidly improving content Where do I start? All functional areas are not equally supported by strong standard SAP BI business content. Some areas have much you can leverage, others will require significant enhancement to meet your requirements The differences are often due to customization on the R/3-side by companies and/or industry solutions. Focus on an area that solves a problem instead of becoming a "replacement" project. Gradually, using a prioritized phased approach, solve other business problems. A good way to think of a BI rollout is in terms of business problems.

39. The Blueprinting Phase: Leveraging Standard Content • As a guiding principle, map requirements to standard content before customizing • However, you’ll probably also have external data sources that require custom ODSs and InfoCubes • Customizing lower level objects will cause higher level standard objects to not work, unless you are willing to customize these also…. An example from a large manufacturing company BW Content available (3.5.1): • Cockpits ??? • Workbooks 1,979 • Queries 3,299 • Roles 861 • MultiCubes 121 • InfoCube 605 • ODS objects 349 • InfoObjects 11,772

40. The Blueprinting Phase: Model Your Solution 1. Create a model based on pre-delivered SAP BI content 2. Map your data requirements to the delivered content, and identify gaps 3. Identify where the data gaps are going to be sourced from Storage Requirements + Storage Objects Standard content Map functional requirements to the standard content before you make enhancements

41. What We’ll Cover… • Final Preparatory steps • 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

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

43. Building ODSs and InfoCubes TIPS 1 Review the functional requirements and 6 Do not allow exceptions to your naming conventions technical design 2 Make sure you have established Data 7 Make sure that “putting out fires” does not Stewards for master data, and assign take precedence, becoming the master data to specific developers “default” architecture and standard. 3 Have your ETL developers work 8 Try new ideas in a sandbox environment , for the individual who is responsible and don’t contaminate the development environment. for creating process chains (organizationally) 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 the needs of a single infoCube. 5 Make your transformations part of 10 Developers must unit test all of their update rules into infocubes if you need work and personally sign-off on their to be able to reconcile to the source storage object. system. Keep the details in the ODS.

44. Consider Upgrading to SAP BI in SAP NetWeaver 2004s On a typical SAP BI project, 40-60% of project effort will be spent on data integration, transformation, and loads BI in SAP NetWeaver 2004 has a new GUI to help you write transformations, potentially saving you a lot of time! Source SAP AG

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

46. SAP BI 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. Plan for more than one test location and early announcements (i.e. France, US and Japan).

47. SAP BI Test Scheduling: Example • Each team should have dedicated time in the test room in each country. If needed, rent your own training/test room • Provide food and snacks • At least 2 testers (preferably 3) should be assigned to test each query • All test results must be logged

48. SAP BI Test: Checklist • Preparations • Data source/cubes/ODS/queries prioritized for testing • Queries developed and available in the SAP BI test environment • Track specific test plans created using test template • Test cases written • People • Individuals (testers) perform the identified tests • Testers invited to complete SAP BI on-line training • Availability of testers confirmed • Security roles tested and user ID’s for testers have been created • Logistics • Testers familiarized with test results recording tools • Identify test location and verify resources • Rooms, computers, sapgui, network connections, phone, etc. • Plan for problem resolution

49. Performance Testing • Performance test execution • Identify queries to be performance tuned, and determine cutoff load for load test – e.g. 40% of actual users (not named) • Schedule queries to run in background, and execute each query while load scripts are running to simulate “real” users • Monitor your system continuously, and attempt tuning at the query level • Perform analysis based on benchmarks, and build aggregates and/or indexes • Record findings in a formal tracking tool available to everyone • Meet with developers daily to discuss issues • Problem resolution: Look at the new BI Accelerator in SAP BI 7.0 for improved performance !!! Source: Alexander Peter, SAP AG

50. 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 in each country and the overall steering committee