This is page 2 of:
Information Overload And Why Your Car Doesn’t E-Mail You
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.