Just like the basic ideas of processes and the division of labor, business process modeling was born in the mechanical industry.
In the winter of 1921, Frank Gilbreth presented a paper to the American Society of Mechanical Engineers entitled “Process Charts: First Steps in Finding the One Best Way to Do Work” — an excellent title by any standards, and something that turned a lot of businesses onto the idea of modeling their processes so they can optimize them.
Gilbreth, the paper’s author, is probably better known as the author and central character of the 1950s novel Cheaper by the Dozen. While I’ve never read it, it amused me to find it that an industrial engineer-turned-management consultant wrote a novel with time and motion study as an underlying theme.
Gilbreth was an interesting character, but also a man laser-focused on exactly what processes are for: finding the one best way to do work.
The basic theory of business process mapping
Why do you need to map business processes? According to Gilbreth, it’s because you need to take stock of your processes before you can begin to improve them. By looking at the big picture, you can see the cause and effect of each step and start to understand the process flow properly.
“Every detail of a process is more or less affected by every other detail; therefore the entire process must be presented in such form that it can be visualized all at once before any changes are made in any of its subdivisions” — Gilbreth
Here’s the form he was talking about:
That’s an informal draft version of a cross-functional process map, which means that it has steps in it that need to be carried out by different people. On the left, you can see the steps are divided amongst the manager, department head, etc.
When process maps are finalized, they’ll look more like this:
Not the most beautiful thing you’ve ever seen, I’m sure, but it can do wonders to fix a slow and inefficient business.
Gilbreth finishes his essay with two quick notes:
- Visualizing processes does not necessarily mean changing the processes
- Process charts pay.
Here’s how to get started with process mapping.
Getting started with process mapping
Ian James, founder of The Process Consultant blog (one of the only other blogs that talks about processes like a human being), has a lot of knowledge to share on process mapping. In his article on the topic, he even lays out a few tips for mapping a process:
- Map the process “as is”
- Ignore process exceptions
- Involve those who execute the process
- After a rough draft, document digitally and share
- Make sure to map on a big canvas
- Collect example documents for every step, if there are any
(Stay with me ’til the end for a full interactive process based on Ian’s tips!)
Processes are mapped in groups, where someone will map the process while the team that executes it explains how they do it. Teams use big whiteboards to draw up the flow before documenting it digitally.
It’s important to remember to use a messy whiteboard when you’re getting together the initial draft because people would rather not change digital information, but don’t mind scribbling on a board. It’s a bit like how people write better in notebooks.
The anatomy of a process map
A process map is a lot like your every day flow chart, but also includes some elements exclusive to business process management nerds. Here are the basics you need to know:
There are, of course, more complex symbols, too. Nothing’s ever jargon-free in business.
There’s nothing stopping you from making up your own, either. Check out this (borderline hilarious) list of chart symbols from 1899, cited in Gilbreth’s Process Mapping essay:
So, yeah… if you ever need an ‘inspection for quality by kinesthesia’ symbol, there you are!
A very official approach to business process modeling and notation
In the same way that a group of people called the Unicode Consortium control which emojis you’re allowed to use, there also exists a group that seeks to standardize the way you map processes.
They’re ironically called OMG (because there’s nothing shocking about them). They joined forces with the Business Process Management Initiative in 2006, sat down at a big table and — thoroughly sick of the inconsistency — decided to fill the vat of coffee and hash out the single best way to represent a business process.
The result is BPMN (Business Process Modeling & Notation) specification. It’s available to learn for free on their site (here) and is the generally accepted prim and proper way, used by businesses small and large.
Some of the notations are pretty complex, but it is nothing if not thorough, and that’s exactly what a business with a ton of varied and messy process diagrams would need to pull itself together.
For a gallery of business process map examples, including where I’ve got the above example from, go here.
Optimizing your process models
The problem you might run into while creating a process map is that you could end up making it either too detailed or too basic. When it comes to this issue, Ian James has a great solution:
“Is it accurate to say “Joe does this bit of the process all by himself”? If the answer is “Yes” then it is safe to abstract all those tasks into a single activity box. If the answer is “No” then you need to break it up into separate boxes so that it’s true for each box.”
Basically, if it needs explaining and breaking up, then do it. If it doesn’t, then compress it into one box and reduce the size of the map. After all, you don’t really want your process map for logging into your email account to end up looking like this behemoth:
The process for creating a process map
As process creating software, it wouldn’t be fair to go on about processes for so long without giving you a process. Below is a checklist you can run from start to end to create a process map.
And, don’t forget the strong guarantee from Gilbreth: process charts pay.
Great article Benjamin. You mentioned draw.io as a possible process mapping tool. Are there any others you would recommend?
yep! I’d say yEd is better, actually, and I should have included it: https://www.yworks.com/products/yed — totally free and open source for the solo, local install. It costs for the cloud version.
Thank you for blog on process modeling! I am happy to read about this subject because I encounter it in my daily work as process improvement / Lean Six Sigma specialist. My biggest challenge with a team when trying to describe the process is that they tend to deviate from the reality towards how the process “should” be like. My rol is to keep them focused on the current situation. Another challenge is to agree on the process steps because everyone tends to have his own version of the process. That has to do with the detail in which you want to describe the process. That’s why I liked your suggestion: ” if it needs explaining and breaking up, then do it.” Thank you again.
I really need to read more on Six Sigma. Also, what do you mean by them deviating? Do they skip the mapping ‘as is’, and then go straight to ‘I don’t like X about the way things work right now’?
Thanks so much for commenting!
Benjamin, people tend to mix reality with wishes and how it supposed to be according to the quality manual. With Lean Six Sigma first you want to get the “as is” situation on paper because only then can you find the causes of the unsatisfactory output related to steps within the process. Thank you for you valuable articles!
Talking about process mapping tools it is a lot easier using any of the pc’s tools but I do prefer an white board. Peter has a point in this!
Hi Benjamin, Good article about bpm. If possible can post some more articles on bpm realtime developing coding articles. once try to post that one .