
Change is the only constant.... a tired cliche, sure, but painfully true on the manufacturing floor. Whether you're building cars, circuit boards, or coffee makers, you’re bound to face design tweaks, supplier swaps, or feature upgrades. Enter Dynamics 365 Finance & Operations’ Engineering Change Management (ECM), the module that transforms those wild change ideas into controlled, traceable actions.
No need to grab a wrench, just your coffee and maybe a sense of humor. Let’s dive in!
Change Requests vs. Change Orders: A Quick Primer
Before we jump into the step-by-step, let’s clarify the two stars of our show:
Engineering Change Request (ECR): This is the idea stage of a change. It’s a proposal to modify a product or process, raised by anyone in the organization—an engineer, a quality inspector, a procurement clerk who can’t get the old parts anymore, even Sales if a customer suggests an improvement. The Change Request captures the what and why of a potential change (description, priority, category, etc.). Think of it as the suggestion box entry (but one that won’t get lost). A change request doesn’t directly alter anything; it’s reviewed, discussed, and approved (or politely declined) via a workflow.
Engineering Change Order (ECO): This is the action stage of a change. Once a change request is vetted and approved, it is converted into a Change Order—the official vehicle to implement the change in the system. The Change Order modifies product data (BOMs, formulas, drawings, etc.) in a structured, traceable way. No rogue cowboy changes allowed—it’s all tracked and controlled.
In simpler terms: Request = "Can we change this?", Order = "Yes, we will change this, here’s how."Â
The journey from one to the other involves a few checkpoints, much like getting sign-off from all the parents before a school field trip. Let’s walk through that journey step by step.
The Step-by-Step Journey from Change Request to Change Order
1. Initiating the Change Request
Every change starts with someone spotting a need or opportunity. An issue on the production line, a supplier sending an end-of-life notice for a component, a customer requesting a new feature—all these can spark an ECR. In D365, creating a Change Request is straightforward: users can navigate to the ECM module or even initiate it directly from a product’s page. They fill in key details like title, priority, and category to help classify it.
Example: A procurement clerk in an automotive company learns that a certain alloy used in engine parts will soon be unavailable. They initiate a change request to switch to a different alloy and mark it as urgent.
2. Review and Triage
Once submitted, the change request triggers a review process. D365 routes the request to the right people (often a product owner or engineering manager) for evaluation. This is where the engineering change committee (formal or informal) assesses the request: Does this change make sense? What’s the impact? Is it a minor tweak or a major redesign?
3. Impact Analysis (Avoiding Nasty Surprises)
A smart reviewer does an impact analysis before approving the request. D365 F&O's ECM has a handy feature for this: Business impact analysis for open transactions. While the change request is under review, the reviewer can search for any open sales orders, production orders, or inventory that involve the product in question.
Example: If our proposed alloy change affects a component currently used in dozens of open production orders, the engineering team might decide to block those orders from proceeding until the new part is ready, preventing rework or scrap.
4. Approval of the Change Request
If the request is sound, the responsible manager(s) approve it via workflow, flipping the request status from "Created" to "Approved." If the request is rejected (maybe someone suggested adding a cup holder to a server rack), it might be sent back for more info.
5. Creating a Change Order
With an approved ECR in hand, the engineering team converts it into an Engineering Change Order. D365 F&O makes this easy—there's a function to create an ECO directly from the request record. Now, the Change Order becomes the detailed execution plan.
6. Detailing and Implementing the Change (Inside the ECO)
The Change Order defines the scope and specifics of the change:
Updates BOMs, formulas, or routing.
Specifies whether it’s a minor tweak or a new version of the product.
Assigns Reason Codes (e.g., "Supplier Change" or "Design Improvement").
Attaches documents (drawings, test reports, regulatory approvals).
Determines effectivity (immediate? phased rollout?).
7. Approving the Change Order
Just like the ECR, the ECO goes through an approval process, often involving multiple stakeholders—engineering, manufacturing, finance, and procurement. D365's workflow can be configured for parallel or sequential approvals, ensuring proper oversight before changes go live.
8. Processing the Change Order (Executing the Change)
Once approved, the ECO is processed, applying all modifications to the live product data:
New versions go into effect.
BOMs update to include new components.
MRP (Master Planning) adjusts procurement for the new material.
Shop floor workers receive updated assembly instructions.
9. Communicating and Closing the Loop
A truly successful engineering change doesn’t end until everyone downstream knows about it. The ECM process should include notifying all stakeholders that the change has been implemented.
Example: A weekly engineering change summary email can help ensure production, procurement, and sales teams stay informed.
Best Practices for Managing Change Requests in D365 ECM
Encourage a Culture of Continuous Improvement:Â Make it easy for any department to submit change requests.
Define Clear Workflows:Â Separate approval paths for minor vs. major changes.
Assess Impact Early: Use D365’s impact analysis tools to avoid surprises.
Communicate, Communicate, Communicate:Â Ensure production, procurement, and sales teams know about approved changes.
Document the Rationale:Â Use fields and attachments to create a knowledge trail.
Use Version Control Wisely:Â Decide when to create a new version vs. an in-place update.
Train and Audit the Process:Â Ensure users follow workflows correctly and monitor for bottlenecks.
And there we have it—the life story of a Change Request growing up into a Change Order, told DynamicsDad style. Managing change is no small feat, but with a clear process and the right tools, it’s absolutely doable.
Until next time, remember: change is inevitable, but unmanaged change is optional—so keep it under control and keep it dynamic.
Over and out,
DynamicsDad