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.