SAP-Orchestrierung erklärt: Tools, Einsatzbereiche und Best Practices (2026)

Was ist SAP-Orchestrierung? Eine einfache Definition

Zunächst ist es wichtig, zwei Dinge voneinander zu unterscheiden, die häufig unter demselben Begriff zusammengefasst werden. „SAP-Orchestrierung“ hat 2026 zwei unterschiedliche Bedeutungen. Wer sie verwechselt, spricht schnell mit dem falschen Anbieter über das falsche Thema.

Dieser Leitfaden konzentriert sich hauptsächlich auf die erste Bedeutung, SAP Process Orchestration, da IT-Teams heute meist genau das meinen, wenn sie nach „SAP-Orchestrierung“ suchen.

Die zweite Bedeutung ist neuer und gewinnt schnell an Bedeutung, da immer mehr Unternehmen KI-Agenten auf Basis von SAP-Daten entwickeln. Deshalb gehen wir an den relevanten Stellen kurz darauf ein.

SAP Process Orchestration: Die Kernkomponenten im Überblick

SAP Process Orchestration fasst drei separate SAP-Tools in einer integrierten Plattform innerhalb der NetWeaver-Produktfamilie zusammen. Sie fungiert als zentrale Integrations- und Automatisierungsebene für Geschäftsprozesse und unterstützt sowohl einfache zweistufige Freigaben als auch systemübergreifende Workflows, die fünf verschiedene Anwendungen einbeziehen.

Richtig eingesetzt reduziert sie die manuelle Dateneingabe, verbessert die Datenqualität und senkt die Gesamtkosten für die Pflege von Punkt-zu-Punkt-Integrationen. SAP PO umfasst drei Kernkomponenten. Zu verstehen, welche Aufgabe jede davon übernimmt, bildet die Grundlage für die weiteren Abschnitte dieses Leitfadens.

SAP Business Process Management (BPM)

BPM dient dazu, Geschäftsprozesse durchgängig zu modellieren, zu gestalten, auszuführen und zu überwachen. Die abgebildeten Workflows reichen von einfachen Freigabeketten bis hin zu komplexen Prozessen über mehrere Systeme hinweg, die sowohl automatisierte Schritte als auch manuelle Aufgaben umfassen.

Ein typischer Anwendungsfall ist die Automatisierung eines Purchase-to-Pay-Prozesses: Eine Bestellanforderung löst einen Freigabe-Workflow aus, wird abhängig vom Ausgabenlimit an die zuständige Person weitergeleitet und stößt nach der Freigabe automatisch die nachgelagerten Schritte in Einkauf und Finanzwesen an, ohne dass Daten manuell erneut eingegeben werden müssen. Workflows für die Rechnungsfreigabe folgen einem ähnlichen Muster.

Vereinfacht gesagt bedeutet das: weniger manuelle Übergaben, weniger Spielraum für Fehler bei der Dateneingabe und kürzere Durchlaufzeiten bei Prozessen, die früher davon abhingen, dass jemand daran dachte, eine E-Mail weiterzuleiten.

SAP Process Integration (PI) und AEX

PI ist die Middleware-Schicht, über die unterschiedliche Systeme miteinander kommunizieren können, unabhängig davon, ob es sich um SAP- oder Non-SAP-Systeme handelt. Sie übernimmt das eigentliche Nachrichten-Routing, die Protokollübersetzung und das Daten-Mapping zwischen verschiedenen Endpunkten.

Die Advanced Adapter Engine Extended (AEX) ist die Konnektivitätskomponente innerhalb von PI. Sie übernimmt die adapterbasierte Kommunikation und das Nachrichten-Routing, ohne dass dafür eine vollständige Dual-Stack-PI-Installation erforderlich ist.

PI ist eine Komponente innerhalb von SAP PO, aber kein Synonym für die gesamte Plattform.

Im alltäglichen Sprachgebrauch werden beide Begriffe häufig synonym verwendet, technisch handelt es sich jedoch nicht um dasselbe.

Ein praktisches Beispiel ist die Verbindung eines SAP-ERP-Systems mit einem externen Logistikdienstleister oder CRM-System. PI übersetzt dabei zwischen den SAP-Datenformaten und dem vom externen System erwarteten Format und sorgt für eine zuverlässige Nachrichtenübermittlung, selbst wenn eines der beteiligten Systeme vorübergehend nicht verfügbar ist.

SAP Process Orchestration vs. SAP Integration Suite: Die wichtigsten Unterschiede

Das ist derzeit eine der häufigsten Fragen für SAP-Teams und sie verdient mehr als eine oberflächliche Antwort. Angesichts des nahenden Wartungsendes von PO müssen viele Teams entscheiden, ob sie zunächst bei PO bleiben, auf SAP Integration Suite migrieren oder sich vollständig außerhalb des SAP-Stacks orientieren.

Der Vergleich lässt sich anhand von drei zentralen Aspekten betrachten: Architektur, Zukunftsfähigkeit und Deployment-Modell.

Zentrale funktionale Unterschiede

Der grundlegende Unterschied liegt in der Architektur. SAP PO ist eine auf NetWeaver basierende On-Premises-Middleware, während SAP Integration Suite eine Cloud-native iPaaS auf SAP BTP ist. Das ist kein nebensächliches technisches Detail. Es verändert die Art und Weise, wie die Plattform bereitgestellt, skaliert, gepatcht und abgerechnet wird.

SAP macht deutlich, in welche Richtung die Entwicklung geht: Integration Suite ist der strategische Nachfolger von PO und keine parallele Alternative. In der SAP-Roadmap löst sie PO ab. Neue Integrationsfunktionen, KI-Features und Tools für das API-Management werden daher für Integration Suite entwickelt, nicht für PO.

Das bedeutet nicht, dass jedes Unternehmen sofort migrieren sollte. Wenn Ihre Umgebung noch überwiegend auf SAP ECC basiert und PO eine überschaubare Anzahl an Integrationen übernimmt, fällt die Entscheidung anders aus als bei einem Unternehmen, das sich mitten in der Migration auf S/4HANA befindet und Integrationen für eine Plattform entwickelt, die noch ein weiteres Jahrzehnt genutzt werden soll.

Welche Lösung passt zu Ihrem Unternehmen?

Die Entscheidung lässt sich vereinfacht so einordnen:

• Sie nutzen weiterhin Legacy-ECC und möchten vorerst dabei bleiben: PO kann innerhalb des bestehenden Wartungszeitraums weiterlaufen. Neue Integrationsprojekte sollten Sie jedoch als Gelegenheit nutzen, Integration Suite zu pilotieren, anstatt weitere Logik zu einer Plattform mit feststehendem Enddatum hinzuzufügen.

• Sie migrieren aktiv auf S/4HANA: Entwickeln Sie neue Integrationen von Anfang an auf Integration Suite. PO-basierte Integrationen nach einem S/4HANA-Go-live nachträglich umzustellen, verursacht zusätzliche Kosten, die sich durch eine passende Reihenfolge der Migrationsschritte vermeiden lassen.

• Sie betreiben hybride SAP- und Non-SAP-Umgebungen: Hier wird die Entscheidung komplexer. Integration Suite eignet sich gut für SAP-to-Cloud- und SAP-to-SAP-Integrationen. Die Koordination von SAP-Prozessen mit der übrigen Enterprise-IT, darunter Job Scheduling, Dateiübertragungen, DevOps-Pipelines und Non-SAP-Anwendungen, ist jedoch eine andere Herausforderung, die iPaaS-Tools allein nicht lösen sollen. Mehr dazu weiter unten.

SAP Process Orchestration End of Life: Was das bedeutet und wie Sie sich vorbereiten

Die Mainstream-Wartung für SAP Process Orchestration endet am 31. Dezember 2027. Eine kostenpflichtige Extended Maintenance ist laut der SAP-eigenen Aktualisierung der Wartungsstrategie für NetWeaver 7.5 bis Ende 2030 möglich. Nach Ablauf der Mainstream-Wartung erhält PO keine regulären Wartungsleistungen mehr, sofern keine Extended Maintenance vereinbart wurde.

In diesem Abschnitt geht es um den Zeitplan und die damit verbundenen Risiken, nicht um den Funktionsumfang.

Der Wartungszeitplan, den Sie berücksichtigen müssen

SAP hat bereits 2020 bestätigt, dass die Wartungszeiträume von PO und PI an den übergeordneten Zeitplan für NetWeaver 7.5 und SAP Business Suite 7 angepasst werden. Die Mainstream-Wartung läuft bis Ende 2027, optional gefolgt von Extended Maintenance bis Ende 2030. Aktuelle Einschätzungen weisen ebenfalls darauf hin, dass Unternehmen, die PI/PO einsetzen, ihre Migration rechtzeitig planen sollten. Weitere Informationen bietet die Analyse von Auritas zur Vorbereitung auf das Support-Ende von SAP PI/PO.

2027 klingt weit entfernt, bis man diesen Termin mit der typischen Projektdauer von 12 bis 18 Monaten für die Migration einer Plattform vergleicht, auf der geschäftskritische Integrationen laufen. Das ist er nicht.

Die geschäftlichen Risiken des Abwartens

Nicht mehr unterstützte Middleware weiterzubetreiben, kann schnell zum Audit-Risiko werden. Nach dem Ende der regulären Wartung können neu entdeckte Schwachstellen in PO ohne entsprechende Extended Maintenance ungepatcht bleiben. Das erhöht die Risiken für eine Plattform, die häufig eine zentrale Rolle in Finanzabschlussprozessen, Order-to-Cash-Abläufen und anderen regulatorisch relevanten Prozessen spielt.

Extended Maintenance verschafft zusätzliche Zeit, ist aber als Übergang gedacht und nicht als dauerhafte Lösung. Zudem bringt sie keine Weiterentwicklung des Funktionsumfangs zurück.

Ein weniger offensichtliches Risiko ist die Konzentration von Wissen auf wenige Personen. PO-Implementierungen sammeln über zehn Jahre oder länger häufig individuelle Adapter, BPM-Prozesse und BRM-Regeln an, die von einer kleinen Zahl von Spezialistinnen und Spezialisten entwickelt wurden. Wenn diese Personen in den Ruhestand gehen oder das Unternehmen verlassen, wächst die Dokumentationslücke oft schneller als erwartet.

Ihre Migrationsoptionen

Unternehmen, die sich auf das Wartungsende von PO vorbereiten, entscheiden sich in der Regel für einen von drei Wegen:

1. Migration auf SAP Integration Suite: Sie folgen damit dem von SAP vorgesehenen Weg, insbesondere wenn Sie bereits auf S/4HANA und eine Clean-Core-Strategie setzen.

2. Extended Maintenance bis 2030: Sie nutzen die kostenpflichtige Wartungsverlängerung bewusst als Übergangslösung. Dies ist vor allem dann sinnvoll, wenn PO im Rahmen eines größeren S/4HANA-Transformationsprogramms stabil weiterlaufen muss, während andere Workstreams noch nicht abgeschlossen sind.

3. Integration und Orchestrierung getrennt neu aufstellen: Die reine System-zu-System-Integration wird in Integration Suite verlagert, während systemübergreifendes Job Scheduling, Abhängigkeitsmanagement und Hybrid-Cloud-Orchestrierung von einer dafür entwickelten Workload-Automation-Plattform übernommen werden.

Dieser Ansatz kommt zunehmend bei Unternehmen zum Einsatz, in denen PO faktisch sowohl als Integrationstool als auch als Job Scheduler genutzt wurde.

Keine dieser Entscheidungen ist rein technischer Natur. Jede Option bringt unterschiedliche Kostenverläufe, Risikoprofile und Anforderungen an interne Kompetenzen mit sich. Deshalb führen die meisten Unternehmen zunächst eine kurze Assessment-Phase durch, bevor sie sich auf einen Weg festlegen.

Über PO hinaus: Warum die Integrationsbreite für die SAP-Orchestrierung entscheidend ist

SAP Integration Suite löst die Integration zwischen SAP-Systemen sowie zwischen SAP und Cloud-Systemen gut.

Was sie nicht allein löst, ist die umfassendere Orchestrierungsfrage, vor der viele Enterprise-IT-Teams stehen:

Wie lassen sich SAP-Prozesse gemeinsam mit allen anderen Workloads in der eigenen Umgebung koordinieren, von Cloud-nativen Datenpipelines über Kubernetes-Workloads bis zu Legacy-Mainframe-Jobs, und zwar über eine zentrale Steuerungsebene statt über fünf voneinander getrennte?

Wer Tools für die SAP-Orchestrierung ausschließlich anhand ihrer Middleware-Architektur bewertet, übersieht deshalb einen wichtigen praktischen Faktor: die Integrationsbreite. Der tatsächliche Nutzen einer Orchestrierungsplattform zeigt sich darin, wie viele Systeme sie standardmäßig anbinden kann und wie viel individuelles Scripting sich dadurch vermeiden lässt.

Bei der Bewertung einer Plattform anhand dieser Kriterien lohnt sich ein Blick auf folgende Punkte:

• Native SAP-Abdeckung über PI/PO hinaus. Kann die Plattform SAP S/4HANA, sowohl On-Premises als auch in der Cloud, BTP, RISE und GROW with SAP direkt über standardisierte, von SAP unterstützte Schnittstellen wie BAPI, OData und RFC anbinden? Oder ist sie auf individuelle Skripte und anfällige Punkt-zu-Punkt-Verbindungen angewiesen?

• Abdeckung außerhalb der SAP-Landschaft. SAP läuft nur selten isoliert. Cloud-Plattformen wie AWS, Microsoft Azure und Google Cloud, Tools für Datenpipelines wie dbt und Azure Data Factory, Container-Plattformen, ITSM-Tools und Systeme für das Secret Management gehören in der Regel zur selben Betriebslandschaft wie Ihre SAP-Systeme.

• Umfang vorgefertigter Konnektoren im Vergleich zum individuellen Entwicklungsaufwand. Der Unterschied zwischen „rund 500 Integrationen“ und „über 600 Integrationen“ sieht auf dem Datenblatt vielleicht gering aus. In der Praxis kann er jedoch darüber entscheiden, ob ein neues System innerhalb eines Nachmittags angebunden werden kann oder dafür individuelle Middleware entwickelt werden muss.

Beta Systems verfolgt mit ANOW! Automate einen Ansatz aus Sicht der Workload Automation und Orchestrierung und nicht aus der reinen iPaaS-Perspektive.

ANOW! Automate bindet SAP S/4HANA und SAP S/4HANA Cloud nativ über standardisierte SAP-Webservices, BAPI-Aufrufe, OData-APIs und RFC an. Dadurch wird ein Clean-Core-Ansatz unterstützt, anstatt anfällige individuelle Skripte nah am SAP Core einzusetzen.

Über SAP hinaus deckt der Integrations Hub von ANOW! Automate zahlreiche sofort einsetzbare Konnektoren für Cloud-Plattformen, DevOps- und Container-Tools, Datenpipeline-Systeme, ITSM-Plattformen und Secret-Management-Systeme ab.

Für Teams, die neben ihrer SAP-Middleware auch ihr Legacy-Scheduling modernisieren, behandeln unser Leitfaden zur Migration von Broadcom Automic und unsere Inhalte zu Community-basierten Frameworks wie Apache Airflow angrenzende Themen.

Das Ergebnis ist eine zentrale Steuerungsebene, über die SAP-Jobs gemeinsam mit allen umgebenden Systemen orchestriert werden können. SAP-Integration und unternehmensweite Job-Orchestrierung müssen damit nicht länger als zwei voneinander getrennte Herausforderungen behandelt werden, für die jeweils unterschiedliche Tools erforderlich sind.

FAQs

1. Erreicht SAP Process Orchestration das End of Life?

Ja. Die Mainstream-Wartung endet am 31. Dezember 2027. SAP bietet eine kostenpflichtige Extended Maintenance bis Ende 2030 an.

2. Wie viel kostet SAP Process Orchestration?

SAP PO verursacht für bestehende NetWeaver-Kunden in der Regel keine separate Lizenzgebühr, sondern ist üblicherweise Bestandteil der bestehenden SAP-Lizenzierung. Extended Maintenance nach 2027 verursacht zusätzliche Kosten. Einen pauschalen öffentlichen Preis gibt SAP nicht an, da die Kosten vom jeweiligen Vertrag abhängen.

3. Was ist nach dem Ende der Wartung die beste Alternative zu SAP PO?

Das hängt davon ab, welche Aufgabe Sie lösen möchten. Für reine SAP-Integration und API-Management ist SAP Integration Suite der von SAP vorgesehene Weg. Für die Koordination von SAP-Jobs gemeinsam mit einer umfassenderen hybriden IT-Landschaft eignet sich häufig eine dedizierte Plattform für Workload Automation und Orchestrierung besser, als Integrations-Middleware als Job Scheduler einzusetzen.

4. Was ist SAP-BTP-Orchestrierung und wie unterscheidet sie sich von SAP PO?

SAP-BTP-Orchestrierung bezieht sich in der Regel auf Integration Suite für die Systemintegration oder auf den Orchestration Service innerhalb von SAP AI Core für die Koordination generativer KI-Workflows. Beide laufen auf der SAP Business Technology Platform. SAP PO hingegen ist eine separate On-Premises-Middleware auf Basis von NetWeaver, die schrittweise zugunsten dieser Cloud-native BTP-Services abgelöst wird.

5. Ersetzt SAP Integration Suite SAP PO für Job Scheduling und Workload Automation?

Nein. Integration Suite ist für System-zu-System-Integration und API-Management ausgelegt, nicht für Job Scheduling, die Verwaltung von Abhängigkeiten oder die plattformübergreifende Workload-Orchestrierung. Unternehmen, die PO faktisch als Scheduler einsetzen, benötigen deshalb in der Regel zusätzlich zu Integration Suite eine dedizierte Workload-Automation-Plattform.