Mit DevOps und ITIL sicher im Service Management landen


Der faszinierende IT Roman „Projekt Phoenix“ beschreibt sehr realitätsnah, wie sich eine IT Organisation, Schritt für Schritt aus dem Feuerwehrmodus befreien kann. Ein Vergleich der sich durchaus lohnt.

Der Protagonist im Roman, namens Bill, deckt dabei schwerwiegende Schwachstellen und permanente Störungen in den IT Abläufen auf. Eigentliche Ausnahmesituationen von Businessausfällen sind zur Regel geworden und können aufgrund fehlender Transparenz, nur mit hohem Aufwand vorübergehend gelöst werden. Bill’s Aufmerksamkeit gilt dabei ebenfalls der fehlenden Zusammenarbeit zwischen dem Business, den Entwickler Teams und IT Operation.

In seiner Lösungsfindung erhält er zunehmend nützliche Tipps und Hinweise von seinem Mentor Erik. Dieser erinnert mich, mit seiner schelmischen Art und Weise, irgendwie an Jack Nicholson in dem Film „die Wutprobe“. Dieser erscheint natürlich immer dann, wenn es darum geht, wichtige Weichen für das Unternehmen zu stellen und gewisse Hindernisse mit Sinn und Verstand aus dem Weg zu schaffen. IT Daily Business halt 🙂

Gemeinsam mit seinem Team und der Unterstützung des Top Management, entwickelt Bill eine neue Strategie, die entscheidende Vorteile in der Vorgehensweise und Unterstützung zur Erreichung der Businessziele hervorbringt. Die Ausrichtung an Lean Management Verfahren und dem Einsatz von Kanban Boards ist nicht neu und wirkt dennoch erfrischend, wenn die Sache mal richtig in der IT angegangen wird.

Entwicklerteams und ITOps Teams arbeiten eng zusammen, sodass der Begriff DevOps zunehmend an Gestalt gewinnt. Engpässe entlang der Servicekette werden dabei identifiziert und lange Wartezeiten, die sonst abteilungsübergreifend viel Zeit in Anspruch genommen haben, werden stark reduziert. Ich sage nur mal – Hallo Ticket Ping Pong und hohe Reibungsverluste!

Aber auch der Hinweis zu Frameworks, wie ITIL, zeigen wie Methoden und Maßnahmen sehr gut kombiniert werden können. Änderungen die möglicherweise das Business stillstehen lassen, werden nicht mehr willkürlich und unkontrolliert, sondern via gesteuerten Prozessen kontrolliert in die Produktivumgebung übergeben. Hallo Change Management.

Wider den Prozessfürsten, wird ein sinnvoller Einsatz und die Verzahnung von Prozessen und Methoden umgesetzt. Auch die Gefahr von Siloswissen, als Flaschenhals im Lösungsprozess, wird von Bill im Roman „Projekt Phoenix“ klar erkannt. Mit geeigneten Vorgehensweisen wird nicht nur eine stabile und auf Vertrauen aufbauende Service Organisation entwickelt, sondern auch die Businessziele der jeweiligen Fachabteilungen nachhaltig unterstützt. Letztlich zahlen alle Maßnahmen auf das übergeordnete Unternehmensziel ein.

Bekannte ITIL Prozesse oder auch in der neuen ITIL Version V4 nun IT Praktiken genannt,  kommen in diesem Roman als praktische Lösungsansätze zum Einsatz. Das Buch ist ein abwechslungsreicher Streifzug durch das IT Service Management, was unter anderem folgende Impulse liefert.

Change Management – Mission Control

Wer kennt es nicht: Da wird mal eben eine neue Software ohne Genehmigung (Unkontrolliert) ins Produktivsystem installiert und tausende von Anwendern befinden sich plötzlich per Pauschale in einem Testszenario. Ups – Und wenn dann noch wichtige Abrechnungssysteme zum Ende des Monats nicht funktionieren, dann ist aber die Ka*** richtig am Dampfen.

Eine Rolle Rückwärts ist dann leichter gesagt als getan. Wer hat schon gerne das Thema Backup;) Also muss wieder einmal die IT Feuerwehr ausrücken, um zu retten was noch zu retten ist. Das Chaos regiert. Ich kann mir gut vorstellen, dass einige Leser diese Situation wie Bill der Protagonist aus dem Roman bereits oft erlebt haben. Dieser spürt, dass durch diese unkontrollierten Ad-hoc Aktionen seine Rockzipfel ungeplanter Arbeit zunehmen. Aus dem Grunde arbeitet Bill diszipliniert mit seinen Mitstreitern, an der Verbesserung und der sorgfältigen Planung eines Change Management Prozesses.

Bill entwickelt Change Management zum IT Tower und schützt bei zukünftigen Änderungen, durch ein transparentes Genehmigungsprozedere, die Produktivumgebung des Unternehmens. Die Vorgehensweise zeichnet sich ebenfalls durch einen kommunikativen Austausch mit den jeweiligen Stakeholdern, über die geplanten Änderungen aus.

Tipps die Bill dabei berücksichtigt:

  • Nicht zu bürokratisch werden aber dennoch sinnvoll und mit Plan dokumentieren!
  • Abläufe analysieren und Änderungen bewerten. Nicht alles, ist gleich wichtig! Normale vs. Notfall-Changes. Gibt es bereits bewährte und oft durchgeführte Änderungen, die in einem Standardverfahren bearbeitet werden können?
  • Es lohnt sich immer, einen Blick in den Auswertungen des Incident Managements nach einem Change zu werfen.
  • Zum Sortieren der Changes kann auch anfangs ein Whiteboard mit Post-IT Zetteln zum Einsatz kommen.
  • Ein Change Kalender der für alle im Unternehmen sichtbar an eine prominente Stelle dargestellt wird, wie z.B. im Intranet.
  • Vorleben und Aha-Effekte schaffen! Schulung ist wichtig aber eben auch keine Wunderwaffe.

Change Management ist nicht nur eine Sache der Technik, sondern es ist relevant bei Veränderungen die Menschen im Vorfeld mit einzubeziehen und nachhaltig zu begleiten. Die Planung eines entsprechenden Zeitraums für eine ordentliche Umsetzung ist dabei zu berücksichtigen.

Ich denke da momentan an viele Menschen, die aktuell in ihrem Homeoffice katapultiert worden sind und viele Fragen zu den permanenten Veränderungen haben. Ein gezieltes Onboarding mit nachhaltigem Support ist ein Minimum an Hilfestellung.

Wer sich auf die IT Service Management Reise und dem Baustein „Change Management“ begibt, der sollte sich im Zusammenspiel mit Incident, Problem, Knowledge, Release, Deployment und Request Management Prozessen auseinandersetzen. Natürlich ist der kontinuierliche Verbesserungsprozess ebenfalls dabei zu berücksichtigen. Denn erst eine enge Verzahnung der Prozesse und Methoden, lässt einen hohen Reifegrad zu. Ist eine Menge an Überlegungen und Vorgehensweisen, ja aber Rom ist angeblich auch nicht an einem Tag erbaut worden. Passt immer noch: Think big and start small.

Lesetipp:

  • Axelos – ITIL Service Transition
  • Axelos – ITIL Foundation 4 Edition
  • John P.Kotter – Leading Change (Auch als Hörbuch erhältlich)

Knowledge Management – Wissen im Unternehmen sichtbar machen

Im Buch „Proiekt Phoenix“ wird dreimal mehr unterstrichen, wie wichtig vorhandenes Wissen und ein gezielter Wissenstransfer ist. Dabei gibt es wie so oft, nicht nur den einen Weg. Wie kann man schnelle und richtige Entscheidungen treffen, wenn man keine validen Daten hat?

Nützlich ist auch das DIKW Modell. Als Beispiel: Stelle Dir 10000 Meldungen (Tel,Chat, E-MAIL und Co.) pro Monat am SPOC vor. Sind das alles Störungen und mit welcher Wichtigkeit? Welche Businessprozesse sind betroffen? Wer ist relevanter Ansprechpartner für das Produkt / den Service? Sind das Anfragen oder einfach nur SPAM? Etc… Um dann gezielte Entscheidungen zu treffen ist eine genaue Analyse oft mit hohem Umstand verbunden. Manche Unternehmen nutzen dafür schon ein internes Google oder KI Lösungen,  andere Firmen verharren dafür immer noch in Excel-Mania.
Der Umgang mit sichtbar vorhandenem Wissen (Wenn auch nur strubbelig vorhanden) ist eine Sache aber wie läuft der Hase dann mit dem informellen Wissen?

Silo-Wissen aus welchen Gründen auch immer, wird zunehmend für Unternehmen eine Bremse in der digitalen Weiterentwicklung. Auch im Buch „Projekt Phoenix“ gibt es den einen Highlander, der mit seinem Erfahrungs-Wissen schon oft die IT Organisation vor einem Super-Gau gerettet hat. Leider ist nichts dokumentiert, sodass die Abhängigkeit für die Organisation auch ein hohes Gefahrenpotential verbirgt.

Wie schafft man es, informelles Wissen (Das was in den Köpfen steckt und nicht sichtbar ist) in formelles um zu wandeln? Im Buch wird ein strukturierter Wissenstransfer durchgeführt, d.h. Mitarbeiter begleiten den Experten und Lernen von ihm. Es wird dokumentiert und Videos aufgezeichnet, sodass man im Falle eines Falles auf wichtige Informationen zugreifen kann. Informelle Ströme sichtbar zu machen ist dabei ein wesentlicher Aspekt. Aber wo steckt denn das ganze Wissen dann?

Stellt euch einfach mal einen Eisberg vor und dreht diesen um. Ihr wisst ja, 2/3 des Eisbergs liegt unter Wasser. So ist das auch mit den Wissensschätzen im Unternehmen 😉

Das Heben von Wissensschätzen ist kein Kinderspiel aber dafür eine lohnende Investition. Technische Möglichkeiten gibt es genug, nur müssen diese auch mit Verstand eingesetzt werden.

Im Zuge der Digitalisierung kommt man als Unternehmen nicht mehr um den Einsatz von Social Collaboration Tools herum. Allerdings mal eben mit der Gießkanne Collaboration Werkezuge über die Mitarbeiter verteilen, wird nicht funktionieren. Das reduziert nur die Möglichkeiten! Zeit für eine ordentliche Planung und zielführende Umsetzung muss dabei einkalkuliert werden.

Das Rollout von Software ist dabei nur ein Element auf der Reise in die virtuelle Zusammenarbeit. Die technische Verfügbarkeit als Rahmenparameter ist wichtig aber auch nur die Vorstufe um den Nutzen eines Netzwerks auszuschöpfen. Ein Schienensystem macht auch nur Laune, wenn es über ein gutausgebautes Wegenetz verfügt, aber wer kümmert sich um die Fahrgäste?!

Wie wäre es mit einem internen Netzwerk, wie z.B. LinkedIn? Alle Mitarbeiter sind vernetzt und tauschen sich unternehmensweit zu relevanten Themen aus. Dabei wird ebenfalls das Prinzip, „Wissen wird nur mehr, wenn es geteilt wird“, verfolgt. Community Management wird logischerweise für gute Erfolgsaussichten relevanter. Also entdecke die Möglichkeiten und stelle den Eisberg auf den Kopf 🙂

Ein zeitgemäßes Knowledge Management ist nicht nur auf eine Knowledge Base reduziert, sondern vereint klassische und moderne Vorgehensweisen. Durch die entstehende Wissenstransparenz werden Unternehmen ebenfalls in die Lage versetzt, schnelle und gezielte Entscheidungen zu treffen. Stichwort: DIKW Modell

Lesetipp:

Incident Management – Wenn der Service mal wieder versagt

Wenn der Service wieder einmal versagt und die Ticketanzahl in die Höhe springt, dann ist eine strukturierte Vorgehensweise mit Ziel der Kundenzufriedenheit (Intern + extern) sehr vorteilhaft. Allerdings bewährte Abläufe kommen auch in die Jahre und sind nicht mehr unbedingt zeitgemäß. Old School IT wird dann wieder zum reaktiven Tagesgeschäft. Hallo Feuerwehrmodus. Ohne Kompass geht es in der Lösungsfindung weiter und im 10 Minutentakt muss dennoch der Kunde informiert werden.

Das Buch „Projekt Phoenix“ zeichnet genauso ein Bild, wie oben kurz beschrieben. Da werden War-Rooms eingerichtet, die die Leute spontan zusammenbringt um nach irgendwelchen Lösungen Ausschau zu halten. Oft ist es dann dieser eine Experte, der Held, der mal eben mit seinem Exklusiv-Wissen noch das Ruder herumreißt. Auch im Roman erweist sich die Abhängigkeit von Silowissen, als Bedrohung für die interne Stabilität und zukünftiger Vorhaben.

Ich bin immer wieder erstaunt, wie wenig Support Teams abteilungsübergreifend zusammenarbeiten bzw. zusammenarbeiten dürfen und so auch kein Wissenstransfer stattfindet. Alles schön streng hierarchisch abgebildet und scheinbar transparent, doch die Reibungsverluste zwischen den Schnittstellen sind enorm hoch. Einträge in der Knowledge Base sind entweder nicht vorhanden oder nicht aktuell. Eine simple Störungsbearbeitung kann dann schon mal ziemlich lange dauern. Stochern im Nebel.

Doch der notwendige Wissensaustausch zu einer Lösung findet oft über informelle Wege statt. Ihr kennt das ja, der Raucherraum, der Spaziergang oder die Kaffeeküche sind wahre Lösungsbeschleuniger 🙂 Leider bleibt das Wissen auf diesen informellen Wegen für den nächsten Feuerwehreinsatz auf der Strecke. Ein Knowledge Management was sich auch mit informellen Wissensströmen beschäftigt, ist oft Mangelware.
Längst ist eine vernetzte Zusammenarbeit gefragt, die über das herkömmliche 1st, 2nd und 3rd Level Modell hinaus geht. Nichts gegen klare Abläufe aber manchmal sind diese einfach zu behäbig. Old School ITSM könnte man auch sagen!

In diesem Zusammenhang ein kleiner Ausflug ins Thema Shift-Left mit Knowledge Centered Service (KCS) und dem UFFA Workflow. Dieser Ablauf des Consortium Service Innovation, (Serviceinnovation) erweitert die ITIL Support Praktiken in der Sache, wie etwas gemacht werden kann. Eine hervorragende Ergänzung zum IT Knowledge Management.

Durch KCS wird die gezielte Wiederverwendung von Wissen im Lösungsprozess verfügbar gemacht, die Dokumentationen im Prozess werden vereinfacht und Einträge sind besser such-, les- und nutzbar. Das Ergebnis, die IT Organisation arbeitet produktiver, aufgrund vom schnelleren Auffinden richtiger Knowledge Base Artikel und reduziert die Bearbeitungszeit und folglich erhöht sie die Uptime. Hallo Shift-Left!

KCS unterstützt ebenfalls die Arbeitsweise bei der Bearbeitung von Requests, bezüglich der Dokumentation und Nachverfolgung. Dabei wird ein Blickwinkel auf Self-Service gelegt, in dem z.B. FAQ Artikel erstellt werden. So können Anwender oder Kunden ihre Zeit besser einteilen und brauchen nicht unbedingt den Support in Anspruch nehmen.

 

Bildinhalte-Quelle: Axelos / HDI

Am Single Point Of Contact (SPOC) oder auch als Service Desk bekannt, wird zuerst ein Blick in die Knowledge Base geworfen, um nach vorhandenen Knowledge-Beiträgen zur Anfrage/Problemlösung zu suchen.
Wenn ein Beitrag gefunden wird, dann wird dieser genutzt (USE IT) – Die Wiederverwendung eines Knowledge-Beitrags reduziert in vielen Fällen nicht nur die Downtime, sondern auch die allgemeinen Supportkosten und weniger technischer Eskalationen. Hallo Shift-Left! Hallo ROI!

FIX IT – Kommt ins Spiel, wenn der Knowledge Beitrag nicht korrekt ist oder verbessert werden soll. Fehlen die Rechte zur Bearbeitung des Knowledge Beitrags (z.B. Redaktioneller Ablauf), dann wird dieser gekennzeichnet mit (FLAG IT). Jemand mit den Autorisierungsrechten wird dann den Beitrag komplettieren und für die Knowledge Base freigegen (ADD IT). Stichwort: Redaktionssystem

Ein wesentlicher Aspekt dabei ist, dass die Knowledge Base Beiträge aus der Sichtweise der Kunden erstellt werden. Also keine Nerdsprache via klassischem Ticket Ping Pong

Lesehinweis: Synenergies beween ITIL und KCS 
Tipp: Netzwerken in der KCS LinkedIn Gruppe

Viele nützliche Themen, die sich miteinander kombinieren lassen gibt es schon sehr lange. Social Collaboration ist ebenfalls kein Neuling, sondern schon fester Bestandteil moderner Arbeitsumgebungen. Auch hier ist ein Brückenschlag zwischen IT Service Management und Enterprise 2.0  Methoden längst überfällig. Endlich erhalten Begriffe, wie „Intelligent Swarming und Shift-Left“ explizit einen Platz im ITIL Universum. Wurde ja auch mal Zeit 😉

Hinweis: Tools und Techniken schreiben nicht die Vorgehensweise vor, sondern dienen nur zur Unterstützung eines sauberen Workflows. Technische Lösungen sind zur Unterstützung der gemeinsamen Zusammenarbeit abteilungsübergreifend zu betrachten. Für eine Auswahl an technischen Werkzeugen, wie z.B. ein Ticketsystem empfiehlt es sich die MUSS und KANN Kriterien zu analysieren.
Stichwort: MoSCoW Analyse https://t2informatik.de/wissen-kompakt/moscow-method

Problem Management – Sherlock Holmes geht auf Ursachenforschung

Im Buch „Projekt Phoenix“ versucht Bill den dauerhaften Störungen mit gezieltem Problem Management Methoden zu entgegnen. Nicht nur um die Nerven der IT Organisation zu schonen, sondern insbesondere um seine Kunden vor IT Ausfällen und den damit verbundenen Kosten zu schützen. Eine abteilungsübergreifende Zusammenarbeit zur gemeinsamen Lösungsfindung ist dabei ein wesentlicher Aspekt.

If you want less Incidents do Problem Management

Der Merksatz: „If you want less Incidents do Problem Management“, entspricht nicht irgendeiner Küchenphilosphie, es bedeutet die Stabilität der Produktivumgebung zu gewährleisten.

Eine hohe Anzahl an Incidents (Störungen) inklusive fürchterlicher Langläufer-Tickets, ist keine schöne Sache. Nicht nur für die Kunden, sondern ebenfalls für die Mitarbeiter am Single Point of Contact.

Während im klassischen Incident Management reagiert wird, so spielt im Problem Management das Vermeiden von Störungen eine große Rolle. Sherlock Holmes geht nachdem die Feuerwehr den IT Brand gelöscht hat auf Ursachenforschung. Manchmal nutzt er dabei die Fünf-Why-Methode oder wendet die Paretoregel an, z.B.  80% der Incidents  können mit 20% an Problems verknüpft werden. Er macht sich aber ebenfalls die Technik zu nutze und mit einem aktivem Monitoring entwickelt Sherlock alias Problem Management, zum Schutz ein Frühwarnsystem. Vergleichbar mit einer App die uns vor einem Tsunami warnt. Wohl dem, der dann über eine valide Datenaussagefähigkeit verfügt. Hallo Knowledge Management.

Ein paar Impulse zur Vorgehensweise

Konzentration auf die Top 5 Services, die bei Störungen möglicherweise das Business lahmlegen, dabei die Auswirkungen bewerten und über Notfallszenarien sprechen.

  1. Was ist die Ursache einer Vielzahl von Incidents? Dabei hilft ebenfalls der Blick in die Auswertungen des Change- und Incident Managements. Abhängigkeiten erkennen.
  2. Weniger Stress im operativen Bereich durch die Reduzierung von wiederkehrenden Tickets.
  3. Mitarbeiter am Single Point of Contact in Fragetechniken schulen. Zum Beispiel eignet sich gut die Fünf-Why-Methode.
  4. Nutze die Known Error Data Base zur transparenten Dokumentation und für eine schnelle Lösungsrate – Think Shift-Left
  5. Nerven schonen durch proaktives Monitoring der IT Landschaft und eine Info erhalten bevor es im Karton rappelt.
  6. Prozesse, wie Event Management, Knowledge Management und Kontinuierlicher Verbesserung (KVP), zwecks Dokumentation, mit einbeziehen.

Lesetipp:

KVP – Kontinuierlicher Verbesserung Prozess – Neue Ideen entstehen oftmals im Gespräch

Auch im Roman „Projekt Phoenix“ spielt die kontinuierliche Verbesserung eine wichtige Rolle um Fehler zu finden und in der Zukunft zu vermeiden. Insbesondere Autokonzerne nutzten schon früh ihr betriebliches Vorschlagswesen um Mitarbeiter-Ideen zu sammeln. Millionen Euro Beträge wurde so entlang der Fertigungsstraßen eingespart.

In einigen Projektmanagement Methoden und Frameworks hat mittlerweile das Thema Verbesserung verschiedene Gesichter. Lessons Learned, Retrospektiven und Co. Wird ein gezielter Dialog und regelmäßigen Feedbackschleifen unter der Einbindung von Kunden zu Verbesserungen implementiert.

Das ITIL Universum unterstreicht nach wie vor das Thema von KVP mit dem Begriff „Continual Service Improvement“ (CSI) und mit dem damit verbundenen Verbesserungspotential. Auch in der neuen Version V4 stellt CSI eine tragende Säule im Service Management dar. Es gilt weiterhin, entdecke die Möglichkeiten! Wie viele Ideen wurden heute eigentlich in deinem Unternehmen eingereicht?

Die wesentlichen Bausteine – eine offene Unternehmenskultur aufbauend auf Vertrauen, Kommunikation auf Augenhöhe und eine abteilungsübergreifende Zusammenarbeit, bilden dabei unanfechtbar das Fundament. Das Thema Nachhaltigkeit wird ebenfalls zum Wettbewerbsfaktor und in Zeiten von Social Media wird man schnell entlarvt, wenn man nur ein Deckmantel namens CSR (Corporate Social Responsibility) überstreift.

In diesem Zusammenhang noch ein paar Lesetipps:

  • Axelos – ITIL Continual Service Improvement
  • Axelos – ITIL Foundation ITIL 4 Edition
  • Masaki Imai – Kaizen
  • Minoru Tominaga – Die kundenfeindliche Gesellschaft
  • Witt – Der Kontinuierliche Verbesserungsprozess (KVP)
  • Leopold/Kaltenecker- Kanban in der IT
  • Blogbeitrag: CSI Modell mit Bezug auf Enterprise 2.0 Einführung

Wer gerne über den Einsatz von Lean Praktiken, DevOps, ITIL, Kanban Boards, Agilität und Co. etwas im Storytelling Format erfahren möchte, der ist mit dem Buch „Projekt Phoenix“ bestens beraten. Ein spannendes Buch zum Thema Service Management, fernab jeder steifen PowerPoint Präsentationen. Ein klasse Impulsgeber für die Praxis!

#Silos aus und #Vernetzung an

Dieser Beitrag wurde unter #E20, ITIL Service Management, LinkedIN, Microblogging, Social Media, Social Networks abgelegt und mit , , , , , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.