1. © 2004 Wellesley Information Services. All rights reserved. Is your SAP BW ready for prime time? - Lessons learned from real world go-lives Dr. Bjarne Berg Lenoir-Rhyne College

2. 2 User community Is this your user community? How can you avoid this BEFORE it happens?

3. 3 What we will cover Evolutionary architectures (back and front-end) Design issues from a storage and performance perspective Complex architectures and lessons learned Testing of BW systems We will examine systems from 4 real companies and discuss 5 more throughout this presentation

4. 4 BW “post mortems” BW architectural issues at a global consumer products company A look at some BW design errors at the implementation level – a case study of a construction company More BW architectural issues – another angle of challenges through the eyes of a chemical company BW testing – what makes sense on a large BW project – a case study of a Fortune-500 manufacturing company Throughout this presentation we will also reference post implementation reviews at other companies. This include an oil and gas company, a European telecom company, a bank, an insurance company and an international materials joint venture organization. Implementation Architecture Testing More

5. 5 Architecture is Should be Based on Design This architecture is a symptom of an evolution This company started with a simple solution, but allowed the architecture to take a back seat to “quick fixes” More transforms

6. 6 A complex solution to a reporting problem Queries Query views Templates Manua l Reports Cubes Lesson Learned: Sometimes non- SAP customization creates great applications, but with poor flexibility and a high cost of ownership Changing a query has major impact, when every query is published in a pre-run view and manipulated in custom Java code

7. 7 What we will cover Evolutionary architectures (back and front-end) Design issues from a storage and performance perspective Complex architectures and lessons learned Testing of BW systems We will examine systems from 4 real companies and discuss 5 more throughout this presentation

8. 8 An Implementation view On the surface, this company appears to have a typical BW implementation with a set of InfoCubes, Multicubes and one ODS. The implementation supported five different department and had been “live” for about one year.

9. 9 Scope observations: The scope of the company's BW implementation was comprehensive and included 17 storage objects. For a first time implementation in an organization unfamiliar with BW, this might be considered a somewhat ambitious scope. In addition to this, the areas that were developed focused to a large extent on financial and project oriented detailed and integrated data. These are areas of a high degree of complexity. A closer implementation look

10. 10 Scope Recommendations In general, a more phased approach might have been beneficial to the overall success of the BW rollout. This scope management could have been accomplished by focusing on departments, or functional areas instead of a rollout of a large content area in a single phase. The multiple phases (3-6 months each) might have been short in duration and still have accomplished to have all the content available earlier that what was achieved. A closer implementation look

11. 11 What happened? In this relative complex implementation users did not get the reports they asked for. To meet the go-live date some reports went “live” with many issues, while other reports were not delivered as promised. Lessons Learned: Don’t try to cram too much in your first go-live. Consider multiple sequential, or parallel projects

12. 12 Next: a look at the technical design Just because an area is colored “red” does not mean it is wrong. However, a storage object with many red areas is worth taking a close look at.

13. 13 In general, a common BW configuration contains a set of characteristics that are used for analysis purposes. The number of these characteristics varies from implementation to implementations. Typically configurations ranges from one to forty characteristics. The design depends largely on the requirements of the business, but there are some technical tradeoffs in load times when adding a very high number of characteristics. This is particularly true when these contains large text fields that are loaded at a high frequency and at a high number of records. Characteristics

14. 14 Navigational attributes Navigational attributes lends flexibility to the way users can access data. Common configuration consists of one to thirty attributes. While technically not incorrect one should review InfoCubes that does not contain any navigational attributes. One should also review of any Infocube that contained more than thirty. This may be an indicator that too much information is being placed in a single Infocube. Hierarchies Hierarchies are ways for users to "drill-down" into the data and is commonly used for analysis purposes. Typical configurations tends to have one to eight. One should review any Infocube with no hierarchy to validate this design with end user navigation, as well as question any design that contains a very high degree of these. Technical stuff Developer quote: “The consultants told me I could not cram all this stuff into one Infocube. I told them – you just watch me!!”

15. 15 Dimensions BW allows for upto 13 dimensions to be created by a developer on a single Infocube. However, using all of these on a first implementation severely limits any future extensions without major redesign of the system (i.e. when adding more divisions to the system). One should review any InfoCubes that are approaching this limit. Key figures While no limitations are imposed by BW in terms of number of key figures (measures), typical implementations contains one to twenty of these. While a higher number of these may be required, there a are significant tradeoffs of load performance when a high number records are loaded (these are loaded with each transaction). Dimensions Lessons Learned: Don’t “paint” yourself in a corner on day one!!

16. 16 Record length In general, as the record length of an InfoSource increases, more data may be populated to the Infocube. Since an Infocube might have more that one InfoSource, the length of each may be an indicator of the Infocube growth size as the company rolls out BW to other divisions. You should review of the design of InfoSources with large record lengths to determine the true need of including all the fields in the Infocube vs. using alternate fields i.e. short text or codes, or removing them from the system.. Record Length Lessons Learned: Don’t throw in the “kitchen sink” because it might come in handy one day…..

17. 17 Data Loads When fixing data load problems, narrow the problem down quickly and focus on these areas. Lessons Learned: Spend your time and effort in a focused manner!!

18. 18 Performance Before redesigning queries, take a look at the performance options of BW. BW have many features that can be leveraged. This company did a somewhat mixed job in this area. Lessons Learned: Cover the basics first before you go “fancy”!!

19. 19 How could they fix their system? This company had major issues, but first it needed an upgrade to take advantage of the improved ODS (the company was still on version 2.0b) Lessons Learned: Don’t be afraid to get better tools before you attack a problem..

20. 20 Not everything has to be fixed… Leverage what you have and focus on the critical areas. Not everything has to be fixed Lessons Learned: Don’t throw the “kids” out with the bath water!!!

21. 21 What we will cover Evolutionary architectures (back and front-end) Design issues from a storage and performance perspective Complex architectures and lessons learned Testing of BW systems We will examine systems from 4 real companies and discuss 5 more throughout this presentation

22. 22 First, only one cube existed consisted of actual, plan and historical data. A MultiCube was built from 9 customized basic cubes. 1 Infocube for Actuals 4 InfoCubes for Current Plan Month for different versions 4 InfoCubes for Plan Last Month for different versions. No reports ran against the basic cubes. All reporting was done via the multicube. Integrated profitability at chemical company

23. 23 Integrated profitability at chemical company This architecture is a result of “best intentions” and not much foresight. An ODS might have served the company better than a large number of InfoCubes with the same data Lessons learned: “Everything in the world is a nail when you only use a hammer” This was intended to be a “scalable” solution

24. 24 Integrated profitability at chemical company Each of the nine cubes is large and have many objects and lots of daily data.. This architecture was partly intended to solve load problems, however BW version 3.x might have solved the problem through use of parallel loads

25. 25 BW Security The security structure in place was not adequate, and was limited to only SAP logon restriction. The data was not restricted on any organizational level. Users could view any data present in the Cost and Profitability InfoCubes. There were approximately 100 users with access to corporate profitability Since this company is publicly traded this is not only a design problem, it is also a possible SEC issue

26. 26 Integrated profitability at chemical company What Happened? Some queries was running longer than the older R/3-COPA environment, due partly to heavy use of currency and other calculations on the front-end. Users were very unhappy !!! The fixes….. Implement an ODS supported architecture For query optimization, key figures can be pre-calculated during load instead of created-on-the-fly on reports. Leverage the OLAP cache for better response time during querying. Aggregates can also improve reporting execution time. 293 queries – many ran in 3-8 minutes

27. 27 What we will cover Evolutionary architectures (back and front-end) Design issues from a storage and performance perspective Complex architectures and lessons learned Testing of BW systems

28. 28 A look at some testing a manufacturing company System Test Integration Test Cycle 1 Integration Test Cycle 2  Load test  Stress test  Performance tuning We assume that unit test is done during development

29. 29 BW Testing – The BIG PICTURE This company plans for adequate time between testing and go-live

30. 30 Scope & Importance – a Manufacturing company Scope by Business Tracks  The testing effort of the queries and reports was organized around the Business Tracks Since the company goes live with R/3 at the same time, this organization allows the BW teams to conduct integration tests with the process teams

31. 31 Testing: Organization and Work Too often BW is treated as a “step child” to R/3 and real testing is executed “when possible”. However, BW testing is a formal process and should have formally assigned resources and formally assigned tasks. A manufacturing company

32. 32 System Test Cycle 2 - Milestones The BW system testing started behind the R/3 testing  The BW teams developed queries and data stores while the process teams conducted system test cycle-1.  This allowed the BW team to refine requirements and to work on better data in system test cycle-2. "There's no time to stop for gas, we're already late"

33. 33 The Schedule…. Each team had dedicated time in the test room. Food was provided (pastry, doughnuts etc). At least 2 testers (normally 3) was assigned to each query All test results was logged in a Lotus Notes database "If you didn't write it down, it didn't happen." A manufacturing company

34. 34 Test Progress Monitoring and Reporting This company planned two types of meeting during system testing: –Progress Meeting –Escalation Meeting Progress Meeting Was held daily to monitor progress and resolve common issues – Business Analysts met with the development team. Other attendees included the test coordinator and the Test Problem Resolution (TPR) administrator, Purpose: Discuss common issues, Monitor progress, Discuss any change in plans, Duration: 30 minutes A manufacturing company

35. 35 Escalation Meeting Held weekly, or as required, to resolve open items that impacts multiple tracks Other attendees include test coordinator, and the Test Problem Resolution (TPR) administrator, Purpose: Discuss open issues, and take necessary action to speed up process, Resource allocation for escalated issues, Duration: 30 minutes Test Progress Monitoring and Reporting A manufacturing company

36. 36 Integration Test Cycle 2 – Load test execution Load test execution  Load for load test –20% of actual users (not named users)  Schedule queries to run in background  Execute each query while eCATT scripts are running  Monitor BW system continuously  Record findings in Lotus Notes database  Meet daily with development team to resolve progress A manufacturing company

37. 37 Integration Test Cycle 2 – Stress test execution Stress test execution  Identify queries to be load tested  Determine cutoff load for load test –40% of actual users  Schedule queries to run in background  Execute each query while eCATT scripts are running  Monitor BW system continuously  Record findings in Lotus Notes database  Meet daily with development team to resolve issues A manufacturing company

38. 38 Integration Test Cycle 2 – Performance tuning Performance test execution  Identify queries to be performance tuned  Attempt tuning at query level  Perform analysis based on benchmarks  Build aggregates, indexes, etc if needed  Record findings in Lotus Notes database  Meet daily with development team to resolve issues Keep this focused!!! Not all queries needs to run in 3 seconds..

39. 39 Resources “Mastering the SAP Business Information Warehouse” Kevin McDonald et. al. chapter 10: “Performance Planning and Management” ISBN 0-471-21971-1 ERP and Data Warehousing in Organizations: Issues and Challenges by Gerald G. Grant ISBN: 1-931-77749-7 http://help.sap.com -- The SAP Help Portal. This is a great place to get access to the lastest and greatest from a documentation perspective.

40. 40 Spend some time thinking consciously about data architecture, and develop a formal “to-be” system diagram. Make all designs pass a review board, question overly complex designs or “work-arounds”. The tool has a high learning curve and training cannot substitute for experience. Plan on spending 10-15% of overall effort on performance tuning of queries and data loads. 7 Key Points to Take Home

41. 41 Do not attempt to “cram” all data into one cube. Keep InfoCubes logically organized and use multi- provider queries as needed. Do not succumb to using BW as a dumping ground, some reports belongs in R/3. Be very wary of evolutionary architectures. Be flexible, but create some “hard rules” that cannot be overridden by “quick fixes”. A line support organization should be established and be part of the development effort (knowledge transfer). 7 Key Points to Take Home

42. 42 Your Turn! Dr. Bjarne Berg bergb@lrc.edu