Why Manufacturing Teams Outgrow CAD Files and Spreadsheets (And What They Use Instead)

The five hard problems engineering and manufacturing teams face in 2026, and what it actually takes to solve them.

Engineering and manufacturing teams are navigating a new level of complexity. Products combine mechanical systems, electronics, firmware, connectivity, and increasingly global supply chains. Teams are growing. Supply chains are stretching. Customers are asking for more traceability, faster delivery, and tighter cost control, all at the same time.

Yet the operational challenges slowing teams down are not new. They are not caused by bad decisions or the wrong investments. They are caused by something much more common: the tools that got a company here were never designed to take it further.

Earlier this year we published an analysis of the five hardest problems engineering and manufacturing teams still face in 2026. Engineers, product managers, and operations leaders kept saying the same thing: we know exactly what you are describing, and we are living it right now.

Those five problems point directly to why companies are choosing OpenBOM. This article draws a direct line from the problems to the solution.

OpenBOM is a cloud-based PDM and BOM management platform that connects CAD data, engineering BOMs, procurement, supplier collaboration, and ERP integration in a single connected workspace without the complexity or cost of traditional PLM.

Why do growing engineering teams outgrow CAD files and spreadsheets?

Most engineering teams started the way almost every product company starts. Designs live in CAD tools like SOLIDWORKS, PTC Creo, Onshape Autodesk Inventor, Autodesk Fusion. Files are organized in folders on a shared drive, in Dropbox, in Google Drive. BOMs are maintained in Excel. Purchasing is tracked in a spreadsheet. Supplier communication happens over email. It works. For a focused team with a manageable product, this approach gets things done quickly and with very little overhead.

Then something changes. The product gets more complex. The team grows. A second supplier is added, then a third. A customer asks for documentation that requires tracing a component back through multiple assemblies. Someone joins from a different time zone and cannot find the right version of a file. Engineering and operations start disagreeing about which BOM is current.

The informal system starts to crack, not because anyone did anything wrong, but because the tools were never designed to carry this kind of weight.

Why traditional PLM is not the answer for most teams

At this point, the obvious answer seems to be PLM (Product Lifecycle Management). PLM is exactly what it sounds like: a system designed to manage the full lifecycle of a product, connecting engineering, manufacturing, procurement, and operations in one place.

And yet most growing companies look at traditional PLM platforms and step back. The implementations are long, often measured in months and sometimes even in years. The licensing costs are substantial. The configuration effort requires dedicated services. The promise is compelling; the path to get there is not. Many teams evaluate PLM, decide it is built for a company three times their size, and quietly shelve the idea. Some others do the project, get burned and back to cut their losses. 

Some reach instead for a cloud PDM system, stretch it beyond file management to cover BOMs, change orders, and supplier data. PDM helps. It brings file versions under control, reduces the chaos of shared drives, and gives engineering a more reliable home for CAD data. But PDM was never designed to be the connected layer the company actually needs. It manages the CAD vault. It does not bridge engineering to procurement, connect product structure to ERP, or give suppliers live access to the right data. The gap that matters most, the one between what engineering knows and what the rest of the company can act on, remains.

So the workaround persists.

Product data exists in multiple places, and someone is always manually moving it between them. Always a person. Always a spreadsheet. Always a lag between what engineering knows and what the rest of the company can act on.

The core problem is not any one system. It is the absence of a connected data management layer that holds the whole product together across engineering, procurement, suppliers, and operations. One that is practical enough to adopt, flexible enough to fit how product teams actually work, and powerful enough to scale as the product and the company grow. That is the gap OpenBOM was built to close.

OpenBOM vs. Other Tools

Reason 1: Why do engineers spend so much time searching for CAD files and product data?

The problem

For most engineering teams, product knowledge lives inside files: CAD models, drawings, assembly structures, documentation. When the team is small and the product is simple, this is manageable. As both grow, it becomes a daily friction.

The version question comes up constantly. Which revision is current? Which drawing was sent to the supplier last month? Which BOM reflects the change that went through last week? These questions seem simple. Answering them is not.

According to many researchers and analysts, knowledge workers spend nearly two hours every day searching for information rather than doing productive work — and engineers specifically can spend up to 25% of their working time on information retrieval alone. For a team of 20 engineers, that is the equivalent of five full-time people whose entire output is finding things that should already be findable.

The real problem is not the files themselves. It is that product knowledge stays trapped inside them, rather than existing as structured, connected data that the entire company can navigate.

Why OpenBOM

OpenBOM integrates directly with SOLIDWORKS, Autodesk Inventor, PTC Creo, and other major CAD platforms to capture product data automatically as it is created. BOMs, component relationships, file versions, derivative files (STEP, PDF, DXF, etc) and design dependencies become structured, searchable product information that exists independently of the files themselves.

Engineers can navigate the product structure, trace where a component is used across assemblies, and find the current revision of any item without digging through folder hierarchies. CAD data management and BOM management become a single connected workflow rather than two separate manual processes.

Reason 2: How do you manage BOMs across mechanical, electronics, and software teams?

The problem

Modern products rarely live in a single engineering domain. Mechanical engineers work in MCAD tools like SOLIDWORKS or Creo. Electronics teams use ECAD environments like Altium or KiCad. Software engineers manage code in Git repositories with their own release cycles. Each discipline has tools that work well within their domain, and that remain largely invisible to the others.

In practice this means a company often has several parallel views of the same product. The mechanical BOM lives in one place. The electronics component list lives somewhere else. The manufacturing BOM (MBOM) may not exist in a structured form at all, assembled manually when production needs it. These structures evolve at different speeds and are updated by different people. When a change happens in one domain, the others may not know for days or weeks.

Why OpenBOM

OpenBOM manages multi-disciplinary product structures – mechanical BOMs, electronic BOMs, software and product structures that all components in a single connected workspace. As designs change in any domain, BOMs update in real time. Revisions, alternates, cost rollups, and product structure are managed together, not in separate systems that drift apart.

Teams get a shared, accurate view of the product regardless of which CAD or engineering tools they work in.

Reason 3: How can engineering teams catch supply chain problems before the design is locked?

The problem

For a long time, supply chain was something procurement handled after engineering finished the design. That separation is no longer viable.

Component availability, lead times, minimum order quantities, and price volatility are now part of engineering decisions, whether engineering teams have easy access to that information or not. When a design calls for a component with a 26-week lead time, the right moment to know that is before the design is locked, not after.

But in most team environments, that information is not integrated into engineering workflows. It lives in a procurement spreadsheet, in a supplier email thread, or in someone’s memory. According to industry research, many manufacturers still rely on spreadsheet-driven workflows for sourcing and cost analysis. When supply chain problems surface late in development, they force last-minute redesigns and supplier renegotiations under time pressure, exactly the conditions that stretch timelines and compress margins.

Why OpenBOM

OpenBOM connects procurement data directly to the BOM. Engineers and procurement teams work from the same product structure. RFQs, purchase orders, supplier lists, and cost rollups are built from the BOM rather than assembled separately in spreadsheets.

Lead times, sourcing alternatives, and supplier data can be tracked alongside the components they describe, making supply chain risk visible during design — when it is still inexpensive to respond — rather than after the product is released.

Reason 4: How do you get clean product data into ERP without manual re-entry?

The problem

Not every team has an ERP or financial system for procurement, but many growing companies reach a point where one becomes necessary to manage purchasing, inventory, and manufacturing operations. When that moment comes, the gap between how engineering manages product data and what ERP systems need to consume it becomes immediately and painfully visible.

ERP and financial systems (NetSuite, Dynamics, Odoo, Quickbooks, Xero, and others) need structured item masters, manufacturing BOMs, and cost data in specific formats. What engineering typically has is a collection of CAD-derived BOMs, spreadsheets, and revision histories that were never organized for operational consumption.

Bridging that gap becomes a recurring manual effort. Someone exports from engineering, reformats in Excel, and imports into ERP. When a revision happens, the cycle repeats. According to many researchers, poor data quality costs organizations significant mistakes and the source is almost always the handoff between disconnected systems.

Why OpenBOM

OpenBOM structures product data in a form that ERP systems can consume directly: clean item masters, manufacturing BOMs, and cost data organized for operational handoff. The ERP integration workflow is built into the product rather than bolted on afterward.

For teams without ERP yet, OpenBOM provides the structured product data foundation that makes that transition straightforward when the time comes. For teams that already have ERP, it eliminates the recurring reconciliation work that currently sits between engineering and operations.

Reason 5: How do you share live product data with contract manufacturers without sending stale files?

The problem

Most manufacturing teams work with external partners: contract manufacturers, suppliers, specialized fabricators. Getting product information to those partners and keeping it current is one of the most consistently painful parts of the process.

The typical workflow: export a BOM, paste it into a spreadsheet, attach a set of drawings to an email, and send. The supplier works from that package. If engineering changes something the next day, the supplier does not know unless someone remembers to send another email.

Suppliers build to outdated specifications. Quality issues trace back to a drawing that was superseded weeks earlier. Traceability becomes a forensic exercise rather than a living record. As manufacturing ecosystems become more distributed and product complexity increases, this collaboration problem becomes increasingly visible and costly.

Why OpenBOM

OpenBOM allows engineering teams to share controlled product information with contract manufacturers and suppliers directly through the platform, not through file attachments. External partners see current product data. When a revision happens, the update is visible without requiring a manual re-send.

Traceability is maintained because the data stays connected to the source. There is no static export that begins to age the moment it is sent.

Reason 6: Is your product data ready for AI workflows?

The problem

This is the reason that did not exist five years ago, and the one that will increasingly separate companies that move quickly from those that do not.

AI tools are beginning to change how engineering teams interact with product data. The potential is real: agents that review a BOM and flag issues before release, identify supply chain risks proactively, automate routine data capture from CAD tools, and support decisions across the product lifecycle.

But AI tools require structured, connected product data that spans the full product context. As long as product knowledge lives inside CAD files, disconnected spreadsheets, and email threads, AI tools cannot access the context they need to be genuinely useful. They can process isolated documents. They cannot reason across a product. The technology is arriving faster than most teams expect. The data foundation is not yet in place for most organizations.

Why OpenBOM

OpenBOM’s Product Memory is the structured, connected record of a product that accumulates as teams design, revise, procure, and manufacture. As CAD data is captured, as BOMs are created and revised, as changes are approved and procurement decisions are made, OpenBOM builds a product knowledge base that AI agents can actually work with.

That product memory is the foundation for OpenBOM’s AI-assisted workflows: the BOM Review Agent that analyzes product structures and surfaces issues before release, the CAD File Agent that automates data capture inside SOLIDWORKS and other CAD environments, and future agents that reason across components, suppliers, costs, changes, and manufacturing requirements in ways that are impossible when product data is scattered across files and spreadsheets.

What connects all six reasons

Each reason traces back to the same moment: a growing team, an increasingly complex product, and a set of tools (CAD, shared drives, spreadsheets, email) that worked well at one scale and started to crack at the next.

The symptoms look different on the surface. Files that are hard to find. BOMs that drift out of sync. Supply chain surprises that arrive too late. ERP handoffs that require manual reconciliation. Suppliers working from outdated drawings. The inability to apply AI tools to product decisions.

But the root cause is the same: product data that exists in fragments, owned by no single system, moved between people by hand.

OpenBOM is the collaborative workspace and product data platform that closes that gap, connecting CAD data, engineering BOMs, procurement, supplier collaboration, and ERP integration in a single workspace that grows with the product and the team.

The five hard problems are real. They have persisted not because teams made the wrong choices, but because the tools they had were never designed to carry product data across an entire organization. OpenBOM was.

Frequently asked questions

What is BOM management software?

BOM management software is a tool that organizes a product’s bill of materials (its components, quantities, relationships, revisions, and costs) in a structured, connected format that engineering, procurement, and manufacturing teams can all work from. Unlike spreadsheets, BOM management software tracks changes in real time, connects to CAD tools like SOLIDWORKS and Fusion, and links component data to purchasing and ERP workflows. OpenBOM is a cloud-based BOM management platform designed for engineering and manufacturing teams.

What is the difference between PDM and PLM?

PDM (Product Data Management) focuses on controlling CAD files, drawings, and BOMs in a managed vault. It solves the version control and file storage problem, but does not connect product data to procurement, suppliers, or ERP. PLM (Product Lifecycle Management) extends that to cover the full product lifecycle including change management, procurement workflows, supplier collaboration, and ERP integration. Most growing companies find PDM too narrow for their needs and traditional PLM too complex, expensive, and slow to implement. OpenBOM sits between the two, providing connected product data management and BOM management without PLM’s implementation overhead.

Does OpenBOM work with SOLIDWORKS and Fusion?

Yes. OpenBOM integrates directly with SOLIDWORKS, Autodesk Fusion 360, PTC Creo, and other major CAD platforms. The integrations capture BOM data and file structures automatically from the CAD environment, keeping the BOM synchronized with design changes and eliminating manual re-entry. The CAD File Agent extends this further, enabling automated data capture and management directly inside the CAD tool.

How does OpenBOM connect to ERP systems?

OpenBOM structures engineering BOMs and item data in a format that ERP systems can consume directly and provide a connected mechanism to exchange sync data with all common ERP platforms including NetSuite, Odoo, Dynamics, QuickBooks, Xero, and others. Manufacturing BOMs and item masters are organized for operational handoff as a natural output of the engineering process, not as a separate cleanup task.

Can OpenBOM replace Excel for BOM management?

Yes. OpenBOM is designed to replace spreadsheet-based BOM workflows. It provides real-time BOM editing, revision control, multi-user collaboration, CAD integration, cost rollups, and supplier sharing, capabilities that spreadsheets cannot support at scale. Teams typically migrate from Excel when BOMs become too complex to manage manually, when errors in spreadsheets start causing production problems, or when supplier and ERP handoffs become too time-consuming to sustain.

What is Product Memory in OpenBOM?

Product Memory is a rich context layer OpenBOM helps to organize to represent a structured, connected record of a product that accumulates as teams design, revise, procure, and manufacture. It has a flexible data model organization and includes component data, BOM history, change records, supplier information, and cost data, all linked and searchable. Product Memory is the data foundation that enables AI agents to assist with BOM review, CAD data capture, supply chain analysis, and decision-making across the product lifecycle. It is what makes the transition from file-based product management to AI-assisted product workflows possible.

Is OpenBOM a PLM alternative?

OpenBOM is not a direct PLM replacement for companies that need the full depth of enterprise PLM platforms like Siemens Teamcenter or PTC Windchill. It is a practical alternative for teams that need connected product data management, BOM management, PDM, procurement workflows, and ERP integration without the multi-year implementation timelines and enterprise licensing costs of traditional PLM. Many teams use OpenBOM as their primary product data platform, while others use it alongside or as a stepping stone toward broader PLM adoption.Ready to see how OpenBOM works for your team?

Start a free 14-day trial and check how OpenBOM can help.

Best, Oleg