When a correction is slower than the next order

Take one object you know is wrong — the label on a pump, the level it hangs under, the date it was moved. Write down the steps between the person who saw it and the person who may change it. Who is told. Who agrees it. Who holds the authorisation. When that person works through their queue. Put a number of days on each step, and where nobody knows the number, write that down too: a step whose length nobody can say is the step the route is waiting on.

Now count the orders closed against that object over the last twelve months and divide the year by that number. That is the interval you are racing.

Say the route takes thirty days and an order lands every fortnight. The correction still arrives. It arrives behind two more orders booked against the object as it was wrong, and their confirmations and costs are now part of the history of the wrong thing. Nothing failed. Nobody was careless. The register lost anyway, on lead time.

That is also why one register can describe one area of a plant well and another badly. The route is the same length everywhere; the traffic is not. The objects that go wrong fastest are the busiest ones, which are the same objects your reporting is built on.

So sort your open corrections by how often work is booked against the object, not by how long they have been waiting. The oldest one on the list may be on a machine nobody has touched since go-live, and it can wait another month without costing you a single record.

Reporting is deliberately broad: anybody who can see the plant can say what they saw. Changing the register is deliberately narrow, because a hierarchy anyone can edit is a hierarchy nobody can rely on, and because one wrong master-record field is wrong in every report that reads the object.

A change to a technical object's master record is normally kept as a change document — which field, the old value, the new one, who and when. Field-level logging is set per field, so confirm the field you care about is included before you promise anybody an audit trail. Where it is included, the corrections that went through the people holding the authorisation are the ones you can still explain next year. The ones that went around them are not.

So the answer to a slow route is not more authorisations. Give the change to whoever is standing at the object and the register gets fixed the way each of them would have fixed it: three spellings of one unit, two places for one machine, and a structure that records who was on shift rather than what is there.

What needs fixing is the routing, not the permission. The person who found the error has one job — turn it into a record. Somebody else has the job of clearing that queue, and that somebody has to be a role rather than a name, because people move and the queue does not.

The person who finds the error can raise a notification against the object. That costs them a minute, and it produces the four things a route needs: which object, what was seen, who saw it, and the date.

A message in a chat has none of those. It also cannot be counted, so nobody can answer whether the register is drifting faster this year than last.

Give the data error its own notification type. Filed as a malfunction report it reads as a fault on the machine, and a register error is not one. Notification types are set up once; the person reporting then picks one, which is the cheapest moment to separate what is wrong with the machine from what is wrong with the record of it.

Its own type also hands you the measurement. A notification carries the date it was reported and, once it is completed, the date it was completed. The gap between them is your correction route, in days, for every correction anybody raised — not an estimate of it, the distribution of it. That is the number to put in front of whoever owns the register, and it comes out of records nobody had to keep specially.

When the route is slower than the work, people do not wait. They book the order to the object they can find. They create a new object for the machine in front of them. They keep the real structure in a spreadsheet and copy numbers across.

Each of those is cheaper for them than waiting, and each leaves the register worse off than the wrong label did.

The new object is the expensive one. Two objects now describe one machine. Both carry notifications, both carry orders, both look alive. Counting the objects with nothing booked against them will never find either of them, because neither is empty — a duplicate is the one kind of drift that test cannot see.

Finding them takes a different question: two objects at the same place with near-identical descriptions, or one machine whose failure history stops on one object in the same month it starts on another. Somebody has to ask it once and then keep asking it.

And the seam is permanent. Once a machine's history is split across two objects, no later correction rejoins it. The orders stay where they were booked.

Correcting master data changes the object from now on. It does not move what was booked against it.

An order that names an object keeps naming it. Yesterday's order still names yesterday's object after you have corrected the register, and it should: an order is a record of work that was done, not a description of the plant. One that has been confirmed and completed is closed, and reopening it to point it somewhere else is a decision about a document rather than a correction to a register.

Equipment is where this gets missed, because a location looks like a field and is not one. Where a piece of equipment has been is a run of installation periods, each with the date it began. Correct a move that happened last month by installing the equipment today and the record says it arrived today: last month's orders and last month's failures stay at the old place, and the weeks in between belong to nobody. The correction is two dates, not one — dismantle it at the day it actually left, install it at the day it actually arrived — and a back-dated install over a period that is still open is the part that will fight you. Everything else is only the current state.

So every correction leaves a seam, and the seam has a date. Anybody comparing two years of cost or failures across an object has to know where the seams are, or the comparison measures your corrections instead of your plant. Write the date where the next person will find it — on the object, in the notification that reported it. A seam nobody recorded is indistinguishable from a machine that got better.

One route for every correction is what makes the route slow. A spelling in a description and a level in the hierarchy are not the same change, and a gate heavy enough for the second is what stops the first.

Split them with one question: does anything already booked depend on it?

Everything in the first row should be correctable by the person who found it, in the same week. Everything in the last row needs somebody to say what happens to the history — which is a decision rather than an approval, and it is the one worth a meeting.

If that split was never written down it still exists. It is whatever the authorisations happen to allow, arrived at by whoever was given them. Reading it back off the authorisations is slower work than agreeing it would have been, and it ends in the same document.

The test after go-live is not whether the register was right at go-live. It is whether a wrong object can be made right before the next order is booked against it.