Wie extrahiere ich Geschäftsregeln aus meinem Altsystem mit KI?

Sie extrahieren die Geschäftsregeln aus Ihrem Altsystem in 3 Schritten: KI liest den Code und formuliert jede Regel als klaren Satz, verknüpft mit der Zeile, aus der sie stammt; der Prozessverantwortliche prüft sie und bestätigt oder korrigiert sie; und Sie vergleichen sie mit dem, was das System bei echten Rechnungen tatsächlich tut. Ein Werkzeug wie AWS Transform für Mainframes schreibt Regeln als prüfbare Anforderungen, und in der Ankündigung von Thought Machine mit Amazon vom 29. September 2026 durchläuft die Extraktion 4 Phasen, die mit einer menschlichen Freigabe enden. Schreiben Sie keinen neuen Code, bevor die Regeln bestätigt sind.

In Teil 3 haben Sie eine Bestandsaufnahme und eine vorläufige Entscheidung für jedes System erarbeitet. Die Systeme, die Sie neu bauen oder konvertieren wollen, brauchen diesen Schritt zuerst.

Warum Geschäftsregeln das Wertvollste in Ihrem Altsystem sind

Eine Geschäftsregel ist die Art, wie Ihr Unternehmen etwas berechnet oder entscheidet: wie der Rabatt eines Großhandelskunden berechnet wird, wann eine Verzugsgebühr hinzukommt, wer eine Bestellung über einer bestimmten Grenze freigibt, wie ein Ratenbetrag gerundet wird. Diese Regeln sind über Jahre voller Änderungen gewachsen, und viele wurden nie in einem Dokument festgehalten.

• Im Code: Bedingungen und Berechnungen, die ein Entwickler vor Jahren auf Wunsch einer Führungskraft geschrieben hat, die das Unternehmen längst verlassen hat.
• In der Datenbank: Preistabellen, Sätze und Grenzwerte, die jemand von Hand ändert, ohne zu wissen, was davon abhängt.
• In den Köpfen der Mitarbeitenden: die Ausnahmen, die die Buchhaltung von Hand erledigt, weil das System es nicht tut.
• In Tabellenkalkulationen: Formeln, die Lücken im System füllen, wie wir in welche Tabelle das System ist erklärt haben.

Wenn Sie das System ohne diese Regeln neu bauen, entsteht ein neues System, das anders rechnet, und Sie merken es erst, wenn ein Kunde eine Rechnung beanstandet. Die Regeln sind das, was umziehen muss; die alte Programmiersprache ist nur der Behälter.

Wie KI den Code liest und die Regeln aufschreibt

Regeln zu extrahieren war lange Handarbeit: Ein Entwickler las den Code Zeile für Zeile und notierte, was er verstand. Heutige Werkzeuge lesen den gesamten Code, verfolgen, woher jede Zahl kommt und wohin sie geht, und schreiben das Gefundene in verständlicher Sprache auf. Ein Beispiel: Amazon schreibt auf der Seite von AWS Transform für Mainframes, dass der Dienst jede Geschäftsregel aus dem Quellcode extrahiert und auf ihren Ursprung zurückführt und dann entwicklungsreife Anforderungen erzeugt, die Ihr Team prüfen kann, jede rückverfolgbar bis zum Code, aus dem sie stammt. Das ist Amazons Beschreibung des eigenen Dienstes, kein garantiertes Ergebnis.

Das Format, in dem eine Regel geschrieben wird, ist wichtig. Ein bekanntes Format ist EARS, der Easy Approach to Requirements Syntax, entwickelt von Alistair Mavin und Kollegen bei Rolls-Royce und erstmals 2009 veröffentlicht. Die Idee: Jede Regel wird in fester Reihenfolge geschrieben, zuerst der Zustand, dann der Auslöser, dann was das System tun muss. Es gibt 5 Grundmuster; hier sind veranschaulichende Beispiele aus dem Geschäftsalltag:

Der Wert dieses Formats: Der Prozessverantwortliche kann es lesen und beurteilen, ohne programmieren zu können. Ein Satz pro Regel, und er antwortet mit ja, nein oder unvollständig.

Ein Beispiel aus dem Bankwesen: Geschäftsabsicht statt Zeile-für-Zeile-Übersetzung

Das deutlichste aktuelle Beispiel kommt aus dem Bankwesen, wo Regeln für Zinsen, Gebühren und Tilgung seit Jahrzehnten in COBOL-Code auf Mainframes leben. COBOL ist eine alte Programmiersprache, auf der noch viele Systeme in Banken und Versicherungen laufen. In seiner Ankündigung vom 29. September 2026 erklärte Thought Machine, ein Bankentechnologie-Unternehmen, dass es mit Amazon an einem Verfahren arbeitet, das Code nicht Zeile für Zeile übersetzt, sondern die reine Geschäftsabsicht extrahiert. Laut der Ankündigung umfasst das Verfahren 4 Phasen:

1. Extraktion: AWS Transform liest die Altanwendungen und extrahiert die Geschäftslogik in Spezifikationen im EARS-Format.
2. Konsolidierung: Hunderte redundante Varianten desselben Produkts werden zu schlanken, modernen Spezifikationen zusammengeführt.
3. Synthese: KI-Agenten erzeugen die Finanzprodukte und ihre Tests in Python.
4. Validierung: menschliche Prüfung, bei der die Engineering- und Risikoteams der Bank ausdrückliche Freigabebefugnis haben.

Beachten Sie die zwei Lehren: Die Konsolidierung zeigt, dass ein Altsystem viele Kopien derselben Regel mit sich trägt, und die letzte Phase ist vollständig menschlich. Das sind Aussagen der beiden Unternehmen über ihr Verfahren, und ihr Beispiel ist eine Bank, aber die Methode passt für jedes Unternehmen: extrahieren, Duplikate zusammenführen, dann bauen, und nichts freigeben, bevor der Entscheidungsverantwortliche unterschrieben hat.

Warum der Prozessverantwortliche jede Regel bestätigen muss

KI liest, was der Code tut, nicht was das Unternehmen will. In der Lücke dazwischen entstehen Modernisierungsfehler:

• Toter Code: Sie kann eine Regel aus einem Teil extrahieren, der seit Jahren nicht mehr genutzt wird, sodass er wie eine lebende Regel aussieht.
• Ein alter Fehler, der zur Gewohnheit wurde: Das System rundet einen Betrag falsch, und die Mitarbeitenden korrigieren das von Hand. Die extrahierte Regel übernimmt den Fehler, wenn niemand sagt, dass es ein Fehler ist.
• Eine Regel außerhalb des Codes: Die Ausnahme, die die Buchhaltung von Hand erledigt, taucht in der Extraktion nie auf.
• Widersprüchliche Regeln: zwei Versionen der Rabattberechnung an zwei verschiedenen Stellen. Welche richtig ist, ist eine geschäftliche Entscheidung, keine technische.

Geben Sie deshalb jeder Regel einen fachlichen Verantwortlichen, der sie abzeichnet: die Vertriebsleitung für Rabattregeln, die Finanzleitung für Verzugsgebühren und Freigaben. Bestätigte Regeln werden zur Grundlage des Lastenhefts für das neue System, und wie man es schreibt, haben wir in unserem Leitfaden für Softwareanforderungen erklärt. Bedenken Sie, dass Code und Datenbanken Kunden- oder Mitarbeiterdaten enthalten können; jedes Werkzeug, das sie außerhalb des Königreichs liest, braucht daher die Prüfung aus Teil 3, zusammen mit den Vorgaben der Saudischen Behörde für Daten und künstliche Intelligenz (SDAIA).

Die Sicht von Origami

Wenn wir ein Altsystem modernisieren, behandeln wir seine Geschäftsregeln als das Wichtigste, das übertragen werden muss, nicht seinen Code. Wir nutzen KI-Werkzeuge, um den Code zu lesen und die Regeln in einem bisher unmöglichen Tempo als klare Sätze aufzuschreiben, aber keine Regel gilt als endgültig, bevor der Prozessverantwortliche sie gelesen und abgezeichnet hat.

Dann testen wir jede bestätigte Regel mit echten Daten aus dem Altsystem, bevor wir das neue System darum herum bauen, damit es so rechnet, wie das Unternehmen es erwartet, und nicht, wie ein Werkzeug es vermutet. Wenn Sie sehen möchten, wie wir arbeiten, werfen Sie einen Blick auf unsere Leistungen.

Die Übung dieser Woche: eine Regel, drei Rechnungen

Sie müssen nicht auf ein Werkzeug warten, um anzufangen. Wählen Sie eine Regel, über die oft diskutiert wird, etwa einen Rabatt oder eine Verzugsgebühr, und gehen Sie so vor:

1. Bitten Sie den Prozessverantwortlichen, die Regel in einem Satz aufzuschreiben, in der Form: Wenn..., muss das System...
2. Ziehen Sie 3 echte Rechnungen aus dem System, bei denen die Regel angewendet wurde: eine normale, eine an der Grenze und eine mit Ausnahme.
3. Berechnen Sie jede Rechnung von Hand mit dem geschriebenen Satz und vergleichen Sie das Ergebnis mit dem, was das System ausgegeben hat.

Stimmen alle drei überein, ist die Regel dokumentiert. Weicht eine ab, haben Sie eine versteckte Regel oder einen alten Fehler gefunden, und genau das müssen Sie vor jeder Modernisierung wissen.

Im nächsten Teil

Sie haben nun bestätigte Regeln für Ihr System. Jetzt kommt die große Entscheidung: Ziehen Sie das System unverändert um, konvertieren Sie seinen Code auf eine moderne Plattform, bauen Sie es um die extrahierten Regeln herum neu, oder ersetzen Sie es durch ein fertiges Produkt und behalten nur die Daten? In Teil 5 vergleichen wir diese Wege in einer Tabelle: wann jeder passt, was er bewahrt, was er riskiert und wer beteiligt sein muss.

Quellen

• AWS Transform für Mainframes: offizielle Seite — Extraktion von Geschäftsregeln mit Rückverfolgung zum Originalcode, prüfbare Anforderungen und Äquivalenztests.
• Thought Machine und AWS: Ankündigung vom 29. September 2026 — die vier Phasen: EARS-Extraktion, Konsolidierung, Synthese und menschliche Validierung.
• EARS: der offizielle Leitfaden von Alistair Mavin — das Format, seine fünf Muster und seine Erstveröffentlichung 2009.
• SDAIA: Schutz personenbezogener Daten.