by Douglas C. Fair
Congratulations, you and your colleagues have made the decision to implement a statistical process control (SPC) software solution.
Now what? There are many options to choose from, and deciding which product is right may seem to be a daunting task. At first glance, nearly all SPC applications look the same. Each creates control charts, histograms, capability indexes, and other statistical analyses. Most allow data collection for shop floor usage and have some kind of management-friendly reporting features. But of the hundreds of SPC software products that are available on the market today, what makes one better or different from the others?
With that in mind, use this checklist to narrow down the long list of possible SPC vendors.
There are two main categories of statistical software that perform SPC functions: real-time SPC and post-analysis. Both products serve a niche and are not viewed as competitive. Post-analysis software is typically used on an office computer by engineers, scientists, and statisticians. They typically type or import data into a spreadsheet, then apply different statistical analyses to portions of the data. Post-analysis software is used off-line, away from the manufacturing environment, and focuses on exploratory analyses such as experimental design (DOE) techniques, multiple linear regression, ANOVA, MANOVA, and other high-end statistical studies. Operators rarely, if ever, interact with such a product.
Real-time analysis, on the other hand, is focused on data collection and analysis on the shop floor. Real-time SPC products are designed to be used by operators for collecting data at the time of manufacture and making that data instantly accessible across a corporate network. Real-time products often come preconfigured to allow communication with electronic gauges (i.e., scales, micrometers, and coordinate measurement machines). They also have a clear focus on SPC analyses such as control charts, histograms, and box-and-whisker plots.
With each new data point entered into a real-time system, quality professionals have the information necessary to make a process change or simply confirm that everything is running properly. An alerting/alarming feature is typical with real-time products so that operators and support personnel can take immediate action to adjust processes that are not performing as they should.
The remaining items in this article are focused on critical distinctions in real-time SPC software products.
Most SPC software can store its data in sophisticated relational databases. However, some SPC products don’t use the abilities afforded by a relational database. Such SPC products use a flat-file database approach, where a single part requires that a separate, unique part file/databank/data collection be created. The structure is flat in that it only houses data for a single part. Control limits, data values, and specification limits are housed within these data files.
Because most manufacturing companies produce hundreds of different part numbers that can be manufactured on a variety of processes, the total count of unique data files/databanks can be staggering. Therefore, the use of a flat-file system can be extraordinarily difficult to maintain, especially when you have a large number of parts and processes to monitor and control.
SPC software products that use a relational database design require far less maintenance and are much simpler to manage.
The easiest way to determine if the software uses a relational database is to perform a simple test. Take a common feature name (like overall length) that is shared among several part numbers. Let’s suppose that you check overall length on 100 part numbers. To match operator terminology, say that you now decide to change the name from overall length to “OAL.”
To perform this task, do you:
A) Have to go to 100 places where “overall length” was used and change the text to “OAL,” or
B) Go to a single place in the database and make the change once?
If the answer is B), then your SPC system is using a relational design, and managing it is simple: A single name change can occur once, and all previously stored data will automatically become associated with “OAL.” If you must go to every part file/databank/data repository to change the name, then it is a flat system, and it will take a great deal of time and patience to make changes.
Using a relational database design will allow you to efficiently manage all aspects of the SPC system. Issues that may be related to a flat database are:
• Administrators, engineers, and managers will need to hunt through lots of different files for part-specific data or process-specific data.
• You will need an extremely large database because flat files are inherently inefficient. They leave lots of empty holes in the database that take up room, but do not actually store any information.
• Any updates to specifications, part names, test names, or process names will require a massive search-and-replace effort among all affected files.
• Charting and analysis are limited to the data that reside in a single file. Any cross-analysis among multiple files is either not supported or requires lots of copy-and-paste routines to bring the data together.
The bottom line is that relational database design was created to make an SPC deployment easy, and also to make the administration of the system simple, fast, and efficient.
Regardless of which SPC solution you select, you will need to set up data-collection routines and create analyses. Both should be flexible. However, configuring a data-collection plan should not only be easy; it should also be flexible enough to allow data collection for many different part numbers, even if those parts have different specifications.
Developing a data-collection routine is critical to the success of your SPC solution. The result should be data-entry simplicity for operators. They should find it easy to enter data for many different part numbers without being required to browse through hundreds of part files or spreadsheets. Nor should operators be required to exit the SPC application, hunt through many menus to find what they need, and then reopen the SPC application. Instead, operators should be able to select their part number and enter data without extraneous effort.
What about an operator who is running two or more machines (i.e., processes) at the same time? The data-collection routine should be flexible enough to accommodate not just hundreds of different part numbers, but also all of the processes that the operator might be running. That is, a single data-collection routine should be flexible enough to manage data entry from any part and any process for which an operator is responsible.
Having flexible data-collection routines also benefits the SPC system administrator, making it easy to create and deploy data collection. Not only should the software be easy for operators to interact with; it must also be efficient for an administrator to set up and maintain.
To uncover the most meaningful improvement opportunities while maximizing return on investment, SPC software must incorporate flexible analysis features. Although beneficial for shop floor use, a control chart only helps to control one process at a time. Most dramatic cost reductions come from comparing and contrasting many different processes, parts, shifts, and other items. By doing so, statisticians and engineers can identify critical differences and solutions that can save the company a lot of money.
Make certain that any chart can display any data that reside in the database. To support this requirement, SPC charts should be generated using database queries. Queries should be easily modifiable to allow the viewing and comparing of any data you wish, even if specification limits are different from part to part.
To make fair comparisons between different parts, machines, and features, SPC software should also accommodate normalization techniques that can be applied even after data have been entered.
Make certain that your SPC software will handle data normalization on the fly. Users should have the option to collect data any way they want and not have to worry about how the data might someday be analyzed.
From an analysis standpoint, changing the query should be a snap. Data normalization should be simple as well. The SPC software that you’re evaluating should have this level of flexibility in analysis. By supporting these flexible options, your SPC software should equip you to uncover meaningful opportunities for improvement and cost containment.
For a control chart, it’s critical that control limits are calculated properly. Not doing so can lead to a lack of alarms when emergencies actually exist, as well as to the creation of alarms when they do not exist. Either way, your SPC software must correctly calculate control limits, or you could be in trouble.
Here are three items to consider when determining whether your system correctly calculates control limits:
• Control limits should be based upon the process that made the part.
• Control limits should vary when subgroup sizes vary.
• Control limits should never be automatically recalculated.
First, control limits should be unique based upon a part number, the feature checked on the part, and the process that made it. When the same part is run on a different machine (process), then the control limits should change. If the software that you’re evaluating calculates control limits solely based on a unique part and feature, it is leaving out of the equation the very thing we are trying to control: the process. Isn’t that why we call it statistical process control?
Second, SPC software products should calculate control limits uniquely when subgroup sizes change. This should be true for the ubiquitous P-chart (for analyzing attributes data), but it should also hold true for variables data as well. For example, say an operator is required to enter five variable data values during each data-collection period. If one of the cavities in his or her mold, for instance, is plugged and only four data values can be entered, then X-bar control limits for the four data values should be wider than for a subgroup of five. If the SPC software doesn’t change control limits when subgroup sizes change, it’s statistically flawed.
Third, control limits should never be automatically recalculated. They should only be recalculated when a sta tistically significant, sustained change in the process has occurred. For example, imagine that your process has an ever-so-slight upward drift. Being slight, this drift is not perceptible unless you look at the data over several weeks. Now imagine that the control limits are automatically recalculated every seven days or every 50 points. If so, then the drift would be masked as the mean continues to slowly move upward. Therefore, it’s possible that this important trend could be missed. This is only one of many examples as to why control limits should never be automatically recalculated. Software that offers this feature indicates that either developers do not truly understand the nature of control limits, or they’re not concerned about the statistical veracity of their reported control limits.
If any of the three items above is true, then the software you’re evaluating violates fundamental statistical principles. Look closely and be careful: You don’t want to select a statistical software package whose control limits fail to trigger alarms when they should.
Data collection on the shop floor should be simple and visually oriented. During data collection, the most useful SPC software products present part drawings to operators and visually walk them through the data-collection.
Engineering drawings and photos presented to the operator should dynamically update when changeovers occur. When a new part is being made, the data-
collection sequence should update with the new engineering photos and the areas on the new part that need to be checked. In other words, the best SPC systems keep data-entry simple and visual for busy operators.
Additionally, operators should have instant access to important electronic media, such as engineering drawings, standard operating procedures, training videos, recipes, and work instructions. There should be no limitation to the type of application that can be opened. Doing so not only helps create a paperless shop floor environment, but it also provides the information that operators need to do their jobs the right way the first time.
The best SPC companies put a lot of time and money into support services. To ensure that your provider will live up to its bold claims, put their support to the test:
• Call the company’s application support during your evaluation period. See if you can reach them via phone and if they can effectively answer your questions.
• Speak with one of their in-house statisticians. Ask him or her some challenging SPC questions that relate to your business.
• Talk with some of their training staff. See if they can answer questions about setup and gauge communications.
• Call the implementation engineers. Ask them to tell you about the challenges in their last on-site installations.
• Make sure that the support staff has the ability to view your PC and work with it using safe collaboration tools such as WebEx.
All of these phone calls will help ensure that a vendor’s technical support isn’t just performed by harried, overworked programmers who use their tiny bit of free time to answer a couple of customer calls.
Any vendor of SPC software should employ industrial statisticians. If they’re selling statistical software, you should expect them to provide statistical expertise, consulting, and advice. If they don’t have statisticians in an SPC software company, it would be like taking your car to be fixed by an auto dealership that has no mechanics.
Look for thought leadership. Does the company employ experts who regularly give back to the quality community? By doing so, the SPC software company demonstrates that it is not just interested in your pocketbook, but is instead intent on delivering important statistical information and advice that can help you create the very best SPC system possible.
Hundreds of companies can create a control chart of data, but not many can manage your demanding needs. If you are serious about getting the best SPC software, focus on the items in this article and you will be able to separate the SPC software contenders from the pretenders.
As vice president of statistical applications at InfinityQS International Inc., Douglas C. Fair helps clients understand statistical methods and implement InfinityQS software in diverse environments and challenging situations.
Fair has co-authored two books on statistical methods: Innovative Control Charting (ASQ Quality Press, 1997) and Principles and Methods of Quality Management in Health Care (Jones and Bartlett Publishing, 2000). He is a bimonthly columnist for Quality Digest’s QualityInsider (www.qualitydigest.com/qualityinsider). |
