Welche Prozesse eignen sich für KI? Der praktische Prozess-Audit
Ein guter Anwendungsfall verbindet spürbaren betrieblichen Wert mit beherrschbarer Komplexität, verfügbaren Daten und einer klaren Rückfalloption.
1. Nicht nach Ideen, sondern nach Arbeit suchen
Beginnen Sie mit wiederkehrender Arbeit: Eingangskanäle, Übergaben, Datenerfassung, Prüfungen, Rückfragen und Statuskommunikation. Befragen Sie Menschen, die den Prozess täglich durchführen. Dokumentieren Sie nicht nur den Soll-Prozess, sondern auch Umwege, Excel-Listen, Kopieren zwischen Systemen und Fälle, die regelmäßig zurückkommen.
Für jeden Kandidaten genügt zunächst ein Einseiter: Auslöser, Ziel, Rollen, Systeme, Eingangsdaten, Ausgang, typische Varianten, Ausnahmen und heutige Bearbeitungszeit. Diese Beschreibung verhindert, dass eine abstrakte „KI-Idee“ den tatsächlichen Ablauf verdeckt.
Den Prozess vom Ergebnis rückwärts betrachten
Fragen Sie zuerst, woran die nächste Rolle erkennt, dass ein Vorgang vollständig ist. Vielleicht braucht der Vertrieb kein „automatisch beantwortetes Lead“, sondern einen Datensatz mit Branche, Bedarf, Dringlichkeit, Einwilligungsstatus und offener Frage. Das gewünschte Ergebnis bestimmt, welche Informationen extrahiert, welche Regeln geprüft und welche Unsicherheit sichtbar gemacht werden muss.
Zeichnen Sie anschließend jeden Systemwechsel und jede menschliche Entscheidung ein. Besonders interessant sind Medienbrüche: E-Mail zu CRM, PDF zu ERP, Telefonnotiz zu Kalender. Sie zeigen Integrationsbedarf, aber auch Verantwortungsgrenzen. Ein scheinbar einfacher Schritt kann kritisch werden, wenn er Stammdaten verändert oder eine externe Nachricht auslöst.
Baseline vor Lösungsidee
Erheben Sie für eine begrenzte Stichprobe Fallzahl, Durchlauf- und Bearbeitungszeit, Rückfragen, Nacharbeit und häufige Fehlerursachen. Die Messung muss nicht perfekt sein, aber ihre Herkunft sollte nachvollziehbar bleiben. Ohne Baseline lässt sich später nicht unterscheiden, ob ein Pilot den Ablauf verbessert oder lediglich eine neue Oberfläche hinzufügt.
2. Wert, Machbarkeit und Risiko getrennt bewerten
| Dimension | Prüffragen |
|---|---|
| Betrieblicher Wert | Wie häufig tritt der Vorgang auf? Wo entstehen Wartezeit, Nacharbeit oder Qualitätsprobleme? |
| Technische Machbarkeit | Sind Eingaben verfügbar? Können die beteiligten Systeme sicher verbunden werden? |
| Qualität | Gibt es eindeutig prüfbare Ergebnisse und repräsentative Testfälle? |
| Risiko | Wer ist betroffen? Welche Folgen hätte eine falsche Antwort oder Aktion? |
| Betriebsfähigkeit | Wer übernimmt Ausnahmen, pflegt Wissen und beobachtet die Leistung? |
Vergeben Sie keine scheinpräzise Gesamtpunktzahl, bevor Sie Ausschlusskriterien geprüft haben. Fehlender rechtmäßiger Datenzugang, nicht kontrollierbare Aktionen oder eine ungeklärte fachliche Verantwortung sind kein „kleiner Abzug“, sondern ein Stoppsignal.
Bevorzugen Sie zunächst Prozesse mit hohem Lernwert, begrenztem Schadenspotenzial und einem Ergebnis, das Fachkräfte schnell prüfen können.
3. Mit realen Fällen statt Demonstrationsfragen testen
Sammeln Sie eine repräsentative Stichprobe historischer Fälle, sofern dies datenschutzrechtlich zulässig ist. Entfernen oder pseudonymisieren Sie personenbezogene Daten, wenn sie für die Bewertung nicht nötig sind. Die Sammlung muss Normalfälle, seltene Formulierungen, unvollständige Eingaben, widersprüchliche Dokumente und bewusst schwierige Fälle enthalten.
Definieren Sie vor dem Prototyp, was „gut genug“ bedeutet. Bei einer Datenerfassung können Pflichtfelder und Feldgenauigkeit zählen; bei Wissensantworten die korrekte Quellenbegründung; bei einer Übergabe Vollständigkeit und Verständlichkeit des Kontexts. So wird ein Test nicht nach dem Bauchgefühl einer eindrucksvollen Demo bewertet.
Testset und Entwicklungsfälle trennen
Nutzen Sie einen Teil der Fälle zum Entwerfen und Fehlersuchen. Halten Sie einen anderen Teil zurück, um Änderungen vergleichbar zu bewerten. Sonst optimiert das Team unbewusst auf bekannte Beispiele. Dokumentieren Sie für jeden Testfall das erwartete Ergebnis, tolerierbare Varianten und besonders kritische Fehler. Nicht jede Abweichung ist gleich wichtig: Eine anders formulierte, aber belegte Antwort ist etwas anderes als eine falsche Systemaktion.
Ergänzen Sie nach Möglichkeit Gegenbeispiele. Dazu gehören Anfragen außerhalb des Leistungsumfangs, fehlende Identität, manipulativ formulierte Instruktionen, widersprüchliche Quellen und Aktionen ohne erforderliche Freigabe. Ein System muss nicht jeden Fall lösen; es muss seine Grenze zuverlässig erkennen und sauber übergeben.
4. Einen schmalen End-to-End-Piloten wählen
Der erste Pilot sollte einen echten Vorgang vom Eingang bis zu einem nutzbaren Ergebnis abbilden. Er darf inhaltlich eng sein, muss aber Datenzugriff, Regeln, Integration, Protokollierung und Übergabe sichtbar machen. Ein isolierter Chat ohne betrieblichen Anschluss beantwortet wichtige Machbarkeitsfragen nicht.
Abhängigkeiten sichtbar priorisieren
Stellen Sie die Kandidaten in einer kleinen Portfoliobetrachtung gegenüber. Hoher Nutzen und geringe Abhängigkeit sind gute Startpunkte. Hoher Nutzen mit ungeklärtem Datenzugang gehört zunächst in eine Vorbereitungsphase. Ein technisch einfacher Fall mit geringem Prozesswert kann als Lernprojekt sinnvoll sein, sollte aber nicht mit einem strategischen Business Case verwechselt werden.
Prüfen Sie auch die Veränderungsbereitschaft. Wenn kein Fachteam Zeit für Testfälle, Rückmeldungen und spätere Pflege bereitstellen kann, fehlt eine zentrale Voraussetzung. Automatisierung ist kein reines IT-Projekt, weil Prozesswissen, Freigaben und Ausnahmen im Fachbereich liegen.
Ergebnis des Audits
- Eine priorisierte Liste mit Begründung und Ausschlusskriterien.
- Ein Zielprozess mit klaren Grenzen und Verantwortlichen.
- Ein erster Evaluationsdatensatz samt Akzeptanzkriterien.
- Eine Übersicht benötigter Daten, Systeme und Berechtigungen.
- Ein Betriebs- und Übergabekonzept für den Pilot.
Nach dem Pilot wird erneut entschieden: erweitern, nachschärfen, mit stärkerer Kontrolle betreiben oder stoppen. Auch ein begründetes Stoppen ist ein erfolgreiches Ergebnis, wenn es spätere Fehlinvestitionen verhindert.
Ein Audit in einem Arbeitstag vorbereiten
Vor dem Termin sammelt die Prozessverantwortung fünf bis zehn reale Fälle und eine grobe Systemübersicht. Im Workshop beschreibt das Team zunächst den heutigen Ablauf, ohne Lösungen zu diskutieren. Danach werden Ergebnis, Varianten, Risiken und Messgrößen festgelegt. Erst im letzten Schritt ordnet man mögliche technische Mechanismen zu. Offene Rechts-, Sicherheits- oder Integrationsfragen werden als eigene Arbeitspakete festgehalten statt durch Annahmen geschlossen.
Das Resultat sollte auch für nichttechnische Stakeholder verständlich sein. Eine Seite Prozessbild, eine Seite Bewertung und eine Seite Pilotgrenzen reichen häufig aus, um eine begründete Entscheidung einzuholen. Detaillierte Architektur folgt, wenn Datenzugang und Verantwortlichkeiten bestätigt sind.
Benennen Sie abschließend die nächste überprüfbare Frage. Das kann die Verfügbarkeit einer Schnittstelle, die Qualität einer Dokumentenklasse oder die sichere Erkennung eines Ausnahmefalls sein. Ein Audit ist dann handlungsfähig, wenn es Unsicherheit in konkrete Prüfaufgaben übersetzt.
Verwandte Lösungen
Quellen
- NIST AI Risk Management Framework
- ISO/IEC 42001: AI management systems
- European Commission: AI regulatory framework
Allgemeine Information, keine Rechtsberatung.