All too often I hear some clients talking about a POC (Proof of Concept) they successfully finished with an IT company on some use case. But many or most of those POCs never saw any follow-up actions afterwards because something important (some drive and commitment in the organization) was missing. The provocative point I wish to discuss today is that a POC – if executed stand-alone – is useless and merely an echo of the good (?) old 1980s.
As a definition, a POC kind of proves that something can be done. Isn’t that important? Well, no, IMHO it’s not. Not in a digital world of the year 2019 anymore. My crazy postulate is that everything can be done today. Certainly not everything can be done by everyone if it comes to IIoT challenges in the world of energy and infrastructure, but, hey, it’s up to you to judge who you think has all the required capabilities: Domain expertise, IT/OT integration skills, data science competence, real-time/offline process know-how, and many more. We hope to be on your (very) short list there ;-)
So, consequently the question must not be if something can be done, but why it should be done, and in a next step, how it should be done. Forget the feasibility-kind-of-POC, because everything is doable nowadays. The question is only what it costs and what it brings. This relation has a simple name: VALUE!
Very often clients ask me if I think we can use their data to predict a particular variable of importance (e.g. an asset failure). I have only one answer every time: Yes, we can! Sorry for the plagiarism ;-)
We really can predict everything today; the only questions are: (1) Up to what accuracy can we forecast a certain variable of interest; and (2) Is the corresponding cost to generate/collect/store/analyze the needed data and visualize it to a decision-maker worth it? In other words, does it deliver VALUE?
To push it even further, with more data, better data, and other data, you can always go from 90% to 99%, from 99% to 99.99%, etc. – but at what cost? And, more importantly, at what outcome? Sometimes more data does not bring additional incremental value, and at other times it does. Damn, you’ll need to find out – and you need to find out with your data, not with someone else’s data presented as “market benchmarks” on glamorous PowerPoint slides! Don’t get me wrong: Benchmarks are great. They deliver information about a potential value of a use case, but you need to get your fingers “dirty with your data” asap to find out the real value waiting for your particular case.
Analytics are great, so great, in fact, that once a certain “WOW!” moment has happened, it pushes creativity, and smart minds tend to have a million ideas about the wonderful things analytics can do. This is where it becomes treacherous, because now (I bet!) someone in the room will suggest doing a POC with some of these brilliant ideas – always. My recommendation in such a situation would be not to get dragged into these interesting topics, but instead qualify all opportunities on the table and only focus on the sub-set of truly value-creating topics. Sometimes these can be interesting topics, but there can be quite boring ones, too. Value rulz!
Therefore, the question is not whether 99.9999…% accuracy can be obtained, but at what level the benefit/cost ratio will reach its maximum for your use case, in your environment, with your data. Sometimes tech-savvy guys – driven by their engineering DNA – forget that the target is not “accuracy to the max” nor is it “data to the max”, but that it’s only about value, stupid ;-) Never forget: The value/cost curve is not a linear more-is-more-relation, but it is what it is: A curve. It’s all about finding the maximum of that curve…
And this is where the POV (Proof of Value) kicks in: Evaluations of valuable use and (!) business case candidates might start with some preliminary ideas sketched on a napkin, make their way into simple XLS spreadsheets, and then result in a complex business case evaluation. One important thing to remember: It should always be supported by data exploration proving that the desired value can be generated using your data at hand and showing to what extent this value can be achieved with your available data (and extrapolating how much more value more data would generate).
Therefore, we strongly advocate to start with the POV (always!) and – if successful – follow up with what we call an “Advanced POC”:
1) POC: Can we do it?
2) POV: Why should I do it? Does it generate value?
“Value rulz” approach
1) POV: Why should I do it? Does it generate value?
2) Advanced POC: How can we do it? Where’s the value/data optimum?
Too often, it seems, we forget not only to proof the (technical) concept and feasibility, but also to put the required energy into proofing an endeavor’s true value in a first step. And of course, you need to justify why you started such a lengthy journey in the first place. Having the big picture in mind and targeting it, still each step toward your ultimate long-term goal must prove its value separately. Then, and only then, does building become real fun, and I refer to both valuable Lego and valuable IoT solutions…