Thursday, July 15, 2010

Building dashboards - Strategic Intent vs Technology

A large technology company I work with generate a few hundred reports on a daily basis, many of them unwanted, unused or unrepresentative of the business. The business understand the challenges, but being a technology-driven company, is heavily reliant on the Information Technology department to deliver the goods.

I’ve been trying to slowly push the concept of implementing a Business Intelligence platform and finally managed to get the ear of the CIO, who told me “Well, I like your idea. Tell you what, provide a quick demo and if I like it I’ll take it to the Business people.” I was excited, and immediately began probing to see which processes would be the best to map for a proof-of-concept demo.


I came away feeling that what will really seal the deal would be a whizz-bang demo showing a hierarchy of dashboards, each boasting fancy graphs of many colours, with hover and click effects, and perhaps soothing music playing in the background. “Make it look nice, and add our logo to the page, ” I was reminded.


This got me to wonder to what extent dashboards needs to be technology focused. In this fast changing technological environment, dashboards have to be – technologically speaking – responsive, relevant and multi-leveled and a good dose of technology is required to provide that. However, at some point, the dashboard has to stop being a technological gimmick and start being reflective of the business environment. At this point, responsiveness, relevance and multi-levelness must be about the business processes, and the technology used to present the information starts to become less and less relevant, as the data presented is probed to deeper levels.


Building a dashboard therefore requires a good balance between the technology used and the information it provides. Far too often, a dashboard project is embarked on largely because of the eye-candy it provides (normally compared to current solutions). Over time, the new bells and whistles become old-hat, and the business is no further from where it was prior to the project. So we wait for the next big technological wave…and the cycle continues.


A dashboard should be one of the deliverable of the strategic intent of the organisation to provide the business with meaningful information. It should be guided by a information management strategy, which should covers all aspects of delivering information to the business. An analysis must be undertaken to understand what is being presented, to whom, and how that information is used by the business. Skipping this portion of the project will bring the whiz-bang, but will run out of flavour as soon as the ooh-aahs subside.


Before embarking on your next dashboard project, ask whether the strategic intent is balanced well with the technology you are presenting. You could use the following points to score your dashboard.

  • Check that your are providing a visual presentation of the measure
    After all, your dashboard is a visual concept. Don't over-do the seriousness of the dashboard, and lose the visual impact in the process.
  • Provide the ability to identify and correct trends
    Information in dashboards must be used to present masses of data compressed into small components, so that trends and patterns are easily recognisable.
  • Provide a measure of efficiencies/inefficiencies
    Pictures on the dashboard are no good if they are not supported by measures. The interpretation of the measures against planned or total performance should also be at hand to provide perspective to the measures.
  • Show details
    Summary data is best suited for some level of audiences (for example senior management), but details should always be available, or be pointed to if the detail data itself is not available to the dashboard.
(Ref: http://en.wikipedia.org/wiki/Dashboards_(management_information_systems)

Sunday, January 24, 2010

Redirecting to dashboard upon login in Pentaho

The Community Dashboard Framework is undoubtedly one of the most significant community contribution to the Pentaho project, and it has attracted a lot of attention and questions about how best to use it as the primary interface to the Pentaho platform.

One question that comes up often is how to redirect the user to a dashboard, instead of the Pentaho User Console.

Generally, the use will invoke the Pentaho webapp by typing the following URL:
http://localhost:8080/pentaho

This results in the invocation of the script biserver-ce/tomcat/webapps/pentaho/index.jsp.

<html>
<head>
<title>Pentaho BI Platform</title>
< META HTTP-EQUIV="refresh" CONTENT="0;URL=./Home" >
</head>
<body>
</body>
</html>

A quick glance at this file reveals that the script redirects execution to the file biserver-ce/tomcat/webapps/pentaho/jsp/Home.jsp.

To redirect Pentaho to load a specific dashboard page instead of running Home.jsp, we change the index.jsp file in the webapps directory, as in the following example:

<html>
<head>
<title>Pentaho BI Platform</title>
<META HTTP-EQUIV="refresh" CONTENT="0;URL=/pentaho/content/pentaho-cdf/RenderXCDF?solution=mydashboard&path=/company&action=homedashboard.xcdf&template=companyview">
</head>
<body>
</body>
</html>

This loads the file
pentaho-solutions/mydashboard/company/homedashboard.xcdf
with the template companyview.

The Pentaho platform by default requires authentication before serving any content. If you haven't logged in, then you will first be directed to the login screen. Upon a succesful login, you will be directed to the dashboard.