Aus Business Cases das Beste machen

Der Weg zum nützlichen Beurteilungs- und Planungsinstrument

Inhalt dieses Artikels:
Aufwände systematisch erarbeiten | Nutzenkategorien auseinanderhalten | Eine Change-Management-Aufgabe | Künftige Entwicklungen diskutieren | Eng mit dem Controlling zusammenarbeiten | Umsetzungsbezug herstellen | Zusammenfassung

Es gibt kein allgemein anerkanntes Vorgehen für die Erstellung eines Business Cases. Trotzdem, oder gerade deswegen kann man vieles falsch machen. In der Dezember-Ausgabe des Fachmagazins IT Managements stellt Boubacar Traoré dar, wie ein Business Case zum nützlichen Beurteilungs- und Planungsinstrument wird und darüber hinaus Hinweise für eine bessere Aufstellung der IT liefert:

1.	Bei der Erstellung eines BC werden, etwa bei der Suche nach belastbarem Zahlenmaterial, mehr Fragen aufgeworfen als beantwortet. Die Aufgabe erfreut sich daher keiner allzu großen Beliebtheit.
2.	Der BC wird verdächtigt, als Budgetbeantragungstool missbraucht zu werden, um das Projekt „zu verkaufen“. Häufig ist auch schon vorgegeben, was das Vorhaben mindestens „einspielen“ muss. Die Aussagekraft wird also erst einmal angezweifelt.
3.	Wie die Potentiale auf dem Papier zu tatsächlichem Nutzen werden sollen, bleibt meist unklar. Der Umsetzungsbezug ist schwammig. Und da kaum nachgehalten wird, ob ein BC erfüllt wurde, verbessert sich auch die Qualität der Aussagen nicht.

Wichtig bei der Aufwandsaufstellung ist, so eng wie möglich an derzeit im Unternehmen erfassten Kosten-Kategorien zu bleiben; diese werden wo notwendig verfeinert und ergänzt. Nur so lässt sich eine historische Datenbasis zusammentragen, durch die die Kostenentwicklung extrapoliert werden kann, mit der sich das Vorhaben messen muss.

Wo kein Zahlenmaterial vorhanden ist, wird auf Expertenschätzungen mit Knowhow-Trägern aus IT und Fachbereich ausgewichen. Für die in Zukunft veränderte Aufwandsbasis ist dies sogar der einzig praktikable Ansatz. Durch eine Diskussion des Lebenszyklus des Investitionsobjektes lässt sich die Aufwandsanalyse schließlich noch um verschiedene Szenarien für die künftige Entwicklung ergänzen. Für IT-Systeme wird der Lebenszyklus typischerweise skizziert wie hier:

Anzumerken ist, dass der Aufwand bis zum Start der Realisierung in der Praxis häufig ausgeblendet wird. Dies ist akzeptabel, wenn der Planungs- und Analyseaufwand nur einen Bruchteil der gesamten Aufwände ausmacht. Kritisch zu hinterfragen ist dieses Vorgehen jedoch, wenn Folgeaufwände eher klein sind, da der BC dann verzerrt wird. Hier ist eine „mutige“ Entscheidung ohne lange Analyseaktivitäten oft wirtschaftlicher.

Die durch die Aufwandsanalyse gewonnenen Erkenntnisse müssen nachvollziehbar aufbereitet werden. Grundprinzip hierfür ist eine Trennung der durch das Vorhaben bedingten budgetwirksamen Aufwände von den nicht budgetwirksamen Aufwänden. Das bedeutet insbesondere, dass benötigte interne Kapazitäten und kalkulatorische Kosten getrennt von externen Kapazitäten darzustellen sind. Werden zusätzlich noch wie üblich Einmalaufwände von laufenden Aufwänden getrennt, ist eine wichtige Basis für die Entscheidungsfindung erarbeitet.

Im Gegensatz zur Aufwandsanalyse fehlen bei der Nutzenbewertung etablierte Analysemodelle. Der Kreativität ist somit entlang der Argumente Kostensenkung, Leistungssteigerung und Risikovermeidung fast freier Lauf gelassen. Ist die IT-Lösung Bestandteil des vom Unternehmen angebotenen Produktes oder der Dienstleistung, lässt sich noch ein entsprechendes viertes Argument hinzunehmen. Eine Nutzenbewertung kann so zum Beispiel entlang folgender Punkte erfolgen:

Die BC-Diskussion dreht sich von „Was muss es (auf dem Papier) bringen?“ hin zu „Wollen wir es machen?“ Hervorzuheben ist, je weniger objektiv quantifizierbarer Nutzen vorhanden ist, das heißt je stärker die Argumentation mit qualitativem Nutzen geführt wird, desto wichtiger ist auch ein Verfechter aus dem Managementkreis und eine Abstimmung mit den von der neuen Lösung Betroffenen.

Der kausale Zusammenhang von diskutiertem Nutzen und IT-Vorhaben ist nicht immer einfach nachzuweisen. Dies gilt insbesondere für den Geschäftsnutzen, der durch eine IT-Lösung entsteht, jedoch manchmal sogar für IT-Nutzen (etwa bei Architekturmaßnahmen). Hier ist eine enge Abstimmung von IT und Fachseite erforderlich.

Kann ein erheblicher Teil des ausgewiesenen Nutzens ohne die IT-Investition realisiert werden, ist zu entscheiden, ob diese nicht eine überteuere Organisationsmaßnahme darstellt. Es gilt aufzuzeigen, warum erst das IT-Vorhaben die Nutzenrealisierung ermöglicht. Der durch den BC entfachte Dialog zeigt, wo die IT Wert für die Fachseite generiert und wo noch Optimierungsbedarf bei der Ausrichtung der Aktivitäten besteht. Darüber hinaus liefert der Dialog eine Antwort auf die Frage „Wem genau bringt das Vorhaben etwas, wer muss es zahlen?“. Diese Erkenntnis sollte genutzt werden, um zusätzlich zum Budgetverantwortlichen auch „Nutzenverantwortliche“ zu benennen und zu verpflichten.

Diese Nutzenverantwortlichen sind die Champions des künftigen Projektes. Risiken und Einflussfaktoren auf die Nutzenrealisierung (wie beispielsweise Verhandlungsbedarf mit aktuellen Dienstleistern) werden durch sie angegeben und fließen in eine Sensitivitätsanalyse ein. Maßnahmen zur Risikokontrolle und Prüfpunkte für die getroffenen Annahmen sollten ebenfalls durch diese Champions geplant werden. Der BC dokumentiert somit die Akzeptanz des Vorhabens und den abgestimmten Beitrag der Beteiligten zum Projekterfolg.

	Welche Entwicklung ist für Infrastruktur und Anwendungslandschaft geplant (Veränderung der technologischen Basis, Betrieb intern oder ausgelagert, stärkere Integration oder Modularisierung/Gestaltung als Services, Standardisierung oder individuelle Realisierung)?
	Welche Veränderungen in der Geschäftsabwicklung werden sich in den nächsten Jahren auf die IT auswirken (zum Beispiel Skalierung, Veränderung bestehender Prozesse, neue Dienstleistungen)?

Lassen sich Entscheidungen zur künftigen Ausrichtung nicht zeitnah einholen, sollte sich diese Unsicherheit in der Planung des Vorhabens niederschlagen. Es wird in Stufen unterteilt, die für sich genommen bereits Nutzen stiften. Vor jeder weiteren Investition erfolgt dann eine erneute Prüfung der folgenden Stufe(n).

Grundregeln effektiver Kommunikation wie deutliche Formulierungen und eine strukturierte Darstellung müssen eingehalten werden und sämtliche Angaben (Datenquellen, Annahmen, Abstimmungspartner) sollten nachvollziehbar sein.

Frühe Schleifen mit den Top-Level-Adressaten des Business Cases helfen, die entscheidungsorientierte Ausrichtung der Analyse zu sichern und rechtzeitig notwendige Unterstützung einzuholen. Mindestens zwei Versionen eines BC sollten daher eingeplant werden: eine grobe Version früh in der Planungsphase und eine verfeinerte nachdem die Lösung im Detail entworfen ist. Eine weitere Überarbeitung nachdem die Lösung eingeführt wurde (um aus Planungsfehlern zu lernen und die Nutzenrealisierung nachhalten zu können) ist wünschenswert, jedoch in der Praxis kaum vorzufinden.

	Management/Summary
	Umfang des Vorhabens: Ziele/Ausgangssituation/Zusammenspiel mit anderen Aktivitäten/flankierende Maßnahmen/Einschränkungen/Hintergrundinformationen
	Fahrplan für die Umsetzung des Vorhabens
	Kosten/Nutzen Analyse
	Kosten/Nutzen-Verteilung und Umsetzungsverantwortung: „Wer muss es verantworten; wem bringt es was“
	Annahmen und damit verbunden Szenarien, Sensitivitätsanalyse und Risikobewertung. Daraus abgeleitet Maßnahmen, die für eine erfolgreiche Umsetzung notwendig sind. „Woran könnte das Projekt scheitern; was ist zu tun, um dies rechtzeitig zu erkennen und gegenzusteuern“
	Entscheidungsbedarf, Empfehlungen
	Methodische Hinweise (Ansprechpartner, Erhebungen, etc.)

Nähere Informationen in der neuesten Ausgabe von IT Management .
Der IT-Verlag behält sich alle Rechte am Artikel vor. © 2004 IT-Verlag