ChaRM@KHS: Zeiten ändern sich

Bei der KHS wurde das Change Management primär seitens der IT gesteuert. Die Steuerung umfasste sowohl die technische Realisierung, als auch die Priorisierung. Jeder Fachbereich wollte seine Änderungen sofort umgesetzt haben, Zielkonflikte zwischen der IT und den Fachbereichen waren vorprogrammiert. Mit SIRIUS haben wir diese Prozesse „rund um das Change Request Management“ neu definiert. Durch den gemeinsam mit den Fachbereichen gestalteten Prozess wurde die primäre Priorisierung und Steuerung von Changes in die Fachbereiche übergeben. Dadurch kommunizieren die Fachbereiche untereinander viel stärker und einigen sich im Vorfeld über die Prioritäten. Durch die Vorgabe ist es für die IT wesentlich einfacher in der Realisierung. Ein Erfahrungsbericht.

Die KHS ist einer der international führenden Anbieter von Abfüll- und Verpackungsanlagen für die Getränke-, Food- und Non-Food-Industrie. Wir stehen für Qualität, Kundenorientierung und Innovationskraft – und nach außen hin leben wir diese Werte auch.

Auf das SAP-ERP-System von KHS greifen ca. 4.000 Benutzer zu. Entsprechend aufwändig waren die Abläufe für das Incident- und Change Request Management. Wir hatten zwar klar definierte Prozesse, aber die führten immer wieder zu Herausforderungen. Konkret sah das dann so aus: Wollte ein Anwender aus dem Fachbereich eine Änderung am System, wandte sich dieser in der Regel direkt an den zuständigen Modulbetreuer und übermittelte eine formlose Beschreibung seiner Anforderung. Diese wurde innerhalb der IT geprüft, priorisiert und realisiert. Nach der Realisierung und Freigabe wurde nach dem Vier-Augen-Prinzip die Änderung ins Produktivsystem übertragen. Dieser Prozess hatte zwei entscheidende Schwachstellen.

Starrer, undurchsichtiger Prozess

Es fehlte an Transparenz, zu welchem Zeitpunkt die konkrete Umsetzung eingeplant wurde. Es konnte sehr schnell gehen, aber auch ein paar Wochen dauern. Die Übergabe ins Produktivsystem konnte jederzeit nach dem 4-Augen-Prinzip erfolgen. Diese unzureichende Transparenz sorgte natürlich für Unmut – und „Schuld“ war am Ende die IT. Die fehlende Priorisierung verschärfte das noch: Es gab keine Instanz, die Change Requests gewichtete und dringende von weniger dringenden Anforderungen abgrenzte. Jeder Anforderer kannte nur seinen eigenen Bedarf und war unzufrieden, wenn dieser nicht schnell erfüllt wurde.

Mit SAP Solution Manager und ChaRM neu aufgestellt

Zur Verbesserung der Situation innerhalb der IT haben wir uns somit für die ergänzende Einführung der Szenarien Incident- und Change-/Releasemanagement im bestehenden SAP Solution Manager entschieden. Als Implementierungspartner haben wir uns schnell und eindeutig für SIRIUS entschieden. Hier war die Erfahrung seitens SIRIUS im ITSM-Umfeld mit der Kombination IT-Prozessmanagement und Solution Manager ausschlaggebend.

Wesentliche Prozessveränderungen

Gemeinsam haben wir neue Verantwortlichkeiten und Workflows definiert.

• Veränderte Organisation: Wir haben zahlreiche neue Rollen definiert, darunter den Global Process Lead. Er prüft die Anforderungen der Fachbereiche und stimmt sie mit einem Release-Verantwortlichen ab. Ein Gremium entscheidet dann über die Priorisierung und schafft in den Fachbereichen sowie in der IT mehr Transparenz. Das verhindert Zielkonflikte zwischen den verschiedenen Fachbereichen und unterschiedliche Zielvorstellungen.
• Wöchentliches Release: Mittwoch ist Release-Tag. Jeder Fachbereich und jeder IT-Mitarbeiter kann sich daran orientieren und weiß, wann welche Änderungen ins Produktivsystem transportiert werden. Ausschließlich dringende Änderungen, welche den Betriebsablauf gefährden, können nach Genehmigung releaseunabhängig produktiv gesetzt werden. Das hilft in puncto Systemstabilität und -verfügbarkeit.
• Release-Testing: Bislang haben wir Änderungen einzeln getestet und produktiv gesetzt. Jetzt bündeln wir alle Changes in ein Wochenrelease und testen dieses komplett. Dies führt zur Qualitätsverbesserung in der Entwicklung.

Fachbereiche zusammenbringen

Mit den ChaRM-Funktionen im SAP Solution Manager hat sich die Nachvollziehbarkeit von Changes maßgeblich verbessert. Um Changes hinsichtlich der Auswirkungen und der Priorisierung zu beurteilen, setzen sich die betroffenen Global Process Leads aus den Fachbereichen zusammen. Jeder erhält nun fachübergreifende und gezielte Informationen im Hinblick darauf, was, wann und warum auf ihn zukommt. Somit erreichen wir das Ziel einer intensiveren Kommunikation und fördern mehr Transparenz. Niemand fühlt sich übergangen oder benachteiligt.

Hierdurch hat das Business mehr Mitspracherecht und es fördert die gemeinsame Entscheidungsfindung zwischen Fachbereichen und IT. Und dies vereinfacht die Arbeit der IT. Denn mit den Rechten kommen auch Pflichten: Bevor sich die IT an die Umsetzung macht, müssen sich die Fachbereiche erst einmal untereinander einigen – und dabei auch gleich die Prioritäten setzen.

Mehr Qualität und Transparenz geschaffen

Offen gesagt: Wir sind heute im Change Request Management nicht viel schneller als früher – aber das war nie unser Ziel. Stattdessen haben wir enorm an Qualität, Nachvollziehbarkeit, Transparenz, Struktur und Sicherheit gewonnen. Und wir können uns als IT ganz anders positionieren, als Enabler statt Verhinderer. Auch ein wesentlicher „Change“ für uns.

Nach erfolgreicher Einführung auf Basis des Solution Manager mit Release 7.1 mussten wir aufgrund des Wartungsendes zum 31.12.2017 auf das aktuelle Release 7.2 wechseln. Durch die gute Zusammenarbeit und das entsprechende Know-how von SIRIUS haben wir uns gemeinsam für ein Folgeprojekt zum Umstieg auf das Release 7.2 entschieden. Hierdurch wurde auch der Projektumfang deutlich verringert und der Realisierungszeitraum relativ kurzgehalten. Dabei sind uns die Erfahrungen seitens SIRIUS aus mehreren SAP-Solution-Manager-Upgrade-Projekten zu Gute gekommen.

Nach einer Projektlaufzeit von 3 Monaten konnten wir Anfang Dezember 2017 das neue Release 7.2 in-time, in-scope und in-budget produktiv setzen.

Titelbild: © Bakhtiar Zein/Shutterstock