Control limits

Hi,
Wondering if it’s helpful to use control limits on operations metrics like customer complaints, supplier DPPM, on time deliver for a start up company - simple responses would be greatly appreciated . Thanks

Yes. (Is that simple enough?)











And there is information on the COVE has to how to set up those control limits using Statistical Process Control.

In a start-up company situation, there has to be some modicum of predictability in order to have "helpful" predicted limits. The math of SPC gives us a way to judge whether a process is "in control".

Statistical Process Control limits can show expected ranges for process metrics. It is helpful to know what is expected, so to recognize and react when the process behaves unexpectedly, both in a favorable and unfavorable direction. Planning and budgeting for a stable, predictable process is far more reliable than for operations which are not in a state of statistical control.

Where your team is working to improve quantities with negative consequences, such as complaints and DPPM, it is helpful to judge whether minor month-to-month improvements are large enough for the team to take credit, or whether the minor improvements could just as likely be random month-to-month fluctuation.

Early in my career as a quality manager, we would have monthly reviews with division leadership of various plant performance metrics. These meetings would last 4-6 hours as every negative movement of an indicator would have to be explained and plans made to address each. These explanations were always smoke and mirrors because no one had any idea what had happened. My company at that time briefly had the wisdom to hire a good VP of Quality that was also the head of ASQ. He suggested that we plot all these metrics on I-MR charts and only explain when the metrics exceed the control limits. Meetings then only took 1.5-2 hours and managers actually knew why the metrics had changed and were able to come prepared with good plans to address it.

So, yes it is helpful.

Miner - I posted your comment (with attribution) to my students in Statistical Applications (ITEC 265 at Southern Illinois University at Carbondale) since they just finished a discussion topic that touched on SPC and management use (and misuse) of data.

Miner said:

Early in my career as a quality manager, we would have monthly reviews with division leadership of various plant performance metrics. These meetings would last 4-6 hours as every negative movement of an indicator would have to be explained and plans made to address each. These explanations were always smoke and mirrors because no one had any idea what had happened. My company at that time briefly had the wisdom to hire a good VP of Quality that was also the head of ASQ. He suggested that we plot all these metrics on I-MR charts and only explain when the metrics exceed the control limits. Meetings then only took 1.5-2 hours and managers actually knew why the metrics had changed and were able to come prepared with good plans to address it.

So, yes it is helpful.

Click to expand...

We had a similar approach in my previous organization.

Part of our culture was to also colour-code the metrics or data points, and our conversations focused on the "red" results. It didn't matter if the point was a "good" red or a "bad" red. Red was red and it meant outside of the control limits. With that said, our conversation on a "good" red was different than on a "bad" red. For "bad" reds, we discussed cause and course correction. For "good" reds, we discussed cause and repeatability - could the "good" red become part of the new norm and result in an adjustment to our control limits.

I like investigating good days as well as bad.

Sometimes on a good day it is easier to identify what is different. Suppose you have 40 machines all doing the same thing that affect the quality at a later process. If on a good day machines 27 and 35 are down for some reason, I would investigate if one or both of those machines is a significant contributor to quality problems. It is al lot easier to run a study on two machines than 40, especially if the later process where problems are easily detectable also has multiple machines.