Dashboard Blogger

Visualization Tools

2009-02-12T09:08:00.001-08:00

Ran across a couple of nice visualization links today, compliments of O'Reilly:

http://www.uuorld.com/ - Immersive mapping environment

http://www.visitmix.com/articles/Visualization-Trends-For-The-Noosphere - Visualization trends for the noosphere

Dash

2009-01-27T21:23:00.000-08:00

I haven't blogged here in a while because I'm not working directly for dashboard company anymore and I'm in the process of moving to a personal blog, but since I still have this site, I thought I'd mention a cool product I saw a demo of tonight. It's called Dash from Five Runs in Austin. Out of the box, it's a really nice tool for instrumenting your Ruby on Rails applications but they've made it extensible and language-agnostic so that other languages can work seamlessly. Even more, they plan to allow you to use their product as a source to store metrics so you can access them and display them any way you want. For example, you could upload supply chain events (order received, order shipped, etc) and use their tool to overlay graphs to show differences between DCs or correlations that might help with analyzing problems.

They're in private beta right now, but check out their site and request a beta key if you're interested.

Relationship Analysis/Visualization

2008-07-09T22:42:00.000-07:00

I recently had the need to evaluate a few different social analysis tools for a project. These are tools that visually show relationships between entities. For example, it could show a representation of your friends/connections on Facebook or Linked In. Then you click on a friend and it shows their network and so on. I looked at open source library called JUNG (Java Universal Network/Graph framework) which was pretty nice. There were a few other commercial offerings that looked ok.

But the one that really caught my eye was the BirdEye Relationship Analysis (RaVis). It's written in Flex and it's just flat out cool. It actually made me spend time to think of possible ways to use relationship analysis in applications that really don't need it, just so I could use the tool.

Check out the demo here. Here's the home page for the suite of related tools.

Every App is a Dashboard

2008-06-26T22:29:00.000-07:00

I just realized today that I can barely design an application without turning it into a dashboard. I'm really trying specifically not to build another dashboard application, but whenever I step back, it looks suspiciously similar to other dashboards I've built.

Web applications generally consist of task-oriented pages and reports. In my domain (primarily enterprise supply chain), many of the tasks are done by hand-held devices of some kind. That leaves a handful of data entry screens and the reports. Greenbar is probably not the way to go these days so the reports are going to be online. Displaying HTML tables with thousands of rows is not all that useful so we need to summarize, highlight, and allow drilldowns to details. Hmm... that sounds familiar.

I'm not saying this is a bad thing, it's just kind of amusing. The challenge is to really think about the layout so that it provides the most value to the user, without getting trapped into assuming a grid of gauges/widgets is the way to go.

Semantic Web

2008-06-08T19:56:00.000-07:00

I recently read an article about the semantic web. Like search, the semantic web is a powerful way for a person or organization to extract information from data. The idea (over-simplified, if not half wrong) is that a group of experts in a domain can define a way of representing data for that domain. Applications or people that generate data for that domain do so in the official format which allows computers to use that data to make inferences, i.e. "learn".

The semantic web could potentially provide even more power than search for corporations trying to optimize their business. It's a little fuzzy like search in that there is not necessarily a clear path to the one true answer. On the one hand, how do you sell someone on a dashboard that may or may not return a useful answer? But on the other hand, why shouldn't corporate dashboard users have access to tools that are powerful enough to answer questions the user hasn't even thought of yet.

At a minimum I think ideas from the semantic web can be leveraged for business intelligence analytics and could make it much easier in the future to write applications that integrate with multiple different data sources.

Dashboard SDK

2008-05-30T21:19:00.000-07:00

As I mentioned in a previous post, my company has added a new software development kit to our dashboard application. I was recently asked to prepare a demo of a gauge for a potential customer. The idea is to show information about a set of inventory picks within a warehouse including total travel distance, and the density of products and locations. The customer can use this to measure how efficient their picking process is.

I've been using Ruby more and more recently so I decided to actually create a first cut of the gauge using our Ruby in our SDK. A screen shot is below, followed by the actual code (disclaimer: I'm fairly new to Ruby and I was purposely verbose to illustrate the details; this could have been done in Groovy, Java, or JavaScript as well). The point is, I seriously doubt a report like this could be easily built using a drag and drop BI tool. The code required some specific knowledge of the data structure, but anyone creating something like this will need that domain knowledge anyway. This only took a few hours and it fully integrates with the framework meaning it can be configured per user, output to Excel or PDF, set up as an Alert, etc.

So more evidence for my earlier assertion that business intelligence requires code.

Code (note: this is running inside a Java framework via JRuby so is accessing the database through Hibernate):


include Java
import 'java.util.ArrayList'
import 'WaveSummary'

# Get the list of Ickpts (inventory runs) either from the parameter ($ickpt)
# or the database if they want all

where = 'where 1 = 1 '
if ($ickpt and $ickpt.length > 0) then
 where += 'and ckpt_id in ('
 $ickpt.each do |i|
   where += i.getName() + ','
 end
 where.chop! # lose the last comma
 where += ') '
else
 # No parameter value; get them all; we could filter by date but some span days
 ickpts = $session.createQuery("from Ickpt").list().toArray()
end

# Build map for easier lookup of ickpt record later
ickptMap = Hash.new
ickpts.each do |i|
 ickptMap[i.getIckptKey().getCkptId()] = i
end

if ($dateRange != nil) then
 where += ' and create_dtim between :from and :to '
end

# First query to get the unique slots
query = $session.createSQLQuery("select ckpt_id, count(distinct sel_loc) from aseld " + where + " group by ckpt_id")
if ($dateRange) then
 query.setDate("from", $dateRange.getDateRange($timeZone).getFrom().getTime())
 query.setDate("to", $dateRange.getDateRange($timeZone).getTo().getTime())
end

summaryMap = Hash.new
query.list().each do |result|
 s = WaveSummary.new
 summaryMap[result[0]] = s
 s.uniqueSlots = result[1]
end

# Next, get the unique skus
query = $session.createSQLQuery("select ckpt_id, count(distinct prod_id) from aseld " + where + " group by ckpt_id")
if ($dateRange) then
 query.setDate("from", $dateRange.getDateRange($timeZone).getFrom().getTime())
 query.setDate("to", $dateRange.getDateRange($timeZone).getTo().getTime())
end

query.list().each do |result|
 s = summaryMap[result[0]]
 if ! s then
   s = WaveSummary.new
   summaryMap[result[0]] = s
 end
 s.uniqueSkus = result[1]
end

# Now query to loop through the picks to calculate the distance
query = $session.createSQLQuery("select ckpt_id, sel_x_coord, sel_y_coord, assg_id from aseld " + where + " order by ckpt_id, sort_seq, sel_loc")
if ($dateRange) then
 query.setDate("from", $dateRange.getDateRange($timeZone).getFrom().getTime())
 query.setDate("to", $dateRange.getDateRange($timeZone).getTo().getTime())
end

lastX = lastY = lastCkpt = lastAssg = 0
query.list().each do |result|
 ckpt = result[0]
 s = summaryMap[ckpt]
 if s == nil then
   s = WaveSummary.new
 summaryMap[result[0]] = s
end
assg = result[3]
if (lastCkpt == 0 or lastCkpt != ckpt) then
lastX = lastY = 0
end

x,y = result[1],result[2]
if lastAssg != 0 and lastAssg == assg then
 if lastX != 0 and lastY != 0 then
   s.distance = 0 if ! s.distance
   # Just using straight-line distance between each sel loc
   # This is not exact, but close enough for comparison
   s.distance += Math.sqrt((x-lastX)**2 + (y-lastY)**2)
 end
end
lastCkpt, lastAssg = ckpt, assg
lastX, lastY = x, y
end

# Dump the map into a list to return
data = ArrayList.new
 summaryMap.each do |ckptId, s|
 s.ickpt = ickptMap[ckptId]
 s.distance = 0 if ! s.distance
 s.uniqueSlots = 0 if ! s.uniqueSlots
 s.uniqueSkus = 0 if ! s.uniqueSkus
 s.distance = s.distance/12 if s.distance > 0
 s.slotDensity = s.distance/s.uniqueSlots if s.uniqueSlots > 0
 s.skuDensity = s.distance/s.uniqueSkus if s.uniqueSkus > 0
 data.add(s)
end

data

SaaS Primer

2008-05-28T23:03:00.000-07:00

I've been working on building a new Yard/Dock Management/Appointment Scheduling application (hence the lack of blog entries). Our plan is to offer this application as both a traditional in-house hosted app and an externally hosted SaaS model. In that spirit, here are some SaaS articles that I've been reading:

Architecture Strategies for Catching the Long Tail is a great primer on SaaS and the issues you will face when adopting it.

Top Ten Reasons Why On-Demand Services Will Soar in 2008 - the title is pretty self-explanatory.

On Demand Gaining Traction in Supply Chain (PDF) from Aberdeen Research has some good information about the adoption of SaaS in the suppy chain software space.

On-Demand/SaaS Reality discusses SaaS pricing and its adoption in the enterprise.

Power Dashboard

2008-03-09T23:37:00.000-07:00

I've always believed that dashboards require code, i.e. anything you can do using drag-n-drop will either not be very useful or will take a large number of complex operations to do something that would be trivial using raw SQL or an actual program. Well finally I've got a hybrid solution that I think could help bridge the gap between drag-n-drop and coding. I've just completed my first test of a new scripting interface for our dashboard application so that a new widget/chart/report can be created by an end-user using a simple wizard. I'm hoping this feature will allow moderately technical power users to create reports that harness the power of programming without the extra baggage you normally encounter when writing new code or using an API.

Right now it handles SQL, HQL (hibernate query language), JavaScript, Groovy, and Ruby. For many types of reports, users can use SQL because it is familiar to them. However, our application integrates with Hibernate so if a user creates or already has a Hibernate mapping to their database, they can move up the chain to HQL. The advantage is that they no longer have to perform all the joins manually and the application allows them to configure the display based on the meta data that comes with the Hibernate mappings.

But there will come a time when a single query will not be powerful enough. For example, what if you want to display a list of appointments between a supplier and their customer but you also want to show a map of the supplier's location. That's not too easy to do in SQL or a drag-n-drop user interface. But with just a few extra lines of code, it can now be added to one of our gauges, all via the standard user interface.

I think this feature will be perfect for IT departments. They get all the power of a dashboard framework such as alerts, configurable tables, many kinds of charts, but do not have to change the environment to add new functionality.

I'll blog more about this feature including some examples in the future.

Cool Visualization Technique

2008-02-24T20:00:00.001-08:00

Today, the New York Times business section had a visualization of movie box office revenue. I thought it was cool enough in the paper, but the online version has popups that show the details and it goes all the way back to 1986. I imagine there could be many uses for this type of chart in supply chain dashboards, for example inventory levels by product over time.

Can Dashboards Be "Close Enough"?

2008-01-10T20:27:00.000-08:00

Web searches are a fuzzy way to get information in that there is no objective right answer. When I've worked on dashboards for customers, it's always been a given that there is a single right answer to a question and that the dashboard fails if it doesn't provide that answer. I never really questioned it. But personally, I make far more use of the fuzziness of searches. I don't expect to always get the right answer and I'm usually perfectly ok with clicking around and scanning articles until I find what I'm looking for. Before Google, I did most of my internet searching using the hierarchical categories on Yahoo. Google and other open-ended text searches freed me from having to think in terms of a set path to the right answer.

Corporations seem to be opening their minds to those concepts too, based on efforts from Microsoft and Google to sell inside-the-firewall search tools. I just wonder how that will play with businesses that are accustomed to getting the one true answer. If I'm a CEO looking for the Q4 sales forecasts, I'm not going to want to hunt through a list of links to things that might be the Q4 sales forecasts. "Close enough" just isn't good enough for that kind of information. Yes, we've accepted the slight inefficiency of the Google search, but only because of the terrible inefficiencies of the alternatives. Just think back to a school research paper where you had to find an obscure periodical article in the library.

So for now, I think corporate search may work its way into dashboards and business intelligence tools, but only in situations where the fuzziness is offset by the inefficiency of the alternative. But it's possible that in a few years all business intelligence will be done via googling and I'll look back at this post and wonder how I could have been so naive. If I can find it, anyway.

Low Dashboard Use in Enterprise

2007-12-19T20:59:00.000-08:00

Aberdeen recently released another study about the role of key performance indicators in various organizations. As expected, the "best in class" organizations have a much higher overall use of KPIs. What's surprising is how few of the companies in the survey make use of dashboards, scorecards, analytics, and alerts. Even among best in class companies, the chart below shows that almost 40% do not use dashboards and even less use those other methods. Maybe I've been in the dashboard business so long that I'm biased, but those numbers seem low to me. Most companies must still be using ad hoc reports, spreadsheets, and whatever information they can pull from their transactional systems. Those tools will always have a place, but the efficiency, collaboration, consistency, and accuracy of dashboards seem to make them a no-brainer for KPI tracking. I guess there's a lot of room for improvement.

Enterprise Software Design

2007-12-11T18:37:00.000-08:00

Robert Scoble started a big blogging war about the beauty, or lack thereof, in enterprise software. His follow-up post covers the initial post and responses fairly well so I won't rehash it here. But I will put in my two cents about how the discussion relates to dashboard software.

The software I write is definitely targeted towards the enterprise. Our biggest customers are Fortune 500 companies. What I find is that, in the dashboard space, you sometimes feel like you have to avoid writing software that's too sexy. Sure, the marketing and sales guys want pretty dashboards with lots of colors and speedometer gauges. But some customers almost act like if it looks good, it's just fluff and not functional.

Aside from that, you're warned so often by the visual design experts not to overdo the prettiness, that you almost become gun shy about your software looking too nice, even if you really are trying to make it functional.

So, you follow all the rules and try to keep your dashboard clean and uncluttered and avoid scrolling and all that. And then your customers come along and put everything into a table view and put 50 gauges on the same page because they prefer vertical scrolling to clicking. And they're happy.

So I guess the only moral I take away from all this is to try my best to make software that's both highly functional and decent looking. Either option sounds pretty good.

Dashboard in the Cloud?

2007-12-04T01:44:00.000-08:00

Software as a service (SaaS) or running applications "in the cloud" is all the rage these days. I've been thinking about the applicability of that model to dashboard software. To be clear, I'm talking about an application that is hosted by someone other than the company that is using it, not just subscription-based licensing, which is a different issue.

The advantages of SaaS for dashboard software for the user are not much different than for other applications: lower IT costs, less up-front cost, easy (theoretically) upgrades, potentially better security and scalability.

However, there is a big difference between a typical dashboard application and something like a CRM system: the data. In a dashboard app, the data typically comes from many other systems. Whether it's real-time or batched the data has to get from inside the firewall to outside the firewall where the dashboard lives. That opens up a big can of worms in terms of security and performance.

On the performance side, a dashboard that pulls data from a relational database would now be going over the net which is going to increase the latency of the queries. Depending on how those queries are designed and the speed of the link, this could be a huge performance hit. The same thing would apply to a dashboard that pulled data off of a message bus. There would be less of an issue if a "push" model was used where some process that lives inside the firewall sends data to the dashboard app. But now we've moved some functionality inside the firewall and back into the hands of IT which decreases the benefit of the SaaS model.

Also, the data seen on the dashboard is now going over the public internet and is likely stored in a database living at the hosting provider. This is a security risk that will have to be carefully managed, but it's not an unsolvable problem. The data can easily be sent encrypted and the dashboard itself can support https so the data can't be intercepted on the way back to the end-user's browser. The database issue is mainly a matter of the trust you have in the hosting provider so the application vendor better do their homework when selecting one.

Microsoft has published a good primer on these kinds of issues and SaaS in general. It's not specific to Microsoft technologies and the first parts are not too technical.

Despite the issues, I believe SaaS does have potential for dashboard software. In cases where collaboration among multiple companies is a requirement, such as CPFR, many of these same issues would have to be addressed anyway. In those situations, the chances are good that a hosted solution would be forced to solve the problems in a better way than a traditional install. So I can

Speedometers

2007-11-25T21:09:00.000-08:00

I just discovered a new blog about business intelligence with an emphasis on charting and dashboarding. It's from a company called Juice Analytics. One of their recent posts is about the use of the speedometer chart widget in dashboards. They, like Stephen Few, are not a big fan of this method of presentation and give various good reasons as to why.

At first I was feeling a little guilty after reading the article, because even though I've read Few, I have still incorporated the speedometer into our dashboard software. It's great for demoing because it looks good, it's easily recognizable, and it helps support the whole dashboard analogy (you don't see many pie charts on your car dashboard). In fact, I added it at the request of one of our sales reps because for the longest time one of our presentations contained the following quote:

I want a supply-chain dashboard that looks like the dash in my 911 Carrera, with all of the dials set to my specific supply-chain metrics. And when any one goes out of tolerance, I want the dial to redline and let me drill into the specific issue.
Hans Peter Schaefer – The Gillette Company.

So should I argue about the car analogy with the CEO of a Fortune 500 company? The challenge is that we do have many situations where there is a key metric or score that needs to be tracked. That score can then be sliced and diced a number of different ways, but different users will want to drill down to different views. For example, one user may want to see the trend so a line graph or a spark line would be appropriate. Another user may want to compare the value across regions or departments. Or by product group or person or any number of categories. Some people will want a combination of those views. So while the speedometer does take up unnecessary space, hide trends, etc, how do you decide which alternate view to use?

The answer may simply be that speedometers are appropriate in one situation: demoing dashboard software. You're trying to illustrate concepts to people in different roles in a short period of time. For better or worse, people get the speedometer. A sales presentation is not the place to preach about the visual display of quantitative information or the effective visual communication of data. If you start with a single value and drill down to a few examples that are more effective displays, the audience will understand that there are options. When you get into the analysis phase, you can weed out the bad displays since you'll have access to the people that understand how the information will be used. Each user can have an initial display tailored to the actions they are likely to take based on the data.

So, I'm not killing the speedometer widget just yet. Maybe for some people, it really does provide the right level of detail. But I'll continue to approach it with a dose of skepticism and look for better ways to express information.

Laptops and Programming for Kids

2007-11-16T07:20:00.000-08:00

This is off-topic but I wanted to mention a couple of things that I've run across recently.

The first is the $100 (closer to $200) laptop project's Give One Get One program. For a limited time you can pay about $400 to get a laptop for yourself or your child and another one will be donated to a child in a developing country. The laptops look pretty cool especially for young kids because they're designed for rugged use and minimal access to support.

I also ran across a kid's programming language called Scratch. It was developed at MIT and it's a way of programming that uses simple drag and drop instead of typing commands. I've tried to get my son interested in programming before, but his eyes just glazed over at even simple Ruby code. But he seems really interested in this. He plays a lot of free Flash games and Scratch theoretically will let him write his own. You can join a community where other kids share their programs. Hmm... maybe I'll look into using it for our dasboard SDK.

IBM Cognos Acquisition - The End of BI?

2007-11-12T23:42:00.000-08:00

IBM is acuiring Cognos, which blows my theory that that Infor would do it. Infoworld's take on the deal is that BI is dead because the big BI tools will become part of the database offering (Oracle and DB2). I'm not so sure about that. Business intelligence has always been more about the intelligence than the tool. It's not really that difficult to pull data out of a relational database and display it in a table or graph. The tools definitely help organize things and can provide a layer of abstraction so the end-users don't have to see the ugliness of the database, but someone still has to do create that abstraction and that's where the value of BI lies.

Contrast the IBM/Cognos deal with the SAP purchase of Business Objects. SAP obviously has knowledge of their own data; now they have a tool to present that data in meaningful ways directly to the people that want it. Combining actual data with a BI tool is powerful. Combining a database with a BI tool still leaves a huge gap. The companies that use DB2 or Oracle will not be able to just turn on Cognos or Business Objects and get value - it will take the standard huge development effort just like it always has. And even though SAP has the better chance to deliver a turnkey BI solution, the complexity and customization of most SAP implementations means it's going to take a while.

I'm not claiming these deals aren't important or won't be successful - just that there's more to BI than a database engine and a reporting tool.

Pros and Cons of Real-time Dashboards

2007-11-10T23:07:00.000-08:00

A lot of Business Intelligence applications boast about being "real-time". On the surface this sounds like a good thing, but in my experience there are trade-offs between real-time and batch processing for dashboard software.

For operational systems, real-time is a must in some cases. For example, managing labor requires you to know precisely what tasks have been completed and what are available. Alerts that are designed to notify you of a situation in time to take action to prevent it from escalating also may require real-time information. Using real-time data usually avoids an extra data store that has to be maintained, backed up, and monitored. The data is pulled directly from the transaction systems or pushed to a temporary cache within the dashboard application.

However, in many cases, it is actually better to use batched data. Transactional legacy applications are usually tuned for OLTP processing, whereas dashboards typically demand DSS queries. Many databases can't be tuned properly to handle both so there is either a performance hit on the dashboard side or on the legacy side. In a batched architecture, the developers can create their own data model that the dashboard uses, which allows the dashboard performance to be optimized without impacting the transactional systems.

With a separate data store, the developers can reuse the dashboard with no changes to go against different transactional applications. For example, in a project I've worked on we had to report against three different legacy applications all doing the same task. By abstracting the data out into our own data model, we were able to write one set of dashboard components that worked over all three systems. As new systems come online or we get new customers with different systems, we can implement the same dashboard quickly because all we have to do is write the loaders to populate our data model.

Additionally, transactional applications often have to purge old data to keep the database small and fast. Data batched for a dashboard can be kept around indefinitely to be used for historical reporting and trending.

When designing a dashboard, it's important to talk to the users to determine if they want real-time because it's a nice sounding buzzword, or if they really need it. Dashboards should be as real-time as they need to be and not more.

Virtual Dashboard Appliances?

2007-11-04T13:21:00.000-08:00

I've recently been working with a customer to develop a prototype of a dashboard for monitoring the process of unloading trailers in a warehouse. It will report on metrics such as late appointments, average unload time, the number of pallets that need to be re-stacked due to damages, rotten wood, etc. We have a quick turnaround on the prototype so I've been thinking about the best way to get our application in the customer's hands with minimal training and IT time on their side.

In an unrelated project I've been using Microsoft Virtual PC to work on a client's network because a) they use the Cisco VPN and the client does incredibly nasty things to your computer (starting with two unprompted reboots during the install process; b) the Cisco VPN doesn't work on Vista so I need to run a Virtual XP to use it; and c) I want a guaranteed virus-free clean environment to connect to the customer's network and what better way than a clean install with only the minimum applications.

Putting the two together, I decided to hand over the prototype by just creating a virtual machine with everything pre-installed and configured. The client can load that machine up on any PC, give it as much memory as necessary, and demo with no new hardware or installations.

That got me to thinking - could that be a good model for doing installs of Dashboards in general? We could install the app server and database, backup software, admin tools, etc; pre-configure everything, and ship it to a customer to drop in and start using right away. It's like SaaS but the customer retains more control in that their data never has to go outside the firewall. The really cool part is if they have issues that need support, they can send the entire virtual machine back to us where we can install debugging tools, etc to find the problem.

I was feeling pretty proud of myself for thinking of that until I read this article talking about virtual applicances. It turns out to not be such an original idea. Still, it's an interesting concept and I'll be on the lookout for opportunities where it makes sense.

Chart Types for Web-based Dashboards

2007-10-27T23:20:00.000-07:00

An article in Smashing Magazine lists many different options for charting in web applications. I've personally evaluated a lot of these and I settled on Fusion Charts and haven't been disappointed. It looks great, it's easy to code, and has a ton of chart types and features. And anytime I've had to use support, they've been extremely quick in getting back to me, which is impressive given that most of my support calls come at about 2 in the morning. Or maybe not so impressive, given that I think they're based in India. Either way, I highly recommend them.

On the same subject, there is one downside to doing Flash-based charts: printing. Maybe the user can print the full page in the browser and get the chart, but there's no good way to get it into a PDF without the user having to install additional software, e.g. CutePDF. I've looked for a server side component that will go from Flash to PDF. And I mean I've really, really looked. I tried in 2006 for days and got nowhere, then again a year later and still nothing.

Our solution was to use a separate server side charting package just for generating PDFs. It's not ideal - for starters we now have to maintain two sets of code per chart type. Also, it limits us on the server side technology; for example, the last time I checked Ruby did not have a very good charting package (although that was over a year ago and things change fast in the Ruby world). But I think it's worth the price to get the cool Flash charts and I wouldn't go back to a pure server side solution without a compelling reason.

Supply Chain Dashboard Tips

2007-10-23T08:20:00.000-07:00

Mike Brooks of Chevron has some opinions about supply chain dashboards in this Supply Chain Digest article:

Get rid of the clutter: most dashboard tools from vendors have all kinds of "overhead" on the screens that add confusion and make it difficult to find and focus on what's really important. "remove every pixel that doesn't show information" he said.

Pie charts, especially side by side pie charts, and "gauges," really don’t communicate data for decision-making effectively.

Work closely with users/execs to ensure the data is truly actionable

Visualization provides maximum impact, but again that doesn't just mean pie or bar charts.

Use very clear metaphors – for example, black means above plan, red means under plan. Gets attention very quickly.

Focus on trends, and key changes over time rather than absolute precision. You are not trying to satisfy the accountants, but improve decisions.

Make the navigation highly simple and intuitive. Strive for a "no nothing" interface.

Focus on "now," not historical data.

He makes some very good points. In particular, pie charts have historically been overused just because they look pretty. As Stephen Few points out, the areas within a circle are deceiving so they can lead to incorrect assumptions about the relationship between the categories. A bar graph is much better for comparing values. However, Few also suggests that a dashboard needs to be pleasant to look at without sacrificing usefulness and the one they use as an example needs a little work in that area. And I'd interested in learning what decisions an executive would make based on that dashboard.

He doesn't mention this directly, but drill-downs to the lower level are key to making the dashboard actionable. You need to know why something is the way it is to make a decision about it. A dashboard should almost be a navigational path telling you who to call. Service level/fill rate is down? Drill down to see where the problem is. Maybe a particular DC or product line is skewing the numbers. So call the DC manager or the buyer. They should have a dashboard that starts at the level that the exec's ends at. But they can drill down and see more specifically where the problem is. Could be that a shift at the DC is understaffed so the manager can work with the shift supervisor to balance the load better. Or the main supplier is low on a part so the buyer needs to source the item from another location. Every level can easily determine the action they need to take by seeing the right level of detail.

Overall, it's a good article and some good ideas to keep in mind while building dashboards or dashboard software.

Liferay Portal

2007-10-18T22:03:00.000-07:00

Check out this cool-looking open source portal server from Liferay. I played around with the demo a little bit and was impressed. It's definitely a developer tool but it has a lot of good ideas relevant to dashboard software.

Hyperion and SAS Vs. Best in Class

2007-10-14T22:26:00.000-07:00

Here's a quote from a research paper by Aberdeen where they compare best-in-class companies versus Hyperion. There's a similar paper for SAS. The links to each paper are below.

The hardest part of delivering information is making the underlying data available to all decision makers. It's not just the top-line information itself that driver performance; it is the detail behind it that provides the insight and understanding of how to take action.

I agree, but what I'm interested in knowing is how do you build the top-line information without access to the details? Somewhere, someone has to have aggregated the details to get those top-line numbers. I suppose in some organizations, the processes that perform that aggregation are separate from the dashboard software that presents those numbers. When I'm building dashboards for customers, the hardest part is usually that the underlying data is so inconsistent that the aggregation makes absolutely no sense. But starting with the high level and not having access to the details at all seems like it would be much worse because as the report said, the data is just not actionable without the details.

The other thing I found interesting in the Hyperion article is the high percentage of companies that use Hyperion but claim "an inability to integrate data from all sources", "lack of internal IT skill sets", and "lack of internal BI skill sets (business users)". I thought tools like Hyperion were supposed to solve those problems. I know Cognos can integrate data from multiple sources using what they call Data Federation. But if companies are failing in BI implementations due to lack of IT and business user skills, the end-user drag and drop BI tool must still have a long way to go. The report somewhat validates my assertion that a good dashboard requires real development, not just drag and drop.

Link: Hyperion Comparison
Link: SAS Comparison

Startup Bipolar Disorder

2007-10-12T00:37:00.000-07:00

I mentioned Founders at Work: Stories of Startups' Early Days in a previous post. This is my favorite quote from the book, I believe it was from the founder of Excite:

No, it was never clear that we were on to something huge. You never know anything. The hardest part in a startup is that you wake up one morning, and you feel great about the day, and you think, "We're kicking ass." And then you wake up the next morning, and you think "We’re dead." And literally nothing's changed.

Yep.

iDashboards

2007-10-10T20:31:00.000-07:00

Disclaimer: iDashboards would probably be considered a competitor to my company so take this for what it's worth. This is just a mild criticism of their website, not their product. Under the company page on their website, they've got a section called "10 Reasons Why iDashboards". It had it some decent points, although I've made it clear how I feel about the "no programming" thing.

Then I saw a link to "10 Reasons Why Not iDashboards" and I thought, this is cool, somebody who recognizes the sales concept of "going for the no", and isn't just assuming that their product is a perfect fit for every possible customer. Oops, I was wrong. It was just a list of 10 more reasons why to go with them, but inverted to turn them into a negative, like "You don't want cutting edge technology." or "You want to see the friendly faces of consultants for 6 to 18 months". Kind of like in an interview when you're asked what your biggest weakness is and you say "I care about my job too much" or "I work too hard". I'm sure they thought it was clever, but it came across as slightly egotistical to me. Their product looks like it has some really nice features, but if I were a buyer that page of their web site would be a turn off. I suppose it is possible that they were deliberately being tongue-in-cheek, but it's a fine line to walk.

Next post: 10 reasons not to read this blog.

Analysis of the SAP Business Objects Deal

2007-10-08T21:28:00.000-07:00

Some analysis of the purchase of Business Objects by SAP.

And more from this Computer World article:

"However, more than ever, there now seems to be a role for an independent BI/performance management vendor not tied to any database or applications company," Vesset said. "Informatica holds this place in the data integration market, and Cognos may be able to do the same in the business analytics market."

The question in my mind is when a large customer comes calling on SAP to integrate their best of breed applications (that don't include SAP), will Business Objects have the autonomy to do the deal like normal, or will the customer just get the big sales pitch from SAP.

This does seem like a good opportunity for Cognos, as the last of the big BI vendors that isn't tied to a specific ERP solution. How long will they stay independent though? And who's left that would buy them? Microsoft has already invested a lot of resources and money into their own BI solutions.

Infor? They are almost my former company. I worked for Dallas Systems which was bought by EXE which was bought by SSA which was bought by Infor - I left during the SSA buyout. Infor is one of the largest Cognos resellers and you can tell from the history that they're not opposed to a little M&A now and then. Maybe they're due for another large acquisition followed by an IPO followed by a private equity buyout followed by an IPO...