From data to decisions: reports and dashboards you can trust

In the previous lesson we covered how to handle change requests and vendor upgrades so the system stays understandable over time. By now you have a stable, connected system running every day, and inside it the data of every order, every invoice, and every stock movement keeps piling up. That raises a question most businesses ask far too late: how do we turn all this data into decisions? The usual response is to ask the vendor for dozens of reports, and then nobody opens most of them. In this lesson we look at how to build reports and a dashboard you actually trust and actually use.

Why reports go unread

When reports stop being used, the reason is usually one of three. First, the report does not answer a clear question, so it is a tidy table with no obvious next step. Second, nobody owns it, so it goes to everyone and is opened by no one. Third, and most damaging, the numbers do not match what the team sees on the ground, so the report loses its credibility once and never gets it back. None of the three is fixed by adding another report; each is fixed upstream of it.

Start from the question, not the report

Before requesting any report, write its question in one sentence, then write the decision that will be made from it. If you cannot write the decision, the report is not needed. A question like "which customers are past their agreed payment terms?" leads to a clear decision: pause credit sales or start collection. A request like "I want a comprehensive sales report" leads nowhere, because there is no question in it.

Three levels of reporting

Not all reports serve the same purpose, and merging them into one giant report is exactly what makes them heavy and unreadable. Separate them like this:

A concrete example

Take a building-materials distributor selling on credit. The owner used to request a long monthly statement of every transaction, and never read it. They changed the arrangement: the sales clerk now opens a list of undelivered orders every morning; the department manager receives a Monday report of orders whose preparation exceeded the usual time; and the owner receives, on the first of each month, a single page showing collected versus outstanding amounts and a list of overdue customers. Three short reports replaced one long statement, and each has exactly one reader and one decision attached to it.

Before you trust a number: define your terms once

What destroys trust in reports is usually mismatched definitions, not a system error. What does a closed order mean: when it leaves the warehouse, or when the customer receives it? Are sales counted before or after tax? Does a return get deducted from the month of sale or the month of return? If every employee carries their own definition, you end up with three correct and contradictory numbers at once. Agree on a written definition for every term that appears in your reports, keep it in the same place as your documented procedures, and revisit it whenever the procedure changes.

Dashboards: short and understandable

A dashboard is not the place for everything the system can calculate. Keep it to five to seven indicators, each with an owner who can answer for it and a reference point to compare against, such as last month or an agreed target. A number without a reference means nothing: knowing you have late orders this month tells you little unless you know how it compares with last month. If an indicator goes three months without changing a decision, remove it; it distracts from what matters.

Checklist before you adopt a report

• What question does it answer, in one sentence?
• What decision will be made from it?
• Who is the specific reader, and when do they receive it?
• Are the definitions of its terms written down and agreed?
• Have its numbers been reconciled at least once against an independent source?
• What happens if it is not issued this month? If nothing, drop it