Selbstwahrnehmung
Wie CIOs sich selbst belügen
4. "Wir machen ITIL"
Es mag jetzt nach spitzfindiger Wortklauberei klingen, aber man kann ITIL nicht "machen". Es ist ein Framework - wie seine Befürworter geduldig jedem erklären werden der nicht bei drei auf den Bäumen ist. Freiwillig bleibt bei einem solchen Vortrag in der Regel nur eine sehr kleine und dann auch oft apathisch wirkende Zuhörerschaft, zu der unser sich selbst belügender CIO nicht gehört.
ITIL bringt die Dinge, die die IT gut zu erledigen hat in Listenform. Es legt dabei aber nicht fest, welche Methoden angewandt werden müssen. Weswegen es keinen einzigen Punkt auf der ITIL-Liste gibt, der in allen Situationen auf die gleiche Weise erledigt werden kann. (Wenn Sie das nicht glauben: Stellen Sie sich vor, wie Sie Ihre IT in einer kleinen Werbeagentur betreiben würden. Und jetzt, wie Sie die Sache angehen würden, wenn Sie für einen Security-Anbieter arbeiten, der mit Regierungsinstitutionen Geschäfte macht.)
- ITSM
ITSM steht als Kürzel für IT-Service-Management. Wikipedia definiert ITSM als „Gesamtheit von Maßnahmen und Methoden, die nötig sind, um die bestmögliche Unterstützung von Geschäftsprozessen (GP) durch die IT-Organisation zu erreichen“. ITSM beschreibe insofern den Wandel der Informationstechnik zur Kunden- und Serviceorientierung. Das ist soweit eine nachvollziehbare und gängige Definition, aber keineswegs die einzige. Eine andere findet sich im Glossar der aktuellen Version ITIL 2011. Demnach meint ITSM die Implementierung und das Management von qualitativen IT-Services, die den Anforderungen des Business genügen. - ITIL
ITIL – Kürzel für IT Infrastructure Library – wurde ursprünglich seit den 1980er-Jahren von einer britischen Regierungsbehörde entwickelt. Die bis 1998 vorliegenden Dokumente der Sammlung von vordefinierten und standardisierten Prozessen, Funktionen und Rollen wurden nachträglich zur Version 1 erkoren. Bis 2003 lag Version 2 vor. 2007 folgte eine dritte Version, die als ITIL V3 bekannt wurde. Diese wurde bis 2011 aktualisiert und unter dem Namen „ITIL 2011 Edition“ veröffentlicht. Es handelt sich dabei um die bisher aktuellste Version der Best Practice-Sammlung, die jeweils an die individuellen Voraussetzungen des Anwender-Unternehmens angepasst werden muss. - Change Management
Durch eine Reduzierung von Vorfällen und Problemen bei Veränderungen ergeben sich im Ideal direkte positive finanzielle Effekte. Zu den Vorteilen zählen außerdem ein bessere Steuerung von Veränderungen und eine verbesserte Zusammenarbeit über Teamgrenzen hinweg, was mit einer verbesserten Risiko- und Folgenbewertung von Veränderungen einhergeht. - Incident Management
Das Incident Management umfasst Ereignisse, die ein ordentliches Erbringen des Services gefährden, stören oder unmöglich machen. Das Ziel ist es, die gewünschte Servicequalität so schnell wie möglich wiederherzustellen. Die geschäftlichen Auswirkungen von Vorfällen sollen minimiert werden. - Service Desk
"Der einzige Kontaktpunkt zwischen dem Service Provider und den Usern“, definiert ITIL 2011. "Ein typisches Service Desk managt Incidents und Service-Anfragen und übernimmt außerdem die Kommunikation mit den Nutzern." Ein Service Desk soll dabei helfen, immer Sinne einer maximalen Business-Produktivität Probleme schneller zu beheben und die IT-Ressourcen optimal einzusetzen.
Darüber hinaus gibt es noch viel zu viele CIOs, für die "ITIL machen" bedeutet, einen funktionierenden Service Desk (oder zumindest einen als Service Desk bezeichneten Help Desk) zu haben und dazu vielleicht noch ein Change Advisory Board (CAB) einzurichten, so dass Devs und Ops sich nicht mehr feindselig anstarren müssen.
5. "Wir machen Agile"
Es gibt IT-Abteilungen, die vom Wasserfall-Modell auf agile Entwicklungsmethoden umgestellt haben.
Auf jedes Unternehmen, das agile Methoden anwendet, kommen mindestens zwölf oder mehr Firmen, die sich stattdessen im agilen Fall befinden. Das liegt in der Regel daran, weil sie zwar strikt alle Scrum-Formalitäten befolgen, dabei aber den erforderlichen Kulturwandel völlig vergessen. Wie in so vielen Business- und IT-"Fällen" genügt es auch hier nicht, Stichpunkte auf Listen abzuhaken.
- Vision, Werte und Sinnstiftung als Leitplanken des Erfolgs
Prägen Vision und Werte meinen Arbeitsalltag? Kenne ich meinen Beitrag zum Unternehmenserfolg? Empfinde ich meine Arbeit als sinnstiftend? - Feedback und Fehlerkultur als Grundlage der Zusammenarbeit
Wie schaffen wir mit konstruktivem Feedback mutiges Verhalten? Wie werden Konflikte als Ressource genutzt? Wie werden wir durch eine Fehlerkultur erfolgreicher? - New Leadership ermöglicht starke Teams
Wie entwickeln Führungskräfte High-Performance-Teams? Wie schaffen es die Führungskräfte, Mitarbeiter zu fördern? Wie gelingt es, erfolgreich in virtuellen Teams zu agieren? - Neues disruptives Denken ermöglicht Innovation
Wie werden experimentelle und disruptive Prozesse gelebt, um Innovationen zu fördern? Ist lebenslanges Lernen bei den Mitarbeitern verankert? Wird lösungsorientiertes Denken gefördert?
Und wo wir gerade dabei sind: Viele Firmen, die nicht in diese Falle tappen, entwickeln sich stattdessen in die andere Richtung. Sie sind von AgileAgile weit entfernt und kämpfen stattdessen gegen die Planlosigkeit. Das hat der unternehmenseigene "Wasserfall-Fan" natürlich schon lange vorher kommen sehen. Und auch alles dafür getan, damit es genauso kommt. Alles zu Agile auf CIO.de
6. "Wir machen DevOps"
Trotz des Wirbels um das Buzzword DevOps, haben die Befürworter dieses Ansatzes die Kollaboration nicht erfunden. Der Agile-Ansatz hat die übergreifende Zusammenarbeit bereits lange zuvor propagiert. Auch wenn die Entwickler dabei nicht unbedingt die Ops im Sinne hatten.
Das kann DevOps zum Agile-Mix beitragen:
Entwicklerteams beinhalten IT Operators. Aus rein egoistischen Gründen: Sie wollen nicht darauf warten, dass die Umgebung für sie gebaut wird und sie wollen nicht auf das CAB warten, um Änderungen an der Software auszurollen.
Automatisierung ist eine echt gute Idee und erleichtert die Arbeit.
Mit DevOps befindet sich Software - im Gegensatz zu den meisten anderen agilen Varianten - immer in einsatzfähigem Zustand.
Für die meisten agilen IT-Abteilungen folgt daraus die unschöne Erkenntnis, dass DevOps und ScrumScrum nicht zusammen geht. Kanban funktioniert da besser. Sorry, wenn das für Sie jetzt neu war. Alles zu Scrum auf CIO.de