Konfliktäre Bezeichnungen in Ereignisgesteuerten Prozessketten -Linguistische Analyse und Vorschlag eines Lösungsansatzes PatrickDelfmann SebastianHerwig Łukasz Lis Westfälische Wilhelms Universität Münster European Research Center for Information Systems (ERCIS)
Leonardo-Campus 3 48149 Münster
Konfliktäre Bezeichnungen in Ereignisgesteuerten Prozessketten -Linguistische Analyse und Vorschlag eines Lösungsansatzes AAD937D158CBDB32AABDE19363E6EB07 GROBID - A machine learning software for extracting information from scholarly documents

Eine kritische Voraussetzung für den erfolgreichen Einsatz von fachkonzeptionellen Modellen ist ihre Verständlichkeit und Vergleichbarkeit. Modelladressaten müssen in die Lage versetzt werden, den mit den Modellen vermittelten Inhalt eindeutig zu erkennen. Dies impliziert das Vorhandensein eines gemeinsamen 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 Herausforderung dar. Ursache sind Benennungspraktiken in Prozessmodellen, die sich nicht in einfachen Ein-Wort-Bezeichnern, sondern ganzen Satzfragmenten für Aktivitäten, oder im speziellen Fall der EPK auch für Ereignisse, äußern. Der vorliegende Beitrag präsentiert die Ergebnisse einer Bezeichnungsanalyse von 4805 EPKs eines konkreten Modellierungsprojekts, die unter Nutzung expliziter Namenskonventionen erstellt wurden. Die Ergebnisse zeigen, dass die reine Existenz solcher Konventionen zur Sicherstellung der Modellverständlichkeit und -vergleichbarkeit von EPKs nicht ausreicht. Als Alternative wird ein linguistischer Ansatz vorgestellt, der die Bezeichnung mit Satzfragmenten explizit berücksichtigt, standardisiert und automatisiert durchsetzt.
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 adressieren [HS06]. In der Folge werden gleiche Sachverhalte von unterschiedlichen Modelladressaten ggf. unterschiedlich bewertet und umgekehrt. Dieses Phänomen wird allgemein als Namenskonflikt bezeichnet [BL84]. Im Extremfall können Namenskonflikte dazu führen, dass Modelle unbrauchbar werden. Zur Vermeidung von Namenskonflikten ist konsequenterweise ein einheitliches Begriffsverständnis bei der Gestaltung fachkonzeptioneller 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 Modellierungsprojekts entstanden sind, zu zeigen, wie diese sich speziell hinsichtlich ihrer Benennung darstellen, und in wieweit diese Benennungspraxis Namenskonflikte begünstigt. 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 Aufbau 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 alternativer Ansatz vorgestellt, der die Besonderheiten der Benennungspraxis in Prozessmodellen 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.

Analyse von Benennungspraktiken in EPKs

Als Vertreter fachkonzeptioneller Prozessmodellierungssprachen weisen EPKs eine besondere Herausforderung in Bezug auf die Benennung von Modellelementen auf. Dies äußert sich darin, dass bei der Benennung von Modellelementen wie bspw. Prozessfunktionen und -ereignisse weniger einzelne Begriffe als vielmehr ganze Satzphrasen Verwendung finden. Ausgehend von dieser Annahme wird nachfolgend anhand einer umfassenden Modellbasis aufgezeigt, wie eine derartige Form der Benennung insbesondere bei EPKs ausgestaltet ist und welche Implikationen sich hieraus in Bezug auf das Auftreten 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 Entstehung von Namenskonflikten. Zweitens wird ermittelt, wie die verwendeten Satzphrasen hinsichtlich ihrer Struktur variieren (z. B. <Verb, Imperativ> <Substantiv, Akkusativ> vs. <Substantiv, Akkusativ> <Verb, Infinitiv> als Bezeichner für Funktionen). Auch hier begünstigt eine hohe Variation der Strukturen Namenskonflikte. Der Konflikt "Rechnung 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)").

Datenbasis

Als Grundlage der explorativ angelegten Analyse von Bezeichnungspraktiken in Prozessmodellen dient eine Modellbasis, die im Rahmen eines umfangreichen, vier Monate dauernden Modellierungsprojekts einer großen deutschen öffentlichen Einrichtung entwickelt wurde. Als Zielstellung des Modellierungsprojekts galt es, eine umfassende Erhebung und Dokumentation des Istzustands der gesamten Prozesslandschaft dieser Einrichtung durchzuführen. Zu diesem Zweck wurde ein Gruppe von mehr als 50 Modellierern etabliert, welche der Systematisierung der Architektur integrierter Informationssysteme (ARIS) [Sc00] folgend Modelle der Daten-, Funktions-, Organisations-, Leistungsund insbesondere Prozesssicht entwickelte. Hierzu wurden Teilbereiche definiert, die verteilt von einzelnen Modellierern bearbeitet wurden. Als Modellierungsplattform wurde der ARIS Business Architect verwendet.

Für die Zwecke der Prozessmodellierung wurden neben der Modellierungstechnik der Wertschöpfungskettendiagramme maßgeblich EPKs verwendet. Einzelne Prozesse wurden 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 verwendende Begrifflichkeiten in Form eines Glossars als auch grammatikalische Benennungsstrukturen spezifiziert. Das Glossar enthielt die im betrachteten Modellierungsszenario gültigen Bezeichner sowie zur Explikation derer Semantik eine detaillierte Beschreibung. Die Bezeichner umfassten ausschließlich Fachbegriffe, d. h. die betriebswirtschaftlich relevanten Objekte wie z. B. "Rechnung", "Beleg", "Lager", "Teil", "Baugruppe" etc. Grammatikalische Bezeichnungsstrukturen, sogenannte Phrasenstrukturen, wurden mit dem Ziel vorgegeben, eine einheitliche Bezeichnerstruktur auch hinsichtlich der Satzsyntax sicherzustellen. Für Funktionen in EPKs wurde die grundlegende Phrasenstruktur <Substantiv, Akkusativ> <Verb, Infinitiv> und für Ereignisse <Substantiv, Nominativ> <konjugiertes Hilfsverb "sein"> <Verb, Partizip Perfekt> vorgegeben.

Die spezifizierten Namenskonventionen wurden allen Modellierern begleitend zum gesamten Prozess der Modellierung in Form eines textuellen Methodenhandbuchs, d. h. in nicht formalisierter Dokumentform, zur Verfügung gestellt. Vorgabe war es, die Konventionen 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 Modellelementen relativ zueinander sowie Syntaxkonventionen für die vereinheitlichte Verwendung von Modellelementtypen. Zu letzteren zählten bspw. eine Beschränkung zulässiger Ressourcentypen sowie eine Anpassung der Kontrollflusssyntax der EPK, die das Aussparen von Ereignissen fordert, welche innerhalb des Kontrollflusses zwei Funktionen direkt verbinden (sog. "Trivialereignisse").

Vorgehen bei der Analyse

Die im Rahmen des Modellierungsprojekts entwickelte Modellbasis liegt strukturiert als eine Modelldatenbank im ARIS Business Architect vor. Unter Verwendung einer Exportschnittstelle wurden die in den vorliegenden 4805 EPK-Modellen verwendeten Elementbezeichner von Prozessfunktionen (13935) und -ereignissen (13381) extrahiert und in strukturierter Form zur weiteren Analyse außerhalb der Modellierungsumgebung bereitgestellt.

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ühren. Exemplarisch kann die Phrase "Rechnung prüfen" auf die einzelnen Wortarten der beiden Wörter "Rechnung" und "prüfen" und somit auf ihre Struktur <Substantiv> <Verb> zurückgeführt werden. Im Rahmen der Analyse wurde das POS-Tagging-System TreeTagger [Sc94] verwendet.

Identifizierte Bezeichnungspraxis

Die Analyse hat u. a. gezeigt, dass zur Bezeichnung von Modellelementen in EPKs Satzstrukturen mit hauptsächlich 2-7 Wörtern bevorzugt werden (vgl. Abbildung 1).

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 Clusterungsoder 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 aufweisen. 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 generiert" 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 Überschneidung auf. Ein weiteres Beispiel liefern die Funktionen "Fakturastorno" und "Rechnungsstorno". Hier werden die synonymen Begriffe "Rechnung" und "Faktura" verwendet.

Für die einzelnen Bezeichnungen muss die Frage beantwortet werden, ob die mit semantischen Überschneidungen behafteten Begriffe tatsächlich das gleiche reale Objekt adressieren oder ob es sich hier um eine bewusst vorgenommene Unterscheidung handelt. Vor allem wenn das Modellieren verteilt erfolgt, werden solche Entscheidungen von den einzelnen Modellierern individuell getroffen, was trotz existierender Konventionen zu Inkonsistenzen führen kann.

Metainformationen

In

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 einzelwortbezogenen Ansätze an ihre Grenzen, da konfliktäre Bezeichner in Form von Satzstrukturen auf diese Weise kaum erkannt werden können. Die hier vorgestellten einzelwortbezogenen Ex-ante-Ansätze wurden zwar für Prozessmodelle entwickelt, betrachten jedoch innerhalb der Satzstrukturen der Bezeichner ausschließlich einzelne Begriffe. Es wird deshalb vorgeschlagen, Namenskonventionen formal zu spezifizieren und deren Umsetzung während des Modellierungsprozesses automatisiert sicherzustellen. Hierfür sind folgende methodische Komponenten notwendig:

Phrasenbezogene

• Ein Domänenlexikon, welches die in der Modellierungsdomäne erlaubten Begriffe enthält. Das Lexikon darf sich nicht auf Substantive beschränken, da auch Verrichtungen 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 Domänensemantik, weshalb ihre Spezifikation im Domänenlexikon nicht notwendig ist.

• Ein Repository, das die erlaubten Satzstrukturen definiert (z. B. <Substantiv, Akkusativ, Singular> <Verb, Partizip Perfekt> für ergebnisanzeigende Ereignisse).

• Ein Verfahren, das bei der Modellierung automatisiert die Konformität der eingegebenen Bezeichner mit den Namenskonventionen sicherstellt. • Elementtypverletzung: Phrasen, die keinen Ereignischarakter haben, aber als Bezeichner für Ereignisse verwendet werden, werden durch speziell für Ereignisse erstellte Phrasenstrukturkonventionen vermieden. Gleiches gilt für Funktionen.

• Phrasenstrukturinkonsistenz: Zur Vermeidung von Phrasenstrukturinkonsistenzen ist die Definition von semantisch äquivalenten Phrasenstrukturen zu vermeiden. Anstatt der beiden äquivalenten Strukturen <Substantiv> <Verb, Partizip Perfekt> und <Substantiv> <konjugiertes "sein"> <Verb, Partizip Perfekt> 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 vermeiden. 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 Begriffe betreffende Eingabefehler können größtenteils durch einen Abgleich mit dem Domänenlexikon und im Rahmen der Synonymsuche mit dem allgemeinen Lexikon erkannt werden.

Werkzeugunterstützung

Eine konkrete technische Umsetzung des hier vorgestellten Ansatzes liegt als Modellierungswerkzeug vor (vgl. Abbildung 4).

Abbildung 1 :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 gestaltete, umso diverser zeigten sich auch die verwendeten Phrasentypen (bspw. existierten 34 Ereignisse mit 10-Wort-Bezeichnern und entsprechend 33 unterschiedliche Phrasentypen). Bezeichnungen von Funktionen verhielten sich ähnlich.
Ansätze scheinen hier geeigneter, da sie die Bezeichnungspraktiken von EPKs explizit berücksichtigen können. Ex-post-Ansätze sind in der Lage, aufgetretene Namenskonflikte durch Gegenüberstellung der Modelle und Analyse ihrer Bezeichnungsstrukturen aufzulösen. Den Autoren erscheint die vorherige Vermeidung von Namenskonflikten allerdings zielführender, da dies eine aufwändige Analyse der fertiggestellten Modelle obsolet macht (freilich ist eine vorherige Vermeidung von Namenskonflikten nur dann möglich, wenn nicht bereits Modelle existieren). Die aufgeführten phrasenbezogenen Ex-ante-Ansätze bieten daher aus Sicht der Autoren eine vielversprechende Grundlage für die Formulierung eines Ansatzes zur Vermeidung von Namenskonflikten in EPKs. Die Ansätze von [Ro96; Ku00] erlauben die Formulierung von Phrasenstrukturen einerseits und Begriffskonventionen andererseits. Es fehlt allerdings 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 EPKs4.1 Konzeption des AnsatzesFür die Konstruktion eines Ansatzes zur Vermeidung von Namenskonflikten in Prozessmodellen 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 Empfehlungen, d. h. in Textform, vorliegen, werden nicht notwendigerweise umgesetzt.
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 Konventionen entspricht, sind dem Modellierer automatisch konventionskonforme Alternativbezeichner anzubieten (z. B. "Rechnung prüfen" anstatt der evtl. nicht konformen Bezeichnung "Faktura muss validiert werden"). Ob eine eingegebene Bezeichnung den Konventionen 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] vorgeschlagen wurden.
Abbildung 3 :Abbildung 3: Automatisches Vorschlagen valider Bezeichner
Abbildung 4 :5•Abbildung 4: Umsetzung des Ansatzes als Modellierungswerkzeug Der Modellierer wird durch Popup-Fenster auf etwaige Konventionsverletzungen hingewiesen und erhält konventionstreue Alternativvorschläge, die er akzeptiert, falls sie die von ihm intendierte Semantik wiedergeben. Falls die Vorschläge nicht passen, kann
1 1 1 2 Anzahl Modellelemente Anzahl Wörter Anzahl Wörter pro Bezeichnung Ereignisse FunktionenEreignisseFunktionenAnzahlAnzahl unterschiedlicherAnzahl unterschiedlicherWörterAnzahlStrukturenAnzahlStrukturen1266127642100922446640342711442799119430913302605286525555491394398612915668023997662445355273832725516814291079748441034331818115544123300Summe 133812455139351727Tabelle 1: Phrasenstrukturen der analysierten EPKs
Einzelwortbezogene Ex-ante-Ansätze AnsätzeBezeichnungen, 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-Die Kürzel XY und AA bezeichnen durch die Autoren anonymisierte vertrauliche Informationen). Im ersten Fall werden durch vorangestellte 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 Modellkontext und müssen nicht zusätzlich im inhaltlichen Teil der Bezeichnung spezifiziert werden. Gleichzeitig ist jedoch die vollständig äquivalente Struktur <Substantiv, Nominativ> <Verb, Partizip Perfekt> mit 725 Instanzen ebenfalls vertreten. Im gleichen Verhältnis befinden sich die Strukturen <Substantiv, Nominativ> <konjugiertes "sein"> <Adjektiv> (390 Bezeichnungen) und <Substantiv, Nominativ> <Adjektiv> (133 Bezeichnungen). Solche inkonsistente Phrasenstrukturen erschweren den Modellvergleich und die Modellanalyse maßgeblich, da aufwändige Homogenisierungsoperationen durchgeführt werden müssen.In einigen Fällen beschreiben Modellelementbezeichnungen nicht einen konkreten, abgegrenzten 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" 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 Element aufzuspalten und durch zwei mit einem Kontrollfluss verbundene Funktionen darzustellen.Das Problem der aggregierten Bezeichnungen ist auch bei den Ereignissen zu beobachten, 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 Vorliegen 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 Zustände, die jedoch nicht durch eine Konjunktion verbunden sind, sondern eher Alternativen 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]. , 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 Modellierungsprojekt oder eine Modellierungsdomäne gültigen Begriffe enthalten. Während der Modellierung 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. 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.Elementtypverletzung strukturen wie z. B. in Funktionen <Substantiv, Akkusativ> <Verb, Infinitiv>. In den dellen [KR98] abgelegt. Die Standardisierung der Satzstrukturen erfolgt durch textuellemeisten Fällen kann diese Phrasenstruktur nicht eingehalten werden, wie z. B. bereits im Empfehlung. Ein alternativer Ansatz definiert Geschäftsobjekte sowie Verrichtungen aufObwohl die EPK eine im Vergleich zu anderen Prozessmodellierungssprachen niedrige Fall der relativ wenig komplexen Bezeichnung "Fehlerhafte Rechnungen aussortieren". diesen Geschäftsobjekten und führt diese als Anweisungen in Prozessmodellen zusam-Anzahl von Elementtypen besitzt, weist die hier untersuchte Datenbasis einige Typver-Freilich ist die Vorgabe sämtlicher erlaubter Phrasenstrukturen schwierig, da nicht die men [NZ98].letzungen auf. So kann z. B. das Ereignis "siehe HP GesVers" genannt werden, dessen Strukturen sämtlicher wahrscheinlich genutzter Bezeichner vorhergesehen werden kön-Bezeichnung sicherlich keinen Prozesszustand beschreibt. Stattdessen wird hier vermut-lich auf einen Hauptprozess verwiesen. Des Weiteren zeigt das Beispiel der Funktion nen. Die Abwesenheit weiterer Phrasenstrukturen führt dann allerdings auch zu einem willkürlichen Gebrauch (vgl. Problembereich Phrasenstrukturinkonsistenz). Einzelwortbezogene Ex-post-Ansätze"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 Frühe Ansätze der 1980er und 1990er Jahre adressieren speziell das Problem der Daten-Die erfolgreiche Durchsetzung von Namenskonventionen erfordert offenbar keine zu-bankintegration und setzen in einem ersten Schritt bei der Integration der Datenbank-sätzliche Motivation der Modellierer, sondern deren Entlastung. Für die Realisierung ei-schemata an [BL84; BLN86; BKK91; LB01; RB01]. Diese Ansätze fokussieren Daten-ner solchen Entlastung wird vorgeschlagen, die Aktivitäten, die zur Einhaltung der Kon-modellierungssprachen, häufig insbesondere Dialekte des Entity-Relationship-Modells 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 (ERM [können. kurz vorgestellt werden.Der Grundhierfür ist sicherlich nicht in böswilliger Absicht zu suchen, sondern vielmehr in demUnvermö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 vorliegendenAggregierte Bezeichnungen 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-Phrasenbezogene Ex-ante-Ansätzelierer erstens äußerst aufwändig, zweitens ermüdend und drittens auch nicht der Qualifi-Phrasenbezogene Ex-ante-Ansätze wurden insbesondere in den 1990er Jahren entwickeltkation eines Modellierers entsprechend fordernd. Es wird vermutet, dass Modellierer und fordern neben einer Standardisierung der gültigen Domänenbegriffe auch eine Stan-nach einigen solchen Suchvorgängen schlichtweg resignieren und auf die Verwendung dardisierung der zur Benennung von einzelnen Modellelementen erlaubten Satzstruktu-der Konventionen verzichten. Umgekehrt verhält sich das Problem bei Phrasenstruktur-ren [Ro96; Ku00]. Die gültigen Begriffe werden dabei in sogenannten Fachbegriffsmo-konventionen. Diese beschränken sich im analysierten Fall auf grundlegende Phrasen-
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 grundsä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: bestehende 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 Modellierungsprojektes diskutiertes Szenario verweisen. In beiden Beispielen betreffen die besprochenen 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.:PhrasenstrukturinkonsistenzTrotz der Etablierung von Modellierungskonventionen in dem untersuchten Modellierungsprojekt ist es in der Datenbasis ersichtlich, dass für analoge Inhalte unterschiedliche Phrasenstrukturen verwendet wurden. Beispielsweise weisen die zwei Funktionen "Prüfen, ob Beschreibung notwendig ist" und "Prüfung auf vorhandenen Zugang" unterschiedliche Strukturen auf, obwohl sie analoge Inhalte der Prüfung einer Tatsache adressieren. Hingegen wäre es möglich, die verwendeten Phrasenstrukturen zu vereinheitlichen, ohne sie in ihrer inhaltlichen Ausdrucksstärke zu beschneiden. So kann beispielsweise 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 Entwicklungsplan an Mitarbeiter übermitteln" hervor. Im ersten Fall wird die Tätigkeit der Übermittlung durch ein Substantiv, im zweiten Fall durch ein Verb im Infinitiv dargestellt. 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 <Substantiv, Nomina-tiv> <konjugiertes "sein"> <Verb, Partizip Perfekt> (z. B. "Rechnung ist geprüft") ist in der Datenbasis 2230-mal vertreten.EingabefehlerIn 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 Projektteam 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 Bezeichnung 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 wiederum 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 AnalyseergebnisseDie Analyse zeigt, dass die Modelle trotz der zur Verfügung gestellten Modellierungskonventionen eine ganze Reihe von Benennungsschwächen enthalten. Die Konventionen wurden auf unterschiedliche Art und Weise und zudem sehr häufig verletzt.3 Lösungsbeiträge existenter ArbeitenIn der Vergangenheit ist eine ganze Reihe von Ansätzen entwickelt worden, die das Problem der mangelnden Vergleichbarkeit von Bezeichnungen in konzeptionellen Modellen 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 vornherein 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.Phrasenbezogene Ex-post-AnsätzePhrasenbezogene 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 semantische Beziehungen verbunden sind. So kann bspw. der Begriff "Rechnung" mit dem Begriff "prüfen" in Beziehung gesetzt werden, so dass bereits in der Ontologie ausgedrückt ist, dass Rechnungen geprüft werden können. Über diese Konzepte werden die Ähnlichkeitsbeziehungen zwischen Modellen hergestellt [Hö07; EKO07; Sa07].
User-friendly semantic annotation in business process modeling MBorn FDörr IWeber Proceedings of the International Workshop on Human-Friendly Service Description, Discovery and Matchmaking (Hf-SDDM 2007) at the 8 th International Conference on Web Information Systems Engineering MWeske M.-SHacid CGodart the International Workshop on Human-Friendly Service Description, Discovery and Matchmaking (Hf-SDDM 2007) at the 8 th International Conference on Web Information Systems Engineering
WISE; Nancy
 2007. 2007 Formalizing Linguistic Conventions for Conceptual Models JBecker PDelfmann SHerwig LLis AStein Proceedings of the 28 th International Conference on Conceptual Modeling (ER 2009) the 28 th International Conference on Conceptual Modeling (ER 2009)
Gramado, Brasilien
 2009 LNCS 5829 Unique Name Violations, a Problem for Model Integration or You Say Tomato, I Say Tomahto HKBhargava SOKimbrough RKrishnan ORSA Journal on Computing 3 1991 A Methodology for Data Schema Integration in the Entity Relationship Model CBatini MLenzerini IEEE Transactions on Software Engineering 10 6 1984 A Comparative Analysis of Methodologies for Database Schema Integration CBatini MLenzerini SBNavathe ACM Computing Surveys 18 4 1986 The Entity-Relationship Model -Toward a Unified View of Data PPChen -S ACM Transactions on Database Systems 1 1976 Unified Enterprise Knowledge Representation with Conceptual Models -Capturing Corporate Language in Naming Conventions PDelfmann SHerwig LLis Proceedings of the 30 th International Conference on Information Systems (ICIS 2009) the 30 th International Conference on Information Systems (ICIS 2009)
Phoenix, Arizona, USA
 2009 Measuring Similarity between Semantic Business Process Models MEhrig AKoschmider AOberweis Proceedings of the Fourth Asia-Pacific Conference on Conceptual Modelling (APCCM) the Fourth Asia-Pacific Conference on Conceptual Modelling (APCCM)
Ballarat
 2007. 2007 An ontology-driven process modeling framework GGreco AGuzzo LPontieri DSaccà Proceedings of the 15 th International Conference on Database and Expert Systems Applications (DEXA 2004) FGalindo MTakizawa RTraunmüller the 15 th International Conference on Database and Expert Systems Applications (DEXA 2004)
Zaragoza
 2004 A Translation Approach to Portable Ontology Specifications TRGruber Knowledge Acquisition 5 1993 Formal Ontology and Information Systems NGuarino Proceedings of the 1 st International Conference on Formal Ontologies in Information Systems NGuarino the 1 st International Conference on Formal Ontologies in Information Systems
Trento
 1998 Achieving business process model interoperability using metamodels and ontologies PHöfferer Proceedings of the 15 th European Conference on Information Systems (ECIS 2007) HÖsterle JSchelp RWinter the 15 th European Conference on Information Systems (ECIS 2007)
St. Gallen
 2007 Variations in conceptual modeling: classification and ontological analysis IHadar PSoffer Journal of the AIS 7 2006 Semantische Prozeßmodellierung auf der Grundlage "Ereignisgesteuerter Prozeßketten (EPK) GKeller MNüttgens A.-WScheer Veröffentlichungen des Instituts für Wirtschaftsinformatik Scheer, A.-W. 89 1992 Fachbegriffsmodellierung für betriebliche Informationssysteme und zur Unterstützung der Unternehmenskommunikation MKugeler MRosemann Informationssystem Architekturen. Fachausschuss 5 2 1998 der Gesellschaft für Informatik e. V. (GI) MKugeler Informationsmodellbasierte Organisationsgestaltung. Modellierungskonventionen und Referenzvorgehensmodell zur prozessorientierten Reorganisation
Ber-
 2000 Integrating Relational Database Schemas using a Standardized Dictionary RLawrence KBarker Proceedings of the 2001 ACM symposium on Applied computing (SAC) the 2001 ACM symposium on Applied computing (SAC)
Las Vegas
 2001 The Babel-System -An HPSG-Fragment for German, a Parser and a Dialog Component SMüller Proceedings of the 4 th International Conference on the Practical Application of Prolog the 4 th International Conference on the Practical Application of Prolog
London
 1996 Deutsche Syntax deklarativ -Head-Driven Phrase Structure Grammar für das Deutsche SMüller 1999 Tübingen Geschäftsprozeßmodellierung mit der objektorientierten Ereignisgesteuerten Prozeßkette (oEPK) MNüttgens VZimmermann Informationsmodellierung -Branchen, Software-und Vorgehensreferenzmodelle und Werkzeuge MMaicher H.-JScheruhn
Wiesbaden
 1998 Semantic Business Process Analysis -Building Block-based Construction of Automatically Analyzable Business Process Models DPfeiffer 2008 Münster A Survey of Approaches to Automatic Schema Matching ERahm PABernstein The International Journal on Very Large Data Bases 10 2001 MRosemann Komplexitätsmanagement in Prozeßmodellen. Methodenspezifische Gestaltungsempfehlungen für die Informationsmodellierung
Wiesbaden
 1996 A Relationship-Driven Framework for Model Merging MSabetzadeh SNejati SEasterbrook MChechik Workshop on Modeling in Software Engineering (Mi-SE'07) at the 29 th International Conference on Software Engineering
Minneapolis
 2007 A.-WScheer ARIS -Business Process Modelling
Berlin
 Auflage 2000 3 Probabilistic Part-of-Speech Tagging Using Decision Trees HSchmid Proceedings of the First International Conference on New Methods in Natural Language Processing the First International Conference on New Methods in Natural Language Processing
Manchester
 1994