Engineering Changes (ECR, ECO, ECN) and how they should be Structured

Hello all,

I am looking for some insight on how engineering changes should be structured (I am in the medical device arena, so keep that in mind).

I have searched on here and found several other threads on the ECR process, along with some example forms and such. Nothing too in depth and nothing that really seems to fit the mold of what I think may be the approach the FDA is seeking these days....

Anyway, it is evident that we are doing our process backwards, using ECOs for BOM changes only, DCOs for document changes only -- which is fine. But when it comes to everything else, drawing changes, product changes, etc., we are using an ECR form that is filled out to post-changes and used like a notification that a change was made. Essentially, it is missing all of the step leading up to the change and the change is made without input upfront.

After looking into this some more, I came to the conclusion that many most med device companies all use a different logic and approach when it comes to engineering changes.

It appears that the approach most are using is incorporating the ECR, ECO, and ECN acronyms in the following way:

1) ECR to document the origination of the request, suggested ways to address or fix the problem, what items would have to change to fix it, and signoffs to say the suggestions are approved and to move forward with the ECO process.

2) ECO to document the items that may need to change as a result of the ECR (drawings, technical specs, SOPs, etc). Implementation of these changes and approvals. Note: Not all ECOs are required to originate from an ECR and the ECO processes may be an independent processes, such as the DCO process for SOPs and such.

3) ECN to notify the appropriate or interested parties when the ECO change(s) are complete. (could be rolled into the backend of the ECO form I suppose)

Note: We do not have an automated way of doing the changes, no electronic signoffs. The form would have to be filled out and routed and signed physically.

Is the approach of using ECR, ECO, and ECN common?

I have seen others only using ECR and ECN or just ECO and ECN.

Any help would be appreciated!

Hi, NickyD! Welcome to The Cove!

There's no reason the system you've described cannot work, as long as you use the documentation correctly. Instead of waiting to the end to fill in everything, start with the Request and let it follow your process.

Our company (small electronics mfr, but not medical) uses one form, which we call ECR/N. We use it as a Request, it follows the process, monitored by the Quality Manager (me), and when completed serves as our Notice of any change.

Because of the potential impacts, medical device really needs the planning and review cycles to lock in a bullet-proof process. Change can be a significant hurdle, so you must be able to justify it. Without electronic distribution, there certainly are some additional difficulties, but it can be managed.

You might find the following article link helpful...


http://www.arenasolutions.com/resources/articles/engineering-change-order

The ABCs of Engineering Change Orders

The stages of the engineering change process are:

1. Issue identification & scoping:
Someone identifies a problem or issue and determines that it may require a change. The scope of the issue and its possible impact are estimated.

2. ECR creation:
An engineering change request (ECR) is created to examine the necessity and feasibility of the change, to identify parts, components and documentation that might be affected, to estimate costs and to list the resources required to implement the change.

3. ECR review:
The ECR is circulated for review and discussion among key stakeholders and is modified as needed.

4. ECO creation:
Once the ECR is approved, an engineering change order (ECO) is generated, which lists the items, assemblies and documentation being changed and includes any updated drawings, CAD files, standard operating procedures (SOPs) or manufacturing work instructions (MWIs) required to make a decision about the change.

5. ECO review:
The ECO is then circulated to a change review board made up of all stakeholders (including external partners when appropriate) who need to approve the change.

6. ECN circulation:
Once the ECO has been approved, an engineering change notification/notice (ECN) is sent to affected individuals to let them know that the ECO has been approved and the change should now be implemented.

7. Change implementation:
Those responsible for implementation use the information in the ECO and ECN to make the requested change.

While an engineering change order is used for changes that are executed by engineering, other types of change orders may be used by other departments. These include the:

Manufacturing change order (MCO) ?
A change order describing modifications to the manufacturing process or equipment.

Document change order (DCO) ?
A change order detailing modifications to documents, specifications or SOPs.

Engineering Change Orders: Paper-based vs. electronic software systems...

The article continues...

Conclusion

Companies need to be able to adapt quickly in today?s constantly changing environment, and often that means making changes to their products. Engineers make modifications during development and production with the intent of adding functionality, improving manufacturing performance or addressing the availability of a particular part.

To make sure proposed changes are appropriately reviewed, a solid process is critical?especially if members of your product team are scattered across multiple locations (for instance, design engineers in Boston, the manufacturing team in St. Louis and component manufacturers all over the world). At the heart of a solid change process is the engineering change order.

I guess there is a lot of information out there how people are managing changes and you should be able to find or put together something that will suit your needs. I just wanted to point out that there is more to it than merely regulatory requirements. Of course you need to have everything documented well and made sure there are no adverse consequences on the product etc. But for a business changes are a perfect opportunity to burn money if they are not planned well and can be initiated by anyone without prior approval. That the implementation of a change needs approval is a regulatory requirement and when this does not happen all the ressources invested up to the time of disapproval is wasted. E.g. you may miss some acceptance criteria of the necessary testing, the change takes so long that it is outdated when the time of approval comes, management decides it wants a more cost-efficient solution for a problem... All this can happen when you have a change process based only on regulatory requirements and not take into account business requirements (of course if there is a conflict, regulatory requirements have priority). Or you have very good design or process based reasons for a change with no regulatory or quality issues whatever and then your customer just does not like it. Or he likes it so much, that your inventory of the old version just became worthless...

@PaulJSmith

Thanks! That makes sense. I was also looking at having the notification rolled into one of the forms so that you dont have all these separate forms, being that outside the scope of DMR and SOP changes, most will be done by hard copy routing.

@Wilderness Woody

Thanks for the info, I had pulled some info from that website which initially got me thinking about the ECR-ECO-ECN flow of how changes should be done. It just seems like everyone does them differently and uses the acronyms slightly different. Especially our company, who uses only an "ECR" form to document all changes outside the scope of the BOM (anything in SAP). Outside observers have noted that we are doing the process backwards.

Paul,
I agree with you on making ECR/ECN one form can make it simpler in most situations.
If it doesn't go past request stage fine, but if it goes further it is your ECN.