Die Terabyte-Frage: Wie edda Betriebsdaten lesbar macht

Warum die Terabyte-Frage die falsche Angst trägt

Hinter der Frage steckt ein Bild: Jemand müsste alle Daten auf einmal in ein System laden, und das System müsste sie alle auf einmal verstehen. So arbeitet kein brauchbares System, und so arbeitet auch kein Mensch. Der Instandhalter, der eine Störung in vierzig Minuten löst, hat nicht das ganze Archiv im Kopf. Er weiß, wo er nachsieht, und er erkennt das richtige Dokument, wenn er es vor sich hat. Genau diese zwei Fähigkeiten baut die Pipeline nach: die Bestände so vorbereiten, dass die richtige Stelle in Sekunden gefunden wird, und die gefundene Stelle so belegen, dass ihr jemand traut.

Die Größe des Bestands entscheidet dabei über Aufwand und Dauer der Vorbereitung, nicht über die Machbarkeit. Bei TROESTER waren es zwölf angebundene Systeme, deren Bestände heute Servicefragen beantworten, gemessen im Zwei-Wochen-Pilot: Lösungszeit pro Störung von rund sechs Stunden auf 76 Minuten. Der Weg dorthin ist derselbe, ob ein Betrieb 200 Gigabyte oder 20 Terabyte hat. Er hat sechs Stufen.

Wie liest edda Terabytes aus, ohne alles zu kopieren?

Stufe eins, Konnektoren. edda verbindet sich mit den Quellsystemen, in denen die Daten heute liegen: ERP, MES, SharePoint, Netzlaufwerke, Postfächer, Ticketsystem. Entscheidend ist die Delta-Synchronisation. Beim ersten Lauf wird der Bestand einmal gelesen, danach nur noch das, was sich geändert hat. Ein Vollabzug jede Nacht würde bei Terabytes weder in die Nacht passen noch in das Netz. Ein Delta von ein paar hundert geänderten Dokumenten pro Tag passt in Minuten.

Stufe zwei, Extraktion. Aus jeder Datei wird das herausgelöst, was Text trägt: Fließtext aus Word und PDF, Tabellen samt Struktur, Zeichnungsköpfe und Stempelfelder aus Scans per Texterkennung, Betreff und Anhänge aus Mails. Die schwierigen Dokumente sind dabei die wertvollen. Der Wartungsbericht von 2019, den jemand mit der Hand ausgefüllt und eingescannt hat, enthält meist genau das Wissen, das heute fehlt.

Stufe drei, Zerlegen und Einbetten. Ein 300-seitiges Handbuch ist als Ganzes nicht durchsuchbar, seine Abschnitte sind es. Jedes Dokument wird in sinnvolle Abschnitte zerlegt, und jeder Abschnitt bekommt eine mathematische Darstellung seiner Bedeutung, einen Vektor. Damit findet das System Stellen, die dasselbe meinen, auch wenn sie andere Wörter benutzen: „Lager heiß" und „Temperaturabweichung Spindel" landen nebeneinander.

Stufe vier, Index und Wissensgraph. Die Vektoren wandern in einen Index, der Ähnlichkeit in Millisekunden findet. Daneben entsteht ein Graph, der Dinge verbindet, wie der Betrieb sie denkt: diese Anlage, dieser Fall, dieser Vertrag, dieser Kunde. Die Ähnlichkeitssuche findet Formulierungen, der Graph findet Zusammenhänge. Beides zusammen schlägt jede Volltextsuche, die nur Wörter kennt.

Stufe fünf, Berechtigungen. Wer eine Akte im Quellsystem nicht öffnen darf, bekommt aus ihr auch keine Antwort. Die Rechte werden aus ERP, SharePoint und Ablage gespiegelt und bei jeder Anfrage geprüft, zur Abfragezeit, nicht einmal beim Import. Das ist die Bedingung, unter der Betriebsrat und IT-Sicherheit ein solches System mittragen, und sie ist von Anfang an Teil der Architektur.

Stufe sechs, Antwort mit Quelle. Jede Antwort verlinkt die Abschnitte, aus denen sie stammt. Wer zweifelt, klickt und steht im Originaldokument. Warum das im Betrieb über Vertrauen entscheidet, steht in Antwort mit Quelle.

Was passiert mit Scans, Zeichnungen und Mails?

Die drei Bestände, bei denen Betriebe die Terabyte-Frage am lautesten stellen, sind zugleich die drei mit dem meisten Wissen darin. Scans laufen durch Texterkennung, Tabellen in Scans werden als Tabellen erkannt, nicht als Zeichensalat. Zeichnungen liefern über Schriftfeld, Stückliste und Änderungsindex genug Text, um gefunden zu werden, auch wenn das System die Geometrie selbst nicht interpretiert. Mails sind der größte und unordentlichste Bestand, und sie enthalten die Zusagen, Ausnahmen und Absprachen, die in keinem System stehen. Wie viel davon in Postfächern liegt, beschreibt Dokumente liegen in Postfächern.

Wie schnell antwortet das System?

Die Suche im Index ist eine Sache von Millisekunden, die Antwort des Sprachmodells dauert einige Sekunden. Für den Betrieb zählt eine andere Zahl: die Zeit bis zur gelösten Frage. Bei TROESTER lag sie im Service bei rund sechs Stunden pro Störung, weil das Wissen über zwölf Systeme verteilt war und die Suche den größten Teil der Zeit fraß. Nach dem Pilot waren es 76 Minuten, gemessen mit derselben Methode wie vorher über die protokollierten Fälle des Pilotzeitraums. Der Unterschied liegt in der Suche, die verschwindet. Die Reparatur selbst dauert so lange wie zuvor.

Was die Pipeline nicht löst

Drei Dinge bleiben beim Betrieb. Erstens die Datenqualität: Ein Dokument, das falsch ist, wird durch Indexierung nicht richtig, es wird nur schneller gefunden. Wo die Grundlage fehlt, hilft Datenqualität als Fundament weiter. Zweitens das Wissen, das nie aufgeschrieben wurde: Was nur im Kopf eines Kollegen existiert, kann keine Pipeline lesen. Dafür braucht es Interviews, Schichtbücher und die Disziplin, Antworten künftig festzuhalten. Drittens die Entscheidung, was gelesen werden darf. Welche Bestände angebunden werden, welche Rechte gelten und ob die Daten das Haus verlassen, entscheidet der Betrieb, nicht das System. Die vier Betriebsformen dazu stehen in Bleiben unsere Daten in Deutschland.

Womit ein Betrieb anfängt

Mit einer Zahl, nicht mit den Terabytes. Wie lange dauert heute eine Servicefrage, eine Angebotsrecherche, die Suche nach dem letzten Prüfprotokoll? Diese Vorher-Zahl wird mit Bordmitteln erhoben, über die letzten zwanzig Fälle. Danach werden zwei bis drei Quellsysteme angebunden, die für diesen einen Prozess zählen, und der Pilot läuft zwei bis vier Wochen an echten Beständen. Am Ende steht die Nachher-Zahl, und sie entscheidet über den Ausbau auf die nächsten Systeme. Der Unterschied zu einer Checkliste oder einem Wiki ist genau dieser Messpunkt, wie Checklisten vs. KI-Wissens-Hub zeigt.