What if
How do I test a process change without running the experiment on customers?
The three ways to find out what a change will do before committing to it, what each costs, and the point at which arithmetic on paper stops being enough.
Somebody proposes moving an approval step, adding a person, or changing a batch size. The honest position is that nobody knows what it will do, and the two usual responses are to argue about it or to try it and see.
Trying it and seeing is an experiment run on live work, with customers as the subjects and no control group. Sometimes that is the right call. Usually there is something cheaper.
Three ways to find out, in order of cost
Arithmetic. Capacity tables, Little’s Law, takt, the queueing results. Costs an afternoon, needs no software, and answers more questions than people expect.
A spreadsheet model. Steps, rates, a demand pattern, and the arithmetic applied over time. Costs a day or two and handles things a single calculation cannot, like a backlog building and draining across a week.
A simulation. A model that runs the process with variability in it, repeatedly. Costs days to weeks depending on the tool and the modeler, and it is the only one of the three that answers questions about variation.
The mistake is not choosing the wrong one. It is skipping the first two, and the first two answer most questions.
What arithmetic already settles
More than most people assume, and each of these is a whole class of proposal.
Will adding people here increase output? A capacity table answers it, completely, in an afternoon. If the step is not the constraint the answer is no and no model is needed to establish that. Capacity is not throughput is this exact case.
How long will the backlog take to clear? Little’s Law, on the net rate. One line of arithmetic, and the answer is usually much worse than the room’s estimate.
Is this batch size defensible? Setup cost per unit against the time the batch costs everything downstream. A calculation, not a model.
What is an hour at the bottleneck worth? Contribution per unit times units per hour. This one is the business case for most process projects and it is four numbers.
If your proposal is answered by one of those, do the arithmetic and stop. A simulation that confirms a calculation you could have done in an afternoon has cost a fortnight to tell you something you already knew.
Where arithmetic stops
Every calculation above uses averages, and averages are exactly what breaks when a process has variation in it. The moment the question involves how often, how bad at worst, or what happens when two things go wrong at once, a mean cannot answer it.
Three questions that need a model rather than a calculation:
“How often will we miss the promise?” Not the average lead time, the proportion past a threshold. That is a property of the distribution, and the whole point of the average was met and a quarter of the orders were late is that the mean tells you nothing about it.
“What happens on the bad day?” Two people off, a supplier late, and a demand spike, together. Interactions between variable things are precisely what closed-form arithmetic cannot handle.
“Where does the queue go if I change this?” Constraints move when relieved, queues relocate rather than disappear, and the second order effects of a change are the ones that surprise people. Tracing them by hand across more than about three steps is not reliable.
What a simulation actually costs
Worth being clear about, because the tooling conversation usually skips it.
The model is not the expensive part. The numbers are. Building the structure is a day. Establishing the handling time distributions, the arrival pattern and the availability figures is the work, and it is the same work whether or not you buy anything. Most failed simulation projects failed on data rather than on software.
And a model built on estimates answers with the confidence of estimates. A simulation given three guessed distributions will produce a precise looking answer with no more authority than the guesses. That precision is genuinely dangerous, because it is persuasive.
So the sequence is: do the arithmetic, and if the question survives it, collect the data. What to collect and how to read it is a week’s work and it is the prerequisite either way.
What to do with it
Write the question down as a sentence before choosing a method. If it contains “how often”, “at worst”, or “when both happen”, you need a model. If it does not, you probably need an afternoon.
Do the arithmetic first, always. It is cheap enough that doing it unnecessarily costs nothing, and it frequently ends the discussion.
And if you get to the tooling question, that is a genuine decision with real differences between the options: what runs on your platform, what a free edition permits, what it costs. Process Improvement Reviews covers those against one published rubric, from published sources.