Welche Prozesse sollte man nicht automatisieren?

Das Wichtigste in Kürze:

• Automatisiere keine Prozesse, die sich schneller ändern, als du die Automatisierung pflegen kannst.
• Entscheidungen mit Ermessen oder Wirkung auf Personen bleiben bei Menschen, Artikel 14 EU AI Act setzt hier Leitplanken.
• Seltene, teure Sonderfälle brauchen eine aktive Weiterleitung an Menschen statt Stichproben.
• Erst vereinfachen, dokumentieren, stabilisieren, dann automatisieren, mit vorher festgelegten Stop-Kriterien.

Das Problem und wer es betrifft

Automatisierung hat einen guten Ruf, zu Recht, wenn sie auf den richtigen Prozess trifft, aber das Problem beginnt, wenn von 2 zentralen Fragen nur eine gestellt wird: „Können wir das automatisieren?“ Die zweite lautet: „Sollten wir das hier automatisieren?“

Ein instabiler, schlecht dokumentierter oder stark fallabhängiger Prozess wird durch Automatisierung nicht besser, sondern nur schneller ausgeführt, inklusive seiner Fehler, seiner Ausnahmen und seiner unklaren Zuständigkeiten. Das Ergebnis ist dann kein effizienter Betrieb, sondern ein automatisiertes Durcheinander. Es versteht niemand mehr im Detail, weil es niemand mehr manuell durchläuft.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU vor einer Automatisierungsentscheidung. Er hilft auch, eine bestehende Automatisierung zu prüfen. Er ist bewusst kein Artikel über das Finden guter Use Cases, dazu gibt es eigene Beiträge in diesem Cluster. Hier geht es um die Gegenrichtung: Woran erkennst du, dass ein Prozess noch nicht automatisiert werden sollte? Und was tust du stattdessen?

In meiner Beratungspraxis ist das einer der teuersten blinden Flecken. Unternehmen bewerten Kandidaten fast nur nach dem sichtbaren Nutzen: Zeitersparnis, weniger Klicks, schnellere Bearbeitung. Viel zu selten fragen sie, was im Fehlerfall passiert und wie oft er eintritt. Das ist kein Plädoyer gegen Automatisierung. Automatisierte Prozesse laufen zuverlässiger, schneller und günstiger als manuelle, solange die Voraussetzungen stimmen. Die Frage ist nicht ob, sondern wann noch nicht.

Begriffe kurz geklärt

4 Begriffe brauchst du für diesen Artikel.

Prozessstabilität beschreibt, wie oft und wie stark sich Ablauf, Regeln oder Systeme eines Prozesses ändern. Ein stabiler Prozess läuft über Monate im Wesentlichen gleich. Ein instabiler ändert sich mit jedem neuen Sonderfall, jeder Systemumstellung oder jeder neuen Vorschrift.

Regelbasiertheit meint, ob sich ein Prozess vollständig als Wenn-Dann-Logik beschreiben lässt, oder ob er an Stellen echtes Abwägen erfordert, das über feste Regeln hinausgeht.

Sonderfall ist hier jede Ausprägung, die von der Hauptvariante abweicht: von der fehlenden Rechnungsnummer bis zum Kulanzfall. Sonderfälle sind kein Hindernis. Problematisch wird es, wenn sie selten, aber teuer sind und in der Automatisierung nicht vorgesehen wurden.

Automatisierungswürdigkeit ist keine binäre Eigenschaft, sondern eine Abwägung aus Stabilität, Regelbasiertheit, Häufigkeit, Datenqualität und den Folgen im Fehlerfall. Genau diese 5 Dimensionen nennt auch das Fraunhofer IAO als zentrale Auswahlkriterien: Stabilität, Häufigkeit, Prozessqualität, Datenqualität und Regelbasiertheit.

Wichtig ist die Abgrenzung zu einem verwandten Thema. Bei der Frage, welche Prozesse Potenzial haben, geht es meist um Nutzen und Machbarkeit. Dieser Artikel dreht die Perspektive um und fragt nach Ausschlusskriterien. Also nach Eigenschaften, die trotz theoretischem Potenzial gegen eine Automatisierung sprechen, zumindest im aktuellen Zustand.

Welche Prozesse sind zu instabil?

Ein Prozess ist zu instabil, wenn er sich schneller ändert, als die Automatisierung gepflegt werden kann. 3 typische Anzeichen dafür: mehrfache Umstellung in den letzten 6 bis 12 Monaten, keine einheitliche, aktuelle Dokumentation, oder mehrere Personen beschreiben denselben Ablauf unterschiedlich.

Der Grund liegt im Wesen der Automatisierung selbst. Ob Workflow, RPA-Bot oder KI-Agent: Eine Automatisierung bildet immer einen Zustand ab, keinen laufenden Wandel. Werkzeuge wie Microsofts Process-Mining-Funktion setzen genau hier an. Sie werten reale Ereignisdaten aus bestehenden Systemen aus und zeigen, wie ein Prozess tatsächlich abläuft, nicht wie er auf dem Papier aussehen soll.

Solche Analysen zeigen häufig: Ein Prozess hat in der Praxis deutlich mehr Varianten als gedacht. Genau diese Varianz ist der Feind der Automatisierung. Jede Ausnahme, die sie nicht kennt, landet als Fehler im System oder als manueller Sonderfall auf einem Schreibtisch. Meist merkt niemand, dass die Zahl dieser Fälle wächst.

Die praktische Folge: Vor der Automatisierung eines instabilen Prozesses braucht es eine Phase der Stabilisierung (siehe Abschnitt zum Vereinfachen). Oder eine Form, die mit Varianz umgehen kann, etwa mit fester menschlicher Prüfung an den bekannten Abweichungsstellen. Eine vollautomatische Lösung für einen Prozess, der sich monatlich ändert, ist in meiner Erfahrung fast immer die teuerste Option. Der Pflegeaufwand übersteigt schnell den Aufwand, den Prozess weiter von Hand zu betreiben.

Wann ist menschliches Urteil zentral?

Menschliches Urteil ist zentral, wo eine Entscheidung mehr braucht als feste Regeln auf klare Daten. Nämlich Abwägung, Kontextwissen oder Verantwortung gegenüber einem Menschen auf der anderen Seite. 3 Kategorien kommen in der Praxis am häufigsten vor.

• Kulanz- und Ausnahmeentscheidungen: Ob eine Reklamation trotz abgelaufener Frist bearbeitet wird oder ein Kunde einen Sonderrabatt bekommt, hängt von Kundenbeziehung, Historie und Ermessen ab. Diese Faktoren sind selten vollständig in Daten abgebildet.
• Entscheidungen mit rechtlicher oder personeller Tragweite: Bewerbungsvorauswahl, Leistungsbeurteilung, Kündigungsvorbereitung. Wo eine automatisierte Entscheidung reale Folgen für eine Person hat, braucht es zwingend eine menschliche Instanz, die prüft und verantwortet.
• Fälle mit unvollständiger oder widersprüchlicher Information: Reicht die Datenlage für eine sichere automatische Entscheidung nicht aus, ist die bewusste Weiterleitung an einen Menschen die bessere Wahl.

Für die zweite Kategorie gibt es inzwischen eine rechtliche Leitplanke. Der EU AI Act verlangt in Artikel 14 für Hochrisiko-KI-Systeme eine wirksame menschliche Aufsicht. Die beauftragten Personen müssen laut Verordnung die Fähigkeiten und Grenzen des Systems verstehen und Auffälligkeiten erkennen. Sie müssen sich der Tendenz zu Automatisierungsbias bewusst sein und Ausgaben korrekt deuten. Und sie brauchen die Möglichkeit, eine Ausgabe zu ignorieren, zu überschreiben oder das System nicht zu nutzen.

Formal gilt das nur für als hochriskant eingestufte Systeme, das Prinzip dahinter ist aber für alle automatisierten Entscheidungen eine sinnvolle Richtschnur. Wenn Fehler eine Person spürbar treffen können, gehört ein Mensch mit echter Eingriffsmöglichkeit in den Prozess, nicht nur als Feigenblatt am Ende. Eine rechtlich verbindliche Einordnung im Einzelfall ersetzt das nicht. Dafür braucht es je nach Fall Rechtsberatung oder den Datenschutzbeauftragten (Stand Juli 2026).

Welche Risiken haben seltene Sonderfälle?

Seltene Sonderfälle sind aus 2 Gründen gefährlicher, als ihre Häufigkeit vermuten lässt. Erstens werden sie schlechter getestet: Wer eine Automatisierung baut, testet naheliegenderweise die häufigen Fälle gründlich. Der Fall, der einmal im Quartal auftritt, fällt bei der Abnahme leicht durchs Raster.

Zweitens geht Seltenheit oft mit Komplexität einher, und damit mit höherem Schaden: Der Standardvorgang ist meist auch der einfachste, der seltene Sonderfall dagegen oft der, bei dem viel zusammenkommt.

Behandelt eine Automatisierung einen solchen Fall falsch, merkt das oft niemand sofort, weil er selten genug auftritt, dass eine Stichprobe ihn leicht übersieht. Das eigentliche Risiko ist also die Kombination aus 3 Faktoren: geringe Häufigkeit, hohes Schadenspotenzial, geringe Entdeckungswahrscheinlichkeit.

Die praktische Folge: Ein Prozess mit vielen seltenen, aber folgenreichen Sonderfällen sollte nicht vollautomatisch laufen. Er braucht eine Erkennungslogik, die diese Fälle aktiv an einen Menschen weiterleitet, statt sie durchlaufen zu lassen. Die Risikomatrix im Umsetzungsteil zeigt, wie du solche Fälle systematisch einordnest.

Wann sollte man zuerst vereinfachen?

Zuerst vereinfachen solltest du immer dann, wenn die Komplexität des Prozesses selbst das Problem ist, nicht die fehlende Automatisierung. 3 typische Warnsignale: mehr Sonderregeln, als eine Person auswendig kennen kann, mehrere Abteilungen an unklar abgegrenzten Stellen, oder derselbe Vorgang läuft je nach Bearbeiter:in unterschiedlich ab.

In solchen Fällen automatisierst du nicht den Prozess, sondern seine Unordnung, und machst sie damit schneller, verbindlicher und schwerer rückgängig zu machen. Eine Automatisierung, die zehn Sonderregeln abbildet, wird bei der elften nicht flexibler, sondern brüchiger.

Vereinfachung heißt konkret: redundante Schritte streichen, Zuständigkeiten klären, Sonderregeln reduzieren und den Rest dokumentieren, idealerweise über eine echte Prozessanalyse, nicht nur ein Gespräch mit der Prozessverantwortlichen. Erst wenn der vereinfachte Prozess über einen längeren Zeitraum stabil läuft, lohnt sich der Aufwand einer Automatisierung. Andernfalls automatisierst du zweimal: erst die unnötig komplizierte Version, nach der fälligen Vereinfachung dann noch einmal die eigentliche.

Welche Stop-Kriterien gelten?

Genauso wichtig wie der Start ist die Entscheidung, wann du eine Automatisierung stoppst, pausierst oder zurückbaust. 4 Kriterien haben sich in meiner Praxis bewährt.

1. Die Fehlerquote liegt über der Schwelle: Ohne eine im Voraus definierte Grenze wird jede Fehlerhäufung im Nachhinein diskutiert und meist verharmlost. Die Schwelle gehört vor den Betriebsstart festgelegt.
2. Der Prozess ändert sich grundlegend: Neues System, neue Vorschrift, neue Organisationsstruktur. Ändert sich die Basis, muss die Automatisierung neu geprüft werden statt einfach weiterzulaufen.
3. Die Datenqualität sinkt messbar: Fehlende, veraltete oder inkonsistente Eingabedaten sind eine der häufigsten Ursachen für schleichend schlechtere Ergebnisse, die oft erst nach entstandenem Schaden auffallen.
4. Es gibt keine benannte Betriebsverantwortung mehr: Eine Automatisierung ohne Owner verfällt unbemerkt, denn niemand prüft Stichproben, reagiert auf Warnsignale oder entscheidet über Anpassungen.

Diese 4 Kriterien gehören nicht in einen Ordner, sondern in die Betriebsdokumentation der Automatisierung selbst, mit klaren Schwellenwerten und einer benannten Person, die im Ernstfall entscheidet.

Umsetzung: die Risikomatrix

Die folgende Matrix fasst die Dimensionen dieses Artikels zusammen und ordnet ihnen Gegenmaßnahmen zu. Sie ersetzt keine Einzelfallprüfung. Aber sie gibt eine schnelle erste Orientierung über 6 Risikozeilen, bevor du Zeit in eine Automatisierung investierst.

• Prozessstabilität (Warnsignal: mehrfache Änderungen in den letzten 6-12 Monaten, keine einheitliche Dokumentation): erst stabilisieren und dokumentieren, alternativ mit Prüfschritt an bekannten Änderungsstellen starten.

• Regelbasiertheit (Warnsignal: Entscheidung erfordert Abwägung statt fester Kriterien): Human-in-the-Loop an genau dieser Entscheidungsstelle, keine Vollautomatisierung.

• Sonderfall-Risiko (Warnsignal: seltene Fälle mit hohem Schadenspotenzial und geringer Entdeckungswahrscheinlichkeit): aktive Erkennung und Weiterleitung an Menschen statt stichprobenartiger Nachkontrolle.

• Personenbezogene Tragweite (Warnsignal: Entscheidung wirkt direkt auf eine Person, etwa bei Bewerbung, Leistung, Vertrag): wirksame menschliche Aufsicht mit echter Eingriffsmöglichkeit vor jeder wirksamen Entscheidung.

• Datenqualität (Warnsignal: Eingabedaten unvollständig, veraltet oder in mehreren Systemen widersprüchlich): Datenbereinigung vor der Automatisierung und laufende Qualitätsstichproben im Betrieb.

• Betriebsverantwortung (Warnsignal: kein benannter Owner nach dem Rollout): vor dem Start eine Person mit Zeitbudget für Monitoring und Stop-Entscheidung benennen.

Eigene Risikomatrix Philogic Labs, abgeleitet aus den Auswahlkriterien der Fraunhofer-IAO-Praxis und den Anforderungen an menschliche Aufsicht nach Artikel 14 EU AI Act.

In der Praxis nutze ich diese Matrix als ersten Filter im Prozess-Audit. Jeder Kandidat wird gegen die 6 Zeilen gehalten. 2 oder mehr Warnsignale in den oberen 4 Zeilen sind für mich ein klares Signal. Dann wird der Prozess vorerst nicht automatisiert, sondern zuerst vereinfacht oder mit engem menschlichem Prüfschritt gestartet.

Was kostet es, den falschen Prozess zu automatisieren?

Eine seriöse Zahl lässt sich hier nicht nennen. Die Kosten hängen zu stark von Prozess, Branche und Fehlerfolgen ab. Die Kostenstruktur eines falsch gewählten Projekts folgt aber einem erkennbaren Muster mit 3 Blöcken.

• Wartungskosten, die den Nutzen übersteigen: Ein instabiler Prozess zwingt dazu, die Automatisierung immer wieder nachzuziehen, denn jede Änderung erfordert angepasste Regeln, Schnittstellen oder Prompts. Bei hoher Änderungsfrequenz kann der laufende Pflegeaufwand den Effizienzgewinn komplett aufzehren.
• Fehlerkosten aus übersehenen Sonderfällen: Diese Kosten entstehen unregelmäßig und werden in Wirtschaftlichkeitsrechnungen häufig unterschätzt oder ganz weggelassen. Ein einzelner grober Fehler kann den kalkulierten Gewinn mehrerer automatisierter Standardfälle übersteigen.
• Vertrauenskosten: Schwerer zu beziffern, aber real. Entscheidet eine Automatisierung wiederholt sichtbar falsch, verlieren Mitarbeitende und Kund:innen das Vertrauen in das Thema insgesamt.

Gerade die Vertrauenskosten wirken lange nach, ein zweites Automatisierungsprojekt ist danach deutlich schwerer durchzusetzen, unabhängig davon, wie gut es konzipiert ist.

Für die Wirtschaftlichkeitsrechnung heißt das: Rechne nicht nur den Zeitgewinn im Normalfall. Rechne auch, was ein übersehener Sonderfall im schlechtesten realistischen Szenario kostet, multipliziert mit einer vorsichtigen Schätzung seiner Häufigkeit. Erst wenn der erwartete Nutzen diese Fehlerkosten deutlich übersteigt, lohnt sich der nächste Schritt.

Risiken und Grenzen

Ein paar Einschränkungen zu diesem Artikel selbst. Die Matrix ist ein Orientierungsrahmen, keine Garantie. Ob ein konkreter Prozess in deinem Unternehmen automatisierbar ist, hängt von Details ab: etwa der genauen Fehlerkostenstruktur oder der tatsächlichen Systemlandschaft. Auch die Grenze zwischen „instabil“ und „ausreichend stabil“ ist keine feste Zahl, sondern eine Abwägung. Im Zweifel triff sie konservativ: lieber einen Prozess zu spät automatisieren, als eine schlechte Automatisierung zurückbauen zu müssen.

Wichtig ist außerdem die Abgrenzung: Dieser Artikel sagt nicht, dass KI oder Automatisierung grundsätzlich riskant sind. Er sagt, dass die Eignung des Prozesses vor der Wahl des Werkzeugs geprüft werden muss. Die gleiche Reihenfolge gilt für die Einführung von KI im Unternehmen insgesamt. Rechtliche Fragen rund um automatisierte Entscheidungen sind hier bewusst nur eingeordnet, nicht abschließend geklärt (Stand Juli 2026). Im Einzelfall braucht es Rechtsberatung oder eine Datenschutz-Folgenabschätzung.

Bist du unsicher, ob ein Prozess bei euch automatisierungsreif ist oder zuerst vereinfacht werden sollte? Das klärt ein kurzes Erstgespräch meist schneller, als es sich anfühlt. Oft reicht ein Blick auf die letzten 3 bis 5 Sonderfälle, um die Antwort zu sehen.

Checkliste: Automatisierungsreife eines Prozesses prüfen

Diese 9 Punkte sollten erfüllt sein, bevor du startest.

1. Der Prozess lief in den letzten 6 Monaten ohne größere strukturelle Änderung.

2. Es gibt eine einheitliche, aktuelle Dokumentation, die alle Beteiligten gleich beschreiben würden.

3. Der Prozess lässt sich überwiegend als klare Regeln formulieren, Ausnahmen sind bekannt und gezählt, nicht diffus.

4. Entscheidungen mit Ermessensspielraum oder Wirkung auf Personen sind identifiziert und bleiben bei Menschen.

5. Seltene Sonderfälle sind bekannt, ihre Häufigkeit grob geschätzt und ihr Schadenspotenzial bewertet.

6. Die Eingabedaten sind vollständig, aktuell und konsistent verfügbar.

7. Es gibt vorher festgelegte Stop-Kriterien mit Schwellenwerten, nicht erst im Fehlerfall.

8. Eine Person ist für den laufenden Betrieb und die Stop-Entscheidung benannt, mit realem Zeitbudget.

9. Bei komplexen, unklaren Prozessen steht Vereinfachung nachweislich vor Automatisierung, nicht parallel dazu.

Weitere Grundlagen zur Bewertung von Automatisierungspotenzial und zur strukturierten Umsetzung findest du in der Kategorie Prozessautomatisierung.