a comprehensive guide to plan, manage, and execute a successful sap bw implementation project

© 2006 Wellesley Information Services. All rights reserved.

A Comprehensive Guide To Plan, Manage, and Execute a Successful SAP BW Implementation Project – Part 2

Bjarne BergMyITgroup

2

What We’ve Covered So Far (in Part 1)…

• Writing your SAP BW business case • Defining the scope of your implem• entation• Writing a milestone plan• Developing your staffing plan• Budgeting• On-boarding and training• Writing your workplan• Monitoring the progress of your project• Monitoring quality / instituting a formal approval process• Why you need an SAP BW “user acceptance group”

3

What We’ll Cover Now (In Part 2)…

• Final Preparatory steps Methodology details Lessons learned Requirements and approvals

• The Blueprinting Phase• The Realization Phase• The Implementation Phase• Wrap-up

4

What We’ll Cover…

• Final Preparatory steps Methodology Lessons learned Requirements and approvals

• The Blueprinting Phase• The Realization Phase• The Implementation Phase• Wrap-up

5

Project Preparation: Some Key Observations

Core Activities

1.1 Initial Project Planning1.2 Project Procedures1.3 Training Preparation

1.4 Project Kickoff

1.5 Technical Requirements Planning1.6 Quality Check Project Preparation

Project plan: This is the first cut. It focuses on milestones and work packages.

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.

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

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.

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…

Note

6

What is ASAP?

• Project Plan, Estimating

• Design Strategies, Scope Definition

• Documentation, Issues Db

• Workshop Agenda

• Questionnaires

• End-User Procedures

• Test Plans

• Technical Procedures

• Made Easy guidebooks (printout, data transfer, system administration…)

Fill in the BlankVersus

Start from Scratch

Fill in the BlankVersus

Start from Scratch

Examples for Accelerators:

7

The ASAP Approach (from Part-1)

Create Functional

specs

Peer Review

Complete?

Complete?

Peer Review

Complete?

Complete?Structured

walkthrough

Approved?

Configuration

Unit Testing

Integration

Testing

System Testing

Structured

walkthrough

Approved?

No

No

No

No

No

Yes

Yes

Yes

Yes

Yes

Yes

No

Create Technical

specs

8

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

Activate standard content

Review data quality issues

Create 2-3 sample queries

Load infocubeUser

acceptance session

Request for modifications

In-

scope?

Rejection

In-future

scope?

Make enhancements

Test

Deploy

Yes

No

No

9

Critical Success Factors for SAP BW Projects

Source: Lee Schlenker

These are lessons learned the hard way… Don’t re-invent the wheel--learn from others.

Note

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

Single location 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

10

SAP Solution Manager

Source: SAP AG

Service Delivery Platform

SAP Support

Services

Best Practice Documents

Implementation Content

Roadmaps

Test Organizer Support Desk

Solution Monitoring

Service Level Reporting

Customizing Synchronization

Implementation Platform

Gateway to SAP

Landscape Reporting

Tool

Content

e-Learning

Upgrade ProjectsChange Request

ManagementNew inNew in20042004

Was added in 2004

11

SAP BI Best Practices

• This tool is still being enhanced, but has several BI-specific project accelerators that you won’t find in SAP Solution Manager

A test drive is available on the Web site: https://media.sdn.sap.com/html/submitted%5Fdocs/Best%5FPractices/BW/


Most of the project management tools about staffing, planning, scoping, and work plans are found here

Most of the project management tools about staffing, planning, scoping, and work plans are found here A test drive is available on the Web site:

https://media.sdn.sap.com/html/submitted%5Fdocs/Best%5FPractices/BW/




12

Many of your team’s deliverables can be downloaded here and you can incorporate them specifically

into your work plans

Many of your team’s deliverables can be downloaded here and you can incorporate them specifically

into your work plans

Option – Workplans Based on Deliverables

• The best practice documents are organized around scenarios, which simplify the collection of tools

13

SAP BI Best Practices – What Versions Does It Support?

• The SAP Best Practices tool was developed for SAP BW 3.5, and was tested with:

While the install recommendations are based on SAP BW 3.5, most management tools, accelerators, and the sample work plan are not version-specific

While the install recommendations are based on SAP BW 3.5, most management tools, accelerators, and the sample work plan are not version-specific

mySAPApplication Component

Software Component

Release Level Highest Support Package

SAP BW SAP_BASIS 640 0004 SAPKB64004

SAP_ABA 640 0004 SAPKA64004

SAP_BW 350 0004 SAPKW35004

PI_BASIS 2004_1_640 0004 SAPKIPYI64

BI_CONT 352 0002 SAPKIBIEP2

Note

Source: SAP - Sept - 2005

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, and provide lunch on-site

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

15


• Final Preparatory steps• The Blueprinting Phase

Leveraging the standard content Modeling your solution Deliverables

• The Realization Phase• The Implementation Phase• Wrap-up

16

Don't Forget

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 inforequestsbusiness input

Gather information using the tool

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

Name Organization Phone NumberJoeJones MYORG Ltd 918-123-1234Joseph Jones Your ORG Ltd 918-123-1234JoeJones MYORG Ltd 123-123-1234JoeJones MYORG Ltd 918-123-1234JoeJones MYORG Ltd 918-123-1238Joseph Jones Your ORG Ltd 918-123-1239JoeJones MYORG Ltd 918-123-1234JoeJones MYORG Ltd 918-123-1234JoeJones MYORG Ltd 918-123-1234Joseph Jones Your ORG Ltd 918-123-1234JoeJones MYORG Ltd 918-123-1234Joseph Jones Your ORG Ltd 918-123-1234JoeJones MYORG Ltd 123-123-1234

Name Organization Phone NumberJoeJones MYORG Ltd 918-123-1234Joseph Jones Your ORG Ltd 918-123-1234JoeJones MYORG Ltd 123-123-1234JoeJones MYORG Ltd 918-123-1234JoeJones MYORG Ltd 918-123-1238Joseph Jones Your ORG Ltd 918-123-1239JoeJones MYORG Ltd 918-123-1234JoeJones



Name Organization Phone NumberJoeJones MYORG Ltd 918-123-1234Joseph Jones Your ORG Ltd 918-123-1234JoeJones MYORG Ltd 123-123-1234JoeJones MYORG Ltd 918-123-1234JoeJones MYORG Ltd 918-123-1238Joseph Jones Your ORG Ltd 918-123-1239JoeJones MYORG Ltd 918-123-1234JoeJones


Team starts by reviewing documentation tool fordocumentation completeness

D1Is reportdocumentationcomplete?

Request additionalinput from BusinessTeam member

ResponsibleTeam memberacquires/documentsadditional information

D2Is thisan Intradayreport?D3Significantnumberof users?

D4Is the reportsystemresourceintensive?

D5DoesStandard R/3contentexist?D6DoesStandard BWcontentexist?D7Is it lessexpensive tocreate inR/3?

R/3is selected asReporting Tooland documentedin doc. toolBWis selected asReporting Tool anddocumented in doc.tool

BWis selected asReporting Tooland documentedin the documentation toolBWis selected asreporting tool and ChangeRequest is submitted ifthe scope changed

R/3is selected asReporting Tooland documentedin doc. toolR/3is selected asReporting Tooland documented

No

Yes

No NoYes

Yes

YesNo

YesNo

D2.5Does data existin "in-scope" modelsInfocube/ODS No

Yes

No

D1aIs this a truereportingneedYes

No Communicate tobus. leader

A2Total Cost ofOwnershipAnalysisD8Is BW costeffective?

Yes

No

Yes Yes

R/3is selected asReporting Tooland documentedin doc. tool

D9R/3 ToolSelectionProcessNo

BWis selected asReporting Tool anddocumented in doc.tool

StandardR/3ABAP/CustomReportWriter

OtherQuery

Review requirements and identifycorresponding Data Model (InfoCube/ODS)

Communicate finaldisposition

Communicate finaldispositionCommunicate finaldispositionCommunicate finaldisposition


R/3 team make final disposition

Communicate finaldispositionCommunicate finaldisposition

BW Team to forward completed detailed report specifications based on selected Reporting Tool -BW or R/3

A3Sub-Process Report Consolidation &eliminate if appropriate (winnowing)

A4Baseline reports











No

Yes

No NoYes

Yes

YesNo

YesNo


Yes

No




Yes

No

Yes Yes


D9











No

Yes

No NoYes

Yes

YesNo

YesNo


Yes

No




Yes

No

Yes Yes





OtherQuery









A4Baseline reports











No

Yes

No NoYes

Yes

YesNo

YesNo


Yes

No












No

Yes

No NoYes

Yes

YesNo

YesNo


Yes

No




Yes

No

Yes Yes





OtherQuery









A4Baseline reports





D2Is thisan Intradayreport?



Yes

No

Yes Yes





OtherQuery









A4Baseline reports











No

Yes

No NoYes

Yes

YesNo

YesNo


Yes

No




Yes

No

D3Significantnumberof users?D4Is the reportsystemresourceintensive?





No

Yes

No NoYes

Yes

YesNo

YesNo


Yes

No




Yes

No

Yes Yes


D9











No

Yes

No NoYes

Yes

YesNo

YesNo


Yes

Yes Yes


D9











No

Yes

No NoYes

Yes

YesNo

YesNo


Yes

No




Yes

No

Yes Yes





OtherQuery









A4Baseline reports











No

Yes

No NoYes

Yes

YesNo

YesNo


Yes

No




Yes

No

Yes Yes





OtherQuery









A4Baseline reports











No

Yes

No NoYes

Yes

YesNo

YesNo


Yes

No




Yes

No

Yes Yes


D9











No

Yes

No NoYes

Yes

YesNo

YesNo


Yes

No




Yes

No

Yes Yes





OtherQuery









A4Baseline reports











No

Yes

No NoYes

Yes

YesNo

YesNo


Yes

No












No

Yes

No NoYes

Yes

YesNo

YesNo


Yes

No




Yes

No

Yes Yes





OtherQuery









A4Baseline reports





D2Is thisan Intradayreport?



Yes

No

Yes Yes





OtherQuery









A4Baseline reports











No

Yes

No NoYes

Yes

YesNo

YesNo


Yes

No




Yes

No

D3Significantnumberof users?D4Is the reportsystemresourceintensive?





No

Yes

No NoYes

Yes

YesNo

YesNo


Yes

No




Yes

No

Yes Yes


D9











No

Yes

No NoYes

Yes

YesNo

YesNo


Yes

Yes Yes


D9











No

Yes

No NoYes

Yes

YesNo

YesNo


Yes

No




Yes

No

Yes Yes





OtherQuery









A4Baseline reports

17

Getting the Functional Specifications

• Avoid taking a total inventory of all reports in the organization. The "top-5" (most used) sales, distribution, inventory etc. reports from each department will cover the vast majority of the reporting needs.

• A single SAP BW "report" may satisfy dozens of today's static reports. It is therefore impossible to map each individual legacy report to a single BW report.

Avoid attempting to replicate each report based on what you might have in place today. Accept new ways of accessing data.

Best Practice

Note

18

Getting the 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)

Tip

19

• Document requirements in a standardized format

• Prioritize requirements

• Consolidate requirements

• Support follow-up discussions and reviews.

P1 of 2

Tool

Sample Info Request Form:

20

• 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 security requirements, or add a separate section for this.

Note the section for dispositioning the requirement

P2 of 2

Tool

Sample Info Request Form:

21

An Example

22

An Example

23

Consider Multiple Ways 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• Print• Form based• Static• Predictable access

OLAP Reporting• Drill Down• Slice and Dice• Analyse• Data Mining • Search and discover

KPI & Scorecard Formatted• Simple• Easy to view• Limited nav• Aggregates

Don't underestimate users’ need to access the information in various ways.

OR OR

24

Blueprinting Phase: Some Key Observations

Core Activities

2.1 Project Management Business Blueprint

2.2 Organizational Change Management

2.3 Project Team Training Business Blueprint2.4 Develop System Environment2.5 Organizational Structure Definition

2.6 Business Process Definition2.7 Quality Check Business Blueprint

Deciding what will be developed in SAP BW and what will be maintained as R/3 reports.

Deciding what will be developed in SAP BW 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.

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.

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

Create detailed technical specifications and designs of infocubes, masterdata, ODSs, and high-level architectural designs.

25

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

Warning

26

Key Questions for Report Dispositioning

• Is this really a reporting need, or a "want"?• Is the data going to be in SAP BW at a frequency that solves

the user's request (e.g., intraday reporting)?• Is the data needed for this report already in our SAP BW

scope?• Is there already a report available in R/3?• Does standard BW 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 BW cost effective in the long run (ownership)?

27

cu

Team starts by reviewing documentation tool for documentation completeness

D1Is report

documentation complete?

Request additional input from Business

Team member

Responsible Team member

acquires/documents additional information

D2Is this

an Intraday report?

D3Significant

numberof users?

D4 Is the report

system resource

intensive?

D5Does

Standard R/3contentexist?

D6Does

Standard BWcontentexist?

D7Is it less

expensive tocreate in

R/3?

R/3 is selected asReporting Tool

and documentedin doc. tool

BW is selected asReporting Tool anddocumented in doc.

tool

BW is selected asReporting Tooland documented

in the documentation tool

BW is selected asreporting tool and ChangeRequest is submitted ifthe scope changed




and documented

No

Yes

No

No

Yes

Yes

Yes

No

Yes

No

D2.5 Does data exist

in "in-scope" modelsInfocube/ODS

No

Yes

No

D1a Is this a true

reportingneed

Yes

NoCommunicate tobus. leader

A2Total Cost ofOwnership

Analysis

D8Is BW costeffective?

Yes

No

YesYes



D9R/3 ToolSelectionProcess

No

BW is selected asReporting Tool anddocumented in doc.

tool

StandardR/3

ABAP/Custom

ReportWriter

OtherQuery










BW Team to forward completed detailed report specifications based on selected Reporting Tool - BW or R/3


A4 Baseline reports

Tool

An example of how to decide which reports should be in R/3 or the legacy system (refer to printed version)

28

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

+ + =Great

Feature

Many requirements can be met by a single SAP BW report

29

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):BW Content available (3.5.1):

• Cockpits ???• Workbooks 1,979• Queries 3,299• Roles 861• MultiCubes 121

• InfoCube 605• ODS objects 349• InfoObjects 11,772

36%

33%

31%

Mostly standard storage objectsSome customization

Highly customized storage objects

An example from a large manufacturing company

30

Billing

Number of billing documentsNumber biling line itemsBilled item quantityNet weightSubtotal 1Subtotal 2Subtotal 3Subtotal 4Subtotal 5Subtotal 6Subtotal ANet valueCostTax amountVolume

Customer

Sold-toShip-toBill-toPayerCustomer classCustomer group~ Customer country~ Customer region~ Customer postal code~ Customer industry code 1End user

Material

Material numberMaterial enteredMaterial groupItem categoryProduct hierarchyEAN/UPC

Time

Calendar yearCalendar monthCalendar weekCalendar day

Unit

Currency KeyUnit of MeasureBase unit of measureSales unit of measureVolume unit of measureWeight unit of measure

Billing information

Billing documentBilling itemBilling typeBilling categoryBilling dateCreation dateCancel indicatorOutput medium~ Batch billing indicatorDebit/credit reason codeBiling categoryReference documentPayment termsCancelled billing documentDivison for the order headerPricing procedure

Organization

Company codeDivisionDistribution channelSales organizationSales group

Logistics

PlantShipping/receiving point

Document details

Sales order document typeSales dealSales docuement

Accounting

Cost centerProfit centerControlling areaAccount assignment group

Personnel

Sales rep number

LEGEND

Delivered in standard extractorsDelivered in LO extractorNot in delivered Content -but in R-3

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

31

Approximate Usage of Standard Content BW 3.5 (percentage of overall development effort)

0

20

40

60

80

100

* Rapidly improving content

Standard Content Vs. Customization

• All functional areas are not equally supported by strong standard SAP BW 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.

32


• 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

33

Realization Phase: Some Key Observations

Core Activities

3.1 Project Management Realization

3.2 Organizational Change Management

3.3 Training Realization3.4 Baseline Configuration and reviews3.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 Queries3.10 Develop User interface enhancements3.11 Determine additional reporting requirements3.12 Create structured reports3.13 Establish Authorization Concept3.14 Establish Data Archiving plan (if applicable)3.15 Final Integration Test3.16 Quality Check Realization

Configuration and Testing Plans: Define how the configuration will be implemented and how it will be tested

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

Development Programs: Provide details of added programming structures

End User Training MaterialEnd User Training Material


34

Building ODSs and InfoCubes

1 Review the functional requirements and technical design

6 Do not allow exceptions to your naming conventions

2 Make sure you have established Data Stewards for master data, and assignmaster data to specific developers

7 Make sure that “putting out fires” does not take precedence, becoming the“default” architecture and standard.

3 Have your ETL developers work for the individual who is responsible

for creating process chains (organizationally)

8 Try new ideas in a sandbox environment ,and don’t contaminate the development environment.

4 Avoid nested ODS layers, and keep the architecture as pristine as possible

9 Keep details for multi-use in the ODS and do not design the ODS based on the needs of a single infoCube.

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

10 Developers must unit test all of their work and personally sign-off on their storage object.

TIPS

35

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 BW project, 40-60% of project effort will be spent on data integration, transformation, and loads

Source SAP AG

36

The SAP BW Test Methodology

Methodology used for System and Integration tests…

Test Strategy

Test Plan

Test Execution

Problem Resolution

SAP R/3 and BW testing is not different from a methodology standpoint, but the execution is….

37

System Test: Planning

Activities

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

1 Create test script 6 Identify key contacts 2 Identify roles to be used 7 Communicate about transports3 Documentation on using test tools 8 Arrange time for progress control4 Procedure for documenting test results 9 Schedule facilities5 Training sessions for using test scripts

Tasks

112

2

3

45

67

8

9

10

11

Timing

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

38

System Test Scheduling: Example

• Each team has dedicated time in the 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

3/1

3/2

3/3

3/4

3/5

3/6

3/7

3/8

3/9

3/10

3/11

3/12

3/13

3/14

3/15

3/16

3/17

3/18

3/19

3/20

3/21

3/22

3/23

3/24

3/25

3/26

3/27

3/28

3/29

3/30

3/31

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

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

System Test: Checklist

• Preparations Data source/cubes/ODS/queries prioritized for testing Queries developed and available in the SAP BW 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 BW 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

40

Integration Test: Planning

• Progress meeting Held daily to monitor progress and resolve common issues Attendees:

Business analysts, back-end developers, query developers, test coordinator, and Test Problem Report (TPR) administrator

Purpose: Discuss common issues, monitor progress, discuss plan changes

Duration: 30 minutes

Tasks\Dates March 2004 29-Mar 5-Apr 12-Apr 19-Apr 26-Apr 3-May 10-May 17-May

Identify People for Testing

Schedule Facilities

Prioritize Test Areas (Queries)

Send out Meeting Notice

Execute System Test

Document Results

Problem Resolution

41

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

42

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 or steering

committee

43


• 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

44

Final Preparation Phase: Some Key Observations

Core Activities

4.1 Project Management Final Preparation

4.2 Training Final Preparation4.3 Acceptance Testing4.4 System Management

4.5 Detailed Project Planning

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

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

Stress & Volume Tests confirm the production hardware’s capabilities


45

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.

46

Getting Power Users involved early is important to the overall success of a Data Warehousing project

To help support 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 End-User Support Organization

47

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

The last deliverable for the implementation ensures high system performance through monitoring and feedback


We need to execute issue resolution plans and contingency plans

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

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

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

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

48

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/2

005

3/22/2

005

3/24/2

005

3/26/2

005

3/28/2

005

3/30/2

005

4/1/20

05

4/3/20

05

4/5/20

05

4/7/20

05

4/9/20

05

4/11/2

005

4/13/2

005

4/15/2

005

4/17/2

005

4/19/2

005

4/21/2

005

4/23/2

005

4/25/2

005

4/27/2

005

4/29/2

005

5/1/20

05

5/3/20

05

5/5/20

05

5/7/20

05

49

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 BW Data Load IssuesNov. 1st through Dec. 15th

0

1

2

3

4

5

6

7

11/1

/04

11/2

/04

11/3

/04

11/4

/04

11/5

/04

11/6

/04

11/7

/04

11/8

/04

11/9

/04

11/1

0/0

4

11/1

1/0

4

11/1

2/0

4

11/1

3/0

4

11/1

4/0

4

11/1

5/0

4

11/1

6/0

4

11/1

7/0

4

11/1

8/0

4

11/1

9/0

4

11/2

0/0

4

11/2

1/0

4

11/2

2/0

4

11/2

3/0

4

11/2

4/0

4

11/2

5/0

4

11/2

6/0

4

11/2

7/0

4

11/2

8/0

4

11/2

9/0

4

11/3

0/0

4

12

/1/0

4

12

/2/0

4

12

/3/0

4

12

/4/0

4

12

/5/0

4

12

/6/0

4

12

/7/0

4

12

/8/0

4

12

/9/0

4

12

/10

/04

12

/11

/04

12

/12

/04

12

/13

/04

12

/14

/04

12

/15

/04

Nu

mb

er o

f Is

sues

ProductionPerformance

DemandPlanning

Transaction -global

Source -PurchaseOrdersRoughcut

MaterialMovements

MD - Bev.Packaging

Master data

Hierarchies

Greycon

CO -line items

50

Go-live: Post-Implementation Review

The Information Paradox: John Thorp

AlignmentAlignment BenefitsBenefits

Capability/EfficiencyCapability/EfficiencyIntegrationIntegration

Are we doingthe right things?

Are we doingthem the right way?

Are we getting the benefits?

Are we getting them done well?

51


• Final Preparatory steps• The Blueprinting Phase• The Realization Phase• The Implementation Phase• Wrap-up

52

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 (http://csc- studentweb.lrc.edu/swp/Berg/BB_index_main.htm)

Download it at:

http://images.amazon.com/images/P/1556159005.01.LZZZZZZZ.jpg

53

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 BW (some belong in R/3)

• Track quality, and create a formal approval process

• Involve power users and ambassadors in the development project

54

Your Turn!!!

How to contact me:[email protected]