Rework rarely begins on the shop floor. More often, it starts much earlier, with outdated information, unclear ownership, or disconnected processes. In one SME manufacturing environment, the root cause was surprisingly simple: BOM updates arriving through email attachments with no reliable way to track revisions. What followed was familiar to many manufacturers: engineering confusion, quality issues, and costly rework.

The Hidden Cost of Email-Driven BOM Management

Last month, I worked with a small manufacturing company producing tube feeders for SMT applications.

Like many growing manufacturers, they had capable engineers, satisfied customers, and a steady flow of orders. Yet beneath the surface, they were struggling with issues that seemed unrelated at first glance: rework, quality problems, engineering confusion, and increasing effort spent finding the “latest” information.

The root cause was not a lack of talent.

It was a lack of control over product information.

The Situation

The company had a team of four engineers working on product design and modifications. Customer Bills of Materials (BOMs) arrived through email, typically as Excel spreadsheets. CAD files were created using SolidWorks and Creo and stored on individual engineer workstations. Inventory tracking existed, but most activities were still managed manually. At first glance, this appeared manageable. However, as customer revisions increased, cracks began to appear.

The Real Problem

A customer would send an updated BOM through email. One engineer might update his local copy. Another engineer could still be working from an older version. Production might receive a different revision altogether.

Because files were distributed across individual systems and communication relied heavily on email, there was no reliable way to answer simple questions:

• Which BOM version is the latest?
• Who approved the change?
• Which CAD model matches the released BOM?
• Has production received the updated information?

The organization had data.

What it lacked was traceability.

The Business Impact

The consequences became visible across multiple areas.

Engineering teams spent time searching for information instead of creating it.

Production occasionally worked with outdated data.

Quality issues emerged because changes were not consistently communicated.

Rework increased.

Most importantly, management had limited visibility into where errors originated. When information is scattered, every department creates its own version of reality.

Looking Beyond Technology

Many organizations immediately assume the solution is software. In reality, software was not the first problem to solve. During our assessment, we found that the challenge involved three interconnected areas:

People

Roles and responsibilities for managing product information were unclear.

Process

There was no defined method for receiving, reviewing, approving, and communicating customer changes.

Technology

Product data was stored in multiple locations without a structured mechanism for version control.

The issue was not caused by people, process, or technology alone; it was the lack of alignment between all three.

Starting Small

Rather than recommending a large-scale transformation program, we advised the company to begin with a series of practical Kaizen activities.

The objective was simple:

Create visibility and control before introducing complexity.

Initial actions included:

• Defining ownership for BOM updates
• Establishing a controlled location for engineering data
• Introducing basic revision tracking
• Standardizing how customer changes were received and communicated
• Mapping the NPD/NPI process from customer requirement to production release

These were not expensive initiatives.

But they delivered immediate clarity.

Building the Roadmap

Once the organization experienced the benefits of structured information management, discussions about future improvements became much easier.

We developed a roadmap that focused on:

• BOM governance
• Product data organization
• Change management discipline
• NPD/NPI process maturity
• Future readiness for PLM adoption

Instead of purchasing software first and defining processes later, the company gained a clear understanding of what needed to be controlled and why.

This approach also helped establish the foundation for a future PLM implementation by identifying gaps in product data, change management, and engineering processes.

Key Takeaway

Many SMEs believe their digital transformation journey starts with software selection.

In my experience, it starts much earlier. If product information arrives through email, engineering data resides on local computers, and revisions depend on individual communication, technology alone will not solve the problem. The first step is creating control over information, responsibilities, and processes. Only then can digital tools deliver their full value. The goal is not to become digital overnight. The goal is to ensure that every person in the organization is working from the same version of the truth.

Every rework has a root cause. The challenge is identifying it before it affects quality, delivery, and profitability. If your engineering team still relies on emails, spreadsheets, and disconnected product information, a structured assessment can help uncover the gaps and define a practical improvement roadmap.