The last ten percent costs more than the first ninety
Almost any repetitive job automates cheaply up to a point. The exceptions are what you actually pay for, and they are usually invisible when the project is scoped.
Watch somebody do a job for an hour and you will see a clean, repeating cycle that looks straightforward to automate. Watch for a full shift and you will see the other things: the carton that arrived dented and had to be rebuilt, the label that has to face out on this customer's pallet, the partial pallet at the end of a run, the part that came out of the machine wrong and got quietly set aside.
Those exceptions are usually a small fraction of the units and a large fraction of the difficulty. Handling a good carton is a solved problem. Recognizing a damaged one, deciding whether it can be used, and rebuilding it is not, and the automation that attempts it costs several times what the straightforward version costs, if it works at all.
The mistake is not failing to automate the exceptions. The mistake is failing to decide about them explicitly, early, in writing. A project scoped as though every unit is a good unit will meet reality on day one of production, and the resolution will be improvised: somebody stands next to the cell handling the awkward ones, which is often exactly the outcome the project was meant to avoid.
There is usually a good answer available, and it is boring. Let the cell handle the ninety percent that is uniform, and let a person handle the exceptions, ideally a person who was already there doing something more valuable. That split is cheap, robust, and honest about what machines are good at. It also means the cell can be simpler, which makes it more reliable, which is worth more than elegance.
The alternative is worth pricing rather than assuming. Sometimes the exception rate is high enough, or the exception costly enough, that engineering it in is justified. Vision to detect a damaged carton, a reject path, an orientation check: these are real capabilities with real prices. What matters is that you chose them knowing what they cost, rather than discovering you needed them after installation.
When we scope a job, the question we ask that most surprises people is what happens when something goes wrong. Not because we expect it to go wrong often, but because the answer to that question is usually where the budget actually lives.
Decide before you buy who handles the damaged, the partial and the odd unit. That decision, made explicitly, is usually the difference between a cell that runs and a cell with a person standing next to it.
Put it to the test on your own job
Tell Joe what you are running and he will apply this to your numbers, including telling you when a robot is the wrong answer.
More notes