Weighing the costs: BOM versus NRE

-June 08, 2015

Optimizing an embedded system for minimal cost can be a delicate matter. In particular, balancing the development and production costs is a tricky proposition. There are a number of factors that determine this balance but it turns out that one must realistically examine production volume expectations in order to properly optimize for cost.

Cost optimization generally falls into two opposing categories: bill of material (BOM) and non-recurring engineering (NRE) costs. The BOM costs are essentially the production costs for the end product while the NRE costs are dominated by the engineering labor required to design and test the product. Attempts to minimize the BOM cost can cause NRE to skyrocket and vice-versa.

Take for example a low volume system that will produce less than 10,000 units annually. System designers might look at their BOM and electrical design and realize that they can $0.50 on every unit if they remove a hardware filter and instead implement the filter in software. At first glance the hardware filter's removal seems like a good idea. After all, it will save approximately $5,000 in production costs. The real question, though, is whether that savings is worth it.

At a low volume an attempt to optimize the BOM that requires shifting a feature into software can be more costly in the long run. In the example of the filter, the shift means that a software developer now needs to add additional functions to be integrated into the architecture, modeled, implemented, and put through testing. As a general rule of thumb a cost for an engineer at one week loaded is $5,000. Can the feature that was moved from hardware to software go through the entire software development cycle in 1 week? If the answer is no, then the overall project costs just went up.

Unfortunately the overall cost impact of moving a feature from hardware into software is usually overlooked in low volume embedded systems. Engineers and even management begin to view the NRE of the labor to be inconsequential because it is already an assumed cost as part of the engineers’ employment and company overhead. Instead, optimization goggles are put on and a vast number of man hours begin to be invested in optimizations efforts that bear little fruit in the overall embedded systems performance, quality, and project costs.

Developing an embedded system in the medium volume range, usually considered to be 10,000 to 100,000 units per year, does start to open up the realistic possibility of optimization. The previous example of a filter, at medium volumes, probably would save the project money by moving this feature into software. A more interesting example at medium volumes is when the system developers decide that a commercially off-the-shelf component such as a certified radio or sensor is too costly and should be developed internally instead.

Designing the component from scratch can seem like a good idea. It may save $5 per system and if the volumes are 50,000 that starts to look like a very good idea in a hurry, after all that’s $250,000. Based on that analysis alone many companies will decide they have to build their own and start down the slippery slope. A closer look would reveal that designing their own radio or sensor very well might cause them to break even or spent more!

The design and certification of a radio module or sensor system could easily take three to four months. It would entail hardware, firmware, testing, and certification engineers along with the fact that it will take at least two revisions to get it right. Using the assumption of $5,000 for an engineer per week of labor, using just one engineer for those months already adds up to $80,000. Taking into account manufacturing of prototypes and certifications such as FCC, an estimate of $120,000 for the radio module development could be considered realistic.

Looking at these numbers it still looks like a win for BOM optimization; however, there would have been a three to four month window where the product could potentially have already been out on the market. The loss of those sales brings the cost versus savings number close to even, with the BOM optimization just squeaking through as a “win”. If one were to consider possible additional sales losses from the early entry of competitor or other business aspects, it might just turn out that the decision to optimize for BOM cost was not the right one for the long run.

The BOM versus NRE dichotomy is real. As one tries to decrease BOM costs, NRE costs rise. Try to minimize NRE costs and BOM costs rise. There is no general right one to choose. Instead, a careful analysis of all the business and engineering factors need to be determined to make the right decision. Companies generally don’t take the time to do this and instead lose tens of thousands of dollars on projects by only examining one piece of puzzle.

Business decisions are often outside the realm of the engineer, but being aware and helping remind management of the real trade-offs and benefits can be the difference as to whether a company or product become and remain viable.

Jacob Beningo is a Certified Software Development Professional (CSDP) whose expertise is in embedded software. He works with companies to decrease costs and time to market while maintaining a quality and robust product. Feel free to contact him at jacob@beningo.com, at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter here.

Join over 2,000 technical professionals and embedded systems hardware, software, and firmware developers at ESC Silicon Valley July 20-22, 2015 and learn about the latest techniques and tips for reducing time, cost, and complexity in the embedded development process.

Passes for the ESC Silicon Valley 2015 Technical Conference are available at the conference’s official site with discounted advance pricing until July 17, 2015. The Embedded Systems Conference and EDN are owned by UBM Canon.

Loading comments...

Write a Comment

To comment please Log In