Process Improvement: Using The Control Chart
/The outcomes of many business processes are hardly stable. Often, they vary either by design or due to various special causes of variation. Some variation is harmless and is to be expected, but other kinds of variation can have disastrous consequences and must be avoided or corrected at all costs. When it comes to the processes for which it is important to notice the causes of variation as soon as they occur, a statistical process control tool called the control chart can be used.
The Shewhart chart, as the control chart is sometimes called, after Walter A. Shewhart (an American physicist also referred to as the father of statistical quality control) is the primary Statistical Process Control (SPC) tool for Six Sigma.
A control chart can be used to monitor processes for problems and to determine whether a process has become stable enough. As an analysis tool, it can be used to detect when problems occur and propose possible causes and solutions via an extensive root cause analysis exercise.
A closer look at the control chart
The control chart graphically tracks a process input or an output over time. “The tracked measurements are visually compared decision limits calculated from probabilities of the actual process performance,” explain Craig Gygi and Bruce Williams in Six Sigma for Dummies. Each control chart has the following basic components:
- Centerline: The centerline for the data is the sum of the data divided by the number of data points.
- Upper Control Limit (also known as UCL): Typically, this is three process standard deviations above the centerline.
- Lower Control Limit (also known as LCL): Typically, this is three process standard deviations below the centerline.
The reason why the control limits are commonly drawn at three process standard deviations away from the centerline is because that’s a good balance between alpha errors, which occur when a point falls outside the control limits even though no special cause is operating, and beta errors, which occur when a special cause is missed because the chart isn't sufficiently sensitive to detect it. Under normal circumstances, data points fall within the three process standard deviations 99.7 percent of the time a process is in control.
As a guide to spotting special factors that cause variation, we can use several tests:
- When 1 data point falls outside the two control limits, we are looking at a special cause.
- If 6 or more points in a row increase or decrease, we are looking at a special cause.
- If 8 or more points in a row are located on one side of the centerline, we are looking at a special cause.
- If 14 or more points are alternate up or down, we are looking at a special cause.
Control Charts in Practice
With control charts, it’s possible to monitor the performance of a process on an ongoing basis to better see whether changes to the process have the desired result. The trends that naturally emerge when a process is monitored on an ongoing basis help predict process capability based on various performance insights, allowing us to know when to take action and when to carry on.
A basic control chart procedure includes the following steps:
1. The choice of a suitable control chart for a data set.
2. The choice of a suitable period for data gathering and plotting.
3. Data gathering and control chart constructing.
4. Data analysis for deviations.
Practical areas of application is in manufacturing processes where there are natural variations inherent in the process and other variations that cannot easily be explained without some analysis. For example, a control chart can be used to monitor the process of producing concrete, while aiming to achieve a certain compressive strength. One cause of natural variation in this case is differences in the chemical composition of raw materials used while a special variation can be due to problems with equipment.
User story maps are an interesting and collaborative way of eliciting user requirements. One of the reasons why I find it so powerful is because it provides a unique approach for aligning discussions relating to the user, their goals, the process that supports the accomplishment of their predefined goals; and the requirements that need to be addressed to solve business problems.