Why SolidWorks Data Breaks Down Between Engineering, Procurement, and ERP

In the previous article, I wrote that engineering teams usually do not lose control because CAD design is wrong. The real breakdown starts after product information leaves the design and PDM environment. That was the engineering side of the story. This article takes the next step. Because once that information starts moving through purchasing, ERP, operations, and supplier collaboration, the issue becomes much bigger than BOM management. It becomes a coordination problem for the entire company.

I want to be clear about what I mean by that, because it is easy to read “coordination problem” as a soft, organizational complaint. I mean something more specific and more costly. I mean that correct design data, correctly managed inside SolidWorks and PDM, can still produce late deliveries, incorrect purchase orders, supplier confusion, ERP mismatches, and rework, not because anyone made a technical mistake, but because product information was never built to travel. It was built to describe. And describing a product and executing on it are two very different things.

SolidWorks Is Only Part of Your Product Definition

There is a mental model that is common in engineering organizations, and it goes roughly like this: if the CAD model is right and the drawings are released, the product can be built. That model is not wrong exactly, but it is incomplete in a way that causes real problems.

Products are built from a much wider set of connected information. The engineering BOM is one layer. But procurement needs approved vendors, validated part numbers, lead times, alternates, cost targets, and sourcing status. Operations needs a build-oriented view that may differ from the engineering structure. Finance and ERP need normalized, transaction-ready records that conform to how those systems want to receive and process data. Suppliers and contract manufacturers need controlled packages that give them exactly what they need to quote, fabricate, or assemble, nothing more ambiguous than that.

And modern products add another dimension to this. Mechanical CAD is one input, but most products today also include electrical design, electronics, embedded software, firmware, and externally sourced assemblies. Each of those disciplines has its own design environment, its own file formats, and its own handoff patterns. None of them naturally align with how SolidWorks structures product information, and none of them enter downstream processes through the same path. The result is that the product as it actually exists in the real world is defined by a combination of sources that were never formally connected to each other.

SolidWorks is a critical part of the product definition. It is not the whole operational reality.

Why Your SolidWorks Engineering BOM Is Not Enough for Procurement and Operations

The engineering BOM reflects design intent. It tells you what parts make up the assembly, how they relate to each other structurally, and what the design calls for at the time it was released. That is valuable and necessary. But the moment downstream teams begin working, the engineering BOM becomes a starting point for a series of transformations, and those transformations are where information starts to drift.

Procurement does not just need to know what parts are specified. They need to know which suppliers are approved, which parts have a preferred vendor, what the lead time looks like for a given component in current market conditions, what the cost target is versus the actual quoted price, and whether there are alternates available if the primary source cannot deliver. None of that lives in the engineering BOM. It has to be built separately, usually in a spreadsheet enriched by the purchasing team.

Operations may need a different structure entirely. A manufacturing or assembly BOM often reflects the sequence in which things are built rather than the hierarchy in which they are designed. That is a legitimate transformation, not an error, but it means someone has to create and maintain a separate view of the product structure and keep it synchronized with engineering changes.

ERP and finance systems need something different again. They want clean, approved, normalized item master records. They want part numbers that conform to their naming conventions. They want unit of measure consistency, procurement types, lead time fields populated, costs attached. Raw engineering BOM data, straight out of SolidWorks, is almost never in a state where it can be loaded directly into ERP without significant cleanup and translation. That cleanup takes time and introduces decisions that are made informally, without traceability.

The engineering BOM is correct. It is simply not sufficient for everything that has to happen after it is released.

How Exported SolidWorks BOMs and Spreadsheets Become Your Unofficial Data System

This is where the fragmentation becomes visible. After engineering releases a BOM, the practical motion of data in most companies follows a recognizable pattern.

Someone exports the BOM to Excel. That spreadsheet becomes the working document for procurement. Columns are added for vendor, quote status, lead time, and price. A separate version is created for the supplier package. Someone prepares a PDF set of drawings. STEP files and DXFs are exported for vendors who need geometry. A separate file goes to operations. Another version is prepared for ERP import. Each of these artifacts is created at a point in time, from whatever state the engineering data was in at that moment.

Then engineering changes something. A fastener is changed. A tolerance is updated. A component is replaced because the original part is no longer available. That change propagates through SolidWorks and PDM in a controlled way, because those tools were built for exactly that. But the exported spreadsheets, the PDFs, the STEP files, the supplier packages, and the ERP staging data are now stale. They are not automatically updated. Someone has to notice that a change happened, figure out which downstream artifacts are affected, and manually re-create or update each one.

In practice, that process works inconsistently. Some changes get propagated fully. Others get missed because the person responsible was not aware a change occurred, or because the change seemed minor, or because the timing was bad. The spreadsheet that procurement is working from may be a version behind. The STEP file the supplier has may be two changes old. The ERP item record may reflect a part number that was retired three weeks ago.

The spreadsheet is not just a report in this situation. It has become the informal transport and transformation layer for product information across the company. And because it was never designed to play that role, it plays it badly.

Why SolidWorks-to-ERP Integration Alone Does Not Fix the Problem

A common response to this problem is to say that the answer is integration. Connect SolidWorks to ERP. Automate the data push. Let the systems talk to each other. That is a reasonable goal, and there are tools that help with parts of it. But it does not address the fundamental issue, and in some cases it can create a false sense of resolution.

ERP systems are not waiting to receive raw engineering data. They are waiting to receive structured, approved, normalized, transaction-ready data. When companies attempt direct CAD-to-ERP integration without a coordination layer in between, they often find that the data does not land cleanly. Part numbers need to be reviewed. Item types need to be assigned. Procurement classifications need to be set. Unit of measure has to match the ERP convention. Cost fields need to be populated before purchasing workflows can trigger. None of that happens automatically because a file was pushed.

The problem is not only connectivity. It is translation, timing, normalization, and trust. Those four things require human decisions at various points in the process. The question is whether those decisions are made in a controlled, visible way or in a scattered, informal way. Most companies today make them informally, which means they are made inconsistently, without documentation, and without a clear audit trail.

Multi-disciplinary products make this worse. Mechanical, electrical, and software teams produce information through completely different tools and processes. Mechanical parts come through SolidWorks. Electrical schematics come through ECAD systems. Software components are tracked in version control repositories. When all of that has to come together in ERP, there is no natural unifying structure. Someone has to build and maintain that structure manually, usually by assembling it from multiple spreadsheets and databases that are each maintained separately.

Integration is important and worth pursuing. But integration without a coherent coordination layer in the middle does not eliminate the problem. It automates parts of a process that still has fundamental gaps.

How Supplier Collaboration Breaks Down Without Controlled Product Data

Everything I have described so far happens inside the company. When suppliers and contract manufacturers enter the picture, the same weaknesses become more dangerous.

External partners do not have access to the informal knowledge that keeps things working inside an engineering team. They cannot walk down the hall and ask which version of the STEP file is current. They cannot check the internal chat thread where someone mentioned that the BOM was updated last Tuesday. They work from what they are given, and they work from it literally. If the package they received contains an older drawing, they will quote and build from that drawing. If the BOM they received has a component that was since replaced, they may already have ordered the wrong part.

The typical supplier information package is assembled manually. Someone pulls the BOM into a spreadsheet, attaches the relevant PDFs, exports the 3D files, writes a cover email, and sends the package. Each of those artifacts was current at the moment it was created, but they do not stay current. The BOM, the drawings, and the geometry may have been created at different points in time and may reflect slightly different states of the product. The supplier has no way to know that. From their perspective, the package is the truth.

This is where informal coordination breaks down in ways that have direct cost consequences. A supplier quotes based on a component that has since been replaced. A contract manufacturer begins fabrication on a part that is under an active engineering change. A PCB house manufactures to a Gerber that was superseded. These are not rare edge cases. They happen regularly in companies that rely on manually assembled supplier packages, and they produce expedite costs, scrap, delays, and rework that are almost never traced back to the root cause, which is the absence of controlled information handoff.

Formal control of what is sent outside the company is not a bureaucratic preference. It is a risk management requirement. And it is very difficult to implement that control when the information itself has no connected home.

Engineering Change Management Across Procurement, ERP, and Suppliers Is Where Things Fall Apart

Engineering changes are a normal part of product development. They are not a sign that something went wrong. They are a sign that the team is learning and improving the design. The problem is not that changes happen. The problem is that change propagation across the full set of downstream consumers is structurally fragile in most companies.

When an engineering change is processed through SolidWorks PDM, it is captured in the context of the design environment. The model is updated. The drawing is revised. The BOM reflects the new state. That part works reasonably well because PDM was built for it.

But the change does not automatically reach the procurement spreadsheet. It does not automatically update the supplier package. It does not automatically trigger a revision to the ERP item master. It does not automatically flag the open purchase orders that may now be pointing to a component that has been revised or replaced. Each of those downstream consumers has to be identified, notified, and updated through a process that is mostly manual and mostly dependent on someone remembering to do it.

In practice, this means that the time between when engineering makes a change and when all downstream parties are working from the updated information is unpredictable. Sometimes it is hours. Sometimes it is days. Sometimes the update never reaches a particular consumer, and the discrepancy is only discovered when a supplier delivers parts that do not fit, or when a purchase order arrives for a component that was obsoleted two months ago.

The business consequence is real and measurable. Missed changes add time to the delivery cycle. They create rework. They interrupt purchase order flow. They generate expedite costs. They cause the kind of coordination failures that show up in project reviews as execution problems, when the actual root cause is a structural gap in how product information moves through the company.

The Real Cost of SolidWorks Data Fragmentation Across Engineering, Procurement, and Operations

I want to be direct about what kind of problem this is, because it is often misclassified.

This is not a CAD problem. SolidWorks and PDM, used properly, manage design data well. The tools do what they were designed to do. Saying that a coordination breakdown is a CAD problem is like saying that a supply chain failure is a manufacturing machine problem. The machine works. The breakdown is in the system around it.

This is not fundamentally a spreadsheet problem either, even though spreadsheets are usually the most visible symptom. Spreadsheets are being used because there is no better alternative available for cross-functional data sharing. They are a symptom, not a cause.

The real issue is the absence of shared product context across functions. Engineering, procurement, operations, ERP, finance, suppliers, and contractors are all working on the same product, but they are each working from a local copy of part of the truth, assembled at a point in time, enriched with local additions, and disconnected from the other copies. No one has a complete and current view of the product that includes design structure, sourcing decisions, ERP status, supplier commitments, and change history together in one place. And because that connected view does not exist, every handoff between functions is a translation event that introduces the possibility of loss.

The consequence of this is not abstract. It shows up in on-time delivery performance. It shows up in cost overruns that cannot be explained by any single decision. It shows up in the constant low-level friction of people spending time reconciling data instead of making progress. It shows up in the engineering leader who cannot answer confidently whether the design that suppliers are working from is the current one. It shows up in the procurement manager who is not sure whether the BOM she is sourcing was updated after the last engineering change.

These are management-level problems, not just workflow frustrations. And they persist not because companies are poorly run, but because the information infrastructure that would allow the company to function as a connected whole is missing.

The Missing Layer: Connected Product Context Beyond SolidWorks and ERP

If you accept this framing, then the solution space looks different from what is usually proposed.

The typical proposal is some variation of better integration. Connect SolidWorks to ERP more tightly. Implement a PLM system. Automate more exports. These are all useful ideas, and in the right context they help. But none of them addresses the core issue, which is not about moving data more efficiently. It is about keeping meaning connected as data moves.

When a BOM is exported to a supplier, the export moves the structure but leaves behind the context. It leaves behind the engineering decisions that shaped that structure, the sourcing constraints that influenced certain choices, the change history that explains why a particular component was selected, and the current status of active changes that might affect what the supplier should know. All of that context stays in the heads of the people who were in the room. It does not travel with the data.

When procurement enriches the engineering BOM with vendor and cost information, that enrichment is rarely linked back to the engineering record. It lives in the procurement spreadsheet. When that spreadsheet is superseded by the next version, the enrichment from the previous round may or may not be carried forward. The decision rationale is almost certainly not carried forward.

Maybe the problem is not a missing export. Maybe it is not even a missing integration. Maybe the deeper problem is that there is no connected place where product data, context, changes, and decisions stay together as the product moves across engineering, purchasing, operations, and suppliers. If the product is built from information that extends well beyond CAD, then the real challenge is not only how to export that information, but how to keep its meaning intact as it moves.

That is the question I want to explore in the next post.

Best, Oleg 

This is the second article in a series on SolidWorks data management, coordination, and product information. The previous post covered the point where engineering data begins to fragment after leaving CAD and PDM. The next post will explore the concept of Product Memory as a possible answer to the coordination problem described here.