In technical and service organizations, people are sitting at desks, working at computers, walking about, sitting around conference rooms, and generally busy moving from task to task. It is very difficult to understand the workflow in the same way you can map a physical product as it is being transformed. In service organizations, the work is often organized around projects that vary widely in size, complexity, number of people involved, and lead time. But if you start with the customer, define value, and then map the process that adds value to the customer, identifying workflow can be more manageable.
My associates and I have done over one hundred kaizen events on technical and business processes and it is always eye-opening for the teams how much waste is uncovered once they start mapping the value stream. Another eye-opener is the discovery that the bulk of these processes are fairly repetitive and standardizing them is possible.
Illustrates a hypothetical account verification value stream. Waste in this case is mostly information waiting in queues for someone to act on it. People are working on their own timelines and there is no coordination among processes. This causes batches of stuff to build up before being shipped to the next process, where they may sit and wait. Often this is information inventory, rather than physical inventory, so it is more difficult to determine the amount. The key importance of physical inventory is how it causes a delay in the process, not the amount of physical inventory itself. And so it is for information inventory—when information is produced before it is used and builds up waiting, the main issue is time delays, just as with physical inventory.
The ideal of TPS is one-piece flow. However, as we have seen earlier in the article, the benefits of flow really come from tightly linking processes to bring problems to the surface. When you link processes in a flow, problems cannot hide in inventory or in queues waiting to be processed. When one department immediately gets the information it needs just in time from a supporting department, two things happen:
- If the supporting department gets behind, it will shut down the receiving department and will get immediate attention.
- There will be rapid feedback from the receiving department if there is a problem with the information provided by the supporting department.
Thus, problems will surface immediately, which will lead to the problem-solving process and organizational learning discussed in Identify Root Causes and Develop Countermeasures. Creating lean flow is the technical backbone of TPS in both service and manufacturing organizations.
There are five steps to creating flow in technical and service organizations:
- Identify who the customer is for the processes and the added value they want delivered.
- Separate out the repetitive processes from the unique, one-of-a-kind processes and learn how you can apply TPS to the repetitive processes.
- Map the flow to determine value added and non-value added.
- Think creatively about applying the broad principles of the Toyota Way to these processes using a future-state value stream map.
- Start doing it and learn by doing using a PDCA cycle and then expand it to the less repetitive processes.