A formulation can look finished long before its product record is under control.
The lab has tested it. The ingredients are known. It may have passed stability, performance, and quality checks. Yet the bill of materials may sit separately from the formula. Cost may be maintained elsewhere. And no one may be able to say with confidence which product version is current across R&D, quality, and manufacturing.
For products made from recipes, that is not simply a documentation problem. It is a product-definition problem.
It is also a product data and data management problem. The information that defines the product is often fragmented across formula files, BOMs, specifications, cost records, test data, and local spreadsheets. When those records do not remain connected, teams spend time reconciling information instead of developing, approving, and improving products.
A coating, adhesive, cosmetic, food or beverage product, specialty chemical, or formulated material is not simply an assembly of components. Its ingredients must balance in defined proportions. Some ingredients are themselves sub-recipes. A raw material may appear in many finished products. One change can affect cost, specifications, quality work, compliance, and every product that uses that material.
The best PLM for formulation-based products represents those relationships naturally. It does not force teams to maintain the real recipe somewhere outside the system.
Why a Parts Model Can Fall Short
Many PLM systems were designed for discrete products, such as equipment, electronics, vehicles, and manufactured assemblies. In those environments, the bill of materials is usually a hierarchy of parts, quantities, assemblies, and subassemblies. The central challenge is controlling product structure and engineering changes across those relationships.
Formulated products follow a different logic.
A recipe contains ingredients expressed as percentages, concentrations, or formulation units. If one ingredient changes, another may need to change to keep the formula balanced. Product performance can also depend on raw-material grade, order of addition, process conditions, packaging, test methods, and the intended application.
A conventional, parts-based BOM can often be configured to store some formulation data. But the real test is whether the system still works the way scientists, quality teams, and manufacturing teams need to manage the recipe.
The warning signs are familiar:
- The formula is stored as a static attachment instead of structured product data.
- Sub-recipes are flattened into a long ingredient list.
- Costs do not roll up in a way formulators recognize.
- The working formulation lives in spreadsheets because the official BOM is difficult to use.
- Product versions exist, but teams cannot see what changed in the formula or why.
- R&D, quality, and manufacturing maintain separate versions of the same product information.
- Specifications sit outside the formulation record, making it harder to confirm which requirements apply to which version.
A PLM system can have a long feature list and still be a poor fit if its core product model does not reflect how formulation-based products are actually developed, tested, approved, and manufactured.
Start With the Formulation Record
In a formulation PLM, the recipe should be a first-class product record.
Recipe management and specification management need to work from the same structured record. Teams should be able to see the approved recipe, its ingredients and proportions, the specifications that apply to it, and the revision history that explains how it changed.
That record should include ingredients, amounts, units, concentrations, supplier grades, process context, specifications, and revision history. The formula should not be a PDF or spreadsheet attached to a generic product record. An attachment cannot easily show the relationships that matter when the product changes.
This becomes especially important during reformulation.
If a preservative moves from 0.5 percent to 0.7 percent, the product composition must remain valid. If a supplier material changes, teams need to know whether its grade, specification, regulatory status, or performance profile is still appropriate. If a product has several regional or customer variants, the organization needs to see which versions are affected before beginning an impact assessment.
The formulation record should answer those questions directly. It should not create another system that requires manual reconciliation.
A Formulation-Aware BOM Is Not a Flat Ingredient List
A bill of materials should answer a basic question: what is in this product?
For an assembly, a flat or hierarchical parts list may be sufficient. For a formulation, it often is not.
A flat ingredient list can show what was present in a formula at one point in time. It does not necessarily preserve the fact that ingredients are proportions that must balance, that they have functional relationships, or that some ingredients are themselves controlled recipes.
Consider a finished coating containing a thickener and a defoamer, each managed as a separate formulation. Flattening those materials into one long list of ingredients hides the actual recipe hierarchy. Teams lose visibility into the version, source, cost, process context, and use of each intermediate.
The BOM needs to retain that structure. It should show the finished product, the sub-recipes within it, and the components within those sub-recipes. When an intermediate changes, teams should immediately see every affected finished product. They should not have to reconstruct those relationships manually.
This matters across coatings, adhesives, polymer compounds, food and beverage products, food bases, masterbatches, fragrances, and personal-care formulations. A beverage product, for example, may rely on managed bases, concentrates, flavors, or other intermediate recipes. The product structure needs to match how the product is developed and manufactured, not merely how a generic BOM can be configured.
Cost Should Roll Up From the Recipe
Cost often lives in ERP or procurement systems. But product and R&D teams still need a clear view of the cost of the formulation they are developing or changing.
A formulation PLM should connect ingredient costs to the recipe and roll those costs through sub-recipes to the finished product. Teams can then see a current, formula-based cost without rebuilding the calculation in a spreadsheet every time an ingredient price or concentration changes.
This does not replace finance, budgeting, or pricing decisions. It provides a reliable product record that reflects what is actually in the formulation.
In Uncountable’s coating demo, held ingredient costs roll up to a finished-formula cost of $1.99 per kilogram. If the unit cost of one component changes by 5.07 percent, the finished-product cost can reflect that impact through the connected formula structure.
The point is not the specific figures. Cost stays connected to the current recipe and its version, rather than living in a separate calculation that may no longer match the formula being developed or approved.
Where-Used Analysis Prevents Portfolio Surprises
Raw materials rarely belong to one product.
A resin, pigment, preservative, additive, flavor, surfactant, or active ingredient may appear across multiple formulas. When its cost, availability, specification, supplier approval, or regulatory status changes, the first question is often not, “What does this mean for this one product?”
It is, “Where else do we use it?”
A formulation-aware PLM should answer that question directly from the raw-material record. The record should connect to every formula, sub-recipe, product variant, and approved finished product in which the material is used. Teams should be able to identify the scope of a change before they begin testing, notifications, or controlled change activities.
Teams may also need to collaborate with suppliers to confirm a change, obtain updated specifications or compliance documentation, and determine whether further testing is required. That work is far easier when the organization can see the full portfolio impact before starting the conversation.
In Uncountable’s current demo, an acrylic resin appears in 38 products. The important point is not the number itself. It is that the relationship is stored as structured data. A team can see the affected portfolio from the ingredient record instead of opening individual BOMs or asking every product owner to check local files.
This becomes critical when a supplier discontinues a material or a new restriction affects an ingredient. Without where-used relationships, the organization starts with a manual search. With them, it can start with an accurate impact scope and make more deliberate decisions about testing, reformulation, customer communication, and change control.
Keep Recipe Development Connected to PLM
Recipe development generates the evidence that explains why a formulation was selected, adjusted, approved, or rejected. That evidence is part of the development process. It should not become disconnected once the product moves beyond the lab.
R&D needs access to the experiments, observations, process conditions, and test results that explain why a formula was developed in a particular way. Quality needs to know which formulation revision and specification applied when a test result falls outside its expected range. Manufacturing needs the approved formula, process requirements, and work instructions needed to make the product consistently.
Those records should not become three disconnected versions of the same product.
A formulation-native platform keeps development, quality, and lifecycle context connected. It allows teams to manage the approved formula and BOM while retaining the experimental and quality evidence behind the version in use. That creates a more reliable handoff from lab to plant. It also makes future reformulation, root-cause analysis, and audit preparation less dependent on institutional memory.
Uncountable’s PLM connects formulations, bills of materials, test data, process parameters, documentation, revisions, and production context in one product record. This helps R&D, quality, and manufacturing teams work from the same governed information throughout the product lifecycle.
Compare the Right PLM Categories
Different PLM categories can be appropriate for different product-development models. The goal is not to find a universally best system. It is to determine whether the system represents the product your organization actually makes.
A system can have extensive capabilities and still be a poor fit if its product model does not reflect formulations. The practical question is whether people can complete their daily work in the system without maintaining a separate, unofficial source of truth.
For formulation manufacturers, the most important evaluation criteria are not limited to document storage, workflow configuration, or a configurable BOM. The system should support connected product data across recipe development, specification management, quality, cost, compliance, and manufacturing.
Test Vendors With a Real Product
Do not begin with a generic feature checklist. Use a real formulation that reflects the complexity your teams manage.
Choose a product with a sub-recipe, a shared raw material, current costs, a recent revision, and supporting test evidence. Then ask the vendor to demonstrate how the system handles the questions that matter:
- Can it show the recipe, quantities, units, and ingredient relationships as structured data?
- Can it preserve a sub-recipe without flattening its composition into the finished-product BOM?
- Can it support recipe management and specification management from the same governed product record?
- Can it roll cost through the recipe hierarchy to a meaningful finished-product value?
- Can it identify every other product that uses a shared material?
- Can it show what changed between two product versions, why the change was made, and what evidence supported it?
- Can R&D, QC, and manufacturing see the appropriate parts of the same product record?
- Can the team assess a supplier, ingredient, or specification change without rebuilding the analysis in spreadsheets?
- Can teams retain the test data, process context, and documentation created during the development process?
- Can the organization collaborate with suppliers through a controlled process when a material, specification, or compliance status changes?
The best PLM demonstration is not a polished workflow designed for a generic product. It is a live test of whether the platform can represent the formula your organization actually makes.
Choose a PLM That Follows the Product
For formulation manufacturers, PLM should not begin when R&D hands over a static recipe. It should carry product data forward with the formulation structure, evidence, specifications, costs, revisions, and relationships intact.
A flat BOM may be enough to list ingredients. It is not enough to manage a living formulation across recipe development, quality, scale-up, manufacturing, and change.
Choose a PLM that lets teams see the real product: the recipe, the hierarchy within it, the specifications that govern it, the evidence behind it, and the portfolio it affects when something changes.
.png)
.png)
.png)
