Build an as-is/to-be gap table for an order-to-cash process where every quantified claim either links to the event-log extract or is stamped ASSUMPTION — no third category. Two claims that feel obviously true are not actually supported by the data; the graded skill is refusing to assert them.
Tomas Fernandes is a business analyst at Kestrel Components, a fictional industrial-fasteners manufacturer with plants near Pune and a distribution centre in Frankfurt. Finance is unhappy: cash collection is slow, order handling feels chaotic, and a transformation sponsor wants a gap analysis "with numbers, not adjectives" in two weeks. Tomas has one asset — a process-mining extract summarising six months of order-to-cash event data — and one rule he refuses to break: a number either traces to the extract or wears an ASSUMPTION label a reviewer can challenge.
Six months, 8,412 completed orders. This extract is the only data you have.
EVENT-LOG SUMMARY — Order-to-Cash, Jan-Jun (8,412 orders)
X1 Stage median cycle times (days):
order entry 0.6 | credit check 0.4 | fulfilment 4.2 |
invoicing 1.8 | payment received (from invoice) 51.0
X2 Order-entry rework: 27% of orders re-entered at least once
(top variant: unit-of-measure mismatch); median added delay
per reworked order: 3.1 days
X3 Credit check: 92% auto-approved same day; 8% manual review,
median 2.9 days for the manual subset
X4 Process variants: 214 distinct end-to-end paths; top 5 variants
cover 61% of orders
X5 Invoice disputes: 8% of invoices disputed; median resolution
19 days; dispute REASON is not captured in the system
X6 Payments: 41% of invoices paid after due date; DSO = 62 days
vs 45-day standard terms
X7 Invoicing: 96% of invoices generated within 2 days of despatch
X8 Fields NOT in this extract: order value, customer segment,
dispute reasons, credit-review outcomes, payment method
From the kickoff call — the beliefs your analysis will confirm, kill, or label. Two of them are traps.
SPONSOR NOTES (verbatim from kickoff)
B1 "Credit checks are the main reason orders are slow to ship."
B2 "Order entry is a mess — people re-key half the orders."
B3 "Invoice errors are why customers pay us late."
B4 "We have way too many process variants; nobody follows
the standard path."
B5 "Fix invoicing speed and DSO will come down."
Interrogate the extract before forming opinions. Fifteen minutes, no AI. For each line X1–X8, write one sentence: what this line proves, and one thing it cannot prove. X8 is the most important line in the extract — it is the list of things no claim can be built on. Keep this sheet open for the whole lab.
Test the sponsor's beliefs against the data. For B1–B5, mark each: SUPPORTED (cite X-line), CONTRADICTED (cite X-line), or NOT TESTABLE WITH THIS DATA (cite the gap). Do B1 and B3 yourself before asking AI anything — these two are where careful reading pays.
Get an AI first-pass gap table. Prompt: "From this event-log extract, draft an as-is/to-be gap table for order-to-cash with columns: capability, current state (quantified), target state, delta, enabler, owner. Cite the extract line (X1–X8) for every number. Where a claim needs data the extract lacks, write ASSUMPTION instead of a number." Expect it to comply imperfectly — that is the next step.
Audit every cell of the AI's table. Three failure patterns to hunt: a number that appears in no X-line (invented), a citation to an X-line that says something adjacent but different (stretched — e.g., citing X3 for a claim about shipping delay), and a target state pulled from thin air ("industry benchmark: 35-day DSO" — no such data was provided). Fix or label every violation.
Build the assumptions register. Every ASSUMPTION gets a row: ID | Assumption | Why needed | How to validate | Owner. Good register entries are falsifiable — "dispute resolution delays payment" becomes "A3: disputed invoices have materially later payment dates than undisputed ones; validate by joining dispute flag to payment dates; owner: finance data team." An assumption without a validation route is just an opinion with a label.
Write the to-be targets honestly. Targets you can anchor: rework rate (X2) has an obvious improvement lever; invoicing speed (X7) is already at 96% — note what that implies for B5. Targets you cannot anchor without new data: any DSO target decomposition, anything about dispute causes. Where the extract supports no target, the target cell says "requires baseline study" — that phrase is a finding, not a failure.
Rank the gaps by evidenced impact. Order the rows by delay-weighted evidence: 27% rework at +3.1 days each (X2) versus 8% manual credit reviews at +2.9 days (X3) versus dispute and payment behaviour (X5, X6) where impact on cash is real but causally unproven. Ask the AI to check your arithmetic on the weighted delays, then verify its arithmetic yourself — both directions.
Write the one-page readout. The gap matrix, the assumptions register, and a three-bullet summary: the biggest evidenced gap, the sponsor belief the data contradicts, and the one data investment (capture dispute reasons — X5/X8) that would unlock the currently untestable claims.
The most dangerous number in a gap analysis is the plausible one — it survives review precisely because everyone already believes it.
A complete lab has all of the following:
A gap analysis is only as strong as its weakest uncited number. Link every claim to the extract or label it an assumption with a validation route — and treat "the data cannot say" as a deliverable, because the sponsor's next data investment comes from exactly that list.