Skip to main content

Process Inventory

What happens when a team improves a process it never finished listing?

Problem: Work nobody named is work nobody owns, measures, or delegates. Guidance, examples, and metrics drift into the process folder, and the folder stops answering the only question it exists to answer.

Question: What is the total set of jobs and tasks that must be managed to run this function end to end?

Decision: Freeze one complete job inventory, with stable identifiers, before mapping, modelling, or allocating any single job.

This method produces a function's job inventory: mutually exclusive jobs, verb-led task statements, stable IDs, a routing decision for every page that is not a job, and gaps declared rather than hidden.

Inputs​

  • A named function and its boundary: one business capability or one industry.
  • The people and agents who perform, receive, or inspect the work.
  • An external reference inventory for that function, used as a completeness check rather than a template to copy. Cross-industry work has APQC's Process Classification Framework; sectors have their own, such as SCOR for supply chain, eTOM for telecom, BIAN for banking, ACORD for insurance, and ITIL for IT services.
  • Every page that currently sits in the function's process folder, whatever shape it is in.
  • The function's other four pillars, which are the routing destinations for content that is not a job.
  • An owner who can accept the inventory and resolve a disputed boundary.

The Five Levels​

An inventory is a hierarchy, and confusing two levels is what makes a process folder unusable. Five levels, each with one meaning:

  • Function — the capability or industry itself. sales
  • Stage — a group of jobs that share a position in the flow. It is a heading, not a page. sales.close
  • Job — one unit of work that must be managed. It gets one page. sales.negotiate-deal
  • Task — one action inside a job. It gets one row in that job's task table. sales.negotiate-deal.T03
  • Step — the numbered instructions for performing a task. It lives inside the job page and is not separately indexed.

The job is the unit of ownership. The task is the unit of allocation: it is the row that later carries a player, a human or agent split, a skill, and a tool. Cutting the hierarchy off above the task leaves nothing to allocate; extending it below the step produces a manual nobody maintains.

This matches the five levels most process frameworks converge on, which run category, process group, process, activity, task. The names differ; the discipline of one meaning per level does not.

Build The Inventory​

  1. Set the function boundary. Name what the function is accountable for, the first work it owns, the last work it owns, and the neighbouring functions on each side. Output: a one-sentence scope and two named handoffs.
  2. Name the stages. Group the flow into the smallest number of stages that a practitioner recognises, ordered as work actually moves. Output: an ordered stage list.
  3. List the jobs. Sweep for the work that must be managed in each stage, then sweep again for the work that has no stage: recurring cadence work, governance and review work, enablement work, and exception or failure work. Ask the people who do it, not only the people who describe it. Output: a job list with each job assigned to one stage.
  4. Test the list for completeness. The inventory must cover planning, doing, measuring, improving, and governing. Jobs must not overlap, and together they must account for the whole function at the level declared. Compare against the external reference inventory last, to find what was forgotten rather than to import a structure. Output: added jobs, merged duplicates, and a recorded completeness check.
  5. Write the task statements. Decompose each job into the actions it is made of, using the statement rule below. Output: a task list per job.
  6. Mark core or supplemental. A core task is performed by anyone running this job. A supplemental task belongs to some contexts only. Both stay in the inventory; the distinction keeps the spine readable. Output: a rated task list.
  7. Assign stable identifiers. function.verb-object for a job, and the job ID plus a task number for a task. The ID survives a retitle, a rewrite, and a route change, because everything downstream keys off it. Output: an ID per job and per task.
  8. Route out what is not a job. Classify every existing page as a job, a task, the instructions for one, or misfiled. Give each misfiled page a disposition and a destination. Output: a disposition per page.
  9. Declare the gaps. A job with no page is a located gap. Name it in the inventory with its ID and mark it absent. Output: a visible gap list.
  10. Validate with practitioners. Walk the inventory with the people who do and receive the work. Ask what they do that is not on the list. Output: a dated validation, named validators, and remaining unknowns.

Do not fill a gap by writing its page in the same pass. A declared gap is more useful than a thin page, because it is honest about coverage and it survives until someone with the evidence closes it.

Task Statement Rule​

A task statement is testable prose, not a topic label. Occupational analysis has settled the form, and it holds here:

  • Start with a present-tense action verb that describes observable behaviour: qualifies, drafts, reconciles, approves.
  • Follow it with the direct object the action is performed on: the lead, the proposal, the ledger, the campaign brief.
  • Add a qualifier only where timing, place, reason, or method changes what the task is.
  • Use one verb. Two verbs belong in one statement only when they are inseparable in practice.
  • Name no tool. The tool is a column in the allocation matrix, and naming it in the statement means the task has to be rewritten every time the stack changes.
  • Write it so two people would agree whether it was done.

Qualifies inbound leads against the ideal customer profile is a task. Lead qualification is a label, and Salesforce lead scoring is a tool.

What Does Not Belong​

A page belongs in the process pillar only if it is a job, a task, or the instructions for performing one. Everything else has a canonical home already, and putting it here removes it from the place a reader would look for it:

  • Rules, criteria, and first principles belong in the function's principles pillar.
  • Metrics, thresholds, and gauges belong in its performance pillar.
  • Tools, platforms, and infrastructure belong in its platform pillar.
  • Actors, roles, and incentives belong in its players pillar.
  • A company or brand example belongs in a reference home, linked back as instance-of.
  • A method that crosses several functions belongs in the method band, linked back as applies-to.

One companion is allowed beside the inventory: an allocation view that projects the inventory's own task rows into a work chart. It is derived from the tasks rather than being new content, and it earns its place only while it stays keyed to job IDs. A second allocation view, or one that invents rows the job pages do not contain, is drift.

Use the standard dispositions: keep, update, move, consolidate, replace, or delete. Moving a page rewrites every caller; it does not leave a route alias behind.

The test is one sentence. Does this page identify or enable a job that must be managed to run the function? If it does not, it is misfiled here even when it is excellent.

The hardest call is a technique that looks like a job. A tactic belongs here as a job only when this function schedules it, staffs it, owns its outcome, and would list it when asked what it does. If instead it is a technique any function might apply on some occasions, it is a method: keep it in the method band and link it applies-to from the job that uses it. Ask who would be accountable if it stopped happening. If nobody in this function would notice, it was never a job here.

Job Page Contract​

Every job page carries these eight parts. The first four make the job operable; the last four make it accountable:

  1. Job ID, and one sentence naming the verb, the object, and the outcome.
  2. Trigger, cadence, and boundary — the first and last action included.
  3. Inputs and outputs, with the upstream and downstream jobs named.
  4. The task table: task ID, task statement, core or supplemental, player, human or agent split, skill, tool, and the evidence that the task is done.
  5. Decision points and authority — what a human must decide, and who.
  6. Controls, failure modes, and exceptions.
  7. The gauge, linked to the function's performance pillar rather than restated here.
  8. Claim state and maturity, with the evidence behind it.

The task table is the reason the inventory is worth building. Each row is a row in the Tools and Skills Matrix, where the function's work is laid against the skills and tools that could do it. Work that was never written as a task cannot appear there, so it is never consciously allocated, delegated, or automated.

Inventory Output​

Function and boundary:
Upstream handoff / downstream handoff:
Stages (ordered):
Jobs:
  ID | job statement | stage | core or supplemental | page present or gap
Tasks (per job):
  ID | task statement | core or supplemental | player | human or agent | skill | tool | evidence
Completeness check: planning / doing / measuring / improving / governing / cadence / exceptions
Reference inventory compared against:
Dispositions for existing pages:
Declared gaps:
Validated by / date:
Unknowns:

Checks​

  • Every job is inside the declared boundary, sits in exactly one stage, and has an ID.
  • No two jobs describe the same work, and the jobs together account for the whole function at the declared level.
  • Planning, doing, measuring, improving, governing, recurring cadence, and exception work each have at least one job.
  • Every task statement leads with a present-tense verb, names its object, and names no tool.
  • Every task is rated core or supplemental.
  • Every page in the folder is a job, a task, instructions, or has a disposition and a destination.
  • Every job without a page appears as a declared gap rather than as an absence.
  • A practitioner can name a job they perform and find it in the inventory.

Failure Modes​

  • Topic drift: a subject that interests the team becomes a process page, and the folder becomes a reading list.
  • Convenience inventory: the jobs the team already has pages for become the declared inventory, so the gaps disappear by definition.
  • Level collapse: tasks are promoted to jobs, or jobs are buried as steps, and nothing can be allocated.
  • Framework transplant: an external reference inventory is copied wholesale, producing jobs this function does not do.
  • Tool-shaped tasks: the statement names the software, so the inventory expires when the stack changes.
  • Silent truncation: the list stops at the interesting work, and cadence, governance, and exception work go unnamed.

Proof Of Done​

A practitioner reads the inventory and finds every job they perform, including the dull recurring ones. A reader picks any task row and can say who does it, whether a human must judge it, what skill it needs, and what evidence shows it happened — or can see that those cells are declared gaps. Someone unfamiliar with the function can tell, for each page in the folder, whether it belongs there.

Changes my mind: a practitioner names work they must manage that no job in the inventory accounts for, and it cannot be composed under an existing job.

Source Trail​

Context​

Questions​

Next question: Which declared gap in this inventory costs the most to leave open?

  • Which job in the inventory has no owner, or two?
  • Which task is allocated to a human only because nobody wrote it down precisely enough to delegate?