Formulation PLM vs Discrete PLM: Why a Recipe Isn't a Bill of Parts

Two products can both be "manufactured goods" and still need completely different systems to manage their lifecycle. A gearbox and a gallon of paint are both products with a bill of materials, but the bill of materials means something different in each case, and that difference runs all the way down. Understanding formulation PLM versus discrete PLM is really understanding one thing: a recipe is not a bill of parts, and a system built for one will fight you if you use it for the other.

‍

The discrete model: products as assemblies

Discrete PLM was built for products that are assembled from parts. A laptop, a car, an appliance. The bill of materials is a list of components: this many of that part, that many of another, arranged in a hierarchy of sub assemblies. The parts are discrete, meaning you can count them, and each one has an identity. Lifecycle management here is about engineering change: revising a part, propagating that revision through every assembly that uses it, and keeping the CAD models and documents in sync.

This model is mature and powerful. It runs the largest engineering organizations in the world. It is also a precise fit for the problem it was built for, which is exactly why it fits a different problem badly.

‍

The formulation model: products as recipes

A formulation is not a list of parts. It is a recipe, and it behaves differently in four ways that matter.

First, the quantities are proportions, not counts. Ingredients are percentages that have to sum correctly, and changing one changes the others. You cannot manage a recipe as "three of this and two of that," because the whole point is the balance.

Second, recipes nest as sub recipes that roll up. A finished coating might contain a thickener and a defoamer that are themselves recipes, each with its own composition and its own cost, rolling up into the product above. A discrete BOM nests assemblies; a formulation BOM nests recipes, and the roll up is of composition and cost, not counts.

Third, cost follows composition. The cost of a formulation rolls up from the unit costs of its ingredients through the recipe to a cost per kilogram of the finished product. This is a property held on the record and rolled up from the recipe. It is not the same as budgeting or cost optimization, which are separate jobs; it is simply the recipe's cost expressed the way a formulator thinks about it.

Fourth, where used is chemical, not mechanical. A raw material appears across many products, and when its price or its regulatory status changes, you need to see every product that contains it. In a formulation world, where used is one of the most important relationships in the system.

‍

Where the mismatch shows up

Try to run a formulation on discrete PLM and the friction appears everywhere. Percentages get forced into a parts model. Sub recipes do not roll up cost the way formulators expect. Versions capture that something changed but not the recipe detail of what. And most tellingly, teams give up and maintain their real BOMs as documents in a shared drive, because the system could not hold them naturally. A bill of materials that lives as a PDF is a bill of materials that drifts, because nothing keeps it connected to the ingredient records it depends on.

The reverse mismatch is just as real. You would not run an automotive assembly on a formulation system. The point is not that one model is better. It is that they are different, and the fit has to match the product.

‍

Choosing by the shape of your product

The decision is not about features, it is about what your product fundamentally is. If it is an assembly of countable parts and your lifecycle problem is engineering change and CAD, you want discrete PLM. If it is a recipe, and your lifecycle problem is versioning formulations, rolling up cost, tracing raw materials across products, and keeping development and production in sync, you want formulation PLM, where the recipe is the unit of data and the BOM versions on the record instead of drifting as a document.

Most teams already know which one they are. The trouble comes when a company standardizes on a discrete PLM for its engineered products and then asks its formulation teams to use the same system, because it is already there. That is how formulators end up managing recipes in spreadsheets alongside a PLM that was never built for them. A recipe is not a bill of parts, and the system that manages it should know the difference.