A Comprehensive Guide

To Plan, Manage, and

Execute a Successful
SAP BW Implementation
Project – Part 2

Bjarne Berg
MyITgroup
© 2006 Wellesley Information Services. All rights reserved.
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”
2
What We’ll Cover Now (In Part 2)…

• Final Preparatory steps

s Methodology details
s Lessons learned
s Requirements and approvals
• The Blueprinting Phase
• The Realization Phase
• The Implementation Phase
• Wrap-up

3
What We’ll Cover…

• Final Preparatory steps

s Methodology
s Lessons learned
s Requirements and approvals
• The Blueprinting Phase
• The Realization Phase
• The Implementation Phase
• Wrap-up

4
 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
budgetof
ofthe
the
project.
project.

Project
Projectplan:This
plan:Thisisisthe
thefirst
firstcut.
cut. ItItfocuses
focuses
on
onmilestones
milestonesand
andwork
workpackages.
packages.

Core Activities Scope:

Scope:Sets
Setsthe
theinitial
initialdefinition
definitionofofthe
theproject.
project.
1 . 1 Initial Project
Planning Project
Projectteam
teamorganization:Sets
organization:Setsthe
the‘who’
‘who’ofof
1 . 2 Project Procedures the
theproject.
project. ItItdecides
decideswho
whowill
willbe
beinvolved,
involved,
1 . 3 Training Preparation and what their goal is.
and what their goal is.
1.4 Project Kickoff
1 . 5 Technical Requirements Standards
Standardsand andprocedures:Sets
procedures:Setsthe
the‘why’
‘why’and
and
Planning
1 . 6 Quality Check Project ‘how’
‘how’ofofthe
theproject.
project. Standardizes
Standardizeshow
how
Preparation meetings
meetingsare arerun,
run,how
howdocuments
documentsare
arehandled,
handled,
etc.
etc.so
soeveryone
everyoneunderstands
understandswhat
whatisisgoing
goingon.
on.

Source: Pauline Woods-Wilson

This is what we covered in Part 1…
5
Note
What is ASAP?

Examples for Accelerators:

• Project Plan, Estimating
Fill
Fillin
inthe
theBlank
Blank
• Design Strategies, Scope Definition Versus
Versus
• Documentation, Issues Db Start
Startfrom
fromScratch
Scratch
• Workshop Agenda
• Questionnaires
• End-User Procedures
• Test Plans
• Technical Procedures
• Made Easy guidebooks (printout, data transfer, system
administration…)

6
 The ASAP Approach (from Part-1)

Integration
Testing
Create Technical
specs
Create Functional No

specs System Testing

Complete?
No
Yes

Complete? Unit Testing

Yes

Yes Configuration
Peer Review
No
Approved? Peer Review
Yes

No
Approved?

Yes Structured
Complete?
walkthrough
No
No Yes Structured
Complete?
walkthrough
7
Alternative Approach For Smaller Projects
(I.E. 1st Go-live)
• Keep the scope focused and use a simple approach:
pe?
• sco
Activate Request for
In-
Make
standard modifications Yes enhancements
content

No
pe?
sco
User re
Load infocube acceptance futu Test
session In-

No

Review data Create 2-3 Deploy

quality issues sample queries

Rejection

No functional or technical specs are used

in this approach . The user acceptance
session is used to refine requirements 8
 Critical Success Factors for SAP BW Projects

Individual Organizational Technological Methodology

The best people End users on the team Platform sizing Proper scope

Backfilling Communication with Testing tools Leadership and

users commitment

Single location Documentation and Integration testing Budget for

training internal before releasing consulting and
changes training

Good SAP Breadth and depth of Do not modify code Overseas contacts
consultants training

Source: Lee Schlenker

These are lessons learned the hard

way …
Note Don ’ t re - invent the wheel -- learn from
others .
9
 SAP Solution Manager

Upgrade Projects New in Change Request

Management
2004
e-Learning Landscape Reporting

Test Organizer Support Desk

Customizing
Tool Solution Monitoring
Synchronization

Implementation Service Level

Platform Reporting

Implementation
Content Services
Content

Best Practice
Roadmaps
Documents

Service Delivery Gateway to SAP SAP Support

Platform

Was added in 2004

Source: SAP AG
10
 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
•

MMost
ostofofth
theepproje
roject
ctmmaa
nn
aa ggee
mmeenn
tttools
tools
aa
bbou
outtstaa
st ffingg
ffin ,,pp
lann
la nn
ingg
in ,,scop
scop ingg
in ,,aa
nn
dd
wwork
orkppla
lannssaa
re
refou
fou nn
ddhh
eerere AAte st
testddrive
riveisisaa
vaila
va bb
ilale
leon
onththeeW Wee
bbsit e::
site
https://m
https://media.sdn.sap.com
edia.sdn.sap.com /htm
/html/subm
l/submitted%
itted%5Fdocs/
5Fdocs/
Best%
Best% 5FPractices/BW
5FPractices/BW //
11
 Option – Workplans Based on Deliverables

• The best practice documents are organized

around scenarios, which simplify the
collection of tools

M a n y o f y o u r te a m ’ s
d e liv e ra b le s ca n b e
d o w n lo a d e d h e re a n d
y o u ca n in co rp o ra te
th e m sp e cifica lly in to
12
y o u r w o rk p la n s
 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:
mySAP Software Release Level Highest Support
•
Application Component Package
Component

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

Source: SAP - Sept - 2005

W h ile th e in sta ll re co m m e n d a tio n s a re b a se d o n S A P B W

3 . 5 , m o st m a n a g e m e n t to o ls , a cce le ra to rs , a n d th e
Note sa m p le w o rk p la n a re n o t v e rsio n - sp e cific 13
 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:
s Ask for 1-2 days of uninterrupted time, and
provide lunch on-site
s Invite power users, casual users, today's report
writers, and managers
s Remove cell phones, PDA, pagers, and email
access
s Keep a rapid pace, and a manageable number of
attendees (no more than 20)
s Focus on shared information needs, and conduct
multiple sessions if needed
s Don't get trapped in details; give people a
You can to
chance useprovide
the session as an in
feedback information
writing and
sharing
follow-upevent , and
later giveindividuals
with a brief overview of
what you are attempting to do 14
What We’ll Cover…

• Final Preparatory steps

• The Blueprinting Phase
s Leveraging the standard content
s Modeling your solution
s Deliverables
• The Realization Phase
• The Implementation Phase
• Wrap-up

15
 A Process Look at Getting Functional
Specifications

Create a contact
Create a tool to Gather ConsolidateBuild storageConstruct
Disposition
group and contact objects and reports and
collect info informationthe info. requirements
ist for businessrequests and using the requests toand write load programsnavigation
requests
input and business input tool BW or R/3functional features
requirements specs
Name Organization PhoneNumber
JoeJ ones MYORG Ltd 918-123-1234
JosephJ ones YourORG Ltd 918-123-1234
JoeJ ones MYORG Ltd 123-123-1234
JoeJ ones MYORG Ltd 918-123-1234
JoeJ ones MYORG Ltd 918-123-1238
JosephJ ones YourORG Ltd 918-123-1239
JoeJ ones MYORG Ltd 918-123-1234
JoeJ ones MYORG Ltd 918-123-1234
JoeJ ones MYORG Ltd 918-123-1234
JosephJ ones YourORG Ltd 918-123-1234
JoeJ ones MYORG Ltd 918-123-1234
JosephJ ones YourORG Ltd 918-123-1234
JoeJ ones MYORG Ltd 123-123-1234

T h e re is m o re th a n o n e w a y to co lle ct th is in fo rm a tio n .
Don't H o w e v e r, a fo rm a l process should exist to capture
Forget re q u ire m e n ts & co m m u n ica te w h a t is b e in g d e v e lo p e d .

W e w ill n o w e x a m in e th e m o st co m m o n fo rm o f R A D
( Rapid Application Development ) .
16
 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.
Note •
• A single SAP BW "report" may
satisfy dozens of today's static
reports. It is therefore
impossible
Avoid attempting to map each individual
to replicate
each report based on what you
Best legacy
might have report
in place today . to a single BW
Practice Accept new ways of accessing
data . report.
•
17
 Getting the Functional Specifications (cont.)

• Create a form that captures the business’

core requirements in a structured
format
s
Tip
• 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:
•

s
•
- Contact info about the requestor - Data
currency (yesterday/today)
• - Department - Security requirements
• - Name of report - How is this reporting
done today 18
 Sample Info Request Form:

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

•
P119of
2
Sample Info Request Form:

• Other uses:
s Post the form
on the
Intranet,
thereby giving
stakeholders
an easy way to
communicate
with the
project team
s Use the
Comment
section for
security
requirements,
or add a
Tool
separate
P220of
section for 2
An
Exa
mpl
e

21
An
Exa
mpl
e

22
 Consider Multiple Ways of Displaying the
Same Data!!
Deliver reports in a consistent
•

manner to users (one version KPI & Scorecard

Formatted
of the "truth"), but use •Simple
•Easy to view
different mechanisms to do so •Limited nav
•Aggregates
• Managers and executives tends to
Flat Reporting
prefer simple •Formatted
• and directed interfaces •Print
•Form based
• Casual userstends to prefer •Static
predictable structured •Predictable access
• access to data
OLAP Reporting
• Analysts and power users tend to •Drill Down
prefer high •Slice and Dice
• flexibility and unstructured access •Analyse
OR
to data OR •Data Mining
•Search and discover
•

D o n 't u n d e re stim a te u se rs ’ n e e d to a cce ss th e

in fo rm a tio n in v a rio u s w a y s . 23
 Blueprinting Phase: Some Key Observations

Getting
Gettingthe
theright
rightrequirements:
requirements:
Finding
Findingout
outthe
thedetailed
detailedfunctional
functional
specs
specsofofwhat
whatusers
usersreally
reallyneed
needand
and
not
notjust
justwhat
whatthey
theywant.
want.

Deciding
Decidingwhat
whatwill
willbe
bedeveloped
developedinin
SAP
SAPBWBWand
andwhat
whatwill
willbe
bemaintained
maintained
as
asR/3
R/3reports.
reports.

Map
Mapthe
thefunctional
functionalrequirements
requirementsto
tothe
the
standard
standardcontent,
content,and
andsee
seewhat
whatcan
can
Core Activities be
beleveraged
leveragedand
andwhat
whatneeds
needsto
tobe
be
2 . 1 Project Management Business extended.
extended.
Blueprint
2 . 2 Organizational Change Create
Management Createdetailed
detailedtechnical
technical
2 . 3 Project Team Training specifications
specificationsand
anddesigns
designsof
of
Business Blueprint infocubes,
infocubes, masterdata, ODSs,and
masterdata, ODSs, and
2 . 4 Develop System Environment
high-level architectural designs.
high-level architectural designs.
2 . 5 Organizational Structure
Definition
2 . 6 Business Process Definition Create
Createuser
useracceptance
acceptancegroup(s),
group(s),and
and
2 . 7 Quality Check Business have
havethem
themreview
reviewandandgivegivefeedback
feedback
Blueprint on
onthe
thesystem
systemasasititisisdeveloped.
developed.

24
 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
Warning 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
We will now take a look at an approach to formal report
meet, andthat
dispositioning how youused
has been will
by accomplish
a few companies. this
25
 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 26
 Team starts by reviewing documentation tool for
documentation completeness
An example of how to
cu Review requirements and identify
Tool
decide which reports
corresponding Data Model (InfoCube/ODS)
should be in R / 3 or the
legacy system
D1
Is report
Yes
D1a
Is this a true No
Communicate to ( refer to printed version )
documentation reporting bus. leader
complete? need

Yes

No D4
D2 D2.5 D3
Is the report
Is this Does data exist Significant
No No No system
an Intraday in "in-scope" models number
resource
Request additional report? Infocube/ODS of users? No
intensive?
input from Business
Team member
Yes Yes
Yes R/3 is selected as
Reporting Tool
R/3 is selected as and documented
Reporting Tool A2
Total Cost of in doc. tool
and documented
Responsible Ownership
Team member Analysis
acquires/documents
additional information R/3 is selected as
Communicate final Reporting Tool
disposition D8 and documented
No
Is BW cost in doc. tool
Yes effective?

D5 BW is selected as
Does Reporting Tool Communicate final
Yes disposition
Yes Standard R/3 No and documented
content in the documentation tool
exist? D9
BW is selected as R/3 Tool
D6 D7 reporting tool and Change Selection
Does Is it less Communicate final Request is submitted if Process
Standard BW disposition the scope changed
No expensive to
content create in
exist? No
R/3?
Standard Report
Yes Yes R/3 Writer

BW is selected as R/3 is selected as BW is selected as Communicate final ABAP/

Custom Query Other
Reporting Tool and Reporting Tool Reporting Tool and disposition
documented in doc. and documented documented in doc.
tool in doc. tool tool
A3
Sub-Process Report Consolidation &
Communicate final Communicate final Communicate final eliminate if appropriate (winnowing)
disposition disposition disposition
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
27
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)
s 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
s Consolidate the requirements, and look for
"low-hanging fruit"
s Create a physical folder with paper copies
Great of these legacy reports
M any
+ + =
„ Make sure that the development
re q u ire m e n tsteam
Feature has access to them --cathis
n b e will
m e t reduce
by
a sin g le with
the time spent in meetings S A P the
business community B W re p o rt
28
 The Blueprinting Phase: Leveraging Standard
Content
• As a guiding Mostly standard storage objects
Some customization
principle, map Highly customized storage objects

requirements 31% 36%

to standard
content
before
customizing
An example from a large
• However, you’ll 33% manufacturing company

probably also
have external BW
BW Content
Content available
available
data sources ::
((33..55..11))

that require
custom ODSs •Cockpits ???
and InfoCubes •Workbooks
•Queries
1,979
3,299
•Roles 861
• Customizing •MultiCubes 121
lower level •
•InfoCube 605
objects will •ODS objects 349
cause higher •InfoObjects 11,772

level standard 29
 The Blueprinting Phase: Model Your Solution
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
Unit
Logistics
Material
Currency Key Billing information
Plant Unit of Measure
Material number
Shipping/receiving point Base unit of measure
Material entered Billing document
Material group Sales unit of measure
Billing item
Item category Volume unit of measure
Billing type
Weight unit of measure

Storage
Product hierarchy Billing category
EAN/UPC Billing Billing date

Requirements
Creation date
Cancel indicator
Number of billing documents Output me dium
Customer Number biling line items ~ Batch billing indicator
Billed item quantity Debit/cre dit re ason code
Sold-to Net weight Biling category
Ship-to Subtotal 1 Reference document
Bill-to Subtotal 2 Payment terms
Payer Subtotal 3 Cancelle d billing docume nt
Customer cla ss Subtotal 4 Divison for the order header

+
Customer group Subtotal 5 Pricing proce dure
~ Custome r country Subtotal 6
~ Custome r region Subtotal A Document details
~ Custome r postal code Net value
~ Custome r industry code 1 Cost
End user Tax amount Sa les order docume nt type
Volume Sales deal
Sales docuement
Organization

Company code
Division
Personnel Accounting
Time Storag
Standard Distribution channel
Sales organization Sales rep number Cost center
Calendar year
e
Object
Profit ce nter

content
Sales group
Controlling area Calendar month
Account a ssignme nt group Calendar week

LEGEND
Calendar day
s
Map functional requirements
to the standard content before Delivered in standard extractors
Delivered in LO extractor
you make enhancements Not in delivered Content -but in R-3 30
 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
Approximate Usage of Standard Content BW 3.5
• (percentage of overall development effort)
100

80
The differences are
60 often due to
customization on
40 the R/3-side by
companies and/or
20 industry solutions.
0
CO

t
FI

*
*

es

ry
gm
g

EM
M

io
AP
in

to
Sa
CR

ut

m
ur

n
SC
rib

ve
y
t
ac

lit

In
st
uf

a
Di

Qu
an

31
M

* Rapidly improving content

What We’ll Cover…

• Final Preparatory steps

• The Blueprinting Phase
• The Realization Phase
s Building ODSs and InfoCubes
s Planning, Managing and executing system
test
s Planning, Managing and executing
integration and performance test
s 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 Development
DevelopmentPrograms:
Programs:Provide
Provide
interface development details of added programming
3.8 Develop Data Conversion details of added programming
structures
Programs ( if any ) structures
3.9 Develop Queries
3 . 10 Develop User interface End
3enhancements
. 11 Determine additional EndUser
UserTraining
TrainingMaterial
Material
3reporting
. 12 Create structured reports
requirements
3 . 13 Establish Authorization Configuration
3Concept
. 14 Establish Data Archiving plan Configurationand
andTesting
TestingPlans:
Plans:
3( if
. 15 applicable
Final Integration Test Define
Define how the configurationwill
how the configuration willbe
be
)
3 . 16 Quality Check Realization implemented and how it will be tested
implemented and how it will be tested

Source: Pauline Woods-Wilson

33
 Building ODSs and InfoCubes

TIPS
Review
1 the functional requirements Do and
not
6 allow exceptions to your naming
technical design conventions
Make
2 sure you have establishedMake
Data7sure that “putting out fires” does not
Stewards for master data, and assign
take precedence, becoming the
master data to specific developers“default” architecture and standard.

Have
3 your ETL developers work Try8 new ideas in a sandbox environment ,
for the individual who is responsible
and don’t contaminate the development
for creating process chains environment.
(organizationally )
Avoid
4 nested ODS layers, and keepKeep
the
9 details for multi-use in the ODS and
architecture as pristine as possible
do not design the ODS based on the needs
of a single infoCube.
Make
5 your transformations part Developers
of 10 must unit test all of their
update rules into infocubes if youwork
needand personally sign-off on their
to be able to reconcile to the sourcestorage object.
system. Keep the details in the ODS.

34
 Consider Upgrading to SAP BI in SAP
NetWeaver 2004s
On a typical SAP BW project , 40 - 60 % of project
effort will be spent on data integration ,
transformation , and loads

BI in SAP
NetWeaver
2004 has a
new GUI to
help you
write
transformat
ions ,
potentially
saving you
a lot of
time !
Source SAP AG

35
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 ….
36
 System Test: Planning
Tasks\Dates December 2003 January 2004 February 2004 1-Mar 8-Mar 15-Mar 22-Mar 29-Mar 5-Apr

Identify People for Testing

o t i m e to
Schedule Facilities
T he re's n , we're
"
f o r ga s
sto p a t e"
Prioritize Test Areas (Queries)
d y l
alrea
Send out Meeting Notice

Execute System Test

Document Results

Problem Resolution

•Activitie
s Tasks
1 Create
• test script 6 Identify key contacts
2 Identify sroles to be used 7 Communicate about transports
3 Documentation
s on using test tools 8 Arrange time for progress control
4 Procedure for documenting test results 9 Schedule facilities
5 Training sessions for using test scripts
„„
11 1
„„ „
1 1

Business analysts are responsible for 1

1
1
1
1

planning , coordinating , and executing Timing

the system testing of queries . 37
 System Test Scheduling: Example

3/10
3/11
3/12

3/23

3/25
3/26
3/27
3/28

3/30
3/13
3/14
3/15
3/16
3/17
3/18
3/19
3/20
3/21
3/22

3/24

3/29

3/31
3/1

3/3
3/4
3/5
3/6
3/7
3/8
3/9

4/2
3/2

4/1
Deliver
Cost and Profitability
Resolving
Order
Environment outstanding
Manufacturing
preparation issues and re-
Plan and scheduling
testing
Demand planning
Source

= Morning session 8:30 - noon

= Evening session 12:30 - 5:00

• 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

38
System Test: Checklist

• Preparations
s Data source/cubes/ODS/queries prioritized
for testing
s Queries developed and available in the SAP
BW test environment
s Track specific test plans created using test
template
s Test cases written
• People
s Individuals (testers) perform the identified
tests
s Testers invited to complete SAP BW on-line
training
s Availability of testers confirmed
s Security roles tested and user ID’s for
testers have been created 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
s Held daily to monitor progress and resolve
common issues
s Attendees:
„ Business analysts, back-end
developers, query developers, test
coordinator, and Test Problem Report
(TPR) administrator
40
s
 Performance Testing

• Performance test execution

s Identify queries to be performance tuned, and
determine cutoff load for load test – e.g.
40% of actual users (not named)
s Schedule queries to run in background, and
execute each query while load scripts are
running to simulate “real” users
s Monitor your system continuously, and
attempt tuning at the query level
s Perform analysis based on benchmarks, and
build aggregates and/or indexes
s Record findings in a formal tracking tool
available to everyone
s Meet with developers daily to discuss issues
L o o k a t th e n e w B I
Problem
Ascce le ra to r resolution:
in S A P B I 7 . 0
fo r im p ro v e d
41
p e rfo rm a n ce ! ! ! Source: Alexander
Peter, SAP AG
Test Signoffs

• Signoff procedure
s Document test feedback and update logs
s Review open issues
s Prioritize outstanding issues
s Agree on scope decisions and resolutions
s Obtain approvals from business
representatives or steering committee
s

42
What We’ll Cover…

• Final Preparatory steps

• The Blueprinting Phase
• The Realization Phase
• The Implementation Phase
s Executing cut-over to production
s Conducting end-user and power user
training
s Establishing end-user support organization
s Post-implementation review and next steps
• Wrap-up

43
 Final Preparation Phase: Some Key
Observations
The
TheCutover
CutoverPlan
Planand
andthetheTechnical
Technical
Operations
Operations Manual describethe
Manual describe thedetails
details
on how to move to the production
on how to move to the production
environment
environmentand
andgogolive
live

Stress
Stress&&Volume
VolumeTests
Testsconfirm
confirmthe
the
production hardware’s capabilities
production hardware’s capabilities

The
TheEnd
EndUser
UserTraining
Trainingdocument
document
describes
describes the delivery of thenecessary
the delivery of the necessary
levels
levels of SAP training prior togoing
of SAP training prior to 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
• Web-based
„ All
us
ers
„ Traini
ng
„ Tutori
als
• Instructor-
led
„ On-
sit
e
„ Power
us
ers
„ Execu
tiv
es
• Vendor-
based 1 ) Create , or buy , an on - line help
„ Devel and training system . Make sure you
op use many images and links .
ers 2 ) Consider using animations to
„ Suppo demonstrate complicated tasks as 45
 Establishing End-User Support Organization

G e ttin g P o w e r U se rs in v o lv e d e a rly
is im p o rta n t to th e o v e ra ll su cce ss o f
a D a ta W a re h o u sin g p ro je ct
ly g roup
w etheon port s?
Are uild re
a n b
that c i n?
e rs jo
w c an oth
Ho olved
be in v
ho u ld ?
Whos ebusinesses
h
from t id e r an
d w econs pt?”
h oul o nc e
S
as s ador c
“Amb

To h e lp su p p o rt b u sin e sse s th a t h a v e
a lre a d y g o n e liv e , a stro n g lo ca l
co m m u n ity o f “ a m b a ssa d o rs ” is
needed.

Without them , ongoing projects can get 46

Go-Live: Some Key Observations

The
Thelast
lastdeliverable
deliverablefor
forthe
theimplementation
implementation
ensures
ensures high system performancethrough
high system performance through
monitoring and feedback
monitoring and feedback

Source: Pauline Woods-Wilson

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

AA“lessons
“lessonslearned”
learned”session
sessionshould
shouldbe
beheld
held
atatthe end of the project to assure
the end of the project to assure
organizational
organizationalawareness
awarenessandandeducation
Core Activities education
5 . 1 Production The
Support Thesupport
supportorganization
organizationwill
willtake
takeover
overthe
the
system after a pre-determined time period.
system after a pre-determined time period.
5 . 2 Project End Some
Someteam
teammembers
membersmaymaytransition
transitioninto
intotheir
their
new roles as support staff
new roles as support staff

This
Thisisisaacritical
criticaltime
timewhen
whenaa“SWAT”
“SWAT”team
team
that quickly addresses user concerns
that quickly addresses user concerns can can
make
makeallallthe
thedifference
differenceininhow
howthe
thesystem
systemisis
received
receivedamong
amongthe theusers
users

47
 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
• Load performance rate
100%

90%

80%

70%

60%

50%

40%

30%

20%

10%

0%
4/ 05
4/ 05

4/ 05

4/ 05
4/ 005

5/ 05

5/ 05

5/ 05
05
3/ 005

3/ 005

3/ 005
3/ 005

3/ 005

4/ 05

4/ 005

4/ 005

4/ 005

4/ 005

4/ 005

4/ 005

4/ 005

4/ 005

5/ 05
4/ 005
20

20
20

20

20

20

20

20
0

0
2
/2

/2

/2
/2

/2

/2

/2

/2

/2

/2

/2

/2

/2

/2

/2
/2
1/

3/

5/

7/

9/

1/

3/

5/

7/
20

22

24

26

28

30

13

15

17

19

21

23

25

27

29
11
3/

It is also a great way to document

your success !! 48
 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 Issues
Production
Performance
Nov. 1st through Dec. 15th
• Demand
7 Planning

Transaction -
global
6
Source -
Purchase
5 Orders
Roughcut
Number of Issues

4 Material
Movements

MD - Bev.
3 Packaging

Master data
2
Hierarchies
1
Greycon

12/12/04
12/13/04
12/14/04
12/15/04
12/10/04
CO -line items
12/1/04
12/2/04
12/3/04
12/4/04
12/5/04
12/6/04
12/7/04
12/8/04
12/9/04
11/29/04
11/30/04

12/11/04
11/14/04

11/18/04

11/23/04
11/10/04

11/12/04
11/13/04

11/15/04
11/16/04
11/17/04

11/19/04
11/20/04
11/21/04
11/22/04

11/24/04
11/25/04
11/26/04
11/27/04
11/28/04
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/11/04

49
 Go-live: Post-Implementation Review

Alignment Benefits
Are we doing Are we getting
the right the benefits?
things?

Are we doing Are we getting

them the right way? them done well?

Integration Capability/Efficiency
The Information Paradox: John
Thorp

50
What We’ll Cover…

• Final Preparatory steps

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

51
 Resources

a) Rapid Development by Steve

McConnell
• Paperback: 680 pages ; Publisher: Microsoft Press;
ISBN: 1556159005
•

• b) Start to Finish Guide to IT

Project D o w n lo a d it a t:

• Management by Jeremy Kadlec

• Digital: 109 pages. Publisher: NetImpress; ISBN:
B0000W86H2
•

• 52
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
•
53
Your Turn!!!

Questions?

How to contact me :
bberg@myitgroup . com
54