Nobody Has a CAD or BOM Creation Problem

Oleg Shilovitsky
Oleg Shilovitsky
6 July, 2026 | 7 min for reading
Nobody Has a CAD or BOM Creation Problem

When companies start looking for better tools to manage product information, the conversation usually begins with a very specific pain.

“We need better BOM management.”

“We need better CAD vault management.”

“Our PDM is not working.”

“We need to connect engineering to ERP.”

“Our spreadsheets are out of control.”

All of these statements are true. But they usually describe symptoms, not the real problem.

Most manufacturing companies do not really have a CAD or BOM problem. They do not only have a PDM problem. They do not only have an ERP problem.

They have a product data flow problem.

A product data flow problem is what happens when product information is created in one system, but must be copied, exported, and re-entered by hand to reach every other team and system that depends on it.

Product data starts in engineering, but it does not stay there. It begins with CAD files, designs, assemblies, drawings, and engineering decisions. Very quickly, that information must be used by many other people and systems across the company. Purchasing needs part numbers, suppliers, costs, and lead times. Manufacturing needs accurate BOMs, approved revisions, and planning information. Finance and ERP systems need clean item records, quantities, costs, and vendor information. Suppliers need enough information to quote, build, and deliver. And customers ultimately depend on the entire company working from the right product information at the right time.

This is where the problem starts.

Product data is created in one place, copied to another, modified in a spreadsheet, shared by email, discussed in meetings, re-entered into purchasing, and eventually typed again into ERP. Every step looks reasonable in the moment. But over time, the flow becomes fragmented.

A CAD assembly becomes an Excel BOM.

An Excel BOM becomes a purchasing spreadsheet.

A purchasing spreadsheet becomes an email thread.

An email thread becomes a manual ERP entry.

A change request becomes a document attached to another email.

A supplier quote becomes another file saved somewhere else.

Soon, nobody is completely sure which version is correct. Engineering has one view. Purchasing has another. ERP has another. Manufacturing works from something slightly different. The company starts spending more time reconciling information than using it.

This is not because people are doing something wrong. It happens because the tools were never designed to support a continuous product data flow.

CAD, Excel, Email, and ERP Create Disconnected Islands

Every manufacturing company uses a combination of tools. CAD is used to design products. Excel is used to organize information. Email is used to communicate. ERP is used to run the business.

Each tool has value. The problem is that each tool usually manages only one part of the product story. CAD knows the design structure, but not always the purchasing reality. Excel can be flexible, but it becomes fragile when it is used as the system of record. Email is convenient, but it hides decisions in conversations that are hard to trace later. ERP is critical for operations, but it is usually not designed to manage early engineering changes, CAD structures, or evolving product definitions.

As a result, companies end up with islands of product information. One island is engineering, another is purchasing, another is inventory, another is ERP, and another is the change process buried in email.

The real challenge is not that any single island is bad. The challenge is that the bridges between them are weak. People become the integration layer. They copy, paste, export, import, check, correct, and explain. This creates delays, mistakes, and a constant dependency on tribal knowledge.

At some point, the company realizes it needs better product data management. It needs more reliable BOM management. It needs a better engineering to manufacturing handoff.

But choosing the right approach is not always simple.

Why Traditional PLM Feels Too Heavy for Growing Teams

For many years, the traditional answer to product data problems was PLM.

In theory, PLM promises to organize everything. Parts, BOMs, revisions, documents, changes, suppliers, processes, and workflows can all be managed in one system. For large enterprises with dedicated implementation teams, this can make sense.

But for many growing manufacturing companies, traditional PLM often feels too heavy. The implementation can take a long time. The data model can be difficult to change. The process can feel rigid. Engineering teams may feel forced into a system that does not match how they work.

Many manufacturers do not have the time, budget, or internal resources to spend months or years implementing a large monolithic PLM system. At the same time, they cannot continue relying on spreadsheets, emails, and manual ERP entry forever.

This creates a gap.

Companies need structure, but not bureaucracy. They need traceability, but not complexity. They need connected product data, but not a massive implementation project. They need a practical PLM alternative that helps them move faster, not slower.

The OpenBOM Approach: Connect the Product Data Flow

OpenBOM was built around a different idea.

OpenBOM provides an online cloud platform that connects the product data flow across engineering, manufacturing, procurement, inventory, suppliers, and ERP.

The goal is not to replace every system a company already uses. The goal is to connect the information that must move between them.

OpenBOM starts where product data begins: in engineering. It connects to CAD systems and helps teams extract product structures, parts, assemblies, files, and related information. From there, CAD files can be stored in cloud design folders, and the data can evolve into structured BOMs, item records, purchasing information, supplier data, cost rollups, inventory planning, change processes, and ERP handoff.

This is the difference between managing isolated documents and managing connected product information.

A BOM is not just a table.

A part is not just a row.

A change is not just an email.

A purchase order is not just a transaction.

Each of these things is connected to the product, the people, the process, and the history of decisions that brought the product to where it is today.

When product data flows correctly, teams can answer important questions faster. What changed? Which BOM is current? Which supplier is approved? What needs to be ordered? What is already in inventory? What should be sent to ERP? Who made the decision, and why?

This is where product data management becomes much more than storing files or managing BOMs. It becomes a connected flow of information that helps the company make better decisions.

Where the Flow Leads

All of this points to a destination. When product data flows without interruption from design to purchasing to production and ERP, a company builds something bigger than a set of connected records. It builds a Product Memory: a persistent, explainable record of what the product is, how it changed, and why. I will come back to this idea at the end of the week.

This Week: Five Short Examples

This post opens a five-part series: a five-minute tour of OpenBOM, from CAD files to product data flow.

This week I will share five short examples showing how OpenBOM connects CAD, BOMs, changes, procurement, inventory, and ERP into one product data flow.

The first step is to stop thinking about the problem as only a BOM problem, a PDM problem, or an ERP problem.

The real problem is the flow.

And when the flow is connected, everything else becomes easier.

Follow the series.

Frequently Asked Questions

What is a product data flow problem?

A product data flow problem happens when product information created in CAD must be manually copied into spreadsheets, emails, purchasing documents, and ERP. Each manual step creates version conflicts and errors. The symptoms look like a BOM problem or a PDM problem, but the root cause is the disconnected flow of product data between teams and systems.

Why do spreadsheets fail for BOM management?

Spreadsheets are flexible, but they have no revision control, no live connection to CAD data, and no shared source of truth. Every copy creates a new version, and changes travel by email. As a product grows in complexity, teams spend more time reconciling spreadsheets than using the information in them.

What is a practical PLM alternative for growing manufacturing teams?

A practical PLM alternative connects the tools a company already uses instead of replacing them with one monolithic system. OpenBOM is a cloud platform that connects CAD, BOM management, purchasing, inventory, and ERP into one product data flow, giving teams structure and traceability without a long enterprise implementation project.

How does OpenBOM connect engineering to manufacturing and ERP?

OpenBOM connects to CAD systems to capture product structures, parts, and files. That information becomes structured BOMs, item records, purchasing data, and cost rollups, which are shared with manufacturing and handed off to ERP. Every team works from one connected view of product data instead of manually re-entered copies.

This is part 1 of 5 in the series. Parts 2 through 5 publish Tuesday through Friday and will link back to this post.

REGISTER FOR FREE and check how OpenBOM can help you for 14 days. 

Best, Oleg 

Related Posts

Also on OpenBOM

4 6
16 July, 2026

Every engineering and manufacturing team knows why BOMs must be validated before release. Catching a mistake early is cheap. Catching...

15 July, 2026

Welcome to the OpenBOM July 2026 update! The July 2026 update focuses on helping engineering and manufacturing teams improve BOM...

14 July, 2026

Last week, the global PLM community gathered in Lecce, Italy, for the IFIP 23rd International Conference on Product Lifecycle Management...

10 July, 2026

Revisions, Change Requests, and Change Orders in OpenBOM This article is concluding our five days blog series with OpenBOM Product...

9 July, 2026

Ask an engineering team when the BOM is finished and they will point to the release. Ask a purchasing team...

8 July, 2026

On Monday we said that nobody has a BOM problem. On Tuesday we followed a design out of CAD and...

7 July, 2026

There is a button in every CAD system that engineers know well: export BOM to Excel. It feels productive. In...

6 July, 2026

When companies start looking for better tools to manage product information, the conversation usually begins with a very specific pain....

3 July, 2026

Here is a story I hear almost every week. Engineering export the bill of materials (BOM) in Excel. Procurement works...

To the top