Process Design Is the Bridge Between Discovery and the Future Operating Model
Discovery explains how the business works today and why. Process design turns that evidence into a deliberate future way of working.
The objective is not to reproduce every existing step inside a new platform. It is to preserve what creates business value, remove waste where appropriate, standardize where possible and design controls that can operate sustainably after go-live.
13.1 Define Process Boundaries Before Drawing Diagrams
Agree the trigger, end condition, owner, upstream inputs and downstream outputs. A process map without clear boundaries quickly becomes either too detailed to govern or too broad to design.
Use enterprise value streams such as order-to-cash or procure-to-pay to establish context, then decompose them into manageable subprocesses.
13.2 Build the AS-IS from Evidence, Not Assumption
Capture what actually happens, including spreadsheets, emails, offline approvals, rework and exceptions. Formal procedures may describe policy while users describe reality; both matter.
Mark known pain points, delays, duplicate entry, manual controls and handoffs. The AS-IS should explain why the current process performs as it does.
13.3 Separate Necessary Complexity from Historical Habit
Ask whether each variation is required by law, customer commitment, operating model or genuine business need. Do not automatically preserve a step merely because it has existed for years.
Use Lean thinking carefully: remove non-value-adding activity without removing necessary control, evidence or segregation of duties.
13.4 Design the TO-BE Around Business Outcomes
Start with the future outcome, control environment and user responsibilities, then apply platform capability. A good TO-BE describes how the organization intends to operate, not just which screen users will open.
State where standardization is expected and where controlled variations are allowed.
13.5 Use Fit-to-Standard as a Design Discipline
Before proposing customization, understand how the standard platform supports the requirement and what process change would be needed to use it.
Fit-to-standard is not a command to ignore legitimate requirements. It is a deliberate challenge to prove why deviation from the standard is necessary.
13.6 Define Roles, Controls and Handoffs
Every key step should make accountability visible. Identify who creates, reviews, approves, reconciles and monitors the process.
Design exception paths and escalation routes. Handoffs between functions are common points of delay and should have explicit ownership and completion evidence.
13.7 Design Global Standards with Controlled Variants
For multi-country or multi-business-unit programs, define a core enterprise process and then document justified variants.
A local variant should have a reason, owner and governance status. This makes later rollout and support far easier than maintaining dozens of undocumented differences.
13.8 Validate the TO-BE with Scenarios
Walk realistic scenarios through the future process, including exceptions, period-end conditions and high-volume cases.
If stakeholders cannot explain how an important scenario flows through the TO-BE, the design is not ready for downstream configuration.
From the Delivery Floor
A distribution company documented eleven different order-entry processes across business units. Initial discussions assumed eleven separate solution designs would be required.
Detailed review showed that seven differences were historic habits, two were customer-specific service models and two were legal or tax requirements. The future design therefore used one common core process with four controlled variations.
The result reduced configuration complexity and made later training, testing and support significantly easier.
13.9 The Delivery Leader's View
Process design is where business transformation becomes visible. A delivery leader should challenge designs that simply digitize existing inefficiency.
Require evidence for deviations from the enterprise standard and make unresolved policy decisions explicit before build begins.
Chapter 13 Implementation Checklist
- Are process boundaries defined?
- Does the AS-IS reflect actual practice?
- Are pain points and controls visible?
- Has unnecessary historical complexity been challenged?
- Is the TO-BE tied to business outcomes?
- Has standard platform capability been considered first?
- Are roles and handoffs clear?
- Are exception paths designed?
- Are global and local variations governed?
- Has the TO-BE been validated using realistic scenarios?
Key Takeaways
AS-IS explains current reality; TO-BE defines the intended operating model.
Do not confuse automation with improvement.
Standardize where possible and justify every important variation.
Design exceptions and controls, not only the happy path.
Validate future processes with real business scenarios before configuration.
Closing Thought
A future-state process is successful when people can explain not only how it works, but why it is better and what evidence will prove that it is operating correctly.