Domänenspezifische Sprachen für betriebliche Abläufe - Vor- und Nachteile am Beispiel von BPMN


Seminararbeit, 2006

18 Seiten, Note: 1,3


Leseprobe


Inhaltsverzeichnis

1 Einleitung

2 Domänen, Domänenspezifische Sprachen und Modellieren

3 Das Domänenkonzept im Geschäftsprozessmanagement
3.1 Die Domänen des BPM
3.2 Die Domäne WFM im BPM
3.3 Spezifische Sprachen für WFMS

4 Business Process Management Notation (BPMN)
4.1 Überblick über die Sprachelemente
4.2 Beurteilung

5 Fazit

Literaturverzeichnis

1 Einleitung

Die zunehmende Vernetzung in der Wirtschaft macht eine dynamische Be­trachtung und Kontrolle von Unternehmen erforderlich. Die Nutzung von Geschäftsprozessmodellen kann diese dynamische Sichtweise unterstützen (s. Beitrag „Geschäftsprozessmodellierung“ dieser Seminarreihe).

Ziel der vorliegenden Arbeit ist es daher zu untersuchen, inwiefern domä­nenspezifische Sprachen einen Beitrag zur Vereinfachung des Managements betrieblicher Abläufe leisten können. Wo liegen die Chancen, aber auch die Nachteile bei der Verwendung dieses Sprachkonzepts in der Modellierung?

Das erste Kapitel dieser Arbeit beschäftigt sich zunächst mit den grundle­genden Eigenschaften domänenspezifischer Sprachen. Hierauf aufbauend geht das folgende Kapitel gezielt auf das Geschäftsprozessmanagement ein, wel­ches auf domänenspezifische Aspekte hin untersucht wird. Weiterhin werden allgemeine Anforderungen an eine entsprechend zu nutzende Modellierungs­sprache gestellt. Schließlich werden die aufgestellten Sprachkriterien auf ein Beispiel aus der Praxis, die graphische Modellierungssprache BPMN, bezo­gen. Ein letztes Kapitel wird die gewonnenen Ergebnisse zusammenfassen und die Arbeit in Form eines Fazits zum Abschluss bringen.

2 Domänen, Domänenspezifische Sprachen und Modellieren

Unter einer Domäne versteht [Wik01] ein abgrenzbares Fachgebiet. Das Ein­betten dieser abstrakten Definition in einen sachspezifischen Kontext macht eine Domäne fassbar. So kann zum Beispiel ein Unternehmen als Domäne in der Gesamtwirtschaft aufgefasst werden.

Basierend auf einer vorliegenden Domäne kann eine domänenspezifische Spra­che (DSL) entwickelt werden. Eine DSL definieren [DKV00, Kap. 2] allgemein als „... a programming language or executable specification language that offers, through appropriate notations and abstractions, ex­pressive power focused on, and usually restricted to, a particular problem domain.“

Wesentliche Charakteristika einer DSL sind also ihre Fokussierung auf die Zieldomäne sowie ihre Ausdrucksstärke und Eindeutigkeit. Dies kann auch am Konzept des „Language Level“([Jon96]) verdeutlicht werden, welches die Ausdrucksmächtigkeit von Programmiersprachen beschreibt. Hiernach ha­ben DSLs im allgemeinen ein höheres Level als generative Sprachen (General Purpose Language - GPL)[1] und sind dementsprechend mächtiger. Gerade diese Charakteristika machen den Einsatz einer DSL zu Modellierungszwe­cken reizvoll.

[Hol01] sieht als vorrangiges Ziel der Modellierung, eine im semiotischen Sinne eindeutige Beziehung zwischen Modell und Modellnutzer herzustellen. Zum einen soll sich ein Modell nur auf wesentliche Sachverhalte beziehen, was durch eine fokussierte Sicht auf den zu modellierenden Sachverhalt erreicht werden kann. Weiterhin bedarf es der Eindeutigkeit der verwendeten Begrif­fe, um eine sowohl semantisch als auch syntaktisch eindeutige Beziehung zu ermöglichen. Während jede beliebige in sich schlüssig aufgebaute und korrekt angewandte Sprache den syntaktischen Anforderungen genügt, kann gerade eine domänenspezifische Sprache die Zweckorientierung und die eindeutige Semantik des Modells unterstützen. Der Einsatz einer DSL als Modellie­rungstechnik ermöglicht es Domänenexperten, Modelle zu entwerfen, ohne auf technische Details eingehen zu müssen bzw. zu können. [DKV00] weisen weiterhin darauf hin, dass sich aus dem terminologischen Sprachkonzept her­aus eine hohe Selbstdokumentationsfähigkeit des Modells und eine erhöhte Produktivität in der Entwicklung und Kontrolle ergibt. Allerdings sehen sie durch den Einsatz einer DSL auch entstehende Nachteile. Diese ergeben sich vor allem durch erhöhte Kosten für die Entwicklung der Sprache selbst und das entsprechende Training von Mitarbeitern. Weitere Schwierigkeiten liegen in der Abgrenzung der relevanten Domäne und einer entsprechenden Balance zwischen domänenspezifischen und generischen Sprachelementen (vgl. auch [DeKa98]).

Einen Überblick über DSLs aus verschiedensten Domänen gibt [Wik02]. Auf­fällig ist hier, dass diese vor allem im Bereich der Informationstechnologie an­gesiedelt sind. Im Folgenden wird erörtert, inwiefern das Konzept einer DSL auch in dem wirtschaftsbezogenen Kontext der Entwicklung und Steuerung betrieblicher Abläufe Verwendung finden kann.

3 Das Domänenkonzept im Geschäftsprozess­management

Die genannten positiven Eigenschaften einer DSL können in der Modellbil­dung nur dann ausgenutzt werden, wenn der zu modellierende Sachverhalt, in diesem Fall ein betrieblicher Ablauf, domänenspezifische Aspekte aufweist und die DSL diese Aspekte abdecken kann (vgl. 2). Aus diesem Grund wird an dieser Stelle zunächst das Management von Geschäftsprozessen vorgestellt, um darin abgrenzbare Bereiche und damit Domänen aufzudecken.

3.1 Die Domänen des BPM

Zentraler Begriff des Geschäftsprozessmanagements (BPM) ist der Geschäftspro­zess. In der Literatur existiert keine eindeutige Definition, allerdings lassen sich einige wesentliche Aspekte aufzeigen. So schreibt [Gai04, Sp. 1212]

„Ein Prozess ist eine zeitlich und räumlich spezifisch strukturierte Menge von Aktivitäten mit einem Anfang und einem Ende sowie klar definierten Inputs und Outputs.“

Wichtiger Aspekt eines Geschäftsprozesses ist die Kundenorientierung. Während so genannte Kernprozesse zumeist auf externe Kunden ausgerichtet sind, sollen Subprozesse interne Kunden (wie z.B. auch andere Geschäftspro­zesse) bedienen ([Gai04, Sp. 1213]).

Innerhalb des BPM lassen sich verschiedene Domänen abgrenzen. So wird zwischen einem Geschäftsprozess als abstrakte Beschreibung der Aktivitäten eines Unternehmens und einem Workflow als Instanz eines Geschäftsprozesses mit dem Fokus auf dessen tatsächliche Ausführung unterschieden ([RuZu96, S. 5], [WMC95, S. 6], [RiSt04, S. 28]). Der Vorgang des Geschäftsprozessma­nagements wird über ein Geschäftsprozessmanagementsystem (BPMS) ge­steuert. [AHW03, S. 5] verstehen die Erstellung und die Anwendung eines BPMS als einen zyklischen Ablauf von Diagnose, Design, Konfiguration und Ausführung der Prozesse eines Unternehmens. Ein Workflow Management System (WFMS) übernimmt dabei den Aufgabenteil der Konfiguration und Ausführung. Es soll den betrieblichen Ablauf im Detail koordinieren und notwendige IT- und Humanressourcen automatisiert bereitstellen ([WMC95, S. 6]). Es kann Designelemente aufweisen, um Detaillösungen zu erstellen, ist jedoch nicht als Diagnosewerkzeug einzusetzen. Im optimalen Fall greifen Analyse- und Designkomponente sowie Konfigurations- und Ausführungs­komponente (also das WFMS) des BPMS nahtlos in einander. Allerdings muss aufgrund der verschiedenen Perspektiven der genutzten Modelle an den Schnittstellen eine Transformation in Bezug auf die Modellierungstech­nik, das Layout und den Modellfokus vorgenommen werden ([BRU00, S. 42 ff]). Diese Transformation ist notwendig, da auf der Ebene eines Workflows (im Gegensatz zur Ebene des Geschäftsprozesses) besonders der Gedanke der Automatisierbarkeit wesentlich ist ([RiSt04, S. 28]).

In der Geschäftsprozessmodellierung nimmt ein Modellierer eine eher unter­nehmensstrategische Position ein. Er benötigt folglich vor allem Experten­wissen im Bereich der Geschäftsführung des Unternehmens. Dagegen ist das Anforderungsprofil an den Modellierer eines WFMS wesentlich technischer. Es muss sich mehr mit Details der Arbeitsabläufe auseinander setzen als mit Fragestellungen des Toplevel Managements.

Die bisherigen Erörterungen haben gezeigt, dass mehrere Domänen inner­halb des BPM existieren. Der folgende Abschnitt befasst sich näher mit der eher technischen Domäne des Workflow Managements (WFM). Es werden Anforderungen an das WFMS diskutiert, woraus sich dann spezifische An­forderungen an die zu verwendende Modellierungstechnik ergeben.

3.2 Die Domäne WFM im BPM

Ziel eines WFMS ist die Koordination und Kontrolle der Workflows eines Unternehmens durch die Integration von vorhandenen Anwendungssystemen und Maschinen sowie die methodische Indoktrination der Mitarbeiter (vgl. auch Beitrag 13 dieser Seminarreihe). Das WFMS arbeitet somit, aus Sicht der drei Einsatzfaktoren (IT, Maschine und Mitarbeiter), auf einer Metae­bene. Während funktional orientierte IT-Anwendungen auf Daten zurück­greifen, Maschinen physische Ressourcen nutzen und Mitarbeiter sowohl Ap­plikationen als auch Maschinen verwenden, ist das WFMS für die Transi­tion zwischen den bearbeitenden Instanzen verantwortlich ([Müh03, S. 263 f], [RiSt04, S.138]). Es findet also ein Paradigmenwechsel von reiner Bear­beitung hin zur Steuerung statt. Das WFMS ist folglich auf einer Ebene zwischen dem abstraktem Geschäftsprozess und der letztendlichen Ausfüh­rung der notwendigen Aktivitäten angesiedelt.

Die Anforderungen an das WFMS resultieren somit zum einen aus der zie­lorientierten Struktur des zugrunde liegenden Geschäftsprozesses und zum anderen aus der technischen Vielfalt und Flexibilität, welche für die letztliche Abarbeitung der Arbeitsschritte notwendig sind. Die genaue Positionierung der Domäne des WFMS zwischen diesen beiden Extremen ist ein entschei­dender Faktor der Operabilität. Hier ergeben sich erstens die Frage nach den zu übernehmenden Aufgaben des WFMS und zweitens Überlegungen zu dem Detailgrad, in dem die gewählten Aufgaben modelliert und schließlich auto­matisiert werden sollen.

Während sich die allgemeine Aufgabe eines WFMS einfach erschließt, sind mögliche Teilaufgaben recht vielfältig. So kann das WFMS nach [RiSt04, S. 32] verschiedene Funktionen übernehmen, wie z.B.:

- die Verbesserung der Prozessabwicklung,
- Rationalisierung,
- Kontrolle,
- Verteilung des Arbeitsflusses und
- Implementierung und Aufrechterhaltung der ISO 9000[2].

Darüber hinaus nennt [Rei03, S. 32 ff.] noch:

- Mitarbeitertrainung und -einarbeitung,
- Simulation und Analyse,
- Dokumentation und
- Informationsmanagement (z.B. als Informationsplattform der Unter­nehmensführung).

Diese Vielzahl möglicher Aufgaben erfordert unterschiedlichste zu imple­mentierende Begriffe und Regeln des Modells. Während zum Beispiel Prozess­verbesserung und Rationalisierung eher einer Klassifikation der Resourcen bedürfen, sind für das Qualitätsmanagement modellierte Produkteigenschaf­ten relevant. Diese verschiedenen Aspekte müssen in der genutzten Modellie­rungstechnik begrifflich abgedeckt sein. Die unterschiedliche Positionierung des WFMS führt also auch zu verschiedenen Anforderungen an die Model­lierungssprache.

In der Frage nach der Detailtiefe des Modells und damit einhergehend nach dem daraus entstehenden WFMS betonen [BeKa03, S. 5] die Wichtigkeit sozialer Faktoren in Unternehmen.

[...]


[1] Man vergleiche in der Quelle zum Beispiel das Language Level der DSL HTML mit dem der generischen Sprache C

[2] Internationale Normen des Qualitätsmanagements von Unternehmen

Ende der Leseprobe aus 18 Seiten

Details

Titel
Domänenspezifische Sprachen für betriebliche Abläufe - Vor- und Nachteile am Beispiel von BPMN
Hochschule
Universität Bielefeld  (Fakultät für Wirtschaftswissenschaften)
Veranstaltung
Seminar zur Statistik/'Informatik - Grafische Modellbildung
Note
1,3
Autor
Jahr
2006
Seiten
18
Katalognummer
V70574
ISBN (eBook)
9783638695237
ISBN (Buch)
9783638769136
Dateigröße
490 KB
Sprache
Deutsch
Schlagworte
Domänenspezifische, Sprachen, Abläufe, Vor-, Nachteile, Beispiel, BPMN, Seminar, Statistik/, Informatik, Grafische, Modellbildung
Arbeit zitieren
Ludger Jußen (Autor:in), 2006, Domänenspezifische Sprachen für betriebliche Abläufe - Vor- und Nachteile am Beispiel von BPMN, München, GRIN Verlag, https://www.grin.com/document/70574

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Domänenspezifische Sprachen für betriebliche Abläufe -  Vor- und Nachteile am Beispiel von BPMN



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden