Thanks for that refresh on the 2013 discussion. 

I’m writing a chapter on knowledge mapping right now, and I wanted to make sense of the many quite diverse definitions for knowledge maps, so I went back to first principles and looked at what maps in general are used for:

1. To get somewhere (navigating through space or time)

2. To define boundaries and control what you own (cadastral maps)

3. To plan an attack (e.g. military maps - driven by a blend of #1 and #2)

4. To figure out where resources are so that you can exploit them (e.g. geography/geology)

5. To figure out relationships between things and reduce uncertainty so that you can do one of the above (sensemaking)

To go to the 2013 comment that maps can get out of date very quickly, and Matt’s reply about pace layering, I think it’s a fundamental feature of maps that they are intended to support repetitive use. They stabilise our understandings of the world for navigation, location, control, etc. 

If you apply that principle to KM, then in general you want to focus on mapping things in such a way that you can get repeated benefits from the map. The exception might be something like concept mapping in conditions of high uncertainty for sensemaking purposes, just so you can figure out what to do next, where your map is quite consciously for temporary use. But in general the value of “temporary” maps needs to be weighed against the effort in producing them.

On the APQC focus on business processes, we take a somewhat similar approach but we find that “business activities” is a better general approach to use in most cases we engage in, because the way “business process” is understood has some limitations. In the BPM world, if you just look at mapped business processes (a) you may find yourself just repeating the same knowledge resources across the entire process, so lots of redundant work; and (b) organisations engage in lots of interesting activities between defined processes that are often not captured in BP maps. This is why auditors often look at transitions between processes, because this tends to be where risks and errors creep in. There’s also a lot of unacknowledged/invisible/interstitial knowledge involved in how those gaps are negotiated, it tends to be the knowledge that keeps the different parts of the organisational machine going in a joined up fashion, and it presents risks when key people move on. 

When mapping “business activities” we ask participants to identify “the most important activities you engage in” in their own words, and give them a set of prompts for what they might be (key cycles, interactions with key stakeholders, routine activities, etc). If we say “business processes” they pull out their BPM maps and lock in to what they say, and tend to ignore everything else. And as we know, what the BP map says on paper is often not a true representation of what actually happens in practice.

We also observe that “business activities” tend to be at a slightly higher level of generality than business processes. We’ve seen organisations new to BPM take activity based knowledge maps, and build out business process maps from there. We’ve also seen BPM organisations take activity based knowledge maps, and assign knowledge resources from the maps to clusters of business processes. So they are similar in principle, and can communicate with each other but are not identical. 

If you look at the list of map functions, above, the two approaches serve slightly different purposes. To my mind business process based knowledge maps tend to function best at the “control” level (#2) where you already know your environment very well, whereas activity based maps are better at resource discovery (#4). So figuring out your goals can help you identify which type of map to use.

P