Der Ausfall von Computersystemen - sei es durch einen Fehler im Programm oder durch einen absichtlichen beziehungsweise versehentlichen Bedienungsfehler - kann für eine Organisation gravierende Folgen haben. Seit jegliche Unternehmensaktivität von Computerprogrammen abhängt, ist das Risiko real und vor allem dort zu steuern, wo individuell entwickelte Software zum Einsatz kommt.

Weil aber auch die Risikosteuerung selbst von IT-Systemen abhängig ist, sind die CIOs unentbehrliche Akteure, wenn es darum geht, Chancen und Risiken für das Unternehmen methodisch zu managen. Deutschland hinkt hier im internationalen Vergleich noch hinterher.

Der Jungfernflug der Ariane 5 am 4. Juni 1996 endete nach kaum 40 Sekunden mit der vollständigen Zerstörung der Rakete. Schuld war ein aus dem Modell Ariane 4 stammendes Softwarefragment, das in der Umgebung der neuen Trägerrakete nie getestet worden war. Schlimmer noch: Das Programm stammte schon aus den Zeiten der Ariane 3 und erfüllte eine Anforderung, die durch neue Zündverfahren längst obsolet geworden war. Die Kosten des durch ein falsches und unnötiges Codestück verursachten Desasters beliefen sich auf 380 Millionen Euro.

Teure oder zumindest peinliche Pannen

Frühjahr 2007: Ein Softwarefehler blockiert sämtliche Zimmertüren eines Luxushotels. Nur mit dem elektronischen Generalschlüssel wäre es den Gästen möglich gewesen, ihre Zimmer zu betreten - wenn nicht ein Mitarbeiter die Magnetkarte versehentlich mit nach Hause genommen hätte. In diesem Fall blieben die Folgen zum Glück harmlos, doch der Ruf der Hotelkette ist angekratzt. So unterschiedlich die Tragweite dieser beiden Beispiele sein mag - eines haben sie gemeinsam: Beide Vorfälle hätten sich vermeiden lassen, wenn beim Entwurf und Einsatz der Computersysteme auch die Risiken systematisch ins Auge gefasst worden wären.

Risiko-Management - Stiefkind deutscher CIOs

"Das Erfassen von Risiken ist in den meisten Unternehmen ein integraler Bestandteil jedes IT-Projekts und jeder strategischen Entscheidung, wird aber kaum jemals als solche ausformuliert", weiß Siegfried Raschke, Director of Operations bei DNV IT Global Services, einem Geschäftsbereich der norwegischen Stiftung Det Norske Veritas. "Während das IT-Risiko-Management heute in den USA und anderen europäischen Ländern wie Frankreich oder Skandinavien ganz oben auf der Prioritätenliste der CIOs steht, herrscht in Deutschland noch erheblicher Nachholbedarf." Dabei lässt die geltende Rechtslage den Unternehmen wenig Spielraum: Spätestens seit Basel II, Sarbanes-Oxley (SOX) und MiFID (Markets in Financial Instruments Device) muss ein Corporate-Governance-Konzept auch Maßnahmen zur Risikosteuerung einbeziehen.

In modernen Unternehmen werden solche Maßnahmen durch die verschiedenen Management-, Betriebs-, Warn- oder Kommunikationssysteme überhaupt erst möglich. So ist die IT selbst risikobehaftet und zugleich unverzichtbar für die Risikoverhütung. Entsprechend geht das IT-Risiko-Management weit über die Steuerung der IT-Risiken hinaus und erstreckt sich auch auf die Risikosteuerung durch die IT. Hier kommt dem CIO eine tragende Rolle zu: "Die Rolle des CIO ändert sich vom Technik- zum Risiko-Manager des Unternehmens", sagt Raschke. "Um die Risiken zu kontrollieren, muss er die Entwicklungs- und Betriebsprozesse permanent im Auge haben."

Vier grundlegende Strategien zum Umgang mit Risiken

Als Faustregel gilt: Risiko-Management muss immer vom "Worst Case Scenario", also den schlimmsten anzunehmenden Folgen, ausgehen. Nach der Quantifizierung der Wahrscheinlichkeit der einzelnen Risiken empfehlen Experten eine sorgsame Abwägung anhand von vier grundlegenden Strategien:

Risiko vermeiden: Auf das Produkt, die betroffenen Produkteigenschaften oder Produkteile kann ganz verzichtet werden. So lassen sich die damit verbundenen Risiken vermeiden, allerdings entfällt dadurch auch deren Nutzen. Sinnvoll ist diese Strategie dann, wenn andere Risikostrategien nicht verfügbar oder zu teuer beziehungsweise die Auswirkungen der Risiken erheblich sind. Angesichts des entgangenen Nutzens sollte sich die Organisation allerdings immer wieder fragen, ob veränderte Gegebenheiten nicht doch eine der im Weiteren aufgeführten Strategien ermöglichen.

Risiko minimieren: Wer sich für diesen Ansatz entscheidet, wird Maßnahmen ergreifen, die sowohl die Wahrscheinlichkeit des Auftretens reduzieren als auch die Auswirkungen der Risiken abschwächen. Zudem empfiehlt es sich, in der Betriebsphase zusätzliche Anforderungen zur Vermeidung von Risiken in die Anforderungsliste aufzunehmen. Diese Strategie ist sinnvoll, solange die Kosten für die Risikominimierung den Nutzen nicht überwiegen. Bei dahingehend optimierter Softwareentwicklung ist mit einem Aufwand in Höhe von fünf Prozent der Entwicklungskosten zu rechnen.

Risiko weitergeben: Kann die eigene Entwicklungsorganisation die Maßnahmen zur Minimierung der Risiken nicht oder nur unzureichend vornehmen, lassen sich Letztere auch weitergeben. So können etwa Teile der Software gekauft statt in Eigenregie entwickelt oder Aufgaben an Dritte mit mehr Know-how vergeben werden. Dabei ist entscheidend, dass das Risiko tatsächlich weitergegeben und die Leistung in jedem Fall erbracht wird - egal, welche Probleme beim Auftragnehmer intern auftreten.

Risiko hinnehmen: Schließlich kann das Risiko auch schlicht akzeptiert werden. Diese Strategie kann bei Risiken mit weniger gravierenden Auswirkungen sinnvoll sein. Im Rahmen eines Risiko-Managements werden nur geringfügige Risiken hingenommen, bei denen sich andere Maßnahmen nicht lohnen. Doch selbst wenn das Risiko in keiner Weise adressiert wird, sollten in der Projektarbeit mögliche Puffer für Verzögerungen und Zusatzaufwand eingeplant werden. Damit lassen sich dann die wenigen tatsächlich eintretenden Vorfälle abfedern.

Vor blindem Aktionismus warnt allerdings Ralf Kneuper, Berater für Softwarequalitäts-Management und Prozessverbesserung: "Viele Entscheidungen in der IT fallen auf Basis eines informellen Reportings oder des Bauchgefühls, wo harte Fakten notwendig wären."

Bevor Maßnahmen zum Risiko-Management ergriffen werden, empfiehlt Kneuper eine sorgfältige Bestandsaufnahme mit Methoden wie CMMI (Capability Maturity Model Integration). "Erst ein initiales Assessment schafft Klarheit, wo tatsächlich Handlungsbedarf besteht", weiß er aus der Praxis. "Oft decken sich die Ergebnisse nicht unbedingt mit der gefühlten Wahrnehmung im Management."

So weiß der Consultant von einem Finanzunternehmen zu berichten, das bis zur Bewertung gemäß CMMI davon überzeugt war, seine IT-Projekte im Griff zu haben. Dann allerdings stellte sich bald heraus, dass die rechtzeitige Fertigstellung in vielen Fällen nur um den Preis einer höheren Fehlerquote oder auch reduzierter Funktionalität gelang.

Erst als diese Risiken dem Management transparent wurden, ließen sich geeignete Maßnahmen ergreifen. "Mit der Einführung entsprechender Praktiken konnten wir die Projektsteuerung gemeinsam mit den Bereichsleitern verbessern", berichtet Kneuper. Heute wisse das Management zu jeder Zeit, wo die Projekte stehen und welche Risiken sie bergen, und könne somit bewusst Entscheidungen treffen.

Die Helden von gestern sind längst Geschichte

Kneuper zufolge ist die Anwendung von Methoden wie CMMI für die Softwareentwicklung oder Itil für den Softwarebetrieb jedoch nicht alles: "Wenn Management-Vorgaben nicht klar formuliert sind oder es keine Mechanismen zu deren Umsetzung im Projekt gibt, nützen alle Methoden wenig." Seiner Erfahrung nach setzen die notwendigen Prozessverbesserungen zunächst ein radikales Umdenken voraus: "Früher war derjenige Projektleiter ein Held, dessen Projekt an den Rand des Absturzes geriet - und der es dann noch retten konnte", erinnert er sich. Heute seien indes optimierte Prozesse gefragt, durch die Projekte von vornherein glatt durchlaufen.

Da das Risiko-Management häufig eine Änderung der Unternehmenskultur erfordert, muss es in eine fortschreitende und kontinuierliche Vorgehensweise eingebunden sein. Es sollte bescheiden beginnen, etwa indem die neue Methode nur im Rahmen eines Projekts oder einer Unternehmenseinheit eingeführt wird. In kleinen und mittleren Betrieben reicht zunächst die Ernennung eines Risikobeauftragten, der die Aufgabe hat, Risikobewusstsein in der Organisation zu verbreiten. In dem Maß, wie die neue Strategie nach und nach umgesetzt wird, kann man weitergehen und vor allem die Mitarbeiter stärker sensibilisieren.

Kultur der permanenten Prozessverbesserung

"Es geht immer um Menschen, Prozesse und Werkzeuge", betont auch Armin Beckert, Improvement Programme Manager im Corporate Quality Office bei EADS. "In allen drei Dimensionen zugleich zu arbeiten ist nicht immer einfach - aber der einzige Weg zum Erfolg."

Damit das gelingt, setzt Beckerts Arbeitgeber seit 2005 auf ein groß angelegtes Improvement-Programm, das in den einzelnen Geschäftsbereichen für eine kontinuierliche Prozessverbesserung sorgen soll. Ziel ist es, eine Kultur der permanenten Prozessoptimierung zu etablieren, in der eine gemeinsame Sprache gesprochen, mit einheitlichen Werkzeugen gearbeitet und eine hauseigene Verbesserungsmethode eingesetzt wird. CMMI ergänzt das Black-Belt-Programm, ein EADS-internes Trainingsprogramm zur Prozessoptimierung, in unterschiedlichen Bereichen wie Projekt-Management oder System-Engineering.

Neben den geringeren operativen Risiken sieht Beckert klare wirtschaftliche Vorteile: "Indem wir unsere Prozesse verschlanken, können wir sie beschleunigen, während wir durch eine geringere Varianz der Ergebnisse die Qualität steigern können." Beides wirke sich äußerst positiv auf die Kosten aus.

Dass die Vermeidung von Risiken zugleich bedeutet, Chancen zu nutzen, weiß auch Dresdner-Bank-CIO Friedrich Wöbking: "In den Prozessen kann man Geld holen, darum betreiben wir jetzt mit CMMI ein Prozessmodell zur Beurteilung und Verbesserung der Qualität von Produktentwicklungsprozessen." So konnte er die IT-Kosten von 1,627 Milliarden Euro (2002) auf 877 Millionen Euro (2005) im Schnitt um jährlich 46 Prozent senken und verfügt heute über standardisierte Produkte und Prozesse sowie eine neu aufgestellte zentrale IT-Governance. (kf)