Process of developing a dynamic dashboard SAP BI

There are several specific task activities that are required for building a dashboard. We find that they are all important but one seems to always get short changed by timelines or milestones and then you’re looking at an uphill battle with developing dashboards that will actually work for your business user. The one I’m talking about is requirements gathering. Of the different tasks needed to accomplish the development including the actual configuration and reporting strategy development, the requirements gathering is, I believe, the most important but the one that gets reduced or cut depending on the milestones and Go Live timeframe. I’ve seen companies where the development of report specs have been delayed so long that you don’t have any time to think about what the business user wants and needs, only the time to get the current task completed based on what has been given to you as basic requirements. Don’t take for granted that the business user will give you everything that is required. They are not as expert as you are at knowing what the system can and can’t do, so you need to question and enhance the business requirements so that the functional specifications can be valid. You need to take the appropriate time to develop the report specs required and work with the business users on the format and functionality required from the dashboard. You can also make suggestions on the dashboard format and this is where, I think, most dashboards go down the drain. We don’t usually ask and push back on anything that the business user might want, even if the idea of a specific KPI in a dashboard might not be the appropriate location for it. There are a number of thoughts around the level of KPIs.

You also need to make sure you focus on the actual requirements of the dashboard and the business needs, not on what the system is capable of doing or what unusual dashboard designs you can come up with. Potentially, you could develop and distribute to your business users something straight out of Star Wars, but if you don’t deliver the information in the form required, your customers will not be happy. They might find all the interactive features (such as sliding bars and so forth) amusing at first, but that will quickly change if you failed to understand what their requirements are and how to present them. The rule of thumb is that if an item doesn’t add value to the dashboard, you shouldn’t add it. Over 75 percent of all charts found on a dashboard are column, bar, pie, and line charts, and these are supported by all major software systems. Don’t add new functionality, such as an unusual chart type, simply because you want to see how it works. If you encounter something unusual about the business requirements, question the business users and you will probably find that you can fine-tune the specifics such that those requirements can be handled by a standard chart type. Don’t worry about the system not being able to support the dashboard; unless someone specifically asks for a dashboard that looks like the interior of an aircraft cockpit, you should be in pretty good shape.

As a final comment around the development of dashboards as we mentioned we want to make sure we listen to the users whether they are the C-level management, operational level, or analysts from the business. What we don’t want to do is develop dashboards that require a doctorate degree to understand and explain. I know we’ve all run into these types of dashboards that look great at first glance but the initial discussion around what each metric means and how to interpret them is painful and requires you to take notes for review so that you can read the statistical information.

NOTE: “C-level management” refers to corporate positions whose titles begin with “Chief”—CEO, CIO, COO, CFO, and so forth.

We need to realize that the normal amount of time that each of these different levels ofpeople have during the day to review and assimilate the information from these dashboardsis anywhere from about two to three minutes for a C-level professional to about five toeight minutes for an operational management person and the difference has nothing to dowith any sort of difference in knowledge base. It has to do with the types of data. The C level, they are looking to get the information that they need and then go manage and growthe business. They don’t get the big bucks for sitting and taking hours out of their day tounderstand the metrics of their business. Their responsibilities are to run the business so the two to three minutes is all they can afford or their time is not being spent wisely. As for the operational management this person is going to have a more detailed dashboard with morespecific information around the execution of their business processes and therefore willrequire more time to understand and probably start to dig deeper into the details andstatistics behind the information. This could also link to having additional drilldown reportsavailable linked to this dashboard or possibly drill-through reports that could be used. So,let’s not take our time and develop a dashboard that makes you feel as though you’re sittingfor the SATs each time you go to read it.

1.Required Details of the KPIs
When it comes to actually developing KPIs, we need to approach this from several angles. But the first item of business is to define what a KPI is for your business users.

key performance indicate as a measure of performance.Such as.measures are commonly used to help an organization define and evaluate how successful it is, typically in terms of making progress towards its long-term organizational goals. KPIs can be specified by answering the question, “What is really important to different stakeholders?” KPIs may be monitored using Business Intelligence techniques to assess the present state of the business and to assist in prescribing a course of action. The act of monitoring KPIs in real-time is known as business activity monitoring (BAM). KPIs are frequently used to “value” difficult to measure activities such as the benefits of leadership development, engagement, service, and satisfaction. KPIs are typically tied to an organization’s strategy using concepts or techniques such as the Balanced Scorecard.

Well, that just about sums it up, right? We could, and people do, sit and battle over what a KPI is for hours on end. I’ve tried many times to get agreements around what KPIs are for a specific company with varying success. Have you ever tried to meet with your divisional managers and once you have them all in a room try to get a standard set of KPIs from them and then get some sort of agreement on what they are? You would spend your entire professional career trying to do something like that. Sure, each division may be selling some unique product line or have some exceptions to the rule in terms of KPI information but within a company there has to be some set of performance indicators that can be quantified so that we can take those and start to drive the business as a whole; then once those KPIs are defined, using the exceptions to the rule for each division to help drive, at a more granular level, the additional products or services that are key to that line of business. It gets even more difficult if the KPIs are linked to monetary gains and everyone has to agree not only on the KPI itself but on the calculations that are taken into account for the value of that KPI. Quite the show when it comes to that aspect of the KPI connection but this starts us into a discussion that is more associated to a Balanced Scorecard rather than a dashboard. So the dashboard is more of a display of information that has happened and hopefully helps us forecast what might happen in the future versus the basic idea of a Balance Scorecard where it is a management toolset that links everyone throughout the company against KPIs.

KPIs differ depending on the nature of the organization, the organization’s strategy and the development level of the organization we are generating the dashboards for. They help to evaluate the progress of an organization toward its vision and long-term goals, especially toward difficult to quantify, knowledge-based goals. So, we need to get these defined and the critical document for this is the report requirements or functional requirements that should be developed initially by the business users. Don’t let them off the hook by trying to help the process along; you will find yourself creating these documents with little or no help from the business. This is a self-defeating scenario. There is little chance that whatever you develop will be approved by the business user unless you’re the business user also. It would be better for you that they reject the functional requirements immediately so that you don’t waste your time developing some set of KPIs that are not agreed upon by the business and once you get the entire dashboard completed they realize that it’s not giving them any indicators that are going to be helpful in their position. Definitely, get the business users involved by offering examples of the final result. Demonstrating the use of a dashboard and driving the need for this component to help your company survive will improve the results that you get from the business requirements document. If all else fails in getting the business requirements directly from the business user, then getting consensus sign off on the KPIs you’ve developed is a must. Do this either from the actual business user point of view or from the management level so that someone from the business has approved the use of these metrics before starting the process of configuration. I know the idea of getting consensus around metrics for one business user group from the management level just above seems a bit harsh but it’s much better than having to reengineer everything that you’ve spent months on after you’re done.

Requirements gathering doesn’t end with KPIs. In my experience implementing BW/BI or SEM-CPM, I have seen very few companies work through the requirements gathering to the extent needed to develop a set of good requirements for the development of the dashboards. Typically, everyone does a great job up to the point of establishing the appropriate KPIs, but after that the requirements gathering stops. This is actually just the start of the process. After this level of information analysis, we have the whole area of architecture and display to follow through and understand. Developing a display component before you get more information about the KPIs is premature. You need to ask questions about positioning, priorities, and formatting. For example, the color schemes will be approved by the corporate marketing department, so that’s not a big issue, but you need to understand if other colors within the dashboard should be softer or bolded. Following are the types of questions you need to pursue after you establish the KPIs.For example:

  • Out of your list of metrics, what are the primary KPIs that the business can’t do without?
  • If you could have only one KPI, what would it be?
  • What formats would work best for you (column charts, line charts, pie charts, bar charts, etc.)?
  • What experience do you have with analysis using a scattergram, radar chart, and so forth?
  • If the answer to this question is that they’ve never used them, this gives you a good idea of what types of charts will work for your audience. Avoid using types of charts that are familiar to you or that look good to you but are probably not the ones that would make sense immediately to your business users.

  • If you were looking at a display of information, where would you want your critical KPI to be located (top, bottom, left, or right)?
  • If a list of values is being used for filters, what format would work best for you (radio buttons, dropdown list, check box, etc.)?
  • Would you prefer to type in a specific value of a characteristic, such as “Region,” or choose it from a list?
  • How comfortable are you with analysis of two or three metrics on one chart, each with its own scaling?
  • This means your chart would have different scaling factors running up the primary and secondary axes. Is that something that will be easy for the business user to think through or will it cause confusion? The concern is whether the metric would be too unusual and possibly be misread, potentially causing errors in decision making.

  • If within your requirements you need additional drill-through reports, is this something that should be available via a context menu or a hyperlink directly on the dashboard screen?

I know some of these requirements sound like overkill but when we are developing a dashboard we are well past the fact that we are getting the appropriate data and information. This is all about displaying the data correctly, accommodating the business user with information, and reducing the total time that they spend on getting to the data and rather increasing the time they spend on analysis of the data. At this point take the time to diagram out an overview of what the dashboard will look like and socialize this throughout the business user community. This additional effort will make the sign off of the final product easier and more successful.

What Are the KPIs?
We talk about these things called KPIs quite a bit. Seems that everyone has some KPIs that they have to manage and need to understand the process of managing them during the business process. Again, on this topic there are is a ton of additional information and material that is available so I’ll keep my discussion just to the comments that make sense to our topic here rather than going into too much conceptual information. There are a number of situations where the whole idea of KPIs needs to be revisited and reworded. May be we can call it something else so that we get a clear picture of what these indicators really are. I’ve reviewed some of my projects and identified some of the critical areas where we will have to focus during the process of developing the correct KPIs. One of my cardinal rules is that we try desperately to avoid having too many KPIs. I can’t tell you the number of times where I’ve seen a dashboard overloaded with KPIs and you’re constantly trying to manage one or the other of these different indicators. We all know that there are critical indicators that will make or break our businesses and we just have to find the right ones and make sense of them.

During a project with a vehicle manufacturing company, we were reviewing these different groups of indicators and found that the inclination was to look at all of the business outcome indicators rather than looking at the source indicators. After review, we found that one of the critical Key Performance Indicators is customer satisfaction. During our analysis we found a direct correlation between the customer satisfaction level and the sales of their vehicles in the next 4–6 month time frame. This was a great find since everything was driven (not a pun) by this analysis—sales, cost of goods sold, inventory levels, labor costs—and this impacted many other areas outside of just the revenue streams. With this additional KPI in their dashboards we were able to really get some good information to them that would proactively impact their bottom line rather than trying to influence the actual sales numbers other ways such as discounts, promotions, etc.

During these fact-finding workshops, you have to realize that you can only manage a specific number of KPIs. No one can manage 50 KPIs or even 30 KPIs, and even 20 would be a big challenge. You need to be aware of the total number of KPIs and make sure that there aren’t so many that they work against each other in the process. For example, if you were increasing the emphasis of the overall worker productivity KPI, you might lower your rating on the KPI regarding employee satisfaction of their work environment. Having indicators that work against each other is a no-win situation. Normally within the company, these KPIs are tied to moves in positions, salaries, and bonuses, so the ability to identify just the correct few KPIs will be a very challenging process.

After you’ve narrowed down the list of KPIs to about 15 or so we can organize them into groups and headings. There are a number of groups that can be identified within KPIs. One area would be in terms of the role that you are responsible for and the KPIs applying to that role. If you are involved with management of a specific department, the KPIs need to be directed to just those activities and not be so wide-ranging that they encompass other areas that you don’t have full control of during the Management by Objective (MBO) process. If my MBO and bonus depends on the Net Profit Margin, then I need to be able to affect the total sales and the costs involved. If I’m only responsible for Total Sales and I’m a sales person, then this is a fair KPI to be looking at during the year and to be gauged against.

Another area that we need to be aware of is the actual data that is being used in the calculation of the KPI. We need to try and make the indicator as transparent as possible so that we can make sure the business user has the ability to manage to that specific indicator. For example, if we use an MBO of sales, we want to make sure that it’s consistent with the person’s responsibilities. If we use a sales number that is calculated with adjustments made for all sales except for sales of specific products or promotional activities, we start to muddy the waters and now the Account Executives are trying to understand the details of the MBOs rather than doing their job, which is selling.

Several other aspects of KPIs are more obvious with regard to the development and validation. One is the fact that we have distinct types of indicators that separate measures into operational and strategic KPIs. I’m comfortable with the fact that we can focus our attention on the nature of the indicator and make sure we are not asking someone to achieve a strategic goal when all they can really do is influence an operational measure. Therefore, during the process of identifying KPIs and assigning them to individuals, we need to ask ourselves if these are KPIs that will affect the day-to-day activities of the person or are they KPIs that will affect the goals of the company. We see these two different groups of KPIs all of the time and should be very familiar with the differences.

Another aspect of KPIs is the data frequency involved. The individuals being managed by these KPIs should know the length of time they have to influence the direction and outcome of their personal MBOs. Time periods typically are defined directly in the dashboard as quarterly, daily, or yearly information.

Finally, we have some enhanced items that we see in the dashboards that I would like to point out. Sometimes, as I have mentioned, we get too caught up with all of the bells and whistles and the final result of the dashboard is something like a what-if scenario rather than an indicator or dashboard display. We need to make sure that we clearly separate the ability to create a set of KPIs from doing what-if analysis on the indicators versus a display of a KPI. It’s all great to be able to shift percentages and values around to see what might be an outcome but to spend too much time over-analyzing the possible outcomes is not the best use of a business analyst’s time. Rather than having them analyzing the actual information, we find some dashboards offering too many options to make comparisons that are meaningless in the scheme of things. Work the KPIs around doable measures and benchmarks and we will not have all of the what-if analysis going on. The what-if will be relegated to forecasting and planning rather than comparison of what was actually posted versus some random changes in levels.

You also need to be very aware of what types of information you deliver to the different groups. Most people immediately want to see the day-to-day information to do analyses. That is fine if they are doing operational KPIs, but strategic KPIs require more static, longer term information. Business users who are responsible for driving the long-term growth of the company need monthly, quarterly, and yearly numbers, not daily information. You want to offer them a larger window to the data so that they can analyze trends and patterns without the distraction of new information arriving every 24 hours.

There are many more aspects of KPIs that we could delve into and analyze, but these are some of the issues that I’ve run into during my projects and workshops to gather KPI information.

2.Tips on Visualization of Dynamic Dashboards
In this section we will work through some ideas on the visualization that goes on with regard to dashboards. Now, I’m not going to say that I’m an expert in this area and there are definitely concepts that I will refer to that have some other more technical terminology and approaches but from my experience these are areas that we don’t seem to work hard enough at to get right and be able to put yourself in the position of the business user and what they are actually looking at. From my perspective we need to get some external comments about the dashboards that we are building. This can definitely improve our approach to the final display of KPIs to the business. I’m also sure that there are other topics or areas where you might have run into issues and have come up with your list of to-do’s when it comes to building the Web templates. Think about including some of the ideas about visualization offered in this section into your current list and keep them in mind as you go through your process. Also, these are not in any order of priority since I believe there is no dependency from one to another. They are separate issues that will come up as you go through your development. Just remember one thing as you work through this. We are trying to get our point across as quickly and as directly as possible and that is the real challenge. This is definitely one of my challenges. There are many times where I’m sure a particular topic could be addressed in a much more effective manner and after about two hours of conversation I’m still not getting to the point. Many of us have this issue and since we communicate and develop our ideas that way, we look at these dashboards the same way. They are just another way to talk to a topic for hours and hours and then finally get to the point. If we can narrow down the conversation and get to the point our skill sets in the area of dashboard development would increase at the same rate. So, rather than continuing to talk about these topics (following my own lead), let’s get started.

Optimum Level of Information
One of the most common mistakes in dashboard development is to attempt to squeeze as much into the screen as possible. If we try to fit too much into one screen, it ceases to be adashboard and becomes a visual bulletin board. If this is the result then what you have issomeone that has to understand the navigational approach to reading the dashboard ratherthan analyzing the dashboard. So what we start to see is someone trying to expand thedashboard the correct way to see what they need and then start to focus on this specific issue such as looking at bullets, detailed data, and anything else we’ve decided to add toour dashboard over time rather than the true needs for our MBOs. The following illustrationis an example of this effect. The actual metrics and the approach to displaying those metricsare good, but the developer started to add in hyperlinks at the bottom of the page, a To Dolist or Action List, additional scroll bars since we couldn’t get everything on the one screen,adding additional colors to highlight whatever is critical since everything is starting to getso tight that we really can’t distinguish what is a KPI versus what is just information. At some point during the development we lost track of what the actual KPIs are that weinitially used the dashboard to understand.

Optimum Level of Information

The following illustration shows another example of this issue. This dashboard tarted to get out of hand as soon as they started to add colors—and lots of them—to this display. Then, with way too much already going on in this dashboard, they tried to push more into the screen by adding the fancy buttons to the left side.

Optimum Level of Information

Five different chart types are included in the Web screens at the top of the dashboard. Assuming that the developer is able to get all of them to work appropriately, we encounter issues with spacing. The descriptions are not clear enough for us to understand what all the colors mean, and because there’s not enough space, the titles have been reduced to being so small that we would have to have worked with this information over time to understand what each indicator is trying to tell us. Remember, you have a total of three to four minutes of the CEO’s time to deliver the information needed to make decisions, so make the most of that time. This dashboard is too overloaded—too much information all at once, too detailed, and no central focus to the primary KPI that the developer is trying to communicate to the business user.

Information Blocked from the Initial View
In the following example, the developer has decided to use a 3D chart. Without a doubt, the chart looks very interesting, but due to the depth that the 3D adds to the chart, some information is blocked from view. In the very back of the 3D chart, you can’t see the last column, so you really don’t know whether that information is flat or has some activity that you just can’t see. This situation could get worse as these columns move higher and start to block the middle of the screen. Other than that issue, I think that this chart would, with a little bit more work, actually drive the information home and give a very good focus to the KPIs, but we would have to adjust the format a bit to unblock the data, then add some titles and information to give this more structure.

Information Blocked from the Initial View

Using the Appropriate Chart Type
In the next example, we see that the dashboard developer tried to get a bit creative by using some of the normally unused chart types. Again, can you identify what this dashboard is trying to show you within 15 seconds of reviewing the information? I’m all for using the correct chart type in your dashboards, but trying to add the radar chart type (lower-right corner) to a dashboard where it doesn’t add any value is wasting space where you could add some additional metric that would make use of the space appropriately. If you were to look at just that portion of the chart, you probably wouldn’t understand the result of the information quickly. You could figure it out eventually, but it would take too long, especially if you have a tight window of time for analysis such as in the case of a C-level management user.

Using the Appropriate Chart Type

The pie chart to the left of the radar chart in the previous dashboard works just fine and is a perfect example of using the appropriate chart type to drive home your information and results to the business analyst. Another issue in this dashboard is to the top right in terms of the two line chart types. What is the actual KPI? Is it the actual versus budget gross margin profit or is it the variance? I like the fact that both are shown here, since we can get a look at the information used to create the variance, but whichever is the primary KPI should really be in a bolder color scheme and highlighted. It would seem, based on the positioning, that the basic information—Actual and Budget—represents the primary metrics and therefore should have the most room, but without some additional focus point, we can’t really be sure. The top left of the dashboard includes another chart that is outlining yearly the Actual and Budget values. This one isn’t immediately obvious but you figure it out pretty quickly. As you can see, the Actual total is the complete chart area and the Budget is embedded into that area with a darker color. My question is whether the scheme would be reversed if the Actual value was less than the Budget. That is, would the whole area be the Budget and the Actual be just a darker area? If that is the case, then this chart would start to get confusing because each month it could change format on the viewer.

As you can see as we go through these examples, one dashboard can have multiple issues that are not working correctly for the business analyst. As long as you’re aware of these pitfalls in creating dashboards, you can understand where you might be challenged on your architecture and possibly why the business users are having difficulty working with the dashboards. I have seen companies invest tons of money into a dashboard approach to management and wind up having only 50 percent of their employees use it. The other 50 percent continue to download the information into Excel and create their own charts for analysis purposes. The goal of the dashboard approach is to eliminate this practice so that the analysts can focus on doing their jobs, which is to analyze the data, instead of gathering and formatting the data. As you’ve noticed, in this section I’ve been italicizing certain phrases or words to emphasize a point and catch your attention. This is exactly what you want to do with the dashboard. You want to focus the user’s eyes on a certain portion of the information first, and then have them review the other KPIs. To do this, use some sort of change in the font or color scheme to highlight some specific portion of the dashboard.

Using Space Appropriately: One Screen vs. Multiple
One of my pet issues is the idea that we have agreed with the business and have too many KPIs without any push back and find ourselves with too many KPIs to put into one screen. Again, remember, only one screen makes up a dashboard. Make sure everyone knows that we can only have a certain number of KPIs or these metrics start to lose their identity in the mix. This next illustration shows this situation to a tee. Since the business user may want to have so many metrics we start using scroll bars to get everything on “one screen” even though with scroll bars it actually means that we have more than one screen. I would have been happier if they would have created some drill through to more detailed information rather than having scroll bars to compensate for this problem. In addition to this there is also an additional tab page for even more metrics. Again, one of my pet issues—How many metrics can one person have and still do their jobs appropriately? Ten? Twenty? Thirty? After more than 10–15 you start to drive the business user nuts since succeeding in one area might easily defeat you in another. In many cases, these KPIs start to work against each other and then you really have a problem if they are linked to bonuses and MBOs.

Using Space Appropriately: One Screen vs. Multiple

The preceding dashboard is a very good example of a developer having difficulty differentiating between a Balanced Scorecard approach and a dashboard concept; some information is specific to management processes, typically found in a Balanced Scorecard, and the other information is presented as a dashboard. There is so much information that the dashboard has scroll bars, additional tab pages, and links on each of the charts to more information. Even though this tab is labeled “Product Headlines,” it presents much more than just the headlines. This dashboard is appropriate for a middle-management position or a business analyst and not for any C-level management groups.

Displaying the Appropriate KPIs with the Appropriate Chart Type
The next example shows the need to understand what KPI you are trying to present. The line chart presents a very clear, focused metric on the dashboard, but the title states “Actual to Budget Variance”—if you look at the chart, it is showing actual and budget values but no variance.

Displaying the Appropriate KPIs with the Appropriate Chart Type

We either have to guess the variance or assume that overall the budget numbers are higher for the larger percentage of the time than vice versa and this is assuming that the KPI is the cumulative variance and not just the individual variances. I think the actual outcome of this metric is impossible to identify. What should be available is another line chart, or only a line chart, for the variance number itself. This would make life much easier for the business analyst. To really display the entire story you would need to have some other chart type since the variance looks like it will be both negative and positive.

The following illustration shows the use of filled-in circles for the chart type to make a point about operating costs versus revenue. This is a chart type doughnut with the center filled in to make it look like a solid format. This example has a couple of issues. First, once the operating costs get to be more than the revenue, the color scheme changes from a green background and brown filled-in area to a lighter-brown background and a darker-brown filled-in area. This should be the first clue that the chart type will not work appropriately with this metric display. The second issue is that expanding circles are used for the total amounts. Although the user can scroll over the areas to see the actual total numbers, to immediately get a feel for this information, the user needs additional context as to the proportion of size to amount.

Displaying the Appropriate KPIs with the Appropriate Chart Type

Let’s take this information and use another chart type—yes, the boring column chart type. In the following illustration, we see the same information, but in this case we can easily identify what is going on in terms of total volume and amounts with revenue versus operating costs.

Displaying the Appropriate KPIs with the Appropriate Chart Type

You can also see that even though the revenue was much lower in April than in March, the difference in revenue versus operating costs is about the same. Therefore, some fixed costs are probably in the operating costs to keep them at such a high level. You can also see that after about the $60,000 level, operating costs are going to start eating into margins due to the fixed costs (probably). This illustration shows how easy it is to get additional information out of this data using this chart type versus the other chart type, which you have to struggle just to read. Yes, the column chart type might seem very straightforward and boring, but the business user will thank you for its simplicity. They want to get the data quickly and effectively, not take a test in graphic design. So, use the appropriate chart type in your design.

Use of Colors and Spacing in the Dashboard
In the next example, the developers have gone wild with bright colors. You can’t see this because the illustration is in grayscale, but the dashboard in this example is loaded with bold shades of red, green, and yellow. It also has way too many different chart types. In the presentation of these KPIs we need to decide on what the primary chart type would be and work with the functionality.

Use of Colors and Spacing in the Dashboard

Having a total of five different chart types and presentation patterns on one dashboard is very complex for the business user to understand and interpret. Also notice the use of a very large space—relative to the amount of space we have to develop these dashboards—for a corporate logo. This is a waste of space. A large corporate logo is great in a presentation or a letterhead, but a business user who is looking at a dashboard for their own corporation doesn’t need a reminder of what the corporate logo looks like. If your marketing group insists on the inclusion of the logo in the dashboards, try to persuade them into allowing a smaller corporate logo for the dashboards. Finally, the headings are way too big. The title Revenue by Region takes up about 25 percent of the entire dashboard. Your titles and corporate logos should be no more than about 10 percent of the total space you have to work with, if that. So, in this one dashboard, we’ve identified five different issues:

  • Too much color is used.
  • The colors are too bright.
  • Too much room is given to the corporate logo.
  • Too much room is given to the titles of the reports.
  • Too many different chart types are included in one dashboard.

Take a closer look at these different dashboards from an outsider’s perspective and see what the business user will see. I am a firm believer that if you really want to know whether your dashboard design is correct, you should show your dashboard to someone completely outside of that particular industry; if they can understand the information and offer some additional analysis of this information within about 30 seconds, then your dashboard is probably pretty good. If not, then there’s something wrong with your display process.

In the following illustration, the developer decided to work with a 3D type of view and use very bright colors.

developer decided to work with a 3D type of view

The combination does offer some additional focus to the chart but doesn’t really add anything of additional value from the analysis point of view. Also, some context is missing because Actual and Budget do not have any sort of corresponding time-period titles such as monthly, quarterly, or yearly. The primary reason I’m offering this chart type 3D column as an example is to show that it doesn’t really add anything to the analysis of the data whether we are looking at a single, 2D or 3D format. In most cases there aren’t really any cons of having one dimensional view versus another but it can be a bit distracting at times. One issue is that the additional graphics used might cause a performance issue, because all of those additional pixels’ worth of display have to be pulled over into the chart and that with the use of colors we may want to use milder ones rather than shocking the business user with these multiple bold colors. You need to review and take into account the cons of any of these creative displays of the metrics because there is always a price to pay for having a highly graphical screen.

Use of Dynamic Graphics in the Dashboard
Don’t get wrong about the use of dramatic dashboards, with the new BOBJ component to the BI frontend, we have components such as Widgets, Dashboard Builder, and Xcelsius that allow the display of the dashboards to look exactly like some of the previous examples and really have bold statements and displays. As a matter of fact, I’ve purposely not disclosed the information about the systems being used on some of the examples to show you that no matter what system you use—BOBJ, BI WAD, and so forth— it’s not just the system that makes a dashboard but the overall architecture and formatting. You can create an excellent dashboard directly from an Excel spreadsheet. It wouldn’t have all the bells and whistles, but it would definitely be functional and capable of supporting the data that you might see on dashboards. An example of a dashboard with dynamic graphics can be seen in the following illustration.

Use of Dynamic Graphics in the Dashboard

This represents a true dashboard-type approach to displaying the KPIs. Personally, I think this example displays a few too many metrics, but that depends on the audience for this dashboard. For middle management, the total number of metrics seems right—very direct, consistent statistics, and a good format (possibly some wasted space). I’m more concerned about the additional filters at the bottom left. How many different combinations can the business user work with? I also don’t see an easy component that would enable the business user to save the specific settings once they switch the combinations to the correct set. In other words, once a person has navigated to a particular set of Product Group, Product, Operation, and time frame, can they save it as a variant, reformat and save again, and so forth? This capability would enable the person to retrieve that particular combination much more easily based on a saved variant. Another question I might ask is whether this dashboard could have been presented using simpler column, bar, and line charts or did the business user specifically ask for something that actually looks like a car or aircraft dashboard?

At this point, having reviewed several examples, it’s time to pause and reconsider what a business “dashboard” really is. It’s not intended to be a video game, so it doesn’t need to look like a racecar dashboard or something out of a Hollywood set. Rather, it is a display of critical KPIs in a single-screen format using charts and graphics and is intended to be easier to analyze than a report. Just give the high-level picture of the information and leave it at that. Having reviewed and worked with a number of different reporting systems, I understand the temptation to use all the dynamic and dramatic components to make a statement with the dashboard format, but giving in to this temptation usually results in an unmanageable dashboard that doesn’t serve its purpose.

The dashboard in the next illustration is another example where the developer of this dashboard simply needed to step back and review the screen to identify the issue. If I look at the allocation of the space in this dashboard we’ve actually given additional space to the buttons for navigation and this space is very important in the dashboard since we are looking to make a statement with only one screen. The space given to the buttons could be used for additional information about the critical tachometers for # of New Customers, Revenue, Top-10 Revenue, and Order Value.

New Customers, Revenue

I like quite a bit about this dashboard; it’s straightforward, presents the information in a very good display, and includes comparisons across the bottom charts. The viewer’s attention is definitely drawn to the primary information with the colors across the top tachometers, but giving them more room and size would make the dashboard better. If this would happen the upper metrics would be the same as the lower charts you would embed with the buttons positioned at the bottom of the diagram so that the size would be exactly the same as the charts below. Also, instead of hyperlinks for “more trends,” I would have a dropdown list with all the additional reports or charts available via the selection option.

Right Size and the Right Information Level
The following illustration is an example of a very good dashboard that follows most of the rules in terms of color, emphasis of the primary KPIs with additional colors and some dimensionality.

Right Size and the Right Information Level

Starting at the top, the dashboard includes some good examples of metrics that give the business user both Actual and Budget and then the Variance or % change to give some perspective. Inclusion of the summary charts in the lower half of the dashboard is a good example of incorporating summary reports into the dashboard so that all the information in the dashboard doesn’t have to be presented as charts. You don’t have to force the information into a chart to allow it into a dashboard. If the data lends itself to a summary report and it works for your business user, go with the summary report.

What I do have an objection to in the preceding example is the amount of valuable space that the logo takes up—over 25 percent of the total space on the top area of the dashboard. If you have no other KPIs to present, then make the chart with the line and column chart types included bigger to fill the upper portion of the dashboard. The logo or picture file only needs to be large enough to get noticed for a moment, not to take up valuable real estate on the screen. In this case, it’s not even a logo but a picture of some sort of accounting information that doesn’t offer any value to the dashboard or the data. This could be relegated to a small portion of the upper bar chart area and the metrics could be given all the additional space. I would also caution about the 3D views of the data. There are no issues with the overlapping of the columns in this situation, but we can’t guarantee that won’t occur with all of the rolling data. We would just have to watch and see if this issue does occur.

Getting Too Graphical and Losing Focus on the KPIs
The next example, one of the more interesting displays, uses lots of JavaScript and graphical horsepower to execute the screen. I’m concerned with that aspect of this dashboard, but what concerns me more about this approach to a dashboard is the positioning of the data and the breakdown of the data.

Getting Too Graphical and Losing Focus on the KPIs

Apparently, the primary KPI is the large gauge on the right side of the screen. Okay, so what is the metric represented here?

If I look at all four gauges we see that the display is confusing. If I look at the middle threegauges and the information displayed I’m not sure of the process of positioning the values in the gauges. See, the three are not indexed the same. If that’s the case, we need to have some sort ofrange showing in the gauge. Look at the top and middle gauges and we see that the colorsections are different and that’s OK since the good, middle, and bad sections may move, but if you look closely at the positioning of the arrows the top is 1.26% and that’s leaning to the rightwhereas the middle gauge is 1.47% and it’s completely over to the far right but the differencebetween the two doesn’t fit the display spacing between 1.47 and 1.26. Same goes with thebottom gauge. Now the larger indicator shows that 3.98% is completely to the far right and inred. So what would have happened if it was a total of 5.90%? Would the gauge range expand toaccommodate this difference? Or what is the maximum or highest total for these loans?

I also have to question the multiple options to change the data. I will assume that as wechange the information on the left side, the gauges change to reflect the informationaccording to the item highlighted. There seems to be too many KPIs available here and also too much in terms of short-term memory required for this to work. By that I mean that weare expecting the business analyst to remember everything about each of these indicators asthey page from one to another. I would find that a bit difficult to do. There is just so muchthat your short-term memory can hold onto while moving through additional information.Then you are looking for the business analyst to take that remembered information and usethat to integrate with other information to make a decision? I would find that more stressfulrather than helpful. If you are going to have all of this information available, you need tofigure a better way to show it. What you don’t want to do is to “lose” the current informationwhile looking at any other information. A better approach to all of this information would be tab pages since you can tab from page to page and not lose any of your information since you will not have to click a button and remove one set of data for another; just click from tab to tab and go back to another tab at any time. This is a situation where the display got thebetter of the person creating the dashboard.

The next example is a well-thought-out dashboard in terms of total information and good use of space, but the whole display and design is completely off. As an exercise, take a moment now to review the dashboard from a business analyst’s point of view and jot down what you find wrong with it. As compare your list against my list of items

Getting Too Graphical and Losing Focus on the KPIs

So first, if I look at this dashboard, the one area that I would really like to point out is the fact that the color scheme doesn’t match. If you look at the screen on the far right you’ll notice that it’s identifying each of the sales organizations as a specific color. Now, if I look at any of the charts I don’t see this color scheme anywhere. So that’s our first issue and really the one that I wanted to highlight in this dashboard, but if we continue to review these screens we see a few more concerns.

Second, if I look at the different charts I can’t really tell which ones are the primary KPIs. They are all in the same font and colors and there’s nothing distinguishing one metric from the other in importance.

Third, in the upper-middle chart I’m wondering what is involved in the organizations of each of these Sales Orgs. I don’t see that they are sorted alphabetically, or in priority of total sales, or by technical name. Basically they are listed randomly and the business analyst will have an issue with that setup.

Finally, I would also take note of the titles—titling something “Series 1” is not a title. So I’ve assumed that this is a graphical interpretation of Revenue YTD from the chart on the left but that’s just an assumption and to do that assumption your business user will have to think about something else other than analysis of the data.

Again, remember our jobs here are to collect the data and present the data consistently so that the business analysts will do their jobs of analysis of the data. I will also assume that the lower chart has the primary KPIs since it takes up most of the room on the dashboard and we should focus on that one the most. Therefore, having to be able to identify the KPI itself quickly is critical. In this case the title again is not straightforward enough and need to be cleaned up. I would also think that we need to have some sort of context to this information. Are the sales for this time period good, okay, bad? For that purpose we need to have some sort of benchmark—Planned Sales, Period to Period comparison, or something like that—to give the information more validity.

3.The Architecture of the Dashboard
Let’s talk a bit about the best business practices when it comes to actually developing a dashboard. So far we’ve covered the mechanics of setting up a dashboard, the KPI process within a dashboard, and generally how to organize your information in a dashboard. Now we are going to discuss the architecture of the dashboard in a bit more depth.

We’ve seen a number of different chart types used in dashboards in this chapter, some different variations of dashboards including dynamic, interactive, and others that include every bell and whistle under the sun in them. If we look at the basics of a dashboard we find that there are some standard rules of thumb when it comes to how a person will review and assimilate the information from a dashboard. In the last section we talked about the number of KPIs that make sense based on the total number that a person can proactively work towards. Well, this falls nicely into the total number or KPIs that you should include in a basic dashboard. The number runs around 12–15 KPIs per dashboard display. What this means is that if I have more than 15 what I should be doing is looking to add a tab page or some other approach to stage the other KPIs for further review and not try and push all of the 25 plus KPIs into one screen or set up a scroll bar to move around and see all of the indicators.

Now, if we look at some of the basics of a dashboard we have a set of views that we can identify. A view is basically one set of indicators in a specific chart type. So, if I have sales by quarter in one screen—this is a view. Normally we look for only two but not more than four KPIs in one view. If there are more than this the business analyst will have difficulty identifying all of them and deciding what the outcome of the particular view is—so the question is how many KPIs per view before the business user has a difficult time deriving any information from the view? If you were to review some of the concepts of the founding fathers of dashboards they would suggest two to three KPIs per view and this is not bad since you can have six views per screen and that means that you can have a total of 12–18 KPIs on one screen. This is more than enough information for one business user to understand at one glance. Now, what do we do to move the business user’s sight to where the more important indicator or information can be found—by the use of color or some other component that you can highlight or enhance to show some difference in one KPI versus all of the others? Use the format, fonts, colors, different chart types, or any other approach that you feel will make your critical KPI stand out and be noticed first. Some of the dashboard critics suggest that the eyes move the same way as your strong side hand—so if you are right handed your eyes will go right first, and vice versa if you are left handed. In my case, let’s not let the individual make that choice. We can make it for them by use of dramatic objects in the dashboard. The amount of formatting is a tricky one. You don’t want too little and you definitely don’t want too much. Too little is not bad but your dashboard will come across as not complete or polished if you don’t have enough highlights to it. If you have too much not only will it be distracting to the users but it may also cause an issue with performance of the dashboard. We don’t want either so you will have to decide what the business user wants and go from there. Some would rather have chart types like columns and bars but others can’t be without tachometers and other more elaborate objects.

As you go through the process of building a dashboard, look to integrate some of these ideas into your dashboards, keeping in mind (as always) that the executive who will be looking at a strategy dashboard has only about two to four minutes to review the dashboard, understand what the dashboard is presenting, assimilate the information, and be able to take that and use it to drive the growth and future of the company.

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

SAP BI Topics