Data Lake in der Fertigung: vom Datensumpf zur Governance

2030 fragt jemand nach einem Vorgang aus 2008. Klickt eine Sachbearbeiterin dann auf einen belegten Datensatz, oder muss erst ein längst abgeschaltetes Altsystem wieder hochgefahren werden? An dieser Frage entscheidet sich, ob Ihre Daten ein Vermögen oder eine Altlast sind.

Viele Betriebe setzen auf einen Data Lake, um alle Daten an einem Ort zu sammeln. Doch ohne Governance wird aus dem Datensee ein Datensumpf: voll mit Daten, die verändert, überschrieben oder gelöscht sein könnten, ohne dass es jemand belegen kann.

Dieser Beitrag zeigt, wann ein Data Lake kippt, warum Vertrauenswürdigkeit in der Fertigung geschäftskritisch ist und wie revisionssichere Archivierung aus einem Datensumpf eine belegbare Datenbasis macht.

Was ist ein Data Lake?

Ein Data Lake ist ein zentraler Speicher, der große Mengen an Daten aus unterschiedlichen Quellen in ihrem Rohformat aufnimmt, ohne dass vorab ein festes Schema definiert werden muss. Anders als ein Data Warehouse, das Daten beim Einlesen strukturiert und standardisiert, folgt der Data Lake dem Prinzip Schema-on-Read: Die Struktur wird erst beim Auslesen festgelegt, nicht beim Speichern.

Dieser Ansatz hat einen klaren Reiz. Ein solcher Datensee nimmt alles auf, von Maschinendaten über Prüfergebnisse bis zu Bildern und Protokollen, ohne dass man sich vorher festlegen muss, wie die Daten später genutzt werden. Für Big-Data-Analysen und maschinelles Lernen ist diese Flexibilität wertvoll, weil sich Auswertungen ergeben können, die beim Sammeln noch niemand geplant hatte.

In der Fertigung wächst die Datenlandschaft ohnehin schneller als die Kontrolle darüber: Prozessdaten liegen im MES, Prüfergebnisse in Tabellen, Werkzeugprotokolle im Altsystem. Der Datensee verspricht, all das an einem Ort zusammenzuführen. Doch genau hier beginnt das Problem, das viele erst spät bemerken. Wie eine belastbare Datengrundlage in der Fertigung stattdessen aufgebaut wird, behandelt unser Beitrag zum Prozessdatenmanagement in der Fertigung.

Wann wird aus dem Data Lake ein Datensumpf?

Ein Data Lake kippt zum Datensumpf, sobald Daten hineinfließen, ohne dass Herkunft, Qualität und Unveränderbarkeit geregelt sind. Der englische Fachbegriff dafür ist Data Swamp, und er beschreibt genau das Bild: ein trüber Speicher, in dem zwar alles liegt, aber niemand mehr sagen kann, welche Daten stimmen und welche nicht.

Das Kernproblem ist nicht die Datenmenge. Es ist die fehlende Vertrauenswürdigkeit. In einem ungoverneten Datensee können Datensätze überschrieben, dupliziert, unbemerkt verändert oder gelöscht worden sein. Wenn später jemand eine Auswertung fährt, arbeitet er möglicherweise mit Daten, die nicht mehr dem entsprechen, was tatsächlich passiert ist. Der Speicher ist voll, aber sein Inhalt ist nicht belastbar.

Für explorative Analysen mag das tolerierbar sein. Sobald Daten aber als Nachweis dienen sollen, wird es kritisch. Ein Auditor fragt nicht, ob ein Wert irgendwo gespeichert ist, sondern ob er seit seiner Entstehung unverändert geblieben ist und wer wann darauf zugegriffen hat. Diese Frage kann ein reiner Datensee nicht beantworten. Warum man sich auf eine laufende Datenbank allein nicht verlassen sollte, vertiefen wir in unserem Beitrag darüber, warum wir einer Datenbank lieber nicht blind vertrauen.

Ein voller Datenspeicher ist kein Beweis. Entscheidend ist nicht, ob die Daten da sind, sondern ob man belegen kann, dass sie seit ihrer Entstehung unverändert geblieben sind.

Warum ist Vertrauenswürdigkeit in der Fertigung geschäftskritisch?

In vielen Branchen ist ein unzuverlässiger Datensee ärgerlich. In der Fertigung ist er ein Haftungsrisiko. Der Grund liegt in den besonderen Nachweispflichten, die produzierende Unternehmen erfüllen müssen.

Rückverfolgbarkeit ist die erste Anforderung. Zulieferer müssen belegen können, welches Teil mit welchen Prozesswerten in welchem Produkt verbaut wurde. Diese Nachweiskette ist nur so viel wert wie die Unveränderbarkeit der zugrunde liegenden Daten. Wie eine solche Kette aufgebaut wird, behandelt unser Beitrag zur Rückverfolgbarkeit in der Produktion.

Die zweite Anforderung sind gesetzliche Aufbewahrungspflichten. Laut CSP Whitepaper zur Data Governance reichen gesetzliche Aufbewahrungsfristen bis zu 50 Jahre, und über diesen gesamten Zeitraum müssen Daten auffindbar, lesbar und belegbar bleiben. Ein Data Lake, dessen Formate und Inhalte sich über die Jahre verändern, kann das nicht garantieren.

Die dritte Anforderung ist die Auditfähigkeit. Normen wie IATF 16949 in der Automobilindustrie oder die GoBD im steuerlichen Kontext verlangen den belastbaren Nachweis, dass Prozesse beherrscht und Daten ordnungsgemäß behandelt wurden. Wer diesen Nachweis erst im Prüfungsfall aus einem Datensumpf zusammensuchen muss, hat die Pflicht faktisch nicht erfüllt.

Die drei Pflichten strukturierter Daten: aufbewahren, löschen, beweisen

Das CSP Whitepaper zur Data Governance bringt den Kern des Problems auf eine Formel: Strukturierte Daten unterliegen gleichzeitig drei Pflichten, die am selben Datenbestand hängen und sich nur gemeinsam erfüllen lassen.

Aufbewahren. Handelsrecht, Steuerrecht, Branchenrecht und Produkthaftung schreiben Fristen von 6 bis 50 Jahren vor. Laut Whitepaper gilt diese Frist für den Inhalt, nicht für die Anwendung, in der er entstanden ist. Ein Altsystem am Leben zu halten, nur um an seine Daten zu kommen, ist deshalb keine Lösung, sondern ein Kostentreiber.

Löschen. Die DSGVO verlangt nach Art. 5 und Art. 17, dass personenbezogene Daten nicht länger vorgehalten werden als nötig und auf Verlangen gelöscht werden. Das ist kein Widerspruch zur Aufbewahrung, sondern laut Whitepaper eine gleichrangige Pflicht mit anderer Richtung.

Beweisen. Beide Pflichten sind wertlos, wenn ihre Erfüllung nicht belegbar ist. Ein Auditor fragt nicht nur, ob gelöscht oder aufbewahrt wurde, sondern wann, durch wen und ob der Datensatz zwischenzeitlich verändert wurde. Genau diese Belegbarkeit ist der Punkt, an dem ein ungoverneter Data Lake scheitert.

Das Whitepaper ordnet diesen drei Pflichten auch die typische Zuständigkeit zu: Aufbewahren liegt bislang bei der IT über Backup und Storage, Löschen beim Datenschutz über Konzepte und Listen, Beweisen bei der Revision über nachträgliche Rekonstruktion. Solange das drei getrennte Vorgänge mit drei Werkzeugen sind, wird jede Prüfung zum Projekt. Data Governance für strukturierte Daten führt sie an einem Datenbestand zusammen.

Data Lake versus revisionssichere Archivierung

Der Unterschied zwischen einem Data Lake und einer revisionssicheren Archivierung ist kein gradueller, sondern ein grundsätzlicher. Er entscheidet darüber, ob Daten nur vorhanden oder auch belegbar sind.

Ein Datensee ist auf Veränderbarkeit ausgelegt. Daten fließen hinein, werden angereichert, umgeschrieben, wieder entnommen. Das ist für Analysen gewollt, macht die Daten aber als Nachweis untauglich, weil ihre Unverändertheit nicht garantiert ist.

Eine revisionssichere Archivierung dreht dieses Prinzip um. Sie legt Daten unveränderbar ab, in einem offenen, langzeitsicheren Format, und protokolliert jeden Zugriff. Damit erfüllt sie die Beweispflicht, an der ein Data Lake scheitert. Welche Kriterien eine solche Lösung erfüllen muss, behandelt unser Beitrag darüber, wie man revisionssichere Archivierungssoftware richtig auswählt.

Wichtig ist die Abgrenzung zum Backup, die oft verwechselt wird. Ein Backup sichert gegen Datenverlust, ist aber überschreibbar und nicht auf Unveränderbarkeit ausgelegt. Warum Backup und Archivierung zwei verschiedene Dinge sind, erklären wir in einem eigenen Beitrag.

Wie schaffen Sie vertrauenswürdige, belegbare Daten?

Der Weg aus dem Datensumpf führt nicht über mehr Speicher, sondern über Governance für strukturierte Daten. Vier Prinzipien sind dabei entscheidend.

Unveränderbarkeit sicherstellen. Daten, die als Nachweis dienen, müssen so abgelegt werden, dass nachträgliche Änderungen ausgeschlossen oder zumindest lückenlos protokolliert sind. Ohne diese Eigenschaft ist kein Datenbestand auditfähig.

Offenes, langzeitsicheres Format wählen. Aufbewahrungsfristen von Jahrzehnten bedeuten, dass Daten auch dann noch lesbar sein müssen, wenn das ursprüngliche System längst abgeschaltet ist. Proprietäre Formate, die an eine Anwendung gebunden sind, sind hier ein Risiko. Der OAIS-Standard für Langzeitarchivierung adressiert genau das.

Aufbewahren, löschen und beweisen zusammenführen. Solange die drei Pflichten in drei getrennten Werkzeugen bearbeitet werden, bleibt jede Prüfung ein Projekt. Eine Governance, die alle drei an einem Datenbestand abbildet, macht den Nachweis zum Normalfall statt zur Rechercheaufgabe.

Altsysteme ablösen statt weiterbetreiben. Ein Fachverfahren nur als Datenbehälter am Leben zu halten, bindet Lizenz, Wartung und Spezialwissen. Wird der Datenbestand revisionssicher archiviert, lässt sich das Altsystem abschalten. Wie das gelingt, behandelt unser Beitrag zum Ablösen von Legacy-Systemen.

Was kostet ein ungoverneter Datenbestand?

Ein Datensumpf ist nicht nur ein Qualitätsproblem, sondern ein handfester Kostenfaktor. 

Rund 70 Prozent der Daten in produktiven Datenbanken historische Bestände, die operativ nicht mehr gebraucht, aber weiter mitbezahlt werden. Wenn fünf bis zehn Altsysteme nur noch als Datenbehälter weiterlaufen, summieren sich die jährlichen Kosten laut Whitepaper in den siebenstelligen Bereich.

Hinzu kommt der unsichtbare Kostenblock auf der Compliance-Seite. Kommt eine Aufsichtsanfrage, beginnt laut Whitepaper die Suche in Altsystemen, Exporten und Tabellen, eine Rechercheaufgabe von Tagen bis Wochen. Was auf dem Papier eine erfüllte Aufbewahrungspflicht war, wird so im Ernstfall zum teuren Projekt. Genau hier setzt der Business Case einer revisionssicheren Archivierung an: Sie senkt die laufenden Kosten und macht den Nachweis zugleich zur Sache weniger Klicks.

Häufig gestellte Fragen

Was ist ein Data Lake?

Ein Data Lake ist ein zentraler Speicher, der Daten aus unterschiedlichen Quellen in ihrem Rohformat aufnimmt, ohne dass vorab ein festes Schema definiert werden muss. Die Struktur wird erst beim Auslesen festgelegt. Das macht ihn sehr flexibel für Big-Data-Analysen, aber ohne Governance auch anfällig für Qualitäts- und Vertrauensprobleme.

Worin unterscheidet sich ein Data Lake von einem Data Warehouse?

Ein Data Warehouse strukturiert und standardisiert Daten bereits beim Einlesen und eignet sich für feste Auswertungen und Reporting. Ein Data Lake speichert Daten roh und legt die Struktur erst beim Lesen fest. Der Data Lake ist flexibler, das Data Warehouse konsistenter und nachvollziehbarer.

Wann wird ein Data Lake zum Datensumpf?

Ein Data Lake wird zum Datensumpf, sobald Daten ohne Regeln zu Herkunft, Qualität und Unveränderbarkeit hineinfließen. Dann liegt zwar alles gespeichert vor, aber niemand kann mehr sagen, welche Daten korrekt und unverändert sind. Der Speicher ist voll, sein Inhalt aber nicht mehr belastbar.

Warum sind Daten in einem Data Lake oft nicht vertrauenswürdig?

Weil in einem ungoverneten Data Lake Datensätze überschrieben, dupliziert, verändert oder gelöscht werden können, ohne dass es nachvollziehbar ist. Für explorative Analysen ist das tolerierbar, als Nachweis für Audits oder Haftungsfragen jedoch untauglich, weil die Unverändertheit der Daten nicht belegbar ist.

Was unterscheidet einen Data Lake von einer revisionssicheren Archivierung?

Ein Data Lake ist auf Veränderbarkeit ausgelegt, eine revisionssichere Archivierung auf Unveränderbarkeit. Die Archivierung legt Daten in einem offenen, langzeitsicheren Format unveränderbar ab und protokolliert jeden Zugriff. Damit erfüllt sie die Beweispflicht, an der ein Data Lake scheitert.

Was bedeutet GoBD- und OAIS-konforme Archivierung?

Die GoBD sind die deutschen Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern und Aufzeichnungen in elektronischer Form. OAIS ist ein internationaler Standard für die Langzeitarchivierung. Eine Archivierung, die beiden entspricht, gewährleistet, dass Daten unveränderbar, nachvollziehbar und über lange Fristen lesbar bleiben.

Wie stellt man die Belegbarkeit von Produktionsdaten sicher?

Indem Daten unveränderbar in einem offenen Format abgelegt, jeder Zugriff protokolliert und die Pflichten aufbewahren, löschen und beweisen an einem Datenbestand zusammengeführt werden. Eine revisionssichere Archivierung auf Datenbankebene, wie sie CHRONOS im CSP Manufacturing OS leistet, erfüllt diese Anforderungen.

Kann man ein Altsystem abschalten, dessen Daten aufbewahrungspflichtig sind?

Ja, indem der Datenbestand des Altsystems revisionssicher archiviert wird. Die Aufbewahrungspflicht gilt für den Inhalt, nicht für die Anwendung. Ist der Inhalt unveränderbar und lesbar archiviert, lässt sich das Altsystem abschalten, was Lizenz-, Wartungs- und Betriebskosten spart.