As a business intelligence consultant, a frequent request I receive is to “create a dashboard”. One of the first things I do is verify that I understand what the client is actually asking for. Many times by “dashboard”, what they mean is “lots of stuff all at once”. That’s when I pull out the tried and true “dashboard analogy” which is of a car dashboard. A car dashboard provides only a handful of key indicators that indicate the high-level status of the most important metrics of the operating car (speed, remaining fuel, RPM). There may be some other items, but these are relegated to smaller supporting dials. So it should be with dashboards.
Information Dashboard Design
is a great resource. Key ideas from this book: “Less is more” “Keep it simple”.
Another related issue is “can I have a dashboard if I don’t have and don’t plan to use SharePoint”. In many cases I think it can be better to start the dashboard discussion with no immediate plans to use SharePoint. It narrows the focus and keeps things on target (pun intended). SharePoint can do a lot, but it’s also a considerable investment in time and infrastructure. Finally, the use of a dashboard may help to prioritize the investment in SharePoint (or not).
Frequently the tools at hand are simply those in the basic Microsoft SQL Server stack, (SQL Server, Analysis Services, Reporting Service, Integration Services). I’ve frequently created v1.0 of a Dashboard using only these tools.
Scenario #1: Integrate in existing portal:
In this case we had a simple intranet portal in place. By creating a page with an iFrame region, we were able to embed the report. You can opt to either show the Report control (which would give you the little spin-y green circle) or have the report appear as an HTML output by changing the flags on the URL
Scenario #2: Use a master report and subreports to create the dashboard. In this scenario we had several user-selectable parameters. The “outer” report was simply a shell to collect the parameters and provide layout positions of the sub-reports. The sub-reports were a collection of small tables, graphs, etc.
Rob Fisch created a nice tutorial that describes many of the techniques I used. I don’t have access to examples I worked on since these were for previous consulting engagements. I am working on one right now, but it’s not available publicly.
One last tip: even before stoplight indicators were integrated in Reporting Services, it was possible to have red/green/yellow indicators. Simply use the switch function to substitute which icon file to display in your report. So you can have effective dashboarding (with KPI indicators, going all the way back to the first version of SSRS)
In my experience it’s far better to get early and simple dashboards off the ground using the technology at hand than to wait until the “next big thing” in software comes along. Feature-rich software is great if you need and use the features, but the dialog with the business stakeholders needs to take place to determine which features are needed. The best way to start that dialogue is with working examples of dashboards and KPI’s.
