=Paper=
{{Paper
|id=Vol-554/paper-11
|storemode=property
|title=Konfliktäre Bezeichnungen in Ereignisgesteuerten Prozessketten – Linguistische Analyse und Vorschlag eines Lösungsansatzes
|pdfUrl=https://ceur-ws.org/Vol-554/epk2009-paper11.pdf
|volume=Vol-554
}}
==Konfliktäre Bezeichnungen in Ereignisgesteuerten Prozessketten – Linguistische Analyse und Vorschlag eines Lösungsansatzes==
https://ceur-ws.org/Vol-554/epk2009-paper11.pdf
Konfliktäre Bezeichnungen
in Ereignisgesteuerten Prozessketten –
Linguistische Analyse und Vorschlag eines Lösungsansatzes
Patrick Delfmann, Sebastian Herwig, Łukasz Lis
Westfälische Wilhelms-Universität Münster
European Research Center for Information Systems (ERCIS)
Leonardo-Campus 3, 48149 Münster
{delfmann | herwig | lis}@ercis.uni-muenster.de
Abstract: Eine kritische Voraussetzung für den erfolgreichen Einsatz von fach-
konzeptionellen Modellen ist ihre Verständlichkeit und Vergleichbarkeit. Modell-
adressaten müssen in die Lage versetzt werden, den mit den Modellen vermittelten
Inhalt eindeutig zu erkennen. Dies impliziert das Vorhandensein eines gemeinsa-
men Begriffsverständnisses unter den Modellierern. Die Herstellung eines solchen
gemeinsamen Begriffsverständnisses stellt für Prozessmodelle im Allgemeinen
und Ereignisgesteuerte Prozessketten (EPK) im Speziellen eine besondere Heraus-
forderung dar. Ursache sind Benennungspraktiken in Prozessmodellen, die sich
nicht in einfachen Ein-Wort-Bezeichnern, sondern ganzen Satzfragmenten für Ak-
tivitäten, oder im speziellen Fall der EPK auch für Ereignisse, äußern. Der vorlie-
gende Beitrag präsentiert die Ergebnisse einer Bezeichnungsanalyse von 4805
EPKs eines konkreten Modellierungsprojekts, die unter Nutzung expliziter Na-
menskonventionen erstellt wurden. Die Ergebnisse zeigen, dass die reine Existenz
solcher Konventionen zur Sicherstellung der Modellverständlichkeit und -ver-
gleichbarkeit von EPKs nicht ausreicht. Als Alternative wird ein linguistischer An-
satz vorgestellt, der die Bezeichnung mit Satzfragmenten explizit berücksichtigt,
standardisiert und automatisiert durchsetzt.
1 Motivation
Eine notwendige Bedingung für die Nutzbarkeit von fachkonzeptionellen Modellen ist
nicht nur ihre syntaktische Korrektheit, sondern auch ihre semantische Vergleichbarkeit.
Letztere sicherzustellen ist ein äußerst ambitioniertes Unterfangen, wenn die Modelle
von unterschiedlichen Personen entwickelt werden. Dies ist allerdings häufig der Fall,
insbesondere im Rahmen umfänglicher Modellierungsvorhaben. Empirische Studien
zeigen, dass auf diese Weise entwickelte Modelle sich in ihren Bezeichnern erheblich
unterscheiden können, auch dann, wenn sie den gleichen Betrachtungsgegenstand adres-
sieren [HS06]. In der Folge werden gleiche Sachverhalte von unterschiedlichen Modell-
adressaten ggf. unterschiedlich bewertet und umgekehrt. Dieses Phänomen wird allge-
mein als Namenskonflikt bezeichnet [BL84]. Im Extremfall können Namenskonflikte
dazu führen, dass Modelle unbrauchbar werden. Zur Vermeidung von Namenskonflikten
178
ist konsequenterweise ein einheitliches Begriffsverständnis bei der Gestaltung fachkon-
zeptioneller Modelle unerlässlich.
Ziel dieses Beitrags ist es, anhand der Analyse einer umfassenden Modellbasis von 4805
Ereignisgesteuerten Prozessketten (EPK [KNS92]), die im Rahmen eines großen Model-
lierungsprojekts entstanden sind, zu zeigen, wie diese sich speziell hinsichtlich ihrer Be-
nennung darstellen, und in wieweit diese Benennungspraxis Namenskonflikte begüns-
tigt. Ausgehend von den Ergebnissen wird untersucht, welche Ansätze zur Lösung von
Namenskonflikten existieren, und ob diese sich zur Anwendung auf EPKs eignen.
Hierfür wird zunächst in Abschnitt 2 die verwendete Datenbasis vorgestellt und der Auf-
bau der Analyse detailliert erläutert. Die Analyseergebnisse werden bewertet, und es
werden Problembereiche von namenskonfliktauslösenden Bezeichnern identifiziert. In
Abschnitt 3 werden existente Ansätze dahingehend untersucht, ob sie in der Lage sind,
Namenskonflikte in EPKs aufzulösen oder zu verhindern. In Abschnitt 4 wird ein alter-
nativer Ansatz vorgestellt, der die Besonderheiten der Benennungspraxis in Prozessmo-
dellen im Allgemeinen und EPKs im Speziellen explizit berücksichtigt. Weiterhin wird
kurz erläutert, wie sich die in Abschnitt 2 identifizierten Probleme vermeiden lassen. Der
Beitrag schließt mit einem Fazit und einem Ausblick auf weiteren Forschungsbedarf in
Abschnitt 5.
2 Analyse von Benennungspraktiken in EPKs
Als Vertreter fachkonzeptioneller Prozessmodellierungssprachen weisen EPKs eine be-
sondere Herausforderung in Bezug auf die Benennung von Modellelementen auf. Dies
äußert sich darin, dass bei der Benennung von Modellelementen wie bspw. Prozessfunk-
tionen und -ereignisse weniger einzelne Begriffe als vielmehr ganze Satzphrasen Ver-
wendung finden. Ausgehend von dieser Annahme wird nachfolgend anhand einer um-
fassenden Modellbasis aufgezeigt, wie eine derartige Form der Benennung insbesondere
bei EPKs ausgestaltet ist und welche Implikationen sich hieraus in Bezug auf das Auf-
treten von Namenskonflikten abzeichnen. Speziell wird erstens untersucht, wie viele
Wörter im Durschnitt für die Bezeichnung eines Modellelements verwendet werden. Je
mehr Wörter in eine Bezeichnerphrase eingehen, desto größer ist die Gefahr der Entste-
hung von Namenskonflikten. Zweitens wird ermittelt, wie die verwendeten Satzphrasen
hinsichtlich ihrer Struktur variieren (z. B.
vs. als Bezeichner für Funktionen). Auch hier
begünstigt eine hohe Variation der Strukturen Namenskonflikte. Der Konflikt „Rech-
nung prüfen“ und „Prüfe Rechnung“ lässt sich bspw. nicht ohne weiteres automatisiert
auflösen. Drittens werden die Bezeichner hinsichtlich der verwendeten konkreten Wörter
untersucht. So kann z. B. die synonyme oder homonyme Verwendung von Einzelwörtern
ebenfalls zu Namenskonflikten führen (z. B. „Rechnung“ vs. „Faktura“ oder „Rechnung
(Beleg)“ vs. „Rechnung (Kalkulation)“).
179
2.1 Datenbasis
Als Grundlage der explorativ angelegten Analyse von Bezeichnungspraktiken in Pro-
zessmodellen dient eine Modellbasis, die im Rahmen eines umfangreichen, vier Monate
dauernden Modellierungsprojekts einer großen deutschen öffentlichen Einrichtung ent-
wickelt wurde. Als Zielstellung des Modellierungsprojekts galt es, eine umfassende Er-
hebung und Dokumentation des Istzustands der gesamten Prozesslandschaft dieser Ein-
richtung durchzuführen. Zu diesem Zweck wurde ein Gruppe von mehr als 50 Modellie-
rern etabliert, welche der Systematisierung der Architektur integrierter Informationssys-
teme (ARIS) [Sc00] folgend Modelle der Daten-, Funktions-, Organisations-, Leistungs-
und insbesondere Prozesssicht entwickelte. Hierzu wurden Teilbereiche definiert, die
verteilt von einzelnen Modellierern bearbeitet wurden. Als Modellierungsplattform wur-
de der ARIS Business Architect verwendet.
Für die Zwecke der Prozessmodellierung wurden neben der Modellierungstechnik der
Wertschöpfungskettendiagramme maßgeblich EPKs verwendet. Einzelne Prozesse wur-
den hierbei auf verschiedenen Abstraktionsebenen modelliert und über Hinterlegungen
miteinander verknüpft.
Zur Sicherung der Qualität und Vergleichbarkeit der Modelle wurden im Rahmen des
Modellierungsprojekts Namenskonventionen etabliert. Hierzu wurden in einem ersten
Schritt vor der Modellierung sowohl für die Benennung von Modellelementen zu ver-
wendende Begrifflichkeiten in Form eines Glossars als auch grammatikalische Benen-
nungsstrukturen spezifiziert. Das Glossar enthielt die im betrachteten Modellierungssze-
nario gültigen Bezeichner sowie zur Explikation derer Semantik eine detaillierte Be-
schreibung. Die Bezeichner umfassten ausschließlich Fachbegriffe, d. h. die betriebs-
wirtschaftlich relevanten Objekte wie z. B. „Rechnung“, „Beleg“, „Lager“, „Teil“,
„Baugruppe“ etc. Grammatikalische Bezeichnungsstrukturen, sogenannte Phrasenstruk-
turen, wurden mit dem Ziel vorgegeben, eine einheitliche Bezeichnerstruktur auch hin-
sichtlich der Satzsyntax sicherzustellen. Für Funktionen in EPKs wurde die grundle-
gende Phrasenstruktur und für Ereignisse
vor-
gegeben.
Die spezifizierten Namenskonventionen wurden allen Modellierern begleitend zum ge-
samten Prozess der Modellierung in Form eines textuellen Methodenhandbuchs, d. h. in
nicht formalisierter Dokumentform, zur Verfügung gestellt. Vorgabe war es, die Kon-
ventionen bei der Erstellung sämtlicher Modelle des Projekts einzuhalten.
Weitere Konventionen, die nicht die Benennung von Elementen adressieren, existierten
in Form von grafischen Regeln zur Vereinheitlichung der Anordnung von Modellele-
menten relativ zueinander sowie Syntaxkonventionen für die vereinheitlichte Verwen-
dung von Modellelementtypen. Zu letzteren zählten bspw. eine Beschränkung zulässiger
Ressourcentypen sowie eine Anpassung der Kontrollflusssyntax der EPK, die das Aus-
sparen von Ereignissen fordert, welche innerhalb des Kontrollflusses zwei Funktionen
direkt verbinden (sog. „Trivialereignisse“).
180
2.2 Vorgehen bei der Analyse
Die im Rahmen des Modellierungsprojekts entwickelte Modellbasis liegt strukturiert als
eine Modelldatenbank im ARIS Business Architect vor. Unter Verwendung einer Ex-
portschnittstelle wurden die in den vorliegenden 4805 EPK-Modellen verwendeten Ele-
mentbezeichner von Prozessfunktionen (13935) und -ereignissen (13381) extrahiert und
in strukturierter Form zur weiteren Analyse außerhalb der Modellierungsumgebung be-
reitgestellt.
Zur strukturellen Analyse der Bezeichner einzelner Modellelemente in EPKs wurde das
computerlinguistische Verfahren des Part-of-Speech (POS) Tagging verwendet. Mittels
POS Tagging ist es möglich, konkrete Wörter auf die zugehörige Wortart zurückzufüh-
ren. Exemplarisch kann die Phrase „Rechnung prüfen“ auf die einzelnen Wortarten der
beiden Wörter „Rechnung“ und „prüfen“ und somit auf ihre Struktur
zurückgeführt werden. Im Rahmen der Analyse wurde das POS-Tagging-Sys-
tem TreeTagger [Sc94] verwendet.
2.3 Identifizierte Bezeichnungspraxis
Die Analyse hat u. a. gezeigt, dass zur Bezeichnung von Modellelementen in EPKs Satz-
strukturen mit hauptsächlich 2-7 Wörtern bevorzugt werden (vgl. Abbildung 1).
Anzahl Wörter pro Bezeichnung
4500
4000
3500
Anzahl Modellelemente
3000
2500 Ereignisse
Funktionen
2000
1500
1000
500
0
1 2 3 4 5 6 7 8 9 10 11 12
Anzahl Wörter
Abbildung 1: Bezeichnungsstruktur der analysierten EPKs
Des Weiteren unterscheiden sich die Satzstrukturen selbst erheblich (vgl. Tabelle 1). So
wurden bspw. 1009 Ereignisse von insgesamt 13381 mit Bezeichnungen versehen, die
genau zwei Wörter enthalten. Trotz dieser geringen Komplexität der Bezeichnerphrasen
ergaben sich 22 unterschiedliche Phrasentypen. Je länger sich eine Bezeichnerphrase ge-
staltete, umso diverser zeigten sich auch die verwendeten Phrasentypen (bspw. existier-
ten 34 Ereignisse mit 10-Wort-Bezeichnern und entsprechend 33 unterschiedliche Phra-
sentypen). Bezeichnungen von Funktionen verhielten sich ähnlich.
181
Ereignisse Funktionen
Anzahl Anzahl unterschiedlicher Anzahl unterschiedlicher
Wörter Anzahl Strukturen Anzahl Strukturen
1 26 6 1276 4
2 1009 22 4466 40
3 4271 144 2799 119
4 3091 330 2605 286
5 2555 549 1394 398
6 1291 566 802 399
7 662 445 355 273
8 327 255 168 142
9 107 97 48 44
10 34 33 18 18
11 5 5 4 4
12 3 3 0 0
Summe 13381 2455 13935 1727
Tabelle 1: Phrasenstrukturen der analysierten EPKs
2.4 Identifizierte Problembereiche
Die große Anzahl von verwendeten unterschiedlichen Phrasenstrukturen stellt einen
Hinweis auf mögliche Inkonsistenzen in der Bezeichnung der Modellelemente dar. Um
diese vermuteten Probleme zu untersuchen, wurden im zweiten Schritt der Untersuchung
die einzelnen Bezeichnungen manuell analysiert und sechs Problembereiche festgestellt.
Diese werden im Folgenden anhand einiger ausgewählter Beispiele vorgestellt. Es sei
angemerkt, dass die Problembereiche nicht das Ergebnis eines spezifischen Clusterungs-
oder Klassifizierungsverfahrens sind, sondern vielmehr den Eindruck widerspiegeln, der
sich den Autoren im Rahmen der Analyse geboten hat.
Synonyme
In vielen Fällen werden Begriffe verwendet, die eine semantische Überschneidung auf-
weisen. Darüber hinaus werden durch einen inkonsequenten Einsatz von Abkürzungen
Mehrdeutigkeiten geschaffen, die nur schwer oder gar nicht auflösbar sind. Als Beispiel
können hier folgende drei Ereignisse genannt werden: „Dok erstellt“, „Dokument ist ge-
neriert“ und „Dokumentation ist unvollständig“. Es fällt auf, dass die Abkürzung „Dok“
sowohl zu dem Begriff „Dokument“ als auch „Dokumentation“ aufgelöst werden kann.
Ferner weisen die Begriffe „erstellen“ und „generieren“ eine semantische Überschnei-
dung auf. Ein weiteres Beispiel liefern die Funktionen „Fakturastorno“ und „Rechnungs-
storno“. Hier werden die synonymen Begriffe „Rechnung“ und „Faktura“ verwendet.
182
Für die einzelnen Bezeichnungen muss die Frage beantwortet werden, ob die mit se-
mantischen Überschneidungen behafteten Begriffe tatsächlich das gleiche reale Objekt
adressieren oder ob es sich hier um eine bewusst vorgenommene Unterscheidung han-
delt. Vor allem wenn das Modellieren verteilt erfolgt, werden solche Entscheidungen
von den einzelnen Modellierern individuell getroffen, was trotz existierender Konven-
tionen zu Inkonsistenzen führen kann.
Metainformationen
In Bezeichnungen, die in diesen Problembereich fallen, werden Informationen gepflegt,
die keinen Bezug zum faktischen Inhalt des Modellelements haben, sondern Angaben
über das Element selbst und dessen Stellung im Gesamtmodell liefern. Solche Informa-
tionen werden in diesem Kontext als Metainformationen bezeichnet. Als erstes Beispiel
kann das Ereignis „Bescheid erstellt PROZESSENDE“ genannt werden. In diesem Fall
wird eine zusätzlich Angabe gemacht, dass es sich um ein Endereignis des Prozesses
handelt. Diese Angabe hat jedoch mit der tatsächlichen Tätigkeit der Erstellung eines
Bescheids nichts zu tun. Solche nicht-inhaltliche Angaben sind in Bezeichnungen grund-
sätzlich unerwünscht und verursachen Probleme bei der Modellanalyse, da sie dort
zwangsweise als inhaltliche Information behandelt werden. Darüber hinaus können bei
einem Modellvergleich zwei Elemente, die die gleiche inhaltliche Bezeichnung tragen,
sich jedoch durch den Zusatz „PROZESSENDE“ unterscheiden, nicht automatisch als
inhaltlich äquivalent gekennzeichnet werden.
Weitere Beispiele liefern die Funktionen „Buchung von Transportmittel u. Unterkunft
(ausgelöst durch Bestätigung, s.o“ und „Katalogisierung durchführen (Szenario1: beste-
hende Orga-Struktur)“. Im ersten Fall werden Metainformationen angegeben, die unnö-
tigerweise das auslösende Ereignis (Bestätigung) nennen und mit dem Zusatz „s.o“ auf
dessen Position im dargestellten Prozessablauf hinweisen. Diese Metainformationen sind
hier überflüssig, weil sie sich zwangsweise aus dem formalen, durch den Prozessfluss
abgebildeten Teil des Modells bereits ergeben sollten. Im zweiten Fall beinhaltet die
Elementbezeichnung Metainformationen, die vermutlich auf ein im Rahmen des Model-
lierungsprojektes diskutiertes Szenario verweisen. In beiden Beispielen betreffen die be-
sprochenen problematischen Zusätze nicht den faktischen Inhalt des Modellelements.
In einigen Fällen werden solche Metainformationen in einer stark komprimierten Form
durch abgekürzte Zusätze dargestellt. Als Beispiele können hier die Funktion „XY_AA-
Mittelbedarf Infrastruktur ermitteln_ Mittelverteilung“ oder das Ereignis „Planung_XY
ist durchgeführt“ genannt werden (Anm.: Die Kürzel XY und AA bezeichnen durch die
Autoren anonymisierte vertrauliche Informationen). Im ersten Fall werden durch voran-
gestellte Zusätze Hinweise auf relevante Softwaremodule gegeben. Der nachgestellte
Zusatz verweist noch auf die hier wahrgenommene betriebswirtschaftliche Aufgabe oder
den übergeordneten Prozess. Im Fall des Ereignisses wird durch einen nachgestellten
Zusatz der Kontext der Planung weiter konkretisiert. In den beiden Beispielen ergeben
sich die Metainformationen bereits aus der Einbettung der Elemente in den Modellkon-
text und müssen nicht zusätzlich im inhaltlichen Teil der Bezeichnung spezifiziert wer-
den.
183
Elementtypverletzung
Obwohl die EPK eine im Vergleich zu anderen Prozessmodellierungssprachen niedrige
Anzahl von Elementtypen besitzt, weist die hier untersuchte Datenbasis einige Typver-
letzungen auf. So kann z. B. das Ereignis „siehe HP GesVers“ genannt werden, dessen
Bezeichnung sicherlich keinen Prozesszustand beschreibt. Stattdessen wird hier vermut-
lich auf einen Hauptprozess verwiesen. Des Weiteren zeigt das Beispiel der Funktion
„Internationale Meldung ist zu erstellen“, dass einige Funktionen offensichtlich Be-
zeichnungen tragen, die einen eindeutigen Ereignischarakter aufweisen.
Elementtypverletzungen bereiten Probleme beim Modellvergleich, da zwei Modellele-
mente, die eigentlich den gleichen faktischen Inhalt adressieren, fälschlicherweise einen
unterschiedlichen Typ besitzen und infolgedessen nicht als äquivalent erkannt werden
können.
Phrasenstrukturinkonsistenz
Trotz der Etablierung von Modellierungskonventionen in dem untersuchten Modellie-
rungsprojekt ist es in der Datenbasis ersichtlich, dass für analoge Inhalte unterschiedli-
che Phrasenstrukturen verwendet wurden. Beispielsweise weisen die zwei Funktionen
„Prüfen, ob Beschreibung notwendig ist“ und „Prüfung auf vorhandenen Zugang“ unter-
schiedliche Strukturen auf, obwohl sie analoge Inhalte der Prüfung einer Tatsache adres-
sieren. Hingegen wäre es möglich, die verwendeten Phrasenstrukturen zu vereinheitli-
chen, ohne sie in ihrer inhaltlichen Ausdrucksstärke zu beschneiden. So kann beispiels-
weise die Bezeichnung der zweiten Funktion mit „Prüfen, ob Zugang vorhanden ist“ in
die Struktur der ersten überführt werden. Ein ähnliches Problem rufen die Funktionen
„Übermittlung von XYZ-Informationen an Servicepartner“ und „Individuellen Ent-
wicklungsplan an Mitarbeiter übermitteln“ hervor. Im ersten Fall wird die Tätigkeit der
Übermittlung durch ein Substantiv, im zweiten Fall durch ein Verb im Infinitiv darge-
stellt. Auch hier wäre eine konsequente Verwendung einer Struktur möglich.
Auch bei den Ereignissen ist eine inkonsistente Benutzung analoger Phrasenstrukturen
zu beobachten. Die für resultierende Ereignisse typische Struktur (z. B. „Rechnung ist geprüft“) ist in
der Datenbasis 2230-mal vertreten. Gleichzeitig ist jedoch die vollständig äquivalente
Struktur mit 725 Instanzen ebenfalls
vertreten. Im gleichen Verhältnis befinden sich die Strukturen
(390 Bezeichnungen) und
(133 Bezeichnungen). Solche inkonsistente Phrasenstrukturen erschweren
den Modellvergleich und die Modellanalyse maßgeblich, da aufwändige Homogeni-
sierungsoperationen durchgeführt werden müssen.
Aggregierte Bezeichnungen
In einigen Fällen beschreiben Modellelementbezeichnungen nicht einen konkreten, ab-
gegrenzten Inhalt, sondern aggregieren gleichzeitig mehrere Inhalte. In dem Fall von
Funktionen werden mehrere Tätigkeiten in einem Element dargestellt. Als Beispiel kann
die Bezeichnung „Bemerkungen einarbeiten und Schlussfassung an Abt X weiterleiten“
184
genannt werden. Hier werden zwei Aktivitäten in einer Funktion zusammengefasst. Um
den atomaren Charakter der Funktionen zu bewahren, wäre es zweckmäßig, dieses Ele-
ment aufzuspalten und durch zwei mit einem Kontrollfluss verbundene Funktionen dar-
zustellen.
Das Problem der aggregierten Bezeichnungen ist auch bei den Ereignissen zu beobach-
ten, wie das Beispiel „Ausl. XYZ zuständig: Einzelner Antrag liegt vor, vorl. VersNr
nicht notwendig“ zeigt. Hier werden sogar drei Zustände (die Zuständigkeit, das Vorlie-
gen eines Antrags und keine Notwendigkeit einer Nummer) in einem Modellelement
aggregiert. Dabei bietet der EPK-eigene UND-Operator die Möglichkeit, den gleichen
Inhalt durch drei Ereignisse darzustellen. Ein weiteres Beispiel „Arbeitsplatz/Kapazität
iat angelegt/geändert“ demonstriert wiederum das Problem mehrerer aggregierter Zu-
stände, die jedoch nicht durch eine Konjunktion verbunden sind, sondern eher Alternati-
ven darstellen. Solche aggregierte Elementbezeichnungen verursachen Schwierigkeiten
beim Modellvergleich, da ein Abstraktionskonflikt entsteht. Dieser kommt zustande,
wenn in zwei Modellen der gleiche faktische Inhalt mit einer unterschiedlichen Anzahl
von Modellelementen repräsentiert wird [Pf08].
Eingabefehler
In der Datenbasis sind außerdem einige fehlerhafte Bezeichnungen zu beobachten, die
vermutlich infolge von Fehlern bei der Eingabe entstanden sind. Als Beispiele können
hier die Ereignisse „Personen, Positionen oder Organisationseinheiten zu einem Pro-
jektteam für e“, „Equipment Ein-, Ausund Umbau“ sowie die bereits erwähnte Funktion
„Arbeitsplatz/Kapazität iat angelegt/geändert“ genannt werden. Im ersten Fall ist die Be-
zeichnung offensichtlich nicht vollständig. Beim zweiten Ereignis fehlt ein Leerzeichen,
wodurch ein in der deutschen Sprache nicht existierendes Wort „Ausund“ zustande
kommt. Bei der Funktion wurde das Verb „ist“ falsch geschrieben, infolgedessen wiede-
rum ein unbekanntes Wort „iat“ entstanden ist. Obwohl solche Eingabefehler oft trivial
sind, stellen sie trotzdem ein ernstes Problem im Rahmen des Modellvergleichs dar.
2.5 Interpretation der Analyseergebnisse
Die Analyse zeigt, dass die Modelle trotz der zur Verfügung gestellten Modellierungs-
konventionen eine ganze Reihe von Benennungsschwächen enthalten. Die Konventionen
wurden auf unterschiedliche Art und Weise und zudem sehr häufig verletzt. Der Grund
hierfür ist sicherlich nicht in böswilliger Absicht zu suchen, sondern vielmehr in dem
Unvermögen, die Konventionen umzusetzen. Letzteres ist wohl auch nicht in mangeln-
der Qualifikation der Modellierer begründet, sondern im schlichten Umfang der Model-
lierungskonventionen. Unternehmensglossare umfassen meist – so auch im vorliegenden
Fall – mehrere hundert bis über tausend Begriffe. Ohne jegliche methodische Unterstüt-
zung ist die Auffindung eines geeigneten Begriffs in einer solchen Fülle für den Model-
lierer erstens äußerst aufwändig, zweitens ermüdend und drittens auch nicht der Qualifi-
kation eines Modellierers entsprechend fordernd. Es wird vermutet, dass Modellierer
nach einigen solchen Suchvorgängen schlichtweg resignieren und auf die Verwendung
der Konventionen verzichten. Umgekehrt verhält sich das Problem bei Phrasenstruktur-
konventionen. Diese beschränken sich im analysierten Fall auf grundlegende Phrasen-
185
strukturen wie z. B. in Funktionen . In den
meisten Fällen kann diese Phrasenstruktur nicht eingehalten werden, wie z. B. bereits im
Fall der relativ wenig komplexen Bezeichnung „Fehlerhafte Rechnungen aussortieren“.
Freilich ist die Vorgabe sämtlicher erlaubter Phrasenstrukturen schwierig, da nicht die
Strukturen sämtlicher wahrscheinlich genutzter Bezeichner vorhergesehen werden kön-
nen. Die Abwesenheit weiterer Phrasenstrukturen führt dann allerdings auch zu einem
willkürlichen Gebrauch (vgl. Problembereich Phrasenstrukturinkonsistenz).
Die erfolgreiche Durchsetzung von Namenskonventionen erfordert offenbar keine zu-
sätzliche Motivation der Modellierer, sondern deren Entlastung. Für die Realisierung ei-
ner solchen Entlastung wird vorgeschlagen, die Aktivitäten, die zur Einhaltung der Kon-
ventionen notwendig sind, so weit wie möglich zu automatisieren. Der dazu vorgeschla-
gene Ansatz unterscheidet sich grundlegend von existenten Ansätzen, die im Folgenden
kurz vorgestellt werden.
3 Lösungsbeiträge existenter Arbeiten
In der Vergangenheit ist eine ganze Reihe von Ansätzen entwickelt worden, die das
Problem der mangelnden Vergleichbarkeit von Bezeichnungen in konzeptionellen Mo-
dellen adressieren. Diese lassen sich durch zwei Dimensionen klassifizieren. Die erste
Dimension unterteilt die Ansätze in Ex-ante- und Ex-post-Ansätze: Einerseits werden
Verfahren vorgeschlagen mit dem Ziel, das Auftreten konfliktärer Bezeichner von vorn-
herein zu verhindern. Andererseits werden existierende Modelle untersucht, konfliktäre
Bezeichner identifiziert und diese durch entsprechende Verfahren aufgelöst. Die zweite
Dimension klassifiziert die Ansätze nach der Struktur der betrachteten Bezeichner. Zum
Einen werden ausschließlich einzelne Wörter als Bezeichner zugelassen, zum Anderen
werden Satzstrukturen, d. h. Phrasen, analysiert.
Einzelwortbezogene Ex-ante-Ansätze
Ansätze, deren Ziel es ist, konfliktäre Bezeichner bereits im Vorfeld zu vermeiden,
schlagen sogenannte Namenskonventionen vor. Namenskonventionen werden i. A. in
Form von Glossaren oder auch Ontologien spezifiziert, die die für ein Modellierungs-
projekt oder eine Modellierungsdomäne gültigen Begriffe enthalten. Während der Mo-
dellierung werden diese Vorgaben genutzt, um konventionsgerechte Modelle zu erstellen
und so konfliktäre Bezeichner zu vermeiden. Entsprechende Ansätze werden bspw. von
[Gr04; BDW07] für Prozessmodelle vorgeschlagen.
Phrasenbezogene Ex-ante-Ansätze
Phrasenbezogene Ex-ante-Ansätze wurden insbesondere in den 1990er Jahren entwickelt
und fordern neben einer Standardisierung der gültigen Domänenbegriffe auch eine Stan-
dardisierung der zur Benennung von einzelnen Modellelementen erlaubten Satzstruktu-
ren [Ro96; Ku00]. Die gültigen Begriffe werden dabei in sogenannten Fachbegriffsmo-
186
dellen [KR98] abgelegt. Die Standardisierung der Satzstrukturen erfolgt durch textuelle
Empfehlung. Ein alternativer Ansatz definiert Geschäftsobjekte sowie Verrichtungen auf
diesen Geschäftsobjekten und führt diese als Anweisungen in Prozessmodellen zusam-
men [NZ98].
Einzelwortbezogene Ex-post-Ansätze
Frühe Ansätze der 1980er und 1990er Jahre adressieren speziell das Problem der Daten-
bankintegration und setzen in einem ersten Schritt bei der Integration der Datenbank-
schemata an [BL84; BLN86; BKK91; LB01; RB01]. Diese Ansätze fokussieren Daten-
modellierungssprachen, häufig insbesondere Dialekte des Entity-Relationship-Modells
(ERM [Ch76]). Durch den Vergleich von Bezeichnungen der Schemaelemente werden
Ähnlichkeiten identifiziert, wobei betont wird, dass ein solcher Vergleich ausschließlich
manuell unter Einbeziehung der Schemakonstrukteure erfolgen kann.
Phrasenbezogene Ex-post-Ansätze
Phrasenbezogene Ex-post-Ansätze untersuchen nicht einzelne Wörter als Bezeichner von
Modellelementen, sondern sogenannte Konzepte. Konzepte umfassen mehrere Domä-
nenbegriffe, die üblicherweise in Ontologien [Gr93; Gu98] abgelegt sind und durch se-
mantische Beziehungen verbunden sind. So kann bspw. der Begriff „Rechnung“ mit dem
Begriff „prüfen“ in Beziehung gesetzt werden, so dass bereits in der Ontologie ausge-
drückt ist, dass Rechnungen geprüft werden können. Über diese Konzepte werden die
Ähnlichkeitsbeziehungen zwischen Modellen hergestellt [Hö07; EKO07; Sa07].
Abgrenzung des vorliegenden Ansatzes
Grundsätzlich lassen sich alle vorgestellten Ansätze zur Herstellung der Vergleichbarkeit
konzeptioneller Modelle anwenden. Speziell für EPKs stoßen jedoch die einzelwortbe-
zogenen Ansätze an ihre Grenzen, da konfliktäre Bezeichner in Form von Satzstrukturen
auf diese Weise kaum erkannt werden können. Die hier vorgestellten einzelwortbezoge-
nen Ex-ante-Ansätze wurden zwar für Prozessmodelle entwickelt, betrachten jedoch in-
nerhalb der Satzstrukturen der Bezeichner ausschließlich einzelne Begriffe.
Phrasenbezogene Ansätze scheinen hier geeigneter, da sie die Bezeichnungspraktiken
von EPKs explizit berücksichtigen können. Ex-post-Ansätze sind in der Lage, aufgetre-
tene Namenskonflikte durch Gegenüberstellung der Modelle und Analyse ihrer Bezeich-
nungsstrukturen aufzulösen. Den Autoren erscheint die vorherige Vermeidung von Na-
menskonflikten allerdings zielführender, da dies eine aufwändige Analyse der fertigge-
stellten Modelle obsolet macht (freilich ist eine vorherige Vermeidung von Namenskon-
flikten nur dann möglich, wenn nicht bereits Modelle existieren). Die aufgeführten phra-
senbezogenen Ex-ante-Ansätze bieten daher aus Sicht der Autoren eine vielverspre-
chende Grundlage für die Formulierung eines Ansatzes zur Vermeidung von Namens-
konflikten in EPKs. Die Ansätze von [Ro96; Ku00] erlauben die Formulierung von
Phrasenstrukturen einerseits und Begriffskonventionen andererseits. Es fehlt allerdings
187
eine Formalisierung, die für eine automatisierte Durchsetzung von Namenskonventionen
notwendig ist. Letztere ist für den Erfolg von Namenskonventionen kritisch, wie die
Analyse in Abschnitt 2 zeigt. Der Ansatz von [NZ98] ist formalisiert, betrachtet jedoch
die Ausgestaltung der Bezeichnerphrasen sehr eingeschränkt auf wenige vorgegebene
Fälle.
Der vorliegende Ansatz ist durch
• die explizite Berücksichtigung von Satzfragmenten als Modellelementbezeichner,
• seine Formalisierung und
• die hierdurch automatisierbare Sicherstellung der konventionstreuen Modellierung
von existenten Ansätzen abzugrenzen.
4 Ein Ansatz zur Vermeidung von Namenskonflikten in EPKs
4.1 Konzeption des Ansatzes
Für die Konstruktion eines Ansatzes zur Vermeidung von Namenskonflikten in Pro-
zessmodellen wird die Idee der Namenskonventionen, wie sie in den 1990er Jahren von
ROSEMANN vorgeschlagen wurde, wieder aufgegriffen. Die Analyse der EPK-Datenbasis
zeigt, dass die alleinige Existenz solcher Namenskonventionen keinesfalls dazu führt,
dass Namenskonflikte ausbleiben. Namenskonventionen, die lediglich als Empfehlun-
gen, d. h. in Textform, vorliegen, werden nicht notwendigerweise umgesetzt.
Es wird deshalb vorgeschlagen, Namenskonventionen formal zu spezifizieren und deren
Umsetzung während des Modellierungsprozesses automatisiert sicherzustellen. Hierfür
sind folgende methodische Komponenten notwendig:
• Ein Domänenlexikon, welches die in der Modellierungsdomäne erlaubten Begriffe
enthält. Das Lexikon darf sich nicht auf Substantive beschränken, da auch Verrich-
tungen und Eigenschaften Teil einer Domäne sein können. Das Lexikon ist daher für
Substantive, Verben und Adjektive/Adverbien zu konzipieren. Sämtliche übrigen
Wortformen (z. B. Artikel, Konjunktionen, Präpositionen etc.) enthalten keine Do-
mänensemantik, weshalb ihre Spezifikation im Domänenlexikon nicht notwendig ist.
• Ein Repository, das die erlaubten Satzstrukturen definiert (z. B. für ergebnisanzeigende Ereignisse).
• Ein Verfahren, das bei der Modellierung automatisiert die Konformität der eingege-
benen Bezeichner mit den Namenskonventionen sicherstellt.
Durch „Einsetzen“ der im Domänenlexikon spezifizierten Begriffe in die im Repository
spezifizierten Satzstrukturen ergeben sich mögliche den Namenskonventionen entspre-
chende Bezeichnungen für Modellelemente. Ein derartiges „Einsetzen“ von Begriffen in
Satzschablonen wird durch ein entsprechendes Verfahren bei der Modellierung sicherge-
188
stellt. Je angelegtem Modellelement werden die validen Satzstrukturen ausgewählt und
mit validen Begriffen „gefüllt“ (vgl. Abbildung 2; vgl. zu einer detaillierten formalen
Spezifikation des Ansatzes [Be09; DHL09]).
Abbildung 2: Nutzung formalisierter Namenskonventionen
Aus Effizienzgründen sollte es allerdings möglich sein, eine Modellelementbezeichnung
wie gewohnt als Freitext einzugeben. Falls eine solche Eingabe dann nicht den Konven-
tionen entspricht, sind dem Modellierer automatisch konventionskonforme Alternativbe-
zeichner anzubieten (z. B. „Rechnung prüfen“ anstatt der evtl. nicht konformen Bezeich-
nung „Faktura muss validiert werden“). Ob eine eingegebene Bezeichnung den Konven-
tionen entspricht, wird durch ein Verfahren ermittelt, das den Bezeichner sowohl auf
verwendete Begriffe als auch auf die verwendete Satzstruktur analysiert. Hierfür werden
linguistische Parsingmethoden verwendet, wie sie bspw. von Müller [Mu96; Mu99] vor-
geschlagen wurden.
Konkret wird jede Eingabe des Modellierers durch einen entsprechenden Parser in ihre
Bestandteile, d. h. ihre Satzstruktur und die Grundformen der verwendeten Wörter (sog.
„Lexeme“) zerlegt (vgl. Abbildung 3; (1)). Die Lexeme des Typs Substantiv, Adjek-
tiv/Adverb und Verb werden auf Konformität gegenüber dem Domänenlexikon geprüft
(2). Entsprechen ein oder mehrere Lexeme nicht den Konventionen, wird mittels eines
allgemeinen Lexikons geprüft, ob die Lexeme durch synonyme, valide Gegenstücke er-
setzt werden können (3). Die validen Begriffe werden in mögliche Phrasenstrukturen
eingesetzt und dem Modellierer als valide Alternative vorgeschlagen (4). So werden
bspw. aus der nicht konventionskonformen Phrase „Falsche Fakturen werden ermittelt“
die korrekten Phrasen „Inkorrekte Rechnungen ermitteln“ oder „Rechnungen ermitteln“.
Aus diesen kann der Modellierer wählen oder eine neue Bezeichnung eingeben (vgl. zu
einer detaillierten formalen Spezifikation dieses Verfahrens nochmals [Be09; DHL09].
Zur algorithmischen Spezifikation des Vorschlagswesens vgl. ausführlich [DHL09]).
189
Abbildung 3: Automatisches Vorschlagen valider Bezeichner
4.2 Lösung identifizierter Probleme
Die im Abschnitt 2.4 ermittelten Probleme lassen sich mithilfe des vorgestellten Ansat-
zes wie folgt vermeiden:
• Synonyme: Im Domänenbegriffsmodell sind die zu verwendenden Begriffe eindeutig
spezifiziert. Bei Verwendung eines Synonyms wird dieses den Konventionen ent-
sprechend durch den validen Begriff ausgetauscht. Synonymprobleme sind hiermit
ex-ante ausgeschlossen.
• Metainformationen: Die Namenskonflikte, die sich durch Metainformationen erge-
ben werden in zweierlei Hinsicht verhindert. Zum Einen befinden sich Begriffe, die
nicht Teil der Domäne sind, nicht im Domänenlexikon und können deswegen auch
nicht verwendet werden. Die Verwendung von Begriffen wie z. B. „Prozessende“
oder „Planung_XY“ wird dadurch vermieden. Zum Anderen erlauben sinnvolle
Phrasenstrukturen für EPKs zumeist kein Voranstellen oder Nachstellen entspre-
chender Metainformation. Hierfür wäre bspw. die direkte Folge zweier Substantive
erforderlich.
• Elementtypverletzung: Phrasen, die keinen Ereignischarakter haben, aber als Be-
zeichner für Ereignisse verwendet werden, werden durch speziell für Ereignisse er-
stellte Phrasenstrukturkonventionen vermieden. Gleiches gilt für Funktionen.
• Phrasenstrukturinkonsistenz: Zur Vermeidung von Phrasenstrukturinkonsistenzen
ist die Definition von semantisch äquivalenten Phrasenstrukturen zu vermeiden. An-
statt der beiden äquivalenten Strukturen und
190
ist eine dieser beiden
zu wählen und als Standard festzulegen.
• Aggregierte Bezeichnungen: Aggregierte Bezeichnungen konnektieren mehrere
Phrasen. Solche Multiphrasen sind bei der Spezifikation der Konventionen zu ver-
meiden. Stattdessen wird der Modellierer dazu angehalten, entsprechend mehrere
Elemente anzulegen und diese mit den Operatoren zu verknüpfen.
• Eingabefehler: Eingabefehler, die ganze Phrasen betreffen (bspw. abbrechende
Phrasen) werden durch die Phrasenstrukturkonventionen abgefangen. Einzelne Be-
griffe betreffende Eingabefehler können größtenteils durch einen Abgleich mit dem
Domänenlexikon und im Rahmen der Synonymsuche mit dem allgemeinen Lexikon
erkannt werden.
4.3 Werkzeugunterstützung
Eine konkrete technische Umsetzung des hier vorgestellten Ansatzes liegt als Modellie-
rungswerkzeug vor (vgl. Abbildung 4).
Abbildung 4: Umsetzung des Ansatzes als Modellierungswerkzeug
Der Modellierer wird durch Popup-Fenster auf etwaige Konventionsverletzungen hin-
gewiesen und erhält konventionstreue Alternativvorschläge, die er akzeptiert, falls sie
die von ihm intendierte Semantik wiedergeben. Falls die Vorschläge nicht passen, kann
191
der Modellierer entscheiden, ob er erneut eine Bezeichnung eingibt oder eine Anfrage an
den Administrator des Modellierungswerkzeugs (idealerweise ein Modellierungsexperte;
vgl. hierzu [DHL09]) stellt, neue Bezeichner bzw. Phrasentypen mit in die Konventionen
aufzunehmen.
5 Fazit und Ausblick
Die linguistische Analyse der EPKs hat gezeigt, dass informal spezifizierte Namenskon-
ventionen für die Sicherstellung einer einheitlichen Benennung von Modellelementen
nicht ausreichen. Des Weiteren reicht es nicht aus, die Standardisierung von Bezeich-
nungen auf einzelne Begriffe zu beschränken. Mit dem vorgestellten Ansatz werden
Namenskonventionen formalisiert, wobei zwei Aspekte wesentlich sind:
• Mit der Bereitstellung von Bezeichnungskonventionen bereits im Vorfeld der Model-
lierung wird die Grundlage dafür gelegt, dass Namenskonflikte erst gar nicht auftre-
ten. Da die Semantik der Bezeichnungen bereits im Vorfeld bekannt ist und diese
ausschließlich in bekannte Phrasenstrukturen eingeordnet werden, entfällt ein auf-
wändiger nachträglicher Bezeichnungsabgleich.
• Die automatisierte Anleitung des Modellierers während der Modellerstellung ist von
nicht zu unterschätzender Bedeutung, da nur auf diese Weise garantiert werden kann,
dass die Bezeichnungskonventionen auch umgesetzt werden.
Die Spezifikation von Begriffs- und Phrasenstrukturkonventionen ist freilich mit einem
nicht geringen Aufwand verbunden. Dem entgegen steht die Tatsache, dass diese Spezi-
fikation je Modellierungsprojekt, Unternehmen oder Domäne lediglich einmalig zu er-
folgen hat und in der Folge wiederverwendbar ist. Hier liegen auch die Grenzen des An-
satzes, der nur dann Anwendung finden kann, wenn
• die formalisierten Modellierungskonventionen sämtlichen am Modellierungsprozess
beteiligten Personen zugänglich gemacht werden können und
• es sich um ein Modellierungsprojekt handelt, das keine bzw. nur eine überschaubare
Anzahl bereits existenter Modelle in den Modellierungsprozess mit einbeziehen
muss.
Induziert durch letztere Beschränkung könnte dem Ansatz entgegengehalten werden,
seine Anwendbarkeit beschränke sich auf einige wenige Ausnahmefälle. Nach Meinung
der Autoren käme allerdings eine derart begründete Verwerfung des Ansatzes einer Re-
signation ob des Vergleichbarkeitsproblems von Modellen gleich. Bestehen solche Pro-
bleme, sind sie im Nachgang der Modellierung nur mit äußerst hohem Aufwand wieder
zu beheben. Eine breite Durchsetzung des Ansatzes in allen Bereichen der Modellierung
ist aber sicherlich erst längerfristig möglich. Zudem existieren Situationen, in denen be-
reits im Unternehmen vorhandene IST-Modelle, die mit anderen bzw. neuen Modellen
abzugleichen sind, von neu zu konstruierenden SOLL-Modellen abgelöst werden. Dies
ist etwa im Rahmen von Reorganisations- oder auch von sog. „Mergers & Akquisi-
192
tions“-Projekten der Fall. Auch hier liegt ein vielversprechendes Anwendungsgebiet des
vorgestellten Ansatzes.
Weitere Forschungsfelder eröffnen sich zukünftig in der konkreten Anwendung des vor-
gestellten Ansatzes. Hier ist zu untersuchen, wie die Anwendung die Geschwindigkeit
der Modellerstellung beeinflusst und bis zu welchem Grad die Vergleichbarkeit von
Modellen gesteigert werden kann. Weiterhin ist zu überprüfen, ob und wie der Ansatz
durch Modellierer akzeptiert wird, die durch die automatisierte Durchsetzung von Mo-
dellierungskonventionen in ihren Modellierungsfreiheiten beschränkt werden. Erste Er-
fahrungen mit der werkzeuggestützten Anwendung des Ansatzes lassen allerdings ver-
muten, dass eine automatisierte Anleitung zur Erfüllung von Modellierungskonventionen
von den betroffenen Personen eher begrüßt als abgelehnt wird. Auch die Antwortzeiten
des implementierten Verfahrens zur Durchsetzung der Modellierungskonventionen be-
wegten sich bisher in einem durch die Modellierer nicht wahrnehmbaren Rahmen.
Literaturverzeichnis
[BDW07] Born, M.; Dörr, F.; Weber, I.: User-friendly semantic annotation in business process
modeling. In: Weske, M.; Hacid, M.-S.; Godart, C. (Hrag.): Proceedings of the Inter-
national Workshop on Human-Friendly Service Description, Discovery and
Matchmaking (Hf-SDDM 2007) at the 8th International Conference on Web Informa-
tion Systems Engineering (WISE 2007). Nancy 2007, S. 260-271.
[Be09] Becker, J.; Delfmann, P.; Herwig, S.; Lis, L.; Stein, A.: Formalizing Linguistic Con-
ventions for Conceptual Models. In: Proceedings of the 28th International Conference
on Conceptual Modeling (ER 2009). LNCS 5829. Gramado, Brasilien 2009, S. 70-83.
[BKK91] Bhargava, H. K., Kimbrough, S. O., Krishnan, R.: Unique Name Violations, a Problem
for Model Integration or You Say Tomato, I Say Tomahto. ORSA Journal on Compu-
ting 3 (1991) 2, S. 107-120.
[BL84] Batini, C., Lenzerini, M.: A Methodology for Data Schema Integration in the Entity
Relationship Model. IEEE Transactions on Software Engineering 10 (1984) 6, S. 650-
663.
[BLN86] Batini, C., Lenzerini, M., Navathe, S. B.: A Comparative Analysis of Methodologies
for Database Schema Integration. ACM Computing Surveys 18 (1986) 4, S. 323–364.
[Ch76] Chen, P. P.-S.: The Entity-Relationship Model – Toward a Unified View of Data.
ACM Transactions on Database Systems 1 (1976) 1, S. S. 9-36.
[DHL09] Delfmann, P.; Herwig, S.; Lis, L.: Unified Enterprise Knowledge Representation with
Conceptual Models – Capturing Corporate Language in Naming Conventions. In:
Proceedings of the 30th International Conference on Information Systems (ICIS 2009).
Phoenix, Arizona, USA, 2009.
[EKO07] Ehrig, M., Koschmider, A., Oberweis, A.: Measuring Similarity between Semantic Bu-
siness Process Models. In: Proceedings of the Fourth Asia-Pacific Conference on
Conceptual Modelling (APCCM) 2007. Ballarat 2007.
[Gr04] Greco, G.; Guzzo, A.; Pontieri, L.; Saccà, D.: An ontology-driven process modeling
framework. In: Galindo, F.; Takizawa, M.; Traunmüller, R. (Hrsg.): Proceedings of the
15th International Conference on Database and Expert Systems Applications (DEXA
2004). Zaragoza 2004, S. 13-23.
[Gr93] Gruber, T. R.: A Translation Approach to Portable Ontology Specifications. Knowl-
edge Acquisition 5 (1993) 2, S. 199-220.
193
[Gu98] Guarino, N.: Formal Ontology and Information Systems. In: Guarino, N. (Hrsg.): Pro-
ceedings of the 1st International Conference on Formal Ontologies in Information Sys-
tems. Trento 1998, S. 3-15.
[Hö07] Höfferer, P.: Achieving business process model interoperability using metamodels and
ontologies. In: Österle, H.; Schelp, J.; Winter, R. (Hrsg.): Proceedings of the 15th Euro-
pean Conference on Information Systems (ECIS 2007). St. Gallen 2007, S. 1620-1631.
[HS06] Hadar, I., Soffer, P.: Variations in conceptual modeling: classification and ontological
analysis. Journal of the AIS 7 (2006) 8, S. 568-592.
[KNS92] Keller, G., Nüttgens, M., Scheer, A.-W.: Semantische Prozeßmodellierung auf der
Grundlage „Ereignisgesteuerter Prozeßketten (EPK)“. In: Scheer, A.-W. (Hrsg.): Ver-
öffentlichungen des Instituts für Wirtschaftsinformatik, Heft 89. Saarbrücken 1992.
[KR98] Kugeler M., Rosemann, M.: Fachbegriffsmodellierung für betriebliche Informations-
systeme und zur Unterstützung der Unternehmenskommunikation. In: Informations-
system Architekturen. Fachausschuss 5.2 der Gesellschaft für Informatik e. V. (GI), 5
(1998) 2, S. 8-15.
[Ku00] Kugeler, M.: Informationsmodellbasierte Organisationsgestaltung. Modellierungskon-
ventionen und Referenzvorgehensmodell zur prozessorientierten Reorganisation, Ber-
lin 2000.
[LB01] Lawrence, R., Barker, K.: Integrating Relational Database Schemas using a Standar-
dized Dictionary. In: Proceedings of the 2001 ACM symposium on Applied computing
(SAC). Las Vegas 2001.
[Mu96] Müller, S.: The Babel-System – An HPSG-Fragment for German, a Parser and a Dia-
log Component. In: Proceedings of the 4th International Conference on the Practical
Application of Prolog. London 1996.
[Mu99] Müller, S.: Deutsche Syntax deklarativ – Head-Driven Phrase Structure Grammar für
das Deutsche. Tübingen 1999.
[NZ98] Nüttgens, M.; Zimmermann, V.: Geschäftsprozeßmodellierung mit der objektorientier-
ten Ereignisgesteuerten Prozeßkette (oEPK). In: Maicher, M.; Scheruhn, H.-J. (Hrsg.):
Informationsmodellierung – Branchen, Software- und Vorgehensreferenzmodelle und
Werkzeuge. Wiesbaden 1998, S. 23-36.
[Pf08] Pfeiffer, D.: Semantic Business Process Analysis – Building Block-based Construction
of Automatically Analyzable Business Process Models. Münster 2008.
[RB01] Rahm, E.; Bernstein, P. A.: A Survey of Approaches to Automatic Schema Matching.
The International Journal on Very Large Data Bases 10 (2001) 4, S. 334-350.
[Ro96] Rosemann, M.: Komplexitätsmanagement in Prozeßmodellen. Methodenspezifische
Gestaltungsempfehlungen für die Informationsmodellierung, Wiesbaden 1996.
[Sa07] Sabetzadeh, M.; Nejati, S.; Easterbrook, S.; Chechik, M.: A Relationship-Driven Fra-
mework for Model Merging. Workshop on Modeling in Software Engineering (Mi-
SE'07) at the 29th International Conference on Software Engineering, Minneapolis
2007.
[Sc00] Scheer, A.-W.: ARIS – Business Process Modelling. 3. Auflage, Berlin 2000.
[Sc94] Schmid, H: Probabilistic Part-of-Speech Tagging Using Decision Trees. In: Procee-
dings of the First International Conference on New Methods in Natural Language Pro-
cessing. Manchester 1994, S. 44-49.
194