Ein mittelständischer deutscher Automobilzulieferer wollte vor zwei Jahren seine Lieferketten mit modernster Big-Data-Software optimieren. Der Vorstand hatte Berichte über die enorme Leistungsfähigkeit von Palantir gelesen und beschloss, die Plattform Foundry einzuführen. Man stellte ein Budget von zwei Millionen Euro bereit und beauftragte eine klassische IT-Beratung mit der Umsetzung. Nach achtzehn Monaten war das Budget aufgebraucht, aber kein einziger Prozess lief stabiler als vorher. Die Daten lagen weiterhin in isolierten Silos, die Mitarbeiter verweigerten die Nutzung der neuen Dashboards und das Projekt wurde schließlich stillschweigend beerdigt. Solche Desaster passieren, weil Entscheider die Philosophie hinter den Systemen missverstehen, die von Alex Karp geprägt wurden. Sie behandeln hochkomplexe, ontologiebasierte Datenplattformen wie gewöhnliche Business-Intelligence-Werkzeuge aus dem Katalog.
Ich habe dieses Szenario in den vergangenen Jahren bei DAX-Konzernen und Behörden gleichermaßen erlebt. Der Fehler liegt fast nie an der Software selbst, sondern an der fundamental falschen Herangehensweise der Unternehmen. Wer glaubt, man könne eine solche Plattform einkaufen, über die bestehende Infrastruktur stülpen und auf Knopfdruck Wunder erwarten, hat das Prinzip nicht verstanden. Es geht hier nicht um schicke Diagramme für den Quartalsbericht. Es geht um eine radikale Umgestaltung der Art und Weise, wie eine Organisation mit Informationen umgeht.
Der Irrglaube an die schlüsselfertige Wunderwaffe
Der größte Fehler besteht in der Annahme, man kaufe ein fertiges Produkt, das nach der Installation von selbst Probleme löst. Große Softwarehäuser verkaufen oft die Vision einer perfekt integrierten Datenwelt. In der Praxis erfordert die Software, die eng mit dem Namen Alex Karp verbunden ist, eine tiefgreifende, fortlaufende Arbeit an der eigenen Datenstruktur.
Wenn die internen Datenbestände im Quellsystem bereits fehlerhaft, unvollständig oder inkonsistent sind, spiegelt die neue Plattform diesen Zustand lediglich auf einer teureren Benutzeroberfläche wider. Unternehmen versäumen es systematisch, vor dem Start des Projekts die eigenen Hausaufgaben zu machen. Sie investieren Millionen in Lizenzen, bevor überhaupt klar ist, welche operativen Kernfragen die Software beantworten soll. Das Ergebnis ist ein extrem teurer Datengrabwald, der von der Belegschaft ignoriert wird.
Datenintegration ohne klare Ontologie ist wertlos
Viele IT-Abteilungen machen den Fehler, Daten einfach nur in einen zentralen Topf zu werfen. Sie bauen den nächsten Data Lake und wundern sich, warum die operativen Abteilungen damit nichts anfangen können. Eine erfolgreiche Implementierung steht und fällt mit der Definition einer semantischen Schicht, der sogenannten Ontologie.
Hierbei werden reale Objekte des Geschäftsbetriebs – wie Maschinen, Verträge, Bauteile oder Lieferanten – und deren Beziehungen untereinander digital abgebildet. Das unterscheidet diesen Ansatz fundamental von klassischen relationalen Datenbanken. Wer diese Modellierung den IT-Generalisten überlässt, ohne die Experten aus den Fachabteilungen einzubinden, baut am Bedarf vorbei. Die Modellierung muss die Sprache des Geschäfts sprechen, nicht die Sprache der Datenbank administratoren.
Warum Ingenieure und Analysten aneinander vorbeireden
Ein konkretes Problem aus der Praxis verdeutlicht das. Die IT-Abteilung definiert das Objekt „Bauteil“ über rein technische Parameter wie die Materialnummer. Der Einkäufer im operativen Geschäft benötigt jedoch Verknüpfungen zu Lieferzeiten, geopolitischen Risiken der Herkunftsländer und historischen Preisentwicklungen. Wenn diese Welten bei der Erstellung der Ontologie nicht zusammengeführt werden, bleibt das System für den Einkauf nutzlos. Der Prozess der Datenmodellierung ist kein technisches Projekt, sondern eine organisatorische Mammutaufgabe.
Die Fehleinschätzung des Betriebskonzepts und der Folgekosten
Unternehmen kalkulieren die laufenden Kosten für den Betrieb solcher Plattformen regelmäßig falsch. Die Lizenzgebühren sind nur die Spitze des Eisbergs. Was wirklich ins Geld geht, ist das Personal, das für den Betrieb und die kontinuierliche Weiterentwicklung benötigt wird.
- Es werden Spezialisten benötigt, die sowohl tiefes technisches Verständnis für Datenpipelines als auch ein ausgeprägtes Gespür für die Geschäftsprozesse besitzen.
- Diese Fachkräfte, oft als Forward Deployed Engineers bezeichnet, sind auf dem Markt extrem rar und teuer.
- Wer glaubt, die bestehende IT-Mannschaft könne diese Plattformen quasi nebenbei mitbetreuen, steuert sehenden Auges auf den Projektabbruch zu.
Wenn man diese Ressourcen nicht dauerhaft einplant, veraltet die Datenstruktur innerhalb weniger Monate, da sich die realen Geschäftsprozesse ständig verändern.
Vorher und Nachher: Ein praktischer Vergleich im Controlling
Um den Unterschied zwischen dem falschen und dem richtigen Ansatz zu verdeutlichen, hilft der Blick auf die Abläufe im Risikomanagement eines Logistikunternehmens.
Der falsche Ansatz (Vorher): Das Unternehmen versucht, Logistikrisiken über herkömmliche Dashboards zu überwachen. Ein Analyst stellt fest, dass ein Zulieferer in Asien Lieferverzögerungen meldet. Um die Auswirkungen zu verstehen, muss der Analyst manuell Excel-Listen aus dem ERP-System exportieren, diese mit den aktuellen Produktionsplänen abgleichen und die Ergebnisse per E-Mail an die Produktionsleitung schicken. Bis dieser Prozess abgeschlossen ist, vergehen drei Tage. Die Produktionslinie steht bereits still, bevor der Bericht gelesen wird. Das System war in diesem Fall nur ein passiver Datenspeicher.
Der richtige Ansatz (Nachher): Bei einer korrekten Implementierung, die sich an der Philosophie von Alex Karp orientiert, ist die Lieferkette als lebendige Ontologie abgebildet. Sobald die Verzögerung des Zulieferers im System registriert wird, verknüpft die Plattform diese Information automatisch mit den betroffenen Produktionsaufträgen, den Lagerbeständen alternativer Lieferanten und den betroffenen Kundenbestellungen. Das System schlägt dem Disponenten sofort drei konkrete Handlungsoptionen vor, inklusive der Berechnung der jeweiligen finanziellen Konsequenzen. Der gesamte Vorgang dauert Sekunden statt Tage. Der Mensch trifft die Entscheidung, aber die Plattform liefert den Kontext.
Der Trugschluss, dass Software die Unternehmenskultur ersetzt
Ein schmerzhafter Reibungspunkt in deutschen Unternehmen ist die ausgeprägte Silomentualität. Abteilungen hüten ihre Daten wie Staatsgeheimnisse. Vertrieb, Produktion und Finanzen arbeiten oft mit eigenen Wahrheiten. Eine Plattform dieser Größenordnung funktioniert aber nur dann, wenn alle Daten radikal geteilt und zusammengeführt werden.
Das scheitert selten an der Technik, sondern fast immer an internen Machtkämpfen und dem Widerstand des mittleren Managements. Wenn die Führungsebene diesen Kulturwandel nicht aktiv vorlebt und gegen Widerstände durchsetzt, bleibt die Software ein isoliertes Werkzeug für ein paar Spezialisten. Das Werkzeug kann Datensilos technisch aufbrechen, aber die organisatorischen Blockaden in den Köpfen der Mitarbeiter muss die Geschäftsführung lösen.
Der Realitätscheck für Ihr Datenprojekt
Wenn Sie im Begriff sind, ein Projekt in dieser Größenordnung zu starten, müssen Sie sich den harten Fakten stellen. Es gibt keine Abkürzung zur datengetriebenen Organisation. Wenn Ihre Datenbasis im Unternehmen aktuell einem unstrukturierten Trümmerfeld gleicht, wird eine neue Plattform dieses Trümmerfeld nur schneller sichtbar machen.
Erfolgt die Einführung nicht mit dem klaren Fokus auf ein konkretes, geschäftskritisches Problem, werden Sie scheitern. Fangen Sie nicht mit der Vision an, das gesamte Unternehmen an einem Tag zu transformieren. Wählen Sie einen einzelnen, messbaren Prozess – zum Beispiel die Reduzierung von Ausschuss in einer bestimmten Produktionslinie oder die Optimierung des Working Capitals in einem spezifischen Lager. Erst wenn dieser Prozess stabil auf der neuen Plattform läuft und echten finanziellen Mehrwert generiert, sollten Sie das System schrittweise ausrollen. Alles andere ist Geldverbrennung auf hohem Niveau.
