Wie Breuninger das Risiko der IT-Änderungen mindert

Der Begriff Change-Management bezeichnet einen der komplexesten Prozesse in der Informationstechnik. Hier hinein spielen Aspekte wie Risiko und Sicherheit, Controlling, Assets, Abhängigkeiten - und eine hohe Disziplin. Ein Unternehmen, das solche Abläufe nicht standardisiert und dokumentiert, lebt immer mit einem hohen Risiko: Plötzlich steht das System still, und niemand weiß, woran es liegen könnte. Eigentlich hatte man doch nur schnell mal einen winzigen Patch einspielen oder eine neue Komponente installieren wollen, und jetzt drohen ernste Umsatzeinbußen, vom Schaden an der Reputation ganz zu schweigen.

Gerade in mittelständischen Unternehmen passieren Infrastrukturänderungen häufig noch "nebenher" und ohne Koordination oder Absprachen. Den Erfahrungen des Systemintegrators Consulting4IT zufolge nutzen höchstens fünf Prozent der deutschen Mittelständler dokumentierte Standardprozesse, um ihre Changes voranzutreiben und mit geeigneten Lösungen nachzuverfolgen.

Weniger Reibungsverluste

Zu dieser Minderheit zählt die 5.500 Mitarbeiter starke E. Breuninger GmbH & Co. Das 1881 gegründete Familienunternehmen mit Hauptsitz in Stuttgart betreibt bundesweit Kaufhäuser der gehobenen Kategorie. Das 90köpfige IT-Team der Mode- und Lifestyle-Kette betreibt dabei seine durchaus heterogene Umgebung weitgehend selbst - abgesehen von einer verlängerten Werkbank in Kroatien.

Doch als vor etwa zwei Jahren die Einführung eines neuen Warenwirtschaftssystems (Dynamics AX von Microsoft) anstand, wollte Breuninger Support und Entwicklung dafür - entgegen der bisherigen Gewohnheit - von außen beziehen. Dem Chief Information Officer (CIO) Frank Postel war klar, dass solche Konstellationen Reibungsverluste mit sich bringen können. Die würden sich nur vermeiden lassen, wenn die Zusammenarbeit zwischen dem internen IT-Betrieb und den externen Entwicklern durch definierte und IT-unterstützte Prozesse geregelt wäre.

Der CIO wusste, was er brauchte: ein allgemeingültiges Verfahren für die Handhabung von Änderungsanfragen (Requests for Change) und deren Umsetzung - auf Neudeutsch: ein definiertes Change-Management-Verfahren. Es sollte verbindliche und revisionssichere Vorgehensweisen definieren sowie dokumentieren, mit denen sich Anforderungen erfassen, einsteuern, prüfen, genehmigen und schließlich in die Produktion überführen ließen. Auf diese Weise würden alle Änderungen an der IT transparent. Parallel zu den Prozessen mussten aber auch die Rollen der IT-Mitarbeiter neu definiert werden.

Suche nach einem Partner

Postel war von Otto zu Breuninger gekommen. Er kannte den Zeitdruck, der auf den Abläufen im Modegeschäft lastet. Und er wusste auch um das schrumpfende Wartungsfenster, bedingt durch immer längere Öffnungszeiten und Internet-Geschäft.

Ganz andere Erfahrungen brachte Antonija Pandza ins Team: Sie hatte zuvor für den Bankendienstleister Finanz Informatik gearbeitet, wo überprüfbare Standards zur Grundausstattung des IT-Betriebs zählen. Unter anderem wegen dieses Hintergrunds berief Postel die junge, aber durchsetzungsstarke Frau zur Change- und Release-Managerin. Sie ging die ihr übertragene Aufgabe an, indem sie zunächst nach einem Partner für Prozessdefinition, Lösungsauswahl und Implementierung Ausschau hielt. Der musste vor allem zwei Kriterien erfüllen: Er sollte Branchen- und Mittelstands-Knowhow mitbringen, möglichst auch selbst mittelständisch geprägt sein, sowie "pragmatisch" arbeiten.

ITIL auf pragmatische Art

Die letzte Forderung betraf vor allem den Umgang mit der "IT Infrastructure Library" (ITIL). Zwar gilt die Best-Practices-Sammlung für Incident-, Problem- , Change- und andere Service-Management-Prozesse als das Maß aller Dinge. Aber der dort beschriebene Standard ist so umfangreich, dass sich selbst Großunternehmen schwer tun, alle vorgeschlagenen Rollen und Abläufe nutzbringend einzuführen.

Folglich war Pandza zunächst wenig begeistert, als sie sich wieder mit ITIL konfrontiert sah: "Ich kannte das zur Genüge, und ich wusste, dass es uns weniger agil machen würde", erinnert sich die Change- und Release-Managerin. Doch es gab einen Plan, der genau das verhindern sollte. Er sah vor, aus dem viele hundert Seiten starken ITIL-Konvolut nur die Aufgaben und Verantwortlichkeiten zu selektieren, die für ein funktionierendes Change-Management unbedingt notwendig wären und dem Unternehmen einen echten Mehrwert brächten.

"Wir haben uns beispielsweise aus den 20 definierten Rollen nur drei herausgesucht", konkretisiert Pandza, "und das viel beschworene Change Advisory Board haben wir radikal geschrumpft: Es besteht jetzt nur noch aus mir und dem jeweiligen Produktverantwortlichen."

Die fünf Phasen des Change-Managements

Auf der Suche nach professioneller Hilfe wurde Change-Managerin Pandza im Web fündig: Die in Waldbronn bei Karlsruhe ansässige Consulting4IT versprach genau den Pragmatismus und die Agilität, an denen Breuninger gelegen war. Vor allem aber begreift sich das derzeit etwa 60 Mitarbeiter starke Unternehmen als "Systemintegrator mit Prozesserfahrung": Wie die Geschäftsführung gern betont, werden gelebte ineffiziente Prozesse durch ihre Digitalisierung schließlich auch nicht effizienter.

Johannes Volckmann sorgte in seiner Funktion als Principal Consultant seitens Consulting4IT dafür, dass die Breuninger-IT mit Unterstützung der Fachbereiche erst einmal die Sollprozesse für das Change-Management beschrieb. "Er hat einfach immer wieder nachgebohrt, bis er die Prozessantworten bekam", so Pandza. Das Ergebnis lässt sich in fünf Phasen darstellen:

Fünf Phasen

• Am Anfang steht jeweils eine sorgfältige Analyse der gewünschten Änderung - praktisch ein Anforderungs-Management: Was soll verändert werden? Warum ist diese Änderung notwendig? Was bewirkt sie am Ende? Welche Folgen hat sie für andere Infrastrukturkomponenten und damit für das Gesamtsystem? Wer übernimmt die Verantwortung für die Umsetzung der Änderung?

• Darauf folgt die Implementierung. Dank der vorangegangenen Analyse, die auch Budgetfragen, Terminvereinbarungen und Risiken betrachtet, hat sie nicht mehr so viele Ecken und Kanten, bleibt aber trotzdem pragmatisch. Der Change Request ist zu diesem Zeitpunkt "durch", wie Pandza es formuliert. Um die Implementierungen effizienter zu machen, hat Breuninger zeitgleich mit dem Change-Management auch ein Release-Management eingeführt: Änderungen werden nach Möglichkeiten in Containern gebündelt. Das spart Zeit in den folgenden Phasen. Es besteht die Möglichkeit, unterschiedliche Arten von Changes (Hotfixes, Bugfixes etc.) parallel und kontrolliert zu den Releases individuell umzusetzen. So sichert der Prozess auch die geforderte Agilität.

• Ausgiebige Tests sind für die Breuninger-IT unabdingbar. "Bevor eine Änderung in die Produktion geht, wird sie zuvor immer ausreichend lang getestet", beteuert Pandza.

• Erst dann erhält die Änderung die formale Freigabe durch den IT-Betrieb.

• In der abschließenden Review-Phase werden die Changes noch einmal auf reibungsloses Funktionieren untersucht.

Erst die Prozesse, dann die Tools

Als die Prozesse schließlich definiert waren, kam die Frage der Werkzeugunterstützung auf den Tisch. Breuninger hatte beim Thema Softwareverteilung bereits gute Erfahrungen mit dem Tool "Empirum" von Matrix42 gemacht. Da Consulting4IT unter anderem auch Matrix42-Platinum-Partner ist, sprach Vieles dafür, den Versuch mit "Matrix42 Service Desk" zu wagen.

An und für sich unterscheiden sich die Softwareprodukte bei der Handhabung des Service Desk kaum, räumen die Berater ein. Allerdings schlug für Matrix42 ein weiteres Argument zu Buche: Das Unternehmen bietet quasi ein komplettes Tool-Portfolio für das IT-Service-Management (ITSM). Dazu zählen beispielsweise Werkzeuge für den Service-Katalog und das Asset-/Configuration Management. Neben dem Incident-, Problem- und Change-Management waren dies genau die Funktionen, die Breuninger parallel einführen wollte.

Mit Hilfe eines Service-Katalogs - ergänzt um eine Warenkorbfunktion mit Vollkostenbetrachtung - können die Anwender nicht nur IT-Dienstleistungen ohne großen Aufwand bestellen; vielmehr sollen sie gleichzeitig erkennen, welche Kosten ihre Anforderungen verursachen. Viele überlegen sich dann, so das Kalkül, ob die gewünschte Beschaffung oder Änderung ihnen die Arbeit tatsächlich so stark erleichtert, dass sie sich unter dem Strich lohnt.

Diese Transparenz hat aus Sicht der Breuninger-IT einen willkommenen Nebeneffekt: Die internen Kunden müssen sich erstmals wirklich mit Service-Level-Vereinbarungen auseinandersetzen. Offiziell gibt es drei Dienstleistungsgrade: Gold, Silber und Bronze. Aber erfahrungsgemäß erwarten in solchen Fällen fast alle einen Gold-Service, auch wenn der von ihrem Service-Level-Agreement (SLA) gar nicht abgedeckt ist. "Vereinbarungen und Erwartungen laufen häufig auseinander", berichtet Postel aus Erfahrung.

Das Configuration-Management ist wichtig, um den eingangs geschilderten Super-GAU infolge von Infrastrukturänderungen zu verhindern. Wer den Überblick über seinen IT-Bestand verliert, kann Abhängigkeiten und Wechselwirkungen leicht übersehen.

Die Breuninger-IT wirkt dem entgegen, indem sie alle eingesetzten Komponenten in einem Abhängigkeitsbaum darstellt sowie valide Stammdaten in einer Configuration Management Data Base (CMDB) verwaltet.

... und schließlich die Köpfe der Mitarbeiter

Direkt betroffen von der neuen Lösung mit ihren festgeschriebenen Arbeitsabläufen sind mehrheitlich die Spezialisten für den IT-Betrieb. Auf den ersten Blick erstaunt es deshalb, dass von deren Seite kaum Widerstand zu spüren war. "Der IT-Betrieb hat die Vorteile schnell gesehen", bestätigt Pandza. Das heiße aber nicht, dass jeder die Prozesse ad hoc beherrscht hätte. Einzelne Mitarbeiter habe sie schon an die Hand nehmen und mit ihnen gemeinsam die ersten Changes aufsetzen müssen.

Auch die externen Entwickler ließen sich relativ rasch überzeugen, dass sie künftig mit der neuen Lösung arbeiten müssen. Als bezahlte Dienstleister hatten sie wohl kaum eine Wahl.

Um die internen IT-Berater - zum Teil ehemalige Fachbereichsmitarbeiter - und das mittlere Linien-Management vom Mehrwert der Lösung zu überzeugen, brauchte Pandza etwas mehr Zeit. Ihnen gefiel es verständlicherweise nicht so gut, dass sie nun einen verbindlichen und transparenten Prozess einzuhalten hatten, der wenig Spielraum für jahrelange Beziehungen und geschliffene Überredungskünste ließ. Einige Mitarbeiter mussten zudem neue Abläufe und Rollen erlernen. Doch im gewohnt vertrauensvollen Umgang miteinander gelang es Pandza, die anfänglichen Bedenken zu zerstreuen.

Dazu trug auch der semiflexible Ansatz bei, auf den man sich schließlich einigte. Er erlaubt es, in begründeten Einzelfällen vom Standardprozess abzuweichen. Neben den Change-Typen "Projekt", "Non-Standard", "Bugfix" und "Hotfix" hat Breuninger auch die "Einzelversorgung" definiert. Das ist eine Änderung, die nachweislich keine Auswirkungen auf andere Systeme mit sich bringt. Und die darf auch schon einmal außerhalb des Software-unterstützten Standardprozesses vollzogen werden - sofern der Produktverantwortliche einverstanden ist. "Wir wollen ja durchaus die Eigenverantwortung unserer Mitarbeiter stärken", bekennt Postel.

Auf eines lassen sich die Change-Management-Experten aber nur sehr selten ein: "Anpassungen der Matrix42-Lösung wollen wir möglichst vermeiden.", erläutert Volckmann, "stattdessen ist es häufig sinnvoller, den Prozess leicht zu modifizieren, um so nicht update-sichere und kostspielige Customizings zu vermeiden."

Leicht verdauliche Pakete

Budgets für Infrastrukturprojekte sind oft schwer zu bekommen. Solche Vorhaben gelten eher weniger als "hip" und "sexy", taugen also nicht zur Außendarstellung. Zudem lässt sich der Return on Investment (RoI) kaum im Voraus beziffern. Doch für Postel stand fest: "Ich konnte mir überhaupt nicht vorstellen, wie man eine so komplexe Architektur anders hätte handhaben können." Die Frage sei nie gewesen, ob es getan werden musste, sondern nur, ob es richtig und schnell genug gemacht würde.

Um die Budgetfreigabe zu erleichtern, unterteilte der CIO das Gesamtvorhaben in "verdauliche Pakete", wie er selbst es ausdrückt. Jeden Projektabschnitt versah er mit einem separaten Preisschild. Und die Erfolge aus der vorangegangenen Phase halfen ihm, den Segen für die nächste zu bekommen: "Dazu konnte ich bereits die Statistiken nutzen, die sich mit dem System erzeugen ließen - Auswertungen, die vorher überhaupt nicht möglich waren."

Ehrgeizige Zukunftspläne

Für die Inbetriebnahme des Change-Management-Systems hatten sich der CIO und sein Team ein unverrückbares Ziel gesetzt: Es sollte gleichzeitig mit dem neuen Warenwirtschaftssystem in Betrieb gehen. Innerhalb eines Dreivierteljahres mussten also die definierten Prozesse umgesetzt sein - im Tool und auch in den Köpfen der Mitarbeiter.

Der Termin wurde gehalten. Im Oktober 2015 war die Implementierung abgeschlossen, auch wenn die Lösung naturgemäß immer noch angepasst und verbessert wird. Den Grad der Fertigstellung bezifferte Postel mit 90 Prozent. Und Pandza konstatiert: "Mittlerweile flutscht das auch bei allen Mitarbeitern."

Tatsächlich können sich der CIO und seine Leute jetzt darauf konzentrieren, die benachbarten Prozesse - vor allem Warenkorb und Service-Katalog - weiter zu verbessern. Zwei Fachbereiche nutzen hierfür schon eine Pilotanwendung mit einer Handvoll Services, die besonders häufig beansprucht werden, zum Beispiel für die Einrichtung eines neuen Arbeitsplatzes. "Daran üben wir", sagt Postel, "denn es hat keinen Zweck, alles auf einmal zu wollen; damit sind schon ganz andere auf die Nase gefallen."

Zudem arbeitet die Breuninger-IT daran, einige der ITSM-Prozesse, beispielsweise das Zurücksetzen von Passwörtern oder das Aufsetzen eines neuen Servers, völlig zu automatisieren. Auch die mehrstufigen Genehmigungsprozesse sollen weitgehend digital ablaufen. Aufgrund der guten Projekterfahrungen und zugunsten des ganzheitlichen Ansatzes, ist die Umsetzung ebenfalls mit Matrix42 geplant.

Die Investition hat sich gelohnt

Inzwischen ist offensichtlich, dass sich der Aufwand für das komplexe Vorhaben auszahlt: Gestiegenes Kostenbewusstsein beziehungsweise gestutztes Anspruchsdenken im Verein mit gestrafften Abläufen münden in konkrete Einsparungen. Diese ergeben sich unter anderem daraus, dass zu kritischen Zeiten der First-Level-Support deutlich weniger beansprucht wird als früher. Zudem lassen sich die nachgefragten Änderungen heute strukturiert und für alle Beteiligten transparent abarbeiten.

Last, but not least hat die IT die Kontrolle über die "Hotfixes" nach der Implementierung zurückgewonnen. "Jetzt ist transparent, wann welcher Hotfix eingespielt wurde", erläutert Postel: "Das war früher nicht der Fall, so dass der Betrieb häufig unliebsame Überraschungen in Form kurzfristiger Änderungen auf dem Produktionssystem erlebte."