by Douglas C. Fair

Like good gymnasts, the best statistical process control software products are flexible--anticipating and accommodating the shifting requirements of today’s manufacturers. And like the product they’re searching for, evaluators must exhibit similar flexibility when considering current and future requirements of SPC analysts in manufacturing, engineering and administration. It’s not as easy as it sounds. Many excellent SPC programs have found successful market niches because their capabilities, functionality and flexibility are extremely different. Choosing the right product can create as much anxiety as walking a tightrope.

In order to make an informed decision and separate SPC software leaders from their runners-up, prospective buyers should ask themselves eight questions to help determine a product’s flexibility and its ability to meet the needs of today’s marketplace.

Does the software support any database application?

Open Database Connectivity is a Microsoft standard for communicating with databases. Like a printer driver that allows a PC to “talk” to a printer, ODBC drivers are required for a PC to communicate with a database application that conforms to the ODBC communication standards. Almost all commonly known database applications--including Microsoft SQL Server, Oracle, Informix and the like--adhere to the ODBC standards, making these applications simpler to use and support.

Make sure the SPC software product can be used with any ODBC database application. Beware the vendor whose standard product includes a proprietary database (i.e., the company offers to supply a product that will communicate with ODBC databases, but for a hefty price). If the vendor requires you to purchase proprietary database drivers to communicate with an ODBC database and then subsequently goes out of business, those drivers won’t be supported and most likely won’t work with newer database software versions from Microsoft, Oracle or others.

By limiting your search to ODBC-compliant vendors, you’ll have the flexibility of starting with one database--say, Microsoft Access in a stand-alone installation--and then moving it to a more sophisticated database application after determining that the SPC software works as advertised.

Is the software built in an open-architecture format?

Products with an open-architecture format can communicate with any gage, computer and database over any network. Additionally, open database systems allow tables, relationships, fields and other critical information to be viewed by system administrators and IT staff. This visibility means the system will automatically and invisibly accept data sent from other systems into the SPC software. Data can then be analyzed without manually entering it or importing it via the SPC software. An open-architecture system can serve as the single database repository for your organization.

Beware of vendors that offer “keys” to view the underlying database architecture. Keys are typically expensive and drive up the overall system price unnecessarily. Without the flexibility of an open-architecture system, your IT staff must work with data that are entered solely through the SPC system’s user interface.

Can any data be placed on any chart?

For ultimate analysis flexibility, a chart should be able to display any data that reside in the database. In other words, a chart from an SPC software product should be a simple database query that can be modified if necessary. For example, if a chart displays data from a single part, the software should allow users to change the chart to include multiple parts and/or multiple machines. The charts should correctly display unique control limits for each machine and the part(s) it has made. Changing back to a single part on the chart should be simple and fast.

Some SPC software products are file-based systems that don’t operate in this fashion. Instead, users are required to create “part files” to enter and view data. With these products, data are entered and saved in files as unique, separate entities within the database. Such software’s inherent inflexibilities inhibit data extraction.

For example, consider the case of an engineer who wants to access the production database to evaluate the same critical dimension from a family of parts and compare them on a single chart. With a file-based system, this would be difficult, if not impossible, because data reside in several separate, unrelated files. By their very nature, file-based systems severely limit post-data-collection analysis. While researching SPC software, make sure that any data in the database can be placed on any chart and that charts represent database queries.

Flexible SPC software can change a chart’s data on a moment’s notice. Engineers, managers and Six Sigma teams should be able to easily combine data for multiple parts and machines for comparison on a single chart, or otherwise manipulate and parse data. By doing so, they’ll be equipped to uncover meaningful opportunities for improvement and cost containment.

Will one data-collection procedure serve many part numbers?

SPC software products whose charts are simply queries of the database can be configured such that a single data-collection procedure can support data entry for hundreds, even thousands, of part numbers. These applications use the features of a relational database, thus minimizing reliance on old file-based technologies and dramatically reducing administration and maintenance costs.

Good software makes searches for data-collection procedures and parts files unnecessary. On the shop floor, users can easily change from one part to the next; there should be no reason to exit the application and search for the file before performing data entry. With file-based SPC systems, administrators must create a file for each part. For a company that makes 1,000 parts, this means creating and managing 1,000 part files.

Also consider that if a single part can run on multiple machine tools or production lines (i.e., the processes that SPC is meant to control), then in order to calculate control limits properly, users must create a file for each part-process combination. Thus, if each part runs on six different machine tools, your IT staff must create 6,000 files to properly analyze 1,000 parts running on six machines. Some file-based SPC systems can handle more than one process in a part file, but make certain that the control limits differ from one process to the next. If the control limits are the same across both processes, it’s a statistical error. Additionally, with the creation of potentially thousands of part files, shop-floor employees will find themselves spending valuable time searching through thousands of files to find the one they need for data collection.

From an analysis standpoint, thousands of files might frustrate post-data-collection analysis because of the inaccessibility of data residing in so many files. To minimize this frustration and maximize data-collection flexibility, choose an SPC software product whose charts are database queries, not separate files.

Can data be normalized after collection?

To extract meaningful information from collected data, various data-normalization techniques must be applied after shop-floor data collection has occurred. For example, a process engineer wants to compare, on a single chart, two different machine tools that manufacture 20 different parts. If specification limits differ from one part to the next, then the data must be normalized to allow for fair comparisons. Additionally, other data-normalization techniques might be necessary to account for differences in machine standard deviations. SPC software products with flexible normalization procedures allow data to be normalized in many different ways, even after data collection.

Beware of SPC products that require users to know what type of normalization to perform before data collection. These products typically can’t accommodate spontaneous normalization. This inflexibility can sometimes lead to a complete overhaul of the SPC system. Rather than begin again, make certain that your SPC software will handle data normalization “on the fly.” Users should have the option to collect the data any way they want and not worry about how the data might be analyzed later. The most flexible SPC software products allow normalization as an afterthought.

Can the user environment accommodate different needs?

SPC software users range from those with little or no computer experience, to those who are sight-impaired or color-blind, to users who speak little or no English. In order to manage the needs of these people, your SPC software must be able to change the user environment based on who signs into the application.

At a single workstation, different users should be able to view charts and graphs according to specific color, chart and line preferences. Colors of fonts, chart backgrounds, lines, specification limits, control limits and other items should be automatically set to the preferences of the user. Additionally, all words, phrases and information displayed to the user should change based on the user’s preferred language. In other words, the user environment must be flexible enough to handle the very different needs of today’s diverse workforce.

Can subgroup size be changed easily?

For attributes and variables data alike, SPC software products should be flexible enough to manage real-world irregularities where subgroup size changes. Statistically speaking, control limits must change based on changes in subgroup size.

For example, consider the case in which a 10-cavity mold is used to make injection-molded parts. In the real world, it’s not unusual for a cavity to become inoperable or plugged due to some machinery problem. However, parts manufacturing must continue until a fix can be implemented. In that case, rather than a subgroup size of 10, the operator might only input data for nine parts. Because control limits are inversely related to subgroup size, the control limits should automatically increase (i.e., widen) based on a reduction in subgroup size. If they don’t, the vendor either doesn’t understand the relationship between subgroup size and control limits, or the software simply can’t handle real-life issues that confront shop-floor personnel. Either way, these inflexibilities can hurt an SPC software implementation, chart interpretation and validation.

Can SPC data collection match workbench data collection?

The real world of a machine operator involves many different distractions and problems. The last thing an SPC system should do is force users to adhere to its quirks. Instead, the best SPC software products mimic the most unusual data collection needs at an operator’s workbench.

The software’s data-collection procedures should be flexible enough so that users can skip characteristics, disable keyboard data entry for specific features, automatically collect data from gages or data files, force data collection using gages and skip incomplete or missing values within a subgroup. Some of these options will be available only with software that’s resilient enough to manage missing values while correctly calculating control limits and related statistics. The software must manage the specific needs of shop-floor operators who have little time to spare on anything other than making parts correctly.

Ensuring your success

Selecting an SPC software product can be a difficult and time-consuming process. Hundreds of vendors want your business; software options abound and every company claims to be the industry leader. What separates the leaders from the losers are the eight questions answered in this article. These expose a product’s foundation and, ultimately, the software’s flexibility. A vendor who answers “no” to one or more of the questions creates a potential problem for the software’s downstream, long-term use and, inevitably, your success. Look for products that can deliver “yes” answers instead. These products will function as flexibly as world-class gymnasts.

About the author

Douglas C. Fair is director of statistical applications at InfinityQS International Inc. He’s also the co-author of two books on statistical methods: Innovative Control Charting (ASQ Quality Press, 1998) and Principles and Methods for Quality Management in Health Care (Aspen Publishing, 2000).