Service- und Ereignisorientierung im Contact-Center: Entwicklung eines Referenzmodells zur Prozessautomatisierung

Daniel Jobst Service- und Ereignisorientierung im Contact-Center GABLER RESEARCH Daniel Jobst Service- und Ereigni...

Author: Daniel Jobst

31 downloads 1466 Views 5MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Daniel Jobst Service- und Ereignisorientierung im Contact-Center

GABLER RESEARCH

Daniel Jobst

Service- und Ereignisorientierung im Contact-Center Entwicklung eines Referenzmodells zur Prozessautomatisierung

Mit einem Geleitwort von Prof. Dr. Christian Wolff

RESEARCH

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

Dissertation der Universität Regensburg, Phil. Fak. IV – Sprach- und Literaturwissenschaft, D 355

1. Auflage 2010 Alle Rechte vorbehalten © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2010 Lektorat: Stefanie Brich | Hildegard Tischer Gabler Verlag ist eine Marke von Springer Fachmedien. Springer Fachmedien ist Teil der Fachverlagsgruppe Springer Science+Business Media. www.gabler.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. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Umschlaggestaltung: KünkelLopka Medienentwicklung, Heidelberg Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier Printed in Germany ISBN 978-3-8349-2487-2

V

Geleitwort Die Neuausrichtung von Geschäftsanwendungen an diensteorientierten Konzepten im Kontext der serviceorientierten Architektur (SOA) hat die Entwicklung der Software-Architekturen in den vergangenen Jahren stark geprägt. Darauf aufbauend setzt sich Daniel Jobst mit der Frage auseinander, welche Rolle Konzepte der Service- und Ereignisorientierung im Contact-Center spielen. Contact-Center umfassen eine Vielzahl unterschiedlicher Organisationsformen der Kommunikation zwischen Unternehmen und Kunden wie zum Beispiel Call-Center. Der wesentliche Beitrag zur Forschung liegt bei der Studie von Daniel Jobst in der Zusammenschau von diensteorientierten Architekturen mit dem neuen Ansatz des „Complex Event Processing“: Dieses neue Forschungsparadigma der angewandten und praktischen Informatik ergänzt die modellierungsgetriebene Sicht der SOA um eine analytische Echtzeitkomponente, bei der die in den Systemen eines Unternehmens auftretenden Ereignisse analysiert werden, um unmittelbare Handlungsempfehlungen ableiten zu können. Als Ergebnis seiner Überlegungen kommt Daniel Jobst zu einem überzeugenden Modell, das vor dem Hintergrund konkreter Projekterfahrungen im Bereich Contact-Center entwickelt wurde. Damit liegt erstmals ein Referenzmodell für die Koppelung von Serviceund Ereignisorientierung für einen einschlägigen Anwendungsbereich vor. Es kann als Ausgangspunkt für zahlreiche Anwendungsfelder dienen, in denen diese Koppelung ebenfalls naheliegend ist. Dazu zählen etwa Finanzdienstleister, Logistik oder auch der Bereich Retail, da auf all diesen Gebieten eine Auswertung auftretender „Event Clouds“ in Echtzeit einen substanziellen Mehrwert verspricht. Die vorliegende Studie besticht durch ihren klaren Aufbau, die Erschließung aller relevanten Quellen und ihren überzeugenden Argumentationsgang. Daniel Jobst hat auf diesem noch jungen Feld Pionierarbeit geleistet, und es ist zu hoffen, dass sein Ansatz für nachfolgende Studien fruchtbar sein möge. Regensburg, im August 2010 Prof. Dr. Christian Wolff

VII

Inhaltsverzeichnis Abbildungsverzeichnis

XIV

Tabellenverzeichnis

XV

Abkürzungsverzeichnis

XVI

I. Grundlagen

1

1. Service- und Ereignisorientierung im Contact-Center 1.1. Problemstellung und Notwendigkeit der wissenschaftlichen Untersuchung 1.2. Zielsetzung und Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1. Forschungsbeitrag . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2. Forschungsmethode . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

1 1 3 4 6 7

2. Contact-Center als Dienstleister in der Kundenkommunikation 2.1. Definition der Begriffe Call-Center und Contact-Center . . . . . . . 2.2. Contact-Center als virtuelle Unternehmungen . . . . . . . . . . . . 2.3. Aufbau und Organisation von Contact-Centern . . . . . . . . . . . 2.3.1. Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2. Problemstellung der IT-Landschaft in Contact-Centern . . . 2.3.3. Aufbauorganisation . . . . . . . . . . . . . . . . . . . . . . . 2.3.4. Ablauforganisation . . . . . . . . . . . . . . . . . . . . . . . 2.3.5. Mitarbeiter . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

11 11 13 15 16 24 25 29 30

. . . . . . . .

. . . . . . . .

. . . . . . . .

3. Kundenorientierung und Industrialisierung in der Kundenkommunikation 3.1. Kundenorientierung als Unternehmensziel . . . . . . . . . . . . . . . . . . . 3.1.1. Begriffsklärung Kundenorientierung . . . . . . . . . . . . . . . . . . 3.1.2. Kundenorientierung als Teil des Unternehmensmarketings . . . . . . 3.1.3. Zielsetzung der Kundenorientierung . . . . . . . . . . . . . . . . . . 3.1.4. Kundenorientierung im Kontext von Contact-Centern . . . . . . . . 3.2. Industrialisierung der Dienstleistungsbranche . . . . . . . . . . . . . . . . . 3.2.1. Globale Einflussfaktoren auf Dienstleistungsunternehmen . . . . . . 3.2.2. Industrialisierung von Dienstleistungen . . . . . . . . . . . . . . . . 3.3. Kundenorientierung und Industrialisierung als Einflussfaktoren . . . . . . .

33 33 33 35 37 39 42 42 45 47

VIII

Inhaltsverzeichnis

II. Geschäftsprozesse, Service- und Ereignisorientierung

51

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement 51 4.1. Prozessbegriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.1.1. Definition des Prozessbegriffs . . . . . . . . . . . . . . . . . . . . . 52 4.1.2. Prozessklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.1.3. Prozessorientierung und Prozessorganisation . . . . . . . . . . . . . 57 4.2. Geschäftsprozessmanagement . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.2.1. Definition Geschäftsprozessmanagement . . . . . . . . . . . . . . . 63 4.2.2. Geschäftsprozessmanagement als integriertes Managementkonzept . 65 4.2.3. Aufgaben des Geschäftsprozessmanagements . . . . . . . . . . . . . 68 4.3. Geschäftsprozessmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.3.1. Prozessmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.3.2. Methoden der Geschäftsprozessmodellierung . . . . . . . . . . . . . 72 4.3.3. Exkurs: Architektur integrierter Informationssysteme (ARIS) und Business Process Management Notation (BPMN) . . . . . . . . . . 79 4.4. Geschäftsprozesscontrolling und -optimierung . . . . . . . . . . . . . . . . 93 4.4.1. Informationsorientiertes Geschäftsprozesscontrolling . . . . . . . . . 93 4.4.2. Regelungs- und steuerorientiertes Geschäftsprozesscontrolling . . . . 96 4.4.3. Koordinationsorientiertes und strategisches Geschäftsprozesscontrolling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.5. Prozessautomatisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.5.1. Workflow-Management und der Workflow-Begriff . . . . . . . . . . 100 4.5.2. Workflow-Management im Kontext von Geschäftsprozessmanagement102 5. Serviceorientierung 5.1. Serviceorientierung und serviceorientierte Architekturen . . . . . . . . . . 5.1.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2. Bestandteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.3. Aktueller Diskussionsstand . . . . . . . . . . . . . . . . . . . . . . 5.2. Umsetzung von serviceorientierten Architekturen mit Web-Services . . . 5.2.1. Web Service Description Language (WSDL) . . . . . . . . . . . . 5.2.2. Simple Object Access Protocol (SOAP) . . . . . . . . . . . . . . . 5.2.3. Universal Description, Discovery and Integration (UDDI) . . . . . 5.2.4. Transaktionen und Sicherheit von Web-Services . . . . . . . . . . 5.3. Serviceorientierte Architekturen und Geschäftsprozessmanagement . . . . 5.3.1. Prozessorchestrierung mit Business Process Execution Language (BPEL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2. Integration manueller Arbeitsschritte . . . . . . . . . . . . . . . .

. . . . . . . . . .

105 105 105 109 113 115 117 118 121 122 124

. 127 . 130

6. Ereignisorientierung 137 6.1. Grundlagen der Ereignisorientierung . . . . . . . . . . . . . . . . . . . . . 137 6.1.1. Ereignisbegriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Inhaltsverzeichnis

IX

6.1.2. Ereignisorientierung und -verarbeitung . . . . . . . . 6.1.3. Ereignisorientierte Ansätze . . . . . . . . . . . . . . . 6.2. Ereignisorientierte verteilte Systeme . . . . . . . . . . . . . . 6.2.1. Grundlagen und Abgrenzung zur Serviceorientierung 6.2.2. Architektur und Engineering . . . . . . . . . . . . . . 6.3. Complex Event Processing (CEP) . . . . . . . . . . . . . . . 6.3.1. Komplexe Events und ihre Verarbeitung . . . . . . . 6.3.2. Event-Processing-Netzwerke und -Agenten . . . . . . 6.3.3. Paradigmen des CEP: Event-Clouds und -Ströme . . 6.3.4. Aktueller Diskussionsstand . . . . . . . . . . . . . . . 6.4. Eventverarbeitung und Geschäftsprozessmanagement . . . . 6.4.1. Business-Activity-Monitoring (BAM) . . . . . . . . . 6.4.2. Workflow-Steuerung . . . . . . . . . . . . . . . . . . 6.4.3. Bestehende Referenzmodelle . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

140 141 142 143 144 148 149 154 156 159 161 161 163 164

III.Referenzmodell: Anwendung der Service- und Ereignisorientierung im Contact-Center 167 7. Handlungsfelder und Neuansatz 7.1. Bewertung des Status quo . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.1. Contact-Center-Praxis . . . . . . . . . . . . . . . . . . . . . . . 7.1.2. Geschäftsprozessmanagement, Service- und Ereignisorientierung 7.1.3. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2. Lösung durch Integration vorhandener Ansätze auf Basis von Standards 7.2.1. Zielbild und Rahmenbedingungen . . . . . . . . . . . . . . . . . 7.2.2. Architektur des Referenzmodells . . . . . . . . . . . . . . . . . . 7.2.3. Eigenschaften von Referenzmodellen und Evaluierungskriterien .

. . . . . . . .

. . . . . . . .

167 168 168 170 172 173 173 174 176

8. Automatisierung durch Serviceorientierung 8.1. Gewähltes Vorgehensmodell . . . . . . . . . . . . . . . . 8.2. Identifikation von Zielen und Architekturprinzipien . . . 8.3. Domänenarchitektur . . . . . . . . . . . . . . . . . . . . 8.4. Identifikation von Service-Typen . . . . . . . . . . . . . . 8.4.1. Beitrag zur Zielerreichung . . . . . . . . . . . . . 8.4.2. Überblick über die Service-Typen . . . . . . . . . 8.4.3. Service-Typ Agenten-Service . . . . . . . . . . . . 8.4.4. Service-Typ Multikanal-Service . . . . . . . . . . 8.4.5. Service-Typ Integrations-Service . . . . . . . . . . 8.4.6. Service-Typ Routing-Service . . . . . . . . . . . . 8.5. Entwicklung eines Contact-Center-Prozessmodells . . . . 8.5.1. Beitrag zur Zielerreichung . . . . . . . . . . . . . 8.5.2. Überblick über das Contact-Center-Prozessmodell

. . . . . . . . . . . . .

. . . . . . . . . . . . .

179 179 180 185 189 189 190 191 195 197 198 201 201 203

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

X

Inhaltsverzeichnis 8.5.3. Prozessmodell Prozesslandkarte 8.5.4. Prozessmodell Geschäftsprozess 8.5.5. Prozessmodell Teilprozess . . . 8.6. Umsetzung . . . . . . . . . . . . . . . . 8.6.1. Servicegestaltung . . . . . . . . 8.6.2. Architektur und Komponenten

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

204 208 213 218 218 226

9. Steuerung und Überwachung durch Ereignisorientierung 233 9.1. Vorgehensmodell und Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . 233 9.2. Erarbeitung der Event-technischen Grundlagen (Event-Enabling) . . . . . 235 9.2.1. Gestaltungsgrundsätze für die Identifikation von Komponenten . . . 236 9.2.2. Schaffung einer Event-Driven-Architecture (EDA) . . . . . . . . . . 237 9.2.3. Notification-Service und Event-Transport . . . . . . . . . . . . . . . 238 9.2.4. Event-Darstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 9.3. Event-Processing-Agents (EPA) und ihre zugehörigen Event-Typen . . . . 244 9.3.1. Event-basierte Geschäftsprozesssteuerung . . . . . . . . . . . . . . . 244 9.3.2. Kennzahlenerstellung . . . . . . . . . . . . . . . . . . . . . . . . . . 251 9.3.3. Kennzahlendarstellung, Event-Historisierung und Verbindung zu bestehenden BI-Lösungen . . . . . . . . . . . . . . . . . . . . . . . . . 255 9.4. Das Event-Processing-Network (EPN) im Contact-Center . . . . . . . . . . 256 9.4.1. Topologie des EPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 9.4.2. Beispielhafte Umsetzung einzelner Kennzahlen . . . . . . . . . . . . 258 9.4.3. Schaffung eines Performance-Netzwerks . . . . . . . . . . . . . . . . 261 9.5. Erweiterung des Prozessmodells um Aspekte der Ereignisverarbeitung . . . 264 9.5.1. Sammlung der Kennzahlen in Kennzahlenbäumen . . . . . . . . . . 264 9.5.2. Prozessmodell Event-Verarbeitungs-Diagramm . . . . . . . . . . . . 264 9.5.3. Gesamtzusammenhang im integrierten Geschäftsprozessmanagement 267 10.Zusammenfassung 10.1. Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2. Ergebnisse und Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3. Grenzen und weitergehende Forschungsfragen . . . . . . . . . . . . . . . Literatur

271 . 271 . 271 . 278 281

XI

Abbildungsverzeichnis 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24.

Themenfelder und Komponenten im Contact-Center . . . . . . . . . . . . . Referenzmodell mit integriertem Managementsystem als Zielsetzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schema einer virtuellen Unternehmung [nach Schümann und Tisson, 2006, S. 25] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beziehungsgefüge Unternehmen – Contact-Center – Kunde [aus Schümann und Tisson, 2006, S. 23] . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wirkfaktoren im Contact-Center: Mensch, Technik, Organisation [nach Böse und Flieger, 1999, S. 36] . . . . . . . . . . . . . . . . . . . . . . . . . . . Überblick über Computer Telephony Integration im Call Center [nach Stockberger, 2001, S. 305] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modelle der Aufbauorganisation im Contact-Center [in Anlehnung an Zapf, 2003, S. 33 - 35] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aufbauorganisation im Contact-Center [in Anlehnung an Scupin, 2006, S. 22] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abgrenzung des CRM-Begriffs [aus Hippner, 2006, S. 20] . . . . . . . . . . Von der Kundenorientierung zum Kundenwert [aus Bruhn, 2006b, S. 200] . Erscheinungsformen der Kommunikation von Unternehmen [aus Bruhn, 2007, S. 200] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Realisierung von Kundennähe als zentrale Zielsetzung einer Kundenbeziehungsstrategie [aus Hippner, 2006, S. 36] . . . . . . . . . . . . . . . . . . . CRM Wirkungskette [aus Hippner, 2006, S. 22] . . . . . . . . . . . . . . . Kernkompetenzen im CRM-Prozess von Contact-Centern [nach Hippner, 2006, S. 33] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wachsender Zuwachs in der Dienstleistungsbranche [aus Pantaleo und Pal, 2008, S. 10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generischer Dienstleistungsprozess [aus Gross et al., 2006, S. 21] . . . . . . Veränderung von Wertschöpfungsprozessen [aus Hildebrand und Klostermann, 2007, S. 10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kriterien für ein kundenorientiertes und industrialisiertes Unternehmen [aus Habel, 2006, S. 51] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definition „Prozess“ und „Geschäftsprozess“ im Vergleich [aus Schmelzer und Sesselmann, 2008, S. 64] . . . . . . . . . . . . . . . . . . . . . . . . . . Wertkette nach [Porter, 2000] . . . . . . . . . . . . . . . . . . . . . . . . . Prozessabläufe durch die Unternehmensorganisation [aus Schreiner, 2001, S. 12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zwischenformen prozessorientierter Organisationsgestaltung [aus Osterloh und Frost, 2006, S. 110] . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beziehungen zwischen den Rollen in einer Prozessorganisation [aus Eicker et al., 2008, S. 253] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 4 8 14 15 16 18 26 28 36 37 39 40 41 42 43 46 47 49 53 55 59 60 61

XII

Abbildungsverzeichnis 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57.

„Traditionen“ des Geschäftsprozessmanagement [aus Harmon, 2008, S. 3] . 64 Managementsysteme für die Unternehmensebenen [aus Ellringmann, 2000, S. 7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Aufgaben des Geschäftsprozessmanagements . . . . . . . . . . . . . . . . . 68 Notwendige normative und strategische Vorgaben für die operative Ebene [nach Bräkling und Oidtmann, 2006, S. 5] . . . . . . . . . . . . . . . . . . 70 Beispiel für Prozessebenen verschiedener Detaillierung . . . . . . . . . . . . 71 Prozess- und Struktursichten im Prozessmodell [aus Gadatsch, 2008, S. 80] 72 Beispiel einer Prozesslandkarte mit Ebenen und Prozessklassen . . . . . . . 74 Metamodell zur detaillierten Geschäftsprozessmodellierung [aus Scheer et al., 2006a, S. 32] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Beispiel der Modellierung eines Geschäftsprozess nach dem Metamodell . . 77 ARIS-Haus [aus Scheer, 2001, S. 1] . . . . . . . . . . . . . . . . . . . . . . 81 ARIS House of Business Process Management [aus Scheer et al., 2005, S. 4] 82 Beispiel eines Wertschöpfungskettendiagramms . . . . . . . . . . . . . . . . 83 Beispiel einer EPK mit Grundelementen . . . . . . . . . . . . . . . . . . . 85 Beispiel einer erweiterten EPK zur Abbildung der Steuerungssicht . . . . . 87 BPMN-Meta-Modell der Grundelemente zur Prozessmodellierung [aus Momm et al., 2007, S. 324] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 BPMN Grundelemente [aus OMG, 2008a, S. 18 - 20] . . . . . . . . . . . . 89 BPMN-Beispiel-Prozess [aus Decker et al., 2008] . . . . . . . . . . . . . . . 90 Vergleich der Grundelemente aus EPK und BPD [aus Kruczynski, 2008, S. 2] 91 Systematisierung von Geschäftsprozesskennzahlen [aus Götze, 2007, S. 327] 95 Ansatzpunkte zur Geschäftsprozessoptimierung [aus Feldmayer und Seidenschwarz, 2005, S. 63] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Workflow-Beispiele zur Integration [aus Weske, 2007, S. 52, 54] . . . . . . . 102 Differenzierung der Systembegriffe [aus vom Brocke, 2008, S. 12] . . . . . . 106 Grundbestandteile einer SOA [nach Krafzig et al., 2005, S. 57] . . . . . . . 110 Rollen und Aktionen in einer SOA [nach Melzer, 2007, S. 12] . . . . . . . . 112 Integrationsaspekte eines ESB [nach Chappell, 2006, S. 12] . . . . . . . . . 112 Rollen und Aktionen in einer SOA mit Web-Service-Standards . . . . . . . 116 WSDL-Struktur [aus vom Brocke, 2008, S. 20] . . . . . . . . . . . . . . . . 117 Ausschnitt aus einem WSDL der Firma Amazon.com [Amazon, 2009] . . . 119 SOAP-Struktur mit Beispiel [aus Woods und Mattern, 2006, S. 328 f.] . . . 121 Unterschied Aufgabe – Funktion anhand einer EPK [nach vom Brocke, 2008, S. 58] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Top-Down oder Bottom-Up-Vorgehen für SOA [nach de Hesselle et al., 2008, S. 32] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 BPEL-Kommunikationselemente mit Bezug zu WSDL [aus Melzer, 2007, S. 243] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Zustandsdiagramm eines Human-Task [aus Agrawal et al., 2007a, S. 37] . . 133

Abbildungsverzeichnis 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95.

Möglichkeiten zur Integration von „human interactions“ in BPEL [aus Agrawal et al., 2007b, S. 16] . . . . . . . . . . . . . . . . . . . . . . . . . . Klassendiagramm mit Elementen aus BPEL4People und WS-HumanTask [aus Russell und van der Aalst, 2008, S. 98] . . . . . . . . . . . . . . . . . . Basisarchitektur eines DEBS [aus Mühl et al., 2006, S. 12] . . . . . . . . . Generisches pub/sub-Interface [aus Mühl et al., 2006, S. 138] . . . . . . . . Scopes und Komponenten [aus Fiege et al., 2006, S. 50] . . . . . . . . . . . Administrations-Interface für Scopes . . . . . . . . . . . . . . . . . . . . . Event-Hierarchien-Modell [aus Luckham, 2002, S. 132] . . . . . . . . . . . . Event-Hierarchie-Beispiel aus einem Contact-Center . . . . . . . . . . . . . Beispiel eines Event-Processing-Netzwerks . . . . . . . . . . . . . . . . . . Grobes CEP-Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . . . CEP-Integrationsmodell [aus Chakravarthy und Adaikkalavan, 2008, S. 9] . Event-Modellierung in BPMN und ARIS EPK . . . . . . . . . . . . . . . . EDBPM-Referenzmodell [nach Ammon et al., 2008] . . . . . . . . . . . . . Zielbild des Referenzmodells . . . . . . . . . . . . . . . . . . . . . . . . . . Architektur des Referenzmodells . . . . . . . . . . . . . . . . . . . . . . . . Vorgehensmodell zur Gestaltung SOA-relevanter Teile des Referenzmodells Indikatoren für/gegen SOA [aus Heutschi, 2007, S. 132] . . . . . . . . . . . Priorisierung der Architekturprinzipien für die Service-Typen-Definition . . Generelle Anwendungsdomänen eines Contact-Centers . . . . . . . . . . . . Service-Typen-Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integrationssichten [aus Vogler, 2006, S. 83] . . . . . . . . . . . . . . . . . CTI-Standards [aus ITWissen, 2009, CTI-Standards] . . . . . . . . . . . . Hierarchieebenen des Contact-Center-Prozessmodells . . . . . . . . . . . . Beispiel einer Prozesslandkarte . . . . . . . . . . . . . . . . . . . . . . . . . Bestellung bearbeiten GP . . . . . . . . . . . . . . . . . . . . . . . . . . . Bestellung erfassen TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zusammenhänge zwischen Prozessmodell und Services . . . . . . . . . . . . Gestaltung von Services aus Teilprozessmodellen . . . . . . . . . . . . . . . Gestaltung von WS-Human-Tasks zu Agenten-Services aus Teilprozessmodellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gesamtarchitektur der SOA-Umsetzung des Referenzmodells . . . . . . . . Ablauf zwischen den SOA-Komponenten . . . . . . . . . . . . . . . . . . . Beispielmontage einer Agent-Desktop-Oberfläche . . . . . . . . . . . . . . . Vorgehensmodell zur Gestaltung der Ereignisorientierung . . . . . . . . . . Operationen und Standardnutzung des Notification-Service . . . . . . . . . Operationen und Standardnutzung des Notification-Service . . . . . . . . . Beteiligte Komponenten beim Event-Transport . . . . . . . . . . . . . . . . Event-Darstellung: Zusammenhänge zwischen Prozessmodell und Event im Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event-Attribute und -Elemente mit Verbindung zum Prozess-Repository .

XIII

134 135 145 145 147 148 151 152 155 156 158 163 165 174 175 179 180 184 188 190 194 196 203 207 213 219 220 221 223 226 229 231 235 238 239 240 241 243

XIV 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106.

Abbildungsverzeichnis Architekturmodell, logischer Ablauf und verwendete Standards der ereignisorientierten Prozesssteuerung . . . . . . . . . . . . . . . . . . . . . . . Zusammenhang zwischen Prozessmodell Geschäftsprozess und dem EventAbonnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Erweiterungen des Agenten-Desktop für die Geschäftsprozesssteuerung . Klassendiagramm der Kennzahlenerstellung mittels EPA . . . . . . . . . Kennzahlendarstellung, Event-Historisierung und Verbindung zu bestehenden BI-Lösungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Topologie eines EPN in Contact-Centern . . . . . . . . . . . . . . . . . . Ausschnitt aus einem EPN zur Umsetzung der wichtigsten Kennzahlen . Geschäftsprozess modelliert als Performance-Netz [aus Mevius et al., 2009, S. 259] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prozessautomatisierung innerhalb eines Performance-Netzwerks . . . . . Beispiel eines Event-Verarbeitungs-Diagramms als neuer Diagrammtyp in ARIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gesamtzusammenhang im Referenzmodell . . . . . . . . . . . . . . . . .

. 245 . 247 . 248 . 253 . 255 . 257 . 258 . 261 . 263 . 265 . 268

XV

Tabellenverzeichnis 1. 2.

Transaktions- und Beziehungsmarketingkriterien [nach Bruhn, 2007, S. 31] Einfluss der Informationstechnologie auf die Prozessorganisation [in Anlehnung an Davenport, 1993, S. 51] . . . . . . . . . . . . . . . . . . . . . . . . 3. Anteile weiterer Managementkonzepte im Geschäftsprozessmanagement [aus Schmelzer und Sesselmann, 2008, S. 13] . . . . . . . . . . . . . . . . . . . . 4. Differenzierung der Eventbegriffe . . . . . . . . . . . . . . . . . . . . . . . 5. Interaktionsmodelle im Vergleich [aus Mühl et al., 2006, S. 14] . . . . . . . 6. Operationen des Service-Typs Agenten-Service . . . . . . . . . . . . . . . . 7. Operationen des Service-Typs Routing-Service . . . . . . . . . . . . . . . . 8. Modellierungskonventionen für die Prozesslandkarte . . . . . . . . . . . . . 9. Modellierungskonventionen für Geschäftsprozesse . . . . . . . . . . . . . . 10. Modellierungskonventionen für Teilprozesse . . . . . . . . . . . . . . . . . . 11. Generelle Übertragungsbeziehungen und Standardnutzung . . . . . . . . . 12. Übertragung und Standardnutzung von Interaktionen in Agenten-Services . 13. Referenzen zwischen dem Prozessmodell und der Event-Darstellung . . . . 14. Prozess-Event: Mögliche Attribute und Elemente . . . . . . . . . . . . . . 15. Übersicht der wichtigsten Kennzahlen im Contact-Center für das Referenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16. BAM-Event: Mögliche Attribute und Elemente . . . . . . . . . . . . . . . . 17. Modellierungskonventionen für das Event-Verarbeitungs-Diagramm . . . .

36 62 67 138 143 192 200 205 210 217 222 224 244 251 252 254 267

XVI

Abkürzungsverzeichnis ACD . . . . . . . . . . . allg. . . . . . . . . . . . . ARIS . . . . . . . . . . . ASR . . . . . . . . . . . BMI . . . . . . . . . . . . BPD . . . . . . . . . . . BPEL . . . . . . . . . . BPM . . . . . . . . . . . BPMN . . . . . . . . . BPO . . . . . . . . . . . bspw. . . . . . . . . . . CEP . . . . . . . . . . . CIM . . . . . . . . . . . . CMMI . . . . . . . . . COM . . . . . . . . . . . CORBA . . . . . . . . CRM . . . . . . . . . . . CSTA . . . . . . . . . . CTI . . . . . . . . . . . . d. h. . . . . . . . . . . . . DEBS . . . . . . . . . . DTF . . . . . . . . . . . EAI . . . . . . . . . . . . ECA . . . . . . . . . . . EDA . . . . . . . . . . . EDA . . . . . . . . . . . EDBPM . . . . . . . . eEPK . . . . . . . . . . eERM . . . . . . . . . . EP-TS . . . . . . . . . EPA . . . . . . . . . . . EPK . . . . . . . . . . . EPL . . . . . . . . . . . . EPN . . . . . . . . . . . EQL . . . . . . . . . . .

Automatic Call Distributor allgemein Architektur integrierter Informationssysteme Automatic Speech Recognition Business Modeling and Integration Business Process Diagram (Teil der BPMN) Business Process Execution Language Business Process Management Business Process Management Notation Business Process Outsourcing beispielsweise Complex Event Processing Computation Independent Model Capability Maturity Model Integration Component Object Model Common Object Request Broker Architecture Customer Relationship Management Computer Supported Telecommunications Applications Computer Telephony Integration das heißt Distributed Event-based Systems Domain Task Force Enterprise Application Integration Event–Condition–Action Event-Driven Architecture Event-driven Architecture Event-driven Business Process Management erweiterte Ereignisgesteuerte Prozesskette erweitertes Entity-Relationship-Modell Event Processing Technical Society Event-Processing-Agenten Ereignisgesteuerte Prozesskette Event Processing Language Event Processing Network Event Query Language

Abkürzungsverzeichnis ERM . . . . . . . . . . . ESB . . . . . . . . . . . . ESP . . . . . . . . . . . . FTP . . . . . . . . . . . HOBE . . . . . . . . . HTTP . . . . . . . . . . IP . . . . . . . . . . . . . . IVR . . . . . . . . . . . . JMS . . . . . . . . . . . . KPI . . . . . . . . . . . . MOM . . . . . . . . . . MUWS . . . . . . . . . NLU . . . . . . . . . . . OASIS . . . . . . . . . OMG . . . . . . . . . . OWL . . . . . . . . . . . PBX . . . . . . . . . . . PIM . . . . . . . . . . . . PSM . . . . . . . . . . . PSTN . . . . . . . . . . QoS . . . . . . . . . . . . RDF . . . . . . . . . . . RDFS . . . . . . . . . . RMI . . . . . . . . . . . . SAML . . . . . . . . . . SIP . . . . . . . . . . . . SLA . . . . . . . . . . . . SMTP . . . . . . . . . . SOA . . . . . . . . . . . SOAP . . . . . . . . . . TAPI . . . . . . . . . . . TQM . . . . . . . . . . . u. a. . . . . . . . . . . . . u. U. . . . . . . . . . . . URI . . . . . . . . . . . .

XVII

Entity-Relationship-Modell Enterprise Service Bus Event Stream Processing File Transfer Protocol ARIS House of Business Engineering Hypertext Transfer Protocol Internet Protocol Interactive Voice Response Java Messaging Service Key Performance Indicator Message-orientierte Middleware Web Services Distributed Management: Management Using Web Services Natural Language Understanding Organization for the Advancement of Structured Information Standards Object Management Group Web Ontology Language Private Branch Exchange Platform Independent Model Platform Specific Model Public Switched Telephone Network Quality of Service Resource Definition Framework Resource Definition Framework Schema Remote Method Invocation Security Assertion Markup Language Session Initiation Protocol Service Level Agreement Simple Mail Transfer Protocol Serviceorientierte Architektur Simple Object Access Protocol Telephony Application Programming Interface Total Quality Management unter anderem unter Umständen Uniform Resource Identifier

XVIII vgl. . . . . . . . . . . . . VoIP . . . . . . . . . . . W3C . . . . . . . . . . . WfM . . . . . . . . . . . WfMC . . . . . . . . . WFMS . . . . . . . . . WKD . . . . . . . . . . WS-BPEL . . . . . . WSDL . . . . . . . . . WSTF . . . . . . . . . XML . . . . . . . . . . .

Abkürzungsverzeichnis vergleiche Voice over IP World Wide Web Consortium Workforce-Management Workflow Management Coalition Workflow Management System Wertschöpfungskettendiagramm Web Services Business Process Execution Language Web Service Description Language Web Service Transaction Framework Extensible Markup Language

1

Teil I. Grundlagen Jedes gelöste Problem ist einfach. (Thomas Alva Edison)

1. Service- und Ereignisorientierung im Contact-Center Inhalt dieser Arbeit ist die Entwicklung eines innovativen Referenzmodells zur sinnvollen Anwendung der Service- und Ereignisorientierung in Contact-Centern. Zur Erarbeitung der notwendigen Grundlagen werden hierfür zunächst die Problemstellung, die Notwendigkeit der wissenschaftlichen Untersuchung, die Zielsetzung und das gewählte Vorgehen sowie der weitere Aufbau der Arbeit vorgestellt.

1.1. Problemstellung und Notwendigkeit der wissenschaftlichen Untersuchung Kundenorientierung und damit verbunden das Maß an Kundenzufriedenheit gehören heute zu den bestimmenden Wettbewerbskriterien. Ein optimal erbrachter Kundenservice kann zum entscheidenden Wettbewerbsvorteil auf dem modernen Markt werden. Dies ist fast unabhängig von Branche oder Industriesektor zu beobachten. Gerade in der heutigen Zeit, in der Produkte und Dienstleistungen immer ähnlicher werden und Konkurrenzangebote viel schneller in gleicher oder ähnlicher Ausprägung auf den Markt kommen, kann die Zufriedenheit des Kunden mit dem erbrachten Kundenservice in hohem Maße über den Erfolg oder Misserfolg eines Produkts und letztendlich über die Existenz einer Unternehmung entscheiden [vgl. u. a. Ebner et al., 2007, Picot et al., 2001]. Vor dem Hintergrund der Kundenorientierung und der Sicherstellung einer hohen Kundenzufriedenheit kommt denjenigen Abteilungen oder Outsourcing-Dienstleistern einer Unternehmung, die die Schnittstelle zu den Kunden hin bilden, eine besondere Bedeutung zu. Bei großen und mittelständischen Unternehmen übernehmen diese Aufgabe meist sogenannte Contact-Center. Erschwerend kommen zu den Aufgaben der Sicherstellung einer hohen Kundenzufriedenheit weitere innere und äußere Einflussfaktoren hinzu. Dies sind etwa Forderungen nach

D. Jobst, Service- und Ereignisorientierung im Contact-Center, DOI 10.1007/978-3-8349-8989-5_1, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2010

2

1. Service- und Ereignisorientierung im Contact-Center

einer schnellen Markteinführung neuer Produkte und Dienstleistungen (und dadurch entsprechend der zugehörige Kundenservice), ein schnelles Erreichen der Gewinnschwelle bei deren Einführung (ebenso mit der Maßgabe der Wirtschaftlichkeit für den Kundenservice) oder eine sich schnell verändernde Unternehmenslandschaft mit immer neuen Unternehmensaufkäufen und -zusammenschlüssen, was im Endeffekt eine Vereinheitlichung oder Zentralisierung des Kundenservice bedeuten kann. All diesen Aspekten muss bei der Erbringung eines optimalen Kundenservice entsprechend Rechnung getragen werden. Dies geschieht zum einen aus fachlicher und prozessualer Sicht in den Fachabteilungen und zum anderen durch den entsprechenden Einsatz von Informations- und Kommunikationstechnologie (IuK, IT). Aus fachlicher Sicht spielt eine optimierte Prozessgestaltung eine wesentliche Rolle, um einzelne Tätigkeiten im Kundenservice oder die gesamte Abfolge der Prozessschritte zu verbessern. Dazu werden in Contact-Centern bis zu einem gewissen Maße bereits Geschäftsprozesse mit Hilfe von Prozessmodellierungssprachen und -tools dokumentiert und analysiert. Im Fokus stehen dabei meist nur Einzelprozesse und nicht deren Wechselwirkung mit der vorhandenen Systemlandschaft. In der IT sind häufig funktional orientierte Insellösungen vorhanden, die einzelne fachliche Aspekte abdecken. Über die Zeit hinweg sind diese in vielen Fällen zu einem heterogenen Verbund zusammengewachsen, der sich oft nur schwer verwalten und schwer an neue Anforderungen anpassen lässt. Diese Problemstellungen werden in der Literatur mit Hilfe von Architekturkonzepten wie den serviceorientierten Architekturen (SOA) und der Ereignisorientierung diskutiert. Dies geschieht jedoch mehr oder minder häufig aus einer technischen Blickrichtung heraus. Zusätzlich liegt der Fokus dabei in einer eher generischen Betrachtung. Contact-Center-spezifische Problematiken finden dabei keine Beachtung.

Abbildung 1: Themenfelder und Komponenten im Contact-Center In der Praxis werden die angesprochenen Punkte, wie in Abbildung 1 dargestellt, nicht einheitlich betrachtet. Es fehlt hier an einem integrierten Managementsystem, welches es erlaubt, Fach- und IT-Themen gemeinsam zu betrachten, so dass beide Seiten eine gemeinsame Sprache sprechen und alle in einem Contact-Center vorhandenen Systeme und

1.2. Zielsetzung und Vorgehen

3

Prozesse integriert betrachtet, entwickelt und verwaltet werden. Daran beteiligte Aspekte des Wissensmanagements und der Mensch-Computer-Interaktion dürfen dabei nicht unberücksichtigt bleiben. In der Praxis existiert solch ein integriertes Managementsystem für Contact-Center jedoch noch nicht. Eine wissenschaftliche Untersuchung dieses Problems steht noch aus und soll mit dieser Arbeit erfolgen. Die Informationswissenschaft als interdisziplinäre Wissenschaft, die unter den Bedingungen der modernen Informations- und Kommunikationstechnologien die Wissensnutzung auf allen Ebenen (individuell, organisatorisch, kulturell und gesellschaftlich) untersucht [vgl. Wersig, 1993], stellt die notwendige Basis für diese Untersuchung dar. Neben der Informationswissenschaft bildet auch die Wirtschaftsinformatik den notwendigen Rahmen. Beide Disziplinen sind angewandte Wissenschaften mit einer starken Ausrichtung auf die Modellbildung. Vor diesem Hintergrund können für eine beliebige Contact-Center-Organisation anwendbare Modelle entstehen, die das Fundament einer konkreten, praktischen Implementierung darstellen können. Die Entwicklung eines Referenzmodells ist dafür hilfreich, da es generalisiert für eine Klasse von Objekten gilt, die sich nicht nur auf Eigenschaften eines spezifischen Objekts (etwa ein Unternehmen) beziehen. Der Abstraktionsgrad ist entsprechend höher. Das Wissen, das in Referenzmodellen abgebildet ist, ist über Best-Practices einer Domäne auf ein Unternehmen zu übertragen [vgl. bspw. Becker, 2004].

1.2. Zielsetzung und Vorgehen Gegenstand dieser Arbeit ist die Entwicklung eines Referenzmodells zur Prozessautomatisierung, -steuerung und -überwachung für Contact-Center. Dieses Modell beinhaltet die Themen Serviceorientierung und Ereignisorientierung sowie ein adäquates Geschäftsprozessmanagement. Dabei sollen diese einzeln bereits bekannten und diskutierten Disziplinen zu einem für Contact-Center sinnvollen Ganzen zusammengeführt werden, wie in Abbildung 2 schematisch dargestellt. Komponenten des entwickelten Referenzmodells sind dabei unter anderem eine integrierte, lose gekoppelte und ereignisgetriebene Systemarchitektur, eine auf Automatisierung gerichtetes Geschäftsprozessmanagement, das gleichzeitig als integriertes Managementsystem den Gesamtrahmen bildet und eine wesentlich stärkere Steuerung durch den Fachanwender erlaubt. Die als wichtig erachtete Kundenorientierung und Schlüsselbegriffe wie „Pattern“ oder „Prozess“ im weiteren Verlauf, lassen Rückschlüsse auf konkrete Kundenwünsche, Bearbeitungen oder Situationen einzelner Kunden oder Unternehmen zu. Hierin liegt jedoch nicht der Fokus dieser Arbeit. Es werden keine Einzelprozesse und -patterns untersucht, auch konzentriert sich die Arbeit nicht auf die Fragestellung, welche Kundenwünsche mit welchen Charakteristiken es in Contact-Centern gibt. Es steht vielmehr die Schaffung der technischen und fachlichen Möglichkeiten im Mittelpunkt. Die Ergebnisse dieser Arbeit

4


Abbildung 2: Referenzmodell mit integriertem Managementsystem als Zielsetzung der Arbeit sollen es konkreten Projekten in konkreten Contact-Centern ermöglichen, einen besseren Kundenservice anzubieten. Wie dieser genau gestaltet wird, ist und bleibt immer eine unternehmensindividuelle Aufgabe. Hier ergibt sich auch eine klare Schnittstelle für das zu entwickelnde Referenzmodell: Es stellt eine sinnvolle Architektur und die notwendigen Rahmenbedingungen zur Verfügung, „Parametrisiert“ oder „Eingerichtet“ muss dies durch Spezialisten in den einzelnen Contact-Centern werden. 1.2.1. Forschungsbeitrag Die Umsetzung von Geschäftsprozessen mit Hilfe einer SOA als aktuelle Fragestellung wird ausführlich diskutiert. In Deutschland geschieht dies besonders durch Forschungen in engem Zusammenhang mit der SAP-Plattform. Weniger Augenmerk liegt auf der Verbindung von SOA mit einer konkreten Prozessmanagementmethode. Die jeweiligen Bedürfnisse und Anforderungen von Contact-Centern im Bezug auf Geschäftsprozessmanagement, SOA und Prozessautomatisierung finden entsprechend noch weniger Aufmerksamkeit in der Forschung. Ähnliches gilt allgemein auch für das Konzept der Ereignisorientierung und für ereignisorientierte Architekturen. Diese werden als eigene Disziplin1 immer häufiger separat diskutiert. Eine Ausrichtung auf den größeren Kontext in einer Unternehmung steht hier größtenteils noch aus2 . Dies alles bedarf einer genaueren Untersuchung. Nach1

Dies zeigt sich beispielsweise durch die Gründung einer eigenen technischen Gesellschaft mit entsprechenden Standardisierungsbemühungen sowie durch neu auf den Markt kommende ereignisverarbeitende Software-Werkzeuge. 2 Gemeint ist die gemeinsame Betrachtung der Themen SOA und Geschäftsprozessmanagement besonders im Kontext von Kommunikationstechnologie und Prozessen in der Kundenkommunikation sowie deren Überwachung im Rahmen des „Corporate Performance Measurement“ beziehungsweise der „Business Intelligence“.

1.2. Zielsetzung und Vorgehen

5

folgende Fragestellungen gliedern den Beitrag dieser Arbeit zur aktuellen Forschung. Sie ergänzen den derzeitigen Stand der Wissenschaft auf den jeweiligen Gebieten. 1. Welche sind die aktuellen Anforderungen und Herausforderungen eines ContactCenters beziehungsweise eines Contact-Center-Dienstleisters? Bisher gibt es keine umfassende Aufstellung von Anforderungen aus den verschiedenen Domänen eines Contact-Centers beziehungsweise eines Contact-Center-Dienstleisters. Insbesondere ist eine Verbindung der Anforderungen aus den einzelnen Domänen von Interesse. Dies heißt konkret: Welche Anforderungen bestehen seitens der Fachabteilung und welche Anforderungen der IT-seitigen Abteilungen stehen dem gegenüber? Wo decken sich diese und sind diese in Verbindung zueinander zu bringen? 2. Wie sieht SOA konkret in einem Contact-Center aus? Wie lassen sich Geschäftsprozessmanagement und SOA vereinen und lässt sich die Summe aus beiden auch für Prozessautomatisierung und Servicegranularität gebrauchen? Bisherige Untersuchungen sind meist abstrakt und entweder nur auf Geschäftsprozessmanagement oder nur auf SOA bezogen. Es fehlt zum Beispiel an konkreten Untersuchungen, wie SOA sinnvoll in einem Contact-Center eingesetzt werden kann. Gleiches gilt auch für das Geschäftsprozessmanagement. Eine konkrete Verbindung beider Themen ist herzustellen und ebenso ist die Frage nach einer Methode zu klären, wie Services für eine SOA gefunden, das heißt wie „geschnitten“, werden können (auf der Grundlage von bestehenden Anwendungen und Prozessen). 3. Was ist der aktuelle „State of the Art“ im Bereich Event-Verarbeitung? Welche Anwendungsbereiche gibt es hierfür im Contact-Center und wie müssen diese gestaltet werden? Die grundlegende Frage ist, was Event-Verarbeitung eigentlich ist und wodurch es sich auszeichnet. Konkreter formuliert heißt dies, was ist neu daran? Ausgehend von dieser Fragestellung fehlt eine Darstellung der aktuellen Standards und Konzepte in diesem Bereich. Ebenso fehlt eine Untersuchung der Anwendbarkeit auf die Anforderungen von Contact-Centern. 4. Wie muss ein innovatives und praxistaugliches Referenzmodell für Contact-Center aussehen und welche Elemente muss es beinhalten? Es ist ein für die Praxis brauchbares Referenzmodell auf der Grundlage von bestehenden Konzepten zu entwickeln. Kernpunkt des Referenzmodells soll das Geschäftsprozessmanagement als integriertes Managementsystem sein. Dieses Managementsystem soll um die Konzepte der SOA und der Ereignisorientierung erweitert werden. Eine Untersuchung des Maßes der Anwendbarkeit dieses Managementsystems und die Integrierbarkeit der angesprochenen Komponenten spielt dabei eine

6

1. Service- und Ereignisorientierung im Contact-Center wesentliche Rolle. Für die Praxis brauchbar ist dieses Referenzmodell, wenn es die in Frage 1 aufgestellten Anforderungen vollständig abbilden kann.

1.2.2. Forschungsmethode Forschungsmethoden sichern eine systematische Vorgehensweise [vgl. Lehner et al., 2007, S. 20 - 21]. Bestimmend für diese Arbeit ist die anwendungsorientierte, pragmatische Forschung der Informationswissenschaft sowie der Wirtschaftsinformatik. Beide sind keine reinen Formalwissenschaften sondern Realwissenschaften. Ihre Aussagen werden an der Realität mittels Erfahrungen überprüft. Die Art der Wissenschaft bestimmt auch die Forschungsausrichtung [vgl. Lehner et al., 2007, S. 18], hier kann auf bewährte Forschungsmethoden dieser Disziplinen zurückgegriffen werden. Für die vorliegende Arbeit heißt dies, sie ist in erster Linie konstruktiv und wird durch empirische Elemente ergänzt. Die dabei vorgestellten Anforderungen und Probleme stammen aus der konkreten Arbeitswirklichkeit von Contact-Centern. Sie sind nicht aus einer rein theoretischen Untersuchung heraus abgeleitet worden. Sich mit Problemen aus der Praxis zu befassen, ist eine der wesentlichen Eigenschaften der Realwissenschaft und bringt Eigenheiten mit sich, mit denen in dieser Arbeit umgegangen werden muss. In diesem Fall müssen verschiedene Lösungskonzepte verbunden werden, die aus unterschiedlichen Wissenschaftsgebieten kombiniert werden. Die Aufgabenstellungen können jeweils terminologisch-deskriptiv, empirisch-induktiv oder analytisch-deduktiv angegangen werden [vgl. Hill et al., 1998]. In der angewandten Forschung kann aber nicht klar eine induktive oder deduktive Vorgehensweise beibehalten werden. Mit Hilfe einer Fallstudie und der Sekundäranalyse werden Probleme erfasst, Lösungen werden deduktiv erarbeitet und mit Hilfe der Referenzmodellierung konstruiert [vgl. bspw. Lehner et al., 2007]. Das verfolgte, pragmatische Wissenschaftsziel ist die Entwicklung praktisch anwendbarer Handlungsanleitungen und soll die Entwicklung eines nützlichen IT-Systems proaktiv vorbereiten [vgl. Lehner et al., 2007, S. 18], [Hill et al., 1998]. Konkret auf diese Arbeit bezogen sind Forschungsgebiete aus den Wirtschaftswissenschaften, der Informatik und Wirtschaftsinformatik sowie aus der Informationswissenschaft betroffen. In der betriebswirtschaftlichen Organisationslehre angesiedelt sind die Themen Prozessorientierung und das Geschäftsprozessmanagement sowie der Entwurf des integrierten Managementkonzepts, beispielsweise nach [Bleicher, 2004]. Methoden zur Analyse und Lösungsfindung werden daraus herangezogen und mit Methoden der Serviceund Ereignisorientierung sowie allgemein des IT-Managements kombiniert. Letztere sind Domänen der Wirtschaftsinformatik und haben sowohl betriebswirtschaftliche als auch informationstechnische Aspekte. Schließlich spielen Teilgebiete der Informationswissenschaft eine wichtige Rolle: Allen voran das Service-Computing ergänzt durch die Themen Wissensorganisation, -management und -repräsentation.

1.3. Aufbau der Arbeit

7

Die Erhebung der Anforderungen und des Status quo greift auf veröffentlichte Berichte von Praktikern zurück [vgl. u. a. Ebner et al., 2007, Helber und Stolletz, 2004] sowie auf Studien von Beratungsunternehmen [vgl. u. a. Habel, 2006] und Marktforschungsgesellschaften [vgl. u. a. Herrell, 2008, Kraus und Cramoysan, 2008, Bern, 2007, Hipperson, 2007, Herrell, 2006]. Einen weiteren Anteil haben interne Dokumente von namhaften Contact-Center-Dienstleistern, die ebenfalls ausgewertet wurden, sowie darüber hinaus Gespräche mit verantwortlichen Experten verschiedener Contact-Center3 . Die Darstellung des Status quo der Praxis wird wesentlich ergänzt durch die Einzelfalluntersuchung eines konkreten Prozessmodells. Das in dieser Arbeit vorgestellte Problem wird durch ein Referenzmodell abgebildet. In der Allgemeinen Modelltheorie nach [Stachowiak, 1973, S. 131 ff] haben Modelle drei wesentliche Merkmale: Sie sind erstens Abbildungen oder Repräsentationen von Originalen, sie verkürzen zweitens Originale auf relevante Eigenschaften und sie haben drittens ein „pragmatisches Merkmal“, das heißt, sie besitzen allgemein keine eindeutige Zuordnung zum Original sondern nur in bestimmten Funktionen (bestimmte Subjekte, Zeitintervalle, Operationen). Modelle haben demnach den Charakter eines Vorbilds oder einer Empfehlung für die Grundzüge eines zu schaffenden Originals. Das geschaffene Referenzmodell ist somit Vorbild für mögliche Umsetzungen in einem realen Unternehmensumfeld. Darüber hinaus kann es grundsätzlich zur Wissensübertragung verwendet werden.

1.3. Aufbau der Arbeit Abbildung 3 zeigt den Aufbau dieser Arbeit in schematischer Darstellung. Im ersten Teil der Arbeit werden die notwendigen Grundlagen erarbeitet. Dazu wird in Kapitel 2 der Contact-Center-Begriff definiert, Contact-Center als virtuelle Unternehmensformen vorgestellt und der Aufbau und die Organisation von Contact-Centern erarbeitet. Dabei werden die Bestandteile und Problemstellungen der aktuell bestehenden Systemund Prozesslandschaften dargestellt, auf die im Referenzmodell Bezug genommen wird. In Kapitel 3 wird die Bedeutung von Kundenkommunikation und Kundenorientierung für heutige Unternehmen herausgearbeitet und die Frage geklärt, für welche Unternehmen die hier vorgestellte Arbeit relevant ist. Die Ergebnisse dieses Kapitels bilden die strategischen Zielsetzungen, die auf die Gestaltung des Referenzmodells Einfluss nehmen. Teil II beschäftigt sich mit dem aktuellen Stand der einzelnen Bestandteile des Referenzmodells. Klassisches Geschäftsprozessmanagement, serviceorientierte Architekturen und die Ereignisorientierung werden in Theorie und Praxis meist nur für sich betrachtet. Aus diesem Grund werden diese Teilgebiete zunächst einzeln erarbeitet. Kapitel 4 3

Verwendete Dokumente und Interviews mit Linien- und Projektverantwortlichen namhafter Unternehmen liegen vor. Die Dokumente und Ergebnisse müssen auf Grund interner Vorgaben der befragten Firmen anonymisiert dargestellt werden. Ausnahmen davon werden jeweils mit Quellenangabe referenziert.

8


Abbildung 3: Aufbau der Arbeit definiert den Prozessbegriff und analysiert das Geschäftsprozessmanagement und seine Methoden. Dabei wird Geschäftsprozessmanagement auch in weitere unternehmensweite Standardisierungsbemühungen eingeordnet und Gründe für die Verwendung der Methode „Architektur integrierter Informationssysteme“ (ARIS) innerhalb dieser Arbeit dargelegt. Der aktuelle Stand aus Forschung und Praxis der Serviceorientierung (Kapitel 5) und der Ereignisorientierung (Kapitel 6) werden ebenfalls analysiert und jeweils in Bezug zu Geschäftsprozessen gestellt. In Teil III wird das Referenzmodell entwickelt. Die Handlungsfelder und der Neuansatz werden aus der Darstellung und Bewertung des Status quo abgeleitet und das Zielbild und die Architektur des Referenzmodells vorgestellt (Kapitel 7). Die eigentliche Entwicklung

1.3. Aufbau der Arbeit

9

des Referenzmodells ist zweigeteilt: In Kapitel 8 wird die Basis mit der Automatisierung durch Serviceorientierung erarbeitet. Wesentliche Punkte sind dabei die Identifikation von Service-Typen, die Entwicklung eines Contact-Center-Prozessmodells sowie die Gestaltung der Umsetzung der Prozessautomatisierung. Kapitel 9 ergänzt das Basismodell um die Steuerung und Überwachung von Geschäftsprozessen mit Hilfe der Ereignisorientierung. Dazu werden Event-technische Grundlagen erarbeitet, Event-verarbeitende Komponenten und ihre zugehörigen Event-Typen definiert sowie ein Event-Processing-Network für Contact-Center entwickelt. Der Gesamtzusammenhang im integrierten Geschäftsprozessmanagement wird ebenfalls in Kapitel 9 dargestellt. Den Abschluss der Arbeit bildet Kapitel 10. Darin werden das gewählte Vorgehen und die Ergebnisse zusammengefasst und anschließend bewertet. Ebenso wird das Referenzmodell anhand von Qualitätskriterien (aufgestellt in Kapitel 7) überprüft. Das Kapitel 10 schließt mit einer Darstellung des weiteren Forschungsbedarfs.

11

2. Contact-Center als Dienstleister in der Kundenkommunikation Die Bezeichnung „Call-Center“ ist relativ geläufig, obwohl sie im deutschen Sprachgebrauch erst seit etwa Anfang der 1990er Jahre gebraucht wird. Call-Center bezeichnen allgemein einen Ort, von dem aus zentralisiert Anrufe in großer Zahl angenommen oder getätigt werden [vgl. bspw. Lehner und Lüders, 2002, Greff und Fojut, 2003]. Grund für die Geläufigkeit des Begriffs ist auch die Belegung mit einem negativem Image, bedingt durch die Anwendung unlauterer Methoden und fragwürdiger Personalpolitik einzelner schwarzer Schafe [vgl. bspw. Wallraff, 2007]. Doch dieser schlechte Ruf täuscht und eher das Gegenteil ist der Fall. Call-Center sind inzwischen unverzichtbare Organisationseinheiten von immer weiter wachsender Bedeutung für ein Unternehmen. Verkürzte Produktions- und Innovationszyklen, steigender Qualitätsdruck, auch seitens der Kunden, sind Einflussfaktoren, die eine hoch spezialisierte Funktion wie ein Call- oder ContactCenter erforderlich machen oder sogar erzwingen [vgl. bspw. Schümann und Tisson, 2006, Menzler-Trott, 1999]. Den Untersuchungsgegenstand der hier vorliegenden Arbeit stellen Contact-Centern dar, im Speziellen deren Anforderungen sowie Lösungen von und für Dienstleistungsunternehmen, die im ständigen Kontakt mit Endkunden stehen. Aus diesem Grund werden in diesem Kapitel beide Begriffe definiert und voneinander abgegrenzt, um die begriffliche Grundlage für die weitere Arbeit zu legen.

2.1. Definition der Begriffe Call-Center und Contact-Center Grob gesprochen ist ein Call-Center ein Dienstleistungsbetrieb, in dem sogenannte Teledienste produziert werden. Teledienste sind Dienste, bei denen Produzenten und Konsumenten der Dienstleistung zwar räumlich voneinander getrennt sind, dabei aber meist zeitlich aneinander gebunden sind und über ein Medium wie die Telefonie miteinander kommunizieren [vgl. Helber und Stolletz, 2004, S. 3]. Der Begriff Call-Center selbst stammt aus den USA ebenso wie die Organisationsform selbst [vgl. Lehner und Lüders, 2002, S. 1]. Die verschiedenen Definitionen folgen dabei der technischen und fachlichen Entwicklung und werden sowohl von Praktikern gegeben, als auch aus der wissenschaftlichen Beschäftigung heraus, die in den letzten Jahren Call-Center vermehrt in allen Disziplinen untersucht. Nach [Menzler-Trott, 1999, S. 1] sind Call-Center „[...] Organisationseinheiten, die eine serviceorientierte und effiziente dialogische Kommunikation durch den Einsatz moderner Informations- und Kommunikationstechnologien unter Wahrung von Unternehmens- und Marketingzielen ermöglichen. Das Call-Center ist das Herzstück und die Visitenkarte eines Unternehmens und Ansprechpartner und Bearbeiter aller Kundenwünsche.“ Call-Center sind dabei über spezielle Telefonnummern erreichbar. Die Größe ist für die Definition


12

2. Contact-Center als Dienstleister in der Kundenkommunikation

eines Call-Centers weniger entscheidend als vielmehr die Tätigkeitsbeschreibung. Abhängig von den jeweiligen Aufgaben und Spezialisierungen der Call-Center lassen sich grob folgende Bereiche differenzieren: Auftrags- und Bestellannahme, Notfall- und Kundendienstangebote, Marktforschung, Reservierungs- und Ticketdienste, Bereitstellung allgemeiner Informationen und das Management von Beschwerden [vgl. Ebner et al., 2007, S. 29]. Mitarbeiter im Call-Center, die den Dialog mit den Kunden führen, werden Agenten genannt [vgl. Greff und Fojut, 2003, S. 36]. Call-Center funktionieren, je nach Aufgabenstellung, in zwei verschiedenen Betriebsweisen: Inbound-Betrieb oder Outbound-Betrieb. Im Inbound-Betrieb gehen Anrufe von außen ein. Dabei sind wesentliche Kenngrößen in Bezug auf die Anrufe unbekannt, etwa wann der Anruf eingehen wird, wie lange er dauern wird und mit welchem Anliegen angerufen wird, was ein Call-Center zu einem stochastischem System mit sehr hoher Dynamik macht. Durch kontrollierte Planung und Steuerung wird dies ausgeglichen [vgl. Helber und Stolletz, 2004, S. 4]. Im Outbound-Betrieb werden Anrufe aus dem Call-Center heraus generiert, das heißt, das Call-Center ruft an. Dies kommt häufig bei Befragungen in der Marktforschung oder bei Meinungsumfragen zum Einsatz, aber auch, um Geschäfte abzuschließen oder um Kunden zu reaktivieren. Wie auch im Inbound-Betrieb ist der Outbound-Betrieb zufallsgetrieben, da die Dauer des Gesprächs vorab nicht bekannt ist [vgl. Helber und Stolletz, 2004, S. 6]. Call-Center sind nicht auf einen Standort begrenzt. Ein Call-Center kann weltweit auf verschiedene Standorte verteilt sein und dabei wie ein einziges Unternehmen arbeiten, dies nennt man virtuelles Call-Center [vgl. Greff und Fojut, 2003, S. 163]. Der Betrieb eines Call-Centers bringt folgende Vorteile für ein Unternehmen [nach Ebner et al., 2007, S. 29]: 1. Erbringung des Kundenservice unabhängig von Ort und Zeit, 2. Professionalisierung eines effektiven Kundenservice und 3. effizienter Kundenservice durch verbesserte Kostenstruktur. Eine Synthese der genannten Kernpunkte führt zu der in dieser Arbeit verwandten eigenen Abgrenzung: Call-Center: Als Call-Center wird eine organisatorische Einheit verstanden, die telefonische Kontakte mit Kunden abwickelt und den Auftrag der Erbringung des Kundenservice inne hat mit dem Ziel, diesen Kundenservice effektiv und effizient zu erbringen. Dies kann an einem Ort oder durch einen virtuellen Verbund mehrerer Standorte geschehen. Ein Call-Center ist dabei meist die einzige und wichtigste Schnittstelle zwischen den Kunden und der Unternehmung. Die angebotenen Dienstleistungen eines Call-Centers erstrecken sich dabei sowohl auf den Inbound- als auch auf den Outbound-Betrieb, immer unterstützt durch modernste Informations- und Kommunikationstechnologie.

2.2. Contact-Center als virtuelle Unternehmungen

13

Im Call-Center werden heutzutage nicht ausschließlich Telefondienstleistungen erbracht. [Schümann und Tisson, 2006, S. 18] beschreiben den Wandel wie folgt: „Call-Center unterlagen einem deutlichen Wandel von der Telefonzentrale zu einer High-Tech-MultikanalKommunikationseinheit. Die optimale Organisation von Kundenschnittstellen durch Aufbau und Betrieb von Call-Centern ist ein strategischer Wettbewerbsvorteil.“ Im Sinne des Begriffs „Multikanal“ werden von Agenten neben telefonischen Kundenanliegen auch Anliegen bearbeitet, die über andere Kanäle eingehen. Dazu gehören E-Mail, Chat, Fax, Brief und weitere denkbare Kanäle [vgl. Ebner et al., 2007, S. 28]. Daraus ergibt sich eine weitere Definition. Contact-Center: Als Contact-Center wird ein Call-Center bezeichnet, welches neben Telefondienstleistungen auch Dienstleistungen über weitere Kanäle wie beispielsweise E-Mail, Fax oder Chat bearbeitet. Dabei gelten die gleichen Rahmenbedingungen wie für Call-Center.

2.2. Contact-Center als virtuelle Unternehmungen Die Organisationsform eines Contact-Center sowie die Einbindung des Contact-Centers in ein Unternehmen sind auf vielfältige Art und Weise möglich. Die Hauptkriterien, die hierbei herangezogen werden, sind unter anderem die Unternehmensstruktur, Art und Größe des Contact-Centers, Aufgaben, Ziele und Schnittstellen zu anderen Unternehmensbereichen oder Unternehmen [vgl. Scupin, 2006, S. 24]. Contact-Center sind entweder Unternehmensabteilungen oder eigenständige Firmen [vgl. Schwetz, 2001, S. 31]. Dabei ergeben sich zwei Grundformen nach [Schümann und Tisson, 2006, S. 23]: 1. Ein Unternehmen führt die gesamte Kommunikation eigenständig durch, betreibt also ein eigenes, internes Contact-Center. 2. Ein Unternehmen übergibt als Auftraggeber einen Service- und Vertriebsprozess an ein rechtlich und finanziell eigenständiges Dienstleistungs-Contact-Center, wodurch eine virtuelle Organisationsvariante entsteht. Bei der klassischen Form ist das Contact-Center eine von mehreren Unternehmensfunktionen. Der Verantwortungsbereich des Contact-Centers ist dabei beschränkt, der Großteil der Verantwortung liegt in der Gesamtunternehmensführung. Die in der Contact-CenterPraxis eher anzutreffende Form ist die der virtuellen Unternehmung. Dabei werden nicht nur Teile von Geschäftsprozessen abgewickelt (wie etwa die Bestellannahme oder der Kundenservice) sondern komplette Vertriebs- und Serviceprozesse im Sinne des sogenannten „Business Process Outsourcing (BPO)“. Virtuelle Contact-Center-Unternehmungen sind dabei Unternehmenskonstellationen auf Zeit, die gegenüber Geschäftspartnern als geschlossene Einheiten auftreten. Die Virtualisierung erlaubt weitreichendere Formen der überbetrieblichen Arbeitsteilung und Spezialisierung, welche durch die Bündelung von

14


Kernkompetenzen ermöglicht werden. Im Innenverhältnis können die Unternehmensteile rechtlich oder finanziell unabhängige Leistungsträger sein (siehe Abbildung 4), im Außenverhältnis erscheinen die Leistungen der virtuellen Contact-Center-Organisation als eine Einheit. Realisiert werden dabei unternehmensübergreifende Geschäftsprozesse, wobei die einzelnen Teilprozesse in einer Kunden-Lieferanten-Beziehung stehen. An den Schnittstellen werden meist Leistungsvereinbarungen getroffen, sogenannte „Service Level Agreements (SLA)“.

Abbildung 4: Schema einer virtuellen Unternehmung [nach Schümann und Tisson, 2006, S. 25] Aus dem Konstrukt der verschiedenen Anspruchs- und Leistungskonstellationen ergibt sich in einer virtuellen Unternehmung ein spezielles Beziehungsgefüge zwischen dem Gesamtunternehmen, dem Contact-Center und den Endkunden. Die Einzelheiten hierzu zeigt Abbildung 5.

2.3. Aufbau und Organisation von Contact-Centern

15

Abbildung 5: Beziehungsgefüge Unternehmen – Contact-Center – Kunde [aus Schümann und Tisson, 2006, S. 23] Für den weiteren Verlauf dieser Arbeit wird aus den Betrachtungen einer virtuellen Unternehmung folgende Definition verwendet: Contact-Center: Als Contact-Center wird eine virtuelle Unternehmung bezeichnet, die als Dienstleistungspartner gegenüber anderen Unternehmen oder Unternehmensteilen alle oder einen Großteil der Geschäftsprozesse im Zusammenhang mit dem Kundenservice bearbeitet und über verschiedene Kontaktkanäle den direkten Kontakt mit Endkunden hält. Contact-Center nach diesem Verständnis bilden den Hintergrund dieser Arbeit.

2.3. Aufbau und Organisation von Contact-Centern Bisher wurde der Begriff „Contact-Center“ eingeführt und abgegrenzt. Darüber hinaus gibt es bei der Planung und Gestaltung eines Contact-Centers auch operative Gesichtspunkte. Der Aufbau und die interne Organisation eines Contact-Centers werden von drei Wirkfaktoren bestimmt: Den Menschen, die im Contact-Center arbeiten, der eingesetzten Technik und der gewählten Organisation des Unternehmens und seiner Prozesse (siehe Abbildung 6). Diese Wirkfaktoren tragen wesentlich zum Erfolg eines Contact-Centers bei [vgl. Böse und Flieger, 1999, Böse et al., 2001, S. 36 u. S. 6]. Zunächst dient die Darstellung des Aufbaus und der Organisation anhand der Wirkfaktoren Mensch — Technik — Organisation zum genaueren Verständnis der Ist-Situation

16


Abbildung 6: Wirkfaktoren im Contact-Center: Mensch, Technik, Organisation [nach Böse und Flieger, 1999, S. 36] in Contact-Centern. Darüber hinaus sind die Komponenten, die in den folgenden Abschnitten aufgeführt werden, auch für die Entwicklung des Referenzmodells von großer Bedeutung, da sie mitunter die Bausteine des Referenzmodells bilden, teilweise auch in veränderter Form. Für eine Annäherung an die Inhalte der Organisation in Contact-Centern ist das in der Literatur gängige organisatorische Strukturierungskonzept der Aufbau- und Ablauforganisation hilfreich. Für die Darstellung der Organisation werden hierzu die allgemeinen Wesenszüge der Aufbau- und Ablauforganisation grob skizziert und darauf basierend die in Contact-Centern vorhandenen Gemeinsamkeiten, bezogen auf Aufbau- und Ablauforganisation, herausgearbeitet4 . 2.3.1. Technik Contact-Center zeichnen sich durch einen speziellen Technologieeinsatz aus, der hauptsächlich durch technische Komponenten im Zusammenhang mit Kommunikationssystemen zu begründen ist [vgl. Scupin, 2006, S. 12]. Bei der Literaturrecherche fällt auf, dass wesentliche technische Komponenten, die sich mit der Entstehung des Call-Centers 4

Dies ist notwendig, da Contact-Center keine einheitlichen Organisationseinheiten sind. Sie weisen in den Bereichen Personal, Organisation und Technik nicht immer gleiche beziehungsweise ähnliche Merkmale auf. Es ergeben sich je nach Branche, Rechtsform, Größe, Aufgabengebiet und strategischer Zielsetzung unterschiedliche Anforderungen an die drei Gestaltungsfelder [vgl. Timm und Wieland, 2003, S. 223].


17

als Unternehmensform zusammen entwickelt haben, über diesen Zeitraum kontinuierlich dargestellt und aufgeführt werden (beispielsweise Telefonanlagen). Neuerungen im Zuge des technischen Fortschritts der letzten Jahre werden kaum oder nur sporadisch mit in die Darstellung aufgenommen. Es ist daher Ziel dieses Abschnitts, einen gesamthaften Überblick über den aktuellen Stand der Contact-Center-Technologie zu geben. Zur sinnvollen weiteren Untergliederung ergeben sich [u. a. nach Kraus und Cramoysan, 2008, Kraus und Blood, 2007, Helber und Stolletz, 2004, Menzler-Trott und Hahnel, 2001] folgende Themenkomplexe: • Telefonie-Infrastruktur und CTI • Multikanal-Kontaktverteilung und Routing • Sprachportale und Selbstbedienung • Proaktives Wählen • Agenten-Desktop • Business-Intelligence • Werkzeuge zur Qualitätskontrolle • Optimierungs- und Planungswerkzeuge Darüber hinaus wird in einem weiteren Abschnitt auf die Problemstellung beim Zusammenspiel klassischer IT-Komponenten, wie sie in den meisten Unternehmen vorkommen, mit den technischen Komponenten der Kommunikationssysteme eines Contact-Centers eingegangen.

Telefonie-Infrastruktur und CTI Telefongespräche anzunehmen und zu führen ist eine der Grundaufgaben seit Beginn der Call-Center-Entwicklung. Dafür ist in einem Contact-Center eine entsprechende Telefonie-Infrastruktur notwendig. Wesentliche Bestandteile dieser Infrastruktur sind die Anbindung an das öffentliche Telefonnetz5 über einen sogenannten Provider, eine Telefonanlage, ein Leitungsnetz sowie Telefonapparate am Arbeitsplatz. Das Kernstück bildet die Telefonanlage beziehungsweise „Private Branch Exchange“ (PBX), die den internen und externen Telefonverkehr regelt und Dienste wie „Gespräch führen“, „Wählen“, „Makeln“, „Halten“, „Verbinden“, „Wartemusik“ und weitere Dienste ermöglicht [vgl. bspw. Greff und Fojut, 2003, S. 128, 151]. Im Zuge der weiteren technologischen Entwicklung folgte die Verbindung der TelefonieInfrastruktur mit der bestehenden IT-Anwendungen; diese Verbindung beider technischer Welten wird allgemein als „Computer Telephony Integration“ (CTI) bezeichnet [Greff und 5

Weiterer häufig gebrauchter Begriff: „Public Switched Telephone Network“ (PSTN) [vgl. Greff und Fojut, 2003, S. 130]

18


Fojut, 2003, S. 55], [Hild, 2003, S. 76]. Genauer definiert [Stockberger, 2001] den Begriff CTI (vergleiche dazu auch Abbildung 7): „[CTI] setzt das Telefonnetz, die Sprachübermittlung, den Datenfluß, die einzelnen Geschäftsanwendungen, Unternehmensdatenbanken und weitere Medien [...] zu einer funktionierenden Einheit zusammen. Damit können zwischen allen Beteiligten Anwendungen Daten ausgetauscht werden und die Abläufe koordiniert werden.“ [Stockberger, 2001, S. 306]

Abbildung 7: Überblick über Computer Telephony Integration im Call Center [nach Stockberger, 2001, S. 305] Mit Hilfe von CTI ist eine Anpassung der technischen Abläufe an den organisatorisch sinnvollen Arbeitsablauf und ihre Optimierung möglich. So können in diesem Zusammenhang mit Hilfe von CTI-Funktionen Informationen über ein Gespräch an andere Systeme übergeben werden, die wiederum eine sinnvolle Kontrolle des Gesprächs von außerhalb der Telefonie-Infrastruktur ausüben. Eine automatische Erkennung des Kunden (etwa anhand der übermittelten Rufnummer) kann beispielsweise Kundendaten vorab laden oder die automatisierte Protokollierung von Anrufen übernehmen [vgl. bspw. Yarberry, 2002, S. 49 ff.], [Greff und Fojut, 2003, S. 55].


19

CTI befindet sich derzeit in einem Veränderungsprozess, da Informations- und Kommunikationstechnologie immer mehr verschmelzen. CTI bietet Integration dort, wo diese notwendig ist. Funktionalitäten der Kommunikationstechnologie werden zusehends mit Hilfe der IT abgebildet. Dieser Trend ist erkennbar anhand der Internet-Telefonie mit Hilfe von „Voice over IP“ (VoIP). Anstatt Gespräche über das öffentliche Telefonnetz zu vermitteln, findet bei VoIP eine Vermittlung des Gesprächs sowie die Übertragung der Sprache mit Hilfe IP-basierender6 Netze statt. Der bekannteste Standard hierzu ist das „Session Initiation Protocol“ (SIP)7 . Dieser Technologiesprung findet zusehends auch Umsetzung in Contact-Centern. Derzeit überwiegen im europäischen Contact-Center-Bereich noch klassische Telefonie-Infrastrukturen mit herkömmlichen Telefonanlagen und CTI-Lösungen. Eine zunehmende Zahl von Contact-Centern migrieren jedoch bereits hin zu Softwareorientierten Lösungen [vgl. Kraus und Blood, 2007, S. 2 - 3]. Multikanal-Kontaktverteilung und Routing Die automatische und sinnvolle Verteilung von Anrufen an freie Agenten ist durch ein weiteres zentrales technisches System in einem Contact-Center abgedeckt. Dieses System zur automatischen Anrufverteilung wird als „Automatic Call Distributor“ (ACD) beziehungsweise ACD-Anlage bezeichnet. Die ACD-Anlage verteilt in ihrer ursprünglichen Aufgabe ankommende Anrufe nach vorprogrammierten Regeln an freie Agenten. Gibt es im Moment des Anrufeingangs keine freien Agenten, kann der Anruf in ein sogenanntes Wartefeld umgeleitet werden oder an eine andere Gruppe von Agenten mit anderen Aufgaben weitergeleitet werden. Diese Verteilung in der ACD-Anlage wird als Routing bezeichnet. Die ACD-Anlage behält neben dem Routing die Kontrolle über einen Anruf vom Anrufeingang bis zum Abschluss des jeweiligen Kundenanliegens (der Agent meldet sich an der ACD-Anlage erst nach Ende der Nachbearbeitung eines Anrufs als bereit für den nächsten Anruf). Sie erfasst dafür alle mit einem Anruf zusammenhängenden Daten und stellt somit die Datengrundlage für eine Darstellung und Aufbereitung von Kennzahlen, dem sogenannten Reporting, dar [vgl. Scupin, 2006, S. 13 ff.], [Greff und Fojut, 2003, S. 19 - 20, 46 - 47], [Böse et al., 2001, S. 77 ff.], [Böse und Flieger, 1999, S. 144 ff.]. Im Sinne des Multikanal-Managements8 bedienen auch Contact-Center weitestgehend alle Kontaktkanäle, die von Kunden genutzt werden. Dazu gehören neben dem klassischen Kanal der Telefonie die Kanäle E-Mail, Fax, Post (gescannte Briefe), Internet (beispielsweise Kontaktformulare, Rückruf-Buttons, Chat und ähnliches) und weitere. Jedes Kundenanliegen, auch ein Telefonanruf, wird als Kontakt bezeichnet. Diese Kontakte gehen 6

Internet Protocol (IP) [spezifiziert in IETF, 1981]. SIP [spezifiziert in IETF, 2002] dient in der IP-Telefonie als Signalisierungsprotokoll, das heißt zur Rufsteuerung. Die Übertragung der Sprach- oder Multimediadaten erfolgt über andere Echtzeitprotokolle [vgl. zum Überblick Trick und Weber, 2007, S. 33 ff.], [Sinnreich und Johnston, 2006] 8 Vergleiche zum allgemeinen Begriff Multikanal-Management beispielsweise [Ahlert et al., 2003], [Merx und Bachem, 2001]. 7

20


technisch getrennt nach Kanälen im Contact-Center ein, fachlich müssen die Kundenanliegen der Kontakte aber gemeinsam im Contact-Center bearbeitet werden. Kanäle mit unmittelbarer Kommunikation (Telefonie) werden dabei als synchron bezeichnet, Kanäle mit mittelbarer Kommunikation (E-Mail, Fax und andere) als asynchron [vgl. Amberg, 2004, S. 56]. Moderne ACD-Anlagen übernehmen heutzutage bereits in manchen Contact-Centern die gemeinsame Verteilung der Kontakte mehrerer Kanäle. So kann es sein, dass ein Agent nach Beendigung eines Kundenanliegens per Telefon kein weiteres Telefongespräch zugestellt bekommt, sondern eine E-Mail mit einer dringenden Kundenanfrage, die schnell beantwortet werden muss. Das Routing der ACD-Anlage wird dabei von folgenden Parametern gesteuert: • Priorität: Die Priorität eines Kontakts kann nach mehreren Gesichtspunkten zugeordnet werden. Beispielsweise ist eine Priorisierung nach Eingangskanal möglich. Telefonanrufe bekommen dabei die höchste Priorität, um sofort beantwortet zu werden. Kontakte anderer Kanäle bekommen auf Grund des Kanals eine niedrigere Priorität, die sich mit zunehmender Wartezeit erhöht. Prioritäten können ebenso nach Art des Kundenanliegens des Kontakts vergeben werden. Beispielsweise können so Bestellungen vor Auskunftsanfragen bearbeitet werden. Hierzu ist eine Klassifizierung des Anliegens notwendig. Die geschieht abhängig vom Kanal unterschiedlich. Telefonanrufe können durch ein vorgeschaltetes Sprachportal klassifiziert werden, indem über die Telefontastatur oder über Spracherkennung die Art des Anliegens eingeordnet wird. Bei schriftlichen Vorgängen kann die Klassifizierung über Inhaltsanalyse erfolgen [vgl. L’Ecuyer, 2006, S. 145]. • Skills: Eine einfache Form der Verteilung auf Agenten wäre die Verteilung an den am längsten wartenden freien Agenten („longest idle“). Agenten sind jedoch meist einer oder mehreren Aufgabenbereichen zugeordnet, wofür sie unterschiedlich qualifiziert sind. Darüber hinaus haben Agenten weitere Kompetenzen und Fähigkeiten, die unterschiedlich ausgeprägt sind (beispielsweise schriftliche Ausdrucksfähigkeit, Fremdsprachenkenntnisse, Umgang mit schwierigen Kunden). Diese Kompetenzen und die fachlichen Fähigkeiten werden im Routing in sogenannten Skills abgebildet, ihre jeweilige Ausprägung in einem Skill-Level. Skills und Skill-Level der Agenten sind in der ACD-Anlage hinterlegt und beeinflussen die Entscheidung, welcher Kontakt an welchen Agenten geroutet wird. Ziel ist dabei, den am besten geeigneten und verfügbaren Agenten zuzuteilen [vgl. bspw. North und Reinhardt, 2005], [Helber und Stolletz, 2004, S. 103 ff.], [Cleveland et al., 2002, S. 118 ff.]. • Service-Level: Vertragliche Regelungen zwischen einem Unternehmen und seinem Dienstleister werden als „Service Level Agreements“ (SLA) bezeichnet, in denen die verschiedenen Grade der Dienstleistungserfüllung (sogenannte „Service Level“) ge-


21

regelt sind9 . Typische Service-Level für Contact-Center als Dienstleistungsunternehmen im Customer-Care-Bereich sind beispielsweise die Erreichbarkeit, die Wartezeit bis zur Entgegennahme des Anrufs oder die gesamte Bearbeitungszeit. Die Erreichung oder Nichterreichung der Service-Level können ebenso als Kenngrößen für die Routingsteuerung dienen. Dabei wird zu jeder Zeit der aktuelle Service-Level ermittelt und je nach Über- oder Unterschreiten das Routing flexibel angepasst (etwa durch Zuschalten von Agenten mit geringerem Skill-Level für die jeweilige Aufgabe) [vgl. bspw. Schmidt, 2007, S. 63 ff.], [Bommer, 2007, S. 87 ff.]. Routing ist nicht auf den jeweiligen Standort eines Contact-Centers beschränkt. In einem Verbund mehrerer Standorte zu einem virtuellen Contact-Center kann das Routing Kontakte zwischen allen Standorten verteilen. Routing kann dabei noch zwei weitere Bereiche mit einschließen: Zum einen ist eine Anbindung an eine übergeordnete Verteilung denkbar, etwa ein vorgeschaltetes Routing beispielsweise durch den Telekommunikationsprovider. Zum anderen lassen sich virtuelle Contact-Center-Verbünde um Heimarbeitsplätze erweitern, sogenannte „Home Agents“, denen Kontakte an den Arbeitsplatz zu Hause zugestellt werden.10

Sprachportale und Selbstbedienung Sprachportale dienen der Selbstbedienung von Kunden über das Telefon. Das technische System, das ein Sprachportal implementiert, nennt man „Interactive Voice Response“ (IVR). Die einfachste Form, und eine Vorstufe zur tatsächlichen Selbstbedienung, ist „Voice Mail“. Dies ist vergleichbar mit einem Sprachpostfach für Anrufe, die außerhalb der Öffnungszeiten eintreffen oder wegen zu hoher Auslastung keinen freien Agenten zugewiesen bekommen. Dabei besteht die Möglichkeit für Anrufer, Nachrichten mit ihrem Anliegen zu hinterlassen für einen späteren Rückruf durch das Contact-Center. Diese Nachrichten können über das Routing dem nächsten freien Agenten zugeteilt werden [vgl. Greff und Fojut, 2003, S. 97, 164 - 165]. In einem Sprachportal werden dem Kunden Sätze mit Hinweisen und Aufforderungen vorgesprochen, sogenannte „Voice Promts“. Diese können vorher aufgezeichnet worden sein („pre-recorded“) oder vom Computer automatisch generiert werden („text-to-speech“) [Lassmann, 2006, S. 537]. Die eigentliche Selbstbedienung kann mittels Tastentönen über 9

Die Herleitung des Begriffs SLA und Service-Level im Kontext von Contact-Centern ebenso wie einen Überblick aktueller Definitionen bietet [Schmidt, 2007, S. 64 - 66]. 10 Reduziert man die obige Darstellung des Routings auf die zu Grunde liegende Problemstellung, so lässt sich diese wie folgt zusammenfassen: Eine automatisierte und optimale Zuordnung eines Dienstleistungsanbieters zu einem Nachfrager. In einer zunehmenden Dienstleistungsgesellschaft (vergleiche Kapitel 3.2.1) und dem Einfluss des Internet wird dies auch im größeren Kontext eine wichtige Problemstellung, die in der Forschung und Wissenschaft ihre Aufmerksamkeit findet. Unter dem Begriff „Service Network“ wird dieser Themenkomplex betrachtet [vgl. bspw. Berkeley, 2008]. Zu „Service Network“ mit Bezug auf Contact-Center bietet [Mandelbaum, 2008] einen guten Überblick über die aktuelle Literatur.

22


das Telefon erfolgen11 oder durch Sprachsteuerung. Bei der Sprachsteuerung ist ähnlich den Tastentönen eine Erkennung von Worten mittels „Automatic Speech Recognition“ (ASR)12 ebenso wie die komplette Erkennung von gesprochenen Sätzen13 denkbar, möglich durch das sogenannte „Natural Language Understanding“ (NLU) [vgl. Lassmann, 2006, S. 537 - 538], [Helber und Stolletz, 2004, S. 95 ff.], [Greff und Fojut, 2003, S. 97]. IVR-Technologien werden bislang zur Prozessoptimierung, wie beispielsweise der Nutzung von Wartezeiten der Anrufer im Wartefeld sowie zur automatischen Abbildung von wiederkehrenden Standardtätigkeiten genutzt. Ziel ist es, durch Selbstbedienung in der Telefonie Kosteneinsparungen zu erzielen [vgl. Lassmann, 2006, S. 537 - 538], [Datamonitor, 2007, S. 5]. Rund 44 Prozent der Contact-Center in den USA und Europa nutzen Sprachportale mittels IVR, etwa die Hälfte davon nutzt vollautomatische IVR-Systeme (mit ASR beziehungsweise NLU) [vgl. Herrell et al., 2006]. Die Nutzung von IVR wird in Contact-Centern weiter ausgebaut und dabei werden auch höherwertige Dienste mittels IVR abgedeckt. Dabei kommen sowohl offene Standards14 für Sprachportalanwendungen zum Tragen als auch Weiterentwicklungen über die Sprache hinaus. So sind mittels IVR-Technologie auch multimediale Erweiterungen denkbar, etwa Video-Helpdesks und weitere Multimedia-Subsysteme [vgl. Datamonitor, 2007, S. 5 - 7], [Herrell et al., 2008, S. 1 - 2].

Proaktives Wählen Im Outbound-Betrieb eines Contact-Centers werden ausgehende Gespräche nicht mehr durch den Agenten gewählt sondern durch ein automatisches Wählsystem, einen sogenannten Dialer, das mit Telefonnummern aus einer Datenbank bestückt wird. Dabei werden nur durchgehende Anrufe, das heißt von Personen angenommene Anrufe, zum Agenten weitergeleitet. Anrufe, die ein Besetztzeichen erhalten oder von einem Anrufbeantworter beantwortet werden, erkennt das System und stellt diese nicht durch. Die Anzahl der vorab zu wählenden Verbindungen wird durch stochastische Verfahren anhand von Gesprächs- und Nachbearbeitungszeiten durch den Dialer ermittelt, wobei die Verfügbarkeit des jeweiligen Agenten antizipiert wird. Diese Gesamtheit an Funktionen eines Dialers wird als proaktives Wählen beziehungsweise als „predictive dialing“ bezeichnet [vgl. bspw. Krumm und Geissler, 2005, S. 50], [Greff und Fojut, 2003, S. 125 - 127].

Agenten-Desktop Ein vereinheitlichter Agenten-Desktop fasst alle für die Bearbeitung eines Kontakts wichtigen Informationen und Anwendungssysteme, die für eine effiziente Bearbeitung notwendig sind, am Bildschirm des Agenten zusammen. Informationen sollen dabei leicht zugänglich sein und relevante Kundendaten vorbefüllt werden. Ziel ist 11

Beispiel: „Drücken Sie die Eins für Bestellungen, drücken Sie die Zwei für Auskünfte“. Beispiel: „Für Bestellungen sagen Sie bitte „Bestellung“, für Auskünfte sagen Sie bitte „Service“. 13 Beispiel: „Wie lautet der aktuelle Kurs der BASF-Aktie an der Börse Frankfurt am Main?“ 14 VoiceXML 2.0 [standardisiert in W3C, 2004d] 12


23

eine Reduzierung der Bearbeitungszeit. Dies wird teilweise dadurch erreicht, dass weniger Arbeitsschritte durch vereinheitlichte Informationen und Anwendungssysteme am Bildschirm notwendig sind oder durch Automatisierung vorab bekannter Arbeitsschritte in den Benutzeroberflächen der benötigten Anwendungssysteme. Die notwendigen Basisund Kundendaten werden durch CTI-Funktionalitäten bereitgestellt [vgl. bspw. Herrell, 2007, S. 6]. Business-Intelligence Der Begriff Business-Intelligence (BI) wird sehr weitläufig verwendet15 . Für die Darstellung von BI als technische Komponente zur Entscheidungsunterstützung in Contact-Centern gibt es jedoch eine ausreichende Abgrenzung [vgl. hierzu Kemper et al., 2006, S. 3 - 4]. Demnach werden unter BI alle (direkten und indirekten) technischen Komponenten verstanden, die für die Entscheidungsunterstützung des Managements eingesetzt werden. Dazu gehören sowohl eine Auswertungs- und Präsentationsfunktionalität als auch die Datenaufbereitung und die Datenspeicherung. Im engeren Sinne versteht man unter BI nur wenige Kernapplikationen (siehe hierzu bspw. [Kimball, 2002]) für eine unmittelbare Unterstützung der Entscheidungsfindung. Im Rahmen des BI sind im Contact-Center zwei Arten von Kennzahlenberichten (auch Reports genannt) zu unterscheiden: Echtzeit-Kennzahlenberichte und historische Kennzahlenberichte. Für beide Dimensionen sind die wesentlichen Zielgrößen die mittlere Wartezeit, die Bedienwahrscheinlichkeit (Erreichbarkeit) und die Auslastung [vgl. Helber und Stolletz, 2004, S. 42 - 43], [Zapf, 2003]. Für die Generierung gibt es Contact-Centerspezifische Datengrundlagen. Wesentliche Datenquellen sind dabei die ACD-Anlage, der Dialer und das IVR-System sowie alle anderen zur Sachbearbeitung benötigten Anwendungssysteme [vgl. bspw. Jahnke und Rabbe, 2001, S. 154], [Böse und Flieger, 1999, S. 142 ff.]. Die besondere Problemstellung dabei bildet die Integration vieler Datenquellen über Schnittstellen in ein BI-System sowie die logische Verbindung der kommunikationstechnologischen Daten mit den Daten der Anwendungssysteme, die den jeweiligen Fachprozess unterstützen, zu aussagekräftigen Kennzahlen [vgl. bspw. Schümann und Tisson, 2006, S. 140 ff.]. Werkzeuge zur Qualitätskontrolle Als technische Werkzeuge zur Qualitätskontrolle und Qualitätsverbesserung werden in Contact-Centern Systeme eingesetzt, die den Dialog zwischen dem Agenten und dem Kunden aufzeichnen. Neben dem einfachen Zuhören durch ein zweites Headset am Arbeitsplatz durch einen Trainer sind Gesprächsaufzeichnungen eine weit verbreitete Methode zur Qualitätskontrolle, um so dem Agenten Feedback über seine Arbeitsleistung geben zu können. Moderne Systeme erweitern diese Funktionalität um die Aufzeichnung des Bildschirms und die darin ausgeführten Aktivitäten, um sowohl 15

Einen Überblick über die verschiedenen Verwendungen des Begriffs Business-Intelligence mit der Fragestellung der wissenschaftlichen Notwendigkeit eines eigenen Begriffs gibt [Mertens, 2002].

24


das Kundengespräch als auch die jeweilige Umsetzung des Prozesses im System kontrollieren zu können [vgl. bspw. Sharp, 2003, S. 81 - 82], [in Manzey, 2001, S. 86ff.]. Optimierungs- und Planungswerkzeuge Für die Planung der täglichen Abläufe im Sinne der Ablaufsteuerung (siehe Abschnitt 2.3.4) sind Systeme im Einsatz, die alle Planungsschritte unterstützen: die Hochrechnung einer Prognose der geplanten Kontakte, die Berechnung des Personalbedarfs sowie die detaillierte Schicht- und Personaleinsatzplanung. Dabei spielt die Integration von Daten und Kennzahlen anderer Systeme eine wichtige Rolle, beispielsweise der ACD-Anlage oder des BI [vgl. Schümann und Tisson, 2006, S. 27, Kap. 2.2.2], [Helber und Stolletz, 2004, S. 155 ff.]. 2.3.2. Problemstellung der IT-Landschaft in Contact-Centern Die in den obigen Abschnitten dargestellten technischen Komponenten sind meist spezifisch für Contact-Center. Sie dienen im weitesten Sinne der Kommunikation zwischen Agenten und Kunden und der Organisation der Kommunikation. Neben der technischen Unterstützung der Kommunikation werden von den Agenten die eigentlichen Geschäftsvorfälle der Kundenanliegen bearbeitet. Dies bedarf weiterer operativer IT-Anwendungen, die Funktionen der Fachgebiete wie beispielsweise Bestellwesen, Vertrieb, Finanzbuchhaltung oder Lagerverwaltung abdecken. Diese operativen IT-Anwendungen sind meist aus ihren betriebswirtschaftlichen originären Aufgabenbereichen unabhängig voneinander und unabhängig von der Kommunikationstechnologie entstanden, welches die Bildung einer heterogenen Systemlandschaft mit sich bringt. Die IT-Landschaft in Contact-Centern kann grundsätzlich in zwei Teile gegliedert werden [vgl. bspw. Helber und Stolletz, 2004, S. 9]: 1. IT-Anwendungen zur Kommunikation und 2. IT-Anwendungen zur Unterstützung der Bearbeitung operativer Geschäftsprozesse. Eine Herausforderung besteht hier in der Verknüpfung und Integration beider Teile beziehungsweise Aufgabenkreise. Diese Verknüpfung ist aus betriebswirtschaftlicher Sicht notwendig, da für eine integrierte Planung und Steuerung eines Contact-Centers Informationen aus beiden Bereichen notwendig sind. Es entsteht die Fragestellung der Verwaltungshoheit und somit „[steht] insbesondere die Integrationsfrage im Vordergrund, das heißt, welche Systeme verwalten welche Daten und Informationen und wie sind diese in einem sinnvollen Steuerungssystem zusammenzuführen“ [Schümann und Tisson, 2006, S. 140]. Daraus können sich Schnittstellenprobleme ergeben, dort wo eine Integration möglich ist, und Medienbrüche, dort wo eine Integration nicht möglich ist [vgl. Schümann und Tisson, 2006, S. 140], [Helber und Stolletz, 2004, S. 9]. Nach [Schümann und Tisson, 2006, S. 140] sind bei der sich daraus gebenden Lösungsfindung folgende Fragestellungen sinnvoll:


25

• „Welche Systeme insgesamt sind im Einsatz? • Welche Daten werden wo verwaltet? • Wie können aus Daten Informationen werden, indem sie sinnvoll so zusammengeführt werden, dass mit ihnen das Unternehmen gesteuert werden kann? • Bieten die im Einsatz befindlichen Systeme flexible Auswertungs- und Analysefunktionen? • Wie kann in einem solchen Informationssystem navigiert und können dabei unter Umständen auch ad hoc neue Informationsinhalte geschaffen werden?“ Diese Fragestellungen der Integration verschiedener Systeme werden bei der Bildung des Referenzmodells entsprechend berücksichtigt. 2.3.3. Aufbauorganisation Die Aufbauorganisation befasst sich mit Hierarchieebenen, Verantwortlichkeiten und Funktionen einer Unternehmung. Ihre wichtigsten Strukturmerkmale sind die Abteilungsgliederung, ein System der Weisungsbefugnisse sowie die Entwicklung eines Kommunikationssystems [vgl. bspw. Laux und Liermann, 2003, S. 18], [allg. auch Bühner, 2004, S. 61 ff.], [Kosiol, 1976]. Abteilungsgliederung In der klassischen Theorie der Aufbauorganisation werden Zuordnungen beziehungsweise Zusammenfassungen von (Teil-)Aufgaben zu personalen Aufgabenträgern unter dem Begriff der Organisationseinheit vorgenommen [vgl. Kosiol, 1976, S. 89 ff.]. In Bezug auf die zur Aufgabenerfüllung eingesetzten Menschen spricht man von Stellen und Stellenmehrheiten. Eine Stelle ist dabei „[...] die kleinste organisatorisch zu definierende Organisationseinheit. Sie entsteht durch Zuordnung von (Teil-)Aufgaben und gegebenenfalls von Sachmitteln auf einen einzelnen menschlichen Aufgabenträger“ [Bühner, 2004, S. 61]. Werden Stellen zusammengefasst, spricht man von Stellenmehrheiten, werden sie einer Leitungsinstanz unterstellt, so spricht man von einer Abteilung [vgl. Bühner, 2004, S. 82 f.]. Auf Grund einer häufig hohen Anzahl von Agenten mit gleichen oder ähnlichen Aufgaben, die sich jedoch im Einsatz des benötigten Fachwissens und anderer Kompetenzen (ihrer Skills) unterscheiden, ist eine Gliederung der Agenten in Abteilungen unüblich. Es ist häufig eine Gliederung von Stellenmehrheiten nach Qualifikations- und Kommunikationsmix in Contact-Centern anzutreffen [vgl. Zapf, 2003, S. 31 ff.]. Hierbei wird eine Aufteilung in Skill-Gruppen vorgenommen und ein grundlegendes Schichtenmodell entwickelt [vgl. L’Ecuyer, 2006, S. 147]. Neben der Gliederung der Stellenmehrheiten ist es ebenso Teil der Aufbauorganisation, die grundsätzliche Art und Weise, wie Kundenanliegen im ContactCenter verteilt werden, festzulegen [vgl. Böse und Flieger, 1999, S. 132 - 141, 217]. Dies

26


konkretisiert sich in der Entwicklung einer Routingstrategie für das Contact-Center mit entsprechender Zuweisung von Skills, Skill-Level und Skillgruppen, wofür meist eine eigene administrative Abteilung oder Gruppe (beispielsweise als „Multikanal-Management“ bezeichnet) zuständig ist. Bei der Differenzierung nach dem Qualifikationsmix der Agenten wird allgemein eine Aufteilung nach Generalisten und Spezialisten vorgenommen, die entsprechend dieser Aufteilung und nach ihren fachlichen Fähigkeiten in Skills eingeteilt werden. Eine Aufteilung in ein 1-Ebenen-Modell, ein n-Ebenen-Modell oder in ein Back-Office-Modell ist dabei üblich16 .

Abbildung 8: Modelle der Aufbauorganisation im Contact-Center [in Anlehnung an Zapf, 2003, S. 33 - 35] Beim n-Ebenen-Modell werden Generalisten in einem sogenannten 1st-Level zusammengefasst. Im First-Level werden alle eingehenden Anliegen aller Kommunikationskanäle 16

Die Aufteilung nach Qualifikationsmix in diese drei Modelle erfolgt in weitestgehende Anlehnung an [Zapf, 2003]. Das 2-Ebenen-Modell wurde hier in ein n-Ebenen-Modell umbenannt, da in diesem Modell auch mehr als zwei Ebenen möglich und in der Praxis auch anzutreffen sind. Diese Aufteilung wird gestützt durch Expertenbefragungen in den Jahren 2006 bis 2008.


27

bearbeitet. Standardanliegen werden von den Generalisten bearbeitet. Komplexere Anliegen, die ein detailiertes Fachwissen oder andere Kompetenzen benötigen, werden vom First-Level in den Second-Level zur weiteren Bearbeitung weitergeleitet. Dieses Modell kann um weitere Ebenen erweitert werden. Üblich ist eine Einteilung bis maximal ThridLevel [vgl. Zapf, 2003, S. 33]. Das 1-Ebenen-Modell ist die einfachste Form der Aufbauorganisation. Dabei können alle eingehenden Anliegen aller Kommunikationskanäle von Generalisten und Spezialisten gleichermaßen bearbeitet werden [vgl. Zapf, 2003, S. 34]. Eine Trennung nach synchronen und asynchronen Kommunikationskanälen findet beim Back-Office-Modell statt. Hier werden alle synchronen Kundenanliegen (hauptsächlich Telefonanrufe) im sogenannten Front-Office beantwortet. Das Front-Office besteht dabei aus den Generalisten. Komplexere Anliegen werden, analog dem n-Ebenen-Modell, an das Back-Office weitergeleitet. Im Back-Office bearbeiten Spezialisten, meist Sachbearbeiter, alle asynchronen Kundenanliegen sowie die weitergeleiteten synchronen Kundenanliegen [vgl. Zapf, 2003, S. 33 - 34], [Hild, 2003, S. 77 - 78]. Einen Überblick über die Modelle nach Qualifikationsmix zeigt Abbildung 8. Neben dem Qualifikationsmix ist auch eine Einteilung nach dem Kommunikationsmix möglich. Entscheidend ist hierbei, ob die Kommunikationskanäle getrennt oder integriert bearbeitet werden. Bei einer Trennung nach Kanälen werden eigene Gruppen von Agenten für die einzelnen Kanäle gebildet, bei einer Integration können von einzelnen Gruppen Kundenanliegen aller Kanäle bearbeitet werden [vgl. Zapf, 2003, S. 35 - 37]. In modernen Contact-Centern ist eine Aufteilung nach dem n-Ebenen-Modell mit integrierten Kommunikationskanälen üblich. Dabei wird ein Großteil der Kundenanliegen automatisch über eine ACD-Anlage geroutet (siehe Abschnitt 2.3.1, Multikanal-Kontaktverteilung und Routing).

Weisungsbefugnisse und Hierarchieebenen Contact-Center weisen meist eine flache Hierarchieabstufung in Kombination mit einfachen und transparenten Strukturen auf, welche im Allgemeinen eine flexible Anpassung der Organisation erlauben [vgl. Thieme und Steffen, 2000, S. 45]. In der Regel wird zwischen vier Hierarchieebenen unterschieden17 : Contact-Center-Manager, Supervisor beziehungsweise Steuerer, Teamleiter sowie die Agenten (siehe Abbildung 9) [vgl. Scupin, 2006, S. 24]. Der Contact-Center-Manager trägt die Gesamtverantwortung für die betrieblichen Abläufe im Contact-Center. Zu seinen Aufgaben gehören unter anderem die strategische Unternehmensführung sowie die Auftragsakquisition, die Qualitätssicherung und das Controlling [vgl. Scupin, 2006, S. 22]. 17

Eine Einbindung der virtuellen Unternehmung Contact-Center in eine eventuell vorhandene übergeordnete Gesamtorganisation (siehe Kapitel 2.2, Contact-Center als virtuelle Unternehmungen) wird hier nicht besprochen, siehe dazu [bspw. Schümann und Tisson, 2006], [Böse und Flieger, 1999].

28


Abbildung 9: Aufbauorganisation im Contact-Center [in Anlehnung an Scupin, 2006, S. 22] Dem Contact-Center-Manager unterstellt ist die Position des Supervisors (teilweise auch Steuerer genannt). Es ist die Aufgabe des Supervisors, die Planung und Steuerung der täglichen Abläufe durchzuführen und zu koordinieren. Neben der Schicht- und Personaleinsatzplanung muss diese Planung mit dem jeweiligen Verlauf des aktuellen Tagesgeschäfts abgeglichen werden. Dabei muss eventuell korrigierend in die Personalzusammenstellung eingegriffen oder eine Feinsteuerung der technischen Systeme vorgenommen werden. Die Bereitstellung der statistischen Daten durch das BI ist dabei besonders wichtig [vgl. bspw. Scupin, 2006, S. 22], [Helber und Stolletz, 2004, S. 155 ff.]. Der Teamleiter führt als direkter Vorgesetzter mehrere Agents, in der Regel bis zu 20, mit zunehmender Größe von Contact-Centern auch mehr. Zu den Aufgaben des Teamleiters gehören die Qualitätssicherung im Sinne der Gesprächsführung sowie die fachliche Aus- und Weiterbildung der Agenten. Der Teamleiter ist disziplinarischer Vorgesetzter und unterstützt Agenten in schwierigen Situationen, wie beispielsweise bei komplexen Kundenanfragen [vgl. Scupin, 2006, S. 22 - 23].

Kommunikationssystem Als Kommunikationssystem im Sinne der Aufbauorganisation werden allgemeine Verhaltensnormen bestimmt, die Kommunikationsaufgaben festlegen, das heißt in welchen Fällen Informationen zu übermitteln und zu beschaffen sind (Bringschuld und Holschuld von Informationen), welche Kommunikationswege dabei einzuhalten sind und welche Kommunikationsmittel verwendet werden. Ebenfalls Teil des Kommunikationssystems sind Regelungen, wie Informationen gespeichert werden und wie der Zugriff darauf geregelt ist [vgl. Laux und Liermann, 2003, S. 188]. Im Zusammenhang mit dem Kommunikationssystem ergibt sich im Contact-Center eine besondere Situation. Dies liegt begründet in der besonderen Verwendung der eingesetzten Kommunikationstechnologie und einer entsprechenden Ausrichtung auf effiziente und


29

automatisierte Kommunikationswege innerhalb des Contact-Centers. Durch das Routing von Kundenkontakten und eventuelle Weiterleitungen von Kundenkontakten oder Teilaufgaben an Spezialisten, die ebenfalls über das Routing abgewickelt werden, gibt es im Contact-Center ein stark technisch gestütztes, automatisiertes und somit präzises Kommunikationssystem. (Im Rahmen des Referenzmodells werden Informationen zu einzelnen Arbeitsaufgaben modelliert und durch die Prozessautomatisierung automatisiert an den Agenten übermittelt.)

2.3.4. Ablauforganisation Während die Aufbauorganisation den groben strukturellen Rahmen für einen ordentlichen Geschäftsablauf vorgibt, versucht die Ablauforganisation die Verrichtungs- und Steuerungsabläufe konkreter festzulegen und durch Regelungen zu präzisieren. Unter Ablauforganisation wird dabei eine zielgerichtete Strukturierung von Arbeitsprozessen verstanden. Die Ablauforganisation beinhaltet sowohl rein ausführende Tätigkeiten als auch Entscheidungsabläufe. Dies konkretisiert sich durch Arbeits- oder Dienstvorschriften oder in Prozessmodellen, die hauptsächlich die Beschreibung einzelner Abläufe genauer festlegen [vgl. bspw. Remer und Hucke, 2007, S. 39 u. 152], [Laux und Liermann, 2003, S. 180 u. 190]. Bezogen auf die konkrete Arbeitsausführung und Arbeitsgestaltung im Contact-Center wird dies durch standardisierte Gesprächsleitfäden, festgelegte Argumentationsrichtlinien oder darauf speziell ausgerichtete Anwendungssoftware umgesetzt. Dadurch werden Agenten vordefiniert durch Gesprächssituationen oder andere Anwendungsfälle geleitet. Die Ablauforganisation in Contact-Centern ist darauf ausgelegt, den Agenten überwiegend ausführende Tätigkeiten zuzuweisen und möglichst eine fallabschließende Bearbeitung zu erreichen. Dies führt zu einer Standardisierung von Tätigkeiten und somit zu kurzen Bearbeitungs- und Durchlaufzeiten [vgl. Scupin, 2006, S. 29]. Die Zuteilung und Verteilung der Arbeit geschieht meist durchgehend automatisiert mit Hilfe des Routings durch die ACD-Anlage. Planungs- und Steuerungsarbeiten werden dabei nicht von den Agenten ausgeführt. Die Planungs- und Steuerungshoheit wird in der Ablauforganisation eines Contact-Centers der Stelle des Supervisors zugeteilt. Im Rahmen der Ablauforganisation beziehen sich die Tätigkeitsbeschreibungen des Supervisors18 auf folgende vier Hauptaufgaben [vgl. L’Ecuyer, 2006, S. 147], [Rosenberg, 2005]: • Vorausplanung von zukünftigen Mengen von Kundenkontakten (das sogenannte Forecasting), • Nutzung der Vorausplanung für das Erstellen von Schichtplänen, 18

Ausführliche Darlegungen der Steuerung beziehungsweise des Controllings von Contact-Centern geben beispielsweise [Schümann und Tisson, 2006], [Helber und Stolletz, 2004] oder [Böse et al., 2001]

30

2. Contact-Center als Dienstleister in der Kundenkommunikation • Einteilung im Rahmen der Personaleinsatzplanung von Agenten in die täglichen Schichtpläne und • fortlaufende Steuerung über den Tag verteilt (die sogenannte Intra-Day-Steuerung).

Dies wird auch als Workforce-Management19 (WfM) bezeichnet [vgl. Rosenberg, 2005]. Bei der fortlaufenden Steuerung werden beispielsweise Änderungen in der Mengen- oder Personalzuteilung vorgenommen (auch an andere Einheiten innerhalb eines virtuellen Verbunds) oder Agenten werden vorübergehend für wichtige Aufgaben hinzugenommen, die hierfür eigentlich einen Skill mit geringerem Skill-Level haben. Ebenso gehört zu den Tätigkeiten der Planung eine flexible Anpassung der Steuerungsparameter der Routingstrategien zur Anpassung auf die aktuellen Bedürfnisse der Arbeitsverteilung. Ziele der Steuerung sind dabei beispielsweise die kontinuierliche Einhaltung von Leistungsvereinbarung, die Optimierung der Auslastung oder eine Minimierung der laufenden Kosten [vgl. Gurvich et al., 2008, S. 279 ff.], [L’Ecuyer, 2006, S. 147 - 148], [Bourke, 2001, S. 299].

2.3.5. Mitarbeiter Die Fähigkeit zu Kommunizieren und einen beim Kunden oder Interessenten als angenehm empfundenen Kontakt herzustellen, wird als wesentlicher Faktor bei der Kundengewinnung und beim Aufrechterhalten von bestehenden Kundenkontakten angesehen [vgl. bspw. Rothlauf, 2004, S. 73]. Zwischenmenschliche Kommunikation und persönlicher Kontakt zwischen Mitarbeiter und Kunde sind wichtige Größen im Zusammenhang mit der Kundenorientierung (siehe Kapitel 3). Dem dritten Wirkfaktor im Contact-Center, dem Menschen beziehungsweise konkreter dem Mitarbeiter, kommt somit eine wichtige Rolle bei der Erbringung der Contact-CenterDienstleistungen zu. [Böse und Flieger, 1999, S. 42] sprechen in diesem Zusammenhang von einem „erheblichen Anteil am Erfolg oder Mißerfolg“. Für [Scupin, 2006, S. 31] ist der persönliche Kundenkontakt eine der strategischen Ressourcen im Contact-Center. Die Agenten sind diejenigen, die den persönlichen Kontakt zum Kunden herstellen, sei es direkt am Telefon oder mittelbar über die asynchronen Kontaktkanäle. In diesem Zusammenhang stellt [vgl. Bruhn, 2006a, S. 234] die positive Qualitätswahrnehmung dar, die sich auf Grund einer hohen Fach- und Sozialkompetenz ergibt. Die Gruppe der Agenten macht mit circa 75 Prozent den größten Anteil der Mitarbeiter im Contact-Center aus [vgl. Schietinger und Schroth, 2001, S. 8]. Ihr Anteil der Personalkosten an den Gesamtkosten liegt bei etwa 70 Prozent [vgl. L’Ecuyer, 2006, S. 145]. Auf 19

Der Begriff Workforce-Management, wie er hier definiert ist, wird in dieser Ausprägung weitgehend im Contact-Center-Umfeld verstanden und häufig benutzt. Der gleiche Begriff wird in der Betriebswirtschaftslehre unterschiedlich und meist mit weiter reichendem Fokus benutzt.


31

Grund der hohen Anteile an der Strategieumsetzung, der Kostenstruktur sowie der Personalstruktur leiten sich entsprechend Anforderungen an fachliche, kommunikative, soziale und persönliche Kompetenzen20 der Agenten ab [Scupin, 2006, S. 33 ff.]. Zur Aufrechterhaltung dieser Kompetenzen sind fachliche Schulungen und ebenso mentale Vorbereitungen der Agenten auf das Aufgabenfeld notwendig, woraus sich auch entsprechende Anforderungen an das Management und die Auftraggeber der Contact-Center ableiten, um eine Aus- und Weiterbildung und eine kontinuierlich gute Arbeitszufriedenheit der Agenten sicher zu stellen [vgl. Schümann und Tisson, 2006, S. 27 - 28]. Eine Verstärkung der Kundenorientierung, gegeben durch den direkten Kundenkontakt, steht hier im Vordergrund der Personalentwicklung [vgl. Bruhn, 2006a, S. 234]. Im Sinne des Ausbaus der Kundenorientierung auf der einen Seite und einer zunehmenden Industrialisierung und Automatisierung andererseits, verändern sich auch die Arbeitsbedingungen und Anforderungen an die Mitarbeiter in einem Contact-Center. Grundlegend ist erkennbar, dass Vorgänge zunehmend teil- oder vollautomatisiert abgewickelt werden. Dadurch nimmt die Anzahl der Routinetätigkeiten für die Agenten ab. Durch Agenten werden dann vermehrt nur noch Kontakte bearbeitet, die entweder ein hohes Fachwissen benötigen oder bei denen ein persönlicher Kontakt notwendig ist (etwa Bearbeitung von Beschwerden). Durch die Freistellung von Routinetätigkeit kommt es zu einer Effizienzsteigerung durch geringeren Personalbedarf. Andererseits kann dies auch als Möglichkeit genutzt werden, die Kundenorientierung durch persönlichen Kontakt zu verstärken, dort wo dies wirtschaftlich sinnvoll und möglich ist, etwa für besondere Kundengruppen.

20

Einen Überblick über die jeweiligen Kompetenzanforderungen zeigt ebenfalls [vgl. Scupin, 2006, S. 33 ff.].

33

3. Kundenorientierung und Industrialisierung in der Kundenkommunikation Eine Untersuchung von Anforderungen bei Contact-Centern und ein Erarbeiten von Lösungen im Bereich der Kundenkommunikation müssen den größeren betriebswirtschaftlichen und volkswirtschaftlichen Kontext mit berücksichtigen. Übergeordnete Trends und Fakten, die auf andere Dienstleistungsunternehmen einwirken, gelten auch für ContactCenter. Darüber hinaus sind die Grundzüge dieser Arbeit und Teile des Referenzmodells auch für andere Dienstleister außerhalb der Telekommunikation und der Kundenkommunikation relevant, für die eine zunehmende Industrialisierung der Dienstleistungen und eine Fokussierung auf die Kundenorientierung ähnliche Rahmenbedingungen bilden. Dieses Kapitel dient deshalb der Darstellung strategischer Einflussgrößen und deren Auswirkungen. Weiterhin kann es zur Ermittlung der Anspruchsberechtigten in einem Unternehmen herangezogen werden, die mit den Themen dieser Arbeit in Beziehung stehen.

3.1. Kundenorientierung als Unternehmensziel Zunächst wird die Kundenorientierung betrachtet. In den nachfolgenden Abschnitten wird eine Begriffsklärung vorgenommen, die Kundenorientierung in den größeren Unternehmenskontext eingeordnet und die Zielsetzung der Kundenorientierung geklärt. Abschließend findet eine Einordnung in Zusammenhang mit Contact-Centern statt. 3.1.1. Begriffsklärung Kundenorientierung Nach eingehender Literaturrecherche muss festgestellt werden, dass es keine allgemeine und übergreifende Definition für ein Konzept der Kundenorientierung gibt. Die Kundenorientierung wird unter verschiedenen Aspekten des Umgangs mit Kundenbeziehungen zitiert und verwendet. Häufig werden Begriffe wie „Customer Relationship Management“ oder „Customer Relationship Marketing“21 und andere Kombinationen aus ähnlichen Begriffen benutzt, die eine Beziehungsgestaltung eines Unternehmens zum Kunden hin meinen. Der Begriff Kundenorientierung bezieht sich auf Kunden als die Anspruchsgruppe von Unternehmen, auf die hin die Unternehmensaktivitäten ausgerichtet werden22 . Der Begriff Kunde ist dabei nicht nur im engeren Sinne zu sehen, sondern kann auf interne Kunden 21

„Customer Relationship Management“ und „Customer Relationship Marketing“ werden beide häufig mit „CRM“ abgekürzt. Nur im jeweiligen Kontext, in dem die Begriffe benutzt werden, wird klar, welche Bedeutung oder welcher Zusammenhang gemeint ist. 22 Kundenorientierung muss abgegrenzt werden von der Marktorientierung, bei der die für ein Unternehmen relevanten Märkte und deren Teilnehmer, wie beispielsweise Konkurrenten oder Absatzmittler, mit einbezogen werden [vgl. Bruhn, 2006b, S. 37]


34

3. Kundenorientierung und Industrialisierung in der Kundenkommunikation

wie Mitarbeiter, Lieferanten und Kapitalgeber ausgeweitet werden [vgl. Meyer et al., 2006, S. 63]. Zunächst definiert [Berry, 1983, S. 25] die Kundenorientierung respektive das „Relationship Marketing“23 sehr einfach als ein Marketing, das Kundenbeziehungen aufbaut, diese aufrechterhält und erweitert. Genauer definiert wird Customer-Relationship-Management oder -Marketing als „[...] ein Marketing und Managementkonzept, mit dem sich ein Unternehmen gezielt und systematisch auf die Bedürfnisse seiner Kunden und Marketingpartner ausrichten will. [...] In erster Linie geht es um die Gestaltung und Pflege von Beziehungen. Die Kundenzufriedenheit ist dann Ziel dieser Bemühungen“ [Rudolph und Rudolph, 2000, S. 9]. In dieser Definition zeigt sich eine der Zielsetzungen der Kundenorientierung: die Kundenbindung. Aus der Sicht eines Kunden ist die Bindung an ein Unternehmen von nachgelagertem Interesse. Im Vordergrund steht der Wunsch, ein günstiges Produkt beziehungsweise die passendste Dienstleistung zu erwerben, sowie die Befriedigung der individuellen Wünsche [vgl. Schwetz, 2001]. Aus Unternehmersicht ist die Bindung der Kunden an das Unternehmen von entscheidenderer Bedeutung. Derzeit gleichen sich Produkte in Preis und ihren weiteren Produkteigenschaften immer weiter an. Dies ist einerseits zurückzuführen auf einen Wandel vom Verkäufermarkt zum Käufermarkt [vgl. bspw. Habel, 2006, S. 27], in dem der Käufer bestimmt, was angeboten wird, und sich die Anbieter daran anpassen. Zusätzlich kommen Angleichungen von Wettbewerbsbedingungen durch gesetzgebende Instanzen24 oder durch die Globalisierung der Märkte hinzu. Als einer der Faktoren der Kundenbindung an einen Anbieter bleibt somit der Grad der Kundenorientierung und ihre Professionalisierung. Dies drückt sich in der Kundenzufriedenheit aus, welche über eine erneute Kaufentscheidung beim gleichen Anbieter entscheidet oder über andere Kommunikationswege zu Kaufentscheidungen von Neukunden führen kann. In diesem Sinne definieren [Rudolph und Rudolph, 2000, S. 4] „CRM [als] professionelles Beziehungsmarketing von Unternehmen oder Institutionen auf den Feldern ihrer Absatzmärkte, den Beschaffungsmärkten und den gesellschaftlichen Systemen. Ziel der Methoden und Werkzeuge des CRM ist es, dass Beziehungen und Kompetenzen erfolgreich in Szene gesetzt werden. Kundenbindung und die gezielte Identifikation profitabler Neukunden sind das Ziel.“ Allen Ansätzen gleich ist die Aussage, dass es um eine professionelle Gestaltung der Beziehung zum Kunden geht und dies als wesentlicher wirtschaftlicher Faktor für ein Unternehmen angesehen wird [vgl. Ebner et al., 2007, S. 14]. Bei der Kundenorientierung bilden die Summe der Kundenbedürfnisse sowie deren Befriedigung den zentralen Punkt der unternehmerischen Tätigkeit [vgl. Bruhn, 2007, S. 36]. „[Gewollt ist eine] grundsätzliche Ausrichtung der Unternehmensaktivitäten an den Kundenbedürfnissen, die bei der Planung und Erstellung der unternehmerischen Leistungen Berücksichtigung finden, mit 23 24

Die Begriffe werden hier noch synonym verwendet. Beispielsweise durch Regulierungen innerhalb des europäischen Binnenmarktes durch die Europäische Union (EU).

3.1. Kundenorientierung als Unternehmensziel

35

dem Ziel, langfristig stabile und ökonomisch vorteilhafte Kundenbeziehungen zu etablieren“ [Bruhn, 2007, S. 32]. Die Kundenorientierung muss dabei immer als Bestandteil der Strategieausrichtung eines Unternehmens gesehen werden [vgl. Habel, 2006, S. 30]. 3.1.2. Kundenorientierung als Teil des Unternehmensmarketings Im vorangegangenen Abschnitt wurden die verschiedenen CRM-Begriffe synonym verwendet, um gemeinsame und wesentliche Elemente des Begriffs Kundenorientierung zu erarbeiten. Dies kann nun etwas genauer betrachtet und die Kundenorientierung in das Unternehmensmarketing eingeordnet werden. Ausgangspunkt klassischen Marketings ist eine gestaltende Beeinflussung des Marktes mit dem Ziel, Geschäftsabschlüsse zu tätigen. Ausgehend vom strategischen Marketing wird eine operative Marketingplanung aufgesetzt, in dem die Marketinginstrumente (Gestaltungswerkzeuge für den Markt) festgelegt sind [Meffert et al., 2008, S. 22]. Als klassische Marketinginstrumente haben sich „Product“ (Produkt), „Price“ (Preis), „Promotion“ (Kommunikation) und „Place“ (Vertrieb) als die sogenannten „4 Ps“ durchgesetzt, die im Rahmen des sogenannten Marketingmixes optimal kombiniert werden [vgl. Bruhn, 2007, S. 21 ff.]. Diese Art von Marketing wird als Transaktionsmarketing bezeichnet, welches auf die Initiierung von Einzeltransaktionen mit nicht näher konkretisierten Kunden abzielt[vgl. Bruhn, 2006b, S. 36 - 37]. Nach [Kotler et al., 2006] sind die Entscheidungskriterien für den Einsatz von Transaktionsmarketing folgende: Zum einen ein kurzer zeitlicher Horizont, zum anderen die Möglichkeit leicht den Anbieter wechseln zu können. Dies gilt besonders für Teilmärkte mit einem sehr hohen Maß an Spezialisierung [vgl. Schwetz, 2001, S. 14 - 17]. Als Beispiel kann hier der Stahl- oder Zementmarkt angeführt werden [vgl. Ebner et al., 2007, S. 15]. Dort sind die angebotenen Produkte fast völlig identisch. Nachfrage entsteht immer nur punktuell für bestimmte Aufträge und kann jeweils von wechselnden Anbietern befriedigt werden. Transaktionsmarketing beziehungsweise die dazugehörigen Methoden und Konzepte bestimmten über viele Jahrzehnte die Inhalte des traditionellen Marketings [vgl. Ebner et al., 2007, S. 15]. Im Sinne eines Paradigmenwechsels wird in den letzten Jahren ein Übergang vom Transaktionsmarketing hin zum Beziehungsmarketing vorgeschlagen. Die Perspektive beim Transaktionsmarketing richtet sich hierbei mehr von innen nach außen, das heißt vom Unternehmen auf den Markt hin. Ein Unternehmen entwickelt ein Marketingmix und will damit Geschäftsabschlüsse am Markt tätigen. Beim Beziehungsmarketing ist die Blickrichtung entgegengesetzt, das heißt, die Art der Beziehung des Kunden zum Unternehmen hin bildet die Ausgangslage der Marketingaktivitäten und der Marktbearbeitung [vgl. Bruhn, 2007, S. 31]. Nach [Bruhn, 2006b, S. 38] ist Beziehungsmarketing Teil des Unternehmensmarketings, das eine ausgeprägte Kundenorientierung gewährleistet und dem Aufbau sowie dem Erhalt

36


Unterscheidungskriterien

Transaktionsmarketing

Beziehungsmarketing

Betrachtungsfristigkeit

Kurzfristigkeit

Langfristigkeit

Marketingobjekt

Produkt/Leistung

Produkt/Leistung und Interaktion

Marketingziel

Kundenakquisition

Kundenakquisition, Kundenbindung, Kundenrückgewinnung

Strategiefokus

Information

Dialog

Ökonomische Erfolgsund Steuergrößen

Gewinn, Deckungsbeitrag, Umsatz, Kosten

Zusätzlich: Kundendeckungsbeitrag, Kundenwert

Tabelle 1: Transaktions- und Beziehungsmarketingkriterien [nach Bruhn, 2007, S. 31] und der Verbesserung profitabler Kundenbeziehungen dient. Ausgangspunkt gestaltender Einwirkung auf den Markt ist nicht mehr eine Kombination aus den Marketinginstrumenten sondern die Beziehungsgestaltung zu den Kunden hin, da festgestellt wurde, dass Transaktionsorientierung teilweise den Erwartungen der Kunden nicht gerecht wird oder Kunden dagegen Widerstände aufbauen [vgl. Bruhn, 2007, S. 31]. Eine Gegenüberstellung der Unterscheidungskriterien beider Marketingrichtungen zeigt Tabelle 1. Ob nun Transaktions- oder Beziehungsmarketing eingesetzt wird, ist eine Entscheidung der Unternehmenspolitik. Diese ist abhängig von verschiedenen Faktoren, etwa von Branche und Zielsetzung der Kunden und Anbieter [vgl. Kotler et al., 2006, S. 14 - 17]. Eine Zunahme der Bedeutung von Beziehungsmarketing ist dabei klar erkennbar bis hin zur Aussage, dass heute Beziehungsmarketing im Sinne einer Ausrichtung auf Gewinnorientierung in der Unternehmensführung nicht mehr wegzudenken sei [vgl. Ebner et al., 2007, S. 17].

Abbildung 10: Abgrenzung des CRM-Begriffs [aus Hippner, 2006, S. 20]


37

Mittels der Einteilung nach [Hippner, 2006] können die verwendeten „Beziehungsbegriffe“ abschließend nochmals abgegrenzt werden. Darin werden die Begriffe wie in Abbildung 10 dargestellt differenziert. Demnach richtet sich das Beziehungsmarketing im Kontext des gesamten Beziehungsmanagements auf Beziehungen zu Kunden hin sowie auf vertikale Beziehungen (das heißt Mitanbieter auf dem Markt). CRM im Sinne des CustomerRelationship-Managements und als Teil des Beziehungsmarketings richtet seine Tätigkeiten auf Kunden hin, sowohl auf die aktuell bestehenden Kunden als auch auf potentielle Neukunden sowie auf verlorene Kunden. Auf diesen Blickwinkel des CRM wird in dieser Arbeit Bezug genommen.

3.1.3. Zielsetzung der Kundenorientierung Kundenorientierung ist das erste Glied der sogenannten „Erfolgskette der Kundenorientierung“ mit den weiteren Gliedern Kundenzufriedenheit, Kundenbindung und Kundenwert (siehe Abbildung 11) [vgl. Bruhn, 2001, S. 58]. In dieser Erfolgskette stehen die einzelnen Glieder in einem Wirkungszusammenhang, bei dem nicht der direkte Zusammenhang zwischen den einzelnen Gliedern im Vordergrund steht, sondern die Gesamtheit der Erfolgskette in ihrer Interdependenz im Hinblick auf die Optimierung des letzten Gliedes in der Erfolgskette, des Kundenwerts. Über die Erfolgskette hinweg ist das letztendliche Ziel der Kundenorientierung eine Optimierung des Kundenwerts als ökonomische Größe der Unternehmenssteuerung und grundsätzlich die Sicherstellung profitabler Kundenbeziehungen [vgl. Bruhn, 2001, 2006b, S. 58 bzw. 38f.].

Abbildung 11: Von der Kundenorientierung zum Kundenwert [aus Bruhn, 2006b, S. 200]

38


Bei der Ausrichtung der Unternehmensstrategie an die Kundenorientierung im Sinne des CRM und der „Erfolgskette der Kundenorientierung“ ist es notwendig, die strategischen Ziele des Unternehmens klar zu definieren. [Hippner und Wilde, 2002, S. 12] unterteilen dabei die strategische Zielsetzungen in die folgenden vier Bereiche: 1. Profitabilität: Im Sinne der Kundenorientierung liegt der unternehmerische Fokus auf langfristig profitablen Kundenbeziehungen. Die größte Rolle spielt dabei der Anteil an der Kaufkraft eines Kunden, den das Unternehmen an sich binden kann. Der Marktanteil ist von geringerer Bedeutung und kann sogar abnehmen. Bestätigt wird die Bedeutung des Kaufkraftanteils dadurch, dass der Großteils des Gewinns eines Unternehmens nur durch wenige Kunden erwirtschaftet wird [vgl. Hippner und Wilde, 2002, S. 7]. Nach [Ebner et al., 2007, S. 25] bringen etwa 20 Prozent der Kunden rund 80 Prozent des Umsatzes. Dies gilt vor allem bezogen auf die gesamte Dauer der Kundenbeziehung, dem sogenannten „Lifetime-Umsatz“. Auch wenn kurzfristig kein Gewinn oder nur wenig erwartet werden kann, so spielt die Gesamtbetrachtung eine wichtige Rolle. [Kotler, 2007] bezeichnet diese Kundengruppe als „schlafende Riesen“. 2. Differenzierung: Nach [Hippner und Wilde, 2002] ist eine feine Differenzierung der Kundenbeziehung eine zentrale Forderung bei der Kundenorientierung. Die Differenzierung bezieht sich dabei auf Produkte, Leistungen und den Dialog mit dem Kunden. Hier müssen diese drei differenziert auf die Kunden zugeschnitten werden. Aus Kundensicht muss dabei auf die Besonderheiten und Eigenheiten der jeweiligen Lebenslagen eingegangen werden und die Leistungen sowie die Kundenansprache kundenspezifisch gestaltet werden. Aus Unternehmersicht ist dies nicht immer machbar. Hier gilt es, die Kosten, die mit der kundenspezifischen Gestaltung der Geschäftsprozesse verbunden sind, mit der zu erwartenden Profitabilität des Kunden abzuwägen [vgl. Hippner und Wilde, 2002, S. 9f.]. 3. Langfristigkeit: Getragen von der Aussage der Profitabilität langfristiger Kundenbeziehungen ist es eine Zielsetzung der Kundenorientierung, langfristige Kundenbeziehungen aufzubauen und zu festigen. Die zentrale Rolle nimmt hier nun die Pflege bestehender Beziehungen ein, nicht mehr die Neugewinnung von Kunden. Daraus wird primär eine Steigerung des Gewinns erwartet, unter anderem aus folgenden Gründen [nach Hippner und Wilde, 2002, S. 11]: • Kunden sind mit steigender Kundenbindung eher dazu bereit, höhere Preisprämien zu bezahlen (Abnahme der Preiselastizität bei steigender Kundenbindung). • Zufriedene Kunden sprechen vermehrt Weiterempfehlungen aus, wodurch die Anzahl derjenigen Kunden steigt, die zumeist ähnlich positiv auf die Marketingmaßnahmen reagieren, wie die Kunden, von denen sie empfohlen wurden.


39

• Auswertungen langfristig angesammelter Kundendaten führen zu Kosteneinsparungen, da Marketingaktionen gezielter eingesetzt werden können und eine differenzierte Kundenansprache zu mehr Rücklauf führt. • Ein Umsatzwachstum kann von daher erwartet werden, dass Kunden mit zunehmender Vertrautheit mit Produkten und Dienstleistungen diese auch vermehrt beziehen und bei jeder Transaktion die Möglichkeit besteht, ähnliche Produkte oder ein höherwertigeres Produkt zu verkaufen. 4. Integration: Die oben genannten Forderungen, insbesondere die Differenzierung der Produkte, Leistungen und des Dialogs mit dem Kunden, verlangen nach einer Integration aller Kundeninformationen, um an den jeweiligen Kontaktpunkten zwischen dem Kunden und dem Unternehmen schnell auf die spezifischen Kundenwünsche reagieren zu können. 3.1.4. Kundenorientierung im Kontext von Contact-Centern Die Kundenorientierung als Teil des Unternehmensmarketings ist überwiegend eine Beschreibung der externen Kommunikation zwischen dem Unternehmen und den Kunden („Externe Kommunikation“ in Abbildung 12). Ist die externe Kommunikation stimmig, so treten konkrete Kunden mit konkreten Mitarbeitern in Kontakt („Interaktive Kommunikation“ in Abbildung 12), etwa dann, wenn durch einen Telefonanruf ein Produkt gekauft wird oder mittels einer E-Mail eine Serviceanfrage formuliert wird.

Abbildung 12: Erscheinungsformen der Kommunikation von Unternehmen [aus Bruhn, 2007, S. 200] Das Beziehungsmarketing richtet sich von außen nach innen. Technisch gesehen geschieht dies über die Interaktionskanäle, über die ein Kunde mit einem Unternehmen in Kontakt tritt (siehe Abbildung 13). Diese werden von Contact-Centern bedient, wodurch die Realisierung der Kundennähe, als eine der zentralen Zielsetzungen der Kundenorientierung, per se zur wichtigen Aufgabe für Contact-Center wird. Hinzu kommt, dass im Zuge der Anpassung auf Veränderungen in den Entwicklungsphasen der Kommunikation sich derzeit neue Kommunikationstechnologien (etwa Internetgebundene Kommunikation wie E-Mail, Chat, VoIP und Videokonferenzen) beständig

40


Abbildung 13: Realisierung von Kundennähe als zentrale Zielsetzung einer Kundenbeziehungsstrategie [aus Hippner, 2006, S. 36] weiter entwickeln und Contact-Center vor der Herausforderung stehen, ihre Kommunikationsprozesse daran anzupassen, um eine langfristige Kommunikationsbeziehung mit den Kunden aufzubauen und mit den Kommunikationsbedürfnissen der Kunden Schritt zu halten [vgl. Bruhn, 2007, S. 201]. Bei der Betrachtung der Phasen im Rahmen der Kundenorientierung greift [Hippner, 2006] die „Erfolgskette der Kundenorientierung“ von [Bruhn, 2006b] auf (Abbildung 11) und entwickelt eine detailliertere „CRM-Wirkungskette“ (Abbildung 14). In Phase 1 dieser Wirkungskette werden Basisstrategien und kundenorientierte Managementkonzepte angeführt, die ein Unternehmen einsetzt, um Kundennähe zu realisieren. Dies unterstützt die angestrebte Nutzung des Geschäftsprozessmanagements als integriertes Managementkonzept für Contact-Center, das alle im Zusammenhang mit der Kundenorientierung stehenden Aspekte aufnimmt. Einer dieser Aspekte ist das Multikanal-Management. Es wird ebenfalls Bestandteil des Referenzmodells dieser Arbeit, da es eine der grundlegenden Aufgaben von Contact-Centern ist, die Summe der Kommunikationskanäle und die darüber abgewickelten Geschäftsprozessen abzudecken und zu managen. In Phase 2 geht es um eine kundenorientierten Reorganisation. Auch hier dürfte der größte Anteil der Zuständigkeit auf Contact-Center fallen, da sie für die Umsetzung einer Kundenbeziehungsstrategie verantwortlich sind und ein Großteil der Geschäftsprozesse und Systeme in ihren Hoheitsbereich fallen. Dazu gehören auch die beiden zentralen Gestaltungsbereiche der Kundenorientierung: Dies sind zum einen eine Neuausrichtung der


41

Abbildung 14: CRM Wirkungskette [aus Hippner, 2006, S. 22] Geschäftsprozesse und der zugehörigen Verantwortlichkeiten und zum anderen der Einsatz integrierter Informationssysteme und die Synchronisierung der Kontaktkanäle [vgl. Hippner, 2006]. Dies wird insofern berücksichtigt, als dass für die spezifischen Belange von ContactCentern das Geschäftsprozessmanagement als integriertes Managementsystem entwickelt wird, um so bei der Neuausrichtung und Optimierung von Geschäftsprozessen den jeweils optimalen Rahmen zu bilden. Auch der Einsatz integrierter Informationssysteme und die Synchronisierung der Kontaktkanäle wird durch die abgestimmte Aufnahme der Serviceund Ereignisorientierung in das Referenzmodell berücksichtigt. Die Kernkompetenzen im CRM-Prozess (siehe Abbildung 15) werden durch die Ausrichtung auf die Kundenorientierung grundsätzlich zu den Kernkompetenzen eines ContactCenters. Eine weitere Kernkompetenz kommt hier hinzu, die bei [Hippner, 2006] so nicht dargestellt wurde, jedoch von entscheidender Relevanz sein kann, nämlich die Flexibilisierung in der Anpassung an bestehende und zukünftige Geschäftsanforderungen. [Meffert et al., 2008, S. 860] fasst diese wie folgt zusammen: „[...] Vor dem Hintergrund der aufgezeigten Trends und zentralen Schlüsselfaktoren zeichnen sich in Zukunft weit reichende Veränderungen in der Marktund Kundenorientierung ab. Sie bestehen in einer Intensivierung der Kun-

42


Abbildung 15: Kernkompetenzen im CRM-Prozess von Contact-Centern [nach Hippner, 2006, S. 33] denbeziehungen, einer Ausweitung und Bündelung der Leistungsangebote, einer verstärkten Prozessorientierung und dem damit verbundenen Ausbau von Netzwerken sowie einer beachtlichen Ausweitung der Marktgrenzen.“ Dieser Forderung muss aus Sicht des Contact-Center-Managements Rechnung getragen werden.

3.2. Industrialisierung der Dienstleistungsbranche Die Kundenorientierung betrifft Contact-Center als Dienstleister in der Kundenkommunikation in direktem Maße. Darüber hinaus sind sie den gleichen wirtschaftlichen und politischen Rahmenbedingungen unterworfen, wie viele andere Unternehmen auch. Schlagworte, die hier oft zitiert werden, sind „Globalisierung der Märkte“, „Informationalisierung“ oder „Industrialisierung der Dienstleistung“. Wenngleich auch unterschiedliche Begriffe verwendet werden, so ist meist eine bestimmte Entwicklung oder ein Trend gemeint, der die Wirtschaft auf der gesamten Welt beeinflusst. Ein Modell, das versucht neue Konzepte für ein Dienstleistungsunternehmen zu erarbeiten, muss diese Entwicklung ernst nehmen und die relevanten Punkte daraus in die Betrachtung mit aufnehmen. 3.2.1. Globale Einflussfaktoren auf Dienstleistungsunternehmen Dass die Bedeutung der Dienstleistung in einer Volkswirtschaft wie Deutschland immer stärker zunimmt, ist kaum strittig. Allein in Deutschland sind rund 70 Prozent der Arbeitnehmer in der Dienstleistungsbranche beschäftigt [vgl. Gross et al., 2006, S. 15]. Der

3.2. Industrialisierung der Dienstleistungsbranche

43

Anteil der Landwirtschaft und des produzierenden Gewerbes am erwirtschafteten Volkseinkommen nimmt zu Gunsten des Dienstleistungsanteils immer weiter ab (siehe Verlauf in Abbildung 16) [vgl. Pantaleo und Pal, 2008, S. 10]. An großen europäischen Dienstleistungsplätzen wie Frankfurt am Main, London oder Paris liegt der Dienstleistungsanteil bereits bei rund 90 Prozent [vgl. Hildebrand und Klostermann, 2007].

Abbildung 16: Wachsender Zuwachs in der Dienstleistungsbranche [aus Pantaleo und Pal, 2008, S. 10] Nun ist der Begriff der Dienstleistung noch etwas breit gefasst. [Bhagwati, 1987] nimmt hierzu eine Einteilung der Dienstleitung in zwei Kategorien vor [zitiert in Gross et al., 2006, S. 16]: Kategorie 1 erfordert eine physische Nähe von Produzent und Konsument der Dienstleistung, etwa eine Beratung im Geschäft oder ein Frisörbesuch. Bei der Kategorie 2 ist dagegen kein persönlicher Kontakt beider Parteien mehr nötig. Doch die Grenzen zwischen beiden Kategorien sind fließend und dank moderner Kommunikationstechnologien ist persönlicher Kontakt auch ohne physischen möglich, so dass man die Definition der Kategorie 2 auf den fehlenden physischen Kontakt begrenzen kann. In diese Kategorie fallen nach dieser Betrachtung beispielsweise eine über das Internet getätigte Überweisung bei einer Bank oder auch ein Beratungsgespräch per Telefon durch ein Contact-Center. Auf diese Art Dienstleistung der Kategorie 2 wird im weiteren Verlauf Bezug genommen. Unternehmen, die Dienstleistungen der Kategorie 2 erbringen, sind, wie andere Unternehmen auch, dem einleitend erwähnten Trend der sogenannten Globalisierung unterworfen, für den es viele Begriffe gibt. „Gemeint ist damit eine Entwicklung, die seit gut 20 Jahren in unterschiedlichen Bereichen stattfindet und begrifflich schwer zu fassen ist“ [Gross et al., 2006, S. 13]. Im Dienstleistungsbereich sind hier vier Entwicklungen zu beobachten: 1. Neue Dienstleistungsangebote und Spezialisierungen erlauben sowohl eine Auslagerung von Dienstleistungen als auch eine Anreicherung durch Dienstleistungen von

44

3. Kundenorientierung und Industrialisierung in der Kundenkommunikation außen. 2. Durch Informations- und Kommunikationstechnologie werden nichtmaterielle Dienstleistungen immer zeitnaher und in konzentrierter Form abgewickelt. Dadurch entsteht auch vermehrt eine „Handelbarkeit“ der Dienstleistung. 3. Standardisierung und Arbeitsteilung sind in immer weitgehenderem Maße realisierbar. 4. Die Erbringung der Dienstleistung ist in vielen Fällen geografisch nicht mehr begrenzt.

Bei der Untersuchung dieser begrifflich schwer zu fassenden Entwicklung und der Frage nach den Auslösern dafür formulieren [Pantaleo und Pal, 2008] sieben globale Imperative25 . Nach Untersuchungen von [Jordan, 2008] sind es sechs fundamentale Kräfte des wirtschaftlichen Trendwandels26 . Für den informationstechnischen Fokus dieser Arbeit sind daraus zusammengefasst folgende Einflussgrößen beziehungsweise Forderungen von Bedeutung: • Angleichung der Informationstechnologie: Es besteht die zunehmende Forderung von Fachanwendern und Unternehmensführung nach flexiblen, reaktiven Echtzeit-ITLösungen [vgl. Pantaleo und Pal, 2008, S. 8], deren Entwicklung und Gebrauch ausschließlich von den Anforderungen der Fachanwender bestimmt wird [vgl. Jordan, 2008, S. 42 - 43]. • Analytisches Management der Unternehmensstrategie: Das Management der Unternehmensstrategie erfolgt zusehends analytisch durch Kontrolle von Kennzahlen. Die IT als Lieferant von Kennzahlen dient nicht nur der Umsetzung von Unternehmensstrategien, sondern zunehmend auch als Überwachungs- und Steuerungsinstrument der Unternehmensstrategie [vgl. Pantaleo und Pal, 2008, S. 6]. • Innovation: Als besonders wichtig wird die Forderung nach Innovationsfähigkeit angesehen. Dies bezieht sich zum einen auf Prozess- und Produktinnovationen und zum anderen liegt ein besonderer Fokus aber auf der Fähigkeit zur Innovation von Geschäftsmodellen27 [vgl. Pantaleo und Pal, 2008, S. 8]. 25

„Globalization“, „Innovation“, „Corporate Strategy Management“, „Corporate Governance and Compliance“, „Expanding Knowledge Access“, „Resurgence of IT Alignment“ und „Emerging Power of SME“ [aus Pantaleo und Pal, 2008, S. 4ff.] 26 „Workforce Dynamics“, „Power Shifts to Customers“, „Capital Goes Global“,„Business Models Evolve“, „Compliance Becomes Imperative“ und „Business Is Leading the Use of IT“ [aus Jordan, 2008] 27 Als Beispiel führt [Comes und Berniker, 2008, S. 66 - 67] das Geschäftsmodell von Amazon.com an: Der Hauptumsatz wird nicht durch den Verkauf von Büchern generiert sondern durch Kapitalmarktgeschäfte. Während im stationären Buchhandel ein Buch im Schnitt 78 Tage nach Bezahlung des Großhändlers verkauft wird, erfolgt der Zahlungseingang verkaufter Bücher bei Amazon.com durchschnittlich 41 vor Zahlung an den Großhändler. Der stationäre Buchhändler muss vorfinanzieren, Amazon.com hat 41 Tage Zeit, um mit dem Geld zu arbeiten.

3.2. Industrialisierung der Dienstleistungsbranche

45

[Comes und Berniker, 2008, S. 79] zeigen auf, wie Unternehmen diesen Forderungen, im Besonderen der Forderung nach Innovation der Geschäftsmodelle, im Allgemeinen nachgehen können: • Anpassung in der Organisationsstruktur eines Unternehmens, • Anpassung in den Kanälen zum Markt und • effektive Nutzung der Infrastruktur wie beispielsweise der IT. Einen weiteren Einflussfaktor stellt die Informationalisierung dar. Der Begriff lässt sich nicht trennscharf abgrenzen und wird in unterschiedlichen Wissenschaftsdisziplinen gebraucht28 . Aus Sicht der Informationswissenschaft ist die Tatsache relevant, dass Wissen und Informationen zusehends zu Produktivkräften und Produktionsfaktoren werden, die wiederum neue Wissensformen hervorbringen. Der Austausch von Daten, Wissen und Informationen führt zu einem Anstieg der Produktivität [vgl. Castells, 2008, Heidbrink, 2003]. Hier besteht ein starker Bezug zur Dienstleistung. Die Informationalisierung stellt Informationen als Rohstoff vernetzter Wirtschaftsprozesse in den Mittelpunkt. Die Wertschöpfungsgenerierung liegt zunehmend im Austausch von Daten, Kenntnissen und Know-how, das im Bezug zur unternehmerischen Tätigkeit in Form einer Dienstleistung erbracht wird. Wie Dienstleistungen auch, ist das informationelle Kapital (Informationen) nicht an Grenzen gebunden. Wissen und Informationen werden so zu den wertvollsten Produktionsgütern einer globalen Wirtschaft. Es besteht zusätzlich eine selbstverstärkende Wechselwirkung zwischen Wissen und der Informationstechnologie, die Dienstleistungen unterstützen oder produzieren [vgl. Schelske, 2007, S. 74]: Benötigtes explizites Wissen für die Ausführung einer Dienstleistung, Prozesswissen bezogen auf die Struktur der Erstellung einer Dienstleistung und das Wissen aus Konstellationen einer Vielzahl von Events. Das Paradigma der Informationalisierung, das sich daraus ableitet, basiert auf Flexibilität aller Akteure und auf der Möglichkeit zur Rekonfiguration [vgl. Schelske, 2007]. Für die dargestellten Auswirkungen der Globalisierung muss eine Dienstleistungsunternehmung ausgelegt sein, um die Zunahme der Geschwindigkeit und der Art des Fortschritts in einer globalen und digitalen Wirtschaft standzuhalten[vgl. Pantaleo und Pal, 2008, S. 3]. In Umrissen wird ein neues Bild von Organisation und Abwicklung klassischer Unternehmensaufgaben sichtbar, die zu einer Industrialisierung in der Dienstleistungsbrache führen. 3.2.2. Industrialisierung von Dienstleistungen Der Begriff Industrialisierung wird in verschiedenen Wissenschaftsdisziplinen gebraucht, für den Fokus dieser Arbeit steht jedoch die geschichtswissenschaftlich-ökonomische Sicht28

Für eine Ausarbeitung zum Einfluss der Informationalisierung auf Gesellschaft und Mensch aus soziologischer Sicht sei auf die Publikation von [Castells, 2008] verwiesen.

46


weise29 im Vordergrund. Aus dieser Sichtweise heraus „[wird] unter Industrialisierung die Anwendung industrieller, hoch produktiver Methoden der Fertigung und Leistungserstellung in sämtlichen Wirtschaftsbereichen verstanden“30 . Grundlage dieser Definition bilden federführend die Arbeiten von Taylor und Ford31 zu Beginn des 20. Jahrhunderts, aus denen sich die ursprünglichen Wesensmerkmale der Industrialisierung ergeben [nach Krotsch, 2006, S. 7]: • Standardisierung: Zerlegung komplexer Arbeitsprozesse in singuläre Arbeitsschritte • Automatisierung: Maschinelle Unterstützung und ganz oder teilweise maschinelle Ausführung manueller Prozesse [vgl. auch Riese, 2006, S. 24] • Spezialisierung: Steigender Spezialisierungsgrad auf Grund der Arbeitszerlegung und Automatisierung Diese abgeleiteten Wesensmerkmale besitzen auf einzelwirtschaftlicher Ebene auch heute noch Gültigkeit [vgl. Kern, 1990] und lassen sich darüber hinaus auch auf die Erbringung von Dienstleistungen anwenden. Dies lässt sich, wie in Abbildung 17 dargestellt, anhand eines verallgemeinerten Prozessablaufs einer Dienstleistung verdeutlichen.

Abbildung 17: Generischer Dienstleistungsprozess [aus Gross et al., 2006, S. 21]

Die einzelnen Schritte des Prozessablaufs sowie der Transport unterliegen heutzutage kaum mehr physikalischen Grenzen, außer dort, wo Arbeitsschritte von Menschen durchgeführt werden. Jeder Prozessschritt kann durch eine große Anzahl von zur Verfügung stehenden Technologien umgesetzt werden, wobei der Transport in Bruchteilen einer Sekunde möglich ist [vgl. Gross et al., 2006, S. 21]. Dadurch ist sowohl eine Zergliederung als auch eine Automatisierung des Prozesses sowie eine leichte Anwendung der Wesensmerkmale der Industrialisierung möglich: Standardisierung, Automatisierung und Spezialisierung. 29

Verschiedene Betrachtungen über Nomenklatur und Verwendungsweise des Begriffs „Industrialisierung“ gibt beispielsweise [Krotsch, 2006, S. 7]. 30 Vgl. Eintrag „Industrialisierung“ in Brockhaus Enzyklopädie, Band 10, 1999, S. 477 f. 31 Frederick Winslow Taylor veröffentlichte die Schrift „Scientific Management“ mit den Prinzipien des Taylorismus [in Taylor, 1972]. Henry Ford realisierte die Prinzipien des Taylorismus und führte 1913 die Fließbandproduktion bei der Produktion seiner Automobile ein. Bezeichnet auch als „Fordismus“ [vgl. dazu bspw. Kang, 1994].

3.3. Kundenorientierung und Industrialisierung als Einflussfaktoren

47

Wertschöpfungsprozesse von Dienstleistungsunternehmen verändern sich auf Grund der Standardisierung, Automatisierung und Spezialisierung und ähneln immer mehr den Wertschöpfungsprozessen der Industrie. Notwendig machen dies die weiter oben genannten ökonomischen Einflüsse der Globalisierung und die in Abbildung 18 genannten Einflussgrößen [vgl. Hildebrand und Klostermann, 2007, S. 10]. Im Besonderen sind dies ein steigender Kostendruck und eine anhaltende Ertragsschwäche in der Dienstleistungsbranche [vgl. Habel, 2006, S. 40].

Abbildung 18: Veränderung von Wertschöpfungsprozessen [aus Hildebrand und Klostermann, 2007, S. 10]

3.3. Kundenorientierung und Industrialisierung als Einflussfaktoren Die Kundenorientierung wie auch die Industrialisierung sind wesentliche Einflussfaktoren auf Contact-Center. Bei einer Untersuchung durch [Habel, 2006] in diesem Bereich wurden für beide Einflussfaktoren Kriterien für Unternehmen aufgestellt, die kundenorientiert beziehungsweise industrialisiert sind. Dabei wurde festgestellt, dass die wesentlichen Kriterien der Kundenorientierung sowie der Industrialisierung identisch sind und verknüpft werden können. Die Kundenorientierung kann in diesem Sinne auch als Bestandteil der Industrialisierung dargestellt werden [vgl. Habel, 2006, S. 49f.]. Die gemeinsamen Kriterien für ein industrialisiertes und kundenorientiertes Unternehmen zeigt Abbildung 19. Diese Kriterien gilt es zu berücksichtigen und auf die Belange von Contact-Centern auszurichten. Die Dimension Strategie beinhaltet die Themen Industrialisierung und Kundenorientierung. Die Kriterien der Dimension Organisation werden in dieser Arbeit mit

48


einem entsprechend ausgelegten Geschäftsprozessmanagement als integriertem Managementkonzept abgedeckt, welches die technischen und kontrollrelevanten Kriterien durch die Integration der Serviceorientierung und Ereignisverarbeitung in dieses Konzept mit berücksichtigt. Im Sinne der Anforderungen von [Comes und Berniker, 2008, S. 79] nach der Fähigkeit zur Innovation der Geschäftsmodelle deckt das Geschäftsprozessmanagement und eine sich daraus ergebende Contact-Center-spezifische prozessorientierte Organisationsstruktur die strukturelle Anpassungsfähigkeit ab. Die effektive Nutzung der Infrastruktur (im Fokus dieser Arbeit ist die IT eines Contact-Centers) decken die Automatisierung durch Serviceorientierung der Einsatz der Ereignisorientierung ab.

3.3. Kundenorientierung und Industrialisierung als Einflussfaktoren

49

Abbildung 19: Kriterien für ein kundenorientiertes und industrialisiertes Unternehmen [aus Habel, 2006, S. 51]

51

Teil II. Geschäftsprozesse, Service- und Ereignisorientierung Ein Prozess ist eine Maschinerie, die man als Schwein betritt und als Wurst verlässt. (Ambrose Bierce) Jeder Prozess ist verbesserbar. (Heinrich von Pierer)

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement Im vorangegangenen, ersten Teil wurde das Umfeld des Themas dieser Arbeit erläutert. In diesem Teil werden nun die wesentlichen Bestandteile des Referenzmodells dargestellt, welches anschließend im Teil III entwickelt wird. Die Auswirkungen der in diesem Teil dargestellten Zusammenhänge und Tatsachen auf die Entwicklung des Referenzmodells wird jeweils am Ende größerer Abschnitte mittels eines Fazits zusammengefasst. Dieser Abschnitt beginnt mit der Definition des Begriffs des Geschäftsprozesses. Anschließend werden das klassische Geschäftsprozessmanagement und seine Komponenten vorgestellt. Der Begriff „klassisch“ ist in diesem Zusammenhang als „im herkömmlichen Sinne“ oder „in typischer Ausprägung“ zu verstehen. Es sollen dabei die derzeit gängige Lehrmeinung und der aktuelle Stand der Wissenschaft wiedergegeben und Gemeinsamkeiten aufgezeigt werden, ohne dabei auf spezifische Ausprägungen oder Spezialisierungen, wie beispielsweise Anwendungsdomänen, einzugehen.

4.1. Prozessbegriff Bevor das Konzept des Geschäftsprozessmanagements erklärt werden kann, ist es nützlich, mit der Definition des Prozessbegriffs zu beginnen und dabei die Eigenschaften zu erarbeiten, die einen Prozess zum Geschäftsprozess machen.


52

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

4.1.1. Definition des Prozessbegriffs Aus Sicht der Wortherkunft meint „Prozess“ zunächst nur einen Vorgang oder eine Abfolge32 . Sehr weitläufig beschreibt demnach die ISO-Norm 9000 einen Prozess zunächst lediglich als einen „Satz von in Wechselbeziehung oder Wechselwirkung stehenden Tätigkeiten, der Eingaben in Ergebnisse umwandelt“ [ISO9000, 2000]. In ähnlicher Weise nähern sich [Bräkling und Oidtmann, 2006, S. 48] einer Prozessdefinition: „Jeder Prozess hat Eingaben (Inputs), die durch Umwandlung in Ergebnisse (Outputs) münden“, wobei durch einen Prozess Werke geschaffen werden. In dieser Input-Output-Beziehung eines Prozesses sind die wesentlichen Eingaben in einen Prozess Arbeit, Roh-, Hilfs- und Betriebsstoffe, Maschinen und Anlagen, Energie und vor allem auch Informationen. Das Ergebnis eines Prozesses (die Werke) sind Produkte im Sinne einer Ware oder einer Dienstleistung [vgl. Schmelzer und Sesselmann, 2008, S. 63]. Insofern kann noch vieles als Prozess bezeichnet werden, vom Werkzeugwechsel an einer Maschine bis hin zur Unternehmensführung. Bei der Frage nach den unterscheidenden Eigenschaften eines Geschäftsprozesses, der ihn von der erheblich größeren Anzahl aller weiteren möglichen Prozesse unterscheidet, beschreibt [Nordsieck, 1972, S. 7 - 8] den Betriebsprozess (die Summe aller Geschäftsprozesse eines Unternehmens) als die schrittweise Verwirklichung der obersten Ziele der Unternehmung, dem Betriebsziel. Ein Geschäftsprozess muss demnach zur Erfüllung der Geschäftsziele beitragen. Dabei werden in einem Geschäftsprozess betriebswirtschaftlich relevante Objekte in einer inhaltlich abgeschlossenen, zeitlichen und sachlogischen Folge von Aktivitäten bearbeitet [vgl. Becker und Kahn, 2005, S. 6]. Betriebswirtschaftlich relevante Objekte können beispielsweise eine Bestellung, eine Kundenreklamation oder ein Reparaturauftrag sein. [Scheer, 2002] beschreibt einen Geschäftsprozess als „eine zusammengehörige Abfolge von Unternehmensverrichtungen zum Zweck einer Leistungserstellung“. Diese Leistungserstellung ist immer Produkt oder Ergebnis eines Geschäftsprozesses, wobei dies sowohl eine Sach- oder Dienstleistung darstellen kann [vgl. bspw. Bräkling und Oidtmann, 2006, Schmelzer und Sesselmann, 2008]. Entscheidend ist dabei, dass das Ergebnis eine Leistung für einen internen oder externen Kunden darstellt, die Qualität dabei den Anforderungen der Kunden gerecht wird [vgl. Feldmayer und Seidenschwarz, 2005, S. 12] und dieses Ergebnis für den Kunden einen Wert erzeugt [Hammer und Champy, 1996]. Ein Geschäftsprozess stellt ein essentielles Bindeglied zwischen dem formulierten Kundenbedürfnis und der dazugehörigen betrieblichen Leistungserstellung im Unternehmen dar (siehe auch Abbildung 20). Es ist demnach Selbstzweck des Geschäftsprozesses, die wertschöpfenden Aktivitäten so anzuordnen, dass sie den Kundenwunsch optimal befriedigen. In diesem Sinne sind Geschäftsprozesse das „Fundament der durchgehenden 32

lat. procedere: hervortreten, weitergehen (Stowasser, Joseph, Der kleine Stowasser, München, Oldenbourg, 1994, Seite 405)

4.1. Prozessbegriff

53

Kundenorientierung“ [Feldmayer und Seidenschwarz, 2005, S. 13], [vgl. Bruhn, 2006a, S. 235]. Der Geschäftsprozess hat dabei eine Ende-zu-Ende-Beziehung, das heißt, er erstreckt sich von der Entstehung des Kundenwunsches im Unternehmen bis zu dessen Beendigung [Scheer und Zimmermann, 1996, S. 267 ff.]. Dabei gilt das Prinzip der Wertschöpfungskette, das heißt, der Geschäftsprozess ruft sowohl beim Kunden als auch im Unternehmen einen Nutzen hervor [vgl. Ellringmann, 2000, S. 11].

Abbildung 20: Definition „Prozess“ und „Geschäftsprozess“ im Vergleich [aus Schmelzer und Sesselmann, 2008, S. 64] Weitere Komponenten eines Geschäftsprozesses sind die Steuerung über Leistungsparameter sowie die Zuordnung eines Prozessverantwortlichen. Bei der Steuerung über Leistungsparameter werden Geschäftsprozesse über Ziel- und Messgrößen gesteuert. Ziel ist es, die Leistungserbringung möglichst effizient und wirtschaftlich zu gestalten [vgl. Schmelzer und Sesselmann, 2008, S. 65 - 67]. Für die funktionale Organisation sowie die Prozessund Schnittstelloptimierung ist ein Prozessverantwortlicher zugeordnet [vgl. Feldmayer und Seidenschwarz, 2005, S. 12]. Ein Geschäftsprozess ist weiterhin Bindeglied zwischen seinen Aktivitäten, den eingesetzten Ressourcen (Menschen und Maschinen) und besonders der verwendeten Informationsund Kommunikationstechnologie sowie zur technischen Umgebung [vgl. bspw. Weske, 2007, S. 5], [Österle, 1995, S. 19]. Im Sinne der Aufbau- und Ablauforganisation kommt dem Geschäftsprozess eine besondere Stellung zu. In den Abschnitten 2.3.3 Aufbauorganisation und 2.3.4 Ablauforganisation wurden die Grundzüge der Organisationsgestaltung bereits dargelegt. Die Ablauforganisation hat zur Aufgabe, eine zielgerichtete Strukturierung der Arbeitsprozesse sicher zu stellen (siehe Seite 29). Dies erfolgt in der Regel konkret durch Geschäftsprozesse. Auf die Aufbauorganisation bezogen kommt es hier häufig dazu, dass die einzelnen wertschöpfenden Aktivitäten unterschiedlichen funktionalen Einheiten

54


zugeordnet sind [vgl. Feldmayer und Seidenschwarz, 2005, S. 12] und der Geschäftsprozess „oft quer zur klassischen Aufbauorganisation [liegt], d. h. er tangiert u. U. mehrere Abteilungen“ [Staud, 2006, S. 8]. Für eine allgemeine Definition von Geschäftsprozessen ist folgende Erhebung33 von [Koch und Hess, 2003, S. 19] ebenfalls von Interesse, die die Kriterien für die Einstufung eines Prozesses als Geschäftsprozess in einer Befragung ermittelten: • Wertschöpfende Aktivität (96,2 Prozent) • Funktionsübergreifend (76,9 Prozent) • Kundenorientiert (73,1 Prozent) • Prozessverantwortung (69,2 Prozent) • Ziele und Messgrößen (61,5 Prozent) • Strategische Bedeutung für das Unternehmen (42,3 Prozent) Nach [Jung, 2006a, S. 15 - 16] gibt es folgende Eigenschaften für Geschäftsprozesse: • Prozessauslösendes Ereignis • Definierter Anfang • Summe von sich wiederholenden Tätigkeiten • Messbarer Prozessoutput • Definiertes Ende • Prozessabschließendes Ereignis • Betroffene Stellen (Abteilungen, Stellen) Wichtig für das Verständnis eines Geschäftsprozess ist außerdem dessen Standardisierung. Dies bedeutet, dass Geschäftsprozesse nicht nur einmalig auftreten sondern in hoher Wiederholungsrate im Unternehmen durchgeführt werden. Dabei werden diese nicht unterschiedlich durchgeführt sondern standardisiert, das heißt inhaltlich immer gleich ausgeführt [vgl. Feldmayer und Seidenschwarz, 2005, S. 9]. Für den weiteren Verlauf dieser Arbeit lässt sich ein Geschäftsprozess in Anlehnung an [Gadatsch, 2008] wie folgt definieren: 33

„Zielgruppe der Erhebung waren deutsche Großunternehmen. Als Stichprobe wurden die DAX 30, MDAX 50 ausgewählt, sowie 20 Unternehmen aus dem SDAX [...]“ [Koch und Hess, 2003, S. 12]


55

„Ein Geschäftsprozess ist eine zielgerichtete, zeitlich-logische Abfolge von Aufgaben, die arbeitsteilig von mehreren Organisationen oder Organisationseinheiten unter Nutzung von Informations- und Kommunikationstechnologien ausgeführt werden können. Er dient der Erstellung von Leistungen entsprechend den vorgegebenen, aus der Unternehmensstrategie abgeleiteten Prozesszielen“ [Gadatsch, 2008, S. 46 - 47]. Der Geschäftsprozess ist Instrument der Kundenorientierung in dem Sinne, als dass er mit dem Eingang eines Kundenwunsches als auslösendem Ereignis beginnt und erst mit der kompletten Leistungserstellung bezogen auf den Kundenwunsch endet. Er wird dabei über Leistungsparameter gesteuert, die sowohl den internen als auch den externen Nutzengrad abdecken.

4.1.2. Prozessklassen Nach Einführung des Geschäftsprozessbegriffs bleibt die Frage nach einer sinnvollen weiteren Differenzierung offen, die zu einem besseren Verständnis des Geschäftsprozessmanagements beiträgt und für das Referenzmodell notwendig ist. Hierbei ist die Wertkette nach [Porter, 2000] hilfreich (siehe Abbildung 21). Darin werden die Aktivitäten eines Unternehmens in primäre und unterstützende Aktivitäten unterteilt. In Anlehnung daran ist eine ähnliche Einteilung von Geschäftsprozessen ebenfalls sinnvoll.

Abbildung 21: Wertkette nach [Porter, 2000] Im Sinne der Wertkette nach [Porter, 2000] unterscheiden beispielsweise [Schmelzer und Sesselmann, 2008] sowie [Weske, 2007] Geschäftsprozesse in zwei Klassen: primäre und

56


sekundäre Geschäftsprozesse34 . Die Bezeichnung Aktivität in der Wertkette ist dabei als Aggregation der Funktionen in einem Unternehmen und somit der Geschäftsprozesse auf höchster Ebene zu verstehen. Eine vertikale Unterscheidung – entsprechend der Granularität der Darstellung des Geschäftsprozesses – wird im Abschnitt 4.3 vorgestellt, wobei dabei die formal unterschiedlich möglichen Detaillierungsebenen beschrieben werden [vgl. bspw. Gadatsch, 2008, S. 47]. Hier wird zunächst eine horizontale, inhaltliche Unterscheidung vorgenommen, diese bezeichnen [Schmelzer und Sesselmann, 2008] als Prozessklassen. Die Kriterien zur Unterscheidung zwischen primären und sekundären Geschäftsprozessen sind deren Beitrag zur Wertschöpfung sowie zur Wettbewerbsfähigkeit des Unternehmens. Primäre Geschäftsprozesse nehmen direkten Einfluss auf die Wettbewerbsfähigkeit, während sekundäre Geschäftsprozesse die entsprechende Umgebung für eine effiziente Ausführung zur Verfügung stellen [vgl. Weske, 2007, S. 42]. [Schmelzer und Sesselmann, 2008] definieren dies ähnlich. Für sie „findet die originäre Wertschöpfung [in den primären Geschäftsprozessen] statt, d. h. die Erstellung und Vermarktung von Produkten und/oder Dienstleistungen für [...] Kunden“. Bei den primären Geschäftsprozessen gibt es einen unmittelbaren Nutzen, während die sekundären Geschäftsprozesse die entsprechende Unterstützung in Bezug auf Management und Infrastruktur geben [vgl. Schmelzer und Sesselmann, 2008]. Unabhängig von Beiträgen zur Wertschöpfung und zur Wettbewerbsfähigkeit sind jedoch beide Prozessklassen am Unternehmenserfolg beteiligt [vgl. Weske, 2007, S. 42]. Neben der Zweiteilung in primäre und sekundäre Geschäftsprozesse ist eine Untergliederung in drei Prozessklassen ebenfalls häufig in der Literatur vertreten. [Jung, 2006a, S. 22] nimmt dabei eine Unterscheidung in Leistungsprozesse, Unterstützungsprozesse und Führungsprozesse vor. Die gleiche Aufteilung nehmen [Bräkling und Oidtmann, 2006, S. 51] vor. Im Unterschied zu [Jung, 2006a] benennen sie Leistungsprozesse als Kernprozesse, ebenso wie [Becker und Kahn, 2005, S. 7], [Seidlmeier, 2006, S. 3] und [Staud, 2006, S. 11]. „[Kernprozesse] sind zentrale Prozesse, mit denen die Hauptleistung erbracht wird, in die die meisten Ressourcen einfließen und mithilfe derer die eigentliche Wertschöpfung erfolgt“ [Staud, 2006, S. 11]. In diesen Definitionen unterscheiden sie sich nicht von primären Geschäftsprozessen. Sekundäre Geschäftsprozesse werden von den oben genannten Autoren jedoch weiter unterschieden. Führungsprozesse sind demnach diejenigen Geschäftsprozesse, die der Organisation Richtung und Dynamik geben, wie etwa die Strategie- und Zielfindung oder die Arbeits- und Produktpolitik [vgl. Bräkling und Oidtmann, 2006, S. 51]. Abzüglich der Führungsprozesse sind Unterstützungsprozesse nicht wertschöpfend beziehungsweise nur gering wertschöpfend, jedoch für die Durchführung der Kernprozesse unbedingt notwendig [vgl. bspw. Seidlmeier, 2006, S. 3], [Staud, 2006, S. 11], [Becker und Kahn, 2005, S. 7]. Wichtig bei der Einordnung von Geschäftsprozessen zu Prozessklassen ist die Abhängigkeit der Zuordnung vom Unternehmenszweck [vgl. Jung, 2006a, S. 23]. Die Geschäftsprozesse der Logistik in einem Handels- oder Industrieunternehmen würden beispielsweise 34

Eine Zweiteilung in Kern- und Supportprozesse nehmen ebenfalls [Osterloh und Frost, 2006] vor.


57

den Unterstützungsprozessen zugeordnet werden. Für ein Logistikunternehmen, welches anderen Unternehmen logistische Dienstleistungen anbietet, wären dies klare Kernprozesse. Die Wertkette nach [Porter, 2000] bietet weiterhin die Möglichkeit, primäre Geschäftsprozesse beziehungsweise Kerngeschäftsprozesse weiter zu differenzieren. Analog den primären Aktivitäten entlang der Wertkette können Kerngeschäftsprozesse grundsätzlich in Kerngeschäftsprozesse der Eingangslogistik, der Operationen (die Fertigung beziehungsweise Erstellung im weitesten Sinne), des Marketing und des Vertriebs, der Ausgangslogistik und des Kundendiensts unterschieden werden. Diese Unterteilung ist für die meisten Industrieunternehmen gültig. Von besonderem Interesse im Bezug auf Contact-Center sind hierbei die Kerngeschäftsprozesse des Kundenservice, worauf sich Contact-Center zumeist konzentrieren. Für das zu entwickelnde Referenzmodell wird in dieser Arbeit nach folgender Dreiteilung unterschieden: Führungsprozesse – Kernprozesse – Unterstützungsprozesse. Der Grund hierfür liegt in den jeweils unterschiedlichen Fokussierungen der Geschäftsprozesse und den abweichenden Interessensvertreter (Stakeholder) dieser Prozessklassen im Unternehmen, die entsprechend berücksichtigt werden müssen.

4.1.3. Prozessorientierung und Prozessorganisation Die Definition von Geschäftsprozessen sowie die entsprechende Aufteilung in Prozessklassen dient nicht einem Selbstzweck. Die Ausrichtung der Geschäftsprozesse auf entscheidende Faktoren im Unternehmen wie Wertschöpfung und Kundenorientierung lassen es zu, Geschäftsprozesse verstärkt in den Mittelpunkt zu setzen und Aktivitäten im Unternehmen „prozessorientiert“ zu betrachten. Insgesamt ist zu prüfen, ob die Ausrichtung der gesamten Unternehmensorganisation auf Geschäftsprozesse (Prozessorganisation), sinnvoll ist. Die Frage nach Prozessorientierung im Unternehmen und einer Prozessorganisation ist nicht neu. Hierzu gibt es bereits frühe Ansätze von [Nordsieck, 1934] und [Nordsieck, 1972], der eine Gliederung der Unternehmensaufgaben nach „den natürlichen technischen Prozessabschnitten“ fordert. Diese Ansätze wurden nicht weiter verfolgt. Erst in den 80er Jahren wurde diese Thematik wieder aufgenommen, vor allem durch [Gaitanides, 1983]. Darin wird in erster Linie die theoretische Fundierung und Grundlagen einer Prozessorganisation entwickelt (aus der Definition betrieblicher Aufgaben werden Stellen und Organisationseinheiten abgeleitet). In den 90er Jahren folgten weitere Konzepte, beispielsweise von [Davenport, 1993], [Hammer und Champy, 1996] und [Porter, 2000]. Aus dem deutschsprachigen Raum sei besonders die Arbeit von [Scheer, 2002] erwähnt. Darin werden Methoden zum systematischen Entwurf und zur Optimierung von Geschäftsprozessen entwickelt, vor allem vor dem Hintergrund der Einführung von Anwendungssystemen. Diese Konzepte stehen jedoch nicht in einem größeren konzeptionellen Gesamtzusammenhang

58


und liefern beispielsweise weitgehend kein Vorgehensmodell hin zu einer Prozessorganisation [vgl. Becker und Kahn, 2005, S. 6]. Neben Konzepten wie „Lean Management“ oder „Six-Sigma“ wurde besonders das Konzept „Business Reengineering“ durch [Hammer und Champy, 1996] bekannt. Darin wird eine radikale Einführung einer Prozessorganisation durch die Neuorganisation sämtlicher Geschäftsprozesse propagiert. Dieses Konzept in seiner ursprünglichen Ausprägung gilt inzwischen als überholt, wobei jedoch „viele damals entwickelte Prinzipien nach wie vor gültig und Bestandteil aktueller Konzepte [sind]“ [vgl. Allweyer, 2005, S. 80]. Hier gilt es nun, einen aktuellen Überblick über das Thema Prozessorganisation und die dazugehörigen Bestandteile zu geben. Im Wesentlichen setzt sich das Konzept „Prozessorganisation“ aus den folgenden drei Merkmalen zusammen [in Anlehnung an Seidlmeier, 2006, S. 3 - 4]: 1. Prozessidee und „Primat der Prozesse“, 2. prozessorientierte Organisationsgestaltung und 3. informationale Vernetzung. Die Prozessidee, beziehungsweise mit mehr Nachdruck formuliert das „Primat der Prozesse“ [Seidlmeier, 2006, S. 3], meint grundsätzlich eine Verankerung des Prozessgedankens im Unternehmen [vgl. Allweyer, 2005, S. 103]. Ausgehend von der strategischen Ebene gilt, dass alle Geschäftsprozesse auf höchster Aggregationsebene auf die Unternehmensstrategie ausgelegt werden [vgl. Fischermanns und Völpel, 2006, S. 285]. Auf nachfolgende Aggregations- beziehungsweise Detaillierungsebenen wird dies in gleicher Weise angewandt und weiter konkretisiert. Dabei stehen immer die Erfüllung des Kundenwunsches und die Erreichung der Geschäftsziele im Vordergrund [vgl. Schmelzer und Sesselmann, 2008, S. 65]. Die durchgängige Darstellung eines Geschäftsprozesses vom Kundenwunsch bis zu dessen Erfüllung erlaubt eine einfache Änderung und proaktive Optimierung des Geschäftsprozesses, sobald Probleme sichtbar werden. Mit durchgehender Prozesssicht ergibt sich somit auch eine größere Agilität für das Unternehmen [vgl. Smith und Fingar, 2006]. In diesem Zusammenhang wird auch die Differenzierung der Geschäftsprozesse nach den Prozessklassen Kernprozess und Supportprozess wichtig. Die Kernkompetenzen eines Unternehmens werden in den Kernprozessen erbracht, darüber differenziert sich das Unternehmen hauptsächlich gegenüber dem Markt und gegenüber den Kunden. Supportprozesse unterscheiden sich dabei eventuell weniger und können mit anderen Unternehmen verglichen werden (im Sinne des „Benchmarking“), gegebenenfalls auch im Rahmen des Outsourcing an Drittanbieter übergeben werden [vgl. Osterloh und Frost, 2006, S. 38]. Im Sinne der Prozessidee mit ihrer Ende-zu-Ende-Betrachtung liegen viele Abläufe von Geschäftsprozessen „quer zur klassischen Aufbauorganisation“, da zwischen Kundenwunsch und Leistungserstellung unter Umständen viele verschiedene Organisationseinheiten beteiligt sind [vgl. Staud, 2006, S. 8] (vergleiche dazu Abbildung 22). Begründet ist dies in der Aufteilung nach Aufbau- und Ablauforganisation der klassischen Organisationsgestaltung. [Osterloh und Frost, 2006, S. 31 - 32] beschreiben die zu Grunde liegende


59

Problemstellung: „Die Aufbauorganisation setzt die Prämissen, so dass die Regelung der Abläufe zu einer nachgeordneten, möglichst algorithmisierbaren Angelegenheit wird“. Für eine Umsetzung der Prozessidee im Unternehmen ist somit eine eigene prozessorientierte Organisationsgestaltung notwendig. Mit dem Wechsel von funktionaler zu prozessorientierter Betrachtungsweise ergeben sich Änderungen der fachlichen und disziplinarischen Verantwortlichkeiten der Abläufe im Unternehmen. Zwei wesentliche Merkmale daraus sind35 [vgl. bspw. Willaert et al., 2007, Seidlmeier, 2006, Feldmayer und Seidenschwarz, 2005]: 1. Strukturierung organisatorischer Funktionsbereiche (Abteilungen) nach Kern- und Unterstützungsprozessen 2. Konzentration der Verantwortung für einen Geschäftsprozess auf einen Prozessverantwortlichen beziehungsweise ein Prozessteam

Abbildung 22: Prozessabläufe durch die Unternehmensorganisation [aus Schreiner, 2001, S. 12] Auf dem Weg zu einer prozessorientierten Organisationsgestaltung sind verschiedene Ausprägungen als Zwischenformen möglich, wie in Abbildung 23 dargestellt. Zum einen ist dies notwendig, um einen „sanften“ Übergang hin zur Prozessorientierung zu ermöglichen. Zum anderen ist nicht für jede Unternehmung eine voll ausgeprägte Prozessorganisation als sinnvoll zu erachten. Entscheidend hierfür ist „die Infrastruktur- und funktionale Spezifität“. Spezifisch genutzte Funktionen beziehungsweise benötigte Infrastrukturen, die nicht beliebig auf mehrere Geschäftsprozesse „geteilt“ werden können, bedürfen einer mehr funktionsorientierten Organisation, wohingegen „analoge Aufgabenkonstellation, geringe Spezifität und hohe Ressourcenteilbarkeit, [...] zu einer prozessbezogenen Organisationslösung [führt]“ [Seidlmeier, 2006, S. 4]. Letzteres ist in besonderem Maße in Contact-Centern gegeben (vergleiche dazu auch Abschnitt 2.3.4). 35

Vgl. auch „Stelle“ und „Abteilung“ im Abschnitt 2.3.3 Aufbauorganisation

60


Abbildung 23: Zwischenformen prozessorientierter Organisationsgestaltung [aus Osterloh und Frost, 2006, S. 110] Prozessorientierte Organisationsgestaltung ist weitergehend auch als Basis für unternehmensübergreifende Organisationsformen denkbar. Weitet man die Ansätze der Prozessidee auch auf Lieferanten und Subunternehmen aus, kann man Geschäftsprozesse als eine Verkettung der Geschäftsprozesse aller beteiligten Unternehmen verstehen [vgl. Feldmayer und Seidenschwarz, 2005, S. 72]. [Weske, 2007, S. 21 ff.] bezeichnet dies beispielsweise als Prozesschoreografie. Für Contact-Center als virtuelle Organisation ist Prozesschoreografie ebenfalls von hoher Relevanz (vergleiche dazu Abschnitt 2.2). Als wesentlich wurde die Einführung der Prozessverantwortung als Funktion (Stelle) bereits erwähnt. Prozessverantwortliche sind für die funktionale Organisation sowie für interprozessuale und schnittstellenbezogene Optimierung zuständig. Sie erhalten die zugehörigen Befugnisse für Gestaltung, Optimierung und Steuerung der überantworteten Geschäftsprozesse [vgl. Feldmayer und Seidenschwarz, 2005, S. 12]. Darüber hinaus gibt es noch weitere Rollen, die in einer prozessorientierten Aufbauorganisation zusätzlich hinzukommen. Nach einer Untersuchung von [Schmelzer, 2005] gibt es zusätzlich folgende Akteure: Prozessvorstand („Chief Process Engineer (CPO)“ mit Verantwortung für die Prozessorganisation auf oberster Managementebene [vgl. hierzu auch Abolhassan, 2005]), Projektleiter (zur Einführung der Prozessorganisation), Prozessberater, Prozesscontroller sowie Prozesskoordinator [vgl. auch Schmelzer und Sesselmann, 2008, Osterloh und Frost, 2006]. Die Beziehungen zwischen den Rollen (siehe Abbildung 24) sowie die benötigten Kompetenzen untersucht [Eicker et al., 2008, S. 252 ff.]. Aus IT-technologischer Sicht kommen noch Systemarchitekt und Entwickler hinzu [vgl. Weske, 2007, S. 13]. Drittes wesentliches Merkmal der Prozessorganisation ist die informationale Vernetzung.


61

Abbildung 24: Beziehungen zwischen den Rollen in einer Prozessorganisation [aus Eicker et al., 2008, S. 253] Darunter fallen die Auswirkungen der modernen Informationstechnologie auf die Gestaltung von Geschäftsprozessen. Tabelle 2 zeigt beispielhaft die wichtigsten Einflussfaktoren. Diese werden im Referenzmodell mit dem besonderen Einfluss der Serviceorientierung und Ereignisorientierung erneut aufgegriffen. Prägnant zusammengefasst lässt sich festhalten: „[Die] Summe aller Prozesse bildet die Prozessorganisation“ [Fischermanns, 2006, S. 12]. Dabei gibt es drei wesentliche Merkmale: die Durchgängigkeit der Maßgaben der Prozessidee in allen Unternehmensbelangen, die prozessorientierte Ausrichtung der Unternehmensorganisation sowie den Einfluss moderner Informationstechnologie auf die Prozessgestaltung. Den strategischen Wert einer Prozessorganisation und den positiven Zusammenhang zwischen Prozessorientierung und Unternehmenserfolg weisen dabei [McCormack und Johnson, 2001] und [Schwenker, 2008, S. 121 ff.] nach. [Willaert et al., 2007] zeigt den positiven statistischen Einfluss von Größen wie Prozessidee, organisatorische Integration (Verringerung der Schnittstellen), Prozessperformanz, Personalmanagement, prozessunterstützende IT sowie Lieferantenorientierung auf das Maß der Prozessorientierung. Hinzu kommen allgemeine Merkmale wie geringerer Koordinationsaufwand, Zielgrößensteuerung, kontinuierliche Verbesserung und Teamarbeit [vgl. Schmelzer und Sesselmann, 2008, S. 83], [Jung, 2006a, S. 23 - 26]. Die besondere Anwendbarkeit der Prozessorganisation als Organisationsform für Contact-Center ergibt sich aus den in diesem Abschnitt dargelegten Zusammenhängen, weiterhin aus den Unterschieden einer Prozessorganisation im Vergleich zu tayloristischen Organisationen. Dies sind ein „breiterer Aufgabenzuschnitt, wenige Hierarchieebenen, fachlich breit ausgebildete Mitarbeiter mit kundenorientierten Aufgaben [und] ein dynamisches, komplexes

62


Einflussfaktor

Beschreibung

Automatisierung

Ersatz menschlicher Arbeit durch automatisierte Prozesse

Informatisierung

„Digitalisierung“ von Informationen und Anreicherung von Prozessen mit Informationen

Sequentialisierung

Veränderung des Ablaufs sowie Parallelisieren von Abläufen

Monitoring

Überwachung des Prozessstatus in Echtzeit

Analyse

Analyseverbesserungen zur Entscheidungsunterstützung

Überwindung geografischer Grenzen

Prozesskoordination über Grenzen hinweg

Integration

Integration und Koordination von Prozessen und Aufgaben

Wissensmanagement Verbesserung der Wissensgenerierung und Wissensverbreitung Schnittstelleneliminierung

Minimierung von Prozessschnittstellen

Tabelle 2: Einfluss der Informationstechnologie auf die Prozessorganisation [in Anlehnung an Davenport, 1993, S. 51] Wettbewerbsumfeld“ [Osterloh und Frost, 2006, S. 25].

Fazit Mit der Kenntnis der Prozessklassen lassen sich primäre Geschäftsprozesse für Contact-Center finden, die die eigentliche Wertschöpfung beinhalten. Die Abgrenzung, welche Prozesse Kernprozesse sind, kann durchaus anders sein als in anderen Unternehmen. Da Contact-Center virtuelle Unternehmen sind, treten sie als Outsourcing-Partner auf, das heißt, alle übernommenen Aufgaben werden Kernprozesse, primär sind dies Geschäftsprozesse des Kundenservice. Auf diese muss die Organisation angepasst werden. Die Anwendbarkeit der Prozessorganisation auf Contact-Center ist gegeben, die angeführten Indizien nach [Seidlmeier, 2006, S. 4] und [Osterloh und Frost, 2006, S. 25] werden voll erfüllt. Die Umsetzung der Prozessorientierung wird somit zur Maßgabe des Referenzmodells. Für die Festlegung der Aufgaben gilt die Definition der Geschäftsprozesse. Die Besonderheit ist hier, sie beginnen mit dem Eingang des Kundenwunsches über einen Kontaktkanal und müssen erst verteilt werden (Routing). Laut Definition des Geschäftsprozesses fällt dies mit in die Betrachtung und muss im Referenzmodell berücksichtigt werden. Um eine Prozesschoreografie zu ermöglichen (virtuelles Unternehmen), müssen Standards

4.2. Geschäftsprozessmanagement

63

benutzt werden. Die Einflussfaktoren der informationalen Vernetzung aus Tabelle 2 müssen ebenfalls im Referenzmodell berücksichtigt werden.

4.2. Geschäftsprozessmanagement „Organisation ist dann eine dynamische Kernkompetenz, wenn sie Effizienz (die Dinge richtig tun) und Effektivität (die richtigen Dinge tun) gleichermaßen realisiert“ [Osterloh und Frost, 2006, S. 132]. Prozessorganisation und Prozessorientierung stellen im Sinne dieser Aussage das Zielgebäude der Effektivität dar, mit anderen Worten ist dadurch die Frage des „Was?“ geklärt. Offen bleibt noch die Frage nach dem „Wie?“. Dies soll mit den folgenden Abschnitten zum Thema Geschäftsprozessmanagement beantwortet werden.

4.2.1. Definition Geschäftsprozessmanagement Unter Management versteht man gemeinhin aufeinander abgestimmte Tätigkeiten zur Lenkung und Steuerung einer Organisation [in Anlehnung an ISO9000, 2000]. Folgt man dieser Definition, so ist Geschäftsprozessmanagement analog eine Sammlung von Tätigkeiten zur Lenkung und Steuerung einer Prozessorganisation. Ähnlich definiert [Kugeler, 2001, S. 386 ff.] Geschäftsprozessmanagement. Für ihn „dient [es] der Planung, Steuerung und Kontrolle von inner- und überbetrieblichen Prozessen, wobei sowohl Kern- als auch Supportprozesse Gegenstand des Prozessmanagements sind“. [Schreiner, 2001, S. 11] gibt eine erweiterte Definition und zählt die notwendigen Tätigkeiten auf: „Geschäftsprozessmanagement ist ein Rahmenkonzept zur Gestaltung, Erfassung, Optimierung, Verwaltung, Steuerung, Umsetzung und Kontrolle von betrieblichen Abläufen und Verwendung geeigneter Methoden und Werkzeuge.“ [Weske, 2007, S. 5] geht ebenfalls detaillierter auf die Tätigkeiten ein: „Business process management includes concepts, methods, and techniques to support the design, administration, configuration, enactment, and analysis of business processes.“ Geschäftsprozessmanagement ist auf Dauer ausgelegt und wird kontinuierlich angewandt. Neben den Vorgehensweisen regelt es auch Inhalte der Prozessorganisation wie Verantwortlichkeiten und „kulturflankierende Maßnahmen“, die im Zusammenhang mit Prozessorientierung notwendig sind [vgl. Fischermanns und Völpel, 2006, S. 286]. Geschäftsprozessmanagement orientiert sich an einer übergreifenden Geschäftsstrategie und leitet daraus marktund kundenorientierte Prozessstrategien ab. Die Planung und Steuerung der prozessorientierten Aktivitäten sind dabei gezielt marktund ergebnisorientiert [vgl. Feldmayer und Seidenschwarz, 2005, S. 13]. Strategische Ziele sollen „durch erstklassige Leistungen und Angebote systematisch zufriedengestellt werden“ [Bräkling und Oidtmann, 2006, S. 48 ff.]. Die Systematik wird durch das Geschäftsprozessmanagement sichergestellt.

64


Geschäftsprozessmanagement lässt sich noch weiter durch Annäherung an die verfolgten Ziele beschreiben. Eines der Hauptziele des Geschäftsprozessmanagements ist die Steigerung des Unternehmenswertes durch Verbesserung der Effektivität und Effizienz des Unternehmens. Notwendig ist dies, da nach wie vor „viele Effektivitäts- und Effizienzprobleme in Unternehmen [...] ihre Ursache in nicht vorhandenen oder unzureichenden Geschäftsprozessen [haben]“ [Schmelzer und Sesselmann, 2008, S. 52]. Als weiteres Hauptziel wird die Anpassbarkeit von Geschäftsprozessen an sich laufend verändernde Anforderungen gesehen [vgl. Jung, 2006a, S. 16]. Eine Reduzierung der Komplexität, die Beherrschung der Geschäftsprozesse sowie ein besseres Verständnis der Beziehungen durch Schaffung einer Prozesstransparenz stehen dabei im Fokus und sollen die Grundlage für systematische Verbesserungen bilden [vgl. Weske, 2007, S. 21], [Feldmayer und Seidenschwarz, 2005, S. 11]. Seit der Veröffentlichung von [Gaitanides, 1983] wurde Geschäftsprozessmanagement mit zunehmender Bedeutung als ganzheitliches Konzept in Forschung und Praxis entwickelt und weiterentwickelt. Dabei flossen unterschiedliche „Traditionen“ in das Geschäftsprozessmanagement mit ein (siehe Abbildung 25). Zum einen sind dies Bestrebungen in Richtung Vereinfachung und Qualität wie beispielsweise „Total Quality Management“ (TQM), Six-Sigma oder Kaizen mit dem Hauptfokus der kontinuierlichen Prozessverbesserung. Zum anderen gibt es die Tradition des Prozessmanagements mit dem Ziel der Verbesserung der Unternehmensperformanz. Weiterhin gibt es eine IT-fokussierte Tradition (beispielsweise geprägt durch [Scheer, 2002]) mit dem Hauptfokus der Prozessautomatisierung [zusammengestellt von Harmon, 2008]. Geschäftsprozessmanagement greift auf eine Reihe dieser bekannten Konzepte zurück oder wurde von diesen inspiriert, ist jedoch nicht mit diesen identisch. Nach Auffassung von [Fischermanns und Völpel, 2006, S. 286] liegt mit dem Geschäftsprozessmanagement inzwischen ein „ganzheitliches Konzept“ vor.

Abbildung 25: „Traditionen“ des Geschäftsprozessmanagement [aus Harmon, 2008, S. 3] Trotz der Erreichung des Status eines ganzheitlichen Konzepts befindet sich Geschäftspro-


65

zessmanagement in einem kontinuierlichen Entwicklungsprozess. Die Triebfedern hierzu sind derzeit die IT-Abteilungen. Die sich eventuell daraus ergebende Problematik beschreiben [Schmelzer und Sesselmann, 2008, S. 46]: „Durch das starke Engagement der IT und der Informatik wird die technikorientierte Sicht des Prozessmanagements deutlich stärker als die betriebswirtschaftliche Sicht vertreten.“ Deutlich erkennbar ist, dass der weltweit verbreitete englische Begriff „business process management“ (BPM) sehr häufig mit IT-Lösungen gleichgesetzt wird (beispielhaft die Veröffentlichungen von [Weske, 2007] oder [Ehlers, 2006]; [Scheer et al., 2006b] unterscheiden in diesem Zusammenhang sogar technisches und betriebswirtschaftliches Geschäftsprozessmanagement; [Allweyer, 2005, S. 42] beschreibt die Umsetzung der Geschäftsprozesse in Informationssysteme als eine der zentralen Aufgaben des Geschäftsprozessmanagements). Aus anderem Blickwinkel hat IT instrumentellen Charakter: Erst nach Klärung von Grundfragen der Strategie, Organisation und des Controlling soll eine Entscheidung bezüglich der IT-Unterstützung getroffen werden [vgl. Schmelzer und Sesselmann, 2008, S. 53]. Es bleibt fraglich, ob die Dominanz der einen oder anderen Seite hinderlich oder förderlich ist. Wichtiger erscheint die Weiterentwicklung eines abgestimmten und ausgewogenen Konzepts mit allen relevanten Größen beider Disziplinen. In den weiteren Ausführungen wird dieses Verständnis verfolgt und Geschäftsprozessmanagement als ganzheitliches Konzept mit dem zusätzlichen Aspekt des integrierten Managementkonzepts verstanden. 4.2.2. Geschäftsprozessmanagement als integriertes Managementkonzept Eine aktuelle Definition von Geschäftsprozessmanagement lautet: „Unter Geschäftsprozessmanagement wird ein integriertes Konzept von Führung, Organisation und Controlling verstanden, das eine zielgerichtete Steuerung der Geschäftsprozesse ermöglicht. Es ist auf die Erfüllung der Bedürfnisse der Kunden und anderer Interessengruppen (Mitarbeiter, Kapitalgeber, Eigentümer, Lieferanten, Partner, Gesellschaft) ausgerichtet und trägt wesentlich dazu bei, die strategischen und operativen Ziele des Unternehmens zu erreichen“ [Schmelzer und Sesselmann, 2008, S. 52]. In diesem Verständnis ist Geschäftsprozessmanagement ein „integriertes Konzept“. Wesentlich entwickelt wurde „Das Konzept Integriertes Management“ an der Universität St. Gallen, vor allem durch [Bleicher, 2004]. Für ihn ist auf Grund von gestiegener Komplexität durch sich verändernde Rahmenbedingungen ein neues, ganzheitliches und vernetztes (systemisches) Denken notwendig, das die verschiedenen Managementebenen verbindet. Er schlägt deshalb eine stufenweise Erarbeitung von Systemzusammenhängen geringer Komplexität hin zu Systemzusammenhängen höherer Komplexität vor, mit dem Ziel, Ganzheitlichkeit mit Hilfe der Integration als Syntheseprozess zu erschließen [vgl. Bleicher, 2004, S. 51 ff. und 594]. Er sieht in integriertem Management die „Harmonisation eines hochkomplexen Netzwerkes auf der Grundlage einer Management-Philosophie“ [Bleicher, 2004, S. 589 ff.].

66


Geschäftsprozessmanagement und das Konzept von [Bleicher, 2004] decken sich inhaltlich in vielen Aussagen. [Bleicher, 2004, S. 52] fordert ein „[...] Umdenken hin zu einer neuen Perspektive, die von der Idee der Ganzheitlichkeit getragen wird, [und] sich prozessualen Zusammenhängen in Systemen [zuwendet]“. Die Analyse, Darstellung, Vernetzung, Optimierung der prozessualen Zusammenhänge sind Kernaufgabe des Geschäftsprozessmanagements. Weiterhin fordert [Bleicher, 2004] eine „Bewegung entlang der Wertschöpfungskette“: Dies beinhaltet eine kundenbezogene Problemlösung, die Reduktion der Komplexität, die Konzentration auf eigene, wenig imitierbare Kernkompetenzen, die Verlagerung der Wertschöpfungskette zu höherwertigen Stufen sowie eine „Entwicklung integrierender Kernfähigkeiten zum Management eines ständig wechselnden, auftragsabhängigen Unternehmensverbundes mit unterschiedlichen Aufgaben und Partnern [...]“ [Bleicher, 2004, S. 137 - 138]. All dies sind wesentliche Bestandteile der Aussagen des Geschäftsprozessmanagements. Es liegt nahe, Geschäftsprozessmanagement als Teil oder als teilweise oder komplette Umsetzung eines integrierten Managementkonzepts zu betrachten und es deshalb selbst als „integriert“ zu bezeichnen.

Abbildung 26: Managementsysteme für die Unternehmensebenen [aus Ellringmann, 2000, S. 7] Integration ist zudem in mindestens zwei Dimensionen entlang der Managementebenen (siehe Abbildung 26) denkbar. Für [Bleicher, 2004] ist eine vertikale Verbindung der verschiedenen Managementkonzepte der normativen, strategischen und operativen Ebene zu einem integrierten Managementkonzept wichtig. Darüber hinaus gibt es in den einzelnen Ebenen (horizontal) unterschiedliche Managementkonzepte, die Detailaspekte der Unternehmensführung betrachten, wie beispielsweise Risikomanagement, Qualitätsmanagement, Wissensmanagement oder Umweltmanagement. Diese haben in ihren Ansätzen, Vorgehensweisen und Methoden enge Beziehungen zu Geschäftsprozessen. Bindeglied ist hierbei immer der Geschäftsprozess, der Tätigkeiten und Objekte verknüpft, denen ein gewisses Risiko anhaftet, die Qualitätsanforderungen erfüllen müssen, die Wissenskonsumenten oder Wissenserzeuger sind oder gewisse Umweltbelastungen erzeugen. „Durch Integration werden Anforderungen nicht mehr isoliert sondern ganzheitlich betrachtet, sie


67

werden den Arbeitsschritten zugeordnet“ [Ellringmann, 2000, S. 12]. Geschäftsprozessmanagement spielt somit in vielen Konzepten und Methoden eine wichtige Rolle. Tabelle 3 gibt einen Überblick darüber, welche Konzepte sich wie im Geschäftsprozessmanagement wiederfinden. Auf Grund der Vielzahl von Konzepten im Unternehmen ist es deshalb wichtig, eine gemeinsame Systematik für alle Aspekte zu finden und Regelungen zu reduzieren; es wird dabei integriert, nicht addiert [vgl. Ellringmann, 2000, S. 13]. Findet dabei nicht die notwendige Integration und Zielabstimmung statt, kommt es zu möglichen Redundanzen und Zielabweichungen, möglicherweise auch zu gegenläufigen Zielen [vgl. Schmelzer und Sesselmann, 2008, S. 26]. Managementkonzept, Managementmethode

Beziehung zum Geschäftsprozessmanagement

Strategisches Management

Voraussetzung für GPM

Balanced Scorecard

wichtig für GPM

Restrukturierung

günstig für GPM

Wertorientiertes Management

von GPM unterstützt

Asset Management


Total Quality Management


Change Management

wichtig für GPM

Wissensmanagement


Customer Relationship Management

in GPM integriert

Supply Chain Management

in GPM integriert

Lean Management


Simultaneous Engineering


Business Process Reengineering

in GPM integriert

KAIZEN, KVP

in GPM integriert

Six Sigma

in GPM integriert

Prozesskostenrechnung

in GPM integriert

Benchmarking

wichtig für GPM

Outsourcing


Tabelle 3: Anteile weiterer Managementkonzepte im Geschäftsprozessmanagement [aus Schmelzer und Sesselmann, 2008, S. 13] Die Einschätzung bezüglich Wichtigkeit von Geschäftsprozessmanagement und die Zufriedenheit der Anwender mit dieser Methode wird durch [Matzler et al., 2004] bestätigt:

68


Neben strategischem Management wurde das Geschäftsprozessmanagement in beiden Kategorien als am höchsten eingestuft [vgl. Matzler et al., 2004, S. 83]. Relevant ist die Integration von Managementsystemen weiterhin für das hier zu entwickelnde Referenzmodell. Durch die Betrachtung von Service- und Ereignisorientierung als weitere Detailaspekte des Managements müssen auch diese sinnvoll integriert werden.

4.2.3. Aufgaben des Geschäftsprozessmanagements Zur Strukturierung der Aufgaben im Rahmen des Geschäftsprozessmanagements ist als Bezugsrahmen eine hierarchische, beziehungsweise eine zeitliche und sach-logische Abfolge hilfreich. Ausgangspunkt ist dabei das Wissen, dass Prozesse zumindest implizit vorhanden sind, im besten Falle bereits explizit in irgendeiner Weise genauer bekannt und fixiert sind. Auf dieser Grundlage werden die vorhandenen Geschäftsprozesse in der Geschäftsprozessmodellierung identifiziert, klassifiziert, beschrieben, dokumentiert und in Beziehung gesetzt. Ergebnis ist ein durchgängiges Geschäftsprozessmodell des IstZustandes. Darauf aufbauend wird im Rahmen des Geschäftsprozesscontrollings eine Analyse und Bewertung vorgenommen. Die Geschäftsprozessoptimierung setzt wiederum auf dieser Basis auf und nimmt kontinuierliche Optimierungen an den jeweiligen Geschäftsprozessen vor. Eine spezielle Form der Optimierung ist die Automatisierung von Geschäftsprozessen, die entsprechend vorbereitete Geschäftsprozesse benötigt. Im Verständnis dieses Bezugsrahmens sind die nachfolgenden Abschnitte gegliedert, wie Abbildung 27 zeigt. Zusätzlich erfolgt im letzten Abschnitt dieses Kapitels eine besondere Betrachtung der Dienstleistung im Geschäftsprozessmanagement.

Abbildung 27: Aufgaben des Geschäftsprozessmanagements In der Literatur ist eine Anordnung der Aufgaben des Geschäftsprozessmanagements in ähnlicher Weise zu finden. Vergleicht man Veröffentlichungen, die nicht nur Teilaspekte betrachten, sondern ein komplettes Vorgehensmodell darstellen, gibt es Unterscheidungen in der Begrifflichkeit und folglich auch in der Zuordnung von Teilaufgaben zu bestimmten Oberpunkten. Für [Fischermanns, 2006] sind die „Prozessgestaltung“ sowie die „kontinuierliche Prozessoptimierung“ (neben der „strategischen Prozessorganisation“) die wesentlichen Aspekte des Geschäftsprozessmanagements, wobei Teilaspekte der Geschäftsprozessmodellierung


69

einerseits als Aufgabe der strategischen Prozessorganisation gesehen werden (beispielsweise das Unternehmensprozessmodell), andererseits Teil der Prozessgestaltung sind, wie die Erhebung, Modellierung aber auch die Analyse, Optimierung und die Einführung. Die Teilaspekte der Optimierung werden als Prozessdesign verstanden, die kontinuierliche Prozessoptimierung gesondert betrachtet. Eine ähnliche Unterscheidung nimmt auch [Allweyer, 2005] vor: Neben Aspekten des strategischen Prozessmanagements sind der „Prozessentwurf“, die „Prozessimplementierung“ (die Einführung von Prozessen im Unternehmen) sowie das „Prozesscontrolling“ wesentlich. Im Prozessentwurf finden sich die Aufgaben der Modellierung, der Optimierung sowie der Simulation wieder. Im Vergleich dazu stellen [Schmelzer und Sesselmann, 2008] die oben genannten Inhalte der Geschäftsprozessmodellierung dreiteilig dar: Gestaltung, Beschreibung sowie Prozessstandardisierung mit Modellbildung. Planung, Kontrolle und Steuerung von Geschäftsprozessen wird im Rahmen des Geschäftsprozesscontrollings dargestellt, ebenso die Optimierung als Teilaspekt. Trotz der beispielhaft gezeigten Unterscheidungen und eventueller Fokussierungen sind die Grundstrukturen gleich und Unterschiede meist nur in der Detailebene zu finden. Für die folgende Darstellung der Aufgaben des Geschäftsprozessmanagements ist jedoch im Rahmen dieser Arbeit primär wichtig, den inhaltlich gleichen Kern der Aufgaben darzustellen, da die grundlegenden Inhalte (Methoden, Vorgehensweisen, Ideen) im Referenzmodell angewendet werden. Mit Bezug auf die verschiedenen Unternehmensebenen36 beziehen sich oben dargestellte Aufgaben auf die operative Unternehmensebene und können als operative Aufgaben des Geschäftsprozessmanagements verstanden werden. Strategische und normative Aufgaben leiten sich ebenfalls aus dem Konzept des integrierten Managements ab und beziehen sich vor allem auf die Prozessorientierung und Prozessorganisation. Sie sind Teil der Managementlehre und werden hier nicht explizit erläutert. Wichtig ist jedoch der Einfluss der normativen und strategischen Ebene auf die operative Ebene. Erst mit Vorgabe der Unternehmensvision, einer entsprechend abgeleiteten Geschäftspolitik beziehungsweise Strategie sowie der daraus resultierenden Ziele und entsprechender Werte (Abbildung 28) können die operativen Aufgaben sinnvoll durchgeführt werden.

Fazit Das Geschäftsprozessmanagement wird als Methode des Referenzmodells festgelegt, um der strategischen Zielvorgabe der Umsetzung der Kundenorientierung systematisch nachzugehen. Im Sinne des integrierten Managementkonzepts ist bereits eine Vielzahl von verwandten Konzepten aufgenommen worden oder sie werden unterstützt. Es besteht die Möglichkeit, dies um folgende Aspekte zu erweitern: Serviceorientierung, Ereignisorientierung und die problematische Trennung zwischen (i) kommunikationsrelevanten Prozessen und Systemen und (ii) operativen Geschäftsprozessen und deren IT-Systeme (siehe Abschnitt 2.3.2). Die Idee der Integration begegnet der vorherrschenden Komplexität 36

Normative, strategische und operative Ebene, wie in Abbildung 26 (Seite 66) dargestellt.

70


Abbildung 28: Notwendige normative und strategische Vorgaben für die operative Ebene [nach Bräkling und Oidtmann, 2006, S. 5] in Contact-Centern; die notwendige Flexibilität, die ein Outsourcing-Anbieter abdecken muss, wird durch die identifizierten Methoden unterstützt. Sie müssen alle innerhalb des Referenzmodells berücksichtigt werden, um die notwendigen Aspekte eines Regelkreises abzudecken.

4.3. Geschäftsprozessmodellierung Als Geschäftsprozessmodellierung wird allgemein die betriebswirtschaftliche und informationstechnische Abbildung von Geschäftsprozessen und zugehöriger Objekte wie Funktionen, Daten oder Organisationseinheiten verstanden [vgl. bspw. Scheer und Zimmermann, 1996], [Becker und Meise, 2005]. Dazu wird im folgenden Abschnitt als Basis der Geschäftsprozessmodellierung das Prozessmodell eingeführt. Anschließend werden die Methoden der Geschäftsprozessmodellierung dargestellt sowie die Architektur integrierter Informationssysteme (ARIS) und die Business Process Management Notation (BPMN) ausführlicher diskutiert.

4.3.1. Prozessmodelle Geschäftsprozesse sind keine losgelösten, unabhängigen Einzelelemente im Rahmen der unternehmerischen Wertschöpfung, sondern sie sind modular und hierarchisch aufgebaut [vgl. Feldmayer und Seidenschwarz, 2005, S. 18]. Auf Grund des hierarchischen Aufbaus kann die Geschäftsprozessdefinition um eine Ebenensicht mit abgestuften Detaillierungsgraden erweitert werden. Wird ein Geschäftsprozess in seine Teilschritte zerlegt, so können

4.3. Geschäftsprozessmodellierung

71

diese Teilschritte wiederum als Prozesse in einer feineren Detaillierung beschrieben werden. Diese Verfeinerung kann über mehrere Ebenen erfolgen (vgl. Abbildung 29) [vgl. Fischermanns, 2006, S. 92].

Abbildung 29: Beispiel für Prozessebenen verschiedener Detaillierung Um die daraus entstehende Komplexität zu beherrschen, wird ein übergeordnetes Modell, ein sogenanntes Prozessmodell, benötigt. Das Prozessmodell soll die vorhandenen Detailmodelle (Teilprozesse) in einen Gesamtzusammenhang stellen, eine Navigation durch die Geschäftsprozesse ermöglichen [vgl. Becker und Meise, 2005, S. 105] und dabei die Geschäftsprozesse und Teilprozesse über die jeweiligen Ebenen vollständig und überschneidungsfrei abbilden [vgl. Schmelzer und Sesselmann, 2008, S. 230]. Als sichtbares Ergebnis entsteht daraus eine sogenannte Prozesslandkarte. Sie stellt die Hauptgeschäftsprozesse des Unternehmens übersichtlich und in ihrem Zusammenhang dar und bildet einen ersten Ordnungsrahmen [vgl. Allweyer, 2005, S. 223]. Das Prozessmodell als Ordnungsrahmen gliedert alle relevanten Elemente und Beziehungen der Geschäftsprozesse auf abstrakter Ebene und nach einer gewählten Strukturierung. Dazu gehört ebenfalls die Auswahl einer beliebigen Beschreibungssprache, im Zusammenhang mit der Darstellung durch Symbole oft als Notation bezeichnet. Der Ordnungsrahmen dient dem Zweck, einen Überblick über das Original (in diesem Fall das Unternehmen in Form der Summe der Geschäftsprozesse) zu geben [vgl. Meise, 2001, S. 62]. Der Ordnungsrahmen beziehungsweise das Prozessmodell kann neben der Detaillierung um weitere Sichten erweitert werden, um nicht alle modellrelevanten Sachverhalte in einer einzigen Darstellung (Modell) abzubilden. Jede Sicht umfasst dabei einen bestimmten Aspekt, wie beispielsweise die beteiligten Organisationseinheiten oder IT-Werkzeuge (siehe Abbildung 30). Umfangreiche Prozessmodelle können so durch Sichtenbildung in übersichtlichere Teilmodelle unterteilt werden [vgl. Allweyer, 2005, S. 140], [Gadatsch, 2008, S. 78].

72


Abbildung 30: Prozess- und Struktursichten im Prozessmodell [aus Gadatsch, 2008, S. 80] Im Rahmen der Forschung und des Praxiseinsatzes der Geschäftsprozessmodellierung wurden in den letzten Jahren zahlreiche sogenannte Standardprozessmodelle von Fachleuten, Gremien oder Verbänden entwickelt. Sie beschreiben idealtypische Geschäftsprozesse und sie werden für bestimmte Anwendungsbereiche oder Branchen entwickelt. Sie sind generell als Vorlage oder Checkliste anwendbar und sollen zur Identifikation, Gestaltung, Dokumentation und Analyse spezifischer Geschäftsprozesse herangezogen werden können [vgl. Schmelzer und Sesselmann, 2008, S. 230]. Dem gegenüber stehen individuelle Prozessmodelle, sogenannte Unternehmensprozessmodelle. Diese werden an die spezifischen Gegebenheiten eines Unternehmens angepasst und dabei individuell konzipiert oder aus Standardprozessmodellen abgeleitet [vgl. Schmelzer und Sesselmann, 2008, S. 235 - 236]. Standardprozessmodelle für Contact-Center konnten im Rahmen der Literaturrecherche nicht eingegrenzt werden, es ist daher notwendig, ein jeweils individuelles Contact-Center-Prozessmodell als Unternehmensprozessmodell zu erstellen. Dies ist unter anderem der Tatsache geschuldet, dass Contact-Center als Outsourcing-Partner von Unternehmen aus unterschiedlichsten Branchen Geschäftsprozesse bearbeiten. Eine Übernahme von Teilen eines Standardprozessmodells aus der jeweiligen Branche ist denkbar, jedoch für jedes Contact-Center verschieden.

4.3.2. Methoden der Geschäftsprozessmodellierung Das Prozessmodell, wie oben dargestellt, dient als Ordnungs- und Bezugsrahmen zur Identifizierung, Strukturierung, Beschreibung und Vernetzung von Geschäftsprozessen und ist


73

Grundlage der folgenden Methoden in der Geschäftsprozessmodellierung: • Identifikation und Strukturierung von Geschäftsprozessen • Beschreibung und Vernetzung von Geschäftsprozessen • Konventionshandbuch

Identifikation und Strukturierung von Geschäftsprozessen Die Identifikation von Geschäftsprozessen steht zu Beginn der Geschäftsprozessmodellierung. Sie soll die Frage klären, welche Geschäftsprozesse im Unternehmen (beziehungsweise einer Geschäftseinheit davon) zur Erfüllung der Bedürfnisse interner und externer Kunden benötigt werden [vgl. Schmelzer und Sesselmann, 2008, S. 121]. Hilfreich für die Identifikation sind zum einen die Fragen danach, welche Produkte angeboten werden und für welche Kunden diese angeboten werden [vgl. Fischermanns, 2006, S. 105]. Zum anderen kann mit Blick auf die Wertschöpfungskette die Aufzählung der notwendigen Kernaufgaben des Unternehmens hilfreich sein [vgl. Bräkling und Oidtmann, 2006, S. 50]. Darüber hinaus bieten Zielmärkte, Kundengruppen, -anforderungen, -bedürfnisse und -erwartungen, die Wettbewerbsstrategie sowie die Kernkompetenzen im Unternehmen wesentliche Anhaltspunkte [vgl. Schmelzer und Sesselmann, 2008, S. 123 - 124]. Der nächste beziehungsweise parallele Arbeitsschritt nach der Identifikation ist die inhaltliche Strukturierung der Geschäftsprozesse. Hierfür können die Prozessklassen (Kernprozesse, Supportprozesse und Führungsprozesse) sowie ebenfalls die Wertschöpfungskette herangezogen werden. Betrachtet man die Wertkette nach [Porter, 2000] (Abbildung 21, Seite 55), so könnten die Geschäftsprozesse auf oberster Ebene beispielhaft sein: Eingangslogistik, Operationen, Marketing und Vertrieb, Ausgangslogistik, Kundendienst (die primären Aktivitäten, analog die Kernprozesse) sowie Personalwirtschaft, Technologieentwicklung und Beschaffung (als Supportprozesse). Diese können zum besseren Verständnis an dieser Stelle als Kerngeschäftsprozesse bezeichnet werden (oberste Ebene, Kernund Supportprozesse mit gleichem Abstraktionsgrad). Beispiele für Kerngeschäftsprozesse nach [Mertens, 2007] sind: Forschung und Produktentwicklung, Anfrage- und Angebotsabwicklung, Auftragsabwicklung, Materialbeschaffung, Produktionsplanung und -steuerung, Reklamation sowie Kundendienst. Noch stärker abstrahiert [Lohse, 1996] die Kerngeschäftsprozesse: Beschaffung und Vertrieb („Order to Delivery“), Produkt- und Dienstleistungsentwicklung und -erstellung („Time to Market“) und Kundenservice („Customer Service“). Die Anzahl der Kerngeschäftsprozesse ist dabei sehr gering (meist fünf bis zehn). Einen genauen Überblick hierzu gibt [Schmelzer und Sesselmann, 2008, S. 81]. Interessant im Zusammenhang mit Contact-Centern erscheint hierbei besonders die Unterteilungen nach [Lohse, 1996] und [Mertens, 2007], wonach Kundenservice beziehungsweise Kundendienst der Kerngeschäftsprozess ist, der größtenteils durch Contact-Center erbracht wird. Somit ist es unter Umständen möglich und sinnvoll, dass ein Contact-Center nur einen Kerngeschäftsprozess hat, nämlich „Kunden betreuen“.

74


An diesem Beispiel des Kerngeschäftsprozesses „Kunden betreuen“ wird ein weiteres Prinzip der Geschäftsprozessmodellierung sichtbar: Für die Benennung von Geschäftsprozessen wird häufig nach dem Objekt-Verrichtungs-Prinzip vorgegangen. Dabei wird das Informationsobjekt (als Substantiv) des Geschäftsprozesses sowie die zugehörige Verrichtung (als Verb im Infinitiv) benutzt [vgl. bspw. Gadatsch, 2008, S. 204]. Für den oben genannten Kerngeschäftsprozess sind die „Kunden“ das Informationsobjekt und „betreuen“ das passende Verb zur Beschreibung der Verrichtung. Nach dieser Weise werden die Geschäftsprozesse der oberen Abstraktionsebenen identifiziert und benannt. Sie werden weiterhin strukturiert, in dem die Teilprozesse der nachfolgenden Abstraktionsebene im Sinne der Prozessebenen ebenfalls identifiziert und benannt werden (analog Abbildung 29, Seite 71). Darüber hinaus gehende Inhalte werden an dieser Stelle der Abstraktion noch nicht identifiziert. So entsteht eine Prozesslandkarte (siehe Beispiel in Abbildung 31), zunächst allein mit den Bezeichnungen der Geschäftsprozesse. Diese ist wiederum individuell und nur im Kontext eines spezifischen Unternehmens gültig [vgl. Feldmayer und Seidenschwarz, 2005, S. 22].

Abbildung 31: Beispiel einer Prozesslandkarte mit Ebenen und Prozessklassen

Beschreibung und Vernetzung von Geschäftsprozessen An die Identifikation und Strukturierung der Geschäftsprozesse schließt sich die Erhebung und Analyse des Istzustandes in Form der Beschreibung, Dokumentation und detaillierten Vernetzung der


75

Geschäftsprozesse sowie deren Objekte an. Das Prozessmodell wird somit weiter mit detaillierten Inhalten gefüllt. Dies gilt als Basis für alle weiteren Aufgaben (Controlling, Optimierung, Automatisierung) des Geschäftsprozessmanagements [vgl. bspw. Schwegmann und Laske, 2005, S. 155]. Zentrale Bedeutung bei der Beschreibung hat die Visualisierung der Geschäftsprozesse und ihrer Schnittstellen. Ziel dabei ist es, die Geschäftsprozessabläufe und die beteiligten Objekte grafisch aufzuzeigen [vgl. Feldmayer und Seidenschwarz, 2005, S. 47 ff.]. Dies geschieht erst ab einer gewissen Ebene im Prozessmodell, in der der notwendige Detaillierungsgrad erreicht wird. Dies wird im Konventionenhandbuch festgelegt (siehe folgenden Abschnitt) und ist von den organisatorischen Gestaltungsregeln abhängig. Grundsätzlich geschieht dies ab der Detaillierungsebene im Unternehmensprozessmodell, ab der eine konkrete Leistungsanforderung des Kunden genannt werden kann und es konkrete Prozessergebnisse gibt [vgl. Schmelzer und Sesselmann, 2008, S. 183]. In den darüber liegenden Ebenen liegt der Fokus auf der Darstellung der Wertschöpfungskette an sich. Für die Beschreibung beziehungsweise die Dokumentation gibt es verschiedene Möglichkeiten: Zunächst ist eine Beschreibung in textueller Form oder als tabellarische Darstellung möglich. Umfangreiche oder komplexe Vorgänge sind so jedoch nur bedingt darstellbar. Die grafische Darstellung dagegen ist anschaulich und der Kontrollfluss kann übersichtlich dargestellt werden. Werden bei der grafischen Darstellung Regeln festgelegt, so ist eine gleichartige und durchgängig verbindliche Darstellung sowie ein einheitliches Verständnis gegeben. Regeln bieten die Möglichkeit, Prozessmodelle auswertbar, analysierbar und weiterverwendbar zu machen [vgl. Allweyer, 2005, S. 133 - 134], [van der Aalst et al., 2003, S. 6]. Für die grafische Darstellung in den unterschiedlichen Detaillierungsebenen gibt es meist unterschiedliche Modelltypen innerhalb des Prozessmodells, die untereinander verknüpft sind. Ein detailliertes Prozessmodell zur Beschreibung eines Geschäftsprozesses muss dabei folgende Mindestanforderungen abdecken [in Anlehnung an Ellringmann, 2000, S. 12 - 13], [Bräkling und Oidtmann, 2006, S. 60], [Fischermanns, 2006, S. 183 - 184], [Allweyer, 2005, S. 136]: • Identifikation, Name (Objekt und Verrichtung), Beschreibung und Inhalte des Geschäftsprozesses • Beteiligter Kunde (intern oder extern) • Input (auslösendes Ereignis, übergebene Mittel) • Output (Endereignis, übergebene Mittel) • Verwendete Mittel (Sachmittel, Informationssysteme, Informationen) • Ablaufdiagramm

76

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement • Schnittstellen (zu über- und untergeordneten Prozessmodellen sowie zu externen Prozessen) • Beteiligte Organisationseinheiten • Zeit und Ort • Prozessverantwortlicher • Zweck • Restriktionen und Rahmenbedingungen

Um diese Anforderungen in grafischer Form mittels eines entsprechenden Modelltyps abzudecken, wird in der Geschäftsprozessmodellierung häufig ein Modell nach dem in Abbildung 32 dargestellten Metamodell gewählt [vgl. Scheer et al., 2006a, S. 32].

Abbildung 32: Metamodell zur detaillierten Geschäftsprozessmodellierung [aus Scheer et al., 2006a, S. 32] Nach diesem Metamodell besteht ein Modelltyp aus einer Aggregation von Objekttypen, die im jeweiligen Modelltyp hinterlegt sind. Mit Hilfe von Verknüpfungen der Objekttypen können die Inhalte der oben genannten Anforderungen dargestellt werden. Objekte haben ein- und ausgehende Beziehungen zu den anderen Objekten im Modell. Diese Beziehungen werden über Kanten zwischen den Objekten dargestellt. Zur näheren Beschreibung von Objekten und Kanten können diesen Attribute zugeordnet werden. Abbildung 33 verdeutlicht dies: Durch die Verknüpfung von Objekten, beispielsweise eines Objekttyps „Funktion“ (Arbeitsschritt) durch ein- und ausgehende Kanten, kann die Prozessabfolge als Ablaufdiagramm dargestellt werden. Zum anderen können auch weitere Informationen, wie an der Funktion beteiligte Organisationseinheiten, Stellen oder verwendete IT-Systeme, mit Hilfe entsprechender Objekttypen in Beziehung gesetzt werden. Attribute bezeichnen dabei die Objekte näher. Im Beispiel der Abbildung 33 werden die Beziehungen mittels der Kantenattribute genauer bezeichnet („Die Funktion „Rabatte prüfen“ ist Nachfolger von Funktion „Daten erfassen““, „Die Funktion „Daten erfassen“ wird durch das IT-System „SAP R/3“ unterstützt“ und so weiter).


77

Abbildung 33: Beispiel der Modellierung eines Geschäftsprozess nach dem Metamodell Für die Darstellung des Ablaufdiagramms als Grundstruktur des Geschäftsprozesses gibt es sechs Grundformen zur Darstellung der Prozessstrukturen beziehungsweise der Folgestrukturen: Kette, UND-Verzweigung, UND-Verknüpfung, ODER-Verzweigung, ODERVerknüpfung und ODER-Rückkoppelung (Schleife). Mit Hilfe von Kombinationen dieser sechs Grundformen lassen sich selbst komplizierteste Geschäftsprozesse abbilden [vgl. Fischermanns, 2006, S. 193]. Die Modellierung mittels dieses Metamodells erlaubt auf Grund der möglichen Verknüpfungen zwischen den Objekt- und Modellinstanzen eine genaue Abbildung des wechselseitig abhängigen Wirkungsgefüges innerhalb des Modells (zur Beschreibung des Geschäftsprozesses) sowie zwischen den Modellen (dem Unternehmensprozessmodell). Auf diese Weise entsteht eine Vernetzung aller relevanten Informationen aus der Istaufnahme der Geschäftsprozessmodellierung. Das Wirkungsgefüge ist somit wirklichkeitsgetreu abgebildet, so dass Veränderungen mit all ihren Auswirkungen auf das komplette Prozessmodell nachvollzogen werden können [vgl. Scheer et al., 2006a, S. 32]. Mit Bezug auf den Geschäftsprozess in Abbildung 33 heißt dies beispielsweise: Welche Funktionen sind betroffen, wenn das IT-System „SAP R/3“ ausfällt? Abschließend ist noch die Frage zu klären, welcher Detaillierungsgrad bei der Modellierung zu wählen ist. Diese Frage kann jedoch nicht allgemein beantwortet werden. Der Detail-

78


lierungsgrad ist unter anderem abhängig vom Grad der gewünschten Vollständigkeit, der Übersichtlichkeit, der Nachvollziehbarkeit, der Erkennbarkeit kritischer Aktivitäten, der Schnittstellen zu anderen Objekten und Modellen, der Möglichkeit zur eindeutigen Verantwortungszuordnung sowie vom Aufwand-Nutzen-Verhältnis der Modellierung und des Informationsbedürfnisses der beteiligten Stellen [vgl. Jung, 2006a, S. 51].

Konventionshandbuch Ähnlich wie in der Bilanzierung und Buchhaltung, gibt es in der Geschäftsprozessmodellierung sogenannte „Grundsätze ordnungsgemäßer Modellierung“. [Rosemann et al., 2005, S. 47 - 49] beschreiben diese allgemein wie folgt: • Richtigkeit: korrekte Abbildung des Sachverhalts • Relevanz: Dokumentation der Sachverhalte der jeweiligen Perspektive • Wirtschaftlichkeit: angemessenes Kosten-Nutzen-Verhältnis der Modellierung • Klarheit: Verständlichkeit für Adressaten • Vergleichbarkeit: konforme Anwendung der Modellierungskonventionen • Systematischer Aufbau: wohldefinierte Schnittstellen wegen jeweils nur Teilaspekten auf Grund eines Komplexitätsmanagements Diese Grundsätze sind bei der Geschäftsprozessmodellierung einzuhalten. Sie bilden die Grundlage eines Modellierungsstandards, der in Form von Modellierungskonventionen in einem Handbuch erläutert wird. Diese Modellierungskonventionen sind „ein verbindlicher Leitfaden für die Modellierer“ [vgl. Rosemann et al., 2005, S. 98]. Neben den Grundsätzen ordnungsgemäßer Modellierung bestehen Modellierungskonventionen konkret aus Grundsätzen und Regeln einer einheitlichen Prozessarchitektur und deren Umsetzung in einem Modell. Darin sind unter anderem enthalten die anzuwendenden Modell- und Objekttypen, deren Attribute und die zugehörigen Symbole sowie Namenskonventionen und Modellierungsregeln [vgl. Feldmayer und Seidenschwarz, 2005, S. 25]. Durch Modellierungskonventionen wird sichergestellt, dass auch bei mehreren Modellierern einheitliche Modelle entstehen [vgl. Allweyer, 2005, S. 135]. Die darin beschriebenen formalen Methoden stellen sicher, dass in den der Modellierung nachgelagerten Aufgaben des Geschäftsprozessmanagements keine Möglichkeiten für Zweideutigkeiten aufkommen können. Formale Methoden erhöhen dabei das Analysepotential [vgl. van der Aalst et al., 2003, S. 6]. Grundsätzlich bilden folgende Strukturelemente den Inhalt und Aufbau der Modellierungskonventionen in einem Konventionshandbuch [nach Rosemann et al., 2005, S. 99 100]: • Ziel und Geltungsbereich: Ziel und Zweck, für den die Modellierungskonventionen erstellt wurden (Unternehmen, Projekt)


79

• Organisatorische Rahmenbedingungen: Festlegung von Verantwortlichkeiten und Prozessen im Rahmen der Modellierung und Pflege der Geschäftsprozessmodelle • Prozessmodellarchitektur: Vorschriften für Modellierer zur Unterteilung, Beziehungsgestaltung und Zweck innerhalb des Unternehmensprozessmodells (analog „Identifikation und Strukturierung“) • Konventionen für Modelltypen: Verwendungshinweise und Vorschriften in Bezug auf einzelne Modelltypen insbesondere die Verwendung von Attributen und Objekttypen • Perspektiven: Beschreibung, aus welcher Perspektive beziehungsweise aus welchen Perspektiven zu modellieren ist und in welcher Weise diese zu berücksichtigen sind • Technische Hinweise: Technische Hinweise zur Verwendung von Modellierungswerkzeugen • Anlagen: Angabe aller zusätzlich gültigen Unterlagen, Vorlagen, Dokumentationen und sonstiger Anlagen, die für die Modellierung von Bedeutung sind Das Konventionshandbuch wird vor Beginn der Geschäftsprozessmodellierung zusammengestellt. Es wird individuell für ein Unternehmen erstellt und kann, wie bei Prozessmodellen auch, neu erstellt oder von Standard- beziehungsweise Referenzkonventionshandbüchern abgeleitet werden. Als Teil daraus sind zusätzlich Modellierungshandbücher als Anwendungsleitfäden für Modellierer möglich [vgl. Feldmayer und Seidenschwarz, 2005, S. 25]. 4.3.3. Exkurs: Architektur integrierter Informationssysteme (ARIS) und Business Process Management Notation (BPMN) „Eine Methode ist eine Vorschrift zur Durchführung einer Aktivität und zur Repräsentation ihrer Ergebnisse“ [Alpar et al., 2005, S. 283]. Die Methoden der Geschäftsprozessmodellierung sind Vorschriften zur Durchführung der notwendigen Schritte hin zu einem vollständigen Unternehmensprozessmodell und sie dokumentieren ihre Ergebnisse (Repräsentation). Hierzu gibt es zahlreiche Möglichkeiten; an dieser Stelle sollen zwei davon auf Grund ihrer Bedeutung dargestellt werden: • Architektur integrierter Informationssysteme (ARIS) und • Business Process Management Notation (BPMN) Beide werden in der Literatur in Bezug auf die Aufgaben des Geschäftsprozessmanagements derzeit am häufigsten herangezogen: ARIS auf Grund der großen Bekanntheit und der breiten theoretischen Fundierung und BPMN als neuer und häufig diskutierter Notationsstandard der Object Management Group (OMG). Es ist nicht Ziel des folgenden Abschnitts ARIS und BPMN ausführlich zu diskutieren und vollumfänglich darzustellen.

80


Es sollen aber wesentliche Eigenschaften und wichtige Elemente daraus (beispielsweise hier verwendete Modelltypen) erklärt werden, die für das Verständnis dieser Arbeit und den Gebrauch im Referenzmodell notwendig sind. Architektur integrierter Informationssysteme ARIS stellt einen allgemeinen Bezugsrahmen „für die systematische und gesamthafte Geschäftsprozessmodellierung“ dar [Scheer, 2002, S. 2]. ARIS wurde von Professor Scheer entwickelt und in [Scheer, 1991] erstmals vorgestellt. Nach heutigem Stand hat ARIS vier Anwendungsaspekte: • Bezugsrahmen: ARIS-Konzept beziehungsweise ARIS-Haus als Bezugsrahmen zur Geschäftsprozessbeschreibung • Modellierungsmethoden: ARIS-Konzept stellt Modellierungsmethoden mit einer Metastruktur basierend auf einem einheitlichen Informationsmodell bereit • Werkzeug: ARIS-Toolset37 als computergestütztes Werkzeug • ARIS HOBE: „ARIS House of Business Engineering (HOBE)“ als Ansatz zum ganzheitlichen computergestützten Geschäftsprozessmanagement [vgl. Scheer, 2001] ARIS als Bezugsrahmen dient als Modell für alle Geschäftsprozesse im Unternehmen. Hierzu wurde das ARIS-Haus entwickelt (siehe Abbildung 34). Hierbei wurden zwei Grundgedanken besonders berücksichtigt [vgl. Scheer, 1997, S. 10 ff., S. 89]: 1. Beherrschung der Komplexität der Modelle durch Sichtenbildung nach Organisation, Funktion, Leistung, Daten und Steuerung. 2. Einführung von drei unterschiedlichen Beschreibungsebenen in allen Sichten, abhängig von der unterschiedlichen Nähe zur IT: Fachkonzept, DV-Konzept und Implementierung. Ausgegangen wird dabei von der betriebswirtschaftlichen Problemstellung, die in der Fachkonzeptebene beschrieben wird, über die Umsetzungsbeschreibung im DV-Konzept38 bis hin zur Implementierung. Die Gewichtung der Sichten innerhalb von ARIS liegt jedoch stark auf der fachlichen Ebene. Das ARIS-Konzept bietet in allen Sichten und Beschreibungsebenen passende Modelltypen an. Die Verwendung bestimmter Modelltypen wird dabei nicht vorgeschrieben, ebenfalls keine Reihenfolgen. ARIS entspricht in erster Näherung eher einem Baukastenprinzip [vgl. Lehmann, 2008, S. 25]. Eine Auflistung der wichtigsten darin enthaltenen Modelltypen ergibt sich nach [Seidlmeier, 2006, S. 51 ff.] und [Lehmann, 2008, S. 29 ff.] wie folgt39 : 37

Das ARIS-Toolset als Werkzeug der IDS Scheer AG wird hier nicht weiter betrachtet. Es wird unter anderem ausführlich von [Davis, 2008], [Davis und Brabänder, 2007] oder [Seidlmeier, 2006] behandelt. DV-Konzept steht für Datenverarbeitungs-Konzept. Diese Bezeichnung ist inzwischen etwas überholt und meint IT-Konzept. 39 Die einzelnen Modelltypen werden hier nicht weiter beschrieben, sie werden in den genannten Quellen ausführlich dargestellt. 38


81

Abbildung 34: ARIS-Haus [aus Scheer, 2001, S. 1] • Organisationssicht: Organigramm • Funktionssicht: Funktionsbaum, Zieldiagramm, Anwendungssystemtypendiagramm • Leistungssicht: Produktbaum • Datensicht: Fachbegriffsmodell, erweitertes Entity-Relationship-Modell (eERM), eERMAttribut-Zuordnungs-Diagramm • Steuerungssicht: Vorgangskettendiagramm, Funktionszuordnungsdiagramm, Wertschöpfungskettendiagramm, Ereignisgesteuerte Prozessketten Je nach Problemstellung sind einzelne Modelltypen zu verwenden und untereinander zu verknüpfen [vgl. Lehmann, 2008, S. 25]. Für die Methoden der Geschäftsprozessmodellierung genügen die ereignisgesteuerten Prozessketten sowie das Wertschöpfungskettendiagramm, sie werden anschließend dargestellt. Als vierter Anwendungsaspekt von ARIS bleibt das ARIS-House of Business Engineering (HOBE) zu nennen. „[Es] beruht auf dem Grundverständnis, dass Strategie, Prozesse und IT nicht isoliert voneinander sondern stets als eine zu managende Einheit gesehen werden müssen“ [Scheer et al., 2005, S. 4]. Dieser Aspekt bezieht alle Aufgaben des Geschäftsprozessmanagements von der Modellierung, Optimierung, Steuerung bis zur Automatisierung in ein 4-Ebenen-Modell mit ein, das untereinander mit Regelkreisen verbunden ist. Das HOBE ist ein umfangreicher Ansatz zur Unternehmenssteuerung mit Hilfe von ARIS, wobei die entwickelten ARIS-Methoden und ARIS-Software-Tools integriert wurden [vgl.

82


Scheer, 1996, S. 7 ff.]. Der ARIS HOBE-Ansatz wurde kontinuierlich weiter entwickelt, optimiert und zu einem neuen Konzept überarbeitet, dem ARIS House of Business Process Management (siehe Abbildung 35) [Scheer et al., 2005, S. 3].

Abbildung 35: ARIS House of Business Process Management [aus Scheer et al., 2005, S. 4] Im ARIS House of Business Process Management werden drei relevante Aspekte des Geschäftsprozessmanagements betrachtet: Die Unternehmensstrategie auf der obersten Ebene, der Entwurf, die Optimierung und das Controlling auf der mittleren Ebene sowie die operative Ausführung und deren IT-Unterstützung auf der unteren Ebene [aus Scheer et al., 2005, S. 3]. Somit bildet es ein komplettes ARIS-Referenzmodell basierend auf der Architektur und den Werkzeugen von ARIS. Wertschöpfungskettendiagramm Das Wertschöpfungskettendiagramm ist ein ARISModelltyp der Steuerungssicht auf Fachkonzeptebene. Es eignet sich besonders für die Identifikation und Strukturierung von Geschäftsprozessen (siehe Methode auf Seite 73). Mit Hilfe von Wertschöpfungskettendiagrammen lassen sich Funktionsabfolgen analog ihrer Wertschöpfung eines Produkts oder einer Dienstleistung darstellen [vgl. Rosemann et al., 2005, S. 64]. Die Darstellung geschieht dabei auf hohem Abstraktionsniveau und verwendet lediglich den Objekttyp „Funktion“ in zwei grafischen Darstellungen (abhängig davon, ob die Darstellung als erste Funktion einer Kette erfolgt oder als Zwischenglied) [vgl. Lehmann, 2008, S. 58]. Die nachfolgende Abbildung 36 zeigt ein Beispiel eines Wertschöpfungskettendiagramms, das einen Ausschnitt aus einer Prozesslandkarte eines Contact-Centers darstellen könnte. Auf oberster Abstraktionsebene zeigt es erneut den Kerngeschäftsprozess „Kunde betreuen“. Dieser ist auf gleicher Ebene Nachfolger von „Vertrieb sicherstellen“, dies wird durch die Kante mit dem Attribut „ist Vorgänger von“


83

angezeigt. Die Kundenbetreuung gliedert sich in mehrere Funktionen (Geschäftsprozesse), die in ihrer Abfolge als Wertschöpfungskette abgebildet sind. Diese sind eine Abstraktionsebene tiefer angesiedelt, dies verdeutlicht der Kantentyp „ist prozessorientiert übergeordnet“. Auf diese Weise lässt sich mit Hilfe eines Wertschöpfungskettendiagramms eine Prozesslandkarte abbilden.

Abbildung 36: Beispiel eines Wertschöpfungskettendiagramms Wertschöpfungskettendiagramme dienen als Übersichtsdarstellung und strukturieren die Kerngeschäftsprozesse und Geschäftsprozesse hoher Abstraktionsebenen. Sie sind der Einstiegspunkt für detailliertere Geschäftsprozessmodelle [vgl. Rosemann et al., 2005, S. 64]. Mit Hilfe von sogenannten Hinterlegungen beziehungsweise Verknüpfungen zu anderen Modelltypen lassen sich die Modelle verbinden und stufenweise verfeinern. So kann beispielsweise aus dem Wertschöpfungskettendiagramm in einen detaillierteren Modelltyp (eine Ebene tiefer) gewechselt werden. Dies könnte wiederum ein Wertschöpfungskettendiagramm sein oder beispielsweise eine ereignisgesteuerte Prozesskette. Ereignisgesteuerte Prozessketten Die ereignisgesteuerten Prozessketten (EPK) sind ebenfalls ein ARIS-Modelltyp der Steuerungssicht auf Fachkonzeptebene. Erstmals veröffentlicht wurden sie von [Keller et al., 1992]. EPK sind zwischenzeitlich eine der am weitesten verbreitete semi-formalen Methode und Notation zur Geschäftsprozessmodellierung [vgl. Staud, 2006, S. 59]. In ihrer ursprünglichen Form bestehen EPK aus den folgenden vier Grundelementen [nach Keller et al., 1992, S. 8 ff.]: • Funktion: Eine Funktion entspricht einer Aufgabe beziehungsweise einem betriebswirtschaftlichen Vorgang zur Leistungserstellung. Der Funktionsbegriff zielt dabei auf das „Was“ ab, nicht auf das „Wie“. • Informationsobjekt: Im Zusammenhang mit dem „Was“ einer Funktion steht das Informationsobjekt. „Informationsobjekte stellen Mengen realer oder abstrakter Dinge

84

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement dar, die für ein Unternehmen von Interesse sind“. Sie werden in Funktionen bearbeitet. In der einfachsten Form der Modellierung mit EPK sind Informationsobjekte im Namen (nach Objekt-Verrichtungs-Prinzip) einer Funktion enthalten. • Ereignis: Innerhalb der Modellierung mit EPK stellt ein Ereignis einen eingetretenen Zustand eines oder mehrerer Informationsobjekte dar. Ereignisse können Funktionen auslösen. Funktionen werden durch Ereignisse ausgelöst. Ereignisse repräsentieren einen eingetretenen betriebswirtschaftlichen Zustand. Ereignisse dienen zur Spezifikation betriebswirtschaftlicher Bedingungen und Ereignisse können auf Informationsobjekte des Datenmodells referenzieren. • Operatoren und Kontrollfluss: Der Kontrollfluss (abwechselnde Abfolge von Ereignissen und Funktionen) wird durch Kanten dargestellt. Operatoren (UND, ODER, exklusives ODER) modellieren dabei die Beziehung unter Ereignissen beziehungsweise unter Funktionen [vgl. auch Staud, 2006, S. 66].

Ein Beispiel einer EPK mit den Grundformen zeigt Abbildung 37. Dabei wurde, ausgelöst von einem Startereignis, eine Folge von Funktionen und Ereignissen modelliert. Funktionen werden grundsätzlich von Ereignissen ausgelöst und enden mit einem Ereignis. Auf diese Weise einsteht eine sich abwechselnde Folge von Ereignis, Funktion, Ereignis und so weiter. Unterscheidungen und parallele Abläufe können mit Hilfe von Operatoren (Regeln) dargestellt werden. Funktion 2 kann beispielsweise zwei disjunkte Ergebnisse liefern. Entweder tritt Ereignis 2a oder Ereignis 2b ein, der Kontrollfluss wird entsprechend in nur einem Strang fortgesetzt. Beendet wird eine EPK immer mit einem Endereignis. Nach diesem Prinzip werden grundsätzlich alle EPK aufgebaut und modelliert. Hierzu gibt es eine Reihe von allgemeingültigen Modellierungsregeln und weiterer Vorschriften sowie spezieller Aspekte (beispielsweise Schleifendarstellung oder Wartezeiten), die im Zusammenhang mit EPK-Modellen wichtig sind. Diese sind ausführlich beispielsweise in [Davis und Brabänder, 2007], [Staud, 2006], [Gadatsch, 2008] oder [Lehmann, 2008] dargestellt40 . EPK sind Teil der Steuerungssicht. Aufgabe der Steuerungssicht ist es, die Sichten (Funktion, Organisation, Daten und Leistung) untereinander in Beziehung zu setzen. Dies gilt sowohl für strukturelle Beziehungen als auch für dynamische Veränderungen im Sinne einer Zustandsänderung [vgl. Scheer, 2001, S. 102]. Zur Erfüllung dieser Aufgabe wurde das EPK-Modell zur sogenannten erweiterten EPK (eEPK)41 weiterentwickelt und um weitere Objekttypen (Symbole) der jeweiligen Sichten ergänzt. Eine Auflistung dieser sogenannten Erweiterungsobjekttypen macht beispielsweise [Lehmann, 2008, S. 78 - 79 (Auszug)]: • Organisationsspezifische Objekttypen: Organisationseinheitstyp, Organisationseinheit, Stellentyp, Stelle, Stellenbeschreibung, Personentyp (Rolle), Standort, Arbeitsplatz • Datenspezifische Objekttypen: Cluster, Entitytyp, Beziehungstyp, Information (Ist), Information (Soll), Fachbegriff 40 41

Auf Grund des Umfangs wird auf eine Darstellung in dieser Arbeit verzichtet. Aus Gründen der Einfachheit wird weiterhin das Akronym „EPK“ auch für „eEPK“ verwendet.


85

Abbildung 37: Beispiel einer EPK mit Grundelementen • Leistungsspezifische Objekttypen: Leistung, Dienstleistung, Informationsdienstleistung, Produkt • Funktionsspezifische Objekttypen: Funktion, Automation, Interaktion, Systemfunktion Darüber hinaus können weitere Sichten hinzugefügt werden, beziehungsweise die bestehenden Sichten unterschieden werden [Auszug ebenfalls aus Lehmann, 2008, S. 79]: • Wissensorientierte Objekttypen: Wissenskategorie, dokumentiertes Wissen • Objektorientierte Objekttypen: Business Object, Package, Class

86

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement • Ausprägungen des Objekttyps Informationsträger: Datei, Dokument, elektronisches Dokument, Brief, Buch, Drucker • Anwendungssystemorientierte Objekttypen: Liste, Maske, Typ DV-Funktion, DVFunktion, Typ Anwendungssystem, Anwendungssystem • Allgemeine ressourcenorientierte Objekttypen: allgemeine Ressource, Betriebsmittel • Managementorientierte Objekttypen: Ziel, Berechtigungsbedingung, Kennzahlinstanz, Kostenart, Cost-Driver, Risiko • IT-City-Plan-orientierte Objekttypen: Zone, District, Cluster, Functional Block, IT System, Subsystem, IT Software

Die Symbole der Erweiterungsobjekttypen werden in der eEPK ebenfalls mit Hilfe von Kanten untereinander sinnvoll verbunden. Das Typ-Attribut der Kante qualifiziert dabei die Art der Beziehung. In Abbildung 38 wird dies an ausgewählten Erweiterungsobjekttypen verdeutlicht: Zum Beispiel ist die Funktion „Rabattanspruch prüfen“ über eine Kante mit einer Organisationseinheit „Hartwarenabteilung“ verbunden, die fachlich dafür verantwortlich ist (Typ der Beziehungskante); die Funktion wird weiterhin vom Anwendungssystemtyp „CIM-System“ unterstützt und so weiter. Auf diese Weise werden in der EPK Objekte anderer Sichten an exakter Stelle (aus Steuerungssicht) mit abgebildet. Die Objekte finden sich dabei auch in anderen Modelltypen wieder, die deren jeweilige Sicht beschreiben, etwa ein Organigramm mit Organisationseinheiten. Erweiterte EPK sind ein geeigneter Modelltyp zur Beschreibung und Vernetzung von Geschäftsprozessen auf der mittleren und detaillierten Abstraktionsebene (siehe Methode auf Seite 74). Dies wird durch das einheitliche Informationsmodell von ARIS innerhalb des Software-Werkzeugs mit Hilfe einer Datenbank ermöglicht. Darin werden alle Objekte und Modelle gespeichert und eindeutig referenziert. Hierdurch ergeben sich besondere Möglichkeiten – unter anderem für die Vernetzung. Wie bereits beim Wertschöpfungskettendiagramm beschrieben, sind Hinterlegungen zu feineren Prozessmodellen möglich. Eine Verkettung auf gleicher Ebene ist mit Hilfe der Prozessschnittstelle möglich, wodurch große Modelle zur besseren Lesbarkeit in Teilmodelle untergliedert werden können. Wird bei der Verwendung von Objekten gleichen Namens auf dasselbe Objekt referenziert, spricht man von Ausprägungskopien (im Gegensatz zu Definitionskopien). Am Beispiel der Abbildung 38 verdeutlicht heißt dies: Die EPK wird auf gleicher Abstraktionsebene durch die EPK „Kundenanliegen dokumentieren“ fortgesetzt, verbunden sind die Modelle durch eine Prozessschnittstelle; die Funktion „Rabattanspruch prüfen“ wird durch eine Hinterlegung eines feineren EPK-Modells detaillierter beschrieben (ersichtlich an einem kleinen Prozesssymbol, das jeweils als Hyperlink zu anderen Modellen dient); die Organisationseinheit findet sich ebenfalls in einem Organigramm wieder, das ebenfalls hinterlegt ist. Durch die Verwendung von Ausprägungskopien, Hinterlegungen und Prozessschnittstellen entsteht so ein durchgängiges und vollständiges Prozessmodell.


87

Abbildung 38: Beispiel einer erweiterten EPK zur Abbildung der Steuerungssicht Business Process Management Notation Die Business Process Management Notation (BPMN) wurde in einer ersten Version 2004 durch die Business Process Management Initiative42 veröffentlicht und liegt nun als Spezifikation in der Version 1.1 seit Januar 2008 vor, spezifiziert durch die Object Management Group (OMG)43 . BPMN ist eine Notation zur grafischen Modellierung von Geschäftsprozessen. Geschäftsprozesse sollen angemessen visualisiert werden können, so dass Experten der Fachabteilungen BPMN verstehen und erstellen können. BPMN ist dazu ebenfalls wie die EPK kontrollflussorientiert [vgl. Gadatsch, 2008, S. 81]. Gleichzeitig verfolgt BPMN das Ziel, durch einen formalen Mechanismus die Visualisierung eines Geschäftsprozesses in eine entsprechende technische Ausführungssprache zu übertragen [OMG, 2008a, S. 11]. Die Spezifikation von BPMN beschreibt und spezifiziert eine Notation zur Beschreibung von Geschäftsprozessen, das sogenannte „Business Process Diagram (BPD)“ mit den zugehörigen Objekttypen [vgl. OMG, 2008a, S. 17 - 142]. Zusätzlich enthält die Spezifi42 43

www.bpmi.org www.omg.org – Seit 2006 arbeiten die BPMI und die OMG im Bereich Geschäftsprozessmanagement unter dem Namen „Business Modeling and Integration (BMI) Domain Task Force (DTF)“ zusammen. In diesem Zusammenhang wird seit 2006 die BPMN von OMG spezifiziert und weiterentwickelt.

88


kation einen informativen Anhang, der die Beschreibung und Beispiele zur Übertragung von BPMN-Modellen in die Ausführungssprache BPEL (vergleiche hierzu die folgenden Abschnitte 4.5 und 5.3) enthält [vgl. OMG, 2008a, S. 143 - 238]. BPMN wurde nur zur Modellierung von Geschäftsprozessen entwickelt, BPD ist dazu der einzige Modelltyp. Ausdrücklich nicht zum Umfang von BPMN gehören die Modellierung der folgenden Aspekte: Organisationsstrukturen und ihre Ressourcen, funktionale Unterteilungen, Daten- und Informationsmodelle, Strategie (im Sinne von Prozessorientierung und Prozessorganisation), Geschäftsregeln. Diese Aspekte werden anderen Spezifikationen und Modellen vorbehalten [vgl. OMG, 2008a, S. 12], [Briol, 2008, S. 18]. Zur grundlegenden Darstellung wenig komplexer Geschäftsprozesse gibt es im BPD eine Sammlung von Grundelementen, die zusammen einen Geschäftsprozess beschreiben. Diese werden in vier Kategorien eingeteilt: „Flow Objects“, „Connecting Objects“, „Swimlanes“ und „Artifacts“44 . Die Aufteilung und eine Auflistung der Elemente dieser vier Kategorien zeigt das BPMN-Meta-Modell in Abbildung 39.

Abbildung 39: BPMN-Meta-Modell der Grundelemente zur Prozessmodellierung [aus Momm et al., 2007, S. 324] Die einzelnen Elemente sind in [OMG, 2008a, S. 18 ff.] wie folgt beschrieben: • Event: Events repräsentieren Geschehnisse im Geschäftsprozessablauf. Sie haben entweder eine Ursache oder repräsentieren ein Ergebnis. Events werden in „Start“, „Intermediate“ und „End“ unterschieden. • Activity: Activity ist der generische Begriff für Tätigkeiten in einem Unternehmen, sie können atomar oder nicht-atomar sein und werden unterteilt in „Process“, „SubProcess“ und „Task“. 44

Die Begriffe werden hier im Original in Englischer Sprache wiedergegeben. Einen ersten Vorschlag zur Übersetzung macht beispielsweise [Allweyer, 2008].


89

• Gateway: Ein Gateway dient der Ablaufsteuerung durch Regelung von Verzweigungen und Verbindungen. • Sequence Flow: Der Sequence Flow verbindet Activities und legt so den Prozessablauf fest. • Message Flow: Ein Message Flow zeigt den Nachrichtenfluss zwischen den Prozessbeteiligten. • Association: Die Assoziation verbindet Informationen mit Flow Objects. Informationen können in Textform oder als grafische Elemente erscheinen. Eine Zuordnung zusätzlicher Informationen zum Prozessablauf, etwa ein Data Object (beispielweise ein Dokument), ist ebenfalls möglich. • Pool: Ein Pool beinhaltet ein Teilmodell aus obigen Elementen. Er repräsentiert die Zuständigkeit eines Prozessbeteiligten. • Lane: Lanes unterteilen einen Pool. • Group: Mit Hilfe von Gruppen werden zusammengehörige Activities zusammengefasst. Die grafischen Symbole der Grundelemente zeigt die nachfolgende Abbildung 40. Im Vergleich zu EPK werden BPD horizontal von Links nach Rechts modelliert. Pools und Lanes dienen dabei der Zuordnung der Prozessabfolgen zu den prozessbeteiligten Gruppen, beispielsweise unterschiedliche Abteilungen.

Abbildung 40: BPMN Grundelemente [aus OMG, 2008a, S. 18 - 20] Zur Beschreibung komplexer Vorgänge in Geschäftsprozessen werden die Grundelemente in den vier Kategorien in einem „Complete Element Set“ erweitert [vgl. OMG, 2008a, S. 20 ff.]. Eine übersichtliche Darstellung aller Elemente und Ausprägungen hierzu gibt [Decker et al., 2008]. Daraus ist Abbildung 41 entnommen, die beispielhaft ein BPMN-Diagramm mit den Grundelementen sowie einer Auswahl an Erweiterungen zeigt, etwa verschiedene Events (beispielsweise „Conditional Start Event“, „Intermediate Message Event“) oder Gateways (beispielsweise „Parallel Gateway“ zur Darstellung parallel ablaufender Prozesszweige).

90


Abbildung 41: BPMN-Beispiel-Prozess [aus Decker et al., 2008] Abgrenzung von ARIS und BPMN und kurze Diskussion Es gibt zahlreiche Notationen zur Geschäftsprozessmodellierung. ARIS und BPMN wurden hier auf Grund ihrer Bekanntheit und Standardisierung näher dargestellt. ARIS ist in Praxis und Lehre relativ weit verbreitet, nicht zuletzt auf Grund der Tatsache, dass EPK Teil der SAPMethodik zur Definition von SAP-Workflows waren. Zusätzlich gibt es (vor allem im deutschsprachigen Raum) eine weite Verbreitung des Software-Toolsets ARIS (und somit der Methode ARIS) [vgl. bspw. Lehmann, 2008, S. 139]. ARIS hat somit einen QuasiIndustrie-Standard erreicht. Im Vergleich dazu wurde BPMN von einem angesehen Standardisierungsgremium als Notation zur Geschäftsprozessmodellierung spezifiziert und ist weltweit bekannt. BPMN ist ungleich jünger, dies hat jedoch den Vorteil, dass es sinnvolle Aspekte anderer Modelle integriert, so etwa sehr viel aus EPK (zum Beispiel das Konzept der Ereignisse und Assoziationen). Die Standardisierung als Erfolgsvoraussetzung im Geschäftsprozessmanagement [vgl. Stähler, 2006, S. 291 - 297] ist somit für beide Ansätze gegeben. Ein näherer Vergleich zwischen ARIS und BPMN lässt sich nicht anstellen, da der Umfang von ARIS ungleich größer und weitreichender ist (vgl. hierzu die vier Anwendungsaspekte auf Seite 80). Dagegen ist ein Vergleich von EPK und BPD möglich und sinnvoll. [Kruczynski, 2008] untersucht beide Modelltypen im Hinblick auf intuitive Modellierung und kommt zu dem Ergebnis, dass sich hier beide nahezu gleich gut eignen. In der Unter-


91

suchung erfolgte eine Konzentration auf diese Fragestellung, da aus beiden Modelltypen heraus ausführbare Prozessmodelle generiert werden können und es bereits Übertragungstools zwischen beiden Modellen gibt. Darüber hinaus sind die Grundelemente beider Modelltypen durchweg identisch (siehe Abbildung 42) [vgl. Kruczynski, 2008, S. 3].

Abbildung 42: Vergleich der Grundelemente aus EPK und BPD [aus Kruczynski, 2008, S. 2] Bezogen auf die Übertragung der Modelle in ausführbare Sprachen definiert der BPMNStandard bereits Mapping-Regeln für das Übertragen von BPMN zu BPEL, die bereits von einigen Entwicklungstools unterstützt werden [vgl. Momm et al., 2007, S. 322]. Für BPMN ist dies plattformunabhängig der Fall, ARIS ist hier im Vergleich proprietär45 . In Bezug auf ausführbare Sprachen im Kontext von serviceorientierten Architekturen sind jedoch beide gleich geeignet [Kruczynski, 2008, S. 4]. Darüber hinaus lassen sich beide Modelltypen durch zusätzliche Objekttypen erweitern. 45

Das Tool der IDS Scheer AG hierzu ist der ARIS SOA Architect.

92


Ein Unterschied zwischen beiden liegt in der jeweiligen Nähe zur fachlichen oder technischen Betrachtungsweise. BPMN erfährt durch die Vorgabe, dass Modelle aus fachlicher Sicht leicht zu erstellen und zu lesen sind, aber gleichzeitig auch immer in ein ausführbares Modell übertragen werden können, einen technischeren Fokus. Die EPK dagegen legen ihren Schwerpunkt mehr auf die fachliche Beschreibung von Geschäftsprozessen, da sie auf Fachkonzeptebene angesiedelt sind. Allerdings fehlt es EPK teilweise an einer mathematischen Fundierung, da bestimmte Objekttypen Mehrdeutigkeiten und somit Spielraum für Interpretationen zulassen, da die Bedeutung einiger Konstrukte nicht eindeutig spezifiziert ist (beispielsweise der ODER-Konnektor). Aus betriebswirtschaftlicher Sicht stellt dies kein Problem dar, jedoch dann, wenn diese Modelle automatisiert werden [vgl. Lehmann, 2008, S. 142]. Auf Grund der Einbindung in die ARIS-Software-Werkzeuge gibt es für EPK eine gute Werkzeugunterstützung. Daraus und auf Grund des Datenbank-Repositorys für alle Modell- und Objekttypen ergeben sich weitere Vorteile eines Modellierungswerkzeuges gegenüber Grafikwerkzeugen: Ausprägungs- und Definitionskopien lassen sich unterscheiden und eine zentrale Verwaltung von Objekten sicherstellen, die eine Konsolidierung von Objekten und Modellen gewährleisten ebenso wie Methodenfilter zur Individualisierung eines Unternehmensprozessmodells und computergestützte Semantikprüfungen. Mit EPK ist dies auf Grund der Einbindung in ARIS möglich [Lehmann, 2008, S. 141]. Für BPMN ist eine derart umfangreiche Abdeckung derzeit noch nicht gegeben. Für die Geschäftsprozessmodelle in den folgenden Kapiteln dieser Arbeit wird hauptsächlich ARIS verwendet, insbesondere EPK und Wertschöpfungskettendiagramme. Dies geschieht aus zwei Gründen heraus: Zum einen ist für Teile des Referenzmodells ein Objektund Modellrepository zur Auswertung des Prozessmodells notwendig, zum anderen bietet ARIS eine umfänglichere Abdeckung des kompletten Geschäftsprozessmanagements inklusive der strategischen Aspekte wie Prozessorientierung und Prozessorganisation und des integrierten Managementkonzepts. BPMN bietet hier lediglich Unterstützung auf detaillierteren und technischen Ebenen. Fazit Aus den unterschiedlichen Quellen wurden drei logische Teilmethoden abgegrenzt und vorgestellt, die im Rahmen des Referenzmodells konkret auf Contact-Center ausgerichtet werden müssen. Dafür wurden die Vorteile eines Standardprozessmodells vorgestellt. Das Referenzmodell muss versuchen, ein für die Contact-Center-Praxis anwendbares Standardprozessmodell zu entwickeln, das alle Struktursichten beinhaltet, die für ein integriertes Managementkonzept für Contact-Center relevant sind. Für die Identifikation und Strukturierung von Geschäftsprozessen bedarf es einer verbindlichen Vorgabe eines Rasters und weiterer Hilfestellungen, um auch komplexe (teilweise chaotische) Unternehmensrealitäten abbilden zu können. Für die Beschreibung und Vernetzung bedarf es passender Modelltypen und Anwendungsrichtlinien. Dies alles soll die Bildung eines konkreten Konventionshandbuchs vorbereiten, das später auch die Aspekte der Serviceund Ereignisorientierung mit aufnehmen kann. Die Verwendung von ARIS ist dabei nicht

4.4. Geschäftsprozesscontrolling und -optimierung

93

verbindlich. Aus der Gegenüberstellung der beiden gängigsten Methoden (beziehungsweise Notationen) wurde jedoch ARIS ausgewählt, um damit die Teile des Referenzmodells abzubilden, die einer Prozessnotation bedürfen.

4.4. Geschäftsprozesscontrolling und -optimierung Controlling ist eine zentrale Managementaufgabe und im Sinne von Lenkung, Steuerung, Regelung im Unternehmen zu verstehen. Die Summe der Aufgaben, die sich daraus ergeben, wird als „Controllership“ bezeichnet. Im deutschen Sprachgebrauch hat sich dafür der Begriff „Controlling“ durchgesetzt. Controlling bezeichnet im Verständnis von Controllership die Funktion. Die Bezeichnung des Aufgabenträgers lautet Controller [vgl. Horváth, 2006, S. 18 - 20]. Zu den Aufgaben des Controllings gehören die Betreuung der Führungsfunktion von Planung und Kontrolle, die Informationsversorgung der Führung sowie die ergebnisorientierte Koordination von Planung und Kontrolle einerseits und der Informationsversorgung andererseits [vgl. Horváth, 2006, S. 97 - 98]. Dies ist eine der weitreichendsten Definitionen von Controlling. Überträgt man diese Sichtweise auf Geschäftsprozesscontrolling, so ist es das auf das Objekt „Geschäftsprozesse“ bezogene Controlling [vgl. bspw. Götze, 2007, S. 323], [Ahlrichs und Knuppertz, 2006, S. 6], [Knuppertz, 2008]. In der wissenschaftlichen Diskussion besteht Uneinigkeit über den Entwicklungsstand, insbesondere die theoretische Fundierung und den Umfang des Controllings [vgl. bspw. Diskussion in Weber und Hirsch, 2002]. In entsprechend höherem Maße trifft dies auch auf die Ausgereiftheit des Prozesscontrollings als jüngerem Teilgebiet zu. Um sich diesem Problem zu nähern, wird hierzu das Thema in die verschiedenen Konzeptionen des Prozesscontrollings unterteilt, die in Anlehnung an die Untersuchung zur Aufteilung der Controlling-Konzeptionen von [Zenz, 1999] geschieht46 . Dazu zählen das informationsorientierte, das regelungs- und steuerungsorientierte und das koordinationsorientierte Geschäftsprozesscontrolling sowie das strategische Geschäftsprozesscontrolling. Da diese Konzeptionen jeweils aufeinander aufbauen, werden die Inhalte und der aktuelle Diskussionsstand in den jeweiligen Abschnitten dargestellt, denen sie am besten zugeordnet werden können. Controlling als betriebswirtschaftliches Teilgebiet wird dabei nicht dargestellt (vergleiche hierzu beispielsweise [Horváth, 2006], [Küpper, 2008], [Jung, 2007]) sondern das Controlling von Geschäftsprozessen als kontinuierliche Aufgabe des Geschäftsprozessmanagements und als Teilgebiet des Controllings. 4.4.1. Informationsorientiertes Geschäftsprozesscontrolling Informationsorientiertes Geschäftsprozesscontrolling bezieht sich auf die gezielte Informationsversorgung zur Vorbereitung prozessbezogener Entscheidungen [vgl. bspw. Reich46

[Götze, 2007] nimmt eine Einteilung der Konzeptionen des Prozesscontrollings wichtiger Autoren in die Systematik von [Zenz, 1999] vor.

94


mann, 2006, S. 4 ff.]. Zu den Aufgaben der Informationsversorgung gehört zunächst die Ermittlung des Informationsbedarfs gefolgt von der Beschaffung, Aufbereitung, Speicherung und Übertragung relevanter Informationen. Die Informationen werden den Prozessverantwortlichen zur Verfügung gestellt, um so eine höhere Qualität der Entscheidungen und letztlich ein besseres Erreichen der Geschäftsprozessziele zu ermöglichen [vgl. Schmelzer und Sesselmann, 2008, S. 345]. Gängige informationsorientierte Instrumente hierzu sind Kennzahlen sowie die Prozesskostenrechnung [vgl. Fink, 2003, S. 28]. Kennzahlen und Indikatoren Relevante Informationen zu Geschäftsprozessen werden in Form von Kennzahlen ausgedrückt, denen im Geschäftsprozesscontrolling eine besondere Bedeutung zukommt [vgl. Götze, 2007, S. 326]. Kennzahlen sind Maßzahlen, die benutzt werden, um unter anderem Geschäftsprozesse zu evaluieren und einen quantifizierbaren Vergleich mit anderen Geschäftsprozessen zu erlauben. Kennzahlen werden häufig auf der Grundlage von Messwerten errechnet. Indikatoren hingegen vergleichen Kennzahlen mit Zielgrößen über die Zeit, um unter anderem Trends aufzuzeigen. Indikatoren werden benutzt, um Kennzahlen zu aggregieren und sie zu visualisieren und um so Entscheidungen zu erleichtern [vgl. Bundschuh und Dekkers, 2008, S. 180 ff.]. Häufig tritt auch der Begriff „Key Performance Indicator (KPI)“ in Erscheinung. In der Literatur zu Geschäftsprozesscontrolling wird in der Regel allerdings keine genaue Unterscheidung der Begriffe wie in [Bundschuh und Dekkers, 2008] vorgenommen. Die fünf wichtigsten Indikatoren im Geschäftsprozesscontrolling sind Prozessqualität, Prozesszeit, Termintreue, Ressourceneinsatz und Kundenzufriedenheit. Diese werden mit Ausgangswert, der Ziel- und Istgröße sowie mit einem Trend dargestellt [vgl. Schmelzer und Sesselmann, 2008, S. 345]. Typische Kennzahlen hierzu zeigt nachfolgende Abbildung 43, in der gängige Geschäftsprozesskennzahlen systematisiert wurden. Kennzahlen und Indikatoren werden von den Prozessverantwortlichen zeitgleich mit der Modellierung auf Basis der Geschäftsziele definiert [vgl. Wetzstein et al., 2008, S. 227]. Einzelne Kennzahlen und Indikatoren können dabei aber nur singuläre Sachverhalte darstellen. Es ist deshalb notwendig, die Zusammenhänge zwischen den Kennzahlen ebenfalls darzustellen und so ein Kennzahlensystem analog dem Prozessmodell zu schaffen [vgl. Tavasli, 2007, S. 177]. Es werden drei Arten von Kennzahlensystemen unterschieden: • Rechensystem: In einem Rechensystem werden quantifizierbare Kennzahlen mathematisch aggregiert und ähnlich der Prozesslandkarte nach Detaillierungsgrad geordnet [vgl. Tavasli, 2007, S. 179]. Die Umsatzkennzahl eines Kerngeschäftsprozesses addiert sich beispielsweise aus den Umsatzkennzahlen der untergeordneten Teilprozesse. • Ordnungssystem: Nicht quantifizierbare Kennzahlenbeziehungen werden in Ordnungssystemen zusammengefasst. Hier werden Kennzahlen sachlogisch geordnet, um Wirkungszusammenhänge transparent zu machen [vgl. Tavasli, 2007, S. 180]. Dies geschieht beispielsweise bei Qualitätskennzahlen.


95

Abbildung 43: Systematisierung von Geschäftsprozesskennzahlen [aus Götze, 2007, S. 327] • Zielsystem: In einem Zielsystem werden Kennzahlen so gebündelt, wie sie als Entscheidungsgrundlage für unternehmerische Entscheidungen zusammen betrachtet werden [vgl. Tavasli, 2007, S. 181]. Die Darstellung der Kennzahlen erfolgt mittels eines Geschäftsprozessberichts. Dieser Bericht zeigt das aktuelle Leistungsniveau der Geschäftsprozesse, in dem der aktuelle Prozessstatus (mittels Kennzahlen und Indikatoren aus dem Kennzahlensystem) sowie der Prozessfortschritt (mittels der Entwicklung) dargestellt werden [vgl. Schmelzer und Sesselmann, 2008, S. 345]. Vor Erstellung der Geschäftsprozessberichte werden die Messwerte erhoben. Dies kann auf drei Arten geschehen: manuelle Erhebung, Datenerhebung der verwendeten operativen ITSysteme und Datenerhebung aus Systemen zur Prozessablaufsteuerung (siehe Abschnitt 4.5). Da keine der drei Methoden ein komplettes Kennzahlensystem mit Messwerten versorgen kann, ist eine Kombination der Messwerte und Erstellung der Kennzahlen mit Hilfe eines Business Intelligence-Systems häufig angezeigt. Darin ist es möglich, Geschäftsprozessberichte zu erstellen, ad-hoc Anfragen zu stellen und Prozesscockpits darzustellen [vgl.

96


Allweyer, 2005, S. 386 - 393]. Prozesscockpits sind Online-Systeme, die Geschäftsprozessberichte am Bildschirm darstellen und meist um Echtzeitinformationen und grafische Darstellungen (Diagramme) ergänzt werden und das Berichtswesen komplettieren [vgl. bspw. Knuppertz, 2008, S. 9], [Mayer, 2005, S. 106 - 109].

Prozesskostenrechnung Neben den Dimensionen Zeit und Qualität spielen besonders die Kosten eine wichtige Rolle in der Kostenrechnung im Rahmen des Geschäftsprozesscontrolling. Ausgangslage und Problemstellung für ein Umdenken in der Kostenrechnung war eine nicht mehr verursachungsgerechte Verteilung von Gemeinkosten. Diese bilden in Unternehmen einen immer größer werdenden Anteil an den Gesamtkosten und können nicht mehr verursachungsgerecht umgelegt werden, ohne Fehler und Verzerrungen in operativen und strategischen Entscheidungen oder der Produkt- und Preispolitik nach sich zu ziehen [vgl. Coenenberg et al., 2007, S. 126], [Horváth, 2006, S. 527 ff.]. „Die Prozesskostenrechnung ist eine die vorhandene Kostenrechnung ergänzende Methodik zur Erfassung, Planung, Steuerung und Verrechnung kostenstellenübergreifender Prozesse“ [Mayer, 2005, S. 102]. Geschäftsprozesse in wenig ausgeprägten Prozessorganisationen durchlaufen mehrere Organisationseinheiten, denen meist direkt Kostenstellen zugeordnet sind. Aus diesem Grund ist ein durchgängiges und vollständiges Prozessmodell notwendig. Die Kosten eines Geschäftsprozesses können dann mittels Zuordnung bewerteter Ressourceninanspruchnahme aller am Prozess beteiligten Kostenstellen zugeordnet werden. Außerdem ist eine Weiterverrechnung der ermittelten Prozesskosten im Rahmen der mehrstufigen Deckungsbeitragsrechnung möglich [vgl. Mayer, 2005, S. 102]. Die Prozesskostenrechnung wird intensiv in Dienstleistungsunternehmen eingesetzt, da sie hier für alle Geschäftsprozesse verwendet werden kann [vgl. Horváth, 2006, S. 526]. Dies macht sie auch für Contact-Center interessant, da der Gemeinkostenanteil durch die Personalkosten besonders hoch ist. Durch die Prozesskostenrechnung lässt sich somit eine verursachungsgerechte Kostenaussage tätigen, die durch den Zusammenhang „Geschäftsprozess gleich Produkt“ direkt die Grundlage der Preisgestaltung liefert. Ausführliche Vorgehensweisen in der Prozesskostenrechnung beschreiben beispielsweise [Coenenberg et al., 2007, S. 132 ff.] und [Fischermanns, 2006, S. 258 ff.]. Die Besonderheiten der Prozesskostenrechnung in der Dienstleistung diskutieren beispielsweise [Coenenberg et al., 2007, S. 272 ff.] und [Möller und Cassack, 2008].

4.4.2. Regelungs- und steuerorientiertes Geschäftsprozesscontrolling Neben dem informationsorientiertem Konzept gibt es weitreichendere Definitionen des Controllingbegriffs, die die Vorgänge des Regelns und Steuerns mit einschließen und zu einer kontinuierlichen Geschäftsprozessoptimierung führen sollen. Die hierzu notwendigen Informationen liefern die informationsorientierten Instrumente.


97

Inhalt des regelungs- und steuerungsorientierten Geschäftsprozesscontrollings ist die zielgerichtete Geschäftsprozessgestaltung durch Planungs- und Kontrollprozesse im Rahmen des Controlling, „die unter Einbeziehung von Vor- und Rückkoppelungsinformationen regelkreisartig aufgebaut sind“ [Götze, 2007, S. 328]. Ähnlich definieren [Feldmayer und Seidenschwarz, 2005] Geschäftsprozesscontrolling als Prozessbewertung (entspricht dem informationsorientierten Konzept) und einer organisatorischen Einrichtung, „die im Sinne eines Regelkreises die zur Steuerung erforderlichen Messgrößen definiert, aufzeichnet, überwacht und dem Management verdichtete Informationen zur Verfügung stellt“ [vgl. Feldmayer und Seidenschwarz, 2005, S. 64]. Ziel der Planung, Steuerung und Regelung ist die laufende Verbesserung der Geschäftsprozesse (Geschäftsprozessoptimierung). Dadurch wird eine nachhaltige Prozessleistungsfähigkeit erreicht [vgl. Mayer, 2005, S. 100]. Der Regelkreis sieht dabei folgendermaßen aus: Zunächst werden die Prozessziele abgeleitet, anschließend werden die Geschäftsprozesse definiert und modelliert (Geschäftsprozessmodellierung). Sie werden weiterhin geplant und operationalisiert, das heißt in die Tat umgesetzt. Anschließend erfolgt die Performanzmessung mittels Kennzahlen und Indikatoren, die Hinweise auf Verbesserungspotentiale geben. Daraufhin werden die Geschäftsprozesse optimiert und die gesetzten Ziele der Optimierung wiederum gemessen und analysiert, um so den Regelkreis erneut zu beginnen. Bei der Analyse werden Maßnahmen auf Grund erkannter Abweichungen abgewogen und eingeleitet sowie Maßnahmen zur Zielerreichung festgelegt [vgl. Knuppertz, 2008, S. 10]. Die Methoden hierzu – zur Identifikation von Verbesserungspotentialen – beschreibt beispielsweise [Jung, 2006a, S. 103 ff.]: • Prozessdatenanalysen: Hierbei werden die Kennzahlen und Attribute von Geschäftsprozessen mit Bezug zu Qualität, Zeit und Kosten analysiert, insbesondere die Durchlaufzeiten, kostenintensive Prozessabschnitte und die Prozessgüte (Erfüllung der Qualitätsanforderungen). • Wertschöpfungsanalyse: Untersuchung des Wertschöpfungsanteils einzelner Prozessschritte und ihre Einteilung in Nutz-, Stütz-, Blind- und Fehlleistungen mit dem Ziel, die letzten beiden zu eliminieren. • Informationsanalyse: Analyse des Informationsflusses inklusive der Beziehungen zwischen den Tätigkeiten und Informationen („benötigt“, „erzeugt“, „geprüft“) zur Optimierung des Informationsflusses. • Leistungsanalyse: Einschätzung der Leistung des Geschäftsprozesses in Bezug auf die Anforderungen der Kunden und Vergleich mit dem Wettbewerb. • Benchmarking: Vergleich mit externen Kennzahlen, Indikatoren und Geschäftsprozesszielen mit dem Ziel, realistische und wettbewerbsadäquate Ziele (Benchmarks) zu bestimmen.

98


Diese und weitere Arten von Analysen decken Optimierungspotentiale auf. Die Analyseergebnisse geben Aufschluss darüber, auf welche Art optimiert werden kann. Einen abstrakten Überblick über mögliche Ansatzpunkte zur Optimierung in Geschäftsprozessen gibt nachfolgende Abbildung 44. Sie zeigt grundsätzliche Möglichkeiten. Auf eine genauere Darstellung der Ansatzpunkte wird hier verzichtet, da dies stark von der individuellen Zielsetzung im Unternehmen abhängig ist.

Abbildung 44: Ansatzpunkte zur Geschäftsprozessoptimierung [aus Feldmayer und Seidenschwarz, 2005, S. 63] Im Zusammenhang mit Geschäftsprozesscontrolling und -optimierung gilt die Regel: Nur was gemessen werden kann, kann auch verbessert werden. Derzeit ist allerdings noch die Tatsache problematisch, dass nur knapp ein Drittel der Unternehmen die Ergebnisse der Geschäftsprozessoptimierung messen [vgl. Schmelzer und Sesselmann, 2008, S. 48], was


99

eine Integration des Geschäftsprozesscontrollings in ein integriertes Managementkonzept besonders notwendig macht.

4.4.3. Koordinationsorientiertes und strategisches Geschäftsprozesscontrolling Die Koordination gilt als die Basisidee des Controllings nach der Auffassung von [Horváth, 2002]. „Über die Koordination des Planungs- und Kontrollsystems mit dem Informationsversorgungssystem wirkt Controlling in alle Führungssubsysteme hinein“ [Horváth, 2002, S. 56]. Controlling rückt nach dieser Definition ganz nah heran an das Management. Dem gegenüber steht die Meinung von beispielsweise [Franz und Kajüter, 2002] und anderen, die Koordination als Managementaufgabe ansehen und nicht als das des Controlling. Diese Definition und Auseinandersetzung soll hier nicht weiter vertieft werden, sie trifft auf Controlling zu, (noch) nicht aber auf Geschäftsprozesscontrolling (vergleiche hierzu die Einteilung der Autoren und Ansätze durch [Götze, 2007], der die vorhandenen Geschäftsprozesscontrollingansätze fast ausschließlich den ersten beiden Konzepten zuordnet). Wesentlich für das Geschäftsprozessmanagement als integriertes Managementkonzept sind auf koordinationsorientierter beziehungsweise strategischer Ebene die Prozessorientierung und Prozessorganisation mit der Rolle des Prozessverantwortlichen. Für das weitere Vorgehen werden allerdings die operativen Gesichtspunkte der Kennzahlen und der Steuerung in den Vordergrund gestellt.

Fazit Die Untersuchung der Konzeptionen des Controllings und das In-Beziehung-Setzen mit Geschäftsprozessmanagement führen zu einer wichtigen Abgrenzung der Aufgaben des Geschäftsprozesscontrollings, um eine bessere Einschätzung der Anwendbarkeit auf das Referenzmodell zu erhalten. Die fortlaufende Kennzahlenerstellung des informationsorientierten Geschäftsprozesscontrollings wird mit Hilfe der Ereignisorientierung umgesetzt werden. Insbesondere sind hier der Echtzeit-Aspekt und die Möglichkeit der Verbindung mit “klassischen“ Contact-Center-Kennzahlen (bisher ohne Prozessbezug) von Interesse, die die Ereignisorientierung bietet. Die Prozesskostenrechnung hat unmittelbaren Einfluss auf die Dienstleistungs- und Produktgestaltung, die Zuordnung von Kosten zu Prozessen bedarf allerdings an Material der Ergebnisrechnung, weshalb die Prozesskostenrechnung nicht weiter berücksichtigt wird. Zusätzlich wird versucht, die Event-technischen Voraussetzungen zu schaffen, um die Planungs- und Kontrollprozesse des regelungs- und steuerungsorientierten Controllings mit Hilfe des Referenzmodells abzudecken und eine Automatisierung des Regelkreises grundsätzlich zu ermöglichen. Die Ansatzpunkte der Geschäftsprozessoptimierung werden in die Gestaltungshilfen des neuen Standardprozessmodells integriert, wodurch auf die Zielsetzung dieser Arbeit abgestimmte Prozesse modelliert werden können.

100


4.5. Prozessautomatisierung An dieser Stelle soll die Grundproblematik der Prozessautomatisierung dargestellt werden, die im Zusammenhang mit Geschäftsprozessmanagement häufig mit dem Begriff Workflow oder Workflow-Management beschrieben wird. Die Automatisierung selbst kann dabei als eine mögliche Sonderform oder Zielsetzung der Optimierung oder der Neugestaltung von Geschäftsprozessen betrachtet werden.

4.5.1. Workflow-Management und der Workflow-Begriff Die Workflow Management Coalition (WfMC) definiert einen Workflow als „[the] automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules“ [Allen, 2001, S. 15]. Die Automatisierung geschieht mittels eines WorkflowManagement-Systems (WFMS). „[A WFMS is a software system] that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications“ [Allen, 2001, S. 16]. Der Workflow-Begriff hat sich inzwischen weiterentwickelt und ist nicht mehr nur als Weiterreichen von Arbeitsaufgaben zwischen Personen zu verstehen. Workflows werden heute als technische Unterstützung einer prozessorientierten Organisationsstruktur betrachtet [vgl. Müller, 2005, S. 8]. Die Kernaufgabe eines WFMS ist demnach die Unterstützung betrieblicher Prozessabläufe durch die Koordination von • Aktivitäten (Funktionen im Geschäftsprozess), • Anwendungen, • Daten und • prozessbeteiligten Personen [vgl. zur Mühlen und Hansmann, 2005, S. 373]. Eine besondere Bedeutung bekommen hier Workflow-Prozessmodelle: WFMS benutzen explizite Repräsentationen von Prozessstrukturen in Form von Workflow-Prozessmodellen. Der Kontrollfluss wird streng nach den Workflow-Prozessmodellen gesteuert, koordiniert und automatisiert ausgeführt [vgl. Weske, 2007, S. 49]. Das Workflow-Prozessmodell beschreibt möglichst genau und auf operativer Ebene die auszuführenden Arbeitsschritte [Freund, 2004] und beinhaltet die Aktivitäten, Schnittstellen zu Anwendungen, Beschreibung der Daten und die prozessbeteiligten Personen (Rolle). Es findet sich dabei auf den untersten Detaillierungsebenen eines möglichen Unternehmensprozessmodells wieder.

4.5. Prozessautomatisierung

101

Abgedeckt wird die Modellierung von Workflows durch die Modellierungskomponente eines WFMS. Weiterhin besteht ein WFMS aus einer Steuerungskomponente, einer Überwachungskomponente und einer Schnittstellenkomponente. Die Steuerungskomponente dient zur technischen Ablaufsteuerung des Kontrollflusses. Die Überwachungskomponente beinhaltet die informationsorientierte Kennzahlenbildung (bezogen nur auf die WorkflowProzessmodelle) [vgl. Müller, 2005, S. 11 - 12]. Bei der Schnittstellenkomponente steht der Integrationsgedanke im Vordergrund. Hierbei wird unterschieden zwischen der Integration bestehender Anwendungssysteme und der Integration prozessbeteiligter Personen (die sogenannte „human interaction“) in die Prozessautomatisierung [vgl. Weske, 2007, S. 50]. Eine Integration von Anwendungen geschieht am besten dann, wenn auch die informationstechnische Infrastruktur einer Prozessorientierung folgt. Hierzu ist eine Segmentierung funktional orientierter Anwendungssysteme notwendig, in dem eine Trennung der Ablauflogik aus dem System heraus erfolgt, das heißt, Prozesslogik wird aus implementierten Programmabläufen herausgelöst, die IT-Systeme stellen nur noch ihre Funktionen zur Verfügung [vgl. Weske, 2007, S. 50 - 52]. Die Prozesslogik, das heißt der strukturierte Aufruf der Funktionen, erfolgt durch das WFMS, welches die Rolle der Integrationsschicht übernimmt [vgl. zur Mühlen und Hansmann, 2005, S. 375]. Mit Hilfe von „human interaction“ werden teilautomatisierte Prozesse durch die aktive Kontrolle von Funktionen unterstützt, die von Personen ausgeführt werden. Ziel ist es, eine effektive Unterstützung der automatisierten Prozessabschnitte zu erreichen, indem die menschlichen Arbeitsschritte exakt nach dem Workflow-Prozessmodell integriert werden. Hierzu muss ein WFMS um besondere Benutzerschnittstellen erweitert werden, die die anstehenden Aufgaben auflisten und je nach Prozessschritt die notwendigen Daten, Informationen und Anwendungen zur Verfügung stellen [vgl. Weske, 2007, S. 53]. Abbildung 45 zeigt für beide Integrationsaspekte ein Beispiel. Im Mittelpunkt steht jeweils ein Workflow-Prozessmodell, das mit Hilfe von BPMN dargestellt wird. Im oberen Beispiel ist dieses Prozessmodell vollautomatisiert. Die Aktivitäten bestehen aus Funktionsaufrufen der Anwendungssysteme mit Hilfe der Integrationsschicht des WFMS. Das untere Beispiel erweitert dies um „human interaction“. Die Aktivitäten „Check Inventory“, „Prepare Invoice“, „Handle Shipment“ und „Archive“ sind Funktionen, die durch eine Person ausgeführt werden. An dieser Stelle wird der Workflow unterbrochen und der prozessbeteiligten Person eine Aufgabe über die Benutzerschnittstelle zugeteilt. Die jeweiligen Anwendungssystemfunktionen und die teilweise notwendige „Office Application“ werden ebenfalls zur Verfügung gestellt, wie im Workflow-Prozessmodell definiert. Der Nutzen von Prozessautomatisierung liegt in der Reduzierung von Transport- und Liegezeiten, sowie in einer möglichen Priorisierung von Vorgängen und der sofortigen Auskunftsfähigkeit. Dem gegenüber steht ein hoher Implementierungsaufwand [vgl. zur Mühlen und Hansmann, 2005, S. 379]. Geschäftsprozesscontrolling ist daher eine notwendige Voraussetzung zur erfolgreichen Prozessautomatisierung, da das Controlling rentable

102


Abbildung 45: Workflow-Beispiele zur Integration [aus Weske, 2007, S. 52, 54] Geschäftsprozesse hierfür ermitteln kann und im Rahmen der Optimierung Geschäftsprozesse entsprechend auf die Automatisierung angepasst werden können. Der ControllingRegelkreis selbst kann ebenfalls von WFMS profitieren, sofern der Regelkreis von der Modellierung bis zur Performanzmessung und Ausführung integriert ist. Eine Änderung an Workflow-Prozessmodellen lässt sich unmittelbar durch das WFMS umsetzen und die Ergebnisse messen. 4.5.2. Workflow-Management im Kontext von Geschäftsprozessmanagement In den vorangegangenen Abschnitten dieses Kapitels wurde das Geschäftsprozessmanagement als integriertes Managementkonzept dargestellt, das komplett auf den Ideen der Pro-

4.5. Prozessautomatisierung

103

zessorientierung und Prozessorganisation beruht. Dafür wurde ein durchgängiges und abgestimmtes Unternehmensprozessmodell entwickelt, welches top-down die Geschäftsprozesse im Unternehmen abbildet. Für die Geschäftsprozesse wurde eine ausführliche Definition abgeleitet. Dem gegenüber steht die Auffassung von [Lehmann, 2008], nach der ein Workflow als eine spezielle Prozessart auf niedriger Aggregationsstufe anzusehen ist und wofür es besondere Anforderungen an Strukturierung und Dokumentation (Modellierung) gibt [vgl. Lehmann, 2008, S. 14 - 15]. Gestützt wird diese Auffassung beispielsweise durch [Müller, 2005]. Darin werden verschiedene Prozesstypen unterschieden und auf ihre Eignung zur Ausführung in WFMS hin untersucht. Lediglich Routineaufgaben und sachbezogene Aufgaben in Routineprozessen sind demnach geeignet [vgl. Müller, 2005, S. 8 - 10]. Dies deckt aber nur einen Teil der Geschäftsprozesse ab. Werden die Anforderungen der Workflow-Modellierung nicht Teil der Geschäftsprozessmodellierung (beispielsweise Anforderungen nicht Teil des Konventionshandbuchs und die Workflow-Modelle nicht Teil des Unternehmensprozessmodells) oder wird WorkflowManagement ganz ohne Geschäftsprozessmanagement betrieben, besteht die Gefahr, dass die Ziele der Prozessorientierung dadurch nicht erreicht werden (vergleiche beispielsweise die Strategiediskussion in [Schmelzer und Sesselmann, 2008]). Im äußersten Fall wäre ein WFMS nur ein weiteres Anwendungssystem, das zur Unterstützung von Geschäftsprozessen eingesetzt wird. Die Prozessautomatisierung wird erst dann zur Geschäftsprozessautomatisierung, wenn sie Geschäftsprozesse nach der hier eingeführten Definition automatisiert und Teil des integrierten Managementkonzepts wird. Hierfür gibt es noch keine ausreichende wissenschaftliche Abdeckung (vgl. bspw. [Ortner, 2008] und [Overhage und Turowski, 2007, S. 4]) und muss deshalb noch weiter ausgearbeitet werden, wie beispielsweise hier für die spezielle Domäne Contact-Center. Einen vielversprechenden Ansatz hierzu bietet die serviceorientierte Architektur, die im Anschluss an dieses Kapitel vorgestellt und diskutiert wird.

Fazit Die Ausrichtung des Referenzmodells ist bereits durch den strategischen Einflussfaktor der Industrialisierung auf eine Automatisierung ausgelegt. Dabei muss versucht werden, die prozessorientierte Organisationsstruktur zu unterstützen, das heißt, das Referenzmodell muss Funktionen, Anwendungen, Daten, Personen und Wissensaspekte koordinieren. Es muss außerdem ein Zusammenhang zwischen Workflow-Prozessmodellen und fachlichen Prozessmodellen (ARIS) hergestellt werden, unter anderem, um eine gemeinsame Sprache der beteiligten Abteilungen zu ermöglichen. Die Steuerungs-, Überwachungs-, Schnittstellen- und Integrationsproblematik wird mit Hilfe der Service- und Ereignisorientierung umgesetzt, weshalb diese Themen noch vorgestellt werden. Unabhängig davon muss das Referenzmodell die Frage klären, wie bestehende WFMS, und deren Paradigma

104


an sich, in ein innovatives Referenzmodell passen und wie mit besonderen Anforderungen von Contact-Centern (Multikanal-Management, Routing, hoher manueller Arbeitsanteil) umgegangen wird. Insbesondere muss das Referenzmodell die Granularitätsfrage (Detaillierungstiefe) von Workflows klären sowie die Frage, inwieweit sie von fachlichen Prozessmodellen abweichen. Die Forderung nach der Automatisierung von tatsächlichen Geschäftsprozessen muss das Referenzmodell abdecken.

105

5. Serviceorientierung Serviceorientierung und serviceorientierte Architekturen (SOA) sind ein nach wie vor stark diskutiertes Thema mit Praxisrelevanz, unter anderem auf Grund der sich etablierenden Web-Service-Standards, der effizienten Möglichkeiten ihrer Realisierung und nicht zuletzt wegen der nach wie vor zunehmenden Bedeutung des Internets. In diesem Kapitel sollen hierzu zuerst Serviceorientierung und SOA als Begriffe eingeführt werden und anschließend die Implementierung mittels Web-Services dargestellt werden. Das Kapitel schließt mit einer Einführung in die Prozessautomatisierung mittels SOA und dessen Standards.

5.1. Serviceorientierung und serviceorientierte Architekturen SOA erfährt sehr unterschiedlich motivierte Definitionen. Dieser Abschnitt soll einen Überblick über diese geben und die grundlegenden Bestandteile herausarbeiten.

5.1.1. Definition Ein Großteil der Definitionen von SOA sind technisch orientiert und beziehen sich auf IT-Systeme im Unternehmen. Hierzu ist es sinnvoll, zunächst die verschiedenen Systembegriffe Anwendungssystem, Informationssystem und Organisationssystem abzugrenzen. Unter einem Informationssystem versteht man in der Wirtschaftsinformatik ein System zur Informationsverarbeitung. Hierzu gehören die Erfassung, Übertragung, Transformation, Speicherung und Bereitstellung von relevanten Informationen. Informationssysteme verarbeiten Informationen als Objektart47 in einem Unternehmen. Sie dienen der Unterstützung und Lenkung von Geschäftsprozessen. Dem gegenüber stehen Anwendungssysteme, die auf einzelne Aufgabengebiete im Unternehmen zugeschnittene Hard- und Softwaresysteme sind und somit ein Teilgebiet eines Informationssystems darstellen [vgl. Ferstl und Sinz, 2008, S. 1 - 10]. Bezogen auf Kommunikationskanäle decken Anwendungssysteme die Kommunikation zwischen Rechnern ab und stellen Benutzerschnittstellen zur Verfügung. Informationssysteme hingegen binden den Menschen in die Informationsverarbeitung, die Kommunikation und den Informationsaustausch mit ein [vgl. vom Brocke, 2008, S. 11]. Die Organisationsebene erweitert diese Betrachtung um die Aufgaben im Unternehmen im Sinne der Aufbau- und Ablauforganisation und ordnet diese dem Organisationssystem zu (vgl. hierzu auch Abschnitte 2.3.3, 2.3.4 und 4.1.3). Die einzelnen Systembegriffe stellt Abbildung 46 in einem Schalenmodell dar. 47

Eine weit eingeschränktere Definition würde die Betrachtung der Information im Sinne von „informieren“ ergeben, die hier jedoch nicht angewendet wird.


106

5. Serviceorientierung

Abbildung 46: Differenzierung der Systembegriffe [aus vom Brocke, 2008, S. 12] Bezogen auf den Kommunikationsaspekt dieser Einteilung ist folgende Entwicklung relevant, die mit der Entwicklung des Internet einhergeht. Lässt man die Mensch-zu-MenschKommunikation (E-Mail, Chat, Blogging) außen vor, so kann man eine Zunahme der automatisierten Kommunikation zwischen Applikationen und Rechnern, die im Internet vernetzt sind, feststellen. Die Mensch-Maschine-Kommunikation geht zusehends über in eine synchrone Unterhaltung, die lediglich vom Menschen initiiert wird, in dem beispielsweise über den Browser im Internet eine Dienstleistung in Anspruch genommen oder ein Produkt gekauft wird. Der weitaus größere Teil der Kommunikation, der darauf hin folgt, findet zwischen Anwendungssystemen statt und geschieht weitgehend automatisiert und maschinell [vgl. Melzer, 2007, S. 8 - 10]. Serviceorientierte Architekturen setzen an dieser Kommunikation der Anwendungssysteme an. Mit Hilfe von SOA werden Anwendungssysteme so aus Teilsystemen zusammengestellt, dass sie eine spezifische Dienstleistung zur Verfügung stellen. Ein Teilsystem wird dabei als Service oder Dienst bezeichnet. Je nach benötigter Funktionalität für eine Aufgabe werden Dienste situativ zusammengestellt, auch von anderen Anwendungssystemen. Dies kann dynamisch auch erst zur Laufzeit geschehen [vgl. Leymann, 2003, S. 20]. Definiert man SOA mit Bezug auf seine Merkmale, so versteht man darunter „[...] eine Systemarchitektur, die vielfältige, verschiedene und eventuell inkompatible Methoden oder Applikationen als wiederverwendbare und offen zugreifbare Dienste repräsentiert und dadurch eine plattform- und sprachenunabhängige Nutzung und Wiederverwendung ermöglicht“ [Melzer, 2007, S. 11]. Der Zugriff auf Dienste erfolgt nach dem „Find-BindExecute“-Prinzip: Dienste werden mittels eines Katalogs veröffentlicht und können darin gefunden werden. Ein passender Service wird auf Grund der bereitgestellten Schnittstellendefinition eingebunden und ausgeführt [vgl. Overhage und Turowski, 2007, S. 4]. OASIS versteht unter SOA ein Paradigma zur Organisation und Nutzung verteilter Kapazitäten

5.1. Serviceorientierung und serviceorientierte Architekturen

107

[vgl. MacKenzie et al., 2006, S. 8]. Die Bereitstellung der hierfür notwendigen Softwarearchitektur in seiner Gesamtheit wird als SOA bezeichnet [vgl. Weske, 2007, S. 58]. Die wesentlichen Eigenschaften einer SOA lassen sich in sogenannten Architektur- beziehungsweise Desginprinzipien zusammenfassen. Diese sind als „Eigenschaften einer umfassenden Umsetzung des SOA-Architekturstils“ [Heutschi, 2007, S. 53] zu verstehen. Die folgende Zusammenstellung der SOA-Architekturprinzipien basiert auf einer ausführlichen Untersuchung durch [Heutschi, 2007, S. 36 ff.]: • Abstraktion von der Serviceimplementierung: Die Dienstleistung eines Services wird von dessen Implementierung abstrahiert, es gilt das sogenannte Geheimnisprinzip („information hiding“). • Umfassende, einheitliche Servicespezifikation: Architekturweite, einheitliche und verbindliche Beschreibung von Services, sowohl bezogen auf die Schnittstellenebene als auch auf die Verhaltens- und Informationsebene. • Stabile, gemanagte Servicekontrakte: Verbindliche (vertragsähnliche) Vereinbarungen sollen möglichst stabile Serviceschnittstellen garantieren, die möglichst wenig geändert werden. • Technische Schnittstellenstandardisierung: Standardisierung vor allem der technischen Servicespezifikation und des Nachrichtenaustauschs (beispielsweise durch WebService-Standards, wie in Abschnitt 5.2 beschrieben). • Fachliche Schnittstellenstandardisierung: Fachliche Servicebeschreibung (nach Inhalt, Struktur und Terminologie), einheitliche serviceübergreifende Informationsobjekte sowie übergreifende Funktions- und Prozessmodelle. Ein entsprechender Ansatz wird in Abschnitt 8.5 als Teil des Referenzmodells vorgestellt. • Verwendung offener und verbreiteter Industriestandards: Für die verschiedenen Standardisierungen sind entsprechend offene und verbreitete Industriestandards zu verwenden. • Hohe Servicekohäsion und schwache logische Kopplung: Im Innenverhältnis werden alle notwendigen Daten und Funktionen gebündelt. Im Außenverhältnis sind Services unabhängig voneinander, das heißt, sie zeigen nicht gleiches Änderungsverhalten auf Grund Änderungen der fachlichen Anforderungen. • Lose gekoppelte Kommunikation: Die Verbindung zwischen den Diensten ist von minimaler Abhängigkeit geprägt und kann durch dynamische Adressierung oder nachrichtenbasierte Kommunikation erreicht werden. Lediglich die Schnittstelle eines Dienstes ist nach außen bekannt, die Einrichtung des Dienstes (dessen Implementierung) ist davon unabhängig und gegebenenfalls austauschbar [vgl. hierzu auch Böhmann und Krcmar, 2006, S. 382].

108


• An Geschäftskonzepten orientierte, grobe Servicegranularität: Der Umfang, wie viel Fachlogik ein Service umfasst (Funktionsgranularität) beziehungsweise wie umfangreich das Datenmodell der Serviceschnittstelle ist, richtet sich nach fachlichen Gesichtspunkten (Geschäftsprozesse). • Generalisierung der Serviceleistung: Services sollen wiederverwendbar und auch in anderen Unternehmenskontexten einsetzbar sein. Die Inhalte der Architekturprinzipien werden in den folgenden Abschnitten noch genauer erläutert. Jedoch kann ihnen abhängig von Anwendungskontext und Zielsetzung unterschiedliche Bedeutung zukommen. Sie müssen daher projekt- und unternehmensspezifisch gewichtet und priorisiert werden. Im Referenzmodell werden diese Architekturprinzipien wieder aufgegriffen und gegen übergreifende Contact-Center-Ziele priorisiert. SOA ist eine Systemarchitektur, die bestehende Anwendungssysteme und -architekturen nicht ersetzt sondern integriert [vgl. Leymann, 2003, S. 1 - 2], [Woods und Mattern, 2006, S. 104]. Dies ist notwendig zum Investitionsschutz und auf Grund der Komplexität gewachsener Infrastrukturen in Unternehmen mit teilweise über hundert verschiedenen (aber notwendigen) Anwendungssystemen [vgl. Kossmann und Leymann, 2004, S. 117]. Mit SOA können neue Dienste veröffentlicht werden, aber auch sogenannte WrapperServices, die Funktionalitäten aus den bestehenden Anwendungssystemen als Dienst in einer SOA bereitstellen. Die Implementierung liegt im Altsystem, der Aufruf erfolgt über den Dienst. Komplexe Anwendungssysteme können so auf Altsystemen aufgebaut werden und die bestehende Komplexität auf Grund der Heterogenität kann zurückgebaut werden [vgl. Keller, 2002, S. 123], [Erl, 2005, S. 45 - 46]. Ähnliche Arbeiten und die Ideen zu SOA gehen auf die 70er-Jahre zurück [vgl. Weikum und Vossen, 2002, S. 20 - 21]. Beispiele für zwischenzeitliche Realisierungskonzepte sind das „Component Object Model (COM)“ von Microsoft [vgl. Microsoft, 2009c] sowie die „Common Object Request Broker Architecture (CORBA)“ der OMG [vgl. OMG, 2008b]. Einen Überblick hierüber gibt [Zwintzscher, 2004]. Inwieweit sich SOA von diesen und anderen Ansätzen, wie etwa Modularisierung, Objekt- oder Komponentenorientierung, unterscheidet, diskutieren beispielsweise [Erl, 2005, S. 88 - 107], [Woods und Mattern, 2006, S. 142 ff.] und [vom Brocke, 2008, S. 35 - 37]. Dabei wird festgehalten, dass in gewisser Weise alle Ansätze auf eine Flexibilisierung von Anwendungssystemen abzielen, wobei etwaige Schwerpunkte gesetzt werden. Im Vergleich zu komponentenorientierten Ansätzen wird bei SOA nicht nur die Wiederverwendung zur Build-Time angestrebt, sondern auch während der Ausführung. Dienste werden hier dynamisch eingebunden. Ein weiterer Punkt sind offene SOA-Standards für den Diensteaustausch. Dienste werden dadurch zu „virtuellen Komponenten“, die sowohl unabhängig von der Implementierung als auch unabhängig von der Institutionalisierung sind, das heißt unabhängig von Speicherort und Dienstanbieter. Durch eine standardisierte Beschreibungssprache lassen sich bei SOA auch nicht modulare und nicht objekt- oder komponentenorientierte Teilsysteme einer Altanwendung als Dienste veröffentlichen.


109

In obigen Ausführungen wird SOA sowohl aus wissenschaftlicher als auch aus praktischer Perspektive technologiegetrieben diskutiert. SOA als Softwarearchitektur an sich ist ein technisches Thema. Insgesamt beschränkt es sich jedoch nicht nur auf technische Aspekte. SOA hat eine Beziehung zur Fachlichkeit, das heißt zu den Geschäftsprozessen, die eine wichtige Rolle spielen [vgl. bspw. Leymann et al., 2002], [Margaria und Steffen, 2006]. Diese Beziehung ist gegeben durch den Zusammenhang von Anwendungssystem – Informationssystem – Organisationssystem (IT als Enabler der Geschäftsprozesse) und der stärker werdenden Ausrichtung der IT-Infrastruktur an Geschäftsprozessen [vgl. Overhage und Turowski, 2007, S. 4]. „[Der] Erfolg von SOA hängt davon ab, ob es gelingt, IT-Funktionen für betriebswirtschaftliche Aufgaben und Prozessschritte in Services zu kapseln“ [Beuthner, 2007]. Das Potential hierzu, das heißt die Nutzung von Geschäftsprozessen als Grundlage für eine systemübergreifende Integration mit Hilfe von SOA, wird derzeit noch unzureichend genutzt [vgl. OrViA, 2009], [Dörner et al., 2008]. Ziel einer prozessorientierten Gestaltung von SOA ist es, Restriktionen von Anwendungssystemen aufzuheben, indem eine Trennung zwischen der Ablauflogik (eigentlich beschrieben in Geschäftsprozessen) und der Ablaufsteuerung (programmiert in Anwendungssystemen) erreicht wird [vgl. Allweyer, 2005, S. 345], [Leymann, 2003, S. 13]. Implementierte Prozessabläufe werden aus Anwendungssystemen herausgelöst und dafür Dienste aus den Anwendungssystemen definiert. Funktionalitäten von Geschäftsprozessen werden so von Diensten abgebildet. Es entsteht eine Art „Baukasten“ von internen und externen Unternehmensfunktionen (als Dienste), die in Prozessen zusammengefügt („orchestriert“) werden [vgl. Buxmann et al., 2008, S. 143]. Dies entspricht einer „Programmierung im Großen“ gemäß der Trennung nach den zwei Programmierebenen nach [DeRemer und Kron, 1976]. Bei der Einführung von Anwendungssystemen sollen keine organisatorischen Anpassungen und Geschäftsprozessänderungen [vgl. Becker und Kahn, 2005, S. 12] oder umfangreiche Konfigurationen von ERP-Systemen [vgl. van der Aalst et al., 2005] mehr notwendig werden. Ausgangspunkt einer Gestaltung von SOA bildet die unternehmensindividuelle Entscheidungssituation, nicht die Funktionen eines Anwendungssystems. Mit Hilfe von SOA wird eine Anpassung von Anwendungssystemen an die Informations- und Organisationsgestaltung erwartet [vgl. vom Brocke, 2008, S. 14, 55 - 56]. Analysten rechnen mit einer kurz- bis mittelfristigen Etablierung von SOA als Paradigma im Geschäftsumfeld, Web-Service-Standards gelten bereits als etabliert [vgl. Phifer et al., 2007, S. 6 - 7].

5.1.2. Bestandteile Unabhängig von einer eher technischen oder prozessorientierten Betrachtungsweise besteht eine serviceorientierte Architektur aus wenigen Grundbestandteilen, wie Abbildung 47 zeigt.

110


Abbildung 47: Grundbestandteile einer SOA [nach Krafzig et al., 2005, S. 57] Service Die Begriffe Service und Dienst werden synonym verwendet, sie bilden die Grundlage einer serviceorientierten Architektur. Ein Dienst bildet eine konkrete Fachlichkeit ab im Kontext zu unterstützender Geschäftsprozesse [vgl. Krallmann et al., 2007, S. 13]. Bezogen auf ein Anwendungssystem ist „[ein] Dienst eine Aktion eines (betrieblichen) Anwendungssystems, welches die Bewältigung einer bestimmten Menge von (betrieblichen) Aufgaben unterstützt“ [Overhage und Turowski, 2007, S. 5]. Ein Dienst besteht aus den Elementen Servicevertrag („Contract“), Implementierung („Implementation“) und Schnittstelle („Interface“) [vgl. Krafzig et al., 2005, S. 57 ff.]. Der Servicevertrag beschreibt die notwendigen Rahmenbedingungen eines Dienstes. Er gibt Auskunft über die zu verwendenden Schnittstellen und den Verwendungszweck des Dienstes und stellt eine Servicebeschreibung in maschinenlesbarer Form zur Verfügung [vgl. Melzer, 2007, S. 12]. Auch nicht-funktionale Anforderungen, wie die zu erwartende Dienstgüte (Antwortzeiten, Verfügbarkeiten, Kosten), werden darin geregelt. Meist geschieht dies in zusätzlichen vertraglichen Vereinbarungen zu diesen Anforderungen, den sogenannten „Service Level Agreements (SLA)“. Ebenfalls Teil des Servicevertrags können eventuelle Voraussetzungen für den ordnungsgemäßen Einsatz sein [vgl. Buxmann et al., 2008, S. 146]. Die Implementierung eines Dienstes besteht zum einen aus der vom Verwendungszweck abhängigen Geschäftslogik und den benötigten Daten. Diese sind meist getrennt, Daten werden in Datenbanken gespeichert wie in anderen Anwendungssystemen auch [vgl. Buxmann et al., 2008, S. 147]. Die Art und Technologie der Implementierung ist nur für den Dienstanbieter relevant. Für den Dienstnachfrager ist dies irrelevant, da der Zugriff nur auf


111

die Schnittstelle erfolgt, die dahinter liegende Implementierung kann ausgetauscht werden, solange sie den Verwendungszweck und die Servicevereinbarung erfüllt [vgl. Melzer, 2007, S. 12 - 13]. Der Zugriff auf einen Dienst erfolgt immer und ausschließlich über die Schnittstelle. Die Schnittstellenbeschreibung ist ebenfalls maschinenlesbar beschrieben und Teil der Servicevereinbarung. Ein Dienst kann über mehrere Schnittstellen (Technologien, Protokolle) erreichbar sein. Im Zusammenhang mit der Definition von Diensten bestehen derzeit noch Herausforderungen bezüglich der richtigen Festlegung von Funktion, Größe und Schnittstellen [vgl. Beuthner, 2007]. Hier stellt sich besonders die Frage nach der notwendigen Granularität eines Dienstes, das heißt nach dessen Funktionsumfang beziehungsweise der Breite des angebotenen Verwendungszwecks [vgl. Buxmann et al., 2008, S. 145]. Wird ein Dienst zu feingranular definiert, so erhöht sich in einer SOA die Anzahl der Schnittstellen und somit die Komplexität. Ein Dienst ist zu feingranular, wenn er nur einen sehr kleinen Aspekt einer Dienstleistung abdeckt. Die Grobgranularität eines Dienstes wiederum hat negative Auswirkungen auf seine Wiederverwendbarkeit, da der abgedeckte Verwendungszweck zu spezifisch ist und nicht, oder nur bedingt, im Kontext der vorhandenen Geschäftsprozesse wiederverwendet werden kann [vgl. Erl, 2005, S. 556 - 557]. Die Granularitätsfrage ist bisweilen noch ungeklärt, hierzu gibt es keine konkreten Aussagen. Die Servicegranularität in einer technisch orientierten SOA liegt niedriger (eine sehr feine Forme währe analog Klassen und Funktionen in einer Programmiersprache) als mit einem betriebswirtschaftlichen Fokus. In Letzterem scheint eine Dekomposition soweit sinnvoll, solange sich trotz des technischen Fortschritts in der Anwendungssystemtechnik keine Auswirkungen auf den Service ergeben [vgl. Böhmann und Krcmar, 2006, S. 381 - 383]. Nach wie vor muss die Frage der Granularität jedoch unternehmens- oder zumindest domänenspezifisch geklärt werden. Service-Repository Zu den wesentlichen Rollen in einer SOA gehören der Anbieter, der Nutzer beziehungsweise Nachfrager und der Vermittler von Diensten mit den zugehörigen Aktionen, wie sie die nachfolgende Abbildung 48 darstellt. Das „Service Repository“ stellt einen Verzeichnisdienst für Services dar und ist Vermittler zwischen Anbieter und Nachfrager von Diensten. Zum Funktionsumfang eines Verzeichnisdienstes gehören mindestens das Registrieren von Diensten sowie deren Suchen und Finden. Dabei werden immer die notwendigen Informationen der Servicevereinbarung und der Schnittstellen mit veröffentlicht. Es gibt sowohl projekt- und unternehmensinterne Verzeichnisdienste als auch unternehmensübergreifende oder globale Verzeichnisdienste [vgl. Buxmann et al., 2008, S. 147], [Melzer, 2007, S. 12 ff.]. Service-Bus Als einen „Service Bus“ beziehungsweise einen „Enterprise Service Bus (ESB)“ bezeichnet man die logisch zentrale Integrationskomponente einer SOA, die zur

112


Abbildung 48: Rollen und Aktionen in einer SOA [nach Melzer, 2007, S. 12] Bereitstellung und Einbindung von Diensten notwendig ist [vgl. Melzer, 2007, S. 23], [Leymann, 2003, S. 7]. Hierzu zählen Funktionalitäten, die als zentrale Komponenten zur Integration von Anwendungssystemen unter dem Begriff „Enterprise Application Integration (EAI)“ diskutiert werden und Softwareschnittstellen in Anwendungssystemen und für diese zur Verfügung stellen [vgl. hierzu Keller, 2002], [Chappell, 2006]. Neben der technischen Integration gibt es noch weitere Aspekte eines ESB, wie die Aufteilung in Abbildung 49 zeigt.

Abbildung 49: Integrationsaspekte eines ESB [nach Chappell, 2006, S. 12] Eine trennscharfe Definition für ESB scheint im Moment noch nicht gegeben [vgl. Melzer, 2007, S. 20], allerdings lassen sich verschiedene Eigenschaften herausarbeiten: • Transformationsfunktion: Es ist Aufgabe des ESB, einen virtuellen Kanal zwischen zwei Diensten beziehungsweise zwischen einem Anbieter und dem Nachfrager zu schaffen. Hierzu ist es notwendig, eine Unterhaltung der betroffenen Partner mittels Transformationen zu ermöglichen. Eine Transformation zwischen Daten oder Datentypen ist notwendig, sofern die Ausgangsparameter eines Dienstes die Eingangsparameter eines anderen bilden und diese nicht kompatibel sind [vgl. Melzer, 2007, S. 20 - 21].


113

• Standardbasierte Integration: Die Integration, wie mit EAI bereits angeführt, soll auf offenen Standards basieren [vgl. Chappell, 2006, S. 8] • Transportfunktion: Der Transport von Informationen und Daten soll unabhängig von technischen Protokollen erfolgen. Der Nachrichtenaustausch muss dabei verlässlich sein und die Kommunikation soll sowohl synchron als auch asynchron möglich sein [vgl. Woods und Mattern, 2006, S. 138 - 139]. • Intelligente Verteilung: Ein ESB als zentrale Komponente soll über intelligente Verteilungsmechanismen verfügen, um eine optimierte Verteilung von Nachrichten und Daten zu ermöglichen [vgl. Melzer, 2007, S. 19]. • Einfachheit: Die vorhandene Komplexität der verwendeten Technologien soll durch einen ESB verdeckt werden (dies gilt vor allem für die zugehörigen Clientanwendungen, meist in Form von Entwicklungsumgebungen für ESB). Durch Abstraktion sollen nur die für jeweils eine Schicht notwendigen Daten und Informationen zur Verfügung gestellt werden [vgl. Melzer, 2007, S. 23]. • Verteiltheit: Die Funktionalitäten eines ESB stehen in einer verteilten Umgebung zur Verfügung, analog der Verfügbarkeit der Dienste und der geografischen Ausbreitung der zugehörigen SOA (Sichtbarkeit analog Service-Repository von projektintern bis global möglich) [vgl. Chappell, 2006, S. 9 - 10]. • Interaktion: Ein ESB muss die Interaktion zwischen Diensten ermöglichen. Dies geschieht zum einen auf Integrationsebene (beispielsweise durch Kombination mehrerer Dienste zu einem neuen Dienst), zum anderen aber auch auf betriebswirtschaftlicher Ebene in Bezug auf eine prozessorientierte Orchestrierung von Diensten [vgl. Scheer et al., 2005, S. 11], [Woods und Mattern, 2006, S. 139]. Auf die Prozessorchestrierung wird speziell im Abschnitt 5.3 eingegangen.

Application Frontend Als „Application Frontend“ wird eine eigene grafische Benutzerschnittstelle innerhalb einer SOA bezeichnet. Bestehende Anwendungssysteme und Altanwendungen stellen ihre Funktionalitäten in Services gekapselt zur Verfügung und deren Benutzerschnittstellen sind somit nicht mehr gültig. Die mit Hilfe von Diensten in einer SOA neu zusammengestellten Anwendungssysteme nutzen ein gemeinsames „Application Frontend“. Dieses initiiert Prozesse und dient zur Interaktion und Kontrolle der Prozesse und Dienste durch die Benutzer. Häufig werden sie als Webanwendung im Intranet eines Unternehmens implementiert [vgl. Buxmann et al., 2008, S. 146].

5.1.3. Aktueller Diskussionsstand Für eine praktische Anwendung einer SOA sind die Bestandteile Service, Service-Bus und Serviceverzeichnis ausreichend [vgl. Vollmer und Gilpin, 2006] und vor diesem Hintergrund

114


wurden sie hier verwendet. Darüber hinaus gibt es komplexere Aspekte einer SOA, die noch erwähnt werden sollen. An erster Stelle ist die Semantik von Diensten und die damit zusammenhängende Automatisierung der Kommunikation zu nennen. Analog dem semantischen Web, in dem es um die automatische Verwertbarkeit der Bedeutung von Informationen für Computer geht [vgl. Berners-Lee et al., 2001], ist eine Bedeutungsunterscheidung von Diensten entscheidend. Im Zusammenhang mit SOA besteht hier die Herausforderung, Semantik von Diensten so eindeutig zu formulieren, dass eine unmissverständliche globale Zuordnung von Symbol zu Konzept, das heißt von Dienst zu seiner Bedeutung, möglich wird [vgl. Melzer, 2007, S. 318]. Ziel ist es, für einen bestimmten Kontext zum gegebenen Zeitpunkt den passenden Dienst automatisch zu finden. An einem Beispiel verdeutlicht könnte dies heißen, dass an einer bestimmten Stelle in einem Geschäftsprozess die Prüfung der Kreditwürdigkeit vorgesehen ist. Statt einer festen Einbindung eines Dienstes könnte hier nur das Konzept beschrieben sein und ein passender Dienst wird zur Laufzeit gesucht. Hierzu wurden für das semantische Web durch das W3C drei aufeinander aufbauende Sprachen entwickelt: das „Resource Definition Framework (RDF)“ [vgl. W3C, 2004a], das RDF-Schema (RDFS) [vgl. W3C, 2004b] und die „Web Ontology Language (OWL)“ [vgl. Bechhofer et al., 2004]. Einen weiterführenden Einblick in das semantische Web geben beispielsweise [Hitzler et al., 2007], zu Semantik von Diensten in SOA, vergleiche [Melzer, 2007, S. 315 ff.]. Eine komplette Automatisierung allerdings – wie im Beispiel oben beschrieben – wird derzeit als noch nicht realisierbar angesehen [vgl. Melzer, 2007, S. 328]. Den Ergebnissen und Standards von SOA im Bereich Geschäftsprozessmanagement widmet sich der Abschnitt 5.3. Der Gesamtzusammenhang von Ereignissen und SOA im Bereich von Real-Time-Unternehmen und „event driven SOA“, beispielsweise ereignisgetriebene Erweiterungen von ESB, wird im Anschluss im Kapitel 6 behandelt. Unabhängig davon gibt es noch allgemein ungeklärte Entwicklungsfragen bezogen auf SOA. SOA-Systemen, wie sie derzeit in der Praxis angeboten werden, wird teilweise ein fehlender wissenschaftlicher Ansatz vorgeworfen [vgl. Ortner, 2008]. Insbesondere die standardisierten und fachlichen methodischen Grundlagen fehlen nach Ansicht von [Aier und Schönherr, 2004] für einen nachhaltigen Einsatz von SOA, sowie eine „organisationstheoretische und strategische Fundierung“ [Krallmann et al., 2007, S. 13]. [Overhage und Turowski, 2007, S. 4] fordern hier zumindest eine methodische Unterstützung zur besseren Operationalisierung in der Praxis auf der Grundlage einer „Konstruktionslehre für angestrebte ingenieurmäßige Entwicklung von Services“. In diesem Zusammenhang müssen vor allem noch teilweise offene Entwicklungsfragen geklärt werden, wie die sinnvolle Dekomposition eines Altsystems in Dienste, die Identifikation neuer, eigenständiger Dienste oder die Ermittlung und Vorhersage der Kompatibilität oder Heterogenität einzelner Dienste im Vorfeld der Orchestrierung [vgl. Overhage und Turowski, 2007, S. 3 - 4], [Erl, 2005, S. 36].

5.2. Umsetzung von serviceorientierten Architekturen mit Web-Services

115

Fazit Zunächst wird (hypothesenartig) die sinnvolle Nutzung der SOA für das Referenzmodell angenommen, unter anderem wegen der Integrationsmöglichkeiten und dem Maß der Ausgereiftheit, die SOA in Literatur und Praxis inzwischen erreicht hat. Die Gestaltung und Anpassung der SOA wird zur Aufgabe des Referenzmodells (im übertragenen Sinn der Hypothesenbeweis durch Modellbildung). Dazu ist die Abgrenzung der Systembegriffe wichtig, um den Fokus des Referenzmodells besser zu verstehen: Es werden keine Anwendungssysteme im engeren Sinne gebaut sondern die Bildung neuer Anwendungssysteme (als Services) wird durch die Gestaltung der Serviceorientierung für Contact-Center ermöglicht. Die Beziehung zur Fachlichkeit, das heißt die Abbildung betriebswirtschaftlicher Aufgaben und Prozesse in Services, wird zur Aufgabe des Referenzmodells. Es muss die notwendigen Technologien und deren Möglichkeiten sinnvoll kombinieren und mit dem Standardprozessmodell abstimmen, um zukünftigen Anwendern die Möglichkeit zu geben, die Contact-Center-Funktionen (Geschäftsprozesse) mit Hilfe des Modells automatisiert zur Verfügung zu stellen. Die Gesamtheit des Referenzmodells versucht ein Informationssystem zu erschaffen, in dem die Aspekte der beteiligten Menschen mit aufgenommen werden. Es gliedert sich in ein Organisationssystem ein. Dies ist bereits vorgegeben durch die Prozessorganisation, wodurch die Prozessorientierung die impliziten Richtlinien vorgibt, wie die SOA zu gestalten ist. Eine explizite und wichtige Gestaltungsrolle nehmen die vorgestellten Architekturprinzipien im Referenzmodell ein. Sie bestimmen die Ausgestaltung der Komponenten wesentlich mit, darin sind ausdrücklich die ereignisorientierten Komponenten mit eingeschlossen. Die vorgestellten Bestandteile werden (angepasst) zu Bestandteilen der SOA-Architektur eines Contact-Centers. Zentral dabei werden das Application-Frontend (es muss in Beziehung gebracht werden zum Agent-Desktop) und die Servicegestaltung. Hier wird für das Referenzmodell die Granularitätsfrage der Detailtiefe von Workflows konkretisiert auf die Fragen der Granularität und der Gestaltung von Services.

5.2. Umsetzung von serviceorientierten Architekturen mit Web-Services SOA ist ein Architekturkonzept, das eine Realisierung mit einer konkreten technologischen Ausprägung benötigt. Hierzu haben sich Web-Services durchgesetzt. Sie sind die derzeit am häufigsten angewandte Technologie zur Implementierung von SOA [vgl. Krallmann et al., 2007, S. 15] und haben in der Praxis bereits eine sehr hohe Produktivität erreicht [Phifer et al., 2007, S. 6]. Zu den Basiselementen gehören die Spezifikationen „Web Service Description Language (WSDL)“, „Simple Object Access Protocol (SOAP)“ sowie „Universal Description, Discovery and Integration (UDDI)“. Ihnen allen ist der Begriff des Web-Service gemein, der einen konkreten Ausprägungstyp eines Dienstes bezeichnet, der über Internettechnologien verfügbar ist und auf den oben genannten Standards basiert. Das W3C definiert einen Web-Service wie folgt:

116

5. Serviceorientierung „A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards“ [W3C, 2004c].

Diese Definition folgt der grundlegenden Beschreibung eines Dienstes. Sie konkretisiert außerdem die Aktionen durch die jeweilige Verwendung der einzelnen Spezifikationen (Basiselemente) im Dreieck der Akteure einer SOA: Anbieter, Nutzer, Vermittler. Abbildung 48 lässt sich daher um die Nutzung der Spezifikationen beziehungsweise Standards entsprechend erweitern (siehe Abbildung 50).

Abbildung 50: Rollen und Aktionen in einer SOA mit Web-Service-Standards

Mit Hilfe der WSDL wird eine Schnittstellenbeschreibung eines implementierten Dienstes erstellt. Der Anbieter veröffentlicht diese WSDL-Schnittstellenbeschreibung seines Dienstes beim Vermittler, der sie in einem Verzeichnis von Diensten veröffentlicht. Dieses Verzeichnis ist nach dem UDDI-Standard geordnet. Nachfrager nutzen SOAP-Nachrichten, um entsprechende Dienste im UDDI-Verzeichnis zu finden. Wird ein passender Dienst gefunden, erhält der Nachfrager die WSDL-Schnittstellenbeschreibung. Mit Hilfe des erhaltenen WSDL-Dokuments ist die Schnittstelle inklusive Adresse des Dienstes bekannt und kann aufgerufen werden. Die notwendigen Nachrichten und Daten werden mittels SOAP-Nachrichten ausgetauscht. Die jeweiligen Rollen sind nicht fest an diese gebunden. Ein Nachfrager kann in einem anderen Kontext Anbieter eines Dienstes sein oder selbst ein UDDI-Verzeichnis für andere Dienste bereitstellen [vgl. vom Brocke, 2008, S. 19 20].


117

5.2.1. Web Service Description Language (WSDL) WSDL wurde 2001 erstmals vom W3C durch [Christensen et al., 2001] veröffentlicht. Inzwischen liegt es seit Juni 2007 in der Version 2.0 als „W3C Recommendation“ (dort im Sinne einer Spezifikation) durch [W3C, 2007d] vor. WSDL ist eine auf XML basierende Schnittstellenbeschreibungssprache, die die Serviceschnittstellen eines Web-Service beschreibt. Neben der angebotenen Funktionalität (Funktion, Ein- und Ausgabeparameter) müssen mit Hilfe von WSDL die Mechanismen des Zugriffs geklärt werden, da Web-Services mittels unterschiedlicher Protokolle genutzt werden können. Zusätzlich muss die Zugriffsadresse (im übertragenen Sinne der Standort des Dienstes) beschrieben werden, da Web-Services sich in einer verteilten Umgebung befinden können und nicht an eine bestimmte Plattform gebunden sind. Ebenfalls müssen Interaktionsparadigmen wie asynchrone Aufrufe mit abgedeckt werden [vgl. Alonso et al., 2004, S. 166]. Die WSDL-Beschreibung ist zur Erfüllung dieser Anforderungen in einen abstrakten und einen konkreten Abschnitt zweigeteilt. Mit einer Überschneidung gibt es eine weitere Zweiteilung, die sich aus der Trennung nach logischem und physischem Zugriff ergibt. Zum einen gibt es die Schnittstellenbeschreibung (logischer Zugriff), zum anderen die Implementierungsbeschreibung (physische Verbindung zum Dienst) [W3C, 2007c]. Diese Unterteilungen und die einzelnen Elemente darin zeigt die folgende schematische Abbildung 51.

Abbildung 51: WSDL-Struktur [aus vom Brocke, 2008, S. 20] Die einzelnen WSDL-Elemente sind wie folgt beschrieben [vgl. bspw. Christensen et al., 2001], [W3C, 2007c], [Alonso et al., 2004, S. 169 ff.]: • : Als Types werden Datentypen definiert, die innerhalb von Nachrichten (Messages) verwendet werden.

118


• : Messages sind Nachrichten, die von den Operationen des Web-Service als ein- oder ausgehende Nachrichten verschickt werden. • : Port-Types gliedern Operationen eines Web-Services zu Gruppen. Operationen sind die eigentlichen Funktionen, die gemäß dem Verwendungszweck durch den Web-Service angeboten werden. • : Das Binding bindet Port-Types zum Kommunikationsprotokoll beziehungsweise zu den Protokollen, die der Dienstanbieter hierfür vorsieht. • : Der Port verbindet die zusammengehörigen Port-Types und das Binding und gibt hierfür die eindeutige Referenzierungsadresse im Netzwerk an. • : Der Service gliedert die Ports eines Web-Service zu einer oder mehreren logischen Gruppen, sofern ein WSDL mehrere unterschiedliche Dienstleistungen beschreibt. Die einzelnen Elemente werden mittels eines Beispiels in Abbildung 52 näher erläutert. Das Beispiel zeigt einen Ausschnitt aus einem WSDL-Dokument der Firma Amazon.com und gibt die Elemente zur Produktsuche über Schlüsselwörter wieder. Die Beziehungen zwischen den einzelnen Elementen wurden entsprechend farbig markiert und mit Pfeilen verbunden. Als Datentyp wird ein zusammengesetzter Datentyp namens KeywordRequest definiert. Dieser ist Teil der Nachricht KeywordSearchRequest. Unter dem Port-Type AmazonSearchPort werden die Operationen (in diesem Fall Suchfunktionen) KeywordSearchRequest48 und „PowerSearchRequest“ zusammengefasst. Diesem Port-Type wird AmazonSearchBinding zugeordnet (in diesem Fall über SOAP). Im Port wird schließlich die Netzwerkadresse festgelegt und Binding und Port-Type zusammengefasst. Der Service AmazonSearchService besteht aus einem Port, dieser ist unter der Adresse http://soap.amazon.com/onca/soap2 physikalisch aufrufbar. Mit diesem WSDL-Dokument ist der von Amazon.com angebotene Web-Service vollkommen beschrieben und kann von Nachfragern genutzt werden.

5.2.2. Simple Object Access Protocol (SOAP) WSDL wird vom Nachfrager zur Designzeit benötigt, um Informationen über einen WebService zu erhalten und einen Client zu erstellen oder eine entsprechende Plattform zu konfigurieren, um einen Service aufzurufen. Die eigentliche Kommunikation, der Nachrichtenaustausch und der Aufruf von Operationen von Web-Services zur Laufzeit, geschieht mittels SOAP. 48

Operation und Message tragen hier zufällig den gleichen Namen „KeywordSearchRequest“, beide stellen aber unterschiedliche Elemente dar.


119

Abbildung 52: Ausschnitt aus einem WSDL der Firma Amazon.com [Amazon, 2009]

SOAP wird durch das W3C spezifiziert, derzeit ebenfalls als „W3C Recommendation“ (dort im Sinne einer Spezifikation) in der Version 1.2 durch [W3C, 2007a] und [W3C,

120


2007b]. SOAP ist ein auf XML basierendes Protokoll zum Austausch strukturierter Informationen in dezentralen und verteilten Umgebungen [W3C, 2007a]. Für SOA mit Web-Services stellt es den derzeitigen Standard zur Kommunikation zwischen Web-Services und zur Nachrichtenkapselung dar [Burghardt, 2004, S. 50]. Eine SOAP-Nachricht besteht dabei aus drei Teilen (siehe auch Abbildung 53): • Envelope: Der SOAP-Envelope enthält die komplette SOAP-Nachricht und legt die verwendete SOAP-Version und weitere XML-spezifische Parameter fest. Der Envelope wird dabei durch das sogenannte Binding in ein Transportprotokoll gekapselt. Hierbei ist SOAP nicht an bestimmte Übertragungsprotokolle gebunden, verwendet werden beispielsweise das „Hypertext Transfer Protocol (HTTP)“, das „Simple Mail Transfer Protocol (SMTP)“, das „File Transfer Protocol (FTP)“, der „Java Messaging Service (JMS)“ oder die „Remote Method Invocation (RMI)“ [vgl. Melzer, 2007, S. 73 u. 85]. • Header: Der Header ist optional und enthält Steuerungsinformationen für den Nachrichtenaustausch, beispielsweise Steuerungsinformationen zum „Quality of Service (QoS)“, zur Transaktionssteuerung oder zur Sicherheit [vgl. Woods und Mattern, 2006, S. 328]. • Body: Der Body enthält die eigentlichen Daten zum Nachrichtenaustausch (die sogenannte Nutzlast). Als Nutzlast können alle XML-kodierten Daten übertragen werden, meinst sind dies Funktionsaufrufe und die zugehörigen Parameter. Diese konversationsorientierte Form wird als „document-style“ bezeichnet. Mit Hilfe von SOAP lassen sich allerdings auch sogenannte „Remote Procedure Calls (RPC)“ als weiteres Kommunikationsparadigma neben der Nachrichtenbasierung verwirklichen. Hierzu gibt es spezielle Rahmenbedingungen, die den Funktionsumfang auf Anfrageund Antwortnachrichten sowie Fehlermeldung einschränken [vgl. Melzer, 2007, S. 75, 78 ff.], [Burghardt, 2004, S. 50]. Zur Verdeutlichung enthält Abbildung 53 ein vereinfachtes Codebeispiel einer Überweisungsgutschrift. Darin wird eine SOAP-Nachricht mittels HTTP übertragen. Der Header enthält Informationen zur Transaktion. Im Body erfolgt der Funktionsaufruf „Deposit“ und die Parameter (Betrag, Währung, Kontonummer) werden übermittelt. SOAP-Nachrichten sind textbasiert. Dies hat sowohl Vor- als auch Nachteile. Als Vorteil gilt die Übertragbarkeit mittel HTTP beziehungsweise HTTPS, wodurch SOAPNachrichten von Firewalls gefiltert und passiert werden können, im Vergleich zu binär kodierten Nachrichten [vgl. Woods und Mattern, 2006, S. 328]. Nachteilig wird teilweise ein Performanzverlust gesehen, der dadurch entsteht, dass binäre Daten auf Seiten des Senders in teilweise sehr lange XML-Nachrichten übersetzt und beim Empfänger wieder zurückübersetzt werden müssen. Dies konnte jedoch in einer Analyse und prototypischen


121

Abbildung 53: SOAP-Struktur mit Beispiel [aus Woods und Mattern, 2006, S. 328 f.] Messreihe der Leistungsaspekte von Web-Services nicht bestätigt werden, da andere Faktoren, wie beispielsweise das Transportprotokoll oder Netzwerkkonfigurationen, wesentlich stärkere Einflussgrößen auf die Performanz bilden als das Parsen von XML-Dokumenten [vgl. Melzer, 2007, S. 155 - 186]. 5.2.3. Universal Description, Discovery and Integration (UDDI) UDDI ist ein Verzeichnisdienst, der das Veröffentlichen und Auffinden von Web-Services im Netz ermöglicht. Die zugehörige Spezifikation wird von der „Organization for the Advancement of Structured Information Standards (OASIS)“ entwickelt. Der aktuelle Stand mit der Version 3.0.2 wurde 2004 in [OASIS, 2004] veröffentlicht. Die UDDI-Spezifikation enthält dabei alle Web-Services, Datenstrukturen und die Beschreibungen aller Instanzen eines UDDI-Verzeichnisdienstes. UDDI gilt als universeller Verzeichnisdienst, das heißt, alle Arten von XML-Dokumenten lassen sich damit veröffentlichen und aufsuchen. Im Zusammenhang mit SOA hat sich UDDI jedoch als Verzeichnisdienst für Web-Services etabliert [vgl. Melzer, 2007, S. 131 132]. Um UDDI zu erklären, ist eine Unterscheidung der vier Kategorien sinnvoll, in denen Informationen zu Web-Services gespeichert und veröffentlicht werden [vgl. bspw. Melzer, 2007, S. 132 - 133], [vgl. Burghardt, 2004, S. 62]: • White Pages: Veröffentlichung von Informationen über einen Anbieter von WebServices. • Yellow Pages: Kategorisierung von Web-Services aller Anbieter nach Kategorien wie Branche oder Ländercodes.

122


• Green Pages: Veröffentlichung von technischen Beschreibungen und Informationen zu einem Web-Service für Benutzer. • Service Type Registration: Analog der Green Pages werden maschinenlesbare Beschreibungen und Informationen über Web-Services in der Service Type Registration angeboten. Green Pages und Service Type Registration verweisen auf ihre Einträge untereinander. UDDI besteht aus zwei Komponenten: dem UDDI-XML-Schema und den UDDI-Schnittstellen. Das XML-Schema spezifiziert die Datenstrukturen, nach denen die Informationen kodiert werden. Das Datenmodell ist von einer Entkopplung institutioneller und dienstbezogener Daten von schnittstellenbezogenen Daten gekennzeichnet. Somit lassen sich zu einer Dienstbeschreibung Schnittstellen mehrerer möglicher Web-Services zuordnen, was die dynamische Selektion von Web-Services zur Laufzeit ([vgl. hierzu Leymann, 2003, S. 13]) ermöglicht [vgl. vom Brocke, 2008, S. 26]. Im erweiterten Kontext kommt hier die bereits erwähnte Semantik von Web-Services zum tragen, die dieses Konzept noch erweitern würde (siehe Diskussion in Abschnitt 5.1.3). Entsprechend den beschriebenen Kategorien hat UDDI zwei Nutzergruppen: Menschen und Anwendungssysteme; entsprechend gliedern sich die Schnittstellen. Zur Interaktion mit Benutzern werden Webseiten von den jeweiligen Verzeichnisbetreibern angeboten. Zur maschinellen Kommunikation nutzt UDDI selbst wiederum die Standards WSDL und SOAP. Schnittstellen werden als WSDL beschrieben, die Kommunikation zwischen UDDI und Anwendungssystemen nutzt SOAP [vgl. Burghardt, 2004, S. 63]. Langfristiges Ziel von UDDI ist es, ein „beliebiges Unternehmen und seine Dienstleistungen mithilfe von Anwendungen in einem UDDI-Verzeichnis finden zu können“ [Melzer, 2007, S. 131].

5.2.4. Transaktionen und Sicherheit von Web-Services Es gibt eine große Anzahl von weiteren Standards, die Web-Services betreffen. Diese sind nicht explizit Teil des Referenzmodells. Zwei davon sollen jedoch überblickartig dargestellt werden, da sie relevante Teilaspekte einer SOA betreffen: Transaktionssicherheit und allgemeine Sicherheitsaspekte von Web-Services.

Transaktionssicherheit Eine Transaktion ist eine Folge von logisch zusammengehörigen Operationen. Sie ist nur dann erfolgreich abgeschlossen, wenn alle darin enthaltenen Operationen erfolgreich waren. Hierzu gibt es im Umfeld von Datenbanken seit langer Zeit erfolgreiche Konzepte [vgl. bspw. Schubert, 2007, S. 313 ff.]. Die Problemstellung im Bereich SOA ergibt sich aus der Tatsache, dass SOA ein verteiltes System darstellt, das sich über mehrere Anwendungssysteme hinweg erstreckt. Eine Transaktion im SOA-Umfeld ist


123

deshalb immer eine verteilte Transaktion [vgl. Melzer, 2007, S. 259], die mehrere Teilnehmer und einen Koordinator mit einschließt. Hierzu wurden ebenfalls erfolgreich sogenannte Commit-Protokolle für Datenbanken entwickelt. Im Bereich von SOA erweitert sich die Problemstellung jedoch noch um die Laufzeit von Transaktionen, da bei lang laufenden Transaktionen Ressourcenzugriffe nicht exklusiv gesperrt werden können. Hier sind entsprechende Kompensationsoperationen notwendig. Ein bewährtes Konzept aus der Praxis sind verschachtelte Transaktionen („open nested transations“) [vgl. Weikum und Vossen, 2002, S. 673 ff.]. Eine Übertragung dieser Transaktionskonzepte, speziell für verteilte und verschachtelte Transaktionen, muss auf die Web-Services erfolgen. Dies geschieht beispielsweise durch das „Web Service Transaction Framework (WSTF)“. Das WSTF besteht aus den folgenden drei, bei OASIS eingereichten, Spezifikationen: • WS-Coordination: WS-Coordination ermöglicht es, durch die Bereitstellung von Mechanismen, neue Transaktionen zu erstellen oder bereits laufenden Transaktionen beizutreten. Weiterhin werden eine Transaktions-Kontext-Struktur und die zugehörigen Anforderungen definiert, die für die Verbreitung von Transaktionskontexten zwischen Web-Services notwendig sind [vgl. OASIS, 2007d]. WS-Coordination ist Basis für die beiden nachfolgenden Erweiterungen. • WS-Atomic Transaction: Diese Spezifikation dient der Koordination im Sinne eines Zwei-Phasen-Commits. Hierzu werden drei Koordinationsprotokolle definiert („completion“, „volatile two-phase commit“, „durable two-phase commit“) inklusive der Definition zugehöriger Zustände und Zustandsübergänge [vgl. OASIS, 2007b]. • WS-Business Activity: WS-Business Activity spezifiziert zwei weitere Koordinationsprotokolle für WS-Coordination [OASIS, 2007c]. Die auf Web-Services übertragenen Transaktionskonzepte funktionieren in diesem Zusammenhang ähnlich problemlos, allerdings behindern die mangelnde Werkzeugunterstützung, fehlende Erfahrungen im Bereich der Kompensation sowie Aspekte der Sicherheit den breiteren Praxiseinsatz [vgl. Melzer, 2007, S. 274].

Sicherheit von Web-Services Sicherheitsaspekte betreffen drei Bedeutungsschwerpunkte: Schutz vor Gefährdungen, Zuverlässigkeit in Bezug auf ein gewünschtes Verhalten und die Gewissheit bezüglich Vermutungen [vgl. Melzer, 2007, S. 188]. Diese sind bei Unternehmensanwendungen immer entscheidend, insofern müssen sie auch in einer SOA mit Web-Services gelöst werden. Bewährte Konzepte wie Nachrichtensicherheit oder Verschlüsselung und digitale Signaturen im Allgemeinen gehören hierzu und sollen weiter genutzt werden. Der Standard WSSecurity beschreibt Erweiterungen zu SOAP zur Nachrichtenintegrität und -zuverlässigkeit und darüber hinaus Mechanismen zur Integration weiterer Standards, um bestehende und

124


zukünftige Konzepte hierin zu integrieren [OASIS, 2006f]. Zu diesen möglichen Erweiterungen gehören beispielsweise: • WS-Policy: WS-Policy spezifiziert ein Framework zur Formulierung von Sicherheitsanforderungen mit zugehöriger Syntax für Web-Service-basierende Systeme [W3C, 2007e]. • WS-Trust: WS-Trust definiert Erweiterungen zu WS-Security zum Austausch sicherheitsrelevanter Daten wie beispielsweise der initiale Schlüsselaustausch [OASIS, 2007e]. • SAML: Die „Security Assertion Markup Language (SAML)“ definiert Syntax und Semantik für XML-kodierte Sicherheitszuweisungen zum Austausch von Informationen zwischen Web-Services bezogen auf Autorisierung und Authentisierung [OASIS, 2005]. SAML ist eigenständig und keine Erweiterung zu WS-Security. Darüber hinaus gibt es noch mehr Erweiterungen zu WS-Security, meist als WS-* bezeichnet. Diese sind jedoch derzeit noch nicht endgültig spezifiziert oder proprietär. Einen umfassenden Überblick hierzu gibt beispielsweise [Melzer, 2007, S. 187 ff.]. Fazit SOA ist ein Architekturkonzept und braucht konkrete Technologien und Standards, damit es umgesetzt und gestaltet werden kann. Im Referenzmodell werden hierfür Web-Services und deren Standards benutzt (und teilweise angepasst). Die detaillierte Vorstellung von WSDL und SOAP, sowie deren Elemente, ist hilfreich, da sie teilweise innerhalb des Referenzmodells in ähnlicher Detailtiefe benutzt, in Bezug gesetzt oder angepasst werden. UDDI, Transaktionen und Sicherheit werden im Referenzmodell nicht explizit genutzt, das Wissen um ihre Zusammenhänge ist aber für das Gesamtverständnis hilfreich.

5.3. Serviceorientierte Architekturen und Geschäftsprozessmanagement Die Problemstellung zur (Geschäfts-)Prozessautomatisierung und eine Einführung in WFMS wurde bereits in Abschnitt 4.5 gegeben. In den folgenden Abschnitten geht es einerseits um die Frage, inwiefern SOA dazu beiträgt, die Konzepte eines WFMS mit Hilfe von WebServices darzustellen. Im größeren Kontext muss zuvor noch darauf eingegangen werden, wie SOA in Bezug auf Geschäftsprozessmanagement zu betrachten ist. Überträgt man den Begriff „Service“ aus SOA (dort im Sinne der Gestaltung von Anwendungssystemen) auf die prozessorientierte Organisationsgestaltung (Prozessorganisation), so kann folgender Vergleich gezogen werden: „Ein „Service“ bezeichnet eine Alternative zur Institutionalisierung einer Aktivität in einem Prozess“ [vom Brocke, 2008, S. 57]. Hierbei ist eine Unterscheidung zwischen Aufgabe und Funktion, wie sie bei [Kosiol, 1976]

5.3. Serviceorientierte Architekturen und Geschäftsprozessmanagement

125

und [Nordsieck, 1972] gemacht wird, hilfreich. Aus der Organisationsgestaltung heraus gibt es eine Aufgabe als fachliche Zielsetzung, die erfüllt werden muss, beispielsweise „Kreditprüfung für eine Bestellung Betrag größer 1.000 Euro durchführen“. Die Institutionalisierung wird als Funktion bezeichnet, sie ist die Übertragung oder Zuweisung an Aufgabenträger. Im Beispiel der Kreditprüfung wäre das etwa das Ausführen durch einen Sachbearbeiter in einer bestimmten Organisationseinheit und unter Zuhilfenahme eines Anwendungssystems. Nach der prozessorientierten Servicebetrachtung wäre ein Service eine weitere Möglichkeit, die Kreditprüfung durchzuführen, etwa automatisiert in der Form eines Web-Service. Die nachfolgende Abbildung 5449 soll diese Möglichkeiten verdeutlichen.

Abbildung 54: Unterschied Aufgabe – Funktion anhand einer EPK [nach vom Brocke, 2008, S. 58] Mit diesem Serviceverständnis kommt es zu einer Kapselung der Aufgabenerfüllung. Somit kann die Gestaltung der Institutionalisierung mehr in den Vordergrund gerückt werden. Die Institutionalisierung steht dabei nicht mehr nur bei einer Gesamtoptimierung und Implementierung eines Prozessmodells im Fokus und ist auch nicht mehr im gleichen Maße wie vorher an die Prozessstruktur gebunden. Gleichzeitig kann eine Nutzung alternativer Institutionalisierungsmöglichkeiten in das Blickfeld der Geschäftsprozessoptimierung mit aufgenommen werden, etwa Outsourcing oder andere Industriepartnerschaften in Bezug auf Services. Das Konzept SOA ist gerade hier darauf ausgelegt, dynamische Servicebindungen einzugehen [vgl. vom Brocke, 2008, S. 57 - 60]. Weiterhin bleibt die Frage nach einer serviceorientierten Geschäftsprozessgestaltung, hier insbesondere die Frage der Gestaltungshoheit: Bei einer Einführung von SOA kann entweder die vorhandene Prozesslandschaft die ausschlaggebende Struktur vorgeben („Topdown-Ansatz“) oder neue und auf Basis der bestehenden (Alt-)Anwendungssysteme entwickelte Services geben die Struktur nach oben vor („Bottom-up-Ansatz“) [vgl. de Hesselle et al., 2008], [Loeser et al., 2008, S. 619]. Die Granularitätsfrage bei Services wird somit zu einer Frage der Vorgaben eines Prozessmodells (Konventionshandbuch), sofern es sich um eine Einführung einer SOA in einer Prozessorganisation handelt. 49

Obwohl in EPK der Objekttyp „Funktion“ verwendet wird, handelt es sich im eigentlichen Sinne um eine Aufgabenbeschreibung. Aufgabe und Institutionalisierung ergeben sich aus dem gesamten Funktionszuordnungsdiagramm (siehe Abbildung).

126


Abbildung 55: Top-Down oder Bottom-Up-Vorgehen für SOA [nach de Hesselle et al., 2008, S. 32] Durch den Zusammenhang von SOA und Geschäftsprozessmanagement kommt es zu einer Abstimmung und Angleichung der Organisations- und Informationssystemgestaltung, da es eine klare Beziehung zwischen den Aktivitäten eines Geschäftsprozesses (Aufgaben) und deren technischer Institutionalisierung (Services) gibt. [vom Brocke, 2008, S. 60 ff.] nimmt dies als Grundlage für die Entwicklung eines serviceorientierten Prozessdesgins, Prozesscontrollings und Prozessmanagements analog der Differenzierung der Systembegriffe aus Abbildung 46 (Seite 106): • serviceorientiertes Prozessdesign: Gestaltung serviceorientierter Geschäftsprozesse und des daraus resultierenden Serviceportfolios. • serviceorientiertes Prozesscontrolling: Informationsorientiertes Geschäftsprozesscontrolling zur Identifikation und Entscheidungsunterstützung von Optimierungsansätzen im Serviceportfolio. • serviceorientiertes Prozessmanagement: Planung, Organisation und Kontrolle der Ausgestaltung des Serviceportfolios.


127

Eine Betrachtung dessen im Zusammenhang mit dem hier vorgestellten integrierten Managementkonzept ist Teil des Referenzmodells. Die nachfolgenden Abschnitte beschreiben zunächst die konkreten Möglichkeiten zur Orchestrierung von Web-Services zu Prozessen mittels des Standards BPEL, der Integration von nicht- oder nur teilautomatisierten Interaktionen von Benutzern („human interaction“) und weitere Aspekte.

5.3.1. Prozessorchestrierung mit Business Process Execution Language (BPEL) Unter Prozessorchestrierung versteht man die Anordnung von Prozessaktivitäten gemäß ihrer logischen Abfolge und die Darstellung ihrer Beziehungen untereinander [vgl. Weske, 2007, S. 125], wie dies in Prozessmodellen der Fall ist. Dabei werden die ausführbaren Aspekte genau eines Geschäftsprozesses, meist aus der unternehmensinternen Sicht, beschrieben [vgl. Melzer, 2007, S. 226]. Werden Geschäftsprozesse aus prozessorientierten Services zusammengesetzt, so bedarf es in einem ausführbaren Kontext einer speziellen Orchestrierungssprache hierzu. Für die Orchestrierung von Web-Services wurde die „Web Services Business Process Execution Language (WS-BPEL)“ (kurz BPEL) entwickelt. Sie ist inzwischen in der Version 2.0 durch [OASIS, 2007a] spezifiziert worden und ist wie WSDL und SOAP ebenfalls XML-basiert. Durch die Spezifizierung von BPEL, und somit die Standardisierung eines Prozessmodells für die Umsetzung von Geschäftsprozessen mittels Web-Services, ist eine Portabilität und Interoperabilität für derartige BPEL-Prozessmodelle gewährleistet [vgl. Masak, 2007, S. 247]. Diese Prozessmodelle (in Form eines maschinenlesbaren XML-Dokuments) dienen als Input für eine zentrale technische Komponente, genannt Workflow-, Process- oder BPELEngine, die die Web-Service-Orchestrierung gemäß dem BPEL-Modell steuert. BPEL erfüllt hierzu grundsätzlich die Kriterien einer imperativen Programmiersprache [vgl. Melzer, 2007, S. 230]. Die Spezifikation ist sehr umfangreich und technisch motiviert. Aus diesem Grund soll hier lediglich ein Überblick über die wesentlichen Elemente gegeben werden, um den grundsätzlichen Aufbau und die Intention von BPEL verständlich zu machen. In der Grundstruktur besteht ein BPEL-Prozess aus den folgenden Elementen, die Teil des Wurzelelements sind [vgl. OASIS, 2007a, S. 21, 36 ff.]: • : Partner-Links dienen der Beschreibung der Partnerbeziehungen im BPEL-Prozess. Partnerbeziehungen sind Web-Services (deren WSDL), die der BPEL-Prozess im Prozessablauf aufruft oder diejenigen Web-Service-Schnittstellen, die er selbst zur Verfügung stellt (beispielsweise um als Prozess selbst aufgerufen zu werden oder um Antworten von außen zu erhalten). Diese werden als Partner-Links zu Beginn deklariert und inhaltlich spezifiziert (zum Beispiel die Rolle des PartnerLinks im BPEL-Prozess (Sender oder Empfänger, Anbieter oder Nachfrager und so weiter) oder der Typ des Partner-Links). Im BPEL-Prozess werden sie über ihr

128

5. Serviceorientierung Attribut „name“ referenziert; diese Kapselung der Web-Services durch Partner-Links dient der durchgängigen losen Kopplung [vgl. auch Melzer, 2007, S. 245 - 246].

• : Variablen dienen zur Speicherung von Nachrichten, sie bilden einen Teil des Zustands eines BPEL-Prozesses ab. Üblicherweise werden Nachrichten gespeichert, die von Web-Services empfangen werden. Sie bilden häufig den Input für spätere Web-Service-Aufrufe. Variablen können mittels Operatoren manipuliert werden. • : Fault-Handler dienen der Fehlerbehandlung. Sie legen fest, welche Aktivitäten in unterschiedlichen Fehlerfällen ausgeführt werden. • : Compensation-Handler kapseln Aktivitäten, die im Kompensationsfall ausgeführt werden, um einen bestimmten Zustand wieder herzustellen und um bereits erfolgreich ausgeführte Aktivitäten wieder rückgängig zu machen. Sie sind Teil eines erfolgreichen Transaktionsmanagements. Kompensation bildet den größeren Kontext als die Fehlerbehandlung. • : Event-Handler dienen der Entgegennahme von Ereignissen. Dies können eingehende Nachrichten sein oder auch Alarme, die von Timern ausgelöst werden. • : Ein Scope definiert jeweils einen Gültigkeitsbereich. Er bildet den Kontext für das Ausführungsverhalten der beinhalteten Aktivitäten, insbesondere für transaktionale Kontexte. • Aktivitäten: Im Wurzelelement muss sich immer mindesten eine Aktivität befinden. Aktivitäten gliedern sich in zwei Klassen: Basisaktivitäten und Strukturaktivitäten. Basisaktivitäten beschreiben die elementaren Bestandteile des Prozessablaufs. Sie werden hier kurz skizziert [vgl. OASIS, 2007a, S. 84 - 97]: • : Invoke dient zum Aufruf von Web-Servies (deren Operationen) über Partner-Links. • : Receive dient zum Empfang von Nachrichten. Dabei wird der PartnerLink spezifiziert, nach dessen zugeordneter Rolle der BPEL-Prozess als Empfänger von Nachrichten gilt und über den entsprechende Nachrichten empfangen werden. Beispielsweise wird so der Prozessstart implementiert oder auf ein Reply eines Partnerprozesses reagiert. • : Reply dient zum Senden einer Antwort auf Grund eines Receive. • : Wait definiert eine Verzögerung über einen bestimmten Zeitraum, um beispielsweise Aufrufe zu einem späteren oder genau festgelegten Zeitpunkt auszuführen.


129

• : Assign dient zum Kopieren von Werten zwischen Variablen [vgl. auch OASIS, 2007a, S. 59]. • : Throw dient zur Signalisierung interner Fehlerzustände. • : Exit beendet den Prozess unverzüglich. Den komplexen Zusammenhang der oben dargestellten BPEL-Kommunikationselemente, insbesondere in Bezug zu den korrespondierenden WSDL-Elementen über Partner-Links, zeigt Abbildung 56.

Abbildung 56: BPEL-Kommunikationselemente mit Bezug zu WSDL [aus Melzer, 2007, S. 243] Den Kontrollfluss in BPEL steuern die Strukturaktivitäten [vgl. OASIS, 2007a, S. 98 114]: • : Sequence gliedert eine oder mehrere Aktivitäten und lässt diese sequenziell ausführen. • , : Flow führt die Aktivitäten parallel aus, die innerhalb des FlowElements enthalten sind. Flow kann zur Synchronisation von unterschiedlich lange laufenden Aktivitäten genutzt werden. Mit Hilfe von Links können Aktivitäten verknüpft werden, die mit einer hierarchisch ineinander verschachtelten XML-Struktur nicht darstellbar sind, in der Praxis jedoch Relevanz haben [vgl. auch Melzer, 2007, S. 241 - 242]. • : If dient zur Fallunterscheidung und entsprechenden Verzweigung des Kontrollflusses. • : Pick wartet auf das Auftreten genau eines Ereignisses aus einer Reihe definierter, möglicher Ereignisse und führt die dazugehörige Aktivität aus.

130


• , , : Diese drei Aktivitäten dienen der Definition von Schleifenkonstrukten. Mit BPEL können auch abstrakte Prozessabläufe dargestellt werden. Dabei steht die (unternehmensübergreifende) Kooperation mehrerer Prozesse im Fokus. Dies wird als Choreografie bezeichnet [vgl. Melzer, 2007, S. 227 - 228]. Hierfür wird die gleiche BPEL-Syntax wie oben verwendet, die entsprechende Semantik wurde nicht spezifiziert [vgl. OASIS, 2007a, S. 147]. Hierzu scheinen andere Modellierungssprachen besser geeignet, beispielsweise BPMN [vgl. Weske, 2007, S. 227 ff.]. Die Anwendbarkeit von BPEL-Prozessen in der Praxis wird durch zwei Umstände beschränkt. Zum einen können hierarchische Prozessstrukturen nicht mittels Subprozess abgebildet werden. Zum zweiten werden manuelle Prozessschritte, wie sie in Geschäftsprozessen häufig vorkommen, in BPEL als Ausführungssprache nicht berücksichtigt [vgl. Russell und van der Aalst, 2008, S. 95]. Dem Kritikpunkt der fehlenden Subprozesse lässt sich entgegenhalten, dass sich Hierarchien von Prozessen und Subprozessen in BPEL leicht durch Partner-Links erreichen lassen. Jeder BPEL-Prozess hat ein WSDL-Interface zum Aufruf des Prozesses, der sich als Partner-Link wiederum in übergeordnete BPEL-Prozesse einfügen lässt [vgl. OASIS, 2007a, S. 37]. Dies nutzt den eigentlichen Anwendungszweck von BPEL (den koordinierten Aufruf von Web-Service-Operationen). Der Bedarf nach einem expliziten Element hierfür scheint weiterhin diskussionswürdig. Die Notwendigkeit zur Aufnahme manueller Arbeitsschritte unter dem Begriff „human interaction“ wurde hingegen bereits in Abschnitt 4.5.1 eingeführt, eine entsprechende Erweiterung zu BPEL wird im nächsten Abschnitt ausführlicher behandelt.

5.3.2. Integration manueller Arbeitsschritte Zur Integration manueller Arbeitsschritte in eine standardisierte Ausführungssprache wie BPEL sind zwei Aspekte von Bedeutung: zum einen ein genaues Verständnis des Konzepts „manueller Arbeitsschritt“ und zum anderen eine Erweiterung eines Prozessmodells mit geeigneten Elementen zur Aufnahme der manuellen Arbeitsschritte. Beides wird hier im konkreten Zusammenhang mit BPEL vorgestellt. Ein Vorschlag zur Aufnahme von „human interaction“ in eine Erweiterung zur BPELSpezifikation wurde bereits 2005 von [Kloppmann et al., 2005] diskutiert. Seither wurden die beiden Spezifikationen „BPEL4People“ und „WS-Human Task“ jeweils in einer Version 1.0 durch [Agrawal et al., 2007b] („BPEL4People“) und [Agrawal et al., 2007a] („WS-Human Task“) vorgestellt. Beide sind durch ihre jeweilige Veröffentlichung unter Beteiligung der wichtigsten Softwarehersteller spezifiziert. Eine Spezifizierung durch ein Standardisierungsgremium steht noch aus, beide Dokumentationen wurden hierfür jedoch bereits an ein technisches Komitee bei OASIS übergeben.


131

Ein manueller Arbeitsschritt wird hier als eine unteilbare Arbeitsaufgabe50 verstanden, die von einer Person ausgeführt wird [vgl. Kloppmann et al., 2005, S. 14]. Gemäß der Integration in eine Ausführungssprache und somit in eine automatisierte Prozessumgebung ist ein Human-Task die elektronische Ausprägung eines solchen manuellen Arbeitsschritts. Um mit Human-Tasks umzugehen, sind drei Anwendungssysteme hierzu notwendig [vgl. Agrawal et al., 2007a, S. 41]: 1. „requesting application“: Als das anfordernde Anwendungssystem ist dasjenige zu verstehen, das einen Human-Task generiert. Dies ist der BPEL-Prozess beziehungsweise genauer die BPEL-Engine. Die Spezifikation hierzu ist „BPEL4People“, darin werden die Sprachkonstrukte zur Erzeugung von Human-Tasks festgelegt. 2. „supporting application“: Zur Verwaltung von Human-Tasks über deren Lebenszyklus hinweg bedarf es eines eigenen Anwendungssystems, das alle Operationen eines Human-Task unterstützt. Hierzu werden in der Spezifikation „WS-Human Task“ die notwendigen Programmierschnittstellen sowie ein Interaktionsprotokoll beschrieben. Die „supporting application“ selbst wird nicht weiter beschrieben. 3. „task list client“: Schließlich bedarf es noch einer Schnittstelle zum Anwender, das heißt zur eigentlich ausführenden Person eines manuellen Arbeitsschritts, um eine Aufgabe zu erhalten und nach Vollendung der Aufgabe den Task abzuschließen und eine Rückmeldung an das anfordernde Anwendungssystem zu geben. Die entsprechenden Zustände und Zustandsübergänge regelt die Spezifikation „WS-Human Task“, das Anwendungssystem selbst wird ebenfalls nicht weiter beschrieben.

WS-Human Task Den zentralen Teil der Spezifikation „WS-Human-Task“ bildet die genaue Beschreibung eines Human-Task. Dieser ist ebenfalls XML-basiert und hat folgende Elemente [vgl. Agrawal et al., 2007a, S. 23 ff.]: • : Das Task-Element stellt das Wurzelelement eines Human-Task dar. Es enthält die nachfolgenden Elemente. • : Mit dem Element Interface werden die beiden Schnittstellen des Human-Task festgelegt. Zum einen ist dies der Port-Type und die Operation zum Aufruf des Human-Task, zum anderen die Schnittstelle zur Rückantwort an das anfordernde Anwendungssystem nach Beendigung des Human-Task. Die Beschreibung eines Human-Tasks besteht immer aus einem WSDL-Dokument und einem WS-Human-Task-Dokument. • : Optional kann die Priorität des Human-Task als ganze Zahl angegeben werden. 50

Unteilbarkeit kann im Zusammenhang dieser Arbeit entsprechend einem Unternehmensprozessmodell auf die Granularität eines Prozessmodells und seiner Funktionen bezogen werden.

132


• : Mit People-Assignment erfolgt eine Zuordnung des HumanTask zu den folgenden generischen Rollen (Zuordnung jeweils zu einer Person oder Gruppe). Der tatsächliche Besitzer darf nicht spezifiziert werden, dies geschieht über Zuordnungen während der Laufzeit. – : Mögliche, später zuordenbare Besitzer dieses HumanTask – : Vom Besitz ausgeschlossene Rollen – : Urheber des Human-Task – : Rolle, die letztendlich für das Ergebnis diesen HumanTask verantwortlich ist – : Rolle, die für das Ergebnis der Summe dieser Human-Task verantwortlich ist • : Festlegung oder Einschränkung von Weiterleitungsmöglichkeiten des Human-Task • : Beschreibende Elemente des Human-Task, die für die Anzeige eines Human-Task über die Benutzerschnittstelle wichtig sind: – : Kurzbezeichnung des Human-Task – : Weitere frei wählbare Parameter zur Beschreibung des Human-Task – : Beschreibung des Human-Task – : Lange Beschreibung des Human-Task, diese kann auch Elemente wie HTML enthalten • : Festlegung der Methode zur Präsentation des Human-Task gegenüber der Benutzerschnittstelle • : Optionaler Verweis auf das Ergebnis des Human-Task • : Optionales Element zur Unterstützung bei der Suche nach Instanzen • : Optionale Festlegung von Fristen für diesen Human-Task, die für eventuelle Eskalationsszenarien von Bedeutung sind Mit dieser Struktur kann nach der Spezifikation ein Human-Task vollständig beschrieben und als XML-Dokument gespeichert werden. Neben dem Human-Task werden auch sogenannte Notifications spezifiziert. Diese werden benutzt, um Personen und Gruppen über Ereignisse zu informieren, beispielsweise im Eskalationsfall. Eine Notification unterscheidet sich von Human-Task nur dadurch, dass sie nicht die Elemente ,


133

und besitzt und keine Rückbestätigung bei Erhalt erfolgt [vgl. Agrawal et al., 2007a, S. 39 ff.]. Neben der Beschreibung eines Human-Task werden weiterhin die Operationen in ihrer Signatur beschrieben, die ein „task list client“ gegenüber einem Human-Task beziehungsweise gegenüber dem Anwendungssystem zur Verwaltung von Human-Tasks implementieren muss. Hierzu gehören Operationen, um den Status zu ändern (claim, start, stop, release, suspend, ...) oder um Parameter zu ändern (get-, set- und delete-Operationen zur Manipulation von Kommentaren und Anhängen), und weitere Operationen, beispielsweise, zur Suche oder Administration. Die genaue Aufstellung gibt [Agrawal et al., 2007a, S. 41 ff.]. Das zugehörige Zustandsdiagramm zeigt Abbildung 57, darin sind die verschiedenen Zustände sowie deren Übergänge dargestellt.

Abbildung 57: Zustandsdiagramm eines Human-Task [aus Agrawal et al., 2007a, S. 37] Aufbauend auf die Spezifikation der notwendigen Operationen gegenüber einem HumanTask wird das „WS-HT coordination protocol“ eingeführt. Es dient zum Austausch der Anweisungen zwischen der „requesting application“ und einem aufgerufenen HumanTask [vgl. Agrawal et al., 2007a, S. 58 - 65]. Ebenfalls werden sogenannte CallbackInformationen zum asynchronen Nachrichtenaustausch mit Human-Tasks über Web-Services

134


und SOAP [vgl. Agrawal et al., 2007a, S. 66 - 73] als eine Erweiterung der bestehenden Web-Service-Spezifikation „WS-Addressing“ spezifiziert [spezifiziert in W3C, 2006b]. BPEL4People Die zweite wichtige Spezifikation ist „BPEL4People“. Sie nutzt die Möglichkeit zur Erweiterung der Sprache WS-BPEL [vgl. OASIS, 2007a, S. 31] und führt eine weitere Aktivität in BPEL ein, die sogenannte „People Activity“. Diese ist die grundlegende Aktivität zur Integration von „human interaction“ in BPEL, das heißt eine Integration von Human-Task und Notification (wie oben beschrieben). Hierbei sind zwei Aspekte von Bedeutung: Zum einen muss die Sprache WS-BPEL erweitert werden, um BPELProzessbeschreibungen um manuelle Arbeitsschritte erweitern zu können. Zum anderen ist hierfür auch eine Erweiterung einer ausführenden BPEL-Engine notwendig, die die neuen Sprachkonstrukte interpretieren und ausführen kann. Ein Vorschlag hierfür wird beispielsweise durch [Holmes et al., 2008] beschrieben. Eine „requesting application“ (in diesem Fall eine BPEL-Engine) muss mehrere Möglichkeiten der Task-Generierung in Bezug auf Gültigkeit und Implementierung berücksichtigen. Diese sind in Abbildung 58 skizziert.

Abbildung 58: Möglichkeiten zur Integration von „human interactions“ in BPEL [aus Agrawal et al., 2007b, S. 16] Sofern eine BPEL-Engine „BPEL4People“ unterstützt, können im BPEL-Dokument zusätzlich Aktivitäten nach folgender Grundstruktur beschrieben werden [vgl. Agrawal et al., 2007b, S. 16 ff.]: • : Element für die „human interaction“ als eine weitere Aktivität in BPEL. Es enthält die folgenden Elemente: • , , : Elemente zur eigentlichen Festlegung und Instanziierung eines Human-Task oder einer Notification. Es wird eines der drei


135

Abbildung 59: Klassendiagramm mit Elementen aus BPEL4People und WS-HumanTask [aus Russell und van der Aalst, 2008, S. 98] Elemente verwendet. Dies ist abhängig von den Möglichkeiten aus Abbildung 58. Notifications werden analog durch , oder instanziiert. • : Element zur Festlegung von Zeitpunkten zur Aktivierung und längsten Gültigkeit des Human-Tasks. • : Element, das festlegt, wie mit Anhängen verfahren wird, die zwischen dem Prozess und dem Human-Task ausgetauscht werden. Den Zusammenhang zwischen den Elementen aus beiden Spezifikationen zeigt abschließend das Klassendiagramm in Abbildung 59.

Fazit Das Referenzmodell versucht, ein serviceorientiertes Prozessmanagement (Planung, Organisation und Kontrolle der Ausgestaltung des Serviceportfolios) zu erreichen (i) durch Abstimmung des Standardprozessmodells auf die Servicegestaltung zur Planung und Organisation und (ii) durch Gestaltung einer Umsetzungsarchitektur, das heißt die Nutzung von Technologien aus SOA und der Ereignisorientierung zur Kontrolle (Automatisierung, Steuerung, Überwachung) der Geschäftsprozesse und seiner Teilprozesse. Den

136


häufig diskutierten Standard BPEL und das weniger beachtete Thema der manuellen Arbeitsschritte (inklusive der Spezifikationen BPEL4People und WS-HT) muss das Referenzmodell mit berücksichtigen: BPEL, da es ein zentraler Standard zur Choreografie von Web-Services ist, und die manuellen Arbeitsschritte, da sie wesentliches Charakteristikum eines Contact-Centers darstellen. Auch hier ist eine genauere Darstellung von BPEL, BPEL4People und WS-HT nützlich, weil auch hier die Elemente in der Gestaltung des Referenzmodells erneut benutzt, in Bezug gesetzt oder angepasst werden.

137

6. Ereignisorientierung Ereignisse werden in der Informationsverarbeitung immer wichtiger, ihre Anzahl in Informationssystemen steigt beständig. Die bereits erwähnte Automatisierung der Kommunikation von Anwendungssystemen durch SOA und die Verbreitung des Internets verstärken dies um ein Vielfaches. Vermehrt taucht die Ereignisorientierung auch als Adjektiv auf. So werden etwa Unternehmen oder Konzepte mit dem Zusatz „event-driven“ beschrieben. In diesem Kapitel werden die Grundlagen zu Ereignissen und die Ereignisorientierung in ihren konkreten Konzepten und Architekturen behandelt. Ausführlich wird das „Complex Event Processing (CEP)“ beschrieben, das derzeit verstärkt in den wissenschaftlichen Fokus tritt. CEP und die Grundlagen verteilter ereignisorientierter Systeme werden anschließend im Kontext von Geschäftsprozessmanagement und Contact-Centern betrachtet.

6.1. Grundlagen der Ereignisorientierung Zum besseren Verständnis werden zunächst die Grundlagen dargestellt. Hierzu gehören Fragen danach, was Ereignisse eigentlich sind und wo informationstechnisch eine Ereignisorientierung festzustellen ist. Die vorhandenen Ansätze der Ereignisorientierung werden unterschieden und in den nachfolgenden Abschnitten genauer betrachtet.

6.1.1. Ereignisbegriff Als Ereignis oder Event51 wird ein instantanes, atomares Auftreten von etwas bezeichnet, an dem man interessiert ist. Atomar ist ein Event, da es sich entweder komplett oder überhaupt nicht ereignet [vgl. Chakravarthy und Adaikkalavan, 2008, S. 8]. Weiterhin lassen sich beim Auftreten von Geschehnissen zwei Bedeutungen des Begriffs Event unterscheiden: Event als etwas, das in der realen Welt passiert und Event als eine Repräsentation dessen in IT-Systemen. Die nachfolgende Tabelle 4 zeigt beispielhaft die hierfür verwendeten Begriffe. Die Ereignisorientierung in Informationssystemen bezieht sich auf Events als Repräsentationen mit Bezug zu Geschehnissen der realen Welt. Hierbei werden drei Aspekte von Events unterschieden [vgl. Luckham, 2002, S. 88 - 89], [Etzion, 2007]: 51

Im weiteren Verlauf dieser Arbeit wird der Begriff „Event“ verwendet. Der englische Begriff ist synonym mit Begriff „Ereignis“, allerdings gibt es fast ausschließlich englischsprachige Literatur zum Thema Ereignisorientierung. Mit dem Begriff „Event“ ist daher eine stärkere Assoziation mit der Bedeutung von Ereignisorientierung von Informationssystemen verbunden, nicht zuletzt durch Akronyme wie CEP („Complex Event Processing“), ESP („Event Stream Processing“) oder EDA („Event Driven Architecture“).


138

6. Ereignisorientierung

Autor(en)

Reale Welt

IT-Repräsentation

[Luckham, 2002, S. 88] Aktivität

Event als Aufzeichnung einer Aktivität in einem System

[Mühl et al., 2006, S. Event 11]

Notifikation als Datum, das auf ein Event verweist (auf unterster Ebene als Message bezeichnet)

Event

Event als Objekt zur Repräsentierung, Kodierung oder Aufzeichnung in Computersystemen

[EPTS, 2008a, S. 5]

Tabelle 4: Differenzierung der Eventbegriffe • Form: Ein Event hat eine Form, mit Hilfe dessen es dargestellt, übermittelt oder gespeichert wird. Hierzu gehören Attribute und Datenkomponenten. • Signifikanz: Ein Event hat einen Inhalt. Dadurch wird ein konkretes Geschehen aus der realen Welt näher beschrieben, auf das das Event verweist. Die Beschreibung erfolgt mit Hilfe von Daten und Attributen. • Relativität: Ein Event steht in Beziehung zu anderen Events. Diese Beziehungen können zeitlich, kausal oder konstruierend sein. Im Zusammenhang mit der Form stehen Datenformate und Modelle, mit denen Events beschrieben werden können. Hierbei werden allgemein folgende Möglichkeiten unterschieden[vgl. Eckert, 2008, S. 42 - 43]: • Typisiert ohne Daten: Repräsentation als Symbol (binär oder als Zeichenkette) für ein Event eines bestimmten Typs, zum Beispiel „EingehenderAnruf01805123456“. Weitere Informationen können hiermit nicht kodiert werden. • Typisiert mit Daten: Repräsentation als typisiertes Event mit Daten in der Form von Attributen, die beispielsweise als Key-Value-Paare dargestellt werden, etwa „EingehenderAnruf(Anrufer=040654321, Empfaenger=01805123456)“. • Relationale Tupel: Relationale Tupel repräsentieren Events durch ein Symbol, das den Typ bestimmt, sowie durch weitere Attributwerte. Die Attribute und deren Typen werden meist in einem Schema spezifiziert. Ein eingehender Anruf könnte sich folgendermaßen darstellen: Event("EingehenderAnruf", 040654321, 01805123456).

6.1. Grundlagen der Ereignisorientierung

139

• Objekte: Repräsentation eines Events in Form eines Objekts einer objektorientierten Programmiersprache wie Java oder C#. Das Event wird dabei sowohl durch die Klasse (und die Superklassen, von denen es abgeleitet ist) als auch durch seine Attribute beschrieben. Die Methoden eines Objekts erweitern die Funktionalitäten eines Events, etwa durch die Möglichkeit, auf eine Instanz eines Events zuzugreifen oder dessen Status zu ändern. • XML-Nachrichten: Ein Event kann als XML-Nachricht dargestellt werden. XML dient dabei einerseits als Datenformat und andererseits als eine Möglichkeit zur Serialisierung. Obiges Beispiel könnte mit Hilfe von XML folgendermaßen dargestellt werden: 040654321 01805123456 Dieser Form der Repräsentationen von Events kommt eine besondere Bedeutung zu, die sich auf Grund der zahlreichen XML-basierten Standards zum Datenaustausch im Internet ergeben, wie beispielsweise die verschiedenen Web-Service-Standards. Hier ist besonders SOAP zu nennen, das zum Transport von XML-Daten genutzt werden kann (vgl. auch Abschnitt 5.2.2). Die Signifikanz eines Events wird durch Daten und Attribute beschrieben. Ein Event, das beispielsweise einen eingehenden Anruf signalisiert, beschreibt diesen Anruf genauer, indem die Telefonnummer des Anrufers und die gewählte Nummer als Attribute angefügt werden. Ein weiteres wichtiges und durchaus nicht triviales Attribut ist die Zeit eines Events, die zu unterschiedlichen Schwierigkeiten führen kann: • Messungen: Es gibt unterschiedliche Möglichkeiten, wann und wo ein Event gemessen werden kann. Dies kann beispielsweise die Zeit des Entstehens, der Entdeckung oder der Meldung sein. • Uhren und Granularität: Uhren in den verschiedenen Systemen können unabgestimmt sein. Ein Event kann unterschiedliche Zeiten zugeordnet haben, obwohl derselbe Zeitpunkt gemeint ist. Als Uhren werden Prozesse bezeichnet, die eine geordnete, aufsteigende Sequenz von Zeitwerten erzeugen (sogenannte Ticks). Als Granularität oder Chronon wird die Länge des Intervalls zwischen zwei Ticks bezeichnet [vgl. EPTS, 2008a, S. 7]. • Zeitpunkt versus Zeitintervall: Es besteht die Frage, ob ein Event zu einem Zeitpunkt oder in einem Intervall stattfindet. Grundsätzlich geht man davon aus, dass ein Event sich in einem Intervall ereignet [vgl. bspw. Galton und Augusto, 2002, S. 548 - 549], [Luckham, 2002, S. 96], [Etzion, 2007, S. 15], [Bry und Eckert, 2007, S. 3]. Ist dieses Intervall kleiner als das Chronon, so erhält ein Event einen Zeitpunkt und wird als instantanes Event bezeichnet [vgl. EPTS, 2008a, S. 16]. Ob dies von

140

6. Ereignisorientierung Bedeutung ist oder nicht, ist jeweils vom Kontext einer Anwendung abhängig und kann nicht generell beantwortet werden.

Von zunehmender Bedeutung ist auch die räumliche Dimension von Events, das heißt die Frage, wo das Event aufgetreten ist oder aufgezeichnet wurde [vgl. Etzion, 2007, S. 11], vor allem dann, wenn mobile Komponenten (beispielsweise Mobiltelefone mit Positionsempfängern) beteiligt sind. Die weiteren Attribute zur Signifikanz sind individuell und stark abhängig vom beobachteten Geschehen. Der dritte Aspekt von Events, deren Relativität (Beziehungen zwischen den Events) ist vor allem für die Verarbeitung komplexer Events von Interesse und wird im Abschnitt 6.3 ausführlich behandelt.

6.1.2. Ereignisorientierung und -verarbeitung Die Ereignisverarbeitung an sich ist nicht neu. Sie ist in Systemen wie aktiven Datenbanken, Sensornetzwerken, Workflow-Systemen, in Netzwerk-Management-Systemen oder in der Oberflächensteuerung von Betriebssystemen (Reaktionen auf Mausklicks und Ähnliches) zu finden [vgl. Mühl et al., 2006, S. 7], [Chakravarthy und Adaikkalavan, 2008, S. 2]. Parallel hierzu gibt es Bereiche, die potentiell eine viel größere Anzahl an Events generieren und über die jeweilige Domäne hinaus von zunehmendem Interesse sind. Hier sind vor allem zu nennen: • Serviceorientierung: Die Bereitstellung und Orchestrierung von Diensten in einer verteilten Umgebung führt zu einer Zunahme der Interaktion und (automatisierten) Kommunikation zwischen Anwendungssystemen. Standardisierte Kommunikation und Schnittstellenbeschreibungen (WSDL, SOAP) unterstützen dies [vgl. bspw. Melzer, 2007], [Alonso et al., 2004]. • Anwendungsintegration: Zunehmende Integration von heterogenen Anwendungssystemen durch Event-basierte Integrationstechnologien und -architekturen [zusammengefasst in Mühl et al., 2006]. • Web: Das Web als Plattform für Privatanwender und Firmen wächst beständig weiter. Es entstehen kontinuierlich neue Geschäftsmodelle, die die Interaktion von Benutzern einschließen. Zusätzlich werden Daten im Netz verteilt gespeichert und Software als Online-Service genutzt. Sozialer Austausch findet immer häufiger virtuell in „social networks“ statt [vgl. bspw. Vossen und Hagemann, 2007, S. 241 ff.]. • Hardware: Immer mehr Endgeräte werden vernetzt. Eine Miniaturisierung von Hardware erschließt eine immer größere Bandbreite von Einsatzmöglichkeiten. Dadurch

6.1. Grundlagen der Ereignisorientierung

141

nehmen mobile Endgeräte immer mehr zu und es werden mehr Sensoren, RFIDChips oder Positionsempfänger eingesetzt. Es entsteht ein starker Anstieg von Kommunikation zwischen allen Komponenten [vgl. bspw. Culler et al., 2004], [Wright, 2009]. Aus den oben aufgezählten Punkten kann mindestens festgehalten werden, dass die Anzahl der untereinander vernetzten Beteiligten (Menschen wie Systeme) und ihre Interaktion steigen. Somit nimmt auch die Kommunikation zwischen ihnen zu. Die einzelnen Interaktionen und der Nachrichtenaustausch können nun einerseits als Geschehnisse der realen (System-)Welt gesehen werden (Person A benutzt Dienstleistung B, Anwendungssystem A ruft Service von Anwendungssystem B auf und so weiter). Hierzu können signifikante Events erzeugt werden, die auf diese Interaktion oder Kommunikation verweisen. Andererseits werden Events bereits explizit erzeugt, um damit Abläufe zu steuern. Die Kenntnis davon ist auch in anderen Zusammenhängen sinnvoll. Im Vergleich zur Ereignisverarbeitung in abgeschlossenen Systemkontexten (wie die Benutzeroberflächensteuerung oder aktive Datenbanken) verlassen Events zusehends Systemund Unternehmensgrenzen. Es sind nicht mehr nur abgegrenzte Zuständigkeitsbereiche wie Anwendungssysteme, verantwortliche Personen oder Unternehmen, auf die sich Events erstrecken. Aus diesen Zusammenhängen lässt sich für das weitere Verständnis dieser Arbeit der Begriff „Ereignisorientierung“ wie folgt abgrenzen: Als Ereignisorientierung wird hier eine wesentliche Eigenschaft von Anwendungs- und Informationssystemen52 verstanden. Die Steuerung dieser Systeme ist stark von Events abhängig. Events werden nicht nur ausschließlich im Innenverhältnis verarbeitet. Das System erhält Events entweder von außerhalb oder Events verlassen den Kontext des Systems. Immer ist dabei die reaktive Eigen- oder Fremdsteuerung und der Nachrichtenaustausch auf Basis von Events ausgerichtet. Das Umfeld der Ereignisorientierung ist heterogen. Für die Umsetzung und Ausgestaltung der Ereignisorientierung in Anwendungs- und Informationssystemen gibt es verschiedene Ansätze, diese werden im Folgenden unterschieden. 6.1.3. Ereignisorientierte Ansätze Eine wesentliche Forderung an ereignisorientierte Systeme ist ihre Reaktivität, das heißt die Möglichkeit, auf bestimmte Eventkonstellationen zu reagieren [vgl. Chakravarthy und Adaikkalavan, 2008, S. 2], [Berstel et al., 2007], [Bry und Eckert, 2006]. Dies ist hauptsächlich in zwei Aspekten zu beobachten [vgl. Schulte et al., 2008]: 52

Abgrenzung der Begriffe „Anwendungssystem“ und „Informationssystem“ siehe Abschnitt 5.1.1.

142


• Integration: Ein verteiltes, heterogenes System bedarf der Integration der beteiligten Anwendungssysteme, um daraus neue Funktionalitäten und Anwendungssysteme zu generieren, die den Anforderungen an Flexibilität genügen (vgl. dazu auch Abschnitt 5.1). Die Kopplung der Systeme kann nachrichtenbasiert erfolgen, das heißt auf Grundlage von Events, die zwischen Anwendungssystemen versandt werden. Die Reaktion eines Systems ist daher von Events anderer Systeme abhängig. Hierbei spielen auch grundlegende Fragen eine Rolle, beispielsweise der Transport und die Verteilung von Events, die auch die technologische Basis für das Monitoring sind. • Monitoring: Die Überwachung von Systemen wird dann schwierig, wenn der jeweilige Hoheitsbereich verlassen wird. Ein wachsender Bedarf an Überwachung besteht auf Grund gesetzlicher, vertraglicher oder operationaler Anforderungen [vgl. Sadiq et al., 2007, S. 149], die allerdings häufig mehrere Hoheitsbereiche abdecken oder über diese hinausgehen. Auch die Anwendungsgebiete hierzu sind unterschiedlich und reichen von expressiver Mustersuche über die Überwachung verteilter Websites bis hin zu aktiver Sicherheit [vgl. Chakravarthy und Adaikkalavan, 2008, S. 1]. Hierfür bedarf es eines generischen Ansatzes, um einen breiten Bereich von Anwendungsgebieten und Domänen abzudecken. Allgemeingültig wurde hierzu die Problemstellung und eine mögliche Lösungsarchitektur erstmals ausführlich in [Luckham, 2002] dargestellt. Den Integrationsaspekt deckt das Thema „ereignisorientierte verteilte Systeme“ im folgenden Abschnitt ab. Monitoring wird im Abschnitt 6.3 „Complex Event Processing“ behandelt.

Fazit Die Ereignisorientierung wird Teil des Referenzmodells. Sie wird in sinnvoller Weise genutzt durch eine zielgerichtete Verwendung und Anpassung (bezogen auf die Zielsetzungen und Anforderungen eines Contact-Centers) innerhalb des Referenzmodells. Die ereignisorientierten Ansätze gliedern dabei nicht nur die folgenden Abschnitte, sie haben auch jeweils ihren dedizierten Einfluss auf das Referenzmodell.

6.2. Ereignisorientierte verteilte Systeme Eine Möglichkeit, der Komplexität und Heterogenität von verteilten Systemen zu begegnen, ist SOA (vgl. Abschnitt 5.1.1). Darüber hinaus gibt es ein weiteres Konzept, die ereignisorientierten verteilten Systeme („Distributed Event-based Systems (DEBS)“), die komplementär zu SOA als Antwort auf die gleichen Anforderungen gelten. Der Fokus dieses Abschnitts liegt deshalb im Schaffen eines Verständnisses für die Zusammenhänge und Funktionsweisen von DEBS sowie auf der Darstellung von Aspekten, die später für CEP wichtig sind.

6.2. Ereignisorientierte verteilte Systeme

143

6.2.1. Grundlagen und Abgrenzung zur Serviceorientierung Als DEBS werden Systeme mit impliziten Aufrufen bezeichnet, die sich aus verteilten funktionalen Komponenten zusammensetzen. Aufrufe von Funktionalitäten sind implizit, da sie nicht direkt aufgerufen werden sondern Reaktionen auf empfangene Events darstellen [vgl. Blanco et al., 2008, S. 221]. Es gibt in einem DEBS folglich mindestens zwei Rollen: Sender und Empfänger von Events, teilweise auch als Konsument und Anbieter von Events bezeichnet [vgl. Mühl et al., 2006, S. 12]. Eine Abgrenzung zu SOA ist hier für das Verständnis hilfreich. In einer SOA erfolgt der Aufruf eines Dienstes explizit, das heißt, der Aufrufer kennt nach (eventuell sogar semantischer) Suche in einem Verzeichnis alle notwendigen Informationen zum Aufruf eines Dienstes. Dies geschieht bei einer Umsetzung mit Web-Services durch die Schnittstellenbeschreibung mittels WSDL. In DEBS erfolgt ein Aufruf von Funktionalität implizit, da sich Sender und Empfänger nicht kennen und Events nicht an eine bestimmte Komponente gerichtet werden [vgl. Mühl et al., 2006, S. 12]. Die Kopplung in beiden Architekturen ist ebenfalls unterschiedlich. Als Kopplung wird das Maß der Abhängigkeit zwischen zwei Kommunikationsentitäten verstanden. Je mehr Regeln in der Kommunikation bestehen oder gegenseitige Annahmen vorhanden sind, desto mehr gilt die Kopplung als „eng“ [vgl. Hohpe, 2006, S. 18]. SOA und DEBS werden beide als lose gekoppelt bezeichnet [vgl. Erl, 2005, S. 37], [Bacon et al., 2008, S. 23]. Das Maß der Abhängigkeit ist bei DEBS jedoch geringer, da die Gegenseite nicht bekannt ist und Regeln (wie bei SOA beispielsweise mit WSDL und SOAP festgelegt) für den Aufruf fehlen. DEBS erlauben so eine Zusammensetzung autonomer und heterogener Komponenten, vor allem dann, wenn es um die Entwicklung eines Anwendungssystems aus einer großen Anzahl funktionaler Komponenten geht [vgl. Blanco et al., 2008, S. 221]. Diese Voraussetzungen sind in Contact-Centern weitestgehend erfüllt, weshalb Anwendungsszenarien für DEBS Teil des Referenzmodells sind. Initiative beim Konsumenten

Initiative beim Anbieter

direkte Adressierung

Request–Reply

Callback

indirekte Adressierung

Anonymes Request–Reply

Event-basiert

Tabelle 5: Interaktionsmodelle im Vergleich [aus Mühl et al., 2006, S. 14] Ermöglicht wird die stark lose Kopplung bei DEBS durch das Event-basierte Interaktionsmodell (zur Unterscheidung vgl. auch Tabelle 5). Die Initiative einer Interaktion geht dabei immer vom Anbieter einer Funktion oder Information (als Empfänger eines Events) aus. Es kommt zu einem Wechsel der Verantwortung vom Sender zum Empfänger:

144


Der Sender eines Events weiß nicht mehr, welche Funktion durch welche Komponente als nächstes aufgerufen wird [vgl. Hohpe, 2006]. Bei SOA hingegen ist der Aufruf nach der Art „Request–Reply“ und geht vom Konsumenten (als „Sender“ des Aufrufs) aus. Lediglich beim Callback geht die Initiative vom Anbieter aus, dann jedoch nur als Antwort auf einen vorherigen Aufruf durch einen Konsumenten. (Callbacks und asynchrone Kommunikation werden in einer SOA entweder durch die Interaktion von BPEL-Prozessen ermöglicht (vgl. Abschnitt 5.3.1) oder für Web-Services durch die Spezifikation WS-Addressing [W3C, 2006b].) Die Ablaufsteuerung in einer SOA liegt auf der Seite des Senders (beispielsweise ein BPEL-Prozess). Das Event-basierte Interaktionsmodell hingegen erlaubt eine klare Trennung der Implementierung von der Kommunikation [vgl. Hohpe, 2006]. Diese Trennung hat zur Folge, dass Planung und Konstruktion (das sogenannte „Engineering“) eines Event-basierten Systems deutlich komplexer werden, was durch Abstraktionsqualität im Engineering und durch Werkzeugunterstützung ausgeglichen werden muss. Bei der Entscheidung, welche Architektur zum Einsatz kommt, muss zwischen Skalierbarkeit und Einfachheit abgewogen werden [vgl. Mühl et al., 2006, S. 17]. Die wesentlichen Punkte einer ausgeprägten ereignisorientierten Architektur können wie folgt zusammengefasst werden [vgl. Hohpe, 2006, S. 18 ff.], [Blanco et al., 2008, S. 222]: • Verbreitende Kommunikation (Broadcasting): Alle Komponenten im System versenden ihre Events grundsätzlich an alle Interessenten. Die Komponente selbst nimmt keine Auswahl von Empfängern vor. Für ein Event können sich mehrere Komponenten interessieren und dieses verarbeiten. Dieses Interesse kann sich dynamisch verändern. • Rechtzeitigkeit und Explizitheit: Events werden zum Zeitpunkt ihres Entstehens versendet. Eine lokale Speicherung oder ein Senden zu einem späteren Zeitpunkt ist nicht vorgesehen. Events werden explizit (und nicht implizit als Seiteneffekt) veröffentlicht. • Asynchronität: Der Sender wartet nicht darauf, dass die Gegenseite ein Event verarbeitet hat. Es findet kein Blocking statt. Die gesamte Kommunikation ist asynchron. • Feingranulare Events: Funktionale Komponenten senden generell Events, so wie sie in den Komponenten auftreten. Eine Aggregation findet meist nicht statt. • Komplexe Events: Für Verarbeitung komplexer Events siehe Abschnitt 6.3.

6.2.2. Architektur und Engineering Die Implementierung von Funktionalität ist in DEBS strikt von der Kommunikation getrennt [vgl. Hohpe, 2006, S. 18 ff.], [Mühl et al., 2006, S. 12]. Daraus ergibt sich eine grundlegende Architektur, wie in Abbildung 60 gezeigt.


145

Abbildung 60: Basisarchitektur eines DEBS [aus Mühl et al., 2006, S. 12] Die zentralen Bestandteile eines DEBS sind die sogenannten Komponenten (nach [Mühl et al., 2006]53 ). Sie beinhalten die fachliche Logik und deren Implementierung. Komponenten können die Rolle eines Senders, eines Empfängers oder auch beide Rollen gleichzeitig einnehmen. Jede Komponente in einem DEBS kann Events mit Hilfe eines NotifikationsServices senden oder empfangen. Der Zugriff auf die Implementierung der Kommunikation ist über diesen Notifikations-Service gekapselt [vgl. Mühl et al., 2006, S. 12]. Es erfolgt kein direkter Zugriff auf die Implementierung der Kommunikationsebene. Die Kommunikation erfolgt nach dem Publish-Subscribe-Paradigma (kurz „pub/sub“). Empfänger bekunden ihr Interesse an bestimmten Events über sogenannte „Subscriptions“ (Abonnements). Wird ein Event veröffentlicht, das dieser Subscription entspricht, so wird es zugestellt. Subscriptions werden über Filter implementiert. Filter können sich auf bestimmte Eventtypen, Themen oder auch auf Attribute und weitere Inhalte von Events beziehen [vgl. Bacon et al., 2008, S. 24]. Ein generisches pub/sub-Interface muss hierfür mindestens folgende Operationen, wie sie Abbildung 61 zeigt, bieten.

Abbildung 61: Generisches pub/sub-Interface [aus Mühl et al., 2006, S. 138] Das pub/sub-Paradigma ist dynamisch: Zur Laufzeit können Empfänger Subscriptions 53

Komponenten im allgemeinen Sinne; nicht zu verwechseln mit spezifischen Ansätzen wie beispielsweise der komponentenbasierten Software-Entwicklung o. Ä.

146


erzeugen (subscribe(Filter)) oder zurückziehen (unsubscribe(Filter)). Sender können im Gegenzug neue Events, die einem bestimmten Filter entsprechen, ankündigen (advertise(Filter)) oder zurückziehen (unadvertise(Filter)) [vgl. Mühl et al., 2006, S. 138]. Das Kommunikationssystem und dessen Implementierung sind durch die Architektur strikt von den Komponenten getrennt. Das Kommunikationssystem ist für den Datentransport, die Verteilung und das Filtern der Events verantwortlich [vgl. Hohpe und Woolf, 2003, S. 57]. Die Implementierung der Kommunikation kann über verschiedene Technologien erfolgen: Direkte Übermittlung von Events („unicast“, beispielsweise auch mittels Request–Reply), Übermittlung an Gruppen („multicast“ wie im IP-Protokoll) oder indirekt (zum Beispiel inhaltsbasiert). Je nach Verteilung der Komponenten und dem gewählten Kommunikationsmedium sind verschiedene Implementierungsstrategien für die Eventverteilung denkbar [vgl. Mühl et al., 2006, S. 169]. Zu unterscheiden ist dabei jedoch immer das Kommunikationsparadigma von der Implementierung der Kommunikation. Obwohl das Kommunikationsparadigma ereignisorientiert ist und dem pub/subParadigma entspricht, kann die darunter liegende technische Verteilung der Events durchaus durch Request–Reply oder technische Multicast-Netzwerk-Protokolle erfolgen. Entscheidend sind funktionale wie nicht-funktionale Anforderungen wie Design- und Performanzüberlegungen, die stark vom jeweiligen Einsatz abhängig sind [vgl. Mühl et al., 2006, S. 17 - 18, 169 ff.]. Neben der Umsetzung des Kommunikationsparadigmas sind die Entwicklung und das Management von DEBS ebenfalls von Interesse. In DEBS führen implizite Aufrufe, die Autonomie von Komponenten und die große Anzahl heterogener Komponenten zu einer fehlenden Kontrolle der Interaktionen im System. Dies erschwert die Entwicklung und das Management von DEBS [vgl. Blanco et al., 2008, S. 221]. Die Lösung zur Wiedererlangung der Kontrolle in DEBS liegt in der Kapselung und im Geheimnisprinzip („information hiding“). Beides wird durch die Sichtbarkeit („Visibility“) von Events, als zentrale Abstraktion, ermöglicht [vgl. Mühl et al., 2006, S. 149], [Blanco et al., 2008, S. 225]. Sichtbarkeit kann umschrieben werden mit Erreichbarkeit. Sind zwei Komponenten gegenseitig „sichtbar“, so werden ihnen abonnierte Events zugestellt. Ist die Sichtbarkeit nicht gegeben, werden Events trotz einer bestehenden Subscription nicht zugestellt. Dadurch besteht eine implizite Koordination. Diese implizite Koordination (anhand von Sichtbarkeit) wird mit expliziter Kontrolle der Sichtbarkeit zu einer expliziten Koordination des DEBS [vgl. Mühl et al., 2006, S. 149 - 151], [Fiege et al., 2006, S. 50 - 51]. Sichtbarkeit gehört in die Ebene der Kommunikation, sie muss von außerhalb der Komponenten ausgeübt werden. Daraus ergibt sich eine dritte Rolle in einem DEBS: der Administrator. Dieser kann eine Person oder auch eine Software-Komponente sein. In der Verantwortung des Administrators liegt die Orchestrierung von Komponenten und deren Management [vgl. Mühl et al., 2006, S. 151]. Die implementierungstechnische Realisierung der Sichtbarkeit erfolgt nach Vorschlägen


147

von [Mühl et al., 2006] und [Fiege et al., 2006] durch sogenannte „Scopes“. Scopes bündeln Sender und Empfänger. Sie limitieren die Sichtbarkeit von Events an angrenzende Komponenten. Der Begriff Scope beschreibt einerseits die Sichtbarkeit von Events und bezeichnet andererseits die Entität, die Sichtbarkeit formt und umsetzt. Nach letzterem Verständnis sind Scopes selbst verteilte Event-basierte Komponenten. Sie enthalten Mechanismen zur Komposition von Komponenten, womit neue, komplexere Komponenten gebildet werden können [vgl. Mühl et al., 2006, S. 152 - 167]. Diese können rekursiv Mitglieder von Scopes höherer Abstraktionsebenen werden (siehe Abbildung 62).

Abbildung 62: Scopes und Komponenten [aus Fiege et al., 2006, S. 50] Da Scopes selbst Komponenten sind, haben sie die gleichen Interfaces zum Empfangen und Senden von Events wie einfache Komponenten. Im Falle von Scopes sind diese Interfaces an die Kanten des Scope-Graphen gebunden (siehe Abbildung 62). Entlang der Graphen gibt es drei Arten der Weiterleitung [vgl. Mühl et al., 2006, S. 165, 177]: • Internal Delivery: Ein Event, das eine Komponente im Scope sendet, wird an alle Mitglieder im Scope gesendet. • Publishing: Veröffentlichte Events von Komponenten eines Scopes werden an den übergeordneten Scope weitergegeben. • Delivery: Events, die von einem Scope von dessen übergeordnetem Scope empfangen werden, werden nach unten weitergegeben. Für die Darstellung von Funktionalitäten in einem DEBS hat die Gestaltung der Weiterleitung entscheidenden Einfluss, ebenso wie die Gestaltung von Scopes. Hierfür kommen für die Rolle des Administrators weitere generische Interfaces zur dynamischen Verwaltung von Scopes hinzu (siehe Abbildung 63). Mittels create(Scope) und destroy(Scope) können Scopes zur Laufzeit erzeugt und zurückgenommen werden. Mit den Operationen join(Component) und leave(Component) werden Komponenten und Scopes dynamisch aufgenommen oder entfernt [vgl. Mühl et al., 2006, S. 159]. Als Antwort auf Anforderungen, wie die Unterstützung von Heterogenität und flexible Anpassungsfähigkeit [vgl. Mühl et al., 2006, S. 132 ff.], ist zusätzlich eine Datentransformation sicherzustellen [vgl. Hohpe und Woolf, 2003, S. 85 ff.]. Events können unterschiedlichsten Typs sein, manchmal sogar unbekannten Typs. Hierfür müssen Interfaces

148


Abbildung 63: Administrations-Interface für Scopes von Sendern und Empfängern um sogenannte Mappings (Übertragungsmechanismen) erweitert werden, die diese Möglichkeiten abdecken [vgl. Mühl et al., 2006, S. 169 ff.]. In einem DEBS wird mit Hilfe der oben genannten Methoden die Funktionalität eines neuen Anwendungssystems durch Kontrolle der Sichtbarkeit dargestellt. Im Entwicklungsprozess erfolgt dabei zunächst die Gestaltung der Komponenten, gefolgt vom Design des Scope-Graphen [vgl. Mühl et al., 2006, S. 182]. In einer SOA geschieht dies zum Vergleich durch die Gestaltung von Diensten und deren Orchestrierung. Eine Darstellung der Workflow-Steuerung in einem DEBS findet sich anhand eines Beispiels im Abschnitt 6.4.2. Berücksichtigung findet DEBS im Referenzmodell in Zusammenhang mit der Workflow-Steuerung und als grundlegende Event-Infrastruktur für das nachfolgend dargestellte Complex-Event-Processing. Fazit Die Tatsache, dass SOA und DEBS komplementär sind, das heißt sich ergänzen und somit auch frei kombinierbar sind, ist eine wesentliche Aussage für das Referenzmodell. Es muss geklärt werden, welches der beiden Paradigmen bestimmend ist (oder wird) und welche Komponenten und Technologien (beider Paradigmen) wo und wie eingesetzt oder kombiniert werden. Unter anderem ist dafür das Verständnis des Unterschieds zwischen dem fachlichen und dem technischen Kommunikationsparadigma (pub/sub) wichtig. Im Referenzmodell kommt es auf das fachliche Paradigma an. Eine technische Umsetzung wird nur insofern berücksichtigt, als dass die Nutzung (Integration) bestehender Technologien und Software-Produkte ermöglicht wird. Das generische pub/sub-Interface bildet die Vorlage für eine entsprechende Service-Schnittstelle. Das Verständnis von Sichtbarkeiten und Scopes wird ebenfalls wichtig für die Abbildung der Paradigmen des CEP.

6.3. Complex Event Processing (CEP) Viele Systeme, ob in der Natur, der menschlichen Soziologie oder in IT-Systemen, funktionieren nach dem Prinzip, etwas wahrzunehmen und darauf zu reagieren. Vor diesem Hintergrund erwägen [Chandy et al., 2007] eine allgemeine und vereinheitlichte „Theorie der Events“. Darin sollen aus allen beteiligten wissenschaftlichen Disziplinen wesentliche Bestandteile zusammengetragen und zu einer gemeinsamen Theorie geformt werden. Ein

6.3. Complex Event Processing (CEP)

149

erster und wesentlicher Schritt hierzu im Bereich der IT ist das CEP, da durch CEP die Möglichkeit geschaffen wird, Events über Systemgrenzen hinweg zu analysieren und daraus wichtige Erkenntnisse abzuleiten. Dabei soll eine komplexe Ereignisverarbeitung beziehungsweise eine Verarbeitung komplexer Ereignisse (die es im Folgenden zu klären gilt) allgemein erarbeitet werden. Für die Umsetzung der Ereignisorientierung sollen statt einer Beschränkung und Implementierung auf jeweils einzelne Domänen oder Anwendungsgebiete allgemeingültige Modelle und Standards entwickelt werden. Hierzu wurde 2008 eigens eine technische Gesellschaft, die „Event Processing Technical Society (EPTS)“, mit dem Ziel „[to] promote understanding and advancement of Event Processing technologies, to assist in the development of Standards to ensure long-term growth, and to provide a cooperative and inclusive environment for communication and learning“ [EPTS, 2008b] gegründet. Im Mittelpunkt steht bei CEP der „Sense“- beziehungsweise Monitoringaspekt. CEP dient dem Aufzeigen von Aktivitäten in einem System, die sich über eine Serie von Abstraktionsebenen ereignen und aus denen sich Rückschlüsse ziehen lassen. CEP selbst ist nicht komplementär zu DEBS. Es ist insofern in DEBS in Ansätzen enthalten, als dass Komponenten auf zusammengesetzte Events reagieren [vgl. Mühl et al., 2006, Kap. 7]. Im Gegenzug liefert DEBS die notwendige Event-Infrastruktur für CEP. 6.3.1. Komplexe Events und ihre Verarbeitung Eventverarbeitung kann in etwa wie folgt zusammengefasst werden: Es ist eine kontinuierliche Verarbeitung von Events in IT-Systemen, wobei Operationen auf Events ausführt werden wie das Lesen, Generieren, Löschen oder Transformieren von Events [vgl. EPTS, 2008a, S. 7]. Diese Art der Verarbeitung lässt sich auf zwei Arten von Events anwenden. Zum einen auf Events nach der hier bereits eingeführten Definition als Repräsentationen von Geschehnissen in IT-Systemen. Diese Art von Events kann man als simple Events bezeichnen [vgl. EPTS, 2008a, S. 10]. Zum anderen lässt sich die Ereignisverarbeitung auch auf sogenannte komplexe Events anwenden. Diese sind Zusammenstellungen anderer Events beziehungsweise Repräsentationen mit Verweis auf diese. Komplexe Events beziehen sich auf eine Kombination (simpler) Events, ihrer sogenannten Mitglieder, die in bestimmten Beziehungen zueinander stehen [vgl. Luckham, 2002, S. 127]. Komplexe Events werden auch als zusammengestellte Events bezeichnet. Für ein komplexes Event gibt es keine direkte 1:1-Beziehung zu einem Ereignis in der realen Welt (eines IT-Systems), das man direkt messen oder wahrnehmen könnte, um daraus ein Event abzuleiten. Es ist vielmehr so, dass bestimmte Kombinationen gewisser Events auf Geschehnisse hindeuten, für die ein komplexes Events erzeugt wird und für die es steht [vgl. Bry und Eckert, 2007, S. 1]. Um ein komplexes Event zu erzeugen, müssen andere Events auftreten und in bestimmter Beziehung zueinander stehen. Die drei hierfür wichtigsten Beziehungen zwischen Events beschreibt [vgl. Luckham, 2002, S. 94 - 95]:

150


• Zeit: Eine zeitliche Reihenfolge zur Anordnung von Events. So kann eine Beziehung zwischen Event A und B darin bestehen, dass Event A vor Event B eintritt. Ausschlaggebend hierfür ist das Zeit-Attribut mit den Besonderheiten der Unterscheidung zwischen Zeitpunkt und -intervall, der Messung und der Granularität (siehe Seite 139). • Kausalität: Als Kausalität wird eine Abhängigkeitsbeziehung zwischen Events bezeichnet. Ein Event B ist abhängig von Event A in dem Sinne, dass Event A eintreten muss, damit Event B eintritt („A verursachte B“). Die Event-Kausalität kann dabei in drei Typen unterschieden werden [vgl. Etzion, 2007, S. 13]: – Explizit: Es besteht eine direkt wahrnehmbare und messbare Abhängigkeit, die immer zwischen zwei Events vorliegt. – Abgeleitet: Die Abhängigkeit zwischen zwei Events ist nicht immer gegeben, sie ist abhängig beispielsweise von bestimmten Attributen. – Implizit: Aus einem Event können implizit weitere Vorgänge (und somit Events) abgeleitet werden, für die jedoch kein reales Event vorliegt. Kausalität beschreibt die horizontale Abhängigkeit von Events auf der gleichen Abstraktionsebene. • Aggregation: Aggregation ist eine Abstraktionsbeziehung. Bezieht sich Event B auf ein Geschehnis, das sich aus der Summe der Events A1, A2, A3, . . . ableitet, so ist B eine Aggregation all dieser Events. Aggregation beschreibt die vertikale Abhängigkeit von Events zwischen zwei Abstraktionsebenen. Aus dem Beziehungstyp der Aggregation lässt sich eine weitere Eigenschaft komplexer Ereignisse ableiten: Sie befinden sich konzeptionell immer auf einer höheren Ebene als ihre Mitglieder [vgl. Luckham, 2002, S. 127]. Dies bedeutet auch, dass es eine EventAbstraktions-Hierarchie gibt (siehe Abbildung 64). Das Event-Hierarchien-Modell besteht aus einer Reihenfolge von Abstraktionsebenen, die von sehr feiner Granularität bis hin zu sehr hohen Aggregationsstufen reichen. Die jeweiligen Abstraktionsebenen bestehen aus den ihnen zugeordneten Eventtypen und aus Regeln. Die Regeln beschreiben die Beziehung zwischen den Events, die ausschlaggebend sind, um ein komplexes Event für die nächst höhere Abstraktionsstufe zu erzeugen. Aus einer sehr großen Anzahl von Events niedriger Granularität entsteht so immer ein überschaubareres Gefüge auf den höheren Aggregationsebenen [vgl. Luckham, 2002, S. 131 - 134], wodurch sich allgemein Generalisierungen, Spezialisierungen oder Delegationen darstellen lassen [vgl. Etzion, 2007, S. 14]. Ein wesentlicher Bestandteil der Regeln sind die sogenannten „Patterns“ (Muster). Patterns beschreiben allgemein eine wiederverwendbare Lösung zu einem Problem, das mehrmals auftritt. Sie sind als Vorlagen zu verstehen, die Entwicklern helfen, neue Instanzen einer konkreten Lösung zu erzeugen [vgl. Alexander et al., 1977]. Bezogen auf Events sind


151

Abbildung 64: Event-Hierarchien-Modell [aus Luckham, 2002, S. 132] Patterns Vorlagen, die auf bestimmte Eventkonstellationen passen [vgl. Luckham, 2002, S. 113]. Mit Hilfe von Event-Patterns lassen sich auch Situationen auf hoher fachlicher Ebene beschreiben [vgl. Schiefer et al., 2007]. Patterns und Regeln werden in einer „Event Processing Language (EPL)“ beschrieben [vgl. EPTS, 2008a, S. 13]. Diese werden teilweise auch als „Event Query Language (EQL)“ bezeichnet [vgl. bspw. Eckert, 2008, S. 17]. Grundsätzlich folgt der Aufbau einer EPL dem Paradigma Event-Condition-Action (ECA), das aus dem Bereich aktiver Datenbanken bekannt ist [vgl. Vossen, 2008, S. 192], [Date, 2004]. Zusammengefasst stellt sich ECA wie folgt dar: ON Event/Pattern IF Condition DO Action Beim Auftreten eines Events oder eines Event-Patterns wird eine Bedingung geprüft (meist ein boolescher Ausdruck). Ist die Bedingung wahr, wird die spezifizierte Aktion ausgelöst. Im Sinne von CEP dienen Aktionen hauptsächlich dem Erzeugen von komplexen Events. Es sind aber auch andere Aktionen denkbar, wie beispielsweise Aufrufe von Diensten oder Zugriffe auf Datenbanken. Zur Verdeutlichung der vorgestellten Zusammenhänge soll nachfolgendes Beispiel dienen.

152


Abbildung 65 zeigt ein fiktives Event-Szenario aus einem Contact-Center. Es veranschaulicht sowohl das Hierarchieverständnis als auch die Idee von Event-Patterns54 .

Abbildung 65: Event-Hierarchie-Beispiel aus einem Contact-Center Auf der niedrigsten Abstraktionsebene (Ebene 1) werden Events aus der Telekommunikationsinfrastruktur angenommen. Dazu zählen eingehende Anrufe von Kunden auf bestimmte Service-Hotlines (Event Anruf(Service, Anrufer)), das Routing eines Anrufs an einen Agenten (Event Routing(Anrufer, Agent)), das Annehmen eines Gesprächs durch einen Agenten (Event Abheben(Agent, Anrufer)) und weitere Events wie beispielsweise das Beenden durch Auflegen (Event Auflegen(Anruf)). Die „normale“ Eventabfolge eines Anrufs bei einem Agenten sieht dabei vereinfacht folgendermaßen aus: Event Anruf gefolgt von Event Routing gefolgt von Event Abheben. Nimmt man die nächste Abstraktionsebene (Ebene 2) als Darstellung von Teilproblematiken, so lassen sich beispielsweise lange Wartezeiten in der Warteschleife oder vorzeitige Abbrüche durch Auflegen des Kunden identifizieren. In Ebene 2 wird dies durch die Events Wartezeit(Service, Zeitraum) und Abbrecher(Service, Zeitraum) dargestellt. Das 54

Das Beispiel ist stark vereinfacht und könnte in diesem Fall aus der Erfahrung vergangener Lastsituationen durch einen Experten definiert worden sein. Die Frage aber, wie Event-Patterns grundsätzlich identifiziert werden können (beispielsweise durch ein Event-Engineering ähnlich dem SoftwareEngineering), liegt außerhalb des Rahmens dieser Arbeit und wird bisher in der Literatur kaum beachtet. Hier besteht weiterer Forschungsbedarf (siehe Abschnitt 10.3.)


153

Event-Pattern einer zu langen Wartezeit lässt sich in etwa wie folgt beschreiben (dargestellt in einer rudimentären ECA-Sprache): ON: Anruf gefolgt von Routing gefolgt von Abheben IF: Abheben.timestamp - Anruf.timestamp >= 3 und Anruf.Anrufer == Routing.Anrufer == Abheben.Anrufer DO: Erzeuge neues Event "Wartezeit" Die Kausalität wird als zeitliche und logische Abfolge der Events durch „gefolgt von“ beschrieben. Sie wird weiterhin abgeleitet aus den Attributen der Events: Zur Gültigkeit eines Patterns muss der Zeitraum zwischen Anruf und Abheben (gemessen an der Differenz der Zeitstempel) mindestens drei Zeiteinheiten betragen und alle drei Events müssen sich auf den gleichen Anrufer beziehen. Das vorzeitige Abbrechen durch Auflegen eines Kunden in der Warteschleife lässt sich ebenfalls als Muster von Events beschreiben: ON: Anruf gefolgt von ABWESENHEIT(Routing) gefolgt von Auflegen IF: Abheben.timestamp - Auflegen.timestamp >= 3 und Anruf.Anrufer == Routing.Anrufer == Auflegen.Anrufer DO: Erzeuge neues Event "Abbrecher" Hierbei wird das Muster noch durch die explizite Abwesenheit eines Events beschrieben. Ein Lastproblem als Aggregation auf Ebene 3 lässt sich wiederum aus Events der Ebene 2 ableiten, wobei dabei das Auftreten bestimmter Events in einem spezifizierten Zeitraum beschrieben wird: ON: Wartezeit oder Abbrecher in Zeitraum von t >= 6 Zeiteinheiten IF: Anzahl von Wartezeit oder Abbrecher >= 3 DO: Erzeuge neues Event "Last-Problem" Die Abstraktionsebenen dieses Beispiels lassen sich beliebig erweitern. Auf Ebene 4 (und höher) ließen sich so Rückschlüsse über anstehende Verletzungen von Service-Level-Vereinbarungen und andere fachliche Situationen beschreiben und hierfür frühzeitig Indikatoren (Events) ableiten, auf die entsprechend reagiert werden kann. Der inhaltliche Zusammenhang ergibt sich rückblickend aus der Aggregation komplexer Events, da diese immer die auslösenden Events (der niedrigeren Abstraktionsebene) enthalten [vgl. EPTS, 2008a, S. 10]. Dadurch lässt sich ein sogenanntes „Drill-Down“ realisieren [vgl. Luckham, 2002, S. 134]. Hierdurch könnte ein Lastproblem auf ein vermehrtes Auftreten von Abbrechern oder Wartezeiten zurückgeführt werden und diese wiederum auf konkrete Anrufsituationen. Insgesamt kann CEP zusammengefasst werden als „[the] (automatable) tasks involved in making sense of all events in a system by deriving higher-level knowledge from lowerlevel events while the events occur, i.e., in a timely, online fashion and permanently“ [vgl. Eckert, 2008, S. 17]. Entscheidend dabei ist, dass es sich um einen kontinuierlichen Prozess handelt, der permanent Events überwacht. Man geht dabei von einer partiellen Ordnung

154


der Events aus, das heißt, es gibt nur eine Teilmenge von Events, die nach den zeitlichen und kausalen Beziehungen vorliegen [vgl. Luckham, 2002, S. 95]. In diesem Zusammenhang kommt eine zweite Bedeutung für das Adjektiv „komplex“ hinzu. Durch die Aggregation und Hierarchisierung von Events und einer großen Anzahl von Events innerhalb von CEP wird auch die Semantik im Sinne von „bedeutungsvoller“, „umfangreicher“ oder auch „komplizierter“ komplexer [vgl. Chakravarthy und Adaikkalavan, 2008, S. 4]. Um der Kompliziertheit zu begegnen, müssen Eventmodelle und -architekturen geschaffen werden, um die Komplexität zu überdecken, umfangreiche Funktionalitäten anzubieten und eine Vielzahl von Anwendungsbereichen abzudecken [vgl. Rozsnyai et al., 2007, S. 63].

6.3.2. Event-Processing-Netzwerke und -Agenten Nach der Definition von CEP bleibt noch die Frage zu klären, welche Komponente oder Komponenten die automatisierte und kontinuierliche Eventverarbeitung übernehmen. Außerdem wird ein grobes CEP-Vorgehensmodell erarbeitet, um ein CEP-Anwendungssystem für ein übergreifendes Monitoring zu erstellen. Die Eventverarbeitung geschieht in Software-Komponenten, den sogenannten Event-Processing-Agenten (EPA oder kurz Agenten) [vgl. EPTS, 2008a, S. 13]. Sie können folgende Aufgaben übernehmen [vgl. Etzion, 2007, S. 26 - 30], [Luckham, 2002, S. 208 ff.]: • Mustererkennung: Das Erkennen von Patterns und das Ausführen von ECA-Regeln stellt die zentrale Aufgabe von Agenten dar. Ergebnis daraus ist die Erzeugung von komplexen Events. • Filterung: Filtern von Events durch zustandslose Agenten. • Routing: Weiterleitung und Verteilung von Events im System. Grundlage für das Routing können Routingtabellen oder Subscriptions sein, ebenso wie ein intelligentes Routing. • Transformation: Übersetzung und Umwandlung von Events, ebenso wie die Aggregation oder das Aufsplitten von Events. • Anreicherung: Anreicherung der Attribute eines Events durch Referenzdaten aus anderen Anwendungssystemen oder Datenbanken. • Adapter: Integration von bestehenden Anwendungssystemen als Provider von Events durch Adapter. CEP-Anwendungssysteme setzen eine Organisation von Agenten in einem Netzwerk auf der Grundlage einer Kommunikationsarchitektur voraus. Die Summe der Agenten und ihre Kommunikationspfade bilden das sogenannte Event-Processing-Netzwerk (EPN) [vgl.


155

EPTS, 2008a, S. 15], [Schulte et al., 2008, S. 2]. Das EPN ist eine implementierungsneutrale Abstraktion aus Sicht des Eventflusses. Jeder Pfad im EPN repräsentiert dabei eine ECA-Regel. Ein Beispiel hierzu zeigt die nachfolgende Abbildung 66.

Abbildung 66: Beispiel eines Event-Processing-Netzwerks Wie ein Agent und seine ECA-Regel-Verarbeitung implementiert sind, ist für das Netzwerk nicht ausschlaggebend. Sie können frei kombiniert werden [vgl. Etzion, 2007, S. 20], [Luckham, 2002, S. 207 - 208]. Der Eventtransport wird durch die Kommunikationsarchitektur abgedeckt und durch die Basistechnologie von DEBS zur Verfügung gestellt. In diesem Zusammenhang stellen Agenten im Sinne von DEBS eine Sonderform von Komponenten dar (vergleiche dazu Abschnitt 6.2). Analog den Scopes und Komponenten eines DEBS lassen sich EPN ebenfalls rekursiv in andere EPN integrieren, das heißt, ein EPN kann als Agent in einem größeren Netzwerk fungieren [vgl. Luckham, 2002, S. 221]. Für den Entwicklungsprozess eines CEP-Anwendungssystems kann ebenfalls die Parallele zu DEBS gezogen werden. Der Engineering-Prozess von DEBS lässt sich auch auf CEP anwenden. Die Zusammenhänge sind hier ähnlich: Agenten als Spezialfall von Komponenten und das Design von Scope-Graphen ähnlich dem Design eines EPN mit Kommunikationspfaden und Hierarchieebenen. Abbildung 67 zeigt hierzu ein grobes Vorgehensmodell für CEP in Anlehnung an das Engineering von DEBS nach [Mühl et al., 2006, S. 182 f.]. In der Designphase muss zunächst auf Agentenebene definiert werden, welche Eventtypen es in welchen Hierarchieebenen gibt. Für die Repräsentation und Sequenzierung der Events sind geeignete Datenmodelle zu finden. Anschließend sind Patterns und ECA-Regeln zu definieren und auf fachliche Anforderungen auszurichten. Dies setzt eine fundierte Anforderungsanalyse voraus. Werden Events aus bestehenden Anwendungssystemen eingebun-

156


Abbildung 67: Grobes CEP-Vorgehensmodell den, ist die Anwendungsintegration zu klären. In der folgenden Phase des EPN-Designs ist die Topologie des Netzes zu spezifizieren. Hierbei werden die Kommunikationspfade zwischen den Agenten definiert und geeignete Implementierungen einer Event-Infrastruktur ausgewählt und Entscheidungen bezüglich der Verarbeitungsparadigmen (siehe folgenden Abschnitt) getroffen. Für das Referenzmodell bedeutet dies, dass die Entscheidungen der ersten beiden DesignPhasen generisch für ein Contact-Center entwickelt werden. Dazu zählt die Spezifikation möglicher Eventtypen, wie sie in Contact-Centern vorkommen. Ähnlich dem Beispiel in Abbildung 65 werden Hierarchieebenen vorgeschlagen und ein EPN zum übergreifenden Monitoring des gesamten Contact-Centers entwickelt und auf das Unternehmens-ProzessModell abgestimmt. Auf Grundlage von Performanzüberlegungen und weiterer Rahmenbedingungen werden für die jeweiligen Hierarchieebenen mögliche Implementierungstechnologien und Datenmodelle vorgeschlagen.

6.3.3. Paradigmen des CEP: Event-Clouds und -Ströme In der Eventverarbeitung lassen sich zwei unterschiedliche Paradigmen differenzieren. Diese sind auf die beiden ursprünglichen Einsatzgebiete der Eventverarbeitung zurückzuführen. Zum einen gab es Entwicklungen aus dem Bereich aktiver Datenbanken, die kontinuierliche Queries (Datenbankabfragen) auf Ströme von Daten anwendeten [bspw. Chakravarthy et al., 1994], [Aggarwal, 2007]. Zum anderen gab es Ansätze der ereignisgetriebenen Simulation verteilter Systemarchitekturen [bspw. Gennart und Luckham, 1992], [Luckham und Vera, 1995]. Beide Strömungen haben zur Entwicklung der zwei Paradigmen der Eventverarbeitung beigetragen und finden sich in den Software-Produkten, die derzeit auf dem Markt sind, mehr oder weniger stark wieder. Dabei entstand eine wissenschaftliche Diskussion über den Inhalt und die Unterschiede beider Paradigmen, auf die hier kurz eingegangen werden soll. Grob kann die Diskussion mit der Frage zusammengefasst werden: Liegen Events in


157

Strömen oder in sogenannten Event-Clouds (Event-Wolken) vor? Als Event-Cloud wird das Resultat vieler Event-generierender Aktivitäten an unterschiedlichen Stellen in ITSystemen verstanden [vgl. Luckham, 2006]. Das heißt eine Event-Cloud ist die Summe aller Events für eine CEP-Applikation. Ein Event-Strom hingegen ist eine linear geordnete Sequenz von Events (meist Event-Tupel [vgl. Rozsnyai et al., 2007, S. 63]), die über den zeitlichen Ablauf geordnet bei einem Agenten eintreffen [vgl. Bass, 2007]. Die Verarbeitung ist entsprechend unterschiedlich: Für das Paradigma der Event-Clouds wird die Verarbeitung mittels komplexer Events und ECA-Regeln angewendet. Darin liegen Events immer nur partiell geordnet vor [vgl. Luckham, 2002, S. 95]. Von einer vertikalen Kausalität („A verursacht B“ beziehungsweise „A ist unabhängig von B“) kann dort nicht grundsätzlich ausgegangen werden [vgl. Luckham, 2006]. Die Verarbeitung von Events in Strömen, das sogenannte „Event Stream Processing (ESP)“, ist auf einen hohen Durchsatz ausgelegt. Dabei steht die Anwendung von Algorithmen und Operatoren auf die Events und Daten im Strom im Vordergrund [vgl. Luckham, 2006]. Anstatt in einem Kontext werden beim ESP Events innerhalb sogenannter „Windows“ verarbeitet [vgl. Chakravarthy und Adaikkalavan, 2008, S. 7]. Ein Window kann dabei beispielsweise ein Zeitfenster („Durchschnittliche Ordersumme aller AktienKauf-Events der letzten 60 Minuten“) oder die Anzahl von Events sein („Kaufsumme der letzten 100 Online-Kauf-Events“). Diese Art der Eventverarbeitung ist wesentlich weniger speicher- und verarbeitungsintensiv und daher wesentlich performanter als die Verarbeitung komplexer Events [vgl. Luckham, 2006]. Dies wird beispielsweise durch die Arbeit von [Kulkarni et al., 2008] noch optimiert, um Datenverluste auf Grund von Performanz zu vermeiden [vgl. auch Khorlin und Chandy, 2006]. ESP-Sprachen sind auf Grund der historischen Verankerung im Datenbankumfeld meist SQL-ähnlich, da SQL unter Entwicklern weithin bekannt ist. Das folgende Statement ist in der SQL-ähnlichen ESP-Abfrage-Sprache CCL der Firma Coral8 geschrieben [vgl. CCL, 2009]. Es ist eine vereinfachte Lösungsbeschreibung der Aggregation der (hier nur) vorzeitigen Abbrüche (zur Anzeige eines Lastproblems) aus dem Beispiel der Abbildung 65. INSERT INTO LastProblemStream SELECT A.Service, COUNT(A.Service) FROM Abbrecher AS A KEEP 6 seconds GROUP BY A.Service HAVING COUNT(A.Service) >= 3; Die Events des Typs Abbrecher werden in einem Strom an einen ESP-Agenten übermittelt. Darin werden die Events gezählt (COUNT(A.Service)), die in einem mitlaufenden Zeitfenster von 6 Sekunden ankommen (KEEP 6 seconds) und sich auf den gleichen Service beziehen (GROUP BY A.Service). Ein Lastproblem wird als Event in einen neuen Strom (INSERT INTO LastProblemStream) geschrieben, sobald im Zeitfenster mehr als drei Events gezählt werden (HAVING COUNT(A.Service) >= 3).

158


Aus Sicht der EPN-Architektur stellt ein Strom eine einzelne Kante (Pfad) im EPN dar. Eine Event-Cloud hingegen ist die Summe aller eingehenden Kanten zu einem Agenten. ESP kann somit als Spezialfall einer Event-Cloud betrachtet werden. Beide zusammen, ESP und die Verarbeitung komplexer Events über Eventhierarchien, bilden das CEP [vgl. Bry und Eckert, 2007, S. 1], [Etzion, 2007, S. 22]. Beide erlauben das Monitoring, die Steuerung und die Optimierung von Prozessen [Chakravarthy und Adaikkalavan, 2008, S. 8]. Dies ist auch für die Entwicklung des Referenzmodells von Bedeutung. Hier müssen für die unterschiedlichen Event-Quellen (beziehungsweise Hierarchieebenen) in einem Contact-Center die geeigneten Paradigmen zugeordnet werden. Wie beide Paradigmen kombiniert werden können, stellt Abbildung 68 als beispielhafte Möglichkeit dar.

Abbildung 68: CEP-Integrationsmodell [aus Chakravarthy und Adaikkalavan, 2008, S. 9] Den Vorteilen von ESP steht eine größere Bandbreite fachlicher Problemstellungen gegenüber, die sich besser (oder ausschließlich) mit Hilfe komplexer Events und ECA-Regeln abbilden lassen, da komplizierte Muster über eine große Anzahl möglicher Events untersucht werden können [vgl. Bass, 2007]. In dem von [Chakravarthy und Adaikkalavan, 2008] entwickelten Modell (Abbildung 68) werden über vier Stufen beide Paradigmen kombiniert. In der ersten Stufe wird ESP angewendet, um die meist sehr große Anzahl von Events zu verarbeiten. Niedrige Abstraktionsebenen decken meist technische Ebenen ab, in denen es zu einer starken Eventlast kommt (beispielsweise ein IP-Netzwerk). In Stufe zwei werden die Ströme weiter verdichtet. In


159

den Stufen drei und vier beginnt die Verarbeitung komplexer Events mit Hilfe von ECARegeln. In einem EPN nach diesem Vorbild lassen sich die Vorteile beider Paradigmen vereinen. Eine ähnliche Vorgehensweise ist auch auf die Situation in Contact-Centern anwendbar, da hier in den Bereichen der Netzwerk- und Telekommunikations-Infrastruktur eine große Anzahl an Events verarbeitet werden muss. Auf fachlicher Ebene geht es jedoch um die Abbildung komplizierter Vertragsgestaltungen (Service-Level-Vereinbarungen) für das Monitoring.

6.3.4. Aktueller Diskussionsstand Für die Darstellung und Sequenzierung von Events gibt es derzeit kaum einen Standard. Aus den Teilen der OASIS-Spezifikation zum Management verteilter SoftwareKomponenten mittels Web-Services („Web Services Distributed Management: Management Using Web Services (MUWS)“) [spezifiziert in OASIS, 2006a,b] kann das EventFormat verwendet werden. Zur Beschreibung der Situation, für die das Event erzeugt wird, ist das Event-Format frei erweiterbar, es dient (ähnlich einer SOAP-Nachricht) als Klammer für allgemeine Event-Daten zum Transport der eigentlichen Beschreibung. Für die Beschreibung von Klassen von Situationen gibt es noch keinen offiziellen Standard. MUWS entstand unter dem Einfluss einer Spezifikation der Firma IBM, die ein „Common Base Event (CBE)“ definieren [vgl. IBM, 2004, Anhang A], [Ogle et al., 2004]. Aus CBE wurden große Teile für MUWS verwendet. CBE selbst ist eine proprietäre Spezifikation. Im Bereich der EPL gibt es ebenfalls keine standardisierten ECA- oder ESP-Sprachen [vgl. Ammon et al., 2008]. Die meisten Sprachen sind proprietär und entstammen den relevanten CEP-Systemen55 . Einen Vorschlag zur Erweiterung der XML-basierten RegelBeschreibungs-Sprache RuleML [vgl. RuleML, 2009] zur sogenannten „Reaction RuleML“ liefern [Paschke et al., 2007]. Darin sollen ECA-Regeln in XML dargestellt werden. Darüber hinaus gibt es eine Reihe wissenschaftlicher CEP-Prototypen, die ebenfalls eigene Sprachen definieren56 . Für die Semantik einer ECA-Sprache wurden folgende allgemeine Operatoren abgeleitet, die zur Beschreibung von Patterns mindestens notwendig sind [vgl. Mühl et al., 2006, S. 238]: • Atom: Ein individuelles Event • Negation: Alle außer ein negiertes Event 55

Beispielsweise Aleri (www.aleri.com), Amit (IBM Active Middleware Technology, www.haifa.il.ibm.com/dept/services/soms_ebs.html), Coral8 (www.coral8.com), Esper (esper.codehaus.org), RuleCore (www.rulecore.com) oder Streambase (www.streambase.com) 56 Beispielsweise XChangeEQ [in Eckert, 2008], CEP-System mit RFID-Readings [in Wu et al., 2006], SASE [in Gyllstrom et al., 2007] und weitere mehr.

160


• Verkettung: Eine Folge von Events (Event A „schwach gefolgt“ von Event B) ohne Berücksichtigung einer Reihenfolge • Sequenz: Eine Folge von Events (Event A „stark gefolgt“ von Event B) mit Berücksichtigung einer Reihenfolge (Events folgen nacheinander) • Iteration: Abbildung einer Kausalität • Alternation: Nur das eine oder nur das andere Event (exklusives Oder) • Parallelität: Das eine oder das andere oder beide Events (Oder) • Timing: Kombination von Events mit Zeit und Zeitgebern (Timer) Der hohe Durchsatz von Events in einem Agenten oder EPN führt zu entsprechenden Performanzanforderungen. Hierfür wurden Benchmarks durchgeführt und Metriken entwickelt. [White et al., 2008] führten beispielsweise ein Benchmark durch, bei dem durch einen Agenten über eine Million Events in der Sekunde erfolgreich bewältigt wurden. Allgemeine Metriken für CEP-Benchmarks entwickelt beispielsweise [Bizarro, 2007]. Für die Umsetzung einer EPN-Infrastruktur liegen mit den Standards der WS-NotificationFamilie und der Spezifikation WS-Eventing zwei Möglichkeiten vor. WS-Notification und WS-Eventing verbinden CEP beziehungsweise DEBS mit dem Bereich SOA, da sie das pub/sub-Paradigma von DEBS mit Hilfe von Web-Services spezifizieren. WS-Eventing beschreibt hier ein Protokoll, das es Web-Services erlaubt, Events anderer Web-Services zu abonnieren oder selbst als Event-Provider Subscriptions entgegenzunehmen [vgl. Box et al., 2006]. Ein Event-Format wird dabei nicht festgelegt, da alle Arten von XMLDokumenten als Event verwendet werden können [vgl. Box et al., 2006, Kap. 4]. WSNotification besteht aus drei Spezifikationen: WS-BaseNotification spezifiziert einen Nachrichtenaustausch zwischen Web-Services, die gegenseitig als Service-Provider auftreten und eine direkte Event-Verbindung aufbauen [vgl. OASIS, 2006c]. WS-BrokeredNotification definiert das Web-Service-Interface für einen Event-Broker [vgl. OASIS, 2006d] und WS-Topics definiert einen Mechanismus zur Organisation und Kategorisierung von Interessensgebieten für Subscriptions anhand sogenannter Topics [vgl. OASIS, 2006e]. Der Standard „XML Events“ definiert ebenfalls Event-Listener, ist jedoch für CEP und DEBS kaum geeignet, da er sich auf ein sehr eingeschränktes Gebiet im Bereich von Events in Websites bezieht [vgl. W3C, 2003]. Über die Infrastruktur hinaus bemüht sich die EP-TS um Entwicklung von Referenzmodellen im Bereich des CEP [vgl. EPTS, 2008b]. Weitere Bemühungen bestehen in der Vereinigung der Paradigmen des ESP und der ECA-Regeln in den Implementierungen der jeweiligen CEP-Software-Produkte [vgl. Luckham, 2006]. Weitergehende Forschung im Bereich des Unsicherheitsprinzips in der Eventverarbeitung [vgl. Luckham, 2002, S. 110] betreibt beispielsweise [Wasserkrug et al., 2006]. Die automatisierte Entdeckung unbekannter Event-Patterns mit Hilfe statistischer Methoden im Bereich Banking untersuchen [Widder et al., 2007].

6.4. Eventverarbeitung und Geschäftsprozessmanagement

161

Der Anteil der vorliegenden Arbeit an der Weiterentwicklung von CEP besteht in der Entwicklung eines Referenzmodells für Contact-Center. Dabei wird das CEP, insbesondere durch die Ausgestaltung von EPA und einer EPN-Architektur, an die besonderen fachlichen Anforderungen und technischen Besonderheiten eines Contact-Centers angepasst. Das Management der Eventverarbeitung wird in das integrierte Managementkonzept des Geschäftsprozessmanagements aufgenommen. Der Fokus liegt dabei auf dem Einsatz von CEP im Geschäftsprozessmanagement, insbesondere im Bereich der Prozessautomatisierung und -steuerung, wodurch ein weiterer und enger Schulterschluss mit SOA erfolgt.

Fazit Entscheidend für das Referenzmodell ist das Prinzip (die Idee, das Konzept) der komplexen Event-Verarbeitung und deren grundsätzliche Anwendbarkeit auf ContactCenter. Es werden keine konkreten ECA-Regeln oder Patterns definiert (nur in Beispielen), dafür gibt es weder eine verbindliche EPL noch entspricht es dem Anspruch des Referenzmodells (und seiner gewählten Detailtiefe). Der Fokus der Modellbildung liegt in der Nutzbarmachung der Technologien des CEP für die Belange von Contact-Centern. Hierzu müssen die notwendigen EPA und ihre Einsatzgebiete spezifiziert werden. Dazu gehört auch eine Untersuchung benötigter Event-Klassen. Insgesamt muss das Referenzmodell alle benötigten Komponenten (Infrastruktur und EPA) spezifizieren und ein für Contact-Center sinnvolles EPN entwerfen. Das CEP muss mit den Technologien des DEBS und von SOA abgestimmt (genauer: darin eingebunden) werden.

6.4. Eventverarbeitung und Geschäftsprozessmanagement Die Eventverarbeitung hat mindestens zwei Ansatzpunkte im Geschäftsprozessmanagement, die direkt von ihr beeinflusst werden: Die Geschäftsprozessautomatisierung im Bereich Workflow-Steuerung und -Überwachung sowie das Geschäftsprozesscontrolling, dort vor allem das Business-Activity-Monitoring und die Reaktivität von Geschäftsprozessen.

6.4.1. Business-Activity-Monitoring (BAM) Die Überwachung von Geschäftsprozessen und das Aufdecken bestehender oder zukünftig relevanter Situationen (positiv nutzbare Situationen oder Problemzustände) im Geschäftsbetrieb werden als Business-Activity-Monitoring verstanden, wenn sie (nahezu) in Echtzeit stattfinden und auf Events beruhen [vgl. bspw. Schulte, 2008, S. 4], [vgl. Jobst und Preissler, 2006], [Greiner et al., 2006]. Der BAM-Begriff ist in der Literatur nicht trennscharf abgegrenzt. BAM kann als Teilgebiet des Business-Intelligence angesehen werden. Business-Intelligence bildet hierzu den Ordnungsrahmen eines IT-basierten Gesamtansatzes [vgl. Kemper et al., 2006, S. 10 ff.], in den sich BAM als der Real-Time-Aspekt einer gesamten BI-Lösung einordnen lässt.

162


BAM ist eine Online-Überwachung des Geschäftsbetriebs. In einer Prozessorganisation ist der Geschäftsbetrieb in Geschäftsprozessen dargelegt (vgl. Abschnitt 4.1.3), wodurch BAM hauptsächlich eine Überwachung der Geschäftsprozesse ist. [McCoy, 2007] unterscheidet hier vier Ebenen: 1. Instanzebene: Monitoring individueller Prozessinstanzen (konkreter Vorgang eines konkreten Kunden) 2. Typ- und Klassenebene: Monitoring von Geschäftsprozesstypen (alle laufenden Instanzen eines Geschäftsprozesstyps, zum Beispiel alle laufenden Bestellungen) bis hin zu Geschäftsprozessklassen (alle laufenden Kern- oder Unterstützungsprozesse) 3. Historie: Erweiterung um die Dimension Zeit (rückblickend) zur Darstellung von Trends und Anomalien 4. Externe Einflüsse: Monitoring relevanter externer Events mit Einfluss auf einzelne Geschäftsprozesse beziehungsweise auf den gesamten Geschäftsbetrieb Die ersten beiden Ebenen lassen sich meist durch den Funktionsumfang von WorkflowEngines abdecken. Für historische Auswertungen werden häufig BI-Lösungen (vgl. auch Abschnitt 2.3.1) eingesetzt. Spätestens bei der Überwachung externer Einflüsse ist eine CEP-basierte Lösung hilfreich. Diese ist auch angezeigt, sobald System- und Hoheitsgrenzen überschritten werden. Die Kennzahlenbildung und Service-Level-Überwachung im Bereich des Geschäftsprozesscontrollings erfordert dabei eine entsprechende EPN-Architektur, in der alle notwendigen Events über ein angemessenes Abstraktionsmodell über komplexe Events aggregiert werden (siehe Beispiel in Abbildung 65). Im Referenzmodell dieser Arbeit wird eine entsprechende EPN-Architektur für ContactCenter erarbeitet, wobei die Besonderheiten der dortigen Geschäftsprozesse (hoher Anteil an Interaktion über die Telekommunikationsinfrastruktur) entsprechend berücksichtigt werden. So lassen sich mit Hilfe der Ereignisverarbeitung die Kennzahlen und alle Service-Level-Vereinbarungen gesamthaft überwachen, die bei der vorherrschenden Systemarchitektur mehrere Systemgrenzen (Telefonanlage, Routing, Sprachportale, Workflow und weitere) umfassen. CEP-relevante Events auf fachlicher Ebene ergeben sich aus dem Unternehmensprozessmodell, sofern sie dort berücksichtigt wurden. Die Geschäftsprozesse eines Contact-Centers müssen entsprechend modelliert und Konventionen hierfür festgesetzt werden. Grundlage für die Modellierung von Events bilden die jeweiligen Modellierungssprachen. Abbildung 69 stellt hierzu das Event-Modell der bereits eingeführten Modellierungssprachen EPK und BPMN gegenüber. In EPK gibt es ein Symbol für Ereignisse. Damit lassen sich Ereigniskonstellationen in einem Geschäftsprozesskontext darstellen. Ähnlich ist dies in BPMN-Modellen. Auf Grund


163

Abbildung 69: Event-Modellierung in BPMN und ARIS EPK des dort technischeren Fokus werden zusätzlich Events für die Prozesssteuerung unterschieden (technische Fehlersituationen, Abbrüche und so weiter). In BPMN eignen sich die Multiple-Events für die Modellierung fachlicher Ereignissituationen. Die Situationen, die so in einem Geschäftsprozess durch Ereignis- beziehungsweise Event-Symbole dargestellt werden, bieten sich an, um daraus Events zu erzeugen und in einer prozessspezifischen Abstraktionsstufe zu verarbeiten. Neben komplexen Events der darunter liegenden Ebenen bilden die Prozess-Events eine weitere Event-Quelle im EPN. Damit ist auch die Grundlage geschaffen, Geschäftsprozesse auf komplexe Events reagieren zu lassen. Die notwendigen Event-Patterns beschreiben dann entsprechende fachliche Situationen im Geschäftsbetrieb, auf die in besonderer Weise reagiert werden soll. Die Komponenten einer SOA (einzelne Service oder Prozesse, die über eine Service-Schnittstelle aufgerufen werden) müssen auf solche Event-Patterns reagieren [vgl. Melzer, 2007, S. 10], [Chappell, 2006, S. 10]. CEP ermöglicht so ein übergreifendes Monitoring des gesamten Geschäftsbetriebs, wobei sich die Qualität und Geschwindigkeit der Entscheidungen erhöhen und gleichzeitig Datenmengen und Kosten reduziert werden können [vgl. Schulte, 2008]. 6.4.2. Workflow-Steuerung Bei der Workflow-Steuerung geht es um die Steuerung des automatisierten Prozessablaufs. Die Workflow-Steuerung in einer serviceorientierten Architektur wurde bereits am konkreten Beispiel von BPEL vorgestellt (vgl. Abschnitt 5.3.1). Eine Event-basierte Workflow-

164


Steuerung in einem DEBS ist ebenfalls möglich. Dies lässt sich mit Hilfe von „ereignisgesteuerten Prozessketten“, den EPK, verdeutlichen. Als Beispiel ist die EPK aus Abbildung 69 ausreichend. Für einen korrekten Prozessablauf müssen „Funktion 1“ und „Funktion n“ nacheinander ausgeführt werden. Beide sind jeweils über eine Kante mit einem Ereignis oberhalb verbunden. Befinden sich diese Ereignisse als Events in einem EPN, würden für die WorkflowSteuerung zwei ECA-Patterns ausreichen: ON Start-Event IF ... DO Funktion 1 ausführen

ON Intermediate-Event IF ... DO Funktion n ausführen

Die erfolgreiche Ausführung der „Funktion 1“ löst das Event „Intermediate-Event“ aus. Ähnliche ECA-Patterns lassen sich auch für andere Situationen darstellen. In Fehler-, Abbruch- oder Kompensationsfällen lassen sich die entsprechenden Mechanismen Eventbasiert aufrufen. Dies bedeutet, dass in einem DEBS die Logik der Prozessausführung nicht mehr in einem Workflow-Modell liegt, sondern in Komponenten (analog [Mühl et al., 2006], ebenso Scopes) und zugehörige ECA-Patterns „aufgebrochen“ wird. Welche Auswirkungen dies auf die einzelnen Bestandteile hat, wird im Referenzmodell dieser Arbeit ausführlich besprochen.

6.4.3. Bestehende Referenzmodelle SOA, DEBS und CEP sind bisher jeweils für sich behandelt worden. SOA und DEBS wurden dabei als komplementäre Architekturkonzepte dargestellt, die gegenseitig austauschbar sind. Sie können auch als orthogonal betrachtet werden, das heißt, sie sind frei kombinierbar, einschließlich CEP. In diesem Sinne entwickeln [Ammon et al., 2008] ein konzeptionelles Referenzmodell eines „event-driven BPM (EDBPM)“, wobei BPM (im Sinne eines Workflow-Managements) und CEP miteinander kombiniert werden (siehe Abbildung 70). Das Referenzmodell nach [Ammon et al., 2008] umfasst zwei Modellierungsebenen: In der Designphase werden Workflow-Modelle erstellt. Darauf aufbauend wird ein Event-Modell erstellt, das Prozess-Events und entsprechende Patterns zur Überwachung relevanter Situationen beinhaltet. Während der Laufzeit werden im Sinne von BAM die WorkflowModelle anhand von Events überwacht und Kennzahlen sowie Situationen in einem sogenannten „Enterprise Cockpit“ grafisch dargestellt. Hierbei werden zwei Spezialistenrollen und ihre Aufgabenfelder identifiziert: Prozess-Modellierer und Event-Modellierer. Das oben dargestellte Referenzmodell trennt dabei zwischen einer „konventionellen“ Workflow-Steuerung und der Ereignisverarbeitung für das Monitoring. Die Workflow-Steuerung erfolgt technisch nicht Event-gesteuert sondern auf Grundlage von Workflow-Modellen (beispielsweise BPEL). Events werden im Rahmen des Business-Activity-Monitorings zur


165

Abbildung 70: EDBPM-Referenzmodell [nach Ammon et al., 2008] Prozessüberwachung verarbeitet. Auf ähnlicher Grundlage gibt es weitere Anwendungsfälle und prototypische Realisierungen, beispielsweise durch [Greiner et al., 2006], [Michlmayr et al., 2008] und [Moser et al., 2008]. [Adi et al., 2006] wenden CEP auf Finanzdienstleistungen an. Mit EDBPM besteht starke inhaltliche Nähe zu SOA und deren Event-Orientierung. [Luckham, 2007, S. 8] bezeichnet die Kombination beider als Event-getriebene Architektur: „An event driven architecture (EDA) is a SOA in which all communication is by events and all services are reactive event processes (i.e., react to input events and produce output events)“. Zwei Unterschiede lassen sich hier zwischen SOA und einer EDA ausmachen: 1. Der Serviceaufruf findet nicht mehr nach dem Find–Bind–Execute-Prinzip statt (Komponenten in DEBS sind unabhängig vom Aufrufer und reagieren nur auf Events). 2. Die Workflow-Steuerung erfolgt nicht mehr in einer Zustandsmaschine nach einem Workflow-Modell sondern muss Event-orientiert umgesetzt werden. In diesen Punkten unterscheiden sich die Referenzmodelle nach dem Beispiel von [Ammon et al., 2008] von der EDA-Vision von [Luckham, 2007]. Diese beiden Punkte aus dem Blickwinkel der Geschäftsprozessautomatisierung in ein Event-basiertes Modell zu überführen, ist ein wichtiger Bestandteil des Referenzmodells dieser Arbeit und wird im folgenden dritten Teil entwickelt. Fazit Sinnvolle Anwendungsgebiete für die Komponentenbildung (EPA) wurden im Zusammenhang mit dem Geschäftsprozessmanagement, als Methode der Prozessorientierung, identifiziert, wodurch die Workflow-Steuerung und das BAM zu den entscheiden-

166


den Anwendungsgebieten für das Referenzmodell werden. Die Diskussion zu bestehenden Referenzmodellen, insbesondere die Abweichungen von einer EDA-Vision, machen einen zusätzlichen Handlungsbedarf klar: Ein EDA soll vorweggenommen und in seinen Minimalanforderungen konstruiert werden. Dies geschieht aus dem Verständnis heraus, dass die in der Vision einer EDA implizit oder explizit erwähnten Ansprüche und Funktionalitäten vereinzelt bereits in SOA, DEBS und CEP behandelt werden. Es liegt die Vermutung nahe, dass eine EDA aus bestehenden Mitteln und Standards konstruiert werden kann. Es soll dabei keine Alternative auf gleichem Anspruchsniveau entstehen, wie beispielsweise das Vorhaben der EP-TS eine Referenzarchitektur abbilden möchte, sondern eine jetzt realisierbare Version für Contact-Center.

167

Teil III. Referenzmodell: Anwendung der Service- und Ereignisorientierung im Contact-Center In der Theorie sind Theorie und Praxis gleich. (anonym) Für das Können gibt es nur einen Beweis: das Tun. (Marie von Ebner-Eschenbach)

7. Handlungsfelder und Neuansatz In den vorangegangenen Kapiteln wurden die Grundlagen dargestellt, die für die Entwicklung eines innovativen Referenzmodells für die Automatisierung und Überwachung von Geschäftsprozessen in Contact-Centern notwendig sind. Die Unternehmensform „ContactCenter“ und die wirtschaftlichen Rahmenbedingungen, in denen sich Contact-Center befinden, allen voran die Kundenorientierung und Industrialisierung, wurden in Teil I vorgestellt. Teil II erarbeitete die drei Themengebiete Geschäftsprozessmanagement, Serviceorientierung und Ereignisorientierung jeweils einzeln, die hier in Teil III zu einem neuen Referenzmodell mit innovativen Ansätzen für Contact-Center kombiniert und angepasst werden. In diesem Kapitel werden die Handlungsfelder und der Neuansatz dieser Arbeit dargestellt. Bei der Erarbeitung des Referenzmodells werden zunächst die Aspekte der Serviceorientierung und des Geschäftsprozessmanagements behandelt, da sie die wesentliche Grundlage des Referenzmodells bilden. Darauf aufbauend wird das Referenzmodell um den Themenbereich der Ereignisorientierung ergänzt. Dabei wird zwischen den Kapiteln 8 (Serviceorientierung) und 9 (Ereignisorientierung) unterschieden. Abschließend gibt Kapitel 10 eine Zusammenfassung und einen Ausblick.


168

7. Handlungsfelder und Neuansatz

7.1. Bewertung des Status quo Vor der Einführung neuer Themen ist eine Analyse des Istzustands sinnvoll. Hierzu wird der in den Teilen I und II vorgestellte Status quo bewertet und um die Erfahrungen aus einem konkreten Praxisprojekt ergänzt.

7.1.1. Contact-Center-Praxis Einen Überblick über den Istzustand der Praxis zu geben, ist aus Quellen der Literatur alleine nur schwer möglich. Nachfolgende Zusammenfassung ist deshalb stark geprägt von Erfahrungen aus Untersuchungen der Prozesslandschaft eines Contact-CenterDienstleisters innerhalb eines großen deutschen Konzerns. Basis der Darstellung bildet ein Unternehmensprozessmodell, das die Geschäftsprozesse eines Contact-Center-Dienstleisters im Versandhandel darstellt. Dabei wurden die Geschäftsprozesse des größten Mandanten im ersten Halbjahr 2007 durch insgesamt zwölf Modellierer in zahlreichen Interviews und Workshops aufgenommen und aus diesen Informationen detaillierte Modelle erstellt. Die Ergebnisse sind nicht öffentlich, da sie alle Kernprozesse des Unternehmens in der Tiefe darstellen. Der Verweis auf die Ergebnisse erfolgt deshalb anonymisiert, als Quelle wird hierfür [Contact-Group, 2007] angegeben. Neben den schriftlich und elektronisch festgehaltenen Ergebnissen fließen außerdem Erfahrungen aus den einzelnen Phasen des Projekts zur Prozessaufnahme sowie aus den anschließend durchgeführten technischen Optimierungs- und Umsetzungsprojekten mit ein. Die Strukturen und Prozesse von Contact-Centern sind nicht identisch. Allerdings können auf Grund der klaren Aufgabenstellung eines Contact-Centers und der überall vorhandenen gleichartigen Telekommunikationstechnologie die Ergebnisse trotzdem als repräsentativ angesehen werden. Zusammen mit Erkenntnissen aus der Literatur erscheinen sie ausreichend genug, um daraus Verbesserungspotentiale abzuleiten und mittels eines Referenzmodells Lösungen zu erarbeiten. Die wichtigsten Größen aus [Contact-Group, 2007] lassen sich folgendermaßen zusammenfassen: Insgesamt wurden 119 Geschäftsprozesse identifiziert und modelliert. Diese enthalten Hinterlegungen zu 723 verfeinerten Prozessmodellen. In den detaillierten Prozessmodellen werden die Prozesse durch folgende Objekttypen genauer beschrieben57 : 8809 Ereignisse, 9421 Funktionen, 122 Anwendungssysteme, 46 Betriebsmittel, 11 verschiedene dokumentierte Wissensobjekte, 64 Fachbegriffe, 477 Informationsträger, 561 Bildschirmmasken, 6088 Regeln (Verknüpfungen) und 58 unterschiedliche Stellen. 57

Die Zahlen beziehen sich auf unterschiedliche Ausprägungen der jeweiligen Objekte.

7.1. Bewertung des Status quo

169

Neben Literatur- und Erfahrungsberichten lassen sich, ergänzt durch die Analyse des Prozessmodells der [Contact-Group, 2007] und der dazu oben genannten Modellobjekte, folgende Charakteristika der Istsituation zusammenfassen: • Kundenorientierung nicht methodisch unterstützt: Die in Kapitel 3 ausführlich erarbeitete Kundenorientierung wird trotz des direkten und unmittelbaren Kontakts zum Endkunden nicht ausreichend methodisch unterstützt und/oder nicht direkt verfolgt. Der Kundenwunsch als zentraler Managementgegenstand wird nicht wie im Rahmen der Geschäftsprozessdefinition betrachtet. Entsprechend ist auch das Geschäftsprozessmanagement als Methode wenig ausgeprägt, eine Ausbildung der Prozessorganisation wird nicht im notwendigen Umfang verfolgt. • Unterschiedliche Prozessdomänen, organisatorische Trennung und verschiedene Prozesssemantiken: Aus der historischen Entwicklung von Contact-Centern sind im Zusammenhang mit den für die Kundenorientierung wesentlichen Bereichen Fachlichkeit und Kontaktkanäle zwei Prozessdomänen entstanden: Fachprozesse und Kommunikationsprozesse. Die fachlichen Abläufe (Fachprozesse) im direkten Kontakt der Agenten mit den Kunden werden durch die Fachabteilungen der Mandanten und durch zugeordnete Spezialisten im Contact-Center definiert. Dies geschieht selten durch die Modellierung strukturierter Prozessabläufe, noch seltener folgen sie einem einheitlichen Prozessmodell des Contact-Centers, wodurch aus dieser Perspektive eine strukturierte und übergreifende Prozessoptimierung erschwert wird. Die technischen Abläufe der Kontaktverteilung werden in sogenannten Kommunikationsprozessen implementiert. Diese liegen in der Hand von techniknahen, internen Abteilungen. Für die Darstellung der Berührungspunkte (Schnittstellen zwischen beiden Prozessdomänen) und des Gesamtablaufs (auch des optimierten) fehlen eine einheitliche Notation und eine einheitliche Prozesssemantik. Erschwert wird diese „semantische Lücke“ noch durch die organisatorische Trennung in unterschiedliche Abteilungen. Eine Ende-zu-EndeBetrachtung mit Hilfe von Geschäftsprozessen ist noch nicht gegeben, entsprechend fehlt die Dimension der Geschäftsprozesse auch bei der Prozessautomatisierung sowie beim Controlling und der Steuerung. • Volatilität erschwert Prozessautomatisierung: Zusätzlich wird die Prozessautomatisierung erschwert durch den Umstand, dass im direkten Kundenkontakt eine Bindung an einen starren Prozessablauf kaum möglich ist. Kunden beeinflussen, solange sie direkt am Telefon sind, dynamisch den Ablauf, indem sie ihre ursprünglich getätigten Wunschäußerungen ändern oder präzisieren, wodurch der Ablauf sich an jeder Stelle ändern kann. Dieser Umstand wird im Folgenden als „Volatilität“ bezeichnet. Die Folge davon sind sehr große und umfangreiche Prozessmodelle, sofern alle Eventualitäten abgebildet werden. Die Prozessautomatisierung wird dadurch erschwert und verkompliziert. Möglichkeiten der Ereignisorientierung, dem zu begegnen, werden weder durch entsprechende Branchen-Software abgedeckt, noch fachlich

170

7. Handlungsfelder und Neuansatz in Erwägung gezogen.

• Multikanal-Management und Heterogenität der Systemlandschaft erhöhen die Komplexität: Die Herausforderungen der heterogenen IT-Landschaft (Abschnitt 2.3.2) und die sich daraus ergebenden Schnittstellenprobleme und Medienbrüche führen zu einer Zunahme der Komplexität. SOA als Methodik und Architekturparadigma wird nicht oder nur teilweise genutzt, um der Komplexität zu begegnen. Umsetzende Technologien, wie beispielsweise Web-Services, werden nur zur Punkt-zuPunkt-Integration verwendet. Die Komplexität erschwert insgesamt wiederum die Prozessautomatisierung und beschränkt diese auf technische Themen. • Fehlende Möglichkeiten zur Reaktivität und Flexibilisierung: Die Möglichkeit, Geschäftsprozesse direkt auf aktuelle Situationen flexibel anzupassen, fehlt auf Grund der Einschränkungen der Prozessautomatisierungen. Zusätzlich trifft dies auch auf die Meta-Steuerung zu, das heißt auf die notwendigen Steuerungsvorgänge der Ablauforganisation (Abschnitt 2.3.4) im Sinne des regelungs- und steuerungsorientierten Controllings (Abschnitt 4.4.2). Die Möglichkeiten, diese flexibel und automatisiert zu gestalten, sind noch nicht ausreichend genutzt. Hierzu fehlen entweder die technischen Möglichkeiten oder es sind proprietäre Erweiterungen der Systemlandschaft notwendig, was wiederum zusätzlichen Integrationsbedarf schafft und die Komplexität erhöht.

7.1.2. Geschäftsprozessmanagement, Service- und Ereignisorientierung Die Status quo des Geschäftsprozessmanagements und der Service- und Ereignisorientierung müssen sinnvoller Weise gemeinsam bewertet werden. SOA und CEP beziehen sich jeweils auf das Geschäftsprozessmanagement (durch Workflow und EDBPM), und das Geschäftsprozessmanagement erhebt Anspruch, ein integriertes Managementkonzept zu sein, in das theoretisch die Aspekte einer SOA und des CEP aufgenommen werden können. In sich sind die Themenbereiche valide und ausgereift. Geschäftsprozessmanagement und SOA haben sich in der Praxis bewährt, die Abdeckung in der wissenschaftlichen Literatur ist umfangreich. Auch für verteilte ereignisorientierte Systeme gibt es grundsätzlich ausreichend Quellen und Umsetzungen. Im Bereich CEP, als der jüngsten Disziplin, ändert sich die Quellenlage ebenfalls zum Positiven, jedoch fehlen hier vor allem noch Referenzmodelle, teilweise auch Standards. In einer ersten Zusammenfassung lassen sich aber bereits zwei wesentliche Erkenntnisse gewinnen: Erstens, die Zusammenhänge zwischen den Themen Geschäftsprozessmanagement, SOA und CEP sind immer aus der Sicht- und Denkweise des jeweiligen Themas betrachtet und nicht alle drei zusammen „von außen“. Zweitens fehlt in allen drei Themenbereichen der Bezug zum und die Umsetzungen für Contact-Center. Genauer auf

7.1. Bewertung des Status quo

171

einzelne Aspekte bezogen, lassen sich deshalb folgende Charakteristika der Istsituation erkennen: • Keine explizite Beschäftigung mit der Dienstleistungsbranche „Contact-Center“: Geschäftsprozessmanagement im Sinne des „Service Engineering“, das die Dienstleistungsideen in marktfähige Leistungen transformiert [vgl. bspw. Bullinger und Scheer, 2006], beschäftigt sich nicht mit den besonderen Anforderungen von Contact-Centern, obwohl sie einen nennenswerten Anteil an der Dienstleistungserstellung haben. Der Status quo zeigt, dass ein theoretisch fundiertes Standardprozessmodell (als Vorlage für ein Unternehmensprozessmodell) für Contact-Center fehlt. Insbesondere fehlen hier ein Hierarchiemodell und Modellierungskonventionen zur Aufnahme der fachlichen und technischen Aspekte von Geschäftsprozessen in Contact-Centern. • Fehlende Abstimmung zwischen Fachlichkeit und der technischen Umsetzung und Überwachung: Geschäftsprozessmanagement wird als Angelegenheit der Fachabteilungen betrachtet, SOA und CEP hingegen als Angelegenheiten der IT. Zwar werden im Zusammenhang mit BPMN und BPEL durchgängige modellgetriebene Ansätze ausreichend diskutiert und abgestimmt, dies bezieht sich jedoch auf die theoretischen und technischen Möglichkeiten. Wie die fachlichen Inhalte modelliert werden müssen und welche fachlichen Attribute dazu notwendig sind, vor allem in welcher Granularität, wird nicht betrachtet. Dies betrifft Aspekte aus allen Methoden des Geschäftsprozessmanagements: Modellierung, Controlling und Automatisierung. Bestehende Standardprozessmodelle sind noch nicht darauf ausgelegt, die relevanten Informationen aller beteiligten Managementgegenstände eines Contact-Centers aufzunehmen und im Sinne eines modellgetriebenen Ansatzes für die Prozessautomatisierung aufzunehmen. Insbesondere sind dies Aspekte der manuellen Tätigkeiten, des benötigten Wissens zur Prozessausführung, des Transportanteils [vgl. Gross et al., 2006, S. 21] sowie der Prozessautomatisierung mittels Workflow und Ereignisorientierung. • Ungenügende Betrachtung der Integration manueller Arbeitsschritte: Der Anteil manueller Tätigkeiten in Contact-Centern ist relativ hoch bei einem gleichzeitig starkem Automatisierungsgrad (bezogen in erster Linie auf den Kommunikationsanteil). Die Quellenlage zum Thema „human interaction“ ist jedoch unzureichend. „Human interaction“ wird in vielen Veröffentlichungen zu Workflows erwähnt, es wird jedoch selten genauer darauf eingegangen. Die zugehörige Spezifikation „BPEL4People“ ist nach wie vor proprietär, ein entsprechendes technisches Komitee bei OASIS wurde erst 2008 gegründet. Der Zeitpunkt einer Standardisierung ist noch nicht absehbar. Es ist zudem unklar, ob eine Erweiterung von BPEL für die Domäne Contact-Center überhaupt notwendig ist. Hinzu kommt die Tatsache, dass die in Contact-Centern häufig eingesetzten Agenten-Desktop-Systeme nicht auf Spezifikationen BPEL4People und WS-HT (und die zusätzlich notwendigen Applikationen) ausgerichtet sind.

172


• EDBPM-Referenzmodelle noch unzulänglich für konkrete Umsetzungen: Der Umfang und das Abstraktionsniveau der bisher veröffentlichten Referenzmodelle für das EDBPM sind für eine konkrete Umsetzung in der Praxis noch nicht ganz ausgereift, eine Referenzarchitektur der EP-TS ist noch nicht veröffentlicht. Vor allem die Frage nach dem Bedarf eigener Prozessmodelle und der Einbindung in eine SOA ist noch nicht ausreichend geklärt. SOA und DEBS gelten als komplementär, das heißt, sie sind auch frei kombinierbar. Wie die von [Luckham, 2007] geforderte Event-getriebene Architektur, die SOA und die Ereignisverarbeitung vereint, konkret aussieht, ist noch unklar und muss für Umsetzungen geklärt werden. Hier steht vor allem der Verweis auf fehlende Standards (insbesondere um BPEL Event-orientiert zu machen und zur Event-Darstellung) dem relativ breiten Spektrum an WS-*-Spezifikationen und -Standards gegenüber. „Best Practices“ wären hier hilfreich. Zur Komplettierung des EDBPM ist außerdem das regelungs- und steuerungsorientierte Geschäftsprozesscontrolling automatisiert zu unterstützen. Die fehlende Flexibilisierung und Reaktivität wurde bereits im Status quo der Praxis (Abschnitt 7.1.1) dargelegt. Hier fehlt eine Referenzarchitektur zur Umsetzung eines sogenannten Performance-Netzwerks mittels CEP. Konkret auf Contact-Center bezogen ist unklar, welche Anwendungsbereiche es für CEP und DEBS gibt, welche Event-Klassen dafür notwendig sind, welche Eventbasierten Komponenten es gibt und wie eine Gesamtarchitektur hierzu aussehen muss.

7.1.3. Fazit Aus der Sicht des Contact-Center-Managements muss den Herausforderungen einer globalisierten Umwelt adäquat begegnet werden. Contact-Center sind klassische Anbieter von Outsourcing-Dienstleistungen, das heißt, sie übernehmen individuelle Prozesse anderer Unternehmen oder bieten standardisierte Bausteine an. Beides erfordert gleichermaßen Flexibilität und Standardisierung, die durch unterschiedliche Mittel erreicht werden können. Die normative und strategische Ebene gibt eine Ausrichtung an Industrialisierung und Kundenorientierung vor. Auf operativer Ebene sind die Geschäftsprozesse und die umsetzende IT angesprochen. Hier empfiehlt es sich, in beiden Bereichen auf bewährte Standards, Methoden und Technologien zurück zu greifen (SOA, DEBS, CEP). Alleinstellungsmerkmale ergeben sich auf dieser Ebene durch die sinnvolle und innovative Nutzung. Aus interner, technischer Sicht muss außerdem der Tatsache begegnet werden, dass die bisher starke Trennung zwischen Telekommunikation und IT überwunden wird (Stichwort „VoIP“); der Sonderstatus einer dedizierten Technologieumgebung ist hier nicht mehr haltbar.

7.2. Lösung durch Integration vorhandener Ansätze auf Basis von Standards

173

Auf fachlicher Ebene ergibt sich aus der Kundenorientierung notwendigerweise die Prozessorientierung. Sie muss auch im Contact-Center methodisch unterstützt werden. In diesem Bereich ist ebenfalls eine Orientierung an Industriestandards (ARIS, BPMN) angezeigt, um eine Eingliederung (technisch und fachlich) in Konzernstrukturen und ServiceNetzwerke zu gewährleisten. Gesetzliche Vorschriften, die für den Auftraggeber gelten, müssen auch vom Outsourcing-Partner erfüllt werden können58 . Sowohl für das Management als auch für die operative Durchführung soll der von [Bleicher, 2004] beschriebene systemische Ansatz eines integrierten Management umgesetzt werden.

7.2. Lösung durch Integration vorhandener Ansätze auf Basis von Standards Die identifizierten Handlungsfelder geben vor, was ein innovatives Referenzmodell für Contact-Center abdecken muss und wie das geschehen soll. Um dies schrittweise und nachvollziehbar zu erarbeiten, wird zunächst ein allgemeines Zielbild konstruiert. Anschließend wird die Architektur des Referenzmodells vorgestellt, womit die bestimmenden Komponenten und deren grobes Zusammenspiel dargelegt werden. Die Einführung in das Referenzmodell runden Gedanken zu Referenzmodellen und deren Eigenschaften ab. Diese werden in der Zusammenfassung wieder aufgegriffen, um die dann detailliert vorhandenen Ergebnisse zu bewerten. 7.2.1. Zielbild und Rahmenbedingungen Als übergeordnetes Ziel wird angestrebt, ein Contact-Center in die Lage zu versetzen, sich fachlich und technisch in bestehende Wertschöpfungsnetzwerke (im übertragenen Sinne in eine globalisierte Umgebung) einzugliedern, ohne dabei Reibungsverluste zu erleiden. Diese würden auftreten, sobald zusätzlicher Integrations- und Anpassungsaufwand entsteht, der über die fachlichen Anforderungen hinausgeht. Das heißt, die umsetzende technische und fachliche Plattform wird auf Flexibilität und Reaktivität ausgelegt. Eine Lösung wird durch Integration, das heißt, durch Zusammenstellung und Anpassung aneinander, der bereits vorhandenen Ansätze des Geschäftsprozessmanagements, der serviceorientierten Architekturen sowie der Ereignisorientierung angestrebt. Dies soll auf Basis von bestehenden Standards und Spezifikationen geschehen. Das Geschäftsprozessmanagement bildet die fachlichen, eine serviceund ereignisorientierte IT-Architektur die technischen Schnittstellen nach innen und außen. Das Geschäftsprozessmanagement wird gleichzeitig so erweitert, dass es wesentliche Informationen für die Automatisierung mittels SOA und CEP mit aufnimmt. Die Handlungsfelder geben die notwendigen Anpassungen vor. Abbildung 71 versucht, diese Zusammenhänge grafisch darzustellen. 58

Als bekannteste Beispiele gelten die Bilanzierungs- und Eigenkapitalvorschriften des „Sarbanes-Oxley Act of 2002“ und Basel-II oder allgemein die ISO-Qualitäts-Standards.

174


Abbildung 71: Zielbild des Referenzmodells Die wissenschaftlichen Erkenntnisse, die sich aus der Modellbildung ableiten lassen, sind • aus übergeordneter Sicht die Gestaltung von CEP und SOA hin zu einem Vorschlag für eine „Event-getriebene Architektur“ aus beiden nach der Forderung von [Luckham, 2007] und, • auf Contact-Center bezogen, die Gestaltung der Geschäftsprozesse und einer umsetzenden IT-Architektur. Das Referenzmodell erhebt dabei nicht den Anspruch, alle aufgezeigten Probleme bis ins Detail zu lösen. Es soll vielmehr wesentliche Eckpunkte einer Umsetzung vordenken und als Grundlage für konkrete Umsetzungen dienen. Der Fokus liegt dabei auf der Darstellung der Gesamtzusammenhänge in Form von Architekturen und Abläufen. Tiefere Detaillierungsebenen, etwa die genaue Festlegung von Datenstrukturen, werden selten gewählt. Noch detailliertere Darstellungen wie WSDL- oder XML-Schema-Definitionen müssen immer in konkreten Projekten erstellt werden. 7.2.2. Architektur des Referenzmodells Abbildung 72 zeigt die Architektur des Referenzmodells. Die Ausgangsvoraussetzungen wurden bereits in Teil I und in den vorigen Abschnitten dieses Kapitels geklärt. Sie liefern insgesamt die Zielsetzungen und Vorgaben für die Umsetzung der beiden Domänen des


175

Abbildung 72: Architektur des Referenzmodells Referenzmodells. Vorgehensmodelle sichern ein planmäßiges Vorgehen und die Einhaltung der Zielvorgaben. Zunächst wird der Teil der Serviceorientierung und des Geschäftsprozessmanagements konstruiert. Contact-Center-typische Applikationsdomänen clustern dabei die Anwendungslandschaft und sind Voraussetzung für eine Definition von Service-Typen. Da einzelne Services nicht identifiziert werden können (hierzu fehlt die Fachlichkeit eines konkreten Unternehmens), werden Klassen gebildet (Service-Typen), die jeweils typische Implementierungs- und Integrationsaspekte beschreiben. Anschließend wird ein Contact-Center-Prozessmodell als Standardprozessmodell entwi-

176


ckelt. Es enthält die Definition von Hierarchiestufen zur Abbildung der gesamten Wertschöpfung in Contact-Centern. Zu den einzelnen Hierarchiestufen werden eigene Prozessmodelle entwickelt. Diesen werden Modellierungskonventionen zur äußeren und Heuristiken zur inhaltlichen Gestaltung als Vorlage für ein Konventionshandbuch beigestellt. Das Contact-Center-Prozessmodell ist somit in der Lage, alle Geschäftsprozesse abzubilden. Die Modellierungskonventionen und Heuristiken sind darauf abgestimmt, dass die Geschäfts- und Teilprozesse mittels SOA und der Eventverarbeitung automatisiert und überwacht werden können. Die Service-Typen bilden die abstrakten Klassen zur ServiceUmsetzung der innerhalb von Teilprozessen modellierten Aktivitäten. Die Granularität der Services ergibt sich dabei durch Anwendung der Gestaltungsrichtlinien. Die Serviceorientierung bildet das bestimmende Paradigma des Referenzmodells. Alle Funktionalitäten werden als Web-Services angeboten. Dort, wo es notwendig und sinnvoll erscheint, wird die Architektur des Referenzmodells durch das ereignisorientierte Paradigma ergänzt. Dies geschieht konkret in zwei Anwendungsgebieten: Erstens wird das Event-basierte Kommunikationsparadigma unterstützt und zweitens werden Funktionalitäten bestimmter Komponenten mit Hilfe des CEP implementiert. Nach außen werden sie aber trotzdem als Web-Services gekapselt. Die Event-Domäne des Referenzmodell erhält folgende Erweiterungen: Es werden eine „Event-driven Architecture“ und die Event-technischen Grundlagen konstruiert. Darin werden der Event-Transports (Zugang zu bestehenden pub/sub-Kommunikationssystemen über einen eigenen Web-Service) und die Darstellung von Events erarbeitet. Auf dieser Basis werden verschiedene Event-Processing-Agents (EPA) und ihre zugehörigen Event-Typen definiert. Die EPA implementieren die Funktionalitäten der Event-basierten Geschäftsprozesssteuerung und des Business-Activity-Monitorings (BAM). Die Gesamtheit der EPA wird zu einem Vorschlag für ein Event-Processing-Network (EPN) zusammengestellt, das insgesamt die Funktionalität eines Performance-Netzwerks darstellt. Für die Abbildung der Funktionalitäten von EPA wird ein eigener Modelltyp entwickelt und in das Contact-Center-Prozessmodell aufgenommen, womit die Aspekte der Eventverarbeitung und notwendige Informationen mit in das Prozessmodell aufgenommen werden. Abschließend wird der Gesamtzusammenhang eines integrierten Geschäftsprozessmanagements aufgezeigt, das Contact-Center-Prozessmodell bietet hierzu die Datenbasis.

7.2.3. Eigenschaften von Referenzmodellen und Evaluierungskriterien Die allgemeinen Modelleigenschaften nach [Stachowiak, 1973] wurden bereits in Abschnitt 1.2.2 eingeführt. Es bleibt die Frage, welche Merkmale ein Modell zum Referenzmodell machen und ob diese hier zutreffend sind. Für eine abschließende Bewertung (nach Erstellung des Referenzmodells) müssen zudem Evaluierungskriterien aufgestellt werden.


177

Eine Referenz ist im allgemeinen Sprachgebrauch entweder als Empfehlung oder als Bezugnahme zu verstehen. Im Sinne der Bezugnahme ist die „Allgemeingültigkeit als konstituierendes Merkmal des Referenzmodellbegriffs“ entscheidend (hergeleitet in [Thomas, 2006, S. 85]). „Referenzmodelle beziehen sich auf bestimmte Sektoren wie Branchen, Wirtschaftszweige, Betriebstypen, Unternehmen oder Funktionen“ [Schmelzer und Sesselmann, 2008, S. 233]. Sie sind dabei als Vorlagen für die Gestaltung von Informationssystemen zu verstehen, die zur Ableitung unternehmensspezifischer Modelle dienen. Als Begriff wurde hierfür explizit „Referenzmodell“ in der Wirtschaftsinformatik in den 90er-Jahren etabliert [bspw. durch Scheer, 1990, 1997]. Aus einer anderen Sichtweise heraus erhält ein Modell die Bezeichnung „Referenzmodell“ entweder durch Deklaration (Wahrnehmung des Erstellers) oder durch Akzeptanz (durch Nutzer oder Gremien) [vgl. Thomas, 2006, S. 85 ff.]. Idealerweise ist beides zutreffend. Nach Kritik von [Thomas, 2006] ist die Deklaration allein nicht ausreichend, es fehlt der „Beweis“. Das Modell, das im Rahmen dieser Arbeit erstellt wird, erhält ebenfalls die Bezeichnung „Referenzmodell“. Das Merkmal der Allgemeingültigkeit ist grundsätzlich erfüllt durch die Fokussierung auf die Branche Contact-Center. Obwohl ein übergeordneter Beweis fehlt (es ist das erste Modell dieser Art für Contact-Center), wurden jedoch schon Teilbeweise im Rahmen der verwendeten Teilgebiete erbracht. Referenzmodelle enthalten Wissen, das wiederverwendet werden kann, wodurch Redundanzen und Inkonsistenzen bei der Anwendung in individuellen Projekten vermieden werden können [vgl. Becker et al., 2007, S. 3]. Der Referenzcharakter entsteht hier auch aus dem Verständnis einer Empfehlung heraus, die IT- und Prozessstrukturen analog dem hier vorgestellten Modell zu gestalten. Hierzu wurden ausführlich die Herausforderungen von Contact-Centern geklärt. Für die abschließende Bewertung des Referenzmodells müssen allgemein anerkannte Qualitätskriterien gefunden werden. Da es sich hier um die Entwicklung eines Informationssystems zur Prozessautomatisierung mittels Software handelt, können die Evaluierungskriterien des Software-Engineering herangezogen werden. Sie werden hier nach der Sammlung von [Weiß und Jakob, 2005, S. 24 - 28] angeführt und erklärt59 : • Anwendungsbreite: In welche Bereiche erstreckt sich die Anwendungsmöglichkeit des Modells, gibt es prinzipielle anwendungsspezifische Einschränkungen? • Implementierbarkeit: Wie groß ist der Aufwand, die erstellten Teilmodelle und Spezifikationen programmtechnisch umzusetzen? • Wiederverwendbarkeit: Wird die Generierung von Modellen, Spezifikationen, Programmteilen, Datenstrukturen oder Daten unterstützt, die in anderen Anwendungen wiederverwendet werden können? 59

Werkzeugspezifische Kriterien wurden weggelassen.

178


• Modularität: Wird ein modularer Systemaufbau unterstützt, der lokale Änderungen erlaubt, ohne andere Teile zu beeinflussen? Dies bezieht sich sowohl auf einzelne Komponenten als auch auf das Gesamtsystem. • Verständlichkeit: Wie verständlich und zugänglich ist das Modell? Welcher Einarbeitungsaufwand ist für das Erlernen der Konzepte und Sichtweisen erforderlich? Kriterien sind hier der Umfang und die Qualität der verfügbaren Dokumentation sowie der Umfang und die Tiefe der benötigten Vorkenntnisse. • Genauigkeit: Sind die zu Grunde liegenden Entwicklungsschritte präzise genug für eine mängelfreie Umsetzung ohne die Gefahr von Fehlinterpretationen und Missverständnissen? • Vollständigkeit: Werden alle Phasen des Entwicklungszyklus abgedeckt? Wird das Zielsystem vollständig abgedeckt? • Variabilität: Sind Änderungen und Anpassungen an Teilen des Modells oder des Zielsystems möglich? • Komplexitätshandhabung: Werden konkrete Unterstützungen für die Realisierung des Modells geboten? • Granularität: Wird die Betrachtung des Zielsystem mittels unterschiedlicher Granularitätsebenen unterstützt? • Sicherheit: Werden sicherheitsrelevante Systemaspekte berücksichtigt? • Überprüfbarkeit: Kann das Modell auf Korrektheit überprüft werden und gibt es hierzu Hilfestellungen? Hierbei ist zwischen der Validierbarkeit (Effektivität des Modells) und Verifizierbarkeit (Effizienz des Modells) zu unterschieden. • Laufzeitdynamik: Wird das Verhalten zur Laufzeit des Modells berücksichtigt? Wie wirken sich Änderungen in der Komponentenzusammensetzung aus? • Expressivität:60 Inwieweit wird die Erfassung und Software-technische Realisierung von Softwareattributen unterstützt?

60

Nicht zu verwechseln mit der Anwendungsbreite.

179

8. Automatisierung durch Serviceorientierung Auf der Grundlage des im vorangegangenen Kapitel diskutierten Status quo und des skizzierten Lösungsansatzes werden im folgenden Kapitel die SOA-relevanten Aspekte des Referenzmodells entwickelt und in das Geschäftsprozessmanagement als integriertes Managementkonzept aufgenommen. Hierzu wird im ersten Abschnitt ein geeignetes Vorgehensmodell entwickelt, dessen Phasen jeweils in den nachfolgenden Abschnitten behandelt werden.

8.1. Gewähltes Vorgehensmodell

Ziel des SOA-relevanten Teils des Referenzmodells ist es, die Geschäftsprozesse eines Contact-Centers optimal zu gestalten, um sie mit Hilfe einer SOA weitestgehend zu automatisieren. Dabei sollen die übergeordneten Ziele eines Contact-Centers unterstützt werden. Dafür müssen diese Ziele bekannt sein. Eine Zusammenstellung der Ziele sowie eine Priorisierung wichtiger Architekturprinzipien wird deshalb als erste Phase des Vorgehensmodells definiert. In der zweiten Phase werden die generischen Anwendungsdomänen in einem Contact-Center identifiziert. Sie dienen gemeinsam mit den identifizierten Zielen als Grundlage für die dritte Phase, die Identifikation und Beschreibung von Service-Typen. In einer vierten Phase wird ein Unternehmensprozessmodell für Contact-Center aufgestellt. Darin werden die Service-Typen in die Prozessgestaltung integriert und entsprechende Modellierungskonventionen formuliert. Dies dient unter anderem dazu, alle Geschäftsprozesse eines Contact-Centers strukturiert zu gestalten und die Grundlage für konkrete Servicegestaltung (insbesondere deren Granularität) zu schaffen. Die letzte Phase bildet die umsetzungsrelevante Architekturgestaltung, die auch die Anwendung bestehender Standards beinhaltet. Die nachfolgende Abbildung 73 stellt die aufeinanderfolgenden Phasen nochmals grafisch dar.

Abbildung 73: Vorgehensmodell zur Gestaltung SOA-relevanter Teile des Referenzmodells


180

8. Automatisierung durch Serviceorientierung

8.2. Identifikation von Zielen und Architekturprinzipien Bevor Ziele identifiziert und eine Domänenabgrenzung vorgenommen werden, ist die grundsätzliche Fragestellung zu klären, ob die Einführung einer SOA im Contact-Center sinnvoll ist. Hierzu wurden durch [Heutschi, 2007, S. 132] entsprechende Indikatoren von [Dietzsch und Goetz, 2005], [SAP, 2005], [Adams, 2005] und [Bloomberg, 2004] zusammengetragen, wie sie in Abbildung 74 zusammengestellt sind.

Abbildung 74: Indikatoren für/gegen SOA [aus Heutschi, 2007, S. 132] Diese Indikatoren lassen sich auf Basis des untersuchten Prozessmodells der [ContactGroup, 2007] bewerten: Bei 119 identifizierten Geschäftsprozessen können diese nicht

8.2. Identifikation von Zielen und Architekturprinzipien

181

so weit standardisiert werden, um einen Großteil der Kundenwünsche mit wenigen Geschäftsprozessen abzudecken. Die abgedeckte Breite der Themen ist hier zu groß. Jedoch ist in den Prozessmodellen zu erkennen, dass Funktionen in unterschiedlichen Geschäftsprozessen mehrmals modelliert werden. Diese können in entsprechender Granularität eventuell in Services gekapselt werden. Darüber hinaus gibt es beispielsweise vier Varianten des Geschäftsprozesses „Bestellung“. Eine Analyse der verwendeten Anwendungssystemtypen zeigt zusätzlich, dass viele Geschäftsprozesse teilweise mehr als fünf Anwendungssysteme verwenden. Insgesamt ist die Applikationsarchitektur stark heterogen (siehe hierzu auch Abschnitt 2.3.2), es wurden 122 verschiedene Anwendungssystemtypen modelliert, was für eine Verwendung einer einheitlichen Integrationsarchitektur spricht (der Anteil der IT-Kosten, hier vor allem die Anpassungs- und Integrationskosten, bildet nach den Personalkosten einen großen Kostenanteil). Ein Blick auf benötigte Informationen in der Prozessausführung zeigt, dass sowohl interne als auch externe Informationsund Datenquellen vorhanden sind. Insgesamt wurden 477 verschiedene Informationsträger und 60 Wissensobjekte in den Prozessmodellen verwendet. Durch die Integration von Wissensobjekten in Services beziehungsweise in ein „Application Frontend“ könnte dies die Produktivität der Agenten erhöhen, womit einer der größten Einflussfaktoren auf die Ausführungskosten (die Personalkosten) positiv beeinflusst wird. Dies ließe sich durch eine Präsentation des notwendigen Wissens zeitgleich mit der Zustellung eines manuellen Arbeitsauftrags erreichen. Der Faktor Durchlaufzeit (Prozesszeiten) ist ebenfalls von Bedeutung. Hier sind vor allem Prozessvarianten betroffen, die durch asynchrone Kontaktkanäle bedient werden, da hier teilweise Liegezeiten von mehreren Tagen zu verzeichnen sind, die durch Steuerungsmechanismen der Prozessautomatisierung verkürzt werden können. Der Bedarf an hochvolumigen, synchronen Echtzeittransaktionen ist eher gering, er entspricht nicht der Anzahl der bearbeiteten Kundenkontakte. Lediglich synchrone Telefonkontakte haben Echtzeitcharakter, sie sind jedoch durch dedizierte Telefonanlagen und durch „Quality of Service“ im Netzwerk (VoIP) sichergestellt. Eine Performanzproblematik besteht diesbezüglich nicht. Managementunterstützung, Know-how und Ressourcen können hier generell nicht in Betracht gezogen werden, sie müssen für jedes Projekt individuell geklärt werden. Grundsätzlich lässt sich jedoch festhalten, dass es große Potentiale einer SOA in Contact-Centern gibt und ein Einsatz deshalb sinnvoll ist. Nachdem der grundsätzliche Nutzen dargelegt ist, müssen Zielvorgaben ermittelt werden. Abgeleitet von der Strategie eines Unternehmens ergeben sich für konkrete Vorhaben Ziele und Umsetzungsprinzipien. Bezogen auf die Entwicklung des Referenzmodells prägen die im Kapitel 3 „Kundenorientierung und Industrialisierung in der Kundenkommunikation“ erarbeiteten Einflussfaktoren die Ziele, die für die Einführung einer SOA im ContactCenter maßgeblich sind. Da die konkreten Strategien einzelner Contact-Center nicht bekannt und nicht Gegenstand dieser Arbeit sind, werden zwei strategische Grundmuster aus den globalen Einflussfaktoren bestimmt. Diese können wie folgt formuliert werden: „Implementierung einer durchgängigen Kundenorientierung“ (als Forderung der Kundenorientierung) und „Wei-

182


terentwicklung der Automatisierung“ (als Forderung der Industrialisierung). Daraus leiten sich folgende Zielsetzungen ab: • Standardbasierte Integration aller kundenrelevanten Daten und Systeme: Die heterogene Systemlandschaft in einem Contact-Center beinhaltet eine Vielzahl inkompatibler Anwendungssysteme, die auf unterschiedlichen Plattformen beruhen (vgl. hierzu Abschnitt 2.3.2). Ziel soll es sein, alle für die Bearbeitung von Kundenanliegen notwendigen Anwendungssysteme und Daten mit Hilfe einer zentralen und plattformübergreifenden Integrationsinfrastruktur zur Verfügung zu stellen. Medienbrüche und Schnittstellenprobleme sollen dabei vermieden werden [vgl. Schümann und Tisson, 2006, S. 140]. Der Einsatz etablierter Standards wie beispielsweise WebServices soll die einfachere Bündelung von Leistungsangeboten und die Möglichkeit zur unternehmensübergreifenden Netzwerkbildung vereinfachen [vgl. Meffert et al., 2008, S. 860]. • Entkopplung der Prozess- und Multikanal-Steuerung: Häufig besteht eine enge Kopplung zwischen der Steuerung der Abläufe in der Kommunikation (Anruf muss von Agent A zu Spezialist B) und der Steuerung des Prozessablaufs (die Weiterleitung des Anrufs löst Prozessschritte aus). Direkte Zugriffe auf das eine System sind jeweils im anderen implementiert. Ein Vorgang der Kommunikationssteuerung kann somit zwangsläufig an anderer Stelle Bearbeitungen auslösen, die nicht explizit gesteuert werden, da dieser Vorgang implizit aus der Programmierung des Routings oder anderer Multikanal-Systeme hervorgeht. Ziel ist es, den Transportanteil im Dienstleistungsprozess [vgl. Gross et al., 2006, S. 21] explizit zu berücksichtigen (vgl. Abschnitt 3.2.2) und beide lose miteinander zu koppeln. Ziel ist es außerdem, eine flexible Anpassung an Kundenpräferenzen (bezogen auf die Wahl des Kontaktkanals) zu gewährleisten. • Ausrichtung der Servicegestaltung an den Geschäftsprozessen und Fachanwendern: Ziel ist es, die Funktionen von Anwendungssystemen an die fachlichen Inhalte von Geschäftsprozessen und an die Anforderungen der Fachanwender (Agenten, Spezialisten) anzupassen (vgl. Abschnitt 3.2.1). Mitunter wird dadurch eine einheitliche Verständigungsbasis zwischen den Fachabteilungen und der IT geschaffen. Die Ausrichtung der Servicegestaltung beinhaltet dabei die von den Anwendungssystemen zur Verfügung gestellten Funktionen und Daten, aber auch die zugehörigen Bildschirmmasken. Der Ablauf eines Geschäftsprozesses – vom auslösendem Ereignis bis zur kompletten Leistungserstellung bezogen auf den Kundenwunsch (vgl. Abschnitt 4.1.1) – soll durch sinnvolle Abfolge von Services abgedeckt werden. • Aufnahme manueller Tätigkeiten in die Servicegestaltung: Persönliche Kontakte sind wesentliche Bestandteile der Bearbeitungen im Contact-Center und ein wichtiges Instrument der Kundenorientierung. Persönliche Kontakte bedeuten jedoch gleichzeitig manuelle Tätigkeiten. Ziel ist es trotzdem, diese Art der Tätigkeit bestmöglich in einen automatisierten und IT-gestützten Prozessablauf zu integrieren und so

8.2. Identifikation von Zielen und Architekturprinzipien

183

die Automatisierung voranzutreiben (vgl. Wesensmerkmale der Industrialisierung in Abschnitt 3.2.2). • Standardisierung, Wiederverwendung und Redundanzreduktion: Es soll eine Standardisierung von Vorgängen erreicht werden, die gleichzeitig in anderen Kontexten (Geschäftsprozessen) wiederverwendet werden können und somit redundante fachliche Funktionen vermeiden. Dies entspricht der Spezialisierung im Sinne der Industrialisierung und des Outsourcing (vgl. Abschnitt 3.2.2), wodurch wiederum die Bündelung von Leistungsangeboten und die Möglichkeit zur Netzwerkbildung [vgl. Meffert et al., 2008, S. 860] unterstützt wird. Darüber hinaus beinhaltet diese Zielsetzung auch eine gewisse Generalisierung in der Servicegestaltung, um so Services von Dimensionen wie Kontaktkanal oder Auftraggeber zu abstrahieren [vgl. bspw. Stauss, 2006], [Buxmann et al., 2008, S. 156 ff.]. • Flexibilisierung und Reaktivität: Ziel ist die Gestaltung innovativer Produkte und Prozesse. Da Produkte von Contact-Centern immer Dienstleistungen sind (die in Prozessen erstellt werden), bedarf dies der Möglichkeit schneller Prozessanpassungen. Hierzu sind flexible, reaktive IT-Echtzeit-Lösungen notwendig (vgl. Abschnitt 3.2.1). Hierbei spielen die Differenzierung der Produkte, Leistungen sowie der Dialog zum Kunden eine große Rolle [vgl. Hippner und Wilde, 2002, S. 9 - 10]. Für die Zielsetzung bedeutet dies, sowohl auf Anpassungen in der Produkt- und Leistungserstellung (Geschäftsprozesse) als auch auf geänderte Anforderungen im Kundendialog (Wahl der Kontaktkanäle) flexibel reagieren zu können (vgl. Abschnitt 3.1.3). Neben der Strategie dienen diese Ziele als Leitmotive für die Einführung einer SOA. Sie bestimmen in hohem Maße die Contact-Center-spezifische Ausgestaltung der jeweiligen Eigenschaften einer SOA. Diese Eigenschaften wurden bereits in Abschnitt 5.1.1 als sogenannte Architekturprinzipien zusammengefasst. Diese werden hier als Richtlinien verstanden, die für eine zielgerichtete und einheitliche Umsetzung einer SOA im ContactCenter notwendig sind. Hierfür werden die Architekturprinzipien nach der Methode von [Heutschi, 2007] gegen die oben erarbeiteten Ziele priorisiert, um für die anschließende Identifikation der Service-Typen die wichtigsten Architekturprinzipien für Contact-Center herauszuarbeiten. Dabei wird der Einfluss der jeweiligen Architekturprinzipien auf die einzelnen Ziele bewertet (eine positive Zielunterstützung wird durch ein Plus gekennzeichnet, eine negative Zielunterstützung entsprechend durch ein Minus, ein nicht vorhandener Einfluss zeigt ein leeres Kästchen). Abbildung 75 zeigt die einzelnen Ziele und die Bewertung der unterstützenden Architekturprinzipien. Aus der Bewertung der Architekturprinzipien kann folgendes Ergebnis abgeleitet werden (Anzahl der unterstützten Zielsetzungen aus Abbildung 75 in Klammern): • hoher Einfluss auf Zielerreichung: Abstraktion von der Serviceimplementierung (5), An Geschäftskonzepten orientierte, grobe Servicegranularität (5), Fachliche Schnittstellenstandardisierung (4), Generalisierung der Serviceleistung (4) und Lose gekoppelte Kommunikation (4)

184


Abbildung 75: Priorisierung der Architekturprinzipien für die Service-Typen-Definition

• mittlerer Einfluss auf Zielerreichung: Umfassende, einheitliche Servicespezifikation (3), Verwendung offener und verbreiteter Industriestandards (3), Technische Schnittstellenstandardisierung (3)

• geringer Einfluss auf Zielerreichung: Stabile, gemanagte Servicekontrakte (2), hohe Servicekohäsion und schwache logische Kopplung (2)

Eine solche Bewertung ist in jedem konkreten Projekt zur Einführung einer SOA erneut unternehmens- und projektindividuell durchzuführen. Die Priorisierung der Architekturprinzipien dient in diesem Referenzmodell neben der Domänenabgrenzung als wichtiger Einflussfaktor für die Identifikation der Service-Typen.

8.3. Domänenarchitektur

185

8.3. Domänenarchitektur Die Entwicklung einer Domänenarchitektur folgt ebenfalls der Methodik von [Heutschi, 2007, S. 141 ff.]. Ziel ist es, eine allgemeingültige Clusterung der in Contact-Centern vorhandenen Applikationsdomänen vorzunehmen. Applikationsdomänen sind zentrale Instrumente zur Entscheidung, wo Services entwickelt werden und wer sie verantwortet. Dies kann noch durch die Fragestellung, wer Services mitgestaltet, erweitert werden. Dadurch lassen sich wesentliche Gestaltungsanforderungen an einen Service mit berücksichtigen. Zielsetzung einer Domänenarchitektur ist die fachliche Strukturierung der Applikationsarchitektur, die Identifikation klarer Verantwortungsbereiche (und deren Autonomie) sowie die Komplexitätsbeherrschung [vgl. Heutschi, 2007, S. 142 - 143]. Aus der Untersuchung verschiedener Ansätze in der Literatur wurden schließlich nachfolgende Kriterien zur Domänenabgrenzung durch [Heutschi, 2007, S. 151 - 155] konsolidiert, die auf das untersuchte Prozessmodell der [Contact-Group, 2007] sowie auf die allgemeinen Ergebnisse der vorangegangenen Kapitel angewendet werden: • Unternehmensbereichsspezifische Domänen: Darunter gliedern sich Funktionen und Daten zur Unterstützung spezifischer Geschäftsprozesse einzelner Geschäftseinheiten oder Produktlinien. Sie orientieren sich an Geschäftsleistungen, Kundensegmenten, Marktkompetenzen und beispielsweise auch an Spezial-Know-How [vgl. Heutschi, 2007, S. 151]. Eine Untersuchung des Prozessmodells der [Contact-Group, 2007] lässt keine direkte Unterscheidung einzelner Geschäftseinheiten im Sinne von Unternehmensbereichen zu. Auch auf Contact-Center allgemein bezogen scheint dies weniger geeignet. Grund hierfür ist die Fokussierung von Contact-Centern auf die Kundenbetreuung, die in den meisten Fällen von Unternehmen als ein Unternehmensbereich angesehen wird. Allerdings ist eine Segmentierung von Geschäftsprozessen möglich. Die [ContactGroup, 2007, Prozesslandkarte] unterscheidet fachlich auf hoher Ebene die Gruppen „Beratung“, „Bestellung“, „Service“ und „sonstige Dienstleistungen“. Diese werden als die Kernprozesse bezeichnet. Diese Gliederung ergibt sich aus unterschiedlichen Gründen. Allgemein können die Kernprozesse als die Spezialisierungen (Generalisierungen, Fachgebiete, „Produktlinien“) des Contact-Centers angesehen werden. Sie clustern die Fachlichkeit und somit Daten, Funktionen und Anwendungssysteme, die die jeweiligen Kernprozesse unterstützen. Unter Umständen lassen sich weitere Sub-Anwendungsdomänen bilden, die für die spätere Service-Typen-Identifikation hilfreich sein können. Neben den vier oben dargestellten Kernprozessen ist eine detailliertere Gruppierung von Anwendungssystemen denkbar. Zum einen ist eine Clusterung nach Produkten im Sinne von angebotenen Dienstleistungen des Contact-Centers denkbar. Die [Contact-Group, 2007, detaillierte Prozessmodelle] untergliedern sich weiter in speziellere Geschäftsprozesse, etwa Beratungen für spezielle Produktsegmente wie Möbel oder Unterhal-

186

8. Automatisierung durch Serviceorientierung tungselektronik, die für ein generalisiertes Produkt „High-Tech-Beratungen“ oder „Life-Style-Beratungen“ sprechen können. Indiz hierfür ist auch eine Untersuchung der Ausprägungen des Objekttyps „Stelle“. Beispielsweise gibt es Stellen für Spezialistenrollen wie „Spezialist Technik“ und „Spezialist Wohnen“. Untersucht man diejenigen Prozessmodelle, in denen diese Spezialistenrollen jeweils modelliert wurden, auf die dort eingesetzten Anwendungssysteme, lassen sich eventuell Gruppen von Anwendungssystemen bilden, die speziell für ein generalisiertes Produkt verwendet werden. Im Falle der Beratungen wären dies beispielsweise Produkt-InformationsSysteme oder Kundendienstsysteme der Hersteller61 . Auch das benötigte Fachwissen wurde in den Prozessmodellen unterschieden. Entsprechend wurden die Objekte „Fachbegriff“ und „dokumentiertes Wissen“ in den einzelnen Prozessmodellen verwendet. Hier lassen sich ähnliche Überlegungen anstellen. Als weitere mögliche Sub-Anwendungsdomäne ist die Unterscheidung nach bedienten Branchen möglich. Hat ein Contact-Center Auftraggeber aus unterschiedlichen Branchen, so lassen sich Anwendungssysteme eventuell nach diesen gliedern. Sehr deutlich zeigt dies die Sparte Reisen, die ebenfalls vom Betreiber [Contact-Group, 2007] bedient wird. Hierfür gibt es mehrere Auftraggeber, die verwendeten Anwendungssysteme lassen sich jedoch klar für diese Branche abgrenzen. Ein Beispiel hierfür ist das genutzte Reisereservierungssystem von [Amadeus, 2009], das für viele Auftraggeber eingesetzt wird.

• Kerngeschäftsentitäten-orientierte Domänen: Dies sind Kerndaten, die in mehreren Unternehmensbereichen und Prozessen verwendet werden, wie beispielsweise Kunden-, Vertrags-, Organisations- oder Produktstammdaten [vgl. Heutschi, 2007, S. 151]. Sowohl in den Bereich der unternehmensbereichsspezifischen Domäne als auch in den Bereich der an den Kerngeschäftsentitäten orientierten Domäne gehörig, können in der [Contact-Group, 2007]62 die sogenannten Mandanten identifiziert werden. Als Mandanten werden dort die Kunden im Sinne der Auftraggeber des Contact-Centers bezeichnet (im Vergleich zu den Endkunden, die von Agenten betreut werden). In 598 von insgesamt 723 modellierten Geschäftsvorfällen (Teilprozesse von Geschäftsprozessen) wird ein zentrales Anwendungssystem des Mandanten verwendet. Fast ausschließlich alle Kundenbewegungsdaten und -stammdaten, Bestelldaten sowie die Produktinformationen werden damit geclustert. Aus diesem Anwendungssystem werden 387 Bildschirmmasken als Objekt „Maske“ an Funktionen modelliert. Eine Untersuchung hier zeigt ebenfalls, dass ein Großteil der Masken Daten und Funktionen zur Verfügung stellt, die in vielen Geschäftsprozessen auf kompletter 61 62

Eine Produktberatung oder ein Kundenservice für ein Elektrogerät der Firma X kann von einem Contact-Center für viele Versender sowie Gross- und Einzelhändler übernommen werden. Das untersuchte Prozessmodell stellt dabei lediglich die Geschäftsprozesse des größten Mandanten dar. Für weitere Mandanten (auch aus unterschiedlichen Branchen) gibt es ähnliche Aufstellungen (allerdings in geringerer Detaillierung und Stringenz der Modellierung).

8.3. Domänenarchitektur

187

Mandantenebene benutzt werden. Lediglich wenige Bildschirmmasken lassen eine Eingrenzung auf Kernprozesse zu, hier meist auf besondere Funktionen für Agenten mit speziellem Profil. Andere, spezielle Anwendungssysteme lassen sich teilweise auf Gruppen oder sogar einzelne Geschäftsprozesse anwenden. Dies spricht für die bereits oben erwähnte Zuordnung zu Kernprozessen oder zu speziellen Querschnittsfunktionen (siehe unten). • Querschnittsfunktionen: Darunter werden fachliche und technische Funktionen verstanden, die bereichs- und prozessübergreifend erbracht werden [vgl. Heutschi, 2007, S. 151 - 152]. Der Kernprozess „unterstützende Dienstleistungen“ der [Contact-Group, 2007, Prozesslandkarte] beinhaltet Geschäftsprozesse, die interne Dienstleistungen als fachliche Querschnittsfunktion anbieten. Diese können als Unterstützungsfunktionen betrachtet werden. Darunter fallen beispielsweise die Geschäftsprozesse „Bonität prüfen“, „Inkasso bearbeiten“, „Archivierung durchführen“ oder „Telefonvermittlung durchführen“. Diese Geschäftsprozesse werden intern mandanten- und kernprozessübergreifend in diversen Geschäftsprozessen verwendet. (Eine Bonitätsprüfung kann beispielsweise sowohl für eine Finanzierung als auch in einer Bestellung verwendet werden. Inkassobearbeitungen können für verschiedene Mandanten angeboten werden.) Sie clustern außerdem Daten und Anwendungssysteme, die ausschließlich für diese Unterstützungsfunktionen benötigt werden, beispielsweise Systeme externer Partner wie Auskunfteien oder interne Systeme wie Dokumenten-Archiv-Systeme. Modellierte Objekte wie „Fachbegriff“ und „dokumentiertes Wissen“ lassen eine weitere Anwendungsdomäne erkennen, die unter dem Begriff Wissens- und Schulungssysteme zusammengefasst werden kann. Darunter fallen beispielsweise unternehmensinterne Suchmaschinen, Portale (die Wissen zu bestimmten Produkten und Themen beinhalten) oder das Intranet. Wird Wissen mit Hilfe von IT-Systemen den Agenten zur Verfügung gestellt, so clustern diese spezielle Daten und Funktionen, die Contact-Center-weit Verwendung finden. Als wesentliche technische Querschnittsfunktion in Contact-Centern ist das Multikanal-Management zu nennen. Darunter fällt in erster Linie das Routing von Kontakten (vergleiche Abschnitt 2.3.1 „Multikanal-Kontaktverteilung und Routing“). Daran sind spezielle Anwendungssysteme wie die Telefonanlage, die ACD-Anlage sowie weitere CTI-Systeme beteiligt, die ausschließlich für das Multikanal-Management zuständig sind, aber in fast allen Geschäftsprozessen zum Tragen kommen. Hierzu wurden in den Geschäftsprozessen der [Contact-Group, 2007, detaillierte Prozessmodelle] 477 Objekte des Typs „Informationsträger“ modelliert, beispielsweise in den konkreten Ausprägungen als E-Mail-, Fax-, Brief- oder Telefonobjekt. Eine ähnliche Querschnittsfunktion bieten Agenten-Desktop-Systeme (beispielsweise [Microsoft, 2009a, Jacada, 2009]), die der Anwendungssystemintegration auf Ebene

188

8. Automatisierung durch Serviceorientierung der Benutzeroberfläche dienen. Sie finden in großen Contact-Centern häufig Verwendung, da dort eine Vielzahl von Anwendungssystemen für die verschiedenen Bearbeitungen notwendig ist, die ein Agent auf Grund seiner Skills nacheinander bearbeiten kann. Die Erhebung der [Contact-Group, 2007, detaillierte Prozessmodelle] ergab 122 Objekte des Typs „Anwendungssystemtyp“, die in den 119 Geschäftsprozessen zum Einsatz kommen.

Abbildung 76: Generelle Anwendungsdomänen eines Contact-Centers Die soeben abgegrenzten Applikationsdomänen zeigt Abbildung 76 im Überblick. In konkreten Projekten zur Einführung von SOA in einem Contact-Center soll es als Anhaltspunkt dienen, indem konkrete Kriterien erarbeitet wurden, die zur Clusterung der Anwendungslandschaft dienen. Die Anwendungsdomänen lassen sich wie folgt nochmals zusammenfassen: • Kernprozesse: Anwendungssysteme für häufig wiederkehrende Geschäftsprozesse eines Contact-Centers, die sich auf Kernprozesse, Fachgebiete oder Produktlinien beziehen können. Eine Bildung von Sub-Domänen für bediente Branchen, angebotene Produkte oder Mandanten (siehe auch nächster Punkt) ist möglich und bei einer größeren Anzahl von Anwendungssystemen meist auch sinnvoll.

8.4. Identifikation von Service-Typen

189

• Mandanten: Anwendungssysteme der unterschiedlichen Auftraggeber eines ContactCenters. • Unterstützungsfunktionen: Anwendungssysteme für interne Dienstleistungen (wie Archivierung oder Bonitätsprüfung), die in Teilprozessen unterschiedlicher Geschäftsprozesse wiederverwendet werden. • Wissen und Schulung: Anwendungssysteme, die den Agenten das benötigte Wissen am Arbeitsplatz situationsgemäß darstellen. • Multikanal: Anwendungssysteme, die Endpunkte von Kontaktkanälen darstellen und meist zur sogenannten Selbstbedienung im jeweiligen Kanal dienen (wie zum Beispiel ein Sprachportal). • Routing: Anwendungssysteme, die dem Routing und der sonstigen Kontaktsteuerung dienen. • Agent-Desktop: Anwendungssysteme, die Agenten manuell am Arbeitsplatz bedienen und die einer speziellen Integration auf Basis der Benutzeroberfläche bedürfen.

8.4. Identifikation von Service-Typen In den folgenden Abschnitten wird zunächst der Beitrag der Identifikation von ServiceTypen zur übergeordneten Zielsetzung geklärt. Daran anschließend werden die identifizierten Service-Typen im Überblick dargestellt. Die dann folgenden Abschnitte behandeln die Service-Typen jeweils einzeln.

8.4.1. Beitrag zur Zielerreichung Die Beschreibung von Service-Typen folgt dem Architekturprinzip der Abstraktion von der Serviceimplementierung. Dadurch werden die Ziele der Integration, der Entkopplung und der Ausrichtung an Geschäftsprozessen und Fachanwendern direkt oder indirekt unterstützt. Die Zielsetzung der Integration manueller Tätigkeiten in die Servicegestaltung wird ebenfalls durch einen eigenen Service-Typ berücksichtigt. Eine Abstraktion wird grundsätzlich durch die fachliche Beschreibung der Serviceleistung (Was) und -nutzung (Wie) erreicht [vgl. bspw. Melzer, 2007, S. 13]. Da eine Identifikation einzelner Services nicht ohne einen unternehmens- und projektspezifischen Kontext möglich ist, werden Service-Typen identifiziert, die Services in Klassen mit ähnlicher Serviceausprägung gliedern. Wichtiger Input hierfür sind die Anwendungsdomänen. Je nach Serviceausprägung sind unterschiedliche Eigenschaften und differenzierte Implementierungsaspekte (vor allem Aspekte der Integration) von Bedeutung. Diese werden in den

190


Service-Typen beschrieben. Für die jeweiligen Service-Typen lassen sich idealtypische Umsetzungen, Standardnutzungen und Konventionen zur Modellierung entsprechender Prozessmodelle ableiten. Hierdurch wird eine konkrete Umsetzung erleichtert, da wesentliche Aspekte bereits vorgedacht sind und nur noch an die projektspezifischen Anforderungen und Gegebenheiten angepasst werden müssen. Service-Typen dienen so beispielsweise der Vorbereitung von Pflichtenheften und Architekturplanungen für konkrete Umsetzungen von Services. Fachliche Aspekte (vor allem die Vorbereitung und die Methodik zur Serviceidentifikation und zu Fragen der Granularität) werden anschließend im Abschnitt 8.5 mit Hilfe eines eigenen Prozessmodells behandelt. Technische Aspekte, vor allem Komponenten, die die Services zur Verfügung stellen, werden im Abschnitt 8.6 dargestellt. Die Unterscheidung der Service-Typen ist für beide Aspekte jeweils relevant.

8.4.2. Überblick über die Service-Typen Eine Analyse der entstandenen Domänenarchitektur lässt zunächst eine Zweiteilung für mögliche Service-Typen erkennen: fachliche Service-Typen und von der Kommunikationstechnik getriebene Service-Typen. Dies deckt sich mit dem dargestellten Status quo aus der Praxis, in dem parallel hierzu neben fachlichen Prozessbeschreibungen vor allem die sogenannten Kommunikationsprozesse als Teil technischer Workflows beschrieben werden (siehe Abschnitt 7.1.1). Es lassen sich hier bereits diese beiden Service-Typen abgrenzen: Fach-Service und Kommunikations-Service. Dies lässt bereits eine Integration der beiden Paradigmen Fach- und Kommunikationsprozesse in eine gemeinsame Prozesssteuerung erkennen. Beide Service-Typen sind jedoch als abstrakt zu betrachten. Sie werden durch detailliertere Service-Typen konkretisiert, die bestimmte Aspekte nochmals genauer betrachten. Folgende Abbildung 77 zeigt die identifizierten Service-Typen im Überblick:

Abbildung 77: Service-Typen-Diagramm Die nachfolgenden Abschnitte beschreiben jeweils die konkreten Service-Typen, die später umgesetzt werden.


191

8.4.3. Service-Typ Agenten-Service Ein Contact-Center wird geprägt durch seine Agenten. Der Agenten-Service beschreibt den Service-Typ, der die manuellen Bearbeitungen von Agenten in die Prozessautomatisierung einer SOA integriert. Allgemeine Beschreibung und Herleitung Der Agenten-Service ist eine Konkretisierung beziehungsweise genaue Gestaltung eines Services zur „human integration“, wie in Abschnitt 5.3.2 beschrieben. Ihm kommt auf Grund des Zusammenhangs zwischen persönlichem Kundenservice und manueller Tätigkeit (die sich gegenseitig bedingen) eine entsprechend große Bedeutung im Contact-Center zu. Fachlich wird ein Agenten-Service durch die Arbeitsaufgabe beschrieben, die ein Agent im Prozessgeschehen abdecken soll. Beispielhaft wäre dies eine Bestellung, die persönlich aufgenommen wird, ein Kundenservice zum Thema Garantieleistung oder eine manuelle Bonitätsprüfung. Aus technischer Sicht sind hier die Anwendungssysteme zu betrachten, die der Agent an seinem Arbeitsplatz manuell bedient. Diese sind nicht zu verwechseln mit Anwendungssystemen, beispielsweise aus der Anwendungsdomäne Kernprozesse, aus denen sich automatisierte Services ergeben (siehe Integrations-Service). Weiterhin wird der Agenten-Service geprägt von der Anwendungsdomäne Wissen und Schulung. Diese kapselt technische Services, die intern vom Agent-Desktop-System benutzt werden, um Wissensthemen zur Verfügung zu stellen. Fachlich hilft dies bei der Findung von Modellattributen beziehungsweise -objekten, die einen Agenten-Service noch genauer beschreiben (im Sinne von „welches dokumentierte Wissen ist für die Durchführung dieses Agenten-Service durch einen Mitarbeiter wichtig und muss am Arbeitsplatz dargestellt werden“). Operationen Auf abstrakter Ebene lässt sich im Rahmen des Referenzmodells für den Agenten-Service eine einzelne generische Operation identifizieren (siehe Tabelle 6).

192


Manuelle Arbeitsaufgabe zustellen

Input

Aus einer Untersuchung der [Contact-Group, 2007, detaillierte Prozessmodelle] lassen sich folgende Parameter für die Gestaltung eines manuellen Arbeitsschritts ableiten: • Eindeutige Beschreibung des Arbeitsschrittes für den Agenten • Auflistung zur Bereitstellung benötigter Anwendungssysteme am Arbeitsplatz des Agenten • Parameter zur Oberflächensteuerung obiger Anwendungssysteme zum vorab Laden, Fokussieren oder Befüllen der darin verwendeten Bildschirmmasken (um unnötige Navigation zum Zielfenster zu vermeiden) • Identifikation benötigter Daten (wie zum Beispiel die Kundennummer) und Business-Objekte • Navigation in Verzeichnisse und Dateien (zum Öffnen, Erstellen, Suchen und Speichern von Dokumenten) • Bereitstellung von Wissen in Systemen, mit denen der Agent Wissen im weitesten Sinne abrufen kann. Hierunter fallen beispielsweise: – firmeneigene Wikis (etwa zur Erklärung von Fachbegriffen) – Wissensportale, Internet, Intranet, eigene Suchmaschinen (eventuell mit den entsprechenden Suchbegriffen oder Parametern bereits aufgerufen) – Schulungsunterlagen, Arbeitsanweisungen und ähnliche Dokumente • Parameter für Systeme, die für die Kontaktbearbeitung des jeweiligen Kanals wichtig sind (Softphone, E-Mail-Client, Dokumenten-Management-Client)

Output

Vorgabe der möglichen Ergebnisse für diesen manuellen Arbeitsschritt (beispielsweise mögliche Ergebnisse einer Bonitätsprüfung: „Auftrag freigeben“, „Auftrag ablehnen“, „Vorauskasse fordern“) Tabelle 6: Operationen des Service-Typs Agenten-Service


193

Anwendungssysteme Der Agenten-Service umfasst Anwendungssysteme aus den Anwendungsdomänen Agent-Desktop und Wissen und Schulung. Dies sind zum einen Anwendungssysteme, deren Funktionen nicht mittels Services gekapselt werden können. Hierfür können verschiedene Gründe vorliegen: Ein Zugriff auf die Implementierung kann durch Mandanten verweigert werden (nur Benutzeroberfläche oder Clients verfügbar). Finanzielle Aspekte können ebenfalls gegen eine Integration mittels Services sprechen (hoher Aufwand oder geringe Häufigkeit). Einen weiteren Grund können Prozessabläufe darstellen, die bereits an der Oberfläche automatisiert wurden und beibehalten werden sollen. Implementierungs- und Integrationsaspekte Ein Agenten-Service stellt einem Agenten eine Aufgabe, einen sogenannten Task, zu. Dies ist im engeren Sinne die einzige Aufgabe (im Sinne einer Operation aus Sicht eines WSDL) des Agenten-Services. Die unterschiedlichen fachlichen Ausprägungen, die mit Hilfe dieses Service-Typs umgesetzt werden, werden durch Parametrisierung erreicht. Der Darstellung eines Tasks kommt demnach eine besondere Bedeutung zu. Die im SOA-Umfeld hierfür am weitesten fortgeschrittene Spezifikation ist „WS-Human Task“ (siehe Abschnitt 5.3.2). Für die Umsetzung empfiehlt sich eine Verwendung dieser Spezifikation, da sie einer Standardisierung am nächsten kommt. Hierbei sind die Besonderheiten eines Contact-Centers zu berücksichtigen und Anpassungen notwendig. Entsprechende Anpassungen werden in der Beschreibung zur Umsetzung im Abschnitt 8.6 dargestellt. Darin werden ebenfalls die notwendigen Anwendungssysteme beschrieben, die den Agenten-Service zur Verfügung stellen. Explizit nicht Teil der Implementierung eines Agenten-Service ist der Vorgang des Zuordnens eines Tasks zu einem geeigneten Agenten. Die Frage, welcher Agent zu welcher Zeit die manuelle Bearbeitung vornimmt, wird, entkoppelt vom Agenten-Service, vorher durch den Service-Typ Routing-Service geklärt. Als Besonderheit im Sinne der Integration bleibt für den Agenten-Service die Frage, wie die Anwendungssysteme der Applikationsdomänen Agent-Desktop und Wissen und Schulung in eine automatisierte Ablaufsteuerung integriert werden können. Eine differenziertere Unterscheidung der verschiedenen Sichten auf Integration ist hier sinnvoll. Abbildung 78 zeigt die drei möglichen Integrationssichten [nach Vogler, 2006, S. 83]: die Prozess-, die System- und die Desktopintegration. Die Prozessintegration dient der Ablaufsteuerung von Prozessen; dies geschieht in einer SOA mittels Ausführungssprachen (beispielsweise BPEL). Die Systemintegration realisiert Integrationsbeziehungen zwischen Anwendungssystemen (in einer SOA durch Bereitstellung und Aufruf von Services). Diese beiden Sichten wurden ausführlich im Kapitel 5 vorgestellt. Als weitere Möglichkeit kommt die Desktopintegration in Betracht. „[Sie] bringt die zur Erfüllung von Aufgaben notwendigen (heterogenen) betrieblichen Anwendungen an einem Arbeitsplatz zusammen. Sie stellt die Sichtweise des Benutzers, nicht so sehr die des gesamten Prozesses, in den Vordergrund“ [Vogler, 2006, S. 83].

194


Abbildung 78: Integrationssichten [aus Vogler, 2006, S. 83] Die Desktopintegration (auch Frontendintegration genannt) als Teil der IntegrationsTechnologien ist seit langem beschrieben [vgl. bspw. Derungs, 1997, Ruh et al., 2001], insbesondere Technologien wie Screen-Scrapping oder Terminalemulationen [vgl. Ruh et al., 2001, S. 22 ff.]. Die Anwendung der Technologie zur Bereitstellung von Services im Sinne einer SOA steht hier nicht im Fokus. Allerdings ist sie ein etablierter Teil in ContactCentern und häufig gängige Praxis zur Erfüllung kurzfristiger Projekte (neue Aufträge von Mandanten). Hierfür gibt es spezialisierte Anwendungssysteme, die diese Technologien nutzen und speziell für Contact-Center angepasst haben [bspw. Jacada, 2009, Microsoft, 2009a]. (Zum Funktionsumfang gehören beispielsweise Argumentationshilfen, Skriptautomatisierungen, Laden und Vorbefüllen von Fenstern). Die Desktopintegration muss deshalb mit in den Kontext der Prozessautomatisierung aufgenommen werden. Bindeglied hierfür ist der Agent beziehungsweise dessen Arbeitsplatz. Je nach Task werden am Arbeitsplatz unterschiedliche Anwendungssysteme (Applikationsdomäne AgentenDesktop) und daraus jeweils entsprechende Masken benutzt. Werden zum Zeitpunkt der Zustellung eines Tasks die speziell hierfür notwendigen Anwendungssysteme (zum Beispiel innerhalb des Agent-Desktops) in den Vordergrund gestellt, Masken geladen und vorab mit den bereits bekannten Daten befüllt, so führt dies zu einer Zeitersparnis und Verkürzung der Durchlaufzeit eines Tasks. Dies ist insbesondere der Fall, wenn einem Agenten zum Zwecke einer sinnvollen Kapazitätsauslastung nicht durchgängig Vorgänge der gleichen Art zugeteilt werden sondern diese abwechselnd auftreten. Als Folge dieser Abwechslung entstehen Rüstzeiten, die durch eine automatische Anpassung des elektronischen Arbeitsplatzes vermieden oder verringert werden können. Den funktionalen Umfang hierfür stellen Agenten-Desktop-Systeme zur Verfügung, die im Rahmen des Agenten-Services mit parametrisiert werden. Die dazu notwendigen Parameter zeigt obige Tabelle 6. Ähnlich gilt dies für die Präsentation von benötigtem Wissen am Arbeitsplatz. Hier ist eine Identifikation der Inhalte über entsprechende „Uniform Resource Identifier (URI)“ [vgl. Berners-Lee et al., 2005] sinnvoll. URIs gehören zu den notwendigen Parametern


195

eines Agenten-Service. Über diese Parameter wird die Darstellung des Tasks am Arbeitsplatz gesteuert. Eine Darstellung des Wissens geschieht gleichzeitig mit der Präsentation der Arbeitsaufgabe. Dabei können die Wissenssysteme und deren entsprechende Seiten ebenfalls geöffnet oder Links hierauf dem Agenten angeboten werden. Beispiel Nach einer automatisierten Kontostandsabfrage über ein IVR-System (siehe Abschnitt 2.3.1) erfolgt laut Geschäftsprozess zufallsgesteuert bei einigen Kunden eine persönliche Zufriedenheitsbefragung. Nach der Kontostandabfrage folgt als nächster Arbeitsschritt die Kundenbefragung durch einen Agenten. Hierfür benötigt der Agent mindestens die Bildschirmmaske mit den Kundenstammdaten aus dem Stammdatensystem (zur Begrüßung des Kunden) sowie die Bildschirmmaske mit dem Fragebogen (aus dem CRM-System). Zusätzlich gibt es ein Dokument mit einem Gesprächsleitfaden für diese Art der Kundenbefragung, das dem Agenten angezeigt werden soll. Dies ist insofern wichtig, da im Gespräch davor und danach jeweils andere Vorgänge zur Bearbeitung geroutet werden können. Von einer Bearbeitung nur eines Vorgangstyps über einen längeren Zeitraum kann nicht notwendigerweise ausgegangen werden. Zur Kapazitätsauslastung werden durch moderne Routingstrategien alle durch die Skills eines Agenten abgedeckten Kontakte zugestellt. Eine schnelle und automatische Anpassung des Arbeitsplatzes ist hierfür notwendig. 8.4.4. Service-Typ Multikanal-Service Ein weiteres Charakteristikum von Contact-Centern, im Vergleich zu anderen Unternehmen, ist deren spezieller Einsatz von Kommunikationstechnologie. Daraus ergibt sich als weiterer Service-Typ der Multikanal-Service, der diese Aspekte beinhaltet. Allgemeine Beschreibung und Herleitung Der Multikanal-Service leitet sich aus der Anwendungsdomäne „Multikanal“ ab. Er gruppiert die speziellen Anwendungssysteme der Kommunikationstechnik, über die fachliche Multimedia-Anwendungen implementiert sind, das heißt Anwendungen, die von Endkunden genutzt werden, wie beispielsweise die Selbstbedienung durch Sprachportale. Operationen Die Funktionalitäten und zugehörige Parameter des Multikanal-Services ergeben sich rein aus der Fachlichkeit und müssen beispielsweise mit Hilfe der Prozessmodellierung bestimmt werden. Die Operationen des Multikanal-Services bestimmen sich dann aus den modellierten Funktionen und Teilprozessen (beispielsweise „Legitimation des Kunden über IVR durchführen“). Technische Funktionalitäten einzelner Systeme (beispielsweise „zu Ansage XY umleiten“) werden weitestgehend gekapselt. Sie werden als technische Service-Operationen zur Verfügung gestellt, wenn dies aus Integrationsgründen notwendig ist. Diese Operationen (mit

196


feinerer Granularität) werden dann allerdings nicht in der Prozessorchestrierung verwendet sondern nur zu Integrationszwecken in anderen Services genutzt. Anwendungssysteme Hierunter fallen in erster Linie die Sprachportale und Systeme zur Selbstbedienung mittels Telefon, verschiedene Video- und Chat-Applikationen, Dialer-Systeme zum proaktiven Wählen und die Werkzeuge zur Qualitätskontrolle (siehe Abschnitt 2.3.1 „Technik“). Implementierungs- und Integrationsaspekte Die Implementierung von MultikanalServices bedarf der Integration von Systemen, die auf Grund der Einbettung in spezielle Kommunikationsnetzwerke oder -protokolle (zum Beispiel ISDN) nicht direkt an einen Enterprise-Service-Bus angebunden werden können. Hierfür sind spezielle Adapter oder manueller Programmieraufwand nötig. Beispielsweise bilden Nebenstellen der Telefonanlage die Schnittstelle zum Sprachportal. Bestimmend bei der Integration dieser Anwendungssysteme ist CTI (siehe Abschnitt 2.3.1). Zu berücksichtigen ist außerdem, dass es hier nur wenige offene Standards gibt. Zu nennen sind die Standards der „Computer Supported Telecommunications Applications (CSTA)“ [vgl. ECMA] sowie das „Telephony Application Programming Interface (TAPI)“ [vgl. Microsoft, 2009b] und ähnliche Protokolle. Viel zahlreicher sind proprietäre Herstellerspezifikationen und -technologien. Die Integration ist stark geprägt von den eingesetzten ACD-Anlagen, Telefonanlagen und anderen Systeme aus dem CTI-Bereich. Abbildung 79 gibt hierzu einen Überblick über die wichtigsten Standards und Technologien:

Abbildung 79: CTI-Standards [aus ITWissen, 2009, CTI-Standards] Mit zunehmendem Einsatz paketbasierter Netzwerke (hauptsächlich IP-Netze) zur Übertragung von Multimediadaten verschwimmt die bisherige Trennung zwischen Informationsund Kommunikationsnetzen, die CTI-Technologien notwendig machen. Hier ist vor allem das Protokoll SIP beziehungsweise VoIP zu nennen. Dessen Schwierigkeit besteht jedoch


197

darin, dass der Umfang der in SIP spezifizierten Funktionen für Contact-Center nicht ausreichend ist. Ein „Nicht-Bereit-Setzen“ eines Agenten am Telefon mit individuellem Pausengrund und Ähnliches ist zum Beispiel in SIP nicht vorgesehen. Hersteller von Telefonanlagen erweitern SIP deshalb proprietär. Dies ist ein weiterer Grund für die Kapselung dieser Gruppe von Anwendungssystemen in den Multikanal-Service. Die Liste der Systeme, Standards und Technologien muss im konkreten Unternehmenskontext entsprechend erstellt werden.

Beispiel Im Geschäftsprozess „allgemeine Bestellung bearbeiten“ erfolgt die Bestellaufnahme am Telefon durch den Agenten. Als abschließender Teilprozess des Geschäftsprozesses ist eine Umfrage zur Zufriedenheit mit der angebotenen Dienstleistung vorgesehen. Diese wird aus Gründen der Neutralität nicht vom Agenten ausgeführt sondern durch ein Sprachportal. In der Prozesssteuerung erfolgt nach dem Agenten-Service (der Bestellaufnahme) ein Multikanal-Service (die Zufriedenheitsbefragung). Hierzu muss durch den Serviceaufruf der Anruf auf das Sprachportal transferiert und die entsprechenden Skripte zur Zufriedenheitsbefragung müssen gestartet werden. Folgen im Prozessablauf noch weitere Schritte, müssen über die Service-Antwort (in diesem Beispiel) die Ergebnisse der Zufriedenheitsbefragung an die Prozesssteuerung zurückgegeben werden.

8.4.5. Service-Typ Integrations-Service Beim Integrations-Service handelt es sich um einen Service ohne manuellen Anteil mit normaler Integration von Anwendungssystemen, die über Services gekapselt werden (wie in Abschnitten 5.1 und 5.2 beschrieben).

Allgemeine Beschreibung und Herleitung Der Integrations-Service gruppiert die fachlichen Anwendungssysteme, aus denen sich Funktionalitäten komplett als Service abbilden lassen.

Operationen Funktionalitäten und deren Parameter ergeben sich ebenfalls rein aus der Fachlichkeit; sie können erst mit Hilfe der Prozessmodellierung bestimmt werden.

Anwendungssysteme Der Integrations-Service betrifft alle Anwendungssysteme, die für die fachliche Erbringung der Dienstleistungen eines Contact-Centers genutzt werden. Darunter fallen meist CRM- oder ERP-Systeme, da hier die Kunden- und Produktdaten bearbeitet werden. Die zugehörigen Applikationsdomänen sind Kernprozesse, Mandanten und Unterstützungsfunktionen mit eventuellen weiteren Untergliederungen in Branchen oder Produkte.

198


Implementierungs- und Integrationsaspekte Hier sind keine Besonderheiten zu nennen. Es findet eine normale Integration durch Services im Sinne einer SOA statt (vergleiche „Systemintegration“ im Sinne von Abbildung 78). Beispiel Ein automatisierter Geschäftsprozess sieht folgenden Ablauf vor: Nach der automatisierten Aufnahme einer Bestellung über ein Sprachportal (Multikanal-Service) wird die Bestellung dem ERP-System des Auftraggebers übergeben (Integrations-Service). 8.4.6. Service-Typ Routing-Service Im Vergleich zum Multikanal-Service geht es beim Routing-Service um eine technische Funktion (Transport des Kontakts innerhalb der technischen Infrastruktur), die im Geschäftsprozess als eine fachliche Funktion (Vermittlung, Weiterleitung) abgebildet wird. Im engeren Sinne ist der Routing-Service kein Service-Typ sondern ein konkreter Service, da er sowohl aus fachlicher als auch aus technischer Sicht nur eine Funktion zur Verfügung stellt. Allgemeine Beschreibung und Herleitung Der Routing-Service kapselt die Funktionalitäten der „Kommunikationsprozesse“, wie sie im Status quo der Praxis im Abschnitt 7.1.1 beschrieben sind. Für bestimmte Bearbeitungen werden passende Ressourcen zugeteilt, im Falle von Contact-Centern sind dies fast ausschließlich Agenten. Am häufigsten fallen hierunter das Routing von Telefongesprächen (zu bestimmten Geschäftsprozessen), teilweise auch die Integration einzelner asynchroner Kanäle wie E-Mail oder elektronische Dokumente (wie Faxe oder gescannte Briefe) in die Kontaktverteilung. Ziel ist die Steuerung von Kontakten (egal auf welchem Kanal) durch das Contact-Center und „durch den Prozess“. Operationen Auf abstrakter Ebene lassen sich im Rahmen des Referenzmodells für den Routing-Service zwei generische Operationen identifizieren. Nachfolgende Tabelle 7 beschreibt diese genauer:


Kontakt routen

Input

Zum Routing sind mindestens folgende Parameter notwendig: • Kontakt-ID: Objekt, das geroutet werden soll, bezeichnet durch einen eindeutigen Primärschlüssel • Kontakttyp: Beschreibung der Kontaktart, über die Steuerungsparameter bezüglich der Priorität, erlaubter Skills und Delegationen sowie einzuhaltender Fristen zugeordnet werden können (optional, sobald dies auf Geschäftsprozesse oder deren Teilprozesse im Prozessmodell zugeordnet wird) • Kanal: Bezeichner des Kanals, in dem der Kontakt vorliegt: Telefonie, E-Mail, elektronisches Dokument, Chat usw. (optional, sofern durch die Kontakt-ID eindeutig ein Kanal zuordenbar ist) • Ziel: Ziel des Routings in Form eines benötigten Skills, teilweise auch ein direkt spezifiziertes Ziel wie eine bestimmte Person oder eine bestimmte Nebenstelle (Eine Zustellung zu einem technischen Endpunkt wie IVR ist ebenfalls denkbar.)

Output

Ergebnis im Sinne eines konkreten Empfängers (Ziel war Skill „Finanz-Spezialist“, Ergebnis ist Zustellung an „Agent 1234 an Geräte-ID 5678“)

199

200


Ressourcen an-/abmelden

Input

Notwendige Aufgabe des Routings ist ebenfalls die fortlaufende Statuskontrolle der verwalteten Ressourcen (Ressource ist bereit oder nicht bereit). Hierzu müssen von extern Änderungen des Status möglich sein: • Statusänderung: Grundsätzlich das Bereit- und NichtBereit-Setzen einer Ressource. Hierzu zählen das grundsätzliche Login und Logout sowie kurzfristige Änderungen (bereit/ nicht bereit). • Kanal: Für welchen Kanal ist die Ressource nicht bereit (einzelne Kanäle, Gruppen von Kanälen oder alle). Beispielsweise kann ein Agent nicht bereit sein für asynchrone Kanäle wie E-Mail, jedoch bereit für Telefongespräche. • Grund: Für Statistikzwecke kann optional ein Grund für die Statusänderung mit angegebenen werden (beispielsweise Nicht-Bereit-Setzen wegen Pause, Besprechung oder Ähnlichem).

Tabelle 7: Operationen des Service-Typs Routing-Service

Anwendungssysteme Alleiniges Anwendungssystem, das durch den Routing-Service gekapselt wird, ist das Anwendungssystem zur Kontaktverteilung. Meist ist dies eine ACDAnlage (der sogenannte „Router“). Einen Überblick über Hersteller und Technologien hierzu geben beispielsweise [Kraus und Blood, 2007]. Implementierungs- und Integrationsaspekte Integrationsaspekte sind abhängig von der verwendeten Technologie der ACD-Anlage, wozu, analog dem Multikanal-Service, ebenfalls CTI-Technologien zum Einsatz kommen. Zum Funktionsumfang des RoutingServices gehört neben der Auswahl einer Ressource auch die Zustellung des Kontakts an die Ressource. Für einen Telefonanruf bedeutet dies die Vermittlung an die entsprechende Nebenstelle, für eine E-Mail kann dies die Weiterleitung an ein entsprechendes Postfach bedeuten. Andere Möglichkeiten ergeben sich durch die Zustellung einer URI und den Abruf durch das Agent-Desktop-System. Die Entscheidung, wie dies technisch umgesetzt wird, ist projektspezifisch. Unter Umständen kann es sein, dass der Routing-Service hierfür intern Multikanal-Services nutzt.

8.5. Entwicklung eines Contact-Center-Prozessmodells

201

Eine Besonderheit des Routing-Services sind Real-Time-Anforderungen bei gleichzeitig langlaufenden Operationen. Einerseits bestehen Real-Time-Anforderungen, um schnelle Entscheidungen in synchronen Kanälen treffen zu können. Hierzu gehören auch Rückmeldungen an den Telefonprovider (das Telekommunikationsunternehmen) noch vor Vermittlung von Gesprächen, um beispielsweise bei Überkapazitäten an andere Contact-Center zu vermitteln. Andererseits kommt asynchrone Kommunikation (asynchrone Services) zum Einsatz, da längere Zeitabschnitte zwischen Serviceaufruf (Kontakt soll geroutet werden) und Zuteilung einer freien Ressource liegen können. Dies wird durch CallbackFunktionalitäten gelöst. Insgesamt bedeutet die Kapselung der alleinigen Routingfunktionalität eine funktionale Einschränkung bisheriger ACD-Anlagen. Diese Abstraktion ist jedoch notwendig, auch wenn dies einen starken Eingriff in bestehende Strukturen und Implementierungsweisen bedeutet und für ACD-Anlagen große Investitionen getätigt wurden, weil nur so das SOAParadigma stringent umgesetzt werden kann.

Beispiel Ein Kunde bestellt telefonisch bei einem Agenten. Da es sich um einen hohen Gesamtbetrag handelt, ist im Geschäftsprozess eine Bonitätsprüfung durch einen Finanzspezialisten vorgesehen. Zwischen der Bearbeitung des Agenten und der Bearbeitung des Spezialisten ist ein Routing (Ressourcensuche und physikalischer Transport des Anrufs) notwendig. Das Handling des Anrufs in der Zwischenzeit übernimmt die Funktionalität des Routing-Services, beispielsweise befindet sich der Anruf während der Ressourcenzuteilung in einer Warteschlange.

8.5. Entwicklung eines Contact-Center-Prozessmodells Zur Entwicklung eines Contact-Center-Prozessmodells im Sinne eines Unternehmensprozessmodells (siehe hierzu Abschnitt 4.3.2) wird zunächst der Beitrag zur Zielerreichung geklärt. Daran anschließend werden die Hierarchiestufen des Prozessmodells sowie die sich daraus ergebenden Modelltypen und deren Konventionen vorgestellt.

8.5.1. Beitrag zur Zielerreichung Die Einführung eines Contact-Center-Prozessmodells genügt unten bezeichneten Architekturprinzipen und folglich den damit unterstützten Zielsetzungen: • An Geschäftskonzepten orientierte, grobe Servicegranularität: Geschäftsprozessmanagement – und darin enthalten Prozessmodelle – richtet sich grundsätzlich an Geschäftskonzepten aus. Da die Prozessmodelle zur Serviceidentifikation dienen, kann auch die Servicegranularität entsprechend gewählt werden.

202


• Fachliche Schnittstellenstandardisierung: Ein Prozessmodell besteht aus Teilschritten. Die Ein- und Ausgangsbeziehungen zwischen den einzelnen Teilschritten (deren Schnittstellen) beschreibt das Prozessmodell. • Generalisierung der Serviceleistung: Regeln zur inhaltlichen Gestaltung versuchen eine Generalisierung der Prozessschritte und somit auch der Serviceleistung [vgl. hierzu Stauss, 2006, Buxmann et al., 2008]. Manuelle Tätigkeiten werden dabei ebenso berücksichtigt. Die Generalisierung führt zur Wiederverwendung und Flexibilisierung. • Umfassende, einheitliche Servicespezifikation: Durch den Zusammenhang zwischen den Prozessmodellen und den Services, die diese umsetzen, spezifiziert das Prozessmodell einheitlich und umfassend die Fachlichkeit und somit den Inhalt von Services. • Verwendung offener und verbreiteter Industriestandards: Die Modellierung erfolgt innerhalb des Referenzmodells beispielhaft mit Hilfe der Notation ARIS. Teil des Referenzmodells ist der Vorschlag eines Prozessmodells, verschiedener Modelltypen und die Formulierung zugehöriger Modellierungskonventionen und Heuristiken (äußere und innere Ausgestaltungsregeln für konkrete Contact-Center-Prozessmodelle). Es wird dadurch zur Methode für die Identifikation von Services und deren Granularität. Konkrete Services können nur in konkreten Projekten und Unternehmen identifiziert werden, allerdings dienen die hier vorgestellten Prozesshierarchien, Modellkonventionen und Heuristiken als Vorgehensmodell und Hilfestellungen für konkrete Umsetzungen. Die vorgestellten Modelltypen und Vorgehensweisen können direkt übernommen und mit konkreten Inhalten angewendet werden. Die Methoden der Geschäftsprozessmodellierung (siehe hierzu Abschnitt 4.3.2) sehen folgenden Aufbau von Modellierungskonventionen vor [vgl. Rosemann et al., 2005, S. 99 100], der hier entsprechend angewandt wird: • Ziel und Geltungsbereich: Der Geltungsbereich erstreckt sich auf Contact-Center nach der Definition aus Kapitel 2. Ziel ist die Abbildung eines Sollzustandes zur Automatisierung der Geschäftsprozesse nach Aufnahme der Ist-Situation. • Organisatorische Rahmenbedingungen: Diese sind im Rahmen des Referenzmodells nicht darstellbar. Grundsätzlich muss es im Contact-Center Rollen im Sinne der Prozessverantwortlichen nach der Maßgabe des Abschnitts 4.1.3 „Prozessorientierung und Prozessorganisation“ geben. • Prozessmodellarchitektur, Konventionen für Modelltypen und Perspektiven: Diese werden in den Abschnitten 8.5.2 bis 8.5.5 vorgestellt. • Technische Hinweise: Technische Hinweise zur Verwendung von Modellierungswerkzeugen können nur in konkreten Umgebungen gegeben werden. Im Referenzmodell wird die ARIS-Notation verwendet (siehe Exkurs in 4.3.3). Dies ist beispielhaft. Es sind andere Methoden und Werkzeuge jederzeit möglich.


203

• Anlagen: Die nachfolgenden Abschnitte werden durch Grafiken und Best-PracticeBeispiele ergänzt, die in konkreten Konventionsvorgaben verwendet werden können.

8.5.2. Überblick über das Contact-Center-Prozessmodell Die unternehmerische Wertschöpfung ist modular und hierarchisch aufgebaut und bedarf der Einteilung in abgestufte Detaillierungsebenen (vergleiche hierzu Abschnitt 4.3.1). Für die Gliederung der Wertschöpfung in Contact-Centern wird eine Abstufung wie in Abbildung 80 vorgeschlagen.

Abbildung 80: Hierarchieebenen des Contact-Center-Prozessmodells Die einzelnen Hierarchiestufen grenzen sich wie folgt voneinander ab: 1. Geschäftsfeld: Das Geschäftsfeld bezeichnet die Unterscheidung nach Art der Tätigkeiten des Unternehmens nach den Einteilungen „homogene Produktpalette – spezifischer Markt“ [vgl. Jung, 2007, S. 314]. Die Contact-Center-Produktpalette ist bestimmt von Dienstleistungen der Kundenbetreuung, meist in direkter Beziehung zum Endkunden über verschiedene Kontaktkanäle. Daraus lässt sich in vielen Fällen ein einzelnes Geschäftsfeld „Kunde betreuen“ ableiten. 2. Kernprozess: In Kernprozessen wird die Hauptleistung erbracht [vgl. Staud, 2006, S. 11]. Darin ist diejenige Gruppe von Prozessen gemeint, in denen die eigentliche Wertschöpfung erbracht wird. Hier ist die Gruppierung in Oberbegriffe gemeint, wie sich die Wertschöpfung durch „Kunde betreuen“ genauer zusammensetzt.

204


3. Hauptprozess: Ein Hauptprozess ist eine „Kette homogener Aktivitäten, die demselben Kosteneinflussfaktor unterliegen“ [Horváth und Mayer, 1993, S. 16]. Dabei gibt es möglichst wenige Hauptprozesse, die jeweils einen großen Teil der Gemeinkosten bestimmen. 4. Geschäftsprozess: Der Geschäftsprozess wird festgelegt als Instrument zur Umsetzung der Kundenorientierung. Das heißt, der Geschäftsprozess enthält die konkrete Abfolge der notwendigen Tätigkeiten vom Kundenwunsch bis zu dessen Erfüllung. 5. Teilprozess: Teilprozesse sind logisch abgeschlossene Teile eines Geschäftsprozesses. 6. Aktivität: Eine weitere Unterteilung eines Teilprozesses in unteilbare Arbeitsaufgaben [in Anlehnung an Kloppmann et al., 2005, S. 14] ergibt Aktivitäten. Sie sind unteilbar, da Teilung aus fachlicher Sicht nicht nötig oder nicht sinnvoll ist. 7. Weitere Unterteilungen: Aus technischen Gründen können weitere Untergliederungen möglich sein, sie werden jedoch hier nicht modelliert. Das Prozessmodell folgt grundsätzlich dem Ziel der Umsetzung der Kundenorientierung mittels Geschäftsprozessen, der Clusterung oberhalb dieser Ebene und der Verfeinerung unterhalb. Im Bereich des Clusterns werden die Entitäten nur namentlich identifiziert, Inhalte werden nicht modelliert. Ab der Hierarchie der Geschäftsprozesse findet eine Modellierung (Darstellung) der Inhalte statt. Mit jeder weiteren untergeordneten Hierarchiestufe findet eine Detaillierung statt: Es wird dabei immer exakt die Entität inhaltlich detailliert, die in der Hierarchie darüber namentlich genannt wurde (Geschäftsprozess A besteht aus Teilprozess A.1, A.2 und A.3. Teilprozess A.3 besteht aus Aktivitäten A.3.1, A.3.2 und A.3.3.). Die Wertschöpfung wird so inhaltlich komplett dargestellt und klar in Hierarchien abgestuft. Dadurch lassen sich Granularitäten finden und spezifizieren. Für die Umsetzung als Service können geeignete Hierarchien ausgewählt werden. Im Fall des Referenzmodells erfolgt eine Auslegung der Modellierungskonventionen für eine Umsetzung der Modelltypen Teilprozess und Aktivität als Service. Weitere Verwendung findet das entwickelte Prozessmodell als Input für die Gestaltung der Ereignisorientierung. Genaueres folgt hierzu im Kapitel 9 „Steuerung und Überwachung durch Ereignisorientierung“.

8.5.3. Prozessmodell Prozesslandkarte Die Erstellung einer Prozesslandkarte ist der erste Schritt zur konkreten Gliederung der Wertschöpfung im Contact-Center. In der Prozesslandkarte werden die identifizierten Geschäftsfeld(er), Kernprozesse, Hauptprozesse und Geschäftsprozesse namentlich genannt und den Hierarchieebenen zugeordnet. Sie dient letztendlich dem Finden von


205

Geschäftsprozessen (Identifikation von „echten“ Kundenwünschen) und der Darstellung der Prozesslandschaft eines Contact-Centers im Überblick. Modellierungskonventionen (Gestaltung der äußeren Form) Die Darstellung der Prozesslandkarte erfolgt innerhalb des Referenzmodells mit Hilfe des ARIS-Diagrammtyps Wertschöpfungskettendiagramm. Folgende Modellierungskonventionen zur Gestaltung der äußeren Form werden dabei verwendet: Objekt

Verwendung

Objekttyp Wertschöpfungskette • Darstellung durch namentliche Bezeichnung jeweils eines Geschäftsfelds, Kernprozesses, Hauptprozesses oder Geschäftsprozesses mit Hilfe einer Wertschöpfungskette. • Benennung nach „Informationsobjekt und Verb der Verrichtung“ plus Zusatz für Prozesshierarchie (GF = Geschäftsfeld, KP = Kernprozess, HP = Hauptprozess, GP = Geschäftsprozess). Beispiel: „Kunde betreuen GF“, „Kundenservice durchführen KP“, „Lieferservice durchführen HP“, „Rückholung veranlassen GP“. Wertschöpfungsketten werden untereinander mit Kanten verbunden. Innerhalb derselben Hierarchieebene erfolgt die Verbindung mit Hilfe des Kantentyps „ist Vorgänger von“. Dies ist optional, da nicht immer eine Vorgängerbeziehung identifizierbar ist. Verbindung von Wertschöpfungsketten mit der hierarchisch direkt übergeordneten Wertschöpfungskette erfolgt mit Hilfe des Kantentyps „ist prozessorientiert übergeordnet“. (Zum Beispiel die Kernprozesse eines Geschäftsfelds oder die Geschäftsprozesse eines Hauptprozesses). Wertschöpfungsketten, die einen Geschäftsprozess darstellen (namentlich bezeichnen), werden mit einer Hinterlegung (Verknüpfung, Link) des zugehörigen Prozessmodells des Geschäftsprozesses verknüpft (Modelltyp „Geschäftsprozess“). Tabelle 8: Modellierungskonventionen für die Prozesslandkarte

206


Heuristiken zur inhaltlichen Gestaltung Für das Finden der einzelnen Entitäten in den jeweiligen Hierarchiestufen können folgende Kriterien als Hilfestellungen und mögliche Fragen verwendet werden: • Verständnisfragen zur ersten Annäherung: Konkrete Fragestellungen zur Erarbeitung der Prozesse in den Hierarchiestufen. Die Antworten sollen so formuliert werden, dass sie (i) in maximal fünf Sekunden die Frage beantworten und (ii) diese möglichst nur mit einem Satz oder einer Aussage beantwortet wird. Diese Art der Fragestellung wird im weiteren Verlauf als „5-Sekunden-Regel“ bezeichnet. Teile der Aussagen lassen sich ähnlich weiter hinterfragen. Somit ist eine Top-DownFragestellung möglich. Am Beispiel der [Contact-Group, 2007, Prozesslandkarte] verdeutlicht sieht die Fragestellung wie folgt aus: Frage: „Was ist Inhalt Ihres Unternehmens?“, Antwort: „Wir betreuen die Kunden unserer Mandanten“ – Frage: „Wie sieht die Kundenbetreuung aus?“, Antwort: „Wir bieten Beratungs-, Bestell- und Serviceleistungen an“ – und so weiter. Aus den Antworten lassen sich erste Erkenntnisse über Entitäten der Hierarchiestufen gewinnen. • Kundenorientierung: Klärung der Frage, welche Kundenwünsche eigentlich im Contact-Center bearbeitet werden: Mit welchen Anliegen wenden sich die Kunden an das Contact-Center? Daraus lassen sich Kandidaten für mögliche Geschäftsprozesse ableiten. Verallgemeinerungen oder Generalisierungen können notwendig sein. • Eingangskanäle: Endpunkte der Eingangskanäle deuten auf Kundenwünsche (Geschäftsprozesse) oder inhaltliche Gruppierungen (Hauptprozesse, Kernprozesse) davon hin: Welche unterschiedlichen Servicerufnummern, E-Mail-Adressen, Webformulare, Faxnummern, Kategorien gescannter Eingangspost, Postfächer, Stichwörter, Adressen für Postsendungen und so weiter gibt es? Welche einzelnen Kundenwünsche werden darüber geklärt? • Beteiligte Organisationseinheiten: Welche Organisationseinheiten (Abteilungen oder Gruppen) gibt es? Welche davon haben direkten Kundenkontakt oder bekommen Dokumente von Kunden? Welche Anliegen (Kundenwünsche) liegen zu Grunde? • Gliederung ähnlicher Kundenwünsche: Hauptprozesse gliedern ähnliche, inhaltlich nah verwandte Geschäftsprozesse. Mögliche Kriterien sind gleiche Fachgebiete (zum Beispiel Arten von Bestellungen), gleiche Mandanten, gleiche Gemeinkostenbasis und weitere. • Heterogene Workshops: Erarbeitung der Prozesslandkarte in heterogenen Projektworkshops unter Beteiligung von Know-How-Trägern aus unterschiedlichen Disziplinen und Organisationseinheiten. Dabei werden die oben genannten Fragestellungen beantwortet. Überprüfung der Ergebnisse durch die Fragestellung, ob Vertreter der anderen Abteilungen diese Einteilung genauso sehen (zur Vermeidung der Abbildung bestehender Organisationsstrukturen in den Prozessen).


207

• Reihung der Wertschöpfung: Kernprozesse sollten, wenn möglich, in eine Reihenfolge gebracht werden. Die Verbindung zwischen den Wertschöpfungsketten bilden Kanten des Typs „ist Vorgänger von“. Soweit möglich, sollte eine Darstellung der gesamten Wertschöpfung in logisch angeordneten Unterteilungen erfolgen. Die Kernprozesse der [Contact-Group, 2007, Prozesslandkarte] lassen sich folgendermaßen anordnen: Nach Beratung folgt Bestellung, gefolgt von Kundenservice, unterstützt von allgemeinen Dienstleistungen. Obwohl Geschäftsprozesse einzeln für sich „abgerufen“ werden, ist zumindest theoretisch eine Wertschöpfungsreihenfolge gegeben.

Beispiel Abbildung 81 zeigt beispielhaft eine Prozesslandkarte als Wertschöpfungskettendiagramm.

Abbildung 81: Beispiel einer Prozesslandkarte

208


8.5.4. Prozessmodell Geschäftsprozess Der Modelltyp „Geschäftsprozess“ stellt die notwendigen Teilschritte und Ereignisse in ihrer logischen Reihung dar, die mit einem Kundenwunsch beginnen und bis zur Erfüllung des Kundenwunsches notwendig sind. Modellierungskonventionen (Gestaltung der äußeren Form) Der Modelltyp „Geschäftsprozess“ nutzt den Objektvorrat des ARIS-Diagrammtyps EPK und schränkt diesen durch die Verwendung der folgenden Modellierungskonventionen ein. Alle möglichen Objekte werden über Kanten analog des logischen Ablaufs verbunden. Funktionen (beziehungsweise Automationen) wechseln sich jeweils mit Ereignissen ab. Objekt

Verwendung

Objekttyp Automation • Verwendung für Teilprozesse, die der Kommunikationssteuerung im Geschäftsprozess dienen. • Benennung nach dem Muster „Informationsobjekt (optional Adverbiale) und Verb der Verrichtung“ plus Zusatz TP für Teilprozess (zum Beispiel „Spezialist für Bonitätsprüfung zuordnen TP“). • Funktionen nennen Teilprozesse namentlich, sie werden mit dem Prozessmodell des Teilprozesses hinterlegt. Objekttyp Funktion • Verwendung für alle anderen Teilprozesse, die fachliche Inhalte abdecken (zum Beispiel „Kreditantrag erfassen TP“). • Benennung und Hinterlegung analog dem Objekttyp Automation.


Objekt

Verwendung

Objekttyp Ereignis • Fachliche Benennung nach dem Muster „Informationsobjekt und Partizip“ (zum Beispiel „Kreditantrag ist erfasst“). • Verwendung vor und nach Funktion beziehungsweise Automation. Jeweils ein oder mehrere Ereignisse möglich. Objekttyp Startereignis • Geschäftsprozess beginnt mit einem oder mehreren Startereignissen. • Ein Startereignis hat nur ausgehende Kanten. • Benennung analog Objekttyp „Ereignis“ Objekttyp Endereignis • Geschäftsprozess endet mit einem oder mehreren Endereignissen. • Ein Endereignis hat nur eingehende Kanten, es muss als letztes Ereignis in einem Pfad stehen. • Benennung analog Objekttyp „Ereignis“

209

210


Objekt

Verwendung

Objekttyp Regel • Regeln spezifizieren Beziehungen zwischen Ereignissen und Funktionen beziehungsweise Automationen. • UND nach Ereignissen: alle Ereignisse müssen eintreten; UND vor Funktionen: Funktionen finden parallel statt; UND nach Funktion: alle Ereignisse treten ein. • XOR nach Ereignissen: Exakt nur eines der Ereignisse tritt ein; XOR nach Funktionen: Funktion löst jeweils nur eines der möglichen Ereignisse aus. • ODER-Regeln sind nicht zulässig.

Tabelle 9: Modellierungskonventionen für Geschäftsprozesse

Heuristiken zur inhaltlichen Gestaltung Für das Finden der einzelnen Teilprozesse (namentliche Nennung), Ereignisse und Regeln sind folgende Kriterien und Fragen hilfreich. • Verständnisfragen zur weiteren Vertiefung: Weitere Vertiefung mit Hilfe konkreter Fragen nach der 5-Sekunden-Regel (siehe Seite 206): Wie wird der Kundenwunsch befriedigt? Welche groben Schritte, Teilergebnisse und so weiter sind hier notwendig? („Ein Kreditantragsprozesse setzt sich zusammen aus: Formaler Prüfung, Ergebnissen von Auskunfteien, Prüfung der Sicherheiten, aus der eigentlichen Kreditprüfung und der Ausfertigung des Kreditvertrags beziehungsweise des Ablehnungsschreibens“.) Welche Gesamtergebnisse des Geschäftsprozesses sind möglich („Kredit ist genehmigt“, „Kredit ist abgelehnt“)? Gibt es weitere Unterscheidungsmöglichkeiten? Welche sind die wesentlichen Pfade im Prozessablauf, welche wesentlichen Entscheidungen gibt es innerhalb des Geschäftsprozesses („Schufa-Auskunft ist positiv, negativ oder zweifelhaft ...“)? • Startereignisse über Kontaktkanäle: Die Identifikation möglicher Startereignisse kann über die vorhandenen Eingangskanäle erfolgen (Kunden kommen über diese Kanäle erstmalig in Kontakt mit dem Contact-Center). Sie werden im Prozessmodell modelliert und fachlich formuliert (zum Beispiel „Kunde wünscht Bestellung“). Technische Details hierzu werden in den Eigenschaften der Ereignisse hinterlegt (zum Beispiel die Rufnummer des Services oder die verwendete E-Mail-Adresse).


211

• Multiple Ereignisse: Ein Geschäftsprozess beziehungsweise seine Teilprozesse können von verschiedenen Ereignissen ausgelöst werden (am Beispiel von Startereignissen etwa differenziert nach Kanälen: „Kunde wünscht telefonische Bestellung“ sowie „Kunde bestellt per E-Mail“). Ereignisse werden so festgelegt, dass konkrete Prozessinstanzen jeweils von nur einem Ereignis gestartet werden. Die Reihe der möglichen auslösenden Ereignisse zeigt das Prozessmodell. • Beteiligte Organisationseinheiten und Skills: Welche Organisationseinheiten (Abteilungen, Stellen, Gruppen) und Skills sind am Geschäftsprozess beteiligt? Was ist deren inhaltlicher Beitrag? Unter Umständen lässt dies Rückschlüsse über mögliche Teilprozesse zu. Notwendige Weiterleitungen zwischen Organisationseinheiten oder Skills werden ebenfalls als Teilprozess identifiziert (siehe unten). • Stellenprofile: Tätigkeiten aus Stellenbeschreibungen oder Stellenprofilen können mögliche Kandidaten für Teilprozesse sein (ein Finanzspezialist kann „Bonität prüfen“, „Sonderkonditionen gewähren“, „Zweifelhafte Aufträge freigeben“ und so weiter). Eine Kombination dessen erfüllt einen Kundenwunsch (Geschäftsprozess), die Tätigkeiten ließen sich noch weiter untergliedern (Aktivitäten). Die Fragen „interessant, wie prüft man die Bonität?“ müsste leicht zu beantworten sein, beispielsweise „zunächst muss das bisherige Zahlungsverhalten anhand des Kontos geprüft werden, dann ist eine Schufa-Auskunft einzuholen und schließlich ... Aus all diesen Ergebnissen komme ich zu meiner Entscheidung.“ • Fachlichkeit und Kommunikation: Vorgänge (hauptsächlich das Routing), die bisher in Kommunikationsprozessen implementiert wurden, werden explizit als Teilprozess aufgenommen. Kommunikationsanteile werden explizit fachlich benannt. Dies geschieht nach dem Muster „benötigte Ressource + nachfolgende Tätigkeit + Verb der Verrichtung“, beispielsweise „Spezialist für Bonitätsprüfung zuordnen“. Das auslösende Ereignis oberhalb des Kommunikations-Teilprozesses wird entsprechend formuliert, zum Beispiel „Sachbearbeiter für Bonitätsprüfung ist notwendig“ („benötigte Ressource + gewünschte Tätigkeit + Partizip“). • Inhaltliche Kohäsion und Volatilität: Volatilität hat Einfluss auf die Abfolge (Anordnung) der Teilprozesse untereinander, nicht aber auf deren innere Abfolge und Struktur. Teilprozesse sind entsprechend so zu identifizieren und abzugrenzen, dass sie inhaltlich abgeschlossen und unabhängig sind. Teil einer Bestellung kann beispielsweise eine Ratenzahlung oder Finanzierung sein. Die Erfassung der Finanzierung wäre ein Teilprozess. Dieser kann auch in anderen Geschäftsprozessen vorkommen (etwa Teil eines Reparaturauftrags, der über Ratenzahlung abgerechnet wird), der Teilprozess an sich bleibt aber der Gleiche in beiden Geschäftsprozessen. Welche dieser Teilfunktionen gibt es insgesamt? • Kanalkohäsion: Kanalwechsel und Routing finden nicht verdeckt innerhalb von Teilprozessen statt. Entsprechend sind einzelne Teilprozesse im Geschäftsprozess zu unterscheiden.

212


• Rückbezug der Ereignisse: Für die Benennung von Ereignissen gilt grundsätzlich ein inhaltlicher Rückbezug zur vorangestellten Funktion beziehungsweise Automation. Ereignisse stellen die möglichen „Ergebnisse“ von Funktionen oder Automationen dar („Kredit ist genehmigt“, „Kredit ist abgelehnt“). Entsprechend sind auch auslösende Ereignisse für Kommunikations-Teilprozesse als Ergebnisse der Vorgängerfunktion zu modellieren. Die Ergebnisse des Transports werden ebenfalls als Ereignisse entsprechend fachlich formuliert (beispielsweise „Agent für Bonitätsprüfung ist zugeordnet“ und „Kein Agent verfügbar“). Ausnahmen bilden Startereignisse (sie formulieren den Kundenwunsch: „Kunde wünscht Bestellung“) und Endereignisse (sie formulieren das Gesamtergebnis des Geschäftsprozesses: „Bestellung ist erfolgreich abgeschlossen“ beziehungsweise „Bestellung ist abgelehnt“). • Gegenseitiger Ausschluss der Ergebnisse: Ergebnisse von Funktionen und Automationen sind so zu wählen, dass für jede Prozessausführung (Instanz) jeweils nur ein Ergebnis eintritt. Das Prozessmodell Geschäftsprozess modelliert alle möglichen Ergebnisse, diese werden über die Regel „XOR“ mit der Funktion beziehungsweise Automation verbunden. Parallele Abläufe sind zulässig, sie werden mit Hilfe der Regel „UND“ modelliert. • Generalisierung (Geschäftsprozessebene): Optimierung von Geschäftsprozessen, so dass sie generalisieren und mehrere Anwendungsfälle abdecken. Mögliche Unterscheidungskriterien sind beispielsweise die Mandanten: Lassen sich ähnliche Geschäftsprozesse (zum Beispiel Bestellungen für unterschiedliche Mandanten) mit einem Geschäftsprozess abdecken (generalisierte Oberfläche, Zuordnung der Business-Objekte zu den Anwendungssystemen innerhalb eines Services)? • Idealtypische Darstellung: Geschäftsprozesse sollen so dargestellt werden, wie sie idealtypisch ablaufen sollen. Sie stellen einen Soll-Zustand dar, der sich aus einer Optimierung ergibt, und dienen einem späteren Vergleich mit tatsächlich aufgezeichneten Abläufen. Sie sind auf Grund der Volatilität immer idealtypisch. Abweichungen (Sprünge, Wunschänderungen), die im direkten Kundenkontakt durchaus möglich sind, werden nicht modelliert (Kunde wollte eigentlich bestellen, wünscht jetzt aber zwischendurch eine Adressänderung). • Auswahlprozess: Können Startereignisse für Geschäftsprozesse nicht direkt aus Ereignissen der Kontaktkanäle abgeleitet werden, etwa weil alle Kundenanfragen an eine Sammelnummer oder eine einzige E-Mail-Adresse gehen, so kann ein Geschäftsprozess vorgeschaltet werden, der die jeweiligen Kundenwünsche ermittelt. • Applikationsdomänen: Bei welchen Tätigkeiten unterstützen die einzelnen Anwendungssysteme der Applikationsdomänen Kernprozesse und Querschnittsfunktionen? Welche Ergebnisse liegen nach Benutzung vor (beispielsweise Kontobewegungsdaten und Auskunftei für die Bonitätsprüfung mit möglichen Ergebnissen „Bonität ausreichend“ und „Bonität mangelhaft“)?


213

Beispiel Abbildung 82 zeigt einen Geschäftsprozess „Bestellung bearbeiten GP“63 .

Abbildung 82: Bestellung bearbeiten GP

8.5.5. Prozessmodell Teilprozess Der Modelltyp „Teilprozess“ detailliert die Vorgänge, die innerhalb des Modelltyps „Geschäftsprozess“ als Funktion beziehungsweise Automation modelliert werden. Diese sind 63

Die Beistellung der Akronyme „GP“ und „TP“ innerhalb von Prozessbezeichnung folgt den Modellierungskonventionen (beispielsweise Seite 205) und dient der Bezeichnung der Hierarchieebene, die aus dem Objekt und dem Verb der Verrichtung alleine nicht ersichtlich ist.

214


mit dem zugehörigen Teilprozessmodell hinterlegt, wodurch eine zunehmende Detaillierung erreicht wird. Modellierungskonventionen (Gestaltung der äußeren Form) Der Modelltyp „Teilprozess“ nutzt ebenfalls den Objektvorrat des ARIS-Diagrammtyps EPK und schränkt diesen durch die Verwendung der folgenden Modellierungskonventionen ein. Automationen und Interaktionen wechseln sich im Ablauf mit Ereignissen ab. Sie werden mit Kanten verbunden und bilden so den logischen Ablauf ab. Alle weiteren Objekte beschreiben die Automationen und Interaktionen näher; sie sind mit diesen mit Kanten verbunden. Kanten-Typen bezeichnen die Art der Verbindung näher (zum Beispiel „ist Input von“). Objekt

Verwendung

Objekttyp Interaktion • Verwendung für manuelle Tätigkeiten • Benennung nach dem Muster „Informationsobjekt (optional Adverbiale) und Verb der Verrichtung“ • Hinterlegungen mit technischen Modellen optional Objekttyp Automation • Verwendung für automatisierte Prozessschritte • Benennung und Hinterlegung analog Interaktion Objekttyp Ereignis • Analog Ereignisse im Prozessmodell „Geschäftsprozess“ • Ereignisse vor und nach dem Teilprozess als Funktion oder Automation im Geschäftsprozess bilden die Start- und Endereignisse des Teilprozesses und werden als Ausprägungskopien übernommen. • Benennung analog Ereignisse im Geschäftsprozess


Objekt

Verwendung

Objekttyp Regel • Analog Geschäftsprozess Objekte zur Erweiterung von Interaktion und Automation:

Objekttyp Anwendungssystemtyp • An Interaktion: Verwendetes Anwendungssystem am Arbeitsplatz (mehrere möglich) • An Automation: Anwendungssystem, das die Automation implementiert Objekttyp Maske • An Interaktion: Bezeichnung der (Bildschirm)Maske, die für die manuelle Bearbeitung notwendig ist Objekttyp Attribut • Darstellung benötigter und/oder erzeugter Attribute und deren Beziehungen • Mögliche Kantentypen: „ist Input für“, „ist Output von“ • In- und Outputbeziehungen eines Attributs können mit mehreren Interaktionen und Automationen verbunden werden

215

216


Objekt

Verwendung

Objekttyp Elektronisches Dokument • An Interaktion: Elektronisches Dokument, das Wissen zur unmittelbaren Unterstützung des Agenten bei der Ausführung der manuellen Tätigkeit (bezeichnet in der Interaktion) dokumentiert • Zum Beispiel Arbeitsanweisungen, Links auf Webseiten, firmeninterne oder externe Wiki-Seiten und so weiter • Die URI des Dokuments wird als Objektattribut erfasst. Objekttyp Dokumentiertes Wissen • An Interaktion: Sonstiges dokumentiertes Wissen zur Unterstützung des Agenten für die Interaktion, das nicht elektronisch vorliegt • Zum Beispiel Hinweis auf bestimmte physikalische Dokumente (beispielsweise „Arbeitsanweisung Kreditvergabe“) Objekttyp Service • Bezeichnung des Services, der diese Interaktion oder Automation implementiert Objekttyp Funktion • Bezeichnung der Operation des Services (siehe oben) • Operation wird mittels einer Kante mit dem Objekttyp „IS Service“ verbunden.


Objekt

217

Verwendung

Objekttyp Skript • An Interaktion: Parameter für Agenten-DesktopSysteme zur Steuerung der Interaktion • Beispielsweise Skripte zur Desktop-Integration oder einzublendende Argumentationshilfen Objekttyp Personentyp • An Automation: Benötigter Skill (Ressource) für das Routing

Tabelle 10: Modellierungskonventionen für Teilprozesse

Heuristiken zur inhaltlichen Gestaltung Für das Finden der einzelnen Aktivitäten eines Teilprozesses (namentliche Nennung) sowie die beinhalteten Ereignisse und Regeln sind folgende Kriterien und Fragen hilfreich: • Verständnisfragen zur weiteren Vertiefung: Die Detaillierung der Teilprozesse kann mit Hilfe der Fragestellungen nach der 5-Sekunden-Regel analog der Prozesslandkarte und den Geschäftsprozessen (siehe Seiten 206 und 210) weiter vertieft werden. Wichtige Fragestellungen sind hierbei die notwendigen Arbeitsschritte am Arbeitsplatz sowie Teilinformationen, die für einen jeweiligen Arbeitsschritt zusammengetragen werden müssen. Auf die Frage, wie sich beispielsweise der Teilprozess „Kreditsicherheiten prüfen TP“ genauer zusammensetzt, könnte eine mögliche Antwort lauten: Hierfür muss das bisherige Zahlverhalten, das Gesamtobligo sowie Risikoabfragen bei den Auskunfteien A und B eingeholt werden und die Einzelergebnisse abschließend bewertet werden. • Applikationsdomänen: Automatisierte Aktivitäten definieren sich innerhalb einer Applikationsdomäne. Entscheidend ist hier die Fachlichkeit im jeweiligen Unternehmen. • Manuelle Tätigkeiten: Bei der Identifikation manueller Tätigkeiten sind Abfolgen von Bildschirmmasken hilfreich: Nicht jede einzelne Bildschirmmaske spricht für eine manuelle Tätigkeit. Welche Folge von Bildschirmmasken ist notwendig, um ein bestimmtes Ergebnis zu erhalten? Welche Bildschirmmasken machen isoliert genutzt keinen Sinn? Beispielhaft könnte eine manuelle Tätigkeit „Kreditwürdigkeit prüfen“

218

8. Automatisierung durch Serviceorientierung sich aus der Interpretation folgender Bildschirmmasken ergeben: Kontendaten, das historische Zahlverhalten (Kontobewegungen) und die Adressdaten.

• Generalsierung (Teilprozessebene): Lassen sich Funktionen (Teilprozesse) finden, die auch in anderen Geschäftsprozessen verwendet werden können? Ziel ist die Bildung eines „Pools“ an Teilprozessen, die allesamt wiederverwendet werden und aus denen sich zukünftige, ähnliche Geschäftsprozesse, ebenfalls ohne Anpassung, zusammenstellen lassen können. Die identifizierten Sub-Domänen der Applikationsdomäne Kernprozesse dienen als wichtiger Anhaltspunkt hierfür. Ein Teilprozess spezifiziert Aktivitäten, indem sie mit Hilfe der Objekte Interaktion und Automation benannt werden. Eine weitere Detaillierung findet im Rahmen des ContactCenter-Prozessmodells nicht statt, da aus fachlicher Sicht eine ausreichende Detaillierungstiefe für die Serviceidentifikation erreicht ist. Eine zusätzliche Hinterlegung mit technischen Modellen, die die Aktivitäten ausführen ist möglich und sinnvoll. Beispiel Abbildung 83 zeigt den Teilprozess „Bestellung erfassen TP“, der im Geschäftsprozess aus Abbildung 82 als Funktion modelliert wurde (die Hinterlegung verweist auf dieses Prozessmodell). Er enthält zwei Aktivitäten: Eine manuelle Tätigkeit „Bestellpositionen erfassen“ sowie daran anschließend eine automatische Prüfung der Bestellung gegen das ERP-System.

8.6. Umsetzung Im nachfolgenden Abschnitt geht es um eine Umsetzung im Sinne der Überführung der Prozessmodelle in automatisierte Services. Die zu klärenden Fragestellungen betreffen dabei erneut die Servicegestaltung selbst, die benötigten SOA-Komponenten sowie das Zusammenspiel innerhalb einer Gesamtarchitektur. 8.6.1. Servicegestaltung Die Servicegestaltung wurde erstmalig im Rahmen der Identifikation der Service-Typen betrachtet. Es bleibt nun die Frage, wie die identifizierten Fachfunktionen jeweils in Services übertragen werden und, in diesem Zusammenhang, welche Service-Typen hierfür genutzt werden. Vorbereitend wurden die Modellierungskonventionen und Heuristiken des Prozessmodells bereits so bestimmt, dass ein direkter Zusammenhang zwischen Teilprozessen beziehungsweise Aktivitäten und den Service-Typen hergestellt werden kann. Einen Überblick der Zusammenhänge zeigt Abbildung 84. Aus Abbildung 84 ist folgendes zu entnehmen: Es besteht ein direkter Zusammenhang zwischen Aktivitäten (die innerhalb des Prozessmodells Teilprozess als Interaktion und Automation modelliert werden) und den vier bereits definierten Service-Typen. Konkret

8.6. Umsetzung

219

Abbildung 83: Bestellung erfassen TP heißt dies, eine Aktivität wird jeweils mittels einer der vier Service-Typen implementiert. Das Prozessmodell „Teilprozess“ liefert den notwendigen Input, um eine konkrete Serviceausprägung nach dem Muster eines Service-Typs umzusetzen. Durch die Modellierung von Aktivitäten mit Hilfe der Objekttypen „Automatisierung“ und „Interaktion“ ist fachlich festgelegt, was mit Hilfe dieser Aktivitäten erreicht werden soll. Die Modellierung dient somit als Teil eines Pflichtenhefts für entsprechende Umsetzungen konkreter Services. Ereignisse oberhalb der Aktivität beschreiben Zeitpunkt und Input, die Ereignisse nach der Aktivität die möglichen Ergebnisse. Zugeordnete Objekte spezifizieren die Aktivitäten zusätzlich. Weiterhin besteht ein direkter Zusammenhang zwischen dem Prozessmodell „Teilprozess“ und den beiden Konkretisierungen als Fach-Service und Kommunikations-Service. Dies

220


Abbildung 84: Zusammenhänge zwischen Prozessmodell und Services entspricht den Heuristiken des Geschäftsprozesses, nämlich einer expliziten Aufnahme der Kommunikationssteuerung in den Geschäftsprozess. Ein Teilprozess erfüllt daher entweder fachliche Zwecke oder er dient der Kommunikationssteuerung. Da ein Teilprozess in seiner Gesamtheit als BPEL-Prozess automatisiert wird, wird auch die jeweilige Funktionalität des Teilprozesses als Web-Service zur Verfügung gestellt. Dies geschieht auf Grund der Tatsache, dass BPEL-Prozesse grundsätzlich über Web-Service-Aufrufe gestartet werden (Eine Betrachtung der Ablaufsteuerung der Teilprozesse beziehungsweise BPEL-Prozesse untereinander wird im Kapitel 9 vorgestellt). Für diese Umsetzung ist es im Rahmen des Referenzmodells möglich, noch weitere Aussagen über die Nutzung bestehender Standards zu treffen. Da dem Architekturprinzip „Verwendung offener und verbreiteter Industriestandards“ gefolgt wird, trägt es ebenfalls zur Zielerreichung bei. Nachfolgende Erläuterungen sind entsprechend nach Standards unterteilt und beinhalten Aussagen zur Übertragung der fachlichen Teilprozessmodelle in die Ausführungssprache BPEL und zusätzlich benötigte Standards. Es geht dabei primär um eine Darstellung der Zusammenhänge. Die Art der Übertragung (manuell oder modellge-

8.6. Umsetzung

221

trieben) bleibt unberücksichtigt (vgl. „Transformation“ im Abschnitt 8.6.2). Entscheidend ist die Tatsache, dass mit den Modelltypen des Prozessmodells ein Gerüst zur Verfügung steht, dass vollständig der Kunden- und Prozessorientierung folgt. Dieses Gerüst stellt Möglichkeiten in Form von Modellen, den darin enthaltenen Objekten und deren Attributen zur Verfügung, die von Experten der Fach- und IT-Abteilungen verwendet werden, um wichtige Informationen zuzuordnen. In diesem Sinne sind die Punkte der folgenden beiden Tabellen 11 und 12 als Vorschläge für erweiterte Informationen der IT-Seite zu verstehen. WSDL und BPEL Automatisierungen und Interaktionen werden jeweils durch einen Web-Service implementiert und folglich durch WSDL beschrieben. Gleichzeitig entspricht die Struktur des Teilprozesses (dessen Ablauf) auch der des ausführenden BPEL-Prozesses. Darüber hinaus lassen sich weitere Aspekte aus dem Prozessmodell für die Umsetzung nutzen.

Abbildung 85: Gestaltung von Services aus Teilprozessmodellen Abbildung 85 zeigt einen Ausschnitt aus einem Teilprozess, der generell für alle ServiceTypen anwendbar ist. Tabelle 11 beschreibt dazu die einzelnen Objekte näher, wie diese für eine Übertragung des Teilprozesses in ein BPEL-Modell und die zugehörigen WSDL der Services verwendet werden kann.

222


Objekt

Technisches Modell

Mögliche Attribute im Prozessmodell

Verwendung

Service

WSDL-Dokument

„WSDL-Pfad“

Festlegung des Services, der die Automation, Interaktion oder Funktion umsetzt (durch das zugehörige WSDL-Dokument gegeben)

Operation

WSDL und BPEL:

„Partner-Link“ „Port-Type“ „Operation-Name“

Spezifikation der Elemente und Attribute aus BPEL und WSDL, die die Automation, Interaktion oder Funktion bereitstellen ( und werden sowohl in WSDL und BPEL verwendet)

Automation Interaktion Funktion

BPEL: (innerhalb der Aktivitäten)

Ereignis

WSDL:

„Message-PartName“ „Message-PartType“ „MessageNamespace“

Name und Typ des Message-Parts sowie des zugehörigen Namespaces der Nachricht, die als Start- oder Ergebnisparameter des BPELProzesses übermittelt werden (Event-basierte Erweiterung des Nachrichten-Typs siehe Abschnitt 9.2.4).

Attribut

BPEL:

„Variable-Name“

Name der Variable, in die Zwischenergebnisse gespeichert werden

Attribut „Name“ bereits vorhanden; es enthält die angezeigte Bezeichnung des Objekts

Tabelle 11: Generelle Übertragungsbeziehungen und Standardnutzung

BPEL4People Die Integration manueller Tätigkeiten in eine automatisierte Ablaufsteuerung erfolgt innerhalb des Referenzmodells nicht mittels des Standards BPEL4People (Darstellung des Standards in Abschnitt 5.3.2). Obwohl BPEL4People derzeit den am weitesten fortgeschrittenen Versuch einer Standardisierung darstellt, um manuelle Tätigkeiten in ausführbare Prozesse zu integrieren, ist dies innerhalb von Contact-Centern nicht notwendig. Innerhalb der BPEL4People-Spezifikation wurden unter anderem Tasks spezifiziert, die lokal einem BPEL-Prozess zugeordnet werden. Darüber hinaus wird die Spezifikation von Rollen und eine Zuordnung von Tasks zu Rollen (Bearbeiter) innerhalb eines BPELModells vorgesehen [vgl. Agrawal et al., 2007b, S. 3, 10 - 15]. Die Workflow-Steuerung wird somit um Aspekte der Task-Steuerung erweitert, beides muss durch Erweiterungen an der Implementierung der BPEL-Engine erreicht werden. Soll eine konsequente Trennung von Daten und Funktionalitäten beibehalten werden, die bereits bei der Identifikation der Applikationsdomänen angestrebt wurde, ist dieser Grundsatz hier ebenfalls anzuwenden. Die Sinnhaftigkeit der Verbindung beider Anwendungsgebiete wird grundsätzlich nicht in Frage gestellt. Der Status quo von Contact-Centern lässt jedoch klar erkennen, dass es innerhalb der Applikationsdomäne Routing bereits umfangreiche Anforderungen und entsprechende Funktionalitäten und Daten für die Zuordnung von Arbeitsaufgaben zu

8.6. Umsetzung

223

Skills gibt und die Steuerung dessen (wann wird welcher Task wem zugeordnet?) außerhalb der Prozesssteuerung liegen muss, da dies einen eigenen Managementgegenstand im Contact-Center bildet. An erster Stelle sei auf die sogenannten Service-Level-Agreements verwiesen (siehe Abschnitt 2.3.1), die durch das Routing gesteuert werden. WS-Human Task (WS-HT) Anders als bei BPEL4People verhält sich die Situation bei der Verwendung von WS-HT (siehe ebenfalls Abschnitt 5.3.2). Eine spezifizierte Beschreibung von Tasks ist notwendig, auch vor dem Hintergrund der Interoperabilität und Portabilität in Zusammenarbeit mit anderen Contact-Centern. WS-HT wird im Rahmen des Referenzmodells im Zusammenhang mit Agenten-Services verwendet. Zunächst unterscheidet sich ein Task nicht von anderen Web-Services. Der Aufruf durch eine Operation (das heißt die Erstellung eines Tasks) sowie die benötigten Nachrichten und Datenstrukturen werden innerhalb eines WSDL-Dokuments spezifiziert. Die Objektverwendung funktioniert dabei analog obigem Abschnitt „WSDL und BPEL“. Die Art und Weise der Modellierung sowie mögliche Objektverwendungen eines AgentenServices zeigt Abbildung 86.

Abbildung 86: Gestaltung von WS-Human-Tasks Teilprozessmodellen

zu

Agenten-Services

aus

Aus der Modellierung eines Agenten-Services lassen sich anschließend Parameter speziell für die WS-HT-Beschreibung ableiten, wie in Tabelle 12 dargestellt.

224


Objekt

WS-HTElement bzw. Attribut

Mögliche Attribute im Prozessmodell

Verwendung

Interaktion

„TaskIdentifikation“ „Beschreibung“

Name (Bezeichnung der Interaktion) und Beschreibung werden als Kurzbezeichnung (Überschrift) und zur detaillierten Aufgabenbeschreibung für den Agenten genutzt. Die Task-Identifikation bezeichnet den TaskTypen eindeutig.

Ereignis

Die möglichen Ergebnisse der Interaktion, die für einen Agenten am Arbeitsplatz auswählbar sind, werden durch das Attribut Name (Bezeichnung) der Ausgangsereignisse beschrieben.

Anwendungs- systemtyp neues Attribut: Anwendungssystem

„System-ID“

Identifikation des Anwendungssystems, das den Fokus auf dem Agenten-Desktop bekommt.

Maske

neues Attribut: Maske

„Masken-Name“

Identifikation der Maske des Anwendungssystems, die aufgerufen wird.

Skript

neues Attribut: Skript

„Skript“

Identifikation eines Skripts des AgentenDesktop-Systems, das mit Start des Tasks ausgeführt werden soll.

Elektronisches Dokument

neues Attribut: ElDokument

„Elektronisches Dokument“

Identifikation eines elektronischen Dokuments mittels einer URI (zum Beispiel „http://firma.de/wiki/ArbeitsanweisungX“, „file:///C:/Dokument.pdf“).

Dokumentiertes Wissen

neues Attribut: DokuWissen

„Dokumentiertes Wissen“

Textueller Hinweis auf dokumentiertes Wissen, das zur Ausführung notwendig ist.

Service und Operation

(analog auch für eine Rückantwort)

Neben der Beziehungen aus Tabelle 11 wird innerhalb des WS-HT-Dokuments auf die Elemente des ihm zugehörigen WSDL-Dokuments verwiesen.

Tabelle 12: Übertragung und Standardnutzung von Interaktionen in Agenten-Services Ein Ausschnitt aus einem WS-HT-Dokument könnte beispielsweise wie folgt aussehen:

8.6. Umsetzung

225

... ... CRM2000 CRM2000-Daten Kundenbefragung Juni 2009 http://firma.de/wiki/Bestellvorgang Arbeitsanweisung Bestellung beachten! Bestellpositionen aufnehmen Bitte nehmen Sie die Bestellpositionen auf und schließen Sie anschließend diese Tätigkeit ab, die Bestellung wird dann automatisch geprüft. Bestellpositionen sind aufgenommen

Die Elemente , , , , , und wurden im obigen Beispiel ausgelassen. Die Festlegung und Verwaltung von Prioritäten, Zuordnungen, Delegationen und Fristen werden im Rahmen des Routings verwaltet. Eine Überwachung findet mit Hilfe der Ereignisorientierung statt. Weitere Standards Die Verwendung von WSDL schließt eine Nutzung von SOAP für den Austausch XML-basierter Nachrichten automatisch mit ein. In diesem Zusammenhang ist eine einheitliche Verwendung von XML-Namensräumen (sogenannte „namespaces“ [vgl. W3C, 2006a]) und eine Zuordnung dieser XML-Namensräume zu Prozessmodellen sowie deren Objekten und Parametern notwendig. Zur asynchronen Web-ServiceKommunikation (beispielsweise für den Routing-Service), sofern sie nicht durch die Funktionalität von BPEL-Engines abgedeckt wird, bedarf es einer Verwendung des Standards

226


WS-Addressing [vgl. W3C, 2006b]. Die Verwendung weiterer Standards, besonders aus der Gruppe WS-* (siehe auch Abschnitt 5.2.4), ergibt sich jeweils aus technischer Sicht und ist entsprechend im Rahmen der projektspezifischen Umsetzung zu klären. 8.6.2. Architektur und Komponenten Aus Umsetzungsperspektive wurden bisher Service-Typen mit Operationen und Parametern identifiziert. Mit Hilfe von Prozessmodellen wurde eine konkrete Serviceidentifikation vorbereitet sowie eine Servicegestaltung aus den Prozessmodellen erarbeitet, wobei wichtige Standards betrachtet wurden. Abschließend soll die Gesamtarchitektur einer SOA im Contact-Center aufgezeigt und wesentliche Abläufe beziehungsweise Besonderheiten verdeutlicht werden. Einen Überblick über die Architektur zeigt Abbildung 87.

Abbildung 87: Gesamtarchitektur der SOA-Umsetzung des Referenzmodells

8.6. Umsetzung

227

Die Bestandteile der Gesamtarchitektur beschreiben sich wie folgt: • Transformation: Auf Grund des oben dargelegten Zusammenhangs zwischen Prozessmodellen und Services ist die Frage der Übertragung zwischen den Modellen (beispielsweise von EPK zu BPEL und umgekehrt) zu klären. Im Zusammenhang mit modellgetriebenen Ansätzen [vgl. bspw. Pastor und Molina, 2007] werden hier folgende Schichten unterschieden: – „Computation Independent Model (CIM)“: Hierunter fällt im Rahmen des Referenzmodells das Contact-Center-Prozessmodell mit den fachlichen Inhalten. – „Platform Independent Model (PIM)“: Hier sind dies die Modelle und Standards wie BPEL, WSDL, WS-Human Task und andere, wie sie ebenfalls bereits dargestellt wurden. – „Platform Specific Model (PSM)“: Hierunter fallen implementierungsabhängige Modelle. Diese sind projektabhängig und werden im Rahmen des Referenzmodells nicht betrachtet. Eine Transformation zwischen den Schichten vom CIM nach PIM und PIM nach PSM kann automatisiert oder „manuell“ erfolgen. Da die Automatisierung im Speziellen und modellgetriebene Ansätze im Allgemeinen die Komplexität erhöhen und zusätzliche Anforderungen stellen, werden sie im Rahmen des Referenzmodells nicht berücksichtigt. Mit der Ausarbeitung der Inhalte in den Schichten CIM (das Prozessmodell) und PIM (Umsetzungsmodelle im Sinne einer SOA im Contact-Center) und eine Abstimmung aufeinander wurden wesentliche Vorarbeiten geleistet. Eine Übertragung wird jedoch nur implizit vorausgesetzt. Auf die Arbeit von [Freund und Götzer, 2008, S. 125 ff.] sei hier verwiesen, in der die Problemstellung ausführlich betrachtet wird. • Prozessausführung: Als Ausführungssprache, in die Teilprozesse übertragen werden, wird innerhalb des Referenzmodells BPEL verwendet. BPEL ist auf Grund der Orchestrierung von Web-Services als Ausführungssprache etabliert und durch OASIS spezifiziert (vgl. Abschnitt 5.3.1). Hierdurch wird gleichzeitig das Paradigma der Ausführungssteuerung für Teilprozesse festgelegt: Die Ausführung wird auf Basis eines festgelegten Prozessmodells (BPEL-Prozess) mittels einer Workflow-Engine (BPEL-Engine) gesteuert. Dies ist zurückzuführen auf eine geringere Änderungshäufigkeit innerhalb der Teilprozesse (bedingt durch die Granularität) und einen geringen Einfluss der Volatilität auf die Abfolge von Aktivitäten innerhalb eines Teilprozesses (bedingt durch die Gestaltungsregeln). Teilprozesse selbst werden wiederum als Web-Services bereitgestellt (Schnittstellen von BPEL-Prozessen werden mittels WSDL definiert). • Prozess-Repository: Das Prozess-Repository beinhaltet den gesamten Prozessdatenbestand. Hierunter fallen das Contact-Center-Prozessmodell sowie die BPELProzessmodelle. Da die Verwendung der ARIS-Methodik auch die Verwendung von

228

8. Automatisierung durch Serviceorientierung ARIS als Software-Werkzeug mit einschließt, liegen alle Prozessmodelle nicht nur im engeren Sinne als Zeichnung vor. Alle Prozessmodelle und Objekte werden als Einträge in einer relationalen Datenbank gespeichert [vgl. Davis und Brabänder, 2007, S. 37]. Externe Daten (wie beispielsweise BPEL-Prozesse) können ebenfalls mittels Hinterlegung aufgenommen werden.

• Service-Enabling: Die Bereitstellung von Services sowie die Integration in bestehende Anwendungssysteme (auch mittels CTI) fallen in den Bereich des EnterpriseService-Bus (siehe Abschnitt 5.1.2). Dies setzt unter Umständen den Einsatz eines Applikation-Servers voraus. Verwendete Technologien, Standards und Plattformen (beispielsweise [Sun-Microsystems, 2009, Microsoft, 2009d]) hierzu fallen in den Bereich PSM und werden nicht dargestellt. Besondere Bedeutung kommt den Service-Typen Routing-Service sowie Agenten-Service zu. Für diese wurden bereits konkrete Operationen und Standardnutzungen identifiziert. Sie decken außerdem spezifische Charakteristika von Contact-Centern ab, die in normalen SOA-Umsetzungen nicht berücksichtigt werden. Eine typische Abfolge ist der Aufruf eines Routing-Services gefolgt vom Aufruf eines Agenten-Services. Die Zuteilung eines Tasks bedarf der vorherigen Auswahl eines freien und geeigneten Agenten aus einem großen Pool. Dies ist dann der Fall, wenn noch kein Agent zugeteilt wurde (zu Beginn des Geschäftsprozesses) oder sobald an einen Spezialisten weitergeleitet wird. Zur Verdeutlichung dieser Services zeigt das Sequenzdiagramm in Abbildung 88 die Abläufe der beteiligten Komponenten nochmals detaillierter. Der Aufruf eines Routing-Services geschieht innerhalb der BPEL-Engine mittels der Aktivität . Die Zuteilung eines freien Agenten erfolgt durch den Router als integriertes Anwendungssystem. Die Zustellung des Kontakts erfolgt durch den Aufruf eines entsprechenden Multikanal-Services. Der Routing-Service wird durch die Übermittlung der Agenten-ID mittels Callback abgeschlossen. Das Kommunikationsparadigma ist hierbei immer asynchron (innerhalb BPEL mit Hilfe der Aktivität , Web-Services untereinander durch WS-Addressing [vgl. W3C, 2006b]). Konkrete WSDL-Dokumente mit Operationen und Nachrichten werden projektspezifisch erstellt. Die Besonderheiten beim Agenten-Service beziehen sich in erster Linie auf den Modus der Zustellung eines Tasks. Üblicherweise erfolgt in Workflow-Umgebungen eine Sammlung von Tasks in sogenannten „Tasklists“ oder „Worklists“ [vgl. bspw. Brahe und Schmidt, 2007, Allen, 2001]. Tasks werden durch Bearbeiter „entnommen“. Dies wird häufig als „Pull-Modus“ bezeichnet und ist beispielsweise implizit in den Spezifikationen zu BPEL4People und WS-HT vorgesehen [vgl. Agrawal et al., 2007b,a]. Im Contact-Center ist eine Sammlung von Tasks und die Entnahme durch Agenten jedoch nicht angezeigt. Der Grund hierfür liegt in der großen Anzahl von Tasks und Agenten sowie der expliziten Steuerung der Zuteilung von Arbeitsaufträgen, das als „Push-Modus“ bezeichnet werden kann.

8.6. Umsetzung

229

Abbildung 88: Ablauf zwischen den SOA-Komponenten Um einen „Push-Modus“ zu erreichen, sind die notwendigen unterstützenden Applikationen aus [Agrawal et al., 2007a] (siehe auch Abschnitt 5.3.2) wie folgt umzusetzen: • Task-Verwaltung: Zur Verwaltung von Tasks ist ein eigenes Anwendungssystem notwendig. Es entspricht in weiten Zügen der „supporting application“ [aus Agrawal et al., 2007a, S. 41]. Die Task-Verwaltung stellt die einzelnen Tasks als Web-Service zur Verfügung (jedem Task sind Operationen des WSDL zugeordnet) und ermöglicht die Verwaltung von Tasks, indem die spezifizierten 31 Programmierschnittstellen (Operationen wie beispielsweise claim(), start(), complete() oder remove()) ebenfalls als Web-Services angeboten werden. Die Operationen und notwendigen Nachrichtenformate (XML) sind in [Agrawal et al., 2007a, Kap. 6.1.1 und 7] ausreichend beschrieben. Die in Abschnitt 8.4.3 „Service-Typ Agenten-Service“ identifizierte Operation „manuelle Arbeitsaufgabe zustellen“ ist generisch, sie wird durch die Operation des konkreten Tasks (festgelegt innerhalb des Elements ) ersetzt. Entsprechend erfolgt der Aufruf dieser Operation durch die BPEL-Engine. Durch den Aufruf wird ein Task physikalisch erzeugt. (Entsprechend müssen Tasks in einer Task-Datenbank

230

8. Automatisierung durch Serviceorientierung durch die Task-Verwaltung gespeichert werden, die notwendigen Datenstrukturen ergeben sich aus [Kap. 3.4.4 Agrawal et al., 2007a].) Da es sich um eine direkte Zustellung eines Tasks handelt, werden die Operationen zum Erstellen, Annehmen, Starten, Stoppen und alle weiteren (anders als spezifiziert) nicht über eine Benutzeroberfläche vom Agenten aufgerufen. Die Operationen unterliegen der Kontrolle des Statushandlings, das weiterhin durch das Routing und das Agent-Desktop-System abgebildet wird. Entsprechend erfolgen die Zuordnung (claim()), die Abfrage von Daten zur Anzeige des Tasks (query()), der Start (start()) sowie der Abschluss des Tasks (complete()) automatisch durch das Agent-Desktop-System.

• Task-List-Client: Die Funktionalität des „task list client“ ist in [Agrawal et al., 2007a, S. 41] nicht näher spezifiziert. Üblicherweise erfolgt das Annehmen eines Tasks nach dem „Pull-Modus“. Hierfür würden Benutzer über den Task-List-Client als Benutzeroberfläche die Operationen der Task-Verwaltung aufrufen. Da die Zustellung direkt erfolgen muss, ist eine Operation pushTask() (Input-Parameter ist die Task-ID) durch das Agenten-Desktop-System als Web-Service zur Verfügung zu stellen. Der Agent-Desktop übernimmt hierfür auch die Umsetzung des Task-ListClients, indem die Arbeitsaufgabe am Arbeitsplatz des Agenten angezeigt wird. Eine mögliche Ausprägung dessen zeigt die Montage einer möglichen Agent-DesktopOberfläche in Abbildung 89. Der Agent beginnt unmittelbar mit der Bearbeitung der zugestellten Aufgabe. Die im Teilprozess modellierte Interaktion mit ihren Objekten wurde in eine TaskBeschreibung nach WS-Human Task übertragen und steuert die Darstellung der Benutzeroberfläche. Dort werden die Masken des Anwendungssystems angezeigt, elektronische Dokumente und dokumentiertes Wissen erscheinen als Link beziehungsweise als textueller Hinweis. Der Task wird durch den Agenten abgeschlossen, indem eines der vordefinierten Ergebnisse (Ereignisse im Prozessmodell) ausgewählt werden muss und der Task abgeschlossen wird. Danach erfolgt der nächste Aufruf eines Agenten-Services (falls im Prozessmodell vorgesehen) oder der Agent wird wieder als „bereit“ im Routing geführt und erhält neue Tasks.

8.6. Umsetzung

Abbildung 89: Beispielmontage einer Agent-Desktop-Oberfläche

231

233

9. Steuerung und Überwachung durch Ereignisorientierung Aufbauend auf den SOA-Teil des Referenzmodells werden im Anschluss die ereignisorientierten Komponenten und Aspekte erarbeitet und das Referenzmodell komplettiert. Neben der notwendigen Betrachtung des gewählten Vorgehens und der damit verfolgten Ziele konzentrieren sich die nachfolgenden Abschnitte hauptsächlich auf die Ausgestaltung der beiden Anwendungsgebiete der Ereignisverarbeitung im Zusammenhang mit Geschäftsprozessmanagement: der Geschäftsprozesssteuerung sowie dem Echtzeit-Monitoring von Geschäftsprozessen.

9.1. Vorgehensmodell und Zielsetzung Die Nutzung der relativ jungen Disziplin „Ereignisverarbeitung“ und deren Anpassung auf die Belange von Contact-Centern ist getrieben von derselben Motivation, mit der auch die Zielsetzung in Abschnitt 8.2 erarbeitet wurde. Dies heißt konkret, die Zielsetzungen sind nach wie vor gültig und auch durch den Einsatz der Ereignisverarbeitung zu erfüllen. Den größten Einfluss hat die Verwendung der Ereignisverarbeitung auf die Zielsetzung „Flexibilisierung und Reaktivität“. Dies zeigt sich im Zusammenhang mit dem Geschäftsprozessmanagement. Die zwei hauptsächlichen Ansatzpunkte dafür sind die WorkflowSteuerung (Abschnitt 6.4.2) und das Business-Activity-Monitoring (Abschnitt 6.4.1). Eine Zunahme der Flexibilisierung und der Reaktivität ergibt sich dabei wie folgt: • Geschäftsprozesssteuerung: Geschäftsprozesse mit Hilfe von BPEL zu automatisieren und zu steuern bedeutet, dass für den Ablauf aller zugehörigen Teilprozesse eine feste Struktur vorgegeben ist. Da im Contact-Center ein hoher Anteil an manuellen Tätigkeiten in den Geschäftsprozessen vorhanden ist (Agenten-Service), der wiederum bedingt ist durch den direkten und persönlichen Kontakt zum Kunden, kommt es zu Problemen auf Grund der Volatilität der Kunden. In der Konsequenz heißt dies, Geschäftsprozesse (und somit auch die zugehörigen BPEL-Modelle) müssen alle Eventualitäten (Sprünge, Abbrüche) an allen möglichen Stellen modellieren und technisch ermöglichen. Dies ist unübersichtlich und nicht verwalt- und implementierbar. Die Flexibilisierung wird dadurch erreicht, dass es einen Pool von Teilprozessen gibt, aus dem situationsbedingt (das heißt ereignisorientiert) die notwendigen Teilprozesse kundenindividuell verkettet werden. Je nach Ausgang des Teilprozesses beziehungsweise je nach Konstellation im Kundengespräch wird der nächste passende Teilprozess gestartet. Inhaltlich ist dies bereits durch das Contact-Center-Prozessmodell vorbereitet. Technisch fehlt hier noch eine Ablaufsteuerung der Teilprozesse untereinander. Innerhalb der Teilprozesse sind die Abfolgen der Aktivitäten bereits


234

9. Steuerung und Überwachung durch Ereignisorientierung als BPEL-Prozesse automatisiert. Sie werden durch eine BPEL-Engine gesteuert. Für diese Granularitätsstufe ist dies ausreichend, entsprechende Abgrenzungen und Vorbereitungen wurden im Contact-Center-Prozessmodell vorgenommen.

• Business-Activity-Monitoring (BAM): Die Reaktivität bezieht sich auf den Grundsatz, dass nur auf etwas reagiert werden kann, von dem man auch Kenntnis hat. Konkret bedeutet dies Kenntnis über den Verlauf des Geschäftsbetriebs und somit über die Geschäftsprozesse. Eine Zusammenstellung aller hierfür notwendigen Entitäten (Ressourcen und Objekte wie beispielsweise Menschen, Anwendungssysteme und Funktionen) wird erstmalig mit Hilfe des Contact-Center-Prozessmodells prozessorientiert erreicht. Die Schwierigkeit einer Echtzeitüberwachung liegt dabei in der Heterogenität der zu überwachenden Entitäten. Allen voran die große Anzahl an Anwendungssystemen. Erschwert wird dies im Contact-Center durch die Dimension der Kontaktkanäle („Multikanalmanagement“) und die hierfür eingesetzten zusätzlichen Anwendungssysteme sowie durch den starken Einsatz asynchroner Abläufe (vor allem Routing und manuelle Tätigkeiten). Überwunden werden diese Schwierigkeiten durch eine Überwachung und Kennzahlengenerierung mittels CEP. Die notwendigen Events können aus den fachlichen Ereignissen, die in den Prozessmodellen modelliert sind, abgeleitet werden. Technisch gesehen sind die Schwierigkeiten der Generierung von Events aus der heterogenen Anwendungslandschaft heraus bereits durch die technische Integration mittels SOA gelöst. Die Reaktivität wird nun dadurch erreicht, dass Ströme oder Clouds von Events erzeugt und diese ausgewertet werden. Eine Reaktion kann entsprechend wiederum automatisiert durch Prozessaufrufe oder -anpassungen erfolgen. Die weiteren Zielsetzungen wurden bereits zum größten Teil vollumfänglich durch SOA und vor allem durch das Contact-Center-Prozessmodell abgedeckt. Die notwendigen Schritte, um eine ereignisorientierte Geschäftsprozesssteuerung und -überwachung zu ermöglichen, ergeben sich grundsätzlich aus dem Vorgehensmodell nach [Mühl et al., 2006, S. 182 - 183], das bereits in Abschnitt 6.3.2 erarbeitet wurde. Der erste Schritt darin ist das Design der Event-Processing-Agents (EPA)64 . Anschließend wird das EventProcessing-Network (EPN) spezifiziert. Die beiden Phasen des Deployments und des Betriebs werden innerhalb des Referenzmodells nicht berücksichtigt, da sie zu stark von konkreten technischen Details abhängig sind, die im Rahmen des Referenzmodells nicht erarbeitet werden, da hierfür unternehmensspezifische Gegebenheiten relevant sind. Das gewählte Vorgehensmodell zeigt die nachfolgende Abbildung 90. Dem Design einzelner EPA und dem gesamten EPN wurden die Darstellung der Zielsetzung sowie die Schaffung der Event-technischen Grundlagen vorangestellt. Zusätzlich wurde die Erweiterung des Contact-Center-Prozessmodells um die Belange der Ereignisverarbeitung angefügt. 64

Der Begriff „Agents“ ist nicht zu verwechseln mit den Agenten (Sachbearbeitern) eines Contact-Centers. EPA sind Software-Komponenten (siehe Definition in Abschnitt 6.3.2).

9.2. Erarbeitung der Event-technischen Grundlagen (Event-Enabling)

235

Abbildung 90: Vorgehensmodell zur Gestaltung der Ereignisorientierung Die Zielsetzung wurde in diesem Abschnitt bereits erläutert. Die folgenden Abschnitte widmen sich den weiteren Bestandteilen des Vorgehensmodells jeweils einzeln.

9.2. Erarbeitung der Event-technischen Grundlagen (Event-Enabling) Damit Geschäftsprozesse ereignisbasiert gesteuert werden können und eine Überwachung mittels CEP möglich wird, sind die technischen Voraussetzungen hierfür zu schaffen. Dies betrifft in erster Linie die Basisarchitektur verteilter Systeme (Abschnitt 6.2.2), die wiederum die Erstellung und Zustellung sowie den Transport von Events ermöglicht, auf deren Grundlage die Paradigmen des CEP (Event-Clouds und -Ströme, Abschnitt 6.3.3) aufbauen. Eine konkrete und umfassende Referenzarchitektur für das Event-Enabling wurde bisher noch nicht vorgestellt65 . Sie muss hier im Rahmen des Referenzmodells vorweggenommen und die Minimalanforderungen konstruiert werden. Als Motivation hierzu gilt die Bildung einer „Event-driven Architecture (EDA)“ nach dem Verständnis von [Luckham, 2007, S. 8]. Dabei soll eine SOA geschaffen werden, in der die Kommunikation auf Events basiert und alle Services reaktive Prozesse sind (das heißt, sie reagieren auf Events und produzieren Output-Events). Eine solche EDA wird im Rahmen des Referenzmodells konstruiert. Dabei wird der Grundsatz verfolgt, nichts Neues hinzuzufügen. Die Basisarchitektur verteilter Systeme ist bereits theoretisch beschrieben (siehe Verweise oben). Sofern möglich, wird sie mit bestehenden Standards und Technologien einer SOA umgesetzt. Da SOA und DEBS komplementär sind, ist dies weitestgehend möglich. 65

Derzeit beschäftigt sich eine Arbeitsgruppe der EP-TS mit der Schaffung einer entsprechenden Referenzarchitektur. Ergebnisse daraus wurden bisher noch nicht veröffentlicht. Eine Diskussion des aktuellen Standes findet 2009 im Rahmen des 5. Symposiums der EP-TS [vgl. Etzion, 2009] und 2010 im Rahmen eines weiteren Dagstuhl-Seminars [vgl. Chandy et al., 2009] statt.

236

9. Steuerung und Überwachung durch Ereignisorientierung

9.2.1. Gestaltungsgrundsätze für die Identifikation von Komponenten Die ereignisverarbeitenden Komponenten müssen als Services, wie in einer SOA, betrachtet werden. Im Vergleich zu Services, wie sie in den vorangegangenen Kapiteln identifiziert wurden, gibt es nur wenige Unterschiede. Deshalb gelten grundsätzlich dieselben Architekturprinzipien. Die Besonderheiten und Unterschiede bei der Identifikation der notwendigen ereignisverarbeitenden Komponenten, das heißt von weiteren Services, zeigt die nachfolgende Aufzählung. Sie ist gegliedert nach den Architekturprinzipien aus Abschnitt 5.1.166 : • Abstraktion von der Service-Implementierung: Die Umsetzung ereignisverarbeitender Services bleibt abstrahiert von ihrer Beschreibung, allerdings erfolgt die Implementierung größtenteils spezifisch durch Technologien des CEP beziehungsweise des ESP. Dies ist bei den EPA, die in Abschnitt 9.3 beschrieben werden, der Fall. • Technische Schnittstellenstandardisierung und Verwendung offener und verbreiteter Industriestandards: Die Schnittstellen ereignisverarbeitender Services bilden der Event-Ein- und -Ausgang. Hierzu werden die bekannten Web-Service-Standards genutzt. • Fachliche Schnittstellenstandardisierung: Die fachliche Schnittstellenstandardisierung erfolgt durch das Contact-Center-Prozessmodell. Dadurch ist zum einen die Notation festgelegt, zum anderen werden die Schnittstellen (Event-Ein- und -Ausgänge) standardisiert mit Hilfe der Modelltypen „Geschäftsprozess“, „Teilprozess“ und einem neuen Modelltyp „Event-Verarbeitungs-Diagramm“ (Abschnitt 9.5.2) beschrieben. • Hohe Servicekohäsion und schwache logische Kopplung: Eine schwache logische Kopplung wird unter anderem in folgenden beiden Aspekten erreicht: 1. Trennung nach komplexer Event-Verarbeitung, Event-Transport und Reaktion (grundsätzlich für die EDA) 2. Trennung nach Geschäftsprozesssteuerung, Kennzahlenerstellung und Kennzahlenpräsentation (inhaltlich-fachlich für die EPA) • Lose gekoppelte Kommunikation: Dies ist explizit durch die Verwendung von DEBS und CEP gegeben. Das zu Grunde liegende Kommunikationsparadigma ist nun zusätzlich Event-orientiert möglich (im Vergleich zu „Find–Bind–Execute“ in einer herkömmlichen SOA). • An Geschäftskonzepten orientierte, grobe Servicegranularität und Generalisierung der Serviceleistung: Für die Geschäftskonzepte sei auf die Zielsetzung in Abschnitt 9.1 (Realisierung der Volatilität und BAM) verwiesen. Eine Generalisierung wird 66

Nicht anwendbare Architekturprinzipien wurden weggelassen.


237

dadurch erreicht, dass für die Steuerung der Geschäftsprozesse und für das BAM wenige dedizierte EPA-Klassen zuständig sind, die über Parameter (Abonnements und Patterns) auf die fachlichen Anforderungen angepasst werden. Nach diesen Gestaltungsgrundsätzen werden zunächst die EDA und anschließend die fachlich notwendigen EPA konstruiert.

9.2.2. Schaffung einer Event-Driven-Architecture (EDA) Für eine EDA nach [Luckham, 2007] muss das Event-getriebene Kommunikationsparadigma und die Service-Reaktivität umgesetzt werden. Dabei sind die oben aufgeführten Gestaltungsgrundsätze einzuhalten. Eine hohe Servicekohäsion bei gleichzeitig schwacher logischer Kopplung wird durch die Trennung in komplexe Event-Verarbeitung (im Sinne von CEP), Event-Transport und Reaktion eingehalten. Diese Trennung ist auf folgenden Gründen sinnvoll: CEP und die Reaktion auf Situationen, die durch CEP aufgedeckt werden, sind fachlich getriebene Aspekte. CEP ist per Definition darauf spezialisiert, Events über Hierarchien zu verarbeiten und aufgedeckte Zustände durch ein neues, komplexes Event mitzuteilen. Dem gegenüber stehen bewährte Workflow-Technologien, die bereits Orchestration und Integration (in Datenbanken und andere Systeme) abdecken. Für beide gibt es bewährte Technologien, Standards und Experten. Diese Trennung soll beibehalten werden, um eine Erweiterung des Funktionsumfangs des jeweils anderen zu umgehen. Die notwendige Reaktion auf ein komplexes Event wird als Workflow modelliert, der Workflow muss entsprechend auf das komplexe Event reagieren. Bei Änderungen des CEP-Patterns muss der Workflow nicht angepasst werden, bei Änderungen der Reaktion muss das Pattern nicht angepasst werden. Gleiches gilt auf höherer Ebene auch für technische Erweiterungen an Workflowund CEP-Engines. Je nach Fachlichkeit werden diese beiden Domänen in weitere fachlich motivierte EPA unterteilt, wobei dies vom jeweiligen Kontext abhängig ist. Eine ContactCenter-spezifische Aufteilung findet deshalb separat in Abschnitt 9.3 statt. Dabei ist die fachliche Schnittstellenstandardisierung und eine an Geschäftskonzepten orientierte, grobe Servicegranularität und Generalisierung der Serviceleistung einzuhalten. Jeder EPA wird ein Web-Service und erhält somit eine Web-Service-Schnittstelle. Die Operation der Schnittstelle dient dem Event-Eingang. Die Zustellung eines Events geschieht von außerhalb durch Aufruf der Web-Service-Operation des EPA. Hierfür werden bestehende Web-Service-Standards (WSDL, SOAP, WS-*) genutzt, wodurch die technische Schnittstellenstandardisierung und die Verwendung offener und verbreiteter Industriestandards eingehalten wird. Dadurch entfällt außerdem eine proprietäre Bindung an Adapter oder Ähnliches, um einen EPA in eine Event-Cloud oder einen Event-Stream einzufügen.

238


Dritte wesentliche Komponente der EDA ist die Kapselung der Event-Infrastruktur (konkret ist dies der Event-Transport). Diese ist technisch motiviert und wird durch einen eigenen Web-Service, den Notification-Service, realisiert. Die fachliche Schnittstellenstandardisierung ergibt sich dabei aus der Beschreibung von DEBS. Der Notification-Service ist zentraler Kommunikationspartner der EPA. Im Rahmen der Event-Zustellung übernimmt er den Web-Service-Aufruf der EPA. Im Gegenzug werden über den Notification-Service Events der EPA veröffentlicht und Abonnements angenommen. Fachlich wird dadurch die lose gekoppelte Kommunikation mittels Events erreicht. Das fachliche Kommunikationsparadigma ist pub/sub, das darunter liegende technische Kommunikationsparadigma ist beliebig (vgl. [Mühl et al., 2006, S. 169] und Abschnitt 6.2.2). Es ist somit nicht Teil des Referenzmodells und der EDA-Darstellung.

Abbildung 91: Operationen und Standardnutzung des Notification-Service Die Zusammenhänge zeigt Abbildung 91. Die genauere Funktionsweise des NotificationService wird im nachfolgenden Abschnitt dargestellt. Daran schließt sich die notwendige Beschreibung einer Event-Darstellung an. Da BPEL-Prozesse selbst Web-Services sind, ist hier derselbe Mechanismus des Notification-Service in Verbindung mit Abonnements anwendbar, wodurch die Reaktivität abgedeckt wird. Genauer wird dies in Verbindung mit der Geschäftsprozesssteuerung dargestellt (siehe Abschnitt 9.3.1). Insgesamt sind so die Zusammenhänge einer EDA, basierend auf SOA-Technologien und -Standards, abgebildet. Detaillierter werden die fachlichen EPA im Abschnitt 9.3 beschrieben. Ihre Gesamtheit bildet eine konkrete EDA für Contact-Center.

9.2.3. Notification-Service und Event-Transport Für den Event-Transport bedarf es einer Software-Komponente, die das Abonnieren, Empfangen und Publizieren von Events ermöglicht und die Implementierung der EventVerteilung (Kommunikation) überdeckt [vgl. Mühl et al., 2006, S. 12, 138]. Ein entsprechender abstrakter „Notification-Service“ wurde in Abbildung 61 (Seite 145) skizziert.


239

Nach diesem Muster enthält das Referenzmodell ebenfalls einen Notification-Service. Dieser wird als Bestandteil der SOA-Architektur als Web-Service zur Verfügung gestellt. Event-Abonnements und Event-Transport erfolgen mittels SOAP. Für die Umsetzung des Notification-Services werden Teile der Spezifikation WS-Eventing verwendet. Dabei werden nur Teile herangezogen, da die Zielsetzung von WS-Eventing nicht vollständig dem des Referenzmodells entspricht. Während WS-Eventing ein Protokoll und Schnittstellen spezifiziert, mit deren Hilfe Web-Services untereinander dezentral Events abonnieren und zusenden können [vgl. Box et al., 2006], ist es die Intention des Referenzmodells, eine zentrale Komponente für das Abonnieren und Versenden von Events zu schaffen. Aus diesem Grund erbt der Notification-Service die Operationen SubscribeOp und UnsubscribeOp sowie die zugehörigen Messages der Schnittstellenbeschreibung von WS-Eventing [vgl. Box et al., 2006, Kap. 3 und Appendix III]. Zusätzlich ist eine Operation PublishOp zu implementieren, mit der beliebige Events als XML-Messages veröffentlicht werden können (dies bezieht sich auf die Event-Quelle). Die Zustellung an die Abonnenten (EPA) erfolgt über deren Web-Service-Schnittstellen, dessen Port innerhalb der jeweiligen SubscribeMsg mit Hilfe des Standards WS-Addressing angegeben wurde (Abbildung 92 zeigt zum Überblick diese Zusammenhänge des Notification-Service als Klassendiagramm). In der Konsequenz bedeutet dies, dass alle EPA, die im Rahmen dieses Referenzmodells identifiziert werden, Services sind und entsprechende Web-Service-Schnittstellen implementieren, über die Events zugestellt werden.

Abbildung 92: Operationen und Standardnutzung des Notification-Service Innerhalb des WS-Eventing-Elements [vgl. Box et al., 2006, Kap. 3] können Filter angegeben werden, die frei bezeichnet und implementiert werden können. Für das Referenzmodell wird die XML-Abfragesprache XPath verwendet, die 2007 in der Version 2.0 vom W3C standardisiert wurde [vgl. W3C, 2007f]. XPath-Abfragen sollen das Abonnement auf Event-Klassen und simple Parameter-Vergleiche beschränken. Eine komplexe Ereignisverarbeitung findet dadurch nicht statt (ECA-Regeln werden nicht mit Hilfe der Filter implementiert), dies geschieht innerhalb des CEP durch dedizierte EPA. Dementsprechend ergeben sich Abonnements aus den CEP-Patterns beziehungsweise genauer aus den darin verwendeten und unterschiedlichen Event-Klassen. Da der Notification-Service innerhalb der bestehenden SOA-Architektur des Referenzmo-

240


dells implementiert wird, wird auch der ESB genutzt. Der ESB stellt den NotificationService innerhalb der SOA als Web-Service zur Verfügung. Gleichzeitig wird die SoftwareKomponente, die den pub/sub-Event-Transport implementiert (unternehmensindividuelle Implementierung der Event-Verteilung oder proprietäre Software-Produkte), im Sinne der Anwendungsintegration über des ESB integriert. Der Notification-Service greift über den ESB auf die bestehende Event-Infrastruktur zu. Diesen Zusammenhang zeigt Abbildung 93. Zum Vergleich wird darin die Basisarchitektur eines DEBS [aus Mühl et al., 2006, S. 12] ebenfalls aufgeführt.

Abbildung 93: Beteiligte Komponenten beim Event-Transport Unter Umständen ist es möglich, dass ein ESB die Funktionalitäten eines pub/sub-EventTransports bereits zur Verfügung stellt, die dann genutzt werden können. Sollten zu diesem Funktionsumfang die komplexe Mustererkennung oder die Verarbeitung von EventStrömen ganz oder teilweise gehören, so ist zu beachten, dass auch hier eine strikte Trennung zwischen dem Event-Transport und der komplexen Event-Verarbeitung dargestellt wird.

9.2.4. Event-Darstellung Das Erzeugen eines Events und dessen Transport bedürfen einer Notation. Da vergleichbare Vorgänge in einer SOA komplett mittels XML umgesetzt werden (Zusammenhänge siehe Abbildung 94), soll dies auch innerhalb der Eventverarbeitung genutzt werden. Sowohl das Publizieren von Events (zum Notification-Service) als auch deren Zustellung (zum EPA) geschieht über Web-Service-Aufrufe und somit zur Laufzeit mit Hilfe von SOAP67 . Für die fachlichen Nachrichten, die die Events transportieren, bedarf es einer unternehmensweit einheitlichen Event-Darstellung. Da es derzeit noch keinen komplett 67

Zur Performanz in der Verarbeitung textbasierter Protokolle wie XML (Parsing) vergleiche Untersuchungen von [Melzer, 2007, S. 155 - 186] (Abschnitt 5.2.2) und [White et al., 2008] (Abschnitt 6.3.4).


241

Abbildung 94: Event-Darstellung: Zusammenhänge zwischen Prozessmodell und Event im Klassendiagramm nutzbaren offiziellen Standard hierfür gibt (siehe aktuellen Diskussionsstand des CEP in Abschnitt 6.3.4), muss ein solcher individuell erstellt werden. Als Input oder Vorlage für die notwendigen Metadaten und Elemente können das CBE [vgl. Ogle et al., 2004] und die Event-Beschreibungen der Spezifikationen zum „Management Using Web-Services (MUWS)“ [vgl. OASIS, 2006a,b] dienen. Die oben genannten Spezifikationen CBE und MUWS sind hilfreich, um notwendige und allgemeine Event-Attribute und -Elemente zu definieren (Metadaten). Dabei müssen die Event-Aspekte „Form“ (erfüllt durch die Darstellung mittels XML-Schemata), „Signifikanz“ und „Relativität“ [Luckham, 2002, Etzion, 2007] berücksichtigt werden. Entsprechend ergeben sich mindestens folgende Attribute und Elemente: • Version: Version der Event-Spezifikation zur Unterscheidung zwischen unterschiedlichen Versionsständen. • Instanz: Lokale und/oder globale Instanz-ID des Events, um es eindeutig zu identifizieren (Primärschlüssel).

242


• Zeiten: Darstellung der Entstehungszeit (des Events, der Situation) und des Zeitraums. • Beschreibung: Für Menschen lesbare Beschreibung des Events (zum Beispiel „Anruf auf Leitung X geht ein“). • Priorität und Schwere: Eventuelle Angabe der Priorität und der Schwere in Form von Skalenwerten bei Überwachung von Fehlerzuständen. Eine entsprechende Skala muss zusätzlich definiert werden. • Wiederholungen: Anzahl der Wiederholungen eines beobachteten Vorgangs, für den das Event steht. • Sequenz: Position in einer Reihe gleicher Events. • Komponenten: Eindeutige Bezeichnung der Komponenten, in der die Situation eingetreten ist („Source“) und die das Event erzeugt („Reporter“). • Zugeordnete Events: Bezug zu anderen Events, die dieses Event erzeugt haben (im Sinne des CEP nach Zeit, Kausalität oder Aggregation) durch Bezeichnung ihrer Instanz (Darstellung der „Relativität“). • Kontext: Bezeichnung oder Beschreibung eines Kontexts, in dem das Event erzeugt wurde, beispielsweise ein Transaktionskontext. • Zustandsklassifizierung: Klassifizierung (Beschreibung einer Semantik) der beobachteten Zustände von Situationen, meist bei der Überwachung von Systemen (zum Beispiel genaue Abgrenzung und Definition von Zuständen wie „ist gestartet“ oder „ist beendet“). • Nachricht und Nachrichten-Typ: Die Nachricht ist die eigentliche Nutzlast des Events im Sinne von fachlichen Informationen. Sie stellt den Situationsbezug dar, für den das Event steht (neben den obigen Metadaten die eigentliche Darstellung der „Signifikanz“). Die Nachricht besteht aus einem beliebigen XML-Dokument, wofür ein XML-Schema definiert sein muss (Nachrichten-Typ). Der Nachrichten-Typ bildet die Event-Klasse beziehungsweise den Event-Typ, das heißt eine Klassifikation der Situation. Hier sind unterschiedliche Granularitäten möglich. Es ist sowohl ein EventTyp möglich, der durch umfangreiche Parameter alle Situationen beschreiben kann. Andererseits kann jede Einzelsituation mit einem eigenen Event-Typen beschrieben werden. Grundsätzlich ist dies unternehmensindividuell zu definieren. Im Rahmen des Referenzmodells werden insgesamt drei Event-Typen vorgeschlagen (die jeweils individuell weiter verfeinert werden können): CTI-Events, Prozess-Events und BAMEvents. Sie werden in den folgenden Abschnitten der einzelnen EPA beschrieben. Abbildung 95 zeigt die Attribute und Elemente nochmals im Überblick. Um einen Rückschluss zum Contact-Center-Prozessmodell zu erhalten, sind Referenzen zwischen dem Event und dem Prozessmodell hilfreich. Die einzelnen Referenzen beschreibt Tabelle 13.


243

Abbildung 95: Event-Attribute und -Elemente mit Verbindung zum Prozess-Repository Eine Referenzierung schafft eine Verbindung zwischen den Verständniswelten der umsetzenden IT sowie den Fachabteilungen. Einzelne Events können auf die „darüber liegenden“ Prozessmodelle im Contact-Center-Prozessmodell bezogen werden und umgekehrt. Für die Event-Serialisierung empfiehlt sich die Nutzung von MUWS. Für die systemtechnische Realisierung der Event-Darstellung in einem konkreten System sind zwei Möglichkeiten denkbar, um Events und Nachrichten-Typen darzustellen. Als erste Möglichkeit kommt die Definition einer abstrakten Event-Klasse in Betracht, von der eigenständige Events abgeleitet werden, die sich hauptsächlich durch die enthaltene Nachricht unterscheiden. Die zweite Möglichkeit besteht in der Definition eines Events, das alle allgemeinen Attribute und das Element zur Aufnahme der Nachricht enthält. Für die Nachrichten werden dann eigene Klassen gebildet. Diese Herangehensweise wird für die Definition der Event-Typen im folgenden Abschnitt gewählt. Sie werden der Einfachheit halber als Events beziehungsweise Event-Typen bezeichnet, sie müssen jedoch immer um die allgemeinen Event-Attribute und -Elemente ergänzt werden. Beide Darstellungsmöglichkeiten haben keinen Einfluss auf die Konformität mit MUWS. Hierfür ist lediglich die XMLSerialisierung entscheidend, diese muss der Schemadefinition entsprechen.

244


Dokument/ Modell

Verbindung

Beschreibung der Referenz

Event

EventBeschreibung

Eintrag der konkreten Objekt-ID des Objekts vom Typ „Ereignis“ aus dem Prozessmodell im Event

Event

Eintrag der konkreten Objekt-IDs der ObjekKomponenten („Source“ und te des Typs „Typ Anwendungssystem“ aus „Reporter“ des dem Prozessmodell im Event Events)

NachrichtenContactTyp CenterProzessmodell

Einführung eines neuen Attributs Nachrichten-Typ des Objekt-Typs „Ereignis“, worin der XML-Namensraum des Nachrichten-Typs eingetragen wird

Tabelle 13: Referenzen zwischen dem Prozessmodell und der Event-Darstellung

9.3. Event-Processing-Agents (EPA) und ihre zugehörigen Event-Typen EPA sind Software-Komponenten, in denen die eigentliche Verarbeitung von Events stattfindet (siehe Definition in Abschnitt 6.3.2). Für die Identifikation der in einem ContactCenter notwendigen EPA werden zunächst die notwendigen Gestaltungsgrundsätze geklärt. Anschließend werden die einzelnen EPA und ihre zugehörigen Event-Typen vorgestellt.

9.3.1. Event-basierte Geschäftsprozesssteuerung Die Event-basierte Geschäftsprozesssteuerung regelt die Abfolge der einzelnen Teilprozesse untereinander. Diese wurden jeweils in BPEL-Prozesse übertragen und werden von einer BPEL-Engine ausgeführt. Im engeren Sinne gibt es deshalb keinen einzelnen EPA zur Geschäftsprozesssteuerung, sondern jeder BPEL-Prozess, der einen Teilprozess repräsentiert, ist ein EPA.

Funktionsweise Für die Funktionsweise einer Event-basierten Geschäftsprozesssteuerung ist die Frage zentral, wie die einzelnen BPEL-Prozesse Event-orientiert werden. Die Spezifikation zu BPEL sieht dies nicht vor [vgl. OASIS, 2007a], entsprechende Erweiterungen sind (noch) nicht von anerkannten Gremien spezifiziert worden. Vor dem Hintergrund der hohen Servicekohäsion und einer schwachen logischen Kopplung („Trennung nach Hoheitsgebieten“) ist dies auch nicht notwendig. Mit den bisher hier vorgestellten Mitteln

9.3. Event-Processing-Agents (EPA) und ihre zugehörigen Event-Typen

245

lässt sich dies auch ohne zusätzliche Standards und ohne Anpassungen der BPEL-Notation und somit an BPEL-Engines umsetzen. Die Funktionsweise hierzu stellt Abbildung 96 als Architekturdiagramm dar, in das Elemente eines Sequenzdiagramms zur Darstellung des Ablaufs integriert wurden.

Abbildung 96: Architekturmodell, logischer Ablauf und verwendete Standards der ereignisorientierten Prozesssteuerung Der logische Ablauf stellt sich dabei wie folgt dar: 0. Event-Abonnements: Für jeden Teilprozess findet ein Abonnement der prozessauslösenden Events über die Operation SubscribeOp des Notification-Services statt. Dies ist ein (halb)automatischer Schritt, der spätestens mit dem Deployment eines BPEL-Prozesses (Teilprozess) stattfinden muss (gegebenenfalls manuell durch einen Administrator). Als prozessauslösendes Event sind sowohl simple als auch komplexe Events möglich. Auch bei komplexen Events obliegt die Mustererkennung nach ECA-Regeln nicht dem BPEL-Prozess (dem prozesssteuerndem EPA) sondern einem eigenen, unabhängigen EPA.

246


1. Eingang des Startereignisses: Ein neuer Kundenkontakt geht über einen Kontaktkanal (Telefon, E-Mail, Fax) ein. 2. Publizieren des Events: Aus dem System (Applikationsdomäne Multikanal), das den Endpunkt des Kontaktkanals darstellt (Telefonanlage, E-Mail-Server, Fax-Server), erfolgt die Publikation eines entsprechenden Events. Hierfür wird die Operation PublishOp des Notification-Services aufgerufen. 3. Zustellung des Events: Der Notification-Service stellt das unter 2. publizierte Event den Abonnenten (mindestens dem BPEL-Prozess, der den Teilprozess implementiert) zu. Die Zustellung geschieht als Web-Service-Aufruf mittels des BPEL-Elements receive. Über den partnerLink ist die Web-Service-Schnittstelle in BPEL hierzu definiert, die gleichzeitig als WS-Addressing-Element in 0. über das Abonnement mittels der SubscribeMsg für die Zustellung beim Notification-Service registriert wurde. 4. Aufruf von Web-Services: Der BPEL-Prozess ruft über das Element invoke WebServices auf, die im Prozessmodell Teilprozess als Aktivitäten modelliert wurden. 5. Callbacks: Die Kommunikation findet asynchron statt. Antworten der aufgerufenen Web-Services werden als Callback über reply empfangen. Die Punkte 4. – 7. sind die wesentlichen Elemente, über die die strukturbasierte Workflow-Steuerung anhand eines BPEL-Modells stattfindet (Ablaufsteuerung der Aktivitäten innerhalb eines Teilprozesses). 8. Publizieren des Ergebnisses: Das Ergebnis des Teilprozesses wird analog 2. ebenfalls als Event publiziert, indem in BPEL über das Element reply ein Web-ServiceCallback aufgerufen wird. In BPEL findet dies über denselben partnerLink statt, über den auch der receive-Aufruf stattgefunden hat. Nachdem der Aufruf durch den Notification-Service geschah, ist hier automatisch der richtige Adressat festgelegt. Die notwendige Message (das Event) ist im Objekt Ereignis im Teilprozessmodell als Attribut hinterlegt. Aus fachlicher Sicht stellt das Publizieren des Ergebnisses eine von zwei Möglichkeiten des Teilprozessaufrufs dar: Entweder startet der Eingang eines Kundenkontakts einen Teilprozess (in der Regel den ersten Teilprozess eines Geschäftsprozesses) oder das Ergebnis eines Teilprozesses startet über die entsprechenden Abonnements den nächsten Teilprozess. Aus Ausführungssicht ist ein Geschäftsprozess ein virtuelles Konstrukt, es besteht nur aus einer Reihe von registrierten Abonnements. Das Prozessmodell des Geschäftsprozesses gibt die fachlichen Vorgaben für die Abonnements. In der Transformationsphase des PIM lassen sich die technischen Parameter daraus generieren. Um eine SubscribeMsg nach dem Standard WS-Eventing zu erstellen, sind Informationen bezüglich des zu abonnierenden Event-Typs und bezüglich der Zustelladresse notwendig. Diese lassen sich aus den Informationen der im Geschäftsprozess modellierten Objekte gewinnen (Zusammenhang siehe Abbildung 97).


247

Abbildung 97: Zusammenhang zwischen Prozessmodell Geschäftsprozess und dem EventAbonnement Aus Sicht der „human interaction“ ist ein weiterer Aspekt der Geschäftsprozesssteuerung zu beachten: der Agenten-Desktop als Benutzerschnittstelle. Agenten müssen auf Grund der Volatilität jederzeit in der Lage sein, andere Teilprozesse aufzurufen. Zum einen müssen dem Agenten sämtliche Teilprozesse angeboten werden, die mit den zugeordneten Skills ausführbar sind. Zum anderen müssen die restlichen Teilprozesse ausgewählt werden können, wodurch eine Weiterleitung an einen Spezialisten erfolgt. Einen Ausschnitt aus einer möglichen Implementierung eines Agenten-Desktop zeigt Abbildung 98. Eine Auswahl eines Skill-fremden Teilprozesses bedeutet eine Weiterleitung an einen Spezialisten. Dies schließt den Transport des Kontakts (Telefongespräch, E-Mail, elektronisches Dokument) und ein auf „Bereit“ setzen des Agenten mit ein (der Agent bekommt anschließend neue Teilprozesse durch das Routing zugeteilt). Dies ist durch die fachliche und technische Unterscheidung der Service-Typen Fach-Service und KommunikationsService möglich (beide sind als Teilprozesse Event-basiert aufrufbar). Die Liste eigener Bearbeitungen sowie die Liste der Weiterleitungen lassen sich aus der Summe der Prozessmodelle der Geschäftsprozesse ermitteln. Eigene Bearbeitungen sind alle Objekte des Typs „Funktion“, Weiterleitungen sich entsprechend die Objekte des Typs „Automation“. Die namentliche Benennung der eigenen Bearbeitungen und Weiterleitungen ergeben sich dabei aus den Namen der Funktionen beziehungsweise Automationen68 (zum Beispiel „Spezialist für Bonitätsprüfung zuordnen TP“ (Weiterleitung) oder 68

Für Weiterleitungen können auch die Namen der darüber modellierten Ereignisse verwendet werden (zum Beispiel „Spezialist für Bonitätsprüfung ist erforderlich“).

248


Abbildung 98: Erweiterungen des Agenten-Desktop für die Geschäftsprozesssteuerung „Lieferdaten erfassen TP“ (eigene Bearbeitung) aus Abbildung 82, Seite 213). Über die modellierten Eingangs-Ereignisse sind die Event-Typen bekannt, die in diesem Fall durch den Agenten-Desktop über den Notification-Service publiziert werden müssen69 . Über die bestehenden Abonnements werden dann die richtigen Teilprozesse gestartet. Darin enthaltene Agenten-Services sorgen für den notwendigen Bildschirmaufbau und die Präsentation des nächsten Arbeitsschritts.

Notwendige Event-Typen (CTI-Events und Prozess-Events) Aus der Beschreibung der Funktionsweise der Geschäftsprozesssteuerung lassen sich zwei Event-Typen identifizieren, die im Sinne der Signifikanz die beobachtete Situation eines Events beschreiben. Dies sind CTI-Events und Prozess-Events. Sie bilden den Inhalt des NachrichtenElements innerhalb der Event-Darstellung aus Abbildung 95 und grenzen sich wie folgt ab: • CTI-Events: CTI-Events stammen aus den Applikationsdomänen Multikanal und Routing, die mit der Signalisierung und Steuerung in den beteiligten Anwendungssystemen und untereinander erzeugt werden. Sie beinhalten auch Events, die die Statusmeldungen der Agenten betreffen, wie Login, Logout oder Pausenmeldungen. Für die Darstellung von CTI-Events kann auf den bestehenden Standard ECMA323 [vgl. ECMA, 2006] zurückgreifen werden. ECMA-323 bietet ein standardisiertes 69

Bei Weiterleitungen wird ein neuer Agent ausgewählt, bei eigenen Bearbeitungen wird die aktuelle Agenten-ID als Parameter mit übergeben. In beiden Fällen wird der BPEL-Prozess abgebrochen, entsprechende Web-Service-Schnittstellen müssen durch die Workflow-Steuerung zur Verfügung stehen, der Aufruf erfolgt über das Agent-Desktop-System


249

XML-Protokoll für CTI-Umgebungen. Darin sind folgende Event-Spezifikationen enthalten: – Call-Controll-Events [vgl. ECMA, 2006, Kap. 15.2] – Call-Associated-Features [vgl. ECMA, 2006, Kap. 16.2] – Events zu zugehörigen Medien (Kontaktkanäle) [vgl. ECMA, 2006, Kap. 17.2] – Routing-Events [vgl. ECMA, 2006, Kap. 15.2] – Events von Endgeräten auf physikalischer Ebene (dies schließt den AgentDesktop mit ein) [vgl. ECMA, 2006, Kap. 19.2] – Events von Endgeräten auf logischer Ebene (einschließlich der Agenten-Zustände wie Login, Logoff) [vgl. ECMA, 2006, Kap. 20.2] – Events zur Verwaltung der Endgeräte [vgl. ECMA, 2006, Kap. 21.2] – Events zu Voice-Dienstleistungen (IVR) [vgl. ECMA, 2006, Kap. 24.2] – Möglichkeiten zu proprietären Erweiterungen [vgl. ECMA, 2006, Kap. 26.3.1] Mit Hilfe des ECMA-323 können weitgehend alle wichtigen Events aus den beiden Applikationsdomänen dargestellt werden. Ein Großteil der Startereignisse der Geschäftsprozesse kann so im Prozessmodell mit den Eingängen von Kundenkontakten verknüpft werden. • Prozess-Events: Prozess-Events sind Events, die innerhalb eines fachlichen Prozessmodells (Geschäftsprozess, Teilprozess) definiert werden und Aussagen über den Prozessverlauf oder über Prozessergebnisse transportieren. Prozess-Events werden mit dem Referenzmodell neu eingeführt. Für die Darstellung von Prozess-Events konnte im Rahmen dieser Arbeit kein bestehender Standard beziehungsweise eine passende Spezifikation recherchiert werden. Aus diesem Grund werden in der nachfolgenden Tabelle 14 die notwendigen Elemente definiert und beschrieben. In konkreten Umsetzungsprojekten können diese Elemente angepasst und erweitert werden. Anschließend sind XML-Schemata zu definieren. Element

Beschreibung

Prozess-ID

Eindeutige Identifikation der Prozessinstanz

Kontakt-ID

Eindeutige Identifikation des zugehörigen Kontakts (Anruf, E-Mail, Fax)

Mögliche Werte

250


Element

Beschreibung

Mögliche Werte

Hierarchie

Hierarchie des zu Grunde liegenden fachlichen Prozessmodells analog den Hierarchieebenen des Contact-CenterProzessmodells (Abschnitt 8.5.2)

GESCHÄFTSFELD, KERNPROZESS, HAUPTPROZESS, GESCHÄFTSPROZESS, TEILPROZESS, AKTIVITÄT

Position

Position im Prozessverlauf

START, STOP, INTERMEDIATE

Fachliches Prozessmodell

Bezeichnung (ID) des zugehörigen fachlichen Prozessmodells

Technisches Prozessmodell, implementierender Service

Bezeichnung des zugehörigen BPELProzesses; das technische Prozessmodell ergibt sich aus der Übertragung aus dem fachlichen Modell (CIM – PIM – PSM)

Ressource

Ressource, die den Prozess zum Zeit- Agenten-ID punkt des Events bearbeitet hat (im Rahmen des Referenzmodells beschränkt auf Agenten)

Arbeitsplatz

Arbeitsplatz (bei manueller Tätigkeit), Arbeitsplatz-ID an dem der Prozess zum Zeitpunkt des Events bearbeitet wurde

Standort

Standort (Center, Zweigstelle, Home- Standort-ID Office), an dem der Prozess zum Zeitpunkt des Events bearbeitet wurde

Kanal

Kanal, über den der Kundenkontakt Liste der vorhandenen zum Zeitpunkt der Event-Generierung Kontaktkanäle besteht

Eventuell abgedeckt durch die Metadaten der Event-Darstellung (falls der Service oder BPEL-Prozess als Source-Komponente angegeben werden kann)


Element

Beschreibung

„Nutzlast“ und Typ

Die bearbeiteten Daten (Business- Frei wählbare XMLObjekte) des Prozesses Dokumente mit zugehörigem XMLNamensraum (zur Typbestimmung)

251

Mögliche Werte

Tabelle 14: Prozess-Event: Mögliche Attribute und Elemente

9.3.2. Kennzahlenerstellung Zum besseren Verständnis der Kennzahlenerstellung ist es zunächst hilfreich, die wichtigsten Kennzahlen eines Contact-Centers aufzustellen. Hier sind zwei bisher nebenläufige Bereiche zusammenzuführen: Auf der einen Seite gibt es die klassische Ablaufsteuerung eines Contact-Centers mit den wichtigsten kanalspezifischen Kenngrößen Wartezeit, Bedienwahrscheinlichkeit (Erreichbarkeit) und Auslastung [vgl. Helber und Stolletz, 2004, S. 42 - 43], [Zapf, 2003] (siehe Business-Intelligence in Abschnitt 2.3.1). Auf der anderen Seite sind Kennzahlen zu berücksichtigen, die mit der Prozessorientierung neu für Contact-Center hinzukommen (siehe Systematisierung von Geschäftsprozesskennzahlen in Abbildung 43, Seite 95). Die nachfolgende Tabelle 15 beinhaltet die wichtigsten Kennzahlen aus beiden Bereichen. Dabei wird primär das informationsorientierte Geschäftsprozesscontrolling unterstützt, es bildet die Grundlage für die darauf aufbauenden Teilgebiete des Controllings70 (vgl. Abschnitt 4.4.1).

70 71

Kennzahl

Quellen

Beschreibung und Konstruktion

Wartezeit

[Helber und Stolletz, 2004, S. 19, 42], [Zapf, 2003] [Götze, 2007] [Unger, 2009]

Die Wartezeit bezieht sich konkret auf die mittlere Wartezeit der bedienten Kunden. Die eigentliche Kennzahl ist der Erwartungswert der Wartezeit der Kunden, die einen Service erhalten: E(W|S) Bei der Konstruktion ist zu unterscheiden zwischen synchronen und asynchronen Vorgängen71 : Wsynchron = tAnruf annahme − tP rozessstart Wasynchron = tP rozessende − tP rozessstart

Diese sind nicht Inhalt des Referenzmodells. Aus der Wahrnehmung eines Kunden endet die Wartezeit bei synchronen Kanälen mit der Annahme

252


Kennzahl

Quellen

Beschreibung und Konstruktion

Bedienwahrscheinlichkeit, Erreichbarkeit, Service-Level

[Helber und Stolletz, 2004, S. 19, 42], [Zapf, 2003]

Anteil der Kunden, die einen Agenten oder Service innerhalb einer vorgegebenen Zeit (t) erreichen: P (W ≤ t|S) Beispiel: „Service-Level 80–20“ bedeutet, dass 80 % der Anrufer innerhalb von 20 Sekunden bedient werden; für asynchrone Kanäle wäre ein möglicher Service-Level: „80 % der E-Mails innerhalb 24 Stunden beantwortet, der Rest innerhalb von 48 Stunden“

Auslastung

[Helber und Stol- Anteil der Zeit in Taskbearbeitung inletz, 2004, S. 19, 42] kl. Nachbearbeitungszeit an der insgesamt zur Bearbeitung verfügbaren Zeit (Zeiten, in denen der Agent eingeloggt ist). tT askbearb. + tN achbearb. Auslastung = tLogin

Prozesszeiten

[Götze, 2007], [Schönheit et al., 1997], [Unger, 2009]

Zu den Prozesszeiten gehören: • Durchlaufzeiten • Rüstzeiten • Liegezeiten • Wartezeiten

Produktivität

[Götze, 2007], [Schönheit et al., 1997], [Gleich, 2002]

Weiterleitungen,[Zapf, 2003], Organisations- [Götze, 2007], [Unger, 2009] wechsel

Tabelle 15: Übersicht der Referenzmodell

wichtigsten

Die Produktivität ist das Verhältnis zwischen Output (Geschäftsprozesse) und Input (Zeit, Ressourcen), meist in der Form: Gesch¨ af tsprozesse P roduktivit¨ at = eingesetzte Zeit Anzahl von Ressourcenwechseln (Weiterleitungen) oder Organisationswechseln (Abteilungen, Standorte) innerhalb eines Geschäftsprozesses. Kennzahlen

im

Contact-Center

für

das

durch einen Agenten. Bei asynchronen Kanälen endet die Wartezeit erst mit dem Prozessergebnis (Zugang einer Reaktion, zum Beispiel einer E-Mail)


253

Um eine Aussagekraft zu erhalten, beziehen sich die oben aufgeführten Kennzahlen auf Dimensionen. So bezieht sich beispielsweise die Erreichbarkeit gleichzeitig auf die Dimensionen Zeit („Erreichbarkeit in der letzten Stunde“) und Kanal („Erreichbarkeit der Servicenummer 01805/1234“). Mit der Einführung der Prozessorientierung kommen für die bestehenden Kennzahlen Wartezeit, Bedienwahrscheinlichkeit und Auslastung neue Dimensionen hinzu. Während bisher eine Aggregation auf Kanäle, Service-Rufnummern oder ähnliches stattfand, ist dies nun auch auf die Hierarchiestufen des Prozessmodells möglich.

Funktionsweise Für die Kennzahlenerstellung werden die technischen Möglichkeiten des CEP beziehungsweise des ESP genutzt72 . Dabei erfolgt (ähnlich wie bei der Geschäftsprozesssteuerung) die Zuordnung eines EPA zu einer Kennzahl. Je nach zu Grunde liegendem Paradigma werden Kennzahlen mit Hilfe von Patterns (Event-Clouds) oder Queries (Event-Ströme) erstellt. Die Event-Typen, die hierfür abonniert werden müssen, sind die innerhalb der Geschäftsprozesssteuerung bereits verwendeten CTI- und ProzessEvents. Das jeweilige Abonnement eines EPA ergibt sich aus den Events, die innerhalb des Patterns beziehungsweise der Query verwendet werden. Das Ergebnis der Kennzahlenerstellung (eine Instanz einer Kennzahl) wird ebenfalls mittels eines Events zurück in einen Event-Strom beziehungsweise in eine Event-Cloud veröffentlicht (siehe Abbildung 99). Dadurch wird eine Entkopplung von der reinen Darstellung der Kennzahlen erreicht. Somit ist es möglich, unterschiedliche Technologien oder Hersteller zu integrieren. Die Kommunikation zwischen beiden ist dann Event-basiert, eine Integration entsprechend durch die Verwendung von Web-Service-Standards (Notification-Service und Event-Zustellung) geregelt.

Abbildung 99: Klassendiagramm der Kennzahlenerstellung mittels EPA Die Kennzahlen zu aggregieren und somit konkrete Kennzahlen (Instanzen) zu erzeugen, ist Aufgabe des EPN. 72

Welches Paradigma konkret wann gewählt wird, ist eine Entscheidung, die ebenfalls mit der Definition des EPN getroffen werden muss.

254


Notwendige Event-Typen (BAM-Events) Für die Darstellung und den Transport einzelner Kennzahleninstanzen wird als neuer Event-Typ das BAM-Event eingeführt. Ein bestehender Standard beziehungsweise eine Spezifikation hierzu konnte im Rahmen der Literaturrecherche nicht gefunden werden. Die Elemente eines BAM-Events müssen in konkreten Projekten gegebenenfalls erweitert und angepasst werden, um anschließend ein XML-Schema definieren zu können. Das BAM-Event enthält als Elemente die wichtigsten Attribute einer Kennzahl, sie werden in folgender Tabelle 16 zusammengefasst: Element

Beschreibung

Kennzahl-ID

Eindeutige Referenzierung der Kennzahl in Form einer ID

Mögliche Werte

KennzahlTyp

Verweis auf den Typ beziehungsweise die Klasse der Kennzahl im Sinne der Übersicht aus Tabelle 15

Meldung (Text)

Textmeldung eines Zustands, den Beispiel: „Zur Steigerung das Event repräsentiert (Signifi- der Produktivität ist ... erforderlich“ kanz)

Zahlenwert

Zahlenwert der Kennzahlinstanz mit Attributen für Einheit (Zeit, Stück, Währung) und Art (MIN, MAX, SCHNITT, WERT)

Dimensionen

Dimensionen im Sinne von Aggre- Aggregation zum Beispiel gationen nach: Kontaktkanal, Hierarchien des Prozessmodells, Zeit, Ressourcen, Organisationseinheiten usw.

Eventueller Verweis auf ein konkretes Modell nach dem Modelltyp „Kennzahlenbaum“ (siehe nachfolgenden Abschnitt 9.5.1

Pattern, Que- Bezeichnung (ID) des Patterns Eventueller Verweis auf ry oder der Query, mit denen die ein konkretes Modell nach dem Modelltyp „EventKennzahl erstellt wurde Verarbeitungs-Diagramm“ (siehe nachfolgenden Abschnitt 9.5.2) Tabelle 16: BAM-Event: Mögliche Attribute und Elemente


255

9.3.3. Kennzahlendarstellung, Event-Historisierung und Verbindung zu bestehenden BI-Lösungen Für die Überwachung durch Ereignisorientierung wurde bisher die allgemeine Funktionsweise der Erstellung von Kennzahlen in Form von EPA beschrieben. Zur Erreichung einer voll umfänglichen Überwachung, die komplett Event-basiert umgesetzt wird, sind noch weitere EPA notwendig. Abbildung 100 gibt hierzu einen Überblick.

Abbildung 100: Kennzahlendarstellung, Event-Historisierung und Verbindung zu bestehenden BI-Lösungen Neben dem bereits beschriebenen EPA „Kennzahlenersteller“ werden noch die folgenden EPA für ein Event-basiertes BAM benötigt: • Präsentations-System mit Enterprise-Cockpit: Das Präsentations-System dient als grundlegendes Server-System zur Kennzahlendarstellung. Es ist primärer Abonnent der BAM-Events, speichert diese zwischen und bereitet die Kennzahleninstanzen für die Präsentation und für das Reporting auf. Hierfür kommen Real-TimeEvent-Speicher in Form von Echtzeitdatenbanken in Frage (sogenannte In-MemoryDatenbanken). Das Enterprise-Cockpit stellt die Benutzeroberfläche zur grafischen Präsentation der Kennzahlen und Reports dar. Gemeinsam mit dem Präsentations-System bildet es Funktionalitäten des BAM ab [vgl. Casati et al., 2004, S. 825]. Der Zugriff auf die Reports und Kennzahlen erfolgt entsprechend rollenbasiert. Häufig findet eine technische Umsetzung mit Hilfe von Portal-Plattformen (Web-basiert) statt. Einen möglichen Standard zur Umsetzung bietet beispielsweise die Spezifikation von [Abdelnur und Hepper, 2003].

256


• Kennzahlenhistorisierer: BAM bildet einen Teilaspekt (Echtzeit) der Business-Intelligence ab. Es ist daher eingebunden in eine bestehende BI-System-Landschaft (Data-Warehouse, Portale). Die Kennzahlenerstellung kann hier genutzt werden, um das bestehende BI-System mit den notwendigen Grunddaten zu versorgen. Dies geschieht dadurch, dass die Kennzahleninstanzen (BAM-Events) über einen Schnittstellen-EPA in das BI-System übertragen werden können. Auf diese Weise lassen sich unter Umständen bestehende Datenintegrationen (Einlesen diverser Datenbanktabellen, Integrationen in bestehende Anwendungssysteme) ersetzen oder zukünftig vermeiden. • Bestehende BI-Systeme: In umgekehrter Richtung zur Kennzahlenhistorisierung lassen sich bestehende BI-Systeme auch als Kennzahlenlieferanten in das BAM integrieren. In diesem Fall werden BAM-Events von externen Quellen zur Verfügung gestellt. Als bestehende Kennzahlensysteme kommen in Contact-Centern in erster Linie ACD-Anlagen und deren Monitoring in Frage. Diese sind hoch-integriert und auf das Routing oder andere spezielle Anwendungsgebiete angepasst. Diese Spezialisierungen aufzugeben, wäre unter Umständen nachteilig für das gesamte BAM. Bestehende Lösungen können durch die Bereitstellung von BAM-Events in die Gesamtarchitektur mit aufgenommen werden. Entscheidend für das Referenzmodell ist die grundsätzliche Aufteilung der Funktionalitäten auf die oben beschriebenen EPA und eine Event-basierte Kommunikation zwischen den EPA. Eine Ausgestaltung der EPA dieses Abschnitts ist Angelegenheit einer konkreten Umsetzung, entsprechend erfolgt hier keine genauere Darstellung. In vielen Fällen können bestehende Systeme (oder Teile daraus) diese Funktionalitäten abbilden.

9.4. Das Event-Processing-Network (EPN) im Contact-Center Die logische Verbindung aller EPA bildet das EPN. In den folgenden Abschnitten wird eine Topologie eines EPN für Contact-Center vorgeschlagen. Zum besseren Verständnis werden anschließend einzelne Kennzahlen beispielhaft in einer konkreten CEP-Sprache umgesetzt. Die Möglichkeit, mit Hilfe des EPN ein sogenanntes „Performance-Netzwerk“ abzubilden, wird abschließend betrachtet.

9.4.1. Topologie des EPN Mit dem Design des EPN findet eine genaue Zuordnung von Kennzahlen zu ihren umsetzenden EPA statt. Da das EPN in Hierarchien unterteilt ist, lassen sich so die Dimensionen der Kennzahlen abbilden. Aus diesem Grund ist für das endgültige Design eines EPN ein bestehendes Kennzahlensystem notwendige Voraussetzung. In erster Linie werden durch CEP Kennzahlensysteme von der Art eines Rechensystems [vgl. Tavasli, 2007, S. 177]

9.4. Das Event-Processing-Network (EPN) im Contact-Center

257

abgebildet. Abbildung 101 gibt deshalb einen Überblick über die möglichen Komponenten und Hierarchieebenen eines EPN innerhalb von Contact-Centern. Das EPN zeigt gleichzeitig die Gesamtarchitektur der Ereignisorientierung. Die Verbindung zur Serviceorientierung ist über das Event-Enabling gegeben.

Abbildung 101: Topologie eines EPN in Contact-Centern Die einzelnen Ebenen sind virtuell, sie gliedern eine Event-Cloud in Bereiche. Im Sinne der Aufteilung nach Scopes (siehe Abschnitt 6.2.2) bilden sie einen ersten Ansatzpunkt zur Begrenzung der Sichtbarkeit. Dies würde allerdings die Event-Cloud in kleinere (private) Event-Clouds unterteilen. Der Steuerungsgedanke aus DEBS steht so der freien und dynamischen Bildung komplexer Events mittels ECA-Regeln und ihrer Hierarchien gegenüber. Innerhalb des Referenzmodells findet daher keine Unterteilung der Event-Cloud mit Hilfe von Sichtbarkeiten statt. Dies geschieht aus zweierlei Überlegungen heraus: Erstens dient die Einführung von Scopes der Steuerbarkeit. Dies ist jedoch durch das Prozessmodell und die sich daraus ergebenden Abonnements bereits abgedeckt. Zweitens geben die Untersuchungen zur Performanz durch [Melzer, 2007, S. 155 ff.] (Abschnitt 5.2.2) und

258


[White et al., 2008] (Abschnitt 6.3.4) keinen Grund für die technische Einschränkung einer Event-Cloud innerhalb der Anwendungsbereiche Geschäftsprozesssteuerung und BAM. Werden mit Hilfe des EPN die Kennzahlen aus Tabelle 15 abgebildet, so befinden sich zwischen der Steuerungs- und Geschäftsprozessebene mindestens sechs EPA, die jeweils eine Kennzahl mit der Dimension „Geschäftsprozessinstanz“ erzeugen (siehe Abbildung 102). Für die Aggregation zur nächst höheren Ebene sind weitere dedizierte EPA notwendig.

Abbildung 102: Ausschnitt aus einem EPN zur Umsetzung der wichtigsten Kennzahlen Für jeden EPA ist eine Entscheidung bezüglich der Implementierung zu treffen. Dies schließt vor allem die Frage nach dem verwendeten Paradigma und dem umsetzenden CEP-System mit ein. Diese Entscheidung ist für jeden EPA individuell zu treffen. Auch eine Verschachtelung von EPN ist möglich, dann werden private EPN gebildet, die in der Form eines EPA in das darüber liegende EPN eingegliedert werden (dies ist meist der Fall, wenn CEP-Systeme intern Ströme und Clouds abbilden). Für die Zuordnung der Paradigmen kann grundsätzlich dem Vorschlag von [Chakravarthy und Adaikkalavan, 2008] (Abschnitt 6.3.3, Seite 158) gefolgt werden, wonach auf den unteren Ebenen eher der Einsatz von ESP, auf den oberen Ebenen eher der Einsatz von ECA-Regeln erwogen wird. Da aber technische Ebenen mit hohem Eventaufkommen sich außerhalb der Aspekte der Geschäftsprozesssteuerung und des BAM befinden und entsprechende Performanzüberlegungen nicht zwingend relevant sind, findet eine Entscheidung nach den jeweils vorliegenden Anforderungen statt. Im Sinne der angestrebten Angleichung von ESP und ECA-Patterns [vgl. Luckham, 2006] verliert die Paradigmenfestlegung außerdem an Wichtigkeit. 9.4.2. Beispielhafte Umsetzung einzelner Kennzahlen Um die Implementierung von EPA für das BAM zu konkretisieren, werden Queries und Patterns zur Generierung einzelner Kennzahlen aus Tabelle 15 dargestellt und erklärt. Sie bilden Kennzahlen für die Dimension der Geschäftsprozessebene ab (siehe auch Abbildung 102). Da es im Bereich der EPL keine standardisierten ECA- oder ESP-Sprachen


259

gibt, erfolgt die Darstellung der Queries (ESP) mit Hilfe der Sprache [CCL, 2009], die Darstellung von ECA-Patterns mit Hilfe von [Esper, 2009]73 . Die Generierung der Wartezeit findet mittels ESP statt ([CCL, 2009]). Die Besonderheit hierbei ist die Zuordnung von Multikanalvorgängen zu den Prozessinstanzen der Geschäftsprozesssteuerung: INSERT INTO Wartezeiten_Synchron_Stream /* Typ BAM-Event */ SELECT

/* Attribute des Events und BAM-Events, z. B. */ ’Wartezeit_synchron’ AS Kennzahlen-Typ, A.Entstehungszeit - H.Entstehungszeit AS Zahlenwert, /* weitere Attribute des Events und BAM-Events */

FROM

Prozess_Event_Stream AS A, CTI_Event_Stream AS H KEEP ALL ROWS PER H.ECMA-Kontakt-ID

WHERE

A.ECMA-Kontakt-ID = H.Kontakt-ID AND A.ECMA-Controll-Event = ’Pick-Up’ /* Call wird angenommen */ AND H.Position = ’START’ /* Prozessbeginn */ AND A.Entstehungszeit > H.Entstehungszeit

INSERT INTO legt den Stream fest, in dem das erzeugte BAM-Event veröffentlicht wird. Dieser Stream ist zunächst nur innerhalb des EPA (in diesem Fall innerhalb des Coral8Projekts) sichtbar. Eine Veröffentlichung findet dann statt, sobald der Stream über den Notification-Service ein Event in die Event-Cloud sendet. Mit Hilfe der Anweisung SELECT werden die Event-Attribute befüllt und das BAM-Event zusammengestellt. Die FROMKlausel legt die Ströme des Event-Eingangs fest. Hinter den Strömen sind über Adapter die bereits beschriebenen Zustellmechanismen implementiert. Innerhalb des Elements WHERE werden Regeln festgelegt. Sobald der Gesamtausdruck wahr ist, wird ein Event erzeugt. Das Matching beider Events wird analog einem Join in SQL-Sprachen über den Ausdruck WHERE A.ECMA-Kontakt-ID = H.Kontakt-ID erreicht. Die Bedienwahrscheinlichkeit (Erreichbarkeit, Service-Level) wird ebenfalls mit Hilfe von [CCL, 2009] erzeugt: INSERT INTO SLA-Stream /* Typ BAM-Event */ SELECT

/* Attribute des Events und BAM-Events, z. B. */ ’Service-Level’ AS Kennzahlen-Typ, to_float(COUNT(W.Zahlenwert) / COUNT(G.Zahlenwert)) AS Zahlenwert, /* weitere Attribute des Events und BAM-Events */

FROM

Wartezeiten_Stream AS W KEEP 15 MINUTES, Wartezeiten_Stream AS G KEEP 15 MINUTES

73

CCL ist Teil des Produkts Coral8 (www.coral8.com), Esper ist ein CEP-Open-Source-Projekt (esper.codehaus.org). Zur besseren Lesbarkeit wurden die Sprachkonstrukte verkürzt (sie zeigen nur Ausschnitte) und teilweise vereinfacht. Zusätzliche Erklärungen wurden als Kommentare innerhalb der Sprachkonstrukte eingefügt. Die Darstellung der Event-Elemente entspricht jeweils den internen Datenformaten, eine Transformation ist entsprechend vorausgesetzt. Die Bezeichnung der Elemente folgt weitgehend den Event-Beschreibungen in Abbildung 95, nach [ECMA, 2006] und aus den Tabellen 14 und 16.

260


WHERE

W.Fachliches_Prozessmodell = G.Fachliches_Prozessmodell AND W.Zahlenwert ) bis zum Eintreffen eines End-Events (Ausdruck until e3). Das Pattern ist insgesamt eingebunden in ein select-Statement ähnlich der [CCL, 2009]. Nach den Mustern every ... -> ... until ([Esper, 2009]) der Weiterleitungen beziehungsweise dem KEEP ALL ROWS ([CCL, 2009]) der Durchlaufzeiten kann jeweils die Anzahl der bearbeiteten Geschäftsprozesse für die Berechnung der Produktivität ermittelt werden. 9.4.3. Schaffung eines Performance-Netzwerks Mit den dargestellten EPA und der Topologie des EPN werden mindestens drei der vier Ebenen des BAM nach [McCoy, 2007] abgedeckt: Instanzebene, Typ- und Klassenebene sowie Historie. Die vierte Ebene bezieht sich auf das Monitoring externer Einflüsse. Das technische Aufdecken externer Einflüsse geschieht mittels CEP durch dedizierte EPA mit entsprechenden ECA-Patterns und einer Erweiterung des Hierarchiemodells. Am Ende dessen steht die Veröffentlichung eines entsprechenden BAM-Events, das die externe Situation bezeichnet. Um die Zielsetzung der Flexibilisierung und Reaktivität aus Abschnitt 8.2 (Seite 180) voll umfänglich umzusetzen, das heißt in das Geschäftsprozessmanagement und eine automatisierte Prozessumgebung zu integrieren, bedarf es einer zusätzlichen Erweiterung der Funktionalitäten des EPN: Es entsteht ein sogenanntes „Performance-Netzwerk“. Als Performance-Netzwerk wird ein Modell bezeichnet, in dem die kausalen Zusammenhänge zwischen Kennzahlen und Geschäftsprozessen (siehe Abbildung 103) aufeinander abgestimmt und im Sinne eines Regelkreises modelliert, analysiert und kontrolliert werden. Besondere Beachtung findet dabei die automatisierte Ausnahmebehandlung und gezielte Anpassung bei zustandsbezogener Kennzahlenverletzung mit Hilfe von Workflows [vgl. bspw. Mevius et al., 2009].

Abbildung 103: Geschäftsprozess modelliert als Performance-Netz [aus Mevius et al., 2009, S. 259] Die Idee des Performance-Netzwerks wird innerhalb des Referenzmodells aufgegriffen. Mit dem bisher dargestellten EPN werden Kennzahlen erzeugt, die mit Hilfe ihrer Metriken

262


den Zustand der automatisierten Geschäftsprozesse (und somit den Zustand der Prozessorganisation) beschreiben. Zum Performance-Netzwerk fehlt noch der regelnde RückEinfluss des momentanen Zustands auf die Geschäftsprozesse selbst, das heißt auf deren Ablauf. Konkret kann dies auf verschiedene Arten erfolgen: • Warnung und Kompensation: Werden bestimmte Zustände erreicht (Kennzahlen über- oder unterschreiten festgelegte Schwellwerte oder dedizierte EPA erkennen mittels CEP Situationen) können automatisierte Prozesse (Services) ausgeführt werden. Diese können dazu dienen, Warnmeldungen abzugeben oder Kompensationen zu starten [vgl. Mevius et al., 2009, S. 260 ff.]. Sinkt beispielsweise die Erreichbarkeit, kann ein Supervisor informiert oder das Routing automatisch angepasst werden, um den Pool der möglichen Agenten zu erweitern (etwa durch Senkung des benötigten Skill-Levels). • Dynamische Anpassung: Der weitaus größere Nutzen liegt in der dynamischen Anpassung des Ablaufs der Geschäftsprozesse, wodurch letztendlich eine umfängliche Flexibilisierung und Reaktivität erreicht wird. Für eine konkrete Umsetzung ist es wiederum wichtig, bestehende Standards und Technologien zu nutzen. Mit den Komponenten des Referenzmodells sind soweit bereits alle wesentlichen fachlichen und technischen Voraussetzungen geschaffen. Aus fachlicher Sicht macht eine dynamische Anpassung der Teilprozessabfolge (das heißt eine Dynamisierung der Geschäftsprozessautomation) am meisten Sinn, denn hier sind die Granularitäten bereits durch das Contact-Center-Prozessmodell angepasst. Mit Hilfe der Teilprozesse lassen sich für „Normal- und Spezialzustände“ mehrere fachliche Varianten modellieren, die auf abweichende Start-Events reagieren. Eine Entscheidung, welcher Teilprozess in der Abfolge als nächstes gestartet wird, ist davon abhängig, welches Event in der Event-Cloud vorhanden ist. In Abbildung 104 werden die beiden hierfür notwendigen EPA als konkrete Objekte dargestellt. Ihre Zuständigkeiten sind dabei wie folgt: 1. ECA-Pattern-Erkenner::komplexe_Situation: Das Erkennen einer bestimmten Situation (Kennzahl, komplexe Situation) obliegt einem dedizierten EPA. Dies können die bereits bestehenden EPA der Kennzahlengenerierung sein oder neue, die mittels CEP komplexe Situationen entdecken. Als Ergebnis erfolgt lediglich die Veröffentlichung eines BAM-Events und keinerlei andere Reaktion (kein Aufruf eines Workflows). 2. ECA-Pattern-Erkenner::neues_Startereignis: Ein weiterer dedizierter EPA übernimmt die Entscheidung, welche Variante eines Teilprozesses gestartet wird. Diese Entscheidung ist von zwei Einflussfaktoren abhängig: dem Eintreten des eigentlichen Start-Events (Startereignis oder Ergebnis eines vorgelagerten Teilprozesses) und dem Vorhanden- oder Nichtvorhandensein der beeinflussenden Situation von oben. Dies wird in einem entsprechenden Pattern oder einer Query festgelegt. Als


263

Abbildung 104: Prozessautomatisierung innerhalb eines Performance-Netzwerks Ergebnis erfolgt die Veröffentlichung nur eines Prozess-Events. Je nach Abonnement wird die passende Teilprozessvariante gestartet. Zur Verdeutlichung eignet sich als Beispiel erneut eine Verschlechterung der Auslastungssituation. Unter normaler Auslastung würde im Geschäftsprozess „Bestellung“ die Erfassung mittels des Teilprozesses „Bestellung manuell erfassen TP“ erfolgen. Tritt eine Verschlechterung ein, wird dies durch den 1. EPA erkannt und als ein eigenes BAM-Event veröffentlicht. Dieses wird durch den 2. EPA registriert und ein entsprechend angepasstes Prozess-Event wird veröffentlicht, das automatisch den Teilprozess „Bestellung automatisch über IVR erfassen TP“ startet. Die Dynamisierung der Geschäftsprozesssteuerung findet so automatisiert statt. Eine klare Trennung zwischen dem Erkennen, der Entscheidung und der Reaktion bleibt dadurch erhalten. Eine Anpassung an BPEL ist nicht erforderlich, es werden lediglich neue EPA im EPN deployed. Als Ergebnis kann festgehalten werden, dass aus Sicht der Geschäftsprozesssteuerung diese statisch (durch Geschäftsprozessmodelle), manuell (durch den Agenten-Desktop)

264


und dynamisch (durch das Performance-Netzwerk) möglich ist. Hierfür gibt es eine einzige Architektur, das EPN, die gleichzeitig auch die Überwachung implementiert.

9.5. Erweiterung des Prozessmodells um Aspekte der Ereignisverarbeitung Zur Komplettierung des Referenzmodells muss als letzter Schritt das Contact-CenterProzessmodell um die Aspekte der Ereignisverarbeitung erweitert werden. Hierzu werden zwei Diagrammtypen dem Prozessmodell hinzugefügt. Abschließend werden die Zusammenhänge im integrierten Geschäftsprozessmanagement dargestellt.

9.5.1. Sammlung der Kennzahlen in Kennzahlenbäumen Das Kennzahlensystem wurde als notwendige Voraussetzung für das konkrete Design des EPN identifiziert. Für die Modellierung des Kennzahlensystems wird der bereits bestehende ARIS-Diagrammtyp „Kennzahlenbaum“ genutzt und als eigener Modelltyp in das Contact-Center-Prozessmodell aufgenommen. Der Kennzahlenbaum dient der strukturierten Darstellung der Kennzahlen und ihrer Hierarchieebenen. Dabei werden fachlich orientierte Kennzahlengruppen gebildet. Einzelne Kennzahlenobjekte werden mit Hilfe des Objekttyps „Kennzahleninstanz“ modelliert (Beschreibung im folgenden Abschnitt) und hierarchisch durch Kanten angeordnet [vgl. Kronz, 2006, S. 36]. Kennzahlenbäume decken alle drei Arten von Kennzahlensystemen (Rechensystem, Ordnungssystem, Zielsystem) nach [Tavasli, 2007, S. 177] ab.

9.5.2. Prozessmodell Event-Verarbeitungs-Diagramm Zwischen dem Prozessmodell Teilprozess (die darin modellierten Aktivitäten) und den ausführenden Web-Services (Schnittstellen der BPEL-Prozesse) gibt es einen direkten Bezug, der eine Verbindung zwischen der Prozess- und der IT-Welt schafft. Eine ähnliche Verbindung fehlt im Bereich der Eventverarbeitung, die mit Hilfe eines neuen Modelltyps, dem Event-Verarbeitungs-Diagramm, eingeführt wird. Das Event-VerarbeitungsDiagramm wird Bestandteil des Contact-Center-Prozessmodells, das heißt, alle Objekte und Attribute sind Teil des zu Grunde liegenden Datenmodells des Prozessmodells. Jeder EPA wird durch ein ihm zugehöriges Event-Verarbeitungs-Diagramm modelliert. Es schafft somit die Verbindung zwischen den Prozessmodellen Teilprozesse und Geschäftsprozesse und dem Kennzahlenbaum. Die hierfür modellierbaren Objekte werden nach dem Muster in Abbildung 105 zu einem Event-Verarbeitungs-Diagramm kombiniert.

9.5. Erweiterung des Prozessmodells um Aspekte der Ereignisverarbeitung

265

Abbildung 105: Beispiel eines Event-Verarbeitungs-Diagramms als neuer Diagrammtyp in ARIS Die zugehörigen Modellierungskonventionen zur Erstellung eines Event-VerarbeitungsDiagramms und zur Verwendung der möglichen Objekte beschreibt Tabelle 17. Objekt

Verwendung

Objekttyp Pattern (Entitytyp) • Der Objekttyp Pattern bezeichnet das ECAPattern beziehungsweise die Query des EPA. • Eine URI des Patterns oder der Query wird als eigenes Attribut gepflegt.

266


Objekt

Verwendung

Objekttyp Ereignis • Als Ereignisse werden alle Events modelliert, die der EPA konsumiert und erzeugt. • Ereignisse werden über Kanten mit dem Objekttyp Pattern verbunden. • Die Beziehung zum Objekttyp Pattern wird über die Kantentypen „ist Input von“ und „erzeugt“ spezifiziert. Objekttyp Anwendungssystemtyp • Modellierung des CEP-Systems, das das Pattern beziehungsweise Query ausführt. • Anwendungssystemtypen werden über Kanten mit dem Objekttyp Pattern verbunden. Objekttyp Kennzahleninstanz • Modellierung der Kennzahleninstanz, die durch das Pattern erzeugt wird. • Die Summe der Kennzahleninstanzen wird im Kennzahlenbaum strukturiert modelliert, eine Kennzahleninstanz daraus wird im Event-Verarbeitungs-Diagramm verwendet. • Die Kennzahleninstanz wird über eine Kante mit dem Ausgangs-Ereignis (Nachrichten-Typ ist ein BAM-Event) verbunden, das die Kennzahleninstanz transportiert. Objekttyp Service • Web-Service des CEP-Systems, das das Pattern implementiert


Objekt

267

Verwendung

Objekttyp Operation • Operation des Web-Services zur Event-Zustellung

Tabelle 17: Modellierungskonventionen für das Event-Verarbeitungs-Diagramm Das Event-Verarbeitungs-Programm erhebt nicht den Anspruch, die verwendeten Patterns und Queries fachlich zu modellieren. Hierfür müssen entsprechende EPL-Notationen entwickelt und standardisiert werden. Vielmehr ist durch die Zuordnung von Kennzahleninstanzen die fachliche Anforderung mit der technischen Entität des Patterns beziehungsweise der Query verbunden, die damit umgesetzt werden soll. Aus fachlicher Sicht ist dies ausreichend, da die Entwicklung von Patterns und Queries durch eine eigene Rolle im Unternehmen, dem Event-Modellierer [vgl. Ammon et al., 2008], abgedeckt ist. Durch die modellierte Input-Beziehung der Ereignisse zum Objekttyp Pattern lassen sich zusätzlich die Abonnements gegenüber dem Notification-Service ableiten. Dies geschieht analog dem Vorgehen der Abonnements aus den Teilprozessmodellen aus Abbildung 97 (Seite 247). Technisch gesehen muss das Event-Verarbeitungs-Diagramm als neuer Modelltyp in der ARIS-Plattform administrativ erzeugt werden. Dies geschieht mittels der Modellgenerierung [vgl. Davis, 2008, S. 95 ff.], wobei in diesem Fall nicht auf bestehende Modelltypen zurückgegriffen werden kann (die Modelltypen „Geschäftsprozess“ und „Teilprozess“ sind Abwandlungen des ARIS-Modelltyps „EPK“). 9.5.3. Gesamtzusammenhang im integrierten Geschäftsprozessmanagement Das integrierte Geschäftsprozessmanagement manifestiert sich technisch in einem abgestimmten und unternehmensweit verwendeten Modellportfolio. Im Rahmen dieses Referenzmodells wurde hierzu das Contact-Center-Prozessmodell geschaffen. Es enthält verschiedene Modelltypen, mit denen jeweils Teilaspekte des gesamten Unternehmens modelliert werden können. Zu den Teilaspekten gehören das Geschäftsprozessmanagement an sich, die Serviceorientierung sowie die Eventverarbeitung. Teilweise wurde auch das Wissensmanagement mit aufgenommen (das Management von Wissen wird nicht behandelt, jedoch wurden Berührungspunkte mit in den Prozessablauf und die Automatisierung integriert). Für die Teilaspekte gibt es eigene Modell- und Objekttypen. Zwischen diesen bestehen Beziehungen, die entweder über Hinterlegungen (Vertiefung der Detaillierungstiefe) oder über Referenzen (Fremdschlüssel zu anderen Entitäten) dargestellt werden können.

268


Mögliche Fragestellungen aus dem Alltag des Managements können so leichter beantwortet werden: Die Verletzung einer bestimmten Kennzahl hat Auswirkungen auf welche Geschäftsprozesse? Welche Geschäftsprozesse werden dynamisch angepasst? Änderungen an einen Geschäftsprozess werden angezeigt durch welche Kennzahlen? Die Events, die innerhalb eines EPA verarbeitet und analysiert werden (vor allem CEP), werden von welchen Systemen (CTI-Events) oder Geschäfts- beziehungsweise Teilprozessen erzeugt (Prozess-Events)? Welche Stellen, Anwendungssysteme, Wissensthemen, Dokumente und so weiter sind an einem bestimmten Geschäftsprozess beteiligt? Diese und ähnliche Fragestellungen können auf Grund des vorhandenen und einheitlichen Datenmodells des Contact-Center-Prozessmodells jederzeit beantwortet werden. Die notwendigen Zusammenhänge der einzelnen Modell- und Objekttypen zeigt die Abbildung 106.

Abbildung 106: Gesamtzusammenhang im Referenzmodell Welch eine zentrale Rolle Events dabei in der realen Welt spielen, findet entsprechend seinen Ausdruck im Prozessmodell mit der durchgängigen Verwendung des Objekttyps Ereignis. Ereignisse bilden die Verbindung zwischen der Eventverarbeitung in den EPA


269

(modelliert jeweils in Event-Verarbeitungs-Diagrammen) und der Prozessautomatisierung (gegeben durch die Teilprozesse und Aktivitäten, die jeweils durch Web-Services implementiert werden). Darüber hinaus besteht ein weiterer, wesentlicher Vorteil des Contact-Center-Prozessmodells in der Schaffung einer einheitlichen „Gesprächsgrundlage“ für die beiden beteiligten Domänen. Die viel zitierte semantische Lücke zwischen Fachabteilungen und umsetzender IT wird teilweise dadurch geschlossen, dass beide Seiten mit den Modelltypen des Contact-Center-Prozessmodells arbeiten. Aus fachlicher Sicht werden die wesentlichen Strukturen vorgegeben. In vielen Fällen bilden die einzelnen Modelle wesentliche Teile eines Pflichtenhefts ab, etwa bei der Festlegung der Service-Granularität. Mit den fachlichen Modellen werden Verbindungen geschaffen zu den zugehörigen technischen Modellen (UML-Diagramme, BPEL-Modelle, EPL-Modelle) und Systemen. Diese bleiben weiterhin in der Hand der IT, sie finden jedoch durch die Referenzierung innerhalb des Prozessmodells ein Raster, das wiederum nach den Zielsetzungen des Unternehmens (zum Beispiel die Kundenorientierung) aufgebaut ist. Dieses Raster, primär die Geschäftsprozesse mit den verbundenen Modellen, ist primärer Managementgegenstand.

271

10. Zusammenfassung Am Schluss dieser Arbeit wird zunächst das gewählte Vorgehen zusammengefasst. Darauf hin werden die gewonnenen Ergebnisse nochmals explizit vorgestellt und anschließend bewertet. Ein Ausblick auf weitergehende Forschungsfragen schließt die Arbeit ab.

10.1. Vorgehen Als übergeordnete Zielsetzung dieser Arbeit wurde die Prozessautomatisierung in ContactCentern gewählt. Damit verbunden sind die Entwicklung einer innovativen, umsetzenden Systemarchitektur und die Ausgestaltung des Geschäftsprozessmanagements als umfassendes, integriertes Managementsystem. Der Zusammenhang zwischen den Themengebieten wird in der Praxis nicht ausreichend berücksichtigt, was daraus resultiert, dass in Contact-Centern eine Zweiteilung zwischen Fach- und IT-Abteilungen herrscht. Diese Zweiteilung findet sich sowohl auf Managementebene als auch auf operativer Ebene wieder. Dies führt zum Grundproblem der nicht durchgängig vorhandenen methodischen und technischen Unterstützung der Kundenorientierung. Insbesondere finden dabei die speziellen Charakteristiken von Contact-Centern keine Berücksichtigung. Basierend auf diesen Erkenntnissen wurden zunächst die betriebs- und volkswirtschaftlichen Rahmenbedingungen erarbeitet, in denen sich Contact-Center als Dienstleistungsunternehmen bewegen. Daraus konnten die wichtigsten strategischen Einflussgrößen abgeleitet werden. Im Rahmen der Beschäftigung mit den Themenbereichen „Aufbau und Organisation von Contact-Centern“, „Geschäftsprozessmanagement“, „Serviceorientierung“ und „Ereignisorientierung“ konnte jeweils der aktuelle Forschungsstand herausgearbeitet werden. Aus den einzelnen Darstellungen wurden die Zusammenhänge analysiert und nutzbare Methoden, Standards und Technologien identifiziert. Ergänzt durch Erfahrungen aus der Praxis wurde aus der Summe der gewonnenen Erkenntnisse der Status quo erarbeitet, aus dem entsprechende Handlungsfelder abgeleitet werden konnten. Zusammen mit den strategischen Einflussgrößen und den Ergebnissen aus den einzelnen Themenbereichen wurde der Neuansatz des Referenzmodells erarbeitet. Das Referenzmodell wurde auf der Basis entsprechender Vorgehensmodelle entwickelt. Für das Design der einzelnen Komponenten des Referenzmodells wurde größtenteils auf Bewährtes zurückgegriffen und dieses innovativ zu einem integrierten Modell kombiniert.

10.2. Ergebnisse und Bewertung Die Ergebnisse dieser Arbeit lassen sich als Antworten auf die in Abschnitt 1.2.1 gestellten Fragestellung darstellen, womit gleichzeitig der Forschungsbeitrag zusammengefasst


272

10. Zusammenfassung

wird. 1. Welche sind die aktuellen Anforderungen und Herausforderungen eines ContactCenters beziehungsweise eines Contact-Center-Dienstleisters? Kundenorientierung und Industrialisierung wurden als wesentliche und verknüpfbare Einflussfaktoren identifiziert. Die Anwendbarkeit der Prozessorganisation für Contact-Center (als Organisationsform der Kundenorientierung) konnte klar nachgewiesen werden. Die Automatisierung (als Konkretisierung der Industrialisierung) ist weiter ausbaubar. Große Herausforderungen sind dabei die unterschiedlichen Prozessdomänen, die starke Heterogenität der Systemlandschaft, ein zu geringer Einfluss der Fachabteilungen auf die Umsetzung und der negative Einfluss der Volatilität auf Automatisierungsbestrebungen. Darüber hinaus ist die Fähigkeit zur Reaktivität und Flexibilität nicht im erforderlichen Umfang gegeben, um den Einflussfaktoren adäquat zu begegnen. 2. Wie sieht SOA konkret in einem Contact-Center aus? Wie lassen sich Geschäftsprozessmanagement und SOA vereinen und lässt sich die Summe aus beiden auch für Prozessautomatisierung und Servicegranularität gebrauchen? Für die Identifikation von Services wurden Applikationsdomänen identifiziert. Daraus konnten vier abstrakte Service-Klassen, sogenannte Service-Typen, abgeleitet und beschrieben werden, mit deren Hilfe sich technisch alle vorhandenen Anwendungssysteme integrieren lassen und alle Fachlichkeit abbilden lässt. Die wichtigsten Integrations- und Implementierungsaspekte wurden dazu beschrieben. Parallel dazu wurde ein Contact-Center-Prozessmodell auf Basis von ARIS definiert. Dieses Prozessmodell enthält auf Contact-Center abgestimmt folgende Komponenten: Ein Hierarchiekonzept, zu den Hierarchieebenen zugeordnete neue Modelltypen, die jeweils um Modellierungskonventionen und Heuristiken ergänzt wurden. So lässt sich die gesamte Wertschöpfung der Kernprozesse eines Contact-Centers mit Hilfe des Prozessmodells abbilden. Als Services werden zwei Modelltypen automatisiert: Teilprozesse und Aktivitäten. Die Granularität ist dabei komplett durch das Prozessmodell geklärt, Heuristiken helfen bei der Einteilung während der Modellierung. Das Prozessmodell dient als Fachkonzept für die Umsetzung der Services, die klassische Workflow-Ausführung (mittels BPEL) ist dabei auf feingranulare Aktivitäten begrenzt. Für „human interaction“ wird der Standard WS-Human Task verwendet. Wichtige Komponente zu dessen Umsetzung ist das Agenten-Desktop-System, für das entsprechende Anpassungen beschrieben wurden. Der Standard BPEL4People ist nicht notwendig. Besonderheiten einer SOA im Contact-Center sind die Kapselung der Kommunikationsprozesse als eigene Routing-Services, ihre Aufnahme in die fachliche Prozessmodellierung und die Spezifikation manueller Tätigkeiten als Agenten-Services inklusive aller benötigten Parameter für die Desktopgestaltung. Die Attribute und

10.2. Ergebnisse und Bewertung

273

Parameter für die Umsetzung der Service-Typen wurden in die Modellierungskonventionen aufgenommen und sind als Objekte und Attribute im Prozessmodell hinterlegt. Im Rahmen der Modellierung manueller Tätigkeiten und deren Umsetzung mittels Agenten-Services wurden für Contact-Center wichtige Aspekte der MenschComputer-Interaktion sowie des Wissensmanagements in das Referenzmodell aufgenommen. 3. Was ist der aktuelle „State of the Art“ im Bereich Eventverarbeitung? Welche Anwendungsbereiche gibt es hierfür im Contact-Center und wie müssen diese gestaltet werden? Es gibt hauptsächlich zwei Anwendungsbereiche der Ereignisorientierung: Integration und Monitoring. Hierfür gibt es zwei Ansätze, die ereignisorientierten verteilten Systeme (DEBS) und CEP. Beide haben komplementäre Eigenschaften und sie bedingen sich einander. DEBS liefert die notwendige Infrastruktur, um CEP zu implementieren. Es wurde der Nachweis erbracht, dass beide Anwendungsbereiche auch auf Contact-Center übertragen werden können. Dies konkretisiert sich in der Geschäftsprozessautomatisierung und der Überwachung des Geschäftsbetriebs. Eine allgemein nutzbare und umfangreiche Referenzarchitektur der Ereignisverarbeitung gibt es hierfür noch nicht, sie musste vorab konstruiert werden (siehe 4.) Die Gestaltung der Anwendungsbereiche im Contact-Center sieht wie folgt aus: Die Geschäftsprozessautomatisierung steuert Event-basiert den Ablauf von Teilprozessen (gröbere Granularität). Dafür bedarf es keines eigenen Prozessmodells (etwa BPEL oder eine Erweiterung dazu), sie besteht lediglich aus einer Reihe von Event-Abonnements. Als fachliches Modell genügt die Modellierung im ContactCenter-Prozessmodell auf Basis von EPK, aus dem die Abonnements abgeleitet werden können (statisches Modell). Die technische Umsetzung erlaubt zusätzlich eine Steuerung durch manuelle Event-Erzeugung (wodurch der Volatilität begegnet wird) sowie eine dynamische Steuerung auf Basis der momentanen Situation des Geschäftsbetriebs. Letztere wird größtenteils mittels Kennzahlen abgebildet, die mit Hilfe von CEP in Echtzeit erstellt werden. Dazu wurde die entsprechende Infrastruktur eines EPN definiert und es wurden notwendige Klassen von EPA entworfen. Das gesamte EPN ist so aufeinander abgestimmt worden, dass auf Veränderungen im Geschäftsbetrieb automatisch reagiert werden kann, wodurch insgesamt ein mittels der Ereignisverarbeitung implementiertes Performance-Netzwerk entsteht, das ein regelungs- und steuerungsbasiertes Controlling innovativ und automatisiert umsetzen kann. 4. Wie muss ein innovatives und praxistaugliches Referenzmodell für Contact-Center aussehen und welche Elemente muss es beinhalten? Basis des Referenzmodells ist durchgängig die Serviceorientierung. Alle Komponenten, auch die Event-verarbeitenden, werden als Services dargestellt. Als Standardfa-

274

10. Zusammenfassung milie sind Web-Services und die bestehenden WS-*-Spezifikationen ausreichend, sie werden durchgehend genutzt. Die Fachlichkeit wird komplett mit Hilfe des ContactCenter-Prozessmodells abgebildet. Es bildet den notwendigen Input für die Gestaltung der SOA und der Ereignisverarbeitung. Wichtigstes Element ist die Durchgängigkeit. Dies bezieht sich auf die Abbildung der Fachlichkeit, auf die umsetzende IT-Architektur und die Abstimmung zwischen beiden. SOA wurde hierfür durchgängig auf Contact-Center bezogen. Wesentliche Elemente sind die Service-Typen und die zugeordneten Prozessmodelle. Im Bereich der Ereignisorientierung musste eine technische Architektur geschaffen werden. Als wesentliche Komponenten wurden die Event-Verarbeitung, der Event-Transport und die Event-Reaktion definiert und ihre auf SOA-Standards basierende Interaktion festgelegt. Für den Event-Transport wurde der Notification-Service auf Basis des pub/sub-Kommunikationsparadigmas eingeführt. Er kapselt den Zugriff auf die Implementierung des Event-Transports und ist als Web-Service implementiert. Die Event-Verarbeitung und der Event-Transport bilden die Event-Cloud ab. Als weiterer, wesentlicher Punkt wurde die Event-Darstellung geklärt und allgemeine EventAttribute definiert. Dies zusammen bildet eine allgemeingültige Event-Architektur. Sie stellt eine Möglichkeit dar, um die von [Luckham, 2007] geforderte Event-getriebene Architektur, die SOA und die Ereignisverarbeitung vereint mit bestehenden Mitteln und Standards umzusetzen. Als weitere Contact-Center-spezifische Elemente wurden Klassen von Event-Processing-Agents (EPA) definiert: Zur Geschäftsprozesssteuerung (siehe oben), zur Kennzahlenerstellung, zur Kennzahlendarstellung, zur Event-Historisierung und zur Verbindung mit bestehenden BI-Lösungen. Dabei wurden über vorher festgelegte Gestaltungsregeln eine Trennung nach Anwendungsbereichen und eine Service-basierte Umsetzung erreicht. Aus diesem Grund erfolgt die Kennzahlenerstellung entkoppelt von der Kennzahlendarstellung und den zusätzlich beteiligten Systemen. Nach außen hin werden die EPA als Web-Services umgesetzt, die interne Implementierung und die Event-basierte Untersuchung der Event-Cloud beziehungsweise der -Ströme basiert auf CEP. Für die situationsspezifischen Attribute eines Events (Nutzlast) wurden entsprechend der Anwendungsgebiete drei Event-Typen identifiziert: CTI-Events, ProzessEvents und BAM-Events. Für CTI-Events wurde ein bestehender Standard verwendet, für Prozess- und BAM-Events die notwendigen Parameter erarbeitet. Wesentliches Element des Referenzmodells ist außerdem das integrierte Geschäftsprozessmanagement. Die einzelnen Prozessmodelle bilden die Kundenorientierung von Anfang bis Ende ab und bilden somit ein Raster, mit dem den einzelnen Schritten alle relevanten fachlichen und technischen Informationen (inklusive Events, Anwendungssysteme und Services) beigeordnet werden können. Management, Fachab-


275

teilungen und IT-Abteilung nutzen das Contact-Center-Prozessmodell als Datengrundlage und zum gemeinsamen Verständnis. Die Summe der einzelnen Bestandteile des Referenzmodells decken insgesamt die funktionalen Anforderungen (Zielsetzungen) ab. Damit das Referenzmodell an sich als für die Praxis brauchbar angesehen wird, muss es weiterhin allgemeinen Qualitätskriterien genügen, die für alle Modelle gleichermaßen gelten. Eine genauere Bewertung findet nun noch auf Basis der in Abschnitt 7.2.3 vorgestellten Qualitätskriterien nach [Weiß und Jakob, 2005, S. 24 - 28] statt: • Anwendungsbreite: Das Referenzmodell lässt sich auf einen Großteil aller ContactCenter (nach der hier verwendeten Definition) anwenden. Branchentypische Geschäftsprozesse, sofern sie standardisierbar sind, das heißt mehrfach vorkommen und keine „Einzelanfertigungen“ sind, können mit Hilfe der vorgestellten Architektur automatisiert werden. Spezielle Anwendungsfälle sind im Einzelfall zu klären, das Referenzmodell „erbt“ jedoch durch die Verwendung der Serviceorientierung die grundsätzliche Fähigkeit auch untypische Funktionalitäten und Systeme als Services zu kapseln und einzubinden. Darüber hinaus wird auch ein Lösungskonzept für die Integration manueller Tätigkeiten erarbeitet, das durchaus auch außerhalb von Contact-Centern anwendbar ist. Der allgemeingültige Teil der Event-getriebenen Architektur ist ohne Branchenbeschränkung einsetzbar. Die Verwendung bereits im SOA-Umfeld genutzter Standards verhilft zu einer pragmatischen Umsetzbarkeit einer EDA. Letztendlich ist es lediglich die Definition von ECA-Regeln (Patterns), die das vorgestellte EPN Contact-Center-typisch machen. Grundsätzlich ist ein breiterer Anwendungsfokus durch die entwickelte Aufteilung der EPA-Klassen denkbar, der auch auf andere Branchen anwendbar wäre. Um die Plausibilität der oben getätigten Aussagen vollumfänglich zu prüfen, wären eigene Marktstudien notwendig, die es für dieses Problem jedoch nicht gibt. Eine Annäherung daran ist mit Hilfe einer Bewertung der Anwendungsbreite innerhalb der [Contact-Group, 2007] möglich, deren Prozessgefüge und IT-Landschaft (zumindest in Teilen) mehr oder minder branchentypisch ist. Den Geschäftsprozessen der [Contact-Group, 2007] wurden während der Modellierung unter anderen die Attribute „Häufigkeit pro Jahr“ (Einheit Stück) und „Aufwand“ (Einheit Mitarbeiterjahre) zugeordnet. Eine ABC-Analyse [nach Jung, 2006b, S. 324 ff.] der Attribute brachte folgendes Ergebnis: Elf Geschäftsprozesse bilden insgesamt einen Anteil von 80 % am Gesamtaufkommen. Eine Untersuchung der zugehörigen Modelle zeigt, dass auf diese Modelle das Referenzmodell anwendbar ist. Ein Anteil von 80 % am Gesamtaufwand verteilt sich auf 21 Geschäftsprozesse, auch auf diese ist, bis auf eine Ausnahme (Postausgang), das Referenzmodell anwendbar. Bezogen auf die Aufgaben des integrierten Geschäftsprozessmanagements (Modellierung, Controlling und Automatisierung; siehe Abschnitt 4.2.3) werden auch diese

276

10. Zusammenfassung voll abgedeckt und die umsetzenden Technologien damit „verknüpft“. Auch hier ist die Anwendungsbreite gegeben, der Status quo aus der Praxis wurde abgedeckt.

• Implementierbarkeit: Der Aufwand der Implementierbarkeit kann ohne konkrete Umsetzungsumgebung nicht exakt bestimmt werden, er ist jedoch nicht höher als dies bei anderen SOA-Projekten der Fall wäre. Der Aufwand wird grundsätzlich durch die Geschäftsprozessmodellierung erhöht, allerdings ergeben sich dadurch Einsparungen bei der Bestimmung der Services und ihrer Granularität. Außerdem wird dadurch sichergestellt, dass die Fachlichkeit exakt abgebildet wird. • Wiederverwendbarkeit: Die Wiederverwendbarkeit ist durchgängig gegeben. Fachlich ist dies durch die Gestaltungsvorschriften der Prozessmodelle (vor allem der Teilprozesse) gegeben, technisch stellt die Verwendung der Web-Service-Standards die Wiederverwendbarkeit sicher. • Modularität: Das Referenzmodell ist durchgängig modular aufgebaut. Die interne Kohäsion wurde sowohl bei der Service- als auch bei der EPA-Identifikation berücksichtigt. Die Modularität wird außerdem durch den Einsatz anerkannter Standards und einer lose gekoppelten Architektur unterstützt. • Verständlichkeit: Das Referenzmodell beinhaltet Bestandteile, die in sich bereits einen hohen Komplexitätsgrad besitzen. Anwendern mit entsprechenden Vorkenntnissen (Prozessmodellierer, IT-Architekten) dürfte der jeweilige fachliche beziehungsweise technische Teil trotzdem zugänglich sein. Für die Beschreibung der einzelnen Teilelemente des Referenzmodells wurden bekannte Notationen verwendet (ARIS, UML). Durch die Abstimmung beider Domänen und der Schaffung des ContactCenter-Prozessmodells wird die Verständigung untereinander verbessert (Überbrückung der „semantischen Lücke“ durch einheitliches Prozessverständnis). Aus fachlicher Sicht bringt die Prozessorientierung darüber hinaus einen Koordinationsvorteil (aus der Reduktion der Anzahl von Schnittstellen durch Prozessoptimierung) und einen Motivationsvorteil (Leistungen werden im Prozessteam erbracht) [vgl. Osterloh und Frost, 2006, S. 35]. • Genauigkeit: Die Genauigkeit ist von der Granularität der Anforderungen und Zielsetzungen abhängig. Diese ist für das Referenzmodell zu grob, da es sich nicht auf ein einzelnes Unternehmen und nicht auf konkrete Geschäftsprozesse oder EventKonstellationen bezieht. Allerdings gibt das Referenzmodell genaue Themen vor, die für eine konkrete Umsetzung durch ein Pflichtenheft beschrieben werden müssen. Außerdem wird die wesentliche Gestaltungsrichtung vorgegeben, so dass eine mängelfreie Umsetzung vorbereitet wird. • Vollständigkeit: Das Zielsystem ist insofern vollständig, als dass das Referenzmodell die fachlichen und technischen Elemente beschreibt und aufeinander abstimmt. Die Anforderungen und Herausforderungen, die aus der Literatur, und ergänzt durch ein


277

Praxismodell, ersichtlich waren, wurden abgedeckt. Eine grundsätzliche Vollständigkeit kann jedoch nicht sichergestellt werden. Bezogen auf die Entwicklungszyklen herrscht keine Vollständigkeit. Die notwendigen Phasen eines Umsetzungsprojektes waren nicht Teil der Untersuchung und sind somit nicht beschrieben. • Variabilität: Änderungen und Anpassungen sind sowohl am Modell als auch am Zielsystem möglich. Inhaltlich wird dies durch die durchgängige Anwendung der Architekturprinzipien erreicht, wodurch beispielsweise die inhaltliche Kohärenz der Komponenten eingehalten wird. Technisch bildet die Modularität die notwendigen Voraussetzungen hierfür. Einzelne Komponenten können somit jederzeit geändert, hinzugefügt oder entfernt werden. Die Kommunikation ist durch Events nahezu entkoppelt. • Komplexitätshandhabung: Wegen des fehlenden Bezugs zu konkreten Umsetzungsprojekten wurden Methoden eingeführt, um eine Anwendung in einem komplexen Umfeld (fachlich wie technisch) zu erleichtern. Aus fachlicher Sicht besteht die größte Herausforderung in der „Verschriftlichung“ (Modellierung) der täglich gelebten Prozesse. Hierzu wurden Heuristiken formuliert und Modellierungskonventionen aufgestellt, die dabei helfen sollen, im Gespräch mit Fachanwendern die Prozessmodelle korrekt zu modellieren. Aus technischer Sicht wurden typische Applikationsdomänen identifiziert und abstrakte Klassen für Services, Events und EPA definiert. Wesentliche Inhalte wurden geklärt, so dass eine Anpassung auf konkrete Umgebungen erleichtert wird. • Granularität: Die Granularität ist wesentliches Element des Contact-Center-Prozessmodells. Die Betrachtung wird durchgängig durch Hinterlegungen und Referenzen entlang der Hierarchien und Detaillierungsgrade unterstützt. Je nach Ebene kann zu den zugehörigen technischen Elementen (Modelle, Attribute, Systeme) gewechselt werden. Ausgehend von der fachlichen Granularität bestimmt sich die technische Granularität. • Sicherheit: Sicherheitsrelevante Systemaspekte wurden nicht berücksichtigt. Die Orientierung an bestehenden Web-Service-Standards erlaubt die Anwendung der entsprechenden Standards bezogen auf Sicherheit. Handlungsbedarf besteht hier in Bezug auf die Ereignisorientierung. • Überprüfbarkeit: Die Effektivität ist grundsätzlich durch die Abdeckung der Anforderungen gegeben. Die Effizienz des Referenzmodells, das heißt seine Wirtschaftlichkeit, wurde nicht überprüft. Insgesamt geht es hier jedoch um den „Beweis“ des Modells (siehe Diskussion zu Referenzmodellen). Dieser kann letztendlich erst durch eine Anwendung in der Praxis erfolgen, die sich notwendigerweise an diese Arbeit anschließen sollte. • Laufzeitdynamik: Änderungen in der Komponentenzusammensetzung sollten auf Grund der beschriebenen Zusammenhänge der Variabilität keine Auswirkungen auf

278

10. Zusammenfassung die Laufzeitdynamik haben. Anforderungen bezüglich der Verfügbarkeit und Skalierbarkeit der Ausführungsumgebung werden grundsätzlich durch die umsetzenden Plattformen und Applikationsserver sichergestellt. Die inhaltlichen Abhängigkeiten wurden nicht untersucht und können deshalb nicht zugesichert werden. Mit Bezug auf die Performanz von CEP-Systemen kann erneut auf die Untersuchung von [White et al., 2008] hingewiesen werden. Der Durchsatz an Events eines durchschnittlichen Server-Systems scheint ausreichend, um die hier beschriebenen Funktionalitäten abzudecken.

• Expressivität: Die einzelnen Modelltypen des Contact-Center-Prozessmodells gelten als primäres Raster für Attribute, die zur Software-technischen Realisierung erfasst werden können. Dabei wurden auch technische Objekte und Attribute berücksichtigt, die für die Ausführung wichtig sind (beispielsweise die Generierung eines WSHT-Dokuments inklusive der Steuerungsparameter für den Agenten-Desktop). Dies geschieht allerdings nur soweit, wie fachliche Inhalte betroffen sind. Eine Erweiterung um rein technische Attribute auf sehr feiner Abstraktionsebene ist möglich. Inwiefern dies sinnvoll ist, wurde nicht untersucht. Die modellgetriebene Architektur wird inhaltlich berücksichtigt, sie ist jedoch nicht Teil des Referenzmodells Die Inhalte dieser Arbeit nehmen auf die allgemeine Kritik an der Contact-Center-Branche [vgl. bspw. Wallraff, 2007] keinen Einfluss, sie sind davon unabhängig. Die Kritikpunkte liegen größtenteils im Einsatz unlauterer Methoden (unerlaubtes Anrufen) und in der Gestaltung von Gehalts- und Arbeitszeitmodellen begründet. Trotz der angestrebten Prozessautomatisierung des Referenzmodells wird der Anteil der manuellen Arbeit nicht zwingend reduziert, er wird lediglich optimal integriert. Die Nutzung der vorgestellten Technologien sollen im Zusammenspiel mit der Arbeitsteilung eine Kompetenzen fördernde Arbeitsgestaltung ermöglichen [vgl. Hild, 2003, S. 71]. Obwohl die Zuteilung der Arbeitsaufgaben fremdbestimmt ist („subjektivierte Taylorisierung“ [vgl. bspw. Matuschek et al., 2007]), liegt die eigentliche Kompetenz eines Agenten in der freundlichen und fähigen Lösungsfindung im persönlichen Kontakt zum Kunden. Dies ist verkaufsfördernd und trägt stark zur Kundenbindung und somit zur Kunden- und Mitarbeiterorientierung bei [vgl. Scupin, 2006, Kerst und Holtgrewe, 2003]. Industrialisierung mittels Prozessautomatisierung und Kundenorientierung mittels persönlichen Kundenkontakts schließen sich nicht aus, sie lassen sich kombinieren.

10.3. Grenzen und weitergehende Forschungsfragen Bezogen auf das hier vorliegende Referenzmodell ist eine Anwendung in der Praxis mit anschließender Validierung angezeigt. Es ist sehr wahrscheinlich, dass durch eine praktische Beschäftigung in realen Unternehmen weiterer Klärungsbedarf entsteht, der aus einer rein theoretischen Betrachtungsweise nicht vollständig abzudecken ist. Eventuell noch nicht entdeckte Mängel des Referenzmodells können so behoben werden.

10.3. Grenzen und weitergehende Forschungsfragen

279

Betrachtet man die abgedeckten Themengebiete dieser Arbeit, so kann man feststellen, dass in der Kombination und Integration von SOA, DEBS und CEP sicher der größte Forschungsbedarf liegt. Um dies genauer betrachten zu können, ist eine Unterscheidung in drei Granularitätsebenen sinnvoll: Die Beschäftigung mit Events selbst, die Kombinationen von Events durch Patterns und Queries sowie die Umsetzung der Ereignisorientierung mittels einer Architektur. • Event-Ebene: Im Bereich der Events ist in erster Linie die Frage der Serialisierung und der zugehörigen Spezifikationen und Standardisierungen entsprechender Notationen zu klären. Im Speziellen heißt dies, sind bestehende Standards aus anderen Bereichen, wie etwa aus dem Web-Service-Management [vgl. OASIS, 2006a], geeignet, um Events in einem CEP-Umfeld zu beschreiben oder müssen hier dedizierte Standards entwickelt werden. Vor dem Hintergrund des Austauschs von Events in einem globalisierten und automatisierten Umfeld rückt die Frage der Notwendigkeit einer Event-Semantik mit in den Vordergrund. Eine erste entsprechende Untersuchung (auch zu existierenden und möglichen, zukünftigen Standards) liefert beispielsweise die Arbeit von [Ammon et al., 2009]. • Pattern-Ebene: Für Patterns und Queries gibt es meist nur proprietäre Ansätze zur Serialisierung und Darstellung. Eine mögliche Zielsetzung wäre hier die Ermöglichung des plattformunabhängigen Austauschs von Patterns und Queries zwischen CEP-Systemen (wie dies beispielsweise für Web-Service-Schnittstellen durch WSDL der Fall ist). Neben den technischen Spezifika bleibt außerdem die Frage zu wenig berücksichtigt, inwieweit Event-Patterns identifiziert und modelliert werden können. Ähnlich der Modellierung von Geschäftsprozessen sind hier kreative und regelbasierte Ansätze denkbar. Darüber hinaus sind auch maschinelle Lernverfahren möglich, um Patterns automatisch zu erkennen und umzusetzen. Beispielhaft ist hier die Arbeit von [Widder et al., 2009, 2007] zu erwähnen. • Architektur-Ebene: Die Bildung einer Referenzarchitektur wird beispielsweise durch die EP-TS vorangetrieben. Zusätzlich gibt es Bestrebungen, die NEXOF-Referenzarchitektur für Service-basierte Systeme [vgl. NESSI, 2009, NEXOF, 2009] um Aspekte der Ereignisorientierung zu erweitern [vgl. Ammon et al., 2009]. Da entsprechende Referenzarchitekturen entweder noch nicht veröffentlicht sind oder ihre Bildung noch nicht initiiert ist, bleibt weiterhin vorbehaltlich die Frage, ob entsprechende Architekturen direkt in brauchbare Unternehmensarchitekturen umgesetzt werden können, oder ob hier noch weitere konkretere Architekturmodelle in Zwischenschichten notwendig werden. Die hier vorliegende Arbeit hat obige Fragen in Teilbereichen pragmatisch geklärt, um eine umfängliche Modellbildung zu ermöglichen. Im Wesentlichen erfolgte jedoch eine Konzentration auf die konkreten Zusammenhänge der Modellgestaltung für Contact-Center. In ähnlicher Weise wäre es sinnvoll, dass weitere, ähnliche Modelle für andere Branchen und Anwendungsbereiche entstehen, um so die Entwicklung des EDBPM auch aus

280

10. Zusammenfassung

pragmatisch-konstruktiver Sicht voranzubringen. Erste Ansätze hierzu finden sind unter anderem in [Michlmayr et al., 2008], [Moser et al., 2008] oder [Greiner et al., 2006]. Im Bereich des Geschäftsprozessmanagements wären Untersuchungen zum Reifegrad einzelner Modellierungsmethoden und Notationen hilfreich. Der Standard BPMN ist häufig Gegenstand technisch motivierter Untersuchungen. Die Anwendbarkeit bezogen auf die Prozesslandschaft einer gesamten Unternehmung und eine Integration in die Organisationsforschung bleibt dabei fast gänzlich unberücksichtigt. Gleiches betrifft die Verbindung zwischen den Aspekten der Ereignisorientierung und dem Geschäftsprozessmanagement. Unter anderem ist auch die Frage von Interesse, inwieweit bestehende Reifegradmodelle (wie beispielsweise CMMI [vgl. SMI, 2009]) hier anwendbar sind.

Literatur

281

Literatur Alejandro Abdelnur und Stefan Hepper. Java(TM) Portlet Specification Version 1.0. Java Specification Request, Java Community Process, 7. Oktober 2003. URL http://jcp.org/en/jsr/summary?id=168. Zugriff am 17.06.2009. Ferri Abolhassan. Vom CIO zum Chief Process Officer. In: Bernd Kuhlin und Heinz Thielmann (Hrsg.), Real-Time Enterprise in der Praxis: Fakten und Ausblick, S. 371 – 381. Springer, Berlin und Heidelberg, 2005. Holt Adams. When, and when not to pursue SOA. IBM Developer Works, 2005. URL http://www.ibm.com/developerworks/architecture/roadmap/insight.html. Zugriff am 5.05.2009. Asaf Adi, David Botzer, Gil Nechushtai und Guy Sharon. Complex Event Processing for Financial Services. In: SCW, S. 7 – 12. IEEE Computer Society, 2006. Charu C. Aggarwal (Hrsg.). Data Streams – Models and Algorithms. Springer, New York, 2007. Ashish Agrawal, Mike Amend, Manoj Das, Mark Ford, Chris Keller, Matthias Kloppmann, Dieter König, Frank Leymann, Ralf Müller, Gerhard Pfau, Karsten Plösser, Ravi Rangaswamy, Alan Rickayzen, Michael Rowley, Patrick Schmidt, Ivana Trickovic, Alex Yiu und Matthias Zeller. Web Service Human Task (WS-HumanTask) Version 1.0, Juni 2007a. URL http://www.sdn.sap.com/irj/scn. Zugriff am 16.02.2009. Ashish Agrawal, Mike Amend, Manoj Das, Mark Ford, Chris Keller, Matthias Kloppmann, Dieter König, Frank Leymann, Ralf Müller, Gerhard Pfau, Karsten Plösser, Ravi Rangaswamy, Alan Rickayzen, Michael Rowley, Patrick Schmidt, Ivana Trickovic, Alex Yiu und Matthias Zeller. WS-BPEL Extension for People (BPEL4People) Version 1.0, Juni 2007b. URL http://www.sdn.sap.com/irj/scn. Zugriff am 16.02.2009. Dieter Ahlert, Josef Hesse, John Jullens und Percy Smed (Hrsg.). Multikanalstrategien. Gabler, Wiesbaden, 2003. Frank Ahlrichs und Thilo Knuppertz. Controlling von Geschäftsprozessen – prozessorientierte Unternehmenssteuerung umsetzen. Schäffer-Poeschel, Stuttgart, 2006. Stephan Aier und Marten Schönherr. Flexibilisierung von Organisations- und ITArchitekturen durch EAI. In: Stephan Aier und Marten Schönherr (Hrsg.), Enterprise Application Integration – Flexibilisierung komplexer Unternehmensarchitekturen, S. 1 – 60. GITO, Berlin, 2004. Christopher Alexander, Sara Ishikawa und Murray Silverstein. A Pattern Language. Oxford University Press, New York, 30. Nachdruck (2008), 1977.

D. Jobst, Service- und Ereignisorientierung im Contact-Center, DOI 10.1007/978-3-8349-8989-5, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2010

282

Literatur

Rob Allen. Workflow: An Introduction, 6. März 2001. URL http://wfmc.org/Specifications-Working-Documents/General. Zugriff am 27.01.2009. Thomas Allweyer. Geschäftsprozessmanagement – Strategie, Entwurf, Implementierung, Controlling. W3L, Herdecke und Bochum, 1. korrigierte Auflage, 2005. Thomas Allweyer. BPMN auf gut Deutsch, 16. April http://kurze-prozesse.de/?pageid=78. Zugriff am 16.01.2009.

2008.

URL

Gustavo Alonso, Fabio Casati, Harumi Kuno und Vijay Machiraju. Web Services – Concepts, Architectures and Applications. Springer, Berlin et al., 2004. Paul Alpar, Heinz Lothar Grob, Peter Weimann und Robert Winter. Anwendungsorientierte Wirtschaftsinformatik. Vieweg, Wiesbaden, 4., überarbeitete und verbesserte Auflage, 2005. Amadeus. About Amadeus, 2009. URL http://www.amadeus.com/amadeus/x5034.xml. Zugriff am 06.05.2009. Amazon. AmazonWebService.wsdl, 2009. URL http://soap.amazon.com/schemas2/ AmazonWebServices.wsdl. Zugriff am 10.02.2009. Michael Amberg. Basistechnologien von CRM-Systemen. In: Hajo Hippner und Klaus D. Wilde (Hrsg.), IT-Systeme im CRM, S. 43 – 74. Gabler, Wiesbaden, 2004. Rainer von Ammon, Christoph Emmersberger, Florian Springer und Christian Wolff. Event-Driven Business Process Management and its Practical Application Taking the Example of DHL. In: Darko Anicic, Christian Brelage, Opher Etzion und Nenad Stojanovic (Hrsg.), iCEP08 – 1st International Workshop on Complex Event Processing for the Future Internet, Band 412 der CEUR Workshop Proceedings, Aachen, 2008. CEUR-WS.org. Rainer von Ammon, Christoph Emmersberger, Thomas Ertlmaier, Opher Etzion, Thomas Paulus und Florian Springer. Existing and Future Standards for EventDriven Business Process Management, Eingereichter Beitrag zur DEBS 2009, 3rd ACM International Conference on Distributed Event-Based Systems, July 6 - 9, 2009 Nashville, TN, USA 2009. URL citt-online.com/downloads/DEBS_2009__Existing_and_Future_Standards_for_EDBPM_final.pdf. Zugriff am 26.07.2009. Jean Bacon, David M. Eyers, Jatinder Singh und Peter R. Pietzuch. Access control in publish/subscribe systems. In: Baldoni [2008], S. 23 – 34. Roberto Baldoni (Hrsg.). Proceedings of the Second International Conference on Distributed Event-Based Systems, DEBS 2008, Rome, Italy, July 1-4, 2008, Band 332 der ACM International Conference Proceeding Series, 2008. ACM.

Literatur

283

Tim Bass. Mythbusters: event stream processing versus complex event processing. In: Jacobsen et al. [2007], S. 1. Sean Bechhofer, Frank van Harmelen, Jim Hendler, Ian Horrocks, Deborah L. McGuinness, Peter F. Patel-Schneider und Lynn Andrea Stein. OWL Web Ontology Language Reference. W3C Recommendation, World Wide Web Consortium, 10. Februar 2004. URL http://www.w3.org/TR/owl-ref/. Zugriff am 10.02.2009. Jörg Becker. Referenzmodellierung. Physica-Verlag, Heidelberg, 2004. Jörg Becker und Dieter Kahn. Der Prozess im Fokus. In: Jörg Becker, Martin Kugeler und Michael Rosemann (Hrsg.), Prozessmanagement – Ein Leitfaden zur prozessorientierten Organisationsgestaltung, Kapitel 1, S. 3 – 44. Springer, Berlin und Heidelberg, 5., überarbeitete und erweiterte Auflage, 2005. Jörg Becker und Volker Meise. Strategie und Ordnungsrahmen. In: Jörg Becker, Martin Kugeler und Michael Rosemann (Hrsg.), Prozessmanagement – Ein Leitfaden zur prozessorientierten Organisationsgestaltung, Kapitel 4, S. 105 – 154. Springer, Berlin und Heidelberg, 5., überarbeitete und erweiterte Auflage, 2005. Jörg Becker, Patrick Delfmann und Tobias Rieke. Referenzmodellierung – Perspektiven für die effiziente Gestaltung von Softwaresystemen. In: Jörg Becker, Patrick Delfmann und Tobias Rieke (Hrsg.), Effiziente Softwareentwicklung mit Referenzmodellen, S. 1 – 9. Physica-Verlag, 2007. Berkeley. Information and Service Design, 2008. http://isd.ischool.berkeley.edu/. Zugriff am 21.06.2008.

URL

Elliot Bern. Prioritizing Contact Center Technology Investments. Gartner Research, Nr. G00144935, 12. Feburar 2007. Tim Berners-Lee, James Hendler und Ora Lassila. Mein Computer versteht mich. Spektrum der Wissenschaft, Nr. 8, S. 42 – 49, August 2001. Tim Berners-Lee, R. Fielding und L. Masinter. Uniform Resource Identifier (URI): Generic Syntax. IETF Standard (RFC 3986), The Internet Society, Januar 2005. URL http://tools.ietf.org/html/rfc3986. Zugriff am 26.05.2009. Leonhard Berry. Relationship Marketing. In: Leonard L. Berry, G. Lynn Shostack und Gregory D. Upah (Hrsg.), Emerging Perspectives on Service Marketing. American Marketing Association, Chicago, 1983. Bruno Berstel, Philippe Bonnard, François Bry, Michael Eckert und Paula-Lavinia Patranjan. Reactive Rules on the Web. In: Grigoris Antoniou, Uwe Aßmann, Cristina Baroglio, Stefan Decker, Nicola Henze, Paula-Lavinia Patranjan und Robert Tolksdorf (Hrsg.), Reasoning Web, Band 4636 der Lecture Notes in Computer Science, S. 183 – 239, Berlin et al., 2007. Springer.

284

Literatur

Andreas Beuthner. IT-Abteilungen öffnen sich nur zögerlich dem Prozessdenken. Computerzeitung, Nr. 38, S. 21, 17. September 2007. Jagdish Bhagwati. Trade in Services and the Multilateral Trade Negotiations. In: The World Bank Economic Review, Band 1, S. 49 – 69. 1987. Tilo Böhmann und Helmut Krcmar. Modulare Servicearchitekturen. In: Hans-Jörg Bullinger und August-Wilhelm Scheer (Hrsg.), Service Engineering – Entwicklung und Gestaltung innovativer Dienstleistungen, S. 377 – 401. Springer, Berlin et al., 2. Auflage, 2006. Rolf Bühner. Betriebswirtschaftliche Organisationslehre. Oldenbourg, München und Wien, 10., bearbeitete Auflage, 2004. Pedro Bizarro. BiCEP – Benchmarking Complex Event Processing Systems. In: K. Mani Chandy, Opher Etzion und Rainer v. Ammon (Hrsg.), Event Processing, Band 07191 der Dagstuhl Seminar Proceedings. Internationales Begegnungs- und Forschungszentrum fuer Informatik (IBFI), Schloss Dagstuhl, Germany, 2007. Rolando Blanco, Jun Wang und Paulo Alencar. A metamodel for distributed event based systems. In: Baldoni [2008], S. 221 – 232. Knut Bleicher. Das Konzept Integriertes Management, Band 1 der Reihe St. Galler Management-Konzept. Campus-Verlag, Frankfurt am Main und New York, 7., überarbeitete und erweiterte Auflage, 2004. Jason Bloomberg. When Not to Use an SOA. zapthink, 16. Februar 2004. URL http://www.zapthink.com/report.html?id=ZAPFLASH-02162004. Zugriff am 5.05.2009. Michael-Maria Bommer. Kundeninteraktion intelligent steuern – Chancen erkennen und wahrnehmen. In: Vivento Customer Services (Hrsg.), Die Zukunft des Customer Service – Analysen, Strategien, Konzeptionen, S. 81 – 92. Gabler, Wiesbaden, 2007. Tony Bourke. Simulation im Call Center. In: Eckart Menzler-Trott und Markus Hahnel (Hrsg.), Call Center Evolution – Standards für effiziente Kunden- und Mitarbeiterbeziehungen, S. 287 – 302. Vahlen, München, 2001. Don Box, Luis Felipe Cabrera, Craig Critchley, Francisco Curbera, Donald Ferguson, David Hull, Gopal Kakivaya, Amelia Lewis, Brad Lovering, Peter Niblett, David Orchard, Shivajee Samdarshi, Jeffrey Schlimmer, Igor Sedukhin, John Shewchuk, Sanjiva Weerawarana und David Wortendyke. Web Services Eventing (WS-Eventing). W3C Member Submission, World Wide Web Consortium, 15. März 2006. URL http://www.w3.org/Submission/WS-Eventing. Zugriff am 27.03.2009. Steen Brahe und Kjeld Schmidt. The story of a working workflow management system. In: Tom Gross und Kori Inkpen (Hrsg.), GROUP, S. 249 – 258. ACM, 2007.

Literatur

285

Patrice Briol. BPMN the Business Process Modeling Notation. Lulu, 2008. Elmar Bräkling und Klaus Oidtmann. Kundenorientiertes Prozessmanagement – So funktioniert ein erfolgreiches Unternehmen, Band 12 der FORUM EIPOS. expert verlag, 2006. Manfred Bruhn. Markteinführung von Dienstleistungen – Vom Prototyp zum marktfähigen Produkt. In: Hans-Jörg Bullinger und August-Wilhelm Scheer (Hrsg.), Service Engineering – Entwicklung und Gestaltung innovativer Dienstleistungen, S. 227 – 247. Springer, Berlin et al., 2. Auflage, 2006a. Manfred Bruhn. Relationship Marketing. Vahlen, München, 2001. Manfred Bruhn. Das Konzept der kundenorientierten Unternehmensführung. In: Hans Hinterhuber und Kurt Matzler (Hrsg.), Kundenorientierte Unternehmensführung, Kapitel 2, S. 33 – 66. Gabler, Wiesbaden, 5. Auflage, 2006b. Manfred Bruhn. Marketing, Grundlagen für Studium und Praxis. Gabler, Wiesbaden, 8., überarbeitete Auflage, 2007. François Bry und Michael Eckert. Twelve Theses on Reactive Rules for the Web. In: Torsten Grust, Hagen Höpfner, Arantza Illarramendi, Stefan Jablonski, Marco Mesiti, Sascha Müller, Paula-Lavinia Patranjan, Kai-Uwe Sattler, Myra Spiliopoulou und Jef Wijsen (Hrsg.), EDBT Workshops, Band 4254 der Lecture Notes in Computer Science, S. 842 – 854, Berlin et al., 2006. Springer. François Bry und Michael Eckert. Towards Formal Foundations of Event Queries and Rules. In: Christoph Koch, Johannes Gehrke, Minos N. Garofalakis, Karl Aberer, Anand Deshpande, Daniela Florescu, Chee Yong Chan, Venkatesh Ganti, Carl-Christian Kanne, Wolfgang Klas und Erich J. Neuhold (Hrsg.), VLDB. ACM, 2007. Bodo Böse und Erhard Flieger. Call Center – Mittelpunkt der Kundenkommunikation. Vieweg, Braunschweig und Wiesbaden, 1999. Bodo Böse, Erhard Flieger und Matthias Temme. Call Center-Steuerung. Vieweg, Braunschweig und Wiesbaden, 2001. Hans-Jörg Bullinger und August-Wilhelm Scheer. Service Engineering – Entwicklung und Gestaltung innovativer Dienstleistungen. In: Hans-Jörg Bullinger und AugustWilhelm Scheer (Hrsg.), Service Engineering – Entwicklung und Gestaltung innovativer Dienstleistungen, S. 3 – 18. Springer, Berlin et al., 2. Auflage, 2006. Manfred Bundschuh und Carol Dekkers. The IT Measurement Compendium. Springer, Berlin et al., 2008. Markus Burghardt. Web Services – Aspekte von Sicherheit, Transaktionalität, Abrechnung und Workflow. Zugl. Diss., Univ. Göttingen, 2004. Deutscher Universitäts-Verlag, Wiesbaden, 2004.

286

Literatur

Peter Buxmann, Heiner Diefenbach und Thomas Hess. Die Softwareindustrie. Springer, Berlin und Heidelberg, 2008. Fabio Casati, Malú Castellanos und Ming-Chien Shan. Enterprise Cockpit for Business Operation Management. In: Paolo Atzeni, Wesley W. Chu, Hongjun Lu, Shuigeng Zhou und Tok Wang Ling (Hrsg.), ER, Band 3288 der Lecture Notes in Computer Science, S. 825 – 827, Berlin et al., 2004. Springer. Manuel Castells. The rise of the network society. Blackwell, Malden, 2., neu überarbeitete Auflage, 2008. CCL. Continous Computation Language (CCL). Produkt-Website, Coral8, Inc., 2009. URL http://www.coral8.com/products/ccl.html. Zugriff am 26.03.2009. S. Chakravarthy, V. Krishnaprasad, E. Anwar und S. K. Kim. Composite events for active databases – Semantics, contexts and detection. In: J. B. Bocca, M. Jarke und C. Zaniolo (Hrsg.), 20th International Conference on Very Large Data Bases, S. 606 – 617, San Francisco, 1994. Morgan Kaufmann. Sharma Chakravarthy und Raman Adaikkalavan. Events and streams: harnessing and unleashing their synergy! In: Baldoni [2008], S. 1 – 12. K. Mani Chandy, Michel. Charpentier und Agostino Capponi. Towards a theory of events. In: Jacobsen et al. [2007], S. 180 – 187. K. Mani Chandy, Opher Etzion und Rainer von Ammon. Schloss Dagstuhl – 16.05.10 - 21.05.10, Seminar 10201, Event Processing, 2009. URL http://www.dagstuhl.de/10201. Zugriff am 26.07.2009. David Chappell. Enterprise Service Bus. O’Reilly, Beijing et al., 2006. Erik Christensen, Francisco Curbera, Greg Meredith und Sanjiva Weerawarana. Web Service Description Language (WSDL) 1.1. W3C Note, World Wide Web Consortium, 15. März 2001. URL http://www.w3c.org/TR/wsdl. Zugriff am 10.02.2009. Brad Cleveland, Julia Mayben und Günter Greff. Call Center Management – Leitfaden für Aufbau, Organisation und Fürhung von Teleservicecentern. Gabler, Wiesbaden, 2. Auflage, 2002. Adolf G. Coenenberg, Thomas M. Fischer und Thomas Günther. Kostenrechnung und Kostenanalyse. Schäffer-Poeschel, Stuttgart, 6., überarbeitete und erweiterte Auflage, 2007. Stacy Comes und Lilac Berniker. Business Model Innovation. In: Daniel Pantaleo und Nirmal Pal (Hrsg.), From Strategy to Execution – Turning Accelerated Global Change into Opportunity, S. 65 – 86. Springer, Berlin und Heidelberg, 2008.

Literatur

287

Contact-Group. Erstellung einer Prozesslandkarte und eines ausführlichen Prozessmodells einer Contact-Center-Gruppe im Versandhandel, 1. HJ 2007. Zusammengestellt in Form einer ARIS-Datenbank und weiterer Projektdokumente. David E. Culler, Deborah Estrin und Mani B. Srivastava. Overview of Sensor Networks. IEEE Computer, Band 37, Nr. 8, S. 41 – 49, 2004. Datamonitor. Profiting from IVR in a Rapidly Shifting Marketplace. Datamonitor Strategy Focus, Nr. BFTC1864, Dezember 2007. Chris J. Date. An Introduction to Database Systems. Addison-Wesley, Boston et al., 8. Auflage, 2004. Thomas H. Davenport. Process Innovation – Reengineering Work Through Information Technology. Harvard Business School Press, Boston, 1993. Rob Davis. ARIS Design Platform – Advanced Process Modelling and Administration. Springer, London, 2008. Rob Davis und Eric Brabänder. ARIS Design Platform – Getting Started with BPM. Springer, London, 2007. Bastian de Hesselle, Sebastian Klüpfel und Christian Bauersachs. Der Blick hinter den SOA-Hype. is report, Nr. 11, S. 30 – 33, 2008. Gero Decker, Alexander Grosskopf und Sven Wagner-Boysen. BPMN – Business Process Modeling Notation 1.1, 2008. URL http://bpt.hpi.uni-potsdam.de/pub/Public/BPMNCorner. Zugriff am 15.01.2009. Frank DeRemer und Hans H. Kron. Programming-in-the-Large Versus Programming-inthe-Small. IEEE Transactions on Software Engineering, Band 2, Nr. 2, S. 80 – 86, 1976. Marc Derungs. Workflowsysteme zur Prozessumsetzung. Zugl. Diss., Univ. St. Gallen. Difo-Druck, Bamberg, 1997. Andreas Dietzsch und Thomas Goetz. Nutzen-orientiertes Management einer Serviceorientierten Unternehmensarchitektur. In: Otto Ferstl, Elmar Sinz, Sven Eckert und Tilman Isselhorst (Hrsg.), Wirtschaftsinformatik, S. 1519 – 1528. Physica-Verlag, 2005. Christian Dörner, Volkmar Pipek, Moritz Weber und Volker Wulf. End-user development: new challenges for service oriented architectures. In: WEUSE ’08: Proceedings of the 4th international workshop on End-user software engineering, S. 71 – 75, New York, 2008. ACM. Markus Ebner, Christian Korunka und Dieter Scharitzer. Kundenorientierung im CallCenter, Ein wirtschaftspsychologischer Beitrag. Nummer 8 in Arbeits-, Organisationsund Wirtschaftspsychologie. facultas.wuv, Wien, 2007.

288

Literatur

Michael Eckert. Complex Event Processing with XChangeEQ: Language Design, Formal Semantics, and Incremental Evaluation for Querying Events. Dissertation, LudwigMaximilians-Universität München, 2008. ECMA. XML Protocol for Computer Supported Telecommunications Applications (CSTA) Phase III. ECMA Standard 323, ECMA International, 4. Auflage, Dezember 2006. ECMA. Computer Supported Telecommunications Applications (CSTA). ECMA Standards ECMA-179, 180, 217, 218, 269, 285, 323, 348, 354, 366, ECMA International. URL http://www.ecma-international.org/publications/standards/Stnindex.htm. Zugriff am 26.05.2009. Stehan Ehlers (Hrsg.). Business Prozessmanagement in Praxis und Anwendung. Books on Demand, Norderstedt, 2006. Stefan Eicker, Jessica Kochbeck und Peter M. Schuler. Employee Competencies for Business Process Management. In: Witold Abramowicz und Dieter Fensel (Hrsg.), Business Information Systems, Band 7 der Lecture Notes in Business Information Processing (LNBIP), S. 251 – 262. Springer, Berlin et al., 2008. Horst Ellringmann. Geschäftsprozesse ganzheitlich managen: Leistungsstarke, kundenorientierte Arbeitsabläufe durch Integration von Qualitätssicherung, Umweltschutz und Arbeitssicherheit. Deutscher Wirtschaftsdienst, Köln, 2000. EPTS. Event Processing Technical Society (EPTS). In: David Luckham und Roy Schulte (Hrsg.), Event Processing Glossary – Version 1.1. Juli 2008a. EPTS. Event Processing Technical Society. http://www.ep-ts.com. Zugriff am 20.03.2009.

Website,

2008b.

URL

Thomas Erl. Service-Oriented Architecture – Concepts, Technology, and Design. Prentice Hall, New York et al., 2005. Esper. Esper – Event Stream and Complex Event Processing for Java Reference Documentation Version 3.1.0. , Esper Tech, 2009. URL http://esper.codehaus.org/esper-3.1.0/doc/reference/en/html/. Zugriff am 18.06.2009. Opher Etzion. Semantic approach to event processing. In: Jacobsen et al. [2007], S. 139 – 139. Opher Etzion. Call for active participation in the 5th EPTS event processing symposium – Trento, September 21 - 23, 2009, 18. Juli 2009. URL epthinking.blogspot.com/2009/07/call-for-active-participation-in-5th.html. Zugriff am 26.07.2009. Johannes Feldmayer und Werner Seidenschwarz. Marktorientiertes Prozessmanagement. Vahlen, München, 2005.

Literatur

289

Otto Ferstl und Elmar Sinz. Grundlagen der Wirtschaftsinformatik. Oldenbourg, München, 6., überarbeitete und erweiterte Auflage, 2008. Ludger Fiege, Mariano Cilia, Gero Mühl und Alejandro Buchmann. Publish-Subscribe Grows Up – Support for Management, Visibility Control, and Heterogeneity. IEEE Internet Computing, Band 10, Nr. 1, S. 48 – 55, 2006. Carmen Andrea Fink. Prozessorientierte Unternehmensplanung – Analyse, Konzeption und Praxisbeispiele. Zugl. Diss., Univ. Stuttgart, 2003. Deutscher Universitäts-Verlag, Wiesbaden, 2003. Guido Fischermanns. Praxishandbuch Prozessmanagement, Band 9 der ibo Schriftenreihe. Verlag Dr. Götz Schmidt, Gießen, 6., neubearbeitete Auflage, 2006. Guido Fischermanns und Michael Völpel. Der Reifegrad des Prozessmanagements. Zeitschrift Führung und Organisation (zfo), Band 75, Nr. 5, S. 284 – 290, 2006. Klaus-Peter Franz und Peter Kajüter. Zum Kern des Controlling. In: Jürgen Weber und Bernhard Hirsch (Hrsg.), Controlling als akademische Disziplin, S. 123 – 130. Deutscher Universitäts-Verlag, Wiesbaden, 2002. Jakob Freund. Geschäftsprozesse vs. Workflows, 7. Dezember 2004. http://www.bpm-netzwerk.de/content/articles. Zugriff am 27.01.2009.

URL

Jakob Freund und Klaus Götzer. Vom Geschäftsprozess zum Workflow. Hanser, München, 2008. Andreas Gadatsch. Grundkurs Geschäftsprozess-Management – Methoden und Werkzeuge für die IT-Praxis. Vieweg, Wiesbaden, 5., erweiterte und überarbeitete Auflage, 2008. Michael Gaitanides. Prozeßorganisation – Entwicklung, Ansätze und Programme prozeßorientierter Organisationsgestaltung. Vahlen, München, 1983. Antony Galton und Juan Carlos Augusto. Two Approaches to Event Definition. In: Abdelkader Hameurlain, Rosine Cicchetti und Roland Traunmüller (Hrsg.), DEXA, Band 2453 der Lecture Notes in Computer Science, S. 547 – 556, Berlin et al., 2002. Springer. Benoit A. Gennart und David C. Luckham. Validating descrete event simulations using event pattern mappings. In: Proceedings of the 29th Design Automation Conference (DAC), S. 414 – 419, Anaheim, 1992. IEEE Computer Society Press. Ralf Gitzel, Aleski Aleksy und Martin Schader (Hrsg.). Proceedings of the 4th International Symposium on Principles and Practice of Programming in Java, PPPJ 2006, Mannheim, Germany, August 30 - September 1, 2006, Band 178 der ACM International Conference Proceeding Series, 2006. ACM.

290

Literatur

Ronald Gleich. Prozessorientiertes Performance Measurement. In: Klaus-Peter Franz und Peter Kajüter (Hrsg.), Kostenmanagement – Wertsteigerung durch systematische Kostensteuerung, S. 311 – 325. Schäffer-Poeschel, Stuttgart, 2., überarbeitete und erweiterte Auflage, 2002. Günter Greff und Simone Fojut. Das ABC des Call Center Management. Gabler, Wiesbaden, 2., überarbeitete und erweiterte Auflage, 2003. Torsten Greiner, Willy Düster, Francis Pouatcha, Rainer von Ammon, Hans-Martin Brandl und David Guschakowski. Business activity monitoring of norisbank taking the example of the application easyCredit and the future adoption of Complex Event Processing (CEP). In: Gitzel et al. [2006], S. 237 – 242. Jürgen Gross, Jörg Bordt und Matias Musmacher. Business Process Outsourcing. Gabler, Wiesbaden, 2006. Uwe Götze. ZP-Stichwort: Prozesscontrolling. Zeitschrift für Planung & Unternehmenssteuerung, Band 18, Nr. 3, S. 323 – 332, 2007. Itay Gurvich, Mor Armony und Avishai Mandelbaum. Service-Level Differentiation in Call Centers with Fully Flexible Servers. Management Science, Band 54, Nr. 2, S. 279 – 294, February 2008. Daniel Gyllstrom, Eugene Wu, Hee-Jin Chae, Yanlei Diao, Patrick Stahlberg und Gordon Anderson. SASE: Complex Event Processing over Streams (Demo). In: CIDR, S. 407 – 411. www.crdrdb.org, 2007. Anna-Maria Habel. Kundenorientierung und Industrialisierung. VDM Verlag Dr. Müller, Saarbrücken, 2006. Michael Hammer und James Champy. Business Reengineering – die Radikalkur für das Unternehmen. Campus-Verlag, Frankfurt am Main, 6. Auflage, 1996. Paul Harmon. Business Process Management: Today and Tomorrow. In: Marlon Dumas, Manfred Reichert und Ming-Chien Shan (Hrsg.), BPM, Band 5240 der Lecture Notes in Computer Science, Berlin et al., 2008. Springer. Ludger Heidbrink. Wie die Information uns verwirrt. DIE ZEIT, Nr. 19, 30.04. 2003. Stefan Helber und Raik Stolletz. Call Center Management in der Praxis. Springer, Berlin et al., 2004. Elisabeth Herrell. Hosted Contact Centers – Benefits And Risks. Forrester Research, Nr. 40679, 7. November 2006. Elisabeth Herrell. How To Select A Contact Center Outsourcer. Forrester Research, Nr. 43696, 18. März 2008.

Literatur

291

Elizabeth Herrell. Self-Assessment For Contact Centers. Forrester Research, Nr. 42504, 12. Juni 2007. Elizabeth Herrell, Benjamin Gray, Ellen Daley und Christine E. Atwood. Enterprise IVR/Speech Platform Plans In 2006. Forrester Research, Nr. 39636, 9. Juni 2006. Elizabeth Herrell, Simon Yates und Walid Saleh. Is It Time To Upgrade Your IVR? Forrester Research, Nr. 43234, 7. Januar 2008. Roger Heutschi. Serviceorientierte Architektur – Architekturmodell und Umsetzung in der Praxis. Zugl. Diss., Univ. St. Gallen, 2007. Springer, Berlin et al., 2007. Paul Hild. Call Center in marktund ressourcenbasierter Strategieperspektive. In: Frank Kleemann und Info Matuschek (Hrsg.), Immer Anschluss unter dieser Nummer. Rationalisierte Dienstleistung und subjektivierte Arbeit in Call Centern, S. 65 – 84. edition sigma, Berlin, 2003. Wolf-Christian Hildebrand und Tanja Klostermann. Dienstleistungsverkehr in industriellen Wertschöpfungsprozessen. In: Manfred Bruhn und Bernd Stauss (Hrsg.), Wertschöpfungsprozesse bei Dienstleistungen, S. 215 – 256. Gabler, Wiesbaden, 2007. Wilhelm Hill, Raymond Fehlbaum und Peter Ulrich. Organisationslehre 2 – Theoretische Ansätze und praktische Methoden der Organisation sozialer Systeme. UTB für Wissenschaft. Verlag Paul Haupt, Bern et al., 5., verbesserte Auflage, 1998. Lucy Hipperson. Forecast methodology: IP contact centres. Ovum, 20. November 2007. Hajo Hippner. CRM – Grundlagen, Ziele und Konzepte. In: Hajo Hippner und Klaus D. Wilde (Hrsg.), Grundlagen des CRM, Konzepte und Gestaltung, Kapitel 1. Gabler, Wiesbaden, 2., überarbeitete Auflage, 2006. Hajo Hippner und Klaus D. Wilde. CRM – Ein Überblick. In: S. Helmke, M. Uebl und W. Dangelmaier (Hrsg.), Effektives Customer Relationship Management. Gabler, Wiesbaden, 2002. Pascal Hitzler, Markus Krötzsch, Sebastian Rudolph und York Sure. Semantic Web. Springer, Berlin und Heidelberg, 2007. Gregor Hohpe. Programmieren ohne Stack: ereignis-getriebene Architekturen. OBJEKTspektrum, Nr. 2, S. 18 – 24, Februar 2006. Gregor Hohpe und Bobby Woolf. Enterprise Integration Patterns – Designing, Building, and Deploying Messaging Solutions. Addison-Wesley, Boston et al., 2003. Ta’id Holmes, Martin Vasko und Schahram Dustdar. VieBOP: Extending BPEL Engines with BPEL4People. In: PDP, S. 547 – 555. IEEE Computer Society, 2008.

292

Literatur

Péter Horváth. Der koordinationsorientierte Ansatz. In: Jürgen Weber und Bernhard Hirsch (Hrsg.), Controlling als akademische Disziplin, S. 49 – 66. Deutscher Universitäts-Verlag, Wiesbaden, 2002. Péter Horváth. Controlling. Vahlen, München, 10., vollständig überarbeitete Auflage, 2006. Péter Horváth und Reinhold Mayer. Prozeßkostenrechnung – Konzeption und Entwicklungen. KRP Kostenrechnungspraxis, Band 2, S. 15 – 28, 1993. IBM. Autonomic Computing Toolkit. Developer’s Guide SC30-4083-02, IBM, August 2004. URL http://www.ibm.com/developerworks/library/specification/ws-cbe/. Zugriff am 26.03.2009. IETF. Internet Protocol Darpa Internet Program Protocol Specification. Request for Comment (RFC) 791, The Internet Engineering Task Force, September 1981. URL http://tools.ietf.org/html/rfc791. Zugriff am 21.06.2008. IETF. SIP: Session Initiation Protocol. Request for Comment (RFC) 3261, The Internet Engineering Task Force, Juni 2002. URL http://tools.ietf.org/html/rfc3261. Zugriff am 21.06.2008. ISO9000. Qualitätsmanagementsysteme – Grundlagen und Begriffe. ISO-Standard, International Organization for Standadization, Brüssel, 2000. ITWissen. ITWissen – Das große Online-Lexikon für Informationstechnologie, 2009. URL www.itwissen.info. Zugriff am 08.05.2009. Jacada. Jacada WorkSpace, 2009. URL http://www.jacada.com/products/workspace/. Zugriff am 06.05.2009. Hans-Arno Jacobsen, Gero Mühl und Michael A. Jaeger (Hrsg.). Band 233 der ACM International Conference Proceeding Series, 2007. ACM. Jennifer Jahnke und Georg Rabbe. Praxishandbuch Call Center. ecmc Europäisches Zentrum für Medienkompetenz, Marl, 2001. Daniel Jobst und Gerald Preissler. Mapping clouds of SOA- and business-related events for an enterprise cockpit in a Java-based environment. In: Gitzel et al. [2006], S. 230 – 236. John M. Jordan. Economic Trends of Change. In: Daniel Pantaleo und Nirmal Pal (Hrsg.), From Strategy to Execution – Turning Accelerated Global Change into Opportunity, S. 29 – 45. Springer, Berlin und Heidelberg, 2008. Berndt Jung. Prozessmanagement in der Praxis. TÜV-Verlag, Köln, 2. Auflage, 2006a.

Literatur

293

Hans Jung. Allgemeine Betriebswirtschaftslehre. Oldenbourg, München, 10. Auflage, 2006b. Hans Jung. Controlling. Oldenbourg, München, 2. Auflage, 2007. Su-Dol Kang. Fordismus und Hyundäismus. Lang, Frankfurt am Main, 1994. Gerhard Keller, Markus Nüttgens und August-Wilhelm Scheer. Semantische Prozeßmodellierung auf der Grundlage „Ereignisgesteuerter Prozeßketten (EPK)“. In: AugustWilhelm Scheer (Hrsg.), Veröffentlichungen des Instituts für Wirtschaftsinformatik (IWi), Heft 89. Saarbrücken, 1992. Wolfgang Keller. Enterprise Application Integration – Erfahrungen aus der Praxis. dpunkt-Verlag, Heidelberg, 2002. Hans-Georg Kemper, Walid Mehanna und Carsten Unger. Business Intelligence – Grundlagen und praktische Anwendungen. Vieweg, Wiesbaden, 2. Auflage, 2006. Werner Kern. Industrielle Produktionswirtschaft. Poeschel, Stuttgart, 4., neu bearbeitete Auflage, 1990. Christian Kerst und Ursula Holtgrewe. Interne oder externe Flexibilität? Call Center als kundenorientierte Organisationen. In: Frank Kleemann und Ingo Matuschek (Hrsg.), Immer Anschluss unter dieser Nummer. Rationalisierte Dienstleistung und subjektivierte Arbeit in Call Centern, S. 85 – 108. edition sigma, Berlin, 2003. Andrey Khorlin und K. Mani Chandy. Control-Based Scheduling in a Distributed Stream Processing System. In: Proceedings of the 2006 IEEE Services Computing Workshops (SCW 2006), 18-22 September 2006, Chicago, Illinois, USA, S. 55 – 64. IEEE Computer Society, 2006. Ralph Kimball. The Data Warehouse Toolkit. Wiley, New York et al., 2. Auflage, 2002. Matthias Kloppmann, Dieter Koenig, Frank Leymann, Gerhard Pfau, Alan Rickayzen, Claus von Riegen, Patrick Schmidt und Ivana Trickovic. WS-BPEL Extension for People – BPEL4People, Juli 2005. URL http://www.sdn.sap.com/irj/scn. Zugriff am 16.02.2009. Thilo Knuppertz. Herausforderung Prozesscontrolling. Controller-Magazin, Band 33, S. 7 – 11, Januar/Februar 2008. Dagmar Koch und Thomas Hess. Business Process Redesign als nachhaltiger Trend? Eine empirische Studie zu Aktualität, Inhalten und Gestaltung in deutschen Großunternehmen. Arbeitsbericht 6, Institut für Wirtschaftsinformatik und Neue Medien der Ludwig-Maximilians-Universität München, München, 2003. URL http://www.wim.bwl.uni-muenchen.de. Zugriff am 20.11.2008. Erich Kosiol. Organisation der Unternehmung. Gabler, Wiesbaden, 2., durchgesehene Auflage, 1976.

294

Literatur

Donald Kossmann und Frank Leymann. Web Services. Informatik Spektrum, Band 27, Nr. 2, S. 117 – 128, 2004. Philip Kotler. Grundlagen des Marketing. Pearson Studium, München, 4., aktualisierte Auflage, 2007. Philip Kotler, Gary Armstrong und John Saunders. Grundlagen des Marketing. Pearson, München, 4., aktualisierte Auflage, 2006. Hans-Ulrich Küpper. Controlling – Konzeption, Aufgaben, Instrumente. Schäffer-Poeschel, Stuttgart, 5., überarbeitete Auflage, 2008. Dirk Krafzig, Karl Banke und Dirk Slama. Enterprise SOA – Service Oriented Architecture Best Practices. Prentice Hall International, Upper Saddle River et al., 2005. Herrmann Krallmann, Marten Schönherr, Jens Dietrich und Philipp Offermann. B2BModellierungssprachen und -methodologien im Kontext der Konzeption und Implementierung Service Orientierter Architekturen. In: Peter Loos und Helmut Krcmar (Hrsg.), Architekturen und Prozesse – Strukturen und Dynamik in Forschung und Unternehmen, S. 13 – 32. Springer, Berlin et al., 2007. Drew Kraus und Steve Blood. Magic Quadrant for Contact Center Infrastructure, EMEA, 2007. Gartner Research, Nr. G00151583, 30. Oktober 2007. Drew Kraus und Steve Cramoysan. Key Issues for Contact Center Infrastructure 2008. Gartner Research, Nr. G00156188, 18. März 2008. Andreas Kronz. Managing of Process Key Performance Indicators as Part of the ARIS Methodology. In: August-Wilhelm Scheer, Wolfram Jost, Helge Heß und Andreas Kronz (Hrsg.), Corporate Performance Management – ARIS in Practice, S. 31 – 44. Springer, Berlin et al., 2006. Steffen Krotsch. Industrialisierung in der Abwicklungs- und Transformationsfunktion von Banken. Zugl. Diss., TU Chemnitz, 2005. Deutscher Universitäts-Verlag, Wiesbaden, 2006. Klaus Kruczynski. Business Process Modelling in the context of SOA – An empiric study of the acceptance between EPC and BPMN. In: Proceedings of the 5th International Conference on Information Technology and Applications (ICITA 2008), 2008. Rainer Krumm und Christian Geissler. Outbound-Praxis. Gabler, Wiesbaden, 2., erweiterte Auflage, 2005. Martin Kugeler. Prozessmanagement. In: Peter Mertens (Hrsg.), Lexikon der Wirtschaftsinformatik, S. 386 – 388. Springer, Berlin et al., 4., vollständig neu bearbeitete und erweiterte Auflage, 2001.

Literatur

295

Dhananjay Kulkarni, Chinya V. Ravishankar und Mitch Cherniack. Real-time, loadadaptive processing of continuous queries over data streams. In: Baldoni [2008], S. 277 – 288. Wolfgang Lassmann (Hrsg.). Wirtschaftsinformatik. Gabler, Wiesbaden, 1. Auflage, 2006. Helmut Laux und Felix Liermann. Grundlagen der Organisation. Springer, Berlin et al., 5. Auflage, 2003. Pierre L’Ecuyer. Modeling and Optimization Problems in Contact Centers. In: Proceedings of the Third International Conference on the Quantitative Evaluation of Systems (QEST’06), S. 145 – 156. IEEE Computer Society, September 2006. Frank R. Lehmann. Integrierte Prozessmodellierung mit ARIS. dpunkt-Verlag, Heidelberg, 2008. Franz Lehner und Ralph Lüders. Helpdesk-Systeme und Call-Center-Anwendungen. In: Schriftenreihe des Lehrstuhls für Wirtschaftsinformatik III, Nummer 33. Regensburg, 2002. Franz Lehner, Stephan Wildner und Michael Scholz. Wirtschaftsinformatik. Hanser, München, 2007. Frank Leymann. Web Services – Distributed Applications Without Limits. In: Gerhard Weikum, Harald Schöning und Erhard Rahm (Hrsg.), BTW, Band 26 der Lecture Notes in Informatics, S. 2 – 23, Bonn, 2003. Gesellschaft für Informatik. Frank Leymann, D. Roller und M.-T. Schmidt. Web services and business process management. IBM Systems Journal, Band 41, Nr. 2, 2002. URL http://www.research.ibm.com/journal/sj/412/leymann.html. Zugriff am 04.02.2009. Christoph Loeser, Ralf Trunko, Thilo Steckel, Kevin Podratz, Emanuel Georgiew und Frieder Swoboda. IT-supported integration of semi-autonomous mobile machines and processes into business and service models. In: Gabriele Kotsis, David Taniar, Eric Pardede und Ismail Khalil Ibrahim (Hrsg.), iiWAS, S. 617 – 621. ACM, 2008. Jens-Marten Lohse. Mit Wertstrategie und Business Reengineering zur Marktorientierung. In: Manfred Perlitz, Andreas Offinger und Michael Reinhardt (Hrsg.), Reengineering zwischen Anspruch und Wirklichkeit: ein Managementansatz auf dem Prüfstand, S. 289 – 298. Gabler, Wiesbaden, 1996. David C. Luckham. The Power Of Events – An Introduction to Complex Event Processing in Distributed Enterprise Systems. Addison-Wesley, Boston et al., 2002. David C. Luckham. What’s the Difference Between ESP and CEP? Complexevents.com, 2006. URL http://complexevents.com/?p=103. Zugriff am 2.03.2009.

296

Literatur

David C. Luckham. SOA, EDA, BPM and CEP are all Complementary, 1. Mai 2007. URL http://complexevents.com/wp-content/uploads/2007/05/SOA_EDA_Part_1.pdf. Zugriff am 20.02.2009. David C. Luckham und James Vera. An Event-Based Architecture Definition Language. IEEE Transactions on Software Engineering, Band 21, Nr. 9, S. 717 – 734, September 1995. URL http://complexevents.com/stanford/rapide. Zugriff am 25.03.2009. Matthew MacKenzie, Ken Laskey, Francis McCabe, Peter F. Brown und Rebekah Metz. Reference Model for Service Oriented Architecture 1.0. OASIS Standard, OASIS, 12. Oktober 2006. URL http://docs.oasis-open.org/soa-rm/v1.0. Zugriff am 06.02.2009. Avishai Mandelbaum. Service Engineering Winter 2008: References, 2008. URL http://iew3.technion.ac.il/serveng/References/references.html. Zugriff am 15.06.2008. Andreas Manzey. Gesprächsaufzeichnung im Call Center. In: Eckart Menzler-Trott und Markus Hahnel (Hrsg.), Call Center Evolution. Standards für effiziente Kunden- und Mitarbeiterbeziehungen, S. 135 – 157. Vahlen, München, 2001. Tiziana Margaria und Bernhard Steffen. Service Engineering: Linking Business and IT. Computer, S. 45 – 55, Oktober 2006. Dieter Masak. SOA? – Serviceorientierung in Business und Software. Springer, Berlin und Heidelberg, 2007. Ingo Matuschek, Katrin Arnold und Günter Voß. Subjektivierte Taylorisierung. Organisation und Praxis medienvermittelter Dienstleistungsarbeit. Arbeit und Leben im Umbruch. Rainer Hampp Verlag, München und Mering, 2007. Kurt Matzler, Martin Rier, Birgit Renzl und Hans H. Hinterhuber. Die wichtigsten Managementkonzepte und -methoden: Die Sicht der Unternehmensberater. Zeitschrift für Controlling & Management, 48. Jahrgang, Nr. H.2, S. 82 – 85, 2004. Reinhold Mayer. Das Process Performance Management-Konzept – Realisierungsbeispiele und Nutzenaspekte. In: Organisationsstrukturen und Geschäftsprozesse wirkungsvoll steuern, S. 95 – 115. Schäffer-Poeschel, Stuttgart, 2005. Kevin P. McCormack und William C. Johnson. Business Process Orientation: Gaining the e-business Competitive. CRC Press, Boca Raton, 2001. David W. McCoy. Intelligent Process Monitoring – BPM, BAM and BI Combined. Gartner Research, Nr. G00151756, September 2007. Heribert Meffert, Christoph Burmann und Manfred Kirchgeorg. Marketing – Grundlagen marktorientierter Unternehmensführung. Gabler, Wiesbaden, 10. Auflage, 2008.

Literatur

297

Volker Meise. Ordnungsrahmen zur prozessorientierten Organisationsgestaltung: Modelle für das Management komplexer Reorganisationsprojekte. Kovac, Hamburg, 2001. Ingo Melzer. Service-orientierte Architekturen mit Web Services – Konzepte, Standards, Praxis. Elsevier, München, 2. Auflage, 2007. Eckart Menzler-Trott und Markus Hahnel (Hrsg.). Call Center Evolution – Standards für effiziente Kunden- und Mitarbeiterbeziehungen. Vahlen, München, 2001. Eckhart Menzler-Trott. Call-Center Management: Ein Leitfaden für Unternehmen zum effizienten Kundendialog. C. H. Beck, München, 1999. Peter Mertens. Integrierte Informationsverarbeitung 1 – Operative Systeme in der Industrie. Gabler, Wiesbaden, 16., überarbeitete Auflage, 2007. Peter Mertens. Business Intelligence – ein Überblick. Arbeitspapier der Universität Erlangen-Nürnberg, Arbeitspapier 2/2002, 2002. Oliver Merx und Christian Bachem (Hrsg.). Multichannel-Marketing-Handbuch. Springer, Berlin und Heidelberg, 2001. Marco Mevius, Andreas Oberweis und Wolffried Stucky. Neue Ansätze bei der Modellierung eines kennzahlenbasierten Managements von Geschäftsprozessen. Controlling – Zeitschrift für erfolgsorientierte Unternehmenssteuerung, Band 21, Nr. 4/5, S. 257 – 263, 2009. Anton Meyer, Roland Kantsperger und Marion Schaffer. Die Kundenbeziehung als ein zentraler Unternehmenswert – Kundenorientierung als Werttreiber der Kundenbeziehung. In: Bernd Günter und Sabrina Helm (Hrsg.), Kundenwert – Grundlagen, Innovative Konzepte, Praktische Umsetzungen, S. 61 – 82. Gabler, Wiesbaden, 3., überarbeitete und erweiterte Auflage, 2006. Gero Mühl, Ludger Fiege und Peter Pietzuch. Distributed Event-Based Systems. Springer, Berlin et al., 2006. Anton Michlmayr, Florian Rosenberg, Philipp Leitner und Schahram Dustdar. Advanced event processing and notifications in service runtime environments. In: Baldoni [2008], S. 115 – 125. Microsoft. Customer Care Framework (CCF Home), 2009a. http://www.microsoft.com/serviceproviders/ccf. Zugriff am 06.05.2009.

URL

Microsoft. Telephony Application Programming Interfaces (TAPI, TSPI, MSPI), 2009b. URL http://msdn.microsoft.com/de-de/library/ms950407.aspx. Zugriff am 26.05.2009. Microsoft. COM: Component Object Model Technologies, http://www.microsoft.com/com. Zugriff am 26.02.2009.

2009c.

URL

298

Literatur

Microsoft. .NET Framework im Überblick, 2009d. http://msdn.microsoft.com/de-de/netframework/default.aspx. 04.06.2009.

URL Zugriff am

Joaching Müller. Workflow-based Integration. Springer, Berlin et al., 2005. Klaus Möller und Ingo Cassack. Prozessorientierte Planung und Kalkulation (kern-)produktbegleitender Dienstleistungen. Zeitschrift für Planung & Unternehmenssteuerung, Band 19, Nr. 2, S. 159 – 184, 2008. Christof Momm, Robert Malec und Sebastian Abeck. Towards a Model-driven Development of Monitored Processes. In: Andreas Oberweis, Christof Weinhardt, Henner Gimpel, Agnes Koschmider, Victor Pankratius und Björn Schnizler (Hrsg.), eOrganisation: Service-, Prozess-, Market-Engineering, Band 2, S. 319 – 336. Universitätsverlag Karlsruhe, Karlsruhe, 2007. Oliver Moser, Florian Rosenberg und Schahram Dustdar. Non-intrusive monitoring and service adaptation for WS-BPEL. In: Jinpeng Huai, Robin Chen, Hsiao-Wuen Hon, Yunhao Liu, Wei-Ying Ma, Andrew Tomkins und Xiaodong Zhang (Hrsg.), WWW, S. 815 – 824. ACM, 2008. NESSI. Networked European Software & Services Initiative, 2009. http://www.nessi-europe.eu. Zugriff am 23.07.3009.

URL

NEXOF. NEXOF-RA (NEXOF Reference Architecture), http://www.nexof-ra.eu. Zugriff am 23.07.2009.

URL

2009.

Fritz Nordsieck. Betriebsorganisation – Lehre und Technik. Poeschel, Stuttgart, 2., bearbeitete Auflage, 1972. Fritz Nordsieck. Grundlagen der Organisationslehre. Poeschel, Stuttgart, 1934. Klaus North und Kai Reinhardt. Kompetenzmanagement in der Praxis. Gabler, Wiesbaden, 2005. OASIS. Web Services Distributed Management: Management Using Web Services (MUWS 1.1) Part 1. OASIS Standard, Organization for the Advancement of Structured Information Standards (OASIS), 1. August 2006a. URL http://docs.oasis-open.org/wsdm. Zugriff am 23.03.2009. OASIS. Web Services Distributed Management: Management Using Web Services (MUWS 1.1) Part 2. OASIS Standard, Organization for the Advancement of Structured Information Standards (OASIS), 1. August 2006b. URL http://docs.oasis-open.org/wsdm. Zugriff am 10.06.2009. OASIS. Web Services Base Notification 1.3 (WS-BaseNotification). OASIS Standard, Organization for the Advancement of Structured Information Standards (OASIS), 1. Oktober 2006c. URL http://docs.oasis-open.org/wsn. Zugriff am 27.03.2009.

Literatur

299

OASIS. Web Services Brokered Notification 1.3 (WS-BrokeredNotification). OASIS Standard, Organization for the Advancement of Structured Information Standards (OASIS), 1. Oktober 2006d. URL http://docs.oasis-open.org/wsn. Zugriff am 27.03.2009. OASIS. Web Services Topics 1.3 (WS-Topics). OASIS Standard, Organization for the Advancement of Structured Information Standards (OASIS), 1. Oktober 2006e. URL http://docs.oasis-open.org/wsn. Zugriff am 27.03.2009. OASIS. Web Services Business Process Execution Language Version 2.0. OASIS Standard, Organization for the Advancement of Structured Information Standards (OASIS), 11. April 2007a. URL http://docs.oasis-open.org/wsbpel/2.0. Zugriff am 13.02.2009. OASIS. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS Standard, Organization for the Advancement of Structured Information Standards (OASIS), 15. März 2005. URL http://docs.oasis-open.org/security/saml/v2.0. Zugriff am 11.02.2009. OASIS. UDDI Version 3.0.2. Technical Committee Draft, Organization for the Advancement of Structured Information Standards (OASIS), 19. Oktober 2004. URL http://uddi.org/pubs/uddi_v3.htm. Zugriff am 11.02.2009. OASIS. Web Services Atomic Transaction (WS-AtomicTransaction) Version 1.1. OASIS Standard, Organization for the Advancement of Structured Information Standards (OASIS), 12. Juli 2007b. URL http://docs.oasis-open.org/ws-tx/wstx-wsat-1.1-spec.pdf. Zugriff am 11.02.2009. OASIS. Web Services Business Activity (WS-BusinessActivity) Version 1.1. OASIS Standard, Organization for the Advancement of Structured Information Standards (OASIS), 12. Juli 2007c. URL http://docs.oasis-open.org/ws-tx/wstx-wsba-1.1-spec.pdf. Zugriff am 11.02.2009. OASIS. Web Services Coordination (WS-Coordination) Version 1.1. OASIS Standard, Organization for the Advancement of Structured Information Standards (OASIS), 12. Juli 2007d. URL http://docs.oasis-open.org/ws-tx/wstx-wscoor-1.1-spec.pdf. Zugriff am 11.02.2009. OASIS. Web Services Security: SOAP Message Security 1.1 (WS-Security 2004). OASIS Standard, Organization for the Advancement of Structured Information Standards (OASIS), 1. Februar 2006f. URL http://docs.oasis-open.org/wss/v1.1/. Zugriff am 11.02.2009. OASIS. WS-Trust 1.3. OASIS Standard, Organization for the Advancement of Structured Information Standards (OASIS), 19. März 2007e. URL http://docs.oasis-open.org/ws-sx/ws-trust/v1.3/ws-trust.pdf. Zugriff am 11.02.2009.

300

Literatur

David Ogle, Heather Kreger, Abdi Salahshour, Jason Cornpropst, Eric Labadie, Mandy Chessell, Bill Horn, John Gerken, James Schoech und Mike Wamboldt. Canonical Situation Data Format: The Common Base Event V1.0.1. , IBM, 2004. URL http://www.eclipse.org/tptp/platform/documents/resources/cbe101spec. Zugriff am 26.03.2009. OMG. Business Process Modeling Notation, V1.1. OMG Available Specification formal/2008-01-17, Object Management Group, Januar 2008a. URL http://www.omg.org/spec/BPMN/1.1/PDF. Zugriff am 16.01.2009. OMG. Common Object Request Broker Architecture (CORBA) Specification, Version 3.1. OMG Available Specification, Object Management Group, Januar 2008b. URL http://www.omg.org/spec/CORBA/3.1. Zugriff am 6.02.2009. Erich Ortner. SOA-Systeme sind oft ohne wissenschaftlichen Ansatz. Computerzeitung, Nr. 27, S. 6, 30. Juni 2008. OrViA. OrViA Kurzbeschreibung, 2009. 06.02.2009.

URL http://www.orvia.de/.

Zugriff am

Margit Osterloh und Jetta Frost. Prozessmanagement als Kernkompetenz – Wie Sie Business Reengineering strategisch nutzen können. Gabler, Wiesbaden, 5. Auflage, 2006. Sven Overhage und Klaus Turowski. Serviceorientierte Architekturen – Konzept und methodische Herausforderungen. In: Service-orientierte Architekturen, S. 3 – 17. Deutscher Universitäts-Verlag, Wiesbaden, 2007. Daniel Pantaleo und Nirmal Pal. Global Imperatives – The Accelerating Pace of Change. In: Daniel Pantaleo und Nirmal Pal (Hrsg.), From Strategy to Execution – Turning Accelerated Global Change into Opportunity, S. 3 – 28. Springer, Berlin und Heidelberg, 2008. Adrian Paschke, Alexander Kozlenkov und Harold Boley. A Homogeneous Reaction Rule Language for Complex Event Processing. In: International Workshop on Event Drive Architecture for Complex Event Processing (EDA-PS 2007), Vienna, Austria, 2007. Oscar Pastor und Juan Carlos Molina. Model-Driven Architecture in Practice – A Software Production Environment Based on Conceptual Modeling. Springer, Berlin et al., 2007. Gene Phifer, David Gootzit, Daniel Sholler, Ray Valdes, Anthony Bradley, Nikos Drakos, Roy W. Schulte, Yefim V. Natis, David Mitchell Smith, Charles Abrams, Stephen Prentice, Waldir Arevolo, De Azevedo Filho, David W. Cearley, Rita W. Know, Nick Jones, Nicholas Gall, Benoit J. Lheureux und L. Frank Kenney. Hype Cycle for Web and User Interaction Technologies, 2007. Gartner Research, Nr. G00148212, 13. Juli 2007. Arnold Picot, Ralf Reichwald und Rolf T. Wigand. Die grenzenlose Unternehmung. Gabler, Wiesbaden, 4., vollst. überarb. und erw. Auflage, 2001.

Literatur

301

Michael E. Porter. Wettbewerbsvorteile – Spitzenleistungen erreichen und behaupten. Campus-Verlag, Frankfurt am Main et al., 6. Auflage, 2000. Thomas Reichmann. Controlling mit Kennzahlen und Management-Tools – die systemgestützte Controlling-Konzeption. Vahlen, München, 7., überarbeitete und erweiterte Auflage, 2006. Andreas Remer und Philip Hucke. Grundlagen der Organisation. Kohlhammer, Stuttgart, 2007. Cornelius Riese. Industrialisierung von Banken – Grundlagen, Ausprägungen, Wirkungen. Zugl. Diss., TU Chemnitz, 2005. Deutscher Universitäts-Verlag, Wiesbaden, 2006. Michael Rosemann, Ansgar Schwegmann und Patrick Delfmann. Vorbereitung der Prozessmodellierung. In: Jörg Becker, Martin Kugeler und Michael Rosemann (Hrsg.), Prozessmanagement – Ein Leitfaden zur prozessorientierten Organisationsgestaltung, Kapitel 3, S. 45 – 103. Springer, Berlin und Heidelberg, 5., überarbeitete und erweiterte Auflage, 2005. Allan Rosenberg. Best Practices in Workforce Management, 5. Oktober 2005. URL http://www.callcentermagazine.com/showArticle.jhtml?articleID=160503291. Zugriff am 10.07.2008. Jürgen Rothlauf. Total Quality Management in Theorie und Praxis. Oldenbourg, München, 2. Auflage, 2004. Szabolcs Rozsnyai, Josef Schiefer und Alexander Schatten. Concepts and models for typing events for event-based systems. In: Jacobsen et al. [2007], S. 62 – 70. Alfred Rudolph und Miriam Rudolph. Customer-Relationship-Marketing. Cornelsen, Berlin, 2000. William R. Ruh, Francis X. Maginnis und William J. Brown. Enterprise Application Integration. Wiley, New York, 2001. RuleML. Rule Markup Language, 2009. URL www.ruleml.org. Zugriff am 26.03.2009. Nick Russell und Wil M. P. van der Aalst. Work Distribution and Resource Management in BPEL4People: Capabilities and Opportunities. In: Zohra Bellahsene und Michel Léonard (Hrsg.), CAiSE, Band 5074 der Lecture Notes in Computer Science, S. 94 – 108, Berlin et al., 2008. Springer. Shazia Sadiq, Guido Governatori und Kioumars Namiri. Modeling Control Objectives for Business Process Compliance. In: Gustavo Alonso, Peter Dadam und Michael Rosemann (Hrsg.), Business Process Management, Band 4714 der Lecture Notes in Computer Science, S. 149 – 164, Berlin et al., 2007. Springer.

302 SAP. Enterprise Services Design Guide. 2005. www.sap.com/platform/netweaver/pdf/BWP_ES_Design_Guide.pdf. 5.05.2009.

Literatur URL Zugriff am

August-Wilhelm Scheer. Architektur integrierter Informationssysteme. Springer, Berlin et al., 1991. August-Wilhelm Scheer. ARIS – Modellierungsmethoden, Metamodelle, Anwendungen. Springer, Berlin et al., 4. Auflage, 2001. August-Wilhelm Scheer. ARIS-House of Business Engineering – Von der Geschäftsprozessmodellierung zur Workflow-gesteuerten Anwendung; vom Business Process Reengineering zum Continous Process Improvement. Heft 133, IWi Institut für Wirtschaftsinformatik, Saarbrücken, September 1996. August-Wilhelm Scheer. Wirtschaftsinformatik – Referenzmodelle für industrielle Geschäftsprozesse. Springer, Berlin et al., 7., durchgesehene Auflage, 1997. August-Wilhelm Scheer. ARIS – vom Geschäftsprozess zum Anwendungssystem. Springer, Berlin et al., 4., durchgesehene Auflage, 2002. August-Wilhelm Scheer. EDV-orientierte Betriebswirtschaftslehre – Grundlagen für ein effizientes Informationsmanagement. Springer, Berlin et al., 4., völlig neu bearb. Auflage, 1990. August-Wilhelm Scheer und Volker Zimmermann. Geschäftsprozeßmanagement und integrierte Informationssysteme: Prozeßmodellierung, Referenzmodelle und Softwaretechnologien. In: Armin Töpfer (Hrsg.), Geschäftsprozesse: analysiert & optimiert, S. 267 – 286. Luchterhand, Neuwied, 1996. August-Wilhelm Scheer, Otmar Adam und Fabian Erbach. Next Generation Business Process Management. In: Wolfram Jost und Karl Wagner (Hrsg.), Von Prozessmodellen zu lauffähigen Anwendungen – ARIS in der Praxis, S. 1 – 16. Springer, Berlin et al., 2005. August-Wilhelm Scheer, Oliver Grieble und Ralf Klein. Modellbasiertes Dienstleistungsmanagement. In: Hans-Jörg Bullinger und August-Wilhelm Scheer (Hrsg.), Service Engineering – Entwicklung und Gestaltung innovativer Dienstleistungen, S. 19 – 52. Springer, Berlin et al., 2. Auflage, 2006a. August-Wilhelm Scheer, Helmut Kruppke, Wolfram Jost und Herbert Kindermann (Hrsg.). AGILITÄT durch ARIS Geschäftsprozessmanagement. Jahrbuch Business Process Excellence 2006/2007. Springer, Berlin et al., 2006b. Andreas Schelske. Soziologie vernetzter Medien – Grundlagen computervermittelter Vergesellschaftung. Lehrbuchreihe Interaktive Medien. Oldenbourg, München et al., 2007.

Literatur

303

Josef Schiefer, Szabolcs Rozsnyai, Christian Rauscher und Gerd Saurer. Event-driven rules for sensing and responding to business situations. In: Jacobsen et al. [2007], S. 198 – 205. Marc Schietinger und Jochen Schroth. Auswertung der Beschäftigtenstruktur in Call Centern. Forschungsprojekt FREQUENZ Personalmanagement – Call Center und Handel, Arbeitspapier 2001-02 2001. URL http://www.bunds-bonn.de/pool/bstruktur/bstruktur.pdf. Zugriff am 23.07.2008. Florian Schümann und Horst Tisson. Call Center Controlling, Ein Modell für die Planung, Kontrolle und Steuerung von Kundenservice-Centern. Gabler, Wiesbaden, 1. Auflage, 2006. Hermann J. Schmelzer. Wer sind die Akteuere im Geschäftsprozessmanagement? Zeitschrift Führung und Organisation (zfo), Band 74, Nr. 5, S. 273 – 277, 2005. Hermann J. Schmelzer und Wolfgang Sesselmann. Geschäftsprozessmanagement in der Praxis. Hanser, München, 6., vollständig überarbeitete und erweiterte Auflage, 2008. Maxie Schmidt. Zufriedenheitsorientierte Steuerung des Customer Care. Zugl. Diss., Kath. Univ. Eichstätt-Ingolstadt, 2007. Deutscher Universitäts-Verlag, Wiesbaden, 2007. Martin Schönheit, Udo Lackner und Michael Jüch. Prozeßkennzahlen zur branchenunabhängigen Prozeßbewertung. In: Prozesskennzahlen – der Weg zum Erfolg, 1. Symposium Wirtschaftlicher Erfolg durch Prozessorganisation, S. 23 – 49, Düsseldorf, 1997. VDIGesellschaft, VDI Verlag. Peter Schreiner. Herausforderung Wissen und Prozesse managen. In: Hans-Jörg Bullinger (Hrsg.), Knowledge meets Process, Wissen und Prozesse managen im Intranet, Kapitel 1, S. 11 – 18. Fraunhofer-Institut für Arbeitswirtschaft und Organisation IAO, Stuttgart, 2001. Matthias Schubert. Datenbanken – Theorie, Entwurf und Programmierung relationaler Datenbanken. Teubner, Wiesbaden, 2., überarbeitete Auflage, 2007. Roy W. Schulte. Getting Business Value From Event Processing. Gartner Research, Nr. G00155981, 2. Mai 2008. Roy W. Schulte, Daniel Sholler und Anthony Bradley. Key Issues for SOA, EDA and WOA, 2008. Gartner Research, Nr. G00158197, 21. Juli 2008. Ansgar Schwegmann und Micahel Laske. Istmodellierung und Istanalyse. In: Jörg Becker, Martin Kugeler und Michael Rosemann (Hrsg.), Prozessmanagement – Ein Leitfaden zur prozessorientierten Organisationsgestaltung, Kapitel 5, S. 155 – 184. Springer, Berlin und Heidelberg, 5., überarbeitete und erweiterte Auflage, 2005.

304

Literatur

Burkhard Schwenker. Auf Veränderungen des Marktes reagieren – den Produktlebenszyklus umfassend managen. In: Michael Höck und Kai-Ingo Voigt (Hrsg.), Operations Management in Theorie und Praxis – Aktuelle Entwicklungen des Industriellen Managements, S. 121 – 138. Gabler, Wiesbaden, 2008. Wolfgang Schwetz. Customer Relationship Management. Gabler, Wiesbaden, 2. Auflage, 2001. Yvonne Scupin. Call-Center-Management und Mitarbeiterzufriedenheit – eine kausalanalytische Untersuchung. Zugl. Diss., Univ. Hamburg, 2005. Deutscher UniversitätsVerlag, Wiesbaden, 2006. Heinrich Seidlmeier. Prozessmodellierung mit ARIS. Vieweg, Wiesbaden, 2., aktualisierte Auflage, 2006. Duane E. Sharp. Call Center Operation. Digital Press, Burlington, 2003. Henry Sinnreich und Alan B. Johnston. Internet Communications Using SIP: Delivering VoIP and Multimedia Services with Session Initiation Protocol. Wiley, Indianapolis, 2. Auflage, 2006. SMI. What is CMMI?, Software Engineering Institut (SMI), Carnegie-Mellon-University, Pittsburgh, 2009. URL http://www.sei.cmu.edu/cmmi/general/index.html. Zugriff am 26.07.2009. Howard Smith und Peter Fingar. Meghan Kiffer, Tampa, 2006.

Business Process Management: The Third Wave.

Herbert Stachowiak. Allgemeine Modelltheorie. Springer, Wien et al., 1973. Josef Staud. Geschäftsprozessanalyse – Ereignisgesteuerte Prozessketten und objektorientierte Geschäftsprozessmodellierung für Betriebswirtschaftliche Sandardsoftware. Springer, Berlin und Heidelberg, 3. Auflage, 2006. Bernd Stauss. Plattformstrategien im Service Engineering. In: Hans-Jörg Bullinger und August-Wilhelm Scheer (Hrsg.), Service Engineering – Entwicklung und Gestaltung innovativer Dienstleistungen, S. 321 – 340. Springer, Berlin et al., 2. Auflage, 2006. Hubert Österle. Business Engineering – Prozeß- und Systementwicklung, Band 1 Entwurfstechniken. Springer, Berlin et al., 2., verbesserte Auflage, 1995. Dirk Stähler. Standardisierung als Erfolgsvoraussetzung im Geschäftsprozessmanagement. Zeitschrift Führung und Organisation (zfo), Band 75, Nr. 5, S. 291 – 297, 2006. Lisa Stockberger. Überblick über Computer Telephony Integration im Call Center. In: Eckart Menzler-Trott und Markus Hahnel (Hrsg.), Call Center Evolution. Standards für effiziente Kunden- und Mitarbeiterbeziehungen, S. 303 – 319. Vahlen, München, 2001.

Literatur

305

Sun-Microsystems. Java EE at a Glance, 2009. URL http://java.sun.com/javaee/. Zugriff am 04.06.2009. Serkan Tavasli. Six Sigma Performance Measurement System. Zugl. Diss., TU Berlin, 2007. Deutscher Universitäts-Verlag, Wiesbaden, 2007. Frederick Winslow Taylor. Scientific Management. Greenwood, Westpoint, 1972. Kurt H. Thieme und Wolfgang Steffen. Call Center – Der professionelle Dialog mit dem Kunden. Verlag Moderne Industrie, Landsberg am Lech, 2. Auflage, 2000. Oliver Thomas. Management von Referenzmodellen, Band 1 der Wirtschaftsinformatik – Theorie und Anwendung. Logos, Berlin, 2006. Elke Timm und Rainer Wieland. Arbeitspsychologie im Call Center: Aktuelle Trends der Call-Center-Arbeitsgestaltung. In: Frank Kleemann und Ingo Matuschek (Hrsg.), Immer Anschluss unter dieser Nummer. Rationalisierte Dienstleistung und subjektivierte Arbeit in Call Centern, S. 223 – 240. edition sigma, Berlin, 2003. Ulrich Trick und Frank Weber. SIP, TCP/IP und Telekommunikationsnetzwerke. Oldenbourg, München, 3. Auflage, 2007. Gerhard Unger. Prozesskennzahlen zur Unternehmenssteuerung in der praktischen Anwendung. Controller-Magazin, Band 34, Nr. 1, S. 20 – 25, 2009. Wil van der Aalst, Alexander Dreiling, Florian Gottschalk, Michael Rosemann und Monique H. Jansen-Vullers. Configurable Process Models as a Basis for Reference Modeling. In: Christoph Bussler und Armin Haller (Hrsg.), Business Process Management Workshops, Band 3812 der Lecture Notes Computer Science, S. 512 – 518, Berlin et al., 2005. Springer. Wil M. P. van der Aalst, A. H. M. ter Hofstede und Mathias Weske. Business Process Management: A Survey. In: Wil van der Aalst, Arthur ter Hofstede und Mathias Weske (Hrsg.), Business Process Management, Band 2678 der Lecture Notes in Computer Science, S. 1 – 12, Berlin et al., 2003. Springer. Petra Vogler. Prozess- und Systemintegration – Evolutionäre Weiterentwicklung bestehender Informationssysteme mit Hilfe von Enterprise Application Integration. Zugl. Habil., Univ. St. Gallen, 2004. Deutscher Universitäts-Verlag, Wiesbaden, 1. Auflage, 2006. Ken Vollmer und Mike Gilpin. The Forrester Wave(TM): Enterprise Service Bus, Q2 2006. Forrester Research, Nr. 38696, 30. Juni 2006. Jan vom Brocke. Serviceorientierte Architekturen – SOA – Management und Controlling von Geschäftsprozessen. Vahlen, München, 2008. Gottfried Vossen. Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme. Oldenbourg, München, 5. überarbeitete und erweiterte Auflage, 2008.

306

Literatur

Gottfried Vossen und Stephan Hagemann. Unleashing Web 2.0 – From Concepts to Creativity. Morgan Kaufmann, Burlington, 2007. W3C. XML Events – An Events Syntax for XML. W3C Recommendation, World Wide Web Consortium, 14. Oktober 2003. URL http://www.w3c.org/TR/xml-events. Zugriff am 26.03.2009. W3C. Namespaces in XML 1.0 (Second Edition). W3C Recommendation, World Wide Web Consortium, 16. August 2006a. URL http://www.w3.org/TR/owl-ref/. Zugriff am 26.05.2009. W3C. Resource Description Framework (RDF). RDF Core Working Group Summary, World Wide Web Consortium, 2004a. URL http://www.w3c.org/RDF. Zugriff am 10.02.2009. W3C. RDF Vocabulary Description Language 1.0: RDF Schema. W3C Recommendation, World Wide Web Consortium, 10. Februar 2004b. URL http://www.w3.org/TR/rdf-schema/. Zugriff am 10.02.2009. W3C. SOAP Version 1.2 Part 1: Messaging Framework (Second Edition). W3C Recommendation, World Wide Web Consortium, 27. April 2007a. URL http://www.w3.org/TR/soap12-part1/. Zugriff am 11.02.2009. W3C. SOAP Version 1.2 Part 2: Adjuncts (Second Edition). W3C Recommendation, World Wide Web Consortium, 27. April 2007b. URL http://www.w3.org/TR/soap12-part2/. Zugriff am 11.02.2009. W3C. Web Services Architecture. W3C Working Group Note, World Wide Web Consortium, 11. Februar 2004c. URL http://www.w3.org/TR/ws-arch/. Zugriff am 10.02.2009. W3C. Web Services Addressing 1.0 – Core. W3C Recommendation, World Wide Web Consortium, 9. Mai 2006b. URL http://www.w3.org/TR/ws-addr-core. Zugriff am 18.02.2009. W3C. Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. W3C Recommendation, World Wide Web Consortium, 26. Juni 2007c. URL http://www.w3.org/TR/wsdl20. Zugriff am 10.02.2009. W3C. Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts. W3C Recommendation, World Wide Web Consortium, 26. Juni 2007d. URL http://www.w3.org/TR/wsdl20-adjuncts. Zugriff am 11.02.2009. W3C. Web Services Policy 1.5 – Framework. W3C Recommendation, World Wide Web Consortium, 4. September 2007e. URL http://www.w3.org/TR/ws-policy. Zugriff am 12.02.2009.

Literatur

307

W3C. XML Path Language (XPath) 2.0. W3C Recommendation, World Wide Web Consortium, 23. Januar 2007f. URL http://www.w3.org/TR/xpath20/. Zugriff am 10.06.2009. W3C. Voice Extensible Markup Language (VoiceXML) Version 2.0. W3C Recommendation, W3C, 16. März 2004d. URL http://www.w3.org/TR/voicexml20/. Zugriff am 22.06.2009. Günter Wallraff. Günter Wallraff ist zurück. DIE ZEIT, Nr. 22, 24.05. 2007. Segev Wasserkrug, Avigdor Gal und Opher Etzion. A Taxonomy and Representation of Sources of Uncertainty in Active Systems. In: Opher Etzion, Tsvi Kuflik und Amihai Motro (Hrsg.), NGITS, Band 4032 der Lecture Notes in Computer Science, S. 174 – 185, Berlin et al., 2006. Springer. Jürgen Weber und Bernhard Hirsch (Hrsg.). Controlling als akademische Disziplin – Eine Bestandsaufnahme. Deutscher Universitäts-Verlag, Wiesbaden, 2002. Gerhard Weiß und Ralf Jakob. Agentenorientierte Softwareentwicklung. Springer, Berlin et al., 2005. Gerhard Weikum und Gottfried Vossen. Transactional Information Systems. Morgan Kaufmann Publishers, San Francisco, 2002. Gernot Wersig. Fokus Mensch. Lang, Frankfurt am Main, 1993. Mathias Weske. Business Process Management – Concepts, Languages, Architectures. Springer, Berlin et al., 2007. Branimir Wetzstein, Zhilei Ma und Frank Leymann. Towards Measuring Key Performance Indicators of Semantic Business Processes. In: Witold Abramowicz und Dieter Fensel (Hrsg.), Business Information Systems, Band 7 der Lecture Notes in Business Information Processing (LNBIP), S. 227 – 238. Springer, Berlin et al., 2008. Seth White, Alexandre Alves und David Rorke. WebLogic event server: a lightweight, modular application server for event processing. In: Baldoni [2008], S. 193 – 200. Alexander Widder, Rainer v. Ammon, Philippe Schaeffer und Christian Wolff. Identification of suspicious, unknown event patterns in an event cloud. In: Jacobsen et al. [2007], S. 164 – 170. Alexander Widder, Rainer von Ammon, Gerit Hagemann und Dirk Schönfeld. An Approach for Automatic Fraud Detection in the Insurance Domain, 2009. URL citt-online.com/downloads/SSS09_FraudInsurance_CamaraReadyVersion.pdf. Zugriff am 26.07.2009.

308

Literatur

Peter Willaert, Joachim Van den Berg, Jurgen Willems und Dirk Deschoolmeeter. The Process-Oriented Organisation: A Holistic View – Developing a Framework for Business Process Organisation. In: Gustavo Alonso, Peter Dadam und Michael Rosemann (Hrsg.), Business Process Management, Band 4714 der Lecture Notes in Computer Science, S. 1 – 15, Berlin et al., 2007. Springer. Dan Woods und Thomas Mattern. Enterprise SOA – Designing IT for Business Innovation. O’Reilly, Beijing et al., 2006. Alex Wright. Making sense of sensors. Communications of the ACM, Band 52, Nr. 2, S. 14 – 15, 2009. Eugene Wu, Yanlei Diao und Shariq Rizvi. High-performance complex event processing over streams. In: SIGMOD ’06: Proceedings of the 2006 ACM SIGMOD international conference on Management of data, S. 407 – 418, New York, 2006. ACM. William A. Yarberry. Computer Telephony Integration. Auerbach, Boca Raton, 2. Auflage, 2002. Michael Zapf. Flexible Kundenkommunikationsprozesse im Communication Center, Band 22 der Reihe Informationstechnologie und Ökonomie. Peter Lang Europäischer Verlag der Wissenschaften, Frankfurt am Main, 2003. Andreas Zenz. Strategisches Qualitätscontrolling – Konzeption als Metaführungsfunktion. Zugl. Diss., TH Aachen, 1998. Deutscher Universitäts-Verlag, Wiesbaden, 1999. Michael zur Mühlen und Holger Hansmann. Workflowmanagement. In: Jörg Becker, Martin Kugeler und Michael Rosemann (Hrsg.), Prozessmanagement – Ein Leitfaden zur prozessorientierten Organisationsgestaltung, Kapitel 10, S. 373 – 407. Springer, Berlin und Heidelberg, 5., überarbeitete und erweiterte Auflage, 2005. Olaf Zwintzscher. Software-Komponenten im Überblick. W3L, Herdecke und Bochum, 2004.

Service- und Ereignisorientierung im Contact-Center: Entwicklung eines Referenzmodells zur Prozessautomatisierung

Markenportfoliobereinigungen: Entwicklung eines Planungsprozesses zur Strategieformulierung

Emotionen - Entwicklung und Regulation

FMEA - Einführung und Moderation: Durch systematische Entwicklung zur übersichtlichen Risikominimierung (inkl. Methoden im Umfeld)

Entwicklung und Analyse walkingbasierter Ausdauertestverfahren im Rahmen der medizinischen Rehabilitation

Entwicklung und Abwicklung von Bauprojekten im Bestand: Analyse - Planung - Ausführung

Drogenkonsum und -kontrolle: Zur Etablierung eines sozialen Problems im ersten Drittel des 20. Jahrhunderts

Optimierungspotenziale im Lebenszyklus eines Gebäudes

Positive Entwicklung: Zur Psychologie gelingender Lebensführung

Kommunikation in Forschung und Entwicklung

StudiVZ: Diffusion, Nutzung und Wirkung eines sozialen Netzwerks im Internet

Imagewirkungen von Eventmarketing. Entwicklung eines ganzheitlichen Messansatzes, 2. Auflage

Entwicklung des Welthandels im 19. Jahrhundert

Entwicklung und Gestaltung eines Untermehmenscontrolling in mittelstandischen Bauunternehemen: Unter Berucksichtigung von zwei empirischen Untersuchungen im zeitlichen Vergleich

Die Phiale, zur zeichenhaften Funktion eines Gefaßtyps

Businessplan und Markterfolg eines Geschäftskonzepts

Freuden und Leiden eines Vielgelesenen

Soziales Engagement von Banken: Entwicklung eines adaptiven und innovativen Konzeptansatzes im Sinne des Corporate Citizenship von Banken in Deutschland

Freuden und Leiden eines Vielgelesenen

Zur Wald- und Wasserfreude

Zur Wald- und Wasserfreude

Mambo: Installation, Administration, Anwendung und Entwicklung

Entwicklung und Anwendung explizit korrelierter Wellenfunktionsmodelle

Entwicklung eines Inline-Viskosimeters auf Basis eines magnetisch-induktiven Durchflussmessers German

Zur Wald- und Wasserfreude

Steuerung im Bildungswesen: Zur Zusammenarbeit von Ministerien, Schulaufsicht und Schulleitungen

Organisation der Integrierten Kommunikation: Entwicklung eines prozessorientierten Organisationsansatzes

Die Schere im Bauch. Aufzeichnungen eines Chirurgen

Zur Wald- und Wasserfreude

Instandhaltung technischer Systeme: Methoden und Werkzeuge zur Gewahrleistung eines sicheren und wirtschaftlichen Anlagenbetriebs (German Edition)

Service- und Ereignisorientierung im Contact-Center: Entwicklung eines Referenzmodells zur Prozessautomatisierung

Markenportfoliobereinigungen: Entwicklung eines Planungsprozesses zur Strategieformulierung

Emotionen - Entwicklung und Regulation

FMEA - Einführung und Moderation: Durch systematische Entwicklung zur übersichtlichen Risikominimierung (inkl. Methoden im Umfeld)

Entwicklung und Analyse walkingbasierter Ausdauertestverfahren im Rahmen der medizinischen Rehabilitation

Entwicklung und Abwicklung von Bauprojekten im Bestand: Analyse - Planung - Ausführung

Drogenkonsum und -kontrolle: Zur Etablierung eines sozialen Problems im ersten Drittel des 20. Jahrhunderts

Optimierungspotenziale im Lebenszyklus eines Gebäudes

Positive Entwicklung: Zur Psychologie gelingender Lebensführung

Kommunikation in Forschung und Entwicklung

StudiVZ: Diffusion, Nutzung und Wirkung eines sozialen Netzwerks im Internet

Imagewirkungen von Eventmarketing. Entwicklung eines ganzheitlichen Messansatzes, 2. Auflage

Entwicklung des Welthandels im 19. Jahrhundert

Entwicklung und Gestaltung eines Untermehmenscontrolling in mittelstandischen Bauunternehemen: Unter Berucksichtigung von zwei empirischen Untersuchungen im zeitlichen Vergleich

Die Phiale, zur zeichenhaften Funktion eines Gefaßtyps

Businessplan und Markterfolg eines Geschäftskonzepts

Freuden und Leiden eines Vielgelesenen

Soziales Engagement von Banken: Entwicklung eines adaptiven und innovativen Konzeptansatzes im Sinne des Corporate Citizenship von Banken in Deutschland

Freuden und Leiden eines Vielgelesenen

Zur Wald- und Wasserfreude

Zur Wald- und Wasserfreude

Mambo: Installation, Administration, Anwendung und Entwicklung

Entwicklung und Anwendung explizit korrelierter Wellenfunktionsmodelle

Entwicklung eines Inline-Viskosimeters auf Basis eines magnetisch-induktiven Durchflussmessers German

Zur Wald- und Wasserfreude

Steuerung im Bildungswesen: Zur Zusammenarbeit von Ministerien, Schulaufsicht und Schulleitungen

Organisation der Integrierten Kommunikation: Entwicklung eines prozessorientierten Organisationsansatzes

Die Schere im Bauch. Aufzeichnungen eines Chirurgen

Zur Wald- und Wasserfreude

Instandhaltung technischer Systeme: Methoden und Werkzeuge zur Gewahrleistung eines sicheren und wirtschaftlichen Anlagenbetriebs (German Edition)

Recommend Documents