Microsoft Teams Governance

Sucht man im Internet nach „Teams Governance“, findet man etliche Beiträge zu dem Thema. Meist sind diese Artikel recht generisch und müssen in der Praxis selbstverständlich den Anforderungen des Kunden angepasst und ergänzt werden.

„5 Punkte für eine erfolgreiche Teams Governance!“

Generischer Blog Titel zum Thema Teams Governance

In keinster Weise soll das übrigens heißen, dass ein „5 allgemeine Punkte für eine Teams Governance“ Artikel nicht lesenswert wäre. Im Gegenteil: Ich finde diese Artikel sehr ansprechend um in ein Thema rein zukommen.

Mein Artikel basiert meist auf Erfahrungen, die ich in der Vergangenheit machen durfte und erhebt – natürlich – keinen Anspruch auf Vollständigkeit! 🙂

Einführung von Teams

Die Indentifizierung von „Early Adopter“ steht mit an erster Stelle bei der Einführung eines neuen Produkts. Unter „Early Adopter“ versteht man einen Personenkreis, der als Versuchskaninchen dienen soll und prinzipiell der neuen Technologie nicht abgeneigt ist. Hat man eine solche Gruppe ausfindig gemacht, gilt es diese vorab ausreichend zu schulen.

Technisch macht es Sinn, die Kandidaten durch eine eigene Security Group ansprechbar zu machen. So ist es auch einfacher, den „Early Adoptern“ die notwendigen Lizenzen zuzuweisen und die Freigabe für Teams zu erteilen.

Für einen Piloten empfiehlt es sich zwei bis drei Teams aufzusetzen und die notwendigen Funktionen freizuschalten.

Wichtig ist auch kontinuierlich Feedback von den „Early Adoptern“ einzuholen und ggf. interne Prozesse bei Roll-Out und Adoption anzupassen.

Wer darf Teams erstellen?

Die Verantwortlichkeit darüber, wer Teams erstellen darf sollte bei der IT liegen. Das ist natürlich von vielen Faktoren abhängig. In einem kleine Unternehmen voller Microsoft 365 Geeks macht diese Regelung vermutlich wenig Sinn. In einem großen Konzern mit wenigen IT-nahen Nutzern ist ein restriktiverer Ansatz – um Wildwuchs zu vermeide – eher zu empfehlen.

Bewährt hat sich ein automatisierter Provisionierungsansatz wie man ihn häufig auch für Office 365 Groups und SharePoint Sitecollections nutzt. Hier hat ein dedizierter Personenkreis (z. B. Abteilungsleiter oder Champions innerhalb der Fachabteilungen) die fachliche Berechtigung ein Teams zu beantragen.

Die Erstellung der Instanz selbst erfolgt – hoffentlich – automatisiert durch die IT.

Erstellung von Channels

Ob es immer gleich ein neues Teams sein muss, ist eine ganz andere Frage. Das kann am besten innerhalb der Fachabteilung geklärt werden. Darum macht es auch am meisten Sinn, die Erstellung und die Moderation von Teams Channels in den Fachabteilungen zu belassen.

Namenskonventionen

Um ein Thema kommt man nicht herum. Namenskonventionen.

Es ist üblich, bestimmte Namen für Teams zu reservieren. Beispielsweise „HR“ oder „IT“ oder „Finance“. Die Idee dahinter ist, dass bestimmte Abteilungsbezeichnungen vorab festgelegt sind und nicht von anderen Zweckentfremdet werde können. Es hilft schlichtweg auch die Erwartungshaltung von Kollegen zu bestätigen, die in einem Teams „HR“ eben auch „HR“ relevante Inhalte vorfinden wollen.

Ein weiterer wichtiger Punkt ist das Unterbinden Sonderzeichen in den Namen zu verwenden. Sonderzeichen nehmen immer einen besonderen Stellenwert bei der Planung und Umsetzung in der IT ein. Die Verwendung der selbigen führt häufig zu Problemen. Daher sollten sie – soweit möglich – außen vorgelassen werden.

Die Verwendung von Präfix/Suffix in der Namensgebung kann gerader bei der Kenntlichmachung von Nutzerkreisen sehr hilfreich sein. Beispielsweise wird ein extern geteiltes Teams mit dem Präfix „[EXT]“ ganz anders wahrgenommen als wenn eben diese Kennzeichnung im Namen fehlt: Der Nutzer wird Informationen völlig anders zur Verfügung stellen.

Ob die Erstellung nun automatisiert oder manuell umgesetzt wird: Ein Tagging von Beginn an erleichtert die Verwaltung von Teams im Nachhinein immens.

Sei es für eine Identifizierung von Verantwortlichkeiten über die Zugehörigkeit der Teams zu bestimmten Unternehmensbereichen bis hin zu Reporting zu Nutzungsverhalten der Abteilungen. Es gibt eine Menge Gründe Tagging für die Bereitstellung von Teams in Betracht zu ziehen.

Externer bzw. Gastzugriff

  • Teams für den internen Austausch und externen Austausch sollten immer getrennt vorhanden sein.
    z. B. Die Abteilung Marketing kommuniziert intern über Teams. Nun kommt die Anforderung, mit externen Partnern zusammenzuarbeiten. Hierfür war die Idee, das vorhandene Teams für den externen Zugriff freizugeben. Stattdessen sollte ein separates Teams mit einer bestimmten Ablaufzeit erstellt werden, über das externer Zugriff möglich ist.
  • Aktivierung von Externem Zugang nur über IT möglich
  • Teams mit aktiviertem Externem Zugriff bzw. Gastzugriff prominent kennzeichnen
    • Namenskonvention
      z. B. „Vertrieb“ vs. „[EXTERN] Vertrieb“ oder „Marketing“ vs. „[EXT] Marketing“
    • Entsprechendes Bild hinterlegen
    • Teams als „extern“ taggen

Public vs. Private Teams

Bei der Erstellung eines Teams hat man die Möglichkeit auszuwählen. Zwischen „Public Teams“ und „Private Teams“. Der Unterschied ist – wie man sich bestimmt denken kann – Inhalte eines „Public Teams“ sind für alle Kollegen einsehbar, um die Inhalte eines „Private Teams“ sehen zu können, muss man dafür extra berechtigt werden.

„Public Teams“ werden häufig für unternehmensweite Kommunikation verwendet. Ähnlich wie in Yammer können hier Informationen für ein breites Publikum im Pull-Prinzip zur Verfügung gestellt werden.

„Private Teams“ im Gegensatz dazu finden Verwendung für einzelne Abteilungen oder dedizierte Anwendungsfälle. Die Erstellung eines „Private Teams“ stellt daher eher die Regel dar.

Microsoft Teams und Office 365 Groups

Eines vorweg: Teams ist nicht Groups, und Groups ist nicht Teams. Im Gespräch mit Kunden kommt irgendwann der Punkt „Teams vs. Groups“.

„Wann verwende ich Teams und wann verwende ich Groups?“

Kurz zur Funktionsweise und was ist was:

  • Teams ist ein Service innerhalb von Microsoft 365 der es Nutzern ermöglicht, sich auszutauschen
  • Groups ist die Funktionalität im Hintergrund um es verschiedenen Microsoft 365 Services und Applikationen zu erlauben miteinander zu kommunizieren

Ich weiß, sehr „High-Level“, aber ich denke es kommt auf den Punkt. Aber zurück zu unserer Governance.

Wann immer möglich sollte die Verwendung von Microsoft Teams im Kontext von Microsoft 365 Groups in Betracht gezogen werden. Auf diese Weise erhalten die Nutzer all Vorteile einer ganzheitlichen Collaboration Strategie, wie von Office 365 bereits vorgesehen.

Eine nachträgliche Verknüpfung zwischen Teams und Groups ist zwar möglich, aber nicht empfehlenswert. Beispielsweise kann eine solche nachträgliche Verknüpfung dazu führen, dass bereits existierende Dokumente, OneNote Einträge und Planner Tasks in Teams nicht korrekt eingebunden werden.

Fazit

Die Erstellung einer Governance – unabhängig für welche Technologie – ist ein fortlaufender, agiler Prozess. Durch die eigenen Erfahrungen und Änderungen in den Anforderungen innerhalb des Unternehmens ändert sich entsprechend auch der Inhalt einer solchen Governance. Dieser Aufwand und Änderungsprozess sollte dem Kunden bewusst und bekannt sein.

Die Einführung von Teams im Unternehmen funktioniert am besten, wenn in kleinen Schritten zunächst mit Early Adoptern oder Champions einen Piloten aufbaut und aus den Erfahrungen mit den Kollegen lernt und Prozesse anpasst. Diese Prozesse und deren Umsetzung werden in der Governance beschrieben.

Technisch nicht- oder schwer umsetzbare Richtlinien sollten wenn möglich organisatorisch (beispielsweise als Anweisung) umgesetzt werden.

Bei allem empfiehlt es sich zunächst klein anzufangen und dann auf den gemachten Erfahrungen basierend kundenspezifisch Anpassungen vorzunehmen.

Links

[1] „Plan for governance in Teams“ Quelle: Microsoft

Lob, Kritik oder eigene Meinung? Lass es uns wissen!