Vom KI-Piloten in den Regelbetrieb: Wann ist ein Workflow einsatzbereit?

Eine Vorführung beweist, dass der Normalfall funktioniert. Das ist notwendig, aber es ist nur ein Teil. Ob ein Workflow im Betrieb trägt, entscheidet sich an den Fällen, die in keiner Vorführung vorkommen: an abweichenden Eingaben, an fehlenden Angaben und an dem Moment, in dem der Workflow selbst ausfällt.

Damit das greifbar wird, zieht sich ein Beispiel durch diesen Ratgeber. Es ist ein selbst erstelltes Muster, kein Kundenprojekt: Nehmen wir an, ein Betrieb erhält seine Eingangsrechnungen als PDF per E-Mail. Der KI-Workflow soll jede Rechnung auslesen - Lieferant, Rechnungsnummer, Datum, Beträge, Steuer, Bestellnummer -, sie mit Bestellung und Wareneingang abgleichen und daraus einen Buchungsvorschlag erzeugen. Die Buchhaltung gibt jeden Vorschlag frei, erst dann geht er ins Buchhaltungssystem. Bezahlt wird nichts, was nicht ein Mensch freigegeben hat.

In der Vorführung sieht das überzeugend aus, weil die gezeigten Rechnungen sauber sind. Die Frage für den Pilot lautet deshalb nicht, ob der Workflow Rechnungen lesen kann, sondern: Erkennt er, wann er sich nicht sicher sein darf? Und kann die Buchhaltung mit dem, was er ihr übergibt, schneller und mindestens so verlässlich arbeiten wie bisher?

Takeaway: Die Vorführung zeigt den Normalfall. Der Pilot muss zeigen, dass der Workflow seine Grenzen erkennt und dass das Team mit den Ausnahmen arbeiten kann.

Der Normalfall. Eine Rechnung eines bekannten Lieferanten, mit Bestellnummer, deren Positionen und Preise zur Bestellung passen und deren Ware vollständig eingegangen ist. Hier soll der Workflow einen vollständigen Buchungsvorschlag liefern.

Abweichende Eingaben. Eine Gutschrift statt einer Rechnung. Eine Teillieferung, bei der nur ein Teil der Bestellung berechnet wird. Ein Preis, der von der Bestellung abweicht. Eine Sammelrechnung über mehrere Lieferungen. Ein eingescanntes Foto statt einer PDF-Datei. Dieselbe Rechnung zum zweiten Mal, weil der Lieferant sie erneut geschickt hat. Und, besonders heikel, eine Bankverbindung, die nicht mit den Stammdaten des Lieferanten übereinstimmt.

Fehlende Angaben. Keine Bestellnummer, kein Leistungsdatum, ein Lieferant, der in den Stammdaten nicht vorkommt. Hier darf der Workflow nicht raten. Er soll die Rechnung mit einem benannten Grund in eine Prüfwarteschlange legen - etwa Bestellnummer fehlt oder Bankverbindung weicht ab -, damit die Buchhaltung sofort sieht, was zu klären ist.

Für den Pilot heißt das: Klären Sie zuerst, ob und unter welchem Vertrag das KI-Werkzeug Ihre Rechnungsdaten verarbeiten darf - Rechnungen enthalten auch personenbezogene Angaben, etwa von Einzelunternehmen oder in Bankverbindungen. Stellen Sie danach aus echten Rechnungen der vergangenen Monate einen Testsatz zusammen, in dem jeder bekannte Sonderfall mindestens einmal vorkommt. Dieser Testsatz ist mehr als ein Prüfstein für den Pilot. Er wird später zum Werkzeug, mit dem Sie jede Änderung am Workflow absichern. Im zweiten Schritt läuft der Workflow im Schattenbetrieb mit: Die Buchhaltung arbeitet wie gewohnt, und die Vorschläge des Workflows werden danach mit ihrem Ergebnis verglichen.

Takeaway: Ein Pilot, der nur saubere Rechnungen verarbeitet, misst die Vorführung. Ein Testsatz mit jedem bekannten Sonderfall und ein Schattenbetrieb messen den Alltag.

Ob ein Ergebnis stimmt, entscheidet nicht das Projektteam, sondern der Fachbereich, der später damit arbeitet. Im Beispiel ist das die Buchhaltung. Sie prüft im Testsatz und im Schattenbetrieb, ob der Buchungsvorschlag dem entspricht, was sie selbst gebucht hätte: richtiger Lieferant, richtige Beträge und Steuer, richtiges Konto, richtige Fälligkeit. Diese Geschäftsabnahme ist etwas anderes als eine technische Prüfung.

Der Unterschied ist wichtig, weil alle Felder korrekt ausgelesen sein können und das Ergebnis trotzdem falsch ist. Eine perfekt erfasste Rechnung für eine Lieferung, die nie angekommen ist, darf nicht zur Zahlung freigegeben werden. Darum gehört der Abgleich mit Bestellung und Wareneingang zum Ergebnis, und darum nimmt der Fachbereich ab, der diesen Zusammenhang kennt.

Ebenso wichtig ist der Rückfallweg. Was passiert, wenn der Workflow einen Tag lang nicht läuft, weil der Anbieter eine Störung hat oder eine Schnittstelle sich geändert hat? Im Beispiel bleiben die Rechnungen im Postfach, und die Buchhaltung erfasst sie manuell weiter. Damit das funktioniert, muss erkennbar sein, welche Rechnungen der Workflow schon verarbeitet hat, sonst wird später doppelt gebucht. Lösen Sie den Rückfall im Pilot einmal bewusst aus, statt ihn zum ersten Mal im Ernstfall zu erleben.

Takeaway: Abgenommen wird das Geschäftsergebnis, nicht die Feldgenauigkeit - und zwar vom Fachbereich. Der Rückfallweg wird getestet, bevor er gebraucht wird.

Ein Workflow entlastet nur, wenn der gesamte Aufwand je Fall sinkt, nicht nur der Teil, den die KI übernimmt. Messen Sie deshalb vor dem Pilot einen Ausgangswert und danach mit derselben Methode erneut. Für das Beispiel schlagen wir vier Messgrößen vor:

• Aufwand je Rechnung vom Eingang bis zur Freigabe, einschließlich Prüfen, Nachfragen und Korrigieren.
• Anteil der Rechnungen in der Prüfwarteschlange und wie lange sie dort liegen. Ein hoher Anteil ist kein Fehler, solange die Gründe stimmen, verschiebt aber Arbeit.
• Fehler, die erst nach der Freigabe auffallen - beim Zahllauf, bei der Abstimmung der Konten oder durch eine Rückfrage des Lieferanten. Sie sind besonders teuer, weil sie spät und an anderer Stelle sichtbar werden.
• Betreuungsaufwand des Workflows selbst: Fehlermeldungen ansehen, Regeln nachschärfen, Rückfragen des Teams beantworten.

Die letzte Messgröße fällt leicht unter den Tisch. Im Pilot erledigt das Projektteam die Betreuung nebenbei, im Regelbetrieb muss sie jemand dauerhaft übernehmen. Wer sie nicht mitzählt, rechnet den Workflow günstiger, als er ist. Wie Sie aus diesen Messwerten eine Kostenrechnung machen, steht in unserem Ratgeber Was kostet KI-Automatisierung im Mittelstand wirklich?

Takeaway: Gemessen wird der ganze Fall, nicht der automatisierte Teil - einschließlich Prüfung, später Fehler und der Betreuung des Workflows.

Abnahmekriterien werden vor dem Pilot festgelegt, nicht nach dem ersten Eindruck. Für den Musterablauf Eingangsrechnungen könnten sie so lauten. Verstehen Sie sie als Vorschlag, den Sie an Ihren eigenen Ablauf anpassen:

• Nichts geht verloren. Jede Rechnung des Testsatzes endet in genau einem von zwei Zuständen: Buchungsvorschlag zur Freigabe oder Prüfwarteschlange mit benanntem Grund. Keine bleibt liegen, keine wird doppelt angelegt.
• Der Normalfall stimmt. Bei Rechnungen mit passender Bestellung und vollständigem Wareneingang entspricht der Vorschlag dem, was die Buchhaltung selbst gebucht hätte. Bestätigt von der Buchhaltung, nicht vom Projektteam.
• Sonderfälle werden erkannt. Gutschriften, Teillieferungen, Preisabweichungen, fehlende Bestellnummern und doppelt geschickte Rechnungen landen ausnahmslos in der Prüfwarteschlange.
• Bankverbindungen werden nie still übernommen. Weicht sie von den Stammdaten ab, prüft immer ein Mensch.
• Die Freigabe bleibt beim Menschen. Kein Vorschlag geht ohne Freigabe ins Buchhaltungssystem.
• Der Rückfallweg ist erprobt. Einmal bewusst ausgelöst, Rechnungen manuell weiterbearbeitet, später nichts doppelt gebucht.
• Der Gesamtaufwand sinkt. Der Aufwand je Rechnung einschließlich Prüfung und Nacharbeit liegt unter dem Ausgangswert. Um wie viel, legen Sie vor dem Start fest.
• Der Betrieb ist übergeben. Zuständigkeit, Dokumentation und Überwachung sind benannt, wie in Abschnitt 06 beschrieben.

Aus den Beobachtungen im Pilot folgt dann eine von drei Entscheidungen. Die Tabelle zeigt, wie Kriterium, Beobachtung und Entscheidung zusammenhängen.

Zuständigkeit. Zwei Rollen gehören namentlich festgelegt: fachlich jemand aus der Buchhaltung, der über Sonderfälle und Regeln entscheidet, technisch jemand, der Fehlermeldungen sieht und Anpassungen umsetzt - im Haus oder bei einem Dienstleister. Beide wissen voneinander.

Dokumentation. Was der Workflow tut, welche Prüfregeln gelten, welche Sonderfälle in die Warteschlange gehen und wie der Rückfallweg funktioniert. Geschrieben für die Person, die in einem Jahr neu dazukommt, nicht für das Projektteam.

Überwachung. Eine besonders aussagekräftige Kennzahl im Betrieb ist der Anteil der Fälle in der Prüfwarteschlange, aufgeschlüsselt nach Lieferant. Steigt er bei einem Lieferanten plötzlich an, hat dieser vermutlich seine Rechnungsvorlage geändert. Sinkt er plötzlich, ist das mindestens ebenso verdächtig: Dann übersieht der Workflow womöglich Fälle, die er früher erkannt hat.

Spätere Änderungen. Formatwechsel beim Lieferanten, ein Update des Buchhaltungssystems oder ein neues Modell beim KI-Anbieter verändern die Ergebnisse, ohne dass eine Fehlermeldung erscheint. Deshalb läuft nach jeder Änderung der Testsatz aus dem Pilot erneut durch, und erst wenn er besteht, geht die Änderung in den Betrieb. Jeder neue Sonderfall, der im Alltag auftaucht, wird in den Testsatz aufgenommen. So wird er mit der Zeit vollständiger statt veralteter.

Takeaway: Zwei benannte Rollen, eine Dokumentation für die nächste Person in der Rolle, eine Überwachung der Prüfwarteschlange je Lieferant und ein Testsatz, der jede Änderung absichert.