„Wer immer tut, was er schon kann, bleibt immer das, was er schon ist.“ Das sagte schon Henry Ford. Übertragen auf das Thema Service-Desk-Projekte bedeutet es, dass bei gleichbleibenden Vorgehensweisen keine Verbesserung bewirkt werden kann. [...]
Auch dann nicht, wenn IT-Entscheider glauben, mit der Einführung eines neuen Service Desk-Tools alle Probleme lösen zu können. Denn die versprochenen Fortschritte bleiben auch mit neuem Tool oft genug aus. Warum ist das immer wieder so?
In der IT-Welt ist nichts von Dauer. So heißt es auch bei IT-Entscheidern oft genug Bäumchen-wechsel-dich. Dabei hinterlassen diese ihrem Nachfolger oft ein brandheißes Eisen: Das Service Desk Tool. Um bei Amtsantritt reinen Tisch zu machen und mit Glanz und Gloria neu durchzustarten, ist es zu einer Art Tradition geworden, das vorhandene Tool in Frage zu stellen und ein Neues einzuführen.
Das löst bei den Mitarbeitern des IT-Supports in der Regel ein unschönes Deja-Vu aus. Denn die Mär vom perfekten Service Desk Tool haben sie schon allzu oft gehört – ohne jedoch bei einem Wechsel jemals in den Genuss der versprochenen Wunderlösungen gekommen zu sein.
Und dennoch: Alle Jahre wieder wird mit großem Getöse – vor allem aber mit hohem Implementierungsaufwand – ein neues Service Desk Tool eingeführt. Ganz nach dem Motto: Never change a not running system.
Warum der ganze Aufwand?
Seien wir einmal ehrlich: Das Haupt-Ziel solcher Hauruck-Aktionen am Service Desk ist die Image-Verbesserung der IT innerhalb des Unternehmens. Die Verbesserung von Kennzahlen – nebensächlich. Schließlich befindet sich die IT in der Rolle eines exklusiv en Service-Dienstleisters gegenüber anderen Abteilungen. Und Neuerungen direkt am Service Desk sind nun mal am schnellsten sichtbar.
Doch was oft außer Acht gelassen wird, ist die enorme Herausforderung bei der Umsetzung einer solchen Implementierung. Ähnlich wie bei einer Herz-OP muss die Tool-Migration nämlich im laufenden Betrieb erfolgen, will man nicht den Stillstand riskieren.
Man braucht nicht viel Vorstellungskraft, um sich vor diesem Hintergrund ausmalen zu können, wie die Reaktion der Support-Mitarbeiter ausfallen dürfte, wenn wieder einmal ein neues Tool angekündigt wird.
Weshalb der Misserfolg vorprogrammiert ist
Warum gelingt es oft nicht, Service-Desk-Migrationen erfolgreich durchzuführen? Wie immer sind die Gründe hierfür vielfältig. Das beginnt bereits mit der Handhabe des implementierenden Systemintegrators.
Statt dem Kunden aus Best-Practice-Ansätzen heraus die ideale Konfiguration vorzuschlagen, fragen die ausführenden Consultants den Kunden nach seinen Wünschen. Die Folge dieses verkehrten Ansatzes: Der Kunde macht kaum umsetzbare oder sinnlose Vorgaben. Klar, woher soll er es besser wissen? Er kennt das neue Tool ja am wenigsten.
Ein genauso beliebter wie fataler Fehltritt: Die Übernahme alter Konfigurationen und Ticket-Altdaten aus dem vorherigen System. Mit aufwändigem Customizing wird damit aus ‚Neu‘ ‚Alt‘ gemacht, um auch ja im gewohnten Schema weiterarbeiten zu können. Das Scheitern ist damit wortwörtlich vorprogrammiert.
Zu guter Letzt noch ein paar weitere beispielhafte Schmankerl aus der Fehlerkiste:
- Die Aufsetzung theoretischer Prozesse, die mit der Realität nichts zu tun haben und Mitarbeiter eher vor den Kopf stoßen als ihnen weiterzuhelfen
- Zu wenig oder gar keine Schulung der Mitarbeiter
- Ablehnung sinnvoller Prozess-Standards wie ITIL
- Fehlende Verantwortlichkeiten
Ursachensuche durch Perspektivwechsel
Freudentränen löst ein Toolwechsel bei erfahrenen Support-Mitarbeitern also normalerweise nicht aus. So stellt sich also die Frage, weshalb wir es einfach nicht schaffen, die Personen, die täglich mit einer solchen Lösung arbeiten, für Migrationsprojekte dieser Art zu begeistern.
Betrachten wir das Thema einmal mit den Augen eines Support-Mitarbeiters. Dabei wird schnell klar: Ein Service Desk-Tool spart keine Zeit, sondern kostet ihn welche. Dabei ist Zeit seine wertvollste Ressource. Schließlich landen ständig neue Fälle auf seinem Tisch und das Telefon klingelt in einer Tour, während sein Erfolg an der Anzahl der gelösten Tickets in einem bestimmten Zeitraum gemessen wird.
Aus seiner Perspektive sind somit die Pflichten im Zusammenhang mit der Tooleinführung – wie zum Beispiel die Änderung seiner Arbeitsweise und die Dokumentation – vor allem eins: ärgerlich und zeitraubend. Wirklichen Nutzen hat allenfalls das Management in Form von verbesserter Ressourcenplanung und -steuerung.
Das Migrationsprojekt gerät damit schnell zum Desaster. Von den versprochenen Mehrwerten ist am Ende jedenfalls keine Rede mehr. Zumindest so lange, bis ein neuer Messias am Service-Desk-Horizont erscheint und das Drama von vorne losgeht.
Auf zu neuen Ufern
Stolperfallen im Projekt können mit der richtigen Herangehensweise umgangen werden. Wenn der von Ihnen beauftragte Systemintegrator beispielsweise Anpassungen vorschlägt, hinterfragen Sie diese und überdenken lieber die zugrundeliegenden Prozesse, anstatt überflüssiges Customizing durchführen zu lassen.
Wehren Sie sich in diesem Zusammenhang auch nicht gegen sinnvolle Standards wie ITIL. Diese liegen heutzutage ohnehin so gut wie allen Tools zugrunde. Eine komplette Tool-Anpassung an Ihre Prozesse und ein Verbiegen der zugrundeliegenden Philosophie bringen Ihnen dagegen keine Vorteile.
Diese Ratschläge bringen den Unternehmen jedoch nichts, wenn Sie die Bedürfnisse Ihrer Support-Mitarbeiter außer Acht lassen. Denn nur, wenn es Ihnen gelingt, diese für Ihr Projekt zu begeistern, wird das auch nachhaltigen Erfolg haben.
Das bedeutet: Schaffen Sie echte Mehrwerte für Ihre Mitarbeiter! Mit einer einfacheren Dokumentation oder einer generellen Prozessänderung locken Sie jedenfalls niemanden hinter dem Service-Desk-Ofen hervor. Stehen also bei der Tool-Migration wieder nur diese Themen im Fokus, werden Sie mit wehenden Fahnen untergehen und die angestrebten Ufer rücken in weite Ferne.
Die Lösung
Wenn es um Motivation am Arbeitsplatz geht, ist es für die meisten Mitarbeiter am wichtigsten, bei den Bedürfnissen des beruflichen Alltags abgeholt zu werden. Also kann auch erst, wenn diese Voraussetzung erfüllt wird, der Funke der Begeisterung überspringen.
Der Schmerz eines Support-Mitarbeiters ist rasch ausgemacht: Er möchte schnell, effektiv und unkompliziert seine Kompetenz beweisen – doch warum ist das noch nicht so und wie kann das gelingen?
Ein Cockpit im Service Desk
Zur Veranschaulichung stellen wir uns den Service Desk einmal als Flugzeug vor, mit ihm als Flugkapitän. Und er müsste das Flugzeug nun so fliegen, wie er bisher seinen Arbeitsalltag bewältigt. Das würde bedeuten: Keinerlei Live-Informationen über wichtige Parameter, beispielsweise über den Flugverkehr auf seiner Route.
Außerdem stünden ihm ausschließlich sehr rudimentäre ‚Tools‘ zur Verfügung: Ein einfacher Taschenkompass für die Ermittlung der Flugrichtung und ein Windmessgerät, das er zu allem Überfluss auch noch selbst aus dem Fenster halten müsste.
Sie finden, der Vergleich hinkt? Leider sieht die Realität tatsächlich so aus: Der Blindflug startet bereits beim Anruf eines Anwenders. Per Fragenkatalog oder Remote-Zugriff muss der Support-Mitarbeiter sich ein Bild vom aktuellen Zustand des betroffenen PCs machen. Und mithilfe einer unüberschaubaren Sammlung unterschiedlichster Tools darf er sich dann die mögliche Ursache zusammenreimen. Von einer Lösung ganz zu schweigen.
Versuchen wir nun einmal, die Flugzeugmetapher auf einen möglichen Lösungsansatz zu übertragen. Denn wäre es nicht naheliegend, dem Support-Mitarbeiter eine Art Cockpit zur Verfügung zu stellen, das – wie bei einem echten Flugzeug – in Echtzeit alle für ihn relevanten Informationen bündelt?
Eines, das Funktionen beinhaltet, die die Beseitigung von Störungen ermöglicht? Und – als Tüpfelchen auf dem i – sogar die Dokumentation nahezu automatisch übernimmt, ähnlich einem Flugschreiber? Eine solche Lösung gibt es tatsächlich, aber noch handelt es sich um eine Innovation, die man am Markt suchen muss.
Pechvogel auf Glücksuche
Leider schlägt der IT-Verantwortliche auf der Suche nach dem Service Desk-Glück häufig schon bei der Ausschreibung des Projekts den Weg ins Verderben ein. Grund dafür: Alte, immer wieder kopierte Pflichtenhefte externer Berater, denen schlichtweg aussagekräftige Punkte für eine ordentliche Marktsondierung fehlen.
Die dort beinhalteten Tool-Anforderungen basieren normalerweise auf antiquierten ‚ITIL-Abfragen‘, die mittlerweile ohnehin zum gängigen Standard gehören. In der Folge fallen Anbieter, die innovative Lösungen im Sinne des Kunden anbieten, einfach durchs Raster, da sie Aspekte vorweisen, die nicht gefordert sind.
Zu teuer sind sie damit in der Regel auch. Ergebnis: Neue Ansätze mit multifunktionalen Cockpit-Lösungen bleiben unbeachtet – ebenso wie die Bedürfnisse des First-Level-Supports. Der Absturz des IT-Pechvogels ist damit absehbar.
Der Schlüssel zum Erfolg
Anstatt eines kompletten Wechsels des Service Desk-Tools reicht es manchmal bereits, die vorhandene Lösung um ein passendes Tool zu erweitern – beispielsweise mit der Anwendung ‚First Aid Service Desk (F4SD)‘ des Softwareherstellers und Systemintegrators Consulting4IT, welche als Ergänzung zu gängigen Service Desk-Tools konzipiert wurde.
Mittels eines übersichtlichen Cockpits kumuliert F4SD alle für den First Level Support wichtigen Informationen und bietet darüber hinaus direkte Lösungsmöglichkeiten für bis zu 80 % häufig auftretender Standardfälle. Besonders sinnvoll ist F4SD in Kombination mit dem Ticket-System von Matrix42.
Ein spezielles Add-on zur Integration ermöglicht Ursachensuche, -behebung und Ticketbearbeitung komplett im F4SD-Cockpit.
Lösungen wie diese bieten dem Support-Mitarbeiter genau jene Vorteile, die er bislang vermisst haben dürfte. Endlich wird er in die Lage versetzt, Störungsursachen sofort zu erkennen und Standardfälle mit minimalem Aufwand zu beheben. Er wird zum sprichwörtlichen Helden für die Anwender und ist nicht mehr der Prügelknabe der IT. Begeisterung garantiert.
Tipp: Für ein Projekt dieser Größenordnung empfiehlt sich außerdem stets ein Systemintegrator mit Fokus auf die Implementierung solcher Lösungen sowie dem Mut, die Dinge auch einmal anders anzugehen. Denn wie eingangs erwähnt, kann es keine Weiterentwicklung geben, wenn man immer nur das gleiche tut. Innovationen und Perspektivwechsel sind der Schlüssel zu Begeisterung und damit zum Erfolg – wenn man sie denn zulässt.
Be the first to comment