Wer verantwortet den Zusammenhang zwischen Wissen und Prozess?

Nehmen wir einen gedachten Servicebetrieb. Er hat eine Anleitung für die Inbetriebnahme eines Geräts und eine weitere für die Bearbeitung einer Störung. Beide sind gepflegt. Im Ablauf zur Störungsannahme ist jedoch noch die Inbetriebnahme verlinkt. Ein neuer Mitarbeitender arbeitet sie gewissenhaft durch und sammelt Angaben, die bei der Störungsbearbeitung nicht helfen.

Der Fehler liegt weder im Wortlaut der Anleitung noch in der Reihenfolge des Prozesses. Er liegt in der Zuordnung. Wer nur nach veralteten Dokumenten sucht, würde ihn übersehen. Auch eine bessere Suche löst ihn nicht automatisch: Sie könnte die falsche Anleitung besonders zuverlässig finden.

Die Fachredaktion kann bestätigen, dass die Anleitung stimmt. Die Prozessverantwortung muss zusätzlich beurteilen, ob sie an dieser Stelle gebraucht wird. In einem kleinen Unternehmen kann beides dieselbe Person sein. Die zwei Entscheidungen bleiben trotzdem verschieden.

Ein berechtigter Einwand lautet: Genau darum kümmert sich gutes Wissensmanagement längst. Es betrachtet Nutzung, Austausch und Pflege von Wissen, nicht nur die Ablage von Dateien. Wer das bereits gut organisiert hat, muss die Arbeit nicht neu benennen.

Ich halte wenig davon, Wissensmanagement künstlich auf Dokumente zu reduzieren, um anschließend eine größere Kategorie danebenstellen zu können. Der Begriff Context Management ist für mich dort nützlich, wo er eine bislang unklare Aufgabe sichtbar macht: die dauerhafte Verantwortung für die Beziehungen zwischen Wissen, Abläufen, Rollen und Systemen.

In „Prozesse hier, Wissen dort“ verwende ich dafür den Arbeitsbegriff Context Governance. Gemeint ist eine organisatorische Vereinbarung darüber, wer diese Beziehungen prüft und pflegt. Daraus folgt kein neuer Standard und auch nicht zwangsläufig ein neues Gremium.

Bleiben wir im Servicebetrieb. Die Störungsannahme wird künftig von einem externen Partner übernommen. Die interne Anleitung kann unverändert richtig sein. Für den neuen Ablauf stellen sich aber andere Fragen: Welche Informationen darf der Partner sehen? Wer nimmt unvollständige Meldungen zurück? Muss ein interner Prüfschritt erhalten bleiben?

Eine automatische Nachricht „Dokument aktualisiert“ hilft hier nicht weiter, weil gar kein Dokument geändert werden musste. Der Auslöser war die neue Verwendung. Deshalb gehören Änderungen an Rollen, Systemen und Abläufen ebenso zu den Prüfanlässen wie neue Wissensversionen.

Für die konkrete Zuordnung würde ich festhalten: Die Serviceleitung verantwortet, welche Anleitung in der Störungsannahme gilt. Die Fachredaktion hält deren Inhalt richtig. Wechselt der ausführende Partner oder verändert sich der Prozessschritt, prüft die Serviceleitung die Zuordnung erneut. Damit ist eine kleine Entscheidung getroffen, die sich tatsächlich ausführen lässt.

Eine pauschale Angabe wie „Verantwortlich: IT“ wäre zu ungenau. IT kann Zugriffe einrichten und Verknüpfungen technisch ermöglichen. Ob eine Anleitung fachlich zu einem Arbeitsschritt passt, braucht eine andere Zuständigkeit.

Man könnte nun jede Wissensseite mit jeder Rolle, jedem Prozess und jedem System verknüpfen. Das würde schnell eine zweite Dokumentationsaufgabe erzeugen. Eine Beziehung, die niemand verwendet oder bei Änderungen überprüft, verbessert die Arbeitsgrundlage kaum.

Mein Maßstab ist deshalb eine konkrete Entscheidung: Hilft diese Zuordnung jemandem, eine Aufgabe richtig auszuführen, eine Änderung einzuschätzen oder eine Rückfrage gezielt zu stellen? Bei der Störungsannahme ist der Nutzen klar. Bei einem allgemeinen Lesetipp im Team-Wiki kann eine zusätzliche Zuordnung unnötig sein.

Auch eine gut sichtbare offene Frage kann ein sinnvoller Zustand sein. Wenn zwei Teams unterschiedliche Anleitungen als führend ansehen, sollte die Inventur diesen Konflikt festhalten. Ihn durch eine beliebige Verlinkung zu verdecken, macht die Darstellung vollständiger und die Arbeit unzuverlässiger.

Eine erfahrene Kollegin erkennt möglicherweise, dass die verlinkte Inbetriebnahme nicht zur Störung passt. Dieses Erfahrungswissen lässt sich bei einer KI-Auskunft nicht voraussetzen. Wird die Zuordnung als Kontext bereitgestellt, kann die falsche Verbindung in eine sehr überzeugende Antwort einfließen.

Mehr Text im Zugriff ersetzt die fachliche Entscheidung deshalb nicht. Für mich ist die erste Frage vor einer solchen Anbindung: Können wir erklären, warum diese Quelle für genau diese Aufgabe maßgeblich ist? Wenn die Antwort nur lautet, dass sie im gleichen Ordner liegt, ist die Grundlage noch nicht geklärt.

Im Servicebeispiel wäre bereits viel gewonnen, wenn die nächste Person direkt bei der Störungsannahme die passende Anleitung, ihren Geltungsbereich und die verantwortliche Rolle findet. Das ist für Menschen hilfreich und gibt einer späteren KI-Unterstützung etwas Belastbares, worauf sie sich beziehen kann.

Die Kontext-Inventur macht diese Beziehung als einzelne, überprüfbare Zeile greifbar. Eine Zuordnung sauber festhalten