When companies contact us for an SPC (Statistical Process Control) solution, we first start with a requirements document. This requirements phase interviews and takes into account the SPC needs of the different intended users of the system. These needs and the capabilities of the system can vary quite a bit. If you’re considering implementing an SPC solution, it’s a good idea to map out everyone’s needs and expectations first. Some examples of different test data management stakeholders and their SPC needs as we’ve seen them are below:
  • Test Engineering: Typically, the TE group will need control charts characterized to verify the performance and accuracy of test equipment. Typically, these charts will be pre-configured and available on a weekly or on-demand basis.
  • Operations: Control charts characterized by both users and meta data to verify the performance of operators, stations, and components across multiple stages. These stages include final assembly of a finished product, subassembly steps, repair steps, etc. Typically, they’ll want to see easy-to-digest high level reports that are available on a weekly basis.
  • Quality: Real Time SPC using WECO rules to operators to identify and fix emergent issues before they cause line shutdown issues.  This includes true real-time alerts integrated with Paperless Forms, and email alerts to management that are triggering off of data immediately. For accurate WECO rules, they’ll need a large enough sample size of data for each measurement to define what the standard deviations should be. A secondary need is having the same kind of control charts as the Operations group.
  • Supplier Quality: Real-time SPC using histograms to alert Suppliers and OEM supplier managers to performance characteristics trending out of control. This includes true real-time alerts needed via email.
Another question to ask your internal users is what kind SPC quality methodology is needed. Most stakeholders will say they need Cpk in order to determine how close they are to their specification limits. Ppk usually isn’t what they initially request. However, it’s important to understand that legacy data defines the availability of Cpk vs Ppk (there’s already a stable process where we can calculate Cpk, and we are bringing the data of that process into the system). Most of the time, it makes more sense to start off with Ppk, and transition to Cpk once the process is well defined. So, to summarize, when your stakeholders say they need SPC, make sure you understand what they mean by SPC and how they’ll be applying SPC rules. Ppk and Cpk are both applicable, depending on your use case.