Customer Support

Designing your engineering change workflow

Part 1: Engineering change process design

Product lifecycle management software provides a lot of flexibility for defining an engineering change control process. By examining the impact of your design decisions, you can determine how best to take advantage of this flexibility in your product data management system.

In Part 1 of our discussion, we'll identify various engineering change forms and how they're used (the change process). In Part 2, we'll consider how each engineering change form is created, reviewed and approved (the change's workflow). Part 3 will describe how to define a engineering change form template that can be used in your PDXpert software's change process.

Balancing control with speed

Your engineering change process must balance the tension between control and speed. Both of these have real financial costs: excessive control imposes a time-to-market "tax" on all of your product data management activities, while over-emphasizing process speed may increase the risk of expensive production or customer service mistakes.

An efficient engineering change control process ensures that all essential approvals are obtained without adding unnecessary approvals to the process.

To achieve the right balance for your engineering change process, consider:

How many different types of change forms are required to implement the entire change process? (this Part 1)
How many steps are necessary to approve each engineering change form in your process? (Part 2)

When in doubt, an important principle for creating a manageable and efficient change workflow design is that "smaller is better". Scaling up a simple process will always be easier than trimming an existing complex process.

Required change form: releasing the changed items

An engineering change process leads up to the critical event: an item (part or document) becomes formally accepted for its intended use. PLM software releases items using what we call an implementing change form ("ICF"). When your users approve the ICF, it will change the release status of the affected item revisions from Pending to Released, or from Released to Canceled¹.

In many workflows, the ICF is called an Engineering Change Notice, and abbreviated as "ECN"². Your company may prefer another name and abbreviation, such as Engineering Change Order (ECO). If the form is shared among many different functions (such as Quality or Marketing) to manage their own requirements and specifications, then you may want generalize the name to "Change Notice". In the Institute of Configuration Management CMII model, the ICF occurs in what they call a "Document Change Record" (DCR).

Optional change forms: reporting a problem

A problem report (or bug report) describes a perceived deviation from requirements, or suggests an enhancement that improves cost, quality, serviceability, or other important parameter.

A problem report (PR) typically does not need to offer a root cause or propose a solution. It is often created by persons directly interacting with the product in manufacturing, field service, sales, and customer support. Your process may or may require the PR to be "approved" (reviewed and accepted as legitimate) by the creating person's supervisor, the product manager, or a quality representative.

Optional change forms: requesting a solution

An Engineering Change Request (ECR) presents the opportunity for describing the problem and likely solution, and for assessing the likely financial benefits of the change prior to expending significant resources.

Not all ECRs result in a revised design. Regardless of technical merit, ECRs that don't have positive financial benefits are usually rejected or canceled. Change requests that represent a speculative benefit may be parked until they can be coupled with a related change that has demonstrable return on the investment.

Many companies don't need to consider an Engineering Change Request prior to revising items. The team informally determines whether a change is warranted, and can skip a formal financial impact assessment and work order.

Optional change forms: authorizing proposed changes

There may be times when you want to explicitly review and authorize proposed documentation changes prior to any work being committed to the originals. This is often important in larger organizations where the proposal effort is quite different from the actual design effort (that is, a redline is required prior to working with actual design documents) or where any technical effort requires the customer's prior approval.

However, as paper-based designs become less common, and as changes are modeled using the same electronic files that will contain the final design, the benefits of creating separate redlines is fading. Although at one time there was substantial effort to incorporate redlined changes into the final documentation, nowadays the modification may simply requiring copying the redline into the PLM file library.

Engineering change forms in your process

The fastest change process requires only an Engineering Change Notice to release³ the affected items. The decision-making team communicates informally on whether to revise the items, without requiring a formal analysis.
Where a change's financial impact influences the technical decision, a common engineering change process uses ECRs to describe proposed changes, estimate their financial impact, and allow work to proceed. An approved ECR authorizes revisions to the original documentation. The follow-up ECN lists the items that have been revised and which, upon the ECN's approval, will be released for use.

Typically, related ECRs may be freely combined into one ECN (and, less often, allocated to multiple ECNs) to promote efficient use of resources.
Another process alternative defines separate financial and technical assessments before allowing any items to be revised.
- ECR identifies the problem and accepts the financial impact of the change
- ECN approves the proposed technical changes prior to execution
- Document Change Record (DCR) provides an audit of the changes, incorporates the change implementation plan (i.e., "dispositioning") and releases the revised documents
The most comprehensive process adds an "issue tracking" function.
- Problem Reports to identify and log problems
- ECR to approve the financial impact of the change
- ECN to approve the proposed technical changes prior to execution
- DCR to audit execution, identify the disposition of parts, and release/cancel the changed documents

Obviously, there's no reason you can't include Problem Reports in the the first two workflows, eliminate ECRs, or rename these change forms to reflect your company's preferences.

Other optional "change" forms: managing production exceptions

Your product data management process may require additional status "announcements" that are not intended to affect the release status of any item. Instead, they provide short-term guidance for managing unusual situations. The two most common announcements are Deviation and Stop Shipment forms. Both of these are intended to address a temporary condition:

Deviations (DEV) indicate that a non-conforming part or process can be used in production, and may specify how the non-conformance should be handled (for example, use as-is or rework). There's a slight difference between a Deviation ("ask for permission") and a Waiver ("ask forgiveness"), but in practical situations the distinction often isn't meaningful, and one change form may be sufficient for handling both a priori and after-the-fact non-conformances.
Stop Shipment forms ("Stop Ship" or STOP) directs that all shipments of the affected product must stop until a suspected defect is validated or rejected. Prior to its expiration, a valid Stop Ship should be replaced by a deviation that contains replacement items, or an ECN that revises the current items, to address the non-conformance. A Stop Ship doesn't always mean that production must be halted; it's often more efficient to finish the current manufacturing lot with the understanding that suspect units should be segregated and may require rework.

By definition, product exceptions are temporary and must be set to expire or be replaced by a permanent solution using the normal engineering change process. They are typically bounded by date, end-item serial number, or production lot code.

Notes

1. In PDXpert software, you create an implementing change form by marking the Releases/cancels items in Affected tab checkbox in the Change Form template, which is contained in the Collections Explorer.

2. In PDXpert, the name & abbreviation can be easily modified in the Change Form template.

3. As noted in the ICF discussion, to revise an existing data record, you'll be releasing the new revision while canceling the previous revision. You can mentally substitute "release/cancel" whenever we say "release".

Resources

Share This Page