Chief Information Officer / India
Keep the subject intact when the context changes
I want a cargo operation to recognise its equipment, reconcile interrupted work and leave a technology supplier without losing the system it thought it owned.
01
Keeping physical identity intact across a shared register
Combining records is not merely a matter of finding matching fields. I ask whether the identifier is unique in the new context and what the operating owner needs to distinguish. In our selected equipment review, six local numbers each belonged to two different devices. The import I approved had collapsed 24 physical devices into 18 records. The repair established distinct identities and preserved the earlier references needed to interpret history. It did not establish technical suitability. Roshan and qualified owners retained decisions about equipment use. I want the design review to follow a record into the physical operation before treating a convenient number as an enterprise key. The useful outcome is an account that refers to the intended item without losing its earlier context, not a smaller register that only appears to have removed duplication.
02
Reconciling disconnected work without inventing a second event
When connectivity returns, the system must distinguish an event that has already happened from a new instruction or physical action. Our selected exercise included 24 handover events recorded online and eight recorded during disconnection. The later upload of those eight had to join the account without representing another handover. I worked with operations on the meaning of the record, the controlled fallback and the reconciliation responsibility. The ₹47 lakh exercise lasted ten weeks and tested a defined group rather than proving every outage manageable. Operating owners decided what work could continue and under which conditions. IT supplied the means to retain and reconcile the account. The aim is to preserve the event through a disruption without using a restored connection as evidence that every operating consequence has also been resolved.
03
Testing the business capability behind a supplier exit
A data export can succeed while the enterprise still lacks a function it needs to operate. I want an exit rehearsal to test the agreed business scope in the receiving environment, including dependencies that remain with the supplier. Ten of twelve functions worked in our first rehearsal; two depended on supplier components. We kept those gaps visible and funded the work needed before retesting. The eventual twelve-function result applied to the rehearsal conditions, not every possible incident or future change. My role includes making the technical and contractual dependencies understandable to the chief executive and operating owners. I do not describe the possession of files as independence. The useful question is whether the enterprise can perform the work it agreed to test, and what still needs another party before that claim is credible.
04
Making system evidence useful without claiming operating clearance
Our information function can improve the identity of an item, the record of an event and the portability of a capability. Those improvements do not give IT authority to determine vehicle suitability, charging practice or whether an operating activity should continue during disruption. I work with Roshan and qualified owners to preserve that boundary in the system and the management account. Three leads coordinate 23 IT colleagues, but the size of the function does not change the decisions assigned elsewhere. I want a complete technical result to be described with its actual meaning and limitations. This is especially important when a repair looks successful: unique records, successful uploads and functioning exports are useful evidence, but each can encourage a broader conclusion. The system should support the accountable owner’s judgement without silently replacing it.
A leadership conviction
A system earns trust when its meaning survives a handover. The next person should know which physical item the record describes, which event has already happened and which capability still depends on somebody outside the enterprise.
Start a conversation ↗