2. © 2007 Wellesley Information Services. All rights reserved. An A-Z guide to planning, managing, and executing a Global SAP NetWeaver BI project - Part 2 Dr. Bjarne Berg Director SAP BI

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

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

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

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

7. 6 What is ASAP?

8. 7 The ASAP Approach (from Part-1)

9. 8 Alternative Approach For Smaller Projects (I.E. 1 st 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 Activate standard content Review data quality issues Create 2-3 sample queries Load infocube User acceptance session Request for modifications In- scope? Rejection In-future scope? Make enhancements Test Deploy Yes No

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

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

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

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

14. 13 SAP BI Best Practices – What Versions Does It Support? The SAP Best Practices tool was developed for SAP BI 3.5, and later updated for SAP BI 7.0. 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 Source: SAP – Jan, 2007 SAP BI 3.5 SAP BI 7.0

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

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

17. 16 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 Let’s Look at a Global BI Project Example A case study

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

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

20. 19 Global SAP BI Activities, Priorities and Architecture

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

22. 21 SAP BI Global Rollout Approach 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. C HANGE “Bottom-Up Fixed Departure” Departure I - 3 months Departure II - 3 months Departure III - 3 months Departure IV - 3 months

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

24. 23 Some Lessons Learned From Other Global Implementations The major findings highlight the need for specialized BI skills and very strong scope control…

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

26. 25 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 & communicate what is being developed. We will now examine the most common form of RAD (Rapid Application Development). Create a contact group and contact list for business input and requirements Create a tool to collect info requests business input Gather information using the tool. Plan traveling Disposition the info. requests to BW or R/3 Consolidate requirements and write functional specs Build storage objects and load programs Construct reports and navigation features requests and

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

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

29. 28 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 Sample Info Request Form:

30. 29 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 Sample Info Request Form:

31. 30 An Example

32. 31 An Example

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

34. 33 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 SAP BI and what will be maintained as R/3 reports. Getting the right requirements: Finding out the detailed functional specs of what 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.

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

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

37. 36 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 BI 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 - BI 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 (refer to printed version)

38. 37 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 ++ = Many requirements can be met by a single SAP BI report

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

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

41. 40 Standard content The Blueprinting Phase: Model Your Solution Storage Requirements Storage Objects Map functional requirements to the standard content before you make enhancements + 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

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

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

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

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

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

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

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

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

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

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

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

53. 52 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 Stress & Volume Tests confirm the production hardware’s capabilities Source: Pauline Woods-Wilson

54. 53 Conducting End-User and Power User Training Web-based  All users  Training  Tutorials Instructor-led  On-site  Power users  Executives Vendor-based  Developers  Support staff 1) Create, or buy, an on-line help and training system. Make sure you use many images and links. 2) Consider using animations to demonstrate complicated tasks as well. 3) Consider multi language versions of the help and training system

55. 54 Getting Power Users involved early is important to the overall success of a Data Warehousing project To help support countries and regional businesses that have already gone live, a strong local community of “ambassadors” is needed. Without them, ongoing projects can get “bogged down” with basic report support and enhancement requests. Establishing Local and Global End-User Support Organization

56. 55 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

57. 56 Tracking Load Performance During the first 6 weeks after each go-live, you should formally track the load performance by process chain to see if you have any systematic issues It is also a great way to document your success!! Load performance rate 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 3/20/20053/22/20053/24/20053/26/20053/28/20053/30/2005 4/1/20054/3/20054/5/20054/7/20054/9/2005 4/11/20054/13/20054/15/20054/17/20054/19/20054/21/20054/23/20054/25/20054/27/20054/29/2005 5/1/20055/3/20055/5/20055/7/2005

58. 57 Tracking Load Performance (cont.) A stabilization period after each go-live is normal, until the new process chains has been tuned in the production box This is a time when active monitoring of process chains should occur Areas of BI Data Load Issues Nov. 1st through Dec. 15th 0 1 2 3 4 5 6 7 11/1/0411/2/0411/3/0411/4/0411/5/0411/6/0411/7/0411/8/0411/9/04 11/10/0411/11/0411/12/0411/13/0411/14/0411/15/0411/16/0411/17/0411/18/0411/19/0411/20/0411/21/0411/22/0411/23/0411/24/0411/25/0411/26/0411/27/0411/28/04 11/29/0411/30/04 12/1/0412/2/0412/3/0412/4/0412/5/0412/6/0412/7/0412/8/0412/9/04 12/10/0412/11/0412/12/0412/13/0412/14/0412/15/04 Number of Issues Production Performance Demand Planning Transaction - global Source - Purchase Orders Roughcut Material Movements MD - Bev. Packaging Master data Hierarchies Greycon CO -line items

59. 58 Go-live: Post-Implementation Review The Information Paradox: John Thorp Conduct a formal 'post-mortem' after go-live before starting the next phase of the project. Not everyone will tell you if they dislike the system, but you need to give them a chance and learn from your mistakes (continuous improvements).

60. 59 What We’ll Cover… Final Preparatory steps The Blueprinting Phase The Realization Phase The Implementation Phase Wrap-up

61. 60 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 c) Dr. Bjarne Berg Home page c) ( http://csc-studentweb.lr.edu/swp/Berg/BB_index_main.htm) Download it at:

62. 61 7 Key Points to Take Home Keep the team relatively small & focused Size your project based on your team’s experience and skills, in addition to scope Make the implementations interactive instead of “Big-Bang” Follow a proven methodology Don’t cram all of your reports into BI (some belong in R/3) Track quality, and create a formal approval process Involve power users and ambassadors in the development project

63. 62 Your Turn!!! How to contact me: bergb@lrc.edu