Die IT und die geschäftlichen Notwendigkeiten Was ist IT-Change Management?

Anbieter zum Thema

Schneider Electric GmbH

VON ZUR MÜHLEN'SCHE GmbH

EPS Rechenzentrum Infrastruktur GmbH

„Alles fließt”, auch in der IT. Um dem häufigen Wechsel der geschäftlichen Anforderungen IT-technisch adäquat entsprechen zu können, ist ein eingespiegeltes IT-Change-Management notwendig. Das ist nicht zuletzt für die beteiligten Mitarbeiter eine große Herausforderung.

Im Idealfall spiegelt die IT-Infrastruktur die geschäftlichen Notwendigkeiten hundertprozentig. In der Realität wird man sich dieser Vorgabe nur annähern können, zumal man bei dieser Approximation zwei Entwicklungsstränge gleichzeitig im Auge haben muss: diejenige des Geschäfts ebenso wie diejenige der IT selbst.

Darüber hinaus ist zu beachten, dass beide Entwicklungsstränge auch noch wechselseitig interagieren. So können einerseits Kosten- und Standortaspekte Unternehmen IT-mäßig Richtung Cloud treiben oder andererseits die (Multi-) Cloud-Entwicklungen in der IT neue Geschäftsmodelle für die Unternehmen interessant erscheinen lassen.

Mehrere Änderungsebenen

Strukturell haben beide Entwicklungsstränge eines gemeinsam: sie erfordern ständige Änderungen in der IT-Infrastruktur und vermutlich auch in der Unternehmensstruktur und Unternehmenskultur. Wir betrachten im Folgenden mit IT-Change Management nur den ersteren.

Der gezielte Einsatz von Verfahren, um eine erfolgreiche Priorisierung, Genehmigung, Planung und Umsetzung von Änderungen an IT Systemen zu gewährleisten, betrifft die technologische Ebene ebenso wie die Prozessebene, die betriebswirtschaftliche Ebene ebenso wie die Mitarbeiterebene.

• Auf der technischen Ebene werden Systeme umgebaut, zum Beispiel die Server-Infrastruktur, oder neu erschaffen, zum Beispiel eine Private Cloud.

• Auf der Prozessebene werden Prozesse optimiert, zum Beispiel die Bearbeitung von Support-Anfragen.

• Auf der betriebswirtschaftlichen Ebene mag es beispielsweise um das Aushandeln von besseren Konditionen mit Providern gehen und

• auf der personellen Ebene kann es um eine Abteilungsumstrukturierung oder um das Auslagern von Tätigkeiten an externe Dienstleister.

Alle genannten Beispiele beziehen sich auf deutliche Strukturänderungen. Tatsächlich gehören aber auch gut standardisierbare beziehungsweise (hoffentlich) standardisierte Prozesse wie Patch- und Update-Management zur IT-Änderungsverwaltung.

Auf der anderen Seite der Komplexitätsskala wären dann komplette Neuinstallationen großer Systeme anzusiedeln, beispielsweise der Ersatz eines ERP- oder CRM-Systems oder einer Datenbankinfrastruktur durch ein anderes System am Markt. Hier kommen neben dem Schulungsbedarf auch noch die Migrationsherausforderungen ins Spiel.

ITIL als etablierter Aufgabenkatalog für IT-Change Management

Seit mittlerweile gut vier Jahrzehnten gibt es mit der Information Technology Infrastructure Library alias ITIL ein detailliert ausgebautes Schema für IT-Change Management, dessen Vorgaben auch in vielen Unternehmen angewandt werden. ITIL besteht aus acht Arbeitsschritten:

• 1. Request-for-Change (RfC) - Der Request-for-Change ist der Änderungsantrag, der den IT-Change-Management-Prozess auslöst. In ihm werden auch alle weiteren Aktivitäten festgehalten.

• 2. Registrierung und Klassifizierung - In dieser Phase werden alle für die Änderung benötigten Informationen zusammengetragen und bewertet.

• 3. Überwachung und Planung - In diesem Schritt wird ein Zeitplan für die Implementierung der Änderung erstellt, inklusive Zwischenetappen.

• 4. Genehmigung - Der Änderungsantrag wird von den Verantwortlichen in der vorliegenden Form genehmigt (oder abgelehnt.)

• 5. Ausarbeitung und Test - Der genehmigte Change wird an die zuständigen Teams weitergegeben. Diese erstellen zunächst ein Testmodell, mit dem die Machbarkeit und die gewünschte Servicequalität überprüft werden.

• 6. Freigabe der Implementierung - Nach erfolgreichem Abschluss der Testphase geht es in die Implementierung der späteren Produktivversion.

• 7. Implementierung - Hier werden die verschiedenen Änderungen konkret umgesetzt. Es müssen verschiedene Teams koordiniert werden, so dass die Zeitvorgaben eingehalten werden.

• 8. Auswertung - Nach erfolgter Implementierung wird der Change bewertet. Wurden die gesetzten Ziele erreicht? Besteht Optimierungsbedarf?

Als Moderator:in / Koordinator_in ist bei ITIL eine Change-Manager:in vorgesehen, die ihrerseits von einem größeren Beraterkreis (Change Advisory Board) unterstützt wird. Mindestens einmal im Monat sollen sich beide Akteure treffen und den Fortgang des Änderungsprojekts zu analysieren.

ITIL ist nur ein „Richtschema“

Der oben kurz dargestellte Ablaufplan ist zeitlich und organisatorisch aufwendig und ist vermutlich nur für große und sehr große Änderungsprojekte angemessen beziehungsweise finanziell darstellbar. Für Standard-Änderungsprozesse wie regelmäßiges Patching und Updating ist er überdimensioniert. Auch für Notfall-Änderungen ist er kaum geeignet, in solchen Fällen fehlt schlicht die Zeit für eine Umsetzung in dem beschriebenen Umfang.

Trotzdem kann die Vorgehensweise viele Anregungen für spezifische Szenarien im Bereich „Standard- und Notfall-Änderungsmanagement“ geben. Auch wird man bemerkt haben, dass der ITIL-Prozess sehr technisch aufgezogen ist.

Menschliche Emotionen sind darin nicht vorgesehen. Dabei spielen solche Emotionen eine oft wichtige und manchmal entscheidende Rolle für Erfolg oder Scheitern (in der Regel für Letzteres).

Das „Menscheln“ hat meist objektive Gründe

Der starke Einfluss emotionaler Faktoren ist beispielsweise bei Projekten wie der Neustrukturierung ganzer Abteilungen oder (noch sensibler) der Übergabe bisher intern abgearbeiteter Prozesse an externe Dienstleister unschwer vorstellbar. Auch jenseits persönlicher Eitelkeit, Versagensängsten vor dem „Neuen“ oder auch schlicht berechtigter Angst um den Arbeitsplatz gibt es bei größeren IT-Change-Management-Projekten viel Potenzial für ein Scheitern auf der ganzen Linie.

Mangelnde Auftragsklärung ist sicher einer der häufigsten Gründe. Wenn nicht klar ist, was eigentlich genau in welcher Zeit zu welchem Preis erreicht werden soll und vor allem nicht klar kommuniziert ist, wieso dieses Ziel so wichtig für das Unternehmen ist, dann sind persönlichen Ränkespielen und dem Kampf um Abteilungsvorteile Tür und Tor geöffnet.

Man darf nicht unterschätzen, dass die verschiedenen Gedanken- und Sprachwelten, die in Change-Prozess-Sitzungen aufeinanderstoßen, auch schon genug objektive Gründe bieten, aneinander vorbeizureden. Taktisch motivierte Scharmützel oder strategisch inszenierte Missverständnisse sind dabei noch nicht einmal nötig, verstärken das Chaos aber noch einmal.

Es gibt keinen 'Königsausweg' aus solchen verfahrenen Situationen, aber man darf doch die Hoffnung aussprechen, dass die verfahrene Situation gar nicht erst entsteht, wenn die Ziele des Änderungs-Prozesses präzise kommuniziert werden, das „Neue“ nicht in übertriebener Weise in den rosigsten Farben gemalt wird, und wenn vor allem das Personal-Tableau nach Erreichen des Ziels ehrlich dargestellt wird, zum Beispiel in dem Sinn „nicht jeder kann immer auf einem angestammten Platz bleiben, aber grundsätzlich werden die Fähigkeiten eines jeden gebraucht“.

„Lingua franca“ für IT-Change Management-Projekte

Um es klar zu sagen: es geht bei der Behandlung der menschlichen Aspekte beim Change-Management weniger um „psycho-pädagogische Stuhlkreise“, sondern um die Einbindung der beteiligten Personen auf Augenhöhe in die Änderungsprozesse. Das heißt in erster Linie, dass die im Change-Prozess gesprochene Sprache jedem geläufig sein muss. Dazu bedarf es geeigneter Schulungsmaßnahmen, es müssen aber auch alle Teilnehmer des Change-Prozesses darauf verzichten, jeweils andere Teilnehmer durch die Nutzung scheinbaren Herrschaftswissens „über den Tisch zu ziehen“.

Und was die gemeinsame Sprache betrifft, so gibt es mittlerweile vor allem durch das Cloud-Computing recht gute Instrumente für die code-sprachliche Darstellung der jeweils verwendeten Anwendungen. Der Autor denkt an die automatische Abbildung der gesamten Infrastruktur in Codeform oder an Automatismen für die Konfiguration von Systemen.

Diese Automatisierung von großen Anwendungsumgebungen, vorzugsweise in der Cloud, scheint auf den ersten Blick die Kluft zwischen IT-Cracks und bloßen IT-Nutzern noch einmal zu vergrößern. Aber das Gegenteil ist der Fall. So lässt sich beispielsweise bei automatischen Konfigurationssystemen eine Message Queue-Steuerung denken, bei der über eine geeignete Webschnittstelle auch bloße IT-Nutzer die Änderung von Anwendungen (Webseiten) anstoßen können, beispielsweise zum Bug Fixing.

Möglich ist, dass durch KI-Instrumente die Integration von IT-Cracks und IT-Nutzern noch einmal besser gelingt. Vielleicht entwickelt sich dann daraus eine echte „lingua franca“ für IT-Change-Management-Prozesse. Ein solche gemeinsame Sprache ist sicher nicht die Lösung aller Probleme, aber eine gute Basis für wechselseitiges Verständnis. Und wechselseitiges Verständnis baut auch emotionale Widerstände ab und verhinderte Querschüsse. Und es erhöht die Prognose für den Erfolg eines IT-Change-Management-Projekts.

(ID:49315759)