Transcript Session Title

Field-Tested Techniques for
Gathering and Interpreting
Dashboard Requirements
Singapore – Oct 2014
Dr. Bjarne Berg
COMERIT
Produced by Wellesley Information Services,
LLC, publisher of SAPinsider. © 2014 Wellesley
Information Services. All rights reserved.
What We’ll Cover
•
•
•
•
•
•
Introduction
Dashboard approaches — Agile, JAD, and RAD
Getting the right requirements
Where to start?
A real-world example
Wrap-up
1
In This Session
•
Get best practice rules for conducting dashboard scoping
sessions to effectively gather requirements from all stakeholders
•
Learn how to get the right dashboard requirements and how to
use Agile, Joint Application Development (JAD), and Rapid
Application Development (RAD)
•
Criteria to map dashboard features and functionality to your
specific requirements, depending on whether you are leveraging
SAP BusinessObjects Dashboards, SAP BusinessObjects Design
Studio, or SAP Lumira
2
What We’ll Cover
•
•
•
•
•
•
Introduction
Dashboard approaches — Agile, JAD, and RAD
Getting the right requirements
Where to start?
A real-world example
Wrap-up
3
Who Gets to Do What?
•
The major decision for an SAP BI-driven enterprise is to determine
who gets access to each tool
•
There is often a temptation for the IT community of wanting to
keep the tools under their domain – That is a mistake
•
The IT community should actively work with the power and casual
users to improve human capabilities and thereby teach them to
become more productive employees
4
The 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 following periods:
 Discovery and education
A dashboard implementation does not simply involve a
 Formal communication
series of black-and-white technical decisions; just
 Prototypes and reviews
because something is technically feasible does not
 Final approvals
mean it is wise or desirable from a business perspective
Source: Gooy_GUI, 2007
5
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.
6
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 …
7
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
8
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 )
9
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
10
Agile and Extreme Programming
•
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 Agile is that you can only pick three out
of these four dimensions: cost, quality, scope, and time
11
Framework for Picking a 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
I.e. Scrum and Agile
High
Impact of Failure
12
What We’ll Cover
•
•
•
•
•
•
Introduction
Dashboard approaches — Agile, JAD, and RAD
Getting the right requirements
Where to start?
A real-world example
Wrap-up
13
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
14
Where Do You Start? — Second Alternative — Step 1
Get a group of 5-7 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”
15
Building a Mockup in Excel — Step 2
•
If you can make a “mockup” in Excel, users can see what it may
look like in SAP BusinessObjects Dashboards (formerly Xcelsius)
Users can now see what it may look like
16
Prototyping the Dashboard Requirements — Step 3
•
•
Once the first day of brainstorming is done, 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
17
What We’ll Cover
•
•
•
•
•
•
Introduction
Dashboard approaches — Agile, JAD, and RAD
Getting the right requirements
Where to start?
A real-world example
Wrap-up
18
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
19
Creating Dashboard Standards
•
A dashboard template should be developed that standardizes the font, colors, button
locations, navigations, and tabs. Spend serious time on this; it should become the
global standard for all your dashboards.
20
Senior Management — Graphical Dashboards
•
•
•
•
Dashboards for the senior
management should be
very graphically oriented
Consider using logos and
images instead of text for
this purpose
Navigation should be very
simple
For senior managers, the
ability to interact with the
data (what-if), and see
performance numbers
relative to plan, budgets,
and prior years are critical
functionalities
21
Divide and Get Performance
Drill-down options
Link to Details
WebI reports
Split your dashboards into logical units. This keeps the result set for each
query small and also decreases the load time for each dashboard.
22
Build Several Dashboards for Each Functional Area
•
Avoid trying to create a single
dashboard for each functional area
•
You will normally need 3-5 dashboards
for areas such as accounts receivables,
accounts payables, purchasing, sales
orders, invoices, shipping, etc.
•
Build 2 to 5 WebI reports for more
details and link them to the dashboards
so that navigation is easy for end users
23
Operational Dashboards
•
•
•
Dashboards can
be operational
This dashboard
focuses on
billing disputes
and is used to
monitor closing
of cases
The users of
this dashboard
are clerks in the
billing office,
not executives
Some dashboards are operational in nature and give a summary of the key metrics and new
cases as they occur. Such dashboards works best when data is refreshed often or real-time.24
The Dashboards User Acceptance Testing (UAT)
Form
Dashboard Name:
•
During each UAT test cycle,
you should solicit detailed
feedback on layout, graphs,
theme, tables, and
navigation
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
Graph colors
Ability to change
graph type
Ability to select
fields
Usefulness of fields
displayed
Drilldown to more
detail
On-line help
Navigation
•
Theme
Area
Print
Save
Single sign-on
Other
Comments:
Approvers Name:
Approvers Signature:
25
Dashboards on SAP HANA
26
SAP Lumira — Visualizations and Interactive Development
With SAP Lumira
you can create
graphs on-the-fly
and get
requirements while
building them
You can also create
many graphs and
put them together
on a report
This means that you can represent
the same data in many ways, and
do not need to force an agreement
on requirements from all users
27
SAP Lumira — Complex Visualizations and Requirements
Since Lumira is much
more interactive and
it is very simple to
change graphs, you
can build your
visualization together
with the users
They can then
provide you feedback
while you are
designing in a
collaborative manner
28
SAP Lumira — Getting Feedback
You can also share
your work products
with others and get
their feedback
You can even use the
SAP Lumira Cloud
solution to publish
your visualizations
and solicit feedback
29
Delivering Requirements with Design Studio
With Design
Studio you
can build
almost
anything the
user wants
This tools does not lend itself to interactive prototyping sessions like Lumira.
Instead, it gives you total flexibility to meet complex requirements.
30
Design Studio — Standard Templates, Look, and Feel
When building a set of dashboards in DesignStudio it is very important to first
agree on the standards, color palate, button locations, and standard graphs used
If you don’t standardize the look and feel before you start, there is a high probability that
each dashboard will function differently and users will get frustrated trying to use them
31
Design Studio — Using External Objects to Meet
Requirements
Sometimes the objects or maps you need are not available in Design Studio. You
can then incorporate these from other sources using HTML5.
In this Dashboard example, the map requirements were met by using an external set of
maps from a 3rd party vendor. Design Studio allows you to simply integrate this.
32
What We’ll Cover
•
•
•
•
•
•
Introduction
Dashboard approaches — Agile, JAD, and RAD
Getting the right requirements
Where to start?
A real-world example
Wrap-up
33
A Real-World Example
•
This project is for travel
expense analysis
•
The color codes
communicate changes,
year over year
•
Graphs can be
displayed in many ways
•
Navigation can
be done and can get
new query result sets
This dashboard is based only on BW query and BICS
connector; the cube is now in SAP HANA and the dashboard,
therefore, loads in less than 12 seconds
34
A Real-World Example (cont.)
• Dashboards
are
most useful when
compared to
something
• This
dashboard is
relative to a
budget
• Notice
that all
graphs can be
displayed in many
ways and that
color coding is
consistent across
the dashboards
Make sure layout, buttons, and
colors are consistently used
35
A Real-World Example (cont.)
• This
dashboard
groups six different
categories and
over 30 lines into
an easily readable
table using a few
lines and mostly
colors
• Too
many lines and
incorrect use of
“bold” makes
dashboards very
hard to read
Don’t cram too much into a single dashboard. Plan
on multiple dashboards for each business area.
36
A Real-World Example (cont.)
•
Changes over
time are typically
tracked in the
dashboards
•
Don’t just present
numbers, plan on
only showing
changes

I.e., in amounts
and percentages
In this dashboard, the graphs are sometimes hard to read, so filter selections
were added. Use these carefully, since they are slow and make Flash files large.
A better solution would be to use Design Studio to meet these requirements.
37
Go-Live Planning for the Dashboards 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.
38
What We’ll Cover
•
•
•
•
•
•
Introduction
Dashboard approaches — Agile, JAD, and RAD
Getting the right requirements
Where to start?
A real-world example
Wrap-up
39
Where to find more information
•
Creating Dashboards with SAP BusinessObjects - The Comprehensive Guide,
book by Ray Li and Evan DeLodder, SAP Press, ISBN 978-1-59229-410-7
•
Getting Started with SAP BusinessObjects Design Studio, book by Xavier
Hacking, Jeroen van der A, SAP Press, ISBN 978-1-59229-895-2
•
SAP Dashboard on SAP Community Network
 http://scn.sap.com/community/businessobjects-dashboards
•
SAP Lumira on SAP Community Network –
 http://scn.sap.com/community/lumira
•
SAP BusinessObjects DesignStudio on SAP Community Network –
 http://scn.sap.com/community/businessobjects-design-studio
40
7 Key Points to Take Home
•
•
•
•
•
•
•
Requirements gathering is interactive, and users are discovering
what they want – Show them many demos
Use a RAD, JAD, or XP approach for your dashboards
requirements gathering process and development
Have multiple meetings with the user groups to gather
requirements
Build interactive prototypes and expect requirements changes
Plan for a formal user acceptance testing of the dashboards
Have a roll-out plan and a long-term vision of how to get there
Spend serious time planning for support and on-going
enhancements of your dashboards, or they will become useless in
a very short time …
41
Your Turn!
How to contact me:
Dr. Bjarne Berg
[email protected]
Please remember to complete your session evaluation
42
Disclaimer
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or
an SAP affiliate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective
companies. Wellesley Information Services is neither owned nor controlled by SAP SE.
43