Technische Dokumentation in SharePoint
Struktur, Metadaten und Versionierung für den Maschinenbau-AlltagTechnische Dokumentation in SharePoint: Struktur, Metadaten, Versionierung
Irgendwo auf deinem Netzlaufwerk liegt eine Datei namens „Betriebsanleitung_BA-4711_final_v2_NEU_MK.docx“. Sie ist die gültige Fassung. Das weiß genau eine Person, und die ist seit März in Elternzeit. Zwei Ordner weiter liegt „…_final_v2.docx“, die ist einen Tag älter und sieht auf den ersten Blick identisch aus. Der Unterschied besteht aus einem Warnhinweis, den die Sicherheitsfachkraft nach dem Vorfall an der Zuführung hineingeschrieben hat. Welche der beiden Dateien im letzten Serienauftrag als PDF an den Kunden gegangen ist, lässt sich nicht mehr rekonstruieren.
Das ist keine Schlamperei. Das ist der Normalzustand in Betrieben, die technische Dokumentation erstellen, ohne eine Redaktion zu haben. Der Konstrukteur schreibt die Anleitung, weil er die Maschine kennt — nebenbei, zwischen Abnahme und nächstem Projekt. Niemand hat sich je hingesetzt und entschieden, wie die Ablage aussehen soll. Sie ist entstanden, so wie ein Trampelpfad entsteht: durch Benutzung, nicht durch Planung. Und wie ein Trampelpfad führt sie zuverlässig dorthin, wo der Erste hingegangen ist, und sonst nirgendwohin.
Die gute Nachricht: Der Weg aus diesem Zustand führt nicht zwangsläufig über ein Redaktionssystem für einen mittleren sechsstelligen Betrag. Er führt in den allermeisten Fällen über einen Mittelweg, der aus drei Bausteinen besteht — Word als Werkzeug, SharePoint als Ablage und Lenkung, Microsoft Purview für Aufbewahrung und Löschung. Wie diese drei Bausteine zusammenspielen und wann der Mittelweg endet, ordnet die Übersicht Technische Dokumentation in der Praxis ein. Dieser Beitrag kümmert sich um den mittleren Baustein: die Plattform. Struktur, Metadaten, Versionierung, Berechtigungen.
Als Beispiel dient durchgehend ein Maschinenbauer mit rund 40 aktiven Maschinentypen in vier Baureihen, fünf Sprachen, drei Personen, die Dokumentation schreiben, und keiner davon in Vollzeit. Anonymisiert, aber realistisch: Die Zahlen sind so typisch, dass sich mindestens die Hälfte der Leser wiedererkennen wird.
Warum das Laufwerk stirbt — und SharePoint es nicht von allein besser macht
Die Anatomie eines gewachsenen Ablageorts
Ein Netzlaufwerk kennt genau eine Ordnungsdimension: den Pfad. Jede Information, die du an einem Dokument festhalten willst, muss in diesen Pfad oder in den Dateinamen. Deshalb heißen die Ordner „Anleitungen“, dann „2021 neu“, dann „Kunde Nord“, dann „final“, und deshalb tragen die Dateien Namen, die aussehen wie abgebrochene Versionshistorien. Der Pfad ist eine Krücke für Metadaten. Er funktioniert genau so lange, wie alle Beteiligten dieselbe Logik im Kopf haben — also ungefähr bis zur ersten Neueinstellung.
Die eigentlichen Kosten dieses Zustands stehen nie in einer Rechnung. Sie verteilen sich in Zehn-Minuten-Portionen über die Belegschaft und tauchen erst dann konzentriert auf, wenn jemand eine Frage stellt, die eine belastbare Antwort verlangt: der Auditor, der Anwalt der Gegenseite, oder der Servicetechniker um 23 Uhr an einer Maschine im Ausland.
|
Symptom im Alltag |
Was es dich kostet |
Was tatsächlich fehlt |
|---|---|---|
|
„Welche Fassung gilt?“ |
Rückfragen, doppelte Prüfungen, im Ernstfall die Auslieferung einer überholten Anleitung |
Ein Status am Dokument, nicht im Dateinamen |
|
„Wo liegt die englische Fassung?“ |
Sucharbeit, Doppelübersetzungen derselben Passage |
Eine Sprachspalte und eine Beziehung zwischen den Sprachständen |
|
„Was hat sich seit dem letzten Stand geändert?“ |
Vollständige Neuprüfung statt Differenzprüfung |
Eine nachvollziehbare Versionshistorie |
|
„Wer hat das freigegeben?“ |
Im Audit eine unangenehme Pause, im Schadensfall mehr als das |
Ein Genehmigungsschritt mit Zeitstempel und Person |
|
„Darf der Servicepartner das sehen?“ |
Entweder Mailanhänge im Umlauf oder gar keine Auskunft |
Ein Berechtigungsmodell, das nicht aus Mailanhängen besteht |
Tabelle 1: Was ein gewachsenes Laufwerk tatsächlich kostet — und welche Funktion in Wahrheit fehlt
Die Lift-and-Shift-Falle
Der häufigste Fehler beim Umzug nach SharePoint dauert etwa vier Stunden und besteht darin, den Laufwerksordner per Migrationstool eins zu eins in eine Dokumentbibliothek zu kippen. Danach hast du dieselbe Struktur, dieselben Dateinamen, dieselbe Unklarheit — nur langsamer, weil ein Browser nun einmal kein Explorer ist. Die üblichen Reaktionen darauf sind entweder „SharePoint ist unbrauchbar“ oder die Rückkehr zum Laufwerk. Beides ist verständlich und beides ist die falsche Schlussfolgerung.
SharePoint bringt Grenzen mit, die auf einem Laufwerk nicht existieren. Wer sie kennt, plant um sie herum. Wer sie nicht kennt, lernt sie an dem Tag kennen, an dem die Bibliothek 5.200 Elemente hat und niemand mehr sortieren kann.
|
FAKTEN · Die Grenzen, die deine Struktur beeinflussen Eine Bibliothek kann bis zu 30 Millionen Elemente aufnehmen — aber jede einzelne Ansicht darf nur bis zu 5.000 Elemente abfragen (Listenansichtsschwelle). Oberhalb dieser Grenze brauchst du indizierte Spalten und gefilterte Ansichten, sonst bekommst du eine Fehlermeldung statt einer Liste. Eine einzelne Datei darf 250 GB groß sein, was für Anleitungen kein Thema ist, für Videobeilagen aber durchaus. Die vollständige Adresse eines Dokuments ist auf 400 Zeichen begrenzt — genau deshalb sterben tief verschachtelte Ordnerbäume beim Umzug. Und der Synchronisierungsclient auf dem Arbeitsplatz wird jenseits von rund 300.000 synchronisierten Dateien unzuverlässig. |
|---|
Was die Plattform tatsächlich mitbringt — und was nicht
SharePoint ist kein Redaktionssystem und wird auch keines. Es kennt keine Textbausteine, keine Varianten, keine Wiederverwendung auf Modulebene, kein Übersetzungsgedächtnis. Was es kann, ist trotzdem beachtlich, und es ist in praktisch jedem Microsoft-365-Abonnement bereits bezahlt: Versionierung mit Historie, Metadaten mit kontrolliertem Vokabular, Genehmigungsschritte, ein Berechtigungsmodell, das diesen Namen verdient, Volltextsuche über den gesamten Bestand und — über Purview — Aufbewahrung und geregelte Löschung.
Das ist genau der Funktionsumfang, den eine Dokumentenlenkung braucht. Es ist nicht der Funktionsumfang, den eine Modularisierung von 400 Anleitungen braucht. Wo die Grenze verläuft, rechnet der Beitrag Ab wann lohnt sich ein Redaktionssystem? Eine ehrliche Rechnung durch, und welche Werkzeugklassen es überhaupt gibt, sortiert Alternative zu Word für technische Dokumentation: die ehrliche Landkarte. Für den Rest dieses Beitrags gilt die Annahme: Word bleibt, und die Ablage wird erwachsen.
|
WARNUNG · Migration ist keine Kopieraktion Wenn du deine 180 GB vom Laufwerk unverändert in eine Bibliothek schiebst, migrierst du das Problem und nicht die Daten. Ziehe einen Stichtag: Was seit 24 Monaten niemand geöffnet hat, wandert unbearbeitet in eine Archivbibliothek — ohne Metadaten, ohne Anspruch, mit Aufbewahrungsrichtlinie. In die neue Struktur wandert nur, was aktiv gepflegt wird. Bei dem Maschinenbauer aus dem Beispiel waren das 340 Dokumente von rund 26.000 Dateien. Das klingt brutal und ist trotzdem die einzige Variante, die jemals fertig wird. |
|---|
Die Bibliotheksstruktur: der Schnitt, der trägt
Schneide nach Lebenszyklus, nicht nach Abteilung
Die naheliegende Struktur ist die falsche. Naheliegend wäre: eine Bibliothek pro Baureihe, oder eine pro Abteilung, oder eine pro Jahr. Alle drei Varianten haben denselben Konstruktionsfehler — sie bilden ab, wie das Unternehmen aussieht, und nicht, was mit dem Dokument passiert. Unternehmen werden umorganisiert. Dokumentlebenszyklen nicht.
Der Schnitt, der über Jahre trägt, verläuft am Zustand des Dokuments: Arbeitsstand, Prüfstand, freigegebener Stand, abgelöster Stand. Diese vier Zustände unterscheiden sich in genau den Dingen, die eine eigene Bibliothek rechtfertigen — wer schreiben darf, wer lesen darf, wie versioniert wird, wie lange aufbewahrt wird. Alles andere, also Baureihe, Maschinentyp, Sprache, Kunde, wird zur Spalte.

Skizze 1: Zielbild der Ablage — vier Bibliotheken in einer Site, quer darüber ein Metadatenmodell
|
Bibliothek |
Inhalt |
Schreibrecht |
Versionierung |
Aufbewahrung |
|---|---|---|---|---|
|
01 Quellen |
Word-Dateien, Bilder, CAD-Auszüge, Textbausteine |
Doku-Team, Konstruktion |
Haupt- und Nebenversionen, Auschecken erzwungen |
keine eigene Regel, folgt der Site |
|
02 In Prüfung |
Freigabekandidaten mit Kommentaren |
Doku-Team; Prüfkreis kommentiert |
Nebenversionen, Inhaltsgenehmigung aktiv |
kurz, Inhalt wandert weiter |
|
03 Freigegeben |
PDF-Ausgabestände, je Maschine und Sprache genau einer |
nur Doku-Team |
nur Hauptversionen |
Aufbewahrungsetikett, ereignisbasiert |
|
04 Archiv |
abgelöste Ausgabestände als Nachweis |
niemand (schreibgeschützt) |
keine neuen Versionen |
lange Frist, Löschung mit Prüfschritt |
|
05 Vorlagen |
Dokumentvorlagen, Bausteine, Piktogramme, Styleguide |
Doku-Team |
Hauptversionen |
folgt der Site |
|
06 Austausch |
Pakete für Übersetzung, Prüfstelle, Zulieferer |
Doku-Team, benannte Externe |
Hauptversionen |
Inhalte werden nach Abschluss gelöscht |
Tabelle 2: Beispielstruktur für einen Maschinenbauer mit 40 Maschinentypen in fünf Sprachen
Sechs Bibliotheken. Nicht sechzig. Die Versuchung, für jede Baureihe eine eigene anzulegen, ist groß und endet immer gleich: Nach zwei Jahren hat jede Bibliothek eine leicht abweichende Spaltenkonfiguration, weil jemand mal schnell etwas hinzugefügt hat, und keine Ansicht funktioniert mehr über alles hinweg.
Eine Site oder viele?
Für den beschriebenen Betrieb reicht eine einzige Team-Site. Die Faustregel: Eine neue Site braucht es, wenn eine andere Personengruppe mit eigener Verantwortung und eigenem Berechtigungsbedarf arbeitet — nicht, wenn nur ein anderes Produkt dokumentiert wird. Wer eine Site pro Baureihe anlegt, baut sich eine Berechtigungslandschaft, die er innerhalb von drei Jahren nicht mehr überblickt, und darf jede Änderung am Metadatenmodell viermal nachziehen.
|
Wenn das zutrifft … |
… dann nimm |
Begründung |
|---|---|---|
|
Andere Organisationseinheit, eigene Verantwortung, eigener Berechtigungskreis |
eigene Site |
Berechtigungen und Aufbewahrung lassen sich sauber trennen |
|
Anderer Lebenszyklus oder anderes Schreibrecht |
eigene Bibliothek |
Versionierung, Genehmigung und Aufbewahrung sind Bibliothekseinstellungen |
|
Nur eine weitere Eigenschaft des Dokuments |
eine Spalte |
Eigenschaften lassen sich filtern, gruppieren und auswerten — Ordner nicht |
|
Nur eine andere Perspektive auf denselben Bestand |
eine Ansicht |
Kostet nichts, dupliziert nichts, ist in fünf Minuten gebaut |
|
Ein physisches Objekt braucht eine geschlossene Akte (Seriennummer, Sondermaschine) |
genau eine Ordnerebene |
Die Akte ist die Einheit, die ausgeliefert und archiviert wird |
Tabelle 3: Wann Site, wann Bibliothek, wann Spalte, wann Ordner
Der Ordner, der bleiben darf
„Ordner sind böse“ ist ein Beraterspruch, kein Prinzip. Ordner sind dann schädlich, wenn sie Eigenschaften abbilden — Ordner „Deutsch“ und Ordner „Englisch“ sind zwei Ordner zu viel, das ist eine Spalte. Ordner sind sinnvoll, wenn sie eine geschlossene Akte abbilden, die als Ganzes entsteht, ausgeliefert und archiviert wird: die Maschinenakte zur Seriennummer 4711 mit Anleitung, Konformitätserklärung, Prüfprotokollen und Zulieferdokumentation. Diese Akte ist eine Einheit, und eine Ebene Ordner ist dafür das ehrlichste Mittel. Eine Ebene. Nicht sieben.
|
TIPP · Der Test für jeden geplanten Ordner Stell dir vor, jemand fragt: „Zeig mir alle deutschen Betriebsanleitungen, die seit zwei Jahren nicht geprüft wurden.“ Wenn du dafür in mehrere Ordner klicken musst, war der Ordner eine Eigenschaft und gehört als Spalte an das Dokument. Wenn du es mit einem Filter beantworten kannst, ist die Struktur richtig. Der Test dauert zehn Sekunden und ersetzt eine Stunde Diskussion im Projektteam. |
|---|
Metadaten statt Ordnergräber
Das Minimalmodell: sechs bis acht Spalten, nicht sechzig
Metadatenmodelle scheitern nicht an zu wenigen Feldern. Sie scheitern an zu vielen. Der typische Verlauf: Im Workshop fallen allen Beteiligten insgesamt 34 wünschenswerte Angaben ein, davon werden 22 umgesetzt, nach einem halben Jahr sind vier gepflegt und der Rest steht auf dem Standardwert. Ab da ist das Modell wertlos, weil niemand mehr weiß, welche Spalte man glauben darf.
Die Gegenregel ist unbequem und wirksam: Eine Spalte darf nur existieren, wenn du eine konkrete Frage, eine Ansicht, eine Auswertung oder eine Regel nennen kannst, die sie beantwortet beziehungsweise antreibt. Kein Anwendungsfall, keine Spalte. Nachträglich hinzufügen ist billig; nachträglich 3.000 Dokumente nachpflegen ist es nicht.
|
Spalte |
Typ |
Beispielwerte |
Pflicht |
Wofür du sie wirklich brauchst |
|---|---|---|---|---|
|
Maschinentyp |
Verwaltete Metadaten |
DM-500, DM-320, FZ-12 |
ja |
Einstieg für Service und Vertrieb, Filter für jede Ansicht |
|
Baureihe |
Verwaltete Metadaten |
Drehen, Fräsen, Automation |
ja |
Bündelung bei Serienänderungen und Rückrufen |
|
Dokumentart |
Auswahl |
Betriebsanleitung, Wartung, Ersatzteile, Konformität |
ja |
Steuert Aufbewahrung, Freigabepflicht und Übersetzungsbedarf |
|
Sprache |
Auswahl |
de, en, fr, it, pl |
ja |
Vollständigkeitsprüfung je Maschinentyp |
|
Ausgabestand |
Text (kurz) |
A, B, C … |
ja |
Die Angabe, die auf dem Deckblatt steht — die Versionsnummer ist es nicht |
|
Gültig ab |
Datum |
01.03.2026 |
ja |
Trennt den gültigen vom abgelösten Stand |
|
Status |
Auswahl |
Entwurf, in Prüfung, freigegeben, abgelöst |
ja |
Ampel in der Ansicht, Auslöser für Workflows |
|
Nächste Prüfung |
Datum |
01.03.2028 |
nein |
Wiedervorlage, ohne die keine Prüfung je stattfindet |
Tabelle 4: Das Metadatenmodell für technische Dokumentation im Maschinenbau
Verwaltete Metadaten, Auswahlspalten, Freitext
Drei Spaltentypen decken 95 Prozent des Bedarfs ab, und die Wahl zwischen ihnen entscheidet darüber, ob das Modell in zwei Jahren noch stimmt. Verwaltete Metadaten aus dem Termspeicher nimmst du für Vokabulare, die wachsen und die an mehreren Stellen gebraucht werden — Maschinentypen sind das Musterbeispiel, weil jedes Jahr neue dazukommen und weil dieselbe Liste in anderen Bereichen ebenfalls gebraucht wird. Auswahlspalten nimmst du für kleine, stabile Listen wie Sprache und Status. Freitext nimmst du für Titel und Kurzbeschreibung — und sonst nirgends.
Damit die Spalten überall identisch heißen und identisch konfiguriert sind, definierst du sie einmal als Websitespalten und bündelst sie in Inhaltstypen, etwa „Betriebsanleitung“, „Wartungsanleitung“, „Konformitätserklärung“. Verteilt werden diese Inhaltstypen zentral über den Inhaltstypkatalog im SharePoint Admin Center. Der Aufwand dafür beträgt einen halben Tag. Der Aufwand, dieselben Spalten später in sechs Bibliotheken manuell anzugleichen, beträgt eine Woche und wird nie ganz fertig.
|
WARNUNG · Pflichtspalten ohne Rückfallwert sind ein Denial of Service gegen die eigene Belegschaft Wenn du eine Pflichtspalte ohne Standardwert einführst, kann Word Dateien nicht mehr sauber zurückspeichern — die Datei bleibt ausgecheckt hängen, bis jemand im Browser die Metadaten nachträgt. Beim dritten Mal kopieren die Leute die Datei auf den Desktop, und du bist zurück auf dem Laufwerk, nur mit mehr Frust. Setze für jede Pflichtspalte einen sinnvollen Standardwert, oder mache sie in „01 Quellen“ optional und erst beim Übergang nach „02 In Prüfung“ verbindlich. |
|---|
Ansichten sind genau das, wofür du früher Ordner benutzt hast
Der Moment, in dem Metadaten für das Team einleuchtend werden, ist nicht der Workshop, in dem sie definiert werden. Es ist der Moment, in dem jemand zum ersten Mal eine Ansicht sieht, die seine Frage beantwortet, ohne dass er klicken muss. Für den Servicetechniker: alle freigegebenen deutschen Anleitungen, gruppiert nach Maschinentyp. Für die Übersetzungskoordination: alle Maschinentypen, bei denen der deutsche Stand neuer ist als der englische. Für die Qualitätssicherung: alles, dessen Prüfdatum in den nächsten 90 Tagen fällig wird, rot eingefärbt.

Skizze 2: Derselbe Bestand — links über den Pfad erschlossen, rechts über Spalten und Ansichten
Diese drei Ansichten kosten zusammen etwa eine Stunde. Sie ersetzen die Ordnerstruktur vollständig, und sie ersetzen nebenbei drei Excel-Listen, die bislang parallel gepflegt wurden und in denen mindestens eine falsch war. Wichtig ist nur, dass die Ansichten von jemandem gebaut werden, der die Fragen kennt — und nicht von der IT, die die Fragen nicht kennen kann.
|
TIPP · Jenseits von 5.000 Elementen: Spalten indizieren Sobald eine Bibliothek die Listenansichtsschwelle von 5.000 Elementen überschreitet, funktionieren nur noch Ansichten, deren erster Filter auf einer indizierten Spalte liegt und weniger als 5.000 Treffer liefert. Indiziere deshalb von Anfang an Maschinentyp, Status und Sprache — nachträglich geht das auch, aber dann sitzt du schon im Fehlerfall. Zusätzlich lohnt sich die Metadatennavigation mit Schlüsselfiltern: Sie gibt der Bibliothek eine Baumnavigation, die aus Metadaten gespeist wird statt aus Ordnern. |
|---|
Dokument-ID und Dateinamen
Aktiviere den Dokument-ID-Dienst auf der Websitesammlung und vergib ein sprechendes Präfix, etwa „TD“. Jedes Dokument bekommt damit eine dauerhafte Kennung und eine dauerhafte Adresse, die auch nach dem Verschieben zwischen Bibliotheken gültig bleibt. Das ist genau die Kennzeichnung, die eine Dokumentenlenkung verlangt, und es ist die Voraussetzung dafür, dass Verweise zwischen Dokumenten nicht bei jedem Umzug brechen. Wie das mit den formalen Anforderungen zusammenpasst, beschreibt Dokumentenlenkung nach ISO 9001 mit Word und SharePoint im Detail.
Dateinamen bleiben trotzdem wichtig, weil das PDF beim Kunden landet und dort keine Spalten mitbringt. Eine gute Konvention ist kurz und maschinenlesbar: Dokumentart, Maschinentyp, Sprache, Ausgabestand — also etwa „BA_DM-500_de_C.pdf“. Kein Datum im Dateinamen, kein „final“, kein Kürzel des Bearbeiters. Das Wort „final“ hat in der Geschichte der technischen Dokumentation noch nie gestimmt.
Damit das Team die Ansichten selbst baut und die Metadaten gedankenlos richtig pflegt, braucht es einmal zwei Stunden Anleitung — nicht mehr, aber die müssen stattfinden. Genau dafür ist die Schulung Technische Dokumentation gedacht: Wer nebenbei dokumentiert, hat keine Zeit, sich das aus Hilfeseiten zusammenzusuchen. Wie sich diese Rolle überhaupt organisieren lässt, behandelt Der Konstrukteur als Nebenbei-Redakteur: Doku-Pflichten ohne Redaktion.
Versionierung, die man erklären kann
Haupt- und Nebenversionen, Auschecken, Genehmigung
Versionierung ist in SharePoint standardmäßig an, und genau das führt dazu, dass sie niemand konfiguriert. Dabei ist die Entscheidung simpel, sobald der Lebenszyklus geschnitten ist: In der Quellbibliothek willst du Haupt- und Nebenversionen, weil dort jede Zwischenspeicherung eine Nebenversion erzeugt und Entwürfe für Unbeteiligte unsichtbar bleiben sollen. In der Freigabebibliothek willst du ausschließlich Hauptversionen, weil es dort keine Entwürfe gibt — was dort liegt, ist freigegeben oder es liegt dort nicht.
Die Frage nach dem Auschecken ist die einzige, bei der es wirklich zwei vertretbare Antworten gibt. Gemeinsames Bearbeiten ist bequem und für kurze Dokumente unproblematisch. Bei einer 180-seitigen Betriebsanleitung mit Feldfunktionen, Querverweisen und eingebetteten Objekten ist es ein Risiko: Genau diese Konstrukte vertragen sich schlecht mit paralleler Bearbeitung, und die Rechnung kommt in Form eines zerschossenen Verzeichnisses. Für die Quellbibliothek ist erzwungenes Auschecken deshalb die konservative und meist richtige Wahl.
Wenn deine Anleitungen so groß sind, dass diese Frage überhaupt relevant wird, lohnt ein Blick auf die Ursachen: Word bei großen Dokumenten: langsam, instabil, unberechenbar — was wirklich hilft beschreibt, woran es tatsächlich liegt. Und falls jemand im Haus vorschlägt, das Problem mit Words Zentraldokument-Funktion zu lösen, lies vorher Zentraldokument und Filialdokumente: Warum Words Master-Konzept riskant ist — insbesondere in Kombination mit einer Bibliothek, in der Dateien ausgecheckt und verschoben werden.
|
Bibliothek |
Versionen |
Auschecken |
Inhaltsgenehmigung |
|---|---|---|---|
|
01 Quellen |
Haupt- und Nebenversionen |
erzwungen |
aus |
|
02 In Prüfung |
Haupt- und Nebenversionen |
erzwungen |
an, Entwürfe nur für Autor und Genehmiger |
|
03 Freigegeben |
nur Hauptversionen |
nicht nötig (kaum Schreibzugriffe) |
an |
|
04 Archiv |
nur Hauptversionen |
entfällt (schreibgeschützt) |
aus |
|
05 Vorlagen |
nur Hauptversionen |
erzwungen |
an |
|
06 Austausch |
nur Hauptversionen |
aus |
aus |
Tabelle 5: Versionierungseinstellungen je Bibliothek
Versionslimits: was mit dem Speicher passiert
Versionen sind nicht gratis. Jede Version einer 40 MB großen Anleitung mit eingebetteten Bildern belegt Speicher im Websitekontingent, und bei drei Personen, die täglich zwischenspeichern, summiert sich das schneller, als man denkt. Microsoft hat deshalb die Versionslimits umgebaut: Neben den klassischen manuellen Grenzen — Anzahl und optional ein Ablaufzeitraum — gibt es einen Automatikmodus, der alte Versionen intelligent ausdünnt, statt sie stumpf nach Anzahl abzuschneiden.

Skizze 4: So dünnt der Automatikmodus die Versionshistorie über die Zeit aus
|
FAKTEN · So arbeitet der Automatikmodus Innerhalb der ersten 30 Tage bleiben alle Versionen erhalten. Zwischen 30 und 60 Tagen behält der Dienst stündliche Versionen, zwischen 60 und 180 Tagen tägliche, ab 180 Tagen wöchentliche — und diese dann unbefristet, bis die harte Obergrenze von 500 Versionen je Datei erreicht ist. Microsoft nennt dafür rund 96 Prozent weniger Versionsspeicher nach sechs Monaten gegenüber reinen Anzahllimits. Die Limits lassen sich für die gesamte Organisation, je Website und je Bibliothek setzen; vor der Umstellung liefert eine „Was-wäre-wenn“-Analyse die zu erwartende Einsparung, und bestehende Versionen lassen sich in einem separaten Lauf nachträglich kürzen. |
|---|
|
Modus |
Was passiert |
Passt für |
Woran du denken musst |
|---|---|---|---|
|
Automatisch |
Dichte Historie in der jüngeren Vergangenheit, ausgedünnt in der ferneren |
Quellbibliotheken mit aktiver Bearbeitung |
Zwischenstände von vor acht Monaten sind eventuell nicht mehr einzeln greifbar |
|
Manuell mit Anzahl und Ablauf |
Versionen werden nach Anzahl und nach Alter gelöscht |
Bibliotheken mit hohem Durchsatz und geringem Nachweisbedarf |
Eine Datei ohne Bearbeitung kann nach Ablauf der Frist ihre gesamte Historie verlieren |
|
Manuell, nur Anzahl |
Immer die letzten n Versionen, unabhängig vom Alter |
Freigabe- und Archivbibliotheken |
Bei stark bearbeiteten Dateien der teuerste Modus |
Tabelle 6: Die drei Versionslimit-Modi im Vergleich
Version ist nicht Ausgabestand
Hier liegt der Denkfehler, der in Audits am häufigsten auffliegt. Die Versionsnummer in SharePoint zählt Speichervorgänge. Der Ausgabestand auf dem Deckblatt deiner Anleitung zählt freigegebene Dokumentstände. Zwischen beiden besteht keine feste Beziehung und darf auch keine bestehen: Version 4.0 kann Ausgabestand B sein, weil die Datei nach der Freigabe noch dreimal wegen Metadaten angefasst wurde.

Skizze 3: Vom Entwurf zum Ausgabestand — und was die Versionsnummer dabei bedeutet (nämlich wenig)
|
WICHTIG · Der Ausgabestand gehört in eine eigene Spalte Führe die Spalten „Ausgabestand“ und „Gültig ab“ und pflege sie beim Freigeben. Nur diese beiden Angaben sind auskunftsfähig. Wer im Audit auf die Frage „Welcher Stand gilt?“ mit „Version 3.0“ antwortet, hat die Frage nicht verstanden — und der Auditor merkt das. Die Versionsnummer ist ein technisches Protokoll, kein Dokumentenstatus. |
|---|
Was die Versionshistorie ausdrücklich nicht ist
Sie ist kein Backup: Wer die Datei löscht, löscht die Historie gleich mit — der Papierkorb hilft 93 Tage lang, danach nicht mehr. Sie ist kein Archiv: Eine Historie, die durch Limits ausgedünnt wird, taugt nicht als Nachweis über zehn Jahre. Und sie ist kein Aufbewahrungskonzept: Dafür brauchst du Aufbewahrungsetiketten aus Microsoft Purview, im Idealfall ereignisbasiert an das Ende der Produktlebensdauer gekoppelt, damit die Frist erst dann zu laufen beginnt, wenn die letzte Maschine dieses Typs außer Betrieb ist. Wie das aufgesetzt wird, steht in Aufbewahrung und Lebenszyklus technischer Doku in Microsoft 365.
Berechtigungen, Sichtbarkeit — und der Weg dorthin
Drei Gruppen oben, eine Ausnahme unten
Berechtigungen in SharePoint sind einfach, solange man sie einfach hält, und werden innerhalb von zwei Jahren unrettbar, sobald man anfängt, einzelne Personen an einzelne Dateien zu hängen. Die tragfähige Variante besteht aus den drei Standardgruppen der Site und aus höchstens einer unterbrochenen Vererbung auf Bibliotheksebene — dort, wo die Freigabebibliothek für alle lesbar, aber nur für das Doku-Team beschreibbar sein soll.

Skizze 5: Berechtigungsebenen — und die Frage, was Copilot daraus macht
|
Rolle |
Gruppe |
Darf |
Darf nicht |
|---|---|---|---|
|
Doku-Team |
Mitglieder |
In allen Bibliotheken schreiben, freigeben, Ansichten bauen |
Berechtigungen ändern |
|
Konstruktion |
Mitglieder |
In „01 Quellen“ schreiben, in „02 In Prüfung“ kommentieren |
Nach „03 Freigegeben“ schreiben |
|
Prüfkreis (Sicherheit, Qualität) |
eigene Gruppe |
Lesen und genehmigen in „02 In Prüfung“ |
Quelldateien ändern |
|
Service, Vertrieb, Montage |
Besucher |
„03 Freigegeben“ lesen |
Entwürfe sehen, irgendetwas ändern |
|
Externe |
Gäste, zeitlich begrenzt |
Genau eine Bibliothek („06 Austausch“) nutzen |
Alles andere, insbesondere Quellen sehen |
|
Administration |
Besitzer (zwei Personen) |
Struktur, Spalten, Berechtigungen ändern |
Sich selbst für unersetzlich halten |
Tabelle 7: Rollenmodell für eine Doku-Site
Externe: Übersetzung, Prüfstelle, Zulieferer
Externe bekommen niemals Zugriff auf „01 Quellen“, auch nicht „nur kurz“. Sie bekommen eine eigene Bibliothek und Freigabelinks mit Ablaufdatum. Das ist keine Schikane, sondern die einzige Konstruktion, bei der du nach Projektende noch weißt, wer worauf zugreifen konnte. Für Übersetzungspakete kommt hinzu, dass die Übergabe strukturiert erfolgen sollte, weil dort die eigentlichen Kosten entstehen — Anleitungen in Word übersetzen lassen: der versteckte Kostentreiber zeigt, wie viel Geld in schlecht vorbereiteten Dateien verschwindet.
Copilot und Suche: was plötzlich sichtbar wird
Ein Effekt, den niemand auf der Rechnung hat: Sobald der Bestand sauber abgelegt und durchsuchbar ist, findet ihn auch die organisationsweite Suche — und Microsoft 365 Copilot findet ihn besonders gut. Copilot vergibt keine neuen Rechte, es nutzt ausschließlich die vorhandenen. Der Unterschied ist die Geschwindigkeit: Was früher nur fand, wer den kryptischen Pfad kannte, steht jetzt in zwei Sekunden in einer Antwort, zusammengefasst und ohne Kontext. Der halbfertige Entwurf mit dem noch nicht abgestimmten Sicherheitshinweis inklusive.
|
WARNUNG · Vor dem Copilot-Rollout: die Doku-Site prüfen Genau deshalb gehören Entwürfe in eine Bibliothek mit engen Rechten und aktivierter Entwurfssichtbarkeit. Für Websites mit besonders heiklem Bestand lässt sich zusätzlich die eingeschränkte Inhaltserkennung (Restricted Content Discovery) setzen: Der Zugriff bleibt unverändert, aber die Inhalte tauchen weder in Copilot-Antworten noch in der organisationsweiten Suche auf. Die Funktion stammt aus SharePoint Advanced Management, das in den Microsoft-365-Copilot-Lizenzen enthalten ist. Betrachte sie als Notbremse, nicht als Ordnungsprinzip — die eigentliche Arbeit bleibt, die Berechtigungen richtig zu setzen. |
|---|
Der Weg dorthin: 90 Tage, nicht 90 Wochen
Der häufigste Grund, warum solche Vorhaben scheitern, ist nicht technische Komplexität. Es ist die Verwechslung von Strukturprojekt und Migrationsprojekt. Die Struktur ist in zwei Wochen entschieden. Die vollständige Migration von 26.000 Altdateien ist nie fertig — deshalb ist sie auch nicht das Ziel.
|
Zeitraum |
Was passiert |
Ergebnis am Ende |
|---|---|---|
|
Woche 1–2 |
Lebenszyklus schneiden, sechs Bibliotheken anlegen, Metadatenmodell auf acht Spalten festlegen |
Eine leere, aber richtige Struktur |
|
Woche 3–4 |
Websitespalten und Inhaltstypen zentral anlegen, Termspeicher füllen, Spalten indizieren |
Ein Modell, das sich nicht auseinanderentwickelt |
|
Woche 5–6 |
Versionierung, Genehmigung und Berechtigungen setzen; Ansichten für Service, Übersetzung und Qualität bauen |
Die Plattform ist arbeitsfähig |
|
Woche 7–10 |
Die aktiven Dokumente umziehen und dabei Metadaten pflegen — nur die aktiven |
Der gepflegte Bestand liegt vollständig im neuen Modell |
|
Woche 11–12 |
Altbestand als Archiv einfrieren, Aufbewahrungsetiketten setzen, zwei Stunden Einweisung für das Team |
Das Laufwerk kann schreibgeschützt werden |
Tabelle 8: Ein realistischer Fahrplan für den beschriebenen Betrieb
Der kritische Punkt liegt nicht in Woche 7, sondern in Woche 1: Wenn der Lebenszyklus falsch geschnitten ist, korrigierst du das später nur noch mit einer zweiten Migration. Genau dafür lohnt sich der Blick von außen — die Beratung für technische Dokumentation setzt in solchen Fällen meist mit einem halben Tag am bestehenden Bestand an: Struktur skizzieren, Metadatenmodell auf die Zahl der Spalten zusammenstreichen, die wirklich gepflegt werden, und den Rest dem Team überlassen.
Häufige Fragen
Brauche ich dafür Zusatzlizenzen wie SharePoint Premium?
Für alles, was in diesem Beitrag beschrieben ist, nein. Bibliotheken, Websitespalten, Inhaltstypen, verwaltete Metadaten, Versionierung, Inhaltsgenehmigung, Dokument-ID und Berechtigungen sind Bordmittel. Aufbewahrungsetiketten erfordern je nach Ausbaustufe entsprechende Purview-Pläne, ereignisbasierte Aufbewahrung liegt in der höheren Stufe. Zusatzfunktionen wie die eingeschränkte Inhaltserkennung stammen aus SharePoint Advanced Management. Nichts davon brauchst du am ersten Tag.
Sind Ordner in SharePoint jetzt verboten oder nicht?
Weder noch. Ordner, die Eigenschaften abbilden — Sprache, Jahr, Status, Kunde —, gehören abgeschafft, weil sie sich nicht filtern lassen und weil sie die Adresslänge auffressen. Ordner, die eine geschlossene Akte abbilden, sind legitim. Die Faustregel bleibt: eine Ebene, mit Begründung.
Wie viele Dokumente verträgt eine Bibliothek wirklich?
Technisch bis zu 30 Millionen Elemente. Praktisch entscheidet nicht die Gesamtzahl, sondern die einzelne Ansicht: Sie darf nicht mehr als 5.000 Elemente abfragen. Mit indizierten Spalten und gefilterten Ansichten arbeiten Bibliotheken mit Hunderttausenden Dokumenten problemlos. Ohne beides wird es schon bei 5.001 unangenehm.
Sollen wir Word-Dateien oder PDF freigeben?
PDF. Der freigegebene Stand ist ein Ausgabestand und kein Arbeitsstand — er soll nicht mehr veränderbar sein, er soll überall gleich aussehen, und er soll ohne Word lesbar sein. Die Word-Datei bleibt in „01 Quellen“ und ist die Grundlage für den nächsten Stand. Wer die Word-Datei freigibt, bekommt innerhalb eines Jahres eine Fassung zurück, die jemand „nur ganz kurz“ angepasst hat.
Auschecken erzwingen oder gemeinsam bearbeiten?
Bei kurzen Dokumenten gemeinsam bearbeiten, bei umfangreichen Anleitungen auschecken. Feldfunktionen, Querverweise, Verzeichnisse und eingebettete Objekte vertragen sich schlecht mit paralleler Bearbeitung. Und wenn zwei Personen gleichzeitig an derselben Betriebsanleitung schreiben, hast du ohnehin ein Abstimmungsproblem, das keine Software löst.
Was passiert mit dem Altbestand auf dem Laufwerk?
Er zieht nicht mit um. Er wird eingefroren: einmal komplett in eine Archivbibliothek oder ein Archivziel gespiegelt, ohne Metadatenpflege, mit einer Aufbewahrungsrichtlinie versehen, danach das Laufwerk schreibgeschützt. Wer etwas daraus braucht, holt es sich und pflegt es beim Herausholen sauber ein. Nach einem Jahr weißt du sehr genau, wie viel von den 26.000 Dateien tatsächlich gebraucht wurde. Es sind erschreckend wenige.
Reicht das für ISO 9001 und für die Produkthaftung?
Für die Dokumentenlenkung nach Abschnitt 7.5 reicht diese Konstruktion aus, sofern Kennzeichnung, Genehmigung, Verteilung, Änderungssteuerung und Aufbewahrung tatsächlich gelebt werden — die Plattform liefert die Mechanik, nicht die Disziplin. Die konkrete Zuordnung von Normanforderung zu SharePoint-Funktion steht in Dokumentenlenkung nach ISO 9001 mit Word und SharePoint. Für die Produkthaftung zählt zusätzlich, dass du Jahre später belegen kannst, welcher Stand mit welcher Maschine ausgeliefert wurde — dafür brauchst du die Verknüpfung von Ausgabestand und Auftrag, nicht nur die Versionshistorie.
Ändert die neue Maschinenverordnung etwas an der Ablage?
Ja, und zwar in eine Richtung, die diese Struktur eher belohnt. Wenn die Betriebsanleitung digital bereitgestellt wird, muss eindeutig sein, welcher Stand zu welcher Maschine gehört, und er muss über die erwartete Lebensdauer verfügbar bleiben. Genau das leisten Ausgabestandsspalte, Dokument-ID und ereignisbasierte Aufbewahrung. Was ab 2027 konkret gilt, beschreibt MVO 2027 und die digitale Betriebsanleitung: Was jetzt auf Hersteller zukommt. Und was inhaltlich in die Anleitung gehört, sortiert Betriebsanleitung erstellen: Was wirklich hineinmuss — und was nicht.
Ab wann reicht diese Konstruktion nicht mehr?
Wenn du anfängst, denselben Sicherheitshinweis in mehr als einem Dutzend Dokumenten pflegen zu müssen, wenn Variantenmatrizen entstehen oder wenn die Übersetzungskosten die Personalkosten der Doku übersteigen, ist die Grenze erreicht. SharePoint verwaltet Dokumente hervorragend und Inhalte gar nicht. Bevor du diesen Schritt gehst, lohnt sich allerdings die Prüfung, ob Word selbst richtig aufgesetzt ist — Word richtig aufgesetzt: das unterschätzte Redaktionssystem zeigt, wie viel Luft dort meist noch ist.
Fazit
Technische Dokumentation in SharePoint ist kein Digitalisierungsprojekt und kein Werkzeugwechsel. Es ist die Entscheidung, die Ordnungsinformation vom Pfad an das Dokument zu verlagern — und alles Weitere folgt daraus. Vier bis sechs Bibliotheken, geschnitten am Lebenszyklus. Acht Spalten, die wirklich gepflegt werden, statt zweiundzwanzig, die es nicht werden. Versionierung, die dem Zweck der jeweiligen Bibliothek entspricht, und ein Ausgabestand, der in einer Spalte steht und nicht in einer Versionsnummer. Drei Berechtigungsgruppen und die Disziplin, es dabei zu belassen.
Das ersetzt kein Redaktionssystem, und es soll es auch nicht. Es beseitigt aber die Klasse von Problemen, die in diesen Betrieben tatsächlich weh tut: die Frage, welche Fassung gilt, wer sie freigegeben hat, ob die englische auf demselben Stand ist und ob man sie in acht Jahren noch vorzeigen kann. Diese vier Fragen beantwortet eine ordentlich aufgesetzte Bibliothek — und zwar ohne dass jemand seinen Beruf wechseln muss.
Der Aufwand dafür liegt bei etwa zwölf Wochen nebenher, und der größte Teil davon ist Nachdenken, nicht Klicken. Die Alternative ist, weiter darauf zu hoffen, dass die Kollegin aus der Elternzeit zurückkommt, bevor jemand die falsche Anleitung ausliefert.
|
WEITERLESEN · DIE ANSCHLUSSTHEMEN ZU DIESEM BAUSTEIN › Dokumentenlenkung nach ISO 9001 mit Word und SharePoint — die Normanforderung, auf die diese Struktur einzahlt › Aufbewahrung und Lebenszyklus technischer Doku in Microsoft 365 — was nach der Freigabe mit den Ständen passiert › Word richtig aufgesetzt: das unterschätzte Redaktionssystem — der zweite Baustein des Mittelwegs › Der Konstrukteur als Nebenbei-Redakteur: Doku-Pflichten ohne Redaktion — wer das Ganze im Alltag betreiben soll › Ab wann lohnt sich ein Redaktionssystem? Eine ehrliche Rechnung — wo der Mittelweg endet |
|---|
|
EINEN NACHMITTAG STRUKTUR STATT DREI JAHRE WILDWUCHS Der Schnitt des Lebenszyklus und die Frage, welche acht Spalten es wirklich werden, entscheiden sich am besten an deinem eigenen Bestand — nicht an einer Beispielbibliothek. Wenn du dafür einen unbeteiligten Blick möchtest: Beratung für technische Dokumentation. Und wenn das Modell steht, aber das Team noch Ansichten, Metadaten und Freigabeschritte im Alltag beherrschen soll: Schulung Technische Dokumentation. |
|---|
Dieses Consulting-Dokument steht als PDF zum Download bereit: https://www.boddenberg.de/ArtikelPdf/betriebsanleitungba.pdf — © Ulrich B. Boddenberg · boddenberg.de






