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 systems is
almost always faster 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.
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.
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, and "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
- accommodate
change
- accommodate the reuse of standards and best practices
- ensure
that all requirements (all released information) remain clear, concise and
valid
- communicate (1), (2) and (3) to each user promptly and precisely
- 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
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", although their effect on the PLM system's
records are just as lasting as a permanent change.
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. An 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.
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 ECO documents that the items listed on it have been updated and may
be used in accordance with the effectivity dates listed.
The ECO (or ECN) 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 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) or 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 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 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).
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 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 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 PLM 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) separately. However, managing
multiple change workflows can get complicated, since each path from one
lifecycle state to another can be enabled (or not), and have various parties
assigned to be notified. With about 25 different paths defined, each of which
having over a dozen notification parties, maintaining large numbers of unique
workflows can be tedious. Fortunately, PDXpert software lets you
assign a single workflow to more than one change form template.
071117.1125