Workflow und Prozesse in SAP

INHALTSVERZEICHNIS

ABBILDUNGSVERZEICHNIS

TABELLENVERZEICHNIS

ABKURZUNGSVERZEICHNIS

1. Einleitung

2. Grundlagen - Begriffe rund um Geschaftsprozess und Workflow
2.1 Geschaftsprozess
2.2 Geschaftsprozessmodellierung
2.3 Workflow
2.4 Workflow-Modellierung
2.5 Prozessmanagement

3. Rollenkonzepte
3.1 Praxisbeispiel: Rollen in ARIS 7.0
3.2 Theoretisches Konzept: Rollen in SAP
3.3 Neue Berufsbilder in der Praxis

4. Notationen zur Prozessmodellierung
4.1 Einleitung
4.2 Bedeutung des Business Process Management (BPM)
4.3 Arten von Modellierungsnotationen
4.3.1 Fachliche Modellnotationen
4.3.2 Technische Modellnotationen
4.4 Vergleich der Notationen
4.4.1 Einleitung
4.4.2 BPMN
4.4.2.1 Aufbau
4.4.2.2 Struktur
4.4.3 BPEL
4.4.3.1 Aufbau
4.4.3.2 Struktur
4.4.4 Vergleich
4.4.4.1 Darstellungsfahigkeit
4.4.4.2 Kontrollflussunterscheidung
4.5 Uberfuhrungsstrategien
4.6 Zusammenfassung

5. Automatisierte Prozessuberfuhrung - ARIS Business Architect

6. Die Anwendung SAP
6.1 Einleitung
6.2 Der SAP Netweaver
6.3 Das SAP NetWeaver Composition Environment
6.3.1 Composite Applications
6.3.2 Das Composition Environment
6.4 Fazit

7. Implementierung eines Geschaftsprozesses im SAP NetWeaver

8. Schlussbetrachtungen

LITERATURVERZEICHNIS

ANHANG

ABBILDUNGSVERZEICHNIS

Abbildung 1 Workflow-Technologie: Evolution der Anwendungsentwicklung

Abbildung 2-1 Diagrammbasierte Modellierungsmethoden

Abbildung 2-2 Einsatz von Prozessmodellen

Abbildung 2-3 BPM Service Orchestrierung

Abbildung 2-4 SAP NetWeaver SOA Architektur

Abbildung 3 Praxisbeispiel: Rollendefinition fur ARIS

Abbildung 4-1 Erweiterte Ereignisgesteuerte Prozesskette

Abbildung 4-2 Grafische Objekte in einem BPD

Abbildung 4-3 Prozessstrukturen

Abbildung 4-4 Orchestrierung und Choreographie

Abbildung 4-5 BPEL Basis Konstrukte

Abbildung 4-6 BPEL Struktur

Abbildung 5-1 ARIS BPM Repository

Abbildung 5-2 Transaktionsaufrufe aus ARIS Business Architect for SAP

Abbildung 6-1 Bereiche des SAP NetWeaver

Abbildung 6-2 SAP NetWeaver Developer Studio

Abbildung 7 Beispielprozess

TABELLENVERZEICHNIS

Tabelle 4-1 Flow Objects

Tabelle 4-2 Connection Objects

Tabelle 4-3 Swimlanes

Tabelle 4-4 Artefacts

Tabelle 4-5 Uberfuhrungsstrategien BPMN zu BPEL

Tabelle 4-6 Uberfuhrungsstrategien BPMN zu BPEL

ABKURZUNGSVERZEICHNIS

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

Die Anforderungen an die heutige Informationstechnik werden immer komplexer. Um den wirtschaftlichen Erfolg des Unternehmens nicht zu gefahrden, mussen Veranderungen schnell, effizient und kostengunstig umgesetzt werden. Typischerweise stehen die implementierten Funktionalitaten jeweils nur in einem in sich geschlossenen System zur Verfugung. Die Kommunikation und der Austausch zwischen solchen Systemen gestaltet sich oft problematisch und ist mit einem hohen Aufwand verbunden. Dadurch sind wertvolle Funktionalitaten in ihren Systemen isoliert und mussen unnotigerweise mehrfach entwickelt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Workflow-Technologie: Evolution der Anwendungsentwicklung^[1]

Gleichzeitig kann die Informationstechnik zur Automatisierung von Unternehmensablaufen genutzt werden. Diese Arbeitsablaufe (Prozesse) uberschreiten jedoch inzwischen die Grenzen einzelner Anwendungen oder gar die des Unternehmens. Solche ubergreifende Prozesse zu automatisieren ist schwierig und teuer.

Diese Diplomarbeit befasst sich unter dem Thema Workflow und Prozesse in SAP mit dieser Problematik und versucht anhand dieser Anwendung den aktuellen Stand darzulegen.

Im Folgenden werden zunachst die grundlegenden Begriffe aus der Welt der Geschaftsprozesse und Workflows dargelegt.

Ein besonderes Augenmerk fallt dabei auch auf Rollenkonzepte und die unterschiedlichen Herangehensweisen, wie Unternehmen ihre Prozessrollen definieren.

AnschlieRend werden gangige Notationen zur Prozessmodellierung vorgestellt, die auch von SAP verwendet werden.

Modellnotationen sind essentieller Bestandteil der Bestrebungen, eine moglichst flexible aber eindeutige „Sprache“ zur Modellierung von Geschaftsprozessen zu schaffen um diese in IT-Systemen implementieren zu konnen.

Nach einem Vergleich der aktuell in der Wissenschaft diskutierten Notationen BPMN und BPEL widmet sich diese Arbeit dann auch der Transformation dieser. Ein Implementierungsbeispiel eines einfachen Prozesses in SAP rundet die Implementierungsdiskussion ab.

AbschlieRend werden die Erkenntnisse zusammengefasst und von einer eher unternehmerischen Perspektive her die Auswirkungen der Workflow Management Systeme auf die IT in Unternehmen angerissen.

Fur die dieser Arbeit zu Grunde liegende SAP Anwendung wurde das Netweaver CE gewahlt, da dies der aktuelle Stand von SAP hinsichtlich Geschaftsprozess- modellierung darstellt.

Installiert wurde hierfur das „EHP1 for SAP Netweaver Composion Environment 7.1“ in der Trial Version.^[2]

Beispieldiagramme in BPMN wurden mittels einer Trial-Version des „Business Process Visual Architect 2.4“ von Paradigm International erstellt.^[3]

2. Grundlagen - Begriffe rund um Geschaftsprozess und Workflow

Der Begriff Prozess und die damit verbunden Themen sind in der heutigen effizienzorientierten Gesellschaft zu Schlagworten geworden - sowohl in der Praxis, als auch in den meisten akademischen Disziplinen. Dabei erhebt jede Disziplin den Anspruch eigener prazisierender Definitionen. Die vorliegende Arbeit beschrankt sich auf die gangigen Begriffsbestimmungen der Wirtschaftsinformatik.

2.1 Geschaftsprozess

Im Rahmen des Business Reengineering derfinieren Hammer und Champy den Geschaftsprozess als eine Menge von Aktivitaten, fur die ein oder mehrere unterschiedliche Inputs benotigt werden und die fur den Kunden ein Ergebnis von Wert erzeugen (sog. Wertschopfung).^[4]

Nach Osterle ist der Geschaftsprozess eine Abfolge von Aufgaben, die uber mehrere organisatorische Einheiten verteilt sein konnen und deren Ausfuhrung von informationstechnologischen Anwendungen unterstutzt wird. Als spezielle Form der Ablauforganisation konkretisiert der Geschaftsprozess die Geschaftsstrategie und verknupft sie mit dem Informationssystem. Daher kann der Geschaftsprozess als Bindeglied zwischen der Unternehmensstrategie und der Systementwicklung bzw. den unterstutzenden Informationssystemen gesehen werden.^[5] Scheer und Jost gehen noch tiefer und verstehen unter einem Geschaftsprozess die modellhafte Beschreibung der in einem Unternehmen durchzufuhrenden Funktionen in ihrer inhaltlichen und zeitlichen Abfolge. Unter Funktionen werden einzelne Aufgaben und Tatigkeiten verstanden, die wiederum uber die sie auslosenden bzw. von ihnen erzeugten Ereignisse verknupft werden.^[6] Marilyn Pratt, Business Process Experting der SAP Community definiert, einen Geschaftsprozess als "a set of activities transforming a defined business input into a defined business result."^[7]

Die aufgefuhrten Definitionen geben ein Beispiel der unterschiedlichen Perspektiven und Abstraktionsgrade mit denen der Begriff Geschaftsprozess in der Literatur definiert wird. Im weiteren Verlauf wird die folgende, zusammenfassende Definition zugrunde gelegt:

Ein Geschaftsprozess ist eine zielgerichtete, zeitlich-logische Abfolge von Aufgaben, die arbeitsteilig von mehreren Organisationen oder Organisations- einheiten unter Nutzung von Informations- und Kommunikationstechnologien ausgefuhrt werden konnen. Er dient der Erstellung von Leistungen entsprechend den vorgegebenen, aus der Unternehmensstrategie abgeleiteten Prozesszielen. Ein Geschaftsprozess kann formal, auf unterschiedlichen Detaillierungsebenen und aus mehreren Perspektiven beschrieben werden. Ein hochstmoglicher Detaillierungsgrad der Beschreibung ist dann erreicht, wenn die ausgewiesenen Aufgaben je in einem Zug von einem Mitarbeiter ohne Wechsel des Arbeitsplatzes ausgefuhrt werden konnen ^[8] .

2.2 Geschaftsprozessmodellierung

Die Geschaftsprozessmodellierung als Unterstutzungsinstrument des Prozess- managements umfasst die Konstruktion, Wartung und Anwendung von konzeptionellen Modellen der Geschaftsablaufe von Unternehmen und Verwaltungen. Sie dient der Anwendungssystem- und Organisationsgestaltung aus der Sicht der betrieblichen Ablaufe.^[9]

Aufgabe der Geschaftsprozessmodellierung kann daher als die Dokumentation betrieblicher Ablaufe gesehen werden mit dem Ziel, die Ablaufe einer inhaltlichen Diskussion zuganglich zu machen. Das heiRt, die Modelle werden in erster Linie von Menschen fur Menschen erstellt, um eine Diskussion sachgerecht zu ermoglichen.^[10]

Prozessmodelle sind semi-formal, diagramm-basiert (zur graphischen Anordnung), nicht direkt ausfuhrbar und dienen in erster Linie der Erklarung und Visualisierung von Ablaufen.^[11] Eine Ubersicht gangiger diagrammbasierter Methoden erfolgt nachfolgend:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-1: Diagrammbasierte Modellierungsmethoden^[12]

2.3 Workflow

Nach Galler und Scheer ist der Workflow eine Verfeinerung des betriebswirtschaftlichen Geschaftsprozesses in technischer Hinsicht. Kriterium fur den Grad der Verfeinerung ist die Automatisierbarkeit: Der Workflow muS als Input und Regelwerk fur die Steuerung durch ein Workflow-Management-System verwendbar sein. Im Rahmen des Architekturkonzepts fur integrierte Informationssysteme ordnen sie den Workflow der Ebene des Datenverarbeitungs- Konzeptes und den Geschaftsprozess der anwendernaheren Fachkonzept-Ebene zu.^[13]

Osterle beschreibt den Workflow als einen verfeinerten Geschaftsprozess, der die detaillierte Form als Mikro- Prozess darstellt; anstelle einer Fachkraft ubernimmt nun der Computer die Ablaufsteuerung. Die Aufgaben sind so detailliert, dass sie von den Prozessmitarbeitern als Arbeitsanweisung umgesetzt werden konnen Ein Workflow kann daher definiert werden als ein formal beschriebener, ganz oder teilweise automatisierter Geschaftsprozess. Er beinhaltet die zeitlichen, fachlichen und ressourcenbezogenen Spezifikationen, die fur eine automatisierte Steuerung des Arbeitsablaufes auf der operativen Ebene erforderlich sind. Die Arbeitsschritte sind hierbei so detailliert, dass sie zur Ausfuhrung durch Mitarbeiter oder durch Anwendungsprogramme geeignet sind.^[15]

2.4 Workflow-Modellierung

Im Rahmen der Workflow-Modellierung werden aus semi-formalen Geschaftsprozessmodellen der Fachebene automatisiert ausfuhrbare Workflow- Spezifikationen erstellt. Dabei steht der Ubergang von den wirtschaftlich motivierten Prozessmodellen der Fachebene zu den technischen Modellen der Workflowausfuhrung im Mittelpunkt.

Ausfuhrbare Workflows mussen eine detaillierte Spezifikation aufweisen und damit eine prazise maschinengestutzte Interpretation erlauben. Hierzu sind skriptbasierte Methoden (Skriptsprachen) notwendig, die eine Beschreibung von Prozessmodellen mit einer an Programmiersprachen angelehnten formalen Notation erlauben. Bei der Spezifikation kommen zunehmend XML-Sprachen zum Einsatz.^[16] Die wichtigsten sind derzeit die Business Process Modeling Language (BPML) und Business Process Execution Language (BPEL) der Business Process Management Initiative (BPMI) sowie die XML Process Definition Language (XPDL) der Workflow Management Coalition (WfMC).

Entsprechend der zwei Modellierungsebenen (diagramm-basiert zu skript-basiert) vollzieht sich die Modellierung eines Workflows durch den idealerweise automatisierten Import bzw. die Ubersetzung eines fachlichen Prozessmodells aus einem Prozessvisualisierungswerkzeug in ein Workflow-Management-System. Dieser Vorgang wird als Transformation bezeichnet.

2.5 Prozessmanagement

Im Prozessmanagement wird generell zwischen Geschaftsprozess- und Workflowmanagement unterschieden. Wahrend beim Management der Geschaftsprozesse die Ableitung der strategischen Unternehmensplanung auf eine fachlich konzeptionelle Ebene erfolgt, bindet das Workflowmanagement die operative Ebene mit ein und beschreibt die notwendige Anwendungs- und Organisationsgestaltung.^[17] Prozessmanagement ist damit ein zentraler Bestandteil fur ein gesamtheitliches Konzept des Geschaftsprozess- und Workflowmanagements.^[18]

Um die Qualitat in einer solchen gesamtheitlichen Prozessarchitektur zu gewahrleisten konnen bei der Modellierung der Prozesse die Grundsatze ordnungsmaRiger Modellierung (GoM) angewandt werden. Die GoM sind begrifflich an die Grundsatze ordnungsmaRiger Buchfuhrung angelehnt und sollen die Erhohung und Sicherstellung der Qualitat der Modelle gewahrleisten bei gleichzeitiger Reduzierung der Komplexitat. Abbildung 3 zeigt den moglichen Einsatz von Prozessmodellen, wobei die Prozesse unter GoM-Gesichtspunkten modelliert werden sollten:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-2: Einsatz von Prozessmodellen^[19]

Viele IT-Losungsanbieter sehen in einem servieceorientierten Ansatz das Architekturparadigma der Zukunft. So untersuchte das Analystenhaus Gartner, das 2007 mehr als die Halfte der unternehmenskritischen Anwendungen in fuhrenden Unternehmen Konzepte einer serviceorientierten Architektur nutzen. Bis 2010 sollen sogar 80% ihrer Anwendungsportfolios auf einer SOA-Architektur aufbauen.^{[20] [20]} Bei SOA handelt es sich um ein Paradigma fur die Strukturierung und Nutzung verteilter Funktionalitat, die von unterschiedlichen Besitzern verantwortet wird. Es ist ein Managementkonzept fur eine dienstorientierte Architektur der Informations- und Kommunikationssysteme (IKT) einer Unternehmung.^[21] Bei einer solchen serviceorientierung steht nicht ein Softwareprodukt im Mittelpunkt, sondern eine langfristige, strategische Neuausrichtung der unternehmensweiten IT- Architektur.

Einen Schritt weiter geht das Business Process Management (BPM). Es synch ronisiert die Bereiche Planung, Entwurf, Konstruktion, Produktion, Instandhaltung, Nachverfolgung und Anpassung der gesamten Prozesse in einer Organisation.^[22] BPM verfolgt einen ganzheitlichen Managementansatz und wird daher auch betrachtet als „evolution of SOA, not a switch".^[23]

Abbildung 2-3 zeigt, wie BPM-Werkzeuge dazu verwendet werden konnen um Geschaftsprozesse durch die Orchestrierung der Tatigkeiten zwischen Mensch und System in einem Unternehmen zu implementieren. Wahrend diese Grafik dabei eine allgemeine Darstellung eine BPM-Architektur zeigt, bezieht sich Abbildung 2-4 auf die spezielle Architektur des SAP NetWeaver.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-3: BPM Service Orchestrierung^[24]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-4: SAP NetWeaver SOA Architektur^[25]

3. Rollenkonzepte

Prozessmanagement ist durch das Zusammenspiel einer Vielzahl von Beteiligten in unterschiedlichen Rollen auf verschiedenen Ebenen des Unternehmens gepragt. In der Literatur finden sich zwar zahlreiche Vorschlage, wie die Verantwortlichkeiten zu verteilen sind, jedoch definiert jedes Unternehmen die Rollen letztendlich nach den Bedurfnissen der eigenen Unternehmensstruktur und —kultur.

So wird beispielsweise nach Hammer und Champy ein Unternehmensprozess gesteuert durch einen Prozessverantwortlichen, der dem Kreis der oberen Managementebene entstammen soll.^[26]

3.1 Praxisbeispiel: Rollen in ARIS 7.0

In der Praxis ist der Prozessverantwortliche jedoch oftmals jene Person, die fachlich fur das jeweilige Thema zustandig ist, unabhangig seiner Position im Unternehmen. Abbildung 3 zeigt einen Auszug aus dem aktuellen Betriebshandbuch eines Munchener Unternehmens^[27] welches als Modellierungstool ARIS 7.0 der Firma IDS-Scheer AG verwendet:

Abbildung in dieser Leseprobe nicht enthalten

3.2 Theoretisches Konzept: Rollen in SAP

Das Rollenkonzept von SAP Systemen unterscheidet sich naturgemaR vom Rollenbegriff in ARIS, da dort der Fokus auf BPM liegt. Dies liegt daran, dass SAP zwar Geschaftsprozesse technisch abbildet, aber daruber hinaus noch zusatzliche Aufgaben erfullen muss.

Wahrend ARIS ausschlieRlich der Designphase dient, muss SAP auch die ITIL Disziplinen „Design“, „Uberfuhrung“ (z.B. Change- und Releasemanagement ), „Operations/Betrieb“ (Access Managent, Incident Management, etc.) und „Verbesserung“ (Service Control) umsetzen.^[28]

Diese zusatzlichen Anforderungen fuhren somit zu Funktionen und damit Rollen in SAP, die uber die eigentlich implementierten Geschaftsprozessrollen hinaus gehen bzw. Rollen in der IT implementieren, die fur die ITIL-Konformitat notig sind.

Zusatzliche Komplexitat kann sich auch dadurch ergeben, dass es auf Grund von rechtlichen, revisionstechnischen oder aufsichtsrechtlichen Bestimmungen notig ist, Gewaltenteilungen in Form von z.B. Vier-Augen-Prinzipien umzusetzen.

So ist der Process-Owner in ARIS bzw. BPM zwar der Eigentumer eines Prozesses, darf ihn aber ggf. nicht ohne eine zweite Person bzgl. seiner Systemimplementierung ohne Einschrankungen andern und gleichzeitig benutzen um Missbrauch zu vermeiden oder Fehlerpotential zu minimieren.

(Beispiel: Prozessanderungen an einem Transaktionsprozess, Anlage von Konten und Benutzung der Uberweisungsfunktion)

Wahrend also BPM und damit auch ARIS das Design eines Geschaftsprozesses und der Prozessrollen (und deren Inhalte) zum Ziel haben, muss die Implementierung ins SAP beispielsweise verhindern konnen, dass Rolleninhaber groRere Rechte haben, als sie fur die Ausfuhrung ihrer jeweiligen Rolle unbedingt benotigen. Dies fuhrt zu einem komplexeren Framework in SAP, das zumindest in der Lage sein muss, solche Anforderungen an Prozessimplementierungen umzusetzen.

Eine Prozessrolle in SAP definiert Tasks, die ein Benutzer auf Prozesse anwenden kann. Die Zuweisung von Prozessrollen geschieht bei der Initiierung des Prozesses in den Guided Procedure runtimes. (GP). Konzeptuell durfen sie jedoch nicht mit den sog. Portalrollen verwechselt werden.

SAP stellt Standardrollen zur Verfugung, erlaubt aber dem Prozessdesigner auch zusatzliche Rollen zu implementieren.

Der Prozessdesigner definiert zusatzlich, wann die Zuweisung von Benutzern auf Prozessrollen abgeschlossen ist. Diese kann beim Erstellen der Prozessinstanz erfolgen, wahrend der Prozesslaufzeit oder per automatischer Zuweisung auf die Prozessrolle selber.

Folgende Guided Procedure Rollen (GP Rollen) sind in SAP standardmaRig vorhanden:^[29]

Administrator

Der Administrator einer Rolle darf

- Benutzer Prozessrollen zuweisen
- Prozessinstanzen mit Hilfe der “GP administration tools” warten

Overseer

Der Overseer darf

- die Prozessinstanzen zur GP Laufzeit sehen
- alle Aktionen in einem Prozessblock sehen

Owner

Die Owen Roll ist identisch zum Superuser Konzept fur Prozesse und darf

- auf alle Schritte eines Prozesses zugreifen
- Prozessinstanzen warten

In Erganzung der Standardrollen konnen folgende Rollen wahrend der Designphase angepasst werden:

Execute Role:

- Diese Rolle wird automatisch fur den Action Processor angelegt, wenn man eine Aktion in einen Prozessblock einfugt.
- Auf Blockebene ist es moglich, die Rollen fur mehre Action Processors in einer Block Processor Rolle zu konsolidieren.

Display Role:

- Auf Prozesblockebene kann die Sichtbarkeit jeder Aktion innerhalb eines Blocks definiert werden.
- Die autorisierten Rollen konnen dann nur die jeweils relevanten Aktionen oder Blocke sehen.

Portal Rollen

Die GP stellen auch einen Anzahl von vordefinierten Portalrollen zur Verfugung, die die Zugriffsrechte von Benutzern auf vordefinierte Worksets steuern.

Die Zuweisung von Benutzern auf GP Portalrollen ist eine Administrationstatigkeit, die mit der User Management Konsole des SAP Netweaver Portals durchgefuhrt wird.

Beispiele fur die vordefinierten GP Portalrollen sind:

GP User:

- Der Benutzer, der Mitglied dieser Rolle ist, darf Prozesse initiieren und zugehorige Aktionen ausfuhren.
- Rechte zu Worksets mussen zusatzlich zugewiesen werden

GP Business Expert:

- Die Rolle gewahrt Zugriff auf die GP Design Werkzeuge
- Mit ihr wird fur das Mitglied das Design Time Workset auf dem Portal sichtbar. Zusatzlich muss der Benutzer aber in diesem Fall auch Mitglied der GP Basic User, Expert User oder Advanced User sein

Daruberhinaus stellt SAP Rollen bereit, die wahrend der Designphase von Prozessmodellen in SAP von Bedeutung sind. Hierbei ist z.B. eine Unterteilung der Benutzer in „Basic User", ,,Advanced User" und „Expert User" moglich, um Rechte auch innerhalb der Designphase einzuschranken bzw. zu steuern.

3.3 Neue Berufsbilder in der Praxis

Unter der Bezeichnung Business Process Expert (BPX) propagiert die SAP AG ein neues Berufsbild, fur das sie unter der URL http://bpx.sap.com sogar eine kostenfreie Internetcommunity eingerichtet hat. Das Profil des Business Process Expert umfasst demnach folgende Fahigkeiten und Kenntnisse:

- Fundierte Kenntnisse der Kernablaufe und Funktionen der Geschaftsbereiche
- Herausragende analytische Fahigkeiten
- Erfahrung im Sammeln von Anforderungen
- Erfahrung mit der Prozessmodellierung
- RoutinemaRiger Umgang mit MS Office

4. Notationen zur Prozessmodellierung

4.1 Einleitung

Bei der Zusammenstellung der Services und der entsprechenden Prozesse werden durch den fachlichen und technischen Bereich unterschiedliche Beschreibungs- sprachen verwendet. Mit diesen Beschreibungssprachen bzw. Modellierungs- notationen ist es moglich Modelle mit fachlicher oder technischer Auspragung zu erstellen. Schwerpunkt dieses Kapitels sind die bereichstypischen Modellnotationen und deren Modelle, wie sie in SAP Anwendung finden. Dabei wird auch auf die Unterstutzung durch das Business Process Management eingegangen. Kapitel 4 soll einen Uberblick uber die jeweiligen Modellnationen geben.

4.2 Bedeutung des Business Process Management (BPM)

Mit dem Business Process Management wird seitens der Fachabteilungen die Vision einer von der IT losgelosten Prozessmodellierung und Prozesszusammenstellung verfolgt. Durch geeignete BPM Werkzeuge (z.B. Process Engines) wird das entstehende Prozessmodell abgearbeitet und zur Ausfuhrung gebracht. Diese Werkzeuge kombinieren entsprechend dem Prozessmodell die physischen Dienste miteinander. Somit erweitert das BPM eine SOA. Der fachliche Bereich soll bei Prozessanderungen nicht mehr auf die IT angewiesen sein, da die Modellumsetzung von BPM Werkzeugen ubernommen wird. Damit schrumpft zwar die Bedeutung der herkommlichen Programmierung und Applikationsentwicklung, denn Prozessanderungen werden durch die Ausfuhrungstools in die IT abgebildet. In dieser Idee soll sich die IT nur noch mit der Implementierung der Services beschaftigen. Die Schnittstellen zwischen Fachabteilung und IT wird jedoch auch ein BPM nicht vermeiden konnen.

Diese rein fachliche Umsetzung von Prozessmodellen lasst sich nicht so einfach realisieren, da die BPM Ausfuhrungstools nur Modelle mit ausreichenden technischen Details sinnvoll umsetzen konnen.^[30] Somit ist eine reine Modelluberfuhrung ohne technische Erweiterung zumindest gegenwartig nicht moglich. Der technische Bereich wird dazu benotigt, die durch den fachlichen Bereich modellierten Modelle mit den notigen technischen Details anzureichern, damit die BPM Ausfuhrungstools dieses Modell sinnvoll umsetzen konnen. Hierbei ist es ublich, dass der technische Bereich auf Grundlage des fachlichen Prozessmodells ein neues technisches Prozessmodell entwickelt, welches durch eine Process Engine abgearbeitet bzw. ausgefuhrt wird. Bei einer solchen Modellneuentwicklung durch den technischen Bereich entstehen oft jedoch Uberfuhrungsfehler, da durch die technische Fokussierung notwendige fachliche Merkmale oft nicht berucksichtigt werden. Die Vision eines BPM liegt darin, die Prozessmodelle in der IT moglichst ohne Uberfuhrungsfehler abzubilden.

Durch eine manuelle Uberfuhrung der Prozessmodelle ist dies jedoch nur sehr bedingt moglich. Dieses Problem konnten durch eine einheitliche Modellnotation gelost werden, die sowohl vom fachlichen als auch vom technischen Bereich genutzt wird. Damit ware eine Uberfuhrung uberflussig und Uberfuhrungsfehler konnten nicht auftreten. Jedoch scheint es zur Zeit noch keine Notation zu geben welche die verschiedenen Anforderungen gleichermaRen erfullt. Daher muss jeweils ein Werkzeug fur jeden Bereich eingesetzt werden. Diese Modellierungswerkzeuge unterstutzen den jeweiligen Bereich in ihrer Arbeit am besten und liefern durch hohere Akzeptanz auch bessere Ergebnisse als ein gemeinsam nutzbares, aber unzureichendes Werkzeug.

Bei der getrennten Modellierung des fachlichen und technischen Bereiches, besteht daher die Herausforderung, die getrennt modellierten Modelle fehlerfrei ineinander zu uberfuhren.

Im folgenden Kapitel wird auf die automatisierte Uberfuhrung zwischen den fachlichen und technischen Modellen eingegangen. Dabei wird der Schwerpunkt auf jene Notationen gelegt, welche im SAP NetWeaver aktuell Verwendung finden.

Languages; Ouyang, Dumas, van der Aalst: From Business Process Models to Process- oriented Software Systems: The BPMN to BPEL Way?; Dumas: Case Study: BPMN to BPEL Model Transformation, etc.

4.3 Arten von Modellierungsnotationen

4.3.1 Fachliche Modellnotationen

Zunachst werden Modellierungsnotationen fur den fachlichen Bereich kurz skizziert. Es werden die Beschreibung durch Text, die EPK (Ereignisgesteuerte Prozesskette) und die BPMN (Business Process Modeling Notation) vorgestellt.

Beschreibung mit Hilfe von Fliefttext

Geschaftsprozesse konnen durch FlieRtext beschrieben werden, da man durch eine einfache Sprache alle Elemente und Verbindungen eines Geschaftsprozesses darstellen kann.

Der Prozess kann sowohl vollig umgangssprachliche dargestellt als auch auf Basis von Geschaftsprozessformularen beschrieben werden. Die sprachliche Modellierung unterliegt lediglich den syntaktischen Normen der jeweiligen Landessprache. Durch Geschaftsprozessformulare lasst sich die textuelle Beschreibung zum Teil formalisieren.

Ereignisgesteuerte Prozessketten (EPK)

Eine ereignisgesteuerte Prozesskette ist eine semiformale, grafische Modellierungssprache, die von Professor August W. Scheer an der Universitat Saarbrucken in Kooperation mit dem Softwareanbieter SAP im Jahre 1992 entwickelt wurde. EPK stellen prinzipiell eine Erweiterung der Petri Netze dar. Basis der einfachen EPK sind Ereignisse die Funktionen auslosen. Durch geeignete Verknupfungsoperatoren kann die Prozesskette verzweigt werden.^[31] Erweiterte Ereignisgesteuerte Prozessketten (eEPK) enthalten zusatzlich Informationsobjekte und Organisationseinheiten (Abbildung 4-1). Dabei werden jeder Funktion die beteiligten Informationsobjekte und die ausfuhrende Einheit in der Organisation zugeordnet.

Business Process Modeling Notation (BPMN)

Die Business Process Modeling Notation ist eine grafische Spezifikationssprache zur Geschaftsprozessmodellierung. Sie wurde im Jahr 2002 von Mitgliedern der Business Process Management Initiative (BPMI) entwickelt. Im Jahr 2005 wurde die Spezifikation BPMN 1.0 zur Weiterentwicklung an die Object Management Group (OMG) ubergeben. Ziel war es eine Notation zu erarbeiten, die sowohl vom Analysten (business analyst) als auch vom Entwickler (technical developer) einfach verstanden wird und somit die Lucke zwischen dem fachlichen Prozessdesign (business process design) und der Prozessimplementierung (process implentation) schlieRt^{[32] [33]}. Mit der BPMN werden fachliche Prozessdiagramme (business process diagram (BPD)) erstellt. Diese basieren auf Flussdiagrammen und sind auf die grafische Representation von Geschaftsprozessen zugeschnitten. Ein weiteres Ziel der Notation ist es, XML-basierte Ausfuhrungssprachen von Geschaftsprozessen mit Hilfe der BPD zu visualisieren. Die OMG verfolgt mit der BPMN das Ziel, alle vorhandenen Geschaftsprozessnotationen in BPMN zu konsolidieren.

4.3.2 Technische Modellnotationen

Dieser Abschnitt widmet sich den Modellnotationen des technischen Bereichs. Dabei liegt das Augenmerk auf den Notationen XML, WDSL und BPEL.

XML

XML (Extensible Markup Language) ist - wie auch HTML - eine vereinfachte Version der Standard Generalized Markup Language (SGML). Die Entwicklung von XML begann 1996 und seit Februar 1998 ist XML ein W3C-Standard. An der Entwicklung haben sich unter anderem Adobe, Hewlett-Packard, Microsoft, Netscape und Sun beteiligt.^[34]

Zentrales Anliegen fur den Einsatz von XML ist es, Inhalte maschinell zuganglich, auffindbar und manipulierbar zu machen. Um das zu erreichen, wird mit XML eine Moglichkeit gegeben, Inhalte uber kennzeichnende Markierungen in funktionale Blocke zu untergliedern. Diese Auszeichnungen werden tags genannt. Tags werden durch spitze Klammern gekennzeichnet, z.B.: <kapitel>. Wird von der Gesamtheit der tags gesprochen, spricht man von Markup.

XML ist eine Methode, um strukturierte Daten, wie z.B. Kalkulationstabellen und Adressbucher, in einer Textdatei darzustellen. Programme, die solche Daten erzeugen, konnen sie in einem Textformat, im einfachsten Fall in einem ASCII- Format, speichern. AuRerdem lassen sich strukturierte Daten auch uber Plattform-/ Betriebssystemgrenzen hinweg austauschen.

WDSL

Unter einem Web Service (webbasierten Dienst) versteht man eine eigenstandige, selbstbeschreibende und modulare Software Applikation, die im Internet veroffentlicht, lokalisiert und aufgerufen werden kann. Die Funktionalitat eines Web Service kann von einfachen Anwendungen bis hin zu komplexen Business Prozessen reichen. Die Beschreibung des Web Services und seine Kommunikation erfolgt mit Hilfe von XML-Vokabularen.^[35]

Die Web Service Decription Language (WSDL) ist ein XML-Vokabular, mit dem man Web Services, ihren Ort und ihre Methoden beschreiben kann. Die Beschreibung des Web Services ist unabhangig von der Implementierungssprache der Applikation und beschreibt zum Einen das Interface des Services und zum Anderen die Bindung dieses Interfaces an ein konkretes Protokoll. Somit kann ein Nutzer den Web Service aufrufen, ohne Implementierungsdetails wissen zu mussen.

Die Methoden des Services werden durch die eingehenden (input) und ausgehenden (output) Nachrichen charakterisiert. Die dabei benutzten Datentypen und -strukturen werden mit Hilfe eines XML-Schemas beschrieben, wobei man sowohl die vordefinierten Datentypen als auch eigene Typen benutzen kann.

In WSDL trennt man die abstrakten Definitionen der Interfaces (port types) mit den Methoden (operations) und Nachrichten (messages) des Dienstes von ihrer konkreten Beschreibung, wodurch die abstrakten Definitionen wiederverwendet werden konnen.

Eine konkrete Bindung an ein Netzwerkprotokoll erfolgt dann im ebenfalls wiederverwendbaren binding-Element. Hier werden Informationen uber die Kodierung und die physische Presentation der Daten festgelegt. Ein Web Service muss nicht zwingend mit dem Netzwerkprotokoll SOAP (Simple Object Access Protocol)^[36] zusammenarbeiten, es werden auch andere Protokolle wie zum Beispiel HTTP GET/POST und SMTP unterstutzt.

BPEL

BPEL (Business Process Execution Language) ist eine XML-basierte Sprache zur Beschreibung von Geschaftsprozessen basierend auf Web Services. BPEL (auch WSBPEL oder veraltet BPEL4WS) ist durch die Firmen IBM, Microsoft und Bea Systems entwickelt und durch OASIS standardisiert worden.^[37] Das Prozessmodell BPEL ist eine Kombination der XLANG (Web Services for Business Process Design) von Microsoft und der WSFL (Web Service Flow Language) von IBM. Es gibt zwei Moglichkeiten Geschaftsprozesse mit BPEL zu modellieren.

So wird mit dem ausfuhrbaren Geschaftsprozessmodell z.B. das Verhalten eines Teilnehmers an einer Geschaftsinteraktion dargestellt. Dabei steht die Komposition der Aktivitaten (Orchestrierung) und die Ausfuhrung des Prozesses durch eine entsprechende Engine im Mittelpunkt. Durch das abstrakte Geschaftsprozessmodell werden hingegen Prozesse modelliert, die z.B. den Nachrichtenaustausch zwischen mehreren Teilnehmern (Choreographie) koordinieren.^[38]

Mit BPEL ist es also moglich das Verhalten von ausfuhrbaren und abstrakten Prozessen zu modellieren und damit den Ablauf eines Geschaftsprozesses mit Hilfe von Choreographie und Orchestrierung zu beschreiben.

4.4 Vergleich der Notationen

4.4.1 Einleitung

Fur eine konsistente Modellierung einer vom fachlichen, wie technischen Bereich gemeinsam verwendeten Modelliernotation wurde es einer gemeinsam verwendeten Modellnotation bedurfen. Die Praxis zeigt jedoch, dass fur die unterschiedlichen Stadien eines Prozesses^[39] jeweils unterschiedliche Notationen verwendet werden. Jungste wissenschaftliche Arbeiten befassen sich daher mit den Moglichkeiten einer widerspruchsfreien Transformation zwischen verschiedenen Notationen, insbesondere aber auch mit der Entwicklung allgemein gultiger Transformationsstandards (conceptual mapping) fur Prozess Design (z.B. BPMN) und Prozess Ausfuhrung (z.B. BPEL) und der damit verbundenen semantischen Weiterentwicklung solcher Notationen.

Auch im SAP NetWeaver CE konnen Prozesse in unterschiedlichen Notationen dargestellt werden entsprechend dem Bedarf der jeweiligen Bereiche. Da jedoch aus der vorliegenden Trial-Version das verwendete Transformationskonzept nicht ersichtlich war, wird im Folgenden versucht in Anlehnung an die Arbeit von Jan Recker und Jan Mendling die Schwierigkeit einer widerspruchsfreien Uberfuhrung darzulegen. Dabei werden die Notationen BPMN und BPEL vorgestellt und versucht zu zeigen, dass eine kompromisslose Uberfuhrung nicht moglich ist.

4.4.2 BPMN

Das primare Ziel bei der Entwicklung dieser Notation war es, die Verstandlichkeit der entworfenen Geschaftsprozessdiagramme zu vereinfachen. Unabhangig vom verwendeten (BPMN-fahigen) Modellierungswerkzeug konnen so leicht lesbare und verstandliche Prozessdiagramme entwickelt werden. Dies wurde erreicht, indem existierende Notationen untersucht wurden und die besten Ideen in die Spezifikation einflossen^[40]. Daraus ist eine hohe Akzeptanz auf der Seite des fachlichen Bereiches abzuleiten.

4.4.2.1 Aufbau

Mit der BPMN werden Prozessdiagramme mit Hilfe von Symbolen erstellt. Die Diagramme bestehen aus einem Netzwerk von grafischen Objekten, welche die Aktivitaten und den Kontrollfluss eines Geschaftsprozesses reprasentieren. Hierbei beschrankt sich BPMN auf einige Basiselemente, die leicht unterscheidbar und aus anderen Notationen, wie z.B. UML, bekannt sind. Dadurch wird ein Prozessdiagramm leicht verstandlich und auch bei komplexen Modellen behalt der Modellierer stets den Uberblick. In Abbildung 4-2 wird ein Uberblick uber alle wichtigen Basiselemente in einem Geschaftsprozess gegeben:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-2: Grafische Objekte in einem BPD^[41]

Die Basiselemente werden nach ihrer Art und Funktion in vier verschiedene Gruppen eingeteilt:^[42]

1. Flow Objects

Die Auswahl der Elemente in der Gruppe „Flow Objects" wurde bewusst sehr klein gehalten um eine einfache und schnelle Modellierung zu ermoglichen. Da nur drei Basiselemente benotigt werden, erhoht sich so der Wiedererkennungswert bei komplexen Modellen.

2. Connection Objects

Die gerade beschriebenen Basiselemente der „Flow Objects" bilden das Grundgerust eines modellierten Geschaftsprozesses, dessen Elemente mithilfe der Connection Objects" miteinander verbunden werden:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4-2: Connection Objects

Basiselemente der Gruppen „Flow Objects" und „Connecting Elements" reichen aus, um einfache Prozessdiagramme zu erstellen. Durch die beschrankte Anzahl von Elementen sind solche Prozessdiagramme sehr leicht verstandlich und einfach zu modellieren. Fur detaillierte Prozessdiagramme konnen die Basiselemente mit Symbolen spezialisiert werden.

[...]

---

^[1] Quelle: Kloppmann et al. (2000), S. 26

^[2] Quelle: www.sdn.sap.com

^[3] Quelle: http://www.visual-paradigm.com

^[4] Vgl. Hammer (1993), S. 35

^[5] Vgl. Osterle (1995), S. 19

^[6] Vgl. Scheer (1996), S. 29

^[7] Vgl. https://www.sdn.sap.com/

^[8] Vgl. Gehring (1999), S. 3

^[9] Vgl. Becker (2008)

^[10] Vgl. Wittges (2004), S. 13

^[11] Vgl. Krallmann (2008)

^[12] Qelle: Gadatsch, (2003), S. 81

^[13] Vgl. Galler (1995), S. 21

^[14] Vgl. Osterle (1995), S. 45

^[15] Vgl. Gehring (1999), S. 4

^[16] Vgl. Mendling (2003), S. 163

^[17] Vgl. Gadatsch 2008, S. 1-3

^[18] Vgl. Becker et al. (2002), S. 52ff

^[19] Quelle: Eigene Darstellung in Anlehnung an Becker et al. (1998 und 2002)

^[20] Vgl. PC Welt (2008)

^[21] Vgl. OASIS (2008)

^[22] Vgl. Wikipedia Business Process Management (2009)

^[23] Vgl. Puneet (2008)

^[24] Quelle: Enterprise Architecture (2007)

^[25] Quelle: www.sdn.sap.com

^[26] Vgl. Hammer (1994), S. 108

^[27] Der Name des Unternehmens wurde aus Datenschutzrechtlichen Grunden unkenntlich gemacht. Im Vorliegenden wird der fiktive Name GreenAG verwendet.

^[28] Die Bewertung der Rollen erfolgte in Anlehnung an das ITIL Framework

^[29] Vgl. http://help.sap.com/

^[30] Siehe dazu die aktuelle Diskussion zur Transformation, z.B. Recher, Mendling: On the Translation between BPMN and BPEL: Conceptual Mismatch between Process Modeling

^[31] Vgl. Keller et al. (1992), S.10-11, S. 15

^[32] Quelle: http://images.google.de/

^[33] Vgl. OMG (2008), S.1

^[34] Vgl. W3C (2008)

^[35] Vgl. W3C (2001)

^[36] SOAP 1.2 ist ein Protokoll fur den Informationsaustausch in dezentralisierten, verteilten Systemen

^[37] Vgl. OSASIS (2007)

^[38] Vgl. Andrews (2003), S. 9

^[39] Vgl. z.B. Osterle, S. 23: der Kreislauf aus Analyse, Entwurf, Implementierung und Betrieb

^[40] Vgl. OMG (2008), S.4-6

^[41] Quelle: Eigene Darstellung in Anlehnung an Briol (2008), S. 22

^[42] Fur eine vollstandige Anfuhrung der Elemente siehe Anhang.