Content uploaded by Nane Kratzke
Author content
All content in this area was uploaded by Nane Kratzke on Oct 10, 2016
Content may be subject to copyright.
Informatik Forsch. Entw. (2006) 20: 196–208
DOI 10.1007/s00450-005-0210-z
REGULÄRE BEITRÄGE
Nane Kratzke
Modell-basierte Identifikation interorganisationaler Wissensflüsse
Eingegangen am 22. Februar 2005 / Angenommen am 8. August 2005 / Online publiziert am 5. Oktober 2005
© Springer-Verlag 2005
Zusammenfassung Im interorganisationalenWissensmana-
gement müssen Organisationen zum einen Kernkompetenz
relevantes Wissen schützen, um überhaupt attraktiv für Ko-
operationen zu sein. Anderseits müssen Organisationen in-
nerhalb von Partnerschaften Wissen teilen, um wertvoll für
eine Kooperation zu sein. Daher muss interorganisationales
Wissensmanagement gleichzeitig den Schutz und die Tei-
lung von Wissen berücksichtigen. Insbesondere der Schutz
von Wissen ist im intraorganisationalen Wissensmanagement
nicht sehr verbreitet und auch nicht sehr sinnvoll. Dies unter-
scheidet intra- vom interorganisationalem Wissensmanage-
ment. Dieser Artikel zeigt, wie in einem interorganisationa-
len Umfeld Modell-basierte Methoden dazu genützt werden
können, um auf einer Wissensebene interoperabel zu werden.
Konzeptionelle Probleme bei der Entwicklung von Know-
ledge Management GRIDs werden systematisch aus einem
Modell-basierten Blickwinkel betrachtet.
Schlüsselwörter Semantic Web ·Wissensmanagement ·
KMDL ·Modelle ·Interorganisational
Abstract In interorganizational knowledge management or-
ganizations have to preserve knowledge from their partners to
guard their core competenciesmaking them attractive for co-
operations. On the other hand organizations have to share their
knowledge to become worthfull members of a cooperation.
Therefore interorganizational knowledge managementhas to
handle the sharing as well as the preserving of knowledge si-
multaneously. In intraorganizational knowledge management
aspects of preserving knowledge is not very common and not
very usefull at all. This differentiates intra- from interorgan-
isational knowledge management. This article presents how
model-based methodologies can be used to become interop-
erable from a knowledge point of view. Conceptional prob-
lems known from knowledge management GRIDs are anal-
ysed systematicallyfrom a model based point of view.
N. Kratzke
Universität Potsdam, Lehrstuhl für Wirtschaftsinformatik
und EGovernment, Potsdam, Deutschland
E-mail: nane.kratzke@gmx.de
Keywords Semantic web ·Knowledge management ·
KMDL ·Models ·Interorganisational
CR Subject Classification I.6.1 ·I.6.4 ·I.6.5 ·K.6.1 ·
K.6.4 ·K.7.2 ·J.1 ·J.4
1 Einleitung
Für das interorganisationale Wissensmanagement ist eine
Kultur des gegenseitigen Verständnisses und Vertrauens un-
erlässlich, wie Howaldt et al. [16] betonen. Um einen interor-
ganisationalen Wissenstransfer effektiv zu gestalten, der die-
ses gegenseitige Verständnis und Vertrauen berücksichtigt,
sind sogenannte Aktivitätssysteme hil freich, wie sie Böhm [5]
beschreibt. Beispiele für interorganisationale Aktivitätssy-
steme sind interorganisationale Projekte oder Prozesse
(vgl. [5]). Insbesondere im Prozessmanagement sind Mo-
delle hilfreich, um ein gemeinsames Problemverständnis zu
erzeugen. Dieses gemeinsame Problemverständnis dient zum
einen dem Aufbau von Vertrauen, aber auch der gemeinsa-
men Gestaltung interorganisationaler Zusammenarbeit. Re-
mus und Lehner [26, 27], sowie Abecker et al. [1] haben ge-
zeigt, dass Prozessmanagement hilfreich für das Wissensma-
nagement ist, da es die Integration von Wissensmanagement-
resultaten1in wissensintensive Geschäftsprozesse2konzept-
ionalisiert. Daher präsentiert dieser Artikel einen auf Ge-
schäftsprozessen beruhenden, Modell-basierten Ansatz, um
den interorgansationalen Wissens- und Kompetenztransfer
zu systematisieren.
Picot et al. weisen darauf hin, dass Organisationen durch
”verschiedene Faktoren, wie z.B. räumliche Entfernungen,
Raum- und Zeitknappheit, Wissensmängel, Kapazitätseng-
pässe und mangelnde Flexibilität“ (vgl. [22, S. 6]) begrenzt
werden. In diesem Zusammenhang kann zwischen Modulari-
sierung, Bildung von Kooperationen bzw. Netzwerken, sowie
virtuellen Organisationen als Auslöser interorganisationalen
1z.B. die Erzeugung von Ingenieurkompetenz
2z.B. die Entwicklung eines Schiffes
Modell-basierte Identifikation interorganisationaler Wissensflüsse 197
Wissensmanagements differenziert werden, die die se begren-
zenden Faktoren kompensieren sollen.
Unter Modularisierung wird eine Restrukturierung der
Unternehmensorganisation in relativ kleine, überschaubare
Einheiten(Module)mitdezentraler Entscheidungskompetenz
und Ergebnisverantwortung verstanden (vgl. [22, S. 230]).
Mittel- bis langfristig angelegte und vertraglich geregel-
te Verbindungen mit externen Partnern, mit dem Ziel diese
in die Erfüllung eigener Aufgaben eng mit einzubeziehen,
werden als Kooperationen bezeichnet (vgl. [22, S. 304]).
Virtuelle Organisationen werden als eine Kooperation
von rechtlich unabhängigen Firmen oder Einzelpersonen, die
ihre Kernkompetenzen in vertikaler oder horizontaler Wei-
se – ohne zentrale Koordinations- und Kontrollfunktiuon –
miteinander vernetzen, gesehen (vgl. [29, S. 369]). Hierbei
ist anzumerken, dass sich bislang in der Literatur noch keine
abschließende Definition durchsetzen konnte. Jedoch werden
immer wieder Eigenschaften, wie die lose Bindungen räum-
lich verteilter Einzelorganisationen (vgl. [9, S. 150]) und
die dezentrale Kommunikation und Kooperation (vgl. [2])
betont. Virtuelle Organisationen stellen demnach ein dyna-
misches Netzwerk modularer Einheiten dar. Sie verbinden
die Reorganisationsformen der Modularisierung und Netz-
werkbildung mittels der aufgabenbezogenen, dynamischen
Rekonfiguration und beschreiben von allen Reorganisations-
formen den komplexesten Anwendungsfall des interorgani-
sationalen Wissensmanagements.
Kooperierende wissensbasierte Organisationen sind da-
bei in einem Dilemma. Einerseits müssen sie Wissen inner-
halb einer Kooperation teilen, um ein produktives Element
dieser Kooperation zu sein (und Mitglied dieser Koopera-
tion zu bleiben). Anderseits ist es notwendig, Kernkompe-
tenz relevantes Wissen zu schützen, um weiterhin attraktiv
für Kooperationen zu bleiben und nicht durch Partner ko-
pierbar zu werden. Dies unterscheidet interorganisationales
von intraorganisationalem Wissensmanagement, in dem der
Aspekt des Wissensschutzes nicht sehr verbreitet oder nütz-
lich ist.
Unterschieden werden im Wissensmanagement Daten,
Informationen und Wissen (vgl. z.B. Probst et al. [25], Daven-
port und Prusak [8]). Der Übergang von Daten zu Informatio-
nen und Wissen ist dabei fließend. Anerkannt ist die Tatsache,
dass Wissen Personen-gebunden ist und zur (wertschöpfen-
den) Nutzung von Informationen Kontexte notwendig sind.
Informationen basieren demnach auf Daten3und Wissen auf
von Personen genutzten und (wertschöpfend) angewandten
Informationen4. Dieser Kontext beruht auf den individuel-
len Erfahrungen und Erlebnissen einer Person und wird im
Sprachgebrauch Senges als Personen-gebundene mentale
Modelle bezeichnet(vgl. Senge [28]). Diese Betrachtung en-
det dabei auf der Ebene der Person. Organisationen bestehen
jedoch aus mehreren Personen und haben das Problem zu lö-
sen, wie die Koordination arbeitsteiliger Aufgaben effektiv
zu organisieren ist (vgl. hierzu auch Hentze und Brose [15],
3von Automaten nach programmierbaren Algorithmen bearbeitbare
”Zahlenkolonnen“
4von Personen in einem Kontext interpretierte Daten
Probst [24] oder Kieser und Kubicek [17]). In diesem Zu-
sammenhang sind in den letzten Jahren prozessorientierte
Methoden in den Fokus der Organisationsgestaltung gerückt
(vgl. Prahalad und Hamel [23], Becker [3] oder Remus [26]).
Auf dieser Ebene kann man von Kompetenz (vgl. North [21])
oder Fähigkeit einer Organisation sprechen. Interorganisatio-
nales Wissensmanagement – wenn man es nicht auf interor-
ganisationale Datenverarbeitung oder Informationssysteme
beschränken will – muss sich also mit dem interorganisatio-
nalen Transfer von Wissen und Kompetenz befassen.
Wenige Methodologien existieren bislang, die interor-
ganisationales Wissensmanagement mittels Modell-basierter
Ansätze systematisch beleuchtet haben. Der Begriff GRID
wird vermehrt im Zusammenhang mit Wissen, Wissenstrans-
fer und Wissensmanagement genannt, wie die Planung eines
sogenannten ”E-Science GRIDs“ des Bundesministeriums
für Forschung und Entwicklung belegt5, das bereits nicht
nur in der rein wissenschaftlich, sondern auch praktisch aus-
gerichteten Fachpresse reflektiert wird (vgl. Harms [14]). Es
erscheint reizvoll, Wissen wie Strom oder Rechenleistung
bei Bedarf aus einem GRID beziehen zu können, leider ist
die ”Ressource“ Wissen komplex und schwer transferierbar,
wie in der Literatur mehr als einmal belegt werden konnte.
Der Ansatz Wissen auf Informationen zu reduzieren, greift
im Allgemeinen zu kurz. Wissen als Wissen kann nur in Per-
sonen ”gespeichert“ werden. Personen können ihr Wissen
unter Kontextverlust (d.h. der Gefahr von Fehlinterpretatio-
nen) in Informationen externalisieren, die in Form elektro-
nischer Artfakte geeignet sind, einfach mittels Informations-
systemen verbreitet zu werden. Darüber hinaus existiert je-
doch auch so etwas wie überpersonelles Wissen. So ist die
Bundeswehr kompetent bei der Durchführung internationa-
ler militärischer Einsätze, EADS hingegen bei der Entwick-
lung von komplexen Waffensystemen. EADS ist daher nicht
in der Lage eine internationale Mission durchzuführen und
die Bundeswehr nicht das Führungssystem einer Fregatte zu
entwickeln. Beiden Organisationen fehlen Wissen und Er-
fahrung, das jeweils andere Produkt bzw. Dienstleistung zu
erzeugen. Daher existiert auf der Ebene von Organisationen
auch noch Wissen in einer anderen Form, welches oft als
Kompetenz bezeichnet wird. Beide Organisationen können
jedoch voneinander lernen. Niemand (im nationalen Um-
feld) weiß besser, was eine moderne Fregatte in der aktu-
ellen sicherheitspolitischen Lage können sollte und worauf
verzichtet werden kann. Insofern ist EADS gut daran bera-
ten, die Bundeswehr in die Entwicklung eines Führungssy-
stems einer Fregatte mit einzubeziehen. Und dies geschieht
ja auch, wie noch in einem Beispiel gezeigt werden wird.
Auch EADS profitiert von dieser Zusammenarbeit, da sie
Systeme auf dem Weltmarkt anbieten kann, die auf neuesten
militärischen Erfahrungen und Erkenntnissen beruhen. Dies
wiederum bedeutet Wettbewerbsvorteile gegenüber Konkur-
renten. Aus diesem Grund sind im Rüstungsexport nationale
Kundenreferenzen so wichtig6.
5vgl. http://www.bmbf.de/foerderungen/3179.php
6Kaum eine Nation der Welt, wird den Eurofighter von EADS kau-
fen, wenn Deutschland diesen nicht fliegt!
198 Nane Kratzke
Wissen kann daher über Personen, über Informationen,
aber eben auch über Organisationsstrukturen transferiertbzw.
bereitgestellt werden. So kann die Bundeswehr bspw. EADS
den Auftrag geben, ein Führungssystem zu entwickeln. Die
Bundeswehr nutzt also die Kompetenz von EADS, kann aber
gleichzeitig nicht hinreichend detailliert nachvollziehen, wie
EADS im Einzelnen das Führungssystem entwickelt. Beide
Organisationen behalten ihre Kernkompetenzen und nutzen
gleichzeitig die Kompetenzen der anderen Organisation. In
solchen Szenarien ist immer zu bedenken, dass die Bundes-
wehr mehr als einen Auftragnehmer beschäftigt und auch
unbeabsichtigt als Wissensleck dienen kann7. EADS sollte
es auf den ersten Blick egal sein, ob die Bundeswehr nach-
vollziehen kann, wie EADS Waffen- und Führungssysteme
entwickelt. EADS ist es aber nicht egal, wenn über die Bun-
deswehr Wissen (absichtlich oder unabsichtlich) an Konkur-
renten transferiert wird, z.B. an Thales. Insofern ist es nach-
zuvollziehen, dass EADS gegenüber der Bundeswehr nicht
alle Details offenlegen wird. In der anderen Richtung ist auch
der Bundeswehr nicht immer erlaubt, militärisch sensible In-
formationen über verwendete Systeme im Rahmen von Rü-
stungsprojekten an beauftragte Konsortien weiterzugeben.
Dies gilt insbesondere für US-amerikanische Systeme.
Dieser Artikel soll demonstrieren, dass diese Problema-
tiken mit bereits existierenden Werkzeugen aus der Domäne
des Semantic Web, sowie Erkenntnissen der Organisations-
gestaltung abgebildet werden können.
Gronau et al. [10–13] haben eine Modellierungssprache
namens KMDL (Knowledge Management and Description
Language) entwickelt, die insbesondere auf wissensintensi-
ve Geschäftsprozesse ausgerichtet ist und auf Erkenntnissen
der Organisationsgestaltung, des organisationalen Lernens,
sowie des prozessorientierten Wissensmanagements beruht.
Aufbauend auf diesen Forschungsergebnissen präsenti ert die-
ser Artikel, wie mittels Modell-basierter Verfahren interorga-
nisationales Wissensmanagement unterstützt werden kann.
Der Artikel stellt dabei Arbeitsergebnisse des Autors dar, die
sich aus der Weiterentwicklung der KMDL8im Rahmen in-
terorganisationaler Problematiken ergeben haben.
Hierzu wird im Abschn. 2 ein Modellbegriff eingeführt,
sowie das Problem der gemeinsamen Nutzung von Modellen
erläutert. Der Abschn. 3 führt in die Grundzüge der Mo-
dellierungssprache KMDL ein. Im Abschn. 4 wird gezeigt,
wie KMDL Modelle in eine N3 Notation überführt werden
und mit welchen Werkzeugen sie bearbeitet werden können.
N3 ist eine Notation, mit der Sachverhalte in einem Subjekt,
Prädikat, Objekt Schema ausgedrückt und mittels Inferenz-
mechanismen verarbeitet werden können. Derartige Subjekt,
Prädikat, Objekt Schemata eigenen sich zur formalen Dar-
stellung von KMDL Modellen. Um konkretere Vorstellungen
zu bekommen, wird im Abschn. 5 ein komplexeres Beispiel
7Auch im Bankenbereich sind derartige Probleme bekannt. Nicht
umsonst spricht man von sogenannten Chinese Walls zischen Kredit-
und Investmentbereichen von Banken, die einen Wissenstransfer ganz
bewusst unterbinden sollen.
8Die KMDL wurde für primär intraorganisationale Aspekte ent-
wickelt.
Abb. 1 Gemeinsame Nutzung von Modellen (allwissende Sicht)
Abb. 2 Gemeinsame Nutzung von Modellen (eingeschränkte Sicht)
aus dem Rüstungsbereich stark vereinfacht dargestellt, auf
das sich die folgenden Abschnitte beziehen werden. Im Ab-
schn. 6 wird gezeigt, wie (potentielle) Wissensflüsseauf Mo-
dellen automatisiert identifiziert werden können. Im interor-
ganisationalen Wissensmanagement sind dabei insbesondere
interorganisationale Wissensflüsse von Interesse, die darüber
Auskunft geben, welches Wissen eine Organisation abgibt
und erhält. Der Abschn. 7 zeigt, wie sich Wissenstransfer-
richtlinien formulieren und deren Einhaltung mittels der in
Abschn. 4 eingeführten Werkzeuge prüfen lassen.
2 Gemeinsame Nutzung von Modellen
Von einem sehr abstrakten Standpunkt betrachtet, besteht ein
Modell aus einer Menge von über Relationen verknüpften
Relationen. Zwei Modelle sind aus dieser Sichtweise genau
dann interoperabel, wenn sie gemeinsame Objekte oder Re-
lationen haben. Über diese Objekte oder Relationen kann ein
Wissenstransfer intialisiert werden. Diese Zusammenhänge
werden in Abb. 1 verdeutlicht. Daher können interorganisa-
tionale Wissensflüsse auf der Vereinigung zweier oder meh-
rerer Modelle identifiziert werden.
In Realität müssen diese Überlegungen jedoch relativiert
werden. Aufgrund des notwendigen Schutzes von Wissen
werden Organisationen im Allgemeinen nicht bereit sein, ih-
re internen Modelle zu offenbaren. Abbildung 1 zeigt eine
solche, praktisch nicht existierende, allwissende Sicht. Al-
le kooperierenden Organisationen müssten also ihre internen
Modelle offenbaren, um interorganisationale Wissensflüsse
identifizieren zu können. Allwissende Modelle widerspre-
chen jedoch dem Wunsch, dass Organisationen Anteile ihrer
internen Wissensverarbeitung (Kompetenz) verbergen möch-
ten, die als notwendig zum Erhalt ihrer Kernkompetenz an-
gesehen werden.
Andererseits können Organisationen als Black-Boxes an-
gesehen werden, die miteinander über Schnittstellen intera-
gieren. Daher können Organisationen Teilmengen ihrer Mo-
Modell-basierte Identifikation interorganisationaler Wissensflüsse 199
delle identifizieren, die eine Schnittstelle bilden und exakt das
Wissen transferieren, welches für eine Kooperation erforder-
lich ist, jedoch kein darüber hinaus gehendes Wissen. Die-
se Schnittstelle MI
2kann Partnern bereitgestellt werden, die
diese Schnittstelle mit ihrem internen Modell M1vereinigen
können. Interorganisationale Wissensflüsse lassen sich daher
auf diesem interoperabilisiertenModell IM
1=M1∪MI
2ab-
leiten. Ein allwissendes Modell ist demnach nicht notwendig.
Abbildung 2 zeigt diese eingeschränkte Sicht.
3 Einführung in die KMDL
Die KMDL ist eine grafische Modellierungssprache zur Ana-
lyse und Gestaltung wissensinte nsiver Geschäftsprozesse. Sie
besteht aus mehreren Modellobjekten und Relationen. Die
Objekte sind in Abb. 3 in ihrer grafischen und textuellen No-
tation dargestellt. Als besonders bedeutsame Relationen kön-
nen die vier Wissenskonversionen Sozialisation, Internalisa-
tion, Kombination und Externalisation genannt werden, die
es ermöglichen, Wissensflüsse automatisiert zu identifzieren.
Sie werden durch Pfeile zwischen einem Quell- und einem
Zielobjekt dargestellt, zwischen denen ein Wissenstransfer
(potentiell) existiert.
Aufgaben sind die Grundelemente wissensintensiver Ge-
schäftsprozesse. Durch Reihung und Verzweigung von Auf-
gaben lassen sich komplexe Geschäftsprozesse modellieren.
Aufgaben arbeiten auf Informationen als Eingangsgröße und
erzeugen Informationen als Ausgangsgröße. Eine Aufgabe
wird durch eine Stelle ausgeführt. An eine Stelle kann der
Qualifikationsbedarf9gehängt werden, der notwendig ist, um
eine Aufgabe als Per son auszuführen. Stellen ermöglichen
dabei die Personen unabhängige Modellierung von Prozes-
9eine Menge von Stellenanforderungen
Abb. 3 Objekte der KMDL
sen, sowie die Definition von Anforderungen. Um Prozes-
se arbeitsfähig zu machen, müssen Stellen durch Personen
wahrgenommen werden. Die Eignung einer Person für ei-
ne Stelle ergibt sich aus der Gegenüberstellung vom Wis-
sen der Person10 gegenüber den Stellenanforderungen ei-
ner Stelle. Deckt eine Person mit all ihren Wissensobjek-
ten die Stellenanforderungen einer Stelle komplett ab, so
ist sie für die Wahrnehmung der Stelle11 vollständig geeig-
net, andernfalls existieren Einschränkungen, die z.B. durch
Ausbildung kompensiert werden können (vgl. hierzu auch
Kratzke [18]).
Informationen lassen sich in einem Speicher ablegen.
Das Ablegen und Auslesen von Informationen aus einem
Speicher kann entweder direkt aus einem Prozess im Rah-
men einer Aufgabenausführung, oder interaktiv über eine
Schnittstelle von einer Person erfolgen. Schnittstellen (ge-
nau wie Gruppen) können dabei Stellen oder Gruppen als
Stellvertreter-Objekte für Personen zugewiesen werden. Der-
artige Zuweisungen werden automatisch an die entsprechen-
den Personen propagiert. Die Modellierung von Gruppen
dient zum einen der Zusammenfassung von mehreren Perso-
nen zu einem Objekt. Eine Gruppe impliziert aber auch im-
mer die Annahme, dass zwischen allen Personen einer Grup-
pe eine erhöhte Kommunikationsaktivität existiert. Gruppen
werden damit auch als Repräsentanten von Sozialisierungs-
prozessen gesehen.
Gruppen können auch Stellen wahrnehmen. Dies dient
zum einen der Modellierungsvereinfachung, zum anderen
wird dadurch eine Selbstabstimmung zwischen allen Mitglie-
dern ausgedrückt, die sich auf die Aufgabenausführung aller
durch die Stelle wahrzunehmenden Aufgaben bezieht. Ge-
meint mit der Wahrnehmung einer Stelle durch eine Gruppe
ist also nicht die gemeinsame Aufgabenausführung, sondern
die gemeinsame Abstimmung aller Mitglieder einer Gruppe
hinsichtlich der Aufgabenausführung durch eine Person der
Gruppe.
4 Verarbeitung von KMDL Modellen
KMDL ist eine grafische Modellierungssprache und wird
dazu genutzt, um Wissensprozesse zu modellieren und zu
analysieren. Grafische Modelle eignen sich leider nur ein-
geschränkt zur automatisierten Verarbeitung durch Rechner.
KMDL selber bietet auch keine Regel- und Inferenzmecha-
nismen zur automatisierten Verarbeitung von Modellen an.
Insofern eignet sich die KMDL nur zur visuellen Analyse
und Modellierung von Wissensverarbeitung, nicht jedoch zur
formalen und automatisierten Verarbeitung.
Daher wird ein Ansatz präsentiert, der KMDL Modelle in
eine durch Berners-Lee entwickelte N3 Notation (vgl. [30])
überführt. Zur besseren Unterscheidung werden in diesem
Artikel daher grafische Modelle als KMDL Modelle und de-
ren textuellen Repräsentationen als KMDL-N3 Modelle be-
zeichnet. Diese KMDL-N3 Modelle können mittels CWM [4]
10 eine Menge von Wissensobjekten
11 und die daran hängende Ausführung aller Aufgaben
200 Nane Kratzke
verarbeitet werden12 . Mittels Inferenzmechanismen ist es
möglich, potentielle Wissensflüsse auf Basis der von Nona-
ka und Takeuchi [20] eingeführten Wissenskonversionen zu
identifizieren. Kleine UNIX Tools, die detailliert auf http:
//www.simpell.org vorgestellt werden, ermöglichen es,
KMDL-N3 Modelle automatisiert zu verarbeiten.
Insofern kann mit KMDL-N3 derselbe Modellumfang
ausgedrückt werden wie mit KMDL. Zusätzlich lassen sich
jedoch formale Verarbeitungen auf Modellen ausdrücken. In-
sofern ist KMDL-N3 mächtiger als die grafische KMDL. Ein
aus einem grafischen KMDL abgeleitetes KMDL-N3 Modell
besteht aus einer Menge an Fakten. Unter einem Fakt wird
dabei ein aus RDF bekanntes Subjekt – Prädikat – Objekt
Statement verstanden.
KMDL-N3 basiert somit auf RDF Statements, wie sie
aus dem Semantic Web bekannt sind. RDF Statements kön-
nen in N3 Statements überführt werden und umgekehrt. N3
hat jedoch gegenüber XML-basierten RDF Statements den
Vorteil, wesentlich einfacher lesbar zu sein. Die Wahl zur
Darstellung von KMDL-Modellen in einer textuellen Form
fiel daher auf N313. KMDL-N3 Modelle lassen sich mit den
folgenden Operatoren verarbeiten:
cup.py vereinigt zwei oder mehrere Modelle und er-
möglicht es, einem Modell einen Regelsatz hinzuzufügen.
Regeln ermöglichen es, weitere Fakten aus Modellen auto-
matisiert abzuleiten.
cap.py bildet die Schnittmenge zwischen zwei oder
mehreren Modellen. cap.py kann dazu genutzt werden,
um zu prüfen, ob ein Wissenstransfer zwischen Modellen
formal möglich ist. Ist die Schnittmenge zwischen zwei Mo-
dellen leer, so ist ein Wissenstransfer, aufgrund des Fehlens
gemeinsam genutzter Objekte, nicht möglich.
think.py leitet alle Fakten aus einem Modell ab, wel-
ches mit einem Regelsatz angereichert wurde und fügt es dem
Modell hinzu.
filter.py reduziert ein Modell mittels eines N3 Fil-
terausdrucks. Diese Operation ist nützlich, um ausschließlich
interorganisationale Wissensflüsse aus einem Modell zu zie-
hen. Im Gegensatz zu think erweitert filter nicht ein
bestehendes Mode ll, sondern liefert nur die abgeleite ten Fak-
ten, ohne sie dem Modell hinzuzufügen.
12 Andere Inferenzmaschinen, wie z.B. Euler (http://www.
agfa.com/w3c/euler/), Jena/Jena2 (http://jena.
sourceforge.net/inference/), Pellet (http://www.
mindswap.org/2003/pellet/index.shtml), RACER
(http://www.racer-systems.com/) oder Sprachen wie
TRIPLE (http://triple.semanticweb.org/) oder Named
Graphs (http://www.w3.org/2004/03/trix/Overview.
html) sind ebenso denkbar, da alle Ansätze letztlich auf RDF/OWL
basierten Tripel-Darstellungen (Subjekt, Prädikat, Objekt) beruhen
und sich somit grundsätzlich eignen, KMDL Modelle darzustellen
und Inferenz-Regeln zu verarbeiten. Die Wahl für N3 und CWM im
Rahmen einer prototypischen Implementierung fiel letztlich aufgrund
der intuitiven Lesart von N3 und der intuitiven Bedienbarkeit, Reife
und Stabilität, sowie freien Verfügbarkeit von CWM gegenüber
anderen (oft erst in Entwicklung befindlichen) Sprachen und Toolings.
13 Jedes KMDL-N3 Modell kann in eine XML-basierte RDF Darstel-
lung überführt werden.
Abb. 4 Modell m1
Abb. 5 Modell m2
assert.py prüft, ob ein Modell Bestandteil eines an-
deren Modells ist. Daher kann assert.py dazu genutzt
werden, um die Einhaltung von Wissenstransfer-Richtlinien
innerhalb von Modellen sicherzustellen.
Der Gebrauch dieser Tools wird exemplarisch veranschau-
licht. Zwei einfache KMDL Modelle m1und m2werden in
Abb. 4 und 5 gezeigt und sollen vereinigt werden. Daher
werden sie in ihre KMDL-N3 Repräsentationen m1.kmdl
und m2.kmdl überführt. Exemplarisch wird das Modell m1
in seiner N3 Repräsentation gezeigt.
# Modell m1
# Objekte
"G" a kmdl:Group.
"P" a kmdl:Person.
"F" a kmdl:Function.
"T" a kmdl:Task.
"I1" a kmdl:Information.
"M" a kmdl:Memory.
"IF1" a kmdl:Interface.
# Relationen
"P" kmdl:member "G".
"P" kmdl:executes "F".
"IF1" kmdl:provided "F".
"IF1" kmdl:readaccess "M".
"F" kmdl:performs "T".
"I1" kmdl:stored "M".
"T" kmdl:produces "I1".
Die folgende UNIX Kommandozeile
cat m1.kmdl | cup.py m2.kmdl
erzeugt die vereinigten KMDL-N3 Modelle. Die grafische
Entsprechung wird in Abb. 6 gezeigt. Dies wird als Verei-
nigung zweier Modelle bezeichnet und kann dazu genutzt
werden, Schnittstellen von Partner-Organisationen in interne
Modell-basierte Identifikation interorganisationaler Wissensflüsse 201
Abb. 6 Vereinigung von Modellen m=m1∪m2
Modelle zu integrieren, um mit diesen Organisationen inter-
operabel zu werden.
Abbildung 6 hat folgende KMDL-N3 Entsprechung, wie
der Leser leicht nachvollziehen kann.
# Objekte
"G" a kmdl:Group.
"P" a kmdl:Person.
"F" a kmdl:Function.
"T" a kmdl:Task.
"I1" a kmdl:Information.
"M" a kmdl:Memory.
"IF1" a kmdl:Interface.
"Q" a kmdl:Person.
"H" a kmdl:Function.
"R" a kmdl:Task.
# Relationen
"P" kmdl:member "G".
"P" kmdl:executes "F".
"IF1" kmdl:provided "F".
"IF1" kmdl:readaccess "M".
"F" kmdl:performs "T".
"I1" kmdl:stored "M".
"T" kmdl:produces "I1".
"Q" kmdl:member "G".
"Q" kmdl:executes "H".
"H" kmdl:performs "R".
"R" kmdl:uses "I1".
"I1" kmdl:retrieved "M".
Ferner ist es möglich, die Schnittmenge mehrerer Model-
le zu bestimmen. So kann ermittelt werden, ob zwei Modelle
gemeinsame Objekte ha ben. Zwischen die sen Modellen kann
also ein Wissensfluss etabliert werden. Dazu können die bei-
den KMDL-N3 Modelle m1und m2in der folgenden Art
verarbeitet werden:
cat m1.kmdl | cap.py m2.kmdl
Dies erzeugt das folgende KMDL-N3 Modell, wie der
Leser einfach nachvollziehen kann.
# Objekte
"G" a kmdl:Group.
"I1" a kmdl:Information.
"M" a kmdl:Memory.
Nur über diese Objekte kann ein Wissenstransfer zwi-
schen den Modellen m1und m2initiiert werden.
5 Komplexes Beispiel aus der Rüstung
Das nun gezeigte Beispiel, erfüllt die Voraussetzungen des in-
terorganisationalen Wissensmanagement (räumlich getrenn-
te, sich nicht gegenseitig weisungsbefugte Organisationen,
die zur Erreichung eines Ziels gemeinsam wissensintensive
Prozesse betreiben müssen).
Es entstammt aus de r nationalen Marinerüstung. Der Rüs-
tungsprozess der Bundeswehr ist anhand von vier Phasen
(Analyse, Projektierung, Einführung bzw. Realisierung und
Nutzung) strukturiert. Diese Phasen sind in sich rückgekop-
pelt, so dass gemachte Erkenntnisse in der Nutzung von Wehr-
material in die Neu-, Weiter- oder Anpassentwicklung von
Wehrmaterial einfließen können. Kursiv geschriebene Be-
griffe spiegeln sich dabei in Abb. 7 wider. Die Abb. 7 stellt
diesen Rüstungsprozess auf einer sehr abstrakten Ebene dar.
Der Prozess ist in sich wesentlich komplexer. Die Aufgaben
Analyse,Projektierung,Realisierung und Nutzung werden
daher nur als abstrakte Black-Boxen dargestellt14.
In der Analysephase (vgl. Abb. 7) wird die aktuelle Fähig-
keitslage der Streitkräfte durch das Bundesministerium der
Verteidigung erhoben und mit einem aus den verteidigungs-
politischen Richtlinien abgeleiteten Fähigkeitsumfang ver-
glichen. Dies geschieht in sogenannten integrierten Arbeits-
gruppen zur Fähigkeitsanalyse (IAGFA). Werden Fähigkeits-
lücken identifiziert, die durch ein technisches System (z.B.
ein modernisiertes Führungs- und Waffeneinsatzsystem einer
Fregatte) kompensiert werden können, so wird eine abschlie-
ßende funktionale Forderung (AF ) an die Lösung formuliert
und zur Projektierung an die Industrie ausgeschrieben. In
die Anforderungen an eine Lösung fließen Erkenntnisse aus
der Nutzung mit ein, die unter anderem aus einer systemati-
schen Auswertung von Mission Reports und Störmeldungen
gewonnen werden.
Die Projektierungsphase wird nur durchlaufen, um si-
gnifikante Risiken bei der Umsetzung einer materiellen Lö-
sung im Vorfeld abzubauen. Dies kann z.B. durch Bau von
Prototypen geschehen. Das Ergebnis einer Projektierung ist
formal eine Realisierungsgenehmigung. Wesentlich wichti-
ger ist jedoch das über die Projektierung aufgebaute Wissen,
das in Prototypen, sowie einer entwickelten Systemarchitek-
tur (SysArc) und Projektplanung externalisi ert werden konnte
und durch eine intensive Interaktion mit der Bundeswehr im
Rahmen einer Anforderungsanalyse aufgebaut wurde.
In der Realisierungsphase wird das System durch ein Kon-
sortium entwickelt und am Ende des Projekts abgenommen.
Bei der Entwicklung des Systems erfolgt eine begleitende
Qualitätssicherung durch die Bundeswehr, die zum Ziel hat,
die Erfüllung der AF sicherzustellen. Der Rüstungsprozess
der Bundeswehr sieht dabei explizi t vor, vorrangig bereits exi-
stierende technische Fertigkomponenten zu nutzen, um kos-
tenträchtige und risikobehafte Entwicklungen zu vermeiden.
Hierauf haben sich die wehrtechnischen Systemhäuser ein-
14 Weitere Details zum Rüstungsprozess der Bundeswehr, kann der
Leser in [7] nachvollziehen. In [19] wird explizit auf Wissensmanage-
mentansätze insbesondere in den Phasen Projektierung und Realisie-
rung von Rüstungsprojekten eingegangen.
202 Nane Kratzke
Abb. 7 Beispiel aus der Rüstung
gestellt und in eigenen Entwicklungsprozessen, insbesondere
im Software-Bereich, wehrtechnische Grundkomponenten15
entwickelt, die im Rahmen der Software-Entwicklung aus
COTS16-Bibliotheken bezogen werden können und nur noch
aufeinspezifisches Systemausgeprägt werdenmüssen.In die-
sen Fertigkomponenten steckt ein Großteil derKompetenz ei-
ner Firma. Entsprechend schutzbedürftig wird das damit zu-
sammenhängende Wissen durch eine Firma gesehen. Gleich-
zeitig betreiben die Firmen ein Controlling, welches oft durch
sogenannte Projektstatusberichte (PSB) getrieben wird. Übli-
cherweise sieht die Bundeswehr diese Entwicklungs- und
Controllingprozesse nicht, da in diesen Prozessen das schüt-
zenswerte Firmen-Know-How verortet ist.
In der Nutzung wird das System entsprechend seiner
operativen Fähigkeiten durch die Marine im Rahmen von
Operationen, Einsätzen, Übungen, Manövern etc. genutzt
und realisiert damit einen Fähigkeitsanteil der Streitkräf-
te. In der Nutzung gewonnene Erkenntnisse17 werden ver-
15 z.B. IT-Komponenten zur Berechung automatisierter Bedrohungs-
berechungen und Bekämpfungsanweisungen, Hochverfügbarkeitslö-
sungen, Waffen- und Sensorintegrationen, Sensorfusionsprozesse, etc.
16 Commercial off-the-shelf
17 z.B. aus der Auswertung von Manövern, Übungen, Einsätzen,
Operationen, Analyse von Störmeldungen, etc.
dichtet und wieder über Mission Reports und schiffstech-
nischen Störmeldungen in den Analyseprozess eingesteu-
ert. Auf diese Weise ergibt sich ein geschlossener Regel-
kreis innerhalb des Rüstungsprozesses der Bundes-
wehr, der eine permanente Anpassung an eine sich wan-
delnde Fähigkeitslage ermöglicht und in der Nutzung ge-
wonnene Erkenntnisse von direkt das System nutzenden
OPZ18-Crews und wartenden Schiffstechnikern systema-
tisch berücksichtigt.
Abbildung 7 zeigt dabei nicht nur den schematischenAb-
lauf des Rüstungsprozesses, sondern auch Ableitungen von
potentiellen Konversionen, die sich innerhalb des dargestell-
ten Modells identifizieren lassen. Diese sind als geschwunge-
ne Pfeile dargestellt und entsprechend ihres Typs als Interna-
lisierungen, Externalisierungen, Sozialisierungen und Kom-
binationen gekennzeichnet und nummeriert. Aus Gründen
der Übersichtlichkeit sind dabei nicht alle ableitbaren Kon-
versionen eingezeichnet, sondern nur für den dargestellten
Sachverhalt relevante.
Wie derartige Konversionen auf einem gegebenen Modell
identifiziert werden können, zeigt der folgende Abschnitt.
18 Operationszentrale: Aus dieser erfolgt der operative und takti-
sche Einsatz eines Kriegsschiffes.
Modell-basierte Identifikation interorganisationaler Wissensflüsse 203
6 Identifikation von Wissensflüssen
Die automatisierte Identifikation von Wissensflüssen auf
KMDL Modellen geschieht in zwei Schritten. Im ersten
Schritt werden potentielle Basiskonversionen (Sozialisation,
Internalisation, Kombination und Externalisation)
–soc :Group ∪Perso n ↔Group ∪Person
–int :Information ∪Memory →Person
–com :Information ∪Memory →Information ∪Memory
–ext :Pers on →Information ∪Memory
identifiziert, wie sie von Nonaka und Takeuchi [20] beschrie-
ben werden. Im zweiten Schritt werden diese Konversionen
kombiniert, um längere Wissensflüsse, die aus mehrals einer
Konversion bestehen, a bleiten zu können. Der hier vorgestell-
te Ansatz basiert damit i.W. auf dem von Borghoff und Pa-
reschi identifizierten ”Flow of knowledge“ (vgl. [6, S. 5 ff]).
Der (potentielle) Wissensfluss wird allerdings automatisiert
aus Modellen abgeleitet bzw. über Modelle gesta ltet. Die Ver-
knüpfung von Organisationsgestaltung und Wissensmanage-
ment ist also wesentlich enger.
6.1 Identifikation von Konversionen
Dieser Abschnitt beschreibt am Beispiel einer Externalisati-
on, wie Konversionen automatisiert auf KMDL-N3 Model-
len identifiziert werden können. Abbildung 8 zeigt ein Mo-
dell mit drei identifizierbaren Externalisationen. Die Person
Phat das Wissen K. Daher kann das Wissen Kmittels der
Schnittstelle IF in den Speicher M2externalisiert werden.
Das Wissen Kkann ferner durch Ausführung der Aufgabe
Tin die Information Iexternalisiert werden. Da die Infor-
mation Iim Speicher M1abgelegt wird, existiert folglich
auch eine Externalisation des Wissens Kvon der Person P
in den Speicher M1. Diese automatisiert identifizierbaren Ex-
ternalisationen, werden in Abb. 8 mit Pfeilen dargestellt. Die-
se Konversionen19 lassen sich mittels der folgenden UNIX
Kommandozeile ermitteln:
cat model.kmdl | cup.py kmdl.rule |
think.py > externalizations.kmdl
Die folgende (vereinfachte) N3 Regel identifiziert Exter-
nalisationen von Personen in Speicher über Schnittstellen.
Diese Regel ist daher Bestandteil der Abb. 8.
{?m2 a kmdl:Memory.
?p a kmdl:Person.
?if a kmdl:Interface; kmdl:provided ?p.
kmdl:writeaccess ?m2;
}=> { ?p kmdl:ext ?m2 }.
Sie besagt, dass jede Person ?p, die Zugang zu einer Schnitt-
stelle ?if mit schreibendem Zugriff auf einen Speicher ?m
19 Nicht nur diese Konversionsart, sondern auch alle anderen Konver-
sionsarten. Auf die Darstellung der Ableitung aller Konversionsarten,
wird an dieser Stelle jedoch aus Platzgründen verzichtet.
Abb. 8 Externalisierungs-Regel
Tabelle 1 Mögliche Kombination von Konversionen
hat, eine potentielle Externalisierung von Wissen der Person
?pin ?mermöglicht.
Der Leser kann zur Veranschaulichung alle in Abb. 8 ge-
zeigten Modellkonfigurationen, die zur Ableitung einer Ex-
ternalisierung führen, mit den in Abb. 7 als ext1 bis ext5
gekennzeichneten Konversionen vergleichen, und wird fest-
stellen, dass die gekennzeichneten Externalisierungen sich
exakt in den in Abb. 8 gezeigten Modellkonfigurationen
wiederfinden.
Der KMDL Regelsatz enthält eine Menge ähnlich gestal-
teter Konversionsidentifikations-Regelsätze und ermöglicht
es, potentielle Sozialisationen, Kombinationen, Internalisa-
tionen, sowie Externalisationen auf KMDL Modellen auto-
matisiert zu identifizieren.
6.2 Kombination von Konversionen
Basiskonversionen lassen sich kombinieren, um so längere
Wissensflüsse zu identifizieren. Die möglichen Kombinatio-
nen von zwei Konversionen und die resultierenden transitiven
Konversionen sind in Tabelle 1 aufgeführt.
Die Tabelle 1 wird anhand einiger in Abb. 7 gekenn-
zeichneten Konversionen erläutert. Abbildung 7 enthält da-
bei nicht alle identifizierbaren Konversionen, sondern nur
die für die Rückkopplung des Rüstungsprozesses relevanten
Basiskonversionen. Unter einer Basiskonversion wird eine
Konversion verstanden, die direkt aus einem Modellanteil
ableitbar ist. Zwei Basiskonversionen lassen sich gem. Ta-
belle 1 zu einer Konversion der Stufe zwei kombinieren.
Eine Basiskonversion kann mit einer Konversion der Stu-
fe zwei gem. Tabelle 1 zu einer Konversion der Stufe drei
kombiniert werden, usw. Ausgehend von der IAGFA kann ei-
ne Kette von Basiskonversionen gefunden werden, die wie-
der in der IAGFA mündet. Insofern existiert ein geschlosse-
ner Wissenskreislauf im modellierten Rüstungsprozess (vgl.
Abb. 7).
204 Nane Kratzke
Zwischen der Fähigkeitslage und der IAGFA existiert eine
Internalisierung (int1). Die IAGFA externalisiert wiederum
ihr Wissen in eine AF (ext1). Zwischen der Fähigkeitsla-
ge und der AF existiert also über die IAGFA eine indirekte
Konversion. Gem. Tabelle 1 ist diese Konversion eine Kom-
bination (com =int1◦ext1)20 .DieAF wird im Rahmen der
Projektierung durch eine Gruppe Designer verarbeitet, d.h.
internalisiert (int2), um eine Systemarchitektur zu entwer-
fen. Von der IAGFA zu den Industrie-Designern wird also
Wissen transferiert. Dieser Personen zu Personen basierte
Wissenstransfer wird als Sozialisation bezeichnet und ergibt
sich auch formal aus der Tabelle 1 (soc =ext1◦int2).
Konversionen, die organisationale Grenzen überschrei-
ten21, werden interorganisationale Konversionen genannt.
6.3 Identifikation interorganisationaler Konversionen
Um interorganisationale Wissensflüsse ableiten zu können,
muss eine Organisation externe Schnittstellen mi.kmdl zu
kooperierenden Organisationen mit ihrem eigenen internen
Modell m.kmdl vereinigen, um so das interoperabilisierte
Modell im.kmdl zu ermitteln. Dieses Modell wird mit dem
KMDL Regelsatz (kmdl.rules) vereinigt, damit mit dem
think Operator alle Wissenskonversionen auf dem Modell
abgeleitet werden können. Dieses Modell enthält folglich al-
le, d.h. sowohl intra- als auch interorganisationale, Konver-
sionen. Mittels des folgenden (vereinfachten) N3 Filter Aus-
drucks ist es möglich, das Modell ausschließlich auf seine
interorganisationalen Konversionen (d.h. Wissensflüsse) zu
reduzieren.
{ ?src a ?T1; kmdl:ownedby _:o.
?dst a ?T2; kmdl:ownedby
[log:notEqualTo _:o].
?src ?con ?dst.
}=>{?srca?T1.?dsta?T2.
?src ?con ?dst. }.
Hierzu wird mittels des Filterausdrucks auf einem gegebe-
nen Modell nach Quell- und Zielobjekten ?src und ?dst ge-
sucht, die in unterschiedlichen Organisationen vorkommen
und zwischen denen eine Konversion ?con existiert. Ist dies
der Fall, so werden die Quell- und Zielobjekte inklusive ih-
res Typs ?T1 und ?T2 mit der zwischen ihnen existierenden
Konversion dem Filterergebnis hinzugefügt.
Das ausschließlich auf interorganisationale Konversio-
nen reduzierte Modell interorg.kmdl lässt sich mit der fol-
genden UNIX Kommandozeile berechnen.
cat m.kmdl |
cup.py m_i.kmdl kmdl.rules |
20 Dies ergibt sich zum einen aus der formalen Typisierung der Kom-
bination, aber auch aus der praktischen Bedeutung. Mehrere in der Fä-
higkeitslage gespeicherte Informationen, werden zu einer neuen Infor-
mation, der AF, durch eine oder mehrere Personen verdichtet. Dies ent-
spricht exakt dem Kombinationsverständnis von Nonaka und Takeuchi.
21 Konversionen mit einem Startobjekt in einer Organisation O1und
einem Zielobjekt in einer Organisation O2(O1= O2).
think.py | filter.py interorg.filter >
interorg.kmdl
Die Anwendung des interorg Filters auf das Modell in
Abb. 7 wirft unter anderem die folgenden Fakten aus22 ,wie
der Leser leicht anhand der in Abb. 7 gekennzeichneten und
nach Stufen sortierten Konversionen nachvollziehen kann:
# Level 1
"AF" kmdl:int "Designer".
"Team 1" kmdl:ext "System".
# Level 2
"IAGFA" kmdl:soc "Designer".
"AF" kmdl:com "SysArc".
"SysArc" kmdl:com "System".
# Level 3
"Mission Reports" kmdl:int "Designer".
"COTS Bibliothek" kmdl:int "Operateure".
7 Wissenstransfer-Richtlinien
Wissenstransfere können aus der Sicht einer Organisation
in zwei Richtungen unterschieden werden (vgl. hierzu auch
Abb. 2). Ein Wissenstransfer aus einer Organisation heraus,
soll Wissensexport, der Transfer von Wissen in eine Organi-
sation Wissensimport heißen. Beide Transferarten lassen sich
innerhalb des eigenen (interoperabilisierten) Modells identi-
fizieren.
Es wird nun verdeutlicht, wie Gestaltungs-Restriktionen
von Modellen formuliert und sichergestellt werden können.
Auf diese Weise können Wissenstransfer-Richtlinien23 for-
muliert und die Einhaltung dieser Richtlinien geprüft wer-
den. Solche Restriktionen lassen sich als Zusicherungen an
Modelle formulieren, deren Einhaltung mittels der folgenden
Kommandozeile geprüft werden kann:
cat model.kmdl |
assert.py transferpolicy.assert
transferpolicy.assert beinhaltet eine einzuhal-
tende Restriktion, die auf einem gegebenem Modell gültig
sein soll. assert.py erzeugt einen Fehler, wenn diese Re-
striktion nicht eingehalten wird. Auf diese Weise lassen sich
(formale) Verstöße gegen Wissenstransfer-Richtlinien auto-
matisiert auf Modellen erkennen.
7.1 Wissensexport-Richtlinien
Bei der Einhaltung von Exportrichtlinien ist das interope-
rabilisierte Modell nach Anteilen zu durchsuchen, die nicht
22 Es sind nicht alle ableitbaren interorganisationalen Konversionen
aufgeführt, sondern nur einige Beispiele.
23 d.h. die konstruktive Vorgabe, welches Wissen eine Organisation
verlassen darf und welches Wissen eine Organisation aufnehmen sollte
Modell-basierte Identifikation interorganisationaler Wissensflüsse 205
Bestandteil des interoperabilisierten Modells sein sollen. Ex-
portrichtlinien werden also als Negativfälle formuliert. Tre-
ten solche Negativfälle innerhalb des Modells auf, ist dies
eine Verletzung der entsprechenden Exportrichtlinie. Export-
richtlinien können daher allgemein formuliert und gegen be-
liebige Modelle geprüft werden. Beispielhaft werden zwei
Grundtypen von Exportrichtlinien gezeigt, die das Prinzip
erläutern sollen.
Die erste Richtlinie definiert den Export des konkreten
Wissens Kals eine Verletzung. Sie ist demnach gleichbedeu-
tend mit der Aussage: ”Das Wissen K darf nicht exportiert
werden.“ Dieses Wissen Kkönnte bspw. als notwendig zum
Erhalt von Kernkompetenzen eingestuft worden sein oder ei-
ner Geheimhaltung unt erliegen und soll daher nicht exportiert
werden. Beliebige Konversionen, die Kexportieren, stellen
daher einen Verstoß gegen diese Richtlinie dar. Für die Ma-
rine kann dies bspw. alles als NATOSECRECT eingestufte
Material beinhalten.
?model log:notIncludes
{ _:ext kmdl:ownedby
[log:notEqualTo "Marine"].
_:int kmdl:ownedby "Marine".
(_:int _:conversion _:ext)
kmdl:content "NATOSECRET".
}.
Sie besagt, dass keine Konversion (gleich welchen Typs) zwi-
schen einem der Marine zugeordneten Objekt _ :int und
einem nicht der Marine zugeordneten Objekt _ :ext existie-
ren darf, die einen als N ATOSECRET gekennzeichneten
Inhalt transferiert.
Die zweite Grundform einer Exportrichtlinie konzentriert
sich nicht auf den Inhalt von Konversionen, sondern auf die
angezapften Quellen. In diesem Fall wird es als nicht akzep-
tabel angesehen, dass Partner-Organisationen auf einen kon-
kreten Wissens- oder Informationsträger Q(z.B. Personen,
Informationen oder Speicher) zugreifen können, der gehei-
mes Wissen oder Informationen besitzt (z.B. Erkenntnisse
über neueste Forschungs- und Entwicklungsprojekte eines
Unternehmens). Im Allgemeinen ist es jedoch paranoid den
Zugriff komplett unterbinden zu wollen.
Dies soll am Beispiel der Mission Reports deutlich ge-
macht werden. Mission Reports können der militärischen
Geheimhaltung unterliegende Daten beinhalten. Demzufolge
darf formal kein Wissensfluss aus der Quelle Mission Reports
herausgehen, der in einem nicht der Marine zugeordneten
Objekt mündet. Dies lässt sich wie folgt formalisieren.
?model log:notIncludes
{ "Mission Reports" _:con [kmdl:ownedby
[log:notEqualTo "Marine"]].
}.
Diese Regel würde im Fall der Abb. 7 bspw. eine Regelver-
letzung auslösen, da sich eine indirekte Konversion (int5◦
ext1◦int2) zwischen Mission Reports und der Gruppe De-
signer ergibt.
An dieser Stelle steht man vor einem Problem. Auf der
einen Seite, ist der Speicher Mission Reports einem beson-
deren Geheimhaltungsschutz unterworfen und sollte daher
nicht im interorganisationalen Kontext leichtfertig Verwen-
dung finden, andererseits ste hen in den Mission Reports durch-
aus wertvolle Erkenntnisse, die dazu genutzt werden können,
in Praxis erfahrene Systemschwachstellen zu beseitigen. Im
Sinne der Geheimhaltung sollte daher der Speicher Mission
Reports nicht im Rüstungsprozess genutzt werden, im Sinne
der evolutionären Weiterentwicklung von Waffen- und Füh-
rungssystemen hingegen schon.
Derartig restriktive Richtlinien sind aber für die wenig-
sten Fälle sinnvoll, da ja interne Personen als Filter dienen
können und davon ausgegangen werden kann, dass Perso-
nen nicht wahllos Speicherinhalte nach außen geben. Eine
übliche Einschränkung ist daher, keinen direkten Zugriff auf
einen Speicher zuzulassen.
?model log:notIncludes
{ _:ext kmdl:ownedby
[log:notEqualTo "Marine"].
("Mission Reports"
_:con _:ext) level 1.
}.
Indirekte Zugriffe jedoch zu erlauben, wenn der eigene nut-
zende Personenkreis einer geheimhaltungsbedürftigen Quel-
le entsprechend geschult ist.
Hier muss der direkte und der indirekte Zugriff auf einen
Speicher unterschieden werden. Sicherlich wäre es verant-
wortungslos, einen externen Ingenieur direkten Zugriff auf
die Mission Reports zu gewähren. Ein indirekter Zugriff (und
dieser erfolgt im Beispiel über die Information AF) ist hinge-
gen unproblematisch, wenn sichergestellt werden kann, dass
keine geheimhaltungswürdigen Inhalte in ein Mittlerobjekt
(in diesem Fall, die Information AF) gelangen. Gefordert
werden muss also, dass alle Personen, die direkten Zugriff
auf Mission Reports erhalten, derart ausgebildet sind, dass
sie wissen, wie mit geheimhaltungsbedürftigen Inhalten um-
zugehen ist. Dies wird in Abb. 7 durch das Wissensobjekt SE-
CRET HANDLING ausgedrückt. Indirekte Zugriffe auf Mis-
sion Reports werden also erlaubt, wenn alle Personen mit
direktem Zugriff auf Mission Reports das Wissen um den
Umgang mit geheimen Inhalten haben (repräsentiert durch
das Wissensobjekt SECRET HANDLING). Dann dienen die-
se Personen als Filter, und es kann davon ausgegangen wer-
den, dass Speicherinhalte nicht wahllos nach außen gegeben
werden.
?model log:includes
{ :p a kmdl:Person;
kmdl:ownedby "Marine".
("Mission Reports" _:con1 :p)
kmdl:level 1
:p _:con2 [kmdl:ownedby
[log:notEqualTo "Marine"]].
}.
?model log:notIncludes
206 Nane Kratzke
{ :p kmdl:knows "SECRET HANDLING".
}.
Der oben formal notierte Fall darf also nicht auftreten. Ei-
ne Person pder Marine hat direkten Zugang zum Spei-
cher Mission Reports über eine wie auch immer geartete
Konversion con1. Gleichzeitig existiert zwischen pund ei-
nem externen Objekt eine Konversion con2. Zwischen Mis-
sion Reports und einem externen Objekt existiert also eine
Konversion con1◦con2 über die Person p. Die Richtlinie
schlägt genau dann Alarm, wenn pnicht das Wissensobjekt
SECRET HANDLING zugewiesen ist, also pkeine Kennt-
nisse darüber hat, wie man mit geheimen Daten aus Mission
Reports umzugehen hat. Über entsprechende Filtergestaltun-
gen24 lassen sich nach gleichen Mechanismen alle Personen
aus Modellen filtern, die direkten Zugang zu Speichern mit
geheimhaltungsbedürftigen Inhalten und Konversionen mit
externen Objekten haben, jedoch keine Kenntnis über Um-
gang mit geheimen Inhalten haben. Diese Personen-Gruppe
muss entsprechend geschult oder von ihren Aufgaben mit
geheimhaltungspflichtigen Material entbunden werden. Der-
artige Abfragen lassen sich formal formulieren und auto-
matisiert auf KMDL-N3 Modellen anwenden. Formale Ver-
letzungen von Geheimhaltungsbestimmungen lassen sich so
einfach erkennen.
7.2 Wissensimport-Richtlinien
Wissensimport-Richtlinien sind weniger kompliziert als Ex-
portrichtlinien. Beim Import kann man immer nur auf das
Vorhandensein bereits identifizierter Konversionen prüfen.
Hierdurch lässt sich feststellen, ob der Erhalt von Wissens-
import-Kanälen bei externen Änderungen25 Auswirkung auf
bereits etablierte Importkanäle hat, insbesondere dann, wenn
diese Importkanäle vertraglich vereinbart wurden26.DerAus-
tausch eines Beraters, mit Verlust der von diesem Berater
bislang bereitgestellten Kenntnisse, wäre dann ein Vertrags-
bruch und kann durch periodische Importchecks erkannt
werden.
Zwei Aspekte lassen sich beim Import daher prüfen. Wird
über eine einmal identifizierte Konversionen weiterhin das-
selbe relevante Wissen Kimportiert? Hat der Wissensimport
weiterhin dieselbe Qualität – oder wird der Transfer zu einer
stillen Post?
Um dies zu verdeutlichen, wird wieder das Beispiel aus
Abb. 7 aufgegriffen. Diesmal wird der Blickwinkel der In-
dustrie eingenommen. Mit Vertragsschluss wurde der Indu-
strie zur Durchführung der Projektierung ein kompetenter
Ansprechpartner im Bereich der Marine zugesagt. Bei dem
weiterzuentwickelnden Führungs- und Waffeneinsatzsystem
sollen weitere Funktionalitäten aus dem Bereich der Luftab-
wehr ergänzt werden. Aus diesem Grund soll der Ansprech-
24 Auf die Nutzung von Filtern wird an dieser Stelle jedoch aus Platz-
gründen nicht eingegangen.
25 z.B. an einer bereitgestellten Schnittstelle oder internen Anpassun-
gen eines Partners
26 z.B. im Rahmen von Beratungsleistungen
partner im Bereich der Marine praktische Erfahrungen aus
dem Bereich der Luftabwehr haben (repräsentiert durch das
Wissensobjekt AAW27). Es wurde sich auf die Person des
FKpt Meier geeinigt, der mit seinem Wissen der Gruppe De-
signer zur Verfügung stehen soll. Auf Seiten der Industrie
wird diese Zusage folgendermaßen formalisiert.
?model log:includes
{ ("FKpt Meier" kmdl:soc "Designer")
kmdl:content "AAW".
}.
Wird FKpt Meier nun während des Projektes versetzt28,kann
dies durch eine formale Prüfung auf dem Modell durch den
Industrie-Partner erkannt werden.
Nun kann der Fall eintreten, dass FKpt Meier als Kom-
mandant an Bord eines Schiffes versetzt wird. Dort würde
er in die Gruppe der Operateure aufgenommen werden. Sein
Wissen über Luftabwehr nimmt er natürlich mit. Dann exi-
stiert immer noch formal ein Wissenstransfer von FKpt Mei-
er zu der Gruppe der Designer, da er als Kommandant na-
türlich die Möglichkeit hat, Beiträge zu Mission Reports zu
schreiben. Über die Kette ext4◦int5◦ext1◦int2 existiert
dann noch eine indirekte Sozialisierung über vier Stufen zur
Gruppe der Designer, wie der Leser leicht in Abb. 7 nach-
vollziehen kann. Dies ist natürlich nicht gewollt, da mit je-
der Konversion immer weniger Wissen transferiert wird und
Stille-Post-Effekte eintreten. Aus diesem Grund formuliert
die Industrie eine weitere einzuhaltende Restriktion, die die
maximale Konversionskette zwischen FKpt Meier und den
Designern beschränkt.
?model log:includes
{ ("FKpt Meier" kmdl:soc "Designer")
kmdl:level [math:lessThan 3].
}.
Beide Restriktionen zusammen, erlauben es der Industrie au-
tomatisiert festzustellen,wann die Person FKpt Meier in der
Marine derart eingesetzt wird, dass ihr Zweck als Wissens-
lieferant für Luftabwehr-Fragen im Rahmen eines Rüstungs-
projekts nicht oder nur noch unzureichend erfüllt wird. Der-
artige Überlegungen sind auch in Was-Wäre-Wenn Überle-
gungen der Personalplanungen der Bundeswehr wertvoll, da
so festgestellt werden kann, durch welche Person FKpt Mei-
er vollwertig ersetzt werden kann, um ein Rüstungsprojekt
nicht zu gefährden.
Und natürlich sind diese Aspekte nicht nur in einem rei-
nen Rüstungskontext von Interesse, sondern grundsätzlich in
wissensbasierten Kooperationen von Bedeutung, in denen al-
le Partner sowohl Wissen teilen, als auch ihr Wissen schützen
müssen.
8 Zusammenfassung und Ausblick
Die präsentierten Ergebnisse sind vor einem rein interorga-
nisationalen Hintergrund entstanden. Auf mehreren Konfe-
27 NATO-Abkürzung für Anti Air Warfare
28 Keine unrealistische Annahme in der Bundeswehr
Modell-basierte Identifikation interorganisationaler Wissensflüsse 207
renzen, in Seminaren und Gutachten zu Veröffentlichungen
wurde jedoch immer wieder von verschiedensten Seiten der
Wert des hier vorgestellten Ansatzes für einen intraorganisa-
tionalen Kontext betont. Dem ist zuzustimmen. Vom Grund-
satz her reicht es, den Begriff der Organisation durch Orga-
nisationsbereich zu ersetzen. Dann ist der hier vorgestellte
Ansatz auch intraorganisational anzuwenden. Dennoch ist
die besondere Betonung der interorganisationalen Perspek-
tive im Rahmen der Forschung wertvoll, weil dies implizi-
te Annahmen von vornherein ausschließt. Aspekte wie for-
male Weisungsbefugnisse, allwissende Modelle, identische
Organisationskultur, etc. werden oft angenommen, sind je-
doch im interorganisationalen Umfeld einleuchtenderweise
nicht immer gegeben. Die Hinterfragung dieser Annahmen
führt dann zu Lösungen, die auch für intraorganisationale
Probleme (vor allem in großen Organisationen) wertvoll sein
können.
Insbesondere beim interorganisationalen Wissensmana-
gement sind die Bedürfnisse der Lieferanten von Wissen
in einem ”Wissens-GRID“ besonders zu berücksichtigen.
Die strukturelle Gestaltung solcher GRIDs lässt sich mit-
tels Modell-basierter Verfahren, wie z.B. der vorgestellten
KMDL, vereinfachen. Dennoch bleiben konzeptionelle Pro-
bleme. Zum einen, wie man aus einem Modell eine ent-
sprechende informationstechnische Infrastruktur ableiten
kann? In diesem Artikel konnte zumindest gezeigt werden,
dass das Problem ”allwissender Modelle“ umgehbar ist und
zwar derart, dass die berechtigten Interessen von Teilneh-
mern an einem Wissens-GRID berücksichtigt werden
können.
Für in einem GRID kooperierende Organisationen reicht
es, eine Schnittstelle zu ihrem Organisationssystem zu defi-
nieren. Ihr eigenes Organisationssystem kann dann von Part-
nern als Black-Box betrachtet werden. Daher ist es jeder Or-
ganisation möglich, eine Schnittstelle zu ihrem Organisati-
onssystem zu entwerfen, die für eine Kooperation notwendi-
ges Wissen systematisch bereitstellt, jedoch Kernkompetenz
relevantes Wissen nicht offenbart. Um solche Schnittstellen
entwerfen und auch einer formalen Qualitätssicherung un-
terwerfen zu können, wurde gezeigt, wie Wissenstransfer-
Richtlinien formuliert und automatisiert verifiziert werden
können.
Danksagung Besonderer Dank gebührt Prof. Gronau und seinen Mit-
streitern an der Universität Oldenburg und Potsdam für die Entwicklung
der KMDL. Dank soll an dieser Stelle auch den unzähligen und sel-
ten erwähnten Gutachtern ausgesprochen werden, die im Rahmen der
wissenschaftlichen Publikation, durch ihre konstruktiven Kommentare
wertvolle Hinweise geben. Und an dieser Stelle möchte ich die Firma
T-Systems nicht unerwähnt lassen. Sie taucht immer wieder als Partner
vieler Tagungen rund um das Thema Wissensmanagement auf. Doch
dies nur am Rande. Gesonderter Dank gilt hier dem Bereich Defence
von T-Systems und noch spezieller Herrn Krause und seinem Team aus
den Niederlassungen in Hamburg und Wilhelmshaven. Als Entwick-
lungsbegleitoffizier vor Ort in Hamburg war es für mich sehr wertvoll,
einmal die Sicht der Industrie in Rüstungsprojekten wahrnehmen zu
können. Viele Einfälle (mindestens jedoch das Problembewusstsein)
habe ich aus dieser Zeit, auch wenn sie kaum durch die formalen No-
tationen erkennbar sein mögen.
Literatur
1. Abecker A, Hinkelmann K, Maus H, Müller HJ (2002) Ge-
schäftsprozessorientiertes Wissensmanagement. Springer, Berlin
2. Bauer H (2001) Virtuelle Organisationen im Zeitalter von E-
Business und E-Government, Chapt Virtualität als neue Dimen-
sion. Springer, Berlin, pp 25–42
3. Becker J, Kugeler M, Rosemann M (eds) (2005) Prozessmanage-
ment: ein Leitfaden zur prozessorientierten Organisationsgestal-
tung, 5th edn. Springer, Berlin
4. Berners-Lee T (2000) CWM.
http://www.w3.org/2000/10/swap/doc/cwm.html
5. Böhm S (2000) Intra- und Interorganisationaler Wissenstransfer.
Schriften zur beruflichen Weiterbildung, No. 65. QUEM-report,
Berlin
6. Borghoff U, Pareschi R (1998) Information Technology for Know-
ledge Management, Chapt Introduction. Springer, Berlin, pp 3–14
7. Bundesministerium der Verteidigung (2004) CPM – Verfah-
rensbestimmungen für die Bedarfsermittlung und Bedarfs-
deckung in der Bundeswehr. http://www.bwb.org/
C1256DC00048AA8F/vwFilesByName/AG-BUND/
$File/CPM.pdf
8. Davenport T, Prusak L (2000)Working Knowledge. Harvard Busi-
ness School Press
9. Ehrhardt, Gora W (2001) Zehn Thesen zur praktischen Virtuali-
sierung. In: Bauer H, Gora W (eds) Virtuelle Organisationen im
Zeitalter von E-Business und E-Government. Springer, Berlin, pp
149–152
10. Gronau N (2004) KMDL: Eine Sprache zur Modellierung wis-
sensintensiver Prozesse. http://www.competence-site.
de/wissensmanagement.nsf/cc/WEBR-66VL2Y
11. Gronau N, Weber E (2004) Defining a infrastructure for know-
ledge intensive business processes. Journal of Universal Computer
Science: Proceedings of I-Know ’04, pp 424–431
12. Gronau N, Weber E (2004) Management of Knowledge Intensive
Business Processes. In: Desel J, Pernici B, Weske M (eds) Business
Process Management. Springer, Heidelberg
13. Gronau N, Weber E (2004) Modeling of Knowledge intensive busi-
ness processes with the declaration language KMDL. In: Khosrow-
Pour M (ed) Proceedings of the IRMA International Conference
2004, IDEA Group Press
14. Harms U (2005) Stand der Entwicklung beim verteilten Rechnen.
IX – Magazin für professionelle Informationstechnik 2:93–95
15. Hentze J, Brose P (1985) Organisation. Verlag moderne industrie,
Landsberg am Lech
16. Howaldt J, Klatt R, Kopp R (2003) Interorganisationales Wissens-
management im Kontext wissensintensiver Dienstleistungen. In:
Katenkamp O, Peter G (eds) Die Praxis des Wissensmanagements.
LitVerlag, Münster, pp 169–195
17. Kieser A, Kubicek H (1992) Organisation, 3rd edn. de Gruyter,
Berlin
18. Kratzke N (2005) Automatisierte Ableitung von Personen-
und Organisations-bezogenem Ausbildungsbedarf mittels Modell-
basierter Verfahren. In: Haake J, Lucke U, Tavangarian D (Hrsg.)
Proceedings of DELFI2005. 3. Deutsche e-Learning Fachtagung
Informatik, 13.–16. September 2005, Universität Rostock, pp 459–
468
19. Kratzke N (2005) Ganzheitliche Entwicklungsbegleitung komple-
xer Waffensysteme der Marine. In: Proceedings der 35. Jahresta-
gung der Gesellschaft für Informatik. Springer
20. Nonaka I, Takeuchi H (2001) Organizational knowledge creation.
In: Henry J (ed) Creative Management, 2nd edn. SAGE, London,
pp 64–82
21. North K (1999) Wissensorientierte Unternehmensführung. Gabler,
Wiesbaden
22. Picot A, Reichwald R, Wigand R (2003) Die grenzenlose Unter-
nehmung, 5th edn. Gabler, Wiesbaden
23. Prahalad CK, Hamel G (1990) The Core Competence of the Cor-
poration. Harvard Business Review 68:79–91
24. Probst G (1992) Organisation. Verlag moderne industrie, Lands-
berg am Lech
208 Nane Kratzke
25. Probst G, Raub S, Romhardt K (1999) Wissen managen, 3rd edn.
Gabler, Wiesbaden
26. Remus U (2002) Prozeßorientiertes Wissensmanagement. PhD
thesis, Universität Regensburg
27. Remus U, Lehner F (2000) The Role of Process-oriented Enterprise
Modeling in Designing Process-oriented Knowledge Management
Systems. In: Proceedings of the AAAI Symposium on Bringing
Knowledge to Business Processes, pp 30–36
28. Senge PM (2001) Die fünfte Disziplin, 8th edn. Klett-Cota, Stutt-
gart
29. Stevens G, Wulf V (2001) Elektronische Archive in virtuellen Or-
ganisationen (1). Informatik Spektrum, pp 369–377
30. W3C (2000) Primer: Getting into RDF & Semantic Web using N3.
http://www.w3.org/2000/10/swap/Primer.html,
latest visit: 17.10.2004
Dipl.-Inform. Nane Kratzke hat
von 1996 bis 2000 an der Univer-
sität der Bundeswehr München In-
formatik studiert. Seit 2000 ist er
als Marine-Offizier mit der Entwick-
lung und Industrie-Begleitung bei
Rüstungsprojekten von Führungs-
waffen Einsatzsystemen am Kom-
mando Marineführungssysteme in
Wilhelmshaven tätig. Er promoviert
als externer Doktorand am Lehrstuhl
für Wirtschaftsinformatik und Elec-
tronic Government in Potsdam bei
Prof. Gronau.