Philip Sargent
15 June 1997
Product Data Management (PDM) software is used to store and process an engineering organisation's design information. MRP software is used to control the configuration and production of manufactured articles. Between the two there are software gaps, overlap and potential conflict, but there are also real tasks requiring engineering analysis and judgement in mediating between these two worlds. Sometimes the software can help.
MRP originally stood for "Materials Requirements Planning": matching order levels of raw materials to match predicted final product shipments. This took little account of the factory capabilities to turn raw material into product and was superseded by "Manufacturing Resource Planning": MRP-II. These evolved into today's large suites of software which calculate resource-limited schedules, manage change control of product configuration, allow for future planned changes in product and resources, monitor shop-floor production as well including full financial and stock control functions. These huge suites are sometimes termed Enterprise Resource Planning (ERP) systems and are intended to cover the entire organisation, not just the manufacturing functions.
MRP-type systems are now very mature in Western economies and are used by manufacturing enterprises almost without exception. Conversely, an awareness that such things as PDM systems even exist dates only from the early 1990s. The hoped-for phantom that is expected by those attempting to procure PDM systems, a myth which is encouraged and reinforced by unscrupulous PDM vendors, is that there is an "interface" that one can buy that plugs the PDM system into the MRP system.
"Does it have an interface to SAP/Baan/BPCS/Triffid/Fourth Shift/Swan ?", asks the customer; "Yes", says the salesman, and both move on to discuss maintenance contracts and consultancy rates. The error is not that an interface may not exist: any specific PDM system might or might not have some means of accepting updates or sending data and commands in a syntax that the MRP system can cope with. The error is thinking that such "conversations" are standard things that can be bought. They are not. They have to be investigated, designed and programmed; even if the PDM and MRP systems are both "vanilla" implementations used straight from the box.
Every PDM system and MRP system will be used in a certain way by a company that uses it and it is these working methods that have to be reconciled across the PDM/MRP boundary: both systems have to have the same view of how the company's design procedures will span the gap.
In any case there will not, in all probability, be a single point at which a design is "finished" and the design information passed over the wall to manufacturing. Companies used to operate in this way but concurrent engineering is at least attempted by all companies trying to reduce their time-to-market, and any organisation thinking of buying PDM is more likely to trying to increase concurrency rather than reduce it.
Figure 1: PDM-MRP Communications
The easiest way to mediate between MRP and PDM is with people: the packages never talk to each other directly, but engineers have two windows on their monitors, one for each system (the modern equivalent of two terminals on the desk).
The first step in complexity after the human-mediated approach is to have the "single point" interface: a fixed, "issued" product structure as-designed is released and exported to the MRP system which accepts it as a wholly new pre-release bill of materials to be modified by the manufacturing engineer from "as-designed" to "as-built" form. If the MRP system cannot handle both types of bill of materials, then the restructuring may take place in an intermediate spreadsheet (a common method in companies before they buy PDM) or in the PDM system prior to export. The key point to notice is that in this scenario the change control processes in the PDM system and the MRP system are entirely separate: the company may operate a common paper system but database updates are performed independently on the two packages.
This now exposes the true problem: how can two different software packages co-operate in a common change process, handing over responsibility to the other at the appropriate point. While some modern PDM systems can be configured or programmed to do this, very few MRP packages can cope with the concept that they are not in complete control of the companies engineering information.
Consider the "simple" matter of propagating modifications to a product structure (bill of materials) from one system to the other. Assuming that both systems can agree on a unique product and version identifier (not always easy), a simple batch program could collect the day's updates from each system and feed them into the other overnight. But that omits two things: access control and conflict errors.
Thus every installation of a PDM-MRP link has to set update rules, e.g. the MRP system can update certain values: prices, costs, dates etc. in the PDM system but not product assembly structures. The PDM system can import new products into the MRP system but not modify old ones. These rules have to be worked out for each company individually and require analysis, decisions and documented procedures.
A more sophisticated approach is to have different rules for different stages in the product's lifecycle. This is shown in the lower half of Figure 1 where there are several points at which information and control is passed between the PDM and MRP systems.
However both MRP and PDM systems have to be programmed to understand the same staging points in the product life cycle and a new change control system put in place to ensure that any changes to the workflow rules defining this lifecycle are updated simultaneously in both systems. If written in software, such a system would of course be bespoke to the individual company.
Any engineer procuring a PDM system should certainly have a item on the check-list labelled "Interface to Company MRP System", but should be aware that turning that into useful time-saving capability will take rather more consultancy and maintenance effort than simply ticking the box.