Overview of the development of dashboards SAP BI

In many ways, the whole field of delivery of the data via dashboards was first emphasized not by BI but by the use of SAP Strategic Enterprise Management (SAP SEM) and the Corporate Performance Management (CPM) component of that module. In BI we are really focused on getting the data from point A to point B as effectively and consistently as possible, then using the base reporting components to generate reports for display purposes. So the whole dashboard concept was the final reporting component developed. Sure, we have a great set of reporting tools and now with the acquisition of Business Objects that frontend is getting much more attention. But we primarily focused on actual reports either via the frontend of the BEx Analyzer (Excel based) or the BEx Web Analyzer (Web based). The idea of dashboard components really didn’t start to get true attention until the WAD started to be used more aggressively and in conjunction with the Visual Composer the ability to generate and develop more effective dashboards was available.

But in the SEM-CPM area we had both the Management Cockpit and the Balanced Scorecard. So in SEM we really were looking to develop the display toolset for these management tools. In this area SAP is working with the concepts of Norton and Kaplan in the Balanced Scorecard area and those of Patrick George in the Management Cockpit area.

Now we will not be looking at the Balanced Scorecard process since this is more of a complete management component and a large portion of the focus of the Balanced Scorecard is not truly dashboard activities but more management processes both vertically and horizontally throughout the company. Where we will find some ideas of what a true dashboard should look like is in the area of the Management Cockpit in SEM. This component really got into the whole concept of visualization and display processes that occurred during the presentation of information. Not sure if anyone remembers but the initial concept of the Management Cockpit (MC) was having all of this information displayed in a room—Management Cockpit Room— and everyone would come to that room and be immersed into the key performance indicators (KPIs) of the company and discuss topics around growth and profitability of the company. Well, the whole idea of having everyone in the same location at the appropriate time was a bit much and having a room dedicated to strictly dashboard metrics was not going to have a long life. So, after the first cycle of SEM-CPM at SAP the Management Cockpit room idea was dropped but not the actual dashboard process. If you remember, the MC consisted of Walls, Frames, and Views and in each case there was a consistency to the architecture.

You will see that several different attributes are required to build a strong dashboard and that being able to configure the end result in the system is only one of them. You will find that pulling together all the aspects of a good dashboard requires as much skill in the areas of business logic and understanding as it does in the actual use of the WAD or other system products to create the final dashboard. My motto is KISS—keep it short and simple. The idea of creating a fancy dashboard with all the bells and whistles included will only distract you from actually building a good, sound dashboard that delivers what the business user needs—fast, accurate, and consistent data displays. You also don’t have to reinvent the wheel and struggle from scratch with every dashboard. Use templates and other components that are already available and built, and don’t worry about reusing a specific set of colors in the same dashboard; if you need to, go for it. Again, presenting everything in the dashboard in bright colors and different colors only distracts the business user and makes it harder for them to identify the important information. The fewer items that they have to digest and the more time they can take reviewing and investigating the data, the more productive they will be—and the less maintenance you will have for both the dashboard itself and the data. A dashboard with only one chart type often is more effective than a dashboard, that has everything under the sun on it—tachometers, split pie charts, dynamic meters, and cockpit-style formats with all the KPIs as indicators that you might see in a vehicle or airplane. Keep your focus on the goal and your dashboard will develop at the appropriate level for the business user needs.

In the latter part we will focus on building a couple of dashboards to show examples of the concepts that we discuss but having developed several of them will give you an idea of what can be achieved using the WAD and all of the functions available in this toolset. We will focus on a couple—one in the sales area and another in an industry specific area. The reason for this is that once you decide on a particular toolset to build your dashboards, which could turn out to be something other than BI, I would hope that you can use some of the information obtained here to develop your dashboards using the other reporting tools. I’m talking as though there isn’t another dashboard component in the reporting toolset with SAP but I’m sure that many of you have read about and probably are using, to some extent, the dashboarding component delivered by BOBJ. That reporting component would be the BOBJ Xcelsius. In either case, there are some similar features between the WAD and Xcelsius but once you decide to use either BOBJ or BI you’ll start to focus solely on what you can accomplish with the chosen reporting software.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

SAP BI Topics