Thirty Processes

Most scoping conversations I sit in about automating work open on the technology. Which platform, which pipeline, which vendor, and lately which language model and how carefully. The answer arrives quickly, everyone writes it down, and nobody has committed to anything, because a platform choice can be revisited in month four without admitting the plan was wrong.

The question that commits somebody is duller and much harder to answer. How many processes are there. Not how many you would like to automate. How many exist, how many you are going to write down, and by when.

I have been going back through a proposal I worked on for a European travel and tourism group that was standing up a new central digital function inside a group-wide reorganisation. The structural blueprint for the new function was close to finished. What the next phase was scoped on is the thing I keep returning to, because it was not a platform and it was not a headcount. It was a count of processes. The document states that around thirty had been identified. Ten of them were to be described at one level of detail, the remaining ones at the same level afterwards, and five to be taken a level below that. The complex and critical ones were to go first.

That is a scope statement you can be caught out on, which is what makes it worth copying.

The only number in the document you could be wrong about

The phase carried three streams of activity beyond finishing the blueprint. One designed the shape of the wider technology function. One implemented the organisation structure, mapping reporting lines and describing roles. One built a way of ranking the portfolio of ideas against what a customer actually goes through.

Read those three side by side at the end of a quarter and only one can fail visibly.

The organisation structure stream produces a chart and role descriptions, and a chart is finished when somebody senior stops objecting to it. The prioritisation stream produces criteria and a ranked list, and a ranked list is finished when the arguing stops, which is a matter of fatigue as much as of method. Both are real work. Neither has a denominator.

The process stream has one. Around thirty. If twenty-two flows exist at the end of the plan, twenty-two is not thirty, and no amount of vocabulary closes that gap in a steering meeting. The word around is doing honest work there, because nobody knows the true number of processes in an organisation being assembled from parts of other organisations, and pretending to would have been worse. An approximate count still forces the arithmetic. A heading never does.

This is why I push scoping conversations toward a count early, even when the count is soft. It is the only artefact in the pack that behaves like a measurement.

A count of processes is a count of decisions

The reason the count matters to anyone building on data, rather than to a programme office, is that a process is where the data work meets something a person is accountable for.

Every process on that list of thirty is a sequence of steps with decisions in it, and each decision is a place where you can ask three questions that have real answers. What is recorded when this step happens. Which system of record holds it. Would two people looking at the same case make the same call. Ask those thirty times and you have a data readiness picture grounded in operations rather than in a data catalogue.

Do it the other way round and the exercise floats. An inventory of tables tells you what is stored, not which stored thing anybody acts on, and I have watched teams build a clean feature store for a decision nobody makes any more.

The count also gives the automation conversation a denominator it usually lacks. Straight-through processing is a per-process measure. It says nothing about a function and everything about a named flow: this many cases arrive, this share completes without a human touching them, and one named exception stops the rest. Process mining works the same way, and the first thing it hands back is a count of paths you did not choose and probably do not like.

Divisible is what makes it a plan

A count on its own is a target. What turned this one into a plan was that it split.

Ten first at one level of detail. The remainder at the same level after. Five at the level below. Three activities, one three-month window, and each of the three can be reported on separately. That structure is worth more than it looks, because it separates the two things a programme usually confuses: how much of the estate is visible, and how much of it is operable.

The ten and the remainder are about visibility: once every process has a flow with roles on it, nothing is invisible and the next candidate for deeper work is always identifiable. The five are about operability, which is a different activity, done with people in a room disagreeing about what happens when something fails.

Splitting the count also means the plan degrades gracefully. If the quarter goes badly you land the ten, slip the remainder, and still have something. A plan expressed as a heading does not degrade. It arrives whole, late and unfalsifiable.

Start with the ones that hurt

The sequencing rule in the plan is the part most organisations invert. Begin with the complex and critical areas, it says, and it names them rather than leaving the reader to guess: financial processes, capacity management, standing up a delivery centre, gating, end-to-end product management.

Every instinct pulls the other way. The easy processes have a willing owner, a tidy handover and a good chance of being finished before the first review. Doing those first produces a healthy-looking burn-down and defers all the information.

The hard processes are where the disagreement lives, and the disagreement is the design decision the exercise exists to make. Take them first and the count you end the quarter with is honest. Take them last and the number goes green for two months and then stops moving, and by then the plan has no room left.

Some of the processes marked for the deeper pass had no incumbent version at all: the document calls them new. It names, as examples rather than as a closed list, work like customer experience, service management, idea intake, running a delivery centre, and managing resources and practices. Those cannot be reconciled against anything, which is a different kind of hard and worth flagging separately when you build your own count.

~30

Processes identified, all of them still to be described

10

To be described first, at one level of detail

5

To be taken to the level below

3 months

The proposed plan window, alongside the organisation design

A count is only real if each item has a name against it

The line I would steal wholesale sits in the governance part of the plan, and it is easy to skim: confirm the process owner and the sponsor, written as its own activity rather than folded into the drafting. The scope statement separately says to engage the process owner in the design work itself, so this is a name secured and then kept in the room. Workshop, refine and validate appear as three more separate items.

That is what stops a count decaying into a list. Thirty rows in a spreadsheet is a list. Thirty rows each with a person obliged to turn up and argue is a plan, and the second number is usually smaller. If you cannot find an owner for a process, you have learned more than a flow diagram would have told you.

A heading cannot be finished. A count can. Thirty is a number somebody has to stand behind in November, and no amount of vocabulary makes twenty-two of them look like thirty.

What I would do before choosing anything technical

Count the processes, accepting that the number will be approximate and saying so. Split it into a tranche you describe now, a tranche you describe after, and a much smaller tranche you take properly deep. Put the hard ones first. Put a name against every row, and treat a row with no name as a finding rather than an omission. Only then open the tooling conversation, because by then you know how many things the tooling has to serve and which of them are understood.

That ordering is the opening block of a RealAI Platform engagement, and it is why we ask how many processes before we ask which model. The technology under a process changes every few years. The count does not, and a programme scoped on the count keeps its meaning when the stack underneath it is replaced.

Drawn from a phase-two proposal for the target operating model of a new central digital function at a European travel and tourism group: its scope statement, its three-month plan and its stated outputs. The processes were to be described and the tranches worked through; none of it is reported here as delivered. Reading a process count as the honest unit of scoping is ours.