RPA ist eine Reise
und nicht nur ein Projekt

Die RPA-Tools einiger Anbieter haben sich schnell von einfachen Workstation-Robotern zu einer komplexen Unternehmenssoftware entwickelt. Aber viele Unternehmen können mit der RPA-Technologie nicht mithalten, da die ausgewählten Anbieter den Anforderungen der IT- und Geschäftsarchitektur nicht gerecht werden können. IT-Architektur: Es ist allgemein bekannt, dass neue Technologien in den IT-Abteilungen erforderlich sind, um den architektonischen Kriterien zu entsprechen. Beispiel: offene und erweiterbare Technologie, stabil und gut dokumentiert, allgemeine Fähigkeiten und solide Sicherheitskonformität. RPA-Tools sollten keine Ausnahme bilden. Geschäftsprozessarchitektur (Business Process Architecture, BPA): das gewählte RPA-Tool muss in der Lage sein, alle wichtigen Geschäftsprozesse zu automatisieren. Dazu gehören virtuelle Umgebungen, die Verwendung von OCR, Anforderung kognitiver Intelligenz usw. BPA definiert und dokumentiert diese Kernprozesse sowie die Beziehungen und Abhängigkeiten und bildet damit den perfekten Rahmen für eine Zusammenstellung der Auswahlkriterien für den richtigen Lieferanten.

Das Ziel eines Konzeptnachweises ist nicht zu bestätigen, dass RPA kann, was es verspricht. Der primäre Zweck des Konzeptnachweises besteht darin, Geschäftsfallannahmen zu testen, das beste Implementierungsmodell zu validieren und RPA-Integrations- und Technologiepartner zu bewerten. Dennoch bleibt für viele Unternehmen eine Bestätigung der RPA-Fähigkeiten das Ziel des Konzeptnachweises. Diese Fehlannahme führt in der Regel zu einem Konzeptnachweis, der wenig zeigt, nicht ausführbar ist und die RPA-Umsetzung oft an Schwung verlieren lässt. Er zeigt wenig, da viele solide Geschäftsfälle die Technologie bereits unter Beweis gestellt haben. Er ist nicht ausführbar, weil ein RPA validierender Konzeptnachweis keine Erkenntnisse mit sich bringt, wie RPA innerhalb dieses entsprechenden Unternehmens funktionieren könnte. Schwung geht verloren, weil es keinen offensichtlichen nächsten Schritt gibt. Der Konzeptnachweis sollte so gestaltet sein, dass er den Grundstein für den viel konkreteren ersten Testlauf legt und die Antworten und Validierungen liefert, die zur Genehmigung nötig sind, mit dem Testlauf fortzufahren.

Mit wenig Engagement geleitete RPA-Pipelines enden oft mit sehr komplizierten Kandidaten für die Process Automation. Vielleicht ist es ein Fall von Vermessenheit, nach dem Motto „RPA kann alles!“. Oder die Entscheidung, einen hochkomplexen Schwachpunkt über einfachere Einsparpotenziale zu stellen, wird einfach subjektiv getroffen. Jedenfalls ist es ein Fehler, strenge Prioritäten zu vernachlässigen. Wenigstens im ersten Jahr der RPA-Reise sollten ausgewählte Prozesse auf eine geringe oder mittlere Komplexität beschränkt werden, die ein aggregiertes Einsparpotenzial von mindestens einer Vollzeitstelle demonstrieren.

Einige Unternehmen haben sich so auf die Idee eines vollautomatisierten End-to-End-Prozesses versteift, dass sie die Realität abnehmender Erträge übersehen. Andere konzentrieren sich so sehr auf die Automatisierung komplexer Prozessschritte, dass der Gedanke, diese Schritte durch eine Umgestaltung zu eliminieren, nie wirklich gefasst wird. Es ist wichtig, sich die niedrigen Kosten und die zurückhaltende Arbeit von RPA ins Gedächtnis zu rufen. Im Gegensatz zu anderen Automatisierungstechnologien kann sie eine hohe Kapitalrendite bei nur teilweiser Automatisierung von Prozessschritten generieren. Der Versuch, einen Prozess zu sehr zu automatisieren, kann die Kaptialrendite durch höhere Implementierungskosten senken. Ebenso ist es oft klüger, den Prozess zu optimieren, als einen Roboter für komplizierte Regeln zu konfigurieren.