Project: As-Is to To-Be

Project: As-Is to To-Be

Every BPMN skill you have practised across this tutorial — events, tasks, sub-processes, gateways, pools, and lanes — converges in this capstone project. The goal of an As-Is to To-Be analysis is simple in concept but demanding in practice: document exactly how a process works today, measure its weaknesses, and redesign it to deliver measurable improvements. This lesson walks through a complete, realistic example so you finish with a repeatable methodology you can apply immediately on real engagements.

The Scenario: Patient Appointment Booking at City Medical Clinic

City Medical Clinic is a mid-size outpatient facility. Patients currently book appointments by phone during office hours only. Receptionists manually check paper scheduling books, confirm the slot verbally, and post a paper reminder card. The clinic loses approximately 18% of booked slots to no-shows and spends 40% of each receptionist's day on scheduling calls alone. Management wants a new online system that reduces no-shows and frees staff for higher-value work.

As a systems analyst, your first task is to document the As-Is (current-state) process faithfully — not the way managers think it works, but the way staff actually perform it. You then identify pain points, define improvement objectives, and produce a To-Be (future-state) BPMN model.

Step 1 — Discover and Model the As-Is Process

Discovery techniques include stakeholder interviews, process-walkthroughs (shadowing staff), and document analysis (call logs, scheduling books). From these you identify three participants: the Patient, the Reception team, and the Doctor. Each becomes a lane inside a single "Clinic Appointment" pool.

Key findings from discovery:

• Patients can only call during 09:00–17:00; calls outside those hours go to voicemail, adding a one-day lag.
• Receptionists check a paper diary — no real-time view of doctor availability.
• Appointment reminders are paper cards handed at the front desk or mailed; no digital reminder exists.
• No-show slots are never backfilled; the time is wasted.
• Doctors sometimes double-book because two receptionists update the same diary concurrently.

Step 2 — Pain-Point Catalogue and Improvement Objectives

After validating the As-Is model with stakeholders, list every identified pain point alongside a measurable target:

• P1 — Limited booking hours: patients can only call 09:00–17:00. Target: enable 24/7 self-service booking.
• P2 — No digital reminders: 18% no-show rate. Target: reduce no-shows to below 5% within six months.
• P3 — Double-booking risk: concurrent diary updates cause conflicts. Target: zero double-bookings via real-time locking.
• P4 — Receptionist overload: 40% of time on scheduling. Target: free at least 30% of receptionist time for patient care.
• P5 — No backfill: cancelled and no-show slots are wasted. Target: automatically offer freed slots to a waitlist.

Step 3 — Design the To-Be Process

The redesigned process introduces an Online Booking Portal (a new pool, because it is an automated system outside the clinic's organisation). Key design decisions:

• A timer start event triggers a 24-hour reminder message automatically.
• An error boundary event catches payment/confirmation failures gracefully.
• Parallel gateway fans out: the system books the slot and places the patient on a waitlist simultaneously, then joins before notifying the patient.
• A message event receives a cancellation, unlocks the slot, and triggers the waitlist sub-process.

Step 4 — Gap Analysis and Change Identification

With both models in hand, the gap analysis is a structured comparison: for each As-Is activity ask whether it survives, changes, or disappears in the To-Be; and for each To-Be activity identify whether it is new or transformed.

• Eliminated: paper diary updates, postal reminder cards, voicemail dead-end path.
• Transformed: receptionist no longer searches for slots — she monitors exceptions and handles escalations.
• New: online booking portal (system pool), 24-hour automated SMS/email reminder, real-time waitlist backfill.

Step 5 — Validate the To-Be with Stakeholders

Walk through the To-Be diagram with every stakeholder group: receptionists, doctors, the IT team, and — critically — patients (via user-research or focus groups). Common validation questions:

1. Does the new flow cover every exception the As-Is handled, plus the new ones introduced by digitisation?
2. Are the swim-lane responsibilities clear and agreed upon?
3. Is the automation scope realistic within budget and timeline?
4. Does the model satisfy all five improvement objectives stated in Step 2?

Revise until all stakeholders sign off. Only then should detailed specification and development begin. The completed As-Is/To-Be pair becomes the baseline for all subsequent system-analysis deliverables — requirements, data models, class diagrams, and test plans — bringing this tutorial full circle.