Gibt es einen Konflikt zwischen Fachabteilungen, als Befürworter von RPA und IT Vertretern, als Skeptikern von RPA?
Warum ist Low-Code eine meist unbeachtete Alternative ?
Über den Author:
„Dipl.-Inform Olaf Neidhardt, geboren 1967, ist Unternehmer und BPM/Low-Code Evangelist mit Appian. Er steht für Prozessmanagement, dass Menschen in der IT und in der Fachabteilung gemeinsam mitnimmt und dabei in einem dynamischen Umfeld der Digitalisierung massiven finanziellen Nutzen erzeugt. Als zweiter verantwortlicher Lizenznehmer in Deutschland der US-Trendsoftware APPIAN, lange vor den jetzt folgenden Großkonzernen, verfügt er über ausgeprägtes Wissen rund um LowCode Development mit APPIAN. Dabei profitierten die Unternehmen enorm von seiner weit mehr als 20 Jahren Erfahrung in der Digitalisierung von Prozessen. Er gründete 2020 die international vernetzte appassionals GmbH mit dem Ziel, sich vor allem der Automatisierung von Prozessen rund um die LowCode/BPM Plattform APPIAN zu widmen. Für ihn waren die Begriffe „Application“, „Passion“ und „Professional“ die Basis, die der appassionals GmbH den Namen gaben.“
Teil 1
dieser kleinen Serie widmet sich der Frage ob es einen Konflikt zwischen meist Fachabteilungen, als Befürworter von RPA und meist IT Vertretern, eher als Skeptikern von RPA gibt und warum Low-Code eine meist unbeachtete Alternative darstellt.
Teil 2
nennt 3 konkrete Punkte bei denen der Einsatz von RPA richtig ist (PRO)
Teil 3
nennt 3 klare Kriterien, die gegen den Einsatz einer RPA Lösung sprechen (CONTRA) und zieht ein kurzes Fazit.
Teil 1
Derzeit redet die ganz Welt über den Einsatz von Robotern (RPA – Robotic Process Automation) in der Digitalisierung. Für viele Fachabteilungen scheinen Roboter der Gipfel der Kosteneinsparung zu sein. Voran getrieben werden sie vom Vertriebsdruck aller großen und kleinen Beratungshäuser, die hier ein unbestelltes weites und ertragreiches Feld in den Fachabteilungen ihrer Kunden erkennen. In diesen Zeiten der Digitalisierung müssen Unternehmen immer schneller und produktiver werden und wollen gern mithalten. Die „non-IT“ Technologie RPA scheint wie geschaffen andere Ansprechpartner in den Fachabteilungen zu finden, die am Ende, so das Kalkül der Beratungshäuser, doch eine Menge „technischen Backups“ durch ihre Jung-Berater brauchen werden, wenn die Lösung erst mal auf dem Tisch der Fachmenschen steht. Besonders dann, wenn der junge und engagierte Berater das Unternehmen wieder verlässt und die Tür hinter sich zugezogen hat, durch die sein Senior-Partner im Vertrieb schon lange vorher gegangen ist, wird der Fachabteilung schmerzlich klar, dass sie mit der Sache nun allein dasteht.
Manch Zweifler wird dahinter vielleicht eher den Wunsch der Fachabteilungen sehen, nicht mehr auf die IT-Dinosaurier in ihrer Welt angewiesen zu sein, schneller zu wirken und Erfolge selbst vorweisen zu können, ohne auf das in langer und schmerzvoller Erfahrung angehäufte Fachwissen der IT angewiesen zu sein. Auch scheinbar ohne die unzähligen dokumentarischen und aufsichtsrechtlichen Auflagen beachten zu müssen, die eine IT heute geradezu strangulieren (DSVGO; Basel 2, 3 etc.),
Der Schwung dieser Technologie scheint so weit fortgeschritten, dass IT-ler, die auf die ungeliebten Risiken und Probleme dieser eigentlich altbekannten Technologie in neuen Tüchern von neuen Unternehmen (Start-Ups und Softwareunternehmen), an den Start gebracht hinweisen, häufig gar nicht mehr zu Wort kommen. Sie werden gerne mit Schimpf und Schande als Bedenkenträger und Blockierer hinter ihre Konsolen zurück gejagt und beim Hinausgehen zwinkern die Kollegen sich hinter ihrem Rückend abschätzig zu: „Die in der IT wieder …“.
Auf jeder Konferenz findet sich mindestens ein Sprecher aus einer Fachabteilung eines Großunternehmens, der starke Zahlen über Einsparungen oder Fallzahlen des letzten Jahres vorlegen kann, die mit Hilfe von RPA Lösungen der bekannten Unternehmen wie UI Path, BluePrism, Automation Anywhere oder WorkFusion gewonnen wurden, um nur die vier „Market Leaders“ im Magic Quadrant for Process Robotics von Gartner 2020 zu nennen.
Quelle : Gartner RPA Magic Quadrant 2020
Kritiker mögen sich die Frage stellen, ob derselbe Sprecher drei Jahre später immer noch auf diesen Konferenzen auftreten mag, aber dies wird uns die Zukunft zeigen.
Warum aber dieser Disput zwischen Befürwortern von RPA und den Gegner von RPA?
Diese Frage kann man sicher aus vielen Perspektiven beantworten, wie Architektur, Compliance, Risiken, Wartbarkeit, Qualität, Nachhaltigkeit, Gesamtkomplexität oder Etat-Allokation im Sinne der Umsetzung einer chronisch unterfinanzierten IT-Strategie.
Aber ich schreibe aus einem Low-Code Umfeld heraus und als solches stellt sich die Frage der Wahl der Alternative an dieser Stelle.
Soll ich ein bestehendes Problem besser mit einem RPA Bot angehen oder doch besser mit einer Low-Code Umgebung eine Lösung schaffen? Diese Frage müssen sich IT-Vertreter und Business Vertreter gleichermaßen stellen, wenn sie einen vollständigen Business Case betrachten, der eben nicht nur von Business Zahlen dominiert wird. Beide Wege dürften das Bedürfnis einer schnellen Lösung adressieren, das sicher im Raum steht, wenn man eine klassische IT-Lösung in der Entwicklung oder Beschaffung schon ausgeschlossen zu haben scheint.
Die RPA Vertreter werden sicher auf die Einfachheit ihrer Lösung, den Kollegen „Roboter“ (der übrigens aus ihrer Sicht nur ein weiterer metallener Mitarbeiter ist…), die Möglichkeit des 24/7 Einsatzes, das Tempo ihrer Implementierung und eben die Tatsache verweisen, dass die Umsetzung in der Fachabteilung passieren kann. (Ist es wirklich nicht meist tatsächlicher der junge Berater, der in der FA dafür eingekauft wurde, oder doch der Finanzbuchhalter?).
Und natürlich, wie bereits oben angesprochen die lange Liste der in der kürzeren Vergangenheit erzielten wirtschaftlichen Erfolge von RPA im Allgemeinen bei anderen.
Für die Low-Code Vertreter ist ein Bot, der über das UI zweier Systeme als „User“ agiert, zunächst mal nichts mehr als eine (nicht)-menschliche Schnittstelle zwischen zwei Systemen.
Und die Tatsache, dass hier ein Robot diskutiert wird zeigt, dass ein Business Case für die Schnittstelle des Prozessflusses dieser Daten an dieser Stelle tatsächlich vorhanden ist.
Da ein Roboter, so wird der Low Code Vertreter sagen, am StatusQuo nichts verändert, beseitigt er das Problem auch nicht.
Um es mit einer Analogie aus der Medizin zu sagen: Man „klebt“ quasi nur ein Schmerz-Pflaster auf das schmerzende IT Knie und behebt den eigentlichen Schaden am Gelenk nicht.
Somit stellt er aus IT-Sicht auch keine Beseitigung des Problems dar, sondern nur eine Bekämpfung des Symptoms. Schlimmer noch: Eine weitere Stelle, an der eine Wundpflege für ein immer noch vorhandenes Problem nötig wird.
Ich hörte von Beispielen aus der Wirtschaft, bei der sich Unternehmen derzeit Loben, dass sie bereits weit mehr als 2.000 Bots im Einsatz haben. Das sind dann näherungsweise 2.000 zusätzliche Schnittstellen, die zu pflegen sind und nicht mit dem Softwarepflege – und Testverfahren des Unternehmens verbunden sind.
Aber immerhin läuft der Patient wieder. Zumindest, bis dieser Patient sich wäscht (ein Update erfährt) und das Pflaster wieder neu überarbeitet werden muss.
Ein IT-ler kriegt Kopfschmerzen, wenn er an all die Pflaster denkt, die da auf seinen Patienten geklebt werden könnten, der doch die Ursachen für die Schmerzen und die geplanten Operationen gar nicht kennt. Zudem ist der Klebende vermutlich kein Mediziner und er wird sich an nichts halten, was in Richtung Hygiene, Anamnese und Therapie Standard in der Medizin sein dürfte.
Möglicherweise ist der Arzt des Patienten (sein IT Manager) auch nicht zufrieden, weil er am kaputten Knie Folgeschäden erwartet, auf die er zwar hingewiesen hat, für die er aber mangels Behandlung von der Krankenkasse oder der Berufsgenossenschaft nicht zur Verantwortung gezogen werden möchte, weil er immer gesagt hat, dass das Pflaster des Quacksalbers nicht langfristig helfen wird.
Solche Schreiben, die in dieser Analogie genannte Berufsgenossenschaft zum Beispiel, kommen dann im Falle der IT vom Landesdatenschutzbeauftragten, der IT Revision oder der BAFIN.
…Lesen Sie weiter in Teil 2 über die ersten 3 PRO Argumente für den Einsatz einer RPA Lösung.
…Lesen Sie weiter in Teil 3 über 3 CONTRA Argumente gegen einen Einsatz einer RPA Lösung.