SharePoint als Doku-Plattform: Bibliotheken, Versionierung, Berechtigungen

SharePoint ist in den meisten Unternehmen längst da. Es ist lizenziert, es läuft, und irgendwo darin liegen auch die Handbücher – meist in einer Bibliothek, die aussieht wie das alte Netzlaufwerk, nur in Blau: sechs Ordnerebenen, Dateinamen mit „final" und „v3_neu", und die Frage nach dem gültigen Stand beantwortet weiterhin ein Kollege aus dem Gedächtnis. Die Plattform kann deutlich mehr – sie wurde nur nie eingerichtet, sondern in Betrieb genommen.

Das ist bemerkenswert, weil hier ein erheblicher Hebel ungenutzt liegt. Für Ablage, Versionierung, Freigaben mit Nachweis, Aufbewahrung und die Bereitstellung an Kunden ist SharePoint eine ausgesprochen tragfähige Doku-Plattform – ohne zusätzliche Lizenz, ohne Systemprojekt, mit den Werkzeugen, die ohnehin im Haus sind. Was es dafür braucht, ist keine Software, sondern ein Konzept: eine Architektur, ein Berechtigungsmodell und ein paar Entscheidungen, die man einmal trifft.

Dieser Artikel liefert genau das: eine Referenzarchitektur in vier Zonen, die Regeln für Bibliotheks-Zuschnitt und Berechtigungen, die Versionierungs- und Freigabelogik – und am Ende die ehrliche Abgrenzung, wo die Plattform aufhört und ein Redaktionssystem anfängt.

Vorab: Wo lebt die Doku-Plattform?

Bevor es um Bibliotheken geht, eine Ebene höher: Wo im Unternehmen soll die Doku eigentlich liegen? Die bewährte Antwort ist eine eigene Website für die Technische Dokumentation – nicht ein Ordner im Vertriebsbereich, nicht ein Teams-Kanal, der irgendwann für ein Projekt angelegt wurde. Der Grund ist nicht Prestige, sondern Sauberkeit: Berechtigungen, Aufbewahrungsregeln, Metadatenschema und Suche lassen sich für einen abgegrenzten Bereich sinnvoll konfigurieren; verstreut über fremde Bereiche ist beides mühsam bis unmöglich.

Ein Punkt verdient dabei Aufmerksamkeit, weil er oft unbedacht entsteht: Wenn ein Teams-Team angelegt wird, entsteht im Hintergrund automatisch eine SharePoint-Website – und die Dateiablage des Teams ist eine Dokumentbibliothek darin. Das ist praktisch für die Zusammenarbeit und ungeeignet als Doku-Plattform, weil die Struktur der Kommunikationslogik folgt statt der Dokumentlogik. Die pragmatische Trennung: Teams für Abstimmung und Kommentare, die Doku-Website für den verbindlichen Bestand. Wer beides vermischt, findet seine Handbücher später neben Urlaubsplänen und Sitzungsnotizen.

Zur Struktur selbst: Für eine mittelständische Redaktion genügt in der Regel eine Website mit wenigen Bibliotheken. Größere Häuser mit mehreren Standorten oder Geschäftsbereichen bauen mehrere Websites und verknüpfen sie über eine übergeordnete Hub-Struktur, sodass Suche und Navigation übergreifend funktionieren, während Berechtigungen getrennt bleiben. Das ist eine Architekturentscheidung, die man einmal trifft und danach selten ändert — sie gehört deshalb in den Konzeptnachmittag und nicht in den laufenden Betrieb.

Die Referenzarchitektur: vier Zonen

Der wirksamste Schritt ist eine gedankliche Trennung, die sich technisch fast von selbst umsetzt: Ein Dokument durchläuft vier Zonen mit unterschiedlichen Regeln. Zone eins ist der Arbeitsbereich der Redaktion – hier liegen Entwürfe und laufende Arbeit, Zugriff haben nur die Autoren. Hier darf es unfertig sein, hier wird ausgecheckt, hier greifen Nebenversionen. Entscheidend ist, was hier nicht passiert: Kein Fachbereich und kein Kunde sieht diese Zone, denn nichts verwirrt zuverlässiger als ein halbfertiger Entwurf, den jemand für die gültige Fassung hält.

Zone zwei ist die Prüfung: Konstruktion, Service und Qualität kommentieren. Wichtig ist die Rechtevergabe – Fachprüfer bekommen Lesezugriff mit Kommentarrecht, nicht Schreibrecht auf die Quelle. Wer redigieren darf, redigiert, und dann verhandelt die Redaktion über Formulierungen statt über Sachverhalte. Technisch braucht diese Zone keine eigene Bibliothek: Sie entsteht über das Statusfeld und passende Ansichten. Zone drei ist die Freigabe – die Hauptversion mit dokumentiertem Freigabevermerk. Ab hier gilt das Dokument, hier greifen Aufbewahrungsregeln, und von hier bedienen sich alle weiteren Kanäle: Intranet, Portal, Assistenten, Auslieferung.

Zone vier ist der Blick nach außen: die Bereitstellung für Kunden und Partner. Auch hier gilt eine Regel, die sich in der Praxis bewährt hat: nie einen Ordner spiegeln, sondern eine gefilterte Sicht bereitstellen – freigegeben, richtige Sprache, passendes Produkt. Wer stattdessen kopiert, hat zwei Wahrheiten und die klassische Frage, welche davon der Kunde gerade sieht. Wie diese externe Zone technisch aufgebaut wird – Gastzugriff, Portal oder öffentlicher Bereich –, ist ein eigenes Thema dieser Serie; für die Architektur genügt zu wissen, dass sie an Zone drei andockt und an nichts anderes.

Technisch lassen sich diese Zonen auf zwei Arten abbilden, und beide sind vertretbar. Variante eins: alles in einer Bibliothek, getrennt über das Statusfeld und Ansichten, mit Nebenversionen für den Entwurfszustand — schlank, wenig Verwaltung, gut für kleine Redaktionen. Variante zwei: getrennte Bibliotheken für Arbeit und Freigabe, mit einem definierten Übergabeschritt — mehr Verwaltung, dafür glasklare Berechtigungsgrenzen, sinnvoll wenn viele Menschen Lesezugriff brauchen oder Compliance-Anforderungen streng sind. Die Entscheidung hängt weniger an der Bestandsgröße als an der Zahl der Beteiligten außerhalb der Redaktion.

Abb.: Vier Zonen mit unterschiedlichen Regeln – und alles Weitere dockt an Zone drei an.

Ein letzter Architekturhinweis zur Zone drei, weil sie das Herzstück ist: Sie sollte so gebaut sein, dass sich der Kreis der Leseberechtigten leicht erweitern lässt, ohne die Struktur anzufassen. Denn erfahrungsgemäß wächst genau dieser Kreis — erst der Service, dann der Vertrieb, dann die Schulungsabteilung, irgendwann der Kunde. Wer von Anfang an über Gruppen berechtigt und die Freigabezone frei von Entwürfen hält, erweitert später mit einem Klick. Wer stattdessen Sonderrechte pflegt und Arbeitsstände dazwischen liegen hat, muss vor jeder Erweiterung aufräumen — und tut es deshalb nicht.

Bibliotheken zuschneiden

Die häufigste Frage beim Aufbau lautet: Wie viele Bibliotheken brauchen wir? Die Antwort ist unbequem knapp – möglichst wenige. Eine neue Bibliothek lohnt genau dann, wenn sich etwas Grundsätzliches unterscheidet: die Berechtigungen, die Aufbewahrungsregeln oder die Versionierungs- und Freigabelogik. Interne Serviceunterlagen gegenüber kundenseitig bereitgestellten Anleitungen sind ein guter Grund; alles andere ist meistens keiner.

Denn was nach einer neuen Bibliothek klingt, ist in aller Regel eine Metadatenfrage: anderes Produkt, andere Sprache, andere Dokumentart, anderer Bearbeitungsstand. All das sind Felder, und Felder filtert man – mit Ansichten, die genau die Fragen abbilden, die im Alltag gestellt werden. Der Fehler in die andere Richtung ist ebenso verbreitet und teurer: Wer für jedes Produkt eine eigene Bibliothek anlegt, baut sich denselben Silo-Effekt, den er mit den Ordnern gerade abgeschafft hat – nur dass diesmal auch die übergreifende Suche und Auswertung leidet.

Die inhaltliche Ordnung innerhalb der Bibliothek liefern Inhaltstypen. Für die Technische Dokumentation lohnen typischerweise drei bis fünf: Betriebsanleitung, Serviceanleitung, Datenblatt, gegebenenfalls Schulungsunterlage und internes Arbeitspapier. Jeder Inhaltstyp bringt seine Pflichtfelder mit, kann eine Dokumentvorlage tragen und – besonders wertvoll – unterschiedliche Aufbewahrungsregeln bekommen. Damit wird die Dokumentart zum echten Ordnungsprinzip statt zu einem Wort im Dateinamen; das Metadatenschema dahinter beschreibt der vorangegangene Beitrag im Detail.

Was die Bibliothek im Alltag bedienbar macht, sind die Ansichten — und sie werden regelmäßig unterschätzt. Eine gute Bibliothek hat vier bis sechs davon, jede auf eine Alltagsfrage zugeschnitten: alle freigegebenen Anleitungen nach Produkt, alles was gerade im Review ist, alle Dokumente einer Sprache, überfällige Überprüfungen, eigene Dokumente. Wer stattdessen die Standardansicht mit allen Spalten stehen lässt, verschenkt den Hauptnutzen der ganzen Konstruktion: Metadaten wirken erst, wenn jemand sie sieht. Und die Ansichten sind zugleich der Praxistest fürs Schema — was sich nicht als Ansicht bauen lässt, ist als Feld falsch geschnitten.

Abb.: Die Zuschnitt-Regel und die Berechtigungsregel – beide laufen auf Sparsamkeit hinaus.

Ein Sonderfall, der in der Maschinenbau-Praxis regelmäßig auftaucht, verdient Erwähnung: die Zulieferer-Dokumentation. Für eine Anlage kommen Anleitungen von Komponentenherstellern hinzu, die zur Gesamtdokumentation gehören, aber nicht selbst erstellt wurden. Sie brauchen dieselbe Ordnung wie eigene Dokumente — Produktzuordnung, Sprache, Stand — und ein zusätzliches Feld für die Herkunft. Der Fehler, den man vermeiden will: sie in einem separaten Zulieferer-Ordner abzulegen und beim Zusammenstellen der Auslieferungsdokumentation zu vergessen. Als Inhaltstyp mit eigenem Herkunftsfeld sind sie Teil des Bestands und tauchen in jeder relevanten Ansicht auf.

Versionierung und Freigabe

Jetzt zur Einstellung, die im Doku-Kontext den größten Unterschied macht: getrennte Haupt- und Nebenversionen. Nebenversionen – 0.1, 0.2, 0.3 – sind Arbeitsstände, die nur sieht, wer Bearbeitungsrechte hat. Hauptversionen – 1.0, 2.0 – sind freigegebene Stände, die alle Leseberechtigten sehen. Diese Trennung löst das Grundproblem jeder gemeinsamen Ablage: Die Redaktion kann jederzeit speichern und weiterarbeiten, ohne dass jemand einen Zwischenstand für die gültige Fassung hält. Wer nur eine Versionsart führt, hat entweder Angst vorm Speichern oder Verwirrung im Haus.

Dazu kommt das Auschecken – die exklusive Bearbeitung. In Zeiten der gemeinsamen Echtzeit-Bearbeitung wirkt das altmodisch, und für ein Besprechungsprotokoll ist es das auch. Für ein Handbuch, an dem gerade jemand strukturell arbeitet, ist es genau richtig: Es verhindert, dass zwei Autoren parallel unterschiedliche Änderungen einbauen und eine davon still verschwindet. Die pragmatische Regel: Auschecken für die großen Dokumente der Redaktionsbibliothek, gemeinsame Bearbeitung für alles, was ohnehin gemeinsam entsteht.

Und die Freigabe selbst? Sie besteht aus zwei Teilen: dem Statuswechsel im Metadatenfeld und dem Veröffentlichen der Hauptversion. Beides lässt sich mit den Automatisierungswerkzeugen der Plattform verbinden – Benachrichtigung an die Beteiligten, Eintrag des Freigabedatums, gegebenenfalls Weitergabe an das Portal. Wichtig ist der Nachweis: Wer hat wann freigegeben? Diese Angabe entsteht automatisch, wenn der Ablauf über die Plattform läuft, und muss mühsam rekonstruiert werden, wenn er per Mail läuft. Bei Dokumenten, die Teil des Produkts sind, ist das kein Komfortthema, sondern Nachweisführung.

Ein Wort zur Aufbewahrung, weil sie im Maschinenbau die härteste Anforderung ist: Die Versionshistorie ist kein Nachweis. Sie hilft beim Zurückgehen, kann aber begrenzt werden, und mit dem Dokument verschwindet sie mit. Für technische Unterlagen, die mindestens zehn Jahre nach dem Inverkehrbringen verfügbar bleiben müssen, braucht es bewusste Aufbewahrungsregeln über die Compliance-Werkzeuge der Plattform — idealerweise an Metadaten geknüpft, sodass die Frist automatisch am richtigen Datum startet. Dieses Thema hat in dieser Serie einen eigenen Beitrag; hier genügt der Merksatz, dass Ablage und Aufbewahrung zwei verschiedene Dinge sind.

Abb.: Der Lebenszyklus vom Entwurf bis zur Aufbewahrung – die Versionshistorie ersetzt dabei keine Aufbewahrungsregel.

Zur Automatisierung noch ein Hinweis, weil sie hier besonders leicht fällt: Die Plattform-Werkzeuge erlauben Abläufe ohne Programmierung — eine Erinnerung, wenn ein freigegebenes Dokument älter als zwei Jahre ist; eine Benachrichtigung an die Fachprüfer, sobald der Status auf „im Review" wechselt; ein Eintrag des Freigabedatums beim Statuswechsel auf „freigegeben". Drei bis vier solcher Abläufe decken den Doku-Alltag weitgehend ab, und sie hängen alle an denselben Metadatenfeldern. Wichtig ist nur die Zurückhaltung: Jeder Ablauf muss gewartet werden, und ein Dickicht aus zwanzig Automatismen ist schlimmer als Handarbeit — dazu mehr im eigenen Beitrag zur Automatisierung in der Redaktion.

Zwei Alltagsdetails, die über die Akzeptanz entscheiden, gehören noch dazu. Erstens die Synchronisierung: Bibliotheken lassen sich lokal einbinden, sodass Autoren im gewohnten Explorer arbeiten. Das ist bequem und hat einen Haken — beim lokalen Arbeiten geraten Metadaten und Ein-/Auschecken leicht aus dem Blick. Die pragmatische Regel: Synchronisierung für Lesezugriff und große Dateien, Bearbeitung möglichst im Browser oder direkt aus der Anwendung heraus. Zweitens die Suche: Sie wirkt erst richtig, wenn die Metadatenfelder als Verfeinerungen konfiguriert sind — sonst sucht man in einer gut strukturierten Bibliothek wie in einem Volltextarchiv.

Berechtigungen: so grob wie möglich

Berechtigungen sind der Bereich, in dem gut gemeinte Sorgfalt am meisten Schaden anrichtet. Die Regel lautet: so grob wie möglich, so fein wie nötig – und praktisch heißt das, Rechte auf Bibliotheksebene über Gruppen zu vergeben. Drei bis vier Gruppen decken die Technische Dokumentation meist ab: Redaktion mit Vollzugriff, Fachprüfer mit Lese- und Kommentarrecht, Leser mit Lesezugriff auf freigegebene Stände, und gegebenenfalls Externe mit Zugriff auf die Bereitstellungszone.

Was man dagegen unbedingt vermeiden will, sind Einzeldokument-Berechtigungen. Sie wirken im Moment praktisch – dieses eine Dokument soll die Konstruktion noch nicht sehen – und erzeugen ein Modell, das nach einem Jahr niemand mehr überblickt. Bei jedem Personalwechsel muss dann geprüft werden, wo überall Sonderrechte hängen, und die Antwort ist mühsam. Wenn ein Dokument tatsächlich anders behandelt werden muss, ist die saubere Lösung meist eine Zone weiter oben: eine eigene Bibliothek oder ein anderer Status.

Zwei Zusatzhebel gehören noch dazu. Erstens die Vertraulichkeitskennzeichnung: Über die Compliance-Werkzeuge der Plattform lassen sich Dokumente klassifizieren – intern, vertraulich, für Kunden freigegeben – und diese Kennzeichnung wirkt über die Bibliothek hinaus, etwa beim Teilen. Zweitens die Gastzugriffe: Wer Externe einbindet, sollte das über eine definierte Zone mit eigenen Gruppen tun statt über Einzelfreigaben, und die Zugänge regelmäßig prüfen. Beides ist weniger Aufwand als die Frage, wer eigentlich noch Zugriff hat – gestellt drei Jahre später bei einem Audit.

Nicht zu vergessen: Die Plattform ist auch der Ort, an dem die Doku für den Rest des Unternehmens sichtbar wird — und das ist strategisch mehr wert, als es klingt. Wenn Vertrieb, Service und Support die gültigen Anleitungen selbst finden, statt in der Redaktion anzurufen, sinkt die Zahl der Rückfragen spürbar. Voraussetzung ist eine Einstiegsseite, die nicht aus einer Dateiliste besteht, sondern aus den zwei, drei Fragen, die diese Kollegen tatsächlich haben: Welche Anleitung gilt für diese Maschine? Wo finde ich die englische Fassung? Wer diese Seite baut, macht aus einer Ablage einen Service — mit demselben Bestand.

Die Grenzen – ehrlich benannt

Und jetzt der Teil, der diesen Artikel von einer Produktbroschüre unterscheidet. SharePoint ist kein Redaktionssystem, und der Unterschied ist grundsätzlich: Die kleinste verwaltete Einheit ist die Datei. Alles, was die Plattform leistet, bezieht sich auf ganze Dokumente – Versionen, Berechtigungen, Metadaten, Aufbewahrung, Bereitstellung. Was sie nicht leisten kann, liegt unterhalb dieser Ebene: Sie kennt keine Topics, kann nicht sagen, in welchen anderen Dokumenten ein bestimmter Warnhinweis steckt, verwaltet keine Sprachstände einzelner Bausteine und steuert keine Varianten im Inhalt.

Ebenso wenig ist sie ein Redaktionswerkzeug: Geschrieben wird woanders – in Word, im Help-Authoring-Werkzeug, im XML-Editor. SharePoint verwaltet die Ergebnisse und, je nach Arbeitsweise, auch die Quelldokumente; es ersetzt aber weder Formatvorlagen-Disziplin noch Topic-Denken noch eine Publishing-Kette. Wer die Plattform mit der Erwartung einführt, sie werde die redaktionelle Ordnung schon herstellen, wird enttäuscht – dieselbe Erfahrung wie bei jedem System in diesem Themenfeld.

Diese Grenze zu kennen ist kein Nachteil, sondern die Voraussetzung dafür, dass die Sache funktioniert. Wer die Plattform für das einsetzt, was sie kann – Ablage, Ordnung, Freigabe, Nachweis, Bereitstellung –, bekommt eine erstaunlich tragfähige Doku-Umgebung ohne Systemprojekt und ohne Zusatzlizenz. Und wer feststellt, dass die fehlenden Fähigkeiten tatsächlich gebraucht werden – Verwendungsnachweis, Sprachstände je Baustein, Freigaben auf Bausteinebene –, hat damit die Anforderungsliste für die Systemfrage, die der Beitrag zur CCMS-Entscheidung behandelt.

Praktisch bedeutet das eine Arbeitsteilung, die man bewusst festlegen sollte. Bei dokumentbasierter Arbeitsweise liegen Quelle und Ergebnis beide in der Plattform — das Word-Dokument in der Redaktionszone, das erzeugte PDF in der Freigabezone. Bei strukturierter Arbeitsweise leben die Quellen typischerweise woanders, etwa in einer Versionsverwaltung, und die Plattform übernimmt ab dem erzeugten Ergebnis: Ablage, Freigabe, Aufbewahrung, Bereitstellung. Beide Aufteilungen funktionieren; entscheidend ist, dass sie dokumentiert ist — sonst landen Quellen und Ergebnisse durcheinander, und niemand weiß mehr, was wo gepflegt wird.

Abb.: Die Trennlinie verläuft an der Dateiebene – oberhalb ist die Plattform stark, unterhalb ist sie blind.

Bleibt die Frage, wie viel das alles kostet — und die Antwort ist der eigentliche Grund, warum dieser Weg für mittelständische Redaktionen so attraktiv ist: Die Plattform ist in aller Regel bereits lizenziert. Was anfällt, sind Konzept und Einrichtung, also Tage statt Budgets, plus die laufende Betreuung in Stundenbruchteilen. Zusätzliche Kosten entstehen nur an zwei Stellen: bei umfangreicheren Compliance-Funktionen für Aufbewahrung und Klassifizierung, die je nach Lizenzstufe unterschiedlich verfügbar sind, und bei externen Nutzern jenseits der Gastzugriffe. Beides gehört vorher geklärt — aber beides bewegt sich in einer anderen Größenordnung als ein Systemprojekt.

Der Einführungspfad

Wie führt man das ein, ohne den Betrieb anzuhalten? In vier Schritten, von denen die ersten beiden am wichtigsten sind. Schritt eins ist das Konzept: Zonen festlegen, Inhaltstypen bestimmen, Metadatenschema entwerfen, Berechtigungsgruppen definieren. Das ist ein Nachmittag Arbeit mit den richtigen Leuten am Tisch – Redaktion, IT und jemand, der die Aufbewahrungsanforderungen kennt. Schritt zwei ist die Einrichtung: Websitespalten anlegen, Inhaltstypen bauen, Bibliothek konfigurieren, Ansichten erstellen, Versionierung einstellen. Ein Tag, wenn das Konzept steht.

Schritt drei ist der Pilot mit einer Dokumentfamilie: eine überschaubare Menge echter Dokumente in die neue Struktur bringen, mit Metadaten versehen, den Freigabeweg einmal komplett durchlaufen. Hier zeigt sich, ob die Felder passen und die Ansichten die richtigen Fragen beantworten. Und Schritt vier ist der laufende Umzug: Neues entsteht ab sofort in der neuen Struktur, der Altbestand wandert priorisiert – aktive Dokumente zuerst, der Rest bei Gelegenheit. Dieselbe Logik wie bei jeder Migration in dieser Serie, und aus demselben Grund: Wer alles gleichzeitig will, bekommt nichts. Realistisch ist der aktive Bestand nach wenigen Wochen umgezogen, der Rest begleitet das Tagesgeschäft.

Und wie bei jedem Betriebsmittel in dieser Serie braucht auch die Plattform eine benannte Zuständigkeit — jemanden, der neue Inhaltstypen anlegt, Auswahlwerte freigibt, Berechtigungsgruppen pflegt und einmal im Jahr prüft, ob die Struktur noch zur Wirklichkeit passt. Das sind wenige Stunden im Quartal, aber sie müssen einen Namen haben. Ohne diese Rolle entstehen binnen eines Jahres wieder Ad-hoc-Bibliotheken, Sonderberechtigungen und ein Kopienordner, den jemand „nur vorübergehend" angelegt hat. Die Technik hält sich nicht selbst in Ordnung; sie macht Ordnung nur billig.

Fazit

SharePoint als Doku-Plattform ist kein Kompromiss, sondern für viele mittelständische Redaktionen die passende Lösung – vorausgesetzt, sie wird eingerichtet statt in Betrieb genommen. Die Referenzarchitektur aus vier Zonen, wenige Bibliotheken mit klaren Inhaltstypen, getrennte Haupt- und Nebenversionen, Berechtigungen über Gruppen und Aufbewahrung über die Compliance-Werkzeuge: Das ist der Kern, und er kostet Konzept- und Einrichtungstage statt eines Projektbudgets. Die Grenze verläuft an der Dateiebene – und wer sie kennt, weiß auch, wann die Systemfrage tatsächlich ansteht.

Der beste erste Schritt ist eine ehrliche Bestandsaufnahme: Wie viele Ordnerebenen sind es, wie viele Kopienordner gibt es, und wer kann ohne Rückfrage sagen, welcher Stand gilt? Die Antworten liefern das Argument für den Konzeptnachmittag. Wenn du dabei Unterstützung willst – von der Architektur über Inhaltstypen und Berechtigungsmodell bis zur Aufbewahrung und externen Bereitstellung: Genau dabei unterstütze ich dich gern; die Details findest du auf der Beratungsseite zur Technischen Dokumentation.

Häufige Fragen zu SharePoint als Doku-Plattform

Wie viele Bibliotheken brauchen wir?

Möglichst wenige. Eine eigene Bibliothek lohnt nur, wenn sich Berechtigungen, Aufbewahrungsregeln oder Freigabelogik grundsätzlich unterscheiden – etwa interne Serviceunterlagen gegenüber Kundendokumentation. Alles andere – anderes Produkt, andere Sprache, andere Dokumentart, anderer Status – sind Metadaten und werden über Ansichten gefiltert. Wer für jedes Produkt eine Bibliothek anlegt, baut denselben Silo-Effekt wie mit Ordnern, nur dass zusätzlich die übergreifende Suche und Auswertung leidet.

Welche Versionierungseinstellung ist die richtige?

Für Technische Dokumentation: Haupt- und Nebenversionen getrennt führen. Nebenversionen sind Arbeitsstände, die nur Bearbeiter sehen; Hauptversionen sind freigegebene Stände für alle Leseberechtigten. Damit kann die Redaktion jederzeit speichern, ohne dass jemand einen Zwischenstand für gültig hält. Ergänzend lohnt das Auschecken für große Dokumente, an denen strukturell gearbeitet wird – es verhindert, dass parallele Änderungen still verschwinden.

Wie regeln wir Berechtigungen sinnvoll?

So grob wie möglich: über Gruppen auf Bibliotheksebene. Drei bis vier Gruppen genügen meist – Redaktion mit Vollzugriff, Fachprüfer mit Lese- und Kommentarrecht, Leser mit Zugriff auf Freigegebenes, gegebenenfalls Externe für die Bereitstellungszone. Einzeldokument-Berechtigungen sollte man vermeiden: Sie wirken kurzfristig praktisch und erzeugen ein Modell, das nach einem Jahr niemand mehr überblickt und das bei jedem Personalwechsel neu geprüft werden muss.

Reicht die Versionshistorie als Nachweis?

Nein. Die Versionshistorie hilft beim Zurückgehen, ist aber kein Aufbewahrungsnachweis: Sie kann begrenzt oder gekürzt werden, und wenn das Dokument gelöscht wird, verschwindet sie mit. Für technische Unterlagen, die mindestens zehn Jahre nach dem Inverkehrbringen verfügbar bleiben müssen, braucht es bewusste Aufbewahrungsregeln über die Compliance-Werkzeuge der Plattform – idealerweise an Metadaten geknüpft, etwa an das Datum des Inverkehrbringens.

Kann SharePoint unser Redaktionssystem sein?

Nein, und diese Klarheit erspart Enttäuschungen. Die kleinste verwaltete Einheit ist die Datei – Topic-Verwaltung, Verwendungsnachweis für Bausteine, Sprachstände je Baustein und Variantensteuerung im Inhalt liegen außerhalb. Als Ablage-, Freigabe-, Aufbewahrungs- und Bereitstellungsplattform ist SharePoint dagegen ausgesprochen tragfähig. Wer die fehlenden Fähigkeiten tatsächlich braucht, hat damit die Anforderungsliste für die CCMS-Frage – und die stellt sich in kleinen Redaktionen seltener, als man denkt.