SharePoint Struktur im Mittelstand: Warum Ihr altes Dateiserver-Denken das Chaos programmiert
- Marcus Machon
- 17. Jan.
- 15 Min. Lesezeit
Aktualisiert: 28. Mai
Wer SharePoint nutzt wie Laufwerk Z:, programmiert das Chaos vor. Teams wird eingeführt, SharePoint läuft im Hintergrund mit, Ordner werden migriert und irgendwann fragt niemand mehr, ob die Struktur eigentlich noch Sinn ergibt.
Das Problem ist nicht SharePoint. Der Suchbegriff SharePoint Struktur Mittelstand klingt zwar nach Ordnerplan, beschreibt aber in Wirklichkeit eine Führungsfrage: Wer besitzt welchen Arbeitsraum, welche Information ist gültig und was darf Microsoft 365 Copilot später finden? Wenn die Cloud nur wie ein schnellerer Dateiserver behandelt wird, entstehen tiefe Ordnerbäume, kaputte Berechtigungsvererbungen, lokale Sync-Fallen und ein unangenehmer Sichtbarkeitseffekt: Die KI findet genau das, worauf Mitarbeitende technisch Zugriff haben.
Wenn Sie nach SharePoint Ordnerstruktur suchen, suchen Sie in Wirklichkeit nach SharePoint Informationsarchitektur: Welche Arbeitsbereiche gibt es? Wer besitzt sie? Welche Inhalte sind gültig? Welche Informationen darf Microsoft 365 Copilot später finden? Genau hier beginnt SharePoint Governance Mittelstand.
Niemand wacht morgens auf und denkt: "Ich hätte heute gerne eine bessere Informationsarchitektur." Aber fast alle kennen die Folgen: Wo liegt die aktuelle Preisliste? Warum ist das alte Angebot plötzlich wieder im Umlauf? Warum darf eine Person etwas sehen, das sie fachlich nicht sehen sollte?
Das wirkt wie Kleinkram, ist aber ein Strukturproblem. SharePoint ist heute nicht mehr nur Ablage. Es ist das Fundament für Teams, Suche, Copilot Chat, Recherche-Agenten und SharePoint Agents. Dieser Beitrag zeigt ein pragmatisches Modell für Fach- und IT-Leitende.
Diese Linie begleitet mich schon lange: Excel ist keine Datenbank, Teams ist nicht nur Chat und SharePoint ist kein Fileserver. Das klingt erst wie ein zugespitzter LinkedIn-Satz. In Projekten wird daraus aber eine sehr praktische Architekturfrage: Welches Werkzeug übernimmt welche Aufgabe, und wo beginnt das Risiko, wenn alles nur noch wie ein Ordner aussieht?
Wenn Sie den KI-Teil zuerst prüfen möchten: Im Beitrag Microsoft 365 Copilot Readiness beschreibe ich, warum Berechtigungen, Datenbestand und Owner vor einem Copilot-Rollout wichtiger sind als die nächste Prompt-Schulung.
Was Sie aus diesem Beitrag mitnehmen:
warum die alte Fileserver-Logik in SharePoint besonders gefährlich wird,
wie das Büro-Haus-Modell OneDrive, Teams, Kommunikationswebsite und Hub Sites trennt,
welche Entscheidungen Projektleitung und Fachbereiche selbst treffen müssen,
und warum Copilot-Readiness bei SharePoint-Struktur beginnt, nicht bei Prompts.
Warum ist eine alte Fileserver-Struktur in SharePoint riskant?
Eine alte Fileserver-Struktur wird in SharePoint riskant, weil Ordnerlogik, Berechtigungsvererbung und lokale Synchronisation dort anders funktionieren als auf einem klassischen Laufwerk.
Viele Unternehmen haben Microsoft 365 unter Druck eingeführt. Während der Pandemie war das nachvollziehbar: Hauptsache, Zusammenarbeit funktionierte irgendwie. Eine AvePoint-Umfrage aus 2021 zeigt, dass 75 % der befragten Organisationen Microsoft Teams ohne passende Governance oder Sicherheitsmaßnahmen ausgerollt hatten; nur 22 % konnten bestimmen, wer Zugriff auf bestimmte Daten hat (AvePoint, 2021).
So wird aus "wir haben Teams" ein Governance-Problem. Unter Teams liegt oft eine SharePoint-Welt, die niemand bewusst entworfen hat: "Firma intern", "Projekte", "Region Nord", 14 Ordnerebenen, Sonderrechte und historische Gruppen ohne klaren Zweck.
Ja, man kann so arbeiten. So wie man theoretisch auch einen Ferrari mit Kohle befeuern könnte. Aber es ist nicht das System, für das SharePoint gebaut wurde. Microsoft beschreibt die moderne SharePoint-Architektur ausdrücklich als flacheres Modell: Jede moderne Site ist eine eigene Site Collection und kann über Hub Sites verbunden werden, statt eine klassische, tief verschachtelte Subsite-Hierarchie zu bauen (Microsoft Learn, 2026).
Die erste Frage lautet deshalb nicht: "Welche Ordner brauchen wir?" Die erste Frage lautet: Ist das ein Arbeitsraum, eine Infotafel, ein Archiv, ein Tresor oder steuernde Prozessinformation? Wer diese Entscheidung überspringt, baut in SharePoint nur den alten Dateiserver nach und wundert sich später, warum Teams, Suche und Copilot dieselbe Unordnung nur schneller sichtbar machen.
Fehler 1: Eine große Website für alles
Der häufigste Fehler ist eine große SharePoint-Website für alles: Marketing, Vertrieb, Geschäftsleitung, HR, Projekte, Vorlagen, Archive. Das fühlt sich vertraut an, weil es aussieht wie das alte Laufwerk. Genau deshalb ist es gefährlich.
In SharePoint sind Sites nicht nur Ablageorte. Sie sind Sicherheits-, Navigations-, Such- und Verantwortungsgrenzen. Wenn zu viele Kontexte in einer Site landen, wird die Berechtigungsebene immer kleinteiliger. Irgendwann kann die IT technisch noch Rechte anzeigen, aber fachlich nicht mehr erklären.
Das alte Fileserver-Muster verschärft diesen Effekt: Unterordner werden zum Ersatz für Architektur. Dann wird Vererbung gebrochen, eine HR-Unterlage bekommt eine Sonderberechtigung, ein Projektordner wird nach außen geteilt und ein Jahr später weiß niemand mehr, welche Ausnahme noch gilt. Das ist nicht nur unordentlich. Es ist ein Steuerungsproblem.
Fehler 2: Alles lokal synchronisieren
Der zweite Fehler ist der Reflex, SharePoint-Bibliotheken wie Netzlaufwerke in den Windows-Datei-Explorer zu spiegeln. Das ist bequem, klar. Aber es erzeugt eine trügerische Sicherheit: Was lokal wie ein Ordner aussieht, bleibt ein bidirektional synchronisierter Cloud-Bestand.
Wenn eine Person lokal Dateien löscht, betrifft das nicht nur ihren Laptop. Je nach Situation wird auch die Cloud-Version gelöscht. Der eigentliche Schaden ist oft ein anderer: Das Team verliert Vertrauen in das System.
Dazu kommt die Copilot-Perspektive: Was dauerhaft auf lokalen Laufwerken oder alten Netzlaufwerken bleibt, kann Microsoft 365 Copilot nicht sinnvoll in den Arbeitskontext einbeziehen. Was dagegen unsauber in SharePoint liegt, kann er finden, auch wenn es fachlich längst veraltet ist. Beides ist schlecht. Die Lösung ist nicht "alles synchronisieren", sondern klare Arbeitsorte mit verständlicher Verknüpfungslogik.
Dazu kommt ein Unterschied, der in Schulungen oft fehlt: "Synchronisieren" und "Verknüpfung zu OneDrive" nutzen zwar beide die OneDrive-Synchronisierungs-App, verhalten sich aber nicht gleich. Microsoft beschreibt OneDrive-Verknüpfungen als vielseitigere Option mit Zugriff über mehrere Geräte und besserer Performance, wenn sie verfügbar sind (Microsoft Support, 2026). Für die Praxis heißt das: einzelne aktive Arbeitsordner eher als Verknüpfung, ganze Bibliotheken und Archive nicht dauerhaft in den Explorer holen. Klassischer Sync bleibt Ausnahme, nicht Standard.
Wichtig ist auch der sichere Ausstieg. Microsoft beschreibt, dass das Entfernen einer Verknüpfung aus OneDrive nur die persönliche Verknüpfung entfernt; wenn dagegen Inhalte innerhalb der Verknüpfung gelöscht werden, wirkt das auf die Originaldateien (Microsoft Support, 2026). Das ist eine kleine Klick-Regel mit großer Wirkung: Mitarbeitende müssen lernen, Verknüpfungen zu entfernen, nicht Teamdaten im Explorer "aufzuräumen".
Und genau hier entstehen in Projekten die ersten Support-Wellen. "SharePoint ist kaputt" heißt dann oft nur: Wir haben den alten Explorer-Reflex nicht sauber eingegrenzt. Microsoft dokumentiert für OneDrive und SharePoint unter anderem Performance- und Pfadlängenlimits; für optimale Leistung empfiehlt Microsoft, nicht mehr als 300.000 Elemente zu synchronisieren (Microsoft Support, 2026). Für den Mittelstand heißt das: Synchronisieren gezielt einsetzen, nicht als Standardantwort auf jede Ablagefrage.
Die ausführliche Einordnung dazu steht im Beitrag OneDrive, Teams und SharePoint: Warum der Datei-Explorer nicht Ihr Hauptarbeitsplatz sein sollte.
Warum braucht Copilot eine saubere SharePoint Informationsarchitektur?
Copilot braucht eine saubere SharePoint-Informationsarchitektur, damit Antworten auf aktuellen, auffindbaren und eindeutig verantworteten Informationen beruhen.
Der dritte Fehler wird erst durch KI wirklich sichtbar. Das Thema ist nicht nur Oversharing. Es ist auch Antwortqualität. Wenn dieselbe Prozessbeschreibung in fünf Teams liegt, wenn "final_v3_neu" neben "final_final" existiert oder alte Projektstände nie archiviert wurden, dann findet Copilot nicht automatisch die fachlich gültige Wahrheit.
Copilot räumt keine Dateileichen auf. Er stolpert darüber. Und manchmal formuliert er daraus auch noch eine erstaunlich überzeugende Antwort.
Microsoft beschreibt, dass der semantische Index für Microsoft 365 Copilot Relevanz und Genauigkeit der Suche verbessert und dabei Microsoft Graph, SharePoint-Dateien, Inhalte und Metadaten nutzt (Microsoft Learn, 2026). Für Projektleitungen heißt das: Metadaten, klare Orte, aktuelle Dokumente und eindeutige Owner verbessern die Grundlage, auf der Copilot Chat, Recherche-Agenten und SharePoint Agents Antworten bilden.
Metadaten sind dabei kein Selbstzweck. Ich erkläre sie gern wie Filter beim Online-Shopping: Niemand möchte durch 14 Unterkategorien klicken, wenn Farbe, Größe, Hersteller und Verfügbarkeit sauber filterbar sind. Genauso helfen Dokumentkategorie, Prozess-Owner, Review-Datum und Vertraulichkeit dabei, dass Menschen und KI nicht zwischen zehn ähnlich benannten Dateien raten müssen.
Fehler 3: Datei-Hoarding und Dark Data
Ein unterschätzter Teil davon ist Datei-Hoarding: Alles wird behalten, weil Löschen Angst macht. Alte Angebote, Kopien, Exporte, Screenshots, "nur zur Sicherheit"-Archive. Ein Teil davon ist Dark Data: Daten, deren Zweck, Aktualität oder Wert niemand mehr kennt. Splunk berichtete, dass 55 % der Unternehmensdaten Dark Data seien (Splunk, 2019). Veritas kam im älteren Databerg Report auf 52 % dunkle Daten plus 33 % redundante, veraltete oder triviale Daten (Veritas, 2016). Vendor-Reports, ja. Aber das Muster ist real.
Für Menschen heißt das: Sie suchen länger und vertrauen Suchergebnissen weniger. Für Copilot heißt es: Die KI muss aus vielen möglichen Treffern Ausschnitte auswählen. Sie hat kein unbegrenztes Arbeitsgedächtnis. Wenn zehn Versionen derselben Datei herumliegen, wird "die richtige Antwort" schwerer.
Deshalb braucht SharePoint nicht nur bessere Ordner, sondern auch Löschregeln. Microsoft Purview kann für SharePoint und OneDrive Aufbewahrungsrichtlinien und Bezeichnungen anwenden; Microsoft dokumentiert, dass Dateien nach Regeln beibehalten und gelöscht werden können (Microsoft Learn, 2026). Das klingt bedrohlich. Es wird handhabbar, wenn vorher klar ist: Was ist Vertragsdokument? Was ist Arbeitskopie? Was ist Projektarchiv? Was darf nach 2, 5 oder 10 Jahren weg?
Der Sicherheitsaspekt bleibt trotzdem wichtig. Microsoft 365 Copilot arbeitet innerhalb der vorhandenen Microsoft-365-Berechtigungen; Microsoft beschreibt explizit, dass Copilot Inhalte nur im Rahmen der bestehenden Nutzerberechtigungen nutzt und dieselben Sicherheits-, Compliance- und Datenschutzkontrollen respektiert (Microsoft Learn, 2026).
Das klingt beruhigend. Ist es aber nur, wenn die Berechtigungen stimmen. Wenn ein Gehaltsdokument, eine Vertragsliste oder ein altes Board-Protokoll für "Jeder außer externen Benutzern" freigegeben ist, ist das kein Copilot-Fehler. Copilot macht sichtbar, was vorher schon falsch freigegeben war.
Varonis hat 2025 rund 1.000 reale IT-Umgebungen mit fast 10 Milliarden Dateien analysiert und berichtet, dass 99 % der Organisationen sensible Daten haben, die von KI leicht gefunden werden können (Varonis, 2025). Das ist Vendor-Forschung, also mit Vorsicht zu lesen. Aber die Richtung passt leider zu dem, was viele M365-Admins aus der Praxis kennen: Oversharing ist selten Absicht. Es ist gewachsene Unordnung.
Auch das ist kein Randthema mehr: In einer Gartner-Befragung, über die Computerworld berichtet hat, gaben 40 % der IT-Leitenden an, Microsoft-365-Copilot-Rollouts wegen Oversharing oder Data-Governance-Problemen um mindestens drei Monate verschoben zu haben; 64 % erwarteten erheblichen Governance-Aufwand (Computerworld / Gartner, 2025). Genau deshalb ist SharePoint-Struktur heute nicht mehr nur "Ablage aufräumen", sondern Copilot-Readiness.
Was muss Projektleitung 2026 über SharePoint Agents wissen?
SharePoint Agents machen alte Ablageprobleme sichtbarer. Für Projektleitungen heißt das: Erst Zuständigkeit, Datenbereiche und Berechtigungen klären, dann Agenten freigeben.
Seit 2026 ist SharePoint nicht mehr nur Ablage und Intranet. Mitarbeitende können Agenten nutzen, also kleine KI-Assistenten, die Fragen zu Sites, Ordnern oder Dateien beantworten.
Microsoft dokumentiert bei SharePoint Agents, dass Antworten von den Berechtigungen der jeweiligen Person auf die Datenquellen abhängen (Microsoft Learn, 2026). Ein Agent ist also keine Sicherheitsprüfung. Er nutzt die vorhandene Struktur. Wenn diese falsch ist, wird er nicht klüger, sondern nur schneller.
Meine eigene Erfahrung mit frühen SharePoint-Agents war genau deshalb zweigeteilt: Das Potenzial ist enorm, weil Fachbereiche sehr schnell einen inhaltsnahen Assistenten bekommen. Gleichzeitig sind die Grenzen brutal sichtbar, sobald Seiten, Bibliotheken, Listen, Metadaten oder Berechtigungen nicht sauber vorbereitet sind. Ein Agent ist kein magischer Architekt. Er ist eher ein Vergrößerungsglas.
Wie ich Kundendaten, SharePoint-Quellen und externe KI-Werkzeuge bewusst trenne, beschreibe ich im Beitrag Microsoft 365 Copilot Agent SharePoint: Kundendaten sauber trennen. Genau diese Trennung wird wichtig, wenn ein Agent Kundeninfos findet, aber nicht alles in jede KI-Welt wandern soll.
Restricted SharePoint Search kann für Copilot vorübergehend eingrenzen, welche SharePoint-Sites in der Suche auftauchen. Microsoft beschreibt die Funktion aber als kurzfristige Maßnahme, nicht als langfristige Governance-Lösung; sie ist keine Sicherheitsgrenze und ändert keine Berechtigungen (Microsoft Learn, 2026). Kurz: Restricted Search kauft Zeit. Sie räumt nicht auf.
Der nachhaltigere Hebel ist Governance. Microsoft bietet dafür mit SharePoint Advanced Management unter anderem Berichte zu offenen Freigaben, Site Access Reviews und Einblicke in Agent-Zugriffe (Microsoft Learn, 2026). Das Tool liefert Hinweise. Entscheiden müssen Fachbereiche und Projektleitung.
SharePoint Struktur Mittelstand: Wie baut man sie sinnvoll auf?
Eine gute SharePoint Struktur im Mittelstand trennt private Entwürfe, Teamarbeit, veröffentlichte Information und Navigation konsequent voneinander.
Die Kernfrage ist also nicht: Wie kopieren wir den alten Dateiserver nach Microsoft 365? Die bessere Frage lautet: Wie baut man eine SharePoint Struktur im Mittelstand sinnvoll auf?
Ich nutze dafür gern das Büro-Haus-Modell. Nicht, weil Metaphern alles lösen, sondern weil sie Entscheidungen einfacher machen: Welcher Inhalt gehört wohin? Wer braucht einen Schlüssel? Wer ist verantwortlich? Und was darf Copilot später finden?
Falls Sie gerade nach einer SharePoint Ordnerstruktur suchen: Nehmen Sie das als Startpunkt, nicht als Zielbild. Gute Struktur heißt, die richtigen Arbeitsorte zu trennen und Ordner nur dort zu nutzen, wo sie wirklich Orientierung schaffen.
Beispiel aus meinem Tenant: vier Hubs, klare Tresore
In meinem eigenen Nous-Works-Tenant nutze ich das Büro-Haus-Modell nicht nur als Grafik, sondern als kleine Referenzarchitektur. Es gibt einen Intranet-Hub für unternehmensweite Orientierung, einen Operations-Hub für interne Arbeit, einen Blueprint-Lab-Hub für Tests und öffentliche Artefakte sowie einen Client-Success-Hub für kundensichtbare Zusammenarbeit.
Darunter sind Sites nicht nach Laune benannt, sondern nach Zweck: OPS-* für operative Arbeit, EXT-* für externe Zusammenarbeit, FIN-* für Finanzunterlagen und LGL-* für rechtlich relevante Dokumente. Dazu kommen wenige Vertraulichkeitsstufen: öffentlich, intern, vertraulich Projekt und streng vertraulich.
Der wichtige Punkt ist nicht die Zahl der Sites. Der wichtige Punkt ist die Schnittkante. Finale Kundenverträge gehören in einen rechtlich geschützten Client Vault, Finanzunterlagen in einen eigenen Fiscal-Records-Bereich, laufende Kundenarbeit in EXT-*, interne Vorlagen und Prozesse in OPS-*. Ein Copilot- oder SharePoint-Agent darf später nicht raten müssen, ob eine Datei Entwurf, finale Rechtsakte, Rechnung oder Arbeitsnotiz ist.
Gerade für kleinere Organisationen wirkt das im ersten Moment streng. In der Praxis macht es die Struktur menschlicher: Mitarbeitende müssen nicht wissen, welche technische SharePoint-Funktion dahintersteht. Sie müssen nur verstehen, welcher Raum welche Verantwortung hat.
Baustein 1: OneDrive ist der Rucksack
OneDrive ist der persönliche Rucksack. Dort liegen Entwürfe, Notizen, eigene Arbeitsstände und Dinge, die noch nicht teamrelevant sind. Der Rucksack ist praktisch, aber er ist kein Projektraum.
Die Regel ist simpel: Sobald ein Dokument für andere relevant wird, wandert es aus OneDrive in den passenden Team-Kontext. Sonst entstehen verwaiste Dateien, persönliche Schattenablagen und Links, die nach einem Rollenwechsel plötzlich niemand mehr sauber zuordnen kann.
Baustein 2: Teams und SharePoint Team Site sind der Projektraum
Microsoft Teams ist die Tür zum Raum: Chat, Meetings, Kanäle, Aufgaben. SharePoint ist der Aktenschrank in diesem Raum. Jedes Team bekommt seinen eigenen Schrank, also seine eigene SharePoint Team Site.
Microsoft beschreibt diese Verbindung sehr konkret: Wenn ein neues Team erstellt wird, entsteht eine verbundene SharePoint-Website; Dateien im Teams-Reiter "Dateien" liegen auf SharePoint (Microsoft Learn, 2026). Das ist der zentrale Unterschied zum alten Dateiserver-Denken. Ein Projekt ist nicht ein Unterordner im großen Firmenschrank. Ein Projekt ist ein eigener Raum mit eigener Mitgliedschaft, eigener Verantwortlichkeit und eigener Lebensdauer.
Auch die Kanalstruktur gehört dazu. Zu wenige, sehr allgemeine Kanäle wirken am Anfang übersichtlich, werden aber schnell zu Sammelbecken. Zu viele Kanäle werden unbenutzbar. Die bessere Frage ist: Welche Arbeitsstränge brauchen eigene Gespräche, eigene Dateien und eigene Orientierung? Ein Kanal ist kein hübscher Ordnername, sondern ein Arbeitskontext.
Baustein 3: Die Kommunikationswebsite ist die Infotafel
Nicht jeder Ort ist zum Bearbeiten da. Richtlinien, News, fertige Vorlagen, HR-Informationen oder offizielle Prozessbeschreibungen gehören auf eine Kommunikationswebsite. Das ist die Infotafel im Foyer: Viele lesen, wenige veröffentlichen.
Diese Trennung ist wichtig. Wenn fertige Informationen in Projekt-Teams liegen, werden sie schwer auffindbar. Wenn Zusammenarbeit auf der Kommunikationswebsite passiert, wird sie unruhig und riskant. Bühne und Werkstatt gehören getrennt.
Ein gutes Intranet ist deshalb keine digitale Werbetafel für interne PR. Es ist die Navigationsschicht der Arbeit: von der offiziellen Information zum passenden Arbeitsraum, vom Prozess zur Vorlage, vom Kundenbereich zum geschützten Vertragsort. Gerade bei Themen wie KI, Richtlinien oder Statuskommunikation lohnt sich die Frage: Braucht es eine veröffentlichte Kommunikationsseite, einen Diskussionsraum, oder beides sauber getrennt?
Baustein 4: Hub Sites sind das Stockwerk
Wenn aus fünf Projekträumen irgendwann 50 werden, braucht es Orientierung. Hub Sites verbinden thematisch zusammengehörige Sites: zum Beispiel alle Marketing-Sites, alle Operations-Sites oder alle Standorte. Navigation, Design und Suche werden konsistenter, ohne wieder eine tiefe Hierarchie zu erzwingen. Microsoft beschreibt Hub Sites genau als Verbindung verwandter Sites mit gemeinsamer Navigation, Branding und Suche über zugeordnete Sites (Microsoft Learn, 2026).
Für kleine Unternehmen reichen oft wenige Hubs. Für 500 bis 1.000 Mitarbeitende braucht es meist mehr Struktur, klarere Verantwortlichkeiten und regelmäßige Reviews. Aber das Prinzip bleibt gleich: flach bauen, logisch verbinden, nicht im Ordnerbaum verschwinden.
Die sieben Schritte aus dem Chaos heraus
Eine gute SharePoint-Informationsarchitektur entsteht selten in einem großen Big-Bang-Projekt. Besser funktioniert ein kontrollierter Aufräumprozess, der erst die Risiken senkt und dann die Struktur verbessert.
Wichtig: Das ist kein reines IT-Aufräumticket. Die IT kann Sites anlegen, Berechtigungen setzen und Reports ziehen. Aber sie kann nicht entscheiden, welche Prozessbeschreibung gültig ist, welche Ablage fachlich führend sein soll oder wann ein Projekt wirklich abgeschlossen ist. Dafür braucht es Fachbereich, Projektleitung und ein sichtbares Mandat der Führung.
Ein hilfreicher Zwischenschritt ist die Trennung zwischen Dokumenten und steuernden Daten. Dokumente wie Verträge, Angebote, Protokolle oder PDFs gehören in SharePoint-Bibliotheken. Status, Termine, Freigaben, Inventar oder Prüfstände gehören oft besser in Microsoft Lists, Dataverse oder ein anderes strukturiertes System. Wer diese Unterscheidung nicht trifft, landet schnell bei Word-Tabellen, Excel-Kopien und PowerPoint-Folien, die niemand automatisieren oder verlässlich prüfen kann.
Mandat klären: Wer darf alte Gewohnheiten wirklich ändern? Ohne Management-Commitment bleibt SharePoint-Aufräumen eine IT-Bitte, die im Alltag verpufft.
Bestandsaufnahme machen: Welche Sites, Teams, Bibliotheken, externen Freigaben und "Jeder"-Berechtigungen gibt es?
Kritische Inhalte priorisieren: Geschäftsleitung, HR, Finanzen, Kundenverträge und personenbezogene Daten zuerst prüfen. Nicht mit der harmlosesten Site beginnen, nur weil sie angenehm ist.
Arbeitskontexte definieren: Sites nach Arbeitszusammenhang schneiden, nicht blind nach Organigramm. Abteilungen sind ein Startpunkt, aber Prozesse, Projekte und externe Zusammenarbeit entscheiden die Struktur.
Bühne, Werkstatt und Tresor trennen: Kommunikationswebsite für fertige Information, Team Sites für Zusammenarbeit, separate Bibliotheken oder Sites für Verträge, Rechnungen, Personalakten und andere kritische Dokumente.
Sync-, Lösch- und Lebenszyklusregeln setzen: Explorer-Sync nur gezielt; alte Arbeitskopien und Projektarchive nicht endlos mitschleppen; neue Teams nicht ohne Owner, Review-Datum und Archivierungsregel anlegen.
Agenten und Adoption mitdenken: Prüfen, welche SharePoint Agents existieren, wer sie bearbeiten darf und auf welche Datenquellen sie zeigen. Parallel Champions befähigen, damit die Struktur nicht nach drei Wochen wieder in Explorer-Gewohnheiten zurückfällt.
Der wichtigste Schritt ist die Bestandsaufnahme. Ohne sie bauen Sie nur eine neue Oberfläche über alte Berechtigungsprobleme.
Was passiert nach der Konzeption?
Eine SharePoint-Struktur wird erst wirksam, wenn Owner und Mitarbeitende sie im Alltag nutzen, korrigieren und weiterentwickeln können.
Aus meiner Erfahrung scheitert SharePoint selten am ersten Konzept. Es scheitert an Woche drei. Dann synchronisiert wieder jemand den halben Projektbereich in den Explorer, neue Teams werden ohne Owner angelegt und alle fragen wieder: "Wo soll ich das speichern?"
Deshalb gehört zur Umsetzung immer Befähigung. SharePoint Owner müssen wissen, wann ein neuer Bereich sinnvoll ist, wann eine Bibliothek reicht und wann Berechtigungen nicht auf Unterordnern gebrochen werden sollten. Endnutzer brauchen einfache Leitplanken: OneDrive-Sync bleibt Ausnahme, Verknüpfungen sind gezielt einzusetzen und rote Sync-Fehler werden sofort geklärt. Der Engpass ist selten der Button. Meist fehlt Training für genau diese Alltagssituationen.
Ich würde deshalb nie nur ein Strukturdiagramm übergeben. Es braucht mindestens drei operative Dinge: eine Owner-Rolle mit echten Entscheidungsrechten, eine kurze Endnutzer-Anleitung für die häufigsten Speicherfragen und einen Review-Termin nach 30 bis 60 Tagen. Erst dann sieht man, ob die Architektur im Alltag trägt oder nur im Workshop gut aussah.
Nach der Architekturphase ist oft eine Kombination sinnvoll: erst SharePoint und Teams aufräumen, dann eine leichte Microsoft 365 Begleitung mit regelmäßiger Sprechstunde. Nicht als Werbeblock, sondern als Brücke zwischen Konzept und Alltag.
Welche Entscheidungen gehören in die Projektleitung?
Die Projektleitung muss nicht jede SharePoint-Einstellung kennen. Sie muss aber Zweck, Owner, Lebenszyklus und Navigationslogik pro Arbeitsbereich entscheiden.
Die technische Umsetzung kann die IT machen. Die fachliche Struktur muss aus dem Projekt kommen. Microsoft beschreibt Governance als Zusammenspiel aus Richtlinien, Rollen, Verantwortlichkeiten und Prozessen zwischen Geschäftsbereichen und IT (Microsoft Learn, 2026). Genau deshalb reicht ein Admin-Workshop nicht.
Für Projektleitungen funktioniert keine abstrakte SharePoint-Checkliste, sondern eine kurze Entscheidungsrunde. Jede Frage muss ein Ergebnis erzeugen:
Welcher Arbeitsmodus ist das? Entwurf, Zusammenarbeit, Veröffentlichung oder Archiv. Ergebnis: OneDrive, Team Site, Kommunikationswebsite, Hub oder Tresor-Site.
Wer besitzt den Bereich fachlich? Ergebnis: Owner, Stellvertretung, Review-Datum und Eskalationsweg; nicht nur "die IT".
Was ist die führende Wahrheit? Ergebnis: klare Regel für Entwurf, gültige Version, Archiv, Aufbewahrung und Löschung.
Wer darf standardmäßig hinein und welche Ausnahme ist verboten? Ergebnis: Berechtigungsmodell mit Gruppen, Sensitivity-Label, externer Freigaberegel und möglichst wenig gebrochenen Unterordnerrechten.
Wie beweisen wir, dass die Struktur funktioniert? Ergebnis: drei echte Suchaufgaben, ein Owner-Test und eine Copilot-/Agent-Testfrage mit erwarteter Quelle.
Der letzte Punkt wird oft unterschätzt. Microsoft betont bei SharePoint-Informationsarchitektur, dass der erste Schritt darin besteht, die Nutzer zu kennen und ihnen zu helfen, Informationen in ihrer Arbeitslogik zu finden (Microsoft Learn, 2026). Für den Alltag heißt das: Testen Sie Ihre Struktur mit drei echten Suchaufgaben. Wenn Fachbereich und neue Mitarbeitende die Antworten nicht ohne Zuruf finden, ist die Struktur noch nicht fertig.
Was kostet eine schlechte SharePoint-Informationsarchitektur?
Schlechte Struktur wirkt selten wie ein einzelner großer Schaden. Sie frisst Zeit, Vertrauen und Entscheidungsqualität in kleinen Portionen. Genau das macht sie so teuer. Und es fällt erst nach Monaten und Jahren auf. Dann möchte niemand das Chaos mehr angehen und man akzeptiert meist sein Schicksal mit erheblichen Nachteilen und Risiken.
Ein einfaches Rechenmodell reicht als Realitätstest: Wenn 100 Mitarbeitende im Schnitt nur 15 Minuten pro Arbeitstag verlieren, weil sie Dateien suchen, falsche Versionen öffnen, Sync-Fehler klären oder Zuständigkeiten nachfragen, sind das mehr als 500 Arbeitsstunden pro Monat. Das wird nicht 1:1 als Bargeld frei. Aber es ist Arbeitszeit, die nicht in Kunden, Projekte, Qualität oder Führung fließt.
Noch teurer sind die stillen Folgeschäden: veraltete Angebote im Umlauf, falsche Vorlagen, unnötige Support-Tickets, externe Gäste mit altem Zugriff, Projektwissen im OneDrive ausgeschiedener Mitarbeitender. Mit Copilot und SharePoint Agents kommt eine neue Dimension dazu: Die Unordnung bleibt nicht passiv liegen. Sie wird aktiv abgefragt.
Die Gegenrechnung ist deshalb nicht "Was kostet SharePoint-Aufräumen?" Die bessere Frage lautet: Was kostet es, wenn Suche, Berechtigung und Verantwortlichkeit jeden Tag unklar bleiben?
Erst das Fundament, dann Copilot
Eine durchdachte SharePoint-Informationsarchitektur ist keine Luxusübung. Sie entscheidet, ob Microsoft 365 im Mittelstand zum stabilen Betriebssystem für Zusammenarbeit wird oder zur digitalisierten Gerümpelkammer mit Suchfunktion.
Schlechte Struktur kostet nicht nur Speicherplatz. Sie kostet Suchzeit, Vertrauen, Support-Aufwand und am Ende Entscheidungsqualität. Das Ziel hinter SharePoint Struktur Mittelstand ist kein schöner Ordnerbaum, sondern ein belastbares Arbeitsmodell: Zuständigkeit, Berechtigung und Auffindbarkeit müssen verlässlich geklärt sein. Wenn niemand sicher weiß, welche Datei aktuell ist, hilft auch die beste KI nur begrenzt.
Mein Rat: Starten Sie nicht mit dem perfekten Zielbild. Starten Sie mit den kritischsten Sites, den offensten Berechtigungen und den größten Sync-Risiken. Ein sauberer Copilot Readiness Check beginnt nicht bei Prompts, sondern bei der Frage: Darf diese Person diese Datei wirklich sehen und ist das überhaupt die richtige Datei?
Über den Autor: Marcus Machon berät mittelständische Unternehmen bei Microsoft 365 Governance, SharePoint-/Teams-Struktur, Power-Platform-Automatisierung und Copilot-/KI-Readiness.
Quellen
AvePoint (2021). Teams Governance Survey. Report
Microsoft Learn (2026). Einführung in die SharePoint-Informationsarchitektur. Dokumentation
Microsoft Support (2026). Synchronisieren von SharePoint- und Teams-Dateien mit Ihrem Computer. Supportartikel
Microsoft Support (2026). Einschränkungen in OneDrive und SharePoint. Supportartikel
Microsoft Learn (2026). Semantische Indizierung für Microsoft 365 Copilot. Dokumentation
Splunk (2019). The State of Dark Data. Report
Veritas (2016). Global Databerg Report. Report
Microsoft Learn (2026). Informationen zur Aufbewahrung für SharePoint und OneDrive. Dokumentation
Microsoft Learn (2026). Microsoft 365 Copilot: Daten- und Compliancebereitschaft. Dokumentation
Varonis (2025). State of Data Security Report. Report
Microsoft Learn (2026). Verwalten des Zugriffs auf Agents in SharePoint. Dokumentation
Microsoft Learn (2026). Eingeschränkte SharePoint-Suche. Dokumentation
Microsoft Learn (2026). Übersicht über die erweiterte Verwaltung von SharePoint. Dokumentation
Microsoft Learn (2026). Integration von Teams und SharePoint. Dokumentation
Microsoft Learn (2026). Planen Ihrer SharePoint-Hubwebsites. Dokumentation
Microsoft Learn (2026). Übersicht über SharePoint-Governance. Dokumentation
Microsoft Support (2026). Hinzufügen von Verknüpfungen zu freigegebenen Ordnern in OneDrive. Supportartikel
Computerworld / Gartner (2025). Microsoft 365 Copilot rollouts slowed by data security, ROI concerns. Artikel
