Der Grundgedanke ist einfach zu erzählen und in der Praxis dennoch anspruchsvoll: Viele Abläufe im Unternehmen bestehen aus einer Mischung aus menschlichen Entscheidungen (etwa eine Freigabe durch die Führungskraft) und stumpfen, wiederkehrenden Tätigkeiten (etwa das Übertragen von Daten zwischen Systemen). SAP Build Process Automation bildet genau diese Mischung ab. Ein modellierter Prozess kann eine Genehmigung anfordern, auf die Antwort warten, anschließend automatisch einen Datensatz in SAP S/4HANA anlegen und zum Schluss eine Bestätigung versenden — ohne dass ein Mensch die Zwischenschritte von Hand ausführt.
Drei Eigenschaften prägen den Dienst und erklären seine Position im Markt:
Der Name „Build“ ist Programm: SAP fasst unter der Marke SAP Build mehrere Low-Code-Angebote zusammen, von denen die Prozessautomatisierung eines ist. Der Anwender arbeitet in einer grafischen Umgebung, zieht Prozessschritte auf eine Fläche, verbindet sie zu einem Ablauf, hängt Formulare und Entscheidungsregeln an und veröffentlicht das Ganze anschließend. Aus dem visuellen Modell wird ein tatsächlich laufender Prozess, der Aufgaben an Menschen verteilt, auf Ereignisse reagiert und Systeme anspricht. Diese Durchgängigkeit vom Entwurf bis zum Betrieb ist der Kern des Versprechens.
Low-Code bedeutet nicht „ohne Fachwissen“. Es bedeutet, dass ein großer Teil der Arbeit ohne klassisches Programmieren gelingt, während für Sonderfälle weiterhin Skript- oder Entwicklungsanteile möglich bleiben. In der Praxis ist das ein Segen und eine Falle zugleich: Ein Segen, weil Fachbereiche schneller zu Ergebnissen kommen und die IT entlastet wird. Eine Falle, weil unkontrolliert entstehende Prozesse zu einem Wildwuchs führen können, der später schwer zu warten ist. Governance — also klare Regeln, wer was bauen und veröffentlichen darf — gehört deshalb aus unserer Sicht von Anfang an dazu.
Im Marktgespräch verschwimmen die Begriffe. Workflow-Automatisierung steuert den Ablauf eines Prozesses mit Aufgaben, Genehmigungen und Entscheidungen — sie orchestriert, wer wann was tut. RPA (Robotic Process Automation) automatisiert dagegen einzelne, oft repetitive Tätigkeiten, indem ein Software-Roboter Benutzeroberflächen oder Schnittstellen bedient, so wie es sonst ein Mensch täte. Process Visibility schließlich macht sichtbar, wie die laufenden Prozesse tatsächlich performen — mit Kennzahlen zu Durchlaufzeiten, Engpässen und Status. Wer diese drei Ebenen auseinanderhält, versteht schneller, warum SAP Build Process Automation mehr sein will als ein reines Bot-Werkzeug.
SAP Build Process Automation ist aus zwei Vorläufern hervorgegangen: dem früheren SAP Workflow Management, das Genehmigungen, Aufgaben, Entscheidungslogik und Prozess-Sichtbarkeit bot, und der SAP Intelligent Robotic Process Automation, dem RPA-Werkzeug für Software-Bots. Beide wurden unter dem Dach von SAP Build zusammengeführt, damit Anwender Workflow und RPA nicht mehr in getrennten Produkten mit getrennten Konzepten pflegen müssen. Für Bestandskunden bedeutet das: Wer früher eines der Vorläuferprodukte nutzte, findet die Fähigkeiten in gebündelter Form wieder — mit einer über die Zeit vereinheitlichten Oberfläche und Verwaltung.
Funktional lässt sich der Dienst in vier zusammenspielende Bausteine gliedern. Der Prozess-Baustein orchestriert Abläufe: Er verkettet Schritte, verteilt Aufgaben, ruft Automatisierungen auf und wartet auf Ereignisse oder Freigaben. Der Aufgaben- und Formular-Baustein bringt Menschen in den Prozess — über Formulare zur Dateneingabe und über einen zentralen Aufgaben-Eingang, in dem Genehmigungen und To-dos landen. Der Bot-Baustein (RPA) automatisiert repetitive Tätigkeiten, indem er Anwendungen bedient, für die es keine saubere Schnittstelle gibt — etwa Altsysteme oder Fremdanwendungen. Der Sichtbarkeits-Baustein (Process Visibility) überwacht schließlich die laufenden Prozesse und stellt ihre Leistung in Kennzahlen dar. Erst das Zusammenspiel dieser vier Ebenen macht aus Einzelfunktionen eine durchgängige Automatisierungsplattform.
SAP Build Process Automation steht nicht für sich allein, sondern ist ein Dienst innerhalb der SAP BTP — der Technologie-Plattform, mit der SAP Erweiterungen, Integrationen und eigene Anwendungen rund um den SAP-Kern ermöglicht. Das hat weitreichende Folgen. Der Dienst teilt sich mit anderen BTP-Angeboten die Verwaltung von Nutzern und Rollen, die Verbindungen zu Zielsystemen (die sogenannten Destinations) und die Anbindung an lokale Systeme über den SAP Cloud Connector. Er ist damit weniger ein isoliertes Werkzeug als vielmehr ein Baustein einer größeren Erweiterungs-Strategie. Für Unternehmen, die auf dem Weg zu „Clean Core“ sind — also den SAP-Standard möglichst unangetastet lassen und Erweiterungen sauber daneben in der BTP bauen —, ist diese Positionierung besonders relevant: Automatisierungen entstehen außerhalb des Kerns und gefährden Upgrades nicht.
Die Zielgruppe ist klar umrissen: Organisationen mit SAP-Schwerpunkt, die wiederkehrende Prozesse rund um ihre SAP-Systeme automatisieren wollen, ohne für jede Kleinigkeit ein Entwicklungsprojekt aufzusetzen. Das können Fachbereiche im Einkauf, in der Finanzbuchhaltung, im Personalwesen oder im Vertrieb sein, die Genehmigungen, Onboarding-Abläufe oder Datenpflege automatisieren möchten. Weniger passend ist der Dienst, wenn SAP nur eine Nebenrolle spielt und der Automatisierungsbedarf überwiegend in einer Nicht-SAP-Welt liegt — dann verschiebt sich das Bild zugunsten herstellerneutraler RPA- oder Automatisierungsplattformen, die wir in Kapitel 06 einordnen.
Im Zentrum steht der grafische Prozess-Editor. Anwender setzen einen Ablauf aus einzelnen Schritten zusammen: Ein Formular nimmt Daten auf, eine Entscheidungsregel verzweigt den Prozess je nach Betrag oder Kategorie, eine Genehmigungsaufgabe geht an die zuständige Führungskraft, und eine Aktion schreibt das Ergebnis am Ende in ein SAP-System. Die Formulare selbst lassen sich ebenfalls ohne Programmierung gestalten — Felder, Pflichtangaben und einfache Prüfungen werden visuell definiert. Für den Mittelstand ist das entscheidend, weil so auch Prozesse abgebildet werden können, für die sich ein klassisches Entwicklungsprojekt nie gelohnt hätte.
Genehmigungsstrecken sind der Klassiker der Workflow-Automatisierung — und einer der häufigsten Einstiegspunkte. Urlaubsanträge, Bestellfreigaben, Rechnungsprüfungen oder Investitionsanträge folgen fast immer demselben Muster: beantragen, prüfen, genehmigen oder ablehnen, dokumentieren. SAP Build Process Automation bildet diese Muster mit einem zentralen Aufgaben-Eingang ab, in dem alle offenen Genehmigungen und To-dos einer Person zusammenlaufen — über Web und mobil erreichbar. Mehrstufige Freigaben, Vertreterregelungen und Eskalationen lassen sich modellieren, sodass ein Antrag nicht liegen bleibt, wenn eine Führungskraft im Urlaub ist.
Wo eine saubere Schnittstelle fehlt, kommen Bots ins Spiel. Sie bedienen Anwendungen wie ein Mensch: Fenster öffnen, Felder ausfüllen, Werte kopieren, Schaltflächen klicken. Das ist besonders für ältere Systeme und Fremdanwendungen wertvoll, die keine moderne Programmierschnittstelle bieten. Bots können unbeaufsichtigt im Hintergrund laufen — etwa nachts einen Stapel Belege verarbeiten — oder beaufsichtigt am Arbeitsplatz, wo sie einer Mitarbeiterin auf Knopfdruck eine lästige Routine abnehmen. Ein wichtiger Grundsatz bleibt: RPA ist eine Brückentechnologie. Wo eine echte Schnittstelle existiert oder wirtschaftlich herstellbar ist, ist sie einem Bot fast immer vorzuziehen, weil Bots empfindlich auf Änderungen der bedienten Oberflächen reagieren und dadurch wartungsintensiv sein können.
SAP verfolgt mit Joule das Ziel, einen durchgängigen KI-Assistenten über die eigenen Anwendungen zu legen. In der Prozessautomatisierung bedeutet das vor allem zweierlei: Erstens soll der Bau von Automatisierungen leichter werden, indem der Anwender in natürlicher Sprache beschreibt, was er erreichen will, und einen ersten Entwurf erhält. Zweitens soll der Assistent im laufenden Betrieb unterstützen, etwa beim Auffinden der richtigen Aktion oder beim Erklären eines Prozessschritts. Wichtig ist eine nüchterne Erwartung: KI-Copiloten liefern Vorschläge, keine fertigen, ungeprüften Ergebnisse. Der fachliche Blick des Menschen bleibt notwendig — gerade bei Prozessen, die auf Geschäfts- oder Personaldaten zugreifen.
Ein großer Teil der Arbeit in Finanz- und Einkaufsprozessen dreht sich um Dokumente: Rechnungen, Lieferscheine, Bestellungen, Verträge. Diese liegen oft als PDF oder Scan vor — für einen klassischen Prozess wertlos, weil die Inhalte nicht strukturiert sind. Die Dokument-Informationsextraktion, die sich in SAP-Build-Prozesse einbinden lässt, liest solche Belege maschinell aus und übergibt die erkannten Felder an den Prozess. Aus einem gescannten Beleg wird so ein strukturierter Datensatz, mit dem der Prozess weiterarbeiten kann. Das ist einer der wirkungsvollsten Automatisierungshebel überhaupt, weil er einen sonst manuellen, fehleranfälligen Schritt ersetzt.
Die zweite Stoßrichtung der KI ist das assistierte Erstellen: Aus einer Beschreibung des gewünschten Ablaufs soll ein Prozessentwurf entstehen, den der Anwender dann verfeinert. Ergänzend erlaubt die Entscheidungsautomatisierung, wiederkehrende Entscheidungsregeln zentral zu hinterlegen — etwa welche Freigabestufe ab welchem Betrag greift. Beides zusammen verschiebt die Rolle des Menschen: weg vom manuellen Zusammenbauen jeder Kleinigkeit, hin zum Prüfen, Anpassen und Verantworten. Aus INAGRO-Sicht ist das die produktive Lesart von KI in der Prozessautomatisierung — sie beschleunigt die Arbeit, ersetzt aber nicht das fachliche Urteil.
Der wichtigste Anknüpfungspunkt ist SAP S/4HANA — das ERP-System, das im SAP-Mittelstand den Kern bildet. Über vorbereitete Verbindungen kann ein Prozess in SAP Build Daten aus S/4HANA lesen und in es zurückschreiben: einen Bestellvorgang anlegen, einen Stammdatensatz aktualisieren, einen Status abfragen. Ähnliches gilt für weitere SAP-Anwendungen wie SAP SuccessFactors im Personalbereich oder SAP Ariba im Einkauf. Diese Nähe ist der entscheidende Unterschied zu neutralen Automatisierungswerkzeugen: SAP Build bringt Wissen über die SAP-Systeme und passende Inhalte bereits mit, statt jede Verbindung von Grund auf bauen zu müssen.
Technisch stützt sich der Dienst auf die Integrationsdienste der BTP. Über sogenannte Destinations werden Zielsysteme zentral hinterlegt, sodass Prozesse und Aktionen sie ansprechen können. Für Systeme, die nicht in der Cloud, sondern im eigenen Rechenzentrum stehen, schlägt der SAP Cloud Connector eine sichere Brücke zwischen der lokalen Landschaft und der BTP. Darüber hinaus lassen sich über offene Schnittstellen (APIs) auch Nicht-SAP-Systeme anbinden — allerdings mit mehr Konfigurationsaufwand als bei den nativen SAP-Verbindungen. Für Fremdsysteme ohne brauchbare Schnittstelle bleiben die RPA-Bots die Rückfalloption.
Ein oft unterschätzter Teil des Ökosystems sind die vorgefertigten Inhalte: fertige Prozess-, Bot- und Aktionsvorlagen für typische SAP-Szenarien, die sich übernehmen und anpassen lassen. Statt einen Rechnungsfreigabe-Prozess oder ein Mitarbeiter-Onboarding von null zu entwerfen, startet man mit einer bewährten Vorlage und passt sie an die eigenen Regeln an. Das verkürzt die Zeit bis zum ersten Ergebnis erheblich. Der ehrliche Zusatz aus der Praxis: Vorlagen sind ein Startpunkt, kein Endpunkt. Fast jeder Prozess hat unternehmensspezifische Eigenheiten, sodass eine Anpassung nötig bleibt — die Vorlage spart die Grundstruktur, nicht das Nachdenken über den eigenen Ablauf.
Der klarste Fall ist eine SAP-zentrierte Systemlandschaft. Wenn der Kern aus S/4HANA und weiteren SAP-Anwendungen besteht und der Automatisierungsbedarf überwiegend rund um diese Systeme entsteht, spielt SAP Build seine Nähe zum Ökosystem voll aus: native Verbindungen, vorgefertigte Inhalte und ein gemeinsamer Betrieb auf der BTP. Ein zweiter guter Fall ist der Wunsch, Workflow und RPA in einem Werkzeug zu vereinen, statt getrennte Produkte zu betreiben. Und drittens passt der Dienst gut zu einer Clean-Core-Strategie, bei der Erweiterungen bewusst außerhalb des SAP-Standards in der BTP entstehen.
Ebenso ehrlich gehören die Gegenfälle benannt. Liegt der Schwerpunkt der Automatisierung in einer heterogenen Nicht-SAP-Welt mit vielen Fremdanwendungen, sind spezialisierte RPA-Plattformen wie UiPath in der Bot-Breite und -Reife oft überlegen. Ist die Organisation stark auf Microsoft 365 ausgerichtet, kann Power Automate mit seiner Nähe zu Teams, SharePoint und Excel die naheliegendere Wahl sein. Und wer noch die frühere SAP Intelligent RPA im Einsatz hat, sollte den Umstieg auf SAP Build Process Automation planen, da die Fähigkeiten dort gebündelt weitergeführt werden — ein Fall für einen geordneten Migrationspfad statt Stillstand.
SAP Build Process Automation läuft als Cloud-Dienst auf der BTP. Das nimmt dem Unternehmen den Betrieb der Infrastruktur ab, verlagert aber Verantwortung auf die richtige Konfiguration und Steuerung. Zwei Themen verdienen besondere Aufmerksamkeit. Erstens der Verbrauch: Weil die Nutzung der BTP in der Regel verbrauchsbasiert abgerechnet wird, sollten Verbrauch und Kosten aktiv überwacht werden, damit keine Überraschungen entstehen. Zweitens die Bot-Wartung: Bots bedienen Oberflächen, die sich ändern können. Ändert sich eine bediente Anwendung, muss der Bot angepasst werden — ein laufender Aufwand, der von Anfang an eingeplant gehört.
Der größte Fehler bei Low-Code-Plattformen ist paradox: Ihre Stärke — dass viele Menschen schnell etwas bauen können — wird ohne Regeln zur Schwäche. Entstehen Prozesse unkoordiniert in verschiedenen Fachbereichen, wächst eine schwer wartbare Landschaft heran, in der niemand mehr den Überblick über Zugriffe, Verbindungen und Datenflüsse hat. Deshalb empfehlen wir, von Anfang an ein leichtgewichtiges Governance-Modell zu etablieren: klare Rollen, ein Freigabeprozess für Veröffentlichungen, Namens- und Dokumentationsstandards und ein kleines Kompetenzteam, das Methodik und Sicherheit hütet. Das bremst nicht, sondern schützt die Skalierbarkeit.
Es ist kein Zufall, dass die meisten Mittelstandsprojekte mit Genehmigungs- oder dokumentgetriebenen Prozessen beginnen. Sie sind hochvolumig, folgen klaren Regeln und lassen sich unmittelbar in Nutzen übersetzen: kürzere Durchlaufzeiten, weniger manuelle Nacharbeit, bessere Nachvollziehbarkeit für die Revision. Genau diese Eigenschaften machen den Nutzennachweis vergleichsweise einfach — die wichtigste Voraussetzung, um ein Automatisierungsprogramm intern zu rechtfertigen und schrittweise auszuweiten.
In unserer Beratungspraxis sehen wir denselben Bruch wie bei anderen Automatisierungswerkzeugen: Ein Prozess ist gebaut, sieht gut aus — und trotzdem ändert sich im Arbeitsalltag wenig, weil er nur teilweise genutzt wird oder an einer Stelle hakt. Der Wert entsteht erst, wenn ein Prozess vollständig gelebt wird und seine Wirkung messbar ist. Deshalb empfehlen wir, jeden Anwendungsfall von Anfang an mit einem konkreten Ziel, einem Verantwortlichen und einer Messgröße zu hinterlegen. „Wir automatisieren mal die Rechnungsfreigabe“ ist kein Ziel. „Wir verkürzen die Durchlaufzeit der Rechnungsfreigabe spürbar, verantwortet von der Buchhaltungsleitung, gemessen über Process Visibility“ ist eines.
Anders als bei einer einfachen Pro-Nutzer-Software lässt sich SAP Build Process Automation nicht mit einem einzigen Eurobetrag beziffern. Die Kosten hängen vom BTP-Modell, vom Verbrauch, von der Zahl und Komplexität der Prozesse und Bots sowie vom Einführungsaufwand ab. Jeder pauschale „Listenpreis“ aus dem Internet ist deshalb mit Vorsicht zu genießen. Seriös ist nur eine individuelle Kalkulation nach einem Scoping — und die aktuellen Konditionen sind stets beim Anbieter zu prüfen. Verlässlich sagen lässt sich: Der Verbrauch will gesteuert werden, und die Einführung ist bei bestehender BTP-Grundlage deutlich günstiger als bei einem Kaltstart.
Als Cloud-Dienst verarbeitet SAP Build Process Automation Daten außerhalb der eigenen vier Wände — und weil automatisierte Prozesse regelmäßig auf ERP- und teils Personaldaten zugreifen, ist Datenschutz zentral. Mehrere Punkte sollten vorab geklärt werden. Der Serverstandort und Datentransfer: SAP betreibt die BTP in verschiedenen Regionen, darunter EU-Regionen — die Wahl einer EU-Region kann ein Vorteil für die Datenhoheit sein und sollte vertraglich festgehalten werden; die konkret verfügbare Region und etwaige Datentransfers sind projektspezifisch zu prüfen. Der Auftragsverarbeitungsvertrag (AVV/DPA) mit SAP regelt Gegenstand, Art und Zweck der Verarbeitung sowie die technisch-organisatorischen Maßnahmen. Und die Berechtigungen der Bots: Ein Bot, der auf ERP- oder Personaldaten zugreift, sollte nur die minimal nötigen Rechte erhalten (Datensparsamkeit) und über eigene, nachvollziehbare Kennungen arbeiten, nicht über die persönlichen Zugänge von Mitarbeitenden.
Ein besonderes Augenmerk verdienen unbeaufsichtigte Bots, die im Hintergrund auf ERP- oder Personaldaten zugreifen. Sie handeln nicht als Mensch, sondern als technischer Nutzer — und genau deshalb müssen ihre Rechte bewusst und eng vergeben werden. Aus INAGRO-Sicht gelten drei Grundsätze: Erstens Datensparsamkeit — ein Bot sieht nur, was er für seine Aufgabe braucht. Zweitens Nachvollziehbarkeit — jede Bot-Aktion sollte protokolliert und einer eigenen technischen Identität zuordenbar sein. Drittens Trennung — persönliche Zugänge von Mitarbeitenden gehören nicht in Bots, weil sonst Verantwortung und Protokollierung verwischen. Wo Prozesse Beschäftigtendaten berühren, gehört zudem der Betriebsrat frühzeitig eingebunden.
