Control charts

Control charts

10.1 Purpose

Information systems contain interrelated processes. Control charts are proactive management tools that can be used to help control, predict, and improve the processes found in information systems as well as processes in general. A control chart allows an analyst to categorize a process as either stable or unstable. The output from a stable process is predictable and consistent over time, while an unstable process is chaotic and produces unpredictable output. To truly judge the capability or usefulness of a process, it must be stable, i.e., predictable. When encountering an unstable process, the process must first be brought into a stable state before assessing its usefulness to the overall system. Control charts are also useful in monitoring stable processes and notifying the analyst if and when a given process moves to an unstable state.

10.2 Strengths, weaknesses, and limitations

Control charts have been proven effective in a wide range of diverse applications. Wherever business activity can be characterized as a process, control charts can be applied to monitor, predict, and ultimately help improve the output from those processes. The managerial implications associated with control charts are enormous. Perhaps the most important is that it allows managers to distinguish between common causes of variation and assignable causes of variation. Quality guru Deming¹ often stressed that the failure to identify and distinguish these two types of variation was the most common mistake in modern management practice.

Control charts are used to distinguish common cause variation from assignable cause variation, not to determine whether or not the output from a process meets certain specifications. In general, it is incorrect to compare a control limit from a control chart to a specification limit.

The calculation of the control limits may seem difficult and unintuitive to someone untrained in statistics. The use of a statistical package should avoid calculation problems. When an analyst is constructing control charts from a spreadsheet or graphing package that does not have control chart procedures built in, extreme care must be taken to insure that the correct formulas are used.

Effective setup and analysis of control charts requires a certain amount of statistical sophistication. Although initial training in control chart techniques may be necessary, the long-term economic benefits should greatly outweigh the short term costs of training.

10.3 Inputs and related ideas

The use of control charts is a central part of the TQM movement as espoused by Deming¹ and other quality gurus. In general, the seven tools for quality improvement (Pareto diagram, cause-and-effect diagram, control chart, process flow diagram, checksheet, scatter diagram, and histogram) serve as a complimentary tool set that has been proven to be effective in improving many systems. Errors or out of control conditions suggested by control charts are commonly used to identify possible errors during the problem definition stage (Part II) of the system development life cycle. Pareto diagrams are discussed in Chapter 11. During the operational stage (Part VIII), control charts are commonly used to support system controls (Chapter 77) and performance analysis (Chapter 78).

10.4 Concepts

A process is the transformation of inputs to outputs. Control charts are statistical tools that help analysts determine whether the output from a process is predictable or unpredictable. Control charts are also used to monitor a process to detect changes in the process and, therefore, changes in the outputs from the process. The basic philosophy behind control charting is that if the process can be controlled, then the output from the process can be controlled. Used correctly, control charts can detect changes in a process before those changes produce undesirable output.

In this chapter, we will consider the operation of a local area network (LAN) from a process perspective. A quality characteristic of the network operation is application turnaround time. To monitor this, a benchmark program will be run every hour and the time required to complete the program recorded.

10.4.1 Run charts

In this section a run chart is constructed and analyzed. A run chart plots individual observations versus the time the observations are taken. In Figure 10.1, the times required to complete a benchmark program on a LAN are plotted. The horizontal axis indicates that one observation was taken per hour. The times are recorded in microseconds, thus observation one indicates that the benchmark time for the first hour was approximately 625,000 ms. The slowest time recorded was observation 14 at approximately 670,000 ms. The figure illustrates the variability in the time to run the benchmark program. If the LAN was consistently slowing down or speeding up, a noticeable trend would have appeared on the run chart. For this example, there are no trends, but observation 14 appears to be quite a bit slower than the others. Is this slow time due to inherent variability in the design of the LAN, or is it due to an outside effect that comes and goes periodically? In other words, is it a time we should expect to see when the LAN is operating correctly, or is it an abnormally slow time? A run chart cannot answer this question.

10.4.2 Types of variation

Variation in the output of a process is owing to either common cause variation or assignable cause variation. Common cause variation is inherent to the process, e.g., it is the variation that is owing to the machines, methods, materials, and so on, that constitute the process itself. In other words, common cause variation is owing to the process design and, therefore, can affect all the outputs from the process. All processes exhibit common cause variation.

Figure 10.1  Run chart produced by Minitab for Windows.

Assignable cause variation is owing to sources outside of the process. A process experiencing assignable cause variation is operating in a fashion different than would be expected from the process design. By definition, assignable cause variation can only affect a subset of output. Possible reasons for assignable cause variation include a hardware malfunction, a power surge, or operator error.

10.4.3 Constructing a control chart

A control chart plots statistics on the vertical axis while the horizontal axis represents time, like a run chart. Unlike a run chart, a control chart also contains a centerline, a lower control limit and an upper control limit. When points are plotted within the control limits, the process is said to be stable. If points lie outside the control limits, the process is said to be unstable. See Section 10.4.4 for more details on analysis.

Figure 10.2 presents a control chart for the benchmark program example discussed earlier. The centerline for a control chart is the mean of the statistic being plotted. The mean may be a known value or it may be an estimated value of the mean. In this example, the mean of the benchmark times is assumed to be 600,000. The control limits are placed three standard deviations away from the mean. The standard deviation for the benchmark times is assumed to be 30,000; thus the control limits are drawn at 510,000 and 690,000. The reason for using three standard deviations is that most observations should lie within three standard deviations of the mean. Any points plotted outside these limits would be unusual observations.

Figure 10.2  Individuals chart produced by Minitab for Windows illustrating a stable process.

10.4.4 Analyzing a control chart

A process is said to be unstable if a point plotted on a control chart is outside the control limits. A point outside a control limit indicates that the cause of the unusually low or high number must be owing not to common cause variation, but to assignable cause variation. In Figure 10.2 all the points are contained within the control limits and the process is said to be stable. Thus, although observation 14 is higher than the other benchmark times, it is an observation that is consistent with the way that the process is currently operating. In contrast, in Figure 10.3, a point is outside the control limits and the process is said to be unstable.

Figure 10.3  Individuals chart produced by Minitab for Windows illustrating an unstable process.

If a process is stable and is producing output that is acceptable to management, then the process should be allowed to continue on its normal path. The stable process should continue to be control charted so that if at a later date it becomes unstable, the analysts will be quickly notified of the change in the process.

A stable process is not necessarily a good process, it simply means that the process is consistent, and the output is known and predictable. If the output from a stable process is unacceptable, then the process itself must be changed. In other words, the process is stable but owing to a large amount of common cause variation, the process is consistently producing output that is unacceptable. In Figure 10.2, the control chart indicates that the process is stable and, therefore, the variation in the benchmark times is consistent and predictable. If the times being observed are acceptable to the analyst, then the LAN (i.e., the process) as it is currently designed is sufficient. If the times are too slow, then a fundamental change in the LAN must occur in order for the LAN to operate at an acceptable level.

When encountering an unstable process, the analyst must determine the sources of the assignable cause variation. The reason for the assignable cause must be investigated and in most cases eliminated. The actual capability of the process cannot be determined until the process actually performs as it was designed, i.e., until all assignable cause variation is removed. In some cases, the assignable cause variation may actually improve the output and in this case the process needs to be redesigned to include the newly discovered improvement. In Figure 10.3 an unstable point is observed and, therefore, the network at time period 21 must be investigated. At this time, an assignable cause is responsible for the slow benchmark time; i.e., a root cause outside of the design process must have been affecting the output. The analyst must identify the source and then institute change that will not allow this type of output to reappear at a later time.

More sophisticated rules than the “single point outside a control limit” have been developed to help identify unstable processes. This rule, however, is the most important and is often the only one used. For a discussion of these additional rules, the reader is referred to Montgomery².

10.4.5 Types of control charts

In the above example, the statistic being plotted is an individual measurement and the control chart is known as an individuals chart. It is the simplest type of control chart. An individuals chart is appropriate when the data are collected one at a time and are distributed, or approximately distributed, as a normal random variable. Other common types of control charts are listed below.

1. C chart For use when the data appear to come from a Poisson distribution; for example, the number of network crashes in a day.

2. P chart For use with binomial data; for example, the proportion of time a network server is active.

3. X-bar and R charts For use with normal, or approximately normal, data which are collected in samples of size two or more; for example, every hour we could run a benchmark program ten times and calculate the mean, X-bar, and the range, R, for those ten measurements. In general, the X-bar and R charts are more sensitive to changes in a process than an individuals chart.

10.4.6 Rational subgrouping

The individuals control charts discussed in this chapter require the simplest sampling scheme of any control charts. As noted above, only one observation per time period is collected. In many cases, to set up a control chart repeated process samples of size two or more must be collected. For example, it is common to use samples of size four or five when using X-bar and R charts. A P chart typically requires rational subgroups of size 30 or more. Process samples taken for the purpose of constructing control charts are called rational subgroups.

A rational subgroup should be a sample collected in such a manner as to maximize the probability that the sample captures common cause variability and that any possible assignable cause variability occurs between rational subgroups. If a rational subgroup is too small, the sample will not be subject to all the common cause variability in the process. This will lead to control limits that are too narrow and may ultimately result in labeling a stable process as unstable, which is referred to as a false alarm. If a rational subgroup is too large, the sample may contain common cause and assignable cause variation. This will result in control limits that are too wide and may result in unstable processes going undetected.

10.4.7 Estimating limits

In many instances the mean and standard deviation of the statistic being plotted will not be known. The analyst must then estimate these parameters using the data contained in the chart. The reader is referred to Montgomery² for details on proper estimation procedures.

10.5 Key terms

Assignable cause variation —

Variation that is not part of the design of the process; the sources or factors producing assignable cause variation can, by definition, only affect a subset of the output from that process. Assignable cause variation is sometimes referred to as special cause variation.

Common cause variation —

Variation that is inherent to a process; common cause variation has the ability to affect all output from a process. All processes are subject to this form of variation.

Control limits —

The upper and lower boundary lines of a control chart; the control limits are typically placed three standard deviations above and below the centerline. The centerline is usually the mean of the statistic being charted.

Rational subgroup —

A sample of measurements taken from a process in such a manner that will maximize the probability that the sample captures common cause variability and that any possible assignable cause variability will occur between rational subgroups. In other words, the variation in the rational subgroup should be the result of common causes of variation only.

Stable process —

A process that only exhibits common cause variation. In other words, the output from a stable process produces a population of items which has a constant mean and a constant variance. A stable process is predictable and, therefore the output from a stable process is predictable. If a stable process is generating output that is undesirable, then the process itself must be redesigned. A stable process is sometimes called an in-control process. If a process is not stable, it is said to be unstable.

Unstable process —

A process that exhibits common cause and assignable cause variation; an unstable process is unpredictable and, therefore, the output from such processes cannot be predicted. Thus, before the true capability of a process can be determined, all assignable causes of variation must be eliminated from the process, i.e., the process must become stable. An unstable process is sometimes called an out-of-control process.

10.6 Software

Most statistical software packages have the ability to produce control charts. The control charts in this chapter were made using Minitab for Windows. In SAS, the most commonly used control charts are in the Shewhart procedure. Spreadsheet packages like Excel require add-in packages to construct the charts automatically, however, the charts can be easily constructed from any spreadsheet package assuming a book of statistical tables and formulas is available.

10.7 References

10.7.1 Citations

1.  Deming, W. E., Out of the Crisis, MIT Center for Advanced Engineering Study, Cambridge, MA, 1986, chap. 11.

2.  Montgomery, D. C., Statistical Quality Control, 3rd ed., John Wiley & Sons, Inc., New York, 1996.

10.7.2 Suggestions for additional reading

1.  Gitlow, H., Oppenheim, A., and Oppenheim, R., Quality Management: Tools and Methods for Improvement, 2nd ed., Irwin, Burr Ridge, IL, 1995, chap. 9.

2.  Ozeki, K. and Asaka, T., Handbook of Quality Tools: The Japanese Approach, Productivity Press, Cambridge, MA, 1990, chap. 12.