In vielen Häusern gilt: KI ja, aber nicht am SAP. Die Sorge ist berechtigt, trifft aber den falschen Punkt. Nicht KI am SAP ist das Risiko, sondern ungegatete KI. Ein Modell, das ohne Prüfung ins System schreibt, ist ein Risiko. Ein Modell, dessen Vorschlag erst durch ein prüfbares Gate muss, ist ein Werkzeug.
Das Telaflux-Modell: Vorschlag, Gate, Ausführung
Telaflux ist meine Dachmarke für ein Muster, das in allen meinen Werkzeugen gleich aufgebaut ist. Es hat drei Stufen:
- Die KI schlägt vor. Sie liest, was im System steht, und erzeugt daraus einen Entwurf: einen Customizing-Vorschlag, ein Mapping, einen Testfall, ein Dokumentationskapitel. Sie schreibt nichts.
- Das Gate entscheidet. Der Vorschlag läuft gegen feste Regeln: erlaubte Objekte, erlaubte Werte, Namenskonventionen, Vollständigkeit, Transportfähigkeit. Was die Regeln nicht durchlassen, wird nicht ausgeführt — unabhängig davon, wie überzeugend der Vorschlag formuliert ist.
- SAP führt aus. Und zwar über die Standardwege: Customizing im Transport, Belege über die zulässigen Bausteine, IDocs über die Partnervereinbarung. Kein Direktschreiben in Tabellen, kein Weg am Transportwesen vorbei.
Der Nutzen liegt in der Prüfbarkeit. Jeder Schritt hinterlässt einen Vorschlag, eine Regelentscheidung und ein Protokoll. Damit lässt sich hinterher beantworten, wer was warum geändert hat — die Frage, an der KI-Vorhaben in regulierten Häusern sonst scheitern.
Wie viel Autonomie das Werkzeug bekommt, ist eine Entscheidung des Kunden und keine Eigenschaft der KI. In der ersten Stufe liest es nur und schlägt vor. In der zweiten setzt es einen freigegebenen Vorschlag um. In der dritten arbeitet es innerhalb eines eng abgesteckten Rahmens selbständig. Ich fange grundsätzlich mit der ersten Stufe an.
KI-gestützte Rollouts: wo sie trägt
- Bestandsaufnahme. Den tatsächlichen Customizing-Stand lesend auswerten und lesbar machen — was eingestellt ist, nicht was dokumentiert wurde.
- Fit-Gap-Vorbereitung. Ist-Stand gegen Template stellen und eine Kandidatenliste der Abweichungen erzeugen. Die Bewertung bleibt beim Menschen, die Fleißarbeit davor nicht.
- Testfälle. Aus Prozessbeschreibung und Konfiguration Testfallgerüste ableiten, einschließlich der Varianten, die man von Hand auslässt.
- Dokumentation. Blueprint, Beraterdokumentation und Key-User-Unterlagen aus dem Systemstand statt aus dem Gedächtnis — mit Belegstelle je Aussage.
- Fehleranalyse. Meldungen, Belege und Konfiguration nebeneinanderlegen und Hypothesen ordnen, bevor jemand debuggt.
Und wo sie nicht trägt
Die Entscheidung im Customizing trifft kein Modell. Ob eine Abweichung ins Template gehört, ob der Prozess geändert wird statt des Systems, ob ein Risiko tragbar ist — das sind Abwägungen mit Folgen für Jahre, und dafür gibt es einen Verantwortlichen mit Namen. Ebenso wenig ersetzt ein Modell den Test: Ein Vorschlag ist erst dann richtig, wenn der Beleg durchläuft.
Dazu eine Frage, die vor die Technik gehört: Was wird dem Modell überhaupt gegeben, in welchem Umfang, und bei wem läuft es. Der Weg über den eigenen Tenant des Kunden ist meist der einfachste, weil dann nichts Neues zu genehmigen ist.
Schulungen: über KI und mit KI
Die Schulung über KI richtet sich an SAP-Teams und an die, die dafür geradestehen müssen: Was ist ein Gate, wie sieht ein gegateter Ablauf im SAP aus, welche Aufgaben eignen sich und welche nicht, und welche Fragen stellt die eigene Sicherheitsabteilung zu Recht. Ergebnis ist eine Haltung, mit der ein Haus KI-Vorhaben beurteilen kann, statt sie pauschal zu verbieten oder pauschal zu erlauben.
Die Schulung mit KI ist ein Konzept, das ich gemeinsam mit dem Kunden erstelle. Ausgangspunkt ist vorhandenes Material — eine Beraterdokumentation, ein Blueprint, eine Key-User-Unterlage. Daraus entsteht eine Videolektion mit einem befragbaren KI-Trainer: Der Teilnehmer sieht die Lektion und kann in derselben Oberfläche nachfragen, in eigenen Worten und in seinem Tempo.
Entscheidend ist die Belegpflicht: Der Trainer antwortet nur aus dem Kursinhalt und weist die Stelle aus, auf die er sich stützt. Wofür es keine Stelle gibt, beantwortet er nicht, sondern verweist auf den Fachverantwortlichen. Dasselbe Gate-Prinzip wie oben, angewandt auf Wissen statt auf Änderungen.
Gemeinsam festzulegen ist, welche Unterlagen hineingehen, in welchen Sprachen, wer den Kursinhalt fachlich abnimmt, wie Aktualisierungen laufen und wo das Ganze betrieben wird. Das ist die Konzeptarbeit, und sie steht vor jeder Produktion.
Vorführen lässt sich das alles, statt es zu beschreiben — siehe Live-Demos und POC. Wenn Sie ein konkretes Vorhaben haben, beschreiben Sie es in ein paar Sätzen: welcher Prozess, welches System, und was heute daran von Hand gemacht wird. Im ersten Gespräch sage ich, ob sich der Aufwand lohnt.