Monday, 9 February 2009

Mapping vs. Modelling

Bookmark and Share

If we think about maps the most familiar to us is the road map. Then we can have many maps together and 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. 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. Our maps or atlases are static representations of the world and once drawn they are difficult to edit and change, especially if a change on one page or map has an impact on another. So in process terms if we are simply drawing pictures on a page then the chances are we are creating maps and most maps are just that – pictures. Visio and PowerPoint being the two most common mapping tools used today.

Something else that we should bear in mind about maps is that we can have many different types. We would not want to use a road atlas to go walking in the hills, or detailed ordnance survey map for driving. We know instinctively that each form of a map has a specific purpose. Maps are also only representations of the world as perceived by the creator of a map, think for a moment about how maps themselves have evolved over the years. You would not want to use a map from even 10 years ago to navigate around the world today.

If having created a map you wish to undertake any kind of 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 asses 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 modelling 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 to 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 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 modelling tool for that to happen. It is also better in the long term to store maps in a modelling 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 interdependencies would add value and enable better business decisions.

In summary, use a map to understand or define a process or problem, then use the map to look at waste reduction or other quick hit opportunities. Then when you have eliminated wasted activities, rules, moments of truth etc. then you would be better to capture the resultant map in a model, adding details as required.


Pierre Pavageau said...

I agree with you. Using processes is truly efficient when trying to automate something that is always the same, or at least doesn't change often. The analogy that would suit yours would be the road from your home to your work: it's always the same every day except when you or your company moves, which happens rarely, or when there is an accident or roadwork or traffic, and that files in the exception category, which you can handle in BPMN. Bottom line is, for that trip, using a process is absolutely fit, and you'll have ROI in no time. The good part is that most companies literally have a ton of those, whether they call them procedures, processes, actions, or activities, and that is where BPMS companies come into play.

Therefore, before creating/modeling/using a process, you have to think about it and make sure that making a process will actually gain you time/efficiency/speed/productivity and what not, and this is where you would get rid of the wasted rules, activities and so on. To keep the same analogy, you wouldn't model a process for the road from your home to your vacation place, because the vacation place is different every year AND you only go on vacation relatively rarely anyway, so unless you want to consider the very VERY long term (but as you said, who wants to use a 10 year old map ? no one), you actually waste time using a process for such a trip.

Mark McGregor said...

Thanks Pierre

I would say that I do not feel there is value in using BPMN for mapping. BPMN as mentioned in other blog entries is an IT notation for modelling low level parts of the process (see below for the entry on process vs. procedure. In my speak BPMN is for creating procedures. This is on the basis that it is designed for drawing activities prior to their being automated.

My point here really was more aimed at making sure people don't waste money on using a modelling tool to just draw maps. Conversely not to imagine that if they have created a map that they can call it a model and carry out detailed analysis as you would with a model.

The notation can be a red herring as the truth applies regardless of notation. In the the same way whether you are working at a process level or a procedure level the same holds true.

Ben Graham said...

Hi Mark,

I agree with your view almost completely with a minor exception regarding the appropriateness of process maps for analysis.
"Conversely not to imagine that if they have created a map that they can call it a model and carry out detailed analysis as you would with a model." Even here, I agree, when the map is created with Visio or Powerpoint or if it is some adaptation of a box and arrow programming flowchart(and most are) it has limited value as a tool for analysis. However, Graham Process Maps provide a simple presentation with a level of detail that is not found in other methods. They provide visibility over all documents/systems/forms/reports in a process and the relationships between these items. They are quite suitable for analysis and are readily accepted by business folks and IT folks alike. Based on the ANSI/ASME standard for Process Charts (established in 1946), they have been helping people understand and improve business process flow for well over half a century.

Mark McGregor said...

Hi Ben

Thanks for your comments, it is always great to have you add to the debate. You were very kind in not adding your link to the post, so let me do it for you :-) For anyone wanting to learn more about Graham Process Charting you can check it out at

I guess we were coming from slightly different perspectives. In my case I was simply pointing out how best people should use the tools they already have/use. I would also add that in my experience people can actually simplify the process greatly with just activity boxes. So often we find that we can simply eliminate activities, challenge rules and identify moments of truth. All of which can easily be done on brown paper or within Visio type environments.

It would be great to see the Graham Process Charting supported by a repository based modelling tool in order that we can look across processes, rather than just at the single process.

Kind Regards


Anonymous said...

Hi Mark,

Are you saying that you can convert a map to a model by adding data?

Also, it would be helpful if you provided examples of maps and models, particularly of the same process.

Dan Madison

Mark McGregor said...

Hi Dan

Yes I am saying that if we take the the resultant map we create and draw it in a modelling tool, we can then populate the definitions to turn it from a map to a model. Remember, the activities drawn in a map only have a label, whereas those drawn in a model have significant additional data attached to them (in the form of a definition), this is how they become part of a model. Examples of the data contained in the definition might include; Who does the activity, how long it takes, what resources it consumes, what rules or regulations apply etc. etc.

Hope this helps to clarify the position.

Kind Regards


Lucas Rodriguez Cervera said...

My background is more related to change management and communication than to BPM and process automation, so I am not familiar with the discipline's teminology.

I believe I can provide a different point of view.

For me a model is simply a "simplified description of reality". Therefore a map is a model, and if you add data to shapes in that map, you have a (more complete) model.

Just a point of view...

Julia Wagner said...

I think that the map is differ from the model exactly as how photos differ from the video: photo captures some state, while the video adds relations between events. Вut the video takes longer to perform.
I prefer to spend some more time to create the model then simply get a map. But I agree that it is wasteful to spend much time to create a model of rarely repetitive, and inefficient processes.

Mark McGregor said...

Thanks Julia

As you suggest all opinions are valuable. Whilst the starting point of map or model will differ from person to person. I think for me the value in your observation is that you understand the difference and actively choose a particular approach. This makes it a very informed choice and one made in full understanding of the relative merits, which is something I can agree with totally, even if I would chose a different starting point. Both are right :-)

Kind Regards


Julia Wagner said...

Thanks Mark
I believe that the map is the most suitable for describing the high-level processes. While it is better to use a special tools for detail to not only model, but also to execute processes. In this case the process will not remain only on paper. Indeed, both are right :-)