A McKinsey expert once told me “A dynamic model is like Kleenex – use it to fix an issue, then throw it away“. Now some digital twin business models are like that, but many, many more are built about issues or plans that continue, recur, or arise in multiple cases.
It should be clear why this is the case from my last post, on standard structures and business-system models.
CONTINUE using a model. If a model shows, say, what drives customer growth and sales, why would you not want to use that model continually? Even if you first build a model to fix an issue, say a customer-support problem, surely you would continue using that model to make sure that the issue does not recur. And if you build a whole-business model to fix a profit crisis, why would you not continue to use that model to plan and manage your strategy to sustain strong performance into the future?
REPEAT using a model. Other models may be built to help with a one-off episode, but similar episodes recur. Perhaps a model you built ensured the success of a new product’s launch. But your business goes on to launch other products. Surely, you would re-use that model for all later product launches – modified of course for unique features of each case.
A large construction company built a digital-twin model to plan, track and manage the complexities of a project. But the company repeatedly sells similar projects in multiple regions. Hardly surprising, then, that it deploys the same model – again, with modifications – every time.
REPLICATE a model. We all know that managing a hospital’s emergency department is complex! But I have lost count of the people who have told me they built a model on how that works, to help both short-term management and medium-term planning. Just how different can EDs be in different hospitals?!
On a more positive note, someone did tell me they had built a model to help plan and manage the operations and marketing of a micro-brewery business. They then ‘packaged’ that model as a standard digital-twin business model for any such business. (If that was you, please email email@example.com!)
And we would surely redeploy useful models for multiple cases within a large business – a marketing/sales model, say, for multiple products or sales regions; or a staff-development model for multiple departments or business units.
There is a huge price to NOT re-using digital-twin business models. There is the obvious case, of course, that building a single model may be a significant effort, or come at significant cost if you buy-in that work. (Although let’s not forget that this is faster, cheaper and more reliable than trying to tackle time-based challenges and plans any other way – especially with spreadsheets!)
So, management may not be willing to make the investment, whether in a digital-twin model or any other type, for just a one-time use. Especially so if this is the first time they have been told about such models.
And it is hugely wasteful to pay the effort and cost to solve the same problem or build the same solution multiple times. (I do wonder just how much effort and cash the UK’s NHS has spent getting multiple teams to do exactly that?)
Then there is the lead-time involved. If we need a solution quite soon, an existing model may be ready in time to help, when yet another new model would be too late.
And the continued, repeated or replicated use of digital-twin business models helps sell their value to senior management. It is hardly persuasive to say “Well, yes, I can build you a model to fix this issue, but then you’re on your own” or “I can build you a model to do X, but if you want to do something like that again, you will have to ask me to build another model“. Of course, digital-twin consultants do not in fact build a new model if the next project is very like a previous case, any more than any other kind of consultant re-invents previous work!
Lastly, there is the huge opportunity cost of not deploying powerful models fast, and widely, to every case where they could be helpful. Every day we do not deploy already-existing digital-twin models to solve recurring challenges is another day of avoidable under-performance. See my post on “adoption” challenges – getting people to be aware, understand, trial and commit to anything new that we want them to do.
I should end by acknowledging that I am not the first, by a long way, to issue this plea. The father of the field, Prof. Jay Forrester, said, half a century ago, something like “Our task is not to solve problems – it is to find solutions to whole classes of problem.”