Service Desk Nearshoring

Beginnen möchte ich mit einem Exkurs: Laut ITIL® ist der Service Desk ist eine Funktion. In einem rein Prozess-getriebenen Räderwerk ist eine Funktion eigentlich eine Mogelpackung. Nämlich ein Team, dass eigenständig über Know-How verfügen muss und viele Teile der Support Prozesse selbst abwickeln und weiterentwickeln muss. In ITILv3 kommen noch Application Management, Technical Management und IT Operations Management als Funktionen hinzu.

Die Idee von ITIL, eine Sammlung von IT Good Practices auf (Rahmen-)Prozesse zu beschränken, ist ein sehr schönes Konzept. Es bedeutet einen optimalen Spielraum in der Organisation, legt jedoch die Muss-Bestandteile im Ablauf fest. Somit ist es für jede gewachsene IT Organisation anwendbar.

Betrachtet man Funktionen treten auf einmal Prozess-Schnittstellen zu Tage — Mist. Schöne Theorie, jetzt muss Du Dich in der Praxis erweisen. Spaß beiseite, irgendwer in der Organisation muss die Aktivitäten ja ausführen, deshalb kommt es zu diesen Mogelpackungen. Eigentlich sind Service Desk, Application Management, Technical Management und IT Operations Management schöne Beispiele für die Integration. Solche Funktionen gibt es Organisationsspezifisch noch Andernorts. Eigentlich perfekte Ansätze mit ITIL pragmatisch umzugehen, aber leider auch viel Arbeit um Insellösungen zu verhindern. Vor allem bei Nearshoring ist das eine ernstzunehmende Gefahr.

In dem Projekt ging es um die Einführung eines zentralen Service Desks für interne IT Anwender. Da zuvor diverse dezentrale Lösungen etabliert waren, konnte die Konzeption weitestgehend auf der Grünen Wiese aufsetzen. Dies war gleichzeitig auch die Herausforderung, dieses große Projekt musst komplett am Schreibtisch geplant werden.

Die Make-or-Buy-Entscheidung fiel überraschend deutlich zugunsten Eigenfertigung in Osteuropa aus. Auch die Nachbetrachtung bestätigt die damalige Entscheidung, die Kosten waren valide geplant. Die Hauptursache für diesen deutlichen Abstand wird die hohe Fertigungstiefe und die daraus resultierenden Risikoaufschläge der Provider sein.

Dumm war, dass die zugekauften Marktzahlen teilweise 20% von den heutigen Werten entfernt waren. Dies konnte man schon an der Varianz zwischen vergleichbaren Städten erahnen. Die selbst ermittelten Werte lagen viel dichter an der Realität. Entscheidend sind bei einem Service Desk natürlich die Personalkosten, die sehr gut intern abgeschätzt werden konnten. So kam es, dass das Projekt das Budget einhalten konnte.

Glück gehört bei straffen Projektplänen auch dazu: Es konnte sehr schnell ein fähiger Service Desk Chef gefunden werden, der das Recruiting zügig aufbauen konnte. Der Service Desk nahm nahezu pünktlich, mit einer Verzögerung von 6 Tagen zum ursprünglichen Projektplan den Pilotbetrieb auf.

Nach wie vor ist die größte Herausforderung bei einem zentralen Service Desk das Veränderungsmanagement der Organisation darum herum. Der Service Desk darf nicht nur eine Funktion auf einer Insel bleiben. Das wäre ein falsches Verständnis von Funktion. Was ich erstaunlich fand, dass der Emotional Cycle of Change (Service Transition S. 161f) auch vor mir selbst nicht Halt machte. Als einer der Führer des Veränderungsprozesses hatte ich das nicht erwartet:

Eines Abends erwischte ich mich dabei mit sehr hohem Ausstoß „alten“ Aktivitäten nachzugehen. Problem erkannt, abgestellt, kein Problem mehr. Von shock bis acceptance geschätzt einen Arbeitstag, das ist okay 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Dein Kommentar wird manuell freigeschaltet. Ich bitte um Geduld, das kann manchmal etwas dauern.