The Data Operations Self-Audit Twenty questions that show where your pipeline leaks
Work through these on your own systems. Most businesses find three or four uncomfortable answers, and the uncomfortable ones are the whole point — they are where the time and the money are going.
- Answer for the system you actually run, not the one you plan to run.
- "I don't know" is a real answer and it counts as a no. Not knowing is itself the finding.
- Do it in one sitting. It takes about twenty minutes and the value is in the pattern, not any single answer.
1. Capture — does the data get in cleanly?
Every downstream problem starts here. Data captured badly cannot be cleaned reliably, only corrected repeatedly.
Is every field on your main forms actually used by something downstream?
Unused fields get filled in carelessly, and that carelessness becomes the habit for the fields that do matter.
Is the same entity — customer, supplier, job, site — written the same way everywhere?
One name per thing causes more wrong answers than any other single defect, and it is invisible until someone counts.
Is data entered once, or typed into a second system by a person?
Every rekeying step is a guaranteed error rate and a guaranteed delay. It is also the easiest thing on this list to remove.
Can bad data be entered at all — a date in the past, a negative quantity, a blank required field?
If the answer is yes, you are relying on discipline where a constraint would do the work permanently.
2. Trust — do people believe the numbers?
An untrusted number costs more than no number, because the work gets done twice: once by the system, once by the person checking it.
When a figure is shown in a meeting, does anyone verify it before acting?
Verification behaviour is the clearest signal a reporting layer has lost trust. It rarely gets said out loud.
If two systems disagree, does everyone know which one is authoritative?
If that knowledge lives in people's heads rather than in writing, it will be wrong the first time it is used by someone new.
Can you say exactly what your key figures include and exclude?
Half of all reporting disputes are definitional rather than numerical. An undefined metric is an argument waiting to happen.
Does every report show when it was last refreshed?
A correct number of unknown age is not information. This is usually the single highest-value missing element on a dashboard.
3. Time — how much is it costing to produce?
This cost is never on a budget line, which is exactly why it persists for years.
Does anyone rebuild the same report every week or month by hand?
Anything a person repeats on a schedule is a process, and a process a person executes by hand is one nobody automated.
How many hours a week go into producing reports, across everyone?
Count for one week with a tally rather than estimating. The total is almost always higher than expected, and the total is what justifies fixing it.
Does your month-end number arrive while you can still act on it?
The value of a figure decays fast. The same number is worth a great deal on the day and almost nothing four weeks later.
If the person who produces the reports were away for two weeks, would they still appear?
Key-person risk in reporting is the most common serious data problem in businesses under two hundred people, and it is rarely on a risk register.
4. Reach — does it get to the decision?
A correct answer in the wrong place, or at the wrong time, is not an answer.
For each report, can you name the person who uses it and the decision it changes?
If either answer is vague, the report will not be used, and no amount of build quality changes that.
Does the information reach people where the decision actually happens?
A dashboard that lives in a tool people open when they remember is a dashboard for a decision nobody was making at that moment.
Can the people who need it see it without asking someone?
Every request routed through a person is a delay and a queue, and it means the real reporting system is that person.
Does anyone see data they should not?
Row-level access is the thing spreadsheets fundamentally cannot do. "They shouldn't look" is not an access control.
5. Resilience — what happens when it breaks?
Everything breaks. The question is whether you find out from your monitoring or from a client.
If a scheduled job failed tonight, would anyone know tomorrow?
Silent failure is the worst failure mode: the report still appears, with yesterday's data, and nothing looks wrong.
Is there a file whose loss would genuinely hurt the business, sitting on one person's machine?
The joke everyone makes about that spreadsheet is the symptom. It is nearly always a real, unregistered risk.
Has anyone ever restored from your backups, rather than only taking them?
An untested backup is a belief, not a backup. The first restore should never be the one that matters.
When a number turns out to be wrong, is there a record of what changed and when?
Without history you cannot answer "was this always wrong?", which is the first question anyone asks and the one that decides how much to re-check.
How to read your answers
There is no score. A total out of twenty would flatten the one thing that matters, which is WHERE the answers cluster.
Count the noes and the don't-knows per section. One section with three or four is a specific, fixable problem and it is where to start. Spread evenly across all five is a different situation: it usually means the underlying data is the constraint rather than any one process, and starting with a dashboard would be starting in the wrong place.
If your noes are concentrated in Resilience, do those first regardless of everything else. Those are the ones that turn into a bad day rather than a slow month.
Have the 20 questions sent to you
A formatted copy you can keep, print, or work through with your team. Everything above is already on this page — the email is for convenience, not for access.
Let's find your best path forward.
Book a strategy call. We'll talk through your goals and where your data can take you — no pressure, no jargon.