Integrationsschicht statt Data Lake: warum das große Datenprojekt selten liefert
Kaum eine Idee hat im Mittelstand so viel Budget gebunden und so wenig geliefert wie der Data Lake. Die Logik klingt zwingend: Erst alle Daten an einen Ort, dann kann man alles damit machen. In der Praxis ist der erste Teil ein Zweijahresprojekt, und der zweite Teil beginnt nie.
Data-Lake-Projekte scheitern an der Reihenfolge: Sie sammeln Daten, bevor jemand die Frage kennt, und liefern erst nach Monaten einen Zwischenstand — oder gar keinen. Eine Integrationsschicht beginnt bei der Frage, erschließt die drei bis vier Quellen, die sie beantworten, und liefert nach zwei Wochen echte Antworten. Ein zentraler Datenbestand bleibt für Langzeitanalysen und Aufbewahrung sinnvoll, ist aber kein Vorprojekt.
Woran das große Datenprojekt scheitert
An der Reihenfolge. Ein Data Lake beginnt mit der Frage, welche Daten man einsammelt, ohne dass jemand weiß, welche Frage beantwortet werden soll. Also sammelt man alles. Alles zu sammeln bedeutet, für jede Quelle Struktur, Historie, Rechte und Pflege zu klären. Nach achtzehn Monaten steht ein technisch beeindruckender Datenbestand, den niemand benutzt, weil die Fachbereiche inzwischen andere Probleme haben.
Was die Integrationsschicht anders macht
Sie beginnt bei der Frage, nicht bei den Daten. Für „Haben wir so eine Maschine schon gebaut?" braucht man Projektakten, Stücklisten und Zeichnungen — drei Quellen, nicht dreißig. Diese drei erschließt man in Tagen. Der Inhalt bleibt, wo er ist, es entsteht ein Index mit Verweisen statt einer Kopie, die gepflegt werden muss.
Der entscheidende Unterschied ist die Verwertbarkeit unterwegs: Nach zwei Wochen beantwortet das System echte Fragen. Beim Data Lake gibt es diesen Zwischenstand nicht — er ist entweder fertig oder nutzlos.
Wann ein zentraler Datenbestand doch richtig ist
- Wenn Sie über Jahre hinweg auf großen Mengen rechnen wollen, etwa für Prognosen über die gesamte Historie.
- Wenn Quellsysteme abgelöst werden und die Historie erhalten bleiben muss.
- Wenn regulatorische Aufbewahrung eine unveränderliche Ablage verlangt.
In allen drei Fällen gilt: Das ist ein eigenes Vorhaben mit eigenem Nutzen, nicht die Voraussetzung dafür, dass Ihre Leute Antworten bekommen. Diese Verwechslung kostet die meiste Zeit.
Häufige Fragen
Brauchen wir einen Data Lake, bevor wir KI einsetzen können?
Nein, und diese Annahme ist einer der teuersten Irrtümer in KI-Projekten. Moderne Systeme lesen Quellen dort, wo sie liegen. Ein zentraler Datenbestand kann für Langzeitanalysen sinnvoll sein, ist aber kein Vorprojekt und verschiebt den Nutzen nur um Quartale nach hinten.
Was ist der Unterschied zwischen Index und Kopie?
Eine Kopie ist ein zweiter Datenbestand, der veraltet und gepflegt werden muss. Ein Index enthält Verweise und Metadaten: wo etwas steht, wie es zusammenhängt, wer es sehen darf. Der Inhalt bleibt im Quellsystem führend, Änderungen dort schlagen durch, und bei Vertragsende lässt sich der Index nachweisbar löschen.
Wie viele Quellen braucht ein sinnvoller Start?
Zwei bis vier, ausgewählt nach dem konkreten Anwendungsfall. Für Servicefragen sind das Tickethistorie, Handbücher und Serviceordner; für Angebote Angebotsarchiv, ERP-Auszüge und Projektpostfächer. Mehr Quellen erhöhen den Klärungsaufwand schneller als den Nutzen.
Was, wenn unsere Datenqualität schlecht ist?
Dann ist sie in einem Data Lake genauso schlecht, nur teurer. Für den Einstieg zählt vor allem eines: verlässliche gemeinsame Schlüssel wie Auftrags- und Chargennummern. Inhaltliche Lücken werden im Betrieb sichtbar und gezielt behoben — das ist wirksamer als eine Datenbereinigung auf Vorrat, die niemand priorisieren kann.
Welche Frage soll Ihr System beantworten?
Im Raum wählen Sie Engpass und Quellen und sehen den Fahrplan.
Raum betreten →
