Prozessgesteuerte Anwendungen entwickeln und ausführen mit BPMN

Grundlagen, Konzepte und aktueller Stand


Trabajo de Seminario, 2014

91 Páginas, Calificación: 1,3


Extracto


Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1 Einleitung
1.1 Gegenstand der Arbeit
1.2 Zielsetzung und Motivation
1.3 Aufbau der Arbeit

2 Grundlagen von prozessgesteuerten Anwendungen
2.1 Geschäftsprozesse und Geschäftsprozessmanagement
2.2 Prozessgesteuerte Anwendungen
2.2.1 Prozessgesteuerte Architektur
2.2.2 Methodik und Vorgehensweise
2.3 Business Process Model and Notation
2.3.1 Abgrenzung und Einordnung der BPMN
2.3.2 Grundprinzipien und Kernelemente
2.4 Automatisierung von Geschäftsprozessen
2.5 Zusammenspiel der fachlichen und technischen Ebenen

3 Realisierung von prozessgesteuerten Anwendungen
3.1 Konzept und methodische Hilfsmittel
3.1.1 Erarbeitung eines Sollkonzeptes anhand eines Beispielprozesses
3.1.2 Auswahl eines BPM-Werkzeuges
3.2 Beispielhafte Darstellung
3.2.1 Modellierung eines Teils des Bestellabwicklungsprozesses
3.2.2 Prozessgesteuerte Ausführung des Modells

4 Schlussbemerkungen
4.1 Fazit und Kritik
4.2 Ausblick

Literaturverzeichnis I

Anhang I

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abb. 1: Geschäftsprozessmanagement-Kreislauf

Abb. 2: Architektur prozessgesteuerter Anwendung

Abb. 3: Vorgehensmodell zur Entwicklung von PDA

Abb. 4: Statistiken über BPMN und anderen Modellierungssprachen

Abb. 5: Einordnung von BPMN in die Modellierungssprachen

Abb. 6: Einfluss von BPMN auf die teilnehmenden Rollen

Abb. 7: BPMN 2.0 Basiselemente

Abb. 8: Prozessautomatisierung anhand einer Prozess-Engine

Abb. 9: Umfrage über die Nutzungsmöglichkeit verschiedener Modellierungssprachen

Abb. 10: Nabe-Speiche-Architektur des EDI-Bestellabwicklungsprozesses

Abb. 11: Bestellbestätigung-Modell beim Business-Experten

Abb. 12: Bestellbestätigungsmodell beim Business-Analysten

Abb. 13: Bestellbestätigungsmodell beim IT-Experten

Abb. 14: Zwei-Schichten-Architektur prozessgesteuerter Anwendung

Abb. 15: Optimiertes Modell

Es ist nicht die stärkste oder intelligenteste Art, die überlebt

Es ist die Art, die sich Veränderungen am besten anpasst

[Charles Darwin]

1 Einleitung

1.1 Gegenstand der Arbeit

Ein wichtiger Faktor für den langfristigen Unternehmenserfolg ist der ebenso zielorientierte wie wirtschaftliche Ablauf der Geschäftsprozesse. Hieraus resultiert die Notwendigkeit, betriebliche Abwicklungen zu analysieren, zu modellieren und möglicherweise neu zu gestalten.[1] Zalando, Europas größter Onlineanbieter für Fashion und Schuhe, hat genau dies gemacht. Das Unternehmen hat sich von der Standard ERP[2] -Software gelöst und ist zu prozessgesteuerten Anwendungen (PDA) übergegangen. Dafür hat es die Modellierungssprache BPMN 2.0 verwendet. Dies steht für Business Process Model and Notation und ist eine standardisierte Notation für Prozessmodelle.[3] Durch das Unternehmenswachstum erhöhten sich die Datenmassen und das ERP-System wurde immer langsamer. Deswegen wurde das Projekt „Schrei vor Glück mit BPMN 2.0“ ins Leben gerufen. Bis zum Zeitpunkt des Projektbeginns hatte das Unternehmen fünf Entwickler. Nach zweieinhalb Jahren Arbeit, wovon eineinhalb Jahre reines Modellieren war, gab es mehr als 400 Entwickler. Die beiden Kernprozesse Retouren und Bestellabwicklung wurden herauskristallisiert und mit Hilfe von BPMN 2.0 modelliert. Das Ergebnis ist, dass es zwei Hauptprozesse, 14 Unterprozesse, 112 Service-Aufgaben und lediglich zwei Benutzer-Aufgaben gibt. Pro Tag werden 1,5 Millionen neue Prozessinstanzen initiiert.[4] Die PDA scheint sehr gut bei Zalando anzukommen, denn im Februar 2014 starteten der Softwarehersteller camunda und Zalando das gemeinsame Projekt „bpmn.io“. Das Ziel ist, ein webbasiertes Open Source Werkzeug für die Modellierung von Geschäftsprozessen zu entwickeln. Herr Zieger, Leiter des Enterprise-System-Bereich bei Zalando, erklärt, dass „für ein Unternehmen mit starkem Wachstum [...] klar definierte Prozesse eine große Rolle [spielen]“.3 An diesem aktuellen Beispiel lässt sich erkennen, dass durch den Einsatz von PDA ein Unternehmen deutliche Verbesserungen erreichen kann.

1.2 Zielsetzung und Motivation

Prozessoptimierung, Kosten-, Zeit- und Ressourcenersparnisse sind das Ergebnis des Einsatzes von PDA. Durch eine detaillierte Modellierung der Geschäftsprozesse können diese erneut durchdacht, Schwachstellen gefunden, behoben und Verbesserungsmaßnahmen eingeleitet werden. BPMN 2.0 steht zurzeit als State of the Art bei der Geschäftsprozessmodellierung und Automatisierung. Wie es wohl auch Zalando bemerkte, ist sie der Lückenfüller. Die Basis dafür sind zwei Ebenen: eine grafische Modellierungssprache für die Fachabteilung und eine formale Prozess-Grammatik für die Entwickler. Letzteres enthält neben den Klassendiagrammen eine Entwicklungsgrundlage für die Prozess-Engines, welche wiederum die Basis zur Automatisierung von Geschäftsprozessen bringt.[5] PDA, die weitgehend automatisch ablaufen, sind weniger fehleranfällig und organisieren und beschleunigen die Arbeitsschritte[6]. Jedoch werden die dazugehörigen Modellierungen und die Automatisierung von Geschäftsprozesse selten ein- bzw. umgesetzt. Zwar ist vielen Unternehmen die Dringlichkeit der Verbesserung und Veränderung bekannt, aber das größte Problem ist das unzureichende Prozessverständnis, welches sowohl von den Fachbereichen als auch von der Informationstechnik (IT) ausgeht. Die geringe Veränderungsbereitschaft und die Investitionsbeschränkung in den Betrieben ist ebenfalls ein wesentliches Hindernis.[7]

Das Ziel dieser Arbeit ist es, anhand von BPMN 2.0 die prozessgesteuerte Anwendungen zu entwickeln und beispielhaft auszuführen. Dabei soll auf dessen Grundlage, Konzepte und den aktuellen Stand eingegangen werden, um dem Leser zu verdeutlichen, welche Vorteile dieser durch die Umsetzung von PDA in heterogenen, verteilen Systemlandschaften erreichen kann.

1.3 Aufbau der Arbeit

Nachdem im Kapitel 1 erläutert wurde, weshalb die PDA relevant sind, wird auf diese Thematik detailliert eingegangen. Da die Modellierung nur dort eingesetzt werden kann, wo es auch Geschäftsprozessmanagement (GPM) gibt[8], wird auch genau dort begonnen: bei der Definition und Erläuterung von Geschäftsprozesse, dessen Management und dem Zusammenhang zur Modellierung. Aufbauend darauf wird die Architektur und die Vorgehensweise der PDA behandelt und die Methodik bei der Realisierung dargestellt. Im Anschluss werden verschiedene Modellierungssprachen voneinander differenziert, wobei die Vorteile von BPMN 2.0 erarbeitet und hervorgehoben werden. Da sich diese Arbeit auf BPMN 2.0 stützt, werden auch kurz die Grundprinzipien und Kernelemente wie Funktion, Ereignis und Gateway erläutert. Anschließend wird auf die Automatisierung von Geschäftsprozessen eingegangen, welche sowohl von der betriebswirtschaftlichen als auch von der technischen Seite erläutert wird. Zum Schluss der theoretischen Phase wird das Zusammenspiel von Business und IT beleuchtet, welches bis heute in vielen Unternehmen ein großes Problem darstellt.

In Kapitel 3 der Seminararbeit wird ein Konzept entwickelt, welches den Teilprozess „Bestellbestätigung“ beispielhaft beschreibt und modelliert. So kann daraus eine PDA mit User-Interface (UI) entwickelt werden. Dazu wird eine Ist-Analyse durchgeführt und diese nach Schwachstellen untersucht. Mit Hilfe dieser Informationen wird ein Sollkonzept erstellt. Das Modell der Bestellbestätigung wird so lange in iterativen Schritten verbessert, bis es einer PDA entspricht. Im Anschluss werden Werkzeuge zur Modellierung miteinander verglichen, ausgewertet und das effektivste und effizienteste für die Zielerfüllung ausgewählt. Nach der Vorarbeit geht es über in die eigentliche Modellierung des Bestellbestätigungsprozesses und die Erklärung, wie die prozessgesteuerte Ausführung auszusehen hat.

Diese Arbeit schließt mit einer kurzen Zusammenfassung und einem Fazit ab. Ebenfalls wird ein Ausblick auf weitere Möglichkeiten, Forschungsfortschritte und zukünftige Handlungen im Bereich der PDA gegeben.

2 Grundlagen von prozessgesteuerten Anwendungen

PDA wird als Prozessverständnis, also das Wissen über die Realisierungsmethodik und Architektur, definiert. Fälschlicherweise wird angenommen, dass die PDA aus dem GPM und der serviceorientierten Architektur (SOA) besteht.[9] Dabei stehen bei der SOA die Services im Mittelpunkt und deren Vorgehensweise beruht hauptsächlich auf einer Bottom-up-Methode. Dies bedeutet, dass die Services die Grundlage schaffen, auf der die Prozesse aufgebaut werden. Dieses Vorgehen führt zu einer Diskrepanz, da die Dienste entwickelt werden, ohne zu wissen, was genau benötigt wird. SOA bietet auch kein optimales Interface und die Wiederverwendbarkeit befindet sich unter fünf Prozent.[10]

Die PDA hingegen stellt die fachlichen Prozesse in den Mittelpunkt und verfolgt somit ein Top-Down-Vorgehen. Die IT-Systemlandschaft schränkt die Modellierung nicht ein, da zuerst die Prozesse beschrieben und im Anschluss die IT-Infrastruktur berücksichtigt wird.[11] PDA sind in sich abgeschlossene Systeme und fachlich orientierte Anwendungen. Sie erstrecken sich über funktionale System- und Organisationsgrenzen hinweg. Ein sehr großer Vorteil ist, dass PDA durch die Wiederverwendbarkeit der fachlichen Prozessbeschreibung an andere Systemen und Plattformen weitergegeben werden kann.[12]

2.1 Geschäftsprozesse und Geschäftsprozessmanagement

Die PDA setzt als Basis Kenntnisse über die Geschäftsprozesse voraus. Diese definieren sich als logische und zeitliche Abfolge von Aktivitäten[13] und finden oftmals zwischen Geschäftspartnern statt.[14] Aktivitäten werden von verschiedenen Funktionseinheiten im Unternehmen ausgeführt und haben einen Zeitraum, welcher durch ein Anfangs- und Endereignis limitiert ist. Geschäftsprozesse sind nicht abteilungsweise begrenzt und können sich durch unterschiedliche Funktionsbereiche und auch über die Unternehmensgrenzen hinaus erstrecken.13

Es sollte immer zwischen der Geschäftsprozessdefinition, z.B. in Form eines Diagrammes, und der Erstellung oder Ausführung einer Prozess-Instanz unterschieden werden. Letzteres ist ein ausführbarer Prozess, der basierend auf die Geschäftsprozess-Definition erzeugt wird. Es kann viele Prozess-Instanzen bezüglicher einer Definition geben.[15]

Die Planung, Verwaltung und das Messen von Kernprozessen erfolgt durch das GPM.[16] Es umfasst die Innovation, Verbesserung und den Erhalt von Ende-zu-Ende-Prozessen[17].8 Das Management wird als eine Top-Down-Methodik verstanden, die bei den Kernprozessen zu analysieren beginnt.[18] GPM versteht sich als systematischer Ansatz und beinhaltet sowohl automatisierte als auch nicht automatisierte Prozesse. Es unterstützt das Unternehmen dabei, sowohl dem Kunden, als auch sich selbst einen Nutzen zu generieren.8 Die häufigste Anwendung des GPM findet sich wieder in:[19]

- Bestehende Prozesse organisatorisch oder mit Hilfe der IT zu optimieren, z.B. bei Eliminierung von Medienbrüchen.
- Bestehende Prozesse zu dokumentieren, wie beispielsweise aufgrund von juristischen Anforderungen oder Zertifizierungsvorgaben (z.B. ISO 9000).
- Neue Prozesse einzuführen. Ein Grund hierfür wäre das Anpassen an veränderte Marktbedingungen oder das Erschließen von neuen Vertriebskanälen.

Um diese Ziele zu realisieren sollte nach dem Vorgehensmodell, welches in Abb. 1 dargestellt ist, gearbeitet werden. Dies ist ein GPM-Kreislauf, welcher auf die Optimierung von bestehenden und das Erstellen von neuen Prozessen eingeht. Es beschreibt somit, welcher Schritt wann kommt und welche Aktivitäten zu erwarteten sind.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Geschäftsprozessmanagement-Kreislauf

(in eigener Darstellung nach [Freund, Rücker (2012), S.4])

Dieser Kreislauf kann von einzelnen Prozessen durchlaufen werden, die sich aktuell in unterschiedlichen Stadien befinden. Zum Verständnis wird mit der „Prozessanalyse“ begonnen. Dort wird analysiert, welche Leistung der Prozess erbringt und welche Priorität dieser besitzt. Ebenfalls wird erhoben, welche auszuführenden Aufgaben, beteiligte Rollen und Organisationen vorhanden sind. Das Ergebnis der Erhebung wird anhand von Diagrammen und Beschreibungen in einem Ist-Prozessmodell zusammengeführt und dokumentiert. Sollte der erstmalige dokumentierte Prozess Schwachstellen aufweisen oder im Rahmen der kontinuierlichen Prozesskontrolle Schwachstellen erkannt werden, werden diese ebenfalls analysiert. Die festgestellten Ursachen für die Schwachstellen sind die Grundlagen für eine Prozesskonzeption. Hier werden unterschiedliche Varianten mit programmgestützter Simulation evaluiert. Aus dem Ergebnis wird das Soll-Prozessmodell abgeleitet. Die Umsetzung des Soll-Modells sollte sowohl organisatorisch als auch im Rahmen eines IT-Projektes stattfinden. Das Ergebnis der Realisierung ist ein Ist-Prozess, welcher dem Soll-Konzept entspricht und gleichzeitig automatisch und vollständig dokumentiert ist. Die Prozesskontrolle wird kontinuierlich durchgeführt und prüft, ob weitere Verbesserungen möglich sind.[20]

2.2 Prozessgesteuerte Anwendungen

Damit ein Unternehmen Wettbewerbsvorteile erzielen kann, muss es kundenorientiert sein und optimale, sich ständig verbessernde Geschäftsprozesse haben. Ist dies der Fall, hat es einen höheren Differenzierungsgrad, welches den Gewinn des Unternehmens steigert.[21] Die PDA werden durch die fachlichen Anforderungen und den bestehenden Funktionen der eingesetzten Systeme entwickelt. Ebenfalls unterstützt sie nicht nur die Ende-zu-Ende-Prozesse, sondern integriert auch Menschen, Informationen und Geschäftsprozesse.[22]

Um solche Kernprozesse abbilden, ausführen, optimieren und überwachen zu können, müssen eigenständige und fachlich orientierte Anwendungen entwickelt werden. Diese sollten flexibel auf Kunden- und Marktanforderungen anpassbar sein.

PDA erfüllt genau diese Anforderungen. Sie unterscheidet sich von Integrationsanwendungen, bei denen der Fokus auf der technischen Integration liegt. Ebenso differenziert sie sich von den Mashups, welche reine grafische Benutzeroberflächen mit direkter Anbindung an unterschiedlichen Systemen beinhalten. PDA ist ebenfalls keine klassische Unternehmenssoftware wie z.B. ein ERP-Standard-System.[23] Der Grund für die Differenzierung liegt in der Trennung zwischen der Fachprozessschicht und der Integrationsschicht. Der kritische Geschäftsprozesse wird von den ständigen Veränderungen der Systemlandschaft nicht betroffen21 und erreicht somit weitestgehend eine Unabhängigkeit.

PDA sollte eingesetzt werden, wenn keine Standardsoftware im Unternehmen vorhanden ist, die Prozesse anwendungs- und unternehmensübergreifend sind oder einen hohen Kommunikations- und Koordinationsaufwand mit sich bringen. Dies gilt auch, wenn die Prozessabläufe vom Mitarbeiter selbst getätigt werden, wie z.B. Urlaubs- oder Geschäftswagenanträge oder die Geschäftsprozesse häufigen Anpassungen unterliegen.[24] Der Kauf von PDA ist nicht möglich, denn es muss für jedes Unternehmen individuell erstellt und angepasst werden.[25]

In der folgenden Arbeit wird öfters auf die Rollen des Business-Experten, des Business Analysten und des IT-Experten eingegangen. Diese lassen sich grob drei Tätigkeiten zuschreiben: Dem Betriebswirt, Wirtschaftsinformatiker und Informatiker.

2.2.1 Prozessgesteuerte Architektur

Die prozessgesteuerte Architektur ist ein Paradigma und benötigt eine andere Denkweise25 als z.B. die Standardsoftware. Aus fachlicher (Management-) Ebene gesehen, sind die Geschäftsprozesse die wahren Treiber für die Ausgestaltung der prozessgesteuerten Architektur und die daraus resultierende PDA. Zwar bauen sie ebenfalls auf Wiederverwendbarkeit von existierenden Fachfunktionen auf, aber im Gegenteil zum SOA-Ansatz verwenden diese nicht direkt die angebotenen Schnittstellen.[26]

Durch einen Service-Vertrag abstrahieren sich die PDA von Backend-Systemen und somit von der technischen Implementierungsschicht. Dies ist in Abb. 2 semantisch dargestellt

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Architektur prozessgesteuerter Anwendung

(in eigener Darstellung nach [Stiehl (2013), S.93])

Die mehrschichtige Architektur gliedert sich in erster Linie in die PDA, den Servicevertrag, der Servicevertrag-Implementierungsschicht (SVIS) und den Backend-Systemen. In der ersten Ebene befindet sich die Prozessebene, die rollenspezifischen, aufgabenorientierten UI für die Bedienung und Steuerung des Prozessablaufs und den dazu notwendigen Diensten und Geschäftsobjekten.[27] Die Prozessschicht beinhaltet die Geschäftsprozesse und benötigt bei Realisierung Zugriff auf das User-Interface, die Anwendungen sowie die Geschäftsobjekte. Das UI ist auf die Bedürfnisse der jeweiligen Rolle im Geschäftsprozess angepasst und benötigt bei dessen Umsetzung die Zugänge zu den Anwendungen und Geschäftsobjekten. Diese bieten eine neue anwendungsspezifische Logik, Datenpersistenz und Wiederverwendbarkeit von bestehenden, internen und externen Services.[28] Die PDA bindet die technische Schicht durch einen Servicevertrag ein. Er definiert die externen Funktionalitäten und Dienste, welche auf den PDA-Anforderungen basieren. Der Servicevertrag ist prozessgesteuert und umfasst ausgehende wie ankommende Anfragen. Dieser erhält keine wiederverwendbaren Services.[29] Alle diese Schichten konzentrieren sich ausschließlich auf die benutzerzentrischen Prozesse. Sie kommunizieren durchgehend mit einer hochgradig technologieabhängigen SVIS. Diese nimmt die Rolle einer Außendarstellung der PDA ein.27

Die SVIS kapselt alle technischen Kommunikationsaspekte mit den Backend-Systemen. Es fokussiert sich auf komplexe, integrationstechnische Prozessteilschritte. Durch diese Schicht wird die lose Kopplung zwischen einer PDA und Backend-Systemen realisiert.[30]

In der prozessgesteuerten Architektur muss je nach Unternehmen unterschieden werden, ob eine Zwei- oder Drei-Ebenen-Architektur sinnvoll ist. Die Darstellung in Abb. 2 ist allgemein gehalten.

Die Zwei-Schichten-Architektur besteht aus der PDA und der Service-Vertrags-Implementierungs-schicht. Dadurch ist eine klare Trennung der Geschäftsprozesse von den technischen Integrationsprozessen möglich, wodurch die Abhängigkeit zu der Geschäftsprozessebene aufgehoben wird. Die beiden Schichten kommunizieren direkt miteinander. Der integrationszentrische Prozess ist direkt mit den Backend-Systemen verbunden (Abb. 2). Diese Architektur setzt voraus, dass die BPMN-Engine sich zu den beteiligten Backend-Systemen verbinden kann. Das Problem entsteht, wenn es im Unternehmen viele komplexe Systeme mit differenzierten Anbindungsmöglichkeiten gibt. Ein weiterer Nachteil ist, dass Änderungen an der Systemlandschaft Anpassungen in der SVIS-Ebene bedingen. Die Aufgaben wie Schnittstellen-, Empfänger-Ermittlung und das Mapping zwischen unterschiedlichen Schnittstellen können somit enorme Ausmaße annehmen. Es wird nur von dem integrationszentrischen Prozess übernommen. Eine sauberere und klarere Lösung wäre es, wenn diese Aufgaben von einem Enterprise Service Bus (ESB) übernommen werden würden.[31] Der ESB ist die Basis für grundlegende Integrationsarchitektur. Er ist serviceorientiert und dient zur Kommunikation zwischen verschiedenen Backend-Systemen und Diensten.[32]

Aus diesem Grund gibt es die Drei-Schichten-Architektur. Da bei Änderungen an den Backend-Systemen diese in die Routingtabelle des ESB geschrieben werden muss, profitiert der integrationszentrische Prozess von der Anpassung. Denn dieser kann z.B. bei der Ermittlung von einem Empfänger auf die von dem ESB verfügbaren Informationen zugreifen. Ebenfalls verläuft die Verwendung von Datentypen, basierend auf dem kanonischen Datenmodell, harmonisch ab. Denn schließlich arbeiten sowohl die PDA wie auch der integrationszentrische Prozess auf demselben Datenmodell. Die Drei-Schichten-Architektur setzt sich zusammen aus dem fachlichen Prozess (=PDA), dem zustandsbehafteten Integrationsprozess (=SVIS) und dem zustandslosen Integrationsprozess (=ESB)[33]. Die Vorteile dieser Architektur gegenüber der Zwei-Schichten-Architektur sind eine kostengünstigere Wartung, eine höhere Flexibilität, die schnelle und kosteneffiziente Innovation, eine Erhöhung der Portabilität auf andere Systemlandschaften und eine unabhängige Entwicklung von Geschäfts- und Integrationsprozessen. Der ESB ist der zentrale Ort für die Steuerung des Ende-zu-Ende-Nachrichtenflusses. Aber zu den Vorteilen kommen auch Nachteile, wie die erhöhte Komplexität, mögliche „Erfüllung“-Strafen, der hohe anfängliche Entwicklungsaufwand und dessen Kosten.[34]

Zu beachten ist, dass bei Verwendung von mehreren Schichten mit einer höheren Antwortzeit zu rechnen ist.[35]

Bei der Realisierung ab Kapitel 3 wird die Zwei-Schichten-Architektur verwendet, weil die Systemlandschaft lediglich aus zwei Backend-Systemen besteht die sich miteinander über das gleiche Protokoll verständigen.

2.2.2 Methodik und Vorgehensweise

Die Herausforderungen bei der Entwicklung von PDA sind:

- Flexibilität, bei einer häufigen Umstellung und Anpassung der Prozesse.
- Komplexität durch die Prozessautomatisierung
- Wartbarkeit durch Heterogenität und Dezentralisierung
- Zusammenspiel von Business und IT. Dieses muss ineinander übergehen, da es verschiedene Rollen mit unterschiedlichen Sichten und Hintergrundwissen gibt.[36]

Das Hauptprinzip bei der Realisierung von PDA basiert auf der Top-Down-Methode. Der Schwerpunkt liegt dabei auf den umzusetzenden Fachprozessen. Durch die Zerlegung (Dekomposition) eines komplexen Prozesses in die kleinsten Teile werden sich die Kernbestandteile (z.B. Datenobjekte oder Basisdienste) einer modellierten Anwendung herausbilden.[37]

Bei der Entwicklung von PDA sollte die Rolle eines Organisationsprogrammierers und nicht die Rolle eines Systemprogrammierers eingenommen werden. Der Grund dafür ist, dass der Erstere in Flussstrukturen mit einer Domination von Geschäftslogik denkt.[38]

Die Oberhoheit über jeden Schritt des Prozesses sollte im fachlichen Prozess liegen und jede Datenübergabe an SVIS auch von dort initiiert werden. Nur so bleibt die Kontrolle des Prozessablaufs auf der Fachebene (vgl. Abbildung 15 im Anhang).[39]

Die Fachabteilung beginnt mit der Modellierung der Geschäftsprozesse. Dafür gibt es unterschiedliche Beschreibungssprachen wie z.B. DIN-Norm 6001, eEPK (erweiterte ereignisgesteuerte Prozesskette) oder BPMN.[40] Jedoch wird für die Entwicklung von PDA einzig und dringend die BPMN (siehe Kapitel 2.3) empfohlen.

In der Abb. 3 wird dargestellt, wie das Vorgehen bei einem guten PDA-Modell aussehen sollte. Anhand der einzelnen Ebenen kann PDA mithilfe von BPMN realisiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Vorgehensmodell zur Entwicklung von PDA

(in eigener Darstellung nach [Freund, Rücker (2012), S. 188])

Die erste Ebene ist das strategische Prozessmodell. Die Zielgruppe sind die Prozessbesitzer und Prozessmanager. In dieser Ebene ist das Ziel, eine grundsätzliche, ergebnisorientierte Abbildung des Prozesses zu erstellen. Dabei soll der grobe Ablauf aus der Vogelperspektive skizziert werden, ohne dass spezielle BPMN-Kenntnisse benötigt werden. Alternative oder mögliche Fehlerereignisse werden nicht dargestellt.[41]

Die zweite Ebene ist das operative Prozessmodell. Hier werden die operativen Details der Prozessabwicklung betrachtet. Dieses Modell wird einerseits von den Teilnehmern benötigt, damit sie sich bei der Arbeit orientieren können, andererseits ist es das Hauptarbeitsmittel des Business Analysten. Damit kann er mögliche Schwachstellen analysieren und Verbesserungsvorschläge definieren. Die Hauptaufgabe liegt jedoch darin, aus dem Modell der Ebene 2 ein technisches Prozessmodell zu entwickeln, welches der IT-Experte realisieren kann. Hierbei kommt BPMN als Notation zum Einsatz.[42]

Ebene 3b und 4b werden für das weitere Vorgehen nicht betrachtet, da sich die PDA auf die Ausführung mit einer Prozess-Engine spezialisiert, welche diese beiden Ebenen nicht bieten.

Die Ebene 3a ist das technische Prozessmodell. Hier geht es darum, dass der Prozess per Software automatisiert wird. Die Prozessmodelle sind direkt ausführbar und haben somit auch einen Quellcode. Voraussetzung für die Funktionalität ist, dass die Modelle sehr exakt und detailliert beschrieben sind, denn mit Interpretationsspielräumen kann die Prozess-Engine nicht arbeiten. Werden die Prozessmodelle von Ebene zwei und drei gut miteinander verknüpft, können die Prozessmodelle der zweiten Ebene aktuell gehalten werden.[43]

Mit dieser Vorgehensweise ist es möglich, dass die fachliche Seite die Prozesse vorgibt (Top-Down-Methode) und die IT diese überführt, ohne dass dabei die Fachabteilung und dessen Verständnis verloren geht. Das BPMN-Prinzip ist für beide Seiten relevant und verständlich.[44]

Ein guter ausführbarer Prozess umfasst Qualität (z.B. Anzahl der Ausnahmezustände), Zeit (z.B. Durchlaufzeit) und Kosten.[45] Eines der wichtigsten Ziele und gleichzeitig das Zeichen für gute Qualität ist die Kundenzufriedenheit. Aus mehreren Gründen, besonders wegen der Komplexität der Aufgaben und der hohen Anzahl der angebundenen Systeme, wird empfohlen, einige Aufgaben aus der SVIS in den ESB auszulagern. Diese sind z.B. Schnittstellen-Anbindung (Mapping), Weiterleitung von Nachrichten (Routen) oder Datenkonvertierung (Nachrichtentransformation).31 Auf keinen Fall darf die Anforderung der Nichtinvasivität (=kein Eingriff in den Backend-Systemen) verletzt werden. Deshalb müssen die Änderungen in der SVIS oder in dem ESB vorgenommen werden.[46]

Während der Modellierung aller Ebenen sollen die „Grundsätze der ordnungsgemäßen Modellierung“ eingehalten werden. Diese sind Richtigkeit, Relevanz, Wirtschaftlichkeit, Klarheit, Vergleichbarkeit und der systematische Aufbau.[47] Verschiedene Umsetzungsmethoden und Stile sollen die Modellierer auf dem Weg zur Prozessmodellierung und -automatisierung mithilfe von BPMN begleiten. Dessen Grundprinzipien sind Vollständigkeit, Klarheit, Austauschbarkeit zwischen Business und IT sowie strukturelle Konsistenz.[48]

2.3 Business Process Model and Notation

Die Modellierung der Geschäftsprozesse sollte nicht als Selbstzweck, sondern als eine notwendige Voraussetzung gesehen werden, um Unternehmensabläufe kontinuierlich analysieren, optimieren und überwachen zu können.[49] Dies war auch die Grundidee für die Entwicklung von Business Process Modeling Notation. Die Zielsetzung war von Anfang an, eine grafische, standardisierte Prozessnotation bereitzustellen, die ebenfalls für die Automatisierung von Prozessen verwendet werden kann. Mit der Version 2.0 wurde auch die Bezeichnung in „Business Process Model and Notation“ umbenannt, da dies nicht nur die Notation definiert, sondern auch ein „formales Metamodell“.[50] Ein Metamodell beschreibt eine Modellierungssprache mit den dazugehörigen Strukturen, Zusammenhängen und verwendbaren Elementen.[51] PDA und somit auch das Zusammenspiel zwischen der Fachabteilung und der IT ist nur mit BPMN 2.0 möglich. Denn dies ist die erste und einzige ausführbare Notation.[52] Aus diesem Grund wird vorrangig auf BPMN 2.0 eingegangen. Der Begriff BPMN meint in der ganzen Ausarbeitung die Version 2.0.

2.3.1 Abgrenzung und Einordnung der BPMN 2.0

Schon im Juni 2009 bzw. im Juli 2010 kristallisierte sich durch Studien, die in Abb. 4 dargestellt sind, deutlich heraus, dass das Interesse an BPMN hoch ist und weiter steigt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: Statistiken über BPMN und anderen Modellierungssprachen

(in eigener Darstellung nach [Modellierungssprachen (2009/2010)]

Auch die Anzahl der Personen, die Praxiserfahrung mit der neuen Modellierungssprache haben, nahm zwischen 2009 und 2010 enorm zu, auch wenn es bis dato nicht mit den ereignisgesteuerten Prozessketten (EPK) mithalten konnte.

Dieses Kapitel erläutert das Besondere von BPMN 2.0 zu anderen Modellierungssprachen und trägt somit durch die Abgrenzung und Einordnung zum Verständnis bei. Es existieren verschiedene Standards zur Modellierung von GP. Der Mittelpunkt der Modellierung ist der Übergang von dem Prozessmodell der Fachebene zu dem technischen Modell der Geschäftsprozessausführung. Prozessmodelle sind diagrammbasiert, teilweise formal, nicht direkt ausführbar und tragen durch Visualisierung der Abläufe zu einem besseren Verständnis bei. Entsprechende Standards hierfür sind z.B. die ereignisgesteuerte Prozesskette und BPMN.[53] Um ein BPMN-Modell auszuführen, werden formale Sprachen wie XML[54] Process Definition Language (XPDL) oder Business Process Execution Language (BPEL) benötigt.[55] Letzteres ist auf automatische Webservice-Aufrufe spezialisiert. Diese können dann wiederum externe Softwarekomponenten aufrufen. Es hat jedoch keine graphisch festgelegte Notation53 und wird als „unschöne“ Sprache bezeichnet.[56] Abb. 5 verdeutlicht auf der einen Seite, wie sich BPMN entwickelt hat und auf der anderen Seite, wo es sich im Vergleich zu anderen Modellierungssprachen befindet. Für diese Ausarbeitung wurden zwei weitere Notationen EPK und UML herausgegriffen, da diese besonders häufig in der Praxis eingesetzt werden.[57] Beide werden mit der BPMN verglichen, um zu verdeutlichen, welchen Vorteil und Fortschritt die BPMN mit sich bringt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 5: Einordnung von BPMN in die Modellierungssprachen

(in eigener Darstellung nach [Kulis, S. 26])

Die BPMN ist eine flussdiagrammbasierte Notation, welche Geschäftsprozesse definiert. Sie ist ein Zusammenschluss verschiedener Notationsanbieter mit dem Ziel, dem Anwender die Arbeit und das Verständnis zu erleichtern, indem es nur eine Notation gibt. BPMN ermöglicht es, einen modellierten Geschäftsprozess mit BPEL auszuführen.[58] BPEL ist eine XML-basierte Ausführungssprache zur Beschreibung von Geschäftsprozessen und Interaktionsprotokollen. Sie bindet die Aktivitäten ein und koordiniert diese als Webservices über die WSDL-Schnittstelle (Web Services Description Language). Zur Ausführung von BPEL-Prozessen wird eine Process-Engine eingesetzt.[59] Auf Prozess-Engines im Allgemeinen wird im Kapitel 2.4 genauer eingegangen.

Die Idee von BPEL, die Ausführung über XML und die Prozess-Engine wurden als Ausgangspunkt für die Entwicklung von BPMN genommen, deren Ziel es ist, eine vollständige und eindeutige Transformation zu erlangen.[60] Somit schloss BPMN die Lücke zwischen der Modellierung von Geschäftsprozesse und der Ausführung[61]. BPMN wird als großer Fortschritt der Geschäftsprozesstechnologie verzeichnet, denn es hat ein vielversprechendes Nutzpotenzial[62]. Durch die graphische Prozessmodellierung und der präzisen Prozess-Darstellung verbessert sie die Zusammenarbeit zwischen Business und IT. BPMN kann bestehende Prozesse durch den Einsatz von Informationstechnik und zum Zweck der (Teil-) Automatisierung optimieren. Die dadurch erreichte und gestiegene Effizienz vermeidet Mehrfach-Arbeit und definiert die Abläufe und Zuständigkeiten. Bei ordnungsgemäßem Einsatz von BPMN können die Anforderungen des Qualitätsmanagements im Rahmen der Zertifizierung erfüllt werden. Ebenfalls besteht die Möglichkeit, mit internationalen Geschäftspartnern Kollaborationen zu definieren. Durch die verständliche Dokumentation und Definition von Prozessen werden die Prozessbeteiligten bei den täglichen Anwendungen unterstützt.

Für die meisten Modellierer ist die grafische Notation das Wichtigste, denn es ist eine Diagrammsprache zur Darstellung von Geschäftsabläufen. Der allgemeine Standard bestimmt die Semantik und nicht das jeweilige Werkzeug. Die BPMN ermöglicht, kleinste Veränderungen im Prozessverhalten zu dokumentierten.[63]

In Bezug auf Abb. 5 wird nun der Unterschied zwischen den EPK und BPMN herausgearbeitet. Den Studien aus Abb. 4 sind zu entnehmen, dass EPK nach und nach von der BPMN verdrängt wurden.[64] Bevor dies der Fall war, wurden in Unternehmen primär die EPK für die fachliche Prozessmodellierung und BPEL für die technischen Prozesse eingesetzt.36 Abb. 6 stellt dies deutlich dar, ebenso wie die Lücke zwischen Business und IT.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 6: Einfluss von BPMN auf die teilnehmenden Rollen

(in eigener Darstellung nach [Stiehl (2014_V), in Bezug auf Folie 20])

EPK verwenden für die Methoden der Geschäftsprozessmodellierung Tabellen-, Spalten- und Zeilendarstellung. Sie bestehen im Allgemeinen aus Kanten und Knoten und bieten neben den Basiselementen „Funktion“ und „Ereignis“ auch Steuer- und Verknüpfungsoperatoren an.[65] Letzteres wird auch Konnektor genannt und ähnelt dem BPMN-Gateway. EPK unterscheiden nicht zwischen ereignis- und datenbasierten Verzweigungen. In der erweiterten Ausführung kommen Symbole für Daten, Anwendungssysteme und die Beschreibung von Organisationseinheiten hinzu. Über die Prozesspfade kann auf die Teilprozesse zugegriffen werden. Die Transformation von den EPK-Prozessmodellen zu BPMN ist sehr einfach. Paradoxerweise ist jedoch BPMN im Bereich der Modellierung von Ereignissen der EPK überlegen. Weder unterscheidet EPK zwischen Start-, Zwischen- und Endereignissen noch kennt sie die Nachrichten- oder Zeittypen. Ein weiterer Nachteil von EPK gegenüber BPMN ist, dass sie keine Ereignisse anheften können, was dazu führt, dass sie die Überwachungsfunktion, Eskalation oder Fehlerbehandlung erschweren und oft unmöglich machen. Auch ist die Anordnung von Datenobjekten nicht klar darzustellen. Die Abbildung 1 im Anhang dient hierfür als Beispiel.64

Zwar bestehen viele Modellierprofis, die aus der eEPK-Welt kommen, darauf, dass BPMN unzureichend sei, aber Grundlage dieser Behauptung ist wohl eher, dass es ihnen am Verständnis für den Standard mangelt. Denn die Kombination zwischen BPMN-Prozessmodellen und anderen Diagrammtypen klappt sehr gut. Die Voraussetzung dafür ist, dass dies auch das verwendete Modellierungswerkzeug unterstützt. Als zweiten Punkt bietet BPMN diverse Erweiterungsmöglichkeiten an, die bis zu eigenen Diagrammsymbolen reichen. Jedoch bekommt der Anwender die BPMN nicht direkt und „out of the box“ (= Standardsoftware). Aber dafür ist es ein Standard, für welches derzeit Softwarewerkzeuge entwickelt werden, die alle notwendigen Sichten wie Daten, Funktionen usw. abdecken und die auf eine BPMN-Prozessdarstellung bauen. Inzwischen bietet auch ARIS eine Prozessmodellierung mit BPMN an.[66]

Bezug nehmend auf Abb. 5 wird nun die Modellierungssprache UML 2.0 und ihr Aktivitätsdiagramm im Vergleich zu BPMN genauer betrachtet. Das Aktivitätsdiagramm ist eines von insgesamt 13 Diagrammarten der UML 2.0. UML ist eine allgemeine Sprache für die Softwaresystem-Modellierung und wurde nicht für Geschäftsprozesse entwickelt. Dennoch wurde das Aktivitätsdiagramm in der Vergangenheit für die Prozessmodellierung zweckentfremdet. Dies fand meistens in Verbindung mit IT-Projekten statt. Die Notation für das Aktivitätsdiagramm ist beispielsweise im Vergleich zu EPK umfangreicher. Es existieren mehrere Symbole, die eine softwaretechnische Basis und keine direkte Entsprechung in BPMN haben. Dieses gilt vor allem für die Verarbeitung von Objekten und deren Parameter in ausgewählten Aktionen. Die Symbole für die Geschäftsprozessmodellierung können weitestgehend übernommen werden. Komplex wird es jedoch dann, wenn in einem UML-Diagramm mit Unterbrechungsbereichen gearbeitet wird, welche über verschiedene Lanes laufen. Diese können nicht als Teilprozess in BPMN übernommen werden. Denn Teilprozesse dürfen die Grenzen der Lanes nicht überschreiten. Die Abbildung 3 und Abbildung 4 im Anhang zeigen am Beispiel eines Antragsstellungsprozesses, wie eine UML in BPMN 2.0 aussehen kann.

Die größte Schwäche von beiden vorgestellten (und weiteren) Notationen gegenüber BPMN ist die mangelnde Fähigkeit, die Kollaboration von Prozessen zu modellieren. Der zweite große Vorteil von BPMN ist, dass es speziell im Umgang mit Ereignissen viel größere Präzessionen hat als alle anderen gängigen Prozessnotationen.64

2.3.2 Grundprinzipien und Kernelemente

Das Hauptziel der BPMN ist es, für sämtliche Nutzer eine verständliche Notation zur Verfügung zu stellen. Da dies mit BPMN erreicht wird, stellt es eine standardisierte Füllung zwischen dem Geschäftsprozessdesign und der Prozessimplementierung dar.[67]

Um ein produktives und rentables BPMN-Modell aufzubauen, wird dies mit drei Ebenen realisiert. Ebene 1, auch „deskriptive Unterklasse“ genannt, beinhaltet die traditionellen Flussdiagrammelemente. Die Modellierung der ersten Ebene genügt, um die meisten Geschäftsprozesse kompakt und geschäftsfreundlich zu beschreiben.[68] Dabei wird das Vorgehen in fünf Schritte unterteilt[69]:

1. Den Umfang und die Funktionalität des Prozesses definieren
2. Ein Top-Level-Modell für den „Happy Path“ erstellen. Der „Happy Path“ ist der Standardablauf eines Prozesses ohne Berücksichtigung von Ausnahmen, Fehlern oder Sonderfällen.[70]
3. Das Modell um Pfade zu Ausnahmebehandlungen ergänzen
4. Das Modell um Unterprozesse erweitern, damit die Veranschaulichung erhöht wird
5. Nachrichtenflüsse zu externen Pools hinzufügen

Sollte der Schwerpunkt der Modellierung bei Ausnahmebehandlungen wie Fehler-, Zeit- und Nachrichtenereignisse, wie auch bei der Verzweigungs- und Zusammenführungsmuster und Iterationen liegen, wird die Ebene 2 benötigt. Diese wird als „analytische Unterklasse“ bezeichnet und oft bei Anforderungs- oder Simulationsanalysen eingesetzt. Sie bereitet die technische Umsetzung für eine Prozess-Engine vor und wird vom Prozess Analysten viel detaillierter modelliert. An dieser Stelle muss vor allem die Interaktion zwischen Menschen und Maschinen untersucht, aber auch über technische und organisatorische Verbesserungen, nachgedacht werden. Zwar wird der modellierte Prozess noch nicht direkt ausführbar, aber sowohl Business als auch IT reden hier über dasselbe Prozessmodell und verringern somit die Verständniskluft zwischen Fachabteilung und Technik.[71]

Selbst die zweite Ebene stellt erst einen Bruchteil des kompletten Ausmaßes der BPMN dar, jedoch benötigen nur wenige Modellierer mehr als die bis hierhin bekannten Elemente.[72]

Vollständigkeitshalber gibt es auch noch die Ebene 3, die „Ausführbare BPMN“. Diese beinhaltet z.B. Verzweigungsbedingungen, Daten- und detaillierte Aktivitätsanbindungen von Diensten. Diese Ebene wird für die ausführbare Prozesslogik mit XML-Elementen verwendet.68 Auch die Entscheidung über die eingesetzte Prozess-Engine, Technologie (z.B. Webservices, Methodenaufruf) und Sprache (z.B. XML, Java) wird auf dieser Ebene getroffen.[73] Ein intensives Testen ist hier unabdingbar, um den Flaschenhals während der Prozesssimulation bzw. semantische oder logische Prozessverlaufsfehler zu identifizieren. Ebenso soll es möglichst alle Ausnahmezustände abfangen, um diese entsprechend behandeln zu können.

[...]


[1] Vgl. Palleduhn, Neuendorf (2013), S. 7.

[2] ERP = Enterprise Ressource Planning

[3] Vgl. OTS (2014).

[4] Vgl. Sarnowski (2014).

[5] Vgl. Göpfert, Lindenbach (2013), S. V.

[6] Vgl. Stiehl (2014_Vo).

[7] Vgl. Quack (2014).

[8] Vgl. Freund, Rücker (2012), S. 1.

[9] Vgl. Stiehl (2014_Vo), in Bezug auf Folie 15.

[10] Vgl. Stiehl (2014_Vo), in Bezug auf Folie 18.

[11] Vgl. Stiehl (2014_Vo), in Bezug auf Folie 19.

[12] Vgl. Stiehl (2014_Vo), in Bezug auf Folie 16.

[13] Vgl. Mertens u.a. (2012), S. 68.

[14] Vgl. Göpfert, Lindenbach (2013), S. 12.

[15] Vgl. Göpfert, Lindenbach (2013), S. 2-3.

[16] Vgl. Harmon (2014), S. 11-13.

[17] Vgl. Fischermanns (2013), S. 110; Gaydoul, Daxböck (2011), S. 40; Freund, Rücker (2012), S. 2.

[18] Vgl. Koch (2011), S. 72.

[19] Vgl. Freund, Rücker (2012), S. 2.

[20] Vgl. Freund, Rücker (2012), S. 4-6.

[21] Vgl. Schaffry (2014).

[22] Vgl. Stiehl (2013), S. 17.

[23] Vgl. Stiehl (2013), S. 22-23.

[24] Vgl. Stiehl (2013), S. 25-26.

[25] Vgl. Stiehl (2014_Vo), in Bezug auf Folie 6.

[26] Vgl. Stiehl (2013), S. 14-15.

[27] Vgl. Stiehl (2013), S. 103.

[28] Vgl. Stiehl (2013), S. 27.

[29] Vgl. Stiehl (2013), S. 28.

[30] Vgl. Stiehl (2013), S. 27-28, 92-93, 111.

[31] Vgl. Stiehl (2013), S. 121-122.

[32] Vgl. Lipinski u.a. (2014_a).

[33] Vgl. Stiehl (2013), S. 126-127.

[34] Vgl. Stiehl (2013), S. 79, 122.

[35] Vgl. Stiehl (2014_Vo).

[36] Vgl. Stiehl (2013), S. 30.

[37] Vgl. Stiehl (2013), S. 51-52.

[38] Vgl. Stiehl (2013), S. IX.

[39] Vgl. Stiehl, Interview 30.05.2014 (E-Mail).

[40] Vgl. Gaitanides (2012), S. 168-169.

[41] Vgl. Freund, Rücker (2012), S. 15-16.

[42] Vgl. Freund, Rücker (2012), S. 16.

[43] Vgl. Freund, Rücker (2012), S. 187.

[44] Vgl. Hillert (2013).

[45] Vgl. Gaitanides (2012), S. 210-211.

[46] Vgl. Stiehl (2013), S. 111.

[47] Vgl. Becker u.a. (2012), S. 32.

[48] Vgl. Silver (2012), S. 64.

[49] Vgl. Palleduhn, Neuendorf (2013), S. 33.

[50] Vgl. Freund, Rücker (2012), S. 8-9.

[51] Vgl. Lipinski u.a. (2014).

[52] Vgl. Stiehl (2014_Vo), in Bezug auf Folie 17.

[53] Vgl. Krallmann und Trier (2013).

[54] XML = Extensible Markup Language

[55] Vgl. Karagiannis (2013).

[56] Vgl. Jürjens (2011), Folie 19.

[57] Vgl. Kloos (2014), S. 25.

[58] Vgl. Jürjens (2011), Folie 10.

[59] Vgl. Jürjens (2011), Folie 17.

[60] Vgl. Jürjens (2011), Folie 18.

[61] Vgl. Jürjens (2011), Folie 20.

[62] Vgl. Göpfert, Lindenbach (2013), S. 3, S. 12, S. 173.

[63] Vgl. Silver (2012), S. 3.

[64] Vgl. Freund, Rücker (2012), S. 108-112.

[65] Vgl. Palleduhn, Neuendorf (2013), S. 56.

[66] Vgl. Freund, Rücker (2012), S. 20.

[67] Vgl. Stiehl (2013), S. 31.

[68] Vgl. Silver (2012), S. 18.

[69] Vgl. Stiehl (2013), S. 65.

[70] Vgl. Ditze, Henninger (2014), S. 9.

[71] Vgl. Freund, Rücker (2012), S. 145-147.

[72] Vgl. Silver (2012), VI & S. 18.

[73] Vgl. Freund, Rücker (2012), S. 189.

Final del extracto de 91 páginas

Detalles

Título
Prozessgesteuerte Anwendungen entwickeln und ausführen mit BPMN
Subtítulo
Grundlagen, Konzepte und aktueller Stand
Universidad
University of Cooperative Education Mosbach
Calificación
1,3
Autores
Año
2014
Páginas
91
No. de catálogo
V281005
ISBN (Ebook)
9783656754138
ISBN (Libro)
9783656754121
Tamaño de fichero
7089 KB
Idioma
Alemán
Palabras clave
prozessgesteuerte, anwendungen, bpmn, grundlagen, konzepte, stand
Citar trabajo
Mandy Melanie Graß (Autor)Jürgen Boxberger (Autor), 2014, Prozessgesteuerte Anwendungen entwickeln und ausführen mit BPMN, Múnich, GRIN Verlag, https://www.grin.com/document/281005

Comentarios

  • No hay comentarios todavía.
Leer eBook
Título: Prozessgesteuerte Anwendungen entwickeln und ausführen mit BPMN



Cargar textos

Sus trabajos académicos / tesis:

- Publicación como eBook y libro impreso
- Honorarios altos para las ventas
- Totalmente gratuito y con ISBN
- Le llevará solo 5 minutos
- Cada trabajo encuentra lectores

Así es como funciona