Private Website

Blog, Strategie

Realoptionen in der IT – ein Wundermittel ? Teil 1

Sind Realoptionen ein Wundermittel zur Bewertung von strategischen IT-Projekten und IT-Investitionen?

In der strategischen Unternehmensplanung hat sich die Bewertung von Unternehmen und Investitionen mittels verschiedenster Verfahren zu einem unverzichtbaren Werkzeug entwickelt. Die Bewertung strategischer Investitionen in einem Unternehmen hingegen entzieht sich großteils der Bewertung mit klassischen Verfahren wie Discounted Cash Flow und anderen gängigen Verfahren.

Die Fragen in diesem Zusammenhang sind folgende: Was für Vor- und Nachteile hat der Realoptionsansatz für die Bewertung? Ist der Realoptionsansatz für IT-Projekte geeignet?

Die Idee von Optionen ist nichts grundlegend Neues. Die alten Griechen, die Römer und auch schon die Phönizier handelten mit Optionen auf Frachten, die ihre lokalen Seehäfen verließen.

Über lange Zeit hinweg waren sich Manager in der Praxis der Tatsache gar nicht bewusst, dass DCF und andere Bewertungsverfahren, ausgehend vom passiven Commitment des Managements gegenüber bestimmten Handlungsstrategien, Projekte zu pessimistisch bewerten. Diese eingeschränkte Sichtweise führt zu einem systematischen Cash-Flow Verlust, da die Flexibilität des Managements zur Reaktion auf sich ändernde Bedingungen nicht miteinbezogen wird. Aktive Entscheidungen des Managements resultieren in einer Steigerung des Cash Flows und einer Verminderung von Verlusten.

Aus diesen Gründen ergibt sich oft eine Differenz zwischen dem errechneten zu erwartenden NPV (Net Present Value) und dem echten NPV eines Projektes (bzw. einer Investition). Der Handlungsspielraum des Managements erweitert die Möglichkeiten durch eine Limitierung des Risikos bei Investitionen zu einem sog. Expanded NPV. Der Expanded NPV (statischer NPV + Optionswert) integriert den traditionellen NPV der direkten Cash Flows mit dem Wert der Handlungsoptionen des Managements.

Charakteristika von IT-Projekten

Einerseits sind Projekte im Umfeld der IT aufgrund der besonderen Gegebenheiten schwierig zu bewerten, andererseits ist gerade die wirtschaftliche Bewertung von IT-Projekten ein wichtiger Faktor. Projekt-Budgets sind grundsätzlich knapp bemessen und oft müssen sich mehrere Projekte um die Budgetmittel bewerben. Die Kosten und der Nutzen von IT-Projekten müssen daher schon im Vorfeld möglichst präzise abgeschätzt werden. Um Projekte vergleichbar zu machen, ist es auch von Nutzen die Kosten als auch die Nutzeffekte einer monetären Bewertung zuzuführen.

Ein besonders erschwerender Faktor von Projekten (nicht nur in der IT) ist die Einmaligkeit solcher Vorhaben. Üblicherweise gibt es keine Erfahrungswerte aus einem anderen Projekt, die einfach auf ein neues Projekt umgelegt werden können. Das zeigt sich schon daran, dass selbst die Vorgehensmodelle im Software-Engineering sowie im Projektmanagement in erfolgreichen Unternehmen einem steten Wandel unterliegen. Diese sind zusätzlich meist auch noch so flexibel aufgebaut, dass ein sogenanntes Tayloring (=“Maßanfertigung“) für das betreffende Projekt durchgeführt werden kann (und meistens auch muss), ohne die grundlegende Struktur des Vorgehensmodells zu verändern.

Aus diesen Gründen ist es also kaum möglich die Aufwandsschätzungen ähnlicher, bereits abgeschlossener Projekte als Grundlagen heranzuziehen. Selbst bei Projekten mit einem sehr ähnlichen Charakter wie ein bereits abgeschlossenes Projekt aus der Vergangenheit führt eine vergleichsgetriebene Bewertung zu nicht unerheblichen Streuungen in den Ergebnissen. Dies mag einerseits darin begründet liegen, dass die Halbwertszeit der Technologien und des Wissens in der IT vergleichsweise sehr kurz ist, andererseits aber auch in der Tatsache, dass sich auch die Geschäftsanforderungen an die IT mittlerweile rasch verändern.

Die zahlenmäßige Erfassung der Nutzeffekte gestaltet sich ebenfalls schwierig. Stand bis vor einigen Jahren noch die Realisierung von Kostensenkungspotentialen als Hauptmotivation für IT-Projekte im Raum, so sind es mittlerweile sehr oft strategische oder qualitative Ziele, die mit diesen Projekten verfolgt werden. Selbstverständlich verursacht daher gerade die monetäre Bewertung strategischer Benefits die meisten Schwierigkeiten.

Vergleich Kapitalwert und Realoptionsansatz

Zur Ermittlung des Kapitalwerts benötigt man folgende Daten:

  • detaillierte Cash Flows in den einzelnen Zeitabschnitten über den gesamten Planungshorizont
  • einen Diskontierungssatz der mehr oder weniger willkürlich festgelegt wird

Die Cash Flows sind aber risikobehaftet und sind im Grunde genommen variabel, weswegen man in der Praxis oft zu Erfahrungswerten übergeht. Dies wiederum resultiert in der Schätzung einer Wahrscheinlichkeits-verteilung. Diese Verteilungen sind üblicherweise symmetrisch. Durch das Risiko der Zahlungsströme ist der risikofreie Zinssatz aber kein korrekter Diskontierungssatz mehr. Zur Abschätzung vernünftiger Diskontierungsfaktoren in zweiperiodigen Modellen kann z.B. das CAPM (Capital Asset Pricing Model) herangezogen werden. Bei Projekten über mehr als 2 Perioden ist das Modell aber nicht mehr anwendbar und die Bestimmung des Diskontierungsfaktors wird zu einem diffizilen Problem. In der Praxis wird oft vom risikofreien Zinssatz ausgegangen und ein Risikozuschlag addiert –ähnlich der hier gewählten Vorgangsweise. Eine andere Möglichkeit ist die Verminderung der Cash Flows um eine Risikoprämie und Anwendung des risikofreien Zinssatzes.

Der Realoptionsansatz verspricht oberflächlich betrachtet eine Umgehung der Probleme bei der Kapitalwertbestimmung. Folgende Daten werden für den Realoptionsansatz benötigt:

  • detaillierte Cash Flows in den einzelnen Zeitabschnitten über den gesamten Planungshorizont
  • Schätzung der Parameter des Binomialprozesses
  • Marktpreis des Underlyings für die Option
  • risikofreier Zinssatz

Das entsprechende Underlying enthält das Risiko und führt somit auch zu einer Bepreisung des Risikos, das in der Option immanent vorhanden ist. So gesehen kann auf die Schätzung von Diskontierungsfaktoren oder Risikoabschlägen bei den Cash Flows etc. verzichtet werden. Das Problem holt den Anwender an einer anderen Stelle aber wieder ein – es ist nämlich ein Marktpreis für das Underlying erforderlich. Oft aber ist ein Marktpreis für ein Underlying nicht objektiv zu ermitteln. Es kann daher kein entsprechendes Portfolio konstruiert werden, wie es der Realoptionsansatz erfordert. In einem solchen Fall gelangt der Anwender wiederum nur dann zum Ziel, wenn er sich mit der Schätzung von Risikoprämien und Diskontierungsfaktoren auseinandersetzt. Somit ist der Analytiker wieder bei den gleichen Eingangsdaten wie für den Kapitalwert-Prozess angelangt.

Aus dieser Betrachtung resultiert, dass der Realoptionsansatz den Kapitalwert nicht ersetzen kann, sofern kein Marktpreis für das Underlying existiert. Der RO-Ansatz ist viel eher als ideale Ergänzung zum NPV zu sehen. Er liefert einen erweiterten Kapitalwert, der absichtlich Handlungsspielräume in die Bewertung mit einbezieht. Das Resultat ist ein Ergebnis das normalerweise deutlich über dem klassischen Kapitalwert eines Projekts liegt.

Realoptionen und Software Engineering

Gerade im Software Engineering wird heute sehr oft auf Basis von Vorgehensmodellen gearbeitet. Diese Vorgehensmodelle sind großteils phasenorientiert und eignen sich daher sehr gut zu einer optionsorientierten Betrachtungsweise. Wenn man von einem einfachen Modell mit vier Phasen ausgeht (Planung, Analyse, Design, Implementierung), so ist der Erfolg jeder Phase notwendige Voraussetzung für die Folgephase. Investitionen in solche Projekte erfolgen üblicherweise in Stufen. Die Mittel werden idealisierter Weise am Anfang jeder Phase freigegeben. Für die erste Phase (Planung) ist eine Anfangsinvestition zu tätigen. Mit dieser Investition erwirbt man sozusagen eine Call Option auf die Cash Flows des Projekts, wenn für die Folgephasen ebenfalls die notwendigen Anfangsinvestitionen getätigt werden. In Summe entsteht so eine Abfolge von Call Option auf Call Option, die auch als Compound Option bezeichnet werden kann.

Compound Option bei Vorgehensmodellen

Compound Option bei Vorgehensmodellen

Die durchschnittlichen Laufzeiten für IT-Projekte liegen erfahrungsgemäß zwischen 6 und 18 Monaten, daher ist auch die Abzinsung der Investitionsbeträge mit dem risikolosen Zinssatz für die einzelnen Phasen selten ein Faktor, der eine wesentliche Rolle spielt. Werden hingegen geschätzte Risikoaufschläge zu diesem risikolosen Zinssatz addiert, ergeben sich mitunter doch erhebliche Diskontierungsfakoren, die sich selbst bei kurzen Laufzeiten auf die Cash Flows auswirken – wenn schon nicht in den einzelnen Phasen so spätestens auf die Kostensituation des Gesamtprojekts.

Verallgemeinert man das Binomialmodell und untersucht damit IT-Projekte, die nach Vorgehensmodellen abgewickelt wurden, so lässt sich für die meisten Projekte Folgendes ableiten: In vielen IT-Projekten liegt eine typische Aufwandsverteilung vor, derzufolge der meiste Aufwand in der Analysephase anfällt und die Aufwende in den Folgephasen dann monoton fallen. Ist das der Fall, so muss für ein Projekt nur am Anfang der Planungsphase und am Beginn der Analysephase über die Fortsetzung entschieden werden, denn die Folgephasen haben dann typischerweise keine negativen Cash Flows mehr. Die negativen Umweltzustände sind nur in der Planungs- und der Analysephase von Relevanz. Daraus kann man wertvolle Schlüsse für ein effektives Projektmanagement ziehen.

[mehr im nächsten Teil …]

Schreibe eine Antwort