Prüfungsabläufe mit RPA automatisieren

Die Aufgabe

Qualitätsprüfungen nach festem Fragenkatalog, Bestände zwischen Werkzeugen umziehen: identische Schritte, vorhersagbares Ergebnis — und Menschen davor.

Kunde: Prüfungs- und Beratungshaus
Branche: Finanz- und Prüfungswirtschaft
Dauer: drei Monate

Prüfungsabläufe per RPA automatisiert, in zwei Teststufen geprüft und dokumentiert übergeben

3 Monate

Projektlaufzeit für beide Abläufe, je eineinhalb Monate

Kurz zum Kunden

International tätige Gesellschaft für Wirtschaftsprüfung und Beratung, in Deutschland mit Standorten im gesamten Bundesgebiet und eingebunden in ein weltweites Netzwerk. Die Geschäftsfelder reichen von der Prüfung und prüfungsnahen Dienstleistungen über Steuerberatung und Rechtsberatung bis zu Advisory Services.

Unsere Lösung

RPA ist ehrlich: Die Automatisierung scheitert an genau der Stelle, an der der Prozess nicht definiert ist.

Die Aufgabe

In der Prüfung gibt es Arbeit, die niemand vermisst. Qualitätsprüfungen anhand feststehender Fragenkataloge, das Umziehen von Beständen zwischen Prüfungswerkzeugen, das Zusammenstellen von Salden. Die Schritte sind identisch, das Ergebnis ist vorhersagbar, und trotzdem sitzen Menschen davor. Aus Workshops kommen drei solche Abläufe, die sich für Robotic Process Automation anbieten — also für eine Automatisierung, die die vorhandenen Anwendungen über deren Oberflächen bedient, statt sie zu ersetzen.

Unser Ansatz

Erst die Daten prüfen, dann entwickeln. Vor der Umsetzung haben wir den bereitgestellten Fragenkatalog und den Zugang zu den Systemen auf Konsistenz und Verwendbarkeit geprüft und dort angepasst, wo es nötig war. Der Grund ist einfach: Eine RPA-Automatisierung kann nicht improvisieren. Was fachlich uneindeutig ist, bleibt uneindeutig, nur schneller. Deshalb steht in der Vereinbarung ausdrücklich, dass die fachlich korrekten und vollständigen Zuordnungen in maschinenlesbarer Form beizubringen sind.

Den dritten Ablauf haben wir nicht angeboten. Aus den Workshops kamen drei Kandidaten. Zwei ließen sich beschreiben, schätzen und terminieren. Der dritte hing an einer automatischen Kontenzuordnung, die es nicht gab, und ohne die weder Aufwand noch Termin belastbar waren. Wir haben ihn deshalb aus dem Angebot herausgenommen und das begründet, statt eine Zahl zu nennen, die niemand halten kann. Ein Angebot, das alles enthält, ist meist keines.

Modelliert, bevor programmiert wurde. Für beide Abläufe wurde der technische Prozess modelliert und alle Ein- und Ausgangsgrößen definiert, bevor die Umsetzung begann. Beide Prozessmodelle waren Teil des Angebots — damit beide Seiten dasselbe Verständnis davon hatten, was die Automatisierung tut und wo sie aufhört. Bei RPA ist das keine Formalie: Was über Oberflächen bedient wird, bricht bei jeder unerwarteten Maske.

Zwei Teststufen, weil zwei Dinge schiefgehen können. Entwicklertests prüfen, ob die Bausteine funktionieren. Fachtests prüfen, ob das Ergebnis das ist, was ein Prüfer erwartet. Wir haben die fachlichen Tests der Kollegen des Hauses begleitet und nicht ersetzt: Ob eine Freitexterkennung die richtige Antwort erkannt hat, entscheidet der Fachbereich, nicht der Entwickler. Am Ende stand eine Dokumentation aller Projekt- und Softwarebestandteile, die eine Übergabe erst möglich macht.

Das Ergebnis

Zwei per RPA automatisierte Prüfungsabläufe, jeder in eineinhalb Monaten umgesetzt.

Der Weg führt von der Datenanalyse über das technische Prozessmodell und die Umsetzung bis zu Entwicklertests, Fachtests mit den Kollegen des Hauses und einer Dokumentation, die eine Übergabe zulässt. Der eine Ablauf dient der Qualitätssicherung anhand des Fragenkatalogs, der andere der Migration von Beständen zwischen Prüfungswerkzeugen, beide einschließlich der Erkennung von Freitextangaben. Der dritte Ablauf ist nicht angeboten worden, weil er von einer Zuordnung der Konten abhängt, die es noch nicht gibt — eine seriöse Aufwandsschätzung ist dafür nicht möglich.