A Guide to Plan and Manage a Successful SAP BI Implementation

2. A Guide to Plan and Manage a Successful SAP BI Implementation Dr. Bjarne Berg Associate Prof., SAP University Alliance Lenoir-Rhyne University and V.P. Comerit Inc.

3. What I’ll Cover

4. Real-time Inquiry Operational Reporting Management Information Lightly Summarized More Summarized More Ad Hoc ERP DW Dividing Line What Logically Belongs in a Global BI System? Seven years ago, with version 3.1C, SAP BI became increasingly able to report on operational detailed data. But some reports still belong in ECC or other transactions systems…

5. The Global Target Architecture – An Example Meta Data Source Data OperationalData Store DataWarehouse Extract Transform Access Managed Query Env. Purchasing R/3 Data ExtractionTransform and Load Processes Marketing& Sales OLAP Legacy Systems Translate Corporate Summarize Data Subsets by Segment External systems Product Line Batch Reporting Calculate Summation Location Messaging SummarizedData Attribute Finance Data Mining Synchronize Supply Internet Reconcile Data Marts Vendor Provided Data Warehouse and Decision Support Framework

6. CONTINUE CHANGE Alternative Global BI Approaches TOP-DOWN APPROACH BOTTOM-UP APPROACH Build a global data warehouse for the company, and proceed sourcing local data from old legacy systems driven from a top-down approach. Focus on a bottom-up approach where the BI project will prioritize supporting and delivering local BI solutions, thereby setting the actual establishment of the global Data Warehouse as secondary, BUT not forgotten.

7. The Six Global Dimensions There are six core global dimensions you must consider before embarking on a global DW strategy. Project management is important, but it’s only one of these dimensions. Failure to account for the others may result in project failures. Source: Peter Grottendieck, Siemens For each dimension, articulate an approach, constraints, limitations and assumptions before you start your project.

8. What the user wanted How designer implemented it How customer described it How analyst specified it Identifying Your Business Requirements • One of the first steps is to gather the right requirements. This is done in a variety of ways, depending on which methodology you employ. It is a complex process involving: • Discovery and Education • Formal communication • Reviews • Final approvals An SAP NetWeaver implementation involves more than just black-and-white technical decisions; just because something is technically feasible, doesn’t mean it is wise or desirable from a business perspective.

9. Defining The Scope Of Your Global SAP BI Implementation • First, determine what the local and shared business drivers are, and make sure you meet these objectives. • Define the scope in terms of what is included, as well as what is not included, make sure everyone is at least heard. In some cultures, process is as important as outcomes. • Make sure you obtain approval of the scope before you progress any further.All your work from now on will be driven based on what is agreed to at this stage. • As part of the written scope agreement, make sure you implement a formal change requestprocess. This typically includes a benefit-cost estimate for each change request and a formal approval process. Change management is done to manage scope, timelines and competing business requirements. Put in place a process for capturing feedback & requests.

10. Selecting A Methodology • Many times, there are several potentially “right” choices • i.e., when time-to-delivery is moderate, or when the impact of failure is moderate. Also be aware of local variations of the methodologies The diagram is intended to illustrate the differences among the appropriateness of each methodology. The decision is clearer in the extreme. In practice, however, there are “gray zones” where more than one answer may be correct.

11. Monitoring BI Quality and Formal Approval Process: Example Integration Testing Create Technical specs Create Functional specs No System Testing Complete? No Yes Unit Testing Complete? Yes Configuration Peer Review Yes Peer Review Approved? No Yes Approved? No Structured walkthrough Complete? Yes Structured walkthrough No Complete? No Yes

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

13. What I’ll Cover

14. Developing Your Staffing Plan: Lessons Learned • Developer training should start early for all project team members • SAP R/3 skills are not easily transferable to SAP BW • Hands-on experience is needed • It’s very hard to learn while being productive • The quality of the team members is much more important than the number of members • An experienced SAP BI developer can accomplish in one day what 3 novice developers can do in a week • The tool has a steep learning curve

15. Organizing the Team — Six Ways to Balance a Development Effort The more distributed the BI development effort becomes, the more difficult it is to maintain communication and get cohesive requirements.

16. Sleep, Travel and Time Zones….. • People crossing 4 or more time zones need over 36 hours to adjust! This increases to over 72 hours when crossing 6 or more time zones. Some simple rules to address this: • Create a "project time" in the middle. I.e. for European and US projects, middle time would be Eastern US time +3 hrs, and European central times less 3 hours. No meetings would be scheduled between 8-11am in Europe, nor between 2-5pm in the US. Source: Leveraging resources in global software development Battin, Crocker, Kreidler, Subramanian, Software, IEEE • Fly to the destination the day before, or allow at least 4 hours downtime for sleeping and showering at the hotel. • Don’t schedule meeting times around when people are traveling. • Keep each trip over 5 days minimum to adjust for sleep, or risk running the team "into the ground"… • Plan extended weekends for family time for staff after a long trip (including consultants)…

17. Organizing the Global Team — Localized BI Training • Training for end-users and the local query developers should be completed in their own language to assure understanding and encourage participation • Developer training should be in the project language (e.g., English, Thai, Chinese). Don’t under estimate the value and cost savings of in-house training.

18. Pick a Project Language and Stick with It! • If you don’t enforce a global project language, BI project documentation becomes fragmented • The project team will quickly disintegrate into groups based on the language with which they are most comfortable • Enforce a project language and require that all emails are written in it and all notes are taken in the same language • Don’t allow “side bars” in languages that others don’t understand Make sure the project language is clear, and that pertinent documents are translated in a timely fashion.

19. Coordination of Multiple Data Warehouse Projects Tight Central Control (24%) Loose Cooperation (38%) Independent (38%) 88% Successful 30% Successful 100% Successful How Tightly Should Multiple Global BI Projects be Controlled? The relationship between global control and success: Source: The Conference Board Survey

20. What I’ll Cover

21. SAP Business Intelligence Project Budgeting Process Steps • Size the SAP BI effort based on the scope • Prioritize the effort • Map the effort to the delivery schedule • Plan for number of resources needed based on the scope, delivery schedule and the effort. We will now look at an example how this process works in the real world Create the Milestone Plan and Scope Statement first, before attacking the budgeting process!! Start the budgeting process by estimating the workload in terms of the development effort. Refine based on the team’s skill experience and skill level

22. 1. Size SAP BI Effort Based on the Scope – Real Example Remember that your sizing also has to be based on the team’s experience and skill level.

23. 2. Prioritize the Effort The next step is to prioritize and outline the effort on a strategic timeline Make sure your sponsor and the business community agree with your delivery schedule

24. 3. Use Project Estimates & the Timeline to Create Project Load Plan There are 480 available work hours per project member per quarter. Knowing this, we can plan the number of team members we need… NOTE: Remember to plan for different vacation schedules (i.e. in Europe a 3-4 weeks vacation is not unusual).

25. 4. Result: Good Input for the Staffing Costs and Planning Use this information to plan for training, on-boarding, and staffing This spike in resource needs is due to an overlap in the delivery schedule Now might be a good time to review that decision… Many companies plan a 60%- 40% mix of internal and external resources for a first go-live. Also, most use $50-$90 per hr for internal budgeting and $90-$170 per hr for external resources.

26. What I’ll Cover

27. Global On-Boarding and Training Don’t underestimate the value of in-house, hands-on training in addition to formal SAP training classes. It is also important to provide technical training to the team members in their own language and this is normally best done in their respective countries,

28. Effort, Duration and Mistakes on Global BI Projects Source: “Planning and improving global software development process” by Setamanit, Wakeland, Raffo, May 2006, international workshop on Global software development Recent research have demonstrated that global projects that spends more days (duration) on similar tasks, have less defects and less re-work. Since team members are more likely to work on multiple tasks not related to the project, longer durations on developing the SAP BI system does not mean more effort (i.e. work hours).

29. Global Project Risk Mitigation Strategies State 3 items in every design, budget and final deliverable: L- Limitations (what are the assumed, existing and design limitations) A - Assumptions (what assumptions are made, and what happens when these assumptions are no longer true?) R - Risks (what are the risks created by this approach, what are the impacts of failure, and how can these risks be minimized) Developers, designers and business analysts should be forced to write at least one paragraph on each of these item. It forces new thinking as well as the constant questioning of assumptions (which may not be accurate).

30. Global Project Risk Mitigation Strategies Add 15% more project time for travel and adjustments Rotate travel so that the stress is more evenly distributed on the team Plan to spend 5-10 days at the beginning of the project to level set and build trust and social networks before the real work begins. Create a formal escalation process of issues related to the project and make sure one culture does not dominate. Select a project language formally and make sure all team members are proficient in it. Spend time rewarding inter-team cooperation and create opportunities for promotion within and outside both teams (“cross pollinate”)

31. The User Acceptance Group and Its Role • Create a user acceptance team consisting of 5-7 members from the various business departments or organizations • Keep the number odd to assist with votes when decisions need to be made. With fewer than 5 members, it can be hard to get enough members present at each meeting • Make this team the focus of your requirements gathering in the early phase, then let this team perform user acceptance testing during the Realization phase • Meet with the team at least once a month during realization to refine requirements as you are building, and have something to show them This approach is hard to execute when also managing scope, but is essential to make sure that the system meets users’ requirements

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

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

34. Global SAP BI Activities, Priorities and Architecture

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

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

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

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

39. 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. 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 • Cockpits ??? • Workbooks 1,979 • Queries 3,299 • Roles 861 • MultiCubes 121 • InfoCube 605 • ODS objects 349 • InfoObjects 11,772

41. In the Blueprinting Phase: Model Your BI Solution 1. Create a model based on pre-delivered SAP NetWeaver 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

42. Accept Cultural Differences — No Culture Is Dominant! • Cultural differences should not be tolerated, but embraced • Europe has longer vacations (four to six weeks are common, not exceptions) • Family time is important — don’t plan 12-hour workdays for four months • Not everyone is equally interested in hearing how we do things in the US, Australia or England. • Many cultures find it offensive to talk about salaries, and money • Talk about value and deliverables instead • Consider a co-project manager

43. SAP BI Test Scheduling: Real 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

44. Tracking Load Performance • 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 Production Areas of BI Data Load Issues Performance Nov. 1st through Dec. 15th Demand 7 Planning Transaction - global 6 Source - Purchase 5 Orders Roughcut 4 Material Movements Number of Issues MD - Bev. 3 Packaging Master data 2 Hierarchies 1 Greycon 0 CO -line items 12/1/04 12/2/04 12/3/04 12/5/04 12/6/04 12/8/04 12/4/04 12/7/04 12/9/04 11/1/04 11/2/04 11/3/04 11/4/04 11/5/04 11/6/04 11/8/04 11/7/04 11/9/04 11/29/04 11/30/04 12/14/04 12/15/04 12/10/04 12/11/04 12/12/04 12/13/04 11/14/04 11/15/04 11/17/04 11/18/04 11/20/04 11/21/04 11/26/04 11/10/04 11/11/04 11/12/04 11/13/04 11/16/04 11/19/04 11/22/04 11/23/04 11/24/04 11/25/04 11/27/04 11/28/04

45. What I’ll Cover

46. The observation relates a company’s current BI system to normally observed configuration parameters, which serve as benchmarks to what is commonly seen at other implementations InfoCube Design — Evaluating Designs (Real Example) Cubes with many red or yellow codes should be examined KF = Key figures

47. Partitioned InfoCubes That Are No Longer the Same • Often when InfoCubes are physically partitioned, changes occur as new development and fixes are applied • After a while there is a risk that some of the physically partitioned InfoCubes no longer are identical • This can cause many issues (i.e., If archiving is used, you must ensure copies of these older datastores are maintained to be able to restore data) A real example

48. InfoCubes should be named: 0ABC_C01 or ZABC_C02 ODSs should be named: 0ABC_O01 or ZABC_O02 MultiProviders should be named: 0ABC_M01 or ZABC_M02 Naming Conventions Should Be Followed ODS = Operational Data Store

49. Performance Enhancements Are Available — Use Them • Check indexes periodically • Under RSA1 Manage Performance • Check database statistics to route queries faster • At this company, 50% of the InfoCubes had outdated database statistics that should be updated • For large InfoCubes, or cubes with many users, the percentage used to build the database statistics can be increased to 15 - 20% • May yield improved query routing

50. Performance Enhancements — Aggregates Are Often Incorrectly Built (Real Example) • Several cubes have no aggregates, while others can benefit from generating new proposals • A score above 30% for average aggregate valuations should be a target for a data store