luvv to helpDiscover the Best Free Online Tools
Topic 2 of 12

Understanding As Is And To Be

Learn Understanding As Is And To Be for free with explanations, exercises, and a quick test (for Business Analyst).

Published: December 20, 2025 | Updated: December 20, 2025

Why this matters

Quick prompt set for SME interviews
  • What triggers this process? What ends it?
  • What are the top 3 delays or rework loops?
  • Which systems do you touch? Any cut-and-paste moments?
  • Where do items wait? For how long?
  • What happens on exceptions? Who decides?

Designing the To-Be process

  • Start from outcomes: shorter cycle time, fewer errors, better compliance, improved UX.
  • Apply simplification: remove unnecessary approvals, merge steps, automate checks.
  • Add control points: clearly defined decision gates and escalation paths.
  • Define metrics and acceptance criteria for success.
Checklist: Is your To-Be ready?
  • All roles identified and lane assignments confirmed.
  • No orphan tasks; each task has clear inputs/outputs.
  • Gateways reflect business rules you can state plainly.
  • Non-happy paths (exceptions) are covered.
  • Metrics and success criteria are attached to key steps.

Gap analysis and prioritization

Compare As-Is vs To-Be across people, process, technology, and data. Each gap should have an owner and a feasibility rating.

  • People: new skills, roles, or approvals needed?
  • Process: steps to merge, remove, or add?
  • Technology: integrations, forms, automations, data quality fixes?
  • Data: sources, definitions, and governance changes?
Prioritization mini-tool

Score each change 1–5 on Impact and 1–5 on Effort. Prioritize High Impact, Low Effort first.

Worked examples

1) Invoice approval

As-Is: Accounts Receivable emails PDF to manager → waits 3 days → manager forwards to finance → duplicate checks happen late → rework.

To-Be: Supplier portal auto-validates invoice fields → BPMN task assigns approval to correct manager via rules → timer triggers reminder in 24h → finance sees only exceptions.

Expected impact: Cycle time from 4 days to 1 day; error rate down by 60%.

2) Employee onboarding

As-Is: HR sends forms, IT creates accounts after HR email, manager forgets equipment request → day-one delays.

To-Be: Single request form triggers parallel tasks to HR, IT, Facilities via a gateway; SLA timers and escalations set at each lane.

Expected impact: Day-one readiness from 70% to 95%.

3) Customer complaint handling

As-Is: Complaints arrive via email; triage inconsistent; escalation unclear.

To-Be: Unified intake with mandatory fields → priority decision gateway → standard tasks with service levels; customer notified at key events.

Expected impact: First response time cut by 50%; better audit trail.

Field guide: capture As-Is quickly

  • Timebox: 45–60 minutes per sub-process.
  • Use the "one real case" rule to avoid hypotheticals.
  • Mark known unknowns with a triangle symbol or clear note to investigate.
  • Keep BPMN minimal: events, tasks, gateways, lanes, data objects, message flows.
  • Validate in a 15-minute playback meeting.
Mini task: Identify the start and end events

Pick any routine process you know. Write one sentence for the start trigger and one for the end condition. Keep them observable and testable.

Metrics and acceptance criteria

  • Cycle time: median time from start to end event.
  • Throughput: items completed per week.
  • First pass yield: % completed without rework.
  • SLA adherence: % meeting promised time.
  • Error rate: % items with defects or escalations.

Acceptance criteria example: "Reduce median onboarding cycle time from 5 days to 2 days within 60 days of go-live; maintain FPY ≥ 90%."

Exercises

These exercises mirror the tasks analysts do in real projects. Complete them before the quick test.

Exercise 1 — Map a simple As-Is

See details in the Exercises section below (Exercise ID: ex1).

Exercise 2 — Design a To-Be and gaps

See details in the Exercises section below (Exercise ID: ex2).

Self-check checklist
  • I defined clear start and end events.
  • Every step has an owner (lane) and an input/output.
  • Gateways reflect real business rules (not guesses).
  • Exceptions and rework loops are visible.
  • Metrics and acceptance criteria are attached to To-Be.

Common mistakes and how to self-check

  • Vague outcomes: If you can’t state the end event in one sentence, refine scope.
  • Skipping exceptions: Add at least the top 2 exception paths.
  • Over-modeling: Use minimal BPMN; avoid custom symbols.
  • Process vs. org chart confusion: Lanes are roles in the process, not necessarily departments.
  • No metrics: Add cycle time and FPY targets to To-Be.
Fast self-audit

Pick any gateway. Can you state its rule as "If [condition], then [path A]; else [path B]"? If not, clarify the rule with SMEs.

Practical projects

  • Map your team’s request intake As-Is, then propose a To-Be with a single decision gateway and a timer event for reminders.
  • Create a To-Be for onboarding a new vendor with automated validation and parallel tasks for compliance and finance.
  • Run a 2-week pilot: measure cycle time and FPY before vs. after; present a one-page impact summary.

Who this is for

Business Analysts, Process Analysts, Project Managers, and anyone improving operations.

Prerequisites

  • Basic BPMN shapes: events, tasks, gateways, lanes.
  • Comfort interviewing stakeholders.

Learning path

  • 1) Understanding As-Is and To-Be (this lesson)
  • 2) BPMN Gateways and Exceptions
  • 3) Metrics and SLAs in Process Design
  • 4) Change Impact and Rollout Planning

Mini challenge

Pick a simple process (e.g., leave approval). In 20 minutes, sketch:

  • As-Is: 5–7 steps with at least one exception.
  • To-Be: reduce one approval and add a timer reminder.
  • Metric: target cycle time and FPY.
Tip

Use timeboxing: 10 min As-Is, 7 min To-Be, 3 min metrics.

Next steps

  • Complete the exercises below and compare with the sample solutions.
  • Take the Quick Test to validate your understanding.
  • Apply this on a live process with real metrics for two weeks.

Quick Test

Everyone can take the test for free. If you are logged in, your progress will be saved so you can return anytime.

Practice Exercises

2 exercises to complete

Instructions

Scenario: A customer submits a support ticket by email. A support agent triages it, then either resolves it or escalates to a specialist. If escalated, the specialist resolves and informs the agent, who replies to the customer. Sometimes the customer sends incomplete info; the agent requests more details and waits.

  • Define clear Start and End events.
  • List lanes (roles) and key tasks.
  • Draft a text-based BPMN flow (no drawing tool needed).
  • Include one exception for missing information.
Optional format hint

Use lanes: Customer | Agent | Specialist. Use events: Start, End. Use gateways: Exclusive (XOR). Show message flows as [message] between lanes.

Expected Output
A structured, text-based BPMN outline with Start/End events, lanes, tasks, an exclusive gateway for triage, and an exception path for missing information.

Understanding As Is And To Be — Quick Test

Test your knowledge with 6 questions. Pass with 70% or higher.

6 questions70% to pass

Have questions about Understanding As Is And To Be?

AI Assistant

Ask questions about this tool