Você está na página 1de 54

An A-Z Guide to Planning,

Managing, and Executing an


SAP BW Project
Part 2
Dr. Bjarne Berg
Lenoir-Rhyne College.
2004 Wellesley Information Services. All rights reserved.

What We Covered So Far (in Part 1)

Writing The business case


Defining the scope
Writing the milestone plan
Timelines and staffing plan
Budgeting
On-boarding and training
Writing the workplan
Monitoring progress
Monitoring quality and a formal approval process
The user acceptance group and their role

What Well Cover (Part 2)

Approach
The blueprinting phase
The realization phase
The implementation phase
Wrap-up

What Well Cover (Part 2)

The approach

Methodology

Lessons learned

Requirements and approvals

The blueprinting phase


The realization phase
The implementation phase
Wrap-up
4

What Do Users Really Want?

Source:
SAP

Project Preparation: Some Key Observations


Project
Projectcharter:
charter:Represents
Representsan
anagreement
agreement
on,
on,and
andcommitment
commitmentto,
to,the
thedeliverables
deliverablesofofthe
the
project,
project,as
aswell
wellas
asthe
thetime
timeconstraints,
constraints,
resources,
resources,standards,
standards,and
andbudget
budgetofofthe
the
project.
project.
Project
Projectplan:
plan:This
Thisisisthe
thefirst
firstcut.
cut. ItItfocuses
focuses
on
onmilestones
milestonesand
andwork
workpackages.
packages.
Core Activities
1.1 Initial Project Planning
1.2 Project Procedures
1.3 Training Preparation
1.4 Project Kickoff
1.5 Technical Requirements Planning
1.6 Quality Check Project Preparation

Scope:
Scope:Sets
Setsthe
theinitial
initialdefinition
definitionofofthe
theproject.
project.
Project
Projectteam
teamorganization:
organization:Sets
Setsthe
thewho
whoofof
the
theproject.
project. This
Thisdecides
decideswho
whowill
willbe
beinvolved
involved
and
what
is
their
goal.
and what is their goal.
Standards
Standardsand
andprocedures:
procedures:Sets
Setsthe
thewhy
why
and
andhow
howof
ofthe
theproject.
project. Standardizing
Standardizinghow
how
meetings
meetingsare
arerun,
run,documents
documentsare
arehandled,
handled,etc
etc
means
meansthat
thateveryone
everyoneunderstands
understandswhat
whatisisgoing
going
on.
on.
Source: Pauline Woods-Wilson

Note

(This is what we covered


in Part 1)

A Brief Look at ASAP

SAP standard
Single, pragmatic, and standardized
methodology
Evolved out of 20 years of experience
Manageable scope, cost, and common
expectations
Common language
Preconfigure documentation and tools

ASAP for BW is based on many of the same ideas and approaches


that are found in the ASAP methodology for R/3
We will take a look at some core differences.

What is ASAP?

Examples for Accelerators:


Project Plan, Estimating
Design Strategies, Scope Definition
Documentation, Issues Db

Fill
Fillin
inthe
theBlank
Blank
Versus
Versus
Start
Startfrom
fromScratch
Scratch

Workshop Agenda
Questionnaires
End-User Procedures
Test Plans
Technical Procedures
Made Easy guidebooks (printout, data transfer, system
administration)

What are the Core SAP Benefits?


Source: CEO Survey - Monash University

The main reasons for SAP BW and R/3 implementations are to


provide better access to information
The BW system being built cannot be slower, less user-friendly
or harder to learn than the one it is replacing!
9

Critical Success Factors to a BW Project

Source: Lee Schlenker

Note

These are lessons learned the hard way!! Dont re-invent the
wheel but learn from others.

10

SAP Solution Manager

Upgrade Projects
e-Learning

New in
2004

Test Organizer
Customizing
Synchronization

Tool

Source: SAP

Solution Monitoring
Service Level
Reporting

Content

Services
Best Practice
Documents

Roadmaps
Service Delivery
Platform

Landscape Reporting
Support Desk

Implementation
Platform
Implementation
Content

Change Request
Management

Gateway to SAP

SAP Support

11

A Process Look at Getting Functional Specifications

Create contact
group and contact
list for business
input and
requirements
Name
Joe Jones
Joseph Jones
Joe Jones
Joe Jones
Joe Jones
Joseph Jones
Joe Jones
Joe Jones
Joe Jones
Joseph Jones
Joe Jones
Joseph Jones
Joe Jones

Organization
MYORG Ltd
Your ORG Ltd
MYORG Ltd
MYORG Ltd
MYORG Ltd
Your ORG Ltd
MYORG Ltd
MYORG Ltd
MYORG Ltd
Your ORG Ltd
MYORG Ltd
Your ORG Ltd
MYORG Ltd

Create a tool to
collect info
requests
and business
input

Phone Number
918-123-1234
918-123-1234
123-123-1234
918-123-1234
918-123-1238
918-123-1239
918-123-1234
918-123-1234
918-123-1234
918-123-1234
918-123-1234
918-123-1234
123-123-1234

Conduct
information
gathering
using the
tool

Disposition
the info.
requests to
BW or R/3

Consolidate
requirements
and write
functional
specs

Build storage Construct


objects and
reports and
load programs navigation
features

Team starts by reviewing documentationtool for


Team starts by reviewi ng d ocumentation tool for
docu men tation completeness

Review req ui reme nts and identify


correspond in g Data M odel (InfoCube/ODS)

D1
Is repo rt
documentatio n
com ple te?

Yes

D1a
Isth is a true
re po rting
need

No

Communicate to
bus . leader

Yes
No

D2
Is this
an Intraday
report?

Request ad diti on al
input from Bus in es s
Team membe r

No

D2.5
Do es data exist
in "i n-scope" models
Infocube/ODS

Yes

Yes

Yes

D6
Doe s
Standard BW
conten t
exis t?
Ye s
BW
is selected as
Reporting Tool and
documented in doc.
to ol

Communicate fina l
disposition

No

D3
Significant
number
of users?

D4
Is the r ep ort
system
resource
intensive?

No

Yes

No

D7
Is it less
exp ensive to
create in
R/3?

BW
is selected as
Re porting Tool
a nd documented
in th e documentation tool

Co mmunicate final
disposition

D8
Is BW cost
effective?

No

R/3 is selected as
Reporting Tool
and documented
in doc. tool

Communicate final
disposition

Yes
D9
R/3 Tool
Selection
Process

BW
is selected as
reporting tool and Change
Request is submitted if
the scope changed

No
Standard
R/3

Yes
R/3
is s elected as
Re port ing Tool
and d ocu mented
i n do c. tool
Com municate final
dis position

No

R/3
is selected as
Reporting Tool
a nd documented
in doc. tool

A2
Total Cost of
Ownership
Analysis

Com mun ic ate final


dis position

D5
Does
Standa rd R /3
content
exist?

No

Yes

is s ele ctedas

R/3
is s elected as
Re port ing Tool
and do cum ent ed

Responsible
Team membe r
acquires/do cum ents
additional informati on

BW
is selected as
Reporting Tool and
documented in doc.
tool

Communicate final
disposition

Communicate final
disposition

ABAP/
Custom

Report
Writer
Q uery

Other

A3
Sub-Process Report Cons ol ida tio n &
eliminate if approp riate (w innowing)
R/3 team make fina l di sp osition

BW Teamto forward complete d detailed report specifications


based on sele cted Reporting Tool - BW or R/3

Don't
Forget

A4
Baseline re ports

There is more than one way to collect this information, however, a formal
process should exist to capture requirements and to communicate what
is being developed.
We will now examine the most common form of RAD
(Rapid Application Development).

12

Rapid Application Development (RAD)

Be flexible and consider using a RAD (Rapid Application


development) approach to the initial information
requirement gathering. Typical ways to conduct this
include:

Ask for 1-2 days of uninterrupted time and provide lunch on-site
Remove cell phones, PDA and pagers and emails
Invite power users, casual users, today's report writers, and
managers
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

13

Rapid Application Development (cont.)

Benefits include:

Increased user involvement and less disruption to the


business
More likely to avoid individual opinions and get more group
consensus
You can use the session as an information sharing event and
give a brief overview of what you are attempting to do

14

Getting the Functional Specifications

Note

Best
Practice

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

15

Getting the Functional Specs (cont.)

Create a form that captures the core requirements in a


structured format
Tip
use

Create a simple form called "information request form" and


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


- Department
- Name of report
- Purpose of report
- Description of report
- Type of users (mgr./analyst/casual)
- Number of users expected
- Frequency of report (daily/monthly)

- Data currency (yesterday/today)


- Security requirements
- How is this reporting done today
- Comments

16

Sample Information Request Form

Document requirements in
a standardized format
Prioritize requirements
Consolidate requirements
Support follow-up
discussions and reviews.

Tool

P117
of 2

Sample Information Request Form

Other uses:

Post form on the intranet


and thereby give
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

Tool
P218
of 2

Report Dispositioning: What Goes in BW and What Stays in R/3?

Warning

There are many tools that can report on R/3 data and you
might have static reports that truly belongs in R/3 and which
would not be cost effective to move to BW
Make cost-effective decisions; just because the report is not
in BW does not mean it cannot be in a portal or on the web
Not all reports belong in BW; avoid using BW as a "dumping
group"
You need to make conscious decisions on what reporting
needs you are going to meet and how you want to accomplish
this

We will now take a look at an approach to a formal report


dispositioning that has been used by a few companies.

19

Key Questions for Report Dispositioning

Is this really a reporting need or a "want"?


Is the data going to be in BW at a frequency that solves
the user's request (intraday reporting)?
Is the data needed for this report already in our BW
scope?
Are there already a report available in R/3 ?
Does standard BW content exist?
Is it less expensive to create in R/3?
Are there a significant number of users?
Is the reporting need resource-intensive?
Is BW cost effective in the long run (ownership)?

20

Team starts by reviewing documentation tool for


documentation completeness

cu

Review requirements and identify


corresponding Data Model (InfoCube/ODS)

D1
Is report
documentation
complete?

Yes

Tool
D1a
Is this a true
reporting
need

No

An example of how to decide


which reports should be in R/3 or
the legacy system (printed version is
easier to read)

Communicate to
bus. leader

Yes
No

D2
Is this
an Intraday
report?

Request additional
input from Business
Team member

No

D2.5
Does data exist
in "in-scope" models
Infocube/ODS

Yes

Yes

Yes

D6
Does
Standard BW
content
exist?
Yes
BW is selected as
Reporting Tool and
documented in doc.
tool

Communicate final
disposition

No

No

D7
Is it less
expensive to
create in
R/3?

BW is selected as
Reporting Tool
and documented
in the documentation tool

Communicate final
disposition

D8
Is BW cost
effective?

Communicate final
disposition

R/3 is selected as
Reporting Tool
and documented
in doc. tool

Communicate final
disposition

Yes
D9
R/3 Tool
Selection
Process

BW is selected as
reporting tool and Change
Request is submitted if
the scope changed

No
Standard
R/3

Yes
R/3 is selected as
Reporting Tool
and documented
in doc. tool

No

No

R/3 is selected as
Reporting Tool
and documented
in doc. tool

Yes

A2
Total Cost of
Ownership
Analysis

Communicate final
disposition

D5
Does
Standard R/3
content
exist?

D4
Is the report
system
resource
intensive?

No

Yes

R/3 is selected as
Reporting Tool
and documented

Responsible
Team member
acquires/documents
additional information

No

D3
Significant
number
of users?

BW is selected as
Reporting Tool and
documented in doc.
tool

Communicate final
disposition

Communicate final
disposition

ABAP/
Custom

Report
Writer
Query

Other

A3
Sub-Process Report Consolidation &
eliminate if appropriate (winnowing)
R/3 team make final disposition

BW Team to forward completed detailed report specifications


based on selected Reporting Tool - BW or R/3

A4
Baseline reports

21

Now That You Have Identified the In-Scope Reports, Whats Next?
Obtain a copy of each of the current reports that are in-scope (not all).
Legacy reports may be a great source to document the data needs; they
can be used to illustrate how data is currently being summarized and
viewed in the organization
Consolidate the requirements and look for "low-hanging fruit"
Create a physical folder with paper copies of "in-scope" legacy reports;
make sure that the development team has access to them and reduce the
time spent in meetings with the business community

Great
Feature

Many requirements
can be met by a
single BW report

22

Flow Overview

BW Report object:

Business
Reporting
Requirements

When: Fall-03 to Jan-12, 2004.


Who:
Process teams
Purpose: Functional requirements
Quantity: 167

Reports

BW Query Detailed Specification


(used by Information Delivery)

Query Name:

BW detailed query specs

Query Technical Name:


Subject area:

Fixed format:
Free format:
Number of users:

When: Fall-03 to Jan-12, 2004.


Who:
Information delivery
Purpose: Functional requirements
Quantity: 167

Target Users:

Time Granularity
Historical data:
Peak time usage:
Data Volume:
Frequency:

SAP Roles:

Test Criteria:

Jump Targets:

BW Reports
An example from a very large manufacturing company

23

An
Example

24

An
Example

25

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

KPI & Scorecard


Formatted
Simple
Easy to view
Limited nav
Aggregates

Flat Reporting

Casual users tends to prefer predictable structured


access to the data
Analysts and power users tends to prefer high
flexibility and unstructured access to the data.

Formatted
Print
Form based
Static
Predictable access

OLAP Reporting
Drill Down

OR

OR

Don't underestimate the user's need to access


the information in various ways.

Slice and Dice


Analyse
Data Mining
Search and discover

26

What Well Cover (Part 2)

The approach
The blueprinting phase

Leveraging the standard content

Modeling your solution

Deliverables

The realization phase


The implementation phase
Wrap-up
27

Blueprinting Phase: Some Key Observations


Getting
Gettingthe
theright
rightrequirements:
requirements:
Finding
Findingout
outthe
thedetailed
detailedfunctional
functional
specs
specsofofwhat
whatthe
theusers
usersreally
reallyneed
need
and
andnot
notjust
justwhat
whatthey
theywant.
want.
Deciding
Decidingwhat
whatwill
willbe
bedeveloped
developedinin
BW
BWand
andwhat
whatwill
willbe
bemaintained
maintainedas
as
R/3
R/3reports.
reports.

Core Activities
2.1 Project Management Business Blueprint
2.2 Organizational Change Management
2.3 Project Team Training Business Blueprint
2.4 Develop System Environment
2.5 Organizational Structure Definition
2.6 Business Process Definition
2.7 Quality Check Business Blueprint

Map
Mapthe
thefunctional
functionalrequirements
requirementsto
tothe
the
standard
standardcontent
contentand
andsee
seewhat
whatcan
canbe
be
leveraged
leveragedand
andwhat
whatneeds
needsto
tobe
be
extended.
extended.
Create
Createdetailed
detailedtechnical
technical
specifications
specificationsand
anddesigns
designsofof
infocubes,
infocubes,masterdata,
masterdata,ODSs
ODSsand
and
high-level
high-levelarchitectural
architecturaldesigns.
designs.
Create
Createuser
useracceptance
acceptancegroup(s)
group(s)and
and
have
havethem
themreview
reviewand
andgive
givefeedback
feedback
on
onthe
thesystem
systemas
asititisisdeveloped.
developed.

28

The Blueprinting Phase: Leveraging Standard Content


Mostly standard storage objects
Some customization
Highly customized storage objects

As a guiding principle we
map requirements to
standard content before we
start customizing.

31%

However, we may also


have external data sources
that require custom ODSs
and InfoCubes.

Some observations on
higher level objects.

36%

33%

An example from a large


manufacturing company

BW Content available:

InfoObjects 11,772
ODS objects 349
InfoCube
605
MultiCubes
121
Roles
861
Queries
3,299
Workbooks 1,979

29

The Blueprinting Phase: Modeling Your Solution

Storage

BW functional requirement:

Storage
Requirements

When: Fall-03 to Jan-12, 2004.


Who:
Information delivery team
Purpose: Storage object requirements
Quantity: 25

Material
Material number
Material entered
Material group
Item category
Product hierarchy
EAN/UPC

BW logical model:

When: Fall-03 to Jan-12, 2004.


Who:
Information delivery team
Purpose: Storage object requirements
Quantity: 25

Unit

Logistics
Plant
Shipping/receiving point

Currency Key
Unit of Measure
Base unit of measure
Sales unit of measure
Volume unit of measure
Weight unit of measure

Billing

Customer
Sold-to
Ship-to
Bill-to
Payer
Customer class
Customer group
~ Custome r country
~ Custome r region
~ Custome r postal code
~ Custome r industry code 1
End user

Number of billing documents


Number biling line items
Billed item quantity
Net weight
Subtotal 1
Subtotal 2
Subtotal 3
Subtotal 4
Subtotal 5
Subtotal 6
Subtotal A
Net value
Cost
Tax amount
Volume

Organization
Company code
Division
Distribution channel
Sales organization
Sales group

Personnel
Sales rep number

Accounting
Cost center
Profit center
Controlling area
Account assignme nt group

Billing information
Billing document
Billing item
Billing type
Billing category
Billing date
Creation date
Cancel indicator
Output me dium
~ Batch billing indicator
Debit/credit re ason code
Biling category
Reference document
Payment terms
Cancelled billing document
Divison for the order header
Pricing procedure
Document details
Sa les order document type
Sales deal
Sales docuement

Time
Calendar year
Calendar month
Calendar week
Calendar day

LEGEND

Standard content

Delivered in standard extractors


Delivered in LO extractor
Not in delivered Content -but in R-3

A real example from a very large manufacturing company

BW InfoCubes

30

Modeling Your Solution


Material
Material number
Material entered
Material group
Item category
Product hierarchy
EAN/UPC

1. Write functional
requirements

2. Create a model based


on pre-delivered BW
content

3. Map your
requirements to the
delivered content and
identify gaps.

Unit

Logistics
Plant
Shipping/receiving point

Currency Key
Unit of Measure
Base unit of measure
Sales unit of measure
Volume unit of measure
Weight unit of measure

Billing

Customer
Sold-to
Ship-to
Bill-to
Payer
Customer class
Customer group
~ Customer country
~ Customer region
~ Customer postal code
~ Customer industry code 1
End user

Number of billing documents


Number biling line items
Billed item quantity
Net weight
Subtotal 1
Subtotal 2
Subtotal 3
Subtotal 4
Subtotal 5
Subtotal 6
Subtotal A
Net value
Cost
Tax amount
Volume

Organization
Company code
Division
Distribution channel
Sales organization
Sales group

Personnel
Sales rep number

Accounting
Cost center
Profit center
Controlling area
Account a ssignme nt group

Billing information
Billing document
Billing item
Billing type
Billing category
Billing date
Creation date
Cancel indicator
Output me dium
~ Batch billing indicator
Debit/cre dit re ason code
Biling category
Reference document
Payment terms
Cancelle d billing docume nt
Divison for the order header
Pricing proce dure
Document details
Sales order docume nt type
Sales deal
Sales docuement

Time
Calendar
Calendar
Calendar
Calendar

year
month
week
day

LEGEND
Delivered in standard extractors
Delivered in LO extractor
Not in delivered Content -but in R-3

31

What Well Cover (Part 2)

The approach
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
32

Realization Phase: Some Key Observations


Core Activities
3.1 Project Management Realization
3.2 Organizational Change Management
3.3 Training Realization
3.4 Baseline Configuration and reviews
3.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 Queries
3.10 Develop User interface enhancements
3.11 Determine additional reporting requirements
3.12 Create structured reports
3.13 Establish Authorization Concept

Development
DevelopmentPrograms:
Programs:Provide
Provide
details
of
added
programming
details of added programming
structures
structures
End
EndUser
UserTraining
TrainingMaterial
Material
Configuration
Configurationand
andTesting
TestingPlans:
Plans:
Define
how
the
configuration
Define how the configurationwill
willbe
be
implemented
and
how
it
will
be
implemented and how it will be
tested
tested
Source: Pauline Woods-Wilson

3.14 Establish Data Archiving plan (if applicable)


3.15 Final Integration Test
3.16 Quality Check Realization

33

Building ODSs and InfoCubes


TIPS
1 Review the functional requirements and 6 Do not allow exceptions to the naming
the technical design
conventions
2 Make sure you have established data
7 Make sure that putting out fires do not
stewards for the masterdata and assigned take precedence and becomes the defaulted
the masterdata to specific developers
architecture and standard.
3 Have your ETL developers report
functionally to an individual who is
responsible for creating process chains

8 Try new ideas in a sandbox environment


and do not 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 a the needs
of a single infoCube.
10 Developers must perform unit test on all
their work and personally sign-off on their
storage object.

5 Make your transformations as part of


update rules into infocubes if you need
to be able to reconcile to the source
system. Keep the details in the ODS.

34

The BW Test Methodology

Methodology used for System and Integration tests


Test Strategy

Test Plan

Test Execution

Problem Resolution

R/3 and BW testing is not different from a methodology


standpoint, but the execution is.

35

System Test: Planning


Tasks\Dates

December 2003

January 2004

Identify People for Testing

February 2004 1-Mar 8-Mar 15-Mar 22-Mar 29-Mar 5-Apr

s,
a
g
r
o
f
p
to sto
e
m
i
t
o
n
"There's dy late"
rea
we're al

Schedule Facilities
Prioritize Test Areas (Queries)
Send out Meeting Notice
Execute System Test
Document Results
Problem Resolution

Activities
Tasks
1
2
3
4
5

Create test script


Identify roles to be used
Documentation on using test tools
Procedure for documenting test results
Training sessions for using test scripts

6
7
8
9

Identify key contacts


Communicate about transports
Arrange time for progress control
Schedule facilities
11

12

10

Business analysts are responsible for planning,


coordinating and executing the system testing of queries.

2
3

9
4

8
7

Timing

36

Deliver
Cost and Profitability
Order
Manufacturing
Plan and scheduling
Demand planning
Source

Environment
preparation

4/2

4/1

3/31

3/30

3/29

3/28

3/27

3/26

3/25

3/24

3/23

3/22

3/21

3/20

3/19

3/18

3/17

3/16

3/15

3/14

3/13

3/12

3/11

3/10

3/9

3/8

3/7

3/6

3/5

3/4

3/3

3/2

3/1

System Test Scheduling: Example

Resolving
outstanding
issues and retesting

= Morning session 8:30 - noon


= Evening session 12:30 - 5:00

Each team has dedicated time in the test room.


Food will be provided (pastry, doughnuts etc)
At least 2 testers (preferably 3) should be assigned
to test each query
All test results to be logged
37

System Test: Checklist

Preparations

Functional requirements complete


Prioritize data source/cubes/ODS/queries for testing
Identify critical path for testing
Queries developed and available in BW test environment
Modify test script to suit each track
Track specific test plans created using existing test template
Test cases written

38

System Test: Checklist (cont.)

People

Individuals (testers) to perform the test identified


Testers invited to complete BW web-based training
Availability of testers ensured
Roles to be used by testers determined
Security roles tested
User IDs for testers created and available

Logisitics

Familiarize test results recording tools LN database, issues


log
Identify test location, and ensure availability of logistics
(rooms, computers, sapgui, network connections, phone, etc..)
Plan for problem resolution

39

Integration Test: Planning


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

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

40

Performance Testing

Performance test execution

Identify queries to be performance tuned


Determine cutoff load for load test e.g. 40% of actual users
(not named)
Schedule queries to run in background
Execute each query while load scripts are running to simulate
real users
Monitor BW system continuously
Attempt tuning at query level
Perform analysis based on benchmarks
Build aggregates, indexes, etc. if needed
Record findings in a formal tracking tool available to all
Meet with developers everyday to discuss issues/progress
Problem resolution
41

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

42

What Well Cover (Part 2)


The approach
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

43

Final Preparation Phase: Some Key Observations


The
TheCutover
CutoverPlan
Planand
andthe
theTechnical
Technical
Operations
Manual
describe
Operations Manual describethe
thedetails
details
on
onhow
howtotomove
movetotothe
theproduction
production
environment
and
go
live
environment and go live
The
TheStress
Stress&&Volume
VolumeTests
Testsconfirm
confirm
the
production
hardwares
capabilities
the production hardwares capabilities
The
TheEnd
EndUser
UserTraining
Trainingdocument
document
describes
the
delivery
of
the
describes the delivery of thenecessary
necessary
levels
levelsofofSAP
SAPtraining
trainingprior
priortotogoing
goinglive
live

Core Activities

Source: Pauline Woods-Wilson

4.1 Project Management Final Preparation


4.2 Training Final Preparation
4.3 Acceptance Testing
4.4 System Management
4.5 Detailed Project Planning
4.6 Cutover
4.7 Quality Check Final Preparation

44

Conducting End-User and Power User Training

Types of training:

Web-based
All users
Training
Tutorials
Instructor-led
On-site
Power users
Executives
Vendor-based
Developers
Support staff

45

Establishing End-User Support Organization


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.
If you dont have them, on-going projects may get bogged
down with basic support of reports.

46

A BW Data Warehouse Approach at a Company

CHANGE

Issue

Should a set of
Ambassadors be part of
the rollout-strategy?

CONTINUE

BW Data Warehouse Alternatives

TOP-DOWN
APPROACH

Issue

How can this be done


with minimal
organizational
disruption?

Note

Building a global data


warehouse for [company X]
and proceed sourcing data
from legacy systems driven
from a top -down approach
where reports are also
created centrally.

BOTTOM-UP
APPROACH
Focus on a bottom up
approach where the DW project
will prioritize supporting and
delivering DW solutions, but
where businesses are actively
involved in developing reports.

The core issue was if the support organization should be centralized, or if


the local organizations should be involved.

47

Some Benchmark Indications Regarding Ambassadors

Can you use a BW


ambassador in your
user organization?

Business Units Involved in Development

No
(10%)

50%
50%
Successful
Successful

Note

Increased business involvement increases the probability for data


warehouse project success.

Yes
(90%)

70%
70%
Successful
Successful

48

Go-Live: Some Key Observations

The
Thelast
lastdeliverable
deliverablefor
forthe
the
implementation
ensures
implementation ensureshigh
highsystem
system
performance
through
monitoring
performance through monitoringand
and
feedback
feedback
Source: Pauline Woods-Wilson

We
Weneed
needtotoexecute
executeissue
issueresolution
resolution
plans
and
contingency
plans
plans and contingency plans

Core Activities
5.1 Production Support
5.2 Project End

AAlessons
lessonslearned
learnedsession
sessionshould
shouldbe
be
held
at
the
end
of
the
project
to
assure
held at the end of the project to assure
organizational
organizationalawareness
awarenessand
andeducation
education
The
Thesupport
supportorganization
organizationwill
willtake
takeover
overthe
the
system
after
a
pre-determined
time
period.
system after a pre-determined time period.
Some
Someteam
teammembers
membersmay
maytransition
transitioninto
into
their
new
roles
as
support
staff
their new roles as support staff
This
Thisisisaacritical
criticaltime
timewhen
whenaaSWAT
SWATteam
team
that
thatquickly
quicklyaddresses
addressesuser
userconcerns
concernscan
can
make
all
the
difference
in
how
the
system
make all the difference in how the system
isisreceived
receivedamong
amongthe
theusers
users

49

Go-live: Post-Implementation Review

Alignment
Are we doing
the right
things?

Are we doing
them the right way?

Integration

Benefits
Are we getting
the benefits?

Are we getting
them done well?

Capability/Efficiency

The Information Paradox: John Thorp

50

What Well Cover (Part 2)

The approach
The blueprinting phase
The realization phase
The implementation phase
Wrap-up

51

7 Key Points to Take Home


Keep the team relatively small and
focused
SAP NetWeaver

Size your projects based on the team


experience

Follow a proven methodology


Track quality and create a formal approval
process

Composite Application Framework

Do not cram all reports into BW (some


belong in R/3)

Multi-Channel Access
Portal

Collaboration

Information Integration
Business
Intelligence

Knowledge
Management

Master Data Management

Process Integration
Integration
Broker

Business Process
Management

Life Cycle Management

Make the implementations interactive


instead of Big-Bang

People Integration

Application Platform
J2EE

ABAP

andOS
OS Abstraction
Abstraction
DBDBand

.NET

WebSphere

Involve power users and ambassadors


in the development

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

Download it at:

53

Your Turn!!!

How to contact me:


bergb@lrc.edu
54

Você também pode gostar