(Created page with "<imagemap> File:0.2-Operations.png|1200px|frameless|center|Operations rect 0 0 686 128 More... rect 2735 128 3539 257 More......")
 
 
(23 intermediate revisions by 3 users not shown)
Line 6: Line 6:
rect 2735 257 3539 390 [[Product_/_Solution_Design|More...]]
rect 2735 257 3539 390 [[Product_/_Solution_Design|More...]]
rect 2735 385 3539 518 [[Co-Creation|More...]]
rect 2735 385 3539 518 [[Co-Creation|More...]]
rect 2735 518 3539 651 [[Agile_AIoT_Grid|More...]]
rect 2735 518 3539 651 [[Rollout_GTM|More...]]
rect 2857 757 3255 837 [[Product_Operations|More...]]
rect 2857 757 3255 837 [[Product_Operations|More...]]
rect 2857 837 3375 988 [[Service_Operations|More...]]
rect 2857 837 3375 988 [[Service_Operations|More...]]
rect 2735 992 3539 1120 [[Product_Organization|More...]]
rect 2735 992 3539 1120 [[Product_Organization|More...]]


desc bottom-left
desc none
</imagemap>
</imagemap>


__NOTOC__
__NOTOC__


== AIoT Framework: Service Operations ==
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.
Providing efficient and effective service operations will be a key success factor for any AIoT-enabled product or solution. Depending on specific nature of the system, the 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 are providing real-time access and advanced analytics of asset-related field data, or even support for predictive or preventive maintenance services.
 
A second 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 about operating the assets, but rather about enabling the AIoT-features themselves. A well-established standard in the ITSM space is [https://en.wikipedia.org/wiki/ITIL ITIL], the Information Technology Infrastructure Library. Since without AIoT-ITSM an AIoT system can not be operated, it will be looked at first in the following.


__TOC__
__TOC__


=== Sales <span id="Sales"></span>===
= Sales <span id="Sales"></span>=
Understanding the 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.
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.  
 
[[File:3.4-Sales.png|800px|frameless|center|AIoT-enabled Sales Organization]]
 
A good example is Seat Heating as a Feature-on-Demand. OEMs are starting to create business cases such as this one, where they will equip the physical asset with certain features as a standard, and then make them available as a subscription service on demand. The extra cost of equipping every asset with the same hardware configuration must be offset by the cost savings for steamlining the product process (it actually costs money to be able to make a feature such as Seat Heating a custom option), plus the average revenue from the subscription services.
 
[[File:3.1-SalesOnDemand.png|800px|frameless|center|Example: Seat Heating as Physical-Feature-on-Demand]]
 
=== FSM: Field Service Management ===
Field service management (FSM) is focusing on enterprise assets, e.g. operational equipment, machines and vehicles. FSM is described by Gartner <ref name="gartner" /> 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.”
 
[[File:3.4-FSM.png|800px|frameless|center|AIoT & Field Service Management]]
 
The figure above 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 for creating 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 is preparing the service operations organization accordingly. This will be one of the big challenges of the AIoT project management team. How to do this will depend strongly 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 like Asset Performance Management (APM)
 
=== AIoT-ITSM: IT Service Management for AIoT ===
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<ref name="brahmachary" />:
* Access Management: grants authorized users the right to use a service; blocks any access request of nonauthorized 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 the IT service to 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 <ref name="rouse" />
warns that CMDB projects often fail due to stale and unusable data. This is certainly an aspect which needs to be addressed, ideally by automating configuration data management as far as possible. The figure below provides an overview of how some key ITIL concepts can be applied to the AIoT perpective.
 
[[File:3.4-ITSM.png|800px|frameless|center|AIoT & IT Service Management]]


=== Architectural Options ===
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.
The architecture 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: 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 be usually very different. For examples, 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 excavator hydraulic component. Consequently, the project must make a deliberate decision on how to organize AIoT-ITSM and FSM.
[[File:3.4-Sales.png|800px|frameless|center|link=|AIoT-enabled Sales Organization]]


==== Separate Systems ====
= Support =
If it is decided that AIoT-ITSM and FSM will be two separate organizations, it can make sense to also run two separate support systems. As an example, a simplified monitoring solution for excavators is shown, using some form of gateway or TCU 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 is using 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 is supporting their respective services.


[[File:3.4-Architecture-Separate.png|800px|frameless|center|Architecture: Seperate Systems]]
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.


==== Integrated System ====
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).
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, only one repository is used, which stores both, asset-related and IoT-enablement related data. The back office is supporting 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, the examples serve the purpose of highlighting the issue and the choices an AIoT project manager must make.


[[File:3.4-Architecture-Integrated.png|800px|frameless|center|Architecture: Integrated Systems]]
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.


== References ==
= DevOps =
<references>
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.
<ref name="brahmachary">''[https://www.certguidance.com/itil-service-strategy-explained-brief/ ITIL Service Operation Processes Explained]'', A. Brahmachary, 2018</ref>
<ref name="rouse">''[https://searchdatacenter.techtarget.com/definition/configuration-management-database Definition: CMDB - Configuration Management Database]'', M. Rouse, 2017</ref>
<ref name="gartner">''[https://www.gartner.com/en/information-technology/glossary/field-service-management FSM Definition]'', Gartner Group, 2019</ref>
</references>


== Authors and Contributors ==
= Authors and Contributors =


{|{{Borderstyle-author}}
{|{{Borderstyle-author}}
|{{Designstyle-author|Image=[[File:Dirk Slama.jpeg|left|100px]]|author={{Dirk Slama|Title=AUTHOR}}}}
|{{Designstyle-author|Image=[[File:Dirk Slama.jpeg|left|100px]]|author={{Dirk Slama|Title=AUTHOR}}}}
|}
|}

Latest revision as of 15:47, 16 November 2021

More...More...More...More...More...More...More...More...Operations


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.

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.

AIoT-enabled Sales Organization

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.

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.

Authors and Contributors

Dirk Slama.jpeg
DIRK SLAMA
(Editor-in-Chief)

AUTHOR
Dirk Slama is VP and Chief Alliance Officer at Bosch Software Innovations (SI). Bosch SI is spearheading the Internet of Things (IoT) activities of Bosch, the global manufacturing and services group. Dirk has over 20 years experience in very large-scale distributed application projects and system integration, including SOA, BPM, M2M and most recently IoT. He is representing Bosch at the Industrial Internet Consortium and is active in the Industry 4.0 community. He holds an MBA from IMD Lausanne as well as a Diploma Degree in Computer Science from TU Berlin.