Can AI Implement PLM for You? Start with Your Company’s Product Data

Every day brings another example of what AI can do. It writes code, reads documents, analyzes spreadsheets, and helps people build applications by describing what they want.

If you are running an engineering or manufacturing company, it is reasonable to ask:

“AI is great. Should I just ask it to implement PLM for me?”

I like the idea. Describe your products, explain how your company works, connect your tools, and let AI help create the environment you need. There is a real opportunity to make product lifecycle management easier to implement and use.

Then the conversation reaches an important wall: your company’s product data.

Where does that data live? Which records should be trusted? How does a CAD assembly relate to the BOM purchasing uses? Which drawing belongs to the revision approved for the next build? Who can decide that a supplier’s alternative is acceptable?

AI can help investigate these questions. Giving it more files does not, by itself, establish the answers. Those answers depend on how your company organizes product information and records its decisions.

This changes how I would approach a PLM system implementation roadmap today. Each step should build a product data foundation that people and AI can use together.

Where an AI-generated PLM application meets your company

Imagine asking an AI assistant to create a simple PLM application. It could help generate an Item table, a BOM editor, document links, and an approval workflow. You could have something useful to explore surprisingly quickly.

Now connect that application to a real product.

Engineering has an assembly in SOLIDWORKS. An electronics partner maintains the controller board in another tool. Firmware lives in a software repository. Purchasing has a spreadsheet with supplier part numbers and prices. A contract manufacturer has a PDF drawing attached to an email.

The housing appears as a CAD file name, an internal Part Number, and a supplier’s quotation line. Engineering has changed the connector opening, but the quotation refers to an earlier drawing.

Ask AI, “What should we order for the next ten units?”

To give a dependable answer, it needs the product definition selected for that build, the applicable component revisions, assembly quantities, sourcing information, and usable inventory information. It also needs to distinguish an accepted change from a proposal still under discussion.

An AI-generated interface becomes useful when the data behind it carries these meanings. Establishing them is a central part of implementing PLM.

AI can help build the foundation while you organize it

Organizing product data can sound like a request to spend months cleaning spreadsheets before doing anything useful. AI creates opportunities to reduce that work.

It can help extract information from documents, propose column mappings, identify possible duplicate records, and surface inconsistent descriptions. These suggestions give the team a starting point for review.

OpenBOM’s AI-powered PDF drawing import illustrates this approach. It recognizes product information in drawings and prepares structured Items and BOM data for user review and confirmation.  OpenBOM’s integrations with CAD and other systems provide additional ways to bring information into the connected product model.

The practical approach is to organize a useful slice of product information, use AI to help prepare and examine it, resolve the important questions, and keep the accepted results connected to their sources. That provides a foundation for the next task and the next product.

Here is how I would reshape the implementation roadmap around that work.

Step 0: Choose the first job and the data it needs

Start with a specific result. For example: prepare the approved product information and component requirements for a ten-unit prototype build.

This gives the implementation a clear boundary. Identify the assembly, its component structure, the design sources, the applicable revisions, and the people responsible for engineering acceptance and purchasing.

Then define the questions the team must be able to answer. Which product definition are we building? What quantities are required? Which components lack usable sourcing information? Which drawings are ready to share?

The output is a defined product-data scope with named owners and a measurable business result.

AI can help draft the plan and identify information the task may require. The people responsible for the build confirm its scope and acceptance criteria.

Step 1: Map the sources and establish their authority

Inventory the information needed for that first job. For each record or important property, identify its source, owner, identifier, and update path.

A practical source map might look like this:

Authority can differ by property. Engineering can own the product definition while purchasing owns supplier commercial information. An ERP system can remain responsible for inventory transactions.

Keep unresolved questions visible. Two records with similar descriptions might represent the same component, different configurations, or acceptable alternatives. AI can propose a match; the responsible owner confirms what the relationship means.

The output is a source and ownership map, with explicit exceptions requiring decisions.

This follows the approach described in planning a modern PLM implementation: organize the data and its governance, then connect the services that use it.

Step 2: Turn files and spreadsheet rows into connected product records

Once the sources are understood, organize the information into a model that represents the product.

An Item provides a reusable engineering identity. A BOM describes how Items are used in an assembly, including their quantities. Drawings, design sources, revisions, and supplier records supply additional context.

These distinctions matter. A motor can appear in several products with different quantities. Its reusable properties belong to the Item; the quantity belongs to its use in a particular assembly. A CAD file can also represent several configured Items, while one Item can have several design representations.

OpenBOM’s Design BOM and Engineering BOM model preserves these distinctions. Design dependencies and file states remain distinguishable from engineering Items and their uses in the product.

OpenBOM catalogs organize reusable Item definitions, while BOMs describe product structures. The catalog and product-structure onboarding approach helps explain how existing Excel information can be organized into this model.

For the housing example, the goal is to connect the housing Item, its use in the assembly, the engineering revision, and the supporting design and drawing. A supplier quotation must then be associated with the definition it actually covers.

The output is a connected product definition with meaningful identities and relationships.

This gives AI a basis for investigating a change without repeatedly reconstructing the product from file names and spreadsheet descriptions.

Step 3: Define how the information changes and who can act

The foundation must remain useful after the first import.

Define how a design update reaches the engineering product record. Decide which changes require review, who can approve them, and how downstream users identify the definition accepted for their work.

Keep a working file version distinguishable from a released engineering revision. The newest design work may still be under review, while purchasing is preparing an order against an earlier approved definition.

For each connected system, establish which records and properties it can update. Include a path for conflicting values, failed updates, and missing source information. Test those exceptions during implementation.

Apply the same discipline to AI-assisted actions. An agent preparing a proposed change needs a different authority from a person approving its release. Granting access to a tool should preserve the company’s permissions and approval requirements.

OpenBOM’s Engineering Frontend connects design sources with engineering product information through configurable models, supported integrations, references, and APIs. Its sharing capabilities let teams collaborate on selected records while defining who maintains and accepts each contribution.

The output is a repeatable way to update, review, release, and share product information while preserving responsibility.

Step 4: Prove the foundation with one real product

Run the selected product through the complete scenario. Include a meaningful change and a downstream handoff.

For example, revise the housing’s connector opening, update the associated engineering definition, review the change, and give purchasing the information needed to request an updated quotation.

Check whether the team can establish:

• Which housing Item and revision the change affects.
• Which assemblies use that Item.
• Which design state and drawing support the accepted revision.
• Whether the existing supplier quotation covers the changed definition.
• Which unresolved issues require an owner before purchasing proceeds.

Ask AI to help explain findings or prepare a review summary. Assess the result against the underlying records and agreed rules. A useful answer should make its evidence and missing information understandable.

OpenBOM BOM Review provides a practical place to examine product data. Its deterministic check cards evaluate explicit rules, while AI BOM Health adds observations for investigation. AI BOM Health requires an AI subscription add-on; its findings support reviewer judgment rather than constituting release approval.

The output is evidence that the team can complete a real handoff using the connected records and resolve the exceptions it encounters.

Step 5: Expand the foundation and make ownership part of daily work

Add the next product family, user group, or handoff once the first scenario works. Reuse the established identities, property definitions, source mappings, and release rules where they apply.

Different disciplines will need different information. A PCB component and a machined housing can have different properties while participating in the same product definition.

Train people using the tasks they actually perform: adding an Item, reviewing a change, preparing a supplier package, or investigating a missing property. Assign ongoing responsibility for resolving duplicates, maintaining mappings, and reviewing recurring data problems.

Measure whether people can identify the applicable revision, follow a change, and complete purchasing work without manually rebuilding the product structure. When an export is needed, make its revision and purpose clear so the team can distinguish it from the maintained record.

The output is an operating product-data practice that can support more products and more automation.

Why OpenBOM is the right foundation for this approach

For a growing manufacturer connecting engineering, purchasing, and suppliers, I believe OpenBOM provides the best starting point for this approach. Its value comes from the combination of capabilities needed to organize and use company product data.

A configurable product model gives the data a place to belong. Companies can organize Items, properties, catalogs, BOM types, and views around their products. The knowledge graph connects those records and their relationships, supporting navigation across product structures.

Connections preserve the context of existing tools. Mechanical design, electronics, software, and business systems can contribute through supported integrations, imports, source references, and APIs. The implementation defines the mappings and authority for each connection. Teams can build a shared engineering definition while continuing to use their authoring environments.

Collaboration and lifecycle control make the information usable in daily work. Revisions, changes, approvals, and controlled sharing help connect engineering information with the people who review, source, and purchase it. This is how the foundation stays relevant after the initial data load.

The same foundation supports AI and future applications. OpenBOM exposes supported operations through REST APIs and is extending MCP support for AI interaction with structured product context. These interfaces provide a path for selected assistants and automations to use the maintained model. Each implementation still needs to verify its required operations, mappings, and permissions.

As described in OpenBOM’s platform differentiators, these connections also underpin Product Memory: product information, relationships, revisions, and decisions that remain available as work continues.

Give AI a foundation it can work with

I expect AI to make PLM implementation faster. It can help prepare information, build connections, propose workflows, investigate problems, and make everyday interaction easier.

The practical starting point is one product and one useful job. Organize its data, establish the relationships and responsibilities, and prove that the team can use the result. Let AI help throughout that process.

Then the request becomes much more concrete:

“Here is our connected product information, the definition approved for this build, and the rules our team follows. Help us complete the next job.”

That is the foundation we are building with OpenBOM.

REGISTER FOR FREE, bring your own product data in OpenBOM, and use one engineering-to-purchasing scenario to see how the foundation comes together.

Best, Oleg