Do you experience these challenges in trying to create a current state process model?
- The team gets mired in process problem details
- People have ideas for improvements but you are not really ready for solutions yet
- Some groups do the process one way and others do it a different way.
- Some people think it’s a big problem but you don’t know for sure.
Here are two techniques that will really help you out and make life much easier.
- Start with a single process instance
- Keep the I-4 Lists as you document
Start with a Single Process Instance
Begin by selecting a single process instance that the team will follow. Capturing one instance of a real completed process makes it easy to complete the model in 90 minutes or less, and it won’t have the spaghetti look of a process model showing all the exceptions.
For optimum results, pick an instance to start with…
- …that is an actual use case of the process and is completed
- …that represents a common example of the process
- …that had some obstacles but was not the case from hell
- …that many team members were involved in
Lots of ideas will come up as the team diagrams the instance. Instead of discussing each one the Team Facilitator can capture those ideas on an I-4 List. These lists are actually the first cut at analysis of this particular As-Is instance. Issues Improvement Ideas Indicative Data Instance Differences
Figure 1. I-4 List Template
- Issues are any challenges or problems that team members relate while the As-Is instance is being documented. • Improvement Ideas are any ideas that come up that are recommendations for changes to make the process better.
- Indicative Data is quantitative data that would be helpful to collect to identify how the process is working at present.
- Instance Differences are examples of different ways the process is completed in other regions of the company, by different individuals or teams, for different use cases, or for different market segments.
The team will be tempted to go off on several tangents as they explain each step of the As-Is instance. The Team Facilitator’s role is to keep them on track, and I-4 Lists are an easy way to do that. When the team names a problem or recommendation, acknowledge it on the I-4 Lists, but do not let them discuss it or try to solve it at that time.
Recording the Activity Flow
The Team Facilitator runs the session and captures one instance of the process. I like to record the activity flow simultaneously in two ways:
- Using stickies on a large piece of butcher paper (4 feet by 9 feet) in the BPMN format. The butcher paper format engages the team at the wall and enables the team to visualize the whole process at once.
- Have an additional BPMN scribe experienced with the tool capture the same flow from the butcher paper in real time. (This can also be done after the working session.)
Below are a few tips for how to stay on track when diagramming a single instance.
- Insert a BPMN gateway (diamond) for each potential branch point in the flow. After adding the gateway, continue to model only the flow followed in this instance. Later on after the single instance is documented, go back and add the other path out of each gateway. Then ask the question, what would happen if the path did not go the first way? The other path may loop back to a previous activity, skip ahead to a downstream activity, or lead to a special activity only needed under certain conditions.
- What happened next? is the most critical recurring question for the Team Facilitator. It constantly reminds the team that they are recording what actually happened in this instance. Sometimes a team member says, “Well, we do this next,” or “And the next thing that happens is….” Stop and ask the team member what actually happened in this instance, not what can happen in in another instance.
- Recognizing the I-4 Lists
- When a team member says, “We have problems at this step” or “There can be challenges at this activity.” These items are issues and should be put under Issues.
- If a member says, “It should have happened this way,” that’s a clue that there is an improvement idea. Note that to the team, and write the improvement idea on the list.
- When a team member says, “That doesn’t happen very often” or “That’s a big problem,” that’s a signal that you want to get real data. Write that item on the Indicative Data list. Write something like “Find out how many customer service issues are in backlog on a daily basis” or “Identify how many input requests arrive incomplete.” Later, as a team, you will review this Indicative Data list and see which items are the most important to collect. (You do not have to collect them all!)
- When a team member says, “We don’t do it that way,” that’s a signal for an Instance Difference. Note it on that section of the I-4 List. In the working session, the Team Facilitator honors that there is an instance difference and writes it down, but does not include it in the process diagram. I have found that when teams try to include all the instances in a single diagram to start, they get very confused, it takes them much longer, and they can end up creating “spaghetti diagrams.” It is easier and faster to start with one instance.
After the initial process diagramming session, the team should review the list under Instance Differences to see if other instances are important to document or not. For example, you will need to capture instances that include each of the exception end states. You also may want to capture additional instances for different levels of complexity, different customer groups, or variations in process at different company locations. Carefully decide which additional instances are useful to document.
Using both a single instance to diagram the current state and the I-4 Lists help the team stay on track and out of the weeds when diagramming.