Subjektorientiertes Geschäftsprozessmanagement

Transkript

1 Werner Schmidt, Albert Fleischmann, Oliver Gilbert Subjektorientiertes Geschäftsprozessmanagement Verbale Beschreibungen von Sachverhalten einer betrieblichen Wirklichkeit, die in Software abgebildet werden sollen, bestehen in der Regel aus Sätzen mit Subjekt, Prädikat und Objekt. Die meisten formalen Methoden zur Modellierung von Geschäftsprozessen und Anwendungssystemen vernachlässigen einen oder mehrere dieser Satzteile. Dies erschwert die Implementierung und behindert insbesondere die automatische Generierung von ausführbarem Code. Mit der Subjektorientierung wird ein Ansatz vorgestellt, der die Handelnden in Geschäftsprozessen (Personen und Systeme als Subjekte), ihre Handlungen (Prädikate) und Ziele bzw. Gegenstände ihrer Handlungen (Objekte) ausgewogen betrachtet. Der Ansatz eignet sich prinzipiell für alle Phasen des integrierten Business-Process-Management-Zyklus. Im Beitrag wird konkret auf die subjektorientierte Modellierung, Validierung und Implementierung eingegangen. Die Methodik stützt sich auf eine grafische Notation, die mit wenigen Diagrammen und Symbolen auskommt und der eine klar formalisierte Semantik zu Grunde liegt. Letztere erlaubt u.a. die automatische Generierung ausführbarer Programme durch geeignete Werkzeuge. Es wird gezeigt, dass sich die aus dem Ansatz abgeleiteten Implementierungsaspekte gut für den Aufbau Serviceorientierter Architekturen (SOA) eignen. Ein Fallbeispiel illustriert den praktischen Einsatz der Methode. Inhaltsübersicht 1 Integrierter Business-Process-Management-Zyklus 2 Subjektorientierter Ansatz 2.1 Einordnung 2.2 Grundgedanke und Herkunft 2.3 Modellierung eines Prozesses 2.4 Validierung eines Prozesses 2.5 Implementierung eines Prozesses Organisatorische Implementierung IT-Implementierung 2.6 Unterstützung Serviceorientierter Architekturen 2.7 Werkzeugunterstützung 3 Praxisbeispiel 3.1 Fallbeschreibung: Genehmigung von internen Forschungsprojekten bei SAP Research 3.2 Modellierung und Validierung 3.3 Implementierung Organisatorische Implementierung IT-Implementierung 4 Fazit 5 Literatur 1 Integrierter Business-Process-Management-Zyklus Das Business Process Management (BPM) oder Geschäftsprozessmanagement stellt in seinen Grundzügen einen klassischen Managementprozess dar. Das Managementobjekt bilden dabei die Geschäftsprozesse, die den Managementaktivitäten in einem Regelkreis mit den Phasen Analyse, Modellierung, Validierung, Optimierung, organisatorische Implementierung, IT-Implementierung, Verifikation und Abnahme sowie Betrieb und Monitoring unterzogen werden. Situativ sind dabei ggf. Rückkopplungen in frühere Phasen nötig. Abbildung 1 zeigt den Regelkreis mit begleitenden Aktivitäten wie Projektmanagement und Changemanagement und mit ihn umgebenden Rahmenbedingungen wie Unternehmensstrategie, BPM-Strategie, IT-Strategie etc. 1 Die Managementaktivitäten dieses integrierten Business-Process-Management-Zyklus beziehen sich immer auf eine Geschäftsprozessbeschreibung mit Subjekt, Prädikat und Objekt. Dies entspricht der Realität, in der ein Mensch Geschäftsprozesse üblicher Weise in natürlicher Sprache, also in kompletten Sätzen mit Subjekt, Prädikat und 1 Detaillierte Ausführungen zum integrierten BPM-Zyklus findet man bei [Schmidt 2009]. 1

2 Objekt, beschreibt. Für einen Auftragserfassungsprozess würde jemand demgemäß auf einer relativ groben Ebene etwa Aussagen treffen wie "Der Vertriebssachbearbeiter erfasst den Kundenauftrag." Im Hinblick auf die einfachere Überführung von Geschäftsprozessbeschreibungen in Lösungen zur IT- Unterstützung kommen in der Praxis jedoch meist nicht mehr natürlichsprachliche, sondern formale Modellierungsmethoden zum Einsatz. Diese sind dadurch gekennzeichnet, dass sie häufig auf einzelne Satzteile wie die Objekte (z.b. bei Klassendiagrammen) oder die Prädikate (z.b. bei Ereignisgesteuerten Prozessketten) fokussieren und den jeweils anderen Satzteilen zu wenig Aufmerksamkeit widmen. Diese Vernachlässigung von Satzteilen behindert die weitgehend automatische Generierung von ausführbarem Code aus den Modellen. Im nächsten Abschnitt wird mit dem subjektorientierten Ansatz eine Methodik vorgestellt und auf ausgewählte Zyklusphasen bezogen, die geeignet erscheint, dieser Problematik durch eine ausgewogene Beachtung von Subjekt, Prädikat und Objekt zu begegnen. Unternehmensvision Unternehmensstrategie Corporate Governance BPM-Vision BPM-Strategie < Projektmanagement Aufbau des Prozesscontrollings Geschäftsprozess < < Change Management BPM-Kultur BPM-Governance IT-Vision IT-Strategie IT-Governance 2 Subjektorientierter Ansatz Abb. 1: Integrierter Business-Process-Management-Zyklus 2.1 Einordnung Ansätze zur Prozessmodellierung kommen aus der Entwicklung computergestützter Informationssysteme. Hier hat im Zeitablauf ein Paradigmenwechsel von der Funktions- über die Daten- zur Objektorientierung stattgefunden. Die verwendeten Modellierungssprachen setzen dementsprechend schwerpunktmäßig auf unterschiedliche Satzteile der natürlichen Sprache. Dies wiederum wirkt sich darauf aus, wie reibungslos sich die modellierten Prozesse automatisiert in Software bzw. Workflows umsetzen lassen. Abbildung 2 zeigt den Zusammenhang für eine Auswahl in der Praxis häufig eingesetzter Modellierungssprachen und die Methodik der Subjektorientierung (vgl. auch [Fleischmann 2007]). 2

3 A u s g e wählte M o d e l l i e r u n g s s p r a c h e n Natürliche Sprache Kontrollflussdiagramm (z.b. Programmablaufplan, Struktogramm) Ereignisgesteuerte Prozesskette (EPK) Erweiterte ereignisgesteuerte Prozesskette eepk) ( Entity Relationship Model (ERM) Unified Modeling Language (UML) Calculus of Communicating Systems (CCS) Business Process Modeling Notation (BPMN) Parallel Activity Specification Schema (PASS) mitsubjektinteraktionsdiagramm(sid) und Subjektverhaltensdiagramm (SVD) E n t w i c k l u n - g s p a r a d i g m a --- Funktions_ orientierung Funktionsorientierung Daten- Orientierung Funktionsorientierung Objekt_ orientierung Subjekt_ orientierung Funktions_ orientierung Subjekt_ orientierung Betrachtung von Subjekt ädikat Pr Objekt E r läu t e r u n g Sachverhaltsbeschreibung i.d.r. durch ganze Sätze (wer tut was woran?), Ausnahme: Passivstil Algorithmik (Schrittabfolge), Integration von Subjekten und Objekten i.d.r. nur durch natürlichsprachlicheergänzungen Kontrollflussorientierte Prozessdarstellung (Funktionen, Ereignisse) Ergänzung der EPK um Organisationseinheiten als Subjekte und Daten als Objekte Integration von Subjekten und Prädikaten nur indirekt durch disziplinierte Bezeichnung der Beziehungen Ursprünglich nur Betrachtung von Methoden (Prädikat) und Daten (Objekt), Beachtung der Subjekte erstmals als Akteure (in Anwendungsfalldiagrammen) und Swim Lanes(in Sequenzdiagrammen), die aber nicht weiter detailliert werden Prozessalgebra zur Modellierung paralleler Prozesse mit Subjekten, elementaren Aktionen (Senden, Empfangen) und Kommunikationsbeziehungen Enthält mit Poolkonzept und Nachrichten subjekt - orientierte Aspekte, der Schwerpunkt liegt jedoch auf Funktionen Kombination des Calculusof Communicating Systems mit der Objektorientierung und Einf ührung von zusätzlichen Operationen neben Senden und Empfangen Konsequenzen ü r f die I m p l e m e n- t i e r u n gvon S o f t w a r e / W o r k f l o w s Automatische Umsetzung in Code bisher nicht möglich Fehlende oder nicht ausreichende Beachtung eines oder mehrerer Sprachelemente führt zu unzulänglichen Anforderungsdefinitionen mit der Folge h äufiger Fehlinterpretationen bei der Implementierung, hohen Aufwands fü r das Hinzufügen der fehlenden Aspekte und beschränkter Möglichkeiten der automatischen Umsetzung von Modellen in Code Ausgewogene Beachtung aller Sprachelementeführt zu vollständigen Anforderungsspezifikationenund ermöglicht automatische Umsetzung von Modellen in Code Abb..2: Schwerpunkte ausgewählter Modellierungssprachen und Konsequenzen für die Implementierung von Software/Workflows 3

4 2.2 Grundgedanke und Herkunft Im Mittelpunkt der Betrachtung stehen die Subjete als an einem Prozess beteiligte Akteure. Dies können Menschen und Maschinen sein. Als Handelnde in Rollen lösen sie den Prozess aus und treiben ihn. Dabei erledigen sie ihre individuellen Teilaufgaben und kommunizieren untereinander, um ihr gemeinsames Handeln zur Erreichung des gewünschten Prozessergebnisses zu strukturieren und abzustimmen. In der Regel nutzen sie dazu geeignete Werkzeuge sowie Informations- und Geschäftsobjekte, auf die sie lesend und/oder schreibend zugreifen und die sie austauschen. Die subjektorientierte Methodik basiert auf einer Prozessalgebra zur Modellierung paralleler Prozesse mit Subjekten, elementaren Aktionen und Kommunikationsbeziehungen wie sie in den 1980er Jahren ursprünglich in der Informatik von [Milner 1980] und [Hoare 1985] vorgestellt wurde. Im Hinblick auf die praktische Verwendbarkeit der theoretischen Konzepte hat [Fleischmann 1994] u.a. eine grafische Notation ergänzt und Aspekte der Objektorientierung integriert. Die begriffliche Heraushebung des Subjekts bedeutet nicht, dass der Ansatz Prädikate und Objekte vernachlässigt. Vielmehr kommt dem Subjekt die Rolle des "primus inter pares" zu. 2.3 Modellierung eines Prozesses Gemäß der dargestellten Grundidee läuft die Modellierung im Wesentlichen in zwei Schritten mit zunehmendem Detaillierungsgrad ab: 1) Identifikation der Subjekte und ihrer Interaktionen Zunächst gilt es die am Prozess beteiligten Subjekte als prozessspezifische Rollen zu identifizieren und ihre Interaktionsbeziehungen, d.h. die zwischen ihnen ausgetauschten Nachrichten, darzustellen. Nachrichten können bei Bedarf formularartig strukturierte Informationen, sog. Geschäftsobjekte enthalten. Ergebnis des ersten Schritts ist ein nach Subjekten strukturiertes Modell mit expliziten Kommunikationsbeziehungen, das als Subjektinteraktionsdiagramm (SID) bezeichnet wird. Abbildung 3 zeigt ein einfaches Subjektinteraktionsdiagramm für die Beantragung einer Dienstreise. Mitarbeiter DR-Antrag Vorgesetzter genehmigter DR-Antrag Reisestelle Genehmigung Ablehnung Legende: Subjekt Nachricht Geschäftsobjekt DR = Dienstreise Abb. 3: Subjektinteraktionsdiagramm für den Prozess Dienstreiseantrag 2) Definition des Subjektverhaltens Der Modellierer verfeinert die Subjekte, in dem er ihr Verhalten als streng sequenzielle Reihenfolge ihrer Tätigkeiten und Interaktionen mit Hilfe von Zuständen und Zustandsübergängen (Transitionen) beschreibt. Mehrere Subjekte können parallel agieren und sich dabei über die Nachrichten synchronisieren. Ein Subjekt kann drei Zustände annehmen. Während der Sende- und Empfangszustand jeweils lediglich die Prädikate Senden und Empfangen zur Subjektinteraktion vorsieht, kann ein Subjekt in einem Funktionszustand beliebige andere Prädikate (Aktionen) ausführen. Den Prädikaten werden Services als klare fachliche Bedeutung eines Schrittes in einem Subjektverhalten zugeordnet. Dabei kann es sich um die Durchführung einer Berechnung ebenso handeln wie um eine Benutzerinteraktion zur Eingabe von Werten in ein Bildschirmformular. Mit Zustandsverfeinerungen (Refinements) kann man Zustände genauer definieren und damit den Subjekten z.b. Ressourcen wie Programme und Zugriffe auf Informationsobjekte in Datenbanken zuordnen oder Geschäftsregeln (Business Rules) für einzelne Schritte hinterlegen. Als Darstellungsmittel wird auf dieser Modellierungsebene das Subjektverhaltensdiagramm (SVD) verwendet. Ein solches Diagramm ist beispielhaft in Abbildung 4 für das Subjekt Mitarbeiter im Prozess Dienstreiseantrag dargestellt. 4

5 pers. Terminkalender Z DR-Antrag ausfüllen [DR-Antrag ausgefüllt] DR-Antrag an Vorges. senden [DR geändert] Legende: [an Vorges.: DR-Antrag] Funktionszustand Sendezustand [von Vorges.: Genehmigung] Z DR antreten Antwort von Vorges. empfangen [von Vorges.: Ablehnung] Z DR zurückziehen? [ja] Empfangszustand Infoobjekt [auf DR] [nein] Z Zustandsverfeinerung (Refinement) [.] Zustandsübergang DR ändern Prozessende Prozessende Prozessbeginn (aus Subjektsicht) Prozessende (aus Subjektsicht) Abb. 4: Subjektverhaltensdiagramm für das Subjekt Mitarbeiter im Prozess Dienstreiseantrag Zustandsübergänge geben jeweils Auskunft über das Ergebnis des vorherigen Zustands. Nach dem Funktionszustand "DR-Antrag ausfüllen" in Abbildung 4 lautet die Transition deshalb "DR-Antrag ausgefüllt". Nach Sendezuständen drückt der Übergang aus, an welches Subjekt welche Information geht, z.b. "an Vorges.: DR-Antrag". Umgekehrt zeigt die Transition nach einem Empfangszustand von welchem Subjekt welche Information kommt, also bspw. "von Vorges.: Genehmigung". Die Abbildung zeigt auch drei Zustandsverfeinerungen. Die erste führt bei "DR-Antrag ausfüllen" zum Aufruf eines Service, der die Zeit der Reise vorläufig in den persönlichen Terminkalender des Mitarbeiters einträgt. Das zweite und dritte Refinement beschreiben einen Service zur Änderung des Status von "vorläufig" auf "fest" nach der Genehmigung der Reise bzw. zum Löschen des Kalendereintrags nach der Ablehnung. 2.4 Validierung eines Prozesses Ein subjektorientiertes Prozessmodell kann durch ein IT-gestütztes Rollenspiel sofort interaktiv auf seine Richtigkeit aus Sicht der beteiligten Akteure getestet werden. Voraussetzung dafür ist, dass sich das Modell automatisch in ein ausführbares Programm umsetzen lässt, mit dem die Subjekte die Ablauflogik und den Informationsaustausch durchspielen können. Dies ist möglich, weil der vorgestellten grafischen Notation mit der oben angesprochenen, weiter entwickelten Prozessalgebra von Milner eine formal klare Semantik und damit maschinell interpretierbare Darstellung mit allen Satzteilen zu Grunde liegt. Durch die interaktive, computergestützte Art der Validierung bereits vor der Implementierung in Organisation und IT lassen sich sehr verlässlich und frühzeitig Fehler und Unzulänglichkeiten in der Modellierung erkennen und beheben und somit Implementierungsdauer und kosten positiv beeinflussen. 2.5 Implementierung eines Prozesses Organisatorische Implementierung Für die Einbettung eines Prozesses in die Aufbauorganisation müssen die Subjekte als prozessspezifische Rollen Aufgabenträgern im Organigramm zugeordnet werden. Aufgabenträger wie etwa ein Vertriebsleiter können die Aufgaben mehrerer Subjekte in verschiedenen Prozessen übernehmen und somit mehrere Rollen ausüben (z.b. Mitarbeiter und Vorgesetzter). Der Einbettungskontext, d.h. der organisatorische Zusammenhang der Aufgabenträger (z.b. Hierarchie), stellt sicher, dass etwa der Dienstreiseantrag nicht an irgendeinen Aufgabenträger mit der Rolle Vorgesetzter, sondern an die zuständige Führungskraft eines konkreten Mitarbeiters gerichtet wird IT-Implementierung 5

6 Das validierte Prozessmodell muss nicht nur organisatorisch sondern auch als computergestützter Workflow implementiert werden. Darin sollen die Beteiligten über geeignete Benutzerschnittstellen und die verwendeten Anwendungen gemäß der Geschäftsprozessdefinition zusammengeführt werden. Die subjektorientierte Prozessbeschreibung gibt die Struktur dafür vor: 1) Abbildung des Subjektverhaltens Das modellierte Subjektverhalten bestimmt die Prozesslogik, d.h. die Reihenfolge der Aktivitäten des Subjekts und die Aktivitäten selbst, welche als eindeutige fachliche Services definiert sind. Die Implementierung muss also eine Ablaufsteuerung erzeugen und Anwendungen bzw. Services einbinden, die die nötige fachliche Funktionalität liefern. Erstere kann man bspw. mit standardisierten Technologien wie JAVA oder der Business Process Execution Language (BPEL) realisieren. Services lassen sich durch Verlinkung, als Portlet, durch Methodenaufruf oder als Webservice integrieren. Auf diesem Weg werden bei Bedarf auch die menschlichen Benutzer in den Workflow einbezogen, in dem Services zur Darstellung von Benutzerschnittstellen angestoßen werden, etwa um die Eingabe von Daten in ein Geschäftsobjekt zu erledigen. 2) Abbildung der Subjektinteraktionen Subjekte interagieren und synchronisieren sich durch Nachrichtenaustausch. Jedes Subjekt besitzt dazu einen Input Pool, in dem Sendersubjekte Nachrichten ablegen können. Ein Input Pool ist ein parametrisierbarer Servicebaustein (Webservice) mit Einfüge- und Entnahmeoperationen zur Nutzung durch die Subjekte. 2.6 Unterstützung Serviceorientierter Architekturen (SOA) Mit der skizzierten Nutzung von Services bei Subjektverhalten und interaktionen bildet der subjektorientierte Ansatz eine solide Basis für den Aufbau Serviceorientierter Architekturen (SOA). Er verbindet bedarfsgerecht die beiden SOA-Steuerungskonzepte der Orchestrierung und Choreografie (vgl. [Decker et al. 2007, S. 296]). Die streng sequenziellen Dienste zur Realisierung des Subjektverhaltens werden orchestriert. Die Synchronisation der parallelen Aktivitäten mehrerer Subjekte mit Nachrichten, ggf. auch über Organisationsgrenzen hinweg, entspricht dem Prinzip der Choreografie. Konsequenz ist, dass Subjekte eines Prozesses auf unterschiedlichen IT- Plattformen bzw. Process Engines implementiert werden und ablaufen können. Lediglich die Kommunikation zwischen ihnen muss standardisiert über einen entsprechenden Webservice stattfinden. Insbesondere in historisch gewachsenen, heterogenen und komplexen IT-Landschaften wie sie für viele Unternehmen typisch sind, trägt der Ansatz damit dazu bei, die Ziele der SOA zu erreichen. Diese liegen darin, Softwaresysteme flexibler zu gestalten und einfacher und schneller an sich ändernde betriebliche Erfordernisse, insbesondere auf der Ebene der Geschäftsprozesse anzupassen [Reinheimer et al. 2008, S. 7 ff.]. 2.7 Werkzeugunterstützung Mit Lösungen und Werkzeugen wie ARIS, Bonapart, Adonis oder Sycat existiert eine Vielzahl von Tools, die kontollfluss- und objektorientiertes Prozessmanagement, nicht jedoch den subjektorientierten Ansatz unterstützen 2. Speziell für letzteren wurde deshalb die BPM-Suite der jcom1 AG entwickelt. Mit jpass! umfasst sie ein Modul für die subjektorientierte Modellierung, mit jlive! eine Lösung für die interaktive Validierung und mit jflow! eine Process Engine für die Ausführung von Geschäftsprozessen [JCOM1 2008]. Charakteristisches Kennzeichen ist der hohe Grad der Automatisierung bei der Generierung von Code. So können bspw. aus den mit jpass! modellierten Abläufen auf Knopfdruck Ablaufsteuerungen in Form von BPEL-Dateien erzeugt und sofort von beliebigen BPEL-fähigen Process Engines ausgeführt werden. Ebenso lässt sich aus dem Prozessmodell ohne Programmierung ein interaktives, webbasiertes Rollenspiel für die verteilte Validierung mit Hilfe von jlive! generieren. Schnittstellen erlauben den weitgehend reibungslosen Import und Export von Modellen anderer Tools, insbesondere von eepks aus ARIS. 3 Praxisbeispiel 3.1 Fallbeschreibung: Genehmigung von internen Forschungsprojekten bei SAP Research Aufgabe von SAP Research ist es, neue technische Entwicklungen zu identifizieren und zu verfolgen. Im Rahmen dieser Aufgabe wurde die subjektorientierte Vorgehensweise als ein betrachtenswerter Ansatz für das Geschäftsprozessmanagement gesehen. SAP Research hat deshalb diesen Ansatz evaluiert und es als lohnenswert empfunden ihn noch weiter praktisch zu untersuchen. Im Rahmen dieser Untersuchung wurde ein realer Prozess aus dem Umfeld von SAP Research beschrieben und implementiert. Diese Prozessimplementierung wird im Rahmen eines mehrmonatigen Wirkbetriebs noch näher untersucht. In den folgenden Abschnitten wird das Ergebnis der Implementierung unter Anwendung der vorgestellten Methodik und Tools erläutert. Bei dem zugrunde gelegten Praxisbeispiel handelt es sich um den sog. TOE-Prozess (Terms of Engagement) zur Beantragung von internen Forschungsprojekten zwischen SAP Research und der Produktentwicklung. Initiatoren (Transfer Project Lead) können Mitarbeiter beider Seiten sein. Anschließend wird das Vorhaben mit den 2 Ein guter Überblick über BPM-Tools findet sich in [Fraunhofer 2008]. 6

7 involvierten Organisationseinheiten inhaltlich (SAP Target Group Content) und budgetbezogen (SAP Target Group Budget via Business Development) abgestimmt. Sind diese Abstimmungen erfolgreich verlaufen, werden die Projektressourcen in Zusammenarbeit mit den Leitern der einzelnen Forschungslabors (Center Management) zusammengestellt. Ziel der Untersuchung war die effiziente Überführung des TOE-Prozesses in einen integrierten computergestützten Workflow. Damit sollte der Prozess standardisiert, die Transparenz über laufende Projektanträge für Leitung, Projektmanager und Controlling verbessert und die Durchlaufzeit verkürzt werden. Das entsprechende Projekt wurde mit der subjektorientierten Methodik und den dafür geeigneten, in Abschnitt 2.7 vorgestellten Werkzeugen durchgeführt. 3.2 Modellierung und Validierung Mit der in Abschnitt 2.3 dargestellten Vorgehensweise wurde der oben verbal beschriebene Sachverhalt modelliert. Ein Ausschnitt aus dem Subjektinteraktionsdiagramm ist in Abbildung 5 zu sehen. Legende: Center- Management Subjekt Nachricht Abb. 5: Subjektinteraktionsdiagramm für den TOE-Prozess Die beteiligten Subjekte wurden anschließend durch Beschreibung ihres Verhaltens detailliert. Abbildung 6 zeigt beispielhaft Teile der Verhaltensdiagramme für die interagierenden Subjekte Transfer Project Lead und Head of Research. So erfasst etwa das Subjekt Transfer Project Lead als Initiator nach der Diskussion des Projekts das TOE-Dokument (TOE-document ready), schickt die Startinformation an den Forschungsleiter, das Subjekt Head of Research, und einen TOE-Content-Request als Information an das Subjekt Business Development. Prozessbeginn für den Head of Research ist der Empfang der Startinformation vom Transfer Project Lead. Es folgt der Eingang der Genehmigungsanfrage vom Business Development usw. Ein Beispiel für ein Refinement im Verhalten des Transfer Project Lead ist ein Service im Sendezustand "Inform Head-of-Research". Er bewirkt, dass die zu versendende "Starting-Information" vollautomatisch aus dem TOE-Dokument extrahiert und in die Nachricht an den Head of Research eingebaut wird. 7

8 Transfer Project Lead Head of Research Legende: Empfangszustand Sendezustand Funktionszustand Zustandsübergang R Refinement (gefüllt) Abb. 6: Subjektverhaltensdiagramme für Transfer Project Lead und Head of Research (Ausschnitt) Im behandelten Prozess kommt das Geschäftsobjekt TOE zum Einsatz, das bei den Interaktionen zwischen den Subjekten alle für ein Forschungsprojekt relevanten Informationen aufnimmt (vgl. Abb. 7). Abb. 7: Auszug aus der Definition des Geschäftsobjekts TOE Für ein solches Geschäftsobjekt können mehrere Zustände und Sichten definiert sein. Diese steuern, welche Objektdaten für welche Subjekte sichtbar und modifizierbar sind und in welcher Lebenszyklusphase eines Geschäftsobjekts sie gelten oder notwendig sind. Beispielsweise sind die Budgetdaten im TOE-Objekt für bestimmte Subjekte ausgeblendet. Die Modellierer erzeugten aus dem fertigen Prozessmodell zunächst automatisch das interaktive rechnergestützte Rollenspiel. Im Rahmen der damit durchgeführten Validierung mit den Prozessbeteiligten wurde der Prozess mehrfach angepasst. 3.3 Implementierung Organisatorische Implementierung Die Einbettung des Prozesses in die Aufbauorganisation erfolgte unter der Verwendung des Lightweight Directory Access Protocol (LDAP)-Verzeichnisses der SAP AG. Dort sind die Mitarbeiter bestimmten Gruppen zugeordnet, auf welchen die Subjekte abgebildet wurden. So wurde z.b. das Subjekt Center Management der LDAP-Gruppe Lab Manager zugewiesen, welche die Leiter der Forschungslabore umfasst IT-Implementierung Der beschriebene Prozess stellte die Anforderungsdefinition für die Workflow-Anwendung dar. Die Umsetzung erfolgte gemäß den oben allgemein erläuterten Schritten: 1) Abbildung des Subjektverhaltens 8

9 Für das Verhalten aller acht Subjekte konnten Prozesslogik sowie Mechanismen zur Integration von Benutzeraktivitäten und Anwendungen oder Services auf Knopfdruck automatisch aus den entsprechenden Modellen generiert werden. Bei der Abwicklung von unterschiedlichen Prozessen oder mehreren Instanzen eines Prozesses zeigt die Engine dem einzelnen Bearbeiter an, für welche Prozesse bzw. Instanzen er Eingaben tätigen soll und bietet ihm dazu ggf. ein Geschäftsobjekt als elektronisches Formular an. Die folgende Abbildung enthält als Beispiel die automatisch erzeugte Oberfläche für das Subjekt Transfer Project Lead. Unter "My Tasks" sieht der Benutzer seinen Arbeitsvorrat, d.h. alle Prozessinstanzen, bei denen er agieren muss. Im Beispiel ist das lediglich ein Antrag für ein internes Forschungsprojekt. Im aktuellen Schritt "Content Negotiation/Initial discussion" wird der Benutzer im Bereich "What's to do?" aufgefordert, Details für den TOE-Content-Request zu erfassen, den er zur Abstimmung an das Subjekt SAP Target Group Content schickt (vgl. "Outbox"). Dazu öffnet die Engine das Geschäftsobjekt TOE (vgl. Definition in Abb. 7) im aktuellen Zustand TOE-Content- Request (vgl. Formularausschnitt "General Information" in Abbildung 8). Zusätzlich zu den vom Benutzer getätigten Eingaben werden auch Felder automatisch mit Werten aus dem LDAP-Verzeichnis befüllt. Abb. 8: Aufforderung der Process Engine zur Eingabe der TOE-Details An den benötigten Stellen im Prozess bindet die Engine zur Laufzeit SAP-Anwendungen durch Aufruf der entsprechenden Transaktionsoberfläche ein. Beispielsweise werden im Subjekt Project Management die SAP- Systeme ISP und Collaboration Projects (cproject bzw. cpro) verwendet. Abbildung 9 zeigt die Einbindung des letzteren innerhalb des Prozesses. 9

10 Abb. 9: Aufruf von cproject als externe Anwendung aus der Process Engine heraus 2) Abbildung der Subjektinteraktionen Auch die Kommunikation der Subjekte konnte automatisch auf die Steuerung durch die Process Engine abgebildet werden. Diese sorgt über den Aufruf der entsprechenden Webservices dafür, dass die zur Abarbeitung und Synchronisation nötigen Nachrichten übertragen werden. 4 Fazit Der TOE-Prozess im Praxisbeispiel konnte zeitnah modelliert, validiert und versuchsweise umgesetzt werden. Insbesondere zeigte sich dabei ein hoher Automatisierungsgrad bei der IT-Implementierung mit einfacher Einbindung von vorhandenen Services und Benutzern. Die vorgestellte Methodik und ihre Werkzeugunterstützung sind darüber hinaus auch in einer Reihe von Projekten vorwiegend in der Automobilindustrie und bei Finanzdienstleistern erfolgreich praktisch erprobt worden. Dabei hat sich bisher die zu Beginn geäußerte Einschätzung bestätigt, dass eine Prozessbeschreibung in ganzen Sätzen, das heißt mit sorgfältiger Berücksichtigung aller Satzteile, die automatische Generierung von sofort ausführbarem Code ermöglicht. Der subjektorientierte Ansatz liefert hierzu einen wertvollen Beitrag, weil er mit den Handelnden und ihren Interaktionen die Subjekte, mit deren Verhalten die Prädikate und mit den Informations- und Geschäftsobjekten die Objekte betrachtet. Weiterentwicklungsbedarf besteht in Bereichen wie der Erweiterung um Modellierungselemente zur Reduktion des Darstellungs- und Beschreibungsaufwands für sehr komplexes Subjektverhalten. Ein Beispiel wäre die rationelle Modellierung der Behandlung von Ausnahmeereignissen, die in vielen Zuständen auftreten können (z.b. geordneter Prozessabbruch). 5 Literatur [Decker et al. 2007] Decker, G., Kopp, O., Leymann, F., Weske, M.: BPEL4Chor: Extending BPEL for Modeling Choreographies, IEEE International Conference on Web Services, Salt Lake City, 2007, S [Fleischmann 2007] Fleischmann, A.: Subjekt, Prädikat und Objekt in der Grammatik der Software, Zugriff am

11 [Fleischmann 1994] Fleischmann, A.: Distributed Systems Software Design and Implementation. Springer- Verlag, Berlin, [Fraunhofer 2008] Spath, D., Weisbecker, A. (Hrsg.): Business Process Management Tools 2008 Fraunhofer Institut Arbeitswirtschaft und Organisation, Stuttgart, [Hoare 1985] Hoare, C.: Communicating Sequential Processes, Prentice Hall-Verlag, New Jersey, [jcom1 2008] jcom1 BPM Suite, Zugriff am [Milner 1980] Milner, R.: Calculus of Communicating Systems, Springer-Verlag, Berlin u.a., [Reinheimer et al. 2007], Reinheimer, S., Lang, F., Purucker, J., Brügmann, H.: 10 Antworten zu SOA. In: HMD - Praxis der Wirtschaftsinformatik, Heft 253, 2007, S [Schmidt 2009] Schmidt, W.: Integrierter Business-Process-Management-Zyklus, Arbeitsbericht der Hochschule für angewandte Wissenschaften FH Ingolstadt, Ingolstadt, 2009 (in Vorbereitung). Stichwörter Business Process Management, Geschäftsprozessmanagement, Subjektorientierung, Codegenerierung, SOA, Orchestrierung, Choreografie Dieser Artikel ist in verkürzter Version im Heft 266 der HMD ( vom April 2009 erschienen. 11