Der Fachbereich als Product Owner: KI-Projekte aus dem Business heraus steuern

Wenn ein Unternehmen ein KI-Projekt startet, landet die Steuerung fast reflexhaft bei der IT. Das wirkt logisch: Es geht um Software, also soll sich die IT darum kümmern. In der Praxis führt genau diese Zuordnung zu einem wiederkehrenden Muster. Das Projekt liefert technisch saubere Ergebnisse, die am Alltag vorbeigehen, weil niemand im Projektteam wusste, dass die Eingangsrechnungen von drei Lieferanten grundsätzlich anders aufgebaut sind oder dass die wichtigste Ausnahme im Prozess nirgends dokumentiert ist.

Die Alternative ist ein Product Owner aus dem Fachbereich: Die Person, die den Prozess täglich lebt, priorisiert das Projekt und entscheidet, was gut genug ist. Nicht weil die IT es schlechter meinen würde, sondern weil sie eine bestimmte Sorte Wissen nicht haben kann. Und dieses Wissen ist in KI-Projekten die knappste Ressource überhaupt.

Warum Wissen über Sonderfälle die knappste Ressource ist

Klassische Software wird über Regeln spezifiziert, und Regeln kann man aufschreiben und übergeben. KI-Systeme werden dagegen über Beispiele und Bewertungen geformt: Welche Antwort ist richtig, welche knapp daneben, welche gefährlich falsch. Diese Bewertungen kann nur jemand abgeben, der den Prozess kennt, und zwar nicht den dokumentierten Prozess, sondern den echten, mit all seinen Ausnahmen.

Genau dort entscheidet sich die Qualität. Die Standardfälle beherrscht ein KI-System meist schnell. Die Sonderfälle, die vielleicht einen kleinen Teil des Volumens ausmachen, aber den Großteil des Ärgers verursachen, kennt nur der Fachbereich. Der Sachbearbeiter, der seit Jahren weiß, dass eine bestimmte Formulierung im Kundenschreiben fast immer eine Reklamation ankündigt, trägt Wissen, das in keinem Dokument steht. Ein Projekt, das diesen Menschen nicht in eine steuernde Rolle bringt, verschenkt seinen wertvollsten Rohstoff.

Die konkreten Aufgaben des fachlichen Product Owners

Die Rolle ist kein Ehrentitel, sondern ein Bündel konkreter Tätigkeiten.

• Priorisieren: entscheiden, welcher Teilprozess zuerst umgesetzt wird und welche Anforderung warten kann. Das verlangt, Nein zu sagen, auch zu Wünschen aus dem eigenen Bereich.
• Beispieldaten liefern: echte, repräsentative Fälle zusammenstellen, inklusive der unangenehmen. Ein Prüfdatensatz aus lauter einfachen Fällen erzeugt ein System, das nur einfache Fälle kann.
• Ergebnisse bewerten: regelmäßig Ausgaben des Systems durchsehen und markieren, was brauchbar ist und was nicht. Diese Rückmeldungen sind das Steuerrad des Projekts.
• Abnehmen: am Ende entscheiden, ob das System in den Echtbetrieb darf. Diese Entscheidung ist fachlich, nicht technisch, und gehört deshalb in diese Rolle.
• Ins Team übersetzen: den Kollegen erklären, was kommt, ihre Einwände einsammeln und ins Projekt zurücktragen.

Wie viel Zeit die Rolle wirklich kostet

Der häufigste Fehler bei der Besetzung ist nicht die falsche Person, sondern das fehlende Zeitbudget. Ein fachlicher Product Owner, der die Rolle zusätzlich zu einem vollen Tagesgeschäft ausüben soll, wird zum Engpass des gesamten Projekts: Der Dienstleister wartet auf Bewertungen, Entscheidungen stapeln sich, und am Ende entscheidet doch wieder der Externe allein.

Als grobe Orientierung aus der Praxis: In intensiven Projektphasen, etwa während der Erprobung mit echten Daten, ist ein Aufwand von etwa einem Tag pro Woche realistisch. In ruhigeren Phasen genügt oft die Hälfte. Wichtiger als die genaue Zahl ist, dass die Geschäftsführung diesen Aufwand ausdrücklich freigibt und im Tagesgeschäft kompensiert. Eine Rolle, für die man sich Zeit stehlen muss, wird nicht ausgeübt.

Grenzen der Rolle und typische Konflikte

Der fachliche Product Owner entscheidet nicht alles. Technische Architektur, Werkzeugwahl und Umsetzungsdetails liegen beim Dienstleister und beim technischen Ansprechpartner. Fragen der Datennutzung und des Datenschutzes brauchen eigene Zuständige. Und Budgetentscheidungen über den vereinbarten Rahmen hinaus bleiben bei der Geschäftsführung. Die Rolle steuert das Was und das Wozu, nicht das Wie.

An zwei Nahtstellen entstehen erfahrungsgemäß Konflikte. Der erste verläuft zur IT: Sie empfindet es mitunter als Übergriff, wenn der Fachbereich ein Softwareprojekt steuert. Das Lösungsmuster ist eine saubere Trennung der Zuständigkeiten, am besten schriftlich: Der Fachbereich verantwortet Anforderungen und Abnahme, die IT verantwortet Betrieb, Sicherheit und Integration, und keine Seite überstimmt die andere in ihrem Feld.

Der zweite Konflikt verläuft zur Geschäftsführung, die gern spontan neue Wünsche ins Projekt gibt und damit jede Priorisierung entwertet. Hier hilft ein einfacher Mechanismus: Neue Anforderungen sind willkommen, laufen aber ausnahmslos über die Priorisierung des Product Owners und verdrängen sichtbar etwas anderes. Wer die Rolle eingesetzt hat, muss ihre Entscheidungen auch dann tragen, wenn sie unbequem sind. Ein Product Owner, der regelmäßig übersteuert wird, ist nur noch Dekoration.

Fazit

KI-Projekte werden dort gut, wo die Menschen mit dem tiefsten Prozesswissen die Richtung vorgeben. Ein Product Owner aus dem Fachbereich bringt genau das ein: Wissen über Sonderfälle, verlässliche Bewertungen und eine Abnahme, die den Alltag ernst nimmt. Damit die Rolle funktioniert, braucht sie ein ehrliches Zeitbudget, klare Grenzen zur IT und Rückendeckung der Geschäftsführung gegen ihre eigenen Zwischenrufe. Der Rest ist Handwerk. Die Frage ist also nicht, ob sich der Fachbereich ein KI-Projekt zutrauen darf. Die Frage ist, ob das Unternehmen es sich leisten kann, sein wertvollstes Wissen draußen zu lassen.