The process taxonomy: the unglamorous backbone of every transformation

A process taxonomy is the least glamorous deliverable in transformation work. No dashboard, no demo, no instant wow. It's a naming and numbering structure — a way of saying this process is part of that group, sits at this level, and is owned by them.

And it's almost always the thing that decides whether everything else holds together.

The problem it solves

Most organisations don't lack process documentation. They have too much of it, scattered across teams, tools and naming conventions that nobody agreed. Two teams document the same journey under different names. A procedure exists but no one can say which process it belongs to. A regulation lands and there's no way to find every document it touches.

That's not a documentation problem. It's a structure problem. A taxonomy fixes it by giving every process a place, a level and an owner — so the estate becomes navigable instead of a search-and-hope exercise.

What a good taxonomy gives you

Traceability — procedures roll up to activities, activities to journeys, journeys to capabilities. You can answer cross-cutting questions in minutes, not weeks.
No duplication — when there's one agreed home for each process, the duplicates and orphans surface immediately and can be retired.
Clear ownership — every node has a name against it, which is what makes governance and review cadence actually stick.
Machine-readability — a consistent, hierarchical structure is exactly what an AI tool needs to reason about your operation. Mess in, nonsense out.

It pays for itself in the rationalisation

In a recent engagement I anchored a sprawling set of maps and procedures to a single taxonomy and used it to consolidate aggressively — collapsing 19 process maps and 57 procedures into a far smaller, governed set, cutting volume by 60–70% without losing a thing that mattered. None of that consolidation is safe without the taxonomy underneath it; the structure is what tells you two documents are genuinely the same.

Build it first, not last

The temptation is to start mapping and "sort out the structure later." Later never comes, and you end up with beautiful diagrams nobody can find. Agree the taxonomy early — even a rough one — and let it grow with the work. It's the backbone everything else hangs from, and a transformation without one tends to quietly fall over.