BI2013 – SAP BusinessObjects Dashboards Best Practices: Top 20 Factors That Affect Your Dashboard Usability, Integration, and Performance by Bjarne Berg
In this 2 part session Bjarne Berg let us look at how you can make your dashboard a success In the organization. This blog describes the points he addressed in the first part of the session. At the end I shortly address the points he made in the second part that had performance as the main theme.
In the first session we looked at the branding, the layout and dashboard layout, how to get the right requirements and use Rapid Application Development and looked at the items that are best to deploy on mobile platform.
Finally we looked at many examples of dashboards that have been designed with the points above in mind.
Before we got started Bjarne Berg showed the setup he is using to show us the live demo. A HANA server in Germany holding 480 mln rows of sales data was connected to a BOBJ server in his office in the U.S.A. and he connected to the BOBJ server from Amsterdam with WIFI. And he showed us that he can start 6 complex dashboards at the same time and have them ready in 11 seconds.
The session was all about SAP Dashboard, not Design Studio.
De difference between the two is that SAP Dashboard is for business driven or self service dashboards and Design Studio for professionally build or IT-built dashboards.
First we looked at the design for dashboards.
- Split dashboards into logical units. This means that each query will deliver a small resultset which will increase performance
- Avoid to build one dashboard to rule them all. You need more dashboards per area. For more details build WEBI reports. Provide a link in the dashboard to the webi report for easy access. The WEBI reports can be prerun at night so that they perform when users open them.
- Dashboards don’t have to be highly interactive. There are also use cases for highly formatted low interactive dashboards such as financial reports.
- Dashboards for senior management should be very graphical, navigation should be simple. Especially here what-if scenario’s are crucial.
- Some Dashboards are operational. A Dashboard shows the key metrics and new cases as they come in. for this the dashboard needs to be refreshed often or better be in realtime.
- Dashboards are the most meaningful when you compare things. A typical comparison is actual vs budget. Colorcoding the result of the comparison makes the dashboard more readable. Use monochromatic colors.
After these design tips we looked at the development methodologies. The typical waterfall type method does not fit well with building dashboards. A method like this is difficult when you have to deal with substantial functional changes in development what is typical for dashboard design.
Use a method like RAD of agile wher e you either start out with a whiteboard mockup or if you have them a set of high quality dashboards. Based on the feedback you make a new mockup. The users will look at it again and based on their comments new enhancements will be made. When the dashboard is a good enough fit to the user the next stage is to enhance performance in front- and backend.
Finally the unit, system and integration test before go-live.
As also discussed in the mobile session you can set a filter in the component panel to only show the components that are usable in mobile. There is also a “mobile compatibility tab” where you can see if an already existing dashboard will need changing before you put it in mobile.
It is important to use the right fonts for mobile. Use the ones that have (IOS 5+) added. This way the grapsh do not look bad when using gestures in the iPad.
In the deployment planning do communicate clearly that you expect to deliver a second version of the dashboard. After using the initial dashboard users will want a lot of new features. This is a sign of success. But if senior management expected that everything was done after the first dashboard they will have a bad impression of the project. A strategic dashboard plan should map out the vision over the next 2-3 years.
Create a dashboard deployment program. This provides a view over who has access to which dashboard. It is not a security role design, but chances are it will become one on a later time. Also a Dashboard owner diagram is needed. This is where you assign the right to grant access to the dashboards.
Finally there is a business readiness checklist shown in the presentation. Use a checklist like that to ensure all the important points are checked. Many projects fail because one of these points was forgotten and came back to bite the project.
In the second part Bjarne Berg looked at factors that affect usability, integration and performance. The first thing he let us see is that performance wins over functionality. As an example he showed us the google layout vs the yahoo layout. The first only a white page, the latter full of buttons and pictures. And we know who won.
In the session we looked at the components that hit the resources hard, how to size the requirements for your hardware. There are calculators that help you set the requirements.
Then we looked at HANA. Bjarne Berg states that basically hard disks and relational databases for reporting become obsolete. In a couple of years everybody will run their BI in memory. Finally there were a couple of BEx query tips and tricks to increase performance
With the 2 sessions we got a comprehensive view of dashboards. We went from strategic planning via design rules to the technical basis setup on how to let your dashboards perform. Very much information in one afternoon!