Pro und Contra objektorientierter Geschäftsprozessmodellierung

Objektorientierung


Ausarbeitung, 2016
15 Seiten, Note: 2.0

Leseprobe

Inhaltsverzeichnis

Einführung

1. Definition und Ziele der Geschäftsprozessmodellierung

2. Geschäftsprozessmodelle und der Übergang zur Softwareentwicklung

3. Grundlagen der Objektorientierung

4. Die objektorientierte Modellierungssprache UML
4.1 Anwendungsfalldiagramm
4.2 Aktivitätsdiagramm

5. Pro und Kontra der objektorientierten Geschäftsprozessmodellierung mit UML

6. Fazit

7. Literaturverzeichnis

8. Abbildungsverzeichnis

9. Tabellenverzeichnis

Einführung

Immer häufiger richten sich Unternehmen prozessoriertiert aus, d.h. sie gliedern ihren Betrieb in eine Abfolge genau definierter Geschäftsprozesse, die in einem komplexen System miteinander verwebt sind. Um diese zahlreichen Prozesse effizient verwalten zu können, sind einheitliche Standards für deren Definition und Darstellung unabdingbar. Hinzu kommt die zunehmende Digitalisierung von unternehmensinternen und –externen Abläufen, die oft maßgeschneiderte Software-Lösungen erfordert. Damit diese Software die Vorgänge der realen Welt anforderungsgetreu abbildet und unterstützt, muss der jeweilige Geschäftsprozess modelliert werden. Jedoch kommt es hierbei oft zu Missverständnissen zwischen Prozessmanagern und Software-Entwicklern, weil sie bezüglich der Modellierung von Prozessen nicht die gleiche Sprache sprechen und unterschiedliche Prioritäten setzen. Die vorliegende Arbeit stellt die Geschäftsprozessmodellierung vor, um darauf aufbauend die Brücke zur Softwareentwicklung zu schlagen. Dabei sollen vor allem die Anwendung standardisierter Modellierungssprachen sowie die Vor- und Nachteile der gängigen objektorientierten Modellierung diskutiert werden. Zuletzt wird das Fazit der Analyse vorgestellt.

1. Definition und Ziele der Geschäftsprozessmodellierung

Um die Modellierung von Geschäftsprozessen im Unternehmen umsetzen zu können, ist eine genaue Definition von Prozessen notwendig. Diese bildet die Basis dafür, die abzubildenden Geschäftsprozesse zu identifizieren.

Generell wird ein Prozess als eine Abfolge von Aufgaben oder Aktivitäten verstanden, die zeitlich und logisch aufeinander aufbauen und dazu dienen, ein betriebswirtschaftlich relevantes Objekt zu bearbeiten[1]. Dazu ist in aller Regel Input in Form von Leistungen des Prozesslieferanten nötig, wodurch andererseits Leistungen an Prozesskunden als Output abgegeben werden[2]. Ein Geschäftsprozess ist ein spezieller Prozess, „der der Erfüllung der obersten Ziele der Unternehmung dient und das zentrale Geschäftsfeld beschreibt“[3]. Ein wesentliches Charakteristikum sind hierbei die Schnittstellen zu Marktpartnern des Unternehmens[4]. Typische Geschäftsprozesse sind zum Beispiel die Auftragsabwicklung eines produzierenden Unternehmens oder die Kreditvergabe einer Bank.

Die Geschäftsprozessmodellierung ist Teil des Prozessmanagements, und „umfasst sämtliche Aktivitäten der Konstruktion, Anwendung und Wartung von Geschäftsprozessmodellen“[5]. Zumeist, aber nicht notwendigerweise, ergänzt eine grafische Darstellung das Modell[6]. Die Geschäftsprozessmodellierung ermöglicht es, Prozesse im Unternehmen zu beschreiben, im Kontext darzustellen und zu analysieren. Dadurch können mögliche Verbesserungspotentiale genutzt, Schwachstellen ausgeglichen und Prozesse an veränderte ökonomische, juristische oder organisatorische Rahmenbedingungen angepasst werden.

2. Geschäftsprozessmodelle und der Übergang zur Softwareentwicklung

Seit den 1990er-Jahren wurden verschiedene Ansätze zur systematischen Modellierung von Prozessen entwickelt. Besonders erfolgreich sind dabei grafische Methoden, welche sich drei Kategorien zuordnen lassen:

Datenorientierte Ansätze: Bei diesen Diagrammen werden nicht die einzelnen Prozessschritte dargestellt, sondern sie illustrieren den Datenfluss im Verlauf der einzelnen Aktivitäten. Sie finden nur noch selten Anwendung.

Kontrollflussorientierte Ansätze: Diese Modelle stellen die Abfolge der Tätigkeiten dar, fokussieren sich also auf den Prozess.

Objektorientierte Ansätze: Die Objektorientierung basiert auf Konzepten aus der Softwareentwicklung. Dabei werden Funktionen und Daten als Objekte zusammengefasst.[7]

Die folgende Grafik zeigt einen Überblick die wichtigsten Methoden der drei Kategorien:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Überblick über die wichtigsten Prozessmodellierungsmethoden[8]

Um festzulegen, welche Methode die geeignete ist, müssen Aspekte wie die Zielgruppe, die Verbreitung, sowie die gewünschte Komplexität berücksichtigt werden. In der vorliegenden Arbeit liegt der Fokus auf den objektorientierten Ansätzen, da diese sich besonders gut als Basis für die Softwareentwicklung eignen. Denn in der Praxis wird oft „im Rahmen der Anforderungsanalyse für ein Softwareentwicklungsprojekt eine begrenzte Geschäftsprozessmodellierung betrieben, um den Kontext des zu entwickelnden Systems zu analysieren. Im umgekehrten Fall werden Softwareentwicklungsprojekte aus einer Geschäftsprozessmodellierung abgeleitet, um Teilprozesse durch Automatisierung zu optimieren.“[9]

3. Grundlagen der Objektorientierung

Die objektorientierte Modellierung greift „Grundkonzepte objektorientierter Programmiersprachen wie Ada, Simula und Smalltalk auf“[10]. Wichtig sind vor allem die folgenden Konzepte:

Objekte: Sowohl konkrete Gegenstände (z.B. Auto, Person, Telefon) als auch abstrakte Gegenstände (z.B. Rechnung, Konto, Terminvereinbarung) können als Objekte verstanden werden. Dem jeweiligen Objekt werden bestimmte Eigenschaften zugeordnet, beim Objekt Auto könnten dies beispielsweise die Eigenschaften „Hubraum“ oder „Höchstgeschwindigkeit“ sein. Desweiteren bietet ein Objekt verschiedene Dienste – auch Methoden oder Operationen genannt – an. Beim Auto wären die Dienste „Licht einschalten“ oder „Gas geben“ denkbar.

Klasse: In einer Klasse werden Objekte mit ähnlichen Eigenschaften und Diensten zusammengefasst. Dadurch ist es bei Objekten derselben Klasse nur einmal erforderlich, deren Eigenschaften und Dienste zu beschreiben.

Nachrichten: Zur Interaktion zwischen verschiedenen Objekten werden Nachrichten versandt. Eine bestimmte Nachricht löst beim Empfängerobjekt die entsprechende Operation aus.

Vererbung: Zwischen verschiedenen Klassen kann es Vererbungsbeziehungen geben, d.h. der untergeordneten Klasse werden die Eigenschaften und Dienste der übergeordneten Klasse zugeschrieben, sie können wahlweise auch erweitert oder überschrieben werden.

Polymorphismus: Gleiche Nachrichtentypen können mittels des Polymorphismus je nach Kontext verschieden interpretiert werden. So kann beispielsweise der gleiche Nachrichtentyp bei Objekten verschiedener Klassen unterschiedliche Konsequenzen auslösen.[11]

4. Die objektorientierte Modellierungssprache UML

Bereits Anfang der 1990er-Jahre gab es eine Reihe objektorientierter Programmiersprachen und Modellierungstechniken[12]. Aus drei dieser Ansätze[13] entwickelte sich 1996 die Unified Modeling Language (UML), die heute den weltweit dominierenden Standard[14] der objektorientierten Modellierung darstellt. Sie wird von der Object Management Group (OMG), einem internationalen Konsortium für die Entwicklung von Technologiestandards, verwaltet und weiterentwickelt[15]. Die zur Zeit aktuelle Version UML 2.5 stellt eine einheitliche Modellierungssprache dar, beinhaltet aber keinen Leitfaden zur Entwicklung eines Anwendungssystems, und ist keine Programmiersprache. Die Grundidee der UML ist die modellhafte Abbildung von Zuständen und Vorgängen der Realität:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Grundidee der Unified Modeling Language[16]

Mithilfe der UML 2 lassen sich 13 verschiedene Diagrammtypen erstellen, die drei Kategorien zugeordnet werden (s. Abbildung 3). Jeder Diagrammtyp setzt verschiedene Schwerpunkte, und eignet sich dementsprechend mehr oder weniger für bestimmte Anwendungsfelder. Wie aus Abbildung 1 hervorgeht, empfehlen sich für die Geschäftsprozessmodellierung besonders das Anwendungsfalldiagramm und das Aktivitätsdiagramm.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Übersicht über die verschiedenen Diagrammtypen der UML 2[17]

4.1 Anwendungsfalldiagramm

Das Anwendungsfalldiagramm, oft auch als Use-Case-Diagramm bezeichnet, beschreibt das Verhalten eines Systems aus Sicht des zukünftigen Nutzers[18]. Das zu betrachtende System wird klar abgegrenzt, um dann die Akteure, Anwendungsfälle und ihre Beziehungen zueinander darzustellen. Die folgende Tabelle zeigt, wie die einzelnen Notationselemente dargestellt werden:

Abbildung in dieser eseprobe nicht enthalten

Tabelle 1: Notationselemente beim Anwendungsfalldiagramm[19]

Die folgende Darstellung zeigt den Prozess „Kundenanfragebearbeitung“ als Anwendungsfalldiagramm:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: “Kundenanfragebearbeitung” dargestellt als Anwendungsfalldiagramm[20]

4.2 Aktivitätsdiagramm

Mit einem Aktivitätsdiagramm kann ein Geschäftsprozess als eine Abfolge von Aktivitäten in Verbindung mit Kontroll- und Datenflüssen dargestellt werden[21]. Das Hauptaugenmerk liegt auf dem Prozess, der in einzelne Aktionen zerlegt wird. Die wichtigsten Notationselemente sind in der folgenden Tabelle aufgeführt:

Abbildung in dieser eseprobe nicht enthalten

Tabelle 2: Die wichtigsten Notationselemente beim Aktivitätsdiagramm[22]

Dementsprechend kann das Aktivitätsdiagramm des Vorgangs „KFZ reservieren“ folgendermaßen aussehen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Aktivitätsdiagramm des Vorgangs “KFZ reservieren”[23]

5. Pro und Kontra der objektorientierten Geschäftsprozessmodellierung mit UML

Aus den vorangegangenen Kapiteln erschließt sich, dass die Geschäftsprozessmodellierung im Rahmen des Prozessmanagements und die Softwareanforderungsanalyse ähnliche Ziele verfolgen. Beide Aktivitäten beschäftigen sich überwiegend mit der „Analyse und Beschreibung von Anforderungen und Abläufen“[24]. Vor allem, wenn Geschäftsprozesse mit dem Ziel modelliert werden, darauf aufbauend ein passendes Anwendungssystem zu entwickeln, liegt die Verwendung von Modellierungswerkzeugen, die auf Konzepten der Softwareentwicklung basieren, nahe. Denn „der Bruch zwischen Geschäfts- und Softwaremodellierung lässt sich vermeiden, wenn auf beiden Seiten die gleichen oder verlustfrei abbildbare semantische Konstrukte verwendet werden, also idealerweise eine standardisierte Sprache“[25]. Genau an dieser Stelle kommt die Unified Modeling Language ins Spiel, denn sie stellt eine einheitliche Modellierungssprache dar, deren Konzepte, Methoden und Notationselemente für alle Aktivitäten von der Konzeption bis zur Implementierung verwendet werden können. Dennoch ist die objektorientierte Geschäftsprozessmodellierung mit UML nicht ohne Hürden. Da die Objektorientierung vor allem auf Konzepten der Softwareentwicklung basiert, ist diese Technik bei der Geschäftsprozessmodellierung von geringer Relevanz. Viele Diagrammtypen werden in der Praxis kaum genutzt[26], weil sie Prozesse nur in abstrahierter Form abbilden und daher schwer verständlich sind. Auch müssen Prozessmanager im Umgang mit UML oftmals erst geschult werden. Darüber hinaus bietet UML für viele Anforderungen der Geschäftsprozessmodellierung, beispielsweise Geschäftsregeln und Organisationsstruktur, (noch) kein adäquates Standardinstrument, sie müssen mit anderen Methoden umschrieben werden.[27] Häufig eignen sich daher andere Prozessmodellierungsmethoden, beispielsweise kontrollflussorientierte Konzepte, besser für das Vorhaben – vor allem, wenn die Entwicklung eines Anwendungssystems für den Prozess oder Teile davon nicht beabsichtigt wird. Nicht zuletzt ist UML eine Modellierungssprache, aber keine Programmiersprache. Für die Umsetzung von Modell zu Software müssen die UML-Modelle also in eine entsprechende Programmiersprache, beispielsweise Java, übersetzt werden. Da UML aber eng an die Programmiersprachen angelehnt ist, können „semantisch gleiche Modellinformationen in den unterschiedlichen Disziplinen durchaus unterschiedlich repräsentiert werden“[28], ohne zu Missverständnissen zu führen. Auf Grund der weiten Verbreitung und der Standardisierung von UML ist die Verwendung vor allem in international agierenden Konzernen von besonderem Vorteil.

6. Fazit

Objektorientierte Geschäftsprozessmodellierung ist im Hinblick auf die zunehmende Softwareunterstützung von Abläufen ein immer wichtigeres Thema. Wenn von Anfang bis Ende, von Konzeption bis Implementierung, dieselbe Sprache gesprochen wird, können Verständigungsprobleme vermieden und somit Zeit und Geld gespart werden. Der Schluss liegt nahe, eine weltweit standardisierte Modellierungssprache zu verwenden, die beide Enden optimal verknüpft. Mit der Unified Modeling Language steht ein Werkzeug zur Verfügung, das diesen Anspruch erfüllen will. Obwohl UML nicht für alle Sachverhalte und Anwendungsszenarien die geeignete Wahl ist, bietet sie doch umfassende Einsatzmöglichkeiten im Bereich der objektorientierten Geschäftsprozessmodellierung. Da sie der permanenten Überprüfung und Weiterentwicklung unterliegt, dürfte sie in Zukunft noch an Bedeutung zunehmen – nicht zuletzt, weil Alternativen mit ähnlichen Vorteilen zur Zeit nicht verfügbar sind.

7. Literaturverzeichnis

1) Becker, J., Kugeler, M., Rosemann, M.: Prozessmanagement: ein Leitfaden zur prozessoptimierten Organisationsgestaltung. Springer Berlin 2005.
2) Dandl, J.: Objektorientierte Prozeßmodellierung mit der UML und EPK. Arbeitspapiere WI Nr. 12/1999. Johannes Gutenberg-Universität Mainz.
3) Gadatsch, A.: Geschäftsprozesse analysieren und optimieren. Praxistools zur Analyse, Optimierung und Controlling von Arbeitsabläufen. Springer Fachmedien Wiesbaden 2015.
4) Gronau, N. et al.: Enzyklopädie der Wirtschaftsinformatik. Online-Lexikon 2012. URL: http://www.enzyklopaedie-der-wirtschaftsinformatik.de. Abgerufen am 05.10.2016.
5) Gronau, N.: Grundlagen der objektorientierten Geschäftsprozessmodellierung mit der UML. Universität Potsdam 2008. URL: http://www.eukritis.de/hp.nsf/0/4E79C06B49CC7827C12574EC00427AA3/$File/VL-GPM_UML_2F.PRZ.pdf. Abgerufen am 05.10.2016.
6) Webseite der Object Management Group. URL: http://www.omg.org/. Abgerufen am 17.10.2016.
7) Jung, J., Sprenger, J.: Muster für die Geschäftsprozessmodellierung. Universität Duisburg-Essen 2006. URL: http://subs.emis.de/LNI/Proceedings/Proceedings90/GI-Proceedings-90-9.pdf. Abgerufen am 08.10.2016.
8) Oestereich, B.: Objektorientierte Geschäftsprozessmodellierung und modellgetriebene Softwareentwicklung. In: HMD- Praxis der Wirtschaftsinformatik, Heft 241, Februar 2005.
9) Webseite der Unified Modeling Language. URL: http://www.uml.org/. Abgerufen am 18.10.2016.
10) Zellner, G.: Leistungsprozesse im Kundenbeziehungsmanagement – Identifizierung und Modellierung für ausgewählte Kundentypen. Dissertation an der Universität St. Gallen, Hochschule für Wirtschafts-, Rechts- und Sozialwissenschaften. St. Gallen 2003.

8. Abbildungsverzeichnis

Abbildung 1: Überblick über die wichtigsten Prozessmodellierungsmethoden 5

Abbildung 2: Grundidee der Unified Modeling Language 7

Abbildung 3: Übersicht über die verschiedenen Diagrammtypen der UML 2 8

Abbildung 4: “Kundenanfragebearbeitung” dargestellt als Anwendungsfalldiagramm 9

Abbildung 5: Aktivitätsdiagramm des Vorgangs “KFZ reservieren” 11

9. Tabellenverzeichnis

Tabelle 1: Notationselemente beim Anwendungsfalldiagramm 9

Tabelle 2: Die wichtigsten Notationselemente beim Aktivitätsdiagramm 10

[...]


[1] vgl. Becker, Kugeler, Rosemann, 2005, S. 6.

[2] vgl. Zellner 2003, S. 44.

[3] Gronau et al. 2012.

[4] vgl. ebenda.

[5] ebenda.

[6] vgl. Jung, Sprenger, 2006, S. 189.

[7] der Absatz folgt Gadatsch 2015, S. 15.

[8] eigene Abbildung in Anlehnung an Gadatsch 2015, S .16.

[9] Oestereich 2005, S. 27.

[10] Gronau et al. 2012.

[11] der Absatz folgt Gronau et al. 2012.

[12] Nennenswert sind hier Smalltalk, C++, Presto und Eiffel. Nähere Informationen: Schill, A.: Migrationssteuerung und Konfigurationsverwaltung für verteilte objektorientierte Anwendungen. Springer-Verlag Berlin Heidelberg 1990, S. 16ff.

[13] Die drei Ansätze sind: “Object-Oriented Software-Engineering (OOSE)“ von Jacobson, die „Object Modeling Technique (OMT)“ von Rumbaugh und die „Object-Oriented Analysis and Design“ von Booch. Vgl. Schäfer, S.: Objektorientierte Entwurfsmethoden: Verfahren zum objektorientierten Systementwurf im Überblick. Bonn et al.: Addison-Wesley 1994, S. 71 ff.

[14] vgl. Gronau et al. 2012.

[15] vgl. Webseite der OMG.

[16] Gronau 2008, S. 6.

[17] vgl. Webseite der UML.

[18] Dandl 1999, S. 12.

[19] eigene Darstellung in Anlehnung an Gronau 2008, S30.

[20] eigene Darstellung in Anlehnung an Dandl 1999, S. 11.

[21] vgl. Gronau 2008, S. 35

[22] vgl. ebenda, S. 36ff.

[23] Oestereich 2005, S. 30.

[24] Oestereich 2005, S. 27.

[25] Ostereich 2005, S. 29.

[26] vgl. Gronau 2008, s.41.

[27] vgl. Oestereich 2005, s. 29.

[28] Oestereich 2005, s. 30.

Ende der Leseprobe aus 15 Seiten

Details

Titel
Pro und Contra objektorientierter Geschäftsprozessmodellierung
Untertitel
Objektorientierung
Veranstaltung
Geschäftsprozessmodellierung
Note
2.0
Autor
Jahr
2016
Seiten
15
Katalognummer
V358632
ISBN (eBook)
9783668431010
ISBN (Buch)
9783668431027
Dateigröße
746 KB
Sprache
Deutsch
Schlagworte
Prozess, UML, Unified modeling language, Geschäftsprozesse, Modell
Arbeit zitieren
Jan Wokittel (Autor), 2016, Pro und Contra objektorientierter Geschäftsprozessmodellierung, München, GRIN Verlag, https://www.grin.com/document/358632

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Pro und Contra objektorientierter Geschäftsprozessmodellierung


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