Seit einiger Zeit bieten wir nun den Evergreen Service an. Dabei kommt als erstes immer die Frage, wie ein solcher Service in den Alltag unserer Kunden integriert werden kann. Natürlich sind die Antworten hier so vielfältig wie die Anforderungen und der Stand der IT unserer Kunden. Doch nachfolgend möchten wir unseren Best-Practices Ansatz als Whitepaper beschreiben.
Was ist der Evergreen Service?
Als Evergreen-Service verstehen wir einen Managed Service Ansatz, welcher unseren Kunden hilft ihre Microsoft 365 Landschaft aktuell zu halten. Dies ist notwendig, da Microsoft jede Woche neue Updates für Microsoft 365, Dynamics 365, Windows 365 und die verwandten Plattformen veröffentlicht. Dabei reicht die Spannweite in der Regel von 10 bis 25 Änderungen. Nun ist es aber so, dass nicht alle 25 Änderungen bei unseren Kunden auch zum Tragen kommen. Hier muss nun eine Vorauswahl getroffen werden.
Dabei unterscheiden wir in 4 verschiedene Kategorien:
- Nicht relevant: Die Technologie wird vom Kunden nicht genutzt, hier ist keine Aktion erforderlich
- Automatisches Update: Das Update ist für den Kunden relevant, wird aber keine sichtbaren Auswirkungen haben. Z.B. ein Sicherheitsupdate.
- Action required: Das Update ist für den Kunden relevant und es hat konkrete Auswirkungen auf mindestens eine Nutzergruppe, bspw. Endnutzer:innen oder Administrator:innen.
- Change: Das Update verursacht eine grundsätzliche Änderung des Verhaltens oder eine neue Komponente wird eingeführt, die für den Kunden relevant ist. Hier ist konkreter Handlungs- und Schulungsbedarf erkennbar
Je nachdem erhält der Kunde nun ein vereinbartes Update, welche Auswirkungen das Ganze auf ihn hat, und was die Handlungsoptionen sind. Und hier stellen nun viele Kunden die Frage, wie dieser Prozess in das Unternehmen integriert werden könnte. Wir stellen hier die Endausbaustufe vor. Diese kann entsprechend des eigenen Bedarfs dann verändert oder auch reduziert werden.
Den Evergreen Service in den Tagesbetrieb einführen
Unsere Kunden haben häufig eine Größe erreicht, die einen dokumentierten Betriebsprozess notwendig macht. Mit der Einführung auf Microsoft 365 wurde dieser häufig bereits auf die Cloud-Systeme angepasst. Den schnellen Update-Zyklen von M365 wird dabei häufig im ersten Schritt noch keine Rechnung getragen. Vielmehr werden die bisher bestehenden Prozesse angepasst und umgeschrieben. Auch ist für agile Anforderungen und Changes, wie es das Evergreen-Modell mit sich bringt, weder die personelle Kapazität noch das Budget vorhanden. Entsprechend wird der Evergreen Service ausgelagert, um hier von Synergieeffekten mit anderen Firmen zu profitieren.
Aber dieses Konzept funktioniert auch dann, wenn das Evergreen Team als interne Ressource abgebildet wird. Hierfür wird das Betriebskonzept um den Bereich Evergreen erweitert. Wir werden in diesem Blog jetzt nicht auf jedes einzelne Element eingehen, doch zumindest die wesentlichen Aspekte beleuchten, die ein solches Evergreen-Modell umfassen muss.
Der Evergreen Report
Dieser Report bildet das Herzstück des Evergreens. Es beinhaltet alle Änderungen, die über den Evergreen-Service identifiziert werden, sowie die Maßnahmen, Einschätzungen, Kostenfaktoren, Risikofaktoren etc., die mit einem Evergreen Artikel in Verbindung stehen. Dabei wird jeder Evergreen wie oben beschrieben zunächst einer Kategorie zugeschrieben. Dabei hilft eine klassische Prioritätsmatrix.
| Gering | Mittel | Groß | Kritisch | |
| Betroffene Systeme | 1 | 2 | 3 | X |
| Betroffene Personengruppen | 1 | 2 | 3 | X |
| Implementierungsaufwand | 1 | 2 | 3 | – |
| Schulungsaufwand | 1 | 2 | 3 | – |
Diese Faktoren werden nun aufaddiert, wobei ein kritisches System oder eine kritische Personenanzahl immer automatisch zu einem hoch-priorisierten Eintrag führt. Für die Aufwände gibt es keine kritischen Faktoren.
- 10 – 12: Hohe Priorität, der Eintrag wird ausführlich beschrieben und analysiert, kann in einem eigenen Projekt münden
- 7 – 9: Mittlere Priorität, der Eintrag wird in einem Mehrzeiler beschrieben und die Handlungsoptionen werden mit Empfehlung aufgezeigt
- 4 – 6: Niedrige Priorität, der Eintrag wird mit einer Handlungsempfehlung beschrieben
- Irrelevant: Das Produkt für den Artikel ist nicht in Benutzung und wird daher nicht berichtet
Klassischerweise sind die meisten Artikel pro Woche, die berichtet werden, nur von niedriger Priorität für einen Kunden und können damit schnell abgehandelt werden. Allerdings kann man davon ausgehen, dass pro Woche auch ein oder zwei mittlere Prioritäten enthalten sind, die eine konkrete Auswirkung auf den Betrieb haben.
Ein Eintrag mit einer hohen Priorität erfolgt entsprechend selten. Doch auch sie kommen vor. Beispielsweise Teams 2.0 oder das neue Layout einer App wie Outlook und dem Planner. Je nachdem, wie die Firmenkultur unseres Kunden ist, kann man hier verschiedene Wege gehen. Einige Kunden veröffentlichen lediglich einen Eintrag im Intranet oder ein kleines Video mit den Neuerungen. Bei anderen müssen in Folge dieser Änderungen das Betriebskonzept und die Schulungsunterlagen geändert, die betroffenen Zielgruppen informiert und die Administrator:innen für die neue Situation vorbereitet werden. Ist dann noch der Rollout auf den Clients notwendig, kann hier schnell ein kleines Projekt aus einem Evergreen-Eintrag werden, welches dann aus dem Evergreen-Service herausgelöst wird. Der High-Prio Report zeigt diese Optionen auf und liefert, soweit möglich, auch bereits erste Schätzwerte über den Aufwand, der sich hinter dem Change stecken. Auch benennt es die beteiligten Gruppen, die für eine solche Änderung berücksichtigt werden müssen, um eine ideale Entscheidungsgrundlage zu bilden.
Evergreen Advisory Board
Das Change Advisory Board (CAB) ist hier die Vorlage und erfüllt in diesem Kontext die gleiche Funktion. Der Unterschied bei vielen Unternehmen ist lediglich die Häufigkeit, mit der dieses Board abgehalten werden sollte. Während das CAB häufig nur einmal im Monat stattfindet, empfiehlt es sich im Evergreen jede Woche einen Slot für das Board bereitzuhalten. Dies ist deshalb notwendig, weil Microsoft seine Changes häufig nur mit einem oder zwei Monaten Vorlauf ankündigt. In diesem Fall bleibt dann nur wenig Zeit eine Entscheidung bis zur Umsetzung zu bringen. Wir empfehlen an dieser Stelle das Evergreen Advisory Board wöchentlich mit lediglich 15-30 Minuten zu adressieren und hier auch nur die wirklich zeitkritischen Evergreens vorzustellen. Alle anderen können dann in der CAB-Sitzung besprochen und entschieden werden.
Je nach Größe des CABs kann es auch notwendig sein das Evergreen-Board nur mit einer reduzierten Anzahl an Personen zu besetzen, um nicht in Terminkonflikte zu geraten. Wichtig ist hier jedoch, dass dieses Board mit den notwendigen Kompetenzen ausgestattet wird, um auch kurzfristig relevante Entscheidungen für das Unternehmen zu treffen. Der Enterprise-Architekt oder Product Owner sind hier mögliche Teilnehmer.
Verfügt eine Firma bisher nicht über ein CAB empfiehlt es sich im Rahmen der Standardisierung dieses Meeting einzuführen und auch andere Themen zu besprechen. Wichtig ist, dass alle Änderungen an der M365-Plattform, egal aus welcher Richtung sie kommen, nach dem Standard des Evergreen-Services oder des Betriebskonzeptes dokumentiert werden, um langfristig die Stabilität des Tenants zu garantieren.
Dieser Punkt der langfristigen Stabilität ist bei Microsoft 365 besonders wichtig. Da wir hier ein System haben, welches nicht irgendwann durch eine neuere Version abgelöst wird. Gerade diese Versionswechsel wurden in der IT traditionell dafür genutzt, um bestehende Probleme, Fehlentscheidungen und Altlasten zu beseitigen. In M365 fallen diese Möglichkeiten weg und so ist eine saubere Dokumentation für den Betrieb der Landschaft in 10 oder 15 Jahren essentiell und muss bereits ab dem 1. Tag richtig umgesetzt werden.
Systemlandschaft
Damit der Evergreen-Service effizient und reibungslos funktioniert, wird bei der Einführung die komplette Systemlandschaft rund um den Evergreen-Service begutachtet. Das beginnt bei den Office-Applikationen, geht weiter zu Teams, Planner und SharePoint, berücksichtigt aber auch technische Aspekte wie Intune, Autopilot, Compliance und Security. Dieser Abschnitt umfasst eine komplette Bestandsaufnahme des Systems, inklusive der relevanten Einstellungen, die hier vorgenommen wurden. Auch wird diese Dokumentation fortlaufend aktualisiert, wenn ein Evergreen umgesetzt wird. Üblicherweise kann ein großer Teil dieser Dokumentation auf das bestehende Betriebshandbuch referenzieren. Ist dieses noch nicht vorhanden, wird es im Rahmen der Einführung implementiert. Die Dokumentation der Betriebslandschaft ist eine zwingende Voraussetzung für eine effektive Umsetzung des Evergreen-Service.
Implementierung, Schulung und Coaching
Unter Implementierung stehen wir alles, was die eigentliche Integration eines Evergreens in die bestehende Systemlandschaft umfasst. Der Prozess hier ist stark von den Anforderungen des Kunden, der Änderung und der Komplexität abhängig. Grundsätzlich wird hier aber zu einem vorher definierten Wartungslot, sofern möglich, die im Evergreen Advisory Board beschlossene Änderung eingeführt. Das kann bedeuten, dass lediglich ein neues Flag gesetzt, oder eine neue Version einer Software ausgerollt wird.
Alle durchzuführenden Änderungen werden vorher in der Dokumentation (Servicehandbuch, technische Dokumentation, Betriebshandbuch, Schulungsunterlagen etc.) beschrieben und zur Abnahme vorgelegt. Mit der Freigabe der Dokumentation wird dann die eigentliche Änderung durchgeführt und die neue Version der Dokumentation released.
An dieser Stelle ist auch darauf zu achten, dass mit einem Update ggf. neue Schulungen durchgeführt werden müssen. Daher werden in diesem Schritt auch die Zielgruppen benannt, der Schulungsumfang definiert und der Schulungsplan aufgesetzt werden. Handelt es sich bei dem Change um eine kritische Änderung an der Infrastruktur oder der Art, wie die Mitarbeiter:innen zukünftig arbeiten werden, so ist darauf zu achten, dass die Schulungen für die Primär-Zielgruppen vor dem eigentlichen Rollout angeboten werden. So ist ein reibungsloser Ablauf des Evergreens ermöglicht.
Schließlich soll an dieser Stelle auch der Helpdesk, bzw. andere Service-Stellen separat Erwähnung finden. Sie werden einen Change später im laufenden Betrieb betreuen und bisher uninformierten Usern erklären müssen. Daher sollte der Helpdesk immer über einen separaten Kanal priorisiert informiert werden, sobald ein Evergreen-Change Auswirkungen auf die Endnutzer:innen haben.
Fazit
All diese Prozesse zeigen bereits, dass ein Evergreen Service nicht mal eben schnell implementiert werden kann. Stattdessen ist er ein neuer Baustein des Betriebskonzeptes, welcher die alten Methoden nutzt, dabei jedoch eine deutlich höhere Geschwindigkeit der Beteiligten erfordert. Auch ist hier eine saubere, konsistente Arbeit notwendig, sowie die Disziplin auch kleine Änderungen sauber in den bestehenden Prozess zu integrieren. Denn durch die Langlebigkeit von Microsoft 365, welches nun bereits seit 11 Jahren ununterbrochen und ohne Migration betrieben wird, können auch kleinere Änderungen später relevant werden, wenn neue Features und Updates eingeführt werden, die man bis heute nicht auf den Schirm hat.
Der Evergreen Service fügt sich somit in ein größeres Betriebskonzept von M365 ein, welches zum Ziel hat, die Betriebsumgebung stets gut dokumentiert und gepflegt zu halten. Weitere Bausteine, wie die automatisierte Bereinigung von Altdaten, das Rechte- und Rollenkonzept, die Einführung neuer Apps und Services, werden wir in weiteren Beiträgen behandeln.
0 Kommentare