17.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 (RapidMiner Inc. 2019). 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 (2019) des Technologieprogramms Smarte Datenwirtschaft und IIP-Ecosphere (2020) 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.
Advertisement
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: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.
1.
Probleme bei der Gewährleistung einer durchgängigen Datenpipeline mit gesicherter Datenqualität
2.
Organisatorische Unternehmensstrukturen, die noch nicht auf Datenanalyse-Projekte ausgelegt sind
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 (Plattform Lernende Systeme, KI im Mittelstand 2021) 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“ (Bashir et al. 2018). Dementsprechend ist eine frühzeitige Einbeziehung der beteiligten Partnerinnen und Partner innerhalb des Unternehmens, bei dem ein Projekt umgesetzt wird, unabdingbar.
Advertisement
Die referenzierten Broschüren bieten Ansätze zur Umsetzung von Datenanalyse-Projekten mit Fokus auf die Berücksichtigung und Einbindung der Interessen der Mitarbeitendenden. 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.
17.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?
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: 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.
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.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.
Darüber hinaus stellt sich häufig bei der Diskussion potenzieller Analysen heraus, dassFü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.
1.
die ursprünglich definierte Zielgröße der Analyse nicht zielführend im Hinblick auf die Aufgabenstellung ist und
2.
eine Umformulierung der Problemstellung bzw. ein Umdenken bei der Wahl des Anwendungsfalls die Erfolgswahrscheinlichkeit des Projektes stark erhöhen kann.
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 (s. Abschn. 17.4).
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:
1.
Vertretung des Industrial Engineerings/der Unternehmensplanung
-
Zur Klärung von Fragen des Change Managements
-
Zur Klärung der geplanten Nutzung der Analyseergebnisse
2.
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
3.
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)
Beispiel: Agenda für Projekte mit Fokus „Maschinelles Lernen als Werkzeug“
1.
Begrüßung und Vorstellungsrunde, 10 Min.
2.
Übersicht Use Case (Anwendende), 20 Min.
3.
Kurzer Einstieg „Maschinelles Lernen“ und Anwendungsszenarien (Entwickelnde), 15 Min.
4.
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
5.
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
6.
Überblick Software-Anbieter (Entwickler, IT ggf. benötigt), je 15 Min.
-
Aufzeigen der Nutzungsmöglichkeiten
-
Vorstellung von Integrationsmöglichkeiten in die IT-Systemlandschaft
7.
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
8.
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: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.
1.
Informationslage reicht aus, um ein Use-Case-Summary-Dokument (1–2 Seiten) zu erstellen,
2.
Anwendende wissen um das Potenzial des Use Case und der Umsetzungsmöglichkeiten mit der Software des Entwicklers,
3.
Datenzugriffe und Softwarenutzung sind geklärt.
Wie es nach dem ersten Treffen weitergehen kann, wird im Abschnitt „Erst die Datenpipeline, dann die Analyse“ beschrieben (s. Abschn. 17.4). 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.
17.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.
17.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:Nachteile dieses Datenquellentyps sind:Zusätzliche Fragestellungen zur qualitativen Beurteilung der Datenquelle „Berichtswesen“:
-
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.
-
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).
-
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:Nachteile dieses Datenquellentyps sind:Zusätzlich Fragestellungen zur qualitativen Beurteilung der Datenquelle „Produktionsbetriebsdaten“:
-
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.
-
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.
-
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:Nachteile dieses Datenquellentyps sind:Zusätzliche Fragestellungen zur qualitativen Beurteilung der Datenquelle „Einzelmessungen/Labordaten“:
-
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).
-
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.
-
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:Nachteile dieses Datenquellentyps sind:Zusätzliche Fragestellungen zur qualitativen Beurteilung der Datenquelle „Prozessparameter“:
-
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.
-
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.
-
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:Nachteile dieses Datenquellentyps sind:Zusätzliche Fragestellungen zur qualitativen Beurteilung der Datenquelle „Fehlermeldungen“:
-
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.
-
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.
-
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:Nachteile dieses Datenquellentyps sind:Zusätzliche Fragestellungen zur qualitativen Beurteilung der Datenquelle „Ereignislogs“:
-
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.
-
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.
-
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:Nachteile dieses Datenquellentyps sind:Zusätzliche Fragestellungen zur qualitativen Beurteilung der Datenquelle „Externe Datenquellen“:
-
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.
-
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.
-
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?
17.3.2 Datenformate
Je nach Form der Daten gibt es verschiedene Herausforderungen in der allgemeinen Handhabung und es werden unterschiedliche Technologien benötigt, um Aufbereitungs- und Analyseschritte durchführen zu können. Auch hat die Form der Daten Auswirkung auf die großflächige Handhabung innerhalb eines Unternehmens über Abteilungen hinweg. Fragen der Datenhaltung und des Transfers sowie der Verfügbarkeit sind maßgeblich durch den Datentyp bedingt.
Tabellarische Daten
Typischerweise werden in Unternehmen vor allem tabellarische Daten vorgehalten, die meist in Einzeldateien aus der Buchhaltung vorliegen, in Manufacturing-Execution-Systemen (MES) oder Enterprise-Resource-Planning-Systemen (ERP) hinterlegt sind oder direkt in einer Datenbank abgespeichert werden. Auch gestreamte Daten werden oft in tabellarischen Strukturen batchweise hinterlegt.
Typische Probleme und Lösungsvorschläge:
-
Daten in Tabellenkalkulationsdateiformaten werden häufig lokal verwaltet und liegen ohne Versionierung vor. Dieses Problem lässt sich am leichtesten durch die Überführung der Daten in Online-Lösungen wie Office 365 oder Google Docs lösen. Jedoch ist hierbei die aktuelle Rechtslage zur DSGVO-Konformität der Onlinedienste zu berücksichtigen. Es gibt auch zahlreiche Produkte die als Komplettlösung aus Hard- und Software oder als reines Softwareangebot für eigene Hardware eingekauft werden kann.
-
Einzelne Seiten in Dokumenten sind oftmals überfrachtet, zum Beispiel mit nicht maschinenlesbaren Strukturen in Tabellen inklusive verschiedener Randbemerkungen. Eine Lösung bietet die Erstellung von Guidelines und Vorlagen zum Anlegen von Dokumenten mit einer einheitlicheren Struktur.
-
Um fehlenden Zugriff auf „eigene“ Daten in MES- oder ERP-Systemen zu vermeiden, muss ein Bewusstsein für die Wichtigkeit von Datenschnittstellen geschaffen werden, sodass bei Anschaffungen auf diese Funktionalität geachtet wird.
Streaming-/Sensordaten
Gestreamte Daten, oft im Zusammenhang mit der Aufzeichnung von Sensorwerten, werden in vielen Fällen in tabellarischer Form abgespeichert, bringen jedoch eigene Herausforderungen im Vergleich zu nicht gestreamten (tabellarischen) Daten mit sich.
Gestreamte Daten können sowohl live als auch in Batches verarbeitet werden. Die Live-Verarbeitung wird meist bei der Anwendung eines Vorhersagemodells oder der Bewertung von Daten verwendet, während die batchweise Verarbeitung bei nicht zeitkritischen Beurteilungen oder der Erstellung eines Vorhersagemodelles Verwendung findet. Häufig werden zur Verarbeitung gestreamter Daten Edge Devices eingesetzt. Als Edge Device werden meist Geräte bezeichnet, die einen Teil der Datenverarbeitung direkt durchführen. Nicht selten sind diese Geräte direkt mit Sensoren verknüpft und am Ort der Datenaufzeichnung angebracht. Edge Devices sind in vielen Fällen Teil eines größeren Systems, welche mehrere Edge Devices verwalten kann und aufwändigere Rechenprozesse (zum Beispiel in der Cloud) ausführt, um lediglich aktualisierte Vorhersagemodelle zurück auf die Edge Devices zu spielen. Sie bieten die Möglichkeit, Analyseschritte direkt nah am oder sogar im Sensor durchzuführen, während gleichzeitig eine regelmäßige Sicherung beispielsweise in Cloudspeichern möglich ist. Bedingt durch diese Umstände benötigt die Analyse solcher Daten ein enges Zusammenspiel aus Soft- und Hardware. Nicht selten muss eine Vielzahl an Sensoren über ein zentrales System orchestriert werden. Diese Gegebenheiten müssen bei der Planung einer Datenpipeline für Streamingdaten berücksichtigt werden.
So erzeugte Datensätze werden in vielen Fällen als Batches abgespeichert und beinhalten je nach Szenario nur Änderungen in den Daten. Werden solche Datenquellen gehandhabt, muss beispielsweise über Batches hinweg Buch geführt werden, welche Werte zuletzt aktuell waren. Die Zusammenarbeit mit Sensorherstellern kann hier ein großes Plus für ein erfolgreiches Projekt sein, insbesondere da die Zuordnung zwischen Sensorendpunkten und Datenpunkten von Interesse bei vielen Sensoren noch einer tiefen Kenntnis über technische Details der Datenhandhabung im Sensor bedarf.
Texte
Ein weiteres häufig verwendetes Format sind Texte. Viele Informationen liegen in Form von Textdokumenten, Kommentaren oder Logbüchern vor. Obwohl Logbücher nicht selten schon tabellarisch geführt sind und textuelle Spalten enthalten, bestehen trotzdem ähnliche Problematiken wie bei der reinen Textverarbeitung. Wichtige Problematiken bei der Arbeit mit textuellen Daten sind passende Repräsentationsfindung, Nutzung des Kontexts und vor allem mangelnde Eindeutigkeit der verwendeten Sprache. Viele Datenanalyseverfahren benötigen Daten in numerischer Form, sodass eine Umwandlung des Texts in ein numerisches Format (Zahl oder Dezimalzahl) notwendig ist. Dabei sollte möglichst der Kontext einzelner Wörter oder Textabschnitte erhalten bleiben.
Eine vollständige Abbildung natürlicher Sprache ist damit aber auch nicht möglich. Beim Übergang in den Produktiveinsatz sind dann zum Beispiel Mehrdeutigkeiten oder neue Bezeichnungen problematisch.
Im Folgenden sollen hier kurz zwei Optionen aufgezeigt werden, die bei diesen Problemen helfen können:
1.
Verwendung eines einheitlichen Vokabulars und einer Struktur für zum Beispiel Arbeitsanweisungen: Werden beispielsweise Instruktionen zur Fertigung eines Produktes festgehalten, sollten diese einem festen Schema folgen, das die Struktur der Anweisung vorgibt und möglichst auf ein vordefiniertes, zentral gepflegtes Vokabular zurückgreift. Im Alltag werden trotzdem durch Verwendungen von Synonymen und Tippfehlern Ungenauigkeiten auftauchen, diese lassen sich aber durch Unterstützung bei der Eingabe und durch Synonymwörterbücher abmildern.
2.
Nutzung und Anpassung vorhandener Sprachmodelle: Existierende Sprachmodelle zum Beispiel zur Klassifikation von Wörtern (Named Entity Recognition) müssen häufig nur auf kleinen Datensätzen mit geringem manuellem Aufwand angepasst werden, um auch bei uneindeutigen Relationen eine höhere Trefferquote zu erlangen.
Bilder, Audioaufnahmen und weitere Formate
Neben den zuvor genannten Formaten werden zunehmend auch Bilder, Audioaufnahmen, Videos, Graphen oder andere proprietäre Formate verwendet.
Insbesondere für Bilder und Videos erschwert sich die Handhabung zusätzlich durch ihren erhöhten Speicherbedarf und limitierte Möglichkeiten, Metadaten zu hinterlegen. Daher wird es aufwändiger, Daten konsistent zu handhaben, ohne Zuordnungen zu verlieren oder hohe zusätzliche Zeit- und Speicheraufwände zu verursachen. Für diese Formate wie auch für große Mengen an Sensordaten empfiehlt es sich daher, die Verarbeitung möglichst nah an den Ort der Lagerung oder Erzeugung der Daten zu schieben. Für Bilder und Videos bedeutet dies oft ein Verarbeiten in Cloud-Umgebungen, da dort auch direkt eine einfache Anpassung an benötigten Rechenressourcen vorgenommen werden kann. Für Sensordaten können Edge Devices und die damit verbundene Infrastruktur zum Einsatz kommen.
Auch bei diesen Formaten ist die passende Findung einer Repräsentation entscheidend. Zwar bieten vor allem Deep-Learning-Ansätze Möglichkeiten, direkt in Rohdaten arbeiten zu können, doch werden auch dabei intern Repräsentationen erstellt, die es zu leiten gilt. Wie auch bei Texten werden nicht selten existierende Deep-Learning-Modelle als Grundlage genutzt, um Anpassungen mit eigenen Daten vorzunehmen. Doch hierdurch entstehen neue Herausforderungen, die nachfolgend behandelt werden.
Nicht technische Probleme
Extern bereitgestellte Modelle wurden zuvor auch auf Daten trainiert und übernehmen Eigenschaften dieser Daten sowie Entscheidungen seitens der Entwicklenden während des Trainings. Hieraus entsteht die Notwendigkeit, solche Modelle tiefgehend auf Voreingenommenheit und Verhalten in seltenen Situationen zu untersuchen. Dies sollte zwar auch immer für eigene Analysen durchgeführt werden, jedoch besteht hier die weitere Problematik, dass die verwendete Datengrundlage und besagte Entscheidungen während der Modellerstellung wesentlich schwerer nachzuvollziehen sind als eigene Entwicklungen.
Allgemein sollte an dieser Stelle darauf hingewiesen werden, dass bei der Nutzung und Zusammenführung von internen und externen Daten und Modellen soziologische und kulturelle Aspekte bei der Datenhandhabung eine wichtige Rolle spielen und auch im industriellen Kontext nicht ignoriert werden dürfen.
Es muss zum Beispiel überprüft werden, ob Daten oder Modelle alle Populationen ausreichend repräsentieren; Sensordaten in ihren Strukturen Arbeitsverhalten von Mitarbeitenden widerspiegeln oder der Einsatz von Audio- und Videosensoren im Produktionsbereich Persönlichkeitsrechte verletzen. Diese Überprüfungen sind nicht rein technischer Natur und sollten auch nicht nur von Technikerinnen und Technikern angegangen werden.
Neben einer frühzeitigen Einbindung (idealerweise bereits bei der Planung) von Personengruppen, deren Daten direkt oder indirekt in einer Datenanalysepipeline verwendet werden, ist hier vor allem die Schaffung eines allgemeinen Bewusstseins beteiligter Partner ein wichtiger Schritt. Mögliche Startpunkte, um mehr über diese Thematik zu lernen, sind das Ethik Briefing (Plattform Lernende Systeme, KI verantwortungsvoll entwickeln und anwenden: Plattform Lernende Systeme veröffentlicht Leitfaden 2020) der Arbeitsgruppe IT-Sicherheit, Privacy, Recht und Ethik der Plattform Lernende Systeme sowie „Towards Reflective AI: Needs, Challenges and Directions for Future Research“ (Novak et al. 2021).
17.3.3 Zusammenführung verschiedener Datenquellen
Wie in den vorangegangenen Abschnitten beschrieben sind in Unternehmen eine Reihe von unterschiedlichen Datenquellen vorhanden, die die Daten mithilfe verschiedener Technologien in unterschiedlichen Formaten speichern. Eine Zusammenführung dieser Datenquellen ist daher in jedem Datenanalyseprojekt ein essenzieller Schritt, um beispielsweise Einflüsse auf die Produktion einzelner Produkte entlang des gesamten Herstellungsprozesses berücksichtigen zu können.
Das Ziel dieser Zusammenführung ist die Erstellung eines repräsentativen Datensatzes, der den (Betriebs-)Zustand des Anwendungsfalls abbildet und in dem die Daten der verschiedenen Quellen semantisch korrekt zusammengeführt werden. Je nach Größe dieses Datensatzes kann er in tabellarischer Form als Einzeldatei oder in einer Datenbank gespeichert werden, um anschließend analysiert zu werden. Auch eine getrennte Speicherung von Einzelabschnitten (Batches) ist möglich. Dabei muss beachtet werden, dass die Struktur und das Schema der Abschnitte einheitlich sind.
In diesem Schritt ist nicht nur der repräsentative Datensatz ein wichtiges Ergebnis, sondern auch die Logik (also die Zusammenführungs- und Verarbeitungsschritte), diesen zu erstellen. Diese Datenverarbeitungsschritte müssen in Form einer nachvollziehbaren und wartbaren Datenverarbeitungspipeline gespeichert werden, da diese in der späteren Inbetriebnahme des erarbeiteten Vorhersagemodells (also in der Anwendung dieses Modells auf Live-Betriebsdaten) verwendet wird.
Im Folgenden werden wichtige Aspekte und häufig auftretende Fallstricke dieser Zusammenführung beleuchtet und Fragestellungen diskutiert, die im Vorfeld geklärt werden sollten.
Profilbildung/Aggregation auf Basis der Zielgröße
Nach der Identifizierung der Zielgröße des Anwendungsfalls muss ein Profil für jede Einheit der Zielgröße erstellt werden. Dies beinhaltet zum Beispiel die Aggregation von Produktionsbetriebsdaten auf die Stufe der Zielgröße. Wenn beispielsweise die Qualität eines Produktes vorhergesagt werden soll, müssen alle Produktionsbetriebsdaten, die über den Zeitraum der Produktion dieses Produktes aufgezeichnet wurden, zu einem Profil aggregiert werden. Dabei bietet es sich an, für die Einheiten der Zielgröße ein Identifizierungsattribut (s. nächster Abschnitt) einzuführen bzw. zu nutzen und es für alle weiterführenden Schritte beizubehalten.
Identifizierungsattribute
Nahezu alle Datenquellen verfügen über Identifizierungsattribute. Diese können Produkt-IDs, Startzeitpunkte von Prozessschritten, Messzeitpunkte oder Ähnliches sein. Eine Zusammenführung von verschiedenen Datenquellen wird vereinfacht, wenn dasselbe Identifizierungsattribut über Datenquellen hinweg vorhanden ist oder ein Zusammenhang zwischen verschiedenen Identifizierungsattributen hergestellt werden kann. Dies kann zum Beispiel die Zuordnung von Produkt-ID und Labormessungs-ID sein oder der Abgleich verschiedener Zeitpunkte. Jedoch kann dies gerade bei Schüttgut schwierig werden. Es gilt, frühzeitig zu klären, wie Daten über beschreibende Eigenschaften beispielsweise eines losen Rohstoffes von der Anlieferung über die Verarbeitung hinweg bis zum finalen Produkt zugeordnet werden können.
Zuordnung über Zeitversatz
Einige Datenquellen verfügen zwar über identifizierbare Zeitstempel, aber im Betrieb gibt es Zeitversätze zwischen aufgenommenen Daten unterschiedlicher Quellen, oder sogar innerhalb einer Quelle. Zum Beispiel können Eigenschaften von angelieferten Rohstoffen zu einem früheren Zeitpunkt aufgenommen werden als diese konkrete Anlieferung in der Produktion verwendet wird. Um beide Datenquellen zusammenführen zu können, muss der Zeitversatz zwischen diesen Prozessschritten bekannt sein und bei der Zusammenführung beachtet werden. Auch ein geschätzter (mittlerer) Zeitversatz kann durchaus verwendet werden, es sollte jedoch beachtet werden, dass dadurch eine potenzielle Unschärfe in den Analyseergebnissen entstehen kann.
Verschnitt, Mischung, und Aufteilung
Bei komplexen Produktionsketten kann es oft zu Verschnitt-, Mischungs- oder Aufteilungssituationen kommen. Zum Beispiel kann ein späterer Prozessschritt auf einen Verschnitt verschiedener Inputprodukte (zum Beispiel verschiedener Tanks) arbeiten oder ein größeres Rohprodukt wird zur weiteren Verarbeitung in kleinere Teile geschnitten.
Bei einer Zusammenführung über diese Prozessschritte hinweg muss besonders Augenmerk darauf gelegt werden, dass die Daten diese Verschnitte, Mischungen oder Aufteilungen widerspiegeln. Dies kann zum Beispiel durch Mittelung der Werte aus unterschiedlichen Inputdatenquellen geschehen oder durch Verwendung probabilistischer Ansätze.
Handhabung von Zeitstempeln
Da bei der Zusammenführung von Datenquellen Zeitstempel häufig eine große Rolle spielen, ist es wichtig, auf deren korrekte Handhabung zu achten. Bei der Zusammenführung zweier Zeitstempel sollte darauf geachtet werden, ob diese die gleiche Zeitzone beschreiben und idealerweise über die gleiche Genauigkeit verfügen. Weiterhin sollte bedacht werden, wie die Zusammenführung zweier teilweise überlappender Zeitbereiche gehandhabt wird. Soll zum Beispiel nur der überlappende Bereich betrachtet werden oder der gesamte Zeitbereich?
Bei der Zusammenführung von Zeitbereichen von hochfrequenten Datenquellen mit Daten von Einzelmessungen sollte bedacht werden, dass hochfrequente Datenquellen oft auch Daten für Zwischenschritte (Vorbereitungsphasen, Säuberungen, Pausen) beinhalten die ggf. gefiltert werden müssen, bevor eine Zusammenführung durchgeführt werden kann. Darüber hinaus ist häufig die Synchronität vorhandener Zeitstempel problematisch. Nicht alle Sensoren bzw. Datenspeicherungssysteme sind im gleichen Takt geschaltet, es gilt somit zu prüfen, ob Synchronisationsdienste im Einsatz sind.
17.3.4 Datenaufbereitung zur Datenanalyse
Nach der Identifizierung und qualitativen Beurteilung von vorhandenen Datenquellen und der Beurteilung der Zusammenführung dieser, ist die Datenaufbereitung der nächste Schritt bei der Betrachtung der Datenlage in einem industriellen Unternehmen.
Auch wenn die notwendigen Schritte zur Datenaufbereitung sehr vielfältig sein können und eine Behandlung aller möglichen Schritte kaum möglich ist, soll im Nachfolgenden eine Übersicht über häufig auftretende Fallstricke im Rahmen der Aufbereitung von Daten aus gewachsenen Datenstrukturen gegeben werden.
Behandlung fehlender Werte
Fehlende Werte können in allen Datenquellen und nach der Zusammenführung verschiedener Datenquellen vorhanden sein. Die Behandlung dieser Werte ist allerdings stark von der Ursache der Entstehung dieser fehlenden Werte abhängig.
Einige Möglichkeiten sind:
-
Fehlerhafte Aufnahme einzelner Datenpunkte (zum Beispiel Fehler beim Speichern): Diese Punkte könnten mithilfe anderer Datenpunkte extrapoliert werden.
-
Fehlende Werte beschreiben eigentlich den Grundzustand (und könnten gegebenenfalls durch eine Null ersetzt werden).
-
Größere Zeitabstände in denen nicht gemessen wurde (Ausfall eines Sensors) oder nur stichprobenartige Messungen vorgenommen wurden (s. Datenquellentyp: Einzelmessung).
-
Fehlende Werte beschreiben keine Änderung (und können daher durch den letzten nicht fehlenden Wert ersetzt werden): Dabei ist zu beachten, dass es bei Datenauszügen passieren kann, dass der letzte valide Wert nicht im Zeitfenster des Auszuges vorhanden ist und damit am Anfang die fehlenden Werte nicht ersetzt werden könnten, obwohl der Wert eigentlich in der Datenquelle vorhanden ist.
-
Es liegen unterschiedliche Varianten eines Produktes vor, die keine Änderungen zur Grundform des Produktes aufweisen, und somit Spalten nicht ausgefüllt wurden.
Datendopplung
Sowohl durch die Datenzusammenführung als auch durch die Datenaufnahme im Unternehmen kann es passieren, dass Einträge sich in den Daten doppeln. Speziell bei Einzelmessungen und manuell eingetragenen Daten kann es passieren, dass es für die gleichen IDs bzw. Zeitstempel Mehrfacheinträge gibt. Doppelte Dateneinträge müssen für die Datenanalyse bereinigt werden.
Datentyp-Konvertierungen
Beim Zugriff auf Daten kann es passieren, dass Daten in einen Datentyp konvertiert werden, der nicht ihrer Bedeutung entspricht. Im Folgenden werden einige typische Konvertierungsprobleme gelistet:
-
Zeitstempel sind nominal: Beim Export von Zeitstempeln kommt es häufig dazu, dass Zeitstempel in nominale Form (als Text) konvertiert werden. Dies erschwert deutlich die Verarbeitung dieser Daten. Je nach Darstellungsformat funktionieren keine Sortierungen, das Zusammenführen ist deutlich erschwert und die Extraktion von Zeitinformationen ist nicht möglich. Bei der Rückkonvertierung in einen Zeitdatentyp muss dabei auf das Darstellungsformat und die Zeitzone geachtet werden, um eine korrekte Konvertierung zu gewährleisten.
-
Numerische Daten sind nominal (Fall I): Besonders bei manuell aufgenommenen Daten kann es vorkommen, dass einzelne Einträge eines eigentlich numerischen Datenattributes mit nominalen Werten befüllt sind. Zum Beispiel kann statt eines konkreten Wertes nur ein „kleiner als“ eingetragen worden sein. Dies führt meist dazu, dass das ganze Datenattribut als nominales Attribut verwendet wird oder die nicht numerischen Werte zu fehlenden Werten konvertiert werden. Eine Konvertierung in einen numerischen Datentyp ist hier oft von Vorteil. Dabei sollte, wenn möglich, die zusätzliche Information, die durch die (einzelnen) nominalen Einträge gegeben ist, erhalten bleiben, zum Beispiel durch Erzeugung einer zusätzlichen nominalen Spalte.
-
Numerische Daten sind nominal (Fall II): Es kann auch vorkommen, dass numerische Daten komplett als nominale Daten exportiert werden. Zum Beispiel durch einen textuellen Export, oder dass unterschiedliche Dezimalzeichen verwendet werden. Bei einer Konvertierung in einen numerischen Datentyp ist darauf zu achten, dass Dezimalzeichen und ggf. Tausendertrennzeichen bei der Konvertierung denen im Datensatz entsprechen und bei Zusammenführung aus verschiedenen Quellen hier landesspezifische Unterschiede mit hereinspielen können.
-
Kategorische Daten sind numerisch: Es kommt öfter vor, dass numerische Werte für kategorische Bezeichnungen in Unternehmen verwendet werden, zum Beispiel die fortlaufende Nummer von Tanks oder Silos oder ein als Zahl kodierter Status. In diesem Fall werden diese Datenattribute meist als numerische Attribute exportiert, wodurch Algorithmen einen (nicht vorhandenen) numerischen Zusammenhang zwischen den Werten annehmen würden. Eine Konvertierung in einen kategorischen Datentyp ist daher empfehlenswert. Zur besseren Verständlichkeit können die Werte auch mit einem Vorsatz versehen werden, um ihren kategorischen Charakter zu betonen („4“ → „Tank 4“).
Verwendung von „magischen“ Werten
In gewachsenen Prozess- und Datenstrukturen kann es oft vorkommen, dass häufig als „magische“ Werte bezeichnete Einträge für besondere Situationen oder Messungen verwendet werden. Beispiele können sein: „−1“ für fehlerhafte Messungen eines Sensors, der ansonsten nur positive Werte liefert; „999“ für einen Überlaufwert. In diesem Fall würde ein Algorithmus diese Werte in einen numerischen Zusammenhang mit den üblichen Werten des Datenattributes bringen, obwohl eine andere Bedeutung vorliegt.
Eine Aufbereitung ist daher sinnvoll. Auch hier sollte beachtet werden, wie die (eigentlich kategorischen) Informationen der „magischen“ Werte erhalten bleiben.
Ausreißer
In den meisten historischen Datensätzen ist es wahrscheinlich, dass Ausreißer in den Daten vorkommen. Bei einer Behandlung dieser Werte ist es, ähnlich wie bei der Behandlung fehlender Werte, nötig, ihre Ursache einzubeziehen. Mögliche Ursachen für Ausreißer sind: Probleme im Produktionsbetrieb, die zu irregulären Werten führen; kürzere Produktionszeiten/kleinere Produktionsmengen, die zu kleineren Werten führen können; Testläufe im Produktionsbetrieb, die ein anderes Verhalten des Betriebszustandes aufweisen; Schwankungen am Sensor, zum Beispiel bedingt durch Ablagerungen, die plötzlich abfallen.
Bei der Behandlung sollte beachtet werden, ob solche Ausnahmesituationen insgesamt aus dem Datensatz entfernt werden, ob die relevanten Werte möglicherweise korrigiert werden können oder ob sie im Datensatz verbleiben können, damit ein Datenanalysemodell die Möglichkeit hat, seltene (aber regulär auftretende) Situationen abzubilden.
Auftreten unmöglicher Werte
Bei der Betrachtung von Datensätzen ist es sehr hilfreich, den Wertebereich zu bestimmen, den die Werte von Datenattributen annehmen können. Zum Beispiel sollten Werte eines Füllstandes eines Gefäßes immer zwischen den Minimalfüllstand (oft Null) und einem Maximalfüllstand liegen. Ein Auftreten von „unmöglichen“ Werten (außerhalb dieses Wertebereichs) ermöglicht eine leichte Identifikation von Ausnahmesituationen in historischen Datensätzen. Diese Situationen müssen gesondert aufbereitet werden (s. auch Ausreißer Behandlung) und deuten nicht selten auf andere zugrundeliegende Probleme der Datenerhebung hin.
Behandlung ähnlicher Werte
Besonders bei manuellen aufgenommenen nominalen Datenattributen (zum Beispiel Beschreibungen in Schichtlogbüchern) kommt es oft vor, dass ähnliche, aber ungleiche Werte für dieselbe Situation verwendet werden. Damit ein Datenanalysemodell diese Werte sinnvoll einbeziehen kann, ist eine Aufbereitung dieser ähnlichen Werte von Vorteil.
Ähnlichkeitsmaße können helfen, unterschiedliche Schreibweisen zu identifizieren und diese Schreibweisen zu einem einzelnen Wert zusammenzufassen.
Datenverständnis
Allen diesen Datenaufbereitungsschritten ist gemein, dass ein Datenverständnis der verschiedenen Datenattribute notwendig ist, um die Aufbereitung durchzuführen. Es ist empfehlenswert, diesen Gedanken auf alle Datenattribute auszuweiten und im Laufe der Evaluierung und Aufbereitung der verschiedenen Datenquellen im Unternehmen ein gemeinschaftliches Datenverständnis aller Datenattribute zu schaffen, das von Anwendenden und Entwickelnden gleichermaßen gepflegt und genutzt wird. Wichtige Aspekte des Datenverständnisses von Datenattributen sind im Folgenden gelistet:
-
Kurze (textuelle) Beschreibung des Datenattributes
-
Wertebereich des Datenattributes
-
Bekanntes Auftreten von fehlenden und/oder „magischen“ Werten und deren Bedeutung
-
Bekannte Zeitbereiche von Ausreißern oder „unmöglichen“ Werten
17.4 Erst die Datenpipeline, dann die Analyse
Welche Möglichkeiten gibt es also, während der eigentlichen Arbeit an einer Analyse den zuvor identifizierten Kernursachen für das Problem „Endstation Prototyp“ (unvollständige Datenpipeline und nicht passende organisatorische Strukturen) entgegenzuwirken?
In diesem Abschnitt werden drei Methoden erläutert, die sich in der Vergangenheit als hilfreich herausgestellt haben:
1.
Live Working Sessions: regelmäßige, gemeinsame Arbeit an der Analyse;
2.
Datenpipeline-Fokus: Anfang und Ende der Analyse sind Anknüpfungspunkte bestehender Unternehmens-IT;
3.
Extraktion wiederverwendbarer Module: Umwandlung von Prozessabschnitten in gekapselte, wiederverwendbare Komponenten mit hinterlegten Testdaten.
17.4.1 Live Working Sessions
Im Anschluss an das erste Treffen bietet es sich an, eine erneute Bewertung der potenziellen Anwendungsfälle durchzuführen. Eine Kosten-Nutzen-Abschätzung von verschiedenen Ansätzen hilft, die besten Kandidaten für die ersten Datenanalyseprojekte auszuwählen, die nachfolgend bearbeitet werden. Hierbei sollte gerade bei ML-Projekten, neben erwarteten Einsparungen/Mehrwerten, auch eine Einschätzung der Datenqualität und -verfügbarkeit mit einbezogen werden.
Da zum Zeitpunkt des Schreibens noch keine Methode bekannt ist, mit der vorab quantifiziert werden kann, wie hoch die Machbarkeit eines ML-Projektes ist, bleibt oft nur eine erfahrungsbasierte Abschätzung sowie die Erstellung erster Prototypen.
Sowohl die Bewertung der Kandidaten an Anwendungsszenarien sowie die Erstellung erster Prototypen als auch die spätere Umsetzung lassen sich gut durch regelmäßige, gemeinsame Arbeitssitzungen vorantreiben. Nach Erfahrung der Autoren bieten sich, neben regelmäßigen Projekt-Update-Meetings, wöchentliche Sitzungen à 90 Minuten an. Anwendende und Entwickelnde arbeiten dabei gemeinsam, beispielsweise über Bildschirmübertragung, an dem Anwendungsfall.
Durch den gewählten Rhythmus haben beide Seiten Zeit, zwischen den Sitzungen tiefergehende Arbeiten durchzuführen, die ggf. keine gemeinsame Aufmerksamkeit benötigten. Während der 90 Minuten der Working Session kann das Projekt dann effektiv vorangebracht werden. Dies kann konkret die Datenanbindung, Begutachtung von Datenvisualisierungen, Besprechung vorhandener Datenpunkte, aber auch andere Aspekte der Datenaufbereitung sowie Analyse, zum Beispiel der Modellbildung, beinhalten.
Durch diese frühzeitige intensive Kooperation können nicht nur gegenseitige Fragen zeitnah geklärt werden, es bauen sich auch bessere soziale Kontakte auf, die sich allgemein positiv auf die Projektarbeit auswirken können. Hinzu kommt ein Upskilling-Effekt, der es der Anwenderseite ermöglicht, Personal im Bereich Datenanalyse stärker zu befähigen, während gleichzeitig auf Seiten des Entwicklungspartners Fehlern durch mangelndes Domänenwissen vorgebeugt wird.
Ein Mitschreiben im gemeinsamen Logbuch während dieser Sitzungen kann zudem helfen, dass Wissen nicht nur persistiert wird, sondern auch, dass das Tempo und die Sprachebene auf ein Level gebracht werden, das für beide Seiten angemessen ist. Ein weiterer positiver Nebeneffekt ist, dass gerade bei längeren Projektlaufzeiten, Personalwechseln oder Ausfällen, die Übergabe der Arbeit vereinfacht wird.
17.4.2 Datenpipeline Fokus
Beim Übergang vom Prototyping in den produktiven Betrieb sind meist viele Anpassungen an einer entwickelten ML-Lösung notwendig. Um diese zu reduzieren, bietet es sich an, verschiedene Faktoren direkt bei der initialen Analyse zu berücksichtigen.
Hauptziel sollte es sein, schnellen Fortschritt beim Aufbau der zukünftigen Datenpipeline zu erzielen. Die einzelnen Verarbeitungsschritte werden zuerst mit einer einfachen Lösung realisiert, um dann zum nächsten Verarbeitungsschritt übergehen zu können. Dadurch wird möglichst früh ein kompletter Durchgang der Pipeline ermöglicht. Der komplette Durchgang umfasst den Abruf der Daten aus dem Unternehmen, die Verarbeitung der Daten bis hin zur Wiedereinspeisung der Analyseergebnisse ins Unternehmen. Dabei liegt das Augenmerk zunächst auf der Beseitigung technischer und konzeptioneller Hindernisse, sodass bei der späteren Ausdetaillierung der Bausteine der Fokus klar auf der Analysequalität liegen kann.
Auch wenn eine einfache Lösung einzelner Analyseschritte angestrebt ist, müssen plausible Annahmen getroffen werden und der Anwendungsfall in einem realistischen Rahmen bearbeitet werden. Dadurch ist auch eine erste Abschätzung der Machbarkeit möglich. Der Fokus liegt zwar auf der zeitnahen Erstellung einer Pipeline, jedoch sollte das nicht auf Kosten der Nachvollziehbarkeit und Wartbarkeit der Pipeline geschehen. Vielmehr sollte der Fokus einen regelmäßigen Abgleich mit dem Hauptziel ermöglichen. Durch das „Rauszoomen“ und die Gesamtbetrachtung der Pipeline soll verdeutlicht werden, welche Aufgaben noch bevorstehen. Es ermöglicht Analysierenden zudem, zu beurteilen, ob die Details an denen gerade gearbeitet wird, wirklich schon zu diesem Zeitpunkt bearbeitet werden müssen oder eine spätere Verfeinerung ausreicht.
Mögliche Hilfsmittel, um auch beim ersten Aufbau einer Datenpipeline einen leichten Übertrag auf ein späteres Produktivsystem zu begünstigen, sind:
-
Testdaten als repräsentativer Auszug aus dem Produktivsystem oder besser: Staging-Datenbank/Toy-Datenbank als Kopie eines Teils der Produktionsdaten: So kann direkt auf späteren Daten gearbeitet werden, ohne zum Beispiel durch zu viele Lese-Abfragen das System zu beeinträchtigen.
-
Nach initialer Feststellung der Nutzbarkeit eines Datensatzes direkt ein Abrufskript erstellen (zum Beispiel Stored Procedures bei SQL-Datenbanken): Es wird mit der Zeit ein Update der Daten benötigt, auch wenn sie nur zur ersten Analyse dienen.
-
Überprüfung der Testdaten auf Variantenvielfalt: Sind alle relevanten Varianten in wichtigen Spalten vorhanden? Welche Ausnahmen gibt es noch und wann sind diese relevant?
-
Nutzung visueller Werkzeuge bei gemeinsamen Diskussionen: Die frühzeitige Visualisierung der Daten und im besten Fall auch der Analysepipeline können zu einem höheren gemeinsamen Verständnis der Problematik beitragen und sogar dazu führen, dass Endanwender selbst Datensätze prüfen und Anpassungen vornehmen.
17.4.3 Extraktion wiederverwendbarer Module
Nachdem die Erstellung der ersten prototypischen Datenpipeline abgeschlossen ist, können einzelne Analyseabschnitte erneut betrachtet und ausgearbeitet werden. Bei diesem Iterationsschritt werden zuvor verkürzte Abschnitte tiefer ausgearbeitet, um die Qualität der Analyse zu erhöhen. Diese Schritte sollten nach Möglichkeit keine Auswirkung mehr auf die erzeugte Datenstruktur der Ergebnisse haben.
Hierbei zeigt die Erfahrung, dass es hilfreich ist, nach Abschluss eines Analyseabschnittes direkt wiederverwendbare Module zu erstellen. Diese Module sollten so gestaltet sein, dass wichtige Parameter klar als solche erkennbar und dokumentiert sind und klare Definitionen für Ein- und Ausgabedatenschemata vorliegen. Weiterhin bietet es sich an, benötigte Datenaufbereitungsschritte direkt als Teil eines Modules zu verbauen. Dies hat verschiedene Vorteile: So können Anforderungen an die benötigte Datenstruktur der Eingabedaten gelockert werden; die Module lassen sich einfacher auf ähnliche Anwendungsfälle übertragen und vor allem können auch Variationen in den Daten besser abgefangen werden, was insbesondere für die Inbetriebnahme hilfreich ist. Es hat sich hierbei als besonders hilfreich herausgestellt, frühzeitig ein Mapping verwendeter Daten zu erstellen, um greifbare Namen für Datenattribute zu verwenden. Oft werden Eingangsdaten aus Datenquellen bezogen, die strikte Vorgaben für zum Beispiel die Länge eines Namens haben (Datenbanken) oder vordefinierte, nicht intuitive Namen aufweisen (OPC-U/A). Bei der gemeinsamen Arbeit an einer Datenpipeline kann frühzeitig eine passende Umbenennung stattfinden, sodass eindeutigere Namen für einzelne Analyseabschnitte gewählt werden. Im Anschluss an einen Analyseabschnitt kann dieses Mapping dann wieder rückgängig gemacht werden, um beim Zurückspielen der Daten in Produktivsysteme Unklarheiten vorzubeugen. Teil dieses Mappings kann und sollte auch eine Anpassung auf einheitliche Maßeinheiten sein.
In welchem Maß Analyseabschnitte zu Modulen herausgearbeitet werden sollten, stellt sich meist bei der Zusammenführung der ersten Datenpipeline heraus und lässt sich ansonsten neben einer Aufteilung nach thematischem Fokus auch über Änderungen an der Datenstruktur (Aggregationen, Zusammenführung verschiedener Datensätze, Kompatibilitätsanpassungen) erfassen.
17.5 Zusammenfassung
Bei der Durchführung von Projekten im unternehmerischen Kontext gibt es oft eine Vielzahl unterschiedlicher Datenquellen und Formate, deren Aufbereitung und Zusammenführung enorme Mehrwerte generieren können. Zusätzlich bieten sie auch viel Potenzial für die Neuentwicklung von Werkzeugen und Klärung von Forschungsfragen. Gerade diese Ausgangslage führt zu einem erhöhten Aufwand bei der Datenhandhabung. Zusätzlich spielen nicht technische Aspekte eine wichtige Rolle bei der Bearbeitung und Analyse dieser Daten. Zuständigkeiten, abteilungsübergreifende Kollaboration und komplexe IT-Systemlandschaften mögen bei der ersten Durchführung von Projekten einschüchternd wirken, jedoch kann diesen Aspekten mit verschiedensten Methoden begegnet werden. Durch erste Projekte kann eine erfolgreiche Grundlage für weitere Zusammenarbeiten über diese Projekte hinausgelegt werden.
Insbesondere frühzeitige Einbindung von Vertreterinnen und Vertretern aller betroffenen Abteilungen und eine fokussierte erste komplette Datenpipeline sind wichtige Grundsteine für eine erfolgreiche Zusammenarbeit. Im Rahmen erster Treffen sollte mit einem Gesamtbild begonnen werden. Die Anforderungen für einen möglichen Einsatz maschineller Lernverfahren und insbesondere die Notwendigkeit Modelle bei Prozessänderungen neu trainieren zu müssen sollten klar kommuniziert werden. Solch ein Austausch mit allen Vorantreibern und insbesondere mit den Endnutzenden sollte stetig erfolgen, um Bedenken vorzubeugen und realistische Erwartungen aller Beteiligten sicher zu stellen. Ein Datenverständnis sollte in Zusammenarbeit zwischen Anwendenden und Entwickelnden geschaffen werden, um häufig auftretende Herausforderungen der Datenqualität die bei der Integration, Zusammenführung und Aufbereitung der Datenquellen entstehen zu meistern. All dies erleichtert das Erwartungsmanagement und führt zu einer produktiveren Zusammenarbeit zwischen beteiligten Partnerinnen und Partnern. Mit realistischen Erwartungen und soliden Vorarbeiten für die Wiederverwendung von Teilanalyseschritten existiert so am Projektende eine gute Ausgangssituation für eine Inbetriebnahme im Unternehmen und die weitere Nutzung entwickelter Methoden und Werkzeuge über das Projekt hinaus.
Danksagung
Die Autoren bedanken sich für die Förderung der Projekte DaPro (Förderkennzeichen: 01MT19004D) und IIP-Ecosphere (Förderkennzeichen: 01MK20006A-Q) durch das Bundesministerium für Wirtschaft und Klimaschutz im Rahmen der Förderprogramme Smarte Datenwirtschaft und KI-Innovationswettbewerb.
Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung 4.0 International Lizenz (http://creativecommons.org/licenses/by/4.0/deed.de) veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden.
Die in diesem Kapitel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.