Warum ich glaube, dass klassische IT-Schulung in gewachsenen Systemlandschaften nicht mehr ausreicht

Ich habe großen Respekt vor klassischer Schulung. Viele von uns haben genau so gelernt: ein Seminarraum, ein erfahrener Trainer, strukturierte Unterlagen, Beispiele, Übungen und am Ende vielleicht eine Teilnahmebescheinigung. Das war lange ein gutes Modell. Und es ist auch heute nicht grundsätzlich falsch.

Aber ich glaube: Für die Realität moderner IT-Organisationen reicht dieses Modell allein nicht mehr aus.

Gerade im Legacy-Umfeld, bei Mainframe-Anwendungen, gewachsenen Fachverfahren, komplexen Datenflüssen und Modernisierungsvorhaben, geht es längst nicht mehr nur darum, einzelne Technologien zu erklären. Natürlich muss jemand verstehen, was COBOL ist. Natürlich muss jemand JCL lesen können. Natürlich braucht es Wissen über CICS, Db2, VSAM, Batch-Prozesse, Schnittstellen oder Betriebsabläufe.

Aber das eigentliche Problem beginnt danach.

Denn in der Praxis fragt niemand nur: „Wie funktioniert diese Technologie im Lehrbuch?“ Die wichtigere Frage lautet: „Was bedeutet das in unserer konkreten Umgebung?“

Welche Anwendung hängt an welchem Prozess? Welche Jobkette versorgt welche Daten? Welche Schnittstelle ist kritisch? Welche Änderung sieht klein aus, kann aber fachlich große Auswirkungen haben? Wo steckt Wissen nur noch in den Köpfen weniger Spezialisten? Und welche Teile eines Systems müssen wir wirklich verstehen, bevor wir über Modernisierung sprechen?

Genau an diesem Punkt beginnt für mich Enablement.

Wissen allein macht noch nicht handlungsfähig

Ich beobachte immer wieder, dass Unternehmen nicht unbedingt zu wenig Wissen haben. Häufig ist sogar sehr viel Wissen vorhanden. Es gibt Dokumentation, alte Projekthandbücher, Architekturübersichten, Tickets, Kommentare im Code, Betriebshandbücher, Wikis und natürlich erfahrene Kolleginnen und Kollegen, die unglaublich viel wissen.

Trotzdem entsteht Unsicherheit.

Warum? Weil Wissen nicht automatisch verfügbar, verständlich oder anwendbar ist. Es ist verteilt. Es ist historisch gewachsen. Es ist manchmal veraltet. Es ist oft nicht dort, wo es gerade gebraucht wird. Und es ist selten so aufbereitet, dass neue Mitarbeitende, Projektteams oder Modernisierungspartner damit sofort sicher arbeiten können.

Klassische Schulung vermittelt Inhalte. Das ist wichtig. Aber Enablement geht weiter. Enablement fragt: Wie wird aus diesem Wissen echte Handlungsfähigkeit?

Für mich ist das der zentrale Unterschied. Eine Schulung erklärt ein Thema. Enablement hilft einem Team, damit im Alltag sicherer zu werden. Eine Schulung folgt einer Agenda. Enablement orientiert sich stärker an der realen Ausgangslage. Eine Schulung endet oft nach ein oder zwei Tagen. Enablement soll im Projekt, im Betrieb und in der Modernisierung weiterwirken.

Das klingt vielleicht wie ein sprachlicher Feinschliff. Ich halte es aber für einen echten Paradigmenwechsel.

Legacy-Systeme versteht man nicht isoliert

Gerade bei Legacy-Systemen halte ich isolierte Wissensvermittlung für gefährlich unvollständig.

Man kann COBOL sehr gut erklären. Man kann zeigen, wie Datenstrukturen aufgebaut sind, wie Copybooks funktionieren, wie File Handling aussieht und wie Programme miteinander interagieren. Man kann JCL, CICS oder Datenbankzugriffe einzeln betrachten. All das ist notwendig.

Aber in einer echten Unternehmenslandschaft kommt die entscheidende Komplexität durch das Zusammenspiel.

Ein COBOL-Programm ist nicht nur Code. Es ist oft Träger fachlicher Regeln, die über Jahre oder Jahrzehnte gewachsen sind. Ein Batchjob ist nicht nur ein technischer Ablauf. Er kann ein kritischer Bestandteil einer fachlichen Verarbeitungskette sein. Eine Datei ist nicht nur eine Datei. Sie kann Übergabepunkt, historischer Kompromiss, Integrationsvehikel oder stillschweigende Abhängigkeit sein.

Wer solche Systeme modernisieren, warten oder erweitern will, muss mehr verstehen als Syntax und Technologie. Er oder sie muss die Wirkung im System verstehen.

Und genau hier greift Enablement besser als klassische Schulung. Enablement bringt technische Erklärung, fachlichen Kontext, reale Beispiele und praktische Anwendung näher zusammen. Es geht nicht nur darum, etwas zu wissen. Es geht darum, etwas einordnen zu können.

Ein Beispiel aus der Praxis: HLASM nicht als Mnemonic-Liste

Ein gutes Beispiel dafür war meine letzte HLASM-Schulung. Natürlich kann man Assembler-Unterricht so aufbauen, dass man sich durch Mnemonics, Register, Befehlsformate und einzelne Instruktionen arbeitet. Das ist fachlich nicht falsch. Aber wenn es dabei bleibt, entsteht schnell genau das, was ich unter klassischer Schulung verstehe: viel Stoff, viele Details, aber noch keine sichere Anwendung.

Mir war deshalb wichtig, HLASM nicht als reines Auswendiglernen von Befehlen zu vermitteln. Es ging nicht darum, dass Teilnehmer möglichst viele Mnemonics aufsagen können. Es ging darum, Zusammenhänge zu verstehen: Was passiert im Speicher? Welche Rolle spielen Register wirklich? Wie wirken Adressierung, Datenbereiche, Aufrufkonventionen und Programmlogik zusammen? Warum sieht bestimmter Code so aus, wie er aussieht? Und wie kann man auch dann noch sinnvoll analysieren, wenn man nicht jede Instruktion sofort auswendig kennt?

HLASM-Fortbildung bei DPS Engineering in Hamburg

Genau das ist für mich Enablement. Die Teilnehmer sollen nicht nur „Assembler gesehen“ haben. Sie sollen in der Lage sein, Code sicherer zu lesen, typische Strukturen zu erkennen, Fehlerbilder besser einzuordnen und bei Analyse- oder Modernisierungsfragen nicht sofort vor einer Wand aus kryptischen Befehlen zu stehen.

Das ist im Alltag viel wertvoller als ein auswendig gelernter Befehlskatalog. Denn niemand wird in einer gewachsenen Mainframe-Landschaft dadurch handlungsfähig, dass er isolierte Mnemonics kennt. Handlungsfähigkeit entsteht, wenn man versteht, warum etwas so gebaut wurde, wie es zusammenwirkt und wie man sich systematisch nähert.

Der eigentliche Engpass ist oft nicht der fehlende Kurs

Ich glaube, viele Organisationen suchen an der falschen Stelle nach der Lösung. Wenn Wissen fehlt, wird schnell nach einer Schulung gefragt. Das ist nachvollziehbar. Aber oft ist nicht der fehlende Kurs das eigentliche Problem.

Der eigentliche Engpass liegt häufig in anderen Bereichen: Wissen ist auf wenige Personen konzentriert, neue Mitarbeitende bekommen zu spät realistische Einblicke, Modernisierungsteams unterschätzen fachliche Abhängigkeiten, Werkzeuge werden eingeführt, ohne dass klar ist, wie sie sinnvoll genutzt werden, und Dokumentation existiert zwar, erklärt aber nicht die tatsächliche Wirklichkeit des Systems. Dazu kommt, dass Fachbereich, Entwicklung und Betrieb oft über dieselbe Anwendung sprechen, aber aus völlig unterschiedlichen Perspektiven.

Das lässt sich nicht allein mit einer Schulung lösen.

Dafür braucht es einen Ansatz, der Lernen, Anwenden, Reflektieren und Entscheiden verbindet. Genau das verstehe ich unter Enablement.

Was Enablement konkret anders macht

Enablement beginnt für mich mit einer anderen Haltung. Es stellt nicht zuerst die Frage: „Welche Folien brauchen wir?“ Sondern: „Was sollen Menschen danach besser können?“

Dabei macht es einen großen Unterschied, ob neue Mitarbeitende schneller produktiv werden sollen, ob erfahrene Spezialisten ihr Wissen besser weitergeben müssen, ob ein Team eine Anwendung wirklich verstehen soll oder ob ein Modernisierungsvorhaben vorbereitet wird. Ebenso verändert sich der Ansatz, wenn KI sinnvoll in Analyse, Dokumentation oder Testunterstützung eingebunden werden soll oder wenn ein Partner befähigt werden muss, Kundenanforderungen besser zu qualifizieren. In all diesen Fällen reicht ein Standardkurs selten aus. Der Inhalt muss zur Rolle, zur Ausgangslage und zum gewünschten Ergebnis passen.

Enablement kann deshalb Schulung enthalten, aber auch Workshops, Labs, gemeinsame Analyse von Beispielsystemen, Tool-Demonstrationen, Reviews, Mentoring, Q&A-Formate, praktische Übungen und Transferbegleitung.

Der Punkt ist: Schulung ist ein Baustein. Enablement ist der Rahmen, in dem aus diesem Baustein Wirkung entsteht.

KI verändert die Diskussion – aber anders als viele glauben

Ein besonders spannender Aspekt ist für mich KI.

Auf den ersten Blick könnte man sagen: Wenn KI Code erklären, Dokumentation erzeugen, Testfälle vorschlagen oder bei Modernisierungsideen helfen kann, dann brauchen wir doch weniger Schulung.

Ich sehe das genau andersherum.

KI macht Enablement wichtiger.

Denn KI kann unterstützen, beschleunigen und neue Perspektiven liefern. Aber KI versteht nicht automatisch die Verantwortung, die mit geschäftskritischen Systemen verbunden ist. Ein generierter Erklärungstext zu einem COBOL-Programm kann hilfreich sein. Aber er ersetzt nicht das Verständnis dafür, welche fachliche Bedeutung dieses Programm im Unternehmen hat. Ein vorgeschlagener Testfall kann ein guter Anfang sein. Aber er ersetzt keine durchdachte Teststrategie. Ein Refactoring-Vorschlag kann interessant sein. Aber er ist noch keine tragfähige Modernisierungsentscheidung.

KI-Ergebnisse müssen bewertet werden. Und diese Bewertung braucht Menschen mit Kontext, Erfahrung und Urteilsvermögen.

Das ist aus meiner Sicht einer der wichtigsten Punkte: Je mehr Werkzeuge automatisch erklären, vorschlagen und erzeugen, desto wichtiger wird die Fähigkeit, diese Ergebnisse kritisch einzuordnen.

KI ist kein Ersatz für Enablement. KI ist ein Grund, Enablement ernster zu nehmen.

Schulung bleibt wichtig – aber sie darf nicht der Endpunkt sein

Ich möchte klassische Schulung nicht abwerten. Sie bleibt wichtig. Sie schafft Grundlagen. Sie strukturiert Wissen. Sie kann Einstiegshürden senken. Und sie ist oft der erste sinnvolle Schritt.

Aber sie darf nicht der Endpunkt sein.

Wenn nach einer Schulung alle sagen: „Das war interessant“, aber niemand weiß, wie das Gelernte im eigenen Umfeld angewendet werden soll, ist zu wenig erreicht. Wenn Teilnehmende eine Technologie erklären können, aber nicht sicher einschätzen können, welche Bedeutung sie in der eigenen Systemlandschaft hat, fehlt der Transfer. Wenn ein Unternehmen nach einer Schulung weiterhin von denselben Wissensinseln abhängig ist, wurde das eigentliche Problem nicht gelöst.

Der Anspruch muss höher sein.

Nicht: „Wir haben geschult.“ Sondern: „Unsere Teams können danach besser arbeiten.“ Nicht: „Die Inhalte wurden vermittelt.“ Sondern: „Die Menschen können sie im richtigen Kontext anwenden.“ Nicht: „Es gab eine Teilnahmebescheinigung.“ Sondern: „Es ist mehr Sicherheit im System entstanden.“

Enablement ist die erwachsene Form von Schulung

Schulung im alten Verständnis reicht für viele heutige Aufgaben nicht mehr aus.

Wir brauchen weniger Denken in Kursformaten und mehr Denken in Befähigung. Weniger Frontalvermittlung und mehr Praxisbezug. Weniger isolierte Technologiebetrachtung und mehr Systemverständnis. Weniger „Das steht so im Handbuch“ und mehr „Das bedeutet es für unsere konkrete Umgebung“.

Für mich ist Enablement deshalb die erwachsene Form von Schulung.

Es verbindet Wissen mit Anwendung. Es verbindet Erfahrung mit neuen Methoden. Es verbindet Legacy-Verständnis mit Modernisierung. Es verbindet KI-Unterstützung mit menschlicher Bewertungskompetenz. Und es verbindet Lernen mit echter Verantwortung im Arbeitsalltag.

Moderne IT-Organisationen brauchen genau das. Nicht noch mehr Folien. Nicht noch längere Agenden. Nicht noch eine Teilnahmebescheinigung als Beruhigungspille.

Sie brauchen Teams, die verstehen, anwenden, bewerten und handeln können.

Und genau deshalb ist Enablement heute nicht nur der modernere Begriff. Es ist die bessere Antwort auf die Realität gewachsener IT-Landschaften.

Über den Autor: Uwe Graf ist Head of Consulting bei der EasiRun Europa GmbH und gilt auf LinkedIn als eine der profiliertesten Stimmen in Sachen Mainframe-Modernisierung. Seine Beiträge sind fachlich präzise, pointiert – und unverkennbar durch den kleinen Dino, der als Symbol für den Brückenschlag zwischen Tradition und Innovation steht. Für sein Engagement in der Mainframe-Community wurde er 2025 sowohl als IBM Champion als auch als „Influential Mainframer“ von planetmainframe.com ausgezeichnet