Transition – startet früher, als man denkt

Der Transition Mode of Operation (TMO) ist eine gut getarnte Herausforderung im IT-Sourcing. Er fällt kaum auf und wird oft übersehen, weil er parallel zum auslaufenden Current Mode of Operation (CMO) und zum hochfahrenden Future Mode of Operation (FMO) verläuft. Viele Unternehmen verlassen sich in dieser kritischen Situation auf die Kooperationsbereitschaft und Expertise der Provider. Meistens hat der Kunde klare SLAs mit ihnen und fühlt sich dadurch abgesichert. Doch nur die wenigsten Dienstleister sind Experten für diese Übergangsphase – oder fühlen sich dafür verantwortlich.

In der Regel sind im TMO die Techniker am Zug, sie ziehen Server von A nach B und prüfen, ob Apps laufen und der Zugriff klappt. Das strukturelle Gerüst für die Services wird jedoch häufig vernachlässigt, weil die Zeitpläne falsch angelegt sind. Denn die Provider orientieren sich an dem Tag, an dem der letzte Server migriert und das letzte Notebook installiert wird – der vollständige FMO. Erst jetzt, so die falsche Annahme, müssen die Prozesse und Umsysteme anlaufen.

Service Commencement Days

Wovon sich Auftraggeber und alle beteiligten Provider dringend verabschieden sollten, ist der Fokus auf den einen Stichtag, an dem die Services übergehen. Die Sourcing-Realität sieht anders aus, denn der Future Mode beginnt mit dem Tag, an dem der erste Service vom neuen Provider angeboten wird. Dann folgen ein paar Monate mit vielen kleinen Service Commencement Days bis zum Full FMO. In dieser Phase geht die operative Verantwortung schrittweise vom bestehenden zum neuen Dienstleister über, und damit auch auf dessen Prozesse und Tools. Werden die Service-Support-Prozesse der Provider nicht frühzeitig miteinander verbunden, lebt der Kunde in zwei Welten.

Servicedesk als einheitlicher Ansprechpartner

Für den Servicedesk als Beispiel bedeutet dies konkret: Er muss zu jedem Zeitpunkt im TMO als Single Point of Contact agieren. Sonst müssen die Enduser bei einem Problem entscheiden, wo sie anrufen – ein klares No-go. Ist dies beim PC-Rollout des neuen Dienstleisters nicht gewährleistet, rufen die Anwender den Bestands-Provider an, der jedoch die neuen Rechner nicht kennt. Daher müssen alle Tickets weitergeleitet und alle benötigten Informationen über die Systeme ausgetauscht werden. Wird der Single Point of Contact umgeschaltet, geht es in die andere Richtung: Die Telefonnummern werden geroutet. Dann muss der neue Provider die Tickets erkennen und an seinen Vorgänger zurückleiten, falls Arbeitsplätze oder Apps noch nicht migriert sind.

Technik, Tools und Prozesse umziehen

Im Transition Mode of Operation geht es nicht nur um den technischen Übergang, sondern um den Aufbau und gegebenenfalls die Koppelung aller Prozesse. Sie müssen ab dem ersten migrierten System ebenfalls funktionieren. Ist dies nicht gewährleistet, beginnt der Kunden allmählich zu verstehen, dass er in den Flitterwochen keine Verfügbarkeitsreports und einen schlechten Support bekommen wird. Ab dem Moment bereuen er und seine Stakeholder, sich für diesen Provider entschieden zu haben – denn nur eine für die Kunden unsichtbare Transition ist eine gute Transition.

Zu den Prozesse und Systemen, die an Tag 1 des Übergangs bei allen Providern grundsätzlich bereitstehen müssen, zählen:

• Das Monitoring aller Systeme (alt/neu);
• Die Ticket-Systeme und das Routing;
• Backup-Systeme;
• Ein verbrauchsabhängiges Billing;
• WAN-Verbindungen;
• Automatic Incident Creation mit Correlation Rules;
• Security-Setups wie Identity & Access Management (IAM) oder Privilege Access Management (PAM);
• Das SLA-Reporting;
• …

Wenn der Move to Production stockt

Da die viele High-Level-Pläne das Ende der Transition als den Service Commencement Day ausweisen, sind die Teams der Provider nicht darauf eingestellt, bereits Monate vorher operativ zu funktionieren. Wichtig ist: Das Delivery-Team (Betrieb) muss den TMO managen, nicht das T&T-Team (Projekt). Findet der Move to Production nicht wie geplant statt, fällt der Schatten nicht nur auf die IT sowie deren Provider, sondern auf die gesamte IT-Sourcing-Industrie. Daher sollten alle Dienstleister im TMO an einem Strang ziehen, zumal selten ein Lieferant allein Schuld an der Misere ist. Das grundlegende Problem ist die Erkenntnis, dass alles schon Monate vorher fertig sein muss – in der Regel wird der falsche Termin anvisiert.

Wer trägt die Verantwortung?

Wenn der Kunde den schlechten Start des TMO nicht akzeptiert und sich dadurch die komplette Transition verschiebt, muss jemand die Rechnung bezahlen: Derjenige, der den schlechten Plan geschrieben hat, oder derjenige der den schlechten Plan akzeptiert hat. Die Krux an der Sache: Wenn Provider ihren Transition-Plan vorlegen, verlassen sich viele Kunden auf die Erfahrung der Profis und geben ihn frei. Hiermit übernehmen sie jedoch unbewusst die Verantwortung für die Richtigkeit des Planes. Damit ist der Provider zwar rechtlich auf der sicheren Seite. Auch wenn diese Einstellung nachvollzogen werden kann – nachhaltig für die IT-Sourcing-Industrie ist sie nicht.

Die richtige TMO-Planung trainieren

Der TMO ist eine Phase, in der der wahre Reifegrad der Provider zum Tragen kommt – oder eben nicht. Allerdings ist es für alle Beteiligten schwierig, falsche Pläne nachträglich anzugleichen. Mit Glück kann man externe Experten einbeziehen, um die verfahrene Situation rechtzeitig aufzulösen und die Probleme zu lindern. Manchmal ist es auch dafür zu spät. Meiner Meinung nach ist es im Interesse aller Provider, einen professionellen TMO auf die Beine zu stellen. Hierzu wäre ein gemeinsamer Austausch von Transition-Profis hilfreich, um von Best Practices zu lernen. Ziel ist nicht nur, den Ruf der Sourcing-Industrie zu stärken, sondern das Leben der Kunden und Kollegen zu erleichtern. Denn jeder ist von Defiziten im TMO betroffen.

Wer Interesse hat, sich über das Thema auszutauschen und/oder eine übergreifende Qualitätsinitiative zu starten, kann sich gerne bei mir melden. Ich freue mich auf Feedback!