Do. Or do not. There is no POC
Key Takeaways:
- There are many seemingly good reasons to engage in a POC. However those reasons are the very cause of getting stuck in “POC hell.”
- Getting unstuck requires a shift from “trying” to “doing” by moving the focus from hypothetical risk reduction back to achieving operational gains.
- The real risk in a POC is being unable to take advantage of what was learned
The proof of concept trap
Yoda could have been talking about POCs when he said, “There is no try.” It applies to everything. POCs included. “Try” belies a lack of commitment and confidence. “Try” doesn’t cut it for Yoda. And “try” doesn’t cut it in manufacturing operations (“sure boss, I’ll try to make those 30 tons of steel we have to ship today”). Nevertheless, “try” is the definition of a POC: “we’ll try it, but we’re not committed to making a difference with it…”
There is mounting evidence that POCs are a dead end. “The proof of concept trap” or “POC hell” has become a common refrain.
Why do companies “try” with POCs instead of “doing”? Why do they fall for short term vanity metrics about innovation instead of insisting on seeing the results of innovation?
There are some pretty simple reasons:
- Executive “innovation” mandate — Boardrooms need innovation. Innovation is an “indicator of potential future value” so innovation gets a level of executive attention that measures activity and spend on such initiatives. “Innovation tourism” is often the result.
- No “commitment,” no “failure.” — Innovation initiatives are almost always commitment free. No commitments are made by P&L owners to reduce waste, increase throughput, or to improve quality during a POC. So POCs are free of career risk. There is no risk of repercussion to the innovation team if the POC does not result in an operational deployment – even in the face of technical success! The only risk to a POC is a little corporate budget – which is already derisked by definition.
- Prevention of “app proliferation” — One commonly claimed reason for conducting POCs is to prevent proliferation of apps that have unproven value or are not connected to operational objectives. But app proliferation is exactly the problem with “try” versus “do.” Try is what results in “unproven value not connected to operational objectives.”
- Phantom dependencies — it’s pretty common to be told “We can’t deploy (your technically successful and operationally impactful solution) because we haven’t completed the XYZ corporate-wide [pick one: cloud, data lake, SAP upgrade, MES] project.” This happens when innovation is driven by IT and not by the business unit.
These are also the reasons companies fall into the proof of concept trap, getting stuck in their operations digitalization journey.
Innovation teams are empowered to spend small amounts of money but have no organizational “power” to follow-through and drive user adoption. POC’s are most often not conducted or “owned” by those with operational responsibility. There is no commitment to deliver results, and thus no “failure” associated with the time and money spent on POCs. Without results ownership, there is also no demand for success.
Escaping the proof of concept trap by returning the focus to accountability
Falkonry is taking a more accountable approach. There is no more Try. There is only Do.
Falkonry’s technology has been proven in 250+ use cases across 12 industry verticals to find patterns in operational data – unprocessed, multivariate operational data – providing detection and prediction capabilities that SPC or regression methods cannot match.
Our newest product, Falkonry Clue, is a plug-and-play solution for predictive production operations that identifies and addresses operational inefficiencies from operational data. It is designed to be used directly by operational practitioners, such as production engineers, equipment engineers or manufacturing engineers, without the need for assistance from data scientists or software engineers.
Here is why Falkonry Clue is a “Do” solution:
- Falkonry’s core AI is proven.
- Falkonry Clue is ready to go out-of-the-box. It doesn’t need historical data. It starts immediately with data being produced “in the now.”
- We use standard data connectors to factory automation systems. Falkonry Clue comes ready-to-run, hosted by Falkonry — “data lake” included.
- Falkonry Clue is a solution. Clue is used directly by operational practitioners and starts providing insights within days, not weeks, of activation.
Falkonry Clue lets the operations team just do their work and recognize the value in the most direct way possible.
Managing risk and the risk of not doing
Often customers will ask, “can we try some historical data?” That’s a road well traveled. A safe road. A “no risk” road. It is also a road to nowhere. A path straight into the proof of concept trap. What good, really, is taking a pile of data from the past and showing that Falkonry’s core technology can identify unusual, novel, or specific patterns relating to known event histories? It’s all in the past. It tells nothing of how it creates value “in the now” by increasing the customer’s ability to react to and make use of predictive insights today.
A true test needs to be tied to operational objectives. Those objectives need to be driven by the operational stakeholders who own and demand measurable outcomes.
A true test needs to take into account the entire solution. Not just one technical element. That solution starts with real data being generated from operations in “production time” and must include the interactions between operational users from interpretation to actions. Even if those actions are cautiously withheld at first, one must know that an action had been called for. Only in this way can a solution be tested against actual outcomes.
One customer taking this approach is in the steel manufacturing industry. This customer put a Falkonry-driven solution into operation. When Falkonry’s software first predicted a failure, the customer, in an abundance of caution, took no action. They had a natural skepticism of this new technology: They did nothing. Then the operation failed. Applause and accolades ensued – and because this system was NOT a POC, every subsequent prediction resulted in measurable, impactful, operational gains.
Do a production pilot, or do not. There is no POC.
