Risikomanagement in IT-Projekten
Aus Winfwiki
| Autoren: | Karsten Froh, Sebastian Kranefeld |
| Titel der Arbeit: | Risikomanagement in IT-Projekten |
| Hochschule: | Fachhochschule für Ökonomie und Management |
| Standorte: | Berlin, Essen |
Inhaltsverzeichnis
Inhaltsverzeichnis
|
1 Einleitung
Projektorientiertes Arbeiten gehört heute unabhängig von der Unternehmensgröße zum Alltag. Die Vorteile beim Umgang mit Neuartigem und Temporärem außerhalb der bestehenden Organisation haben überzeugt. Durch den schnellen und kontinuierlichen technologischen Fortschritt bietet sich gerade die Informationstechnik an, um Arbeiten in Projektform umzusetzen. Obwohl die IT zu den Pionierbranchen im Projektbereich zählt, weisen IT-Projekte eine vergleichbar geringe Erfolgsquote von 26 Prozent auf [1](S. 29). Eine Studie[2] hat herausgefunden, dass fehlendes oder mangelhaftes Risikomanagement eine der häufigsten Ursachen für das Scheitern von IT-Projekten ist. Fehlt das Risikomanagement in einem Projekt oder einer Unternehmung, so hängt der Umgang mit den zweifellos vorhandenen Risiken von den subjektiven Wahrnehmungen der unmittelbar beteiligten Personen ab. Die Kriterien für die subjektive Bewertung von Risiken des Einzelnen sind:
- Die maximale Schadenshöhe
- Die Zufälligkeit des Ereignisses (schlechte oder unmögliche Bestimmung eines Zeitpunktes erhöhen die Einschätzung)
- Zeitspanne zur Gefahrenabwehr bei Eintritt des Ereignisses
Der realistischen Eintrittswahrscheinlichkeit des Ereignisses, sprich dem statistischen Erwartungswert, wird keinerlei Bedeutung zugemessen. Hinzu kommt der Umgang des einzelnen Individuums mit erkannten Risiken. Sie werden zum Teil als "Herausforderung der eigenen Kräfte", als "unvermeidbare Schicksalsschläge" oder lediglich als "akute Bedrohung" wahrgenommen. [3][4] Selbst bei zutreffender Identifikation und Bewertung eines Risikos fehlen ohne ein etabliertes Risikomanagement Prozesse, um mit dieser Information in angemessener Zeit darauf reagieren zu können. Diese Fallstudie behandelt das Risikomanagement im Allgemeinen und im Projektkontext, betrachtet die gängige Praxis in Unternehmen und leistet Hilfestellung bei der Entscheidung, ein Risikomanagement in zukünftigen Projekten zu etablieren.
2 Grundlagen[5][6][7][8][9][10][11]
In diesem Abschnitt soll ein kurzer Überblick über die Grundlagen von Projekten, das Projektmanagement und das damit verbundene Risikomanagement gegeben werden.
2.1 Projektmanagement
Unter einem Projekt versteht man eine neuartige, komplexe Aufgabe mit konkreten Zielvorgaben, welche in einem festgelegten Zeitraum zu erledigen ist. Das Projektmanagement übernimmt dabei die zentrale Verantwortung für die erfolgreiche Erledigung dieser Aufgabe (Projektabschluss). Die Aufgaben des Projektmanagements gliedern sich dabei in folgende Teilbereiche:
- Beschaffungsmanagement
- Kommunikationsmanagement
- Kostenmanagement
- Personalmanagement
- Qualitätsmanagement
- Risikomanagement
- Zeitmanagement
Im Folgenden behandeln wir das Risikomanagement an sich und im Kontext des Projektmanagements.
2.2 Risikomanagement
Das Risikomanagement (im Folgenden RM genannt) umfasst sämtliche Aufgaben, die sich aktiv mit den Risiken und deren Auswirkungen auseinandersetzen, die innerhalb einer Organisation oder deren Umfeld auftreten können. Die Vorgehensweise innerhalb des RM ist streng systematisch und orientiert sich an einer klar zu definierenden Strategie. An dieser Stelle wird das Risikomanagement in seiner ursprünglichen Form, die sich vornehmlich mit Risiken für die Existenz oder den Geschäftserfolg von Unternehmungen beschäftigt, behandelt.
Ziele des Risikomanagements sind[12](S. 150):
- Nachhaltige Erhöhung des Unternehmenswertes
- Sicherung der Unternehmensziele
- Sicherung des zukünftigen Erfolges des Unternehmens
- Optimierung der Risikokosten
- Soziale Ziele aus der gesellschaftlichen Verpflichtung des Unternehmens
2.2.1 Risiko
Allgemein bezeichnet ein Risiko ein mögliches zukünftiges Ereignis, welches zu einer Abweichung von einem erwarteten bzw. geplanten Zustand führt. Da sich das RM mit der Prävention von Risiken und der Reduktion von deren Auswirkungen beschäftigt, ist in diesem Kontext von einem möglichen zukünftigen Ereignis mit zwangsläufig negativen Konsequenzen auszugehen.
2.2.2 Prozesse des Risikomanagements
2.2.2.1 Risikostrategie
Eine klar formulierte Risikostrategie ist für die Durchführung aller RM-Prozesse unerlässlich. Entscheidungen in den einzelnen Phasen müssen sich an dieser Strategie ausrichten. Bei der Etablierung eines neuen RM in einem Projekt/Unternehmen kann die Strategie aufgrund des herrschenden Informationsmangels natürlich nur vage formuliert werden. Eindeutige Ziele in messbaren Größen dürfen aber nicht fehlen. Die Risikostrategie liefert die Antwort auf folgende Fragen:
- Welche Faktoren bedrohen Erfolg und Erfolgspotenziale?
- Welche Kernrisiken soll das Unternehmen selbst tragen?
- Welche Eigenkapital- und Liquiditätsausstattung ist als “Risikodeckungspotenzial” nötig?
- Welcher risikoadjustierte Erfolgsmaßstab ist Zielgröße der Unternehmenssteuerung?
[13](S. 38)
2.2.2.2 Risikoidentifikation
Die Risikoidentifikation ist der begründende Teil eines erfolgreichen RM. Sie liefert die Datenbasis, auf der alle weiteren Schritte des RM aufbauen. Aus dieser Abhängigkeit für Folgeprozesse kommt der Identifikation eine besondere Bedeutung zu und stellt hohe Ansprüche an die qualitative Umsetzung dieses Prozesses. Die Risiken werden zunächst bei der Einführung des RM zusammengetragen, um eine RM-Strategie zu entwickeln und die Voraussetzungen für den Durchlauf weiterer Prozesse zu schaffen. Die Risikoidentifikation ist jedoch kontinuierlich anzuwenden, um sicherzustellen, dass auch zukünftig auftretende Risiken in das RM einbezogen werden. Die konkrete Ausgestaltung hängt dabei stark von der Unternehmensstruktur, dem Geschäftsfeld, der Marktsituation und dem sonstigen Umfeld der Unternehmung ab und reicht von der jährlichen Revision des Risikokataloges bis hin zur Erfassung von „Ad-hoc-Risiken“, die durch Mitarbeiter gemeldet werden können. Das Ergebnis der Risikoidentifikation ist ein Risikokatalog in Form von gegliederten atomaren Einzelrisiken, zunächst ohne Wertung aufgelistet. Weitere Daten, die bei der Identifikation bereits anfallen, wie Schätzwerte oder mögliche Auswirkungen, werden nicht verworfen, sondern zunächst an den Katalog angehängt. Es ist jedoch wichtig, dass diese Zusatzinformationen zu dem eigentlichen Risiko an dieser Stelle nicht gefordert werden. In der Praxis wird häufig bei der Risikoidentifikation von den Mitarbeitern erwartet, die Risiken gleichzeitig zu bewerten. So läuft man Gefahr, dass Risiken, die zwar erkannt wurden, die aber der Mitarbeiter aus seiner Position heraus nicht einzuschätzen weiß, erst gar nicht in das RM einfließen. Methoden zur Identifikation werden unter 2.2.3 detailliert beschrieben.
2.2.2.3 Bewertung
In dieser Phase werden die zuvor gesammelten Risiken einzeln inhaltlich betrachtet und bewertet. Jedem Element werden Eintrittsvoraussetzungen und -Wahrscheinlichkeiten zugeordnet sowie der daraus resultierende mögliche Schaden. Ist der Schaden direkt messbar, wie beispielsweise ein Forderungsausfall oder der Verlust von Gütern, so wird dieser direkt in monetären Werten ausgedrückt. Schwieriger wird es bei Schäden wie „sinkende[r] Reputation eines Markennamens“, die schwer quantifizierbar sind, jedoch existenzielle Auswirkungen haben können. Soweit dies möglich ist, werden in diesen Fällen die damit verknüpften Folgeschäden bewertet und kumuliert den Einzelrisiken zugeordnet. Bei der Ermittlung der Schadenshöhe ist das „Worst-Case-Szenario“[14] anzuwenden.
2.2.2.4 Aggregation
Einzelrisiken, die ihrer Höhe und Eintrittswahrscheinlichkeit nach bewertet vorliegen, bilden das Gesamtrisiko des Unternehmens nicht vollständig ab. Durch kompensatorische und kumulative Effekte der Einzelrisiken ist das aggregierte Gesamtrisiko nicht gleich der Summe der Einzelrisiken. Ebenso können Einzelrisiken isoliert zu vernachlässigen sein, kumulativ betrachtet jedoch existenzgefährdendes Ausmaß annehmen. Deshalb ist es unumgänglich, die Beziehungen der Einzelrisiken im Kontext des Gesamtrisikos zu prüfen und entsprechend neu zu bewerten. [12]
2.2.2.5 Steuerung
Im nachfolgenden Abschnitt werden verschiedene Strategien bzw. Methoden betrachtet, die geeignet sind, Risiken zu bewerten und zu beherrschen.
Grundsätzlich können Risiken nicht gänzlich vermieden werden. Es bleibt immer ein bestimmtes Restrisiko erhalten, das trotz optimaler Anwendung der Strategien und Methoden nicht vermieden werden kann.
Auch hier stellt sich die Frage nach der Wirtschaftlichkeit der Risikobeherrschbarkeit. Zur Diskussion stehen hier immer Aufwendungen zur Risikoeinschränkung, die über dem eigentlichen Nutzen liegen. Der eigentliche Nutzen besteht hier in der Vermeidung eines potenziellen Schadens, der in der Zukunft auftreten kann. Hierbei besteht die Frage, ob dieses Risiko akzeptiert wird, da mit faktisch 20 % des Aufwandes zur Risikobeherrschung bereits 80 % des Risikopotenzials reduziert wurde, jedoch mit weiteren 80 % Aufwand nur noch 20 % Risikopotenzial reduziert bzw. beherrscht werden kann.
Hier besteht dann die Frage, ob dieses Risiko akzeptiert wird, d. h., ob man bereit ist, mit diesem Restrisiko zu leben, wenn von ihm kein weiteres Eskalationspotenzial mehr ausgeht.
Reduktion
Risiken minimieren bedeutet, deren Eintrittswahrscheinlichkeit oder die daraus resultierende Schadenshöhe herabzusetzen. In der Praxis erfolgt dies meist durch technische oder personelle Maßnahmen. Beispielsweise senkt die Verbesserung oder Erneuerung einer Maschine deren Ausfallwahrscheinlichkeit und setzt somit das Risiko "Ausfall der Produktion durch technische Defekte" herab. Eine Schulungsmaßnahme für Mitarbeiter für bestimmte Ausnahmesituationen kann die Schadenshöhe bei Eintritt des entsprechenden Ereignisses reduzieren (Personalentwicklung).
Abwälzung
Das Risiko wird nicht weiterhin durch die Unternehmung selbst getragen, sondern auf einen anderen Träger abgewälzt. Dies können darauf spezialisierte Unternehmen wie Versicherungen und Banken sein, aber auch Vertragspartner, Lieferanten und Kunden. Die Abwälzung kann dabei formeller (durch Verträge oder Gesetze) oder physischer Natur (bspw. Lagerung von Gefahrenstoffen) sein. Gesetzliche Vorgaben müssen hierbei eine besondere Berücksichtigung finden, nicht alle Risiken können ohne Weiteres übertragen werden. Die Risikoträger müssen regelmäßig kontrolliert werden.
Streuung
Kann ein Risiko nicht weiter reduziert oder abgewälzt werden, ist es unter Umständen möglich, dieses zu streuen. Angenommen die Eintrittswahrscheinlichkeit eines Lieferausfalls beträgt bei allen Lieferanten 5 %. Es wurden alle operativen Maßnahmen getroffen, um den Schaden eines Lieferausfalls zu minimieren. So lässt sich das Risiko weiter senken, indem die Aufträge auf verschiedene Lieferanten gestreut werden. Wichtig ist hierbei, dass diese möglichst autark agieren und keine Korrelation zwischen den Ausfallrisiken der Lieferanten besteht. Dies könnte bei identischen Vorlieferanten gegeben sein.
Vermeidung
Unter Risikovermeidung versteht man das Senken der Eintrittswahrscheinlichkeit oder der Schadenshöhe eines Risiko auf 0 (nicht gegen 0). Dies ist in der Praxis selten möglich, da der völlige Ausschluss eines Risikos oft nur durch Unterlassung der risikobehafteten Tätigkeit erreicht werden kann. Diese Maßnahme stellt eine letzte Konsequenz dar, wenn alle anderen Prozesse des RM ein existenzbedrohendes Restrisiko hinterlassen.
2.2.2.6 Akzeptanz von Restrisiken
Alternative Risikoübernahme: Sind die vorherigen Steuerungsoptionen des Risikomanagements ausgeschöpft, so muss das verbleibende Restrisiko durch das Unternehmen getragen werden. Die Entscheidung, ob das Unternehmen in der Lage ist, das Risiko selbst zu tragen, wird durch die Risikostrategie beeinflusst und in der Steuerungsphase der Risikovermeidung getroffen. Sollte sich das Risiko als untragbar herausstellen, ist die Vermeidung der risikobehafteten Tätigkeit die einzige Alternative. Zur Akzeptanz des Risikos bedarf es der Schaffung einer entsprechenden Risikodeckungsmasse. Diese kann durch Eigenkapital, Bildung von Rückstellungen und Wagniszuschläge geschehen. [15](S. 101)[16](S. 190) Dieses Vorgehen ist nicht für alle Risiken und beliebig große Schadenssummen, die innerhalb der unternehmerischen Tätigkeit auftreten, umsetzbar.
2.2.3 Methoden des Risikomanagements
An dieser Stelle wird auf die in der Praxis häufig angewandten Methoden des Risikomanangements eingegangen. Weitere Methoden des Risikomanagements gehen aus Abbildung XX hervor, werden im Folgenden jedoch nicht näher erläutert.
2.2.3.1 Relevanzklassen
Die älteste und einfachste Methode des Risikomanagements ist die Einteilung identifizierter Risiken in Relevanzklassen. Als einzige Kriterien, um die Risiken zu bewerten, stehen die direkten Auswirkungen auf den Unternehmenswert und den Jahresüberschuss zur Verfügung. Diese Vorgehensweise ist leicht durchzuführen, bringt aber eine Reihe von Nachteilen mit sich:
- Kurzfristiger Zeithorizont
- Schlecht geeignet für operative Risiken
- Abhängigkeiten und Wirkungszusammenhänge der Risiken werden nicht betrachtet
Ein Beispiel für die Einteilung von Risiken in Relevanzklassen:
| Relevanzklasse | Beschreibung |
|---|---|
| 1 Unbedeutendes Risiko | Weder Jahresüberschüsse noch Unternehmenswert sind spürbar beeinflusst |
| 2 Mittleres Risiko | Spürbare Beeinflussung des Jahresüberschusses |
| 3 Bedeutendes Risiko | Starke Beeinflussung des Jahresüberschusses bei gleichzeitiger spürbarer Auswirkung auf den Unternehmenswert |
| 4 Schwerwiegendes Risiko | Führt zu einem Jahresfehlbetrag und senkt den Unternehmenswert erheblich |
| 5 Bestandsgefährdendes Risiko | Mit einer sehr hohen Wahrscheinlichkeit ist der Fortbestand des Unternehmens gefährdet |
2.2.3.2 Risk-Map
2.2.3.3 Post-Mortem-Analyse
Der Begriff Post-Mortem-Analyse (PMA) kommt aus dem Lateinischen für post (=nach) und mors (=Tod)[19] und bedeutet wörtlich soviel wie "nach dem Tod". Der Begriff der Post-Mortem-Analyse wird vielfältig verwendet, im Kontext des Risiko- und Projektmanagements steht er für die Betrachtung und Analyse einer in der Vergangenheit abgeschlossenen Handlung. Die Übersetzung lässt vermuten, dass gescheiterte Projekte bzw. eingetroffene Schäden (die zuvor nicht als Risiko eingestuft wurden) betrachtet werden und nach deren Ursachen gesucht wird. Dies ist jedoch nur ein Teil der PMA. Auch bei der Analyse erfolgreich abgeschlossener Projekte werden Risikopotenziale sichtbar, die bei Durchführung gleichartiger Projekte bzw. im Unternehmensalltag in das Risikoportfolio aufgenommen werden. Ebenfalls geben positiv verlaufene Geschäftsjahre Hinweise auf kritische Bereiche des Unternehmens und deren Risiken.
2.2.3.4 Delphi-Studie
Bei der Delphi-Studie (oder auch Delphi-Methode) handelt es sich um eine strukturierte Befragungstechnik zur Schätzung und Erstellung von Prognosen. Die Grundidee basiert auf der unabhängigen, rezidivierenden Befragung von Experten zu einem Thema. Diskussionen unter den Teilnehmern werden nach Möglichkeit unterbunden. So soll verhindert werden, dass gruppendynamische Prozesse und soziale Aspekte Einfluss auf die Qualität der fachlichen Aussage der Studie haben. Jeder Teilnehmer greift autark auf sein fachliches Kow-how zurück. In der Praxis wird die Delphi-Methode meist schriftlich mithilfe von Fragebögen durchgeführt. Nach dem ersten Durchlauf werden Mittelwerte oder Trends ermittelt und große Abweichungen einzelner Teilnehmer entsprechend auf dem Fragebogen kommentiert. In der zweiten Runde sollen die Kommentare in die Überlegungen mit einbezogen werden, sodass sich die Ergebnisse weiter annähern. Ein aussagekräftiges Ergebnis ist dann erreicht, wenn sich bei den Ergebnissen ein Konsens deutlich abzeichnet.
Diese Methode eignet sich vornehmlich zur Ermittlung von Wahrscheinlichkeiten in komplexen Umgebungen, mit denen ein hoher Schaden verbunden ist. Sie beansprucht sowohl finanzielle und personelle Ressourcen stark und setzt einen entsprechenden Durchführungszeitraum voraus. Es ist denkbar, dass Expertenwissen nicht in dem Umfang zur Verfügung steht, um die Delphi-Studie sinnvoll umzusetzen. Auch ist zu beachten, dass der Verzicht auf Gruppendynamik nachteilig für die Konsensfindung sein kann.[18](S. 75)
2.2.3.5 Monte-Carlo-Simulation
In ein IT-gestütztes Modell der Wirkungszusammenhänge der Unternehmung wird das gleichzeitige Eintreffen unterschiedlicher Risiken simuliert, indem die Risikotreiber und die Schadenshöhe über „Pseudozufallswerte“ generiert werden. Was soviel bedeutet, dass die Werte nur scheinbar zufällig sind, jedoch durch Algorithmen generiert werden. Die Schwankungsbreite der Werte ergibt sich aus historischen Zahlen, Worst-Case-Werten[14] und branchenüblichen Annahmen. In mehreren Tausend Testläufen wird ermittelt, welche Auswirkungen bestimmte Konstellationen von Einzelrisiken auf das Gesamtrisiko haben. Die Ergebnisse in Form des jeweiligen aggregierten Gesamtrisikos werden in einer Datenbank gespeichert und die kritischen Konstellationen der Einzelrisiken können näher analysiert werden. Die Ergebnisse einer Monte-Carlo-Simulation können auch für weitere Unternehmenszwecke nutzbar sein. [12]
2.2.3.6 FMEA - Failure Mode and Effects Analysis
Die FMEA (Ausfalleffektanalyse) kommt aus dem militärischen Bereich. Zunächst wird das Unternehmen als intaktes und störungsfreies System beschrieben. Anschließend werden einzelne Funktionsbereiche gebildet und deren Schwachstellen herausgearbeitet. Als Ergebnis werden die Auswirkungen der erkannten Schwachstellen auf das Gesamtsystem aufgezeigt. Der Vorteil dieser Methode ist die streng vorgegebene Systematik und entsprechende „Worksheets“. Die Methode dient nicht nur zur Analyse von Unternehmensprozessen, sondern auch zur Analyse von Hard-/Software sowie Konstruktionen sämtlicher Art. Der wesentliche Nachteil ist die fehlende Berücksichtigung von Interdependenzen. [12](S. 176)
2.2.3.7 Risikoereigniskette
Mithilfe der Risikoereignisskette können Wirkungszusammenhänge zwischen Risikoursache, den Risiken und Schäden bis hin zum aggregierten Gesamtrisiko erarbeitet und visualisiert werden. Ein Risiko kann dabei direkt einem Schaden zugordnet werden, aber auch eine Ursache für ein weiteres Risiko darstellen. So werden die Bedeutungen der Einzelrisiken im Gesamtkontext deutlich. Die Schadenshöhe, die von einem Einzelrisiko ausgeht, ist unter dieser Betrachtung höher als der direkt zuzuordnende Schaden.
3 Risikomanagement als Teil des IT-Projektmanagements
An dieser Stelle soll auf die Notwendigkeit des Risikomanagements im Speziellen eingegangen werden, ohne den bereits bestehenden Abschnitt aus den #Grundlagen zu wiederholen. Hier geht es darum, die Notwendigkeit der Risikoanalyse eindeutig hervorzuheben, um insbesondere deren realer Bedeutung gerecht zu werden. Dabei dreht es sich um die Frage der Motivation, warum Risiken analysiert und bewertet werden müssen.
Risiken stellen durch das unbestimmte Vorhersagen des möglichen Eintretens eines Ereignisses eine Gefahr der wirtschaftlichen Beeinträchtigung der unternehmerischen Zielstellungen dar. Bei den unternehmerischen Zielstellungen handelt es sich hier um Projektziele, die wie bereits beschrieben zeitlich und finanziell limitierte Vorhaben mit definiertem Start- und Endzeitpunkt sind.
„Durch die Kategorisierung von Risiken wird das Zusammenfassen von gleichartigen Risiken und somit die Beherrschbarkeit dieser Risiken mittels gemeinsamer oder ähnlicher Risikoidentifikation und Risikoreduzierungsmaßnahmen ermöglicht. Bei der Kategorisierung ist von besonderer Bedeutung, dass die Definition der einzelnen Kategorien möglichst exakt erfolgt“ [21] Ziel ist hierbei, durch eine Kategorisierung von Risiken die Beherrschbarkeit der zu analysierenden Risiken mittels gemeinsamer oder ähnlicher Risikoidentifikation und Risikoreduzierungsmaßnahmen zu ermöglichen. Nur durch die detaillierte und deterministische Kenntnis der Projektrisiken kann deren Eintrittswahrscheinlichkeit oder die Höhe der negativen Auswirkungen eingeschränkt werden.
Dies erfolgt unternehmensintern und unternehmensübergreifend und gilt beispielsweise für:
- Bildung von Datenkonsortien für den Austausch von Schadensfällen
- Benchmarking von Risikoportfolios
- Anwendung allgemeiner Kategorisierungskataloge zur Veröffentlichung statistischer Sachverhalte
Mit dem Eintritt eines bestimmten Ereignisses bzw. einer Ereigniskombination wird aus dem latenten Risiko ein Schadensfall, der in der Regel zur Beeinträchtigung des wirtschaftlichen Erfolges des Unternehmens führt. Quelle: 20 (Seite 15)
3.1 Typische Risiken von IT–Projekten
3.1.1 Allgemeine Projektrisiken[21]
Projektrisiken werden nach ihren Ursachen unterschieden und nach deren unterschiedlichen Merkmalen gruppiert.
3.1.1.1 Mensch
„Am Ende sind alle Probleme der Wirtschaft Personalprobleme.“(Alfred Heerhausen, ehemaliger Vorstandsvorsitzender der Deutschen Bank) [21](S. 16) Die Risikokategorie Mensch lässt sich in ungewollte Fehlhandlungen und vorsätzliche Handlungen untergliedern. Rechtliche Begriffe wie (grobe) Fahrlässigkeit spielen in diesem Zusammenhang keine Rolle. Dieser Kategorie werden sämtliche Risiken zugeordnet, die unmittelbar in der Person oder dem Verhalten eines Menschen begründet sind. In der Praxis handelt es sich dabei meist um menschliches Versagen und kriminelle Handlungen und zeigt sich beispielsweise in:
- Gesetzeswidrigen Handlungen von Mitarbeitern
- Dubiose Verkaufspraktiken im Vertrieb
- Unautorisierte Handlungen
- Fehlentscheidungen
Risikotreiber:
Die Risikotreiber in der Kategorie sind nicht erschöpfend aufzuzählen, da alle Faktoren, die menschliches Handeln beeinflussen, ein relevanter Risikotreiber sind. Ein Großteil der Risikotreiber befindet sich außerhalb des Unternehmens und kann weder erkannt noch beeinflusst werden, da viele private Einflüsse von Mitarbeitern Auswirkungen auf deren Verhalten am Arbeitsplatz haben. Klar zu nennen sind jedoch die größten Einflussfaktoren auf die betriebliche Tätigkeit:
- Ausbildung / Bildungsstand
- Motivation
- Identifikation mit dem Unternehmen / Projekt
- Entlohnung
Alle aufgeführten Risikotreiber verhalten sich antiproportional zum Risiko.
3.1.1.2 Technologie
In dieser Kategorie finden sich alle direkt in den Eigenschaften einer Technologie begründeten Risiken wieder. Sicherlich sind viele technologische Fehler mittelbar auf menschliches Fehlverhalten zurückzuführen, was für die Kategorisierung jedoch unerheblich ist. Ein Fehler bei der Entwicklung einer Maschine würde beim Hersteller eventuell in die Kategorie "menschliche Risiken" eingegliedert, beim Käufer (und/oder Nutzer) der Maschine stellt dies jedoch ein technologisches Risiko dar. Technologische Risiken treten hierbei wie folgt in Erscheinung:
- Ausfall
- Fehlende Eigenschaften
- Mangelnde Effizienz
Risikotreiber:
Für den Bereich der technologischen Risiken sind ausreichende Informationen zu den kausalen Zusammenhängen vorhanden, sodass die Treiber für ein bestimmtes Risiko nahezu vollständig ermittelt werden können. Die Schwierigkeit besteht darin, Einzelrisiken klar voneinander abzugrenzen und entsprechende Gesamtrisiken zu bilden. Beispielsweise kann ein Risikotreiber für "Ausfall der Produktion" der "Ausfall Maschine A" sein, da diese zwingend erforderlich ist. Gleichzeitig stellt "Ausfall der Spannungsversorgung" einen Risikotreiber für den "Ausfall der Maschine A" dar. Ob die Spannungsversorgung nun lediglich ein Risikotreiber, zusätzlich noch ein eigenes Risiko oder gar ein aggregiertes Risiko mit eigenen Risiken als Treiber darstellt, kann nicht allgemeingültig festgelegt werden. Die Gliederungstiefe hängt vom Anteil am Gesamtrisiko ab und wird sinnvoll mit der #Risikoereigniskette dargestellt. Häufig anzutreffende Risikotreiber sind:
- Komplexität
- Einsatzdauer
- Auslastung
- Reifegrad
- Wartung
- Kontrolle
Die ersten drei Risikotreiber verhalten sich proportional zum Risiko, die lezteren antiproportional.
3.1.1.3 Prozessrisiken
Das Risikopotenzial von Projekten ist bekanntlich sehr groß, da diese einmalige Vorhaben sind, verbunden mit individuellen Anpassungen.
Sie äußern sich durch:
- Unzureichend ausgeprägte Kontrollmechanismen
- Unvollständig definierte und implementierte Prozesse
- Mangelnde bzw. inkonsistente Rollendefinitionen
Quelle: 20 (S. 18)
Risikotreiber:
- Prozesskomplexität
- Unternehmenskultur (Fehlerkorrektur)
- Automatisierungsgrad
3.1.1.4 Externe Risiken / Umweltrisiken
Alle Risiken, die im Unternehmen bzw. Projekt selbst begründet sind, lassen sich in die zuvor genannten Kategorien einteilen. Die verbleibenden Risiken, die nicht direkt einem Bestandteil der Organisation zuzuordnen sind, sondern von außen auf diese einwirken, sind sogenannte Umweltrisiken. Dies ist quantitativ der größte Teil von Einzelrisiken, welche gleichzeitig schwer zu bewerten sind. Deshalb wird sich meist auf die Betrachtung von Risiken mit kritischer Bedeutung für das Gesamtrisiko und gut zu bewertende Risiken beschränkt. Zu diesen gehören Markt- und Wettbewerbsrisiken, Finanzrisiken, administrative und legislative Risiken, Naturereignisse.[22]
Beispiele aus der unternehmerischen Praxis:
- Allgemeiner Preisverfall am Absatzmark
- Nachfragerückgang
- Rohstoffkosten
- Personalkosten
- Zinsveränderungen
- Kriminalität (Diebstahl / Betrug / Korruption)
- Streichen von Subventionen
- Strengere Auflagen
- Steuererhöhungen
- Überschwemmungen
Risikotreiber:
- Gesetzgebung
- Zentralbankaktivität
- Konkurrenzsituation (Marktverteilung / Anzahl der Konkurrenten)
- Umweltverschmutzung
- Einkommenssituation im Absatzmarkt
3.1.1.5 Schadenskategorisierung
Neben der oben aufgeführten Kategorisierung der Risiken nach deren Ursachen wird sehr häufig ebenfalls nach deren Auswirkungen differenziert:
- Monetäre Risiken/Effizienzrisiken: durch entgangenen Gewinn oder erhöhten Verlust .
- Qualitative Risiken: verminderter oder falscher Leistungsumfang, geringe Systemverfügbarkeit, Zeitverzug.
- Reputationsrisiken: verminderte oder negative Wahrnehmung des Unternehmens oder der Marke in der Öffentlichkeit.
Derartige Risiken können oft nur sehr schwer identifiziert werden. Beim IT–Risikomanagement bilden die Systemverfügbarkeit, insbesondere die IT–Sicherheit, der Datenschutz und deren Risikotreiber, ein hohes Potenzial. Weiterhin können Projektrisiken nach deren Zeiträumen unterschieden werden.
In den vorherigen Teilen wurden Risiken ihrer Eintrittswahrscheinlichkeit und Schadenshöhe nach bewertet, sowie ihrer Ursache oder Auswirkung nach kategorisiert. Ein weiteres wichtiges Kriterium für den Umgang mit einem Risiko ist die Zeit. „Je länger mit der Existenz eines Risikoszenarios gerechnet werden muss, desto sinnvoller erweisen sich bei gleicher Eintrittswahrscheinlichkeit und erwarteter Schadenshöhe die Einleitung von entsprechenden Gegenmaßnahmen.“ [21](S. 19/20)
3.1.1.6 Zeitliche Kategorisierung
Kurzfristige Risiken
Kurzfristige Risiken sind temporäre Risiken, die sich zumeist auf einmalige Situationen, d. h. oftmals erst kurzfristig ergeben und schwierig vorherzusehen sind.
Das Risikopotenzial zeigt sich über das Bestehen des Risikos mit hoher Wahrscheinlichkeit beständig. Beispiele hierfür sind:
- Projektrisiken bei Kleinprojekten
- Risiken in Ausnahmesituationen
Mittelfristige Risiken
Mittelfristige Risiken zeichnen sich durch ein erwartetes Ende aus, das durchaus beschrieben werden kann.
Das erwartete Ende liegt bei etwa einem bis fünf Jahren. Beispiele hierfür sind:
- Risiken aus dem Betrieb eines konkreten Anwendungssystems heraus
- Projektrisiken bei Großprojekten
Langfristige/permanente Risiken
Bei langfristigen Risiken geht man von einem Zeithorizont von über 5 Jahren aus, permanente Risiken bleiben andauernd bestehen. Maßnahmen zur #Reduktion, #Streuung und #Vermeidung können hier mit höherem Aufwand betrieben werden.
Operative Risiken
Operative Risiken bewirken vorwiegend einen konkreten Einzelfall. Das bedeutet, dass die Zuordnung von Entscheidung und Wirkung unkompliziert erfolgen kann.
Die hier beschriebenen Möglichkeiten zur Kategoriesierung stellen lediglich unterschiedliche Sichtweisen auf das Risikoportfolio dar und ergänzen sich gegenseitig. Abhängig von der Situation, dem Projekt oder den eingesetzten Methoden sind andere Einteilungen der Risiken sinnvoll. Das unterstreicht die Bedeutung einer durchgängigen #Strategie, an der sich sowohl die Methoden als auch die entsprechende Kategorisierung bei der #Bewertung ausrichten.
3.1.2 Spezielle IT-Risiken[16]
Hier werden einige wesentliche spezielle IT–Risiken dargestellt, die sich unmittelbar aus der IT–Betriebsnutzung der IT–Abteilungen, der Anwender und der Durchführung von IT–Projekten ergeben können:
Bei Risiken, die speziell im Umgang mit Informationstechnologie auftreten, spricht man oft vom "Operational Risk". Eine allgemeingültige Definition des Begriffs ist derzeit nicht verfügbar. Eine abstrakte Definition aus Eigenschaften geben Johanning&Rudolf: “Operational Risk ist das Risiko von Verlusten durch menschliches Versagen, fehlerhafte Managementprozesse, Natur- und sonstige Katastrophen, Technologieversagen und Änderungen im externen Umfeld“.[23] Im Umkehrschluss lässt sich also sagen: “Alle Risiken, die nicht Marktpreis oder Kreditrisiken sind”.
IT-Risikien entstehen entlang der gesamten Wertschöpfungskette der Informationstechnik eines Unternehmens. Sie entstehen aus der mangelden Verfügbarkeit von IT-Systemen. Im Folgenden werden die Teilbereiche der Risikoentstehung einzeln aufgeführt:
Anwender IT–Risiken:
„Diese IT-Risiken wirken sich in der mangelnden Leistungserstellung des eigentlichen Geschäftszwecks des Unternehmens aus.“
Die Fachbereiche des Unternehmens haben das Risiko, dass die IT–Abteilung nicht die erforderlichen Leistungen in quantitativer, qualitativer und terminlicher Hinsicht zur Verfügung stellt. Dies betrifft insbesondere Risiken aus der Verfügbarkeit und Sicherheit der benötigten Anwendungen und deren zukünftige Entwicklung.
Originäre Risiken:
Hierbei handelt es sich um Risiken, die in der IT–Abteilung im Unternehmen selbst oder beim Outsourcing-Partner entstehen.
Dies sind Leistungen bei der Zulieferung in der IT–Abteilung oder in dessen eigener Verantwortung.
Projektrisiken:
Projektrisiken ergeben sich aus dem Ergebnis eines oder mehrerer Projekte und beziehen sich auf:
- Ressourcenverbrauch
- Zeitrahmen
- Inhaltliche Projektziele
- Anzahl der Projekte
Anwendungsentwicklungsrisiken:
- Fehler in der Konzeption
- Mangelhafte Dokumentation
- Einführung der erarbeiteten Lösungen
- Wechsel der Anforderungen/unklare Anforderungen
- Latente/versteckte Fehler
Laut einer Studie[2] sind häufig wechselnde und nicht spezifizierte Anforderungen während der gesamten Projektphase der größte Risikotreiber für das Scheitern von Projekten der Softwareentwicklung. -> siehe Abbildung X
Betriebsrisiken:
Betriebsrisiken stellen das Risiko aus dem laufenden Betrieb der IT–Lösung dar:
- Anwendungen stehen nicht zur Verfügung
- IT–Sicherheit wird nicht eingehalten
- Fehler, die sich aus der Administration der Anwendung ergeben
Vertraulichkeitsrisiken:
Das sind Risiken, die sich aus den Gefahren ergeben, dass Daten von anderen als den berechtigten Nutzern einsehbar- oder gar änderbar sind.
Authentifizierungsrisiken:
Diese ergeben sich unmittelbar aus den Vertraulichkeitsrisiken und haben ihre Bedeutung bei Datenübertragungen über Systeme Dritter (z. B. Internet).
Hierdurch wird nachgewiesen, dass die übertragenen Informationen vom berechtigten Partner stammen.
3.2 Effektives Risikomanagement in IT–Projekten
3.2.1 Theoretische Ansätze[1]
Nachdem in den vorherigen Abschnitten die Risiken beschrieben und kategorisiert wurden, die in der wirtschaftlichen Tätigkeit eines Unternehmens und insbesondere in Projekten und hier speziell in IT–Projekten auftreten können, soll hier darauf eingegangen werden, wie mit diesen Risiken umgegangen werden kann.
An dieser Stelle soll nochmals darauf hingewiesen werden, dass IT–Projekte ein außerordentlich hohes Risiko in der Planung, Steuerung und Durchführung haben. Dies liegt insbesondere im Charakter von Projekten begründet, dass Projekte immer einmalige Vorhaben sind und speziell entwickelt und implementiert werden. An dieser Stelle soll auf den wesentlichen Zusammenhang von Kosten, Zeit und Qualität der IT–Projekte hingewiesen werden.
Das effiziente Risikomanagement beginnt in der zielgerichteten Umsetzung seiner #Prozesse.
Identifikation:
Bei der Identifikation bzw. Analyse der projektrelevanten Risiken aus der konkreten projektindividuellen Risikosituation müssen die einzelnen Risiken beschrieben werden (siehe Abschnitt 3.1.)
Assessment:
Hier werden die identifizierten Projektrisiken mit den beschriebenen Methoden detailliert dargestellt und bewertet.
Entscheidend ist ihre Relevanz für den Projektverlauf und eine Auswahl der besonders bedeutsamen und bedrohlichen Risiken.
Hierbei spielt die Größe und Toleranz der Risiken eine entscheidende Rolle.
Dabei werden folgende drei Schritte unterschieden:
- Möglicher Risikoschaden wird in GE bewertet
- Eintrittswahrscheinlichkeit wird ermittelt
- Identifizierung der Risiken, die besonders intensiv betrachtet werden müssen
Reaction:
Hier werden dann die Strategien zu den relevanten Risiken ermittelt und anschließend Strategien zur Risikobewältigung festgelegt.
„Reaction“ kann hier mit Reaktion auf ein Risiko übersetzt werden.
An dieser Stelle soll dargelegt werden, wie die Projektrisiken behandelt bzw. umgangen werden können, die von den jeweiligen Projektbeteiligten auch beherrscht bzw. beeinflusst werden können. Auf diese Aspekte wird nachfolgend eingegangen als einen wirkungsvollen effektiven Beitrag für das Risikomanagement in IT–Projekten:
Service-Level-Management (SLM):
Das SLM vereinbart und überwacht permanente Leistungen, welche die IT ihren Abnehmern zur Verfügung stellt.
Hierzu werden Vereinbarungen zwischen IT und den einzelnen Fachbereichen, sog. SLA (Service-Level-Agreements) getroffen. Diese beinhalten wirtschaftliche und technische Aspekte und somit implizit deren Risikobetrachtungen.
Die Wirtschaftlichkeitsbetrachtung wird hier vorrangig von den jeweiligen Fachbereichen durchgeführt. Hierbei muss festgestellt werden, ob der fachliche Mehrwert die verursachenden Kosten rechtfertigt. Die Höhe der Absicherung durch einen solchen Service kann eine wesentliche Rolle bei einem nicht qualitätsgerechten Leistungsumgang durch den IT–Bereich spielen. Hierbei kann ein entsprechender Kompromiss bzw. eine Priorisierung der IT–Leistungen zwischen den Fachbereichen und der IT–Abteilung nötig sein. Ziel ist dabei, das mögliche Ausfallrisiko von geschäftsrelevanten IT–Prozessen zu vermeiden sowie einzugrenzen. Dabei werden weniger wichtige Anwendungen mit schlechteren Service–Leistungen versehen als kritische Anwendungen. Der IT–Bereich muss dann prüfen, welche Qualitäten von Services technisch geboten werden können und die dabei auftretenden Kosten darlegen. Das SLM wird für permanente Leistungen angewendet, während das IT–Risikomanagement weiterhin die Risiken bei Permanent- und Einzelleistungen mitberücksichtigt.
Qualitätsmanagement:
Das Qualitätsmanagement stellt eine operative Unterstützung des IT–Risikomanagements im Sinne der Erarbeitung von Risikoreduzierungsmaßnahmen dar.
Dem Qualitätsmanagement werden häufig Risiken mit sehr hoher Eintrittswahrscheinlichkeit zugeordnet, während beim Risikomanagement Risiken mit geringer Eintrittswahrscheinlichkeit behandelt werden.[21](S. 35)
IT–Projektcontrolling:
Beim IT–Projektcontrolling steht im Fokus der Betrachtung das Risiko, dass eine bestimmte Leistung von der IT–Abteilung nicht erbracht werden kann.
IT–Projektcontrolling bezieht sich in seiner Betrachtungsweise stärker auf die Anwender-IT–Risiken.
Projektcontrolling muss die Risikosituation in den jeweiligen Projekten abdecken.
Im Gegensatz zum Projektcontrolling betrachtet das Risikomanagement hauptsächlich zukünftige Ereignissen. [21](S. 36-37)
IT–Security:
Die IT–Security beinhaltet Sicherungsmaßnahmen bis auf Systemebene hinunter. Teil der Sicherungsfunktion ist die Technik selbst, die sich nicht mehr mit fachlicher Logik befasst, sondern rein technische Protokolle und Datenströme überwacht, wie z. B. Firewallsysteme, Intrusion-Detection-Systeme. Das IT–Risikomanagement betrachtet die einzelnen Sicherheitskomponenten im Ganzen und hat daher im Gegensatz zur IT–Security ein höheres Abstraktionslevel, wobei die Ziele der IT–Security vollständig im IT–Risikomanagement enthalten sind.
Bei den Wirtschaftlichkeitsbetrachtungen wird bspw. untersucht, ob der Einsatz eines Firewallsystems die dadurch erreichte Risikoreduzierung rechtfertigt.
Im Gegensatz zum IT–Risikomanagement bezieht sich die IT–Security auf die Risiken mit deren Auswirkungen auf den Systembetrieb. Hierbei stehen daher die unternehmensspezifischen IT–Sicherheitsbestimmungen im Vordergrund. Das IT–Risikomanagement bezieht sich daher auf weitere Leistungsbereiche der IT, beispielsweise die Anwendungsentwicklung oder Organisationsberatung. Das IT–Risikomanagement stellt somit eine gute Verbindung zwischen den Fachbereichen und dem technikorientierten IT–Security-Management dar. [1] (S. 31-33)
3.2.2 Praktische Umsetzung
In diesem Kapitel sollen praktische Handlungsanweisungen aufgezeigt werden, wie IT– Risikomanagement in IT–Projekten gelebt werden kann, um der obersten Zielstellung einer möglichst hohen Risikobeherrschung gerecht zu werden.
Betont werden muss hierbei, dass es nicht möglich ist, alle IT–Projektrisiken auszuschalten, man sich ihrer jedoch bewusst werden kann und sie sich durch entsprechendes Führungsverhalten und die Verhaltensweisen der Projektmitglieder eingeschränken lassen.
Vorweg soll betont werden, dass das beste Risikomanagement nicht durch autoritäres Führungsverhalten von oben verordnet werden kann. Daher möchte ich nachfolgend einige Thesen zu den Prinzipien eines wirkungsvollen und somit effektiven Risikomanagements vorstellen, die aus dem Buch „IT-Risikomanagement leben!“ entnommen sind und sich speziell auf die Softwareentwicklung beziehen, jedoch auf alle Spielarten von IT–Projekten übertragen werden können:
Thesen für wirkungsvolles Risikomanagement:
- Verteilen Sie Risikobewusstsein und Risikoverantwortung.
- Betreiben Sie Projektmanagement als Risikomanagement und umgekehrt.
- Fördern Sie eine offene und professionelle Risikokommunikation und – kultur.
- Lernen Sie von anderen.
- Passen Sie den Risikomanagementprozess an und benutzen Sie ihn.
- Integrieren Sie den Risikomanagementprozess in Ihre vorhandenen Prozesse.
- Nutzen Sie bewusst das Prinzip der Evolution für sich!
- Lernen Sie schätzen.
- Überblicken Sie die Wirtschaftlichkeit.
- Risikomanagement handelt von den Menschen.
These 1: Verteilen Sie Risikobewusstsein und Risikoverantwortung
Die wahrscheinlichste Ursache für interne Risiken ist die allzu menschliche Unwissenheit über Sachverhalte, Technologien, Menschen und Methoden, Machtverhältnisse etc. Wir wissen einfach nicht genug.
Ursachen: 1. Komplexität heutiger Vorhaben 2. eingeschränkte Perspektive heutiger Vorhaben
Lösungsansatz: Der Ansatz eines effektiven Risikomanagements muss breiter werden und die Herausforderungen der Komplexität und Perspektive berücksichtigen: Verteilung von Risikobewusstsein 1. Verteilung von Risikoverantwortung 2. Verteilung von Risikobewusstsein
Qualitätskriterien: 1. Risiken werden verteilt identifiziert, analysiert und überwacht. 2. Kommunikationskanäle für das Risikomanagement sind geschaffen und werden genutzt. 3. Die Verantwortlichkeiten im Risikomanagementprozess sind definiert. 4. Risikoindikatoren sind aufgestellt und werden verteilt überwacht.
[24](S. 61 – 67)
These 2: Betreiben Sie Projektmanagement als Risikomanagement und umgekehrt
Das Projektmanagement plant die Zukunft, es werden Visionen entwickelt, wie etwas aussehen wird und wie dies und bis wann es erreicht werden kann.
Da das Risikomanagement sich mit den Bedrohungsszenarien für diese geplante Zukunft auseinandersetzt, muss es integraler Bestandteil des Projektmanagements sein.
Aufgaben: 1. Die Risikobetrachtung ist Grundlage von Entscheidungen. 2. Es existieren qualitativ hochwertige Arbeitsprodukte aus dem Risikomanagement. 3. In generellen Arbeitsprodukten findet eine Risikobetrachtung statt. 4. Zielvereinbarungen erhalten Risikomanagement als Aufgabenbeschreibung der Projektrollen.
[24](S. 67 – 71)
These 3: Fördern Sie eine offene und professionelle Risikokommunikation und –kultur
Die Projektmitarbeiter können Projektrisiken am besten benennen. Durch das schlechte Image (Probleme, Schaden, Kosten) des Begriffs des Risikos werden die Projektmitarbeiter jedoch allzu oft davon abgehalten, diese innerhalb des Projektes offen zu benennen.
Die dazu erforderliche Risikokultur ist das Ergebnis, wie die Organisation bzw. das Projekt mit den Risiken umgeht: (a) Wird der Entdecker des Risikos bestraft oder belohnt? (b) Können alle Mitarbeiter entdeckte Risiken zweckmäßig kommunizieren? (c) Ist die Organisation eine „Mund–Halten“ oder „Nicht-Hinhören-Organisation“?
Entwicklung von geeigneten Verhaltensweisen:
1. Risikokultur von oben: Die Projektleitung lebt eine vertrauensvolle und offene Risikokultur vor. 2. Risikokultur von unten: Die Projektmitarbeiter arbeiten aktiv am Risikomanagement mit. 3. Risikokultur von ganz oben: Die Geschäftsleitung und der Projektsteuerkreis sind an einem erfolgreichen Risikomanagement interessiert.
[24](S. 71 – 73)
These 4: Lernen Sie von anderen
Teilspekte: 1. Lernen Sie von erfahrenen Mitarbeitern. 2. Lernen Sie aus den TOP–Risikolisten. 3. Lernen Sie aus Risikosammlungen. 4. Lernen Sie von den Erfolgsfaktoren anderer IT–Projekte.
Erfolgsfaktoren: 1. Unterstützung durch das Management 2. Beteiligung der Anwender 3. Erfahrene Projektleiter 4. Klare geschäftliche Zielvorgaben 5. Begrenzter Projektrahmen 6. Standardisierte Softwareinfrastruktur 7. Stabile Basisanforderungen 8. Formale Methoden 9. Verlässliche Schätzungen 10. Weiteren Faktoren
- Zeitlich zusammenhängende Meilensteine - Gute Planung - Kompetente und motivierte Mitarbeiter - Mitarbeiterverantwortung [24](S. 80 – 83)
These 5: Passen Sie den Risikomanagementprozess an und benutzen Sie ihn
Die Einführung des Risikomanagements in Unternehmen erfordert zunächst grundsätzlich, dass sich die Beteiligten mit dem eigentlichen Risikomanagementprozess in seinen klassischen Phasen aus Risikoidentifikation, Risikosteuerung, Risikoanalyse und Risikoüberwachung vertraut machen. Dabei ist es nicht entscheidend, welches Modell hierbei eingesetzt wird. Der Prozess sollte einerseits immer diese vier Grundphasen widerspiegeln und andererseits an die Geschäftsprozesse der Unternehmen oder Projekte angepasst werden. Diese erarbeiteten Prozesse sind nunmehr strukturiert zu dokumentieren. Hieraus werden dann zu den jeweiligen Aktivitäten die jeweiligen Verantwortlichkeiten der Mitarbeiter festgelegt bzw. zugewiesen. Zum Schluss geht es um die Umsetzung und die dazu benötigten Techniken und Methoden, um die einzelnen Prozessphasen zu realisieren.
Fragestellungen zu den Techniken für die Umsetzung der Aktivitäten: (1) Wie werden Risiken identifiziert? (2) Wie werden die identifizierten Risiken identifiziert und dokumentiert? (3) Wie werden die Risiken analysiert und dokumentiert? (4) Wo sind unsere Akzeptanzprobleme für Risiken? (5) Wie können die Risiken überwacht werden? (6) Wie werden Maßnahmen definiert? (7) Wie können Maßnahmen definiert werden? (8) Wie können die Maßnahmen gesteuert und überwacht werden? (9) Wie kann der Risikomanagementprozess bzw. das gesamte System optimiert und überwacht werden?
Zusammenfassung als Checkliste des Risikomanagementprozesses:
(1) Definieren Sie einen Risikomanagementprozess und passen Sie diesen an individuelle Gegebenheiten an! (2) Dokumentieren und kommunizieren Sie den Prozess! (3) Definieren Sie für jeden Prozessschritt Input und Output! Was kommt herein? Was kommt heraus? (4) Leiten Sie einzelne Aktivitäten der Prozessschritte ab und ordnen Sie sie einem Verantwortlichen zu! (5) Legen Sie Methoden und Techniken für die Umsetzung der Aktivitäten fest! (6) Ergänzen Sie die Dokumentation und finalisieren Sie diese!
[24](S. 83 – 86)
These 6: Integrieren Sie den Risikomanagementprozess in Ihre vorhandenen Prozesse
Hierbei geht es darum, die „Schnittstellen“ zwischen den Risikomanagementprozessen und den im Unternehmen integrierten Geschäftsprozessen zu bestimmen und darauf aufbauend in die standardisierten Abläufe im Unternehmen, wie regelmäßige Meetings, Dokumentationen, Statusberichte (ohne viel Mehraufwand, jedoch mit hohem Mehrwert) zusammenzubringen. Hierbei hat die Regelmäßigkeit einen hohen Stellenwert. So kann z. B. die Risikoidentifikation doch mit der Iterationsplanung im Arbeitsschritt Projektmanagement zusammengebracht werden. Somit findet bei jeder Iterationsplanung dann ein Workshop zur Risikoidentifikation statt.
Jeder neu eingeführte Prozess sollte in vorhandene Prozesse integriert werden, damit der Risikomanagementprozess zur Gewohnheit werden kann.
[24](S. 86 – 87)
These 7: Nutzen Sie bewusst das Prinzip der Evolution für sich!
Hier soll dem Grundsatz: „Lernen Sie aus den eigenen Fehlern!“ gefolgt werden. Dies folgt aus der Notwendigkeit der permanenten Anpassung des Risikomanagements, indem bestehende Fehler behoben werden und das Risikomanagement somit kontinuierlich auf der Grundlage gewonnener Erfahrungen optimiert werden kann.
Bestandteile dieser These:
(1) Wie bewerte ich meinen eigenen Risikomanagementprozess derzeit? Stimmen die Ergebnisse? (2) Wie kann der Risikomanagementprozess optimiert werden? Wer ist dafür zuständig?
Besonderes Gewicht kann dabei den Mitarbeitern zukommen, die ermutigt werden sollen, Verbesserungsvorschläge beizusteuern. Hierbei wird nach der Post-Mortem-Analyse nach jedem Projekt, eben am Ende eines speziellen Risikomanagementprozesses, ein umfassender Rückblick durchgeführt. Hier wird kritisch überprüft, um festzustellen, ob das Risikomanagementsystem seine Aufgaben und Ziele erfüllt hat. Hierbei stehen folgende Fragen im Vordergrund, die hierbei beantwortet werden sollen:
(1) Was lief besonders gut? Was lief nicht gut? (2) Hat das Risikomanagement seine Ziele erfüllt? (3) Können Risiken früh genug behandelt werden? Konnte ihr Eintreten und Schadensausmaß minimiert oder ganz verhindert werden? (4) Waren alle Mitarbeiter effektiv am Prozess beteiligt? (5) Wurden effektive Strategien und Maßnahmen gewählt? Wurden die Maßnahmen gut bzw. überhaupt umgesetzt? (6) Welche Risiken wurden nicht rechtzeitig erkannt und warum? (7) Sind neue noch unbekannte Risiken aufgetreten?
[24](S. 87 – 90)
These 8: Lernen Sie schätzen
Risiken sind unmessbar und müssen daher entsprechend wertmäßig eingeschätzt werden. Als Hilfsmittel ist dabei die Gleichung hilfreich: allgemeine Schadensformel: Schadensmaß = Eintrittswahrscheinlichkeit * Risikohöhe.
Diese Gleichung beruht aber auf ungenauen Zahlengrößen, da es z. B. sehr schwierig, ja fast unmöglich ist, die Risikohöhe eines Imageschadens, der durch die verspätete Auslieferung der Software entsteht, einzuschätzen.
Schätzmodelle:
1. Schätzung direkt aus dem Aufwand heraus berechnen 2. Auf der Basis früherer ähnlicherer Aktivitäten den gegenwärtigen Aufwand ableiten 3. Expertenurteil einholen, das den Umfang bewertet
Diese Schätzmodelle sind jedoch nur begrenzt einsetzbar, da Risiken insbesondere bspw. bei Software weder in festen Maßen noch durch Analyse direkt zu greifen sind. Daher sollte hier ein bewusstes Schätzen erfolgen, das generell bewusst reflektiert werden sollte.
[24](S. 90 – 95)
These 9: Überblicken Sie die Wirtschaftlichkeit
Fragestellung:
Wann lohnt sich der Aufwand für ein Risikomanagement?
Wer bewusst auf einen kontrollierten Umgang mit Risiken verzichtet, handelt grob fahrlässig. Es stellt sich somit eher die Frage nach der Ausgestaltung des Risikomanagements, nicht nach der Darseinsberechtigung.
An dieser Stelle soll nochmals darauf hingewiesen werden, dass bei aktiver Senkung des Schadensausmaßes für den Risikoeintritt auch die Kosten für die Sicherungsmaßnahmen (Vermeidung und Verminderung) steigen. Zudem ist es in jedem Fall effizienter, hohe Gesamtrisikokosten zu verkleinern, als geringe Kosten noch zu minimieren. Daher muss Risikomanagement den Grundsätzen der Wirtschaftlichkeit entsprechen, wie dies an anderen Stellen der Fallstudie bereits ausgeführt wurde.
Hierbei sollten jedoch auch die Chancen betrachtet bleiben, die sich hieraus ergeben und diese sind insbesondere mit der Frage nach dem „Warum“ zu beantworten:
Warum sollten wir das beträchtliche Risiko eines Softwareentwicklungsprojektes auf uns nehmen?
Chancen:
1. Strategischer Vorteil 2. Produktivitätssteigerung 3. Kostensenkung 4. Umsatzvergrößerung
[24](S. 95 – 99)
These 10: Risikomanagement handelt von den Menschen
Das zentrale Element des Risikomanagements ist der Mensch mit folgenden Betrachtungsaspekten: (1) Relevanz des Menschen: Mix aus Motivation, Verantwortung, Wissen, Risikobewusstsein, Verlässlichkeit usw.
(2) Kommunikation und Vernetzung: Ohne Risikobewusstsein keine horizontale Risikokommunikation, ohne Kommunikation und Offenheit keine realistischen Risikoanalysen, ohne Berücksichtigung der Risikoanalysen in Entscheidungen keine Motivation, das nächste Risiko zu entdecken.
(3) Relevanz von uns: Hier geht es darum, ein optimales Verhältnis zwischen formalen Prozessen und menschlicher Kreativität einzustellen, das für alle Beteiligten ein wünschenswertes Ergebnis gestattet.
Das Einzige, was wir wirklich ändern können, sind wir selbst.
[24](S. 99 – 101)
4 Schlussbetrachtung
Diese Fallstudie zeigte auf, welche Risiken in Unternehmen und bei der IT–Leistungserstellung auftreten können und wie strukturiert und kontrolliert mit diesen zu verfahren ist. Die Frage, ob ein Risikomanagement in einem Unternehmen oder einem Projekt etabliert werden sollte, ist schon in der Definition des #Risikomanagements beantwortet. Wer bewusst auf einen kontrollierten Umgang mit Risiken verzichtet, handelt grob fahrlässig.
Vielmehr stellt sich die Frage nach der Ausgestaltung des Risikomanagements. Bei einem kleineren Projekt lohnt es kaum, ein IT-gestütztes Risikomanagement aufzufahren bzw. eine aufwendige #FMEA - Failure Mode and Effects Analysis durchzuführen. Ein einfaches Brainstorming der Projektteilnehmer und eine gewissenhafte Schadensanalyse sowie die Dokumentation und Kommunikation der Risiken ist durchaus als angemessenes Risikomanagement zu werten. Die Frage der Installation eines wirkungsvollen IT–Risikomanagements kann in erster Linie aus dem Wirtschaftlichkeitsprinzip bzw. aus wirtschaftlichen Betrachtungen hergeleitet werden. Veranschaulicht wurde dies insbesondere im in Abschnitt #Steuerung bereits beschriebenen Pareto–Prinzip.
Hierfür stehen dem Management in Unternehmen verschiedene Methoden des IT–Risikomanagements zur Verfügung, die in unterschiedlichen IT–Risikoprozessen angewandt werden können.
Ausgehend davon, das mittels IT–Risikomanagement die Kosten bei der Durchführung von IT–Projekten beherrschbar werden, Termine eingehalten und die Qualität von IT–Projektleistungen signifikant erhöht werden, zeigte diese IT–Fallstudie auf, welche Methoden, Prozesse zur Verfügung stehen, allgemeine und spezielle IT–Risiken zu bewerten und wirkungsvolle Maßnahmen zur Risikobeherrschung zu entwickeln.
Betont werden soll an dieser Stelle, dass IT–Risikomanagement immer dann seine volle Wirkung entfalten kann, wenn dies unmittelbar in der IT verankert wird. Besonders deutlich kommt dies beim Projektmanagement zum Ausdruck. Risiken können mit IT–Risikomanagement beherrschbar gemacht werden, jedoch nicht „ausgeschaltet“ werden. Ein zu tragendes Restrisko bleibt.
Der entscheidende Faktor bei der Beherrschung von IT–Risiken ist hierbei der Mensch, insbesondere mit seinen Fähigkeiten und Verhaltensweisen. Hier stehen insbesondere den Führungskräften auch in Zukunft noch entscheidende Herausforderungen bevor.
Mit dieser Fallstudie wurde aufgezeigt, dass es sich lohnt, ein wirkungsvolles Risikomanagement sowohl im IT–Tagesgeschäft als auch und insbesondere im IT–Projektmanagement zu entwickeln und zu installieren. Die beschriebenen #Prozesse_des_Risikomanagements und #Methoden_des_Risikomanagements geben dem Management einige praktische Hilfestellungen, um das Risikomanagement erfolgreich im IT–Projektgeschäft umzusetzen.
5 Quellen
- ↑ 1,0 1,1 1,2 Wack Jessica: Risikomanagement für IT-Projekte, 1. Auflage, Deutscher Universitätsverlag, 2007, k. o.
- ↑ 2,0 2,1 Richter Gérard, Dr. Bender Kai, Klinger Matthias, Dr. Herbolzheimer Claus: Projekte mit Launch Management auf Kurs halten, Studie, Roland Berger, 2008, kein Ort
- ↑ Prof. Dr. Renn Ortwin; Die subjektive Wahrnehmung technischer Risiken
- ↑ Slaby Martin,Urban Dieter:Risikoakzeptanz als individuelle Entscheidung, ifs, 2002, Stuttgart>
- ↑ DIN EN ISO 14971
- ↑ Dr. Gleißer,Werner,Romeike,Frank: Risikomanagement,1. Auflage 2005,Haufe,Müchen
- ↑ LinkWolke, Thomas:Risikomanagement Oldenburg 2007,München
- ↑ Mangold, Pascal: IT-Projektmanagement kompakt,2. Auflage 2004,Spektrum Verlag, Berlin
- ↑ Wieczorrek,H.W.,Mertens,Peter: Management von IT-Projekten,2005, Springer Verlag, Berlin
- ↑ Kitz, Andreas: IT-Projektmanagement,2004, Galileo Press, Bonn
- ↑ Prokein, Oliver: IT-Risikomanagement 2008, Gabler Edition Wissenschaft
- ↑ 12,0 12,1 12,2 12,3 12,4 Romeike Frank: Erfolgsfaktor Risikomanagement, Gabler, 2003, Wiesbaden
- ↑ 13,0 13,1 Dr. Gleißner, Werner: Grundlagen des Risikomanagements im Unternehmen, Vahlen, 2008, München
- ↑ 14,0 14,1 http://www.finanzen-lexikon.de/lexikon/worst-case-szenario.htm
- ↑ Prof. Dr. Ehrmann, Harald: Risikomanagement, Kiehl Verlag, 2005, Leipzig
- ↑ 16,0 16,1 16,2 Keitsch Detlef: Risikomanagement, Schäffer, Pöschel, 2007, Stuttgart
- ↑ 17,0 17,1 http://dict.leo.org
- ↑ 18,0 18,1 Schmitz Thorsten, Wehrheim Michael: Risikomanagement, Kohlhammer, 2006, Stuttgart
- ↑ Latein/Deutsch www.albertmartin.de
- ↑ Müller-Reichart Matthias, Romeike Frank:Risikomanagement in Versicherungsunternehmen,Wiley-VCH, 2004 ,kein Ort
- ↑ 21,0 21,1 21,2 21,3 21,4 21,5 21,6 Seibold Holger: IT-Risiko-Management, 1. Auflage, Oldenbourg Verlag, 2006, München
- ↑ Dr. rer. nat. Kaack Jürgen:Einführung von Risikomanagement in mittelständischen Unternehmen,2006,Perspektive Mittelstand
- ↑ Dr. Johanning Lutz, Prof. Dr. Rudolph Bernd: Handbuch Risikomanagement, Uhlenbruch, 2000 Bad Soden
- ↑ 24,0 24,1 24,2 24,3 24,4 24,5 24,6 24,7 24,8 24,9 Ahrendts Fabian, Marton Anita,IT-Risikomanagement leben!, Springer, 2008, kein Ort
