Aktuelle Themen der Informatik. Change Management

Transkript

1 Aktuelle Themen der Informatik Change Management Michael Epple Allgemeine Informatik 8. Semester

2 Einführung: Um konkurrenzfähig zu bleiben müssen Unternehmen neue Technologien und Änderungen in ihren vorhandenen Systemen schnell und sicher implementieren können. Diese Implementierungen sind die so genannten Changes. Die Ansprüche an die IT-Services durch die Kunden steigen dabei zunehmend. Die Regelung des Managements und die Kontrolle der Änderungen nennt man Change- Management. Die kürzeste Definition: Ein Change ist ein Prozess, der von einem definierten Zustand in einen anderen führt. Begriffsklärung: Request for Change (RFC): Ist ein formeller Antrag auf eine oder mehrere Änderung(en). Es sind bereits wichtige Detailinformationen enthalten, wie Aktivitäten, betroffene Bereiche, sowie Auslöser und Sponsor des Changes. WAS WARUM WANN geändert werden muss. Der Auslöser hat den Change eingereicht. Der Sponsor übernimmt die Kosten des Changes. Gründe für einen RFC sind z.b.: - Incident oder Problem Report. - Einführung oder Entfernung eines CI`s - Upgrade eines vorhandenen Systems - Wechsel der Lokalität Thema eines RFC`s kann sein z.b.: - Hardware - Software - Dokumentation - Telekommunikation - Weiterbildung - IT Infrastruktur Inhalte eines RFC`s, also wie soll ein RFC aufgebaut sein: - Beschreibung der zu Ändernden Komponenten - Gründe für den Change - Was passiert, wenn der Change nicht durchgeführt wird? - Daten des Erstellers des Change - Change Priorität - Abschätzung der Auswirkungen des Changes, sowie der benötigten Ressourcen. - Der Zurücksetzungsplan - Abschätzung der Risiken - Auswirkungen auf die Service-Verfügbarkeit. - Status des RFC`s

3 Forward Schedule of Change (FSC): Ist der Zeitplan zur Implementierung von genehmigten Changes. Außerdem Sind die wichtigsten Details jedes Changes enthalten, sowie der Implementierungszeitpunkt. Change-Manager: - Er ist verantwortlich für die Durchführung von Änderungen und prüft, filtert und klassifiziert RfC`s. - Bereitet die CAB-Meetings vor. Erstellt eine Liste mit den abzuarbeitenden RFC`s. - Entscheidet, welche Personen zu welchen Meetings eingeladen werden. - Beschließt außerordentliche Meetings des CAB oder EC bei dringenden Changes. - Führt den Vorsitz bei allen CAB oder EC Meetings. - Autorisation von Changes welche vom CAB oder EC empfohlen wurden. - Updaten des Change Log. - Bewertung aller ausgeführten Changes. - Beurteilung aller neu erfassten Changes. - Analysieren der Change Abläufe, um etwaige Trends zu erkennen. - Schließen der RFC`s. - Erstellen von Reports. Change Advisory Board (CAB): Änderungsbeirat der bei periodischen Zusammentreffen, oder in Sonderfällen bei außerordentlichen Treffen wichtige Änderungen beurteilt und über ihre Autorisierung entscheidet. Außerdem Abschätzung der Risiken und Festlegung der Priorität eines Changes. Wie setzt sich das CAB zusammen: - - Kunden - Vertreter der Benutzergruppen - Entwickler - Technische Experten Die tatsächliche Zusammensetzung des CAB ist situationsabhängig, d.h. es kommt auf die zu bearbeitenden Changes an. Emergency-Commitee(EC): Bei besonders dringenden Änderungen trifft das EC die notwendigen Entscheidungen. Es setzt sich aus einem Teil der CAB Mitglieder zusammen. Es muss dabei sichergestellt werden, dass Vertreter aller wichtigen Bereiche daran beteiligt sind. Warum braucht man Change-Management: Häufig verursachen Änderungen an Systemen schwerwiegende Beeinträchtigungen von Services und damit Produktionsausfälle und hohe Kosten. Die Gründe liegen dabei häufig in einer schlechten Arbeitsweise und Dokumentation. Manche Änderungen werden vorgenommen, ohne dass im Vorfeld geklärt wurde, welche Risiken und Auswirkungen auf andere Bereiche durch die Änderung

4 entstehen. Wegen der hohen Arbeitsbelastung der IT-Mitarbeiter wird dieses Problem noch verstärkt. Wegen einer hohen Anzahl von Störungen aufgrund von Änderungen versuchen IT- Mitarbeiter oft Änderungen zu vermeiden, um möglichen Risiken aus dem Weg zu gehen. Es entstand das Sprichwort Never touch a running system. Aber genau dieses Verhalten führt dazu, dass die notwendigen Services auf Dauer nicht mehr zu erbringen sind und die Leistungsfähigkeit der IT sinkt. Ziele des Change-Managements: Effiziente und wirtschaftliche Implementierung autorisierter Changes mit minimalem Risiko für die bestehende IT-Infrastruktur sicherzustellen. Auf Deutsch: Die gewünschten Änderungen sollen möglichst schnell, möglichst billig, mit minimalem Risiko für das bestehende System umgesetzt werden. D.h. es wird der Weg gewählt, der für das Unternehmen langfristig am wenigsten Kosten mit sich bringt, und somit das Primärziel eines Unternehmens, die Gewinnmaximierung, maximal unterstützt. Grundsätzlich soll das Change-Management auf Dauer zu einer Reduzierung notwendiger Changes führen. Die Umgebung bleibt in einem definierten Zustand und wird dadurch vorhersehbar. Durch ein gutes Change-Management wird ein ausgewogenes Verhältnis zwischen Flexibilität und Stabilität erreicht. Dies wird maßgeblich durch einen durchschaubaren Änderungsprozess ermöglicht. Aufgaben des Change Managements: - Alle Änderungsanträge werden geprüft, genehmigt und die ordnungsgemäße Durchführung von Änderungen wird organisiert, überwacht und dokumentiert. - Abschätzung der Risiken für betroffene Systeme, mit Hilfe der Informationen aus dem Configuration Management. - Überwachung, Kontrolle und Reporting der eingeleiteten und beauftragten Aktionen und Implementierungen. - Abschließende Prüfung. Bewertung der Changes. Abschluss derselben. Um die eingehenden und anstehenden RFC`s überblicken und effektiv koordinieren zu können, steht der FSC zur Verfügung. Alle Schritte werden dokumentiert und es werden Statistiken darüber geführt.

5 Der Ablauf des Change Management Prozess: Was wird für den Prozess benötigt: - RFC`s - CMDB - FSC Aktivitäten während dem Prozess: - Changes filtern. Evtl. ablehnen oder bei geringeren Problemen außerhalb des Change Management Prozesses lösen. - Managen der Changes und des Change Prozesses. - Sitzungen des CAB und des EC abhalten. - RFC`s bewerten und abschließen. - Dokumentation Was bekommt man aus dem Management Prozess heraus: - FSC - RFC`s - Aktionen des CAB - Dokumentationen Vorteile, Kosten und mögliche Probleme des Change Managements: Vorteile: - Verbesserte Abschätzung von Risiken, Kosten. - Geringere Beeinflussung von betroffenen Services. - insgesamt weniger Changes - Weniger Changes die Zurückgesetzt werden müssen. - Steigerung der Produktivität. - Es können mehr Changes gleichzeitig bearbeitet werden. - Verbesserte Qualität und Verfügbarkeit der Services. Kosten: Personal: Change Management Team CAB Mitglieder Mitarbeiter des Configuration- und Release Managements. Support Tools: Darunter fallen Software- und Hardware Kosten für Change Management, Configuration Management, Problem Management und Service Desks. Mögliche Probleme: Der Umfang des Change Managements muss an die Größe des Unternehmens angepasst sein, ansonsten sinkt die Effektivität. Mitarbeiterschulungen sind nötig um das Change Management zu erklären und die Akzeptanz zu fördern.

6 Die geforderten Änderungen in einem Change überschreiten die Kapazität der Mitarbeiter und der Ressourcen. Wird auf das Configuration Management verzichtet, leidet die Effektivität darunter. Ist der Prozess zu bürokratisch, wird die Akzeptanz nicht gerade gefördert. Zurücksetzungs-Vorgänge fehlen, oder sind nicht getestet. Zusammenhang zwischen Change Management, Configuration Management und Release Management: Change Management Abschätzen der Auswirkungen Change Management Autorisation von Changes Release Management Kontrolle neuer Soft- und Hardware für die Umsetzung von Changes Change Management Abschätzen der Anforderungen an die IT Configuration Management Identifikation betroffener Bereiche Configuration Management Dokumentation und Logging

7 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. Beispiel: Der Vorfall eines defekten Computers muss nicht über das Change Management gelöst werden. Das Ersetzen mit einem neuen Computer führt nicht in einen neuen anderen Zustand.

8 Ablaufdiagramm des Change Management Prozesses:

9 Initiator des Changes Filtert Changes Akzeptiert Setzt zu Begin die Priorität fest Abgelehnt Dokumentation der RFC`s Dringend? Ja folgend Nein Entscheidung welchen Umfang die Änderungen haben. Standard Modell gering Autorisiert Changes und legt den Zeitplan fest. Informiert CAB mittel Gibt RFC`s an die CAB Mitglieder weiter hoch CAB hoch Entscheidet während Sitzungen über Changes CAB Mitglieder Abschätzen der Auswirkungen und der benötigten Ressourcen. Zustimmung zu den Changes. Zustimmung zur Priorität. Änderung des Zeitplans. Nein autorisiert? folgend Ja

10 Weiter mit normalem Ablauf: Ausführender Erstellt Änderungen. Erstellt Testfälle und Fallback Möglichkeiten. mit Prozess Reports Unabhängige Tester Testen der Changes erfolgreich Koordiniert die Implementation der Changes., Informiert die Benutzer funktioniert es? nein Ausführender Implementation des Fallbacks ja Beurteilen der Changes Erfolg? nein Neubeginn des Prozesses ja Abschluss des Prozesses Schließen des RFC im Log

11 Dringende Changes:

12 CAB oder EC Meeting Configuration Manager Loggen des RFC CAB oder EC Schnelle Abschätzung der Auswirkungen auf Ressourcen und Dringlichkeit Configuration Manager zurück nein Dringend? ja Ausführender Schnelles Erstellen des Changes Unabhängige Tester Schnelle Tests ja Zeit zum testen? nein nein Erfolg? ja Koordiniert die Implementation der Changes. Configuration Manager Stellt sicher, dass alle Aufzeichnungen auf den neuesten Stand gebracht werden ja funktioniert es? nein Koordination des Zurücksetzungsplans zurück Beurteilen der Changes nein Erfolg? ja schließen Configuration Manager Schließen des RFC im Log

13 Loggen von Changes. Alle eingereichten Changes werden zunächst registriert. Alle durchgeführten Aktionen werden nach ihrer Reihenfolge (mit einem geeigneten Tool) geloggt. Somit sind alle Änderungen nachvollziehbar. Außerdem erleichtert das Loggen das zurückführen zum Anfangszustand. Prioritätsvergabe an Changes: Die Priorität eines Changes wird mit Hilfe von 2 Faktoren bestimmt: 1. Die Auswirkungen des vorhandenen Problems 2. Die Dringlichkeit der Problembeseitigung. Die Priorität bestimmt den Ablauf wie der jeweilige Change umgesetzt wird. Die Priorität wird normalerweise gemeinsam vom Initiator, und evtl. vom CAB bestimmt. Würde der Initiator allein entscheiden, hätte der Change im Allgemeinen eine zu hohe Priorität. Eine feste Regelung für die Stufen der Priorität gibt es nicht. Vorgeschlagen sind hier: gering, mittel, hoch, unverzüglich Gering: Der Change ist gerechtfertigt, kann aber bis zum nächsten geplanten Release oder Upgrade warten. Ressourcen wie Personal, Budget, usw. 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 geplanten Release gewartet werden. Ressourcen erhält der Change mit mittlerer Priorität. Hoch: Es gibt Einschränkungen für wenige bis viele Benutzer. Für die Vergabe von Ressourcen erhält der Change die höchste Priorität. Unverzüglich: Wenn nicht sofort gehandelt wird sind große Einbußen zu erwarten, wie z.b.: Aufrechterhaltung angebotener Services, Einschränkungen für eine große Anzahl von Benutzern, Ausfall Unternehmenskritischer Systeme, usw. Sofort wird der EC zur Beratung zusammengerufen. Die benötigten Ressourcen werden sofort zur Verfügung gestellt. Kategorisierung von Changes: Changes gibt es in allen möglichen Bereichen eines Unternehmens. Genauso vielfältig sind die Inhalte jedes einzelnen Changes. Um eine gewisse Vereinheitlichung zu ermöglichen, können Kategorien für Changes festgelegt werden. Jeder auftretende Change wird dann einer Kategorie zugeordnet. Der Sinn dabei ist, dass für eine Kategorie bestimmte Abläufe und Prozesse festgelegt werden können.

14 CAB Meetings: Treffen des CAB finden normalerweise regelmäßig statt, z.b. alle 6 Monate. Für Changes mit einer hohen Priorität kann allerdings auch ein außerordentliches Treffen stattfinden, je nachdem wie dringend der Change ist. Dabei ist auch zu beachten, dass CAB Meetings sehr zeitraubend für alle Teilnehmer sind. Abschätzung der Wirkung und der benötigten Ressourcen eines Changes: Beteiligt sind die Mitarbeiter des Change Managements, CAB, EC und alle anderen Personen die an diesem Prozess beteiligt sind. Die folgenden Punkte sollten beachtet werden: - Der Einfluss den der Change auf die Geschäftsfähigkeit hat. - Den Einfluss auf die Infrastruktur die Kapazität, die Leistung, die Zuverlässigkeit - Den Einfluss auf andere Services die sich auf derselben Infrastruktur befinden. - Den Einfluss auf nicht IT-Infrastrukturen innerhalb des Unternehmens, z.b. Security, Verwaltung, Transportwesen - Den Effekt bei nicht Umsetzung des Changes - Berücksichtigung aller benötigten Ressourcen - Das FSC Change scheduling/ Planen Normalerweise werden mehrere Changes die parallel durchgeführt werden zu einem Release zusammengefasst. Ein Release wird dann wie ein einzelner Change betrachtet, auch wenn mehrere Changes darin enthalten sind. Falls es Probleme mit dem neuen Release gibt, wird es komplett zurückgesetzt, (alle beinhalteten Changes). Das Change Management arbeitet dabei sehr nahe mit dem Release Management zusammen. Erstellen der Changes, Testen: Der Erstellungsprozess beinhaltet: - Erstellen eines neuen Produktionsmoduls - Erstellen einer neuen Version eines oder mehrerer Softwaremodule. - Kaufen von Equipment oder externen Services - Vorbereiten einer Hardwaremodifikation - Erstellen der Zurücksetzungsprozesse - Erstellen der Dokumentation - Vorbereitungen für Benutzerschulungen Das Change Management koordiniert dabei die Abläufe und wird vom Release Management unterstützt. Testen: Testkriterien sind: Leistung, Sicherheit, Instandhaltung, Support, Zuverlässigkeit, Funktionalität.

15 Dringende Changes: Dringende Changes sollten die absolute Ausnahme sein, weil sie naturgemäß zu mehr Problemen und Störungen führen. Ablaufdiagramm: Für Vortrag siehe auch Bewerten eines Changes: Jeder umgesetzte Change wird nach einer gewissen Zeit beurteilt. Die Beurteilung wird von CAB-Mitgliedern durchgeführt. Die Beurteilung beinhaltet folgende Punkte: - Erfüllt der Change den gewünschten Effekt - Sind die Benutzer zufrieden mit den Resultaten - Sind keine unerwarteten Seiteneffekte aufgetreten - War der Verbrauch an Ressourcen wie erwartet - Wurde der Change in der vorgesehen Zeit zu vorgesehenen Kosten umgesetzt - Hat der Zurücksetzungsplan korrekt funktioniert( wenn nötig) Sind nicht alle Punkte zufrieden stellend gelöst worden, werden die aufgetretenen Probleme dazu genutzt um zukünftigen Changes zu verbessern. Gibt es des Öfteren nicht zufrieden stellende Ergebnisse, ist die ein Indikator dafür, dass der ganze Change Management Prozess nicht optimal funktioniert. Der Change Management Prozess kann durch folgende Aktionen verbessert werden: - Reduktion des Einflusses auf die Servicequalität - Reduktion der auftretenden Vorfälle - Reduktion der zurückgesetzten Changes - Geringe Anzahl dringender Changes Nach der Beurteilung wird der Change geschlossen. Management Reporting Ein regelmäßig erscheinender Report soll folgende Inhalte haben: - Anzahl der Changes die in dieser Periode umgesetzt wurden - Die Gründe für die Changes - Anzahl der erfolgreichen Changes - Anzahl der Fehlschläge - Anzahl der Vorfälle die in einem Change resultierten - 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