Im Monatsabschluss läuft das Finance-Team zwischen BMD, einem Shop-Backend, Excel und E-Mail hin und her, während im Hintergrund ein Chatbot in Teams erklärt, welche Rechnung offen ist. Die KI antwortet schnell, aber sie sitzt neben dem Geschäft, nicht im Prozess. Sie sieht weder die Buchung noch den Freigabestatus noch die Ausnahmeliste.
Viele Unternehmen haben Copilots, interne Sprachmodelle oder einzelne Bots eingeführt. Laut Eurostat nutzten 2025 20 % der EU-Unternehmen mit mindestens zehn Beschäftigten KI-Technologien, in Österreich waren es laut Statistik Austria 30 %. Die eigentliche Arbeit bleibt trotzdem oft verteilt, manuell und brüchig. Eine Enterprise Automation Platform soll das ändern: Sie bringt KI in ERP-, CRM- und Finance-Workflows, in Freigaben, Übergaben und nachvollziehbare Ausführung.
Dieser Beitrag erklärt, was eine solche Automatisierungsplattform ist, aus welchen Schichten sie besteht, wie Konnektoren und die MCP-Schicht gebaut sein müssen und nach welchen Kriterien Sie eine Plattform auswählen. Welche Prozesse Sie zuerst automatisieren und wie Sie ein Projekt Schritt für Schritt aufsetzen, beschreibt unser Leitfaden zur KI-Automatisierung.
Was eine Automatisierungsplattform ist
Eine Automatisierungsplattform verhält sich wie ein zentrales Nervensystem. Sie nimmt Signale aus Fachsystemen auf, entscheidet, wohin sie gehören, stößt Aktionen an und sorgt dafür, dass Freigaben, Daten und Rückmeldungen an der richtigen Stelle landen. Nicht jede Komponente muss alles können, aber alle zusammen müssen einen stabilen Ablauf bilden.
Chat-Tools liefern Wissen, aber sie ändern keine Stammdaten, stoßen keine Freigabe an und schreiben nichts sauber in das Zielsystem zurück. Eine Plattform verbindet Gespräch und Aktion: Sie nimmt eine Anfrage auf, versteht den Kontext, löst einen Workflow aus und protokolliert das Ergebnis so, dass Finance, IT und Compliance damit arbeiten können.
Praktische Regel: Wenn ein Prozess noch Copy-Paste zwischen ERP, Excel und E-Mail braucht, läuft die KI daneben, nicht im Ablauf.
RPA, iPaaS und MCP-Schicht im Vergleich
Hinter dem Begriff stehen drei Technologien, die unterschiedliche Probleme lösen. Wer sie als austauschbare Produkte behandelt, landet schnell in einem Konnektor-Chaos.
RPA bedient grafische Oberflächen und bleibt nützlich, wenn ein Altsystem keine API besitzt. Die Schwäche liegt in der Fragilität: Ändert sich ein Button, ein Formular oder der Anmeldeprozess, muss der Bot angepasst werden. Für einzelne stabile Sonderfälle ist das akzeptabel, als zentrale Integrationsstrategie nicht.
iPaaS verbindet Systeme über APIs, verarbeitet Datenflüsse und zentralisiert die Orchestrierung. Das ist der richtige Kern für Abläufe zwischen ERP und CRM oder zwischen Buchhaltung und Reporting. Lizenzmodelle, proprietäre Konnektoren und isolierte Altsysteme können die Lösung jedoch begrenzen.
Die MCP-Schicht ergänzt diese Architektur um eine kontrollierte Verbindung zwischen KI-Agenten und Geschäftssystemen. Das Model Context Protocol ist ein offener Standard, über den Modelle Werkzeuge und Kontext einheitlich nutzen. Tools werden eindeutig beschrieben, Berechtigungen lassen sich granular steuern und Aktionen laufen in einem nachvollziehbaren Kontext. MCP ersetzt keine bestehenden Schnittstellen, sondern schafft eine Governance-Schicht für die Nutzung durch Agenten.
| Kriterium | RPA | iPaaS | MCP-Schicht |
|---|---|---|---|
| Hauptzweck | Bedienung von Oberflächen | API- und Datenintegration | Kontext, Tool-Zugriff und Agentensteuerung |
| Geeignet für | Altsysteme ohne API | ERP-, CRM- und Buchhaltungsflüsse | KI-Agenten mit kontrolliertem Systemzugriff |
| Stärke | Schneller Zugriff auf alte Oberflächen | Wiederverwendbare Integrationen | Granulare Berechtigungen und Auditierbarkeit |
| Schwäche | Wartung bei Änderungen der Oberfläche | Abhängigkeit von APIs und Plattformlogik | Zusätzliche Governance- und Architekturarbeit |
| Empfehlung | Nur gezielt einsetzen | Als Middleware bevorzugen | Über den relevanten Integrationen aufbauen |
Für mittelständische Unternehmen mit ERP-Schwerpunkt empfehlen wir eine hybride Architektur: RPA für einen kleinen Anteil schwer zugänglicher Altsysteme, eine API-basierte Integrationsschicht als Basis und darüber eine MCP-Schicht, die Kontext und KI-Zugriff kontrolliert.
Die Schichten einer Plattform
Eine produktionsreife Plattform lässt sich in sechs Fähigkeiten zerlegen. Diese Aufteilung ist unsere Prüfliste aus Projekten, keine Norm. Sie hilft zu erkennen, ob ein Werkzeug nur Workflows startet oder durchgängige Automatisierung über ERP-, CRM- und Altsysteme stabil tragen kann.
- Integration: Konnektoren für die Kernsysteme, mit Lese- und Schreibrechten, Mapping und Fehlerbehandlung.
- Datentransfer: Synchron, ereignisbasiert oder als Batch, jeweils mit Validierung und Korrelations-IDs.
- Orchestrierung: Zustände, Abhängigkeiten, Zeitüberschreitungen und Wiederaufnahme nach Fehlern.
- Zugriffskontrolle und Policies: Rollen, Freigabepflichten und Grenzen dafür, was ein Agent tun darf.
- Schutz: Secrets-Verwaltung, Verschlüsselung, Datenminimierung und Datenresidenz.
- Betrieb: Monitoring, Audit-Trail, Reporting und Integrationstests.
Eine Plattform ist dann reif, wenn sie nicht nur Workflows baut, sondern Fehler, Zugriffe und Ausnahmen im Betrieb beherrscht.
Die Rollen müssen dabei sauber getrennt bleiben. Konnektoren sprechen technisch mit den Zielsystemen. Die MCP-Schicht ist die kontrollierte Brücke zwischen Modell und Unternehmenssystem. Agenten planen und koordinieren Arbeitsschritte. In hybriden Umgebungen mit On-Premises-ERP, Cloud-CRM, Dokumentenmanagement und manuellen Freigaben ist genau diese Trennung wertvoll, weil sie Komplexität nicht versteckt, sondern steuerbar macht.
Konnektoren für ERP, CRM und Finanzsysteme
Ein Konnektor ist kein dünner API-Aufruf. Er übersetzt Identitäten, Datenmodelle, Berechtigungen und Fehlerzustände zwischen Anwendungen. Bei SAP, Salesforce, BMD, DATEV oder vergleichbaren Systemen brauchen Sie eine verbindliche Mapping-Tabelle, eine zentrale Authentifizierung und ein definiertes Verhalten für Wiederholungen.
Wählen Sie das Integrationsmuster nach dem Charakter des Prozesses:
| Systemtyp | Integrationsmethode | Vorteile | Einschränkungen |
|---|---|---|---|
| ERP mit transaktionalen Änderungen | API-basiert | Direkte Validierung und kontrollierte Schreibvorgänge | Abhängigkeit von API-Limits und Verfügbarkeit |
| CRM mit Statusänderungen | Ereignisbasiert | Schnelle Reaktion und lose Kopplung | Ereignisse brauchen Versionierung und Wiederholungslogik |
| Finanzsystem mit periodischem Abgleich | Batch-Synchronisation | Planbar und einfach zu überwachen | Änderungen sind nicht sofort sichtbar |
| Altsystem ohne stabile API | Adapter oder Dateischnittstelle | Bestehende Systeme bleiben nutzbar | Höherer Pflegeaufwand und mehr Validierung |
Datenqualität und Idempotenz
Definieren Sie für jedes Feld eine Quelle, ein Format und eine Validierungsregel. Kundennummern dürfen nicht einmal als Text und einmal als Zahl behandelt werden. Währungen, Datumsformate und Steuerinformationen werden vor dem Schreiben normalisiert. Legen Sie außerdem Systemgrenzen fest: Das ERP bleibt für Aufträge führend, das CRM für Kundenbeziehungen, das Finanzsystem für Buchungen. Der Agent darf nicht stillschweigend zum vierten führenden System werden.
Idempotenz verhindert doppelte Vorgänge. Jeder Auftrag braucht eine eindeutige externe Referenz, die der Konnektor vor einer erneuten Ausführung prüft. Schlägt ein Netzwerkaufruf nach der Buchung fehl, darf ein Wiederholungsversuch keine zweite Buchung erzeugen.
Fehler gehören in einen nachvollziehbaren Prozess. Technische Fehler können automatisch wiederholt werden, fachliche Fehler brauchen eine Korrektur oder eine menschliche Entscheidung. Speichern Sie Anfrage, Antwort, Korrelations-ID und Status, aber nicht mehr sensible Inhalte, als für Audit und Fehlersuche erforderlich sind.
Die MCP-Schicht als Gatekeeper
Die MCP-Schicht arbeitet als kontrollierter Zugangspunkt zwischen KI-Agenten und Unternehmenssystemen. Der Agent erhält keinen pauschalen Zugriff auf das ERP. Er ruft eine freigegebene Fähigkeit auf, die Eingaben validiert, Berechtigungen prüft, den Zielkontext festlegt und das Ergebnis protokolliert.
Beginnen Sie mit einer Inventarliste aller Tools und Aktionen. Kundendaten lesen ist eine andere Fähigkeit als eine Adresse ändern. Eine Buchung oder Auszahlung gehört in eine strengere Risikoklasse als das Erstellen eines Entwurfs. Legen Sie Rollen und Policies ausdrücklich fest:
- Leserechte: Der Agent darf Daten abrufen, aber keine Änderungen auslösen.
- Entwurfsrechte: Der Agent erstellt Vorschläge, Dokumente oder Freigabeaufgaben.
- Ausführungsrechte: Der Agent darf nur definierte Aktionen mit geprüften Parametern ausführen.
- Freigabepflicht: Kritische Änderungen benötigen eine menschliche Bestätigung.
- Notfallpfad: Jede riskante Aktion lässt sich stoppen, zurücksetzen oder manuell korrigieren.
Token gehören in einen zentralen Secret-Manager und werden nach dem Prinzip der geringsten Berechtigung vergeben. Daten werden bei der Übertragung und im Speicher verschlüsselt. Audit-Logs zeigen, welcher Agent mit welchem Nutzerkontext welche Fähigkeit aufgerufen hat und welches Ergebnis zurückkam.
Wir betreiben für Kunden mit Supercenter eine eigene verwaltete MCP-Schicht. Entscheidend ist aber nicht der Produktname, sondern die Funktion: versionierte Tools, kontrollierte Endpunkte, ein Rollenmodell, Protokollierung und ein nachvollziehbarer Rollback. Diese Anforderungen sollten Sie an jede Plattform stellen.
Ein Ablauf aus der Praxis
So kann ein Bestellprozess über die Plattform laufen:
- Ein Eingangsdienst übernimmt Auftrag und Anhänge.
- Ein Agent extrahiert Positionen und ordnet den Kunden zu.
- Ein ERP-Konnektor prüft Preise, Bestand und Zahlungsbedingungen.
- Ein Regelwerk entscheidet, ob eine Freigabe erforderlich ist.
- Ein CRM-Schritt aktualisiert den Vorgang und informiert den zuständigen Account Manager.
- Das Finanzsystem erhält erst nach bestätigter Freigabe den Buchungsauftrag.
Unabhängige Prüfungen wie Bonität, Kundensegment und Vollständigkeit der Dokumente können parallel laufen. Abhängige Schritte bleiben sequenziell, damit kein Agent mit unvollständigem Zustand arbeitet. Freigaben, Rückfragen und Eskalationen landen im bestehenden Arbeitskanal, etwa in Teams, Slack oder E-Mail.
Betriebsregel: Der Agent darf Vorschläge flexibel erzeugen. Schreibvorgänge, Finanzbuchungen und Berechtigungsänderungen müssen deterministisch abgesichert bleiben.
Klassische RPA scheitert an diesem Ablauf meist an drei Stellen: Es fehlt die semantische Einordnung, weil ein Bot nur Klicks kennt; es fehlt eine Modellschicht für dynamische Entscheidungen; und es fehlt ein einheitlicher Sicherheits- und Berechtigungsrahmen über mehrere Systeme und Rollen hinweg.
Sicherheit, Governance und Compliance in der EU
Eine Architektur ohne Governance ist im EU-Kontext ein Risiko. Sobald Agenten auf Buchungen, Freigaben oder personenbezogene Daten zugreifen, müssen EU-Datenresidenz, DSGVO-konforme Datenflüsse, rollenbasierte Zugriffe, Audit-Trails und ein klarer Human-in-the-Loop fest eingebaut sein. Das ist kein späteres Kontrollkästchen, sondern Teil des Betriebsentwurfs.
Der kritische Punkt ist nicht das Lesen von Daten, sondern das Schreiben. Sobald ein Agent in ERP, Finance oder Buchhaltung etwas ändert, braucht es nachvollziehbare Rechte, Protokollierung und eine saubere Freigabelogik. Die Governance gehört deshalb auf die Ebene der MCP-Schicht und der Konnektoren. Dort wird entschieden, ob ein Zugriff erlaubt ist, ob eine Aktion eine zweite Freigabe braucht und ob ein Mensch eingebunden werden muss. Werden diese Regeln erst nachgelagert oder in Einzeltools abgebildet, wird die Plattform schwer prüfbar.
In Finance-nahen Prozessen reicht es nicht, wenn ein Workflow „irgendwie funktioniert“. Verantwortliche brauchen eine Audit-Spur, die zeigt, wer was angestoßen hat, welche Daten verwendet wurden und wo eine Freigabe erteilt wurde.
Arbeitsregel: Wenn eine Plattform keinen belastbaren Audit-Weg liefert, gehört sie nicht in Finanz- oder Compliance-Prozesse.
Einen ausführlichen Rahmen für Zugriffe, Protokollierung und Freigaben beschreibt unser Security Governance Framework.
Testen und Betrieb
Ein automatisierter Ablauf ist erst produktionsreif, wenn er nicht nur im Idealfall funktioniert. Testen Sie jeden Konnektor isoliert, das Zusammenspiel der Komponenten und den vollständigen Ablauf mit realistischen Ausnahmefällen. Verwenden Sie anonymisierte oder synthetische Testdaten und trennen Sie die Sandbox strikt von produktiven Buchungen.
- Unit-Tests prüfen Parser, Validierungen und Statuslogik isoliert. Ein fehlerhaftes Datumsformat sollte hier auffallen, bevor ein kompletter Prozess startet.
- Integrationstests prüfen Authentifizierung, Mapping, Fehlercodes und Wiederholungen zwischen zwei Komponenten, einschließlich abgelaufener Tokens, langsamer Antworten und nicht erreichbarer Systeme.
- End-to-End-Tests laufen vom Eingang eines Vorgangs bis zum erwarteten Abschluss und prüfen auch Freigaben, Benachrichtigungen, Audit-Logs und das Rollback-Verhalten.
Im Betrieb überwachen Sie Latenz, Fehlerrate, Durchsatz, offene Ausnahmen und die Wartezeit an menschlichen Freigabepunkten. Ein Dashboard sollte zwischen Modellfehler, Konnektorfehler, Berechtigungsfehler und fachlich abgelehnten Vorgängen unterscheiden. Sonst sieht das Betriebsteam nur, dass ein Prozess fehlschlug, aber nicht, wer handeln muss. Alerts brauchen Schweregrade, Zuständigkeiten und Runbooks. Was vor dem Go-live erfüllt sein muss, fasst unsere Checkliste zur Production Readiness zusammen.
Auswahlkriterien und Entscheidungsmatrix
Bei der Auswahl helfen keine Feature-Listen, sondern harte Vergleichsfragen. Die meisten Fehleinkäufe passieren, weil Unternehmen sich von Demos beeindrucken lassen, statt die Betriebsrealität zu prüfen.
| Kriterium | Warum es zählt | Prüffrage an den Anbieter |
|---|---|---|
| Integrationstiefe in ERP, CRM und Buchhaltung | Ohne tiefe Kopplung bleibt Automatisierung an der Oberfläche | Welche Kernsysteme lassen sich ohne Sonderbau produktiv anbinden? |
| Lock-in-Risiko | Konnektoren und Betriebswissen müssen intern nutzbar bleiben | Wem gehören die Konnektoren, und kann unser Team sie selbst weiterführen? |
| Modellunabhängigkeit | Ein Modellwechsel darf nicht den ganzen Prozess umbauen | Arbeitet die Plattform mit mehreren Modellen und Tool-Setups? |
| Datenresidenz in EU und Österreich | Datenwege müssen regulatorisch und organisatorisch passen | Wo werden Daten verarbeitet, gespeichert und protokolliert? |
| Auditfähigkeit | Ohne Nachvollziehbarkeit keine Tauglichkeit für Finance | Wie werden Aktionen, Freigaben und Fehler lückenlos dokumentiert? |
| Durchsatz und Latenz | Prozesse müssen auch unter Last verlässlich bleiben | Welche Spitzenlast wurde getestet, mit welchen Erfolgskriterien? |
Liefermodell und Übergabe zählen mit
Ein zweites Kriterium ist das Liefermodell. Eine Plattform kann mit eingebetteten Engineers kommen oder als reine Software, die intern betrieben wird. Für viele Unternehmen ist die wichtigere Frage nicht, ob ein Pilot schnell startet, sondern ob das eigene Team ihn später tragen kann. Wenn Konnektoren, Policies und Monitoring nur beim Dienstleister liegen, steigt das Abhängigkeitsrisiko sofort.
Wenn ein Anbieter keine klare Antwort auf Betrieb, Eigentum an den Konnektoren und Testbarkeit gibt, ist die Demo noch kein Entscheidungsgrund.
Anwendungsfälle für Mittelstand und Konzern
Im Mittelstand entsteht der erste echte Wert oft im Monatsabschluss. Ein Team prüft Kontoauszüge, Belege und die Vorbereitung der Umsatzsteuer über BMD, DATEV und ein ERP, dazu kommen Freigaben per Mail und Rückfragen aus dem Shop. Ein Agent übernimmt die wiederholten, regelbasierten Schritte, Menschen entscheiden die Ausnahmen. Die Teams arbeiten dann nicht mehr gegen Excel-Ketten, sondern mit einem gesteuerten Ablauf, der Kontierung, Dokumentation und Freigabe zusammenhält. Mehr dazu in den Beiträgen zu KI in der Buchhaltung und zur Automatisierung des Kontenabgleichs.
Im Konzern geht es häufiger um Service Operations über mehrere Länder, Sprachen und Freigabeebenen. Ein Agent nimmt ein Ticket im CRM auf, prüft den Kontext im ERP, stößt Folgeaktionen an und entscheidet nach Regelwerk, ob ein Mensch eingreifen muss. Der Unterschied liegt weniger in der Technologie als im Takt. Beide Szenarien profitieren dort, wo Prozesse wiederholt, regelbasiert und datenintensiv sind.
Plattform evaluieren und einführen
Wer eine Plattform ernsthaft prüft, plant in Wochen, nicht in Quartalen. Wichtig ist, dass der Test echte Systeme berührt und nicht nur eine Demo-Datenbank.
| Phase | Fokus | Kennzahlen |
|---|---|---|
| Discovery | Schmerzpunkte kartieren, Anwendungsfälle priorisieren, Shortlist nach Entscheidungsmatrix | Ausgangswerte für Durchlaufzeit, Fehlerquote, Ausnahmequote, manuelle Übergaben |
| Pilot | Ein durchgängiger Prozess, eng abgegrenzt, mit Rollback-Plan | Zeit bis zur Entscheidung, Fehlerrate im Zielprozess, Rollback-Fähigkeit |
| Rollout | Weitere Teams, schrittweise Übergabe der Konnektoren an das interne Team | Time-to-Value, Anteil manueller Übergaben, Stabilität im Betrieb |
| Skalierung | Mehr Anwendungsfälle, kontinuierliches Monitoring | Ausnahmequote, Durchsatz unter Last, operative Verlässlichkeit |
Neue Agenten erhalten zunächst Lese- oder Entwurfsrechte. Erst nach belastbaren Tests und einem definierten Freigabemodell kommen Schreibrechte hinzu. Ein zusätzlicher Konnektor sollte einen konkreten Prozessschritt verbessern, nicht nur die Tool-Landschaft vergrößern.
Drei Schritte reichen für den Anfang. Erstens: Markieren Sie mit Finance und Operations alle Stellen mit Copy-Paste, Medienbruch und Wartezeit auf Freigaben. Zweitens: Bauen Sie eine ehrliche Shortlist entlang der Entscheidungsmatrix, nicht entlang von Demos. Drittens: Legen Sie zwei Kennzahlen fest, die innerhalb von 30 Tagen messbar sein müssen. Sonst ist der Pilot nur Theater.
Sprechen Sie mit uns
Wenn Sie eine Automatisierungsplattform mit Agenten, Konnektoren und kontrollierter MCP-Schicht in Ihre ERP-, CRM- und Finance-Landschaft bringen wollen, sprechen Sie mit uns.