Der richtige Service-Vertrag garantiert den stabilen Betrieb eines RPA Bots und damit einen erheblichen Mehrwert für das Unternehmen
Mit Robotic Process Automation (RPA) können Unternehmen bei der Abarbeitung von Aufgaben einen Grad an Präzision implementieren, der durch menschliches Handeln allein oft unerreichbar ist. In der Regel schlägt sich das in einer verbesserten Back-Office-Performance und letztlich in einem verbesserten Kundenservice und einer höheren Kundenzufriedenheit nieder. Die Kehrseite der Geschwindigkeit und des Umfangs der RPA-Ausführung ist, dass Änderungen in der IT-Umgebung oder scheinbar geringfügige Aktualisierungen einer Software erhebliche Auswirkungen auf die Fähigkeit des Roboters haben, seine Funktion korrekt auszuführen.
Viele Softwareentwickler stehen angesichts der steigenden Nachfrage nach Service-Apps im Zuge der digitalen Transformation unter enormem Zeit- und Erfolgsdruck. Trotzdem neigen viele Unternehmen dazu, ihre RPA-Entwickler gleichzeitig auch als Support- und Wartungs-Notnagel einzusetzen. Mit der Folge, dass dem Entwickler durch Support- und Maintenance-Aufgaben wertvolle Entwicklungszeit verloren geht und sich neue, dringend benötigte (Weiter-)Entwicklungen bzw. Entwicklungen “nach Vorne” den Wartungsarbeiten zum Opfer fallen. Andererseits werden drängende Wartungsarbeiten verschleppt, weil der (Weiter-)Entwicklungen bzw. Entwicklungen “nach Vorne” Vorrang eingeräumt wird. Dadurch entsteht ein Teufelskreis, der die Wahrscheinlichkeit von Ausfallzeiten und zu langen Entwicklungszyklen und die damit verbundenen Kosten erhöht.
Dabei birgt der Einsatz von RPA im Unternehmen aber nicht nur technologiespezifische Herausforderungen, z. B. im Zusammenhang mit der Auswahl und dem Einsatz der RPA-Lösung, sondern auch potenzielle Servicerisiken. Damit hat jede RPA-Implementierung auch eine Serviceperspektive, bei der es um spezifische Serviceparameter, Volumenmetriken und Servicelevels geht. Jedes Unternehmen sollte sich daher überlegen, welche Schritte welche Partei unternehmen muss, um die potenziellen Auswirkungen unmittelbar nach einem Vorfall abzumildern und zu beheben. Ein Service-Vertrag stellt daher eine zwingende Anschlussmaßnahme dar, um einen stabilen Betrieb der RPA-Bots zu gewährleisten, wenn die Prozessautomatisierung live geschaltet wurde.
- Incident Management
- Event Management
- Problem Management
Die Transition in einen laufenden Servicebetrieb wird typischerweise erreicht durch
- Service Level Management
Das Service Level Management (SLM) ist Teil der Service Transition und wird in der Regel nach Zeitaufwand abgerechnet. SLM stellt ein definiertes Maß an Stabilität, Zuverlässigkeit und Leistung für die bereitgestellte IT-Infrastruktur sicher. Das bedeutet, dass potenzielle Probleme identifiziert (z. B. allmähliche Leistungseinbußen) und Warnungen erstellt werden können, wodurch das Risiko von Ausfallzeiten minimiert wird. SLM schafft eine “Komfortzone” für die Qualität einer bestimmten Infrastrukturlösung. Die Service Level Agreements (SLAs) konzentrieren sich dabei auf die Einhaltung der vordefinierten Antwortzeit und der auf dem Schweregrad basierenden Lösungszeit durch den Lieferanten. Die Basis des SLMs bildet eine Liste für jede RPA Prozessautomatisierung, die durch Review existierender Dokumente, durch Code-Review und gegebenenfalls durch Interviews/Workshops erarbeitet wurde. Sie enthält eine Kurzbeschreibung und Angaben
- zur Benennung der RPA Prozessautomatisierung,
- zu den Zuständigkeiten der RPA Prozessautomatisierung (Process Owner),
- zum Vorgehen bei Changes,
- zu den Deploymentprozessen,
- zum Review vorhandener Dokumentation,
- zu den verwendeten Systemen und Benutzern der RPA Prozessautomatisierung,
- zu den implementierten Konfig-Items,
- zu den aktuellen Zeitplänen der Ausführung,
- zur implementierten Fehlerbehandlung,
- zum implementierten Logging,
- zu den Effizienz-Kennzahlen.
In Absprache mit dem Owner einer RPA Prozessautomatisierung können kleinere Anpassungen am RPA Prozess vorgenommen werden, insbesondere wenn sich dadurch eine Verbesserung der Wartungsfreundlichkeit ergibt. Die Reaktionszeiten werden aus dem Ergebnis der Auflistung abgeleitet.
Idealerweise hat der Auftraggeber die Möglichkeit, Störungen und Fehler über ein webbasiertes Ticketsystem (mit kundenindividueller Webadresse) zu melden. Das Ticketsystem bietet neben der klassifizierten Meldung von Störungen Einsicht in eine Liste aller gemeldeten Störungen des Auftraggebers für einen Zeitraum von mindestens der letzten 30 Tage, den Status des Tickets, die Klassifizierung des Tickets, die Priorisierung des Tickets und den aktuell zuständigen Bearbeiter. Dabei werden im Ticketsystem nicht nur die Fehlermeldung, sondern auch die zur Fehlerbehandlung ergriffenen Maßnahmen dokumentiert, so dass der Auftraggeber den jeweils aktuellen Stand der Fehlerbehandlung kontrollieren kann.
Incident Management ist ebenfalls Teil der Service Operation und wird in der Regel über eine Basis-Servicegebühr zzgl. Zeitaufwand abgerechnet. Das Incident Management zielt darauf ab, Vorfälle und Probleme zu beheben, die durch Fehler des Endbenutzers oder Probleme mit der IT-Infrastruktur verursacht werden und den normalen Betrieb stören, und das Wiederauftreten solcher Vorfälle zu verhindern. Das Incident Management gliedert sich in Incident Resolution im 1st Level Support und Incident Resolution im 2nd Level Support. Ziel ist es in beiden Fällen, eine Störung schnellstmöglich zu beheben, auch unter Anwendung von Workarounds, etwa bei bekannten Problemen.
Im Rahmen des Incident Resolution im 1st Level Support können kleinere Anpassungen zur Aufrechterhaltung des Betriebs angepasst werden, wenn sich diese beschränken auf:
- Änderungen der Konfiguration
- Anpassungen von Benutzer-Credentials
- Änderungen an der Auslastung in der RPA Infrastruktur
- Bis zu zwei Selektor-Änderungen
Soweit es erforderlich ist, greift der Service-Provider auch auf Ressourcen des Auftraggebers zurück, z. B. auf das Identity Management zur Neuvergabe von Passwörtern.
Handelt es sich um weitergehende Anpassungen, werden diese über den 2nd Level Support und in Absprache mit dem Auftraggeber vorgenommen. Hierzu zählen Änderungen an der Geschäftslogik, umfangreiche Selektoranpassungen und Änderungen, die der Freigabe durch den Betreiber der RPA Infrastruktur sowie der Freigabe durch den Fachbereich bedürfen. Falls notwendig, greift der Service Provider auch auf Ressourcen des Auftraggebers zurück, beispielsweise auf das Application Management bei Abhängigkeiten von Nachbarsystemen.
Die Fehlerbehandlung findet auf der Basis gemeldeter Störungen (“Incidents”) statt. Fehler an den RPA Prozessautomatisierungen sollten innerhalb eines definierten Zeitrahmens (z. B. von acht Stunden) nach Zugang einer ordnungsgemäßen Fehlermeldung über das Ticketsystem mindestens bearbeitet, im besten Fall behoben werden. An den RPA Prozessautomatisierungen auftretende blockierende Fehler werden mit höchster Priorität behandelt. Hierbei handelt es sich um Störungen, die die Ausführung der Prozessautomatisierung oder mehrerer Prozessautomatisierungen verhindert, so dass eine Nutzung ganz oder nahezu vollständig unmöglich ist. Die Fehlerbehandlung umfasst dabei die Eingrenzung der Fehlerursache, die Fehlerdiagnose sowie Leistungen, die auf die Behebung des Fehlers gerichtet sind. Zur Fehlerbehandlung gehört auch die Information des Auftraggebers darüber, wie und bis wann ein Fehler beseitigt werden kann bzw. ob und wenn ja, wie der Auftraggeber Fehlfunktionen umgehen kann. In aller Regel werden Fehlerbehandlungen remote durchgeführt.
Das Ziel von Service Operation ist es, sicherzustellen, dass die IT-Services effektiv und effizient bereitgestellt werden und gleichzeitig die höchste Servicequalität erhalten bleibt. Die Service Operation Prozesse bilden die Grundlage für eine effektive IT-Support-Struktur, die effizient ablaufen muss, damit alles reibungslos funktioniert. Die Service Operation Prozesse umfassen neben dem Event Management, dem Incident Management auch das Request Fulfillment und das Problem Management und dürfen deshalb auch in keinem Service-Vertrag fehlen.
Nicht jeder Service Request beruht auf einer Störung oder bedarf gründlicher Abstimmung. Daher ist es sinnvoll, bekannte und wiederholte und standardisierte Service Requests ohne gesonderte Freigabeprozesse zu vereinbaren. Im Rahmen der Wartung der RPA Infrastruktur hält der Service Provider in Abstimmung mit dem Auftraggeber die Komponenten der RPA Plattform aktuell, installiert zusätzliche Komponenten, unterstützt bei der Aktivierung sowie beim Customizing der RPA Plattform und berät den Auftraggeber bei How-To-Fragen.
Im Problem Management werden die Lösungen aus den Incidents gesammelt und daraufhin untersucht, ob zukünftige Störungen vermieden oder -in ihrer Auswirkung minimiert werden können.
Das Problem Management untersucht dazu die Root Causes, um Changes vorzuschlagen.
Das Problem Management arbeitet dazu eng mit dem Auftraggeber zusammen und trifft insbesondere auch Aussagen zum erwarteten Aufwand der Implementierung von Changes und erarbeitet proaktiv Vorschläge, z.B. wenn bekannt wird, dass Änderungen in der Systemlandschaft des Auftraggebers anstehen.
RPA im Unternehmen zu implementieren ist die eine Sache. Ein reibungsloser Betrieb der RPA-Bots ist eine andere Sache. Schnittstellenaktualisierungen, Sicherheitspatches oder auch Prozessänderungen können RPA-Bots schnell aus dem Arbeitstakt bringen. Ein bedarfsgerechter Wartungsservice stellt dabei aber sicher, dass Unternehmen alle Vorteile ihrer Automatisierung nutzen können, da die Software-Roboter rund um die Uhr und 365 Tage im Jahr reibungslos funktionieren. Die Identifizierung und Klassifizierung der Bots bzw. Prozessautomatisierungen entsprechend der Komplexität der Automatisierung bilden dabei die Grundlage eines jeden Wartungsvertrags. Nur wenn im Rahmen eines Service Level Managements mit individuell angepassten SLAs gewährleistet ist, dass ausreichend Ressourcen zur Verfügung stehen, um auftretende Events und Incidents je nach Kritikalität / Kategorisierung schnellstmöglich zu beseitigen, kann eine Automatisierungslösung über den gesamten Lebenszyklus hinweg und insbesondere im Betrieb den gewünschten Mehrwert für das Unternehmen liefern.
Milad Safar ist Managing Partner der Weissenberg Group, die er 2013 mit dem Ziel gründete, Prozesse durch den Einsatz von intelligenten Automatisierungslösungen effizienter zu gestalten. Schon während seines Studiums der Volkswirtschaftslehre interessierte er sich für zukunftsweisende Technologien. Getrieben durch die Erkenntnis, dass viele Prozesse wertvolle Arbeitszeit verschlingen, beschäftigt sich Milad Safar von Beginn seiner Beratertätigkeit an mit den Themen Digitalisierung, Robotics und Künstliche Intelligenz, zu denen er auch regelmäßig Vorträge hält, an Expertenrunden teilnimmt und Beiträge in namhaften Fachmagazinen veröffentlicht. Er ist Co-Buchautor des 2019 von WEKA Media herausgegebenen vierbändigen IT-Lexikons “Informationstechnologie von A-Z”. Als Initiator rief er 2018 das jährlich stattfindende AI Camp Wolfsburg ins Leben, eine Diskussionsplattform rund um die Themen Künstliche Intelligenz, Robotics, Maschinelles Lernen und deren Anwendung.
Weissenberg Group mit Sitz in Wolfsburg wurde 2013 von Milad Safar und Marcel Graichen gegründet und beschäftigt 82 Mitarbeiter. Weissenberg Group ist der interdisziplinäre Ansprechpartner für hocheffiziente und innovative IT-Lösungen. Das Kerngeschäft der Weissenberg Group wird durch die Unternehmensbereiche Weissenberg Solutions und Weissenberg Intelligence abgedeckt.
Das Kerngeschäft von Weissenberg Intelligence bilden die vielfältigen Anwendungsmöglichkeiten, die sich für Unternehmen durch den Einsatz von Robotic Process Automation und Künstlicher Intelligenz ergeben. Im Zentrum steht die Automatisierung standardisierter, regelbasierter Prozesse durch Software-Roboter, um die vorhandenen Ressourcen effizienter einzusetzen und damit für die Unternehmen letztendlich einen wirtschaftlichen Mehrwert zu schaffen.