Designing your engineering change process and change forms

PDXpert PLM software supports a virtually unlimited selection of change forms to meet almost any requirement. So, whether you only need a single form to release and cancel item revisions, or a complex array to propose changes, provide for design deviations and production waivers, and temporarily suspend shipments, PDXpert software has your product data management needs covered. In this topic, we describe many engineering change forms and a comprehensive change workflow, but emphasize that a simple system is almost always more efficient and less expensive.

Most product companies begin with a manual paper-based engineering change process. In these configuration management (i.e., "document control") systems, change forms are documents that describe the change, list the items that are affected by the change, and provide for authorized people to approve the change.

In a PLM software system, these functions are still important. In addition, the automated system will actually release or cancel items as directed by the change's contents and perform cost estimates. The PLM software also provides convenient real-time links to the affected items, their parent assemblies, and attached electronic data files such as CAD drawings, specifications and budget worksheets.

Engineering change process overview

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 (CMII¹) as a means to

1. accommodate change
2. accommodate the reuse of standards and best practices
3. ensure that all requirements (all released information) remain clear, concise and valid
4. communicate (1), (2) and (3) to each user promptly and precisely
5. ensure that results conform to the requirements in each case.

Engineering change process forms

A change form describes an intended or actual action affecting a product's documentation and/or parts. You can specify related information, such as

• Whether a change affects the actual release or cancellation of an item
• The disposition of the affected items
• Who will be reviewing and approving the change, and who will be notified after the change has been approved
• A cross-reference to preceding or related changes
• Electronic file attachments that describe rework instructions, cost impact or other information necessary to ensure that the change is adequately reviewed and implemented.

Implementing and non-implementing changes

An implementing change form (sometimes called a "permanent change" form) is the vehicle for executing the release and/or cancellation of a set of affected items.

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.

Implementing change forms: engineering change order or engineering change notice

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)² 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.

Non-implementing change forms: engineering change requests & deviations

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.

Engineering change form revisions

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.³

Determining which engineering change forms are required

Simple engineering change process

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.

Comprehensive engineering change process

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:

• Problem identification
• Solution proposal and cost estimate
• Business case review and approval to execute
• Technical design review and production impact assessment
• Documentation update and notification of changes
• Execution of changes through inventory actions, rework, supplier notifications, etc.
• Temporary remediation, if required

In CMII, these ideas are detailed in six distinct change forms:

• problem report
• enterprise change request
• enterprise change notice
• document change record
• work authorization
• deviation/waiver

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.

Defining reviewing departments and their authorized reviewers

Functional department or product role?

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:

• Departments are organizational divisions, and reflect where formal responsibility is assigned: engineering, manufacturing, procurement, marketing, service, etc.
• Groups perform ad hoc, cross-departmental functions, and reflect what a person does: program manager, design engineer, quality manager, production supervisor, CM analyst. Since a person can be assigned to more than one department/group, you may have program managers in marketing and manufacturing, or engineers in engineering and purchasing.

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.

Limiting participation

In PDXpert PLM software, you can create a single change form template and tailor it "on the fly" to a specific need by adding appropriate reviewing groups. Alternately, you can create specialized change forms that specify a fixed set of reviewers. In either case, the list can be virtually unlimited in scope.

However, it's essential to distinguish between those would are responsible for the technical accuracy of the change and its contents, and therefore approving the change, and those who simply need to be informed of the change.

Best practice, in most cases, encourages an absolute minimum number of responsible approvers, typically two: the creator/modifier of the technical data and the user of that data. Increasing the number of reviewers slows the change process, consumes scarce technical resources, delays implementation of the change, and - surprisingly - may increase the likelihood of mistakes:

• The time to review a change is linearly dependent on the number of reviewers, yet the first competent reviewer should be able to find pretty much every error. So, doubling the number of reviewers will make the review process twice as long, but is very unlikely to catch a significantly greater number of errors.
• Long experience has shown that there's a "finite quantity of responsibility" for discovering errors. The more people responsible for approval, the less likely any one person will actually be held responsible. An approval with more than a few people simply gets passed along, with each person confident that the preceding reviewer, or the next reviewer, will ensure the change is correct. Invariably the question "Why did you approve this?" is answered with "Because everyone else approved it."

Change workflow design

Each change has a lifecycle, from origination through completion. The process of moving a change along a path, from one lifecycle state to the next, is called the engineering change workflow. This process is begun with the creation of a change form and identification of the affected items; the change form is then routed for review and, if approved, executed according to its business rules.

In PDXpert product lifecycle management software, you can define a unique change workflow to support each engineering change form template (or any other change form, such as for production or marketing product data). For practical advice on creating your engineering change forms & workflow in PDXpert, see our application note Designing an engineering change process and workflow.

Notes

1. The term Configuration Management II, or CMII, is used by the Institute of Configuration Management for their document and change management process. This process, while most appropriate for large enterprises, is a useful model for controlling product information. It can be adopted by smaller companies by careful assessment of the change forms and workflow.
2. The terms "engineering change order" and "engineering change notice" are pretty much interchangeable in small and mid-sized companies. It's very simple to rename your change forms (and abbreviations) in PDXpert PLM software to whatever you prefer.
3. Although a change form may be "locked down" after it's been released, PDXpert PLM software permits some attributes (such as dispositioning tasks) to be modified by specified users.

Contact us if you'd like to discuss how the general concepts in this note may be applied to your situation. We'd be happy to address other PLM software good practices — ask us!