Ein Gründer beauftragt einen KI-Agenten-Implementierer. Der Workflow wird in einem Gespräch erklärt, Live-Beispiele werden gezeigt, es macht im Raum Sinn. Sechs Wochen später korrigiert das Team noch täglich Agenten-Ergebnisse. Drei weitere Discovery-Sessions folgten der ersten. Die Implementierung dauerte vier Monate statt der erwarteten sechs Wochen – nicht weil der Workflow komplex war, sondern weil niemand ihn vor Beginn des Engagements dokumentiert hatte.
Die Implementierungsgeschwindigkeit wird vor dem ersten Gespräch bestimmt
Die Variable, die die Implementierungsdauer am stärksten beeinflusst, ist weder die Erfahrung des Implementierers noch die Komplexität des Workflows. Es ist, ob das Unternehmen seinen Prozess vor Beginn des Engagements Schritt für Schritt beschreiben kann.
Ein Unternehmen, das mit einer schriftlichen Verfahrensbeschreibung ins erste Gespräch kommt – Trigger definiert, Eingaben benannt, Ausgabeformat festgelegt, Ausnahmen aufgelistet – erhält einen funktionierenden Agenten in zwei bis vier Wochen. Ein Unternehmen, das den Workflow durch Live-Demonstration erklärt oder sagt „ich schicke Ihnen ein Beispiel", iteriert typischerweise zwei bis drei Monate, bevor der Agent zuverlässig läuft.
Der Unterschied liegt nicht in der Komplexität des Workflows. Er liegt in der Dokumentationsarbeit – und darin, ob diese Arbeit vor oder während des Engagements stattfindet.
Was undokumentierte Prozesse in einem laufenden Engagement kosten
Wenn ein Prozess vor Beginn des Engagements nicht dokumentiert ist, wird Dokumentation zum Engagement. Jede Session mit „lassen Sie mich zeigen, was ich meine" ist eine Session, in der kein Aufbau stattfindet. Der Implementierer beobachtet, notiert und stellt aus einer Live-Demonstration eine Spezifikation zusammen – Arbeit, die das Unternehmen vor dem ersten Gespräch hätte leisten können.
Bei einem typischen Implementierungssatz fügt jede zusätzliche Discovery-Session ein bis zwei Wochen zur Zeitlinie hinzu. Ein Unternehmen, das vier Sessions benötigt, um einen Workflow zu spezifizieren, der an einem Nachmittag hätte aufgeschrieben werden können, hat für diesen Nachmittag mehrfach bezahlt.
Die Kosten sind nicht abstrakt. Sie zeigen sich als verlängerte Zeitlinie, höhere Rechnung und – häufig – als ein Agent, der nach dem Launch noch Korrekturen benötigt, weil die Discovery-Sessions Grenzfälle übersehen haben, die eine schriftliche Verfahrensbeschreibung aufgedeckt hätte.
Die Kosten undokumentierter Prozesse tragen die Auftraggeber, nicht der Implementierer. Jede Runde „lassen Sie mich zeigen, was ich meine" verlängert den Zeitplan und erhöht die Kosten – bevor eine einzige Zeile Agenten-Code geschrieben wurde.
Was ein dokumentierter Prozess vor dem Engagement bedeutet
Ein Prozess ist bereit für die Implementierung, wenn eine neue Person ihn korrekt ausführen könnte – allein auf Basis der schriftlichen Version, ohne weiteren Kontext. Dieser Test – der Neue-Mitarbeiter-Test – ist das zuverlässigste Maß dafür, ob ein Prozess präzise genug spezifiziert ist, damit ein Agent ihn ausführen kann.
In der Praxis bedeutet Dokumentationsreife, dass vier Elemente vor dem ersten Gespräch schriftlich vorliegen.
Der Trigger. Ein spezifisches, beobachtbares Ereignis, das den Workflow startet. Nicht „wenn ein Kunde ein Update benötigt" – sondern „wenn die letzte Status-E-Mail eines Projekts mehr als sieben Tage zurückliegt". Der Trigger muss testbar sein: entweder er feuert oder er feuert nicht.
Die Eingaben. Die genauen Informationen, die beim Ausführen des Workflows verfügbar sind. Feldnamen, Datenquellen, welche Felder immer befüllt sind, welche leer sein können. Ein Agent kann keine Informationen verwenden, die er nicht erhalten hat.
Das Ergebnis. Die spezifische Leistung, die der Workflow produziert. Nicht „eine Follow-Up-E-Mail" – eine Follow-Up-E-Mail mit definiertem Betreffzeilenformat, einer maximalen Länge und einem konkreten nächsten Schritt.
Die Ausnahmen. Die Fälle, in denen sich der Workflow anders verhält, jeder explizit benannt. Nicht „es kommt drauf an" – sondern „wenn der Kunde innerhalb von 48 Stunden auf die letzte E-Mail geantwortet hat, diesen Zyklus überspringen". Ein Workflow mit fünfzehn dokumentierten Ausnahmen ist spezifizierbar. Ein Workflow, der mit „es kommt drauf an" beantwortet wird, ist es nicht.
Ein Prozess mit diesen vier Elementen schriftlich gibt einem Implementierer, was er zum Bauen braucht. Ein Prozess ohne sie macht den Implementierer zum Verfasser der Spezifikation – auf Kosten des Auftraggebers.
Wie man prüft, ob der Prozess dokumentationsreif ist
Vor dem Aufschreiben der Verfahrensbeschreibung hilft es zu wissen, ob der Prozess stabil genug ist. Ein Prozess, der sich noch wöchentlich ändert, liefert eine Spezifikation, die veraltet ist, bevor der Agent fertig ist. Ein Prozess, den das Team konsistent ausführt, ist dokumentierbar.
Die folgende Checkliste zeigt, ob ein Workflow bereit zur Spezifikation ist:
| Frage | Bereit | Nicht bereit |
|---|---|---|
| Wird dieser Workflow von allen im Team gleich ausgeführt? | Ja — oder er würde es mit einer schriftlichen Beschreibung sein | Nein — jeder macht es anders |
| Wurde dieser Workflow in den letzten drei Monaten mindestens zwanzig Mal ausgeführt? | Ja | Nein — zu neu oder zu selten für ein Muster |
| Können Sie den Trigger ohne das Wort „normalerweise" beschreiben? | Ja | Nein — „normalerweise wenn ein Kunde anruft" ist kein Trigger |
| Sind die Ausnahmen endlich? | Ja — Sie können alle benennen | Nein — immer wieder tauchen neue auf |
| Hat das Ergebnis ein definiertes Format? | Ja — jedes Mal dieselbe Struktur | Nein — variiert je nach Kontext |
Ein Workflow, der alle fünf Fragen mit „bereit" beantwortet, kann heute dokumentiert werden. Ein Workflow mit ein oder zwei „nicht bereit"-Antworten benötigt noch einen Monat konsistenter Ausführung, bevor eine Dokumentation eine zuverlässige Spezifikation liefert.
Wie man einen bekannten, aber nie aufgeschriebenen Prozess dokumentiert
Die meisten Gründer kennen ihre Prozesse gut genug, um sie auszuführen. Weniger haben sie aufgeschrieben, weil das Aufschreiben Zeit kostet und der Prozess immer einfach funktioniert hat. Die folgende Methode wandelt Prozesswissen in zwei bis drei Stunden in eine Spezifikation um.
Mit einer aktuellen Instanz beginnen. Die letzte Ausführung dieses Workflows öffnen. Was hat ihn ausgelöst? Das aufschreiben. Welche Informationen wurden zur Durchführung verwendet? Jedes Stück und seine Herkunft auflisten. Was wurde produziert? Das genaue Format und den Inhalt beschreiben.
Die Entscheidungspunkte identifizieren. Den Workflow erneut durchgehen und jeden Punkt identifizieren, an dem eine Entscheidung getroffen wurde. „Wenn der Kunde geantwortet hatte, habe ich das Follow-up übersprungen." „Wenn die Rechnung über einem bestimmten Betrag war, habe ich angerufen statt E-Mail zu schicken." Jeder Ermessensentscheid ist entweder eine Ausnahme oder ein Hinweis, dass die Trigger-Bedingung präzisiert werden muss.
Zwanzig weitere Instanzen durchgehen. Die letzten zwanzig Ausführungen des Workflows prüfen. Jede markieren, die anders als der Standardpfad behandelt wurde. Für jeden Unterschied einen Satz schreiben, der erklärt warum. Diese Sätze sind die Ausnahmeregeln.
Die Ergebnisdefinition schreiben. Das Ergebnis beschreiben, als würden Anweisungen für jemanden geschrieben, der den Workflow noch nie gesehen hat. Wie sieht ein korrektes Ergebnis konkret aus — Länge, Format, erforderlicher Inhalt, Ton? In einem Satz aufschreiben.
Das Ergebnis dieser Übung ist ein grober Brief. Er muss nicht poliert sein. Ein Implementierer kann eine grobe Spezifikation schnell verfeinern. Aus dem Nichts kann er nicht bauen.
Drei Dinge, die vor dem ersten Gespräch bereit sein sollten
Ein Implementierer kann alles bauen, was Sie präzise beschreiben können. Die Hürde ist fast nie die Technologie.
Vorbereitung erfordert keinen technischen Hintergrund. Sie erfordert, mit dem Prozess zu sitzen und ihn aufzuschreiben.
Die Verfahrensbeschreibung schreiben. Den Workflow vom Trigger bis zum Ergebnis Schritt für Schritt dokumentieren, ohne Vorkenntnisse beim Leser vorauszusetzen. Überall, wo sich „dann prüfen Sie..." schreiben lässt – aufschreiben, was geprüft wird, was jedes Ergebnis bestimmt und was in jedem Fall als nächstes passiert.
Die Ausnahmen auflisten. Die letzten zwanzig Instanzen des Workflows durchgehen und jede markieren, die anders als die übrigen behandelt wurde. Für jeden Unterschied den Grund aufschreiben. Diese Gründe werden zu den Ausnahmeregeln. Diesen Schritt überspringen die meisten Auftraggeber – und er ist die Quelle der meisten Korrekturen nach dem Launch.
Definieren, was „fertig" bedeutet. Einen Satz schreiben, der ein korrektes Ergebnis beschreibt. Wenn die Bewertung der Agenten-Ergebnisse als korrekt oder falsch mehr als dreißig Sekunden dauert, ist die Ergebnisdefinition zu vage. Sie so schärfen, bis die Prüfung sofort möglich ist.
Ein Unternehmen, das mit diesen drei Dokumenten ins erste Gespräch kommt, erhält einen funktionierenden Agenten in kurzer Zeit. Ein Unternehmen ohne diese Dokumente erhält ein Spezifikationsprojekt, das mehr kostet als der Agent selbst. Die Dokumentationsarbeit ist unvermeidbar – die einzige Frage ist, wer sie übernimmt und wann.
Häufig gestellte Fragen
Was sollte vor der Beauftragung eines KI-Agenten-Implementierers bereit sein?
Drei schriftlich vorliegende Dokumente vor dem ersten Gespräch: die Verfahrensbeschreibung (Trigger bis Ergebnis, Schritt für Schritt), die Ausnahmenliste (jeder Fall, der vom Standardpfad abweicht, mit Begründung) und die Ergebnisdefinition (ein Satz, der beschreibt, wie ein korrektes Ergebnis aussieht). Diese drei Dokumente entfernen die Spezifikationsphase aus dem Engagement und halbieren die Implementierungszeit.
Warum ist Dokumentation vor dem Engagement wichtig?
Wenn ein Prozess vor Beginn des Engagements nicht dokumentiert ist, wird Dokumentation zum Engagement. Jede Discovery-Session – den Workflow live beobachten, eine Spezifikation aus Beispielen zusammenstellen – fügt ein bis zwei Wochen zur Zeitlinie auf Kosten des Auftraggebers hinzu. Die Dokumentationsarbeit ist unvermeidbar; sie vor dem ersten Gespräch zu leisten bedeutet, einmal dafür zu bezahlen statt über das gesamte Engagement hinweg.
Was ist der Neue-Mitarbeiter-Test für Prozessreife?
Der Neue-Mitarbeiter-Test fragt: Könnte eine neue Person diesen Prozess am ersten Tag korrekt ausführen, allein auf Basis der schriftlichen Verfahrensbeschreibung ohne weiteren Kontext? Wenn ja, ist der Prozess spezifizierbar und der Agent kann darauf aufgebaut werden. Wenn die Antwort Vorkenntnisse, Urteilsvermögen bei Ausnahmen oder Rückfragen erfordert, ist die Spezifikation unvollständig – und der Agent wird an denselben Lücken scheitern.
Wie lange dauert es, einen Workflow vor der Beauftragung eines Implementierers zu dokumentieren?
Ein einzelner Workflow mit klarem Trigger, definierten Eingaben, einem spezifischen Ergebnis und einer überschaubaren Anzahl von Ausnahmen lässt sich typischerweise in zwei bis drei Stunden vollständig dokumentieren – einschließlich einer Durchsicht aktueller Instanzen zur Aufdeckung von Grenzfällen. Dieser Zeitaufwand entfernt Wochen von Discovery-Arbeit aus dem Engagement und liefert ein Brief, aus dem der Implementierer direkt bauen kann.
Was ist, wenn sich der Workflow häufig ändert — sollte man warten, bis er stabil ist? Ja. Ein Workflow, der sich noch wöchentlich ändert, liefert eine Spezifikation, die veraltet ist, bevor der Agent fertig ist. Der Dokumentationstest ist nicht, ob der Workflow korrekt läuft, sondern ob er konsistent läuft — auf dieselbe Weise, von allen im Team, mit einer endlichen Ausnahmenmenge. Wenn nicht, ist diese Inkonsistenz das zu lösende Problem, bevor die Implementierung beginnt. Ein Agent, der auf einem inkonsistenten Prozess aufgebaut ist, systematisiert die Inkonsistenz.
Müssen alle Ausnahmen gelöst sein, bevor das Engagement beginnt? Nein. Das Ziel der Ausnahmenliste ist, die Ausnahmen zu benennen, nicht zu lösen. Eine klar benannte Ausnahme — „Kunde hat innerhalb von 48 Stunden geantwortet: diesen Zyklus überspringen" — kann in den Kontrolllayer eingebaut werden. Eine vage Ausnahme — „hängt vom Kunden ab" — nicht. Der Unterschied zwischen einer gelösten und einer benannten Ausnahme ist der Unterschied zwischen etwas, das ein Agent ausführen kann, und etwas, das er falsch behandelt.
Was sollte man nicht zum ersten Gespräch mitbringen? Eine Live-Demonstration des Workflows. Live-Demonstrationen sind die ineffizienteste Art, Prozesswissen zu übertragen — der Beobachter sieht eine Instanz, zu einem Zeitpunkt, von einer Person ausgeführt. Er verpasst die Ausnahmen, Edge Cases und Entscheidungen, die bei der siebenundzwanzigsten Instanz anders ablaufen als bei der gezeigten. Eine zweiseitige schriftliche Verfahrensbeschreibung enthält mehr verwertbare Spezifikation als eine Stunde Live-Beobachtung.