Ein KI-Werkzeug für die Angebots­bearbeitung entwickeln und übergeben

Der Anwendungs­fall stammt aus einer Potenzial­analyse im Vertrieb und ist dort der am besten begründete. Zu einer Kundenanfrage oder einer Ausschreibung gehören Dutzende Dokumente mit umfangreichen technischen Spezifikationen; entscheidungs­relevant sind wenige Seiten. Die Dokumente haben keine einheitliche Struktur und keine sprechenden Dateinamen, sodass das Zusammensuchen der Angaben für die Bid- oder No-bid-Entscheidung im Vertrieb Zeit bindet, die dort knapp ist. Die Make-or-Buy-Prüfung fällt auf Make. Beauftragt ist die Entwicklung eines Werkzeugs zur Extraktion der Angaben aus Anfrage­dokumenten, in Sprints, von der fachlichen und technischen Anforderungs­erhebung über das Lösungs­konzept bis zu Produkt­ivsetzung, Übergabe an die eigene IT und Schulung der Mitarbeitenden im Vertrieb. Ein Jahr später folgte auf Grundlage eines gemeinsam abgestimmten Lastenhefts die Architektur für den Dauerbetrieb.

Der Fall kam aus der Analyse, nicht aus dem Katalog. Er war nicht der technisch reizvollste der drei Anwendungs­fälle, sondern der mit der klarsten Begründung: eine Tätigkeit, die täglich anfällt, deren Ergebnis eine Entscheidung ist, und deren Aufwand vollständig im Suchen liegt. Solche Fälle eignen sich für Umsetzungs­projekte, weil der Nutzen am ersten Tag sichtbar ist und niemand ihn erklären muss.

Semantische Suche statt Volltextsuche, weil die Anfragen nicht dieselben Wörter benutzen. In technischen Spezifikationen steht dieselbe Anforderung in jedem Dokument anders. Eine Suche nach Begriffen findet deshalb entweder nichts oder alles. Die Aufnahmestrecke übersetzt die Unterlagen daher in Vektoren, und die Suche arbeitet auf Bedeutungs­nähe mit einer Rangfolge. Das Sprachmodell formuliert erst danach, auf Basis der gefundenen Stellen. Diese Reihenfolge ist der Unterschied zwischen einer belegten Antwort und einer erfundenen.

Zwei Stufen mit einem Jahr Abstand, und die zweite hatte ein Lastenheft. Die erste Beauftragung führte von der Anforderungs­erhebung über das Lösungs­konzept zur Umsetzung im Vertrieb. Für die Architektur des Dauerbetriebs wurde ein Jahr später ein gemeinsam abgestimmtes Lastenheft geschrieben und danach entwickelt. Das ist kein Umweg. Ein Lastenheft für ein KI-System lässt sich sinnvoll erst schreiben, wenn man an einem ersten Stand gesehen hat, welche Fragen die Nutzer wirklich stellen.

Entwickelt wird spezifikations­getrieben, und der Code entsteht KI-gestützt. Am Anfang jeder Umsetzung steht eine Spezifikation: ein versioniertes Dokument, das wie Code geprüft wird, für Technik und Fachbereich gleichermaßen lesbar, in dem Entscheidungen, Sonderfälle und Abwägungen geklärt sind, bevor eine Zeile entsteht. Die Architektur wird nach einem etablierten Rahmenwerk dokumentiert. Der Grund für diese Reihenfolge ist nicht Ordnungsliebe, sondern Prüfbarkeit: Erzeugter Code wächst schneller, als die Zeit reicht, ihn zu lesen. Wer einem Modell nur beschreibt, was er ungefähr will, bekommt schnell Code und bei jedem Durchlauf einen anderen. Die Spezifikation ist zugleich die Dokumentation, die sonst am Ende fehlt — und weil das Werkzeug als lauffähiger Container an die eigene IT ging, ist sie der Teil der Lieferung, der nach uns weiterhilft.

Als Container übergeben, damit die eigene IT es betreiben kann. Die Bewertung der Infrastruktur hatte gezeigt: starker Fokus auf den eigenen Betrieb, erste Erfahrungen mit containerisierten Anwendungen vorhanden. Genau darauf wurde ausgeliefert, mit technischer Dokumentation, Funktions- und Schnittstellen­tests und Unterstützung bei der Einbindung. Ein Werkzeug, das nur beim Dienstleister läuft, erzeugt eine Abhängigkeit, die bei einem Familien­unternehmen mit eigener IT niemand will.

Zwei Sprachen, weil das Geschäft zwei Sprachen hat. Die Anfragen kommen aus Europa, dem Nahen Osten und Asien. Ein Werkzeug, das nur deutsche Unterlagen liest, hilft im halben Geschäft. Die Zweisprachigkeit wurde deshalb ausdrücklich vereinbart, mit einem gedeckelten Rahmen für die notwendigen Anpassungen. Das gehört zur Ehrlichkeit eines solchen Projekts: Ein System, das eine Sprache beherrscht, beherrscht nicht automatisch die zweite.