Kennisbank

When does a register across multiple business units count as complete

A register for one business unit gets finished at some point. The data points are in it, each with a source and an owner, and the definitions have been tested. With multiple business units, the question changes. It is no longer about whether one list is complete, but whether the lists together add up to one picture of the organization.

That is a different kind of work than adding more rows. The pitfall is thinking that a register is complete as soon as every unit has filled in its own table. Four full tables with four different definitions of the same data point do not produce a register, but four registers that happen to lie next to each other.

What should be in the register per business unit

Per unit the same basic work repeats itself: which data points are needed, where do they come from, and who is responsible for them. That starts with the question which data points do you really need, because a unit that registers too many data points mainly accumulates maintenance burden without the reporting getting any better.

For every data point that remains, the same question must be asked: does this already exist in a system, or does it still need to be requested. The page about where a data point already exists describes that investigative work. With multiple business units the answer often varies: unit A already has energy consumption in a facilities system, unit B still keeps it in a spreadsheet managed by one controller. That difference must be visible in the register, not disappear behind a uniform column that says 'present' everywhere.

Where it often goes wrong: the same name, a different definition

The biggest risk with multiple units is not that data points are missing, but that they are present under the same name while measuring something different. 'Water consumption' may cover only the head office at one unit and also the production hall at another. 'Number of FTE' may be counted with or without temporary staff. As long as that difference is not identified, no one adds up the problem until the moment the figures need to be consolidated for the combined report.

A register that solves this records the definition of each data point at the organizational level, and then shows per unit whether that definition has also been applied that way. Where that is not the case, it is listed as an open point in the register, not as a silent assumption. The structure for building this is described in how do you set up a data point register, and that order does not change when there are multiple units: first record the data points and their definitions at the organizational level, then fill in per unit what already exists and what is missing.

Missing sources are everywhere, not just at the smallest unit

The assumption that only the smaller or less mature units have gaps in their sources is rarely true. A large unit with an extensive ERP system can rely on a manual count for certain environmental data just as much as a small site. The share of data points without a solid source depends on the subject and on how long a unit has already been working with these figures, not on the size of the unit. How many of your data points have a source is therefore a question that must be answered separately per unit, see how many of your data points have a source. Only once that is mapped per unit can something be said about the whole.

Data points without a source do not disappear from the register because they are uncomfortable. They get a status and a next step, described under what do you do with a data point without a source. With multiple business units it is wise to compare this status between units: if three of the four units have a source for a data point and the fourth does not, a solution is usually within reach at those three units, rather than the fourth unit having to reinvent the wheel.

When the register is correct

A register across multiple business units is correct not because it looks complete, but because three things are true at the same time. First: every data point has one definition at the organizational level, and that definition has been applied the same way at every unit, or the difference has been explicitly recorded. Second: for every data point it is clear per unit whether there is a source, and if not, what the status is. Third: ownership is assigned at the level where the knowledge actually resides, not automatically with the unit's highest manager.

How long this work takes depends on the number of units, the number of subjects and the state of the underlying systems; an estimate of that is described in how long does it take to get a subject in order. That is not a fixed timeline, but a sum of the work that still needs to be done per unit and per data point.

Bringing these registers together, tracing definitions back and comparing sources per unit is largely repeatable work: the same questions, applied again and again to a different department or a different data point. Which part of that can be taken over by AI and which part remains human work is exactly what the work scan of FTE TO AI was made for: it calculates per task how much room there is to speed up this kind of register work, without the outcome becoming dependent on assumptions that no one has checked.