Many companies are investing significant effort in data lakes, digital twins and other digital transformation initiatives with more failures than successes. Digital transformation and digital adoption reports over the past five years from consulting firms like McKinsey, Everest, and Boston Consulting Group consistently show that roughly 70% of digital transformation projects fail. This is consistent with the “80:20 rule” or Pareto principle, in which 80% of results come from 20% of initiatives, so perhaps this should not be a big surprise.
I suspect, however, the problem isn't the Pareto principle, but something more basic. We neglect to take a step back to ask and answer the question, “What are we trying to achieve?” Among the insufficient answers, “We need to be ready when the (insert technology here) goes mainstream.” Or, “We need to be prepared when the corporate leadership team, who know there's value in (insert technology here), jump on the hype bandwagon.” Or, “We need to be seen as progressive.”
Too often, we jump on a new technology during its hype cycle, hoping we won’t lose all faith during the “trough of disillusionment,” and will thus be better prepared take full advantage of the technology once it's matured, by which time we’ll be able to identify what we hope to achieve. We in the technology sector commonly fall into this trap. Why else would so many toys sit unused in our personal digital workshops?
A proven method to capture the desired outcome is with the “use case” concept and tools. This technique is normally the first step in developing any new consortia base or international standards effort. It keeps the team focused on the problem(s) they're working to solve.
For example, joint technical committee/standards committee 41 of the International Organization for Standardization and International Electrotechnical Commission (ISO/IEC JTC1 SC41) is developing a wide range of standards in the realm of “Internet of things and digital twin,” including a document entitled “ISO/IEC TR 30172 digital twin – use cases.” The document is presently at the Committee Draft (first circulation for comment) stage. The document includes in the Annex a sample use case template designed to guide teams in defining the scope and desired outcomes/objectives of digital-twin projects.
The most important steps in developing any use case are to first confirm what problem(s) you're trying to solve and whether it's worth solving. “Worth solving” means there's an associated value, which may or may not mean money. If you can’t do these two things, then stop. If you can’t stop because of momentum, take a step back and confirm you're going in the right direction.
Once you know what problem you’re trying to solve, you may find out you're not collecting the right data in your data lake—which for many of us is our plant historian. You may need to supplement the data with information from other sources, including laboratory information management systems, protection and control systems, manual maintenance records (a big task itself to input and validate), business systems, and supplementary data such as asset management sensor diagnostics that you may not have.
Lastly, rather than trying to solve all the world’s problems with your first project, start small and proceed with incremental steps. This not only limits exposure, but also lets you gain experience and confidence from each of your successes.
Just like nature, your data lake can start as a data pond and grow from there as your streams of data improve and multiply. The same is true for your digital twin. Start with one machine, or maybe one problem valve and its assembly. Then, apply that understanding to more valves, associated piping, then a pump, etc. Don’t start with a refinery.
Let’s learn from our past by overcoming our inherent desire for cool technology. Instead, step back and ask, “What problem(s) am I trying to solve?” In many cases, with the increasing capabilities of digital technology and edge devices, the answer will entail some novel use of digital tools. But at least you'll know where you want to be at the end of the project.
About the author: Ian Verhappen
