Ein Unternehmen kann seine Prozesse sauber modelliert haben. Es kann gleichzeitig ein ordentlich gepflegtes Intranet besitzen, klare Richtlinien veröffentlichen und sogar einen Company Brain aufbauen.
Und trotzdem fehlt im Arbeitsalltag etwas Entscheidendes.
Der Prozess zeigt, was als Nächstes passieren soll. Die Arbeitsanweisung erklärt die Aufgabe. Eine frühere Entscheidung liegt in einem Protokoll. Die Ausnahme steht in einer E-Mail. Welcher Inhalt für diesen Fall führt und warum, weiß am Ende die Person, die lange genug dabei ist.
Mich beschäftigt diese Trennung, weil beide Seiten für sich sinnvoll aufgebaut sein können. Prozessmanagement soll Komplexität reduzieren und den verlässlichen Ablauf zeigen. Wissensmanagement braucht Raum für Erklärung, Hintergründe und Erfahrung. Schwierig wird es erst an der Stelle, an der die konkrete Arbeit beides gleichzeitig benötigt.
Für diese Verbindung verwende ich hier den Begriff Context Governance. Das ist keine einheitlich standardisierte Methode und auch kein Versuch, eine neue Governance-Disziplin neben alle bestehenden zu stellen. Es ist meine organisationale Einordnung für eine Aufgabe, die in vielen Unternehmen zwischen den Zuständigkeiten liegt.
Context Governance erweitert Process Governance um die Wissensversorgung der Arbeit. Sie verbindet einen Prozessschritt mit den Inhalten, Quellen und Nutzungsregeln, die Menschen oder technische Systeme dort tatsächlich brauchen. Knowledge und Content Governance bleiben wichtig. Sie sorgen weiterhin dafür, dass Inhalte gepflegt und auffindbar sind. Context Governance klärt ihre Bedeutung im Prozess.
Genau darin liegt für mich der neue Gedanke. Der frühere Beitrag über die lebende Unternehmenskarte beschrieb die Infrastruktur, die Zusammenhänge sichtbar macht.[3] Hier geht es eine Ebene tiefer: Wie betreiben und verantworten wir die Verbindung zwischen Prozess und Wissen im Alltag?
Die entscheidende Lücke ist die Zuordnung
Ein Prozessmodell verbindet Schritte, Rollen, Entscheidungen und Kontrollen. Ein Wissenssystem verbindet Inhalte mit Eigentümerschaft, Versionen und Ablageorten. Was zwischen beiden häufig fehlt, ist die fachliche Zuordnung.
Für einen konkreten Prozessschritt sollte sich beantworten lassen: Welche Quelle ist für diese Rolle und diese Entscheidung maßgeblich? Für welchen Fall gilt sie? In welchem Stand wird sie gebraucht? Welches Fachsystem liefert die ergänzende Information? Und wann endet die zulässige Nutzung?
Ein Dokument kann korrekt versioniert, freigegeben und leicht auffindbar sein. Das macht es noch nicht zum richtigen Arbeitskontext. Auffindbarkeit ist keine Aussage über Geltung.
Diese Unterscheidung wird mit AI operativ. Ein System kann das gesamte Intranet durchsuchen und trotzdem eine fachlich falsche Quelle heranziehen. Es kann eine passende Richtlinie finden, ohne zu erkennen, dass eine autorisierte Entscheidung ihren Geltungsbereich verändert hat. Es kann die Prozessbeschreibung lesen und den maßgeblichen Datenstand aus dem Fachsystem übersehen.
Sobald eine Empfehlung in eine Entscheidung einfließt oder ein Arbeitsschritt automatisch ausgeführt wird, reicht eine plausible Fundstelle nicht mehr aus. Dann muss klar sein, warum der Inhalt relevant ist, woher er stammt, in welchem Zusammenhang er gilt und wofür er verwendet werden darf.
Anthropic beschreibt Context Engineering als die laufende Auswahl und Pflege der Informationen, die ein Modell für eine konkrete Aufgabe erhält. Kontext ist dabei eine begrenzte Ressource. Ein kleiner, signalstarker Ausschnitt ist nützlicher als eine wahllose Sammlung.[1]
Damit dieser Ausschnitt entstehen kann, braucht das Unternehmen eine belastbare Grundlage. Menschen und AI müssen nicht dieselbe Darstellung erhalten. Sie sollten aber auf dieselben verantworteten Quellen und Beziehungen zugreifen können.
Was an einem Prozessschritt wirklich verbunden werden muss
Die Verbindung beginnt nicht mit einem neuen System. Sie beginnt mit einer fachlichen Klärung.
Bei einem kritischen Prozessschritt kehren sechs Fragen wieder:
- Welcher Inhalt wird für die Aufgabe oder Entscheidung benötigt?
- In welcher Struktur und in welchem Format muss er vorliegen?
- Welche Quelle ist fachlich führend?
- Mit welchem Prozessschritt, welcher Rolle oder welcher Entscheidung ist der Inhalt verbunden?
- Woran erkennen wir Stand und relevante Änderungen?
- Wer oder was darf den Inhalt wofür verwenden, und wo liegt die Grenze?
Der Unterschied zu sauberem Dokumentenmanagement zeigt sich an einer einfachen Stelle. Ein Dokument kann korrekt versioniert, freigegeben und leicht auffindbar sein. Wenn seine Verwendung im Prozess ungeklärt bleibt, ist es ordentlich verwaltet und als Arbeitskontext trotzdem unvollständig.
Die Eigentümerschaft eines Dokuments reicht deshalb nicht. Jemand muss auch seine Bedeutung im Prozess verantworten.
Nehmen wir als hypothetisches Beispiel eine Angebotsfreigabe. Das Prozessmodell zeigt, welche Prüfung wann stattfindet und wer freigibt. Für einen bestimmten Freigabeschritt könnte zusätzlich eine Rabattregel relevant sein. Dann müsste geklärt sein, welche freigegebene Regel führt, für welche Kundengruppe sie gilt, ob sie als Fließtext oder Entscheidungstabelle benötigt wird, welches System den maßgeblichen Kundenstatus liefert und ab welcher Abweichung die Entscheidung wieder beim Menschen liegt.
Nicht jede dieser Informationen gehört in das Prozessmodell. Genau deshalb braucht es die Verbindung.
Auch die Formatfrage wird dadurch konkreter. Es geht nicht darum, alle Dokumente in Markdown umzuwandeln oder jedes Erfahrungswissen in Felder zu pressen. Die Form muss zur späteren Nutzung passen.
Eine Arbeitsanweisung kann Voraussetzungen, Schritte, Entscheidungskriterien und Ausnahmen klar trennen. Eine Entscheidung sollte mit ihrem Anlass und dem ersetzten Stand verbunden bleiben. Eine Richtlinie braucht einen erkennbaren Geltungsbereich. Beziehungen zu Rollen, Systemen und Prozessen können im Text lesbar bleiben und zusätzlich strukturiert vorliegen.
Technische Standards illustrieren den engeren Teil dieser Aufgabe. Der Model Context Protocol Standard kann Ressourcen mit eindeutigen Kennungen, Beschreibungen und Inhaltstypen transportieren. Optionale Annotationen geben Clients Hinweise, etwa zu Priorität oder Änderungsstand.[2] Sie bestätigen keine fachliche Gültigkeit und modellieren auch nicht, welcher Prozessschritt eine Quelle benötigt. Diese Zuordnung bleibt Organisationsarbeit.
MCP kann also eine technische Verbindung tragen. Context Governance entscheidet, was über diese Verbindung fachlich bereitgestellt wird.
Wo sich der Aufwand lohnt und wo nicht
Man könnte nun versuchen, das gesamte Unternehmen neu zu dokumentieren. Jede Beziehung würde erfasst, jeder Inhalt klassifiziert und jede denkbare Nutzung vorab beschrieben.
Ich halte das für den falschen Weg.
Die Trennung von Prozess und Wissen hat auch Vorteile. Fachbereiche können Inhalte in der Tiefe pflegen, ohne jedes Detail in ein Prozessmodell zu zwingen. Menschen behalten Spielraum für Situationen, die sich nicht sinnvoll standardisieren lassen. Erfahrungswissen entsteht oft erst im konkreten Fall und verliert an Wert, wenn wir es zu früh in starre Kategorien pressen.
Jede zusätzliche Beziehung kostet außerdem Pflege. Eine vollständige Kontextarchitektur kann schneller veralten, als ein Unternehmen sie aktuell halten kann. Im schlechtesten Fall entsteht eine zweite Dokumentationsschicht, die sauber aussieht und im Alltag wieder umgangen wird.
Context Governance lohnt sich deshalb nicht überall gleich. Ich würde dort beginnen, wo die Trennung bereits heute einen erkennbaren Preis hat:
- wiederkehrende Rückfragen und Suchaufwand,
- kritische Entscheidungen mit mehreren möglichen Quellen,
- Übergaben, bei denen Gründe oder Ausnahmen verloren gehen,
- starke Abhängigkeit von einzelnen erfahrenen Personen,
- oder eine geplante AI-Unterstützung beziehungsweise Automatisierung.
Der erste Bereich darf klein sein. Für einen Prozess und einen relevanten Schritt wird geklärt, welches Wissen benötigt wird, wer die Verbindung verantwortet und welches Ereignis eine Aktualisierung auslöst. Fehlt eine fachliche Verantwortung oder ein erkennbarer Änderungsanlass, würde ich die zusätzliche Kontextbeziehung nicht anlegen.
Im Einsatz zeigt sich dann, was wirklich fehlt. Rückfragen machen unklare Inhalte sichtbar. Widersprüche zeigen, welche Quelle nicht eindeutig führt. Wiederkehrende Ausnahmen können ergänzt werden, wenn ihr Nutzen den Pflegeaufwand rechtfertigt.
So wächst der Zusammenhang aus realer Arbeit. Er muss nicht vollständig sein, um wertvoll zu werden.
Die Verantwortung darf nicht zwischen den Rollen verschwinden
Für die Verbindung braucht es wahrscheinlich keine neue Jobbezeichnung. Es braucht eine klare Entscheidung, die heute leicht zwischen Process Owner, Fachbereich, Knowledge Management und IT verloren geht:
Wer entscheidet, welche Quelle für diesen Arbeitsschritt führt, und wer prüft die Auswirkungen einer Änderung?
Process Owner kennen Zweck, Ablauf und Risiken des Prozesses. Fachverantwortliche verstehen die Inhalte. Knowledge- und Content-Verantwortliche unterstützen Struktur und Pflege. IT und Architektur stellen die technischen Wege bereit. Die Verantwortung für die fachliche Verbindung muss trotzdem benannt sein.
Regulatorik setzt dabei wichtige Grenzen. Datenschutz, Berechtigungen, Nachvollziehbarkeit und branchenspezifische Vorgaben gehören zur Gestaltung. Sie reichen als Perspektive aber nicht aus. Ein Inhalt kann regulatorisch sauber zugänglich sein und fachlich trotzdem am falschen Prozessschritt auftauchen.
Guter Kontext überträgt AI auch keine Entscheidungshoheit. Ziele, Nutzungsgrenzen und fachliche Verantwortung bleiben beim Menschen. Die Technik kann Zusammenhänge auffindbar machen und verschiedene Darstellungen für unterschiedliche Aufgaben bereitstellen. Welche Quelle gilt und wann eine Entscheidung übergeben werden muss, entscheidet die Organisation.
Diese Frage prägt auch meine Perspektive auf NEXTHORIZN. Mit Pulse baut NEXTHORIZN aktuell die technische Grundlage, um Prozessarbeit mit strukturiertem Unternehmenskontext zu verknüpfen und diesen Zusammenhang dort verfügbar zu machen, wo Menschen oder AI-Systeme ihn für ihre Aufgabe brauchen. Pulse nimmt der Organisation dabei nicht die fachliche Entscheidung ab, welche Quelle gilt, welche Nutzung zulässig ist oder wann eine Übergabe erforderlich wird. Es schafft die technische Basis, auf der sie diese Verbindungen verlässlich gestalten und bereitstellen kann.
Unternehmen brauchen eine Tür zwischen Prozess und Wissen
Das Bild der zwei Unternehmenswelten lässt mich nicht los. Auf der einen Seite stehen Prozesse, Rollen und Entscheidungen. Auf der anderen Inhalte, Erklärungen und Erfahrungen. Beide Gebäude haben ihren Zweck. Keines sollte im anderen aufgehen.
Für das Unternehmen der Zukunft reicht es aber nicht, beide getrennt weiter auszubauen.
Wenn ein Prozessschritt sichtbar mit den relevanten Quellen, Gründen und Nutzungsgrenzen verbunden ist, verbessert das bereits die heutige Arbeit. Menschen suchen weniger, verstehen Entscheidungen schneller und können Änderungen besser einordnen. AI erhöht den möglichen Nutzen dieser Klarheit, ist aber nicht ihr einziger Grund.
Context Governance ist für mich deshalb die nächste Erweiterung der Process Governance. Sie macht Wissen nicht zum Anhang eines Prozesses. Sie sorgt dafür, dass Arbeit auf den richtigen Inhalt zugreifen kann, wenn er gebraucht wird.
Die beiden Gebäude müssen nicht zu einem verschmelzen. Aber sie brauchen eine verlässliche Tür.
Quellen
[1] Effective context engineering for AI agents
[2] Model Context Protocol: Resources
[3] AI Agents brauchen eine lebende Landkarte des Unternehmens
