0

Inside an SAP Business

Intelligence Project,
Part 1: Best Practices
for Planning and Project
Management
Dr. Bjarne Berg
COMERIT
2010 Wellesley Information Services. All rights reserved.

In This Session

Get expert advice on how to budget, scope, and manage

an SAP business intelligence project Ranging from
SAP BusinessObjects implementations to leveraging
portals

Hear best practices for writing a solid business case for

your BI initiative, defining reasonable scope agreements,
creating a rollout strategy, developing budgets, picking
the right front-end tools, and creating a project
organization that matches scope and delivery plans

In This Session (cont.)

Walk through real examples of four SAP customers that have

implemented SAP BusinessObjects dashboards and cockpits, and
learn how to avoid their top 10 project pitfalls, including performance
and user interface deployment

Explore functional specifications and requirements, and glean

insight into which reports should remain in SAP ERP and which can
be leveraged by your SAP business intelligence and SAP
BusinessObjects front-end tools

Take home best-practice functional specification templates, staffing

templates including roles and responsibilities, and decision flow
charts for SAP business intelligence projects

What Well Cover

Planning your SAP business intelligence project

Organizing your BI initiative
Top 10 lessons learned by four SAP customers that have
implemented SAP BusinessObjects dashboards
Getting started with your BI project
Wrap-up

Planning Your SAP Business Intelligence Project

1.
2.
3.
4.

The business case

Scope agreement
Milestones
Steering committee

Writing the Business Case

The business case must be aligned with some

concrete business benefits
The best way to write a business case is to align it
with one of these areas:

Money

Strategy

Reducing time and effort of delivery

Improved information quality

and access for end users
6

Business Case Ideas

Area

Observation

SAP
BI BI

Benefit

Cost of Ownership

Maintaining a custom developed

BI solution is complex and
expensive

SAP is responsible for

maintenance of the
product

Cost Avoidance

Updating extract programs

when upgrading ERP is
expensive

BW ERP integration
points are maintained
and tested by SAP

Substantial cost savings, by

not having to redevelop new
extract programs for each
SAP upgrade

Web strategy

Web delivery requires rapid data

delivery of high consistency with
the source system

BW is closely integrated
with ERP and can deliver
data that reflects the
source system at short
time intervals

Enables web initiatives to get

closer to the source data,
both in time and consistency

Reconciliation Effort

A substantial portion of the data

warehouse effort is spent on
reconciling information

BW is closer to the
source system, and more
accurately reflects data

Users spend less time on

reconciling data, and more
time analyzing it

Information Access

Business users need a high

availability solution

Load times in BW are

less than traditional,
custom- developed
data warehouses

Users get earlier access to

information

Substantial maintenance
cost savings

More Business Case Examples

Area

Observation

SAP BI

Benefit

Faster Deployment

Need to increase time to

deliver new applications and
enhancements to existing
areas

Typical use of 60-80%

of predelivered
content increases
development speed

Reduced development
time for new decision
support areas

Integrated Products

SAP continues to offer new

products and modules that
the organization might wish
to leverage in the future

SAP NetWeaver BW
is the cornerstone
of SAPs BI product
offerings

Enables closer
integration with other
SAP modules

Query speed

Business users need fast

access to their data

Through use of
summaries and the
SAP NetWeaver BW
Accelerator, the blade
architecture lends
itself to faster inmemory query
performance

Users get the data they

need quickly to perform
their job functions

Three More Business Case Examples

Area

Observation

SAP BI

Benefit

SAP Strategy

It is the organizations
SAP strategy to leverage
investments in SAP to
the fullest extent, and
maximize SAP resource
utilization

SAP BI is an SAP product,

and is based on standard
SAP NetWeaver
technologies (Basis,
ABAP, kernels, etc.)

Strategic fit and synergy

with SAP. SAP Basis,
ABAP, etc., resources
can be used across SAP
projects, including SAP
BI

Tool
Standardization

The organization must

be able to leverage
industry standards to
enable business users to
access data in a variety
of ways

Interfaces such as ODBO

and MDX and Java are
supported by a variety of
major presentation and
Web tools. SAP
BusinessObjects tools can
be integrated rapidly via
native: connections

Simplifies user access

to data; expands options
for using standard
presentation and Web
tools or developing your
own

Industry Trend

The organizations
competitors and some of
the organizations
business areas are
installing SAP BI

Increased industry
resource pool and
knowledge of SAP BI

Enables the organization

to leverage industry
solutions and know-how

The Scope Agreement Dimensions

For the first go-live, keep the scope as small as possible

For example, Accounts Payable, Accounts Receivable, G/L, or
COPA
You have only three dimensions to work with, if one of these
dimensions changes, you have to adjust at least one of the others
Scope

Resources
(people, technology,
and money)

Time

There is a limit to how far you can compress timelines:

Brooks law states that "Nine women cannot make a baby in one month*
* Frederick Brooks, The Mythical Man-Month, Addison-Wesley, 1975)

10

The Scope Agreement A Discovery Exercise

Determining the scope is done in a variety of ways, depending on

which methodology you employ. It is a complex process
involving:
1. Discovery and education
An SAP BI implementation involves more
than black-and-white technical decisions;
2. Formal communication
just because something is technically
3. Reviews
feasible, doesnt mean it is wise or desirable
from a business perspective.
4. Final approvals

Source: Gooy_GUI, 2007

11

Defining The Scope Of Your SAP BI Implementation

First, determine what the business drivers are; Then meet these objectives

Define the scope in terms of what is included, as well as what is not included

Make sure you obtain approval of the scope before you progress any further. All
your work from now on will be based on what is agreed to at this stage.

As part of the written scope agreement, make sure you implement a formal
change request process. This typically includes a benefit-cost estimate for each
change request and a formal approval process.

Source: Gooy_GUI, 2007

12

Change Management Process

IT responsible

Change
Request form

Integration tested
QA environment

Business responsible

No
Approved?

Sr. mgmt. responsible

Yes
Approved?

Submission

No

No

Complete?

No

Approved?

Yes

Yes
Moved to
production

System tested

Scheduled

Dev. Environment

Yes

Review
Recommended?

No

Change
Request form

Unit Tested

Developed

Dev. environment

Yes
No
13

Approved?

Yes

The Change Management Form Page 1

To make this process work, you need a formal instrument

The instrument can be online (i.e., a Web page), electronic (Word
document), or a paper-based system
The form should contain at least these fields

Change Request Form

Requestor Name:
Department
Phone number / email

The front page

that the
requestor fills
out

Describe the change requested, be

detailed

Why is it needed

How important is it that the

change occur? (how would you
manage if this is not done)
TBD

When is the change needed

When
possible

Future
release

Date

Break-fix
(right now)

14

The Change Management Form Page 2

This page is used by the system administrator or the project team

The purpose is to have controlled changes that are scheduled and
tested appropriately
For internal use only
Received date:
Reviewed by:
Comments/recommendation

The back page

that the
system admin
and approver
fill out

Pending

Not-Approved

Future
release

Approved

Break-fix
(right now)

Pending

Prototyped

In QA

Tested

In Production

Approval status:
Approved by:
Approved date:
Assigned to:
Due date:

Development status:

15

15

Do You Have a Plan? The Six Dimensions of BI Management

There are six core global dimensions you must consider before embarking on a
BI project
Project management is important, but its only one of these dimensions
Failure to account for the others may result in project failures.

Source: Peter Grottendieck, Siemens

For each dimension, articulate an approach, constraints, limitations, and

assumptions before you start your project.

16

What Well Cover

Planning your SAP business intelligence project

Organizing your BI initiative
Top 10 lessons learned by four SAP customers that have
implemented SAP BusinessObjects dashboards
Getting started with your BI project
Wrap-up

17

Organizing your BI initiative

1. Budgeting
2. Project team organization
3. User Acceptance Testing (UAT) and Rapid Application
Development (RAD)

18

Budgeting Process Steps

1.
2.
3.
4.

Size the SAP BI effort based on the scope

Prioritize the effort
Map the effort to the delivery schedule
Plan for number of resources needed based on the scope,
delivery schedule, and the effort

Create the Milestone Plan and Scope Statement first, before attacking
the budgeting process
Start the budgeting process by estimating the workload in terms of the
development effort. Refine based on the teams skill experience and skill
level
19

1. Size the SAP BI Effort Based 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 teams

experience and skill level.

20

2. Prioritize the Effort

The next
step is to
prioritize
and outline
the effort
on a
strategic
timeline

Make sure your sponsor and the business community agree with
your delivery schedule
21

3. Use Project Estimates and the Timeline to Create Project Load Plan

There are 480 available work hours per project member per quarter.
Knowing this, we can plan the number of team members we need
22

4. Result: Good Input for the Staffing Costs and Planning

Use this information to plan for training, on-boarding, and staffing
Number of team members

This spike in
resource needs
is due to an
overlap in the
delivery
schedule

14
12
10
8
6

Now might be a
good time to
review that
decision

4
2
qtr 1

qtr 2

qtr 3

qtr 4

qtr 1

qtr 2

qtr 3

qtr 4

qtr 1

qtr 2

qtr 3

Many companies plan a 60%- 40% mix of internal and external resources for a
first go-live. Also, most use $50-$90 per hr for internal budgeting and $90$170 per hr for external resources.

23

How Tightly Should Multiple BI Projects be Controlled?

The relationship between
control and success
according to a conference
Board Survey of 89 BI
projects.

Coordination of Multiple Business Intelligence Projects

Tight Central Control
(24%)

Loose Cooperation
(38%)

Independent
(38%)

88% Successful

30% Successful

100% Successful

Source: The Conference Board Survey

24

Six Ways to Organize your BI Project Team

Option
1

Single site

Distributed analysis

Distributed analysis and design

Co-located analysis and design

Multiple co-located analysis and design

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.
25

Example 1 Small Project Team Organization

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 jack 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 ERP support

Four to five team members and normally

three to six months duration on each go-live depending on scope
ETL = Extract, Transform, and Load

26

Example 2 Medium Project Team Organization

This model scales well to
teams of up to 12-15 people

Project sponsor/
Steering
Committee

Project Manager

SAP BI
Architect

Extract,
Transforms
and Loads

Business
Analyst(s)

Data Management
(InfoCubes &
ODS)

Presentation
Developer(s)
- cockpits & queries

Sr. Business analyst

Sr. ETL developer

Sr. SAP BI developer

Sr. Presentation
developer

Business analyst

ETL developer

SAP BI developer

Presentation developer

Basis and functional ERP support

8-10 team members and normally

2-4 months duration depending on scope

27

Example 3 Large Project Team Organization

Project Sponsor/
Steering Committee

Project Manager

In larger teams, you need to

create functional teams, instead
of the previous technical team
models. This is to avoid islands
of teams that are not really
integrated

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 ERP support

15-30 team members and normally

6-18 months duration between each go-live

28

On-Boarding ,Training, and SAP Courses

BW Developer
ETL Developer
Presentation Developer
Project Manager
Business Analysts

Ref
BW-310
BW-305
BW-350
BW-360
BW-361
BW-365
SAP-330

Course
Intro to SAP BI
BI Reporting & Analysis
BI Data Acquisition
BW Performance & Admin
BW Accelerator
BW Authorizations
BW Modeling

Ideal Yrs
Experience
(minimum)
2+

Training days In-house

(if new in the training
role)
days
15
3-5

3+

15-20

3-5

1+

5-10

3-5

5+

10-15

3-5

5+

5-10

3-5

Who should take the training

All
End user support and Training
Data loads and Fixes
System admin
System admin
Information risk mgmt
System admin

Dont underestimate the value of in-house, hands-on

training in addition to formal SAP training classes.

29

The User Acceptance Group and Its Role

Create a user acceptance team consisting of five to seven members

from the various business departments or organizations

Keep the number odd to assist with votes when decisions need to be
made. With fewer than 5 members, it can be hard to get enough
members present at each meeting

Make this team the focus of your requirements gathering in the early
phase, then let this team perform user acceptance testing during the
Realization phase

Meet with the team at least once a month during realization to refine
requirements as you are building, and have something to show them

This approach is hard to execute when also managing scope, but is

essential to make sure that the system meets users requirements
30

RAD Approach For Smaller BI and Cockpit Projects

In Rapid Application Development (RAD), 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

In RAD, no functional or technical specs are used in this approach. Over 8-16
weeks, multiple user acceptance sessions are used to refine requirements and
multiple prototypes are built (think rapid interactive prototyping).
31

What Well Cover

Planning your SAP business intelligence project

Organizing your BI initiative
Top 10 lessons learned by four SAP customers that have
implemented SAP BusinessObjects dashboards
Getting started with your BI project
Wrap-up

32

Example 1 Build on a Solid Foundation

In this company, the data

volumes were very high
Therefore, a set of
summary cubes were
used instead of building
dashboards on top of
large InfoProviders

Lessons # 1: Make sure you build dashboards on top of summary cubes

and data stores where the volume is small and queries can run fast.

33

Example 1 Build on a Solid Foundation (cont.)

Lesson #2: Modularize the
data and always leverage
MultiProviders.

This reduces data

replication, decreases the
number of data updates,
and makes the data
available to the end user
faster.

You can also use the

MultiProviders for other
summary reports beyond
the dashboards.

34

Example 2 Compare to Plans

Lesson #3: Adding
forward looking
dashboards that are
linked to Business Plans
(BP), Rolling Estimates
(RE), and Prior Year (PY)
makes the dashboard
more meaningful.

Lesson #4: Create charts that predict where the sales will be each
month if the trend continues. This makes the dashboard actionable
and tells the users what needs to be done.
35

Example 3 Provide Numbers, not Just Graphs

Lesson #5: Almost
all dashboards
should have graphs
as well as numbers.
Do not create a
visually pleasing
dashboard with just
images. People are
visual as well as
numerical oriented.
In this example, users can toggle between tables and graphs. This
means that the same information does not consume a large space.
36

Example 4 Create Drill Downs from Dashboards

Lesson #6: Users want to see the details without having to log-on to a separate
system. It is not advisable to try to cram too much details in a single management
cockpit (max. 500-1000 rows).

Instead, create jump-to reports from the dashboard. This can be to Interactive
Analysis (SAP BusinessObjects Web Intelligence ) or to existing BW Web queries.

37

Example Four Online Help and Metadata

Lesson #7: When presenting numbers on charts and complex graphs, you should
always provide an online explanation for:
What the numbers mean
How they are calculated
How you read the graphs
This can be developed inside SAP BusinessObjects Dashboard Builder (formerly Xcelsius).

38

It Is All About Performance, Performance, Performance

Lesson #8: It is hard to build a fast dashboard with
many queries and panels without SAP NetWeaver
BW Accelerator. This provides in-memory
processing of queries that is 10-100x faster.

Lesson #9: Pre-running queries into cache via BEx

Broadcaster requires more memory than the 200MB
default values. Analyze your server and consider
increasing the cache to 400MB+.
Lesson #10: MDX cache is for OLAP Universes, OLAP cache is for BICS
connectors used by SAP BusinessObjects Dashboard Builder. Think how
you are accessing the data before you performance tune the system and
always conduct a stress test before deploying any dashboards.

39

What Well Cover

Planning your SAP business intelligence project

Organizing your BI initiative
Top 10 lessons learned by four SAP customers that have
implemented SAP BusinessObjects dashboards
Getting started with your BI project
Wrap-up

40

Getting Started
1. Methodology and Functional Specs
2. Tool Selection
3. Report dispositioning

41

Pick a Formal Methodology You Have Many Choices

Accelerated SAP (ASAP) methodology is not your only choice

Even though they are 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 Life cycle

based methodologies
(SDLC)

Time to
Delivery

Extreme Programming
(EP)

Rapid Application Development

(RAD)

Look at what your

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

42

Monitoring BI Quality and Formal Approval Process:

Example
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

43

Sample Info Request Form

Documents requirements in
a standardized format and
allows for a large comment
section
Prioritizes requirements
Consolidates requirements
Supports follow-up
discussions and reviews

Sample Info Request Form (cont.)

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
45

What Dashboard and Cockpit Tool to Select

All SAP tools have strength and weaknesses

This is a subjective summary of each of the major dashboard
tools
Development

Capabilities

Tool
End
User

Power
User

Author

IT
Developer Graphing Navigation

External
data

External
web
services

Simplicity

OLAP

Ad-Hoc
querying

Longterm
Stategy

Web
Application
Designer
Dashboard
Designer
(Xcelsius)
Visual
Composer
Interactive
Analysis
(WebI)

46

SAP's Vision Who Should Do What ..

SAP has a vision of which SAP BusinessObjects tools are

appropriate for the different user groups

Source: SAP

47

Team starts by reviewing documentation tool for

documentation completeness

An example of how to decide

which reports should be in ERP 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

D7
Is it less
expensive to
create in
ERP?

No

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

Communicate final
disposition

D8
Is BI cost
effective?

Communicate final
disposition

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

Communicate final
disposition

Yes
D9
ERP Tool
Selection
Process

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

No
Standard
ERP

Yes
ERP is selected as
Reporting Tool
and documented
in doc. tool

No

No

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

Yes

A2
Total Cost of
Ownership
Analysis

Communicate final
disposition

D5
Does
Standard ERP
content
exist?

D4
Is the report
system
resource
intensive?

No

Yes

ERP 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

48
BW Team to forward completed detailed report specifications
based on selected Reporting Tool - BI or ERP

Communicate final
disposition

ABAP/
Custom

Report
Writer
Query

Other

A3
Sub-Process Report Consolidation &
eliminate if appropriate (winnowing)
ERP team make final disposition
A4
Baseline reports

What Well Cover

Planning your SAP business intelligence project

Organizing your BI initiative
Top 10 lessons learned by four SAP customers that have
implemented SAP BusinessObjects dashboards
Getting started with your BI project
Wrap-up

49

Resources

Evan Delodder and Ray Li, Creating Dashboards with

Xcelsius: Practical Guide, SAP PRESS, 1st Edition;
(September 15, 2010)

Boris Otto and Jrg Wolter, Implementing SAP Customer

Competence Center, SAP PRESS, 1st edition; 1st edition
(December 1, 2008)

by Frank K. Wolf and Stefan Yamada, Data Modeling in

SAP NetWeaver BW 7.1, SAP PRESS, 1st Edition;
(August 1, 2010)
50

7 Key Points to Take Home

Do not jump into a dashboard project. Create a formal strategy,

plan, budgets, and scope, and train your staff before you start.
Have a formal organization, but do not overstaff. Skills are more
important than numbers.
Spend serious time on the backend BI system. Not all systems are
ready for dashboards Performance is essential.
Consider SAP NetWeaver BW Accelerator as part of your
dashboard project.
Rollout interactive analysis (SAP BusinessObjects Web
Intelligence) as part of the dashboard project Details are
important and users want drill-down capabilities.
Make the first rollout short and focused (12-16 weeks max).
Use Rapid Application Development (RAD) as you methodology
Anything else does not make sense!
51

Your Turn!

How to contact me:

Dr. Berg
Bberg@ComeritInc.com
52

Disclaimer
SAP, ERP, mySAP, mySAP.com, SAP NetWeaver, Duet, PartnerEdge, and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product
and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by
SAP.

53