O. Setup/Changeover Takes Too Long Overview The majority of processes don't have the luxury of processing the same entity type continuously for all time; thus, at some point (or regular points), they have to switch over to another entity type. This causes a downtime and hence lost capacity and responsiveness. Sometimes even the time between entities of the same type has the same impact. The former problem is often countered with the very poor solution of running long campaigns of the same entity type ("we can't afford the time to stop and change"), which causes lower delivery performance and increased inventory levels. It is much better to tackle the root-cause problem of the long changeover time instead. Examples Industrial. Line changeover, line setup, vessel cleaning Healthcare. Room setup, operating room turnover Service/Transactional. Freight vehicle change (e.g., road to rail)
Measuring Performance Changeover time is measured as actual clock time from the end of the last value-added step to the start of the first value-added step for the next entity (type). The words value-added here are the key to really understanding and capturing potential opportunity. Tool Approach |  | Look at validity of the time metric; a sound operational definition and consistent measure versus a detailed investigation of Gage R&R will suffice. For more details see "MSAValidity" in Chapter 7, "Tools." |
This whole topic can be grouped under one tool called Setup Reduction or otherwise know as Rapid Changeover or Single Minute Exchange of Dies (SMED)[10]. Most processes have several different types of setup or changeover depending on the entities being run pre- and post-changeover. These will vary in complexity and frequency. The best way to start is to select the most frequent and most complex changeover. Often this is the superset of all activities that make up other changeovers (i.e., the worst-case scenario that involves all aspects of a change). [10] See A Revolution in Manufacturing: The SMED System by Shigeo Shingo (Productivity Press, ISBN: 0915299038).
|  | Take a baseline measure of changeover time for the chosen changeover. This might be calculable from historical data or could be tracked as a matter of course. If not, capture 10 or more data points to get a reasonable average of time. |
The roadmap to reduce the time is then as follows (see also "Rapid Changeover (SMED)" in Chapter 7 for more detail): |  | A full 5S will be conducted later, but it is useful to quickly take a baseline at this point. | |  | Identify all the roles involved in the changeover and video each role (multiple video recorders are required here) from the identified start of the changeover to its end. | |  | Taking each video in turn (or preferably in parallel using subteams), identify the activities and steps for each role. Lay them out on a Swimlane Map. Timings should be included from the video for all steps. | |  | From the videos, construct a Spaghetti Map showing movement for all roles and other key entities (material, supplies, information, Primary Entity, etc.). Calculate the travel distances for each of the roles. | |  | Use the internal/external analysis from the Setup reduction tool to identify which activities should be eliminated (as NVA) and which could be done pre- or post-setup. | |  | The vast majority of time reduction will come from better organization and layout. A 5S undertaking in the area will ensure that the workstations make sense and the materials and supplies are stored close to point of use (POU). | |  | After the changeover is stripped to its bare minimum, structure the remaining tasks into a sensible order, taking into account skills of roles (does an activity require a "license" to do it?). Critical Path Analysis helps reduce the overall time by identifying the longest chain of activity. | |  | From the Critical Path Analysis/Swimlane Map, construct role checklist for the changeover and move to implement the new structure. Test out the new method and tweak as necessary. | |  | Remeasure the process using the 5S measurement tool. |
After the changeover looks reasonable (the tendency is usually to try and "over-think" it), move to the Control tools in Chapter 5. The preceding work represents improvement to only one changeover type, but hopefully encompasses learning that could be implemented across the board. Create a rollout plan and Teams to take the approach to other changeovers by order of volume and complexity. |
