Process optimisation with software starts with measurement. Four numbers tell you where a process gets stuck: lead time, waiting time, manual work, and errors. Once you know the bottleneck, choose the lightest fix that removes it: change the process, make better use of the software you already have, or build something. A baseline before and a second measurement after show whether it worked.
Skip the measurement and you risk buying or building software for a step that was already fast enough. This article covers the software side of process optimisation: how to make the bottleneck visible with data your systems often already hold, how to choose between the three routes, and how to prove the gain. For the execution that follows, read our guides to business process automation and business process digitization.
Why process optimisation with software starts with measurement
In a process that's stuck, you mostly see the symptoms: customers calling about their orders, a backlog at month end, and colleagues working late. The cause often sits somewhere other than where the complaints land. A request can take ten minutes to handle and still wait for days on an approval, a check, or a handover between two departments.
Much of that delay lives in the coordination around the work. In Asana's Anatomy of Work Global Index 2023, 9,615 knowledge workers in six countries reported spending 58% of their day on "work about work": coordinating, searching for information, and chasing the status of tasks.
Part of that comes from systems that don't talk to each other. According to Salesforce's 2026 Connectivity Benchmark Report, organisations run an average of 957 applications, and only 27% of them are integrated. The survey covered 1,050 IT leaders in nine countries across Europe, North America, and Asia Pacific.
Without measurement, you can't tell which part of the lead time is the work itself and which part is waiting and handing over. That distinction decides which fix will help.
Four measures that expose the bottleneck
You don't need an elaborate measurement programme to find a bottleneck. Four measures are usually enough:
- Lead time. The time from start to finish for a single case, such as from order intake to delivery or from application to decision.
- Waiting time. The share of lead time when nobody is working on the case, because it sits in a queue or waits for approval or information.
- Manual work. The steps where someone retypes data, copies it between systems, maintains lists, or checks things by hand.
- Errors. The cases that come back for rework because of missing data, wrong amounts, or duplicate entries.
The data for each measure is often already recorded somewhere:
| Measure | What you measure | Where the data often lives |
|---|---|---|
| Lead time | Median and spread per case | Created and closed timestamps in the ERP, CRM, or case system |
| Waiting time | Time between two status changes | Status history, log files, a shared mailbox |
| Manual work | Actions and minutes per case | Sampling, time tracking, number of exports and imports |
| Errors | Share of cases needing rework | Corrections, credit notes, reopened tickets |
Look at the median and the outliers alongside the average. An average lead time of five days can mean almost everything is done in two days while a small share hangs for three weeks. That calls for a different fix than a process that's slow at every step.
How to find the bottleneck in your own systems
Almost every business system records when a record is created, changed, or closed. Together, those timestamps form a trail of each case through the process. Line them up per step and you see where cases pile up. The technique is called process mining: you rebuild the actual flow from your systems' log data, instead of relying on the process diagram on paper.
Here's how to approach it:
- Pick one case as the unit. An order, application, work order, or invoice. Everything you measure hangs off that case number.
- Collect the events per case. Pull timestamps and statuses from each system involved, together with the case number.
- Fill the gaps. Steps outside the systems, such as a phone call or a spreadsheet, can be measured with a short sample.
- Put the steps on a timeline. The step with the longest waiting time or the biggest pile of work in progress is your first candidate.
The trail often breaks where two systems meet. The order sits in one package, the planning in another, and between them is someone copying data across. That's where waiting time, manual work, and errors appear together. In that case the fix usually lies in software integration that passes the data along automatically.
Three routes: change the process, use software better, or build
Once the bottleneck is clear, choose the lightest intervention that removes it. Redesigning the work itself has its own methods. As a software company, we focus on the choice that comes after, and it has three routes:
| Route | Fits when | Example bottleneck |
|---|---|---|
| Change the process | The bottleneck lies in agreements, sequence, or authority | An approval by two people where one would do |
| Use existing software better | The package can already do it and isn't fully used | A workflow module or standard connector that was never switched on |
| Build software | The bottleneck sits between systems or in work no package supports well | Data retyped every day from one system into another |
Start with the software you already have. According to Eurostat, 53% of EU enterprises used specialised business software for ERP, CRM, or business intelligence in 2025, with the Netherlands and Belgium at 70%. ERP use ranged from 41% of small enterprises to 89% of large ones. So check first whether your package can solve the bottleneck with a setting, an extra module, or a standard connector.
Building makes sense when you see one or more of these signals:
- The bottleneck sits between two or more systems without a usable standard connector.
- The work is specific to your organisation and the package forces workarounds.
- The workarounds themselves, such as spreadsheets and macros, have become a continuity risk.
Building rarely means a whole new system. Often a connector, an input screen that stops errors at the source, or a small application that closes a gap between two packages is enough. Our page on custom software development explains how we approach that choice.
Baseline and second measurement: making process optimisation provable
An improvement you can't prove tends to lose its support at the next budget round. So agree up front how you'll measure, and stick to it afterwards:
- Record the baseline over a representative period, using the four measures and definitions you'll keep unchanged later.
- State the target in the same unit, such as the median waiting time at one step or the share of orders needing rework.
- Build measurement into the solution. Let the new software record timestamps and statuses itself, so the second measurement isn't manual work.
- Measure again after a fixed period and compare with a period of similar volume, allowing for seasons and peaks.
- Check the next step too. A bottleneck that disappears often moves on to the following step in the process.
A simple dashboard showing the four measures week by week makes the effect visible to everyone, from the shop floor to the board. We build dashboards like these as part of our data and AI work, on data the systems record anyway.
What the software side of process optimisation needs
Whether you connect, extend, or build from scratch, a few components decide whether the improvement stays measurable and lasts:
- Connections through APIs, so data moves between systems without retyping or exports.
- A case number that's recognisable everywhere, so you can follow one order or application across all systems.
- Logging of statuses and timestamps per step, as the basis for every future measurement.
- Checks at the point of entry, so incomplete or incorrect data doesn't travel further into the process.
- A managed place for business rules, so a changed agreement doesn't create a new spreadsheet workaround.
For more than 30 years, Isatis has built software that runs in production for years, from maintenance software for aviation to a subsidy administration platform and RFID in the supply chain. With 30+ engineers in Nijmegen and Sarajevo, more than 100 projects, and ISO 9001 and ISO 27001 certification, we look at what your systems show first, and only then at what needs to be built. Book an introductory call and we'll look together at where your process gets stuck.
Frequently asked questions
What is process optimisation?
Process optimisation is improving a business process so it runs faster, needs less manual work, or produces fewer errors. With software, you measure where the process gets stuck and remove that bottleneck by changing the process, making better use of existing software, or building something.
How do you measure the lead time of a process?
Pick one case as the unit, such as an order or application, and pull the start and end timestamps per case from your systems. Look at the median and the outliers. By also using the timestamps of intermediate steps, you can see which part of the lead time is waiting time.
When should you build software instead of configuring a package better?
When the bottleneck sits between systems without a usable standard connector, or when the work is so specific that the package forces workarounds. Check first whether your existing software can already do it with a setting, module, or standard connector. That's faster and keeps your application landscape simpler.
How do you prove that a process improvement works?
With a baseline before and a second measurement after, using the same measures and the same definitions. Let the new software record timestamps and statuses itself, compare periods of similar volume, and check that the bottleneck hasn't simply moved to the next step.
