Wie SAP Build Process Automation mit der S/4HANA Public Cloud zusammenarbeitet: Ein Praxisbeispiel

Prozesse einfach und ohne tiefgehende Programmierkenntnisse zu modellieren und zu automatisieren – das verspricht SAP Build Process Automation, kurz SBPA. Doch was kann die Lösung im Zusammenspiel mit der SAP S/4HANA Public Cloud? Wie haben es uns angeschaut und anhand eines Praxisbeispiels durchexerziert.

 

Die Digitalisierung von Geschäftsprozessen steht bei vielen Unternehmen ganz oben auf der Agenda. Mit der SAP Build Process Automation (SBPA) bietet SAP leistungsfähige Low-Code-Services, die es Anwender:innen ermöglichen, Prozesse effizient zu modellieren und zu automatisieren – ganz ohne Entwicklerkenntnisse und Source Coding. Klingt prima, also gleich zugreifen?

Die grundlegende Frage, die beim Blick auf SAP BPA Hand in Hand geht: Kauft man eine fertige Lösung mit klar definierten Funktionen oder entwickelt man selbst etwas? Wie so oft ist heute die Antwort auf diese Frage meist nicht mehr nur ein Entweder-Oder zwischen SAP-Standard und klassischer Eigenentwicklung in ABAP – speziell, da SAP neben SBPA auch noch andere Umsetzungs-Möglichkeiten wie das RESTful Application Programming Model (RAP) oder auch das Cloud Application Programming Model (CAP) liefert, welche unterschiedliche Ansätze für die Entwicklung von Cloud-nativen Erweiterungen bieten.

Wir haben daher die Probe aufs Exempel gemacht und einen internen Use Case aufgesetzt, um zu zeigen, wie SBPA gemeinsam mit der SAP S/4HANA Public Cloud eingesetzt werden kann, um Prozesse zu optimieren und die Reaktionsgeschwindigkeit zu erhöhen.

Unser Use Case: Kundenbenachrichtigung bei Sales Ordern

Es ist ein Fall, wie er im Unternehmensalltag oft vorkommt: Immer, wenn eine neue Sales Order im SAP ERP System angelegt wird und einen bestimmten, konfigurierbaren Betrag wie beispielsweise 10.000 Euro übersteigt, soll automatisch eine E-Mail an den betreffenden Kunden versendet werden. Klingt einfach, oder? Der Teufel steckt wie so oft im Detail.

Also schauen wir genauer hin und beginnen mir der Architektur und dem Set-Up des Prozesses. Dafür kamen folgende SAP-Services zum Einsatz:

  • SAP S/4HANA Public Cloud als ERP-System
  • SAP Extensibility Wizard
  • SAP Event Mesh, um Ereignisse aus der Cloud an SBPA weiterzuleiten. (Alternativ haben wir auch SAP Cloud Application Event Hub erfolgreich getestet)
  • SAP Build Process Automation (SBPA) als zentrales Workflow- und Automatisierungstool & SMTP Server Konfiguration
  • Standard APIs aus S/4HANA Public Cloud, um zusätzliche Daten abzufragen.

Schon beim Blick auf die Liste der Komponenten wird klar: Es wird etwas komplexer. Schließlich müssen und sollen diese Lösungen und Systeme nahtlos zusammenspielen, wenn am Ende ein sauberer Prozess entstehen soll. Im Detail funktioniert der SBPA-Flow wie folgt:

Der Flow startet mit einem Event aus der SAP S/4HANA Cloud, beim Anlegen einer Sales Order. Dieses Ereignis wird über den Event Mesh an SBPA übermittelt, woraufhin der automatisierte Prozess ausgeführt wird. Folgende Schritte werden also durchlaufen:

  1. Trigger durch Sales Order Event:

    Da Event kann entweder mit einem Wizard oder manuell über den SAP Business Accellerator Hub konfiguriert werden.

  2. Datenanreicherung via API:

    Da das Event nur begrenzte Informationen liefert, wird per API-Call über eine sogenannte Action der vollständige Datensatz zur Sales Order (z. B. Gesamtbetrag) abgefragt.

  3. Datenverarbeitung und Regelprüfung:

    Der erhaltene Betrag wird aus einem String in eine Zahl konvertiert. Anschließend prüft eine Business Rule, ob der Betrag über 10.000 Euro liegt. Durch die Nutzung einer Regel kann dies sogar von Fachabteilungen gepflegt werden, etwa via Excel.

  4. Kunden-E-Mail ermitteln:

    Über weitere Actions wird die Kundenadresse basierend auf dem ShipToParty und letztlich die E-Mail-Adresse abgefragt. Dahinter liegt ein mehrstufiger Prozess, da die Daten über unterschiedliche APIs verteilt sind.

  5. Versand der Benachrichtigung:

Sobald die E-Mail-Adresse vorliegt und die Bedingung erfüllt ist, wird über einen konfigurierten SMTP-Server die Nachricht versendet.


Wie gut funktioniert das? Erkenntnisse aus der Praxis.

Die Umsetzung des Flows offenbarte spannende Einblicke. So ermöglicht SAP BPA eine flexible, modulare Prozessmodellierung mit klaren Genehmigungsschritten und Prozessmonitoring. Durch Versionierung ist eine Verwaltung verschiedener Prozeßvarianten Out-of-the-Box möglich. Die Nutzung von Business Rules und Templates macht die Lösung für Fachbereiche leicht zugänglich und anpassbar und mit dem integrierten Store in der SAP Build Lobby stehen weitere zahlreiche Vorlagen sowohl von SAP als auch von Drittanbietern zur Verfügung.

Allerdings gab es auch einige Herausforderungen zu überwinden. So war der initiale Setup-Aufwand der Services inklusive aller Verbindungen, der Authentifizierung und Berechtigungen im Vergleich zur Prozessmodellierung recht hoch. Zudem liefern nicht alle Datenquellen die benötigten Informationen direkt, wodurch es teils mehrere API-Calls braucht. Und wenn an Regeln oder Aktionen Änderungen vorgenommen werden, muss der Flow erneut veröffentlicht werden.

Unser Fazit: Low-Code mit SBPA ein echter Mehrwert für SAP

Unser Projekt hat gezeigt: SAP Build Process Automation ist im Zusammenspiel mit weiteren SAP Cloud Services und Eventing ein mächtiges Werkzeug, um Workflows mit und ohne Freigabeprozessen in SAP-Systemen effizient zu automatisieren. Das Versprechen, das auch ohne tiefgehende Coding-Kenntnisse für weniger technikaffine Anwender:innen möglich zu machen, wurde weitestgehend gehalten. Insbesondere wer bereits mit Tools wie Microsoft Power Automate gearbeitet hat, wird sich schnell zurechtfinden.

Dennoch gilt: Eine gewisse technische Basis, insbesondere beim Umgang mit APIs und Systemverbindungen, bleibt notwendig. Wer diesen Schritt wagt, profitiert jedoch von einer hohen Flexibilität bei Anpassungen und Erweiterungen und letztlich von deutlichen Effizienzgewinnen im operativen Alltag.

SBPA bietet hier einen Mittelweg: Statt aufwändig eigene Workflow Services bauen oder teure Custom Extensions pflegen zu müssen, lassen sich mit geringem Codeeinsatz smarte Automatisierungen und Erweiterungen realisieren. Die zentrale Frage von oben lautet also nicht mehr nur „Standard oder Eigenbau?“, sondern vielmehr „Tue ich mir eine vollständige Eigenentwicklung an oder reicht nicht auch ein konfigurierbarer Low-Code-Flow, der 80 % meines Bedarfs abdeckt?“

Gerade für Unternehmen, die sich aus der „alten“ SAP-Welt in die „neue“ Cloud-Welt der SAP S/4HANA Public Cloud bewegen, ist SAP SBPA besonders interessant. Denn hier geht es nicht nur um technische Migration, sondern auch um ein Umdenken bei der Prozessgestaltung – weg von hart codierten Eigenentwicklungen, hin zu modularen, flexiblen und wartungsarmen Automatisierungen.

 

Teilen

Kommentare

Ihr Kommentar