Markenrecht

Produktnamen, Marken und Logos genannter Unternehmen werden in dieser Arbeit lediglich zum Zweck der Information dargestellt. Inhaber dieser Produktnamen, Marken und Logos sind die jeweiligen Firmen. Die Verwendung der Produktnamen, Marken und Logos der jeweiligen Firmen durch Dritte ± gleich in welcher Weise - ist unzulässig.

I

INHALTSVERZEICHNIS

  INHALTSVERZEICHNIS  I

  ABBILDUNGSVERZEICHNIS  III

TABELLENVERZEICHNIS III   

  ABKÜRZUNGSVERZEICHNIS  IV

1.  Einleitung  1

2.  Grundlagen - Begriffe rund um Geschäftsprozess und Workflow  3

2.1  Geschäftsprozess  3

2.2  Geschäftsprozessmodellierung  4

2.3  Workflow  5

2.4  Workflow-Modellierung  6

2.5  Prozessmanagement  7

3.  Rollenkonzepte  11

3.1  Praxisbeispiel: Rollen in ARIS 7.0  11

3.2  Theoretisches Konzept: Rollen in SAP  13

3.3  Neue Berufsbilder in der Praxis  16

4.  Notationen zur Prozessmodellierung  17

4.1  Einleitung  17

4.2  Bedeutung des Business Process Management (BPM)  17

4.3  Arten von Modellierungsnotationen  19

4.3.1  Fachliche Modellnotationen  19

4.3.2  Technische Modellnotationen  20

4.4  Vergleich der Notationen  24

4.4.1  Einleitung  24

4.4.2  BPMN  24

4.4.2.1  Aufbau  25

4.4.2.2  Struktur  30

4.4.3  BPEL  31

4.4.3.1  Aufbau  31

4.4.3.2  Struktur  34

4.4.4  Vergleich  35

4  4 4 1 Darstellungsfähigkeit  36

II

4.4.4.2  Kontrollflussunterscheidung  38

4.5  Überführungsstrategien  39

4.6  Zusammenfassung  41

5.  Automatisierte Prozessüberführung ARIS Business Architect  42

6.  Die Anwendung SAP  46

6.1  Einleitung  46

6.2  Der SAP Netweaver  47

6.3  Das SAP NetWeaver Composition Environment  52

6.3.1  Composite Applications  52

6.3.2  Das Composition Environment  53

6.4  Fazit  54

7.  Implementierung eines Geschäftsprozesses im SAP NetWeaver  55

8.  Schlussbetrachtungen  59

  LITERATURVERZEICHNIS  

  VI  

  ANHANG  

X

III

  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 für 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  Überführungsstrategien BPMN zu BPEL  

Tabelle 4-6  Überführungsstrategien BPEL zu BPMN  

ABKÜRZUNGSVERZEICHNIS

AG Aktiengesellschaft ANF Anforderung ARIS BW Business Information Warehouse BWW IBM ehemals: International Business Machines IDEF

1. Einleitung

Die Anforderungen an die heutige Informationstechnik werden immer komplexer. Um den wirtschaftlichen Erfolg des Unternehmens nicht zu gefährden, müssen Veränderungen schnell, effizient und kostengünstig umgesetzt werden. Typischerweise stehen die implementierten Funktionalitäten jeweils nur in einem in sich geschlossenen System zur Verfügung. Die Kommunikation und der Austausch zwischen solchen Systemen gestaltet sich oft problematisch und ist mit einem hohen Aufwand verbunden. Dadurch sind wertvolle Funktionalitäten in ihren Systemen isoliert und müssen unnötigerweise mehrfach entwickelt werden.

¹ Abbildung 1: Workflow-Technologie: Evolution der Anwendungsentwicklung

Gleichzeitig kann die Informationstechnik zur Automatisierung von

Unternehmensabläufen genutzt werden. Diese Arbeitsabläufe (Prozesse) überschreiten jedoch inzwischen die Grenzen einzelner Anwendungen oder gar die des Unternehmens. Solche übergreifende Prozesse zu automatisieren ist schwierig und teuer.

¹ Quelle: Kloppmann et al. (2000), S. 26

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 zunächst die grundlegenden Begriffe aus der Welt der Geschäftsprozesse und Workflows dargelegt.

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

Anschließend werden gängige Notationen zur Prozessmodellierung vorgestellt, die auch von SAP verwendet werden.

Modellnotationen sind essentieller Bestandteil der Bestrebungen, eine möglichst IOH[LEOH DEHU HLQGHXWLJH Ä6SUDFKH³ ]XU 0RGHOOLHUXQJ YRQ *HVFKlIWVSUR]HVVHQ ]X schaffen um diese in IT-Systemen implementieren zu können.

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.

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

Für die dieser Arbeit zu Grunde liegende SAP Anwendung wurde das Netweaver CE gewählt, da dies der aktuelle Stand von SAP hinsichtlich Geschäftsprozessmodellierung darstellt.

,QVWDOOLHUW ZXUGH KLHUIU GDV Ä(+3 IRU 6$3 1HWZHDYHU &RPSRVLRQ (QYLURQPHQW ² ³LQGHU7ULDO9ersion.

Beispieldiagramme in BPMN wurden mittels einer Trial-Version des Ä%XVLQHVV ³ 3URFHVV9LVXDO$UFKLWHFW³YRQ3Dradigm International erstellt.

² Quelle: www.sdn.sap.com ³ Quelle: http://www.visual-paradigm.com

2. Grundlagen - Begriffe rund um Geschäftsprozess 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 präzisierender Definitionen. Die vorliegende Arbeit beschränkt sich auf die gängigen Begriffsbestimmungen der Wirtschaftsinformatik.

2.1 Geschäftsprozess

Im Rahmen des Business Reengineering derfinieren Hammer und Champy den Geschäftsprozess als eine Menge von Aktivitäten, für die ein oder mehrere unterschiedliche Inputs benötigt werden und die für den Kunden ein Ergebnis von ⁴ Wert erzeugen (sog. Wertschöpfung).

Nach Österle ist der Geschäftsprozess eine Abfolge von Aufgaben, die über mehrere organisatorische Einheiten verteilt sein können und deren Ausführung von informationstechnologischen Anwendungen unterstützt wird. Als spezielle Form der Ablauforganisation konkretisiert der Geschäftsprozess die Geschäftsstrategie und verknüpft sie mit dem Informationssystem. Daher kann der Geschäftsprozess als Bindeglied zwischen der Unternehmensstrategie und der Systementwicklung bzw. ⁵ den unterstützenden Informationssystemen gesehen werden. Scheer und Jost gehen noch tiefer und verstehen unter einem Geschäftsprozess die modellhafte Beschreibung der in einem Unternehmen durchzuführenden Funktionen in ihrer inhaltlichen und zeitlichen Abfolge. Unter Funktionen werden einzelne Aufgaben und Tätigkeiten verstanden, die wiederum über die sie ⁶ auslösenden bzw. von ihnen erzeugten Ereignisse verknüpft werden. Marilyn Pratt, Business Process Experting der SAP Community definiert, einen Geschäftsprozess als "a set of activities transforming a defined business input into ⁷ a defined business result."

⁴ Vgl. Hammer (1993), S. 35 ⁵ Vgl. Österle (1995), S. 19 ⁶ Vgl. Scheer (1996), S. 29 ⁷ Vgl. https://www.sdn.sap.com/

Die aufgeführten Definitionen geben ein Beispiel der unterschiedlichen Perspektiven und Abstraktionsgrade mit denen der Begriff Geschäftsprozess in der Literatur definiert wird. Im weiteren Verlauf wird die folgende, zusammenfassende Definition zugrunde gelegt:

Ein Geschäftsprozess ist eine zielgerichtete, zeitlich-logische Abfolge von Aufgaben, die arbeitsteilig von mehreren Organisationen oder Organisationseinheiten unter Nutzung von Informations- und Kommunikationstechnologien ausgeführt werden können. Er dient der Erstellung von Leistungen entsprechend den vorgegebenen, aus der Unternehmensstrategie abgeleiteten Prozesszielen. Ein Geschäftsprozess kann formal, auf unterschiedlichen Detaillierungsebenen und aus mehreren Perspektiven beschrieben werden. Ein höchstmöglicher Detaillierungsgrad der Beschreibung ist dann erreicht, wenn die ausgewiesenen Aufgaben je in einem Zug von einem Mitarbeiter ohne Wechsel des Arbeitsplatzes 8 ausgeführt werden können .

2.2 Geschäftsprozessmodellierung

Die Geschäftsprozessmodellierung als Unterstützungsinstrument des Prozessmanagements umfasst die Konstruktion, Wartung und Anwendung von konzeptionellen Modellen der Geschäftsabläufe von Unternehmen und Verwaltungen. Sie dient der Anwendungssystem- und Organisationsgestaltung aus ⁹ der Sicht der betrieblichen Abläufe.

Aufgabe der Geschäftsprozessmodellierung kann daher als die Dokumentation betrieblicher Abläufe gesehen werden mit dem Ziel, die Abläufe einer inhaltlichen Diskussion zugänglich zu machen. Das heißt, die Modelle werden in erster Linie von Menschen für Menschen erstellt, um eine Diskussion sachgerecht zu ¹⁰ ermöglichen.

Prozessmodelle sind semi-formal, diagramm-basiert (zur graphischen Anordnung), nicht direkt ausführbar und dienen in erster Linie der Erklärung und Visualisierung

⁸ Vgl. Gehring (1999), S. 3 ⁹ Vgl. Becker (2008) ¹⁰ Vgl. Wittges (2004), S. 13

¹¹ Eine Übersicht gängiger diagrammbasierter Methoden erfolgt von Abläufen. nachfolgend:

¹² Abbildung 2-1: Diagrammbasierte Modellierungsmethoden

2.3 Workflow

Nach Galler und Scheer ist der Workflow eine Verfeinerung des betriebswirtschaftlichen Geschäftsprozesses in technischer Hinsicht. Kriterium für den Grad der Verfeinerung ist die Automatisierbarkeit: Der Workflow muß als Input und Regelwerk für die Steuerung durch ein Workflow-Management-System verwendbar sein. Im Rahmen des Architekturkonzepts für integrierte Informationssysteme ordnen sie den Workflow der Ebene des Datenverarbeitungs-Konzeptes und den Geschäftsprozess der anwendernäheren Fachkonzept-Ebene ¹³ zu.

Österle beschreibt den Workflow als einen verfeinerten Geschäftsprozess, der die detaillierte Form als Mikro- Prozess darstellt; anstelle einer Fachkraft übernimmt nun der Computer die Ablaufsteuerung. Die Aufgaben sind so detailliert, dass sie ¹⁴ von den Prozessmitarbeitern als Arbeitsanweisung umgesetzt werden können.

¹¹ Vgl. Krallmann (2008) ¹² Qelle: Gadatsch, (2003), S. 81 ¹³ Vgl. Galler (1995), S. 21 ¹⁴ Vgl. Österle (1995), S. 45

Ein Workflow kann daher definiert werden als ein formal beschriebener, ganz oder teilweise automatisierter Geschäftsprozess. Er beinhaltet die zeitlichen, fachlichen und ressourcenbezogenen Spezifikationen, die für eine automatisierte Steuerung des Arbeitsablaufes auf der operativen Ebene erforderlich sind. Die Arbeitsschritte sind hierbei so detailliert, dass sie zur Ausführung durch Mitarbeiter oder durch 15 Anwendungsprogramme geeignet sind.

2.4 Workflow-Modellierung

Im Rahmen der Workflow-Modellierung werden aus semi-formalen

Geschäftsprozessmodellen der Fachebene automatisiert ausführbare Workflow-Spezifikationen erstellt. Dabei steht der Übergang von den wirtschaftlich motivierten Prozessmodellen der Fachebene zu den technischen Modellen der Workflowausführung im Mittelpunkt.

Ausführbare Workflows müssen eine detaillierte Spezifikation aufweisen und damit eine präzise maschinengestützte 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 ¹⁶ Die wichtigsten sind derzeit die Business Process Modeling Language Einsatz.

(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 Übersetzung eines fachlichen Prozessmodells aus einem Prozessvisualisierungswerkzeug in ein Workflow-Management-System. Dieser Vorgang wird als Transformation bezeichnet.

¹⁵ Vgl. Gehring (1999), S. 4 ¹⁶ Vgl. Mendling (2003), S. 163

2.5 Prozessmanagement

Im Prozessmanagement wird generell zwischen Geschäftsprozess- und Workflowmanagement unterschieden. Während beim Management der Geschäftsprozesse 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 ¹⁷ Prozessmanagement ist damit ein zentraler Bestandteil Organisationsgestaltung. für ein gesamtheitliches Konzept des Geschäftsprozess-und ¹⁸ Workflowmanagements.

Um die Qualität in einer solchen gesamtheitlichen Prozessarchitektur zu gewährleisten können bei der Modellierung der Prozesse die Grundsätze ordnungsmäßiger Modellierung (GoM) angewandt werden. Die GoM sind begrifflich an die Grundsätze ordnungsmäßiger Buchführung angelehnt und sollen die Erhöhung und Sicherstellung der Qualität der Modelle gewährleisten bei gleichzeitiger Reduzierung der Komplexität. Abbildung 3 zeigt den möglichen Einsatz von Prozessmodellen, wobei die Prozesse unter GoM-Gesichtspunkten modelliert werden sollten:

¹⁷ Vgl. Gadatsch 2008, S. 1-3 ¹⁸ Vgl. Becker et al. (2002), S. 52ff

¹⁹ Abbildung 2-2: Einsatz von Prozessmodellen

Viele IT-Lösungsanbieter sehen in einem servieceorientierten Ansatz das Architekturparadigma der Zukunft. So untersuchte das Analystenhaus Gartner, das 2007 mehr als die Hälfte der unternehmenskritischen Anwendungen in führenden Unternehmen Konzepte einer serviceorientierten Architektur nutzen. Bis 2010 sollen sogar 80% ihrer Anwendungsportfolios auf einer SOA-Architektur ²⁰ Bei SOA handelt es sich um ein Paradigma für die Strukturierung und aufbauen.

Nutzung verteilter Funktionalität, die von unterschiedlichen Besitzern verantwortet wird. Es ist ein Managementkonzept für eine dienstorientierte Architektur der

²¹ Bei einer

Informations- und Kommunikationssysteme (IKT) einer Unternehmung. solchen serviceorientierung steht nicht ein Softwareprodukt im Mittelpunkt, sondern eine langfristige, strategische Neuausrichtung der unternehmensweiten IT-Architektur.

¹⁹ Quelle: Eigene Darstellung in Anlehnung an Becker et al. (1998 und 2002) ²⁰ Vgl. PC Welt (2008) ²¹ Vgl. OASIS (2008)

Einen Schritt weiter geht das Business Process Management (BPM). Es synchronisiert die Bereiche Planung, Entwurf, Konstruktion, Produktion, Instandhaltung, Nachverfolgung und Anpassung der gesamten Prozesse in einer ²² BPM verfolgt einen ganzheitlichen Managementansatz und wird Organisation. ²³ GDKHUDXFKEHWUDFKWHWDOVÄHYROXWLRQRI62$QRWDVZLWFK³. Abbildung 2-3 zeigt, wie BPM-Werkzeuge dazu verwendet werden können um Geschäftsprozesse durch die Orchestrierung der Tätigkeiten zwischen Mensch und System in einem Unternehmen zu implementieren. Während diese Grafik dabei eine allgemeine Darstellung eine BPM-Architektur zeigt, bezieht sich Abbildung 2-4 auf die spezielle Architektur des SAP NetWeaver.

²⁴ Abbildung 2-3: BPM Service Orchestrierung

²² Vgl. Wikipedia Business Process Management (2009) ²³ Vgl. Puneet (2008) ²⁴ Quelle: Enterprise Architecture (2007)

10

  25  

  Abbildung 2-4: SAP NetWeaver SOA Architektur  

25  Quelle: www sdn sap com  

3. Rollenkonzepte

Prozessmanagement ist durch das Zusammenspiel einer Vielzahl von Beteiligten in unterschiedlichen Rollen auf verschiedenen Ebenen des Unternehmens geprägt. In der Literatur finden sich zwar zahlreiche Vorschläge, wie die Verantwortlichkeiten

zu verteilen sind, jedoch definiert jedes Unternehmen die Rollen letztendlich nach den Bedürfnissen 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.

3.1 Praxisbeispiel: Rollen in ARIS 7.0

In der Praxis ist der Prozessverantwortliche jedoch oftmals jene Person, die fachlich für das jeweilige Thema zuständig ist, unabhängig seiner Position im Unternehmen. Abbildung 3 zeigt einen Auszug aus dem aktuellen ²⁷ Betriebshandbuch eines Münchener Unternehmens welches als

Modellierungstool ARIS 7.0 der Firma IDS-Scheer AG verwendet:

²⁶ Vgl. Hammer (1994), S. 108

²⁷ Der Name des Unternehmens wurde aus Datenschutzrechtlichen Gründen unkenntlich gemacht. Im Vorliegenden wird der fiktive Name GreenAG verwendet.

3.2 Theoretisches Konzept: Rollen in SAP

Das Rollenkonzept von SAP Systemen unterscheidet sich naturgemäß vom Rollenbegriff in ARIS, da dort der Fokus auf BPM liegt. Dies liegt daran, dass SAP zwar Geschäftsprozesse technisch abbildet, aber darüber hinaus noch zusätzliche Aufgaben erfüllen muss.

Während ARIS ausschließlich der Designphase dient, muss SAP auch die ITIL 'LV]LSOLQHQ Ä'HVLJQ³ ÄhEHUIKUXQJ³ ]% &KDQJH- und Releasemanagement ),

Ä2SHUDWLRQV%HWULHE³ $FFHss Managent, Incident Management, etc.) und ²⁸ Ä9HUEHVVHUXQJ³6HUYLFH&RQWUROXPVHW]HQ

Diese zusätzlichen Anforderungen führen somit zu Funktionen und damit Rollen in SAP, die über die eigentlich implementierten Geschäftsprozessrollen hinaus gehen bzw. Rollen in der IT implementieren, die für die ITIL-Konformität nötig sind.

Zusätzliche Komplexität kann sich auch dadurch ergeben, dass es auf Grund von rechtlichen, revisionstechnischen oder aufsichtsrechtlichen Bestimmungen nötig ist, Gewaltenteilungen in Form von z.B. Vier-Augen-Prinzipien umzusetzen. So ist der Process-Owner in ARIS bzw. BPM zwar der Eigentümer eines Prozesses, darf ihn aber ggf. nicht ohne eine zweite Person bzgl. seiner Systemimplementierung ohne Einschränkungen ändern und gleichzeitig benutzen um Missbrauch zu vermeiden oder Fehlerpotential zu minimieren. (Beispiel: Prozessänderungen an einem Transaktionsprozess, Anlage von Konten und Benutzung der Überweisungsfunktion)

Während also BPM und damit auch ARIS das Design eines Geschäftsprozesses und der Prozessrollen (und deren Inhalte) zum Ziel haben, muss die Implementierung ins SAP beispielsweise verhindern können, dass Rolleninhaber größere Rechte haben, als sie für die Ausführung ihrer jeweiligen Rolle unbedingt benötigen. Dies führt 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 dürfen sie jedoch nicht mit den sog. Portalrollen verwechselt werden.

SAP stellt Standardrollen zur Verfügung, erlaubt aber dem Prozessdesigner auch zusätzliche Rollen zu implementieren.

Der Prozessdesigner definiert zusätzlich, wann die Zuweisung von Benutzern auf Prozessrollen abgeschlossen ist. Diese kann beim Erstellen der Prozessinstanz erfolgen, während der Prozesslaufzeit oder per automatischer Zuweisung auf die Prozessrolle selber.

²⁸ Die Bewertung der Rollen erfolgte in Anlehnung an das ITIL Framework

Folgende Guided Procedure Rollen (GP Rollen) sind in SAP standardmäßig ²⁹ vorhanden:

x Prozessinstanzen warten

In Ergänzung der Standardrollen können folgende Rollen während der Designphase angepasst werden:

Aktionen oder Blöcke sehen.

Portal Rollen

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

²⁹ Vgl. http://help.sap.com/

Die Zuweisung von Benutzern auf GP Portalrollen ist eine Administrationstätigkeit, die mit der User Management Konsole des SAP Netweaver Portals durchgeführt wird.

Beispiele für die vordefinierten GP Portalrollen sind:

sein

Darüberhinaus stellt SAP Rollen bereit, die während der Designphase von Prozessmodellen in SAP von Bedeutung sind. Hierbei ist z.B. eine Unterteilung der %HQXW]HULQÄ%DVLF8VHU³Ä$GYDQFHG8VHU³XQGÄ([SHUW8VHU³P|JOLFKXP5HFKWH auch innerhalb der Designphase einzuschränken bzw. zu steuern.

3.3 Neue Berufsbilder in der Praxis

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

4. Notationen zur Prozessmodellierung

4.1 Einleitung

Bei der Zusammenstellung der Services und der entsprechenden Prozesse werden durch den fachlichen und technischen Bereich unterschiedliche Beschreibungssprachen verwendet. Mit diesen Beschreibungssprachen bzw. Modellierungsnotationen ist es möglich Modelle mit fachlicher oder technischer Ausprägung zu erstellen. Schwerpunkt dieses Kapitels sind die bereichstypischen

Modellnotationen und deren Modelle, wie sie in SAP Anwendung finden. Dabei wird auch auf die Unterstützung durch das Business Process Management eingegangen. Kapitel 4 soll einen Überblick über 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 losgelösten Prozessmodellierung und

Prozesszusammenstellung verfolgt. Durch geeignete BPM Werkzeuge (z.B. Process Engines) wird das entstehende Prozessmodell abgearbeitet und zur Ausführung gebracht. Diese Werkzeuge kombinieren entsprechend dem Prozessmodell die physischen Dienste miteinander. Somit erweitert das BPM eine SOA. Der fachliche Bereich soll bei Prozessänderungen nicht mehr auf die IT angewiesen sein, da die Modellumsetzung von BPM Werkzeugen übernommen wird. Damit schrumpft zwar die Bedeutung der herkömmlichen Programmierung und Applikationsentwicklung, denn Prozessänderungen werden durch die Ausführungstools in die IT abgebildet. In dieser Idee soll sich die IT nur noch mit der Implementierung der Services beschäftigen. Die Schnittstellen zwischen Fachabteilung und IT wird jedoch auch ein BPM nicht vermeiden können.

Diese rein fachliche Umsetzung von Prozessmodellen lässt sich nicht so einfach realisieren, da die BPM Ausführungstools nur Modelle mit ausreichenden

30

technischen Details sinnvoll umsetzen können. Somit ist eine reine

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

Modellüberführung ohne technische Erweiterung zumindest gegenwärtig nicht möglich. Der technische Bereich wird dazu benötigt, die durch den fachlichen Bereich modellierten Modelle mit den nötigen technischen Details anzureichern, damit die BPM Ausführungstools dieses Modell sinnvoll umsetzen können. Hierbei ist es üblich, dass der technische Bereich auf Grundlage des fachlichen Prozessmodells ein neues technisches Prozessmodell entwickelt, welches durch eine Process Engine abgearbeitet bzw. ausgeführt wird. Bei einer solchen Modellneuentwicklung durch den technischen Bereich entstehen oft jedoch Überführungsfehler, da durch die technische Fokussierung notwendige fachliche Merkmale oft nicht berücksichtigt werden. Die Vision eines BPM liegt darin, die Prozessmodelle in der IT möglichst ohne Überführungsfehler abzubilden.

Durch eine manuelle Überführung der Prozessmodelle ist dies jedoch nur sehr bedingt möglich. Dieses Problem könnten durch eine einheitliche Modellnotation gelöst werden, die sowohl vom fachlichen als auch vom technischen Bereich genutzt wird. Damit wäre eine Überführung überflüssig und Überführungsfehler könnten nicht auftreten. Jedoch scheint es zur Zeit noch keine Notation zu geben welche die verschiedenen Anforderungen gleichermaßen erfüllt. Daher muss jeweils ein Werkzeug für jeden Bereich eingesetzt werden. Diese Modellierungswerkzeuge unterstützen den jeweiligen Bereich in ihrer Arbeit am besten und liefern durch höhere 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 überführen.

Im folgenden Kapitel wird auf die automatisierte Überführung 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 Processoriented 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

Zunächst werden Modellierungsnotationen für 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 Fließtext

Geschäftsprozesse können durch Fließtext beschrieben werden, da man durch eine einfache Sprache alle Elemente und Verbindungen eines Geschäftsprozesses darstellen kann.

Der Prozess kann sowohl völlig umgangssprachliche dargestellt als auch auf Basis von Geschäftsprozessformularen beschrieben werden. Die sprachliche Modellierung unterliegt lediglich den syntaktischen Normen der jeweiligen Landessprache. Durch Geschäftsprozessformulare lässt 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 Universität Saarbrücken 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 auslösen. Durch

31

geeignete Verknüpfungsoperatoren kann die Prozesskette verzweigt werden. Erweiterte Ereignisgesteuerte Prozessketten (eEPK) enthalten zusätzlich Informationsobjekte und Organisationseinheiten (Abbildung 4-1). Dabei werden jeder Funktion die beteiligten Informationsobjekte und die ausführende Einheit in der Organisation zugeordnet.

³¹ Vgl. Keller et al. (1992), S.10-11, S. 15