Mapping the To-Be Process (BPD): Designing the Future Process

Estimated reading: 8 minutes 7 views

At the moment you’ve validated your as-is process and uncovered the true cost of inefficiency, the real work begins. You’ve seen the bottlenecks, the duplicated steps, the silent handoffs that cost days. Now, you’re not fixing these—they’re being replaced. This is where decision table modeling becomes your compass. The moment to shift from diagnosis to design is here. Many teams delay this phase, clinging to the safety of the familiar. But innovation doesn’t emerge from tweaking the present—it springs from imagining a system that doesn’t yet exist.

Over two decades of guiding BPR initiatives has taught me one truth: if you don’t start with a bold vision, you’ll end up with an improved version of what failed. To-be process design isn’t about automation. It’s about rethinking. It’s about asking: what would the process look like if we had no constraints—no legacy software, no old habits, no fear of disruption?

You’ll learn how to model that future state using BPMN, validate your decisions with value stream mapping, and execute the redesign with precision. By the end, you’ll have a living model—not just a diagram—for how your organization should operate, not just tomorrow, but in three years. This is where strategy becomes executable, and transformation begins.

Why To-Be Process Design Requires Radical Thinking

Most teams treat to-be design as a refinement of the as-is. That’s a fatal error. The as-is is a record of how things are. The to-be must be a declaration of how they should be.

When you see a workflow that takes four days to complete, the natural impulse is to reduce it to three. But what if you could reduce it to one hour? That’s not optimization. That’s reimagining.

Consider a loan processing team that manually verified documents across five departments. The as-is flow took 10 business days. The to-be process didn’t just automate— it eliminated the need for manual verification by integrating OCR and a rule engine. Now, decisions happen in real time. The process isn’t faster. It’s fundamentally different.

Don’t ask: “Can we fix this?”
Ask: “What if we remove this step entirely?”
Don’t ask: “How can we speed this up?”
Ask: “Why does this step exist in the first place?”

Value Analysis: The Foundation of Future-State Design

Every step in a to-be process must serve a clear purpose. Ask: does this activity add value from the customer’s perspective?

Value is not defined by effort. It’s defined by outcome. A document review may be essential, but if it doesn’t change the result, it’s waste. Use the Value Stream Mapping principle: classify each activity as either value-adding, non-value-adding, or necessary non-value-adding.

Activity Type	Definition	Example
Value-adding	Directly contributes to the customer’s desired outcome	Processing a loan application with correct data
Non-value-adding	Doesn’t contribute to the outcome and can be eliminated	Waiting for approval from a manager
Necessary non-value-adding	Required but doesn’t add value; must be minimized	Legal compliance checks

Redesigning for the future means eliminating non-value-adding steps. For every activity that doesn’t serve the end result, ask: “What if this didn’t exist?” If the process still works, it’s a candidate for removal.

Techniques to Drive Innovation in To-Be Design

Designing the future isn’t about logic alone. It’s about curiosity, challenge, and courage. Use structured innovation techniques to break free from mental models.

1. The Five Whys – Dig Beyond the Obvious

Ask “why” five times to uncover root causes. But go further. Use the answers to question the necessity of the step.

Example: Why does the loan officer need to verify income documents?

Because the system doesn’t trust the data.
Why doesn’t the system trust the data?
Because the documents are scanned and not digitized.
Why can’t they be digitized?
No OCR integration.
Why no OCR?
Legacy system doesn’t support it.
Why not upgrade?
Budget freeze.

Now you see: the real issue isn’t verification—it’s a lack of digitization. The to-be design doesn’t include manual verification. It includes automated OCR and trust rules.

2. Reverse Engineering the Outcome

Start from the end. What does the customer receive? How should it look? Then build backward through the process.

If the goal is a customer receiving a final loan approval within minutes, then every decision point must be designed to execute in seconds, not hours. This forces you to rethink handoffs, approvals, and data validation.

3. Process Innovation Through Decision Table Modeling

Decision tables are the backbone of to-be design. They allow you to model complex logic into structured, executable rules.

For example, in credit risk assessment, you have multiple conditions:

Income > $50k?
Debt-to-income ratio < 36%?
Bank account active?

Use a decision table to define rules:

Rule #	Income > 50k	DTI < 36%	Account Active	Action
1	Yes	Yes	Yes	Approve
2	No	Yes	Yes	Review
3	Yes	No	Yes	Review
4	No	No	No	Reject

This isn’t just logic. It’s a blueprint for automation. When you build your to-be process, embed decision tables directly into BPMN gateways. This ensures the model is both visual and executable.

Executing BPMN Redesign: Tools That Enable the Future

Modeling the to-be process is only effective if the tools allow you to design, validate, and deploy.

Visual Paradigm’s BPMN tools are not just for diagramming. They’re for engineering. The platform allows you to:

Map decision tables directly into gateways
Automatically validate process structure (no dead ends, no loops)
Simulate process execution under real-world conditions
Integrate with external systems via API connectors
Generate BPR artifacts (KPIs, WBS, rollout plans) from the model

Here’s a real example: a logistics company redesigned its delivery dispatch process. The as-is model had 12 steps, including manual dispatching. The to-be model reduced it to 4 steps—automated routing, real-time traffic integration, dynamic dispatch, and customer notification.

Using Visual Paradigm’s BPMN redesign features, we modeled the new process, linked decision tables for route optimization, and ran simulations showing a 65% reduction in dispatch time. The model wasn’t static. It evolved with feedback.

BPMN Redesign Checklist

Before finalizing your to-be process, verify:

Every activity adds value from the customer’s perspective
Decision points use decision tables, not guesswork
Parallel paths are minimized unless truly necessary
Gateways are clear: are they sequence, parallel, or inclusive?
Swimlanes reflect actual responsibilities—not just roles
Start and end events are properly marked

Moving from Design to Reality: What Comes Next?

Once your to-be process is validated, it’s not a decoration. It’s a contract. The next steps are to compare it against the as-is model, identify gaps, and build a work breakdown structure (WBS) to guide implementation.

Use the gap analysis not to highlight differences, but to expose risks: missing systems, untrained staff, untested integrations. Turn each gap into a task. Then assign ownership.

Your to-be process diagram is no longer a static image. It’s the foundation of execution. With Visual Paradigm, you can export it into a Gantt chart, link tasks to process steps, and track progress in real time.

Frequently Asked Questions

How do I know if my to-be process is truly optimized?

Optimization isn’t just speed. It’s alignment with business objectives. A process is optimized when it meets KPIs like cycle time, cost per transaction, and error rate. Simulate the model under real data. Compare results to the as-is process. If you’re not seeing 30–50% improvement, you’re likely still iterating, not redesigning.

Can I automate a to-be process without changing its structure?

Automation without redesign is not re-engineering. If you automate a flawed process, you amplify the flaws. The to-be process must be logically sound first. Only then can automation deliver value. Use decision tables and clean logic to ensure automation is built on a solid foundation.

Why use decision tables in to-be process design?

They make complex logic visible, testable, and maintainable. Without them, gateways become black boxes. With them, you can validate rules, detect conflicts, and ensure consistency. They’re especially critical when designing workflows involving compliance, risk, or eligibility rules.

What if my team resists the new to-be process?

Resistance isn’t about the process—it’s about fear of change. Involve stakeholders early. Let them see the simulation results. Show the before-and-after. Use the as-is to-be comparison to make the benefits tangible. The model isn’t imposed—it’s co-created.

How often should I revisit the to-be process after rollout?

Revisit it every 3–6 months. Markets shift. Systems evolve. The to-be model should be a living document. Use performance data from KPI dashboards to identify new bottlenecks. Update the model, simulate changes, and revalidate.

Is BPMN redesign the same as process reengineering?

BPMN is the language. Redesign is the action. Reengineering is the strategy. BPMN redesign is the technical implementation of reengineering. Without the model, you can’t validate the change. Without the redesign, you’re just improving what already exists.