Geschaftsprozesse realisieren: Ein praxisorientierter Leitfaden von der Strategie bis zur Implementierung

Herbert Fischer Albert Fleischmann Stefan Obermeier Gechäftsprozesse realisieren

Aus dem Bereich IT erfolgreich nutzen

Netzarchitektur – Entscheidungshilfe für Ihre Investition Von Thomas Spitz Kommunikationssysteme mit Strategie Von Peter Fidrich Optimiertes IT-Management mit ITIL Von Frank Victor und Holger Günther Chefsache Open Source Von Theo Saleck Unternehmens-IT für Banken Von Andreas Krupinski Chefsache IT-Kosten Von Theo Saleck Handbuch Unternehmenssicherheit Von Klaus-Rainer Müller Von der Unternehmensarchitektur zur IT-Governance Von Klaus D. Niemann IT-Controlling realisieren Von Andreas Gadatsch Beyond Compliance Von Ralf-T. Grünendahl und Peter H.L. Will Outsourcing realisieren Von Marcus Hodel, Alexander Berger und Peter Risi Die Praxis des Knowledge Managements Von Andreas Heck Best-Practice mit SAP® Von Andreas Gadatsch und Reinhard Mayr Process Modeling with ARIS Von Heinrich Seidlmeier ARIS in IT-Projekten Von Jürgen Grief Profikurs Microsoft Navision 4.0 Von Paul M.Diffenderfer und Samir El-Assal jr. Microsoft Navision 4.0 Von Paul M.Diffenderfer und Samir El-Assal jr.

www.vieweg.de

Controlling von Softwareprojekten Von Katrin Gruner, Christian Jost und Frank Spiegel Bilanzanalyse mit MS ACCESS Von Jörg Hartung Masterkurs Kostenstellenrechnung mit SAP® Von Franz Klenger und Ellen Falk-Kalms Unternehmensführung mit SAP BI® Von Heinz-Dieter Knöll, Christoph SchulzSacharow und Michael Zimpel Controlling für Industrieunternehmen Von Jürgen Bauer und Egbert Hayessen CAD mit CATIA® V5 Von Michael Trzesniowski CRM-Systeme mit EAI Von Matthias Meyer Marketing-Kommunikation im Internet Von Dirk Frosch-Wilke und Christian Raith B2B-Erfolg durch eMarkets und eProcurement Von Michael Nenninger und Oliver Lawrenz SAP APO® in der Praxis Von Matthias Bothe und Volker Nissen E-Mail-Marketing Von Lutz Labs Website Marketing Von Sven Roddewig Marketingkampagnen effizient managen Von Thomas Dold, Bernd Hoffmann und Jörg Neumann Grundlagen des Software-Marketing Von Björn Wolle IT-Projekte lenken – mit System Von Bogdan Lent Controlling von Projekten Von Rudolf Fiedler Geschäftsprozesse realisieren Von Herbert Fischer, Albert Fleischmann und Stefan Obermeier

Herbert Fischer Albert Fleischmann Stefan Obermeier

Geschäftsprozesse realisieren Ein praxisorientierter Leitfaden von der Strategie bis zur Implementierung Mit 78 Abbildungen

Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

http://www.geschaeftsprozesse-realisieren.de

1. Auflage August 2006 Alle Rechte vorbehalten © Friedr. Vieweg & Sohn Verlag | GWV Fachverlage GmbH, Wiesbaden 2006 Lektorat: Günter Schulz / Andrea Broßler Der Vieweg Verlag ist ein Unternehmen von Springer Science+Business Media. www.vieweg.de Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Konzeption und Layout des Umschlags: Ulrike Weigel, www.CorporateDesignGroup.de Umschlagbild: Nina Faber de.sign, Wiesbaden Druck- und buchbinderische Verarbeitung: MercedesDruck, Berlin Printed in Germany ISBN-10 3-8348-0053-8 ISBN-13 978-3-8348-0053-4

Vorwort Der wirtschaftliche Erfolg eines Unternehmens hängt zunehmend davon ab, wie flexibel es im Markt agiert. Das Management muss rasch auf neue Erfordernisse reagieren – zum Beispiel wenn es darum geht, neue Märkte zu erschließen, Kundenwünsche zu realisieren oder neue Lieferanten einzubinden. Je schneller und besser ein Unternehmen sich diesen Herausforderungen stellen kann, desto größer wird sein Vorsprung vor den Mitbewerbern sein. Unternehmen erreichen diese Agilität, indem sie Geschäftsprozesse definieren, implementieren und optimieren. Geschäftsprozesse regeln das Miteinander der beteiligten Personen, geben standardisierte Abläufe vor, bestimmen den Einsatz von Ressourcen und führen zu einem definierten Ergebnis. Systematisierte Geschäftsprozesse versprechen konkreten wirtschaftlichen Nutzen. Kosten werden reduziert und vorhandene Betriebsmittel werden besser genutzt. Gleichzeitig lässt sich die erwünschte Qualität eines Produktes oder einer Dienstleistung besser erreichen. Und nicht zuletzt schaffen gut gestaltete Geschäftsprozesse mehr Transparenz und vereinfachen die Führung eines Unternehmens. So ist es verständlich, dass der Markt für Geschäftsprozesse stark wächst. Viele Beraterhäuser haben sich darauf spezialisiert, Prozesse zu reorganisieren und zu verbessern; zahlreiche Werkzeuge unterstützen Unternehmen bei der Konzeption und Umsetzung von Prozessen; und in den Hochschulen sind Vorlesungen zu diesem Thema nicht mehr wegzudenken. Es gibt eine wachsende Zahl an Lehrbüchern zum Thema „Prozesse“, und in Fachzeitschriften kann man vielfältige Informationen finden. Unserem Verständnis nach bleibt die Literatur jedoch vorwiegend in der Theorie. Mit dem Buch „Geschäftsprozesse realisieren“ wollen wir gerne Abhilfe schaffen. Wir wollen aus unserer Erfahrung der betrieblichen Realität Hilfestellungen für die konkrete Umsetzung geben. So wird ein leicht nachvollziehbares, praxisorientiertes Modell an die Hand gegeben, das konkrete Schritte zur Realisierung von Geschäftsprozessen aufzeigt. Wir werden den Horizont etwas öffnen und neben den gängigen flussorientierten Ansätzen mit weiV

Vorwort teren Methoden arbeiten. Anhand einer durchgängigen Fallstudie kann jeder Schritt nachvollzogen werden. Wir werden uns allen maßgeblichen Aspekten widmen und vor allem wichtige Fragen zur Realisierung beantworten: x

Was muss man wissen, um von Geschäftsprozessen zu sprechen?

x

Wie sieht die Planung von Geschäftsprozessen aus?

x

Wie werden Geschäftsprozesse realisiert?

x

Was kostet die Realisierung von Geschäftsprozessen?

x

Wer muss an der Realisierung von Geschäftsprozessen beteiligt sein?

x

Passen die realisierten Geschäftsprozesse zu den Anforderungen?

und mehr. Wir danken an dieser Stelle den Menschen, die uns beim Schreiben des Buches unterstützt haben. Da sind vor allem unsere Familien, die uns, an zahlreichen Abenden und Wochenenden in den Arbeitszimmern, vermisst haben. Besonderer Dank auch den Korrekturlesern Frau Eberle, Franz Böhm, Herrn Schneeberger, Herrn Dobmeier und Herrn Voigt. Silvia Haller und Georg Obermayr sei gedankt für die Erstellung der gelungenen Graphiken. Wir wünschen Ihnen mit diesem Buch einen guten „Lese-, Lernund Unterhaltungsprozess“!

Deggendorf, Rohrbach, München im Mai 2006

Herbert Fischer, Albert Fleischmann, Stefan Obermeier

VI

Inhaltsverzeichnis

1

Geschäftsprozesse – Warum? .......................................................................1

1.1

Aufbauorganisation.......................................................................................1

1.2

Ablauforganisation: organisationsverbindende Prozesse ...........................3

1.3

Geschäftsprozess - Definition ......................................................................4

1.4

Statische und dynamische Prozesse ............................................................8

1.5

Detaillierungsgrade und Unternehmensgrenzen ........................................9

1.6

Prozesse und IT .......................................................................................... 10

1.7

Herausforderung an das Unternehmen..................................................... 11

1.8

Zusammenfassung ...................................................................................... 12

2

Geschäftsprozesse realisieren auf fünf Ebenen ........................................ 15

2.1

Klassisches Drei-Ebenen-Modell................................................................ 15

2.2

Das Fünf-Schichten-Modell zur Realisierung von Geschäftsprozessen... 17

2.3

Ebene 1: Zielsetzung und Strategie (Kapitel 3) ........................................ 18

2.4

Ebene 2: Architektur und Planung (Kapitel 4) ......................................... 18

2.5

Ebene 3: Modell und Beschreibung (Kapitel 5) ....................................... 19

2.6

Ebene 4: Test und Plausibilisierung (Kapitel 6) ....................................... 19

2.7

Ebene 5: Implementierung und Anwendung (Kapitel 7) ........................ 19

2.8

Zusammenfassung ...................................................................................... 19

2.9

Aufgaben und Fallstudie ............................................................................ 20

3 3.1

Unternehmersicht: Prozesse strategisch gestalten .................................... 21 Prozesse in Unternehmensstrategien......................................................... 21

3.1.1

Business Process Re-Engineering....................................................... 21

VII

Inhaltsverzeichnis 3.1.2

ISO 9000:2000 und ISO 9001 ............................................................. 22

3.1.3

Total Quality Management ................................................................. 24

3.1.4

EFQM Unternehmensbewertung........................................................ 26

3.1.5

Balanced Scorecard............................................................................. 28

3.1.6

Six Sigma ............................................................................................. 31

3.1.7

Gegenüberstellung und Bewertung................................................... 32

3.2

Strategisches Vorgehen im Geschäftsprozessmanagement...................... 33

3.2.1

Differenzierung der Prozesstypen...................................................... 33

3.2.2

Typenabhängiges Geschäftsprozessmanagement............................. 34

3.3

Prozesscontrolling....................................................................................... 40

3.4

Zusammenfassung ...................................................................................... 42

3.5

Aufgaben zur Prozess-Modellierung (Teil 1) ............................................ 43

4

Architektensicht: Prozesse übersichtlich strukturieren............................. 45

4.1

Architektur von Geschäftsprozessen – warum ?....................................... 45

4.2

Architekturkriterien..................................................................................... 46

4.3

Flussorientierte Architekturkriterien .......................................................... 50

4.4

Objektorientierte Architekturkriterien ....................................................... 54

4.5

Asynchrone Architekturkriterien................................................................ 56

4.6

Zusammenfassung ...................................................................................... 60

4.7

Aufgaben zur Prozessarchitektur (Teil 2).................................................. 61

5

Fokus Mensch: Prozesse gekonnt beschreiben ........................................ 63

5.1

Kriterien zur Prozessbeschreibung ............................................................ 63

5.2

Textuell-informelle Prozessbeschreibungen ............................................. 64

5.3

Strukturierte Prozessbeschreibungen ........................................................ 66

5.4

Flussorientierte Prozessbeschreibungen.................................................... 69

5.5

Objektorientierte Prozessbeschreibungen................................................. 73

5.6

Subjektorientierte Prozessbeschreibungen................................................ 78

5.7

Zusammenfassung ...................................................................................... 85

VIII

Inhaltsverzeichnis 5.8

6

Aufgaben zur Prozess-Modellierung (Teil 3) ............................................ 87

Qualitätskontrolle: Prozesse auf Eignung prüfen ..................................... 89

6.1

Visuelle Begutachtung................................................................................ 89

6.2

Walk-Throughs ........................................................................................... 91

6.3

Simulation.................................................................................................... 92

6.4

Geschäftsprozesse sofort erleben .............................................................. 93

6.4.1

Klärung des Begriffs ........................................................................... 94

6.4.2

Ziel: Geschäftsprozesse am System erleben...................................... 95

6.4.3

Beispiel für Prozesse erleben............................................................. 95

6.5

Zusammenfassung .................................................................................... 101

6.6

Aufgaben zur Prozess-Modellierung (Ebene 4) ...................................... 103

7 7.1

IT-Unterstützung: Prozesse erfolgreich implementieren ........................ 105 Manuelle und IT-gestützte Prozessausführung ....................................... 105

7.1.1

Office-Unterstützung......................................................................... 105

7.1.2

Isolierte Datenbankanwendungen................................................... 106

7.1.3

Worklist-Anwendung ........................................................................ 107

7.2

Standardsoftware in den Workflow integrieren...................................... 107

7.2.1

Referenzmodell für Workflow-Management-Systeme .................... 108

7.2.2

Umsetzung eines Prozesses in SAP/R3............................................ 110

7.2.3

Zusammenfassung ............................................................................ 115

7.3

Konzepte einer offenen Architektur zur Prozessimplementierung ....... 116

7.3.1

Serviceorientierte Architektur........................................................... 117

7.3.2

Implementierungskonzepte zur Prozessbeschreibungsmethodik.. 124

7.4

Technische Lösungen für Workflows...................................................... 129

7.4.1

J2EE.................................................................................................... 130

7.4.2

.NET ................................................................................................... 132

7.4.3

Web-Service....................................................................................... 134

7.4.4

MQ-Series .......................................................................................... 137 IX

Inhaltsverzeichnis 7.4.5

SAP Netweaver.................................................................................. 138

7.5

Zusammenfassung .................................................................................... 140

7.6

Aufgabe zur Prozess-Implementierung (Teil 5)...................................... 143

8

Fallstudie ................................................................................................... 145

8.1

Strategische Gestaltung ............................................................................ 145

8.2

Anforderung an die Prozess-Struktur ...................................................... 147

8.3

Optimierung der Prozessbeschreibung ................................................... 149

8.4

Prozessimplementierung .......................................................................... 152

8.5

Einbinden existierender Programme ....................................................... 158

8.6

Messen und Bewerten.............................................................................. 159

8.7

Zusammenfassung .................................................................................... 160

8.8

Aufgabe zur Fallstudie.............................................................................. 160

9

Checklisten................................................................................................ 161

9.1

Einleitung .................................................................................................. 161

9.2

Prozessüberblick....................................................................................... 161

9.3

Prozessanalyse .......................................................................................... 162

9.4

Vorbereitung der Prozessmodellierung................................................... 162

9.5

Prozessaufnahme ...................................................................................... 163

9.6

Prozessoptimierung .................................................................................. 164

9.7

Prozesse einführen ................................................................................... 164

Literaturverzeichnis .................................................................................................. 167 Schlagwortverzeichnis.............................................................................................. 171 Über die Autoren ..................................................................................................... 175

X

1

Geschäftsprozesse – Warum?

Geschäftsprozesse reduzieren Kosten

Seit den späten 90er Jahren rückt die Betrachtung von Geschäftsprozessen zunehmend in das Blickfeld von Unternehmen. Auch Forschung und Lehre widmen dem Thema immer mehr Aufmerksamkeit. So empfehlen Wirtschaftsinformatiker einen Wechsel von einer funktionszentrierten Sichtweise zu einem vorgangsorientierten Denken. Während vorher Programme im Vordergrund standen, betrachtet man jetzt reale Abläufe. Beratungshäuser sind darauf spezialisiert, Prozesse zu analysieren, abzubilden und zu optimieren. Schließlich erkennen viele Manager, dass eine an Geschäftsprozessen orientierte Organisation Kosten reduziert und dazu beiträgt, strategische Ziele rascher zu erreichen. Um ein besseres Verständnis von Geschäftsprozessen zu erlangen, werden wir ihre Bedeutung diskutieren und klären, warum sie seit einigen Jahren eine so zentrale Rolle in Unternehmen spielen.

1.1

Aufbauorganisation

Organisationen erfüllen Aufgaben

Ein kommerziell ausgerichtetes Unternehmen will durch Entwicklung, Produktion und Vertrieb von Produkten – sowie der dazu gehörigen Dienstleistungen – Gewinne erzielen. Dazu muss es zahlreiche, sehr unterschiedlich strukturierte und oftmals miteinander vernetzte Aufgaben erfüllen. Zur Erfüllung dieser Aufgaben gilt es, eine Organisation zu schaffen, die es ermöglicht, „(...) unterschiedliche Funktionsträger mit verschiedenen Kompetenzen und Wissenshintergründen so miteinander zu koordinieren, dass auf diese Weise an sich höchst unwahrscheinliche Leistungen zustande kommen“ [Na02], S.95. Die Organisation eines Unternehmens lässt sich in unterschiedlicher Weise darstellen – je nachdem, ob man den Aufbau oder die Abläufe zeigen will.

Aufbauorganisation

Bei der Aufbauorganisation steht die Strukturierung des Unternehmens mit seinen Elementen – in der Regel sind dies Abteilungen, Teams und Mitarbeiter – im Mittelpunkt. Sie zeigt, welche Organisationseinheiten es gibt und nach welchen Gesichtspunkten - zum Beispiel Entwicklung, Vertrieb und Administration - die Aufgaben geteilt werden. Weiterhin ist aus der Aufbauorga1

1

Geschäftsprozesse – Warum? nisation ersichtlich, welche Kompetenzen – etwa Führungserfahrung oder Programmierkenntnisse – benötigt werden und welche Verantwortlichkeiten vergeben werden.

Work-Breakdown-Structure

Die Aufbauorganisation definiert Stellen und die ihnen zugeordneten Personen. Damit entspricht sie der Work Breakdown Structure (WBS), wie sie im Projektmanagement zur Strukturierung von Aufgaben verwendet wird. Die Gesamtaufgabe „Unternehmen“ wird, auf eine für sinnvoll betrachtete Art, in verschiedene Aufgabenblöcke gegliedert. Eine sinnvolle Aufgabengliederung kann sich zum Beispiel nach Märkten, Geografien und Funktionen richten.

Organisation besteht aus lebenden Elementen

Eine Aufbauorganisation orientiert sich an den zu erfüllenden Aufgaben, aber auch an den Besonderheiten ihrer „Mitglieder“. Ihre individuellen Fähigkeiten und Rollen innerhalb der Organisation prägen die Struktur implizit mit. Für einen außen Stehenden mag daher ein bestimmtes Organigramm weniger plausibel erscheinen, intern können auf diese Art und Weise die zu erfüllenden Aufgaben jedoch am besten gelöst werden. Die Ziele der Führungskräfte – etwa Umsatz, Gewinn, Kosten und Produktivität – orientieren sich an den in der Aufbauorganisation beschriebenen Organisationseinheiten. Der Leiter einer Organisationseinheit hat mit ihr bestimmte Vorgaben zu erfüllen. Die Aufbauorganisation ist die Identität stiftende Struktur einer Organisation, indem sie definiert, wer beispielsweise dem Vertrieb, der Entwicklung, dem Marketing oder der Niederlassung Süd angehört.

2

1.2

Ablauforganisation: organisationsverbindende Prozesse

1.2

Ablauforganisation: organisationsverbindende Prozesse

Ablauf- und Aufbauorganisation

Die statische Aufbauorganisation gibt in der Praxis den Rahmen vor, innerhalb dessen sich die dynamische Ablauforganisation bewegt. Diese stellt dar, wie sich die Abläufe der Aufgaben gestalten und wie die Arbeit geteilt wird. Sie stellt die Beziehungen innerhalb eines Unternehmens in den Mittelpunkt und zeigt, wie die einzelnen Elemente zusammen arbeiten, um die Anforderungen an das „Gesamtsystem Unternehmen“ zu erfüllen. Die Aufgaben in einer Organisation sind nicht unabhängig voneinander zu betrachten. Vielmehr haben sie einen stark vernetzten Charakter. So kann es zum Beispiel für die Verrichtung einer Tätigkeit im Vertrieb erforderlich sein, Informationen aus der Entwicklung einzuholen und eine Teilaufgabe an einen bestimmten Mitarbeiter im Kundenservice weiter zu geben. Damit wird ein Geschäftsprozess angestoßen, der weitere Abteilungen berührt.

Prozesse sind die konkrete Umsetzung der Ablauforganisation in die Praxis. Ein Prozess „durchläuft“ die Aufbauorganisation teilweise oder im Extremfall sogar vollständig. Aufgaben und Prozesse

Den Zusammenhang zwischen Aufgaben- und Prozess-Sicht zeigt Abbildung 3. Es sind betriebliche Aufgaben in einer Organisation zu erledigen. Das ist die arbeitsplatzorientierte Sicht. Die prozessorientierte Sicht zeigt den richtigen Ablauf der Aufgaben. Der Prozess muss gewährleisten, dass die richtige Aufgabe an die 3

1

Geschäftsprozesse – Warum? richtige Stelle geleitet und nach der Bearbeitung an die nächste richtige Stelle weitergegeben wird.

Aufgaben- und Prozess-Sicht bedingen und ergänzen sich. Zum Gelingen des Prozesses müssen die Aufgaben erledigt sein. Hinweis: Viele Methoden zur Beschreibung von Prozessen nehmen eine Linearisierung der Aufgaben innerhalb eines Prozesses an, insbesondere in Überblicksdarstellungen. Dies entspricht oft nicht der betrieblichen Realität, denn Prozesse sind selten linear. Sie verzweigen sich, werden wieder zusammengeführt oder haben Schleifen. Organisationseinheiten bearbeiten einzelne Aufgaben eines Prozesses häufig parallel und unabhängig voneinander. Wir werden diesen Aspekt im Detail besprechen.

1.3

Geschäftsprozess - Definition In der Literatur finden wir einige Beispiele dafür, was man unter einem Geschäftsprozess verstehen kann, nämlich

Ein Prozess ist...

• „eine Menge von Aktivitäten mit Input und Ergebnis“ [HaCh94] • „eine modellhafte Beschreibung der Funktionen im Unternehmen“ [ScJo96]

4

1.3

Geschäftsprozess - Definition

• „eine Abfolge von Aufgaben über mehrere organisatorische Einheiten mit informationstechnischer Unterstützung“ [Ös95]

Kennzeichen eines Prozesses

In diesem Buch werden wir uns an folgender Definition orientieren. Ein Prozess beschreibt einen betrieblichen Ablauf, das heißt den Fluss und das Bewegen von Material und Informationen unter Anwendung von Operationen und Entscheidungen. Er beschreibt Reihenfolgen von funktionsübergreifenden Aktivitäten mit Anfang und Ende sowie klar definierten Eingaben und Ausgaben. Aus Sicht des Unternehmens soll er einen Mehrwert schaffen. Verschiedene Branchen können ganz unterschiedliche Auffassungen von Prozessen haben. Prozessanwendungen sind daher sehr vielfältig und unterschiedlich. Deshalb sind die Beispiele im Buch „illustrativ“ zu verstehen. Bei der Übertragung auf Ihre betriebliche Praxis müssen Sie diese unter Umständen entsprechend abwandeln. Der Begriff „Prozess“ wird sehr vielseitig und vieldeutig genutzt. Die Bedienungsfolge einer komplexen Anwendung, ausgeführt von einer Person oder einer Software, wird fälschlicherweise ebenso als Prozess bezeichnet wie eine Arbeitsanweisung, die die Handlungsreihenfolge einer Aufgabe für eine bestimmte Person beschreibt. Die Tätigkeit einer Person wird häufig ebenfalls Prozess genannt. Zu einem Geschäftsprozess gehören jedoch mindestens drei beteiligte Rollen: • eine Rolle, die den Prozess anstößt, • eine Rolle, die den Prozess ausführt • und eine Rolle, welche die Prozessleistung (Ausgabe) benötigt. Nimmt eine Person mehrere Rollen ein, kann man ebenfalls von einem Geschäftsprozess sprechen. Vereinfacht kann ein Prozess mit dem folgenden Modell beschrieben werden.

5

1

Geschäftsprozesse – Warum?

Häufig ist der Anforderer einer Prozessleistung identisch mit dem Empfänger der Leistung. Das ist beispielsweise dann Fall, wenn ein Kunde eine Preisanfrage startet (Initiator eines Geschäftsereignisses) und als Ergebnis eine Preisauskunft erhält (Empfänger des Resultats).

Prozessauslöser

6

Prozesse definieren die erforderlichen organisations- und/oder unternehmensübergreifenden Aktivitäten, Mittel und Beteiligten zur Bearbeitung eines Geschäftszwecks, ausgelöst durch einen externen oder internen Kunden, um ein gewünschtes Ergebnis zu erzielen. Die am Prozess Beteiligten sind in der Regel Teil einer Organisation. Der Aufbau der Organisation orientiert sich an funktionalen (Entwicklung, Produktion, Vertrieb etc.), geografischen oder Kundengruppen-orientierten Erfordernissen.

1.3 Prozessziel: Kommunikation in der Organisation

Geschäftsprozess - Definition

Der Verlauf eines Prozesses besteht darin, dass verschiedene Organisationseinheiten miteinander kommunizieren, ihre Tätigkeiten synchronisieren und Zwischenergebnisse austauschen. Das erreichte Ergebnis wird an den internen oder externen Empfänger übergeben. In Abbildung 6 wird ein komplexes Beispiel zur Bedarfsrechnung skizziert.

In den Prozessbeschreibungen müssen mehrere Bearbeitungszweige für verschiedene Varianten und Situationen vorgesehen werden. Es kann unterschiedliche Auftragsvarianten geben, die ebenso unterschiedlich bearbeitet werden müssen, so dass während eines Prozessablaufs verschiedene Zweige der Prozessbeschreibung durchlaufen werden. Außerdem können Bearbeitungsschritte eines Prozesses parallel zueinander ausgeführt werden. Während der Erstellung der Auftragsbestätigung wird bereits der Versand vorbereitet. Die Parallelisierung von Prozessen führt oft zu kürzeren Durchlaufzeiten.

7

1

Geschäftsprozesse – Warum?

1.4

Statische und dynamische Prozesse

Statischer und dynamischer Prozess

Wir unterscheiden zwischen der statischen Prozessdefinition (Prozessbeschreibung) und der dynamischen Ausprägung eines Prozesses (Prozessinstanz). Der konkrete Ablauf eines Prozesses wird durch ein Ereignis ausgelöst. Dies hat die Bearbeitung eines Vorgangs gemäß Prozessdefinition zur Folge. Es gibt beispielsweise in einem Unternehmen eine Prozessbeschreibung für die Bearbeitung von Aufträgen. Eine Prozessinstanz ist die konkrete Bearbeitung eines eingetroffenen Auftrags. Abbildung 7 stellt den Prozess der Auftragsbearbeitung mit zwei Vorgängen, die Aufträge von Herrn Huber und Herrn Meier dar.

Prozesse, Aktivitäten und Arbeitsabläufe

Weiter gilt es, eine wichtige Unterscheidung zwischen Prozessen und Aktivitäten zu treffen. An einem Prozess sind mindestens zwei Organisationen und/oder Personen beteiligt. Eine stößt den Prozessablauf an, und eine weitere führt die entsprechenden Aktivitäten aus. Häufig wird eine komplexe Aktivität, die von einer Person u.U. zusammen mit einer Anwendungssoftware ausgeführt wird, als Prozess bezeichnet. Das Ausfüllen einer Folge von Bildschirmmasken durch eine Person zur Erfassung eines Auftrags ist nach der hier verwendeten Definition kein Prozess, sondern eine Aktivität, ein Arbeitsvorgang oder ein Arbeitsablauf einer Person. Das Erfassen eines Auftrags als Gesamtes kann eine durchaus komplexe Aktivität innerhalb des Prozesses „Auftragsabwicklung“ sein.

8

1.5

Detaillierungsgrade und Unternehmensgrenzen

1.5

Detaillierungsgrade und Unternehmensgrenzen

Abstraktionsebenen

Betriebliche Prozesse können auf verschiedenen Abstraktionsebenen betrachtet werden. Jedes Unternehmen hat ca. drei bis zehn übergeordnete Prozesse (beispielsweise Einkauf, Produktion, Vertrieb etc.), die grob darstellbar sind ([Ham94]). Diese Prozesse können beliebig verfeinert werden bis auf eine Ebene, auf der einzelne Aktivitäten beschrieben sind. Das Beispiel in Abbildung 8 zeigt den "internen" Prozess einer Auftragsbearbeitung. Der Teilprozess „Auftragsbearbeitung“ kann weiter verfeinert werden.

Tipp

Beispiel

Behalten Sie den Überblick! Für das Management ist es in der Regel nicht erforderlich, alle Prozesse genau zu kennen. Auf operativer Ebene sind jedoch die Details eines Prozesses entscheidend. Es genügt nicht, von einem Prozess eine grobe Vorstellung zu haben. Für alle Prozessbeteiligten ist es wichtig, Zusammenhänge zu verstehen, um gegenseitigen Nutzen zu generieren. Benennen Sie das Ziel, das Sie in Ihrer Rolle verfolgen!

Ein schnell wachsendes und sich veränderndes Unternehmen beauftragte ein namhaftes Beratungsunternehmen, Prozesse zu analysieren und darzustellen. Nach einigen Monaten waren umfangreiche Prozessablaufbilder angefertigt, mit denen man alle Wände des Unternehmens hätte tapezieren können. Mittlerweile hatten sich die Organisation und die Prozesse bereits so stark 9

1

Geschäftsprozesse – Warum? verändert, dass das Ergebnis aufgrund des hohen Detaillierungsgrades nicht mehr der gelebten Realität entsprach. Die Arbeit konnte nicht produktiv verwertet werden. Verschiedene Abteilungen haben unterschiedliche Bilder von Prozessen (Sichten). Die Abwicklung eines Schadensfalls für eine Versicherung sieht für den geschädigten Versicherungsnehmer anders aus als die interne Abwicklung für den Sachbearbeiter in der Versicherung.

Prozesse überschreiten Unternehmensgrenzen

Die Zusammenarbeit zwischen verschiedenen Unternehmen macht die Betrachtung unternehmensübergreifender Prozesse notwendig. Die beteiligten Personen, Rollen und Organisationen liegen außerhalb des eigenen Unternehmensbereiches. Geschäftsprozesse machen auch vor Unternehmensgrenzen nicht Halt!

Erhöhte Bedeutung gewinnt dieser Aspekt durch die zunehmenOutsourcing: Prozess auslagern den Outsourcing-Aktivitäten. An der Erbringung einer Leistung für den Endkunden sind mehrere Unternehmen beteiligt. Das bedeutet, Outsourcing-Projekte dürfen nicht nur vom Standpunkt der Aufbauorganisation her betrachtet werden. Auch aus Sicht der Ablauforganisation ergeben sich signifikante Einschnitte. Es muss klar definiert werden, wie die betroffenen Unternehmen zusammenarbeiten, um die entsprechenden Leistungen zu erbringen. Outsourcing als das Auslagern einer Organisationseinheit betrachtet die Restrukturierung der Leistungserbringung eines Unternehmens nur statisch. Ein anderer Ansatz ist Supply Chain Management (SCM), bei dem die Zuliefer- und Versorgungsprozesse in die gesamte Prozessbetrachtung einbezogen und mit abgestimmten IT-Lösungen unterstützt werden.

1.6 Büroakte als erstes Prozesswerkzeug

10

Prozesse und IT Vor zwanzig Jahren war das wichtigste Bürokommunikationswerkzeug die Büroakte. Die Ergebnisse einer Tätigkeit konnten an andere Sachbearbeiter mit dem Hausboten weitergeleitet werden. War der Vorgang abgeschlossen, wanderten die Unterlagen in das Archiv. Viele Büroaufgaben werden heute von IT unterstützt und sind ohne Computersysteme nicht mehr denkbar.

1.7 Prozess und Workflow

Herausforderung an das Unternehmen

Für die IT besteht die Herausforderung darin, nicht nur einzelne Aufgaben, sondern komplette Abläufe zu unterstützen. Geschäftsprozesse, die mit einem IT-System automatisiert werden, werden als workflow bezeichnet. Sie erleichtern den Austausch von Teilergebnissen zwischen den Prozessbeteiligten und koordinieren den Ablauf der Arbeiten. Durch Vernetzung der IT – vor allem über das Internet – ergeben sich neue unternehmensübergreifende Anwendungsmöglichkeiten (beispielsweise E-Commerce, E-Business, E-Procurement, EGovernment etc.). Dadurch lassen sich Unternehmensgrenzen – scheinbar – auflösen. Ob sich eine Abteilung im gleichen Gebäude oder auf einem anderen Kontinent befindet oder sogar einer anderen Organisationsform angehört, ist unerheblich.

Wechselwirkung Aufbau-, Ablauforganisation und IT

Die Aspekte Aufbauorganisation, Ablauforganisation und ITSysteme einer Organisation stehen in Wechselwirkung. Prozesse lassen sich in einer prozessorientierten Aufbauorganisation leichter implementieren, da weniger Organisationseinheiten beteiligt sind und weniger Schnittstellen betrachtet werden müssen. Manche Prozesse können nur mit IT-Unterstützung sinnvoll eingeführt werden, oder IT-Systeme prägen selbst die Ablauforganisation. Diese Wechselwirkungen gewinnen besonders bei der Einführung von Standard-Anwendungssystemen an Bedeutung. Zum einen muss das IT-System an die gewünschten Abläufe angepasst werden, zum anderen müssen die Wunschprozesse dem ITSystem angeglichen werden. Welcher „Best-Practice-Weg“ beschritten wird, ist einerseits eine Kosten-Nutzen-Entscheidung, andererseits eine an den Softwaremöglichkeiten ausgerichtete Abwägung. Eine zu starke Anpassung von Standardsoftware an firmenspezifische Prozesse zieht in der Regel hohe Folgekosten nach sich. Ein neues Release einer Standardanwendung erfordert häufig umfangreiche Anpassungen am IT-System und in der Ablauforganisation.

1.7

Herausforderung an das Unternehmen Prozesse dienen dem Zweck, um strategische Zielsetzungen in operative Handlungen umzusetzen, um die gesetzten Ziele zu erreichen.

11

1

Geschäftsprozesse – Warum?

Effizienz und Effektivität

Die Effizienz und Effektivität der eigenen Geschäftsprozesse ist heute ein unbedingtes Muss. Es wird erwartet, dass Geschäftsvorgänge wie Bestellungen, Serviceanfragen etc. vom Unternehmen entsprechend den Kundenerwartungen schnell und zuverlässig bearbeitet werden.

Minimale Ressourcen

Die Ziele der Prozesse müssen mit möglichst wenig Ressourcenund Kostenaufwand erreicht werden, d. h. Prozesse müssen effizient sein. Eine weitere Herausforderung ist es, die eigenen Geschäftsprozesse schnell und flexibel an veränderte Marktsituationen anpassen zu können. Die Produktionszyklen werden immer kürzer, auf der anderen Seite aber immer komplexer. Lieferanten und auch Hersteller gehen bei der Beherrschung ihrer Prozesse soweit, den Kunden den eigenen Prozess-Status zu kommunizieren. Bei einem Automobilproduzenten kann der Kunde seine Sonderwünsche noch ändern, wenn der Wagen sich bereits in der Produktion befindet. Wird beispielsweise kurzfristig eine andere Lackfarbe gewünscht, kann diesem Wunsch Rechnung getragen werden. Prozesse zu beherrschen bedeutet Kundenbindung. Die enge Verzahnung von Prozessen mit der IT muss sehr flexibel gestaltet sein, um auf Änderungen reagieren zu können. Das ist ein wichtiges Spannungsfeld. Der Bedarf an flexibler Anpassbarkeit der Prozesse ist derzeit sehr viel höher als durch IT realisierbar. Zwar werden Systeme workflow-basiert gebaut, sie können jedoch auf Prozessänderungen nur bedingt flexibel reagieren.

1.8

Zusammenfassung Wir unterscheiden zwei Darstellungen der Organisation eines Unternehmens. Die statische Aufbauorganisation strukturiert ein Unternehmen nach Organisationselementen, während die dynamische Ablauforganisation beschreibt, wie diese Elemente zusammen arbeiten. Der Begriff der Geschäftsprozesse verbindet beide Organisationsformen. Demnach verstehen wir unter einem Geschäftsprozess die Reihenfolge, in der die Aufgaben innerhalb einer Aufbauorganisation bearbeitet werden. Ein Prozess benötigt immer eine Eingabe und eine Ausgabe sowie einen Initiator, einen Bearbeiter und einen Empfänger.

12

1.8

Zusammenfassung

Prozesse lassen sich in verschiedenen Komplexitätstiefen darstellen, die von den groben Unternehmensabläufen bis hin zu detaillierter Beschreibungen der Handlungen reichen. Zusätzlich unterscheiden wir zwischen der abstrakten Beschreibung eines Prozesses und seiner Instanz, dem konkreten Ablauf. IT-Systeme unterstützen die Automatisierung von Geschäftsprozessen. Richtig angewandt tragen sie dazu bei, Komplexität zu reduzieren, Kosten zu sparen und die Agilität eines Unternehmens zu erhöhen. Aus diesem Grund ist die Beherrschung der eigenen Prozesse eine vordringliche Unternehmens- und Managementaufgabe.

13

2

Geschäftsprozesse realisieren auf fünf Ebenen Modelle sind vereinfachte Abbilder der Realität und helfen, Zusammenhänge einfach und verständlich darzustellen. Das bekannteste Prozess-Modell ist das Drei-Ebenen-Modell. Wir werden begründen, warum es für die betriebliche Praxis zu grob ist. Wir stellen in diesem Kapitel ein umfassendes und durchgängiges Modell vor, das fünf Ebenen zur Realisierung von Geschäftsprozessen enthält. In den anschließenden Kapiteln 3 bis 7 wird das Vorgehen innerhalb der verschiedenen Gestaltungsebenen detailliert beschrieben.

2.1

Klassisches Drei-Ebenen-Modell Zunächst soll an das bekannte systemische Drei-Ebenen-Modell erinnert werden, das häufig in Literatur (beispielsweise [Ös95]) und Praxis zitiert wird. Es werden drei Ebenen Strategie, Prozesse und Systeme unterschieden. Ausgehend von der Unternehmensstrategie werden die Prozesse im Unternehmen definiert und beschrieben. Stehen die Prozesse fest, werden Systeme für die Unterstützung der Geschäftsprozesse eingeführt (Top-downAnsatz).

15

2

Geschäftsprozesse realisieren auf fünf Ebenen

Bemerkung

Manche Führungskräfte sehen die Gestaltungsreihenfolge aus ihrer Erfahrung mit Systemhäusern genau umgekehrt. Aus den Möglichkeiten, die die eigenen IT-Systeme bieten, müssen Prozesse so gut es eben geht abgebildet werden. Aus dem ergibt sich, was dem Unternehmen letztendlich möglich ist, und die Strategie des Unternehmens muss sich dementsprechend der Produktphilosophie fügen... (Bottom-up-Ansatz) Diese Bemerkung mag überzeichnet sein, sie hat einen wahren und realistischen Kern. In vielen Fällen ist es schlichtweg zu teuer, individuelle Lösungen zu verfolgen, die sich nahtlos in die Strategie einfügen. So ist die Orientierung an standardisierten Systemen und standardisierten Prozessen – mit einigen individuellen Anpassungen – eine durchaus gängige Methode. Und bei nicht-wettbewerbsrelevanten Prozessen ist diese Vorgehensweise legitim.

Grenzen des Drei-Ebenen-Modells Umsetzung: Das Modell gibt keine konkreten Empfehlungen für die Umsetzung in die Praxis. Es wird nicht hinreichend dargestellt, wie man von einer Strategie zum Prozess und daraus zur technischen Unterstützung (IT-System) gelangt. Linearität: Betrachtet man das Modell prozessorientiert, erhält man einen streng sequentiellen dreistufigen Prozess.

16

2.2

Das Fünf-Schichten-Modell zur Realisierung von Geschäftsprozessen Es wurde bereits darauf hingewiesen, dass rein sequentielle Prozesse in der Praxis seltener auftreten. Für eine einfache Vorstellung ist dies zwar hilfreich, nicht aber für die Realisierung. Dem Modell fehlen weiter die gegenseitigen Abhängigkeiten und die Möglichkeiten der Prüfung, ob die Prozesse den Anforderungen entsprechen bzw. ob die IT-Lösungen die Anforderungen wie gewünscht unterstützen. Aus diesem Grund wurde das Modell von den Autoren erweitert. Es hat sich in der Prozessberatung in vielen Projekten bewährt.

2.2

Das Fünf-Schichten-Modell zur Realisierung von Geschäftsprozessen Das Vorgehen des Buches zum Realisieren von Geschäftsprozessen lässt sich von einem Fünf-Ebenen-Modell leiten.

Die Bedeutung der fünf Ebenen wird im folgenden kurz beschrieben. Die einzelnen Ebenen werden dann in weiteren Kapiteln detailliert behandelt und von einer durchgängigen Fallstudie begleitet.

17

2

2.3

Geschäftsprozesse realisieren auf fünf Ebenen

Ebene 1: Zielsetzung und Strategie (Kapitel 3) Geschäftsprozesse wurden in den vergangenen Jahren in viele strategische Unternehmensmodelle aufgenommen. Methoden zur Beschreibung, Implementierung und Verbesserung von Prozessen werden wir in Kapitel 3 vorstellen. Hierzu gehören beispielsweise EFQM (European Foundation for Quality Management) oder Balanced Scorecard. Wir werden diese und einige andere Modelle diskutieren und ihre Einsatzfelder für die Realisierung von Geschäftsprozessen gegenüberstellen. Abhängig von der Unternehmensstrategie werden höchst unterschiedliche Anforderungen an die Gestaltung und Realisierung von Geschäftsprozessen gestellt. Diese können von qualitativer Natur. wie Kundenzufriedenheit oder Umweltverträglichkeit, oder von quantitativer Natur sein, zum Beispiel Durchlaufzeiten oder Ressourcenverbrauch. Ein weiterer Aspekt behandelt die grundlegenden Strategien beim Prozessmanagement. Wir differenzieren fünf verschiedene Prozesstypen und skizzieren, welche Strategien in welchen Anwendungsfällen am besten greifen. Zur Strategie gehört auch die Einrichtung von Maßnahmen und Werkzeugen zur Kontrolle von Geschäftsprozessen.

2.4

Ebene 2: Architektur und Planung (Kapitel 4) Noch vor dem konkreten Entwurf müssen die verschiedenen Gestaltungsmöglichkeiten von Prozessen geklärt und mit den Beteiligten abgestimmt werden. Prozesse werden häufig als logische Kette entworfen. Es müssen jedoch darüber hinaus vernetzte Strukturen oder Schleifen in der Prozessfolge erkannt und dargestellt werden. Die Fähigkeit eines Prozess-Systems, häufige Sonderfälle behandeln zu können, kann als besondere „Herausforderung“ und „Qualität“ betrachtet werden. Daher müssen mögliche Strukturierungstypen der Prozessarchitektur gezeigt werden. Welche Prinzipien gibt es und welche Abhängigkeiten können entstehen? Außerdem ist zu klären, wie Prozesse von der Aufbauorganisation abhängig sind. Zusammengefasst beschreibt das Kapitel 4 verschiedene Gestaltungsrahmen zur Prozessarchitektur.

18

2.8

2.5

Zusammenfassung

Ebene 3: Modell und Beschreibung (Kapitel 5) Das Kapitel 5 nimmt eine Strukturierung der Beschreibungswerkzeuge vor. Hier soll ein Verständnis für die verschiedenen Sichtweisen zur Beschreibung von Geschäftsprozessen geschaffen werden. Einfache Kriterien helfen, geeignete Methoden für die eigenen Modellierungs- und Beschreibungsaufgaben herauszufinden.

2.6

Ebene 4: Test und Plausibilisierung (Kapitel 6) Kapitel 6 mag vielleicht erstaunen: Prozesse testen? In der Tat: Der klassische Weg ist, dass Prozesse beschrieben und dann unmittelbar auf IT-Systeme abgebildet werden. Der Test erfolgt erst am lauffähigen IT-System. Prozessmodelle selbst werden häufig nicht überprüft. Unzureichende Prozessbeschreibungen schlagen sich in unzureichender Funktionalität des ITSystems nieder. Zur Praktikabilität und Akzeptanz eines Prozesses gehören bedeutend mehr Informationen, als die Betrachtung des entwickelten IT-Systems. Ziel muss es sein, frühzeitig eine Vorstellung des Geschäftsprozesses zu bekommen, wie er in der konkreten Praxis aussieht, noch bevor dieser in einer IT-Lösung realisiert wird. Herausforderung ist, den Prozess mit den beteiligten Personen und ITSystemen zu simulieren. Dies nennen wir den „Prozess erlebbar“ machen und ist eine Testmethode, die den Anforderungen an die zu realisierenden Geschäftsprozesse gerecht wird.

2.7

Ebene 5: Implementierung und Anwendung (Kapitel 7) Die fünfte und letzte Ebene ist die Realisierung auf Systemebene. Es werden Ansätze gezeigt und Technologien skizziert, die heute auf dem Markt zur Umsetzung von Prozessen verfügbar sind (Kapitel 7).

2.8

Zusammenfassung Das klassische Drei-Ebenen-Modell enthält die Elemente Strategie, Prozesse und Systeme. Es ist als theoretisches Modell etabliert, reicht aber für praktische Konzepte nicht aus.

19

2

Geschäftsprozesse realisieren auf fünf Ebenen Das Fünf-Ebenen-Modell repräsentiert fünf unterschiedliche Arbeitsgebiete, die getrennt voneinander betrachtet werden können, sich aber gegenseitig beeinflussen.

2.9

Aufgaben und Fallstudie Am Ende der Kapitel 3 bis 7 finden Sie eine Checkliste mit Fragen, die helfen, den Inhalt des jeweiligen Kapitels in Ihre Praxis umzusetzen. Damit können Sie ein eigenes Beispiel entwickeln und in den Kontext Ihres Unternehmens einordnen. Bei der Realisierung Ihrer Geschäftsprozesse hilft auch das Kapitel 8. In einer durchgängigen Fallstudie werden alle fünf Ebenen exemplarisch erläutert und damit gezeigt, wie das Modell in die Praxis umgesetzt werden kann.

20

3

Unternehmersicht: Prozesse strategisch gestalten In diesem Kapitel betrachten wir den Zusammenhang zwischen der Unternehmensstrategie und der Gestaltung von Geschäftsprozessen. Literatur und Praxis kennen zahlreiche Konzepte zur Darstellung der vielschichtigen Aufgaben in Unternehmen. Strategiemodelle sollen die Strukturen, die Dynamik und die Fähigkeiten eines Unternehmens leichter verständlich machen. Nur mit diesem Verständnis ist es möglich, gezielte Maßnahmen einzuleiten, beispielsweise um die Kundenzufriedenheit und die Produktivität zu verbessern. Verschiedene Strategiemodelle werden in diesem Kapitel vorgestellt und ihr Bezug zur Gestaltung von Geschäftsprozessen erläutert. Weiter werden wir verschiedene Konzepte für das Management von Geschäftsprozessen vorstellen und zeigen, dass unterschiedliche Typen von Prozessen bestimmte Vorgehensweisen erfordern. Zum Abschluss des Kapitels werden wir erläutern, wie mit Hilfe des Prozesscontrollings nachvollzogen werden kann, ob definierte Prozessziele erreicht worden sind.

3.1

Prozesse in Unternehmensstrategien

3.1.1

Business Process Re-Engineering

BPR - die radikale Methode

Eine radikale Methode zur Implementierung von Geschäftsprozessen ist das Business Process Re-Engineering (BPR), das in den Neunziger Jahren von Hammer und Champy vorgeschlagen wurde [HAM94]. Dieses Konzept bedeutet, dass in einem Unternehmen oder in einem größeren Teilbereich die Prozesse grundsätzlich neu überdacht und gestaltet werden. Das kann dann erforderlich werden, wenn die vorhandenen Strukturen so starr sind, dass durch singuläre Änderungen keine nennenswerten Verbesserungen mehr zu erwarten sind. Der Handlungsdruck auf das Unternehmen ist so groß geworden, 21

3

Unternehmersicht: Prozesse strategisch gestalten dass eine komplexe Veränderung notwendig wird. Vorhandene Strukturen der Organisation können nicht berücksichtigt werden. Es kann so zu Identitätsverlusten der Organisation und ihrer Mitglieder kommen.

Ausrichtung an IT-Systemen

Dieser Ansatz gewinnt eine besondere Bedeutung, wenn man den Bezug zu IT-Systemen herstellt. Bei der Einführung einer unternehmensweiten Software kann es einfacher sein, die alten Prozesse in Frage zu stellen und völlig neu zu definieren. Allerdings werden bei diesem Ansatz die Auswirkungen und Folgekosten auf die Veränderungen der Ablauforganisation, der Arbeitsweisen und Qualifikation der Mitarbeiter häufig unterschätzt. Die Bemerkung aus Kapitel 2.1 bekommt damit jedoch eine positive Bedeutung. Eine Entscheidung für einen IT-Einsatz ist immer auch eine strategische Entscheidung. Die Methode hat zweifelsohne Vorteile, denn eine zentrale Planung und Gestaltung von Ablauf- und Aufbauorganisation bringt für das Management eine klare Ordnung. Heute hat diese Methode abnehmende Bedeutung. Schließlich bestehen in Unternehmen bereits Abhängigkeiten und Verflechtungen von IT-Systemen und Partnern, die nicht ohne weiteres transformiert werden können. Nur in besonderen Einzelfällen sind Prozesse und Systeme auf der „grünen Wiese“ implementierbar.

3.1.2

ISO 9000:2000 und ISO 9001 Die Normenfamilie ISO 9000, 9001, 9004 enthält Anforderungen an die Gestaltung eines Qualitätsmanagement-Systems (QMSystem). Dabei besteht die Aufgabe, die wichtigen und kritischen Erfolgsfaktoren für ein Unternehmen zu dokumentieren und zu steuern. Solche Erfolgsfaktoren sind beispielsweise Mitarbeiter, Methoden, Verfahren, Prozesse und Informationen.

ISO 9000:2000 Prozesse im modernen Fokus

22

Im ersten Kapitel wurde erläutert, dass die Bedeutung von Prozessen in den letzten Jahren deutlich gewachsen ist. Dies schlägt sich auch in der Neufassung DIN EN ISO 9000:2000 nieder, die um wesentliche Punkte ergänzt und vor allem um den Abschnitt „Prozesse“ erweitert wurde.

3.1

Prozesse in Unternehmensstrategien

Der ISO/TC 176 hat aus den überarbeiteten Normen acht „quality management principles“ definiert. Prinzip 4 heißt „Vorgehen mittels Prozessen“: „Ein erwünschtes Ergebnis wird effizienter erreicht, wenn die betroffenen Ressourcen und Aktivitäten als Prozesse geleitet werden.“ Diese Empfehlung enthält noch wenig praktische Hilfestellungen, konkreter wird die folgende Norm.

ISO 9001 In der Einleitung zur ISO 9001:2000, Abschnitt 0.2 wird als Neuerung ein komplettes Prozessmodell eingeführt. Dieser prozessorientierte Ansatz kann verstanden werden als x

das systematische Ermitteln der Prozessarchitektur,

x

das Festlegen und Gewichten von Kriterien zur Bewertung eines Prozesses,

x

das Messen und Prüfen der Prozesse und

x

Maßnahmen zur Erreichung der geplanten Ergebnisse.

Die Norm ISO 9001 definiert die Anforderungen an ein Qualitätsmanagement-System auf Grundlage eines Prozessmodells, welches die Bestandteile eines QM-Systems in einen strukturellen Zusammenhang bringt (siehe Abbildung 13).

23

3

Unternehmersicht: Prozesse strategisch gestalten

Zwei Steuerkreise: Kunde und Optimieren

Das QM-Modell nach ISO 9001 besteht aus zwei Steuerkreisen. Zum einen gibt es einen Steuerkreis, der zeigt, wie die Anforderungen und Wünsche der Kunden aufgegriffen werden und in entsprechende Produkte oder Dienstleistungen münden, die an den Kunden geliefert werden. Produkte und Dienstleistungen werden durch den Kunden bewertet. Die Ergebnisse werden durch das Vorgehen Messen/Analysieren/Verbessern aufgegriffen. Dies stellt den Übergang in den zweiten Regelkreis dar. Er steuert alle Aktivitäten, um das Management der Prozesse so zu verbessern, dass die Kundenzufriedenheit bzw. die Effizienz steigt. Der zweite Regelkreis umfasst zusätzlich die Bereiche Verantwortung der Leitung und Management der Ressourcen. Damit sollen die Voraussetzungen zur Verbesserung der operativen Prozesse geschaffen werden. Das ISO-Prozessmodell zeigt in seinen Komponenten das Zusammenwirken wichtiger Prozessgruppen. Jede dieser Prozessgruppen wird noch feiner gegliedert und detaillierter beschrieben. Die Norm legt also fest, welche Prozesse in einem Unternehmen betrieben werden und welche Aspekte in den Prozessen eines Unternehmens berücksichtigt werden müssen, um die Norm zu erfüllen.

3.1.3

Total Quality Management

Im Mittelpunkt steht der Kunde

Total Quality Management (TQM) bezeichnet eine Unternehmensstrategie, „die auf die Erfüllung der Kundenwünsche abzielt, so dass der interne und externe Kunde im Mittelpunkt der Bemühungen steht“ [Pf01]. Damit soll ein langfristiger Geschäftserfolg sowie ein entsprechender Nutzen für die Mitglieder der Organisation und der Gesellschaft erreicht werden. Abbildung 14 zeigt das Zusammenwirken der Aufgaben und Unterstützungsprinzipien, um sich den Zielen von TQM Schritt für Schritt anzunähern [Ka00]. Dabei wird deutlich, dass zwei Methoden des TQM die kontinuierliche Verbesserung und die Prozessorientierung sind. Diese Grundlagen unterstützen verschiedene Aufgaben, um die Ziele des Unternehmens zu erreichen.

24

3.1

Kaizen als Vorbild

Prozesse in Unternehmensstrategien

Für die kontinuierliche Verbesserung wird oft der japanische Begriff Kaizen verwendet, was soviel wie „Veränderung zum Besseren“ bedeutet. Alle Führungskräfte und Mitarbeiter suchen in der gesamten Organisation permanent nach Möglichkeiten, die Qualität zu verbessern und/oder die Kosten zu reduzieren [Sm02]. Der ständige Verbesserungsprozess gliedert sich in die Phasen Planen (Plan), Ausführen (DO), Überprüfen (Check) und Anpassen (Act). Abbildung 15 zeigt diesen Plan-Do-Check-Act- Zyklus, der oft nach seinem Erfinder auch Deming-Cycle genannt wird. Der allgemeine TQM-Ansatz gilt für alle Unternehmen unabhängig von der Branche, Größe usw. Allerdings muss dieser allgemeine Ansatz für die Umsetzung in einem Unternehmen konkretisiert werden. Unternehmen benötigen einen Orientierungsrahmen, an dem sie ihre Vorgehensweise bei der Einführung von TQM anlehnen können [Ka00]. Zusammengefasst steht bei TQM die kurzfristige Prozessoptimierung im Vordergrund.

25

3

Unternehmersicht: Prozesse strategisch gestalten

3.1.4

EFQM Unternehmensbewertung

Vom WAS zum WIE

Während die ISO 9001 fordert, dass bestimmte Aspekte durch einen zugeordneten Prozess oder innerhalb eines entsprechenden Prozesses abgedeckt sind („WAS“) [Ka00], betrachtet EFQM (European Foundation for Quality Management), wie Prozesse identifiziert, aufgebaut und verbessert werden können („WIE“). EFQM liefert Sichten auf ein Unternehmen und Kriterien, um den Stand des Unternehmens zu bewerten. Somit kann das EFQMModell auch als ganzheitliches Modell zur Führung eines Unternehmens genutzt werden. Das EFQM-Modell ist eine Konkretisierung des allgemeinen TQM-Ansatzes. Das EFQM-Modell besteht aus 9 Kriterien, die zur Bewertung des Fortschritts einer Organisation in Richtung TQM herangezogen werden. Abbildung 16 zeigt diese neun Kriterien.

Befähiger und Ergebnisse

26

Die neun Kriterien teilen sich in zwei Gruppen, den Befähigern und den Ergebnissen. Die Befähiger-Kriterien beschäftigen sich damit, wie eine Organisation ihre Hauptaktivitäten abwickelt. Durch die Befähiger-Kriterien werden die jeweiligen Vorgehensweisen betrachtet, die eingesetzt werden, um die gewünschten Ergebnisse zu erreichen (Plan, Do).

3.1

Prozesse in Unternehmensstrategien

Die Ergebnis-Kriterien bewerten, welche Ergebnisse durch die Vorgehensweisen erzielt wurden. Die erreichten Ergebnisse beeinflussen wiederum die Vorgehensweisen. Wurden die gewünschten Ergebnisse nicht erzielt, werden die Vorgehensweisen geändert und angepasst (Check, Act). RADAR-Logik

Für die Bewertung der einzelnen Kriterien wird die sogenannte RADAR-Logik eingesetzt. Die Elemente der RADAR-Logik sind Ergebnisse, Vorgehen, Umsetzung, Bewertung und Überprüfung. Wobei die Elemente Vorgehen, Umsetzung und Bewertung beispielsweise nur bei den Befähiger-Kriterien und das Kriterium Ergebnisse nur bei den Ergebniskriterien eingesetzt werden (Abbildung 15). Das Ergebnis der Bewertung durch ein Kriterium ist ein Prozentsatz, der angibt, in welchem Ausmaß das Kriterium erfüllt ist. Die Ergebnisse eines jeden Kriteriums fließen zu einem bestimmten Anteil in die Gesamtbewertung ein. Durch diese Gewichtung wird die Bedeutung eines jeden Kriteriums für den Fortschritt zum Ausdruck gebracht. Am höchsten gewichtet wird bei den Befähigern das Kriterium Prozesse (14%) und bei den Ergebnissen die Kriterien Kundenergebnisse (20%) und Schlüsselleistungen (15%). Diese Kriterien spielen für ein Total Quality Management die größte Rolle. Daraus kann abgeleitet werden, dass durch passende und wirksame Prozesse eine hohe Kundenzu27

3

Unternehmersicht: Prozesse strategisch gestalten friedenheit und ein exzellenter Geschäftserfolg erzielt werden kann. Die maximale Punktanzahl bei EFQM sind 1000 Punkte. Das entspricht einem perfekten Unternehmen. Das EFQM-Modell will kein starres, normatives Vorgehen vorgeben, sondern überlässt es dem Unternehmen, seine Vorgehensweisen zu finden und einzusetzen, um die geforderten Kriterien zu erfüllen. Das Modell kann also für Organisationen der unterschiedlichsten Größen oder Branchen verwendet werden. Das EFQM-Modell gibt nicht vor, welche Prozesse ein Unternehmen einführt, um Kundenzufriedenheit bzw. ein gutes Geschäftsergebnis zu erzielen. Mit EFQM kann Effizienz und Effektivität von Prozessen gemessen werden. Folgende Voraussetzungen und Vorabreiten sind hierzu notwendig:

3.1.5 Kennzahlensystem

28

x

Systematisches Gestalten und Managen der Prozesse

x

Kontinuierliche Prozessverbesserung zur Erhöhung der Kundenzufriedenheit und Steigerung der Wertschöpfung

x

Ausrichtung der Produkte und Dienstleistungen auf den Kunden hin

x

Sicherstellung der Services für Produkte und Dienstleistungen

x

Pflege der Kundenbeziehungen

x

Definition der strategischen Ziele in den einzelnen Unternehmensperspektiven

x

Festlegen der strategischen Maßnahmen mit den jeweiligen Zielen, sowie Kriterien und Kennzahlen zur Beurteilung der Zielerreichung

Balanced Scorecard Balanced Scorecard ist ein Management-Instrument zur strategischen Führung eines Unternehmens mit Hilfe eines Kennzahlensystems [Ge00]. Die Methode wurde von Norton und Kaplan vorgeschlagen [Kap97]. Dieses Konzept hat inzwischen weite Akzeptanz gefunden.

3.1

Prozesse in Unternehmensstrategien

Mit Hilfe einer Balanced Scorecard werden von der Leitung der betrachteten Organisation zunächst eine Vision aufgestellt und daraus eine Mission entwickelt. Welche Ziele sollen erreicht werden und wie ist der Weg dorthin? Anschließend werden mit allen Führungskräften die Strategien des Unternehmens erarbeitet, d. h. es wird festgelegt, über welche Zwischenziele (strategische Ziele) sich der Vision und Mission genähert werden soll. Die strategischen Ziele werden einer bestimmten Perspektive zugeordnet. In der Regel werden die vier Standardperspektiven Finanzen, Kunden, Prozesse oder Mitarbeiter/Potentiale betrachtet. Diese vier Zielbereiche bilden eine Hierarchie, wobei die Finanzperspektive die oberste Ebene darstellt, es folgt die Kundenperspektive, dann die Prozessperspektive und schließlich die Potential- und Mitarbeiterperspektive. Strategische Ziele einer Perspektivebene können Ziele in der gleichen oder einer höheren Ebene stützen. Ziele in Wirkungsketten organisiert

Die einzelnen Ziele bilden Wirkungsketten, die aufzeigen, wie die wichtigsten Ziele, nämlich die Finanzziele, unterstützt und damit erreicht werden sollen. Die Wirkungsketten spiegeln die Kausalität der strategischen Überlegungen wieder. Abbildung 18 zeigt ein abstraktes Beispiel einer Wirkungskette zur Steigerung des Unternehmenserfolges.

29

3

Unternehmersicht: Prozesse strategisch gestalten

Für jedes strategische Ziel werden Messgrößen und Zielwerte festgelegt. Durch das Erreichen oder Nicht-Erreichen der Werte kann beurteilt werden, ob die strategischen Ziele erreicht wurden. Durch dieses Vorgehen werden Vision und Mission in ein Kennzahlensystem übersetzt. Die strategischen Ziele können abhängig von der Organisation weiter detailliert werden. Teilorganisationen können eine Balanced Scorecard aus der übergeordneten Balanced Scorecard ableiten. Diese Kaskadierung kann bis hin zum einzelnen Mitarbeiter erfolgen, dessen persönliche Ziele aus einer Kette von Balanced Scorecards abgeleitet sind. Abbildung 19 zeigt beispielhaft eine Zielhierarchie. Die Balanced Scorecard bildet ein generisches Modell, das an die spezielle Situation eines Unternehmens angepasst werden kann. Mit diesem Modell wird die Strategie beschrieben, mit deren Hilfe die Führung einer Organisation die angestrebten Ziele erreichen will.

30

3.1

Prozesse in Unternehmensstrategien

Eine Balanced Scorecard ist im Gegensatz zum EFQM-Modell unternehmensspezifisch, das unabhängig von der Organisation betrachtet, wie die Prozesse umgesetzt werden sollen. Die Balanced Scorecard ist in die Zukunft gerichtet, während mit dem EFQM-Bewertungsverfahren stärker die Gegenwart betrachtet wird .

3.1.6

Six Sigma

Starker Statistikbezug

Six Sigma ist eine systematische Methode zur Optimierung von Prozessketten. Sigma (V) beschreibt eine Metrik für Fehlerhäufigkeiten. Bei Sigma 1 liegt die Fehlerwahrscheinlichkeit bei fast 70%, während bei Sigma 6 die Fehlerrate nur bei 3,4 10-6 % liegt. Für das Geschäftsprozessmanagement unterschiedet Six Sigma zwei Methoden: x

Verbesserung von Prozessen (DMAIC)

x

Neugestaltung von Prozessen (DFSS)

31

3

Unternehmersicht: Prozesse strategisch gestalten Die Vorgehensweise von Six Sigma betrachtet drei sogenannte Diagnoseräume: Prozesstür, Datentür und Kulturtür. Damit wird der Blick auf die ganze Organisation geöffnet. Die Methodik Six Sigma arbeitet mit komplizierten statistischen Modellen und wirkt sehr mathematisch und schwer durchschaubar.

3.1.7

Gegenüberstellung und Bewertung Die Gegenüberstellung der verschiedenen strategischen Methoden zeigt, dass der Zusammenhang zwischen Strategie und Prozessen auf sehr unterschiedliche Art und Weise erfolgen kann: x

Radikale Neugestaltung von Prozessen (Business ReEngineering)

x

Beschreibung wichtiger Prozessgruppen im Unternehmen (ISO 9000:2000 und ISO 9001)

x

Ständige Verbesserung von Prozessen (TQM)

x

Messung und Bewertung der Prozessverbesserungen (EFQM)

x

Zukunftsausrichtung der Prozesse (Balanced Scorecard)

x

Minimierung von Prozessfehlern (Six Sigma)

Die Methoden haben für die praktische Anwendung auch Schwächen:

32

x

Es fehlen Kriterien zur Entscheidung für Optimierung oder Neugestaltung von Prozessen.

x

Prozess-Strukturen orientieren sich weitgehend an allgemeinen Standards; diese können für die eigene Organisation relevant sein, müssen aber nicht.

x

Es gibt keine Hilfestellung zur Gestaltung der unternehmensspezifischen und damit wettbewerbsentscheidenden Prozesse.

x

Der Weg geht von der Strategie zum Prozess, konkrete Verbindungen von Prozessen zu Systemen fehlen.

x

Die Nutzenansätze sind zu sehr auf die Effizienz der Prozessdurchläufe ausgerichtet. Ansätze für eine unternehmensübergreifende Betrachtungsweise sind nur ansatzweise vorhanden.

3.2

3.2

Strategisches Vorgehen im Geschäftsprozessmanagement

Strategisches Vorgehen im Geschäftsprozessmanagement Im ersten Abschnitt wurden Unternehmensstrategien beschrieben und wie Prozesse darin eingebettet sind. Nun werden wir klären, welche Schlussfolgerungen für das Geschäftsprozessmanagement aus den Prozessen abgeleitet werden kann. Dazu werden fünf verschiedene Prozesstypen charakterisiert und davon eine grobe Methodik für das Vorgehen abgeleitet.

3.2.1

Differenzierung der Prozesstypen Im Folgenden werden fünf Prozesstypen skizziert. Die Einteilung erfolgt aufgrund der langjährigen praktischen Erfahrungen der Autoren. Prozesse haben unabhängig von Branche und Struktur weitere Unterscheidungsmerkmale. Das hängt davon ab, wie Prozesse im Unternehmen eingeführt und verankert sind. Wir unterscheiden: 1.

Wettbewerbsrelevante Prozesse

2.

Change-sensitive Prozesse

3.

IT-terminierte Prozesse

4.

Wissensintensive Prozesse

5.

Zombie-Prozesse

Erläuterungen: Zu 1. Wettbewerbsrelevante Prozesse: Dieser Prozesstyp spielt eine entscheidende Rolle für die Wettbewerbsfähigkeit des Unternehmens und bildet das Alleinstellungsmerkmal ab. Zu 2. Change-sensitive Prozesse: Solche Prozesse müssen häufig an neue Geschäftsbedingungen angepasst werden. Jede Anpassung ist von der Komplexität her vergleichbar mit einer Neuorganisation des Prozesses. Zu 3. IT-terminierte Prozesse: Der Prozess ist stark von der IT-Unterstützung (beispielsweise Workflow-Systemen) abhängig.

33

3

Unternehmersicht: Prozesse strategisch gestalten Zu 4. Wissensintensive Prozesse: Bei der Definition oder Ausführung solcher Prozesse ist umfangreiches Wissen notwendig. Zu 5. Zombie-Prozesse: Solche Prozesse „funktionieren irgendwie“, werden von der Organisation nicht richtig verstanden oder beherrscht. In der betrieblichen Praxis können Prozesse häufig nicht eindeutig einem bestimmten Prozesstyp zugeordnet werden, es existieren zahlreiche Mischformen. Für die Unternehmensführung ist es sehr hilfreich, sich an den Prozesstypen zu orientieren. Aus den fünf Prozesstypen ergeben sich fünf Strategien für das Geschäftsprozessmanagement (GPM). Tabelle 1: Typisierung Geschäftsprozessmanagement (GPM) Externe Orientierung x

wettbewerbsorientiertes GPM

x

change-sensitives GPM

Interne Orientierung x

IT-terminiertes GPM

x

wissensorientiertes GPM

x

organisationsorientiertes GPM

Im folgenden werden die unterschiedlichen Strategien erklärt und mit Beispielen erläutert.

3.2.2

Typenabhängiges Geschäftsprozessmanagement Wettbewerbsorientiertes Geschäftsprozessmanagement Haben Sie sich schon einmal Gedanken gemacht, welche Prozesse entscheidend für Ihren Geschäftserfolg sind? Womit differenzieren Sie sich vom Wettbewerb?

Beispiel

34

Der Erfolg des Internet-Buchhändlers amazon ist vor allem auf seinen ausgefeilten Logistik-Prozess zurückzuführen, mit dem viele Partner an das Versandsystem angeschlossen sind. Das hat Auswirkungen auf die Anforderungen an die Stabilität und Qualität der Prozesse, aber auch an die unterstützenden Systeme.

3.2

Strategisches Vorgehen im Geschäftsprozessmanagement

Methodik Es ist eine strategische Entscheidung, unterstützende Prozesse mit Standardsystemen abzubilden. Prozesse, die für das Unternehmen ein USP (Unique Selling Proposition) darstellen, sollten nicht durch Standards unterstützt werden.

Change-sensitives Geschäftsprozessmanagement In allen Strategiemodellen fehlt die explizite Betrachtung und Beurteilung, wie Prozesse langfristig stabil aufgebaut werden müssen. Kurzfristige ad-hoc-Lösungen, die langfristig immer wieder korrigiert werden müssen, verursachen hohe Kosten. Prozessveränderungen müssen als eigener Prozess begriffen und unterstützt werden! Change-sensitives Geschäftsprozessmanagement hat das Ziel, flexibel auf neue Prozess-Anforderungen zu reagieren. Fokus ist, Anforderungen weitgehend zu standardisieren und den Prozess flexibel zu halten. Prozess-Veränderungen durch Anpassung von Parametern (Customizing) zu realisieren, ist eine häufig praktizierte Methode, wandelbare IT-Systeme gelten als hoffnungsvoller Ansatz [In04]. Diesen Ansätzen fehlt die Orientierung an der Unternehmensstrategie und die methodische Unterstützung.

Wir betrachten im folgenden die Abhängigkeiten zwischen Prozessen und IT-Systemen bei auftretenden Änderungen. 1.

Änderungen von Prozessen auf IT-Systemen:

Wie müssen IT-Systeme eingerichtet werden, damit sie auf Prozessänderungen flexibel reagieren? Beispiel

Fusion zweier bisher unabhängiger Unternehmen: Mit der Fusion wird eine weitreichende Umstrukturierung der Prozesse erforderlich. Kernfrage: Wie können die vorhandenen IT-Systeme mit möglichst wenig Aufwand umgestaltet werden? 35

3

Unternehmersicht: Prozesse strategisch gestalten 2.

Änderungen von IT-Systemen auf Prozesse:

Releasewechsel können weitreichende Auswirkungen auf Prozesse haben. Wie kann gewährleistet werden, dass die Prozesse trotzdem stabil laufen? Beispiel

Ein Unternehmen setzt ein CRM- und ein ERP-System desselben Herstellers ein. Die Prozesse innerhalb des Unternehmens nutzen beide Systeme, die über eine Schnittstelle miteinander verbunden sind. Allerdings funktioniert die Schnittstelle nur für die jeweils aktuelle Softwareversion. Eine neue Softwareversion des einen Produktes macht zwingend einen Upgrade des anderen Produktes notwendig, und weitere Kosten fallen an, weil die Prozesse an die neue Version angepasst werden müssen. Besser wäre es gewesen, die Prozesse so zu gestalten, dass möglichst wenige gegenseitige Abhängigkeiten bestehen. Methodik: Aufbau eines MUST-Prozesses Ein Weg zur Implementierung eines change-sensitiven Prozesses kann ein MUST-Prozess (minimaler universeller Standardprozess) sein. Jeder Mitarbeiter und jede Abteilung haben von einem Prozess unterschiedliche Vorstellungen und Begriffe. In Unternehmen wird oft von vielen unterschiedlichen Prozessen gesprochen, teilweise wird jedoch von den selben Prozessen gesprochen. Häufig werden dann Prozesse neu implementiert und verändert, ohne zu untersuchen, ob vorhandene Prozesse mit minimalem Aufwand angepasst, verändert werden können. Ein Weg zur Lösung dieses Dilemmas ist der Aufbau eines MUST-Prozesses (Referenz-Prozess). Ziel ist, den Prozess auf eine möglichst kleine gemeinsame Basis zu stellen, die jedoch von allen Beteiligten verstanden und akzeptiert wird. Außerdem werden die verschiedenen Systemlösungen transparent. Mit der Umsetzung eines MUST-Prozesses gelangt man auch zur nächsten Ebene in unserem Fünf-Ebenen-Modell. Die Klärung einer unabhängigen Prozess-Architektur ist wesentlicher Bestandteil eines MUST-Prozesses. Ein Weg, um einen MUST-Prozess zu definieren, kann über die Aufarbeitung der Wissensstrukturen gehen. Alle Prozess-

36

3.2

Strategisches Vorgehen im Geschäftsprozessmanagement

Beteiligten müssen die selbe Vorstellung und Begrifflichkeit des Prozesses finden. Aus diesem Grund besteht eine Verwandtschaft zum wissensorientierten Geschäftsprozessmanagement. Beispiel

Der Bestellprozess eines Konzerns existiert in vielen Varianten. Jedes Werk hat ihn separat gestaltet, und in einem Werk gibt es sogar mehrere Ausprägungen gleichzeitig. Es ist klar, dass diese Vielfalt unnötige Kosten verursacht. Jedes Werk pflegt eigene Softwaresysteme. Bei Änderungen muss eine Vielzahl gleichartiger Prozesse angepasst werden. Ein MUST-Prozess ist ein nützliches Hilfsmittel. Er gibt einen Überblick über die wesentlichen Prozesseigenschaften, die in allen Organisationseinheiten gelten. Aus diesem Überblick lassen sich Maßnahmen ableiten, Synergien nutzen und die Prozesse so anpassen, dass sie den unterschiedlichen Anforderungen gerecht werden.

IT-terminiertes Geschäftsprozessmanagement Aufgabe eines IT-terminierten GPM ist es, die Möglichkeiten der vorhandenen IT-Systeme in optimaler Weise zu nutzen. Die Prozesse werden in Abhängigkeit der IT-Systeme gesehen, aufgebaut und betrieben. Prozessänderungen müssen sich in hohem Maße an den technischen Möglichkeiten orientieren. Das Buch orientiert sich stark an IT-terminierten Prozessen und soll eine Anleitung geben, diese zu realisieren.

Wissensorientiertes Geschäftsprozessmanagement Seit einigen Jahren taucht mit dem Wissensmanagement im Geschäftsprozessmanagement eine neue Sicht auf. Oberflächlich betrachtet haben Prozesse und Wissen einer Organisation wenig miteinander zu tun. Auf der einen Seite geht es um Abläufe der Aktivitäten, auf der anderen Seite um das Wissen, das bei den Mitarbeitern und damit in der Organisation implizit und explizit verfügbar ist.

37

3

Unternehmersicht: Prozesse strategisch gestalten

Beispiele

Dennoch hängen beide Themen voneinander ab. x

Welches Wissen (beispielsweise Prozesserfahrung) ist für den korrekten Aufbau von Prozessen erforderlich?

x

Welches Wissen brauchen die Beteiligten beim Durchlauf eines Prozesses?

x

Welches Wissen ergibt sich aus den Prozessen?

x

usw.

In diesem Buch werden fünf Ebenen zum Geschäftsprozessmanagement unterschieden. „Wissen“ dient als wichtiges Bindemittel zwischen diesen Ebenen. Methodik Die Automatisierung von Geschäftsprozessen erfordert eine genaue Abstimmung zwischen den Prozess-Anwendern und den unterstützenden IT-Systemen. Die Mitarbeiter müssen frühzeitig in den Veränderungsprozess eingebunden und es muss ausreichend Akzeptanz geschaffen werden. Das kann geschehen durch:

Beispiel

x

Einbindung des Wissens bei der Implementierung neuer Strukturen. Viele Ideen und Vorstellungen können einfließen, die es zu begutachten, aber auch zu filtern gilt.

x

Frühzeitige Kommunikation und Klärung des neuen Prozesses („Prozess erleben“), um die Akzeptanz zu erhöhen.

Ein kleines Unternehmen strukturiert seine Vertriebsprozesse radikal nach einer CRM-Strategie (Customer Relationship Management). Die Vertriebsmitarbeiter bekommen jetzt alle Aufgaben automatisch zugewiesen. Dennoch werden die von der Unternehmensleitung definierten Ziele, Umsatzsteigerung, Verkürzung des Verkaufszyklus und verbesserte Kundenbindung nicht erreicht. Der Grund ist die fehlende Einbindung der Mitarbeiter. Statt ihr Wissen und ihre Erfahrung zu nutzen und zu würdigen, wurden die Prozesse technokratisch den Mitarbeitern übergestülpt. Sie haben keinen Gestaltungsspielraum mehr, fühlen sich übergangen, sind demotiviert und verlassen das Unternehmen. Wer erfolgreiche Geschäftsprozesse realisieren will, muss Mitarbeiter frühzeitig und umfassend einbinden und ihr Wissen, ihre Erfahrung und ihr gestalterisches Potential nutzen!

38

3.2

Strategisches Vorgehen im Geschäftsprozessmanagement

Methoden der Einbindung Erster Schritt ist die Information der beteiligten Personen über den Änderungsbedarf der betroffenen Geschäftsprozesse. Eine verbreitete Methode der Arbeit in Großgruppen ist der sogenannte „open space“. Über 100 Mitarbeiter erarbeiten gemeinsam Lösungen in der großen Gruppe und in Kleingruppen. Dieses Vorgehen ermöglicht, dass zu einer Problemlösung das Wissen vieler zusammengetragen werden kann und durch kurze Kommunikationswege Lösungen in kurzer Zeit erarbeitet werden können. Da ein Prozess aus komplexem Wissen vieler Beteiligter besteht, ist das ein hoffnungsvoller Ansatz. Steigt jedoch die Komplexität der Aufgabenstellung, stößt diese Methode an ihre Grenzen. Das ist beispielsweise dann der Fall, wenn es um schwierige Zusammenhänge (Integrationsanforderungen) an IT-Systeme handelt. Eine weitere Methode ist, eine gemeinsame Darstellung und Bezeichnung des Prozesses zu finden, die alle Prozessbeteiligten verstehen können und die alle Prozessbeteiligte akzeptieren.

Organisationsorientiertes Geschäftsprozessmanagement Einen weiteren Ansatz bietet das organisationsorientierte Geschäftsprozessmanagement. Der Schwerpunkt liegt auf der Betrachtung der Organisation und wird im Folgenden beispielhaft an so genannten Zombie-Prozessen beschrieben. Zombie-Prozess Bei der Festlegung von Unternehmensstrategien wird häufig davon ausgegangen, dass Prozesse dokumentierbar, beherrschbar und steuerbar sind. Es treten in der Praxis immer wieder Fälle auf, in denen Prozesse, auch mit intensiver Beraterunterstützung und IT-Werkzeugen nicht beherrschbar sind. Solche Prozesse nennt man Zombie-Prozesse (Hinweis: Dieser Begriff wird ebenso bei der Beschreibung von Betriebssystemen verwendet, wird in diesem Buch jedoch in einem anderen Kontext verwendet). Kennzeichen eines Zombie-Prozesses ist, dass er „irgendwie“ funktioniert, niemand weiß so recht, wie und warum. Weil 39

3

Unternehmersicht: Prozesse strategisch gestalten er einer der Kernprozesse ist oder hohe Kosten verursacht, bindet er hohe Aufmerksamkeit im Unternehmen. Hintergrund ist häufig, dass Prozesse zu schnell und unkontrolliert eingeführt wurden und „leben müssen“. Sie laufen zwar, der Organisation wurde zu wenig Zeit gegeben, sich in sie einzugewöhnen. Die aufgezeigten Symptome sind häufig ein Indiz, dass der Prozess nicht oder nur unzureichend in der Organisation verankert ist. Ein Hinweis auf einen Zombie-Prozess kann auch sein, dass Versuche, den Prozess zu verbessern, scheitern. Verbesserungen finden noch weniger Akzeptanz als die ursprüngliche Version. Methodik Ansatzpunkt für die Auflösung eines Zombie-Prozesses ist, die betroffene Organisation zu entwickeln und zu stärken. Orientiert an der Methodik von „Six Sigma“, ist der Schlüssel zur Verbesserung die „Kultur“. Auf sie gilt es zuerst das Augenmerk zu richten, bevor der Prozess optimiert wird.

3.3

Prozesscontrolling Um einen identifizierten Prozess zu bewerten und zu verbessern, müssen die Ziele des Prozesses von der Strategie abgeleitet und definiert sein. Neben dem „Prozesse gestalten“ ist also das Messen der Prozesse eine strategische Aufgabe, das Prozesscontrolling. Die bekannteste Methode hierzu ist die Prozesskostenrechnung. Damit können beispielsweise die durchschnittlichen Kosten einer Serviceanfrage oder eines Kundenauftrags berechnet werden. Die Prozesskosten hängen stark von der benötigten Zeit und den eingesetzten Ressourcen ab und messen nur die Effizienz eines Prozesses. Die Frage nach der Effektivität eines Prozesses fließt lediglich indirekt ein. Kennzahlen helfen festzustellen, ob ein Prozess den Anforderungen entspricht. Entspricht er beispielsweise der geforderten Qualität? Kennzahlen sind stark prozessspezifisch orientiert. Während man unter dem klassischen Controllingbegriff überwiegend die Überwachung der Kosten versteht, sind im Kontext von Prozessen

40

3.3 x

Durchlaufzeiten

x

Qualität

x

Effizienz

x

Flexibilität

x

Kundenzufriedenheit und

x

Kosten

Prozesscontrolling

zu überprüfen (vgl. [Ro02]). Die folgende Aufstellung zeigt unterschiedliche Prozessziele, welche teilweise in Konkurrenz zueinander liegen.

Im Mittelpunkt einer Prozessbewertung stehen IST- und SOLLProzesse. Für diese Prozesse können Prozessmessgrößen (KPI Key Performance Indicators) definiert und eingeführt werden. KPIs liefern Kennzahlen für die in Abbildung 20 genannten Anforderungen und sind deshalb ein wichtiges Steuerungsinstrument für die Prozess-Verantwortlichen. Trotz Einführung geeigneter Kennzahlen hat die Messbarkeit von Prozessen Schwächen. Prozesstypen sind beispielsweise nur schwer quantifizierbar. Eine andere gängige Controlling-Methode ist das „benchmarking“. Prozesse werden anhand verschiedener Kriterien miteinander verglichen. Häufig vergleichen sich fremde Unternehmen 41

3

Unternehmersicht: Prozesse strategisch gestalten auf diese Art miteinander, um voneinander zu lernen und die eigene Position zu definieren. Auch innerhalb eines Unternehmens können benchmarks zur Ermittlung der Prozess-Performanz eingesetzt werden. Eine Voraussetzung für das benchmarking ist, dass die betrachteten Prozesse die gleiche Zielsetzung verfolgen und die Kennzahlen vergleichbar sind.

Grenzen des Prozesscontrollings

Prozesse sind ein ausgezeichnetes Steuerungsinstrument. Sie lassen sich quantifizieren, messen und verändern. Es muss beachtet werden, dass Prozesse ein Mittel sind, um weitere Unternehmensteile zu steuern. Die im vorherigen Kapitel angesprochene „Prozess-Typisierung“ macht genau auf diese wichtige Eigenschaft von Prozessen aufmerksam. IT-terminiertes Geschäftsprozessmanagement verfolgt beispielsweise das Ziel, dass die hinter den Prozessen liegenden IT-Systeme die verwendete Managementmethodik stark beeinflussen. Die Prozesskennzahlen haben daher nur indirekten Hebeleffekt. Prozesscontrolling wird häufig in einem geschlossenen Kreislauf als direkte Rückmeldung an die Strategie beschrieben. Die Strategie legt die Prozessbeschreibung fest, diese wird umgesetzt und gemessen. Das Ergebnis geht wieder in die Controllingmethoden ein. Dieser Ansatz ist aus obigen Gründen systemisch etwas kurz gefasst. Die fünf Ebenen der Realisierung von Geschäftsprozessen zeigt die Zusammenhänge in anderer Art und Weise auf.

3.4

Zusammenfassung Die oberste Ebene unseres Fünf-Ebenen-Modells zur Realisierung von Geschäftsprozessen beschäftigt sich mit den Aspekten „Zielsetzung und Strategie“. Zunächst wurde dargestellt, wie Geschäftsprozesse in gängige Modelle für Unternehmensstrategien, beispielsweise EFQM oder Balanced Scorecard, eingebettet werden können. Anschließend wurden unterschiedliche Prozesstypen differenziert und gezeigt, dass jeder Prozesstyp ein besonderes Management verlangt. Die Zuordnung zu diesen Prozesstypen gelingt durch die Bewertung, ob die Prozesse hauptsächlich im Kontext des Wettbewerbs, der Veränderung, der IT-Systeme, des Wissens oder des „zombiehaften“ Wildwuchses angesiedelt sind.

42

3.5

Aufgaben zur Prozess-Modellierung (Teil 1)

Das Prozesscontrolling muss sicher stellen, dass die quantitativen und qualitativen Ziele eines Prozesses erfüllt werden. Bevor konkrete Geschäftsprozesse beschrieben werden, ist es wichtig, prinzipielle Festlegungen zum Aufbau von Prozessbeschreibungen zu treffen. Einen strukturierten Überblick über grundlegende Architekturprinzipien für Geschäftsprozesse erfahren Sie im nächsten Kapitel.

3.5

Aufgaben zur Prozess-Modellierung (Teil 1) Checkliste:

)

x

Welche Strategiemodelle eignen sich grundsätzlich, um im Prozesskontext genutzt zu werden?

x

Welche Strategie ist in einem konkreten Anwendungsfall am besten geeignet?

x

Welcher Prozesstyp bzw. welche Prozesstypen liegen vor?

x

Welche Methode zum Geschäftsprozessmanagement kann daraus abgeleitet werden?

x

Ist es möglich, einen „MUST“-Prozess zu implementieren?

x

Was sind die Ziele eines Prozesses und mit welchen Kennzahlen werden diese gemessen?

x

Welche Beziehung haben die Kennzahlen zur Strategie? Hinweise zur Lösung dieses Gestaltungsschrittes finden Sie im Abschnitt 8.1. Die Fallstudie ist jedoch nicht als „Musterlösung“ zu verstehen, hier finden sich Hinweise zu einer möglichen Lösung.

43

4

Architektensicht: Prozesse übersichtlich strukturieren

Wie behält man den Überblick?

Geschäftsprozesse werden zunehmend komplexer. Gleichzeitig sollen sie flexibel sein und rasch an neue Situationen angepasst werden können. Sie müssen so strukturiert sein, dass sie zur Aufbauorganisation des Unternehmens passen. Diese vielfältigen Anforderungen zu berücksichtigen, ist die Aufgabe der Prozessarchitektur. Geschäftsprozesse können nach unterschiedlichen Architekturprinzipien entworfen und realisiert werden. Diese Prinzipien zu verstehen ist hilfreich, um die in Kapitel 5 aufgeführten Beschreibungsmethoden besser einschätzen zu können. Es werden vier Kriterien herausgearbeitet, mit deren Hilfe die folgenden Architekturprinzipien verglichen und bewertet werden können.

4.1

Architektur von Geschäftsprozessen — warum ?

Was ist Architektur ?

Architektur steht im allgemeinen für die Auseinandersetzung von Menschen mit gebautem Raum und für die Kunst oder Wissenschaft eines planvollen Entwurfs. Der Architekturbegriff findet im Anwendungsbereich von Bauwerken (Häuser, Brücken, Strassen, etc.) seine Verwendung und Interpretation. Der Begriff hat auch Einzug in vielen anderen technischen und ingenieurwissenschaftlichen Bereichen menschlichen Handelns gehalten. Man trifft beispielsweise auf Hardware-, Software- und Rechnerarchitekturen [St05]. Im Zusammenhang mit Geschäftsprozessen spricht man ebenfalls von einer Prozess-Architektur. Das sind Architekturprinzipien zur Gestaltung, Beschreibung und Realisierung einzelner Prozesse und der Darstellung ihrer Abhängigkeiten.

45

4

4.2

Architektensicht: Prozesse übersichtlich strukturieren

Architekturkriterien Um verschiedene Architekturprinzipien zu vergleichen und zu bewerten, werden Kriterien für Prozessarchitekturen definiert: Strukturierbarkeit, Sichten und Verständlichkeit, Durchgängigkeit und Flexibilität.

Strukturierbarkeit Geschäftsprozesse müssen in Komponenten oder Teilprozesse zerlegt werden können. Schnittstellen und Beziehungen untereinander müssen übersichtlich dargestellt und verständlich gemacht werden. Abbildung 22 zeigt eine einfache Prozessarchitektur mit vier Phasen.

46

4.2

Architekturkriterien

Sichten und Verständlichkeit Eine Prozessarchitektur muss unterschiedliche Sichten auf Geschäftsprozesse unterstützen, sodass verschiedene Interessensgruppen Prozesse aus ihrer Sicht betrachten und verstehen können. [Ga00] Folgende Rollen sind an einem Prozess beteiligt: Prozess-Kunde Bei wettbewerbsspezifischen Prozessen nimmt diese Rolle der Kunde des Unternehmens ein. Ein Prozess-Kunde erwartet kostengünstige, schnelle, fehlerfreie und aus seiner Sicht einfach zu handhabende Prozesse. Prozess-Sponsor Diese Rolle nimmt das Management, das für die Einführung eines Prozesses verantwortlich ist, ein. Hintergrund ist jeweils eine strategische Entscheidung: Implementierung eines neuen Geschäftsfeldes, Optimierung und Neuausrichten von Prozessen oder Erhöhung der Qualität. Prozess-Manager Der Prozess-Manager hat die Aufgabe, die Anforderungen der Fachabteilungen zu koordinieren, sowie korrekte und verständliche Prozessbeschreibungen zu liefern. Zu diesem Aufgabengebiet gehören auch die Entwicklung und Optimierung von Prozessen. Prozess-Owner Prozess-Owner sind für den Prozess im laufenden Betrieb verantwortlich und sind die ersten Ansprechpartner für Fragen zum Prozess oder bei Störungen. Prozess-Controller Dieser ist verantwortlich dafür, dass der Prozess im betrieblichen Durchlauf den geforderten Output in der gewünschten Qualität (Zeit, Kosten) liefert.

47

4

Architektensicht: Prozesse übersichtlich strukturieren Prozess-Anwender Diese Personengruppe ist für die Ausführung von Tätigkeiten im Rahmen eines Geschäftsprozesses voll- oder teilverantwortlich. Diese Rolle kann ein betriebseigener Mitarbeiter oder auch ein externer Dienstleister einnehmen. Prozess-Implementierer Implementierer bilden die Anforderungen von Prozessen auf ITSysteme ab. Dazu gehören Software-Entwickler, die Anpassungen vornehmen, und der IT-Service, der die Lauffähigkeit der verbundenen Systeme garantiert. Die Auswirkungen auf notwendige Anpassungen der Aufbau- und Ablauforganisation müssen ebenfalls unterstützt werden.

Unterschiedliche Rollen

Es ist verständlich, dass jede Rolle eine andere Sicht auf den Prozess erforderlich macht. Für Führungskräfte reicht oft ein Prozessüberblick, wogegen die am Prozess direkt Beteiligten und die Software-Entwicklung eine detaillierte Prozessbeschreibung brauchen. Die Zielsetzungen der verschiedenen Rollen sind bezüglich Kosten, Qualität und Zeit teilweise divergent. Bezogen auf das Fünf-Ebenen-Modell (siehe Kapitel 2) können die Rollen den fünf Ebenen zugeordnet werden: Tabelle 2: Fünf Ebenen und Rollenzuordnung Zielsetzung und Strategie

Prozess-Sponsor

Architektur und Planung

Prozess-Manager

Modell und Beschreibung

Prozess-Owner

Test und Plausibilisierung

Prozess-Anwender und Prozess-Controller

Implementierung und

Prozess-Implementierer,

Anwendung

Prozess-Anwender und Prozess-Kunde

48

4.2

Architekturkriterien

Durchgängigkeit Produkte und Dienstleistungen durchlaufen einen spezifischen Lebenszyklus.

Der abgebildete Kosten-/Nutzenverlauf ist beispielhaft und typisch für viele Produktlebenskurven. Für Geschäftsprozesse gilt diese Charakteristik ebenso [Sc98]. Eine Prozessarchitektur muss durchgängige Methoden zur Unterstützung aller Lebensphasen eines Prozesses zur Verfügung stellen.

Flexibilität „Nichts ist stetiger als der Wandel“. Geschäftsprozesse müssen in jeder Lebensphase änderbar und anpassbar sein, besonders wenn es sich um einen changesensitiven Prozess handelt (siehe Kapitel 3). Eine besondere Anforderung an die Prozessarchitektur ist, dass die Prozessbeteiligten in ihrer jeweiligen Sichtweise Änderungen sehr frühzeitig „erleben“ können. Für die Prozess-Owner ist die frühzeitige Abschätzung von Kosten und Risiken einer Prozessänderung eine wesentliche Entscheidungsgrundlage. Für die Prozess-Anwender spielen die praktische Relevanz der Prozessänderung und die Benutzerfreundlichkeit eine große Rolle.

49

4

Architektensicht: Prozesse übersichtlich strukturieren

4.3

Flussorientierte Architekturkriterien

Grundprinzip: Funktionen und Aufgaben

Beim flussorientierten Ansatz stehen Aufgaben bzw. Funktionen und ihre Bearbeitungsfolgen im Mittelpunkt der Darstellung und Beschreibung von Geschäftsprozessen. Zur Modellierung haben sich Prozessketten (beispielsweise EPK, als Ereignisgesteuerte Prozesskette, siehe [Se02]) etabliert.

Beispiel

Ändern eines Kundenauftrages (flussorientierte Sicht) Folgende Daten stehen auf dem Beleg eines "Kundenauftrags": ·

Auftragsnummer: 2341

·

Auftraggeber: Firma Meier GmbH

·

Produkt: Schrauben M5

·

Menge: 100.000 Stück

·

etc.

Der Kunde möchte die Stückzahl auf 150.000 erhöhen. Es ist eine Funktion (Prozessschritt) erforderlich, welche diese Änderung an den Daten dieses Kundenauftrags zulässt und realisiert. Diese Vorgehensweise entspricht einem Prozessschritt im Rahmen einer flussorientierten Geschäftsprozessabwicklung.

Prozessketten

50

Das flussorientierte Architekturprinzip basiert auf dem Grundprinzip der Sequenz. Die Aufgaben werden nacheinander abgearbeitet. Eine Prozesslandschaft kann aus mehreren Prozessketten bestehen (siehe Abbildung 24).

4.3

Information an Prozessketten

Flussorientierte Architekturkriterien

Die Funktionalität von Prozessketten kann mit weiteren Angaben ergänzt werden. Dazu zählen beispielsweise x

Daten, Informationen, Belege

x

Organisationselemente, Stellen, Rollen

x

IT-Systeme und Werkzeuge.

Vor allem bei wissensintensiven Prozessen (siehe Kapitel 3) spielt dies eine wesentliche Rolle. Abbildung 25 zeigt hierzu ein Beispiel. Der Prozessschritt „Störungs-Meldung annehmen“ wird von der Organisationseinheit „Servicedesk“ ausgeführt und von einem „Ticketverwaltungssystem“ unterstützt.

Prozesshierarchie

Im ersten Kapitel wurde gezeigt, dass Prozesse hierarchisch strukturiert werden können. Flussorientierte Prozessketten können weiter detailliert werden. Ein Sequenzschritt kann in weitere Unterprozessketten zerlegt werden. Abbildung 26 zeigt die Verfeinerung des Prozesses „Angebot abstimmen und anpassen“ durch die Teilprozesse „Kalkulieren“ und „Freigeben“. 51

4

Architektensicht: Prozesse übersichtlich strukturieren

Prozesslogik

Durch die Verwendung von logischen Operatoren (UND, ODER, exclusives ODER) können in Sequenzen x synchrone Parallelität (z.B. gleichzeitige Kundenauftragsbearbeitung und Bonitätsprüfung), x Auswahl (z.B. Annahme oder Ablehnung eines Angebotes) und x Wiederholungen (z.B. Wareneingangsbuchungen) abgebildet werden.

In Abbildung 27 wird das flussorientierte Prozessmodell eines „Urlaubsantrags“ gezeigt. Die Prozesslogik von sich gegenseitig

52

4.3

Flussorientierte Architekturkriterien

ausschliessenden Prozessschritten wird beispielsweise durch ein „exklusives ODER„ (XOR) dargestellt (siehe [Se02]). Bewertung

Im Mittelpunkt der Betrachtung von betrieblichen Geschäftsprozessen stehen in der Praxis häufig flussorientierte Prozessmodelle. Diese übernehmen die primäre Rolle bei der Darstellung, Gestaltung und Realisierung von Geschäftsprozessen. Akteure und unterstützende (IT-)Systeme nehmen eine nachgeordnete Rolle ein. Diese Art der Betrachtung berücksichtigt insbesondere das Interesse des Managements nach einer einfachen und übersichtlichen Darstellung von Geschäftsprozessen. Die grobe Einordnung eines Prozesses in die betriebliche Umgebung und die Zusammenhänge zu IT-Systemen sind übersichtlich darstellbar. Die Flussorientierung der Prozesse erschwert es jedoch, Ereignisse, die nach dem Prozessstart auftreten, in den Prozessablauf zu integrieren. Es ist aus einer Prozesskette nicht ersichtlich, was passiert, wenn sich ein „Kundenauftrag“ bereits im Prozess „Produkt liefern“ befindet und der Kunde seine „Bestellung ändern“ bzw. „stornieren“ möchte. Es kann durchaus im Rahmen der Strategie festgelegt worden sein, dass ein Kunde seine Bestellung bis kurz vor der Auslieferung ändern können soll. Ein Kunde wünscht statt dem bestellten grünen Auto ein blaues, und der Automobilhersteller sieht es als Wettbewerbsfaktor an, diesen Wunsch kurzfristig realisieren zu können.

Grenzen des flussorientierten Architekturprinzips

Die flussorientierte Beschreibungsform hat Grenzen. Es besteht keine Möglichkeit zur Beschreibung paralleler Prozesse, welche sich synchronisieren müssen. Das bedeutet, bestimmte Tätigkeiten werden erst dann ausgeführt werden, wenn in einem anderen parallelen Prozess bestimmte Aktionen bereits erledigt worden sind. Prozess- oder Wertschöpfungsketten erlauben eine eingeschränkte Darstellung asynchroner Prozesszusammenhänge. Im betrieblichen Alltag finden sich jedoch zahlreiche Beispiele asynchroner Prozessanforderungen. Es handelt sich dabei um sogenannte „Sonderfälle“, welche während des „normalen“ Prozessablaufes auftreten und berücksichtigt werden müssen, beispielsweise Änderungen im Entwicklungsprozess eines Produktes. In der Geschäftsprozessmodellierung werden solche „ungeplanten Ereignisse“ häufig vernachlässigt oder bleiben unberücksichtigt.

53

4

Architektensicht: Prozesse übersichtlich strukturieren

4.4

Objektorientierte Architekturkriterien

Grundprinzip: Objekte und Methoden

Beim objektorientierten Ansatz stehen betriebliche Objekte (Produkte und Dienstleitungen) im Mittelpunkt der Konzeption und Darstellung von Geschäftsprozessen. Ein Prozess wird als Verrichtung von Tätigkeiten an Objekten mittels Methoden beschrieben. Eigenschaften der Objekte werden gelesen oder durch Anwendung geeigneter Methoden verändert. Diese übernehmen die primäre Rolle bei der Darstellung, Gestaltung und Realisierung von Geschäftsprozessen. Akteure und Datenelemente (Eigenschaften bzw. Zustände der Objekte) nehmen eine unterstützende Rolle ein. Die Änderungen an Objekten entspricht bei Standard-Prozessen der betrieblichen Realität [Oe03].

Beispiel

Ändern eines Kundenauftrages (objektorientierte Sicht) Ein bestimmter "Kundenauftrag" hat beispielsweise die Eigenschaften: ·

Auftragsnummer: 2341

·

Auftraggeber: Firma Meier GmbH

·

Produkt: Schrauben M5

·

Menge: 100.000 Stück

·

etc.

Der Kunde möchte die Stückzahl auf 150.000 erhöhen. Es ist eine Methode erforderlich, welche diese Änderung am gewählten Objekt (Kundenauftrag) zulässt und durchführt. Prozessketten

54

Abbildung 28 stellt einen Ausschnitt der „objektorientierten“ Prozesskette „Zeitnachweis erfassen“ dar. Dabei werden verschiedene Methoden (beispielsweise „erfasse()“ oder „wähleProjekt()“) auf bestimmte Objekte (beispielsweise Zeitnachweis oder Projekt) angewandt. Das Beispiel zeigt eine Sequenz von Methoden. Die Methode „wähleMitarb()“ wird beispielsweise auf ein Objekt „Personal“ angewandt und bedeutet fachlich das „Auswählen einer bestimmten Person aus der Personaltabelle“.

4.4

Objektorientierte Architekturkriterien

Prozesslogik

Auch im objektorientierten Ansatz ist die Abbildung von Sequenzen (wie auch bei der Flussorientierung, siehe Abschnitt 4.3) möglich. Methoden laufen sequentiell und bilden auf diese Weise die Prozesslogik ab. Synchronisationsbedingungen mehrerer paralleler Aktivitäten werden durch spezielle Methoden beschrieben. Ergänzungen und Hierarchisierung sind in objektorientierten Prozessbeschreibungen ebenso nutzbar, durch Verwendung von Methoden sogar noch eleganter darstellbar.

Bewertung

Parallelität und Nebenläufigkeit bei objektorientierten Geschäftsprozessen kann durch Aktivitäts- und Interaktionsdiagramme repräsentiert werden. Diese können mit speziellen Diagrammtypen der Modellierungssprache UML (Unified Modelling Language) beschrieben werden. Zustandsdiagramme realisieren die Reaktion auf externe Ereignisse (Akteure). In der Praxis der Geschäftsprozessmodellierung hat der objektorientierte Ansatz bislang keine große Bedeutung erlangt [Oe03]. Zur Gewährleistung der Durchgängigkeit, von der fachlichen Beschreibung bis zur Software-Realisierung bietet die objektorientierte Prozessarchitektur jedoch Vorteile gegenüber dem flussorientierten Ansatz.

55

4

Architektensicht: Prozesse übersichtlich strukturieren Der flussorientierte Architekturansatz hat bei der fachlichen Beschreibung von Geschäftsprozessen Vorteile, der objektorientierte Ansatz bietet bessere Unterstützungsmöglichkeiten in der Software-Modellierung und -Realisierung.

Grenzen der objektorientierten Methode

Sowohl die flussorientierte als auch die objektorientierte ProzessArchitektur bieten keine ausreichende Möglichkeit zur Beschreibung paralleler Prozesse, welche sich synchronisieren müssen. Es handelt sich um Tätigkeiten, welche erst ausgeführt werden können, wenn in einem anderen parallelen Prozess bestimmte Aktionen bereits erledigt sind. Diese wichtige Anforderung ist bei der Modellierung und Realisierung von Automatisierungs- und Betriebssystemen seit vielen Jahren integraler Bestandteil. Im Bereich der Geschäftsprozessmodellierung ist diese Anforderung bisher kaum berücksichtigt. Das Architekturprinzip in Abschnitt 4.5 führt die Vorteile des fluss- und objektorientierten Ansatzes zusammen.

4.5

Asynchrone Architekturkriterien

Grundprinzip: ProzessKommunikation

Dieser Architekturansatz stellt die Prozessbeteiligten und deren Kommunikationsverhalten in den Mittelpunkt der Betrachtung. Im Rahmen eines Prozesses sendet ein Prozessbeteiligter Nachrichten an andere Prozessbeteiligte, empfängt Nachrichten von anderen oder führt eigene Arbeiten aus. Die Kommunikation der am Prozess Beteiligten kennzeichnet das asynchrone Architekturprinzip [Fl94] und entspricht dem Verhalten der Kommunikationspartner. Zur Veranschaulichung dient das nachfolgende Beispiel. Der Geschäftsprozess „Kundenauftrag ändern“ wird aus der Sicht der Beteiligten beschrieben.

Beispiel

56

Ein bestimmter "Kundenauftrag" hat die Eigenschaften: ·

Auftragsnummer: 2341

·

Auftraggeber: Firma Meier GmbH

·

Produkt: Schrauben M5

·

Menge: 100.000 Stück

·

etc.

4.5

Asynchrone Architekturkriterien

Der Kunde möchte die Stückzahl auf 150.000 erhöhen. Der Kunde nimmt Kontakt mit dem Verkäufer auf (Prozessanstoß) und tritt in Interaktion (Kommunikation). Der Geschäftsprozess wird durch eine Folge von synchronen (quasi zeitgleichen) und asynchronen (zeitversetzten) Kommunikationsschritten beschrieben. Dieses Architekturprinzip wird in Abbildung 29 dargestellt und nachfolgend erläutert.

Ein „Kunde“ sendet die Nachrichten „Anforderung Kundenauftrag ändern“, „Änderungswunsch“ und „Kunde bedankt sich“ an einen Verkäufer. Dieser sendet die Nachrichten „Bestätigung der Machbarkeit“ und „Bestätigung der Änderung“ an einen „Käufer“. Die möglichen Reihenfolgen, in der die Nachrichten gesendet, empfangen und bearbeitet werden, definieren das Verhalten der Beteiligten.

57

4

Architektensicht: Prozesse übersichtlich strukturieren Prozesse können in der Praxis folgende Beziehungen haben:

ArchitekturTypen

x

Sequentieller Prozess: Unmittelbar vor Abschluss eines Prozesses wird der Nachfolgeprozess gestartet. Das entspricht dem flussorientierten Architekturprinzip (siehe Kapitel 4.3).

Beispiel

Nach Abschluss einer Kundenauftragsänderung wünscht der Kunde eine Preisauskunft. x

Abhängiger Prozess (asynchron, wartend): Ein Prozess startet einen weiteren Prozess, welcher asynchron abläuft. Dieser wird beendet, bevor der initiierende Prozess terminiert. Der initiierende Prozess delegiert Teilaufgaben an einen Prozess und möchte am Ende dieses Prozesses ein Ergebnisse erhalten.

Beispiel

Während der Durchführung einer Kundenauftragsänderung wird eine Preisauskunft eingeholt. Spätestens mit Abschluss der Kundenauftragsänderung wird diese dem Kunden mitgeteilt. x

Unabhängiger Prozess (asynchron): Der initiierende und der initiierte Prozess laufen unabhängig voneinander ab. Zur Synchronisation können diese kommunizieren.

Beispiel

Während der Durchführung einer Kundenauftragsänderung wird eine Preisauskunft angefordert. Rückfragen an den Verkäufer sind möglich. Die Preisauskunft wird dem Kunden unabhängig von der Fertigstellung der Kundenauftragsänderung mitgeteilt. x

Interaktiver Prozess (asynchron, interagierend): Zwei unabhängig ablaufende Prozesse synchronisieren ihre Abläufe.

Beispiel

58

Aufgrund der laufenden Kundenauftragsänderung (zum Beispiel Erhöhung der Stückzahl) können verbesserte Konditionen zur Preisauskunft herangezogen werden.

4.5 Prozesslogik

Asynchrone Architekturkriterien

Die Prozesslogik des asynchronen Architekturansatzes wird durch das Verhalten der Prozessbeteiligten beschrieben. Es werden sequentielle (flussorientierte) Instrumente mit Synchronisationsmechanismen verwendet. Zur Abbildung von Parallelität, Auswahl und Wiederholungen werden logische Operatoren (UND, ODER, exklusives ODER) genutzt. Synchrone und asynchrone Prozessanforderungen werden durch unterschiedliche Formen der Interaktion beschrieben. Ergänzungen der Beschreibungen (refinements) und Hierarchisierung sind in asynchronen Prozessbeschreibungen möglich.

Funktionen und Objekte

Der asynchrone Architekturansatz nutzt die Stärken der flussorientierten (Grundprinzip: Funktionen) und objektorientierten (Grundprinzip: Objekte) Architekturprinzipien. Ein Geschäftsprozess wird durch interagierende Kommunikationspartner bestimmt. Die Prozessbeteiligten kapseln das eigene Prozessverhalten. Das ist eine der Stärken des objektorientierten Ansatzes. Das Prozessverhalten selbst wird mit flussorientierten Mitteln beschrieben.

Bewertung

In der asynchronen Prozess-Architektur sind Ergänzungen und Erweiterungen definierbar. Die frühzeitige Überprüfung des Prozesses und das Qualitätsmanagement sind integraler Bestandteil, und bereits bei der Planung von Änderungen möglich. Die Beschreibung „ungeplanter Ereignisse“ (beispielsweise Störungen im Normalablauf, Retouren, etc.) und die Rückverfolgung von Prozessaktivitäten sind möglich.

Kritische Würdigung

Im Mittelpunkt der Betrachtung von betrieblichen Geschäftsprozessen stehen kommunizierende Prozesse mit aktiven Prozessbeteiligten. Akteure (Prozessbeteiligte) übernehmen die primäre Rolle bei der Darstellung, Gestaltung und Realisierung von Geschäftsprozessen. Das Verhalten der Akteure bestimmt die Kommunikationsmöglichkeiten und somit die Art und Weise der damit realisierten Geschäftsprozesse. Akteure benutzen Objekte. Objekte nehmen eine passive (unterstützende) Rolle ein. Die Änderungen an Objekten entsprechen der betrieblichen Realität. Parallelität und Nebenläufigkeit bei Geschäftsprozessen werden durch kommunizierende Prozesse realisiert. Es werden Prozessmodelle definiert, welche im nächsten Kapitel ausführlich dargestellt werden. 59

4

Architektensicht: Prozesse übersichtlich strukturieren In der Prozess-Datenverarbeitung (Automatisierung) nutzt man das asynchrone Architekturprinzip schon lange Zeit. Darunter wird eine asynchrone Kommunikation von Prozess-Instanzen, zum Zweck einer gezielten und fachlich notwendigen Manipulation von Objekten (Anlegen, Ändern, Lesen und Löschen) verstanden. In diesem Architekturansatz fließen sowohl flussorientierte (synchrone) als auch objektorientierte Aspekte zur Definition und Realisierung von Automatisierungsprozessen ein.

4.6

Zusammenfassung Die drei behandelten Architekturprinzipien werden gegenübergestellt und abschließend anhand von Kriterien auf ihre Praxistauglichkeit bewertet. Die Zusammenfassung der Ergebnisse zeigt die folgende Tabelle. Die Bewertungen geben eine grobe Richtung an und basieren auf den langjährigen Praxiserfahrungen der Autoren. Tabelle 3: Vergleich der Architekturmodelle flussorientiert

objektorientiert

asynchron

Strukturierung

+

+

+

Verständlichkeit

++

+

++

Durchgängigkeit

-

+

++

Flexibilität

-

+

+

Legende

60

++

ziemlich gut

O

neutral

-

weniger gut

+

eher gut

--

eher schlecht

4.7

4.7

Aufgaben zur Prozessarchitektur (Teil 2)

Aufgaben zur Prozessarchitektur (Teil 2) Checkliste: x

Welche Architekturkriterien sind zur übersichtlichen Strukturierung Ihrer Prozesse relevant ?

x

Welches Architekturprinzip ist für Ihre Anforderungen am besten geeignet ?

x

Skizzieren Sie auf Basis des „flussorientierten Architekturprinzips“ die weitere Vorgehensweise!

x

Gehen Sie auf die verschiedenen Architekturkriterien ein!

) Hinweise zur Lösung dieses Gestaltungsschrittes finden Sie im Abschnitt 8.2.

.

61

5 Geschäftsprozesse sind real!

Fokus Mensch: Prozesse gekonnt beschreiben Eine der wichtigsten Herausforderungen bei der Beschreibung von Geschäftsprozessen ist es, betriebliche Abläufe für alle Beteiligten nachvollziehbar und transparent zu machen. Schließlich werden die Prozesse nicht von Maschinen, sondern von Menschen bearbeitet. Gute Verständlichkeit der Beschreibungen ist deshalb das oberste Gebot, wenn man neue Prozesse erfolgreich einführen oder bestehende Prozesse effektiv verändern will. Daher muss der Mensch im Mittelpunkt der zu beschreibenden Geschäftsprozesse stehen. Dies gilt besonders dann, wenn der angestrebte Automatisierungsgrad und die Komplexität der Prozesse hoch sind. In diesem Kapitel werden wir zunächst einige Kriterien aufstellen, die es ermöglichen, die Qualität einer Prozessbeschreibung zu beurteilen. Anschließend werden unterschiedliche Beschreibungsformen für Geschäftsprozesse erläutert, welche sich in der Praxis bewährt haben (siehe [Mi02]). Anhand der Kriterien werden wir diese Beschreibungsformen schließlich bewerten.

5.1

Kriterien zur Prozessbeschreibung Erlernbarkeit und Verständlichkeit Die Erlernbarkeit von Prozessbeschreibungen hängt von der Kenntnis der verwendeten Sprache (Syntax und Semantik) und des Anwendungsbereiches (Pragmatik) ab. Die verschiedenen Interessensgruppen sollten eine gemeinsame Beschreibungssprache nutzen, die für alle Beteiligten verständlich ist.

Genauigkeit und Korrektheit Voraussetzung für die Anforderungen zur Genauigkeit rektheit ist eine formale Notation und die Präzision der bungssprache. Beschreibungsformen, welche von den denen Interessensgruppen unterschiedlich interpretiert

und KorBeschreiverschieund ver63

5

Fokus Mensch: Prozesse gekonnt beschreiben standen werden können, sind ungeeignet. Auf der anderen Seite erschwert starker Formalismus die Akzeptanz der ProzessAnwender.

Statische und dynamische Aspekte Es müssen sowohl statische als auch dynamische Aspekte von Prozessen beschrieben werden können. Die wesentliche Voraussetzung besteht in der Identifikation von Bestandteilen und Elementen einer Prozessaufbaubeschreibung (statisch) und der Konstruktion von zeit- und zielorientierten Prozessablaufbeschreibungen (dynamisch).

Komplexität und Abstraktion Prozesse müssen auf unterschiedlichen Detaillierungsebenen darstellbar sein (Überblick und Detail). Zwischen den verschiedenen Darstellungsebenen sind definierte Übergänge notwendig. Verallgemeinerungen (Generalisierung) und Detaillierung (Spezialisierung) von Prozessbeschreibungen müssen schlüssig nachvollzogen sein.

5.2

Textuell-informelle Prozessbeschreibungen Textuell-informelle Prozessbeschreibungen werden in der betrieblichen Praxis häufig genutzt. Stellenbeschreibungen, Arbeitsanweisungen und Dokumentationen für die Anpassung und Änderung von Geschäftsprozessen liegen oft in dieser Form vor.

Beispiel: Ein Krankenhausprozess

64

Information der Patienten durch das Pflegepersonal des Krankenhauses Das Pflegepersonal des Krankenhauses nimmt mit der Pflegeanamnese die Sozialanamnese innerhalb von 24 Stunden nach Aufnahme der Patienten auf. Dabei wird der Bedarf einer Versorgung durch einen ambulanten Pflegedienst festgestellt. Die Daten werden direkt in ein EDVSystem eingegeben. Die Patienten werden über das Angebot eines kostenlosen Informationsgespräches durch die ambulanten Pflegedienste informiert. Bei Interesse an einem Informationsgespräch klärt das Pflegepersonal des Krankenhauses, ob Angehörige einbezogen werden sollen. Der behandelnde Arzt bzw. die behandelnde Ärztin wird bei festgestelltem

5.2

Textuell-informelle Prozessbeschreibungen

Bedarf informiert. Die Information über den weiteren Verlauf erfolgt über die Patienten-Akte. Wird der Bedarf eines ambulanten Pflegedienstes erst im Laufe des Krankenhaus-Aufenthaltes festgestellt, wird das Angebot eines Informationsgespräches von dem Pflegepersonal des Krankenhauses zum frühest möglichen Zeitpunkt gemacht.  Wünscht der Patient einen anderen als die kooperierenden ambulanten Pflegedienste, wird der Sozialdienst eingeschaltet.  Sollte der Bedarf bestehen, der Patient nimmt aber mehrfach das Informationsangebot nicht an, wird der Sozialdienst über den verantwortlichen Stationsarzt eingeschaltet. Information des ambulanten Pflegedienstes usw. Informationsgespräch usw. Pflegeüberleitung usw. In diesem Beispiel wird eine typische Arbeitsanweisungen in einem Krankenhaus beschrieben. Auch das ist eine Geschäftsprozessbeschreibung. Bewertung der Praxisrelevanz Erlernbarkeit und Verständlichkeit

In der beispielhaften Prozessbeschreibung (siehe Krankenhausprozess) sind Kenntnisse der deutschen Sprache und des Anwendungsbereiches „Krankenhaus“ erforderlich. Dem fachlichen Laien werden die Begriffe „Pflegeanamnese“ und „Sozialanamnese“ nicht geläufig sein, darunter leidet die Verständlichkeit für fachfremde Beteiligte. Lange Texte sind schwer zu überblicken und zur Optimierung, Validierung und Realisierung von Geschäftsprozessen nicht geeignet. Für den Fachanwender ist die textuell-informelle Prozessbeschreibung jedoch häufig die einzig bekannte und praktizierte Beschreibungsform für Geschäftsprozesse.

Genauigkeit und Korrektheit

Textuell-informelle Prozessbeschreibungen sind oft ungenau. Die beispielhafte Prozessbeschreibung ist nur für den Ersteller der

65

5

Fokus Mensch: Prozesse gekonnt beschreiben Beschreibung exakt. Die Korrektheit unterliegt der subjektiven Einschätzung und hat große Interpretations-Spielräume.

Statische und dynamische Aspekte

Die textuell-informelle Prozessbeschreibung lässt zwar statische und dynamische Aspekte einer Prozessbeschreibung erkennen. Überblick und Struktur sind jedoch schwer nachvollziehbar. Die sequentielle Art der Beschreibung lässt eine eingeschränkte Vorstellung für die dynamischen Aspekte des beschriebenen Prozesses zu.

Komplexität und Abstraktion

In einer textuell-informellen Prozessbeschreibung lassen sich unterschiedliche Sichten nur schwer beschreiben. Der Übergang zwischen verschiedenen Beschreibungsebenen (Abstraktion) wird textuell-informell nicht erreicht.

Einsatz in der Praxis

Trotz der beschriebenen Probleme werden textuell-informelle Beschreibungsformen für Geschäftsprozesse von ProzessAnwendern zur Prozessbeschreibung bevorzugt eingesetzt.

5.3

Strukturierte Prozessbeschreibungen Strukturierte Prozessbeschreibungen werden in der betrieblichen Praxis meistens in Form von Prozesstabellen dargestellt. Diese Beschreibungsform ist aus dem Bereich der „Betriebssysteme“ bekannt. Abbildung 31 zeigt ein Beispiel einer tabellarischen Prozessbeschreibung, strukturiert nach dem Prinzip „Eingabe-VerarbeitungAusgabe“. Für den Prozess „Steuerung Produktstammdaten“ werden alle relevanten Vorgaben (Input) angegeben. Die Tabelle ordnet den einzelnen Prozessschritten jeweils die Verantwortlichen, die benötigten Dokumente und Tools und das erwartete Ergebnis (Output) zu.

66

5.3

Strukturierte Prozessbeschreibungen

67

5

Fokus Mensch: Prozesse gekonnt beschreiben Bewertung der Praxisrelevanz Nachfolgend werden Anforderungen an strukturierte Prozessbeschreibungen beleuchtet und bewertet:

Erlernbarkeit und Verständlichkeit

Die strukturierte Prozessbeschreibung ist intuitiv verständlich. Sie setzt Grundfertigkeiten zum Lesen von Tabellen voraus (Denken in Zeilen und Spalten). Aufgrund der weiten Verbreitung und Nutzung von Tabellenkalkulationsprogrammen ist diese Art der Prozessbeschreibung für alle Beteiligten gut verständlich. Allerdings lassen sich auf diese Weise nur streng sequentielle Prozessbeschreibungen darstellen.

Genauigkeit und Korrektheit

Die Zuordnung verschiedener Aspekte (beispielsweise Input, Organisation, Dokumente, Werkzeuge und Output) zur Prozessbeschreibung erfüllt die Genauigkeitsanforderungen der Fachanwender weitgehend. Ist jedoch die Beschreibung komplexer Abläufe mit Alternativen, Schleifen und Nebenläufigkeit erforderlich, dann lassen sich diese Anforderungen in Prozesstabellen nicht mehr übersichtlich darstellen. Die Korrektheit strukturierter Prozessbeschreibungen lässt sich dann nicht nachweisen.

Statische und dynamische Aspekte

Statische und dynamische Prozesssichten lassen sich in strukturierten Prozessbeschreibungen lokal gut darstellen. Die Beschreibung von Prozessschritten mit verschiedenen Aspekten kann die statischen Anforderungen gut abdecken. Dynamik kann nur in Sequenzen und einfacher Prozesslogik abgebildet werden. Diese Beschreibungsform reicht zur Vorbereitung einer Geschäftsprozess-Realisierung nicht aus.

Komplexität und Abstraktion

Die strukturierte (oft tabellarische) Beschreibung von Prozessen lässt Hierarchisierungsmechanismen zu. Zur detaillierten Beschreibung einer Prozessinstanz kann eine neue Prozesstabelle angelegt werden. Die tabellarische Form einer Prozessbeschreibung unterstützt die Abstraktion und fördert die Konzentration auf das Wesentliche.

Einsatz in der Praxis

Strukturierte Beschreibungsformen für Geschäftsprozesse werden bevorzugt von Prozess-Owner, Prozessmanagement und ProzessControlling eingesetzt.

68

5.4

5.4

Flussorientierte Prozessbeschreibungen

Flussorientierte Prozessbeschreibungen Flussorientierte Prozessbeschreibungen werden in der betrieblichen Praxis sehr häufig eingesetzt. Sehr bekannte Vertreter dieser Beschreibungsform sind x

Ereignisgesteuerte Prozessketten (EPK), siehe [Ru99] und [Se02] oder eEPK (erweiterte ereignisgesteuerte Prozessketten)

x

Programmablaufpläne (PAP), siehe [Mi02]

eEPK werden zur Modellierung von Geschäftsprozessen verwendet, PAP werden immer noch häufig in der Softwareentwicklung zur Spezifikation von Programmabläufen eingesetzt. Abbildung 32 zeigt eine Prozessbeschreibung für eine „Buchbestellung an einer Universität“. Der Prozess beginnt mit dem Ereignis „Buchbedarf ist aufgetreten“. Dann erfolgt die Bearbeitung der ersten Funktion „Buchdaten besorgen“. Es werden die benötigten Daten „Buchdaten“ und die Verantwortlichkeit „Professor“ angegeben. Das Ereignis „Buchdaten sind vorhanden“ zeigt die erfolgreiche Durchführung der Funktion „Buchdaten besorgen“ an. In der weiteren Folge werden die notwendigen Prozessschritte beschrieben, wobei neben der reinen Sequenz auch parallele („UND“) und optionale („ODER“ und „EXCLUSIVES ODER“) Schritte angegeben werden.

69

5

70

Fokus Mensch: Prozesse gekonnt beschreiben

5.4

Flussorientierte Prozessbeschreibungen

Es folgt ein Beispiel für einen PAP zur Darstellung einer verschachtelten Zählschleife (Abbildung 33). Der Prozess beginnt mit Initialisierung des Prozesses (I=1). Anschliessend wird der Zähler I laufend erhöht. Beim Zählerstand I=48 erfolgt ein Zählersprung auf I=81. Dann wird bis I=99 weitergezählt und der Prozess endet. Diese Prozessbeschreibung erinnert an die Beschreibung von Programmabläufen, trotzdem wird sie häufig für die Darstellung von Geschäftsprozessen verwendet.

Bewertung der Praxisrelevanz Nachfolgend werden Anforderungen an flussorientierte Prozessbeschreibungen bewertet. Erlernbarkeit und Die Prozessbeschreibung des betrieblichen Praxisbeispiels (siehe Abbildung 32) ist für Prozess-Verantwortliche (Prozess-Owner) Verständlichkeit intuitiv verständlich und nachvollziehbar. Das ist auch ein wich71

5

Fokus Mensch: Prozesse gekonnt beschreiben tiger Grund für die Beliebtheit dieser Beschreibungsmethode in Unternehmen. Der Überblick über den Gesamtprozess kann sehr gut visualisiert werden. Falls an einem Geschäftsprozess jedoch unterschiedliche Nutzer eventuell aus unterschiedlichen Unternehmensbereichen beteiligt sind, verliert diese Beschreibungsform an praktischer Relevanz. Das Nachvollziehen einer individuellen Rolle ist nicht mehr zusammenhängend darstellbar. Die Prozessbeschreibung in Abbildung 33 (PAP) wird von Prozess-Implementierern geschätzt, da in dieser Beschreibungsform eine große Nähe zur Realisierung erkennbar ist.

Genauigkeit und Korrektheit

Statische und dynamische Aspekte

Die Darstellung eines Prozess-Überblicks mit Programmablaufplänen (PAP) und ereignisgesteuerte Prozessketten (EPK) kann hinreichend genau dargestellt werden. Die Korrektheit der Prozessbeschreibung kann auf Basis von Regeln (Syntax) auch programmgesteuert nachgewiesen werden. Die fachliche Korrektheit (Semantik) muss visuell durch den Prozess-Owner festgestellt werden. Der einzelne Prozess-Anwender kann nur bedingt die fachliche Korrektheit bestätigen. Durch Ergänzung weiterer Prozessaspekte (wie beispielsweise Input, Organisation, Dokumente, Werkzeuge und Output) kann der Prozess noch genauer beschrieben werden. Eine Vielzahl von Beschreibungsvarianten, wie beispielsweise x

Funktionsbaum

x

Organigramm

x

Datenmodell

unterstützen die Darstellung statischer Aspekte einer Prozessbeschreibung. Die Bestandteile eines Geschäftsprozesses können auf diese Weise übersichtlich und kompakt dokumentiert werden. Die dynamischen Aspekte einer Prozessbeschreibung werden überwiegend mit Hilfe der bereits besprochenen EPK oder PAP dargestellt. Durch Einsatz von Simulationsinstrumenten können Kennzahlen für die betrachteten Prozesse ermittelt werden. Auf diese Weise werden anhand der Prozessbeschreibung Kosten und Zeiten für den Prozess ermittelt.

72

5.5

Objektorientierte Prozessbeschreibungen

Komplexität und Abstraktion

Komplexe flussorientierte Prozessbeschreibungen können durch Hierarchisierung einfacher und übersichtlicher gestaltet werden. Weiterhin werden Prozess-Schablonen erstellt, welche den Wiederverwendungsgrad bei Prozessvarianten deutlich erhöht. Darüber hinaus existieren Referenzmodelle, beispielsweise für Standard-Anwendungssysteme wie SAP R/3, anhand derer sich Prozess-Beteiligte grob orientieren können.

Einsatz in der Praxis

Flussorientierte Beschreibungsformen für Geschäftsprozesse werden bevorzugt von Prozess-Anwendern, Prozess-Ownern und dem Prozessmanagement eingesetzt. Spezielle Formen wie beispielsweise Programmablaufpläne werden überwiegend von Prozess-Implementierern eingesetzt.

5.5

Objektorientierte Prozessbeschreibungen Objektorientierte Prozessbeschreibungen dienen in erster Linie der Beschreibung von Anforderungen und Konzepten für die objektorientierte Softwareentwicklung. Die Unterstützung von Geschäftsprozessbeschreibungen ist eher ein Nebenaspekt. Die „Unified Modeling Language“ (UML) [Ru05] stellt die führende und weit verbreitete Notation und Beschreibungsform für objektorientierte Softwaresysteme. UML bietet einen umfangreichen Katalog an Struktur- und Verhaltensbeschreibungen. Die Beschreibung von Geschäftsprozessen wird in der betrieblichen Praxis durch spezielle Diagrammformen der UML unterstützt, das sind: x

Use-Case-Diagramme

x

Sequenzdiagramme und

x

Aktivitätsdiagramme

Es ist anzumerken, dass diese Diagramm-Notationen primär auf dem flussorientierten Architekturprinzip basieren. Beispiele für einfache Use-Case-Diagramme, Sequenzdiagramme und Aktivitätsdiagramme werden im Folgenden dargestellt.

73

5

Fokus Mensch: Prozesse gekonnt beschreiben

x

Beispiel: Bearbeitung von Kopieraufträgen als Use-caseDiagramm (Ausschnitt)

Das Beispiel in Abbildung 34 zeigt eine Prozessbeschreibung für die „Bearbeitung von Kopieraufträgen“ als Use-Case-Diagramm. Es werden verschiedene Akteure (beispielsweise: Auftraggeber und Haushaltssachbearbeiter) und deren Beziehung zu den erforderlichen Anwendungsfällen dargestellt. Die Beziehungen zwischen den Anwendungsfällen können noch näher konkretisiert („extend“ oder „include“) werden. Mit Hilfe eines Sequenzdiagramms (Abbildung 35) kann der Ablauf eines Anwendungsfalles als Folge von Funktionsschritten (beispielsweise: Wertkarte beantragen) näher beschrieben werden. Es werden die verantwortlichen Akteure (Auftraggeber, Haushaltssachbearbeiter und Mitarbeiter Kopierzentrale) mit angegeben.

74

5.5 x

Objektorientierte Prozessbeschreibungen

Beispiel: Bearbeitung von Kopieraufträgen als Sequenzdiagramm (Ausschnitt)

Am häufigsten werden zur Beschreibung von Prozessen aus dem UML-Werkzeugkasten Aktivitätsdiagramme verwendet. Abbildung 36 zeigt ein Beispiel für einen einfachen Prozess definiert als Aktivitätsdiagramm. x

Beispiel: Getränkeautomat als Aktivitätsdiagramm (Ausschnitt)

75

5

Fokus Mensch: Prozesse gekonnt beschreiben Das Beispiel in Abbildung 36 zeigt eine Prozessbeschreibung für einen „Getränkeautomaten“. Es werden die verschiedenen Aktivitäten (wie „einschalten“ und „eingießen“) in der notwendigen Abfolge dargestellt. Auch Parallelität (wie „Kaffee gefunden“) und Optionen „Mineralwasser gefunden bzw. nicht gefunden“ können dargestellt werden. Start- und Endpunkte der Prozessbeschreibung werden durch Kreissymbole dargestellt. Bewertung der Praxisrelevanz Nachfolgend werden Anforderungen an objektorientierte Prozessbeschreibungen untersucht.

Erlernbarkeit und Verständlichkeit

Use-Case-Diagramme sind sehr anschaulich, jedoch in der Regel zu oberflächlich und werden von Prozess-Anwendern oft nicht akzeptiert. Für Prozess-Verantwortliche dienen Sie als Überblick, um die Beteiligten (Akteure) den geforderten Anwendungsfällen (Geschäftsprozesse) zuzuordnen. Sequenzdiagramme stellen den Kommunikationsbedarf zwischen den beteiligten Akteuren in einem Geschäftsprozess dar. Für die Prozess-Anwender (Akteure) ist diese Beschreibungsform aussagekräftig. In der Praxis ist für diese Beschreibungsform die Akzeptanz im Fachbereich sehr gering. Sequenzdiagramme sind für die Prozess-Anwender eher nicht geeignet. Aktivitätsdiagramme visualisieren den Ablauf eines Geschäftsprozesses und sind flussorientierten Beschreibungsformen (beispielsweise EPK) sehr ähnlich.

Genauigkeit und Korrektheit

Die UML basiert auf einer definierten Syntax. Objektorientierte Prozessbeschreibungen können deshalb auf syntaktische Korrektheit überprüft werden. Der Nachweis der fachlichen Korrektheit (Semantik) ist aufgrund der Vielzahl unterschiedlicher Beschreibungsformen (Modellarten) schwer nachzuweisen. Insbesondere Prozess-Anwender sind mit der Interpretation objektorientierter Beschreibungsformen überfordert. Die Einfachheit von Use-Case-Modellen wird aufgrund der inhaltlichen Oberflächlichkeit und Ungenauigkeit von Prozess-Anwendern nach Erfahrung der Autoren oft nicht akzeptiert.

76

5.5 Statische und dynamische Aspekte

Objektorientierte Prozessbeschreibungen

UML bietet mehrere Struktur- und Verhaltensmodelle an. Statische Aspekte (Struktur) einer Prozessbeschreibung können mit folgenden Diagrammarten beschrieben werden: x

Objektdiagramme

x

Klassendiagramme

x

Paketdiagramme

x

Kompositionsstrukturdiagramme

x

Komponentendiagramme

x

Verteilungsdiagramme

Beschreibungsformen für dynamische Aspekte (Verhalten) sind: x

Use-Case-Diagramme

x

Aktivitätsdiagramme

x

Sequenzdiagramme

x

Zustandsautomaten

x

Kommunikationsdiagramme

x

Timing-Diagramme

x

Interaktionsübersichtsdiagramme

Für einen detaillierten Einblick in die Beschreibungsformen der UML sei die einschlägige Fachliteratur empfohlen [Ru05]. UML bietet ein umfangreiches Beschreibungs-Instrumentarium. In der Praxis zeigt sich diese Vielfalt als Nachteil in der Anwendungs-Akzeptanz. Zahlreiche Beziehungen zwischen den unterschiedlichen Beschreibungsformen sind für viele ProzessBeteiligte nicht nachvollziehbar. Insbesondere die dynamischen Aspekte können nicht eingeschätzt und erlebt werden. ProzessAnwender und Prozess-Owner werden dadurch schnell überfordert. Prozess-Implementierer setzen objektorientierte Beschreibungen (statisch und dynamisch) zur Vorbereitung der „Programmierung von Geschäftsprozessen ein. Komplexität und Abstraktion

Die objektorientierten Beschreibungsformen basieren auf den Grundprinzipien von Wiederverwendbarkeit und Abstraktion. Für die „Software“-Architektur von Geschäftsprozessen sind diese Prinzipien von großem Nutzen. Für den fachlich-orientierten 77

5

Fokus Mensch: Prozesse gekonnt beschreiben Prozess-Anwender oder Prozess-Owner sind diese Aspekte eher uninteressant.

Einsatz in der Praxis

Objektorientierte Beschreibungsformen für Geschäftsprozesse werden bevorzugt von Prozess-Implementierern und ProzessOwnern eingesetzt.

5.6

Subjektorientierte Prozessbeschreibungen

Basis: Aktivitätsdiagramme

Bereits in den 90er Jahren wurde festgestellt [Wa98], dass die streng flussorientierte Beschreibung von Prozessen (siehe Abschnitt 5.4) an ihre Grenzen stößt und nicht immer der betrieblichen Realität entspricht. Im Rahmen der objektorientierten UML wurden zu diesem Zweck Aktivitätsdiagrammen eingeführt. Diese Beschreibungsform taucht in der Folgezeit zwar immer wieder in der Geschäftsprozessmodellierung auf, hat sich in der Praxis jedoch nicht durchgesetzt. Aktivitätsdiagramme unterstützen jedoch die Anforderungen der betrieblichen Praxis an die asynchrone Prozess-Architektur. Die subjektorientierte Modellierungsmethode verwendet ganz ähnliche Konzepte zur Darstellung von Prozessen und greift auf die Eigenschaften von Aktivitätsdiagrammen zurück. Nachfolgend wird ein durchgängiges Konzept entwickelt und zur Verfügung gestellt, das sich in der Praxis eignet. Die subjektorientierte Beschreibungsform vereint die Vorteile der flussorientierten (siehe Abschnitt 5.4) mit der objektorientierten Beschreibungsform (siehe Abschnitt 5.5).

Was sind Subjekte ?

Subjekte, sind beispielsweise x

Prozessrollen (siehe 4.2)

x

Prozessbeteiligte (siehe 4.5)

x

Akteure (siehe 5.5)

und haben zentrale Eigenschaften:

78

x

sie reden miteinander (Kommunikation)

x

sie hören zu (Information)

x

sie handeln selbst (Aktion)

5.6 Beispiel

Subjektorientierte Prozessbeschreibungen

Einleitend ein praktisches Beispiel:

Abbildung 37 zeigt einen Kreditantrags-Prozess, an dem fünf Handelnde (Subjekte) beteiligt sind. Die Kommunikations- und Informationsflüsse zwischen den Subjekten werden mit Pfeilen festgelegt. Die Subjekte („Kunde“ und „Berater“) kommunizieren („beantragen“ und „beraten“) und tauschen Informationen aus. In diesem Beispiel fehlen noch Details zum Verhalten der Subjekte und deren Aktionen. Grundlagen

Modellierungssprache Bei der Beschreibung von Geschäftsprozessen aus der subjektorientierten Sicht werden die an einem Prozess Beteiligten ins Zentrum der Betrachtung gestellt. Sie sind die Handelnden d. h. die Subjekte eines Prozesses [Fl94]. In der objektorientierten Beschreibungsform spielen Prädikate (Methoden) und Objekte (Eigenschaften) die primäre Gestaltungsrolle. Wer aber initiiert, dass die durch das Verb definierte Aktion auf dem Objekt ausgeführt wird?

Was ist ein Subjekt?

Dazu wird ein aktives, handelndes Element benötigt: Ein Subjekt. In der Grammatik der subjektorientierten Prozessbeschreibung wird im Vergleich zu den objektorientierten Beschreibungen das Sprachelement „Subjekt“ ergänzt. Ein vollständiger Satz besteht aus Subjekt, Prädikat und Objekt.

79

5

Fokus Mensch: Prozesse gekonnt beschreiben

Beispiel

Ein Käufer (Subjekt) bestellt (Prädikat) einen PC (Objekt). Im Rahmen eines Prozesses sendet ein Subjekt Nachrichten an andere Subjekte, empfängt Nachrichten von anderen Subjekten oder führt interne Arbeiten aus. Abbildung 37 zeigt ein einfaches Prozess-Beispiel aus subjektorientierter Sicht. Die möglichen Reihenfolgen, in der ein Subjekt Nachrichten sendet, empfängt und bearbeitet, definieren sein Verhalten. Wie das Verhalten eines Subjekts beschrieben werden kann, wird ausführlich in der weiteren Methodenbeschreibung erläutert.

Prozesse

Eine subjektorientierte Prozessbeschreibung gibt an, welche Tätigkeiten die am Prozess Beteiligten wann ausführen müssen und welche Interaktionen (Senden und Empfangen von Nachrichten) zur Koordination der jeweiligen Tätigkeiten erforderlich sind. Jedes Subjekt definiert seinen eigenen Ablauf (Kontrollfluss), der sich über Nachrichten mit den Abläufen (Kontrollflüssen) der anderen Subjekte koordiniert und synchronisiert. Ein Subjekt kapselt die Interaktionen und Tätigkeiten, die von einer beteiligten Organisationseinheit/Person im Rahmen des betrachteten Prozesses ausgeführt werden. Ein Subjekt wird einer Organisationseinheit zugeordnet. Ein Subjekt beschreibt weiterhin, welche Aufgabe eine Organisation/Person innerhalb eines Prozesses erfüllt und welchen Beitrag diese zur Bearbeitung des auslösenden Geschäftsvorfalls leistet. Die Subjektdefinition beschreibt, wie sich Mitarbeiter der zuständigen Organisation im Rahmen eines Prozesses verhalten. Zwischen Subjekten werden Schnittstellen definiert. Sie sind eindeutig identifiziert und auf die betroffenen Subjekte bezogen. Die Beschreibungen sind unabhängig von den jeweiligen Organisationen, denen die Subjekte zugeordnet sind. Wechselt die Verantwortung für ein Subjekt, müssen die Schnittstellenbeschreibungen nicht verändert werden. Das Verhalten von Subjekten wird von dem Prozess, dem es angehört, definiert. Die Arbeitsabläufe eines Subjekts sind getrennt von der Prozessbeschreibung und werden detaillierter beschrieben. So kann beispielsweise die Erstellung eines Angebots mehrere Arbeitsschritte umfassen. Die Reihenfolge dieser Arbeitsschritte kann mit einer flussorientierte Beschreibungsformen [Sc02] festgelegt werden.

80

5.6

Subjektorientierte Prozessbeschreibungen

Modellierungsmethode Die subjektorientierte Beschreibung von Prozessen erfolgt auf drei Gestaltungsebenen. Ebene 1: Interaktionen der Subjekte

Auf der ersten Ebene werden die an einem Prozess beteiligten Subjekte, deren Interaktionen und Schnittstellen festgelegt. Zu den einzelnen Interaktionen wird beschrieben, welche Daten bei einer Interaktion vom sendenden zum empfangenden Subjekt übermittelt werden.

Beispiel

Ein Kunde stellt bei einer Bank eine Kreditanfrage. Diese wird vom Beratungs-Desk entgegen genommen und von einem Kreditsachbearbeiter geprüft. Die Freigabe oder Ablehnung erfolgt durch den Leiter der Kreditabteilung. Die Entscheidung wird dem Kunden anschließend mitgeteilt. Abbildung 38 zeigt hierzu ein Diagramm , das die Interaktionen der beteiligten Subjekte darstellt.

Ebene 2: Verhalten der Subjekte

Auf der zweiten Ebene wird das Verhalten der einzelnen Subjekte festgelegt. Es wird beschrieben, in welcher Reihenfolge ein Subjekt welche Interaktionen oder Tätigkeiten ausführt. Es werden Teile der Grundlagen von UML-Aktivitätsdiagrammen [Ru05]

81

5

Fokus Mensch: Prozesse gekonnt beschreiben übernommen und in die subjektorientierte Beschreibungsform integriert. Folgende Zustandsarten sind zu unterscheiden: x

Empfangszustand

x

Funktionszustand

x

Sendezustand

Jeder Zustand kann durch Angabe von „refinements“ detaillierter beschrieben werden. Damit ist es möglich, einem Subjekt zusätzliche Ressourcen (beispielsweise Verhaltensvorschriften, externe Programme, Hilfsmittel, etc.) zuzuordnen. Beispiel

Ebene 3: Anwendung der Subjekte 82

Es wird das Verhalten der „Beratung“ exemplarisch beschrieben und in Abbildung 39 als Verhaltensmodell dargestellt. Die „Beratung“ befindet sich zunächst im Wartestatus (Empfangszustand). Sobald eine Kreditanfrage eines Kunden eingeht, führt die „Beratung“ eine Prüfung (Funktionszustand) durch. Das Ergebnis der Prüfung wird dem Kunden mitgeteilt (Sendezustand).

Auf der dritten Ebene werden einzelne Tätigkeiten (Prozessschritte) in Arbeitsabläufe aufgelöst und u.U. die auszufüllenden Formulare / Bildschirmmasken spezifiziert. Zu jedem Subjekt

5.6

Subjektorientierte Prozessbeschreibungen

können Details (refinements) angegeben werden, welche die Handlungen des Subjektes genau beschreiben. Die Realisierung dieser Details kann durch die Verwendung eigener oder fremder Software-Bausteine unterstützt werden. Die Anwendung der Subjekte spielt bei der Prozess-Validierung (siehe Kapitel 6) und Prozess-Realisierung (siehe Kapitel 7) die zentrale Rolle. Beispiel:

Die Anwendung der Subjekte „Kunde“ und „Beratung“ entspricht der Durchführung eines Geschäftsprozesses. Grundlage sind die Subjekt-Deklarationen (Kommunikation der Subjekte, Ebene 1) und die Subjekt-Definitionen (Verhalten der Subjekte, Ebene 2). Für jedes Subjekt kann ein Dialog geführt werden, sodass der beschriebene Geschäftsprozess (Kreditantragsbearbeitung) nachvollzogen und frühzeitig erlebbar gemacht werden kann.

83

5

Fokus Mensch: Prozesse gekonnt beschreiben Bewertung der Praxisrelevanz Subjektorientierte Prozessbeschreibungen stellen die am Prozess Beteiligten (Handelnden) in den Mittelpunkt. Bei der Beschreibung und Visualisierung von Geschäftsprozessen stehen folgende Aspekte im Vordergrund: x

Interaktion (Kommunikation) von Subjekten

x

Verhalten (Fähigkeiten) von Subjekten

x

Erlebbarkeit der Prozesse

Nachfolgend werden Anforderungen an subjektorientierte Prozessbeschreibungen beleuchtet und bewertet. Erlernbarkeit und Im Subjektbegriff findet sich der Prozess-Anwender schnell zurecht und identifiziert sich als Prozessbeteiligter in der jeweiligen Verständlichkeit Rolle. Das Verhalten eines Subjektes kann mit einfachen Darstellungsmitteln nachvollzogen, ergänzt oder geändert werden. Das Zusammenspiel der Subjekte (Prozess-Anwender) im Prozess ist visualisierbar. Dadurch gewinnt die Beschreibung der Geschäftsprozesse eine neue Qualität. Alle Prozess-Beteiligten können gemeinsam die Prozess-Beschreibung betrachten und begutachten. Genauigkeit und Korrektheit

Subjektorientierte Prozessmodelle basieren auf einer definierten Syntax und können deshalb rechnergestützt validiert und auf syntaktische Korrektheit überprüft werden. Das fachlich notwendige Kommunikations- und Prozessverhalten (insb. refinements) der Subjekte kann hinreichend genau beschrieben werden. Die rasche Erlebbarkeit der beschriebenen Geschäftsprozesse ermöglicht ein frühzeitiges Erkennen von „Prozessfehlern“, sodass diese unmittelbar in der Prozessbeschreibung behoben werden können.

Statische und dynamische Aspekte

84

Die subjektorientierte Prozessbeschreibung unterstützt statische und dynamische Aspekte. Auf der Beschreibungsebene 1 (Interaktionen der Subjekte) werden die beteiligten Subjekte deklariert. Die Deklaration be-

5.7

Zusammenfassung

schreibt die statischen Anforderungen an das Kommunikationsverhalten der Subjekte. Auf der Ebene 2 (Verhalten der Subjekte) findet die Definition der Subjekte statt. Es werden die dynamischen Anforderungen an die Prozessbeschreibung dargestellt. Die Ebene 3 (Anwendung, Visualisierung und Erlebbarkeit der Prozesse) kann die Prozessbeschreibung zum „Leben erweckt“ werden. Komplexität und Abstraktion

Die subjektorientierte Prozessbeschreibung verwendet die Abstraktionsmechanismen der Objektorientierung und Hierarchisierung. Dadurch kann die Komplexität „großer“ Geschäftsprozesse beherrschbar gemacht werden. Subjekte interagieren untereinander (öffentlich) und kapseln das Prozessverhalten (privat). Das Subjektverhalten wird flußorientiert beschrieben. Detaillierte Anforderungen an das Prozessverhalten werden durch „refinements“ ermöglicht und können in einer objektorientierten Notation formuliert werden.

Einsatz in der Praxis

Subjektorientierte Beschreibungsformen für Geschäftsprozesse sind von allen Prozess-Beteiligten mit frühzeitigem Erlebniswert und hoher Akzeptanz nutzbar. Prozess-Anwender identifizieren sich mit der subjektorientierten Beschreibungsform sehr schnell. Die eigene Rolle im Geschäftsprozess geht unmittelbar in die Prozessbeschreibung (Modellierung) ein. Die Möglichkeit des frühen Prozess-Erlebnisses bildet einen wichtigen Beitrag zur Prozess-Qualität. Auch Prozess-Implementierer profitieren von der syntaktisch klaren Beschreibung. Aus der subjektorientierten und erlebbaren Geschäftsprozessbeschreibung kann automatisiert Programmcode generiert werden. Dieser kann in der Softwareentwicklung weiter detailliert und optimiert werden.

5.7

Zusammenfassung In der Praxis haben sich mehrere Methoden etabliert, mit denen Prozesse beschrieben werden können. Diese Darstellungsformen reichen von „informell“ bis „stark strukturiert“, wobei unterschiedliche inhaltliche Schwerpunkte gesetzt werden. Jede Methode hat ihre spezifischen Vorzüge, jedoch sollte genau analy85

5

Fokus Mensch: Prozesse gekonnt beschreiben siert werden, ob sie den jeweiligen Anforderungen gerecht werden. Die zu Anfang dieses Kapitels aufgestellten Kriterien helfen bei der Auswahl die richtigen Beschreibungsmethode. Die Ergebnisse unserer Bewertung sind in der folgenden Tabelle dargestellt und basieren auf der langjährigen Praxiserfahrung der Autoren.

subjektorientiert

Erlernbarkeit und Verständlichkeit

o

+

++

+

+

Korrektheit und Genauigkeit

--

-

+

+

++

Statische und dynamische Aspekte

--

o

+

+

++

Komplexität und Abstraktion

--

o

+

++

+

textuellinformell

objektorientiert

flussorientiert

struktuiert

Tabelle 4: Kriterien der Beschreibungsmethoden

Legende ++

ziemlich gut

O

neutral

-

weniger gut

+

eher gut

--

eher schlecht

Von der in diesem Kapitel erläuterten Prozessbeschreibung (Ebene 3) zur konkreten Umsetzung (Ebene 5) bedarf es noch eines Zwischenschrittes. Im nächsten Kapitel werden wir darstellen, wie das Ergebnis der Beschreibung auf seine Eignung für die Praxis hin überprüft werden kann. 86

5.8

5.8

Aufgaben zur Prozess-Modellierung (Teil 3)

Aufgaben zur Prozess-Modellierung (Teil 3) Checkliste: x

Welche Kriterien zur Beschreibung der betroffenen Geschäftsprozesse sind relevant ?

x

Welche Beschreibungsmethode ist am besten geeignet ?

x

Skizzieren Sie auf Basis der „subjektorientierten Beschreibungsmethode“ die weitere Vorgehensweise!

x

Gehen Sie auf die verschiedenen Kriterien bei der ProzessModellierung ein!

) Hinweise zur Lösung dieses Gestaltungsschrittes finden Sie im Abschnitt 8.3.

87

6

Qualitätskontrolle: Prozesse auf Eignung prüfen Mit dem Entwurf eines Prozesses ist ein wichtiger Schritt in Richtung seiner Realisierung getan. Nun sollte der Entwurf auf seine Tauglichkeit in der Praxis überprüft werden. Eine sorgfältige Validierung zeigt, ob der Prozess alle Anforderungen erfüllt und die beabsichtigten Ergebnisse erreicht. Diese Qualitätskontrollen müssen möglichst frühzeitig einsetzen, bevor IT-Systeme entwickelt und die späteren Anwender geschult werden. Die Qualitätskontrolle bei Geschäftsprozessen hat zwei wesentliche Aufgaben. Sie soll die Effektivität und die Effizienz von Prozessen gewährleisten. Effektivität bedeutet, dass der Prozess die an ihn gestellten Anforderungen erfüllt. Effizient ist der Prozess dann, wenn er mit möglichst geringem finanziellen und zeitlichen Mitteleinsatz ausgeführt werden kann. Diese qualitativen und quantitativen Ziele sollten durch entsprechende Messgrößen definiert werden. Ideal ist es, wenn für einen Prozess Effektivitäts- und Effizienzkennzahlen existieren, die einen Prozess ausreichend charakterisieren und damit steuerbar machen. Im Folgenden werden Methoden vorgestellt, mit deren Hilfe die Qualität von Prozessdefinitionen bewertet werden kann. Diese Methoden ergänzen sich und sollten je nach Unternehmenssituation kombiniert eingesetzt werden. Am Ende jedes Abschnitts wird in einer Tabelle die Eignung der Qualitätsbeurteilung für Prozesse hinsichtlich der in Kapitel 5 dargestellten Beschreibungsmethoden bewertet.

6.1

Visuelle Begutachtung Bei dem Begriff „visuelle Begutachtung“ wird man sagen, das ist doch selbstverständlich, dass Dokumente mit Prozessbeschreibungen begutachtet werden, bevor sie umgesetzt werden!

Effizienz

Eine systematische Begutachtung kann in Form von Reviews erfolgen. Dabei wird die Prozessbeschreibung von Mitarbeitern, die nach diesem Prozess arbeiten sollen, beurteilt. Zur Vorberei89

6

Qualitätskontrolle: Prozesse auf Eignung prüfen tung eines Reviews wird die Prozessbeschreibung und eine Checkliste, nach der die Prozessbeschreibung geprüft werden soll, kommuniziert. Diese Checkliste enthält die Fragen, die die Gutachter bezüglich des Prozesses beantworten sollen. Beispiele für solche Fragen sind:

90

x

Sind die Ziele des Prozesses definiert ?

x

Ist der Nutzen des Prozesses in der Zielsetzung klar beschrieben und ist ersichtlich, welche Wertschöpfung er für wen liefert?

x

Gibt es Kennzahlen mit denen die Zielerreichung bewertet werden kann ?

x

Sind die Messverfahren für die Kennzahlen eindeutig festgelegt?

x

Werden die Zielwerte für die Kennzahlen des Prozesses systematisch festgelegt und liefern sie eine Aussage über den Wertbeitrag des Prozesses?

x

Unterstützt der Prozess die Politik und Strategie des Unternehmens bzw. der IT Organisationen?

x

Ist der Prozessablauf beschrieben ?

x

Sind die Eingaben und Ergebnisse des Prozesses beschrieben?

x

Ist klar, wer (Organisationen, Rollen, Personen) welche Eingaben liefert und welche Ergebnisse entgegennimmt?

x

Werden die Beschreibungskonventionen für Prozesse eingehalten ?

x

Ist klar definiert, wer für die einzelnen Schritte des Prozesses verantwortlich ist (Organisationen, Rollen oder Personen)?

x

Ist das Vorgehen in dem Prozess auf die Interessensgruppen (beispielsweise Kunden) ausgerichtet ?

x

Ist das Vorgehen im Prozess klar begründet?

x

Gibt es neben der Prozessbeschreibung noch ausreichend Hilfsmittel für die Ausführung des Prozesses (Checklisten, Arbeitsanweisungen etc.)?

x

Wurde ein Prozessverantwortlicher (Process Owner) benannt ?

6.2

Bewertung

Walk-Throughs

x

Sind die Befugnisse des Prozessverantwortlichen (Process Owner) festgelegt und sind diese ausreichend?

x

Ist der Geltungsbereich des Prozesses eindeutig festgelegt?

x

Sind die Beziehungen des Prozesses zu anderen Prozessen beschrieben bzw. definiert?

Lediglich die Beantwortung der fett herausgehobenen Fragen wird durch geeignete Werkzeuge unterstützt. Alle anderen Fragen können nur durch die am Prozess beteiligten Personen bzw. Organisationen geklärt werden. Insbesondere sind die fett gekennzeichneten Fragen für Menschen schwer und mühselig zu beantworten. Umfangreiche Diagramme, die den Prozessablauf beschreiben, müssen auf das Einhalten von Beschreibungskonventionen (Syntax) geprüft werden und ob mit dem Prozess erreicht wird, was gefordert wurde. Diese Beweise durch „heftiges Hinschauen“ (Spruch eines alten Mathematiklehrers) sind sehr mühselig zu erbringen und fehleranfällig. Insbesondere ist das Lesen seitenlanger Diagramme für Menschen sehr ermüdend, und die Inhalte sind bezüglich ihrer Praxistauglichkeit nur schwer nachvollziehbar. Aus diesem Grund sind wir der Meinung, dass diese Methode der Qualitätssicherung gut geeignet ist für Prozesse, die in Fliesstext oder in strukturiertem Text wie beispielsweise Tabellen beschrieben sind. Für formale Beschreibungsmethoden sollten Werkzeuge zur Verfügung stehen, die einen großen Teil der Prüfungen (beispielsweise Syntax) automatisch erledigen.

6.2 Effektivität

Walk-Throughs Um die Nachteile der visuellen Begutachtung abzumildern, wurde eine stärker formalisierte Version des Review entwickelt. Ähnlich wie bei der Code-Inspection in der Programmierung, wird beim Walk-Through der Prozess gemeinsam Schritt für Schritt durchgegangen. Um das schrittweise Durchgehen lebendiger zu gestalten, kann eine formale Prozessbeschreibung mit Hilfe eines praktischen Beispiels durchlaufen werden. Ein Prozess-Beteiligter geht anhand eines konkreten Beispiels die Geschäftsprozessbeschreibung schrittweise durch. Zu jedem Prozess-Schritt stellt der 91

6

Qualitätskontrolle: Prozesse auf Eignung prüfen Experte gezielte Fragen, um die Effektivität der Prozessbeschreibung zu hinterfragen. Es werden beispielsweise das Verständnis der Fachbegriffe, die fachliche Notwendigkeit sowie die Vollständigkeit der Prozessbeschreibung, um die fachliche Aufgabe optimal zu lösen, überprüft. Auf diese Weise wird die Prozessbeschreibung kontrolliert. Ein Walk-Through wird mit etwa zwei bis drei ProzessBeteiligten durchgeführt, die verschiedene Benutzergruppen vertreten. Die Personen, die den Prozess definiert haben (beispielsweise Prozess-Manager), sollten sich im Hintergrund halten, damit Kritik offen formuliert werden kann. Alle Kritikpunkte und Anregungen werden gesammelt, dokumentiert und anschließend mit den Prozess-Beteiligten ausgewertet. Diese Auswertung führt zu einer Überarbeitung des Prozesses. Die schrittweise Analye des Prozesses kann durch Animationen unterstützt werden. Das verwendete Werkzeug zeigt den aktuellen Prozess-Schritt beispielsweise durch eine andere Farbkennzeichnung an. Das schematische „Abarbeiten“ der Prozessbeschreibung erfordert, dass der Prozessablauf formal beschrieben ist. Allerdings schränkt die Anforderung der formalen Beschreibung die Anwendbarkeit des Walk-Throughs wieder ein, denn die Anwender eines Prozesses (Fachabteilungen) sind nicht generell in der Anwendung formaler Techniken geschult. Wird zur Beschreibung eines Prozesses beispielsweise UML verwendet, ist dieser zumindest semiformal beschrieben; allerdings ist UML eher eine Technik für Softwareentwickler und nicht für Fachabteilungen.

Bewertung

6.3 Effizienz

92

Für informelle Beschreibungen von Prozessen in Freitextform oder strukturierter Textform sind Walk-Throughs nur bedingt geeignet.

Simulation Neben der Effektivität muss die Effizienz der beschriebenen Geschäftsprozesse überprüft werden. Nach der Prüfung der Effektivität (Liefern die Prozesse überhaupt das gewünschte Ergebnis?), muss überprüft werden, ob das Ergebnis mit dem geringsten möglichen Einsatz von Ressourcen zustande kommt. Die hierbei gewonnenen Erkenntnisse liefern die Basis für die Ermittlung des

6.4

Geschäftsprozesse sofort erleben

Ressourcenbedarfs bei einer angenommenen Anzahl von Prozessdurchläufen. Bei der Simulation von Geschäftsprozessen werden die von einem Prozess verarbeiteten Geschäftsereignisse zufällig erzeugt. Im Rahmen der Simulationsläufe werden Informationen über die Ablauffähigkeit von Prozessen, über Prozess-Schwachstellen und Ressourcenengpässe geliefert. Auf Basis der simulierten Prozesskennzahlen können bereits im Vorfeld kostenintensiver Prozessänderungen innerhalb eines Unternehmens verschiedene Alternativen bewertet und ein realitätsgetreues Benchmarking durchgeführt werden. Moderne Werkzeuge und Simulationsmethoden ermöglichen die Analyse und Optimierung der Prozesse bezüglich der Kosten, der Durchlaufzeiten, der Auslastung oder der Engpässe. Zusätzlich bildet die Simulation der Geschäftsprozesse eine Ausgangsbasis zur Einführung der Prozesskostenrechnung anstelle der relativ ungenauen Zuschlagskalkulation. Die Gewinne bzw. Verluste der einzelnen Bereiche werden damit frühzeitig transparent. Bewertung

6.4

Die Durchführung einer Simulationsuntersuchung setzt eine präzise Beschreibung des betrachteten Prozesses voraus. Dies bedeutet, dass zur Definition des Prozessablaufes eine formale Methode verwendet wird. Zusätzlich sind genaue Kenntnisse über die untersuchten Kennzahlen notwendig. In der Praxis werden Simulationen wegen des damit verbundenen Aufwandes nicht sehr häufig eingesetzt, obwohl die gewonnenen Erkenntnisse überzeugend sein können.

Geschäftsprozesse sofort erleben Die beste Bewertung für die Effektivität und für erste Abschätzungen der Effizienz liefert die Möglichkeit, Prozesse bereits im frühen Beschreibungsstadium auszuprobieren. Da durch das „sofortige Erleben“ der höchste Qualitätszuwachs erzielt werden kann, soll diese Art der Qualitätsverbesserung etwas genauer vorgestellt werden, denn der Mensch lernt durch das praktische Tun am meisten.

93

6

Qualitätskontrolle: Prozesse auf Eignung prüfen

6.4.1

Klärung des Begriffs „Prozesse sofort erleben“ hat folgende Aspekte: x

Die Darstellung von Prozessen orientiert sich an der realen „Erlebniswelt“ der betroffenen Personen. Mit Erlebniswelt ist natürlich das Geschäftsumfeld gemeint.

x

Das Geschäftsumfeld ist stark von den damit verbundenen IT-Systemen geprägt. Das bedeutet, die Abläufe können weitgehend am Computer nachempfunden werden.

x

Die Anforderung „sofort“ bedeutet, dass anhand der Prozessbeschreibung die Prozesse ausprobiert werden sollen. Mängel können auf diese Weise frühzeitig erkannt und korrigiert werden. Das reduziert Zeit und Kosten der weiteren Konzeptions- und Realisierungsarbeiten deutlich.

Der Erlebnisaspekt klingt ungewohnt emotional. Der Begriff „Erleben“ führt jedoch weiter, was in den 90er Jahren durch „Multimedia“ propagiert wurde. Damals wurde versprochen, dass mit dem „Neuen Medium“ alle menschlichen Sinne angesprochen werden. Richtig ist, dass am Computer sowohl Audio- Bild-, Videoverarbeitung etc. möglich ist und die Medien miteinander kombiniert werden können. Für die sensuelle Aufnahme muss Information auf mehreren Kanälen nicht unbedingt hilfreich sein. Einschub

Ein Softwareanbieter verspricht, dass man mit seiner Software „gleichzeitig“, das heißt parallel, Briefe schreiben, Bilder bearbeiten und Tabellen berechnen kann. Dieses, fiktive Beispiel zeigt: Was technisch machbar ist, ist für den Menschen nicht unbedingt möglich oder wünschenswert. Um den Aspekt „Erleben“ zu verstehen, kann ein Bezug zur handlungsorientierten Medienpädagogik herangezogen werden. Hier wird gezeigt, dass der Umgang mit Medien am besten durch das aktive Handeln und Ausprobieren erlernt werden kann. Man stelle sich vor, jemand hat noch nie ferngesehen, sondern darüber in Büchern gelesen und versucht, jemandem das Fernsehen zu erklären oder über Filme zu diskutieren. Das Ergebnis wird sicher sehr merkwürdig sein.

94

6.4

Geschäftsprozesse sofort erleben

Nun sind Unternehmensabläufe erheblich komplexer. Schließlich münden hier viele unterschiedliche „Erlebniswelten“ ein. Oft wird behauptet, dass durch Aufzeichnen eines Prozesses die Zusammenhänge in ihrer Gesamtheit verstanden werden. Das bezieht sich auf alle Beteiligten: Management, Prozessverantwortliche, Entwickler oder Anwender. Um Prozesse verstehen zu können, ist es entscheidend, ein umfassendes Verständnis zu bekommen. So gleicht das Konzept „Prozesse erleben“ in gewisser Weise einem Unternehmensplanspiel, in dem Personen verschiedene Rollen einnehmen. Eine günstige Vorraussetzung zum „Prozesse erleben“ ist die subjektorientierte Sicht von Geschäftsprozessen.

6.4.2

Ziel: Geschäftsprozesse am System erleben Optimale Voraussetzungen, um Prozesse zu erleben, sind dann vorhanden, wenn die skizzierten Prozesse sofort ausprobiert werden können. Der End-Anwender sollte sofort in der Lage sein, zu sehen, wie sich der Prozess in der täglichen Arbeit auswirkt.

6.4.3 Beispiel für Prozesse erleben Ein Produkt, das dem Anspruch von erlebbaren Prozessen sehr nahe kommt, ist das Werkzeug jLive! der Firma jCOM1. Es wurde auf Basis der subjektorientierten Prozessbeschreibung (vgl. Abschnitt 5.6) entwickelt und realisiert den „Sofort Erleben“-Ansatz. Beim „Prozesse erleben“ werden alle Daten und Informationen aus der subjektorientierten Prozessbeschreibung ausgewertet und analysiert. Als Ergebnis werden Benutzermasken generiert, die simulieren, welche Schritte die Benutzer im Prozess abarbeiten. Im folgenden Beispiel wird dies an einem vereinfachten Prozess „Urlaubsantrag“ gezeigt.

Vorbereitung: Identifikation der Subjekte und Interaktionen Zunächst werden die am Prozess beteiligten Subjekte Mitarbeiter, Vorgesetzter und Personalabteilung identifiziert. Darüber hinaus werden die Interaktionen zwischen den Subjekten beschrieben.

95

6

Qualitätskontrolle: Prozesse auf Eignung prüfen

Der Mitarbeiter sendet einen Urlaubsantrag an seinen Vorgesetzten. Von diesem erhält er eine Genehmigung oder eine Ablehnung. Der Mitarbeiter sendet einen genehmigten Urlaubsantrag an die Personalabteilung. Abbildung 42 zeigt das Verhalten des Mitarbeiters. Der umrandete Zustand „Arbeiten“ ist der Anfangszustand. In diesem Zustand führt der Mitarbeiter die Funktion Arbeiten aus. Diese Funktion führt zum Ergebnis „urlaubsreif“. Im resultierenden Nachfolgezustand „Urlaubsantrag stellen“ sendet der Mitarbeiter einen Urlaubsantrag an seinen Vorgesetzten. Danach wartet der Mitarbeiter auf die Antwort. Wird der Urlaub abgelehnt, ist der Prozess beendet, ansonsten wird der genehmigte Urlaubsantrag an die Personalabteilung geschickt und dort in der Urlaubsliste vermerkt.

96

6.4

Geschäftsprozesse sofort erleben

Analog zum Verhalten des Mitarbeiters ist das Verhalten des Vorgesetzten und der Personalabteilung beschrieben. Bei obigem Prozess handelt es sich um einen einfachen Prozess, der durchaus durch „vollständiges Hinschauen“ auf seine Effektivität geprüft werden kann. Wir wollen an diesem einfachen Beispiel zeigen, wie eine Validierung als „Prozess erleben“ aussieht.

Prozess sofort erleben Aus der Prozessbeschreibung werden mit Hilfe von jLive! für jedes Subjekt automatisch Benutzermasken generiert, in denen interaktiv die Prozess-Schritte ausprobiert werden. Die Masken haben ein einheitliches Format, sind also noch nicht individuell angepasst und optimiert, für diese frühe Phase ist das aber noch nicht erforderlich. Für jedes Subjekt wird in einem Fenster eine Benutzermaske erzeugt. In dieser Maske sieht jeder am Prozess Beteiligte die Aktionen, die er in dem betrachteten Prozess auszuführen hat. Im folgenden Beispiel wird der Name des aktuellen Zustands (Arbeiten) und der in diesem Zustand einzig mögliche Übergang „urlaubsreif“ gezeigt.

97

6

Qualitätskontrolle: Prozesse auf Eignung prüfen

Der Mitarbeiter entscheidet nun, den Übergang „urlaubsreif“ auszuführen. Dadurch wird der Zustand „Urlaubsantrag stellen“ erreicht. Die nächste Maske für den Mitarbeiter sieht dann wie folgt aus:

In diesem Zustand wird der Urlaubsantrag ausgefüllt und an den Vorgesetzten gesendet. Abbildung 45 zeigt die Parameter des Urlaubsantrags. Durch Klicken auf den Nachrichtenparameterschalt-

98

6.4

Geschäftsprozesse sofort erleben

fläche (Symbol Blatt und Stift) werden die Parameter eingeblendet (Abbildung 45, rechts).

Die Tabelle „Message Parameters“ in Abbildung 45 zeigt die Informationen, die der Mitarbeiter im Urlaubsantrag an seinen Vorgesetzten senden muss. Formate von geplanten Formularen können nun als Bilder hinterlegt werden, um eine Vorstellung vom geplanten „look&feel“ zu bekommen. Für den Urlaubsantrag sei folgendes Formular geplant.

99

6

Qualitätskontrolle: Prozesse auf Eignung prüfen

Nun wird der Antrag an das „Subjekt“ Vorgesetzter gesendet. Auch für diese Rolle werden die entsprechenden Masken mit jLive! generiert. Der Vorgesetzte erhält den Antrag mit den zugehörigen Parametern.

100

6.5

Zusammenfassung

Auf die oben geschilderte Art kann nun der gesamte Prozess durchgespielt werden. Jeder Prozessbeteiligte erlebt den Prozess aus seiner Perspektive. Damit kann durch das praktische Tun beurteilt werden, ob der Prozess den Anforderungen entspricht. Fazit

Dieses einfache Beispiel beschreibt, wie eine subjektorientierte Beschreibung rasch in eine erlebbare Form umgesetzt werden kann. Damit wird getestet, ob die Logik des Prozesses, d. h. die Reihenfolge der Interaktionen, den Anforderungen entspricht und wichtige Fragen werden geklärt Genügen die ausgetauschten Informationen den Anforderungen? Werden die verwendeten Formulare oder Bildschirmmasken akzeptiert? Gibt es hierzu Änderungswünsche? etc. Man beachte: Das Ergebnis „Prozess sofort Erleben“ ist nicht die Realisierung selbst! Der Entwicklungsaufwand hält sich bislang in Grenzen. Realisiert wurde das Konzept „Prozesse sofort erleben“ unserer Kenntnis nach bislang nur für subjektorientierte Beschreibungen. Hier passen die beiden Konzepte gut zusammen.

6.5

Zusammenfassung Es gibt verschiedene Methoden, um die Qualität einer Prozessbeschreibung einzuschätzen. Ein wesentliches Kriterium ist, wie gut der Prozess in allen Auswirkungen verstanden wird. Zur Veranschaulichung soll abschließend folgendes Beispiel dienen.

Herausforderung: Ein sehr erfolgreiches Unternehmen konnte aufgrund zu geringer Ressourcen einen Kernprozess nicht so schnell skalieren, wie es Prozesse das momentane Wachstum erfordert hätte. Deshalb beschloss verstehen! das Management, den Prozess einem Fremdunternehmen zu übertragen (outsourcing). Dies funktionierte jedoch nur unzureichend, und bereits nach einem Jahr holte man den Prozess wieder zurück (insourcing). Um den Kapazitätsengpass zu überbrücken und den Prozess zu unterstützen, stellte man über 100 ungelernte Zeitarbeitskräfte ein. Die Fehlerrate war entsprechend hoch, und so beauftragte man einen externen Dienstleister mit besten Referenzen. Es dauerte nicht lange, da überlegte man sich, den Prozess wieder ins eigene Haus zu überführen …

101

6

Qualitätskontrolle: Prozesse auf Eignung prüfen Was ist passiert? Niemand hat den Prozess richtig verstanden, und jede Migration war nur eine Verlagerung des Problems, die aber zu keiner Lösung führte. Welches Konzept zur Qualitätssicherung am besten geeignet ist, hängt von den betrieblichen Rahmenbedingungen ab. Eine Begutachtung der Dokumente wird häufig der erste Schritt sein. Bei Walk-Throughs steht die Effektivität im Vordergrund, bei Simulation die Effizienz. Das Konzept „Erleben“ bringt die deutlichsten Vorteile, da Effizienz und Effektivität eines Prozesses gleichermaßen berücksichtigt werden. Als Zusammenfassung stellt folgende Tabelle die Methoden von Kapitel 6 gegenüber und zeigt, welche Qualitätsmethoden für bestimmte Prozessbeschreibungsmethoden (Kapitel 5) eher geeignet sind. und

Qualitäts-

+

-

-

-

Walk-Throughs

-

0

++

+

++

Simulation

--

-

++

+

++

Prozesse erleben

o

o

O

O

++

Begutachtung

Struktuiert

++

textuellinformell

subjektorientiert

Methoden

objektorientiert

Gegenüberstellung

aufgabenflußorientiert

Tabelle 5: maßnahmen

Legende

102

++

ziemlich gut

O

neutral

-

weniger gut

+

eher gut

--

eher schlecht

6.6

6.6

Aufgaben zur Prozess-Modellierung (Ebene 4)

Aufgaben zur Prozess-Modellierung (Ebene 4) Checkliste: x

Welche Zielgruppen müssen die Prozessbeschreibung verstehen?

x

Wie genau muss der Prozess definiert werden?

x

Wie groß ist das Risiko, einen „falschen“ Prozess zu definieren und dann zu implementieren?

x

Welche Qualitätssicherungsmaßnahmen für die Prozessbeschreibung sind angemessen?

) Hinweise zur Lösung dieses Gestaltungsschrittes finden Sie im Abschnitt 8.4.

103

7

IT-Unterstützung: Prozesse erfolgreich implementieren Dieses Kapitel beschreibt die konkrete Umsetzung von Geschäftsprozessen in die betriebliche Praxis. Wir werden klären, was zu beachten ist, wenn Geschäftsprozesse teilautomatisiert oder ohne IT-Unterstützung realisiert werden. Ein allgemeines Referenzmodell und dessen Nutzen beim Einsatz von Standardsoftware wird erläutert, und verschiedene Technologien für die Eigenentwicklung von Prozessen werden vorgestellt. Bei der Implementierung von Geschäftsprozessen ist der Begriff des Workflows von zentraler Bedeutung. Darunter versteht man einen Geschäftsprozess, der durch IT-Systeme, so genannte Workflow-Management-Systeme, unterstützt wird. Die Automatisierung von Geschäftsprozessen bedeutet also, diese als Workflows zu realisieren.

7.1

Manuelle und IT-gestützte Prozessausführung

7.1.1

Office-Unterstützung

Manuelle Prozessausführung

Geschäftsprozesse lassen sich in der Regel auch manuell ausführen, wobei dann nicht mehr von einem Workflow gesprochen werden kann. Eine manuelle Prozessausführung wird durch zwei wesentliche Eigenschaften festgelegt. Die Prozessbeschreibung (vgl. Ebene 3) legt die Reihenfolge der einzelnen Aufgaben fest. Die Kontrolle (vgl. Ebene 4) über die korrekte Ausführung der einzelnen Aktionen kann durch Arbeitsanweisungen oder Checklisten erfolgen, in denen die einzelnen Arbeitsschritte durch den jeweiligen Bearbeiter absolviert werden. Das ist eine manuelle Methode zur Ausführung eines Prozesses.

Einfache Hilfsmittel

Bei die Durchführung von Prozessen werden häufig Hilfsmittel wie Textverarbeitungs- und Tabellenkalkulationsprogramme genutzt. Kennzeichen dieser Umsetzung von Geschäftsprozessen sind äußerste Disziplin bei der Abarbeitung des „Kontrollflusses“ und Medienbrüche mit Doppeleingaben bei der Ausführung der 105

7

IT-Unterstützung: Prozesse erfolgreich implementieren einzelnen Arbeitsschritte. Die Kontrolle des Prozesses liegt beim Mitarbeiter.

7.1.2

Isolierte Datenbankanwendungen

Isolierte ITAnwendungen

Eine weitere Methode sind isolierte IT-Anwendungen, bei denen einfache Datenbankaufrufe genutzt werden. Das können einfache Datenbankanwendungen sein, die für einen ganz bestimmten Teilprozess implementiert worden sind. So kann der Prozess „Auftragsverwaltung“ einen Schritt „Kundendaten erfassen“ enthalten, der als Datenbankanwendung umgesetzt worden ist. Da diese Anwendung jedoch isoliert ist, kann es passieren, dass eine bereits über das Kundenverwaltungssystem erfasste Adresse nochmals in ein Formular eingegeben werden muss, statt sie direkt aus dem Kundensystem in das Formular zu übertragen. Dieser manuelle Zusatzaufwand bedeutet auch Fehleranfälligkeit. Ein anderes Problem ist, dass in Datenbankanwendungen keine expliziten Prozesse abgebildet werden. Jeder Benutzer manipuliert die Daten ohne übergreifendes Konzept. Auch hier sind Fehler vorausprogrammiert.

Workflow in Datenbankanwendungen

Es wäre beim Aufbau einer Datenbank einfach, diese Mängel zu vermeiden, wenn eine Workflow-Logik implementiert würde. Die folgende Methode wird häufig in der Automatisierungstechnik eingesetzt. Jeder Datensatz in den Kern-Tabellen wird um ein „Status“-Attribut erweitert. In einer neuen Datenbank-Tabelle (beispielsweise „STATUS“) werden alle möglichen Zustände abgelegt, die die Attribute annehmen können. In einer zweiten Tabelle (beispielsweise Tabelle „TRANSITION“) werden die zulässigen Übergänge zwischen den Stati abgelegt. Auf diese Art und Weise hat jeder Datensatz einen definierten Zustand. Wird er bearbeitet, kann durch Überprüfung in TRANSITION festgestellt werden, welche weiteren Zustände zulässig sind, also welche Prozess-Schritte korrekt sind. Wird der Datensatz bearbeitet und erhält er einen neuen Zustand, wird der Status des Satzes entsprechend geändert. Diese einfache Methode entspricht dem Grundprinzip von Workflow-Engines. In isolierten Datenbankanwendungen integriert, kann dieses Verfahren auf einfache Art und Weise die Korrektheit eines Workflows sichern.

106

7.2

Standardsoftware in den Workflow integrieren

7.1.3

Worklist-Anwendung

Worklistsystem

Unter einem Worklistsystem versteht man Software, die ProzessSchritte steuert, ohne dass die Ausführung der einzelnen Schritte bereits integriert ist. Der Anwender hat die Information, an welchen Prozessinstanzen er arbeitet und welche Schritte er in der jeweiligen Instanz auszuführen hat. Im Vergleich zu der oben beschriebenen Datenbankanwendung ist bereits eine Kontrollfunktion des Workflows integriert. Wird in einem Prozess-Schritt eine Standardanwendung aufgerufen, so ist es anwenderfreundlich, wenn das Worklistsystem beim Erreichen des jeweiligen Prozess-Schrittes die Anwendung selbst aufruft und die erste Funktionen automatisch ausführt. Durch ein Worklistsystem können einfache Prozess-Schritte automatisiert werden. Diese Art der Prozessimplementierung ist in überschaubaren Organisationen ohne große Investitionen möglich, wobei die Anzahl der Prozessausführungen pro Zeiteinheit nicht hoch sein sollte. Durch die IT-gestützte Steuerung der Prozessausführung können für die einzelnen Schritte die Ausführungszeiten gemessen werden und ein Prozess-Controlling realisiert werden. Ein systematisches Verbessern der Prozesse ist auf diese Weise möglich. Im nächsten Abschnitt werden wir darauf näher eingehen.

7.2

Standardsoftware in den Workflow integrieren Im folgenden wird ein allgemeines Referenzmodell für Workflows beschrieben und exemplarisch gezeigt wie Programmbausteine eines Standard-Anwendungssystems (hier SAP R/3) in eine Prozessimplementierung eingebunden werden können.

107

7

IT-Unterstützung: Prozesse erfolgreich implementieren

7.2.1 WorkflowManagementSystem

Referenzmodell für Workflow-Management-Systeme Ein System zur Implementierung von Geschäftsprozessen wird als Workflow-Management-System bezeichnet. Die „WorkflowManagement-Coalition-Organisation“ (WfMC) hat ein Referenzmodell für Workflow-Management-Systeme entwickelt. Abbildung 48 zeigt die einzelnen Komponenten eines solchen Systems und dessen Schnittstellen.

Die Schnittstellen zwischen den einzelnen Komponenten sind wie folgt definiert. Tabelle 6: Überblick der Schnittstellen im WorkflowManagement-System

108

Schnittstelle

Definition

Prozessdefinition (1)

Schnittstelle zwischen Prozessdefinition, Modellierungswerkzeugen und der „Workflow Engine“

Benutzerschnittstelle (2)

APIs für Clients, um Dienste von der „Workflow Engine“ an-

7.2

Standardsoftware in den Workflow integrieren zufordern, damit der Prozessfortschritt und die Aktivitäten kontrolliert werden können.

Applikations-Schnittstelle (3)

APIs, die der „Workflow Engine“ erlauben, Applikationen aufzurufen und zu nutzen.

Workflow-Management-System Standard-Schnittstelle für den Schnittstelle (4) Austausch mit anderen Workflow-Systemen Administration und Monitoring Schnittstelle für Werkzeuge zur (5) Kontrolle der Prozesse und zur Überwachung Die wesentlichen Komponenten im Referenzsystem der WfMC sind der „Workflow Enactment Service“ und die Workflow Engine. Die Aktivitäten und ihre Reihenfolge werden in der Prozessdefinition festgelegt und durch die Workflow Engine gesteuert. In einem Unternehmen laufen mehrere Instanzen eines Geschäftsprozesses gleichzeitig ab. Bei der Erteilung eines individuellen Kundenauftrages wird eine neue Instanz des Geschäftsprozesses „Auftragsbearbeitung“ angestossen. Das Management der einzelnen Instanzen eines Geschäftsprozesses erfolgt mit Hilfe von „Workflow Engines“ durch das „Workflow Enactment System“. Eine Workflow Engine stellt die Ausführungsumgebung für eine Workflow-Instanz zur Verfügung. Dazu gehören beispielsweise folgende Aufgaben: x

Einordnung der Instanz in das organisatorische Umfeld

x

Interpretation der Prozessdefinition

x

Kontrolle der Prozessinstanzen

x

Navigation zwischen sequentiellen oder parallelen Prozessaktivitäten

x

Interpretation von Prozessdaten

x

Identifikation der Benutzerschnittstellen

x

Verknüpfung mit anderen Programmen

x

Übergeordnete Kontrollfunktion 109

7

IT-Unterstützung: Prozesse erfolgreich implementieren Ein Workflow Enactment Service ist ein Dienst, der eine oder mehrere Workflow Engines startet, verwaltet und ausführt. Der Zugriff auf Komponenten einer Anwendungssoftware erfolgt über die Schnittstelle WAPI (Workflow Application Programming Interface). Ein Worklist handler ist der Teil eines Programms, der die Benutzerschnittstelle zum Anwender organisiert. Er kann Teil eines Workflow-Management-Systems sein oder von einem WorkflowExperten definiert und programmiert werden. WorkflowFunktionen können in andere Anwendungen eingebettet werden, wie beispielsweise in ein E-Mail-Programm, damit der Benutzer eine einheitliche Arbeitsoberfläche hat. Zwischen dem Workflow Enactment Service und den Anwendungen muss ein Kommunikationsmechanismus bestehen, um verschiedene operative Systeme zu integrieren. Der letzte Bereich ist eine Schnittstelle für Administration und Monitoring. Der Ablauf verschiedener Instanzen der einzelnen Geschäftsprozesse muss überwacht werden. Dabei werden zwei Überwachungssichten unterschieden. Zum einen die Überwachung der verwendeten IT-Systeme bezüglich auftretender Engpässe und Fehler, zum anderen eine Überwachung der laufenden Geschäftsprozesse. Beispiele hierfür sind die Überwachung von Antwort- und Bearbeitungszeiten für Geschäftsvorfälle. Wie wir später zeigen werden, ist die Aufgabe einer Workflow Engine eng verbunden mit dem Konzept der Service Orchestrierung. Im folgenden Abschnitt wird erklärt, wie vom Workflow Referenz System ausgehend eine SAP-Anwendung in eine Workflow-Steuerung integriert wird.

7.2.2

Umsetzung eines Prozesses in SAP/R3 In einem Industrieprojekt (Branche Anlagenbau) wurde die Standardsoftware SAP R/3 für den Auftragsabwicklungsprozess einer Kundeneinzelfertigung in einen Workflow integriert. Zu diesem Zweck wurde die praktische Anwendung der subjektorientierten Modellierungs- und Implementierungsmethode des Werkzeugherstellers jCOM1 AG eingesetzt. Das Institut für modellbasierte Softwareentwicklungsprozesse (BayTech IMSWEP) an der FH Deggendorf (www.imswep.baytech.de) wurde beauftragt, das Projekt zu evaluieren. Interessant war, dass der Kunde

110

7.2

Standardsoftware in den Workflow integrieren

als externe Organisation und viele verschiedene Organisationsbereiche des Unternehmens beteiligt waren.

Übertragung des Referenzmodells auf den Anwendungsfall Wird das Referenzmodell auf den vorliegenden Fall übertragen ergibt sich das folgende Gestaltungs-Szenario. Die Prozessdefinition wurde in jPASS! abgelegt, die Masken, die durch jLIVE! generiert wurden, liegen in der Benutzerschnittstelle. Jedes Subjekt kann durch eine eigene Workflow Engine ausgeführt werden. Die einzelnen Workflow Engines kommunizieren über eine RMISchnittstelle (Remote Method Invocation, Zugriff auf Methoden über Rechnergrenzen hinweg) oder SOAP (siehe dazu auch nachfolgende Abschnitte). Diese Subjekte rufen SAP-Bausteine über BAPIs (SAP Zugriffsmethode auf R/3 Module) auf. Im Folgenden werden die Implementierungsschritte detailliert aufgezeigt.

Anforderungsbeschreibung Auf Basis einer Prozessanalyse wurde eine verbale Beschreibung des Auftragsabwicklungsprozesses angefertigt. Dadurch werden die Sichten der am Prozess beteiligten Anwender dokumentiert. Dies ist noch kein Bestandteil des Referenzmodells, sondern eine erforderliche Vorarbeit.

Subjektorientierte Modellierung Als Subjekte wurde der „Kunde“ und alle beteiligten „Organisationseinheiten“ des betrachteten Unternehmens identifiziert und deren Interaktionen mit Hilfe des Subjektmanagers modelliert. Abbildung 49 zeigt die am Prozess beteiligten Subjekte.

111

7

IT-Unterstützung: Prozesse erfolgreich implementieren

Im Folgenden wird die Interaktion zwischen den Subjekten Kunde und Auftragsmanager betrachtet. Der Kunde erfasst seinen Auftrag über eine Dialog-Maske und sendet die Auftragsdaten an den Auftragsmanager (Nachricht „Auftrag“ in Abbildung 49). Der Auftragsmanager ergänzt die erhaltenen Auftragsdaten und legt dann den Auftrag ab. Abbildung 50 zeigt das Verhalten des Kunden.

112

7.2

Standardsoftware in den Workflow integrieren

Validierung des Prozessmodells Das subjektorientierte Prozessmodell (Auftragsabwicklung) wurde von Vertretern der betroffenen Fachabteilungen evaluiert. Das Rollenverhalten der am Prozess Beteiligten wurde über das Internet mit Hilfe von jLIVE! überprüft. Die Mitarbeiter konnten von verschiedenen Orten aus den Prozess gemeinsam betrachten, simulieren und diskutieren.

113

7

IT-Unterstützung: Prozesse erfolgreich implementieren

Nutzung von Softwarebausteinen ( hier SAP BAPIs) Aus der Verhaltensbeschreibung eines Subjekts wurde automatisch Java Code generiert. Für jedes Subjekt wird eine Klasseninstanz (Objekt) generiert. Jeweils eine Methode ist für jeden Sende- oder Empfangsübergang verfügbar. Diese Methoden werden beim Ausführen eines Zustandsübergangs (Senden und Empfangen eines Subjektes) bzw. beim Erreichen eines internen Zustands ausgeführt. Die „Refinement-Schnittstelle“ erlaubt das Einbinden von Anwendungen, die bei der Ausführung des Subjektverhaltens aktiviert werden. Abbildung 51 zeigt, wie bei der Beschreibung des Kundenverhaltens für den internen Zustand „Auftrag_erfassen“, der entsprechende Methodenrumpf eingefügt wird. Mit dieser Methode wird eine Maske zur Erfassung des Auftrags am Bildschirm erzeugt.

114

7.2

Standardsoftware in den Workflow integrieren

Nach der Erfassung des Auftrags wird dieser an den Auftragsmanager gesendet. Erhält der Auftragsmanager die Nachricht „Auftrag“, wählt er den entsprechenden Prozessübergang. Es wird wieder die entsprechende Methode in den „Refinements“ aufgerufen, die dafür sorgt, dass die erhaltenen Auftragsdaten gespeichert werden. In der nachfolgenden internen Funktion werden die Auftragsdaten ergänzt und in der SAP Auftragsverwaltung erfasst. Abbildung 52 zeigt den Aufruf einer SAP R/3 Funktion innerhalb der Methode „Auftrag_anlegen“.

7.2.3

Zusammenfassung Dieser Abschnitt zeigt, wie Prozesse in einer konkreten Umgebung (subjektorientierte Modellierung, Prozesse sofort erleben, SAP R/3) orientiert am allgemeinen Referenzmodell für Workflow-Management-Systeme umgesetzt werden können.

115

7

IT-Unterstützung: Prozesse erfolgreich implementieren In diese Implementierungsmethode können auch „ereignisgesteuerte Prozessketten“ (EPK) und objektorientierte Modelle (UML) integriert werden.

Wissen ist maßgeblich für Effizienz

Eine wesentliche Größe für die Effizienz der Realisierung von Geschäftsprozessen ist das Wissen und die Kenntnis über die benutzten Softwarebausteine. Jede Standardsoftware bestimmt die Möglichkeiten der ausführbaren Workflows. Die Nutzbarkeit dieses Wissens setzt die Offenheit der zu integrierenden Anwendungssysteme voraus.

7.3

Konzepte einer offenen Architektur zur Prozessimplementierung Im vorherigen Abschnitt wurde gezeigt, wie Prozesse mit Hilfe konventioneller Methoden bzw. mit Hilfe von Standardsoftware realisiert werden. Diese Implementierungsansätze können durch allgemeine Architekturkonzepte zur Realisierung von Geschäftsprozessen erweitert werden. In diesem Abschnitt werden technische Konzepte zur Implementierung von Geschäftsprozessen erläutert. Diese Konzepte sind bereits Bestandteil von Standard-Softwareprodukten bzw. werden in den nächsten Jahren eine zunehmende Rolle spielen. Das technisch orientierte Kapitel hat zum Ziel, die am Markt angebotenen Produkte besser verstehen und einordnen zu können. Zur Realisierung von Geschäftsprozessen gibt es heute grundsätzlich zwei Konzepte: Workflow-Management-Systeme (WMS) und Serviceorientierte Anwendungsarchitekturen (Service Oriented Architecture, SOA). Das Zusammenfügen von Softwareanwendungen (in Zukunft Services genannt) gemäß den Arbeitsschritten eines Geschäftsprozesses zu einem Workflow hat einen engen Bezug zu den Konzepten „Serviceorchestrierung“ und „Servicechoreographie“. Im Folgenden werden diese Konzepte und ihre Beziehung zueinander erläutert.

116

7.3

7.3.1

Konzepte einer offenen Architektur zur Prozessimplementierung

Serviceorientierte Architektur Das Referenzmodell der WfMC ist eine allgemeine Architektur für Workflow-Management-Systeme. Die Komponenten mit ihren Schnittstellen, die beim Ablauf eines Workflows verwendet werden können, werden durch Serviceorientierte Architekturen (SOA) implementiert (Schnittstelle 3 in Abbildung 48). SOA ist ein weiteres Architekturprinzip zur Implementierung von Geschäftsprozessen. Serviceorientierte Architekturen beruhen auf dem Prinzip, dass Servicekonsumenten (Service Client) Dienste anfordern (Service Request), welche von Servicelieferanten (Service Provider) bereitgestellt werden. Der Servicelieferant nimmt die Serviceanforderung entgegen, führt den angeforderten Service aus und liefert das Ergebnis an den Servicekonsumenten zurück. Abbildung 53 gibt einen Überblick über die grundsätzliche Struktur von Serviceorientierten Architekturen.

Da ähnliche oder gleichartige Services von verschiedenen Servicelieferanten zur Verfügung gestellt werden können, natürlich auch zu unterschiedlichen Preisen, ist eine der wesentlichen Aufgaben eines Servicekonsumenten, den passenden Service zu den günstigsten Konditionen zu bekommen. Umgekehrt benötigt ein Servicelieferant einen Marktplatz, um seine Dienste anbieten zu können. Dieser Marktplatz wird durch Service Directories realisiert. Die Verzeichnisse enthalten Informationen über die Art der angebotenen Services, wo diese zu finden sind und wie sie abgerufen werden können. Das bedeutet, dass ein Servicekonsument erst in einem Directory den geeigneten Service suchen muss, um ihn anschließend anzufordern. Abbildung 54 zeigt die daraus resultierende SOA-Struktur. Die Nummerierung der Kan117

7

IT-Unterstützung: Prozesse erfolgreich implementieren ten gibt an, in welcher Reihenfolge die Operationen ausgeführt werden.

Die oben beschriebene Service-Architektur kann unter Verwendung von Web-Technologien genutzt werden. Für die Beschreibung der Services wird die Sprache WSDL (Web-Service Description Language) eingeführt. Ein Service-Anbieter beschreibt seinen Service in dieser Sprache. Ein angebotener Service wird in einem allgemein zugänglichen Verzeichnis registriert (Service Directory). Dazu wird zur Zeit der Standard UDDI (Universal Description Discovery and Integration) verwendet. Das Service-Register bildet somit die „gelben Seiten“ einer Web-Serviceorientierten Anwendungsimplementierung, in denen mögliche Anbieter nach gewünschten Services suchen können. Mit Hilfe der für einen angebotenen Service im UDDI hinterlegten Informationen kann der gewünschte Service verwendet werden. Der Aufruf erfolgt mit Hilfe von SOAP (Simple Object Access Protocol) [Ne05], [Ku02]. Das Zusammenfügen verschiedener Services zu einem Ganzen bzw. zu komplexeren Services, wie beispielsweise der Implementierung eines Geschäftsprozesses, geschieht durch die Orchestrierung [Pe03] bzw. Choreographie [w302]. Im Sinne des WfMC Workflow-Modells entspricht die Orchestrierung bzw. Choreographie den Aktionsfolgen eines Geschäftsprozesses und der benutzten Services. Im Folgenden werden die beiden Konzepte Orchestrierung und Choreographie eingeführt. 118

7.3

Konzepte einer offenen Architektur zur Prozessimplementierung

Service-Orchestrierung Orchestrierung bedeutet, dass die Services von einer zentralen Stelle kontrolliert werden. Service-Orchestrierung ist also vergleichbar mit einem Workflow-Management-System, während Service-Orchestrierung eine Methode ist, eine Workflow-Engine zu implementieren. Prozesse können sowohl mit internen, als auch mit externen Webdiensten kommunizieren. Orchestrierung beschreibt, wie die Webdienste auf Nachrichtenebene interagieren, einschließlich der Prozesslogik und der Ausführreihenfolge. Die Datenebene bleibt von der Orchestrierung ausgenommen.

Vorteil der Orchestrierung ist die Einfachheit, da die Reihenfolge der auszuführenden Aktionen an einer zentralen Stelle dokumentiert ist. Aufgabenorientierte Prozessbeschreibungen lassen sich mit dieser Methode einfach umsetzen, weil die Prozessbeschreibung im Wesentlichen der Orchestrierungsdefinition entspricht. Diese Vorgehensweise hat jedoch beträchtliche Nachteile, wenn ein Prozess Organisationsgrenzen überschreitet und deshalb keine zentrale Stelle existiert, welche die Orchestrierungssteuerung ausführen kann. Das Konzept „Service-Choreographie“ bietet hierfür eine Lösung. 119

7

IT-Unterstützung: Prozesse erfolgreich implementieren

Service-Choreographie Das Konzept der Choreographie legt den Schwerpunkt auf die Zusammenarbeit unabhängiger Services. Jeder Teil spielt eine definierte Rolle und tauscht mit anderen Komponenten Nachrichten zur Synchronisierung aus. Dadurch entsteht ein System von asynchronen unabhängigen Teilprozessen. Dies ist ein Konzept, wie es bei „embedded systems“ (Steuerung technischer Systeme) und Betriebssystemen schon lange verwendet wird. Service-Choreographie ist dann sinnvoll, wenn keine Organisation die vollständige Kontrolle über den Ablauf eines Prozesses haben kann oder soll. So kann ein Käufer nicht die Kontrolle über das Verhalten des Verkäufers haben und umgekehrt. Technisch gesehen kann die Service Choreographie auch betrachtet werden als eine Menge zusammen geschalteter Workflow-Management-Systeme, welche über die Schnittstelle 4, (siehe Abbildung 48), verbunden sind. Abbildung 56 zeigt ein einfaches Beispiel. Käufer und Verkäufer stimmen durch den Austausch von Nachrichten ihre Aktionen aufeinander ab, um den Kauf eines Produktes zu organisieren. Käufer und Verkäufer arbeiten auf separaten WorkflowManagement-Systemen, und die Nachrichten zur Koordinierung werden über eine gemeinsam definierte Schnittstelle 4 ausgetauscht. Der Prozess wird dadurch beschrieben, dass zulässige Nachrichtenfolgen zwischen den Beteiligten festgelegt werden. Als theoretisches Modell wird auf die Prozesskalküle (process calculus) von R. Milner [Mi80] und C.A.R. Hoare [Hoa85] zurückgegriffen. Ein Überblick zu diesem sehr interessanten Bereich der Informatik findet sich in Wikipedia (www.wikipedia.org) unter den Stichworten „Process Calculus“, „Pi-Calculus“ und „Calculus of Communicating Systems“.

120

7.3

Konzepte einer offenen Architektur zur Prozessimplementierung

Gegenüberstellung von Orchestrierung und Choreographie Die folgende Tabelle stellt die wesentlichen Eigenschaften der Orchestrierung und Choreographie gegenüber [Ne05]: Tabelle 7: Gegenüberstellung Orchestrierung und Choreographie Orchestrierung Eine zentrale Stelle ist für die Prozessausführung verantwortlich. Eine zentrale Prozessausführung lässt sich bei organisationsübergreifenden Prozessen schwer realisieren (Probleme beim Outsourcing). Impliziert starke Sequentialisierung der Aktivitäten eines Prozesses. Mögliches Werkzeug: ARIS

Choreographie Jeder Prozess ist für die korrekte Ausführungsreihenfolge selbst verantwortlich. Eine dezentrale Prozessausführung lässt sich bei organisationsübergreifenden Prozessen einfach realisieren. Impliziert starke Parallelisierung der Aktivitäten der am Prozess Beteiligten. Mögliches Werkzeug: jPASS! 121

7

IT-Unterstützung: Prozesse erfolgreich implementieren Die Orchestrierung hat Vorteile, wenn eine zentrale Koordination der Prozesse aufgebaut werden soll. Dies ist in der Regel bei „kleinen“ Prozessen, die innerhalb einer Abteilung ablaufen, der Fall. Bei abteilungsübergreifenden Prozessen ist es schwieriger, einen Koordinator festzulegen. Wenn ein Prozess Organisationsgrenzen überschreitet, beispielsweise beim Outsourcing, ist ein gemeinsamer Koordinator nur schwer zu realisieren. Unabhängige Organisationen sind es gewohnt, ihre Tätigkeiten über Nachrichtenaustausch zu organisieren. Sind an einem Prozess mehrere unabhängige Aufgabenträger beteiligt, so kann das Konzept der Choreographie besser greifen.

Kombination von Orchestrierung und Choreographie In der Praxis werden häufig beide Ansätze kombiniert. Das hängt von der Beschreibungstechnik des Geschäftsprozesses und den Rahmenbedingungen durch die Aufbauorganisation ab. Außerdem kann jedes an einer Choreographie beteiligte „Orchester“ mit Hilfe einer anderen Technologie oder Workflow Engine implementiert werden. Die folgende Aufzählung zeigt Anforderungen und Schritte, um einen als Aufgabenfolge beschriebenen Prozess entsprechend den organisatorischen Erfordernissen zu realisieren, falls keine zentrale Ablaufsteuerung etabliert werden kann:

122

x

Orchestrierung gibt einen zentralen Überblick über einen Prozess.

x

Bei organisationsübergreifenden Prozessen wird die Orchestrierung aufgelöst.

x

Jede an einem Prozess beteiligte Organisation, die nicht über eine zentrale Steuerung kontrolliert werden möchte (intern oder extern), erhält eine eigene Steuerung für seine Aufgabenfolgen innerhalb eines Prozesses (Choreographie).

x

Die organisationsspezifischen Steuerungen synchronisieren sich durch Nachrichten. Mit diesen Nachrichten werden bei Bedarf Ergebnisse in Datenform ausgetauscht. In die organisationsspezifischen Steuerungen werden Sende- und Empfangsaktionen eingefügt.

x

Grundmuster: Sequenz von Aufgaben

7.3

Konzepte einer offenen Architektur zur Prozessimplementierung Andere Voraussetzungen liegen vor, wenn bei der Prozessbeschreibung von einer existierenden Aufbauorganisation ausgegangen wird und ein Prozess eine Folge von Interaktionen der am Prozess Beteiligten ist (subjektorientierte Prozessbeschreibung). Da beim Choreographie-Ansatz keine zentrale Steuerung erforderlich ist, müssen bei der Implementierung einer solchen Prozessbeschreibung mehrere parallele Kontrollflüsse aufgebaut werden, die sich über geeignete Methoden synchronisieren. Die Vorgehensweise bei der Definition und Implementierung von Prozessen entsprechend des Choreographie-Ansatzes skizzieren folgende Punkte: x

Identifikation der an einem Prozess beteiligten Organisationseinheiten mit einer groben Beschreibung der jeweiligen Prozessleistungen.

x

Beschreibung der zwischen den Organisationseinheiten durchgeführten Interaktionen (Bezeichnung, ausgetauschte Daten).

x

Beschreibung der Aktionsfolgen für jede der am Prozess beteiligten Organisation (lokale Orchestrierung) einschließlich der Interaktionen zur Synchronisation.

x

Die organisationsspezifischen Steuerungen synchronisieren sich durch Nachrichten. Mit diesen Nachrichten werden bei Bedarf Ergebnisse (Daten) ausgetauscht.

x

Grundmuster: Parallel arbeitende Organisationen die sich abstimmen (Synchronisieren).

In der Praxis kommen diese Konzepte kombiniert zum Einsatz. Die Implementierung von Geschäftsprozessen bedeutet die Orchestrierung und Choreographie von Anwendungen, die in Form von Services zur Verfügung gestellt werden. Zur Orchestrierung der einzelnen Services innerhalb einer Choreographie können unterschiedliche Technologien verwendet werden. Das ist die Regel bei unterschiedlichen Organisationen, die an einem Prozess beteiligt sind. Es muss eine Übereinkunft bezüglich der Interaktionsschnittstelle getroffen werden (Schnittstelle 4 des Referenzmodells).

123

7

7.3.2

IT-Unterstützung: Prozesse erfolgreich implementieren

Implementierungskonzepte zur Prozessbeschreibungsmethodik Bei der Implementierung von Geschäftsprozessen gilt es entsprechend der Prozessbeschreibung und den organisatorischen Rahmenbedingungen, die IT-Unterstützung für die Abwicklung von Geschäftsprozessen festzulegen. Im folgenden wird gezeigt, welche Geschäftsprozessbeschreibungsmethode sich mit welchen Techniken bevorzugt umsetzen lässt.

Implementierung flussorientierter Prozessbeschreibungen Flussorientierte Prozessbeschreibungen lassen sich als Orchestrierung von Services umsetzen. Der zentrale Koordinator wird durch eine Workflow Engine realisiert. Die Prozessbeschreibung wird in eine von einer Workflow Engine interpretierbaren Beschreibung umgesetzt und um Aufrufe der Anwendungsbausteine ergänzt. Als Standard für die Beschreibung einer Workflow Engine hat sich in den letzten Jahren die Beschreibungssprache BPEL (Business Process Execution Language) etabliert. BPEL ermöglicht es, verteilte Web-Services und die Interaktionen mit dem Benutzer zur Geschäftsprozesslogik hinzuzufügen. BPEL ist mittlerweile zu einem anerkannten Standard für die Komposition von Web-Services geworden. Mit BPEL können komplexe Prozesse implementiert werden, indem die unterschiedlichen Aktivitäten als Programme erstellt und entsprechend der Prozesslogik zusammengesetzt werden. Bei den Aktivitäten kann es sich beispielsweise um den Aufruf von (Web-) Services, Altanwendungen, Datenmanipulationen, Anwenderdialoge oder dem Filtern und Behandeln von Fehlern innerhalb des Prozesses handeln. Diese einzelnen Aktivitäten können ineinander geschachtelt, in Schleifen geführt oder parallel kombiniert werden. Abbildung 57 zeigt das Schema eines BPEL-Prozesses. Mit dieser Abbildung wird deutlich, dass es sich bei BPEL um einen Orchestrierungsansatz handelt.

124

7.3

Konzepte einer offenen Architektur zur Prozessimplementierung

In BPEL wird angenommen, dass die Aufrufschnittstellen für die verwendeten WEB-Services in der Sprache WSDL beschrieben sind.

Implementierung objektorientierter Prozessbeschreibungen Die Implementierung von objektorientierten Prozessbeschreibungen hängt stark von der verwendeten Beschreibungsnotation ab. Heute hat sich dazu UML bzw. UML mit entsprechenden Erweiterungen durchgesetzt. Zur Beschreibung der Prozessdynamik werden häufig Aktivitätsdiagramme verwendet (siehe dazu Abschnitt 5.5). Aktivitätsdiagramme definieren, welche Aktivitäten in welcher Reihenfolge aufgerufen werden. Aus diesen Aktivitätsdiagrammen können mit Unterstützung geeigneter Werkzeuge BPEL-Beschreibungen abgeleitet werden. BPELBeschreibungen werden in naher Zukunft von zahlreichen Workflow Engines interpretiert.

125

7

IT-Unterstützung: Prozesse erfolgreich implementieren Die Aktivitäten werden mit den UML-Methoden zur Definition von Klassen beschrieben. Auch aus diesen Definitionen kann mit Hilfe von Werkzeugen ein Gerüst für entsprechende Programme automatisch abgeleitet werden. Mit MDA (Model Driven Architecture) wurde von der OMG (Open Management Group) ein Ansatz zur Ableitung von Applikationen aus UML-Beschreibungen entwickelt. Die Ableitung von ausführbarem Programmcode erfolgt über drei Modellebenen: x

CIM: Computationally Independent Modell Dieses Modell beschreibt das zu entwickelnde System aus konzeptioneller Sicht und enthält die Anforderungen. Es wird das Geschäftsmodell beschrieben, wer das neue System benutzt und welche Funktionen zur Verfügung gestellt werden. Beschreibungen von Geschäftsprozessen können als ein CIM verstanden werden.

x

PIM: Plattform Independent Modell Das plattformunabhängige Modell PIM beschreibt das System in der Art, dass es auf mehrere ähnliche Systemplattformen abgebildet werden kann. Das PIM enthält noch keine Einzelheiten bezüglich der später zur Implementierung verwendeten technischen Plattform.

x

PSM: Plattform Specific Modell Das plattformspezifische Modell kombiniert das plattformunabhängige Modell mit den technischen Einzelheiten der Zielplattform. Das PSM enthält die Details, wie das PIM die Implementierungsplattform benutzt.

Ausgehend vom CIM wird durch Transformationsschritte das zu entwickelnde System immer weiter zum ausführbaren Anwendungssystem konkretisiert. In jedem Transformationsschritt wird das Vorgängermodell mit zusätzlichen Informationen ergänzt, damit das detailliertere Nachfolgemodell erreicht werden kann. Abbildung 58 gibt einen Überblick zu den einzelnen Transformationsschritten des MDA Konzepts der OMG.

126

7.3

Konzepte einer offenen Architektur zur Prozessimplementierung

Implementierung subjektorientierter Prozessbeschreibungen Bei subjektorientierten Prozessbeschreibungen werden die Konzepte der Orchestrierung und Choreographie kombiniert. Die Orchestrierung der Services innerhalb eines Subjekts wird ergänzt durch den Austausch von Nachrichten mit anderen Subjekten. Dies entspricht der Choreographie. Jedes Subjekt kann als Orchestrierung der von einem Subjekt benötigten Services betrachtet werden, wogegen die Zusammenarbeit der einzelnen Subjekte als Choreographie interpretiert werden kann. Zur Synchronisierung der Zusammenarbeit der einzelnen „Orchester“ werden Nachrichten ausgetauscht. Jedes Subjekt benutzt zur Ausführungskontrolle seiner eigenen Aktivitäten eine eigene „Workflow Engine“. Die Workflow Engines der einzelnen Subjekte sind miteinander verbunden (Schnittstelle 4). Über diese Verbindung werden die Nachrichten ausgetauscht, um die einzelnen Kontrollflüsse der Subjekte bei Bedarf zu synchronisieren. Abbildung 59 zeigt diese Struktur mit den einzelnen Schnittstellen gemäß dem Referenzmodell der Workflow-ManagementCoalition. 127

7

IT-Unterstützung: Prozesse erfolgreich implementieren

Jedes Subjekt eines Prozesses kann mit Hilfe einer geeigneten Technologie realisiert werden. Ein Subjekt kann über BPEL, ein anderes durch Java Server Pages, WebDynpro von SAP oder andere Technologien implementiert werden. Für den Nachrichtenaustausch müssen Vereinbarungen getroffen werden. Da die Standards für Web-Services weitgehend akzeptiert sind, empfiehlt es sich, den Austausch der Nachrichten, d. h. eine Implementierung der Schnittstelle 4, mit Hilfe von Web-Services vorzunehmen. Abbildung 60 zeigt eine Architektur, bei der verschiedene Technologien zum Einsatz kommen und die Verknüpfung über Web-Services erfolgt.

128

7.4

7.4

Technische Lösungen für Workflows

Technische Lösungen für Workflows Die Implementierung von Geschäftsprozessen mit Hilfe von Informationstechnologien bedeutet die Orchestrierung und Choreographie von Anwendungen. Hier gilt es folgende Aufgaben zu lösen: x

Realisierung der Prozesse in den verwendeten Anwendungen und Bereitstellung der Services.

x

Orchestrierung von Services: Anwendungen, die über einen zentralen Kontrollfluss gesteuert werden, müssen entsprechend der Prozessdefinition zusammengefügt werden.

x

Choreographie von orchestrierten Services: Festlegung von Standards zur Kommunikation der „Orchester“.

x

Ausrollen von komplexen Prozessimplementierungen über mehrere Organisationen und Technologien

x

Betreiben eines Prozesses, der mit Hilfe mehrerer Technologieplattformen realisiert wurde.

129

7

IT-Unterstützung: Prozesse erfolgreich implementieren Im Folgenden werden einige Produkte verschiedener Hersteller vorgestellt. Die vorgestellten Plattformen schließen sich nicht gegenseitig aus, sondern ergänzen sich vielmehr. Die momentan aktuellen Basistechnologien zur Implementierung von Anwendungen sind J2EE und .NET. Diese Anwendungen können als Web-Services verpackt werden. Die skizzierten Produkte enthalten oft mächtige Unterstützungsfunktionen um Altanwendungen, oft in Cobol oder PL/I programmiert, ebenfalls als (Web)-Services nutzen zu können. In den folgenden Abschnitten werden die Architekturen gängiger Produkte kurz erläutert.

7.4.1

J2EE

J2EE steht für Java 2 Platform Enterprise Edition und ist die SpeJava 2 Platform Enterprise Edition zifikation einer Standardarchitektur für die Ausführung von verteilten Multi-Tier-Anwendungen. Abbildung 61 zeigt die Struktur (J2EE) von J2EE-Anwendungen [Ba02], [En02].

130

7.4

Technische Lösungen für Workflows

In der Regel wird von einer dreischichtigen Struktur ausgegangen, einer Three-Tier. Der Client Tier repräsentiert den Zugang der Menschen zu der jeweiligen Anwendung und stellt die Benutzeroberfläche zur Verfügung. Der „Client Tier“ wird deshalb auch als „Presentation Tier“ bezeichnet. Der Middle Tier enthält einen wesentlichen Teil der Funktionalität und wird auch als „Business Logic Tier“ bezeichnet. Dieser Begriff ist im Zusammenhang mit Geschäftsprozessen (Business Processes) etwas irreführend. Trotz dieser Bezeichnung enthält der Middle Tier nicht die Ablauflogik eines Prozesses über mehrere Beteiligte bzw. enthält in der Regel keine Funktionalitäten eines Workflow-Management-Systems. Vielmehr wird mit „Business Logic“ die Steuerung der Arbeit eines Clients, d. h. eines Benutzers, bezeichnet und nur indirekt die Zusammenarbeit mehrerer am Prozess Beteiligter gesteuert. Die einzelnen Funktionen des Middle Tiers sind in Enterprise Java Beans (EJB) enthalten. Ein EJB-Container beinhaltet zahlreiche, von allen EJBs benötigte Funktionen wie Sicherheitsmanagement oder Speichermanagement. Clients, die im eigenen Firmennetz liegen, können unmittelbar auf den Middle Tier zugreifen und die entsprechenden Funktionen anstoßen. Eine Variante ist, über Web-Services zuzugreifen. Aus Sicherheitsgründen dürfen Clients, die außerhalb des Firmennetzes liegen, nur über Web-Container den Middle Tier nutzen. Von dort werden erst die Funktionen der EJBs angesprochen. Der EIS Tier repräsentiert im Unternehmen bereits vorhandene Anwendungen und Daten. Diese werden von den EJBs des Middle Tiers genutzt. Insbesondere sind dies Zugriffe auf Datenbanken oder Enterprise Ressource Planning Systems (ERPSysteme) wie SAP/R3. Bei J2EE Anwendungen sind die Clients mit dem Middle Tier bzw. der Middle Tier mit den jeweiligen Bausteinen des EIS Tier verbunden. Die Entwicklung von Multi-Tier-Anwendungen wird durch verschiedene Bibliotheken unterstützt, wie beispielsweise Directory Services oder Bibliotheken zum Zugriff auf Datenbanken. Abbildung 62 gibt einen Überblick über die verschiedenen Unterstützungsservices.

131

7

IT-Unterstützung: Prozesse erfolgreich implementieren

J2EE unterstützt nicht unmittelbar die Steuerung von Workflows über mehrere Prozessbeteiligte hinweg. Diese muss mit den Möglichkeiten von Java direkt programmiert werden, was in der Regel sehr aufwändig und teuer ist. Allerdings ist J2EE ein hervorragendes Werkzeug, Services zu programmieren. Wie dies aussehen kann, wird im Abschnitt über Web-Services erläutert.

7.4.2

.NET .NET ist eine Infrastrukturumgebung, die aus Betriebssystemen, Server-/Back-Officesystemen und Entwicklungswerkzeugen besteht. .NET ist die alternative Plattform zu J2EE für die Entwicklung von Anwendungen [We02]. .NET ist vergleichbar dem Java-Komplex, dem J2EE angehört. Die Laufzeitumgebung von .NET orientiert sich an der JavaUmgebung und erlaubt die Entwicklung von Multi-Tier-Systemen analog der im obigen Abschnitt beschriebenen Grundstruktur. Abbildung 63 gibt einen Überblick über die einzelnen .NETKomponenten.

132

7.4

Technische Lösungen für Workflows

Einen großen Umfang von .NET stellen die Entwicklerwerkzeuge dar. Diese basieren fast alle auf einer einheitlichen Laufzeitumgebung und einer umfangreichen Klassenbibliothek, die nahezu das gesamte Windows-API objektorientiert verkapselt. Für den Entwickler stellen die Klassenbibliotheken vergleichbar mit J2EE umfangreiche Frameworks zur Verfügung, welche die Entwicklung von komplexen Anwendungssystemen erheblich vereinfachen können. Zu nennen sind beispielsweise: x

ASP.NET für serverseitige Webanwendungen.

x

ADO.NET für den einfachen, homogenen Zugriff auf Datenbanken.

x

.NET-Remoting für den Aufbau leichtgewichtiger Remote Procedure Call (RPC)-basierter Anwendungen.

x

.NET Enterprise Service zur einfachen Nutzung der COM+ Dienste sowie das

x

.NET Compact Framework für die Entwicklung von Anwendungen für mobile Endgeräte.

CLR, CTS und CLS entspricht in etwa der Virtual Java Machine aus dem Java-Umfeld. Programme mit verschiedenen Programmiersprachen (C#, VB etc.) werden in eine Zwischensprache IL (Intermediate Language) übersetzt, von der CLR (Common Language Runtime) interpretiert und zur Ausführung gebracht. Daneben beinhaltet .NET einige Services wie SQL Server, Ex133

7

IT-Unterstützung: Prozesse erfolgreich implementieren change usw. Alle Services und Komponenten in .NET sollen als Web-Services ansprechbar sein. Ähnlich wie J2EE unterstützt .NET die Service Aspekte für die Implementierung von Geschäftsprozessen. Funktionalitäten, wie sie eine Workflow Engine bietet, sind bis jetzt nur begrenzt vorhanden. So verfügt bizTalk über eine BPEL-Schnittstelle, die allerdings nicht durch komfortable Werkzeuge zur Erstellung von BPEL-Spezifikationen unterstützt wird.

7.4.3

Web-Service Web-Services sind die momentan aktuelle Methode, den Zugriff auf Anwendungen zu vereinheitlichen. J2EE und .NET sind Technologien zur Entwicklung von Services. Diese Services können als Web-Services von Dienstanbietern zur Verfügung gestellt werden. Obwohl J2EE- und .NET-Vertreter sich in diesen Bereichen einen ausgeprägten Wettbewerb liefern, arbeiten sie im Bereich Web-Services zusammen (Microsoft, IBM, SUN etc.). Web-Service Standards sollen es erlauben, dass man auf Services zugreifen kann, ohne wissen zu müssen, wie sie implementiert sind (J2EE, .NET usw.). Beispielsweise soll es für den Nutzer eines Services bedeutungslos sein, ob dieser mit Hilfe von J2EE oder .NET realisiert wurde. Obwohl die Konzepte zu service-orientierten Architekturen (SOA) bereits entwickelt wurden, bevor es Web-Dienste gab, spielen Web-Dienste in SOA eine wesentliche Rolle. Der Grund hierfür ist, dass die Dienste auf sehr gut definierten und plattform-unabhängigen, weltweit akzeptierten Protokollen aufgebaut wurden. Diese Protokolle beinhalten HTTP, XML, UDDI, WSDL und SOAP. Diese Kombination macht Web-Dienste für den praktischen Einsatz sehr interessant. Weitere Anforderungen an SOA ist die dynamische Auffindbarkeit und Aufrufbarkeit von WebServices. Web-Services bestehen aus folgenden Elementen: x

134

Der XML (Extended Markup Language): Sprache zur Erstellung maschinen- und menschenlesbarer Dokumente in Form einer hierarchischen Struktur (Baumstruktur). XML definiert die Regeln für den Aufbau von Dokumenten. Für einen konkreten Anwendungsfall ("XML-

7.4

Technische Lösungen für Workflows

Anwendung") müssen die Strukturierungsdetails der jeweiligen Dokumente spezifiziert werden. Dies betrifft insbesondere die Festlegung der Strukturelemente und ihre Anordnung innerhalb des Dokumentenbaums. x

Das HTTP-Protokoll, mit dem im Internet Webseiten übertragen werden. So werden über das HTTP-Protokoll auch XML-Dokumente übertragen.

x

Das SOAP-Protokoll, das auf HTTP aufsetzt und Anwendungsfälle beschreibt, wie Funktionsaufrufe und die dazugehörigen Parameter codiert werden.

x

Der Web-Service Description Language (WSDL), einer weiteren XML-Notation, die beschreibt, wie im Detail auf einen Web-Service zugegriffen werden kann. Dies betrifft die Adressierung und die Definition der ausgetauschten Nachrichten. Es werden im wesentlichen die Funktionen definiert, die von außen zugänglich sind, sowie die Parameter und Rückgabewerte dieser Operationen.

x

Die UDDI (Universal Description Discovery and Intergration): Funktionen, mit denen zum einen Anbieter von Webdiensten ihre Dienstleistungen beschreiben und bekannt machen können und zum anderen Dienstkunden nach geeigneten Diensten suchen können. UDDI bildet das Verzeichnis der zur Verfügung stehenden Services.

Die Spezifikationen der Web-Services legen fest, wie Services identifiziert und wie auf sie zugegriffen werden kann. Sie enthalten keine Beschreibung von Technologien, um Web-Services zu implementieren. Zur Implementierung von Web-Services können Technologien wie J2EE oder .NET verwendet werden. Zur Nutzung von Altsystemen werden diese häufig als Web-Services verpackt. Damit wird es möglich, diese auch in modernen ITUmgebungen weiter zu nutzen.

135

7

IT-Unterstützung: Prozesse erfolgreich implementieren Abbildung 64 [Or05] zeigt ein Beispiel, wie J2EE Technologien im Rahmen von Web-Services genutzt werden.

Web-Services sind zur Zeit die aktuelle Methode, serviceorientierte Architekturen umzusetzen. Zur Orchestrierung von Services werden Sprachen wie BPEL verwendet. In den folgenden Abschnitten werden Produkte vorgestellt, die wichtige Ansätze enthalten, um Anwendungen zu orchestrieren und zu choreographieren. Sie unterstützen neben den beschriebenen Basistechnologien Funktionalitäten für die Installation und den Betrieb von Geschäftsprozessimplementierungen.

136

7.4

7.4.4

Technische Lösungen für Workflows

MQ-Series MQ-Series als Teil der Websphere-Familie, ist ein MiddlewareSystem der Firma IBM, das mit Message Queueing arbeitet, um Programme verteilter Anwendungen miteinander kommunizieren zu lassen und um Geschäftsprozesse zu implementieren [Ha03]. Es bietet Funktionalitäten, um die Aspekte Kontrollfluss, Organisation und IT-Anwendung zusammenzuführen. Das sind gute Voraussetzungen, um Geschäftsprozesse zu implementieren. Abbildung 65 [Wa01] zeigt die Hauptkomponenten von MQ-Series.

MQ-Series ist eine "nachrichten-orientierte Middleware" (MOM: Message Oriented Middleware). Sie ermöglicht es Anwendungsprogrammen, über Plattformgrenzen hinweg mit Hilfe eines "Message Brokers" (Integration Server) zu kommunizieren. MQSeries arbeitet mit allen IBM-Betriebssystemen (zum Beispiel OS/2), mit Microsoft Windows und einer Vielzahl von UnixBetriebssystemen zusammen. MQSeries reiht Nachrichten in Queues (Warteschlangen) ein und leitet sie von dort aus an den Zielrechner weiter. MQSeries arbei137

7

IT-Unterstützung: Prozesse erfolgreich implementieren tet asynchron. Wenn der Empfänger einer Nachricht nicht bereit ist, eine Nachricht entgegen zu nehmen, übermittelt MQSeries die Nachricht zu einem späteren Zeitpunkt.

7.4.5

SAP Netweaver Die spezifische Ausprägung einer service-orientierten Architektur der SAP AG ist die Enterprise Service Architecture (ESA) [Ka05]. SAP Netweaver [Wo04 ] ist die Technologieplattform zur Umsetzung der Enterprise Service Architektur. SAP-Netweaver dient als Integrations- und Anwendungsplattform, um Menschen, Daten und Geschäftsprozesse mit Anwendungen zu integrieren. Abbildung 66 zeigt die einzelnen Schichten, welche die verschiedenen Integrationsaspekte abdecken.

138

7.4

Technische Lösungen für Workflows

Über das Composite Application Framework können Anwendungen entwickelt werden, die aus Services verschiedener Bereiche bestehen. Die NetWeaver-Komponente Multi-Channel Access wird dem Bereich People Integration zugeordnet und erlaubt den Zugriff auf SAP R/3 und auf nicht SAP-basierte Anwendungen über verschiedene Endgeräte wie beispielsweise mobile Geräte. Das SAP Enterprise-Portal hat die Aufgabe, einen einheitlich gestalteten und dem Unternehmen angepassten Zugang für alle im Unternehmen vorhandenen Informationen zu ermöglichen. Der Bereich People Integration umfasst zahlreiche Funktionen zur Bereitstellung und Gestaltung der Informationen. Mit der Collaboration-Komponente (Unification Server) können Informationen aus unterschiedlichen Quellen einheitlich navigierbar gemacht werden. Über die Collaboration-Komponente ist es möglich, Teams und Communities über virtuelle Räume und Werkzeuge zur Zusammenarbeit in Echtzeit zu unterstützen. Die für die Implementierung des Kontrollflusses wesentliche Komponente ist die Process Integration-Schicht. Sie besteht im Wesentlichen aus zwei Teilen, dem Integration Broker und dem Business Process Management [Su05]. Der Integration Broker ermöglicht das Anbinden von Komponenten zahlreicher unterschiedlicher Anbieter. Das Business Process Management ist für den reibungslosen Kommunikationsprozess dieser Komponenten untereinander zuständig. Zur Kommunikation müssen die beteiligten Komponenten an die Exchange Infrastruktur angebunden werden. Dadurch ist eine direkte Verbindung zwischen den Komponenten nicht mehr erforderlich. Abbildung 67 zeigt die einzelnen Komponenten der ExchangeInfrastruktur. Mit Hilfe der Komponenten des Integration Builders wird der zu implementierende Prozess definiert. Dies umfasst die Beschreibung von Szenarien, beispielsweise die Prozessbeschreibung in BPEL. Das Integration Directory enthält die jeweiligen Prozessmuster, wogegen das Configuration Directory und Landscape Directory die Informationen zur jeweiligen aktuellen System und Hardware-Konfiguration enthält.

139

7

IT-Unterstützung: Prozesse erfolgreich implementieren

Der Integration Server steuert die Ausführung der im Integration Builder hinterlegten Prozesse. Die Business Process Engine hat die Prozessausführungskontrolle, die Integration Engine wickelt den dazu notwendigen Nachrichtenverkehr ab und die Adapter Engine enthält die Übergänge zu anderen Systemen wie beispielsweise Übergänge zu anderen Middlewaresystemen wie MQ-Series oder .NET. Die Komponentenplattform SAP Web Application Server (Web AS) beinhaltet alle Komponenten des fachlichen Bereichs Application Platform.

7.5

Zusammenfassung Geschäftprozesse müssen entsprechend den fachlichen Anforderungen und den ökonomischen Rahmenbedingungen realisiert werden. Je nach Situation im Unternehmen können Prozesse manuell, teilautomatisiert oder vollautomatisiert abgebildet werden. Je nach Art der gewünschten IT-gestützten Implementierung

140

7.5

Zusammenfassung

werden unterschiedliche Werkzeugtypen eingesetzt. Das Spektrum reicht von einer IT-gestützten Lenkung ohne automatischen Aufruf von Anwendungssoftware in den entsprechenden Prozess-Schritten bis zur vollautomatisierten Abwicklung von Geschäftsprozessen. Eine allgemeine Implementierungsarchitektur von Geschäftsprozessen orientiert sich am Referenzmodell der Workflow Management Coalition Organisation zur Standardisierung und Verbesserung von Workflow-Management-Systemen. In dieses Modell lassen sich die aktuellen Konzepte für Service-Architekturen integrieren. In der Regel wird in Prozessen das ganze Spektrum von ITTechnologien zum Einsatz kommen. Um dies zu ermöglichen, empfiehlt es sich, Geschäftsprozesse in entsprechende Abschnitte zu zerlegen, wobei jeder Abschnitt mit Hilfe der dafür geeigneten Technologie oder Workflow Engine implementiert werden sollte. Verschiedene Hersteller bieten Plattformen an, welche die oben beschriebenen Konzepte unterstützen. Geeignete Standards wie beispielsweise Web-Services verbinden diese Technologieplattformen miteinander. Bei der Implementierung von Prozessen kommt es darauf an, den Prozessablauf, die IT-Unterstützung, die Organisation und die Anwender zu integrieren. Die Prozessbeschreibung legt fest, welche Rollen, Zuständigkeiten und Aktivitäten am Prozess beteiligt sind. Mit Hilfe von Kontrollfunktionen wird die Ausführung der im Prozess definierten Aktionen festgelegt. Die Aktionen selbst werden durch Menschen und/oder Anwendungssysteme gemäß einer festgelegten Reihenfolge ausgeführt. Abbildung 68 zeigt die drei wesentlichen Aspekte für die Realisierung von Geschäftsprozessen.

141

7

IT-Unterstützung: Prozesse erfolgreich implementieren

Bei der Einbettung eines Prozesses in die Organisation ist zu beachten, dass die Umsetzung der in der Geschäftsprozessbeschreibung festgelegten Verantwortlichkeiten durch entsprechende IT-Methoden und Technologien sehr komplex sein kann. Daher sollten mit dieser Aufgabe Experten betraut werden. Hierdurch wird vermieden, dass beispielsweise Kollisionen zwischen unterschiedlichen Inkarnationen von Prozessen auftreten. Die Abhängigkeiten zwischen Beschreibungsmethoden, Lösungsplattformen und IT-Infrastrukturen müssen immer im Zusammenhang betrachtet werden. Im folgenden Kapitel werden wir an einem konkreten Praxisbeispiel zeigen, wie ein Prozess von der Zielvorgabe über die Gestaltung bis zur IT-gestützten Durchführung durchgängig implementiert wird. In dieser Fallstudie greifen wir die Aufgaben der Kapitel 3 bis 7 auf und geben Lösungshinweise. Aus den Projekterfahrungen und -ergebnissen eines betrieblichen Projektes „Geschäftsprozesse realisieren“ wurde diese durchgängige Fallstudie von den Autoren entwickelt.

142

7.6

7.6

Aufgabe zur Prozess-Implementierung (Teil 5)

Aufgabe zur Prozess-Implementierung (Teil 5) Checkliste: x

Wie würde eine Realisierung der Fallstudie als reine Orchestrierung aussehen?

x

Welcher Implementierungsansatz erleichtert ein späteres Outsourcing von Funktionen?

x

Wann würden Sie zur Implementierung eines Subjekts eine Worklist verwenden und unter welchen Bedingungen einen BPEL-Ansatz?

) Hinweise zur Lösung dieses Gestaltungsschrittes finden Sie im Abschnitt 8.5.

143

8

Fallstudie Im abschließenden Kapitel 8 werden wir das Fünf-EbenenModell zur Realisierung von Geschäftsprozessen anhand einer Fallstudie schrittweise darstellen. Wir zeigen, wie, ausgehend von der Unternehmensstrategie, ein Prozess identifiziert, dokumentiert, umgesetzt und überwacht wird. Das Beispiel stammt aus einem realen Projekt, jedoch wurden Branche und Parameter verändert.

8.1

Strategische Gestaltung

Ausgangslage

Nehmen wir an, ein Finanzdienstleister will seine Geschäftsaktivitäten ausweiten und gezielt 120.000 Neukunden für eine Kontoeröffnung gewinnen. Die Kunden sollen zudem ein bestimmtes Profil aufweisen, kreditwürdig sein und aus dem „PremiumSegment“ stammen. Aus Kapazitätsgründen will man zur Gewinnung der Neukunden das Vertriebsnetz eines Partnerunternehmens nutzen. Dazu soll ein Neukundenprozess beschrieben werden, der es erlaubt, dem Kunden jederzeit Auskunft über den Bearbeitungszustand seiner Kontoeröffnung zu geben. Der Prozess soll mit dem verfügbaren Personal und der vorhandenen IT durchgeführt werden. Außerdem soll ein geeignetes Monitoring Ineffizienzen des Prozesses frühzeitig aufzeigen, um sofort steuernd eingreifen zu können.

Strategisches Modell

Zur Darstellung und Umsetzungsplanung der Strategie wird in dem Unternehmen die Balanced Scorecard eingesetzt. Die folgende Tabelle zeigt einen Auszug davon.

145

8

Fallstudie Tabelle 8: Auszug einer Balanced Scorecard

Prozesstypisierung

146

Sicht

Ziel

Kennzahl

Finanz-Sicht

Durch Gewinnung neuer Kunden sollen Umsatz und Marktanteil erhöht werden.

120 000 neue Kunden im kommenden Geschäftsjahr

Kunden-Sicht

Die Kunden sollen entsprechend dem anvisierten Premiumsegment jederzeit über den Bearbeitungszustand ihrer Wünsche informiert werden.

Kundenanfragen bezüglich des Bearbeitungsstandes können sofort zur Kundenzufriedenheit erledigt werden.

Prozess-Sicht

Es werden entsprechende Geschäftsprozesse entwickelt.

Im laufenden Geschäftsjahr wird als Schwerpunkt der Prozess zur Kontoeröffnung entwickelt.

Ressourcen-Sicht

Existierende Anwendungen sollen aus Kostengründen in den jeweiligen Prozessen verwendet werden. Nur bei signifikanten Kostenvorteilen werden die Anwendungen in den Workflow vollständig integriert.

IT-Investitionen werden nur durch den Nachweis des Nutzens getätigt. Dieser Nutzen ist durch Messungen am Prozess zu belegen.

Die Strategie gibt als Ziel vor, eine große Zahl von Neukunden in dem eher konservativen Markt des Finanzdienstleisters zu erschließen. Dies ist ein ambitioniertes Wettbewerbsziel. Daher ist der Prozess primär ein wettbewerbsorientierter Prozess. Die hohen Ansprüche an die Qualität des Ergebnisses und an die schnelle Umsetzung rechtfertigen beim Geschäftsprozessmanagement die Anwendung die Methodik „Prozesse erleben“.

8.2

Vorgabe an das Prozesscontrolling

8.2

Anforderung an die Prozess-Struktur

Entsprechend der Balanced Scorecard werden die notwendigen Prozesskennzahlen festgelegt: x

Finanz-Sicht: 120.000 Neukunden

x

Kunden-Sicht: Prozentsatz der Kunden, die den Bearbeitungszustand der Kontoeröffnung am Telefon erfahren

x

Prozess-Sicht: Termintreue des Einführungsprojektes

x

Ressourcen-Sicht: Klare Effizienz-, Kosten-, und Nutzennachweise

Anforderung an die Prozess-Struktur Entsprechend den strategischen Vorgaben durch die Balanced Scorecard muss zunächst der Prozess zur Bearbeitung von Kontoeröffnungen definiert werden. Aufgrund der internen Kenntnisse entscheidet man sich für ein flussorientiertes Architekturprinzip, mit dessen Hilfe der Prozess strukturiert werden soll. Es stehen Funktionen und Aufgaben in einer ablauforientierten Betrachtungsweise im Vordergrund. Abbildung 69 zeigt einen Ausschnitt des Prozesses „Kontoanlage“. Dieser Prozess wurde im ersten Schritt flussorientiert mit Hilfe von erweiterten ereignisgesteuerten Prozessketten (eEPK) beschrieben. In die eEPKs können bereits die Messpunkte für das Monitoring der Prozessausführung eingearbeitet werden. Beispielsweise soll gemessen werden, ob die Kundenunterlagen vollständig sind und wie lange es vom Eintreffen der Unterlagen bis zum Abschluss der Prüfung dauert.

147

8

Fallstudie

An dem Prozess der Kontoeröffnung sind, neben dem Kunden, der Finanzdienstleister und sein Partnerunternehmen beteiligt. Für beide Organisationen müssen parallele Abläufe geschaffen werden, die miteinander kommunizieren. Die Darstellungsweise als eEPK zeigt Grenzen auf, da sie flussorientiert ist und nicht die Subjekte des Prozesses in den Mittelpunkt stellt. Die Prozessbeschreibung wird deshalb im nächsten Schritt optimiert. 148

8.3

8.3

Optimierung der Prozessbeschreibung

Optimierung der Prozessbeschreibung Der Prozess wurde bisher als eEPK beschrieben, sie verdeutlichen den Ablauf eines Prozesses und können als Vorgabe dienen, die Prozesse später mit Unterstützung von IT zu automatisieren. Dabei handelt es sich (vgl. Abschnitt 5.4) um eine halbformale, flussorientierte Beschreibungsmethode. Jedoch haben eEPKs ihre Grenzen, wenn die Prozesse aus der Sicht der Beteiligten erlebbar sein sollen. Deshalb werden die eEPKs nun in eine subjektorientierte Beschreibung überführt. Es müssen die an einem Prozess beteiligten Rollen identifiziert werden. Diese Informationen können aus der vorliegenden Prozessbeschreibung (eEPK) extrahiert werden. Das betrifft vor allem das Verhalten, wenn die Subjekte Nachrichten austauschen, um sich zu koordinieren. Mit einem Softwarewerkzeug (jPASS!) werden die eEPKs automatisch in eine subjektorientierte Darstellung transformiert. Dies funktioniert umso besser, je präziser die eEPKs definiert sind. Es wurde beispielsweise in der eEPK eine Funktion „Kunden über fehlende Unterlagen informieren“ modelliert. Da es in der ursprünglichen eEPK-Beschreibung keine Rolle „Kunde“ gibt, die als Aufgabenträger einer Funktion dient, wird in jPASS! das Subjekt „Kunde“ manuell ergänzt. Im Prozess „Konto anlegen“ gibt es somit vier Prozessrollen (Subjekte): x

Kunde

x

Vertriebsagentur

x

Zentrale

x

Verwaltungssystem

Die Zentrale und die IT-Systeme der Zentrale führen die eigentliche Prüfung durch. In diesem Fall werden die Systeme nicht als Objekt betrachtet, das vom Subjekt „Zentrale“ benutzt wird, sondern als eigenes Subjekt. Damit wird eine lose Bindung der Anwendungen an die Zentrale beschrieben. Abbildung 70 zeigt die Subjekte und die zwischen ihnen ausgetauschten Nachrichten.

149

8

Fallstudie

Für jedes Subjekt wurde das Verhalten aus der eEPK extrahiert. Abbildung 71 zeigt exemplarisch einen Ausschnitt des Verhaltens der Zentrale. Diese erhält die Kontounterlagen von der Vertriebsagentur und werden dort auf Vollständigkeit geprüft. Abhängig vom Ergebnis dieser Prüfung unternimmt die Zentrale den nächsten Schritt:

150

x

Sind die Unterlagen nicht vollständig oder stark fehlerhaft, wird zunächst das Subjekt „Verwaltungssystem“ über die formalen Mängel informiert. Anschließend erhält die Vertriebsagentur eine Nachricht. Die Bearbeitung wird dann so lange unterbrochen, bis die ergänzenden Informationen vorliegen.

x

Bei leichten Mängeln wird lediglich die Vertriebsagentur informiert. Die Bearbeitung wird fortgesetzt.

x

Liegen keine Mängel vor, wird sofort mit den weiteren Bearbeitungsschritten fortgefahren.

8.3

Optimierung der Prozessbeschreibung

Die so transformierte Prozessbeschreibung kann nun sofort erlebt werden (siehe Kapitel 6). Abbildung 72 zeigt für jedes am Prozess beteiligte Subjekt ein Dialog-Fenster. Durch dieses Fenster kann der jeweilige am Prozess Beteiligte seine Sicht auf den Prozess erleben. Er sieht, zu welchem Zeitpunkt er seine Aufgaben im Rahmen dieses Prozesses erledigen muss.

151

8

Fallstudie

8.4

Prozessimplementierung Gemäß der Anforderung aus der Balanced Scorecard soll der Prozess Kontoanlage so implementiert werden, dass er kontrolliert werden kann. Es soll, wo möglich, eine vollautomatisierte Realisierung erfolgen. Im ersten Schritt ist eine worklist-orientierte Implementierung vorgesehen. Sie erlaubt es, den Kunden jederzeit über den Bearbeitungsstand zu informieren und die benötigte Zeit zur Prozessbearbeitung zu messen. Basierend auf diesen Werten sollen dann einzelne Bearbeitungsschritte automatisiert werden.

Einfügen weiterer Informationen

152

Nach der Umsetzung der eEPK in die über jLIVE! erlebbare jPASS!-Darstellung ist bereits ein erster Schritt für die Implementierung des Prozesses getan. Um eine worklist-orientierte Implementierung zu realisieren, wird die jPASS!-Beschreibung nun um folgenden Prozessinformationen angereichert: x

Daten, die beim Austausch von Nachrichten übertragen werden,

x

Aufgaben eines Subjektes in einem Prozess (Rollendefinitionen),

8.4 x

Prozessimplementierung

Einordnung des Prozesses und der Rollen in die Organisation. Damit wird auch festgelegt, welche Organisationseinheiten bestimmte Subjektaufgaben wahrnehmen.

Einbettung der Subjekte in die Organisation

Eine große Herausforderung an die Implementierung von Prozessen ist das unterschiedliche Verhalten von Subjekten in verschiedenen Organisationseinheiten. Im vorliegenden Fall gibt es die Organisationen „NORD“, „SÜD“ und „OST“ mit jeweils vier Niederlassungen und „WEST“ mit nur einer Niederlassung. Zwar sind die Prozesse in allen Organisationen gleich, jedoch haben sie unterschiedliche Eigenschaften.

Rollenkonzept

Diese Herausforderung wird durch ein Rollenkonzept gelöst. Jedes Subjekt nimmt eine prozessbezogene Rolle ein, die einer oder mehreren Organisationseinheiten oder Stellen zugewiesen werden kann. Das entspricht den Anforderungen, wenn ein Prozess mehrere Organisationseinheiten betrifft. Für unser Beispiel sind drei Rollen erforderlich: x

Administrator

x

Angestellter

x

Management

Abbildung 73 zeigt die Definition der Rollen.

153

8

Fallstudie

Die Rollen „Administration“ und „Angestellter“ werden von den Niederlassungen wahrgenommen, während die Rolle Management nur in den Vertriebsbereichen vorkommt. In jPASS! können die Rollen einer Organisation zugeordnet werden. Das Ergebnis der Eingaben ist in Abbildung 74 dargestellt..

154

8.4

Prozessimplementierung

Im letzten Schritt werden die Subjekte des Prozesses den jeweiligen Rollen zugeordnet. Da die Rollen bereits in das Organigramm eingeordnet sind, ist nun der Prozess in der Organisation verankert. Kontext

Zusätzlich wird noch ein Kontext hinterlegt. Er legt fest, welche Rollen beziehungsweise Organisationszuordnungen ein Subjekt verwenden kann. Damit wird beispielsweise vermieden, dass eine Prozessinstanz des Prozesses „Kontoeröffnung“ im Vertriebsbereich „SÜD“ für das Subjekt „Zentrale“ die Rolle Management benutzt, die in der Organisation „NORD“ platziert ist. Der Kontext legt für eine Prozessinkarnation fest, wo die einzelnen Subjekte dieser Inkarnation in der Organisation platziert sind. Die zugehörige Maske in jPASS! zur Definition des Kontextes zeigt Abbildung 75.

155

8

Fallstudie

Überführung in ein WorklistSystem

Die Prozessdefinition wird noch mit allen notwendigen Informationen angereichert und kann dann zur Prozessausführung verwendet werden. Zur Ausführung wird die jPASS!-Beschreibung in das Workflowsystem jFLOW! übernommen. jFLOW! übernimmt die Prozessausführung. Dabei werden die Worklists für jede Prozessinkarnation erstellt, welche die möglichen Aktionsfolgen gemäß der Prozessdefinition zulassen.

Das Worklist-System legt fest, in welcher Reihenfolge die einzelnen Arbeiten für die Kontoeröffnung auszuführen sind. Damit wird die Eröffnung von Konten ausgeführt, gesteuert, überwacht und verbessert. Prozessausführung

Soll ein neues Konto eröffnet werden, muss der Bearbeiter das Anlegen einer Prozessinstanz initiieren. Hierfür wählt er den Prozessnamen „Kontoeröffnung“ (siehe Abbildung 76), entscheidet sich für einen Kontext (Einordnung der Prozessinkarnation in die Organisation) und eine Priorität, die diese Prozessinkarnation haben soll. Optional kann eine kurze Bezeichnung der Prozessinstanz angegeben werden. Diese kann als eine Art Aktenzeichen verwendet werden. Bei der Kontoeröffnung empfiehlt es sich, den Nachnamen des Neukunden als Aktenzeichen zu verwenden. Dies erleichtert das Finden des entsprechenden Vorgangs, wenn der Kunde später wissen will, in welchem Zustand die Bearbeitung seiner Kontoeröffnung ist. Nach dem Drücken des Start-Buttons wird die Prozessinstanz in die Worklist im linken Bildschirmbereich aufgeführt. In der Liste sieht der Benutzer alle für ihn freigegebenen Bearbeitungsschritte, wobei der aktuelle Zustand mit einem kleinen Auge gekennzeichnet ist.

156

8.4

Prozessimplementierung

Klickt man nun auf diesen aktuellen Zustand, so wird im Hauptfenster der Prozessablauf sowohl in schriftlicher als auch in grafischer Form dargestellt. Abbildung 77 zeigt den Bearbeitungszustand der ausgewählten Prozessinstanz. Der aktuelle Zustand, in Abbildung 77 ist es der zweite von oben, ist in der Ablaufbeschreibung farbig hinterlegt. Links neben der Grafik sind im Feld „Tätigkeiten“ die im aktuellen Zustand auszuführenden Tätigkeiten genauer beschrieben. In unserem Beispiel müssen nun die Kontounterlagen auf formale Richtigkeit geprüft werden. Dies geschieht manuell, da die Unterlagen in Papierform vorliegen. Ist die Prüfung abgeschlossen, werden im Feld „Mögliche Aktionen“ eines der möglichen Ergebnisse angegeben. In unserem Beispiel zeigt sich, ob die Kontoeröffnung leichte, schwerwiegende oder keine formale Mängel aufweist. Damit wird der Nachfolgezustand mit den Nachfolgeaktionen definiert.

157

8

Fallstudie

Durch Anklicken der einzelnen Tabellenreiter in der rechten Fensterhälfte werden verschiedene Informationen – zum Beispiel über die am Prozess Beteiligten und über notwendige Parameter angezeigt. Abbildung 77 zeigt, dass der Anwender sich gerade darüber informiert, in welchen Zustand er sich befindet. Dazu wird die entsprechende Verhaltensbeschreibung, wie sie in jPASS! verwendet wird, angezeigt.

8.5

Einbinden existierender Programme Die aus der subjektorientierten Prozessbeschreibung abgeleitete Worklist unterstützt den Benutzer bei der Abarbeitung von Kontoreröffnungsanträgen. Es müssen die einzelnen Schritte hintereinander ausgeführt werden. Soll beispielsweise eine SchufaPrüfung durchgeführt werden, wird diese vom Benutzer aufgerufen und ausgeführt. Zur schnelleren Bearbeitung von Kundenaufträgen kann dieser Schufa-Aufruf in den Workflow integriert und von diesem automatisch angestoßen werden. Die Kundendaten, die für die Schufa-Anfrage benötigt werden, werden in den oben beschriebenen Work List-Parametern erfasst. In unserem Beispiel wird die Schufa-Auskunft über die Middleware MQ-Series eingeholt. Nach dem Eintreffen der Antwort wird abhängig vom Ergebnis automatisch der Nachfolgezustand ausgewählt.

158

8.6

8.6

Messen und Bewerten

Messen und Bewerten Die Effizienz des Prozesses wird laufend anhand der Zahl der Kontoeröffnungen und der für die Bearbeitung der Anträge benötigten Zeit gemessen. Dazu wird das Werkzeug PPM (Process Performance Manager) der Firma IDS-Scheer verwendet. Der PPM wird beispielsweise bei jeder Kontoeröffnung darüber informiert, wenn ein Bearbeiter eine Aktivität begonnen oder beendet hat. Aus diesen und anderen Rohdaten erstellt der PPM für die jeweiligen Managementebenen die entsprechenden Informationen. Diese werden grafisch angezeigt. Abbildung 78 zeigt ein Beispiel, wie die Messdaten für Prozessabläufe aufbereitet werden können.

Das Management kann beispielsweise daraus erkennen, in welchen Regionen das Programm zur Gewinnung von Neukunden besonders erfolgreich ist. Ebenso lassen sich leicht Rückschlüsse auf die Wirksamkeit von Werbemaßnahmen oder auf Aktionen des Mitbewerbs ziehen, und das Management kann rasch auf neue Situationen reagieren.

159

8

8.7

Fallstudie

Zusammenfassung In dieser Fallstudie wurde gezeigt, wie, ausgehend von einer in der Balanced Scorecard definierten Strategie, schrittweise eine ITgestützte Abwicklung des Kontoeröffnungsprozesses entwickelt wurde. Nach einer groben Definition des Prozesses in Form einer eEPK wurde der Prozess weitgehend automatisch in eine subjektorientierte Form transformiert. Anschließend konnten die Beteiligten den Prozess testen, was zu einigen Verbesserungen führte. So konnte der Prozess mit zusätzlichen Informationen angereichert und korrekt in die Organisation eingeordnet werden. Aus dieser Prozessbeschreibung wurde anschließend automatisch die Worklist-Anwendung generiert. In diese Worklist wurde zur Verbesserung der Arbeitsgeschwindigkeit ein automatischer Aufruf zur Feststellung des bisherigen Finanzverhaltens der Neukunden eingebaut. Zuletzt wurde der Prozess in ein bestehendes Softwaresystem zur Auswertung von Performance-Daten integriert.

8.8

Aufgabe zur Fallstudie Checkliste:

160

x

Kann der Prozess mit „Papier und Bleistift“ umgesetzt werden?

x

Welche Vorteile hat die worklist-orientierte Umsetzung des Beispieles gegenüber einer „Papier und Bleistift“Lösung?

x

Welche Probleme müssen bei der Einordnung eines Prozesses in eine Organisation gelöst werden?

x

Welche Messungen sind für dieses Beispiel sinnvoll, um die Prozesseffizienz zu steigern?

x

Welche Verbesserungsmöglichkeiten bezüglich der Effizienz könnten noch eingebaut werden?

9 9.1

Checklisten Einleitung Die Checklisten dienen als Gedankenhinweise und Arbeitsanleitung für die praktische Arbeit. Diese Frage- und Aufgabenstellungen haben die Autoren in zahlreichen Praxisprojekten gesammelt. Die Leserinnen und Leser dieses Buches werden ermutigt ihre eigenen firmenspezifische Erfahrungen zu ergänzen.

9.2

Prozessüberblick x

Verschaffen Sie sich einen Überblick über die Unternehmensprozesse. x

Erstellen Sie eine Prozesslandschaft.

x

Kennzeichnen Sie Kernprozesse und unterstützende Prozesse.

x

Grenzen Sie den betrachteten Prozess sauber ab.

x

Bestimmen Sie die Verankerung des Prozesses in der Organisation.

x

Bestimmen Sie die Schnittstellen nach außen zu anderen Organisationen.

161

9

9.3

9.4

162

Checklisten

Prozessanalyse x

Sprechen Sie mit Ihrem Auftraggeber Ihre Ziele ab und machen Sie sie bekannt.

x

Bestimmen Sie das Prozess-Ziel.

x

Bestimmen Sie den Anstoß des Prozesses.

x

Bestimmen Sie den Empfänger des Prozessergebnisses.

x

Ermitteln Sie den Prozess-Owner.

x

Ermitteln Sie weitere Prozessbeteiligte.

x

Stellen Sie aus den Beteiligten ein Prozessteam zusammen.

Vorbereitung der Prozessmodellierung x

Entscheiden Sie frühzeitig, welche Prozessdarstellung in der Organisation am ehesten passt.

x

Suchen Sie ein geeignetes Werkzeug zur Prozessmodellierung.

x

Stellen Sie in der Organisation hinreichende Akzeptanz her.

9.6

9.5

Prozessoptimierung

Prozessaufnahme x

Gehen Sie systematisch vor.

x

Gehen Sie dabei nicht zu sachlich vor, vermeiden Sie den Eindruck eines Verhör.

x

Planen Sie workshops und denken Sie hierbei an Moderationsregeln o

Termin und Raum festlegen

o

Flip-Chart, Pin-Wände, Papier, Stifte, Beamer etc. vorbereiten

o

...

x

Beschreiben Sie die Prozesse auf verschiedenen Detaillierungsebenen und Sichten.

x

Überprüfen Sie die aufgenommenen Prozesse auf ihre korrekte Darstellung.

x

Achten Sie hierbei auf verschiedene Prozessarchitekturen.

x

Fragen Sie gezielt nach Ausnahmen und Störungen. Diese bringen in der Regel „saubere“ Prozesse durcheinander.

x

Messen Sie, soweit möglich, Quantität und Qualität der Prozesseffizienz.

x

Wenn möglich, machen Sie die Prozesse unmittelbar erlebbar.

x

Veröffentlichen Sie die Prozesse bei den Prozessbeteiligten und holen Sie deren Rückmeldung ein. 163

9

9.6

9.7

164

Checklisten

Prozessoptimierung x

Bestimmen Sie Potentiale, bei welchen Prozessen eine Optimierung Sinn macht.

x

Arbeiten Sie hierbei nach der 80:20-Regel – mit wenig Aufwand viel erreichen!

x

Regen Sie gegebenenfalls ein Neudesign vorhandener Strukturen an.

x

Modellieren Sie den zukünftigen Prozess und machen Sie diesen erlebbar.

x

Erklären Sie hierbei im Besonderen die zukünftige Rolle der Subjekte.

x

Stellen Sie die neuen Prozesse den Prozessbeteiligten vor und holen Sie die Akzeptanz ein.

x

Lassen Sie sich den neuen Prozess von den Verantwortlichen freigeben.

Prozesse einführen x

Beschreiben Sie die technische Unterstützung des Zielprozesses und implementieren Sie ihn bzw. geben Sie ihn in Auftrag.

x

Bereiten Sie das „Change Management“ im Detail vor.

x

Legen Sie einen Prozessverantwortlichen fest, sofern dies noch nicht geschehen ist.

9.7

Prozesse einführen

x

Entscheiden Sie sich, ob Prozessteile in Schritten oder komplett umgesetzt werden sollen.

x

Legen Sie Kriterien oder Kennzahlen fest, anhand derer der Erfolg der Umsetzung überprüft werden kann.

x

Bewerten Sie abschließend auch, was Sie in dem Projekt gelernt haben („lessons learned“) und dokumentieren Sie dies für weitere Projekte.

165

Literaturverzeichnis [Ba02] Backschat M., Gardon O., Enterprise Java Beans, Spektrum Akademischer Verlag, Heidelberg 2002 [En02] Engel A., Koschel A., Tritsch R., J2EE kompakt, Spektrum Akademischer Verlag, Heidelberg 2002 [Fl94] Fleischmann Albert: Distributed Systems – Software Design & Implementation, Springer-Verlag, 1.Auflage, 1994 [Ga00] Gappmaier M., Heinrich L.J.: Geschäftsprozesse mit menschlichem Antlitz, Universitätsverlag Rudolf Trauner, 2.Auflage, 2000 [Ga02] Gadatsch Andreas: Management von Geschäftsprozessen, vieweg-Verlag, 2.Auflage, 2002 [Ham94] M. Hammer, J. Champy, Business Re-Engineering, Campus Verlag, Frankfurt (1994) [Ha03] Hart J., Connecting your Applications without complex programming, www.ibm.com, Internet 2005 [Hoa85] C.A.R. Hoare, Communicating Sequential Processes, Prentice Hall, Englewood Cliffs 1985 [In04] Magazin IndustrieManagement 20, Thema Wandlungsfähigkeit, 2004 [Kap97] R.S. Kaplan, D.P. Norton, Balanced Scorecard. Strategien erfolgreich umsetzen, Schäffer-Poeschel Verlag, Stuttgart 1997 [Ka00] Kamiske G.F. (Hrsg.), Der Weg zur Spitze, Hanser Verlag, München 2000 [Ka05] Karch S., Heilig L., SAP-Netweaver Roadmap, Galileo Press, Bonn 2005 167

[Ku02] Kuschke M., Wolfel L., Web-Services kompakt, Spektrum Akademischer Verlag, Heidelberg 2002 [Mi02] Mielke Carsten: Geschäftsprozesse, Spektrum Akademischer Verlag, 1.Auflage, 2002 [Ne05] Newcomer E., Lomow G., Understanding SOA with Web-Services, Addison Wesley Verlag, 2005 [Oe03] Oesterreich Bernd et.al.: Objektorientierte Geschäftsprozessmodellierung mit der UML, dpunkt.verlag, 1.Auflage, 2003 [OMG] Open Management Group; www.omg.org/mda/, Internet 2005 [Or05] Ort E., Service-Oriented Architecture and Web-Services: Concepts, Technologies and Tools; www.sun.com , Internet 2005 [Ös95] ÖSTERLE (1995)] Business Engineering. Prozess- und Systementwicklung [Pe03] Peltz C., Web-Service Orchestration, A Review of emerging technologies, tools and standards, Hewlett Packard 2003, HTTP://devresource.hp.com/drc/technical_white_papers/WSOrch/WSOrchestration.pdf,

Internet 2005

[Pf01] Pfeifer T., Qualitätsmanagement, Strategien Methoden Techniken, Hanser Verlag, 3. Auflage, München 2001 [Ri04] Richter-von Hagen Cornelia et al.: Business-Process- und WorkflowManagement, Teubner-Verlag, 1.Auflage, 2004 [Ru99] Rump Frank J.: Geschäftsprozessmanagement auf der Basis ereignisgesteuerter Prozessketten, Teubner-Verlag, 1.Auflage, 1999 [Ru05] Rupp Chris et.al.:UML2 glasklar, Hanser Verlag, 2.Auflage, 2005 168

[Sc02] Scheer A.W., ARIS – Von Geschäftsprozess zum Anwendungssystem, Springer Verlag 4. Auflage, Berlin 2002 [ScJo96] SCHEER/JOST (1996)] [Sc98] Scheer A.-W.: ARIS – Vom Geschäftsprozess zum Anwendnungssystem, Springer-Verlag, 1.Auflage, 1998 [Se02] Seidlmeier Heinrich: Prozessmodellierung mit ARIS, vieweg Verlag, 1.Auflage, 2002 [Sm02] Schmelzer H. J., Sesselmann W, Geschäftsprozessmanagement in der Praxis, Hanser Verlag 2. Auflage, München 2002 [St05] /Artikel Steinmetz TU Darmstadt2005 Seite 2/ [St05] Starke Gernot: Effektive Software-Architekturen, Hanser Verlag, 2.Auflage, 2005 [Su05] Stumpe J. Orb J., SAP Exchange Infrastructure, Galileo Press, Bonn 2005 [Wa98] Günter Wahl: UML kompakt, OBJEKTspektrum 2/1998 [Wa01] Wackerow D., Adam W., Burton D., MQSeries Workflow for Windows NT for Beginners, Red Book, IBM 2001 [We02] Westphal R., .NET kompakt, Spektrum Akademischer Verlag, Heidelberg 2002 [WM] Reference Modell for Workflow Management systems /HTTP://www.wfmc.org/standards/model.htm/, internet 2005 [w302] Web-Services Choreography Working Group, ,HTTP://www.w3.org/2002/ws/chor/, internet 2005 [Wo04] Woods D., Word J., SAP Netweaver for Dummies, Wiley Publishing Inc.,2004 169

Schlagwortverzeichnis

A Ablauf 8, 11, 22, 74, 76, 80, 110, 117, 120, 149 Ablauforganisation 3, 10, 11, 22 Akteure 38, 53, 54, 55, 59, 74, 76, 78 Aktivitäten 6, 8, 9, 10, 23, 24, 37, 55, 76, 108, 109, 121, 124, 127 Anwendung 19, 20, 54, 82, 84, 85, 92, 107, 110, 131, 135, 137, 160 Anwendungssoftware 8, 110, 141 Anwendungssystem 11, 126, 169 Architektur 18, 36, 45, 46, 48, 56, 59, 77, 78, 116, 117, 118, 128, 132, 138, 140 Architekturprinzipien 45, 46, 59, 60 Aufbauorganisation 1, 2, 3, 10, 11, 12, 18, 22, 45, 122, 123 Aufgaben 1, 4, 11, 21, 24, 28, 38, 43, 48, 50, 86, 87, 89, 102, 103, 105, 107, 109, 117, 122, 129, 147, 151, 152

B Balanced Scorecard 28, 29, 30, 32, 145, 146, 147, 152, 160, 167 benchmarking 42 BPEL 124, 125, 128, 134, 136, 139 BPR 21 Business Reengineering 21, 32, 167

C change-sensitive Prozesse 33 Change-sensitives Geschäftsprozessmanagement 35

Choreographie 118, 119, 120, 121, 122, 123, 127, 129

D Deming-Cycle 25

E eEPK 69, 148, 149, 150, 152, 160 Effektivität 12, 28, 40, 89, 91, 92, 93, 97, 102 Effizienz 12, 24, 28, 32, 40, 41, 89, 92, 93, 102, 116, 160 EFQM 18, 26, 27, 28, 31, 32 EJB 131, 132 Enterprise Java Beans 131, 167 Enterprise Service Architektur 138 EPK 50, 69, 72, 76 Ereignisgesteuerte Prozesskette 50 Erfolgsfaktoren 22

F Fünf-Ebenen-Modell 17

G Geschäftsprozesse 1, 10, 15, 17, 18, 19, 20, 21, 38, 42, 43, 45, 46, 47, 49, 55, 59, 63, 65, 66, 68, 73, 76, 78, 84, 85, 87, 92, 93, 95, 105, 110, 137, 138, 141, 146, 167, 168 Geschäftsprozessmanagement 16, 31, 33, 34, 35, 37, 38, 39, 42, 43, 146, 168 Geschäftsvorgänge 12

171

I

N

ISO 9000:2000 22 IT-System 11, 19, 22, 38, 39, 94 IT-terminierte Prozesse 33 IT-terminiertes Geschäftsprozessmanagement 37

.NET 130, 132, 133, 134, 135, 140, 169 Netweaver 138, 167, 169

J

Objekt 54, 79, 80, 85, 149 objektorientiert 133 Orchestrierung 110, 118, 119, 121, 122, 123, 124, 127, 129, 136, 146 Organisation 2, 6, 7, 9, 10, 11, 22, 24, 25, 26, 68, 72, 80, 108, 111, 120, 122, 123, 137, 141, 153, 154, 155, 156, 160 Organisationseinheit 7, 10, 11, 51, 80, 111, 123, 153 Organisationsorientiertes Geschäftsprozessmanagement 39

J2EE 130, 134, 135, 136, 167 Java 114, 128, 130, 133, 136, 167 jLive! 95 jPASS! 111, 121, 149, 152, 154, 155

K Key Performance Indicators 41 Kosten 11, 25, 40, 41, 47, 48, 49, 72, 93, 147 KPI 41

M MDA 126 Messen 23, 24, 40, 159 Messgrößen 30 Messung 32 Methoden 22, 24, 31, 32, 34, 39, 49, 54, 55, 79, 89, 102, 116, 123, 126, 142, 168 Methodik 32, 33, 35, 36, 38, 40, 146 middle tier 131 Mission 29, 30 Modell 15, 16, 17, 19, 20, 24, 26, 27, 28, 30, 48, 120, 126, 141, 145, 169 MQ-Series 137, 140, 158 Multi-Tier 130, 131, 132 MUST-Prozess 36

172

O

P Parallelität 52, 55, 59, 76 Plan-Do-Check-Act 25, 26 Prozess 45, 48, 56, 58, 146, 147 Prozessablauf 8, 53, 90, 91, 92, 141 Prozessarchitektur 18, 23, 46, 47, 49, 55 Prozessbeschreibung 7, 8, 18, 42, 47, 48, 63, 65, 69, 71, 72, 74, 75, 76, 77, 79, 80, 84, 85, 89, 90, 91, 92, 95, 97, 103, 105, 119, 123, 124, 141, 149, 151 Prozessbeteiligte 39, 56, 57, 59, 78, 101 Prozesscontrolling 40, 42 Prozesse 48, 149 Prozessketten 31, 51, 53, 54, 69, 72, 168 Prozesskosten 40 Prozessmodell 23, 24, 52, 53, 113 Prozessstatus 12 Prozesstypen 33, 34, 41, 43

Q

Vision 29, 30

Qualität 18, 25, 34, 41, 47, 48, 84, 89

W

R

Web-Dienste 134 Web-Services 124, 128, 132, 134, 135, 136, 141, 168, 169 Wettbewerbsorientiertes Geschäftsprozessmanagement 34 wettbewerbsrelevanter Prozess 33 WfMC 108, 109, 117, 118 Wissen 34, 36, 37, 38, 39, 116 wissensintensiver Prozess 34 Wissensorientiertes Geschäftsprozessmanagement 37 Work Breakdown Structure 2 Workflow 11, 12, 33, 107, 108, 109, 110, 115, 116, 117, 118, 119, 120, 125, 128, 131, 141, 146, 158, 168, 169 Worklist 107 WSDL 118, 125, 134, 135

RADAR 27 Rolle 33, 47, 49, 51, 53, 54, 59, 72, 84, 120, 134, 149, 153, 154, 155

S serviceorientierte Architekturen 117 Six Sigma 31, 32, 40 SOA 116, 117, 118, 134, 136, 168 SOAP 118, 134, 135 Stellen 51, 153 Strategie 15, 16, 18, 30, 32, 38, 42, 43, 53, 90, 145, 146 Subjekt 79, 80, 81, 82, 83, 85, 97, 100, 111, 114, 127, 128, 149, 150, 151, 153, 155

X

T

XML 111, 134, 135

Three-Tier 131 Total Quality Management 24, 27 TQM 24, 25, 26, 32

Z Zombie-Prozess 34

U UDDI 118, 134, 135 UML 73, 75, 76, 77, 78, 81, 92, 116, 125, 126, 168, 169 Unternehmensstrategie 15, 24, 33, 35

V Verbesserungsprozess 25

173

Über die Autoren

Herbert Fischer Prof. Dr.-Ing Herbert Fischer lehrt im Bereich Modellierung, Softwareentwicklung und Anwendungssysteme an der Fachhochschule Deggendorf im Studiengang Wirtschaftsinformatik. Er leitet das Institut für modellbasierte Softwareentwicklungsprozesse (BayTech IMSWEP). In zahlreichen Praxisprojekten mit Industrieunternehmen und Behörden berät er den Einsatz von Modellierungsmethoden bei der Einführung von Individual- und Standardsoftware. Albert Fleischmann Dr.-Ing. Albert Fleischmann ist einer der Vorstände der jCOM1 AG, welche sich in erster Linie als innovativer Lösungsanbieter für das Geschäftsprozessmanagement am Markt etabliert hat. Stefan Obermeier Dipl.-Inform. Dipl.-Päd. Stefan Obermeier hat langjährige Beratung- und Projektleitungserfahrung in der Umsetzung von Geschäftsprozessen in den Bereichen Personal-, Kunden (CRM)-, und Wissensmanagement und arbeitet heute beim IVZ des ZBFS für den Geschäftsbereich des Bayerischen Staatsministerium für Arbeit, Sozialordnung, Familie und Frauen. Darüber hinaus ist er als Dozent für die Hamburger Fernhochschule im Studienschwerpunkt Wirtschaftsinformatik tätig.