.webp)
Consumers are demanding great digital experiences in every context of their daily life – from mobile phones through home entertainment and appliances to cars. The automotive industry is quickly moving from a single static display for information sharing to digital cockpits delivering a wide range of services and applications. The pace of change is accelerated not only by external benchmarks such as mobile devices but also industry forerunners, such as Mercedes Benz, Tesla and Audi. All of them have lifted up the expectations for in-car experience. Responding to the increased digital requirements is different than responding to competition with better cup holders*.
The automotive industry must look at the procurement of software differently in the world of digital cockpits. The current processes and practices are optimized for sourcing hardware components globally. Software components are just glued on top of these practices. It has led to situations where software costs are creeping into projects and platforms. In order to build winning digital cockpits automotive OEMs must lift software sourcing to a totally new level. The concept of Software BOM (bill of materials) is at the core of the change. Software BOM should include all the cost related to the product lifecycle – from concepting to deployment and updates. Software decisions also have an indirect impact on hardware cost such as memory (size and quality) and boards (performance and availability), but in this blog series only direct BOM items are covered.
The automotive industry today has well-established practices for managing bill of materials. Actually, a typical car project is a fine oiled procurement process of well-defined specifications, bidding practices over multiple rounds and established supplier layers (called tiers). The fundamental idea behind the process is that a car can be departmentalized into small independent units and each unit’s cost can be minimized, resulting in an optimum total cost structure at the end of the day. This is a very good approach when all components are truly independent from each other and do not share anything in common.
A software component, however, has very little independency as everything is connected and often shared. Furthermore, great software is typically the result of several phases from user experience definition and development to final target optimization. Development in one component may have requirements on other components. Thus, software procurement must be seen as a system purchase and not as a component purchase.
There is a simple way to test whether an OEM is mastering Software BOM or not – by just asking one question at the start of production (SOP) ceremony: „What is the software cost per car for this model?“ A black belt is given when you get an answer consisting of a number and currency. All other answers should lead to a change how software decisions are being made.
Would you like to hear more about what is preventing optimized BOM for automotive OEMS. Stay tuned!
Tero Marjamäki
* www.theatlantic.com / cupholders are everywhere
