Change Management

Transcription

Change Management
Aktuelle Themen der
Informatik
Change Management
Michael Epple
AI 8
Inhalt:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Einführung
Begriffsbestimmungen
Ablauf des Change Management Prozesses
Zusammenhang zwischen Change Management,
Configuration Management und Release
Management
Ablaufdiagramm des CM Prozesses
Prioritätsvergabe an Changes
Change scheduling
Bewerten eines Changes
Change Management Reporting
Vorteile, Kosten, mögliche Probleme
1
1. Einführung
Was ist Change Management?
Wozu braucht man Change
Management?
Was sind die Ziele des Change
Managements?
Was ist Change Management?
Konkurrenzfähig bleiben
Aufstellung von Regelungen um
Änderungen umzusetzen
Umsetzung von Problemlösungen
Definition:
Ein Change ist ein Prozess der ein System
von einem definierten Zustand in einen
anderen führt.
2
Wozu braucht man Change
Management? (1)
Unerwartete Probleme bei der
Durchführung von Änderungen
Beeinträchtigung von Services durch
Änderungen
Schlechte Arbeitsweise und
Dokumentation
Ändern ohne vorherige Analyse der
Risiken und Einflüsse
Hohe Arbeitsbelastung der IT-Mitarbeiter
Wozu braucht man Change
Management? (2)
Resultat:
Never Change a running system
Ergebnis: Services sind auf Dauer
nicht mehr zu erbringen, die
Leistungsfähigkeit der IT sinkt.
3
Was sind die Ziele des Change
Managements? (1)
Effiziente und wirtschaftliche
Implementierung autorisierter
Changes mit minimalem Risiko für
die bestehende betroffene
Infrastruktur.
Was sind die Ziele des Change
Managements? (2)
Reduzierung notwendiger Changes
Die Umgebung bleibt während dem
Prozess in einem definierten Zustand
Erreichen eines ausgewogenen
Verhältnisses zwischen Flexibilität und
Stabilität
Dies wird durch einen durchschaubaren
Änderungsprozess erreicht
4
2. Begriffsbestimmungen
Request for Change (RFC): (1)
Formeller Antrag auf eine Änderung
Enthält Detailinformationen:
Auslöser, betroffene Bereiche,
Aktivitäten, Sponsor
Also was warum wann geändert werden
muss
Ergebnis des Problem Managements
5
Request for Change (RFC): (2)
Beispiele für Gründe für einen RFC:
Problem Report
Ausfall von Services, oder Systemen
Hardware Upgrades
Software Updates
Themen eines RFC`s:
Hardware, Software, Dokumentation,
Telekommunikation, Weiterbildung, ITInfrastruktur…
Request for Change (RFC): (3)
Aufbau eines RFC:
Beschreibung der zu ändernden Komponenten
Gründe für den Change
Was passiert, wenn der Change nicht
durchgeführt wird
Priorität
Abschätzung der Auswirkungen und der
Risiken des Changes
Zurücksetzungsplan
Status des RFC`s
6
Forward Schedule of Change (FSC)
Zeitplan zur Implementierung
genehmigter Changes
Enthält Details jedes Changes
Enthält den
Implementierungszeitpunkt
Change Manager (1)
Zentrale Figur des Change
Management Prozesses
Aufgaben:
Verantwortlich für die Durchführung
von Änderungen
Prüft und Filtert RFC`s
Bereitet CAB-Meetings vor. Erstellt eine
Liste abzuarbeitender RFC`s
Entscheidet welche Personen an
welchen Meetings teilnehmen
7
Change Manager (2)
Aufgaben:
Beschließt außerordentliche Meetings des CAB
oder EC bei dringenden Changes
Führt den Vorsitz bei allen Meetings
Autorisation von Changes, welche vom CAB
oder EC empfohlen wurden
Update des Change Log
Bewertung aller ausgeführten Changes
Beurteilung aller neu erfassten Changes
Ständige Analyse der Change Abläufe, um
etwaige Trends zu erkennen
Abschließen der RFC`s
Erstellen von Reports und Statistiken
Change Advisory Board (1)
Änderungsbeirat
Entscheidet über wichtige Changes
Periodische Zusammentreffen
Außerordentliche Treffen, bei
dringenden Changes
Abschätzen der Risiken und
Festlegung der Priorität eines
Changes
8
Change Advisory Board (2)
Zusammensetzung des CAB:
Change Manager
Kundenvertreter
Vertreter der Benutzergruppen
Entwickler
Technische Experten
Die tatsächliche Zusammensetzung
ist situationsabhängig
Change Advisory Board (3)
Folgende Punkte sollten bei einer Entscheidung über
einen Change geklärt werden:
o
o
o
o
o
o
o
Einfluss des Changes auf die Geschäftsfähigkeit
Einfluss auf die Infrastruktur, Kapazität, Leistung,
Zuverlässigkeit
Einfluss auf andere Services
Einfluss auf nicht IT-Infrastrukturen
Effekt bei nicht Umsetzung des Changes
Berücksichtigung aller benötigten Ressourcen
FSC
9
Emergency Commitee
Wird bei besonders dringenden
Änderungen zusammengerufen
Besteht aus Mitgliedern des CAB
Es muss sichergestellt sein, dass
Vertreter aller wichtigen Bereiche
beteiligt sind
3. Ablauf des Change Management
Prozesses
10
Für den Prozess werden folgende
Komponenten benötigt:
RFC`s
CMDB Configuration Management
Datenbank (aus Configuration
Management)
FSC
Aktivitäten während dem Prozess
Changes filtern, evtl. ablehnen und bei
geringen Änderungen außerhalb des CMP
lösen
Managen der Changes und des Change
Prozesses
Sitzungen des CAB und des EC abhalten
RFC`s bewerten und abschließen
Dokumentation und Statistiken erstellen
11
Ergebnisse des Prozesses
FSC
RFC`s
Aktionen des CAB
Dokumentationen
4. Zusammenhang zwischen Change
Management, Configuration Management
und Release Management
Change Management
Change Management
Release Management
Abschätzen der Auswirkungen
Autorisation von Changes
Kontrolle neuer Softund Hardware für die
Umsetzung von
Changes
Change Management
Configuration Management
Abschätzen der Anforderungen an
die IT
Identifikation betroffener
Bereiche
Configuration
Management
Dokumentation und
Logging
12
Abgrenzung zwischen Incident
Management und Change Management:
Ein Vorfall ist nicht gleichzusetzen
mit einem Change
Ein Problem führt nicht unbedingt
zu einem Change
Ein Change ist das Resultat von
Problemlösungsprozessen welcher
in einen neuen definierten Zustand
führt
5.
Ablaufdiagramm
des Change
Management
Prozesses
13
Normaler
Ablauf:
Dringende
Changes:
14
6. Prioritätsvergabe an Changes (1)
Wird bestimmt durch 2 Faktoren:
1. Auswirkungen des vorhandenen
Problems
2. Dringlichkeit der Problembeseitigung
Eigenschaften:
o
Bestimmung durch Initiator, Change
Manager, evtl. CAB / EC
o
Keine festgelegten Prioritätsstufen
o
Vorschlag: gering, mittel, hoch,
unverzüglich
Prioritätsvergabe an Changes (2)
Gering:
Gerechtfertigt, kann aber bis zum nächsten
Release warten
Ressourcen werden mit geringer Priorität an
den Change vergeben
Mittel:
Es steht kein größerer Schaden bevor. Es kann
aber nicht bis zum nächsten Release gewartet
werden
Ressourcen werden mit einer mittleren Priorität
vergeben
15
Prioritätsvergabe an Changes (3)
Hoch
Es gibt Einschränkungen für wenige bis viele
Benutzer
Ressourcen werden mit der höchsten Priorität
vergeben
Unverzüglich
Wird nicht sofort gehandelt, drohen große
Einbußen, z.B. Aufrechterhaltung angebotener
Services, Ausfall unternehmenskritischer
Systeme
Sofort wird der EC zusammengerufen. Die
benötigten Ressourcen werden unmittelbar zur
Verfügung gestellt
7. Change scheduling
Zusammenfassung mehrerer
Changes zu einem Release
Betrachtung wie ein einzelner
Change
Bei Problemen wird das ganze
Release zurückgesetzt
Enge Zusammenarbeit mit dem
Release Management
16
8. Bewerten eines Changes (1)
Gilt für alle umgesetzten Changes
Bewertung durch CAB-Mitglieder
Folgende Punkte werden bewertet:
Erfüllung des gewünschten Effekts
Zufriedenheit der Benutzer
Gibt es unerwartete Seiteneffekte
Verbrauch der Ressourcen wie erwartet
Umsetzung in der vorgesehenen Zeit zu
vorgesehenen Kosten
Funktionierte der Zurücksetzungsplan (wenn
nötig)
Bewerten eines Changes (2)
Probleme mit aktuellen Changes
fließen zur Optimierung in
zukünftige Changes Prozesse ein
Öfters auftretende Probleme deuten
darauf hin, dass der ganze Change
Management Prozess nicht optimal
funktioniert
17
Bewerten eines Changes (3)
Verbesserung des Change
Management Prozesses:
Reduktion des Einflusses auf die
Servicequalität
Reduktion der auftretenden Vorfälle
Reduktion der zurückgesetzten
Changes
Geringe Anzahl dringender Changes
9. Change Management Reporting
Beinhaltet Informationen zu allen aufgetretenen
Changes:
Anzahl der umgesetzten Changes in dieser Periode
Gründe für die Changes
Anzahl der erfolgreichen Changes
Anzahl der Fehlschläge
Anzahl der Vorfälle, die in einem Change resultieren
Anzahl der RFC`s
Statistiken über die letzten Perioden
Anzahl der abgelehnten RFC`s
Anzahl der umgesetzten Changes, die nicht
erfolgreich waren
Anzahl der zurückgesetzten Changes
-> Erfolg des Change Managements
18
10. Vorteile, Kosten, mögliche
Probleme (1)
Vorteile:
Verbesserte Abschätzung von Risiken und
Kosten
Geringere Beeinflussung von betroffenen
Services
Weniger Changes
Weniger Changes, die zurückgesetzt werden
müssen
Steigerung der Produktivität
Es können mehr Changes gleichzeitig
bearbeitet werden
Vorteile, Kosten, mögliche Probleme
(2)
Kosten:
Personal:
Change Management Team
CAB Mitglieder
Mitarbeiter des Configuration- und
Release Managements
Support Tools:
Darunter fallen alle Soft- und Hardwarekosten für das Change Management
19
Vorteile, Kosten, mögliche Probleme
(3)
Mögliche Probleme:
Wenn der Umfang des Change Managements
nicht an die Größe des Unternehmens
angepasst ist, sinkt die Produktivität
Durch Schulungen der Mitarbeiter muss das
Verständnis und die Akzeptanz zum Change
Management gefördert werden
Wird auf Configuration Management verzichtet,
leidet die Effektivität
Ist der Prozess zu bürokratisch, sinkt die
Akzeptanz unter den Mitarbeitern
Zurücksetzungs-Vorgänge werden nicht
angemessen vorbereitet
Ende
Fragen?
20

Documents pareils