10/15/2000 | 4 MINUTE READ

Picking High-Quality SPC/SQC Software

Facebook Share Icon LinkedIn Share Icon Twitter Share Icon Share by EMail icon Print Icon

If you want to improve something, you measure it. On the production line, within the enterprise, and even externally along the supply chain, the measuring tool of choice is statistical process control/statistical quality control (SPC/SQC) software. Here are some issues to consider in choosing that software.


Facebook Share Icon LinkedIn Share Icon Twitter Share Icon Share by EMail icon Print Icon

Selecting off-the-shelf SPC/SQC packages, says Michael Young, president of Process Integrity, Inc. (Arlington, TX), begins with going back to "what you're buying this stuff for." From that, determine what analyses will help you realize that goal. Then, figure out what information you need for that analyses. These basics help reduce the universe of software packages to those few that might satisfy your needs.

Unfortunately, too many buyers select software by researching what's available, building an aggregated checklist of features, and then sending this list to all the vendors to check off what their software can do. Make sure this checklist has some weightings, urges Brad Klenz, technology strategist, Quality Center, for SAS Institute Inc. (Cary, NC). The weightings he suggests are: "have to have now," "nice to have," and "what will be needed in the future." (The future being a year or two from now.) And remember, he adds, "even though 'nice-to-have' features aren't requirements, they can be real crowd pleasers on the shop floor."

Easy Does It
Software user interfaces often create a dilemma: The more options and capabilities in the software, the more complicated the user interface.

Given that, a major differentiator separating SPC/SQC software products is in how easy they are to set up, use, maintain, and integrate with the rest of the software applications in the enterprise. "If this stuff is hard to use, it's not going to be used well," says Jeffery Cawley, vice president of Northwest Analytical, Inc. (Portland, OR). By extension, a properly designed interface also greatly reduces training time.

So, ensure the software is easy and quick to learn—and relearn—and that it doesn't get in the way of the work at hand.

Also ensure the software displays are in a language that everybody can understand. "Inputs and outputs have to be pinpointing some measurement or action that you can measure within a process, and that information must be captured in a standard, easy-to-understand format," says Young.

Tweaking the Package
Most off-the-shelf SPC/SQC packages come with a basic set of analytics and display options. From that basic set, they diverge. Note that an increasing number of SPC/SQC packages are adding more complicated data analysis to their basic set of analytics because of the increase in user sophistication, plus the advances in computer processing technology, coupled with the plunging price of computer hardware.

Sometimes the analytics in an off-the-shelf software package can be tweaked for a unique user requirement. Too often, the analytics exist in the software, but they are not easily tweaked.

This ability to change analytics is important. All the automakers, says Klenz, have written their own textbooks regarding quality analysis and acceptable analytics. As a result, custom SPC/SQC software is prevalent on the automotive production line.

The flexibility to meet needs
Tweaking analytics is just one customization issue. Also consider this: Along with producing easy-to-read and -interpret charts, the SQC/SPC software should provide the ability to customize chart titles, axes and data point labels, and other report elements to match the reporting requirements of your company, supply chain, and associated regulatory agencies. This is especially true in supply chains with contracts requiring SPC/SQC deliverables, says Cawley. What's more, not only must the SPC/SQC software deliver control charts, process capability reports, and so on, the output often must also conform to AIAG standard formats and computations.

Another useful customization, continues Cawley, is the ability, through some internal scripting language, to automate routine procedures, such as generating the same reports hourly, daily, weekly, or whatever. You don't want your people keyboarding when they've got more important work to do.

The ties that bind
Integrating SPC/SQC software to databases and other software applications is so much a reality today because much of the quality and process control data collected will come from plant floor data collection systems, laboratory information management systems, the Web, extranets, virtual private networks, and the like.

Generally, off-the-shelf software packages rely on Open Database Connectivity to integrate with external data sources. However, the world will not come to a screeching halt if such easy and direct access is not available. Usually some mechanism exists to export and import data between a database and an SPC/SQC system—even if that mechanism is a kludge involving a text-file transfer.

Another information technology issue to consider is the real-time nature of the SPC/SQC package. Is the data analysis and associated quality information available immediately or a week or more later? "Speed up the feedback time, and you'll speed up the improvement," comments Young.

Look at the vendor
Last, don't forget to evaluate the software vendor. A profile of the vendor should go beyond addresses and tech support phone numbers. Investigate how long the vendor has been in business, the number of customers using the software, and for how long the software has been used. If possible, talk to three users; find out how they use and like the software. Perhaps there is a user group.

More important, find out if the software helps those users accomplish their goals in the high quality you want the software to help you.

Here are some other factors to consider in the SPC/SQC software evaluation:

  • Usability Can the software handle both production and laboratory data? Will you be able to select one package to meet the needs of all users?
  • Data Elements Can descriptive, measurement, and defect data be viewed in and analyzed from the same data file? 
  • Operator Requirements Can routine charting tasks be automated to reduce training time? Is unattended operation possible? 
  • Configurability Can charts be configured to precisely meet internal QC needs and still meet customer and regulatory reporting requirements? 
  • Computability Can the software easily collect process data? Can it accept instrument data? Can it share or exchange data with corporate or manufacturing execution systems? 
  • Vendor Awareness Are the software developers knowledgeable about the issues and special requirements of your manufacturing environment? 
    (Source: Northwest Analytical, Inc.)