Most of the data created, harvested and consumed in business is worthless. In fact, millions of dollars are wasted every year creating systems to deliver information to people who do absolutely nothing with it. Hundreds of reports have never been clicked, thousands of automated E-mails have never been read and millions of sheets of paper are (hopefully) recycled without even so much as a glance. The next time someone tells you he or she needs more data to do a job, ask that person point blank: "If you were given this additional data, what would you do with it?" In my opinion, people actually need less data.
I have spent a lot of time in recent months contemplating and designing an Information Architecture for Focus Brands. As a result, I think IT systems should be designed from the ground up with an understanding of the information supply chain, as in "What groups/people will need access to the data entered into or created by this system?" Through this process, I have come to realize that one precursor to an Information Architecture is an Action Framework. Basically, it's not enough to think about who may need access to this data; rather, it's critical to understand what, if anything, they intend to do with it.
Why is this distinction important? First, it's not uncommon for people to want data because they believe it provides information that it actually doesn't. It's also important to understand how this information will be consumed. Will it be raw data fed into another system? Will it be displayed through an executive dashboard? Will it be referenced by someone in a functional role as part of an established business process? Will it be used strictly as reference for historical purposes?
As an example, let's look at cars. For decades, production automobiles had a single light on their dashboards that said "Check Engine." That single light was the "alert" interface between the driver and a complicated system called the internal combustion engine. If any one of the dozens, if not hundreds, of components had an issue, the light would illuminate to inform the driver that action was required. The problem could be something as small as low fluid to something as large as "this thing is about to spit a piston through the hood if you don't turn it off."
The simplicity of the interface was part of its elegance. To drive a car, you didn't need to know how an engine worked. Instead, you simply had to find someone who did once that light came on.
Now imagine if your car E-mailed you a report on the performance of all its parts and sub-systems after each time you drove it. This information is critical to the engine's operation, but it would be absolutely meaningless to you. Reports like these are created every second of every day in the business world.
In the business world, think of the gauge as a dashboard. The system is so complex it doesn't make sense to expose its detailed information to a user. Rather, the system merely needs to indicate there is a problem to those who do not necessarily need to understand the details of that problem. In today's world, we expose so much information to users that none of it is valuable.
(Editor's Note: That car gauge is a pet peeve. How about replacing it with a series of lights showing severity, like the DEFCON indicators? Red for urgent; yellow for "soon, but it doesn't have to be today"; orange for "within a month"; etc. That approach would still shield users from a lot of data they may not understand, but it would also let those users better decide what to do and when to do it.)
We recently deployed a new back-office inventory and labor management system in one of our brands. This is a complex system that ties our POS to inventory and labor management systems to better help operators manage their business. Literally hundreds of reports are available with this tool. It was one of the vendor's selling points. The new system can show everything sold in the restaurant. It can show all the cases of food ordered from the distributors and how many hours each person worked and when. It can slice and dice the data in a million different ways.For all those hundreds of reports, however, the one thing that isn't included: How to save money on inventory and labor.
In this case, the data is placed into a series of detailed reports that a restaurant operator must read and then take additional action to achieve the desired result: saving money. In other words, the operator has to use this information to take additional action to save money.
Here's an example: The tool can tell you that your theoretical inventory shows there should be three more cases of chicken in the restaurant than are physically present. However, it cannot tell the operator where he/she should look to find out what happened to the missing chicken. If the operator were to use this information to discover that the crew was over-portioning because of poor training, then the operator can take action to correct the issue (fix the training), which will result in savings.
In this example, not knowing how the information will be consumed (Action Framework) will result in a largely inefficient use of time and resources. Instead of a 15-page report filled with mostly irrelevant data, wouldn't it be better to provide a dashboard that shows an alert (check engine light) that then provides a link to the operations manual section on managing (Action) food-cost variance?
Because we purchased an off-the-shelf product, the vendor did not know what our Action Framework was. As such, so the best the vendor could do was create a comprehensive Information Architecture it thought would be usable in the most situations (customers). But in doing so, the vendor diluted the value of the tool itself. This situation is the equivalent of your car sending you an E-mail about its performance.
Here are some of my recommendations for creating your own Action Framework:
- Less is more. Challenge yourself to drastically limit the information presented to users. Educate the users to the advantages of a low-information diet (better, more relevant information).
- Beauty is in the eye of the beholder. Information that is critical to one person may only be interesting to someone else. Make sure you identify and document all critical information (and its associated audience).
- Too many cooks is a problem. There are typically many different ways to solve a problem. That translates into many different ways to show the same data. Just because different people want to show the data differently, doesn't mean you should do it. Consult with the various people to determine if a standard can be set. Be pushy. If your organization doesn't like to set standards, explain to them the cost impact in DBA salaries.Drill-down is OK. Some people and some business processes will require a deeper level of detail. Building a system capable of drilling into more information is OK, but make sure users don't start there.
- Adapt an information trade-in policy. Ask users to give up five pieces of information for every new one they request. Get the users thinking about a low-information diet.
- Straight-to-video isn't just for bad movies. If people want to have access to data for historical reference or "just in case", then push the raw data into a database for later retrieval. Do not create reports for problems you haven't had yet and may never have. It's a waste of time and money.
- Analytics is not a business process. One of my co-workers used to say that with business intelligence systems, the third question someone asks is the most powerful. The idea is that while investigating one piece of information, you are lead to another and then another. It's not uncommon to find significance in something you weren't even looking for. Although I am advocating a low-information diet, that doesn't mean you have to restrict the people who truly need information for analytical purposes. Their requirements will be different from those who simply need the information as part of a standard business processes.
I think too much data is out there. What I really want is information that will help me make decisions and take action. I want the overwhelming glut of data being produced boiled down to a few critical pieces of information that will help me. That's it. I want it to help me. I think our users want the same thing (even if they don't know it yet).
Term Of The Week: "Rublish"--spending a significant amount of time creating and publishing documentation that 95 percent or more of the intended audience will not read. "We spent the last two weeks of the project working on a bunch of rublish for the intranet."
What do you think? Leave a comment, or E-mail me at [email protected]. You can also follow me on Twitter: @todd_michaud.
You can follow my Ironman training at www.irongeek.me.