Choosing the First Process

The first process should be chosen to succeed, not to be important. A failed first project usually ends the programme.

The criteria

One system, or at most two with a clean join. Every additional system multiplies the extraction time.

Status history available, which shortens the project by weeks.

High volume, so the analysis has enough cases to be credible.

A defined start and end, which most transactional processes have and most knowledge processes do not.

An owner who wants to change something, which is the criterion most often ignored and the most decisive.

The usual good candidates

Purchase to pay, which is transactional, high volume, single system and rich in compliance findings.

Order to cash, similar.

Service ticket handling, where the workflow tool logs everything.

Employee onboarding, which is bounded and full of handovers.

Claims handling, which is high volume with clear states.

What looks attractive and is not

The end-to-end value stream, which spans six systems and takes a year to extract.

The process everyone complains about, which is frequently complained about because it is genuinely complex and poorly instrumented.

A knowledge process with no defined start, end or case identity.

A process about to be replaced, where the finding will be obsolete.

A process owned by someone who did not ask for this, which produces a rejected analysis regardless of quality.

Testing the candidate quickly

Two days, before committing.

Ask whether a status history table exists. If not, ask what does.

Extract one week and count events per case.

Check whether a case identifier persists end to end.

Trace five cases by hand and see whether the log matches.

Ask the owner what decision they would make differently if they knew where cases waited.

If any of these fails, choose another process. The two days are cheap compared with a stalled project.

The scope of the first project

Narrow. One process, one boundary, one question.

Weeks, not months.

One finding delivered and acted on, which is the deliverable rather than a map.

Re-measured, which is what makes the case for the second project.

Sequencing after the first

The second process of the same type is much faster, if the pattern was recorded.

Extend the first boundary across a handover, which is where the larger findings are and which now has credibility behind it.

Add the compliance rules to continuous refresh, which is cheap and produces standing value.

Then a different process type, which restarts some of the learning.

The owner question, asked properly

The criterion most often skipped and the most decisive.

Not "would you like visibility". Everyone says yes.

Ask: what decision would you make differently if you knew where cases waited?

A specific answer means the project has a destination.

A vague answer means the analysis will be received politely and produce nothing.

Ask a second question: what have you already tried, and why did it not work. The answer tells you whether the constraint is knowledge or something else entirely.

Recording the pattern for reuse

The second process of the same type should take a fraction of the first.

Write down per process type: which table held the history, how the case identifier was formed, the boundary, the mapping approach, the defects found.

Include the queries.

Include the access route and who approved it, which saves weeks next time.

Include what took longest, so the next estimate is realistic.

Review after every few processes, because the pattern improves and a stale pattern is worse than none.

The checklist for the first process

Choosing badly costs the programme its credibility before it has any.

High volume, so variants and patterns are visible.

One or two systems, not seven.

A single clear case identifier.

A named owner who wants the answer, which matters more than any technical criterion.

A performance question in dispute, so the finding lands somewhere.

Not the most strategically important process, and not the most broken one. Pick the one where you can produce a verified finding within a quarter.