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 an 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 executing change form (or "implementing change"). When your users approve the executing change, it will move the release status of the affected item revisions from Pending to Released, or from Released to Canceled¹.

In many workflows, the executing change 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 executing change 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) does not need to identify 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 will usually require the PR to be approved (reviewed and accepted as legitimate) by the creating person's supervisor, a quality representative, or product manager.

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§

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

2. Where a change's financial impact influences the technical decision, a common engineering change process uses an ECR 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.

   To promote an efficient use of resources, related ECRs may be freely combined into one ECN and (less often) one ECR may be allocated to multiple ECNs.

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

4. 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 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 advising change forms that are not intended to affect the release status of any part. Instead, they provide short-term guidance for managing unusual situations. The two most common announcements are Deviation and Stop Shipment advising changes. These can affect only parts, never documents. Both address a temporary condition:

• Deviations (DEV) and Waivers (WVR) accept a non-conforming part for 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, which expects a future non-conformance, and a Waiver, which allows an existing non-conformance. In most situations, the distinction isn't meaningful; a single change form (perhaps a Non-Conforming Notice or Variance Authorization) is sufficient for handling both.§

• 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 an ECN that revises the current items, or a deviation that contains replacement 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 put aside 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 executing 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 executing change form 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".

This application note was relevant to the PDXpert software release that was current at time of publication. Product changes since that time may affect its utility. We'd be happy to assist you in assessing the applicability of this note to your situation.