Choosing the Case Identifier
The most consequential decision in the project. A different identifier produces a different process, and the wrong one produces findings nobody recognises.
Procedure
Everything downstream depends on what a case is. Choose it wrong and the map is technically correct and operationally meaningless.
What makes a good identifier
It corresponds to the unit of work people think in. If the operation talks about orders, the case is an order.
It persists across the whole scope, from the first activity to the last.
It is present on every event, or can be derived.
It is unique, and does not get reused.
Validate it with the operation before building anything on it. Ten minutes with a supervisor prevents a month of rejected findings.
The one-to-many problem
The most common difficulty.
An order has several lines. A line can be on several deliveries. A delivery can cover several orders.
Choosing "order" makes line-level detail disappear. Choosing "line" makes the order-level view impossible and multiplies the log.
There is no correct answer, only a choice matched to the question.
Options: mine at line level and aggregate up, mine at order level and accept the loss, or build two logs.
Say which you did, with every finding, because two analyses at different levels will disagree.
Cases that span systems
An order in one system becomes a shipment in another with a different key.
Find the link table, which usually exists somewhere.
Where it does not, the join is a reconstruction and should be labelled as one, with a match rate reported.
Unmatched cases are a finding in themselves, since they represent work that falls between systems.
Identifiers that change
A quote becomes an order, with a new number.
A ticket is merged into another.
A case is split.
Each breaks the trace, and each needs a deliberate rule: follow the successor, treat as separate, or exclude.
Document the rule and report how many cases it affected.
Testing the choice
Pick twenty real cases and trace them by hand through the systems.
Compare against what the log produced.
Discrepancies are either a data problem or an identifier problem, and this exercise distinguishes them.
Show the twenty traces to the operation and ask whether they look right.
When to change it
Rarely, and it means rebuilding.
Change it if the findings are consistently rejected as not reflecting reality.
Change it if the question changed — a shift from cycle time to line-level fulfilment needs a different level.
Do not change it mid-analysis, because the before and after will not be comparable and the comparison is the point.
The twenty-case validation
An hour of work that prevents a month of rejected findings.
Pick twenty real cases across the range: fast, slow, reworked, cancelled.
Trace each by hand in the source system.
Compare against what the log produced for the same twenty.
Show the traces to the operation and ask whether they look right.
Discrepancies are either a data defect or a wrong identifier, and this exercise distinguishes them, which nothing else does.
Two logs rather than one
Where the one-to-many problem has no good single answer.
Build one log at header level — the order — for cycle time and customer-facing questions.
Build a second at line level for fulfilment and picking questions.
Keep them separate rather than trying to satisfy both with one.
State which log every figure came from, because the two will disagree on case counts and durations and the disagreement will otherwise be read as an error.
More work than choosing one, and less than defending a compromise nobody recognises.
When one identifier will not do
Real processes split and merge, and a single case notion cannot represent both.
One order becomes several shipments. Order-level cases hide shipment behaviour; shipment-level cases lose order lead time.
Several orders combine into one invoice, which is the same problem inverted.
A case moves between systems and changes identifier on the way.
The options: build separate logs at each level and answer different questions from each; or use an object-centric representation where tools support it.
Choose deliberately and say which you chose, because a reader comparing two figures from two case levels will otherwise conclude the data is wrong.