Manufacturing Configurator

For our purposes, the definition of a Configurator is rules-based— the use of the concepts of expert systems to define and use product information in a practical manner. Think of rules as easily recognizable algebraic notations, such as If-then, Select, Greater than, etc., accompanied by textual explanation messages. Rules-based methods are methods designed to define unique product configurations in a more user-friendly fashion than older methods.

Rules-based systems are often associated with artificial intelli­gence (AI). But AI is usually defined in terms of getting the computer to think like a human being, including learning from experience, so such software must be quite sophisticated. On the other hand, expert systems, or knowledge-based systems, are normally defined at a lesser level of sophistication, i.e., more pragmatic and understandable!

Most of the MRP II software vendors do not use expert system packages per se, rather the concepts are programmed in the language of the MRP II software of which they are a module. For instance, Friedman & Associates uses RPG II, Logia uses Advanced Revelation and Minx uses C. Recently, several pack­ages from the AI community have appeared. These vendors are: Intellicorp, Trinzic, and Trilogy.

In general, the software vendors define their capabilities in two categories: (1) creating the product definition database, and (2) using scripts of selection criteria, or questions, to accomplish the unique configuration task by selecting the components and routings from some form of a master file. The capabilities often include rules for pricing and costing.

Usually, the master file for bills of materials is a form of modular bills with rules associated with the component parts to be used in the selection process at order entry time. One vendor (Logia) relates rules to parts without any form of modular bill file.

Most of the early implementations of PDM systems were in engineering design; only recently have they encompassed func­tions such as manufacturing. The widening scope of PDM systems has been fueled by the increasing realization that time-based strategies are imperative if manufacturers are to compete in the 1990s. More of you will become involved with evaluating and implementing these Integration Enablers as the implementation of PDM systems spreads beyond their engineering orientation.

The decision processes for evaluating PDM systems will look quite familiar to those of you experienced with the decision processes for evaluating and implementing MRP II systems. The general methodology is almost identical; some of the terms and project team players may be different.

As with MRP II software, there are two fundamental choices— make or buy, with some degree of enhancement. MRP II software is considerably more mature than PDM system software. Rarely if ever is it rational to develop MRP II software in house.

In the case of PDM systems, however, the decision is not quite so clear cut, due to a number of factors. One is the rapid evolution of the software. Another factor is the limitations of current technology. These limitations may cause companies to think twice about the scope and intensity of their ambitions until software matures to a higher level.

The evaluation/selection process is similar to that for MRP II, but the sources of software are quite different. As background, the reader should first understand the nature of the market. By the definition of PDM systems presented earlier, there are over thirty packages available from software vendors, although only about half represent any substantial system.

Most of the vendors originally entered the market from the direction of CAD packages, not MRP II. Their impetus was the need to control the proliferation of information being generated by CAD systems. However, many of the packages are expanding in scope to position the software as enterprisewide solutions and not just for managing CAD.

There are more than thirty commercially available software package sources in the U.S. There are a few more in Europe; but the major players are all U.S. based. CIMdata offers a review and evaluation service for PDM packages.[2]

When evaluating the vendor's response to checklists, both for applications and technical capabilities, bear in mind the lack of standardization of terminology. There is not yet an APICS-type
dictionary! Furthermore, a capability that is checked as "Yes, we have it" must still be analyzed. Interpretations may be different, and the vendor's terminology may not be the same as the team's.
Be sure the team understands how the software accomplishes the checked capability.