Operative Wissensmodelle: Kontext für reale Arbeit nutzbar machen

Was sind operative Wissensmodelle?

Ein Kontextmodell beschreibt dafür zunächst die Personen, Objekte, Tätigkeiten, Regeln und Zustände, durch die eine konkrete Situation fachlich eingeordnet werden kann. Das operative Wissensmodell ergänzt, welches freigegebene Wissen in dieser Situation genutzt werden darf.

Der Begriff bezeichnet keinen einzelnen technischen Standard. Er beschreibt eine Funktion innerhalb der Systemarchitektur: Fachbegriffe, Objektbeziehungen, Zustände, Regeln und Herkunftsinformationen werden so verbunden, dass sie während der Arbeit ausgewertet werden können. Ein Modell kann beispielsweise ausdrücken, dass eine Materialcharge zu einem Produkt gehört, für einen Verarbeitungsschritt freigegeben sein muss und nur unter einer bestimmten SOP-Version verwendet werden darf.

„Operativ“ bedeutet dabei nicht automatisch oder autonom. Das Modell stellt einen belastbaren Kontext bereit. Ob daraus ein Hinweis, eine Prüfung, eine Sperre, ein Vorschlag oder eine menschliche Entscheidung folgt, muss die jeweilige Anwendung ausdrücklich festlegen.

Eine anstehende Prüfung braucht Regel, Eingaben und eine erlaubte Folge

In einem fiktiven Verarbeitungsschritt soll ein Temperaturwert bewertet werden. Aufgabe A-17 gehört zu Produktvariante V-2. Für diese Aufgabe ist Regel R-7 aus einer bestimmten freigegebenen SOP-Fassung maßgeblich. Ein neuerer Bearbeitungsstand ist noch nicht aktiviert und wird daher nicht allein wegen seiner Aktualität verwendet.

Zunächst werden Messgegenstand, Einheit und erforderlicher Gerätestatus geprüft. Fehlt der Gerätestatus, liefert die Anwendung keinen scheinbar vollständigen Bereichsentscheid. Im angenommenen Ablauf fordert sie eine Klärung an. Diese Reaktion ist eine ausdrücklich festgelegte Anwendungsregel.

Sind die Voraussetzungen erfüllt, kann der Wert gegen R-7 bewertet werden. Ein Ergebnis außerhalb des Bereichs führt im Beispiel zu einer Prüfaufgabe für die zuständige Rolle. Es erteilt weder automatisch eine Freigabe noch bestimmt es bereits die Fehlerursache.

Beobachtung, Regelbewertung und spätere Entscheidung bleiben getrennt. So lässt sich nach einer Änderung von R-7 noch erklären, welche Aussage damals unter welcher Regel entstanden ist.

Die passende Fassung auswählen und ihren Bezug erhalten

Für A-17 muss die Anwendung die maßgebliche SOP-Fassung und Regel R-7 eindeutig zuordnen. Eine Dokumentnummer ohne Fassung ist dafür zu unbestimmt. Bei laufenden Aufgaben braucht ein Versionswechsel einen ausdrücklich festgelegten Übergang.

Die Herkunft der Regel bleibt ebenfalls relevant. Data Provenance kann den Bezug zur Quelle, ihrer Übertragung und den beteiligten Verantwortlichen beschreiben; PROV-O stellt dafür ein formales Vokabular bereit.[4] Diese Herkunft entscheidet nicht automatisch, ob die Regel für die aktuelle Aufgabe gilt.

Ein Prüfbefund benötigt eine ausdrücklich festgelegte Wirkung

Eine Strukturprüfung kann feststellen, dass der Gerätestatus fehlt. SHACL ist eine Möglichkeit, solche Bedingungen für RDF-Daten zu formulieren.[3] Das Ergebnis beantwortet zunächst die formulierte Datenfrage.

Ob die Anwendung daraus eine Rückfrage, eine Sperre oder eine Prüfaufgabe erzeugt, wird zusätzlich festgelegt. Im Beispiel ist die Klärung des Gerätestatus Voraussetzung für die weitere Bewertung. Diese Wirkung darf nicht versteckt aus dem Vokabular entstehen.

Auch eine vollständig vorliegende Eingabe kann sachlich falsch sein. Die Anwendungsregel muss daher mit geeigneter Erfassung und fachlicher Prüfung verbunden bleiben; ein bestandener Strukturtest ersetzt diese nicht.

Beobachtung und spätere Bewertung bleiben getrennt

Der Temperaturwert gehört zur Erfassung in A-17. Die Aussage „außerhalb des Bereichs“ entsteht erst durch seine Bewertung unter R-7. Wird später eine andere Grenze verwendet, ändert das nicht rückwirkend die ursprüngliche Beobachtung.

Eine erneute Auswertung benötigt deshalb einen eigenen Bezug zu den verwendeten Daten und der neuen Regel. Historische Bewertung und aktuelle Neueinordnung dürfen nebeneinander bestehen, müssen aber unterscheidbar sein.

Vom statischen Wissensbestand zur laufenden Ausführung

Ein operatives Wissensmodell entfaltet seinen Nutzen an konkreten Arbeitspunkten. Vor einer Aufgabe kann es die gültige SOP-Version, erforderliche Qualifikationen und freigegebene Materialien bestimmen. Während der Ausführung kann es Pflichtangaben, Einheiten und zulässige Wertebereiche prüfen. Nach einem Ergebnis kann es die zuständige Prüfung, mögliche Folgeaufgaben oder betroffene Objekte ermitteln.

Dabei entsteht ein Kreislauf:

1. Der aktuelle Prozesskontext bestimmt, welches Wissen relevant ist.
2. Das Modell stellt Begriffe, Beziehungen, Regeln und gültige Versionen bereit.
3. Menschen oder Systeme führen eine Aufgabe aus und treffen Entscheidungen.
4. Die Ausführung erzeugt neue Zustände, Ereignisse und Nachweise.
5. Diese Ergebnisse erweitern den Kontext für nachfolgende Aufgaben.

Dieser Kreislauf ist ein Kern von Process Intelligence: Betriebsdaten werden nicht nur nachträglich analysiert. Überprüfte Zusammenhänge können wieder in die Ausführung zurückgeführt werden, ohne die Entscheidungshoheit und Verantwortlichkeit der beteiligten Menschen zu verdecken.

Ein operatives Modell darf dabei nicht zu einer unüberschaubaren Gesamttheorie des Betriebs werden. Es sollte von konkreten Entscheidungssituationen ausgehen. Welche Information benötigt die ausführende Person jetzt? Welche Beziehung muss das System prüfen? Welche Herkunft muss später nachvollziehbar sein? Von diesen Fragen aus wächst das Modell kontrolliert entlang realer Anwendungsfälle.

Fünf Bausteine eines operativen Wissensmodells

Für die hier beschriebene operative Nutzung betrachten wir fünf zusammenwirkende Ebenen. Sie dienen als Gliederung dieses Ansatzes und bilden keinen universellen Mindestkatalog:

RDF kann die benötigten Aussagen darstellen; OWL kann ihre formalen Begriffe und Schlussfolgerungen beschreiben.[1][2] OWL-Domain- und Range-Aussagen sind dabei keine automatische Eingabesicherung. Datenprüfung und die erlaubte Wirkung in der Anwendung werden gesondert festgelegt.

Wissensmodell, Knowledge Graph und Workflow sind nicht dasselbe

Ein Datenmodell legt fest, welche Felder und Strukturen ein System speichert. Ein Wissensmodell beschreibt darüber hinaus die fachliche Bedeutung von Objekten, Eigenschaften und Beziehungen. Es kann ausdrücken, dass „verwendet Material“ eine andere Beziehung ist als „erzeugt Zwischenprodukt“ und dass beide Beziehungen unterschiedliche Voraussetzungen besitzen.

Knowledge Graphs sind eine mögliche Repräsentationsform für solches Wissen. Sie verbinden identifizierte Entitäten und benannte Beziehungen zu einem auswertbaren Netz. Ein operatives Wissensmodell kann auf einem Knowledge Graph aufbauen, muss aber zusätzlich klären, wann Aussagen gelten, wie sie geprüft werden und in welchem Ausführungskontext sie benötigt werden. Der Graph ist die Wissensstruktur; die operative Nutzung ist ihre Verbindung mit laufenden Aufgaben und Entscheidungen.

Ontologien können Klassen, Eigenschaften und allgemeine fachliche Aussagen formal beschreiben. Ein operatives Wissensmodell nutzt solche Bedeutungsebenen, verbindet sie aber zusätzlich mit konkreten Zuständen, Gültigkeiten und Wirkungspunkten in der Prozessausführung.

Auch Workflow-Modelle erfüllen eine andere Aufgabe. Sie beschreiben Aktivitäten, Übergänge, Ereignisse und Entscheidungspunkte eines vorgesehenen Ablaufs. Das Wissensmodell liefert den fachlichen Kontext, den ein Workflow an diesen Punkten benötigt. Der Workflow kann festlegen, dass nach einer Messung eine Prüfung folgt. Das Wissensmodell beschreibt, welche Grenzwerte für das betroffene Produkt und die aktuelle SOP-Version gelten und welche Freigaberolle zuständig ist.

Eine Wissensdatenbank wiederum kann Dokumente und Antworten auffindbar machen, ohne ihre Inhalte formal miteinander zu verbinden. Ein operatives Wissensmodell beginnt dort, wo das System nicht nur Text findet, sondern die Bedeutung einer Information auf den konkreten Vorgang beziehen kann.

Was operative Wissensmodelle nicht automatisch leisten

• Ein Modell erzeugt keine richtigen Daten. Es kann Struktur und Beziehungen prüfen, aber fehlerhafte Beobachtungen nicht ohne weitere Evidenz in Wahrheit verwandeln.
• Mehr Semantik bedeutet nicht automatisch mehr Nutzen. Begriffe und Regeln ohne konkrete Anwendung erhöhen Pflegeaufwand und Interpretationsrisiko.
• Ableitungen benötigen erklärbare Grundlagen. Nutzer müssen erkennen können, aus welchen Aussagen und Regeln eine Empfehlung oder Prüfung hervorgegangen ist.

Wissen wird an einer bestimmten Stelle wirksam

A-17 zeigt die entscheidende Verbindung: Eine identifizierte Regel trifft auf bestimmte Eingaben und eine ausdrücklich erlaubte Reaktion. Fehlt eine Voraussetzung, muss auch dieser Fall einen verständlichen Weg besitzen.

Der Nutzen operativer Wissensmodelle lässt sich deshalb an solchen Arbeitssituationen prüfen. Eine Sammlung von Begriffen genügt nicht; nachvollziehbar werden müssen die Auswahl des Wissens, seine Bewertung und die tatsächliche Folge im Ablauf.