Skip to main content

Process passport

Purpose​

The process passport is an entry artifact for the Assessment stage. The process owner fills it before deep work on an AI initiative.

AI fit and deployment impact cannot be judged from a flowchart alone. They are predicted by concrete process properties — volume, data, type of work, cost of error — and one value formula. The passport forces the process to be described along those axes. The verdict “AI or not” and a draft value hypothesis fall out of the fill-in, not from intuition.

A completed passport delivers two things:

  • a verdict on AI fit and a route to a catalog AI product;
  • a value hypothesis with baseline — evidence for the stage gate.

The passport does not replace the gate. It supplies evidence. One process = one passport = one AI initiative with an owner.

Block A. Describe the process​

Do not draw a diagram for its own sake. Fill in the fields:

1. Process and owner​

  • Process name — as the business calls it.
  • Process owner — accountable for the process outcome, not for AI.

Without a named owner the passport is not accepted.

2. Trigger → outcome​

What starts the process and what comes out: a document, a decision, an action in a system.

3. Volume and frequency​

  • How many times per day / month.
  • How many people and hours per unit.

This is the multiplier for future impact — without it you cannot estimate impact.

4. Steps and their type​

Break the process into 3–10 steps. Assign each step a type:

  • reading / search
  • classification / prediction
  • draft generation
  • judgment / decision
  • action in a system
  • physical / manual work

Step type directly determines which AI product applies (see block B).

5. Data​

  • Which input data is needed.
  • Where it lives, in what form (text / table / image / audio).
  • How structured it is and how realistically you can access it.

“Data exists but cannot be exported” = no data.

6. Rules vs judgment​

Where rules are fixed, where expert judgment applies, where ambiguity remains. Where rules change often.

7. Current metrics (baseline)​

Cycle time, unit cost, volume, error rate, SLA — as they are today.

A blank here = nothing to confirm impact against later.

Block B. AI fit assessment​

Score the process on five axes. This is not a good/bad score — it is a map of where AI actually fits.

AxisAI fitsAI does not fit
Volume and repeatabilityfrequent, similar casesrare, every case is new
Datadigital and accessiblepaper, fragmented, no access
Type of worklanguage, patterns, extraction, draftsphysical action, need for 100% determinism
Cost of errorreview exists / low risk tiercritical and nothing to verify against
Rule stabilitystablechange daily

Step type → catalog AI product​

  • reading / search in documents → RAG
  • classification / prediction on tabular data → ML platform
  • draft generation, summarization, rewriting → LLM
  • multi-step action across systems → agent / orchestrator
  • writing and editing code → code agent

Stop signals​

If the process is rare, data is missing or inaccessible, the cost of error is critical with no way to verify, or strict determinism is required — AI is not the tool here.

Stating that in the passport matters more than forcing an initiative: the gate filters AI theater at intake, not on the pilot.

Block C. Impact assessment (value hypothesis)​

Impact per unit × volume, minus deployment and run cost. The formula is simple — discipline is in the fields.

1. Primary impact type (one)​

Time / cost savings · throughput · quality / fewer errors · speed / SLA · revenue / retention.

One primary type; the rest is secondary.

2. Baseline → target​

Take “as-is” from block A.7, set a target:

Impact = (baseline − target) per unit × volume from A.3

3. Risk tier (Low / Moderate / High / Critical)​

Control is proportional to risk: the higher the tier, the more review and the higher run cost — subtract that from impact.

4. Value evidence and impact owner​

What will confirm the impact is real, not “the model shipped”: accepted evidence, impact owner.

Without this the initiative does not pass the gate from Awaiting impact to On support.

5. Boundary (but-what)​

Where the calculation breaks: volume is lower than assumed, data is dirty, people must stay in the loop.

A named boundary increases trust in the estimate.

Place in the methodology​

The process passport is an artifact for Assessment in the business funnel (New → Assessment → Delivery → Awaiting impact → …).

  • block B gives the fit verdict and product route;
  • block C gives the value hypothesis and baseline checked against value evidence at the gate.

After the passport the initiative moves to the use case document and checks in the use case validation playbook.

Fill-in template​

=== Block A. Process ===
Process:
Process owner:
Trigger → outcome:
Volume and frequency:
Steps (3–10) and type of each:
Data (source, format, access):
Rules vs judgment:
Baseline metrics:

=== Block B. AI fit ===
Volume and repeatability:
Data:
Type of work:
Cost of error:
Rule stability:
Verdict (fit / no fit / partial):
Route to AI product:
Stop signals (if any):

=== Block C. Value hypothesis ===
Primary impact type:
Baseline → target:
Risk tier:
Value evidence and impact owner:
Calculation boundary:

Mini example​

A. Processing incoming supplier invoices. Owner — head of facilities. 2,000/month, ~8 min manual entry. Data — PDF/scan. Steps: read → extract fields → verify → enter in ERP.

B. High volume, digital data, work type — text extraction, review exists (accountant confirms) → high fit. Route: extraction → RAG/LLM, entry → agent. Risk tier — Moderate (errors caught by reconciliation).

C. Primary impact — time. Baseline 8 min → target 2 min per invoice × 2,000 = ~200 h/month. Impact owner — head of facilities; evidence — before/after time measurement on a sample. Boundary: if scans are poor quality, extraction degrades — need a confidence threshold and manual fallback.

Last updated on