Microsoft entwickelt Microsoft 365 laufend weiter. Im Message Center eines grossen Tenants erscheinen jede Woche neue Einträge: neue Funktionen, geänderte Standardwerte, abgekündigte Einstellungen. Manche davon betreffen nur die Oberfläche. Andere erzeugen neue Daten über das Verhalten der Mitarbeitenden, etwa Nutzungsberichte, Anwesenheitsinformationen oder Auswertungen zur Copilot-Nutzung.
In Deutschland ist bei solchen Änderungen der Betriebsrat einzubeziehen. Wird der Tenant zentral für mehrere Betriebe oder Einrichtungen betrieben, ist häufig der Gesamtbetriebsrat zuständig. Dieser Artikel beschreibt ein Vorgehen, mit dem Betriebsteams Changes so aufbereiten, dass zügig entschieden werden kann. Er ersetzt keine arbeitsrechtliche Beratung.
Warum fast jeder Change mitbestimmungsrelevant sein kann
Nach § 87 Abs. 1 Nr. 6 BetrVG hat der Betriebsrat mitzubestimmen bei der Einführung und Anwendung technischer Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen. Nach ständiger Rechtsprechung des Bundesarbeitsgerichts genügt es, dass eine Einrichtung objektiv dazu geeignet ist. Ob der Arbeitgeber die Daten tatsächlich auswerten will, spielt keine Rolle.
Microsoft 365 erzeugt an vielen Stellen Daten, die sich einzelnen Personen zuordnen lassen: Anmeldeprotokolle, Audit-Log, Nutzungsberichte, Teilnehmerlisten von Besprechungen, Lesebestätigungen. Eine neue Funktion oder ein geänderter Standardwert kann deshalb eine neue Auswertungsmöglichkeit schaffen, auch wenn sie dafür gar nicht gedacht ist.
Hinzu kommen die Unterrichtungs- und Beratungsrechte nach § 90 BetrVG bei der Planung technischer Anlagen und Arbeitsverfahren, ausdrücklich auch beim Einsatz von Künstlicher Intelligenz. Muss der Betriebsrat die Einführung oder Anwendung von KI beurteilen, gilt die Hinzuziehung eines Sachverständigen nach § 80 Abs. 3 BetrVG als erforderlich. Für Copilot und Agents ist das relevant.
Die Rahmenbetriebsvereinbarung als Grundlage
In der Praxis bewährt sich eine Rahmenbetriebsvereinbarung für Microsoft 365. Sie regelt die Grundsätze, etwa dass keine Leistungs- und Verhaltenskontrolle mit den Daten erfolgt, wer auf Protokolle zugreifen darf und wie lange sie aufbewahrt werden. In Anlagen werden die einzelnen Dienste und ihre Konfiguration beschrieben.
Wichtig ist der Teil, der in vielen Vereinbarungen fehlt: ein vereinbarter Prozess für Änderungen. Ohne ihn wird jeder Change zur Einzelverhandlung. Mit ihm ist klar, welche Changes nur angezeigt werden, welche beraten werden und welche eine Anpassung der Anlage brauchen.
Schritt 1: Jeden Change einordnen
Wer das Message Center sichtet, ordnet jeden relevanten Eintrag einer von drei Klassen zu. Die Einordnung ist ein Vorschlag des Betriebsteams, die Klassen selbst sind mit dem Betriebsrat vereinbart.
- Klasse A, ohne Relevanz: Änderungen an Oberfläche, Fehlerbehebungen, Leistungsverbesserungen. Es entstehen keine neuen personenbezogenen Daten und keine neuen Auswertungsmöglichkeiten. Sammelinformation, zum Beispiel monatlich.
- Klasse B, Information: Neue Funktionen im Rahmen bereits vereinbarter Dienste, die keine neuen Auswertungen ermöglichen oder bereits durch die Vereinbarung abgedeckt sind. Information vor dem Rollout, mit Möglichkeit zur Rückfrage.
- Klasse C, Beratung: Neue Dienste, neue Datenarten, neue Berichte mit Personenbezug, KI-Funktionen oder geänderte Standardwerte, die Auswertungen erweitern. Die Funktion bleibt deaktiviert oder wird verschoben, bis eine Einigung vorliegt.
Viele Microsoft-Funktionen lassen sich vor dem Rollout über Richtlinien deaktivieren oder auf Pilotgruppen beschränken. Ob das geht, gehört zu den ersten Fragen der technischen Bewertung. Denn davon hängt ab, ob Zeit für die Abstimmung bleibt oder ob gehandelt werden muss, bevor Microsoft den Standardwert ändert.
Schritt 2: Den Change-Steckbrief ausfüllen
Für jeden Change der Klasse C, besser auch für Klasse B, entsteht ein Steckbrief von höchstens zwei Seiten. Er beantwortet die Fragen, die der Betriebsrat ohnehin stellen würde, bevor er sie stellt.
- Was ändert sich? In zwei, drei Sätzen, ohne Marketingsprache. Mit Link auf den Message-Center-Eintrag und das geplante Datum.
- Wer ist betroffen? Alle Nutzenden, bestimmte Gruppen, nur Administratoren?
- Welche Daten entstehen? Neue Protokolle, Berichte, Statusinformationen, Inhalte, die eine KI verarbeitet.
- Wer kann sie sehen und auswerten? Die betroffene Person selbst, Kolleginnen und Kollegen, Vorgesetzte, Administratorrollen? Mit Namen der Rollen.
- Wie lange werden sie gespeichert? Aufbewahrung bei Microsoft und mögliche eigene Exporte.
- Was ist konfigurierbar? Tenantweit, pro Richtlinie, pro Person. Was ist der Standardwert, was wird empfohlen?
- Wie wird es zurückgenommen? Lässt sich die Funktion wieder abschalten, und was passiert dann mit den entstandenen Daten?
- Was empfiehlt das Betriebsteam? Mit Begründung, getrennt von den Fakten.
Der Steckbrief wird einmal sorgfältig erstellt und dann wiederverwendet: für Informationssicherheit, Datenschutz, Servicedesk und die Dokumentation der Konfiguration.
Typische Kandidaten für Klasse C
Welche Funktionen in Ihrer Organisation relevant sind, hängt von der Vereinbarung ab. Erfahrungsgemäss lohnt ein genauer Blick bei diesen Themen:
- Nutzungsberichte mit Namen: Im Microsoft 365 Admin Center lässt sich festlegen, ob Berichte Benutzer-, Gruppen- und Site-Namen anzeigen oder anonymisieren. Eine Änderung dieser Einstellung ist ein typischer Fall für die Abstimmung.
- Besprechungsdaten in Teams: Anwesenheitsberichte, Aufzeichnungen, Transkripte und Zusammenfassungen. Wer darf sie erstellen, wer sieht sie, wie lange bleiben sie erhalten?
- Präsenz und Lesebestätigungen: Status in Teams und Lesebestätigungen in Chats machen Verhalten für andere sichtbar.
- Viva Insights und Analysen: Persönliche Auswertungen, Auswertungen für Führungskräfte und organisationsweite Analysen sind unterschiedlich zu bewerten.
- Microsoft 365 Copilot und Agents: Auf welche Daten greift die KI zu, welche Nutzungsberichte entstehen, welche Agents dürfen Fachbereiche selbst erstellen?
- Purview-Funktionen: Audit, Kommunikationsüberwachung und Insider-Risikomanagement sind gerade wegen ihres Zwecks sorgfältig zu regeln.
Schritt 3: Entscheiden, umsetzen, nachweisen
Die Entscheidung des Gremiums wird zur Konfigurationsvorgabe. Das Betriebsteam setzt sie um und dokumentiert, mit welcher Richtlinie oder Einstellung sie erfüllt wird. So lässt sich später jederzeit belegen, dass der Tenant der Vereinbarung entspricht.
Dazu gehört, regelmässig zu prüfen, ob die vereinbarte Konfiguration noch gilt. Einstellungen werden durch Microsoft-Änderungen, neue Standardwerte oder eine «kurze Änderung» im Admin-Portal verschoben. Ein automatisierter Abgleich zwischen dokumentiertem Sollzustand und tatsächlicher Konfiguration findet solche Abweichungen, bevor sie zum Konflikt werden.
Was den Prozess schnell macht
- Früh sichten: Microsoft kündigt viele Änderungen Wochen vorher an. Wer das Message Center wöchentlich sichtet, hat Zeit für die Abstimmung.
- Bündeln: Klasse-A- und Klasse-B-Changes gesammelt vorlegen, damit die Zeit in den Sitzungen für Klasse C bleibt.
- Vorführen statt beschreiben: Eine Funktion im Testtenant zu zeigen, beantwortet viele Fragen in fünf Minuten.
- Fakten und Empfehlung trennen: Der Betriebsrat muss sich darauf verlassen können, dass der Steckbrief vollständig ist, auch wenn die Empfehlung ihm nicht gefällt.
- Einen festen Ansprechpartner benennen: Rückfragen gehen an eine Person, die den Tenant kennt, und nicht in eine Warteschlange.
Wenn Sie Unterstützung bei der Bewertung und Aufbereitung von Microsoft-365-Changes brauchen, finden Sie unser Angebot unter Microsoft-365-Betrieb für grosse Organisationen.
Schreibt hier über Probleme, die in echten Projekten auftreten: Microsoft 365, Security, Automatisierung und digitale Systeme. Hängen Sie gerade an genau diesem Thema? Dann lösen wir es gemeinsam, von der Diagnose bis zur Umsetzung.
Kontakt aufnehmen