How is a Digital Twin Model better than Business Process Mapping?
How is a Digital Twin Model better than Business Process Mapping?
We are asked this question a lot, and answering it is fundamental to the success of business automation and transformation initiatives. In terms of the development and productivity of our industrial future, how we define the workings of business is an issue akin to that of the 'Great' debate of a geocentric vs. heliocentric earth that ultimately led to NASA creating the Digital Twin.
So let's try to dispel the misconceptions of current dogma when it comes to defining how business works.
To start with, there is a huge difference between a process map and a process model.
A process map is, like its cartographic namesake, a picture: a 2D representation of business activity.
A process model is, as the name implies, a scaled structure – a 3D replica of business activity.
In 2D drawings there is no intrinsic way of applying rules to check the legitimacy of what we have drawn. We have a palette of shapes – an oblong box, rhombus, and more – but they are merely drawing components. We can add words to the shapes and we can extract/search these words, but basically any integrity checking is manual. In the most widely used mapping tool, Microsoft Visio, the template of shapes available is virtually identical to that used by coders to design programs since day 1 of the IT industry.
Because of their IT origins Business Process Mapping tools have fundamental limitations that make them ill-suited for their most important function – communicating how a business works. To be sure, there are products that are more advanced than Visio, perhaps the best example being the German mapping product Signavio (now owned by SAP), but in the end they are still 2D drawing tools and as such they cannot fulfill the functions of a Digital Twin. At some point they will be side-lined in favour of process modelling tools since these do support the needs of a Digital Twin. For many organizations, the point at which this change is needed has already been reached.
With mapping you are essentially starting with a blank sheet of paper and adding drawing components. But a model is a scaled replica of something, in this case, business: a structure - how it is organized, how it undertakes activities, and how resources are used in those activities. With a model you are starting with a set of components and using them to define how your business works.
Modelling essentially populates a predefined business framework with the real-life information of a specific business. The definition can be in a list form since each component knows the information you must provide in order to create a valid model. However, one of the elements of a business model - its process/work flow - is best defined visually, and it is this that gives the mistaken impression that mapping and modelling are the same. In a model the flow is just one element, in mapping it is everything – if you don’t define a flow you don’t have a map. In modelling what you see in a diagram is a visual reference to the databased object that bears that image. If you move the object within a flow or to a different flow all the information associated with the object goes with it and the rules that apply to that component determine what you can do with it. This lets you see where in a model a specific component is used.
With a model of business you are just a short step away from being a Digital Twin – for which the model components must have a one-to-one relationship with real-life artifacts and actions you find in business.
This takes us to the fundamental limitations of Business Process Mapping:
1. Poor Communication Capability
Whatever you want to achieve with your map/model, accuracy of content plays a critical role – particularly if you are creating automated solutions from the map/model, where anything less than 100% accuracy in a process definition (including all its nuances such as exceptions) will cause the automation to fail. Mapping’s problem is that it is a conceptual representation of what’s happening in a business. It’s designed for program coders. It is not designed for workers to see themselves in the business, thereby better relating to the map/model’s content and seeing the content as ‘theirs’. They give answers but with no ownership of the content. It doesn’t trigger them to remember those important nuances – e.g. ‘what happens if this doesn’t match with that’, etc. They recall only ‘the happy path’. More importantly, it leaves out ‘tribal knowledge’, unique information held only in someone’s head, the content learned from experience that is so vital to the outcome the map/model seeks to aid. Mapping’s communication capability with the real-world is further eroded by some of the constructs and language it uses – workers are not used to seeing ‘swim-lanes’ in their business.
2. Lack of Process Flow
The most damaging aspect of process mapping is its lack of process flow definition, because it is in the flow of work between workers and robots at their desk or factory work centre that real transformational change can happen within a business. The longer a transaction takes to complete the more it costs and the more mistakes are made. Making sure that a transaction is always moving (i.e. no ‘dead air’) can dramatically affect customer satisfaction and profitability.
Defining business at the transactional flow level also appeals to executive management. Finally they can see an accurate picture of exactly how the business works. The flow diagram in modelling may look long but typically it will be a fraction (typically 1/5th) of what the same would look like in a mapping diagram, which shows only the flow of tasks that are undertaken in a process. Consequently, mapping outputs are impractical for showing a business’s core transactions end-to-end (e.g. Quote to Cash) …and it is easy-to-understand end-to-end definition that is needed engage the interest of C-level executives in business design technology.
3. Lack of Context
Because of their lack of process flow, maps are generally small portions of transactional processes, making it very difficult to construct an overall picture of the business. Unlike a model, there is no inbuilt component relationship capability. You can't reference a specific object in a set of maps, and this makes process connectivity impossible. Process structure is implied by document indexing rather than component relationship. Not only does it make it difficult for people, especially executives, to see how their whole business operates, but it also leads to the next limitation…
4. Poor maintainability
In a map there is no way to ensure referential integrity except by laborious manual checking. One of the Big 4 consulting firms said to us that the time taken to check the content integrity of a map was 1,200% greater than with a model. For example, a model will prevent you from deleting a component (such as a Task or a Role) if it is used in multiple places, without resolving these first. If, for example, a circumstance requires that with customer contact you are required to do something new, in a model with one change all instances of customer contact will be updated. The difficulty of changing a map is such that most businesses opt to start from scratch every time they need to use BPM to support a major business change. The cost of the lost effort is significant. As a consequence, process mapping (or modelling when perceived as the same) has never been endorsed as a strategic business tool under the direct ownership of the CEO, and therefore most CEOs having nothing at which to point and say ‘this is how my business works’.
We are rapidly reaching the point at which the advantages of Digital Twin Models are going to make model technology a strategic issue, especially with the arrival of 5G and the IoT. This will highlight the difference between a model and a map and in doing so finally resolve the question “How is a Digital Twin Model better than BPM?”