Sprachmodell an einem Bestandssystem von 1998
Beispielprojekt. Es zeigt Aufbau und Vorgehen, beschreibt aber keinen erteilten Auftrag; Kunde, Zahlen und Zitat sind nicht belegt.
- Kunde
- Logistikdienstleister, 2.500 MitarbeitendeAuf Wunsch des Kunden ohne Namen.
- Branche
- Logistik
- Jahr
- 2026
Ausgangslage
Der Stand vor dem Projekt
Die Disposition lief über ein Host-System von 1998, ohne dokumentierte Schnittstelle. Wer nach einer Sendung fragte, landete im Callcenter. Dort suchten Mitarbeitende die Auskunft aus vier Masken zusammen.
Aktualität der Daten
1 Nacht
Beispielprojekt, nicht belegt
Eingriffe in das Altsystem
0
Beispielprojekt, nicht belegt
bis zum Produktivbetrieb
3 Wochen
Beispielprojekt, nicht belegt
Lösung
Was das System tut
Zwei Altsysteme, zwei Wege. Vom Host lesen wir die vorhandene Nachrichtenwarteschlange mit; die Copybooks liegen als geprüftes Schema vor, und der Sendungsstatus steht in Sekunden bereit. Aus der Lagerverwaltung, die keine Schnittstelle hat, lesen wir den Bestandsauszug, den sie ohnehin jede Nacht schreibt. Der Agent beantwortet aus beidem und nennt an jeder Auskunft ihren Stand. An beiden Systemen blieb jede Zeile, wie sie war.
Zwei Altsysteme, zwei Aktualitäten. Der Host schreibt seine Nachrichten ohnehin nach IBM MQ. Ein Übersetzer bringt die Copybooks in ein versioniertes Schema, Kafka verteilt sie, und eine Projektion hält den letzten Sendungsstatus je Kennung vor. Das läuft in Sekunden. Das Lagerverwaltungssystem hat keine dokumentierte Schnittstelle; gelesen wird deshalb der Bestandsauszug, den es seit fünfzehn Jahren jede Nacht auf ein Laufwerk schreibt, und diese Daten sind bis zu einen Tag alt. Beide Wege laufen im selben Agenten zusammen, und jede Auskunft trägt den Zeitstempel ihres Standes.
›Dieselbe Architektur als Textfassung
Host (COBOL, seit 1998)
│ schreibt ohnehin
↓
IBM MQ ──→ [Übersetzer] ──→ Kafka ──→ [Projektion]
└─ Copybook → Schema └─ Sendungsstatus,
geprüft, versioniert letzter Stand je ID
│
↓
[Agent] ──→ Auskunft
+ Zeitstempel
Lagerverwaltung (ohne Schnittstelle)
│ nächtlicher Bestandsauszug auf ein Laufwerk
↓
[Import] ─────────────────────────────────→ derselbe AgentArchitektur
Wie es aufgebaut ist
Der Host bleibt unberührt. Das war die Bedingung, unter der das Projekt überhaupt begonnen hat: ein System, das seit 28 Jahren läuft und dessen Erbauer im Ruhestand sind, ändert man nicht für eine Auskunftsfunktion.
Der Zeitstempel steht an jeder Auskunft. Eine Projektion ist immer ein Stand von vorhin, und wer das verschweigt, verkauft eine Verzögerung als Gegenwart. Bei einer Sendungsauskunft entscheidet das über die nächste Frage des Kunden.
Die Übersetzung der Copybooks war die eigentliche Arbeit. Sie liegt als versioniertes Schema im Repository und wird gegen echte Nachrichten getestet: ändert der Host ein Feld, bricht der Test und nicht die Auskunft.
Ein System ohne Schnittstelle
Das Lagerverwaltungssystem stammt aus den Neunzigern, läuft stabil und hat keine dokumentierte Schnittstelle. Der Hersteller existiert noch, die Zuständigkeit für dieses Produkt nicht mehr.
Damit fallen zwei der drei üblichen Wege weg. Was bleibt, ist der dritte, und er wird regelmäßig übersehen: die Datei, die ohnehin entsteht.
Der nächtliche Export
Das System schreibt jede Nacht einen vollständigen Bestandsauszug auf ein Laufwerk. Das tut es seit fünfzehn Jahren, weil ein längst abgelöstes Berichtswesen ihn einmal gebraucht hat. Niemand liest ihn mehr.
Wer diese Datei liest, braucht keinen Zugang zum System, keine Freigabe der IT-Sicherheit für einen Datenbankzugriff und keine Abstimmung mit einem Hersteller, der niemanden mehr benennen kann. Er braucht Leserechte auf ein Laufwerk.
Der Preis ist die Aktualität: Die Daten sind bis zu einen Tag alt. Für die Fragen, um die es hier ging, wo liegt ein Artikel, welche Charge ist betroffen, welcher Lieferschein gehört dazu, ist das ohne Bedeutung. Für eine Verfügbarkeitsprüfung im Verkaufsgespräch wäre es das nicht, und dann wäre dieser Weg der falsche gewesen.
Warum nicht in die Datenbank geschrieben wird
Die Datenbank des Altsystems liegt offen. Lesend wäre sie erreichbar, schreibend ebenso.
Geschrieben wird trotzdem nicht. Eine Anwendung prüft beim Speichern Bedingungen, die in der Datenbank nicht abgebildet sind: Plausibilitäten, Folgebuchungen, Sperrkennzeichen. Wer an der Anwendung vorbei schreibt, umgeht diese Prüfungen und erzeugt Zustände, die ihr Hersteller nie vorgesehen hat, und die fallen nicht sofort auf, sondern in drei Monaten bei einer Inventur.
Was geschrieben werden muss, geht deshalb über die Anwendung. Im konkreten Fall über eine Importdatei in dem Format, das sie ohnehin einliest.
Der Aufwand lag woanders
Die Anbindung selbst war in wenigen Tagen fertig. Die drei Wochen gingen fast vollständig in die Aufbereitung: ein Format ohne Feldtrenner, feste Spaltenbreiten, kodiert in einer Zeichensatztabelle, die zwei Umlaute anders abbildet als erwartet.
Dazu kamen Datensätze, die es nach der Dokumentation nicht geben dürfte. Ein Bestand, der über fünfzehn Jahre gewachsen ist, enthält immer solche Fälle, und jeder einzelne muss entschieden werden: überspringen, korrigieren oder melden.
Diese Arbeit ist unspektakulär und sie ist der eigentliche Inhalt einer Altsystem-Anbindung. Wer sie im Angebot unterschlägt, liefert entweder später oder schlechter.
Was daraus folgt
Ein Altsystem ohne Schnittstelle ist selten ein Ausschlusskriterium. Es ist eine Frage danach, welche Aktualität der Vorgang tatsächlich braucht, und diese Frage wird im Erstgespräch gestellt und nicht im Projekt.
Ergebnis
Was sich geändert hat
- Die Auskunft steht in unter zehn Sekunden, ohne Suche in vier Masken
- Der Zugriff bleibt lesend, das Bestandssystem unberührt
- Jede Auskunft trägt den Zeitstempel des Host-Datensatzes
Was im Einsatz ist
- InsideAI
- IBM MQ
- COBOL-Copybooks
- Kafka
- OpenTelemetry
Produkt- und Anbieternamen sind Marken der jeweiligen Inhaber. Ihre Nennung weist auf den Einsatz hin, nicht auf eine geschäftliche Verbindung.
Kontakt
Wir sehen uns Ihren Vorgang an
Wir gehen Ihren Vorgang durch und sagen, welche Schritte zuerst dran sind.