So bleiben Unternehmensintegrationen bei der Migration auf SAP S/4HANA stabil

Eine SAP-Migration ist auch ein Integrationsprojekt. Wenn angebundene Systeme über eine Integrationsschicht mit SAP kommunizieren, kann diese Schicht einen großen Teil der Änderung auffangen. Bei den meisten der 30 bestehenden Schnittstellen, grob geschätzt 80 %, hielten angepasste Mappings jede Schnittstelle genau so, wie sie war, und die aufrufenden Systeme bekamen von der Umstellung nichts mit.

Eine Migration auf SAP S/4HANA ist auch ein Integrationsprojekt, weil jedes System, das Daten mit SAP austauscht, von dessen Datenstrukturen und Schnittstellen abhängt. Wird das ERP-System ersetzt, muss jede dieser Verbindungen geprüft, angepasst oder neu gebaut werden.

In diesem Projekt tauschten 18 Systeme und Konsumenten über Scheer PAS Daten aus, darunter SAP S/4HANA selbst, die Enterprise Data Platform (früher Data Warehouse), Datenbanken, Händlersysteme, Dach- und Landesgesellschaften, Agenturen, Behörden, Dienstleister, Personalmanagement- und Benutzerverwaltungssysteme, Blob Storage, Job-Steuerung, ein Onlineshop, Banken, Versicherungen und Mobilitätsdienstleister.

Nur wenige davon können sich nach dem Zeitplan der Migration richten. Eine Bank, eine Behörde oder eine externe Agentur passt ihre Schnittstelle selten an, weil einer ihrer Partner sein ERP-System migriert.

Bei den meisten der 30, grob geschätzt 80 %, passte das Team die Mappings in Scheer PAS so an, dass jede Schnittstelle genau so aussah wie vor der Umstellung. Die aufrufenden Systeme bekamen von der Migration nichts mit. Wie wichtig das war, zeigen die Schnittstellen zu einer Bank im Konzern: Dort laufen viele Legacy-Anwendungen, deshalb mussten ihre Schnittstellen genau so bleiben, wie sie waren. Bei wenigen Schnittstellen war das wegen grundsätzlicher Änderungen an den SAP-Datenstrukturen nicht möglich. Dort hat das Team zuerst versucht, nur die nötigen Änderungen in die bestehenden Schnittstellen einzuarbeiten, und wo auch das nicht ging, komplett neue Schnittstellen gebaut. 

Das ist das Kernargument für eine Integrationsschicht bei einer Migration. Jede Schnittstelle hat einen Vertrag mit den Systemen, die sie nutzen. Hält der Vertrag, bleibt die Migration für diese Systeme ein SAP-Projekt. Bricht er, wird jeder Konsument Teil der Migration. Eine stabile Struktur macht End-to-End-Tests nicht überflüssig, denn Werte und Bedeutungen können sich mit SAP S/4HANA trotzdem ändern. Aber sie macht aus einem Neubau einen Regressionstest.

Viele verschiedene Technologien lassen sich bei einer SAP-Migration leichter beherrschen, wenn alle über eine Integrationsschicht laufen. Jedes System behält sein eigenes Protokoll und Format. Die Integrationsschicht übersetzt dazwischen, sodass die Migration mit einem Satz an Mappings, Patterns und Monitoring auskommt statt mit einem pro Technologie. 

In diesem Projekt waren das fünf Arten von Verbindungen: moderne APIs über REST und OData, etablierte Unternehmensschnittstellen wie SOAP-Services und SAP Remote Function Calls (RFC), nachrichtenbasierte Kommunikation über JMS, SQL-Zugriff auf Datenbanken und dateibasierter Austausch. Die Daten kamen als XML, JSON oder Flatfiles, und für Robotic Process Automation (RPA) wurde UiPath eingesetzt. 

Wiederkehrende Integrations-Patterns und wiederverwendbare Libraries sorgten dafür, dass nicht jede Verbindung für dasselbe Problem eine eigene Lösung brauchte.

Logging, Monitoring und wiederverwendbares Design sind bei einer SAP-Migration wichtig, weil eine Schnittstelle, die am Tag des Go-live funktioniert, danach auch weiter funktionieren muss. Im Projekt wurde ein zentrales, einheitliches Logging und Monitoring über die Schnittstellen aufgebaut. Damit gibt es einen Ort, an dem die Aktivität aller Schnittstellen protokolliert und überwacht wird, unabhängig vom Protokoll. 

Integrations-Patterns und wiederkehrende Designs wurden über alle Verbindungen hinweg angewendet, und gemeinsame Funktionen wurden in wiederverwendbaren Libraries gebündelt. Bei 180 Schnittstellen zählt das. Ein bekanntes Pattern muss nicht für jede Verbindung neu erfunden werden, und eine Änderung an einer Library erreicht jede Schnittstelle, die sie nutzt. Deshalb brauchen Library-Änderungen auch Versionierung und Regressionstests.

Sobald KI-Agenten eigenständig Aktionen über mehrere Systeme hinweg ausführen, werden klare Regeln für Zugriff, Validierung und Nachvollziehbarkeit besonders wichtig. Ein Agent, der SAP direkt aufruft, umgeht die Mappings, die Validierung und das Logging, auf die sich alle anderen Konsumenten verlassen. Er kann Daten in einer Form schreiben, die eine Bankschnittstelle, ein Händlersystem oder die Enterprise Data Platform nicht erwartet, ohne dass ein zentraler Logeintrag zeigt, woher sie kamen. 

Die Migration hat eine Grundlage geschaffen, auf der ein Agent aufbauen könnte: definierte Schnittstellen, Mappings, zentrales Logging und wiederverwendbare Libraries. Agentic Orchestration kann Aufgaben über mehrere Systeme hinweg koordinieren, während die Integrationsschicht die technische Kommunikation mit ihnen übernimmt. Patterns und Libraries wie diese können als kontrollierte Bausteine für Agenten dienen, statt dass jeder Agent seine eigene Verbindung baut. In Scheer PAS sind Agenten, die mit PAS Code gebaut werden, ein Feature eines Service: Sie haben keinen eigenen Endpunkt und sind nur über diesen Service erreichbar. 

In diesem Projekt wurden keine KI-Agenten eingesetzt. Die hier beschriebene Integrationsgrundlage ist eine Voraussetzung für ihren späteren Einsatz. 

Je mehr Systeme ein KI-Agent einbezieht, desto wichtiger werden technische und organisatorische Schutzmechanismen entlang der Integrationskette. Daten, die ein Agent in falscher Form schreibt, können jeden Konsumenten einer Schnittstelle erreichen. Drei Guardrails sind hier am wichtigsten. 

Berechtigungsgrenzen pro System.

Ein Agent sollte nur bestimmte Operationen auf bestimmten Systemen aufrufen dürfen. Ein Agent könnte zum Beispiel Auftragsdaten aus SAP S/4HANA lesen dürfen, aber nicht in die Bank- oder Versicherungsschnittstellen schreiben. 

Validierung vor dem Zielsystem.

Daten sollten in der Integrationsschicht validiert und umgewandelt werden, bevor sie SAP oder ein angebundenes System erreichen, und zwar gegen dieselben Strukturen, die die bestehenden Konsumenten erwarten. 

Freigabe für irreversible Aktionen.

Buchungen, Zahlungen oder Daten, die an externe Partner gehen, sollten auf die Freigabe durch einen Menschen warten. 

Wie Scheer PAS festlegt, welche Operationen ein Agent ausführen darf, und welche allgemeinen Anforderungen an Governance für KI-Agenten gelten, beschreibt KI-Agenten-Governance: Warum Agentic Orchestration eine kontrollierte Integrationsschicht braucht.