A long time ago, I had a discussion with a software architect working for a consumer electronics company. We talked about development efficiency and he explained to me the economics of high-volume manufacturing. When you manufacture a million televisions and you can squeeze one euro out of the bill-of-materials cost, you’ve made the company a million.
This concept has of course spread far and wide in the industry and virtually any company has cost-down initiatives where, also after the initial release of the product, redesign efforts take place to squeeze the bill-of-materials cost. The general belief is that the benefits of this reduction will outweigh the necessary R&D expenses to such an extent that no analysis is necessary.
To be honest, I think that the bill-of-materials focus has been an oversimplification from the beginning and that it has become even more of an outdated belief over recent years. This is the case for two reasons, an older one and a more recent one.
The older reason is concerned with two aspects of economies of scale. The aforementioned architect also told me that one development team had been tasked to squeeze the size of the software for a specific television model such that it would fit in a 6 MB EPROM rather than an 8 MB one (this was many years ago). The team spent months on this, but when they finally succeeded, it turned out that an 8 MB EPROM was cheaper than a 6 MB one, which had a bit of a weird size and consequently ordered less frequently.
For many companies, due to their being able to place larger orders and get bigger discounts, ordering the same electronics for the entire product range, even if it means that lower-end products are overdimensioned, is simply cheaper than optimally dimensioning each product in the portfolio and ordering much smaller quantities.
The second benefit of building your entire product portfolio on a single hardware platform is that your software has to support much fewer variants and becomes much easier to reuse over a product portfolio. Not having to address the peculiarities of each individual product in terms of hardware architecture, resource availability, performance and dedicated special solutions simplifies the software, leading to lower cost and higher quality. We want variants from a sales perspective, but the best way to achieve that from an R&D perspective is by a very limited core set and using combinatorics and configuration as a means to generate all those variants.
As an example, an agile team of 8 people working in 3-week sprints burns 24 person weeks or around 0.5 FTE. Assuming an FTE cost €150K (including taxes, workplace, equipment, overhead, and so on), that means every sprint costs around €75K. In a company where R&D receives 5 percent of the revenue, every euro invested in R&D has to result in 20 euros of business value. That means that this team has to generate €1.5M of business value per sprint. Ensuring that investments in software R&D lead to that outcome isn’t easily achieved by only squeezing bill-of-materials cost.
The new reason why a bill-of-materials focus increasingly is an outdated belief is the industry-wide adoption of DevOps and continuous deployment. If your product is expected to receive new software updates throughout its economic life, it’s obvious that you need to start with a significant amount of headroom, in terms of storage and computational resources, as new functionality will need to go somewhere and use computing. Consequently, squeezing the bill-of-materials cost to the lowest possible at the start of production is a really bad idea as you’ve painted yourself into a corner.
The question that I see many companies struggle with today is the balance between upfront headroom and electronics upgrades throughout the economic life of the product. For instance, in automotive, the typical model is that a vehicle starts its life as a leasing car and then enters the private market after two or three years. Providing an electronics upgrade after three years to allow the new owner to continue to enjoy software updates can be a reasonable compromise between limiting the upfront headroom while creating a business around lifetime upgrades.
Of course, this doesn’t work in all contexts. For instance, although there have been experiments with modular mobile phones, the nature of the product doesn’t support post-manufacturing upgrades well due to several technical reasons. In those cases, the balance has to be made between upfront headroom and planned obsolescence and replacement.
Especially in high-volume manufacturing, the industry has had an excessive bill-of-materials focus. Any R&D effort to reduce the bill of materials was considered a good tradeoff. If this belief ever was true is a good question, but it most certainly is no longer true today. DevOps and continuous improvement throughout the lifetime of the product require headroom, increasing the bill-of-materials cost in service of maximizing the lifetime value of the product. So, rather than squeezing the last drop of blood out of the stone, perhaps focus your energy on maximizing the value and revenue you can create with your products throughout the entire economic lifecycle.
This blog is taking a summer vacation break and will be back in the middle of August.
To get more insights earlier, 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).
