The demonstration went well. Somebody had chosen a real case rather than a toy one, the software handled it in front of the room, and the questions afterwards were about how soon rather than about whether. That was eleven months ago. The thing still exists, somebody can still show it to you, and nothing in the company would stop if it were switched off tomorrow.
Nobody was careless and the technology was not oversold. The pilot answered one question honestly — can the software do this task — and the answer was yes. Depending on it is a different question, and the pilot tested no part of it.
What sits between the two is a list of five things. It is the same list almost every time, and read in one sitting it is intimidating, which is the main reason people avoid writing it down. Written down, it becomes much easier to deal with, because none of the five has a fixed cost. Each one is sized by a decision that has not been made yet.
The Five Things The Pilot Did Not Test
It read a copy, not the records
The pilot ran against a file somebody prepared: exported once, tidied up, correct on the day. The real process reads from the system that holds the customer, the system that holds the invoice, and a spreadsheet on one person's own machine — three sources that were never designed to agree with each other, that identify the same customer three different ways, and that are not all reachable by a program at all. Research on hidden technical debt (NeurIPS, 2015) named dependencies on data as the dominant source of long-term cost in systems of this kind, a decade before any of this was a board topic. That cost is not avoided by a better model. It is inherited by one.
Nobody had to grant it permission
In the pilot, a person who already had access ran the software on their own account. In the live process, the software reads on its own, continuously, and often at hours when nobody is watching. That is a different permission and somebody has to grant it deliberately. The rule to design against is fifty years old and still the right one: every program and every user should operate using the least set of privileges necessary to complete the job (Saltzer & Schroeder, Proceedings of the IEEE, 1975). In plain terms, decide what it must never see before it is allowed to see anything. In a listed company that decision has an owner, a date, and an auditor who will eventually ask about it.
The process was never actually written down
The pilot ran the version of the process people describe when you ask them. The version that runs is different, and the difference is the exceptions: the customer who always gets a manual review, the threshold that is treated as advisory in one region, the step that is skipped when the month-end date falls badly. Comparing a documented process against what the records show it really did is a mature discipline — the process mining manifesto (van der Aalst et al., 2012) sets out how it is done — and it exists precisely because the two are never the same. A system built against the described version handles the ordinary cases and stops on the ones that matter.
Nobody decided who steps in
In the pilot, the person who built it was watching. In the live process, unless somebody is named, nobody is. The choice that has to be made explicitly is where the system must stop and ask rather than proceed, who it asks, and what that person is expected to do with the question.
There is a well-established trap here. Ironies of Automation (Bainbridge, Automatica, 1983) observed that automating most of a task leaves the person responsible for exactly the parts that could not be automated, adds monitoring — which people are poor at — and means they need more preparation for the rare intervention, not less. The practical consequence is that the new process is not the old process with a step removed. If the person who used to do the work now only watches, they lose the judgement the exceptions require, and the exceptions are the reason they are still there.
Nothing proved it was still right the following month
The pilot was correct once, on a fixed sample, on a Tuesday. Businesses change: a new product line, a new counterparty, a change to the terms, a supplier who starts formatting a field differently. The survey of concept drift (Gama et al., ACM Computing Surveys, 2014) is the reference treatment of the general problem — the relationship between the inputs and the right answer moves over time, on its own. A system that was right in March is not automatically right in September, and by default nothing tells you which one you have.
The Same List, At Two Very Different Sizes
Read the five again and the natural reaction is that this is a two-year programme. It is, at one scope, and it is about a month at another. The list does not change. The size of each item is set entirely by what you decided the scope was before you started.
| The item | Scoped to one process | Scoped to the company |
|---|---|---|
| Reaching the records | Three named systems, listed this week | Every system, inventoried by a programme |
| Permission to read them | One access decision, one owner, one date | The whole permission model, redesigned |
| A written process | A few days with the people who run it | A documentation effort nobody finishes |
| Who steps in, and when | One rule and one named person | A new operating model for the function |
| Proof it still works | A few checks on one output, reported monthly | A monitoring platform and a team to run it |
The right-hand column is not merely expensive. It is unbounded, which is the more important property. There is no state in which a company has finished inventorying its systems, and no month in which the process documentation is complete, because both keep moving. A programme scoped that way has no natural end and therefore no natural point at which anyone can say it worked.
The left-hand column ends. Three systems either are reachable or are not, and you find out in a week. One access decision is either granted or refused, by a person whose name you can write down today. That is the real argument for doing one process first, and it has nothing to do with caution. It is that the five costs are only knowable by measurement, and one process is the cheapest instrument you will ever have for measuring them in your own company rather than in general.
The list is not the price of the project. It is the price of the scope, and the scope is the only part of this you fully control.
Where The List Gets Longer
Two situations make the left-hand column bigger, and both are worth recognising before rather than after.
Where the process reaches a decision about a person — their care, their credit, their employment — items two and five stop being items on a list and become the project. The permission question acquires a legal answer rather than an operational one, and the proof has to satisfy somebody outside the company. The work is still worth doing. It is simply set by the people who own the controls rather than by how quickly anything can be built.
The other case is a pilot that did not actually work. If the demonstration was impressive but the answers were wrong often enough that somebody quietly checked all of them, none of this list is the diagnosis. The question there is whether the task was specified well enough to be right or wrong at all, and that is a question to settle before any of the five is worth paying for.
First Steps
- Write the five for the pilot you already ran. One line each, in your own words, about that specific pilot. The items you cannot answer in one line are the reason it is still a demonstration.
- Put a name against each item. Who grants the access, who can state the exceptions, who is called when the system stops and asks. Where you cannot name a person, you have found the real blocker, and it is not a technical one.
- Rank your candidate processes by the length of that list, not by the size of the prize. Do this on paper, for three of them, before anyone builds anything.
Pick The Process Where The List Is Shortest
The instinct is to point the first one at the biggest prize, and it is almost always wrong. The biggest prize is usually the process that touches the most systems, carries the most exceptions, and needs the most people to agree — which is to say, the process with the longest list. Starting there means paying all five costs at once, in an organisation that has never paid any of them, with nothing to compare the invoice against.
The first one is not where you earn the most. It is where you find out what each of these five items actually costs inside your company, on a scope small enough that a disappointing answer is affordable. After that you have your own numbers instead of a vendor's, and the second candidate can be chosen on evidence.
A fifteen-minute call — nothing paid, nothing signed — takes one candidate through the five and says which items are short, which are long, and what has to be true before any of it is worth funding. Sometimes the answer is that this particular process is not the one to start with, and that answer is worth the quarter hour on its own.
References
- Bainbridge, L. Ironies of Automation. Automatica, 1983.
- Saltzer, J. H., & Schroeder, M. D. The Protection of Information in Computer Systems. Proceedings of the IEEE, 1975.
- Gama, J., Žliobaitė, I., Bifet, A., Pechenizkiy, M., & Bouchachia, A. A Survey on Concept Drift Adaptation. ACM Computing Surveys, 2014.
- van der Aalst, W. M. P., et al. Process Mining Manifesto. Lecture Notes in Business Information Processing, 2012.
- Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., & Dennison, D. Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28 (NeurIPS), 2015.
