A signal deviation is a rule that says: if this value falls outside this range, then there is something someone needs to look at. That sounds simple, but the question breaks down into three parts that need to be answered separately. What is a valid value. What is a deviation from that value. And who gets visibility into it. Without these three, a signal is nothing more than a number sitting somewhere.
You cannot define a deviation without first knowing what is normal. For energy consumption per location, that is a range that depends on floor area, opening hours and season. For a headcount, it is a range that depends on the size of the unit. That bandwidth must be established per data point before a signal has meaning. How you determine and establish that bandwidth is described at what is a valid value and who notices when it goes wrong. Without that step, you are setting a signal on a value that has never itself been tested, and then you are not really signalling anything.
A signal can respond to different things. There is the hard limit: a value that falls outside a physically or logically possible range, such as a negative number of employees. There is the soft limit: a value that lies within what is possible but deviates strongly from previous periods, such as a doubling of water consumption without a clear cause. And there is the comparative deviation: a value that deviates from a comparable unit, such as a location reporting three times as much waste as a location of equal size. Each of these three requires a different rule and a different kind of source data to compare against. An intermediary who only looks at the most recent value often only sees the first kind. The second and third require you to have historical or comparable data within reach, which is a reason to take this into account already when setting up the data point register.
A deviation that lands nowhere is not a signal but a log entry. For every signal, it must be established who the first recipient is: that is usually the person who supplies the data point, not the person who compiles the report. The supplying department can check a cause while the reminder is still fresh. By the time of the reporting deadline, that context has often disappeared. In addition, it must be established what happens if the first recipient does not respond: does the signal move on to a second person after a period, or does it just sit there. This question is directly connected to the ownership you established earlier per data point, and to the controls that apply to that data point — see which controls belong to a data point and who notices when for how signalling and control connect to each other.
A deviation can be an error, but it can also be a genuine change: a merger, a new location, a changed reporting year. A signal rule that does not allow for that distinction leads to two problems. Users who receive too many false signals will, at some point, ignore all signals. Users who receive too few signals miss precisely the deviation that does matter. Both are a form of false precision: it looks as though the system is watching, while in practice it no longer filters anything. How you prevent that when setting thresholds is described at how do you prevent false precision. Part of the solution is requiring a reason when dismissing a signal: not to check who did something wrong, but to see whether the threshold itself needs to be adjusted.
A signal rule that is identical across the whole organisation overlooks the fact that units sometimes work with different definitions of what they measure, even when the data point is called the same everywhere. A location that defines scope 3 emissions more broadly than another will show different values without anything being wrong. A signal rule that does not take this into account produces false deviations in every comparison between units. At what do you do with definitions that differ per unit you can find how you record that difference so the signal rule can take it into account instead of confusing it with an error.
Setting a signal deviation does not require software; it requires that, per data point, you know what is valid, what counts as a deviation, and who sees it. That is exactly the kind of work the Data Readiness Scan maps out: the data point register, the associated quality rules and the ownership, so that a signal can rest on something instead of on a loose formula in a spreadsheet. The scan itself is under development; anyone who wants to get started with this now can sign up for the waiting list.
Once that structure is in place, a follow-up question arises: who should look at these signals daily, and which part of that control work is repetitive enough to hand over to a machine. That question does not belong on this page, but on the work scan of FTE TO AI, which calculates per task which part of the work can be taken over by AI. For reviewing routine deviations, following up on a cause with a fixed group of data suppliers and keeping a signal log, that is often a relevant question.
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.