Managed Services klingen nach einer guten Idee. Jeder macht, was er kann. Der Kunde kümmert sich um sein Kerngeschäft. Die IT-Services kauft er bei einem Provider ein. Der Provider bietet Netzwerk, Application Server, Mail Server, File Server, Storage, virtuell und als Blech, alles gewürzt mit einer fetten Prise Firewalls und Proxys, ein Schuß MDM dazu und oben drauf noch Identity Management. Hochverfügbar im Tier-4-Rechenzentrum.

Ein bisschen kniffliger wird dann der Leistungskatalog. Grundprinzip des Kunden: Ich will alles! Zumindest Kulanz und Flexibilität.Grundprinzip des Providers: Wir machen nur, was im Leistungskatalog beschrieben ist. Wenn der Leistungskatalog aus Sicht des Kunden schlecht verhandelt ist, wird jeder zweite Handgriff des Providers gesondert abgerechnet. Kulanz ist da eher nicht das prägende Stichwort.

Das mag dennoch alles ganz nett funktionieren, wenn das Service Konstrukt im eingeschwungenen Zustand ist, und keiner daran rüttelt. Ein kleiner Change Request hier, eine kleine Erweiterung des Leistungskataloges dort. Leben und leben lassen.

Was vermutlich in keinem Leistungskatalog steht, kann aber passieren. Der Kunde bestellt eine „Mail Migration Notes/Domino nach Outlook/Exchange/O365“. Anfangs denken alle Beteiligten noch „lass kommen“. Die Puzzlesteine werden sich schon irgendwo im Leistungskatalog finden. Aber dann stellt sich heraus, dass das Projekt an den Grundfesten der Managed Services rüttelt.

Das Projektteam fordert:

• Vollzugriff auf das Active Directory
• Vollzugriff auf das Domino Directory
• Vollzugriff auf die Domino Server
• Vollzugriff auf die Exchange Infrastruktur oder die Cloud-Komponenten
• Vollzugriff auf Migrationsmaschinen
• Ein Change Request Window für den gesamten Projektzeitraum
• Öffnen von Firewalls für neue Ports und Maschinen
• und, und, und …

Der Provider sagt: „Geht nicht, gibt´s nicht!“. Und schon steckt das Projekt im Sand. Die Dauerschleife heißt dann: Bedarfe formulieren (die man unter anderen Bedingungen in 5 Minuten umsetzen könnte), diskutieren, verhandeln, beschließen oder auch nicht, warten, warten, warten. Der Provider besteht aus Sicht des Projektteams aus einer Ansammlung von grauen Männern, die einem die Zeit stehlen. Abgeschottet durch den Stellverteter des „Systems“, den Service Delivery Manager. Da kommt tägliche Freude auf.

Wenn das Migrationsziel die Cloud ist, läutet zusätzlich eine Vielzahl von Alarmglocken bei allen Beteiligten: Wie sind wir sicher? Wer ist in Zukunft für was verantwortlich? Was macht Microsoft? Was war eine Illussion, weil es Microsoft nicht macht? Sind wir „cloud ready“?

Der Kunde selbst trägt natürlich auch mit seinen Befindlichkeiten zum Versanden bei. Als Höhepunkt fordert das Projektteam noch den Zugriff auf die Mailboxen, auch die des Vorstandes. „Das haben wir jetzt so nicht gewußt!“. Aber wie soll man sonst Mails migrieren? Mancher Kunde kommt einem vor wie der Patient beim Arzt, der über eine klaffende Wunde am Oberschenkel klagt, sich aber weigert die Hose auszuziehen.

Unterm Strich würde ich sagen: „Managed Services bei einem externen Provider verdoppeln oder verdreifachen die Projektkosten und die Laufzeit des Migrationsprojektes.“ Wer sich das leisten kann und will, der sei beglückwünscht. Wer nicht, dem sollte das Projektteam sehr frühzeitig den vollen Umfang des Dilemmas offenbaren. Ansonsten wird das zur Schnitzeljagd mit Grabenkämpfen und endet in Frustration und endlosen Vorwürfen.

Beruhigend wirkt dann lediglich, wenn die Projektleitung sagt: “ Wir halten am Abschlußtermin des Projektes fest und Nachtragsbudgets sind leider nicht möglich!“