Last Chance for Gas

Imagine that every time you began to drive your car, you received a 50-page printed report. It would give information on the characteristics of the gasoline, the place of origin, its evaporation point, the price paid for the gas this year versus the price paid last year, political influences on petroleum prices, and the percentage of the auto’s operating costs represented by fuel. That would be the start. But what the driver really wants to know is how much gasoline is in the tank and how far the car can get on that amount. And, if there were some nifty link between the gas tank and a GPS system, there should be a trigger that would bring up directions to the nearest gas stations once the fuel level dropped to a critical point. Reports from software systems are a lot like this—There’s all sorts of detail when all the user wants to know is how much gasoline is in the tank. The other problem is that the report is usually delivered after the car is out of gas. Users want to know when things are going wrong and how they can make things work better. Talking to practitioners about workflow software repeatedly brought up the point that they would like dashboards that enable them to know the status of returns, and who has them. Executives everywhere want reporting by exception, not stacks of reports, so that they can make corrections before things go wrong. It’s like the warning a car gives when the gas levels drop, usually to about one-eighth of a tank. Easier said than done, of course, because it takes more sophisticated systems to get finer control over an operation than it does to generate reams of small print. And that’s why the history of computing, until recently, has been about killing trees. The need for conserving the environment aside, simpler, more understandable reports in real time is what business needs—unless you just like reading reports. Or don’t like trees.