Automate or redesign? A framework for the decision that matters more
There is a widely repeated observation in operations circles that automating a broken process just gives you a faster broken process. The observation is correct, but it does not tell you which processes are broken in a way that disqualifies them from automation, and which are broken in a way that automation can fix. Most real processes are somewhere in between, and the decision about whether to automate or redesign first is not binary: it depends on what kind of broken the process actually is.
The question matters for budget reasons as much as for technical ones. An organisation that spends six months redesigning a process before automating it has a much longer payback period than one that automates a structurally sound process directly. An organisation that automates a process without addressing its underlying design flaws will typically see its automation savings eroded by the cost of exception handling, rework, and maintenance.
Here is a framework for making this decision from workflow data rather than from intuition.
The first question: is the process broken in its structure or its execution?
Structural problems are design flaws: unnecessary steps, redundant approvals, incorrect sequencing, missing validation that causes rework downstream. These problems produce bad outcomes regardless of how well the process is executed. You can train people better, add more resources, and communicate more clearly, and the structural problem will persist.
Execution problems are performance gaps in an otherwise sound structure: steps that take too long because of queue management issues, handoffs that stall because of unclear ownership, decisions that are slow because the decision criteria are not clear. The structure is correct; the execution is not meeting the structure's potential.
Workflow data is useful for distinguishing these. If the process has a high rework rate across all instances, regardless of who is handling them or when, that is a structural signal: something in the process design is generating rework that execution changes cannot eliminate. If the rework rate is high for certain approvers or certain time periods but low for others, that is an execution signal: the structure can handle the work, but the execution is inconsistent.
The automation case for execution problems
Execution problems are generally strong automation candidates. If the process design is sound and the problem is that queue times are long, escalations are informal, or data transfer between steps is manual and error-prone, then automation addresses the problem directly. The automation is not masking a deeper issue; it is solving the actual problem.
The risk with execution-problem automation is overengineering. If the execution problem is a slow queue because one approver has too much on their plate, the automation solution might be a routing rule that distributes load more evenly, not a complex workflow automation platform. The complexity of the solution should be proportional to the complexity of the problem. Workflow data helps here: it tells you exactly what the problem is, which allows you to scope the solution tightly rather than building for every contingency.
The redesign case for structural problems
Structural problems require redesign before automation is efficient. The most common structural problems are unnecessary approval tiers (approvals that exist for historical or political reasons rather than genuine risk management), redundant data collection (the same information collected multiple times across different steps because the process grew without being rationalised), and incorrect process ownership (steps that sit with a team that is not best positioned to handle them, generating handoff overhead).
Automating a process with these problems will reduce some costs: you will automate the unnecessary approvals faster, you will collect the redundant data more efficiently. But you will also have built an automation that is hard to change, because the unnecessary structure is now embedded in the automation logic. When the business eventually decides to remove the unnecessary approvals, the automation needs to be rebuilt.
The redesign case is strongest when the structural problem is causing high exception rates. If more than 20% of process instances do not follow the standard path, and the reason is a design flaw (missing information at submission, wrong routing logic, steps that trigger rework), then automating the current process will embed that exception rate into the automation. The exception handling in the automation will be complex, expensive to maintain, and will account for a disproportionate share of the total automation cost.
The hybrid path
In practice, most processes have both structural and execution problems, and the decision is not purely binary. A common pattern is to address the structural problems that directly cause the highest exception rate, automate the redesigned process, and then iterate on the remaining execution problems post-automation.
The key is sequencing the structural fixes correctly. You do not need to achieve perfect process design before automating. You need to address the structural problems that will generate the most exception handling overhead in the automation, because those are the ones that will make the automation expensive to build and maintain. Everything else can be a subsequent iteration.
Workflow data helps identify the right sequencing here. Look at the exception rate and ask: of the cases that deviate from the standard path, what is causing the deviation? If the cause is a structural problem (missing information, incorrect routing), address that first. If the cause is an execution problem (a specific approver who is slow, a step that is consistently delayed at month-end), that can be addressed after or alongside the automation.
What this framework does not resolve
This framework does not resolve the question of whether the process should exist at all. Some processes persist because they were needed at one point in the organisation's history and no one has ever questioned whether they are still needed. A purchase approval workflow designed when the organisation was managing cash carefully might be unnecessary overhead now that financial controls are embedded in the ERP system. Automating that process, even after redesigning it, is adding efficiency to something that should arguably be eliminated.
The eliminating option is outside the scope of an automation programme, but it is worth keeping in view. Before committing to an automation project, it is worth asking: if we could redesign this process from scratch today, would it look like this? If the answer is clearly no, and if the gap between current design and ideal design is large, then the effort required to redesign before automating may actually be less than the total cost of automating the current process and living with its limitations.
The data tells you what the process looks like. The framework tells you what question to ask next. The decision ultimately requires judgment about what the organisation needs the process to do, and that judgment is not something workflow analytics can replace. What it can do is make the starting point for that judgment much more accurate than an intuitive read of a process diagram.