A Comprehensive Guide To Plan, Manage, and Execute a Successful SAP BW Implement

ation 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 Wri
ting a milestone plan Developing your staffing plan Budgeting On-boarding and tr
aining Writing your workplan Monitoring the progress of your project Monitoring
quality / instituting a formal approval process Why you need an SAP BW “user accep
tance group”
2
What We’ll Cover Now (In Part 2)…
•
Final Preparatory steps
s s s
Methodology details Lessons learned Requirements and approvals
• • • •
The Blueprinting Phase The Realization Phase The Implementation Phase Wrap-up
3
What We’ll Cover…
•
Final Preparatory steps
s s s
Methodology Lessons learned Requirements and approvals
• • • •
The Blueprinting Phase The Realization Phase The Implementation Phase Wrap-up
4
Project Preparation: Some Key Observations
Project charter: Represents an agreement Project charter: Represents an agreemen
t on, and commitment to, the deliverables of the on, and commitment to, the deli
verables of the project, as well as the time constraints, project, as well as th
e time constraints, resources, standards, and budget of the resources, standards
, and budget of the project. project. Project plan:This is the first cut. It foc
uses Project plan:This is the first cut. It focuses on milestones and work packa
ges. on milestones and work packages. Core Activities 1 . 1 Initial Project Plan
ning 1 . 2 Project Procedures 1 . 3 Training Preparation 1.4 Project Kickoff 1 .
5 Technical Requirements Planning 1 . 6 Quality Check Project Preparation Scope
: Sets the initial definition of the project. Scope: Sets the initial definition
of the project. Project team organization:Sets the ‘who’ of Project team organizati
on:Sets the ‘who’ of the project. It decides who will be involved, the project. It d
ecides who will be involved, and what their goal is. and what their goal is. Sta
ndards and procedures:Sets the ‘why’ and Standards and procedures:Sets the ‘why’ and ‘how’
f the project. Standardizes how ‘how’ of the project. Standardizes how meetings are
run, how documents are handled, meetings are run, how documents are handled, etc
. so everyone understands what is going on. etc. so everyone understands what is
going on.
Source: Pauline Woods-Wilson
This is what we covered in Part 1…
Note
5
What is ASAP?
Examples for Accelerators:
• Project Plan, Estimating • Design Strategies, Scope Definition • Documentation, Issu
es Db • Workshop Agenda • Questionnaires • End-User Procedures • Test Plans • Technical Pr
ocedures • Made Easy guidebooks (printout, data transfer, system administration…)
Fill in the Blank Fill in the Blank Versus Versus Start from Scratch Start from
Scratch
6
The ASAP Approach (from Part-1)
Integration Testing
No
Create Functional specs
No
Create Technical specs
System Testing
Complete? Yes Complete? Yes
Unit Testing
Yes
Configuration Peer Review
Yes No Approved?
Peer Review
No
Approved?
Complete? No
Yes
Structured walkthrough
No Complete? Yes
Structured walkthrough
7
Alternative Approach For Smaller Projects (I.E. 1st Go-live)
• •
Keep the scope focused and use a simple approach:
Activate standard content Request for modifications
Insco pe?
Yes No No
Make enhancements
Load infocube
User acceptance session
Review data quality issues
Create 2-3 sample queries
Rejection
No functional or technical specs are used in this approach . The user acceptance
session is used to refine requirements
Infutu re sco pe?
Test
Deploy
8
Critical Success Factors for SAP BW Projects
Individual The best people Backfilling Organizational End users on the team Comm
unication with users Documentation and training internal Breadth and depth of tr
aining Technological Platform sizing Testing tools Methodology Proper scope Lead
ership and commitment Budget for consulting and training Overseas contacts
Single location
Integration testing before releasing changes Do not modify code
Good SAP consultants
Source: Lee Schlenker
Note
These are lessons learned the hard way … Don ’ t re - invent the wheel -- learn from
others .
9
SAP Solution Manager
Upgrade Projects e-Learning Test Organizer Customizing Synchronization Implement
ation Platform Implementation Content Roadmaps Service Delivery Platform
New in 2004
Change Request Management Landscape Reporting Support Desk
Tool
Solution Monitoring Service Level Reporting
Content
Services Best Practice Documents
Gateway to SAP
SAP Support
Source: SAP AG
Was added in 2004
10
SAP BI Best Practices
•
This tool is still being enhanced, but has several BI-specific project accelerat
ors that you won’t find in SAP Solution Manager
•
Mostof h ep ctmaa gmettools ost M of ttep roje mn ae mn tt h roje ct a ng e e n
ools a b ttstffin gp lan in,,scop in,, ad b ou a ffin, la nin g in g n d aou st
a g , p n n g scop g a n workp n s a fou n h e ork la n re n d e re w p las a re
foud hre
A ttstd riveis a ila b ontteWe sit :: b Ae std is a va b leonh eW bsite e rive v
a ilale h e e https://m edia.sdn.sap.com l/subm itted% edia.sdn.sap.com /htm /ht
m l/subm itted% 5Fdocs/ 5Fdocs/ https://m Best% 5FPractices/BW 5FPractices/BW /
/ Best%
11
Option – Workplans Based on Deliverables
•
The best practice documents are organized around scenarios, which simplify the c
ollection 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 y o u r w o r
k p la n s
12
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:
Software Component Release Level Highest Support Package
mySAP • Application Component SAP BW
SAP_BASIS SAP_ABA
640 640
0004 0004
SAPKB64004 SAPKA64004
SAP_BW PI_BASIS BI_CONT
350 2004_1_640 352
0004 0004 0002
SAPKW35004 SAPKIPYI64 SAPKIBIEP2
Source: SAP - Sept - 2005
Note
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 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 th
is include:
s s s s s s
Ask for 1-2 days of uninterrupted time, and provide lunch on-site Invite power u
sers, 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 attende
es (no more than 20) Focus on shared information needs, and conduct multiple ses
sions if needed Don t get trapped in details; give people a You can use the sess
ion as an information chance to provide feedback in writing and sharing event ,
and give a brief overview of follow-up later with individuals
what you are attempting to do
14
What We’ll Cover…
• •
Final Preparatory steps The Blueprinting Phase
s s s
Leveraging the standard content Modeling your solution Deliverables
• • •
The Realization Phase The Implementation Phase Wrap-up
15
A Process Look at Getting Functional Specifications
Build storageConstruct Create a contact Create a tool to Gather Disposition Cons
olidate objects and reports and group and contact collect info information the i
nfo. requirements navigation ist for business requests and using the requests to
requests and write load programs features input and business input tool BW or R
/3functional specs requirements
Nm a e Joe on J es J sephones o J Joe on J es Joe on J es Joe on J es J sephones
o J Joe on J es Joe on J es Joe on J es J sephones o J Joe on J es J sephones o
J Joe on J es O a iza ion rg n t MYORG Ltd Your ORG Ltd MYORG Ltd MYORG Ltd MYO
RG Ltd Your ORG Ltd MYORG Ltd MYORG Ltd MYORG Ltd Your ORG Ltd MYORG Ltd Your OR
G Ltd MYORG Ltd P eN m r hon u be 918 - 234 - 1 123 918 - 234 - 1 123 123 - 234
- 1 123 918 - 234 - 1 123 918 - 8 - 123 123 918 - 9 - 123 123 918 - 234 - 1 123
918 - 234 - 1 123 918 - 234 - 1 123 918 - 234 - 1 123 918 - 234 - 1 123 918 - 23
4 - 1 123 123 - 234 - 1 123
Don t H o w e v e r, a fo rm a l process should exist to capture Forget re q u i
re 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 Appl
ication Development ) .
16
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 .
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
•
Best Practice
A single SAP BW "report" may satisfy dozens of today s static reports. It is the
refore Avoid attempting to replicate impossible to map each individual each repo
rt based on what you legacy report might have in place today . to a single BW Ac
cept 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
Tip •
•
s
•
• •
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 s
hould include at least the following fields:
s
•
• •
- Contact info about the requestor - Data currency (yesterday/today) - Departmen
t - Security requirements - Name of report - How is this reporting done today
18
Sample Info Request Form:
•
•
•
•
Document requirements in a standardized format Prioritize requirements Consolida
te requirements Support followTool up discussions and reviews.
•
P1 of 19 2
Sample Info Request Form:
•
Other uses:
s
s
Post the form on the Intranet, thereby giving stakeholders an easy way to commun
icate with the project team Use the Comment section for security requirements, o
r add a Tool separate section for
P2 of 20 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 of the "truth"), bu
t use different mechanisms to do so
•
KPI & Scorecard
Formatted •Simple •Easy to view •Limited nav •Aggregates
•
Managers and executives tends to prefer simple and directed interfaces Casual us
erstends to prefer predictable structured access to data Analysts and power user
s tend to prefer high flexibility and unstructured access OR OR to data
Flat Reporting
•
•Formatted •Print •Form based •Static •Predictable access
•
•
OLAP Reporting
•
•
•Drill Down •Slice and Dice •Analyse •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 the right requirements: Getting the right requirements: Finding out the
detailed functional Finding out the detailed functional specs of what users real
ly need and specs of what users really need and not just what they want. not jus
t what they want. Deciding what will be developed in Deciding what will be devel
oped in SAP BW and what will be maintained SAP BW and what will be maintained as
R/3 reports. as R/3 reports. Map the functional requirements to the Map the fun
ctional requirements to the standard content, and see what can standard content,
and see what can be leveraged and what needs to be be leveraged and what needs
to be extended. extended. Create detailed technical Create detailed technical sp
ecifications and designs of specifications and designs of infocubes, masterdata,
ODSs, and infocubes, masterdata, ODSs, and high-level architectural designs. hi
gh-level architectural designs. Create user acceptance group(s), and Create user
acceptance group(s), and have them review and give feedback have them review an
d give feedback on the system as ititis developed. on the system as is developed
.
24
Core Activities 2 . 1 Project Management Business Blueprint 2 . 2 Organizational
Change Management 2 . 3 Project Team Training Business Blueprint Environment 2
. 4 Develop System 2 . 5 Organizational Structure Definition 2 . 6 Business Proc
ess Definition 2 . 7 Quality Check Business Blueprint
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 repo
rts that truly belong in R/3, which would not be cost effective to move to SAP B
W Make cost-effective decisions; just because the report is not in SAP BW does n
ot mean it cannot be added to a Portal or viewed on the Web Not all reports belo
ng 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 a
n approach to formal report meet, and how you will a few companies. dispositioni
ng that has been used by accomplish this
25
•
Warning
•
•
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 rep
ort available in R/3? Does standard BW content exist? Is it less expensive to cr
eate the report in R/3? Are there a significant number of users? Is the reportin
g need resource-intensive? Is SAP BW cost effective in the long run
26
Team starts by reviewing documentation tool for documentation completeness
cu
Review requirements and identify corresponding Data Model (InfoCube/ODS)
Tool
D1a Is this a true reporting need Yes No Communicate to bus. leader
D1 Is report documentation complete?
An example of how to decide which reports should be in R / 3 or the legacy syste
m
( refer to printed version )
Yes
No
Request additional input from Business Team member
D2 Is this an Intraday report?
No
D2.5 Does data exist in "in-scope" models Infocube/ODS
No
D3 Significant number of users?
No
D4 Is the report system resource intensive?
No
Yes R/3 is selected as Reporting Tool and documented
Yes A2 Total Cost of Ownership Analysis
Yes
R/3 is selected as Reporting Tool and documented in doc. tool
Responsible Team member acquires/documents additional information
Communicate final disposition Yes D5 Does Standard R/3 content exist? D7 Is it l
ess expensive to create in R/3? Yes R/3 is selected as Reporting Tool and docume
nted in doc. tool BW is selected as Reporting Tool and documented in doc. tool B
W is selected as Reporting Tool and documented in the documentation tool
D8 Is BW cost effective?
No
R/3 is selected as Reporting Tool and documented in doc. tool
Yes
No
Yes D9 R/3 Tool Selection Process
Communicate final disposition
D6 Does Standard BW content exist? Yes BW is selected as Reporting Tool and docu
mented in doc. tool
No
Communicate final disposition No
BW is selected as reporting tool and Change Request is submitted if the scope ch
anged
Standard R/3 Communicate final disposition ABAP/ Custom Query
Report Writer Other
Communicate final disposition
Communicate final disposition
Communicate final disposition
A3 Sub-Process Report Consolidation & eliminate if appropriate (winnowing) R/3 t
eam make final disposition
BW Team to forward completed detailed report specifications based on selected Re
porting 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 acr
oss your organization)
s
s
s
Great Feature
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 pa
per copies of these legacy reports M any Make sure that the development team re
q u ire m e n ts ca n b e m e t b y has access to them -- this will reduce a sin
g le S A P the time spent in meetings with the business community B W re p o rt
+
+
=
28
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
Mostly standard storage objects Some customization Highly customized storage obj
ects
31%
36%
•
33%
An example from a large manufacturing company
BW Content available BW Content available
((3 ..5 ..1 )) 3 5 1
::
•
•Cockpits ??? •Workbooks 1,979 •Queries 3,299 •Roles 861 •MultiCubes 121 • •InfoCube 605 •O
jects 349 •InfoObjects 11,772
29
The Blueprinting Phase: Model Your Solution
1. Create a model based on pre-delivered SAP BW content 2. Map your data require
ments to the delivered content, and identify gaps 3. Identify where the data gap
s are going to be sourced from
Material Material number Material entered Material group Item category Product h
ierarchy EAN/UPC Logistics Plant Shipping/receiving point Unit Currency Key Unit
of Measure Base unit of measure Sales unit of measure Volume unit of measure We
ight unit of measure Billing information Billing document Billing item Billing t
ype Billing category Billing date Creation date Cancel indicator Output me dium
~ Batch billing indicator Debit/cre dit re ason code Biling category Reference d
ocument Payment terms Cancelle d billing docume nt Divison for the order header
Pricing proce dure Document details Sa les order docume nt type Sales deal Sales
docuement
Storage Requirements
Billing Number of billing documents Number biling line items Billed item quantit
y Net weight Subtotal 1 Subtotal 2 Subtotal 3 Subtotal 4 Subtotal 5 Subtotal 6 S
ubtotal A Net value Cost Tax amount Volume
Customer Sold-to Ship-to Bill-to Payer Customer cla ss Customer group ~ Custome
r country ~ Custome r region ~ Custome r postal code ~ Custome r industry code 1
End user Organization Company code Division Distribution channel Sales organiza
tion Sales group
+
Standard content
Personnel Sales rep number
Accounting Cost center Profit ce nter Controlling area Account a ssignme nt grou
p
Time Calendar Calendar Calendar Calendar year month week day
Map functional requirements to the standard content before you make enhancements
LEGEND Delivered in standard extractors Delivered in LO extractor Not in deliver
ed Content -but in R-3
Storag e Object s
30
Standard Content Vs. Customization
•
•
100 80 60 40 20 0
Approximate Usage of Standard Content BW 3.5
(percentage of overall development effort)
All functional areas are not equally supported by strong standard SAP BW busines
s content. Some areas have much you can leverage, others will require significan
t enhancement to meet your requirements
The differences are often due to customization on the R/3-side by companies and/
or industry solutions.
CO AP O m gm t
FI
rib ut io n
SC EM *
*
es
CR M
ur in
Sa l
an uf ac t
Di st
Qu a
In ve n
lit y
to ry
g
* Rapidly improving content
31
M
What We’ll Cover…
• • •
Final Preparatory steps The Blueprinting Phase The Realization Phase
s s
s
s
Building ODSs and InfoCubes Planning, Managing and executing system test Plannin
g, Managing and executing integration and performance test Issue resolution, log
s, 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 Man
agement 3.3 Training Realization 3.4 Baseline Configuration and reviewsSystem Ma
nagement 3.5 3.6 Final Configuration and Confirmation 3.7 Prepare & Coordinate i
nterface development 3.8 Develop Data Conversion Programs ( if any ) 3.9 Develop
Queries 3 . 10 Develop User interface 3 . 11 Determine additional enhancements
3 . 12 Create structured reports reporting requirements 3 . 13 Establish Authori
zation 3 . 14 Establish Data Archiving plan Concept 3if applicable ) ( . 15 Fina
l Integration Test 3 . 16 Quality Check Realization
Development Programs: Provide Development Programs: Provide details of added pro
gramming details of added programming structures structures End User Training Ma
terial End User Training Material Configuration and Testing Plans: Configuration
and Testing Plans: Define how the configuration will be Define how the configur
ation will be 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 the functional requirements and allow exceptions to your naming 1 Do
not 6 conventions technical design Make sure you have establishedMake 7 2 Datas
ure that “putting out fires” does not Stewards for master data, and assign take prec
edence, becoming the master data to specific developers “default” architecture and s
tandard.
Have your ETL developers work Try new ideas in a sandbox environment , 3 8 for t
he individual who is responsible don’t contaminate the development and environment
. for creating process chains
(organizationally )
Avoid nested ODS layers, and keep thedetails for multi-use in the ODS and 4 Keep
9 architecture as pristine as possible not design the ODS based on the needs do
of a single infoCube. Make your transformations part Developers must unit test
all of their 5 of 10 update rules into infocubes if you need work and 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 , pote
ntially 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 th
e execution is ….
36
System Test: Planning
Tasks\Dates Identify People for Testing Schedule Facilities Prioritize Test Area
s (Queries) Send out Meeting Notice Execute System Test Document Results Problem
Resolution
•
December 2003 January 2004 February 2004 1-Mar 8-Mar 15-Mar 22-Mar 29-Mar 5-Apr
to o time re s n There r gas, we " o sto p f y lat e" alread
Activitie s
Tasks
6 7 8 9 Identify key contacts Communicate about transports Arrange time for prog
ress control Schedule facilities
11 1 1 1 1 1 1 1 1
• 1 Create test script 2 Identify s roles to be used 3 Documentation on using test
tools s 4 Procedure for documenting test results 5 Training sessions for using
test scripts
Business analysts are responsible for planning , coordinating , and executing th
e system testing of queries .
Timing
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 Order Environment Manufacturing preparation Plan
and scheduling Demand planning Source = Morning session 8:30 - noon = Evening se
ssion 12:30 - 5:00
Resolving outstanding issues and retesting
•
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 m
ust be logged
38
• •
•
System Test: Checklist
•
Preparations
s
s
s
s
Data source/cubes/ODS/queries prioritized for testing Queries developed and avai
lable in the SAP BW test environment Track specific test plans created using tes
t template Test cases written Individuals (testers) perform the identified tests
Testers invited to complete SAP BW on-line training Availability of testers con
firmed Security roles tested and user ID’s for testers have been created 39
•
People
s
s
s s
Integration Test: Planning
Tasks\Dates Identify People for Testing Schedule Facilities Prioritize Test Area
s (Queries) Send out Meeting Notice Execute System Test Document Results Problem
Resolution March 2004 29-Mar 5-Apr 12-Apr 19-Apr 26-Apr 3-May 10-May 17-May
•
Progress meeting
s
s
Held daily to monitor progress and resolve common issues Attendees: Business ana
lysts, back-end developers, query developers, test coordinator, and Test Problem
Report (TPR) administrator
s
40
Performance Testing
•
Performance test execution
Identify queries to be performance tuned, and determine cutoff load for load tes
t – 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 Mon
itor your system continuously, and attempt tuning at the query level s Perform a
nalysis based on benchmarks, and build aggregates and/or indexes s Record findin
gs 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 in S A P B I 7 Ascce le ra
to r resolution: . 0 fo r im p ro v e d 41 p e rfo rm a n ce ! ! !
s
Source: Alexander Peter, SAP AG
Test Signoffs
•
Signoff procedure
s s s s s
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
s
42
What We’ll Cover…
• • • •
Final Preparatory steps The Blueprinting Phase The Realization Phase The Impleme
ntation Phase
s s
s s
Executing cut-over to production Conducting end-user and power user training Est
ablishing end-user support organization Post-implementation review and next step
s
•
Wrap-up
43
Final Preparation Phase: Some Key Observations
The Cutover Plan and the Technical The Cutover Plan and the Technical Operations
Manual describe the details Operations Manual describe the details on how to mo
ve to the production on how to move to the production environment and go live en
vironment and go live Stress & Volume Tests confirm the Stress & Volume Tests co
nfirm the production hardware’s capabilities production hardware’s capabilities The
End User Training document The End User Training document describes the delivery
of the necessary describes the delivery of the necessary levels of SAP training
prior to going live levels of SAP training prior to going live
Core Activities 4 . 1 Project Management Final Preparation 4 . 2 Training Final
Preparation 4 . 3 Acceptance Testing 4 . 4 System Management 4 . 5 Detailed Proj
ect Planning 4 . 6 Cutover 4 . 7 Quality Check Final Preparation
Source: Pauline Woods-Wilson
44
Conducting End-User and Power User Training
•
•
•
Web-based All us ers Traini ng Tutori als Instructorled Onsit e Power us ers Ex
cu tiv es Vendorbased Devel op ers Suppo
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 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
up ly gro ? n e o w the ild re o ts pr Are n b u that ca ? r i e s jon th wcan o
Ho l d invove e u b s s ho ld ne se ? Whos eb si u m o th fr ide an n r co s e
t?” e u w r n ho ld ado co c p S mb ss A a “
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 the
m , ongoing projects can get
46
Go-Live: Some Key Observations
The last deliverable for the implementation The last deliverable for the impleme
ntation ensures high system performance through ensures high system performance
through monitoring and feedback monitoring and feedback
Source: Pauline Woods-Wilson
We need to execute issue resolution plans We need to execute issue resolution pl
ans and contingency plans and contingency plans A “lessons learned” session should b
e held A “lessons learned” session should be held at the end of the project to assur
e at the end of the project to assure organizational awareness and education org
anizational awareness and education The support organization will take over the
The support organization will take over the system after aapre-determined time p
eriod. system after pre-determined time period. Some team members may transition
into their Some team members may transition into their new roles as support sta
ff new roles as support staff This is aacritical time when aa“SWAT” team This is cri
tical time when “SWAT” team that quickly addresses user concerns can that quickly ad
dresses user concerns can make all the difference in how the system is make all
the difference in how the system is received among the users received among the
users 47
Core Activities 5 . 1 Production Support 5 . 2 Project End
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 perfo
rmance rate
100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%
/2 3/ 005 22 /2 3/ 005 24 /2 3/ 005 26 /2 3/ 005 28 /2 3/ 005 30 /2 0 4/ 05 1/ 2
0 4/ 05 3/ 20 4/ 05 5/ 20 4/ 05 7/ 20 4/ 05 9/ 2 4/ 005 11 /2 4/ 005 13 /2 4/ 00
5 15 /2 4/ 005 17 /2 4/ 005 19 /2 4/ 005 21 /2 4/ 005 23 /2 4/ 005 25 /2 4/ 005
27 /2 4/ 005 29 /2 0 5/ 05 1/ 20 5/ 05 3/ 20 5/ 05 5/ 20 5/ 05 7/ 20 05 3/ 20
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 chain
s has been tuned in the production box This is a time when active monitoring of
process Production chains should of BW Data Load Issues Areas occur Performance
Nov. 1st through Dec. 15th
Demand Planning Transaction global Source Purchase Orders Roughcut Material Move
ments MD - Bev. Packaging Master data Hierarchies
7 6 5
Number of Issues
•
4 3 2 1
Greycon
12/12/04 12/13/04 12/14/04 12/15/04 12/10/04 12/1/04 12/2/04 12/3/04 12/4/04 12/
5/04 12/6/04 12/7/04 12/8/04 11/29/04 11/30/04 12/9/04 11/14/04 11/18/04 11/23/0
4 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 12/11/04 11/1/04 11/2/0
4 11/3/04 11/4/04 11/5/04 11/6/04 11/7/04 11/8/04 11/9/04 11/11/04
0
CO -line items
49
Go-live: Post-Implementation Review
Alignment
Are we doing the right things?
Benefits
Are we getting the benefits?
Are we doing them the right way?
Are we getting them done well?
Integration
The Information Paradox: John Thorp
Capability/Efficiency
50
What We’ll Cover…
• • • • •
Final Preparatory steps The Blueprinting Phase The Realization Phase The Impleme
ntation Phase Wrap-up
51
Resources
•
a)
•
McConnell
ISBN: 1556159005
Rapid Development by Steve
Paperback: 680 pages ; Publisher: Microsoft Press;
•
•
•
•
•
b)
Project
B0000W86H2
Start to Finish Guide to IT
D o w n lo a d it a t:
•
•
Management by Jeremy Kadlec
Digital: 109 pages. Publisher: NetImpress; ISBN:
• • • • • • • •
52
7 Key Points to Take Home
• •
•
• •
•
•
Keep the team relatively small & focused Size your project based on your team’s ex
perience and skills, in addition to scope Make the implementations interactive i
nstead of “Big-Bang” Follow a proven methodology Don’t cram all of your reports into B
W (some belong in R/3) Track quality, and create a formal approval process Invol
ve power users and ambassadors in the development project
53
•
Your Turn!!!
Questions?
How to contact me : bberg@myitgroup . com
54