On her first Tuesday inside a new engagement, a readiness assessor asks the operations director for something that sounds trivial: "Can I get the list of your processes?" The director opens a shared drive and produces three things. An org chart from January. A process catalog PDF from a 2021 consulting engagement, forty pages, beautifully formatted, describing a department that has since been reorganized twice. And a shrug: "Honestly, for month-end close, you just need to talk to Marta. She's been here nineteen years. It all lives in her head." That shrug is the real state of process knowledge in most organizations, and it is the wall every readiness assessment hits in week one. You cannot assess the AI readiness of processes nobody can name. Before any scorecard can rank anything, someone has to build the list, and this lesson teaches you to build it in two to three weeks instead of a quarter, using the toolkit you assembled in Chapter 2.1 and one new artifact: the Process Inventory Register.

The List Nobody Has

Here is an uncomfortable experiment you can run in any organization. Ask five managers in the same division to write down, independently, the ten most important recurring processes their teams execute. Then compare the lists. In a typical division you will get perhaps twenty-five distinct entries across the five lists, wildly inconsistent names for the same work ("client setup," "onboarding," "account activation" describing one process), and at least a few processes that appear on nobody's list yet consume real hours every single week. The organization is running on tribal knowledge: the veteran who carries the month-end close in her head, the exception workflow that exists only as a chain of forwarded emails with "FYI, this is how we handle these now" in the subject line, the approval path everyone follows because "that's how Dave set it up" even though Dave left in 2023.

Tribal knowledge is not a moral failing. It is what naturally accumulates when smart people solve problems faster than anyone documents the solutions. But for a readiness assessor it is a hard blocker, because every downstream instrument in this level depends on having a list. The readiness scorecard you will build in Chapter 2.5 ranks processes against each other: which one has the volume, the structure, and the measurable baseline that make it a strong first AI candidate? Ranking requires rows. If the rows do not exist, the scorecard is a fantasy, and the organization defaults to the pattern that produces the failure statistics you learned in Level 1: someone picks a pilot because a vendor demo was impressive or an executive had a hunch, and the pilot lands on a process nobody has mapped, where nobody agrees on the steps, the owner, or the volume. MIT's GenAI Divide research found that 95 percent of enterprise generative AI pilots deliver no measurable profit-and-loss return, and the autopsy pointed at missing workflow integration as a leading cause. You cannot integrate into a workflow you have never named. Unmapped processes are where pilots go to die.

There is a data-side cousin to this problem that you already know. Gartner found that 63 percent of organizations either lack AI-ready data practices or are unsure whether they have them, and predicted that through 2026, 60 percent of AI projects without AI-ready data will be abandoned. The process side has the same disease with less press coverage: call it the process-readiness gap, the one you met in Level 1. An undocumented process is to process readiness what an ungoverned spreadsheet is to data readiness. If the process exists only in Marta's head, then its steps cannot be verified, its volume cannot be measured, its exceptions cannot be counted, and any AI you point at it will be guessing at work nobody wrote down. The inventory is not paperwork before the real assessment starts. The inventory is the first assessment finding, and often the loudest one.

Until recently, producing a credible process inventory was a genuinely expensive undertaking. A consulting team would arrive, run six to ten weeks of workshops and interviews, transcribe everything by hand, argue about names in a conference room, and deliver a catalog that began going stale the day it was printed (see: the 2021 PDF on the shared drive). The economics have now changed, and they changed in your favor. The bottleneck in inventory work was never insight; it was reading. Someone had to read every transcript, every ticket export, every stale document, and hold hundreds of scattered mentions of work in mind at once. That is precisely the task at which a large language model is superhuman and a human is miserable. With the Chapter 2.1 toolkit (the four-part prompt, the Source Pack, the Output Skeptic's Checklist, the Verification Log), one trained assessor can now produce a defensible first-pass inventory of a division in two to three weeks of part-time effort. This lesson gives you the method: a four-stage funnel called harvest, extract, consolidate, validate.

The Artifact: The Process Inventory Register

Before the method, meet the deliverable, because every stage of the funnel exists to fill it. The Process Inventory Register is a single table, one row per process, and it is deliberately shallow: it does not contain process maps, step lists, or standard operating procedures (an SOP, the written step-by-step instruction set for doing a task the same way every time; the next lesson covers drafting those). The register answers exactly one question at scale: what recurring work exists here, and what is its basic condition? Each row carries these fields:

• Process name. A verb-noun name a stranger could parse: "Approve supplier invoices," "Onboard new distributor," "Reconcile daily cash position." Not "the Karen thing."
• Purpose in one sentence. What business outcome the process exists to produce. If you cannot write this sentence, you have found a candidate that is not actually a process yet.
• Trigger. What starts an instance: a calendar date, an arriving document, a customer action, a threshold breached.
• Owner. The single person accountable in practice, not the department name. When nobody can name one, write UNKNOWN in capital letters and leave it. An UNKNOWN owner is not a gap in your work; it is a finding about theirs, and later in this lesson you will see it become the headline of an executive briefing.
• Inputs and outputs. What the process consumes and what it produces, at the level of "supplier invoice PDF in; approved payment record out."
• Systems touched. Every application the work passes through, including the unofficial ones: the enterprise resource planning system, yes, but also the shared spreadsheet and the personal inbox where the real queue lives.
• Volume band. An order-of-magnitude estimate: per day, per week, per month, per quarter. Bands, not false precision; "roughly 300 a month" beats a fabricated "312."
• Pain level. A simple high, medium, or low, sourced from the people who run it. This is perception data and is labeled as such, but perception is where pilot enthusiasm and pilot resistance both live.
• Documentation status. Current, stale, or none. "Stale" means documentation exists but a practitioner tells you it no longer matches reality. This column, summed, is one of the two numbers leadership has never seen.
• Source of entry. The citation: which interview, which system export, which document produced this row. "Interview 4, min 12" or "Ticket category export, rows 210 to 260." This column is what makes the register defensible instead of arguable, and it is non-negotiable.

Notice what the register is optimized for: breadth with evidence. Fifty shallow rows with citations beat five deep process maps, because at this stage your enemy is the unknown unknown, the process nobody mentioned that will later eat a pilot alive. Depth comes later, and only for the processes the scorecard says deserve it.

You cannot assess what you cannot name, and a process is only named when a row exists with an owner, a trigger, and a citation behind it.

Stage One: Harvest, or Collecting the Raw Signals

The funnel starts wide and dumb on purpose. In the harvest stage you are not identifying processes; you are gathering every material in which processes leave footprints. Processes are like animals in a forest: you rarely see them directly, but they leave tracks everywhere. Your job in week one is to collect tracks from at least four different kinds of terrain, because each kind is biased and the biases cancel each other out.

• Structural sources. The org chart (roles imply work), the list of systems in use with their license counts (nobody pays for 40 seats of a claims tool without a claims process), and any report inventory (every recurring report is the output of some process, and someone somewhere assembles it).
• Operational exhaust. Ticket categories from the service desk, shared-mailbox folder names, request-form types, workflow states in whatever tracking tool exists. This is the least glamorous and most honest source you have: people lie in interviews without meaning to, but the folder named "Escalations - URGENT - Karen only" does not lie.
• Legacy documentation. The stale 2021 catalog, old SOPs, audit reports, the RACI charts (RACI: a responsibility matrix naming who is Responsible, Accountable, Consulted, and Informed for each activity) from the last reorganization. Stale documents are still useful as a checklist of what used to exist; every entry becomes a question, not a fact.
• Interviews. The richest source and the one you must run yourself: 30-minute "walk me through your week" conversations, recorded and transcribed with permission. Not "list your processes," which produces the official answer, but a walk through actual time, which produces the truth.

The 30-Minute Interview Script

The interview works because of a quirk of human memory: people cannot enumerate their processes in the abstract, but they can narrate their calendar with startling accuracy. Here is the script. Use it as written the first few times.

1. Minutes 0 to 3, setup: "I'm building a simple list of the recurring work in this division. Nothing you say is an audit finding about you. I'd like to record and transcribe this so I don't misquote you; is that okay?" (Get explicit consent, every time, and follow whatever your organization's policy says about recordings.)
2. Minutes 3 to 15, the walk: "Walk me through last week, Monday morning onward. What did you actually do?" Then steer gently with: "What kicked that off?" (trigger), "Where does that go when you finish?" (output and next process), "How often does that happen?" (volume band), "What system were you in?" (systems touched).
3. Minutes 15 to 22, exceptions: "What's the version of that task that goes wrong? What do you do then?" Exceptions are where hidden processes live; the workaround someone runs twice a week is a process, whether or not anyone blessed it.
4. Minutes 22 to 27, the three magic questions: "What work would pile up if you were out for two weeks?" and "What do you do that you suspect nobody else knows how to do?" and "If you could hand one recurring chore to a very reliable assistant, what would it be?" (That last answer is a pain-level reading in disguise.)
5. Minutes 27 to 30, close: "Who else touches this work before or after you?" Every name is your next interview candidate. Snowball until names start repeating; in a division, that usually takes eight to twelve interviews.

Harvest discipline matters because of a rule you learned in the clean-inputs lesson: the quality of what AI can extract is capped by the quality of what you feed it. Assemble everything into a Source Pack, the labeled bundle of inputs from Chapter 2.1: each transcript tagged with the speaker's role and date, each export tagged with the system and extraction date, the stale catalog tagged loudly as STALE, 2021, UNVERIFIED. Those labels will follow every candidate activity through the funnel and end up in the register's source column.

Stages Two and Three: Extract, Then Consolidate

Extract: one source at a time, citations mandatory

Now the AI earns its seat. In the extract stage you feed each source through an extraction prompt, one source per conversation, never the whole pile at once (a model given twelve documents will silently favor some and skim others; given one, it can be held to account for that one). The prompt follows the four-part pattern from the prompting lesson: role, task, context, format. A working version:

"You are a business process analyst reviewing raw material from an operations division. Your task: list every distinct recurring activity this material implies, whether stated directly or implied by a role, folder, category, or anecdote. For each candidate activity give: a short verb-noun name, what seems to trigger it, who seems to perform it, and the exact passage from the material that is your evidence, quoted verbatim. Rules: do not merge similar activities, do not skip small ones, do not add activities that are typical for organizations like this but absent from the material. If the material implies an activity but names no performer, write PERFORMER UNCLEAR. Format: a table with columns name, trigger, performer, evidence quote."

Two clauses in that prompt are load-bearing. "Cite the exact passage" converts every candidate from an assertion into a checkable claim; in the verification-habit lesson's terms, it makes spot-checking cheap. "Do not add activities that are typical for organizations like this" is your first defense against template gravity, the failure mode from the bad-output lesson: the model's pull toward producing what such a document usually contains rather than what your evidence contains. It will not fully hold (nothing fully holds against template gravity), but it lowers the noise floor.

Run every source through this. Expect the output to be a mess, and welcome the mess: duplicates by the dozen ("process invoices," "handle supplier bills," "AP entry" from three different interviews), fragments, activities too small to be processes, a few obvious misreadings. A division-sized harvest typically yields between 150 and 250 candidate activities. That number should feel absurd. It is supposed to. The funnel narrows next; the extract stage's only job is recall, and this is where AI is at its strongest: it reads nine transcripts and six exports without fatigue, it never gets bored on page 40, and it will surface the reconciliation task mentioned once at minute 27 of interview six that every human reviewer would have skimmed past. In inventory work, the forgotten process is the expensive one, and tireless recall is exactly the tool that finds it.

Consolidate: AI clusters, the human decides

Consolidation turns 200 candidates into a few dozen named processes, and here the division of labor flips. The AI is excellent at the mechanical half: paste in the full candidate list and ask it to "group candidates that appear to describe the same underlying process, propose one verb-noun name per group, and list the member candidates with their citations under each group." It will do in four minutes what used to take a wall of sticky notes and an afternoon.

But the AI must not make the granularity call, because granularity is a judgment about how the organization should see itself, and the model has no stake in being right. You will hit the eternal question within the first ten groups: is invoice-exception handling its own process, or a branch inside accounts payable? Is "onboard new distributor" one process or four? Left alone, a model will answer by vibes, and its vibes come from training data, which means template gravity again: it will shape your inventory to look like a generic company's inventory. So you decide, using a practical three-question rule. Split an activity out as its own process when it has all three: its own trigger, its own owner-in-practice, and its own failure mode.

Three yeses: invoice-exception handling gets its own row. If it had shared AP's owner and simply been a slower path to the same failure, it would be a branch, not a process. The rule is not sacred; it is a tiebreaker that makes your granularity decisions consistent and explainable, which is what matters when a department head challenges a row in the validation meeting. Consistency you can defend beats theoretical purity you cannot.

Consolidation is also where the AI's danger peaks, so run the Output Skeptic's Checklist on the clustered output before you accept it. Three tells deserve special attention in this specific task. First, the orphan row: a named process in the consolidated list whose member candidates you cannot find in the extract tables. That is template gravity graduating from noise to fabrication; the classic is a "vendor onboarding" process appearing because most companies have one, not because your evidence does. Every row must trace to citations, and a row that cannot is deleted on the spot, no matter how plausible it sounds; plausible is precisely what fabrication looks like. Second, the false merge: two teams' same-named work fused into one process. If sales operations and client services both said "client onboarding," the model will happily cluster them, even when one onboards distributors into an ordering portal and the other onboards enterprise accounts into a support plan: different triggers, different owners, different failure modes, two rows. Same name is a hypothesis, never a proof. Third, the confident owner: a name in the owner column that no source actually stated. Models complete tables the way water fills holes; if the evidence said PERFORMER UNCLEAR, the register says UNKNOWN, and any named owner must trace to a citation like every other field.

Stage Four: Validate, or the 20 Minutes That Save the Engagement

The consolidated register is now a hypothesis with citations. Validation turns it into a finding. The mechanics are cheap: send each interviewee the ten to fifteen rows their material contributed to, then book 20 minutes to walk them: "Is this real? Is the name right? Is that actually the owner? Did we merge two different things? What's missing?" Because every row carries its source citation, disputes resolve by evidence instead of by rank or volume: "Row 31 came from your description at minute 14; here's the quote; did I misread it?" Expect validation to change 10 to 20 percent of the rows: merges you got wrong, splits you missed, owners corrected, and usually two or three genuinely new processes that surface only when people see a list and notice what is absent from it. That churn is not a quality failure. It is the quality process, and the fact that the register visibly changed in response to their input is what converts interviewees from sources into co-authors who will defend the inventory in the workshop instead of sniping at it.

The failure story: the merged onboarding

Here is what skipping this stage costs, in a composite story assembled from real failure patterns; treat the details as illustrative. An assessor at a financial services firm, running two weeks behind, decides the consolidated register looks clean enough to ship: 60 rows, tidy names, full columns. The model had merged two departments' "client onboarding" into a single row, and because the owner field looked bare, it had filled in the most-mentioned plausible name, a team lead from one of the two departments. No validation pass, so nobody caught either error. Three weeks later, the register goes up on screen in the readiness workshop, both department heads in the room. One reads the row and says, slowly, "That is not our process, that is not how ours starts, and she does not own it." The other department head agrees, for opposite reasons. In ninety seconds, in front of the executive sponsor, the room has learned that the inventory contains at least one fabricated fact, and every other row is now suspect. The assessor spends the rest of a six-month engagement re-earning trust one verified row at a time, and the readiness scorecard, built on the disputed inventory, has to be re-baselined. The 20-minute confirmation pass with each interviewee would have cost about four hours total. The lesson from the verification-habit lesson applies with full force here: the checker's name is on the artifact, and the workshop is the worst possible place to run your first check.

A Worked Example: 140 People, Three Weeks, Two Numbers

Now the whole funnel, end to end, with hypothetical numbers you can use to calibrate your own first run. All figures here are illustrative, not benchmarks.

The setting: a 140-person operations division of a mid-sized distributor. The assessor (one person, working the inventory roughly half-time alongside other duties) harvests for a week and a half: 9 recorded interviews using the script above (snowballed from an initial three until names repeated), 6 system exports (ticket categories, shared-mailbox folders, report inventory, workflow states from two tools, license list), and the inevitable stale process catalog from a 2021 engagement, tagged as unverified history.

Extraction runs each of the 16 sources through the citation prompt: approximately 210 candidate activities, duplicates and all. Consolidation clusters them into 54 proposed processes; the assessor applies the trigger-owner-failure rule, deletes two orphan rows with no traceable citations (one of them, naturally, a "vendor onboarding" process the evidence never mentioned), and splits one false merge. Validation, nine 20-minute calls, merges four rows, splits two, corrects five owners, and surfaces three processes nobody had mentioned until they saw the list. Final register: 47 processes.

And now the two numbers that justify the whole exercise. Of the 47 processes, 11 have owner UNKNOWN: nobody in a 140-person division could name who is accountable for nearly a quarter of its recurring work. And 29 of 47, about 62 percent, have documentation status "none" or "stale." Those two numbers are the readiness story, and leadership has never seen either of them, because nobody had a denominator before. They echo the Gartner data finding almost eerily (63 percent of organizations lack AI-ready data practices; here, 62 percent of processes lack current documentation), and they explain in advance why a pilot dropped into this division at random would likely join MIT's 95 percent: most landing zones are unmapped and un-owned. The register does not just enable the Chapter 2.5 scorecard; its summary row is the first executive slide of the entire assessment.

The cost: roughly 35 assessor hours across three weeks (about 8 for interviews and consent logistics, 6 for harvest wrangling, 7 for extraction runs and spot-checking citations, 8 for consolidation and granularity calls, 6 for validation calls and corrections). The traditional comparison, a consulting-style manual inventory of the same division, would plausibly run 8 to 10 weeks of team effort at a five-to-low-six-figure price, and would be no more defensible, because defensibility comes from the citations and the validation pass, not from the day rate. This is BCG's 10-20-70 arithmetic showing up at the level of a single artifact: the model is 10 percent of the outcome; the harvest discipline and the human judgment calls are where the value lives.

What to Do Monday Morning

You do not need permission for a division-wide program to start this. You need one department and a calendar.

1. Book three "walk me through your week" interviews in one department, 30 minutes each, using the script from this lesson. Ask for recording consent in the invitation so nobody is surprised, and check your organization's recording policy first.
2. Harvest that department's operational exhaust in one hour: ticket categories, shared-mailbox folder names, the report list, the systems they touch. Label everything into a Source Pack with dates and origins.
3. Run the extraction prompt on each source separately, citations mandatory, and spot-check five quoted passages per source against the original before trusting any of it. Expect noisy, duplicated output; that is the funnel working.
4. Draft your first 15-row Process Inventory Register with every column filled or explicitly marked UNKNOWN, and every row carrying its source citation. Apply the trigger-owner-failure rule to at least one granularity dispute so you have practiced the call.
5. Flag every UNKNOWN owner and every "none or stale" documentation status, count them, and write the two counts at the top of the page. Then send the 15 rows back to your three interviewees for a 20-minute confirmation each. What comes back corrected is your first validated inventory, and the seed of your Level 2 capstone scorecard.

Key Takeaways

• Treat the missing process list as the first readiness finding: most organizations run on tribal knowledge, and you cannot assess, integrate into, or pilot on a process nobody can name, which is one reason MIT found 95 percent of GenAI pilots deliver no measurable return.
• Build the Process Inventory Register as one row per process: name, one-sentence purpose, trigger, owner (or UNKNOWN), inputs and outputs, systems touched, volume band, pain level, documentation status, and a source citation for every single row.
• Run the four-stage funnel in order: harvest raw signals from structure, operational exhaust, legacy documents, and 30-minute "walk me through your week" interviews; extract candidates with mandatory citations; consolidate with human granularity judgment; validate with the people who gave you the material.
• Use the AI where it is superhuman (tireless recall across hundreds of pages, surfacing the process mentioned once that everyone forgot) and never where it is dangerous (granularity calls, owner attribution, deciding what is real).
• Apply the three-question granularity rule to every split-or-merge dispute: a process earns its own row when it has its own trigger, its own owner-in-practice, and its own failure mode.
• Hunt the three inventory-specific tells with the Output Skeptic's Checklist: the orphan row with no citations (template gravity, like an invented "vendor onboarding"), the false merge of two teams' same-named work, and the confidently named owner no source ever stated.
• Never skip validation: 20 minutes per interviewee, disputes resolved by citation, expecting 10 to 20 percent of rows to change; the merged-onboarding failure story shows that the workshop in front of both department heads is the most expensive place to run your first check.
• Report the two summary numbers the register produces (share of processes with UNKNOWN owners, share with no current documentation) as the opening readiness story, and carry the validated register forward as the raw material for the Level 2 capstone scorecard.