Before Automating a Process, Redesign It
Automating a broken process only means making mistakes faster.
This is the most common mistake in automation projects: taking the workflow as it is — with years of accumulated steps, duplicate approvals, and supporting Excel spreadsheets — and transferring it to software. The result is an inefficient process that now comes with a software license cost as well.
We start one step earlier. We look at how the work actually flows today, measure where it gets stuck and what those delays cost, and redesign the workflow before automating it. It often turns out that half the steps exist simply because “that’s how it has always been done,” and that the greatest gains come not from technology, but from simplification.
What you get
- An objective picture of how the process works today, based on data from your systems rather than opinions.
- A clear indication of which activities should be automated, which should be eliminated, and which should remain with people.
- Process times and costs before and after, measured using the same metrics, so investment decisions are based on numbers rather than impressions.
How we work: from data, not interviews
The method is the classic as-is → to-be approach, but powered by data rather than interviews alone. We collect application logs from the systems involved — business management systems, CRM, ticketing, email — and use them to reconstruct how cases actually move through the process: how often a case is sent back, where queues build up, and which process variants actually exist compared to the one described in the procedures.
The metrics we measure
- Lead time: the total time from case initiation to completion.
- Touch time: the actual time people spend working on the case.
- Rework rate: the percentage of cases that are sent back at least once.
- Straight-through processing rate: the percentage of cases completed without any manual intervention.
- Cost per transaction: the full cost of a single execution of the process.
The gap between lead time and touch time is almost always the most useful insight: it shows how much of the process is spent waiting rather than being worked on.
The redesign: a specification, not a presentation
The to-be process is modeled in BPMN 2.0, a standard notation that is readable both by business stakeholders and by the people who will develop the solution. It also serves as the project specification: what is approved is what gets implemented, without reinterpretation.
For each activity, we define its execution mode — autonomous, assisted, or requiring human validation — so that the boundaries of automation are an explicit decision rather than a side effect of development.
What we do not touch
Your systems stay where they are and continue to be the systems of record for your data. The redesign concerns the workflow, not the infrastructure. No migration, no change of business management system, and no operational downtime.