30 critical lessons for global SAP NetWeaver Business Intelligence project teams

30 critical lessons for global
SAP NetWeaver Business
Intelligence project teams
Dr. Bjarne Berg
© 2009 Wellesley Information Services. All rights reserved.
What We’ll Cover …
•
•
•
•
•
•
•
•
•
Introduction
Scoping the SAP NetWeaver BI project
Getting the project started - project plans & execution
Designing InfoCubes — the good, the bad, and the ugly
Improving performance — what to do, and how to do it
Understanding the curse of MultiProviders
Cleaning up and DSO management
Considering global integration points
Wrap-up
1
BI Has “Grown Up” and Is Now a Core Infrastructure Requirement
•
59% of companies now have an enterprise data warehouse

•
This number will grow to 86% in 2009
However, only 39% of companies have a BI competency
center and only 54% have an enterprise information strategy
BI competency center
BI governance program
No plans
Within 2009
Currently have
Enterprise Info. strategy
Information quality program
Enterprise Data Warehouse
0%
10%
20%
30%
40%
50%
60%
Source: Business Week Research,
Where will your company be in three years?
2
What We’ll Cover …
•
•
•
•
•
•
•
•
•
Introduction
Scoping the SAP NetWeaver BI project
Getting the project started - project plans & execution
Designing InfoCubes — the good, the bad, and the ugly
Improving performance — what to do, and how to do it
Understanding the curse of MultiProviders
Cleaning up and DSO management
Considering global integration points
Wrap-up
3
1. Global Master Data Integration and SAP NetWeaver BI
•
When an organization has multiple SAP R/3 systems, the SAP
NetWeaver BI master data integration can be cumbersome
1. Determine what local master data needs to be maintained in the BI
system and load it as separate master data
2. Determine what global master data needs to be maintained in the BI
system and load it to the shared areas
 To do this you will need master data mapping rules or tables
3. If you have conflicting master data, consider loading the local
masterdata to DSOs (make it reportable) and merge the global
master data to be used by the InfoCubes
 Alternatively, you can load versions of master data into custom
master data objects in SAP NetWeaver BI and use the merged
master data as the “0 objects”
If you have multiple regional transaction systems, plan on spending 5%-10%
of your global project time on master data integration, design, and testing.
4
2. Using MDM for Global Master Data Integration
•
You can also decide to use
the SAP NetWeaver Master
Data Management (MDM) tool
to manage and merge the
global master data in a
central location
Source: SAP NetWeaver Magazine, Alan Joch
If an MDM implementation is warranted,
make it a separate project and don’t
include this as part of the global BI
project. The BI system simply extracts the
new merged and integrated master data.
5
3. Privacy and Security Concerns across International Boundaries
•
•
European and many Asian countries
Some European Restrictions
have strict privacy rules
information cannot be
European Union Commission’s Directive 1. Personal
collected without consumers’
on Data Protection protects personal
permission. They have the right to
review the data and correct
information from Europe to countries
inaccuracies.
whose privacy practices are not
deemed “adequate”
2. Data processing companies must

•
All European Union (EU) member countries
are bound by the European Commission’s
finding of adequacy
Your company can become entangled in
many local laws, or seek participation in
the “safe harbor” agreements by the
Department of Commerce (costs up
to $500)

The safe harbor eliminates the need for prior
approval to begin data transfers, and makes
approval from the appropriate EU member
countries automatic
register their activities with the
government.
3. Employers cannot read, copy, or
transfer workers’ private email.
4. Personal information cannot be
shared by companies or across
borders without express
permission from the data subject.
Safe harbor agreements can
reduce exposure to such
legal issues.
6
4. Capacity and Scalability Is the Top Concern for Your CxO
•
Don’t under size your global BI system

Spend adequate funding on hardware, memory, processing power,
and disk space
A survey of 353 top C-level officers in large companies reported
that the top BI concern was the scalability of their solutions.
Overall System Performance and capacity
7.9
Server & Desktop processing capacity
7.88
Determining ROI
7.65
Security
7.62
Data Integration
7.51
Too many Business Intelligence tools in use
7.31
Danger of distributing outdated data
7.21
Difficult for end users to learn or use
Source: Intel, SAP, and Business Week
"Seizing the BI Opportunity" 2007.
7.03
7
7.25
7.5
7.75
8
7
4. Capacity and Scalability — Global Hardware Example
Example of a large BI system
Production
12 CPUs
96 GB RAM
Sandbox
4 CPUs
32 GB RAM
Development
4 CPUs
32 GB RAM
Test
4 CPUs
32 GB RAM
Key numbers:
 3.1 Terabytes of data
 2,810 named users
 About 620 active users
•
This company reallocated their Sun6900 box (on Oracle) and have three
app servers on the production box
•
More memory allows them to take
better advantage of the parallel load
of the BI system and to cache many
of the frequently run queries
(BEx Broadcaster)
•
The hardware also allows them to
compare performance between
the boxes
Global systems must consider network connections (speed),
data encryption, and distributions of application and Web
servers for load balancing (due to 24-hour operations).
8
5. Pick a Formal Methodology — You Have Many Choices
•
•
Accelerated SAP (ASAP) methodology is not your only choice
Even though harder to manage on a global project due to long
communication lines, consider RAD, JAD, or EP based on the
time to delivery and impact of failure
When to Select Different Methodologies
High
Joint Application Design
(JAD)
System development Lifecycle
based methodologies
(SDLC)
Time to
Delivery
Extreme Programming
(EP)
Rapid Application Development
(RAD)
Look at what your global
organizational partners
have done.
You may know more about
RAD than you think!
Low
Low
High
Impact of Failure
Source: Bjarne Berg, Data
Management Review 2004
9
6. Report Dispositioning — Don’t Throw Every Report into BI
•
Many tools exist that can report on SAP R/3 data

•
Make cost-effective decisions

•
Just because the report is not in SAP NetWeaver BI does not mean
it cannot be added to a Portal or viewed on the Web
Not all reports belong in SAP NetWeaver BI

•
You might have static reports that belong in SAP R/3, which would
not be cost effective to develop in SAP NetWeaver BI
Avoid using 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
You need a formal report dispositioning process and need to
evaluate every requirement as BI vs. transaction reporting.
10
7. SAP Solutions Manager — EarlyWatch Reports Are Great!
•
EarlyWatch reports provide a
simple way to confirm how
your system is running and
to catch problems

•
•
A “goldmine” for system
recommendations
Run them periodically and
read the details
A real EarlyWatch report
from a mid-sized company
that has been running SAP
BW for the last three to four
years
On a large global project, system
issues can be hard to pin-down without
access to EarlyWatch reports. The
monitoring reports allow you to tune
the system before the user community
gets access and complaints arise.
11
7. SAP Solutions Manager — EarlyWatch Performance Info
1 Performance Indicators
The following table shows the relevant performance indicators in various system areas.
Area
System Performance
Hardware Capacity
Database Space Management
Query Performance
Indicators
Active Users
Max. CPU Utilization on DB Server
Max. CPU Utilization on Appl. Server
DB Size
Last Month DB Growth
Avg. Total Runtime of the BW Queries
Avg. Database Runtime of the BW Queries
Value
18
74 %
74 %
355.52 GB
118.63- GB
11.5 s
8.0 s
Trend
down
steady
steady
steady
steady
down
steady
Due to time-zones, a 24hour operational system,
will have less time to
react and fix issues.
1 Performance Overview
The performance of your system was analyzed with respect to the average response times and total
workload. We did not detect any major problems that could affect the performance of your system.
The following table shows the average response times for various task types:
Task type
DIALOG +
RFC
UPDATE
UPDATE2
BATCH
HTTP
Dialog
Steps
195240
Avg. Resp.
Time in ms
3253.3
Avg. CPU
Time in ms
728.7
Avg. Wait
Time in ms
1.8
Avg. Load
Time in ms
2.5
Avg. DB
Time in ms
1110.9
5
48
59288
257762
984.2
133.2
11599.3
693.5
28.2
17.1
2091.2
183.7
26.0
0.7
0.6
4.4
15.2
3.3
8.5
2.2
585.4
80.8
5772.6
405.0
Therefore, early
Avg. GUI
of system
Timedetection
in ms
6.3
issues
are critical to the
success of a global
project.
1.1 Current Workload
The following table lists the number of current users (measured from our workload analysis) in your system.
Users
Measured in System
Low Activity
98
Medium Activity
11
High Activity
7
Total Users
116
12
8. Organizing the Global Team — Six Ways to Balance the Global
BI Development Effort
Option
1
Single site
2
Distributed analysis
3
Distributed analysis and design
4
Co-located analysis and design
5
Multiple co-located analysis and design
6
Fully distributed development
Benefits
Risks
The more distributed the BI
development effort becomes,
the more difficult it is to
maintain communication and
get cohesive requirements.
13
9. Organizing the Global Team — Small Technical Team Roles
•
These are roles, not positions

Many companies fail to
formally assign roles
and responsibilities.
Sometimes one team member can
fill more than one role
As a result, they have
many “jacks of all
trades” and “masters
of none.”
Project Sponsor
Project Manager
Business Team
Business Analyst
Presentation Developer
Technical Team
BI Architect
ETL Developer
BI Basis and functional SAP R/3 support
The team consists of four to five team members and projects
lasts normally 3-6 months depending on scope
ETL = Extract, transform, and load
14
10. Organizing the Global Team — Large Functional Teams
Project Sponsor/
Steering Committee
Project Manager
In a global BI organization, you
simply need to create functional
teams (instead of the previous
technical team models).
BI Architect
Portal Developer(s)
Sales Team
Finance Team
Business Analyst/(sub-team lead)
BI Developer
Presentation Developer(s)
ETL Developer
Business Analyst/(sub-team lead)
BI Developer
Presentation Developer(s)
ETL Developer
Material Mgmt. Team
Business Analyst/(sub-team lead)
BI Developer
Presentation Developer(s)
ETL Developer
BI Basis and functional SAP R/3 support
15-30 team members and normally
6-18 months duration between each go-live
15
11. Organizing the Global Team — Localized BI Training
Reference
Title
Audience
Language
Class size
Note
All
Local
25
Bring in house
Query developers
Local
15
Bring in house
BW-310
Intro to SAP BI
BW-305
BI Reporting and Analysis
BW-350
BI Data Acquisition
ETL developers
English
10-12
SAP facility
BW-365
BW Authorizations
System admin
English
1-3
SAP facility
SAP-330
BW Modeling
BI developers
English
10-20
SAP facility
•
•
Training for end users and the local query developers should
be completed in their own language to assure understanding
and encourage participation
Developer training should be in the project language (e.g.,
English, German, French)
Don’t underestimate the value and
cost savings of in-house training.
16
12. You Have to Plan for Global Cockpits
•
58% of all companies reported that
they were already using BI dashboards
and 25% more planned to do by end of 2009

•
Source: Business Week Research
Dashboards are no longer cutting-edge

Expected by senior management
Purpose
Usage
Updates
Data
Measures
Context
Source
Dashboard
Scorecard
Cockpits
Displays performance
Displays progress
Displays status and events
Performance monitoring
Performance management
Performance management
Real-time feeds
Monthly snapshots
Daily snapshots
Events
Summaries
Summaries and events
Metrics
KPIs
Metrics and KPIs
Exceptions/alerts
Targets and thresholds
Trends
Linked to systems
Linked to plans
Linked to BI systems
Sources: Wayne Eckerson, Bjarne Berg,
Dashboards and cockpits should be in your
long-term global BI strategy (three to five years).
17
13. Pick a Project Language and Stick with It!
•
If you don’t enforce a global project language, BI project
documentation becomes fragmented

The project team will quickly disintegrate into groups based on the
language with which they are most comfortable
•
Enforce a project language and require that all emails are
written in it and all notes are taken in the same language
•
Don’t allow “side bars” in languages that others don’t
understand
Make sure the project
language is clear, and that
pertinent documents are
translated in a timely fashion.
18
What We’ll Cover …
•
•
•
•
•
•
•
•
•
Introduction
Scoping the SAP NetWeaver BI project
Getting the project started - project plans & execution
Designing InfoCubes — the good, the bad, and the ugly
Improving performance — what to do, and how to do it
Understanding the curse of MultiProviders
Cleaning up and DSO management
Considering global integration points
Wrap-up
19
Resource Leveling — 1. Base It on the Scope (Real Example)
Customi
zation
L
M
L
M
L
M
L
L
L
L
L
L
L
L
L
M
M
M
M
Tech. Dev.
infocube
Financials
General ledger line item (ODS)
COPA
Prod cost planning released cost
estimates (COPC_C09)
Exploded itemization standard
product cost (COPC_C10)
Cost and allocations
(COOM_C02)
Cost object controlling
(0PC_C01)
Order
Extraction and Report
transforms
and roles
Security and
scheduling
Web
development
User
support/
planning
Project mgmt System docs Tech infraand admin
& manuals
structure
Bus. Analysis,
training, req.
gathering, change
mgmt.
Total
Hours
216
158
216
229
286
229
188
153
188
101
127
101
132
153
133
134
152
135
100
120
100
79
94
79
150
180
150
403
470
403
1,732
1,893
1,734
238
286
216
126
153
152
120
94
180
470
2,035
216
1144
188
101
132
135
100
79
150
403
2,648
238
286
216
137
153
152
120
94
180
470
2,046
216
216
216
229
229
229
187
187
187
101
101
101
132
132
132
135
135
135
100
100
100
79
79
79
150
150
150
403
403
403
1,732
1,732
1,732
216
229
187
101
132
135
100
79
150
403
1,732
216
216
228
228
187
187
101
101
132
132
135
135
100
100
79
79
150
150
403
403
1,731
1,731
Delivery data of shipment stages
(0LES_C13)
Delivery service (0SD_C05)
Planning and Scheduling
Material Movements (0IC_C03)
216
228
187
101
132
135
100
79
150
403
1,731
180
229
133
101
132
134
100
79
150
403
1,641
216
457
132
101
132
134
100
79
150
403
1,904
APO Planning
SNP Integration
Manufacturing Processes
Production Orders
Cross Applications
Total Hours
277
277
832
832
216
216
127
127
153
153
152
152
120
120
94
94
180
180
470
470
2,621
2,621
277
277
4,298
832
832
8,074
216
216
3,587
127
127
2,110
153
153
2,656
152
152
2,681
120
120
2,040
94
94
1,606
180
180
3,060
470
470
8,126
2,621
2,621
38,238
Billing
Sales order
Acct. Rec. (0FIAR_C03)
Deliver
Shipment cost details
(0LES_C02)
Shipment header (0LES_C11)
Stages of shipment (0LES_C12)
Remember that your sizing also has to be
based on the team’s experience and skill level.
20
Resource Leveling — 2. Prioritizing & ‘rules of thumb’ (real example)
2006
2005
qtr 1
Financials
866
General ledger line item (ODS)
946.5
COPA
Prod cost planning released cost
estimates (COPC_C09)
Exploded itemization standard product
cost (COPC_C10)
Cost and allocations (COOM_C02)
Cost object controlling (0PC_C01)
Order
Billing
Sales order
Accounts receivables (0FIAR_C03)
Deliver
Shipment cost details (0LES_C02)
Shipment header (0LES_C11)
Stages of shipment (0LES_C12)
Delivery data of shipment stages
(0LES_C13)
Delivery service (0SD_C05)
Planning and Scheduling
Material Movements (0IC_C03)
APO Planning
SNP Integration
Manufacturing Processes
Production Orders
Cross Applications
Total 1,813
qtr 2
qtr 3
qtr 4
qtr 1
qtr 2
qtr 3
qtr 4
qtr 1
2007
qtr 2
qtr 3
866
947
867
867
1,732
1,893
1,734
1017.5
1017.5
2,035
1324
1023
1324
1023
2,648
2,046
866
866
866
866
866
866
1,732
1,732
1,732
866
865.5
865.5
865.5
866
865.5
865.5
865.5
1,732
1,731
1,731
1,731
820.5
820.5
1,641
952
1310.5
1310.5
1,813
4,232
4,232
2,598
2,598
4,283
4,283
3,573
952
1311
1311
1,904
2,621
2,621
1311
1311
1,311
1,311
2,621
2,621
6,195
2,622
38,238
Plan to spend 15% of the project time on project prep, 25% on blueprinting, 45% on
realization and 15% on go-live.
There is a risk of spending too much time on design and short changing development
time, which often causes project delays. Accept that you will not have answers to all
questions until you see the data and queries.
21
1
2
3
4
5
6
7
8
9
2-Jun
1-Jun
31-May
30-May
TASK
29-May
ID
28-May
Project Preparation Phase — Dependencies
SAP Best Practices BI Implementation Roadmap - read Notes
Pre-Sales Phase / Project Preparation
Perform Customer Workshop & present Best Practices in Demo System
Review and select scenarios that are best fit for customer requirements
Carry out review of delivered business content to check for gaps
Define Critical Success Factors
Validate & Document Technical Requirements
Define System Landscape Strategy (maybe 2 system landscape and/or SAP One
Server)
Perform Hardware sizing
•
Key to project prep phase is the level setting of all parties


One-day workshop with stakeholders, managers, and sponsors
Dedicate some time early in the workshop to demo SAP
NetWeaver BI and discuss capabilities of the tool set
A one-day workshop can remove project confusion
and delays, help in getting the right requirements,
and avoid missing “low hanging fruit.”
22
2-Jun
1-Jun
31-May
30-May
TASK
29-May
ID
28-May
Blueprinting Phase — Planning Dependencies
1 SAP Best Practices BI Implementation Roadmap - read Notes
11
Blueprint Phase & Planning Phase
12
Apply for Going Live Check
13
Finalize Project Scope [selected scenarios]
14
Check Content delivered by Best Practices
15
Determine those issues affecting BW Implementation and assign risk to project
16
Present Final Scope to Customer and Get Signoff of Scope
17
Project Planning Phase
18
Set Up Development Environment
19
Define transport Strategy
20
Activate TMS
21
Define Project Organization and Create Teams
22
Analyze Roles and Tasks by Standard Content Areas and Technical
23
Update delivered Project Plan & finalize, including resources assignments
24
Define customer rollout & training strategy for SAP BW
25
Define types of users of the BW
26
Determine Number of users for BW
27
Determine Data Access Requirements
•
Many tasks can take place at the same time

The trick is to ensure all team members
are active and the workload is
evenly balanced throughout project
Spend some time on resource loading and
workload balancing. Not all tasks are dependent.
Note: Example dates are
based on a 6-8 weeks RAD
implementation
23
Test Strategy
Test Plan
Test Execution
Problem Resolution
10-Jun
9-Jun
Blueprint Phase & Planning Phase
Project Planning Phase
Project Procedures
Update Project Management Standards and Operating Procedures
Update Implementation Standards and Procedures to include BW specific
Update SAP System Admin Procedures
Test plans
Define BW Test Plans
Define Data Flow & Validation Test Plans
Define Data Access Test Plans
Define Authorizations Test Plan
Develop System Test Plans
Develop Technical Test Plans
Develop Functional/Performance Test Plans
8-Jun
11
17
37
38
39
40
41
42
43
44
45
46
47
48
7-Jun
TASK
6-Jun
ID
5-Jun
Blueprinting Phase — Project Management, Test Plans,
Dependencies
SAP R/3 and BI testing is
not different from a
methodology standpoint,
but the execution is.
24
51
52
53
54
55
56
57
58
59
60
61
Project Realization
BW Development Configuration
Implement relevant Best Practices scenarios
Configure Data Access Environment
Source Data Quality Validation
Collect Representitive Sample of Source Data (Transaction and Master)
Identify and List all issues with transaction/master data
Implement Standard Authorization Concept - Development Environment
Document those issues affecting BW Implementation and assign risk to project
Communicate issues to customer and agree on criteria to clean data
Provide customer report on findings and agree on go forward strategy to clean
•
9-Jun
8-Jun
Duration
7-Jun
TASK
6-Jun
ID
5-Jun
Realization Phase — Development Core Dependencies
6.25d
3.d
3.d
.25d
.75d
.5d
.5d
1.d
.25d
.5d
.25d
Most issues during this phase will be data ETL

While you cannot plan for all issues, you can set aside time to deal with them
Data cleansing should occur in the source system.
(Hint: Cover this in the scope statement.)
25
Realization Phase — Testing Core Activities
ID
51
62
63
64
65
66
67
68
Duration
TASK
Project Realization
Quality Assurance Environment
Set Up Quality Assurance Environment
Transport Requests from Dev
Load data from R/3 QA Environment
Test QA Environment
BW Quality Assurance Configuration
Execute BW Test Plans in Quality Environment
Tasks\Dates
December 2003
January 2004
Start
6/5/05 8:00 AM
6.25d
3.25d 6/10/05 8:00 AM
.5d 6/10/05 8:00 AM
.25d 6/10/05 1:00 PM
1.d 6/10/05 3:00 PM
2.5d 6/10/05 3:00 PM
.5d 6/10/05 3:00 PM
2.d 6/11/05 10:00 AM
Finish
6/13/05 10:00 AM
6/13/05 10:00 AM
6/10/05 12:00 PM
6/10/05 3:00 PM
6/11/05 3:00 PM
6/13/05 10:00 AM
6/11/05 10:00 AM
6/13/05 10:00 AM
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
Business analysts are responsible for planning
and executing the system testing of queries.
26
69
70
71
72
73
74
75
76
77
78
79
80
•
19-Jun
18-Jun
17-Jun
16-Jun
15-Jun
14-Jun
13-Jun
12-Jun
TASK
11-Jun
ID
10-Jun
Final Preparation Phase — System Testing Dependencies
Final Preparation Phase
Setup Production Environment
Define Production System Design
Set Up Production Environment
Confirm BW Production Configuration
Execute BW Test Plans in Production Environment
Conduct System Tests
Conduct System Administration Tests
Conduct Backup and Restore Procedure Test
Conduct Failure Scenarios Test
Conduct Disaster Recovery Test
Conduct Going Live Check
Typical backup strategy


Run a full system backup on the weekends and only delta backups each day
before the load process starts
Make sure that you can actually restore from the backups and that the system has
the resources it needs (i.e., Will one application server be enough?)
Don’t underestimate the need for system testing
for performance and recovery purposes.
27
69
81
82
83
84
85
86
87
88
89
90
19-Jun
18-Jun
17-Jun
16-Jun
15-Jun
14-Jun
13-Jun
12-Jun
TASK
11-Jun
ID
10-Jun
Final Preparation Phase — User Training & Support Dependencies
Final Preparation Phase
Training Plans
Develop End User Training and Documentation Content
Prepare for End User Training and Documentation Delivery
Deliver End User Training
Train System Administration Staff
Define Long-Term Production Support Strategy
Refine Production Support Plan
Reorganize Team for Production Support
Establish Help Desk
Realization Review
•
This is the time to execute the production support plans and
re-organize the project team into a sustainable organization,
or plan the hand-off to a support organization if one exists
•
Remember to plan for the integration of your support plans
with your organization’s existing support systems
and help desk routing
28
24-Jun
23-Jun
22-Jun
21-Jun
20-Jun
19-Jun
TASK
18-Jun
ID
17-Jun
Final Preparation Phase — Dependencies
69 Final Preparation Phase
91
Final Preparation Tasks
92
Transport to Production Environment
93
Perform Conversions
94
Cutover
95
Perform Cutover to Production System
96
Confirm Production Readiness
97
Verify Users are Ready
98
Final Preparation Review
99
Conduct Quality Check
100
Conduct Final Preparation Review
101
Sign off Final Preparation Phase
102
Final Approval for Going Live
•
You can often cut over to the production box before the go-live

If you already have BI users live in-the-box, you can mask the new functionality
by not mapping the new queries to the user’s role menu until you are ready
If you are already live with other content, plan for a weekend
cut-over and spend Saturday to validate the production box.
This gives you Sunday to fix any major issues.
29
1-Jul
30-Jun
29-Jun
28-Jun
27-Jun
26-Jun
TASK
25-Jun
ID
24-Jun
Go-Live — Post Go-Live Activities
103 Go Live and Support Phase
104 Setup Production Support
105 Go Live & Support Review
106 Provide Production Support
107 Post Go Live Activities
108
Review and Close Open Issues
109
Close Open Issues and Sign off Go-Live and Support Phase
110
Review Business scenarios
111
Validate Live Business Process Results
112
Strategic BW Planning
113
Develop Strategic Plan for BW
114
Identify additional requirements concerning Web Reporting and Bex Analyzer
115
Project End
The last deliverable for the implementation
ensures high system performance through
monitoring & feedback.
We need to execute issue resolution plans
and contingency plans.
A “lessons learned” session should be held
at the end of the project to assure
organizational awareness and education.
The support organization will take
over the system after a predetermined 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.
Source: Pauline Woods-Wilson
30
14. In the Blueprinting Phase — Model Your Global Solution
1. Create a model based on pre-delivered SAP NetWeaver 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 billing 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
Map functional requirements to
the standard content before
you make enhancements
Company code
Division
Distribution channel
Sales organization
Sales group
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
Billing category
Reference document
Payment terms
Cancelled billing document
Divison for the order header
Pricing procedure
Document details
Sales order document type
Sales deal
Sales document
Time
Calendar year
Calendar month
Calendar week
Calendar day
Storage
Objects
LEGEND
Delivered in standard extractors
Delivered in LO extractor
Not in delivered Content - but in R-3
31
15. Accept Cultural Differences — No Culture Is Dominant!
•
Cultural differences should not be tolerated, but embraced
•
Europe has longer vacations (four to six weeks are common,
not exceptions)
•
Family time is important — don’t plan 12-hour workdays for
four months
•
Not everyone is equally interested in hearing how we do
things in the US
•
Many cultures find it offensive to talk about salaries,
and money

•
Talk about value and deliverables instead
Consider a co-project manager
32
16. Meet Local and Global Requirements
•
In most global organizations there are varying product
hierarchies, financial reporting requirements, mapping of
accounts, data integration, and tool requirements
•
Try not to solve only the enterprise reporting needs of the
corporation, but also the local reporting and analytical needs

•
This way you will get local support and ensure the system will
actually be used
A successful global BI project has more than one constituent
If you ignore local requirements, they will simply reinvent
your effort and find work-arounds and other tools.
33
17. Determine Where to Start
All functional areas are not equally supported by strong
standard 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 in SAP R/3 by
companies and/or industry solutions
Focus on an area that
solves a problem instead
of becoming a
“replacement” project.
ApproximateUsage
Usage
Standard
Content
BW
3.5
Approximate
of of
Standard
Content
SAP BI
7.0.3
(percentage of overall development effort)
100
80
Gradually, using a
priority-phased
approach, solve other
business problems.
60
40
20
to
ry
In
ve
n
M
*
SC
E
t
gm
m
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.
34
What We’ll Cover …
•
•
•
•
•
•
•
•
•
Introduction
Scoping the SAP NetWeaver BI project
Getting the project started - project plans & execution
Designing InfoCubes — the good, the bad, and the ugly
Improving performance — what to do, and how to do it
Understanding the curse of MultiProviders
Cleaning up and DSO management
Considering global integration points
Wrap-up
35
18. InfoCube Design — Evaluating Designs (Example)
Name
Billing documents condition values
Customer
Delivery service
Invoice summary
Order summary
Sales order condition value
Sales overview
Profitability analysis
Inventory mgmt plant summary
Material stock/movements
Plant & periodic plant stocks
Ad-hoc query order line details
Conditions order & billing document
Order and Invoice summary
SD Pricing order & billing docs
Campaign management
Commissions
Daily management
Disposition summary
Inquiry summary
Matrix
Monthly management report
Program summary
Type
Tech_nm
Infocube
Infocube
Infocube
Infocube
Infocube
Infocube
Infocube
Infocube
Infocube
Infocube
Infocube
MC
MC
MC
MC
Infocube
Infocube
Infocube
Infocube
Infocube
Infocube
Infocube
Infocube
ZSD_C15
0SD_C01
0SD_C04
ZSD_C06
ZSD_C03
0SD_C15
0SD_C03
Z_COPA_X
MRP_MATL
0IC_C03
0IC_C01
ZSD_M01
OSD_MC01
ZSD_C04
ZSD_M02
ZDM_C006
ZDM_C003
ZSD_C01
ZDM_C001
ZDC_C005
ZDM_C002
ZDM_C005
ZDM_C004
Cubes with many red
or yellow codes
should be examined
Dims* Characteristics Largest dim #
(all)
total
of Char
10
47
11
8
14
5
9
23
5
16
55
11
16
62
13
10
41
10
11
34
7
15
56
14
6
9
3
9
18
4
8
15
5
7
14
3
4
66
56
16
72
20
12
53
12
15
56
19
14
34
14
9
31
8
9
16
4
15
22
4
10
16
3
7
9
3
16
23
4
KF
3
16
15
19
23
2
17
85
22
24
21
6
2
24
3
29
8
10
1
1
141
6
12
# info.
Nav
Sources attributes
1
107
1
5
2
10
4
116
5
96
1
0
7
16
1
70
1
16
5
15
0
0
88
94
9
109
4
0
6
6
1
0
1
29
1
0
1
0
8
1
The observation relates a company’s current BI system to
normally observed configuration parameters, which serve as
benchmarks to what is commonly seen at other implementations
KF = Key figures
36
19. Partitioned InfoCubes That Are No Longer the Same
•
Often when InfoCubes are physically partitioned, changes occur as
new development and fixes are applied


After a while, there is a risk that some of the physically partitioned
InfoCubes are no longer identical
This can cause many issues (i.e., if archiving is used, you must ensure
copies of these older datastores are maintained to be able to restore data)
InfoCubes
Nam e
Technical
nam e
All
Largest Characteri
Key
Nav.
dim ensions dim ension
stics
Figures Attrib.
Sales Order: ACD 2007
ZCORD_A07
15
5
40
9
59
Sales Order: LPD 2006
ZCORD_L06
14
4
40
9
59
Sales Order: LPD 2007
ZCORD_L07
15
5
40
9
59
Sales Order History: ACD 2006
ZCODI_A06
15
13
58
39
66
Sales Order History: ACD 2007
ZCODI_A07
15
13
60
9
66
Sales Order History: LPD 2006
ZCODI_L06
15
13
58
39
66
Sales Order History: LPD 2007
ZCODI_L07
15
13
60
9
66
NOTES
Added 'Created by' as a Dimension(instead of field in
Date dim)
Added 'Created by' as a Dimension(instead of field in
Date dim)
1) Removed 30 Key Figures, 2) Added field "Date for
inv/bill index and print out" to Date dimension 3) added
field "Customer purchase order type" to business reason
dimension
1) Removed 30 Key Figures, 2) Added field "Date for
inv/bill index and print out" to Date dimension 3) added
field "Customer purchase order type" to business reason
dimension
37
20. Naming Conventions Should Be Followed
InfoCubes should
be named:
0ABC_C01 or
ZABC_C02
ODSs should be
named:
0ABC_O01 or
ZABC_O02
MultiProviders
should be named:
0ABC_M01 or
ZABC_M02
ODS = Operational Data Store
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
Supply Chain Mgmt - Inventory Mgmt.
Supply Chain Mgmt - Inventory Mgmt.
Industry Sectors - Oil & Gas - Exchanges
Industry Sectors - Retail
Non SAP Area - Marine Services
Non SAP Area - Marine Services
Non SAP Area - Marine Services
Non SAP Area - Marine Services
Non SAP Area - SFIO
Non SAP Area - SFIO
Non SAP Area - SFIO
Non SAP Area - SFIO
Non SAP Area - EPM (Ent. project mgmt)
Non SAP Area - EPM (Ent. project mgmt)
PIW - Profit Improvement Warehouse
Monthly Operation Planning 3
Monthly Operation Planning 3
Fin. Mgmt & Controlling - Profit Center Acct.
Fin. Mgmt & Controlling - Profit Center Acct.
Fin. Mgmt & Controlling - Profit Center Acct.
Fin. Mgmt & Controlling - Profit Center Acct.
Fin. Mgmt & Controlling - Profit Center Acct.
Fin. Mgmt & Controlling - Profit Center Acct.
Fin. Mgmt & Controlling - Profit Center Acct.
Fin. Mgmt & Controlling - Profit Center Acct.
Fin. Mgmt & Controlling - Profit Center Acct.
Fin.
& Controlling
- Profit Center
Acct.
Cust.Mgmt
Rel.MgmtCRM AnalyticsCross-Scenario
Analyses-Case
Mgmt
Analysis
Cust. Rel.Mgmt- CRM Analytics- Cross-Scenario
Analyses-Activity
ERP Analytics- Sales & Distribution Analyses SAP R/3
SD Sales & Distribution Analyses ERP
AnalyticsSAP R/3
SD Sales & Distribution Analyses ERP
AnalyticsSAP R/3
SD Sales & Distribution Analyses ERP
AnalyticsSAP
R/3
SD Sales & Distribution Analyses ERP AnalyticsSAP
R/3
SD Sales & Distribution Analyses ERP AnalyticsSAP R/3
SD Sales & Distribution Analyses ERP
AnalyticsSAP R/3
SD Sales & Distribution Analyses ERP
AnalyticsSAP R/3
SD Sales & Distribution Analyses ERP
AnalyticsSAP R/3
SD Sales & Distribution Analyses ERP
AnalyticsSAP
R/3
SD Sales & Distribution Analyses ERP AnalyticsSAP
R/3
SD Sales & Distribution Analyses ERP AnalyticsCommercial
Excellence
Strategic
Enterprise
Mgmt - BPS - Capital
Investment Planning
Cube for Risk Management
Material stocks/movements (as of 3.0B)
Exchange balance
Retail Competitor Pricing
PEDCO DTHEAD_DTTAIL
PEDCO LOGSUM
PEDCO MTHEAD_MTTAIL
PEDCO RCHEAD_RCTAIL
SFIO Movement Position
SFIO Movement Position History
SFIO OIPR
SFIO OIPR History
EPM Cube II
Enterprise Project Mgmt (EPM)
PROFIT IMPROVEMENT WAREHOUSE
MOP3 Pricing Marker
Monthly Operation Planning 3
Margin Analysis
PCA: Summary 1
PCA: Summary 1 History
PCA: Transaction data
Profit Center Accounting - Customer
Profit Center Accounting - Other
Profit Center Accounting - Periodic Balance
Profit Center Accounting - Planning Items
Profit Center Accounting - Summary
Profit Center Accounting - Vendor
CRM Case Management Analysis
Activities
Billing Cube
Billing Cube - History
Billing Summary
Billing: Condition Data Cube
Billing: Tax Conditions Cube
Daily Lift Report
Delivery Cube
Delivery Cube - History
PAWS: Pricing Analysis
PAWS: Pricing Analysis (1)
PAWS: Pricing Analysis Archive
CE Pricing Log
Capital Investment Planning
ZRISK
0IC_C03
0OI_EXC01
ZRTL_C01
ZPDCO_C01
ZPDCO_C05
ZPDCO_C03
ZPDCO_C02
ZSDMVMPOS
ZSDMVMHIS
ZSD_OIPR
ZSD_OIPHS
ZEPM_C02
ZEPM_C01
ZPIW_P001
ZMOP_CMKR
ZMOP_P01
ZPCA_C04
ZPCA_C03
ZPCA_C03H
0PCA_C01
ZPCA_C09
ZPCA_C10
ZPCA_C05
ZPCA_C06
ZPCA_C07
ZPCA_C08
ZCRM_CASE
0CSAL_C01
ZSD_CVF0
ZSD_CVFH1
ZSD_C17
ZSD_C06
ZSD_C06C
ZSD_ZS561
ZSD_CVL0
ZSD_CVLH1
ZPAWS
ZPAWS1
ZPAWS2
38
ZCE_C01
ZBPS_P05
What We’ll Cover …
•
•
•
•
•
•
•
•
•
Introduction
Scoping the SAP NetWeaver BI project
Getting the project started - project plans & execution
Designing InfoCubes — the good, the bad, and the ugly
Improving performance — what to do, and how to do it
Understanding the curse of MultiProviders
Cleaning up and DSO management
Considering global integration points
Wrap-up
39
Global Performance Issues
•
•
Global projects have many performance challenges

Hardware must be optimized for 24/7 operations and Network
capabilities

BI system must also have optimal backup and disaster recovery
windows and rapid data load processing
Since most of the query rendering time is spent on the
database, it is important that global projects spend serious time
optimizing the database reads by leveraging tools, such as the
BI Accelerator and the classical SAP NetWeaver BI aggregates
The correct definition of global aggregates can dramatically
reduce the time spent on database reads by the BI queries,
thereby delivering faster queries to the users in different countries
40
21. Performance Enhancements Are Available — Use Them
•
Check indexes periodically
 Under
RSA1  Manage  Performance
Nam e
COPA(US) : P&L L'Oreal R110: 2006
Check database statistics to route
queries faster
 At
this company, 50% of the InfoCubes
had outdated database statistics that
should be updated
•
For large InfoCubes, or cubes with
many users, the percentage used to
build the database statistics can be
increased to 15%-20%
 May
yield improved
query routing
Indexes Aggregate Stats
DB
index
build Stats
YCPAPL_1
10%
COPA(US) : P&L L'Oreal R110: ACD 2007
ZCPAPLA07
10%
COPA(US) : P&L L'Oreal R110: LPD 2007
ZCPAPLL07
10%
YCZO_1
10%
ZCARHI_1
10%
FIAR (CS) : Cube - Hist. indicators Zoom
YCZOHI_1
10%
Agreement
Cancellation and rejection
Carry Over
Consolidated Open Orders
Consolidated Open Orders
Delivery
Historical Invoice LPD
Invoice
RGA Data
Sales Order History
Sales order
Service rate
Invoice: ACD 2004
Invoice: ACD 2005
Invoice: ACD 2006
Invoice: LPD 2004
Invoice: LPD 2005
Invoice: LPD 2006
Sales Order: ACD 2006
Sales Order: ACD 2007
Sales Order: LPD 2006
Sales Order: LPD 2007
Sales Order History: ACD 2006
Sales Order History: ACD 2007
Sales Order History: LPD 2006
Sales Order History: LPD 2007
Invoice: ACD 2007
Invoice: LPD 2007
Delivery: ACD 2007
Delivery: LPD 2007
Service Rate: ACD 2007
Service Rate: LPD 2007
YC13_AGR
10%
YC11_CR
10%
ZCSD_CROV
10%
ZC_OO
10%
FI-AR Accounts Receiv. Line Item IC
•
Technical
nam e
FI-AR Historical Indicators US
YC_OO
10%
YC12_DEL
10%
ZCHSTLI
10%
YC13_INV
10%
ZC_RGADTL
10%
ZCORDINV
10%
YC11_ORD
10%
YC11_SR
10%
ZCINVA04
10%
ZCINVA05
10%
ZCINVA06
10%
ZCINVL04
10%
ZCINVL05
10%
ZCINVL06
10%
ZCORD_A06
10%
ZCORD_A07
10%
ZCORD_L06
10%
ZCORD_L07
10%
ZCODI_A06
10%
ZCODI_A07
10%
ZCODI_L06
10%
ZCODI_L07
10%
ZCINVA07
10%
ZCINVL07
10%
ZCDELA07
10%
ZCDELL07
10%
ZCSRIA07
10%
ZCSRIL07
10%
41
21. Performance Enhancements — Aggregates Are Often
Incorrectly Built
•
•
Several cubes
have no
aggregates,
while others
can benefit
from
generating
new proposals
A score above
30% for
average
aggregate
valuations
should be a
target for a
data store
42
21. Performance Enhancements — Correct Aggregates Are Easy
to Build
•
This example shows the benefits of aggregates by
using system statistics to generate proposals

This very large InfoCube had over 160 queries attached to
it and only one aggregate
•
•
Select the run time of queries
to be analyzed (e.g., 20 sec)
Select time period to
be analyzed

•
Only those queries executed in
this time period will be reviewed
to create the proposal
High value aggregate proposal
(users who had queries that ran
over 20 seconds during the last
six months would have
benefited from 438 times —
each query execution)
43
22. Memory Cache Is Often Set Too Low
•
The cache settings at many companies are too low

•
For example, at one large company the cache was set at 100 MB for local
and 200 MB for global cache, which is too low for a system with
thousands of users and 4 TB of data
Review the settings with the Basis team and look at the available
hardware
During the review, use the transaction code RSCUSTV14 in SAP
NetWeaver BI to increase the cache, if needed
 Focus particularly on the global cache

•
To monitor the usage of the cache, use transaction code
RSRCACHE and also periodically review the analysis of load
distribution using ST03N – Expert Mode
Example: At one company, over 61% of all 35,644
navigation steps in a month accessed the database
instead of the cache, even after the query was executed.
44
23. Use the BEx Broadcaster to Pre-Fill the Cache
Distribution Types
By broadcasting the query result of commonly
used queries to the cache, your users do not
need to execute the query from the database.
Instead the result is already in the system
memory (much faster).
45
24. Focus Performance Enhancements on Large InfoCubes
Type
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoCube
InfoArea
Non SAP Area - SFIO
Non SAP Area - SFIO
Fin. Mgmt & Controlling - Profit Center Acct.
Fin. Mgmt & Controlling - Profit Center Acct.
Fin. Mgmt & Controlling - Profit Center Acct.
Fin. Mgmt & Controlling - Profit Center Acct.
•
SFIO OIPR History
SFIO OIPR
Profit Center Accounting - Customer
Profit Center Accounting - Vendor
Profit Center Accounting - Other
PCA: Summary 1
Tech Name
ZSD_OIPHS
ZSD_OIPR
ZPCA_C09
ZPCA_C08
ZPCA_C10
ZPCA_C03
Index
x
x
x
x
x
x
Stats
x
x
x
x
x
x
No of Rows
157,218,110
157,131,010
119,969,043
116,068,014
116,012,946
108,784,493
Typically 20% of the cubes and queries will see 80% of
the usage

•
Name
Focus on these when performance tuning, or it can become
overwhelming
InfoCubes with over 100 million rows should be analyzed for
performance enhancements, such as broadcasting of queries
to cache, aggregates, indexes, database stats, etc.
Avoid building local queries that are unique to the various
geographies or business units. Focus instead on the reusability
of global queries that are saved as local views (favorites).
46
What We’ll Cover …
•
•
•
•
•
•
•
•
•
Introduction
Scoping the SAP NetWeaver BI project
Getting the project started - project plans & execution
Designing InfoCubes — the good, the bad, and the ugly
Improving performance — what to do, and how to do it
Understanding the curse of MultiProviders
Cleaning up and DSO management
Considering global integration points
Wrap-up
47
25. Avoid “Swiss Army Knife” MultiProviders: It Will Be Slow!
•
There is a temptation to use only a few MultiProviders to build
all queries


This may dramatically slow down queries
Hint: This design may prevent queries from being executed in parallel
Avoid attempting to
build a single
MultiProvider to do all
functions of the data
warehouse
48
25. “Swiss Army Knife” MultiProviders and Parallel Processing
•
To avoid an overflow of the memory, parallel processing is
cancelled as soon as the collected result contains 30,000
rows or more and there is at least one incomplete subprocess


•
The MultiProvider query is then restarted automatically and
processed sequentially
What appears to be parallel processing corresponds to sequential
processing plus the preceding phase of parallel processing up to
the termination
Generally, it’s recommended that you keep the number of
InfoProviders of a MultiProvider to no more than 10 (ideally
less than 4-5)
Avoid creating InfoCubes that are specific to one country or
business unit. If you do this, you will have to later combine
them in large MultiProviders that may cause slow performance.
49
25. MultiProviders and Parallel Processing (cont.)
•
Consider deactivating parallel processing for those queries
that are MultiProvider queries and have large result sets

With SAP BW 3.0B SP14 (SAP BW 3.1 SP8), you can change the
default value of 30,000 rows — refer to SAP Notes 629541, 622841,
607164, and 630500
•
A larger number of base InfoProviders is likely to result in a
scenario where there are many more base InfoProviders than
available dialog processes, resulting in limited parallel
processing and many pipelined sub-queries
•
Create ‘hints’ to direct queries when you use MultiProviders
to link physically partitioned InfoCubes (i.e. by year)
50
What We’ll Cover …
•
•
•
•
•
•
•
•
•
Introduction
Scoping the SAP NetWeaver BI project
Getting the project started - project plans & execution
Designing InfoCubes — the good, the bad, and the ugly
Improving performance — what to do, and how to do it
Understanding the curse of MultiProviders
Cleaning up and DSO management
Considering global integration points
Wrap-up
51
Tip 26: Clean Up Old Objects That Are No Longer Used
•
•
After a few years of running SAP NetWeaver BI, companies
often have many objects that are no longer used
Cleaning them up makes for a simpler development
environment, which is easier to navigate and has a positive
impact on analysis when designing new objects
Keep your environments clean of obsolete junk.
52
Tip 27: Don’t Replicate Legacy Data Logic in SAP NetWeaver BI
•
It’s tempting to replicate the SAP transaction system in the
BI environment
•
You can spot this when you find many DSOs that serve as
lookup tables (easy to recognize, because these systems have
many DSOs and each of them have few fields)
Number of fields per ODS
14
12
Number of ODSs
Don't allow the BI
system to become a
replication of the
transaction system,
merely because that
is what your
developers know.
10
8
6
4
2
0
0-5
6-10 11-15 11-20 21-30 31-40 41-50 51-60 61-70 71-80 81-90 90+
53
Tip 28: Avoid Direct Querying of DSO (ODS)
To quickly solve local reporting requirements, it is tempting
to bypass the global InfoCubes and query the DSO (ODSs)
directly — this is a mistake
•
DSOs are for central staging of historical data, detailed analysis,
lookups, and data mining — not for local reporting
•
If you allow the users to bypass the global InfoCube logic, you
will find yourself supporting slow local queries that do not take
full advantage of the inherent performance of the OLAP processor
•
Many local detailed queries will consume system resources,
causing other global users to suffer
•
If you follow this path, you will be asked to create InfoSet queries
and eventually have minimal advantages of standard content,
which will lead you to the road to build a traditional legacy data
warehouse
Restrict the number of users that can access the DSOs.
54
What We’ll Cover …
•
•
•
•
•
•
•
•
•
Introduction
Scoping the SAP NetWeaver BI project
Getting the project started - project plans & execution
Designing InfoCubes — the good, the bad, and the ugly
Improving performance — what to do, and how to do it
Understanding the curse of MultiProviders
Cleaning up and DSO management
Considering global integration points
Wrap-up
55
Tip 29: Be Aware of Divergent Country Accounting Rules
•
Different accounting standards must be dealt with on
global projects
 For
example, pension obligations are considered long-term
debt in most European countries and long-term liabilities in
the US (unsecured)
•
Accounting rules for depreciation, amortization,
depletions, and allocations vary from country to country
 For
example, the US allows for accelerated depreciation in
certain instances
Plan on involving accountants and mapping tables if you are
consolidating reporting for both local and global purposes.
Make sure you have an audit trail of transformations.
56
30. Standardization - Currency and Units of Measures
•
A global BI requires standardized currencies and Units of
Measure (UOM) for aggregate reporting
•
Conversions from pounds to kilos, or from liters to gallons
are easy, but you have to decide how to handle currencies

Possible solution A: Some companies use a pro-forma currency translation
rate for reporting during an interim period and a real currency translation
rate when the financial books are closed or funds are transferred

Possible solution B: Some companies use previous month’s currency
translation rate for reporting during an interim period and a real currency
translation rate when the financial books are closed or funds are transferred
Sites like www.xe.com can provide you pro-forma currency
translation daily, but you have to make a decision.
57
30. Standardization - Hierarchies — Global vs. Local
•
On a global project, you can create local and global
hierarchies
 For
example, a large European telecom company created a fivelevel sales material hierarchy in BI that reflected the Dutch
reporting view, a seven-level hierarchy that reflected the German
reporting view, and a four-level hierarchy for corporate reporting
 This
allowed reporting for each subsidiary and a new corporate
reporting hierarchy that was not available in any local system
•
Lessons learned: You don’t have to select a single
hierarchy; local needs can also be accommodated
MultiProviders can be used to mask the
complexity for the query developers.
58
What We’ll Cover …
•
•
•
•
•
•
•
•
•
Introduction
Scoping the SAP NetWeaver BI project
Getting the project started - project plans & execution
Designing InfoCubes — the good, the bad, and the ugly
Improving performance — what to do, and how to do it
Understanding the curse of MultiProviders
Cleaning up and DSO management
Considering global integration points
Wrap-up
59
Resources
•
Steve McConnell, Rapid Development (Microsoft
Press, 1996).

•
Jeremy Kadlec, Start to Finish Guide to IT Project
Management (NetImpress, 2003).

•
www.Comerit.net
European privacy laws

•
ISBN: B0000W86H2, Digital, 109 pages
Presentations and accelerators)

•
ISBN: 1556159005
www.msnbc.msn.com/id/15221111
European Commission’s Directive on Data Protection

www.export.gov/safeharbor
60
7 Key Points to Take Home
•
Be sensitive to other cultures and don’t enforce US
working methods
•
More than one methodology is available for you to use
•
Long-term environment sizing and planning is critical
•
Performance tuning is not an afterthought, but a project task
•
An SAP NetWeaver BI architecture should be formulated before a
project starts
•
Plan for BI cockpits and dashboards — they are not nice-to-haves,
but a critical part of BI
•
Get the global team active and develop the SAP NetWeaver BI
solutions for local and global needs
61
Your Turn!
How to contact me:
Dr. Bjarne Berg
[email protected]
62