Business Case Standards für Innovation Teams: Einheitliche Qualität über das Portfolio

In den meisten Corporate Innovation Teams entsteht jeder Business Case neu — mit eigener Struktur, eigenen Annahmen-Logiken und eigenem Detailgrad. Das Ergebnis: Das Board bekommt bei jedem Gate ein anderes Format, vergleicht Ventures nicht mehr sauber miteinander, und jedes Review beginnt bei null. Ein gemeinsamer Business-Case-Standard löst dieses Problem. Dieser Guide zeigt, wie ein Innovation Team die Qualität seiner Business Cases über das gesamte Portfolio vereinheitlicht — von der Modell-Architektur über die Bewertungskriterien bis zum Playbook.

Standardisierung klingt nach Bürokratie, ist aber das Gegenteil: Sie nimmt dem Team die wiederkehrende Grundsatzarbeit ab, sodass jeder Case schneller entsteht und beim Board verlässlich ankommt.

Warum ein gemeinsamer Standard den Unterschied macht

Ein einzelner guter Business Case ist ein Erfolg. Zehn Business Cases, die alle unterschiedlich aufgebaut sind, sind ein Problem — selbst wenn jeder für sich solide ist. Die Schwierigkeit liegt nicht in der Qualität des einzelnen Cases, sondern in der fehlenden Vergleichbarkeit.

Drei konkrete Effekte fehlender Standardisierung tauchen in fast jedem Innovation Team auf:

• Das Board kann nicht vergleichen. Wenn Venture A mit einer Top-down-Marktschätzung und Venture B mit Bottom-up-Unit-Economics ankommt, bewertet das Board zwei unvergleichbare Dinge. Priorisierung über das Portfolio wird zur Gefühlssache.
• Jeder Case kostet zu viel Zeit. Ohne gemeinsame Bauweise baut jede Person die Modell-Architektur neu auf. Das kostet Tage, die in die inhaltliche Qualität fließen sollten.
• Wissen verlässt mit Personen das Team. Wenn die Methodik nur in einzelnen Köpfen steckt, geht sie beim nächsten Personalwechsel verloren. Onboarding neuer Teammitglieder dauert Monate.

Ein Standard adressiert alle drei: Er macht Cases vergleichbar, beschleunigt ihre Erstellung und konserviert die Methodik im Team statt in einzelnen Personen.

Die vier Bausteine eines Business-Case-Standards

Ein tragfähiger Standard ist keine Excel-Vorlage, die man nur noch befüllt. Er umfasst vier Elemente, die zusammen dafür sorgen, dass jeder Case im Team dieselbe Sprache spricht.

Baustein 1: Die gemeinsame Modell-Architektur

Die Modell-Architektur ist das sichtbarste Element des Standards. Gemeint ist eine gemeinsame Bauweise, nach der jede Person im Team ihren Case selbst aufbaut, keine fertige Datei zum Befüllen. Eine gute Architektur trennt drei Ebenen sauber voneinander:

• Input: ein zentrales Annahmen-Sheet, in dem jede Annahme genau einmal steht — mit Quelle, Begründung und Confidence Level.
• Berechnung: die Modellierungslogik, die ausschließlich auf das Annahmen-Sheet verweist. Keine hartkodierten Werte in Formeln.
• Output: die Auswertung — Unit Economics, P&L, Sensitivität und Executive Summary.

Diese Trennung ist der wichtigste einzelne Standard, den ein Team setzen kann. Sie macht jeden Case nachvollziehbar, prüfbar und änderbar, ohne dass jemand die Formellogik rückwärts entwirren muss.

→ Den methodischen Unterbau dazu findest du im Guide Business Case erstellen.

Baustein 2: Einheitliche Bewertungskriterien

Ein Standard legt fest, woran ein Case an jedem Gate gemessen wird. Welche Kennzahlen müssen vorliegen? Welche Schwellenwerte gelten als Freigabe-Signal? Welche Annahmen müssen belegt sein, bevor das nächste Gate erreicht wird?

Sinnvoll ist eine phasengerechte Logik: In der Ideation reicht die Frage, ob das Geschäftsmodell auf Unit-Economics-Ebene grundsätzlich profitabel sein kann. Erst in späteren Phasen kommen vollständige Finanzplanung, Szenarien und Finanzierungsbedarf hinzu. Wer in der Ideation schon eine 5-Jahres-P&L verlangt, erzeugt Scheinpräzision — und bremst das Team aus.

Diese Kriterien sollten dokumentiert und dem Board bekannt sein. Dann weiß jeder im Team, was an welchem Gate erwartet wird, und das Board weiß, dass jeder Case nach denselben Regeln geprüft wurde.

Baustein 3: Die Annahmen- und Confidence-Logik

Der größte Qualitätsunterschied zwischen Business Cases liegt selten in der Mathematik — sondern im Umgang mit Annahmen. Ein Standard legt fest, wie das Team mit Unsicherheit umgeht.

Bewährt hat sich eine einfache Confidence-Level-Logik: Jede zentrale Annahme bekommt eine Einstufung (hoch / mittel / niedrig), die zeigt, wie gut sie belegt ist. Eine Annahme mit hoher Confidence stützt sich auf eigene Daten oder belastbare Benchmarks; eine mit niedriger Confidence ist eine begründete Schätzung. Diese Transparenz ist ehrlicher als falsche Präzision — und sie lenkt die Aufmerksamkeit von Board und Team genau dorthin, wo das Modell am verwundbarsten ist.

Gekoppelt wird das mit der Sensitivitätsanalyse: Annahmen mit niedriger Confidence und hohem Ergebnis-Einfluss sind die Punkte, an denen weitere Validierung den meisten Wert schafft.

→ Mehr dazu im Guide Sensitivitätsanalyse.

Baustein 4: Das Playbook

Das Playbook ist die schriftliche Form des Standards. Es muss kein dickes Dokument sein — eine knappe, praxisnahe Anleitung reicht, die festhält: Wie ist ein Case aufgebaut? Welche Kriterien gelten an welchem Gate? Wie dokumentieren wir Annahmen? Welche Beispiele gibt es?

Der Wert des Playbooks zeigt sich beim Onboarding. Ein neues Teammitglied kann anhand des Playbooks und eines Referenz-Cases in Tagen statt Monaten produktiv werden — und baut von Anfang an Cases, die dem Team-Standard folgen.

Wie du den Standard im Team einführst

Ein Standard, den niemand nutzt, ist wertlos. Die Einführung entscheidet über den Erfolg. Drei Prinzipien helfen:

Mit einem echten Case starten, nicht mit einem Konzept. Der Standard sollte an einem realen Venture aus dem Portfolio entwickelt werden, nicht an einem abstrakten Idealmodell. So entsteht eine Bauweise, die zu den tatsächlichen Geschäftsmodellen des Teams passt — und ein erster Referenz-Case, an dem sich alle orientieren können.

Das Team einbeziehen statt den Standard zu verordnen. Ein Standard, der von oben diktiert wird, erzeugt Widerstand. Wird er gemeinsam entwickelt — etwa in einem Training, in dem jeder am eigenen Case arbeitet — entsteht Ownership. Das Team trägt den Standard, weil es ihn mitgestaltet hat.

Den Standard lebendig halten. Geschäftsmodelle und Board-Erwartungen ändern sich. Ein guter Standard wird regelmäßig überprüft und angepasst, statt einmal festgeschrieben und dann vergessen zu werden.

Wann sich externe Unterstützung lohnt

Ein Team kann einen Standard selbst entwickeln — wenn es die methodische Erfahrung und die Zeit dafür hat. In der Praxis fehlt oft beides: Das Team ist mit den laufenden Ventures ausgelastet, und niemand hat den vollständigen Methodik-Überblick, um Architektur und Kriterien von Grund auf sauber zu setzen.

Genau hier setzt externe Begleitung an. In einem Team-Enablement wird der Standard gemeinsam mit dem Team entwickelt — verbunden mit einem Training, in dem alle die Methodik an einem echten Case lernen. Das Ergebnis ist eine Fähigkeit, die im Team bleibt.

Fazit

Ein Business-Case-Standard ist kein bürokratisches Korsett, sondern ein Beschleuniger. Er macht Cases vergleichbar, spart dem Team wiederkehrende Grundsatzarbeit und sorgt dafür, dass jedes Venture beim Board mit derselben verlässlichen Qualität ankommt. Die vier Bausteine — gemeinsame Modell-Architektur, einheitliche Bewertungskriterien, klare Annahmen-Logik und ein knappes Playbook — bilden zusammen ein System, das auch beim nächsten Venture und beim nächsten Teammitglied trägt.

Wer die Business-Case-Qualität über das ganze Portfolio heben will, beginnt nicht beim einzelnen Case, sondern beim Standard.

→ Nächster Schritt: Business Case vor dem Board verteidigen — wie ein standardisierter Case die Prüfung durch Board, CFO und Controlling besteht.