Change Management am Beispiel der JTL Wawi

Die einzige Konstante im Leben ist die Veränderung. Das gilt so auch in der Informationstechnologie. Alles ist einem laufenden Wandel unterzogen, den wir irgendwie auch verwalten müssen. Am Beispiel der Warenwirtschaftslösung von JTL will ich mal zeigen, was Change/Veränderungs-Management bedeutet und wie dieses im Unternehmen umgesetzt werden kann.

2016-10-05-14_30_34-jtl-wawi-1-1-4-6-admin-eb-standard
JTL Wawi Dashboard

Der obige Screenshot sollte rund 20.000 Benutzern des Warenwirtschaftssystems JTL-Wawi bestens bekannt sein. Wer sein Dashboard nicht, wie es eigentlich sinnvoll wäre, angepasst hat, wird unten links über neue Updates informiert. Was auf dem ersten Blick ein ganz banaler Vorgang zu sein scheint, ist in Wirklich ein hochkomplexer Prozess. Natürlich können wir jetzt einfach auf den Button Download klicken, die Installationsdatei herunterladen und anschließend die Installation auf einem oder mehreren PCs durchführen.

Aber ist das effektiv? Wissen wir ganz genau, was wir da tun? Ich denke mal nicht. Der Grund vieler Störungen und vermeintlicher Bugs liegt einfach darin begründet des es kein vernünftiges Change Management in den Unternehmen gibt. Da wird wird wie der Teufel aus dem Netz heruntergeladen, neue Software oder Plugins für bestehende auf produktiv genutzten Systemen installiert, ohne das man sich im Vorfeld ausreichend Gedanken über die möglichen Auswirkungen des eigenen Handelns gemacht hat.

Mit Marc Völker vom JTL-Service-Partner Visitmedia habe ich über dieses Thema einen sehr langen Chat in Facebook geführt, in dem es um einen ganz speziellen Aspekt des Change (Veränderungs-) Management geht. Es ging hauptsächlich um die Frage, ob das Warenwirtschaftssystem JTL Wawi überhaupt mit den gängigen Tools verteilt werden kann. An dieser Stelle gehen zwar unsere Meinungen weit auseinander, aber es ist schon mehr als nur bemerkenswert, dass sich hier endlich jemand neben mir Gedanken darüber macht und nach Lösungen sucht.

Das ganze soll jetzt nicht wieder trocken daherkommen. Ich kenne die Sichtweisen einiger Kandidaten genau, die dafür in Frage kommen hier und in Facebook später ihren glorreichen Senf abgeben werden. Angefangen von ich installiere nur jedes dritte Update bis hin zu, ich warte mal ab und schaue ob bei den anderen alles gut gegangen ist. Gleich vorne weg, der Schlüssel für einen erfolgreichen Change-Prozess heißt Kommunikation. Und je besser diese ist, desto geringer ist die Gefahr, das der Change nicht korrekt durchgeführt wird und Störungen (Incidents) auftreten. Auf der Seite des Anwendungsherstellers bedeutet dies, ein ordentliches und vollständiges Changelog den für den Change verantwortlichen Anwendungsbetreuern zur Verfügung zu stellen.

Manch Dumpfbacke hat in der letzten Zeit auf meine berechtigte Kritik an der Update-Politik der Firma JTL-Software GmbH angemerkt, das Microsoft auch alle Nase lang Updates herausgibt und diese doch auch oft mit Fehlern versehen sind. Nun diesen Schraubköpfen sei gesagt, das Microsoft im Oktober 2003, also vor genau 13 Jahren, den Patchday eingeführt hat, mit dem Ziel eine gewisse Planbarkeit beim einspielen von Updates den Administratoren zu ermöglichen. An jedem zweiten Dienstag im Monat werden diese Updates freigegeben. Dieser Praxis schlossen sich 2005 Unternehmen wie Oracle (vierteljährlich), Adobe und im September 2010 SAP an. Für gefährliche Sicherheitslücken werden aber auch außerhalb des Patchdays Sicherheitsupdates veröffentlicht, um das Sicherheitsrisiko für solche Lücken zu minimieren.

Zu dem Punkt mit den Fehlerhaften Updates komme ich noch, da in der Praxis wohl nur ein Promille der fehlerhaften Updates wirklich in der Lage sind Schaden anzurichten, wenn der Prozess des Change Management richtig implementiert ist. Der Grund dafür liegt einfach darin, das fähige Administratoren die fehlerhaften Updates im Vorfeld erkennen und diese erst gar nicht in Ihren Netzwerken verteilt werden. Die Looser sind hier wohl mehr die Millionen an Privatanwendern, die hier öfter mal Opfer des Fehlerteufels werden.

Das Change Management betrifft hier auch nicht nur eine Anwendung, sondern die komplette IT-Infrastruktur eines Unternehmens, von der Hardware mit den Treibern, über die Betriebssysteme, bis hin zu den einzelnen Anwendungen. Und für jede Veränderung muss der folgende Prozess eingehalten werden.

changeprozess
Changeprozess

Request for Change – Änderungsantrag

Jeder Veränderung sollte eine formelle Registrierung der Änderung in einem Logbuch vorausgehen (Aufnahme des Antrags). Darin werden alle Aktivitäten, Diskussionen, Beschreibungen, Analysen, Dokumentationen und Entscheidungen bezüglich der Veränderung festgehalten. In meinem konkreten Beispiel heißt der Änderungsantrag Update auf JTL Wawi Version 1.1.4.7.

Registrierung und Klassifizierung

Bevor wir wie wild loslegen, müssen wir alle Informationen bezüglich der Veränderung sammeln um überhaupt eine Entscheidung treffen zu können, was geändert werden muss, in welche Kategorie unser Change fällt und welche Auswirkungen er hat. Die Kategorie und die Priorität wird basierend auf den Auswirkungen des Changes zugewiesen. In meinem Beispiel kann ich jetzt zusammen mit dem Applikationsverantwortlichen entscheiden, ob dieses Update wichtig ist und welche Auswirkungen es auf den laufenden Betrieb hat. Wenn es sich um ein Sicherheitsrelevantes Update handelt oder eines, welche eine dringende Störung beseitigt, können wir es als Emergency Change deklarieren und somit auch den Notfallplan fahren.

Überwachung und Planung

Jetzt können wir damit beginnen den Change zu planen und eine Kontrolle für den Durchführungsplan zu implementieren. Hier macht es zum Beispiel keinen Sinn den Change an einem Montagmorgen durchzuführen, wenn die Systeme für den Versand der Bestellungen gebraucht werden, die über das Wochenende eingetroffen sind. Die Planung sollte so gestaltet sein, das die Ausfallzeiten möglichst gering gehalten werden und der laufende Betrieb durch den Change nicht behindert wird.

Genehmigung

Haben wir alle Informationen zusammen und einen Plan für die Durchführung, kann die Geschäftsleitung zusammen mit dem Applikationsverantwortlichen und dem ServicePartner entscheiden, ob der Change gemacht wird oder nicht. Hier im Falle der JTL Wawi bedeutet dies, das wir den Change nicht absagen können, sondern nur auf einen späteren Zeitpunkt verschieben, da dieser Change in jedem Fall durchgeführt. Wir können hier nur Anhand der Dringlichkeit entscheiden, ob wir dieses Update sofort einspielen müssen.

Ausarbeitung und Test

Ist der Change genehmigt worden, kommen die Schraubköpfe ins Spiel. Sie übernehmen die technische Durchführung des Changes. Um zu verhindern, das der Change schwerwiegende Auswirkungen auf die Service-Qualität (übersetzt: auf die Funktionalität des Warenwirtschaftssystems) sollten wir den Change erst in einer Testumgebung testen, den Test vom Applikationsverantwortlichen absegnen lassen (Schwarzen Peter an DAU zurückgeben) und einen Roll-Back-Plan in der Hinterhand haben, falls der Change doch in die Hose geht.

Freigabe und Implementierung

War der Test erfolgreich und nach Überprüfung des Roll-Back-Plans kann der Change durchgeführt werden. Also unser Schraubkopf rennt los (daher auch der Begriff Turnschuh-Administration) und führt den Change an allen Systemen (möglichst gleichzeitig) durch. Im Falle der Wawi bedeutet dies, das zuerst der Datenbankserver die neue Version erhält, damit die Datenbank auf den neuen Release-Stand gebracht wird und anschließend alle Clients im Netzwerk, wie im Durchführungsplan beschrieben die neue Version erhalten.

Auswertung und Dokumentationen

Ganz zum Schluss müssen wir unseren Change noch auswerten. Dabei geht es um Fragen wie:

  • Sind die gesetzten Ziele innerhalb der vorgegebenen Grenzen erreicht worden?
  • Entspricht das erreichte Ergebnis der vorherigen Erwartungshaltung?
  • Wurden vereinbarte Projektzeiten (Milestones) eingehalten?
  • Ist der Prozess mit dem vorgegebenen Budget und den angedachten Ressourcen durchgeführt worden?
  • Sind unvorhergesehene Probleme aufgetreten?

Ziel der Auswertung ist es, die Effizienz der durchgeführten Maßnahmen zu ermitteln und hat uns der Change das gebracht, was wir uns im Vorfeld davon erhofft haben.

Fazit

Never Change a running System

Diese Weisheit aus der Steinzeit der Informationstechnologie bekommt durch einen Change-Prozess einen sehr langen Bart, vorausgesetzt es wurde im Vorfeld ein vernünftiges Client Management mit den dafür notwendigen Werkzeugen implementiert.

Aus Sicht eines Piloten bedeutet dies, das ich in den Wolken vom gefährlichen Sichtflug (VFR) auf den durch die Flugsicherung unterstützten Instrumentenflug (IFR) wechsle. Die Vorteile dabei sind, das ich viel sicherer fliege und mich auf die Aussagen der Fluglotsen verlassen kann. Wichtig ist nur, das es eine Kommunikation zwischen dem Unternehmen, den externen Servicepartnern und den Herstellern der Systeme gibt. Microsoft hat mit den Windows Server Update Services (WSUS) ein mächtiges Werkzeug geschaffen, mit dem Administratoren auch in Arbeitsgruppen Updates von Microsoft und anderen Softwareherstellern, wie zum Beispiel Adobe, verwaltet, getestet und bereitgestellt werden können. Ein einfaches Change Advisory Board lässt sich mit Excel, LibreOffice Calc oder auf einer SharePoint-Seite in wenigen Minuten einrichten.

Die größte Hürde liegt aber in den Köpfen der verantwortlichen Beteiligten. Hier muss die Einsicht entstehen, das ein Change ohne eine gründliche Planung im Vorfeld immer mit einem unkalkulierbaren Risiko verbunden ist und im schlimmsten Fall zu einem Totalausfall der Systeme führen kann.

Und jetzt mache ich mich über die Paketierung der Wawi her, damit ich euch zeigen kann, wie einfach das geht.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.