Risiko-Management: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
| Zeile 18: | Zeile 18: | ||
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. | ||
| − | == Management der Risiken der Umsetzung von IVS- | + | == Management der Risiken der Umsetzung von IVS-Architektur == |
=== Ebenen und Schritte im IVS-Architektur Risikomanagement === | === Ebenen und Schritte im IVS-Architektur Risikomanagement === | ||
| Zeile 27: | Zeile 27: | ||
* Verbleibendes Risiko (Rest-Risiko): Klassifizierung und Bewertung des Risikos nach 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 | + | Zur Identfikation und Bewertung einzelner Risiken werden '''folgende Schritte''' empfohlen: |
#Identifikation möglicher Risiko-Quellen | #Identifikation möglicher Risiko-Quellen | ||
| Zeile 37: | Zeile 37: | ||
*Technik (Technologiekomplexität, Architekturdefizite, Over-Engineering) | *Technik (Technologiekomplexität, Architekturdefizite, Over-Engineering) | ||
| − | *Sicherheit ( | + | *Sicherheit (die notwendige Sicherheit kann nicht gewährleistet werden) |
*Information (Informationen fehlen oder sind fehlerhaft) | *Information (Informationen fehlen oder sind fehlerhaft) | ||
*Menschen (Mitarbeiter, personelle Schwächen) | *Menschen (Mitarbeiter, personelle Schwächen) | ||
*Prozesse (Prozesse sind zu starr und können nicht angepasst werden) | *Prozesse (Prozesse sind zu starr und können nicht angepasst werden) | ||
| − | *Management ( | + | *Management (das Management unterstützt das Projekt nicht) |
*Externe Quellen (Umwelt, Lieferanten, Gesetze) | *Externe Quellen (Umwelt, Lieferanten, Gesetze) | ||
| − | *Erfolg ( | + | *Erfolg (ist das Angebot skalierbar, was kann bei zu vielen Anfragen passieren) |
| − | *Anforderungen (unsichere Anforderungen: typisches Projektrisiko, falsche oder gar fehlende Anforderungen | + | *Anforderungen (unsichere Anforderungen: typisches Projektrisiko, falsche oder gar fehlende Anforderungen) |
*Anwendungen (Legacy-Anwendungen können nicht angebunden werden) | *Anwendungen (Legacy-Anwendungen können nicht angebunden werden) | ||
*Kunden bzw. Nutzer (unzureichende Beteiligung, fehlende Akzeptanz) | *Kunden bzw. Nutzer (unzureichende Beteiligung, fehlende Akzeptanz) | ||
*Planung (unrealistisch) | *Planung (unrealistisch) | ||
| − | *Fehler und Qualitätsmängel ( | + | *Fehler und Qualitätsmängel (die Lösung enthält Fehler) |
*Unzureichende Projektorganisation (keine Kontrolle der Fortschritts; zu viele oder zu wenige Beteiligte) | *Unzureichende Projektorganisation (keine Kontrolle der Fortschritts; zu viele oder zu wenige Beteiligte) | ||
| − | *Finanzen ( | + | *Finanzen (die finanzielle Planung ist unzureichend) |
=== Beispiel für Risisken von IVS-Architektur === | === Beispiel für Risisken von IVS-Architektur === | ||
Version vom 4. Oktober 2016, 16:45 Uhr
Inhaltsverzeichnis
Risiken bei der Umsetzung von IVS-Architektur
Unter Phase A (Architektur Vision) - Schritt 9 wurde dargestellt, welcher Nutzen von IVS-Architektur ausgehen kann und welche Dimension der Wertbeitrag von IVS-Architektur 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 nehmen die Interpendenzen, 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 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-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 Identfikation und Bewertung einzelner Risiken werden folgende Schritte empfohlen:
- 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
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 Risisken von IVS-Architektur
- 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.
- ...
Bewertung der Risiken, Gegenmaßnahmen
Die Bewertung der einzelnen konkreten Risiken erfolgt anhand der geschätzten Eintrittswahrscheinlichkeit und dem Schweregrad 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.
