Service-Desk-Projekte zum Erfolg führen

„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.