A quotation takes twenty minutes to prepare, yet reaches the customer three days later. An invoice is ready but waiting for confirmation. An order has been entered correctly and is still copied into another system. When a process slows down, the cause is not necessarily its most complex activity.
Before adding automation, it helps to understand where time accumulates, how often work goes backwards and which information is missing. That gives us a basis for choosing a useful intervention rather than speeding up a step with little impact on the outcome.
Processing time measures the effort spent working on a case. End-to-end elapsed time measures the interval from beginning to completion, including queues, pauses and waiting. A short activity can become a bottleneck when requests arrive together or depend on a single approval.
The gap between two status updates does not, by itself, measure work performed. Without an event marking the start of work and another marking completion, we cannot accurately separate processing from waiting. The calendar matters too: elapsed hours and business hours answer different questions.
“Improve business efficiency” is too broad a starting point. Choose a journey with a beginning, an end and an observable result: from enquiry to quotation sent, from order to shipment, or from support request to closure.
A clear boundary lets us compare similar cases. A standard order and a made-to-order project should not be combined into a single average without distinction. First define what completing a case means and which exceptions need separate analysis.
A useful record connects events to the same case and makes their sequence understandable. The starting points are:
The current status in an ERP system is not enough to reconstruct its history. Technical HTTP request logs alone rarely describe every business step either: they need to be connected to operational events, without treating a server request as a completed business case.
Consider a hypothetical example: a company prepares quotations for customised supplies. Sales collects the enquiry, the technical team checks feasibility and a manager approves the terms before the quotation is sent.
The first idea might be to use AI to draft the document faster. Looking at the process might instead reveal cases waiting for missing customer details, approval requests without a clear recipient and revisions reopened after the technical review.
In this situation, we could improve the initial information collection, make the approval queue visible and define which conditions require an additional check. Draft generation would remain an option to assess afterwards. This example is neither a customer result nor a promise of savings.
Process mining uses event records to reconstruct the paths cases actually follow. It can help compare variations, identify returns to earlier stages and observe where elapsed time concentrates.
Not every SME needs to start with a dedicated platform. For a bounded process, a well-prepared sample and a shared reconstruction can clarify the issue. More structured tools become attractive when volumes, variations and ongoing monitoring justify them. Data guides the questions; the people working within the process explain the context.
An average can hide very different situations. Missing events, duplicates and changes in the mix of cases also need checking: an apparent improvement may come from easier requests rather than the intervention itself.
Unclear responsibility may call for an organisational rule. Repeatedly copying the same information may be addressed through application integration. Missing statuses and notifications may justify a software workflow. AI in business processes can contribute where documents need interpretation or content needs drafting, with checks appropriate to the task.
Choose a bounded change and compare equivalent cases before and after, preserving quality and exception handling. If an improvement merely shifts the queue to the next department, the overall process has not yet improved.
A pseudonymised case reference and the department involved may be enough to identify waiting times: email contents and every person's name are often unnecessary. Pseudonymised information can still be personal data. Access, purpose, retention and any implications for workers should be assessed before collection. Analysing a workflow does not mean ranking people.
Bring a process that creates delays, the systems it passes through and a sample of cases. Together, we can check which events are already available, reconstruct missing steps and identify a proportionate digitalisation or software development intervention.
Tell us where work gets stuck: we will start with what needs to change in the process before choosing the technology to support it.
For the method, see Microsoft's process mining overview. For structuring event records, see data requirements and process preparation. These are technical references; the example and operational choices in this article are illustrative.
