Data Readiness beginnt damit, den Fileshare einzufrieren

Eine Frage kommt bei uns in Gesprächen über Data Readiness immer wieder: „Wie sieht so eine Data-Readiness-Reise eigentlich aus? Zeigen Sie uns doch mal den Ablauf.“ Ich habe darauf lange keine gute Antwort gegeben. Eine Antwort hatte ich schon, aber sie ist eben keine Reiseroute. Wir schauen uns Daten pro Anwendungsfall an. Denn es gibt keinen Standardweg vom Fileshare ins gelobte KI-Land.

Häufig läuft parallel zur KI-Einführung noch ein zweites großes Projekt: ein neues Intranet, eine neue Wissensplattform. Das halte ich für den zweiten Denkfehler. Dazu erscheint hier nächste Woche ein eigener Artikel. Hier geht es um den Altbestand, also um das, was ohnehin schon da ist.

Dieser Artikel ist meine ausführliche Antwort auf die Frage nach dem Ablauf. Er wird unbequem, das kündige ich vorher an. Aber ich glaube, genau diese Unbequemlichkeit brauchen viele Unternehmen gerade.

‍

KI einführen und auf Fileshares von 1998 sitzen

Fast jedes Unternehmen, mit dem ich spreche, hat denselben Zustand: Es gibt einen gewachsenen Fileshare, oft mehrere. Ordnerstrukturen, die irgendwann mal jemand angelegt hat, der längst nicht mehr im Unternehmen ist. Projektordner von 2009 neben Projektordnern von 2024. Dateinamen wie „Angebot_final_v3_NEU_final2.docx“. Und jetzt kommt KI ins Haus, Copilot wird ausgerollt, und plötzlich steht die Frage im Raum: Was machen wir mit all dem?

Fast immer lautet die reflexhafte Antwort: migrieren. Alles nach Microsoft 365, in SharePoint-Bibliotheken, sauber verschlagwortet, damit die KI darauf zugreifen kann. Das klingt zunächst vernünftig. Es ist trotzdem der teuerste Fehler, den du in deinem KI-Projekt machen kannst.

‍

Was auf typischen Fileshares wirklich liegt

Für den Inhalt alter Fileshares hat die Branche einen eigenen Begriff: ROT-Data. Redundant, Obsolete, Trivial. Doppelte Dateien, veraltete Versionen, temporäre Ablagen, die nie aufgeräumt wurden, private Urlaubsfotos im Teamordner. 2016 kam die Veritas-Databerg-Studie zu dem Ergebnis, dass 52 Prozent der gespeicherten Daten in Unternehmen „dark“ sind, also niemand ihren Wert kennt, und weitere 33 Prozent in die ROT-Kategorie fallen [1].

‍

‍

Meine Erfahrung aus Projekten im Mittelstand deckt sich damit weitgehend. Wenn wir mit Kunden konkret in einen Anwendungsfall einsteigen, brauchen wir am Ende einen Bruchteil dessen, was auf dem Fileshare liegt. Der Rest ist Ballast. Und dieser Ballast ist nicht neutral, er schadet aktiv.

‍

Warum der Großteil davon die Antworten verschlechtert

„Daten sind das neue Öl“ hat sich als Metapher festgesetzt, und sie führt hier komplett in die Irre. Öl wird wertvoller, je mehr man davon hat. Alte Unternehmensdaten nicht. Eine KI, die auf einem ungefilterten Fileshare arbeitet, findet zu jeder Frage mehrere Antworten: die aktuelle Preisliste und die von 2019, der gültige Prozess und seine drei Vorgängerversionen, das unterschriebene Angebot und den verworfenen Entwurf.

Stephen Rose, der 15 Jahre bei Microsoft die IT-Pro-Readiness für OneDrive, Teams und Copilot verantwortet hat, beschreibt genau dieses Problem: Wenn Copilot fünf oder zehn Versionen derselben Datei über OneDrives, SharePoint und E-Mail-Anhänge hinweg vorfindet, wie treffsicher soll es dann entscheiden, welche für die Antwort zählt? Garbage in, garbage out [2]. Das Ergebnis sind Antworten, die plausibel klingen und falsch sind. Verantwortlich dafür ist allein das widersprüchliche Material, das du ihr gegeben hast.

Und das kostet Antwortqualität und echte Projekte, denn Gartner rechnet damit, dass Unternehmen bis Ende 2026 60 Prozent der KI-Projekte aufgeben, die nicht auf KI-taugliche Daten gestützt sind [3]. Die meisten davon scheitern daran, dass niemand vorher entschieden hat, welche Daten überhaupt in die KI gehören.

‍

Der erste Denkfehler beim Altbestand

Die Vollmigration ist eine Falle

Rechnen wir also kurz nach, was eine Vollmigration bedeutet. Du bezahlst dafür, Terabytes zu bewegen, von denen der Großteil ROT ist. Du bezahlst dafür, Berechtigungen zu übertragen, die historisch gewachsen und längst nicht mehr korrekt sind. Du bezahlst Mitarbeiter dafür, Ordnerstrukturen zu sichten, die sie selbst nicht mehr verstehen. Und am Ende hast du denselben Datenfriedhof wie vorher, nur in der Cloud und mit einer KI obendrauf, die jetzt auf dem gesamten Friedhof halluzinieren kann.

Über einen zweiten Effekt wird dabei seltener gesprochen: Berechtigungen. Auf alten Fileshares kann fast jeder fast alles sehen, das ist über die Jahre so gewachsen. Solange Menschen suchen mussten, war das ein theoretisches Problem, denn niemand fand die Gehaltsliste im Unterordner von 2012. Eine KI findet sie. Wer ungefiltert migriert, macht aus jedem historischen Berechtigungsfehler ein akutes Datenschutzproblem.

‍

Der Greenfield-Ansatz

Meine Position, und ich weiß, dass sie polarisiert: Lass den alten Fileshare liegen. Friere ihn ein, mach ihn read-only, behalte ihn als Archiv für das, was aufbewahrt werden muss. Aber hör auf, ihn als Fundament deiner KI-Zukunft zu behandeln.

Stattdessen: Greenfield. Du baust die Wissensbasis für deine KI neu auf, klein, sauber, pro Anwendungsfall. Was gebraucht wird, wird aus dem Archiv geholt, geprüft, in ein aktuelles Format gebracht und erst dann in die neue Struktur übernommen. Was nicht gebraucht wird, bleibt dagegen wo es ist. Für viele fühlt sich das erst mal falsch an, wie Kapitulation vor dem eigenen Datenbestand. Ich halte es für das Gegenteil: Es ist die einzige Variante, bei der du je fertig wirst.

Interessanterweise argumentieren inzwischen sogar Anbieter, die vom „KI auf alles draufsetzen“ leben, gegen die Migration: Dokumente dort lesen, wo sie liegen, nichts umziehen, und die Fragen, die die KI nicht beantworten kann, als Rangliste dafür nutzen, was sich zu dokumentieren lohnt. Über den Weg kann man streiten. In einem sind sich aber fast alle einig, die sich ernsthaft mit dem Thema beschäftigen: Die Vollmigration des Altbestands ist es nicht.

‍

‍

So fängt es in der Praxis an

Zurück zur Frage vom Anfang: Wie sieht die Data-Readiness-Reise denn nun aus? Sie sieht so aus, dass sie klein anfängt, denn am Anfang steht ein einziger Anwendungsfall.

‍

Pilot-Case definieren und Erfolg messbar machen

Such dir deshalb einen Anwendungsfall mit klarem Nutzen und überschaubarem Wissensbedarf. Technischer Support ist ein Klassiker: Die Fragen wiederholen sich, die Antworten sind dokumentierbar, und der Erfolg lässt sich messen, etwa an der Lösungsquote im ersten Kontakt oder der Bearbeitungszeit pro Ticket. Andere Kandidaten sind das Schreiben von Angeboten, das Onboarding neuer Mitarbeiter und interne IT-Anfragen.

Der Pilot-Case zwingt dich zu einer gesunden Disziplin: Anfassen musst du nur die Daten, die dieser eine Fall braucht. Das sind selten mehr als ein paar Dutzend bis ein paar Hundert Dokumente. Damit ist Data Readiness plötzlich ein Projekt von ein paar Wochen.

‍

Welche Dokumente den Umzug wert sind

Welche Dokumente den Umzug in die neue Wissensbasis wert sind, entscheiden bei uns vier Fragen. Wird das Dokument aktiv genutzt, also hat es in den letzten zwölf Monaten jemand geöffnet oder geändert? Ist es die einzige gültige Quelle für sein Thema, oder existieren konkurrierende Versionen? Ist der Inhalt fachlich noch gültig, und kann das jemand im Unternehmen heute bestätigen? Und braucht der Pilot-Case es wirklich, oder ist es nur „vielleicht mal nützlich“?

Nur was alle vier Fragen besteht, kommt mit. Der Rest bleibt im Archiv. Dabei ist die vierte Frage in der Praxis die härteste, weil „vielleicht mal nützlich“ das Argument ist, mit dem Fileshares überhaupt erst entstanden sind. Genau hier passiert das Loslassen.

‍

‍

Von Ordnerchaos zu KI-Format

Was den Filter passiert, wird übersetzt und nicht einfach kopiert. Aus der PowerPoint mit den Support-Prozessen wird eine Markdown-Datei mit klarer Struktur. Aus den fünf Word-Versionen der Eskalationsmatrix wird eine einzige, geprüfte Fassung mit Datum und Verantwortlichem. Unstrukturierte Inhalte, die sich nicht sinnvoll in Markdown fassen lassen, etwa große Bestände an Altdokumenten, die durchsuchbar bleiben sollen, wandern in eine Vektordatenbank. Warum das Zielformat Markdown heißt und nicht Wiki-Seite, ist das Thema des Artikels, der nächste Woche folgt.

Dieser Schritt ist Arbeit, keine Frage. Aber es ist einmalige, wertschöpfende Arbeit an einem kleinen, relevanten Bestand. Verglichen mit der Alternative, einen kompletten Fileshare zu kuratieren, ist es ein Bruchteil des Aufwands mit einem Vielfachen des Nutzens. Und mit jedem weiteren Use Case wächst die Wissensbasis dort, wo sie tatsächlich gebraucht wird. Wenn du dafür einen strukturierten Einstieg suchst: Genau diese Priorisierung, welcher Use Case zuerst kommt und welche Daten er braucht, ist der Kern unseres KI-Strategie Workshops.

‍

Loslassen ist Kulturarbeit

Wenn der Greenfield-Ansatz so viel schneller zum Ziel führt, warum macht ihn dann nicht jeder? Weil das Hindernis die Angst ist, etwas wegzuwerfen, das man noch brauchen könnte.

‍

Die Angst vor dem Wegwerfen und wie du ihr begegnest

Diese Angst verstehe ich, ehrlich. In den alten Daten steckt gefühlt die Firmengeschichte, die Arbeit von Kollegen, manche davon nicht mehr im Unternehmen. „Das können wir doch nicht einfach liegen lassen“ ist keine irrationale Reaktion, sie ist menschlich.

Deshalb hilft eine Klarstellung, die in der Diskussion fast immer fehlt, denn Loslassen bedeutet Archivieren. Als Archiv bleibt der alte Bestand also erhalten, unverändert, durchsuchbar, falls doch mal jemand das Angebot von 2014 braucht. Was sich ändert, ist sein Status, denn er ist Geschichte, und Geschichte gehört ins Archiv.

Meine Erfahrung dazu ist eindeutig, denn sobald Mitarbeiter verstehen, dass nichts verloren geht und sich nur die Rolle der alten Daten ändert, kippt die Stimmung. Aus „ihr wollt unsere Arbeit wegwerfen“ wird „endlich müssen wir den alten Kram nicht mehr durchsuchen“. Der Wandel gelingt über diese Umdeutung.

‍

Wohin aufbewahrungspflichtige Daten gehören

Bleibt der Compliance-Einwand: Aufbewahrungspflichten, GoBD, Verträge, Personalunterlagen. Alles richtig, und nichts davon spricht gegen den Greenfield-Ansatz. Aufbewahrungspflichten verlangen, dass Dokumente unverändert und auffindbar aufbewahrt werden. Über die Nutzung durch eine KI sagen sie nichts. Im Gegenteil, ein sauber getrenntes, read-only-Archiv erfüllt Aufbewahrungspflichten besser als ein lebender Fileshare, auf dem weiterhin jeder schreiben kann. Die Trennung in Archiv und Wissensbasis ist also nicht nur KI-hygienisch sinnvoll, sie ist auch aus Governance-Sicht der sauberere Zustand.

‍

Fazit

Die Data-Readiness-Reise, nach der ich immer wieder gefragt werde, gibt es doch. Sie sieht nur anders aus als erwartet. Am Anfang steht eine Entscheidung, die Mut kostet, und zwar den alten Fileshare als Archiv einzufrieren. Die zweite Entscheidung betrifft das, was ab morgen dazukommt. Darum geht es im Artikel nächste Woche.

Das fühlt sich zwar an wie Verzicht, entlastet aber sofort. Das Migrationsprojekt, das nie fertig wird, sparst du dir. Und du bekommst dafür etwas, das bisher kein Wissensmanagement geliefert hat: eine Wissensbasis, die klein genug ist, um aktuell zu bleiben.

Bei aithoria haben wir genau dafür einen schlanken Weg entwickelt, vom Pilot-Case über die Datenauswahl bis zur Wissensbasis, die mit jedem KI-Tool funktioniert. Wenn du wissen willst, wie das bei euch aussehen könnte: Lass uns 20 Minuten sprechen, wo bei euch der erste Use Case und die dafür nötigen Daten liegen.