Office 365: Wer "blind" migriert, verliert

Bei der Migration von MS Office auf eine "Managed Cloud" sollten Unternehmen sehr sorgfältig erwägen, welche Service Level notwendig sind. Digitale Vorlagen für Servicebeschreibungen können dabei helfen.

Bei der Migration von MS Office auf eine "Managed Cloud" sollten Unternehmen sehr sorgfältig erwägen, welche Service Level notwendig sind. Digitale Vorlagen für Servicebeschreibungen können dabei helfen.

Microsoft Office 365 ist für manche IT-Verantwortliche derzeit ein wichtiges Thema. Denn kurz- oder mittelfristig steht eine Migration der rein lokal genutzten Programmversionen an – eine größere IT-Herausforderung und zumindest teilweise eine "black box". Die Office-Anwendungen waren bisher meist on-premise im eigenen oder gemieteten Rechenzentrum installiert. Bei Office 365 handelt es sich dagegen um ein SaaS-Produkt aus der Cloud – und als solches bringt es seine eigene, "unverhandelbare" Servicebeschreibung mit. Dennoch muss auch diese Variante "gemanaged" werden: Lagert man das Management aus, ist es wichtig, den Betrieb mit Störungsbearbeitung, Monitoring und Verwaltung nach den eigenen, spezifischen Anforderungen an den Service Level zu steuern.

Der Nutzen ist unbestritten: Die cloudbasierte Software erleichtert den Anwendern vor allem das mobile Arbeiten. Gleichzeitig wirft das Modell aus der Managed Cloud aber auch viele Fragen auf: Wer trägt die Verantwortung für den Softwarebetrieb? Wer steht als Ansprechpartner bei Störungen zur Verfügung? Wer ist als "Tenant", d.h. Mieter, zur Nutzung befugt? Kurz: Was muss in einer Servicebeschreibung berücksichtigt werden?

Das ist insbesondere dann der Fall, wenn der Kunde die Anwendung in der Cloud nicht selbst betreuen kann oder will, d.h. dieses Management auslagert. Gründe dafür gibt es viele – zum Beispiel Personalmangel oder vorheriges Outsourcing solcher Prozesse. Für Kunden, die den Umzug in die Cloud nicht selbst übernehmen wollen, bietet das Office-365-Ökosystem viele Anbieter, die das leisten und sich darüber hinaus um den Betrieb des Systems kümmern. Dafür eignen sich sowohl traditionelle IT-Provider als auch mittelständische Systemhäuser.
 

Am Ende ein klassisches Outsourcing

Bei Licht betrachtet ist die Auslagerung von Cloud-Migration und/oder Softwarebetrieb an einen Dritten dann eben doch wieder: ein klassischer Outsourcing-Prozess. Und beim Outsourcing von IT-Dienstleistungen muss der Kunde eine Servicebeschreibung vornehmen. Durch diese wird klar festgelegt, für welche Aufgaben der Anbieter verantwortlich ist und wie seine Tätigkeiten hinsichtlich Service und Bedarf aussehen. Eine klare Vorgabe der Servicebeschreibung und der Service Levels erleichtert es dem Kunden zudem den Wettbewerb für sich zu nutzen und verschiedene Anbieterangebote zu vergleichen. Und genau wie bei jedem Outsourcing-Prozess kann es sich rächen, hier zu wenig Sorgfalt walten zu lassen – entweder durch Schwierigkeiten im Betrieb oder durch unnötig hohe Kosten.

Worauf es ankommt: Drei Beispiele

Wegen der Vielfalt und Dynamik der MS-Office-365-Apps spielt zum Beispiel die Differenzierung zwischen qualitativen Betriebsanforderungen und den eigentlichen Serviceaktivitäten eine wichtige Rolle. Denn auch wenn das Unternehmen Kunde ist und Prozesse auslagert, liegt die Verantwortung für diese – zumindest teilweise – bei ihm. Bei MS-Office-365 gehören zu solchen Anforderungen an erster Stelle Angaben, welche Office-, Collaboration-, Unified-Communication- und App-Funktionen der Kunde nutzen will – und welche eben nicht. Auch geht es um die Einstellung von Konfigurationsparametern, die Abschaltung von nicht genutzten Funktionen oder die Verwaltung von kompatiblen Add-Ins. Die Frage, ob und welche externen Systeme anzubinden und zu überwachen sind, muss ebenfalls geklärt sein wie etwa die Anbindung von Exchange-Systemen per Federation.

Manchmal muss oder will der Kunde auch über besondere Aktivitäten informiert werden, bestimmte Vorgänge genehmigen oder mitwirken - wie etwa bei der Analyse gemeldeter Störungen in der Nutzung von MS Office 365 oder bei Vorgaben zur Pflege von Workflows. Von zentraler Bedeutung ist in solchen Konstellationen eine präzise Verantwortungszuordnung für die Störungsbearbeitung sowie das Anlegen und Löschen von Usern, Gruppen oder auch E-Mail-Adressen. Um das gewährleisten zu können, müssen diese Prozesse sauber von Anbieterleistungen getrennt werden, was wiederum durch das DEMI-Format der Aktivitätenbeschreibung erreicht werden kann.

Zu einer sauberen und vollständigen Service-Level-Auflistung gehören neben dem eigentlichen Wert, der zum Beispiel Reaktions-, Wiederherstellungs- und Umsetzungszeit darstellt, auch ergänzende Informationen wie Schwell- und Toleranzwerte sowie Informationen und Vereinbarungen zu Messmethoden und wessen Tickettool genutzt werden soll.

Muster-Servicebeschreibungen schaffen Sicherheit

Allein die drei Beispiele zeigen, dass die Ausgestaltung von Servicebeschreibungen nicht trivial ist und dass generische Formulare nicht ausreichen. Angesichts der Einmaligkeit des Umstiegs fehlt es in den meisten Unternehmen an Erfahrungswerten, um hier Nägel mit Köpfen zu machen – von den knappen Zeitressourcen der zuständigen Teams ganz abgesehen. Statt mit lückenhaften oder überkompletten Beschreibungen ins Risiko zu gehen, bietet es sich an, Beratungsleistungen in Anspruch zu nehmen. Wenn das nicht in Frage kommt, können Unternehmen, die sich die Abwicklung selbst zutrauen, aber bei den Servicebeschreibungen auf Nummer Sicher gehen wollen, inzwischen auf vorgefertigte Servicebeschreibungen für Migration und Betrieb von MS-Office-365 zurückgreifen. Und zwar auf solche, die von spezialisierten Beratern angefertigt wurden und damit weder die Interessen von Service-Providern noch von Microsoft favorisieren.

Artikel empfehlen

Durch die Nutzung dieser Webseite erkläre ich mich mit der Verwendung von Cookies einverstanden. Weitere Informationenschließen