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

© 2004 Wellesley Information Services. All rights reserved.

Is your SAP BW ready for prime time?

- Lessons learned from real world go-lives

Dr. Bjarne BergLenoir-Rhyne College

2

User community

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”

• 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

Architecture

Testing

More

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”

SAP(Cost Center,

Product Costing,

Activity Based Costing)

PSA ODS

Flatfile1066B

1066BReports

ZABC

PC_C01

CCA_C11

ReportsCRD

More transforms

6

A complex solution to a reporting problem

Queries

Query views

Templates

Manual

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

Warning

7

What we will cover






8

Number of BW storage objects

17

21

InfoCubes

Multicubes

ODS

Morrison HomesAvailable options ZOP_C01Jobcost details multicube ZMCJOBCOSJobcost history cube ZJC_C01Options sold ZOP_C02Pending close multicube (new) ZSDPSMC03Finance departmentMH AP line item cube ZAP_C01MH AR line item cube ZAR_C01MH general ledger cube ZARC01General ledger line item ODS ZGL_O01Purchasing/estimation departmentCost cube ZMM_C01MH property master (LOT) cube ZPM_C01Purchasing item data ZPU_C01Construction departmentInventory cube ZPS_C04Inventory multicube ZMCINVC01PS controlling MH ZPS_C01PS dates MH ZPS_C02PS controlling and dates cube ZPS_C03Sales departmentEarnest money estimation cube ZSD_C03MHSD overview ZSD_C01SD commissions cube ZSD_C02

InfoCubes in BW (as of 4/1/03)

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

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

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

Report Status (per BW Team Lead)

Outstanding reports, 2

Reports with issues, 5

In production no issues,

15

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

Within typical design parametersApproaching recommended regular configuration parametersNot frequently used design parameters

Ledger

Infocubes Characteristics Navigational attributes

Time char-acteristics

Hierarchies Dimensions Key figures Record length

Complexity

Available options 20 4 4 2 9 4 Moderate ModerateJobcost history cube 57 0 1 0 12 1 High HighOptions sold 23 19 4 1 11 14 Low LowMH AP line item cube 52 13 4 3 10 15 High HighMH AR line item cube 29 0 4 1 8 20 Low LowMH general ledger cube 30 2 5 6 8 9 Low LowCost cube 14 0 3 2 8 2 Low LowMH property master (LOT) cube 24 2 4 1 11 7 Low LowPurchasing item data 13 10 5 3 11 15 Low LowInventory cube 33 4 2 3 9 23 Low LowPS controlling MH 44 37 5 10 12 35 Moderate HighPS dates MH 25 19 5 4 8 17 Low ModeratePS controlling and dates cube 34 48 3 5 9 30 Low HighEarnest money estimation cube 40 24 5 7 13 16 Moderate HighMHSD overview 49 28 5 7 13 27 High HighSD commissions cube 51 22 4 4 10 21 High High

BW InfoCubes Observations

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.

Note

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.

Infocubes Characteristics Navigational attributes

Time char-acteristics

Hierarchies Dimensions Key figures Record length

Complexity

Available options 20 4 4 2 9 4 Moderate ModerateJobcost history cube 57 0 1 0 12 1 High HighOptions sold 23 19 4 1 11 14 Low LowMH AP line item cube 52 13 4 3 10 15 High HighMH AR line item cube 29 0 4 1 8 20 Low LowMH general ledger cube 30 2 5 6 8 9 Low LowCost cube 14 0 3 2 8 2 Low LowMH property master (LOT) cube 24 2 4 1 11 7 Low LowPurchasing item data 13 10 5 3 11 15 Low LowInventory cube 33 4 2 3 9 23 Low LowPS controlling MH 44 37 5 10 12 35 Moderate HighPS dates MH 25 19 5 4 8 17 Low ModeratePS controlling and dates cube 34 48 3 5 9 30 Low HighEarnest money estimation cube 40 24 5 7 13 16 Moderate HighMHSD overview 49 28 5 7 13 27 High HighSD commissions cube 51 22 4 4 10 21 High High

BW InfoCubes Observations

CharacteristicsJust 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.Note

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!!”

ClientIssue

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

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

Data Loads

Infocubes Number ComplexityAvailable options 1 LowJobcost details multicube* 2 LowJobcost history cube 1 HighOptions sold 1 ModeratePending close multicube (new)* 2 LowMH AP line item cube N/A HighMH AR line item cube 1 ModerateMH general ledger cube 1 LowGeneral ledger line item ODS 2 HighCost cube 1 LowMH property master (LOT) cube 1 LowPurchasing item data 1 LowInventory cube 2 ModerateInventory multicube* 2 LowPS controlling MH 5 HighPS dates MH 1 ModeratePS controlling and dates cube 4 HighEarnest money estimation cube 1 ModerateMHSD overview 2 HighSD commissions cube 1 Moderate

BW Sources to InfoCubes/ODS and MultiCubesSources 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

Indexes BW index diagnosticStatistics BW diagnostic of statistics that is recommended to be updatedAggregates User designed aggregates (performance & existence)

Ledger

Performance

Morrison Homes Indexes Statistics AggregatesAvailable options Pass Pass NoneJobcost history cube Pass Yellow NoneOptions sold Pass Yellow NoneFinance department Indexes Statistics AggregatesMH AP line item cube Pass Yellow NoneMH AR line item cube Pass Yellow NoneMH general ledger cube Pass Yellow NonePurchasing/estimation dept. Indexes Statistics AggregatesCost cube Pass Pass NoneMH property master (LOT) cube Pass Yellow NonePurchasing item data Pass Pass NoneConstruction department Indexes Statistics AggregatesInventory cube Pass Yellow NonePS controlling MH Pass Pass NonePS dates MH Pass Pass NonePS controlling and dates cube Pass Pass NoneSales department Indexes Statistics AggregatesEarnest money estimation cube Pass Pass NoneMHSD overview Pass Pass NoneSD commissions cube Pass Yellow None

InfoCubes Performance observations (as of 4/1/03)

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

High-Level tasksWeek

1Week

2Week

3Week

4Week

5Week

6Week

7

Copy BW existing system to new test environmentDevelop test casesExecute and document base test results from old environmentUpgrading the previous BW release on the new test environmentConduct regression testing of existing BW content (test cases)Conduct stress test of the existing queries and processes impactedAssemble a detailed assessment of impacts of upgrade Formal review session of upgrade test results and approval to progress.Backup of production environment and contingent recovery planningUpgrading of the production environment and testingFinal sign-off and approvals

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…

InfoCube Tech name Redesign Level Suggested approach*Available options ZOP_C01 No N/AJobcost details multicube ZMCJOBCOS Yes High Redo (AP not in production today)Jobcost history cube ZJC_C01 Yes Moderate Reporting ODS Options sold ZOP_C02 No N/APending close multicube (new) ZSDPSMC03 Yes Low Redo based on new ZSD_C01 in ODS MH AP line item cube ZAP_C01 Yes Moderate To be devloped (not in production today)MH AR line item cube ZAR_C01 No N/AMH general ledger cube ZARC01 No N/AGeneral ledger line item ODS ZGL_O01 No N/ACost cube ZMM_C01 No N/AMH property master (LOT) cube ZPM_C01 No N/APurchasing item data ZPU_C01 No N/AInventory cube ZPS_C04 No N/AInventory multicube ZMCINVC01 No N/APS controlling MH ZPS_C01 Yes High Reporting ODS PS dates MH ZPS_C02 No N/APS controlling and dates cube ZPS_C03 Yes Moderate To be determinedEarnest money estimation cube ZSD_C03 Yes High Reporting ODS MHSD overview ZSD_C01 Yes High Reporting ODS SD commissions cube ZSD_C02 Yes Moderate To be determined

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






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

GOTCHA!

23

SAP R/3

CE1DU01CE2DU02

Profitability Analysis

PSA

Reports

ZCOPA_V00

ZCOPA_V01

ZCOPA_V02

ZCOPA_V03

ZCOPA_V04

ZCOPA_V1H

ZCOPA_V2H

ZCOPA_V3H

ZCOPA_V4H

ZCOPA_MLT

FlatfilePlan & Actual


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


Each of the nine cubes is large and have many objects and lots of daily data..

LowHigh102461373148ZCOPA_V3H

LowMedium102461373148ZCOPA_V04








ComplexityVolumeKey Figures

Unit Characteristics

Time Characteristics

DimensionsNavigational Attributes

CharacteristicsTechnical










ComplexityVolumeKey Figures

Unit Characteristics

Time Characteristics

DimensionsNavigational Attributes

CharacteristicsTechnical

33413341ZCOPA_V04

6170680926ZCOPA_V03

614070629798ZCOPA_V02

725314747698ZCOPA_V01

Records Added

Records Transferred

Infocube

33413341ZCOPA_V04

6170680926ZCOPA_V03

614070629798ZCOPA_V02

725314747698ZCOPA_V01

Records Added

Records Transferred

Infocube

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


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 !!!>46

>85

>231

>224

>203

>426

>158

Avg db (sec)

18Consolidated>192XXXXXX_06

620Detail>500XXXXXX_01






No of output records

OutputAvg time (sec)

Query

>46

>85

>231

>224

>203

>426

>158

Avg db (sec)


620Detail>500XXXXXX_01






No of output records

OutputAvg time (sec)

Query

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

What we will cover





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

Q: How many testers does it take to change a light bulb?

A: Testers don't change anything. They just report that it's dark.

Q: How many testers does it take to change a light bulb?

A: Testers don't change anything. They just report that it's dark.

We assume that unit test is done during

developmentNote

29

BW Testing – The BIG PICTURE

Building Block

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

ProcurementDemand PlanningManufacturing ProcessPlanning & SchedulingDeliverOrderFinancials

In ScopeBusiness Track

ProcurementDemand PlanningManufacturing ProcessPlanning & SchedulingDeliverOrderFinancials

In ScopeBusiness Track

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

T e st an d Q u a lityM a na g er

T e st Co o rd in a to rs T e am Le a ds

O th e r R e sou rces(P ro ce ss T e a m s)

T e st P la n nin g Co o rd in a to rs

P ro ce ss M a na g e m e nt Test Strategy

Test Plan

Test Execution

Problem Resolution

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.

Don't Forget

A manufacturing company

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.

Tasks\Dates December 2003 January 2004 February 2004 1-Mar 8-Mar 15-Mar 22-Mar 29-Mar 5-Apr

Identify People for Testing

Schedule Facilities

Prioritize Test Areas (Queries)

Send out Meeting Notice

Execute System Test

Document Results

Problem Resolution

112

2

3

45

67

8

9

10

11

Timing

"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

3/1

3/2

3/3

3/4

3/5

3/6

3/7

3/8

3/9

3/1

0

3/1

1

3/1

2

3/1

3

3/1

4

3/1

5

3/1

6

3/1

7

3/1

8

3/1

9

3/2

0

3/2

1

3/2

2

3/2

3

3/2

4

3/2

5

3/2

6

3/2

7

3/2

8

3/2

9

3/3

0

3/3

1

4/1

4/2

DeliverCost and ProfitabilityOrderManufacturingPlan and schedulingDemand planningSource

Resolving outstanding

issues and re-testing

= Morning session 8:30 - noon= Evening session 12:30 - 5:00

Environment preparation

"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

Progress MeetingWas 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 minutesSolutionA manufacturing company

35

Escalation MeetingHeld 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

Solution

Test Progress Monitoring and Reporting


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

Note


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

Note


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

http://images.google.com/imgres?imgurl=www.geocities.com/whunt171/stress.jpg&imgrefurl=http://www.geocities.com/whunt171/HypnoticSolutionsstress.html&h=411&w=490&prev=/images%3Fq%3Dstress%2Bimage%26start%3D120%26svnum%3D10%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26sa%3DN

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.

http://www.amazon.com/gp/reader/1931777497/ref=sib_dp_pt/002-5938751-8852820

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

Tip

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

Warning

42

Your Turn!

Dr. Bjarne [email protected]

Documents

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