KI-Anwendungs­fälle konzipieren und daraus die Ziel­architektur ableiten

Ein international tätiges Familien­unternehmen für Futtermittelzusatzstoffe hat drei KI-Anwendungs­fälle priorisiert. Einen Assistenten für den Vertrieb, einen Wissens­assistenten für das Intranet und einen Controlling-Fall. Der übliche nächste Schritt wäre die Beschaffung einer Plattform gewesen. Die Geschäfts­führung will das ausdrücklich nicht. Vereinbart ist stattdessen, die drei Fälle zuerst fachlich zu validieren und zu schärfen, bevor in Technik und Infrastruktur investiert wird — und die Analyse der Daten- und System­landschaft zielgerichtet an diesen Konzepten auszurichten statt als Vollerhebung zu betreiben. Am Ende soll eine Planung stehen, die belastbar genug ist, um darauf eine Investitions­entscheidung zu gründen.

Erst das Fachkonzept, dann die Technik — bewusst andersherum. Der naheliegende Weg nach einem Anwendungs­fall-Workshop ist, die Plattform zu beschaffen und danach zu schauen, was darauf laufen soll. Hier wird umgekehrt vorgegangen: Zuerst werden die drei priorisierten Fälle fachlich ausgearbeitet, erst danach wird die Daten- und System­landschaft aufgenommen, und zwar entlang dieser Konzepte statt flächendeckend. Wer zuerst kauft, muss hinterher begründen, warum das Gekaufte passt.

Die Arbeitspakete sind einzeln bestellbar, und das ist keine Verkaufs­technik. Angeboten waren sechs Pakete, beauftragt wurden fünf: die drei Fachkonzepte, die Analyse der Daten­landschaft und die Umsetzungs­planung. Die Einrichtung der Plattform blieb ausdrücklich draußen. Für ein Haus, das keine dauerhafte Abhängigkeit von externen Partnern will, ist genau diese Teilbarkeit die entscheidende Eigenschaft eines Angebots — und für uns die ehrlichere Reihenfolge, weil sie uns zwingt, den Nutzen vor dem Umsatz zu zeigen.

Zu jedem Anwendungs­fall gehört eine verantwortliche Person im Haus. Vor dem ersten Termin standen sie fest: je eine für den Vertriebs­assistenten, den Wissens­assistenten und den Controlling-Fall, dazu eine aus der IT für die Daten­landschaft, und eine Projekt­leiterin als zentrale Ansprech­partnerin. Das klingt nach Organisation und ist inhaltlich: Ein Fachkonzept, das niemandem gehört, wird ein Dokument. Eines mit einer verantwortlichen Person wird ein Anforderungs­katalog.

Die Analyse der Daten­landschaft ist zielgerichtet, nicht vollständig. Eine vollständige Aufnahme aller Systeme und Datenquellen dauert Monate und veraltet währenddessen. Gefragt ist nur, was die drei Konzepte tatsächlich brauchen: welche Quellen sie lesen, welche Rechte daran hängen, welche Formate und welche Aktualität vorliegen. Der Umfang der Analyse folgt damit aus den Fachkonzepten — und das ist der zweite Grund, warum sie danach kommt und nicht davor.

Die Architektur­entscheidung steht am Schluss, weil sie erst dort begründbar ist. Zwischen eigenem Betrieb und hybridem Modell entscheidet nicht die Grundhaltung, sondern das, was die Konzepte an Datenzugriff, Vertraulichkeit und Last verlangen. Zusammen mit der Ressourcen­planung entsteht daraus eine Investitions­vorlage, die auf Zahlen aus dem eigenen Haus beruht und nicht auf einer Herstellerpräsentation.