Das Besondere daran ist weniger das Etikett „AI“. Spannend ist vielmehr, wie sich ein über Jahrzehnte bewährtes Steuerungsverfahren mit historischen Betriebsdaten ergänzen lässt. WLM reagiert traditionell sehr gut auf den aktuellen Zustand eines Systems. Die KI-Komponente versucht zusätzlich vorherzusagen, was in den nächsten Minuten wahrscheinlich passieren wird.
Gerade in Banken und Versicherungen ist das eine interessante Kombination. Dort gehören planbare Lastspitzen, eng getaktete Batch-Fenster und zeitkritische Folgeprozesse zum täglichen Betrieb. Zahlungsverkehr, Buchungen, Tagesabschlüsse, Kontenverarbeitung, regulatorische Auswertungen, Beitragsabrechnungen oder Schadenprozesse entstehen schließlich nicht völlig zufällig. Viele dieser Workloads folgen festen Zeitplänen und wiederkehrenden Mustern.
IBM beschreibt die Funktion für z/OS unter anderem in dieser Veröffentlichung.
WLM war schon lange vor KI intelligent
Bevor man den KI-Anteil betrachtet, sollte man sich zunächst vergegenwärtigen, was der klassische Workload Manager ohnehin bereits leistet. Für WLM-gesteuerte Jobklassen entscheidet das System dynamisch, wie viele Initiators aktiv sein sollen. Dabei spielen unter anderem die Anzahl wartender Jobs, definierte Performanceziele, Prioritäten und die aktuelle Systemauslastung eine Rolle.
Das Verfahren ist seit Jahren ausgereift und wird von IBM hier beschrieben.
Der entscheidende Punkt ist jedoch, dass dieses Verhalten grundsätzlich reaktiv ist. Wenn eine größere Anzahl von Jobs eintrifft, erkennt WLM den zusätzlichen Bedarf und reagiert darauf. Bei regelmäßig auftretenden Batch-Wellen kann dadurch trotzdem eine kurze Phase entstehen, in der Jobs warten, während zusätzliche Initiators bereitgestellt werden.
In einer beliebigen Unternehmensanwendung mögen einige Sekunden mehr oder weniger Queue Time kaum auffallen. In Banken und Versicherungen kann sich dieser Effekt dagegen über große Verarbeitungsketten hinweg summieren.
Ein Tagesabschluss besteht beispielsweise selten aus einem einzigen Job. Häufig startet eine ganze Kette von Verarbeitungen, deren Ergebnisse wiederum Voraussetzung für weitere Jobs sind. Verzögert sich ein früher Schritt, verschieben sich möglicherweise auch nachgelagerte Prozesse. Ähnliches gilt für Versicherungen, wenn etwa Beitragsberechnungen, Bestandsverarbeitung, Provisionsabrechnungen oder regulatorische Auswertungen innerhalb eines definierten Nachtfensters abgeschlossen werden müssen.
Der interessante Gedanke lautet deshalb nicht, ob man durch KI einzelne Sekunden spart. Entscheidend ist, ob ein System früh genug auf vorhersehbare Last reagieren kann, damit die gesamte Verarbeitungskette stabiler durch das verfügbare Zeitfenster läuft.
Was wäre, wenn WLM zwei Minuten früher Bescheid wüsste?
Viele Batch-Workloads sind erstaunlich regelmäßig. Sie beginnen zu ähnlichen Uhrzeiten, an bestimmten Wochentagen oder rund um Monats-, Quartals- und Jahresabschlüsse. Scheduler sorgen zusätzlich dafür, dass sich Abläufe über lange Zeit sehr ähnlich wiederholen.
Genau solche Muster können aus historischen Daten gelernt werden.
AI-powered WLM verwendet dafür systembezogene Zeitreihenmodelle. Diese Modelle untersuchen historische Workload-Daten und versuchen vorherzusagen, wie viele Initiators für eine Batch-Service-Class in naher Zukunft benötigt werden. IBM erläutert den Ansatz hier.
Kann das Modell ein wiederkehrendes Muster erkennen, bekommt WLM bereits vor dem tatsächlichen Lastanstieg eine Prognose. Dadurch kann es zusätzliche Initiators früher bereitstellen.
Für eine Bank könnte das beispielsweise bedeuten, dass der regelmäßig auftretende morgendliche oder nächtliche Batch-Peak nicht erst dann behandelt wird, wenn hunderte Jobs bereits in der Queue stehen. Bei einem Versicherer könnte das gleiche Prinzip auf periodische Bestands- oder Abrechnungsläufe angewendet werden.
Der Vorteil entsteht damit nicht durch eine völlig neue Form der Ressourcensteuerung. WLM macht weiterhin das, was es schon immer gut konnte. Der Unterschied besteht lediglich darin, dass das System einen zeitlichen Vorsprung erhält.
Und zwei Minuten können in einer eng getakteten Batch-Kette erheblich wertvoller sein, als sie zunächst erscheinen.
Die KI übernimmt nicht den Mainframe
Gerade in Banken und Versicherungen ist dieser Punkt wichtig, weil dort bei produktionskritischen Systemen zu Recht hohe Anforderungen an Kontrolle, Nachvollziehbarkeit und Stabilität gelten.
Das KI-Modell startet nicht autonom irgendwelche Initiators und übernimmt auch nicht die Steuerung des Systems. Es liefert eine Prognose. Die endgültige Entscheidung bleibt beim Workload Manager.
IBM beschreibt, dass WLM weiterhin den aktuellen Zustand des Systems berücksichtigt. Wenn wichtigere Workloads Ressourcen benötigen, bereits eine hohe Auslastung besteht oder andere Begrenzungen greifen, kann sich WLM gegen das Hochfahren zusätzlicher Initiators entscheiden.
Genau diese Architektur macht den Ansatz für kritische Produktionssysteme interessant.
Die KI sagt sinngemäß: „Auf Basis der vergangenen Wochen dürfte gleich zusätzliche Last kommen.“
WLM entscheidet anschließend: „Unter den aktuellen Bedingungen ist es sinnvoll oder eben nicht sinnvoll, darauf zu reagieren.“
Damit wird ein bewährtes deterministisches Verfahren nicht durch ein statistisches Modell ersetzt, sondern lediglich um zusätzliche Informationen ergänzt.
Für hochregulierte Branchen ist das vermutlich ein wesentlich realistischerer Weg als die Vorstellung, eine KI solle künftig völlig autonom geschäftskritische Produktionssysteme steuern.
Und die Trainingsdaten liegen längst vor
Besonders interessant ist auch die Datengrundlage. Für das Training muss nicht erst eine neue Telemetrieplattform eingeführt werden. Verwendet werden SMF Type 99 Subtype 2 Records.
Laut IBM werden mindestens 30 zusammenhängende Tage historischer Daten benötigt. Das Training erfolgt systembezogen; anschließend kann entschieden werden, für welche geeigneten Service-Classes die Funktion aktiviert werden soll. Details dazu finden sich an dieser Stelle.
Gerade für Banken und Versicherungen steckt darin ein interessanter Gedanke. Diese Unternehmen verfügen häufig über jahrzehntelang gewachsene Mainframe-Landschaften und entsprechend große Mengen historischer Betriebsdaten.
Bislang werden solche Informationen überwiegend rückblickend genutzt. Ein Batch-Fenster war zu langsam, also analysiert man die entsprechenden SMF-Daten. Eine Service Class hat ihre Ziele nicht erreicht, also untersucht man, was passiert ist.
Das klassische Muster lautet:
Ein Problem ist aufgetreten. Jetzt analysieren wir die Vergangenheit.
Mit Zeitreihenmodellen kommt eine zweite Perspektive hinzu. Historische Daten werden nicht nur verwendet, um zu erklären, was passiert ist, sondern auch, um Hinweise darauf zu gewinnen, was wahrscheinlich als Nächstes passieren wird.
Gerade in Branchen mit vielen wiederkehrenden Verarbeitungszyklen ist das ein erheblicher Unterschied.
Banken und Versicherungen sind nahezu ideale Kandidaten
Der Einsatz ist natürlich nicht automatisch überall sinnvoll. AI-powered WLM funktioniert dort am besten, wo Workloads ausreichend regelmäßig sind.
Genau deshalb könnten Banken und Versicherungen besonders interessante Kandidaten sein.
Im Bankenumfeld existieren beispielsweise regelmäßig wiederkehrende Verarbeitungsspitzen im Zahlungsverkehr, in der Kontenverarbeitung, bei Buchungen, Schnittstellen zu Clearing- oder Settlement-Systemen sowie rund um Tages-, Monats- und Quartalsabschlüsse.
Auch Versicherungen arbeiten mit stark zyklischen Workloads. Beitragsabrechnungen, Policenverarbeitung, Bestandsänderungen, Provisionsläufe, Schadenverarbeitung oder periodische Auswertungen erzeugen häufig vergleichbare Lastmuster.
Natürlich wird keine KI jeden außergewöhnlichen Peak vorhersagen können. Ein unerwartetes Marktgeschehen, eine technische Störung oder eine außergewöhnliche fachliche Situation bleibt außergewöhnlich.
Der Nutzen liegt dort, wo Regelmäßigkeit vorhanden ist und bislang lediglich reaktiv darauf reagiert wurde.
IBM empfiehlt deshalb auch, die Modelle regelmäßig mit aktuellen Daten neu zu trainieren, weil sich Workload-Profile verändern können.
Das ist ein wichtiger Punkt, denn das Modell versteht den Geschäftsprozess nicht. Es erkennt statistische Muster. Wenn sich diese Muster ändern, muss auch die Datengrundlage aktualisiert werden.
Erst beobachten, dann produktiv einsetzen
Ein Detail erscheint mir gerade für Banken und Versicherungen besonders wichtig: Die Funktion kann zunächst im Simulation Mode betrieben werden.
Das Modell erzeugt dann bereits Prognosen, diese werden aber noch nicht zur tatsächlichen Steuerung der Initiators verwendet. Stattdessen können die Ergebnisse ausgewertet und mit dem realen Systemverhalten verglichen werden. IBM erläutert dieses Vorgehen hier.
Das ist aus meiner Sicht ein ausgesprochen vernünftiger Weg, KI in geschäftskritischen Produktionssystemen einzuführen.
Man kann zunächst beobachten, welche Entscheidungen das Modell empfohlen hätte, wie gut seine Prognosen mit dem tatsächlichen Workload übereinstimmen und ob überhaupt ein relevanter Nutzen entsteht. Erst wenn dieses Verhalten verstanden ist, muss entschieden werden, ob die Empfehlungen produktiv berücksichtigt werden sollen.
Für regulierte Branchen ist genau diese Nachvollziehbarkeit entscheidend. Neue Technologie wird dort nicht deshalb wertvoll, weil sie modern klingt, sondern weil ihr Verhalten messbar, kontrollierbar und im Zweifel auch erklärbar bleibt.
Die ersten Zahlen sind durchaus bemerkenswert
Wie groß der praktische Effekt sein kann, zeigen Ergebnisse, die Anfang September 2026 von Planet Mainframe aufgegriffen wurden. Der zugrunde liegende Test nutzte 30 Tage SMF-99.2-Daten zum Training des Modells.
Bei regelmäßig geplanten Batch-Workloads sank die durchschnittliche Queue Time von ungefähr 83 auf 25 Sekunden. Gleichzeitig verringerte sich die Zahl gleichzeitig wartender Jobs im Peak von rund 80 auf 42. Zusätzliche Initiators wurden etwa zwei Minuten vor dem erwarteten Lastanstieg gestartet. Der Bericht ist auf Planet Mainframe zu finden.
Diese Werte sollte man natürlich nicht einfach auf jede Installation übertragen. Eine Umgebung mit sehr regelmäßigen Jobwellen bietet dem Modell deutlich bessere Voraussetzungen als ein System mit weitgehend zufälligem Workload.
Trotzdem zeigen die Zahlen recht anschaulich, welchen Effekt der zeitliche Vorsprung haben kann.
Gerade in Banken und Versicherungen sollte dabei nicht nur auf die Queue Time eines einzelnen Jobs geschaut werden. Interessanter ist die Auswirkung auf das gesamte Batch-Fenster. Wenn ein früher Prozess schneller startet, können davon möglicherweise auch alle nachgelagerten Verarbeitungsschritte profitieren.
Und genau dort wird aus einer scheinbar kleinen technischen Optimierung möglicherweise ein geschäftlich relevanter Vorteil.
Vielleicht reden wir zu viel über generative KI
An dieser Stelle stellt sich fast zwangsläufig die Frage, ob ein Zeitreihenmodell zur Workload-Prognose überhaupt in dieselbe Kategorie gehört wie ChatGPT, große Sprachmodelle oder generative KI.
Technisch natürlich nicht.
Und gerade deshalb ist der Anwendungsfall interessant.
In der aktuellen Diskussion wird „KI“ häufig nahezu automatisch mit Large Language Models gleichgesetzt. Dabei existieren viele andere Verfahren, die für bestimmte Aufgaben wesentlich besser geeignet sind.
Für die Vorhersage einer regelmäßig wiederkehrenden Batch-Last braucht man kein Modell, das COBOL erklären oder Texte erzeugen kann. Man braucht ein Verfahren, das Zeitreihen analysiert und zuverlässig wiederkehrende Muster erkennt.
Die entscheidende Frage sollte deshalb nicht lauten:
„Wo können wir generative KI einsetzen?“
Sondern vielmehr:
„Welches Problem wollen wir lösen, welche Daten besitzen wir dafür und welches Verfahren passt dazu?“
AI-powered WLM ist gerade deshalb ein gutes Beispiel, weil Problem, Daten und Ziel vergleichsweise klar definiert sind.
Der eigentliche Schatz könnten die vorhandenen Betriebsdaten sein
Der für mich interessanteste Gedanke geht deshalb über WLM hinaus.
Mainframes produzieren seit Jahrzehnten große Mengen sehr detaillierter Betriebsdaten. SMF, CICS-Monitoring, Db2 Accounting, MQ-Statistiken und weitere Quellen erlauben eine Tiefe der Analyse, die in vielen anderen IT-Umgebungen erst mühsam aufgebaut werden muss.
Bislang wurden diese Daten vor allem retrospektiv genutzt.
Ein Prozess war zu langsam, also wurde analysiert. Eine Transaktion hatte ungewöhnliche Antwortzeiten, also wurden Messwerte untersucht. Ressourcenverbrauch stieg, also suchte man nach der Ursache.
Mit modernen Analyseverfahren verschiebt sich die Perspektive langsam.
Neben der Frage „Warum ist das passiert?“ tritt zunehmend die Frage:
„Können wir aus dem bisherigen Verhalten erkennen, was wahrscheinlich als Nächstes passiert?“
Gerade bei Banken und Versicherungen könnte darin erhebliches Potenzial liegen. Dort existieren nicht nur große Datenmengen, sondern häufig auch ausgesprochen stabile, wiederkehrende operative Muster.
AI-powered WLM ist lediglich ein konkretes Beispiel dafür, wie sich dieses Wissen nutzen lässt.
Die größere Frage lautet, welche weiteren System- und Betriebsdaten künftig verwendet werden könnten, um Anomalien früher zu erkennen, Kapazitätsengpässe vorherzusagen oder kritische Verarbeitungsketten proaktiv zu unterstützen.
Innovation muss nicht immer etwas ersetzen
Vielleicht ist genau das die interessanteste Erkenntnis an diesem Thema.
In vielen KI-Diskussionen wird sehr schnell darüber gesprochen, welche bestehende Tätigkeit, welches Werkzeug oder welche Technologie durch KI ersetzt werden könnte.
Beim AI-powered WLM funktioniert die Logik anders.
WLM bleibt WLM.
SMF bleibt SMF.
Die vorhandenen Mechanismen werden nicht verworfen. Stattdessen wird aus historischen Daten eine zusätzliche Information gewonnen, die ein bewährtes System für bessere beziehungsweise frühere Entscheidungen nutzen kann.
Gerade auf dem Mainframe erscheint mir dieser Ansatz ausgesprochen passend. Banken und Versicherungen setzen diese Plattform schließlich nicht ein, weil sie möglichst experimentell arbeiten möchten, sondern weil dort hochkritische Geschäftsprozesse zuverlässig und kontrolliert verarbeitet werden müssen.
Der Erfolg eines KI-Verfahrens sollte dort deshalb weniger daran gemessen werden, wie spektakulär die Technologie wirkt.
Entscheidend ist, ob sie messbar dazu beiträgt, Stabilität, Vorhersagbarkeit und Effizienz des Betriebs zu verbessern.
Wenn eine regelmäßig wiederkehrende Batch-Welle dadurch früher erkannt wird und WLM rechtzeitig reagieren kann, ist das vielleicht keine KI-Revolution.
Für ein knappes Nachtverarbeitungsfenster in einer Bank oder Versicherung kann es trotzdem ausgesprochen wertvoll sein.
Und vielleicht liegt genau darin eine der realistischsten Chancen für KI auf dem Mainframe: nicht vorhandenes Wissen zu ersetzen, sondern die enorme Menge an Betriebswissen, die längst vorhanden ist, besser und vorausschauender zu nutzen.
Denn manchmal beginnt Innovation nicht mit einem neuen System.
Manchmal beginnt sie damit, dass ein bestehendes System früher erkennt, was gleich passieren wird.
Ü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
