**Constantin Budin**, Lead Consultant Data & AI bei Pexon Consulting | 9 Min. Lesezeit | 01.10.2026
TL;DR: Automation Engineer in fünf Sätzen
Ein Automation Engineer macht aus Tickets, Routineaufgaben und Medienbrüchen laufende, betriebene Automatisierung. Er entscheidet mit dem Fachbereich, was sich lohnt, baut mit dem passenden Werkzeug und betreut den Betrieb. Pexon Consulting stellt diese Rolle als Dienstleistung bereit, eingebettet im Team, mit dem Einstieg Automation Start ab 15.000 €.
Das Problem: Bauen ist einfach geworden, Automatisieren nicht
Vor ein paar Jahren war ein Workflow zwischen zwei Systemen ein kleines Projekt. Heute baut ein Fachbereich mit n8n oder Power Automate an einem Nachmittag den ersten Entwurf, und ein Coding-Agent schreibt das Skript für den Rest. Das Bauen ist billig geworden.
Und trotzdem stapeln sich die Tickets. Der Service-Desk beantwortet jede Woche dieselben Anfragen, der Fachbereich gleicht weiter Excel-Listen ab, und die drei Workflows vom letzten Quartal laufen, aber niemand weiß mehr genau, wer sie ändern darf.
Der Grund liegt nicht beim Werkzeug. Er liegt davor und danach. Davor fehlt die Entscheidung, welche Aufgabe überhaupt automatisiert wird. Danach fehlt jemand, dem der Workflow gehört: Zugriffe, Fehlerfälle, Änderungen an der Schnittstelle, die nächste Version. Genau diese Lücke füllt ein Automation Engineer.
Was ein Automation Engineer konkret tut
Ein Automation Engineer ist eine Rolle, kein Produkt. Er übernimmt wiederkehrende Arbeit aus Tickets und Fachbereichen, verwandelt sie in Automatisierung und sorgt dafür, dass sie im Betrieb bleibt. In der Praxis sind das fünf Tätigkeiten, die in dieser Reihenfolge ablaufen:
- Sammeln: Tickets, Routineaufgaben und Wünsche aus den Fachbereichen landen an einer Stelle, mit Häufigkeit, Dauer und Ansprechperson.
- Priorisieren: Gemeinsam mit dem Fachbereich entscheidet er nach klaren Kriterien, was zuerst drankommt. Wie das geht, beschreibt der Beitrag Was automatisieren zuerst.
- Bauen: Er nimmt das Werkzeug, das zur Landschaft passt: n8n, Power Automate, ein Python-Skript, eine API-Integration oder ein Agent mit Freigabeschritt.
- Einbetten: Zugriffe mit minimalen Rechten, ein Owner im Fachbereich, Dokumentation und ein Runbook, bevor der Workflow live geht.
- Betreiben: Monitoring, Fehlerbehandlung und Anpassungen, wenn sich ein Vorsystem ändert.
Der Satz, der die Rolle am kürzesten beschreibt: Aus jedem wiederkehrenden Ticket wird ein Entscheid, ob es automatisiert, vereinfacht oder bewusst gelassen wird. Das ist weniger Programmierung, als man bei dem Titel vermutet, und mehr Zuhören im Fachbereich.
Automation Engineer, RPA-Entwickler und Citizen Developer: die Abgrenzung
Die drei Begriffe werden ständig verwechselt. Dabei unterscheiden sie sich genau an den beiden Stellen, die zählen: wer entscheidet, was automatisiert wird, und wer den Betrieb trägt.
| Kriterium | RPA-Entwickler | Citizen Developer | Automation Engineer |
|---|---|---|---|
| Aufgabe | Baut Bots für vorgegebene Prozesse | Baut eigene Flows im Fachbereich | Findet, priorisiert, baut und betreibt |
| Entscheidung, was automatisiert wird | Kommt vom Auftraggeber | Entsteht im eigenen Fachbereich | Gemeinsam mit dem Fachbereich nach Kriterien |
| Werkzeuge | Meist eine RPA-Plattform | Low-Code im eigenen Bereich | Tool-neutral: Low-Code, Skripte, APIs, Agenten |
| Betrieb | Oft vom Bau getrennt | Beim Fachbereich, selten abgesichert | Bau und Betrieb in einer Hand |
| Passt, wenn | Prozess und Plattform feststehen | Einfache Flows im eigenen Team genügen | Der Backlog größer ist als die Kapazität |
Unsere klare Position: Citizen Developer sind gut und sollten bleiben. Wir haben dazu einen eigenen Beitrag, n8n und Citizen Developer: Automatisierung ohne IT. Aber ein Fachbereich, der nebenbei Workflows baut, kann den Betrieb und die Priorisierung über mehrere Bereiche nicht auch noch tragen. Dafür braucht es jemanden, dessen Hauptaufgabe genau das ist.
Tool oder Rolle: warum eine Lizenz keine Automatisierung liefert
Wer Automatisierung einkaufen will, landet meist zuerst bei einem Werkzeug. Das ist nachvollziehbar, und die Werkzeuge sind gut. n8n ist als Open-Source-Plattform dokumentiert (n8n Docs), und die Power Platform bringt hunderte Konnektoren mit (Microsoft Learn: Power Automate). Wie n8n bei Pexon aufgesetzt und betrieben wird, steht auf der Seite n8n Workflow-Automatisierung.
Nur: Die Lizenz erzeugt Workflows, sie wählt keine aus. Sie klärt keine Zugriffe, benennt keinen Owner und reagiert nicht, wenn die API des Vorsystems am Montag anders antwortet. Wir sehen das Muster häufig: Tool eingeführt, drei Quick Wins, dann Stillstand.
Das ist der Unterschied zwischen Software konfigurieren und Automatisierung liefern. Das eine ist ein Produkt, das andere sind Menschen plus Delivery. Ein Automation Engineer ist deshalb die Rolle, die das Werkzeug erst nützlich macht.
Stelle besetzen oder als Dienstleistung einbetten?
Die ehrliche Frage lautet: Brauchen Sie die Rolle fest im Haus, oder reicht sie als Service? Beides ist legitim, aber die Abwägung fällt anders aus, als es zunächst scheint.
| Kriterium | Eigene Stelle | Tool-Lizenz allein | Automation Engineering als Service |
|---|---|---|---|
| Startzeit | Recruiting, danach Einarbeitung | Sofort, aber ohne Owner | Nach Scoping, Einstieg mit Workshop |
| Ausfallrisiko | Wissen hängt an einer Person | Keiner betreibt | Team statt Einzelperson |
| Breite | Selten Tools, Integration, Agenten und Betrieb zugleich | Nur das Werkzeug | Je nach Fall das passende Werkzeug |
| Kosten | Fix, auch bei leerem Backlog | Lizenz, ohne Delivery | Nach Scoping, skalierbar mit dem Backlog |
| Passt, wenn | Dauerhaft hoher, stabiler Bedarf | Wenige einfache Flows | Der Bedarf wächst und schwankt |
Unsere Empfehlung: Wer bei null startet, sollte die Rolle zuerst als Dienstleistung testen. Ein Einstieg zeigt, wie viel Backlog wirklich da ist und welche Fähigkeiten gebraucht werden. Erst danach lohnt sich die Frage, ob eine Stelle im Haus oder die Übergabe an das eigene Team sinnvoll ist.
Dahinter steckt ein Gedanke, der oft übersehen wird. Die Nachfrage nach Automatisierung ist praktisch unbegrenzt: Jede erledigte Aufgabe zeigt die nächste. Ein einmaliges Projekt mit Festpreis deckt das nicht ab. Deshalb passen Retainer, Enablement oder ein eingebettetes Modell besser, bei dem der Backlog laufend abgearbeitet wird.
Wohin die freie Zeit geht: Redeploy statt Abbau
Automatisierung wird gern mit Stellenabbau verwechselt. Wir sehen es anders und sagen das auch im Erstgespräch: Das Ziel ist, die frei werdende Zeit fest einer neuen Aufgabe zuzuordnen, etwa Kundenarbeit, Analyse oder der nächsten Automatisierung. Ohne diese Zuordnung versickert der Gewinn in der nächsten Ticket-Welle.
Ein Automation Engineer unterstützt das praktisch. Er dokumentiert, welche Routine entfällt, und gibt dem Fachbereich damit eine Grundlage, die Kapazität bewusst zu verlagern. Konkrete Projektzahlen dazu veröffentlichen wir erst, wenn ein Kunde sie freigibt. Erfundene Beispiele gibt es bei uns nicht.
Wann ein Automation Engineer nichts bringt
Nicht jedes Haus braucht die Rolle. Es gibt drei klare Fälle, in denen wir abraten:
- Zwei oder drei einfache Flows: Dann reicht ein Citizen Developer oder ein kleines Einzelprojekt.
- Kein Systemzugriff: Ohne Zugriff auf die beteiligten Systeme baut auch der beste Engineer nur Attrappen. Erst Zugriff klären, dann starten.
- Kein Owner im Fachbereich: Ein Workflow ohne Besitzer verfällt. Wir bauen ihn nicht, solange niemand die Verantwortung übernimmt.
Auch das Betriebsmodell hat eine Grenze: Wir betreuen 8×5, also an Werktagen mit Monitoring und Reaktion. Ein 24/7-Betrieb ist kein Standardversprechen.
Was der Einstieg kostet
Zu den Preisen nennen wir nur, was auf unseren Angebotsseiten steht (Stand 01.10.2026). Der Einstieg ist das Paket Automation Start ab 15.000 €: ein eintägiger Potenzial-Workshop für einen Prozess, Analyse und Dokumentation, ein Prototyp mit Live-Demo, Aufwandsschätzung und Roadmap-Empfehlung. Details stehen unter Process Automation Consulting.
Gehört ein KI-Assistent dazu, startet das 6-Wochen-Pilotprojekt ab 30.000 €. Für das eingebettete Modell danach nennen wir bewusst keinen Monatspreis. Zuschnitt und Endpreis entstehen nach dem Scoping, weil sie vom Backlog, vom Werkzeug-Mix und vom Betriebsumfang abhängen.
Häufig gestellte Fragen
Was ist ein Automation Engineer?
Ein Automation Engineer macht aus wiederkehrender Arbeit wie Tickets, Routineaufgaben und Medienbrüchen betriebene Automatisierung. Er wählt gemeinsam mit dem Fachbereich aus, was sich lohnt, baut Workflows mit dem passenden Werkzeug und betreut sie im Betrieb.
Was macht ein Automation Engineer anders als ein RPA-Entwickler?
Ein RPA-Entwickler baut Bots für Prozesse, die feststehen. Ein Automation Engineer entscheidet zusätzlich mit, was automatisiert wird, nutzt auch Skripte, APIs und Agenten und trägt den Betrieb. Die Plattform ist für ihn Mittel, nicht Ausgangspunkt.
Was kostet ein Automation Engineer als Dienstleistung?
Der Einstieg ist das Paket Automation Start ab 15.000 € für einen Prozess, inklusive Workshop, Prototyp und Kostenschätzung. Mit KI-Assistent startet der 6-Wochen-Pilot ab 30.000 €. Für das eingebettete Modell legen wir den Preis nach dem Scoping fest.
Stelle besetzen oder Dienstleister: was ist besser?
Das hängt vom Bedarf ab. Bei dauerhaft hohem, stabilem Bedarf lohnt eine eigene Stelle. Bei wachsendem oder schwankendem Backlog ist die Dienstleistung flexibler und weniger abhängig von einer Person. Viele starten als Service und entscheiden danach.
Wann lohnt sich ein Automation Engineer nicht?
Bei nur wenigen einfachen Flows, ohne Zugriff auf die beteiligten Systeme oder ohne Owner im Fachbereich. Dann klären wir zuerst diese Punkte. Betrieb ist 8×5, ein 24/7-Betrieb gehört nicht zum Standard.
Nächster Schritt
Verwandte Themen
→Wann ein externer KI-Agent-Berater sinnvoll ist
→n8n und Power Automate im Vergleich für AI Workflows
