Change

Note System Literature review

PPT Engineering Change management. Overview and best practices.

Focusing on product change management. Change management process: - - - - - Requesting Determining attainability Planning Implementing Evaluating

Vocabulary: - - - - ECO: Engineering Change Order ECR: Engineering Change Request ECN: Engineering Change Notice ECM: Engineering Change Management

Common issues: - - - - - - - - Benefits of improving the CNS can include : - - - - - Simplified and quicker process Eliminate errors Improve collaboration Reduce cots based on miscommunication Paper-free process still working on paper electronic system not integrated with other areas (eg. manufacturing) limited scope (which documents can be changed) Inappropriate flow Long cycle time Supply chain not integrated No ability to measure KPI Limited visibility of change history

Six activities to manage the change, executed by four different roles: - - - - - - Identify potential change (customer) Analyse change request (project manager) Evaluate change (change committee) Plan change (change builder or project manager) Implement change (change builder) Review and close change (project manager)

 Some companies use two systems: - ECM (Engineering Change Management) and PCM (Production CM): PCM steps in when the change has been made in the design and it is handed over to the production, which must update the production data,, order the goods, prepare the shopfloor, etc.

Best practices (SAP): - - - - - having one system which includes ECM and PCM: avoid the throwing over the wall syndrome) down stream groups should be involved in the approval process or at least on the distribution list (know what is coming). Activities that down stream groups need to do are started as soon as possible (do not just start at the release of the change). [Add names of the key individuals involved in the change] [Workflow notifications sent to e-mail]

Further best practices (Arena): - Avoid having files floating in e-mail or folders, use a centralised system

2 systems: Define Easy: Define Change request: - must have an ID, a priority or deadline (optional), a customer, an abstract and related documents. A change request is declarative, i.e. it states what needs to be accomplished, but leaves out how the change should be carried out. (wiki) Submit Evaluate Review Plan ECO Execute

Approve

Execute

Release

Close

More complicated, longer, but reduces the number of errors:

Implement

Release

Review

An engineering change request (ECR) form is used to describe a suggested enhancement or problem with a product. The form initiates the change process it promotes discussions within the organization to help determine the impact of a change and the best possible solution. The ECR form is circulated and reviewed among key stakeholders. It is the predecessor for an engineering change order (ECO), which describes the details of a change and may specify how a change should be implemented (arena) It provides a method to document problems, raise issues, capture responses, propose solutions and define consequences when deferring issues. It captures the action the group wants to take on a particular problem or suggested change. And unlike an ECO, which documents an actual change, an ECR shows the origins of an issue, discussions of options and thoughts behind the action chosen. The information captured on the ECR can often be helpful in the future when looking at past modifications.

Different types of change requests: - Engineering change request (ECR) A change request listing proposed improvements or problems with components or assemblies. - Manufacturing change request (MCR) A change request specifying changes to the manufacturing process or equipment. - Document change request (DCR) A change request detailing changes or problems with documents, specifications or SOPs. - Corrective action request (CAR) A change request documenting a critical problem with a product. - Field failure request (FFR) A change request detailing a problem with the product as observed in the field. - Supplier corrective action request (SCAR) A change request describing something that is wrong with a part, process, or component from a supplier. A Change Request must contain:
- - - - - - - - - - A description of the problem encountered The reason the change is needed A proposed change (optional) The part number(s) affected by the problem The part descriptions The request originators name The change request submission date The key stakeholders names and roles The stakeholders opinion on the change request The disposition action chosen to resolve the original issue

Engineering Change Order: - An engineering change order (ECO) is a documentation packet that outlines the proposed change, lists the product or part(s) that would be affected and requests review and approval from the individuals who would be impacted or charged with implementing the change. ECOs are used to make modifications to components, assemblies, associated documentation and other types of product information (Arena).

- -

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 (Arena). 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. Then the ECN is created and circulated (Arena). Wikipedia: ECO is the same thing as ECN.

Engineering change notice: - Is a form that communicates the details of an approved change to someone who needs to know about the change. It often authorizes a notice recipient to make a change to the design or process, which may include purchasing new materials. A detailed description and an explanation of the change should be captured on the ECN form. The form must contain the list of the items impacted and how to disposition each of them. It should also reference the approved ECO. (Arena) - An Engineering Change Notice (ECN), or Change Notice, is a document which records or authorizes a change to a specific design. The reasons for the change should also be recorded. (wiki) - An ECN must contain at least this information (wiki): o Identification of what needs to be changed. This should include the part number and name of the component and reference to the drawings that show the component in detail or assembly. o Reason(s) for the change. o Description of the change. This includes a drawing of the component before and after the change. Generally, these drawings are only of the detail affected by the change. o List of documents and departments affected by the change. The most important part of making a change is to see that all pertinent groups are notified and all documents updated. o Approval of the change. As with the detail and assembly drawings, the changes must be approved by management. o Instruction about when to introduce the changeimmediately (scrapping current inventory), during the next production run, or at some other milestone.

Managing The Process of Engineering Change Orders: The Case of the Climate Control System in Automobile Development
Coupling between activities: - product/product : between two sub-assemblies of within one subsystem. - Product/process: between one component and the corresponding manufacturing process. These coupling are the origin of the problems in change management. The Four Principles of Engineering change order management (to try to reduce the negative effects of ECOs) : the three first ones are engineering-driven, the fourth is process-driven. The later the change, the higher the cost, the more work there is to be modified. A recommendation such as freeze early and do not allow further changes is note appropriate. The Four principles: Reduce Impact Avoid Changes Detect Problems Speed up the Early Process - Modularity - Avoid - Frontloading by - Congestion - Flexibility in unnecessary technology - Batching tooling changes - Frontloading by - Organisation - Stop fine Organisation tuning Avoid changes: - Spend more time on the first release: some engineers dont give all the information to their colleagues, as they know the component will have to be reworked anyway - It has been shown that a lot of ECOs provide only minor cost savings and do not justify the externalities caused by the change. at some point in the project, it is beneficial to freeze all fine-tuning and only allow necessary changes (quality reasons) Reduce Impact: - Work on product architecture to make the different subsystems as self-contained as possible (avoid the snowball effect) - In the case of manufacturing processes: delay as much as possible the irreversible downstream decisions until enough information is available. Detect ECOs early (=frontloading): - Can be achieved by technical and organisational means - Technological means: do simulation to anticipate problems - Organisation means: Design for Manufacture methods like early reviews with manufacturing

Speed up the ECO process: Problems: o long-response time and non-transparent flow of information. A lot of time spent in the process in non-value added time (most of it is waiting time). o Therefore, long-lived problems (open changes): therefore a lot of changes open at the same time. Changes interact. o The more it waits, the higher the costs of the change Sources of ECO Lead-time problems: - Batching: ECOS are not processed as early as possible but have to wait and are processed in a batch. - Congestion: people have no time to process the ECOs, it waits on their desk. Problem of separation of work. - Organisational issues Managing congestion: - thats a queuing problem. There is an equation to calculate the waiting time compared to the processing time depending on the capacity utilisation of the people processing the ECO.

- Increasing flexibility: provide capacity when it is needed. Can reduce a lot waiting time, as the ECOs are processed when they arrive. - Merging tasks: avoid queuing at each step: everything is done in one go. - Balancing workload: solve the bottleneck problem (one signle activity is slowing down the whole process) - Sharing resources: many people should be able to do the same job, in order to help balancing workload. Managing Batching problems: - Reasons for batching: information (regular meeting times), coordination (eg. Prototype building), setup costs for retooling, mental setups. So batching makes sense in a lot of cases (scale economies) - But the larger the batch size, the longer is the average time between problem detection and implementation (holding costs). - Use the IT system to avoid meetings: the better the IT platform, the easier it is to forward the information without physical meeting (but requires investment). Managing the organisational aspects: Problems: - Cultural differences and lack of process knowledge across group boundaries. - Cultural problem: learn to take care of the time issues. The process must force people to have a look at the processing time and to keep it below a certain level. Make sure time performance is measured. - Misunderstanding between the different departments. They dont all put the same priority level to processing the ECOs. - Lacking awareness of the consequences of ECOs. Solutions: - from coordination to integration: joint working platforms, common activities (visits, conferences) - Set up time incentives. - Exchange meta-information (to avoid cost surprises downstream): eg hole X is crucial for current design and can only be changed at high cost, whereas hole Y can be changed easily (extract from paper).

 Usually, the changed is discussed by a cross-functional engineering change committee. The vendors of PDM systems often provide an EC module. The EC system steps in once the documents are released. In order to reduce the amount of changes companies often treat changes that do not affect the form, fit or function of a part with a simplified EC process. Another way to reduce the lead times for making changes is to classify changes in a more sophisticated way and treat them with different processes depending on the nature and the importance of the change. All functional departments have their own main computer system and the cross-functional nature of the EC process would require integration of many different systems. However, the commercial PDM systems now offer modules for the ECM.

A comparative study of engineering change management in three Swedish engineering companies.

Case studies:

Volvo Car Corporation: - Need an EC coordinator role to simplify the handling of transaction in the product structure and EC system. - ECOs are problem oriented and not parts or document oriented. - Time target is set (Each ECO is connected to an introduction date for manufacturing, which gives a goal to work against). Set priority to the different ECOs. - Different versions of the same ECO (because the manufacturing refuses it for inability to manufacture): due to lack of communication between manufacturing and engineering, feedback is given at a late stage. If for example manufacturing or purchasing could comment on a part during earlier phases of the design, the amount of iterations of the ECO:s would decrease. This could be supported by the viewing and workflow functionalities of the PDM systems. FFV Aerotech: - A lot of checks of all updated documents (+ prototypes) before change is approved. - Instead of having a designated EC coordinator, the ECO:s at FFVA are managed by a handling officer. The role of the officer can to large extend be compared to a designer but the handling officer is additionally responsible for all changes for an object (e.g. HW, SW or regulation) and is also responsible for deciding whether a failure report is correct. - The current computer tools are only used for the creation of data and to send e-mail amongst users. The archive is currently paper-based and all communication of archived documents is by sending paper copies through the internal post office. - An automation of the complete process would be hard to perform in a PDM system, since different documents are treated differently. In order to obtain a process that can be fully supported in a PDM system, a business process reengineering (BPR) can be done CelsiusTech electronics: - The process starts by the evaluation of a failure report and investigation of possible solutions. The suggestions are evaluated by an EC committee, which decides on the proposed measures and writes ECO:s for all affected parts. This is followed by the redesign process, where the change is planned and executed, followed by a review and approval and finally the changed documents are distributed and archived. - The EC committee is a flexible group, which is specially composed for each change proposal. This gives the company the possibility to always gather the most experienced people for each change, thus giving the opportunity of making the correct

decision. - CTE, as most companies in Sweden, have a part oriented system linking one ECO to each part that is to be changed. Analysis: - Use a designer as a reviewer, as the has the skills and knows the product and the change. - VCC have a designated role to manage the administration of ECO and product structures in their legacy system. He/she helps the designer to create an ECO and he is also an important link when the ECO and all documentation is to be released. The introduction of the EC coordinator role is a result of the fact that consultants and less experienced staff have had difficulties when using the system. When the legacy system is replaced by a more easy-to-use process support tool, the role will probably change to manage processes and configurations within the system.

Two types of change: - funded changes (the customer pays for it): the change is usually documented as a purchase order amendment or contract variation order. - unfunded changes In large companies, the change committee might be a properly constitute body that meets regularly in formal meetings. Two key members of the committee: - the design authority (typically the chief engineer) - the inspecting authority (typically quality manager) Questions to examine during committee meeting: - is the change actually possible to make? - Is it a customer-requested change or a self-inflicted change? - What is the estimated cost of the change? - Who will pay for the change? - Is the change really necessary? Why? - How will safety, reliability and performance be affected? - Does the change have an impact on other products with the same components? - Does it create any problem with the work in progress? - Does it create any problem with the stock? - Does it affect already delivered products? - Does it affect any purchasing order? - How much will the resulting delay cost? - What drawings, BoM, work instructions and other documents will have to be modified? A change coordinator is preferable. His tasks include: - registering change and allocating serial numbers - distributing and filing copies of the change documents - following up to ensure all change requests are assessed on time, etc. Change register: provide a base to follow a change request through all its stages. Should provide a search base that allows traceability of all changes. Typical columns:
Change Originators number name Originators department Date request ed Details or title Approved? (yes or no) Date of final Budget distribution change

Project management Dennis Lock

The register should highlight all the requests that are active. Good question to ask: at which point of the process should the formal change procedure be introduced? In this book; ECO=ECR. Any person should be able to make an ECR, as there is no effect until the change has been authorised. Emergency changes: use a streamlined version of the formal modification procedure, which does not bypass any of the essential control points: - write ECR and get it registered by the change coordinator. - Immediate approval, but the drawings must be updated after. The ECR must be seen by the next change committee meeting.