Chapter 10. Probability

What you will learn in this chapter of the book is to let data drive problem solving. However, to interpret data, you need to make a judgment as to whether unusual results were due to random cause, like someone who flips a coin and gets an excessive number of heads by chance, or due to an assignable cause, like the coin having two heads. A knowledge of probability helps you make this determination with a minimum number of samples.

Much Six Sigma work can't be done without some understanding of probability statistics. Probability can be used in all the steps of DMAIC. You will be able to use these techniques to solve many problems in the work-place without using additional tools.

NOTE

Probability

Manufacturing On any production line with multiple heads, compare defect levels from each head to see if they are significantly different. Compare two or more similar production lines, shifts, defects on different days of the week, etc. Often you will see significant differences that can be addressed at little cost.

Sales Compare salespeople. The criteria could include new customers, lost sales, etc. Cross training between the best and worst performers can often improve both! Also, through these careful comparisons, compensation can be made more equitable.

Marketing Check if sales increased significantly in multiple markets after a marketing campaign.

Accounting and Software Development Compare error incidence to check for significant difference between groups.

Receivables Check the effect of increased or decreased monitoring of overdue receivables.

Insurance Compare the complaints at similar-sized treatment centers. The criteria could include patient care, billing errors, etc.

Case Study: Application of Simple Probability

Aproduction plant was in trouble. They were getting multiple defects in their product going out from every production line. They felt it was caused by a problem with the incoming raw material. They had given up on making good product and gave a panicked call for help to their home-office engineering group. A task force was assembled and began attacking the problems.

One of the first things an engineer did was collect defects from one line. He quickly concluded that one of the defects was coming from one set of tooling. (There were 20 tooling sets per line.) He had the tooling set taken out of production and found it had been assembled wrong. On looking at maintenance records on the machine, he found that the tooling set had been on the machine for two weeks. Since there were 20 tooling sets on the line, 5% of the product coming from the machine for two weeks was defective, since every product coming from this set of tooling was bad.

The engineer knew that raw materials would not cause this 100% defect on only one set of tooling without also affecting products off the other tooling sets. This is what triggered him to have the tooling set removed and inspected. Using this kind of systematic analysis of defect data and reacting accordingly, the plant was back to normal productivity within three days. There had been no problem with the raw materials.

Certainly this reasoning took only a rudimentary knowledge of probability, but no one in the plant, including the plant engineers, was analyzing the problem in this way. They just assumed that, since they were having multiple problems throughout the plant, that the issue must be raw materials.

At the end of the third day, the task force received a call from their general manager who wanted an update on how the team was doing. When the team leader told the GM that the plant was now back to targeted production using the very basic analysis described, the GM did not initially believe it! It just seemed too simple. The task force went home.

By the beginning of the following week, the plant yields had again slipped dramatically. This time only one of the task force engineers returned and, with the same methods, was again able to get the plant back to targeted production within three days.

The net effect of all this was that the plant manager at the plant was taken out of his job and the plant began to pay more attention to the required detail of running production.


The above case study is typical in that the initial conclusion that the problem was caused by the raw materials was made without carefully analyzing data. In contrast, the engineer used specific data and an elementary knowledge of probability to reach his conclusions, since he knew that defects caused by raw materials would have been random and not specific to one of the sets of tools on a line. Although the other production lines did not have the identical problems, the same kind of careful analysis based on detailed data resolved the production problems.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.217.214.141