PD fallacy #8: the bill of materials has the highest priority
Photo by Vadim Sherbakov on Unsplash

PD fallacy #8: the bill of materials has the highest priority

Traditional companies building products including mechanics, electronics and software tend to focus on the bill of materials (BOM), standard unit cost (SUC) or some other KPI tracking the per-product instance cost during manufacturing. When manufacturing large numbers of the same product for extended periods, this makes perfect sense as every penny saved is multiplied over all the manufactured instances.

The challenge arises when companies are undergoing a digital transformation of their product portfolio and aim to deliver value to customers continuously. A typical model is to adopt DevOps as a mechanism to push new software to products in the field frequently. The moment the company transitions to this model, the BOM focus of the mechanical and electronics engineers becomes a significant hurdle as their decisions tend to lead to designs with very little ‘headroom’ in terms of CPU and memory resources.

The consequence is a clash between two paradigms of product development. On the one hand, it obviously is a good idea to minimize the cost of the product as it allows for better margins. On the other hand, not leaving headroom in the product destroys the ability to deliver value over time. Especially during the transition, it’s often very easy to quantify the short-term gains of squeezing the BOM and very hard to quantify the potential gains through continuous value delivery. This leads to companies continuing to focus on the BOM for way longer than what would make sense from a business perspective.

The BOM perspective tends to cause multiple challenges of which I want to discuss the three primary ones. The first, most obvious, is that not leaving headroom in the product destroys the ability of the company to build a continuous value delivery model. Especially for long-lived products that have years, if not decades, of expected life span, this is a major issue as the current product generations will hamper the company’s digital transformation for years to come.

The second challenge, often less well understood, is that an excessive focus on the BOM tends to introduce strong dependencies between different subsystems. Engineers are allowed to introduce any shortcut that results in a reduced BOM and consequently, the system will exhibit high coupling. When adopting DevOps for products, this tends to lead to an increased number of quality issues as it’s hard to validate and test all the intricate dependencies in the system.

Finally, especially in platform companies, allowing for BOM optimization tends to result in a significant deviation from the common platform architecture of the product portfolio. This causes what’s often referred to as a versioning hell as every product and every generation of every product needs its own specific, unique version of the software. This is acceptable if we have the build the software once, but when we adopt DevOps, it means that we have to generate new software for every configuration every two to four weeks. This gets expensive and labor intensive really fast.

To address these challenges, one of the key actions required is to ensure that you monetize the continuous value delivery through DevOps in some way. If there’s no revenue associated with new functionality being delivered to customers, the entire organization will drag its feet as it will only add cost at the promise of some vague ‘customer preference’ promise.

Of course, we can monetize through maintenance or subscription fees, but an effective approach can be to use the outcome metrics your customer is concerned with as a basis. Assume your system generates 100 units per hour for the customer and you can increase the output to 110 units per hour by deploying new software. In that case, it’s entirely reasonable for the customer to share some of the additional revenue with you. This requires, however, a clear understanding of what the key value factors are that your customer cares about. This understanding is surprisingly limited in most of the companies I work with as they focus on the product itself.

The second key action is to focus on bringing your entire offering portfolio into a single platform and make each product a configuration of that single platform. This allows for a vastly improved return on investment for most R&D efforts as much of the newly developed functionality can be shared among all products in the portfolio. Test infrastructure, deployment infrastructure, data collection infrastructure, and so on, can all be shared as well.

Although I’ve covered this topic before, I still run into people and cases that make me realize that the message hasn’t been received everywhere. An excessive focus on the bill of materials leads to significant challenges for companies that are undergoing a digital transformation and adopt continuous value delivery. The lack of headroom, high coupling and versioning hell may easily cause an explosion of R&D expenditure over time. Instead, ensure to monetize continuous value delivery and platformize your entire product portfolio to address these concerns. From a focus on the bill of materials, we need to shift to lifetime value. In the end, we want a continuous relationship with our customers and this is one of the best ways to strengthen that.

Like what you read? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).

Paul Garrish

Helping companies make a success of Product Lifecycle Management (PLM)

1y

Don't throw the baby out with the bathwater. If you make a product, configuring the BoM is still key and software is just another part of it. You talk about 'optimising' the BoM but if your only metrics to optimise are build cost or part count then of course you'll make shorter term decisions. If you make expandability or flexibility a metric then the BoM is no more a constraint than any other way of defining your product. Think of the argument Wozniak and Jobs had about expansion slots. You could view that as an argument about BoM complexity but that is just the outcome, the real argument was do you want a more complicated, but more flexible product, or a simpler but more constrained product. The BoM is the outcome of your decisions but it is still vital as the thing around which you communicate.

Like
Reply
Stefan Mueller

Digitalization Challenger for Automotive Clients @ BearingPoint | Author | Future Mobilist

1y

Great analysis that is showing for example why traditional carmakers are heavilivy struggling with becoming software oriented companies. Thanks for these insights.

Like
Reply
Ola Lundström

Senior Consultant | Business owner | Digital Advisor

1y

Spot on, and to your first point there is also the dimension of the customer's as they also need to mature in regards of how they buy production capacity. If you as a customer don't understand what continous delivery of features/capabilities means as you have bought-resold/replaced machines for decades in som cases it can be hard to move into the new world of being provided a capability rather than a tangible hardware product.

Like
Reply
Bert van Appeven

Owner “van Appeven | Idea to Business” ★ Result driven pragmatist ★ Organizational Design for Tech Innovation ★ Innovation Management

1y

Indeed, you can easily deduct that the BOM has quite a low impact on profit, especcially when servitization is part of the business case.

Like
Reply
Alex Bruskin

Bespoke Generative AI for Engineering & Manufacturing (PLM, MES, ERP) | Cloud Native | Air Gapped | System Integration | Concepts, Technologies, Execution

1y

Hard to argue here, however, this raises a question about requirements management - if engineers make shortcuts etc., perhaps the requirements are not clearly defined and consequences of these decisions are not clearly understood? The document-managed requirements cannot possibly keep track of the entire picture, so SysML, especially SysML2.0 might be the only future? Tim Weilkiens Another thought - maybe BOM itself is an obsolete concept, and some other abbreviation covering derivative structures inside the knowledge graph are necessary? Martijn Dullaart

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics