Flowcharts and process mapping are powerful tools we use to depict the flow of activities in a process. These show many different characteristics of the process, including process boundaries, responsibilities for the work to be done, the interactions between the steps. Possible disconnects where activities aren’t really connected to something else that needs to be addressed. Non-value add activities. Bottlenecks and inputs and outputs of the process. In the practice of DMAIC, define, measure, analyze, improve and control, we often find that this is very helpful to us in the define, measure and analyze steps.
Another thing to note is that process maps and flowcharts are often used interchangeably, although they are not exactly the same thing. A flowchart is the diagram itself, while process mapping is often when we add activities to the flowchart to illustrate a process in order to identify the waste and non-value added activities.
Flowcharts often use universal symbols. The first is a start/stop, which is typically an oblong-shaped circle, which would indicate where the process begins and where the process ends. This might have letters in it, if you wish to show continuity or sequencing for instance, where you would point from point A to point B. Next, we have the actual step or the operation, represented by a rectangle. Very often, this is where the money is actually being spent. The value add and non-value add activities that use time and money in the company are happening right there. From there on, we have a decision point depicted by a diamond. This may be a yes/no answer, and depending on the response, you would navigate in different directions on the flowchart. Then we have inspection, shown as a circle. This is the point in the process where quality tasks occur. Next we have delay, which is depicted as a capital D shape. Delays represent a point in the process where nothing is really happening. Finally, there’s a symbol for input and outputs. It’s a parallelogram shape, which looks like a crooked square. Inputs and outputs represent actions or items that enter or leave the process. For instance, raw materials are inputs to the process, while deliverables are outputs. Finally, we have the flow line which connects all the step shape components of the chart. It illustrates the logical flow from end to end along the entire process.
Building a flowchart is very much a team activity. And when we think about chartering a Lean Six Sigma project, we typically want to have our key stakeholders involved. That may include customers, suppliers, the project team, and subject matter experts who have expertise and insight into the type of work we’re doing. The point of building the flowchart is to capture the what, when, and where of the entire end to end process. What are the steps and activities that make it up? Next we must determine when the sequence of activities occurs over the flow of time. And then, where do things actually happen? Where do the inputs come from, and where do the outputs of the process go once they leave the process? For example, on a technical support call, some inputs and outputs are obvious. But others may be more subtle. For instance, what the customer tells us about their question or problem is an input. The ultimate output would be the solution we offer to our customer. Another more subtle input would be what we search for in the knowledge base and the output that we receive from that search. We need to be very detailed to include all of the inputs and outputs, not just those that touch the customer.
There are many ways to define the process boundaries. Generally, you will select a logical start and stop point. Then, work to identify all of the steps that fall within the process scope. But no more than that. Just as we define boundaries in project scope in order to avoid scope creep, we must define the boundaries of our process to avoid biting off more than we should chew. For this example, we will use the scenario of a gas delivery from the refinery to the gas station. We should consult those who are involved, who actually know about the process. They can help to identify the inputs and make suggestions about how the process works, and where we might improve it. We will start at a fairly high level and define a major task and a major decision points. From there, we can decompose the process, breaking it down into the smallest steps and making the connections between the steps.
Let’s take a look at the example of the gas delivery. The starting point is when the service station is low on gasoline. This triggers an output from the station, which is an order for gasoline. This leads to a step in the operation to dispatch an order to delivery. Dispatch sends the order information as an output, which is received as an input by the refinery. They fill the truck at the refinery. Then we encounter a delay while the truck is driving to the station and filling tanks at the station. At this step, we have a decision point while we ask this question. Is the truck empty? Yes or no? If yes, we have to return the truck to the refinery. But if no, the truck can receive input about where to go next and repeat the cycle of filling up another gas station.
Now we need to verify that our understanding of the process is correct. We need to show this to our key stakeholders and those who understand the process. Working with your team and stakeholders, you identify the necessary changes or improvements to the process. For example, maybe we can automate the step where the order is generated from dispatch. Instead, maybe we can automate the order process so that we can receive notification directly from the customer to the refinery. Could we eliminate that extra step and still accomplish filling the truck? Using a flowchart can help us to illustrate the process steps, which can lead to important discussions and improvements to the process flow.