The Processes With No As-Is

There is a quiet assumption inside every operating model method I have used, including ours: that the process you are about to describe is already happening somewhere, performed by somebody, badly or well, in a system or a spreadsheet or their head. You find that person, sit with them, watch a few cases, draw what you saw, then argue about what it should look like instead. Current state, then target state. The method runs on the current state being available.

A proposal I keep coming back to sits at a European travel and tourism group that had just designed the structure of a new digital function and now had to make it operable. What follows was scoped to be designed, not delivered. That is why it is useful: a proposal is where an organisation writes down what it thinks the work is before contact with the work changes its mind.

The scoping unit was the process, and around thirty had been identified as needing description. That list does not hold together as one kind of task, because a handful of the named processes are introduced as new, with no incumbent anywhere in the organisation. They did not exist yet.

The interview that cannot be arranged

The proposal introduces the six as key priority processes, for example new processes such as, then trails off with an ellipsis, which is a proposal's way of saying we have not finished counting. So six is a floor, not a count. The plan and the commercial offer both later commit to five at the deeper level, so between describing the work and pricing it the list narrowed by at least one. The arithmetic is not the point. The point is that the six are a different species of task from the other twenty-odd, and the plan treats them as the same species.

For a process that exists, the description work is recovery. There are tickets, handovers, a shared mailbox, a person who has done it for years and can tell you which step everyone skips. You are reconstructing something real, and reality arbitrates: when two people disagree, you go and look.

For a process that does not exist, none of that is available. No case to observe, no exception to catalogue, no owner who can say that is not how we do it. Whatever gets drawn is an assertion by whoever is in the room, and it will be wrong in ways nobody can detect until the process runs for the first time. The design is not a description at all. It is a hypothesis with a swimlane diagram on it.

None of that shows up on a plan. On the plan a process is a process, and the twenty-fifth costs about what the third cost. It is the estimating error I see most often in this work, and it is invisible because the units look identical.

Where the plan puts its depth

The plan is honest about rationing, which is more than most are. Ten main processes are to be described first at one level of detail, the remainder follow, and only five go a level below that, to the description that names who does what, in what order, with what handoff. Artefacts move through the same cycle of workshop, refine and validate, and adoption is a deliverable in its own right: operating model in use and people trained, not merely operating model designed.

The proposal is candid about method, too. Process design is a hybrid: the organisation's own existing processes plus a pre-built library of reference process flows. That is close to the only way to get thirty processes to a usable level of detail inside a quarter. It is also the mechanism that fails on the six. A reference library gives you a starting shape for accounts payable or incident management, because those are the same shape almost everywhere. It gives you nothing for shared capability centres this organisation had only just invented, and the closest match is worse than nothing, because it looks plausible.

So the process estate splits, and the half with no as-is needs a different activity: design under uncertainty, with a first version expected to be wrong and a scheduled point at which it gets corrected against real cases.

The line item that has to be confirmed later

The proposal treats the detailed description of the five priority processes as a provision, held open to be confirmed by a date in late September, alongside a second provision for detailed people data analysis. Both sit outside the committed scope.

Read commercially, that is reasonable. You do not price work whose shape you cannot see, and an option with an expiry forces the decision early rather than midway.

Read it as an operating model problem and it is the whole issue in one line. The activity hardest to estimate, because it has no precedent to estimate from, is the activity the commercial structure makes conditional. It is the first thing dropped when the quarter gets tight, and the quarter always gets tight. Meanwhile the processes that could have been described from a library and an afternoon with the person who does them sit inside the base scope, because they were easy to price. That is not a criticism of the proposal. It is what happens when budgeting is driven by estimability. Work with no as-is is unestimable, and unestimable work becomes optional work.

~30

Processes identified for description in the new operating model

10

To be described first, at one level of detail

5

To be taken a level below that

Dated option

Where detailed description of those five sat in the offer

Why this reads differently now

I would have filed this under change management a few years ago. I do not any more, because the same split decides which processes can carry the systems everyone is now trying to build.

Every retrieval-augmented pipeline, every copilot pointed at internal work, runs on a corpus of what the organisation already does: documents, tickets, resolved cases, previous decisions. That corpus is the as-is in machine-readable form. Where a process has run for years, the vector store fills itself as a by-product of the work, lineage is traceable back to a system of record, and an evaluation set can be assembled from cases whose correct outcome is known because somebody handled them.

For a process that does not exist yet, all of that is empty. Nothing to retrieve, because nothing has been done. No evaluation set, because there are no graded examples and no agreed definition of a good outcome. Careful MLOps practice does not help: it is machinery for keeping a trained thing honest, and there is nothing to train. Early, narrowly scoped autonomous experiments are the right instinct here, and they still need a way to tell whether the thing did well.

Which produces an awkward ordering. The processes best prepared for automation are the ones the organisation has been doing longest, and usually the ones it wants to shrink. The processes the new function was created to perform, the ones carrying the growth argument, have no corpus at all. That is not a data quality problem you can clean your way out of. The data will not exist until somebody runs the process badly for a while and writes down what happened.

Every technique we have for describing a process assumes somebody is already doing it. At least six of these had nobody. The work with no incumbent to interview is the work the new function exists to do, and it is the first line the plan rations.

It is also why I have stopped treating documentation of new processes as overhead. Design a process, run it two quarters without capturing outcomes in a consistent shape, and you have paid for the design while discarding the only asset it produces: a record of what happened when the hypothesis met the world. Political agreement on European rules for AI has landed, and whatever the obligations finally look like, none will be satisfiable for a process whose behaviour was never written down.

What I would change in the scope

Four things, none expensive.

Sort the process list into two columns before pricing anything, one for processes with a live incumbent and one for processes with none, and accept that the second column runs at a different rate per process. Put that column in the base scope, not in an option, because it carries the reason the function was created. Give each new process a first-run date and a named owner, so the design is tested against cases rather than reviewed in a workshop. And define the record before the first case runs: what gets captured, in what fields, with what definitions.

That last one pays twice. It makes the process improvable, and it is the only route by which a new process becomes something a model can support. RealAI's Consult team scopes it as a design activity rather than a reporting one, for the reason this proposal shows so plainly: nobody funds the documentation of work that has not happened yet, and nobody can explain, later, why the new part of the business is the part where none of the automation works.

Drawn from a second-phase proposal to build the operating model for a newly created digital function at a European travel and tourism group: its scope, its plan and its commercial structure. A proposal states what was scoped to be designed, not what was delivered, and nothing here is an outcome. The named processes, the counts and the staging are as written in that document. The reading of what a process with no as-is costs is ours.