Strategie, Vorgehen und Voraussetzungen
Condition Monitoring wirtschaftlich nutzen
Im Rahmen der Diskussionen um Industrie 4.0 erlebt Condition Monitoring eine Renaissance. Man feiert deshalb ein Comeback, weil es die Ansätze aus Hersteller- und Betreibersicht an sich schon seit vielen Jahren gibt. Sie wurden jedoch viel zu selten wertschöpfend eingesetzt.
Softwarehersteller bieten zwischenzeitlich sehr viele Lösungen an, die Sensor- und Steuerungsdaten in Echtzeit verarbeiten und visualisieren. Es entsteht jedoch noch kein Mehrwert allein durch die reine Cockpit-Darstellung der Performance-Daten an der Maschine selbst oder in einem Portal. Es gibt bereits weiterentwickelte Lösungen, welche anhand definierter Schwellenwerte Benachrichtigungen per E-Mail oder SMS verschicken. 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 es nicht bestellt, nicht geliefert und kein Wartungsfenster dafür geplant wird? Eine noch wichtigere Frage ist: Wie kann man aus welchen Echtzeit-Daten, durch welche Algorithmen einen tatsächlichen Mehrwert für wen schaffen? Und wie lässt sich dieser als Geschäftsmodell-Baustein in ein Service-Produkt umsetzen?
Erweiterte Möglichkeiten durch neue Technologien
Bisher wurden Remote Service- oder Condition Monitoring-Lösungen vorwiegend 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 Anwender zu unterstützen. In der Produktion leisten diese Lösungen vornehmlich einen Beitrag zur Instandhaltung oder sie werden zur ansatzweisen Optimierung der Overall Equipment Efficency (OEE, oder oft Gesamtanlageneffizient) genutzt. Ein Ziel aus Hersteller- und Betreibersicht ist die vorausschauende Wartung bzw. Instandhaltung. In der Praxis werden diese Ziele jedoch meist nur ansatzweise erreicht - besonders, weil es an den erforderlichen Algorithmen zur automatischen Muster- und Abweichungserkennung mangelt. Zusätzlich ist es vielen nicht möglich, Handlungsempfehlungen und Prozesse zu automatisieren noch diese zu digitalisieren. In der Tat hält der Weg von der Zustandsüberwachung zu automatisierten, vorausschauenden Handlungs- oder Planungsempfehlungen sowohl im fachlichen als auch im organisatorischen Bereich einige Herausforderungen bereit. Dabei bieten solche Themen den Herstellern das Potenzial für neue, bezahlte Dienstleistungen im Sinn von datenbasierten Services. Dieses zu heben gelingt nur selten und auch nur bei wenigen Kunden. Oft sind es zudem Individualentwicklungen, die sich kaum auf andere Kunden- oder Marktsegmente übertragen lassen. Speziell Anlagenhersteller tun sich aufgrund der Komplexität ihrer Produkte und einem hohen Anteil an externem Know-how von Zulieferern erfahrungsgemäß besonders schwer. 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. Weiter bestehen die Herausforderungen, den Nutzen auszuprägen, die erforderlichen Daten sinnvoll auszuwerten und tragfähige Business-Cases zu gestalten und auszurollen. Diese Arbeit übernimmt auch heute noch keine Software. Um losgelöst von Software ein Engineering für Smart Services im Unternehmen zu verankern, kann man jedoch auf Vorgehensmodelle, Methoden und Werkzeuge zurückgreifen.
1. Ziele. Werte. Nutzen.
Der erste Schritt zur 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 strategieschen Vision. 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 des Ziels erforderlich. Andererseits braucht es für solche Dienstleistungen neue, funktionale und horizontale Prozesse. Zudem sollten bei der Ideenfindung und der Prototyp-Erstellung von Anwendungen und Business-Cases verschiedene Sichtweisen eingenommen werden, um den unterschiedlichen Bedürfnissen der Nutzer möglichst nahe zu kommen.
2. Anforderungen. Rollen. Bedürfnisse.
Bei Dienstleistungen auf der Basis von (Echtzeit-) Daten lässt sich die klassische Anwendermenge nicht nur in Bedarfs-, Markt- oder Produktsegmente unterteilen, sondern auch in ein Nutzer-Diagramm eintragen. Dabei wird hinterfragt, welche Rolle bei welchen Anwendern welches Bedürfnis hat. Außerdem werden die Anforderungen eines Instandhalters und die eines Produktionsleiters sowie die Ansprüche eines Maschinenbedieners von denen eines Qualitätsmanagers unterschieden. Weitere Rollen in einem Unternehmen sind Eigentümer, Dienstleister und Logistiker. Der Nutzen ergibt sich erst mit dem Blick auf die eigene Geschäftsarchitektur. Dazu kann ein 'Business Model Canvas' benutzt werden, der das Geschäft in Schlüsselaktivitäten, Partner, Wertangebote, Kundensegmente und -kanäle strukturiert. Aus diesem Canvas können Rollen in einem Nutzer-Netzwerk-Diagramm abgeleitet werden, das ebenfalls die entsprechenden Bedürfnissen abbildet. Auf dieser Basis entstehen bei der darauf folgenden Kreativarbeit im Design- und Data-Thinking-Prozess oft besonders werthaltige Ideen und Prototypen. In dieser Phase ist alles erlaubt. Selbst ein Plattform-Gedanke für Dienst-Ideen, die bisher noch nicht im Geschäftsmodell vorkam, sollte betrachtet und nicht sofort ausgeschlossen werden. Dieses Rollenspiel hilft auch, den Fragen zur Datensicherheit - die meist von der IT aufgeworfen werden - einen wirtschaftlichen Mehrwert und Nutzen für möglichst viele Nutzer-Rollen entgegenzustellen. Dafür gibt es verschiedene Modelle.
3. Methoden. Ideen. Lösungen.
Zur Entwicklung von neuen Diensten und datenbasierten Applikationen genügt das klassische Requirement-Engineering oft nicht, da sich damit etwa Ansätze der agilen Softwareentwicklung nur schwer auszuprägen lassen. Eine vielversprechende Methode ist das Design Thinking. Dieser Ansatz hat sich aus der nutzerorientierten Denkweise von Designern weiterentwickelt und basiert auf der Annahme, dass jene Ideen erfolgreich sind, die interdisziplinär, experimentell und nutzerorientiert entstehen. Die Methode beschreibt einen kreativen Prozess der Prototypisierung, der agiles Vorgehen mit dem Wasserfall-Verfahren kombiniert. Beim Prototyping für Dienstleistungen werden erlebnisorientierte Innovationen mit wirtschaftlichem Mehrwert zusammengeführt. Das Produkt basiert auf den Rollenprofilen und -bedürfnissen, die zuvor im Diagramm erstellt wurden. In den frühen Phases einer neuen Dienstleistung helfen eine Reihe von Werkzeugen dabei, die Kreativität zu fördern. Dazu zählen Customer Journey Mapping, 6 Denkhüte und Pecha Kucha. Das Vorgehen beim Design Thinking teilt sich in zwei sogenannte Räume auf. Der erste wird als Problemraum bezeichnet, in dem möglichst viele Ideen generiert werden. Diese werden mit den herausgearbeiteten Standpunkten und Zielen der später angedachten Nutzergruppen zusammengebracht. Der zweite Bereich ist der Lösungsraum, in dem die konvergierten Ideen für das Data Thinking prototypisiert werden, das darauf folgt. Bei den Prototypen werden Design, technologische Anforderungen und Geschäftsmodell berücksichtigt. Es gibt eine divergierende und eine konvergierende Phase, in der zunächst viele Prototypenbeschreibungen erstellt werden. Aus diesen werden diejenigen in die Data Thinking-Phase geleitet, die den im Problemraum definierten Standpunkten, Lösungen und Zielstellungen entsprechen und für die es eine Geschäftsmodellgrundlage gibt.
4. Algorithmen. Daten. Infrastruktur.
Auf der Basis der veredelten Ideen können Unternehmen mit den Prototypen der Applikationen und Business Cases beginnen. Jetzt müssen die Algorithmen methodisch und prozessorientiert entwickelt werden. Dafür werden den jeweiligen Aufgaben Rollen zugeordnet. Es wird definiert, welche Daten aus welchen Quellen für das Produkt in den Data Lake überführt werden müssen. Dafür braucht es Wissen um Data Science. Das kann ein Fachmann sein oder ein Team aus Steuerungsentwicklern, Business-IT-Spezialisten und Hardwarespezialisten. Ein Tool bei der Entwicklung eines Data Lake kann 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 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. Im nächsten Schritt wird die Infrastruktur definiert und aufgebaut. Dabei sollen nicht nur Maschinen- und Echtzeitdaten betrachtet werden - auch historische Daten und solche aus den Geschäftsprozessen können eine bedeutende Rolle spielen. Ein wichtiger Aspekt bei der Ausprägung des Datenpools ist die Zeitachse und die Datenmenge. Um eine verlässliche Analyse von Ausreißern und Mustern auszubilden - was in einen automatisierten Machine Learning-Prozess überführt werden soll - sind große Datenmengen über einen längeren Zeitraum erforderlich. Später werden diese Daten auch für einen Abgleich genutzt, ob das Produkt stets mit den gesteckten Zielen übereinstimmt. Wenn das der Fall ist, kann der finale Prototyp erstellt werden, der als Business-Case oder Produkt in eine Projektplanungs- und Implementierungsphase übertragen werden kann.
Im Rahmen der Diskussionen um Industrie 4.0 erlebt Condition Monitoring eine Renaissance. Man feiert deshalb ein Comeback, weil es die Ansätze aus Hersteller- und Betreibersicht an sich schon seit vielen Jahren gibt. Sie wurden jedoch viel zu selten wertschöpfend eingesetzt.
Softwarehersteller bieten zwischenzeitlich sehr viele Lösungen an, die Sensor- und Steuerungsdaten in Echtzeit verarbeiten und visualisieren. Es entsteht jedoch noch kein Mehrwert allein durch die reine Cockpit-Darstellung der Performance-Daten an der Maschine selbst oder in einem Portal. Es gibt bereits weiterentwickelte Lösungen, welche anhand definierter Schwellenwerte Benachrichtigungen per E-Mail oder SMS verschicken. 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 es nicht bestellt, nicht geliefert und kein Wartungsfenster dafür geplant wird? Eine noch wichtigere Frage ist: Wie kann man aus welchen Echtzeit-Daten, durch welche Algorithmen einen tatsächlichen Mehrwert für wen schaffen? Und wie lässt sich dieser als Geschäftsmodell-Baustein in ein Service-Produkt umsetzen?
Braincourt GmbH
Dieser Artikel erschien in IT&Production Oktober 2017 - 09.10.17.Für weitere Artikel besuchen Sie www.it-production.com