Wie Sie Condition Monitoring wirtschaftlich nutzen
Strategische Ausrichtung, Vorgehensmodelle und Voraussetzungen

Thomas Müller

Durch die ständige mediale Präsenz von Industrie 4.0 und die damit verbundenen – nicht selten mit alarmierenden Botschaften versehenen – Handlungsempfehlungen erleben altgediente Themenfelder wie Condition Monitoring gewissermaßen eine Renaissance. Altgedient sind sie deshalb, weil die Ansätze aus Hersteller- und Betreibersicht schon seit vielen Jahren vorhanden sind, doch aus vielschichtigen Gründen nur eingeschränkt wertschöpfend umgesetzt werden können.

Lösungen von Softwareherstellern, welche Steuerungs- und Sensordaten in Echtzeit verarbeiten und visualisieren, gibt es zwischenzeitlich sehr viele. Durch eine Cockpit-Darstellung der Performance-Daten an der Maschine selbst oder in einem Portal entsteht jedoch noch kein darstellbarer Mehrwert. Manche weiterentwickelten Lösungen verschicken anhand definierbarer Schwellwerte Benachrichtigungen per SMS oder E-Mail. Aber was nützt eine Benachrichtigung, wenn sie nicht gelesen oder von den richtigen Fachexperten und Beteiligten im richtigen Prozesskontext verarbeitet wird? Stark vereinfacht ausgedrückt: Was nützt die Information, dass demnächst ein Kugellager getauscht werden muss, wenn dies nicht bestellt, nicht geliefert und dafür kein Wartungsfenster geplant wird? 

Eine weitere, noch wesentlich wichtigere Frage ist: Wie kann man aus welchen Echtzeit-Daten, durch welche Algorithmen einen tatsächlichen Mehrwert für wen schaffen, der sich letztendlich auch als Geschäftsmodell-Baustein in ein Service-Produkt umsetzen lässt? 


Remote Service und Condition Monitoring zum Selbstzweck 

Bislang wurden Remote Service oder Condition Monitoring-Lösungen größtenteils zur Überwachung von Maschinenzuständen genutzt. Diese Möglichkeiten werden gerne von Herstellern innerhalb der Gewährleistung genutzt, um Reaktionszeiten einzuhalten oder den Anlaufbetrieb beim Kunden zu unterstützen. In der Produktion leisten diese Lösungen vornehmlich einen Beitrag zur Instandhaltung oder sie werden zur ansatzweisen Optimierung der OEE (Overall Equipment Efficency) genutzt. Ein Ziel aus Hersteller- und Betreibersicht ist es unter anderem im Bereich Predictive Maintenance, die vorausschauende Wartung bzw. Instandhaltung zu verorten. In der Praxis werden diese Ziele jedoch nur ansatzweise erreicht – besonders, weil es an den erforderlichen Algorithmen zur automatischen Muster- und Abweichungserkennung mangelt und die Handlungsempfehlungen und Prozesse nicht automatisiert bzw. digitalisiert werden können. 

In der Tat birgt der Weg von der Zustandsüberwachung zu automatisierten, vorausschauenden Handlungs- oder Planungsempfehlungen sowohl im fachlichen wie auch im organisatorischen Bereich einige Herausforderungen. Hervorgehoben sei hier, dass für Hersteller solche Themen Potenzial für neue, bezahlte Dienstleistungen (datenbasierte Services) bieten. Dieses zu heben und umzusetzen gelingt jedoch nur den wenigsten und auch nur bei einer überschaubaren Kundenschicht. Oftmals sind es auch ausschließlich Individualentwicklungen, die sich kaum auf andere Kunden- oder Marktsegmente übertragen lassen. Speziell Anlagenhersteller tun sich aufgrund der Komplexität der Produkte und einem hohen Anteil an externem Knowhow von Zulieferern erfahrungsgemäß besonders schwer. 


Bild 1: Vorgehensmodell für datenbasierte „Smart Service“-Produkte


Durch die wachsende Verfügbarkeit von Daten, Schnittstellen und Infrastruktur zur Vernetzung und Datenakquise bei konstant sinkenden Preisen stellt die Technologie mittlerweile jedoch kein großes Hindernis mehr dar. Leider bestehen weiterhin die Herausforderungen in der Ausprägung von Nutzen, der sinnvollen Verarbeitung der dazu erforderlichen Daten, der organisatorischen Implementierung und der Gestaltung von tragfähigen Business-
Cases. Dafür gibt es auch in der heutigen Zeit noch keine Softwarelösung, die einem diese Arbeit abnimmt. 

Um losgelöst von Software ein Engineering für Smart Services im Unternehmen zu verankern und operativ zu implementieren, kann man jedoch auf Vorgehensmodelle, Methoden und Werkzeuge zurückgreifen. 


Schritt 1: Verankerung eines Werte- und Nutzenversprechens 

Der erste Schritt zu einer erfolgreichen Entwicklung und Umsetzung von datenbasierten Services, die auch auf einem bereits vorhandenen Condition Monitoring oder einer Remote Service-Lösung aufsetzen können, ist die Verankerung und Abbildung von Zielen, Werte- und Nutzenversprechen sowie einer Mission / 
Vision in der Unternehmens-Strategie. Das ist vor allem wichtig, um datenbasierte Services als Business-Case zu entwickeln. Dabei ist auf der einen Seite ein interdisziplinäres, einheitliches Verständnis der Zielbilder erforderlich. Andererseits sind zur Erbringung und Sicherstellung der Dienstleistungen neue, funktionale Prozesse entscheidend, die eine sogenannte Silo-Organisation horizontal durchlaufen. 

Des Weiteren werden in der Phase der Ideenfindung bzw. Prototypisierung von Anwendungen und Business-Cases in den Workshops verschiedene Rollen und Sichtweisen eingenommen, um den realen Bedürfnissen der verschiedenen Nutzer (Stakeholder) in den unterschiedlichen Kundensegmenten möglichst nahe zu kommen. Damit die Rollen und die Ergebnisse stringent den strategisch verankerten Zielbildern folgen, ist ein einheitliches Verstehen diesbezüglich unabdingbar. 


Bild 2: Der Design-Thinking-Prozess

Schritt  2: Bedürfnisse der Stakeholder noch besser verstehen 

Eine gern angewandte Redewendung, wenn man über das Kerngeschäft spricht, ist:  „Den klassischen Kunden gibt es nicht“. Wenn man über Dienstleistungen basierend auf (Echtzeit-)Daten, z. B. in Bezug auf Condition Monitoring, spricht, erhält diese Floskel jedoch ein neues Gewicht. In diesem Fall unterteilt man die klassische Kundenmenge nicht nur in Bedarfs-, Markt- oder Produktsegmente, sondern in ein Stakeholder Diagramm. Dabei wird hinterfragt, welche Rolle bei welchen Kunden welches Bedürfnis hat. Außerdem werden die Anforderungen eines Instandhalters und die eines Produktionsleiters bzw. die Ansprüche eines Maschinenoperators von denen eines Qualitätsmanagers unterschieden. Des Weiteren werden jegliche Rollen in einem Unternehmen wie Eigentümer, Dienstleister, Logistiker etc. betrachtet. 

Um den Nutzen herauszufinden, gilt es die eigene Ist-Geschäftsarchitektur genauer zu betrachten. Dazu kann ein Business Model Canvas benutzt werden, welches das Ist-Geschäftsmodell u. a. in Schlüsselaktivitäten, Partner, Wertangebote, Kundensegmente und -kanäle strukturiert. Aus diesem Canvas können dann Rollen in einem Stakeholder Netzwerk Diagramm abgeleitet werden, in welchem die unterschiedlichen Rollen mit den jeweiligen Bedürfnissen analysiert und strukturiert abgebildet werden. Dies schafft die Voraussetzung für Kreativarbeit im Design- und Data Thinking-Prozess, bei welchem Ideen und Proto-
typen mit hohem Nutzen- und Wertansatz entstehen. In diesem Prozess ist alles erlaubt. Selbst ein Plattformgedanke für Dienst-Ideen, die bisher noch nicht im Ist-Geschäftsmodell vorkamen, wird betrachtet und darf nicht von vorne herein ausgeschlossen werden. 

Dieses Rollenspiel soll auch dazu dienen, bisherige Blockaden in Bezug auf Datensicherheit und -schutz, welche in der Regel ausschließlich von der IT aufgebaut werden, durch wirtschaftlichen Mehrwert und Nutzen, der für möglichst viele Stakeholder-Rollen entsteht, zu lösen. Auch hierfür gibt es verschiedene Modelle. 


Schritt 3: Neue Wege, Ideen und Methoden für neue Datennutzung 

Zur erfolgreichen Entwicklung von neuen Diensten und datenbasierten Applikationen, ist es erforderlich, bewährte wie auch neue Wege
zu gehen. Das klassische Requirement-Engineering genügt oftmals nicht, um innovative Ansätze in agilen Verfahren jenseits der klassischen Software-Entwicklung auszuprägen. Eine erfolgversprechende Methode ist das Design-Thinking. Dieser Ansatz hat sich aus der nutzerorientierten Denkweise von Designern weiterentwickelt und basiert auf der Annahme, dass Ideen, die interdisziplinär, experimentell und konsequent nutzerorientiert entstehen, erfolgreich sind. Die Methode beschreibt prinzipiell einen kreativen Prozess der Prototypisierung, der sich aus agilen und Wasserfall-Vorgehensweisen zusammensetzt. 

Im Prototyping für Dienstleistungsprodukte geht es dabei im Wesentlichen um die Ausgestaltung von erlebnisorientierten Innovationen mit wirtschaftlichem Mehrwert. Diese basiert auf den Rollenprofilen und -bedürfnissen aus den in Schritt 1 erstellten Profilen innerhalb eines Stakeholder-Netzwerk-Diagramms. Dabei steht ein ausgeprägter Kunden- bzw. User-zentrischer Ansatz im Mittelpunkt. Innerhalb der Workshops werden – fokussiert auf die Anwendersicht – die verschiedenen Rollen und deren Standpunkte eingenommen. Hierzu kommen innerhalb der jeweiligen Phasen von der Ideengenerierung bis zur Prototypisierung verschiedene Tools (z. B. Customer-Journey-Mapping, 6 Denkhüte, Pecha Kucha) zum Einsatz. 

Die Vorgehensweise bei Design-Thinking teilt sich in zwei sogenannte Räume auf. Der erste wird als „Problemraum” bezeichnet, in welchem zunächst möglichst viele Ideen generiert und danach in einer Synthese auf die herausgearbeiteten Standpunkte und Zielstellungen der jeweiligen Stakeholder konvergiert werden. Der zweite Bereich ist der „Lösungsraum”, in dem die konvergierten Ideen als Storyline zum späteren Data-Thinking prototypisiert werden. Die Prototypisierung orientiert sich ebenfalls an einem methodischen Prozess, in dem alle Aspekte von der Design-Challenge über die technologischen Anforderungen bis hin zum Geschäftsmodell erarbeitet werden. Auch hier gibt es eine divergierende und eine konvergierende Phase, in der zunächst viele Prototypenbeschreibungen erstellt werden. Aus diesen werden danach in einer Synthesephase nur diejenigen zur Übergabe in das Data-Thinking selektiert, die den im Problemraum definierten Standpunkten, Lösungen sowie Zielstellungen entsprechen und für die es eine Geschäftsmodellgrundlage gibt. 


Bild 3: Industrial Data Analytics

Schritt 4: Big Data-Vorgehensmodell zur Algorithmenentwicklung 

Aufbauend auf die konvergierten Ideen aus der Design Thinking-Phase kann mit der weiteren Prototypisierung der Applikationen und Business Cases begonnen werden. Nun geht es darum, die Algorithmenentwicklung methodisch und prozessorientiert zur funktionalen Prototypisierung zu bringen. 

Hierbei werden ähnlich wie im Prozess-Management den jeweiligen Aufgaben Rollen zugeordnet. Die Business Lane verantwortet das Storyboard, die gemeinsam mit dem Data Scientist definiert, welche Daten aus welchen Quellen zur Realisierung der Idee in den Data  Lake überführt werden müssen. Die Data Science-Rolle muss hierbei nicht an eine Person gebunden sein – es kann auch ein Team aus Steuerungsentwicklern, Business IT und Hardwarespezialisten gebildet werden.

Ein Tool bei der Entwicklung eines Data-Lake kann auch die „Diagnose und Parameter Matrix“ sein, die innerhalb der Idee festlegt, welche Daten in welchen Zyklen wo und mit welcher Technologie erfasst und bereitgestellt werden müssen. 

Das reicht z. B. von der Stromaufnahme eines Elektromotors bis zum Schwingverhalten einer Antriebswelle. Dabei wird auch definiert, ob zusätzliche Sensorik oder weitere Erfassungsgeräte zum Einsatz kommen müssen und welche Investitionen und Ressourcen hierzu erforderlich sind 

Dies wird im nächsten Schritt in der „Data Lake Creation“-Phase der „Technology Lane“ zugeordnet, die primär die Aufgabe hat, die Infrastruktur zu definieren und aufzubauen. Dabei sollen nicht nur Maschinen- und Echtzeitdaten betrachtet werden – auch historische Daten und Daten aus den Geschäftsprozessen können innerhalb der Storyline eine bedeutende Rolle spielen. Ein wichtiger Aspekt bei der Ausprägung eines Data Lake sind unter anderem die Zeitachse und die Datenmenge. Um eine verlässliche Analyse von Ausreißern und Mustern ab- und auszubilden – was letztendlich in Phase 4 in einen automatisierten machine
learning-Prozess überführt werden soll – sind große Datenmengen über einen längeren Zeitraum erforderlich. Dies dient auch einer agilen Prototypisierung, um die festgelegten Parameter und die Ergebnisse immer wieder mit der Storyline zu spiegeln, ob die Erwartung aus der Idee erfüllt wird. Dies wird später von der Business-Lane betrachtet, um letztendlich durch Erfüllung der Annahmen und Erwartungen mit der Ausprägung eines finalen Prototyps zu beginnen, der schließlich auch als Business-Case oder Produkt in eine Projektplanungs- und Implementierungsphase übertragen werden kann. Dann werden auch weitere Kriterien in einer „Capability-Map“, wie z. B. die prozessuale und fachliche Ausgestaltung innerhalb der Organisation, beschrieben und festgelegt. 


Ausblick

Der Zielpfad vom Condition Monitoring zu messbarem, wirtschaftlichem Nutzen oder zu neuen Dienstleistungs-Geschäftsmodellen ist in mehrstufigen Schritten in verschiedenen Richtungen zu beschreiten. Die technologischen Voraussetzungen zu schaffen, bildet im Zeitalter des Internet of Things keine Hürden mehr. Die Möglichkeiten der Vernetzung und die Verfügbarkeit günstiger Technologien eröffnen vielfältige Möglichkeiten. 

Damit ein Mehrwert und eine Grundlage für Business-Cases ausgebildet werden kann, sind eine strategische Verankerung und ein methodisches Vorgehen erforderlich. Wenn diese in Kreativarbeit in Form von bedarfsorientierten Applikationen prototypisiert sind, dann kann mit der Generierung von nutzenorientierten Data-Lakes zielorientiert begonnen werden. Dabei steht immer der Business-Nutzen als User Story im Vordergrund, welche die Daten-Quellen und das Data-Engineering zur Algorithmen-Entwicklung maßgeblich bestimmt. Die User Story ist hierbei nicht eindimensional – auch die Change-Faktoren in der internen Organisation sind hier mit einzubeziehen, damit die dafür erforderlichen Rollen und Prozesse beschrieben und die Implementierungsvoraussetzungen geschaffen werden können. 

Entscheidend dabei ist es, interdisziplinäre Rollen aus Technik, Mathematik, Business Development und Organisationsentwicklung in einem prozessorientierten Vorgehen richtig zu orchestrieren, damit die richtigen Informationen an der richtigen Stelle Mehrwert abbilden und kein nutzloser oder unbeherrschbarer „Overhead“ entsteht.

Schlüsselwörter:

Condition Monitoring, Big Data, Digitalisierung, Industrie 4.0, Design Thinking, Proto- typing, Internet of Things, Data Analytics

Literatur:

[1] Osterwalder, A.; Pigneur, Y.: Business Model Generation. Ein Handbuch für Visionäre, Spielveränderer und Herausforderer. Frankfurt New York 2011, S. 48.