An interesting blog post by Keith Swenson on unpredictable processes got me thinking about the use of a model in BPM. People use the term “to map the process” as a way to describe what is done during process discovery, and as the result of the discovery process. After having thought about it, using the term “map” is misleading, since the result is usually a set of codified directions – not a map.

A map is used to show the lay of the land, and existing obstacles. It doesn’t give direction (or focus on a particular path) – just shows what is out there (for better or worse), at various level of detail. For any specific navigation task, most of what is shown on the map isn’t relevant and it is up the person using the map to find the appropriate path. The more structured the terrain (e.g. an urban area, versus out in the wild) the easier it is to use automation to find a path. But in many circumstances the map doesn’t contain all the relevant details – especially about movable obstacles (e.g. where construction is happening right now, where there is an accident, where the lions are located at this very minute) – so you can’t always rely on the directions. As the terrain becomes less structured – the less detailed the directions that can be given, and navigating the trail relies more on the knowledge and skill of the participant.

Most BPMN models provide something closer to directions (since they don’t map all the terrain, but rather the process as it should be executed), not maps – which is why they work for routine processes, but are inappropriate for unstructured, unpredictable human processes. For unstructured, unpredictable, human work the best you can do is a very high level description (Guidelines, Best Practices, Checklist) – not a detailed model.