Fragt man die Mitarbeiter im IT-Support, ob sie mit ihrem Service-Desk-Tool zufrieden sind, lautet die Antwort im besten Falle "Geht so". Warum kommt hier so gut wie nie Begeisterung auf? Liegt das vielleicht daran, dass der Service-Desk nur interessant ist, wenn er einmal nicht funktioniert? Oder daran, dass die Verantwortlichen falsche Erwartungen an das Tool stellen? Erwartungen, die das Werkzeug gar nicht erfüllen kann - nicht, weil es technisch minderwertig wäre, sondern weil es falsch implementiert wurde?
Foto: Kjetil Kolbjornsrud - shutterstock.com
Auf die Frage, was ein Service-Desk-Tool leisten soll, gibt es einige allgemeingültige Antworten. Es soll die Arbeit der Service- und Supportspezialisten vereinfachen, die Zusammenarbeit innerhalb der IT sowie zwischen IT und Kunde verbessern, Art und Dauer bestimmter Tätigkeiten transparent machen, Expertenwissen - zum Beispiel über eine Knowledge Base - verbreiten, durchgängige Prozesse definieren und den Arbeitsaufwand verringern.
Soweit die Theorie. Im gelebten Alltag ist es häufig so, dass das vorhandene Werkzeug die Arbeitsweise der Mitarbeiter eigentlich gar nicht unterstützt, weil die abgebildeten Abläufe den Wunschprozessen des Managements entsprechen und wenig mit den tatsächlich gelebten Prozessen zu tun haben. Vor diesem Hintergrund überrascht es, dass "Unzufriedenheit mit dem Tool" die häufigste Antwort auf die Frage ist, warum Unternehmen ihr Service-Management erneuern sollten. Als ob ein anderes Werkzeug etwas an den Prozessen ändern würde! Zweitwichtigstes Wechselmotiv ist die Absicht, den IT-Service-Management-Standard ITIL mit Hilfe eines Tools einzuführen. Aber wie soll das gelingen? Ein Tool bleibt ein Tool - an den Prozessen ändert es erstmal gar nichts.
Alte ITSM-Gewohnheiten
Tatsächlich laufen entsprechende Projekte meist so: Der Systemintegrator, der mit der Einführung beauftragt wurde, will von seinem Kunden eine Vorgabe für die gewünschte Konfiguration. Der aber ist mit dem Tool noch gar nicht richtig vertraut. Wenn er nun sagen soll, wie er es implementiert haben möchte, kann er sich nur an dem orientieren, was er kennt, sprich: am vorhandenen Tool. Damit bleibt die Innovation der neuen Lösung auf der Strecke.
Dazu ein simples Beispiel: Das neue System verfügt über eine Warenkorb-Funktion, mit der IT-Services online bestellt werden können. Das Unternehmen hat zum Erfassen der Service-Anforderungen bislang aber immer Tickets genutzt. Also wird er diese Anforderung auch an das neue Tool stellen. Und weil der Kunde König ist, wird der Berater das auch so umsetzen. Die neue Software, die dafür angeschafft wurde, das Service-Management zu vereinfachen und zu verbessern, bietet also keinen Warenkorb, sie wird vielmehr umständlich verbogen, damit der Support im gewohnten Stil weiterarbeiten kann.
Aber es kommt noch schlimmer: Damit das neue System der alten Lösung entspricht, ist meist ein aufwändiges Customizing notwendig. Und das dürfte der Philosophie des neuen Werkzeugs auch noch widersprechen. So entsteht dann die nächste Dauerbaustelle. Oft genug werden die Abläufe im Service-Management auch von Mitarbeitern definiert, die gar nicht für Service und Support zuständig sind. Diejenigen, die später tatsächlich damit arbeiten, müssen sich dann mit konstruierten Komplexitätsmonstern herumschlagen, die wenig mit ihrer Arbeitswirklichkeit zu tun haben.
- Matthias Roth, Business Consultant, FNT GmbH
"Es gibt in den Unternehmen in der Regel keinen expliziten Digitalisierungs-Verantwortlichen, der als einzelne Person für alles zuständig ist. So wie man die klassischen IT- und Business-Services gebaut hat, sollte man auch die neuen Themen wie Enterprise Service Management KI oder IoT angehen: bereichsübergreifend und vorhandene Silos integrierend." - Pierre-Andre Aeschlimann, EMEA Sales & Solution Strategy, Cherwell
"ITSM ist ein essenzieller Baustein bei der Umsetzung der Digitalen Transformation, denn es trägt in der Regel dazu bei, dass die IT ein Fundament hat, auf dem sie neue Geschäftsprozesse und Services bauen und integrieren kann. Wenn dieses Fundament fehlt, wird die IT sehr schnell zum bloßen Erfüllungsgehilfen der Fachbereiche, indem sie einfach nur eine Anforderung über den Zaun geworfen bekommt." - Alexander Betti, Executive Solution Architect, USU GmbH
"Ich kann nicht erkennen, dass ITSM out of fashion ist. Ganz im Gegenteil: Wenn es heute heißt, dass alles disruptiv ist, gilt das nicht für letztendlich saubere und durchgängige IT- und Geschäftsprozesse. Die IT steht im Zuge der Transformation unter einem enormen Kosten-, Anpassungs- und Modernisierungsdruck, und sie muss sich mehr denn je als interner Service-Provider beweisen. Da helfen ITSM und ITIL schon ungemein weiter." - Hagen Neulen, Key Account Manager EAM & Mobile, Axino Solutions GmbH
"Das Problem bei ITSM im Kontext der Digitalen Transformation ist die Geschwindigkeit der Veränderungen – weniger in technologischer Hinsicht, sondern eher im Hinblick auf den Mindset der Unternehmen beziehungsweise deren Erwartungshaltung. Die entscheidenden Fragen sind doch: Wie viel Geduld hat man grundsätzlich bei einem Digitalisierungs-Projekt? Was passiert, wenn der verantwortliche CIO/CDO nach zwei Jahren das Unternehmen wieder verlässt? Und warum scheitern so viele Unternehmen daran, ein erfolgreiches Leuchtturmprojekt, also einen neuen Service oder einen entwickelten Prototypen in ein skalierbares Business-Modell umzuwandeln oder ein serienreifes Produkt auf den Markt zu bringen?" - Korinna Durmeyer, Senior Sales Manager Service Management, Ivanti
"Unternehmen sind nur dann in der Lage, die Digitale Transformation erfolgreich zu bewältigen, wenn es eine vom Business klar definierte Geschäftsstrategie gibt, aus der sich die Prozesslandschaft und IT-Strategie ableiten lässt. Federführend in der Umsetzung ist dann zwangsläufig der CIO – aber in enger Interaktion mit den Fachbereichen. Vor diesem Hintergrund werden wir immer stärker als Plattform-Anbieter und Berater wahrgenommen, wenn es darum geht, Prozesse und IT-Infrastruktur zu konsolidieren." - Peter Schneider, Chief Product Officer, Efecte
"Wenn man als Anbieter den Plattform-Gedanken als Geschäftszweck verfolgt, sollte man aber tunlichst dem Kunden nicht nur seine Suite aufzwingen wollen, sondern zunächst den strategischen Vorteil und die Business-Relevanz erklären. Ausgangspunkt dabei muss immer der konkrete Bedarf des Kunden sein. Wir sind da natürlich häufig mit einem „Build-to-Purpose-Ansatz“ unterwegs - wenngleich wir eigentlich, wann immer möglich, den „Build-to-evolve“-Ansatz favorisieren. Ziel sollte es stets sein, dem Kunden eine flexible, skalierbare Plattform bereitzustellen, die es ihm ermöglicht, auch zukünftige Services zu integrieren." - Michael Geyer, Member of the Executive Board, OMNINET
"Alle Anwenderunternehmen bewegen sich in der so genannten VUCA-Welt. Da hilft einerseits das ITIL-Framework nach wie vor, andererseits wird sich die ITSM-Systemlandschaft ein großes Stück weit verändern müssen – weg von starrer Ticketing-Software hin zu flexiblen Low-Code-Business-Process-Ökosystemen."
Service Desks und der "sonstige" Ärger
Rechtzeitige Schulungen könnten solche Implementierungsfehler abfedern. Aber sie sind in den meisten Unternehmen "nice to have". Am Training der Mitarbeiter wird gerne gespart. So lernen diese nie, richtig mit dem Tool umzugehen. Umständliche Handhabungen und Workarounds schleichen sich ein, die dann irgendwann als Standard etabliert sind.
Ein Beispiel dafür liefert die Kategorisierung von Tickets. Können Mitarbeiter die Frage richtig beantworten, ob es sich bei einem Problem um einen Hardware-, Software- oder Infrastrukturfehler handelt, lassen sich Störungsmeldungen ohne Umwege den jeweils zuständigen Technikexperten zuweisen. Außerdem werden statistische Auswertungen über die Art und Häufigkeit von Fehlfunktionen einfacher und präziser, was das Problemmanagement unterstützt.
Dazu müssten die Mitarbeiter aber mithilfe von Schulungen eine Vorstellung davon bekommen, unter welcher Kategorie sie welche Störungen erfassen sollen. Anderenfalls werden sie der Einfachheit halber die meisten Störungen unter "Sonstiges" verbuchen - unter einer Kategorie also, die es bei vernünftiger Schulung gar nicht geben müsste. In vielen Service-Desks fallen zwei Drittel der Störungen unter Sonstiges. Wie sich das auf die Serviceprozesse und das Problemmanagement auswirkt, lässt sich leicht ausmalen. Die erhoffte Transparenz und Auswertbarkeit bleibt genauso auf der Strecke wie der übersichtliche und nachvollziehbare Prozess.
- Carsten Owerfeld, iET Solutions
DevOps steht bei ITSM aktuell noch am Anfang. ITIL 4 wird hier entscheidende Fortschritte bringen. Doch für einen flächendeckenden Siegeszug ist auch ein kultureller Wandel erforderlich, wie zum Beispiel die Bereitschaft, Fehler zuzulassen, diese schnell zu finden und zügig zu beheben. - Heiko Maneth, BWI GmbH
Agile Methoden wie Scrum sind bei genauerem Hinsehen im Grunde nichts Neues. Bestimmte agile Elemente waren auch in früheren ITIL-Versionen adressiert, aber nicht hinreichend spezifiziert. Darüber hinaus heißt „agiler” nicht automatisch „besser” und darf nicht zur Generalantwort auf ineffiziente Prozesse werden. - Norbert Huber, Materna
Der Siegeszug von KI und Machine Learning ist im ITSM nur eine Frage der Zeit, auch wenn die Hemmschwelle beim Kunden hier noch relativ hoch ist. Am Ende wird die Technologie aber immer nur so gut sein wie die Daten, mit der sie gefüttert wird. Doch es lohnt sich definitiv, verstärkt darin zu investieren. - Gerald Haberecker, Axios Systems
Das IT-Service-Management breitet sich auf immer mehr Abteilungen aus. Neben CRM und ERP bildet das Service-Management mittlerweile die dritte tragende Säule im Unternehmen. Eine immer wichtigere Rolle spielen dabei natürlich auch die Automatisierung der Prozesse und Zukunftsthemen wie KI oder Machine Learning. - Felix Heintz, Topdesk Deutschland
Vor zehn Jahren war das Thema ITSM ausschließlich für die IT-Abteilung relevant, heute beschäftigen sich zum Beispiel auch HR oder das Facility-Management damit. Das führt zu mehr abteilungsübergreifenden Berührungspunkten, wodurch zwangsläufig auch eine andere Sprache gesprochen werden muss. Als Dienstleister muss man heute mehr darauf achten, Formulierungen zu finden, die überhaupt verstanden werden. - Sebastian Welke, scienITec
ESM kann die Brücke zwischen Compliance-Vorgaben und deren Umsetzung im Tagesgeschäft schlagen. Gelingt dies, macht ESM das abstrakte Thema Compliance auf operativer Ebene handhabbar. Beispiel DSGVO: Die Betroffenenanfrage eines Kunden ist – stark vereinfacht – ein Service Request. - Robert Scholderer, Scholderer GmbH
Der hohe Innovationsgrad, der mit der Digitalisierung einher geht, produziert kontinuierlich eine Vielzahl an neuen Services, die entsprechend beschrieben werden müssen. Prominentestes Beispiel hierfür ist der Einsatz von KI. Dieser scheitert jedoch – bedauerlicherweise – häufig an der Investitionsbereitschaft: Wenn ein CIO seine Hauptaufgabe darin sieht, IT-Kosten einzusparen, ist es kaum möglich, die dafür nötigen architektonischen Veränderungen umzusetzen. - Alexander Wachtel, ESCDE
Aus Kundenprojekten wissen wir, dass durch den Einsatz einer KI die Servicelandschaft innerhalb eines Unternehmens eine zufällige Komponente erhält. Dadurch steigt nicht nur die Komplexität in der korrekten Ausführung, sondern auch der Erklärungsbedarf bei den Mitarbeitern. Die Ungewissheit durch den Einsatz von KI-Komponenten wird zunehmen, wenn das Unternehmen nicht proaktiv gegensteuert.