Gap Analysis Between Two Process Models, Line by Line

Every as-is row walked to its fate in the to-be, then every to-be line walked back. Two residual gaps, one shared verb and one step neither model draws.

Numbers in this note carry source tags ([POLICY], [THREADS n=10], [MINE]). What the tags mean.

This piece stands on the returns case published on this site: damaged-delivery refunds at a mid-size online retailer, built only from public sources, namely a published returns policy [POLICY], help centre articles [HELP], ten public complaint threads I selected myself [THREADS n=10], consumer law [LAW] and a walk through the published customer journey [WALKTHROUGH]. No client, no engagement, no interview. The case has an as-is and a to-be model (section 3). Here they are reconciled row by row, in both directions.

A gap analysis between two process models is a ledger that takes every row of the as-is to its fate in the to-be, takes every line of the to-be back to the as-is row that justifies it, and records every row that has no partner in the other direction.

In short

• Run the pass twice. Forwards, each as-is row gets a fate and a requirement that closes it. Backwards, each to-be line gets the as-is row it answers, or a stated reason it exists without one.
• Forwards, the case's eight as-is rows give five closed gaps, two partly closed and one kept. The two partial ones share a break the case neither fixes nor lists as left alone: there is no written test of what counts as enough evidence.
• Backwards, three requirements answer no as-is row. Each names its reason: a guard rail, a risk the change creates, or a legal gate. A to-be line with no row and no reason is scope creep.
• The pass can only compare what is drawn. A step missing from both models produces no gap at all.

Why not just put the two diagrams side by side?

Because side by side answers "what changed", and a gap analysis has to answer "is every problem in the as-is either fixed or knowingly left?" Both diagrams can be internally consistent while the gaps sit between them.

Wikipedia's article on gap analysis opens: "gap analysis involves the comparison of actual performance with potential or desired performance." That is a performance gap, and it needs numbers this case cannot have: "How often cases stall today. It cannot be obtained from outside" (section 7, logged as OQ-06).

What can be done from outside is the structural gap: which as-is steps the to-be addresses, and through which requirement. It does not depend on notation. BPMN, which the OMG calls "the de-facto standard for business processes diagrams", draws shapes; the ledger works on the rows under them. The pack's as-is and to-be template writes steps as rows first, and "every numbered step becomes one task box" when you draw it.

The forward pass: every as-is row to its fate

The source is the as-is table in section 3.1 of the case: eight rows, step 6 split into 6a and 6b. "Where it breaks" is quoted from that table; fates come from sections 3.3, 3.4 and 4.

Five closed, two partly closed, one kept. Read the two partial rows together, because they are the same gap seen from two seats.

What the two partial rows have in common

Rows 4 and 5 break on one missing thing: a written test of what counts as enough evidence. The customer does not know what to send, and the agent has no rule for judging it. Row 4 of the stakeholder map gives the frontline agent D, decides in practice, over "Whether the evidence is 'enough' today", because "No written evidence test exists in any public source".

The to-be moves the two rules that can be applied mechanically (BR-04 and BR-11) into the pre-check, and puts a clock and an owner on any undecided case. Neither writes the test. Ambiguous photographs still reach a person who judges them alone, and two people can still reach two answers. The case just no longer stalls while they do.

That is my reading, not something the case states. Section 3.4 lists seven things deliberately not changed: change-of-mind returns, the 40 EUR threshold, the accounting posting, the payout window, the phone line, a status tracker and staffing hours. The evidence test is not there, and no requirement or open question names it.

So the ledger raises a question, not an error. Leaving the test alone in release 1 may be right. But a gap that is neither closed nor listed as kept is the one the first reviewer finds for you. Scorecard check 11 asks that "the to-be states what changed against the as-is, and what deliberately stayed the same"; the pass finds what fell off both lists.

Row 6a: one verb, two events

The as-is says the refund is "issued in 2 to 5 working days". The to-be diagram says "Refund issued, same working day". Section 3.4 says the "2 to 5 working day payout window" stays, because "That is a payment operation, not a decision".

All three hold if "issued" names two events: money reaching the customer in the as-is, the refund being triggered in the to-be. REQ-018 criterion 1 supports that reading: the pre-check can "issue it with no human involvement". But a reader comparing the two models sees a payout that suddenly got faster.

The fix is one word: "Refund triggered, same working day; payout unchanged". It is the process version of scorecard check 13, "Every criterion containing a duration names the event that starts the clock", and the row-level pass catches it because both labels land in one row.

The backward pass: every to-be line to the row it answers

Now the other direction. Every element of the to-be, and every requirement in the register, should point back to an as-is row. If it cannot, it needs a stated reason, or it is work nobody asked for.

Three lines have no as-is row, and that is expected: a change creates obligations the old process did not have. Holding customer photographs needs REQ-016. Letting a rule approve needs REQ-018 to stop it refusing. Deciding before the parcel arrives needs REQ-017. Each names its reason in the register.

The test for a line with no row: does it name a risk the change creates, or a legal obligation? If neither, it is a feature that arrived with the redesign, and it gets argued for on its own.

The step neither model draws

Look at the last row again: "none drawn". REQ-017 traces to OBS-08 in the brief: "A returned item is inspected on receipt, and the outcome of that inspection can change the refund." That observation is [HELP], so it is part of the as-is. Yet the as-is table in section 3.1 has no row for it, and the to-be diagram has no box for it either.

The consequence is the biggest risk in the case, and the ledger cannot see it. Section 3.5: "The condition dispute moves after the money." Today the sequence protects the goods-in lead "by accident"; in the to-be, the refund can be decided from photographs before the parcel arrives. Neither diagram shows the sequence, so neither shows it changing. The case catches the risk in prose and in the stakeholder map.

That is the limit of any line-by-line method. A step absent from both models produces no row, so it produces no gap. The defence sits outside the ledger: before the pass, take each observation in the brief and each stakeholder row and ask which as-is row it lives in. OBS-08 has no answer, and that is the finding.

The gap ledger, filled

Written for this piece from the case record, showing only the rows that need action. The case has no ledger, and its two reviewers never saw this sheet.

Forward

Backward

Not in either model: OBS-08, inspection on receipt [HELP]. Owner: goods-in lead, no name available (stakeholder row 3, OQ-03 for names). Action: draw it in the as-is, then re-run the pass.

The gap ledger, blank

Copy it under your two models. Forward first, then backward, then the last line.

Forward

Backward

Not in either model: [Every observation in your brief and every stakeholder row that has no as-is row. Draw it, then run the pass again]

Two rules. A "Partly closed" row is unfinished until its last column says where the rest went. And a backward table with no "none" in it deserves a second look, because a real change usually creates an obligation the old process did not have.

Where is this method weak?

It inherits every gap in the models it compares, as OBS-08 shows. It also makes every row look equally important: rows 2 and 6b both read "Closed", but only 6b is the problem the case exists for. The ledger finds what is missing; the problem statement decides what matters.

And it is my own case, read by me. A reviewer could argue that the 48 hour owner makes the evidence test unnecessary in release 1. Fair, and that answer still belongs in section 3.4, written down.

Where to start

Put your as-is rows in a column. Next to each, write the to-be step it becomes and the requirement that closes it. Stop at the first empty "Closed by" cell. Either you left it on purpose, and it goes on the "not changed" list with a reason, or you did not notice it.

The two models are in the case, section 3, and the row format comes from the as-is and to-be template. As-is before to-be covers why the failure branch has to be in the as-is before any of this works. The traceability matrix piece ties rules to requirements, criteria and tests, the same row-level discipline one layer down. The scorecard has checks 11 and 12 for the process models.

All field notes · The portfolio guide · More in The Case File