Transcript Session Title

Testing and Go-Live
Best Practices for
a Successful
Dashboard Rollout
Dr. Bjarne Berg
Comerit
© 2012 Wellesley Information Services. All rights reserved.
14
1
13
Seminar Roadmap
Best-in-Class
Deployment,
Dashboards
Testing & Change
Management
• Dashboards vs. reports
We are here
12
•
•
•
•
•
Key dashboard roll-out decisions • Answers to dashboard FAQs
• SAP BusinessObjects Dashboards
Mobilizing your dashboard
4.0 overview
Support organization
• Product updates and
Volume, stress, and UAT
implementation criteria
Training and change management • Recent changes to dashboard
terms
Options &
Prototyping
11 Performance
& Security
10
• Common causes of poor
dashboard performance
• Effective performance testing
• Performance-enhancing design
techniques
• Preventing unauthorized access
to dashboards
• Password protection
Customization,
and SSO
Branding &
Governance
• Hands-on lab: Advanced techniques
• Web service integration and Adobe
Flex Builder
• Panel discussion: Dashboard Projects
• Ownership and branding
9 • Post-production changes
8
©
SAP AG 2009 / 1
2
7
•
•
•
•
•
Scoping vs. requirements gathering
KPI definitions
Required skills and resources
Data connectivity deep dive
Key criteria to retrieve data sets
Landscape,
Connectivity &
Sizing
• Hands-on lab: Build a dashboard
with BOBJ Dashboards 4.0
• Sizing and scaling recommendations
• User management and access
5
control
®
• SAP NetWeaver BW
Accelerator and
SAP HANA
6
3
4
What We’ll Cover …
•
•
•
•
•
•
•
•
Planning for the SAP BusinessObjects Dashboards initiative
Understanding the JAD, RAD, Agile (XP), or ASAP methodology
Getting the right dashboard requirements
Upgrading and migrating tools
Defining the SAP BusinessObjects Dashboards testing approach
Rolling out dashboards: Big-bang vs. gradual go-lives
Designing the BI support organization
Wrap-up
2
Go-Live Planning for the SAP BusinessObjects Dashboards
(Formerly Xcelsius) Initiative
•
•
During the planning phase, you should also start planning your
go-live strategy
This includes answering the following questions:
 Where are my users located?
 What is the network capacity?
 Do I need support people for extended time periods — Different
time zones?
 Do I need multi-currency support on my dashboards?
 Do I need multi-language support?
 What type of users do I have in
each region?
Create a user map as part of your
project planning. This will help you
understand your user base.
3
User Training Options
•
•
•
There are four core options for the training strategy
Classroom training
 Best when users are similar and centrally
located
Online training
 Best when users are dispersed, dashboards
are simple, or go-live is over a long time period
Train the trainer
 Best when users reside in many locations, multiple languages
are involved, and when there is a very high number of users
One-on-one training
 Best for executives and senior management
 Should be done at each user’s office
Source: Dashboard Insights, 2009
•
•
Communicate and schedule training early in
the project so that everyone will be available
User Training for Complex Dashboards
•
•
If users need training, then you have often failed to create good
dashboards
However, there are times when training is needed; this includes:
 Interactive dashboards and dashboards with complex graphing
In this dashboard, users
can budget for travel
categories for each
month, and also save
scenarios.
Therefore, some
training is required and
should be planned early.
5
Plan for an Online Help System for Your Dashboards
Go-Live
•
•
Online help should be created for each dashboard
The online help system should
explain:
 How numbers are calculated
 How to read graphs
 What functionality is
embedded
6
How to Create Online Help Systems
•
Some ways to create a low-cost
online help system include:
 Flash files
 Create a simple help dashboard and
embed this into the overall
dashboard
 Word
 Create a word document with
screenshots
 Save it as HTML and store the Web
pages on a Web server
 You can then link the URL on your
dashboard
 Custom Application
 Use a tool-like front page or any Web
authoring tool and create a complex
online help system with menus,
search functionality, movies that
show demonstrations, etc.
Online help centers can include contact
information and training schedules.
They can also be used to communicate
information on future projects.
7
What We’ll Cover …
•
•
•
•
•
•
•
•
Planning for the SAP BusinessObjects Dashboards initiative
Understanding the JAD, RAD, Agile (XP), or ASAP methodology
Getting the right dashboard requirements
Upgrading and migrating tools
Defining the SAP BusinessObjects Dashboards testing approach
Rolling out dashboards: Big-bang vs. gradual go-lives
Designing the BI support organization
Wrap-up
8
The JAD, RAD, Agile (XP), or ASAP Methodologies
•
•
There are several options for the SAP BusinessObjects
Dashboards project
 Joint Application Design (JAD)
 Rapid Application Development (RAD)
 Agile or Extreme Programming (XP)
 Accelerated SAP Methodology/System Development Lifecycle
(SDLC)
Many of the methodologies are not appropriate for the dashboard
development effort
Pick your SAP BusinessObjects Dashboards methodology carefully.
Do not use ASAP unless your project is part of a budgeting,
consolidation, or planning effort.
9
The “Waterfall Methodologies” Are Not Good for
Dashboards
•
•
The System Development Lifecycle (SDLC) methodologies, such
as ASAP, are known collectively as “waterfall methodologies”
They give a false sense of clear-cut stages, and do not address
substantial functionality changes during development
 It is hard to fix missing functionality during integration testing
The waterfall
Examples for Accelerators:
• Project Plan, Estimating
• Design Strategies, Scope Definition
• Documentation, Issues Db
Fill
Fillin
inthe
theBlank
Blank
Versus
Versus
Start
from
Scratch
Start from Scratch
• Workshop Agenda
• Questionnaires
• End-User Procedures
• Test Plans
• Technical Procedures
• Made Easy guidebooks (printout, data transfer, system
administration…)
Source: SAP
The challenge with ASAP is that users don’t know
what they want until they see it …
10
The ASAP Methodology Overview
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
11
Joint Application Design (JAD) — Who Participates?
1.
2.
3.
4.
5.
6.
•
Facilitator — Facilitates discussions, enforces rules
End Users — Three to five, attend all sessions
Developers — Two or three, question for clarity
Tie Breaker — Senior manager; breaks end-user ties, doesn’t
attend
Observers — Two or three, do not speak
SMEs — A few subject matter experts (SMEs) for understanding
business and technology
Keep it very focused and explore the interfaces. How do the users
want to see the screen layouts and functionality?
A study of 60 development projects found that,
without JAD, 35% of the functionality was missed
(Source: Caper Jones, Software Quality, Reliability, and Error Prediction )
12
Rapid Application Development (RAD)
•
•
•
•
•
RAD has an abbreviated blueprinting phase where meetings are
executed in short succession to get the requirements
 Most of the blueprinting and realization
phases of the project are combined
The first meeting: A one or two-day work session
with uninterrupted time
Who: Power users, casual users, people who today interact with
the current system, and managers who have a stake in the
outcome of the dashboards
How many: A rapid pace is kept in these meetings and the number
of attendees is kept to no more than seven people in attendance
The coordinators should focus on shared information needs and
conduct multiple sessions (typically once a week)
Why RAD? Increase involvement, less business disruption, less
opinions, more consensus, information sharing, and an education event.
13
Agile and Extreme Programming (XP) for SAP
BusinessObjects Dashboards
•
•
XP was started by programmers who decided
that the traditional requirements gathering
sessions took too much time, and often just
verified what they already knew
The argument for XP is that other methodologies were developed
to build software for low levels of change and reasonably
predictable outcomes


But the business world is no longer very predictable, and
software requirements change at extremely high rates
Development can be completed faster with collaborative
efforts of paired programmers with small “sprint”
timelines and many go-lives
The core premise of XP is that you can only pick three out of these
four dimensions: cost, quality, scope, and time
14
Framework for Picking Your Dashboard Methodology
When to Select Different Methodologies
High
Joint Application Design
(JAD)
System development Life-Cycle
based methodologies
(SDLC)
Extreme Programming
(EP)
Rapid Application Development
(RAD)
Time to
Delivery
Low
Low
High
Impact of Failure
Source: Dr. Berg,
DM Review, 2006
15
What We’ll Cover …
•
•
•
•
•
•
•
•
Planning for the SAP BusinessObjects Dashboards initiative
Understanding the JAD, RAD, Agile (XP), or ASAP methodology
Getting the right dashboard requirements
Upgrading and migrating tools
Defining the SAP BusinessObjects Dashboards testing approach
Rolling out dashboards: Big-bang vs. gradual go-lives
Designing the BI support organization
Wrap-up
16
The SAP BusinessObjects Dashboards Business
Requirements
•
•
Business requirements can be collected in a variety of ways
based on the methodology that the company employs
It is a complex process and involves the periods:
A dashboard implementation does not simply
 Discovery and education
involve a series of black-and-white technical
 Formal communication
decisions; just because something is
 Prototypes and reviews
technically feasible does not mean it is wise
or desirable from a business perspective
 Final approvals
Source: Gooy_GUI, 2007
Where Do You Start? — First Alternative
You can start with a
blank template and
fill in the capabilities
Focus on graphs,
layout, measures,
and navigation
One method is to
write storyboards
from a user
perspective and add
needed functionality
to support this
18
Where Do You Start? — Second Alternative
Get a group of five to seven people
for a brainstorming session
Draw the solution, knowing that it
may look somewhat different once
developed
Focus on the use of space, graphs,
navigation, available data, and the
purpose of the dashboards
Do not design fixed-format “reports”
19
Building a Mockup in Excel
•
If you can make a “mockup” in Excel, users can see what it may look
like very quickly
 You do not need to have any SAP BusinessObjects tools installed
This can be done in 30-60 minutes
20
Prototyping the Dashboard Requirements
•
•
Once the first day of brainstorming is completed, you can create data in
Excel and prototype the solution in SAP BusinessObjects Dashboards
Focus on layout, space management, colors, and basic formatting
Plan for multiple weekly prototypes before you get
the solution that everyone can agree on
21
Flexible Options to Meet Many Requirements
•
There are often disagreements on how to present numbers and graphs
Make your
dashboard flexible
and present data in
many interactive
ways
Amount vs. Percentages
Different graphs
Users can select what
they want graphed
22
What We’ll Cover …
•
•
•
•
•
•
•
•
Planning for the SAP BusinessObjects Dashboards initiative
Understanding the JAD, RAD, Agile (XP), or ASAP methodology
Getting the right dashboard requirements
Upgrading and migrating tools
Defining the SAP BusinessObjects Dashboards testing approach
Rolling out dashboards: Big-bang vs. gradual go-lives
Designing the BI support organization
Wrap-up
23
Tool Upgrades and Deployment of New SAP
BusinessObjects Dashboards Functionality
•
When you upgrade your SAP BusinessObjects Dashboards,
consider a multi-step approach
 Conduct a developer training or workshop session to learn the
new functionality and agree on the upgrade timeline
 Do a technical upgrade over the weekend
 Copy all of the dashboards
 Implement new functionality on the copied dashboards
 Have a formal feedback session with user involvement to see
how they like the changes
 Implement the new changes two to six weeks after the technical
upgrade
Stability is the key to success in all end-user systems.
Even if the new functionality is better, users do not like
a system that changes look and feel frequently.
24
Tool Migration Strategy
•
•
If you are migrating users from a legacy reporting tool to your new
dashboards, you need a formal migration strategy. This could
include:
 Maintaining two systems (not recommended)
 Running two systems in parallel for a short time to reconcile
results
 Removing a legacy reporting tool as part of go-live
(recommended)
When Vikings settled new lands, they always burned the boats so
that the settlers were 100% committed to the new situation
 While it caused some anxiety, this is a great migration strategy
that can be used for system migration efforts, as well
A “burn-the-boats” reporting migration strategy assures high
commitment to the new solution and possibly a high number of
new requirements after go-live. Be prepared to support this.
25
What We’ll Cover …
•
•
•
•
•
•
•
•
Planning for the SAP BusinessObjects Dashboards initiative
Understanding the JAD, RAD, Agile (XP), or ASAP methodology
Getting the right dashboard requirements
Upgrading and migrating tools
Defining the SAP BusinessObjects Dashboards testing approach
Rolling out dashboards: Big-bang vs. gradual go-lives
Designing the BI support organization
Wrap-up
26
The Dashboards Test Methodology
•
Dashboards testing should follow a formal
methodology
Test Strategy
Test Plan
Test Execution
Problem Resolution
•
The test strategy is written at the
beginning of the project and
should include:
 What will be tested?
 Who will test it and approve it?
 Where will the test occur?
 When will the test be
scheduled?
The test plan is more detailed and should be
written once the first prototype is built
27
The SAP BusinessObjects Dashboards User Acceptance
Testing (UAT) Form
Theme
Area
Approved
Change
Wanted
Description
Background color &
Image
Button layout &
locations
Link names &
locations
Chart and Table
names & location
Table location
Tables
Table and font size
Colum order
Sort ability
Summary row
layout & colors
Graph type
Graph location
Graph labels & size
Graphs
•
By requiring each of the
five to seven UAT members
to complete a form for each
dashboard, you get solid
feedback that you can use
in the next RAD
development cycle
During each UAT test
cycle, you should solicit
detailed feedback on
layout, graphs, theme,
tables, and navigation
Graph colors
Ability to change
graph type
Ability to select
fields
Usefulness of fields
displayed
Drilldown to more
detail
On-line help
Navigation
•
Dashboard Name:
Print
Save
Single sign-on
Other
Comments:
Approvers Name:
Approvers Signature:
28
The SAP BusinessObjects Load Testing Form
•
•
•
The load testing is
intended to show any
performance issues
prior to the go-live
While all areas cannot
be tested, this will give
you an idea on
bottlenecks
For large scale golives, you should
consider having test
PCs in multiple
locations
Dashboard Name:
Estimated number of named users
Concurrent
User Type
Number
Factor
Users
Casual Users (less then 2-5 times monthly)
20%
Power Users (daily)
40%
Executive Users (2-10 times monthly)
25%
Total:
Load Testing
Test lab setup
Number of PCs required
(concurrent users divided by 5)
Batch script created (i.e. Java script)
5 copied of script installed on each PC
Execution
Start scripts on each PC
(continuous loop)
Pass
Issue
Findings
Monitor BOBJ BI Server Load
Monitor BW App sever load
Monitor BW Server load
PC load time
(average of 10 dashboard loads)
Comments
29
The SAP BusinessObjects Stress Testing Form
•
•
•
•
Stress testing is very
similar to load testing
The difference is that the
number of concurrent
users is expected to be
doubled
Not all companies will use
a stress test, nor pass it
 This is due to the
unrealistic concurrent
load and the high
hardware costs of
meeting them
However, it provides very
useful information
Dashboard Name:
Estimated number of named users
Concurrent
User Type
Number
Factor
Users
Casual Users (less then 2-5 times monthly)
40%
Power Users (daily)
80%
Executive Users (2-10 times monthly)
50%
Total:
Stress Testing
Test lab setup
Number of PCs required
(concurrent users divided by 5)
Batch script created (i.e. Java script)
5 copied of script installed on each PC
Execution
Start scripts on each PC
(continuous loop)
Pass
Issue
Findings
Monitor BOBJ BI Server Load
Monitor BW App sever load
Monitor BW Server load
PC load time
(average of 10 dashboard loads)
Comments
30
SAP BusinessObjects Dashboards Test Planning
Key Activities
Tasks
1
2
3
4
5
Create test script
Identify roles to be used
Documentation on using test tools
Procedure for documenting test results
Training sessions for using test scripts
6
7
8
9
Identify key contacts
Communicate about transports
Arrange time for progress control
Schedule facilities
The business analysts are responsible for planning,
coordinating, and executing the testing of dashboards
31
Deliver
Cost and Profitability
Order
Manufacturing
Plan and scheduling
Demand planning
Source
Environment
preparation
4/2
4/1
3/31
3/30
3/29
3/28
3/27
3/26
3/25
3/24
3/23
3/22
3/21
3/20
3/19
3/18
3/17
3/16
3/15
3/14
3/13
3/12
3/11
3/10
3/9
3/8
3/7
3/6
3/5
3/4
3/3
3/2
3/1
Large-Scale SAP BusinessObjects Dashboards Test
Scheduling — Example
Resolving
outstanding
issues and retesting
= Morning session 8:30 - noon
= Evening session 12:30 - 5:00
•
•
•
Each UAT team could have dedicated time in the test room
Provide food and snacks
At least two testers (preferably more) should be assigned to test
each functionality
All test results should be logged so that fixes do not
impact other dashboards and consistency is maintained
32
What We’ll Cover …
•
•
•
•
•
•
•
•
Planning for the SAP BusinessObjects Dashboards initiative
Understanding the JAD, RAD, Agile (XP), or ASAP methodology
Getting the right dashboard requirements
Upgrading and migrating tools
Defining the SAP BusinessObjects Dashboards testing approach
Rolling out dashboards: Big-bang vs. gradual go-lives
Designing the BI support organization
Wrap-up
33
Big-Bang vs. Gradual Go-Lives
•
•
•
•
There are many ways to do a gradual rollout of the dashboards
The simplest way is:
 Bring all content into the production box
 Set up the roles in the production
environment
 Gradually release roles to the end users
The benefit of doing this is that you can see how the system
performs
 And you can solicit feedback from an increasingly large user
group before you release the dashboards to many users
A gradual go-live can reduce the potentially negative impact on
the organization
Unless the dashboards are for a single department, or very few users,
you should always plan for a gradual go-live
34
Gradual Go-Lives by Region
•
A gradual go-live by region makes sense if:
 Training is needed
 Multi-language support is required
 A high number of users are expected
 Dashboards are tailored to local needs
•
When you use a regional go-live strategy, you can also roll out the
dashboards to power users first (i.e., one month before go-live) to
see how the system works in a real production setting
Global dashboards require serious attention to language support, user
support, 24/7 availability, and to non-native English speakers
35
SAP BusinessObjects Dashboards Go-Live by Organization
Units
•
A gradual go-live by Organization Units makes sense if:
 Organization is very large
 Departments have very different needs
 Dashboards are tailored to department needs
 Data must be secured between organizations
•
When you use an organizational go-live strategy, you need to
focus on the branding of each dashboard (e.g., logos of
subsidiaries) and on integration of support functions in their
organizations (e.g., help desk)
Departmental dashboards should have first-level
support in their respective business units
36
What We’ll Cover …
•
•
•
•
•
•
•
•
Planning for the SAP BusinessObjects Dashboards initiative
Understanding the JAD, RAD, Agile (XP), or ASAP methodology
Getting the right dashboard requirements
Upgrading and migrating tools
Defining the SAP BusinessObjects Dashboards testing approach
Rolling out dashboards: Big-bang vs. gradual go-lives
Designing the BI support organization
Wrap-up
37
BI Support Organization — Big Picture
•
•
You need to separate the operations of BI systems from the
project work
If there is no support organization, the BI system quickly becomes
an orphan when the project ends
Without a support
org there is a risk
that future BI
projects will be
delayed, since the
project team has
to support
previous projects
38
An Example of a Large BI Support Team
Note: Job areas are meant for
illustration and will vary
depending on the BI
applications supported
Dashboards
(i.e., SAP
BusinessObjects Dashboards)
Full-time
BI Query
(i.e., Web Intelligence, BEx)
Full-time
Support leader
Full-time
Help desk,
user support
SAP BI Basis
Data loads & fixes
Full-time
Full-time
Data quality &
data resource mgmt.
Data loads & fixes
Full-time
Training,
user support
Full-time
Full-time
Full-time
Portal, collaboration,
KM, security
Full-time
This large team can support complex applications, cockpits, BI
portals, and broadcasting, while providing training and help desk
support, as well as on-going data warehousing production support
39
What to Include in a BI Dashboard Service-Level
Agreement (SLA)
1.
2.
3.
4.
When must data stores be loaded by (time)?
 What will happened if a persistent problem occurs (“swat” teams)?
 Who is responsible for fixing process chains, and who pays?
 Do you get a discount for each data store that is not loaded in time?
How should Service Packs and Fix Packs be applied?
 When will SP, FP, and SAP Notes be applied?
 Who pays for it?
 Who is responsible for testing them?
When will the SAP BusinessObjects system be upgraded?
 When will upgrades occur, how is the pricing determined?
 Who pays for it, and who is responsible for testing?
 How long can the system be offline?
Minimum uptime and target uptime
 What is uptime defined as (data store loaded vs. queries available vs.
security fixes applied vs. portal uptime vs. third-party reporting tool uptime
vs. network uptime vs. SAP BusinessObjects Dashboards issues, etc.)?
 What are the penalties (money) for missing the dashboard uptime
requirements?
40
What to Include in a BI Dashboard Service-Level
Agreement (SLA) (cont.)
5.
6.
7.
8.
Issues log
 What issues must be logged?
 Who owns the log? Do you have access?
 Can entries be updated, or must an audit trail be preserved?
Backup and disaster recovery
 What is included in the backup and when is it taken?
 When will restore abilities be tested?
 How fast must restore occur, and what data stores and users will first have access
(priority list)?
Who owns the data?
 If you switch vendors, who owns the data?
 How will you get access to the data? Do you get full insights to all?
 Who, of the vendor’s employees, gets access to your data? Can they share it with
your competitor?
Service tickets
 When will service tickets be monitored?
 What are the categories and who will resolve them?
 What are the resolution processes and timelines?
 How are customer and support satisfaction measured?
41
What to Include in a BI Dashboard Service-Level
Agreement (SLA) (cont.)
1.
Escalation process
 What will happened if an
issue cannot be resolved by
the internal IT department/
vendor and your business
SLA manager?

What are the steps needed to terminate the SLA contract, and
are there any payments/fault payments or a budget recourse
(i.e., move money from cost centers)?
The more details you put into the dashboards SLA
upfront, the easier it will be to measure, and the more
likely you are to have a successful relationship
42
Selecting Objective Measures for the SLA
•
•
Measures drive behavior,
so be careful when
selecting them. They
should be:
 Simple to understand
and easy to calculate
 Meaningful, and drive
the behavior you want
to encourage
 Controllable and
immune to
manipulations
Instruments that collect
measures must be
consistent over time and
as automated as possible
Sites such as the free online KPI Library have over 6,000 standard measure
definitions based on the SEC, API, ISO, FASB, GAAP, IEEE, and other organizations
43
Standardized SLA Performance Measures
•
Standard measures exist for SLAs. These include:
 First-Level Call Resolution (FLCR)
 Average Call Answer Time (ACAT)
 Percentage Calls Re-Opened Within Two Weeks (PCRT)
 Percentage of Training Type Calls (PTTC)
 Number of Tickets Escalated to Level-2 Support (NTE2)
 Percent of Tickets Escalated to Level-2 Support (PTE2)
 Number of Tickets per Service Employees (NTSE)
 Number of Service Employees per User (NSEU)
 Average Service Employees Training Level (ASET)
 Percent Service Employees Certified (PSEC)
 Turnover Rate of Service Employees (TRSE)
 End-User Satisfaction Score (EUSS)
 Number of System Failures (NOSF)
 Number of Critical System Failures (NOCF)
44
Standardized SLA Performance Measures — More to
Consider
•
Additional measures
 Mean Time Between Failures (MTBF)
 Mean Time Between Critical Failures (MTCF)
 Mean Time to Provision (MTTP)
 Mean Time to Repair (MTTR)
 Percent Up-Time Per System (PUPS)
 Percent Down-Time Per System (PDPS)
 Percent Call-Back to Customers (PCBC)
 Cost per Service Ticket (CPST)
 Cost per Service Employee (CPSE)
 Cost per Serviced System (CPSS)
 SLA Operating Efficiency (SLAOE) Consultants can drive the measures and
create balanced scorecards by assigning
 SLA Operating Effectiveness
weights.
(SLAOF)
BEST PRACTICE:
 Employee Turnover Rate (EMTR)
Pick 10-12 initially, and add more as the
relationship matures.
Reasonable SAP BusinessObjects Dashboards SLA
Performance
•
Examples of reasonable performance targets
 90% of all dashboards run under 20
seconds
 System is available 98% of the time
 Data loads are available at 8 am — 99% of the time
 User support tickets are answered within 30 minutes (first
response)
 User support tickets are closed within 48 hours — 95% of
the time
 System is never unavailable for more than 72 hours —
including upgrades, fix packs, service packs, and disaster
recovery
 Delta backups are done each 24-hour cycle and system
backups are done every weekend
46
What We’ll Cover …
•
•
•
•
•
•
•
•
Planning for the SAP BusinessObjects Dashboards initiative
Understanding the JAD, RAD, Agile (XP), or ASAP methodology
Getting the right dashboard requirements
Upgrading and migrating tools
Defining the SAP BusinessObjects Dashboards testing approach
Rolling out dashboards: Big-bang vs. gradual go-lives
Designing the BI support organization
Wrap-up
47
Where to Find More Information
•
•
•
Harold Kerzner, Project Management Metrics, KPIs, and
Dashboards: A Guide to Measuring and Monitoring Project
Performance (Hoboken, NJ: John Wiley & Sons, 2011).
Leopoldo Simini, “Agile Project Dashboards – Bringing Value to
Stakeholders and Top Management (What Can You Do for Your
PO Today?)” (July 2011).
David Parmenter, Key Performance Indicators: Developing,
Implementing, and Using Winning KPIs (Hoboken, NJ: John Wiley
& Sons, 2010).
48
7 Key Points to Take Home
•
•
•
•
•
•
•
Use a RAD, JAD, or XP approach for your dashboards
Have multiple meetings with the user groups
Build interactive prototypes and expect requirements changes
Plan for a formal load testing of the dashboards
Have a roll-out plan and a long-term vision of how to get there
Requirements gathering is interactive, and users are discovering
what they want
Spend serious time planning for support and on-going
enhancements of your dashboards, or they will become useless in
a very short time …
49
Your Turn!
How to contact me:
Dr. Bjarne Berg
[email protected]
50
Disclaimer
SAP, R/3, 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.
51