Änderungen an den IT-Systemen eines Unternehmens sind das Tagesgeschäft der IT-Abteilungen und -Dienstleister. Sie müssen auf Kundenwünsche reagieren, Anwendungen für neue Geschäftsprozesse implementieren, bestehende Systeme mit denen der Geschäftspartner vernetzen, neue Technologien einbinden und natürlich auch weiterhin alltägliche Änderungen wie die Server-Aufrüstung bewerkstelligen. Darüber hinaus sind Systeme und Arbeitsprozesse der Unternehmen untereinander immer engmaschiger verknüpft, wie beispielsweise beim Supply-Chain-Management (SCM).
Technische Sicht genügt nicht
In einem solchen Netzwerk kann jede Veränderung, ob beabsichtigt oder nicht, weit reichende Auswirkungen haben und das Geschäft aller Beteiligten beeinträchtigen. Es gilt deshalb, ein systematisches Change-Management zu etablieren, das über die rein technische Sicht der IT hinausgeht und das Softwareentwickler, IT-Betreiber und Geschäftsverantwortliche gleichermaßen beteiligt. Wie ein solches Change-Management aufgebaut werden kann, zeigen anerkannte Standards für die IT-Organisation wie "IT Infrastructure Library" (ITIL). Diese dokumentiert konsistent, umfassend und herstellerunabhängig bewährte "Best Practices" im IT-Service-Management.
Als Steuerungsinstanz für alle Veränderungen der IT-Systeme benötigt das Change-Management umfassende Informationen über den aktuellen Status der IT-Systeme. So dient es in den meisten Unternehmen für eine mehr oder weniger genaue Bestandsführung der verschiedenen IT-Systeme und -Elemente. Dazu gehören Software-, Hardware- und Netzwerkkomponenten. Darüber hinaus - und das ist aus technischer Sicht zunächst ungewohnt - ist es unverzichtbar, organisatorische Aspekte in das Configuration-Management einzubeziehen. Hierzu zählen zum Beispiel Anwender, Know-how-Träger, Arbeitsprozesse, Verträge, Service-Level-Agreements, Bereitschaftsdienst oder Zuständigkeiten.
Dabei sind die einzelnen Elemente nicht nur isoliert zu betrachten, sondern auch in ihrer Beziehung untereinander. Nur dann lassen sich die Auswirkungen geplanter Changes schon im Vorfeld absehen. Auch bei Störungen kann man auf diese Weise betroffene Elemente leichter identifizieren und Fehlermuster besser erkennen.
Gesamtkonzept entscheidet
Es kommt beim Configuration-Management also nicht immer auf einen hohen Detaillierungsgrad an, sondern darauf, dass das gesamte Konzept stimmt. Konfigurationsbreite und -tiefe sollten so festlegt werden, wie es für alle gewünschten IT-Services und ein reibungsloses Change-Management notwendig ist.
So haben viele Unternehmen einen Notfallplan, in dem beschrieben ist, was im Falle eines Systemausfalls oder anderer massiver IT-Störungen zu tun ist. Diese Pläne sind aber nur in den wenigsten Organisationen auf dem neuesten Stand, weil sie meist kein Konfigurationselement sind. Ähnliches gilt für Service-Level-Agreements, die zwischen Fachabteilung und internem IT-Service-Center oder externem Service-Provider geschlossen werden. Solche Vereinbarungen müssen unter Umständen auf neue IT-Gegebenheiten ausgerichtet werden.
Beim Aufbau des Change-Managements empfiehlt es sich, Softwareentwickler, IT-Betreiber und Geschäftsverantwortliche an einen Tisch zu holen und - als Change Advisory Board (CAB) - gemeinsam über notwendige IT-Änderungen entscheiden zu lassen. Nur so können sie sicherstellen, dass kein wichtiger technischer oder geschäftskritischer Aspekt übersehen wird.
Bei jedem Change werden dann neun Schritte durchlaufen (siehe Grafik): Zunächst werden die Änderungsanträge (Request for Change: RFC) aufgenommen (1) und festgestellt, wer welche Änderungen mit welchem Ziel wünscht. Die RFCs werden hinsichtlich ihrer Nutzen, Risiken und Kosten bewertet (2) sowie in ihrer Priorität und Kategorie festgelegt (3). Dabei wird beispielsweise geklärt, ob es sich um alltägliche Änderungen handelt, die sich standardisiert durchführen lassen oder bedeutende, die - wie beispielsweise ein Release-Wechsel - ein besonderes Management erfordern. Dann werden die Changes grundsätzlich freigegeben (4), getestet (5) und geplant. Dabei muss es sowohl Pläne für den reibungslosen Change-Prozess geben als auch für mögliche Problemszenarien. Für diesen Fall müssen Fallback- und/oder Backout-Strategien entwickelt werden (6). Außerdem sollten in dieser Phase Kriterien festgehalten werden, mit deren Hilfe beurteilt wird, ob eine Änderung erfolgreich war und den erwünschten Nutzen bringt. Dann wird die Implementierung der Änderung durch den Change-Manager freigegeben (7), mit entsprechenden Statusänderungen im Configuration-Management durchgeführt (8) und - nach einer Erfolgskontrolle - abgeschlossen (9).
Aufwand reduzieren
Auch wenn sich dieses Vorgehen grundsätzlich bei jedem Change empfiehlt, ist doch offensichtlich, dass nicht für jede Routineänderung das Change Advisory Board einberufen und um Genehmigung gebeten werden kann. Um hier den Aufwand zu reduzieren, aber dennoch systematisch vorzugehen, kann man verschiedene Ände-rungskategorien definieren, für die der Change-Prozess in bestimmter Weise standardisiert wird und dadurch vorab genehmigt ist. Mit einer einfachen Rückmeldung an das CAB und das Configuration-Management ist ein solcher Routine-Change dann abgeschlossen.
Auch für ungeplante Änderungen, die bei Störungen und Ausfällen möglichst schnell dafür sorgen sollen, dass die Systeme wieder laufen, empfiehlt ITIL die gleiche Vorgehensweise: keinen Schritt auslassen (außer möglicherweise umfangreichen Tests), aber schneller arbeiten. Für einen solchen Notfall wird schon vorher eine Notfalltruppe aus Mitarbeitern gebildet. Sie bewerten dann mögliche Ursachen, notwendige Änderungen, Risiken sowie Sicherungskonzepte und entscheiden gemeinsam, was getan werden soll. So entwickeln sich im Unternehmen mit der Zeit für verschiedene Arten von Änderungen standardisierte Vorgehensweisen, die gut geplante und abgesicherte Changes gewährleisten, die von allen Beteiligten gemeinsam getragen werden und den Geschäftsprozessen des Unternehmens wirklich nützen. Eine Vorgehensweise, die für viele Unternehmen interessant sein müsste, weil beispielsweise auch in Banken, Versicherungen, Logistikunternehmen, E-Shops sowie bei Application oder Internet-Service-Providern das gesamte Business von reibungslos funktionierenden IT-Systemen abhängt.
Gerade wenn Unternehmen mit Internet und Application-Service-Providern oder klassischen Outsourcern zusammenarbeiten, ist es sinnvoll, gemeinsam mit dem Dienstleister ein Change Advisory Board einzurichten und in oben beschriebener Weise vorzugehen. Denn bei diesen Geschäftsmodellen haben die Beteiligten in der Regel keine gemeinsame Sicht auf die IT, weil alle in unterschiedlichen Unternehmen arbeiten und verschiedene Interessen verfolgen. So kann es im Unternehmen, das ASP-Leistungen bezieht, zu Problemen kommen, wenn der Provider zum Beispiel ein neues Software-Release einspielt, was zwar aus seiner technischen Sicht Sinn macht, nicht aber aus der geschäftlichen Perspektive seines Kunden. Um hier klare Verhältnisse zu schaffen und Probleme zu vermeiden, sollte der Provider oder Outsourcer das Change-Management gemeinsam mit den Kunden durchführen, weil nur sie die Auswirkungen geplanter Changes auf ihr Geschäft beurteilen und einschätzen können.
*Titus Kaufmann ist Geschäftsführer der Adhoc SMT GmbH in Bensheim
Abb: Anpassung des Systems
Beziehung zwischen Change- und Configuration-Management. (Quelle: ashoc SMT GmbH)