Heuballen als Symbol für Arbeitspakete

Office 365 Groups Governance – Teams, Planner und der böse Wildwuchs

Viele Blogeinträge, die sich mit dem Thema Office 365 Groups und Governance beschäftigen, raten rigoros dazu, erst einmal die Erstellung für den Otto-Normal-Benutzer abzuschalten. Wo kämen wir denn da hin, wenn jeder hier täte, was er wollte und überhaupt: Microsoft spinnt ja wohl, das Scheunentor im Standard offen zu lassen. Wenngleich es sicherlich nicht die schlechteste Idee ist, sich über Governance Gedanken zu machen, sollte das reflexartige Abknipsen der wohl großartigsten Sache in Office 365 kein Automatismus sein. Denn mit diesem System führt man nicht nur ein Tool ein, sondern auch eine Philosophie. Und auch wenn man seine eigenen User vielleicht für die letzten digitalen Bauerntrampel hält – vor dem kulturen Wandel kann man sich bei einer Office 365 Einführung nun mal nicht verstecken, so gerne man dieses leidige Thema auch aussparen wollte. Warum dann also bereitwillig das schärfste Schwert opfern?

Aber bevor wir uns schon im Anreisser zur Conclusio hangeln, gehen wir doch erst noch einen Schritt zurück und schauen, warum die Behandlgung von Office 365 Groups so ein großer Elefant im Raum einer jeden Implementierung von Office 365 in einem Unternehmen ist. 

Office 365 Groups in der Nusschale

Gruppen sind offensichtlich also etwas sehr Besonderes. Schaut man sich beispielsweise mal die Perodic Table der Office 365 Dienste von Matt Wade an, tauchen sie nirgends in der Aufstellung auf. Man kann sie eher als ein unterliegendes Konzept verstehen, ich bezeichne sie gerne gegenüber Kunden als den „Kitt, der all die anderen Kacheln da in der Übersicht zusammenhält“, allerdings mit eigener Funktionalität. Ursprünglich kommt die Grundidee aus der guten alten Mailingliste – ein Zusammenschluss von Kontakten unter einer Emailadresse.

Da das für viele sicherlich ein alter Hut ist und es unter Garantie bessere Primärquellen für die Beschreibung von Groups ist, soll ein schneller Blick an dieser Stelle für die Charakterisierung genügen:

  • Office 365 Groups enthalten ein Postfach mit einer einzigartigen Emailadresse und einem geteilten Kalender
  • Sie haben entsprechende Objekte im Azure Active Directory (je nachdem, wie und mit was sie erstellt wurden eins oder mehrere)
  • Gruppen haben Besitzer und Mitglieder, die dort von Besitzern eigenständig verwaltet werden können
  • Gruppen können (meistens) aus Outlook/OWA heraus bedient werden
  • Sie bekommen automatisch eine eigene SharePoint Webseite
  • Sie haben standardmäßig ein geteiltes Notizbuch
  • Gruppen bekommen immer bei der Erstellung eine eigene Planner-Instanz, die mit den Mitgliedern geteilt werden
  • Gruppen werden auch von Yammer benutzt, wobei der genaue Zusammenhang und die technische Implementierung weltweit neben den Microsoft Architekten nur von Albert Einstein und dem Yeti komplett und korrekt erfasst werden konnten
  • Office 365 Groups kann man prima über PowerShell-CMDlets verwalten
  • Office 365 Groups stellen für sich bereits eine zentrale Möglichkeit für emailbasierte Kommunikation und Zusammenarbeit dar

Kurz gesagt: Gruppen sammeln die verschiedenen Dienste aus Office 365 ein und stellen Instanzen davon miteinander in Beziehung, sind gleichzeitig aber auch technische Grundlage für die Funktionaliät der angeschlossenen Funkhäuser. Dass zum Beispiel Gäste in Teams funktionieren, es Besitzer und Mitglieder gibt, sowie mit einem Team bereits weitere Dienste automatisch provisioniert werden, ist letztlich den darunterliegenden Groups zu verdanken, deren Funktionumfang einfach von Teams genutzt und erweitert wird.  Wie so vieles andere auch lässt sich dieser Umstand bei Matt Wade wunderbar verinnerlichen. Diese Zusammenhänge sollte jeder wirklich kommplett verstanden haben, der sich irgendwie mit Office 365 auseinandersetzt.

Stecker raus?

Was erst einmal so wundervoll klingt, ist aber nun auch gleichzeitig die grundsätzliche Problematik dieses Konzepts: Wann immer neue Instanzen von Teams, SharePoint Webseiten, Planner Plänen, Power BI Arbeitsbereichen, Stream Kanälen, Yammer Feeds und – nunja – Office 365 Groups erstellt werden, erblickt eine eben solche das Licht der Welt und bringt alles mit, was sie zum Leben und Atmen braucht. Das sind wiederum diverse Instanzen der genannten Dienste.

Drücken also viele bunte Menschen auf viele bunte „Erstellen“-Knöpfe, wächst die Anzahl der Gruppen in einem Tenant in rasender Geschwindigkeit. Werden nun noch Doppelungen von Arbeitsinstanzen erstellt oder kommen noch die vielen Arbeitsorte für so wichtige Sachen wie Mittagessenplanung, „Noch ein Test“, Filmtauschbörsen oder Glühweinbeschallung auf dem Weihnachtsmarkt dazu, kann man dem Wust an Gruppen beim zahlenmäßigen Explodieren förmlich zuschauen. Mit einer ähnlichen Geschwindigkeit weicht die Pigmentierung aus dem Haupthaar desjenigen, der im Unternehmen dafür zuständig ist, dass hier alles fein säuberlich mit Zucht und Ordnung im überwachten Rahmen bleibt. Denn derjenige hat an dieser Stelle jetzt ein handfestes Problem.

Folgt man klassischen Ansätzen einer Governance in Unternehmen, trifft man häufig auf die Freigabe von neuen Arbeitsebenen. So kennt man das vielleicht noch aus Großmutters Zeiten bei Ordnern auf dem zentralen Netzlaufwerk, die zentral eingerichtet und berechtigt werden. Oder Datenbanken in Lotus Notes. Vielleicht ja auch schon von SharePoint Webseiten oder ähnlichen Produkten zum Informations- und Dokumentenmanagement in on-premise-Systemen. Vielfach wird versucht, eine neu geschaffene Instanz eines digitalen Arbeitsmittels einem Zweck zu unterwerfen, einem Prozess unterzuordnen, sie zu katalogisieren, Verantwortliche dranzuschreiben und im besten Fall noch durch die interne Kosten- und Leistungsrechnung zu drehen. So wurde lange Zeit agiert, denn

  • für selbst gehostete Systeme ist man selbst verantwortlich, also auch für Skalierung und Betrieb
  • Das Einrichten ist ein technischer Vorgang, der nicht durch Endandwender geschieht
  • Regeln und Prozesse wurden geschaffen und implementiert, um das Funktionieren dieser Systeme zu gewährleisten und nachvollziehbar zu halten.
  • Gerne wird das Ganze auch zur Bewertung messbar gemacht
  • im schlimmsten Fall gibt es noch einen Servicedienstleister, der in einer Melange aus Pönalen und Vertrieb sich dabei die ein oder andere Mark verdient.

Demensprechend sind die Konzepte, die da auf einmal aus der Wolke purzeln, ein echtes Problem, denn diese passen so überhaupt nicht auf die Strukturen, Prozesse und das Mindset der verantwortlichen und handelnden Personen. Wer bisher in Servicequalität und handverlesener Anforderungserfüllung gedacht hat, trifft hier gegebenenfalls diametral auf die Denke, die Microsoft mit Office 365 verfolgt. Denn die Cloud als Service funktioniert einfach so, ohne dass hinten jemand in ausreichender Geschwindigkeit neue Festplatten reinstöpselt.

Der natürliche Reflex ist beim Erkennen dieser Funktionweisen dann das Aufrufen dieser Seite und das Zusammenstreichen der Berechtigung, wer eine Gruppe anlegen darf, per Active Directory Setting via PowerShell. Dazwischen gibt es dann einen Freigabemechanismus und ein paar Leute, die sich das jeweils genau anschauen.

Mal schnell ein paar Zahlen in den Taschenrechner getippt

Spitzen wir doch einmal den Bleistift und rechnen scharf nach, was das für Groups in Zahlen bedeutet. Dazu nehmen wir ein Unternehmen aus dem gesunden deutschen Mittelstand, welches in die Cloud geht und Office 365 einführt. Gehen wir mal von soliden 2.500 Mitarbeitern aus, von denen 2.000 irgendwie mit einem Office versorgt werden.

Ich lasse an dieser Stelle all die Feinheiten mal komplett raus. Um sinnvoll statistisch zu argumentieren müsste man jetzt die Implementierungs- und Einführungsphase separat betrachten sowie einen tendentiell eher logarithmischen als linearen Wachstumsquotienten heranziehen, usw. – spielt für das Argument keine wirkliche Rolle. Wichtig ist hier, dass wir annehmen, dass jeder dieser Mitarbeiter durchschnittlich einmal in der Woche eine neue Gruppe anlegt mit irgendeinem der Office 365 Services, weil sie oder er damit seine fachliche Arbeit erledigen will. Egal, ob ein Team, ein Planner Plan, eine SharePoint Site oder eine der anderen Instanzen.

Betrachtet man diese Annahmen einfach mal auf zwei Jahre (Einführung, On-Ramp, Ausrollen, bis sich alles so zurechtruckelt plus Anfangsphase) und rechnet das stumpf aus, ergibt sich für die Überlegungen zu einer Governance eine Größenordnung:

2.000 Mitarbeiter x 50 (Arbeitswochen) x 2 Jahre => 200.000 Gruppen(!)

Selbst wenn man hier die Hälfte aus irgendwelchen Gründen abzieht, möchte man nicht der arme Schlumpf sein, der bei einer neuen Instanz entscheiden soll, ob diese Gruppe jetzt aus dem Ei kriechen darf oder nicht. Die schiere Menge allein führt eine sinnvolle Überprüfung nach irgendwelchen Kriterien das Ganze bereits ad Absurdum.

Was ist denn hier eigentlich Governance und was ist Wildwuchs?

Kommen wir dazu mal auf den Begriff der Fachlichkeit zu sprechen. Office 365 „denkt“ und funktioniert nun einmal in diesen Instanzen, die nicht zentral erstellt werden, sondern die sich aus dem wirklichen, alltäglichen Bedarf der Mitarbeiter generieren. Aus Sicht der IT ist dabei die Krux, dass genau diese Mitarbeiter es auch normalerweise am besten wissen, zu welcher Fachlichkeit sie Toolunterstützung aus dem Bereich Office 365 gebrauchen können. Auch wissen sie diverse Male besser als die IT, wer welchen Zugriff gewährt bekommen soll, was sich vielleicht seit letzter Woche geändert hat und welcher Externer wo mitarbeiten muss. Was aus Sicht der IT vielleicht wie Kraut und Rüben aussieht, macht für den fachlichen Experten des Unternehmens vollkommen Sinn.

Geben Sie auf, dagegen kann man faktisch nicht gewinnen. Letztlich ist die IT auch nur ein Dienstleister, der sicherstellen soll, dass die Umsatz erwirtschaftenden Bereiche eines Unternehmens vernünftig und effizient arbeiten können. Office 365 liberalisiert diesen Aspekt noch weiter, indem Dinge wie Instantiierung und Lebenszyklen von Arbeitsebenen inhaltlich komplett an der IT vorbeilaufen können.

Wann ist also eine Group Wildwuchs und wann ist sie gerechtfertigt und wer entscheidet das? Sicherlich gibt es diverse ärgerliche No-Gos, die man unbedingt vermeiden sollte:

  • Doubletten (lassen sich schlecht mergen ohne Informationsverlust, doppelte Arbeit, viel Verwirrung)
  • Verwaiste Instanzen ohne Abschluss des Lebenszyklus (liegen „tot“ in der Gegend herum, schlimmstenfalls ohne Ansprechpartner und Owner)
  • Geschlossene Datencontainer von „fertigen“ Informationen (Variante der verwaisten Instanzen: Wertvolles Firmenwissen lungert irgendwo herum ohne dass jemand es finden kann)

Unter Betrachtung von Fachlichkeit, Lebenszyklus und Datenzugriff ergibt sich damit ein viel differenzierteres Bild davon, welche Groups wirklich im Rahmen der Governance behandelt werden müssen und was einfach nicht zu beachtendes Grundrauschen im Sinne der IT ist. Dementsprechend braucht an andere Kennzahlen und Indikatoren, das rein Technische erledigt Microsoft ja wie gesagt selber, egal, wie viele Groups es im Tenant gibt.

Wie eine solch qualitative Governance durchgeführt werden kann, werde ich beizeiten mit einem möglichen Lösungsansatz in einem weiteren Blogbeitrag zeigen.

Training, Training, Training und immer ein offenes Ohr haben

Kürzt man das also diesen Aspekt aus der Gleichung heraus, bleibt von der unabdingbaren Notwendigkeit, das Erstellen von Groups im Tenant hart zu beschränken, nur ein Bruchteil über. Und zwar soviel, dass man sich darüber Gedanken machen und es so gestalten kann, dass fachliche Anforderungen von Benutzern und der notwendige Durchblick miteinander verhandelbar werden.

Denn eines der anfangs angekündigten schärfsten Schwerter ist genau diese Flexibilität für den einzelnen Mitarbeiter: Er kann erstellen, bearbeiten, löschen und selber Herr im Haus seiner Daten sein, denn im besten Fall weiß er selbst am besten, was er braucht und was ihn bei der Arbeit unterstützt. Das Konzept von Office 365 stützt das mit den vielen Self Services und entlastet gleichzeitig die IT von dem unabdingbaren inhaltlichen Detailwissen, welches eine umfassende Überwachung und Freigabe bräuchte.

Damit das aber funktioniert, stellt Office 365 einen vergleichsweise riesigen Anforderungsberg an den Endanwender. Der muss lernen und sich trauen, das System auch wirklich nach diesem Baukastenprinzip selbstbewusst und selbstbestimmt zu benutzen. Denn wenn er das tut, hat die IT keinerlei Arbeit damit, egal, wie viele Instanzen in einem Tenant wirklich existieren. Solange sinnvolle Leitplanken aufgestellt sind (Namingpolicies, Expirationpolicies, etc.), läuft das Groß des Verkehrs von ganz alleine.

Daher mein Appell an dieser Stelle: Statt Benutzer zu beschränken sollte man ihnen auf dem Schoß sitzen, ihnen zuhören, Verständnisprobleme erkennen und auflösen sowie quantitativ monitoren und qualitativ einschreiten, wenn etwas droht, falsch zu laufen (dann auch gerne deutlich und bestimmt). Damit das aber funktioniert, muss man den Change akzeptieren und die neue digitale Kultur nicht nur annehmen, sondern auch mit einem großen Haufen Commitment vorleben. An diesen Aspekten muss sich eine zu implementierende und zu lebende Governance orientieren.

Gleichzeitig ist es unabdingbar, die eigenen Benutzer so fit wie irgendwie möglich zu machen. Ohne Training und gelebtes Inhouse-Consulting schafft man nicht die Leuchttürme in den Abteilungen, die es braucht, um die kritische Masse mitzuziehen. Denn nur so verselbstständigen sich die Gepflogenheiten und Spielregeln rund um Groups, Teams, SharePoint Webseiten, Planner Plänen, Yammer Kanälen, Power Bi Arbeitsbereichen und all den anderen kleinen Tools dazwischen.

Office 365 dringt tief in ein Unternehmen und seine Arbeitsweisen ein und bringt für viele einen tiefen kulturellen Wandel in der digitalen Arbeit mit sich. Da bringt es nichts, sich davor zu verstecken.


3 thoughts on “Office 365 Groups Governance – Teams, Planner und der böse Wildwuchs

  1. Amazing! Fascinating, and somewhat worrying how we are all going to be inevitably stuck like wasps in treacle, to Office365.
    I am now hoping you have some articles on how you see Teams working and developing on our corporate desktops. Some of use think Teams is a great product, helping to rid us of the banalities mail we do not want and do not need to read. But i suppose all it will do is cause people to announce their dog is feeling sick on Teams and Yammer instead of email.

    Actually, the serious query was about archiving a Teams group once a project, conducted for a ‚Team‘ setup for that purpose is complete. Or perhaps we should not use it that way, but simply use Teams for projects another way… What would be best practice is interesting topic.

    Thanks Carsten, A well written blog. Forgive my ignorance of German language please.
    Seumas

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.