Zurück zum Blog Automatisierung

RPA oder Schnittstelle? Was sich im Mittelstand lohnt

Thomas Grafenau20. Januar 20265 Min. Lesezeit

Was RPA ist

Robotic Process Automation, kurz RPA, bezeichnet Software, die die Bedienung anderer Programme nachahmt. Ein sogenannter Bot klickt auf Schaltflächen, füllt Felder aus, kopiert Werte von einer Maske in die nächste und liest Ergebnisse vom Bildschirm ab. Er tut also dasselbe wie ein Mensch an der Tastatur, nur nach einem festen Ablauf und ohne Pause.

Der Reiz liegt auf der Hand: An den bestehenden Systemen muss nichts geändert werden, der Bot nutzt dieselbe Oberfläche wie die Mitarbeiter. Das macht RPA zu einem schnellen Einstieg, wenn zwei Programme Daten austauschen sollen, aber keines dafür vorgesehen ist. Genau darin liegt allerdings auch die Schwäche, um die es in diesem Artikel geht.

Wo RPA im Mittelstand eingesetzt wird

Eingesetzt wird RPA bei Abläufen, die nach festen Regeln laufen und mit strukturierten Daten arbeiten. Typische Einsatzfelder:

  • Bestellungen oder Aufträge aus einem Portal in ein Warenwirtschafts- oder ERP-System übertragen.
  • Eingangsrechnungen in der Buchhaltung erfassen, wenn die Werte bereits strukturiert vorliegen.
  • Stammdaten wie Adressen, Preise oder Artikelnummern zwischen zwei Programmen abgleichen.
  • Wiederkehrende Berichte aus mehreren Anwendungen zusammenstellen.
  • Daten aus Portalen von Behörden, Banken oder Lieferanten abrufen, die keinen anderen Zugang anbieten.

Gemeinsam ist diesen Abläufen, dass heute ein Mensch Daten von einem System ins andere trägt. Es sind dieselben Abläufe, die sich auch für eine Schnittstelle eignen. Die eigentliche Frage ist deshalb nicht, ob RPA sie übernehmen kann, sondern ob ein Bildschirm-Roboter der richtige Weg ist.

Wie ein Bot arbeitet und warum das zählt

Ein RPA-Bot orientiert sich an der Oberfläche: an Fenstertiteln, Feldbezeichnungen, Positionen auf dem Bildschirm oder dem Aufbau einer Webseite. Solange diese Oberfläche gleich bleibt, arbeitet er zuverlässig. Ändert der Hersteller mit einem Update eine Maske, verschiebt ein Feld oder benennt eine Schaltfläche um, findet der Bot seinen Weg nicht mehr. Im günstigen Fall bricht er ab, im ungünstigen trägt er Werte in das falsche Feld ein.

Dazu kommt, dass ein Bot nur sieht, was auf dem Bildschirm steht. Er weiß nicht, ob ein Wert fachlich stimmt, ob ein Datensatz bereits übertragen wurde oder ob das Zielsystem eine Eingabe stillschweigend gekürzt hat. Diese Prüfungen müssen zusätzlich gebaut werden, und über die Oberfläche sind sie deutlich schwerer zu bauen als über eine Schnittstelle, die strukturierte Antworten und Fehlermeldungen liefert.

Wann RPA NICHT die richtige Lösung ist

Für die meisten Abläufe zwischen zwei Geschäftssystemen ist RPA nicht die erste Wahl. Bietet ein System eine Schnittstelle an, etwa eine dokumentierte API, einen Datenbankzugang mit klar begrenzten Rechten oder einen geregelten Datenexport, ist die direkte Anbindung der stabilere Weg. Sie überträgt Felder statt Bildschirminhalte, bleibt von Änderungen an der Oberfläche unberührt und lässt sich mit automatischen Tests absichern.

RPA ist in diesen Fällen nicht die richtige Wahl:

  • Es gibt eine Schnittstelle: Ist eine vorhanden oder lässt sie sich mit vertretbarem Aufwand bereitstellen, ist die direkte Anbindung stabiler und im Betrieb weniger anfällig.
  • Die Oberfläche ändert sich häufig: Jedes Update der angebundenen Anwendung kann den Bot unterbrechen, und jede Unterbrechung braucht jemanden, der sie bemerkt und behebt.
  • Der Ablauf ist geschäftskritisch: Wenn ein stehender Bot bedeutet, dass Aufträge nicht ankommen oder Lieferungen nicht ausgelöst werden, ist eine Lösung, die an Bildschirmpositionen hängt, ein Risiko.
  • Es braucht fachliches Urteil: Eine Reklamation zu bewerten oder einen Sonderpreis freizugeben, ist keine Klickfolge. Hier entscheidet ein Mensch, unterstützt durch gute Software.
  • Der Ablauf selbst stimmt nicht: Ein umständlicher Prozess wird durch einen Bot nicht besser, nur schneller umständlich.

Bleibt der Fall, für den RPA tatsächlich gedacht ist: Ein System hat keine Schnittstelle, etwa ein älteres Programm ohne API oder ein externes Portal, das nur über den Browser erreichbar ist. Dann kann ein Bildschirm-Roboter eine sinnvolle Übergangslösung sein. Entscheidend ist das Wort Übergang: Der Bot überbrückt die Zeit, bis das Altsystem abgelöst ist oder der Anbieter eine Schnittstelle bereitstellt. Er sollte nicht zum dauerhaften Fundament eines Kernprozesses werden.

Ein Bildschirm-Roboter ist eine Brücke, kein Fundament.

Wenn RPA, dann mit denselben Regeln wie jede Software

Wer RPA als Übergang einsetzt, sollte es behandeln wie jede andere Software im Betrieb:

  • Jeder Durchlauf wird protokolliert: was übertragen wurde, wann und mit welchem Ergebnis.
  • Fehlerfälle landen sichtbar bei einer zuständigen Person, statt stillschweigend übersprungen zu werden.
  • Nach jedem Update der angebundenen Anwendung wird geprüft, ob der Bot noch richtig arbeitet.
  • Es gibt eine fachliche und eine technische Verantwortung, beide namentlich benannt.
  • Es steht fest, wann und wodurch der Bot abgelöst wird, zum Beispiel durch eine Schnittstelle oder durch die Ablösung des Altsystems.

Gerade der letzte Punkt entscheidet, ob aus einer Übergangslösung unbemerkt eine Dauerlösung wird.

Der Weg über die Schnittstelle

Eine Schnittstelle zu bauen bedeutet mehr als die technische Verbindung. Vorher wird geklärt, welches System für welches Feld maßgeblich ist, was bei widersprüchlichen Daten gilt und wer im Fehlerfall entscheidet. Erst dann wird programmiert, mit Protokoll, sichtbaren Fehlerfällen und automatischen Tests.

Für einen Fensterhersteller betreuen wir eine Software, die seit 2022 im täglichen Einsatz ist. Dazu gehört ein nächtlicher ERP-Abgleich von 11 Standorten, und die Software ist durch rund 6.000 automatische Tests abgesichert. Einen Abgleich dieser Größenordnung über Bildschirmmasken zu führen, wäre bei jedem Update der beteiligten Systeme ein Risiko.

Wir entwickeln mit Claude Code, dem KI-Werkzeug von Anthropic. Keine Änderung geht ohne automatische Tests, Code-Review und Freigabe durch einen Menschen in Betrieb. Das gilt für eine Schnittstelle genauso wie für jede andere Software, die wir bauen.

Was die beiden Wege kosten

RPA wirkt auf den ersten Blick günstig, weil an den bestehenden Systemen nichts geändert wird. Zu den Kosten gehören aber die Lizenz für die RPA-Plattform, die Einrichtung jedes Bots und seine Pflege nach jedem Update der angebundenen Anwendungen. Welche Variante sich rechnet, hängt davon ab, wie lange die Lösung tragen soll und wie oft sich die beteiligten Systeme ändern.

Für individuelle Lösungen gelten bei uns diese Bandbreiten, jeweils netto: Eine kleine Fachanwendung kostet 10.000 bis 30.000 Euro, ein System für mehrere Abteilungen 30.000 bis 90.000 Euro, unternehmensweite Lösungen beginnen bei 90.000 Euro. Davor steht eine bezahlte Analyse von ein bis zwei Wochen für 3.000 bis 6.000 Euro, die voll angerechnet wird; ohne verwertbares Ergebnis bekommen Sie das Honorar zurück. Gebaut wird danach zu einem Festpreis je Etappe, Betrieb und Wartung beginnen bei 300 Euro im Monat.

Der erste Schritt

Wenn Sie überlegen, einen Ablauf mit RPA zu automatisieren, oder bereits Bots im Einsatz haben, die nach Updates regelmäßig ausfallen, ist das ein guter Anlass für ein Erstgespräch. In 30 Minuten klären wir kostenlos, ob die beteiligten Systeme eine Schnittstelle anbieten und welcher Weg sich in Ihrem Fall lohnt.

Ihr Vorhaben

Sie haben einen konkreten Fall? Wir ordnen ihn ein, ohne Verkaufsgespräch.

Beschreiben Sie kurz, worum es geht. Thomas Grafenau schaut sich an, ob und wie daraus Software wird, die im Betrieb läuft: eine ehrliche technische Einschätzung, kein Pitch.

Kein Newsletter, kein Verteiler. Nur eine Antwort auf Ihre Anfrage.