G. Process Has Enough Capacity, But Process Lead Time Is Too Long Overview Processes often can generate entities quickly enough if we consider just the time between entities as they exit the process. However, sometimes an entity has to traverse the whole process in a given time to be considered successful. If the Lead Time through the process is too long, the process has failed to meet demand. For more details see "TimeProcess Lead Time" in Chapter 7, "Tools." Examples Industrial. Long delivery times on special orders Healthcare. Length of stay in an emergency department/surgery Service/Transactional. Billing cycle is too long
Measuring Performance Measuring Process Lead Time is simply a matter of attaching a "runner" document to an entity and time-stamping it as it progresses through the process. The total Process Lead Time is the time from when a single entity enters the process to when that entity exits the process at the other end. The time is measured as an actual clock time versus resource working hours or Total Work Content. Tool Approach First we must get an understanding of the current performance with respect to Process Lead Time: |  | Focus should just be on measuring validitya sound operational definition and consistent measure of lead time versus a detailed investigation of Gage R&R. For more detail see "MSAValidity" in Chapter 7. Quite often, the Process Lead Time isn't historically measured from end to end, so be aware of the start and stop points of the metric. | |  | Data capture needn't be too long because it is possible, at least in theory, to get Process Lead Time data on every entity that passes through the process. However, it is important to capture data over a long enough period of time to take into account any external noises that drive the Process Lead Time (volume of demand, different staffing models, etc.). The data is typically captured over a period of one week to one month (depending on process drumbeat) to get a reasonable estimate. | |  | Process Lead Time can be dramatically reduced by removing NVA activities from the process. A detailed Value Stream Map is a tool to identify those activities. Map with a focus on the Primary Entity and particularly the delays it meets. Be sure to consider the whole process from customer-request trigger to customer acceptance. Identify actions to eliminate NVA steps and thus accelerate the Primary Entity. | |  | Handoffs through the process can be the cause of significant delay. After the Value Stream Map is created, it should be relatively straightforward to add swim lanes to it to identify handoff problems. | |  | Apply a Multi-Cycle Analysis to the Swimlane Map to flesh out where the time is being spent along with an indication of variation in times. Usually it is the variability in step times that causes the problems. | |  | A Load Chart for the process will show Takt Time versus Cycle Time. For more detail see "TimeTakt Time" and "TimeIndividual Step Cycle Time" in Chapter 7. All steps should be meeting the pace of demand (or otherwise it wouldn't have enough capacity), but there might be opportunity to redistribute the workload and combine tasks to use fewer operators and hence have fewer handoffs. | |  | If, after balancing, there still appears to be problems with Lead Time, look to altering the resource structure to allow parallelism of tasks. Critical Path Analysis will allow the Team to see the longest chain of activity in the process that is driving the Lead Time. Offloading tasks from the Critical Path will reduce the Lead Time accordingly. |
At this point, the Process Lead Time should be significantly shorter. Move to the Control tools as outlined in Chapter 5. |  | If the Process Lead Time is still considered to be too long, there are still a few options available to us: Look to accelerating the pace of the individual VA steps (go to "2: The Pace for a Single Process Step Is Too Slow" in Chapter 4). Add additional resources to the process at the appropriate places (the load chart will help with this). Hold inventory buffers at key locations throughout the process so entities don't have to traverse the whole process to be delivered (only works if the entities aren't unique). Seek to anticipate demand from the Customer. (Is there an earlier trigger available to start the entity through the process?) Examine options to keep the entity "vanilla" longer. (Is it possible to pre-prepare any parts of the entity so less work is required from the point of request?) If all else fails, it might be a case of considering a different process technology.
|
|
