Praxisleitfaden
Der Ausnahmefall gehört in den Prozess – bevor er automatisiert wird
Wie Prozessverantwortliche fachliche Ausnahmen erkennen, sicher anhalten, entscheiden, zurückführen und zur Verbesserung nutzen.
Prozessautomatisierung beginnt gern mit dem Idealfall: Antrag vollständig, Daten korrekt, Freigabe eindeutig, Schnittstelle verfügbar. Der Ablauf wird schnell, solange die Wirklichkeit dem Modell folgt. Sobald eine notwendige Angabe fehlt, eine Regel nicht eindeutig greift oder ein System nicht antwortet, verlässt die Arbeit jedoch den Prozess. Sie wandert in E-Mail, Chat, Excel oder den Kopf einer erfahrenen Person.
Damit ist die Ausnahme nicht verschwunden. Sie ist nur unsichtbar geworden.
Der Standardweg ist wichtig, aber nicht hinreichend. Ein Prozess ist erst automatisierungsfähig, wenn er auch festlegt, wie er Abweichungen erkennt, sicher anhält, entscheiden lässt und in einen kontrollierten Zustand zurückkehrt.
Ausnahme ist nicht gleich Fehler
Für die Gestaltung lohnt eine saubere Trennung. Unterschiedliche Abweichungen benötigen unterschiedliche Reaktionen:
| Art | Beispiel | Angemessene Reaktion |
|---|---|---|
| Erwartete fachliche Ausnahme | eine zulässige Bestellung liegt über der normalen Freigabegrenze | an eine befugte Rolle weitergeben |
| Unvollständige oder widersprüchliche Daten | Kostenstelle fehlt oder zwei Stammdatenquellen widersprechen sich | Klärung anfordern und Vorgang sicher parken |
| Technischer Fehler | Schnittstelle oder Zielsystem ist nicht erreichbar | Wiederholung begrenzen, überwachen und technisch eskalieren |
| Regel- oder Richtlinienabweichung | gewünschter Zugriff widerspricht dem Standard | Ausnahme begründen, Risiko entscheiden und befristen |
| Verdacht auf Missbrauch | ungewöhnliche Änderung von Zahlungsdaten | Verarbeitung stoppen und getrennten Kontrollweg auslösen |
Wer alle Fälle in eine allgemeine Queue „manuell prüfen“ schiebt, hat formal einen Ausnahmeweg. In der Praxis fehlen weiterhin Priorität, Befugnis und Entscheidungskriterien. Umgekehrt darf ein technischer Wiederholungsmechanismus keine fachliche Unklarheit kaschieren. Ein zehnter automatischer Versuch entscheidet nicht, ob eine Bestellung zulässig ist.
Der Ausnahmeweg ist Teil des eigentlichen Prozesses
Die BPMN-Spezifikation der Object Management Group bietet unter anderem Ereignisse, Fehler- und Eskalationsmechanismen, um alternative und unterbrechende Abläufe präzise darzustellen. Für einen mittelständischen Prozess ist nicht zwingend ein vollständiges BPMN-Modell erforderlich. Die zentrale Denkweise ist dennoch wertvoll: Eine Abweichung besitzt einen Auslöser, einen Zustand und einen definierten weiteren Weg.
Ein belastbarer Ausnahmeablauf beantwortet sieben Fragen:
- Erkennen: Woran erkennt der Prozess, dass der Standardweg nicht zulässig oder nicht möglich ist?
- Sichern: In welchem Zustand werden Daten, Fristen und bereits erfolgte Entscheidungen bewahrt?
- Zuweisen: Welche Rolle übernimmt die Ausnahme, und besitzt sie das notwendige Entscheidungsrecht?
- Informieren: Wer muss wissen, dass und warum der Vorgang wartet?
- Entscheiden: Welche Optionen bestehen, und welche Nachweise sind dafür erforderlich?
- Zurückführen: An welcher Stelle kehrt ein freigegebener oder korrigierter Vorgang in den Standardweg zurück?
- Lernen: Wird ein wiederkehrender Ausnahmegrund künftig zur Regel, zur Prozessverbesserung oder bewusst zum manuellen Fall?
Diese Fragen gehören vor die technische Umsetzung. Eine Workflow-Engine kann Zustände und Zuweisungen zuverlässig ausführen. Sie kann aber nicht selbst festlegen, welche Rolle eine geschäftliche Ausnahme genehmigen darf.
Der Ausnahme-Steckbrief
Für regelmäßig erwartbare Abweichungen genügt ein knapper Steckbrief:
| Feld | Leitfrage |
|---|---|
| Bezeichnung | Welche Abweichung wird eindeutig beschrieben? |
| Erkennung | Welche Bedingung oder Beobachtung löst sie aus? |
| Sicherer Wartezustand | Was darf bis zur Entscheidung ausdrücklich nicht passieren? |
| Entscheidungsrolle | Wer darf verbindlich entscheiden? |
| Kriterien und Nachweise | Welche Informationen sind für die Entscheidung notwendig? |
| Zeit und Eskalation | Bis wann muss reagiert werden, und wer übernimmt danach? |
| Mögliche Ausgänge | genehmigen, korrigieren, ablehnen, abbrechen oder technisch wiederholen |
| Rückkehr in den Prozess | An welcher Stelle und mit welchem Status geht es weiter? |
| Kommunikation | Wer erhält welche verständliche Information? |
| Review | Wann wird geprüft, ob die Ausnahme weiterhin sinnvoll ist? |
Der sichere Wartezustand verdient besondere Aufmerksamkeit. Bei einer fehlenden Rechnungsfreigabe darf keine Zahlung ausgelöst werden. Bei einer unklaren Zugriffsberechtigung darf nicht vorsorglich das weitergehende Recht vergeben werden. Bei einer ausgefallenen Schnittstelle darf ein erneuter Lauf keine Doppelbuchung erzeugen.
Ein konstruiertes Beispiel: Bestellung außerhalb des Standardfalls
Das folgende Beispiel ist konstruiert.
Ein digitaler Beschaffungsprozess verarbeitet inländische Lieferanten und Bestellungen in Euro. Eine fachlich zulässige Bestellung bei einem neuen ausländischen Lieferanten trifft ein. Der Workflow findet weder den erwarteten Stammdatensatz noch die vorgesehene Währung und bleibt mit einem technischen Fehlerstatus stehen.
Weil keine Rolle für diese Ausnahme benannt ist, fragt der Einkauf per E-Mail bei IT und Buchhaltung nach. Eine Person trägt Daten manuell nach, eine andere startet den Vorgang erneut. Im Prozess ist später nicht mehr eindeutig erkennbar, wer die Zulässigkeit geprüft und warum der zweite Lauf keine Doppelbestellung erzeugt hat.
Ein gestalteter Ausnahmeweg würde den Vorgang unverändert parken, die fehlenden Prüfungen sichtbar machen, eine fachlich befugte Rolle zuweisen und den Besteller über den Status informieren. Nach Lieferanten- und Währungsprüfung würde derselbe Vorgang mit dokumentierter Entscheidung an einer definierten Stelle weiterlaufen.
Das Beispiel ist kein berichteter Kundenfall. Es zeigt, wie ein fachliches Ereignis als technischer Fehler erscheint, wenn der Prozess nur seinen Standardweg kennt.
Entscheidung und technische Bearbeitung trennen
Die Person, die einen Datensatz korrigieren kann, ist nicht automatisch befugt, die zugrunde liegende Ausnahme zu genehmigen. Umgekehrt kann eine Prozessverantwortliche entscheiden dürfen, ohne technische Schreibrechte im Zielsystem zu besitzen.
Diese Trennung verhindert, dass ein Administrator aus Zeitdruck eine fachliche Entscheidung trifft oder eine Führungskraft technische Kontrollen umgehen muss. Der Beitrag „Verantwortlichkeiten als Voraussetzung für skalierbaren IT-Betrieb“ unterscheidet Aufgabe, Rolle, Ergebnisverantwortung, Entscheidungsrecht und technische Berechtigung.
Für den Ausnahmeweg sollte daher ausdrücklich feststehen:
- wer die Abweichung fachlich bewertet,
- wer eine Ausnahme von Regel oder Richtlinie genehmigen darf,
- wer die technische Korrektur ausführt,
- wer den Vorgang anschließend freigibt,
- und wann ein Vier-Augen-Prinzip nötig ist.
Eine Personalunion kann in kleinen Organisationen vertretbar sein. Die Rollen müssen trotzdem gedanklich und im Protokoll getrennt bleiben, damit später nachvollziehbar ist, in welcher Eigenschaft entschieden und gehandelt wurde.
Nicht jede Ausnahme vorab modellieren
Vollständigkeit ist auch hier kein sinnvolles Ziel. Wer jeden theoretisch möglichen Sonderfall vor der ersten Automatisierung modellieren will, blockiert den Start und erzeugt Regeln für Situationen, die vielleicht nie eintreten.
Eine sinnvolle Staffelung ist:
- häufige und folgenreiche Ausnahmen ausdrücklich modellieren,
- seltene, aber riskante Ausnahmen mit sicherem Stopp und klarer Entscheidungsrolle absichern,
- seltene und folgenarme Ausnahmen über einen kontrollierten allgemeinen Klärungsweg bearbeiten,
- unbekannte technische Fehler in einen überwachten Fehlerzustand führen, statt sie still zu verwerfen.
Der allgemeine Klärungsweg ist kein Freibrief für Zuruf. Er braucht mindestens Owner, Wartezustand, Frist, nachvollziehbare Entscheidung und Abschluss. Aus seinem Protokoll lässt sich später erkennen, welche Ausnahmen häufig genug geworden sind, um einen eigenen Weg zu rechtfertigen.
Prozessaufnahme muss Nebenwege sichtbar machen
Der Artikel „Nicht den schlechten Prozess digitalisieren“ empfiehlt, vor der Werkzeugauswahl Zweck, Eingaben, Ergebnisse, Rollen, Regeln, Ausnahmen und Kennzahlen zu klären. Für Ausnahmefälle ist besonders wichtig, nicht nur die offizielle Arbeitsanweisung zu betrachten.
Die Methode Prozessmapping des DigitalService hilft, tatsächliche Schritte, Beteiligte und Abhängigkeiten gemeinsam sichtbar zu machen. In Workshops sollten deshalb Fragen gestellt werden wie:
- Wann schicken Mitarbeitende zusätzlich eine E-Mail?
- Für welche Fälle wird eine erfahrene Person persönlich angesprochen?
- Welche Vorgänge bleiben in „Warten“ liegen, ohne dass ein Termin existiert?
- Wo werden Daten außerhalb des führenden Systems korrigiert?
- Welche Ablehnungen werden durch eine neue Anfrage umgangen?
- Bei welchen Fällen kann niemand erklären, wer final entscheiden darf?
Auch das GOV.UK Service Manual empfiehlt, den vollständigen Weg einschließlich Übergängen, Sackgassen sowie Online- und Offline-Schritten zu betrachten. Genau in diesen Brüchen liegen häufig die späteren Ausnahmeprozesse.
Automatisierung darf keine Entscheidung erfinden
Ein System benötigt für jeden erkannten Zustand eine technische Reaktion. Daraus folgt nicht, dass es bei fachlicher Unklarheit selbst einen endgültigen Ausgang wählen sollte.
Gefährliche Ersatzentscheidungen sind beispielsweise:
- fehlende Freigabe als Zustimmung behandeln,
- bei unklarer Rolle das umfangreichste Berechtigungspaket vergeben,
- nicht erreichbare Prüfung nach mehreren Versuchen überspringen,
- widersprüchliche Daten aus einer beliebigen Quelle übernehmen,
- oder einen Fehlerstatus schließen, ohne den Geschäftsvorgang zu klären.
Der sichere Standard hängt vom Risiko ab. Häufig bedeutet er: nicht weiterwirken, Zustand erhalten, zuständige Rolle informieren und eine Frist überwachen. Bei zeitkritischen Prozessen kann zusätzlich ein definierter Notfallweg notwendig sein. Dieser Weg ist dann selbst ein verantworteter Prozess, keine spontane Umgehung.
Bei Low-Code-Plattformen wird diese Frage besonders schnell relevant. Ein Fachbereich kann Standardwege zügig digitalisieren, während Ausnahmeentscheidungen, technische Konten und Betriebsverantwortung unklar bleiben. Low-Code-Governance muss deshalb nicht nur Anwendungen registrieren, sondern auch Wirkung, Owner und sichere Betriebsgrenzen klären.
Das Ausnahmeprotokoll ist ein Verbesserungsinstrument
Jede bearbeitete Ausnahme sollte so knapp wie möglich, aber so aussagekräftig wie nötig protokolliert werden:
- betroffener Prozess und Vorgang,
- Ausnahmeart und Auslöser,
- Beginn und Ende des Wartezustands,
- zuständige Entscheidungsrolle,
- getroffene Entscheidung und Begründung,
- Rückkehr- oder Abschlussweg,
- sowie möglicher Verbesserungsbedarf.
Nicht jede Entscheidung gehört mit sensiblen Details in ein allgemein sichtbares Log. Datenschutz, Vertraulichkeit und Aufbewahrung müssen zum Inhalt passen. Für die Prozesssteuerung reichen häufig kategorisierte Gründe und Verweise auf geschützt abgelegte Nachweise.
Das Protokoll verhindert, dass jede Ausnahme als einmaliger Sonderfall behandelt wird. Wiederholen sich dieselben Ursachen, bestehen mehrere Möglichkeiten: Eingabemaske verbessern, Regel präzisieren, Stammdaten korrigieren, Standardweg erweitern oder die Abweichung bewusst weiterhin manuell halten.
Die richtigen Kennzahlen betrachten
Eine hohe Automatisierungsquote kann gut aussehen, während schwierige Vorgänge in Nebenkanälen verschwinden. Auch eine kurze Bearbeitungszeit des Standardwegs sagt wenig über die gesamte Leistung aus.
Nützlicher sind:
- Anteil der Vorgänge, die einen Ausnahmeweg benötigen,
- Wartezeit bis zur fachlichen Entscheidung,
- Häufigkeit derselben Ausnahmeursache,
- Anteil der Fälle, die nach der Entscheidung sauber in den Prozess zurückkehren,
- Zahl der Doppelbearbeitungen oder Neuanlagen wegen gescheiterter Rückführung,
- und Zahl der Ausnahmen ohne eindeutig dokumentierte Entscheidungsrolle.
Diese Kennzahlen sollen nicht jede Abweichung bestrafen. Ein Ausnahmeweg kann Ausdruck einer sinnvollen Kontrolle sein. Entscheidend ist, ob er sichtbar, beherrscht und lernfähig ist.
Der ISO-Prozessansatz verbindet Prozesse mit beabsichtigten Ergebnissen, Eingaben, Wechselwirkungen, Verantwortungen, Risiken, Leistungsindikatoren und Verbesserung. Die Quelle schreibt keine konkrete Ausnahmequote vor. Sie stützt die breitere Einordnung, dass ein Prozess nicht allein nach der Geschwindigkeit seines Idealwegs bewertet werden sollte.
Der kleinste sinnvolle nächste Schritt
Nehmen Sie einen bereits digitalisierten Prozess und sammeln Sie die Fälle, bei denen Mitarbeitende den vorgesehenen Weg verlassen. Wählen Sie eine häufige oder folgenreiche Abweichung und erstellen Sie den Ausnahme-Steckbrief.
Prüfen Sie anschließend nicht nur, ob das Werkzeug den Zustand technisch abbilden kann. Prüfen Sie, ob eine befugte Rolle rechtzeitig entscheiden kann, der Vorgang bis dahin sicher bleibt und danach ohne Neuanlage oder verdeckte Handarbeit weiterläuft.
Der Standardweg zeigt, wie ein Prozess im Idealfall funktioniert. Der Ausnahmeweg zeigt, ob die Organisation auch dann handlungsfähig bleibt, wenn die Wirklichkeit vom Ideal abweicht.
Quellen
- Business Process Model and Notation 2.0.2 – Object Management Group
- Business Process Model and Notation – Object Management Group
- The process approach in ISO 9001:2015 – International Organization for Standardization
- Prozessmapping – DigitalService des Bundes
- Map and understand a user's whole problem – UK Government Digital Service
