Wie aus einer KI-Ideenliste ein steuerbares Portfolio wird

Wenn du KI-Vorhaben über Abteilungsgrenzen hinweg steuerst, braucht jeder Use Case einen fachlich verantwortlichen Owner und eine anstehende Entscheidung. Im Steering schaue ich zuerst auf Fälle ohne Owner, danach auf belastbare Quick Wins. Anschließend prüfe ich die Belege hinter den Prioritäten und ordne offene Fragen zu. Wer auf das Portfolio zugreifen darf, entscheide ich über reviewten Code, weil schon die erfassten Bedarfe sensibel sein können.

Ich lasse mir beschreiben, welcher Arbeitsablauf sich ändern soll und woran die Abteilung eine Verbesserung erkennen würde. Bei einem vorgeschlagenen Assistenten frage ich nach der Arbeit dahinter: Wer würde ihn verwenden, und welches Ergebnis würde diese Person akzeptieren?

Für die Priorisierung stelle ich den erwarteten Nutzen dem Lieferaufwand gegenüber. Die Belege bleiben bei der Einschätzung. Fehlt die Beobachtung, auf der eine Schätzung beruht, kennzeichne ich die Unsicherheit. Gemeinsame Abhängigkeiten halte ich ebenfalls fest, damit im Steering erkennbar wird, welche Vorhaben eine fehlende Fähigkeit blockiert.

Der Enterprise-AI-Readiness-Check hilft, Voraussetzungen vor einer Lieferzusage zu prüfen. Was noch ungeklärt ist, landet als zugeordnete Aufgabe im Portfolio.

Zuerst öffne ich die Ansicht der Fälle ohne Owner. Dort steht die Entscheidung an, Verantwortung zuzuweisen oder das Vorhaben zu parken. Auch ein hoch eingeschätzter Nutzen ersetzt niemanden, der das Ergebnis fachlich abnehmen kann.

Danach kommen die Quick Wins samt Belegen. Diesen Status vergebe ich, wenn der Umfang begrenzt ist und die Voraussetzungen geprüft sind. Ein vermeintlich kleiner Aufwand reicht dafür nicht aus. Solange eine Abhängigkeit offen ist, kann auch eine einfache Idee liegenbleiben. Der Eintrag muss erkennen lassen, warum der Status vergeben wurde.

Über eine Abteilungsansicht prüfe ich anschließend, ob die Auswahl Lücken im übrigen Portfolio verdeckt. Für die Abwägung nutze ich eine Impact/Effort-Ansicht; ein gemeinsamer Filterzustand hält die besprochenen Fälle zusammen. Die Entscheidung zum jeweiligen Fall kommt ins Steering-Protokoll.

Ich unterscheide zwischen geprüften Belegen und Annahmen, auf die noch eine Antwort fehlt. Im Portfolio muss sichtbar sein, wo die Evidenzabdeckung endet und welche Quelle eine Einschätzung stützt. Ein angehängtes Dokument reicht dafür erst, wenn sein Inhalt auch auf die Nutzenbehauptung geprüft wurde.

Offene Follow-ups sammle ich in einer gemeinsamen Ansicht mit zuständigen Personen. Ich formuliere sie als Fragen, die sich mit einem Beleg schließen lassen, und halte fest, bis wann die Antwort gebraucht wird. Im nächsten Review prüfe ich, ob die Antwort den Status des Vorhabens verändert.

Geht es um den Lieferweg, nutze ich die Entscheidungshilfe Build vs Buy vs Partner. Die gewählte Richtung und ihre verbleibenden Abhängigkeiten gehören anschließend wieder in den Use Case.

Schon ein Bedarfseintrag kann Abteilungspläne oder ungeklärte Bedenken offenlegen. Deshalb trenne ich die Frage nach dem Zugang zum Portfolio von der Rolle innerhalb der Anwendung. Änderungen an Mitgliedschaften gehen durch ein Code-Review, damit die Entscheidung für spätere Maintainer nachvollziehbar bleibt.

Der Merge gibt die Änderung frei. Sie muss auch für bereits geöffnete Sessions wirksam werden, sonst kann der fortbestehende Zugriff von der geprüften Entscheidung abweichen. Bei der Übergabe halte ich fest, wer Zugriffsänderungen prüft und wo die Freigabe dokumentiert ist.

Diese Felder halte ich pro Use Case fest. Zu jedem Feld gehört eine Frage und die Zuständigkeit für die Antwort.

Arbeitsablauf und beabsichtigtes Ergebnis Wessen Arbeit soll sich ändern, und welche beobachtbare Verbesserung rechtfertigt das Vorhaben? Der fachliche Owner beschreibt das Ergebnis und legt fest, wie es abgenommen wird.

Verantwortlicher Owner Wer darf die Abteilung auf den nächsten Schritt festlegen? Die Abteilungsleitung benennt die Person oder kennzeichnet den Fall als unbesetzt.

Nutzen und Aufwand Welcher Nutzen ist plausibel, und welche Lieferarbeit steht ihm gegenüber? Der fachliche Owner belegt die Nutzenerwartung; der Delivery Lead hält Aufwand und Unsicherheit fest.

Voraussetzungen und Lieferweg Was muss vor dem Start verfügbar sein, und wie könnte die Fähigkeit bereitgestellt werden? Der Delivery Lead dokumentiert die Abhängigkeiten und die offene Build-, Buy- oder Partner-Entscheidung.

Evidenzabdeckung Welche Annahmen sind geprüft, und wo liegen die Belege zur Einsicht? Der Case Owner verlinkt die Quellen und benennt die offenen Annahmen.

Status und nächste Entscheidung Ist ein begrenzter nächster Schritt möglich, wartet der Fall auf eine Abhängigkeit oder ist er geparkt? Die Steering-Leitung dokumentiert die Entscheidung samt Bedingung für eine erneute Vorlage.

Offenes Follow-up Welche Frage verhindert die nächste Entscheidung, wer beantwortet sie und bis wann? Die zuständige Person liefert die Antwort mit einem Beleg.

Zugriffsprüfung Wer soll den Eintrag sehen oder ändern können, und wo wurde das genehmigt? Der Portfolio-Maintainer verlinkt die reviewte Zugriffsentscheidung.

Der folgende ausgefüllte Eintrag ist hypothetisch und beschreibt kein Kundenvorhaben.

Arbeitsablauf und beabsichtigtes Ergebnis: Ein Schulungsteam möchte freigegebene Lernmaterialien leichter finden. Der fachliche Owner würde das Ergebnis abnehmen, wenn das Team im Arbeitsablauf die passende freigegebene Quelle abrufen kann.

Verantwortlicher Owner: Die Schulungsleitung übernimmt die Verantwortung für die nächste Entscheidung.

Nutzen und Aufwand: Erwartet wird weniger Sucharbeit. Der Delivery Lead lässt den Aufwand offen, bis das Ausgangsmaterial geprüft ist.

Voraussetzungen und Lieferweg: Die Verfügbarkeit freigegebener Unterlagen ist ungeklärt. Bis diese Abhängigkeit geklärt ist, vertagt der Delivery Lead die Wahl des Lieferwegs.

Evidenzabdeckung: Der Bedarf beschreibt den gewünschten Arbeitsablauf. Ob die Unterlagen dafür verwendbar sind, ist noch unbelegt; der Case Owner hält diese Lücke sichtbar.

Status und nächste Entscheidung: Wartet auf Belege. Die Steering-Leitung vergibt den Quick-Win-Status erst nach Prüfung der Quellen.

Offenes Follow-up: Die Schulungsleitung klärt vor dem nächsten Steering, welches Material freigegeben ist, und ergänzt den Quellenverweis.

Zugriffsprüfung: Vor dem Teilen dokumentiert der Portfolio-Maintainer die reviewte Entscheidung darüber, wer den Eintrag lesen und bearbeiten darf.

Ein Portfolio-Review belegt noch nicht, dass eine KI-Anwendung im Betrieb zuverlässig arbeitet. Für das ausgewählte Vorhaben bleibt eine Evaluation anhand der vorgesehenen Nutzung nötig. Der fachliche Owner muss deren Ergebnisse vor der weiteren Lieferung abnehmen.

Auch fehlende Befugnisse kann die Vorlage nicht ausgleichen. Darf niemand im Termin einen Owner benennen oder Mittel zusagen, halte ich die nötige Entscheidung fest und benenne, wer beim nächsten Review dabei sein muss.

Im Rahmen von Beratung & Sprints biete ich ein AI-Readiness- oder Portfolio-Review an. Du erhältst eine Bewertung der Entscheidungslücken und geprüfte Prioritäten. Für die noch fehlenden Belege werden Follow-ups mit Zuständigkeiten festgehalten. Vor Beginn vereinbaren wir, welche Führungsentscheidungen das Review vorbereiten soll.

Den Auftrag hinter dieser Praxisnotiz beschreibe ich im AI-Compass-Abschnitt der Bahlsen-Fallstudie.