In terms of internal empowerment at OEMs, we have identified four success factors:

• Eye-level collaboration: The classic relationship between an OEM and its suppliers is a hierarchical one in which the OEM sets targets and directions and makes the important decisions. If a project goes wrong, many OEMs have specialized task force teams that will “invade” the supplier and take over operations. Due to the existing lack of software competencies at OEMs and the power of large tech providers, this approach will not work for many software projects. Software collaboration demands shared beliefs and a strategy underlying a joint approach toward the development of software products. This is why our first success factor is “eye-level collaboration.” This means that shared responsibility allows each party to contribute their unique expertise and capabilities while sharing risks related to technology, market, and regulatory compliance. Procurement must take this position on the OEM side and constantly steer this relationship with supplier management. This establishes the foundation for more flexible requirements and target setting as well as new contract and business models.

• Flexible requirements and target setting: The playing field of software-defined products needs a completely different approach to target setting and documentation. Moving away from rigid specification sheets and towards flexible requirements will allow for changes and adaptations in the scope, timeline, and deliverables of the software. This approach will benefit from agile development methodologies, which emphasize iterative and incremental delivery of software and may include performance metrics that are tied to the achievement of project milestones and goals (e.g., achievement of a defined number of story points), rather than strict adherence to predefined functional requirements. Challenges arising out of this “softer” target agreement must also be addressed through new contract and business models.

• New contract and business models: Traditionally, the classic contract model between an OEM and a supplier has focused on two parameters – unit price and development cost. Software was usually included in the (one-off) unit price of the hardware component. Today, however, new business models are needed for continuously developed and delivered software components. OEMs may need to evolve beyond a software license model based on production volume, irrespective of software usage intensity, and consider time-/usage-based payment models that better take into account ongoing supplier development and maintenance costs. Indeed, we predict that software-as-a-service business models will become the new normal. A further step is the participation of software suppliers in vehicle or function sales (e.g., autonomous driving functionality). This business model is applicable, especially in terms of long-term strategic partnerships and cooperation.

• Software assessment competence: Procurement needs to increase its ability to understand and evaluate software and deepen its connection to hardware. This includes knowledge of the overall software architecture with all its dependencies, common programming languages, software development methods, and systematic procedures for the management of critical projects. Therefore, procurement needs to establish a close relationship to development departments in order to build up this understanding in addition to its commercial competence. This competence is crucial in order for procurement to remain a neutral partner between the supplier and the OEM development departments. It is the foundation for negotiation in the initiation phase and the basis for a successful partnership.
  
  

In addition to internal empowerment, OEMs should consider four evaluation criteria when assessing potential software partners:

• Software delivery model: Compelling software products are the result of efficient development, rigorous testing, feedback loops, and appropriate adjustments throughout the product lifecycle. Suppliers need to offer a software delivery model that implements new requirements fast in agile teams using shorter release cycles and DevOps methods. Short feedback loops within the development value chain, from the OEM to the supplier, are a prerequisite for shortening time-to-market while maintaining quality. This enables continuous development, refinement, and delivery of software components “as-a-service” over the entire lifecycle. It stands in contrast to the traditional, SOP-focused delivery models used for hardware projects.

• Software flexibility and efficiency: A modern vehicle with its increasingly centralized computer architecture processes hundreds of millions of lines of software code – it is now estimated that a typical electric vehicle uses four times as much code as a commercial jetliner. Even though computing power is continuously increasing, the complexity of porting software to multiple platforms makes the flexibility and efficiency of acquired software a strategic issue. Buyers and suppliers must move from developing static, monolithic software tailored to specific hardware to prioritizing a flexible and modular cross-domain software portfolio.

• Automotive software steering competence: Nowadays, organization in agile teams to develop and maintain software is pretty much standard. But the implementation of these practices varies vastly across organizations and hierarchies. Currently, there is no global blueprint on how car software is developed and steered. The supplier’s management team in particular needs to be able to assess and handle the steering of software projects and the interfaces to the OEMs as part of automotive systems engineering. This includes efficient decision-making, prioritization, harmonization with hardware engineering, and communication in a much more volatile setup than with traditional hardware projects. And, if a project turns critical, the ability to manage overarching task forces up to and including the highest levels of corporate leadership is crucial.