1
© 2010 Wellesley Information Services. All rights reserved.
Inside an SAP Business Intelligence Project, Part 1: Best Practices for Planning and Project Management Dr. Bjarne BergCOMERIT
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
3
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
4
What We’ll 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
5
Planning Your SAP Business Intelligence Project
1. The business case2. Scope agreement3. Milestones4. Steering committee
6
7
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
8
Business Case Ideas
Users get earlier access to information
Load times in BW are less than traditional,custom- developeddata warehouses
Business users need a high availability solution
Information Access
Users spend less time on reconciling data, and moretime analyzing it
BW is “closer” to the source system, and more accurately reflects data
A substantial portion of the data warehouse effort is spent on reconciling information
Reconciliation Effort
Enables web initiatives to get closer to the source data,both in time and consistency
BW is closely integrated with ERP and can deliver data that reflects the source system at short time intervals
Web delivery requires rapid data delivery of high consistency with the source system
Web strategy
Substantial cost savings, bynot having to redevelop newextract programs for eachSAP upgrade
BW – ERP integration points are maintained and tested by SAP
Updating extract programswhen upgrading ERP is expensive
Cost Avoidance
SAP is responsible for maintenance of the product
Maintaining a custom developed BI solution is complex and expensive
Cost of Ownership
BenefitBI ObservationArea
Information Access
Reconciliation Effort
Web strategy
Cost Avoidance
Cost of Ownership
BenefitSAP BI ObservationArea
Substantial maintenancecost savings
9
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 SAP’s 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 in-memory query performance
Users get the data they need quickly to perform their job functions
More Business Case Examples
10
Area Observation SAP BI Benefit
SAP Strategy It is the organization’s 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 organization’s competitors and some of the organization’s 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
Three More Business Case Examples
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
11
There is a limit to how far you can compress timelines:Brooks law states that "Nine women cannot make a baby in one month“*
Time
Scope
Resources(people, technology,
and money)
* Frederick Brooks, The Mythical Man-Month, Addison-Wesley, 1975)
12
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 2. Formal communication3. Reviews 4. Final approvals
An SAP BI implementation involves more than black-and-white technical decisions; just because something is technically feasible, doesn’t mean it is wise or desirable from a business perspective.
Source: Gooy_GUI, 2007
13
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
14
Change Management Process
Change Request form
Complete?No
ReviewRecom-mended?
Submission
Change Request formNo
Yes
Approved?
No
Scheduled
Developed Unit TestedDev. environment
System testedDev. Environment
Integration testedQA environment
Approved?
Approved?
Approved?
Moved to productionNo
No
No
Yes
Yes
Yes Yes
Yes
IT responsible
Business responsible
Sr. mgmt. responsible
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
15
The front page that the requestor fills out
Requestor Name:Department
Phone number / email
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 possible
Future release
Date Break-fix (right now)
When is the change needed
Change Request Form
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
1616
The back page that the system admin and approver fill out
Received date:Reviewed by:
Comments/recommendation
Pending Not-Approved Future release
Approved Break-fix (right now)
Approval status:
Approved by:Approved date:
Assigned to:Due date:
Pending Prototyped In QA Tested In Production
Development status:
For internal use only
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 it’s 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. 17
What We’ll 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
18
Organizing your BI initiative
1. Budgeting2. Project team organization3. User Acceptance Testing (UAT) and Rapid Application
Development (RAD)
19
Budgeting Process Steps
1. Size the SAP BI effort based on the scope 2. Prioritize the effort3. Map the effort to the delivery schedule4. Plan for number of resources needed based on the scope,
delivery schedule, and the effort
20
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 team’s skill experience and skill level
1. Size the SAP BI Effort Based on the Scope — Real Example
21
Customization
Tech. Dev. infocube
Extraction and transforms
Report and roles
Security and scheduling
Web develop-
ment
User support/ planning
Project mgmt and admin
System docs & manuals
Tech infra-structure
Bus. Analysis, training, req.
gathering, change mgmt.
Total Hours
FinancialsL General ledger line item (ODS) 216 229 188 101 132 134 100 79 150 403 1,732M COPA 158 286 153 127 153 152 120 94 180 470 1,893L Prod cost planning released cost
estimates (COPC_C09)216 229 188 101 133 135 100 79 150 403 1,734
M Exploded itemization standard product cost (COPC_C10)
238 286 216 126 153 152 120 94 180 470 2,035
L Cost and allocations (COOM_C02)
216 1144 188 101 132 135 100 79 150 403 2,648
M Cost object controlling (0PC_C01)
238 286 216 137 153 152 120 94 180 470 2,046Order
L Billing 216 229 187 101 132 135 100 79 150 403 1,732L Sales order 216 229 187 101 132 135 100 79 150 403 1,732L Acct. Rec. (0FIAR_C03) 216 229 187 101 132 135 100 79 150 403 1,732
Deliver L Shipment cost details
(0LES_C02)216 229 187 101 132 135 100 79 150 403 1,732
L Shipment header (0LES_C11) 216 228 187 101 132 135 100 79 150 403 1,731L Stages of shipment (0LES_C12) 216 228 187 101 132 135 100 79 150 403 1,731L Delivery data of shipment stages
(0LES_C13)216 228 187 101 132 135 100 79 150 403 1,731
L Delivery service (0SD_C05) 180 229 133 101 132 134 100 79 150 403 1,641Planning and Scheduling
L Material Movements (0IC_C03) 216 457 132 101 132 134 100 79 150 403 1,904M APO Planning 277 832 216 127 153 152 120 94 180 470 2,621M SNP Integration 277 832 216 127 153 152 120 94 180 470 2,621
Manufacturing Processes M Production Orders 277 832 216 127 153 152 120 94 180 470 2,621M Cross Applications 277 832 216 127 153 152 120 94 180 470 2,621
Total Hours 4,298 8,074 3,587 2,110 2,656 2,681 2,040 1,606 3,060 8,126 38,238
Remember that your sizing also has to be based on the team’s experience and skill level.
22
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
23
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…
24
4. Result: Good Input for the Staffing Costs and Planning
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.
Number of team members
-
2
4
6
8
10
12
14
qtr 1 qtr 2 qtr 3 qtr 4 qtr 1 qtr 2 qtr 3 qtr 4 qtr 1 qtr 2 qtr 3
Use this information to plan for training, on-boarding, and staffing
This spike in resource needs is due to an overlap in the delivery schedule
Now might be a good time to review that decision
How Tightly Should Multiple BI Projects be Controlled?
Source: The Conference Board Survey
The relationship between control and success according to a conference Board Survey of 89 BI projects.
88% Successful 30% Successful
Loose Cooperation(38%)
Independent(38%)
Tight Central Control(24%)
100% Successful
Coordination of Multiple Business Intelligence Projects
25
26
Six Ways to Organize your BI Project Team
Benefits Risks
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
Option
The more distributed the BI development effort becomes, the more difficult it is to maintain communication and get cohesive requirements.
Example 1 — Small Project Team Organization
27
Four to five team members and normally three to six months duration on each go-live depending on scope
BI Basis and functional SAP ERP support
• These are roles, not positions Sometimes one team member can
fill more than one role
Many companies fail to formally assign roles and responsibilities.
As a result, they have many “jack of all trades” and “masters of none.”
Business AnalystPresentation Developer
Business Team
BI ArchitectETL Developer
Technical Team
Project Manager
Project Sponsor
ETL = Extract, Transform, and Load
Example 2 — Medium Project Team Organization
28
This model scales well to teams of up to 12-15 people
Basis and functional ERP support
8-10 team members and normally 2-4 months duration depending on scope
Project sponsor/ Steering
Committee
Project Manager
SAP BIArchitect
Business Analyst(s)
Extract, Transforms and Loads
Data Management(InfoCubes &
ODS)
Presentation Developer(s)
- cockpits & queries
Sr. Business analyst
Business analyst
Sr. ETL developer
ETL developer
Sr. SAP BI developer
SAP BI developer
Sr. Presentation developer
Presentation developer
Example 3 — Large Project Team Organization
29
BI Basis and functional SAP ERP support
15-30 team members and normally 6-18 months duration between each go-live
Portal Developer(s)
BI Architect
Business Analyst/(sub-team lead)BI DeveloperPresentation Developer(s)ETL Developer
Sales Team
Business Analyst/(sub-team lead)BI DeveloperPresentation Developer(s)ETL Developer
Finance Team
Business Analyst/(sub-team lead)BI DeveloperPresentation Developer(s)ETL Developer
Material Mgmt. Team
Project Manager
Project Sponsor/Steering Committee
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
30
On-Boarding ,Training, and SAP Courses
Ideal Yrs Experience (minimum)
Training days (if new in the
role)
In-house training
daysBW Developer 2+ 15 3-5ETL Developer 3+ 15-20 3-5Presentation Developer 1+ 5-10 3-5Project Manager 5+ 10-15 3-5Business Analysts 5+ 5-10 3-5
Don’t underestimate the value of in-house, hands-on training in addition to formal SAP training classes.
Ref Course Who should take the trainingBW-310 Intro to SAP BI AllBW-305 BI Reporting & Analysis End user support and TrainingBW-350 BI Data Acquisition Data loads and FixesBW-360 BW Performance & Admin System adminBW-361 BW Accelerator System adminBW-365 BW Authorizations Information risk mgmtSAP-330 BW Modeling System admin
31
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
RAD Approach For Smaller BI and Cockpit Projects
• In Rapid Application Development (RAD), keep the scope focused and use a simple approach
32
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).
Activate standard content
Review data quality issues
Create 2-3 sample queries
Load InfoCubeUser
acceptance session
Request for modifications In-
scope?
Rejection
In-futurescope?
Make enhancements
Test
Deploy
Yes
No
No
What We’ll 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
33
34
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.
35
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.
36
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.
37
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.
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.
38
Example 4 — Create Drill Downs from Dashboards
39
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®).
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+.
40
It Is All About Performance, Performance, Performance
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.
What We’ll 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
41
Getting Started
1. Methodology and Functional Specs2. Tool Selection3. Report dispositioning
42
43
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
Joint Application Design(JAD)
Rapid Application Development(RAD)
Extreme Programming(EP)
System development Lifecycle based methodologies
(SDLC)
Impact of FailureLow High
Low
High
Time to Delivery
When to Select Different Methodologies
Source: Bjarne Berg, Data Management Review 2004
Look at what your organizational partners have done.
You may know more about RAD than you think!
Monitoring BI Quality and Formal Approval Process: Example
44
Create Functional specs
Peer Review
Complete?
Complete?
Create Technical specs
Peer Review
Complete?
Complete?Structured
walkthrough
Approved?
Configuration
Unit Testing
Integration Testing
System Testing
Structured walkthrough
Approved?
No
No
No
No
No
Yes
Yes
Yes
Yes
Yes
Yes
No
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
46
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
47
End User
Power User Author
IT Developer Graphing Navigation
External data
External web
services Simplicity OLAPAd-Hoc
queryingWeb Application DesignerDashboard Designer (Xcelsius)
Visual Composer
Interactive Analysis (WebI)
CapabilitiesDevelopmentTool
Long-term
Stategy
SAP's Vision — Who Should Do What … ..
• SAP has a vision of which SAP BusinessObjects tools are appropriate for the different user groups
48Source: SAP
49
cuTeam starts by reviewing documentation tool for
documentation completeness
D1Is report
documentation complete?
Request additional input from Business
Team member
Responsible Team member
acquires/documents additional information
D2Is this
an Intraday report?
D3Significant
numberof users?
D4 Is the report
system resource
intensive?
D5Does
Standard ERPcontentexist?
D6Does
Standard BWcontentexist?
D7Is it less
expensive tocreate in
ERP?
ERP is selected asReporting Tool
and documentedin doc. tool
BW is selected asReporting Tool anddocumented in doc.
tool
BW is selected asReporting Tooland documented
in the documentation tool
BW is selected asreporting tool and ChangeRequest is submitted ifthe scope changed
ERP is selected asReporting Tool
and documentedin doc. tool
ERP is selected asReporting Tool
and documented
No
Yes
No
No
Yes
Yes
Yes
No
Yes
No
D2.5 Does data exist
in "in-scope" modelsInfocube/ODS
No
Yes
No
D1a Is this a true
reportingneed
Yes
No Communicate tobus. leader
A2Total Cost ofOwnership
Analysis
D8Is BI costeffective?
Yes
No
YesYes
ERP is selected asReporting Tool
and documentedin doc. tool
D9ERP Tool
SelectionProcess
No
BW is selected asReporting Tool anddocumented in doc.
tool
StandardERP
ABAP/Custom
ReportWriter
OtherQuery
Review requirements and identifycorresponding Data Model (InfoCube/ODS)
Communicate finaldisposition
Communicate finaldisposition
Communicate finaldisposition
Communicate finaldisposition
Communicate finaldisposition
ERP team make final disposition
Communicate finaldisposition
Communicate finaldisposition
BW Team to forward completed detailed report specifications based on selected Reporting Tool - BI or ERP
A3Sub-Process Report Consolidation &eliminate if appropriate (winnowing)
A4 Baseline reports
An example of how to decide which reports should be in ERP or the legacy system (refer to printed version)
What We’ll 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
50
51
Resources
• Evan Delodder and Ray Li, Creating Dashboards with Xcelsius: Practical Guide, SAP PRESS, 1st Edition; (September 15, 2010)
• Boris Otto and Jörg 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)
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!52
54
DisclaimerSAP, 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.