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 were about how soon rather than 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, whether the software can do this task, and the answer was yes. Depending on the software is a different question, and the pilot did not test any part of it.
What sits between the two is a list of five things. It is the same list almost every time. None of the five has a fixed cost. Each one is sized by a decision not yet made.
The Five Things The Pilot Did Not Test
It read a copy, not the records. The pilot ran against a file somebody exported once and tidied up. The real process reads from the system that holds the customer, the system that holds the invoice, and a spreadsheet on one person's machine: three sources never designed to agree, that identify the same customer three different ways, and that are not all reachable by a program. Research on hidden technical debt (NeurIPS, 2015) named dependencies on data as the dominant source of long-term cost in such systems.
Nobody had to grant it permission. In the pilot, a person who already had access ran it on their own account. In the live process, the software reads on its own, often when nobody is watching, and somebody has to grant that permission deliberately. The rule is fifty years old: 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).
The process was never written down. The pilot ran the version of the process people describe. The version that runs is different, and the difference is the exceptions: the customer who always gets a manual review, the threshold treated as advisory in one region, the step skipped when month-end falls badly. A system that is built against the described version handles the ordinary cases and stops on the cases 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. Ironies of Automation (Bainbridge, Automatica, 1983) observed that automating most of a task leaves the person responsible for 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. If the person who did the work now only watches, they lose the judgement the exceptions require.
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 formats a field differently. The survey of concept drift (Gama et al., ACM Computing Surveys, 2014) is the reference treatment: the relationship between the inputs and the right answer moves over time. A system 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 and the natural reaction is that this is a two-year programme. It is, at one scope, and about a month at another. The size of each item is set by the scope you chose.
| The item | One process | The whole company |
|---|---|---|
| Reaching the records | Three named systems, listed this week | A programme listing every system |
| Permission to read them | One access decision, owner and date | The permission model, redesigned |
| A written process | A few days with the people who run it | Documentation nobody finishes |
| Who steps in, and when | One rule and one named person | The operating model, redesigned |
| Proof it still works | A few checks on one output, monthly | A monitoring platform and its team |
The right-hand column is not just expensive. It is unbounded: no company finishes inventorying its systems or documenting its processes, because both keep moving, so a programme scoped that way has no 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. 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 have for measuring them in your own company.
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.
First Steps
- Write the five for the pilot you already ran. One line each, in your own words, about that pilot. Items you cannot answer in one line are why it is still a demonstration.
- Put a name against each item. Who grants the system 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: the process with the longest list.
The first is where you find out what each item costs in your company, on a scope where a disappointing answer is affordable. Then you have your own numbers, not a vendor's.
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 full quarter hour of the call 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.
- 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.
