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

Auch in der Cloud gibt es Probleme

Der Nutzen ist unbestritten: Die Cloud-basierte 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 und das 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, wie traditionelle IT-Provider als auch mittelständische Systemhäuser, die ihm dabei helfen können.

Am Ende ein klassisches Outsourcing

Bei Licht betrachtet ist die Auslagerung in die Cloud 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, 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 im Vorfeld 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 oft nicht ausreichen. Angesichts der Einmaligkeit des Umstiegs fehlt es in vielen Unternehmen an Erfahrungswerten, um hier Nägel mit Köpfen zu machen – von den knappen Zeitressourcen der zuständigen Teams ganz abgesehen. Als Alternative zu teuren Serviceverträgen können Unternehmen, die bei den Servicebeschreibungen trotzdem auf Nummer sicher gehen wollen und sich die Abwicklung selbst zutrauen, inzwischen auch auf von unabhängiger Seite vorgefertigte Musterservicebeschreibungen zurückgreifen – und damit die Gewähr haben, dass weder die Interessen von Service-Providern noch von Microsoft bevorzugt werden.