For those of you who work in industry, I am curious whether your company uses ECOs or another similar form of documentation to execute a change to a product. My company uses the CCF (Change Control Form) process, and personally, I have found it to be very cumbersome. In order to initiate a change, the change request first has to be reviewed by a change control board (CCB), which holds weekly meetings, and often there are multiple follow ups with the CCB to make sure they agree with the proposed change and sign off on it. Once the change request is approved a change notice is created with an implementation plan detailing the tasks that must be completed before the CCF can close. Any changes to this plan must be reviewed and re-approved by the CCB, which also requires filling out an addendum to the form. I understand that all of this is in place to ensure to control the changes being made, but I think the process could definitely be more streamlined. I'm interested to hear your experience with ECOs and/or your company's equivalent document.
I worked in the software development area. Our company would call it the Engineering Change Order for Code Change. There were many change orders depending on whether it was an addition to the code, or enhancement. Sometimes, it would be required to process a change order for even maintenance especially if it would be server maintenance. I remember specifically, the code change order was the most tedious one as it would go through many approvals from top-down since it would involve a whole new invoice with the contractors apart from the existing contract.
The company I currently work for generates ECOs to make specific changes to products or manufacturing processes. Our ECOs are generated in a Product Management System, we currently use Agile but there are others such as OTIS or ADAPTIV. Basically, our ECOs are generated and highlight essentially the description of the change, the justification of the change, and sometimes the risk. If we are changing anything that is a document such as an SOP, Work Instruction, or Batch Record we open a DCO which contains similar fields that an ECO needs. ECO and DCO are separated to ensure there is an easy and organized way to separate changes between the product/manufacturing process vs documentation. To your point, after attaching whatever documents are needed, the ECO is routed for approval and taken to CCB and the changes move from there.
There really isn't a great way to streamline this from my experience, the biggest issue I've seen is people in other departments that are approvers either taking a long period of time to review and approve or after it passes along the Change Order process it gets rejected or demoted by someone and moves back a step.
Our company uses ECOs and refers to them as Change Notices, as these can be originated by non-engineering as well. These CNs serve to make revisions to any document in the Quality Management System, including but not limited to SOPs, device and tooling drawings, manufacturing floor plans, equipment registrations, etc. In order for this to be passed, it must be reviewed and approved by the necessary departments depending on the nature of the change. In general, every CN must be approved by Document Control to check for formatting and consistency across the QMS. Manufacturing Engineering must sign and approve that the changes do not affect the current manufacturing process and if it does, state if it requires a design review. Regulatory, Quality, and Operations must also sign. If one department rejects it, even if the other departments already approved it, the originator of the CN must make the changes and get all of these approvals again. The QMS software we utilize is TrackWise.
The current company that I work for uses ECOs in the form of change notices as Julienne has stated above. The process of implementing a change within an SOP requires engineering to supply a redline and final draft of the suggested changes to document control via a software format known as a CN. Once the CN is approved by document control then only will it route for an approval from one designated reviewer from Regulatory, R&D, Manufacturing and Operations. Then only will document control release the new revision for others to access. However, if the change affects the design input or output of a medical device or procedure then it will require a design change. A design change has four phases, each phase will result in a design review meeting and approval by a design review board. Only after the fourth design review phase completion will the request for change be allowed to processed as either a CN or request for deviation (RFD).
I currently work as a manufacturing engineer at a medical device company. My team is responsible for maintaining the on market device. We use DCPs (Design Change Process) to make any changes to the device, including labeling. People who join our team from other companies really thing that our process is more tedious and elaborate. Recently the president of our division suggested that the business review the process to stream line some activities. Similarly, we have to propose our changes to a change control board (CCB). Once a change has been opened, you must conduct a risk analysis, an initial design review to discuss the verification strategy and any impact to associate Design inputs, conduct verification activities, assess process validation impact, and execute design change activities.
Personally, I can see SOME areas for improvement to streamline the process. But I think a lot of the activities are not overhead but are necessary for traceability and helps us meet thorough expectations of the FDA.
