Förderer:

Service-Support-Metriken

Release-Management

Kapitel 8

Das Release-Management ist eine zentrale Komponente von ITIL und wurde in den aktuellen Neuausgaben von ITIL-Publikationen von Grund auf überarbeitet. Früher war die Hauptaufgabe des Release-Managements die Verwaltung von Softwarefreigaben in der IT-Umgebung. Mittlerweile geht das Release-Management jedoch weit über diesen Bereich hinaus, wie das folgende Zitat aus dem Kapitel des Service-Support-Buches über das Release-Management belegt:

„An der Freigabe von Hardware und Software in einer verteilten Umgebung können zahlreiche Service-Provider und -Lieferanten beteiligt sein. Die sorgfältige Planung und Verwaltung der Ressourcen ist ausschlaggebend dafür, dass Freigabeversionen erfolgreich zusammengestellt und an die Kunden ausgeliefert werden. Das Release-Management betrachtet Änderungen an IT-Services aus ganzheitlicher Sicht und sollte gewährleisten, dass alle technischen und nichttechnischen Aspekte der Freigabe als einheitliches Ganzes behandelt werden. (9.1. Ziel für das Release-Management)

Mit dem Begriff „Version“ wird eine Sammlung genehmigter Änderungen an einem IT-Service bezeichnet. Jede Version wird von den Änderungsanfragen definiert, die sie implementiert. Sie besteht normalerweise aus einer Reihe von Problembehebungen und Verbesserungen des Services. Sie umfasst die erforderliche neue oder überarbeitete Software sowie alle neue oder überarbeitete Hardware, die für die Implementierung der genehmigten Änderungen erforderlich ist. (9.3.1. Version)

Das Release-Management ist mittlerweile eine der Hauptkomponenten von ITIL. Ebenso wie andere ITIL-Prozesse wird auch das Release-Management anhand von zwei Arten von Messzahlen bewertet: der Überwachung der KPI (Key Performance Indicators, Hauptleistungsindikatoren) und der Managementberichte. Zunächst sehen wir uns genauer an, wie ITIL die KPI beschreibt:

Sehr wenige fehlgeschlagene Erstellungen
Sichere und exakte Verwaltung der DSL (Definitive Software Library)
Kein Hinweis auf Software in der DSL, die Qualitätsprüfungen nicht bestanden hat, oder auf Überarbeitungen einer Software, die aus der DSL entnommen wurde
Größenbemessung der DSL gemäß dem tatsächlichen Platzbedarf sowie rechtzeitige und sorgfältige Säuberung der DSL
Einhaltung aller gesetzlichen Bestimmungen für die Verwendung gekaufter Software Fehlerlose Verteilung der Versionen an alle Remote-Standorte
Rechtzeitige Implementierung der Versionen an allen Standorten einschließlich der Remote-Standorte
An keinem Standort Hinweise auf eine nicht genehmigte Wiederherstellung früherer Versionen
An keinem Standort Hinweise auf die Verwendung nicht genehmigter Software
Kein Hinweis auf die Zahlung von Lizenzgebühren oder auf Wartungsarbeiten für Software, die am jeweiligen Standort nicht eingesetzt wird
Kein Hinweis auf unnötige Kopiervorgänge bei der Versionserstellung (z.B. mehrere Ausgaben von Remote-Sites, wenn eine einzige Ausgabe genügt)
Präzise und zeitnahe Aufzeichnung aller Erstellungs-, Verteilungs- und Implementierungsaktivitäten in der CMDB (Configuration Management Database)
Analyse aller Freigabeaktivitäten und aller notwenigen Korrektur- und Folgemaßnahmen sowie Prozessverbesserungen
Die geplante Zusammenstellung von Versionen entspricht der tatsächlichen Zusammenstellung (belegt gute Versionsplanung)
Alle für das Release-Management erforderlichen IT- und Personalressourcen unterliegen einer guten laufenden Vorausplanung

Wie zu erwarten war, gleichen dieser KPI-Messdaten denjenigen für das Change-Managements. Dies ist unvermeidlich, da Release- und Change-Management eng miteinander verbunden sind. Es gibt jedoch einige wesentliche Unterschiede.

Termin- und budgetgerecht erstellte und implementierte Versionen (wobei jedoch alle Probleme sorgfältig ermittelt werden sollten, die nicht der Kontrolle oder Verantwortung des Release-Managements unterliegen, zum Beispiel Verzögerungen bei der Anwendungsentwicklung): Um diesen KPI zu verstehen, müssen wir diese Aussage erweitern: „Anzahl der innerhalb des letzten Kalendermonats ohne Überschreitung der geplanten Ressourcen erstellten und implementierten Versionen.“

Die ursprüngliche Aussage nennt für diesen KPI keinen bestimmten Zeitraum. Ein Kalendermonat ist lediglich ein Beispiel, das verdeutlichen soll, dass Sie genau angeben müssen, über welchen Zeitraum eine Messung erfolgt. Ebenso benötigen Sie eine klare Definition von „nicht der Kontrolle oder Verantwortung des Release-Managements unterliegen“, um Missverständnisse und Ungenauigkeiten zu vermeiden.

Letztlich bietet dieser KPI eine kurze Prüfliste für die erfolgreichen Versionsfreigaben eines bestimmten Zeitraumes. Obwohl dieser KPI also wichtig ist, sollte der Bericht für jede erfolgreiche Freigabe nur eine einzige Zeile enthalten. Normalerweise enthält er das geplante und das tatsächliche Datum sowie die geplante sowie die tatsächliche Uhrzeit der Versionsfreigabe, die Referenznummer, den Versionseigentümer und Kommentare zu nicht der Kontrolle des Release-Managements unterliegenden Problemen. Um diesen Bericht optimal zu nutzen, vergleichen Sie ihn mit dem folgenden Bericht über gescheiterte Freigaben. Bei diesem KPI wird eine möglichst hohe Erfolgsquote angestrebt.

Indikator für die IT-Geschäfts-Abstimmung: Diesen Bericht benötigen viele Business-Manager, insbesondere diejenigen, die während des Berichtszeitraumes Freigabeversionen erhalten haben. Bereiten Sie sich darauf vor, mit den Business-Managern Probleme zu besprechen, die durch neue Versionen verursacht werden und als „nicht der Kontrolle oder Verantwortung des Release-Managements unterliegend“ eingestuft wurden. Rechnen Sie auch damit, dass nicht jeder eine bestimmte Freigabe für erfolgreich halten wird.

Sehr wenige (im Idealfall keine) Freigaben, die wegen inakzeptabler Fehler zurückgezogen werden müssen (Softwareversionen müssen jedoch nicht vollkommen fehlerfrei sein; die Entscheidung, eine Version trotz bekannter Fehler freizugeben, ist zulässig, sofern die Fehler geringfügig sind und den erlaubten Toleranzbereich nicht überschreiten): Wie bereits erwähnt, besteht eine Beziehung zwischen diesem und dem vorhergehenden KPI. Je niedriger dieser und je höher der vorhergehende KPI ist, desto besser ist die Gesamtleistung. Versuchen Sie zwischen bekannten Fehlern (deren Ursache Sie erkannt und für die Sie einen Workaround eingerichtet haben) und Fehlern, die unerwartete Vorfälle auslösen (seien diese auch noch so geringfügig), zu unterscheiden. Fehler, die unerwartete Vorfälle auslösen, sollten den Problem-Management-Prozess durchlaufen. Analysieren Sie alle Fehlschläge, die durch inakzeptable Fehler hervorgerufen wurden, und erstellen Sie für jeden einen Bericht, der beschreibt, welche Maßnahmen ergriffen wurden, um zu gewährleisten, dass dieser Fehler bei künftigen Freigaben nicht mehr auftritt.

Indikator für die IT-Geschäfts-Abstimmung: Wahrscheinlich wurde der Status aller fehlgeschlagenen Freigaben bereits vor der Veröffentlichung dieses KPI bekannt und besprochen. Dennoch ist dies ein wichtiger Bericht für die Business-Manager. Diese können zudem weitere Einzelheiten zu den unternehmerischen Auswirkungen unerwarteter Fehler liefern.

Betrachten Sie diesen Bericht unbedingt als eine Grundlage für eine bessere Zukunft und nicht als eine Möglichkeit, jemandem die Schuld zuzuweisen.

Sehr wenige fehlgeschlagene Erstellungen: Bevor Sie diesen KPI messen, müssen Sie einen Zielwert für „wenige“ definieren. Keine? Höchstens eine von Hundert? Der ideale Zielwert für diesen KPI ist null. Unabhängig davon, welchen KPI Sie definieren, müssen Sie auf jeden Fall alle fehlgeschlagenen Versionserstellungen untersuchen. Die meisten Kriterien, die für den vorhergehenden KPI unter dem Stichwort „unerwartete Fehler“ beschrieben wurden, gelten auch hier.

Indikator für die IT-Geschäfts-Abstimmung: Hier gilt dasselbe wie beim vorherigen KPI.

Sichere und exakte Verwaltung der DSL (Definitive Software Library): Dieser KPI unterscheidet sich grundlegend von den bisher besprochenen. Er kann nicht allein aus Grunddaten gewonnen werden, sondern erfordert Untersuchungen, Überprüfungen und die Begutachtung der DSL. Die exakte Verwaltung der DSL können Sie nur gewährleisten, indem Sie die Versionen der in der DSL enthaltenen Software begutachten, prüfen und mit der auf Geräten in der Infrastruktur installierten Software vergleichen.

Die Überprüfung der Sicherheit ist keine leichte Aufgabe. Dennoch sollte kein Zugriff auf die DSL ohne Passwort erfolgen. Aus diesem Grund ist es sinnvoll, mit einer Überprüfung des Passwortverkehrs zu beginnen. Eine Sicherheitsüberprüfung sollte nicht von einem IT-Analysten, sondern von einem unabhängigen Sicherheitsanalysten vorgenommen werden. Diese Überprüfung wird im Allgemeinen auf Anfrage des IT-Managements in regelmäßigen Abständen durchgeführt. Falls hinsichtlich der Sicherheit Probleme oder Unregelmäßigkeiten festgestellt werden, müssen sofort Maßnahmen ergriffen werden, um diese Schwachpunkte des Release-Managements zu beheben und ihr erneutes Auftreten zu verhindern.

Indikator für die IT-Geschäfts-Abstimmung: Es kommt ganz darauf an, ob und wie der Geschäftsbetrieb an der DSL mitwirkt. Falls Business-Manager Software in der DSL besitzen, müssen sie vollständig in diese Überprüfungen einbezogen werden. Sprechen Sie unbedingt mit den Business-Managern, wenn die Überprüfung der Softwareversionsnummern einen Besuch im Zuständigkeitsbereich dieser Manager erforderlich macht.

Kein Hinweis auf Software in der DSL, die Qualitätsprüfungen nicht bestanden hat, oder auf Überarbeitungen einer Software, die aus der DSL entnommen wurde: Auch die Messung dieses KPI kann nicht allein anhand von Grunddaten erfolgen. Sie erfordert Untersuchungen, Überprüfungen und Begutachtungen der DSL. Sie können die Qualität und Integrität nur nachweisen, indem Sie die Versionen der in der DSL enthaltenen Software mit der auf Geräten in der Infrastruktur installierten Software vergleichen. Die Begutachtung sollte nicht von einem für die DSL verantwortlichen Mitarbeiter vorgenommen werden, sondern von einem unabhängigen Analysten.

Diese Überprüfung wird auf Anfrage des IT-Managements in regelmäßigen Abständen durchgeführt. Falls hinsichtlich der Qualität oder Integrität Probleme festgestellt werden, müssen sofort Maßnahmen ergriffen werden, um diese Schwachpunkte des Release-Managements zu beheben und ihr erneutes Auftreten zu verhindern.

Indikator für die IT-Geschäfts-Abstimmung: Es kommt ganz darauf an, ob und wie der Geschäftsbetrieb an der DSL mitwirkt. Falls Business-Manager Software in der DSL besitzen, müssen sie vollständig in diese Überprüfungen einbezogen werden. Sprechen Sie unbedingt mit den Business-Managern, wenn die Überprüfung der Softwareversionsnummern einen Besuch im Zuständigkeitsbereich dieser Manager erforderlich macht.

Größenbemessung der DSL gemäß dem tatsächlichen Platzbedarf sowie rechtzeitige und sorgfältige Säuberung der DSL: Für diesen wichtigen KPI sind Informationen aus dem ITIL-Prozess „Kapazitätsmanagement“ sowie die Unterstützung durch diesen Prozess erforderlich. Messen Sie den Platzbedarf in der DSL, indem Sie die Größe der aktuellen Datenbank, den für die Aktualisierung der derzeitigen Software erforderlichen Platz und den für geplante neue Software erforderlichen Platz addieren. Vergleichen Sie das Ergebnis dieser Berechnung mit dem tatsächlich für die DSL vorhandenen Platz. Falls voraussichtlich nicht ausreichend Platz für die neue Software vorhanden sein wird, müssen Sie entweder in der DSL mehr Platz schaffen oder alte bzw. redundante Software aus der DSL löschen. Falls Sie die Software wegen Platzmangels nicht hinzufügen können, erfüllen Sie die Bedingungen dieses KPI nicht.

Die rechtzeitige und sorgfältige Säuberung der DSL sollte eine regelmäßige Aktivität sein, und alle diesbezüglichen Aktivitäten sollten in einem Transaktionsprotokoll aufgezeichnet werden. Bei diesem KPI müssen sowohl die DSL als auch die Transaktionsprotokolle überprüft werden. Hinweise auf fehlende Säuberungsaktionen oder Ungenauigkeiten bedeuten, dass Sie die Bedingungen dieses KPI nicht erfüllen. Falls hinsichtlich der Zeitplanung oder Sorgfalt Probleme festgestellt werden, müssen sofort Maßnahmen ergriffen werden, um diese Schwachpunkte des Release-Managements zu beheben und ihr erneutes Auftreten zu verhindern.

Indikator für die IT-Geschäfts-Abstimmung: Es kommt ganz darauf an, ob und wie der Geschäftsbetrieb an der DSL mitwirkt. Falls Business-Manager Software in der DSL besitzen, müssen sie vollständig in diese Überprüfungen einbezogen werden. Sprechen Sie unbedingt mit den Business-Managern, wenn die Überprüfung der Softwareversionsnummern einen Besuch im Zuständigkeitsbereich dieser Manager erforderlich macht.

Einhaltung aller rechtlichen Vorgaben für die Verwendung gekaufter Software: Dieser KPI ist sehr wichtig. Falls seine Bedingung nicht erfüllt wird, drohen dem Unternehmen rechtliche Konsequenzen. In der Regel bezieht sich dieser KPI auf Lizenzbeschränkungen, die Softwareerneuerung und die Laufzeit von Softwarelizenzen.

Erstellen Sie eine Liste aller Softwareverträge und implementieren Sie Prüfungen und Einschränkungen, damit auf jeden Fall alle rechtlichen Vorgaben eingehalten werden. Sorgfalt ist besonders dann geboten, wenn Sie vorhandener Software neue Anwender hinzufügen oder vorhandene Software aktualisieren.

Indikator für die IT-Geschäfts-Abstimmung: Stellen Sie sicher, dass die Business-Manager wissen, welche gesetzlichen Bestimmungen nicht eingehalten werden — besonders, wenn die Business-Manager selbst (vorsätzlich oder aus Versehen) geben die Bestimmungen verstoßen. Ein Beispiel: Ein Business-Manager vereinbart die Bezahlung von zehn Einzelplatzlizenzen für eine bestimmte Software, die jedoch regelmäßig von mehr als zehn Personen gleichzeitig verwendet wird. In diesem Fall sollten Sie den betreffenden Manager darauf hinweisen, dass die Software widerrechtlich genutzt wird. Dabei können Sie auch Nicht-IT-Abteilungen einbeziehen, zum Beispiel die Rechtsabteilung oder den Einkauf.

Fehlerlose Verteilung der Versionen an alle Remote-Standorte: Dieser KPI kann durch Prüfungen gemessen werden. Meist werden jedoch die Vorfalls- und die Problemdatenbank regelmäßig auf Hinweise auf eine fehlerhafte Softwaredistribution überprüft. Sehen Sie sich in diesem Zusammenhang auch die Änderungsanfragen im Change-Management an. Eventuell liegen Änderungsanfragen vor, die auf einer fehlerhaften Softwaredistribution beruhen. Ein Anwender könnte zum Beispiel nach Aktualisierungen oder Funktionen fragen, die bereits installiert sein sollten. Falls Sie Hinweise auf eine fehlerhafte Versionsdistribution finden, erfüllen Sie die Anforderungen dieses KPI nicht.

Indikator für die IT-Geschäfts-Abstimmung: Manchmal wissen Business-Manager nicht, welche Softwareversionen in ihrer Abteilung installiert sein sollten. Achten Sie darauf, dass alle Manager im Rahmen des Freigabeprozesses für Software genaue Informationen erhalten.

Rechtzeitige Implementierung der Versionen an allen Standorten einschließlich der Remote-Standorte: Dieser KPI ist einfach zu überwachen, da die Versionen entweder rechtzeitig oder zu spät freigegeben werden. Verspätet freigegebene Versionen sind ein Beleg dafür, dass die Anforderungen dieses KPI nicht erfüllt werden. Allerdings sollten Sie die Gründe für die Verzögerung herausfinden und Maßnahmen ergreifen, damit künftige Versionen nicht aus denselben Gründen verspätet freigegeben werden. Erstellen Sie regelmäßig, zum Beispiel einmal im Monat, Berichte über verspätete Freigaben, die Sie allen IT-Managern zur Prüfung und Kommentierung vorlegen.

Indikator für die IT-Geschäfts-Abstimmung: Die Business-Manager benötigen diesen Bericht über verspätet freigegebene Versionen ebenfalls. Wahrscheinlich weisen die Manager Sie auf Verzögerungen bei der Versionsfreigabe hin. Halten Sie sie also ebenfalls über den Fortschritt aller Versionen auf dem Laufenden.

An keinem Standort Hinweise auf eine nicht genehmigte Wiederherstellung früherer Versionen: Für diesen KPI sind Begutachtungen und Überprüfungen erforderlich. Eventuell können Sie wiederhergestellte frühere Versionen mit einem Suchprogramm finden. Auch eine Überprüfung der Vorfalls- und der Problemdatenbank kann Hinweise ergeben. Überprüfen Sie die Änderungsanfragen im Change-Management daraufhin, ob Änderungen wegen wiederhergestellter alter Softwareversionen beantragt wurden. Ein Anwender könnte zum Beispiel nach Aktualisierungen oder Funktionen fragen, die bereits installiert sein sollten. Jeder Hinweis auf eine nicht genehmigte Wiederherstellung bedeutet, dass Sie die Anforderungen dieses KPI nicht erfüllen.

Indikator für die IT-Geschäfts-Abstimmung: Sprechen Sie mit den zuständigen Business-Managern über Probleme, die in ihrem Verantwortungsbereich aufgetreten sind. Es kann auch notwendig sein, der Sicherheitsabteilung Wiederherstellungen früherer Versionen zu melden.

An keinem Standort Hinweise auf die Verwendung nicht genehmigter Software: Dieser KPI erfordert ebenfalls Begutachtungen und Überprüfungen. Definieren Sie zunächst genau, was „nicht genehmigte Software“ ist und welche Strafen die Verwendung oder Implementierung derartiger Software nach sich zieht. Sorgen Sie anschließend dafür, dass alle IT- und Business-Manager die Definition von „nicht genehmigter Software“ und die Strafen genau verstehen. Eventuell finden Sie nicht genehmigte Software mit Hilfe eines Suchprogramms oder durch die Überprüfung der Vorfalls- und der Problemdatenbank. Falls Sie Hinweise auf eine nicht genehmigte Software finden, erfüllen Sie die Anforderungen dieses KPI nicht.

Indikator für die IT-Geschäfts-Abstimmung: Sprechen Sie unbedingt mit den zuständigen Business-Managern, falls Sie in deren Verantwortungsbereich nicht genehmigte Software finden. Nicht genehmigte Software kann zu schwerwiegenden Problemen bei der Installation neuer Versionen anderer Software führen. Noch wichtiger ist jedoch, dass nicht genehmigte Software Viren und anderem Softwaremissbrauch Tür und Tor öffnet. Daher kann es notwendig sein, die Sicherheitsabteilung oder Wirtschaftsprüfer über die Verwendung nicht genehmigter Software zu informieren.

Kein Hinweis auf die Zahlung von Lizenzgebühren oder auf Wartungsarbeiten für Software, die am jeweiligen Standort nicht eingesetzt wird: Dieser KPI könnte als „gute Hauswirtschaft“ bezeichnet werden. Planen Sie regelmäßige Begutachtungen, damit Sie wissen, welche Software wo eingesetzt wird. Wichtig ist dabei nicht, ob eine Software verwendet wird, sondern wie viele Lizenzen für diese Software benötigt werden.

Ein Beispiel: Eine Abteilung mit 40 Mitarbeitern verfügt über Lizenzen einer Software für alle 40 Workstations. Wegen abteilungsinterner Änderungen wird die lizenzierte Software tatsächlich jedoch nur auf zehn Workstations eingesetzt.

Sie können die Kosten für Lizenzen und Wartung senken, indem Sie die Anzahl der Lizenzen reduzieren und die Software von den Workstations entfernen, auf denen sie nicht mehr verwendet wird.

Eventuell finden Sie nicht mehr verwendete Software mit Hilfe eines Programms für die Ermittlung der Softwareauslastung oder durch die Überprüfung der Vorfalls- und der Problemdatenbank. Dieser KPI unterscheidet sich etwas von den übrigen, da sich, wie das obige Beispiel zeigt, die Bedingungen ändern können.

Indikator für die IT-Geschäfts-Abstimmung: Mit Hilfe bestimmter Technologien können Sie die Softwareauslastung (oder -nichtauslastung) ermitteln, die Reduzierung der Softwarelizenzen muss jedoch von den Business-Managern genehmigt werden. Aus diesem Grund sollten Sie immer mit den zuständigen Managern sprechen, bevor Sie die Anzahl der Lizenzen senken. Bitten Sie die Business-Manager auch, einmal im Jahr die von ihren Mitarbeitern verwendeten Softwarelizenzen zu überprüfen und festzustellen, welche Lizenzen tatsächlich noch gebraucht werden.

Kein Hinweis auf unnötige Kopiervorgänge bei der Versionserstellung (z.B. mehrere Ausgaben von Remote-Sites, wenn eine einzige Ausgabe genügt): Die Messung dieses KPI ist etwas schwieriger, weil die IT-Mitarbeiter, die an einer Version arbeiten, unnötige Kopien selbst feststellen und melden müssen. Manchmal fallen überflüssige Kopien erst auf, wenn die Version freigegeben wird. Ermutigen Sie Ihre Mitarbeiter, jeden Kopiervorgang zu melden, damit künftige Versionsfreigaben effizienter abgewickelt werden können. Ein Hinweis auf unnötige Kopien kann auch vorliegen, wenn eine Freigabe länger dauert oder höhere Implementierungskosten verursacht als geplant.

Regelmäßige Begutachtungen und Überprüfungen sind hier nicht erforderlich. Das Auffinden unnötiger Kopien sollte jedoch Bestandteil der Auswertung sein, die nach Abschluss des Freigabeprozesses durchgeführt wird. Wenn Sie unnötige Kopien finden, sollten Sie Maßnahmen ergreifen, um den Release-Management-Prozess zu verbessern und das erneute Auftreten desselben Fehlers zu vermeiden. Jede unnötige Kopie bedeutet, dass die Bedingungen dieses KPI nicht erfüllt wurden.

Indikator für die IT-Geschäfts-Abstimmung: Je mehr die Endanwender in den Freigabeprozess einbezogen werden, desto wahrscheinlicher ist es, dass sie unnötige Kopien bemerken. Die Endanwender und Business-Manager können dazu beitragen, dass unnötige Kopien gefunden und gemeldet werden. Die Endanwender und Business-Manager könnten zum Beispiel feststellen, dass sie mehrmals zur Ausführung derselben Aktion aufgefordert werden. Informieren Sie die Business-Manager auf jeden Fall über jede Kopie, die während der Versionserstellung angefertigt wird.

Präzise und zeitnahe Aufzeichnung aller Erstellungs-, Verteilungs- und Implementierungsaktivitäten in der CMDB (Configuration Management Database): Damit Sie diesen KPI messen können, müssen Sie zunächst die Begriffe „präzise“ und „zeitnah“ definieren. Anschließend finden Sie die Fälle, die diese Bedingungen nicht erfüllen. Hinsichtlich der „Präzision“ ist das Configuration-Management für die Überprüfung der CMDB verantwortlich und sollte alle Ungenauigkeiten melden, die auf Fehler des Release-Managements zurückzuführen sind. Die Messung der „Zeitnähe“ ist etwas schwieriger. Zeitnähe bedeutet die Zeit, die zwischen der Änderung von CMDBElementen durch eine Version und der Aktualisierung dieser Elemente vergeht. Fälle, in denen die Bedingung „Zeitnähe“ nicht eingehalten wird, finden Sie mittels einer Überprüfung der CMDB. Auch die Überprüfung der Problemund der Vorfallsdatenbank sowie das Service-Desk können Hinweise liefern. Ein Beispiel: Das Service-Desk bearbeitet einen Vorfall, aber die CMDB spiegelt nicht die tatsächliche Konfiguration am Standort des Kunden wider, da das Release-Management die CMDB nicht zeitnah aktualisiert hat.

ITIL bezeichnet eine genaue CMDB als eine wesentliche Komponente des IT-Service-Managements. Wenn Sie die Anforderungen dieses KPI nicht erfüllen, müssen Sie sofort Maßnahmen ergreifen, damit die CMDB immer die richtigen Daten enthält.

Indikator für die IT-Geschäfts-Abstimmung: Informieren Sie die Business-Manager über Ungenauigkeiten in der CMDB. Insbesondere müssen Sie diejenigen Manager informieren, die die CMDB nutzen, also zum Beispiel Manager der Abteilung Finanzierung, Vertragsverwaltung und Einkauf. Außerdem kann es notwendig sein, auch Business-Manager, die die CMDB nicht nutzen, über Ungenauigkeiten zu informieren, denn auch diese Manager sind betroffen, wenn sich die ungenauen oder veralteten CMDBDaten (zum Beispiel Zuweisung falscher Prioritäten) negativ auf den Service auswirken. Sprechen Sie mit den Business-Managern, um herauszufinden, wer Feedback zu Ungenauigkeiten in der CMDB benötigt.

Analyse aller Freigabeaktivitäten und aller notwenigen Korrektur- und Folgemaßnahmen sowie Prozessverbesserungen: Dieser KPI ist etwas unverständlich formuliert. Geht es darum, dass Analysen vorgenommen werden oder dass die Analysen keine Freigabeprobleme ans Licht bringen? Natürlich sollte bei jeder Versionsfreigabe eine Analyse durchgeführt werden. Falls dies nicht möglich ist, sollten zumindest alle Versionsfreigaben analysiert werden, bei denen Probleme aufgetreten oder die gescheitert sind. Wenn kein Analysebefund vorliegt, haben Sie die Anforderungen dieses KPI nicht erfüllt. Stellen Sie auch sicher, dass alle erforderlichen Korrektur- und Folgemaßnahmen sowie alle Prozessverbesserungen durchgeführt wurden. Wenn hierzu keine Prüfungen durchgeführt wurden, haben Sie die Bedingungen dieses KPI nicht erfüllt. Die Analysen liefern auch Daten für viele andere in diesem Abschnitt beschriebene KPI.

Indikator für die IT-Geschäfts-Abstimmung: Die Business-Manager benötigen nicht alle diese Analysebefunde. Schicken Sie ihnen nur Kopien derjenigen Analysen, die auf Probleme mit Versionen hinweisen, die im Geschäftsbereich des jeweiligen Managers installiert sind.

Die geplante Zusammenstellung von Versionen entspricht der tatsächlichen Zusammenstellung (belegt gute Versionsplanung): Im Idealfall wird so sorgfältig geplant, dass die geplante Zusammenstellung einer Version immer mit der tatsächlichen Zusammenstellung übereinstimmt. Häufig treten jedoch unerwartete Umstände ein, und gerade aus diesen lernen wir, wie wir die Planung verbessern können. Aus diesem Grund ist dieser KPI wichtig, obwohl dabei nicht von der Implementierung einer Strategie zur Verbesserung der Planung die Rede ist. Nach Abschluss einer Freigabe ermitteln Sie, ob die tatsächliche der geplanten Zusammenstellung der Freigabeversion entspricht. Diese Untersuchung kann im Rahmen der abschließenden Analyse erfolgen. Falls eine tatsächliche Zusammenstellung nicht der geplanten Zusammenstellung entspricht, sind die Anforderungen dieses KPI nicht erfüllt.

Indikator für die IT-Geschäfts-Abstimmung: Falls Ihrem Änderungsgremium (Change Advisory Board, CAB) Business-Manager angehören, sind diese sicher an diesem KPI interessiert, besonders dann, wenn Abweichungen gemeldet werden. Jeder Business-Manager, in dessen Verantwortungsbereich eine andere als die geplante Zusammenstellung installiert wurde, ist wahrscheinlich ebenfalls an diesem KPI interessiert.

Alle für das Release-Management erforderlichen IT- und Personalressourcen unterliegen einer guten laufenden Vorausplanung: Dies ist ein weiterer „Planungs“-KPI. Er soll sicherstellen, dass alle für das Release-Management erforderlichen Ressourcen verfügbar sind. Da der Zielwert „gut“ schwer zu messen ist, müssen Sie ein objektives Ziel definieren, zum Beispiel dass höchstens fünf Prozent aller Freigaben durch eine Ressourcenknappheit verzögert werden dürfen. Unabhängig davon, welche Messzahl Sie definieren, bedeutet deren Nichteinhaltung, dass die Anforderungen dieses KPI nicht erfüllt wurden. Denken Sie daran, dass eine Überschätzung bei der Planung ebenso negative Folgen haben kann wie eine Unterschätzung. Wenn Sie zum Beispiel schätzen, dass für eine Aufgabe 100 Arbeitsstunden erforderlich sind, während tatsächlich nur 25 Stunden anfallen, kann dies dazu führen, dass Ihre Anträge auf Personalzuweisung künftig abgelehnt werden. Überwachen Sie jede Version während ihres gesamten Lebenszyklus sorgfältig und informieren Sie die IT-Manager umgehend über alle in Zusammenhang mit Ressourcen auftretenden Probleme. Werten Sie die Planung nach Abschluss jeder Versionsfreigabe aus, um die geplanten mit den tatsächlich eingesetzten Ressourcen zu vergleichen. Dieser KPI ist von grundlegender Bedeutung, da die falsche Ressourcenplanung ein häufiger Grund für verspätete Freigaben ist. Jede Ressourcenknappheit muss vollständig erklärt werden. Ebenso muss erläutert werden, welche Maßnahmen ergriffen wurden, damit die Freigabeplanung künftig besser verlaufen wird.

Indikator für die IT-Geschäfts-Abstimmung: Die Business-Manager sind in der Regel dann an diesem KPI interessiert, wenn sich die Implementierung ihrer Versionen durch eine unzulängliche Ressourcenplanung verzögert. Hingegen zeigen sie wenig Interesse, wenn die Implementierung ihrer Versionen durch effiziente Planung beschleunigt wird. Rechnen Sie mit einer Fülle von Fragen, da die meisten Business-Manager mit der Ressourcenplanung bestens vertraut sind. Auch bei Projekten, die vor dem geplanten Termin fertiggestellt wurden, sollten Sie mit Skepsis rechnen. Wenn Sie lesen, dass die neue Autobahn neun Monate früher als geplant fertiggestellt wurde, ist Ihre erste Reaktion wahrscheinlich nicht „hervorragende Planung“, sondern „an der Sache ist etwas faul“. Den Business-Managern ergeht es nicht anders. Stellen Sie den Business-Managern auf jeden Fall eine Aufschlüsselung aller Abweichungen von der Ressourcenplanung zur Verfügung.

Bei der Besprechung dieser KPI kristallisieren sich zwei Grundmotive heraus: Begutachtung/Überprüfung und Analyse. Beide Aktivitäten sind unerlässlich, wenn Sie das Release-Management kontinuierlich verbessern möchten. Setzen Sie diese Instrumente jedoch behutsam ein. Falls Sie Begutachtungen und Analysen dafür verwenden, die Mitarbeiter oder ihre Handlungen zu kritisieren, werden diese Instrumente bald nichts mehr wert sein. Und noch ein Punkt, den Sie beachten sollten: „Begutachtung“ bedeutet hier die Untersuchung der Genauigkeit und Zeitnähe, keine Wirtschaftsprüfung oder gerichtliche Untersuchung. (Eine Ausnahme kann die Lizenzverwaltung sein.)

Sehen wir uns die Messzahlen für die Managementinformationen genauer an: Diese Messzahlen betreffen in erster Linie die Gesamtleistung des Release-Managements. ITIL empfiehlt für Managementinformationen die folgenden Messzahlen:

Anzahl der Haupt- und Nebenversionen je Berichtsperiode
Anzahl der Probleme in der Arbeitsumgebung, die auf neue Versionen zurückzuführen sind und nur während der ersten Monate nach Einführung einer neuen Version gemessen werden müssen, aufgeschlüsselt nach Ursache (z.B. „falsche Dateiversion“ oder „fehlende Dateien“)
Anzahl der im Rahmen der neuen Version neu eingeführten, geänderten und gelöschten Objekte, z.B. Anzahl der Module und Programme
Anzahl der innerhalb des vereinbarten Zeitrahmens abgeschlossenen Versionen; hierfür muss die zentrale Release-Management-Funktion vordefinierte Zielwerte (Service-Level oder SLA) für Softwaredistributionen und andere allgemeine Aufgaben veröffentlichen.

Nachdem es für das Release-Management ein große Zahl von KPI gibt, ist es nicht erstaunlich, dass nur wenige Messzahlen für Managementberichte erforderlich sind.

Anzahl der Haupt- und Nebenversionen je Berichtsperiode: Leider verrät uns dieser Messwert nicht viel darüber, was der Bericht enthalten soll. Die während der Periode abgeschlossenen Versionsfreigaben? Die während der Periode in Angriff genommenen Versionen? Die Versionen, die gerade erstellt werden? Oder alle diese Versionen? Im Idealfall sollten alle diese Versionen in einen periodischen Bericht aufgenommen werden. Der Bericht kann in drei Abschnitte aufgegliedert werden: abgeschlossene, begonnene und aktuelle Versionen. Jeder Abschnitt kann wiederum in zwei Unterabschnitte aufgegliedert werden: Haupt- und Nebenversionen. Verteilen Sie diesen Bericht an alle IT-Manager, da er es ihnen ermöglicht, alle Versionen zu verfolgen, an denen sie oder ihr Personal mitarbeiten.

Indikator für die IT-Geschäfts-Abstimmung: Dieser Bericht ist für alle Business-Manager wichtig, da sie damit die Versionen verfolgen können, die sich auf ihren Geschäftsbereich auswirken. Wenn Sie diesen Bericht allgemein verfügbar machen, brauchen Sie weniger Fragen von Business-Managern zu ihren Versionen zu beantworten. Rechnen Sie mit Fragen der Business-Manager, wenn sich die Freigabe ihrer Versionen verzögert.

Anzahl der Probleme in der Arbeitsumgebung, die auf neue Versionen zurückzuführen sind und nur während der ersten Monate nach Einführung einer neuen Version gemessen werden müssen, aufgeschlüsselt nach Ursache (z.B. „falsche Dateiversion“ oder „fehlende Dateien“): Diese Messzahl ist einfach verständlich und kann auf alle Vorfälle ausgeweitet werden, die von Anwendern gemeldet oder neuen Versionen zugeordnet werden. Im Idealfall bestehen weder Probleme noch Vorfälle. Tatsächlich treten jedoch selbst bei erfolgreichen Freigaben häufig Probleme oder Vorfälle auf. Die einzige Möglichkeit, sich dem Idealfall auch nur anzunähern, besteht darin, alle neuen Probleme und Vorfälle zu untersuchen und die geeigneten Maßnahmen zu ergreifen, um ein erneutes Auftreten zu verhindern. Diese Messzahl schlägt vor, die Probleme nach ihrer „Ursache“ zu klassifizieren. In ähnlicher Weise können Vorfälle nach ihrer „Kategorie“ aufgeschlüsselt werden. Zwischen allen Problemen und Vorfällen und den betreffenden Versionen sollten Querverweise hergestellt werden, zum Beispiel anhand der Referenznummer der Version. Außerdem sollten für alle Probleme und Vorfälle Korrekturmaßnahmen genannt werden, mit denen ein erneutes Auftreten in künftigen Versionen vermieden werden kann. Dieser Bericht sollte regelmäßig erzeugt und an alle IT-Manager verteilt werden.

Indikator für die IT-Geschäfts-Abstimmung: Auch dieser Bericht ist ein „Muss“ für alle Business-Manager. Diese möchten über Probleme und Vorfälle Bescheid wissen, die durch bestimmte Versionen ausgelöst wurden. Immerhin haben die Business-Manager wahrscheinlich die Auswirkungen dieser Probleme zu spüren bekommen. Darüber hinaus sind sie an den Korrekturmaßnahmen interessiert, mit denen ein erneutes Auftreten dieser Probleme und Vorfälle vermieden werden soll.

Anzahl der im Rahmen der neuen Version neu eingeführten, geänderten und gelöschten Objekte, z.B. Anzahl der Module und Programme: Diese Messzahl ist lediglich ein nach künstlichen Kategorien aufgeschlüsselter Mengenindikator. Die Anzahl der neuen, geänderten und gelöschten Objekte liefert keine nützlichen Informationen, keine Daten zu Auswirkungen oder Arbeitslast. Zusammen mit den KPI und anderen Managementinformationen liefert sie jedoch einen Hinweis auf das Arbeitsvolumen eines bestimmten Zeitraumes. Es wäre sinnvoll, diese Zahlen durch eine Liste der Objekte zu ergänzen. Dieser Bericht sollte allen IT-Managern zur Verfügung gestellt werden.

Indikator für die IT-Geschäfts-Abstimmung: Dieser Bericht ist für die meisten Business-Manager von geringem Interesse. Eine Ausnahme bilden wahrscheinlich die Manager der Abteilungen Unternehmensentwicklung, Verträge, Einkauf sowie die Angehörigen des Änderungsgremiums. Stellen Sie fest, welche Business-Manager diesen Bericht benötigen und verteilen Sie ihn entsprechend.

Anzahl der innerhalb des vereinbarten Zeitrahmens abgeschlossenen Versionen; hierfür muss die zentrale Release-Management-Funktion vordefinierte Zielwerte (Service-Level oder SLA) für Softwaredistributionen und andere allgemeine Aufgaben veröffentlichen: Auf den ersten Blick ist kaum ein Unterschied zwischen dieser Messzahl für das Management und dem ersten KPI dieses Abschnittes zu erkennen, dessen Gegenstand die „termin- und budgetgerecht erstellten und implementierten Versionen“ waren. Tatsächlich können wir aus fehlgeschlagenen Versionen wahrscheinlich mehr lernen als aus erfolgreichen. Eine eingehendere Prüfung ergibt jedoch, dass der Unterschied zwischen dieser Messzahl und dem ersten KPI in der Erwähnung von SLA besteht. Nehmen wir zum Beispiel an, dass Sie in einem SLA festlegen, dass 95 Prozent aller Freigabeversionen innerhalb des vereinbarten Zeitrahmens implementiert werden. In diesem Fall gewinnt der Bericht an Bedeutung, da er die Gesamtleistung des Release-Managements zeigt. Kurz gesagt: Setzen Sie Zielwerte für die erfolgreiche Implementierung von Versionen, legen Sie eine Berichtsperiode fest und stellen Sie diesen Bericht allen IT-Managern zur Verfügung.

Indikator für die IT-Geschäfts-Abstimmung: Falls Sie SLA-Ziele für die erfolgreiche und termingerechte Implementierung von Versionen vereinbart haben, müssen Sie diesen Bericht allen Business-Managern oder zumindest denjenigen, die die SLA unterzeichnet haben, zur Verfügung stellen.

Damit verfügen wir für das Release-Management nun über eine große Liste von KPI und Messzahlen für Managementinformationen. Möglicherweise ist es zu schwierig oder zeitaufwändig, in jeder Berichtsperiode Berichte zu allen diesen Kategorien zu erstellen. Denken Sie daran, dass ITIL eine Rahmenarchitektur ist. Wählen Sie diejenigen KPI und Messzahlen aus, die für Ihr Unternehmen am wichtigsten sind, und erstellen Sie nur die dafür relevanten Berichte.

Denken Sie immer daran, dass der Erfolg der IT von einem wirkungsvollen Change- und Release-Management abhängt. Sparen Sie also nicht bei den Messwerten und suchen Sie ständig nach neuen Möglichkeiten, das Changeund das Release-Management zu verbessern.

> > Kapitel 9 - Configuration-Management

AdvancedITIL

Service-Support-Metriken

Release-Management

Kapitel 8