KI-Anbindung an SAP S/4HANA: Was sie wirklich bringt – und wie ein sicherer Einstieg aussieht

Sie macht sichtbar, was in der Landschaft steckt: Custom Code, offene Transporte, gewachsene Konfiguration. Daraus entstehen belastbare Planungsgrundlagen für Upgrades und Migrationen, technische Dokumentation, die vorher fehlte, und deutlich kürzere Schleifen bei Konzeption und Prüfung. Der Nutzen liegt in der Transparenz, nicht in der Automatisierung von Buchungen. Diese Abgrenzung ist der wichtigste Satz zum Thema, weil die Erwartung meist eine andere ist. Praktisch messbar wird der Nutzen an drei Stellen: bei der Aufwandsschätzung für ein Upgrade oder eine Migration, weil erstmals bekannt ist, wie viel Eigenentwicklung tatsächlich noch genutzt wird; bei der Einarbeitung neuer Kolleginnen und Kollegen in eine Landschaft ohne Dokumentation; und bei der Fehlersuche, wenn niemand mehr weiß, warum eine Erweiterung vor zwölf Jahren gebaut wurde. Alle drei Punkte sind heute Personenwissen und werden damit zu Systemwissen, das im Haus bleibt, wenn jemand geht.

Nein. Für Transparenz über Code und Konfiguration genügen Customizing- und Systeminformationen; Bewegungs- und Stammdaten bleiben außen vor. Diese Einschränkung sollte über die Berechtigungen eines eigenen technischen Benutzers im System selbst erzwungen werden, nicht über eine Absichtserklärung. Der Unterschied ist wesentlich: Was technisch nicht lesbar ist, kann auch nicht versehentlich mitgelesen werden, und genau das ist gegenüber Datenschutzbeauftragten und Prüfern belegbar. Drei Festlegungen gehören dazu, bevor der erste Zugriff erfolgt: ein eigener technischer Benutzer nur für diesen Zweck, ausschließlich lesende Rechte, und die Beschränkung auf Entwicklungs- und Testsysteme. Ein Zugriff auf das Produktivsystem ist für Transparenz über Code und Konfiguration in der Regel nicht erforderlich, weil Code und Customizing dort identisch mit dem Entwicklungssystem sind. Wer ihn trotzdem einrichten will, sollte begründen können, welche Frage sich anders nicht beantworten lässt. Diese Begründung schriftlich zu verlangen, ist in geprüften Umgebungen ohnehin üblich.

Ein lesender Zugriff auf Entwicklungs- und Testsysteme mit protokollierten Zugriffen und getrennten Berechtigungsstrukturen ist in regulierten Umgebungen darstellbar. Entscheidend ist, dass Zugriffe nachvollziehbar sind und die Auswertungen strukturiert abgelegt werden – daraus entsteht die Nachweisstruktur, die eine Prüfung verlangt. Die konkrete Bewertung trifft immer Ihre Qualitätssicherung, und wir formulieren das ausdrücklich so – eine Freigabe können wir nicht erteilen und würden es auch nicht behaupten. Was wir liefern, ist die Grundlage für diese Bewertung: eine Beschreibung des Zugriffswegs, der eingesetzten Berechtigungen, der protokollierten Zugriffe und der Ablage der Auswertungen. Erfahrungsgemäß entscheidet weniger die Technik als die Nachweisbarkeit: Ein Verfahren, das lückenlos zeigt, wer wann was gelesen hat und wo das Ergebnis liegt, wird in regulierten Umgebungen deutlich häufiger freigegeben als eines, das nur zusichert, sich zu beschränken. Die Nachweise entstehen dabei nebenbei und müssen nicht nachträglich rekonstruiert werden.

Die Frage stellt sich nicht als Entweder-oder. SAP Joule spielt seine Stärke bei customizing- und systembezogenen Fragen im SAP-Kontext aus und ist in aktuellen SAP-Lizenzmodellen häufig bereits enthalten, ohne dass zusätzliche Kosten entstehen. Allgemeine KI-Assistenten sind stärker, wenn über viele Objekte hinweg analysiert, dokumentiert oder konzipiert wird. Wichtig ist eine schriftliche Einsatzrichtlinie, die beides abgrenzt. Sie muss nicht umfangreich sein; eine Seite genügt, wenn sie vier Fragen beantwortet: Welches Werkzeug ist für welche Aufgabe vorgesehen, welche Daten dürfen dabei jeweils verarbeitet werden, wer gibt neue Anwendungsfälle frei, und wie werden Ergebnisse abgelegt. Der praktische Grund für die Schriftform ist banal und trifft trotzdem zu: Ohne Richtlinie entscheidet jeder Mitarbeiter selbst, welches Werkzeug er mit welchen Inhalten benutzt, und diese Entscheidungen sind hinterher nicht rekonstruierbar. Die Richtlinie ist damit weniger eine Vorschrift als eine Entlastung.

Mit zwei bis drei konkreten Fragen, die heute Zeit kosten, und mit dem Sicherheits- und Berechtigungskonzept. Gerade bei schlanken Organisationen zahlt sich Enablement aus: Das Ziel ist ein Team, das die Auswertungen anschließend selbst fährt, statt für jede Frage extern einzukaufen. Staufenberg Advisory begleitet diesen Einstieg mit SAP-Experten, die auch im Konzernumfeld arbeiten. Für den ersten Schritt hat sich eine Reihenfolge bewährt, die ohne Budgetfreigabe auskommt: Notieren Sie zwei Wochen lang, welche Fragen im Team Zeit gekostet haben und nirgends dokumentiert beantwortbar waren. Diese Liste ist die belastbarste Grundlage für die Auswahl der ersten Anwendungsfälle, und sie kostet nichts. Vermeiden Sie dagegen den verbreiteten Einstieg über eine Werkzeugauswahl: Bei zwei bis drei klar benannten Fragen ergibt sich das Werkzeug fast von selbst, während umgekehrt eine Lizenz ohne Anwendungsfall im Haus liegen bleibt.

Der Aufwand hängt von der Zahl der Anwendungsfälle, den Anforderungen an Sicherheit und Nachweisführung sowie dem gewünschten Umfang des Enablements ab. Staufenberg Advisory liefert nach dem Erstgespräch innerhalb von fünf Werktagen eine unverbindliche Aufwandsindikation für Ihr Vorhaben. Für die eigene Budgetplanung lohnt es sich, drei Blöcke getrennt zu betrachten. Erstens die Einrichtung samt Sicherheits- und Berechtigungskonzept, ein einmaliger Aufwand. Zweitens die Lizenzen, wobei SAP Joule in aktuellen Lizenzmodellen häufig bereits enthalten ist und dann keine zusätzlichen Kosten verursacht – das gehört geprüft, bevor etwas beschafft wird. Drittens das Enablement, also die Befähigung Ihres Teams. Es macht den größten Anteil aus und bestimmt gleichzeitig die laufenden Kosten der Folgejahre: Ein Team, das die Auswertungen selbst fährt, braucht danach keine externe Begleitung mehr, und genau das ist das Ziel. Ein Aufwand, der sich jedes Jahr wiederholt, wäre schlecht angelegt.

Das lässt sich so gestalten. In vielen Vorhaben verbleiben Hosting und Betrieb der Komponenten beim Unternehmen selbst, während Konzeption, Einrichtung und Befähigung extern begleitet werden. Wer den Betrieb abgeben will, kann das ebenfalls vereinbaren – die Entscheidung sollte bewusst fallen und nicht nebenbei. Zwei Kriterien helfen dabei mehr als eine Kostenrechnung. Erstens die Frage, wer im Störungsfall handlungsfähig ist: Liegt der Betrieb im Haus, brauchen Sie mindestens zwei Personen, die die Umgebung kennen, sonst haben Sie den Engpass nur verschoben. Zweitens die Frage, wie oft sich die Umgebung ändert – bei häufigen Anpassungen ist die Nähe zum eigenen Team von Vorteil, bei einem stabilen Aufbau eher die Verlagerung. Wir legen die Aufteilung schriftlich fest, damit im Störungsfall keine Zuständigkeitsfrage entsteht. Erfahrungsgemäß ist das die Festlegung, die am häufigsten fehlt und im Ernstfall am meisten Zeit kostet.