Building Blocks for Technical Service 4.0
The Service-Meister team illustrates the digitalization of the manufacturing service industry – moving from products to service via AI building blocks.
Technical Service 4.0: Future Service
The German SME sector is undisputedly facing the greatest challenges in its history: the critical path that emerges here is characterized by waypoints such as a shortage of skilled workers, a massive increase in international competition, and strong pressure to adapt to modern, digital business models. These are certainly only the main drivers. There is most definitely need for substantial change in value chains, which many see as pivotal. However, this is easier said than done for German SMEs. Why is that the case?
The decisive difference in the approach in the corporate field between the big players and the true SMEs, in the narrower sense, can be condensed at this point into one single characteristic: Knowledge. Specifically, it is knowledge about how crucial smart services and digital products have become for maintaining a position in the international competitive arena. This means understanding how exactly to implement a shift from a traditional structure of offering predominantly analog products to offering smart services. The big players, with their large development, business intelligence, engineering and digitalization departments, have long understood this and are investing and positioning themselves accordingly. Based on this experience, the value chains can then be digitally transformed. If this approach of complete digitalization is transferred to the relevant segments in technical service, this can be called Service 4.0: technical service for Industry 4.0.
Digital aids from Service-Meister
The Service-Meister research project has been working since January 2020 to close the knowledge gap that exists in technical service 4.0 between German SMEs and global players, and to create support for SMEs. To this end, a generalized design layout was first developed for the entire technical service process. Fig. 1 shows the coherent sequence of all necessary segments for technical service. Here, the entire technical service process is broken down into individual, consecutive segments, each of which is then fully digitalized, thus enabling successive, automated processing of the entire service life cycle.
Fig. 1: Service 4.0, Technical Service within the Service Life Cycle
AI-based tools are being developed to cover the entire service life cycle as part of the Service-Meister project, and these can be used in the future to support technicians from the service area in their tasks. At the same time, this approach enables a practical implementation of the complete set of digital technical service processes for all Industry 4.0 applications. In order to successfully offer digital services on the Service-Meister platform in the future, it is first necessary to identify the value proposition – something which, based on current activities, will soon be completed. Once the state of Minimal Marketable Products has been achieved, there will be greater clarity with regard to what can be offered and the target customer group.
From products to service via building blocks
The starting point for such successful marketing is that the AI tools already developed for the service segments (see Fig. 1) – such as the tools for predictive analytics, ticket dispatching or the service bots – are sufficiently generalizable to be transferred from the project to other SME-wide service approaches and industries. This will enable Service 4.0 to be scaled across companies, since the services to be offered can be used across systems, departments, and companies.
Fig. 2: Generalized building blocks and a simple example excerpt from a code segment on a data science learning routine for anomaly detection (see. Fig. 1, segment 1).
The approach used to achieve the goal of generalizing the AI tools and digital services developed as far as possible is called “AI building blocks”. In software production, building blocks map encapsulated functionalities of software and thus enable the defined business requirements to be implemented successfully and repetitively. If the correct, appropriate building blocks are selected for an application, this usually leads to boosts in innovation, as well as improving the interaction of previously active system components and enhancing the performance of newly deployed applications.
In general, then, building blocks represent an encapsulation of clearly defined functions that fully meet the business requirements in an enterprise. They have the following properties:
- Properties and functions of building blocks are well specified
- Building blocks are interchangeable and reusable
- Published interfaces ensure maximum functionality
- Building blocks can be assembled with and from other building blocks
- Building blocks can interact with other building blocks
This is precisely the approach we are taking in the production of AI building blocks, by understanding the AI tools developed to date as generic functional units that can be used to fully map all segments of the service life cycle (see Fig. 1), while enabling high reusability and high combinability. This work will be fully completed in the fall of 2021, which means that a building block, which can be combined with other building blocks, will then be available for each service segment. From these modules, a wide variety of landscapes from the Service 4.0 area will be able to be freely combined.
Building block example: AI-based ticket creation and assignment
An example of an AI building block that has already been largely conceptualized to completion is detailed via the following generalized process structure in AI-based ticket creation and allocation (see Fig. 1, segment no. 2).
Fig. 3: Generalized program flow of life cycle element 2, AI-based ticket creation and assignment.
Nowadays, service requests are very often processed via ticket systems or case processing systems. These are software systems which, for example, record service requests from customers (e.g. "Printing machine not printing!") as small message modules, group these into relevant classes according to the type of problem, and then assign these messages to the correct technician groups with the request for problem handling. The further processes are illustrated by the step sequences in Fig. 3.
A service ticket can enter the system via a wide variety of input channels, such as email, telephone, direct system input, and a call center (see Fig. 3, step 1). It can have different states in the following, such as "in process" or "closed".
In step 2, the information from the tickets is extracted using Extract-Transform-Load (ETL) methods and pre-processed for further processing. In step 3, this pre-processed data is then passed to an AI component that performs an analysis on the data. Classifications are then performed in step 5. Between these two components, an interface for intermediate output can be attached. In step 6, further suggestions can be connected, which can then also be retrieved via an interface. The software flow chart suggested here is not stationary, but can be extended accordingly under different conditions at arbitrary places.
Multiple combinations for maximum service
On the Service-Meister platform, it will be possible in the future to book service and data products individually for each of the six segments. As they can be mapped by building blocks for AI tools, the structures and structural processes just described can in principle be combined in any way, meaning that this results in a basis for a service ecosystem that will be perfectly adapted to the processes of technical service. The free combinability of the individual service modules resulting from the life cycle will be one of the unique selling points for the Service-Meister platform; it is based on the high level of domain expertise that will have flowed into the generalized buildings blocks from the six different use cases from the Service-Meister project. The combinability of the service modules to the life cycle can be exemplified by the following:
- Predictive Analytics Module + Ticket Dispatcher Module (Fig. 1, segments 1+2)
- This would detect a service requirement and forward it as a service ticket. - Predictive Analytics Module + Ticket Dispatcher Module + Module 4, as illustrated in an example in Fig. 4 (Fig. 1, Segments 1+2+4)
- This would detect a service need case, create it as a service ticket and forward it, a chatbot would read the result to the technician or enter into a conversation with the technician at the service case on site. - Predictive Analytics Module + Ticket Dispatcher Module + Module 5 (Fig. 1, segments 1+2+5)
- This would detect a service call, create it as a service ticket and forward it, based on which a service report would be created automatically. - Etc.
Fig. 4: Example of Choice of Modules: Predictive Analytics Module + Ticket Dispatcher Module + Module 4
Interfaces for digital service ecosystems
When using the building blocks as freely combinable AI software modules, the complete and generalized specification of the desired properties and functions of the respective AI tool will be of crucial importance as will a secure interface connection. With this in mind, we are therefore focusing on open interface techniques for the applied service API, which we will use to define a standard for service apps in the future. This is certainly one of the conditions for the AI tools to then be able to be used in any combination with each other via plug and play, and thus a prerequisite for the integration of third-party offerings on the platform.
We are delighted to be working so successfully with our large consortium on the complete and scalable digitalization of service knowledge for Industry 4.0, and thus to be able to support the competitiveness of SMEs in technical service in the long term.
Dr. Fred Jopp has more than 20 years of experience in Big Data analytics and algorithm development in Applied Physics and Economics. As Head of Industrial Project Management at USU, he is responsible for the development and management of industrial projects in the field of Smart Services.
Christine Neubauer is Project Manager for AI and Industry 4.0 at eco – Association of the Internet Industry. Currently, she is working on the Service-Meister project, an AI-based Service Ecosystem for Technical Service in the Age of Industry 4.0. She is part of the project coordination team, with distributed tasks such as planning, steering, agile actions, reactions, internal and external communication, and stakeholder management.
Hauke Timmermann is Consultant for Digital Business Models and is the Project Lead for the Service-Meister project at the eco Association.
Andreas Weiss is Head of Digital Business Models at eco - Association of the Internet Industry. He started with eco in 1998 with the Competence Group E-Commerce and Logistics, moving afterwards to E-Business. Since 2010, he has been leading the eco Cloud Initiative as Director of EuroCloud Deutschland_eco and is engaged in several projects and initiatives for the use of artificial intelligence, data privacy, GDPR conformity, and overall security and compliance of digital services.
Please note: The opinions expressed in Industry Insights published by dotmagazine are the author’s own and do not reflect the view of the publisher, eco – Association of the Internet Industry.