Der Kerngedanke von RPA ist schnell erklärt: Überall dort, wo keine saubere Schnittstelle (API) zwischen zwei Systemen existiert, übernimmt ein Roboter die manuelle Bedienung. Er meldet sich in einer Web- oder Desktop-Anwendung an, überträgt Daten aus einer Excel-Tabelle in eine Buchhaltungsmaske, liest eine Bestätigungsnummer aus und schreibt sie zurück – Aufgaben, die sonst ein Mensch stur und fehleranfällig per Copy-and-paste erledigt. Power Automate positioniert diese Fähigkeit als eine von mehreren: Neben den Desktop flows für die Oberflächen-Automatisierung stehen die Cloud flows, die über hunderte vorgefertigte Konnektoren direkt mit Diensten wie SharePoint, Outlook, Teams, Dynamics 365 oder auch Fremdsystemen sprechen.
Drei Eigenschaften definieren Power Automate RPA und erklären seine Marktstellung im DACH-Raum:
Im Marketing verschwimmen die Bezeichnungen, deshalb lohnt die Klarstellung. Robotic Process Automation (RPA) ist die Disziplin, repetitive Bildschirmarbeit durch Software-Roboter zu übernehmen. Bei Power Automate ist diese Fähigkeit in den Desktop flows gebündelt – sie laufen auf einem Windows-Rechner und automatisieren Desktop- und Web-Oberflächen. Die Cloud flows hingegen sind serverseitige Abläufe, die über Konnektoren und Auslöser (Trigger) Ereignisse in Cloud-Diensten verarbeiten, ganz ohne Oberflächen-Steuerung. Wer diese Ebenen unterscheidet, versteht die zentrale Design-Frage jedes Projekts: Wo genügt eine saubere Konnektor-Anbindung, und wo ist die Oberflächen-Automatisierung der einzige Weg?
Power Automate nimmt eine besondere Stellung im Markt ein. Anders als die spezialisierten RPA-Anbieter, die als reine Automatisierungsplattformen groß geworden sind, ist Power Automate Teil eines umfassenden Ökosystems. Microsoft verfolgt damit die Strategie, Automatisierung nicht als Zusatzprodukt, sondern als Querschnittsfähigkeit über die gesamte Produktivitäts- und Cloud-Welt anzubieten. Für Anwenderunternehmen bedeutet das eine große Reichweite und viele Berührungspunkte, aber auch die Notwendigkeit, sich im breiten Lizenz- und Funktionsangebot zurechtzufinden. Wer die Landkarte kennt, kann den Nutzen gezielt heben; wer sie nicht kennt, verliert sich leicht in der Fülle der Bausteine.
Die grundlegende Zweiteilung von Power Automate ist entscheidend. Cloud flows laufen in der Microsoft-Cloud und reagieren auf Ereignisse – eine neue E-Mail, eine neue Zeile in einer Liste, ein eingehendes Formular. Sie orchestrieren die Logik über Konnektoren, ohne je eine Bildschirmoberfläche zu berühren. Desktop flows hingegen sind der eigentliche RPA-Teil: Sie laufen auf einem Windows-Rechner und bedienen dort Anwendungen wie ein Mensch. In der Praxis werden beide oft kombiniert: Ein Cloud flow nimmt das auslösende Ereignis entgegen, ruft bei Bedarf einen Desktop flow für die Oberflächen-Arbeit auf und führt das Ergebnis danach wieder in die digitale Prozesskette zurück.
Der Unterschied zwischen den beiden Betriebsmodi ist für Planung und Kosten zentral. Im attended-Modus arbeitet der Roboter Hand in Hand mit einem Menschen an dessen Arbeitsplatz. Das eignet sich für Assistenzszenarien, in denen ein Sachbearbeiter einen wiederkehrenden Teilschritt an den Bot abgibt, aber die Gesamtkontrolle behält. Im unattended-Modus läuft der Roboter dagegen selbstständig auf einer dafür vorgesehenen Maschine – zeit- oder ereignisgesteuert, ohne menschliche Anwesenheit. Dieser Modus ist die Voraussetzung für echte Skalierung: hohe Stückzahlen, Nachtläufe, Batch-Verarbeitung. Er erfordert aber eine eigene Lizenz- beziehungsweise Kapazitätszuordnung und ein durchdachtes Berechtigungs- und Betriebskonzept, weil der Bot unbeaufsichtigt auf Fachsysteme zugreift.
Power Automate versteht sich nicht als reines RPA-Werkzeug, sondern als Automatisierungsschicht der Power Platform – gemeinsam mit Power Apps (Low-Code-Anwendungen), Power BI (Analyse) und Power Pages (Web-Portale). Diese Einbettung ist strategisch: Microsoft adressiert damit sowohl die Fachanwenderin, die sich einen kleinen Ablauf selbst zusammenklickt, als auch die IT-Abteilung, die unternehmensweite, gesteuerte Automatisierung betreiben will. Die Kehrseite dieser Breite ist ein vielschichtiges Lizenz- und Kapazitätsmodell, das ohne Überblick schwer zu durchdringen ist – ein Punkt, auf den wir in Kapitel 09 zurückkommen. Für die Einordnung genügt zunächst: Power Automate ist so konzipiert, dass RPA nur ein – wenn auch prominenter – Baustein eines größeren Automatisierungsangebots ist.
Herzstück der RPA-Fähigkeit ist der Aufbau von Desktop flows mit einer eigenen Entwurfsumgebung. Dort steht ein umfangreicher Katalog vorgefertigter Aktionen bereit: Anwendungen starten, Fenster fokussieren, Felder befüllen, Schaltflächen klicken, Text aus Oberflächen auslesen, mit Dateien und Ordnern arbeiten, Excel-Arbeitsmappen automatisieren, Webseiten steuern und Daten zwischen Systemen übertragen. Ein Recorder erlaubt es, Arbeitsschritte am Bildschirm mitzuschneiden und daraus einen ersten Ablauf zu erzeugen – ein niederschwelliger Einstieg, der allerdings für robuste Produktionsprozesse meist nachbearbeitet werden muss. Für stabile Automatisierungen ist die Art der Element-Erkennung entscheidend: Ein Roboter, der Oberflächenelemente zuverlässig über ihre technischen Eigenschaften anspricht, ist deutlich weniger fehleranfällig als einer, der sich nur auf Bildschirmkoordinaten oder Bildvergleich verlässt.
Die zweite Säule sind die Konnektoren. Power Automate bringt eine sehr große Zahl vorgefertigter Anbindungen mit – für Microsoft-Dienste wie SharePoint, Outlook, Teams, OneDrive, Dynamics 365 und den Dataverse-Datenspeicher ebenso wie für viele Drittsysteme. Diese Konnektoren erlauben es, ohne Programmierung Daten zu lesen und zu schreiben, Nachrichten zu senden, Dateien zu verwalten oder Datensätze anzulegen. Wo ein System keinen fertigen Konnektor mitbringt, lassen sich generische Wege über offene Schnittstellen oder eigene Konnektoren nutzen. In der Praxis gilt die Faustregel: Alles, was sich über einen Konnektor lösen lässt, sollte auch über einen Konnektor gelöst werden – die Oberflächen-Automatisierung per Desktop flow bleibt der Sonderfall für Systeme ohne brauchbare Schnittstelle.
Der dritte Bereich sind die Auslöser. Ein Ablauf kann manuell per Knopfdruck, nach Zeitplan, durch ein Ereignis (etwa eine eingehende E-Mail oder ein neues Element in einer Liste) oder durch einen anderen Ablauf gestartet werden. In der Verbindung von Cloud flow und Desktop flow entsteht so eine durchgängige Orchestrierung: Das auslösende Ereignis wird in der Cloud verarbeitet, für die Oberflächen-Arbeit auf einen Roboter übergeben und das Ergebnis wieder eingesammelt. Für den unbeaufsichtigten Betrieb kommt die Steuerung der Roboter-Maschinen hinzu – die Frage, welcher Bot auf welcher Maschine wann läuft, wie Warteschlangen abgearbeitet und Fehler behandelt werden. Diese Orchestrierungslogik ist für die Zuverlässigkeit im Produktivbetrieb mindestens so wichtig wie die einzelnen Aktionen im Ablauf selbst.
Ein oft unterschätzter Teil des Funktionsumfangs ist alles, was einen Ablauf produktionsreif macht: strukturierte Fehlerbehandlung, damit ein Bot bei einer unerwarteten Situation nicht einfach abbricht, sondern kontrolliert reagiert; Protokollierung, damit im Fehlerfall nachvollziehbar ist, was geschah; und die Wiederverwendung von Teil-Abläufen, damit nicht jede Automatisierung von null beginnt. Power Automate stellt hierfür Mechanismen bereit, doch ihr Einsatz ist eine Frage der Disziplin. In der Praxis unterscheidet genau diese Sorgfalt einen bastelnden Einzel-Flow von einer belastbaren Automatisierung, die auch nach Monaten und über Systemänderungen hinweg zuverlässig läuft.
AI Builder bringt vorgefertigte und trainierbare KI-Funktionen direkt in die Power Platform. Für die Automatisierung besonders relevant ist die Dokumentverarbeitung: Aus Rechnungen, Formularen oder Belegen lassen sich strukturierte Daten extrahieren, ohne dass ein Mensch sie abtippt. Ein Roboter kann so eine eingehende PDF-Rechnung erkennen, die relevanten Felder auslesen und in ein Buchhaltungssystem übertragen. Weitere Bausteine adressieren Textklassifikation, Stimmungsanalyse, Objekterkennung in Bildern oder Vorhersagen. Der Reiz liegt darin, dass diese Fähigkeiten als Aktionen in einen Ablauf eingefügt werden können – die Grenze zwischen regelbasierter RPA und KI-gestützter Verarbeitung verschwimmt, was gerade bei halbstrukturierten Eingaben wie Dokumenten den Automatisierungsgrad deutlich erhöht.
Der zweite große KI-Baustein ist Copilot. Die Idee: Statt einen Ablauf mühsam Aktion für Aktion zusammenzuklicken, beschreibt die Anwenderin in natürlicher Sprache, was passieren soll – etwa „Wenn eine E-Mail mit Anhang eingeht, speichere den Anhang in SharePoint und benachrichtige das Team“ –, und Copilot erzeugt daraus einen Entwurf. Ebenso soll Copilot beim Anpassen, Erklären und Fehlersuchen unterstützen. Das Potenzial ist erheblich, weil es Automatisierung für Menschen zugänglich macht, die keine Entwickler sind. Zugleich gilt ein nüchterner Praxis-Vorbehalt: Ein per Sprache erzeugter Entwurf ist ein Ausgangspunkt. Für einen robusten, wartbaren Produktivprozess braucht es weiterhin Fachverständnis, saubere Fehlerbehandlung und Tests – die KI beschleunigt den Start, ersetzt aber nicht die Sorgfalt.
Der eigentliche Mehrwert entsteht im Zusammenspiel. Klassische RPA ist stark bei klaren, regelbasierten Abläufen, stößt aber an Grenzen, sobald Eingaben unstrukturiert oder variabel sind – ein Rechnungsformat, das leicht abweicht, eine E-Mail in freier Formulierung. Genau hier ergänzt die KI: Sie bringt die nötige Deutung ins Spiel, die feste Regeln nicht leisten können. Ein typischer kombinierter Ablauf sieht so aus: Ein Cloud flow fängt eine eingehende Nachricht ab, AI Builder liest das angehängte Dokument aus, eine Regel prüft die extrahierten Werte, und ein Desktop flow überträgt sie in ein Fachsystem ohne Schnittstelle. Diese Kette aus Erkennen, Prüfen und Ausführen ist das, was Microsoft unter dem Schlagwort der intelligenten Automatisierung fasst – und sie ist im Mittelstand oft der Punkt, an dem aus einer netten Einzelautomatisierung ein echter Prozessvorteil wird.
Der Großteil der Büroarbeit im DACH-Mittelstand spielt sich in Microsoft-365-Anwendungen ab: E-Mails in Outlook, Dateien in SharePoint und OneDrive, Zusammenarbeit in Teams, Daten in Excel. Power Automate setzt genau hier an. Abläufe können auf neue E-Mails reagieren, Anhänge automatisch ablegen, Excel-Tabellen befüllen und auswerten, Genehmigungen über Teams einholen oder Benachrichtigungen versenden. Weil diese Dienste ohnehin lizenziert und verbreitet sind, ist die erste Automatisierung oft nur wenige Schritte entfernt. Dieser niederschwellige Einstieg ist ein wesentlicher Grund für die breite Akzeptanz – gerade bei Fachanwendern, die kein Entwicklerteam im Rücken haben.
Die Desktop-Automatisierung ist eng mit Windows verbunden – dem Betriebssystem, auf dem im Mittelstand die allermeisten Fachanwendungen laufen. Das erleichtert die Automatisierung von Desktop-Software, die keine moderne Schnittstelle bietet. Als gemeinsame Datendrehscheibe dient Dataverse, der strukturierte Datenspeicher der Power Platform: Hier lassen sich Daten zentral, sicher und mit Berechtigungen versehen ablegen, auf die dann Automatisierungen, Apps und Analysen gemeinsam zugreifen. Für durchgängige Szenarien – etwa eine selbst gebaute Antragsanwendung, deren Freigaben automatisiert und deren Kennzahlen ausgewertet werden – ist dieses Zusammenspiel ein echter Architekturvorteil.
Power Automate steht nicht allein, sondern ist eine Säule der Power Platform. Neben ihm stehen Power Apps für Low-Code-Anwendungen, Power BI für Datenanalyse und Power Pages für externe Web-Portale. Der Vorteil dieser Bündelung: Automatisierungen bleiben nicht isoliert, sondern lassen sich in umfassendere Lösungen einbetten. Ein Vorgang, der in einer selbst gebauten App angestoßen wird, kann durch Power Automate verarbeitet, in Dataverse gespeichert und in Power BI ausgewertet werden. Für den Mittelstand bedeutet das die Chance, mit überschaubaren Mitteln maßgeschneiderte digitale Prozesse zu bauen, ohne für jeden Baustein ein eigenes Produkt beschaffen und integrieren zu müssen.
Trotz der Microsoft-Nähe ist Power Automate nicht auf die eigene Welt beschränkt. Über Konnektoren, offene Schnittstellen und selbst gebaute Anbindungen lassen sich auch Nicht-Microsoft-Systeme einbinden – vom ERP über CRM-Systeme bis zu Branchensoftware. Realistisch bleibt aber festzuhalten: Der Komfort ist am größten innerhalb des Microsoft-Kosmos, und je weiter man sich davon entfernt, desto mehr Eigenleistung ist gefragt. Für Unternehmen mit stark heterogener, wenig Microsoft-lastiger Systemlandschaft relativiert sich der Heimvorteil entsprechend. Das ist kein Ausschlusskriterium, aber ein ehrlich einzupreisender Faktor bei der Werkzeugwahl – und einer der Punkte, an denen sich der Vergleich mit den spezialisierten RPA-Anbietern lohnt, den das nächste Kapitel zieht.
Aus unserer Beratungspraxis sind die Stärken klar. Erstens, wenn die IT-Landschaft ohnehin auf Microsoft aufsetzt – dann sind Beschaffung, Integration und Akzeptanz kaum zu schlagen, und viele Automatisierungen starten quasi aus dem Stand. Zweitens, wenn Fachbereiche selbst automatisieren sollen: Der Low-Code-Anspruch und die Copilot-Unterstützung senken die Einstiegshürde für Nicht-Entwickler deutlich. Drittens, wenn RPA nur ein Baustein einer breiteren digitalen Lösung ist – die Einbettung in Power Apps, Power BI und Dataverse erlaubt durchgängige Szenarien, die ein reines RPA-Werkzeug so nicht bietet. Für den typischen DACH-Mittelständler mit Microsoft-Kern ist Power Automate deshalb häufig der pragmatische Startpunkt.
Ebenso ehrlich gehören die Gegenfälle benannt. UiPath und Automation Anywhere sind aus dem klassischen Enterprise-RPA gewachsen und bringen bei sehr großen, streng gesteuerten Bot-Flotten, anspruchsvoller Orchestrierung und ausgereiften Governance-Werkzeugen oft mehr Reife mit. Blue Prism ist traditionell stark, wo strenge Kontrolle, Nachvollziehbarkeit und der Betrieb im eigenen Rechenzentrum im Vordergrund stehen – etwa in stark regulierten Branchen. Wer eine hochskalierte, zentral orchestrierte RPA-Fabrik mit hunderten unbeaufsichtigten Robotern und strengen Compliance-Anforderungen plant, sollte diese Anbieter fair in den Vergleich nehmen. Und wo die Systemlandschaft kaum Microsoft-Bezug hat, schrumpft der Heimvorteil von Power Automate spürbar.
Ein Blick auf die Marktbewegung hilft bei der Einordnung. RPA, Process Mining, Low-Code und KI verschmelzen zunehmend zu einem, was der Markt Hyperautomatisierung nennt. Microsoft treibt diese Verschmelzung besonders sichtbar voran, indem es RPA, Cloud-Workflows, KI und Analyse unter einem Dach bündelt. Für Anwenderunternehmen bedeutet das zweierlei: Erstens verwischt die Frage „welches RPA-Tool“ immer stärker zur Frage „welche Automatisierungsarchitektur insgesamt“. Zweitens gewinnt die Fähigkeit, verschiedene Bausteine sauber zu kombinieren, an Bedeutung. Gerade hier spielt Power Automate seine Stärke aus – sofern das Fundament aus Microsoft-Diensten schon steht.
Power Automate wird als Cloud-Dienst betrieben; die Verwaltung erfolgt über Umgebungen, in denen Abläufe, Daten und Berechtigungen gebündelt sind. Für einen sauberen Betrieb empfiehlt sich die Trennung von Entwicklungs-, Test- und Produktionsumgebungen, damit Änderungen erprobt werden, bevor sie produktiv gehen. Das Rollenmodell unterscheidet qualitativ zwischen denen, die Abläufe erstellen und teilen, denen, die Umgebungen und Richtlinien verwalten, und den administrativen Rollen, die plattformweite Einstellungen und Sicherheitsvorgaben steuern. Wichtig ist, diese Rollen bewusst zu vergeben und nicht jedem alles zu erlauben – gerade weil die Plattform so niederschwellig ist, dass ohne Steuerung schnell viele kleine, unkoordinierte Automatisierungen entstehen.
Ein Punkt, den wir in Projekten immer wieder betonen: RPA ist kein einmaliges Bauprojekt, sondern ein Dauerposten. Oberflächen-Bots sind naturgemäß empfindlich gegenüber Änderungen der Zielsysteme – ein Update der Fachanwendung, ein verschobener Button, ein geändertes Anmeldeverfahren kann einen zuvor stabilen Ablauf brechen. Wer die laufende Wartung nicht von Anfang an einplant und verantwortlich verankert, erlebt nach Monaten stille Ausfälle, die niemand bemerkt, bis ein Vorgang liegen bleibt. Die realistische Kalkulation eines RPA-Vorhabens umfasst deshalb immer auch den Betrieb – nicht nur die Erstellung.
Im Mittelstand beginnen die meisten Automatisierungen bei den alltäglichen Datenübertragungen zwischen Systemen ohne Schnittstelle: Stammdaten aus einer Excel-Liste in ein ERP übernehmen, Bestellbestätigungen aus E-Mails in ein Auftragssystem übertragen, wiederkehrende Berichte aus mehreren Quellen zusammenstellen und versenden, oder Rechnungen erfassen und in die Buchhaltung überführen. Diese Aufgaben sind hochvolumig, regelbasiert und binden bislang wertvolle Arbeitszeit – ein idealer Startpunkt. Weil die zugrunde liegenden Office-Daten ohnehin in Microsoft 365 liegen, ist der Weg zur ersten Automatisierung kurz, was gerade Unternehmen ohne eigene Entwicklungsabteilung entgegenkommt.
In unserer Projekterfahrung entscheidet weniger die Technik über den Erfolg als das Vorgehen. Erfolgreich sind Unternehmen, die klein und wertstark starten, den ersten Prozess sauber umsetzen und Betrieb wie Wartung von Beginn an mitdenken. Scheitern sehen wir dort, wo drei Fehler auftreten: Erstens der Versuch, sofort alles zu automatisieren, statt einen belastbaren Piloten zu bauen. Zweitens das Ignorieren der Governance, sodass unkontrolliert viele kleine Bots entstehen, die niemand überblickt. Und drittens das Unterschätzen der Wartung – Oberflächen-Bots brechen, wenn sich Zielsysteme ändern, und ohne Verantwortlichen bleibt das lange unbemerkt. Wer diese Fallen kennt, umgeht sie leicht.
Die Kostenstruktur von Power Automate ist mehrschichtig und einer der Punkte, an denen Projekte ohne Überblick teuer werden. Grundlegende Cloud-Automatisierung ist in vielen Microsoft-365-Plänen bereits in Grundzügen enthalten, sodass einfache Abläufe ohne Zusatzkosten möglich sind. Die eigentliche RPA-Fähigkeit – die Desktop flows, besonders im unbeaufsichtigten Betrieb – sowie erweiterte Funktionen und KI-Bausteine erfordern jedoch zusätzliche, kostenpflichtige Lizenzen beziehungsweise Kapazitäten. Entscheidend für die Kalkulation ist die Unterscheidung, ob pro Nutzer, pro Ablauf oder über Kapazität für unbeaufsichtigte Roboter lizenziert wird. Konkrete Preise ändern sich und hängen von Plan, Region und Vertragskonstellation ab – sie sind immer beim Anbieter beziehungsweise Partner zu prüfen.
Die richtige Frage lautet nicht „Was kostet die Lizenz?“, sondern „Welche Gesamtkosten stehen welchem Nutzen gegenüber?“. Zur Gesamtbetrachtung (Total Cost of Ownership) gehören Lizenzen und Kapazitäten, die Infrastruktur für unbeaufsichtigte Bots, die einmalige Umsetzung und – besonders wichtig – die laufende Wartung. Dem gegenüber steht der realisierte Nutzen: eingesparte Arbeitszeit, weniger Fehler, schnellere Durchlaufzeiten. Weil sich seriöse Pauschalpreise verbieten, ersetzen wir Wunschzahlen durch ein Prinzip: Stellen Sie die realistisch eingesparte Zeit eines konkreten Prozesses den Gesamtkosten seiner Automatisierung samt Betrieb gegenüber. Übersteigt der Nutzen die Kosten mehrfach und stabil, trägt die Investition. Bleibt der Nutzen vage oder klein, ist das ein Warnsignal – dann ist der Prozess falsch gewählt oder die Automatisierung überdimensioniert.
Power Automate ist ein Dienst von Microsoft, einem US-Anbieter – ein Umstand, der im DACH-Raum berechtigte Datenschutzfragen aufwirft. Zugleich bietet Microsoft mit den Azure-Rechenzentren EU-Regionen und mit der EU-Datengrenze ein Konzept, das die Verarbeitung und Speicherung bestimmter Kundendaten innerhalb der EU vorsieht. Das kann ein gewichtiger Vorteil gegenüber Anbietern ohne vergleichbare regionale Option sein – ist aber kein Automatismus: Welche Region tatsächlich genutzt wird, welche Datenkategorien erfasst sind und wie mit Subprozessoren und etwaigen Drittlandbezügen umgegangen wird, muss konkret geprüft und vertraglich abgesichert werden. Serverstandort und Datenfluss gehören ausdrücklich benannt, und der Auftragsverarbeitungsvertrag (AVV/DPA) samt technisch-organisatorischer Maßnahmen ist die Grundlage jeder konformen Nutzung.
Ein Aspekt verdient im DACH-Mittelstand besondere Aufmerksamkeit: Ein unbeaufsichtigter Roboter meldet sich eigenständig mit einem technischen Konto an Fachsystemen an und verarbeitet Daten ohne menschliche Kontrolle im Moment der Ausführung. Das macht das Berechtigungskonzept sicherheitskritisch. Solche Bot-Konten sollten strikt nach dem Prinzip der minimalen Rechte ausgestattet werden – nur so viel Zugriff wie für den konkreten Prozess nötig –, ihre Anmeldedaten gehören in eine sichere Verwaltung und nicht in den Ablauf selbst, und ihre Aktivitäten sollten protokolliert und überwacht werden. Datensparsamkeit ist dabei nicht nur eine rechtliche Anforderung, sondern verkleinert zugleich die Angriffsfläche. Wer diese Sorgfalt an den Anfang stellt, betreibt unbeaufsichtigte Automatisierung verantwortbar.
