Illustratives Szenario. Eine Buchhaltungskanzlei will, dass ein Agent Zahlungseingänge abgleicht. Man fragt Marta, die das seit zwölf Jahren macht, wie sie vorgeht. „Einfach“, sagt sie, „du gleichst den Kontoauszug mit den Rechnungen ab.“ Der Agent wird auf dieser Beschreibung gebaut und scheitert in den ersten Wochen genau dort, wo Marta nie nachdachte: beim Kunden, der drei Rechnungen mit einer Überweisung zahlt, beim Betrag, der immer um einen mündlich vereinbarten Rabatt zu niedrig eintrifft, beim Quartalsabschluss, an dem nichts angefasst wird, bis eine E-Mail kommt. Nichts davon stand irgendwo. Marta wusste nicht einmal, dass sie es wusste.
Die These in einer Zeile: Bevor du einen Prozess automatisierst, musst du aus dem Kopf der Person holen, was nie aufgeschrieben wurde – und dieser Schritt bringt oft mehr als die Automatisierung selbst.
Warum Prozesse dokumentieren, bevor du mit KI automatisierst?
Weil ein Agent tut, was du ihm erzählst, nicht was das Unternehmen wirklich macht. Der Unterschied ist implizites Wissen: Kriterien, Ausnahmen und Abkürzungen, die die Person bei der Arbeit unbewusst anwendet und deshalb nicht erklären kann. Fragst du „Wie machst du das?“, bekommst du die offizielle Version, die in einen Satz passt. Der Agent wird auf dieser Version gebaut und bricht an allem anderen.
Das ist kein Detail der Einführung. Die RAND-Analyse dazu, warum KI-Projekte scheitern, gestützt auf Interviews mit Ingenieuren und Data Scientists, nennt als eine der häufigsten Ursachen, dass das zu lösende Problem falsch verstanden oder falsch kommuniziert wurde (RAND, 2024). Es ist dasselbe Muster, das wir in warum KI-Automatisierungsprojekte scheitern beschreiben: Das Projekt scheitert nicht in der Demo, sondern in der Lücke zwischen dem, was jede Seite für selbstverständlich hielt.
Woran erkennst du, dass ein Prozess nur im Kopf einer Person existiert?
Es gibt recht zuverlässige Anzeichen, und du brauchst kein Audit, um sie zu sehen.
- Zwei Personen machen es unterschiedlich und beide sagen, sie machen es richtig. Jede wendet ihr eigenes Kriterium an, und niemand hat die beiden je nebeneinandergelegt.
- Fehlt diese Person, steht der Prozess still oder wird schlechter. Wenn jemandes Urlaub ein Betriebsrisiko ist, lebt der Prozess in ihrem Kopf (dasselbe Problem, aus Sicht des Agenten, in was mit deinem Agenten passiert, wenn der geht, der ihn gebaut hat).
- Die Erklärung beginnt mit „kommt drauf an“. Wenn jeder Schritt ein „kommt drauf an“ mitbringt und niemand weiß, worauf, gibt es ungeschriebene Regeln.
- Ausnahmen werden per Telefon oder Nachricht geklärt. Was außerhalb des Systems entschieden wird, landet nicht im System – und der Agent sieht nur das System.
Wie holst du den echten Prozess in einer Woche heraus?
Nicht mit einem Fragebogen und nicht mit einem Zwei-Stunden-Meeting. Sondern mit echten Fällen, beobachtet von jemandem, der die Arbeit nicht selbst macht. Eine Methode, die in fünf Tage passt:
- Montag: Wähle einen Prozess und eine Person. Ein einziger Prozess, der mit dem meisten Durchlauf, und wer ihn täglich ausführt. Sag von Anfang an, dass niemand bewertet wird: Es geht ums Verstehen, nicht ums Prüfen.
- Dienstag: Beobachte Fälle, frag nicht, wie es geht. Setz dich neben die Person, während sie echte Fälle bearbeitet, auch die schrägen, und notiere jede Entscheidung. Eine Stichprobe der letzten Fälle ist mehr wert als jede Beschreibung.
- Mittwoch: Frag bei jeder Entscheidung nach dem Warum. „Warum dieser und nicht jener?“, „Was wäre bei einem anderen Betrag passiert?“ Hier kommen die Kriterien zutage, die sie für selbstverständlich hielt.
- Donnerstag: Schreib die Geschäftsregel auf, nicht die Klicks. Bedingung, Ausnahme und wer informiert wird, eine Seite pro Prozess. Das Format steht in Automatisierungen dokumentieren.
- Freitag: Prüf gegen Fälle, die sie nicht kennt. Gib ihr neue Fälle, ohne die Regel zu zeigen, und vergleiche ihre Entscheidung mit dem Aufgeschriebenen. Jede Abweichung ist eine fehlende Regel.
| Was die offizielle Version sagt | Was die Person tatsächlich tut | Wie es auftaucht |
|---|---|---|
| „Ich gleiche den Auszug mit den Rechnungen ab“ | Bündelt Zahlungen, wendet mündlich vereinbarte Rabatte an und stellt bestimmte Kunden zurück | Echte Fälle beobachten, statt sie sich beschreiben zu lassen |
| „Wird freigegeben, wenn es der Richtlinie entspricht“ | Gibt Dinge außerhalb der Richtlinie frei, wenn sie den Kunden kennt | Bei jeder Ausnahme nach dem Warum fragen |
| „Wird vor dem Versand geprüft“ | Prüft nur, was komisch aussieht – nach einem Bauchgefühl, das sie nicht benennen kann | Neue Fälle vorlegen und ihre Entscheidung mit der geschriebenen Regel vergleichen |
Schau auf die letzte Spalte: In keinem Fall besteht die Lösung darin, mehr zu fragen – sie besteht darin, mehr hinzusehen. Wer seine Arbeit beschreibt, beschreibt das Ideal; wer sie vor dir macht, zeigt die Wirklichkeit. Und nur die Wirklichkeit begegnet dem Agenten am Montagmorgen, mit den Fällen, die in der Kick-off-Runde niemand vorhergesehen hat.
Und wenn sich beim Dokumentieren zeigt, dass es sich nicht automatisieren lässt?
Das kommt öfter vor, als man zugibt. Beim Dokumentieren tauchen Widersprüche zwischen Personen auf, Schritte, deren Grund niemand kennt, und Entscheidungen, die von einem Urteil abhängen, das sich nicht auf Regeln reduzieren lässt. Daraus ergeben sich drei Auswege: den Prozess vereinfachen, bevor du irgendetwas anfasst; nur den Teil automatisieren, der schon eine Regel ist, und den Urteilsteil bei einer Person lassen; oder entscheiden, dass dieser Prozess nichts für einen Agenten ist (die Überlegung dahinter steht in wann du nicht mit KI automatisieren solltest). Jeder der drei ist billiger, als es erst zu merken, wenn der Agent schon produktiv läuft.
Und der Urteilsteil verschwindet nicht: Er legt fest, wie viel Autonomie du dem Agenten geben kannst. Das entscheidest du mit den Autonomiestufen eines Agenten – und nur, wenn du vorher weißt, wo das Urteil sitzt.
Wann lohnt es sich nicht, den Prozess zuerst zu dokumentieren?
Wenn der Prozess kurz, umkehrbar und billig zu verbocken ist: drei Schritte, weder Geld noch personenbezogene Daten im Spiel. Dann probierst du direkt und korrigierst unterwegs. Auch lohnt es sich nicht, einen Prozess, der sich jeden Monat ändert, so genau zu dokumentieren; dort schreibst du die stabilen Prinzipien auf, nicht jeden Schritt (mehr in einen Prozess automatisieren, der sich jeden Monat ändert).
Hast du mehrere Kandidaten und weißt nicht, womit du anfangen sollst, beantwortet deine Prozesse für KI prüfen zuerst, welcher den Aufwand verdient; die Übung dieser Woche ist das, was du danach mit dem gewählten machst.
Die Zeile zum Mitnehmen: Der Prozess, den du automatisierst, ist nicht der im Handbuch, sondern der, den die Person ausführt – und solange der nicht aufgeschrieben ist, steht der Agent auf einer Vermutung.
Quellen (abgerufen am 28. Oktober 2026): „The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed“, RAND Corporation (2024), qualitativ verwendet. Das Eingangsszenario ist illustrativ, kein realer Fall.