The purpose of any change control process is to manage the evolution of a product from the current approved configuration to a new approved configuration. And, by definition, an "approved configuration" includes all of the product data necessary to reliably create the product.
The Institute of Configuration Management defines its change process (CMII1) as a means to
A change form describes an intended or actual action affecting a product's documentation and/or parts. You can specify related information, such as
A non-implementing change form simply announces a particular fact about the affected items. A "fact" may be, for instance, that a product needs upgrading ("change request"), or product shipments must be stopped until a defect is corrected ("stop ship"), or an unapproved component can be used as a temporary substitution ("deviation"). Changes which have a temporary effect on the product, such as a deviation, are often called "temporary changes". In general, temporary change forms address changes to items without specifying specific revisions: the document revision may change between the change proposal and its implementation; part revisions are interchangeable and therefore irrelevant when issuing deviations or stop ships.
An implementing change form acts upon the parts and document that are listed on it. Items that are not yet released ("pending" items) will be released, and released items will be canceled. A non-implementing form does not release or cancel anything. Therefore, the process flow and outcome will be somewhat different between implementing and non-implementing change forms.
What's an "EC"?
Many configuration management specialists encourage the use of "enterprise change process" rather than "engineering change process". This reflects the view that, once a company adopts a useful change process, this process can be extended throughout the organization. In particular, marketing requirements and product literature, sales procedures, product warranty policies, staff training materials, field service procedures and a host of other documents blur the distinction between engineering product data and other important product-related information.
There are significant benefits to ensuring all documents and physical assets are properly managed and controlled, and scaling the initial "engineering" process into an "enterprise" process can be both simple and quite effective.
Nonetheless, since most companies start with an engineering change process, that's what we'll use in this topic. Some terms like ECR and ECO will work in either case.
In order to release and cancel items, your PLM design must include at least one implementing change in its set of change forms. Every other change form is optional.
The engineering change notice ("ECN") or engineering change order (ECO)2 defines a set of items being released and/or canceled. That is, a signed-off ECN/ECO documents that the items listed on it have been updated and may be used in accordance with the effectivity dates listed.
The ECN/ECO may also provide information on the dispositioning of the items, such as whether current inventory should be reworked, returned to the supplier, or scrapped. The ECN/ECO may also calculate the change's cost; for example, the expenses associated with scrapping or reworking old parts, and retooling and expediting new ones. An engineering change order typically affects design documentation and part release or revision.
There may be other types of implementing change forms, such as a manufacturing change order, which is used to control process documentation and approved vendor parts. Similarly, you can define change forms that are managed by different groups using specialized change workflows that manage product marketing literature, accounting policies and procedures, and customer support scripts.
A problem report describes a product issue that requires investigation, validation and possible remediation. Since the PR may be initiated by a customer, regulator, or employee who does not know the product in details, it may not identify an affected item.
An engineering change request (ECR) or engineering change proposal (ECP) is a documented notice that an item may require modification. The ECR identifies the specific deficiency in enough detail so that the responsible designer can understand the problem. While a proposed solution is usually required, this solution may not be what is ultimately implemented.
A request for deviation (RFD, or simply a deviation) and a waiver specifies a temporary suspension of approved items as a result of, typically, an unavailable or incorrectly manufactured part. A deviation proposes the use prior to the acquisition of the parts, while a waiver proposes acceptance of already-produced items that do not conform to the design documentation, but are acceptable for use (or will be acceptable after approved rework is performed). Deviations and waivers apply only to parts (never documents), only to the part numbers (never specific revisions), and are typically limited in quantity or time. (You'd release any temporary rework instruction documents using a related engineering change order.)
You'd use a stop ship to temporarily halt shipments of products (parts) that may not conform to design requirements. A stop ship will typically provide a fixed time, after which it expires or is replaced with a new stop ship or other change (e.g., an ECO or deviation). It is written agains a part number, not a revision, as all revisions are interchangeable and may be intermixed in one inventory location without markings.
If revising a document or a part record requires a change form to describe the rationale for the revision, shouldn't revising a change form require a similar level of documentation - a "meta-change"? How does one know the release status of an item that appears on a particular change revision, but not on another? While business rules can define what can be changed on an ECO, the fact remains that any subsequent revision creates an ambiguity that your customers, supply chain partners and even your employees may not fully understand.
An engineering change is a "complete thought", a directive to execute a specific bundle of modifications. If the directive is wrong, then we (a) "roll back" the entire bundle - if possible - by canceling the change, or (b) execute a new change that may counter the effects of the preceding change.
Engineering change orders should be issued exactly once, and therefore a revision identifier is unwarranted.3
Many smaller companies only require two change forms, one for permanent changes (the engineering change order) and the other for temporary changes (the deviation).
All changes should only require two reviewers: the person who is responsible for creating the item, and the internal user (whether in production, product management, sales or customer support) who best knows how the item is used in practice.
Every other interested party is simply notified as the change is considered, processed and released.
In larger organizations, it may be important to gather the cost impact of making changes prior to executing a change. For example, some changes may require coordination between people who must plan the change, schedule engineering resources and production downtime, and involve a complex supply chain. Failure to plan wide-reaching changes could force costly rework and vendor returns, and threaten the sales channel with production gaps.
A more complete engineering change process consists of these elements:
In CMII, these ideas are detailed in six distinct change forms:
In lighter-weight processes, these ideas are often consolidated into an engineering change request, engineering change order, and engineering change notice; a temporary fix, called a deviation, may keep the production line moving.
Regardless of the number of forms you adopt, the review and approval responsibility should still conform as much as possible to the two principals: document content author and its user. In highly-controlled environments, you'll probably include a third authority who is responsible for regulatory and/or contract compliance.
A department or group is one or more people responsible for the technical accuracy of the PLM software system. You can choose to set up any number of departments and groups to reflect your product management process:
Whether you choose to define departments, groups, or a combination is up to you. However, if your process is organizationally oriented (for example, the quality manager, engineering manager and production manager approve design changes on all projects), you'll probably work primarily with departments. Conversely, if your company is project-oriented, then job classifications (program manager, project engineer, product marketing manager) may be more appropriate.