Processes · to-be · implementation
Process optimisation:
from an as-is map to results
A process map is only useful when it helps change how work is done. That means selecting the real causes of waste, designing a target route, testing it against actual operations and embedding accountability.
Anton Konnov · 20 August 2026 · 9 minutes
Difference
An audit explains the problem; optimisation changes the process
Diagnosis captures the actual route and the reasons for deviations. Optimisation starts after that: the team selects a target outcome, removes unnecessary steps, adjusts responsibility hand-offs and tests the new model in practice.
If you draw an ideal process without real examples, the to-be model usually ignores the constraints of systems, authority and data. If you stop at as-is, the organisation ends up with a detailed map and no change.
Six steps
How to optimise a business process
Document the as-is
Walk through several real operations from trigger to outcome. Capture roles, systems, documents, working time, expectations, returns, exceptions and decision points.
Select causes and priorities
Separate symptoms from the mechanism that creates them. Assess gaps by impact on the customer, time, quality, cost and risk. Include in the first change package only what relates to the target outcome.
Design the to-be model
Define the new route, roles, rules, data, control points and automation requirements. For each change, it must be clear which cause it addresses.
Test on a limited pilot
Run the target model on one type of operation, product or division. The pilot reveals real exceptions and lets you refine rules before scaling systems and regulations.
Embed responsibility and tools
Appoint a process owner, update authority, instructions, forms and systems. Training should explain not only the new actions but also the expected outcome and how to handle exceptions.
Embed and verify the result
Compare actual performance against the baseline, check quality and new risks. Turn post-launch deviations into a limited improvement list rather than an endless redesign project.
To-be map
What must be defined
Outcome
The process customer, readiness criteria and acceptable timeframes.
Accountability
Owner, performers, authority and escalation rules.
Data and systems
A single source, mandatory fields and automated checks.
Control
Deviation signals, evidence and corrective action.
Automation
Logic first, technology second
Automate a stable and understood target scenario. If responsibility and rules contradict each other, an ERP, workflow or AI component will only cement the historical defect into a new interface.
System requirements should be framed in terms of event, data, decision, action and exception. This approach lets you compare a manual pilot, configuration of an existing platform and bespoke development against a single outcome criterion.
Acceptance
How to tell the change is working
The process outcome is defined consistently by all participants.
The number of returns, waits or manual hand-offs has decreased.
Exceptions are visible and owned, not handled informally.
Metrics are linked to decisions and corrective actions.
The new route maintains quality under volume growth and staff changes.
First step
Choose one problematic route
We will define the as-is state, root causes of waste and the boundaries of a target-process pilot.