Metadaten für Technische Doku: Das Fundament für Suche und KI

Metadaten sind das unbeliebteste Thema der Technischen Dokumentation. Sie klingen nach Verwaltung, nach zusätzlichen Feldern beim Speichern, nach Bürokratie für einen Nutzen, den niemand sofort sieht. Entsprechend sieht die Realität aus: Dokumente heißen „Handbuch_M400_final_v3", liegen in einer sechsstufigen Ordnerhierarchie, und die Frage „Welche Anleitungen zur Baureihe M sind aktuell freigegeben?" beantwortet ein Kollege aus dem Gedächtnis – falls er da ist.

Und dann kommt Copilot ins Haus, und plötzlich wird das Thema dringend. Denn ein KI-Assistent, der auf einer Ablage ohne Metadaten arbeitet, findet den Entwurf von 2019 genauso zuverlässig wie die gültige Fassung – und er kann den Unterschied nicht erkennen, weil ihn niemand hingeschrieben hat. Die Antwort klingt dann genauso überzeugend wie eine richtige. Sie ist nur falsch.

Dieser Artikel liefert das Handwerkszeug: ein konkretes Metadaten-Schema mit sieben Feldern, die Umsetzung mit SharePoint-Spalten und Inhaltstypen – und die Erklärung, warum dieselben Felder, die heute die Suche verbessern, morgen darüber entscheiden, ob ein Assistent brauchbare Antworten gibt.

Kurz sortiert: Welche Metadaten es gibt

Der Begriff ist weit, deshalb eine schnelle Sortierung. Es gibt technische Metadaten, die das System ohnehin mitführt – Dateigröße, Erstellungsdatum, letzter Bearbeiter. Die sind nützlich, aber sie beschreiben die Datei, nicht den Inhalt. Es gibt fachliche Metadaten, die jemand vergeben muss: Um welches Produkt geht es, welche Dokumentart ist das, für wen ist es bestimmt, gilt es noch? Genau diese Schicht fehlt in den meisten Ablagen, und genau sie macht den Unterschied.

Zweite Unterscheidung: Metadaten am Dokument gegen Metadaten im Inhalt. In der Dokumentwelt hängen die Angaben an der Datei – das ist der Fall, um den es in diesem Beitrag vor allem geht. In strukturierten Umgebungen können auch einzelne Bausteine Metadaten tragen, etwa ein Topic mit Angaben zu Produktvariante und Zielgruppe. Beides ergänzt sich: Die Baustein-Ebene steuert, was in eine Publikation kommt; die Dokument-Ebene steuert, was mit dem Ergebnis passiert – Ablage, Freigabe, Bereitstellung, Aufbewahrung.

Und drittens die praktische Frage, wer die Werte einträgt. Ein Teil lässt sich automatisieren: Sprache und Dokumentart ergeben sich oft aus dem Ablageort und lassen sich vorbelegen, das Freigabedatum setzt der Workflow, die Version zählt das System. Was übrig bleibt, ist überschaubar – meist Produkt, Zielgruppe und Gültigkeit. Wer diese Aufteilung bewusst plant, reduziert die gefühlte Zusatzarbeit auf wenige Klicks je Dokument, und genau daran entscheidet sich die Akzeptanz.

Warum Ordner nicht reichen

Der klassische Weg, Ordnung zu schaffen, ist der Ordnerbaum – und er hat einen strukturellen Nachteil, den man erst merkt, wenn es zu spät ist: Er erzwingt genau eine Ordnung. Wer Produkte, dann Sprache, dann Dokumentart, dann Jahr verschachtelt, hat eine perfekte Struktur für alle, die zuerst nach Produkt suchen. Für die Kollegin, die alle französischen Dokumente sehen will, ist es eine Zumutung; für den Auditor, der alle freigegebenen Betriebsanleitungen sehen will, ebenso. Jede Ebene im Baum ist eine Entscheidung gegen alle anderen Sortierungen.

Metadaten drehen das um: Die Angaben hängen am Dokument, nicht an seinem Speicherort. Dasselbe Dokument trägt Produkt, Sprache, Dokumentart, Version, Status und Zielgruppe gleichzeitig – und jede Frage wird zu einem Filter statt zu einem Suchmarsch. „Alle freigegebenen Betriebsanleitungen zur Baureihe M auf Französisch" ist dann kein Projekt, sondern drei Klicks. Die Ordnung entsteht beim Suchen, nicht beim Ablegen.

Das heißt nicht, dass Ordner verboten wären – eine grobe Gliederung nach Bereich oder Produktlinie ist völlig in Ordnung und hilft der Orientierung. Die Regel lautet: Ordner bleiben grob, Feinheiten wandern in Felder. Ein guter Test ist die Frage, ob eine Ordnerebene jemals als Filter gebraucht würde: Wenn ja, gehört sie als Metadatum ans Dokument, nicht in den Pfad. Denn was im Pfad steht, ist für Suche und Auswertung praktisch unsichtbar.

Abb.: Eine erzwungene Ordnung gegen beliebig viele Sichten – der Unterschied zeigt sich bei jeder Suche.

Ein Missverständnis sei noch ausgeräumt, weil es die Einführung erschwert: Metadaten ersetzen keine gute Benennung. Ein sprechender Dateiname mit Dokumentkennung, Produkt, Sprache und Version bleibt sinnvoll — er hilft, wenn eine Datei die Ablage verlässt, per Mail wandert oder auf dem Rechner eines Kunden landet, wo die Metadaten nicht mitreisen. Die beiden ergänzen sich also: Der Dateiname trägt das Wichtigste mit sich, die Metadaten machen den Bestand auswertbar. Wer nur eines von beidem pflegt, verliert je nach Situation die eine oder die andere Hälfte.

Das Schema: sieben Felder, die reichen

Damit zum Kern: Wie sieht ein brauchbares Schema aus? Sieben Felder decken die Technische Dokumentation weitgehend ab. Erstens die Dokumentart – Betriebsanleitung, Serviceanleitung, Datenblatt, Schulungsunterlage. Sie ist das wichtigste Ordnungsfeld, weil an ihr Pflichten hängen: Eine Betriebsanleitung unterliegt Aufbewahrungsfristen und Sprachanforderungen, eine interne Notiz nicht. Zweitens Produkt beziehungsweise Baureihe – aus einer gepflegten Auswahlliste, niemals als Freitext, weil „M400", „M-400" und „Baureihe M400" sonst drei verschiedene Werte sind und jeden Filter unbrauchbar machen.

Drittens die Sprache als Sprachkürzel, eine je Dokument. Viertens Version und Freigabedatum – die Grundlage jedes Nachweises, wie es der Beitrag zu den Aufbewahrungspflichten ausführt. Fünftens der Status: in Arbeit, im Review, freigegeben, überholt. Dieses Feld wirkt banal und ist das wertvollste im ganzen Schema, weil es als einziges beantwortet, was gerade gilt. Sechstens die Zielgruppe – Bediener, Instandhaltung, Fachpersonal, intern –, die Berechtigungen und Bereitstellung steuert. Und siebtens die Gültigkeit beziehungsweise das Datum des Inverkehrbringens der zugehörigen Maschine: Daran hängt die Aufbewahrungsfrist von mindestens zehn Jahren, und ohne dieses Datum lässt sie sich nicht automatisieren.

Wichtiger als die genaue Feldliste ist die Auswahlregel dahinter, und sie ist streng: Jedes Feld muss eine Frage beantworten, die jemand tatsächlich stellt. Wer ein Feld nicht mit einem konkreten Anwendungsfall begründen kann – Suche, Filter, Berechtigung, Automatisierung, Nachweis –, streicht es. Denn jedes zusätzliche Feld kostet bei jedem Dokument Aufmerksamkeit, und Aufmerksamkeit ist die knappste Ressource in jeder Redaktion. Ein Schema mit sieben gepflegten Feldern ist unendlich viel wert; eines mit zwanzig halb gefüllten ist Datenmüll mit Struktur — und schlimmer als gar keines, weil er Verlässlichkeit vortäuscht.

Wo Erweiterungen sinnvoll sind, ergeben sie sich aus dem Anwendungsfall. Wer viele Varianten führt, ergänzt ein Feld für die Ausstattungs- oder Optionskennung. Wer regulatorisch stark gebunden ist, ergänzt einen Verweis auf die zugehörige Konformitätsdokumentation. Wer intensiv übersetzt, ergänzt den Übersetzungsstand oder das Quellsprachen-Dokument als Verknüpfung. Alle drei sind gute Felder — aber eben nur dort, wo der Fall existiert. Das Schema wächst mit dem Bedarf und nicht auf Vorrat; ein guter Rhythmus ist die jährliche Prüfung, ob ein Feld gepflegt wird und ob eines fehlt.

Abb.: Ein Beispielschema mit sieben Feldern – jedes mit konkretem Zweck, keines als Freitext.

Umsetzung in SharePoint

Wie wird daraus eine funktionierende Ablage? In der Microsoft-365-Welt führt der Weg über drei Bausteine, und ihre Reihenfolge entscheidet über die spätere Konsistenz. Erster Baustein: Websitespalten. Jedes Feld wird einmal zentral definiert – mit Typ, Auswahlwerten und Beschreibung – und steht dann überall zur Verfügung. Der Fehler, den man hier vermeiden will, ist die Ad-hoc-Spalte: Wer in jeder Bibliothek eigene Felder anlegt, hat nach einem Jahr dreimal „Produkt" mit unterschiedlichen Werten und keine übergreifende Auswertung mehr.

Zweiter Baustein: Inhaltstypen. Sie bündeln die Felder je Dokumentart – der Inhaltstyp „Betriebsanleitung" trägt eben andere Pflichtfelder als „Besprechungsnotiz" – und können zusätzlich eine Dokumentvorlage, Aufbewahrungsregeln und Workflow-Zuordnungen mitbringen. Damit wird die Dokumentart zum echten Ordnungsprinzip statt zu einem Wort im Dateinamen. Dritter Baustein: die Dokumentbibliothek, in der die Inhaltstypen genutzt werden und in der die Menschen arbeiten – mit Ansichten und Filtern, die genau die Fragen abbilden, die im Alltag gestellt werden.

Für Werte, die es hausweit nur einmal geben soll – Produkte, Baureihen, Dokumentarten, Zielgruppen –, lohnt der Blick auf verwaltete Metadaten: zentral gepflegte Wertelisten, die überall dieselben Begriffe liefern. Das ist die technische Entsprechung der Terminologiearbeit aus dem vorigen Beitrag, nur eine Ebene höher: Was dort für Fachbegriffe im Text gilt, gilt hier für Ordnungswerte am Dokument. Und wie dort braucht es eine benannte Zuständigkeit für die Pflege, sonst wuchern die Werte, sobald jemand ein neues Produkt anlegen darf.

Eine architektonische Frage stellt sich dabei früh: eine Bibliothek für alles oder mehrere? Die pragmatische Antwort für kleine und mittlere Bestände lautet: möglichst wenige, dafür gut strukturiert. Getrennte Bibliotheken lohnen dort, wo Berechtigungen sich grundsätzlich unterscheiden — etwa interne Serviceunterlagen gegenüber kundenseitig bereitgestellten Anleitungen — oder wo Aufbewahrungsregeln abweichen. Alles andere lässt sich über Metadaten und Ansichten trennen, ohne den Bestand zu zerlegen. Wer zu früh zu viele Bibliotheken anlegt, baut sich denselben Silo-Effekt, den er mit den Ordnern gerade abgeschafft hat.

Abb.: Websitespalten, Inhaltstypen, Bibliothek – und verwaltete Metadaten für hausweit einheitliche Werte.

Zum Schluss der Umsetzungsfrage noch ein Wort zur Sprache der Feldnamen: Sie sollten heißen, wie im Haus gesprochen wird, nicht wie im Systemhandbuch. „Baureihe" statt „Produktklassifikation", „gilt ab" statt „Gültigkeitsbeginn". Klingt nebensächlich und entscheidet mit darüber, ob Autoren die Felder richtig befüllen — denn ein Feld, dessen Bedeutung man erraten muss, wird geraten. Dieselbe Sorgfalt lohnt bei den Auswahlwerten: Sie stammen idealerweise aus der Terminologie, die ohnehin gilt, statt eine zweite Begriffswelt neben der bestehenden aufzubauen.

Bleibt die Frage nach dem Zusammenspiel mit einem Redaktionssystem, falls eines existiert oder geplant ist. Die Antwort ist eine Arbeitsteilung: Das Redaktionssystem verwaltet die Metadaten der Bausteine — Produktvariante, Zielgruppe, Gültigkeit auf Topic-Ebene —, die Dokumentplattform die Metadaten der Ergebnisse. Doppelte Pflege entsteht nur dort, wo beide Ebenen dieselben Angaben brauchen; für diese Fälle lohnt es, die Werte einmal festzulegen und beim Erzeugen der Ausgaben mitzugeben statt sie erneut zu tippen. Wer das früh klärt, vermeidet die klassische Situation, in der ein Dokument im System als freigegeben gilt und in der Ablage als Entwurf.

Der Nutzen im Alltag – vor jeder KI

Bevor es um Assistenten geht, der unmittelbare Ertrag, denn er trägt die Einführung schon allein. Erstens die Suche: Eine Suche, die nach Dokumentart, Produkt und Status filtern kann, liefert Treffer statt Trefferlisten. Der Unterschied zwischen „vierhundert Ergebnisse" und „drei Ergebnisse, alle relevant" ist genau dieser Filter – wie man die Suche darauf einstellt, behandelt der Beitrag zur SharePoint-Suche. Zweitens die Vollständigkeitsprüfung: Eine nach Produkt und Sprache gefilterte Ansicht zeigt sofort, welche Sprachfassung fehlt – eine Frage, die in mehrsprachigen Redaktionen sonst eine Excel-Liste braucht, die selbst veraltet.

Drittens die Automatisierung. Metadaten sind das, woran Automatismen andocken: Eine Erinnerung an die fällige Überprüfung, wenn das Freigabedatum älter als zwei Jahre ist. Eine Benachrichtigung, wenn ein Dokument von „im Review" auf „freigegeben" wechselt. Eine Aufbewahrungsregel, die am Datum des Inverkehrbringens hängt und die Frist automatisch berechnet. All das braucht keine Programmierung, nur Felder mit verlässlichen Werten – ohne sie ist jede Automatisierung Handarbeit mit Zusatzschritt.

Und viertens die Bereitstellung nach außen. Wer digitale Anleitungen für Kunden bereitstellt – ein Thema, das mit der EU-Maschinenverordnung an Gewicht gewinnt –, braucht eine verlässliche Auskunft darüber, welche Fassung in welcher Sprache für welches Produkt gilt. Genau das leisten Metadaten: Der Kundenzugang zeigt gefiltert, was freigegeben und für dieses Produkt gültig ist, statt einen Ordner zu spiegeln, in dem auch Entwürfe liegen. Ohne Metadaten ist externe Bereitstellung entweder Handarbeit oder ein Risiko.

Damit dieser Nutzen nicht nach einem Jahr erodiert, braucht auch das Metadatenmodell eine benannte Zuständigkeit — dieselbe Rolle, die in dieser Serie schon für Vorlagen, Strukturmodelle und Terminologie gefordert wurde, und in kleinen Häusern gern dieselbe Person. Ihre Aufgaben sind überschaubar: neue Auswahlwerte freigeben statt sie wuchern zu lassen, einmal im Jahr prüfen, ob Felder gepflegt werden und welche fehlen, und bei neuen Dokumentarten den passenden Inhaltstyp anlegen. Wenige Stunden im Quartal — aber ohne sie schleicht sich der Wildwuchs zurück, den man gerade beseitigt hat.

Ein weiterer Alltagsnutzen betrifft die Übergabe und Vertretung. Wer heute im Urlaub ist, ist morgen im Projekt und übermorgen in Rente — und mit ihm verschwindet das Wissen, welche Datei gilt und wo die aktuelle Fassung liegt. Metadaten machen dieses Wissen explizit und damit übertragbar: Eine neue Kollegin findet den gültigen Stand über einen Filter statt über eine Rückfrage. In kleinen Redaktionen, in denen ein oder zwei Personen den gesamten Bestand im Kopf haben, ist das kein Komfort, sondern Risikovorsorge — und es ist derselbe Gedanke, der schon bei Terminologie und Vorlagen trägt: Betriebsmittel gehören ins System, nicht ins Gedächtnis.

Und noch eine Ergänzung zur Aufbewahrung, weil sie im Maschinenbau die härteste Anforderung ist: Technische Unterlagen müssen mindestens zehn Jahre nach dem Inverkehrbringen verfügbar bleiben, und im Streitfall zählt der ausgelieferte Stand. Diese Frist automatisch zu berechnen setzt genau ein Feld voraus — das Datum, ab dem das zugehörige Produkt in Verkehr gebracht wurde. Liegt es vor, lässt sich die Aufbewahrung über die Compliance-Werkzeuge der Plattform regeln, statt sie in einer Kalendererinnerung zu führen. Fehlt es, bleibt nur die pauschale Aufbewahrung von allem — was funktioniert, aber weder elegant noch billig ist.

Warum KI-Assistenten Metadaten brauchen

Jetzt zum Thema, das die Dringlichkeit erzeugt hat. Ein KI-Assistent wie Copilot arbeitet auf den Inhalten, auf die er Zugriff hat – er sucht relevante Passagen und formuliert daraus eine Antwort. Das funktioniert erstaunlich gut, solange die Ausgangsmenge stimmt. Und genau da liegt das Problem: Ein Assistent kann nicht wissen, welche von drei ähnlichen Anleitungen die gültige ist. Er sieht drei Texte über den Filterwechsel – einen von 2019, einen Entwurf im Teamordner und die aktuelle Fassung. Alle drei sind sprachlich plausibel, alle drei handeln vom richtigen Thema.

Ohne Metadaten wählt er nach inhaltlicher Ähnlichkeit – und die sagt nichts über Gültigkeit. Mit Metadaten wird die Auswahl zur Filterfrage: Produkt gleich Baureihe M, Status gleich freigegeben, Sprache passend, aktuellste Version. Aus zehntausend Seiten werden vierzig relevante, und die Antwort stammt aus der Fassung, die tatsächlich gilt. Deshalb ist „Status = freigegeben" das wertvollste Feld im ganzen Schema – es ist das einzige, das die Frage beantwortet, die ein Assistent nicht selbst beantworten kann.

Der zweite Beitrag der Metadaten ist die Nachprüfbarkeit. Ein Assistent, der seine Antwort mit Quellenangabe versieht, ist nur so vertrauenswürdig wie die Möglichkeit, die Quelle einzuordnen: Aus welchem Dokument, welcher Version, welchem Stand stammt das? Genau diese Angaben liefern Metadaten mit. Und der dritte Beitrag ist die Zugriffssteuerung: Was ein Assistent zeigt, richtet sich nach den Berechtigungen des Fragenden – und die hängen an Bibliotheken und Feldern wie der Zielgruppe. Interne Serviceunterlagen sollen dem Kunden nicht in der Antwort erscheinen, und das regeln keine Dateinamen, sondern Felder und Bibliotheken.

Neben den Metadaten spielt die Struktur der Inhalte selbst eine Rolle, und beide verstärken sich. Ein Assistent arbeitet mit Textabschnitten; je klarer diese abgegrenzt und benannt sind, desto präziser sind die Fundstellen. Ein Dokument mit aussagekräftigen Überschriften und eigenständig verständlichen Abschnitten liefert bessere Antworten als ein Fließtext-Monolith, in dem der entscheidende Satz im dritten Absatz eines Kapitels namens „Allgemeines" steht. Insofern zahlt alles ein, was diese Serie an anderer Stelle empfiehlt: Formatvorlagen-Disziplin, Topic-Denken, sprechende Titel und konsistente Terminologie — mit KI im Haus wird daraus ein unmittelbar spürbarer Vorteil.

Abb.: Dieselbe Frage, zwei Ausgangslagen – der Unterschied zwischen einer richtigen und einer überzeugenden Antwort.

Einführung ohne Widerstand

Bleibt die praktische Frage, wie man das einführt, ohne dass die Autoren revoltieren – denn Metadatenpflege gilt als Zusatzarbeit. Der erste Hebel ist die Menge: sieben Felder statt zwanzig. Der zweite ist die Vorbelegung: Standardwerte je Bibliothek sorgen dafür, dass Dokumentart, Sprache und Produkt bereits stimmen, wenn ein Autor an der richtigen Stelle speichert – gepflegt werden muss nur die Abweichung. Der dritte ist die Pflicht: Optionale Felder bleiben in der Praxis zu zwei Dritteln leer, Pflichtfelder werden ausgefüllt. Weniger Felder, aber die verbindlich – das ist die Formel.

Der vierte Hebel ist der sichtbare Nutzen, und er wird am häufigsten vergessen. Metadaten, die niemand nutzt, wirken wie Bürokratie; dieselben Metadaten mit guten Ansichten wirken wie eine Erleichterung. Deshalb gehört zur Einführung immer die Ansichtenarbeit: eine Ansicht „Meine Dokumente im Review", eine „Alle freigegebenen Anleitungen nach Produkt", eine „Überfällige Überprüfung". Wenn Autoren am zweiten Tag merken, dass sie Dinge finden, für die sie vorher jemanden fragen mussten, ist die Diskussion beendet.

Und der fünfte: die Altbestände nicht zur Bedingung machen. Der verbreitete Fehler ist, erst den gesamten Bestand nachzupflegen und dann zu starten – das dauert Monate, in denen nichts wirkt. Besser ist der Schnitt: Ab jetzt wird alles Neue mit Metadaten abgelegt; der Altbestand wird nachgepflegt, wenn ein Dokument ohnehin angefasst wird, und ansonsten priorisiert – die aktiven Dokumente zuerst, der Rest nach Bedarf. Dieselbe Logik wie bei der Migration aus dem Word-Grab, und aus demselben Grund: Wer alles gleichzeitig will, bekommt nichts.

Zur Erwartung an den Aufwand: Das Schema zu entwerfen und in SharePoint umzusetzen ist eine Sache von Tagen, nicht Wochen — vorausgesetzt, die Fragen aus dem Alltag liegen vor und man widersteht der Versuchung, alles auf einmal abbilden zu wollen. Der größere Posten ist die Nachpflege des Altbestands, und genau der lässt sich strecken. Und der laufende Aufwand je Dokument liegt bei gut vorbelegten Feldern im Sekundenbereich. Wer über Metadaten als Belastung spricht, meint meistens nicht die Pflege, sondern ein schlecht geschnittenes Schema mit zu vielen Freitextfeldern.

Fazit

Metadaten sind keine Verwaltungsübung, sondern die Schicht, die aus einer Dateiablage eine auswertbare Wissensbasis macht. Sieben Felder genügen – Dokumentart, Produkt, Sprache, Version, Status, Zielgruppe, Gültigkeit –, umgesetzt als zentrale Websitespalten, gebündelt in Inhaltstypen und gestützt auf verwaltete Metadaten für einheitliche Werte. Der Ertrag beginnt bei der Suche, geht über Vollständigkeitsprüfung, Automatisierung und externe Bereitstellung – und endet vorerst bei der Frage, ob ein KI-Assistent unterscheiden kann, was gilt.

Der beste erste Schritt kostet eine Woche Aufmerksamkeit: die Fragen sammeln, die im Alltag tatsächlich gestellt werden. Daraus entsteht ein Schema, das klein genug ist, um gepflegt zu werden, und nützlich genug, um akzeptiert zu werden. Wenn du beim Schema, bei der Umsetzung in SharePoint oder bei der Vorbereitung auf KI-Assistenten Unterstützung willst: Genau dabei unterstütze ich dich gern; die Details findest du auf der Beratungsseite zur Technischen Dokumentation.

Häufige Fragen zu Metadaten in der Technischen Dokumentation

Welche Metadaten brauchen wir mindestens?

Sieben Felder decken die Technische Dokumentation weitgehend ab: Dokumentart, Produkt oder Baureihe, Sprache, Version mit Freigabedatum, Status, Zielgruppe und Gültigkeit beziehungsweise Datum des Inverkehrbringens. Wichtiger als die genaue Liste ist die Auswahlregel: Jedes Feld muss eine Frage beantworten, die jemand tatsächlich stellt – Suche, Filter, Berechtigung, Automatisierung oder Nachweis. Felder ohne konkreten Anwendungsfall werden nicht gepflegt und verwässern das Schema.

Ordner oder Metadaten – was ist besser?

Beides, aber mit klarer Rollenteilung. Ordner erzwingen genau eine Ordnung: Wer nach Produkt, Sprache, Art und Jahr verschachtelt, macht jede andere Sortierung mühsam. Metadaten hängen am Dokument und erlauben beliebig viele Sichten – jede Frage wird zum Filter. Die bewährte Regel: Ordner bleiben grob (Bereich, Produktlinie), Feinheiten wandern in Felder. Testfrage für jede Ordnerebene: Würde jemand danach filtern wollen? Dann gehört sie als Metadatum ans Dokument.

Wie setzen wir das in SharePoint um?

Über drei Bausteine in dieser Reihenfolge: Websitespalten definieren jedes Feld einmal zentral, damit nicht jede Bibliothek eigene Varianten erfindet. Inhaltstypen bündeln die Felder je Dokumentart und können Vorlage, Aufbewahrungsregeln und Workflows mitbringen. Dokumentbibliotheken nutzen die Inhaltstypen und zeigen Ansichten und Filter. Für hausweit einheitliche Werte – Produkte, Dokumentarten, Zielgruppen – kommen verwaltete Metadaten dazu, zentral gepflegt mit benannter Zuständigkeit.

Was hat Copilot mit Metadaten zu tun?

Alles. Ein Assistent sucht inhaltlich passende Passagen – aber inhaltliche Ähnlichkeit sagt nichts über Gültigkeit. Ohne Metadaten findet er die Anleitung von 2019, den Entwurf und die aktuelle Fassung gleichermaßen und kann nicht unterscheiden, welche gilt; die Antwort klingt trotzdem überzeugend. Mit Metadaten wird die Auswahl eingegrenzt: Produkt, Status freigegeben, passende Sprache, aktuellste Version. Deshalb ist „Status = freigegeben" das wertvollste Feld – es beantwortet die einzige Frage, die ein Assistent nicht selbst beantworten kann.

Müssen wir den kompletten Altbestand nachpflegen?

Nein, und dieser Anspruch bringt Einführungen regelmäßig zum Stillstand. Bewährt hat sich der Schnitt: Ab sofort wird alles Neue mit Metadaten abgelegt. Der Altbestand wird priorisiert nachgepflegt – aktive Dokumente zuerst, der Rest bei Gelegenheit oder gar nicht. Für Dokumente, die weder gepflegt noch gebraucht werden, ist ein pauschaler Status wie „überholt" plus Ausschluss aus Suche und Assistenten-Zugriff oft die pragmatischste Lösung.