AdvancedITIL

Service-Support-Metriken

Change-Management

Kapitel 7

Ebenso wie für das Problem-Management empfiehlt ITIL auch für das Change-Management zwei Überwachungsebenen. Die erste Ebene, die Erstellung von Managementberichten, entspricht derjenigen für das Problem-Management. Die zweite Ebene sieht etwas anders aus, da ITIL hier auf die BSI-Publikation „A Code of Practice for IT Service Management“ (PD0005) verweist. Diese Ebene konzentriert sich auf ausführliche Berichte zum Change-Management. Denken Sie bei beiden Ebenen an das Hauptziel für das Change-Management:

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.

Das Change-Management bietet eine Fülle von Daten für die Überwachung, Messung und Metrik. ITIL konzentriert sich auf die folgenden Kernpunkte:

  • Anzahl der in diesem Zeitraum implementierten Änderungen, aufgeschlüsselt nach Gesamtzahl, Konfigurationselement (KE), Konfigurationstyp, Service usw.
  • Aufschlüsselung der Gründe für Änderungen (Benutzeranfragen, Verbesserungen, unternehmerische Anforderungen, Beantwortung von Service-Anrufen/Vorfalls-/Problembehebung, Verbesserung von Verfahren/Training usw.)
  • Gesamtzahl der erfolgreichen Änderungen
  • Anzahl der zurückgezogenen Änderungen und Gründe für den Rückzug (z.B. falsche Einschätzung, Softwarefehler)
  • Anzahl der auf Änderungen zurückzuführenden Vorfälle(aufgeschlüsselt nach Problemgewichtung) und Gründe (z.B. falsche Einschätzung, Softwarefehler)
  • Anzahl der Änderungsanfragen (und Trends in der Veranlassung)
  • Anzahl der implementierten und überprüften Änderungen und Umfang der noch auszuführenden Überprüfungen (aufgeschlüsselt nach Zeitverlauf)
  • Vermehrtes Auftreten von Änderungsanfragen/Problemberichten zu einem bestimmten KE (dies verdient besondere Beachtung) sowie die Gründe hierfür (z.B. hoher Bedarf der Anwender, empfindliche Komponente, Softwarefehler)
  • Zahlen aus früheren Zeiträumen (letzte Periode, letztes Jahr) zu Vergleichszwecken
  • Anzahl der abgelehnten Änderungsanfragen
  • Änderungsrückstand, aufgeschlüsselt nach KE und Stadium des Change-Management-Prozesses

Wie Sie sehen, decken die empfohlenen Berichte für das Management viele Bereiche ab, konzentrieren sich dabei aber auf Messungen auf hoher Abstraktionsebene, statt auf Einzelheiten konkreter Änderungen. Es lohnt sich, diese Berichte etwas genauer zu analysieren:

Anzahl der in diesem Zeitraum implementierten Änderungen, aufgeschlüsselt nach Gesamtzahl, Konfigurationselement (KE), Konfigurationstyp, Service usw.: Diese leicht verständliche Zahl bezeichnet die Gesamtzahl der Änderungen, aufgeschlüsselt nach Kategorien. Sie ist nicht viel mehr als ein Barometer, denn sowohl die Zahl selbst als auch die Änderungskategorien hängen von Änderungen der IT und des Geschäftsbetriebes ab und verändern sich schnell. Dieser Bericht ist für Manager des Configuration-Managements (Anlagenmanagements) wichtig, da ITIL empfiehlt, dass jede Statusänderung eines Konfigurationselementes (einer Anlage) den Change-Management-Prozess durchlaufen muss. Sie müssen entscheiden, welche Kategorien für Ihr Unternehmen wichtig sind. Achten Sie jedoch darauf, nicht allzu viele Kategorien zu definieren. Eine allzu feine Aufschlüsselung stiftet lediglich Verwirrung.

  • Indikator für die IT-Geschäfts-Abstimmung: Dieser Bericht ist für die Business-Manager noch wichtiger als die übrigen Berichte des Change-Managements. Das gilt besonders, wenn Sie ihn nach Geschäftsbereichen aufschlüsseln.

Aufschlüsselung der Gründe für Änderungen (Benutzeranfragen, Verbesserungen, unternehmerische Anforderungen, Beantwortung von Service-Anrufen/Vorfalls-/Problembehebung, Verbesserung von Verfahren/Training usw.): Dieser Bericht liefert nützliche Daten auf hoher Abstraktionsebene. ITIL empfiehlt für diesen Bericht keinen bestimmten Zeitraum. Er könnte als ausführlicher Bericht über die vergangene Periode erstellt werden oder als Sammelbericht über mehrere Perioden, zum Beispiel die vergangenen zwölf Monate, so dass Trends erkennbar werden.

  • Indikator für die IT-Geschäfts-Abstimmung: Dieser Bericht sollte allen Business-Managern verfügbar gemacht werden, die an den Gründen für Änderungen interessiert sind, insbesondere wenn die Änderungen nicht vom Geschäftsbetrieb angeregt wurden.

Gesamtzahl der erfolgreichen Änderungen: Zwar definiert ITIL den Begriff „erfolgreich“ nicht, seine Bedeutung ist jedoch offensichtlich: Gemeint sind alle Änderungen, die erfolgreich implementiert wurden. Was ist jedoch mit den Änderungen, die erfolgreich, aber verspätet implementiert wurden, die zuerst zurückgezogen und dann erneut implementiert wurden oder die zu neuen Vorfällen geführt haben? Damit dieser Bericht nützlich ist, müssen Sie definieren, was Ihre Organisation unter einer „erfolgreichen“ Änderung versteht. Entsprechend könnten Sie diesen Bericht nach Kategorien erfolgreicher Änderungen aufschlüsseln. Ein Bericht, der nur eine Gesamtzahl nennt, ist für diese wichtige Komponente des Change-Managements nur von geringem Nutzen.

  • Indikator für die IT-Geschäfts-Abstimmung: Dieser Bericht ist für Business-Manager wichtig. Business-Manager haben eine völlig andere Vorstellung von einer „erfolgreichen Änderung“ als IT-Manager. Sie erhalten am Ende des Berichts oder online gerne einen kurzen Überblick über die einzelnen erfolgreichen Änderungen. Rechnen Sie damit, von Business-Managern Rückmeldungen zu einigen in diesem Bericht genannten „erfolgreichen“ Änderungen zu bekommen.

Anzahl der zurückgezogenen Änderungen und Gründe für den Rückzug (z.B. falsche Einschätzung, Softwarefehler): In der ITIL-Terminologie bedeutet „zurückgezogen“, dass eine Änderung zunächst zwar implementiert, dann aber wieder entfernt und der ursprüngliche Zustand wiederhergestellt wurde. Eine Änderung kann aus verschiedenen Gründen zurückgezogen werden, zum Beispiel wegen schlechter Leistung, einer zu großen Anzahl neuer Vorfälle, negativer Auswirkungen auf eine andere Komponente oder weil sie die, in der Änderungsanfrage definierten Anforderungen nicht erfüllt. Die Bedeutung dieses Berichtes ergibt sich aus den ITIL-Zielen für das Change-Management, die besagen, dass Änderungen den laufenden Betrieb des Unternehmens verbessern müssen. Eine zurückgezogene Änderung erfüllt diese Anforderung eindeutig nicht. Ergänzen Sie diesen Bericht durch eine Beschreibung der einzelnen zurückgezogenen Änderungen, die erklärt, warum die Änderung zurückgezogen wurde, welche Maßnahmen für die Fehlerbehebung ergriffen wurden und welche Änderungen vorgenommen wurden, damit nicht noch einmal derselbe oder ein ähnlicher Fehler auftritt.

  • Indikator für die IT-Geschäfts-Abstimmung: Dieser Bericht ist für Business-Manager wichtig. Sie benötigen eine Beschreibung jeder zurückgezogenen Änderung, die sich auf ihren Geschäftsbereich auswirkt. Viele Business-Manager ermitteln anhand dieses Berichtes die Kosten und Auswirkungen zurückgezogener Änderungen auf ihre Umgebung. Ergänzend zu diesem Bericht sollten Business-Manager sofort benachrichtigt werden, wenn der Change-Management-Prozess Änderungen findet, die zurückgezogen werden müssen.

Anzahl der auf Änderungen zurückzuführenden Vorfälle (aufgeschlüsselt nach Problemgewichtung) und Gründe (z.B. falsche Einschätzung, Softwarefehler): Dies ist eine weitere wichtige Messzahl, da sie sich direkt auf das Ziel für das Change-Management bezieht, nämlich auf die Minimierung von Vorfällen in Zusammenhang mit Änderungen. Viele, aber nicht alle Vorfälle werden durch fehlgeschlagene oder zurückgezogene Änderungen verursacht. Auch erfolgreiche Änderungen können zu Vorfällen führen. So kann es zum Beispiel vorkommen, dass eine Änderung zwar der Änderungsanfrage entspricht, somit erfolgreich ist, der Kunde aber nicht alle Aspekte der Änderung versteht und Just-in-Time-Training benötigt. In diesem Fall ist nicht die Änderung gescheitert, sondern der Änderungsprozess.

Es ist sehr wichtig, dass alle Vorfälle, die das Ergebnis von Änderungen sind, verfolgt und gemeldet werden. Dies bedeutet, dass die Vorfalls- und die Änderungssoftware eng miteinander verbunden sein müssen, damit diese Informationen schnell und leicht verfolgt werden können. Es bedeutet auch, dass die Mitarbeiter des Service-Desks darin geschult werden müssen, auf Änderungen bezogene Vorfälle zu erkennen. Darüber hinaus müssen die Mitarbeiter des Service-Desks alle Einzelheiten, zum Beispiel die Referenznummer der Änderung, genau aufzeichnen, damit der Vorgang verfolgt werden kann.

Auch dieser Bericht ist sehr wichtig. Er sollte außerdem den Grund für die einzelnen Vorfälle enthalten, damit derselbe oder ein ähnlicher Vorfall nicht noch einmal auftritt.

  • Indikator für die IT-Geschäfts-Abstimmung: Meist sind die Business-Manager bereits mit diesen Vorfällen vertraut, da entweder sie selbst oder ihre Mitarbeiter die Vorfälle ausgelöst haben. Über diesen Bericht hinaus müssen die Business-Manager jederzeit und möglichst online alle Vorfälle einsehen können, die mit Änderungen in Verbindung gebracht wurden.

Anzahl der Änderungsanfragen (und Trends in der Veranlassung): Die Anzahl der Änderungsanfragen ist ein leicht verständlicher Wert. Schwierig sind hingegen die „Trends in der Veranlassung“. Die Anzahl der Änderungsanfragen ist nicht immer gleich der Anzahl der vorgenommenen Änderungen. Einige Änderungsanfragen werden abgelehnt, und zu jeder Änderung können mehrere Änderungsanfragen vorliegen. Dies bedeutet, dass die Anzahl der Änderungsanfragen immer mindestens so groß ist wie die Anzahl der vorgenommenen Änderungen. Der erste Teil dieses Berichtes enthält die Anzahl der Änderungsanfragen. Es ist sinnvoll, die Gesamtzahl durch eine kurze Zusammenfassung zu ergänzen, die zwischen „abgelehnten“ und „angenommenen“ Änderungsanfragen unterscheidet.

Mit der Bereitstellung von Trends begeben wir uns in den Bereich von Wissen und Intervention. ITIL legt nicht fest, welche Trends ausgemacht werden sollen. Diese Entscheidung muss jede Organisation selbst treffen. Typische Trends sind Zunahme/Abnahme von Änderungsanfragen aus einer bestimmten Geschäftseinheit, von Änderungsanfragen zu einer bestimmten Software oder von Änderungsanfragen zu neuen Technologien. Diese Trends können Sie nur erkennen, wenn Sie Informationen erfassen und analysieren. Jeder Bericht, der anhand dieser Analyse erstellt wird, bezieht sich ausschließlich auf den Zeitraum, den er beschreibt.

  • Indikator für die IT-Geschäfts-Abstimmung: Die tatsächliche Anzahl der Änderungsanfragen ist für Business-Manager nicht interessant. Trends sind hingegen sehr wichtig.

Anzahl der implementierten und überprüften Änderungen und Umfang der noch auszuführenden Überprüfungen (aufgeschlüsselt nach Zeitverlauf): ITIL stellt fest: „Das Change-Management sollte Folgemaßnahmen ergreifen, um alle Probleme und Mängel in der Effizienz zu korrigieren, die als Ergebnis erfolgloser Änderungen aus dem Change-Management-System selbst entstehen.“ Daher müssen Sie unbedingt Berichte zu Änderungs- und Datensatzüberprüfungen sowie Rückständen erstellen. Ein umfangreicher Änderungsrückstand kann zum Beispiel ein Hinweis darauf sein, dass die Personalausstattung des Change-Managements nicht ausreicht. Eine große Anzahl erfolgloser Änderungen kann ein Hinweis darauf sein, dass die Beurteilung und Programmierung von Änderungen nicht zufriedenstellend verlaufen.

Durch die Überprüfung von Änderungsdatensätzen können Sie auch Probleme in anderen Prozessen aufdecken. Eine Überprüfung kann zum Beispiel ergeben, dass das Problem-Management die Ursache nicht richtig erkannt hat, dass Technologiekomponenten unzuverlässig sind oder dass Verfahren und/oder Training unzulänglich sind. Die Vorbereitung dieses Berichtes erfordert Zeit und eine sachkundige Analyse. Der Bericht ist für ein erfolgreiches Change-Management jedoch unverzichtbar. Eine Nebenwirkung dieses Berichtes ist allerdings wahrscheinlich, dass die IT neue Änderungsanfragen erhält, die das Change-Management verbessern sollen.

  • Indikator für die IT-Geschäfts-Abstimmung: Dieser Bericht ist für Business-Manager höchst wichtig, insbesondere wenn deren Verfahren oder Schulungsmaßnahmen scheitern. Wenn Sie diesen Bericht für die Business-Manager vorbereiten, sollten Sie darauf achten, dass er die Aufmerksamkeit auf Verbesserungsbereiche lenkt, die für den Geschäftsbetrieb von Interesse sind.

Vermehrtes Auftreten von Änderungsanfragen/Problemberichten zu einem bestimmten KE (dies verdient besondere Beachtung) sowie die Gründe hierfür (z.B. hoher Bedarf der Anwender, empfindliche Komponente, Softwarefehler): Um diese Messzahl besser zu verstehen, entfernen wir die in Klammern angegebene Information: „Vermehrtes Auftreten von Änderungsanfragen/Problemberichten zu einem bestimmten KE sowie die Gründe hierfür.“ Nun wird das Bild klarer.

Mit Hilfe der Anzahl der Änderungsanfragen und Problemberichte können Sie Schwächen von Konfigurationselementen (Anlagenkomponenten) erkennen. Dieser Bericht ist von grundlegender Bedeutung, denn je früher Sie Schwächen von KE erkennen, desto schneller können Sie sie korrigieren und damit den Kundendienst verbessern. Um diesen Bericht zu erstellen, vergleichen Sie die Problemdatenbank und die Änderungsdatenbank mit der Konfigurationsdatenbank (Anlagendatenbank). Voraussetzung dafür sind kompatible Datenbanken (oder eine integrierte Datenbank) für Probleme, Änderungen und Konfiguration sowie ein Berichtgenerator, der die erforderliche Ausgabe erzeugen kann. Dieser Vorgang nimmt zwar viel Zeit in Anspruch, sollte aber für alle IT-Manager verbindlich vorgeschrieben sein.

  • Indikator für die IT-Geschäfts-Abstimmung: Auch dieser Bericht ist für Business-Manager ein „Muss“. Sie sollten ihn den Business-Managern nicht nur zur Verfügung stellen, sondern ihn mit Business-Managern besprechen. Business-Manager können möglicherweise weitere Gründe für das häufige Auftreten bestimmter Änderungsanfragen und Problemberichte liefern.

Zahlen aus früheren Zeiträumen (letzte Periode, letztes Jahr) zu Vergleichszwecken: Diese Messung sollte kein eigenständiger Bericht sein, sondern eine wesentliche Komponente aller oben angeführten Managementberichte.

  • Indikator für die IT-Geschäfts-Abstimmung: Legen Sie gemeinsam mit den Business-Managern fest, welche Zeiträume diese Berichte abdecken sollen.

Anzahl der abgelehnten Änderungsanfragen: Dieser einfache Bericht könnte durch eine Aufschlüsselung der Gründe für die Ablehnung von Änderungsanfragen aufgewertet werden. Eine Organisation kann aus verschiedenen Gründen zu viele Änderungsanfragen hervorbringen, zum Beispiel wegen unzureichender Steuerung, Inkompetenz oder mangelnder Kenntnis des Inhalts von Änderungsanfragen. Die Kriterien für die Ablehnung von Änderungsanfragen sollten definiert und veröffentlicht werden.

  • Indikator für die IT-Geschäfts-Abstimmung: Dieser Bericht sollte den Business-Managern zusammen mit einer Aufschlüsselung der abgelehnten Änderungsanfragen zur Verfügung gestellt werden. Da die meisten abgelehnten Änderungsanfragen wahrscheinlich aus dem Geschäftsbetrieb stammen, kann dieser Bericht den Business-Managern dabei helfen, ihre Verfahren und Prozesse zu verbessern und damit die Anzahl der unnötigen Änderungsanfragen zu reduzieren.

Anteil der implementierten, aber nicht erfolgreichen Änderungen (Gesamtzahl und aufgeschlüsselt nach KE): Für zurückgezogene Änderungen wurde bereits ein ähnlicher Bericht beschrieben, und die dort genannten Prinzipien können auch hier angewandt werden. Allerdings besteht ein wesentlicher Unterschied: Nicht alle fehlgeschlagenen Änderungen werden zurückgezogen. Manchmal ist es zu schwierig, Änderungen zurückzuziehen, so dass stattdessen Workarounds eingerichtet werden. Wesen und Struktur der Berichte stimmen dennoch bei beiden Berichten überein.

  • Indikator für die IT-Geschäfts-Abstimmung: Dieser Bericht sollte den Business-Managern zur Verfügung gestellt werden. (Siehe den Abschnitt „zurückgezogene Berichte“ weiter oben.)

Änderungsrückstand, aufgeschlüsselt nach KE und Stadium des Change-Management-Prozesses: Ein ähnlicher Bericht über Rückstände wurde weiter oben bereits beschrieben. Dieser enthielt jedoch lediglich Gesamtzahlen, während jetzt die Rückstände aufgeschlüsselt werden. Eventuell müssen Sie die Kategorien an Ihr Unternehmen anpassen. Denken Sie daran, dass dieser Bericht in erster Linie die Engpässe finden und beseitigen soll, die zu Rückständen führen. Da die Abarbeitung von Rückständen wichtig ist, sollten alle IT-Manager diesen Bericht erhalten.

  • Indikator für die IT-Geschäfts-Abstimmung: Auch dieser Bericht ist ein „Muss“ für Business-Manager, die wissen müssen, welche Rückstände für Verzögerungen ihrer Änderungen verantwortlich sind. Darüber hinaus sollten Sie die Business-Manager sofort benachrichtigen, wenn die von ihnen angeforderten Änderungen nicht termingerecht abgeschlossen werden.

Diese Managementberichte decken eine große Palette von Fragen des Change-Managements ab. Sie sind von zentraler Bedeutung, da eine mangelhafte Verwaltung von IT-Änderungen unweigerlich zum Chaos führt. Am Anfang dieses Abschnittes wurde erwähnt, dass ITIL auf die BSI-Publikation „A Code of Practice for IT Service Management“ (PD0005) verweist. Diese empfiehlt die folgenden Berichte:

  • Anzahl der Änderungsanfragen
  • Anzahl und Prozentsatz der abgelehnten Änderungen
  • Eil-Änderungen
  • Status „Wird geändert“
  • Anzahl der Änderungen, die auf ihre Implementierung warten, aufgeschlüsselt nach:
    • Kategorie
    • verbleibende Zeit
  • Anzahl der implementierten Änderungen, aufgeschlüsselt nach:
    • Konfigurationskomponente
    • Service
  • Änderungsrückstände und -engpässe
  • Kosten je Änderung und Kostenzusammenstellungen
  • Unternehmerische Auswirkungen von Änderungen
  • Änderungen nach Geschäftsbereichen
  • Häufigkeit der Änderung an KE

Die meisten dieser Elemente wurden in den oben beschriebenen Managementberichten bereits abgedeckt. Die wichtigsten Ausnahmen sind:

  • Eil-Änderungen
  • Kosten je Änderung und Kostenzusammenstellungen
  • Unternehmerische Auswirkungen von Änderungen

Diese Ausnahmen werden im Folgenden besprochen:

Eil-Änderungen: Wenn viele Eil-Änderungen vorgenommen werden müssen, ist dies ein eindeutiger Hinweis darauf, dass der Change-Management-Prozess nicht optimal arbeitet oder von einigen Support-Gruppen umgangen wird. Eil-Änderungen sollten nur in Ausnahmesituationen durchgeführt werden, zum Beispiel wenn das System eines Kunden nur wieder in Gang gesetzt werden kann, indem die Problemursache durch eine Änderung beseitigt wird. Eil-Änderungen sollten nicht auf Grund von Inkompetenz initiiert werden, zum Beispiel wenn ein Änderungsarchitekt eine bereits vor einiger Zeit beantragte Änderung schlichtweg vergessen hat. Dieser Bericht sollte eine generische Gesamtzahl von Eil-Änderungen nennen, die in Kategorien wie zum Beispiel Anzahl je Support-Gruppe, Anzahl je Geschäftseinheit und/oder Anzahl je KE aufgegliedert wird. Auch der Grund für die Eiländerung sollte in den Bericht aufgenommen werden.

  • Indikator für die IT-Geschäfts-Abstimmung: Da sich Eil-Änderungen direkt auf die Geschäftseinheiten auswirken, sollte dieser Bericht an alle Business-Manager weitergeleitet werden. Falls die Geschäftseinheiten zu viele Eil-Änderungen beantragen, setzen Sie eine Besprechung an, in der Sie erörtern, wie Eil-Änderungen besser geplant werden können.

Kosten je Änderung und Kostenzusammenstellungen: Finanzielle Aufschlüsselungen hängen vom Typ und der Natur der Organisation ab. Unternehmen, in denen Ausgleichsbuchungen vorgenommen werden, benötigen wesentlich detailliertere Informationen als Unternehmen ohne Ausgleichsbuchungen. Unabhängig davon sollte jedoch jedes Unternehmen wissen, welche Kosten mit seinen Änderungen verbunden sind, und es sollte diese Kosten veröffentlichen. Dieser Bericht sollte an alle IT-Manager verteilt werden. Der Änderungsdatensatz für Änderungen, die gerade bearbeitet werden, sollte die laufenden Gesamtkosten enthalten, so dass die bisherigen Kosten der einzelnen Änderungen ersichtlich sind.

  • Indikator für die IT-Geschäfts-Abstimmung: Business-Manager müssen die Kosten aller Änderungen kennen, die sie beantragt haben oder die sich auf ihren Geschäftsbereich auswirken. Auch hier gilt wieder, dass Ausgleichsbuchungen den Inhalt der Berichte beeinflussen. Diese Berichte sollten an alle Business-Manager verteilt werden, damit sie die Kosten der Änderungen erkennen können, die sie angeregt haben oder die sich auf ihren Geschäftsbereich auswirken.

Unternehmerische Auswirkungen von Änderungen: Viele Änderungen haben sehr spezielle Auswirkungen, die von der Natur und der Dringlichkeit der Änderung abhängen. Die Informationen zu den Auswirkungen werden zwar nicht in einem Bericht zusammengefasst, sollten jedoch zur Verfügung gestellt werden, sobald für einen beliebigen Änderungstyp im Change-Management-Prozess ein neuer Änderungsdatensatz angelegt wird.

  • Indikator für die IT-Geschäfts-Abstimmung: Dieser Bericht ist für Business-Manager wichtiger, als es zunächst scheinen mag. Die unternehmerischen Auswirkungen oder die Dringlichkeit können sich während des Lebenszyklus einer Änderung aus verschiedenen Gründen ändern. Daher ist es wichtig, dass Business-Manager die unternehmerischen Auswirkungen aller Änderungen prüfen.

Wie bereits erwähnt, kann das Change-Management sehr umfangreiche Messungen und Überwachungen erfordern. Ein weiteres ITIL-Ziel für das Change-Management ist folgendermaßen definiert:

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

Kernpunkte dieses Zieles sind die „große Sichtbarkeit und die offenen Kommunikationskanäle.“ Diese Begriffe verdeutlichen, warum diese Berichte so wichtig sind und warum die Abstimmung auf den Geschäftsbetrieb hohe Priorität haben sollte. Das Change-Management ist der Grundstein für die erfolgreiche Einbindung der IT in den Geschäftsbetrieb. Daher sind alle oben beschriebenen Berichte von grundlegender Bedeutung.

> > Kapitel 8 - Release-Management