The previous post, Measuring Service Time, defined service time as the wall clock time to provide a service from start to finish. This post describes how to use service time as a measure of process flow.
The productivity of people and tools has dramatically increased over the last 20 years. Yet with all of that increase in productivity, things still seem to take too long to get done. The service times of processes have remained stubbornly high.
Traditional process improvement is conducted from the perspective of helping make people more productive. But what about information? It’s impossible to perform any process without information. However, the productivity of information is largely ignored. In most organizations people are busy but information is lazy.
To understand why this is true, it is necessary to break service time down into two components. The Agile and Lean Glossary defines the first component of Lada’s Laws as:
To understand why this is true, it is necessary to break service time down into two components. The Agile and Lean Glossary defines Lada’s Law as:
Service Time = Work Time + Wait Time
Where:
Work Time = The time necessary to apply assets to create value added work if there are no blockages or interruptions
Wait Time = The time an asset is waiting and not being used to create customer value
The first component of Lada’s Laws defines two contributing components of service time from the perspective of information, rather than a people perspective.
For example, consider the following process:
- A service request is received via email
- Information about the request is entered into a database
- Phone calls are made to gather additional information about the request
- The additional information is entered into the database
- It is determined which resources are necessary to complete the request
- The request is sent for fulfillment
For the above example process there are periods of time when someone is working on the service request (work time), followed by periods of time when the request is waiting for someone to work on it. From the perspective of the request’s information, it is alternately waiting and then being worked. For this process the wait/work cycle repeats at least 5 times.
From the perspective of the individual handling the request, they never wait. They work on multiple service requests, one at a time, each at a different step in the process. The individuals performing this work have very little non-value added time.
It is a different story from the perspective of the service request. Whereas the people are busy, the information about the service request is very lazy.
Let’s define the following for the process above:
- The average work time to complete the process above for one service request (work time) is .5 hours
- Each person averages a throughput of 2 service requests per hour
- At any point in time each person is assigned an average of 15 service requests; their work-in-process (WIP)
Little’s Law establishes that Work-in-Process = Service Time * Throughput. Since Service Time = Work Time + Wait time, the average wait time for a service request is 7 hours; [(13 / 2) - .5].
Based on this information the people performing the process are very efficient. Their average work time equals their average throughput.
However, the service request information is very lazy. For just this segment of the process, the average service time is 7.5 hours. This means that if you put a tag on a service request that entered the process, that same tagged service request would exit the process an average 7.5 hours later.
For that same tagged service request, someone is actually only working on it for a total of .5 hours. For the 7.5 hours our tagged service request is working its way through the process, it is sitting around doing nothing for 7 of those hours. How lazy can it be?
The invention of Lean is how to make information just as busy and productive as the people of a process. Lean does this without adding more people or more automation. It just requires some process design changes.
The next post, Effective Information Flows, describes how the ratio between work time and wait time indicates the effectiveness of information flows.
Recent Comments