This is one of the most useful ways to reframe enterprise transformation.

A request enters the organisation. The core platform records it immediately. The calculation runs correctly. The transaction is technically ready to move.

Then the work stops.

A document is missing. An approval sits in an inbox. Two teams reconcile the same information. An exception reaches someone who is unsure who owns the next action.

Five days later, the customer finally experiences the outcome.

From the outside, the organisation is slow. Internally, the explanation often becomes simple: the legacy system is holding us back.

Sometimes that diagnosis is correct. But sometimes the system completed its part in seconds and the organisation spent the remaining time waiting.

APQC defines cycle time as the total time from the beginning of a process to the end, including both time spent performing the work and time spent waiting to move forward. Its open benchmarking data shows that approval-heavy processes can span days even when the underlying transaction itself is straightforward. For example, APQC reports a median of five days for credit approval across its available cross-industry sample. [1][2]

APQC’s August 2026 guidance on credit approval also points to process inefficiencies, incomplete information and unnecessary handoffs as common sources of delay, and argues that faster approvals come from better workflow design rather than weaker controls. [3]

McKinsey has made a similar point from an operations perspective: the strongest automation gains often come from redesigning work, eliminating handoffs and resequencing approvals, rather than simply applying new technology to the existing process. [4]

This is why system age, and business speed should not be treated as the same question.

Legacy technology can create genuine constraints, but it is not always the reason an organisation is slow. A core system may complete a transaction in seconds while the business waits hours or days for information, approvals, reconciliation, exception handling or action from another team. Before approving replacement, leaders should measure system processing time and organisational waiting time separately, then modernise the layer that is actually creating the delay.

Legacy platforms can absolutely become material business constraints.

IBM identifies common modernisation drivers including high maintenance costs, limited scalability, poor adaptability, inefficient performance, outdated technology and security vulnerabilities. It also notes that older applications can become difficult to integrate and change as architectures, dependencies and skills age. [5][6]

Those are valid reasons to modernise.

But they are different from saying that every slow process is slow because the core platform is old.

The first leadership task is therefore diagnosis.

1. The transaction completes quickly, but the case remains open for days. The technology finishes its step, while the surrounding workflow continues to wait.

2. Employees spend more time chasing information than entering transactions. The bottleneck is availability and coordination, not raw system processing.

3. Approvals dominate total cycle time. The request is technically ready, but the organisation is not ready to decide.

4. Teams reconcile the same information across systems. The delay exists between records, owners and controls rather than inside one transaction engine.

5. Exceptions move outside the designed workflow. The normal path is fast, but non-standard cases depend on email, spreadsheets and personal knowledge.

6. A new implementation improved the interface but not the elapsed time. The technology changed while the operating model around it stayed largely the same.

Optimo separates organisational waiting into five practical categories.

1. Information waiting

The process cannot continue because required information is missing, incomplete or difficult to access.

2. Decision waiting

The transaction is ready, but an approval, review, escalation or judgement must happen before the next step.

3. Handoff waiting

Ownership moves from one person, team, system or external party to another, creating a new queue.

4. Reconciliation waiting

Different records, spreadsheets or systems must be compared before the organisation trusts the result.

5. Exception waiting

The standard process works until something falls outside it and there is no clear owner, decision rule or structured path.

The better question is not, ‘How old is the system?’

It is, ‘Which layer is creating the delay?’

Optimo uses three connected operating lenses to answer that question:

• SEE: identify where the organisation is losing visibility, context or timely information.

• ACT: redesign and automate the workflows, approvals, handoffs and exception paths creating waiting.

• BUILD: modernise or change technology faster where the platform itself is the constraint.

Beneath all three is the control layer: identity, permissions, data boundaries, human oversight, auditability and deployment choices.

This creates a more disciplined transformation decision. Preserve what still creates value. Remove the operating drag. Modernise the technology where the evidence says the platform is the constraint.

1. Choose one commercially important end-to-end process. Start with a journey such as customer onboarding, procurement, claims, approvals, fulfilment or service requests.

2. Establish the baseline. Measure total elapsed time, active processing time, waiting time, rework, backlog and exception volume.

3. Map every stop. Mark where the work waits for information, a decision, a handoff, reconciliation, an exception owner or a system response.

4. Identify ownership. Make the next accountable person or team explicit at each waiting point.

5. Separate policy from technology. Ask whether the delay exists because the system cannot move, because the organisation chooses not to move yet, or because required information is unavailable.

6. Match the intervention to the constraint. Use integration, workflow redesign, automation, clearer ownership, AI assistance, selective modernisation or core replacement according to where the delay lives.

7. Measure the outcome after change. Compare the new total cycle time against the baseline and confirm that the business outcome improved, not only the technical platform.

Before approving a major replacement programme, leadership should ask for one process map that separates active processing from waiting.

The session should produce four outputs:

• The largest system constraint.

• The largest information or workflow delay.

• The largest ownership or exception gap.

• The first intervention that can be measured against a clear baseline.

This immediately improves the quality of the technology decision.

If the platform genuinely cannot be secured, supported, integrated, scaled or changed at a reasonable cost and risk, modernisation may be necessary.

If most of the delay exists around the platform, the first move may be workflow automation, integration, clearer ownership or selective intelligence rather than a full reset.

OPTIMO’s Discovery Workshop identifies one high value enterprise AI use case, maps its production readiness requirements and defines the practical path across ownership, workflow, data, integration, governance and delivery.

1. APQC: Cycle time in days for credit approval. APQC defines cycle time as end-to-end elapsed time including both active work and waiting, and reports a median of 5.0 days in the available cross-industry sample.
2. APQC: Cycle time measures for approvals and other processes. APQC consistently defines cycle time as including both processing and waiting.
3. APQC: Credit Approval Cycle Time: How CFOs Can Cut Delays Without Raising Risk, 14 August 2026. APQC highlights process inefficiencies, incomplete information and unnecessary handoffs as common approval delays.
4. McKinsey: What does automation mean for G&A and the back office? McKinsey describes larger gains from redesigning processes, eliminating handoffs and resequencing approvals rather than simply automating existing steps.
5. IBM: What Is Legacy Application Modernization? IBM identifies maintenance cost, scalability, adaptability, performance and security as common legacy modernization drivers.
6. . IBM: Legacy code migration: What it is, why it matters, and how to do it right, 2026. IBM notes that older applications can contain deeply embedded business logic while becoming harder to maintain and integrate.