Organization

Abstract

The final perspective in the AIoT Business Execution discussion is on the organization, which needs to support the creation and operation of AIoT-enabled products or solutions. The organizational setup is a potential Achilles’ heel: if this is not done properly, the entire initiative can be derailed. A number of different factors play a role here, from cultural aspects to proper alignment of the organizational structure with the key architectural elements of the product or solution. Owing to the large differences between Digital OEM and Digital Equipment operations from the organizational perspective, both will be discussed individually in this chapter.

The final perspective in the AIoT Business Execution discussion is on the organization, which needs to support the creation and operation of AIoT-enabled products or solutions. The organizational setup is a potential Achilles’ heel: if this is not done properly, the entire initiative can be derailed. A number of different factors play a role here, from cultural aspects to proper alignment of the organizational structure with the key architectural elements of the product or solution. Owing to the large differences between Digital OEM and Digital Equipment operations from the organizational perspective, both will be discussed individually in this chapter.

1 Digital OEM (Fig. 17.1)

The product organization is ultimately responsible for delivering smart, connected products. Given the complexity of a typical AIoT product, as well as the different cultures that have to be brought together, building an efficient and effective AIoT product organization is not an easy task. This section of the AIoT framework discusses key challenges and proposes a specific setup that can be easily adapted to fit one’s individual needs.

Fig. 17.1

Product organization

1.1 Product Organization

A successful product organization differs significantly from a project organization, as we will see in the following. In order to understand the differences, we will first look at the typical product lifecycle phases, before discussing how a product vs. a project organization typically evolves during this cycle.

1.2 Product Lifecycle Perspective

Particularly at the beginning of the new product journey, it is important to take a step back and look at the complete product lifecycle to be prepared for the road ahead. The lifecycle of most successful products can be described as follows:

• Exploration: During this phase, the initial product is developed, market reception is validated, initial customers are acquired, etc. Please note that the popular concept of a Minimum Viable Product (MVP) is more difficult to execute if physical product components are involved.

• Growth: The growth phase aims to expand reach, scale sales and continue to develop the product to stay competitive

• Maturity: In this phase, the focus is on customer retention and to sustain market share

• Decline: Finally, a strategic decision regarding strategic pivoting or phasing out has to be made; often the start for a next generation product

The interesting question now is: what must an organization look like to support a product through these different phases, and how does the organization itself have to evolve? (Fig. 17.2).

Fig. 17.2

Product lifecycle

1.3 Traditional Project Organization

In many incumbent enterprises, the development of a new product often starts as a project because from a controlling and administration point of view, setting up a project is more lightweight than establishing a new organizational unit. Since in the early stages it is often not known whether the product idea will be successful, this is quite understandable. If the initial MVP is promising, the project might be transferred to an internal accelerator. If the product shows the potential to scale from a sales point of view, a new line of business may eventually be created (Fig. 17.3).

Fig. 17.3

Project organisations

In principle, there is nothing wrong with this approach. However, in practice it can cause severe problems. To better understand why, let us first quickly summarize the key differences between project and product. The table following provides a high-level comparison.

1.4 Toward the AIoT Product Organisation

In practice, there are a number of common problems associated with starting a new product with a project mindset and setup. First, a product should be developed from the beginning with product KPIs as the central measurement of success; customer satisfaction and customer adoption should be key KPIs from the very beginning. Typical project-centric KPIs such as development and go-to-market milestones (as well as cost) should be secondary.

Second, a typical project has a fixed start and end date, while a product needs to take a longer-term perspective. Especially in manufacturing-centric organizations, it is still a common assumption that at the end of the initial development project, the product is “ready” and can be handed over to a maintenance and operations team, eliminating the costs for expert developers. Such a transition will obviously cripple any long-term oriented, continuous advancement of the product (Fig. 17.4).

Fig. 17.4

Toward a real product organisation

Even if the product is initiated as a project in the early stages, it is key to remember the following:

• Use product-oriented KPIs from the beginning

• Implement a sustainable team setup with a 4 to 5-year perspective; this will continually evolve the product beyond the MVP

• View the project only as an administrative vehicle for initiating the product organization, but follow a product-oriented approach from the beginning

1.5 Organizational Culture

A key issue in most AIoT product organizations is the cultural differences typically found in heterogeneous teams that need to work together. Developers who are used to do frequent, cloud-enabled updates have a very different way of managing projects compared to manufacturing-centric engineers who know that after the SOP (Start-of-Production), any change to a physical asset after it has left the factory usually involves a costly and painful recall procedure. This “Clash of two worlds” within an AIoT product organization should not be underestimated. Actually, make this a “Clash of three worlds”: don not forget that the “AI people” usually also have a culture which is very different than the culture of the “cloud/software people”.

As shown in Fig. 17.5, different types of organizations typically have different types of cultures, even within the same company. Applying a one-size-fits all method to such a cultural mix will be difficult. This topic is discussed much more in-depth in the Agile AIoT section.

Fig. 17.5

Corporate cultures and Agile setup

2 Digital Equipment Operator (Fig. 17.6)

The organization of the Digital Equipment Operator will usually be very different than that of the Digital OEM. The focus is much less on development but mostly on integrating the solution with the existing assets and the existing business processes. This will be discussed in the following.

Fig. 17.6

DEO organization

2.1 Solution Provisioning

This part of the organization will heavily depend on the make vs. buy decision. In many cases, the AIoT-enabled solution will be sourced externally (or from a dedicated IT unit in the same company). In this case, the organization required will be relatively lightweight, focusing on requirements and provider management. If the decision is made to develop the solution with one’s own resources, the picture obviously looks different.

An interesting example for solution provisioning is discussed in the Bosch Chassis Systems Control (CC) case study. In this example, a dedicated team for building AIoT-enabled solutions for manufacturing optimization is established. This central team supports manufacturing experts in the different Bosch CC factories. The central team has AI and analytics experts who then team up with the manufacturing experts in the different locations to provide customized AIoT solutions.

2.2 Solution Retrofit

Particularly in cases where new hardware (e.g. sensor packs) must be deployed to existing assets, solution retrofitting becomes a huge issue, and must be supported with the right organizational setup. Take, for example, the railway operator who wants to roll out the escalator monitoring solutions to thousands of escalators in different train stations around the country. For this rollout, a dedicated rollout/retrofit organization will have to be established.

Depending on the complexity of the assets – how they are operationally utilized, and the scale of the rollout – this can be quite a significant organization. Of course, key questions include: for how long the rollout/solution retrofit organization must exist, and how the peak load during the initial rollout should be dealt with. Take, for example, an AIoT solution that needs to be retrofitted to all the trains in the railway operator’s network. Each train might only get a couple of hours of extra maintenance time every year. This will be quite a challenge for the team responsible for applying the retrofit to a fleet of thousands of trains.

2.3 Solution Utilization

Ultimately, the utilization of the AIoT-enabled solution is indeed the aspect that is of most interest to the Digital Equipment Operator, as it is where the business benefit is generated. Depending on the nature of the solution, this can involve a dedicated organizational unit, or be supported by an existing unit. New, AIoT-enabled analytics features might feed into an existing MRO (maintenance, repair and operations) organization. More advanced features, such as predictive maintenance, may already require some changes to the organizational setup because they will most likely have a more profound impact on the processes. For example, if the predictive maintenance solution actually predicts a potential failure, then the MRO organization must pick up this information and react to it. This process could be completely different than the traditional, reactive maintenance process.

If the AIoT solution offers a broader set of features to support Asset Performance Management (APM), then this will require a dedicated APM team to continually execute the performance optimizations.

Finally, if the AIoT solution feeds into other business processes, then business process re-engineering must be performed, and the new target processes must be supported by a suitable organizational setup. Take, for example, the AIoT-enabled flight path optimization system explained earlier. The introduction of such a system will have a significant impact on how the airline operates and touch many of its core processes.