1. Einblicke in Herausforderungen der Datenaufbereitung und Datenanalyse und die Wichtigkeit der organisatorischen Ebene

Viele Projekte im Bereich Datenanalyse gehen nicht über die Phase des Prototyping hinaus. Welche Hemmnisse erklären das Scheitern des Übergangs vom Prototyping in die Produktion und wie kann diesem Problem frühzeitig begegnet werden? In diesem Kapitel soll es um die Betrachtung dieser Fragestellung im Hinblick auf die Datenlage im Unternehmen gehen.

Die geteilten Beobachtungen und Empfehlungen beruhen auf unserer Erfahrung als Software-Anbieter (RapidMiner Inc.) im Bereich Data Analytics und sind aus der Sicht zweier Data Scientists geschrieben, die an der Umsetzung der geförderten Projekte DaPro des Technologieprogramms Smarte Datenwirtschaft und IIP-Ecosphere des Technologieprogramms Innovationswettbewerb Künstliche Intelligenz, des Bundesministeriums für Wirtschaft und Klimaschutz (BMWK), im Bereich maschinelles Lernen arbeiten. In diesen Projekten wird vor allem Augenmerkt daraufgelegt, Datenanalyse für ein breiteres Publikum nutzbarer zu gestalten. Hierzu wurden Werkzeuge zur einheitlicheren Datenverarbeitung und -analyse sowie Konzepte zur Einführung von Analyse-Systemen in Unternehmen erarbeitet. Dazu wird auf Erfahrungen aus dem Kundenkontakt außerhalb dieser Projekte zurückgegriffen.

Bei der Zusammenarbeit mit Partnerinnen und Partnern aus unterschiedlichen Branchen (Automobil, Chemie, B2B-Elektronik, Finanzen, Haushaltsgeräte, Lebensmittel, Logistik, Metallverarbeitung) zeichnen sich zwei wesentliche Probleme ab:

• Probleme bei der Gewährleistung einer durchgängigen Datenpipeline mit gesicherter Datenqualität
• Organisatorische Unternehmensstrukturen, die noch nicht auf Datenanalyse-Projekte ausgelegt sind

Das Kapitel widmet sich verschiedenen Teilaspekten dieser Probleme und soll dabei helfen, wichtige Faktoren frühzeitig zu erkennen. Dabei werden im Alltag erprobte Methoden geteilt, die sich von der Planung des ersten Treffens über die Gestaltung regelmäßiger Zusammenarbeit bis hin zur späteren Übergabe des Projektes erstrecken. Die Methoden werden in einem industriellen Kontext vorgestellt, lassen sich jedoch leicht auf andere Geschäftsbereiche und Branchen übertragen, in denen Datenanalyseprojekte umgesetzt werden sollen.

Doch wieso ist gerade die organisatorische Ebene ein so großes Problem bei Datenanalyse-Projekten? Im industriellen Kontext gibt es oft eine komplexe Systemlandschaft, die über Jahre und Jahrzehnte hinweg gewachsen ist. Speziell im Bereich von kleinen und mittelständischen Unternehmen werden nicht ständig neue Fabriken von Grund auf geplant und umgesetzt, sondern es gibt verschiedene Maschinengenerationen und Verwaltungssysteme, die mit der Zeit eingeführt wurden und eigenständig in der jeweiligen Abteilung funktionieren müssen. Wichtige Informationen werden im Alltag so hinterlegt, dass der anfängliche Aufwand, etwas festzuhalten, gering ist und der lokale Zweck der Datenhaltung erfüllt wird. Dabei werden Aspekte der Wiederverwendbarkeit für andere Abteilungen oder spätere Nutzung für noch nicht geplante Zwecke häufig nicht beachtet, wodurch impraktikable Ansammlungen von Daten entstehen, über die kaum jemand Bescheid weiß. Häufig wird dann von sogenannten Datensilos gesprochen.

Datenanalysen profitieren jedoch von der Zusammenführung unterschiedlicher Datenquellen, die ein möglichst breites Spektrum an Einflüssen auf einen (Produktions-)Prozess haben. Somit zeichnet sich direkt die erste Schwierigkeit organisatorischer Natur ab: Es muss ein Austausch zwischen Abteilungen stattfinden, der zuvor ggf. nur sporadisch stattfand und der vor allem selten schon strukturiert und (teil-)automatisierbar ist. In der Broschüre „KI im Mittelstand“ der Plattform Lernende Systeme werden vier Pfade beschrieben, wie Unternehmen mit unterschiedlichen Voraussetzungen Datenanalyse-Projekte angehen können. In der Broschüre wird zwischen vier Ausprägungsgraden vorhandener Daten- und Analyseinfrastruktur im Unternehmen unterschieden, um basierend darauf angepasste Einführungssystematiken zu empfehlen. So kann es für kleinere Unternehmen mit geringer vorhandener Dateninfrastruktur eine gute Option sein, einen fertigen „KI-Service“ passend zu einer vorhandenen Maschine einzukaufen, während andere Unternehmen zum Erhalt der Wettbewerbsfähigkeit eigene Analyse-Abteilungen aufbauen sollten, um das Thema als weitere Kernkompetenz zu verankern.

Darüber hinaus sind für einen unternehmenskulturellen Wandel die Bereitschaft, sich weiterzuentwickeln, Informationen über Abteilungen hinweg zu teilen und notwendige Änderungen in der eigenen Abteilung vorzunehmen unabdingbar. Möglichkeiten, diesen Wandel und anderen Hindernissen im Hinblick auf die Einbindung der Mitarbeitenden zu begegnen, finden sich beispielsweise in der Broschüre „Industrie 4.0 – Mitarbeiter einbinden“. Dementsprechend ist eine frühzeitige Einbeziehung der beteiligten Partnerinnen und Partner innerhalb des Unternehmens, bei dem ein Projekt umgesetzt wird, unabdingbar.

Die referenzierten Broschüren bieten Ansätze zur Umsetzung von Datenanalyse-Projekten mit Fokus auf die Berücksichtigung und Einbindung der Interessen der Mitarbeitenden. Das vorliegende Kapitel betrachtet allgemeinere Probleme, die im Hinblick auf die Organisation von Projekten sowie die eigentliche Datenhandhabung stehen. Das Kapitel ist dabei wie folgt strukturiert:

Um Fallstricke bei der Handhabung von Daten angehen zu können, müssen die Daten zunächst verfügbar sein und der notwendige Kontext der zu analysierenden Daten hergestellt werden. Dementsprechend soll es im nächsten Abschnitt um die Konzeption eines ersten Arbeitstreffens im Rahmen eines Datenanalyse-Projektes gehen. Das Ziel dieses Treffens ist, ein gemeinschaftliches Verständnis für mögliche Anwendungsfälle für Datenanalyse im Unternehmen (im Folgenden kurz Anwendungsfälle oder auch Use Cases) sowie eine Übersicht vorhandener Datenquellen zu schaffen. Im nachfolgenden Abschnitt werden häufig auftretende Datenqualitätsprobleme benannt. Zuletzt wird beschrieben, wie die Handhabung der Daten und der Analyseprozesse während der Projektumsetzung nachhaltig gestaltet werden kann, um Reibungsverluste beim Übergang in den Produktivbetrieb zu reduzieren.

2. Die ersten Treffen: Wen brauche ich? Welche Fragen müssen geklärt werden?

Die ersten Vorgespräche zur Definition des groben Projektumfangs liefen erfolgreich und das (Forschungs-)Projekt hat begonnen. Doch wie genau kann die Bearbeitung von Anwendungsfällen starten, um zukünftigen organisatorischen und technischen Problemen der Datennutzung vorzugreifen?

Definition: Im Folgenden wird davon ausgegangen, dass die Partner zuvor noch nicht zusammengearbeitet haben. Der Partner, in dessen Unternehmen Anwendungsfälle durchgeführt werden sollen, wird als Anwender bezeichnet. Der Partner, der die Entwicklungen im Bereich Datenanalyse realisiert, wird als Entwicklungspartner bezeichnet.

Zuerst gilt es, weitere Details über den Kontext potenzieller Anwendungsfälle zu gewinnen. Zum Kontext potenzieller Anwendungsfälle zählen vor allem Informationen über die IT-Systemlandschaft, existierende Datenquellen, mögliche Zielgrößen aus Unternehmenssicht sowie vorhandene Praktiken der Datenauswertung. Hierbei ist es von Vorteil, nicht nur einen einzelnen Anwendungsfall zu betrachten und darauf basierend die minimal notwendigen Datensätze/-anbindungen zusammenzutragen. Alternative Ansätze sollten von Anfang an mitgeplant werden, um als Ausweichmöglichkeit zu dienen, wenn die Evaluation des ursprünglichen Ansatzes ergibt, dass eine Umsetzung nicht zielführend oder praktikabel genug ist.

Definition: Als Anwendungsfall wird ein konkretes Datenanalyse-Problem bezeichnet. Oft ist dies durch die Art der Daten und der Zielsetzung abgesteckt. Die Zielsetzung leitet sich dabei in den vielen Fällen aus einer Unternehmens-Kennzahl ab. Für maschinelle Lernverfahren im Speziellen werden häufig sogenannte „überwachte Lernverfahren“ betrachtet. Diese benötigen eine definierte Zielgröße (ein „Label“), welche zugleich für das Erstellen der Analyse benötigt wird und die spätere Grundlage für das Analyseergebnis stellt. Die Zuordnung eines Produktbildes zu einer Kategorie mit den Ausprägungen „defekt“, „in Ordnung“, „zu prüfen“ wäre ein Beispiel für einen Anwendungsfall.

Wichtig zu erwähnen ist, dass zwischen der unternehmerischen Zielsetzung und der Zielgröße aus Analysesicht unterschieden werden muss. In einigen Fällen ist hier ein 1:1-Abgleich möglich, aber wesentlich häufiger muss ein Zusammenhang hergestellt werden, der insbesondere für die spätere Bewertung einer Analyse im Fokus stehen sollte. Konkret heißt dies, dass vor allem bei überwachten Lernverfahren die Vorhersagegüte eines gewählten „Labels“ nicht zwingend die oberste Priorität hat, sondern vielmehr der daraus abgeleitete tatsächliche Mehrwert für das Unternehmen.

Darüber hinaus stellt sich häufig bei der Diskussion potenzieller Analysen heraus, dass

• die ursprünglich definierte Zielgröße der Analyse nicht zielführend im Hinblick auf die Aufgabenstellung ist und
• eine Umformulierung der Problemstellung bzw. ein Umdenken bei der Wahl des Anwendungsfalls die Erfolgswahrscheinlichkeit des Projektes stark erhöhen kann.

Für diese Betrachtungen ist es daher wichtig, Flexibilität bei der Wahl des Anwendungsszenarios mit einzuplanen. Nicht selten ist eine vorangehende Betrachtung vorhandener Datenquellen sehr hilfreich.

Daher empfiehlt es sich, nach einer ursprünglichen Klärung des Produktionsprozesses zunächst mit der Betrachtung der Systemlandschaft zu beginnen, um anschließend verfügbare Datenquellen aus relevanten Bereichen zu diskutieren. Hierbei müssen nicht direkt tiefgreifende Analysen aller Quellen erfolgen. Qualitative Beschreibungen reichen den Entwickelnden oft aus, um zusammen mit den Anwendenden entscheiden zu können, welche Datenquellen für Analysen geeignet sind. Dies sollte im Zusammenhang von potenziellen Anwendungsfällen geschehen. Daher ist eine Erhebung möglicher Probleme in relevanten Abteilungen von Interesse.

Eine Datenpipeline wird umgesetzt, um Mehrwert zu generieren. Dementsprechend, müssen auch Anknüpfungspunkte für eine (regelmäßige) Verwertung gegeben sein. Dies gibt oft wichtige Anforderungen an die Daten und organisatorischen Strukturen vor, die möglichst früh bei der Planung miteinbezogen werden sollten. Diese Anforderungen beschränken sich nicht nur auf technische Details, sondern gehen fließend in die Definition der Anforderungen durch das Anwendungsszenario über, denn herausgearbeitete Analyseergebnisse müssen irgendwann auf die Prozesse des Unternehmens übertragen werden.

Zur Klärung aller dieser aufgeführten Faktoren rund um die System- und Datenlandschaft eines Unternehmens sowie potenzieller Anwendungsfälle ist es hilfreich, verschiedene Akteure des Anwendungsunternehmens frühzeitig in Diskussionen einzubinden. Eine mögliche Aufteilung für benötigte Akteure ist im Folgenden aufgeführt zusammen mit Stichpunkten zu den Themen, für die die jeweilige Person benötigt wird:

Beispiel: Akteure für ein erstes Treffen:

• Vertretung des Industrial Engineerings/der Unternehmensplanung
  • Zur Klärung von Fragen des Change Managements
  • Zur Klärung der geplanten Nutzung der Analyseergebnisse
• Verantwortlicher des betrachteten Prozessabschnittes mit Detailwissen
  • Zur Klärung von Detailfragen zum Prozess und für Rückfragen zur Domäne
  • Zur Klärung von Verständnisfragen der Datenrepräsentation und -interpretation
  • Zur späteren fachlichen Validierung von Analyse-/Vorhersage-Ergebnissen und damit auch frühzeitig zur Information über Methoden des Informationsgewinns
• Vertretung der IT
  • Zur Klärung von Integrationsmöglichkeiten der Datenanalyseprozesse in bestehende IT-Prozesse
  • Zur Absteckung von Rahmenbedingungen der Datennutzung
  • Zur Bereitstellung von Datenkatalogen (falls vorhanden)

Mit diesen Akteuren gilt es, ein Treffen zu organisieren, in dem die zuvor aufgelisteten Punkte diskutiert werden. Eine erprobte Agenda für Projekte mit Fokus „Maschinelles Lernen als Werkzeug“ kann beispielsweise wie folgt aussehen:

Beispiel: Agenda für Projekte mit Fokus „Maschinelles Lernen als Werkzeug“

• Begrüßung und Vorstellungsrunde, 10 Min.
• Übersicht Use Case (Anwendende), 20 Min.
• Kurzer Einstieg „Maschinelles Lernen“ und Anwendungsszenarien (Entwickelnde), 15 Min.
• Use-Case-Definition & Detaillierung (gemeinsam), 1,5 Std.
  • Diskussion der Zielgrößen, möglicher Einflussgrößen und Erfolgskriterien (Performanz-/Kostenmaße)
  • Besprechung von Verwertungsmöglichkeiten
• Datenevaluation (gemeinsam, IT ggf. benötigt), 1,5 Std.
  • Besprechung vorhandener Datenquellen und Datenarten
  • Erste Evaluation der benötigten/verfügbaren Daten
  • Klärung der Anbindungsmöglichkeiten und des Nutzungsrahmens
• Überblick Software-Anbieter (Entwickler, IT ggf. benötigt), je 15 Min.
  • Aufzeigen der Nutzungsmöglichkeiten
  • Vorstellung von Integrationsmöglichkeiten in die IT-Systemlandschaft
• Organisatorisches (gemeinsam, IT ggf. benötigt), 1 Std.
  • Klärung der Rahmenbedingungen zum Software-Einsatz und zur Datennutzung
  • Abstimmung der gemeinsamen Arbeitsweise
  • Abstimmung der Rollenverteilung der Software-Partner
• Abschluss: Abgleich der Erwartungshaltungen an die Projektarbeit, 30 Min.

Bei dem Verlauf der Agenda fällt auf, dass recht früh ein „Einstieg in maschinelles Lernen“ (ML) gegeben wird. Dieser Aspekt hat sich in der Vergangenheit als sehr vorteilhaft herausgestellt, da so ein Bewusstsein für die Möglichkeiten, aber auch Nebenbedingungen von ML-Projekten vermittelt werden kann. Dies hilft vor allem bei Diskussionen zur Machbarkeit von Anwendungsfällen, hilft neue Blickwinkel auf die gleiche Fragestellung seitens der Anwendenden zu ermöglichen und bereitet frühzeitig die Basis für Diskussionen um gegebene Voraussetzungen.

Insbesondere die Notwendigkeit neben den eigentlichen Datenquellen auch Informationen über etwaige Kontextwechsel zu erhalten, ist hier kritisch. Gerade in produzierenden Unternehmen sind durch Verschleiß, Rezeptänderungen oder Wechsel bei Zulieferern zahlreiche Situationen gegeben, wo sich der Analysekontext ändert und somit entwickelte Analyseverfahren angepasst werden müssen. Im besten Fall können Informationen über potenzielle Kontextwechsel bereits als Datenquelle mit in die Analysepipeline einfließen. Ist dies nicht der Fall, muss zumindest ein Bewusstsein bei den Anwendenden geschaffen werden, dass zu definierende Kennzahlen überwacht werden müssen, um erkennen zu können, wann die Anpassung einer Analyse notwendig ist.

Als gemeinsame Hauptziele dieses ersten Treffens lassen sich folgende drei Punkte nennen:

• Informationslage reicht aus, um ein Use-Case-Summary-Dokument (1–2 Seiten) zu erstellen,
• Anwendende wissen um das Potenzial des Use Case und der Umsetzungsmöglichkeiten mit der Software des Entwicklers,
• Datenzugriffe und Softwarenutzung sind geklärt.

Das genannte zweiseitige Use-Case-Summary-Dokument bezieht sich auf eine Vorlage, die im Forschungsprojekt Datengetriebene Prozessoptimierung mit Hilfe maschinellen Lernens in der Getränkeindustrie (DaPro) entwickelt wurde, um eine klassische Arbeitsbeschreibung für ML-Projekte zu erhalten, die im Verlauf des Projektes immer wieder herangezogen werden kann, um ursprünglich definierte Ziele und Anmerkungen schnell griffbereit zu haben. Es empfiehlt sich, dies beispielsweise als Start für ein Logbuch zu verwenden, in dem wichtige Projektschritte festgehalten werden. Auch bei Verwendung von agilen Methoden zur Projektverwaltung kann die Nutzung eines Logbuchs (als separates Dokument oder im internen Projektwiki) sehr hilfreich sein.

Wie es nach dem ersten Treffen weitergehen kann, wird im Abschnitt „Erst die Datenpipeline, dann die Analyse“ beschrieben. Im Folgenden soll zunächst genauer auf häufig auftretende Probleme beim Umgang mit Daten eingegangen werden. Diese Probleme und Herausforderungen fließen sowohl bei der Betrachtung und Beurteilung von Datenquellen beim ersten Treffen als auch bei der Handhabung von Daten bei der Erstellung der Datenanalyse ein.

3. Datenquellen, Verantwortlichkeiten und Potenziale

Die Daten- und Systemlandschaft in industriellen Unternehmen ist oft über Jahre oder Jahrzehnte gewachsen und beinhaltet daher eine hohe Diversität in verwendeten Technologien, Datenformaten und Datenschemata. Da Daten die Grundlage für die Datenanalyse zuvor identifizierter Anwendungsfälle sind, sollte die Evaluierung existierender Datenpipelines im Unternehmen ein wesentlicher Bestandteil eines Projektes sein. Die Zielsetzung dieses Schrittes ist es, einen Überblick über schon vorhandene Datenquellen zu erhalten, ihre Eignung für den anvisierten Anwendungsfall zu evaluieren und notwendige Schritte für den Datenzugriff wie auch die Datenaufbereitung zu identifizieren.

Es ist empfehlenswert die Evaluation von Datenquellen in die ersten Treffen zur Durchführung von Datenanalyseprojekten einzubinden wie beschrieben im Abschn. 17.2. Dabei liegt der Fokus auf die im Unternehmen schon vorhandenen Datenquellen und -senken (Zielorte für die Weitergabe der Daten nach einer Verarbeitung). Im späteren Verlauf eines Datenanalyseprojektes kann eine schrittweise vertiefende Betrachtung der Datenquellen erfolgen. Zum Beispiel in den in Abschn. 17.4.1 vorgeschlagenen Arbeitstreffen.

In den folgenden Abschnitten werden zuerst übliche Typen von Datenquellen in (industriellen) Unternehmen aufgeführt und es wird diskutiert, wie eine qualitative Beurteilung durchgeführt werden kann. Anschließend werden häufig verwendete Datenformate vorgestellt und Besonderheiten bei der Datenanbindung und Datenaufbereitung aufgelistet, die sich aus diesen Formaten ergeben. Probleme, die durch die Zusammenführung von verschiedenen Datenquellen aus verschiedenen Abteilungen resultieren, werden im dritten Abschnitt diskutiert. Eine Diskussion von häufig auftretenden Fallstricken bei der Aufbereitung von Daten zur Datenanalyse schließt diesen Abschnitt.

3.1 Datenquellen und ihre qualitative Beurteilung

Im Folgenden werden zuerst allgemeine Fragestellungen aufgelistet, die für alle Datenquellen herangezogen werden können, um eine qualitative Beurteilung der jeweiligen Datenquelle zu ermöglichen. Im Anschluss wird eine Übersicht über übliche Typen von Datenquellen in (industriellen) Unternehmen gegeben. Neben einer kurzen Beschreibung des Quellentyps wird auf Vor- und Nachteile, sowie zusätzliche Fragestellungen eingegangen, die eine qualitative Beurteilung ermöglichen.

Allgemeine Fragestellungen

• Wie lässt sich ein Zugriff auf die Daten realisieren? Ist ein Export möglich und wenn ja, in welches Format? Ist ein automatisierter Zugriff möglich?
• Wer ist verantwortlich für die Verwaltung von Zugriffen und Änderungen?
• Über welche Dimensionen verfügen die Daten? Wie viele Datenattribute finden sich (ungefähr) in der Datenquelle? Mit welcher Sampling-Rate/Granularität werden die Daten aufgezeichnet?
• Sind die Daten personenbezogen und dürfen sie daher ggf. nicht verwendet werden bzw. benötigen zusätzliche Mechanismen zur DSGVO-konformen Handhabung?
• Müssen die Daten anonymisiert oder normalisiert werden?

Berichtswesen

In den meisten Unternehmen hat sich für die einzelnen Prozessschritte ein (technisches) Berichtswesen etabliert, das von den Prozessexpertinnen und -experten des Anwenders verwendet wird, um retrospektive Ist-Analysen durchzuführen und die Kennwerte des entsprechenden Prozessschrittes zu überwachen. Dieses Berichtwesen kann als sehr gute erste Datenquelle für eine Prototypanalyse verwendet werden.

Vorteile dieses Datenquellentyps sind:

• Die Datenwerte in Berichten sind sinnvoll aufbereitete Kennzahlen, die den Prozessschritt beschreiben. Es kann davon ausgegangen werden, dass sie einen Einfluss auf den zu untersuchenden Anwendungsfall haben.
• Die im Anwendungsfall identifizierte Zielgröße, die untersucht werden soll, findet sich oft direkt in den Daten des Berichtswesens. Achtung: Manchmal wird sie jedoch nur zum Zeitpunkt der Erstellung des Berichts für diesen generiert und nicht abgespeichert.
• Viele Softwarelösungen, die für das Berichtwesen eingesetzt werden, verfügen über eine visuelle Möglichkeit zur Dateninspektion und sind gut geeignet, um die Daten des vorliegenden Anwendungsfalls zu untersuchen und ein Datenverständnis beim Entwickler zu schaffen, ohne schon technische Probleme der Datenanbindung angehen zu müssen.
• Der Zugriff auf diese Datenquelle ist einfach einzurichten. Viele Software-Lösungen verfügen bereits über einen einfachen Datenexport in gängige Formate.

Nachteile dieses Datenquellentyps sind:

• Die Daten im Berichtswesen sind oft hochaggregierte Kennzahlen, deren Granularität nicht ausreicht, um komplexere Zusammenhänge aufzuzeigen. Sie eignen sich gut für eine erste Prototypanalyse, für eine tiefergehende Analyse sollten aber weitere Datenquellen wie die den Berichten zugrundeliegenden Produktionsbetriebsdaten herangezogen werden.
• Datenexporte werden oft in einer menschenlesbaren Struktur erzeugt, die eine maschinelle Interpretation erschwert.
• Grundlegende Daten zur Bestimmung einer Kennzahl liegen erst deutlich später vor und sind zum Zeitpunkt der anvisierten Vorhersage nicht bekannt. Diese Größen können in der Analyse als Eingangsdaten nicht verwendet werden (wohl aber zur Bestimmung der Zielgröße, die vorhergesagt werden soll).

Zusätzliche Fragestellungen zur qualitativen Beurteilung der Datenquelle „Berichtswesen“:

• Aus welchen anderen Datenquellen werden die Daten des Berichtswesens berechnet? Diese Information ermöglicht in späteren Schritten des Datenanalyseprojektes eine einfache Identifikation von zusätzlichen Datenquellen, die die Gütequalität der Analyse erhöhen könnten.
• Ist die Zielgröße des Anwendungsfalls in dem Berichtswesen zu finden?
• Welche Daten sind potenziell erst nach dem anvisierten Zeitpunkt der Vorhersage verfügbar und können daher nicht als Eingangsdaten in der Analyse verwendet werden?

Produktionsbetriebsdaten

Die Automatisierung in industriellen Unternehmen hat dazu geführt, dass der Produktionsbetrieb in diesen Unternehmen von einer Vielzahl von Sensoren überwacht wird. Typische Beispiele sind Temperatur- oder Druckmessungen. Aber auch Stromverbräuche, Flussgeschwindigkeiten und viele weitere Größen werden erfasst. Diese Produktionsbetriebsdaten werden genutzt, um im Livebetrieb den Betriebszustand der Prozesskette zu überwachen und ggf. reaktiv steuernd einzugreifen. Die registrierten Datenwerte werden jedoch auch oft aufgezeichnet und teils für Jahre in größeren Datenbanken als historische Datensätze gespeichert.

Diese historischen Datensätze bieten eine sehr gute Grundlage für optimierte Datenanalysen, da der Betriebszustand des Prozesses mit einem sehr hohen Detailgrad in den Daten abgebildet ist, was das Potenzial für die Analyse und Vorhersage komplexer Zusammenhänge beinhalten kann.

Vorteile dieses Datenquellentyps sind:

• Durch die oft hohe Abtastrate ist der Betriebszustand des Prozesses in einem hohen Detailgrad abgebildet. Es kann davon ausgegangen werden, dass die Analyse von Produktionsbetriebsdaten ein großes Potenzial hat, auch komplexe Zusammenhänge im Prozess zu erkennen und vorherzusagen.
• Die hohe Anzahl unterschiedlichster Einflussgrößen, die in den Produktionsbetriebsdaten vorhanden sind, bietet ein hohes Potenzial, unbekannte multivariate Zusammenhänge zu finden.

Nachteile dieses Datenquellentyps sind:

• Der automatisierte Zugriff auf die gespeicherten historischen Daten, speziell für große Zeiträume, ist oft sehr komplex, insbesondere, weil häufig auch Änderungen am Prozess (zum Beispiel Rezeptänderungen, Wartung, Umbau) in diesen Zeiträumen auf-tauchen.
• Die große Dimensionalität der Daten erschwert die Handhabung in der Analyse durch einen höheren Speicherbedarf und längere Laufzeiten von Analyseprozessen. Auch die menschliche Interpretation von Zusammenhängen in den Daten ist erschwert, da die hohe Dimensionalität nur schwer erfasst werden kann. Dies stellt hohe Anforderungen an die Aufbereitung dieser Daten.
• Produktionsbetriebsdaten werden oft in ihrer initialen Form aufgezeichnet. Für die erfolgreiche Verwertung ist die Erstellung von Profilen der zu untersuchenden Einheiten (zum Beispiel einzelnen Batch-Produktionen oder Prozessschritten) notwendig. Beispielsweise werden die Daten kontinuierlich aufgezeichnet und unterschiedliche Prozessschritte oder unterschiedliche Batches in der Produktion sind nicht eindeutig gekennzeichnet.

Zusätzlich Fragestellungen zur qualitativen Beurteilung der Datenquelle „Produktionsbetriebsdaten“:

• In welcher Form sind historische Datensätze gespeichert? Welche Technologien/Datenformate werden verwendet?
• Die Speicherung von historischen Datensätzen wird oft von Manufacturing Execution Systems (MES) durchgeführt. Anwendende haben oft Zugang zu diesen Daten mit Hilfe des MES selbst, was für den täglichen Zugang eine geeignete Möglichkeit ist. Es sollte jedoch geklärt werden, ob ein direkter Zugang auf die historischen Datensätze (die zum Beispiel in Datenbanken abgelegt sein können), ohne das MES zu integrieren, für die Datenanalyse eine sinnvollere Möglichkeit darstellt.
• MES zeigen oft den IST-Zustand des Produktionsbetriebes, häufiger auch mit einer höheren Genauigkeit und Abtastrate als sie in den historischen Datensätzen gespeichert werden. Bei der Diskussion des Anwendungsfalls sollte beachtet werden, dass Analysen nur auf Basis der historischen Datensätze erstellt werden können.

Einzelmessungen/Labordaten

Auch wenn man Einzelmessungen (wie zum Beispiel Labormessungen) zu den Produktionsbetriebsdaten zählen könnte, unterscheiden sie sich in der Handhabung und Art der Speicherung oft stärker von typischen Betriebsdaten, wie sie von MES aufgenommen werden, sodass Einzelmessungen als eigener Datenquellentyp zu betrachten sind.

Einzelmessungen sind typischerweise manuell oder semi-automatisch vorgenommene Messungen an besonders kritischen Stellen des Produktionsbetriebes und dienen oft zur Qualitätssicherung. Die Auswertung dieser Messungen (wie zum Beispiel in Laboren) kann einen längeren Zeitraum benötigen und die gewonnenen Daten werden oft mithilfe zusätzlicher Software-Systeme in den allgemeinen Datenfluss des Unternehmens eingespeist.

Vorteile dieses Datenquellentyps sind:

• Die Tatsache, dass Einzelmessungen oft für kritische Stellen des Produktionsbetriebes eingeführt wurden, machen die Daten dieses Datenquellentyps zu idealen Eingangsdaten in einem Datenanalyseprojekt, da eine hohe Korrelation mit der Zielgröße wahrscheinlich ist.
• Die im Anwendungsfall identifizierte Zielgröße, die untersucht werden soll, findet sich oft als Einzelmessung (und ein häufiger Anwendungsfall kann darin bestehen, die Notwendigkeit einer aufwendigen/teuren Einzelmessung mithilfe einer Vorhersage zu verringern).

Nachteile dieses Datenquellentyps sind:

• Einzelmessungen sind oft deutlich später verfügbar als der anvisierte Zeitpunkt der Vorhersage, sodass diese Daten nicht leicht zur Echtzeitbewertung verwendet werden können, ohne dass Prozesse angepasst werden müssen.
• Einzelmessungen werden oft nur stichprobenartig durchgeführt. Dadurch stehen diese Daten nur für einen Teil oder nur auf einer hohen Aggregationsstufe der zu analysierenden Daten zur Verfügung.

Zusätzliche Fragestellungen zur qualitativen Beurteilung der Datenquelle „Einzelmessungen/Labordaten“:

• Ist die Zielgröße des Anwendungsfalls als Einzelmessung zu finden?
• Welche Daten sind potenziell erst nach dem anvisierten Zeitpunkt der Vorhersage verfügbar und können daher nicht als Eingangsdaten in der Analyse verwendet werden?
• Auf welcher Aggregationsstufe bzw. mit welcher Frequenz werden Einzelmessungen durchgeführt? Eine qualitative Diskussion, wie Datenattribute mit einer geringen Frequenz (und damit einer hohen Anzahl an fehlenden Werten) in der Datenanalyse behandelt werden können, sollte bei der Beurteilung der Datenquelle stattfinden. Optionen, wie solche Datenattribute gehandhabt werden können, sind:
  • Keine Nutzung des Datenattributes
  • Entfernen der Datenzeilen, die fehlende Werte beinhalten
  • Nutzung von Algorithmen, die mit fehlenden Werten umgehen können
  • Eine Kodierung der fehlenden Werte mit alternativen Werten
  • Ein zusätzliches kategorisches Datenattribut, das beschreibt, ob eine Messung stattgefunden hat, in Kombination mit einer der beiden vorangegangenen Optionen

Prozessparameter

Unter Prozessparametern werden alle Einstellungen verstanden, die manuell oder automatisch im Produktionsbetrieb bei den unterschiedlichen Prozessschritten verwendet werden. Dies können Zieltemperaturen, Ventileinstellungen, Mischungsverhältnisse von Eingangsstoffen oder die Dauer von Prozessschritten sein.

In ihrer schematischen Form unterscheiden sich diese Daten nicht besonders stark von Produktionsbetriebsdaten und Einzelmessungen, da sie (besonders bei automatisierten Einstellungen) mit einer hohen Abtastrate verändert und abgespeichert werden oder bei manuellen Einstellungen ähnlich wie Einzelmessungen behandelt werden können.

Tatsächlich werden viele Prozessparameter direkt durch MES eingestellt und ihre Einstellungen in historischen Datensätzen abgespeichert. Einstellungen, die in Einzelwerten vorhanden sind, werden oft durch Enterprise-Resource-Planning-Systeme (ERP) gesteuert und durch diese in den allgemeinen Datenfluss des Unternehmens eingespeist.

Vorteile dieses Datenquellentyps sind:

• Prozessparameter beschreiben die Steuerung des Produktionsbetriebes und die Wahrscheinlichkeit ist hoch, dass eine hohe Korrelation zwischen den Prozessparametern und der Zielgröße besteht. Die Daten eignen sich daher gut als Eingangsdaten der Analyse.
• Prozessparameter können in einem gewissen Umfang (s. Nachteile) verändert werden. Eine Optimierung von Prozessparametern auf Basis eines trainierten Vorhersagemodells ist daher ein häufig durchgeführter Anwendungsfall in Datenanalyseprojekten mit einem großen Potential zur Erzeugung von Mehrwert.

Nachteile dieses Datenquellentyps sind:

• Wie bei Produktionsbetriebsdaten stellt die hohe Dimensionalität von Prozessparametern desselben Schemas Anforderungen an den Zugriff, die Handhabung und Aufbereitung sowie die sinnvolle Profilbildung in der Datenanalyse (s. Nachteile Produktionsbetriebsdaten).
• Bei Prozessparametern von Einzelwerteinstellungen muss die Frequenz und Aggregationsstufe dieser Daten ähnlich wie bei Einzelmessungen beachtet werden.
• Nicht alle Prozessparameter können einfach oder überhaupt verändert werden. Sicherheitsbedenken, Skepsis gegenüber der durchgeführten Analyse und technische Möglichkeiten limitieren dies.
• Einschränkungen in den Einstellmöglichkeiten der Prozessparameter sind zwar oft den Anwendenden bekannt, eine generelle mathematische Bedingung zu formulieren, ist allerdings oft komplex.
• Prozessparameter von automatisierten Steuerungen basieren oft auf Regelsystemen. Auch wenn das Verhalten dieser Regelsysteme sich in den Daten widerspiegelt, kann es schwierig sein, dieses Regelsystem nur mithilfe der Daten im Modell abzubilden.

Zusätzliche Fragestellungen zur qualitativen Beurteilung der Datenquelle „Prozessparameter“:

• Welche Prozessparameter können in welchem Umfang verändert werden?
  • Besonderes Augenmerk sollte hier auf die spätere Einbindung in den laufenden Betrieb gelegt werden.
  • Ist zum Beispiel ein Betrieb des Optimierungsprozesses als Empfehlung für den Anwender möglich oder ein zeitweise paralleler Simulationsbetrieb, der Vertrauen in die Vorhersagen des Optimierungsprozesses stärkt?
• Gibt es Regelsysteme hinter automatisierten Steuerungen, deren Eigenschaften vielleicht in die Modellierung miteinbezogen werden können (oder müssen)? Und wie häufig werden diese Regeln angepasst?

Fehlermeldungen

Fehlermeldungen sind automatisierte Statusmeldungen von Maschinen, die im laufenden Betrieb anfallen. Gerade kurze Fehlerstatusmeldungen von (kleineren) Subsystemen treten oft auf, ohne dass es direkt zu einem größeren Problem in der Produktion kommt und ohne dass ein Eingreifen nötig ist. Jedoch können die Frequenz und die Abfolge dieser Fehlermeldungen Hinweise auf aufkommende größere Probleme bieten.

Vorteile dieses Datenquellentyps sind:

• Aufgrund der hohen Wahrscheinlichkeit einer Korrelation von Frequenz und Abfolge von Fehlermeldungen zu dem Auftreten größerer Probleme (Ausfälle, Maschinendefekte) eignen sich Fehlermeldungen sehr gut als Eingangsdaten für Datenanalyseprojekte der vorausschauenden Instandhaltung und Ausfallsicherung.
• Bei dem Anwendungsfall der Vorhersage von auftretenden Fehlern beinhalten Fehlermeldungen die Zielgröße des Anwendungsfalls.

Nachteile dieses Datenquellentyps sind:

• Fehlermeldungen sind oft als Fehlercode codiert. Eine Inbezugnahme der Definition des Fehlers kann komplex sein.
• Fehlermeldungen können als Strom kategorischer Zeitreihendaten mit nicht äquidistanten Zeitstempeln gesehen werden. Die Aufbereitung und Analyse dieser Daten können komplex sein.
• Fehlermeldungen können auch bei gewollten manuellen Eingriffen (zum Beispiel zum Säubern von Maschinen etc.) entstehen und sind meist nicht direkt vom normalen Betriebszustand getrennt. Eine komplexere Aufbereitung ist nötig und durch meist fehlende Buchführung über solche Eingriffe erschwert.
• Bei der Vorhersage von seltenen Ereignissen (zum Beispiel dem Defekt eines Bauteils) kann das Aufkommen von vielen Fehlermeldungen suggerieren, dass eine ausreichende Datenmenge zur Verfügung steht, um solche Ereignisse vorherzusagen, obwohl die eigentliche Anzahl an Ereignissen klein ist.

Zusätzliche Fragestellungen zur qualitativen Beurteilung der Datenquelle „Fehlermeldungen“:

• Gibt es eine Definition der Fehlermeldungen?
• Wie hoch ist die Frequenz von kritischen Fehlermeldungen?
• Gibt es manuelle Eingriffe in den Produktionsbetrieb, die zu Fehlermeldungen führen? Wie können diese Eingriffe aus den Daten gefiltert werden?

Ereignislogs

Unter Ereignislogs wird die Auflistung aller Ereignisse verstanden, die zu einer größeren Änderung des Produktionsbetriebes geführt haben. Dies kann zum Beispiel der Austausch einer Maschine sein, die Änderung der Steuerungslogik, Rezepturänderungen und Ähnliches. Auch wenn Ereignislogs oft nicht als potenzielle Datenquelle wahrgenommen werden, ist die Bedeutung dieses Datenquellentyps nicht zu unterschätzen. Nur bei Vorlage eines Ereignislogs kann beurteilt werden, ob es im angestrebten Zeitfenster zu Kontextwechseln kam, die bei der Datenanalyse beachtet werden müssen.

Vorteile dieses Datenquellentyps sind:

• Die Notwendigkeit, Kontextwechsel in Datenanalyseprojekten einzubeziehen, macht Ereignislogs zu einer notwendigen Datenquelle für Datenanalyseprojekte.
• Eine Übersicht über vergangene Ereignisse ermöglicht eine Beurteilung, wann ein in den Produktivbetrieb gebrachtes Datenanalyseprojekt möglicherweise angepasst werden muss.

Nachteile dieses Datenquellentyps sind:

• Ereignislogs sind selten in anderen Datenquellen des Unternehmens eingebunden. Oft handelt es sich um manuell (teils handschriftlich) gepflegte Listen, die auch über verschiedene Abteilungen verteilt sein können.
• Manche Änderungen sind gar nicht aufgezeichnet und können nur aus Änderungen in den Dateneigenschaften anderer Datenquellen rekonstruiert werden.

Zusätzliche Fragestellungen zur qualitativen Beurteilung der Datenquelle „Ereignislogs“:

• Gibt es Ereignislogs im Unternehmen? Wie werden diese nachgehalten?
• Ist ein Bewusstsein für die Bedeutung von Kontextwechseln in der Datenanalyse bei den Anwendenden vorhanden?

Externe Datenquellen

Unter externen Datenquellen werden solche Daten verstanden, die nicht im Unternehmen anfallen. Dies können zum Beispiel Wetterdaten, statistische Informationen von öffentlichen Instituten oder Datenquellen von Zuliefererfirmen sein.

Vorteile dieses Datenquellentyps sind:

• Externe Datenquellen können, besonders bei Prozessen, bei denen ein Einfluss externer Größen vermutet wird, einen wertvollen Informationsgewinn für den geplanten Anwendungsfall bringen.

Nachteile dieses Datenquellentyps sind:

• Die Einbindung von externen Datenquellen in den Datenanalyseprozess kann sehr komplex sein. Möglicherweise müssen manuelle oder semi-automatische Prozesse aufgesetzt werden, um regelmäßig Daten aus der externen Datenquelle zu exportieren und in die eigene Prozesskette einzubinden.
• Externe Datenquellen verfügen fast immer über andere Aggregationsstufen, Abtastraten und Identifikationsattribute. Eine Zusammenführung mit internen Datenquellen ist oft aufwendig.
• Die Verfügbarkeit der Quelle liegt selten im eigenen Einflussbereich.

Zusätzliche Fragestellungen zur qualitativen Beurteilung der Datenquelle „Externe Datenquellen“:

• Gibt es Einflussgrößen auf den zu analysierenden Prozess, die nicht in internen Datenquellen abgebildet sind?
• Gibt es externe Datenquellen, die dazu integriert werden können?

Schlunder, P., Temme, F. (2022). Unternehmensdaten – Informationen aus gewachsenen, komplexen Systemen herausarbeiten. In: Rohde, M., Bürger, M., Peneva, K., Mock, J. (eds) Datenwirtschaft und Datentechnologie. Springer Vieweg, Berlin, Heidelberg.

https://doi.org/10.1007/978-3-662-65232-9_17

http://creativecommons.org/licenses/by/4.0/deed.de