Should we use flow charts, swim lanes, value stream mapping, proprietary software notation, or BPMN?  Yes, there a number of notations you could use, and you want to pick the right one for your organization.

The first question to ask is what is the purpose of the process diagramming notation?  Since there are several purposes for process diagramming at different stages of a BPM/ process improvement project, you may switch to one type of notation or another at different times.

Purpose 1:  A high level map to scope the project and as part of the charter.  Here I suggest using a simple flow chart with 6-10 steps using rectangle for activities/steps, diamond shaped decision diamonds and directional arrows.  You could actually create it in PowerPoint, but I usually do it in Visio.  The purpose of this map is to get people understanding what a process looks like. 

A high level process map is:

This article covers an issue within Business Process Management (BPM) redesign which is often not fully discussed. Frequently, development groups are eager to get the team fully engaged as quickly as possible. Looking at “as is” situations (examining, modeling) may receive slight attention as being “bygones” – “Let’s start with a clean slate.”  The issue is deciding how quickly to begin computerized development after a project or analysis has been scheduled. 

There are different aspects of business growth and development.  One faction may wish to apply technology to change its business as quickly as possible, while another may prefer to proceed cautiously and methodically, moving only after research and through using a well-tested methodology. Which is correct? The classic answer is “It depends.”

Except for natural disasters such as earthquakes, floods, or hurricanes, all risks are man-made.  This article is a synthesis of three past Harvard Business Review articles.  The bibliography is at the end of the piece.  Project Managers (PMs) usually have very little control of the risk circumstances in which they are placed. Taken together, viewing risk from the combined perspectives of the authors cited should help PMs assess risk in their own environments. Summarizing the titles as follows: “Right Risks,”  “Is it Real?” and “Hidden Traps” will help us consider the contribution of each, and then meld them into the PM’s decision process.

The Right Risks

If you don’t get off to the right start with a BPM Project, there are all kinds of consequences such as:

• Needing to change process owners mid stream
• Wasting time focusing on the wrong goals
• Not involving the right resources
• Missing critical information and making poor decisions
• “Buying” the technology solution

Do you notice any built-in contradiction in the title of this article? A naïve approach to Continuous Improvement (CI) would be to attempt to benchmark Toyota, and just do what they do. That would be OK if: 1) You make automobiles, and 2) You have fifty years of Toyota management experience. Without those advantages, you would do best to consider a modified strategy.

It’s not easy to change, and usually not fruitful to change precipitously.  An anecdote from an unnamed country, several wars ago, decided to mechanize the cavalry. An inspector, reviewing the prototype of the new battalion, marveled in the shiny new personnel carriers and tanks.  However, he then noticed two soldiers standing off to the side, apparently doing nothing.  When he inquired, he was told: “They are there to hold the horses.”