Statistical Thinking to Improve Quality

The Cause and Effect Diagram graphically portrays the potential causes of an effect.   The causes are grouped into categories.   Common categories are manpower (personnel), materials, methods and machines.   When the diagram uses these specific categories we might call the diagram a 4M diagram.  Depending on the effect, the diagram might display other categories.   The diagram is also known as an Ishikawa diagram since Dr. Ishikawa devised its first use of the diagram.   Another name for the diagram is a Fishbone diagram because of its appearance.   Recording the results of a brainstorming session is a typical use for the diagram.   A project might use a brainstorming session to generate a list of potential causes of an effect or a quality problem.  

We will continue the case study reported by Gijo (2005) to illustrate the Cause and Effect diagram.   The previous post presented a Pareto chart for a machine shop showing that the grinding operations generated most of the rejections experienced by the shop. They estimated grinding machine capability based on a sample of 40 parts.   The estimated P_pk for this sample was .49.  This result verified the lack of grinding machine capability. 

Selected individuals participated in a brainstorming session to generate a set of potential causes of grinding machine rejections.    The following figure shows the resulting causes. 

After further study, project members selected four factors for further analysis based on designed experiments.   These factors were Feed Rate, Wheel Speed, Work Speed, and Wheel Grade.   Analysis of the experimental results identified “optimum” levels for the four factors.  The estimated P_pk  at the optimum factor levels was 1.25 based on a sample of 40 parts.   This showed significant improvement.

References

1. Gijo, E. V. (2005). "Improving Process Capability of Manufacturing Process by Application of Statistical Techniques." Quality Engineering 17(2): 309-315.

Posted by Gordon M. Clark at 08:20 PM | Permalink | Comments (1)

We use Pareto Charts to rank problems or causes with respect to their frequency of occurrence.  The charts highlight those causes which result in the most quality problems.  

Pareto charts get their name from Vilfredo Pareto (1848 – 1923) who was an economist.   He analyzed and studied the unequal distribution of wealth.   Dr. Juran in the 1940s stated a principle of the “vital few” and the “trivial many” (see Juran and Godfrey (1999)).   That is, in many situations a few problem categories (about 20%) will produce the most problems (about 80%).  Juran called this principle “Pareto’s principle of unequal distribution.”

We illustrate the application of Pareto Charts using a case study taken from Gijo (2005).  A company was experiencing a high rejection rate in one of its machining shops.   They did not know the root causes of these rejections nor how to reduce their occurrence.   They started by examining existing records, and they classified the defects by the individual operations causing the defect.   The analysis of data by this classification is called stratification.   Using the results, they constructed a Pareto chart. The following figure presents the chart.  

The chart shows that 60% of the rejections were due to grinding problems.   Based on the Pareto Chart they started a study improve grinding operations.   This study resulted in designed experiments to determine improved grinding operating procedures.   The resulting analyses lead to operating procedures that significantly reducing rejections and rework due to grinding operations.  

References

1. Juran, J. M. and A. B. Godfrey (1999). Juran’s Quality Handbook, 5^th Edition, New York, McGraw-Hill.
2. Gijo, E. V. (2005). "Improving Process Capability of Manufacturing Process by Application of Statistical Techniques." Quality Engineering 17(2): 309-315.
   

Posted by Gordon M. Clark at 09:48 PM | Permalink | Comments (0)

This post illustrates the Statistical Thinking tool, the flowchart or process map, using an example taken from the author’s consulting experience.   A flowchart of a process is sometimes referred to as a process map.   A manufacturer produced automotive door frames, depicted in the following figure.   The door frame consists of four parts which were joined by a welding operation.  The shape and finished product dimensions were important quality characteristics of the finished product.  However, they had a problem meeting dimensional specifications on the assembled final product.   As a result they did considerable rework to insure satisfactory quality for the finished product.  

The manufacturer formed a team to recommend corrective action to reduce rework costs and the time to meet shipment schedules.   Shop floor personnel thought that variations in incoming raw material caused the quality problems.   An analysis showed that the header was the primary quality problem.

The following figure gives the flowchart or process map for producing a header.  The roll mill takes sheet metal, cuts the input material to the proper length, forms the two parts for a header, and spot welds them together.   The bender bends the header to the proper shape punches two holes which will be used to position the part in subsequent operations.   The saw forms the proper angles at the two ends of the header.    The data on the flow chart below each operation specify important quality characteristics.   The symbols h₁, h₂, g, D1, D2, D3 and SC 4 through SC20 specify dimensions.

The manufacturer collected data for the team for relating the quality characteristics on the flowchart to finished part dimensions.   Collecting and analyzing data for individual steps in the flowchart is an example of disaggregation.  A regression analysis resulted in the following conclusions:

1. Variation in material characteristics has little effect on quality characteristics.
2. D1, D2 and D3 have considerable variation and affect finished product quality
3. The left and right headers have significantly different variation for D2 and D3.

The above conclusions motivated corrective action, and the manufacturer eliminated the need for rework.    This example reinforces the conclusion that data-driven decision making gives Statistical Thinking a significant advantage over expert opinion.

Posted by Gordon M. Clark at 10:02 PM | Permalink | Comments (0)

This post starts a series of posts to present the use of Statistical Thinking Tools in applying Statistical Thinking.   The Statistical Thinking Tool illustrated by this example is a flowchart.   We can have flowcharts for processes having service time objectives as well as processes processes producing a physical product.  Jeffries and Sells (2004) present this example and describe the use of “statistical tools” to meet company service time objectives.   We regard their use of statistical tools as an application of Statistical Thinking.

A Midwest manufacturing firm processes orders for its 6 manufacturing plants and 12 warehouses.   Originally, each plant and warehouse had its own order processing service staffed by a total of 36 customer service representatives.  To improve customer service and reduce costs, the company president directed a team to develop a centralized customer service center located at corporate headquarters.   The president made this decision after the team surveyed customers and found that they were adamant that they did not want to wait for a customer service representative to answer a phone call and they were not very interested in personalized service provided by a plant or warehouse representative.

The team established a goal where 95% of incoming calls would wait less than 2 minutes for a customer service representative.   The team acquired an Automatic Call Distribution (ACD) system to route customer calls to customer service representatives.  The call center would operate from 7:00 am to 7:30 pm Central Time.   The following figure gives a flowchart specifying the process of answering incoming customer calls.

The team collected data giving the distributions of incoming calls by time of day and the service times of the customer service representatives to answer the calls.  Recording and analyzing data for individual steps in the process flow chart is an example of disaggregation.   Classifying and analyzing data by a factor such as time of the day is an example of stratification.

The customer service center staffing levels by hour of the day is a crucial system design parameter.   Wait times will be long without adequate staff.  On two occasions in the past two months, I have had to wait more than an hour for technical service support personnel to answer my calls.   I know that this happens because the companies involved have allocated inadequate staffing to handle the incoming calls.

The team developed staffing levels throughout the day using a simulation of the process represented by the figure above.   Constructing a simulation requires a flowchart.  Refer to Jeffries and Sells (2004) for additional details.

The next post will illustrate the use of a flowchart for a process producing a physical product.

References

1. Jeffries, R. D. and P. R. Sells (2004). Managing Customer Service Using Statistical Tools: A Case Study. Annual Quality Congress Proceedings.
   

Posted by Gordon M. Clark at 09:32 PM | Permalink | Comments (0)

The previous post described Part A of the Distribution Center On-Time Delivery Example.   It illustrated Off-Target and Common-Cause Variation.   This part of the example illustrates Special-Cause and Structural variation.   The control chart in Figure 2 of Part A shows a Lower Control Limit (LCL) of about 88% on-time deliveries. This means that Common-Cause variation would rarely result in a weekly on-time delivery percentage lower than 88%.

Shawn formed a team to study the process and improve it.   While monitoring the process the weekly on-time delivery percentage fell to 73%.  Something had happened to increase the variation.   Figure 3 shows this drop in on-time delivery performance.  The team reviewed the distribution center activities and found that a division supplying the distribution center announced a price increase.   Customers responded by submitting additional orders to avoid the price increase.   This one-time increase in volume caused the distribution center to fall behind in filling orders because it was unprepared to handle the additional work.   Also, this one-time increase in volume is an example of Special-Cause variation.

Figure 3

The team responded by developing an improvement policy.   They determined that one could predict the weekly work load given the state of orders on Wednesday.   The improvement policy provided for overtime hours based on the orders received and remaining work on Wednesday.    Figure 4 shows the result.   The average on-time percentage rose to 98.5%.   The new LCL became 97%.   However, subsequent results  showed two weeks, Special-Cause weeks, where the volume was so heavy even the improvement policy could not handle the heavy demand.   These were end-of-quarter weeks.  Figure 4 shows them as weeks 39 and 52.

Figure 4

These end-of-quarter weeks shown in Figure 4 are examples of Structural variation.   Structural variation is a blend of common and predictable special causes.   Structural variation is due to causes that operate as an inherent part of the system as common causes do.   However, on a control chart, they appear to be due to special causes.  But their occurrence is predictable.

The four types of variation defined by Britz, Emerling et al (2000, p. 34) are:

·        Off-Target variation occurs when the process average is not equal to its target value.

·        Common-Cause variation is the variation exhibited by the process while operating in its best manner.

·        Special-Cause variation results from the intervention of causes that are unplanned and undesirable.

·        Structural variation is variation inherent in the system but appears to be due to special causes on a control chart.   However, the causes of Structural variation are predictable.

References
1.     Britz, G. C., D. W. Emerling, et al. (2000). Improving Performance Through Statistical Thinking. Milwaukee, WI, ASQ Quality Press.

Posted by Gordon M. Clark at 08:51 PM | Permalink | Comments (0)

The Customer-Complaint-Process Example illustrated two types of variation, i.e., special and common cause.   The example, taken from Britz, Emerling, et (2000, p. 29), in this post illustrates four types of variation, i.e.,

·        Off-target

·        Common Cause

·        Special Cause

Off-target variation occurs when the process average does not meet the organization’s desired target.  Structural variation occurs when causes occur in a predictable manner.    For example, the waiting line for a table at a restaurant might be longer on Saturday evenings than on other days.

Distribution Center On-Time Delivery Example

Shawn was perplexed when she examined Figure 1 showing a plot of weekly on-time deliver percentages at her distribution center.  The corporation’s goal was to deliver 97.5% of orders each week in a timely manner.  During the past quarter, the center had only met that goal twice.   In addition, a review to the center’s activities during the two satisfactory weeks did not reveal any unusual behavior.

The overall average of weekly on-time delivery percentages was 94% which was significantly below the corporate goal of 97.5%.    The average of weekly on-time percentages must be greater than 97.5% in order for the center to consistently meet its goal of 97.5%.   If the average of all weekly on-time delivery percentages exactly equaled 97.5% then about half of the weeks would have on-time delivery percentages less than the goal of 97.5%.   Assume that a target of 99% on-time deliveries would permit the center to consistently meet the goal of 97.5% for each week.   This gap between the target (99%) and the weekly averages of 94% is Off-target variation.

Figure 1

Figure 2 suggests that the variation in on-time delivery percentages is due to common-cause variation.   One reason is that all of the plotted points are less than the Upper Control Limit (UCL) and greater than the Lower Control Limit (LCL).   Factors contributing to Common-Cause Variation are:

·        Number and complexity of orders in each week

·        Truck schedules

·        Personnel availability

The conclusion is that an analysis of the actions during the two weeks where the center met the goal of 97.5% would be an inefficient approach to improving the system.   Analyzing all of the weeks where the same common-causes are active would be more effective in identifying process improvements.

The next post will illustrate special-cause and structural variation.

Figure 2

1.     Britz, G. C., D. W. Emerling, et al. (2000). Improving Performance Through Statistical Thinking. Milwaukee, WI, ASQ Quality Press.

Posted by Gordon M. Clark at 09:13 PM | Permalink | Comments (0)

Statistical Thinking gives a framework for learning and action to improve performance.  We initiate the application of Statistical Thinking by identifying, documenting and defining the business process.  The Monthly-Billing-Process Example began by flowcharting and defining the billing process.   The team in the Customer-Complaint Process recognized that the process included raw material suppliers, the OEM manufacturer, and their customers.   Statistical Thinking recognizes that reducing variation is the key to success.  Often reducing variation involves recognizing the different types of variation.   The team in the Customer-Complaint-Process Example recognized the difference between special-cause and common-cause variation.

Usually Statistical Thinking requires the collection and analysis of data to estimate and reduce variation.  Statistical Thinking is data-driven decision making.   However, we need to define the overall process including its customer before collecting and analyzing data.   Also, the process definition includes available subject matter knowledge.   In the Monthly-Billing-Process Example, the process definition created knowledge concerning the process that did not exist without the flowcharts.   In the Customer-Complaint-Process example, the team recognized that it had to collect usage rates in order to estimate variation and identify special-cause outcome.  This process definition allows us to collect the appropriate data and focus our analysis.

Britz, Emerling, et al (2000, p26) point out two key advantages of Statistical Thinking and data-driven decision making.

1. Managers react to the last outcome.   If it is satisfactory, everyone is pleased and satisfied that the system is performing well.   If it is unsatisfactory, the implication is that something needs correction.   Results from common-causes are treated as resulting from special causes.  The analysis to reduce common-cause variation is much more effective if results from multiple outcomes are used.  Trying to find a special cause when one does not exist leads to frustration.
2. The lack of data makes everyone an expert.   Individual opinions vary and conflict with each other.

The figure depicts the relationship among Statistical Thinking, data and statistical methods.   Effective application of statistical methods occurs after performing Statistical Thinking.   In the Customer Complaint Process Example, a control chart and designed experiments occur after Statistical Thinking.   Lynne Hare points out in the reference by Britz, Emerling, et al (2000, p27) that he was successful in getting increased use of statistical tools only after explaining Statistical Thinking to managers.   They would not permit employees to use tools when they did not understand their purpose.

1. Britz, G. C., D. W. Emerling, et al. (2000). Improving Performance Through Statistical Thinking. Milwaukee, WI, ASQ Quality Press.
   

Posted by Gordon M. Clark at 09:27 PM | Permalink | Comments (1)

The previous blog post describes an application of Statistical Thinking to increase customer satisfaction by examining the processes starting with the raw material supplier and ending with the customer use of the product.   This example illustrates important features of Statistical Thinking described by Britz, Emerling et al (2000).   These features include:

1. Reducing variation improves performance.   The team had training in Statistical Thinking so they understood the various types of variation.   One type is common-cause variation which is always present.   Another type is special-cause variation which is due to isolated events.   One way to reduce overall variation is to identify outcomes that have a significant special-cause variation component.  For those outcomes, we can analyze the circumstances causing the increased variation.    To reduce common-cause variation, we need to analyze the all outcomes not affected by special causes.   The team knew this so they collected data to help them identify outcomes due to special causes.    A control chart which is a statistical method is a common approach for identifying outcomes affected by special causes.
2. The team had management support.   An understanding of Statistical Thinking facilitates management support.   Management had to support the tactic of going to the customer and convincing them to collect usage data so the team could estimate defect rates.   The team explained the concepts of Statistical Thinking to the customer to gain their support.   Note that management and the customer did not have to have a detailed understanding of the statistical methods.  When the team discovered that the importance of raw material, they had to convince management to support designed experiments to reduce common-cause variation.   My experience is that management can be very reluctant to approve designed experiments unless they appreciate the principles of Statistical Thinking.
3. Reducing variation is often a sequential process.   The team went after special-cause variation and then discovered a potential contributor to common-cause variation.

References

1. Britz, G. C., D. W. Emerling, et al. (2000). Improving Performance Through Statistical Thinking. Milwaukee, WI, ASQ Quality Press.
   

Posted by Gordon M. Clark at 04:56 PM | Permalink | Comments (0)