Manche Prozesse wirken einfacher, als sie sind. Jemand nimmt eine Vorlage, passt ein paar Angaben an, wählt eine Sprache, vergibt für das Dokument eine laufende Nummer und speichert es. Wiederholt sich diese Handlung regelmäßig, liegt Automatisierung nahe.

Bis du anfängst zu fragen. Warum ist diese laufende Nummer genau so aufgebaut? Welche Kombinationen sind erlaubt und welche nicht? Was passiert, wenn eine einzige Vereinbarung mehrere Personen umfasst? Welche bestehenden Dokumente bestimmen mit, welche Nummer als Nächstes folgt, und wer darf entscheiden, dass eine Ausnahme doch erlaubt wird? Dann zeigt sich: Du automatisierst kein Word-Dokument. Du formalisierst einen Prozess, der jahrelang teils in Dateien und teils im Kopf von Menschen gelebt hat.

Software ist ziemlich gut darin, Regeln auszuführen. Die Schwierigkeit liegt darin, festzustellen, welche Regeln wirklich existieren. Wer eine Routine manuell ausführt, bemerkt selten, wie viele implizite Entscheidungen er dabei unterwegs trifft: dass eine bestehende Nummer nie erneut verwendet wird, dass ein bestimmter Kunde immer ein kleines bisschen anders behandelt wird, dass eine bestimmte Kombination „nicht vorkommt“ — bis sie jemand eines Tages doch eingibt. Solange ein Mensch den Prozess ausführt, füllt Erfahrung diese Lücken. Software tut das nicht. Und genau das macht sie nützlich: Eine gute Automatisierung zwingt dich dazu, „normalerweise machen wir das so“ durch eindeutige Regeln zu ersetzen, die sich anwenden und testen lassen. Dann muss feststehen, was verpflichtend ist, was blockiert wird, was eindeutig bleiben muss, welche Daten maßgeblich sind und was passiert, wenn ein Schritt fehlschlägt.

Erst danach wird Technologie interessant. Ein Tool, das in einer Demo zwanzig Sekunden spart, nützt mir wenig, wenn ich nicht sicher weiß, ob zwei Nutzer dieselbe laufende Nummer bekommen können oder ob bestehende Daten bei einer Übertragung überschrieben werden. Deshalb schaue ich mir bei internen Tools zuerst an, was auf keinen Fall passieren darf. Ein Button, der funktioniert, hat wenig Wert, wenn die Ausnahmen daneben unzuverlässig sind.

Das bestimmt auch, wie ich KI bei einem solchen Vorhaben einsetze. Ein Modell kann helfen, Code zu schreiben, Testfälle vorzuschlagen, einen Entwurf infrage zu stellen oder Szenarien aufzudecken, an die niemand gedacht hatte. Nützlich. Aber „die KI hat den Code gemacht“ sagt nichts über die Qualität des Ergebnisses aus. Wo eine Geschäftsregel feststehen muss, darf ein Modell nicht stillschweigend schätzen, welcher Typ, welche Nummer oder welche Sprache zutrifft. Was zählt, ist, ob dieselbe Eingabe jedes Mal das beabsichtigte Ergebnis liefert, ob Fehler blockiert werden, bevor sie Daten beschädigen, und ob es Tests für Verhalten gibt, das erhalten bleiben muss.

Nicht jedes menschliche Urteil muss dabei verschwinden. Manche Entscheidungen behältst du bewusst bei einem Nutzer. Wenn ein Tool zehn Handlungen übernimmt und eine wichtige Entscheidung bei einem Menschen lässt, ist das oft besser, als elf Handlungen zu automatisieren und zu hoffen, dass die elfte immer gutgeht. Automatisieren heißt für mich nicht, möglichst viele Schritte zu entfernen, sondern Routine zuverlässig wegzunehmen, ohne dabei gleichzeitig die Kontrolle wegzuautomatisieren.

Dasselbe gilt für das, was bereits existiert. Ein neues Tool bekommt selten ein leeres Spielfeld: Es gibt Dokumente, Nummern, Akten und Gewohnheiten von vor dem Tool, und die gehören zum Problem dazu. Eine funktionierende Automatisierung muss nicht nur wissen, was morgen passieren soll. Sie muss auch respektieren, was gestern bereits passiert ist.

Deshalb beginne ich lieber mit einer unangenehmen Frage: Was darf dieses Tool auf keinen Fall falsch machen? Solange es darauf keine klare Antwort gibt, sind wir noch nicht bereit zu automatisieren.