Wenn der letzte COBOL-Entwickler geht: was in den verbleibenden Monaten wirklich hilft
Die übliche Reaktion auf einen absehbaren Abgang ist die Suche nach Ersatz. Bei Mainframe-Kenntnissen ist das eine Suche mit schlechten Quoten und langem Vorlauf — und selbst ein guter Treffer bringt die zwanzig Jahre Systemkenntnis nicht mit. Die Frage muss anders gestellt werden.
Beim absehbaren Abgang von Mainframe-Kennern ist die Nachfolgersuche nicht die erste Maßnahme. Zuerst wird maschinell ausgelesen, was in Quellcode, Job-Steuerung, Schemata und Betriebsdaten steht; Interviews adressieren gezielt die Lücken — Begründungen, Warnungen aus früheren Fehlversuchen und die fachlichen Ansprechpartner je Lauf. Übrig bleiben müssen Abhängigkeitskarte, bewertete Geschäftsregeln und eine ausdrückliche Liste offener Punkte.
Was genau verloren geht
Nicht die Sprache. COBOL ist lernbar, und Menschen, die es können, gibt es. Verloren geht das, was nirgends steht: warum ein Programm einen Sonderfall behandelt, welche Abhängigkeit man auf keinen Fall anfassen darf, welcher Job wirklich kritisch ist und welcher seit Jahren nur mitläuft. Dieses Wissen hängt an Personen, und es hat ein Austrittsdatum.
Die realistische Reihenfolge
Erst auslesen, dann fragen. Was maschinell aus Quellcode, Job-Steuerung, Schemata und Betriebsdaten gewinnbar ist, sollte nicht Gegenstand eines Interviews sein — dafür ist die verbleibende Zeit zu wertvoll. Interviews gehören an die Stellen, an denen die Analyse Lücken zeigt: unklare Sonderfälle, Programme ohne erkennbaren Auslöser, Widersprüche zwischen Dokumentation und Code.
Was in den Interviews tatsächlich wichtig ist
Drei Kategorien. Erstens die Begründungen: warum etwas so gebaut wurde, nicht wie. Zweitens die Warnungen: welche Änderungen schon einmal schiefgegangen sind und warum. Drittens die Beziehungen — welche Fachabteilung ruft an, wenn dieser Lauf nicht durchgeht. Alles drei steht in keinem System und ist in vier bis sechs Gesprächen erfassbar, wenn sie vorbereitet sind.
Was danach übrig bleiben muss
Ein Ergebnis, das ohne die Person funktioniert: eine Abhängigkeitskarte, eine Liste der Geschäftsregeln mit Bewertung, die dokumentierten Warnungen und eine ausdrückliche Liste der offenen Punkte. Letztere ist wichtig, weil sie den nächsten Menschen davor bewahrt, ein Nichtwissen für Wissen zu halten.
Und der Ersatz?
Die Suche bleibt richtig, sie ist nur nicht die erste Maßnahme. Wer die Analyse vorher gemacht hat, kann eine neue Person in Wochen statt Jahren einarbeiten — sie liest eine Karte, statt sie sich zu erarbeiten. Das verändert auch den Anforderungsprofil-Zuschnitt: Gesucht wird jemand, der ein dokumentiertes System übernimmt, nicht jemand, der zwanzig Jahre Erfahrung mitbringt.
Häufige Fragen
Wie viel Zeit braucht man mindestens?
Für ein abgegrenztes System reichen zehn Arbeitstage für die Analyse plus vier bis sechs vorbereitete Gespräche. Kritisch ist nicht die Dauer, sondern die Reihenfolge: Wer erst am Ende analysiert, hat niemanden mehr, der die Funde bestätigen kann.
Was, wenn die Person schon weg ist?
Dann wird die Analyse aufwendiger, aber nicht unmöglich. Quellcode, Job-Steuerung und Betriebsdaten sind noch da; was fehlt, sind die Begründungen. Praktisch heißt das mehr vermutete als belegte Aussagen — und deshalb eine längere Liste offener Punkte, die bei jeder Änderung mitgelesen werden muss.
Lohnt sich eine Analyse, wenn das System ohnehin abgelöst werden soll?
Gerade dann. Eine Neuentwicklung ohne Kenntnis der Geschäftsregeln des Altsystems ist die teuerste Art, dasselbe Nichtwissen noch einmal zu produzieren. Die Analyse ist in diesem Fall keine Investition in das Alte, sondern die Anforderungsgrundlage für das Neue.
Kann man Wissenstransfer nicht einfach über Doppelbesetzung lösen?
Wenn die Zeit reicht, ist eine Überlappung wertvoll — aber sie überträgt vor allem das, woran sich jemand erinnert. Die stillen Teile des Systems, die täglich funktionieren und deshalb nie erwähnt werden, kommen nur über die Analyse ans Licht.
Bringen Sie das System mit, das Ihnen Sorgen macht.
30 Minuten, kein Vertrieb. Wir sagen Ihnen, ob eine Discovery bei diesem System etwas bringt.
Legacy Discovery ansehen →
