Lade Inhalt...

Webbasierte Projektmanagement-Tools. Blueprint zur Integration unter Verwendung service-orientierter Architekturen

Masterarbeit 2009 119 Seiten

Ingenieurwissenschaften - Wirtschaftsingenieurwesen

Leseprobe

Inhaltsverzeichnis

MANAGEMENT ABSTRACT

ABBILDUNGSVERZEICHNIS

TABELLENVERZEICHNIS

ABKÜRZUNGSVERZEICHNIS

DANKSAGUNG

1 EINLEITUNG
1.1 PROBLEMSTELLUNG UND ZIELSETZUNG
1.2 ABGRENZUNG
1.3 AUFBAU DER ARBEIT

2 GRUNDLAGEN
2.1 GESCHÄFTSPROZESS UND WORKFLOW
2.1.1 Begriff des Prozesses
2.1.2 Begriff des Geschäftsprozesses
2.1.3 Komponenten von Geschäftsprozessen
2.1.4 Begriff des Workflows
2.1.5 Gegenüberstellung von Geschäftsprozess und Workflow
2.1.6 Fazit
2.2 GESCHÄFTSPROZESSMODELLIERUNG (BUSINESS PROCESS MODELING)
2.2.1 ARIS-Architektur integrierter Informationssysteme
2.2.1.1 Modellierungskonzept
2.2.1.2 EPK Ereignisgesteuerte Prozesskette
2.2.1.3 Erweiterte Ereignisgesteuerte Prozesskette (eEPK)
2.2.1.4 Modellierungsregeln
2.2.2 BPEL oder BPEL4WS
2.2.2.1 Kontrollfluss eines BPEL-Prozesses
2.2.2.2 BPEL-Basiselemente
2.2.2.3 BPEL Activities
2.2.2.4 Beispiel von BPEL und WSDL
2.2.3 Fazit
2.3 SERVICE-ORIENTIERTE ARCHITEKTUREN (SOA)
2.3.1 Grundlegende Merkmale einer SOA
2.3.1.1 Lose Kopplung
2.3.1.2 Dynamisches Binden
2.3.1.3 Verzeichnisdienst
2.3.1.4 Verwendung von Standards
2.3.1.5 Einfachheit
2.3.1.6 Sicherheit
2.3.2 Merkmale einer SOA bzgl. komplexer Aspekte
2.3.3 Was ist eine Service-orientierte Architektur?
2.3.3.1 Die Sichtweise der Analysten
2.3.3.2 Die Definitionen der großen Hersteller
2.3.4 Service (Dienste) als Grundkomponente
2.4 DIE WICHTIGSTEN STANDARDS
2.4.1 Web Services
2.4.1.1 Definition Web Services
2.4.1.2 Web Service-Basistechnologie
2.4.1.3 Bestandteile einer Web Service-Architektur
2.4.1.3.1 Dienstanbieter (Service Provider)
2.4.1.3.2 Dienstnachfrager (Service Requestor)
2.4.1.3.3 Dienstmakler (Service Broker)
2.4.1.4 Aktionen
2.4.2 Grundlegende Standards SOAP, WSDL und UUDI
2.4.2.1 SOAP
2.4.2.1.1 Aufbau einer SOAP-Nachricht
2.4.2.1.2 SOAP-Verwandte
2.4.2.2 WSDL
2.4.2.3 UDDI (Verzeichnisdienste für Web Services)
2.5 WEB SERVICES SCHICHTENMODELL (WEB SERVICE ARCHITEKTUR)
2.6 SOA-ARCHITEKTURMODELL
2.6.1 Präsentation
2.6.2 Geschäftslogik
2.6.3 Datenbank und Applikationssysteme
2.6.4 Prozesslogik
2.6.5 Servicelogik
2.6.6 Sonstige Geschäftslogik
2.7 FAZIT
2.8 PROJEKTMANAGEMENT (PM) UND WEBBASIERTES PM-TOOL
2.8.1 Was ist ein Projekt?
2.8.2 Was ist Projektmanagement (PM)?
2.8.3 Webbasiertes PM-Tool
2.8.4 Funktionen von PM-Tool
2.8.5 Klassifikation von PM-Tool
2.8.6 Fazit

3 PROVENTIS GMBH
3.1 DAS PRODUKT-BLUE ANT (BA)
3.2 FAZIT

4 LÖSUNGSANSÄTZE FÜR EINE INTEGRATIONSPROBLEMATIK
4.1 INTEGRATIONSANSÄTZE
4.1.1 Point-to-Point-Architektur
4.1.2 Hub-and-Spoke-Architektur
4.1.3 Bus-/Pipeline-Architektur
4.1.4 Service-orientierte Architektur
4.2 INTEGRATION ARCHITEKTURE
4.2.1 Logische Integration
4.2.2 Enterprise Service Bus
4.2.2.1 Grundlegende Eigenschaften
4.2.2.2 Nachrichtenorientierte Middleware (MOM)
4.2.2.3 Integration basierend auf Standards
4.2.2.4 Die Entwicklung von ESB in den letzten Jahren
4.2.3 Data Integration
4.2.4 Prozess Integration
4.3 BESONDERHEIT EINER SOA-LÖSUNG
4.4 VORGEHENSWEISE
4.4.1 Top-Down
4.4.2 Bottom-Up
4.4.3 Meet-in-the-Middle
4.4.4 Schrittweise Einführung
4.5 ARCHITEKTUR SZENARIEN BLUE ANT-INTEGRATION
4.5.1 Blue Ant-Integration über AS/Broker–Web Services
4.5.2 Integration über ESB mit JBI
4.6 OPEN SOURCE SOA-STACK-BEWERTUNG
4.7 FAZIT

5 UMSETZUNG DER ARCHITEKTUR „ARBEITSZEITERFASSUNG“
5.1 WERKZEUGAUSWAHL
5.1.1 Integrationsarchitektur mittels ESB
5.1.2 Orchestrierungsebene
5.1.3 Service – Ebene
5.1.4 Modellierung
5.1.5 IDE (integrated development environment)
5.2 ENTWICKLUNGSUMGEBUNG
5.3 VORGEHENSWEISE BEI DER UMSETZUNG
5.3.1 Beschreibung der fachlichen Geschäftsprozesse
5.3.1.1 Arbeitszeiten im Backend-System erfassen
5.3.1.2 Arbeitszeiten im Blue Ant (BA)-System erfassen
5.3.2 Beschreibung der technischen Geschäftsprozesse
5.3.2.1 XML-Schema
5.3.2.2 WSDL
5.3.2.3 BPEL-Prozess
5.3.3 BPEL-Prozess compilieren und deployen
5.3.4 BPEL-Prozess testen
5.4 FAZIT

6 ZUSAMMENFASSUNG UND AUSBLICK

LITERATURVERZEICHNIS

Management abstract

Das Thema Integration ist durch die Ausbreitung von SOA aktueller denn je geworden. So-wohl die Ära der isolierten betrieblichen Informationssysteme auch als die der Silos, auch Stovepipe genannt, ist endgültig vorbei (vgl. Liebhart et al. 2008, S.1). Die Anwendung, die zu einem bestimmten Zweck erstellt worden ist, ohne dass sie sich mit anderen Systemen austauschen muss, ist unwahrscheinlich. Dies ist auch für die webbasierte Projektmanage-ment-Software „Blue Ant“ des jungen Berliner Beratungs- und Softwarehaus proventis GmbH der Fall.

Durch den Erfolg des Produkts im Enterpriseumfeld mit aktuellen Kunden, wie z.B. Porsche oder Berliner Bank, stellt sich für das Unternehmen in immer größerem Umfang die Notwen-digkeit, sich mit Integrationsproblematiken bzw. deren Lösungen im Enterpriseumfeld zu be-schäftigen, wobei aktuell kein Wissen vorhanden ist.

Als Standardarchitektur für die Integration setzt sich SOA mehr und mehr durch. Wobei SOA als Ganzes betrachtet, eine unterstützende Funktion für betriebliche Abläufe einer IT-Systemlandschaft darstellt. SOA ermöglicht es Prozesse einfacher und schneller zu gestal­ten und umzugestalten. Dadurch wird eine deutlich höhere Flexibilität erreicht. Darüber hin-aus stehen Dienste bzw. Services zur Verfügung, die in einer anderen Anwendung wieder verwendet werden können. Außerdem können neue Dienste und Produkte schneller am Markt eingeführt und bestehende Dienste schneller an neue Anforderungen angepasst wer-den. Dies führt dazu, dass die Kosten für Entwicklung und Wartung gesenkt werden können. Der Blueprint für die Systemintegration hilft bei der richtigen Umsetzung auf Basis von SOA, ohne das Gesamtbild einer flexiblen, skalierbaren, performanten und bezahlbaren Unter-nehmensarchitektur aus den Augen zu verlieren.

Abbildungsverzeichnis

Abbildung 2.1: Definition von Prozess (vgl. Schmelzer 2006, S. 60)

Abbildung 2.2: Definition von Geschäftsprozess (vgl. Schmelzer 2006, S. 60)

Abbildung 2.3: Komponenten von Geschäftsprozessen (vgl. Schmelzer 2006, S. 61)

Abbildung 2.4: Verfeinerung der Geschäftsprozesse im Workflow (vgl. Freund, 2004)

Abbildung 2.5: Geschäftsprozess vs. Workflow (vgl. Gadatsch 2005, S. 47)

Abbildung 2.6: Das ARIS-Haus (vgl. Gadatsch 2005, S. 114)

Abbildung 2.7: Standard Building Blocks von BPEL (vgl. Liebhart 2007, S. 19)

Abbildung 2.8: BPEL und ein Web Service (vgl. Liebhart 2007, S. 21)

Abbildung 2.9: SOA Tempel (vgl. Melzer et al. 2007, S. 11)

Abbildung 2.10: Web Service-Dreieck (vgl. Melzer et al. 2007, S. 52)

Abbildung 2.11: Protokoll Stack von Web Services (vgl. Liebhart et al. 2007, S. 295)

Abbildung 2.12: SOAP-Nachrichtenstruktur: (vgl. Liebhart 2007, S. 15)

Abbildung 2.13: WSDL-Dokument (Version 1.1) (vgl. Liebhart 2007, S. 16-17)

Abbildung 2.14: WSDL-Nachrichtentypen (WSDL 1.1) (vgl. Liebhart 2007, S. 17)

Abbildung 2.15: Die UDDI Business Registry (UBR) (vgl. Melzer et al. 2007, S. 149)

Abbildung 2.16: UDDI (vgl. Melzer et al. 2007, S. 52)

Abbildung 2.17: Web Services Stack (vgl. Melzer et al. 2007, S. 54)

Abbildung 2.18: Service-orientierte Softwarearchitektur (vgl. Mathas2008, S. 28)

Abbildung 4.1: Point-to-Point-Architketur (vgl. Liebhart et al. 2008, S. 24)

Abbildung 4.2: Hub-and-Spoke-Architektur (vgl. Liebhart et al. 2008, S. 26)

Abbildung 4.3: Bus-/Pipeline-Architektur (vgl. Liebhart et al. 2008, S. 27)

Abbildung 4.4: Service-orientierte Architektur (vgl. Liebhart et al. 2008, S. 28)

Abbildung 4.5: ESB-Aufbau nach dem JBI-Standard (vgl. Adelhardt, D., S. 18)

Abbildung 4.6 JBI Architektur (vgl. White, Spec JSR 208)

Abbildung 4.7: Blue Ant-Integration Passiv/Pull (eigene Darstellung)

Abbildung 4.8: Blue Ant-Integration über AS/Broker-Web Services (eigene Darstellung)

Abbildung 4.9: Ein Open Source SOA-Modell (vgl. Liebhart 2007, S. 56)

Abbildung 5.1: Oracle BPEL Process Manager (vgl. o.V., Copyright © 2004 Oracle)

Abbildung 5.2: Entwicklungsumgebung mit integrierter Oracle BPEL Designer

Abbildung 5.3: Top-Down-Ansatz (eigene Darstellung)

Abbildung 5.4: Arbeitszeiten im Backend-System erfassen (eigene Darstellung)

Abbildung 5.5: Arbeitszeiten im BA-System erfassen (eigene Darstellung)

Abbildung 5.6: XML-Schema der Arbeitszeiterfassung

Abbildung 5.7: XML-Schema des Fehlerfalls der Arbeitszeiterfassung

Abbildung 5.8: Auszug der WSDL-Datei für Arbeitszeiterfassung

Abbildung 5.9:BPEL-Prozess von Arbeitszeiterfassung

Abbildung 5.10 Veröffentlichung der WSDL-Datei

Abbildung 5.11:Anmeldemaske von BPEL Console

Abbildung 5.12: Oracle BPEL Console

Abbildung 5.13: Generiertes HTML-Formular

Abbildung 5.14: Ergebnis der asynchronen Kommunikation

Abbildung 5.15: Visueller Flow „Arbeitszeiterfassung“-Teil 1

Abbildung 5.16: Visueller Flow „Arbeitszeiterfassung“-Teil 2

Abbildung 5.17: Audit-Instanz für die Liste der „Arbeitszeiterfassung“

Tabellenverzeichnis

Tabelle 2.1: Notation der Grundelemente der EPK (vgl. Gadatsch 2005, S. 158)

Tabelle 2.2: Erweiterung der Notation der EPK (vgl. Gadatsch 2005, S. 160)

Tabelle 2.3: Aspekte der losen Systemkopplung (vgl. Mathas 2008, S. 21)

Tabelle 2.4: SOAP Fault Block (vgl. Melzer et al. 2007, S. 77)

Tabelle 4.1: Vorgehensweise bei der schrittweisen Einführung (vgl. Liebhart 2007, S. 174f)

Tabelle 4.2: Eine Auswahl von Open Source Tools für SOA (vgl. Liebhart 2007, S. 55)

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Danksagung

Ich widme diese Arbeit meiner geliebten kleinen Schwester und Freundin Aminata Diabaté, die am 15.12.2008 im Alter von nur 36 Jahren in meiner Heimat Mali von uns ging. Möge ihre Seele in Frieden ruhen.

An dieser Stelle möchte ich folgenden Personen für ihre Unterstützung bei der Erstellung dieser Masterarbeit danken.

Mein recht herzlicher Dank gilt meinem Betreuer Herrn Prof. Dr. Langenbacher für seine Un-terstützung und die zahlreichen wissenschaftlichen Ratschläge, die ich während dieser Mas-terarbeit von ihm erhalten habe.

Ein großer Dank gilt der Firma proventis GmbH, im Besonderen Herrn Frischmuth und Herrn Eckert für die Bereitstellung der nötigen Basisdokumentation und Infrastruktur.

Ein ganz herzlicher Dank gelten meinem Chef Herrn Friedrich, der trotz des stressigen Bera-terjobs, mir den Rücken in dieser Zeit freigehalten konnte, sowie meinem Arbeitskollegen Lars Bunge für die zahlreichen guten Ideen und Ratschläge, die Kritik und das Korrekturle-sen.

Besonderer Dank gebührt meiner Ehefrau Ina Hellmuth-Diabaté (Mäuschen), die mich wäh-rend des Studiums immer wieder motivierte und auf dem richtigen Weg hielt. Von Anfang an unterstützte sie mich beim Schreiben meiner Masterarbeit durch Zuhören, konstruktive Dis-kussionen und Korrekturlesen, so dass das Familienleben in dieser Zeit fast zum Erliegen kam. Vielen Dank für die persönlichen Entbehrungen.

Bedanken möchte ich mich auch bei meinen Eltern, die in Afrika leben und meinen neuen liebgewonnen Großeltern Omi und Opi in Warnsted, die mich immer wieder moralisch unter-stützten.

Ohne die genannten Personen wäre diese Arbeit nicht möglich gewesen.

1 Einleitung

Das Kernprodukt des 2001 gegründeten Berliner Beratungs- und Softwarehauses proventis GmbH ist die webbasierte Projektmanagement (PM)-Software Blue Ant, die derzeit in Deutschland, Österreich und in der Schweiz vertrieben wird. Blue Ant unterstützt den gesam-ten Projektlebenszyklus in einem durchgängigen Prozess von der Auftragserteilung über Termin- und Ressourcenplanung bis hin zum Nachweis der erbrachten Leistungen. Dabei folgt proventis dem Prinzip der Ganzheitlichkeit, in dem alle Beteiligten über die Software in die Projektarbeit einbezogen werden. Das steigert die Transparenz, verbessert die Kommu-nikation und macht die Projektarbeit für alle Beteiligten erfolgreicher. Somit können Kosten und Zeit eingespart werden (vgl. o.V. 2009, Produktinformation).

Aufgrund der zunehmenden Komplexitäten der Projekte und des immer kürzer werdenden Produktenlebenszyklus und deren Geschäftsprozesse ist für die erfolgreiche Durchführung eines Projekts ohne Unterstützung von PM-Software in den heutigen Zeiten nicht vorstellbar. Die Integration solcher Software oder Anwendungen in eine bestehende IT-Systemlandschaft mit ERP-Systemen, Data Warehouses oder Portal-Lösungen und den dort abgebildeten Geschäftsprozessen bringt zusätzliche Anforderungen an die Integrationsfähig-keit der eingesetzten Software, sowie die Verwendung von Standard Enterprise Integrations-Architekturen (z.B. SOA), mit sich. Dies kann nur mit zusätzlichem fachlichen und techni-schen Aufwand bewältigt werden.

Zu den oben genannten Herausforderungen kommt noch hinzu, dass die Unternehmen in der Lage sein sollten, auf Änderungen der Unternehmensstruktur flexibel reagieren zu kön-nen. Der Ansatz der serviceorientierten Architektur (SOA) mit Web Services verspricht, diese Aufgabe bewältigen zu können und dabei gleichzeitig die IT-Kosten zu senken.

1.1 Problemstellung und Zielsetzung

Durch den Erfolg des Produkts im Enterpriseumfeld mit aktuellen Kunden, wie z.B. Porsche, Berliner Bank, stellt sich in immer größerem Umfang für das Unternehmen die Notwendig-keit, sich mit Integrationsproblematiken bzw. deren Lösungen im Enterpriseumfeld zu be-schäftigen, wobei aktuell kein Wissen vorhanden ist.

Ziel der Masterarbeit soll es sein, einen grundlegenden Ansatz (konzeptionell sowie techno-logisch) für diese Problemstellung zu liefern, d.h. für diese Arbeit ergibt sich daraus für den praktischen Teil die Konzeption und Realisierung der Blue Ant-Web Sevices sowie die theo-retische Betrachtung eines möglichen Integrationsszenarios (trivial). Die Lösung wird nicht auf einen speziellen Kunden ausgerichtet, sondern soll als Basis für den Wissensaufbau in der Firma, sowie Blueprint (Blaupause) für Integrationsanforderungen von Kunden dienen.

Das Konzept soll für die Realisierung einer breiteren und flexibleren Integration von Blue Ant (BA) (Prototype bzw. Blaupause) mit Fremdsystemen bzw. Backendsysteme wie z.B. SAP, Zeiterfassungssystem-Datenbank oder Queue abgedeckt werden und die möglichen Lö-sungsansätze mit deren Vor- und Nachteilen darlegen zu können. Diese Integration basie-rend auf Standards wie ESB (Enterprise Service Bus), die gleichen Integrationskonzepte wie Enterprise Application Integration (EAI) nutzt oder BPEL Business Process Execution Lan­guage) für Web Service auch BPEL4WS (Business Process Execution Language for Web Service). Diese Integrationslösung soll dabei die Anforderungen eines Kunden erfüllen und mit einem vernünftigen Aufwand realisiert werden.

Um das erreichen zu können, wird der Geschäftsprozess „Arbeitszeiterfassung“ für die Integ­ration sowohl fachlich als auch technisch beschrieben. Danach wird ein Konzept erstellt, wie dieser Geschäftsprozess zu integrieren ist, dabei sind die möglichen Integrationsszenarien zu erläutern und darzulegen, anschließend folgt die Realisierung des Geschäftsprozesses „Arbeitzeiterfassung“. Abschließend ist die adäquate Werkzeugauswahl für die Realisierung auch Bestandteil der Zielsetzung.

1.2 Abgrenzung

Die Auswahl der standardisierten und bewährten Grundkomponenten mit Hilfe von Tools und Produkten für ein funktionierendes Ganzes basiert auf Open Source Produkten bzw. Soft­ware. Es wird in der Masterarbeit keine Prozess- bzw. Geschäftprozessanalyse eines realen Kunden durchgeführt, sondern als Grundlage wird ein „Metaprozess“ dienen.

Unter Metaprozess wird hier eine kleinstmögliche, allgemeingültige Prozesskette verstanden, die in Absprache mit der Firma proventis GmbH entwickelt wird.

Eine Integration unter Zuhilfenahme eines kommerziellen Brokers (z.B. IBM-WSBI, WebSphere Business Integration Server Foundation) ist grundsätzlich möglich und in den Unternehmen klar der favorisierte Weg, aber die Realisierung solcher Lösung ist aufwendig und kann nicht berücksichtig werden, weil diese den Rahmen dieser Arbeit sprengt.

1.3 Aufbau der Arbeit

In diesem Kapitel wird die Vorgehensweise dieser Arbeit beschrieben. Nach dem Abstract und der Einleitung werden in Kapitel 2 die wesentlichen Begriffe der Themenbereiche von Geschäftsprozessen, Workflow, Modellierungsmöglichkeiten sowie von SOA erläutert. Zu den Modellierungsmöglichkeiten wird auf zwei der bekanntesten Ansätze, den ereignisge-steuerten Prozessketten (EPK) von ARIS auf der fachlichen Ebene und BEL4WS (Business Process Execution Language for Web Services) kurz BPEL und BPML (Business Process Modeling Language) auf der technischen Ebene eingegangen. Außerdem werden standardi- sierte Services als Grundkomponente und der konsequente Einsatz der Standards SOAP, WSDL und BPEL als ausführbarer Geschäftsprozess den wesentlichen Bestandteil dieser Grundlage dargestellt. Danach wird auf das SOA Architekturmodell, das als ein Architektur-konzept für verteilte und lose gekoppelte Systeme zu verstehen ist und deren technische Bandbreite und Vielfalt ernorm sind, näher eingegangen. Abschließend werden Projektma-nagement (PM), webbasierte PM-Tools und deren Nutzen für die Abwicklung eines Projektes erläutert.

Anschließend werden in Kapitel 3 das 2001 in Berlin gegründete Software- und Beratungs-haus „proventis GmbH“ und deren 100%ig webbasierte Multi-Projektmanagementsoftware „Blue Ant“ dargestellt.

Darauffolgend werden in Kapitel 4 die Lösungsansätze für eine Integrationsproblematik wie Point-to-Point, Hub and Spoke, Pipeline und SOA skizziert. Außerdem wird die Umsetzung der Integration Architektur-Ebene mit ESB definiert. Für die Integration werden der Top-Down-, Bottom-Up-, Meet-in-the-Middle- Ansatz und die schrittweise Einführung beschrie-ben. Anschließend werden Architektur Szenarien Blue Ant-Integration und ein Open Source SOA-Stack als Basisinfrastruktur für die Realisierung von Anwendungen mit Open Source Tools und Frameworks für ein SOA-Modell dargestellt.

Anschließend wird in Kapitel 5 die Umsetzung der Architektur am Beispiel „Arbeitszeiterfas-sung“ zusammengefasst. Dabei werden die möglichen Werkzeuge für die Realisierung und die Entwicklungsumgebung aufgezeigt.

Die Arbeit wird in Kapitel 6 mit einer Zusammenfassung und einem Ausblick abgeschlossen.

2 Grundlagen

Dieses Kapitel fasst die Grundlage von Geschäftsprozessen, Workflow, Modellierungsmög-lichkeiten sowie von SOA zusammen. Dabei stellt der standardisierte Service Grundkompo-nente und der konsequente Einsatz der Standards SOAP, WSDL und BPEL den wesentli-chen Bestandteil dieser Grundlage dar.

2.1 Geschäftsprozess und Workflow

Hier werden die Geschäftsprozesse und Workflows definiert und der Unterschied zw. den beiden gegenübergestellt.

2.1.1 Begriff des Prozesses

Unternehmen erzeugen Leistungen, um die Bedürfnisse der Kunden befriedigen zu können. Die Vermarktung dieser Leistungen führen dazu, dass der wirtschaftliche Erfolg des Unter-nehmens gesichert werden kann.

Die Leistungen können Sach- oder Dienstleistungen sein und werden in Prozessen erstellt. Somit wird allgemein unter einem Prozess „eine Reihe von Aktivitäten verstanden, die aus einem definierten Input ein definiertes Ergebnis (Output) erzeugen“ (Schmelzer 2006, S. 58). Unter Input sind Einsatzfaktoren, wie z.B. Arbeitsleistung, Betriebsmittel (Maschinen, Ge-bäude), Energie, Werkstoffe (Roh-, Hilfs- und Betriebsstoffe) und Informationen zu verstehen und Output sind Produkte oder Dienstleistungen.

Im Zusammenhang mit Prozessen wird häufig auch von Lieferanten-Kunden- oder Input-Output-Beziehung gesprochen, aufgrund dessen, dass der Input von Lieferanten bereitge-stellt und der Output für Kunden bestimmt wird.

Nach DIN 66201 ist ein Prozess als „Umformung und/oder den Transport von Materie, Ener-gie und Informationen von einem Anfangszustand in einen Endzustand nach genau festge-legten Regeln“. Dabei wird der Prozess in den technischen Prozess für die Verarbeitung von Materie/Energie und in den Rechenprozess/Informatikprozess, für die Verarbeitung von In­formation, aufgeteilt (vgl. Schlingloff 2005, Folie 8).

Der Prozessbegriff reicht nicht aus um über die Begrenzung, Reichweite, Inhalte und Struk-tur des Prozesses sowie die Empfänger der Prozessergebnisse zu sprechen, sondern es wird erst über Prozess gesprochen, wenn wenige Aktivitäten oder Arbeitsschritte miteinander verknüpft sind, um ein Arbeitsergebnis erstellen zu können. In diesem Sinne laufen hunderte oder tausende von Prozessen innerhalb eines Unternehmens ab.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Definition von Prozess (vgl. Schmelzer 2006, S. 60)

2.1.2 Begriff des Geschäftsprozesses

In der Literatur findet sich eine Vielzahl verschiedener Definition für den Geschäftsprozess, die jeweils verschiedene Komponenten des Geschäftsprozesses hervorheben. Hammer und Champy definieren den Geschäftsprozess im Rahmen des Business Reengineering als „Menge von Aktivitäten, für die ein oder mehrere unterschiedliche Inputs benötigt werden und die für die Kunden ein Ergebnis von Wert erzeugen“ (Gadatsch 2005, S. 34). Die Ent-wicklung eines neuen Produkts wird als Beispiel von den beiden genannt.

Scheer und Jost verstehen unter Geschäftsprozess „die modellhafte Beschreibung der in einem Unternehmen durchzuführenden Funktionen in ihrer inhaltlichen und zeitlichen Ab-hängigkeit.“ (Gadatsch 2005, S. 34). Dabei ist unter Funktion die einzelne Aufgabe und Tä-tigkeit zu verstehen. Diese sind über Ereignisse, die von Ihnen ausgelöst wurden, miteinan-der verknüpft.

Der Begriff des Geschäftsprozesses wird von Scheer mit der Prozesskette und der Vor-gangskette gleichgestellt und somit wird der Akzent auf die funktionsübergreifende Eigen-schaft des Geschäftsprozesses gesetzt, der sich auf mehrere Funktionsschritte ausdehnt (vgl. Gadatsch 2005, S. 35).

Nach Österle ist der Geschäftsprozess „eine Abfolge von Aufgaben, die über mehrere orga-nisatorische Einheiten verteilt sein können und deren Ausführung von informationstechnolo-gischen Anwendungen unterstützt wird. (vgl. Gadatsch 2005, S. 35). Österle betrachtet dem Geschäftsprozess als Bindeglied zwischen der Unternehmensstrategie und der Systement-wicklung bzw. den unterstützenden Informationssystem.

Nach Berkau werden Prozesse in betriebliche Geschäftsprozesse und technische Prozesse aufgeteilt. Unter den betrieblichen Geschäftsprozessen sind kaufmännische Tätigkeiten, wie z.B. die Bearbeitung von Kundenaufträgen oder Einstellung eines Mitarbeiters, zu verstehen. Die technischen Prozesse dienen zur primären Leistungserstellung, wie z.B. Montage eines Motors. (vgl. Gadatsch 2005, S. 35)

Schlüter/Schneider aus dem Bereich der Produktionsplanung und –steuerung verfolgen gleichartige Ansätze. Sie definieren Geschäftsprozess als „Folgen sachlogisch zusammen-hängender Aktivitäten, die eine in sich geschlossene Aufgabe realisieren, deren Ziel darin besteht, Materialien und Informationen in eine vom Kunden gewünschte Form zu bringen.“ (Gadatsch 2005, S. 35)

Laut Gadatsch ist ein Geschäftsprozess „eine zielgerichtete, zeitlich-logische Abfolge von Aufgaben, die arbeitsteilig von mehreren Organisationen 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.“ Die Beschreibung eines Geschäftsprozesses kann formal auf unterschiedli-chen Detaillierungsgradsebenen und aus mehreren Sichten erfolgen. Der maximale Detaillie-rungsgrad ist z.B. dann erreicht, wenn die ausgewiesene Arbeit von einem Mitarbeiter in ei-nem Zug ohne Wechsel des Arbeitsplatzes durchgeführt werden kann. (vgl. Gadatsch, S. 36).

Im weiteren Verlauf wird folgende Definition des Geschäftsprozesses verwendet:

Unter einem Geschäftsprozess wird die inhaltlich abgeschlossene, zeitlich-logische Abfolge der Funktionen verstanden, die zur Bearbeitung eines betriebswirtschaftlich relevanten Ob-jektes notwendig sind.

Mit anderen Wörtern ist ein Geschäftsprozess (eng. business process) ein Prozess, der dazu beiträgt, die definierten Unternehmensziele zu erreichen und eine Wertschöpfung zu erbrin-gen, z.B. Reisekostenabrechnung, Bestellungen.

In einiger Literatur wird der Begriff Geschäftsprozess mit Unternehmens-, Wertschöpfungs-oder Kerngeschäftsprozess gleichgesetzt. Innerhalb eines Unternehmens werden häufig alle Prozesse als Geschäftsprozess bezeichnet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Definition von Geschäftsprozess (vgl. Schmelzer 2006, S. 60)

2.1.3 Komponenten von Geschäftsprozessen

Die Komponenten von Geschäftsprozessen sind Abbildung 2.3 zu entnehmen.

Wobei die Anforderungen der Kunden am Anfang des Prozesses und die Bereitstellung der zu erwartenden Leistungen bzw. Ergebnisse am Ende des Prozesses stehen. Dabei ist zu bemerken, dass es bei den Geschäftsprozessen nicht um die Input-Output-Beziehung geht, sondern um die Anforderungs-Ergebnis-Beziehung. Für die Unternehmen sind die Prozess-ergebnisse, die aus einzelnen Produkten oder Dienstleistungen oder aber auch aus einer Kombination der beiden bestehen, wichtig für die Zukunftssicherung des Unternehmens. Unter Kunden sind hier nicht nur der einzelne Kunde zu verstehen, sondern die Interessen-gruppen (Stakeholder), von denen der Erfolg des Unternehmens abhängt. Dies können z.B. Kunden, Lieferanten, Kapitalgeber, Partnerunternehmen, Mitarbeiter usw. sein.

Alle Aktivitäten, die für die Erzeugung der Ergebnisse in einem Geschäftsprozess erforder-lich sind, werden organisatorisch gebündelt. Diese Bündelung kann sich über aufbauorgani-satorische Grenzen wie z.B. Funktionen und Abteilungen genauso auch über Unterneh-mensgrenzen hinweg erstrecken (vgl. Schmelzer 2006, S. 61-62).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Komponenten von Geschäftsprozessen (vgl. Schmelzer 2006, S. 61)

2.1.4 Begriff des Workflows

Es sind zahlreiche manchmal auch teilweise widersprüchliche Definitionen in der Literatur bzw. in der Praxis über den Begriff Workflow zu finden. Aus diesem Grund hat die in 1993 gegründete „Non-Profit“ Organisation Workflow-Management Coalition (WfMC)1, deren Do-kumente weitgehend von der Industrie akzeptiert werden, als Ziel einen Standard zu etablie-ren, an welchen sich fast alle Publikationen und auch Produkte orientieren sollen.

Der Duden definiert Workflow als „Ablauf arbeitsteiliger Vorgänge bzw. Geschäftsprozesse in Unternehmen u. Behörden mit dem Ziel größtmöglicher Effizienz“ oder in der EDV als „Ar-beitsablauf bei Computerprogrammen“

Unter Workflow versteht die WfMC „the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules” (o.V., WfMC 1999, S. 8).

Auf Deutsch ist ein Workflow ein ganz oder teilweise automatisierter Geschäftsprozess, in welchem Dokumente, Informationen oder Aufgaben unter Berücksichtigung von Prozedur-regeln von einem Teilnehmer an einen anderen zur Ausführung übergeben werden.

Galler und Scheer sehen den Workflow als nichts anderes als eine technische Verfeinerung des betriebswirtschaftlichen Geschäftsprozesses. Wobei die Automatisierbarkeit als Kriteri-um für den Verfeinerungsgrad festgelegt wird (vgl. Gadatsch 2005, S. 41).

Österle beschreibt den Workflow ähnlich wie Galler und Scheer. Auch er definiert den Workflow als einen verfeinerten Geschäftsprozess. Dabei wird der Prozessentwurf in Teil-prozesse zerlegt bis der gewünschte Detaillierungsgrad erreicht ist. Die Aufgaben sind so zu zerlegen, dass sie von dem Prozessmitarbeiter zugeordnet und als Arbeitsanweisung umge-setzt werden können. Anstelle einer Führungskraft übernimmt der Computer die Ablaufsteue-rung (vgl. Gadatsch 2005, S. 41).

Becker, Rosemann und Kugler bezeichnen „einen Prozess, dessen Funktionsübergänge in der Kontrollsphäre eines Anwendungssystems liegen als Workflow“ (Gadatsch 2005, S. 41).

Zusammenfassend wird Workflow folgendermaßen definiert:

Ein Workflow wird als formal ganz oder teilweise automatisierter Geschäftsprozess beschrie-ben. Er beinhaltet die zeitlichen, fachlichen und ressourcenbezogenen Spezifikationen, die für eine automatische Steuerung des Arbeitsablaufs auf der operativen Ebene erforderlich sind. Die hierbei anzustoßenden Arbeitsschritte sind zur Ausführung durch Mitarbeiter oder durch Anwendungsprogramme vorgesehen.“(Gadatsch 2005, S. 41)

Die Geschäftsprozesse werden im Workflow verfeinert (s. Abbildung 2.4).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: Verfeinerung der Geschäftsprozesse im Workflow (vgl. Freund, 2004)

2.1.5 Gegenüberstellung von Geschäftsprozess und Workflow

Oftmals werden Workflows und Geschäftsprozesse gleichgesetzt, weil beide Arbeitsabläufe beschreiben, eine klare Abgrenzung ist aufgrund des gemeinsamen Untersuchungs-gegenstandes nicht immer möglich. Trotz des engen Zusammenhangs zwischen Workflows und Geschäftsprozessen verfolgen die beiden unterschiedliche Ziele (s. Abbildung 2.5).

Der wesentliche Unterschied ist, dass der Geschäftsprozess beschreibt, „WAS“ zu tun ist, um die vorgegebene Geschäftsstrategie umsetzen zu können. Der Workflow beschreibt „WIE“ dies umgesetzt werden soll. Der Geschäftsprozess ist in der fachlichen Ebene zu fin-den, der Workflow in der operativen Ebene.

In der Praxis gibt es keine feste Regel bzw. „objektive“ Kriterien für einen angemessen De-taillierungsgrad.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: Geschäftsprozess vs. Workflow (vgl. Gadatsch 2005, S. 47)

[...]


1 WfMC wurde 1993 gegründet und ist ein Verbund von Forschungsinstituten, Hochschulen, Anwen-dern und Softwareherstellern, die sich mit Standards im Bereich des Workflow-Managements befas-sen.

Details

Seiten
119
Jahr
2009
ISBN (eBook)
9783640404049
Dateigröße
3.8 MB
Sprache
Deutsch
Katalognummer
v133743
Institution / Hochschule
Beuth Hochschule für Technik Berlin
Note
1,3
Schlagworte
Blueprint Integration Webbasierte PM-Tools Projekmanagement SOA ESB JBI WSDL Web Services SOAP BPEL EPKs Geschäftsprozess Workflow Geschäftsprozessmodellierung UUDI SOA-Architekturmodell Integrationsansätze

Autor

Teilen

Zurück

Titel: Webbasierte Projektmanagement-Tools. Blueprint zur Integration unter Verwendung service-orientierter Architekturen