Optimising business processes through BPM (Business Process Management) has stopped being a one-off improvement project and has become a discipline of continuous management. Its goal is clear: to redesign end-to-end workflows in order to eliminate waste, shorten cycle times and reduce the cost per transaction without sacrificing quality. In this article we break down the BPM methodology from modelling to automation, with the standard notation, the metrics that matter and an example of a real redesign.
What BPM is and how it differs from one-off improvement
BPM is a systemic approach to discovering, modelling, analysing, measuring, improving and automating business processes. The difference from an isolated improvement is that BPM manages the process as an asset that is permanently monitored through its life cycle: discovery, analysis, redesign, implementation and monitoring, before returning once more to discovery. It is a loop, not a project with a closing date.
The modelling standard is BPMN 2.0 (Business Process Model and Notation), maintained by the Object Management Group and also published as the standard ISO/IEC 19510:2013. BPMN offers a common graphical language — events, activities, gateways, flows and lanes — that both the business analyst and the developer understand without ambiguity. That unambiguity is what makes it possible to move from a diagram to an executable process without losing semantics along the way.
Phase 1: discovery and modelling of the current state (AS-IS)
Before optimising, you have to understand. AS-IS modelling documents the process as it actually works, not as the manual says it should work. To do this you combine interviews, direct observation and, above all, process mining: techniques that reconstruct the real process from the event logs of the ERP, CRM or document management systems. Process mining reveals the "ghost process", the undocumented variants, the rework and the bottlenecks that no interview confesses.
A good AS-IS model identifies the seven wastes of Lean thinking applied to administrative processes: overproduction of reports, waits between departments, unnecessary movement of documents, over-processing, an inventory of queued tasks, redundant motion and defects that generate rework. Documenting where they are is half the work of optimisation.
Phase 2: analysis with metrics, not opinions
The quantitative analysis of the process rests on four core metrics. Lead time is the total time from when a request enters until the result is delivered. Cycle time is the effective working time. Process cycle efficiency (PCE) is the ratio of value added to total lead time; in unoptimised administrative processes it is usually below 10%, which means that more than 90% of the time the work is simply waiting. The fourth metric is the cost per transaction.
Bottleneck analysis draws on Goldratt's Theory of Constraints: the throughput of the whole process is set by its slowest link, so optimising any other stage before raising the constraint is wasted effort. Identifying the constraint, exploiting it, subordinating everything else to it and then elevating it is the correct sequence.
It is also worth distinguishing between two kinds of unproductive time that the analysis often confuses. The first is structural waiting time: the request is stuck in a queue because the next resource is busy or because the process requires a hand-off between departments. The second is poorly used touch time: the resource is working, but on low-value tasks such as re-keying data that already existed in another system. Reducing the first requires redesigning the flow and parallelising; reducing the second requires integration or automation. Treating both with the same tool is one of the mistakes that waste the most effort in optimisation projects.
A complementary technique is value-added analysis (VA/NVA), which classifies each activity into three categories: it adds value that the customer pays for (VA), it does not add value but is necessary because of a legal or control requirement (necessary NVA), or it does not add value and is pure waste (avoidable NVA). The aim of the redesign is to eliminate the third category, minimise the second and protect the first. In typical administrative processes, genuinely value-adding activities rarely exceed 15% of the total lead time, which sizes the improvement potential before touching a single line of code.
Phase 3: redesigning the target state (TO-BE)
The TO-BE redesign applies concrete principles. Eliminate steps that add no value (redundant validations, ceremonial sign-offs). Simplify those that remain. Parallelise activities that are currently done in sequence unnecessarily. Standardise the variants to reduce exceptions. And automate only after simplifying: automating a bad process achieves nothing but producing defects faster.
This is where the Lean Six Sigma tools come in. Lean attacks waste and waiting time; Six Sigma attacks variability through the DMAIC cycle (Define, Measure, Analyse, Improve, Control), standardised in ISO 13053. The combination, Lean Six Sigma, pursues processes that are both fast and predictable. The six sigma target of 3.4 defects per million opportunities is rarely necessary in the back office, but the statistical discipline that underpins it certainly is.
Phase 4: automation and hyperautomation
The modern automation layer combines three technologies. BPM engines (BPMS) orchestrate the flow according to the executable BPMN model. RPA (Robotic Process Automation) automates repetitive tasks that interact with existing interfaces without the need for deep integration. And process intelligence adds classification and data extraction from unstructured documents.
When these layers are combined in an orchestrated way we speak of hyperautomation. It is worth remembering the governance principle: any system that makes or supports decisions with an impact on people must comply with the General Data Protection Regulation (GDPR) — especially Article 22 on automated decisions — and, where applicable, the European Artificial Intelligence Regulation (AI Act), which classifies systems that automate sensitive decisions by risk level. Optimising a process does not exempt you from the obligation to explain and audit the decisions that the process automates.
The decision about what to automate and what not to automate must be taken with explicit economic criteria, not out of technological enthusiasm. A useful rule of thumb is the volume-versus-stability matrix: high-volume tasks with stable rules are the ideal candidates for RPA or a rules engine, because their return is predictable and their maintenance low; low-volume tasks or tasks with rules that change frequently almost never justify automation, because the cost of maintaining the bot exceeds the saving. A mature optimisation project starts by automating a handful of high-volume processes, demonstrates the return with data, and only then extends the practice.
Just as important is to design the exception from the outset. No real process works without atypical cases, and an automation that only contemplates the happy path breaks in production and generates more manual work than it saves. The TO-BE process must define what the system does when the data do not add up, who it escalates to and how that escalation is recorded. Exception traceability is, moreover, the main source of learning for the next turns of the BPM life cycle.
Comparison table: process optimisation techniques
| Technique | Attacks | Best use case | Standard |
|---|---|---|---|
| Lean | Waste and waiting times | Processes with much queuing and rework | TPS philosophy |
| Six Sigma (DMAIC) | Output variability | Processes with unpredictable defects | ISO 13053 |
| BPMN + BPMS | Lack of orchestration and traceability | Multi-department flows | ISO/IEC 19510 |
| RPA | Repetitive manual tasks | Copying data between systems without an API | — |
| Process Mining | Ignorance of the real process | Objective AS-IS diagnosis | — |
Worked example: supplier onboarding in an industrial company
The AS-IS process of onboarding a supplier took 12 days on average, with a lead time of 96 hours of effective work but a PCE of 6%: almost all of it was waiting between four departments. Process mining revealed 17 different variants for something that should have had one. In the TO-BE redesign, a redundant double tax validation was eliminated, the banking and solvency checks were parallelised, the onboarding form was standardised, and the creation of the record in the ERP was automated via RPA. Verified result after three months: lead time from 12 to 3 days, variants from 17 to 2, and cost per onboarding cut in half, all with a complete audit trail compliant with the GDPR.
Common mistakes in optimisation projects
- Automating before simplifying: the chaos is digitised instead of eliminated.
- Modelling the TO-BE without measuring the AS-IS: without a baseline there is no way to demonstrate the improvement.
- Optimising stages that are not the constraint: the bottleneck stays where it was.
- Ignoring change management: the new process exists on the diagram but people keep working as before.
- Forgetting data governance: automating decisions without traceability or a legal basis exposes you to penalties.
Frequently asked questions
Are BPM and RPA the same thing?
No. BPM orchestrates the complete end-to-end process; RPA automates specific tasks within that process. The ideal is to use BPM to govern the flow and RPA as one of the execution tools.
How long does it take to see results?
A first redesign with quick wins usually delivers measurable results in 8 to 12 weeks. The complete transformation of a complex process, including automation, can take between six months and a year depending on its criticality.
Do you need expensive BPM software to get started?
Not to diagnose. Discovery and AS-IS modelling can be done with free BPMN modelling tools. Investment in a BPMS or in RPA is only justified once the process has been simplified and the expected return is known.
How does the AI Act affect process automation?
If the automation includes AI systems that classify or make decisions about people, the AI Act requires assessing the risk level, documenting the system and guaranteeing human oversight. Optimisation must be designed from the outset with this framework in mind.
Conclusion
Optimising processes with BPM is not about buying technology, but about imposing discipline: measuring the real process before touching it, simplifying before automating and governing the decisions that are automated. The metric that best sums up the success of a BPM project is process cycle efficiency: every point that figure rises means less idle time, less cost per transaction and an organisation capable of responding to the customer in hours rather than weeks. At Summum Consulting we tackle these projects in that exact order — discover, analyse, redesign, automate and govern — because skipping any step turns optimisation into a digitisation of the previous disorder.