Match your manufacturing ERP to how work is released
Describe demand, product definitions and release decisions before selecting manufacturing ERP. Test standard components and order-specific work together.
Start a manufacturing ERP selection by describing what authorizes work to begin and how the product becomes defined. A factory replenishing finished stock has a different planning problem from a shop waiting for an approved drawing on each order. Some businesses do both, sometimes using the same components and equipment.
Give the implementation team representative production paths before asking for a demonstration. A label such as “discrete manufacturing” will not explain which decisions must happen before purchasing, scheduling or release.
Odoo 19 bills of materials describe components and quantities and can include operations. That provides a structure for manufacturing records, but the business still needs to define what is stable, what varies and who may authorize a change. Odoo 19 bills of materials.
Describe the trigger and the unresolved work
Choose three representative orders or use fictional equivalents with the same operating conditions. For each, complete this production-model card.
| Question | Evidence to collect |
|---|---|
| What triggers demand? | Stock policy, accepted customer order or another documented signal |
| What is already defined? | Product identity, approved component list and operation sequence |
| What changes per order? | Dimensions, finish, approved options or a new design |
| What must happen before buying? | Technical approval, quantity decision or supplier confirmation |
| What must happen before production starts? | Material availability, released instructions and responsible approval |
| What can be produced ahead? | Common parts or assemblies that remain usable across orders |
| What proves completion? | Accepted output, inspection evidence and disposition of unfinished work |
Write actual differences in the card. “Custom product” may mean choosing a finish from a controlled list, or it may mean designing a new assembly. Those cases should not automatically receive the same configuration.
Use the manufacturing planning input ledger after this card. The production model establishes which inputs exist and when; the planning ledger checks whether those inputs are credible enough to schedule.
Locate the point where the customer order changes the work
Imagine a fictional manufacturer that makes standard frames for stock but cuts a mounting plate to an approved customer drawing. The frame can be replenished independently. The mounting plate cannot be released until the drawing is accepted. Final assembly needs both.
Ask the proposed ERP to represent those separate conditions. Test whether the planner can see common stock, the order-specific requirement and the outstanding drawing decision without treating the entire product as either fully standard or entirely new.
Do not assume that a sales confirmation is sufficient authorization for every manufacturing operation. Define the release condition the business actually needs, then have the implementer demonstrate it in the proposed configuration. If a separate approval or document-control extension is required, identify it as part of scope.
Distinguish a variant from a new definition
Odoo documents a shared bill of materials with components assigned to particular product variants. This is relevant when the allowed choices can be represented as defined attributes and components. It does not establish that every engineering change or free-form customer request should become a variant. Odoo 19 variant bills of materials.
Give the demonstrator two cases: a permitted standard option and a request outside that option set. Ask how each is identified, approved and released. Inspect the next ordinary order as well. An exception made for one customer should not silently change the shared definition used for others.
This test should include the purchasing and shop-floor users. A configuration that looks tidy to sales may leave production unable to distinguish an approved option from an unresolved instruction.
Write requirements around the transition
A useful requirement names the starting condition, responsible person, action and evidence. For example: “With the customer's drawing still unapproved, the planner can identify the held mounting-plate operation while seeing available standard frames.” That is a proposed acceptance condition, not an assertion about default Odoo behavior.
Include the exception that exposes your operating model: a revised drawing after procurement, a substitute component, or stock allocated to a different order. Use the implementation work-packet method to assign each decision and test.
Finish with a small set of production paths, not a long list of application names. For each path, name what can start, what must wait, the approved product definition and the record that proves the next release. That gives an ERP provider a concrete manufacturing problem to solve.