Vorteile von RPA mithilfe von Java und Selenium

Sie kennen das: ein großer Teil Ihrer Geschäftslogik basiert auf einer Anwendung wie z.B. einem Siebel-CRM. Ihre Stammdaten sind dort enthalten und viele Geschäftsprozesse abgebildet. Die Anwendung ist unverzichtbar.

In der Regel arbeiten sehr viele Menschen mit dem System. Damit das Geschäft läuft, müssen sie oftmals sich wiederholende Arbeitsschritte durchführen.

So ist es auch bei einem unserer Auftraggeber aus der Telekommunikationsbranche. Verträge werden in diesem System angelegt und geändert. Über Anbieterwechsel kommen neue Kunden in das System und genauso können Kunden das System auch wieder verlassen.

Sehr viele monotone Tätigkeiten gehen damit einher, Listen werden von Ihren Kolleg:innen abgearbeitet, die sich zeilenweise nur in wenigen Parametern unterscheiden. Die Idee liegt nahe, diese monotonen und gut strukturierbaren Prozesse von Menschen auf Maschinen zu übertragen, Stichwort: „Robotic Process Automation (RPA)“.

Deshalb lohnt sich der Einsatz von RPA

Vorteile von RPA haben Sie bestimmt schon oft gehört:

• Weniger Fehler in der Sachbearbeitung, da Menschen bei monotoner Arbeit zu Flüchtigkeitsfehlern neigen
• Freiwerdende menschliche Kapazitäten können für anspruchsvollere Tätigkeiten genutzt werden
• z.B. können diese Kapazitäten im ersten Schritt für die Dokumentation bisheriger Prozesse genutzt werden, da dieses Wissen oft nur in den Köpfen dieser Menschen steckt
• Ein Kreislauf der Verbesserung kann so in Gang gesetzt werden
  
  

POC durch den Auftraggeber

Diese Vorteile wollte unser Auftraggeber ebenfalls. Aus diesem Grund wurde eine Studie durchgeführt und eine Marktanalyse erstellt. Die Wahl fiel schließlich auf den Einsatz von UIPath. Die Annahme war, dass man mit UIPath einfach Prozesse modellieren kann, die der Roboter versteht. UIPath ist außerdem ein großes Unternehmen und bietet einen guten Support, gerade auch in Deutschland. Verglichen mit den Einsparungen durch die Entlastung von Arbeitskräften waren die Lizenzkosten ebenfalls erträglich.

Der erste Bot wurde von einem Dienstleister realisiert, der auf den UIPath-Zug schnell aufgesprungen war. Der Dienstleister setzte einen Spezialisten dafür ein.

Der Kunde zog aus dem Einsatz dieses ersten Bots folgende Schlüsse:

• Die Abhängigkeit von dem Spezialisten war sehr hoch
• Der Bot war sehr komplex durch sehr viele Workarounds
• Gleichzeitig war der Bot zu unflexibel – einfache grafische Modellierung von Prozessen kommt in technisch herausfordernden Situationen schnell an Grenzen
• Zudem lassen sich grafische Modelle sehr schlecht warten nach Änderungen an Prozessen
• Die Ansteuerung von APIs (Siebel JavaBeans) war nicht vorgesehen

Folgendes hat unser Auftraggeber daraus gelernt, weswegen er sich am Ende gegen den Einsatz von UIPath entschieden hat:

• Eine Mischung aus Bedienung der grafischen Siebel-Oberfläche und die Steuerung über Siebel JavaBeans bieten Wahlfreiheit – das gelang mit UIPath nicht
• UIPath-Know-How war nicht so einfach kostengünstig zu beschaffen vgl. z.B. mit Java-Know-How
• UIPath sperrt Monitor und Mauszeiger
• Es ist nur ein Bot pro Maschine nutzbar
  
  

Die viadee kommt ins spiel: Vorteile von RPA mithilfe von Java und Selenium

Diese Nachteile haben dazu geführt, dass der Kunde angefangen hat, eine Entwicklungs-Mannschaft mit vorhandenem Java-Know-How aufzubauen. Deren Aufgabe bestand im Wesentlichen darin, die Roboter auf Basis von Selenium umzusetzen. Hier kam viadee ins Spiel. Mit unserer langjährigen Erfahrung im Java-Umfeld wie auch im Roboter-Bau haben wir den perfekten Mix mitgebracht, um das Team zu unterstützen. Dabei haben wir als Entwickler in einem agilen Team an der Konzeption mitgewirkt, Tests begleitet und standen als Ansprechpartner bei Fragen rund um die produktive Arbeit der Bots zur Verfügung.

Mit dem Einsatz von Java und Selenium konnten folgende Vorteile realisiert werden:

• Flexible Nutzung verschiedener Bots auf einem Rechner
• Schnellere Bots
• Einfacher wiederverwendbare Komponenten
• Fachliches Know-How musste nicht auf externe Mitarbeiter:innen übertragen werden
• Damit einher ging auch ein besseres Gefühl durch weniger Abhängigkeit von Spezialisten
• Make statt Buy: Keine Lizenzkosten

Für unseren Auftraggeber war es der richtige Weg. Den UIPath-Roboter haben wir dann übrigens abgelöst.

In Zukunft werden nächtliche Läufe angestrebt. Wie auch UIPath soll ein eigener Orchestrator eingesetzt werden. Dieser könnte auf Camunda basieren.

Mit dieser Architektur ist es außerdem leichter möglich, zu einer stärker API-basierten Lösung zu migrieren. Denn am Ende ist RPA eine Brückenlösung und der Einsatz von UIPath hätte den Einsatz der eingesetzten Siebel-Version quasi zementiert. Das hätte einen doppelten Lock-In-Effekt bewirkt.