Data Science Beratung.

Wie an jedem zweiten Dienstag im Monat werden die Sicherheitsupdates für Clients und Server von Microsoft veröffentlicht. Im Juni 2026 schließt Microsoft 198 Schwachstellen, davon 32 kritische.

Welche Patches müssen heute Nacht raus und was kann warten? Hier ist unsere Einschätzung.

Sicherheitsupdates für Juni 2026 im Überblick

Zuletzt geprüft am 15.06.2026, 15:16 Uhr

Ganzheitlicher Blick auf die Support Zeiträume

Die folgende Matrix gibt Aufschluss über die aktuellen Support-Zeiträume. Die Update-Verlängerung bezieht sich auf das Extended Security Update (ESU) Programm von Microsoft.

Zuletzt geprüft am 15.06.2026, 15:22 Uhr

Schlussworte

Fragen zu einzelnen Updates oder zur Patch-Strategie in Ihrer Umgebung? Sprechen Sie uns an.

Cloud-Infrastrukturen entwickeln sich nahezu tagtäglich weiter und mit ihnen die Anforderungen an Teams, die diese Umgebungen betreiben und weiterentwickeln. Auch das Cloud Platform Engineering ist entsprechend in Bewegung: Neue Technologien, Nutzungsmuster und Anforderungen nehmen Einfluss darauf, wie Plattformen gebaut werden und aussehen sollen. Dieser Artikel gibt einen Überblick über vier Entwicklungen, die das Cloud Platform Engineering in den kommenden Jahren beeinflussen und welche Veränderungen sich dadurch ergeben können.

Infrastruktur ohne selbst gehostete Server: Serverless Architekturen

In klassischen Cloud-Umgebungen bauen Entwicklungsteams ihre Anwendungen und sind zusätzlich für die Verwaltung der Infrastruktur dahinter verantwortlich: Server bereitstellen, skalieren, aktualisieren und überwachen. Serverless Architekturen verschieben diese Verantwortung vollständig. Statt die Infrastruktur selbst zu verwalten, übernimmt das der Cloud Provider. Server gibt es natürlich weiterhin, das Unternehmen muss sich aber nicht mehr selbst darum kümmern. Entwicklungsteams stellen nur noch ihren Code oder Container bereit, der automatisch skaliert und nutzungsbasiert abgerechnet wird.

Daraus ergeben sich verschiedene Veränderungen und Vorteile:

• Weniger Betriebsaufwand: Plattformteams müssen keine Serverkapazitäten mehr einplanen oder verwalten. Die Infrastruktur passt sich selbst an.
• Schnellere Bereitstellung: Neue Funktionen lassen sich in kürzerer Zeit produktiv schalten, weil kein Aufbau der Infrastruktur mehr nötig ist.
• Neue Kostenstruktur: Statt für dauerhaft gebuchte Server zahlen Unternehmen nur für tatsächliche Nutzung. Das kann bei schwankendem Bedarf erhebliche Einsparungen bedeuten.

Serverless ist für viele Anwendungsfälle ein Effizienzgewinn und ist teilweise schon heute fester Bestandteil moderner Plattformstrategien.

Daten dort verarbeiten, wo sie entstehen mit Edge Computing

Klassische Cloud-Architekturen folgen einem klaren Prinzip: Daten werden gesammelt, in ein Rechenzentrum übertragen und dort verarbeitet. Das funktioniert gut, solange Geschwindigkeit keine kritische Rolle spielt und die Datenmenge beherrschbar bleibt. Dieser Weg wird aber immer häufiger zu langsam. Geräte am sogenannten Edge, also am Rand eines Netzwerks wie beispielsweise Maschinen in einer Produktionshalle, Fahrzeuge oder medizinische Geräte erzeugen besonders große Datenmengen. Diese alle erst in ein zentrales Rechenzentrum zu schicken, kostet Zeit und Bandbreite.

Beim Edge Computing wird ein Teil der Verarbeitung dorthin verlagert, wo die Daten entstehen. Sie findet direkt auf dem Gerät oder in unmittelbarer Nähe davon statt. Das bringt mehrere Vorteile mit sich:

• Reaktionszeiten sinken erheblich, weil keine langen Übertragungswege mehr nötig sind.
• Netzwerklast und Übertragungskosten werden reduziert.
• Sensible Daten müssen das lokale Umfeld gar nicht erst verlassen.

Für Cloud Platform Engineering bedeutet dieser Trend, dass Plattformen künftig nicht mehr nur zentrale Rechenzentren, sondern auch dezentrale Infrastruktur an verschiedenen Standorten verwalten können müssen. Das Modell ist zwar deutlich komplexer, aber auch zukunftsfähig.

KI-gestützte Verwaltung als Plattform, die mitdenkt

Cloud-Umgebungen wachsen. Mit der Zahl der Services, Teams und Anwendungen steigt auch die Komplexität irgendwann in Dimensionen, die manuell kaum noch beherrschbar sind. In solchen Fällen kann der Einsatz KI-gestützter Plattformverwaltung sinnvoll sein. Konkret geht es darum, wiederkehrende Aufgaben zu automatisieren und Muster zu erkennen, die für Menschen schwer zu erfassen sind. Plattformen, die KI einsetzen, können zum Beispiel:

• Anomalien frühzeitig erkennen: Ungewöhnliches Verhalten in der Infrastruktur wird automatisch gemeldet, bevor es zu einem ernsthaften Problem wird.
• Ressourcen intelligenter verteilen: Anhand von Nutzungsmustern wird die Infrastruktur vorausschauend skaliert.
• Routineaufgaben übernehmen: Updates, Konfigurationsanpassungen oder Sicherheitsprüfungen laufen automatisiert ab, ohne dass ein Mensch jeden Schritt anstoßen muss.

Wichtig ist dabei: KI-gestützte Verwaltung ersetzt Plattformteams nicht, sondern ist zur Entlastung da. Der Routineaufwand sinkt, sodass sich Mitarbeitende auf Entwicklungsaufgaben fokussieren können.

Nachhaltiger betreiben: Green IT als zentraler Trend im Cloud Platform Engineering

Cloud-Infrastrukturen verbrauchen große Mengen an Energie. Rechenzentren gehören zu den energieintensivsten Einrichtungen überhaupt. Mit steigender Cloud-Nutzung wächst dieser Fußabdruck entsprechend weiter. Nachhaltigkeit ist damit längst zum wichtigen Trend im Cloud Platform Engineering geworden. Unternehmen reagieren darauf auf verschiedenen Ebenen:

• Wahl des Anbieters: Cloud-Anbieter mit nachweislich erneuerbaren Energiequellen und transparenter Klimabilanz nehmen eine immer wichtigere Rolle ein.
• Effizientere Ressourcennutzung: Ungenutzte Ressourcen werden konsequenter abgeschaltet, Workloads sinnvoll skaliert, um nur so viel Energie zu verbrauchen wie wirklich nötig.
• Messbarkeit als Voraussetzung: Möchten Unternehmen Emissionen reduzieren, müssen sie sie erst erfassen können. In Plattformen finden sich immer häufiger Tools, die den tatsächlichen CO₂-Fußabdruck von Cloud-Workloads sichtbar machen.

Nachhaltigkeit und Effizienz gehen hier Hand in Hand: Optimieren Unternehmen ihren Energieverbrauch, sparen sie in der Regel auch Kosten.

Cloud Platform Engineering Trends: heute planen, morgen vorn mitspielen

Aktuelle Entwicklungen im Cloud Platform Engineering, von Serverless Architekturen über Edge Computing und KI-gestützter Verwaltung bis hin zu Green IT, sind schon heute im Einsatz. Unternehmen nutzen die Möglichkeiten schon in unterschiedlichen Reifegraden. In vielen Firmen stehen die Entwicklungen allerdings noch am Anfang, sodass wir davon ausgehen können, dass diese Trends uns noch einige Jahre begleiten werden. Beziehen Unternehmen für sie sinnvolle Trends frühzeitig in ihre Plattformstrategie ein, schaffen sie Strukturen, die sich zukünftigen Anforderungen anpassen können. Dabei ist nicht jedes Thema für jedes Unternehmen gleich relevant. Es lohnt sich aber, einen Blick auf die Möglichkeiten zu werfen.

In Teil 1 und Teil 2 unserer Blogreihe haben wir gesehen, wie extrahierte Dokumentendaten entweder direkt in einer Benutzeroberfläche validiert oder per Integration Suite vollautomatisch im Hintergrund verbucht werden. Es gibt jedoch Geschäftsprozesse, die sich nicht rein linear oder starr automatisieren lassen. Häufig verlangen Compliance-Richtlinien dynamische Genehmigungsschritte, die von den extrahierten Dateninhalten abhängen.

In diesem dritten und letzten Teil zeigen wir Ihnen, wie die prozessgetriebene Integration mit SAP Build Process Automation (SBPA) funktioniert. Wir orchestrieren den gesamten Lebenszyklus eines Dokuments – von der KI-Extraktion bis hin zur flexiblen Freigabe-Logik im Unternehmen.

Business Szenario: Regelbasierter Genehmigungsworkflow

In unserem Szenario betrachten wir die Verarbeitung von Reisekostenabrechnungen oder projektbezogenen Spesenbelegen. Mitarbeiter laden ihre Belege digital hoch. Die manuelle Prüfung jedes einzelnen Belegs durch das Management blockiert jedoch wertvolle Ressourcen.

Das Ziel unseres Szenarios:

• Automatisierung bei Kleinbeträgen: Liegt der extrahierte Gesamtbetrag des Belegs unter einem definierten Schwellenwert von beispielsweise 100 €, verbucht das System den Beleg nach der KI-Extraktion direkt dunkel in SAP S/4HANA.
• Dynamischer Workflow: Überschreitet der Betrag diese Grenze oder wurde der Beleg in einer Fremdwährung ausgestellt, triggert das System automatisch einen Genehmigungsworkflow. Der zuständige Abteilungsleiter erhält eine Benachrichtigung in seiner Inbox und muss den Beleg vor der finalen Verbuchung explizit freigeben.

Lösungsarchitektur

Dieses Muster nutzt die Low-Code/No-Code-Plattform SAP Build Process Automation als zentralen Workflow-Orchestrierer. SBPA verbindet dabei die KI-Fähigkeiten nativ mit der Prozesslogik.

1. Prozess-Trigger: Ein Start-Formular (UI) in SAP Build, eine eingehende E-Mail oder ein API-Callback.

2. SAP Build Process Automation (Prozessfluss): Steuert die Abfolge der Schritte.

3. SAP Document AI (als Prozess-Schritt): Extrahiert die Daten aus dem hochgeladenen Dokument.

4. Decision Engine (Geschäftsregeln): Evaluiert den Betrag und steuert die Verzweigung des Pfads.

5. Approval Form (User Task): Die Inbox für den Vorgesetzten im Falle einer Schwellenwert-Überschreitung.

6. SAP S/4HANA (via Actions): Die finale Verbuchung des Belegs im ERP-Kern.

Technische Umsetzung

Der große Vorteil dieses Musters liegt in der visuellen Modellierung des gesamten Prozesses innerhalb der SAP Build-Entwicklungsumgebung.

1. Flexibler Prozessstart & KI-Extraktion

Der Prozess kann über verschiedene Kanäle initiiert werden. Ein eleganter Weg ist ein in SBPA integriertes Start-Formular, über welches der Nutzer die PDF-Datei hochlädt. Im Prozessfluss wird als direkt nachgelagerter Schritt die SAP Document AI aufgerufen. Innerhalb von SAP Build lässt sich die Extraktions-Schnittstelle komfortabel als nativer Prozessschritt einbinden, ohne dass tiefe Coding-Kenntnisse im Backend erforderlich sind.

2. Konditionale Genehmigungsschritte (Decision Tables)

Nachdem die Document AI die strukturierten Daten (z. B. grossAmount und currency) zurückgeliefert hat, nutzen wir eine Condition oder eine Decision Table in SBPA:

• Bedingung: grossAmount > 100 ODER currency != 'EUR'

• Pfad A (Ja): Der Prozess zweigt ab zu einem User Task (Genehmigungsformular). Der Abteilungsleiter sieht die extrahierten Daten und kann per Klick „Genehmigen“ oder „Ablehnen“.

• Pfad B (Nein): Der Beleg überspringt die menschliche Instanz und geht direkt in die Verbuchung.

3. Automatische Verbuchung via SAP Build Actions

Die finale Verbuchung in SAP S/4HANA erfolgt nicht über klassischen Integrationscode, sondern über sogenannte Actions. Hierzu importieren wir die standardisierten Spezifikationen (wie z. B. das Billing Document oder entsprechende Finanzbuchungs-APIs) direkt aus dem SAP Business Accelerator Hub in unser SAP Build-Projekt.

SBPA generiert daraus wiederverwendbare Bausteine. Wir mappen einfach die Datenfelder aus dem Document-AI-Schritt (bzw. dem Genehmigungsformular) per Drag-and-Drop auf die Eingabeparameter der S/4HANA-Action.

Voraussetzungen

Um diesen prozessgetriebenen Ansatz umzusetzen, müssen folgende Komponenten in der BTP bereitstehen:

• SAP Build Process Automation: Ein aktivierter Subaccount mit der SBPA-Anwendungsoberfläche und zugewiesenen Entwickler-Rollen (ProcessAutomationAdmin etc.).

• Destinations & Actions: Im BTP-Subaccount müssen die Destinationen zu SAP S/4HANA und zur SAP Document AI sauber gepflegt sein. Im SAP Build Lobby-Projekt müssen die entsprechenden Actions eingerichtet sein.

• Prozess-Modellierung: Anlage eines neuen Business Processes, Definition der Datenstrukturen für die Formulare und Aktivierung des Projekts zur Bereitstellung in der Task-Inbox der Nutzer.

Fazit

Wählen Sie dieses Integrationsmuster immer dann, wenn Sie eine flexible, konfigurierbare und audit-sichere Prozesslogik benötigen. Es schließt perfekt die Lücke zwischen reiner Benutzeroberfläche (Teil 1) und starrer Dunkelverarbeitung (Teil 2).

Die Vorteile auf einen Blick

1. Compliance und Nachvollziehbarkeit: Jeder Genehmigungsschritt, jede Ablehnung und jede automatiche Buchung wird im Prozessprotokoll von SAP Build lückenlos dokumentiert.
2. Business Agilität: Schwellenwerte können von Key-Usern oder Prozessverantwortlichen direkt in den Decision Tables angepasst werden – ganz ohne Software-Deployment oder Code-Änderungen im ERP-Kern.
3. Nahtlose UX: Für den Genehmiger fügt sich der Task nahtlos in die tägliche Arbeit ein, da er seine Freigaben zentral in der SAP Launchpad/Work Zone Umgebung mobil oder am Desktop erledigen kann.

Möchten Sie komplexe Genehmigungsprozesse mit einer intelligenten Dokumentenverarbeitung verknüpfen?

Wir von Rewion unterstützen Sie umfassend bei der Implementierung von SAP Build Process Automation auf der SAP Business Technology Platform. Kontaktieren Sie uns für ein unverbindliches Erstgespräch, um Ihre Prozesse agil, transparent und zukunftssicher aufzustellen. Zusätzliche Fachartikel zu Erweiterungsstrategien und SAP BTP Governance finden Sie direkt auf unserem Blog.

In Teil 1 unserer Blogreihe haben wir uns das „Human-in-the-loop“-Szenario angeschaut, bei dem extrahierte Daten manuell in einer SAPUI5-Oberfläche validiert werden. Doch was passiert, wenn das Belegaufkommen so massiv ansteigt, dass eine manuelle Prüfung zum unbezahlbaren Nadelöhr wird? Hier kommt die datengetriebene Integration ins Spiel. In diesem zweiten Teil zeigen wir Ihnen, wie durch die Kombination von SAP Document AI und der SAP Integration Suite eine vollständige Dunkelverarbeitung (Dark Processing) realisiert wird – berührungslos, hocheffizient und skalierbar.

Business Szenario: Vollautomatisch verbuchen

Stellen wir uns einen Großkonzern vor, der monatlich 50.000 standardisierte Rechnungen von festen Vertragspartnern oder Tochtergesellschaften erhält. Die Layouts sind bekannt, die Datenqualität ist hoch. Würde hier ein Team von Sachbearbeitern jede einzelne Extraktion manuell prüfen, wäre der wirtschaftliche Vorteil der KI dahin.

Das Ziel unseres Szenarios: Die Dokumente treffen über automatisierte Kanäle wie einen zentralen E-Mail-Inbound oder einen SFTP-Server ein und das System übergibt sie im Hintergrund an die SAP Document AI. Nach erfolgreicher Extraktion fließen die Daten ohne menschliches Zutun direkt in die SAP Integration Suite. Dort werden sie validiert, transformiert und vollautomatisch als Billing Document (Faktura) direkt im digitalen Kern (SAP S/4HANA) verbucht.

Lösungsarchitektur

Dieses Muster setzt auf eine ereignisgesteuerte, asynchrone Architektur. Die Integration Suite agiert dabei als der zentrale, intelligente Datenverteiler.

1. Ingest / Quelle: Ein automatisierter Trigger (z. B. ein iFlow-Timer, SFTP Listener oder ein Callback-Event), der das PDF an Document AI sendet.

2. SAP Document AI: Verarbeitet das Dokument asynchron und hält das Ergebnis bereit.

3. BTP Destination (Callback): Informiert die Integration Suite aktiv über die Fertigstellung.

4. Cloud Integration (iFlow): Empfängt die Payload, übernimmt das Daten-Mapping und steuert das Error-Handling.

5. SAP S/4HANA: Empfängt die transformierten Daten über die standardisierte OData-Schnittstelle.

Technische Umsetzung

Da wir im Enterprise-Kontext mit asynchroner Verarbeitung arbeiten, nutzen wir den integrierten Callback-Mechanismus von SAP Document AI. Das vermeidet ineffizientes Polling und schont die Systemressourcen der Integration Suite.

1. Der Callback-Endpunkt im Integration Flow

Der iFlow startet mit einem HTTPS-Sender-Kanal. Die dort generierte Endpunkt-URL wird in den BTP-Destinations hinterlegt. Sobald die Document AI die Extraktion abgeschlossen hat, sendet sie einen HTTP-Post-Request an diesen iFlow. Die Payload enthält direkt das extrahierte JSON-Ergebnis.

2. Daten-Transformation: Groovy Script vs. XSLT Mapping

Das von SAP Document AI gelieferte Ergebnis liegt nativ im JSON-Format vor. Um dieses in die von S/4HANA erwartete Struktur für Billing Documents zu bringen, stehen Entwicklern zwei Wege offen:

• Weg A (XML & XSLT): Die JSON-Payload wird über einen JSON-to-XML-Converter in XML umgewandelt. Anschließend wird ein klassisches XSLT-Mapping ausgeführt, um die Felder (wie Netto-Betrag, Steuer, Kreditor) zuzuweisen.

• Weg B (Groovy Script – Empfehlung): Um Konvertierungs-Overhead zu vermeiden, nutzen wir ein Groovy Script. Dieses parst das JSON-Objekt nativ, führt Validierungen durch (z. B. „Liegt der Konfidenzwert aller Pflichtfelder über 85%?“) und baut direkt die finale JSON-Struktur für den S/4HANA OData-Aufruf auf.

3. Verbuchung im S/4HANA Core via OData

Die transformierten Daten werden über einen OData-Receiver-Kanal an S/4HANA übergeben. Wir nutzen hierbei das standardisierte API aus dem SAP Business Accelerator Hub: Billing Document - Read, Create, Delete (API_BILLING_DOCUMENT_SRV). Der iFlow übergibt die Daten per POST-Request an die Entity A_BillingDocument.

Voraussetzungen

Für die Umsetzung dieses automatisierten Musters müssen folgende technischen Komponenten vorbereitet sein:

• SAP Integration Suite: Ein aktiver Subaccount mit aktivierter Cloud Integration Capability

• HTTPS Inbound Konfiguration: Vergabe der entsprechenden Rollen (MessagingSend) für den Service-User, damit Document AI den iFlow aufrufen darf

• BTP Destination für den Callback: Eine Destination in der BTP, die auf die Runtime-URL des iFlows verweist

• S/4HANA Konnektivität: Ein Cloud Connector (bei On-Premises/Private Cloud) oder eine direkte Kommunikationsvereinbarung (Public Cloud) zur Freischaltung des Billing-Document-OData-Services

Fazit

Dieses Muster ist der Standard für High-Volume-Szenarien, bei denen Effizienz und Durchsatz im Vordergrund stehen. Es minimiert die Prozesslaufzeiten von Tagen auf wenige Sekunden.

Einbindung der Document AI Benutzeroberfläche

Ein großer Vorteil dieses Musters ist seine Flexibilität: Es funktioniert sowohl, wenn Dokumente vollautomatisch über Schnittstellen eintreffen, als auch, wenn Key-User Dokumente gesammelt über die Standard-UI von SAP Document AI hochladen. Der anschließende Verbuchungsprozess im ERP bleibt identisch digitalisiert und entkoppelt.

Architektur-Tipp aus der Praxis: Im iFlow sollte zwingend ein datenbasiertes Routing für den Fehlerfall berücksichtigt werden. Fällt der Konfidenzwert der KI bei einer Rechnung unter einen definierten Schwellenwert, sollte der iFlow die Buchung in S/4HANA stoppen und stattdessen ein Ticket im System anlegen oder den Beleg in eine manuelle Klärungsschleife leiten.

Im nächsten und letzten Teil unserer Blogreihe betrachten wir das dritte Integrationsmuster. In Teil 3 orchestrieren wir komplexe, abteilungsübergreifende Geschäftsprozesse und Genehmigungsworkflows mithilfe von SAP Build Process Automation.

Planen Sie die Einführung einer berührungslosen Dunkelverarbeitung für Ihre Massendaten?

Rewion unterstützt Sie umfassend bei der Konzeption und Umsetzung Ihrer Integrationsprojekte auf der SAP Business Technology Platform. Kontaktieren Sie uns noch heute für ein unverbindliches Beratungsgespräch, um Ihre Prozesse hocheffizient zu automatisieren. Für weitere strategische Einblicke empfehlen wir Ihnen auch unsere verwandten Blogartikel zu den Themen SAP BTP Governance und moderne Erweiterungsstrategien für S/4HANA.

Im Einführungsartikel unserer Blogreihe haben wir SAP Document AI als strategischen Baustein für eine Clean-Core-Architektur betrachtet. In diesem ersten Deep Dive widmen wir uns dem am häufigsten nachgefragten Muster in der Praxis: Der benutzerzentrierten UI-Integration nach dem „Human-in-the-loop“-Prinzip. Hierbei überlassen wir der künstlichen Intelligenz die schwere Arbeit der Datenextraktion, behalten aber die volle Kontrolle durch ein maßgeschneidertes Validierungs-Frontend.

Business Szenario: Schluss mit dem Abtippen

In vielen Unternehmen sieht die Realität der Rechnungsverarbeitung noch immer so aus: Eine Rechnung trifft als PDF-Anhang per E-Mail ein. Ein Sachbearbeiter öffnet das Dokument auf dem einen Bildschirm und tippt im anderen Bildschirm mühsam Kreditorennummer, Rechnungsbetrag, Steueranteile und Positionsdaten manuell in das SAP-System ein. Das kostet wertvolle Zeit und ist zudem extrem fehleranfällig.

Das Ziel unseres Szenarios: Der Sachbearbeiter lädt das Dokument über eine intuitive Web-Oberfläche hoch. Die SAP Document AI extrahiert die Daten im Hintergrund in Sekundenschnelle. Der Nutzer sieht das Ergebnis sofort visuell aufbereitet, korrigiert bei Bedarf minimale Abweichungen und gibt den Beleg mit einem Klick zur Buchung frei.

Lösungsarchitektur

Die Architektur dieses Szenarios basiert vollständig auf dem Side-by-Side-Extensibility-Ansatz auf der SAP Business Technology Platform (BTP).

1. Frontend (SAPUI5 Freestyle): Eine maßgeschneiderte Applikation, die dem Nutzer den Upload ermöglicht und die extrahierten Daten neben dem Original-PDF anzeigt.

2. Backend (SAP CAP Service): Das Cloud Application Programming Model agiert als zentraler Orchestrator. Es nimmt das Dokument entgegen, leitet es an die Document AI API weiter und stellt die Business-Logik (z.B. Validierungsregeln) bereit.

3. Connectivity Layer (BTP Destination Service): Kapselt die Verbindungsparameter und die Authentifizierung zur KI-Schnittstelle.

4. SAP Document AI: Der eigentliche Business Service, der die Extraktion durchführt und das strukturierte JSON-Ergebnis zurückliefert.

Technische Umsetzung

Die technische Umsetzung kombiniert die Stärken des CAP-Frameworks mit der Flexibilität von SAPUI5.

Das CAP-Backend als API-Brücke

Der CAP-Service konsumiert die Schnittstellen der SAP Document AI, wie sie im SAP Business Accelerator Hub definiert sind. Da die Verarbeitung bei größeren Dokumenten asynchron erfolgt, implementieren wir im CAP-Handler eine entsprechende Logik:

• Schritt A (Upload): Der Service sendet die Payload per POST-Request an den Endpunkt /document-jobs und erhält als Antwort eine Job-ID.
• Schritt B (Status-Check): Über den Endpunkt /document-jobs/{id} fragt das System den Status ab oder nutzt das BTP-Callback-Szenario.
• Schritt C (Datenabruf): Sobald der Status auf SUCCESS steht, rufen wir das extrahierte JSON-Objekt ab.

Das SAPUI5-Frontend zur Visualisierung

Ein kritischer Erfolgsfaktor für die Akzeptanz durch die Anwender ist die UI-Gestaltung. Wir nutzen hierfür eine Fiori Freestyle App, da wir maximale Kontrolle über das Layout benötigen. Eine Split-Screen-Ansicht bietet sich an: links das PDF im Viewer, rechts die extrahierten Eingabefelder. Ein echtes Highlight im Code ist die Auswertung des confidence-Scores, den die SAP Document AI für jedes extrahierte Feld mitliefert:

• Ein Wert > 0.9 (90% Sicherheit) wird im UI grün (ValueState.Success) markiert.

• Ein Wert < 0.7 wird auffällig gelb oder rot hervorgehoben (ValueState.Warning / ValueState.Error), damit das Auge des Sachbearbeiters sofort auf die kritische Stelle gelenkt wird.

Voraussetzungen

Um dieses Szenario in Ihrer eigenen BTP-Landschaft zu implementieren, müssen folgende Voraussetzungen erfüllt sein:

• BTP Subaccount & Space: Ein eingerichtetes Cloud Foundry- oder Kyma-Environment

• Entwicklungsumgebung: SAP Business Application Studio (BAS), SAP Build Code oder eine lokale VS Code-Installation

• SAP Document AI Instanz: Eine Service-Instanz des Typs document-information-extraction im Space inklusive eines Service Keys für die Credentials

• BTP Destination: Eine konfigurierte Destination auf Subaccount-Ebene, welche die Credentials aus dem Service Key nutzt (OAuth2ClientCredentials), um den sicheren Aufruf aus CAP zu gewährleisten

• Optional: Eine Application Subscription für die Standard-UI von SAP Document AI zu Test- und Schemadefinitionszwecken

Fazit

Dieses Integrationsmuster ist immer dann die perfekte Wahl, wenn eine menschliche Interaktion und Validierung zwingend erforderlich ist. Das gilt besonders bei regulatorischen Vorgaben oder stark schwankender Datenqualität der Quellbelege.

Warum eine eigene CAP/UI5-App statt des SAP-Standards?

AP liefert über die Application Subscription bereits eine Standard-Oberfläche für Document AI mit. Warum lohnt sich dennoch der Aufwand einer Eigenentwicklung?

1. Das Berechtigungs-Problem: Die Standard-UI von SAP bietet bezüglich der Rollen oft nur ein Alles-oder-nichts-Modell. Im Enterprise-Kontext möchten Sie jedoch häufig, dass Sachbearbeiter aus Team A nur Dokumente aus Buchungskreis A sehen. Das lässt sich über gefilterte Ansichten in einer eigenen App sauber abbilden.
2. User Experience (UX): Mit einer eigenen UI5-App bauen Sie einen maßgeschneiderten, hürdenfreien Einstieg für die Endanwender, der exakt auf den bestehenden Geschäftsprozess optimiert ist.

Im nächsten Teil unserer Blogreihe verlassen wir die Benutzeroberfläche und wechseln in die Welt der vollständigen Automatisierung. In Teil 2 schauen wir uns an, wie wir mit der SAP Integration Suite eine komplette Dunkelverarbeitung für hohe Belegvolumina realisieren.

Möchten Sie die Effizienz Ihrer Sachbearbeitung durch intelligente Frontends steigern?

Die Experten von Rewion unterstützen Sie umfassend bei der Konzeption und Umsetzung Ihrer maßgeschneiderten BTP-Apps. Kontaktieren Sie uns noch heute für ein unverbindliches Beratungsgespräch. Vertiefende Informationen zu modernen Erweiterungen finden Sie auch in unseren Artikeln über SAP BTP Governance und zukunftssichere Erweiterungsstrategien für S/4HANA.

Viele Unternehmen beginnen ihre Cloud-Reise mit einzelnen Projekten, ersten virtuellen Maschinen oder einem Kubernetes-Cluster. Was anfangs funktioniert, wird jedoch schnell zur Herausforderung, sobald mehrere Teams, Anwendungen und Compliance-Anforderungen hinzukommen. An dieser Stelle wird das Konzept der Landing Zone relevant. Eine Landing Zone bildet das organisatorische, technische und sicherheitsrelevante Fundament einer Cloud-Plattform. Sie schafft Standards, Governance-Strukturen und zentrale Dienste, auf denen spätere Anwendungen aufbauen können. Ziel ist es, von Anfang an eine Umgebung zu schaffen, die skalierbar, sicher und langfristig wartbar ist.

In diesem Artikel betrachten wir, wie eine moderne STACKIT Landing Zone aussehen kann und welche Aspekte aus unserer Sicht besonders wichtig sind.

Die richtige Projektstruktur als Ausgangspunkt für erfolgreiche STACKIT Landing Zones

Bevor Netzwerke, Firewalls oder Plattformdienste eingerichtet werden, sollte zunächst eine sinnvolle Projektstruktur definiert werden. STACKIT bietet hierfür verschiedene Möglichkeiten. Kleinere Umgebungen können bereits durch konsequente Naming-Konventionen strukturiert werden. Für größere Organisationen empfiehlt sich die Nutzung von Foldern, um Projekte logisch zu gruppieren.

Weniger bekannt ist, dass über den STACKIT Support aktuell sogar eine zweite Folder-Ebene freigeschaltet werden kann. Diese Funktion befindet sich noch in einer erweiterten Testphase und erfordert eine engere Abstimmung mit STACKIT. Für größere Organisationen eröffnet sie jedoch zusätzliche Möglichkeiten zur Abbildung von Geschäftsbereichen, Mandanten oder Plattformdomänen. Eine durchdachte Hierarchie bildet die Grundlage für Berechtigungen, Kostenzuordnung, Logging und Governance.

Warum moderne Landing Zones auf Network Areas setzen

Bei der Netzwerkarchitektur empfehlen wir heute grundsätzlich den Einsatz von STACKIT Network Areas. Das klassische STACKIT Public Projekt sollte aus unserer Sicht nur noch für Sonderfälle wie Sandbox- bzw. Testumgebungen verwendet werden. Der Grund dafür ist, dass bereits viele neuere Plattformdienste eine Network Area voraussetzen. Gleichzeitig ist ein späterer Wechsel zwischen Projekttypen mit entsprechendem Migrationsaufwand verbunden.

Network Areas ermöglichen es, mehrere Projekte innerhalb einer gemeinsamen Netzwerkarchitektur miteinander zu verbinden. Dadurch lassen sich klassische Hub-and-Spoke-Architekturen aufbauen, wie sie aus Enterprise-Umgebungen bekannt sind.

Hub-and-Spoke als Standardarchitektur für STACKIT Landing Zones

Eine bewährte Landing-Zone-Architektur basiert auf einem zentralen Netzwerk-Hub. In diesem Hub können zentrale Dienste betrieben werden:

• VPN-Anbindungen
• Firewalls
• DNS-Dienste
• Shared Services
• Monitoring- und Logging-Komponenten

Die eigentlichen Anwendungen werden in separaten Spoke-Projekten betrieben und greifen auf die zentralen Dienste des Hubs zurück. Aktuell erfolgt die zentrale Anbindung typischerweise über:

• STACKIT Managed VPN Gateway
• selbstverwaltete Firewall-Appliances, beispielsweise auf Basis einer pfSense-Instanz in STACKIT: STACKIT Docs 

Direkte private Netzwerkverbindungen stehen heute noch nicht zur Verfügung. Mit STACKIT Connect befindet sich jedoch bereits ein entsprechender Dienst in Vorbereitung, der künftig dedizierte private Verbindungen mit entsprechenden SLAs ermöglichen soll. Ende 2026 bzw. Anfang 2027 werden wir mehr dazu wissen.

Tipps zur Netzwerksegmentierung

STACKIT Network Areas ermöglichen eine klare Netzwerksegmentierung. So können beispielsweise Produktions- und Non-Produktionsumgebungen bereits auf Ebene der Network Area logisch und organisatorisch voneinander getrennt werden.
 

Dabei gibt es jedoch einen wichtigen Aspekt zu beachten:
Sobald ein STACKIT Virtual Network für das Routing in das Transfernetz konfiguriert wird, können Kommunikationspfade zwischen den angeschlossenen Projekten entstehen. Ohne zusätzliche Schutzmechanismen kann dies zu einer deutlich größeren Netzwerksichtbarkeit führen als ursprünglich beabsichtigt.

Aus diesem Grund sollten Network Security Groups (NSGs) von Beginn an ein zentraler Bestandteil jeder STACKIT Landing Zone sein. Wir empfehlen, sämtliche Subnetze durch NSGs abzusichern, besonders schützenswerte Workloads zusätzlich auf NIC-Ebene zu schützen und Netzwerkkommunikation ausschließlich explizit freizugeben. Ein konsequent umgesetztes Default-Deny-Prinzip stellt dabei sicher, dass nur die tatsächlich benötigten Kommunikationsbeziehungen erlaubt werden. Auf diese Weise bleibt jederzeit nachvollziehbar und kontrollierbar, welche Systeme über welche Ports und Protokolle miteinander kommunizieren dürfen.

Der aktuelle Stand zu Private Endpoints

Ein Thema, das viele Nutzer von Hyperscalern kennen, sind Private Endpoints für Plattformdienste. Diese Funktion steht bei STACKIT aktuell noch nicht flächendeckend zur Verfügung. Viele PaaS-Dienste werden deshalb bewusst als sogenannte Online Services bereitgestellt und sind über öffentliche Endpunkte erreichbar.

Wichtig zu verstehen ist dabei:

Greift eine virtuelle Maschine innerhalb der STACKIT Cloud auf einen solchen Dienst zu, verbleibt der Datenverkehr zwar im STACKIT Backbone. Die Architektur unterscheidet sich jedoch von den vollständig privaten Service-Endpunkten anderer Cloud-Anbieter.

Private Endpoints befinden sich bereits in der Entwicklung. Erste Dienste, beispielsweise für den STACKIT Objektspeicher, werden voraussichtlich zeitnah folgen. Bis dahin können ACLs und Netzwerkkonzepte dabei helfen, die Angriffsfläche zu reduzieren.

Identitäten und Service Accounts richtig planen

Ein weiterer wichtiger Unterschied zu vielen anderen Cloud-Plattformen betrifft das Identitätsmodell. STACKIT versteht sich bewusst nicht als eigener Identity Provider. Stattdessen integriert sich die Plattform in bestehende Identitätslandschaften und unterstützt etablierte Föderationsmechanismen.

Unternehmen mit vorhandenem Identity Provider können diesen direkt anbinden. Wer noch keinen zentralen Identity Provider besitzt, kann beispielsweise auf Open-Source-Lösungen wie Keycloak setzen und diese über SSO-Föderation integrieren. Zusätzlich lässt sich durch die Einrichtung einer SCIM-Anbindung zwischen STACKIT und dem Identity Provider die Benutzerverwaltung deutlich vereinfachen, da User-Accounts und Berechtigungen automatisiert bereitgestellt und synchronisiert werden können.

Besondere Aufmerksamkeit verdienen Service Accounts. Diese sind immer organisationsgebunden und leben innerhalb von Projekten. Wer seine Landing Zone vollständig über Terraform oder die STACKIT CLI automatisieren möchte, sollte daher frühzeitig einen ausreichend berechtigten Service Account bereitstellen. Ohne diesen können spätere Automatisierungsprozesse nicht starten. Unsere Empfehlung ist es außerdem, die Authentifizierung solcher Service Accounts mit OIDC zu konfigurieren, um die Aufwände für Verwaltung und Security bezogen auf Secrets zu minimieren.

Backup-Strategien gehören in jede STACKIT Landing Zone

Ein Backup wird häufig erst dann betrachtet, wenn produktive Workloads bereits laufen. Unsere Empfehlung ist genau umgekehrt: Die Backup-Strategie sollte Teil der Landing-Zone-Planung sein.

Viele Unternehmen bringen bestehende Lösungen wie Veeam mit. Dieser Ansatz funktioniert auf STACKIT sehr gut. Der S3-kompatible Objektspeicher lässt sich problemlos als Backup-Repository nutzen und integriert sich bereits heute in die meisten etablierten Backup-Produkte. Bei PaaS-Diensten empfehlen wir aktuell weiterhin die nativen Backup-Funktionen der jeweiligen Services. Externe Backup-Lösungen bieten hier häufig noch keine ausreichende Integration.

Interessant ist außerdem die Möglichkeit, Object Lock zu verwenden. Dadurch können Backup-Daten nach dem WORM-Prinzip (Write Once Read Many) gespeichert werden. Das erhöht den Schutz vor Manipulationen und kann insbesondere im Kontext von Ransomware-Angriffen eine wichtige Rolle spielen.

Zentrales Logging mit dem Telemetry Router

Auch Logging sollte Bestandteil jeder Landing Zone sein. Mit dem Telemetry Router stellt STACKIT inzwischen einen zentralen Mechanismus bereit, um Telemetriedaten und Audit Logs aus Projekten, Foldern, Organisationen und Services zu sammeln. Über Telemetry Router Links können diese Daten zentral exportiert und in externe Log-Plattformen oder eigene Auswertungssysteme übertragen werden. Dadurch entsteht eine zentrale Sicht auf sicherheitsrelevante Ereignisse und Plattformaktivitäten. In STACKIT könnte man diese Logs beispielsweise in Services wie STACKIT Logs oder STACKIT Observability einspeisen, verarbeiten und im letzterem Beispiel auch Alerts generieren.

FinOps in STACKIT Landing Zones von Anfang an berücksichtigen

Cloud Governance endet nicht bei Sicherheit und Netzwerkdesign. Auch Kostenkontrolle sollte Bestandteil jeder Landing Zone sein. STACKIT unterstützt heute Kostenexporte im FOCUS-Format. Dadurch können Verbrauchsdaten langfristig archiviert und automatisiert ausgewertet werden.

Zusätzlich lassen sich Projekte mit Abrechnungsinformationen versehen, wodurch interne Kostenstellen oder Business Units sauber zugeordnet werden können. Projektbudgets stehen aktuell noch nicht nativ zur Verfügung. Mit den vorhandenen APIs und Kostenexporten lassen sich entsprechende Mechanismen jedoch vergleichsweise einfach selbst implementieren.

Infrastructure as Code als Betriebsmodell

Spätestens bei mehreren Projekten, Netzwerksegmenten, Service Accounts und Sicherheitsrichtlinien wird deutlich, dass sich eine STACKIT Landing Zone nicht mehr sinnvoll manuell betreiben lässt. Infrastructure as Code ist deshalb ein zentraler Bestandteil der Plattformstrategie.

Terraform bietet hierfür bereits eine sehr solide Grundlage. Auch wenn die neuesten STACKIT-Dienste nicht immer unmittelbar als native Terraform-Ressourcen verfügbar sind, stehen die zugrunde liegenden APIs in der Regel bereits bereit und können automatisiert angebunden werden. Dadurch lassen sich selbst komplexe Landing-Zone-Architekturen reproduzierbar, konsistent und revisionssicher verwalten.

Die programmatische Beschreibung der Infrastruktur bringt darüber hinaus eine Reihe weiterer Vorteile mit sich:

• Automatisierte Kosten- und Ressourcenprognosen auf Basis des tatsächlichen Codes
• Testbarkeit der Infrastruktur, z. B. zur Validierung von Sicherheitsstandards (etwa ob alle Subnetze NSGs nutzen oder ein Default-Deny-Prinzip umgesetzt ist)
• Definierte Freigabeprozesse (Approval Gates), inklusive mehrstufiger Genehmigungen vor der Umsetzung von Änderungen
• Vollständige Versionierung von Infrastrukturänderungen inklusive nachvollziehbarer Historie und Entscheidungsgrundlagen
• Möglichkeit zu statischen Code-Analysen (Linting, Security Scans, Policy Checks etc.)
• und viele weitere Automatisierungs- und Governance-Mechanismen

Unser Fazit zu STACKIT Landing Zones

Eine Landing Zone auf STACKIT besteht aus deutlich mehr als einer Netzwerkverbindung und einigen Projekten. Sie definiert die organisatorische Struktur, die Netzwerkarchitektur, Sicherheitsrichtlinien, Identitäten, Backup-Konzepte, Logging und FinOps-Prozesse, die später von allen Anwendungen genutzt werden.

Wer diese Grundlagen frühzeitig etabliert, schafft die Voraussetzung für eine Cloud-Plattform, die langfristig skalierbar, sicher und betrieblich beherrschbar bleibt. Und das ist letztlich das eigentliche Ziel einer Landing Zone.

Welche Automatisierungs-Plattform passt zu Ihrem Unternehmen?

Die Automatisierung von Geschäftsprozessen gehört inzwischen zu den wichtigsten Grundbausteinen zur Erreichung von Effizienz, Skalierbarkeit und Wettbewerbsfähigkeit. Unternehmen stehen dabei häufig vor der Frage: Soll eine klassische RPA-Plattform eingeführt werden oder reicht eine flexible Workflow-Automatisierung über APIs und Integration aus? Genau an dieser Stelle werden Automation Anywhere und n8n miteinander verglichen.

Automation Anywhere und n8n werden folgendermaßen in ihren Stärken, Gemeinsamkeiten sowie Unterschieden gegenüberstellt. Zu berücksichtigen ist, dass beide Plattformen unterschiedliche Schwerpunkte verfolgen und dabei verschiedene Automatisierungsansätze abdecken, auch wenn sie beide das gleiche Ziel der Prozessoptimierung und effizienteren Workflow-Gestaltung verfolgen.

Zwei unterschiedliche Ansätze zur Automatisierung: Automation Anywhere und n8n im Vergleich

Automation Anywhere:

Automation Anywhere ist eine in den USA entwickelte klassische Enterprise-RPA-Plattform (Robotic Process Automation), die heute weit über klassische Bot-Automatisierung hinausgeht und deshalb auch als AI- und Agentic-Process-Automation-Plattform zu bezeichnen ist. Neben der Automatisierung wiederkehrender Aufgaben über Benutzeroberflächen umfasst die Plattform klassische Bots, KI-gestützte Agenten, Dokumentenverarbeitung, Orchestrierung und Governance.

Automation Anywhere ist kein „Do-it-yourself“-Projekt, sondern bietet dem Kunden eine bereits fertige Automatisierungsmaschine, die nach eigenen Bedürfnissen konkretisiert werden kann. Ein wesentlicher Vorteil liegt in der strukturierten Steuerung und Skalierbarkeit, Rollen, Berechtigungen, Monitoring und Prozesskontrolle werden zentral verwaltet. Dadurch eignet sich Automation Anywhere insbesondere für größere Unternehmen, Banken, Versicherungen, Behörden oder Konzerne mit hohen Anforderungen an Compliance, Nachvollziehbarkeit und Governance. Der Schwerpunkt der Plattform liegt auf Prozessstandardisierung, organischer Kontrolle, Skalierbarkeit sowie der Reduzierung manueller und wiederkehrender Arbeitsschritte.

n8n:

n8n verfolgt einen anderen Automatisierungsansatz: Die Open-Source-Plattform basiert primär auf API-gestützter Workflow-Automatisierung und dient dazu Anwendungen, Datenquellen, APIs und KI-Dienste flexibel miteinander zu verbinden. Im Gegensatz zu klassischen RPA-Plattformen liegt der Fokus nicht auf der Automatisierung von Benutzeroberflächen, sondern auf der technischen Orchestrierung von Systemen und Datenflüssen. Mithilfe sogenannter „Nodes“ können Unternehmen individuelle Workflows erstellen und unterschiedlichste Anwendungen miteinander verknüpfen, ganz nach eigenem Bauprinzip. Die aus Deutschland stammende Plattform bietet hohe Flexibilität und umfangreiche Anpassungsmöglichkeiten. Gleichzeitig setzt sie ein gewisses technisches Grundverständnis voraus. Für die Anwendung ist allerdings keine klassische Softwareentwicklung notwendig.

Außerdem überzeugt die Plattform durch die wesentliche Möglichkeit des Self-Hostings. Insgesamt liefert n8n damit eine hohe Anpassungsmöglichkeit, Flexibilität sowie eine starke Datenkontrolle. Die Plattform ist auch im Lizenz-Angebot nutzbar. Im Gegensatz zu Automation Anywhere kann n8n insbesondere auch von Start-Ups und kleineren technischen Unternehmen genutzt werden. Der Schwerpunkt dieser Plattform liegt grundlegend auf Anpassbarkeit, technischer Freiheit, experimenteller Weiterentwicklung und Integration moderner KI-Services und API-basierter Prozesse.

Wann ist welche Plattform sinnvoll?

Automation Anywhere:

Automation Anywhere spielt seine Stärken insbesondere dann aus, wenn Automatisierung zentral gesteuert und unternehmensweit skaliert werden soll. Das betrifft klassische RPA-Szenarien, aber auch agentische Prozessautomatisierung mit KI-gestützten Entscheidungen, Dokumentenverarbeitung und orchestrierten Arbeitsschritten. Häufig betrifft dies größere Organisationen mit vielen standardisierten Prozessen, klaren Rollen und hohe Anforderungen an Kontrolle, Berechtigungen und Nachvollziehbarkeit. Typische Einsatzbereiche sind:

• Standardisierte Fachprozesse in Finance, HR, Einkauf, Kundenservice oder Backoffice
• UI-basierte Automatisierungen bei bestehenden Anwendungen ohne geeignete APIs sowie Arbeitsschritte, die über Benutzeroberflächen ablaufen
• Dokumentenverarbeitung und KI-gestützte Informationsauswertung
• Agentic Process Automation mit KI-Agenten
• Prozesse mit hohen Anforderungen an Governance und Compliance
• Enterprise-Automatisierungsprogramme mit vielen Bots und Nutzen

n8n:

n8n eignet sich besonders für Unternehmen, die Systeme flexibel miteinander verbinden und technisch individuelle Workflows erstellen möchten. Wichtig ist die Abgrenzung: n8n ist keine RPA-Plattform, mit der Benutzeroberflächen durch Bots automatisiert werden. Typische Einsatzbereiche sind hier:

• API-basierte Workflows und Systemintegrationen
• Automatisierung von Datenflüssen
• Verknüpfung von Cloud-Diensten und Geschäftsanwendungen
• Integration von KI-Diensten und Sprachmodellen
• Schnelle Weiterentwicklung von Prototypen und neuen Automatisierungsideen
• Self-Hosting-Szenarien mit hoher Datenkontrolle

Kosten und Betrieb: Lizenzkosten sind nur ein Teil der Entscheidung

Automation Anywhere:

Beide Plattformen bieten unterschiedliche Lizenz- und Abonnementmodelle an. Automation Anywhere richtet sich in erster Linie an größere Unternehmen und Enterprise-Umgebungen, weshalb die Einstiegskosten aufgrund individueller Bot-Lizenzen und Unternehmensverträge höher angesetzt sind. Die wirtschaftliche Bewertung hängt stark davon ab, wie viele Bots und Agenten betrieben werden, welche Prozesse automatisiert werden und wie gut die Plattform organisatorisch verankert wird. Bei der wirtschaftlichen Betrachtung sollten jedoch nicht nur Lizenzkosten berücksichtigt werden. Entscheidend sind auch Betrieb, Wartung, Governance, interne Skills und die Frage, wie viele Prozesse langfristig automatisiert werden sollen. Unternehmen erhalten mit Automation Anywhere eine Plattform, die für Governance, Skalierung, zentrale Steuerung und moderne AI- sowie Agentic-Automation-Szenarien konzipiert wurde.

n8n:

Die Plattform n8n bietet transparente Cloud-Modelle sowie eine kostenlose Open-Source-Variante. Dadurch erscheinen die Einstiegskosten häufig niedriger, allerdings sollten neben den Lizenzkosten auch Infrastruktur, Hosting, Wartung, Sicherheit, Workflow-Design, Fehlerbehandlung und interne Verantwortung berücksichtigt werden. Besonders beim Self-Hosting entstehen zusätzliche Aufgaben hinsichtlich Betrieb, Monitoring und Updates. Die tatsächlichen Kosten hängen stark von den vorhandenen technischen Kompetenzen und dem gewünschten Betriebsmodell ab. n8n kann deshalb für technisch starke Teams besonders attraktiv sein statt für Organisationen ohne klare technische Zuständigkeit. 

Technischer Aufwand, Bedienbarkeit und Stabilität

Automation Anywhere:

Die Anwendung sowie der technische Aufwand der Plattform sind gering, da eine grafische Oberfläche, mit der Automatisierung erstellt und verwaltet werden kann, zur Verfügung gestellt wird. Ohne tieferes Verständnis von Programmierungswissen können automatisierte Prozessabläufe innerhalb der Enterprise-Organisation installiert werden.

Besonders lukrativ bei Automation Anywhere: Automatische Updates, damit auf dem höchsten Stand gearbeitet werden kann. Es herrscht insgesamt weniger Eigenverantwortung und es liegen klare Enterprise-Strukturen vor. Damit kann auch mit geringeren technischem Wissen die Plattform eigenständig angewendet werden. Nachteile stellt das nötige Anpassen bei veränderter Bildschirmoberfläche dar. Die Stabilität und Performance hängt stark vom jeweiligen Anwendungsfall ab.

n8n:

Die Plattform n8n steht für Flexibilität in seiner Anwendung und Bedienbarkeit. Einhergehend ist damit allerdings ein erhöhtes technisches Grundverständnis notwendig. Eine erhöhte Unabhängigkeit und Freiheit bedeutet auch zunehmende Eigenverantwortung und unternehmerische Selbstorganisation hinsichtlich Updates, Hosting, Sicherheit und Wartungen. Damit erfordert n8n erweiterte Skills, liefert allerdings mit den wesentlichen Vorteilen der Unabhängigkeit, dem guten Verständnis von APIs, Datenmodellen, Authentifizierung, Fehlerbehandlung und Infrastruktur einen Ausgleich. Insgesamt verläuft n8n sehr stabil, da API-basierte Automatisierungen in der Regel weniger anfällig sind als bei RPA UI-Änderungen. Des Weiteren verlaufen die Schnittstellen n8ns performant und technisch fortschrittlich.

Datensouveränität und Governance: Kontrolle entsteht nicht automatisch

Automation Anywhere:

Bei Automation Anywhere werden starke Sicherheitsmechanismen und eine Enterprise-Governance geboten. Beinhaltet sind unter anderem Zugriffskontrollen, Verschlüsselungen sowie eine zentrale Verwaltung. Das ist besonders relevant, wenn viele Bots und KI-Agenten in verschiedenen Bereichen laufen oder Compliance-Anforderungen berücksichtigt werden müssen. Außerdem erhalten Kunden dieser Plattform einen Ansprechpartner und werden entsprechend beraten.

n8n:

n8n unterscheidet sich im Vergleich zu Automation Anywhere darin, dass eine erhöhte Kontrolle hinsichtlich Infrastruktur und Datenflüsse aufgrund der Self-Hosting-Option besteht. Diese Kontrolle ist aber kein Selbstläufer: Unternehmen legen selbst den Ablauf der Verwaltung, Speicherungen und Zugriffsberechtigungen fest. Allerdings besteht auch hier die Möglichkeit, auf ein Lizenz-Angebot zurückzugreifen und die Datenkontrolle auszulagern. Wer Self-Hosting betreibt, kann das Betriebssystem offline betreiben sowie eigene Cloud-Infrastrukturen integrieren. Insgesamt lautet die Frage weniger, welche Plattform grundsätzlich sicherer ist, sondern welche besser zum eigenen Betriebsmodell und den internen Anforderungen passt.

Der Faktencheck im Überblick: Der Vergleich: Automation Anywhere und n8n

Entscheidungskriterien für Unternehmen

Für die Auswahl zwischen Automation Anywhere und n8n sollten Unternehmen vor allem den eigenen Prozesskontext betrachten. Hilfreich sind fünf Fragen:

1. Läuft der Prozess hauptsächlich über Benutzeroberflächen, Schnittstellen oder KI-gestützte Entscheidungen? UI-lastige Prozesse sprechen eher für RPA, API-lastige Prozesse eher für n8n. Wenn Agenten, Dokumente, Entscheidungen und Governance zusammenspielen müssen, sollte Automation Anywhere ebenfalls geprüft werden.
2. Wird eine RPA-, AI- oder API-Automatisierung benötigt? Automation Anywhere deckt RPA und AI-gestützte Enterprise-Automatisierung ab. n8n ist stärker, wenn APIs, Datenflüsse und Integrationen im Mittelpunkt stehen.
3. Wie stark muss die Automatisierung zentral gesteuert werden? Je höher Governance- und Compliance-Anforderungen sind, desto wichtiger wird eine klare Plattformstruktur.
4. Welche technischen Fähigkeiten sind intern vorhanden? n8n bietet viel Freiheit, braucht aber technisches Verständnis im Betrieb.
5. Wie kritisch sind die automatisierten Prozesse? Geschäftskritische Workflows benötigen Monitoring, Fehlerbehandlung, Berechtigungskonzepte und klare Verantwortlichkeiten.

Fazit: Automation Anywhere oder n8n?

Grundsätzlich zeigt sich, dass keine Plattform pauschal besser ist als die andere. Sowohl Automation Anywhere als auch n8n verfolgen das Ziel der Automatisierung, setzen jedoch unterschiedliche Schwerpunkte. Automation Anywhere überzeugt besonders hinsichtlich zentraler Governance, der RPA, AI Automation, KI-Agenten sowie geringeren technischen Anforderungen. Die Plattform ist besonders attraktiv und geeignet für große Unternehmen, die durch standardisierte wiederholende Prozesse wertvolle Arbeitszeit durch RPA-Prozesse einsparen möchten. n8n überzeugt hingegen durch Flexibilität, technische Freiheit und umfangreiche Intergrationsmöglichkeiten in ihrer modernen API-Automatisierung. Der Einstieg in die Plattform ist technisch mit höheren Anforderungen verbunden, dennoch werden gezielte Verknüpfungen bestimmter Schnittstellen hergestellt, die ebenfalls der Prozessoptimierung dienen. Dabei ersetzt n8n keine klassische RPA-Plattform, sondern adressiert vor allem Integrations- und Workflow-Szenarien.

Es sollte sich also nicht die Frage gestellt werden „Welche Plattform ist besser?“, sondern vielmehr „Welche Anforderungen und strategischen Ziele verfolgt mein Unternehmen und welche Automatisierungs-Plattform kann diesen Anforderungen gerecht werden?“ In vielen Unternehmen kann deshalb sogar eine Kombination beider Ansätze sinnvoll sein: Während Automation Anywhere die Enterprise-Automatisierung mit Bots, KI und Governance übernimmt, kann n8n als flexible Integrations- und Workflow-Schicht dienen. Die beste Automatisierungsplattform ist letztlich diejenige, die optimal zum Prozess, zur Organisation und zur technischen Reife des Unternehmens passt.

Wenn Unternehmen über Automatisierung sprechen, landen sie oft sehr schnell bei Tools. Soll es n8n sein? Brauchen wir RPA? Oder ist ein KI-Agent der bessere Weg? Diese Fragen sind verständlich, aber häufig zu früh gestellt. Denn eine Technologie allein ist selten die Antwort.

Entscheidend ist zuerst, welchen Wert ein Unternehmen mit Automatisierung schaffen will. Erst danach ergibt sich, welcher technologische Ansatz passt. Manchmal ist das n8n, manchmal klassische RPA, manchmal ein KI-Agent. Und in vielen Fällen ist eine Kombination aus mehreren Ansätzen sinnvoller als die Suche nach dem einen richtigen Werkzeug.

Warum Toolvergleiche zu früh beginnen

Ein klassischer Toolvergleich wirkt auf den ersten Blick pragmatisch. Man vergleicht Funktionen, Lizenzmodelle, Integrationen, Bedienbarkeit und Herstellerstrategie. Das ist wichtig, aber nicht der erste Schritt.

Der Grund ist einfach: Viele moderne Automatisierungsplattformen können ähnliche Dinge, zumindest auf einer abstrakten Ebene. Daten übertragen, Workflows auslösen, Systeme verbinden, Oberflächen bedienen, Dokumente verarbeiten oder KI-Modelle einbinden. Der Unterschied liegt selten nur darin, ob ein Tool etwas grundsätzlich kann. Wichtiger ist, wie gut es zum konkreten Prozessmuster, zur Architektur und zur Organisation passt.

Deshalb sollte der Einstieg nicht lauten: „Welches Tool ist besser?“ Die bessere Frage lautet: Welche Use Cases erzeugen für uns Wert und welche Fähigkeiten brauchen wir dafür?

• Welche Aufgaben kosten heute Zeit, verursachen Fehler oder bremsen Entscheidungen?
• Welche Prozesse sind wiederkehrend, stabil und gut beschreibbar?
• Welche Systeme sind beteiligt und gibt es APIs oder nur Benutzeroberflächen?
• Wo braucht es menschliche Kontrolle, Freigabe oder Bewertung?
• Welche Anforderungen bestehen an Datenschutz, Berechtigungen, Betrieb und Nachvollziehbarkeit?
• Wer trägt die Verantwortung: Fachbereich, IT, Center of Excellence oder ein gemeinsames Team?

RPA: Stark bei bestehenden Oberflächen und regelbasierten Abläufen

Robotic Process Automation (RPA) ist besonders stark, wenn Prozesse über bestehende Benutzeroberflächen laufen und Systeme nicht sauber über APIs angebunden werden können. Das betrifft häufig ältere Anwendungen, Fachverfahren oder gewachsene Prozesslandschaften.

• Daten aus einer Anwendung auslesen und in eine andere übertragen
• wiederkehrende Bearbeitungsschritte in Legacy-Systemen ausführen
• strukturierte Prüfungen nach klaren Regeln durchführen
• bestehende Oberflächen automatisieren, ohne das Zielsystem direkt zu verändern

RPA ist damit nicht automatisch „alt“ oder überholt. Der Ansatz löst weiterhin ein sehr reales Problem: Viele Unternehmensprozesse laufen nicht in perfekten API-Landschaften. Sie laufen in gewachsenen Systemen, mit Medienbrüchen, manuellen Schritten und Oberflächen, die Menschen bisher bedienen mussten.

n8n: Stark bei API-, Workflow- und KI-Orchestrierung

n8n ist kein klassisches RPA-Tool. Genau das macht es für viele Use Cases interessant. Die Plattform eignet sich besonders dann, wenn Systeme über Schnittstellen verbunden werden können und technische Teams Workflows flexibel gestalten wollen.

n8n positioniert sich selbst als AI Workflow Automation Platform für technische Teams. Die Plattform verbindet visuelles Workflow-Building mit Code-Optionen, etwa JavaScript oder Python, und unterstützt Self-Hosting, Testing, Debugging und Governance-Funktionen. Damit passt n8n gut in Szenarien, in denen APIs, Events, Datenflüsse und KI-Bausteine orchestriert werden sollen.

• Daten aus mehreren Systemen per API einsammeln und weiterverarbeiten
• Benachrichtigungen, Freigaben und Folgeaktionen auslösen
• KI-Modelle in bestehende Workflows einbinden
• Informationen aus CRM, Ticketsystem, Collaboration-Tools oder Datenbanken kombinieren
• wiederkehrende Integrationsprozesse transparent abbilden

KI-Agenten: Stark bei Kontext, Sprache und variablen Entscheidungen

KI-Agenten werden oft als nächster großer Automatisierungsschritt diskutiert. Dabei ist wichtig, den Begriff sauber einzuordnen. Ein KI-Agent ist nicht einfach ein besserer Bot. Er kann Aufgaben interpretieren, Kontext nutzen, Werkzeuge aufrufen und Schritte planen. Das eröffnet neue Möglichkeiten, bringt aber auch neue Anforderungen mit sich.

• E-Mails oder Dokumente klassifizieren und einordnen
• Wissensarbeit mit wechselndem Kontext unterstützen
• Ausnahmen vorbereiten, bei denen Regeln allein nicht reichen
• Entscheidungsvorbereitung für Fachbereiche ermöglichen
• Assistenzfunktionen über mehrere Systeme hinweg aufbauen

Gleichzeitig brauchen KI-Agenten klare Grenzen. Ohne Governance, Logging, Tests, Berechtigungen und Human-in-the-Loop entstehen Risiken. Gerade im Enterprise-Kontext reicht es nicht, einen Agenten zu bauen, der in einer Demo funktioniert. Er muss nachvollziehbar, kontrollierbar und betreibbar sein.

Ein Entscheidungsmodell: Use Case vor Tool

1. Use Case und Wertbeitrag klären: Welches Problem soll gelöst werden? Wo entsteht messbarer Nutzen?
2. Prozessmuster bestimmen: Geht es um UI-Bedienung, API-Orchestrierung, Dokumentenverarbeitung, Entscheidungsvorbereitung oder Ausnahmen?
3. Systemzugänge prüfen: Gibt es stabile Schnittstellen? Müssen Oberflächen genutzt werden? Welche Datenquellen sind relevant?
4. Governance bewerten: Welche Datenschutz-, Compliance-, Rollen- und Freigabeanforderungen bestehen?
5. Betrieb mitdenken: Wer überwacht die Lösung? Wie werden Fehler behandelt? Wer ist verantwortlich?
6. Technologie auswählen: Erst jetzt werden n8n, RPA, KI-Agenten oder Kombinationen sinnvoll verglichen.

Multi-Vendor ist nicht automatisch falsch

Viele Unternehmen wünschen sich eine klare Antwort: ein Tool, eine Plattform, eine Strategie. Das ist verständlich, aber nicht immer realistisch. In der Praxis kann eine Multi-Vendor-Strategie sinnvoll sein. Zum Beispiel, wenn RPA bestehende Oberflächen stabil automatisiert, n8n API- und KI-Workflows orchestriert und spezialisierte KI-Komponenten bestimmte Aufgaben übernehmen. Entscheidend ist dann nicht die Anzahl der Tools, sondern die Architektur dahinter.

• klare Verantwortlichkeiten
• definierte Einsatzgrenzen je Technologie
• einheitliche Governance
• transparente Betriebsprozesse
• nachvollziehbare Dokumentation
• gemeinsame Sicherheits- und Datenschutzstandards

Typische Fragen aus der Praxis

• Welche Strategie verfolgen die einzelnen Technologien?
• Welche Use Cases passen wirklich zu welchem Ansatz?
• Wie sieht die Zielarchitektur aus?
• Welche Datenschutz- und Sicherheitsanforderungen müssen berücksichtigt werden?
• Wie aktuell und zukunftsfähig sind die Plattformen?
• Wo liegen Verantwortlichkeiten zwischen Fachbereich, IT und Automatisierungsteam?
• Wie finden wir geeignete Use Cases und interne Unterstützer?
• Wer übernimmt Governance, Betrieb und Weiterentwicklung?
• Wie finden wir einen Sponsor im Unternehmen?

Fazit: Erst Wertbeitrag klären, dann Technologie entscheiden

n8n, RPA und KI-Agenten beantworten unterschiedliche Fragen. RPA hilft bei regelbasierten Prozessen über bestehende Oberflächen. n8n eignet sich für API-, Workflow- und KI-Orchestrierung. KI-Agenten können Kontext, Sprache und variablere Aufgaben einbeziehen.

Die eigentliche Entscheidung beginnt aber früher. Unternehmen sollten zuerst klären, welche Use Cases Wert schaffen, welche Strategie sie mit Automatisierung verfolgen und wie Governance, Datenschutz, Architektur und Betrieb aussehen sollen. Danach wird der Toolvergleich deutlich sachlicher.

Ein guter Automatisierungsansatz ist selten die Wahl eines einzelnen Werkzeugs. Er ist die Verbindung aus Use Case, Zielbild, Technologie, Verantwortlichkeit und Betrieb. Genau dort entsteht der eigentliche Mehrwert.