1. Dr. Bjarne Berg Lenoir-Rhyne College
Is your SAP BW ready for prime time? - Lessons learned from real world go-lives
Dr. Bjarne Berg
Lenoir-Rhyne College

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

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. BW “post mortems”
Architecture
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. Architecture is Should be Based on Design
This architecture is a symptom of an evolution
More transforms
This company started with a simple solution, but allowed the architecture to take a back seat to “quick fixes”

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

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. 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. A closer implementation look
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.

10. A closer implementation look
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.

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

14. Technical stuff 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.
Developer quote: “The consultants told me I could not cram all this stuff into one Infocube. I told them – you just watch me!!”

15. Lessons Learned: Don’t “paint” yourself in a corner on day one!!
Dimensions
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).
Lessons Learned: Don’t “paint” yourself in a corner on day one!!

16. Record Length 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..
Lessons Learned: Don’t throw in the “kitchen sink” because it might come in handy one day…..

17. Lessons Learned: Spend your time and effort in a focused manner!!
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. Lessons Learned: Cover the basics first before you go “fancy”!!
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. 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. 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. 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. Integrated profitability at chemical company
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.

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

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. 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. 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 !!!
293 queries – many ran in 3-8 minutes
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.

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. 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. BW Testing – The BIG PICTURE
This company plans for adequate time between testing and go-live

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. Testing: Organization and Work
A manufacturing company
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.

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. 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. Test Progress Monitoring and Reporting
This company planned two types of meeting during system testing:
Progress Meeting
Escalation 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. Test Progress Monitoring and Reporting
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
A manufacturing company

36. Integration Test Cycle 2 – 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. Integration Test Cycle 2 – 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. 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. Resources
“Mastering the SAP Business Information Warehouse” Kevin McDonald et. al. chapter 10: “Performance Planning and Management” ISBN
ERP and Data Warehousing in Organizations: Issues and Challenges by Gerald G. Grant ISBN:
The SAP Help Portal. This is a great place to get access to the lastest and greatest from a documentation perspective.

40. 7 Key Points to Take Home
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.

41. 7 Key Points to Take Home
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).

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