An A-Z guide to planning,
managing, and executing a
Global SAP NetWeaver BI
project
- Part 2
Dr. Bjarne Berg
Director SAP BI
© 2007 Wellesley Information Services. All rights reserved.
What We’ve Covered So Far (in Part 1)…
•
•
•
•
•
•
•
•
•
•
Writing your Global SAP BI business case
Defining the scope of your implementation
Writing a milestone plan
Developing your global staffing plan
Budgeting
Comprehensive On-boarding and training
Writing your workplan
Monitoring the progress and risks of your global project
Monitoring quality / instituting a formal approval process
Why you need an SAP BI “user acceptance group”
2
What We’ll Cover Now (In Part 2)…
•
Final Preparatory steps



•
•
•
•
Methodology details
SAP BI Global Lessons learned
Requirements and approvals
The Blueprinting Phase
The Realization Phase
The Implementation Phase
Wrap-up
3
What We’ll Cover…
•
Final Preparatory steps



•
•
•
•
Methodology
SAP BI Global 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
on, and commitment to, the deliverables of the
project, as well as the time constraints,
resources, standards, and budget of the
project.
Project plan: This is the first cut. It focuses
on milestones and work 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: Sets the initial definition of the project.
Project team organization: Sets the ‘who’ of
the project. It decides who will be involved,
and what their goal is.
Standards and procedures: Sets the ‘why’
and ‘how’ of the project. Standardizes how
meetings are run, how documents are handled,
etc. so everyone understands what is going on.
This is what we covered in Part 1…
Note
Source: Pauline Woods-Wilson
5
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…)
6
The ASAP Approach (from Part-1)
Integration
Testing
Create Technical
specs
No
Create Functional
specs
System Testing
Complete?
No
Yes
Unit Testing
Complete?
Yes
Configuration
Yes
Peer Review
No
Approved?
Peer Review
Yes
No
Complete?
Yes
Approved?
Structured
walkthrough
No
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
Inscope?
Yes
Make
enhancements
No
Load infocube
User
acceptance
session
Test
In-future
scope?
No
Review data
quality issues
Create 2-3
sample queries
Deploy
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 Global SAP BI Projects
Individual
Organizational
Technological
Methodology
The best people
End users on the team
Platform sizing
Proper scope
Backfilling
Communication with
users
Testing tools
Leadership and
commitment
Few locations
(keep it focused and
have many rollouts)
Documentation and
training internal
Integration testing
before releasing
changes
Budget for
consulting and
training
Good SAP
consultants
Breadth and depth of
training
Do not modify code
Overseas contacts
Source: Lee Schlenker
These are lessons learned the hard way…
Don’t re-invent the wheel--learn from others.
Note
9
SAP Solution Manager
Upgrade Projects
New in
2004
e-Learning
Landscape Reporting
Test Organizer
Support Desk
Customizing
Synchronization
Tool
Implementation
Content
Content
Services
Best Practice
Documents
Roadmaps
Service Delivery
Platform
Solution Monitoring
Service Level
Reporting
Implementation
Platform
Source: SAP AG
Change Request
Management
Gateway to SAP
SAP Support
Was added in 2004
10
SAP BI Best Practices – some hints
This tool is still being
enhanced, but has
several BI-specific
project accelerators
that you won’t find in
SAP Solution
Manager.
It has been available
for 4 years. The
current release is
version 1.7 (as of
August 2007)
You can access SAP BI Best Practices for BI
at: http://help.sap.com/bp_biv170/index.htm
11
Option – Workplans Based on Deliverables
The best practice documents are organized around scenarios,
which simplify the collection of tools
Source: SAP – Aug, 2007
12
SAP BI Best Practices – What Versions Does It Support?
SAP BI 7.0
The SAP Best
Practices tool was
developed for SAP BI 3.5,
and later updated for SAP
BI 7.0.
SAP
App.
Compon
ent
Software
Component
Release
Level
Highest
Support
Package
SAP BW
SAP_BASIS
700
0007
SAPKA70007
SAP_ABA
700
0007
SAPKA70007
SAP_BW
700
0007
SAPKW70007
PI_BASIS
2005_1_700
0007
SAPKIPYJ77
BI_CONT
702
0004
SAPKIBIHP4
SCM
500
0002
SAPKY50002
SAP_BW
700
0005
SAPKW70005
SAP_BASIS
700
0005
SAPKB70005
SAP_ABA
700
0009
SAPKA70005
SAP_BASIS
700
0007
SAPKA70007
SAP_ABA
700
0007
SAPKA70007
SAP_APPL
600
0004
SAPKH60004
PI_BASIS
2005_1_700
0007
SAPKIPYJ77
SAP_BASIS
700
0007
SAPKA70007
SAP_ABA
700
0007
SAPKA70007
BBPCRM
500
0004
SAPKU50004
PI_BASIS
2005_1_700
0007
SAPKIPYJ77
SAP SCM
SAP BI 3.5
mySAP
Application
Component
SAP BW
Software
Component
Release
Level
Highest Support
Package
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 – Jan, 2007
SAP ERP
2005
SAP CRM
While install recommendations are based on SAP BI 3.5/ or BI 7.0, most management
tools, accelerators, and the sample work plan are not version-specific
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:

Ask for 1-2 days of uninterrupted time at each location, and provide lunch
on-site (global requirements gathering take 2-3 times more time -- plan for it)

Invite power users, casual users, today's report writers, and managers

Remove cell phones, PDA, pagers, and email access

Keep a rapid pace, and a manageable number of attendees (no more than 20)

Focus on shared information needs, and conduct multiple sessions if
needed

Don't get trapped in details; give people a chance to provide feedback in
writing and follow-up later with individuals
You can use the session as an information sharing event, and give a
brief overview of what you are attempting to do
14
What We’ll Cover…
•
•
Final Preparatory steps
The Blueprinting Phase




•
•
•
Some Global Case Studies
Leveraging the standard content
Modeling your solution
Deliverables
The Realization Phase
The Implementation Phase
Wrap-up
15
Let’s Look at a Global BI Project Example
A case study
•
•
•
•
Fortune 100 company with operations around the world
230 systems identified as “mission critical”
23 installations of SAP R/3 on 6 continents
Other ERP systems:


JD Edwards
Custom-developed Oracle systems
16
Global Data Warehouse Initiatives
A case study
These were the DW initiatives that
corporate HQ knew about
17
Rationale for a “Bottom-Up” Global SAP BI Approach
Improved Project
Management
 Enables future
migration of
standardized data
architecture to a Global
DSS architecture
through standard local
solutions.
 Ensures higher quality
of local deliveries and
projects through
increasing focus on
providing local
solutions.
Improved Cost
Efficiency
 Minimizes local investments through a
consolidated hardware
environment.
 Leverages buying
power in front of
vendors through provision of guidelines
and corporate
agreements.
 Enables lower
development costs
through centralized
user documentation
and training.
 Establishes a better
working environment
between local units and
central project
 Substantially reduces
management through
ABAP report
the positioning as a
programming costs
“Competency Center for
through providing
Local Needs”.
support for an efficient
SAP BW roll-out.
A case study
Secured Commonality
across Company
Leveraged SAP
Decision Support
 Ensures use of
common definitions.
 Provides users with a
fast way to integrate
ERP reporting to
advanced standardized decision
support systems
through simplifying the
roll-out of SAP BW
 Enables the inclusion
of future SAP-based
standard decision
support modules
(SEM, EC and others).
 Ensures uniformity
through eliminating
options to develop
regional, functional or
non-standard
solutions.
 Provides centralized
testing of vendor
software (combined
with ESOE etc).
 Using ONE
methodology - one
way of working.
 Reduces delivery time
of decision support for
SAP R/3 through
usage of a
standardized
application.
 Ensure reusability.
 Reusability will ensure
commonality !
 Creates a
Competence Center
for SAP BW.
18
Global SAP BI Activities, Priorities and Architecture
4. Migrate existing solutions into Company
architecture
3. After local solutions are implemented and
standardized, consolidation to a Global
Data Warehouse is simplified and faster
2. Coordinate development
efforts and activities:
-Tool selection
-Methodology
-Organization
-Deliverables
-Data standards
-Training
-Documentation
A case study
Global DW
SAP
BW
DW
Local
DW
Local
DW
Oracle
Sybase
MVS
Others
Oracle
Sybase
MVS
Others
5. Install SAP BW based solutions
(SEM, EC and consolidated BW)
for business and financial
management together with Shared Financial Services
Local
DW
Oracle
Sybase
MVS
Others
SAP
BW
SAP
BW
SAP
BW
SAP
BW
SAP
R/3
SAP
R/3
SAP
R/3
1. Test, productify
SAP BW and install
standard
solution(s) locally:
-Software
-Hardware
-Testing
-Training
-Documentation
19
An Approach to BI Global Architecture Development
BISC (Business Information Supply
Chain) Responsibilities
SAP Business Warehouse
 BISC would take the responsibility for productfying and installing SAP BW standard solutions
locally, including software, hardware, testing,
training and documentation.
 BISC could support for SAP BW based solutions
for business and financial management (SEM,
EC and consolidated BW together with SFSC
etc).
Global DW
SAP
BW
DW
Local
DW
Oracle
Sybase
MVS
Others
Local
DW
Oracle
Sybase
MVS
Others
Local
DW
Oracle
Sybase
MVS
Others
SAP
BW
Local Data Warehouses
SAP
BW
SAP
BW
SAP
BW
SAP
R/3
SAP
R/3
SAP
R/3
 BISC coordinates development efforts and
activities within the Data Warehousing field at
Company. This includes guidelines on tool
selection,
methodology,
organization,
deliverables, data standards, training and
documentation.
Global Data Warehouse
 BISC has the overall responsibility to establish
the Global DW within Company, which is
achieved through prioritizing development of
consistent local DW solutions enabling our long
20
term goals.
SAP BI Global Rollout Approach
• The
CHANGE
“Bottom-Up
Fixed Departure”
Departure I - 3 months
•A
Departure II - 3 months
Departure III - 3 months
Departure IV - 3 months
A case study
project delivered local SAP
BI solutions and packaged
solutions for decision support as
a first priority, and the Global
Data Warehouse as a second
priority.
“fixed departure approach”
was applied with focus on
delivering solutions rather than
projects and software; specific
BI solutions were developed
according to a pre-defined
schedule where local business
units were invited or encouraged
to participate.
21
A Global Rollout – a Different European Example
UK
North West (Den Haag)
Ireland
Local
Local
AMC/Dev
AMC/Dev
Spiridon
Spiridon
/CRM
/CRM
BW
Spiridon
others
CRM
CRM (one client)
Global
Development
Spiridon/CRM
Netherland
s
Mid South (Wien)
BW
Local
AMC/Dev
BW
others
BW
Local
AMC/Dev
Spiridon
/CRM
Spiridon
e.p@ss
/CRM
e.p@ss
Austria
South West (Madrid)
Portugal
others
Switzerland
CRM
Turkey
Belgium
CRM
Spain
Source: Siemens Corp information 2004
In this case, the company created both a local
and global BI system for CRM data
22
Some Lessons Learned From Other Global Implementations
Very large
global telecom Co.
BW version
Largest
Volume
Lessons
learned
3.1c
3.1c
5-20 million
Largest cubes have 18.8
transactional records million, 18.4 million, and
in FI cubes
11.2 million records
each.
Keep scope and
Should not have gone
development effort
“live” on 1.2a, should
focused, use more
have used more than
than one
one presentation tool.
presentation tool,
The extract and load
don’t underestimate
process is the most
the extract and load
complex, strong BW
effort
experience is essential
Standardized global
reporting
Creation of corporate
enterprise-wide data
warehouse
Very happy with
implementation
added 3 more
countries last year
Overall happy. Have
accomplished in 6
months what would
have taken 5 years.
Business
drivers
Success
Note
Global oil co.
Fortune-500
Retailer
Global oil co.
3.0b
35 million rows
3.2
120 million records in
sales, and 230GB in
Sales and finance
Data movement is
Custom coding cannot
the most complex
overcome the BW
part of BW. The
extractors. Integration
project would not
with non-R/3 data was
have accepted as
technically easy, but
many enhancements
conceptually hard.
if done again.
The team members must
You need a really .
have solid BI skills
strong BI architect
SAP R/3 was being Custom global reporting
installed, and SAP
has a too-high cost
BW is the reporting of ownership and is too
strategy for all key hard to manage. Want
performance
content and features.
indicators
Is being rolled out to Very happy with the
more subsidiaries
speed of delivery and
and management is
user satisfaction
pleased with results
The major findings highlight the need for specialized BI
skills and very strong scope control…
23
Global Examples Summary
• A conceptual architecture is the first
step and the physical architecture is a
product of this. It should be driven by
the user needs and the types of
interfaces needed, and not by an internal
IT exercise.
• SAP BI can now be used as an
enterprise Data Warehouse and a Global
rollout can be accomplished.
• There are two core ways to succeed, but
both require strong central control and
support.
24
A Process Look at Getting Functional Specifications
Create a contact
group and contact
list for business
input and
requirements
Name
JoeJones
JosephJones
JoeJones
JoeJones
JoeJones
JosephJones
JoeJones
JoeJones
JoeJones
JosephJones
JoeJones
JosephJones
JoeJones
Organization
MYORG Ltd
YourORG Ltd
MYORG Ltd
MYORG Ltd
MYORG Ltd
YourORG Ltd
MYORG Ltd
MYORG Ltd
MYORG Ltd
YourORG Ltd
MYORG Ltd
YourORG Ltd
MYORG Ltd
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
Don't
Forget
Create a tool to
collect info
requests and
business input
Gather
Disposition
information the info.
requests to
using the
tool. Plan
BW or R/3
traveling
Consolidate Build storage
requirements objects and
load programs
and write
functional
specs
Construct
reports and
navigation
features
starts by
documentation
tool for
TeamTeam
starts
byreviewing
reviewing
documentation
tool for
documentation
completeness
Review requirements
identify
corresponding
Data Modeland
(InfoCube/ODS)
D1
D1aa true No Communicate to
Is report
Is this
bus. leader
documentation
complete? Yes reporting
need
Yes
D4report
No
D2
D2.5 exist No Significant
D3
Is system
the
this
No Does
anIs
Intraday
in -"indatamodels
scope"
report?
Infocube/ODS
ofnumber
users? No resource
Request
additional
intensive? No
input
frommember
Business
Team
Yes
Yes
R/3
is selected
as
Yes
Reporting
Tool
R/3
is selected
selected
as as
and
is
A2
Reporting
Tool
indocumented
doc. tool
Total
Cost of
and
documented
Ownership
Responsible
Analysis
Team
member
acquires/documents
additional
information
R/3
is selected
as
Communicate
Reporting
Tool
D8cost Noand
dispositionfinal
Iseffective?
BW
indocumented
doc. tool
Yes
BW
is selected
as
D5
Communicate
Reporting
Tool
Does
Yes
disposition final
documented
Yes
Standard
R/3 Noin and
the
documentation
tool
content
exist?
BW
is selected
R/3D9Tool
D6
reporting
andasChangeSelection
Does
Request
istool
submitted
Communicate
Is itD7
less to
the scope
changed if Process
Standard
BW No expensive
disposition final
content
create
No
exist?
R/3? in
Standard Report
Yes as
Yes
ABAP/R/3QueryWriter
BW
is selected
BW
is selected
R/3
is selected
as Reporting
Other
Reporting
Tool and Reporting
Tool
Tool as
andCommunicate
dispositionfinalCustom
documented
documented
tool in doc. andindocumented
tool in doc.
doc. tool
A3 Consolidation &
Process
Sub
- ifReport
eliminate
appropriate
(winnowing)
Communicate
disposition final Communicate
disposition final Communicate
disposition final
R/3 team make final disposition
BW Team
to forward
completed
detailed
based
on selected
BW
- Reporting
or R/3
Toolreport specifications
A4reports
Baseline
There is more than one way to collect this information. However, a formal process
should exist to capture requirements & communicate what is being developed.
We will now examine the most common form of RAD
(Rapid Application Development).
25
Getting the Global Functional Specifications
Note
•
Avoid taking a total inventory of all reports in the
global organization. The "top-5" (most used) sales,
distribution, inventory etc. reports from each
geographical location will cover the vast majority of
the reporting needs.
•
A single SAP BI "report" may satisfy dozens of
today's static reports. It is therefore impossible to
map each individual legacy report to a single BI
report.
Avoid attempting to replicate each local report
based on what you might have in place today.
Accept new ways of accessing data.
26
Getting the Global Functional Specifications (cont.)
•
Create a form that captures the business’ core requirements
in a structured format
Create a simple Information Request Form, and use
it to gather the core relevant information about each report
being requested by the business community. This should
include at least the following fields:
- Contact info about the requestor
- 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
27
Sample Info Request Form:
•
Document requirements
in a standardized
format and allow for a
large comment section
•
Prioritize requirements
•
Consolidate
requirements
•
Support follow-up
discussions and
reviews.
P1 28
of 2
Sample Info Request Form:
•
Other uses:

Post the form on the
Intranet, thereby giving
stakeholders an easy way to
communicate with the
project team

Use the Comment section
for language and security
requirements, or add a
separate section for this.

Note the section for
dispositioning the
requirement
P2 29
of 2
An
Example
30
An
Example
31
Consider Multiple Country Views of Displaying the Same Data!!
•
Deliver reports in a consistent manner to
users (one version of the "truth"), but use
different mechanisms to do so

Managers and executives tends to prefer simple
and directed interfaces

Casual users tends to prefer predictable structured
access to data

Analysts and power users tend to prefer high
flexibility and unstructured access to data
KPI & Scorecard
Formatted
• Simple
• Easy to view
• Limited nav
• Aggregates
Flat Reporting
• Formatted
• Print
• Form based
• Static
• Predictable access
OLAP Reporting
• Drill Down
OR
OR
• Slice and Dice
• Analyse
• Data Mining
• Search and discover
Don't underestimate different users in various countries and their need to
access the information in various ways -- one size does not fit all!
32
Blueprinting Phase: Some Key Observations
Getting the right requirements:
Finding out the detailed functional
specs of what users really need and
not just what they want.
Deciding what will be developed in
SAP BI and what will be maintained
as R/3 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 the functional requirements to the
standard content, and see what can
be leveraged and what needs to be
extended.
Create detailed technical
specifications and designs of
infocubes, masterdata, ODSs, and
high-level architectural designs.
Create user acceptance group(s), and
have them review and give feedback
on the system as it is developed.
33
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 BI does not mean it cannot be added to a Portal or viewed
on the Web
Warning •
•
Not all reports belong in SAP BW; avoid using SAP BI as a
"dumping group"
You need to make conscious decisions on what reporting
needs you are going to meet, and how you will accomplish this
We will now take a look at an approach to formal report
dispositioning that has been used by a few companies.
34
Key Questions for Report Dispositioning
•
Is this really a reporting need, or a "want"?
•
Is the data going to be in SAP BI at a frequency that solves the
user's request (e.g., intraday reporting)?
•
Is the data needed for this report already in our SAP BI scope?
•
Is there already a report available in R/3?
•
Does standard BI 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 BI cost effective in the long run (ownership)?
35
Team starts by reviewing documentation tool for
documentation completeness
An example of how to decide
which reports should be in R/3 or
the legacy system
cu
Review requirements and identify
corresponding Data Model (InfoCube/ODS)
D1
Is report
documentation
complete?
Yes
D1a
Is this a true
reporting
need
No
(refer to printed version)
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 BI 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 - BI or R/3
A4
Baseline reports
36
Now That You Have Identified the In-Scope Reports, What’s Next?
•
Obtain a copy of each of the current reports that are “inscope” (not all report across your organization)



Legacy reports are often a great way to document the data needs
 They can be used to illustrate how data is currently being
summarized and viewed
Consolidate the requirements, and look for "low-hanging fruit"
Create a physical folder with paper copies of these legacy reports
 Make sure that the development team has access to them -- this
will reduce the time spent in meetings with the business
community
+
+
=
Many requirements
can be met by a
single SAP BI report
37
Where do I start?
All functional areas are not equally supported by strong standard SAP BI business
content. Some areas have much you can leverage, others will require significant
enhancement to meet your requirements The differences are often due to
customization on the R/3-side by companies and/or industry solutions.
Focus on an area that
solves a problem
instead of becoming
a "replacement"
project.
Approximate Usage of Standard Content BW 3.5
(percentage of overall development effort)
100
80
Gradually, using a
prioritized phased
approach, solve other
business problems.
60
40
20
to
ry
In
ve
n
M
*
SC
E
m
gm
t
lit
y
Qu
a
rib
ut
io
n
es
Di
st
Sa
l
*
CR
M
AP
O
g
ur
in
CO
an
uf
ac
t
M
FI
0
* Rapidly improving content
A good way to think
of a BI rollout is in
terms of business
problems.
38
The Blueprinting Phase: Leveraging Standard Content
•
•
•
As a guiding principle,
map requirements to
standard content
before customizing
Mostly standard storage objects
Some customization
Highly customized storage objects
31%
36%
However, you’ll
probably also have
external data sources
that require custom
ODSs and InfoCubes
Customizing lower level
objects will cause
higher level standard
objects to not work,
unless you are willing
to customize these
also….
33%
An example from a large
manufacturing company
BW Content available (3.5.1):
•
•
•
•
•
Cockpits
Workbooks
Queries
Roles
MultiCubes
???
1,979
3,299
861
121
• InfoCube
605
• ODS objects
349
• InfoObjects 11,772
39
The Blueprinting Phase: Model Your Solution
1. Create a model based on pre-delivered SAP BI 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
Material
Logistics
Material number
Material entered
Material group
Item category
Product hierarchy
EAN/UPC
Storage
Requirements
Plant
Shipping/receiving point
Billing
Customer
+
Currency Key
Unit of Measure
Base unit of measure
Sales unit of measure
Volume unit of measure
Weight unit of measure
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
Standard content
Company code
Division
Distribution channel
Sales organization
Sales group
Map functional requirements
to the standard content before
you make enhancements
Personnel
Sales rep number
Accounting
Cost center
Profit center
Controlling area
Account assignment group
Billing information
Billing document
Billing item
Billing type
Billing category
Billing date
Creation date
Cancel indicator
Output medium
~ Batch billing indicator
Debit/credit reason code
Biling category
Reference document
Payment terms
Cancelled billing document
Divison for the order header
Pricing procedure
Document details
Sales order document type
Sales deal
Sales docuement
Time
Calendar
Calendar
Calendar
Calendar
year
month
week
day
Storage
Objects
LEGEND
Delivered in standard extractors
Delivered in LO extractor
Not in delivered Content -but in R-3
40
What We’ll Cover…
•
•
•
Final Preparatory steps
The Blueprinting Phase
The Realization Phase




•
•
Building ODSs and InfoCubes
Planning, Managing and executing system test
Planning, Managing and executing integration and performance test
Issue resolution, logs, sign-off and approvals
The Implementation Phase
Wrap-up
41
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
Development Programs: Provide
details of added programming
structures
3.10 Develop User interface enhancements
End User Training Material
3.11 Determine additional reporting requirements
Configuration and Testing Plans:
Define how the configuration will be
implemented and how it will be
tested
3.12 Create structured reports
3.13 Establish Authorization Concept
3.14 Establish Data Archiving plan (if applicable)
Source: Pauline Woods-Wilson
3.15 Final Integration Test
3.16 Quality Check Realization
42
Building ODSs and InfoCubes
TIPS
1 Review the functional requirements and 6 Do not allow exceptions to your naming
conventions
technical design
2 Make sure you have established Data
7 Make sure 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.
3 Have your ETL developers work
8 Try new ideas in a sandbox environment ,
for the individual who is responsible
and don’t contaminate the development
environment.
for creating process chains (organizationally)
4 Avoid nested ODS layers, and keep the 9 Keep 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.
5 Make your transformations part of
10 Developers must unit test all of their
update rules into infocubes if you need
work and personally sign-off on their
to be able to reconcile to the source
storage object.
system. Keep the details in the ODS.
43
Consider Upgrading to SAP BI in SAP NetWeaver 2004s
On a typical SAP BI 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
transformations,
potentially
saving you a lot
of time!
Source SAP AG
44
The SAP BI Test Methodology
Methodology used for System and Integration tests…
Test Strategy
Test Plan
Test Execution
Problem Resolution
SAP R/3 and BI testing is not different from a
methodology standpoint, but the global execution is….
45
SAP BI 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
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
Business analysts are responsible for planning,
coordinating, and executing the system testing of queries.
11
1
2
3
9
4
8
7
Plan for more than one test location and early
announcements (i.e. France, US and Japan).
12
10
6
5
Timing
46
Deliver
Cost and Profitability
Order
Manufacturing
Plan and scheduling
Demand planning
Source
Environment
preparation
Resolving
outstanding
issues and retesting
= Morning session 8:30 - noon
= Evening session 12:30 - 5:00
• Each
team should have dedicated time in the test
room in each country. If needed, rent your own
training/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
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
SAP BI Test Scheduling: Example
47
SAP BI Test: Checklist
•
Preparations




•
People




•
Data source/cubes/ODS/queries prioritized for testing
Queries developed and available in the SAP BI test environment
Track specific test plans created using test template
Test cases written
Individuals (testers) perform the identified tests
Testers invited to complete SAP BI on-line training
Availability of testers confirmed
Security roles tested and user ID’s for testers have been created
Logistics



Testers familiarized with test results recording tools
Identify test location and verify resources
 Rooms, computers, sapgui, network connections, phone, etc.
Plan for problem resolution
48
Performance Testing
•
Performance test execution







Identify queries to be performance tuned, and determine cutoff load for
load test – e.g. 40% of actual users (not named)
Schedule queries to run in background, and execute each query while
load scripts are running to simulate “real” users
Monitor your system continuously, and attempt tuning at the query level
Perform analysis based on benchmarks, and build aggregates and/or
indexes
Record findings in a formal tracking tool available to everyone
Meet with developers daily to discuss issues
Problem resolution:
Look at the new BI Accelerator in SAP
BI 7.0 for improved performance !!!
49
Source: Alexander
Peter, SAP AG
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 in each
country and the overall steering committee
50
What We’ll Cover…
•
•
•
•
Final Preparatory steps
The Blueprinting Phase
The Realization Phase
The Implementation Phase




•
Executing cut-over to production
Conducting end-user and power user training
Establishing end-user support organization
Post-implementation review and next steps
Wrap-up
51
Final Preparation Phase: Some Key Observations
The Cutover Plan and the Technical
Operations Manual describe the details
on how to move to the production
environment and go live
Stress & Volume Tests confirm the
production hardware’s capabilities
The End User Training document
describes the delivery of the necessary
levels of SAP training prior to going 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
52
Conducting End-User and Power User Training
Web-based

All users

Training

Tutorials
Instructor-led

On-site

Power users

Executives
Vendor-based

Developers

Support staff
1) Create, or buy, an on-line help and training system.
Make sure you use many images and links.
2) Consider using animations to demonstrate
complicated tasks as well.
3) Consider multi language versions of the help and
53
training system
Establishing Local and Global End-User Support Organization
Getting Power Users involved early is important to
the overall success of a Data Warehousing project
p
u
o
r
g
y
onl
e
h
t
s?
t
e
r
o
w
p
e
e
r
r
A
ild
u
b
n
a
c
that
n?
i
o
j
s
r
e
oth
n
a
c
w
Ho
ved
l
o
v
n
i
be
d
l
u
o
?
h
Who s e businesses
an
from th
r
e
d
i
s
on
c
e
w
t?”
p
d
e
l
c
u
n
o
o
h
S
or c
d
a
s
s
a
“Amb
To help support countries and regional businesses that
have already gone live, a strong local community of
“ambassadors” is needed.
Without them, ongoing projects can get “bogged down”
with basic report support and enhancement requests.
54
Go-Live: Some Key Observations
The last deliverable for the implementation
ensures high system performance through
monitoring and feedback
Source: Pauline Woods-Wilson
We need to execute issue resolution plans
and contingency plans
Core Activities
5.1 Production Support
5.2 Project End
A “lessons learned” session should be
held at the end of the project to assure
organizational awareness and education
The support organization will take over the
system after a pre-determined time period.
Some team members may transition into their
new roles as support staff
This is a critical time when a “SWAT” team
that quickly addresses user concerns can
make all the difference in how the system is
received among the users
55
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%
It is also a great way to document your success!!
56
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
Production
Performance
Areas of BI Data Load Issues
Nov. 1st through Dec. 15th
Demand
Planning
7
Transaction global
6
Source Purchase
Orders
Roughcut
4
Material
Movements
MD - Bev.
Packaging
3
Master data
2
Hierarchies
1
12/15/04
12/14/04
12/13/04
12/12/04
12/11/04
12/9/04
12/10/04
12/8/04
12/7/04
12/6/04
12/5/04
12/4/04
12/3/04
12/2/04
12/1/04
11/30/04
11/29/04
11/28/04
11/27/04
11/26/04
11/25/04
11/24/04
11/23/04
11/22/04
11/21/04
11/20/04
11/19/04
11/18/04
11/17/04
11/16/04
11/15/04
11/14/04
11/13/04
11/12/04
11/11/04
11/10/04
11/9/04
11/8/04
11/7/04
11/6/04
11/5/04
11/4/04
11/3/04
0
11/2/04
Greycon
11/1/04
Number of Issues
5
CO -line items
57
Go-live: Post-Implementation Review
Alignment
Are we doing
the right
things?
Are we doing
them the right way?
Benefits
Are we getting
the benefits?
Are we getting
them done well?
The Information Paradox: John Thorp
Integration
Capability/Efficiency
Conduct a formal 'post-mortem' after go-live before starting the next
phase of the project. Not everyone will tell you if they dislike the system,
but you need to give them a chance and learn from your mistakes
(continuous improvements).
58
What We’ll Cover…
•
•
•
•
•
Final Preparatory steps
The Blueprinting Phase
The Realization Phase
The Implementation Phase
Wrap-up
59
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:
Dr. Bjarne Berg Home page
c)
c)
(http://csc-studentweb.lr.edu/swp/Berg/BB_index_main.htm)
60
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 BI (some belong in R/3)
•
Track quality, and create a formal approval process
•
Involve power users and ambassadors in the development
project
61
Your Turn!!!
How to contact me:
bergb@lrc.edu
62