as process control is about measuring variation, detecting abnormal variation, and then reacting to it. In this session, we talk about Toyota Production System and how it deals with quality. We will introduce a detect, stop, alert framework and we will introduce two new terms to your Japanese vocabulary Jidoka and Tiamenco. Catching defects quickly is critical. There are at least two reasons for that. First, we'll see that defects often lead to further defects. Especially if there's a lot of inventory in the process. Second, if we have a defect in the process, it's critical that we catch it before it moves to the bottleneck. Because otherwise, the scarce bottleneck capacity is wasted on the defect. Now, let's look first at the role of one defect, and its impact on further defects. Here are two processes. The first one has the big inventory between the two steps then make up the process. Assume that every obvious activity shown in either of the processes has a one minute processing time. Now you may have to visit at some point the operator who is making the first step here in the process, starts making defects. So the operator has, at that moment, and starts making defects. How long will it take until somebody, in this case our second operator, will catch that defect? Well, by Little's Law, we know that there are many other units in inventory before this unit finally reaches the next step. This gives the second operator no way of giving feedback to the first operator. The feedback loop is broken by inventory. We speak about the process having a long information turn around time. Long information turn around time, delayed feedback keeps us from improving. In the second example of the process being lean and the inventory between the steps relatively low, you notice that after two cycles at the latest, the second operator will get the defective part and can trigger an alert. Again, this triggers process improvement action, and, the process becomes better. Now that we understand how defects impact the bottleneck calculations. Let us understand some of the economics of defects. What are the costs of making a defect? Consider the following example. In a restaurant I'm saucing pasta from the market. I have somebody that brings the pasta from the market and puts it in to the kitchen. That's the preparation stem. I then have a busy and famous chef who is preparing the meal. Finally, somebody puts a meal on a plate and brings it to the customer. We're charging twenty dollars for each meal and so I'm enjoying quite a significant markup. Now, what is the cost of making a defect in this process. Is it driven by the two dollars per meal, that costs us to source the pasta or is it driven by the twenty dollars that we can make by selling the pasta. The answer to this question will depend on where the defect happens or, more accurately, where the defect is identified. If the defect happens here, as we come back from the market and we're dropping some pasta on the floor, all we have to do. Is buy another round of pasta. So as long as the defect happens before the bottleneck, it just costs us $two. If, however, the chef has already spent all the time. Preparing the meal and the defect happens as we're serving the food to the customer, so say the server is dropping the pasta on the floor. We have to go back to our scarce resource and go back to the bottleneck. Since the bottleneck is a constraint on the process, we really have to charge a $twenty to this type of defect. So you notice how defects that are happening before the bottleneck are really just driven by the input prices. Defects that are happening after the bottleneck, however, need to be valued at the cost or, more strictly speaking, the opportunity cost of a unit of sales. Notice, in this example, that the crucial question is not where the defect occurred, but where the defect was identified. If we buy bad pasta, and we have the bottle and spent time, time in preparing the meal, and we catch the defect only after the bottleneck. It didn't matter that the defect occurred before the bottleneck, but it mattered that the bottleneck spent time on it. This drives the location of test points in the process. It's important that we test flow units as much as we can before we put them into the bottleneck. So detecting defects quickly is critical. Be it because of learning, or because you want to avoid wasting capacity. We've already seen how control charts can help us catch abnormal deviations of the process and then trigger some sort of an alert. The Toyota production system has produced a similar idea. That's the idea of Jidoka. Jidoka Doka is about alerting an operator or management that there's a problem in the process. That means that the process has to be able to detect there is a problem in the first step. This comes from the day when Toyota was actually still building automated looms. Before their auto days, Toyota was a loom company and when a loom is out of control, it's a disaster. You want to cut it down as quickly as possible. So the looms, Toyota figured out, should be able to self-detect if they have a problem. Detect, alert and then finally stop. Nowadays, Toyota is no mo-, longer making looms. It's an automotive company, with a long assembled line. And jidoka was introducing the assembly line in the form of the NM cord. The NM cord is a long rope that run, runs adjacent to the assembly line at Toyota. And, it allows each operator along the line to pull the cord and, thereby, stops the line. When an operator recognizes a problem, they pull the cord and stops the line. It's just an assembly worker version of jidoka. If you compare the Toyota Production System approach to quality and the approach that the six sigma philosophy has, you will notice some similarity. Let's go back to jidoka first. The idea of jidoka works, detect, stop and alert. Now, what do you do once you have alerted the operators? The operators engage in root-cause problem-solving. We'll talk about this in the next session and introduce the tools, Ishikawa and kaizen. Both of them are tools that help workers solve problems and investigate into root causes. The outcome of that is that hopefully you can avoid the defects in the future. You start to build quality into the process, and use Poka Yoke as a way of fool proofing your operations. That gets you to a higher level of knowledge and the cycle begins all over. Now the process is never perfect. You keep on cycling through these three stages, and get better and better. But you never get perfect. The same is true for capability analyses that analyses six sigma production system. You're looping through the cycle of measuring the current capability. You're looking for ways of driving down variation, improving the process, measuring again, and so on. The process is never perfect. You go from three sigma to four sigma, until the parts that you have defective are measured in the numbers of one part per billion. Detect, stop, alert. The sooner we can start searching for the root cause of a defect, the more likely are we able to get to this root cause. Compare this with a crime scene investigation. If you tried to solve the murder case that happened five or ten years ago, it's much harder compared to a murder case where you're on the crime scene. You start your investigation one or two seconds after the murder occurred. This is the basic idea of Jidoka to detect, stop, and alert. One way of implementing Jidoka was the NM chord. The NM chord allows workers on the line to stop the process, thereby sacrificing flow at the benefit of quality.