Ein Business Case endet nicht mit der Budgetfreigabe

Ein Business Case wird häufig für einen einzigen Moment geschrieben: die Budgetentscheidung. Das Vorhaben wird genehmigt, die Datei abgelegt und der Projekterfolg später an Termin, Budget und Lieferumfang gemessen. Ob die versprochene Wirkung tatsächlich eintritt, bleibt offen.

Damit verliert der Business Case genau dann seine Steuerungsfunktion, wenn aus einer Annahme Realität werden müsste. Ein System kann planmäßig live gehen, ohne dass Nutzer ihr Verhalten ändern. Eine Automatisierung kann technisch funktionieren, während der alte manuelle Weg weiterläuft. Eine Lizenz kann günstiger erscheinen, obwohl Betrieb, Integration und interne Arbeit höher ausfallen als erwartet.

Die zentrale These lautet: Der Business Case ist kein Verkaufstext für den Projektstart. Er ist eine fortgeführte Vereinbarung darüber, welche Wirkung mit welchen Kosten erwartet wird, wer sie verantwortet und wann neu entschieden wird.

Lieferung ist noch kein Nutzen

Projektoutput und Geschäftswirkung liegen auf unterschiedlichen Ebenen:

Ebene	Beispiel
Liefergegenstand	Workflow, Schnittstelle oder neues System ist produktiv
Fähigkeit	Ein Vorgang kann digital und regelbasiert bearbeitet werden
Nutzung und Verhaltensänderung	Beteiligte verwenden den neuen Weg und beenden den alten
Operative Wirkung	weniger Rückfragen, geringere Wartezeit oder höhere Nachvollziehbarkeit
Wirtschaftliche oder strategische Wirkung	vermiedener Aufwand, geringeres Risiko oder bessere Skalierbarkeit

Ein Projektteam kann die ersten beiden Ebenen weitgehend liefern. Die folgenden Ebenen hängen zusätzlich von Prozessverantwortung, Führung, Datenqualität, Qualifikation und tatsächlicher Nutzung ab. Genau deshalb darf die Nutzenverantwortung nicht mit der technischen Projektleitung enden.

Nicht jeder Nutzen muss in Euro übersetzt werden. Compliance, Resilienz, Entscheidungsfähigkeit oder reduzierte Personenabhängigkeit können legitime Ziele sein. Sie müssen aber konkret genug beschrieben werden, dass später eine Veränderung gegenüber der Ausgangslage beurteilt werden kann.

Vier typische Brüche im Business Case

Die Ausgangslage wurde nie gemessen

Wer „Bearbeitungszeit senken“ verspricht, aber weder Start- und Endpunkt noch heutigen Wert kennt, kann später jede Entwicklung als Erfolg deuten. Eine Baseline muss nicht perfekt sein. Sie muss für dieselbe Leistung, denselben Messpunkt und einen nachvollziehbaren Zeitraum gelten.

Nutzung wird als selbstverständlich angenommen

Eine technische Funktion erzeugt nur dann Wirkung, wenn die vorgesehenen Personen sie verwenden und der bisherige Weg tatsächlich verändert wird. Adoption ist kein Kommunikationsdetail am Projektende, sondern eine zentrale Annahme des Business Case.

Einsparung und vermiedener Aufwand werden vermischt

Wenn ein Team künftig weniger Zeit für eine Tätigkeit benötigt, entsteht zunächst freie Kapazität. Eine zahlungswirksame Einsparung entsteht erst, wenn Verträge, Stellen, Überstunden oder andere Ausgaben tatsächlich entfallen. Beide Wirkungen können wertvoll sein, sollten aber nicht als dasselbe ausgewiesen werden.

Mit Projektende verschwindet der Owner

Der Projektleiter verantwortet die Lieferung. Der Nutzen entsteht häufig erst im Fachprozess oder Betrieb. Ohne benannten Nutzen-Owner kann niemand verbindlich entscheiden, ob Schulung, Prozessänderung, Abschaltung des Altwegs oder weitere Investition nötig sind.

Der Nutzen-Steckbrief

Für mittelständische Vorhaben muss Nutzenmanagement kein eigenes Büro und kein schweres Reporting bedeuten. Pro erwartetem Nutzen reicht zunächst ein belastbarer Steckbrief:

Feld	Leitfrage
Problem und Ausgangslage	Welcher heutige Zustand soll sich ändern, und wie wird er beobachtet?
Erwartete Wirkung	Welche konkrete Veränderung soll für Geschäft, Nutzer oder Betrieb eintreten?
Wirkungskette	Welche Lieferung und welche Verhaltensänderung sollen diese Wirkung auslösen?
Zentrale Annahmen	Was muss außerhalb der technischen Lieferung zutreffen?
Nutzen-Owner	Welche Rolle kann die notwendige Veränderung im Betrieb steuern?
Frühindikator	Woran ist rechtzeitig erkennbar, ob Nutzung und Veränderung einsetzen?
Ergebnisindikator	Woran wird die tatsächliche Wirkung gegenüber der Baseline beurteilt?
Vollkosten	Welche internen und externen Kosten entstehen über Einführung und Betrieb?
Review und Entscheidung	Wann wird fortgeführt, angepasst, skaliert oder beendet?

Der Steckbrief verhindert Scheingenauigkeit nicht automatisch. Eine exakte Zahl ohne belastbare Datengrundlage bleibt eine unsichere Annahme. Deshalb sollten Annahmen, Schätzungen und gemessene Werte erkennbar getrennt werden.

Ein konstruiertes Beispiel: Go-live grün, Wirkung unbekannt

Das folgende Beispiel ist konstruiert.

Ein Freigabeworkflow wird termingerecht und innerhalb des genehmigten Budgets eingeführt. Der Projektstatus ist grün. Das alte Funktionspostfach bleibt jedoch geöffnet, weil einige Beteiligte den neuen Weg als umständlich empfinden. Ein Teil der Vorgänge läuft digital, ein anderer weiter per E-Mail.

Im Business Case war eine kürzere Durchlaufzeit genannt. Es wurde aber weder eine vergleichbare Ausgangslage festgehalten noch definiert, ob die Zeit vom Eingang bis zur Entscheidung oder nur die Bearbeitungszeit im neuen System gemeint ist. Auch der Nutzungsgrad und die parallel entstehende Doppelarbeit werden nicht erfasst.

Ein fortgeführter Nutzen-Steckbrief hätte früher sichtbar gemacht, dass die Wirkungskette unterbrochen ist: Der Workflow wurde geliefert, aber die notwendige Verhaltens- und Prozessänderung ist nicht eingetreten. Die richtige Reaktion wäre nicht automatisch eine weitere technische Funktion. Zuerst müsste der Nutzen-Owner entscheiden, ob der alte Weg beendet, der neue vereinfacht oder die ursprüngliche Erwartung korrigiert wird.

Das Beispiel enthält keine berichtete Erfahrung oder behauptete Kennzahl. Es verdeutlicht, warum Lieferstatus und Nutzenstatus getrennt geführt werden müssen.

Vollkosten laufen nach der Einführung weiter

Der genehmigte Kaufpreis ist nur ein Teil der wirtschaftlichen Entscheidung. Je nach Vorhaben gehören unter anderem dazu:

• interne Zeit für Auswahl, Einführung, Migration und Abstimmung,
• Lizenzen, Infrastruktur und nutzungsabhängige Gebühren,
• Integration, Tests und Datenpflege,
• Betrieb, Support, Informationssicherheit und Notfallvorsorge,
• Schulung und Prozessumstellung,
• Kosten paralleler Alt- und Neusysteme,
• sowie späterer Wechsel, Export oder Rückbau.

Der Artikel „IT-Kosten im Mittelstand“ beschreibt, wie externe und interne Kosten mit Leistungskennzahlen verbunden werden können. Für den Business Case ist zusätzlich entscheidend, ob Kostenannahmen nach dem Go-live durch reale Vertrags-, Nutzungs- und Arbeitsdaten ersetzt werden.

Das gilt ebenso für Make-or-Buy. Ein externer Service kann den internen Betriebsaufwand senken und zugleich Steuerungs-, Übergabe- und Exit-Aufwand erzeugen. Der Stundensatz entscheidet nicht, wenn Leistung, Risiko und Ausstieg nicht vergleichbar zugeschnitten sind.

Annahmen müssen einen Eigentümer und ein Verfallsdatum haben

Eine Annahme ist keine Schwäche des Business Case. Sie ist unvermeidlich, solange die Zukunft unsicher ist. Problematisch wird sie, wenn sie nach der Freigabe als Tatsache behandelt wird.

Typische Annahmen sind:

• ein bestimmter Anteil der Zielgruppe nutzt den neuen Weg,
• ein Altsystem kann zu einem Termin abgeschaltet werden,
• notwendige Stammdaten besitzen ausreichende Qualität,
• eine Schnittstelle ist im vereinbarten Umfang verfügbar,
• ein Dienstleister liefert zu angenommenen Konditionen,
• oder frei werdende Kapazität kann tatsächlich anders eingesetzt werden.

Für jede wesentliche Annahme sollte feststehen, wer sie prüft, bis wann ein Nachweis möglich ist und welche Entscheidung bei Nichterfüllung folgt. Ohne diese Konsequenz entsteht ein Annahmenregister, das zwar gepflegt wird, aber nichts steuert.

Reviews brauchen eine Entscheidungsfrage

Ein Berichtstermin allein erzeugt keine Steuerung. Jeder Review sollte auf eine echte Entscheidung zulaufen:

• fortführen: Wirkung und Kosten entwickeln sich im erwarteten Rahmen,
• anpassen: eine Annahme ist falsch, aber ein veränderter Weg bleibt sinnvoll,
• skalieren: ein begrenzter Einsatz zeigt belastbare Wirkung und kann erweitert werden,
• einfrieren: weitere Investition wartet auf einen fehlenden Nachweis,
• beenden: Wirkung, Nutzung oder Wirtschaftlichkeit rechtfertigen den Betrieb nicht,
• neu legitimieren: Ziel oder Umfang haben sich so stark verändert, dass ein neuer Business Case nötig ist.

Die Zeitpunkte hängen vom Vorhaben ab. Ein Nutzungsindikator kann kurz nach dem Go-live sinnvoll sein, eine wirtschaftliche Wirkung erst später belastbar werden. Statt einer pauschalen Frist sollte der Steckbrief festlegen, wann die jeweils notwendige Evidenz realistisch vorliegt.

Die Green Book-Ausgabe 2026 verbindet die vorgelagerte Bewertung von Optionen mit späterer Evaluation. Das Digital and Data Benefits Framework konkretisiert die Erfassung und Steuerung des Nutzens digitaler und datenbezogener Vorhaben. Beide Quellen richten sich an den britischen öffentlichen Sektor. Die hier vorgeschlagene schlanke Übertragung auf mittelständische Unternehmen ist eine redaktionelle Einordnung, keine formale Anwendungspflicht.

Nutzenverantwortung liegt im Betrieb

Der Nutzen-Owner muss die Einflussmöglichkeit besitzen, die für die Wirkung notwendig ist. Bei einem Prozessvorhaben ist das häufig die fachliche Prozessverantwortung, nicht die IT. Bei einer Infrastrukturmaßnahme kann die IT-Leitung näher am Nutzen liegen. Bei einer strategischen Vorgabe kann die Geschäftsführung verantwortlich bleiben.

Die Rolle sollte insbesondere entscheiden können über:

• Änderung des Arbeitsablaufs,
• notwendige Mitwirkung und Qualifikation,
• Abschaltung paralleler Altwege,
• Priorisierung weiterer Verbesserungen,
• und Akzeptanz verbleibender Einschränkungen.

IT kann Nutzungs- und Betriebsdaten liefern. Sie kann aber keine fachliche Adoption erzwingen, wenn der Prozess-Owner den alten Weg weiter zulässt. Der Beitrag „Nicht den schlechten Prozess digitalisieren“ zeigt, warum Prozesszweck, Rollen und Regeln vor der Werkzeugentscheidung geklärt werden müssen.

Kleine Vorhaben dürfen leichtgewichtig bleiben

Nicht jede Automatisierung und jede Lizenz benötigt einen mehrseitigen Business Case. Bei geringen Kosten, überschaubarer Wirkung und leichter Rückholbarkeit kann eine kurze Entscheidungsnotiz genügen.

Leichtgewichtig bedeutet jedoch nicht beliebig. Auch eine kleine Entscheidung sollte beantworten:

• Welches Problem wird gelöst?
• Welche Wirkung wird erwartet?
• Wer verantwortet die Nutzung?
• Welche Kosten und Bindungen entstehen?
• Wann wird geprüft, ob die Lösung bleibt?

Mit wachsender Investition, Abhängigkeit, Irreversibilität oder Geschäftswirkung muss die Tiefe zunehmen. Das ist eine Frage der Verhältnismäßigkeit, nicht des grundsätzlichen Verzichts auf Nutzensteuerung.

Der Guide for Effective Benefits Management wurde für Großprojekte veröffentlicht. Sein vollständiger Prozess wäre für viele mittelständische Vorhaben zu schwer. Die grundlegenden Gedanken – Nutzen über einen Lebenszyklus steuern, Verantwortung benennen und Messung mit dem Business Case verbinden – lassen sich jedoch angemessen reduzieren.

Woran ein lebender Business Case erkennbar ist

Ein Business Case wirkt nach dem Go-live weiter, wenn

• Projektstatus und Nutzenstatus getrennt berichtet werden,
• Schätzungen durch reale Kosten- und Nutzungsdaten ersetzt werden,
• Abweichungen zu einer Entscheidung führen statt nur erläutert zu werden,
• der Nutzen-Owner auch nach Auflösung des Projektteams handlungsfähig bleibt,
• alte Verfahren oder Systeme bewusst beendet oder neu legitimiert werden,
• und eine Beendigung möglich bleibt, obwohl bereits investiert wurde.

Der letzte Punkt ist wichtig. Bereits angefallene Kosten werden durch weiteres Ausgeben nicht zurückgewonnen. Eine Stop-Entscheidung ist kein Beweis, dass jede frühere Entscheidung falsch war. Sie kann das sachgerechte Ergebnis neuer Informationen sein.

Auch eine IT-Roadmap profitiert davon. Vorhaben konkurrieren nicht nur vor dem Start um Kapazität. Laufende Initiativen müssen ihren nächsten Nachweis und Entscheidungspunkt sichtbar machen, damit schwache Annahmen nicht dauerhaft Ressourcen binden.

Der nächste Schritt ist ein Review, kein neues Formular

Wählen Sie ein kürzlich abgeschlossenes Digital- oder IT-Vorhaben. Stellen Sie Liefergegenstand, erwartete Wirkung, tatsächliche Nutzung, heutige Vollkosten und verbleibende Annahmen nebeneinander. Benennen Sie anschließend genau eine Rolle, die über Fortführung, Anpassung oder Beendigung entscheiden kann.

Wenn dafür Daten fehlen, ist das bereits ein Ergebnis: Der bisherige Business Case konnte die Wirkung nicht prüfen. Ergänzen Sie nicht rückwirkend eine scheinpräzise Erfolgsgeschichte. Legen Sie fest, welche beobachtbare Information bis zum nächsten Entscheidungszeitpunkt benötigt wird.

Ein guter Business Case rechtfertigt nicht nur den Anfang. Er hält eine Investition so lange überprüfbar, wie sie Kosten verursacht und Nutzen liefern soll.