Die Regeln, die Sie durchsetzen wollen, sprechen die falsche Sprache

Sven Seidenberg 3. November 2026 4 Min. Lesezeit

Fragen Sie ein Governance-Team, welche Regeln es gern durchsetzen würde, und die Antwort kommt selten nur im Vokabular von Microsoft 365. Sie kommt in der Sprache des Unternehmens.

Typische Wünsche klingen so. Externe Benutzer sollen raus aus Abteilungsteams. Kundenprojekträume sollen strenger geschützt sein als interne. Speicherkosten sollen bei dem Geschäftsbereich oder Projekt landen, das sie verursacht. Ein Arbeitsbereich soll geschlossen werden, wenn sein Projekt endet.

Keine dieser Regeln ist exotisch, und jede scheitert aus demselben Grund. Microsoft 365 beschreibt einen Arbeitsbereich über seinen Eigentümer, sein Vertraulichkeitslabel, seinen Gruppentyp und seinen Namen. Welchem Kunden er dient oder welche Kostenstelle ihn bezahlt, weiß es nicht. Die Absicht ist da. Es fehlen die Wörter, die die Regel braucht.

Teams übersetzen bisher von Hand

Governance-Teams haben nicht auf eine Lösung gewartet. Sie kodieren Bedeutung in Namen, sodass “PRJ-4021 Contoso Migration” einen Projektcode trägt, den eine Regel oder ein Bericht erkennen kann. Sie bauen Nebendatenbanken und SharePoint-Listen für die Geschäftsfelder, die die IT für ihre Anwendungsfälle braucht.

Beide Ansätze beweisen, wie wichtig der geschäftliche Kontext ist, und beide sind fragil. Ein umbenanntes Team fällt still aus der Regel, die dafür geschrieben wurde. Eine Nebendatenbank speichert Werte, kann aber nicht danach handeln, und meist hängt sie davon ab, dass eine einzelne Person sie am Leben hält.

Die Kosten werden leicht unterschätzt, weil sie langsam wachsen. Jede neue Regel braucht eine neue Konvention. Jede Konvention braucht jemanden, der sie überwacht. Jede Umstrukturierung bricht einige davon, und niemand merkt es, bis ein Audit oder ein Vorfall die Lücke zeigt.

Mit der Zeit steckt das Governance-Team mehr Aufwand in die Pflege der Übersetzung als in die Regeln, für die sie gebaut wurde. Heraus kommt ein Governance-Modell, das viel über die Objekte von Microsoft weiß und sehr wenig über das Unternehmen, dem sie dienen.

KI erhöht den Preis dieser Lücke

Früher war das ein Effizienzproblem. KI macht daraus eine Risikofrage.

Microsoft 365 Copilot antwortet aus den Inhalten, die Benutzer bereits erreichen können. Damit klingen die wichtigsten Governance-Entscheidungen heute wie Geschäftsentscheidungen. Welches Kundenmaterial muss streng geschützt sein? Welche Abteilungsbereiche sollten nie Gäste enthalten? Welche Projekträume sollten geschlossen sein, bevor ein Assistent sie ein Jahr später wieder hervorholt?

Ein Governance-Programm, das einen Kundenraum nicht von einer Community-Site unterscheiden kann, beantwortet diese Fragen nicht, wie stark seine technischen Kontrollen auch sind.

Holen Sie das Unternehmen ins Governance-Modell

Die Lösung: Hören Sie auf, zu übersetzen und die Daten zentral von Hand zu pflegen. Bringen Sie die Begriffe des Unternehmens in die Governance-Ebene, halten Sie sie aus den Systemen und von den Menschen aktuell, denen sie gehören, und lassen Sie jede Regel sie direkt nutzen.

Drei Prinzipien halten wir dabei für entscheidend.

Geschäftlicher Kontext sollte aus seiner Quelle kommen. Die Finanzabteilung verantwortet Kostenstellen. Die Personalabteilung verantwortet Abteilungen. Werte, die in Arbeitsbereiche abgetippt werden, sind bei der ersten Änderung falsch.

Eigentümer sollten nur nach dem gefragt werden, was kein System weiß. Und zwar innerhalb von Arbeit, die sie ohnehin erledigen, etwa einem regelmäßigen Review.

Jedes Feld muss sich seinen Platz verdienen. Ein Feld, das nur in einer Spalte steht, macht Ihr Inventar ordentlicher. Ein Feld, das eine Regel, einen Bericht oder ein Review steuert, ergibt ein Governance-Modell.

Was sich ändert, wenn die Governance die Sprache des Unternehmens spricht

Die erste Änderung betrifft die Regeln selbst. Sie werden kürzer und genauer, weil sie prüfen, worauf es dem Unternehmen ankommt, statt eines Ersatzmerkmals. Eine Regel auf Basis von “Arbeitsbereichstyp ist Kundenprojekt” übersteht Umbenennungen, Umstrukturierungen und neue Namensstandards.

Die zweite Änderung betrifft, wer die Ergebnisse lesen kann. Ein Bericht, gruppiert nach Kostenstelle oder Kunde, sagt Finanzabteilung, Rechtsabteilung und Bereichsleitungen etwas. Governance ist dann nicht mehr eine Sammlung von IT-Dashboards, sondern ein Nachweis, den andere Teams nutzen können und mit dem die IT klarer mit ihnen kommuniziert.

Die dritte Änderung betrifft Ihr Tempo. Kommt eine neue Anforderung, etwa ein Kundenvertrag mit strengeren Vorgaben zum Umgang mit Daten, lautet die Frage nur noch: Welche Arbeitsbereiche gehören zu diesem Kunden? Die Antwort haben Sie in Minuten, statt ein Discovery-Projekt zu starten.

So sieht das in Rencore Governance aus

Diese Überlegungen haben Custom Metadata in Rencore Governance geprägt. Kunden definieren eigene Felder und Referenzlisten, etwa Arbeitsbereichstyp oder Kostenstelle. Referenzlisten bleiben über einen geplanten Import aktuell, und Review-Schritte fragen Eigentümer nur nach den Werten, die noch fehlen.

Diese Felder wirken dann überall dort, wo Rencore bereits fragt, welche Arbeitsbereiche Sie meinen: in Richtlinien, Segmenten, Berichten und Reviews. “Externe Benutzer aus Abteilungsteams entfernen” ist dann kein Wunsch mehr, sondern eine Richtlinie.

Wir wissen, dass jedes Unternehmen anders ist. Deshalb hält Custom Metadata, was der Name verspricht: Es ist wirklich anpassbar. Sie können bestehende Objekte wie Teams um eigene Eigenschaften erweitern und eigene Beziehungen anlegen, und Sie können vollständige Objekte aus Ihrem Unternehmen hineinholen, etwa Projekte oder Kostenstellen.

Beginnen Sie mit der Regel, die Sie nicht schreiben können

Ihr Team kann vermutlich ohne Nachdenken eine nennen. Alle sind sich einig, und niemand kann sie durchsetzen, weil das System nicht weiß, wovon die Regel spricht. Genau dort sollten Sie anfangen. Erste Tests haben gezeigt, dass Anwendungsfälle sehr anspruchsvoll werden können. Beginnen Sie deshalb klein, mit einem klar abgegrenzten Anwendungsfall, den alle verstehen und der eine klare Richtung hat.

Sprechen Sie mit einem Experten über Ihre Regel.

Häufige Fragen dazu

Warum kann Microsoft 365 keine Regeln durchsetzen, die in Geschäftsbegriffen wie Kunde oder Kostenstelle formuliert sind?

Weil Microsoft 365 einen Arbeitsbereich über seinen Eigentümer, sein Vertraulichkeitslabel, seinen Gruppentyp und seinen Namen beschreibt. Es gibt kein Feld dafür, welchem Kunden ein Arbeitsbereich dient, zu welcher Abteilung er gehört oder welche Kostenstelle ihn bezahlt. Eine Regel wie "Externe Benutzer raus aus Abteilungsteams" braucht genau diese Information. Die Absicht ist also da, aber das System hat nichts, wogegen es die Regel prüfen kann.

Was spricht dagegen, Projektcodes in Namen von Arbeitsbereichen zu kodieren oder eine Nebenliste zu führen?

Beide Ansätze zeigen, wie wichtig der geschäftliche Kontext ist, und beide sind fragil. Ein umbenanntes Team fällt still aus der Regel, die für seinen alten Namen geschrieben wurde. Eine Nebendatenbank oder SharePoint-Liste speichert Werte, kann aber nicht danach handeln, und meist hängt sie davon ab, dass eine einzelne Person sie pflegt. Jede neue Regel braucht eine neue Konvention, und jede Umstrukturierung bricht unbemerkt einige davon, bis ein Audit oder ein Vorfall die Lücke zeigt.

Warum zählt geschäftlicher Kontext in der Governance mehr, sobald Copilot ausgerollt ist?

Microsoft 365 Copilot antwortet aus den Inhalten, die Benutzer bereits erreichen können. Damit klingen die wichtigsten Governance-Entscheidungen plötzlich wie Geschäftsentscheidungen: Welches Kundenmaterial muss streng geschützt sein, welche Abteilungsbereiche sollten nie Gäste enthalten, und welche Projekträume sollten geschlossen sein, bevor ein Assistent sie ein Jahr später wieder hervorholt? Ein Governance-Programm, das einen Kundenraum nicht von einer Community-Site unterscheiden kann, beantwortet diese Fragen nicht, wie stark seine technischen Kontrollen auch sind.

Wie lässt Rencore Governance Regeln mit Geschäftsbegriffen arbeiten?

Mit Custom Metadata in Rencore Governance definieren Sie eigene Felder und Referenzlisten, etwa Arbeitsbereichstyp oder Kostenstelle, erweitern bestehende Objekte wie Teams um eigene Eigenschaften und Beziehungen und holen Geschäftsobjekte wie Projekte hinein. Referenzlisten bleiben über einen geplanten Import aktuell, und Review-Schritte fragen Eigentümer nur nach den Werten, die noch fehlen. Die Felder wirken dann in Richtlinien, Segmenten, Berichten und Reviews.

Über den Autor

Sven Seidenberg

Sven ist Microsoft 365 Governance Consultant bei Rencore. Er begann seine Karriere in der Microsoft 365-Welt etwa zur gleichen Zeit, als Microsoft Teams auf den Markt kam, ein Produkt, das ihn bis heute begleitet und inspiriert. In den letzten Jahren hat er verschiedene Unternehmen bei ihrer Umstellung auf die Microsoft 365-Cloud und der Transformation ihrer Arbeitsweise beraten. In seiner Funktion bei Rencore hilft Sven nun Kunden und Partnern dabei, die richtigen Fragen zu ihren Governance-Herausforderungen zu stellen, und unterstützt sie dabei, den maximalen Nutzen aus Rencore Governance zu ziehen. Er ist Mitautor mehrerer E-Books und eines Buches darüber, wie man am besten mit Microsoft 365-Apps und -Diensten arbeitet.