Welche Prozesse sollte man nicht automatisieren?

Das Problem und wer es betrifft

Automatisierung hat einen guten Ruf – zu Recht, wenn sie auf den richtigen Prozess trifft. Das Problem entsteht, wenn die Frage „Können wir das automatisieren?” wichtiger wird als die Frage „Sollten wir das hier automatisieren?”. Ein instabiler, schlecht dokumentierter oder stark fallabhängiger Prozess wird durch Automatisierung nicht besser. Er wird nur schneller ausgeführt – inklusive seiner Fehler, seiner Ausnahmen und seiner unklaren Zuständigkeiten. Das Ergebnis ist dann kein effizienterer Betrieb, sondern ein automatisiertes Durcheinander, das niemand mehr im Detail versteht, weil es niemand mehr manuell durchläuft.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die vor einer Automatisierungsentscheidung stehen oder eine bestehende Automatisierung überprüfen. Er ist bewusst kein „So findest du gute Use Cases”-Artikel – 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 eine der teuersten blinden Flecken, die ich sehe: Unternehmen bewerten Automatisierungskandidaten fast ausschließlich nach dem sichtbaren Nutzen – Zeitersparnis, weniger manuelle Klicks, schnellere Bearbeitung – und viel zu selten nach der Gegenfrage, was im Fehlerfall passiert und wie oft dieser Fehlerfall 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 in diesem Artikel ist nicht ob, sondern wann noch nicht.

Begriffe kurz geklärt

Prozessstabilität beschreibt, wie oft und wie stark sich Ablauf, Regeln oder beteiligte 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 eines Prozesses, die von der Hauptvariante abweicht – von der fehlenden Rechnungsnummer bis zum Kulanzfall. Sonderfälle sind nicht per se ein Automatisierungshindernis; problematisch wird es, wenn sie selten, aber teuer sind und in der Automatisierung nicht vorgesehen wurden.

Automatisierungswürdigkeit ist keine binäre Eigenschaft eines Prozesses, sondern das Ergebnis einer Abwägung aus Stabilität, Regelbasiertheit, Häufigkeit, Datenqualität und Folgen im Fehlerfall. Genau diese fünf Dimensionen nennt auch das Fraunhofer IAO als zentrale Auswahlkriterien für Automatisierungsprojekte: Stabilität, Häufigkeit, Prozessqualität, Datenqualität und Regelbasiertheit.

Wichtig ist die Abgrenzung zu einem verwandten, aber anderen Thema: Bei der Frage, welche Prozesse überhaupt Automatisierungspotenzial haben, geht es meist um Nutzen und Machbarkeit. Dieser Artikel dreht die Perspektive um und fragt nach den Ausschlusskriterien – den Eigenschaften, die trotz vorhandenem theoretischem Potenzial gegen eine Automatisierung sprechen, zumindest im aktuellen Zustand des Prozesses.

Welche Prozesse sind zu instabil?

Ein Prozess ist zu instabil für Automatisierung, wenn er sich schneller ändert, als die Automatisierung gepflegt werden kann. Typische Anzeichen: Der Prozess wurde in den letzten sechs bis zwölf Monaten mehrfach umgestellt, es gibt keine einheitliche, aktuelle Dokumentation, oder mehrere Personen beschreiben denselben Ablauf unterschiedlich, wenn man sie einzeln danach fragt.

Der Grund, warum das ein echtes Problem ist, liegt im Wesen der Automatisierung selbst: Eine Automatisierung – ob als klassischer Workflow, RPA-Bot oder KI-gestützter Agent – bildet immer einen Zustand ab, keinen laufenden Prozess. Prozessanalyse-Werkzeuge wie Microsofts Process-Mining-Funktion setzen deshalb genau hier an: Sie werten reale Ereignisdaten aus bestehenden Systemen aus, um sichtbar zu machen, wie ein Prozess tatsächlich abläuft – nicht wie er auf dem Papier aussehen soll. Solche Analysen zeigen häufig, dass ein Prozess in der Praxis deutlich mehr Varianten hat als angenommen. Genau diese Varianz ist der Feind der Automatisierung: Jede zusätzliche Ausnahme, die die Automatisierung nicht kennt, landet entweder als Fehler im System oder als manueller Sonderfall auf einem Schreibtisch – meist ohne dass jemand merkt, dass die Zahl dieser Fälle wächst.

Praktische Konsequenz: Bevor du einen instabilen Prozess automatisierst, brauchst du entweder eine Phase der Stabilisierung (siehe Abschnitt „Wann sollte man zuerst vereinfachen?”) oder eine Automatisierungsform, die mit Varianz umgehen kann – etwa ein Vorgehen mit obligatorischer menschlicher Prüfung an den Stellen, an denen der Prozess erfahrungsgemäß abweicht. 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 manuell zu betreiben.

Wann ist menschliches Urteil zentral?

Menschliches Urteil ist dort zentral, wo eine Entscheidung mehr braucht als das Anwenden fester Regeln auf klare Eingabedaten – nämlich Abwägung, Kontextwissen oder Verantwortung gegenüber einem Menschen auf der anderen Seite. Drei Kategorien kommen in der Praxis am häufigsten vor:

• Kulanz- und Ausnahmeentscheidungen. Ob eine Reklamation trotz abgelaufener Frist bearbeitet wird, ob ein Kunde einen Sonderrabatt bekommt – solche Entscheidungen hängen von Faktoren ab, die selten vollständig in Daten abgebildet sind: Kundenbeziehung, Historie, Ermessen.
• Entscheidungen mit rechtlicher oder personeller Tragweite. Bewerbungsvorauswahl, Leistungsbeurteilung, Kündigungsvorbereitung – überall dort, wo eine automatisierte Entscheidung reale Konsequenzen 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. Wenn die Datenlage für eine sichere automatische Entscheidung nicht ausreicht, ist eine erzwungene automatische Entscheidung schlechter als eine bewusste Weiterleitung an einen Menschen.

Für die zweite Kategorie gibt es inzwischen auch eine rechtliche Leitplanke: Der EU AI Act verlangt in Artikel 14 für Hochrisiko-KI-Systeme ausdrücklich eine wirksame menschliche Aufsicht. Die damit beauftragten Personen müssen laut der Verordnung die Fähigkeiten und Grenzen des Systems verstehen, Auffälligkeiten erkennen, sich der Tendenz zu Automatisierungsbias bewusst sein, Ausgaben korrekt interpretieren und die Möglichkeit haben, eine Systemausgabe zu ignorieren, zu überschreiben oder das System nicht zu nutzen. Das gilt formal nur für als hochriskant eingestufte Systeme – aber das Prinzip dahinter ist auch für alle anderen automatisierten Entscheidungsprozesse 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 formal als Feigenblatt am Ende. Rechtlich verbindliche Einordnung im Einzelfall ersetzt das nicht – dafür braucht es je nach Anwendungsfall Rechtsberatung oder den Datenschutzbeauftragten (Stand Juli 2026).

Welche Risiken haben seltene Sonderfälle?

Seltene Sonderfälle sind aus zwei Gründen gefährlicher, als ihre Häufigkeit vermuten lässt. Erstens werden sie in der Regel schlechter getestet: Wer eine Automatisierung baut und prüft, 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 korreliert Seltenheit in der Praxis oft mit Komplexität und damit mit höherem Schadenspotenzial: Der Standardvorgang ist meist auch der einfachste; der seltene Sonderfall ist häufig genau der, bei dem viel zusammenkommt – eine ungewöhnliche Kombination aus Kundendaten, Vertragskonstellation und Fristen.

Wenn eine Automatisierung einen solchen Fall falsch behandelt, merkt das oft niemand sofort – denn er tritt selten genug auf, dass eine stichprobenartige Prüfung ihn leicht übersieht. Das eigentliche Risiko ist also nicht der Einzelfall, sondern die Kombination aus geringer Auftrittshäufigkeit, hohem Schadenspotenzial und geringer Entdeckungswahrscheinlichkeit.

Die praktische Konsequenz: Ein Prozess mit vielen seltenen, aber folgenreichen Sonderfällen sollte nicht vollautomatisch laufen, sondern mit einer 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 eines Prozesses selbst das eigentliche Problem ist – nicht die fehlende Automatisierung. Typische Warnsignale: Es gibt mehr Sonderregeln als eine Person auswendig kennen kann, mehrere Abteilungen sind an unklar abgegrenzten Stellen beteiligt, oder derselbe Vorgang läuft je nach Bearbeiter:in spürbar unterschiedlich ab.

In solchen Fällen automatisiert man mit hoher Wahrscheinlichkeit nicht den Prozess, sondern seine Unordnung – und macht sie damit schneller, verbindlicher und schwerer wieder rückgängig zu machen. Eine Automatisierung, die zehn Sonderregeln abbildet, wird bei der elften Regel nicht flexibler, sondern brüchiger. Vereinfachung heißt hier konkret: Redundante Schritte streichen, Zuständigkeiten klären, Sonderregeln auf ein Minimum reduzieren und den verbleibenden Prozess sauber dokumentieren – idealerweise durch echte Prozessanalyse an den tatsächlichen Daten, nicht nur durch ein Gespräch mit der Prozessverantwortlichen. Erst wenn dieser vereinfachte Prozess über einen längeren Zeitraum stabil läuft, lohnt sich der Aufwand einer Automatisierung. Andernfalls automatisierst du zweimal: einmal die unnötig komplizierte Version, dann – nach der eigentlich fälligen Vereinfachung – noch einmal die eigentliche.

Welche Stop-Kriterien gelten?

Genauso wichtig wie die Entscheidung, eine Automatisierung zu starten, ist die Entscheidung, wann du sie stoppst, pausierst oder zurückbaust. Vier Kriterien haben sich in meiner Praxis bewährt:

1. Fehlerquote überschreitet eine vorher festgelegte Schwelle. Ohne eine im Voraus definierte Grenze wird jede Fehlerhäufung im Nachhinein diskutiert und meist verharmlost. Die Schwelle gehört vor den Start des Betriebs festgelegt.
2. Der zugrunde liegende Prozess ändert sich grundlegend. Neues System, neue Vorschrift, neue Organisationsstruktur – wenn sich die Basis ändert, muss die Automatisierung neu geprüft werden, nicht einfach weiterlaufen.
3. Datenqualität verschlechtert sich messbar. Fehlende, veraltete oder inkonsistente Eingabedaten sind eine der häufigsten Ursachen für schleichend schlechter werdende Automatisierungsergebnisse – und werden oft erst bemerkt, wenn schon Schaden entstanden ist.
4. Es gibt keine benannte Betriebsverantwortung mehr. Eine Automatisierung ohne Owner verfällt unbemerkt: Niemand prüft Stichproben, niemand reagiert auf Warnsignale, niemand entscheidet über Anpassungen.

Diese vier 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 fünf Dimensionen aus diesem Artikel zusammen und ordnet ihnen konkrete Gegenmaßnahmen zu. Sie ersetzt keine Einzelfallprüfung, gibt aber eine schnelle erste Orientierung, bevor du Zeit in eine Automatisierung investierst.

Risikodimension	Warnsignal	Gegenmaßnahme
Prozessstabilität	Mehrfache Änderungen in den letzten 6–12 Monaten, keine einheitliche Dokumentation	Erst stabilisieren und dokumentieren, dann automatisieren; alternativ mit Prüfschritt an bekannten Änderungsstellen starten
Regelbasiertheit	Entscheidung erfordert Abwägung statt fester Kriterien	Human-in-the-Loop an genau dieser Entscheidungsstelle, nicht Vollautomatisierung
Sonderfall-Risiko	Seltene Fälle mit hohem Schadenspotenzial, geringe Entdeckungswahrscheinlichkeit	Aktive Erkennung und Weiterleitung an Menschen statt stichprobenartiger Nachkontrolle
Personenbezogene Tragweite	Entscheidung wirkt sich direkt auf eine Person aus (Bewerbung, Leistung, Vertrag)	Wirksame menschliche Aufsicht mit echter Eingriffsmöglichkeit vor jeder wirksamen Entscheidung
Datenqualität	Eingabedaten unvollständig, veraltet oder in mehreren Systemen widersprüchlich	Datenbereinigung vor Automatisierung; laufende Qualitätsstichproben im Betrieb
Betriebsverantwortung	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 in einem Prozess-Audit: Jeder Kandidat wird gegen die sechs Zeilen gehalten. Zwei oder mehr Warnsignale in den oberen vier Zeilen sind für mich ein klares Signal, den Prozess vorerst nicht zu automatisieren, sondern zunächst zu vereinfachen oder mit engem menschlichem Prüfschritt zu starten.

Was kostet es, den falschen Prozess zu automatisieren?

Eine seriöse Zahl lässt sich hier nicht angeben – die Kosten hängen zu stark von Prozess, Branche und Fehlerfolgen ab. Aber die Kostenstruktur eines falsch gewählten Automatisierungsprojekts folgt einem erkennbaren Muster, das sich in drei Blöcken beschreiben lässt.

• Wartungskosten, die den Nutzen übersteigen. Ein instabiler Prozess zwingt dazu, die Automatisierung immer wieder nachzuziehen – jede Änderung am zugrunde liegenden Ablauf erfordert eine Anpassung der Regeln, Schnittstellen oder Prompts. Bei hoher Änderungsfrequenz kann dieser laufende Pflegeaufwand den ursprünglichen Effizienzgewinn komplett aufzehren.
• Fehlerkosten aus übersehenen Sonderfällen. Diese Kosten entstehen unregelmäßig und werden deshalb in Wirtschaftlichkeitsrechnungen häufig unterschätzt oder ganz weggelassen. Ein einzelner grober Fehler in einem folgenreichen Sonderfall kann den kalkulierten Effizienzgewinn mehrerer automatisierter Standardfälle übersteigen.
• Vertrauenskosten. Schwerer zu beziffern, aber real: Wenn eine Automatisierung wiederholt sichtbar falsch entscheidet, verlieren Mitarbeitende und Kund:innen das Vertrauen – nicht nur in diese eine Automatisierung, sondern in das Thema insgesamt. Ein zweites Automatisierungsprojekt wird danach deutlich schwerer durchzusetzen, unabhängig davon, wie gut es konzipiert ist.

Die praktische Konsequenz für die Wirtschaftlichkeitsrechnung: Rechne nicht nur den Zeitgewinn im Normalfall, sondern 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 & 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, die sich pauschal nicht beantworten lassen – 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, die im Zweifel konservativ getroffen werden sollte: Lieber einen Prozess zu spät automatisieren als eine schlechte Automatisierung wieder 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, die auch für die Einführung von KI im Unternehmen insgesamt gilt. Und schließlich: Rechtliche Fragen rund um automatisierte Entscheidungen, insbesondere mit Bezug zu Beschäftigten oder Kund:innen, sind hier bewusst nur eingeordnet, nicht abschließend geklärt (Stand Juli 2026) – dafür braucht es im Einzelfall Rechtsberatung oder eine Datenschutz-Folgenabschätzung.

Wenn du unsicher bist, ob ein konkreter Prozess bei euch automatisierungsreif ist oder zuerst vereinfacht werden sollte: Das lässt sich in einem kurzen Erstgespräch meist schneller klären, als es sich anfühlt – oft reicht ein Blick auf die letzten drei bis fünf Sonderfälle, um die Antwort zu sehen.

Checkliste: Automatisierungsreife eines Prozesses prüfen

1. Der Prozess lief in den letzten sechs 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.