Every transformation programme starts with a process map, swimlane diagrams, documented workflows, and a shared belief that the organisation understands how its own work moves.
That belief is almost always wrong and the cost of discovering it mid-migration is rarely small. Ask TSB.
In April 2018, TSB migrated 1.3 billion customer records from a legacy Lloyds platform to a new system built by its Spanish parent, Sabadell. Within 48 hours, 1.9 million customers were locked out of their accounts. Mortgage customers could see other people’s balances. Business accounts were inaccessible for weeks.
The cost exceeded £330 million. The CEO resigned. A subsequent review found the migration had proceeded without adequate understanding of the interdependencies between TSB’s existing processes and the new system’s architecture. The technology worked but nobody had mapped what it was supposed to carry. The problem has a name, and it is more precise than most organisations appreciate.
Operational intelligence derives a data-accurate picture of how work actually moves across processes, systems, decisions, and people, from the systems that already exist. It answers questions that no stakeholder interview or workshop can reliably answer: What paths does work actually take? Where do delays accumulate, and why? What decisions are being made, at what points, by whom, and with what consistency? Without it, three things happen reliably. Teams automate undefined workflows. They digitise bottlenecks. They scale inefficiencies across platforms.
The raw material of operational intelligence is event data. Every enterprise system: ERP, CRM, case management, order management writes event logs. Every status change, approval trigger, and record update leaves a timestamp. Those timestamps, linked by a case identifier, contain a complete record of actual operational behaviour. The data already exists in systems organisations already run. What typically does not exist is the practice of treating it as a primary input to transformation strategy rather than a compliance byproduct.
From a clean event log, process mining tools such as Celonis, UiPath Process Mining, and SAP Signavio reconstruct actual process paths, show where delays concentrate, and compare real behaviour against documented models. The gap between what the process map shows and what the event log shows is rarely trivial. Approvals that look automatic in a diagram can involve three email threads and a spreadsheet nobody has officially sanctioned. When DHL applied process mining to its customs clearance operations, it did not find the bottlenecks its managers expected. Most delays were not in processing time. They were in decision latency, the gap between a case arriving at a decision point and a decision actually being made.
That distinction matters. Most transformation programmes focus on process visibility: where things are in the pipeline. Decision visibility goes further. The decision point is where the workflow branches, and overlaying case attributes on those forks reveals what factors govern path selection and whether that governance is consistent across teams and over time. It tells you which exception paths consume disproportionate capacity and how workflows actually behave versus how the process architects assumed they would.
This is where the stakes are highest, and where poor sequencing causes the most damage. A machine learning model trained to automate routing decisions will perform well if the training data accurately reflects the decision logic that should govern those decisions. The emphasis is on should.
In most organisations, historical decision data does not reflect intended logic. It reflects formal rules mixed with informal workarounds, individual discretion, and exceptions handled outside the system and never recorded. A model trained on that data learns a corrupted version of the intended logic, not the rules, but the average of what people actually did, including every shortcut and undocumented escalation path. Deployed at scale, it reproduces those patterns at machine speed: consistently, confidently, and wrongly. Establishing correct decision logic before training, and building a dataset that reflects intended rather than observed behaviour, is not a hygiene step. It is the difference between an AI system that accelerates good decisions and one that scales bad ones.
Operational intelligence is not a workstream that runs in parallel with implementation. It is the prerequisite that makes implementation decisions defensible. Before any platform is selected or automation brief is written, three questions need answers from data: What paths does work actually take, and how frequently does each variant occur? Where do delays accumulate, and what attributes predict them? At what decision points does the workflow branch, what governs those branches in practice, and how consistent is that governance across teams and over time?
