An emissions figure with two decimal places inspires confidence. But precision in the presentation says nothing about the reliability of the source. A spreadsheet that sits three manual retypes downstream can just as easily display two decimal places as a figure that comes straight from a validated system. The difference does not lie in how the figure looks, but in what has been recorded about where it comes from and what counts as a valid value.
False precision arises when a number radiates more certainty than the underlying data justifies. This does not happen through bad intent. It happens because nobody has recorded the boundaries of a data point: which values are plausible, which deviations are normal, and which should trigger a signal. Without those boundaries, every number looks equally credible, including the number that is a typing error or a wrong unit.
The question what is a valid value should therefore be answered for every data point, not afterwards during a sample check, but beforehand, at the moment the data point is recorded. A valid value is not just a number within a range. It is also a unit that is correct, a period that matches, and a source that is known.
A quality rule does more than approve or reject a value. It also determines when a deviation should become a signal. Energy consumption that is twenty percent higher than last year could be an error, but could also be a genuine expansion. The rule itself does not establish what happened; it establishes that this type of deviation deserves review before it flows onward.
How do you set up a deviation signal is therefore a different question from what is a valid value. One question concerns the boundary of acceptable, the other the boundary of noteworthy. Both boundaries are needed, and both should be recorded per data point, not as a general rule of thumb for the entire report.
A signal that nobody sees is not a signal. This is the point where many data structures stop: the rule exists, the deviation is detected, but it has not been recorded who receives the notification and what that person should do with it. Without ownership per data point, a signal disappears into a list that nobody reads through, or it ends up with someone who does not know the data point and therefore cannot assess it.
Which controls belong to a data point therefore covers not only the rule itself, but also the route: who the owner is, when that person receives a notification, and what happens if that person does not respond. A data point without an owner is a data point where nobody except the end user of the report will ever notice that something went wrong, and by then it is too late to address the underlying cause.
There are tools that detect deviations and display dashboards. Those tools are useful once the rules are in place. But a tool running on a data point register without recorded valid values, without signal definitions, and without assigned owners mainly produces notifications that nobody can interpret. The question buy a tool first or set up the process first applies directly here: a tool placed on top of an unorganized process changes the shape of the problem, not its substance.
The same applies to definitions. If two parts of the organization use a different understanding of the same data point, then a quality rule for one part will produce a false signal for the other. What do you do with definitions that differ per unit and which choice do you record should therefore be answered in advance, otherwise every rule becomes a compromise that does not fit anywhere properly.
Valid values, signals, and ownership are not something determined in general and then applied everywhere. They follow from how an organization actually records the data point, who can access it in practice, and which errors have occurred in the past. Which functional requirements come from your own process describes how those rules are derived from the existing process rather than from a generic checklist.
Once it is clear which values are valid, which deviations form a signal, and who reviews that signal, a view also emerges of the work behind that control: who looks up data, who compares against previous periods, who forwards the notification. That work consists of tasks that can be broken down, and for part of it, it can be determined whether software can take it over. The work scan from FTE TO AI calculates, per task, what portion of the work can be taken over by AI, based on the same recorded rules and routes that underpin data quality.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.