The very bright daughter of a friend of mine — I’ll call her Hannah — grew up with the Harry Potter series. Eight years old when the first book came out and an avid reader, Hannah looked forward to each new volume with painful anticipation.
Now 27, Hannah recently confided to her mother that in the days before her 11th birthday she waited, hoping against hope, for that magical letter inviting her to Hogwarts (as did her best friend). Of course, these two were well aware that that letter wouldn’t arrive. But they just couldn’t help hoping. Why exactly is this?
The Harry Potter Problem
Which brings me to my topic for my next three posts: the Harry Potter Problem. We all want to believe in magic. It’s so much more enchanting than the nasty logistics of the everyday world. We want to work with a wand — not a spreadsheet or a fretsaw or a food processor.
So when exciting new tools and concepts began emerging 20 years ago — the neural networks and the data mining and the expert system algorithms — people like me leapt upon them. Artificial intelligence 20 years ago was the next big thing. We thought, Now we can solve the problems that plague us. These new tools were so powerful, the computer would solve the problem!
What happened? Those of you of who are my vintage remember. Data-driven project after data-driven project failed — whether it was Artificial Intelligence, Expert System, or some other flavor. Often, the failures were miserable. Dare I admit that I even managed to correlate the full moon with a production problem? (The real issue was that the product schedule had coincidentally put the delivery of problematic products in sync for a few months with the full moon). Talk about Harry Potter!
So we began blaming the tools, the neural networks et al., or the tool wielders, the coders and IT specialists. Someone or something had to be at fault.
Yet We Could Have Made It Work
The irony is that those projects could have been successful. Virtually every data-driven project was missing at least one of what I now recognize as the four KSFs:
- Enough good quality data
- Data specialist, to learn from the data
- Process specialist: someone who knows how the process works
- Choose your case carefully
Enough Good Quality Data
If you want to predict the next volcanic eruption, the volcano needs to erupt a few times first.
It’s the same with machine failure, or downtime or quality issues. To predict when or why or how often this happens, you need many examples, a record of all those events. You need quality data and you need enough of it. Many projects were doomed from the start, due to the lack of good data with sufficient examples of the requisite inputs and outputs.
Data Specialist, To Learn From the Data
It’s astonishing how many ways there are to categorize and model your data. Many difficult questions arise. But you need to find ways of categorizing, or else your analytics will be presented with umpteen thousand unique events, which means patterns can’t be identified. You also need to exclude dirty data, and/or data that are missing fields you need. This is where the data specialist comes in.
Process Specialist: Someone Who Knows How the Process Works
Your process specialist understands how the process you are analyzing actually works, in depth and in detail. Without a process specialist, your project will fail. Harry Potter can always use his magic wand, but for you, the mechanical, chemical, electrical, production, efficiency and quality context matters.
Choose Your Case Carefully
Finally, choose your case carefully. Do not start with the problem that has plagued your plant or industry for 30 years! Don’t start with the oldest pieces of equipment, either, those with no or little data. Again, this is not magic. It requires a disciplined process.
To reiterate, most of those failing projects lacked at least one of the above KSFs, dooming their success from the start. And regrettably, I see the Harry Potter mentality reemerging today.
Crawl. Walk. Run.
Now let’s turn to approach, to process. Not surprisingly, the Harry Potter mentality again curtailed success in early attempts. People chose cases with no data, and/or the toughest problems, and gave them to student interns — fully equipped with the new magic wand software!
Take an actual case with a major F&B manufacturer. They decided to tackle their most complex multi-routed packaging line — targeting legacy, one-off, custom-built machines — for which they no longer held the controller source code. Can you see where this is going?
To start, an intern spent a month creating baseline data with a magic stopwatch and clipboard. If choosing an intern to start the project wasn’t enough to kill it, this first step certainly was. Well before the month was over, the operators had decided they were being watched by Big Brother. By the time the solution was deployed several months later, they did a fine job of ensuring the project didn’t succeed.
Real legwork trumps wands. Success comes only to those who knew to first crawl, then walk, then run.
Achieving world-class manufacturing isn’t an event, it’s a journey — and the journey is composed of a series of smaller successes. To start, choose the quick wins. You’ll get buy-in and engagement, as well as an early and ongoing return on your investment. From there, proceed to tougher projects (crawling), until finally you can move into full-on complexity (running).
The Good News
Bad news first. No one on your team goes to Hogwarts, no one can wave a magic wand to make change happen. The good news? We’re finally learning how to make the new tools of 20 years ago work to our advantage. We know what’s required, we know the process, we have the pieces in place.
And let’s not forget what Arthur C. Clarke so memorably said: Any sufficiently advanced technology is indistinguishable from magic.
Check out the second part of The Harry Potter Problem series: Define the Why to Succeed With Your Machine Learning Project.