The same number described two different pieces of equipment

In 2018 we combined equipment records that had been maintained in separate local contexts. I approved an import that used the local number alone as an enterprise identity. A selected review found 24 physical devices represented by 18 records. Six numbers had each been used for two different devices, so the import had collapsed six pairs. A battery and a charger could share a number without being the same item.

The immediate temptation was to treat the smaller register as a successful removal of duplicates. Roshan’s operating colleagues showed why that interpretation was wrong. The physical devices remained distinct, and their histories needed to remain attributable to the intended item. The import had made the data appear cleaner by discarding context. My approval belonged in the account because the software had implemented the assumption we had accepted.

We committed ₹37 lakh to an eight-week review. The work established distinct identities for the selected 24 devices and preserved their earlier references so that the repaired account did not erase the path from the local records. Qualified owners reviewed the operating implications. I did not claim that a corrected identifier made an item suitable for use or that the selected repair proved every equipment record complete.

The result was a register that could distinguish the physical subjects of the selected histories. It was not evidence of new equipment, an inventory gain or a technical safety approval. The six shared numbers explained why eighteen imported records had represented twenty-four devices; they did not establish a general error rate across the enterprise. The programme cost was the expense of correcting the design and selected account.

I changed the question I brought to integration reviews. Before asking whether fields match, I want the team to explain where an identifier is unique and what a receiving owner believes it refers to. A convenient match can be the wrong basis for combining records. The enterprise needs the physical distinction to survive the integration, even when preserving it makes the resulting system less superficially tidy.

The selected 2023 exercise contained 32 operating handover events. Twenty-four were recorded online and eight were recorded during a period of disconnection. When connectivity returned, the eight records still described events that had already happened. Their arrival in the central application could not responsibly be interpreted as another set of physical handovers or as a fresh instruction to repeat the work.

I worked with Roshan’s team to define the fallback and reconciliation responsibilities before judging the technology. Operating owners decided which activities could continue under the exercise conditions. IT supplied the means to retain the account and bring it back into the central record. The distinction mattered because a successful upload answered a technical question while the operation needed confidence about what had already occurred and what remained to be reconciled.

We committed ₹47 lakh over ten weeks to the exercise and the supporting changes. The selected eight disconnected events were reconciled with the twenty-four online events without representing additional physical activity. The resulting account therefore described thirty-two events, not forty. We retained the distinction between the time of the handover and the later arrival of its record. The work did not assert that every future disruption could be handled through the same fallback.

The outcome was a tested arrangement for a defined situation. It did not transfer dispatch or equipment-suitability decisions into IT, and it did not prove that restored connectivity resolved every consequence of an interruption. An operating owner could still need to examine a particular event or decide that work should remain stopped. I wanted that possibility preserved rather than hidden by a successful technical status.

The lesson was about the meaning of recovery. Bringing records into one application is useful only if the account remains faithful to the activity it describes. A system that reconnects but invents another handover has recovered its connection at the expense of the operating truth it exists to support.

In 2025 we rehearsed a proposed supplier exit against twelve agreed business functions in a replacement environment. Ten ran as intended. Two still depended on supplier components. The export had produced files, but possession of those files did not establish that the enterprise could perform the full agreed scope without the existing arrangement.

I resisted describing the first rehearsal as a completed exit with minor follow-up work. The two functions were part of the scope the business had agreed to test. Ajay and the operating owners needed to understand the dependency before deciding whether the transition was acceptable. The supplier also needed a specific account of the missing capability rather than a broad assertion that the export was inadequate. The issue concerned what the receiving environment could actually do.

We funded ₹63 lakh over twelve weeks to resolve the dependencies and repeat the exercise. The work included the appropriate agreements and implementation changes, with the accountable owners reviewing the resulting capability. At the subsequent rehearsal, all twelve functions ran under the agreed conditions. I kept that scope attached to the result instead of extending it into a claim that the enterprise had eliminated every supplier dependency or could withstand any disruption.

The outcome gave management a more useful basis for the particular transition decision. It did not prove that every future version, operating volume or exceptional process had been tested. The ₹63 lakh was programme expense, not a quantified saving from a completed commercial change. We had demonstrated the agreed functions in a receiving environment and made the earlier gaps visible before relying on them.

I now want exit discussions to begin with the work the enterprise must be able to perform, then follow that work through data, components, agreements and receiving responsibilities. An export is one part of that path. It should not become a substitute for the business capability whose continuity made the exit question important in the first place.