Ihr Portfolio entscheidet nur, was schon fertig gedacht ist.

Ein Portfolio, das erst am Ende auftaucht

Der übliche Weg sieht so aus: Ein Fachbereich hat eine Idee. Daraus wird ein Konzept mit Anforderungen, dann ein Business Case, der den Nutzen begründet. Das Vorhaben wird angemeldet, das Gremium bewertet Budget, Ressourcen und Priorität, und erst nach der Freigabe beginnt die Arbeit. Das Portfolio ist in diesem Ablauf eine Prüfinstanz für fertige Pläne.

Ich habe das lange für richtig gehalten. Wer Geld ausgibt, soll begründen, wofür. Für eine ERP-Einführung oder eine neue Fertigungslinie stimmt das auch. Dort sind Nutzen, Umfang und Technik weitgehend bekannt, und die Investition ist groß genug, um sorgfältig geplant zu werden.

Bei den meisten KI-Ideen ist das anders. Ob der Nutzen eintritt, ob die Daten reichen, ob die Menschen die Lösung annehmen, weiß zu Beginn niemand. Trotzdem verlangen wir einen belastbaren Business Case, bevor jemand die Annahmen darin prüfen konnte. Die Zahlen, die dann entstehen, sind grobe Schätzungen. Die Entscheidung wird trotzdem auf dieser Grundlage getroffen.

Warum Vorhaben auf dem Weg durchs Gremium wachsen

Der aufwendige Freigabeweg hat eine Nebenwirkung, die selten jemand ausspricht. Wer weiß, dass er nur einmal durch das Gremium kommt, schreibt alles hinein, was er irgendwann brauchen könnte. Lieber jetzt die Integration, die Berechtigungen und jede weitere Funktionalität mit beantragen als in einem Jahr noch einmal anzutreten.

So wird jedes Vorhaben größer als nötig. Anforderungen werden festgelegt, bevor jemand genug weiß, um sie festzulegen. Aus Vermutungen werden Projektannahmen, an denen später der Erfolg gemessen wird.

Dazu kommt ein zweiter Effekt: Für einen kleinen Test lohnt sich der Weg durchs Gremium nicht, also wird er gar nicht erst beantragt. Was durchkommt, sind wenige große Vorhaben, die lange brauchen. Die Governance, die für bessere Entscheidungen sorgen soll, sorgt so dafür, dass weniger fertig wird. Das Problem ist dann nicht, dass viel geliefert wird und wenig wirkt. Es wird schon weniger geliefert.

Warum aus jedem MVP ein Wasserfall wird

Der zweite Mechanismus liegt in der Erfolgsmessung. Wenn ein Vorhaben am tatsächlichen Geschäftsnutzen gemessen wird, muss es vollständig umgesetzt werden, sonst lässt sich der Nutzen nicht nachweisen. Vollständig heißt: IT-Security, Datenzugriff, Berechtigungen, Schnittstellen, Betrieb. Das dauert Monate, bevor ein einziger Nutzer etwas sieht.

Viele Unternehmen nennen das dann MVP. Gebaut wird trotzdem ein Wasserfall, nur mit agilem Etikett. Die Teams arbeiten in Sprints, die Entscheidung darüber, was gebaut wird, ist aber längst gefallen. Agilität fehlt nicht in der Umsetzung. Sie fehlt davor.

Ein Beispiel: der Agent, der durch die Oberfläche führt

Nehmen wir ein komplexes System, das in vielen Unternehmen täglich benutzt wird, etwa im Einkauf. Die Eingabemaske hat Dutzende Felder, nur wenige Mitarbeitende bedienen sie sicher, es gibt Fehler, Rückfragen und Nacharbeit. Wer in diesem Prozess zu Hause ist, kommt schnell auf eine naheliegende Idee: Ein KI-Agent begleitet die Menschen durch die Oberfläche und sagt ihnen, was in welches Feld gehört.

Im klassischen Portfolio wird genau diese Lösung bewertet. Ein Business Case rechnet die Einsparung pro Vorgang hoch, dazu kommen Systemintegration, Berechtigungen und Security-Freigabe. Das Gremium genehmigt oder lehnt ab. Niemand fragt, ob der Agent überhaupt die richtige Antwort auf das Problem ist.

Genau diese Frage müsste im Portfolio jemand stellen: Halt, haben wir uns den gesamten Prozess angesehen? Brauchen wir die Oberfläche in ihrem heutigen Umfang überhaupt? Vielleicht lassen sich viele Daten automatisch ins System schreiben, ohne dass ein Mensch sie in eine Maske tippt. Dann wäre der Agent eine Verbesserung an einer Stelle, die es so gar nicht mehr bräuchte. Das Vorhaben wäre nicht zu groß, sondern zu klein gedacht.

Schneiden heißt also nicht nur, Vorhaben kleiner zu machen. Es heißt, zuerst das richtige Problem zu finden und dann den kleinsten Schritt, der dazu eine echte Antwort liefert. Für das Beispiel würde ich drei Schritte mit jeweils eigenem Zweck vorschlagen.

Erster Schritt: herausfinden. Bevor über den Agenten entschieden wird, schaut sich ein kleines Team den Prozess einmal von Anfang bis Ende an: Woher kommen die Informationen, die heute in die Maske getippt werden? Wer braucht sie danach, und wofür? Wo wird gewartet, nachgefragt oder nachgearbeitet? Daraus folgt eine erste Einschätzung, ob sich der Prozess neu gestalten lässt oder ob es reicht, die heutige Oberfläche leichter bedienbar zu machen.

Für wenige Wochen wird dann die entscheidende Annahme an einer Handvoll echter Vorgänge geprüft, etwa ob sich die Daten tatsächlich automatisch beziehen lassen. Trägt der Ansatz nicht, ist die Idee mit wenig Geld beendet, und vielleicht ist der Agent in der Oberfläche dann doch die richtige Lösung. Auch das ist ein gutes Ergebnis, weil die Entscheidung jetzt auf einem Blick auf den ganzen Prozess beruht.

Zweiter Schritt: das Fundament bauen. Der Test zeigt meist auch, was fehlt: Die Daten haben nicht die Struktur, die das System erwartet, es gibt keine Schnittstelle, Berechtigungen sind ungeklärt. Ein früher Test prüft deshalb nicht nur die Technik. Er prüft auch, was die Organisation für den nächsten Schritt noch nicht kann. Dieses Fundament zu bauen ist eine eigene Investition. Sie lohnt sich besonders, wenn auch andere Vorhaben darauf aufsetzen können.

Dritter Schritt: Wert realisieren. Erst jetzt wird der Prozess wirklich verändert, und erst hier verlange ich einen Business Case. Er ist dann belastbar, weil er auf Erfahrung beruht statt auf Schätzung. Und er rechnet einen anderen Prozess, nicht eine bessere Maske.

Ich nenne diese drei Investitionsarten Learning Bet, Capability Bet und Value Bet. Nicht jede davon muss sich rechnen. Die erste soll eine Frage beantworten, die zweite ein Fundament bauen, erst von der dritten erwarte ich Rendite. Wichtig ist die Balance: Ein Portfolio, das nur noch lernt und Fundamente baut, erzeugt keinen Wert. Learning und Capability Bets brauchen deshalb eine feste Zeitbox, ein begrenztes Budget und ein klares Kriterium, wann sie enden.

Der eigentliche Engpass: Im Portfolio sitzen Entscheider

Wer soll diese Arbeit machen? An dieser Frage hängt alles. In den meisten Portfolio-Gremien sitzen Führungskräfte, die über eingereichte Pläne entscheiden. Das ist ihre Aufgabe, und sie machen sie oft gut. Aber niemand bereitet so vor, dass es etwas Sinnvolles zu entscheiden gibt.

Gebraucht werden Menschen, die das Geschäft gut verstehen und genug von der Technik, um ein Vorhaben sinnvoll zu schneiden. Die bei einem Vorschlag zuerst fragen, ob er das richtige Problem löst, und dafür den ganzen Prozess ansehen. Die einen Prototyp selbst bauen oder zumindest beurteilen können. Die entscheiden, ob der ganze Prozess angefasst wird oder zuerst nur ein Ausschnitt, und daraus eine Entscheidungsvorlage machen. Am ehesten ist das Produktmanagement mit einem operativen Anteil. Im Fachbereich gibt es diese Rolle selten, in der IT auch nicht. In vielen Unternehmen gibt es sie heute gar nicht.

Am Anfang lässt sich die Lücke mit externen Leuten schließen, die genau diese Rolle übernehmen. Parallel braucht es einen Plan, die Fähigkeit im eigenen Haus aufzubauen. Und es braucht Vertrauen: Zu Beginn wird das Management jede Vorlage genau prüfen. Entscheidungsrechte lassen sich erst verschieben, wenn es bei den Vorlagen immer öfter denkt: Das hätte ich auch so entschieden.

Was KI daran ändert

Früher war ein Prototyp teuer. Es war vernünftig, erst auf Papier zu klären, ob sich der Aufwand lohnt. Heute ist ein erster Prototyp oft schneller gebaut als der Business Case, der ihn rechtfertigen soll. Wer trotzdem zuerst das Papier verlangt, verschenkt den größten Vorteil, den KI gerade bietet.

Das gilt in beide Richtungen. Auch viele Fachbereiche denken bei KI sofort an die fertige, produktive Lösung. Den Unterschied zwischen einem Test, einem Prototyp und einem System im Regelbetrieb zu kennen und bewusst zu wählen, ist selbst eine Fähigkeit. Sie fehlt auf beiden Seiten des Gremientischs.

Woran Sie das Muster erkennen

1. 1.Hat jedes Vorhaben schon Budget, Zeitplan, Ressourcen und Scope, bevor es zum ersten Mal im Portfolio besprochen wird?
2. 2.Wurde in den letzten zwölf Monaten ein Vorhaben im Portfolio neu zugeschnitten, kleiner oder größer, statt nur genehmigt oder abgelehnt?
3. 3.Gibt es Budget, um eine Idee auszuprobieren, ohne vorher einen vollständigen Business Case zu schreiben?
4. 4.Wer in Ihrem Portfolio-Gremium könnte selbst einen Prototyp bauen oder fachlich beurteilen?
5. 5.Wie lange dauert es bei Ihnen von einer KI-Idee bis zum ersten echten Test mit Nutzern?

Wenn Frage 1 ein Ja ist und Sie bei Frage 4 niemanden nennen können, verwalten Sie Ihr Portfolio. Gestaltet wird es nicht.

Warum eine Fastlane nicht reicht

Der naheliegende Reflex auf ein langsames Portfolio ist eine Abkürzung: eine Fastlane für kleine Vorhaben, eine Checkliste, ein vereinfachter Freigabeweg. Das hilft für einige Wochen. Dann rechnen alle ihre Vorhaben klein, um hineinzukommen, und das Problem hat nur seine Form geändert.

Eine Regel fragt nicht, ob ein Vorhaben das richtige Problem löst, und sie schneidet es nicht zu. Das braucht Urteilsvermögen, und das sitzt bei Menschen, nicht in Prozessen. Große Vorhaben wie eine ERP-Einführung sollen weiter sorgfältig durch das Portfolio laufen. Daneben braucht es ein Budget für das Ausprobieren und Leute, die die Arbeit vor der Entscheidung machen. Erst dann entscheidet ein Portfolio über die richtigen Fragen und nicht nur über fertige Pläne.