.png)
Most product lifecycle problems do not begin with a missing bill of materials.
They begin when a product changes and the organization cannot see the full effect of that change. A supplier alters a material. A formula needs revision. A quality result starts to drift. A customer asks for supporting documentation. A product moves from R&D toward scale-up. Each event should be manageable, but only if the organization can connect formulas, sub-recipes, materials, specifications, development evidence, product revisions, and operational handoffs around the same product record.
When those records are fragmented, teams do not lack data. They lack a reliable way to understand what the data means together.
This is especially true in formulation-driven industries. A coating, adhesive, chemical, cosmetic, food product, battery material, or advanced material is not fully described by a flat component list. Its performance depends on ingredient ratios, intermediate blends, properties of the materials used, relevant process conditions, test evidence, specifications, and the development decisions behind the approved version.
The following ten PLM pain points are where that connected product record most often breaks down.
1. BOM Errors and Formula Mismatches
A bill of materials is essential. It identifies the materials, components, quantities, and relationships needed to make a product. But formulation-driven products need more than a flat BOM.
They may include percentage-based recipes, multi-level sub-recipes, intermediate blends, approved alternatives, material-specific properties, unit conversions, and dependencies that affect performance. A small quantity difference, incorrect unit, or outdated material relationship can change the behavior of the finished product. When R&D, Product Lifecycle, and operations maintain separate representations of the formula, those differences can become competing product definitions.
The problem is rarely a single obvious error. It is drift. One team changes an ingredient quantity during development. Another updates an operational structure later. A third team retains an earlier document because it was still valid when they began work. Each record looks reasonable in isolation. Together, they create uncertainty about which formulation is actually approved.
The practical test is simple: can every relevant team identify the current approved formula, its revision status, and the history behind it without reconciling multiple files or systems?
2. R&D Context Disappears Before Scale-Up
The final specification usually moves downstream. The learning that produced it often does not.
During development, a formulation team may discover that a product is sensitive to temperature, order of addition, mixing conditions, raw-material variability, moisture, or a narrow concentration range. It may test several plausible alternatives and learn why they fail. It may see early quality patterns that explain what stable performance looks like before the product reaches larger-scale production.
A transfer report can capture the approved formula and a defined process. It cannot always carry the full development history. When that history remains in laboratory notebooks, experiment records, static reports, and individual memory, manufacturing and quality teams may discover the same sensitivities again through scale-up issues or investigations.
PLM should not be positioned as the owner of production-batch history. QC LIMS and MES retain production and quality-execution records. The PLM role is to preserve the product definition and the development context that helps downstream teams understand why the product was designed and qualified as it was.
3. Product Data Is Scattered Across Systems
A product can be represented in many places. R&D systems hold experiments and formulation work. Quality systems hold specifications and results. ERP holds operational material and product records. Supplier documentation may live in other repositories. Product teams may rely on release packages, PDFs, or spreadsheets that summarize the current state.
Each system can be useful. The problem is that the product is not a single record inside any one of them.
As a result, teams spend time answering questions that should be routine: Which formula revision is current? Which specification applies? Has this material been approved for this product? What changed since the last release? Which test evidence supports the new version? What did R&D learn when it evaluated the alternative ingredient?
When the answers require separate searches and manual comparison, the organization turns reconciliation into a normal part of product work. The cost appears in slower reformulations, slower investigations, slower customer responses, and decisions delayed until someone can confirm the underlying record.
4. Specifications Are Managed as Documents, Not Product Data
A specification is more than a controlled document. It is the link between the approved product definition and the requirements used to assess the product.
That relationship becomes critical when a formula changes. A raw-material substitution, altered concentration, new process range, or product revision may affect the properties quality needs to verify. It may require a revised specification, a different method, a new target, or confirmation that the existing requirements remain appropriate.
When specifications are managed independently from product revisions, that review can be missed. Quality may continue using a specification that was valid for an earlier formulation. Product teams may approve a change without fully assessing the downstream quality implications. The organization may have a controlled document in both cases, but the product-to-specification relationship is weak.
A connected product record makes that relationship explicit. It shows which specification applies to which product and revision, when it became effective, what test methods it references, and what quality evidence is associated with it.
5. Version Control Does Not Explain the Change
A version number tells a team that something changed. It does not tell them why.
A formulation may move from revision 14 to revision 15 because a supplier discontinued a material, a quality issue required a change, a customer requested a different property, a regulatory requirement shifted, or R&D found a better-performing alternative. The revision may also reflect a minor administrative correction. These changes should not be treated as equivalent.
The useful product history is therefore more than a sequence of released files. It captures the decision context: what triggered the revision, which alternatives were evaluated, what testing supported the selected change, which approvals were required, and which related specifications or documents were affected.
This matters long after release. A future formulation scientist may need to understand why a material was removed. A quality investigator may need to know whether an issue appeared before or after a change. A regulatory or customer team may need the evidence behind a statement about the product. A revision history without decision context forces each team to reconstruct the rationale later.
6. A Material Change Becomes a Manual Portfolio Search
A material change is rarely limited to one formula.
A resin, pigment, solvent, polymer, additive, flavor, active, or other raw material can appear directly in finished products and indirectly through intermediate blends. It may be used under different identifiers across sites, in historical revisions, or in products managed by different teams. A supplier issue, cost change, discontinuation, or regulatory decision can therefore become a portfolio-wide question.
Without reliable where-used relationships, teams begin with discovery. They search formulation files, pull ERP reports, ask site experts, compare material names, and attempt to map intermediate blends to finished products. Before they can decide what to do, they must establish where the material appears.
Where-used analysis is not an administrative convenience. It is the first step in understanding the true scope of a material change. A connected product record should allow teams to trace from a material to the formulations, sub-recipes, products, revisions, specifications, and qualification evidence that may be affected.
7. Legacy PLM Does Not Reflect How Formulation Products Are Developed
Many PLM systems were designed around discrete products. They are strong at component hierarchies, engineering changes, configuration control, and released structures. Those are important capabilities, but formulation work has a different set of requirements.
The organization may need to model ingredient ratios, formula versions, intermediate blends, raw-material properties, approved substitutes, process conditions, test results, specifications, and R&D evidence. It may need to compare formulas across experiments, understand the impact of material variability, and preserve the relationship between a released product and the work that qualified it.
A general PLM system may be configurable enough to store these records. The more important buyer question is whether the data model reflects how the organization actually develops its products. If the model forces scientists and product teams to manage critical formulation context outside the system, the product record will fragment no matter how strong the version-control features are.
8. Regulatory and Customer Requests Trigger Reconstruction Work
A customer may ask for product documentation. A regulator may change a requirement. A supplier may issue new material information. A sustainability team may need to assess product composition. A commercial team may need confirmation of what is in a specific product revision.
In each case, the organization needs evidence. Which materials are present? Which revision applies? What specifications and supporting documents are relevant? What supplier information supports the answer? What testing or qualification evidence exists? Which markets or customers are affected?
When this information is distributed across systems, responding becomes a reconstruction project. The organization may be able to answer, but it depends on people searching, interpreting, and aligning records under time pressure.
Connected product data does not replace regulatory expertise or customer judgment. It makes the relationships that experts need easier to retrieve and assess. The first question after a regulatory or customer request is often not what the answer should be. It is where the relevant evidence lives.
9. Knowledge Is Trapped in Static Files and Individual Memory
The final formula is often easier to find than the knowledge behind it.
That knowledge includes the paths that did not work, the process sensitivities that appeared during development, supplier observations, quality context, material interactions, and the tradeoffs that led the team to choose one alternative over another. It is valuable because it can prevent the next team from repeating failed work.
Static reports and attachments can preserve part of this history. They become difficult to use when the organization needs to search across many projects, formulas, materials, and time periods. Individual memory can preserve even more context, but it disappears when people change roles or leave the organization.
PLM adds value when it gives the product a usable history. The goal is not to expose every lab note to every downstream user. It is to keep relevant development evidence connected enough that a future scientist, quality manager, or product owner can understand why the product looks the way it does.
10. ERP Handoffs Create Competing Product Records
ERP is essential for planning, procurement, inventory, costing, and operational transactions. It should not require teams to maintain a separate, competing version of the product definition.
The common failure mode is duplicate maintenance. R&D and product teams maintain one formula. ERP users maintain another operational structure. A change moves through files, exports, or manual re-entry. Over time, each system can become internally consistent while the two records drift apart.
The better operating model is clear about ownership. Product Lifecycle governs the approved product definition, including formulas, revisions, specifications, approval status, and the development context behind the release. ERP receives the approved operational record required to run the business. When the product changes, the next approved revision follows the same controlled handoff.
This does not mean every development detail must move into ERP. It means the product should have one governed definition, with a controlled final-state representation for operations.
Why the Product Needs a Connected Record
These pain points have a common cause. The organization has product information, but it does not stay connected as the product is developed, qualified, revised, and handed downstream.
A connected product record does not replace the systems designed for specialized work. R&D tools remain essential for experiments. Quality systems remain essential for quality execution and governance. ERP remains essential for operational transactions. QC LIMS and MES retain production-batch history.
The role of PLM is to govern the product definition and preserve the relationships between formulas, materials, specifications, development evidence, revisions, and approved downstream handoffs. It turns product history from a set of disconnected files into something the organization can use when the next change arrives.
.png)
.png)
.png)
