Contents of This Page
How to Think About Process Maps
- Where Are You Coming from?
- MORE DETAIL
- Why Think about Process Diagrams?
- The ActionMap Diagram Format
- History of Process Diagrams
- Flow of Content Compared to Flow of Control
- The Evolution of the ActionMap Process Map Format
- How to Get Started Creating an ActionMap Process Map
- There Is an Art - Deciding What Is In the Central Process
- Naming the Central Process
- The Big Question about the Central Process
- Deciding Between a Distinct Separate Process and an Area of Interaction
- Guidelines for Deciding between Distinct Central Process and Area of Interaction
- The Rest Is a Mechanical Procedure
How to Think About Process Maps
Depending on your prior experience with process mapping, you are likely to have a particular point of view about ActionMap process maps.
If you have done little or no process mapping, any type of process map might seem complex.
If you have done a lot of process mapping, ActionMap maps might seem overly simple.
ActionMap is designed to strike a balance, leaning toward "simple and still effective."
That is because we believe that:
- Process mapping is a very important part of accelerating process change;
- Process diagramming as a skill is a strategic competitive capability; and that
- many more people should have the confidence to quickly create effective process maps in many more situations.
With that in mind, we'll start with the point of view of people who may not have done a lot of process mapping.
ActionMap Process Maps are pictures of how people do things. They can be thought of like this:
A structured sketch
You can draw one on the back of a napkin. It's been done.
A graphic list
You probably keep lists. ActionMap Maps arrange the items in columns.
A visual story of how things happen
Tell the story with a visual assist.
An extension of short term memory
You can only keep so much in mind at one time.
A simple form of animation
The arrows provide the movement.
A way of showing relationships among people, organizations and systems
Relationships = the way they interact.
A way of focusing on how things work
Processes operate through transactions. Maps show the transactions.
A structure for helping people talk about their interests and priorities
Start with agreement on the objective facts, shown on the maps.
A critical tool in creating strong shared understanding, agreement and commitment to take action
What should we understand, agree on, and commit to?
Things that can be drafted, adjusted and improved
Changing processes means changing the process transactions; you need to see them to change them.
And please see the following links for different uses of ActionMap Process Maps:
ActionMap Process Maps are data flow diagrams
A key component of Structured Analysis, a systems analysis method that is literally used for rocket science.
ActionMap Process Maps are system activity diagrams
The widely used IT project management format, with more structure and extra information in the Central Process.
ActionMap Process Maps emphasize showing everything that happens compared to showing things happening in sequence
Because that is all that is needed for getting people to talk about their interests with respect to the process.
ActionMap Process Maps can be enhanced with annotations to show more detailed connections and sequences
In hundreds of process improvement meetings this has rarely been used.
ActionMap Process Maps focus on flow of content versus flow of control
Flow of content arrow ("data flow diagrams") carry more graphic information and are better at evoking experiential memory than flow of control arrows ("box and diamond diagrams").
ActionMap Process Maps are designed to support process change over process operations
Because process change depends on people's:Knowledge
which are best evoked through fast, complete and accurate overviews versus detailed sequences, decision points and divisions of responsibility.
ActionMap Process Maps can be combined to show any level of detail in any process
Which gives them a great deal of analytic power.
ActionMap Process Maps provide a fast, effective discovery method for other types of diagramming
They play nicely with many other methods.
The following section describes:
- Why process diagramming is important to learn
- The history of process diagramming
- The ActionMap diagram format
- Two major types of process diagramming
- The importance of "flow of content" versus "flow of control" in process change
- The evolution of the ActionMap Process Map format
- How to get started creating an ActionMap Process Map
- Naming the Central Process
- Deciding between a distinct separate process and an area of interaction
Short answer: process diagramming is a strategic competitive capability
1) Process diagrams are a major tool in accelerating people's detailed shared understanding of processes. Without that detailed shared understanding, successful process change is difficult to achieve. Which is a major reason why process change is slow, painful and often fails.
2) If you cannot personally use process diagrams then your capabilities for driving, leading and managing process change are dependent on other people who can personally use process diagrams.
3) Historically, the capability to use process diagrams has been limited to IT professionals and process improvement experts. More specifically, organizational change leaders often have little experience with process diagramming. Further, the people who know how to create process diagrams are in short supply and have many other things to do.
The result is a major bottleneck in overall worldwide process innovation, improvement, development and change.
4) In the age of Digital Transformation and rapid social, economic, scientific and political change, process diagramming is more important than ever. Process diagramming is in fact a strategic competitive capability, whether you are competing with other organizations or just to keep up with customer and citizen needs and demands.
It is therefore more important than ever that many, many more people acquire process diagramming capabilities.
5) That is the primary purpose of ActionMap Inc.: to broadly increase people's capabilities for process change, in particular by broadly distributing easy-to-use process diagramming skills.
The image below shows the basic format of every ActionMap Process Map. If you think about it, you can see that it is essentially a table with rows and columns. So it is easy to read and simple to graphically construct. At the same time, it has strong analytic capabilities, and can be used on virtually any activity that can be considered a process.
How did the ActionMap format get to be this way, and how can you start using it?
Let's go back to the beginning.
Historically speaking, process diagramming is relatively new and has rapidly expanded in use.
- 1920's and 30's - original broad use in electrical and chemical engineering
- 1940's and 50's - expansion into "operations research" for mass manufacturing
- 1960's and 70's - expansion into computer hardware and software design
- 1980's and 90's - expansion into Total Quality Management and Reengineering
- 1990's and 2000's - expansion into Business Process Management
Two major extensions in process diagrams have occurred.
▪ An extension from physical layout to logical relationships:
- Electrical and chemical engineering diagram started with precise physical representation. Physical parts were connected on the diagrams and shown in physical relation to each other.
- Manufacturing diagrams necessarily became more abstract, showing sequence of events as opposed to detailed factory flow layouts.
- Software diagrams have little or no connection to physical layout; they are purely logical (at least to the programmers!)
▪ An extension from flow of control ("box and diamond") to flow of content ("data flow").
Please stay with this, because this is major decision point, and it is important to understand where to invest your time and energy for increasing your process diagramming capabilities.
The process diagramming format most widely used in business and information technology today is the "swim lane diagram", as shown below.
Swim lane diagrams are direct descendants of the original 1920's and 30's diagramming. They are very useful for process control, in terms understanding what needs to happen, delegating responsibility and showing hand-offs between separate work groups.
Data flow diagrams ("DFDs") are another major form of process diagramming. Data flow diagrams were developed out of mathematical network theories in the 1960's and became widely used in what is called "Structured Analysis", which is a very powerful general systems analysis methodology. The general format of a data flow diagram is shown below.
(In this illustration "Content" can mean virtually anything that can be moved, including information, data, signals, objects, money, energies or physical forces.)
A major guideline in the use of data flow diagrams is that:
- The arrows do not change the content.
- They just move it from one place to another.
- All changes to the content happens inside the "bubbles".
The major difference in the two diagrams types is in the how they use arrows.
▪ In swim lane diagrams, the arrows represent flow of control, i.e. "go to" or "do next".
▪ In data flow diagrams, the arrows represent flow of "stuff" (content), i.e. "this stuff from here to there".
▪ The difference is that in data flow diagrams, the arrows convey much more information.
Flow of control is very useful in process control, where each box has an assigned role and specific steps to perform. However, our view is that flow of content is more useful in process change.
Flow of content ("stuff") is very useful in process change, where all possible interactions need to be considered, and people's interests need to be evoked.
- Flow of stuff is more concrete.
- Flow of stuff is more measurable.
- Flow of stuff shows more information about relationships among parts of the process.
- Flow of stuff can be be more easily captured in any sequence.
- Flow of stuff is more recognizable as real world events.
- Flow of stuff evokes stronger experiential memories about events.
- Flow of stuff is more effective at prompting subjective knowledge, assessments and ideas.
- "I know that transaction; that's the one that has 10% errors."
- "That's the event that has the payoff for the customer; we need more of those."
- "If we could send those documents directly to Department X it would save 3 days."
The primary challenge with data flow diagrams is that they can turn into "spaghetti" charts.
- They become visually difficult to trace and understand.
- As such they lose their value for evoking people's knowledge and interests.
This can be partly resolved with a format called a "System Activity Diagram":
However, that reduces the amount of information in the diagram and becomes inefficient in terms of graphic space. Those concerns can be remedied with a more structured format like this...
...which with a little more structure becomes this...
...and with a little more detail becomes this.
This Is the Format Used in ActionMap Process Maps.
While this format gives up a certain amount of analytic detail, additional graphic detail is seldom needed in ActionMap group sessions. Also the detail can be added through various techniques (link to be added).
The important thing to note is that the format above is very efficient and effective at discovering, capturing and sharing the transactions, or flows, of the process.
Again, the flows, or transactions, are the starting point for process change.
▪ They are real.
▪ They are measurable.
▪ They can be easily recognized and reacted to.
▪ They can be acted on, and perhaps most important:
▪ Effectively, the process only changes when the transactions change, in content, quality and/or frequency.
▪ If the transactions do not change, then the process effectively has not changed at all.
Therefore, it is very useful to focus directly on the transactions.
One challenge with the above format is that all the arrows only go to and from the center rounded rectangle (called the "Central Process"). There are two needs that are related to this:
1) Showing transactions that go between the boxes on the sides (called Boundaries).
▪ Our experience in hundreds of meetings is that this is very seldom needed in terms of effectively using the method. This need can also be addressed in two major ways:
▪ Labeling the sources and destinations of the arrows (link to be added.)
▪ Assuming that all the arrows can potentially go to any side box.
2) Deciding what should be in the Central Process
Consider an area of activity that you would like to change: your job, a business, a community program, something that is important to you. If you consider all the interactions that can happen in that situation, you might come up with a data flow diagram that looks like this:
The reality is that causes and effects go on forever. However, you have to draw a line somewhere.
That means you have to limit the area that you want to focus on.
You can always extend or shrink those limits. However, if you don't have those limits you won't be able to focus on the details.
The next thing to understand is that you have limited capability to change the process. Some of the parts of the process you can directly control, other parts you can at best only influence. So the next step is to think about those differences.
In ActionMap the parts we cannot control directly are called "Boundaries" and are represented by boxes as opposed to rounded rectangles.
From there, it is a simple transition to the ActionMap format:
The key remaining piece is...
The Big Question about the Central Process:
Is It a Distinct Separate Process or an Area of Interaction?
From this perspective, processes can be sorted into two major categories:
▪ Distinct Separate Process
▪ Area of Interaction
Examples of a "Distinct Separate Process" are: task, job, project, team, organization, information system. These are things that people can point to and say "this is inside the activity of the process, that is outside activity of the process."
In the Distinct Separate Process, the arrows very specifically go between the Boundaries and the Central Process.
Examples of an "Area of Interaction" are: a negotiation, a group social conversation, a neighborhood, a possible new business model.
In an area of interaction, the arrows are used to show how the Boundaries interact with each other, with the assumption that any arrow can connect with any Boundary. In other words, the arrows go through the Central Process, which acts like a "switchboard" for the flows.
In a Distinct Separate Process, the side parts talk TO the Central Process.
In an Area of Interaction, the side parts talk THROUGH the Central Process.
An area of activity people, groups, systems, etc. interact in a structured way, and we know a lot of the details. Examples:
Generally used when people are coming together to improve a specific area of activity that is fairly well-defined.
In this situation, we have a fairly good idea of where the arrows go, so we try to make them as exact as is reasonable for the allowed time.
An area of activity where people, organizations etc. interact in a unstructured way, where we don’t know all the details. Examples:
- Neighborhood planning view
- New business model
Area of Interaction is generally used when people are coming together to learn about an area of activity that may not be well-defined.
In this situation, we generally know the arrows that come and go from individual boundaries. However, we may may not know exactly where those arrows connect. In that case we want to just get the arrows captured so we can talk about them.
1) Consider if the process is obviously a Distinct Separate Process.
2) Ask, from the perspective of what you are interested in changing, whether the boundaries primarily interact with a few other processes (which together make a Distinct Separate Process), or whether they interact broadly in many different ways (as in an Area of Interaction).
3) When in doubt, start with an Area of Interaction.
In hundreds of uses of the ActionMap Toolkit method, there were only a handful of situations where it was not immediately clear how to identify what was in the Central Process, and in those case the question was quickly resolved through a brief discussion.
The rest of ActionMap Process Map construction is a highly mechanical procedures, described with step-by-step instruction in the software.
Suggested Next Pages
To add or view comments about this article please go to the forum post at this link.