Designing your engineering change workflow

Part 2: Engineering change workflow design

In our previous discussion, we defined various engineering change forms and how they're used (the engineering change process). In this topic, we'll discuss how each type of change form is created, reviewed and approved (the engineering change form's workflow). In our final topic, we'll show how to configure your new engineering change process within PDXpert PLM software.

Engineering change workflow: required tasks

Each engineering change workflow has two essential activities:

1. Create the change form, and send it to the appropriate authority for approval
2. That authority accepts or rejects the change

This pair of workflow activities is resolved into four distinct change lifecycle states:

1. Originate (create) the change form, and then
2. Route the change form to the appropriate reviewer(s) for a decision, who must
3. Approve and release the change form, or
4. Disapprove and stop the change

This workflow can be applied to both an implementing change form (an ECN) that releases item revisions, as well as to a non-implementing change form, such as an Engineering Change Request, that simply communicates the proposed change's impact.

Engineering change workflow: additional tasks

Other activities may be defined within a change workflow to ensure that the change form's content is "clear, concise and valid"¹. These include

• a pre-routing verification that the change form provides adequate descriptions, appropriate reviewers, and an accurate list of affected items
• holding the change back from further review while a question is pending
• a post-routing, pre-release verification that reviewers' comments have not compromised the validity of the review
• options for handling a disapproved change by reworking, deleting or archiving it

These additional change lifecycle states generally require the support of separate change analysts, who can manage the change through its workflow and re-direct it as necessary to ensure the change conforms to accepted practices.

For example, you may want your Configuration Management analyst to review the accuracy and completeness of all originated changes prior to the routing for approval; furthermore, you may want the analyst to rework all disapproved change forms over $10,000 and cancel (delete) any lower-value changes.

Engineering change workflow participation

A change review requires a specific responsibility, not a specfic person. Persons may be assigned responsibility, and later replaced. The change workflow remains consistent as people change.

There can be significant debate about the appropriate number of people necessary to approve a change form. Increasing the number of reviewers increases the time required to review a change. Moreover, there's an unexpected problem with having an extensive list of reviewers: as the list grows, accountability falls. If the list is large enough, almost certainly you will discover that (1) every reviewer becomes overwhelmed with the number of changes that must be reviewed, and (2) any reviewer can comfortably approve a change without careful review because "someone else will catch any problem".

If a reviewer is not accountable for the outcome of the change form's approval, then the reviewer should be re-assigned as an observer. Instead, a very effective rule is:

Each affected item on a change form has two — and only two — principal actors: the information's author and the information's consumer. If they both agree on the information, including another reviewer is unlikely to change the outcome.

With relatively few exceptions, it's both necessary and sufficient that a fabrication drawing is reviewed by the mechanical engineer who designed the part, and the machinist who fabricates the part. By identifying the pair of stakeholders for each affected item, the list of reviewers can be easily determined.

Engineering change workflow specialization

There's infinite variety of business rules that can influence a change form's workflow. However, the resulting changes generally fall into two groups: changes that have a greater or lesser financial impact to the company, and changes that affect one technical discipline rather than another.

Rather than specifying the approval groups in the change form template, each change may need to be tailored on a case-by-case basis. In a financial assessment, for example, an expensive re-tooling may require the Finance Department to approve the change, or a proposal that is likely to be under $1000 would not require an ECR. Similarly, a change that revises a software binary file may not require review by the Electronics team.

If the exact review process depends upon a complex set of business rules, the originator may be required to submit the change to an analyst to ensure that all appropriate functions are included in the reviewer list. In this case, there may be no reason to add any reviewers to the change form template unless there is one group (e.g. Program Managers) that always participates in every change workflow.

Notes

1. The Institute of Configuration Management defines its CMII as a closed-loop communication process. "Pre-requisites include (1) clear, concise and valid communication of requirements and (2) proof that the intended results were achieved." Course IV: Closed-Loop and Fast-Track Change Process

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.