The terminal could identify location without identifying a person
In 2024 we reviewed 120 entries made through shared factory terminals. Forty-four could not be attributed to an individual from the records available. We could identify the terminal and its common login, but those facts did not establish the person who had made each entry. The result exposed a limitation in our account of the work. It did not establish that forty-four people had acted improperly, or that the entries themselves were necessarily wrong.
That distinction shaped the response. If we had presented the finding as misconduct, we would have converted missing evidence into an accusation. If we had dismissed it because the entries looked plausible, we would have ignored a real accountability problem. The enterprise needed to understand who had performed an action and what authority that action represented. The available record could not always answer the first question, and it was important not to pretend otherwise.
We funded a ₹48 lakh identity and usability programme. I wanted the operating setting to be part of the work from the beginning. A shared factory terminal is used within a sequence of tasks, handoffs and shift changes. A procedure that works conveniently at an office desk may not fit that sequence. The review needed to understand how people actually approached and left the terminal, and what made the intended practice workable.
This was not an argument for abandoning individual accountability when work became inconvenient. It was an argument for designing it with enough knowledge of the work that people could follow it reliably. A control can look complete in a specification while encouraging sharing or shortcuts in use. The CIO should be interested in that gap, because the resulting record may later be used to support an important management conclusion.
Recording an action and authorising it are different responsibilities
Individual attribution would still not answer every question. The person who enters a record may be recording an event, requesting an action or carrying out a step that requires someone else's approval. Attaching a name to the entry does not by itself establish that the person had authority to approve the resulting commercial or operating consequence. We needed to preserve that distinction in the process rather than let identity become a substitute for the approval rules.
The relevant process owners therefore had to participate. IT could help establish how a person was recognised and how the action was recorded. Operating and financial owners had to explain what the action meant and which decisions it was permitted to make. A useful design connects those accounts. It does not require every participant to understand every technical detail, but it does require the enterprise to know where responsibility changes.
The sample also needed careful interpretation. Forty-four unattributable entries out of 120 reviewed entries described the selected record set. It was not a count of fraudulent transactions, a count of distinct people or a measurement of every terminal in the company. A later assessment could examine whether the programme had improved attribution under its own stated conditions. The approved budget could not establish that improvement before the work was tested.
I wanted the report to remain intelligible to colleagues who were not identity specialists. They needed to understand the practical question: when the enterprise later relies on this record, can it explain who did what and what decision that action was authorised to make? Technical terms can be useful, but they should not obscure the business consequence. The record exists to support work and accountability, not merely to demonstrate that a control was installed.
There is a risk in making the response solely about individual blame. People operate within arrangements designed and approved by management. If a common login was the established route through a task, the absence of attribution was not something the final user alone could repair. I needed to own the systems and process question, work with operating leaders and retain the distinction between a design limitation and evidence about a particular person's conduct.
Accountability must survive the ordinary working day
The programme's usefulness would depend on ordinary use, including the moments between tasks and shifts. A demonstration conducted slowly with an attentive facilitator can show that a mechanism is possible. It does not necessarily show that the mechanism will be followed consistently when several colleagues need the same terminal during normal work. The operating review should examine those conditions without inventing a claim that every practical difficulty justifies a weaker account.
People also need to understand the meaning of the record they create. If an entry is a request awaiting approval, the interface and process should not encourage the belief that the underlying action is already authorised. If a person is recording another event, the record should preserve the relevant context. These are business-design questions with technical consequences. They deserve joint attention before a name in a log is treated as a complete answer.
A later supplier-exit review reinforced a related boundary. Seven of 26 scheduled jobs still depended on a vendor service identity. Unattended work does not have a person at a terminal for every execution, but it still needs an accountable owner and authorised conditions. The answer was not to pretend the service identity was an individual. It was to understand the purpose, permission and responsibility behind the job as the relationship changed.
That separate case led to a ₹32 lakh transfer programme. I would not merge it with the terminal programme or claim that one identity product solved both. The two cases concern different kinds of action. They share a leadership question about whether the enterprise can explain the actor, authority and continuing ownership behind the activity its systems perform. A common category label is less useful than a clear account of those differences.
For a board, the appropriate discussion concerns the reliability and limits of the evidence management uses. Directors need not choose the terminal mechanism or administer service identities. They can ask whether important transactions have an intelligible account of responsibility, whether the practice works in the operating setting and what remains unresolved. Management should be able to answer without turning a programme budget into proof of completion.
I would rather report a bounded attribution gap than fill it with an assumption that later becomes part of someone's performance or conduct record. The forty-four entries remained uncertain in the original review. Our responsibility was to improve the arrangement and examine the result honestly. A factory terminal can help people carry out work, but it cannot by itself explain who intended, recorded or approved that work. That explanation requires a process the enterprise has deliberately made usable and accountable.