01 / Definitions
Two different questions, two different tools.
Process optimization asks: how do we make the current process faster, cheaper and more reliable? Process reengineering asks: should this process exist in this form at all—and what would it look like if we designed it for today's business instead of yesterday's constraints?
02 / Key differences
The distinction is scope and ambition of change.
Optimization vs reengineering.
| Dimension | Optimization | Reengineering |
|---|---|---|
| Starting point | The existing process | The business outcome |
| Change | Incremental improvement | Fundamental redesign |
| Risk | Low to moderate | High; change management is essential |
| Speed | Weeks to months | Months to a major program |
| When it fits | Process is sound but inefficient | Process was built for outdated constraints |
03 / When to reengineer
Redesign when the process itself is the problem.
- The process exists to serve an outdated technology or structure.
- Performance is far below what the business needs, and tuning will not close the gap.
- The process creates outcomes nobody can defend—duplicate records, multiple owners, no single source of truth.
- A major system or business-model change is happening anyway.
- The organization can absorb the disruption and change management effort.
04 / When to optimize instead
Optimize when the process is fundamentally sound.
- The workflow produces the right outcome but has friction.
- Bottlenecks are identifiable and fixable without redesign.
- The current structure is understood and mostly consistent.
- The business cannot absorb a big disruption right now.
05 / How to reengineer
Design from the outcome backward.
- Define the outcome the process must produce, not the steps it currently takes.
- Identify which constraints are real (regulation, physics, customer expectation) and which are inherited habits.
- Map the future state as a clean design, then validate it with the people who do the work.
- Plan the transition honestly: parallel runs, training, controls and rollback points.
- Reengineer in bounded scope—one process at a time—rather than all at once.
06 / Risks and mistakes
Reengineering fails when it becomes theater.
- Renaming the old process and calling it reengineered.
- Redesigning without the people who run the work daily.
- Ignoring data quality—new processes run on old, dirty data.
- No change management, so the old process quietly returns.
- Reengineering everything at once and losing the business during transition.
07 / A practical example
From departmental silos to one operating flow.
A business where sales keeps its own order book, warehouse keeps stock in a spreadsheet and finance builds invoices from memory has three versions of one transaction. Optimization would speed each silo.
Reengineering would collapse them into a single order-to-cash flow with one record, one owner and one system—changing the process's structure, not just its speed.
08 / Conclusion
Choose the tool that matches the gap.
Both paths require the same first step: understanding the current process honestly. Optimization improves what exists; reengineering replaces it. The gap between current and required performance decides which one you need.
A useful next step