How many variants does the process you will automate have?
The return on an automation depends on two counts that tend to stay out of the scoping conversation: how many times the process will run and how many variants it has. With many variants and few runs of each, covering them all costs more than it saves. Automate the frequent core and design a route for the tail.
Why does the return on automation depend on two counts?
Because automation has a cost to build and a saving on every run, and the math only works after a minimum number of runs. Brown and Hellerstein formalize this in the IBM paper. In their model, automation pays off when the number of runs over the process's lifetime exceeds the extra cost of building it divided by the saving per run.
The paper calls the ratio between the cost of automating and the cost of one manual run the generalization difficulty. Every variant of the process needs its own rule, test and error handling. That reading is ours, not the paper's: the more variants, the higher the build cost, and the fewer runs each one gets to pay it back.
What did IBM measure when it automated in practice?
The authors start from a sentence that works as a warning: automation does not necessarily reduce the cost of operations. They give three reasons. Deploying and maintaining the automation infrastructure takes work. Structured inputs require design and testing up front. And detecting and recovering from errors is harder in an automated process than in a manual one.
Their case is software distribution in data centers. Of the packages built, 25% were installed on fewer than 15 servers over their lifetime. Of the install requests, 19% ended in failure. With costs they estimated, the break-even point falls between 5 and 20 servers, which leads to the conclusion that 15% to 30% of installs should not have been automated.
Two limits are worth stating. The break-even point comes from cost ranges the authors estimated, not from a full data analysis, so treat it as an order of magnitude. And the context is IT operations in 2005, far from a small or midsize business. What carries over is the method of the calculation, not the percentages.
What are process variants, and why is the tail long?
A variant is each different path a case takes through the process. The order that goes straight through, the one that comes back for correction and the one that needs an extra approval are three variants of the same process.
Fischer, Hofmann, Imgrund, Janiesch and Winkelmann studied four process execution logs (IT service desk, loan applications in two periods, and building permits) from three Dutch organizations, two financial and one public body. They split the variants into a head, the 20% with the highest combined indicator score, and a tail, the rest. The tail accounted for about two thirds of the indicator values they calculated, and its variants had fewer customer contacts, fewer runs and more stakeholders.
The authors do not conclude that you should ignore the tail. They conclude that you should treat it differently: manage the main processes centrally and improve the rest gradually, where they are executed. The reading for automation is ours. A variant with few runs and many stakeholders has a low number of runs and a high build cost, the worst combination for break-even. The data come from three Dutch organizations, with no breakdown for small and midsize businesses.
What is left for people after automation?
What the project did not cover is left, and it is usually the hardest part. In 1983, Lisanne Bainbridge wrote in Automatica that automation can expand rather than eliminate problems with the human operator. In her words, the designer still leaves the operator to do the tasks the designer cannot think how to automate, and the operator ends up with an arbitrary collection of tasks.
The paper is about industrial process control, and the application here is ours. In an office operation, the tail left out of the automation becomes that arbitrary collection when nobody designed the route: each person solves it their own way, in a private spreadsheet, and the case never enters any count.
How do you count variants and volume before approving the scope?
This is a procedure we propose, not a method from the studies cited. Start from real cases, not from the process flowchart. Take three months of cases and group them by the path they followed. Count how many cases each variant had and how many minutes each manual run takes.
Next, estimate the cost of building each variant in hours and divide it by the hours it saves per month. The result is the payback in months, variant by variant, not a single number for the process. The calculation of automation ROI works better this way, because the average hides the variant that never pays back.
Then split them into three groups. The frequent, stable core gets automated. The middle depends on whether the rule changes. The tail gets a designed manual route, with an owner and a record in the same system, so every case keeps counting. Measuring payback depends on that record, a topic covered in measuring automation ROI without a system of record. Where the line between manual and automatic sits is the subject of when manual processes and automation belong together.
Deciding what goes into the automation is an architecture decision, not a tool decision. Counting variants is work for people who know the process from the inside, and that intelligence, the natural kind, comes before any machine.
A practical example: endorsements at an insurance brokerage
The scenario is hypothetical and the numbers are illustrative assumptions, not measurements. An insurance brokerage with 35 people handles 600 policy endorsements a month, and each one takes 12 minutes of manual work. After grouping three months of cases, the brokerage finds 1,800 endorsements and 14 variants.
The three largest concentrate 1,260 cases, 70% of the total. The other 11 share 540 cases, with the largest at 90 and the smallest at 8. Assume, for simplicity, 40 hours to automate each variant. If the tail variants cost more, as the Fischer study suggests by pointing to more stakeholders, the payback gets worse still.
For the three largest, that is 420 cases a month, or 84 hours saved against 120 hours of build time. Payback comes in about a month and a half. A variant with 90 cases in the quarter has 30 a month, saves 6 hours, and pays back in about seven months. The variant with 8 cases has fewer than 3 a month, saves about 30 minutes, and takes 75 months to pay back, more than six years.
The 11 variants together would cost 440 hours to save 36 hours a month, an average payback of about 12 months. The average looks acceptable and hides the variant that never pays back. That holds even more if the rule of a variant changes before payback arrives, because the automation then costs maintenance without returning hours.
This kind of count requires a structured record of each case's path. In the Repap On case, a company in which Yowpi holds an equity stake, as the case itself discloses, the document management platform grew out of process consulting, and mapping the process is the starting point of the system.
Frequently asked questions
I don't know whether automation has a financial return. How do I find out before hiring?
Estimate, per variant, the runs per month, the minutes per run and the hours to build. If you cannot fill in those three numbers, the right stage is still measuring. The IBM paper reminds us that automation does not necessarily reduce cost, and the per-variant calculation shows where it does.
My team is used to spreadsheets. Does the tail that stays manual stay in the spreadsheet?
It does not have to. What stays manual should have a designed route and a record in the same system as the automated part. The parallel spreadsheet is what makes the tail invisible, and an invisible tail never enters the next scoping decision.
I don't have a qualified team to implement this. Who does the survey?
Surveying cases and variants is work for the people who run the process, and a spreadsheet is enough. Building is the part that needs engineering, and that is where an engineering partner comes in. The decision about what goes into the scope stays with you, and the count is what supports it.
The next step
If you have a process that is a candidate for automation and do not yet know how many variants it has, the Operational Architecture Diagnostic is a 30-minute conversation to map with you where the variants and the volume sit before any scoping decision. If it makes sense for your case, talk to Yowpi.
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No proposal in the first conversation.
Book a diagnostic