Business Analysis Notes

Case studies

Case Study: A Waterfall Approach to Restructuring Invoice Processing

4 min read · Updated

In short A company considered moving invoice processing to its head office and reducing the local team, under strict confidentiality. The analyst documented the current process through a series of interviews with the one available expert. The analysis showed the risk outweighed the savings, and the project was stopped: a valuable result in its own right.

Based on: R. Leyton, IIBA case study on a waterfall approach (invoice process restructure), series “How Do I Identify What Needs to Be Done”, 2021; IIBA, BABOK® Guide v3, Business Analysis Core Concept Model.

On this page

This page summarizes a published IIBA case study by Ryland Leyton in our own words. The facts of the case are his; the lessons section adds general practice.

Context#

Management was considering moving invoice processing to the head office, with fewer people, and possibly automating parts of it. No decision had been made about closing the local office, so the work was confidential: it could not be discussed with anyone outside the direct participants. Only one process expert, who would be kept on, was available to the analyst.

Approach#

The analyst framed the situation with the six core concepts of the Business Analysis Core Concept Model (BACCM) from the BABOK® Guide: - Change: move the work, possibly with automation. - Need: new staff must be able to run the process; the technical SME needs enough detail to judge automation; the director needs enough to assess costs. - Solution: whatever is chosen must let new people perform the process. - Stakeholders: the sponsor, a technical subject matter expert (SME), and the retained process expert. Staff who might be let go were deliberately kept out of the loop. - Value: savings on positions and possibly from automation. - Context: confidentiality and a tense situation for the people involved.

The task, documenting how the process works today, was clear and stable. A predictive (plan-driven, waterfall) approach therefore fit better than an adaptive one.

What the analyst did#

  • Ran an interview cycle of one-to-one sessions with the expert, following a steady rhythm: interview, refine the documentation offline, then review it with the expert the next day. The case describes this as a very common and successful pattern for analysis in complex or unfamiliar domains.
  • Modeled the happy path first: the main flow without errors, then the typical errors and how they are handled, then a final review.
  • Produced a set of deliverables: process diagrams for the happy path and for error handling, a catalog of systems and tools, a catalog of roles, the expert’s improvement suggestions, and a data catalog, possibly with an entity-relationship diagram.

Outcome: the analysis showed that moving the process would mean retraining a new team on systems they did not know. The risk was greater than the expected savings, and the project was closed on the strength of the analysis.

Lessons you can reuse#

  1. Choose the approach to fit the problem. A well-defined, stable task such as documenting a current process suits a predictive approach. Decide per piece of work, not by habit.
  2. Use the interview–refine–review loop. Short sessions, an offline write-up and a next-day review keep the expert’s workload light and surface misunderstandings within a day.
  3. Model the happy path first, then the exceptions. It gives everyone a stable backbone before the detail multiplies. Give the exceptions as much attention as the main flow; that is where new staff struggle.
  4. Plan for confidentiality. Agree with the sponsor who may be told what, restrict access to documents, and record dependence on a single expert as a risk.
  5. Build reusable catalogs. Catalogs of systems, roles and data are useful whatever the decision turns out to be.
  6. Treat “don’t do it” as a valid outcome. Analysis that stops a change whose risks exceed its value saves real money. Present the conclusion with evidence and tie it back to the value the sponsor expected.

Applying it at The Workshop (a fictional bike-repair chain): suppose the owner considers centralizing all parts ordering at one workshop. The analyst interviews the one manager who knows the supplier’s system well, documents the happy path and the common exceptions, and compares the time saved with the training and dependency risk. If the risk is higher, recommending “do nothing for now” is a legitimate result.

Sources#

  • R. Leyton. Case studies “How Do I Identify What Needs to Be Done” (agile and waterfall approaches). IIBA, 2021: waterfall approach, invoice process restructure.
  • IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015: Business Analysis Core Concept Model.