The Process Map That Hid the Rework
A university's student enrolment process is documented as eight sequential steps from application to registration, taking an average of 11 working days. The registry manager says the process is 'fine, just slow'. A walkthrough of 30 cases shows: 40% of applications are returned to the applicant for missing documents; the document check step is performed twice, once by admissions and once by registry; staff maintain a shadow spreadsheet because the student record system cannot show document status; and peak-week volumes are four times the annual average. The documented process map shows none of this. The vice-chancellor has asked why enrolment takes so long and wants a lean review.
1. Explain why the documented process map is misleading and what modelling technique would reveal the real process.
Read the worked answer
The map is a prescriptive artefact - how the process is supposed to work - not a descriptive one. It records the eight happy-path steps and omits the variation that actually consumes time.
What it hides:
- The 40% return loop. This is the dominant source of delay. Loops are invisible on a sequential map.
- Duplicated document check. Two steps doing the same work; the map shows one.
- The shadow spreadsheet. A manual workaround compensating for a system gap. Not on any map, but it is where staff time goes and where errors originate.
- Peak load. A single average of 11 days conceals that peak weeks behave completely differently. Averages across a fourfold volume swing are meaningless.
Technique: build a descriptive model from observed cases - a swimlane diagram with the return loop drawn explicitly, plus a value-stream or flow analysis capturing wait time versus work time at each step. Sample across peak and off-peak. Validate with the staff who do the work, not only the manager who owns it. Then quantify: how much of the 11 days is queue, how much is rework, how much is genuine work.
2. The vice-chancellor has already decided the answer is 'lean review'. How do you respond?
Read the worked answer
Lean may well be the right lens, but the evidence should select the tool, not the other way round.
The 11 days is mostly wait and rework, not waste in the classic lean sense of the work itself. The 40% return loop is a quality-at-source problem - incomplete applications entering the process. Lean's answer (poka-yoke, right-first-time, standard work) is relevant, but so is a digital answer: the system cannot show document status, which causes both the duplicate check and the shadow spreadsheet.
So the honest response is: 'Lean analysis will be part of this, and it will tell us where the delay sits. It may also show that the fix is a system change and an applicant-facing checklist rather than process simplification.'
Practical approach: run the descriptive modelling first (1–2 weeks), present the flow data, and let the evidence determine whether the intervention is process redesign, system change, demand management (staggering peak), or all three. Do not contradict the vice-chancellor; reframe so the lean review is the vehicle for finding the real answer. If you simply execute a lean review on a process whose main problem is a missing system capability, you will optimise the wrong thing and the 11 days will not move.