Auf einen Blick

• Kunde: Global tätiges B2B-Medizintechnikunternehmen, Unternehmensebene und Ländermärkte

• Ausgangslage: Ein produktiver KI-Agent für Text und Übersetzung, der pro Durchlauf nur ein einzelnes Asset erzeugt und sich nur mit hohem Aufwand erweitern lässt

• Aufgabe: Die Anforderungen an eine skalierbare KI-Infrastruktur für Kundenkommunikation definieren und in den Märkten absichern

• Unsere Rolle: Fit-Gap-Analyse, verantwortliches Requirements Engineering, Markt-Workshops, Executive Consulting auf Unternehmensebene

• Ergebnis: Eine detaillierte, in drei Märkten validierte Requirements-Dokumentation entlang von fünf Prozessphasen und drei Architektur-Layern als Grundlage für die technische Umsetzung

Ausgangslage: Ein KI-Agent, der funktioniert – und trotzdem an Grenzen stößt

Das Unternehmen setzte generative KI im Marketing bereits produktiv ein. Ein interner KI-Agent unterstützte die Marketingverantwortlichen in den Ländern dabei, Texte zu erstellen und zu übersetzen. Die Lösung war im Einsatz und wurde genutzt.

Im Alltag zeigte sich jedoch, dass der Agent die tatsächliche Kommunikation der Märkte nur unvollständig abbildete:

• Ein Asset, ein Produkt: Pro Durchlauf entstand genau ein Asset zu genau einem Produkt. Die Märkte arbeiten aber mit Kampagnen über mehrere Produkte und mit Event-Strecken aus Einladung, Reminder und Follow-up.

• Jede Korrektur startet von vorn: Änderungen führten zur Neugenerierung des gesamten Assets. Das Review lief über statische PDFs.

• Medienbrüche bis zur Freigabe: Die regulatorische Freigabe lag in einem separaten System, was viel manuelle Dateneingabe bedeutete. Das Publishing war nur teilweise automatisiert.

• Kein Lernen aus Ergebnissen: Es gab keinen Rückfluss von Kampagnendaten in Briefing und Content-Erstellung.

Dazu kam Zeitdruck: Ein zentrales System für Briefing und Projektsteuerung sollte abgelöst werden, und damit fiel das bisherige führende System für den gesamten Ablauf weg.

Die eigentliche Herausforderung: Das Problem lag in der Architektur, nicht in fehlenden Features

Naheliegend wäre gewesen, den bestehenden Agenten um weitere Funktionen zu erweitern. Unsere Analyse zeigte, warum das nicht trägt: Geschäftslogik, Nutzerinteraktion und Systemanbindung liefen alle direkt im Agenten zusammen. Jede Erweiterung erforderte Umprogrammierung, und das Wissen darüber lag bei sehr wenigen Personen.

Damit stellte sich eine grundsätzlichere Frage: Welche Architektur braucht ein Unternehmen, damit KI-Agenten in der Kundenkommunikation skalieren, über Märkte, Kanäle und Anwendungsfälle hinweg, ohne dass Governance und Markenkontrolle verloren gehen?

Unser Ansatz: Von der Analyse bis zur übergabefähigen Anforderung

1. Fit-Gap-Analyse der bestehenden KI-Lösung und der angrenzenden Systeme

Am Anfang stand eine strukturierte Bestandsaufnahme entlang der gesamten Prozesskette: Briefing, Content-Erstellung, Asset-Auswahl, Review, Freigabe, Publishing und Analytics. Für jede Phase haben wir das führende System, die Übergaben zwischen Systemen und Menschen sowie die zentralen Pain Points dokumentiert und gemeinsam mit den Beteiligten priorisiert.

Das Ergebnis war eine klare Unterscheidung: Was leistet die bestehende Lösung gut und bleibt erhalten? Wo fehlen Funktionen? Und wo fehlt eine ganze Architekturschicht? Der Agent blieb als leistungsfähige Content-Engine gesetzt. Eine einheitliche Bedienoberfläche oberhalb der Tools fehlte dagegen vollständig, und ebenso eine Logik, die die einzelnen Schritte steuert.

2. Requirements Engineering für eine Multi-Layer-Architektur

Wir haben die Verantwortung für das Requirements Engineering der neuen Zielarchitektur übernommen. Sie trennt drei Ebenen sauber voneinander:

• Interface Layer: eine einheitliche Oberfläche für Briefing, Vorschau, Bearbeitung und Freigabe

• Orchestration Layer: die Steuerung, welcher Agent, welcher Service oder welcher Mensch als Nächstes übernimmt, einschließlich Rework-Schleifen

• Agenten und Skills: spezialisierte Bausteine, etwa für strukturiertes Briefing, Content-Erstellung oder die Prüfung von Marken- und Produktaussagen

Die Basis bildet eine durchgängige Data Foundation mit Learning Loop, aus der jede Phase Daten bezieht und in die jede Phase zurückschreibt.

Zwei Werkzeuge haben sich dabei als entscheidend erwiesen. Erstens eine gemeinsame Sprache: Zehn Kernbegriffe von „Agent“ über „Skill“ bis „Orchestration“ haben wir vorab mit dem Kunden definiert und abgestimmt. Die KI-Definition folgt dem EU AI Act. Zweitens Design Cards: Für jeden geplanten Agenten und Skill beantworten sie dieselben Fragen zu Aufgabe, Nutzer, Inputs, Guardrails, Output, Rolle des Menschen und Lernmechanismus. So werden Annahmen testbar, bevor sie im Code landen.

3. Markt-Workshops: Anforderungen dort validieren, wo sie entstehen

Eine Architektur für globale Kundenkommunikation lässt sich nicht aus der Zentrale heraus spezifizieren. Deshalb haben wir die Anforderungen in Co-Creation-Workshops mit drei internationalen Ländermärkten entwickelt. Diese Märkte sind zugleich die künftigen Anwender.

Jeder Markt durchlief zwei Sessions. Im Kick-off wurden Zielbild, Begriffe und Arbeitsboard eingeführt, danach kommentierten die Teilnehmenden die Journey und die Design Cards asynchron. In der Co-Creation-Session haben wir die Journey Phase für Phase gegen die Marktrealität geprüft, Oberflächen mit kurzen Live-Coding-Elementen konkretisiert und Übergaben sowie Guardrails gemeinsam geschärft. Methodisch stützten wir uns auf Lean UX und Assumption Mapping.

Die Märkte haben wir bewusst nacheinander eingebunden. So wurden Einzelsignale Schritt für Schritt zu marktübergreifend bestätigten Anforderungen, zum Beispiel:

• eine nahezu finale visuelle Vorschau schon während der Erstellung

• modulare Bearbeitung einzelner Bausteine statt kompletter Neugenerierung

• eine durchgehend sichtbare Prüfung von Marken- und Produktaussagen statt einer einmaligen Kontrolle am Ende

• marktspezifisch freigegebene Aussagen, denn Formulierungen, die global gelten, sind nicht automatisch in jedem Land zulässig

• Content-Erstellung direkt in der Landessprache statt Übersetzung eines englischen Entwurfs

• ein funktionierender Rückfluss von Kampagnendaten in künftige Empfehlungen

Eine wichtige Erkenntnis: Die Märkte widersprachen sich nicht, sie setzten unterschiedliche Schwerpunkte. Ein Markt steuert zum Beispiel primär über Leads, ein anderer über die Bewertung einzelner Kampagnen. Wir haben diese Gewichtungen transparent nebeneinandergestellt, statt sie künstlich aufzulösen.

4. Executive Consulting auf Unternehmensebene

Parallel haben wir die Verantwortlichen auf Unternehmensebene beraten. Im Kern ging es darum, einen Proof of Concept klar von einer späteren Build-Entscheidung zu trennen, mit einem expliziten Entscheidungs-Gate dazwischen. Außerdem haben wir den Scope sauber abgegrenzt: 13 Themen, von der Zielgruppensegmentierung bis zur Mehrkanal-Ausspielung, sind bewusst als „out of scope“ dokumentiert und als Kandidaten für spätere Iterationen bewertet. So kann das Entscheidungsgremium auf einer klaren Grundlage entscheiden, statt Erwartungen stillschweigend wachsen zu lassen.

Das Ergebnis: Eine markt-validierte Requirements-Dokumentation für die technische Umsetzung

Übergeben haben wir eine detaillierte Requirements-Dokumentation, strukturiert nach fünf Phasen der Referenz-Journey (Briefing, Content-Erstellung, Review und Freigabe, Publishing, Analytics) und jeweils nach den drei Architektur-Layern. Jede Anforderung enthält:

• eine eindeutige ID und die Rückverfolgbarkeit zu Markt und Workshop

• Akzeptanzkriterien aus Business-Sicht

• eine Einordnung in „Proof of Concept“ oder „Iterations-Backlog“

Ergänzt wird die Dokumentation durch ein Register der Datenquellen und Datenverantwortlichen sowie durch die dokumentierten Out-of-Scope-Themen. Die technische Umsetzung kann damit direkt weiterarbeiten, und das Management hat eine belastbare Grundlage für die Entscheidung über den Scope.

Was andere Unternehmen daraus mitnehmen können

• Erst die Architektur, dann die Features. Wenn Logik, Oberfläche und Integration in einem Agenten gebündelt sind, macht jede neue Funktion die Lösung teurer. Skalierung entsteht durch die Trennung der Layer.

• Eine gemeinsame Sprache ist Voraussetzung. Ohne abgestimmte Begriffe reden Marketing, IT und Compliance über unterschiedliche Dinge.

• Anforderungen entstehen in den Märkten. Die Zentrale kennt das Zielbild, die Märkte kennen die Ausnahmen, und an den Ausnahmen entscheidet sich, ob eine Architektur trägt.

• Governance gehört in den Prozess, nicht ans Ende. In regulierten B2B-Branchen muss die Prüfung von Marken- und Produktaussagen fester Teil des Ablaufs sein.

• Auch „Out of Scope“ ist ein Deliverable. Eine klare Scope-Grenze schützt den Proof of Concept und macht das Backlog planbar.