Embedded Analytics oder Enterprise Analytics? In fünf Schritten zum datengetriebenen Unternehmen

Anbieter zum Thema

Fujitsu Technology Solutions GmbH

INFOMOTION GmbH

QUNIS GmbH

NTT DATA Business Solutions AG

Im Industrial Internet of Things fallen enorme Datenmengen an – sei es durch Sensoren an Maschinen und Anlagen oder durch smarte Produkte. Dabei ist nicht immer ganz klar, was mit dem digitalen Kapital passieren soll. Fünf Dimensionen können hier für Klarheit sorgen.

Obwohl die ersten IoT-Szenarien erfolgreich realisiert wurden, kann das gemessen an der Menge und Vielfalt der vorhandenen Daten lediglich der Anfang sein. Noch fehlt vielen produzierenden Unternehmen eine klare Idee dazu, wie sie Datenbestände konsequent nutzen und sich zur Data Driven Company entwickeln können. Bestätigt wird das durch die Zahlen der Bitkom-Studie „Industrie 4.0 – so digital sind Deutschlands Fabriken“ von 2020: 88 Prozent der befragten Unternehmen gaben an, im Rahmen von Industrie-4.0-Initiativen Produkte und Services für plattformbasierte Geschäftsmodelle zu entwickeln. Produkte und Services für datenbasierte Geschäftsmodelle entwickelten dagegen nur 18 Prozent.

Insofern sollten sich Unternehmen in Bezug auf ihren Umgang mit Daten unbedingt Klarheit verschaffen, um dann den richtigen Rahmen setzen zu können. Das betrifft die Organisation, die Prozesse und die Technologie – insbesondere die Analytics-Architektur. Hierfür lohnt es sich, einen genaueren Blick auf Dimensionen zu werfen: Erkenntnisinteresse, Daten, Anwender, Kosten und Systemlandschaft.

Dimension 1: Erkenntnisinteresse

Das Erkenntnisinteresse lässt sich als Fundament für die anderen vier Dimensionen verstehen. Es ist darüber hinaus ausschlaggebend für die Motivation, sich mit dem Umgang mit Daten zu befassen. Aufschlussreich ist zunächst ein Blick auf den Reifegrad.

Bislang beschränkt sich die Analyse von Daten vor allem darauf, Daten aus der Vergangenheit zu Kennzahlen oder Key Performance Indicators (kurz: KPI) zu verdichten und diese in Berichten zusammenzustellen. Erkennen lässt sich beispielsweise, wie hoch die Gesamtanlageneffektivität (englisch: Overall Equipment Effectiveness) war – in einem bestimmten Zeitraum, an einem bestimmten Standort, für ein bestimmtes Produkt. Diese Descriptive Analytics gibt damit Antworten auf die Frage, was geschehen ist. Mittlerweile lässt sich mithilfe von Auswertungen auch beantworten, warum etwas passiert ist (Diagnostic Analytics), was passieren wird (Predictive Analytics) und wie Unternehmen etwas passieren lassen können (Prescriptive Analytics). Mit diesem steigenden Reifegrad nimmt auch der Umsetzungsgrad einer Data Driven Culture zu, die zu einer Steigerung der Wertschöpfung des gesamten Unternehmens führt.

Welcher Reifegrad sinnvoll ist, muss jedes Unternehmen für sich selbst beantworten. Das gilt auch dafür, in welchem Handlungsfeld sich ein umfassendes Wissen lohnt. Einige pauschale Annahmen dazu, was für produzierende Unternehmen besonders relevant ist, lassen sich dennoch treffen.

Kontinuierliche Verbesserung
Als Ergänzung zur Leistungskennzahl (Englisch: Key Performance Indicator) Overall Equipment Effectiveness lässt sich diagnostizieren, wie es zu dem Ergebnis gekommen ist, was die Gründe für eine besonders schlechte oder besonders gute Leistung waren. Dieses Wissen kann genutzt werden, um passende Maßnahmen zu definieren. Analyseverfahren erlauben auch vorherzusagen beziehungsweise zu simulieren, wie diese Maßnahmen vermutlich wirken.

Produktionsplanung und -steuerung
Die Produktionsplanung und -steuerung basiert schon heute auf möglichst umfassenden Daten und auf Tools, die Ressourcen und Aufträge zusammenbringen. Zum Teil werden dabei Rückmeldungen aus dem Produktionsbereich berücksichtigt. Mit neuen Analyseverfahren lassen sich über alle Phasen der Planung und Steuerung hinweg deutlich mehr Daten verarbeiten und aufeinander beziehen. Dadurch wird es möglich, Details weiter zu optimieren – etwa die Bandgeschwindigkeit. Entscheidungen können zudem von Menschen an eine Künstliche Intelligenz delegiert werden. In Summe steigert all das die Auslastung der vorhandenen Ressourcen, verkürzt die Durchlaufzeiten und trägt dazu bei, kaufmännische Anforderungen zu erfüllen. Die Vision einer Losgröße-1-Produktion zu wettbewerbsfähigen Preisen kann damit Realität werden.

Produktentwicklung
Daten der Produkte, die bei den Kunden im Einsatz sind, lassen sich zu wertvollen Einsichten zur Qualität und zur Nutzung verdichten. Die Erkenntnisse können der Produktentwicklung dabei helfen, Produkte kontinuierlich zu optimieren.

Dimension 2: Daten

Einerseits wird durch das Erkenntnissinteresse maßgeblich definiert, welche Daten für die Analyse erforderlich sind. Anderseits gibt ein Überblick über die verfügbaren Daten Impulse für die Identifizierung nützlicher Anwendungsfälle (Englisch: Use Cases) – schränkt sie aber auch auf das Machbare ein. Um sich Klarheit zu verschaffen, bietet sich die Orientierung am 3V-Modell von Gartner an:

• Volume: Welches Datenvolumen soll verarbeitet werden?

• Variety: Welche Datenquellen (z. B. SAP-Systeme, Non-SAP-Systeme, IoT-Devices) und welche Datentypen (strukturiert, unstrukturiert) sollen verarbeitet werden?

• Velocity: Welche Geschwindigkeit soll bei der Verarbeitung der Daten erreicht werden?

Dimension 3: Anwender

Analysen nutzen nur dann etwas, wenn die Anwender auch damit arbeiten. In vielen Unternehmen war das nicht immer der Fall. Es wurden mit viel Aufwand zig Excel-Reports erstellt, die dann ungelesen auf den Festplatten verstaubten. Insofern sollte unbedingt geklärt sein, unter welchen Bedingungen die Anwender den größten Nutzen aus den Analysen ziehen. Das erhöht die Akzeptanz und Nutzungshäufigkeit. Anforderungen lassen sich vor allem daraus ableiten, wozu bestimmte Anwendergruppen die Daten nutzen möchten.

Dimension 4: Kosten

Dass bei einer Entscheidung für eine Architektur auch die Kosten eine Rolle spielen, ist selbstverständlich. Die Identifizierung aller Kosten und deren Beurteilung ist es ganz und gar nicht. Denn zum einen muss eine Reihe von Faktoren beachtet werden. Zum anderen müssen die Kosten immer auch in Relation zum dadurch realisierten, monetär ausgedrückten Nutzen gesetzt werden:

Capex oder Opex
Bis vor ein paar Jahren war es üblich, eine IT-Lösung zu kaufen und dafür Lizenzkosten zu zahlen. Es entstanden also Capex-Kosten. Mittlerweile gibt es etliche Abo-Modelle, bei denen die Software nicht gekauft, sondern die Nutzung bezahlt wird – und damit Opex-Kosten entstehen.

Betrieb
Neben den Kosten für die IT-Lösung an sich fallen Kosten für den Betrieb an. Wie hoch diese sind, hängt maßgeblich davon ab, wer sich wie intensiv um die Software kümmert.

Return
Mithilfe der Analytics-Architektur werden unterschiedliche Use Cases realisiert, die einen Mehrwert bringen sollen. Beispielsweise können Kosten gesenkt oder der Umsatz gesteigert, neue Produkte und Services kreiert oder innovative Geschäftsmodelle etabliert und die User Experience verbessert werden. Wie hoch der Mehrwert ausfällt, lässt sich vorab nur selten exakt sagen. Eine Annäherung ist aber dennoch für eine fundierte Entscheidung unverzichtbar.

Dimension 5: Systemlandschaft

Schließlich können sich Anforderungen aus der vorhandenen oder gewünschten Systemlandschaft ergeben. Das betrifft zum einen das Deployment: On-Premises, Cloud oder Hybrid? Zum anderen geht es um die Skalierbarkeit der Architektur – hinsichtlich der Funktionen und der Leistung.

Embedded Analytics oder Enterprise Analytics?

Die Auseinandersetzung mit den fünf Dimensionen trägt erheblich zur Entwicklung einer Data Driven Culture bei. Hinzu kommt, dass dabei Aspekte geklärt werden, die für die Auswahl einer Analytics-Architektur elementar sind. Grundsätzlich gibt es zwei Architektur-Ansätze, die jeweils ihre spezifischen Stärken haben und sich zudem kombinieren lassen: Embedded Analytics und Enterprise Analytics. Bei Embedded Analytics befinden sich Daten und Funktionen im transaktionalen System – üblicherweise im ERP-System – bei SAP also in SAP ERP oder in SAP S/4HANA. Bei Enterprise Analytics werden Daten und Funktionen in dezidierten Komponenten außerhalb des transaktionalen Systems vorgehalten. In der Regel kommen ein Data Warehouse als Backend und spezifische Modellierungs-, Analyse- und Visualisierungslösungen als Frontend zum Einsatz. Definieren lassen sich die beiden Ansätze auch in Bezug auf die unterschiedlichen Ebenen einer Analytics-Architektur: Beim Embedded-Analytics-Ansatz umfasst ein System die Ebenen Collection, Storage und Usage, während es beim Enterprise-Analytics-Ansatz für alle Ebenen spezielle Systeme gibt, die einen Single Point of Truth unterstützen.

Erstmals wirklich umgesetzt hat das Embedded-Analytics-Konzept SAP mit SAP S/4HANA. Hier sind Analytics-Funktionen eingebettet, die auf die in der HANA-Datenbank gespeicherten Daten zugreifen. Parallel dazu bietet SAP nach wie vor dezidierte Komponenten für einen Enterprise-Analytics-Ansatz – unter anderem SAP Analytics Cloud (SAC), SAP BW/4HANA und SAP Data Warehouse Cloud (SAP DWC). Beide Ansätze weisen einige spezifische Merkmale auf.

Für Unternehmen besteht die Aufgabe nun darin, die Merkmale der Ansätze mit ihrem beabsichtigten Umgang mit den Daten in Einklang zu bringen. Sollen beispielsweise Daten aus der Produktion genutzt werden, um die Produktionsplanung- und -steuerung weiter zu verbessern, ist der Embedded-Analytics-Ansatz am ehesten geeignet. Um die enorme Datenmenge von Produkten im Einsatz zu analysieren, kommt allein schon wegen der Anbindung von Quellen nur der Enterprise-Analytics-Ansatz infrage.

Wichtig ist dabei: Mit der Entscheidung für eine Architektur schaffen Unternehmen keine irreversiblen Fakten. Denn die einzelnen Komponenten bauen aufeinander auf. Wer also heute zu dem Schluss kommt, dass die Embedded-Analytics-Möglichkeiten von SAP S/4HANA genügen, kann morgen als Ergänzung die SAP Analytics Cloud einführen. Und wer eine elaborierte Enterprise-Analytics-Architektur mit der SAC, SAP BW/4HANA und einem zusätzlichen Data Warehouse in der Cloud betreibt, für den ist der Einsatz von Embedded Analytics in bestimmten Anwendungsfällen dennoch sinnvoll.

Dieser Artikel stammt von unserem Partnerportal Industry of Things.

* Georg Aholt arbeitet als Principal Manager Business Analytics & Information Management bei der NTT Data Business Solutions AG.

(ID:48299831)