Why AI Workflows in PLM Start With Business Objects

Last week I was at the Share PLM Summit. AI was everywhere: in the keynotes, in the vendor demos, in the workshop sessions, in the mingling conversations between sessions. The energy was real, and the conversations were genuinely useful. People are thinking seriously about what AI means for PLM, and that is a good starting point.

But starting points need next steps.

Most of the discussions were still at the level of “where can we use AI?” The demos were mostly chat interfaces and document summaries. These are legitimate entry points, but they leave the harder operational question unanswered: how do you use AI for a specific workflow, and how do you redefine that workflow so AI actually changes how the work gets done, not just how it gets described?

At the AI workshop I was part of, I added a comment that tried to name what comes next. Before you can talk seriously about AI in any PLM workflow, three things have to happen. First, find the data. Second, define or redefine the workflow. Third, build the context for AI to operate in.

Those three steps sound simple – read about it in my article yesterday. But when I came back and started thinking about why they are so consistently skipped, I kept landing on the same answer: most companies have not identified the business objects their workflows are built on. And without that, neither the data question nor the workflow redesign question can be answered seriously.

Business objects are the missing prerequisite. That is what this article is about.

Do Not Start With the Prompt. Start With the Object.

Many AI projects begin with a prompt. The team asks: what can we ask the AI to do? Can it summarize this BOM? Can it review this change request? Can it generate an ECO description? These are reasonable experiments, but they are not the foundation of an AI workflow.

A better starting point is this: what business object is this workflow built around?

In PLM, work does not happen in the abstract. People don’t just “do change management.” They change a part, revise a drawing, update a BOM, approve a supplier, release a manufacturing structure, or resolve a quality issue. Each of these activities is centered on objects. Each object has properties, relationships, history, and consequences.

A part is an object. A BOM is an object. A supplier part is an object. A drawing is an object. A requirement is an object. An ECO is an object. An approval is an object.

If AI does not understand these objects, it cannot meaningfully participate in the workflow. It can generate language about the workflow. It cannot help run it. This is the difference between AI as a writing assistant and AI as a workflow participant.

PLM Workflows Are Object-Driven

Take engineering change as an example. A change is not just a form or an approval process. It is a network of business objects.

A change may start with a problem report, a customer complaint, a supplier issue, or a manufacturing problem. The change touches one or more affected parts. These parts belong to assemblies. The assemblies are represented in BOMs. The parts are connected to CAD files and drawings. They may have approved suppliers, manufacturer part numbers, costs, inventory, and lead times. They may be used in released products, active customer orders, or service configurations.

So when someone says, “Let’s use AI to help with engineering change,” the first question should not be: “Which model should we use?” The first question should be: “Which objects define the change workflow?”

The same is true for BOM review. A BOM review is not just looking at a table. It involves items, quantities, revisions, sourcing status, approved vendors, alternates, costs, lead times, compliance attributes, CAD references, drawings, and open issues. The same is true for procurement. The same is true for manufacturing handoff. These are not text workflows. They are object workflows. And that is why they are difficult to automate with generic AI.

The Missing Step: Object Discovery

I think one of the most consistently skipped practices in AI implementation for PLM is what I would call object discovery.

Before designing an agent, before writing prompts, before connecting APIs, the team needs to identify the business objects involved in the workflow. The questions are practical:

What object starts the workflow? What objects are created, modified, reviewed, or approved? What properties define each object? Where does each object live today? Who owns it? What relationships connect it to other objects? What decisions are made based on it? What actions require human approval?

This is not an academic exercise. It is the foundation of AI workflow implementation. If a company wants to build an AI workflow for BOM release, it needs to identify the objects that define release readiness. If a company wants to build an AI workflow for engineering change, it needs to identify affected items, BOMs, drawings, revisions, approvals, inventory, manufacturing plans, and customer impact. Without this object discovery step, AI projects tend to become demos: impressive outputs with no clear path into production.

Relationships Matter More Than Objects Alone

Identifying objects is only the first step. The real value comes from relationships.

A part number alone tells very little. To understand the part, AI needs to know where it is used, which BOMs include it, which CAD file defines it, which drawing documents it, which supplier provides it, which ECO changed it, and which manufacturing plan consumes it.

A BOM alone is not enough. AI needs to know which items are missing sourcing data, which items have no approved supplier, which items have cost or lead time risk, and which items changed since the last revision.

This is where AI needs context. We often talk about AI “understanding” data, but in enterprise PLM workflows, understanding means knowing how objects are connected and what those connections mean for the work. If a supplier part is obsolete, what engineering items are affected? If a drawing is not released, what BOMs cannot be approved? If a cost target is exceeded, what assemblies are impacted? These are relationship questions. AI cannot answer them reliably from disconnected files and generic prompts. It needs a connected object model.

A Practical Example: BOM Review

Let’s make this concrete. A company wants to build an AI workflow for BOM review before release.

A generic AI approach might start by exporting the BOM to a spreadsheet and asking a model to review it. This can produce some useful observations, but it is limited. The model sees a table, not a workflow.

A business-object approach starts differently. First, identify the objects: BOM, items, assemblies, CAD files, drawings, supplier parts, manufacturer part numbers, approved vendors, cost, lead time, revision status, compliance attributes, open issues, approval state. Then define relationships: which items belong to which BOM, which CAD files define which items, which suppliers are approved, which items are missing sourcing data, which approvals are still open.

Now AI can do something useful. It can identify parts without approved suppliers. It can flag items missing drawings. It can find components with cost or lead-time risk. It can detect missing compliance attributes. It can summarize what changed since the previous revision. It can prepare a release-readiness report and create tasks for humans.

This is not AI summarization. This is AI participating in a workflow. The business objects and relationships are available.

Why Traditional PLM Implementations Struggle Here

The problem is not that companies have no product data. Most PLM implementations contain important objects: parts, BOMs, CAD files, revisions, changes, and approvals. So why is AI so difficult to apply?

Because the data is fragmented, rigid, and often disconnected from the reality of daily work. Some data lives in CAD and PDM. Some lives in ERP. Some in spreadsheets. Some in supplier portals. Some in emails. Even when the data exists inside PLM, it can be difficult to adapt the model to a new workflow. Many implementations were designed around predefined processes and hard-coded schemas not built for a world where companies need to rapidly experiment with AI workflows and continuously evolve their context model.

This creates a gap. AI needs context, but the context is not always available in a form AI can use. The data exists, but it is not connected. The objects exist, but the relationships are not explicit. The history exists, but the reasoning behind decisions is often missing.

Flexible Data Model as the AI Workflow Foundation

Every company has slightly different workflows, and every company defines its objects a little differently. One company’s engineering item is not exactly the same as another’s. Supplier approval, cost review, and manufacturing handoff vary across industries and organizations. This is why flexibility matters.

To build AI workflows, companies need a way to define the business objects that matter to them and connect those objects in ways that reflect their real work. Companies also need to change and extend this model without launching a multi-year PLM reimplementation.

This is where OpenBOM’s flexible data model becomes important. It is not just a convenience for BOM management. It can become a way to model the objects that define the business workflow: engineering items, manufacturing items, supplier parts, change records, procurement data, compliance attributes, approval states, cost targets, and others. Once these objects are connected, OpenBOM creates a context foundation for AI workflows. The AI agent is no longer operating against disconnected files and exports. It works with a structured representation of how the business actually operates.

From Business Objects to Product Memory

When business objects, relationships, decisions, and history are connected, they become something more powerful than a database. They become Product Memory.

Product Memory is the context that explains not only what the product is, but how it got there: why decisions were made, what changed, who approved it, what alternatives were considered, and what downstream consequences followed. This is the foundation AI needs to move from answering questions to participating in product development and manufacturing workflows. AI without Product Memory is forced to infer context from disconnected fragments. AI with Product Memory can reason about product structure, change impact, sourcing risk, release readiness, and missing information.

Where to Start

The practical framework is straightforward, and it connects directly to the three steps I named at the Share PLM Summit.

Finding the data starts with object discovery: identify the objects involved in one specific workflow, define their properties, understand where they live today. Redefining the workflow means asking what AI can read, suggest, prepare, escalate, or route. What must remain under human control stays with humans. Building the context means connecting those objects into a structured model before you introduce the model.

This sequence matters. If you start with AI, you get a demo. If you start with objects and relationships, you can build a workflow.

Before your company can have an AI strategy for PLM, it needs a business object strategy. That is the foundation everything else is built on. OpenBOM’s flexible data model gives you a practical place to start: define the objects that matter to your specific workflows, connect them with the relationships that reflect how your business actually works, and create the context foundation your AI workflows will need. The intelligence comes later. The objects come first.

Register for free to check how you can build business objects with OpenBOM. 

Best, Oleg