Wer verantwortet den Zusammenhang zwischen Wissen und Prozess?

Nehmen wir einen gedachten Servicebetrieb, der sowohl die Inbetriebnahme neuer Geräte als auch die Bearbeitung späterer Störungen unterstützt. Für beide Aufgaben gibt es gepflegte Anleitungen. Im Ablauf zur Störungsannahme ist jedoch noch die Anleitung zur Inbetriebnahme verlinkt. Ein neuer Mitarbeitender folgt dem Verweis und arbeitet die dort beschriebenen Fragen ab. Er sammelt dadurch Angaben zum Aufbau des Geräts, während der nächste Bearbeiter vor allem wissen müsste, welche Störung im laufenden Betrieb beobachtet wurde.

Bei einer reinen Inhaltsprüfung würde dieser Fehler möglicherweise unbemerkt bleiben, weil die Inbetriebnahmeanleitung weiterhin richtig ist. Unpassend ist ihre Verwendung in der Störungsannahme. Wenn die Zuordnung ungeprüft bleibt, kann eine verbesserte Suche sogar dafür sorgen, dass die ungeeignete Anleitung noch leichter gefunden wird. Um das Problem zu beheben, muss deshalb jemand den dokumentierten Zusammenhang mit der tatsächlichen Aufgabe vergleichen.

Die Fachredaktion kann beurteilen, ob die Anleitung die Inbetriebnahme korrekt beschreibt. Ob sie der Störungsannahme hilft, muss dagegen die Person beurteilen, die diesen Ablauf verantwortet. In einem kleinen Unternehmen können beide Aufgaben bei derselben Person liegen. Trotzdem sollte bei einer Prüfung erkennbar sein, ob nur der Inhalt geprüft wurde oder auch seine Verwendung im konkreten Prozess.

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.

Der Unterschied wird besonders deutlich, wenn sich die ausführende Organisation verändert. Angenommen, der Servicebetrieb gibt die Störungsannahme an einen externen Partner ab. Die technische Beschreibung des Geräts kann dabei unverändert richtig bleiben. Der neue Ablauf braucht aber eine überprüfte Vereinbarung darüber, welche Informationen der Partner verwenden darf, welche Angaben er an den internen Service übergibt und wer unvollständige Meldungen zur Klärung zurücknimmt.

Eine Benachrichtigung über geänderte Dokumente würde diese Prüfung nicht unbedingt auslösen, weil sich der Inhalt der Anleitung gar nicht geändert haben muss. Verändert hat sich, wer sie in welchem Ablauf nutzt. Wenn Beziehungen nur bei einer neuen Dokumentversion überprüft werden, bleibt dieser Anlass unberücksichtigt. Deshalb müssen auch passende Änderungen an Rollen, Anwendungen und Prozessen in die Pflegevereinbarung aufgenommen werden.

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.

Praktisch braucht es dafür eine erreichbare Person mit einer klar beschriebenen Entscheidung. Wird bei der Übergabe an den Partner ein Problem mit der Anleitung festgestellt, muss die Erstaufnahme wissen, an wen sie die Rückfrage richtet. Diese Person prüft die Verwendung, stimmt sich bei Bedarf mit der Fachredaktion ab und hält das Ergebnis an der Zuordnung fest. So wird aus dem allgemeinen Wunsch nach „Verantwortung“ ein Weg, über den die konkrete Unklarheit bearbeitet wird.

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