Angenommen, die Vorarbeit ist getan. Du weißt, welcher Ablauf sich lohnt, und er ist als Arbeitsanweisung beschrieben. Auslöser, Schritte, Fertig-Kriterium stehen fest.
Jetzt kommt der Moment, in dem die meisten Projekte falsch abbiegen. Sie fangen beim Werkzeug an. Welches Tool nehmen wir, n8n oder Make, welches Modell, welche Plattform. Das ist die letzte Frage, nicht die erste, und sie beantwortet sich meistens von selbst, sobald die anderen geklärt sind.
Hier ist die Reihenfolge, mit der ich arbeite. Sie ist unspektakulär und sie hält.
Schritt 1: Miss den Ist-Zustand, bevor du etwas baust
Zwei Zahlen, sonst nichts: wie lange ein Durchlauf heute dauert und wie oft er im Monat vorkommt. Dazu, falls vorhanden, wie oft etwas schiefgeht.
Das dauert eine Woche nebenher und ist der einzige Grund, warum du hinterher sagen kannst, ob sich etwas verbessert hat. Ohne diese Zahlen endet jedes Projekt in einer Diskussion darüber, ob es sich gelohnt hat, und die gewinnt der, der lauter redet.
Notier auch, was der Ablauf heute an Fehlern produziert. Eine Automatisierung, die genauso schnell ist, aber die vergessene Wiedervorlage abschafft, kann sich allein darüber rechnen.
Schritt 2: Trenne Handgriffe von Entscheidungen
Geh die Schritte deiner Anweisung durch und markiere jeden als eines von beiden.
Handgriff: Daten von A nach B, Datei umbenennen, Vorlage befüllen, Eintrag anlegen. Läuft immer gleich. Das gehört in eine feste Regel, nicht in ein Modell. Es ist billiger, schneller und macht jedes Mal dasselbe.
Entscheidung: Ist das eine Reklamation oder eine Bestellung? Passt dieser Textbaustein? Ist der Betrag plausibel? Das ist der Teil, für den es ein Sprachmodell braucht.
Die meisten Abläufe bestehen zu achtzig Prozent aus Handgriffen und zu zwanzig aus Entscheidungen. Wer alles einem Modell überlässt, zahlt für Rechenleistung, die eine Regel gratis erledigt, und handelt sich Unberechenbarkeit ein, wo keine nötig wäre. Wo genau die Grenze verläuft, steht im Beitrag zu deterministischer gegen KI-Automatisierung.
Schritt 3: Nimm den schmalsten Schnitt, nicht den ganzen Prozess
Jeder Ablauf hat einen Normalfall und einen Schwanz von Sonderfällen. Der Normalfall ist meistens der weitaus größte Teil, die Sonderfälle fressen die Bauzeit.
Automatisiere den Normalfall und lass alles andere zum Menschen laufen. Nicht als Kompromiss, sondern als Bauweise: Das System erkennt, wenn ein Vorgang nicht dem Normalfall entspricht, und legt ihn auf einen Stapel für Menschen. Ein Ablauf, der siebzig Prozent sauber erledigt und dreißig Prozent ehrlich abgibt, ist im Betrieb mehr wert als einer, der alles versucht und bei jedem zehnten Vorgang etwas Falsches produziert.
Das ist auch der Grund, warum ich vom ersten Fall nie verlange, dass er viel spart. Er muss funktionieren und sichtbar sein.
Schritt 4: Erst Entwurf, dann Freigabe, dann Stichprobe
Kein neuer Ablauf wirkt am ersten Tag nach außen. Drei Stufen, in dieser Reihenfolge, jede Stufe erst nach Zahlen aus der vorherigen:
- Vorbereiten. Das System legt einen Entwurf hin, ein Mensch übernimmt oder verwirft. Antwortentwurf im Postfach, Angebotsentwurf im System. Nichts geht raus, bevor jemand hingesehen hat.
- Freigeben. Das System arbeitet vollständig, das Ergebnis wartet an einer definierten Stelle auf ein Ja. Der Unterschied zur ersten Stufe ist der Aufwand für den Menschen: Er beurteilt, statt zu bearbeiten.
- Stichprobe. Es läuft durch, und jemand sieht sich regelmäßig einen Teil an. Vertretbar erst, wenn die Zahlen aus Stufe zwei das hergeben.
Und dazu die Regel, die am meisten Ärger erspart: Der Prüfpunkt gehört an die Entscheidung, nicht ans Ergebnis. Wenn ein Ablauf im dritten Schritt bestimmt, um welchen Kunden und welche Leistung es geht, dann prüfst du dort. Stimmt das, ist der Rest Fleißarbeit. Stimmt es nicht, ist alles danach wertlos, egal wie gut es formuliert ist. Am Ende zu prüfen ist die teuerste Stelle.
Schritt 5: Vier Wochen mitlaufen lassen
Bevor der neue Ablauf den alten ersetzt, lass ihn danebenher laufen. Das System erzeugt sein Ergebnis, der Mensch macht es weiter wie bisher, und ihr vergleicht.
Das kostet ein paar Wochen und ist die günstigste Versicherung im ganzen Projekt. Hier fallen genau die Fälle auf, die in keiner Anweisung stehen: der Kunde mit den zwei Rechnungsadressen, der Lieferant, der seine Nummern anders schreibt, der Vorgang, der einmal im Quartal rückwärts läuft. Diese Fälle findest du nicht durch Nachdenken, nur durch Betrieb.
Erst wenn die Ergebnisse über vier Wochen übereinstimmen, wird umgestellt.
Schritt 6: Rückfahrkarte und Protokoll
Alles, was das System verändern kann, muss sich zurückdrehen lassen. Bei Dateien heißt das Versionierung, bei Datensätzen ein Wiederherstellungspunkt, bei Mails: erst in den Entwurfsordner, nicht in den Postausgang.
Dazu ein Protokoll, das eine einzige Frage beantworten kann: Warum hat das Ding das getan? Wenn ein Kunde in vier Wochen anruft, brauchst du den Vorgang, die Eingangsdaten und die Entscheidung. Ohne das diskutierst du gegen ein System, das dir nicht antworten kann.
Und die Rechtefrage, die sich niemand gern stellt: Zugriff auf das, was die Aufgabe erfordert, und auf nichts sonst. Diese Arbeit macht man einmal am Anfang oder nach dem ersten Vorfall unter Zeitdruck.
Schritt 7: Gegen die Zahlen von Schritt 1 messen
Nach vier Wochen Echtbetrieb dieselben zwei Zahlen erheben und vergleichen. Dazu eine dritte: Wie oft musste ein Mensch eingreifen?
Diese dritte Zahl ist die wichtigste und wird fast nie erhoben. Ein Ablauf, der nominell automatisch läuft, aber bei jedem dritten Vorgang jemanden aus der Arbeit reißt, hat nichts gespart. Er hat die Arbeit nur unplanbar gemacht.
Wenn die Zahlen nicht stimmen, ist Zurückdrehen ein legitimes Ergebnis. Genau das unterscheidet ein Projekt mit Messpunkt von einem, das aus Rechtfertigungsdruck weiterläuft. Warum das einer der Hauptgründe für gescheiterte KI-Projekte ist, habe ich dort beschrieben.
Die Frage, die vor dem Start beantwortet sein muss
Wer betreibt das Ding? Nicht, wer es baut. Wer es in einem halben Jahr anfasst, wenn der Anbieter eine Schnittstelle ändert oder ein Sonderfall auftaucht.
Wenn darauf niemand die Hand hebt, ist es kein Automatisierungsprojekt, sondern ein Prototyp mit langer Lebenserwartung. Das ist völlig in Ordnung, solange alle es so nennen. Problematisch wird es, wenn ein Ablauf produktiv geht, den niemand pflegt: Der fällt nicht laut aus, sondern liefert eines Tages leise falsche Ergebnisse.
Fazit
Die Reihenfolge lautet: messen, Handgriffe von Entscheidungen trennen, den Normalfall schmal schneiden, mit dem Entwurf beginnen, vier Wochen parallel laufen lassen, eine Rückfahrkarte einbauen, gegen die Ausgangszahlen messen.
Das Werkzeug kommt zum Schluss und ist dann meistens keine große Frage mehr. Wer umgekehrt anfängt, hat nach zwei Monaten ein hübsch gebautes System und keine Antwort darauf, ob es besser geworden ist.
Wenn du das für einen konkreten Ablauf durchspielen willst, rechne den KI-Potenzial-Check durch oder wir gehen ihn in einer KI-Beratung gemeinsam durch.