Fields marked with a * are required


A Single Source of the Truth for the BOM Still Doesn’t Exist

References Cited

Product Lifecycle Management (PLM), Mechanical Computer Aided Design (MCAD), Electrical Computer Aided Design (ECAD)

It is crazy how time flies. Blink and 2015 is gone. I guess that’s what happens when you get busy. I hope that 2016 decides to pass by a little more slowly. But I don’t think I’ll have much luck with that.

Regardless, I have a topic that I’ve wanted to touch upon for quite some time. You see, I’ve been doing a lot of work on systems development in the past few months. And there’s this issue that is bugging me. So here, in this post, I’ll unburden myself.

We’re here to talk about how completely, or incompletely, software solutions truly support the Bill of Material (BOM). We’ll look at this, engineering discipline by engineering discipline.

Mechanical Hardware

This is an area that most PDM or PLM solutions have licked. Right?

Well, those systems certainly do have lots of capabilities to create, synchronize and manage BOMs. Users can build them out and push them down to MCAD software. You can create a product structure in MCAD and push it up to a PDM or PLM system, creating a BOM. You can make iterative changes where modifications go back and forth between the two. Heck, many of today’s systems manage design artifacts from many different MCAD applications. Managing multi-MCAD data is a real thing now. There’s lot of great stuff here.

However, it is not enough. Today, there is incredible innovation in mechanical engineering that is coming from materials science. Some of this is the result of 3D printing technologies. Some of it comes from composites. Some of it comes from new-to-the-world stuff. But in general, the properties of these materials aren’t homogenous nor constant with time. For example, engineers can now specify how the material properties of a component changes along its length. It is amazing to see where we are going with mechanical design.

Yet, when it comes to supporting the specification of materials in the Bill of Materials in enterprise systems, there is almost nothing. A few software provides have stepped up, like MSC Software with their Materials Center focused on simulation. However, that solution is used to manage BOMs. Siemens PLM also has some plans in process, but it has yet to arrive. From a big picture perspective, this is an area where there is a dearth of capability.

Electronics Hardware

Overall, engineers have been putting components on Printed Circuit Boards (PCBs) for decades. How fully are PCB BOMs supported?

To answer that question, we need a little context. Most PCBs are designed using off the shelf components that have to go through some qualification or approval process for use. Engineering organizations build up a list of approved components that are maintained in a library. New components are introduced from time to time. Other components are retired from time to time. From a design perspective, engineers connect their ECAD tools to a library of these components. They then place components from the library onto the design layout. In this process, you end up with two ‘things’: the design layout and the component library.

Modern PDM and PLM systems do a good job managing ECAD design layouts. When they are checked in, the system can read the information in the ECAD design layout and exact the BOM. This is a fairly common capability. What is missing in PDM and PLM systems is any kind of management and synchronization of the ECAD library. Some of the EDA solution providers provide something akin to a PDM to manage both the design layout and the library. But these tools aren’t the ones to manage the BOM for the entire product.

Embedded Software

What about the software? In some industries, this is where 90% of all innovation is happening in today’s products.

Well, a lot goes into compiled software. There is the raw code files. There are function libraries that the raw code uses. There are SDKs, APIs and web services that need to be integrated. Don’t forget that there is the compiler itself. There are also UML diagrams and other visual and logical representations of the software.

Yet, when you look at what most PDM and PLM systems manage, it is only the compiled software. ALM systems obviously include a lot more functionality to manage all these artifacts. But again, ALM systems aren’t going to be managing product level BOMs anytime soon. What is most interesting is that there has been acquisitions on this front in recent years. PTC acquired Integrity a couple years ago. Siemens PLM acquired Polarion towards the end of this year. It is still too early to get a glimpse into the vision that Siemens PLM has for Polarion, but it is clear PTC has no intentions of creating a solution to manage this level of BOM granularity between Windchill and Integrity.

Why Does Any of This Matter?

OK. So it is clear that the BOM sources for mechanical hardware, electronic hardware and embedded software are not fully integrated and supported today. There is no single source for a product level BOM. So what? Why does it matter?

Here’s the short answer: integrated development across engineering disciplines matters more today than ever.

When planning and modifying designs, mechanical engineers, electrical engineers and embedded software developers must work together and collaboratively to come up with holistic design solutions. That means that satisfying a system level requirement will often be broken down and assigned to hardware and software components. It means that if a new material in that mechanical component can’t satisfy that requirement, there might need to be a change to the requirement on the software component, which might flow down to an API or function library. These types of trade-offs and coordination plays out in hundreds of different scenarios, like change orders, modified requirements, failed prototypes and so many more, in engineering organizations on a daily basis.

The Only Alternative: Spreadsheets

Ultimately, this is why many engineers manage requirements in spreadsheets.

The lack of granularity in the BOMs in these types of systems is an obstacle. When an engineer can’t allocate a requirement to a material, he turns to a spreadsheet. When a systems engineer can’t reallocate a requirement from a electronics library component to raw software code, they turn to a spreadsheet. Having requirements in many different systems leads to miscommunication that, in turn, results in a failed testing round.

Listen. If you’ve read this blog or any of my eBooks over the past five years, you could probably figure out that, in general, I’m an advocate for technology. But in this case, the solution(s) are too incomplete. They are too ugly. So it shouldn’t come as any surprise.

Let me know your thoughts in the comments. Looking forward to a constructive conversation.

Take care. Talk soon. Thanks for reading.

Chad Jackson is an Industry Analyst at Lifecycle Insights and publisher of the engineering-matters blog. With more than 15 years of industry experience, Chad covers career, managerial and technology topics in engineering. For more details, visit his profile.

Like this post?

Sign up now to get more like it

Fields marked with a * are required


  • Interesting discussion Chad and I agree with your proposition.

    One of the largest hurdles on multi-domain is the complexity of workflows and artefacts within the different workflows (SW, EE and ME). We must remember that managing lifecycles is more than just BOMs, it’s BOMs in context, at stages through the lifecycle and with traceability (of BOMs and artefacts etc.). which is tough enough to do in any one environment as we know.

    On the topic of embedded. I still hold that its naiive (perhaps too strong a word?) to suggest that SW can be managed at binary level in PLM form for complex products, and the fact that (even PTC) it’s not been practical to merge ALM and PLM solutions to date reflects this. More so now that many are implementing Agile (DEVOPS) for server and other software components.

    IBM’s come closest to addressing this (SW/ME at least) schism with RELM. And OSLC is still a work in progress but aims to deliver better ALM/PLM interoperability, which should/will help. BUT these (types of solutions) really only address the needs of bigger companies. Mid size and smaller …. you’re on you own…..and that’s where I’d like to see some more activity. Perhaps the advent of more and more/new Cloud based environments with new use models will drive a change in business/design/manufacturing/service workflows and associated tool-chains for small-mid size business? That’s what I’m hoping!

    • Hey Allan. Thanks for weighing in. Here’s my additional thoughts.

      Managing the BOM, and getting them to represent and update with their underlying design representations (MCAD model, software binaries, ECAD layouts) is different than forcing all engineering disciplines to use the same PDM system. You’re right: the lifecycle is more than just the BOM. But my point here is that the granularity that is needed, so you can assign requirements down to lower level representations, isn’t supported right now.

      I get that it is not easy for PTC to merge Windchill and Integrity. It may not be easy for Siemens PLM to merge Teamcenter and Polarion. There are many cases where, at first glance, a software provider doesn’t want to do something like this. That stance holds up as long as there is no competitive pressure.

      PTC, who took the stance that Direct Modeling really couldn’t be integrated into ProE, changed that quickly when Spaceclaim started gaining traction with engineers. That same story has played out, again and again, with each of these providers over time.

      I hope that some software provider will see this opportunity. I hope that one of them will be bold enough to seize it. Then I hope the rest of the industry follows.

      • We’re in complete agreement here Chad. Assigning requirements down to the lower representations is required for not least, traceability and test. That’s why I for one think that OSLC’s ALM/PLM work is important. It allows for more granular collaboration amongst the app environments and makes (programatic) traversing of complex and interconnected systems a more practical proposition.

        • I agree there are various levels of traceability required. It all depends on the impact of an error made and the mechanisms to avoid making this mistake. However as long as organisations are still in the process of learning I hope there will be first infrastructure before vendors come with (closed) solutions

  • I’ve got a new term for you. CADBOM – This is the hierarchy generated within a native CAD platform, and then flows into the EBOM (Engineering BOM). This assists those BOMs to align, and at least gets the mechanical hardware to align. What do you think of that concept?

    • Jennifer the CADBOM is an old concept not generic and complete enough to support multidiscip

      • Jos – Thanks. The CADBOM is central to any hardware, and is the seed for all other BOMs built from that hardware. I think there is variation in the term BOM and the concepts it imparts. When I use CADBOM, I mean the seed for the parts list.

        • Hey Jen. I think that is an accurate way to describe the concept. All the disciplines need to synch up at one point or another.

  • Jeppe Sörensen

    There is no such thing as The single source of truth. Neither when it comes to BOMs nor anything else. The BOM will change, and so will the workflows managing the BOM. From my experience it is best to let the different disciplines solve their pains. Don’t mix Mechanical CAD BOM with Software version control or Chemical recepies. However, I think that using Spreadsheets are error prone. You need a system on top of the different xDM systems. It needs to be aware of the other mangement tools. I think that Collaboration and Openess are key requirements for any tool managing engineering data, so that you can easily collect the information and process it from a top view.
    However, I think most PLM system suppliers are moving towards closed solutions, trying to solve it all. What do you think?

    • Hi Jeppe – we are of the same age. We think by nature in silos instead of shared data :)

    • Hey Jeppe. Thanks for your comment.

      I think it is possible to have a single source of truth for BOMs. It is just that, unfortunately, the solutions that manage different aspects of BOMs were developed by software providers who had a limited scope in the market. Therefore, their solutions were limited.

      I believe it is an artificial and unnecessary constraint.

      Do I think one of the existing software providers will solve this problem? Perhaps. I think it is more likely that a new player, who decides they won’t play by those existing rules, comes in and acts as a disrupter. The opportunity is there.

  • Chad thanks for raising this issue. I will not write a blog post to respond as there are so many viewpoints for this discussion.

    You are pointing to the software vendors who are not able to provide a fully integrated product suite. I see it as a chicken and egg situation.

    Do you know any company that has a full understan

    • Jos! Sorry for responding so late. Things have been hectic.

      I understand your point about the chicken and egg scenario with respect to manufacturers and solution providers. However, I think at different points of solution maturity, each needs to take a leadership position.

      Years ago, when every engineer was creating lines on digital drawings, no one was asking for 3D models that would automatically create and update drawings. Yet when PTC launched Pro/ENGINEER, it broadened the constraints of what was possible. The industry as a whole leapt forward.

      Today, I see artificial constraints with respect to managing requirements and change across a holistic, complete and granular BOM. No one is asking for this because the concept hasn’t been introduced, much less launched.

      Here’s my point: manufacturing customers, and any customers really, think within the box of existing solutions and, perhaps, slightly enhanced potential versions of those solutions. When it comes to revolutionary progress, software providers have to lead.

      • Chad I see your point – somebody has to lead. I think the problem now is that PLM definition and complexity is changing and I am not sure the old PLM gurus can do a revolution.

        I believe it will come from the field (and I see several attempts) where companies discover old PLM is no longer good enough, therefore, do not want to create a new solution inside these suites.

        I hope to discuss some of these concepts during the upcoming PI Conference in Munich

  • Ed Danzer

    We have had a method to allow the SolidWorks assembly to have a complete BOM. We do this by assigning a part number to each item used to build a product. It does not matter what department adds the item. Once a part number is assigned to an item it can be reused in 1 or many products. We have a part number for packaging items and paint color if required and these items are placed in the assembly and become part of the Excel BOM on the SolidWorks drawing page for ordering, part pulling and production. If something is missing during assembly that item is added to the SolidWorks assembly and the drawing page updated.

    The best part is when a change is made by doing a file save as to a new part number most of the prior work is reused and only the changed items need to be worked on. There is never a REV change, always a new part number. This eliminates wondering which rev does the customer have or need.

    • Hey Ed. Apologies for the delay in responding!

      So do you have software and electronics folks adding their parts to the SolidWorks assembly? How do they do that? Do they open SolidWorks?

      Configuration change is always a really complicated topic. Your approach leaves little doubt whether the customer has the latest. But how do you deal with one functional part having many part numbers?

      • Ed Danzer

        We are unique shop in that we do it all here. If there is a project with electronics items and software we assign a master part number in Excel that everyone references. If the item is a physical electronic part it will probably get modeled and put in the assembly. The software will just be an empty solid model and added to the assembly. We use file properties in the SolidWorks file for the item description that matches the Excel Description and if there is a manufactures part number that is entered also. This makes the SolidWorks assembly file the master of information when building a product. We print the 2D assembly drawing to pull parts from. If there are not enough of a part in stock to build the assembly they are ordered.

      • Ed Danzer

        Each unique part has only one part number that we use in the SolidWorks assemblies. If we have a purchased part with multiple vendors with different part numbers that additional information may be in the SolidWorks file properties or in QuickBooks for purchasing to deal with.

        The system we use is not perfect. I have been looking into using a graph database as a better way to store the knowledge instead of SolidWorks.