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 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 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.

Copyright Mark McGregor 2007 | www.markmcgregor.com