Operations

Abstract

Providing efficient and effective service operations will be a key success factor for any AIoT-enabled product or solution. Depending on the specific nature of the system, service operations setup can potentially take very different shapes. For complex, industrial assets, service operations will most likely include direct customer interactions via a call center, as well as on-site maintenance or repair services. For mass-market consumer products, service operations will most likely be highly automated and provide only limited field services, if any. Most Field Service Management (FSM) organizations will be able to greatly benefit from AIoT-enabled features, which provide real-time access and advanced analytics of asset-related field data, or even support for predictive or preventive maintenance services.

Providing efficient and effective service operations will be a key success factor for any AIoT-enabled product or solution. Depending on the specific nature of the system, service operations setup can potentially take very different shapes. For complex, industrial assets, service operations will most likely include direct customer interactions via a call center, as well as on-site maintenance or repair services. For mass-market consumer products, service operations will most likely be highly automated and provide only limited field services, if any. Most Field Service Management (FSM) organizations will be able to greatly benefit from AIoT-enabled features, which provide real-time access and advanced analytics of asset-related field data, or even support for predictive or preventive maintenance services.

Since the operations perspective will usually be quite different for the Digital OEM vs. the Digital Equipment Operator, this chapter will look at both perspectives.

1 Digital OEM (Fig. 16.1)

The operations perspective of the Digital OEM and his AIoT-enabled products will include a number of different elements. The sales organization will be responsible for supporting the new, digital-enabled features and services. The support organization must be able to handle the added product complexity. Finally, the DevOps organization must be able to continuously enhance and optimize the digital product offering.

Fig. 16.1

Operations

1.1 Sales

Understanding digital transformation from a sales perspective is essential for its success. The Digital OEM is presented with many opportunities, which must be properly adopted by the sales organization.

AIoT will provide the sales and marketing organization with the opportunity to truly understand how customers are using the products in the field. Together with other data, e.g., from web analytics, CRM and social media, this will enable the sales and marketing organization to better target new and existing customers, e.g., for upselling newly available, digital-enabled features (Fig. 16.2).

Fig. 16.2

AIoT-enabled sales organization

1.2 Support

Providing AIoT-enabled digital features can significantly increase a product’s complexity. While it should be a core duty of the DevOps team to ensure the best possible user experience, there is a good chance that the new, digital features will cause additional customer requests to the support organization. There is nothing more frustrating for a customer buying a smart, connected product – let us say a vacuum robot – and then failing to get it to work, e.g., because of a pairing problem, or some other issue. Connectivity alone can be a source for many problems, which need to be addressed by the support organization. Especially for mass-market products, an efficient triage to manage the combination of internet FAQs, automated bots and potentially call center services will be important.

The support organization must also be prepared to deal with new, unexpected problems. For example, the use of AI in a smart, connected product might lead to problems that will initially be very hard to reproduce because the product is no longer following the deterministic logic encoded in the software (but rather is driven by an AI that is a black box in that regard).

Finally, the support organization should be supported with AIoT-enabled problem analytics and diagnostics. This will have to be provided by the DevOps team, which needs to focus not only on the product features but also on how to support the rest of the organization with AIoT-based features.

1.3 DevOps

While DevOps has the word operations in its name, the focus of the DevOps organization is usually on developing and operating smart, connected products. As discussed in the previous section, the focus of the DevOps team is usually on continuously improving the features of the product. However, one should not underestimate the importance of ensuring that the DevOps organization also supports the other parts of the operations side. In particular, the DevOps team will be responsible for providing sales, marketing, and support organizations with the required capabilities. Together, they need to identify which additional features – beyond the features important and visible to the end-user – will have to be built. The earlier example of seat-heating-on-demand applies here, where the DevOps team will not only have to build the feature itself but also implement dynamic pricing together with the sales team and build suitable in-app promotions in collaboration with the marketing team. Similarly, the DevOps team will be responsible for providing the support team with the required data, analytics reports and applications.

2 Digital Equipment Operator (Fig. 16.3)

The Digital Equipment Operator will usually have a different perspective on the operations of the AIoT-enabled solution. This will most likely include field services related to assets in the field, IT Service Management related to the AIoT solution, and supplier management for the AIoT solution.

Fig. 16.3

Service operations

2.1 Field Service Management

Field service management (FSM) focuses on enterprise assets, e.g., operational equipment, machines and vehicles. FSM is described by Gartner [16] as a practice that “includes the detection of a field service need (through remote monitoring or other means, inspection or a customer detecting a fault), field technician scheduling and optimization, dispatching, parts information delivery to the field, and process support of field technician interactions.”

Figure 16.4 outlines how AIoT and FSM can play together. FSM can benefit from AIoT in a number of areas, including:

• Improved triage: Utilize AIoT to determine the severity and priority of asset-related incidents.

• Faster identification of required parts: Utilize AIoT for precise identification of assets and key parts deployed in the field.

• Inventory tracking: Utilize AIoT to create a precise and real-time inventory update.

• Initiation of automated intelligent dispatch events: Utilize AIoT to better prioritize incidents and to provide more information for problem resolution.

• Remote monitoring and diagnostics: Use real-time machine data for asset health and performance assessments.

All of this will only be possible if the AIoT project prepares the service operations organization accordingly. This will be one of the big challenges of the AIoT project management team. How to do this will greatly depend on a number of different factors, including:

• Is there already an existing organization responsible for FSM?

• If so, how is the organizational relationship between the IoT solution project and the existing FSM organization?

• If not, how far is the IoT solution project empowered to actually set up a new FSM organization to start operating after the start of production?

• Will the focus be mainly on operational FSM topics, or will it also include strategic topics such as Asset Performance Management (APM)?

Fig. 16.4

AIoT & field service management

2.2 IT Service Management

Another important dimension of AIoT Service Operations will be what is traditionally referred to as IT Service Management (ITSM). AIoT-ITSM will be responsible for ensuring the design, planning, delivery, operations, and management of all IT services related to the AIoT-enabled system. This means that AIoT-ITSM is not concerned with operating assets but rather enables the AIoT-features themselves. A well-established standard in the ITSM space is ITIL, the Information Technology Infrastructure Library. Without AIoT-ITSM, an AIoT system cannot be operated, which will be covered below.

ITIL defines five processes and four functions. The four functions are service desk, technical management, application management, and IT operations management. The five service operations processes are [17]:

• Access Management: grants authorized users the right to use a service; blocks any access request of non-authorized users to the service

• Event Management: captures, filters, and categorizes events to decide the appropriate actions to be taken. Events might or might not require an action.

• Incident Management: Incidents are events that have a negative impact on a service or its quality. Incident management helps restore IT service to a working state as quickly as possible.

• Problem Management: deals with identifying and addressing problems at their root. Multiple incidents can relate to the same problem.

• Request Fulfilment: responsible for acknowledging and processing service requests received from users. Usually, these are technical requests, not requests related to the functionality of business applications.

To manage all IT assets and other related data, ITIL foresees the use of a so-called configuration management database (CMDB) as the central repository for this kind of information. However, the complexity of introducing a CMDB should not be underestimated. Rouse [18] warns that CMDB projects often fail due to stale and unusable data. This is certainly an aspect that needs to be addressed, ideally by automating configuration data management as much as possible. Figure 16.5 provides an overview of how some key ITIL concepts can be applied to the AIoT perspective.

Fig. 16.5

AIoT & IT service management

The architecture and organization for the supporting systems of the service operation will always be highly project-specific. However, the following discussion can provide some guidance regarding the architectural setup.

A key question is as follows: will there be separate AIoT-ITSM and FSM organizations, or will they be merged into one organization? While process-wise there might be similarities, the required skills will usually be very different. For example, the skills required to deal with the IP configuration of an IoT gateway or to keep a time series database running are very different than, for example, the skills required to analyze and repair the malfunction of an escalator. Consequently, the project must make a deliberate decision on how to organize AIoT-ITSM and FSM.

2.3 Option 1: Separate Systems

If it is decided that AIoT-ITSM and FSM will be two separate organizations, it can also make sense to run two separate support systems. As an example, a simplified monitoring solution for excavators is shown in Fig. 16.6, using some form of IoT gateway on the excavator. Both the FSM application and the AIoT-ITSM application have their own databases, receiving data from the gateway/TCU. The AIoT-ITSM solution uses some form of CMDB to store information related to the configuration items that make up the IoT solution (e.g., an inventory of gateways in the field, with related incidents). The FSM solution stores asset-related data, e.g., performance data from the hydraulics component of the excavator. Both solutions then have their dedicated and specialized staff, which supports their respective services.

Fig. 16.6

Architecture: separate systems

2.4 Option 2: Integrated System

For strategic reasons, it can make sense to integrate AIoT-ITSM and FSM into the same organization, supported by an integrated system. In this case shown in Fig. 16.7, only one repository is used, which stores both asset-related and IoT enablement-related data. The back office supports all functions, and so is the field service. Of course, these are only two examples of a potential organizational setup; in reality, many other, potentially hybrid combinations could be possible. However, these examples serve the purpose of highlighting the issue and the choices an AIoT project manager must make.

Fig. 16.7

Architecture: integrated systems

2.5 Supplier Management

Finally, the operations side also needs to take care of managing the supplier of the AIoT-enabled solution. Chances are that the operator will not have development resources himself and therefore requires an internal or external supplier to provide the solution. In some cases, the operator will have a team within his own organization, in which case the DevOps discussion from the previous chapter can also be applied here. However, in the likely case that the solution comes from another – internal or external – division, then the operator must build an effective supplier management function. Duties will include requirements management, sourcing, and dealing with additional or changing requirements.

Take, for example, the railway operator example from the Introduction section. In this case, the railway operator acquired an AIoT-enabled solution for escalator monitoring. It is highly likely that this solution will be externally sourced, so supplier management becomes an integral part of the railway operator’s organization. Ensuring the integration of the external escalator monitoring solution with the internal systems of the railway operator will be one key responsibility of this team.

Another interesting question will then be who will take on the responsibility for the IT service management of the escalator monitoring solution: will this be done in-house, or will the railway operator have a long-term support contract with the provider of the escalator monitoring solution? If this requires in-depth knowledge about other operational systems, then there is a good chance that at least parts of system operation (including the IT service management) will be in-house.