How process case studies differ from other business papers
Strategy papers argue about direction; process papers argue about flow. The evidence is a sequence: who does what, in what order, how long each step takes, and where work stops moving. The unit of analysis is not a company or a person but a path — an order travelling from click to dispatch, an invoice from receipt to payment.
That changes the writing in three ways. First, a map is worth more than a paragraph: even a simple numbered list of steps with times beats prose. Second, the villain is usually a queue, not a person — work stops moving at handovers, approvals and batch timings, and your analysis should say so. Third, the before/after structure is not optional garnish; it is the spine. Markers want to see the current state, the changed state, and the measure that connects them.
Process mapping: the minimum a marker expects
You do not need software. Three lightweight techniques cover virtually every student prompt:
- Numbered flow with times. List each step, its owner, and its duration. Mark the waiting gaps explicitly — that list alone will already show where the process bleeds.
- Swimlane sketch. One lane per role, steps left to right, arrows at each handover. Handovers are where queues form, so count your arrows: each one is a candidate bottleneck.
- SIPOC frame. For the process as a whole, name Suppliers, Inputs, Process, Outputs, Customers in five columns. Useful when the case expects you to define scope before diving in — one table, first page of analysis.
Whichever you choose, keep the units honest. "Three days" and "40 hours" are different claims; convert once, say which unit you are using, and stay with it.
Size the bottleneck: cycle-time calculator
Lean practice compares value-added time (the moments work actually changes) with total lead time (start to finish, waiting included). The ratio — often called process cycle efficiency — tells you how much of the journey is motion and how much is queue. The reading bands below are illustrative heuristics for coursework, not industry standards; use your course's guidance where it has one.
Cycle-time efficiency calculator
Runs in your browser — nothing is sent anywhereMeter fills to the efficiency percentage (illustrative bands: <10% waiting-dominated, 10–25% mixed, >25% flow-healthy).
The calculator's real lesson for writing: when efficiency is low, the improvement story is about waiting — handoffs, approval queues, batch timings — and almost never about people typing faster. Papers that attack worker speed while the queue dwarfs the work miss the whole point of the method.
Before and after: the two-paragraph pattern
"In the current state, an invoice travels eight steps across four roles. Touch time totals roughly 45 minutes, yet the average invoice takes 38 hours to reach payment, because two handovers queue: the approval inbox is checked twice a day, and the finance batch runs only on Thursday afternoons. Illustrative figures for teaching the structure."
Note the anatomy: step count, roles, touch time vs lead time, and the two named queues. No blame, just flow.
"Two changes target the queues rather than the touch time: approvals move to a same-day notification, and the Thursday batch becomes a daily run. On the illustrative numbers, lead time falls from 38 to about 10 hours while touch time is unchanged — the work did not get faster, the waiting did. A four-week pilot would track lead time and error rate to check the change holds."
Note: before/after pairs on the same measure, waiting identified as the lever, and a validation step. All figures illustrative — your case will supply its own, or you label the example as a model.
| Measure (illustrative) | Before | After | What it proves |
|---|---|---|---|
| Lead time, invoice receipt to payment-ready | 38 hours | ~10 hours | The queue, not the work, drove the delay |
| Touch time across all steps | ~45 min | ~45 min | No one was asked to work faster |
| Number of handovers | 8 steps / 7 handovers | 6 steps / 5 handovers | Fewer seams, fewer queues |
| Check to watch | — | error rate at pilot review | Speed bought without breaking accuracy |
The 5-step approach for a process case study
Define the path and its edges
Where does the work start and end? "Order placed to dispatch confirmed" is a scope decision — write it down, because a fuzzy edge makes every later number arguable.
Map steps, owners and times
Numbered list or swimlanes. Include waiting gaps as steps — they are not blank space, they are the finding.
Quantify the flow
Lead time, touch time, handover count. Run the calculator above on the case's numbers, or label your estimate as an estimate. One honest number beats three vague ones.
Locate the bottleneck and its reason
The queue with the longest wait is the bottleneck; the reason is usually a policy (batch runs, approval limits, shift timing). Name the policy — that is the thing a manager can change.
Write the before/after with a validation step
Same measure, two states, plus how you would check the improvement holds (pilot window, error rate, staff feedback). That last line is what separates a redesign from a daydream.
Worked mini-outline (illustrative scenario)
Scenario, invented for practice: a three-person accounts team at a mid-size wholesaler takes 38 hours on average from invoice receipt to payment-ready, and the CFO wants the number halved without hiring.
- Introduction and scope. Process: receipt to payment-ready. Thesis: "the delay lives in two queues, not in the team's pace; batching and approval timing explain most of the 38 hours."
- Current-state map. Eight numbered steps, four roles, touch time 45 minutes, waiting gaps marked at approval inbox and Thursday batch.
- Quantification. Efficiency: 45 minutes of value-added work against a 38-hour lead — most of the journey is queue (illustrative figures).
- Bottleneck diagnosis. The approval inbox check (twice daily) and the batch run (weekly) are policy choices, not capacity limits.
- Redesign. Same-day approval notifications; daily batch; two redundant steps merged. Touch time deliberately unchanged.
- Before/after. Lead time 38 → ~10 hours (illustrative); check: error rate and exception count over a four-week pilot.
- Limits. Invented figures; single site; assumes approval staff can absorb same-day cadence.
Pitfalls specific to process case studies
- Mapping without times. A flow with no durations can show order but cannot show pain. Times (even labelled estimates) are what let you point at a bottleneck.
- Attacking touch time. If the queue is 90% of the journey, faster typing changes nothing. Say where the waiting is before proposing effort changes.
- Before/after with different measures. Comparing hours before to satisfaction after proves nothing. Pick one measure and hold it constant across both states.
- Ignoring exceptions. Most processes run two paths — the standard one and the mess the exceptions cause. Markers notice when the messy path is missing.
- Design theatre. Recommending "automation" or "an ERP system" for everything is a mood, not a redesign. Name the exact step the change alters.
- Unlabelled numbers. Case figures are cited to the case; your own estimates are labelled as estimates. Never let a modelled number dress up as field data.
Flow-language drill
1. Lead time vs touch time — which does a low cycle-time efficiency indict?
2. The bottleneck is usually…
3. A credible before/after section needs…
Free tools that help with process papers
- Word counter — process papers carry tables and lists; check the budget after mapping, before writing.
- Readability checker — step descriptions sprawl; keep sentences short enough to follow while holding a coffee cup.
- Thesis statement generator — the one-line diagnosis ("the delay lives in two queues") is your thesis.
- Harvard referencing generator — if your course cites the lean or quality-management texts, format them once, properly.
Going further? The radical-redesign end of this subject has its own guide at business process reengineering case study writing, and when the "process" turns out to be a system problem, cross-check business problems case studies.
Have a process case with a deadline attached?
Send the case, the numbers it gives you, the word count and the deadline. You get a draft with the map, the queue diagnosis and a before/after section built to the brief — ready for your edits.
Frequently asked questions
What is a business process case study?
An assignment that follows one operational path — an order, an invoice, a patient, a part — from start to finish and asks how it could flow better. The expected output is a map of the current state, a diagnosis of where work waits, and a before/after improvement case with a measure attached.
How do I find the bottleneck if the case gives no numbers?
Use relative signals: the step with the most rework, the handover mentioned most in quotes, the queue described in the most detail. Count handovers — each arrow in a swimlane sketch is a candidate. State plainly that you are reasoning from description, not measurement.
Which metrics belong in a process case study?
The core set: lead time, touch (value-added) time, number of steps and handovers, and one quality check such as error or rework rate. If the case provides volumes or batch timings, add them. Two or three measures presented cleanly beat a dashboard of six.
Can I invent numbers for the before/after section?
Only as a clearly labelled model: "illustrative figures to show the structure." Real cases must be cited to the case. Markers penalise invented numbers far less than they penalise invented numbers pretending to be real — label, always.
How is this different from process reengineering?
Incremental process improvement trims the existing flow — shorter batches, fewer handovers. Reengineering questions whether the flow should exist at all and redesigns it from scratch. If your prompt says "radically redesign" or mentions reengineering, switch to the reengineering guide for that angle.
Was this page useful?