WHITE PAPER. Remedy Customer Practices Change Management in der Praxis. Eine Studie zu den Erfahrungen von Remedy-Kunden mit IT-Change-Management

Remedy Customer Practices Change Management in der Praxis Eine Studie zu den Erfahrungen von Remedy-Kunden mit IT-Change-Management Von Malcolm Fry

Inhaltsverzeichnis Einleitung....................................... 1 Der Change Impact Factor.......................... 2 Die Auslöser für ein effektives Change Management........ 2 Strategischer Nutzen............................... 3 Die Aufgabe: Ein effektives Change Management.......... 4 Capability Maturity Model.......................... 5 Der Umfang des Change Management.................. 5 Change Authority................................. 6 Change Advisory Board............................. 7 Change Testing................................... 8 Forward Schedule of Changes........................ 8 Kommunizieren von Änderungen..................... 8 Messen von Veränderungen.......................... 9 Finanzmanagement................................ 9 Integration von Veränderungen mit anderen Prozessen...... 10 Von Change Control zum Change Management.......... 10 Zusammenfassung................................ 11 Biografie von Malcolm Fry......................... 11 Remedy Unternehmensprofil...................... 11

Einleitung Heutzutage ist die Informationstechnologie (IT) zur Unterstützung der geschäftlichen Aktivitäten von entscheidender Bedeutung. Gleichzeitig hat die Komplexität und der Vernetzungsgrad der IT-Infrastrukturen zugenommen und setzt die Unternehmen einem zunehmenden Risiko von Betriebsstörungen durch Hardware- oder Software-Fehler aus. Durch die Komplexität der IT-Infrastruktur ist es für Unternehmen äußerst schwierig geworden, eine permanente Verfügbarkeit von kritischen Informationssystemen sicherzustellen. Es ist sicherlich nicht überraschend, dass Veränderungen - sowohl geplante als auch ungeplante - eine der häufigsten Fehlerquellen in der IT-Infrastruktur darstellen.viele Unternehmen haben festgestellt, dass anscheinend geringfügige Änderungen an einer einzelnen Komponente der Infrastruktur andere Komponenten in vielen Bereichen negativ beeinflussen können, zum Beispiel Server, Netzwerke, Datenbanken und Anwendungen. Die meisten Unternehmen müssen jedoch ihre IT-Umgebung praktisch permanent aufrüsten und aktualisieren, um mit der Dynamik im heutigen Geschäftsleben Schritt halten zu können.aus diesem Grund sind viele Unternehmen mit zunehmenden Ausfallquoten konfrontiert, die einen Anstieg der Kosten für den IT-Support verursachen und kritische Geschäftsprozesse beeinträchtigen, die von der IT-Infrastruktur abhängen. IT-Organisationen in praktisch allen Branchen sind bestrebt, einen disziplinierten und prozessorientierten Ansatz für das Management von IT-Veränderungen zu verwirklichen, um Betriebsstörungen auf ein Minimum zu beschränken. Das Ziel hierbei ist, die Häufigkeit und Auswirkungen von IT-Fehlfunktionen zu verringern, die von der IT abhängigen Geschäftsprozesse zu unterstützen und die Support- und Betriebskosten zu senken. Das IT-Change-Management ist ein vielschichtiges Aufgabengebiet, das sich aus Planung,Auswirkungs- und Risikoanalysen, Festlegung von Genehmigungsverfahren, Back-Out-Plänen, Kommunikation mit IT- und Business Managern und der Vereinfachung der Einführung von Veränderungen in der Produktionsumgebung zusammensetzt. Um seine volle Effizienz zu erreichen, muss der Change- Management-Prozess mit anderen zentralen IT-Service-Management-Prozessen, wie zum Beispiel Vorfallsund Problemmanagement sowie Asset Management, integriert werden. Eine solche Integration bietet klare geschäftliche Vorteile, wie zum Beispiel die Steigerung der operativen Effizienz, finanzielle Vorteile und einen immateriellen Nutzen, wie höhere Mitarbeiter- und Kundenzufriedenheit. Anfang 2003 hat Malcolm Fry, ein anerkannter Experte für die IT-Branche, eine qualitative Studie mit Remedy-Kunden aus vielen verschiedenen Branchen durchgeführt, um festzustellen, wie sie den Herausforderungen des Change Management begegnen. Zu diesen Unternehmen gehörten: Ein Großunternehmen aus der Konsumgüter- und Pharmaindustrie Ein IT-Serviceprovider für die Finanzdienstleistungsbranche Ein großer Lebensmittel- und Getränkehersteller Ein Anbieter von gehosteten Software-Lösungen Ein großer Hersteller von Computer-Komponenten In diesem Dokument sind ihre Erfahrungen bei der Entwicklung und Implementierung einer Strategie für das Change Management zusammengefasst. In vielen Fällen werden die Unternehmen zitiert. Dieses Whitepaper ist kein umfassender Leitfaden oder eine Checkliste für die Implementierung einer effektiven Lösung für das Change Management. Es werden jedoch einige zentrale Aspekte beleuchtet, die veranschaulichen sollen, welche Auswirkungen das Change Management auf die IT-Organisation haben kann und wie die befragten Kunden mit diesen Fragen umgehen.wir hoffen, das Ihnen die in der Studie zusammengestellten Kundenerfahrungen helfen werden,argumente für ein strategisches Change-Management-Projekt zu formulieren oder Ihre bestehenden Change-Management-Systeme und -Prozesse zu verbessern. 1

Der Change Impact Factor Veränderungen sind und waren schon immer ein Charakteristikum der IT.Warum also hat sich das Change Management zu einem so heißen Thema entwickelt? Die Antwort lautet:weil das Volume of Changes (VOC) ständig zunimmt und immer mehr Raum für Fehler schafft. Gleichzeitig sinkt der Failure Tolerance Level (FTL), da die geschäftlichen Aktivitäten immer mehr von den zugrunde liegenden IT-Services abhängen.wie Abbildung 1 zeigt, erhöhen diese beiden Faktoren den Change Impact Factor (CIF), ein Maß für die Auswirkungen von Veränderungen auf die Geschäftstätigkeit. Das heißt, je größer der Change Impact Factor, desto wichtiger ist das Change Management für das Unternehmen. Volume of Changes (VOC) Failure Tolerance Level (FTL) Abbildung 1 Der Change Impact Factor Höher Niedriger Das Volume of Change steigt exponentiell, getrieben durch das rasche Erscheinen und die zunehmende Komplexität neuer Technologien und die steigende Integration mit Legacy- Technologien, wie zum Beispiel Mainframes. Andererseits steigt der Failure Tolerance Level rasch an, da die Technologie immer fester in die Struktur jedes Unternehmens eingewoben wird. Dies bedeutet, dass mehr Änderungen mit weniger Fehlern implementiert werden müssen. Der Change Impact Factor steigt, da die Kluft zwischen dem Volume of Change und dem Failure Tolerance Level zunimmt. In dem Maße, wie der Change Impact Factor steigt, nimmt auch die Sichtbarkeit von Veränderungsfehlern beim IT- Management und der Geschäftsleitung zu. Daher zwingt der Change Impact Factor viele IT- Fachleute, ihre Change-Management-Strategien zu überprüfen und zu verbessern. Change Impact Factor (CIF) Die Auslöser für ein effektives Change Management Der Change Impact Factor ist ein Indikator für die zunehmende Notwendigkeit des Change Management.Aber welche spezifischen Auslöser oder Probleme innerhalb einer Organisation erhöhen letztlich die Sichtbarkeit und die Notwendigkeit für Verbesserungen? Im Folgenden sind einige Auslöser aufgeführt, die unsere Studie aufgedeckt hat und die ein Indiz für die zunehmende Komplexität von IT-Umgebungen und des Veränderungsprozesses selbst sind: Vor sieben Jahren, nach der Einführung der Client/Server-Technologie, überstieg die Anzahl und der Umfang der Änderungen, die jede Nacht zur Unterstützung der Produktionsumgebung durchgeführt werden mussten, unsere Fähigkeit, diese Änderungen zu verfolgen. Die Client/Server-Architektur versprach eine Vereinfachung - sie ist kleiner, flexibler usw. - dabei blieb aber unberücksichtigt, wie sich die Komplexität auf die Supportanforderungen auswirken würde. Unsere Systeme müssen während der Börsenzeiten in Betrieb sein, oder die Wirtschaft der USA wird in Mitleidenschaft gezogen. Wir mussten die Kontrolle unserer Mainframe- Umgebung auf die nun unternehmenskritische, verteilte Rechnerumgebung ausweiten.wir konnten keine unternehmenskritischen verteilten Anwendungen (SAP, Manugistics, Siebel) einführen, ohne die Veränderungen in der Produktionsumgebung zu kontrollieren. Es gibt keine Einzelperson und keine Personengruppe, die derzeit alle Abhängigkeiten in der globalen Infrastruktur versteht.wir gehen davon aus, dass durch diesen Umstand in Zukunft immer größere Probleme entstehen werden. Dies gilt für viele Bereiche. Gute Beispiele sind Änderungen an den Routern, die letztlich das DNS beeinflussen. Einfache Änderungen an Firewalls, die an anderen Stellen unerwünschte Ausfälle produzieren. Wir haben ein VPN-Upgrade durchgeführt, das eine Leistungsminderung verursachte, weil interne CNAMES unbeabsichtigt zurückgesetzt wurden. Der direkte Zusammenhang zwischen IT- Fehlfunktionen und kürzlich durchgeführten Änderungen an der IT-Infrastruktur macht zudem deutlich, dass ein effektives Change Management erforderlich ist, um die Häufigkeit und das Ausmaß von IT-Fehlern zu verringern. Ich schätze, dass rund 70 bis 80 Prozent der bei uns auftretenden Zwischenfälle auf Arbeiten (Änderungen) zurückzuführen sind, die wir am Vorabend durchgeführt haben. Die Sommermonate beispielsweise sind eine sehr ruhige Zeit (was den Support angeht), nicht nur weil die Endanwender in Urlaub sind, sondern auch weil die Personen, die die Änderungen an der IT letztlich durchführen, nicht im Hause sind. In dieser Zeit werden nur wenige Änderungen vorgenommen. Im 2

September sind es dann wieder viele. Infolgedessen schnellt die Anzahl der Supportanforderungen um bis zu 40 Prozent in die Höhe. Dies liegt daran, dass alle diejenigen Projekte und Änderungen implementieren, die in den Sommermonaten liegen geblieben sind. Wir haben uns darüber unterhalten, dass die meisten Unternehmen im Hinblick auf das Jahr-2000-Problem alle IT-Änderungen in den Monaten vor dem 1. Januar 2000 eingefroren haben. In dieser Zeit, als alle IT-Änderungen eingefroren waren, war ein erheblicher Rückgang bei der Anzahl der Anrufe in der Serviceabteilung zu verzeichnen. Die Herausforderungen des Change- Management-Prozesses selbst untermauern ebenfalls die Notwendigkeit, die vorhandenen Werkzeuge und Methoden zu verbessern. Die Dokumentierung von Änderungen, insbesondere was verändert wurde und wie, erwies sich im Hinblick auf die Anforderungen unserer Geschäftsumgebung als unzureichend. Die durchgeführten Änderungen wurden oft nicht zeitnah intern kommuniziert. Es waren mehrere Verfahren für die Einreichung von Änderungen in Gebrauch, und die für die Implementierung dieser Änderungen im Produktionsbereich verantwortlichen Teams wurden nicht in jedem Fall vollständig informiert. Dadurch mussten zahlreiche Telefonate geführt werden, und die Änderungen erforderten mehr Zeit als nötig. Diese zusätzliche Zeit verursachte zusätzliche Kosten und erforderte zusätzliches Personal. In vielen Fällen sind die Auslöser offenkundig. Diese Auslöser treten zumeist bei einer einzelnen, schweren Fehlfunktion zutage, die von einer Änderung verursacht wurde, oder sie sind eine Häufung von Beschwerden der Endanwender. In einigen Fällen beruhen sie auch auf einer Unterbrechung des Änderungsprozesses, ausgelöst durch die schiere Anzahl an Änderungen.Was auch immer der Auslöser ist, der Change Impact Factor erreicht in der Regel eine hohe Sichtbarkeit, worauf das IT-Management oder die Geschäftsleitung dann die Verbesserung des Change Management anordnet. Strategischer Nutzen Obwohl die Implementierung einer effektiven Change-Management-Lösung Investitionen in Menschen, Prozesse und Werkzeuge erfordert, überwiegt der daraus resultierende Nutzen diese Anstrengungen bei Weitem. Der unmittelbarste Nutzen ist die Eliminierung der Auslöser, die die Notwendigkeit eines Change Management zuerst zutage treten lassen. Die Verbesserung des Change Management bringt weitere potenzielle Vorteile auf operativer, finanzieller und immaterieller Ebene. Der operative Nutzen besteht aus messbaren Vorteilen, die sich aus Verbesserungen der geschäftlichen oder operativen Effizienz oder der Verringerung der Anzahl an Vorfällen auf Grund von fehlgeschlagenen Änderungen ergeben. Der finanzielle Nutzen kann als quantifizierbare finanzielle Einsparungen definiert werden, zum Beispiel die Reduzierung der Kosten für die Implementierung von Änderungen. Der immaterielle Nutzen beinhaltet eine Reihe so genannter Soft Benefits, wie zum Beispiel größeres Kundenvertrauen und höhere Mitarbeiterzufriedenheit. Operativer Nutzen Finanzieller Nutzen Immaterieller Nutzen Tabelle 1 Nutzenübersicht Reduzierung der Fehlalarme und des Support-Aufkommens. Verringerung des Risikos unplanmäßiger Ausfälle. Reduzierung der geplanten Stillstandszeit durch die Kombination von Aufgaben und die Zusammenlegung mehrerer Änderungen in eine einzige Sitzung. Bessere Analyse der Auswirkungen von Änderungen. Automatisierung von Prozessen und Eliminierung von Papier. Eliminierung von Aufgaben ohne Wertschöpfungscharakter und Steigerung der Produktivität. Asset Management mit Änderungshistorie. Erfüllung der Anforderungen elektronischer Signaturen. Verbesserung des Berichtswesens,um zukünftige Entscheidungen zu verbessern. Verringerung der Kosten durch weniger unplanmäßige Ausfälle von unternehmenskritischen Anwendungen. Reduzierung der Support-Kosten. Verbesserung des Lieferanten- Managements durch die Verfolgung von Gerätefehlfunktionen. Eliminierung von Papier- und Lagerkosten. Reduzierung der Kosten für die Durchführung bestimmter Änderungen. Verringerung des Zeitaufwands für das Ausfüllen von Änderungsanträgen. IVerbesserung der Kommunikation mit betroffenen IT- und Geschäftsanwendern. Steigerung der Kundenzufriedenheit. Erhöhung des Kundenvertrauens in die IT-Organisation. Verringerung des Stresslevels bei den Mitarbeitern. Bessere Sichtbarkeit und Vorhersehbarkeit für unsere Kunden. Aufbau einer partnerschaftlichen Beziehung zu unseren Kunden. Verringerung des Frustrationsgrades bei den Mitarbeitern. Bessere Kommunikation innerhalb des Unternehmens. 3

Zusammengenommen bewirken diese Nutzeffekte eine Minderung der Risiken in einem von der Informationstechnologie abhängigen Unternehmen und eine Verbesserung der Gesamtrentabilität. Hier finden sich also hervorragende Rechtfertigungsgründe für die Change- Management-Initiative. In Tabelle 1 sind die von den Studienteilnehmern genannten Vorteile zusammengefasst. Dabei handelt es sich um echte Vorteile, die den wahren Nutzen wiederspiegeln, den reale Unternehmen durch ein effektives Change Management erzielen. Wenn Sie eine Change-Management-Initiative in Angriff nehmen wollen, sollten Sie zunächst feststellen, welche dieser Vorteile für Ihre Organisation am wichtigsten sind, und gegebenenfalls einige Vorteile hinzufügen, die Sie erreichen wollen. Eine klare und exakte Vorstellung vom erwarteten Nutzen kann dazu beitragen, ein strategisches Mission Statement zu quantifizieren, um eindeutige taktische Ergebnisse zu erhalten.auch wenn Sie über ein etabliertes Change-Management- Verfahren verfügen, ist es von Nutzen, zur Erfolgsmessung die erzielten Vorteile regelmäßig zu überprüfen. Ein Teilnehmer an der Studie äußerte eine interessante Beobachtung. Es sei praktisch unmöglich gewesen, die erzielten Vorteile im Einzelnen zu messen, da das Änderungsmanagement vor dem Start des Projekts zur Verbesserung des Change Management absolut unzureichend war. Die Ursache hierfür war, dass keine Basisdaten zur Verfügung standen, um die Verwirklichung des erwarteten Nutzens zu veranschaulichen. Dies ist ein verbreitetes Problem. Ohne Basisdaten ist es schwierig,verbesserungen zu quantifizieren. Es sollten Verfahren etabliert werden, um Basisdaten frühzeitig zu sammeln - zum Beispiel in der Planungsphase des Projekts. Diese Daten können dann die Grundlage für die Erfolgsermittlung nach Abschluss des Projekts liefern. Die Aufgabe: Ein effektives Change Management Change-Management-Projekte werden in zunehmendem Maße als strategischer Kernbereich innerhalb der IT betrachtet. Mission Statements für Change-Management-Initiativen werden immer ambitionierter und betreffen - neben einer Verbesserung der Kontrolle über die Änderungen - Prozessverbesserungen, Integration und Geschäftsziele. Die Change Management Mission eines Remedy-Kunden lautet beispielsweise: Bereitstellung einer integrierten und harmonisierten globalen Lösung aus mehreren Management-bezogenen IT-Service-Prozessen. Dieses System integriert bestimmte kritische, die Infrastruktur betreffende Prozesse, wie zum Beispiel:Vorfalls- und Problemmanagement, Change Management, Konfigurations- und Asset Inventory Management,Verwaltung von Kundendienstanfragen (Service Request Management) und Service Level Agreement Management. In diesem Statement ist die Integration der Schlüssel zum Erfolg. Das folgende Mission Statement eines anderen Kunden konzentriert sich auf die Problemverringerung als zentralen Erfolgsfaktor beim Change Management: Verfeinerung des Change-Management-Prozesses, um zu gewährleisten, dass alle Änderungen kommuniziert und dokumentiert werden.auf diese Weise soll die Anzahl der Probleme reduziert und die Auswirkungen dieser Probleme auf unsere Kunden vermindert werden. In einem umgestalteten Prozess werden wir dann die erforderlichen Schritte einleiten, um in bestimmten Bereichen die Automatisierung einzuführen und so die Produktivität unserer Mitarbeiter zu erhöhen. In beiden Statements ist ein wichtiges Ziel des Change-Management-Projekts für das Unternehmen klar hervorgehoben. Um seine volle Wirkung zu entfalten, muss das Change Management mehrere Ziele abdecken. Dazu gehören: Erhöhung der Erfolgsquote von implementierten Änderungen. Reduzierung des Umfangs und der Tragweite von IT-Fehlern, die von Änderungen verursacht werden. Integration des Change Management mit anderen Service-Management-Prozessen. Erzielung von Produktivitätssteigerungen. Reduzierung der Kosten für Veränderungen. Festlegung standardisierter Methoden und Verfahren für eine prompte Handhabung von Veränderungen. Analyse der Risiken und der potenziellen Auswirkungen solcher Risiken auf das Unternehmen. Förderung einer hohen Sichtbarkeit der Änderungen. Schaffung von offenen Kanälen für die effektive Kommunikation von Änderungen. Management der Änderungen in allen Phasen. Management der Beziehungen zwischen den Änderungen. 4

Management der finanziellen Aspekte von Änderungen. In der Regel enthält ein Mission Statement nicht alle diese Ziele, sondern konzentriert sich auf die Beseitigung der Auslöser, die die Notwendigkeit für eine Verbesserung des Change Management zutage gebracht haben. Capability Maturity Model Eine erfolgreiche Change-Management-Initiative identifiziert den aktuellen Status des Change Management innerhalb der Organisation, legt Ziele fest und misst anschließend den Fortschritt des Projekts, bis die Ziele erreicht sind. Das Change Management Maturity Model vereinfacht diesen Prozess. Wir haben die Studienteilnehmer aufgefordert, unter Zuhilfenahme von Tabelle 2 anzugeben, wo sie sich beim Start ihrer jeweiligen Change- Management-Initiativen befunden haben, wo sie heute sind und wo sie in Zukunft stehen wollen. Die meisten Studienteilnehmer sagten, dass sie mit Stufe 1 begonnen und inzwischen die dritte Stufe erreicht haben.als Ziel gaben sie Stufe 4 (nicht notwendigerweise Stufe 5) an. Es überrascht nicht, dass der Großteil von ihnen auf Stufe 1 begonnen hat. Der Grund hierfür ist, dass Veränderungen in allen IT-Abteilungen zwar kontinuierlich durchgeführt werden, aber die meisten Einzeländerungen sind begrenzt auf und werden kontrolliert von den Abteilungen, in denen sich die bereits erwähnten Auslösern manifestieren. Das Erreichen der Stufe 3 ist der logische nächste Schritt, da es relativ einfach ist, einen Prozess zur Kontrolle der Änderungen (Change Control Process) innerhalb des gesamten Unternehmens zu etablieren. Stufe 4 hingegen stellt eine größere Herausforderung dar, weil die Durchführung der erforderlichen Planungsprozesse, die Implementierung eines effektiven Finanzmanagements und die Integration des Asset Management mit anderen IT-Service- Management-Prozessen ein wesentlich größeres Maß an Engagement und Investitionen voraussetzt. Warum aber wird nicht Stufe 5 von den IT- Organisationen als Endziel angesehen? Der Grund hierfür ist, dass Stufe 5 zwar ein wünschenswertes Ziel ist, aber außerhalb des Kontrollbereichs der IT-Organisation liegt. Darüber hinaus sind die Geschäftsprozesse des Unternehmens möglicherweise nicht ausreichend entwickelt, um eine funktionsübergreifende Integration zu ermöglichen. Durch einen nachweisbaren Erfolg auf Stufe 4 kann die Informationstechnologie jedoch den geschäftlichen Nutzen demonstrieren, den die Integration des Change-Management-Prozesses mit anderen Service-Management-Prozessen innerhalb der IT-Organisation bietet. Die IT- Organisation kann dann diesen Nutzen auf die Integration des Change Management mit anderen Geschäftsprozessen innerhalb des Unternehmens extrapolieren, um die Geschäftsführung für ein solches Vorhaben zu gewinnen. Der Umfang des Change Management Eine der größten Herausforderungen beim Change Management besteht darin, den Umfang des Change 0 Abwesenheit Keine Anzeichen von geplanten und dokumentierten Aktivitäten, die den Prozess begleiten. Tabelle 2 Capability Maturity Model 1 Initiierung Informelle Aktivitäten vorhanden, weisen aber innerhalb eines Prozesses keine Verbindungen miteinander auf. 2 Bewusstsein Es existiert zwar ein Prozess, aber einige Aktivitäten sind unvollständig oder inkonsistent. Es gibt keine übergreifende Messung oder Kontrolle. 3 Kontrolle Gutes Verständnis und Implementierung des Change Management als Einzelprozess, aber keine Integration mit anderen Prozessen. Es gibt minimale Vorausplanungen und Budgetmanagement, aber keine Finanzplanung. 4 Management Der Prozess umfasst Finanzmanagement, Vorausplanung, Trendanalysen und Geschäftsbeziehungen und ist integriert mit anderen IT-Systemen und Service-Prozessen. 5 Strategisch Das Change Management ist vollständig integriert in die Geschäftsprozesse und bietet eine Plattform, die der Geschäftsführung hilft, verlässliche Unternehmensentscheidungen unter Ausnutzung ihrer technologischen Ressourcen zu treffen. Englisches Original mit freundlicher Genehmigung von Pink Elephant 5

6 Management festzulegen. Ist das Change Management zu breit angelegt, wird das System zu schwerfällig. Dies kann Verzögerungen verursachen anstatt sie zu beseitigen. Ist der Umfang zu klein, bleiben kritische Änderungen möglicherweise außerhalb des Change-Management-Prozesses und können Probleme und Fehlfunktionen verursachen. Die meisten Kunden, die wir befragt haben, begannen mit einem begrenzten Umfang und erweiterten ihn in dem Maße, wie sich ihre Change-Management- Prozesse und Fertigkeiten entwickelten. Die folgenden Zitate von Studienteilnehmern zeigen, wie sich der Änderungsumfang mit zunehmender Ausreifung des Change Management erhöhte: Unser Spektrum/Ziel hat sich im Laufe der Implementierung weiterentwickelt. In Phase I beinhaltete der Prozess ursprünglich alle Produktionsänderungen: Hardware, Software und zum Teil auch Einrichtungen. Dies war begrenzt auf Server mit direkter Auswirkung auf den Kunden. Phase II: Einbeziehung nicht nur aller Hard- und Software, die sich auf die Kunden auswirkt, sondern auch aller Änderungen, die unsere Fähigkeit beeinflussen, Dienstleistungen für unsere Kunden anzubieten, sowie die Überwachung (Service Level) von Hard- und Software, die zur Sicherung ihrer problemfreien Bereitstellung verwendet wurde. Phase III: Gegen Ende wurden alle Aspekte der Qualitätssicherung (QS) einbezogen, die einen technischen Bezug haben.wir haben festgestellt, dass die gleichen Funktionen, die in unserer Produktions- und Staging-Umgebung durchgeführt wurden, auch bei der Einrichtung von QS-Servern für Testzwecke ablaufen. Wir fanden heraus, dass wir durch die Ausweitung des Prozesses auf alle Technologiebereiche einige analoge Effizienzgewinne erzielen konnten. Es begann mit simplen Änderungen im Client/Server- Bereich. In den vergangenen drei Jahren wurde der Prozess auf den Mainframe, das Kommunikationssystem (LAN/WAN) und geschäftliche Änderungen ausgeweitet. Das Change Management Capability Maturity Model kann dazu beitragen, den Umfang des Change Management zu bestimmen und zu erweitern. Die Prozessverbesserungsstufen dieses Modells bieten eine genau definierte Progression für die schrittweise Erweiterung des Umfangs.Angenommen, der ursprüngliche Umfang beinhaltet Server-Änderungen.Wenn die Mitarbeiter nachweisen, dass die Änderungsprozesse in diesem Bereich stabil laufen und dass die Anzahl der Serverprobleme reduziert werden konnte, kann der Umfang auf Änderungen am Netzwerk ausgedehnt werden. Ein Stufenkonzept wird im Rahmen des Change- Management-Prozesses wahrscheinlich breiter und schneller akzeptiert, da es auf früheren Erfolgen aufbaut. Letztlich sollten alle Statusänderungen an sämtlichen Infrastrukturkomponenten abgedeckt werden, die für die Bereitstellung von IT-Systemen und -Services, einschließlich Hardware, Software, Telekommunikation und Dokumentation, erforderlich sind. Change Authority Neben der Definition des Umfangs der Komponenten, die in das Change Management einbezogen werden sollen, muss zudem festgelegt werden, wer Änderungen genehmigen kann. Änderungen erfordern in ihrem Verlauf in der Regel Autorisierungen auf unterschiedlichen Stufen, angefangen bei der Genehmigung eines Request For Change (RFC), über die Annahme dieses Request, bis hin zur Genehmigung der Implementierung der Änderung. Die Anzahl und Art der Genehmigungsstufen hängt in erster Linie von zwei Faktoren ab: der Managementstruktur Ihrer Organisation und dem Change-Management- Prozess, der implementiert werden soll. Die Managementstruktur bestimmt die Genehmigungsstufen in den verschiedenen Phasen der Änderung.Als erster Filter kann beispielsweise vorgesehen werden, dass ein RFC von einem Business Manager unterschrieben werden muss, um sicherzustellen, dass ein Business Manager die beantragte Änderung geprüft und genehmigt hat, bevor sie in das Change- Management-System gelangt. Sobald eine Änderung in das System aufgenommen wird, sind für jeden Schritt weitere Genehmigungen/ Unterschriften erforderlich. Dringende Änderungen, zum Beispiel die Behebung eines Problems im Produktionssystem, das Fehlfunktionen verursacht, werden in der Regel im Rahmen eines separaten Change- Management-Prozesses abgearbeitet, mit dem der Standardprozess umgangen wird, da in solchen Fällen sofortiges Handeln nötig ist. Einer der befragten Kunden handhabt dringende Änderungen folgendermaßen: Änderungen mit hoher Priorität, die während der Geschäftszeiten durchgeführt werden müssen, erfordern die Unterschrift der Geschäftsleitung und die Zustimmung aus einem oder mehreren der folgenden Bereiche: Genehmigender Manager: In der Regel der direkte Vorgesetzte desjenigen, der den Antrag einreicht. Produktion: Zustimmung zu den gemachten Angaben und Prüfung, ob es umgesetzt werden kann.

Infrastruktur-Services: Zustimmung und Richtigkeitsprüfung der vorgelegten Informationen. Entwicklung: Zustimmung, dass es sich nach ihrer Auffassung um eine Änderung handelt, die für die problemfreie Ausführung oder Entwicklung der Anwendung erforderlich ist. Qualitätssicherung: Freigabe aus der Testabteilung vor der Implementierung. Kundendienst: Geschäftsfreigabe, mit der bestätigt wird, dass die Änderungen durchgeführt werden müssen und die betroffenen Kunden informiert wurden. Produkt: Dies ist die Projektplanungsabteilung, die die Demo-Sites betreibt und den Verkauf unterstützt. Dieser Kunde achtet besonders sorgfältig darauf, dass die erforderlichen Unterschriften vorliegen, um sicherzustellen, dass eilige Änderungen nicht fehlschlagen. Korrekte Autorisationen helfen, durch Änderungen verursachte Fehlfunktionen zu vermeiden, die sich katastrophal auswirken und die IT-Organisation in erhebliche Schwierigkeiten bringen können. Eine Änderung, die ein Problem verschärft anstatt es zu lösen, wäre zweifellos katastrophal und sehr peinlich. Change Advisory Board Die meisten Organisationen verfügen über ein Change Advisory Board (CAB), auch wenn sie dafür eine andere Bezeichnung verwenden. Ungeachtet der Namensgebung, ist die Aufgabe dieses Gremiums immer die gleiche: Eine funktionsübergreifende Gruppe mit der Befugnis, alle RFCs zu prüfen und zu genehmigen oder abzulehnen. Die Entscheidung, ob eine beantragte Änderung umgesetzt wird oder nicht, erfolgt in der Regel auf der Grundlage der Kosten, der Komplexität und der Auswirkungen oder reflektiert den Umstand, dass das in dem RFC beschriebene Problem bereits durch andere geplante Änderungen behoben wird. Alle befragte Kunden gaben unisono an, ein CAB zu besitzen: Verfügen Sie über ein CAB? JA Wenn ja, wer ist Mitglied in Ihrem CAB? Senior- Analysten und Berater. Berater sind Managern gleichgestellt. Wie oft tritt das CAB zusammen? Wöchentlich. Nehmen sowohl Business Manager als auch IT Manager daran teil? Business Manager nehmen normalerweise nicht daran teil. Ihre Interessen werde von den Site Managern wahrgenommen. Das CAB trifft sich mindestens zwei Mal täglich, einmal allein und einmal mit dem Hauptkunden. Es existiert ein Ausschuss, der die Auswirkungen von größeren geplanten Änderungen analysiert. In diesem Ausschuss sind die Unternehmensbereiche Business, Entwicklung, Qualitätssicherung und Operations vertreten. Er tritt bei Bedarf zusammen. Diese Aussagen rücken drei Schlüsselfragen in Bezug auf ein CAB in den Mittelpunkt: Brauchen wir ein CAB? Wie häufig sollte es zusammentreten? Welche Gruppen sollten in einem CAB repräsentiert sein? Die Tatsache, dass jeder der von uns befragten Kunden über ein CAB verfügt, unterstreicht die Bedeutung eines solchen Gremiums. Die anderen beiden Fragen wollen wir genauer untersuchen. Wie häufig ein CAB zusammentreten sollte, hängt oft von der Art des Unternehmens ab. In einer schnelllebigen Branche, die stark von der Informationstechnologie abhängig ist, wird das CAB häufiger zusammentreten als in einem weniger volatilen Geschäftsumfeld. Der Bereich Finanzdienstleistungen beispielsweise ist ein dynamisches Umfeld, das kontinuierliche und unmittelbare Änderungen erfordert. In dieser Branche wären tägliche Sitzungen des CAB nicht übertrieben. Ein großer Konsumgüterhersteller andererseits kann Änderungen über einen längeren Zeitraum implementieren. In einem solchen Fall sind weniger häufige Sitzungen des CAB denkbar. Um festzulegen, wie oft Ihr CAB zusammentreten sollte, sind die Dringlichkeit und die Auswirkungen von Änderungen in Ihrer Organisation zu berücksichtigen. Die Mitglieder des CAB können aus verschiedenen IT- und IT-fremden Gruppen kommen. In unserem dritten Beispiel weiter oben sind Vertreter aus den Bereichen Business, Entwicklung, Qualitätssicherung, IT und Operations im CAB vertreten. Dies repräsentiert einen guten Querschnitt, da unterschiedliche Perspektiven aus den folgenden Bereichen eingebracht werden: Die kaufmännische Seite weist auf geschäftliche Argumente und Gefahren der geplanten Änderungen hin. Der Bereich Entwicklung liefert Informationen über die technischen Aspekte, die Kalkulation und den Arbeitsaufwand. Die Qualitätssicherung untersucht die Auswirkungen auf die Prozesse und die Qualität. Der Bereich Operations prüft die Praktikabilität der Umsetzung einer Änderung. 7

8 Die Anzahl der Personen, die an den CAB- Sitzungen teilnehmen ist weniger wichtig als die Bereiche, die sie repräsentieren. Die CAB- Mitglieder sollten als Repräsentanten ihrer Kollegen und nicht als Mitglieder einer geheimen Gemeinschaft angesehen werden. Generell sollte ein CAB auf möglichst wenige Personen beschränkt werden, wobei gewährleistet sein sollte, dass sich alle Bereiche einbringen können, die von Änderungen betroffen sein könnten. Change Testing Die Frage des Testens von Änderungen ist immer strittig. Zudem ist es nicht immer möglich, vor der Übertragung auf die Produktionsumgebung ausführliche Tests durchzuführen. Beispielsweise kann eine neue Version eines Browsers zwar auf seine Kompatibilität auf allen Computern in der Testumgebung getestet werden, aber diese Kompatibilitätstests lassen sich wahrscheinlich nicht auf allen im Unternehmen stationierten Computern durchführen. Eine Simulation kann hier Abhilfe schaffen. Eine teilweise Implementierung in die Produktionsumgebung kann ebenfalls hilfreich sein.aber auch mit diesen Testverfahren lassen sich die Auswirkungen einer vollständigen Implementierung nicht voraussagen. Daher muss festgelegt werden, welche Tests für spezifische Änderungen benötigt werden. Von zentraler Bedeutung ist zudem, wer die Tests durchführt und wer überprüft, ob die Testanforderungen erfüllt wurden und ob die Testergebnisse verlässlich sind. Normalerweise werden einige Tests vom Change Builder durchgeführt. Darüber hinaus müssen auch unabhängige Tests durchgeführt werden, um festzustellen, ob die Tests wirklich aussagekräftige Ergebnisse geliefert haben. Die Antworten der Studienteilnehmer zeigen, dass allen Tests etwas gemeinsam ist: Input Qualifications und Output Qualifications (IQ/OQ s), die einen Testplan und eine Liste der durchzuführenden Aktivitäten beinhalten. Verantwortlich für die Tests ist in der Regel der Operations Manager der betreffenden Anwendung oder das QS-Team (oder beide). Sie sind für einen sinnvollen Ablauf der Tests verantwortlich. Änderungen durchlaufen eine Qualitätssicherungsumgebung, eine Staging-Umgebung und gelangen dann in die Produktion; sie erfordern QS-Autorisierungen, um für die Produktion freigegeben zu werden. Bei allen Änderungsprojekten sichert ein QS-Team die tatsächliche Unabhängigkeit der Tests. Der zuerst zitierte Kunde schreibt zudem einen Testplan für jede Änderung vor. Dies ist eine gute Strategie, da auf diese Weise die Unabhängigkeit der Testkriterien gewährleistet ist und ein QS-Team bei Bedarf unabhängige Tests durchführen kann. Forward Schedule of Changes Ein Forward Schedule of Changes (FSC) umfasst alle im System vorhandenen Änderungen, ihre wichtigen Meilensteintermine, einschließlich des Zieltermins der Implementierung, sowie den aktuellen Status dieser Änderungen. Das FSC sollte nach jeder CAB-Sitzung aktualisiert und im gesamten Unternehmen kommuniziert werden. Je früher Änderungen im Verlauf des Prozesses protokolliert werden, desto größer ist der Nutzen eines FSC. Die Studienteilnehmer verfolgen beim FSC unterschiedliche Ansätze: Zwei Wochen vorab wird ein Change Report erstellt, um die Auswirkungen auf die Infrastruktur, den Kunden und das Geschäft zu prüfen und zu analysieren. Diese Prüfung wird vom Technical Change Advisory Board durchgeführt. Wir haben in der Tat ein FSC. Das FSC wird von der QS-Gruppe geführt und wöchentlich aktualisiert. Die meisten Änderungen werden auf einen Montag oder einen Donnerstag gelegt. Für umfangreichere Änderungen, an denen gegebenenfalls mehrere Gruppen beteiligt sind, die Einführung neuer Versionen oder Hot Fixes gibt es Projektplaner, die diese Änderungen für das Unternehmen projektieren. Bei Änderungen, die größere Auswirkungen mit sich bringen, setzen wir Projektplaner ein. Bei kleineren Änderungen verwenden wir eine Art Change-Control-Verfahren. Diese drei unterschiedlichen Ansätze entsprechen den Anforderungen in drei verschiedenen Umgebungen. Jede Organisation muss ihre Bedürfnisse analysieren und entscheiden, welches FSC-Verfahren für sie am besten geeignet ist. Gleichgültig, welche Methode Sie auswählen, ein FSC ist für ein erfolgreiches Change Management von entscheidender Bedeutung, da ohne ein FSC eine wirksame Änderungskontrolle nicht möglich ist. Kommunizieren von Änderungen Einer der wichtigsten Faktoren für den Erfolg des Change Management ist eine effiziente und hochwertige Kommunikation des aktuellen Stands aller Änderungen am System.Alle Betroffenen müssen regelmäßig über sämtliche Aspekte aller laufenden Änderungen auf den neuesten Stand gebracht werden.aus den folgenden Zitaten wird deutlich, das die Studienteilnehmer erhebliche Anstrengungen unternehmen, um den Status ihrer Änderungen zu kommunizieren:

Wir verwenden ein Makro in Remedy, um die Daten in eine CSV-Datei zu übertragen.anschließend wird diese Datei mit Hilfe eines Excel-Makros formatiert und als Excel-Dokument gespeichert. Dann stellen wir sie für den internen Gebrauch auf die Website in unserem Intranet und auf die Website unseres Kunden. Die Assets und Standorte müssen manuell eingegeben werden. Unsere Site Manager und Ingenieure liefern bei Bedarf Feedback. Änderungen werden in erster Linie durch E-Mails kommuniziert. Je nach Wichtigkeit und Dringlichkeit werden dazu auch Piepser verwendet und/oder die Betreffenden per Telefon informiert. Das Feedback zu Änderungen, die durchgeführt bzw. nicht durchgeführt wurden, wird nachts per E-Mail versendet. Wir versenden Feedback per E-Mail, und jeder besitzt Zugang zum System und kann die Änderungen verfolgen. Darüber hinaus können die Änderungen zu den betroffenen Kunden, Servern bzw. Produkten zurückverfolgt und auf unseren Asset-Tracking und Client-Profile- Bildschirmen angezeigt werden. Der Status der Änderung wird an drei Gruppen kommuniziert: Diejenigen, die die Änderungen vornehmen (Change Builders); diejenigen, die von den Änderungen betroffen sind (Change Recipients); und diejenigen, die die Änderungen nach ihrer Implementierung unterstützen müssen (Change Integrators). Die Change Builders müssen die anderen beiden Gruppen informieren, damit die Change Recipients die Auswirkungen der Änderung verstehen und wissen, wann sie wirksam wird, und damit die Change Integrators über genaue Informationen verfügen, um die für die Änderung erforderliche Umgebung vorzubereiten. Um eine solche Kommunikation zu gewährleisten, können die Betroffenen entweder einzeln informiert werden, oder Sie stellen eine Plattform bereit, wie zum Beispiel ein Intranet, wo die Betroffenen die Veränderungen selbständig verfolgen können. Wie den obigen Äußerungen zu entnehmen ist, nutzen die Studienteilnehmer beide Kommunikationsmöglichkeiten. Die Teilnehmer eins und drei setzen auf das sicherste Verfahren: Benachrichtigung der direkt von der Änderung Betroffenen und zusätzlich die Bereitstellung einer Plattform, wo die Betroffenen die Änderung verfolgen können. Ganz gleichgültig, wie gut die Change- Management-Prozesse sind, wenn Sie kein Feedback liefern, setzen Sie sich der Kritik Ihrer Kunden aus. Messen von Veränderungen Erfolgreiche Unternehmen setzen auf einen guten Informationsfluss, um intelligente Entscheidungen treffen zu können. In gleichem Maße benötigt auch die Informationstechnologie aussagekräftige Informationen, um intelligente IT-Entscheidungen zu treffen. Die Informationstechnologie befindet sich in einem ständigen Wandel. Dies kann dazu führen, dass IT-Entscheidungen von unbekannten Änderungen innerhalb des Systems beeinflusst werden. IT-Manager müssen über alle geplanten und genehmigten Änderungen informiert werden, damit sie gut informierte und intelligente Entscheidungen über zukünftige Entwicklungen und Verbesserungen im Bereich der Informationstechnologie treffen können.alle Studienteilnehmer messen die Auswirkungen und den Umfang der Änderungen. Es wurde deutlich, dass sie besonderen Wert auf das kontinuierliche Feedback über den aktuellen Stand der Änderungen legen. Damit aber die Messwerte den erforderlichen Informationsgehalt besitzen, müssen alle Änderungen in das Change Management eingebunden werden, BEVOR mit den Arbeiten für die Änderung begonnen wird.auf diese Weise wird die Qualität der Managementinformationen deutlich erhöht. Wenn beispielsweise das Netzwerk-Team seit drei Monaten an einer Änderung arbeitet, die Änderung aber erst vorlegt, wenn die Implementierungsreife erreicht ist, kann das Management keine informierte Entscheidung in Bezug auf andere Aspekte der Informationstechnologie treffen, die das Netzwerk nutzen. Das Management sollte in der Lage sein, den aktuellen Stand aller geplanten und in der Pipeline befindlichen Änderungen abzurufen. Erstaunlich ist, dass keiner der Studienteilnehmer verlangt, Änderungen bereits zu Projektbeginn einzureichen, sondern erst zu einem späteren Zeitpunkt: Die Änderung muss vor ihrer Implementierung eingereicht werden, und zwar mit genügend Vorlauf, damit sie ordnungsgemäß an alle Betroffenen kommuniziert werden kann. Die Kommunikation erfolgt entweder im Rahmen des Genehmigungsprozesses oder per E-Mail. Dies ist zwar ein gutes Beispiel für eine wirksame Änderungskontrolle, aber die Informationen werden nicht frühzeitig genug bereitgestellt, um ein effizientes Change Management zu gewährleisten. Ein effektives Change Management, das heißt das Erreichen der CMM-Stufen 4 und 5, macht es erforderlich, ein kontinuierliches Change Management - vom Change Request bis zur erfolgreichen Implementierung der Änderung -sicherzustellen. Finanzmanagement In vielen Organisationen kann sich das Finanzmanagement als Mienenfeld erweisen. Die meisten Organisationen kennen weder die wahren Kosten ihrer IT-Änderungen noch ist ihnen bewusst, dass die Kosten von Änderungen eine 9

wesentliche Komponente beim Management von IT-Investitionen darstellt. Dies bezeichnet Gartner Group als versteckte Kosten der Informationstechnologie. Es wird viel über den Return On Investment (ROI) geredet. Dabei handelt es sich, einfach ausgedrückt, um die Differenz zwischen den Kosten eines Projekts und seinem Ertrag. Es wird jedoch nur wenig über ein weiteres Konzept der Gartner Group gesprochen, nämlich die Total Cost of Ownership (TCO), die die Kosten für die Unterhaltung einer Dienstleistung oder eines Systems über seine gesamte Lebensdauer messen. Um ein effektives Finanzmanagement im Bereich der Informationstechnologie zu ermöglichen, müssen die Kosten von Änderungen einem TCO- Konto zugeordnet werden, so dass diese sichtbar werden. Das Sichtbarmachen dieser bisher versteckten Kosten ermöglicht ein effektives Kostenmanagement.Auf die Frage, ob seine Organisation Kostenanalysen durchführt, antwortete einer der Studienteilnehmer: Nein, wir haben nie zusammengesessen und eine Kostenanalyse aufgestellt. Dies gilt nicht nur bei Änderungen.Wir wissen nicht einmal, was es uns kostet, ein Problem zu lösen, und ich glaube, dass dies zu den Dingen gehört, die funktionieren müssen, bevor man mit SLAs beginnt. Wie die meisten Unternehmen konzentriert sich auch die Organisation dieses Studienteilnehmers auf das Change Control und nicht auf das Change Management. Die Gesamtkosten der einzelnen Änderungen sollten miteinander verknüpft und in eine zentrale Datenbank gestellt werden, um eine Analyse durch das Management zu ermöglichen. Anderenfalls kann sich das Change Management als der bei Weitem größte Posten in den versteckten Kosten erweisen. Integration von Veränderungen mit anderen Prozessen IDie Integration des IT-Change-Managements mit anderen IT-Service-Management-Prozessen maximiert die Effektivität und beseitigt redundante Arbeiten. Die Integration von Änderungen beispielsweise mit dem Konfigurations- und Asset- Management-Prozess ermöglicht es, beim Betrachten eines Asset gleichzeitig alle vergangenen und laufenden Änderungen dieses Asset anzuzeigen. Wenn sich das Servicedesk mit einem Vorfall beschäftigt, kann der Sachbearbeiter erkennen, ob die fehlerhafte Komponente am vorangegangenen Tag einer Änderung unterzogen wurde. Der wirkliche Nutzen ergibt sich aus der Integration der Service-Management-Prozesse, und nicht nur durch die Verbesserung eines einzelnen Service- Management-Prozesses. Einer der Studienteilnehmer schildert, wie er von der Integration profitiert: Unsere Change-Management-Anwendung besitzt eine automatische Verknüpfung zu unserer Asset-Management- Anwendung. Es gibt zwar manuelle Verknüpfungen zu unserem Bug/Enhancement-Tracking, aber dies ist ein manuelles Verfahren, das voraussetzt, dass Mitarbeiter diese Verknüpfungen auch wirklich herstellen. Das Change Management ist zudem mit allen unseren Kundenprofilen verknüpft. Dies ermöglicht uns, ein Kundenprofil auszuwählen und sofort zu erkennen, welche Änderungen vorgenommen wurden und wie sich diese Änderungen auf den Kunden ausgewirkt haben. Darüber hinaus sind die Änderungen für alle Mitarbeiter des Unternehmens einsehbar. Mit Unterstützung unserer externen Kunden haben wir dafür gesorgt, dass die Änderungen zudem über unsere Problemmanagement-Bildschirme verfügbar sind. Dies ermöglicht es unseren Support-Mitarbeitern aus dem kaufmännischen Bereich, diese Informationen bei Kundengesprächen abzurufen. Bei diesem Beispiel verbessert die Integration des Change Management mit dem Asset Management, den Kundenprofilen und dem Problemmanagement nicht nur das Change Management selbst, sondern auch die Messbarkeit und Nutzbarkeit. Auf Grund der großen Bedeutung der Integration sollte dafür gesorgt werden, dass eine einfache Integrationsfähigkeit mit anderen Service- Management-Systemen in die Kriterien bei der Auswahl einer Change-Management-Lösung aufgenommen wird. Von Change Control zum Change Management Viele Organisationen verfügen über ein gutes Change Control, aber nur wenige besitzen ein gutes Change Management. Die Studienteilnehmer verfügen bei dem Change Control generell über ein hohes Niveau, haben aber bislang den Schritt zu einem effektiven Change Management nicht vollständig vollzogen.was sind die Hauptfaktoren, die das Change Management vom Change Control unterscheiden? Um als Change Management zu gelten, sollte der Prozess die folgenden Merkmale aufweisen: Lifecycle Management. Eine Änderung muss in das Change Management eingebettet werden, bevor jegliche Arbeiten daran beginnen, und nicht, nachdem die Arbeiten abgeschlossen sind und die Änderung zur Freigabe für die Produktion bereit ist. Consensus Approval. Bevor mit den Arbeiten 10

an einer Änderung begonnen wird, müssen alle beteiligten Parteien der Änderung zugestimmt haben. Diese Parteien sind: Change Builders, Change Recipients, Change Integrators, Business Manager sowie alle anderen Parteien, die an dieser Änderung beteiligt oder von ihr betroffen sind. Forward Schedule of Changes. Es sollte ein Zeitplan angelegt werden, der die Fristen für alle Änderungen enthält, einschließlich der tatsächlichen und der projektierten Termine. Finanzmanagement. Die Gesamtkosten von Änderungen müssen in einer zentralen Change- Costing-Datenbank zusammengefasst werden. Kommunizieren von Änderungen. Der aktuelle Stand aller Änderungen muss regelmäßig an alle betroffenen Parteien kommuniziert werden. Messgrößen. Es sollten umfassende Change- Messgrößen in einer Datenbank zusammengefasst werden, um Daten zur Messung des Erfolgs des Change Management und seiner kontinuierlichen Verbesserung zur Verfügung zu haben. Change Control ist eine Stufe innerhalb des Maturity Model, aber Change Management ist unverzichtbar, wenn die Informationstechnologie Kosten kontrollieren, die Entscheidungsfindung verbessern und die negativen Auswirkungen von Änderungen auf die Unternehmen verringern soll. Change Control kann Organisationen helfen, strukturiert und planvoll vorzugehen. Das Change Management hingegen trägt dazu bei, ein hohes Niveau der Strukturierung und Planung zu gewährleisten. Change Control kann durch simple manuelle Prozesse auf der Basis grundlegender Software-Funktionen erreicht werden. Um ein Change Management zu erreichen, das nach Best- Practice-Verfahren abläuft, ist jedoch eine hochwertige Software-Lösung erforderlich. Zusammenfassung Durch die ständig steigende Komplexität und Geschwindigkeit der Veränderungen der IT- Infrastruktur sowie die zunehmenden Auswirkungen von IT-Fehlfunktionen auf abhängige Unternehmenssysteme stehen IT- Experten unter einem hohen Druck, die Bereitstellung und den Support von IT-Services zu verbessern.viele IT-Experten überprüfen ihre Strategien und starten Change-Management- Projekte. Dies ist eine große Herausforderung, da eine effektive Change-Management-Lösung sowohl Finanzmanagement, Forward Scheduling, Trendanalysen als auch Geschäftsbeziehungen abdecken und mit anderen IT-Service- Management-Systemen und -Prozessen integriert werden muss.viele Remedy-Kunden haben diese Herausforderung erfolgreich bestanden. Einige dieser Kunden haben buchstäblich bei Null begonnen, andere haben eine effektive Change- Management-Lösung weiterentwickelt. Im Verlauf dieses Prozesses ist es ihnen gelungen, die IT- Ausfallquoten, die Kosten für den IT-Support und negative Auswirkungen auf kritische Geschäftsprozesse, die von der IT-Infrastruktur abhängen, zu reduzieren. Dieses Dokument zeigt, dass es kein Patenrezept für die Planung und Implementierung einer effektiven Change-Management-Lösung gibt. Die Kriterien für eine Lösung und den besten Ansatz für ihre Implementierung sind in hohem Maße von den spezifischen Bedürfnissen der jeweiligen Organisation abhängig. Biografie von Malcolm Fry Malcolm Fry ist ein unabhängiger Executive Partner bei Remedy, der die Bemühungen von Remedy-Kunden regelmäßig unterstützt und Vorträge auf Remedy-Events hält. Malcolm Fry ist eine anerkannte Koryphäe der IT-Industrie und blickt auf eine über 35-jährige Erfahrung in vielen Branchen zurück, wie zum Beispiel Einzelhandel, Produktion, Petrochemie und Pharmazie sowie Consulting. Die Kombination aus Berufspraxis und beeindruckenden Fachkenntnissen macht Malcolm Fry zu einem Experten, dessen Wissen und Erfahrung ihresgleichen suchen. Er ist Autor von vier Büchern über IT-Service und -Support, die an der Spitze der Bestsellerlisten stehen. Darüber hinaus ist er Verfasser vieler Beiträge und Artikel und spielt die Hauptrolle in einer enorm erfolgreichen Videoserie, die für das Help Desk Institute produziert wurde. Malcolm Fry besitzt das ITIL- Masters-Zertifikat. Remedy Unternehmensprofil Remedy, a BMC Software company, automatisiert service-bezogene Geschäftsprozesse durch eine komplette Suite von Best-Practice Service Management Applikationen, einschließlich IT Service Management, Help Desk,Asset und Change Management, Customer Service und Support Lösungen.Alle Remedy Produkte basieren auf dem flexiblen Action Request System (AR System), einer umfassenden Entwicklungsumgebung, die mit der Automatisierung zahlreicher Geschäftsprozesse, die Anforderungen moderner Unternehmen heute und in Zukunft erfüllt. Remedy zählt 79 Prozent 11

der Fortune 100 Unternehmen und 60 Prozent der Fortune Global 500 Firmen zu seinen Kunden. Remedy Lösungen sind in über 80 Ländern weltweit im Einsatz, mit mehr als 10 Millionen Benutzern. Remedy wurde 1990 in Mountain View, USA, gegründet und beschäftigt heute weltweit ca. 760 Mitarbeiter, davon 30% im Support, 23% in R&D. Remedy betreut seine Kunden und Partner in Europa durch Hauptniederlassungen in England (Nord-Europa), Deutschland (Zentral- Europa) und Italien (Süd-Europa). Seit November 2002 ist Remedy ein Geschäftsbereich der BMC Software und tritt dort als eigenständige Business Unit auf. Remedys Service-Management- und BMCs Enterprise- Management-Lösungen sollen Kunden gemeinsam zu einem ganzheitlich integrierten Service- Management-Ansatz führen. Das Action Request System (AR System) bietet neben der bereits bewährten Client-Server Entwicklungsumgebung jetzt eine neue, für das Internet optimierte Entwicklungsumgebung in Verbindung mit hochwertigen Workflow- Funktionen. Dies gewährleistet äußerste Flexibilität bei der Erstellung von leistungsfähigen, einfach zu bedienenden, globalen Anwendungen. Das AR System integriert somit in einer einzigen Lösung eine übergreifende Plattform für Entwurf, Entwicklung und Einsatz von neuen Anwendungen sowie für die Anpassung vorhandener, mit AR System erstellten Anwendungen. Remedy Service Management ist eine hochintegrierte, skalierbare Gesamtlösung für das klassische IT Service Management. Die Lösung ist modular aufgebaut und beinhaltet die Module Help Desk, Change Management,Asset Management und Service Level Agreement. Die den Modulen zugrundeliegenden Prozesse entsprechen gängigen Industriestandards, sogenannten Best Practices und verhalten sich ITIL konform.alle Module der Remedy Service Management Suite basieren auf dem Action Request System und einer gemeinsamen Datenbasis. Remedy vertreibt seine Produkte über ein globales Netz von Business Partner, dazu gehören System Integratoren, Consulting Partner und Technologie Partner. In Zentral Europa sind CC CompuNet, IBM, Materna, Siemens SBS, Softlab und T-Systems strategische Remedy Partner. Remedy,a BMC Software company Lyoner Str. 36 60528 Frankfurt Tel: +49(0)69 66406 343 Fax: +49 (0) 69 66406 330 www.remedy.com 10 Remedy,a BMC Software company.remedy,das Remedy-Logo und alle anderen Produkt- und Dienstleistungsnamen von Remedy sind eingetragene Marken oder Warenzeichen von BMC Software, Inc. 2003 BMC Software, Inc. Alle Rechte vorbehalten.