ECR/ECO for Dummies

This time an article explaining the basics of the Engineering Change Request (ECR) and Engineering Change Order (ECO) as they are common processes across many different industries, often named different, either by the customer or by the PLM supplier.

Although with the new social, WEB 2.0 collaboration, we find new and interesting concepts of engineering collaboration, I wanted to make sure also the ‘old’ processes are described and available for those who need a reference to it.

This post is related to some of my previous educational posts, listed here below:

BOM for Dummies: Engineering to Order

BOM for Dummies: Build to Order

BOM for Dummies: Configure to Order

BOM for Dummies: BOM and CAD

Connecting PLM and ERP: Post 1, Post 2, Post 3

The Engineering Change Processes(es)

In a manufacturing organization, there are is a need to manage many changes in different stages of the product lifecycle. In the conceptual phase, it is mainly the requirements and the change of requirements against the customer or market needs that need to be managed.

Later during the design and manufacturing preparation, there are changes to be communicated between the shop floor and engineering department, which are still internal. Here depending on the organizational structure we talk about change notifications to other departments and suppliers as long as the product is not yet released. These changes can often occur ad-hoc and for that reason not embedded in processes

After the release of a product, we need to manage changes in a controlled manner. This is done through engineering change process, where theoretically we have two types of processes:

The Engineering Change Request (ECR)

An engineering change request can start from anywhere in- or outside the organization and can have a certain level of importance. But the process is similar

The start node can be a customer reporting a problem or an enhancement request from the customer for the future. It can be a service engineer reporting a severe problem (to be solved now) or an enhancement request for the future.

It can be someone in production reporting a manufacturing problem (to be solved now) or an enhancement request. It can be a purchasing agent –working in ERP – reporting that a part is no longer available (to be solved now) or that a part becomes obsolete (to be solved in the future)

The analyze node can be a product manager in case it is related to a product enhancement request, it can be a lead engineer in case of issues to be solved immediately and of course it can be a group of people

The Change Control Board (CCB) can be a group of people – product management, production, purchasing, marketing, who decide on what to do with this proposed change. Their decision is based on the analysis done in the previous step.

The CCB has four options.

1. They can request for further analysis, which means the process goes one step back or they can move the process forward.
2. The option with no impact is to decline the ECR, which means there is no economical or marketing reason to implement the requested change. It might be clear that this option is only applicable for an enhancement request and not for a severe issue.
3. In case the request makes sense, it will be approved, but in situations that it is not critical for the current product release, it will be put on hold. This means that only when the product is going to be changed, it will be evaluated if this requested change can be implemented at the same time. Usually at major releases of the product, sometime when the product requires a change, and it is easy to implement.
4. In case of an urgent issue, immediately an (Engineering Change Order) ECO is planned and in case of a severe issue, it might even lead to several ECOs. This means the requested change needs to be implemented and engineering gets the order to implement this request. It might be, depending on the timing, that some other approved ECRs might be combined with this approved ECR as they can be managed in one change.

The Engineering Change Order

An Engineering Change Order is the process to implement a change. An Engineering Change Order can be based on one or more ECRs, depending on the urgency. In general, an ECO can be generalized as follows:

Or in case no new engineering activities are required, the major steps are followed as below – mainly when the change does not affect the engineering definition – which flow will be used to start depends on the result of the ECR:

The execution of the engineering change order contains the following steps:

The start node can be a product manager, engineering manager or lead engineer who defines which ECR(s) are going to be implemented. The implemented ECR’s are the ones approved by the CCB. The ones that required immediate implementation, in case of a critical situation or the ECRs that were approved and on hold in case of a platform update

This is the step where engineering changes are defined and implemented. Often using the CAD system and changing the engineering BOM

The approval node marks the formal approval of the engineering work, which means engineering believes the engineering process has been completed and the design is ready for manufacturing. It is not a formal release as manufacturing engineering can still find issues that require re-engineering due to manufacturing issues

Note: this generic process is only applicable where the engineering definition is separated from the manufacturing definition. This usually happens in Configure To Order or Make to Stock business processes, as the time between engineering change and manufacturing is not extremely critical.

The manufacturing node is important for companies delivering standard or generic products. In this stage the engineering BOM is translated into a manufacturing BOM, changing the engineering definition into a specific definition for manufacturing – in PLM after this stage the MBOM would be released to ERP.

Note: In many companies, the manufacturing definition is not directly visible in the engineering change order process. For two reasons:

1. Engineering is already taking the manufacturing tasks into account, when defining an engineering change. This means the company is working with a kind of hybrid BOM, not 100 % pure an engineering BOM and not 100 % pure a manufacturing BOM. This method is often used in the engineering to order process or in companies where the product definition is very basic (single discipline – understandable impact)
2. Historically companies are used to define their manufacturing BOM in ERP. Engineering provides a BOM, which is used as the base for manufacturing planning in the ERP system. This is a very common situation in many companies and leads to a disconnect between these departments for engineering and manufacturing.

Change Notifications

Change notifications are more used during the go-to-production phase of a product. This happens when between engineering and manufacturing there are several steps defined – engineering release, prototype phase, manufacturing definition. In this case notifications of an upcoming change, an approved changed or discovered issue. As these activities are internal and often need to happen add-hoc they are not supported by processes but by notifications inside PLM systems (and/or connected to email systems)

Some PLM remarks:

• ECRs can be originated from anywhere. From a PDM user, an ERP user, a marketing person, a service engineer and for sure a customer. Which means implementing ECRs completely requires cross domain services between different systems in your company. However the place where information will be collected, reviewed and decided on, is the PLM system – as change requests are affecting the product knowledge (IP) for current and future products
• ECO should always start from the PLM side, planning and implementing an engineering change. After finalization the released data will be pushed to ERP for execution

Next week I will share my thoughts about ‘classic’ PLM, PLM 2.0 and all the new social collaboration . Also I hope to meet you in January in London at the PLM Innovation 2011 congress