MAG 1509 Management

Zwischen Agilität und Stabilität

2015

Wie lassen sich neue Funktionalitäten in greifbare Nutzen konvertieren? In drei Beiträgen gehen wir dieser Frage nach. Zunächst geht es darum, welche Architekturen, Profile und Denkweisen eine not­wendige Voraussetzung sind.

Mit „Digitalisierung“ meinen wir nicht die Umsetzung analoger Inhalte (Bücher, Musik, Filme) in digitale Medien.

Wir verstehen darunter einen Megatrend, der von mehreren neuen Technologien wie Sensorik, Mobilkommunikation und superschneller Datenverarbeitung begünstigt wird und der letztendlich hinausläuft auf eine Echtzeit-Synchronisation von physischer und digitaler Realität.

Getrieben wird diese Entwicklung nicht von Technologiefans und Bastlern, sondern durch handfeste wirtschaftliche Vorteile. Die maschinelle Verarbeitung von Echtzeit-Daten schafft Nutzen, der in Euro und Cent gemessen werden kann.

T-Systems

Ein klassischer Business Case der SAP aus dem Bereich der vorbeugenden Instandhaltung: Sensoren im Gehäuse einer Pumpe messen Temperatur, Feuchtigkeit und Vibration und übertragen diese Daten in Echtzeit an ein analytisches System.

Leistungsfähige statistische Algorithmen prognostizieren anhand erfahrungsbasierter Regeln die Wahrscheinlichkeit, dass eine bestimmte Pumpe innerhalb der nächsten 24 Stunden ausfallen wird.

Bei Bedarf werden sofort Instandhaltungsmeldungen oder -aufträge angelegt. Der beauftragte Techniker vor Ort meldet den tatsächlichen Zustand der Pumpe zurück und versetzt die analytische Anwendung in die Lage, aus falschen oder richtigen Prognosen zu lernen.

Die Nutzenpotenziale liegen auf der Hand: weniger Ausfallzeiten bei den Pumpen, weniger Fehlalarme und defekte Pumpen und deutlich geringere Kosten im Betrieb.

ROI fällt nicht vom Himmel

Die Potenziale sind gewaltig, aber der angestrebte ROI fällt nicht vom Himmel. In Fachabteilung und IT braucht es neue Lösungsarchitekturen, neue Qualifikationen und neue Denkweisen.

Unser Pumpenszenario besteht aus mehreren Teilsystemen (siehe Abbildung) 1) die Pumpe mit ihren Sensoren, 2) ein Event Stream Processor (wie SAP ESP), der Ausfallwahrscheinlichkeiten errechnet und Instandhaltungsmeldungen anlegt, 3) eine ERP-Lösung für die Abwicklung von Instandhaltungsaufträgen und die Entgegennahme von Rückmeldedaten und 4) eine Rule Detection Engine, die die Algorithmen im ESP generiert und fortlaufend verbessert.

Event Stream Processing

Ereignisströme – wie in unserem Beispiel – liefern große Datenmengen von oft unsicherer Qualität. Vor der Weiterverarbeitung müssen die Daten ergänzt und/oder bereinigt werden.

Die Kunst bei der Gestaltung einer Lösungsarchitektur liegt darin, eine Balance zwischen hohem Datendurchsatz und gleichzeitig hoher Fehlertoleranz zu finden. Zur Anwendung kommen sowohl spezielle Architekturmodelle (zum Beispiel die Lambda-Architektur) als auch besondere Programmierparadigmen.

Geschlossene Rückkoppelungskreise

Die Daten aus ESP und ERP werden in der Rule Detection Engine zusammengeführt, um sie dort weiter zu analysieren und auf dieser Basis die Regeln im Event Stream Processor zu verbessern.

Damit beeinflussen die historischen Daten indirekt auch zukünftige Instandhaltungsaufträge. Es resultiert ein in sich geschlossener Rückkoppelungskreis.

All das passiert automatisch, kontinuierlich und – mehr oder weniger – ohne Verzögerungen oder Latenz. Das Gesamtsystem ist somit in der Lage, flexibel zu reagieren, wenn neue Einsichten gewonnen werden oder wenn sich das „Verhalten“ der Pumpen (aus welchen Gründen auch immer) ändert.

Geschlossene Regel- oder Rückkoppelungskreise an sich sind nicht neu, viele Prozessleitsysteme arbeiten damit. Die Innovation besteht vollständig digitalisierten Geschäftsmodellen:

Solche Regelkreise existieren dann nicht nur für Prozessschritte in der Fertigung, sondern für komplette Geschäftsprozesse . Die zugrunde liegenden Regeln sind dabei nicht starr, sondern selbstlernend ausgestaltet werden können.

Neue Qualifikationen

Die Verarbeitung von Ereignisströmen und selbstlernende Regelkreise sind für sich genommen schon eine Herausforderung für altgediente Abap-Entwickler. Hinzu kommt: In den Lösungen werden oft anspruchsvolle statistische Algorithmen (Bayessche Netze, Arima/Armax, Latente Variablen-Modelle) verwendet.

Sowohl für SAP BW als auch für S/4 hat SAP die Tür zur Welt der Statistik mit HAP (Hana Analysis Process), SAP PAL (Predictive Analysis Library) und die Integration der Sprache R weit aufgestoßen.

An die Stelle erfahrener Programmierer treten zukünftig Data Scientists, viele Universitäten bieten schon entsprechende Masterstudiengänge an. Deren Absolventen arbeiten in fünf bis zehn Jahren entweder für Sie oder für Ihren Wettbewerb.

Induktion statt Deduktion

Organisationen operieren heute in einer instabilen Umwelt. Die Verhaltensweisen von Kunden und darauf basierende Entscheidungsregeln in Geschäftsprozessen ändern sich nicht mehr im Jahresrhythmus, sondern täglich, stündlich oder minütlich.

Die oben beschriebenen Architekturen müssen daher extrem flexibel sein; zur gleichen Zeit geht es darum, in puncto Governance und Compliance den Überblick zu behalten.

Das funktioniert nur, wenn man sich a) nur noch auf Korrelationen anstatt auf die Erklärung von Ursache-Wirkungs-Zusammenhängen konzentriert und b) sich von Daten führen lässt, anstatt Daten die eigene Weltsicht aufzuzwingen (Induktion statt Deduktion).

Die Veränderung entsprechender Denkweisen braucht mehr Muße als die reine technische Migration von ERP 6.0 nach S/4.

Die IT als Komponist

Der CIO kann eine entscheidende Rolle dabei spielen und die Weiterentwicklung der Organisation beschleunigen. Egal ob mit oder ohne Outsourcing:

Es geht nicht mehr darum, alle Entwicklungsarbeiten selber zu erledigen sondern die Organisation so weiterzuentwickeln, dass sie die Auslagerung von Arbeiten effizient führen und ergebnisorientiert überwachen kann.

Mit „ergebnisorientiert“ sind nicht ITIL-Service-Level gemeint. „Ergebnisorientiert“ heißt: IT-Dienstleister werden anhand von Gütekriterien für die Performance von Algorithmen (Beispiel: „Treffsicherheit in puncto Ausfall einer Pumpe“) gemessen.

Wie solche Algorithmen im Detail funktionieren, spielt eine untergeordnete Rolle und muss von den eigenen Mitarbeitern bestenfalls nachvollzogen werden können.

Crowdsourcing-Portale wie www.kaggle.com für die Entwicklung von Algorithmen oder der SAP-eigene Idea Marketplace (ideas.sap.com) weisen hier den Weg.

Der Spagat zwischen Agilität und Stabilität kann nur gelingen, wenn sich die IT-Experten im eigenen Haus von „Musikern“ zu „Komponisten“ weiterentwickeln. Anstatt alle möglichen Funktionalitäten in Z-Programmen oder BAdIs unterzubringen, kann die Offenheit einer Plattform wie Hana genutzt werden, um andere Lösungen beispielsweise via Extended Application Services (XS) zu integrieren.

So können einfache Aufgaben (etwa: Reporting via Tableau) oder hochspezielle Arbeitsschritte (Berechnung von Fahrzeiten im Rahmen einer Echtzeit-Kundensegmentierung) an andere Anwendungen ausgelagert werden.

Gleichzeitig ist beim Aufbau von Datenflüssen zu klären, wo persistente Strukturen benötigt werden (zum Beispiel die neue Adso im Hana-basierten BW) oder was über virtuelle (zum Beispiel Open ODS View) oder hybride (zum Beispiel Composite Provider) abgebildet werden soll.

Letztendlich trägt der CIO die Verantwortung dafür, dass seine Organisation derartige Entscheidungen treffen und Instrumente wie Crowdsourcing oder SaaS souverän arrangieren kann.

Wahrscheinlichkeiten verstehen

Klassische ERP-Systeme sind deterministisch organisiert. Natürlich kann man im SAP CRM Auftragswahrscheinlichkeiten auf Ebene Angebotsposition hinterlegen.

Aber im nächsten Schritt wird aus einem Angebot ein Kundenauftrag oder eben nicht. Folgeschritte (wie zum Beispiel eine Materialbedarfsplanung) werden nicht durch Wahrscheinlichkeiten gesteuert.

Für Hana – eine Plattform mit vielfältigen stochastischen Funktionen – eine gravierende Einschränkung. In Zukunft wird es also darum gehen, teilweise automatisiert Entscheidungen nicht aufgrund (wahrscheinlich falscher) Annahmen, sondern basierend auf errechneten (wesentlich realitätsnäheren) Wahrscheinlichkeiten zu treffen. E

in Beispiel hierfür bietet unser Pumpenszenario: Bei einer beschränkten Anzahl an Servicetechnikern werden Instandhaltungsmeldungen nur oberhalb einer gewissen – maschinell ermittelten und fortlaufend adaptierten – Wahrscheinlichkeits-Schwelle ausgelöst.

Fazit

Hana ist ein unschätzbar wertvolles Instrument bei der digitalen Ausgestaltung von Geschäftsprozessen. Um dieses Potenzial zu nutzen, müssen Architekturen, Anforderungen an Mitarbeiter und althergebrachte Denkmodelle grundsätzlich neu gestaltet werden.

Der Fokus der IT verschiebt sich weg von der Aushandlung von Service Levels hin zur Komposition einer Symphonie aus Anwendungen und Partnern.

Im nächsten Artikel unserer kleinen Serie befassen wir uns mit dem Aufspüren werthaltiger Business Cases für die „Digitalisierung“ mit Hana.

Über den Autor

Michael Mattern, Horváth & Partners

Michael Mattern ist Projektleiter, Senior Consultant und Enterprise Architect bei Horváth & Partners, einer internationalen Managementberatung für Unternehmenssteuerung und Performanceoptimierung.

Hinterlassen Sie einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.