Odoo PLM: change control for bills of materials and engineering teams

What Odoo PLM actually does

Odoo Product Lifecycle Management (PLM) is an Enterprise app under Inventory & MRP that gives manufacturing teams a systematic way to propose, review, approve, and release product and BoM changes. It spans concept and design through manufacturing and post-launch support, with stakeholder approvals before anything goes live on the production BoM.

PLM does not replace bills of materials or routings. It layers change control on top of the BoMs and routings already owned by the Manufacturing app. The unit of change is the Engineering Change Order (ECO). Work splits into change management (ECOs, ECO types and stages, version control) and project-style collaboration (approvals, chatter, scheduled activities).

Because Odoo PLM sits in the same database as Manufacturing, Quality, Inventory, and Documents, an engineer revising a BoM and a planner consuming that BoM on a Manufacturing Order share one data model. There is no separate PLM database to sync, which is the main reason discrete-manufacturing SMEs adopt Odoo PLM instead of a dual-stack CAD-centric PLM plus ERP integration project.

ECO data model: fields, status, and workflow

Search interest around “engineering change order ECO data model fields status workflow PLM” is asking a concrete question: what is on an ECO record, which statuses move it forward, and when does the production BoM actually change? In Odoo PLM the answer is explicit and BoM-centric.

An ECO is created inside an ECO type (or auto-created from that type’s email alias). The header captures product context, target of change, timing, and description. Stages on the type are the status pipeline—Kanban columns, not a free-text status field—so “status” in Odoo PLM means which stage the ECO currently occupies.

Typical lifecycle: New → In Progress (revise BoM / product) → verification stage with required approvers → Apply Changes → closing stage (often Effective). Apply is the hard transition: the original production BoM is archived, the revised BoM becomes production, the BoM version increments, and pending and future Manufacturing Orders can take the latest version while ongoing orders keep the BoM they started on.

Engineering change orders: the unit of change in Odoo PLM

An Engineering Change Order tracks, implements, and can revert change versions on products and bills of materials. ECOs can be created inside an ECO type, generated from feedback emailed to the type’s alias, or raised from Manufacturing and Shop Floor when operators suggest improvements mid-production.

Two header decisions shape manufacturing impact. Apply on chooses Bill of Materials versus Product only. Effective chooses As soon as possible versus At Date. After that, the revision workflow is deliberately non-destructive until apply.

• →Start Revision creates a copy of the production BoM under a Revision smart button, with the next version number (V2, V3, …).
• →Engineers edit components and operations on that archived copy so the production BoM stays live for open work.
• →BoM Changes and Operation Changes tabs show a colour-coded diff against production: blue added, black unchanged, red removed.
• →Design files (CAD, PDF, images) attach via chatter on the ECO; they land on the production BoM only when the ECO is applied; prior files remain in archived ECOs.
• →After verification approvals, Apply Changes archives the original production BoM, promotes the revised BoM, updates the Version field, and moves the ECO into a closing stage.

ECO types and stages: shaping the change pipeline

Every Odoo ECO belongs to an ECO type, and every type has its own Kanban of stages. That is what separates Odoo PLM from a generic document workflow: you model different change processes for different business situations, each as its own project on the PLM Overview so collaborators only see relevant BoM work.

Common type examples include New Product Introduction, BOM Updates, Component Change, Product Improvement, and Firmware Update. Configure types under PLM → Configuration → ECO Types. An optional email alias on each type auto-generates ECOs into the type’s first stage—useful for operators, suppliers, or quality teams who should not open the full PLM UI.

Stages are user-defined. Defaults of New, In Progress, Validated, and Effective are a solid baseline. Two stage flags do the heavy lifting: verification stages list required approvers (notified when an ECO enters the stage); closing stages with Allow to apply changes are where Apply Changes is used and BoM/operations updates land, with pending and future Manufacturing Orders able to consume the latest BoM version. Put at least one verification stage and one closing stage on every type.

BoM version control and manufacturing-order impact

Odoo PLM version control is BoM-centric. Every applied ECO bumps the BoM version number, and the full revision history sits one click away. Former assembly instructions, components, and design files stay out of the live production BoM but remain accessible for audits and recalls via the ECO history on the BoM.

The ECO smart button on a BoM (visible when PLM is installed) shows responsible user and effective date, supports reverting to a previous version, and helps answer which BoM version was active on a given date—critical for complaints and regulated industries.

Manufacturing impact is designed to avoid mid-job chaos. Odoo’s PLM product behaviour: the latest approved BoM is always shown for new manufacturing work; draft Manufacturing Orders can be updated to the newly approved BoM in one action; existing and ongoing manufacturing orders keep the BoM they already use so open production is not silently rewritten. Concurrent ECOs on the same BoM use Apply Rebase: if production moved while another ECO still targeted an older base, differences appear under Previous Eco Bom Changes and rebase retains already-applied changes without dropping the new ECO’s edits.

Roles, approvals, and who owns each gate

Poor ECO systems fail at people, not fields. A usable Odoo PLM setup names who must approve at each verification stage—engineering for design intent, quality for control points and compliance, production for buildability and capacity, procurement when components or lead times change, and finance when cost impact crosses a threshold you define outside pure PLM.

On a verification stage, add approver lines with Role, User, and Approval Type. At least one approver should use Is required to approve so the ECO cannot leap to Apply Changes on a silent pass. Approvals and discussion live in the ECO chatter so the audit trail is the record, not a side email thread.

Keep the matrix short for SMEs. One engineering approver plus one production or quality gate covers most discrete shops. Add a Change Control Board style multi-stage path only when regulation, multi-plant release, or high scrap risk justifies the latency.

From the shop floor: feedback that becomes an ECO

Odoo PLM is not only an engineering desk tool. Operators can suggest improvements from a Manufacturing Order—for example a new quality-control step that checks for broken components—or attach worksheet feedback with images, PDFs, or docs during production. That suggestion becomes an ECO assigned to the raiser and then follows the normal verification and apply path.

The Quality app is required to configure quality control points used as operation steps on a BoM. Closing that loop matters: a defect at a work center becomes a controlled, approved revision instead of a tribal-knowledge email. The same theme shows up outside Odoo—manufacturers keep asking for controlled BoM change without spreadsheet version trees, and for engineering and operations to stay on one definition of the product.

When Odoo PLM is enough vs enterprise PLM

Enterprise PLM suites (PTC Windchill, Siemens Teamcenter, Dassault-class platforms) are built for multi-CAD vaulting, complex configuration/variant management, deep supplier collaboration, and heavily regulated product structures. For many SMEs that stack is over-featured: the pain is uncontrolled BoM edits, missing approvals, and shop-floor version confusion—not the absence of a full digital thread.

Odoo PLM is usually enough when your primary need is ERP-native BoM and routing change control, ECO types with Kanban stages, role-based approvals, version history with revert, shop-floor feedback into ECOs, and one database with MRP and quality. It is weaker when you need deep multi-CAD PLM as the system of record, multi-site engineering release with CAD-centric workflows, or industry-specific compliance packs that enterprise PLM vendors productize.

A common 2025–2026 pattern for mid-market manufacturers is ERP-native change control first (Odoo PLM or D365 Engineering Change Management), then selective CAD/PDM connectors—not a greenfield Teamcenter/Windchill program before BoM governance exists. Choose enterprise PLM when CAD is the product master and ERP is a consumer; choose Odoo PLM when the manufacturing BoM in ERP is the operational master and engineering change must land cleanly on MOs.

The Dynamics 365 equivalent: Engineering Change Management

For SMEs evaluating both platforms, Microsoft’s counterpart is Engineering Change Management (ECM) inside Dynamics 365 Supply Chain Management. Originally an add-in and on by default since Supply Chain Management version 10.0.36, ECM is an ERP-native PLM layer rather than a standalone CAD PLM product.

Core capabilities include product versioning (with Version as an inventory dimension when the Product dimension - Version configuration key is enabled), engineering change requests (ECRs) and engineering change orders (ECOs) under Engineering change management > Engineering workflows, readiness checks that gate activation, enhanced product release from an engineering company to other legal entities, and lifecycle state control over where a released product can be used. Unique ECO fields on the Microsoft side include engineering change reasons, change description, required special tooling, and engineering material disposition—useful when you need formal disposition of scrap or tooling from a change.

Microsoft does not market a dedicated CAD-level PLM product. Deep CAD/PDM integration usually means third-party PLM on top of D365 ECM. Compared with Odoo’s BoM-diff Kanban model, D365 is stronger on multi-legal-entity release and open-transaction impact analysis (sales, purchase, production, inventory) with notify-and-block patterns.

When each fits an SME

Odoo PLM and D365 ECM solve the same class of problem—controlled engineering change—at different scales. Odoo PLM is BoM-centric, Kanban-driven, and tightly coupled to Manufacturing and Quality in one database. It suits discrete-manufacturing SMEs that need change control without a separate PLM licence stack or a heavy workflow engine.

D365 ECM is enterprise-scale within the Microsoft stack: multi-company release, formal workflows, version-as-inventory-dimension, and process-manufacturing formula change support, with heavier licensing and implementation cost.

The decision rarely reduces to a feature checklist. It turns on legal-entity structure, CAD integration depth, existing ERP footprint, and whether a unified Odoo data model or a mature multi-entity Dynamics platform is the better five-year foundation. Flectic implements both and maps ECO fields, stages, and approvers to how your engineering, quality, and production teams already work.

Frequently asked questions