Unternehmensdaten – Informationen aus gewachsenen, komplexen Systemen herausarbeiten – Teil 2

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:

• 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.
• 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 der Arbeitsgruppe IT-Sicherheit, Privacy, Recht und Ethik der Plattform Lernende Systeme sowie „Towards Reflective AI: Needs, Challenges and Directions for Future Research“.

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.

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

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:

• Live Working Sessions: regelmäßige, gemeinsame Arbeit an der Analyse;
• Datenpipeline-Fokus: Anfang und Ende der Analyse sind Anknüpfungspunkte bestehender Unternehmens-IT;
• Extraktion wiederverwendbarer Module: Umwandlung von Prozessabschnitten in gekapselte, wiederverwendbare Komponenten mit hinterlegten Testdaten.

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.

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.

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.

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.

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

Zur einfacheren Lesbarkeit wurden die Quellen- und Literaturverweise entfernt.