RPA vs. KI-Agenten: Was der Mittelstand bei der Automatisierung falsch macht

Ein deutsches Logistikunternehmen investierte 18 Monate und ueber 400.000 Euro in die Einfuehrung von 47 RPA-Bots zur Auftragsabwicklung ueber drei Systeme. Sechs Monate nach dem Go-Live hatten 31 dieser Bots mindestens einmal wegen UI-Aenderungen im ERP versagt. Das IT-Team verbrachte mehr Zeit damit, Bots zu reparieren, als die Bots an Arbeitskosten einsparten. Das Projekt wurde still begraben.

Diese Geschichte ist keine Ausnahme. Die globale RPA-Studie von Deloitte zeigt: 63 Prozent der Unternehmen gaben an, dass ihre Zeitplanerwartungen nicht erfuellt wurden, 37 Prozent ueberschritten das Budget². Forrester-Forschung zeigt, dass 70 Prozent der RPA-Programme bei weniger als 50 Bots stagnieren, bevor die Wirtschaftlichkeit zusammenbricht¹. Und dennoch evaluieren deutsche KMU RPA weiterhin als Standardwahl fuer Automatisierung - oft ohne zu verstehen, wofuer das Tool eigentlich entwickelt wurde.

Dieser Artikel bewertet weder RPA als gut noch als schlecht. Es geht darum, die genaue Grenze zu verstehen zwischen dem, was RPA gut erledigt und was nicht - und was KI-Agenten stattdessen tun. Als CTO, Betriebsleiter oder Geschaeftsfuehrer, der Automatisierungsoptionen bewertet, erhalten Sie hier das Framework, um beim ersten Mal richtig zu entscheiden.

RPAs versteckte Krise

RPA wurde als schneller Weg zur Automatisierung vermarktet. Keine APIs noetig, kein tiefgreifendes Integrationswerk, keine Entwicklerressourcen erforderlich. Einfach einen Prozess aufzeichnen, einen Bot einsetzen, laufen lassen. Das Versprechen war ueberzeugend - und trieb zwischen 2016 und 2022 eine Welle von RPA-Adoptionen an. Doch die Ergebnisse sind ernuechternd.

Die Versagensdaten, ueber die niemand spricht

• 30 bis 50 Prozent der initialen RPA-Implementierungen scheitern - EY-Forschung, die in mehreren Unternehmensautomatisierungsanalysen zitiert wird, beziffert die Ausfallquote erster RPA-Projekte auf etwa die Haelfte - noch bevor die Frage der Skalierung gestellt wird¹.
• 63 Prozent ueberschritten die Implementierungszeitplaene - Die globale RPA-Studie von Deloitte ergab, dass fast zwei Drittel der Unternehmen RPA laenger als geplant brauchten².
• 37 Prozent ueberschritten das Budget - Ueber ein Drittel der RPA-Einfuehrungen kostete mehr als urspruenglich geschaetzt, noch ohne laufende Wartungskosten².
• 70 Prozent stagnieren unter 50 Bots - Forrester-Forschung zeigt, dass die Mehrheit der RPA-Programme weit vor einer unternehmensweiten Automatisierung aufhoert zu wachsen. Wartungsaufwand und Wirtschaftlichkeit werden unhaltbar¹.
• 54 Prozent der Technologiestoerungen entstehen durch Fuehrungsversagen - Nur 3 Prozent resultieren aus technischen Ausfaellen. Der Rest kommt von falsch ausgerichteten Zielen, mangelhafter Prozessauswahl und Defiziten im Change Management¹.

Warum die Krise verborgen bleibt

Die meisten RPA-Misserfolge generieren keine Pressemitteilungen. Sie sterben still: Budgets erschoepfen sich, das Wartungsteam wird ueberwaeltigt, Bots werden einer nach dem anderen deaktiviert, und die urspruengliche Einfuehrung versinkt in der Bedeutungslosigkeit. Drei Faktoren verhindern, dass die Versagensdaten in Beschaffungsgespraechen ankommen:

• Sunk-Cost-Druck - Unternehmen, die 500.000 Euro in RPA-Lizenzen und Implementierung investiert haben, erklaeren die Investition nicht gerne fuer gescheitert. Das Narrativ wird “wir optimieren unser Automatisierungsprogramm” statt “es hat nicht funktioniert”.
• Interessenausrichtung der Anbieter - RPA-Anbieter profitieren davon, mehr Bot-Lizenzen zu verkaufen, wenn bestehende Bots abbrechen oder ersetzt werden muessen. Die Anreizstruktur beguenstigt keine Transparenz ueber Skalierungsgrenzen.
• Pilot-vs.-Produktions-Luecke - RPA-Pilotprojekte gelingen fast immer. Der Prozess ist gut definiert, die Daten sind sauber, das Team ist engagiert. Das Scheitern passiert bei der Skalierung, Monate spaeter, wenn der Bot auf seinen hundertsten Sonderfall trifft und der urspruengliche Entwickler das Unternehmen laengst verlassen hat.

Was RPA gut kann (und warum Unternehmen es gekauft haben)

Die Kritik an RPA bedeutet nicht, dass es nutzlos ist. Es gibt eine klar definierte Klasse von Aufgaben, bei denen RPA das richtige Werkzeug ist - guenstiger, schneller einsetzbar und vorhersehbarer als jede Alternative. Diese Klasse praezise zu verstehen, trennt gute Automatisierungsentscheidungen von teuren Fehlern.

Der RPA-Kernbereich

RPA funktioniert gut, wenn alle folgenden Bedingungen zutreffen:

• Strukturierte Dateneingabe - Der Prozess empfaengt Daten immer im gleichen Format. Feste Felder, konsistente Spaltenpositionen, vorhersehbare Datentypen. Eine Rechnung, die immer als PDF mit demselben Layout ankommt.
• Stabile Benutzeroberflaeche - Die Anwendungsbildschirme und UI-Elemente, mit denen der Bot interagiert, aendern sich nicht. Wenn der ERP-Anbieter ein UI-Update veroeffentlicht, bricht der Bot.
• Keine Ausnahmen - Der Prozess folgt entweder immer demselben Pfad oder hat eine sehr kleine, klar definierte Menge von Verzweigungen. RPA kann keine Situation bewaltigen, fuer die es nicht explizit programmiert wurde.
• Hohes Volumen, geringe Varianz - Dieselbe Aktion muss hunderte oder tausende Male mit identischer Logik ausgefuehrt werden. Daten zwischen Systemen kopieren, geplante Berichte ausloesen, Formulare aus einer Datenbank befullen.
• Kein Urteilsvermogen erforderlich - Die Regel fuer jede Entscheidung ist explizit und kann als Wenn-Dann-Aussage geschrieben werden. Keine Ermessensentscheidungen, keine Kontextinterpretation.

Wo RPA versagt: 5 grundlegende Grenzen

Das sind keine Randfaelle. Es handelt sich um strukturelle Einschraenkungen, die in der Funktionsweise von RPA verankert sind. Jeder Prozess, der auf eine dieser Grenzen stoesst, erzeugt dauerhaften Wartungsaufwand - und keine Menge Bot-Feinabstimmung wird das zugrundeliegende Problem loesen.

Grenze 1: Brueche bei Veraenderungen

RPA-Bots interagieren mit Anwendungs-UIs so wie ein Mensch - durch Klicken auf Schaltflaechen, Lesen von Bildschirmtext und Eingabe von Werten in Felder. Wenn sich die Anwendungs-UI aendert - ein Anbieter-Update, ein neues Bildschirmlayout, ein umbenanntes Feld - bricht der Bot. Das ist kein Fehler. Es ist das Design.

• ERP-Updates loesen Bot-Ausfaelle aus - SAP, Oracle und Microsoft Dynamics veroeffentlichen mehrmals jaehrlich Updates. Jedes Update kann Bots beschaedigen, die sich auf bestimmte Bildschirmkoordinaten oder Feldpositionen stuetzen.
• Kumulative Fragilitaet - Ein Unternehmen mit 50 Bots und 10 integrierten Anwendungen kann Hunderte potenzieller Bruchpunkte pro Jahr haben. Wartung verbraucht schnell die Einsparungen, die die Bots erzeugen sollten.
• Versionsblockierungs-Risiko - Manche Unternehmen hoeren auf, ihre Unternehmenssoftware zu aktualisieren, um Bots nicht zu beschaedigen. Dies schafft Sicherheits- und Compliance-Risiken als direkte Folge der RPA-Einfuehrung.

Grenze 2: Unfaehigkeit zur Verarbeitung unstrukturierter Daten

Rund 80 Prozent der Unternehmensdaten sind unstrukturiert: E-Mails, Vertraege, Besprechungsnotizen, PDFs mit variablen Layouts, Kundenmitteilungen, technische Dokumentation. RPA kann keine davon verarbeiten. Ein Auftrag von einem neuen Lieferanten mit einem anderen Layout erfordert einen neuen Bot, manuelles Vorverarbeitung oder einen Ausnahmeworkflow.

• Variable Rechnungsformate - Ein Hersteller mit 200 Lieferanten empfaengt Rechnungen in 200 verschiedenen Formaten. RPA erfordert einen separaten Bot oder eine Vorlage fuer jedes Format - was bei Skalierung unpraktisch ist.
• E-Mail-gesteuerte Prozesse - Jeder Prozess, bei dem Arbeitselemente per E-Mail eintreffen - Kundenanfragen, Lieferantenbestaetigungen, HR-Abfragen - liegt ausserhalb der Reichweite von RPA.
• Vertragsbearbeitungs-Workflows - Vertraege unterscheiden sich in Struktur, Terminologie und Layout. RPA kann keine Klauseln extrahieren, Bedingungen vergleichen oder Anomalien ueber Dokumente mit variablen Formaten hinweg markieren.

Grenze 3: Keine Ausnahmebehandlung

Echte Geschaeftsprozesse erzeugen Ausnahmen. Eine Kundenbestellung kommt mit einem nicht standardmaessigen Produktcode. Eine Lieferantenrechnung hat eine Diskrepanz. RPA hat zwei Antworten auf Ausnahmen: Fehler und Stopp, oder Weiterleitung an einen Menschen. Keine davon ist skalierbar.

• Ausnahme-Warteschlangen haeufen sich - Bei den meisten RPA-Einfuehrungen landen 10 bis 30 Prozent des Prozessvolumens in manuellen Ausnahme-Warteschlangen - oft mehr als das Volumen, das der Bot verarbeitete. Die versprochenen Einsparungen materialisieren sich nie.
• Ausnahmebehandlung erfordert Urteilsvermoegen - Der Grund, warum diese Faelle Ausnahmen sind, ist genau der, dass sie nicht durch eine einfache Regel geloest werden koennen. RPA kann kein Urteilsvermoegen anwenden. KI-Agenten koennen ueber den Kontext nachdenken und eine Entscheidung treffen oder eskalieren.

Grenze 4: Schlechte Skalierungsoekonomie

Die Kosten von RPA skalieren nicht linear mit dem Wert - sie skalieren mit der Komplexitaet. Jeder neue Bot erfordert Design, Tests und Einfuehrung. Jeder bestehende Bot erfordert laufende Wartung. Das Verhaeltnis von Wartungskosten zu Lizenzkosten verschlechtert sich, je groesser das Portfolio wird.

• Wartungsaufwand summiert sich - Jeder zusaetzliche Bot erhoet die Wartungsarbeit. Wenn Portfolios ueber 50 Bots hinauswachsen, gehen die meisten Unternehmen 70 bis 75 Prozent ihres Automatisierungsbudgets fuer die Wartung bestehender Bots statt fuer den Aufbau neuer aus⁴.
• Governance-Overhead - Grosse RPA-Portfolios benoetigen Bot-Register, Monitoring-Dashboards, Fehler-Alarmsysteme und Change-Management-Prozesse. Diese Infrastruktur selbst hat Kosten, die mit der Skalierung wachsen.
• Talentabhaengigkeit - RPA erfordert Spezialisten, die sowohl die Prozesse als auch das Automatisierungswerkzeug verstehen. Das ist ein knappes, teures Qualifikationsprofil.

Grenze 5: Kein systemuebergreifendes Denken

Ein Bot kann Schritte ueber mehrere Systeme in einer vordefinierten Reihenfolge ausfuehren. Er kann nicht ueber das nachdenken, was ueber diese Systeme hinweg passiert, oder seinen Ansatz anpassen. Wenn der Auftragsstatus eines Kunden im ERP “ausstehend” sagt, aber das Logistiksystem “versandt” zeigt, wird ein Bot entweder seinem Skript folgen oder scheitern. Er wird die Diskrepanz nicht erkennen, die Ursache untersuchen und die richtige Loesung waehlen.

• Datenkonsistenzpruefungen - Die Verifizierung, dass Daten ueber Systeme hinweg konsistent sind, erfordert das Verstaendnis, was Konsistenz im Kontext bedeutet.
• Mehrstufige Entscheidungen - Workflows, bei denen mehrere Eingaben aus verschiedenen Systemen ausgewertet werden muessen, liegen ausserhalb der Faehigkeiten von RPA.
• Dynamisches Routing - Einen Fall basierend auf Inhalt, Prioritaet und aktueller Auslastung an das richtige Team zu senden, erfordert Urteilsvermoegen, das regelbasierte Systeme nicht zuverlaessig liefern koennen.

Was KI-Agenten anders machen

Der architektonische Unterschied zwischen RPA und KI-Agenten ist nicht kosmetisch. Er spiegelt einen grundlegend anderen Ansatz zur Automatisierung wider - einen, der fuer die unordentliche Realitaet von Unternehmensworkflows entwickelt wurde, nicht fuer die idealisierten Bedingungen eines Proof-of-Concept.

Wie KI-Agenten funktionieren

Ein KI-Agent empfaengt ein Ziel statt eines Skripts. Er denkt darueber nach, wie er dieses Ziel mithilfe verfuegbarer Werkzeuge - APIs, Datenbanken, Dokumentenprozessoren, Sprachmodelle, externe Dienste - erreichen kann. Bei Ausnahmen versteht er den Kontext und trifft eine Entscheidung oder eskaliert mit einer klaren Erklaerung, warum.

• API-first-Integration - KI-Agenten verbinden sich ueber APIs und Datenkonnektoren, nicht per UI-Scraping. Anwendungsupdates brechen keine Agenten, da sie mit stabilen Backend-Schnittstellen interagieren, nicht mit Praesentationsschichten.
• Verarbeitung unstrukturierter Daten - KI-Agenten koennen E-Mails, Vertraege, PDFs und Besprechungsnotizen lesen. Sie extrahieren relevante Informationen und verstehen den Kontext, ohne ein bestimmtes Datenformat zu benoetigen.
• Zielorientiertes Denken - Statt einem festen Skript zu folgen, arbeitet ein KI-Agent auf ein definiertes Ergebnis hin. Wenn ein Ansatz scheitert, probiert er einen anderen.
• Kontextbewusstsein - KI-Agenten behalten den Ueberblick ueber das, was sie getan haben und was sie finden. Sie koennen Diskrepanzen erkennen und angemessen eskalieren.
• Selbstverbesserung durch Feedback - KI-Agenten verbessern sich, indem sie mehr Faelle verarbeiten. Korrekturen durch menschliche Pruifer fliessen in das Verhalten des Agenten zurueck.

Architekturvergleich

Was KI-Agenten nicht koennen

• KI-Agenten sind nicht unfehlbar - Sie koennen Denkfehler machen, besonders bei hochspezialisierten Fachaufgaben. Human-in-the-Loop-Kontrollpunkte sind fuer kritische Entscheidungen unerlasslich.
• KI-Agenten benoetigen API-Zugang - Fuer Systeme ohne APIs erfordert die Verbindung von KI-Agenten zuerst den Aufbau dieser Integrationen. Das ist vorab mehr Arbeit als RPAs UI-Scraping-Ansatz.
• KI-Agenten brauchen Governance - Gartner prognostiziert, dass 40 Prozent der agentischen KI-Projekte bis 2027 abgebrochen werden, wenn keine ordnungsgemaessen Governance-Rahmenbedingungen vorhanden sind¹⁰.
• KI-Agenten sind neuer - Gartner-Analystin Anushree Verma stellt fest: “Die meisten agentischen KI-Projekte sind derzeit fruehe Experimente oder Proofs of Concept, die hauptsaechlich durch Hype getrieben werden”⁹. Waehlen Sie Partner mit echter Einfuehrungserfahrung.

Der echte Kostenvergleich: RPA vs. KI-Agenten

Die Headline-Lizenzkosten von RPA sehen attraktiv aus. Die Gesamtbetriebskosten ueber drei Jahre erzaehlen eine ganz andere Geschichte. Unternehmen, die Automatisierungsplattformen evaluieren, muessen Implementierung, Wartung und laufende Arbeitskosten fuer das Bot-Management einkalkulieren - nicht nur die Lizenzgebuehr.

Dreijahres-Gesamtbetriebskostenvergleich

Woher die Kostendifferenz kommt

• Wartungsaufwand - Traditionelle RPA-Programme geben 70 bis 75 Prozent ihres laufenden Budgets fuer die Wartung bestehender Bots statt den Aufbau neuer aus⁴. KI-Agenten, die auf stabilen APIs basieren, erfordern deutlich weniger Wartung, wenn Systeme aktualisiert werden.
• Ausnahmebehandlungs-Arbeitskosten - RPA leitet Ausnahmen in menschliche Warteschlangen. Bei Prozessen mit 15 bis 30 Prozent Ausnahmeraten sind das permanente Personalkosten, die nicht im Automatisierungsbudget erscheinen, aber trotzdem existieren.
• Bot-Ausfallkosten - Jedes Mal, wenn ein Bot abbricht und ein Prozess stockt, entstehen Kosten: die geschaeftliche Auswirkung des verzoegerten Prozesses und die IT-Zeit fuer Diagnose und Reparatur.
• Skalierungs-Kostenverhaeltnis - Fuer jeden Euro RPA-Lizenzkosten geben Unternehmen 3,41 bis 4,00 Euro fuer Beratung und Wartung aus³. Dieses Verhaeltnis ist strukturell schlechter fuer RPA als fuer KI-Agenten.

Behalten, wechseln oder beides laufen lassen?

Die Antwort haengt voellig davon ab, was Sie automatisieren wollen. Es gibt keine universell richtige Antwort - nur ein prozessbasiertes Entscheidungsframework, das Ihnen unabhaengig von der Richtung einen vertretbaren Weg gibt.

Entscheidungsframework nach Prozesstyp

Wie der Mittelstand den Wechsel vollzieht

Deutsche KMU stehen vor einem spezifischen Bedingungsrahmen, der beeinflusst, wie Automatisierungsmigrationen in der Praxis funktionieren. Drei Faktoren stechen hervor: regulatorisches Umfeld, Systemlandschaft und Personalentwicklung.

Der deutsche Kontext

• SAP-Dominanz - Die Mehrheit der deutschen Mittelstandsunternehmen betreibt SAP als ERP-Kern. Das API-Oekosystem von SAP (SAP Business Technology Platform, OData-APIs, BAPI) bietet die Integrationsschicht, die KI-Agenten benoetigen. Fuer Unternehmen, die RPA wegen SAP-Integrationskomplexitaet ablehnten, sind KI-Agenten ueber SAP-APIs tatsaechlich zuverlaessiger als der UI-Scraping-Ansatz von RPA.
• DSGVO und Datenhaltung - Deutsche KMU muessen sicherstellen, dass jedes KI-System, das personenbezogene Daten verarbeitet, DSGVO-konform ist. Konkret: Vergewissern Sie sich, dass Ihre KI-Agenten-Plattform On-Premise-Bereitstellung oder EU-gehostete Cloud-Instanzen unterstuetzt. Daten duerfen die EU ohne angemessene Schutzmassnahmen nicht verlassen.
• EU-KI-Verordnung - Die EU-KI-Verordnung wird ab August 2026 vollstaendig anwendbar. Die meisten KI-Agenten zur Geschaeftsprozessautomatisierung fallen in die Kategorien mit begrenztem oder minimalem Risiko. Hoehere Risikoklassifizierungen gelten fuer KI-Systeme in der Personalentscheidungsfindung, sicherheitskritischen Systemen und Kreditbewertung.
• Betriebsratliche Mitbestimmung - Betriebsraete haben nach dem Betriebsverfassungsgesetz Mitbestimmungsrechte fuer technische Systeme, die das Verhalten oder die Leistung von Mitarbeitern ueberwachen koennen. Jedes Automatisierungssystem, das Daten darueber erfasst, wie Mitarbeiter arbeiten, erfordert Betriebsratskonsultation. Bauen Sie das von Anfang an in den Projektzeitplan ein.
• Digital-Jetzt-Foerderung - Das Bundesministerium fuer Wirtschaft bietet KMU ueber das Programm “Digital Jetzt” Foerderungen bis zu 50.000 Euro fuer Digitalisierungsprojekte, die bis zu 70 Prozent foerderfahiger Beratungs- und Investitionskosten abdecken. KI-Automatisierungsprojekte koennen foerderfaehig sein.

Wo der Mittelstand typischerweise beginnt

Erfolgreiche Uebergaenge teilen ein Muster: Sie beginnen mit den schmerzhaftesten Prozessen, nicht mit den einfachsten. Die Logik ist einfach - das Ersetzen eines zuverlaessig laufenden Bots erzeugt keinen unmittelbaren Geschaeftswert.

• Rechnungsverarbeitung - Lieferantenrechnungen kommen in Dutzenden von Formaten von verschiedenen Lieferanten. RPA erfordert entweder eine Vorlage pro Lieferant oder bricht staendig ab. KI-Agenten lesen Rechnungen mit variablen Formaten, extrahieren Positionen, gleichen mit Bestellungen ab und routen Genehmigungen - ohne lieferantenspezifische Konfiguration.
• Kunden-Anfragentriage - Kundenanfragen kommen in unstrukturierter Sprache. RPA kann sie nicht lesen. KI-Agenten lesen die Nachricht, klassifizieren den Anfragentyp, extrahieren relevante Daten, leiten ans richtige Team weiter und entwerfen eine Antwort zur menschlichen Genehmigung.
• Lieferketten-Ausnahmemanagement - Lieferverzoegerungen und Lieferengpaesse erzeugen Alarme ueber mehrere Systeme. KI-Agenten koennen diese Signale ueberwachen, Daten ueber ERP und Logistikplattformen korrelieren und die richtigen Faelle mit dem richtigen Kontext eskalieren.
• HR- und Onboarding-Workflows - Die Einarbeitung neuer Mitarbeiter umfasst Dokumentensammlung, Kontoeinrichtung, Zugriffsberechtigungen und Genehmigungsworkflows ueber HR, IT und Finanzen. Die Kombination aus strukturierten Formularen und unstrukturierten Dokumenten macht das zu einem schlechten Fit fuer RPA und einem idealen fuer KI-Agenten.

Migrationschritte, die funktionieren

1. Aktuelles RPA-Portfolio auditieren - Jeden Bot auflisten: Wartungshistorie, Ausfallrate, Prozessvolumen und Ausnahmerate. Das ergibt Ihre Migrationsprioritaetsliste.
2. Den schmerzhaftesten Prozess zuerst identifizieren - Den Prozess waehlen, bei dem Ihr Team die meiste Zeit mit Ausnahmen, Ausfaellen und manuellen Eingriffen verbringt.
3. Prozess von Ende zu Ende dokumentieren - Jeden Schritt, jede Eingabe, Ausgabe, jedes System und jeden Ausnahmetyp dokumentieren. Das ist die Arbeit, die die Einfuehrung zum Erfolg fuehrt.
4. Erfolgskennzahlen vor der Einfuehrung definieren - Was ist der aktuelle Basiswert? Ohne Ausgangslage koennen Sie keinen ROI nachweisen.
5. Zuerst auf begrenzten Umfang einsetzen - Mit 20 Prozent des Prozessvolumens beginnen. In der Produktion validieren, bevor skaliert wird.
6. Feedback-Schleife von Woche eins - Jede Ausnahme, jede Korrektur und jeden Fehler des Agenten protokollieren und woechentlich pruefen.
7. Betriebsrat fruehzeitig einbeziehen - Wenn der Prozess Mitarbeiterleistungsdaten erfasst, Konsultationsprozess vor der Einfuehrung beginnen, nicht danach.

Wie Superkind passt

Superkind entwickelt massgeschneiderte KI-Agenten, die ueber stabile API-Integrationen - nicht per UI-Scraping - mit bestehenden Systemen (SAP, ERP, CRM, Dokumentenmanagement) verbunden werden. Der Ansatz adressiert die spezifischen Versagensmuster traditioneller RPA, ist dabei aber realistisch ueber das, was KI-Agenten zum Erfolg brauchen.

Kernfaehigkeiten

• SAP- und ERP-Integration - Native Konnektoren fuer SAP Business Technology Platform, SAP OData-APIs und BAPI-Schnittstellen. Agenten verbinden sich direkt mit der SAP-Datenschicht, nicht mit der SAP-UI. Anwendungsupdates unterbrechen die Integration nicht.
• Dokumentenintelligenz - Liest und extrahiert Daten aus variablen Rechnungen, Vertraegen, Lieferscheinen und E-Mail-Anhaengen. Keine dokumentenspezifischen Vorlagen noetig.
• Ausnahmebehandlung mit Kontext - Wenn ein Agent auf einen ungewoehnlichen Fall stifft, leitet er nicht nur in eine Warteschlange weiter. Er prasentiert dem menschlichen Pruefer eine klare Erklaerung: was er gefunden hat, was er versucht hat, und welche Entscheidung benoetigt wird.
• Systemuebergreifende Orchestrierung - Ein einziger Superkind-Agent kann Aktionen ueber SAP, ein CRM, eine Logistikplattform und ein E-Mail-System innerhalb eines einzelnen Workflows koordinieren.
• Human-in-the-Loop nach Design - Kritische Entscheidungen enthalten konfigurierbare Genehmigungsstufen. Sie legen fest, welche Aktionstypen menschliche Freigabe erfordern und bei welchem Konfidenz-Schwellenwert.
• DSGVO-konforme Einfuehrung - Agenten koennen innerhalb Ihrer bestehenden Infrastruktur oder auf EU-gehosteten Cloud-Instanzen eingesetzt werden. Audit-Logs verfolgen jede Agentenaktion fuer die Compliance-Dokumentation.
• Hybrid-RPA-Kompatibilitaet - Superkind-Agenten koennen bestehende RPA-Bots als Werkzeuge in einem groesseren Workflow ausloesen und koordinieren. Sie brauchen zuverlaessig laufende Bots nicht zu ersetzen.
• Einfuehrung in Wochen, nicht Monaten - Eine fokussierte erste Einfuehrung erreicht die Produktion typischerweise in 8 bis 12 Wochen. Ausgangspunkt ist ein Prozess-Assessment, das aktuelle Schritte, Datenfluesse und Ausnahmetypen vor jeglicher Entwicklung abbildet.

Der 90-Tage-Migrationsplan

Diese Checkliste deckt den Weg von der Entscheidung bis zur ersten Produktionseinfuehrung fuer einen Prozess ab. Nutzen Sie sie fuer Ihre interne Diskussion und Abstimmung mit Ihrem Automatisierungspartner.

Wochen 1 bis 4: Assessment und Auswahl

• Aktuelles RPA-Portfolio auditieren - Jeden Bot dokumentieren: Prozessname, System, Volumen pro Tag, Ausfallrate in den letzten 90 Tagen, Wartungsstunden pro Monat, Ausnahmerate und aktuelle Eigentuemer.
• Bots nach Migrationsprioritaet bewerten - Jedem Bot eine Punktzahl basierend auf Fehlerfrequenz + Ausnahmerate + Wartungsaufwand zuweisen. Die hoechsten Punktzahlen sind Ihre Migrationskandidaten.
• Einen Prozess zur zuerst migrieren auswaehlen - Den Bot mit der hoechsten Punktzahl waehlen oder, bei fehlendem RPA, den Prozess mit der hoechsten Kombination aus Volumen und Ausnahmerate.
• Prozess von Ende zu Ende dokumentieren - Jeden Eingabe, Ausgabe, Entscheidungspunkt, jedes involvierte System und jeden Ausnahmetyp dokumentieren. Die Menschen interviewen, die aktuell die Ausnahmen bearbeiten.
• Basiskennzahlen definieren - Aktuellen Zustand messen: Stunden pro Woche fuer Ausnahmen, Fehlerrate, Verarbeitungszeit pro Element, Kosten pro Transaktion.
• API-Verfuegbarkeit bestaetigen - Fuer jedes System, das der Prozess beruehrt, bestaetigen ob eine API existiert und welche Daten sie exponiert.
• Betriebsrat benachrichtigen, falls zutreffend - Wenn der Prozess Mitarbeiterleistungsdaten erzeugt, den Konsultationsprozess jetzt starten.

Wochen 5 bis 8: Aufbau und Tests

• Agenten gegen die Prozesskarte entwickeln - Entwicklung beginnt aus dem dokumentierten Prozess, nicht aus Annahmen.
• Eskalationsschwellen definieren - Festlegen, welche Entscheidungen menschliche Ueberpruefung erfordern, bei welchem Konfidenz-Schwellenwert und welches Teammitglied die Eskalation erhaelt.
• Mit echten historischen Daten testen - Tatsaechliche Prozesseingaben aus der Vergangenheit zur Validierung des Agenten verwenden, bevor er Live-Daten beruehrt.
• Ausnahmebehandlung spezifisch testen - Sicherstellen, dass Eskalationen den richtigen Kontext liefern und der menschliche Ueberpruefungspfad klar ist.
• DSGVO-Protokollierungskonfiguration bestaetigen - Pruefprotokolle verifizieren und DSGVO-Dokumentationsanforderungen erfuellen.
• Das Team schulen, das neben dem Agenten arbeiten wird - Fokus auf: wie man Eskalationen pruefen, den Agenten korrigieren und Protokolle interpretieren kann.

Wochen 9 bis 12: Produktion und Optimierung

• Zuerst auf 20 Prozent des Prozessvolumens einsetzen - Eng beginnen. Den Agenten auf einer repraesentativen Teilmenge laufen lassen, waehrend Menschen den vollstaendigen Prozess parallel abwickeln.
• Jede Ausnahme und Korrektur woechentlich pruefen - Was der Agent falsch machte, warum und was die richtige Antwort war protokollieren.
• Gegen Basislinie messen - Verarbeitungszeit, Ausnahmerate und Fehlerrate mit den in Woche 1 festgelegten Kennzahlen vergleichen.
• Auf volles Volumen ausweiten, sobald validiert - Nach zwei bis drei Wochen stabilen Betriebs auf 20-Prozent-Niveau auf volles Volumen ausweiten.
• Prozess fuer naechste Migration dokumentieren - Was wurde gelernt? Welche Teile der Abbildungsphase waren am wertvollsten? Dieses Wissen macht die zweite Migration schneller.

Verwandte Artikel

• KI-Agenten fuer den Mittelstand: Wie Deutschlands Hidden Champions KI einsetzen, ohne zu verlieren, was sie stark macht
• Warum 95% aller KI-Projekte im Mittelstand scheitern - und was die anderen 5% anders machen

Haeufig gestellte Fragen

Henri Jung

Mitgruender von Superkind, wo er KMU und Unternehmen dabei hilft, massgeschneiderte KI-Agenten einzufuehren, die wirklich zu ihrer Arbeitsweise passen. Henri ist leidenschaftlich daran interessiert, die Luecke zwischen dem, was KI leisten kann, und dem Wert, den sie in echten Unternehmen schafft, zu schliessen. Vor Superkind arbeitete er Jahre mit mittelstaendischen Unternehmen an der digitalen Transformation und sah aus erster Hand, warum so viele KI-Projekte scheitern. Er glaubt, dass der Mittelstand alles hat, was er braucht, um bei KI fuehrend zu sein.