We’re all probably familiar with the idea that it takes half the time to get to 90% done and the other half to finish the last 10%. This is a staple of project management.
I think there’s actually a narrower scope of really dangerous solutions that you only become familiar with after you experience it. There’s a whole set of problems where the obvious solution gets you 95 to 98% of the way to your performance spec really quickly, but is almost impossible to reach 100% by incremental improvements. The reason I say they’re dangerous is because the feeling of being “almost there” prevents you from going back to the drawing board and coming up with a completely parallel solution.
I can remember a machine vision job from years ago where the spec was “100% read rate”. I only got it to about 94%, and someone else gave it a try. He got it up over 96%, but 100% was out of reach given the technology we had.
Experiences like that make you conservative. Now I unconsciously filter possible solutions by their apparent “flakiness”. I’m much more likely to add an extra prox to a solution to verify a position than to rely on timers or other kinds of internal state, because the latter are more prone to failure during system starts and stops. I press for mechanical changes when I used to bend under the pressure to “fix it in software”.
Still, you have to be careful. Its easy to discount alternatives just because they bear some passing resemblance to a bad experience you had before. You have to keep re-checking your assumptions. Unfortunately, rapid prototyping usually fails to uncover the “almost there” situation I’m talking about. If you prototype something up fast, and it works in 97% of your lab tests, you’ll probably think you have a “proof of concept”, and go forward with it.
The best way to test new solutions is to put them into production on a low risk system. If you’re an integrator, this means having a really good relationship with your customer (chances are you need their equipment to run your tests). If you work for a manufacturer, you can usually find some out-of-the-way machine to test on before you go all-in.
I agree 100%.
It’s really easy to make something work 50 or 100 times in the lab, but what does that equate to in real production time? Running 2000 twinkies through a prototype in a lab may sound like a lot, but if the line rate is 200 twinkies per minute, it’s only 10 minutes worth of production. To get a 1-shift equivalent for a week you need to run 96000… …not practical in a lab to do.
To get real OEE and performance you need to run real significant numbers to get real data.
Very good point Scott. I’m a regular victim (or perpetrator?) of this scenario (though not related to industrial automation per se). I find that this happens often due to feeling too pressed for time/budget to go back and re-think the solution. It can be hard to justify to the people in charge that we need time to ‘re-think’ a little. They would usually prefer to just squeeze a little more juice out of the lemon.
Good point Ken. It makes you wonder how NASA manages to land *any* landers on Mars… it’s not like you can try that too many times. 🙂