BPMN & Business Process Analysis

Designing the To-Be Process

18 min Lesson 8 of 10

Designing the To-Be Process

In the previous lesson you documented the as-is process — every hand-off, wait time, and workaround that exists today. That map is valuable precisely because it surfaces the pain. Now comes the creative and analytical challenge: designing the to-be process, the future state that your system or improvement initiative will deliver.

The to-be process is not a wish list. It is a rigorous, BPMN-modeled design that you can hand to developers, operations managers, and stakeholders as a shared contract for what the new system must do and how work must flow. Getting it right requires applying four improvement levers systematically.

The Four Improvement Levers

Every process improvement reduces to four fundamental interventions. Apply them in order — eliminating waste first, then automating what remains, then parallelizing independent work, then reordering to move slow or risky steps earlier or later.

1. Eliminate

Remove steps that add no value for the customer or the organization. Common targets are duplicate data entry (the same field typed into two systems), approval layers that rubber-stamp without reviewing, intermediate storage steps (printing a form only to scan it ten minutes later), and reconciliation tasks that exist only to fix earlier errors. Ask for every task in the as-is: "What would happen if we simply stopped doing this?" If the answer is "nothing bad," eliminate it.

2. Automate

Replace manual human effort with system execution wherever the decision rule is deterministic. A status-check task — "Is the invoice amount below the approval threshold?" — is a perfect automation candidate. So is any task that is purely data transformation (format conversion, field mapping, calculation). Automation in BPMN is represented by service tasks (the gear icon) rather than plain user tasks. Flag every plain task in the as-is and ask: "Does this require human judgment, or is it a rule the system can execute?"

3. Parallelize

Sequential steps that have no data dependency can often run at the same time. An online store that sequentially checks inventory, then charges the card, then notifies the warehouse could instead charge the card and check inventory in parallel, notifying the warehouse only after both succeed. A parallel gateway (+) splits the flow into concurrent branches and a second parallel gateway merges them, proceeding only when all branches complete. Parallelization directly reduces elapsed time (cycle time) without eliminating any real work.

4. Reorder

Move expensive or slow steps later and cheap validation steps earlier. A classic example: a mortgage lender historically ran a full credit-bureau pull (slow, costly) before verifying basic eligibility criteria (fast, free). Reordering the eligibility check to run first eliminates the credit-bureau cost for every ineligible applicant. Reordering also applies to approvals — pushing the human approval to the very end of an automated pipeline means the approver receives a fully prepared packet rather than a half-baked request.

Apply the levers in sequence. Automating a step you should have eliminated just makes waste faster. Paralelizing work you should have reordered can amplify a bottleneck. Eliminate first, automate second, parallelize third, reorder last.

Worked Example: Clinic Appointment Booking

Consider a small private clinic. The as-is process works like this: a patient phones the reception desk; the receptionist manually checks a paper diary for availability; the receptionist calls back the patient (often hours later) to confirm a slot; the receptionist then manually sends a reminder SMS by typing it into a phone. The doctor is only notified via a printout left on her desk the morning of the appointment. Cancellations are handled informally and the freed slot is rarely rebooked.

Applying the four levers:

Eliminate: The callback step (patient waits hours for confirmation) exists only because the paper diary is not available to the patient. An online booking portal eliminates both the callback and the receptionist data-entry step.
Automate: Reminder SMS, appointment confirmation email, and doctor schedule update are all deterministic — automate all three as service tasks triggered by the booking event.
Parallelize: Sending the patient confirmation and updating the doctor schedule have no dependency on each other — run them in parallel after booking succeeds.
Reorder: Move payment (or insurance pre-authorization) to the booking step rather than on arrival, so the slot is never wasted by a no-show who has not committed financially.

To-be clinic booking: payment is reordered to booking time, confirmations and reminders are automated service tasks running in parallel, and the callback step is eliminated entirely.

Drawing the To-Be Diagram: Practical Steps

Start from the as-is skeleton. Copy the pool and lane structure. You will modify it, not start from scratch.
Mark eliminated steps. Strike them out or delete them. Note in a comment why each was eliminated (traceability to your analysis).
Promote manual tasks to service tasks. Change the task marker from the default (blank) to the gear icon wherever automation applies.
Insert parallel gateways. Replace sequential flows between independent tasks with a parallel split (+) and a parallel join (+).
Resequence as needed. Move tasks and their connecting sequence flows to reflect the new order.
Validate the flow. Every token that enters the process must reach an end event. Trace at least three scenarios: the happy path, a rejection path, and a cancellation path.

Traceability rule: For every change between as-is and to-be, record the lever applied and the rationale. Your stakeholders will ask: "Why did you remove the manager approval step?" You need a documented answer, not a guess.

Common Mistakes to Avoid

Automating without eliminating first. If a duplicate data-entry step is automated, you now have a fast, reliable system doing something pointless. Eliminate it instead.

Parallelizing dependent tasks. Two tasks can only run in parallel if neither needs the output of the other. Sending a confirmation email before the payment succeeds is a flow error, not a parallelization gain.

Over-engineering the to-be. The to-be process must be achievable within the project budget and timeline. A to-be diagram that requires three new systems and a team of ten developers for a two-person process is not a design — it is a fantasy.

Never present the to-be as final without stakeholder sign-off. The to-be process will change how people work. Surprises at go-live destroy trust. Walk every process owner through the to-be diagram in a workshop before it becomes a requirement.

Linking To-Be to Requirements

Each change in the to-be process generates or modifies requirements. An automated service task becomes a functional requirement on the system. A removed approval step may require a business rule change (someone must update a policy document, not just a diagram). A parallel branch that requires two systems to exchange data creates an integration requirement. As the analyst, you are responsible for making these connections explicit — the to-be BPMN diagram is the bridge between the business case and the requirements specification.

In the next lesson you will learn how to measure whether the to-be process actually delivers the improvement it promises, using process metrics and analysis techniques such as cycle time, throughput, and cost-per-transaction.