Redesign the Process Before Automation Encodes Its Workarounds

Introduction

A purchase requisition arrives without information procurement needs to place the order. Procurement corrects it, sends it back, the requester resubmits it, and the approval sequence begins again.

An automation project can remove the emails, route each handoff immediately and make every return happen faster. The requisition can still be wrong when it reaches procurement.

That is the central problem in automation process redesign before implementation. Existing process steps are not automatically requirements. Some exist because a business control is necessary; others survive because an upstream input is weak, an old system imposed a constraint, two teams check the same condition or a local workaround became normal operating practice.

Current process-transformation tooling increasingly separates the observed process from the process intended for implementation. SAP Signavio’s 2026 transformation guidance, for example, explicitly moves from analysis into the design of an optimized future-state process, then recommends modeling and simulation before implementation. Its Source-to-Pay content separately examines manual changes, process variants and harmonization rather than treating a higher automation rate as the only objective.

Automation engineering therefore starts too late if the first serious design question is how to execute today’s steps without a person.

At a glance

• An as-is process records current behavior; it does not prove that every step belongs in the automated future state.
• Rework often exists because an earlier input, policy, handoff or decision is weak. Automating the rework preserves the cause.
• Legitimate controls and necessary process variants should remain; historical workarounds need a business reason before they become software.
• Process mining can expose loops and deviations, but redesign determines what should change.
• The to-be process can be modeled and tested before automation engineering commits the organization to its current operating habits.

The as-is process is evidence, not the automation specification

Process discovery has become considerably better at showing what actually happens.

Power Automate Process Mining can reconstruct execution from event data, compare processes, identify root causes and surface inefficiencies. Microsoft also describes standardization as a way to reduce rework and eliminate pending cases. Its documentation covers rework analysis, root-cause analysis and process comparison.

SAP Signavio provides a similar execution view through process variants, showing different sequences taken by real cases and allowing teams to compare their effects on efficiency, compliance and business outcomes.

Those capabilities answer an important diagnostic question: what is the process doing? They do not decide whether the observed behavior deserves to survive.

A return loop may be frequent and predictable enough to automate perfectly. It can still exist because the first submission asks for the wrong information. A second approval may appear in nearly every case but add no decision beyond an earlier control. A regional variation may be necessary because of regulation, or it may remain only because nobody has revisited a configuration introduced six years ago.

The execution record shows the pattern. Redesign has to explain it.

A downstream task may exist because an upstream step is weak

The purchase-requisition example becomes more useful when the correction is examined rather than merely counted.

Suppose procurement repeatedly receives requests without a valid contract reference. One response is to automate the correction cycle: detect the missing field, route the requisition back, notify the requester and restart approval after the field is supplied.

That may be legitimate if the information cannot be known earlier. But if the contract reference already exists in another system, or can be required and validated when the requisition is created, the return cycle is compensating for an upstream design problem.

The distinction affects what should be automated. In one design, the organization builds reliable machinery around a recurring correction. In the other, much of that correction disappears.

SAP Signavio’s current correction-recommendation model reflects this broader range of interventions. Some recommendations are small source-system changes; others explicitly require significant changes to the process.

A process redesign discussion should therefore ask why a task exists before asking how quickly software can perform it. Otherwise, work created by another process weakness can acquire the status of a permanent requirement simply because it has become familiar.

Business necessity and process habit look similar on a flowchart

Removing steps indiscriminately would be as weak a strategy as automating them indiscriminately.

An approval may represent a genuine segregation-of-duties requirement. A manual check may cover a condition for which the source data is unreliable. A regional variant may reflect a contractual or regulatory obligation. The fact that a step slows throughput does not make it waste.

The more useful question is what business condition justifies the step.

That question becomes particularly important when processes have accumulated variants. SAP’s process-variant guidance recognizes that process differences can arise from geography, business units, customer channels and other operating conditions. The same tooling is also intended to reduce redundancy and control how changes propagate across related variants.

The redesign task is therefore selective.

A difference supported by a real business constraint may belong in the future state. A different route used by one office because its old application could not support the standard sequence needs a different defence. The first is process design; the second may simply be process history.

Once both are encoded into automation, they can become equally expensive to unwind.

Rework needs a cause before it needs an automated route

Rework is particularly easy to misread because it already looks like a workflow.

A case moves forward, something is found to be incomplete or incorrect, the case returns to an earlier step and work resumes. Every transition can be documented, and every handoff can be automated.

The sequence is still evidence of work being repeated.

SAP’s current process-intelligence dashboards explicitly treat changes and rework as contributors to additional manual effort, higher throughput time, mistakes and process loops. Its harmonization analyses examine alternative activities used to perform the same process step and use those differences to derive a more standardized execution model.

That does not mean every loop should disappear. A risk review may legitimately send a case back when new evidence invalidates an earlier assumption.

The redesign question is narrower: does the loop represent a required business reaction, or does it compensate for something the process could have prevented?

Only the first answer immediately justifies encoding the loop as part of the future-state workflow.

This is also the boundary between process analysis and process redesign. Event data can show that one path generates disproportionate rework. It cannot decide whether the underlying policy, input requirement, ownership boundary or control should change.

Standardization should remove accidental variation, not legitimate difference

Automation projects often encounter several versions of what the business describes as one process.

The temptation is either to automate each local version or to impose one global sequence before understanding why the differences exist. Both approaches can create avoidable problems.

SAP’s current transformation guidance describes process harmonization as reducing unnecessary local variants and defining a standardized future-state process that can be reused across the organization. Its example compares procurement execution across different regions before designing the harmonized to-be process.

That word—unnecessary—does important work.

A process may need several valid paths because customer type, jurisdiction or transaction value changes the required treatment. Those paths are part of the operating model.

Elsewhere, apparent variation is created by inconsistent master data, different forms, local spreadsheets, duplicate controls or teams making up for limitations in their surrounding systems.

Automating every existing variation does more than increase implementation effort. It gives those differences a longer life by turning them into maintained configurations, workflow branches, tests and change dependencies.

Process harmonization before automation is therefore less about forcing uniformity than deciding which differences the business is prepared to defend.

Build the to-be process before choosing how to automate it

Once the underlying process logic has been challenged, the next artifact should be the future-state process rather than the automation build.

SAP’s current transformation methodology explicitly separates as-is and to-be models and recommends modeling the optimized future state before implementation. Its 2026 guidance goes further by suggesting simulation against measures such as cycle time, automation rate and exception reduction before the redesigned process is approved for implementation.

Its BPMN simulation tooling can model execution duration, cost, case frequency, gateway probabilities and resource availability, then expose cycle time, resource use and bottlenecks across simulated runs.

Microsoft’s Process Mining simulation capability similarly allows teams to modify a statistical process model and test the effect of proposed changes without altering the underlying process data or production process.

Simulation cannot prove that a redesigned process will work exactly as production will behave. It can, however, expose assumptions before they are buried inside implementation.

Removing an approval, shifting a validation upstream or consolidating two variants changes queues, timing and responsibilities. Those consequences deserve examination while the process is still cheap to change.

The choice between workflow automation, RPA, an agent or another execution mechanism comes later. First the organization needs a process worth encoding.

Faster task execution can hide a poor redesign

Automation metrics can make an unreformed process look better.

A task that previously waited four hours for someone to open an email may now begin in seconds. A return to the requester can happen instantly, while a duplicate check can run at machine speed.

Those improvements are genuine at the task level. They do not show whether the business is still creating avoidable work.

A more revealing post-redesign view tracks whether cases complete correctly the first time, how often work returns to an earlier stage, how many distinct variants remain, where cases wait and which steps continue to exist solely because another part of the process produces incomplete or ambiguous inputs.

Microsoft’s process-mining guidance connects standardization with reducing rework and pending cases, while SAP’s execution-analysis tooling compares variants against efficiency, compliance and business outcomes rather than treating process speed as the only measure.

That keeps the redesign objective separate from the automation business case. The question here is whether the future-state process contains less avoidable work. The economics of exception labour and automation ROI belong to a different analysis.

FAQs: automation process redesign before implementation

Should a process always be redesigned before automation?

It should at least be challenged before the existing sequence is treated as an implementation requirement. Some processes are already well controlled and consistent. Others need changes to inputs, policies, handoffs, ownership or variants before automation adds much value.

Does process mining redesign the process automatically?

No. Process mining can reveal actual paths, bottlenecks, rework, deviations and correlations in event data. Those findings can identify where redesign deserves attention.

The business still has to determine why the behavior exists and whether the future-state process should retain, alter or remove it.

Should every manual step be removed?

No. Manual activity may represent necessary judgment, control, evidence review or regulatory responsibility. Redesign asks whether the step has a defensible business purpose and whether its location in the process remains appropriate.

What is the difference between process standardization and process redesign?

Standardization reduces unnecessary variation across ways of performing similar work. Redesign can go further by changing the sequence, inputs, decisions, controls, ownership or even whether a step should exist.

A redesigned process may still contain several legitimate variants.

How can a redesigned process be tested before automation?

Teams can model the to-be process, compare it with the as-is process and use simulation or controlled pilots to test assumptions about cycle time, case volumes, resources, bottlenecks and exception behavior before committing those assumptions to production automation.

The automation build should start from the process the business wants to keep

An existing workflow contains more than business requirements. It also carries the residue of old systems, incomplete inputs, local fixes, duplicate checks and compromises that once solved practical problems.

Automation is very good at preserving repeatable behavior. That is precisely why the behavior deserves scrutiny first.

The as-is process can reveal where work occurs and how cases move. Redesign determines which of those movements still have a reason to exist. The future-state model turns that decision into something that can be reviewed, simulated and challenged before engineering begins.

Only after that point does faster execution become unambiguously useful.

When the process has been redesigned first, automation scales an operating choice the business has deliberately made. Without that work, it can just as efficiently scale the workaround.