Part 4 - Digital Twin Design Process
The reason for this book
A structured, iterative approach to designing digital twins and applied AI, focusing on solving real-world problems, enabling change, and ensuring measurable value through validated solutions and user-centric design.
Why do we even need a process?
A major current challenge with digital twins and applied AI is that everyone does them differently, and everyone starts a new process or way of thinking each time, and those processes are discarded almost before they’re used in anger. Most of these new starts are done under extreme time pressure (after the contract / project / runway time has started ticking), and no small amount of new twins are reverse engineerings of ideas that a budget holder had. This is very normal in the early years of a new paradigm, and older readers will be able to name any number of “paradigms” that swept through our professional lives and were marked by extreme uncertainty in ideation and haphazard execution. Eventually, as we learn the hard lessons, ways of working emerge that deliver benefits more often than not, and the long climb of professionalization and deeper learnings begins.
Digital twins and applied AI are no different. A key difference, however, is that these connected solutions are explicitly designed to create change in the real world. The real world, therefore, has an integral place in digital twin and applied AI design. We address this by explicitly considering the ecosystem around the twin, as well as the actual software.
In the land of software, I will focus on products as they are a higher bar than tools, and by definition any product can be used as a tool, while the reverse is not necessarily true.
The ecosystem encompasses the real-world elements that must be understood and / or changed to enable the product to create value (i.e., it is the portions of the real and virtual worlds that we are interested in). Note I do not mean designing and building the real world – there is no need to know how to build a jet engine in order to create a digital twin of one, but if you don’t understand the problem the jet engine has that you’re trying to solve, and how whatever portion of the surrounding ecosystem of fuel, air, structure, controls etc. impacts that problem and solution – then the probability that your twin or AI model solves the real-world problem is low.
Digital Twin Design Process – Summary
The Digital Twin Design Process (DTDP) has four stages that drive the iterative process of designing a valuable, feasible, usable and viable industrial digital twin and/or applied AI solution. Following this process drives the right behaviors and vastly increases the probability of positive change in the real world and subsequent ROI.
We call this highest level the Level 1 DTDP – it explains the why of the process stages and the intended outcomes. It also shows the deliberately iterative nature of the DTDP.
Valuable problem
Twins as products or tools must solve real problems in order to create sufficient value to justify the investment and cost. Unlike many software products, digital twins and applied AI are highly connected to the real world. This strong connection is what drives much of the change in the real world and it is also what enables twins to measure the change created. The flipside of this is that twins measure their own success or failure. All software products are meant to “solve a problem,” but twins are in the unique position of measuring the effectiveness of themselves.
The outcome of this stage is a well-defined problem that is at least partially validated in terms of cost and complexity. Executing this stage well results in the selection of a problem whose solution will create real and measurable value for the organization.
Feasible ecosystem change
The heart of the DTDP is analyzing and defining the change required in the real world to solve the selected problem, and the linking of capabilities and data to create and measure change. The process in this stage works backwards from the desired change in the real world, to determine what actions and decisions will need to occur to create these changes, and what capabilities enable the decisions and actions. Desired Changes, Decisions, Actions and Capabilities all create and / or require Data, and the final step of data requirements brings together the complete data acquisition and measurements of the virtual and real worlds.
The outcome of this stage is a solution specification for the software and hardware components of the twin, a data strategy, and a change strategy for business processes and user activities that enable the solution to work in the real world. Executing this stage well results in a feasible twin design, which is technically capable of creating the required changes to solve the problem in both the real and virtual worlds.
Usable solution
Many industrial products suffer from very low adoption rates and products that have many interfaces with existing products and processes suffer the most. When users encounter complexity, and when users in one department need to work with users in another department to execute new or changed business processes, the inevitable result is confusion, friction, frustration, Excel and WhatsApp. To combat this, solutions and changes must be designed with the users in mind – both users of the solution and users of changed business processes. Change, in all its forms, must be designed for the humans who make the decisions and take the actions. Measurement of adoption enables the digital twin product team to target features and actions that do not work for the users, and to continuously improve these to increase ROI.
The outcome of this stage is the solution design, the change related products for users (business process redesign, training programs, change management etc.) and delivery of the final solution. A critical outcome of these steps is the instrumentation requirements to measure adoption and use of capabilities. Executing this stage well results in a digital twin that is used in its intended manner, and that provides the right feedback to designers to improve the product further, increasing value and ROI.
Viable solution
With a validated problem that defines the change required and potential value created, and a technically feasible solution that measures the change created – we are now setup to determine viability. The success of a product is often measured by its adherence to cost and budget. In a digital twin, we have defined success by the change in real world, and thus we measure success by the benefits created in the real world versus the increased cost of virtual world capabilities and real-world changes. Pre-deployment, this is a calculation, that must be weighted by the risk of failure and the risk of unintended consequences as a result of change. Post-deployment, this is a measurement that is highly impacted by adoption of users and successful change of business processes and actions. We measure the benefits and cost across the real and virtual world, to obtain the true “round trip” cost and value, and hence determine the viability of the product.
The outcome of this stage is a business case before we build the product, and cost / benefits analysis three, six and twelve-months post-deployment. Executing this stage well results in approvals for digital twins that are highly likely to create value and positive ROI, ongoing measurement and improvements of success, and reinvestment to iterate more and increase value creation.