Versionierte Wissensmodelle: Wie Änderungen betrieblichen Wissens nachvollziehbar bleiben

Welche Modellfassung war tatsächlich maßgeblich?

Für einen betrieblichen Vorgang muss erkennbar sein, welche konkrete Modellfassung verwendet wurde. Die zuletzt gespeicherte Datei beantwortet diese Frage nicht zuverlässig.

Bei Process Intelligence ist dieser Bezug relevant, sobald frühere Abläufe unter ihren damaligen Bedingungen ausgewertet werden. Eine spätere Regeländerung darf nicht unbemerkt zum ursprünglichen Maßstab werden. Modellidentität, Versionsidentität und Einsatzbereich sind deshalb getrennt festzuhalten.

Eine neue Regel gilt an zwei Standorten zu verschiedenen Zeiten

In einem fiktiven Modell M-Trocknung legt Fassung 2.2 fest, welche Temperaturbedingungen für eine Produktvariante gelten. Fassung 2.3 präzisiert eine Grenze und ergänzt eine Prüfung. Sie wird am 1. Juni veröffentlicht, am Standort Nord zum 1. Juli aktiviert und am Standort Süd erst zum 15. Juli. Die Daten sind Teil dieses Beispiels.

Eine am 8. Juli neu gestartete Aufgabe kann daher je nach Standort einer anderen Fassung zugeordnet sein. Die Versionsnummer allein genügt nicht: Die Zuordnung benötigt zusätzlich Produkt, Standort und den für den Prozess festgelegten Bezugszeitpunkt.

Für eine vor dem 1. Juli in Nord begonnene und danach weiterbearbeitete Charge ist eine eigene Übergangsregel erforderlich. Sie kann die bisherige Fassung beibehalten oder eine geprüfte Umstellung vorsehen. Bei einer Umstellung bleiben der ursprüngliche Bezug, der Wechsel und seine Auswirkungen auf bereits erledigte Schritte nachvollziehbar. Ein Aktivierungsdatum entscheidet das nicht allein.

In Knowledge Graphs lassen sich diese Fassungen und Zuordnungen als eigene Objekte und Beziehungen darstellen. Welche Zuordnung zulässig ist, muss das fachliche Regelwerk festlegen.

Stabile Identität und konkrete Version sind zwei verschiedene Dinge

Ein Wissensmodell benötigt eine stabile Identität, unter der es als zusammengehörige Modellreihe bekannt bleibt. Zusätzlich braucht jede veröffentlichte Fassung eine eigene Versionsidentität. Die stabile Identität beantwortet die Frage „Welches Modell ist gemeint?“. Die Versionsidentität beantwortet „Welche konkrete Fassung dieses Modells wurde verwendet?“.

OWL 2 unterscheidet entsprechend zwischen einer Ontologie-IRI und einer optionalen Versions-IRI. Die Ontologie-IRI bezeichnet die Modellreihe; eine eigene Versions-IRI identifiziert eine bestimmte Fassung. Frühere Versionen sollen über ihre versionsspezifische Adresse erreichbar bleiben, während die allgemeine Adresse auf die aktuelle Fassung verweisen kann.^[1]

Dasselbe Prinzip lässt sich auch außerhalb einer OWL-Ontologie anwenden. Eine Modellversion sollte eine unverwechselbare Kennung besitzen und nach ihrer Freigabe nicht stillschweigend überschrieben werden. Zur Kennung gehören mindestens Veröffentlichungsdatum, Status und Vorgängerversion. Eine menschenlesbare Nummer wie 2.3 kann hilfreich sein, genügt allein aber nicht, wenn verschiedene Umgebungen oder Teilmodelle dieselbe Nummer verwenden könnten.

Eine stabile Identität bedeutet nicht, dass jeder einzelne Begriff für immer unverändert bleiben muss. Sie sorgt vielmehr dafür, dass Änderungen einer gemeinsamen Entwicklungslinie zugeordnet werden können. Wird ein fachlich völlig anderes Modell geschaffen, kann dagegen eine neue Modellidentität angemessener sein als die Fortsetzung einer bestehenden Versionsreihe.

Veröffentlichungszeit und fachliche Gültigkeit getrennt erfassen

Eine neue Modellversion kann am 1. Juni veröffentlicht werden, aber erst ab dem 1. Juli für einen bestimmten Standort gelten. Umgekehrt kann eine Korrektur rückwirkend den fachlichen Bezugsrahmen einer bereits abgeschlossenen Untersuchung präzisieren, ohne historische Aufzeichnungen zu verändern. Daher benötigt die Versionierung mindestens zwei zeitliche Perspektiven:

• Systemzeit: Wann wurde eine Fassung angelegt, geprüft, veröffentlicht oder technisch ersetzt?
• Gültigkeitszeit: Für welchen Zeitraum, Prozess, Standort, Produkttyp oder Anwendungsfall ist die Fassung fachlich maßgeblich?

Das Kontextmodell beschreibt, welche Bedingungen eine konkrete Betriebssituation fachlich einordnen. Die Modellversion ergänzt dazu den zeitlich eindeutigen Referenzpunkt. Ein Ereignis sollte nicht lediglich mit „dem aktuellen Modell“ verbunden sein, sondern mit der Version, die für diesen Vorgang tatsächlich freigegeben war.

Bei parallel gültigen Fassungen reicht eine lineare Folge von Version 1 zu Version 2 nicht aus. Unterschiedliche Standorte können eine neue Regel gestaffelt einführen, Produkte können verschiedenen Spezifikationen unterliegen und ein Pilotbereich kann eine Erweiterung früher verwenden. Der Geltungsbereich muss daher als explizite Bedingung behandelt werden. „Aktuell“ ist ohne Angabe des relevanten Kontexts keine eindeutige fachliche Aussage.

Abhängigkeiten zwischen Modellen müssen mitversioniert werden

Ein betriebliches Wissensmodell steht selten allein. Es kann Begriffe aus einer Ontologie übernehmen, Einheiten aus einem Referenzmodell verwenden, Prüfbedingungen aus einem Regelwerk importieren oder Zuordnungen zu externen Klassifikationen enthalten. Verändert sich eine solche Abhängigkeit, kann sich die Bedeutung des eigenen Modells verändern, obwohl dessen lokale Dateien unverändert geblieben sind.

Eine freigegebene Version sollte deshalb festhalten, auf welche konkreten Versionen ihrer Abhängigkeiten sie verweist. Ein offener Verweis auf „jeweils aktuell“ erschwert die Reproduzierbarkeit, weil derselbe historische Vorgang bei einer späteren Auswertung einen anderen Bedeutungsrahmen erhalten könnte. OWL 2 beschreibt Importe als Bestandteil einer Ontologie und betrachtet auch direkt importierte Ontologien bei den strukturellen Anforderungen.^[1]

Zu den Abhängigkeiten gehören außerdem Mappings zwischen Begriffssystemen. Wird beispielsweise ein interner Materialstatus einem Begriff eines Partnersystems zugeordnet, muss die Zuordnung eine eigene Version und einen Geltungsbereich besitzen. Eine geänderte Zuordnung darf nicht unbemerkt so wirken, als hätten frühere Daten schon immer dieselbe externe Bedeutung gehabt.

Nicht jede Änderung besitzt dieselbe fachliche Tragweite

Eine reine Schreibkorrektur unterscheidet sich grundlegend von einer neuen Pflichtbeziehung oder einer geänderten Entscheidungsregel. Versionierte Wissensmodelle sollten Änderungen deshalb nicht nur auflisten, sondern fachlich klassifizieren. Eine praktikable Einteilung unterscheidet mindestens:

• redaktionelle Änderungen: verständlichere Bezeichnungen, ergänzte Erläuterungen oder korrigierte Tippfehler ohne veränderte fachliche Aussage;
• additive Änderungen: neue Begriffe, Beziehungen oder Regeln, die bestehende zulässige Aussagen nicht einschränken;
• präzisierende Änderungen: enger gefasste Definitionen, zusätzliche Bedingungen oder genauer bestimmte Geltungsbereiche;
• inkompatible Änderungen: entfernte Begriffe, geänderte Bedeutungen oder Regeln, durch die bisher gültige Daten und Schlussfolgerungen anders behandelt werden;
• Stilllegungen: als veraltet gekennzeichnete Elemente, die für historische Vorgänge erhalten bleiben, aber nicht mehr neu verwendet werden sollen.

Die Forschung zur Ontologieentwicklung weist darauf hin, dass semantische Modelle nicht wie gewöhnliche Datenbankschemata behandelt werden können. Explizite Bedeutungen, logische Abhängigkeiten und unterschiedliche Nutzungskontexte machen Änderungen an Ontologien zu einem eigenen Problemfeld.^[2] Schon eine scheinbar kleine Begriffsänderung kann Abfragen, Regeln, Zuordnungen oder abgeleitete Aussagen beeinflussen.

Kompatibilität sollte deshalb nicht allein aus einer Versionsnummer abgeleitet werden. Auch Bezeichnungen wie „rückwärtskompatibel“ sind zunächst dokumentierte Aussagen der Modellverantwortlichen. Ob vorhandene Daten, Abfragen und Anwendungen tatsächlich weiterhin funktionieren, muss anhand der betroffenen Nutzungsszenarien geprüft werden.

Ein Änderungsnachweis erklärt mehr als ein technischer Vergleich

Ein automatischer Vergleich kann zeigen, welche Elemente hinzugefügt, entfernt oder umbenannt wurden. Für eine kontrollierte Wissensfortschreibung reicht diese Differenzliste nicht aus. Erforderlich ist zusätzlich die fachliche Begründung: Welches Problem wurde beobachtet? Welche Quelle oder Erfahrung rechtfertigt die Änderung? Welche Prozesse und Entscheidungen können betroffen sein? Wer hat sie geprüft und freigegeben?

W3C PROV-O stellt unter anderem Beziehungen für Ableitung, Revision und Verantwortlichkeit bereit. Eine Revision kann als neue Entität beschrieben werden, die aus einer vorherigen Entität hervorgegangen ist; zugleich lassen sich beteiligte Aktivitäten und verantwortliche Akteure ausdrücken.^[3] Für ein Wissensmodell kann dadurch beispielsweise verbunden bleiben, dass Version 2.3 aus Version 2.2 hervorging, durch welche Änderungsaktivität sie entstand und welche Person oder Organisation dafür verantwortlich war.

Der Nachweis sollte auf Ebene eines freigegebenen Änderungspakets erfolgen. Einzelne Bearbeitungsschritte während der Modellierung können zahlreich und technisch geprägt sein. Für die betriebliche Prüfung ist entscheidend, welche fachlich zusammengehörenden Änderungen gemeinsam bewertet wurden und welche erwarteten Auswirkungen die Freigabe berücksichtigt hat.

Ein Prüfbericht gehört zu einem bestimmten Versionsverbund

Ein Bericht zur Fassung 2.3 muss erkennen lassen, welche Modell-, Import-, Shape- und Testdatenfassungen verwendet wurden. Sonst bleibt unklar, ob eine spätere Wiederholung noch denselben Gegenstand prüft. SHACL unterscheidet Datengraph und Shapes-Graph; beide gehören zum nachvollziehbaren Prüfkontext.[4]

Bei einer geänderten Bedingung können dieselben Daten unter zwei Shape-Versionen unterschiedliche Ergebnisse liefern. Ein solcher Unterschied ist zunächst anhand der jeweiligen Anforderung zu erklären. Die weitergehende Frage ist die Validierung des Wissensmodells: Welche Prüfungen tragen eine Einsatzentscheidung?

Bearbeitungsstand, Kandidat und freigegebene Fassung klar trennen

Während der Modellpflege entstehen Zwischenstände. Würde jeder davon unmittelbar in operative Prozesse gelangen, könnten laufende Vorgänge von unvollständigen oder ungeprüften Änderungen beeinflusst werden. Ein kontrollierter Lebenszyklus unterscheidet daher wenigstens Entwurf, Prüfkandidat, freigegebene Version und außer Kraft gesetzte Version.

Für die Freigabe sollten Verantwortlichkeiten, Prüfumfang und Entscheidung dokumentiert sein. Je nach Tragweite können fachliche Modellverantwortliche, Prozessverantwortliche, Qualitätssicherung und technische Betreiber beteiligt sein. Eine additive Erläuterung benötigt möglicherweise weniger Prüfung als eine Regel, die Aufgaben sperrt oder eine Freigabe beeinflusst.

Operative Wissensmodelle verbinden Wissen mit realen Aufgaben, Zuständen und Entscheidungen. Gerade deshalb darf eine neue Fassung nicht allein aufgrund ihrer technischen Verfügbarkeit wirksam werden. Die operative Aktivierung ist eine eigene kontrollierte Handlung. Sie legt fest, ab wann und für welchen Bereich die freigegebene Modellversion verwendet wird.

Eine Rücknahme sollte ebenfalls vorbereitet sein. Sie bedeutet nicht, die fehlerhafte Fassung zu löschen. Stattdessen wird ihre weitere Anwendung beendet, eine andere Version aktiviert und dokumentiert, welche Vorgänge während des betroffenen Zeitraums mit der zurückgenommenen Fassung verarbeitet wurden.

Versionierung, Historie und Provenienz abgrenzen

• Versionsverwaltung unterscheidet freigegebene Fassungen eines Modells und ihre Entwicklungslinie.
• Änderungshistorie protokolliert, welche Elemente wann bearbeitet wurden; sie enthält nicht automatisch deren fachliche Bedeutung.
• Provenienz beschreibt Herkunft, Ableitung, beteiligte Aktivitäten und Verantwortlichkeit einer Modellfassung.
• Gültigkeitsmanagement bestimmt, für welchen Zeitraum und Kontext eine Version anzuwenden ist.
• Migration überführt Daten oder Anwendungen in eine neue Struktur; historische Daten müssen dadurch nicht rückwirkend ihre ursprüngliche Bedeutung verlieren.
• Ontologien definieren Begriffe und Beziehungen formal. Ontologien können versioniert werden, doch auch weniger formale Wissensmodelle benötigen kontrollierte Fassungen.^[5]

Diese Aufgaben ergänzen sich. Eine Versionsnummer ohne Änderungsnachweis erklärt nicht, was sich verändert hat. Eine vollständige Historie ohne Gültigkeitsregeln erklärt nicht, welche Fassung in einer Situation anzuwenden war. Und eine Migration ersetzt nicht die dauerhafte Referenz auf den ursprünglichen Bedeutungsrahmen.

Wissensmodelle validieren beschreibt ergänzend, wie eine eindeutig identifizierte Fassung anhand von Strukturregeln, fachlichen Testfällen und ihrem vorgesehenen Geltungsbereich geprüft wird.

Wenn mehrere Fassungen zugleich passen

Ein ungelöster Fall entsteht, wenn zwei aktive Fassungen dieselbe Produkt- und Standortkombination beanspruchen. Die höhere Versionsnummer ist dann keine fachlich begründete Auswahlregel. Das Modellmanagement muss solche Überschneidungen erkennen und eine Entscheidung oder ausdrücklich definierte Priorität vorsehen.

Auch eine Rücknahme braucht einen klaren Anschluss: Welche Fassung gilt für neue Vorgänge, und welche bereits bearbeiteten Fälle müssen untersucht werden? Das Wiederaktivieren einer älteren Version macht die zwischenzeitliche Verwendung nicht ungeschehen.

Ein früherer Vorgang braucht seinen früheren Bezug

Die Frage nach „der aktuellen Version“ reicht im Standortbeispiel nicht aus. Erst Fassung, Geltungsbereich und Übergangsregel erklären, warum eine bestimmte Aufgabe unter 2.2 oder 2.3 bearbeitet wurde.

Ein brauchbarer Versionsnachweis führt daher von der konkreten Ausführung zur identifizierten Fassung und ihren Abhängigkeiten. Für die Wiederverwendung bewerteter Erfahrungen kommt ein weiterer Bezug hinzu: Das Prozessgedächtnis erhält frühere Verläufe mit ihrer fachlichen Einordnung.