Presentation on theme: "What We’ll Cover Introduction"— Presentation transcript:
0 Field-Tested Techniques for Gathering and Interpreting Dashboard Requirements Singapore – Oct 2014 Dr. Bjarne BergCOMERIT
1 What We’ll Cover Introduction Dashboard approaches — Agile, JAD, and RADGetting the right requirementsWhere to start?A real-world exampleWrap-upLet’s begin with features of Query Designer
2 In This SessionGet best practice rules for conducting dashboard scoping sessions to effectively gather requirements from all stakeholdersLearn 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 LumiraWhat is covered in this session?Advanced tips and trick in Query designer and BEx AnalyzerThe advanced tips and tricks are explained using business scenariosOverlooked and obscure features are brought to limelightLots of demos to explain BExGetData and other topics
3 What We’ll Cover Introduction Dashboard approaches — Agile, JAD, and RADGetting the right requirementsWhere to start?A real-world exampleWrap-upLet’s begin with features of Query Designer
4 Who Gets to Do What?The major decision for an SAP BI-driven enterprise is to determine who gets access to each toolThere is often a temptation for the IT community of wanting to keep the tools under their domain – That is a mistakeThe IT community should actively work with the power and casual users to improve human capabilities and thereby teach them to become more productive employees
5 The Dashboards Business Requirements Business requirements can be collected in a variety of ways based on the methodology that the company employsIt is a complex process and involves the following periods:Discovery and educationFormal communicationPrototypes and reviewsFinal approvalsA 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 perspectiveSource: Gooy_GUI, 2007
6 The JAD, RAD, Agile (XP), or ASAP Methodologies There are several options for the SAP BusinessObjects Dashboards projectJoint 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 effortPick your SAP BusinessObjects Dashboards methodology carefully. Do not use ASAP unless your project is part of a budgeting, consolidation, or planning effort.
7 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 developmentIt is hard to fix missing functionality during integration testingThe waterfallSource: SAPThe challenge with ASAP is that users don’t know what they want until they see it …
9 Joint Application Design (JAD) — Who Participates? Facilitator — Facilitates discussions, enforces rulesEnd Users — Three to five, attend all sessionsDevelopers — Two or three, question for clarityTie Breaker — Senior manager; breaks end-user ties, doesn’t attendObservers — Two or three, do not speakSMEs — A few subject matter experts (SMEs) for understanding business and technologyKeep 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 )
10 Rapid Application Development (RAD) RAD has an abbreviated blueprinting phase where meetings are executed in short succession to get the requirementsMost of the blueprinting and realization phases of the project are combinedThe first meeting: A one or two-day work session with uninterrupted timeWho: Power users, casual users, people who today interact with the current system, and managers who have a stake in the outcome of the dashboardsHow many: A rapid pace is kept in these meetings and the number of attendees is kept to no more than seven people in attendanceThe 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
11 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 knewThe argument for XP is that other methodologies were developed to build software for low levels of change and reasonably predictable outcomesBut the business world is no longer very predictable, and software requirements change at extremely high ratesDevelopment can be completed faster with collaborative efforts of paired programmers with small “sprint” timelines and many go-livesThe core premise of Agile is that you can only pick three out of these four dimensions: cost, quality, scope, and time
12 Framework for Picking a Dashboard Methodology I.e. Scrum and Agile
13 What We’ll Cover Introduction Dashboard approaches — Agile, JAD, and RADGetting the right requirementsWhere to start?A real-world exampleWrap-upLet’s begin with features of Query Designer
14 Where Do You Start? — First Alternative You can start with a blank template and fill in the capabilitiesFocus on graphs, layout, measures, and navigationOne method is to write storyboards from a user perspective and add needed functionality to support this
15 Where Do You Start? — Second Alternative — Step 1 Get a group of 5-7 people for a brainstorming sessionDraw the solution, knowing that it may look somewhat different once developedFocus on the use of space, graphs, navigation, available data, and the purpose of the dashboardsDo not design fixed-format “reports”
16 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
17 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 DashboardsFocus on layout, space management, colors, and basic formattingPlan for multiple weekly prototypes before you get the solution that everyone can agree on
18 What We’ll Cover Introduction Dashboard approaches — Agile, JAD, and RADGetting the right requirementsWhere to start?A real-world exampleWrap-upLet’s begin with features of Query Designer
19 Flexible Options to Meet Many Requirements There are often disagreements on how to present numbers and graphsMake your dashboard flexible and present data in many interactive waysAmount vs. PercentagesDifferent graphsUsers can select what they want graphed
20 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
21 Senior Management — Graphical Dashboards Dashboards for the senior management should be very graphically orientedConsider using logos and images instead of text for this purposeNavigation should be very simpleFor senior managers, the ability to interact with the data (what-if), and see performance numbers relative to plan, budgets, and prior years are critical functionalities21
22 Divide and Get Performance Link to Details WebI reportsDrill-down optionsSplit your dashboards into logical units. This keeps the result set for each query small and also decreases the load time for each dashboard.
23 Build Several Dashboards for Each Functional Area Avoid trying to create a single dashboard for each functional areaYou 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 users23
24 Operational Dashboards Dashboards can be operationalThis dashboard focuses on billing disputes and is used to monitor closing of casesThe users of this dashboard are clerks in the billing office, not executivesSome 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.
25 The Dashboards User Acceptance Testing (UAT) Form 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 cycleDuring each UAT test cycle, you should solicit detailed feedback on layout, graphs, theme, tables, and navigation
26 Dashboards on SAP HANALet’s begin with features of Query Designer
27 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 reportThis means that you can represent the same data in many ways, and do not need to force an agreement on requirements from all users
28 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
29 SAP Lumira — Getting Feedback You can also share your work products with others and get their feedbackYou can even use the SAP Lumira Cloud solution to publish your visualizations and solicit feedback
30 Delivering Requirements with Design Studio With Design Studio you can build almost anything the user wantsThis tools does not lend itself to interactive prototyping sessions like Lumira. Instead, it gives you total flexibility to meet complex requirements.
31 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 usedIf 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
32 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.
33 What We’ll Cover Introduction Dashboard approaches — Agile, JAD, and RADGetting the right requirementsWhere to start?A real-world exampleWrap-upLet’s begin with features of Query Designer
34 A Real-World Example This project is for travel expense analysis The color codes communicate changes, year over yearGraphs can be displayed in many waysNavigation can be done and can get new query result setsThis 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
35 A Real-World Example (cont.) Dashboards are most useful when compared to somethingThis dashboard is relative to a budgetNotice that all graphs can be displayed in many ways and that color coding is consistent across the dashboardsMake sure layout, buttons, and colors are consistently used
36 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 colorsToo many lines and incorrect use of “bold” makes dashboards very hard to readDon’t cram too much into a single dashboard. Plan on multiple dashboards for each business area.
37 A Real-World Example (cont.) Changes over time are typically tracked in the dashboardsDon’t just present numbers, plan on only showing changesI.e., in amountsand percentagesIn 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.
38 Go-Live Planning for the Dashboards Initiative During the planning phase, you should also start planning your go-live strategyThis 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.
39 What We’ll Cover Introduction Dashboard approaches — Agile, JAD, and RADGetting the right requirementsWhere to start?A real-world exampleWrap-upLet’s begin with features of Query Designer
40 Where to find more information Creating Dashboards with SAP BusinessObjects - The Comprehensive Guide, book by Ray Li and Evan DeLodder, SAP Press, ISBNGetting Started with SAP BusinessObjects Design Studio, book by Xavier Hacking, Jeroen van der A, SAP Press, ISBNSAP Dashboard on SAP Community NetworkSAP Lumira on SAP Community Network –SAP BusinessObjects DesignStudio on SAP Community Network –
41 7 Key Points to Take HomeRequirements gathering is interactive, and users are discovering what they want – Show them many demosUse a RAD, JAD, or XP approach for your dashboards requirements gathering process and developmentHave multiple meetings with the user groups to gather requirementsBuild interactive prototypes and expect requirements changesPlan for a formal user acceptance testing of the dashboardsHave a roll-out plan and a long-term vision of how to get thereSpend serious time planning for support and on-going enhancements of your dashboards, or they will become useless in a very short time …
42 Please remember to complete your session evaluation Your Turn!How to contact me:Dr. Bjarne BergPlease remember to complete your session evaluation
43 DisclaimerSAP 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.
Your consent to our cookies if you continue to use this website.