Multi-entity & enterprise operations

Because a process replicated across entities drifts by default. Each location adapts it to its own systems, staffing and the working style of whoever owns it locally, and without a maintained standard those adaptations never converge — they diverge a little more each year until one workflow on paper is dozens in practice. Nobody designed this; it accreted. The cost is real, though: you cannot improve or compare what is defined differently everywhere, so the variation itself becomes invisible and unmanageable. Seeing the actual divergent processes side by side, not the tidy shared diagram, is where most of the lost time and hidden error turns out to live.

Not by working faster — by removing steps that existed only to compensate for an earlier failure, and by parallelising approvals that had been needlessly serial. Long cycles across entities are usually made of serial sign-offs, and most are habit rather than control. Interrogating each step separates genuine control from pure delay dressed up as governance, and re-sequencing independent steps to run at the same time compresses the timeline far more than speeding up any single step could. Done across 75 entities and more than 2,000 people, that discipline took the approval cycle from roughly two months to fifteen days with no loss of control.

By testing every approval against one question: does it add genuine control, or only a queue? An approval that catches real risk earns its place and stays. One that exists because "we’ve always signed off here," or only because an earlier step cannot be trusted, is delay dressed up as governance and can go — often by fixing the upstream issue it was compensating for. The result is fewer, more meaningful controls rather than a long chain of reflexive ones. Compression comes from deleting the approvals that were never protecting anything, not from rushing the ones that genuinely are.

Because when every entity runs the workflow differently and records it differently, the numbers are not comparable and rarely reconcile — so the group view is assembled by hand, argued over, and out of date by the time it lands. A systemic problem hiding across many entities looks like many unrelated local issues, and a strong entity cannot be told apart from one that marks itself generously. Standardising the underlying process is what makes a single trusted number possible: when the work is done and recorded the same way everywhere, the group metric means the same thing everywhere, and leadership can finally steer the enterprise as a whole.

Only if it is done bluntly. Not every divergence is waste — a market with different regulation, a genuinely different customer, a real legal constraint all call for legitimate local variation, and a standard that ignores them just breeds workarounds worse than the inconsistency it replaced. The discipline is to separate accidental variation (drift, habit, local preference, steps that only added delay) from essential variation that reflects a real difference in the world. Standardise the first ruthlessly and preserve the second deliberately. A standard that respects the variation that should exist is one entities actually adopt, rather than quietly route around once attention moves on.

Because in a long cross-entity process an error introduced early can travel a long way before anyone catches it — sometimes into another entity, weeks later — where it triggers expensive rework and a hunt back through the chain to find the origin. The further a defect travels, the more it costs, because everything built on top of it has to be unwound. The fix is to move validation upstream, to the point where data enters the process, so the error is caught while it is cheap and local. Building the check in early is almost always cheaper than the cascading correction it prevents.

It depends on the number of entities and the breadth of the process, but the work is sequenced so value lands along the way rather than all at the end. A focused transformation of one cross-entity process typically runs over a few months: mapping the real divergent flows, re-engineering the sequence and piloting it, then standardising and instrumenting it as a governed metric. Larger programmes spanning many processes are broken into discrete pieces, each with its own measurable target, so improvement is proven against a baseline at each step. The aim is a series of proven, measured gains, not an open-ended programme.

Usually not. The variation that stretches cycles and hides errors is far more often a process and governance problem than a systems problem, and a great deal can be standardised and re-engineered on the platforms you already run. Replacing systems before the process is fixed tends to cement the existing divergence into new software at great cost. The better order is to standardise and re-engineer the flow first, prove the simpler version works, and only then decide whether any system change is genuinely needed to support the process that remains — rather than mistaking a tooling change for the transformation itself.