Risiko-Management: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
 
(12 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
  
  
== TOGAF ===
+
== Risiken bei der Umsetzung von IVS-Architektur ==
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.
+
[[File:FormenDerZusammenarbeit 00-00-02.PNG|thumb|right|250px|Formen der Zusammenarbeit, Quelle: Reinhard Riedl, Fachhochschule Bern, Wirtschaftsinformatik]]
*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.
+
Unter Phase A (Architektur Vision) - Schritt 9 wurde dargestellt, welcher Nutzen von IVS-Architektur ausgehen kann und welche Dimension der Wertbeitrag von IVS-Architektur annehmen kann (siehe auch [[Ziele_und_Nutzen|Wertbeitrag und KPI's von IVS-Architektur]]).
  
== Risiken bei der Umsetzung 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 und Kollaboration) hinweg nehmen die <span class="_Tgc">'''Interdependenzen'''</span>, das heißt die Abhängigkeiten der IVS-Akteure, zu und damit auch die Risiken. Diese können folgende Ursachen haben:
  
[[Datei:FormenDerZusammenarbeit_00-00-02.PNG|thumb|right|250px|Formen der Zusammenarbeit, Quelle: Reinhard Riedl, Fachhoschule Bern, Wirtschaftsinformatik]]
+
*Ungenügende kulturelle Voraussetzungen
 +
*Fehlendes Vertrauen als größtes 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
 +
*...
  
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 [[Ziele und Nutzen | Wertbeitrag und KPI's von IVS-Architektur]] .
+
Vor diesem Hintergrund muss einerseits 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.
  
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:
+
== Management der Risiken der Umsetzung von IVS-Architektur ==
  
*Ungenügende kulturelle Voraussetzungen
+
=== Ebenen und Schritte im IVS-Architektur Risikomanagement ===
*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.
+
Risiken sollten auf '''zwei Ebenen''' untersucht und bewertet werden:
  
== Management der Risiken der Umsetzung von IVS-Archtektur ===
+
*Ursprüngliches Risiko: Klassifizierung und Bewertung 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).
  
=== Ebenen und Schritte im IVS-Architektur Risikomanagement ====
+
Zur Identifikation und Bewertung einzelner Risiken werden '''folgende Schritte''' empfohlen:
  
Risiken sollten auf '''zwei Ebenen''' untersucht und bewertet werden:
+
#Identifikation möglicher Risiko-Quellen,
 +
#Identifikation konkreter möglicher Risiken aus den einzelnen Quellen,
 +
#Bewertung der Risiken nach Eintrittswahrscheinlichkeit und Schwere,
 +
#Identifikation möglicher Gegenmaßnahmen für kritische Risiken.
  
* Ursprüngliches Risiko: Klassifizierung und Bwertung des Risikos vor Umsetzung der IVS-Architektur(maßnahme)   
+
=== Risiko-Quellen ===
* 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:
+
*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)
  
#Identifikation möglicher Risiko-Quellen
+
=== Beispiel für Risiken von IVS-Architektur ===
#Identifikation konkreter möglicher Risiken aus den einzelnen Quellen
 
#Bewertung der Risiken nach Eintrittswahrscheinlichkeit und Schwere
 
#Identifikation möglicher Gegenmaßnahmen für kritische Risiken
 
  
=== Risiko-Quellen ===
+
*Die IVS-Rahmenarchitektur wird nicht von allen Beteiligten mitgetragen.
 +
*Die Architektur beinhaltet zu konkrete oder zu vage Festlegungen (z. B. in Bezug auf den Umfang von festgeschriebenen Standards).
 +
*Die verbindliche Einführung der IVS-Rahmenarchitektur scheitert.
 +
*...
  
*Technik (Technologiekomplexität, Architekturdefizite, Over-Engineering)
+
=== Bewertung der Risiken, Gegenmaßnahmen ===
*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)
 
  
=== Beispiel für Risisken von IVS-Architektur ===
+
Die Bewertung der einzelnen konkreten Risiken erfolgt anhand der geschätzten Eintrittswahrscheinlichkeit und des Schweregrades des Risikos bei Eintritt.
*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 ==
+
'''Risikokennzahl = Wahrscheinlichkeit (1-5) * Schweregrad (1-5)'''
  
Die Bewertung der einzelnen konkreten Risiken aus 2. erfolgt anhand der geschätzten Eintrittswahrscheinlichkeit und dem Schweregrad des Risikos bei Eintritt.  
+
Für kritische Risiken (z. B. Risikokennzahl über 15) und für Risiken mit hoher Eintrittswahrscheinlichkeit sollten Gegenmaßnahmen überlegt und geplant werden.
  
Wahrscheinlichkeit (1-5) * Schweregrad (1-5) = Risikokennzahl
+
== Template ==
  
Für kritische Risiken (z.B. Risikokennzahl über 15) sollten mögliche Gegenmaßnahmen geplant werden.
+
[[IVS-Risikomanagement-Template|IVS-Risiko]]
  
== 4. Gegenmaßnahmen ==
+
----
Mindestens für die Risiken mit hoher Eintrittswahrscheinlichkeit sollten Gegenmaßnahmen überlegt werden.
 
  
== Template ==
+
[[Hauptseite|<< Zurück zur Hauptseite]]
[[Media:Risiko-Template]]
 

Aktuelle Version vom 26. November 2017, 00:12 Uhr


Risiken bei der Umsetzung von IVS-Architektur

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

Unter Phase A (Architektur Vision) - Schritt 9 wurde dargestellt, welcher Nutzen von IVS-Architektur ausgehen kann und welche Dimension der Wertbeitrag von IVS-Architektur annehmen 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 und Kollaboration) hinweg nehmen die Interdependenzen, das heißt die Abhängigkeiten der IVS-Akteure, zu und damit auch die Risiken. Diese können folgende Ursachen haben:

  • Ungenügende kulturelle Voraussetzungen
  • Fehlendes Vertrauen als größtes 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 einerseits 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-Architektur

Ebenen und Schritte im IVS-Architektur Risikomanagement

Risiken sollten auf zwei Ebenen untersucht und bewertet werden:

  • Ursprüngliches Risiko: Klassifizierung und Bewertung 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 Identifikation und Bewertung einzelner 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.

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)

Beispiel für Risiken von IVS-Architektur

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

Bewertung der Risiken, Gegenmaßnahmen

Die Bewertung der einzelnen konkreten Risiken erfolgt anhand der geschätzten Eintrittswahrscheinlichkeit und des Schweregrades des Risikos bei Eintritt.

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

Für kritische Risiken (z. B. Risikokennzahl über 15) und für Risiken mit hoher Eintrittswahrscheinlichkeit sollten Gegenmaßnahmen überlegt und geplant werden.

Template

IVS-Risiko


<< Zurück zur Hauptseite