Singapore – Oct 2014
Produced by Wellesley Information Services,
LLC, publisher of SAPinsider. © 2014 Wellesley
Information Services. All rights reserved.

•
•
•
•
•
•
Introduction
Dashboard approaches — Agile, JAD, and RAD
Getting the right requirements
Where to start?
A real-world example
Wrap-up
1

•
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

•
•
•
•
•
•
Introduction
Dashboard approaches — Agile, JAD, and RAD
Getting the right requirements
Where to start?
A real-world example
Wrap-up
3

•
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

•
•
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
Formal communication
Prototypes and reviews
Final approvals
A dashboard implementation does not simply involve a series of black-and-white technical decisions; just because something is technically feasible does not mean it is wise or desirable from a business perspective
Source: Gooy_GUI, 2007
5

•
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 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
• Workshop Agenda
•
Questionnaires
• End-User Procedures
• Test Plans
•
Technical Procedures
• Made Easy guidebooks (printout, data transfer, system administration…)
Fill in the Blank
Versus
Start from Scratch
Source: SAP
The challenge with ASAP is that users don’t know what they want until they see it …
7

Integration
Testing
Create Functional specs
No
Complete?
Yes
Create Technical specs
No
Complete?
Yes
System Testing
Unit Testing
Peer Review
No
Yes
Approved?
Peer Review
Complete?
Yes
No
Structured walkthrough
No
Complete?
Yes
No
Configuration
Yes
Approved?
Structured walkthrough
8

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

•

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

•
•
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

High
When to Select Different Methodologies
Joint Application Design
(JAD)
System development Life-Cycle based methodologies
(SDLC)
Time to
Delivery
Extreme Programming
(EP)
Rapid Application Development
(RAD)
Low
Low
I.e. Scrum and Agile Impact of Failure
High
12

•
•
•
•
•
•
Introduction
Dashboard approaches — Agile, JAD, and RAD
Getting the right requirements
Where to start?
A real-world example
Wrap-up
13

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

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

•
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

•
•
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

•
•
•
•
•
•
Introduction
Dashboard approaches — Agile, JAD, and RAD
Getting the right requirements
Where to start?
A real-world example
Wrap-up
18

•
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

•
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

•
•
•
•
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

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

•
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

•
•
•
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

•
•
Dashboard Name:
Area Approved
Change
Wanted
Background color &
By requiring each of the five
Image
Button layout & locations
Link names & to seven UAT members to complete a form for each dashboard, you get solid feedback that you can use in the next RAD locations
Chart and Table names & location
Table location
Table and font size
Colum order
Sort ability
Summary row layout & colors
Graph type
Graph location development cycle
Graph labels & size
Graph colors
During each UAT test cycle, you should solicit detailed feedback on layout, graphs, theme, tables, and navigation
Comments:
Ability to change graph type
Ability to select fields
Usefulness of fields displayed
Drilldown to more detail
On-line help
Print
Save
Single sign-on
Other
Approvers Name:
Approvers Signature:
Description
25 25

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

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

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

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

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

•
•
•
•
•
•
Introduction
Dashboard approaches — Agile, JAD, and RAD
Getting the right requirements
Where to start?
A real-world example
Wrap-up
33

•
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

•
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

•
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

•
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

•
•






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

•
•
•
•
•
•
Introduction
Dashboard approaches — Agile, JAD, and RAD
Getting the right requirements
Where to start?
A real-world example
Wrap-up
39

•
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

•
•
•
•
•
•
•
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

Please remember to complete your session evaluation
42

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