5 years, 7 months ago

Mapping vs. Modeling

Link: http://feedproxy.google.com/~r/BecauseProcessMatters/~3/xiOvpeT7D5o/

What are the differences between them and when to use each technique?

If we think about maps the most familiar to us is possibly the road map. Then if we put multiple maps together we can create a road atlas. These are great for allowing us to see where we are and where we might want to go. We could even use our maps to trace a route in order to plan a journey. But, of course, roadmaps are only one type of atlas. We could have in mind a world atlas, in which case we can identify continents and countries, but might find it hard to plan a journey from a city to city due to the lack of detail. Conversely, it might be that we have in mind a street map, with very low levels of detail, but hardly practical if journeying from one side of the country to another. We could go with other examples of nautical maps, flight maps or walking and climbing maps. All of these maps are designed and constructed for a particular purpose. When using maps for their intended purpose they perform well, but use them for the wrong purpose and we are going to struggle. We will also find that if we were to try and combine the maps together to create a multi‐purpose map we would create something that would, in effect, be difficult to read and likely to serve none of the intended audiences well. In practice we know almost instinctively when looking at a map what its purpose might be and whether it might be suitable for us. The same need for clarity of purpose should be true when mapping our processes.

Staying with the analogy of atlases, we also know that knowledge changes over time. We know that new or different information can change our perceptions of what is. Fundamentally, we understand atlases are static representations of the world. Ones that were created based on the information available to and limited by the knowledge of their creators. We also understand that an atlas of the world is not the world; we would not expect someone to be able to recreate the world based on an atlas or roadmap. We all accept that depending on the level of the map there will be details missing, whether low level or high level detail depending on scale and purpose. The same requirement for, or sacrifice of, detail decisions need to be made when mapping processes. We also need to remember that we are not likely to be able to recreate our business based on the maps alone.

So now, let us assume that we have created our maps. They are fit for our purpose and contain the right level of detail. Now we want to plan a journey from where we are, to some new destination. Just as with our road atlas we can use our map and plot a route based on our opinion and the visible clues we can read on the map.

Assuming that all was well, the journey could proceed and with luck, we would arrive at our destination as hoped for. However, if there had been a new road built or an old one dug up, we would at best waste time and at worst be unable to complete our journey. We might also arrive to have someone ask us why it took us days to make the journey. They may suggest that instead of the car we should have flown or taken the train. They may even start arguing about our route, suggesting that the longer way is quicker, or that another route was more economical. All of these would be valid comments and ones that could cause us to question the suitability of not just our map, but maps in general. In these examples we see that a map will allow us to plan a route from A to B, but the route we take may not be totally suitable once we add in other requirements. Once we add in additional requirements such as cost, speed, resources etc., we start to find that maps are not especially efficient.

At this point we need to find an alternative view, in the case of our road maps we start to see the benefit of route planning software or GPS systems, which are based on models rather than maps. The same needs to occur in our process projects. We need to accept that we can use maps up to a point, but then we need to switch onto making use of models.

From another perspective our maps or atlases, as we have stated, are static representations of the world and once drawn they are difficult to edit and change. Making changes is not impossible, but as we say just difficult. This change becomes even harder if a change on one page or map is linked to or has an impact on another. Or what if we decided to change the visual representation for a particular item? How can we be sure that the same change can occur everywhere? So in process terms, the pictures we draw with tools like Visio and PowerPoint are only pictures or at best maps. They suffer from the issues mentioned, lack of linkage, and lack of ability to change once and see the change occur everywhere.

If having created a process map we wish to undertake detailed analysis we will find it challenging. Sure, we can look at straightforward waste elimination or spot those other aha! moments, but beyond that we will struggle. The other thing that we have not talked about is detail. A box on a map or drawing is labeled but has no further detail attached. In a model the same box with label also has a detailed definition underneath it. So when it comes to analysis be it impact, time, what-if, resource or any other kind then maps will not be suitable, in order to do this you will need a model. In today’s world the best example of rich models, which we use, can be thought of as GPS Navigation systems. With these devices we can assess multiple route options based on a whole host of criteria. Compared to our road atlas the maps in these devices are seamless.

It takes much longer to build a model than a map as for each shape on the chart, one will be required to input additional data about such things as resources, cycle times, wait times, costs etc. The richer the “definition” contained in the chart, then the then the richer the analysis that can be performed. In part this is why modeling tools are perceived as being harder to use; they are designed to provide a richer analysis experience and to allow the use of the computer to do some of the comparisons and calculations for you. Maps can only really be compared with other maps by using the human eye and a whole host of other spreadsheets and calculators. Even then, such analysis is not especially efficient.

Whether you use a map or a model depends on your purpose. It may be that using a simple map, as a first stage in knowing what the process is and how to simplify it is a good step. Indeed this is the approach taught in my own classes and seminars, as first step tremendous waste opportunities can be discovered.

However, if you want to do more detailed analysis you will need to take the simplified map and enter it into a modeling tool, such as OpenText ProVision for that to happen. It is also better in the long term to store maps in a modeling tool as it makes it significantly more practical to maintain both the map and the interdependencies. Many suggest that the effort to build models is not justified; perhaps what they are really saying is that they cannot be bothered to undertake proper analysis? Or maybe they do not care about calculating timing or cost information – this would be surprising today.

Certainly, for those who wish to undertake any kind of automation, the models will need to be built. The cost of implementing a badly designed process or procedure is just too expensive. There is also an assumption here that your business contains more than one process and that understanding the inter-dependencies would add value and enable better business decisions.

The suggestion would be that we would be right to use a map to understand or define a process or problem. The resultant map can then be used to look at waste reduction or other quick hit improvement opportunities. Then when we have eliminated wasted activities, rules, moments of truth etc., we would be better to convert the resultant map into a model, adding details as required. Based on experience, this seems to be the most cost effective way of moving toward managed processes in practical way. As many have discovered the act of detailed modeling first and then eliminating is an expensive route to go down.

In the context of Business Process Management (BPM) this distinction is vital, because we have said that we wish to manage our processes. To manage them we have to find a way of filing them in some logical way that enables us to navigate them later. This act of filing in effect is another way of taking maps – binding them together. When grouped together they become manageable. Taking it forward another step, if we then link them together in that filed world, we can carry out impact and change analysis and monitor across maps. Thus, if we wish to undertake BPM we need to put everything together in a cohesive and coordinated manner, so for truly effective BPM we need models. If we are just working with maps we can visualize and improve, but we will find it difficult to manage them effectively.

To end, starting simple and growing with your approach is easily supported with OpenText ProVision, and of course you can then use your resultant models to guide your automation or system initiatives. The traceability of such an approach makes it far easier to mange future change, while ensuring that your projects are always aligned with the corporate strategy.

Related posts:

  1. Business Architecture 101 – It’s results that count! Business Architecture may not be a new term, but it…
  2. Mass Modeling Process discovery and process validation are interesting topics and ones…
  3. The Reality of Process Excellence Whether we like to admit it, most organizations are still…

Related posts brought to you by Yet Another Related Posts Plugin.