Section 1. A Single Process Step Does Not Meet Takt

1. A Single Process Step Does Not Meet Takt

Overview^[1]

^[1] Before reading this chapter it is important to read and understand Chapter 1, "Introduction," particularly the section, "How to Use This Book."

Processes are required to cycle at a rate fast enough to generate entities at a pace to meet customer (or market) demand. Takt Time represents the pace of customer (or market) demand. If the Cycle Time (the actual rate of processing entities) of the process is longer than the Takt Time, then the process isn't cycling quickly enough and inevitably falls behind. For more details see "TimeTakt Time" and "TimeGlobal Process Cycle Time" in Chapter 7, "Tools."

This category infers that some work has been done to relate the Takt Time to the Cycle Time, usually a Load Chart, and also to identify that this single process step is not meeting Takt. If this is not the case, then return to Chapter 3, "Global Process Problems," to select the Problem Category for the process as a whole.

Measuring Performance

The measure used should have been put in place at the Global Problem Category level, but if not, then use the Process Cycle Time as the metric with the goal of being below the Takt Time.

Tool Approach

If this hasn't already been done at a previous step, then:

	The focus is on measuring validity (a sound operational definition and consistent measure) of Cycle Time versus a detailed investigation of Gage R&R. See "TimeGlobal Process Cycle Time" and "MSAContinuous" in Chapter 7, for more detail.
	If we were interested in just the average Cycle Time, then a data collection of 10 to 15 points would suffice. However, it is often the case that variability in the Cycle Time is more of a problem, and in that case, it is best to capture 25 to 30 data points at minimum for the baseline. For more details see "CapabilityContinuous" in Chapter 7.
	If the data in the Capability Study shows too high a level of variability then it is useful to visit the roadmap in Section 3 of this chapter; however, there are some simple improvements that can be made first. Continue in this roadmap below and return to Section 3 later if needed.

This roadmap is to quickly identify using Overall Equipment Effectiveness (OEE), whether the issue is with quality related problems, the uptime of the process, or the speed of the process when it is running.

The process would hit minimum Cycle Time if it never went down, did only VA activity, as fast as it has ever run, and generated only perfect quality entities.

From the OEE, we gain an understanding of whether the issue is

	This is a quality-related problem. Cycle Time is effectively increased because the process step spends time generating defective entities. Continue to Section C in Chapter 3 and follow the roadmap focusing on this single process step.
	The Cycle Time is extended because the process is spending part of its available time to do VA entity generation doing something else. Continue to Section D in Chapter 3 and follow the roadmap focusing on this single process step.
	The Cycle Time is extended because the process could do the VA piece of the work more rapidly. Continue to Section 2 in this chapter.

It is highly likely that the problem is resolved at this time. To confirm this:

	Capture 25 to 30 data points for Cycle Time to understand the new mean, but also the variability in Cycle Time.
	If the data in the Capability Study still shows too high a level of variability then go to Section 3 of this chapter.

At this point, the Cycle Time of the step should be consistently below Takt, in which case proceed to the Control tools in Chapter 5, "ControlTools Used at the End of All Projects."

If the Cycle Time is still above Takt, look at the process as a whole (versus this single step) and ask

• Why are we doing this?

• Is there any other way to do this?

• Does it make more sense to offload work from this step to other adjacent steps?

• Is it better to add more resources to accelerate the step?

• Is it better to split the step into two or more steps?

• Is there a simple changing of technology or approach to the whole process that would help?

At this point, if the path to improving this process is still not clear, then it might be time to consider designing an entirely new process. A useful methodology at this time would be Six Sigma Process Design.^[2]

^[2] Six Sigma Process Design (SSPD) is a more recent newcomer to the Lean Sigma world. At the time of writing this, there are no known references for this. See www.sbtionline.com for more details.