What Are Enterprise Dashboards and Why Should I Care?

Featured

What are enterprise dashboards? Well, dashboards are simple-to-understand, visually-oriented depictions of the current state of the metrics and key performance indicators of most importance to your business. Of course, they borrow from the “cockpit” or “dashboard” metaphors that are so easy to “get”.

Here’s a screenshot of a typical dashboard:

Dashboard HTML Template

Nice layout, right? Do you want a copy of the HTML for it? It will save your developers weeks of tweaking code. To get a free copy of the html template, just sign up for my newsletter. Use the form to the side of this post. There’s no cost and I’ll send you 2 other cool layouts as well.

Business dashboards have become the universal front-end of business intelligence. From the production line worker on the manufacturing plant floor, to the sales force in the field, and all the way up to the CEO and CFO in the boardroom, everyone gets their metrics served through a dashboard these days. All enterprise reporting software use the dashboard layout as the home page view of the data. The business intelligence dashboard is easy to embrace, popular to develop and here to stay.

A word about business dashboard software and technology:

Don’t get hung up on the technology. Things don’t have to be complicated. Using Microsoft Excel is an excellent way to start business dashboarding. You can certainly use it to prototype and you may find it good enough to stick with for a very long time.

Here are 2 great resources on using Excel Dashboards:

Excel Dashboards: Templates and Ebook on Creating Excel Dashboards

Excel School for Dashboards

Are you new to the world of digital dashboards? Want to learn more about them?

Here’s how to start:

Key White Papers About BI and Dashboards

Gartner Magic Quadrant Report on Business Intelligence Platforms

Microstrategy’s Business Intelligence Platform for zone-based layout for scorecards and dashboards

More Business Intelligence White Papers (excellent way to research the business dashboard landscape)

Key Books on Enterprise Dashboards

I’ve been following the business dashboard space since the beginning. In addition to designing and building some of the first really major dashboard applications, I’ve had the pleasure of being the consolidator of dashboard project artifacts for many teams across many industries. Those with me at the beginning remember me having to swear secrecy in exchange for getting a “secret screenshot” of a hush-hush dashboard project (hence the moniker “Dashboard Spy”!). I’ve watched the development of the growing niche of dashboard books. Here are some of my very favorite:

First off, every once in a while, you should search Amazon for new books on the subject. Here’s a link that will bring up the latest books on enterprise dashboards:

Amazon Page of Dashboard Books (My favorite place to purchase books or anything else)

And here are some recommended books (be sure to browse inside the books with the “Look Inside” function):

Information Dashboard Design: The Effective Visual Communication of Data by Stephen Few (This is a great book on the principles of information visualization.)

Business Dashboards: A Visual Catalog for Design and Deployment by Nils Rasmussen (Really, really great book of examples)

Project Management Metrics, KPIs, and Dashboards: A Guide to Measuring and Monitoring Project Performance by Harold Kerzner (This is nirvana for project management dashboard geeks. I wrote a section in this book!)

Here are the latest books (both coincidentally on the SAS platform):

Building Business Intelligence Using SAS: Content Development Examples by Tricia Aanderud

SAS/GRAPH: Beyond the Basics by Robert Allison

Key Blogs to Follow

Here are a couple of launch points to learn more about business dashboards:

http://dashboardspy.com/experts

http://dashboardsbyexample.com

http://dashboards.tv

http://dashboards.org

http://enterprisedashboards.com

Key Dashboard Software Vendors to Check Out

http://www.idashboards.com

8 Step Approach to Developing Clinical Dashboards

Topic: Supply Chain Dashboard. An example of using dashboards to assist with the complexities of a logistics system.

Dashboard Spy post: 8 Step Approach to Developing BI Dashboards. The CTO of a healthcare company shares his 8 step dashboard methodology in the Computerworld article Developing Clinical Dashboards.

Hospitals, medical centers and other health systems are increasingly using digital dashboard technology to provide relevant, up-to-the-minute information to clinicians in a visually rich format to improve the quality of patient care.

Designing and using clinical dashboards requires substantial physician involvement and a well-defined process. The University of Pennsylvania Health System, a.k.a. Penn Medicine, is currently in the midst of developing the Penn Data Store, a data warehouse and series of individual dashboards, to serve our clinicians and researchers. The Penn story may be of use to you and your organization as you move forward in the world of dashboards.

So starts the article that details how an organization used Oracle’s Business Intelligence Suite to create a single data storehouse with all of their patient, admin, financial and supply chain data.

Here are the 8 steps:

  1. Meet with users to determine data needs
  2. Design the presentation layer
  3. Design the semantic layer
  4. Design the physical layer
  5. Develop and test all 3 layers
  6. Perform QA
  7. Conduct a Pilot
  8. Begin general rollout

Here are some particulars. See the article for the full story.

1. Meet with users to determine major data needs

Many users and potential users of dashboards aren’t familiar with the systems’ power and capabilities. They typically use noninteractive spreadsheets and graphs that present data in fixed rows and columns and lack the flexibility of Web-based tools.

The first step in this phase was to inform clinicians of the many additional possibilities that a more powerful tool offers. We did this by first building sample dashboards to demonstrate the tool’s capabilities. We then asked the clinicians to identify several key measures, dimensions and filtering criteria for the dashboards they were interested in.

2. Design the presentation layer

For dashboards to deliver the most benefit, users must agree on presentation standards before the design phase begins. It’s crucial to achieve agreement on items such as color schemes, graphical objects and navigation standards so future dashboards will look, feel and behave consistently. This will improve user satisfaction and reduce training demands for each new dashboard.

Designers must think carefully about the hierarchy of the data they want depicted in the dashboards and what levels of the hierarchy will be visible. In our example, the hierarchy is Practice Physician Patient. Depending on a user’s security status, he may or may not be able to see the patient data.

Once the hierarchy and associated measures such as year, month and practice name were grouped into a dashboard page, we selected the graphical elements. We chose histograms, line graphs, pie charts and simple tables to present the data in an intuitive fashion that met users’ needs and simplified navigation through the dashboard pages.

3. Design the semantic layer

The semantic layer maps the presentation layer to the physical layer. Developers prove their worth in the design of this layer. Defining patient populations by disease categories, grouping drugs hierarchically by therapeutic area and organizing physical locations are examples of the challenges that the semantic layer’s designer faces. Users play a key role in formulating those definitions. In-depth knowledge of both the presentation layer design and the physical data models is essential.

4. Design the physical layer

As mentioned, try not to change the design of the physical layer. Whenever possible, avoid creating an entire new physical data structure, because doing so generates the need for additional extract, transform and load (ETL) steps each time the clinical data warehouse is updated. Redundantly storing data produces additional storage, backup and maintenance costs and opens up the risk that duplicate copies of data won’t be updated with the same frequency as the original.

5. Develop and test all three layers

Users who are new to the dashboard development process will likely need to see how the systems operate with real data. We have found it useful to introduce clinicians to a working prototype to gain early feedback on the design. Regular weekly demo and review sessions then help developers refine and test the design. When you’re engaged in this phase of the project, take care to manage scope creep, since participants might be tempted to request new capabilities or data that weren’t in the original design. Put off responding to such requests until a subsequent release of the dashboard.

6. Perform quality assurance

Here are several quality-assurance requirements we developed at Penn Medicine:

  • Use data from the actual data warehouse, rather than simulated or test data.
  • Include monthly and quarterly data warehouse updates during the QA process, especially when the data being used in dashboards will cross calendar months, quarters and years. A year-end data update would be ideal, but most projects can’t wait that long.
  • Compare dashboard data to the original source systems, to ensure that no translation or presentation errors were introduced during development.
  • Test system performance and response times with large amounts of data to ensure that the dashboard responds effectively to users’ needs.

7. Conduct pilot tests

Before making a dashboard available, we ask a small group of users to pilot-test it for a few weeks, as a short extension of the QA phase. This provides additional information on usability, performance and quality. If the pilot group recommends moving forward, we proceed to the general rollout. If the pilot group identifies problems, the development team resolves them.

8. Begin general rollout

This phase involves these major components:

  • User orientation: New users may need a brief training session. Those who have used dashboards in the past should be able to use the new dashboard with no assistance — if the presentation layer was designed well.
  • Support documentation: Gather design and operational specifications and post them on support sites.
  • Help-desk hand-off: Write scripts and give them to the help desk for guidance in responding to support calls.