Risiko-Management: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
Zeile 27: Zeile 27:
 
Vor diesem Hintergrund muss einserseits die Förderung der Zusammenarbeitsfähigkeit von IVS-Akteuren in IVS-Wertschöpfungsketten und -netzwerken und anderseits die Vermeidung der mit der Intensivierung der Zusammenarbeit verbundenen Risiken mittels eines entsprechenden '''IVS-Architektur Risikomanagements''' ein Hauptanliegen von IVS-Architektur sein.
 
Vor diesem Hintergrund muss einserseits die Förderung der Zusammenarbeitsfähigkeit von IVS-Akteuren in IVS-Wertschöpfungsketten und -netzwerken und anderseits die Vermeidung der mit der Intensivierung der Zusammenarbeit verbundenen Risiken mittels eines entsprechenden '''IVS-Architektur Risikomanagements''' ein Hauptanliegen von IVS-Architektur sein.
  
== Ebenen und Schritte im IVS-Architektur Risikomanagement ==
+
== Management der Risiken der Umsetzung von IVS-Archtektur ===
 +
 
 +
=== Ebenen und Schritte im IVS-Architektur Risikomanagement ====
  
 
Risiken sollten auf '''zwei Ebenen''' untersucht und bewertet werden:
 
Risiken sollten auf '''zwei Ebenen''' untersucht und bewertet werden:

Version vom 5. September 2016, 10:02 Uhr


TOGAF =

Identify the risks associated with the Architecture Vision and assess the initial level of risk (e.g., catastrophic, critical, marginal, or negligible) and the potential frequency associated with it. Assign a mitigation strategy for each risk. A risk management framework is described in Part III, 31. Risk Management. There are two levels of risk that should be considered, namely:

  • Initial Level of Risk: Risk categorization prior to determining and implementing mitigating actions.
  • Residual Level of Risk: Risk categorization after implementation of mitigating actions (if any).

Risk mitigation activities should be considered for inclusion within the Statement of Architecture Work.

Risiken bei der Umsetzung von IVS-Architektur

Formen der Zusammenarbeit, Quelle: Reinhard Riedl, Fachhoschule Bern, Wirtschaftsinformatik

Unter Phase a - Schritt 9 wurde dargestellt, welcher Nutzen von IVS-Architektur ausgehen kann und welche Dimension der Wertbeitrag von IVS-Archtektur annhemen kann (siehe auch Wertbeitrag und KPI's von IVS-Architektur .

Die Zusammenarbeit von IVS-Akteuren im Rahmen von IVS-Wertschöpfungsketten und -netzwerken ist jedoch auch mit Risiken verbunden. Über die stufenweise Intensivierung der Zusammenarbeit(Kooperation, Koordination, Kollaboration) hinweg neben die Interpendenzen, das heißt die Abhängigkeiten der IVS-Akteure zu und damit auch die Risisken. Diese können folgende Ursachen haben:

  • Ungenügende kulturelle Voraussetzungen
  • Fehlendes Vertrauen als grösstes Hemmnis für den Erfolg von Teamarbeit
  • Fehlende Zielvorgaben bzw. unklare Aufgabenverteilung
  • Unzureichende Kommunikation, fehlende Standards für Kommunikation
  • Fehlende oder ungenügende Konfliktlösung
  • ...

Vor diesem Hintergrund muss einserseits die Förderung der Zusammenarbeitsfähigkeit von IVS-Akteuren in IVS-Wertschöpfungsketten und -netzwerken und anderseits die Vermeidung der mit der Intensivierung der Zusammenarbeit verbundenen Risiken mittels eines entsprechenden IVS-Architektur Risikomanagements ein Hauptanliegen von IVS-Architektur sein.

Management der Risiken der Umsetzung von IVS-Archtektur =

Ebenen und Schritte im IVS-Architektur Risikomanagement =

Risiken sollten auf zwei Ebenen untersucht und bewertet werden:

  • Ursprüngliches Risiko: Klassifizierung und Bwertung des Risikos vor Umsetzung der IVS-Architektur(maßnahme)
  • Verbleibendes Risiko (Rest-Risiko): Klassifizierung und Bewertung des Risikos nach Umsetzung der IVS-Architektur(maßnahme)

Zur Identfikation und Bewertung einmzelner Risiken werden folgende Schritte empfohlen:

  1. Identifikation möglicher Risiko-Quellen
  2. Identifikation konkreter möglicher Risiken aus den einzelnen Quellen
  3. Bewertung der Risiken nach Eintrittswahrscheinlichkeit und Schwere
  4. Identifikation möglicher Gegenmaßnahmen für kritische Risiken

1. Risiko-Quellen

  • Technik (Technologiekomplexität, Architekturdefizite, Over-Engineering)
  • Sicherheit (Die notwendige Sicherheit kann nicht gewährleistet werden)
  • Information (Informationen fehlen oder sind fehlerhaft)
  • Menschen (Mitarbeiter, personelle Schwächen)
  • Prozesse (Prozesse sind zu starr und können nicht angepasst werden)
  • Management (Das Management unterstützt das Projekt nicht)
  • Externe Quellen (Umwelt, Lieferanten, Gesetze)
  • Erfolg (Ist das Angebot skalierbar, was kann bei zu vielen Anfragen passieren)
  • Anforderungen (unsichere Anforderungen: typisches Projektrisiko, falsche oder gar fehlende Anforderungen
  • Anwendungen (Legacy-Anwendungen können nicht angebunden werden)
  • Kunden bzw. Nutzer (unzureichende Beteiligung, fehlende Akzeptanz)
  • Planung (unrealistisch)
  • Fehler und Qualitätsmängel (Die Lösung enthält Fehler)
  • Unzureichende Projektorganisation (keine Kontrolle der Fortschritts; zu viele oder zu wenige Beteiligte)
  • Finanzen (Die finanzielle Planung ist unzureichend)

2. Konkrete mögliche Risiken

Die IVS-Rahmenarchitektur wird nicht von allen Beteiligten mit getragen. Die Architektur beinhaltet zu konkrete oder zu vage Festlegungen (z.B. im Bezug auf den Umfang von festgeschriebenen Standards). Die verbindliche Einführung der IVS-Rahmenarchitektur scheitert.


3. Bewertung

Die Bewertung der einzelnen konkreten Risiken aus 2. erfolgt anhand der geschätzten Eintrittswahrscheinlichkeit und dem Schweregrad des Risikos bei Eintritt.

Wahrscheinlichkeit (1-5) * Schweregrad (1-5) = Risikokennzahl

Für kritische Risiken (z.B. Risikokennzahl über 15) sollten mögliche Gegenmaßnahmen geplant werden.

4. Gegenmaßnahmen

Mindestens für die Risiken mit hoher Eintrittswahrscheinlichkeit sollten Gegenmaßnahmen überlegt werden.

Template

Media:Risiko-Template