Addressing barriers to scaling data: Some tips

Steve DaumLike a recipe designed for four servings that is called upon to serve 4,000, dramatically up-scaling the number of quality metrics being monitored may demand new approaches when deploying SPC. Here are some thoughts and approaches to overcoming barriers to scaling your SPC efforts.

Today, computers and software are widely used for SPC, but the basic workflow of SPC has remained the same: 1) measure something, 2) visualize it on a chart, 3) learn from and possibly react to signals that are detected. One problem with this workflow is the difficulty of scaling to the large number of metrics required in today’s competitive and sometimes highly regulated environments.

Imagine any moderately complex manufacturing production line. Think about the number of metrics that might be gathered along the line. Even in focusing only on metrics that have a direct impact on quality, the numbers can be staggering. What if there are 300, 500, or even 1,000 metrics that need to be monitored for variation? Is it realistic or practical to deploy 1,000 control charts along this hypothetical line? In most cases, even when computers and software are available, the answer will be no. It is just not practical. Who would look at these charts? How many workers could be spared to do this SPC work?

There are at least two barriers to scaling SPC to these levels: 1) the effort/cost required to setup the charts initially; and 2) the attention burden on the workers who must look at, think about, and react to these charts. To truly scale SPC charting efforts, both of these must be addressed.

The first issue clearly represents a challenge to any large organization. Setting up hundreds of charts will demand time and effort. The employees doing this work require clear training related to SPC charting, understanding variation, and analyzing charts. Knowledge of product specifications and process parameters is also important. Errors made when setting up these charts will ultimately affect the payback time for the investment in SPC charting.

The second issue, the problem of paying attention to the charts, is also difficult to address. In the production settings with which we are familiar, workers are busy. They tend not to have free time, time when they can focus their attention on a chart, engage in analytical thinking, react to it correctly, and then get back to what they were doing. To address these obstacles, consider the following:

  1. First of all, whenever possible, your data collection efforts should be automated. When your production line is running, product should be being measured and tested and these results should be flowing into databases. With today’s modern production machines, this is often possible without operator intervention. When manual measurement or testing is required, the sampling rates should be set based on the potential cost of failures. Additionally, the manual measurement and testing workflow should be well integrated into some worker’s natural workflow. These manually gathered results should flow directly into a database rather than onto paper and later put into the database.
  2. Once data from your process is flowing into a database, software-based control charts of the key metrics should be defined. The employees doing this work need to be familiar with SPC concepts, including control limits, out-of-control testing, and chart type selection. Ideally, the charts should be defined so that each time a viewer sees it, it will be showing a reasonable amount of the most recent, most relevant data – and no further chart configuration is needed. The goal for these charts should be “define them once, view them often.”
  3. Defining these charts can be time consuming. Think about this workflow and ways to make it more efficient. For example, have “template charts” pre-defined. When a new chart is needed, rather than starting from scratch, use a template, give it a new name, and change only the settings that are different. Creating and using meaningful naming conventions is important. Since the number of charts can be large, good naming conventions can reduce the cognitive burden on employees who commonly look for and view the charts.
  4. Next; what about looking at all these charts? Here is where new technology and new thinking about the SPC charting workflow might really improve the scalability of SPC.

What is the reason for looking at a control chart? To see a signal. By the time a control chart is set up, you really should not expect to see too many signals. The limits were established when the process was running in a predictable, in-control, state.

What we propose is that operators see control charts only when a signal is detected, preferably by software. There might be several hundred control charts defined. However, the appropriate operator is shown a control chart only when a signal is detected by some other agent. The agent in this case is the SPC software. While operators go about their work, the software is patiently watching data flow into the database, applying SPC thinking to this data, then raising a signal for operator intervention only when needed.

There are very real challenges when scaling SPC charting efforts. However, if we are willing to change our paradigm and think carefully about the workflows, these challenges can be overcome and large scale SPC charting efforts can pay for themselves by reducing scrap and variation.

PQ Systems, Inc. has been thinking about SPC and how it is deployed in the real world for more than 25 years. Software that includes CHARTrunner Lean and SQCpack are designed to overcome barriers to understanding large amounts of data.