"Die Aufgabe der IT ist es, die User glücklich zu machen". Dieses Statement eines jungen Vertrieblers für IT-Service-Management-Lösungen würde wohl kaum ein CIO unterschreiben. Dafür fände es bei den Anwendern sicher breite Zustimmung. Denn sie erwarten von einer erstklassigen IT vor allem eins: Sie muss reibungslos funktionieren, und wenn es doch einmal irgendwo hakt, soll sie schnell Abhilfe schaffen.
Was so simpel klingt, ist das Ergebnis eines komplexen Systems von Infrastrukturentscheidungen, Software-Tools und Prozessen. Es geht nicht nur darum, Störfälle ad hoc aufzunehmen und möglichst rasch abzuarbeiten. Das, was im Fachjargon Incident-Management genannt wird, ist nur eines der vielen Teile des IT-Service-Managements (ITSM), mit dem die Anwender unmittelbar konfrontiert werden. Zu diesem "sichtbaren" ITSM gehören zudem die automatisierte Anforderung und Genehmigung von IT-Komponenten mit Hilfe eines Service-Katalogs.
Das unsichtbare ITSM
Daneben oder darunter gibt es aber in vielen Unternehmen jedoch ein Netz miteinander verbundener und voneinander abhängiger ITSM-Komponenten, von dem sich der normale User meist keine Vorstellung macht. Beispielsweise gilt auch im ITSM der Nachhaltigkeitsgedanke: Anstatt nur auf Incidents zu reagieren, ist es auf Dauer effizienter, die einzelnen Störfälle zu analysieren und auf bestimmte, wiederkehrende Muster und Fehlerquellen zurückzuführen. Diese Aufgabe erledigt das Problem-Management. Eine Knowledge-Management-Komponente, beispielsweise eine Wissensdatenbank, innerhalb der ITSM-Umgebung kann helfen, Störungsmuster zu erkennen und erfolgversprechende Lösungsmöglichkeiten zu identifizieren.
Am geschicktesten ist es jedoch, mögliche Fehlerquellen abzudichten, bevor die damit verbundenen Probleme überhaupt auftreten. Dabei helfen ein gut gepflegtes Asset- und Konfigurations-Management inklusive einer Configuration Management Data Base (CDMB). Solche Werkzeuge ermöglichen es dem IT-Service-Team, den Überblick über alle im Unternehmen eingesetzten Hardware- und Softwarekomponenten mit all ihren wechselseitigen Abhängigkeiten zu behalten. Das hilft - zumindest theoretisch - zu verhindern, dass kleine Änderungen an einem Teil der Infrastruktur das Gesamtsystem lahmlegen.
Die ITIL-Euphorie ist verflogen
Für diese - und noch ein paar weitere - ITSM-Aufgaben müssen die IT-Bereiche gemeinsam mit den Anwendern Prozesse definieren und vor allem auch Sorge dafür tragen, dass sie auch eingehalten werden. Dabei handelt es sich trotz aller Verschiedenheit der Unternehmen weitgehend um Standardabläufe.
Viele IT-Bereiche orientieren sich deshalb an der Best-Practices-Sammlung IT Infrastucture Library (ITIL). In deren fünf Bänden sind insgesamt 37 Kernprozesse für das ITSM beschrieben - angefangen vom Strategie- und Finanz-Management für IT-Services über das Information-Security-Management sowie das Servicekatalog- und Service-Level-Management bis zu den operativen Prozessen am Service Desk und einem kontinuierlichen Verbesserungsprozess (Continous Service Improvement).
Mittlerweile haben viele Unternehmen die Prozesskompetenz ihrer IT-Service-Mitarbeiter nach ITIL zertifizieren lassen. Doch die ganz große Euphorie ist verflogen. Vor allem mittelgroße Unternehmen klagen zunehmend darüber, dass das ITIL-Kompendium viel zu umfangreich und detailliert sei, um es praktisch zu nutzen. Und die vielen unterschiedlichen Rollen, die ITIL beschreibt, können Mittelständler meist gar nicht besetzen.
Folglich wird seit einigen Jahren der Ruf nach einer abgespeckten Version der Best-Practices-Sammlung immer lauter, sprich: nach einem "ITIL Light". Tatsächlich gibt es schon Alternativen wie FitSM oder YaSM. Allerdings hat ITIL immer noch ein gewichtiges Argument auf seiner Seite: Das Regelwerk ist von Anwendern wie Dienstleistern anerkannt, dient quasi als gemeinsame Sprache. Deshalb entscheiden sich viele Unternehmen, dabei zu bleiben. Aber nur die Prozesse und Rollen umzusetzen, die sie wirklich brauchen - das hört sich einfacher an, als es tatsächlich ist, und es erfordert häufig die Hilfe versierter Berater.
Flexibel und hybrid versus definiert und wiederholbar
Darüber hinaus stellt sich heute die Frage, ob ein nach verbindlichen Prozessen ablaufendes ITSM überhaupt noch zeitgemäß ist - angesichts von IT-Umgebungen, die zumindest teilweise nach dem Nike-Prinzip ("Just do it") funktionieren: Systems of Engagement, agile Entwicklungsmethoden, hybride Umgebung aus On-premise- und Cloud-basierenden Anwendungen, das Verschmelzen von Development und Operations zu DevOps, das sind nur einige der Stichworte in diesem Zusammenhang.
Welche Bedeutung kann ITSM angesichts dieser Veränderungen noch haben? Muss es selbst agiler werden? Oder kommt es künftig nur noch in den Systems of Record, also den großen, auf stabilen Betrieb ausgelegten, langlebigen Enterprise-Systemen zum Tragen? Um solche Themen zu diskutieren, trafen sich auf Einladung der COMPUTERWOCHE Vertreter von fünf ITSM-Lösungsanbietern sowie Steven Handgrätinger, Vice President beim Systemhaus Bechtle und zugleich Vorstandsvorsitzender des deutschen itSMF (IT Servive Management Forum), das sich die Förderung von Governance-Regeln und Policies für das ITSM zum Ziel gesetzt hat.
Totgesagte leben länger
Wie Handgrätinger beteuerte, hat sich die Dachorganisation des itSMF ernsthaft mit der eigenen Rolle auseinandergesetzt: "Uns haben ja viele schon totgesagt", bekannte der itSMF-Vorstand. Unter anderem habe sich der Verband sogar gefragt, "ob wir nicht besser das IT aus unserem Namen streichen sollten". Aber genau das sei der falsche Ansatz, "denn eigentlich wird in den Unternehmen derzeit alles zu IT."
Deshalb habe sich das Forum nun vorgenommen, "die richtigen Antworten auf die Fragen eines digitalen Betriebskonzepts zu finden", wie Handgrätinger es formulierte. Und wie könnten diese Antworten aussehen? - "Wir brauchen Agilität und Geschwindigkeit auf Basis von Service-Management." Und dazu gehöre auch ITIL. Das sei zwar nicht die "eierlegende Wollmilchsau, aber es biete eine breite Palette von Best Practices, aus denen sich schließlich jeder das heraussuchen könne, was er für seinen Geschäftserfolg brauche.
Wann lohnt sich der ITSM-Aufwand?
Im Prinzip stimmten die - sämtlich aus der ITSM-Industrie stammenden - Experten dieser Einschätzung zu - mit gewissen Einschränkungen allerdings. So postulierte Ingo Bollhöfer, Managing Director bei PCMS.helpLine Software, ITIL müsse für Nicht-ITler so übersetzt werden, dass diese Sinn und Nutzen verstehen.
Ein anderer Teilnehmer der Runde erinnerte daran, dass sich außerhalb der Kern-IT sehr wohl Widerstände gegen standardisierte Prozesse regen könnten: Martin Landis, heute Business Unit Manager bei der USU AG, hat vor einigen Jahren auch einmal einen Start-up-Ableger des Unternehmens geführt. Dort habe man zumindest die "schwergewichtigen" ITIL-Prozesse eher kritisch gesehen.
"Das, was ITIL zum Beispiel im Change- und Release-Management beschreibt, ist für die agile Welt zu starr", stellte Landis klar. "Solche Prozesse taugen nicht, um zu Beginn eines agilen Projekts DevOps-Umgebungen oder hybride Infrastrukturen zu managen." Er habe seinerzeit festgestellt, dass eine agile Umgebung auch ohne solche Prozesse und Standards funktionieren kann, zumindest für eine gewisse Zeit. Schließlich gehe ja durchschnittlich nur eins von zehn Projekten tatsächlich in Betrieb.
Agil und ITSM muss kein Widerspruch sein
Allerdings wollte Landis die Vorteile eines strukturierten ITSM auch für agile Projekte nicht pauschal in Abrede stellen: "Das kann die Entwicklung in agilen Projekten auch entscheidend beschleunigen. Wenn beispielsweise die Entwickler über einen zentralen Service-Shop vollautomatisiert und in Sekundenschnelle Cloud-Ressourcen bestellen, verändern oder auch wieder stoppen können, ist das sehr hilfreich."
Fazit der Runde: ITSM und agil müssen keine Gegensätze sein. Zu hinterfragen ist allerdings immer: Zu welchem Zeitpunkt, unter welchen Umständen und für welche Prozesse lohnt es sich, ein IT-Service-Management aufzusetzen? Und wie können die Unternehmen zweigleisig fahren, also bestimmte Projekte zumindest in der Anfangsphase auch mal am Standardprozess vorbei handhaben, ohne damit gleich das gesamte Service-Management über den Haufen zu werfen?
Bimodal - mit und ohne ITSM
Die letztgenannte Frage ist vor allem für solche Unternehmen wichtig, die eine "IT der zwei Geschwindigkeiten" eingerichtet haben. Diese - auch bimodale IT genannte - Form der IT-Organisation geht davon aus, dass nicht-lineare, sprich: kurzfristig umgesetzte, experimentelle und meist stark kundenbezogene Anwendungen nicht unbedingt denselben Standards unterworfen werden müssen wie langlebige, auf Zuverlässigkeit gepolte Enterprise-Systeme.
Als Urheber des "bimodalen" Modells gilt das Marktforschungs- und Beratungsunternehmen Gartner. Dessen Konkurrent Forrester Research, schien sich dieser Empfehlung anfangs anzuschließen und sprach in diesem Zusammenhang von Begriffen wie "Systems of Record" und "Systems of Engagement". Allerdings sind sich die Forrester-Analysten mittlerweile gar nicht mehr so sicher, ob diese Organisationsform wirklich der Weisheit letzter Schluss ist.
Auch unter den IT-Entscheidern in den Anwenderunternehmen gibt es mittlerweile viele, die zumindest eine strikte Trennung der beiden Bereiche ablehnen. Ihrer Ansicht nach steigert die Zweigleisigkeit die Komplexität der IT-Organisation; außerdem berge sie Gefahr einer "Zweiklassengesellschaft".
Bimodal verursacht mehr Komplexität
Ottmar Höhenberger, Geschäftsführer bei Omninet Solutions, kritisierte diesen Ansatz ebenfalls: "Ich brauche keine zwei Geschwindigkeiten, sondern eine flexible Bandbreite und cross-funktionale Rollen", konstatierte er. "Bimodale IT heißt höhere Komplexität, und die ist für mich konträr zu einer pragmatischen und agilen Kundenausrichtung."
Mehrheitlich waren sich die eingeladenen Experten allerdings darin einig, dass es in den meisten Unternehmen zumindest zwei Typen von IT-Projekten und -Systemen gibt, die hinsichtlich der IT-Service-Prozesse unterschiedlich zu handhaben sind. itSMF-Vorstand Handgrätinger outete sich sogar als "Fan des bimodalen Organisationsmodells": Es gebe in den Konzernen und Verwaltungen "immer Bereiche, die in einem kreativen Umfeld neue Lösungsansätze schnell entwickeln möchten".
Wie Handgrätinger ergänzte, bringt eine IT im - dezidiert agilen - "Modus II" auch neue Betreiberformen, beispielsweise Cloud-Lösungen, mit sich, was wiederum zu Lasten von formalen Prozessen für Beschaffung und Service-Management gehen könne. Der Anbieter der Cloud-Software hingegen, da ist sich der Experte sicher, betreibe selbstverständlich ein striktes ITSM.
Die Zukunft des ITSM
Stichwort: Anwendungen aus der Cloud - für die anwesenden Vertreter der Tool-Industrie gehören die längst zum IT-Alltag: Ausnahmslos alle Teilnehmer reklamierten für sich, den Bezug ihrer Produkte aus dem Netz und im Abonnement zu offerieren.
Nicht ganz so selbstbewusst waren die Softwarehäuser hinsichtlich ihrer Unterstützung für das Management hybrider Umgebungen oder der Handhabung einer bimodalen IT auf der Kundenseite. Auch das Internet of Things (IoT) sowie Machine-Learning- und andere AI-Systeme (Artificial Intelligence) ließen sich derzeit nur mit viel Eigenaufwand in ITSM-Umgebungen einbinden, klang in der Diskussion durch. Und diesen Aufwand scheuten nach den Erfahrungen der Experten derzeit noch viele Unternehmen.
Selbst vergleichsweise simple und naheliegende Funktionen wie die Einbindung von Wissens-Management sind oft noch Mangelware, wie Bollhöfer bestätigte: "Lösungswissen ist in den ITSM-Systemen häufig nicht optimal hinterlegt." Was wirklich schade sei, denn "damit fehlen die Grundlagen für bessere Lösungsquoten, aber auch wichtige Voraussetzungen für den sinnvollen Einsatz von AI und Bots im IT-Service-Management."
In nicht allzu ferner Zukunft werden die ITSM-Tools möglicherweise auch Big-Data-Analytics-Komponenten aufweisen. Dazu Landis: "Die gleichen Mustererkennungsmechanismen wie bei den im Maschinenbau eingesetzten Predictive Analytics-Anwendungen lassen sich auch im Service-Management verwenden." Beispiele aus dem Security-Bereich gebe es schon: "Aber da sind wir noch im Forschungsstadium."