New OEMs Business Models Change Product Development from Head to Toe
New Business Models Impact every Aspect of the Product Lifecycle
Business models of OEMs are about to change from hardware sellers to service and solution providers. It is a common belief that selling mobility services is more profitable than selling mechatronics. Since it was foreseeable that the automobile market would stagnate (126 versus 120 million sold vehicles), manufacturers have looked for new sources of income. At the same time, new automotive trends such as C.A.S.E (Connectivity, Autonomous, Sharing, Electrification) are on their way promising new types of services, even solutions, based on new kinds of technological architectures. This development implies new offerings and creates new customer demands, e.g. for electric driving. Tesla and other newcomers are about to show how such an approach makes it possible to ensure continuous revenue streams by providing an extensible service portfolio. They understand themselves as tech companies which happen to also develop vehicles. However, traditional manufacturers have stepped in the arena as well. Car.Software.Org, the Volkswagen subsidiary dedicated to software development in the future, has implemented VW.OS. Daimler AG and BMW are working on their operating systems and improvements. Other OEMs are working on similar projects. Renault, FCA, GM and others have announced plans to use Alphabet’s Android Automotive OS. Although the companies in focus are automotive OEMs, the principle change in business models towards service orientation is a general trend that holds true for many industries. It is essentially the monetization of value through data-driven transformation (see MIT Technology Review Insights [1]), or the “business of data” as the calls it [2].
Mobility services offer a tremendous amount of variability in product portfolio. They capture not only the usage of cars, but any kind of mobility services based on different technological platforms (airplane, train, bicycle et.) run by potentially different operators (e.g., “reach now”, former [3] “moovel”, [4] daimler lkw). As services are predominantly software-driven, time to customer is going to be dramatically reduced because software cycles are fast and service delivery is on-demand via flashing techniques. This generates a desire for on-demand availability as we have already experienced with smartphones.
Such a change in the business model has an enormous impact on all aspects of the product life cycle, starting with the requirements. The latter are driving hybrid product development as well as architectures of systems from mechanics and mechatronics to software and OS components. Even seemingly solely technological challenges, such as connected car, e-drive, autonomous driving, are influenced by the development of business models.
Complexity of the Mechatronic World
Historically, the product development process originated in mechanical engineering which was then combined with electrics and electronics and later added software components. Naturally, this led to a division of labor, so that product data (especially software components) were managed independently along the three disciplines, often in different authoring systems. This alone may, in one or the other case, have posed a challenge in complexity to a manufacturer, especially if its product portfolio consisted of many combinations of components from the three disciplines. Given defined requirements, it might not be clear across the disciplines which mechanical device may be used with which electronic board and appropriate state of a software module.
For the manufacturer, the customer’s benefit of on-demand software updates turns into a challenge. As software changes occur much faster than mechanical and electronics changes, this creates a higher degree of complexity and makes it even more difficult to deliver the needed information on time to the roles across the product lifecycle as required by PLM. Figure 1 shows a 3D-coordinate system relating to disciplines, product lifecycle and supply chain. Technical components such as a braking system or an operating system typically undergo all stages on the product lifecycle axis. They need supply at every stage and involve the disciplines accordingly.
The discussion, so far, reflects the degree of complexity which is induced by the development cycles of the different disciplines in the mode of today’s mechatronics driven development. Each vehicle contains of a multitude of mechatronics including on-board control units and communication busses that compose the technical system of a vehicle. Hence, the management of the product lifecycle has often been described as complex. Particularly, because the overall process breaks down in subprocesses that in turn have created independent data silos thus missing context and transparency across the lifecycle process. At this point, I would like to clearly stress that in my opinion data silos are important, in fact, they are necessary because they represent the specialization in the respective business functions. The question cannot be to eliminate them but rather to ensure the connected data across silos can be exploited by relevant roles along the lifecycle. This is essentially the core purpose of PLM. Viswanathan Kuppuswami recently wrote this nicely in his post
“…in a product organization, every business process is a step in the lifecycle of the product. Acknowledging this and looking at the processes from a product perspective instead of a functional perspective will unlock significant improvements; reduce pain and accelerate Time-To-Market.”
