Manufacturing AUTOMATION

The milkshake controversy

November 27, 2012
By Dick Morley

We recently had a milkshake conflict at the barn.

My long-suffering coauthor, Debbie, had the effrontery to disagree with me. I told her that I liked vanilla milkshakes (frappes, in New Hampshire), but the ones made in fast food emporiums were not to my taste. They made them too thick and impossible to eat while driving. She disagreed. She and her family thought the shakes were wonderful. Several interchanges convinced me that we both had valid data. What was the problem?
I limped over to my search engine and found that indeed this conflict existed with other people as well. What could be the cause? After reading some blogs, one finally made sense. The blog posted, “Hey stupid, it’s the size of the straws, not the shake.” Suddenly the light dawned. When I make shakes at home, I use big straws.
This called for a scientific experiment. Off I went off to the local fast food joint, ordered a frappe and was handed a small straw. I asked the Harvard MBA server for large straw and he said, “Certainly, sir.” Both Debbie and I were correct. Our mistake was coupling the symptoms of the problem and not the box it came in.
The very first time this concept was demonstrated was by Edgar Allan Poe. His story The Murders in the Rue Morgue is credited with being the very first detective story. His main character, C. Augusta Dupin, solves crimes by deduction. Two women are killed in a locked room with no way in or out. Who killed the women? Read the story.
The concept is best said by the author of Sherlock Holmes who said, “When you have eliminated the impossible, whatever remains, however improbable, must be the truth.”
“Nothing happened,” said the policeman. “The dogs didn’t even bark.”
“That,” said Sherlock, “is a significant event.”
Deduction is best done by starting at the conclusion and working back to the beginning.
Some examples from technology may help. It helps with design, risk analysis and social interaction. In the early ’70s I worked on computers for fast-food emporiums. The first fast food company was White Castle. They wanted computer technology in their process. At that time cash registers cost $150 each and the computer implementation costs were $3,200. The company contracted with us to do that design. We scratched our heads. Why would “Mr. Castle” want a high-cost solution? Our solution was to have some of our engineering and sales staff work in a fast food restaurant for a month where we discovered the problem. The problem was that significant paperwork had to be done with auditing at the end of every day. Secondly, the staff had a high turnover rate and training was expensive. The average teenager off the street did not want to become an accountant.
Taking care of the audit was straightforward for us computer geeks, but handling personnel problems? No way! Struggle as we might, we could not come up with a suitable training and retention program that made any sense. Again, the light dawned. The solution was to use visual aids so simple that training was unnecessary. We put pictures of the products — hamburgers and soft drinks — on the keys. Retention rates went way up and training essentially vanished. The magic box gave the owner an extra hour of sleep every day and solved the employee issues.
When we started this “illusion of freedom” consulting business in 1964, we hired a marketing person to help sell our services. We soon found out that his marketing information was always wrong — a wonderful discovery. Every suggestion he made as to what turn in the road to take, we took the opposite turn. It was a perfect relationship. We never told him why we loved him so much. We posited that if we did, he would try to be “correct.” This would destroy his value. Consistency is more important than the advice.
This example occurred during World War II — a real-life Catch-22. Many allied aircraft were shot down over Germany. Many bombers came back full of bullet holes. One of the suggestions would be to armour the airplanes. If we put the armour everywhere, the airplanes could not fly the distance. Someone said,“All you have to do is put armor where there are no holes.” You see, the aircraft with bullet holes returned, so those areas were not vital to flight. Armour where there were no holes would protect the parts that were vital to safe flight.
My recommendation for a takeaway is that you go to the future, look at the problem and let the problem decide the tools of the solution. When building a SCADA system and a new component is of interest, ask yourself, “Does it make more beer?” A cheaper programmable controller, pump component or computer does not really make more beer. One must try to analyze what the problem really is and solve it in a straightforward manner so that when you’re looking back, you think, “that was easy.”

This article originally appeared in the November/December issue of Manufacturing AUTOMATION.


Print this page


Story continue below