Advanced ITIL

Die Ziele von ITIL

Ziele für das Change-Management

Kapitel 3

Wenn Sie mit dem ITIL-Change-Management nicht vertraut sind, müssen Sie zunächst wissen, dass ITIL zwischen Änderungsmanagement und Änderungssteuerung unterscheidet. Nur wenn Sie diesen Unterschied verstehen, können Sie eine starke Argumentation für das ITIL-Change-Management aufbauen.

ITIL definiert die Änderungssteuerung folgendermaßen:

Das Verfahren, das gewährleistet, dass alle Änderungen gesteuert werden. Dazu gehören Einreichung, Analyse, Entscheidungsfindung, Genehmigung, Implementierung und Postimplementierung der Änderung.

Im Gegensatz dazu beschreibt ITIL das Change-Management folgendermaßen:

Der Prozess der kontrollierten Steuerung von Änderungen der Infrastruktur oder eines beliebigen Aspektes von Services, damit die Implementierung genehmigter Änderungen mit minimalen Störungen verbunden ist.

Der Anfang dieser beiden Definitionen ist der Schlüssel zum Verständnis des Unterschiedes zwischen Change-Management und Änderungssteuerung. Die Änderungssteuerung ist ein Verfahren, das Change-Management hingegen ein übergeordneter Prozess. Anders ausgedrückt: Innerhalb des Change-Management-Prozesses können viele Änderungen gesteuert werden. Jede Änderung erfordert eine effektive Änderungssteuerung, während der Change-Management-Prozess alle Änderungen überwacht.

Auch bei einer guten Änderungssteuerung können Fehler auftreten, wenn das Change-Management nicht effektiv ist. So können zum Beispiel zwei IT-Teams an unterschiedlichen Änderungen auf demselben Server arbeiten. Beide Teams steuern ihre Änderungen effektiv, aber bei der Implementierung treten Fehler auf, da zwischen den Teams keinerlei Kommunikation stattfindet und die eine Änderung negative Auswirkungen auf die andere hat. Wenn ein Change-Management in Kraft ist, wird festgestellt, dass zwei Teams den Status desselben Servers zu ändern versuchen, und die Teams werden zur Zusammenarbeit aufgefordert, um ein Fehlschlagen der Änderungen zu vermeiden. Zugleich verwaltet das Change-Management den Lebenszyklus und den Status vieler kontrollierter Änderungen, da die Änderungssteuerung eine Komponente des Change-Managements ist.

Da das Change-Management umfangreich ist, hat naturgemäß auch das entsprechende ITIL-Ziel beträchtlichen Umfang.

Das Ziel für den Change-Management-Prozess besteht darin, zu gewährleisten, dass für die effiziente und unverzügliche Handhabung aller Änderungen standardisierte Methoden und Verfahren verwendet werden, damit die Auswirkungen änderungsbedingter Vorfälle auf die Service-Qualität minimiert und der laufende Betrieb des Unternehmens verbessert wird.

Die angemessene Reaktion auf eine Änderungsanfrage umfasst ein durchdachtes Verfahren zur Einschätzung von Risiko und Geschäftskontinuität, Auswirkungen der Änderung, Ressourcenbedarf und Änderungsgenehmigung. Dieses durchdachte Verfahren ist unerlässlich für die Wahrung des Gleichgewichts zwischen der Notwendigkeit und den Auswirkungen einer Änderung.

Besonders wichtig sind die große Sichtbarkeit und die offenen Kommunikationskanäle der Change-Management-Prozesse , damit Änderungen reibungslos durchgeführt werden können.

Zerlegen wir diese wortreiche Definition nun in ihre Bestandteile, um mögliche Argumente für ITIL zu finden:

„die Auswirkungen änderungsbedingter Vorfälle auf die Service-Qualität minimieren“: Diese klare Aussage quantifiziert die allumfassende Verantwortung des Change-Managements. Die Frage lautet: „Treten neue Vorfälle oder Probleme in Folge gescheiterter Änderungen oder in Folge von Änderungen auf, die zwar ‚funktioniert‘, aber neue Vorfälle oder Probleme in anderen ITInfrastrukturkomponenten hervorgerufen haben?“ Ein Beispiel: Eine neue Softwareanwendung wird erfolgreich installiert, aber die Leistung sinkt, da der Speicher nicht ausreicht. Wenn Sie nicht sicher sind, wie Sie diese Frage beantworten sollen, überprüfen Sie die Vorfalls- und die Problemdatenbank auf Hinweise auf gescheiterte Änderungen. Verwenden Sie diese Daten als Beleg dafür, dass das Ziel für das Change-Management nicht erreicht wird. Es ist sinnvoll, die Service-Desk-Mitarbeiter nach Beispielen zu fragen. Wenn Änderungen scheitern, helfen Ihnen diese Mitarbeiter sicher gerne.

„effiziente und unverzügliche Handhabung aller Änderungen“: Dieser Punkt betrifft die zeitliche Planung von Änderungen. Falls Änderungsanfragen an zentraler Stelle registriert und verwaltet werden, sollten Sie einen Querschnitt der Anfragen untersuchen, um herauszufinden, wie hoch der Anteil der verspäteten oder verzögerten Änderungen ist.

Dadurch erhalten Sie Daten, anhand derer Sie ermitteln können, ob Sie die Bedingungen dieser Zielkomponente für das Change-Management erfüllen. Falls derzeit kein Change-Management im Einsatz ist, kann sich die Quantifizierung dieser Komponente als schwierig erweisen. Eventuell können Sie Kunden dazu befragen, wie effektiv Änderungen ihrer Meinung nach derzeit gehandhabt werden. Sie können auch Änderungsanfragen, die derzeit an verschiedenen IT-Standorten aktiv sind, sammeln und analysieren. Wie auch immer Sie die Daten gewinnen, dieses Thema ist auf jeden Fall wichtig, da die zeitliche Planung von Änderungen der Schlüssel zu einem erfolgreichen Change-Management ist.

Wenn Sie keine zentrale Stelle für die Registrierung und Verwaltung von Änderungsanfragen haben, ist dies an sich schon ein Argument für das Change-Management, da Sie Änderungen nicht effizient verwalten können, wenn Sie nicht wissen, welche Infrastrukturkomponenten Sie ändern oder wann Sie sie ändern.

„standardisierte Methoden und Verfahren verwenden“: Traditionell hat jede ITAbteilung eigene Verfahren zur Steuerung des Zyklus derjenigen Änderungen, die in ihren Verantwortungsbereich fallen. Dies ist jedoch nicht hinnehmbar, falls an einer Änderung verschiedene Abteilungen mitwirken sollen. Das größte Problem bei Änderungen besteht nicht darin, die Änderung erfolgreich durchzuführen, sondern darin, sie ohne negative Auswirkungen auf die Umgebung durchzuführen. Nehmen wir zum Beispiel an, dass für die Änderung eines Netzwerk-Browsers Software und Arbeitsspeicher von Infrastrukturkomponenten aufgerüstet und die Anwender geschult werden müssen. Falls dies nicht vor der Änderung geschieht, wird die Änderung scheitern oder zumindest Probleme bereiten. Aus diesem Grund sind standardisierte Methoden und Verfahren unbedingt erforderlich. Dieses Ziel können Sie leicht überprüfen, da standardisierte Methoden und Verfahren entweder dokumentiert und vorgeschrieben sind oder nicht. Falls es sie nicht gibt, sollten Sie argumentieren, dass die Gefahr fehlgeschlagener Änderungen wesentlich größer ist, wenn mehrere Teams an derselben Änderung arbeiten, ohne standardisierte Methoden und Verfahren einzuhalten. Eventuell können Sie dieses Argument mit Daten zu gescheiterten Änderungen untermauern.

„ein durchdachtes Verfahren zur Einschätzung von Risiko und Geschäftskontinuität“: Der Kern dieser Aussage besteht darin, dass Änderungen, die von isolierten Gruppen im Unternehmen durchgeführt werden, enorme Auswirkungen auf den Geschäftsbetrieb haben können. Alle Entscheidungen, die die IT-Infrastruktur verändern, müssen zentral, unter Beteiligung aller betroffenen Parteien getroffen werden. Allzu häufig wird bei Änderungen für den ROI ein falscher Wert angesetzt, der die Komponenten anderer an der Änderung beteiligter IT-Teams nicht berücksichtigt. Wie soll die IT-Abteilung Budgets und Investitionen planen, wenn sie die tatsächlichen Kosten von Änderungen nicht kennt?

Wie soll die IT-Abteilung ihren Personalbedarf ermitteln, wenn sie nicht weiß, wie viele Mitarbeiter an Änderungen mitarbeiten? Wenn nicht die gesamte ITAbteilung gemeinsam die Auswirkung von Änderungen einschätzt, treffen beim Service-Desk mehr Anrufe ein. Heute können selbst einfache Änderungen, wenn sie scheitern, erhebliche Auswirkungen auf Unternehmen haben, und in einigen Fällen spiegeln sich diese Auswirkungen direkt im Unternehmensgewinn wider. Bei diesem Ziel konzentrieren Sie sich also nicht darauf, Beweise für gescheiterte Vorgänge zu suchen, sondern Sie weisen auf den Schaden hin, der dem Unternehmen aus der Nichterfüllung dieser Bedingungen entstehen kann.

„Wahrung des Gleichgewichts zwischen der Notwendigkeit und den Auswirkungen einer Änderung“: Die potenziellen Auswirkungen, Vorteile und Ergebnisse einer Änderung einerseits und die Kosten für die Implementierung der Änderung andererseits müssen sich im Gleichgewicht befinden. Zum Beispiel: Es wird eine Änderung angefordert, damit ein Problem behoben wird, das drei Anrufe beim Service-Desk pro Tag verursacht, aber nur geringe Auswirkungen auf den Geschäftsbetrieb hat. Zunächst klingt diese Änderung sinnvoll. Was aber, wenn die Durchführung 200.000 Euro kostet? Dieses Beispiel ist übertrieben, macht aber deutlich, dass Auswirkungen und Kosten sorgfältig gegeneinander abgewogen werden müssen. Dieses Ziel ist schwer erreichbar, da sich nicht leicht Belege dafür finden lassen. Sie müssen wiederum für die zentrale Verwaltung von Änderungsanfragen argumentieren. Dadurch können Sie tatsächliche Kosten identifizieren, da Sie von allen Teams, die an der Änderung mitwirken, Informationen erhalten und die Änderung vom Standpunkt verschiedener IT- und Kundengruppen aus betrachten können.

„große Sichtbarkeit und offene Kommunikationskanäle“: Einfach ausgedrückt: Erbitten Sie regelmäßig Rückmeldungen aller beteiligten Parteien in IT- und Geschäftsbetrieb zum Status von Änderungen. Ob Sie dieses Ziel erreichen, können Sie problemlos einschätzen, da Sie die Rückmeldung entweder anfordern oder nicht. Machen Sie es nicht, so ist dies bereits ein Argument für das Change-Management.

Das Change-Mnagement ist einer der Schlüssel zum Erfolg der IT im Unternehmen. Die IT ist mittlerweile ein wesentlicher Bestandteil der Geschäftsprozesse und vollständig in das Gewebe der täglichen Geschäftsaktivitäten eingebunden. Überschrittene Änderungsbudgets, gescheiterte, verspätete, zu gering ausgestattete, unzureichend kommunizierte, isolierte und schlecht verwaltete Änderungen sind nicht hinnehmbar. Denken Sie auch an den Unterschied zwischen Änderungssteuerung und Change-Management.

> > Kapitel 4 - Ziele für das Configuration-Management