RPA im Shared Service Center: Automatisieren oder erst standardisieren?
Im Shared Service Center der Hallmann-Gruppe bearbeiten 26 Mitarbeitende Reisekostenabrechnungen für neun Gesellschaften. Jede Gesellschaft hat eigene Regeln: fünf verschiedene Kontenpläne, drei Freigabegrenzen, zwei Währungen. Die Durchlaufzeit liegt bei 6,2 Tagen, 18 Prozent der Belege werden zurückgewiesen. Der Vorstand hat ein RPA-Pilotprojekt genehmigt (Lizenz 60.000 Euro pro Jahr, 12 Bots), das die Belegprüfung automatisieren soll. Der Prozessverantwortliche hat 40 Arbeitsschritte dokumentiert, davon sind 25 manuelle Prüfungen. Der Betriebsrat fordert eine Vereinbarung zu Leistungs- und Verhaltenskontrolle. Zwei Gesellschaften wollen ihre Sonderregeln nicht aufgeben. Ein Berater empfiehlt, zuerst zu standardisieren, dann zu automatisieren – der CFO will Ergebnisse in vier Monaten sehen. Für die Pilotierung sind sechs Monate und zwei Gesellschaften vorgesehen.
1. Beurteilen Sie, ob der RPA-Ansatz hier tragfähig ist. Begründen Sie mit Bezug auf die Prozessmerkmale und geben Sie eine Empfehlung zur Reihenfolge.
Read the worked answer
Analyse an den Prozessmerkmalen:
- Regelvarianz: fünf Kontenpläne, drei Freigabegrenzen, zwei Währungen. Jede Variante braucht im Bot eigene Verzweigungen und eigene Testfälle. 25 manuelle Prüfungen mit hoher Varianz sind der teuerste Teil der Automatisierung – und der wartungsintensivste.
- Instabilität: 18 Prozent Rückweisungen deuten nicht auf Fleißprobleme hin, sondern auf unklare Regeln. Wer unklare Regeln automatisiert, bekommt Rückweisungen in größerer Stückzahl und schneller.
- Prozessreife: 40 dokumentierte Schritte sind eine gute Grundlage, aber Dokumentation ist keine Standardisierung.
Empfehlung: beides parallel, mit klarer Rollenverteilung.
- Sofort automatisierbar: die 15 Schritte ohne Regelvarianz (Belegerfassung, Dublettenprüfung, Verteilung, Erinnerungen). Kurzfristiger Erfolg, geringes Wartungsrisiko.
- Gleichzeitig Standardisierung: Zielbild ein Kontenplan, zwei Freigabegrenzen, eine Währung. Entscheidung durch den CFO, nicht durch das Projekt.
- Regel: Keine Automatisierung von Schritten, die in zwölf Monaten entfallen sollen. Sonst werden Bots zu Denkmälern gewachsener Sonderregeln.
Wirtschaftlichkeit grob: 60.000 Euro Lizenz pro Jahr müssen gegen eingesparte Bearbeitungszeit gerechnet werden. Bei 6,2 Tagen Durchlaufzeit liegt der größere Hebel zunächst in der Standardisierung, weil ein erheblicher Teil der Zeit Wartezeit ist – der Bot beschleunigt einen Prozess, der vor allem aus Warten besteht.
Antwort an den CFO: Ergebnisse in vier Monaten sind erreichbar, aber als Standardisierungs- und Transparenzergebnis, nicht als Vollautomation.
2. Wie gehen Sie mit den zwei Gesellschaften um, die ihre Sonderregeln behalten wollen?
Read the worked answer
1. Kosten der Varianz sichtbar machen. Für jede Sonderregel den Preis ausrechnen: zusätzliche Prüfschritte, eigene Bot-Variante, Testaufwand, Schulung, Betrieb, Prüfungsrisiko. Eine Zahl pro Sonderregel und Jahr verändert die Diskussion von „wir brauchen das“ zu „das ist es uns wert oder nicht“. Ohne diese Zahl ist jede Debatte eine Machtfrage.
2. Entscheidungsrecht klären. Die Gesellschaften entscheiden über ihre Regel, aber nicht über die Kostenfolge im Shared Service. Die Entscheidung liegt beim CFO auf Basis der Zahlen aus Schritt 1; die Projektleitung bereitet vor und empfiehlt.
3. Modell mit Stufen statt Verbot.
- Kern: einheitlicher Standard, automatisiert, kostengünstig.
- Genehmigte Variante: explizit beantragt, befristet, mit Preisaufschlag und Ablaufdatum.
- Sonderweg: außerhalb des Shared Service, auf eigene Kosten der Gesellschaft.
4. Ausstiegspfad statt Endlosigkeit. Jede Variante erhält ein Ablaufdatum und eine Bedingung, unter der sie endet (Vertragswechsel, Systemwechsel, neue Freigabegrenze). Damit ist die Ausnahme möglich, aber nicht dauerhaft.
5. Nicht moralisieren. Sonderregeln entstehen selten aus Bosheit, sondern aus Steuer-, Vertriebs- oder historischen Gründen. Wer sie pauschal als Widerstand labelt, verliert die Gesellschaften als Partner und bekommt Schattenprozesse statt Standardisierung – also genau das Gegenteil des Projektziels. Zusätzlich: Die zwei Gesellschaften früh als Pilotkunden einbinden, damit sie Mitgestalter der Standardvariante werden.
3. Welche Inhalte muss eine Betriebsvereinbarung haben, damit das Projekt nicht blockiert wird, und wie sichern Sie die Mitbestimmung praktisch ab?
Read the worked answer
Zweck und Gegenstand: klare Beschreibung, welche Daten die Bots verarbeiten, welche Protokolle entstehen und wofür sie verwendet werden dürfen. Pauschale Formulierungen sind der häufigste Grund für Nachverhandlungen mitten im Betrieb.
Kernpunkte:
- Keine Leistungs- und Verhaltenskontrolle. Protokolldaten dienen der Prozesssicherheit und Fehleranalyse, nicht der Bewertung einzelner Beschäftigter. Auswertungen nur aggregiert und mit definiertem Mindestumfang je Gruppe.
- Zweckbindung und Löschung: Aufbewahrungsfristen für Protokolle, Löschroutine, benannter Verantwortlicher.
- Transparenz: Beschäftigte erhalten Auskunft über die zu ihrer Tätigkeit gespeicherten Daten.
- Beteiligung bei Änderungen: neue Bots, neue Prüfschritte, neue Kennzahlen werden vorab vorgelegt; Betriebsrat und Fachbereich erhalten feste Fristen zur Stellungnahme.
- Qualifizierung statt Abbau: konkrete Zusage, welche Rollen entstehen (Bot-Betrieb, Regelpflege, Ausnahmebearbeitung) und welche Weiterbildung angeboten wird. Das ist der Punkt, der die Zustimmung praktisch trägt.
- Evaluation: Überprüfung nach zwölf Monaten anhand gemeinsam vereinbarter Kriterien.
Praktische Absicherung: Die Vereinbarung läuft parallel zur Pilotierung, nicht danach. Der Pilot wird auf einen abgegrenzten Bereich mit definierten Daten begrenzt, damit der Betriebsrat zustimmen kann, ohne das Gesamtprojekt zu blockieren. Mitbestimmung ist hier kein Hindernis, sondern der Mechanismus, der Akzeptanz erzeugt – ohne sie scheitert der Bot-Betrieb an der täglichen Ausnahmebearbeitung, und das Projektziel verschwindet in der Grauzone.