Work through a supplier change from request to release. Keep current revisions, stock decisions and unfinished production clear at every step.
Sign in to explore the example in Jodoo. Screens show fictional manufacturing records.
| Term | Purpose | Do not confuse it with |
|---|---|---|
| ECR: engineering change request | Propose a change and explain why it should be assessed. | Permission to start using a changed part or instruction. |
| ECO: engineering change order | Define the authorized scope and implementation work. | Proof that every affected item is already effective. |
| ECN: engineering change notice | Communicate the effective change and who or what it applies to. | A substitute for unresolved technical decisions or implementation evidence. |
Companies use these labels differently. Your procedure may combine documents or use other names. Keep the underlying decisions distinct, and make sure the people changing production understand which one they have received.
In the fictional example, the team wants to qualify an alternate supplier for bracket BRK-104, currently revision B. The requester records the business reason, proposed change and qualification evidence. Engineering should not have to guess which drawing or item the proposal concerns.
Separate immediate containment from the permanent change. If current material is unsafe or nonconforming, follow the applicable quality procedure while the engineering assessment proceeds.
Engineering decides whether the request is specific enough to assess. Return it if the scope or evidence is missing. Acceptance allows preparation of an order; it does not tell purchasing or production to switch.
Use the engineering change request form to keep the proposal and its review connected.
The bracket moves from B to C; the assembly instruction needs its own revision change. Review quality, manufacturing and purchasing impacts. Identify which functions actually need to contribute rather than using the same review list for every category.
Record the 40 brackets in stock separately from the 12 units in work in progress. Purchasing’s pending run-out decision must not disappear because manufacturing has already agreed a rework method.
Agree the item-level scope, dispositions, responsibilities and planned cutover. Check the substance of the functional assessments, not only the number completed. Decide which actions are release-critical.
The ECO template provides a structure for these decisions. Keep the current revision unchanged while the work is being prepared.
Update the required instructions, complete qualification or inspection, resolve material disposition and brief the relevant people. Assign each action and review its evidence. In the App’s drawing-change example, a first-off inspection waits for a replacement gauge; order authorization does not make that task complete.
Use a document-control process for revised instructions and acknowledgements. The engineering change App records the release decision; it does not replace that separate document lifecycle. If an implementation result is unacceptable, return it for correction rather than making a critical action optional to meet a deadline.
Identify the item, revision and operational boundary now taking effect. Check that the current revision still matches the starting point and that the required work has been verified. Retain the original-to-released history and communicate the effective instruction to those using it.
The example records an effective release; it does not schedule future activation. If multiple items must change atomically, or another system owns their revisions, design and validate that control separately.
| Role | Decision or work | Evidence to retain |
|---|---|---|
| Requester | Explain the problem and the proposed change. | Current item, reason, supporting information and corrections. |
| Engineering reviewer | Assess technical suitability and affected scope. | Review rationale and proposed revisions. |
| Functional reviewers | Resolve quality, supply and manufacturing impacts. | Each function’s findings and disposition decisions. |
| Implementation owner | Perform the assigned change work. | Result, completion evidence and exceptions. |
| Release reviewer | Confirm readiness and the effective boundary. | Reviewed release and retained revision history. |
| Change coordinator | Follow up missing decisions and keep the work connected. | Outstanding reviews, critical actions and escalation notes. |
One person may hold several roles in a small team, but the procedure should still show which decision they are making. Configure native task assignments and permissions to match the agreed responsibilities before live use.
Reassess the proposal against the new current revision. Do not apply an old before-and-after instruction blindly. Explain whether the proposal is superseded, needs to be revised, or can be combined with the other change.
Keep the stock decision open and make the delay visible to the coordinator. Determine what work can proceed safely without assuming that material disposition has been approved.
Return the action with a specific correction. Preserve the failed result and subsequent evidence so the final release decision is understandable.
Contain the issue and use a traceable corrective change or approved reversal procedure. Do not erase the earlier release or reuse a revision label in a way that makes historical records ambiguous.
| Measure | How to define it | How to interpret it |
|---|---|---|
| Review turnaround | Decision timestamp minus submission timestamp, for each review type. | Separate time waiting for information from time waiting for a reviewer. |
| Request return rate | Requests returned for correction ÷ requests reviewed in the same cohort. | A high rate may indicate unclear form questions or insufficient evidence—not simply poor requester performance. |
| Release-critical backlog | Count of open critical implementation actions, grouped by order and due date. | Distinguish authorized-but-blocked work from changes still being assessed. |
| Implementation lead time | Effective release timestamp minus order authorization timestamp. | Compare similar change categories; a drawing correction and a supplier qualification are not equivalent workloads. |
These are definitions for your reporting design, not claimed results from the example. Decide the cohort, calendar and treatment of cancelled changes before comparing periods. A dashboard should help the team choose an action, not merely display a large number.
Choose one part or instruction with a known current revision and a small group of reviewers. Walk through a normal case, a returned request and a blocked implementation action. Ask a production user to identify the effective revision and explain what happens to old stock without asking the coordinator for help.
Adapt the Jodoo fields, categories and views only where the actual procedure needs them. Keep CAD control, ERP transactions and regulated validation in scope for the appropriate systems and specialists. Expand after the first team can use the process reliably.
Give requesters the information structure needed for assessment.
Plan the affected items, dispositions and implementation.
Choose software that supports your actual control requirements.
No. The labels vary. What matters is distinguishing the proposal, the authorized implementation scope and communication of the effective change. If your company uses one document, its stages and decision responsibilities still need to make those distinctions clear.
Assign one coordinator to keep the change moving, but leave technical and functional decisions with the people qualified to make them. Purchasing can confirm supply and run-out; it should not become the default approver of engineering suitability.
Define the difference between release-critical work and follow-up that may legitimately continue afterward. For example, verifying a changed inspection method may be critical while reviewing longer-term supplier performance may not. Record the rationale rather than marking all actions optional to meet a date.
Contain the issue under the appropriate quality procedure and assess the released revision through a new, traceable change or approved reversal process. Do not erase the previous release evidence or silently restore an old revision number.
Start with one part or instruction change, a small review group and a clear handoff to production. Include a returned request or blocked implementation task, not only a smooth success. Expand after the team can explain which revision is current and why.
