B2B / Distribution
Ein wiederkehrender Vertragsprozess mit mehreren Marken, Vertragsformen und Sprachen wurde in ein internes Tool umgesetzt. Nicht indem das bestehende Dokument digitalisiert wurde, sondern indem zuerst Regeln, Ausnahmen, Nummerierung und historische Daten explizit gemacht wurden — und danach vor allem das getestet wurde, was auf keinen Fall schieflaufen durfte.
Die Ausgangssituation
Der Prozess funktionierte. Verträge wurden aus bestehenden Vorlagen erstellt, Angaben wurden eingetragen, die richtige Version wurde gewählt, und Dokumente fanden ihren Platz im Archiv. Das funktionierte, weil diejenige Person, die den Prozess ausführte, auch wusste, wie er aufgebaut war. Nur stand nicht jede Regel irgendwo beschrieben.
Es gab mehrere Marken, verschiedene Vertragsarten und mehrere Sprachen. Laufende Nummern mussten korrekt an die bestehende Historie anschließen, bestimmte Kombinationen waren ausdrücklich nicht erlaubt, und bestehende Daten sowie bereits vergebene Nummern durften nicht gefährdet werden. Solange alles manuell geschieht, fängt Erfahrung diese Komplexität auf. Bei Automatisierung verschwindet dieser Sicherheitsspielraum.
Die geschäftliche Fragestellung
Die erste Frage klingt einfach: Können wir aus mehreren Eingaben automatisch den richtigen Vertrag erstellen? Technisch ist das nicht das Schwierigste. Die schwierigeren Fragen kamen davor: Welche Daten bestimmen, welches Dokument verwendet wird, welche Felder sind verpflichtend, welche Kombinationen müssen verhindert werden, wie behandelt man mehrere Personen innerhalb eines Vertrags, und wie verhindert man, dass zwei Aktionen dieselbe Vertragsnummer erhalten?
Einen Fehler in einem Social-Media-Beitrag behebt man. Ein Tool, das Vertragsnummern doppelt vergibt oder bestehende Registrierungen beschädigt, schafft eine andere Art von Problem. Deshalb wog Zuverlässigkeit von Anfang an schwerer als zusätzliche Funktionalität.
Die Entscheidungen
Das bestehende Verhalten wurde nicht sofort ersetzt. Zuerst wurde festgehalten, was heute korrekt ablief und welches Verhalten unbedingt erhalten bleiben musste. Die bestehenden Daten blieben der Ausgangspunkt — nicht etwas, das während der Entwicklung neu aufgebaut wurde, weil das einfacher war.
Geschäftsregeln mussten feststehen. Vertragstyp, Marke, Sprache, Nummerierung und erlaubte Kombinationen durften nicht von einem Modell abhängen, das „wahrscheinlich“ die richtige Interpretation traf. KI half bei Analyse, Entwicklung und Review; die Regeln selbst blieben explizit und überprüfbar.
Daraus ergab sich eine einfache Gestaltungsregel: Was nicht erlaubt ist, wird blockiert, bevor ein Dokument entsteht — nicht nachträglich gemeldet. Und für die Nummerierung galt eine harte Anforderung: Zwei Aktionen, auch gleichzeitige, dürfen niemals dieselbe Vertragsnummer ergeben.
Meine Rolle
Meine Rolle begann nicht beim Code. Zuerst wurde die bestehende Funktionsweise zerlegt: Dokumenttypen, Entscheidungen, Ausnahmen, historische Nummerierung und die Art, wie Daten gepflegt wurden. Daraus entstand eine explizite Beschreibung des Prozesses — die Regeln, an die sich das Tool in jedem Fall halten musste.
Danach wurde das Tool iterativ gebaut und getestet. KI wurde dabei in verschiedenen Rollen eingesetzt: Code erzeugen, Annahmen infrage stellen, Ausnahmen aufspüren und die Funktionsweise von einem zweiten Modell prüfen lassen. Wichtiges Verhalten wurde nicht nur visuell kontrolliert: Es entstanden automatisierte Tests für Regeln, die sich nicht verschieben durften, wenn später etwas am Tool geändert wurde. Dieses Testset wurde mit der Zeit mehr als eine nachträgliche Kontrolle. Es wurde zur Beschreibung des Verhaltens, das wir bewahren wollten.
Die Umsetzung
Die erste funktionierende Version lief lokal: eine einfache Oberfläche, die bestehenden Daten und die Dokumentenerstellung. Der Nutzer wählt aus, was benötigt wird; das Tool prüft die Eingabe, wendet die Regeln an, erstellt das Dokument und protokolliert, was geschehen ist.
Danach kamen die Situationen, die man in einer Demo leicht vergisst: mehrere Personen in einer Verarbeitung, bestehende Nummernreihen, Dokumentkonvertierung, ein Fehler in einem Programm, von dem das Tool abhing. Jedes Mal ging es nicht nur darum, ob wir es wieder zum Laufen brachten, sondern auch, ob derselbe Fehler später unbemerkt zurückkommen konnte. Korrekturen wurden deshalb, wo möglich, von Tests und einer separaten Überprüfung des betroffenen Verhaltens begleitet.
Als eine Online-Version zur Sprache kam, wurden die lokalen technischen Entscheidungen nicht blind übernommen. Speicherung, Zugriff, Dateien und Dokumentkonvertierung wurden für die Webumgebung neu entworfen, weil das, was lokal gut funktioniert, nicht automatisch eine gute Serverlösung ist. Die Regel blieb dieselbe: erst das Verhalten festlegen, erst danach die Plattform ändern.
Bewusst nicht gemacht
Kein Chatbot rund um einen Prozess gebaut, der vor allem feste Regeln brauchte. Keine KI entscheiden lassen, welche Vertragsregeln „wahrscheinlich“ zutrafen. Keine bestehenden Daten neu aufgebaut oder Nummerierung zurückgesetzt, weil das die Entwicklung einfacher gemacht hätte. Keine Korrektur als gelungen betrachtet, nur weil das Dokument einmal erneut erzeugt werden konnte. Keine Online-Version entworfen, indem einfach die lokalen Entscheidungen übernommen wurden. Und keine Automatisierung hinzugefügt, nur weil sie technisch möglich war.
Das Tool sollte Zeit sparen. Aber nicht, indem es die Kontrolle über den Prozess aufgab.