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 1464 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 hoﬀen, dass sein Ansatz für nachfolgende Studien fruchtbar sein möge. Regensburg, im August 2010 Prof. Dr. Christian Wolﬀ

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. Deﬁnition der Begriﬀe 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. Begriﬀsklä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 Einﬂussfaktoren auf Dienstleistungsunternehmen . . . . . . 3.2.2. Industrialisierung von Dienstleistungen . . . . . . . . . . . . . . . . 3.3. Kundenorientierung und Industrialisierung als Einﬂussfaktoren . . . . . . .

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. Prozessbegriﬀ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.1.1. Deﬁnition des Prozessbegriﬀs . . . . . . . . . . . . . . . . . . . . . 52 4.1.2. Prozessklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.1.3. Prozessorientierung und Prozessorganisation . . . . . . . . . . . . . 57 4.2. Geschäftsprozessmanagement . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.2.1. Deﬁnition 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. Workﬂow-Management und der Workﬂow-Begriﬀ . . . . . . . . . . 100 4.5.2. Workﬂow-Management im Kontext von Geschäftsprozessmanagement102 5. Serviceorientierung 5.1. Serviceorientierung und serviceorientierte Architekturen . . . . . . . . . . 5.1.1. Deﬁnition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. Ereignisbegriﬀ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. Workﬂow-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. Identiﬁkation von Zielen und Architekturprinzipien . . . 8.3. Domänenarchitektur . . . . . . . . . . . . . . . . . . . . 8.4. Identiﬁkation 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 Identiﬁkation von Komponenten . . . 236 9.2.2. Schaﬀung einer Event-Driven-Architecture (EDA) . . . . . . . . . . 237 9.2.3. Notiﬁcation-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. Schaﬀung 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-Begriﬀs [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] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deﬁnition „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 Workﬂow-Beispiele zur Integration [aus Weske, 2007, S. 52, 54] . . . . . . . 102 Diﬀerenzierung der Systembegriﬀe [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-Deﬁnition . . 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-Oberﬂäche . . . . . . . . . . . . . . . Vorgehensmodell zur Gestaltung der Ereignisorientierung . . . . . . . . . . Operationen und Standardnutzung des Notiﬁcation-Service . . . . . . . . . Operationen und Standardnutzung des Notiﬁcation-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] Einﬂuss 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. Diﬀerenzierung der Eventbegriﬀe . . . . . . . . . . . . . . . . . . . . . . . 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 Speciﬁc Model Public Switched Telephone Network Quality of Service Resource Deﬁnition Framework Resource Deﬁnition 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 Identiﬁer

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 Workﬂow Management Coalition Workﬂow 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 Einﬂussfaktoren 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 Endeﬀekt 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äuﬁg 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äuﬁg aus einer technischen Blickrichtung heraus. Zusätzlich liegt der Fokus dabei in einer eher generischen Betrachtung. Contact-Center-speziﬁsche Problematiken ﬁnden 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 speziﬁschen 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üsselbegriﬀe 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 Schaﬀung der technischen und fachlichen Möglichkeiten im Mittelpunkt. Die Ergebnisse dieser Arbeit

4

1. Service- und Ereignisorientierung im Contact-Center

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 ﬁnden 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äuﬁger 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ückgegriﬀen 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 betroﬀen. 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ösungsﬁndung 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öﬀentlichte 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 ﬀ] 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 schaﬀenden Originals. Das geschaﬀene 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-Begriﬀ deﬁniert, 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 Einﬂuss 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

1. Service- und Ereignisorientierung im Contact-Center

Abbildung 3: Aufbau der Arbeit deﬁniert den Prozessbegriﬀ 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 Identiﬁkation 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 deﬁniert 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äuﬁg, 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, Greﬀ und Fojut, 2003]. Grund für die Geläuﬁgkeit des Begriﬀs ist auch die Belegung mit einem negativem Image, bedingt durch die Anwendung unlauterer Methoden und fragwürdiger Personalpolitik einzelner schwarzer Schafe [vgl. bspw. Wallraﬀ, 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 Einﬂussfaktoren, 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 Begriﬀe deﬁniert und voneinander abgegrenzt, um die begriﬄiche Grundlage für die weitere Arbeit zu legen.

2.1. Deﬁnition der Begriﬀe 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 Begriﬀ Call-Center selbst stammt aus den USA ebenso wie die Organisationsform selbst [vgl. Lehner und Lüders, 2002, S. 1]. Die verschiedenen Deﬁnitionen 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 eﬃziente 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 Deﬁnition

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

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 diﬀerenzieren: 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. Greﬀ 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äuﬁg 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. Greﬀ 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 eﬀektiven Kundenservice und 3. eﬃzienter 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 eﬀektiv und eﬃzient 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 Begriﬀs „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 Deﬁnition. 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 ﬁnanziell 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 anzutreﬀende 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

2. Contact-Center als Dienstleister in der Kundenkommunikation

Kernkompetenzen ermöglicht werden. Im Innenverhältnis können die Unternehmensteile rechtlich oder ﬁnanziell 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 getroﬀen, 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 Deﬁnition 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 Begriﬀ „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

2. Contact-Center als Dienstleister in der Kundenkommunikation

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].

2.3. Aufbau und Organisation von Contact-Centern

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 öﬀentliche 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. Greﬀ 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 [Greﬀ und 5

Weiterer häuﬁg gebrauchter Begriﬀ: „Public Switched Telephone Network“ (PSTN) [vgl. Greﬀ und Fojut, 2003, S. 130]

18

2. Contact-Center als Dienstleister in der Kundenkommunikation

Fojut, 2003, S. 55], [Hild, 2003, S. 76]. Genauer deﬁniert [Stockberger, 2001] den Begriﬀ CTI (vergleiche dazu auch Abbildung 7): „[CTI] setzt das Telefonnetz, die Sprachübermittlung, den Datenﬂuß, 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 ﬀ.], [Greﬀ und Fojut, 2003, S. 55].

2.3. Aufbau und Organisation von Contact-Centern

19

CTI beﬁndet 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 öﬀentliche Telefonnetz zu vermitteln, ﬁndet 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 ﬁndet 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 ﬀ.], [Greﬀ und Fojut, 2003, S. 19 - 20, 46 - 47], [Böse et al., 2001, S. 77 ﬀ.], [Böse und Flieger, 1999, S. 144 ﬀ.]. 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) [speziﬁziert in IETF, 1981]. SIP [speziﬁziert 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 ﬀ.], [Sinnreich und Johnston, 2006] 8 Vergleiche zum allgemeinen Begriﬀ Multikanal-Management beispielsweise [Ahlert et al., 2003], [Merx und Bachem, 2001]. 7

20

2. Contact-Center als Dienstleister in der Kundenkommunikation

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 Klassiﬁzierung des Anliegens notwendig. Die geschieht abhängig vom Kanal unterschiedlich. Telefonanrufe können durch ein vorgeschaltetes Sprachportal klassiﬁziert werden, indem über die Telefontastatur oder über Spracherkennung die Art des Anliegens eingeordnet wird. Bei schriftlichen Vorgängen kann die Klassiﬁzierung ü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 qualiﬁziert 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 beeinﬂussen 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 ﬀ.], [Cleveland et al., 2002, S. 118 ﬀ.]. • 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-

2.3. Aufbau und Organisation von Contact-Centern

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 ﬂexibel angepasst (etwa durch Zuschalten von Agenten mit geringerem Skill-Level für die jeweilige Aufgabe) [vgl. bspw. Schmidt, 2007, S. 63 ﬀ.], [Bommer, 2007, S. 87 ﬀ.]. 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 Öﬀnungszeiten eintreﬀen 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. Greﬀ und Fojut, 2003, S. 97, 164 - 165]. In einem Sprachportal werden dem Kunden Sätze mit Hinweisen und Auﬀorderungen 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 Begriﬀs SLA und Service-Level im Kontext von Contact-Centern ebenso wie einen Überblick aktueller Deﬁnitionen 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 Einﬂuss des Internet wird dies auch im größeren Kontext eine wichtige Problemstellung, die in der Forschung und Wissenschaft ihre Aufmerksamkeit ﬁndet. Unter dem Begriﬀ „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

2. Contact-Center als Dienstleister in der Kundenkommunikation

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 ﬀ.], [Greﬀ 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 oﬀene 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], [Greﬀ 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 eﬃziente 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

2.3. Aufbau und Organisation von Contact-Centern

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 Benutzeroberﬂächen der benötigten Anwendungssysteme. Die notwendigen Basisund Kundendaten werden durch CTI-Funktionalitäten bereitgestellt [vgl. bspw. Herrell, 2007, S. 6]. Business-Intelligence Der Begriﬀ Business-Intelligence (BI) wird sehr weitläuﬁg 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 Entscheidungsﬁndung. 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-Centerspeziﬁsche 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 ﬀ.]. 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 ﬀ.]. 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 Begriﬀs Business-Intelligence mit der Fragestellung der wissenschaftlichen Notwendigkeit eines eigenen Begriﬀs gibt [Mertens, 2002].

24

2. Contact-Center als Dienstleister in der Kundenkommunikation

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. 86ﬀ.]. 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 ﬀ.]. 2.3.2. Problemstellung der IT-Landschaft in Contact-Centern Die in den obigen Abschnitten dargestellten technischen Komponenten sind meist speziﬁsch 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ösungsﬁndung folgende Fragestellungen sinnvoll:

2.3. Aufbau und Organisation von Contact-Centern

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 beﬁndlichen Systeme ﬂexible Auswertungs- und Analysefunktionen? • Wie kann in einem solchen Informationssystem navigiert und können dabei unter Umständen auch ad hoc neue Informationsinhalte geschaﬀen 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 ﬀ.], [Kosiol, 1976]. Abteilungsgliederung In der klassischen Theorie der Aufbauorganisation werden Zuordnungen beziehungsweise Zusammenfassungen von (Teil-)Aufgaben zu personalen Aufgabenträgern unter dem Begriﬀ der Organisationseinheit vorgenommen [vgl. Kosiol, 1976, S. 89 ﬀ.]. In Bezug auf die zur Aufgabenerfüllung eingesetzten Menschen spricht man von Stellen und Stellenmehrheiten. Eine Stelle ist dabei „[...] die kleinste organisatorisch zu deﬁnierende 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äuﬁg 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äuﬁg eine Gliederung von Stellenmehrheiten nach Qualiﬁkations- und Kommunikationsmix in Contact-Centern anzutreﬀen [vgl. Zapf, 2003, S. 31 ﬀ.]. 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

2. Contact-Center als Dienstleister in der Kundenkommunikation

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 Diﬀerenzierung nach dem Qualiﬁkationsmix 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-Oﬃce-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 Qualiﬁkationsmix 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 anzutreﬀen sind. Diese Aufteilung wird gestützt durch Expertenbefragungen in den Jahren 2006 bis 2008.

2.3. Aufbau und Organisation von Contact-Centern

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 ﬁndet beim Back-Oﬃce-Modell statt. Hier werden alle synchronen Kundenanliegen (hauptsächlich Telefonanrufe) im sogenannten Front-Oﬃce beantwortet. Das Front-Oﬃce besteht dabei aus den Generalisten. Komplexere Anliegen werden, analog dem n-Ebenen-Modell, an das Back-Oﬃce weitergeleitet. Im Back-Oﬃce 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 Qualiﬁkationsmix zeigt Abbildung 8. Neben dem Qualiﬁkationsmix 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 ﬂache Hierarchieabstufung in Kombination mit einfachen und transparenten Strukturen auf, welche im Allgemeinen eine ﬂexible Anpassung der Organisation erlauben [vgl. Thieme und Steﬀen, 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

2. Contact-Center als Dienstleister in der Kundenkommunikation

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 eingegriﬀen 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 ﬀ.]. 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 beschaﬀen 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 Zugriﬀ 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 eﬃziente und

2.3. Aufbau und Organisation von Contact-Centern

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 vordeﬁniert 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 ﬂexible 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 ﬀ.], [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 Begriﬀ Workforce-Management, wie er hier deﬁniert ist, wird in dieser Ausprägung weitgehend im Contact-Center-Umfeld verstanden und häuﬁg benutzt. Der gleiche Begriﬀ wird in der Betriebswirtschaftslehre unterschiedlich und meist mit weiter reichendem Fokus benutzt.

2.3. Aufbau und Organisation von Contact-Centern

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 ﬀ.]. 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 Eﬃzienzsteigerung 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 ﬀ.].

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 Einﬂussgröß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 Begriﬀsklärung vorgenommen, die Kundenorientierung in den größeren Unternehmenskontext eingeordnet und die Zielsetzung der Kundenorientierung geklärt. Abschließend ﬁndet eine Einordnung in Zusammenhang mit Contact-Centern statt. 3.1.1. Begriﬀsklärung Kundenorientierung Nach eingehender Literaturrecherche muss festgestellt werden, dass es keine allgemeine und übergreifende Deﬁnition für ein Konzept der Kundenorientierung gibt. Die Kundenorientierung wird unter verschiedenen Aspekten des Umgangs mit Kundenbeziehungen zitiert und verwendet. Häuﬁg werden Begriﬀe wie „Customer Relationship Management“ oder „Customer Relationship Marketing“21 und andere Kombinationen aus ähnlichen Begriﬀen benutzt, die eine Beziehungsgestaltung eines Unternehmens zum Kunden hin meinen. Der Begriﬀ Kundenorientierung bezieht sich auf Kunden als die Anspruchsgruppe von Unternehmen, auf die hin die Unternehmensaktivitäten ausgerichtet werden22 . Der Begriﬀ 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äuﬁg mit „CRM“ abgekürzt. Nur im jeweiligen Kontext, in dem die Begriﬀe 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]

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

34

3. Kundenorientierung und Industrialisierung in der Kundenkommunikation

wie Mitarbeiter, Lieferanten und Kapitalgeber ausgeweitet werden [vgl. Meyer et al., 2006, S. 63]. Zunächst deﬁniert [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 deﬁniert 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 Pﬂege von Beziehungen. Die Kundenzufriedenheit ist dann Ziel dieser Bemühungen“ [Rudolph und Rudolph, 2000, S. 9]. In dieser Deﬁnition 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 deﬁnieren [Rudolph und Rudolph, 2000, S. 4] „CRM [als] professionelles Beziehungsmarketing von Unternehmen oder Institutionen auf den Feldern ihrer Absatzmärkte, den Beschaﬀungsmä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 Identiﬁkation proﬁtabler 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 ﬁnden, mit 23 24

Die Begriﬀe 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-Begriﬀe synonym verwendet, um gemeinsame und wesentliche Elemente des Begriﬀs Kundenorientierung zu erarbeiten. Dies kann nun etwas genauer betrachtet und die Kundenorientierung in das Unternehmensmarketing eingeordnet werden. Ausgangspunkt klassischen Marketings ist eine gestaltende Beeinﬂussung 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 [Meﬀert 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 ﬀ.]. 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

3. Kundenorientierung und Industrialisierung in der Kundenkommunikation

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 proﬁtabler 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-Begriﬀs [aus Hippner, 2006, S. 20]

3.1. Kundenorientierung als Unternehmensziel

37

Mittels der Einteilung nach [Hippner, 2006] können die verwendeten „Beziehungsbegriﬀe“ abschließend nochmals abgegrenzt werden. Darin werden die Begriﬀe wie in Abbildung 10 dargestellt diﬀerenziert. 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 proﬁtabler Kundenbeziehungen [vgl. Bruhn, 2001, 2006b, S. 58 bzw. 38f.].

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

38

3. Kundenorientierung und Industrialisierung in der Kundenkommunikation

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 deﬁnieren. [Hippner und Wilde, 2002, S. 12] unterteilen dabei die strategische Zielsetzungen in die folgenden vier Bereiche: 1. Proﬁtabilität: Im Sinne der Kundenorientierung liegt der unternehmerische Fokus auf langfristig proﬁtablen 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. Diﬀerenzierung: Nach [Hippner und Wilde, 2002] ist eine feine Diﬀerenzierung der Kundenbeziehung eine zentrale Forderung bei der Kundenorientierung. Die Diﬀerenzierung bezieht sich dabei auf Produkte, Leistungen und den Dialog mit dem Kunden. Hier müssen diese drei diﬀerenziert 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 kundenspeziﬁsch gestaltet werden. Aus Unternehmersicht ist dies nicht immer machbar. Hier gilt es, die Kosten, die mit der kundenspeziﬁschen Gestaltung der Geschäftsprozesse verbunden sind, mit der zu erwartenden Proﬁtabilität des Kunden abzuwägen [vgl. Hippner und Wilde, 2002, S. 9f.]. 3. Langfristigkeit: Getragen von der Aussage der Proﬁtabilität langfristiger Kundenbeziehungen ist es eine Zielsetzung der Kundenorientierung, langfristige Kundenbeziehungen aufzubauen und zu festigen. Die zentrale Rolle nimmt hier nun die Pﬂege 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.

3.1. Kundenorientierung als Unternehmensziel

39

• Auswertungen langfristig angesammelter Kundendaten führen zu Kosteneinsparungen, da Marketingaktionen gezielter eingesetzt werden können und eine diﬀerenzierte 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 Diﬀerenzierung 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 speziﬁschen 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

3. Kundenorientierung und Industrialisierung in der Kundenkommunikation

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

3.1. Kundenorientierung als Unternehmensziel

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 speziﬁschen 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. [Meﬀert 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

3. Kundenorientierung und Industrialisierung in der Kundenkommunikation

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 betriﬀt 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 Begriﬀe verwendet werden, so ist meist eine bestimmte Entwicklung oder ein Trend gemeint, der die Wirtschaft auf der gesamten Welt beeinﬂusst. 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 Einﬂussfaktoren 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 Begriﬀ 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 ﬂießend und dank moderner Kommunikationstechnologien ist persönlicher Kontakt auch ohne physischen möglich, so dass man die Deﬁnition 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 Begriﬀe gibt. „Gemeint ist damit eine Entwicklung, die seit gut 20 Jahren in unterschiedlichen Bereichen stattﬁndet und begriﬄich 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 geograﬁsch nicht mehr begrenzt.

Bei der Untersuchung dieser begriﬄich 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 Einﬂussgrößen beziehungsweise Forderungen von Bedeutung: • Angleichung der Informationstechnologie: Es besteht die zunehmende Forderung von Fachanwendern und Unternehmensführung nach ﬂexiblen, 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. 4ﬀ.] 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 vorﬁnanzieren, 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 • eﬀektive Nutzung der Infrastruktur wie beispielsweise der IT. Einen weiteren Einﬂussfaktor stellt die Informationalisierung dar. Der Begriﬀ 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 Rohstoﬀ 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 Rekonﬁguration [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 Begriﬀ Industrialisierung wird in verschiedenen Wissenschaftsdisziplinen gebraucht, für den Fokus dieser Arbeit steht jedoch die geschichtswissenschaftlich-ökonomische Sicht28

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

46

3. Kundenorientierung und Industrialisierung in der Kundenkommunikation

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 Deﬁnition 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 Begriﬀs „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öﬀentlichte die Schrift „Scientiﬁc 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 Einﬂussfaktoren

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 Einﬂüsse der Globalisierung und die in Abbildung 18 genannten Einﬂussgröß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 Einﬂussfaktoren Die Kundenorientierung wie auch die Industrialisierung sind wesentliche Einﬂussfaktoren auf Contact-Center. Bei einer Untersuchung durch [Habel, 2006] in diesem Bereich wurden für beide Einﬂussfaktoren 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

3. Kundenorientierung und Industrialisierung in der Kundenkommunikation

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-speziﬁsche prozessorientierte Organisationsstruktur die strukturelle Anpassungsfähigkeit ab. Die eﬀektive 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 Einﬂussfaktoren

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 Deﬁnition des Begriﬀs des Geschäftsprozesses. Anschließend werden das klassische Geschäftsprozessmanagement und seine Komponenten vorgestellt. Der Begriﬀ „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 speziﬁsche Ausprägungen oder Spezialisierungen, wie beispielsweise Anwendungsdomänen, einzugehen.

4.1. Prozessbegriﬀ Bevor das Konzept des Geschäftsprozessmanagements erklärt werden kann, ist es nützlich, mit der Deﬁnition des Prozessbegriﬀs zu beginnen und dabei die Eigenschaften zu erarbeiten, die einen Prozess zum Geschäftsprozess machen.

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

52

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

4.1.1. Deﬁnition des Prozessbegriﬀs Aus Sicht der Wortherkunft meint „Prozess“ zunächst nur einen Vorgang oder eine Abfolge32 . Sehr weitläuﬁg 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 Prozessdeﬁnition: „Jeder Prozess hat Eingaben (Inputs), die durch Umwandlung in Ergebnisse (Outputs) münden“, wobei durch einen Prozess Werke geschaﬀen werden. In dieser Input-Output-Beziehung eines Prozesses sind die wesentlichen Eingaben in einen Prozess Arbeit, Roh-, Hilfs- und Betriebsstoﬀe, 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. Prozessbegriﬀ

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 ﬀ.]. 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: Deﬁnition „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 eﬃzient 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äuﬁg dazu, dass die einzelnen wertschöpfenden Aktivitäten unterschiedlichen funktionalen Einheiten

54

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

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 Deﬁnition 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 • Deﬁnierter Anfang • Summe von sich wiederholenden Tätigkeiten • Messbarer Prozessoutput • Deﬁniertes Ende • Prozessabschließendes Ereignis • Betroﬀene 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 deﬁnieren: 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]

4.1. Prozessbegriﬀ

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äftsprozessbegriﬀs bleibt die Frage nach einer sinnvollen weiteren Diﬀerenzierung oﬀen, 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

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

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 Einﬂuss auf die Wettbewerbsfähigkeit, während sekundäre Geschäftsprozesse die entsprechende Umgebung für eine eﬃziente Ausführung zur Verfügung stellen [vgl. Weske, 2007, S. 42]. [Schmelzer und Sesselmann, 2008] deﬁnieren dies ähnlich. Für sie „ﬁndet 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äuﬁg 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 einﬂießen und mithilfe derer die eigentliche Wertschöpfung erfolgt“ [Staud, 2006, S. 11]. In diesen Deﬁnitionen 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 Zielﬁndung 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.

4.1. Prozessbegriﬀ

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 diﬀerenzieren. 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 Deﬁnition 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 Deﬁnition 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

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

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 Diﬀerenzierung der Geschäftsprozesse nach den Prozessklassen Kernprozess und Supportprozess wichtig. Die Kernkompetenzen eines Unternehmens werden in den Kernprozessen erbracht, darüber diﬀerenziert 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

4.1. Prozessbegriﬀ

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 Speziﬁtät“. Speziﬁsch 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 Speziﬁtä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

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

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 ﬀ.] bezeichnet dies beispielsweise als Prozesschoreograﬁe. Für Contact-Center als virtuelle Organisation ist Prozesschoreograﬁe 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 ﬀ.]. Aus IT-technologischer Sicht kommen noch Systemarchitekt und Entwickler hinzu [vgl. Weske, 2007, S. 13]. Drittes wesentliches Merkmal der Prozessorganisation ist die informationale Vernetzung.

4.1. Prozessbegriﬀ

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 Einﬂussfaktoren. Diese werden im Referenzmodell mit dem besonderen Einﬂuss der Serviceorientierung und Ereignisorientierung erneut aufgegriﬀen. 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 Einﬂuss 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 ﬀ.] nach. [Willaert et al., 2007] zeigt den positiven statistischen Einﬂuss 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

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

Einﬂussfaktor

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 geograﬁscher 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: Einﬂuss 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 ﬁnden, 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 Deﬁnition 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 Deﬁnition des Geschäftsprozesses fällt dies mit in die Betrachtung und muss im Referenzmodell berücksichtigt werden. Um eine Prozesschoreograﬁe zu ermöglichen (virtuelles Unternehmen), müssen Standards

4.2. Geschäftsprozessmanagement

63

benutzt werden. Die Einﬂussfaktoren 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 Eﬃzienz (die Dinge richtig tun) und Eﬀektivitä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 Eﬀektivität dar, mit anderen Worten ist dadurch die Frage des „Was?“ geklärt. Oﬀen bleibt noch die Frage nach dem „Wie?“. Dies soll mit den folgenden Abschnitten zum Thema Geschäftsprozessmanagement beantwortet werden.

4.2.1. Deﬁnition 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 Deﬁnition, so ist Geschäftsprozessmanagement analog eine Sammlung von Tätigkeiten zur Lenkung und Steuerung einer Prozessorganisation. Ähnlich deﬁniert [Kugeler, 2001, S. 386 ﬀ.] 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 Deﬁnition 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, conﬁguration, 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 „kulturﬂankierende 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 markt- und kundenorientierte Prozessstrategien ab. Die Planung und Steuerung der prozessorientierten Aktivitäten sind dabei gezielt markt- und 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 ﬀ.]. Die Systematik wird durch das Geschäftsprozessmanagement sichergestellt.

64

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

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 Eﬀektivität und Eﬃzienz des Unternehmens. Notwendig ist dies, da nach wie vor „viele Eﬀektivitäts- und Eﬃzienzprobleme 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 Schaﬀung 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öﬀentlichung von [Gaitanides, 1983] wurde Geschäftsprozessmanagement mit zunehmender Bedeutung als ganzheitliches Konzept in Forschung und Praxis entwickelt und weiterentwickelt. Dabei ﬂossen 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 Auﬀassung 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 beﬁndet sich Geschäftspro-

4.2. Geschäftsprozessmanagement

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 Begriﬀ „business process management“ (BPM) sehr häuﬁg mit IT-Lösungen gleichgesetzt wird (beispielhaft die Veröﬀentlichungen 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 getroﬀen 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 Deﬁnition 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 ﬀ. und 594]. Er sieht in integriertem Management die „Harmonisation eines hochkomplexen Netzwerkes auf der Grundlage einer Management-Philosophie“ [Bleicher, 2004, S. 589 ﬀ.].

66

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

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

4.2. Geschäftsprozessmanagement

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 wiederﬁnden. Auf Grund der Vielzahl von Konzepten im Unternehmen ist es deshalb wichtig, eine gemeinsame Systematik für alle Aspekte zu ﬁnden 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äuﬁgen 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

von GPM unterstützt

Total Quality Management

von GPM unterstützt

Change Management

wichtig für GPM

Wissensmanagement

von GPM unterstützt

Customer Relationship Management

in GPM integriert

Supply Chain Management

in GPM integriert

Lean Management

von GPM unterstützt

Simultaneous Engineering

von GPM unterstützt

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

von GPM unterstützt

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

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

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 ﬁxiert sind. Auf dieser Grundlage werden die vorhandenen Geschäftsprozesse in der Geschäftsprozessmodellierung identiﬁziert, klassiﬁziert, 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 ﬁnden. Vergleicht man Veröﬀentlichungen, die nicht nur Teilaspekte betrachten, sondern ein komplettes Vorgehensmodell darstellen, gibt es Unterscheidungen in der Begriﬄichkeit 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

4.2. Geschäftsprozessmanagement

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 ﬁnden 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 ﬁnden. 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 Einﬂuss 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

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

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 identiﬁzierten 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äftsprozessdeﬁnition 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

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

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 Identiﬁkation, Gestaltung, Dokumentation und Analyse speziﬁscher 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 speziﬁschen 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 Identiﬁzierung, Strukturierung, Beschreibung und Vernetzung von Geschäftsprozessen und ist

4.3. Geschäftsprozessmodellierung

73

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

Identiﬁkation und Strukturierung von Geschäftsprozessen Die Identiﬁkation 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 Identiﬁkation 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 Identiﬁkation 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 Beschaﬀung (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, Materialbeschaﬀung, Produktionsplanung und -steuerung, Reklamation sowie Kundendienst. Noch stärker abstrahiert [Lohse, 1996] die Kerngeschäftsprozesse: Beschaﬀung 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

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

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äuﬁg nach dem Objekt-Verrichtungs-Prinzip vorgegangen. Dabei wird das Informationsobjekt (als Substantiv) des Geschäftsprozesses sowie die zugehörige Verrichtung (als Verb im Inﬁnitiv) 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 identiﬁziert und benannt. Sie werden weiterhin strukturiert, in dem die Teilprozesse der nachfolgenden Abstraktionsebene im Sinne der Prozessebenen ebenfalls identiﬁziert und benannt werden (analog Abbildung 29, Seite 71). Darüber hinaus gehende Inhalte werden an dieser Stelle der Abstraktion noch nicht identiﬁziert. 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 speziﬁschen 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 Identiﬁkation und Strukturierung der Geschäftsprozesse schließt sich die Erhebung und Analyse des Istzustandes in Form der Beschreibung, Dokumentation und detaillierten Vernetzung der

4.3. Geschäftsprozessmodellierung

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 graﬁsch aufzuzeigen [vgl. Feldmayer und Seidenschwarz, 2005, S. 47 ﬀ.]. 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 graﬁsche Darstellung dagegen ist anschaulich und der Kontrollﬂuss kann übersichtlich dargestellt werden. Werden bei der graﬁschen 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 graﬁsche 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]: • Identiﬁkation, 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 graﬁscher Form mittels eines entsprechenden Modelltyps abzudecken, wird in der Geschäftsprozessmodellierung häuﬁg 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).

4.3. Geschäftsprozessmodellierung

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 betroﬀen, 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

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

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: wohldeﬁnierte 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)

4.3. Geschäftsprozessmodellierung

79

• Organisatorische Rahmenbedingungen: Festlegung von Verantwortlichkeiten und Prozessen im Rahmen der Modellierung und Pﬂege der Geschäftsprozessmodelle • Prozessmodellarchitektur: Vorschriften für Modellierer zur Unterteilung, Beziehungsgestaltung und Zweck innerhalb des Unternehmensprozessmodells (analog „Identiﬁkation 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äuﬁgsten herangezogen: ARIS auf Grund der großen Bekanntheit und der breiten theoretischen Fundierung und BPMN als neuer und häuﬁg 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

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

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 ﬀ., 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 Auﬂistung der wichtigsten darin enthaltenen Modelltypen ergibt sich nach [Seidlmeier, 2006, S. 51 ﬀ.] und [Lehmann, 2008, S. 29 ﬀ.] 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

4.3. Geschäftsprozessmodellierung

81

Abbildung 34: ARIS-Haus [aus Scheer, 2001, S. 1] • Organisationssicht: Organigramm • Funktionssicht: Funktionsbaum, Zieldiagramm, Anwendungssystemtypendiagramm • Leistungssicht: Produktbaum • Datensicht: Fachbegriﬀsmodell, 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

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

Scheer, 1996, S. 7 ﬀ.]. 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 Identiﬁkation 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 graﬁschen 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“

4.3. Geschäftsprozessmodellierung

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öﬀentlicht 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 ﬀ.]: • Funktion: Eine Funktion entspricht einer Aufgabe beziehungsweise einem betriebswirtschaftlichen Vorgang zur Leistungserstellung. Der Funktionsbegriﬀ 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 Speziﬁkation betriebswirtschaftlicher Bedingungen und Ereignisse können auf Informationsobjekte des Datenmodells referenzieren. • Operatoren und Kontrollﬂuss: Der Kontrollﬂuss (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 Kontrollﬂuss 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 Auﬂistung dieser sogenannten Erweiterungsobjekttypen macht beispielsweise [Lehmann, 2008, S. 78 - 79 (Auszug)]: • Organisationsspeziﬁsche Objekttypen: Organisationseinheitstyp, Organisationseinheit, Stellentyp, Stelle, Stellenbeschreibung, Personentyp (Rolle), Standort, Arbeitsplatz • Datenspeziﬁsche Objekttypen: Cluster, Entitytyp, Beziehungstyp, Information (Ist), Information (Soll), Fachbegriﬀ 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.

4.3. Geschäftsprozessmodellierung

85

Abbildung 37: Beispiel einer EPK mit Grundelementen • Leistungsspeziﬁsche Objekttypen: Leistung, Dienstleistung, Informationsdienstleistung, Produkt • Funktionsspeziﬁsche 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 qualiﬁziert 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 ﬁnden 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 Deﬁnitionskopien). 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 ﬁndet 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.

4.3. Geschäftsprozessmodellierung

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öﬀentlicht und liegt nun als Speziﬁkation in der Version 1.1 seit Januar 2008 vor, speziﬁziert durch die Object Management Group (OMG)43 . BPMN ist eine Notation zur graﬁschen 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 kontrollﬂussorientiert [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 Speziﬁkation von BPMN beschreibt und speziﬁziert 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 Speziﬁ42 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 speziﬁziert und weiterentwickelt.

88

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

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 Speziﬁkationen 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 Auﬂistung 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 ﬀ.] 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 Begriﬀ 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 Begriﬀe werden hier im Original in Englischer Sprache wiedergegeben. Einen ersten Vorschlag zur Übersetzung macht beispielsweise [Allweyer, 2008].

4.3. Geschäftsprozessmodellierung

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 Nachrichtenﬂuss zwischen den Prozessbeteiligten. • Association: Die Assoziation verbindet Informationen mit Flow Objects. Informationen können in Textform oder als graﬁsche 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 graﬁschen 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 ﬀ.]. 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

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

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 Deﬁnition von SAP-Workﬂows 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 speziﬁziert 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-

4.3. Geschäftsprozessmodellierung

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 deﬁniert 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

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

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 speziﬁziert 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 Graﬁkwerkzeugen: Ausprägungs- und Deﬁnitionskopien lassen sich unterscheiden und eine zentrale Verwaltung von Objekten sicherstellen, die eine Konsolidierung von Objekten und Modellen gewährleisten ebenso wie Methodenﬁlter 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 Identiﬁkation 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 Begriﬀ „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 Deﬁnitionen 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 triﬀt 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

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

mann, 2006, S. 4 ﬀ.]. Zu den Aufgaben der Informationsversorgung gehört zunächst die Ermittlung des Informationsbedarfs gefolgt von der Beschaﬀung, 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 quantiﬁzierbaren Vergleich mit anderen Geschäftsprozessen zu erlauben. Kennzahlen werden häuﬁg 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 ﬀ.]. Häuﬁg tritt auch der Begriﬀ „Key Performance Indicator (KPI)“ in Erscheinung. In der Literatur zu Geschäftsprozesscontrolling wird in der Regel allerdings keine genaue Unterscheidung der Begriﬀe 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 deﬁniert [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 schaﬀen [vgl. Tavasli, 2007, S. 177]. Es werden drei Arten von Kennzahlensystemen unterschieden: • Rechensystem: In einem Rechensystem werden quantiﬁzierbare 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 quantiﬁzierbare 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.

4.4. Geschäftsprozesscontrolling und -optimierung

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äuﬁg angezeigt. Darin ist es möglich, Geschäftsprozessberichte zu erstellen, ad-hoc Anfragen zu stellen und Prozesscockpits darzustellen [vgl.

96

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

Allweyer, 2005, S. 386 - 393]. Prozesscockpits sind Online-Systeme, die Geschäftsprozessberichte am Bildschirm darstellen und meist um Echtzeitinformationen und graﬁsche 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 ﬀ.]. „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 mehrstuﬁgen 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 ﬀ.] und [Fischermanns, 2006, S. 258 ﬀ.]. Die Besonderheiten der Prozesskostenrechnung in der Dienstleistung diskutieren beispielsweise [Coenenberg et al., 2007, S. 272 ﬀ.] und [Möller und Cassack, 2008].

4.4.2. Regelungs- und steuerorientiertes Geschäftsprozesscontrolling Neben dem informationsorientiertem Konzept gibt es weitreichendere Deﬁnitionen des Controllingbegriﬀs, 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.

4.4. Geschäftsprozesscontrolling und -optimierung

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 deﬁnieren [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 deﬁniert, 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 deﬁniert 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 Identiﬁkation von Verbesserungspotentialen – beschreibt beispielsweise [Jung, 2006a, S. 103 ﬀ.]: • 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 Informationsﬂusses inklusive der Beziehungen zwischen den Tätigkeiten und Informationen („benötigt“, „erzeugt“, „geprüft“) zur Optimierung des Informationsﬂusses. • 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

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

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

4.4. Geschäftsprozesscontrolling und -optimierung

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 Auﬀassung 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 Deﬁnition 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 Deﬁnition und Auseinandersetzung soll hier nicht weiter vertieft werden, sie triﬀt 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 Einﬂuss 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 schaﬀen, 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. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

4.5. Prozessautomatisierung An dieser Stelle soll die Grundproblematik der Prozessautomatisierung dargestellt werden, die im Zusammenhang mit Geschäftsprozessmanagement häuﬁg mit dem Begriﬀ Workﬂow oder Workﬂow-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. Workﬂow-Management und der Workﬂow-Begriﬀ Die Workﬂow Management Coalition (WfMC) deﬁniert einen Workﬂow 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 WorkﬂowManagement-Systems (WFMS). „[A WFMS is a software system] that deﬁnes, creates and manages the execution of workﬂows through the use of software, running on one or more workﬂow engines, which is able to interpret the process deﬁnition, interact with workﬂow participants and, where required, invoke the use of IT tools and applications“ [Allen, 2001, S. 16]. Der Workﬂow-Begriﬀ hat sich inzwischen weiterentwickelt und ist nicht mehr nur als Weiterreichen von Arbeitsaufgaben zwischen Personen zu verstehen. Workﬂows 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 Workﬂow-Prozessmodelle: WFMS benutzen explizite Repräsentationen von Prozessstrukturen in Form von Workﬂow-Prozessmodellen. Der Kontrollﬂuss wird streng nach den Workﬂow-Prozessmodellen gesteuert, koordiniert und automatisiert ausgeführt [vgl. Weske, 2007, S. 49]. Das Workﬂow-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 ﬁndet sich dabei auf den untersten Detaillierungsebenen eines möglichen Unternehmensprozessmodells wieder.

4.5. Prozessautomatisierung

101

Abgedeckt wird die Modellierung von Workﬂows durch die Modellierungskomponente eines WFMS. Weiterhin besteht ein WFMS aus einer Steuerungskomponente, einer Überwachungskomponente und einer Schnittstellenkomponente. Die Steuerungskomponente dient zur technischen Ablaufsteuerung des Kontrollﬂusses. Die Überwachungskomponente beinhaltet die informationsorientierte Kennzahlenbildung (bezogen nur auf die WorkﬂowProzessmodelle) [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 Ablauﬂogik 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 eﬀektive Unterstützung der automatisierten Prozessabschnitte zu erreichen, indem die menschlichen Arbeitsschritte exakt nach dem Workﬂow-Prozessmodell integriert werden. Hierzu muss ein WFMS um besondere Benutzerschnittstellen erweitert werden, die die anstehenden Aufgaben auﬂisten 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 Workﬂow-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 Workﬂow unterbrochen und der prozessbeteiligten Person eine Aufgabe über die Benutzerschnittstelle zugeteilt. Die jeweiligen Anwendungssystemfunktionen und die teilweise notwendige „Oﬃce Application“ werden ebenfalls zur Verfügung gestellt, wie im Workﬂow-Prozessmodell deﬁniert. 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

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

Abbildung 45: Workﬂow-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 proﬁtieren, sofern der Regelkreis von der Modellierung bis zur Performanzmessung und Ausführung integriert ist. Eine Änderung an Workﬂow-Prozessmodellen lässt sich unmittelbar durch das WFMS umsetzen und die Ergebnisse messen. 4.5.2. Workﬂow-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 Deﬁnition abgeleitet. Dem gegenüber steht die Auﬀassung von [Lehmann, 2008], nach der ein Workﬂow 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 Auﬀassung 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 Workﬂow-Modellierung nicht Teil der Geschäftsprozessmodellierung (beispielsweise Anforderungen nicht Teil des Konventionshandbuchs und die Workﬂow-Modelle nicht Teil des Unternehmensprozessmodells) oder wird WorkﬂowManagement 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 Deﬁnition 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 Einﬂussfaktor 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 Workﬂow-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

4. Geschäftsprozesse und klassisches Geschäftsprozessmanagement

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 Workﬂows 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 eﬃzienten 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 Begriﬀe 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 Deﬁnitionen. Dieser Abschnitt soll einen Überblick über diese geben und die grundlegenden Bestandteile herausarbeiten.

5.1.1. Deﬁnition Ein Großteil der Deﬁnitionen von SOA sind technisch orientiert und beziehen sich auf IT-Systeme im Unternehmen. Hierzu ist es sinnvoll, zunächst die verschiedenen Systembegriﬀe 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 Systembegriﬀe stellt Abbildung 46 in einem Schalenmodell dar. 47

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

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

106

5. Serviceorientierung

Abbildung 46: Diﬀerenzierung der Systembegriﬀe [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, ﬁndet 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 speziﬁsche 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]. Deﬁniert 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 oﬀen zugreifbare Dienste repräsentiert und dadurch eine plattform- und sprachenunabhängige Nutzung und Wiederverwendung ermöglicht“ [Melzer, 2007, S. 11]. Der Zugriﬀ auf Dienste erfolgt nach dem „Find-BindExecute“-Prinzip: Dienste werden mittels eines Katalogs veröﬀentlicht und können darin gefunden werden. Ein passender Service wird auf Grund der bereitgestellten Schnittstellendeﬁnition 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 ﬀ.]: • Abstraktion von der Serviceimplementierung: Die Dienstleistung eines Services wird von dessen Implementierung abstrahiert, es gilt das sogenannte Geheimnisprinzip („information hiding“). • Umfassende, einheitliche Servicespeziﬁkation: 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 Servicespeziﬁkation 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 oﬀener und verbreiteter Industriestandards: Für die verschiedenen Standardisierungen sind entsprechend oﬀene 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

5. Serviceorientierung

• 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 unternehmensspeziﬁsch gewichtet und priorisiert werden. Im Referenzmodell werden diese Architekturprinzipien wieder aufgegriﬀen 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öﬀentlicht 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 ﬀ.] 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 oﬀene 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öﬀentlichen.

5.1. Serviceorientierung und serviceorientierte Architekturen

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 Steﬀen, 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 Ablauﬂogik (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 deﬁniert. 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 Konﬁgurationen 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

5. Serviceorientierung

Abbildung 47: Grundbestandteile einer SOA [nach Krafzig et al., 2005, S. 57] Service Die Begriﬀe 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 ﬀ.]. 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 Zugriﬀ nur auf

5.1. Serviceorientierung und serviceorientierte Architekturen

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 Zugriﬀ 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 Deﬁnition 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 deﬁniert, 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 speziﬁsch 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änenspeziﬁsch 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öﬀentlicht. 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 ﬀ.]. Service-Bus Als einen „Service Bus“ beziehungsweise einen „Enterprise Service Bus (ESB)“ bezeichnet man die logisch zentrale Integrationskomponente einer SOA, die zur

112

5. Serviceorientierung

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 Begriﬀ „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 Deﬁnition 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 schaﬀen. Hierzu ist es notwendig, eine Unterhaltung der betroﬀenen 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].

5.1. Serviceorientierung und serviceorientierte Architekturen

113

• Standardbasierte Integration: Die Integration, wie mit EAI bereits angeführt, soll auf oﬀenen 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 geograﬁschen 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 graﬁsche 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äuﬁg 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

5. Serviceorientierung

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 ﬁnden. 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 Deﬁnition 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 ﬀ.]. 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 oﬀene Entwicklungsfragen geklärt werden, wie die sinnvolle Dekomposition eines Altsystems in Dienste, die Identiﬁkation 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 Systembegriﬀe 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 erschaﬀen, 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 Workﬂows 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äuﬁgsten 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 Speziﬁkationen „Web Service Description Language (WSDL)“, „Simple Object Access Protocol (SOAP)“ sowie „Universal Description, Discovery and Integration (UDDI)“. Ihnen allen ist der Begriﬀ 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 deﬁniert 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 (speciﬁcally 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 Deﬁnition folgt der grundlegenden Beschreibung eines Dienstes. Sie konkretisiert außerdem die Aktionen durch die jeweilige Verwendung der einzelnen Speziﬁkationen (Basiselemente) im Dreieck der Akteure einer SOA: Anbieter, Nutzer, Vermittler. Abbildung 48 lässt sich daher um die Nutzung der Speziﬁkationen 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öﬀentlicht diese WSDL-Schnittstellenbeschreibung seines Dienstes beim Vermittler, der sie in einem Verzeichnis von Diensten veröﬀentlicht. Dieses Verzeichnis ist nach dem UDDI-Standard geordnet. Nachfrager nutzen SOAP-Nachrichten, um entsprechende Dienste im UDDI-Verzeichnis zu ﬁnden. 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].

5.2. Umsetzung von serviceorientierten Architekturen mit Web-Services

117

5.2.1. Web Service Description Language (WSDL) WSDL wurde 2001 erstmals vom W3C durch [Christensen et al., 2001] veröﬀentlicht. Inzwischen liegt es seit Juni 2007 in der Version 2.0 als „W3C Recommendation“ (dort im Sinne einer Speziﬁkation) 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 Zugriﬀs geklärt werden, da Web-Services mittels unterschiedlicher Protokolle genutzt werden können. Zusätzlich muss die Zugriﬀsadresse (im übertragenen Sinne der Standort des Dienstes) beschrieben werden, da Web-Services sich in einer verteilten Umgebung beﬁnden 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 Zugriﬀ ergibt. Zum einen gibt es die Schnittstellenbeschreibung (logischer Zugriﬀ), 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 ﬀ.]: • : Als Types werden Datentypen deﬁniert, die innerhalb von Nachrichten (Messages) verwendet werden.

118

5. Serviceorientierung

• : 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 deﬁniert. 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 konﬁgurieren, 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.

5.2. Umsetzung von serviceorientierten Architekturen mit Web-Services

119

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

SOAP wird durch das W3C speziﬁziert, derzeit ebenfalls als „W3C Recommendation“ (dort im Sinne einer Speziﬁkation) in der Version 1.2 durch [W3C, 2007a] und [W3C,

120

5. Serviceorientierung

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-speziﬁsche 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 ﬀ.], [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 geﬁltert 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

5.2. Umsetzung von serviceorientierten Architekturen mit Web-Services

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 Netzwerkkonﬁgurationen, wesentlich stärkere Einﬂussgröß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öﬀentlichen und Auﬃnden von Web-Services im Netz ermöglicht. Die zugehörige Speziﬁkation 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öﬀentlicht. Die UDDI-Speziﬁkation 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öﬀentlichen 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öﬀentlicht werden [vgl. bspw. Melzer, 2007, S. 132 - 133], [vgl. Burghardt, 2004, S. 62]: • White Pages: Veröﬀentlichung von Informationen über einen Anbieter von WebServices. • Yellow Pages: Kategorisierung von Web-Services aller Anbieter nach Kategorien wie Branche oder Ländercodes.

122

5. Serviceorientierung

• Green Pages: Veröﬀentlichung 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 speziﬁziert 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 ﬁnden 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 betreﬀen. Diese sind nicht explizit Teil des Referenzmodells. Zwei davon sollen jedoch überblickartig dargestellt werden, da sie relevante Teilaspekte einer SOA betreﬀen: 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 ﬀ.]. 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

5.2. Umsetzung von serviceorientierten Architekturen mit Web-Services

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 Ressourcenzugriﬀe 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 ﬀ.]. 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, Speziﬁkationen: • 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 deﬁniert, 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 Speziﬁkation dient der Koordination im Sinne eines Zwei-Phasen-Commits. Hierzu werden drei Koordinationsprotokolle deﬁniert („completion“, „volatile two-phase commit“, „durable two-phase commit“) inklusive der Deﬁnition zugehöriger Zustände und Zustandsübergänge [vgl. OASIS, 2007b]. • WS-Business Activity: WS-Business Activity speziﬁziert 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 betreﬀen 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

5. Serviceorientierung

zukünftige Konzepte hierin zu integrieren [OASIS, 2006f]. Zu diesen möglichen Erweiterungen gehören beispielsweise: • WS-Policy: WS-Policy speziﬁziert ein Framework zur Formulierung von Sicherheitsanforderungen mit zugehöriger Syntax für Web-Service-basierende Systeme [W3C, 2007e]. • WS-Trust: WS-Trust deﬁniert Erweiterungen zu WS-Security zum Austausch sicherheitsrelevanter Daten wie beispielsweise der initiale Schlüsselaustausch [OASIS, 2007e]. • SAML: Die „Security Assertion Markup Language (SAML)“ deﬁniert 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 speziﬁziert oder proprietär. Einen umfassenden Überblick hierzu gibt beispielsweise [Melzer, 2007, S. 187 ﬀ.]. 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 Begriﬀ „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

5. Serviceorientierung

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 ﬀ.] nimmt dies als Grundlage für die Entwicklung eines serviceorientierten Prozessdesgins, Prozesscontrollings und Prozessmanagements analog der Diﬀerenzierung der Systembegriﬀe aus Abbildung 46 (Seite 106): • serviceorientiertes Prozessdesign: Gestaltung serviceorientierter Geschäftsprozesse und des daraus resultierenden Serviceportfolios. • serviceorientiertes Prozesscontrolling: Informationsorientiertes Geschäftsprozesscontrolling zur Identiﬁkation und Entscheidungsunterstützung von Optimierungsansätzen im Serviceportfolio. • serviceorientiertes Prozessmanagement: Planung, Organisation und Kontrolle der Ausgestaltung des Serviceportfolios.

5.3. Serviceorientierte Architekturen und Geschäftsprozessmanagement

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] speziﬁziert worden und ist wie WSDL und SOAP ebenfalls XML-basiert. Durch die Speziﬁzierung 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 Workﬂow-, 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 Speziﬁkation 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 ﬀ.]: • : 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 speziﬁziert (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äuﬁg 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 deﬁniert 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 beﬁnden. 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 speziﬁziert, 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 deﬁniert eine Verzögerung über einen bestimmten Zeitraum, um beispielsweise Aufrufe zu einem späteren oder genau festgelegten Zeitpunkt auszuführen.

5.3. Serviceorientierte Architekturen und Geschäftsprozessmanagement

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 Kontrollﬂuss 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 Kontrollﬂusses. • : Pick wartet auf das Auftreten genau eines Ereignisses aus einer Reihe deﬁnierter, möglicher Ereignisse und führt die dazugehörige Aktivität aus.

130

5. Serviceorientierung

• , , : Diese drei Aktivitäten dienen der Deﬁnition 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 Choreograﬁe bezeichnet [vgl. Melzer, 2007, S. 227 - 228]. Hierfür wird die gleiche BPEL-Syntax wie oben verwendet, die entsprechende Semantik wurde nicht speziﬁziert [vgl. OASIS, 2007a, S. 147]. Hierzu scheinen andere Modellierungssprachen besser geeignet, beispielsweise BPMN [vgl. Weske, 2007, S. 227 ﬀ.]. 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äuﬁg 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 Begriﬀ „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 BPELSpeziﬁkation wurde bereits 2005 von [Kloppmann et al., 2005] diskutiert. Seither wurden die beiden Speziﬁkationen „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öﬀentlichung unter Beteiligung der wichtigsten Softwarehersteller speziﬁziert. Eine Speziﬁzierung durch ein Standardisierungsgremium steht noch aus, beide Dokumentationen wurden hierfür jedoch bereits an ein technisches Komitee bei OASIS übergeben.

5.3. Serviceorientierte Architekturen und Geschäftsprozessmanagement

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 Speziﬁkation 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 Speziﬁkation „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 Speziﬁkation „WS-Human Task“, das Anwendungssystem selbst wird ebenfalls nicht weiter beschrieben.

WS-Human Task Den zentralen Teil der Speziﬁkation „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 ﬀ.]: • : 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

5. Serviceorientierung

• : 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 speziﬁziert 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 Speziﬁkation ein Human-Task vollständig beschrieben und als XML-Dokument gespeichert werden. Neben dem Human-Task werden auch sogenannte Notiﬁcations speziﬁziert. Diese werden benutzt, um Personen und Gruppen über Ereignisse zu informieren, beispielsweise im Eskalationsfall. Eine Notiﬁcation unterscheidet sich von Human-Task nur dadurch, dass sie nicht die Elemente ,

5.3. Serviceorientierte Architekturen und Geschäftsprozessmanagement

133

und besitzt und keine Rückbestätigung bei Erhalt erfolgt [vgl. Agrawal et al., 2007a, S. 39 ﬀ.]. 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 ﬀ.]. 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 Speziﬁkation 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

5. Serviceorientierung

und SOAP [vgl. Agrawal et al., 2007a, S. 66 - 73] als eine Erweiterung der bestehenden Web-Service-Speziﬁkation „WS-Addressing“ speziﬁziert [speziﬁziert in W3C, 2006b]. BPEL4People Die zweite wichtige Speziﬁkation 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 Notiﬁcation (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 ﬀ.]: • : 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 Notiﬁcation. Es wird eines der drei

5.3. Serviceorientierte Architekturen und Geschäftsprozessmanagement

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. Notiﬁcations 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 Speziﬁkationen 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

5. Serviceorientierung

häuﬁg diskutierten Standard BPEL und das weniger beachtete Thema der manuellen Arbeitsschritte (inklusive der Speziﬁkationen BPEL4People und WS-HT) muss das Referenzmodell mit berücksichtigen: BPEL, da es ein zentraler Standard zur Choreograﬁe 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. Ereignisbegriﬀ 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 Begriﬀs 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 Begriﬀe. 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 Begriﬀ „Event“ verwendet. Der englische Begriﬀ ist synonym mit Begriﬀ „Ereignis“, allerdings gibt es fast ausschließlich englischsprachige Literatur zum Thema Ereignisorientierung. Mit dem Begriﬀ „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“).

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

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]

Notiﬁkation 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: Diﬀerenzierung der Eventbegriﬀe • Form: Ein Event hat eine Form, mit Hilfe dessen es dargestellt, übermittelt oder gespeichert wird. Hierzu gehören Attribute und Datenkomponenten. • Signiﬁkanz: 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 speziﬁziert. 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 Signiﬁkanz 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 stattﬁndet. 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 Signiﬁkanz 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, Workﬂow-Systemen, in Netzwerk-Management-Systemen oder in der Oberﬂächensteuerung von Betriebssystemen (Reaktionen auf Mausklicks und Ähnliches) zu ﬁnden [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 ﬁndet immer häuﬁger virtuell in „social networks“ statt [vgl. bspw. Vossen und Hagemann, 2007, S. 241 ﬀ.]. • 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 signiﬁkante 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 Benutzeroberﬂä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 Begriﬀ „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 Begriﬀe „Anwendungssystem“ und „Informationssystem“ siehe Abschnitt 5.1.1.

142

6. Ereignisorientierung

• 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äuﬁg 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 Einﬂuss 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 Schaﬀen 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

6. Ereignisorientierung

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 Speziﬁkation 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 ﬀ.], [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 Seiteneﬀekt) veröffentlicht. • Asynchronität: Der Sender wartet nicht darauf, dass die Gegenseite ein Event verarbeitet hat. Es ﬁndet kein Blocking statt. Die gesamte Kommunikation ist asynchron. • Feingranulare Events: Funktionale Komponenten senden generell Events, so wie sie in den Komponenten auftreten. Eine Aggregation ﬁndet 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 ﬀ.], [Mühl et al., 2006, S. 12]. Daraus ergibt sich eine grundlegende Architektur, wie in Abbildung 60 gezeigt.

6.2. Ereignisorientierte verteilte Systeme

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 NotiﬁkationsServices senden oder empfangen. Der Zugriﬀ auf die Implementierung der Kommunikation ist über diesen Notiﬁkations-Service gekapselt [vgl. Mühl et al., 2006, S. 12]. Es erfolgt kein direkter Zugriﬀ 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öﬀentlicht, 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 speziﬁschen Ansätzen wie beispielsweise der komponentenbasierten Software-Entwicklung o. Ä.

146

6. Ereignisorientierung

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 ﬀ.]. 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

6.2. Ereignisorientierte verteilte Systeme

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 Begriﬀ 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öﬀentlichte 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 Einﬂuss, 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 ﬂexible Anpassungsfähigkeit [vgl. Mühl et al., 2006, S. 132 ﬀ.], ist zusätzlich eine Datentransformation sicherzustellen [vgl. Hohpe und Woolf, 2003, S. 85 ﬀ.]. Events können unterschiedlichsten Typs sein, manchmal sogar unbekannten Typs. Hierfür müssen Interfaces

148

6. Ereignisorientierung

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 ﬀ.]. 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 Workﬂow-Steuerung in einem DEBS ﬁndet sich anhand eines Beispiels im Abschnitt 6.4.2. Berücksichtigung ﬁndet DEBS im Referenzmodell in Zusammenhang mit der Workﬂow-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 geschaﬀen 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 Deﬁnition 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

6. Ereignisorientierung

• 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 beﬁnden 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

6.3. Complex Event Processing (CEP)

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 speziﬁzierte 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 Zugriﬀe auf Datenbanken. Zur Verdeutlichung der vorgestellten Zusammenhänge soll nachfolgendes Beispiel dienen.

152

6. Ereignisorientierung

Abbildung 65 zeigt ein ﬁktives 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 Auﬂegen (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 Auﬂegen des Kunden identiﬁzieren. 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 deﬁniert worden sein. Die Frage aber, wie Event-Patterns grundsätzlich identiﬁziert 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.)

6.3. Complex Event Processing (CEP)

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 Diﬀerenz der Zeitstempel) mindestens drei Zeiteinheiten betragen und alle drei Events müssen sich auf den gleichen Anrufer beziehen. Das vorzeitige Abbrechen durch Auﬂegen 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 speziﬁzierten 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

6. Ereignisorientierung

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 geschaﬀen 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 Deﬁnition 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 ﬀ.]: • 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.

6.3. Complex Event Processing (CEP)

155

EPTS, 2008a, S. 15], [Schulte et al., 2008, S. 2]. Das EPN ist eine implementierungsneutrale Abstraktion aus Sicht des Eventﬂusses. 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 deﬁniert werden, welche Eventtypen es in welchen Hierarchieebenen gibt. Für die Repräsentation und Sequenzierung der Events sind geeignete Datenmodelle zu ﬁnden. Anschließend sind Patterns und ECA-Regeln zu deﬁnieren und auf fachliche Anforderungen auszurichten. Dies setzt eine fundierte Anforderungsanalyse voraus. Werden Events aus bestehenden Anwendungssystemen eingebun-

156

6. Ereignisorientierung

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 speziﬁzieren. Hierbei werden die Kommunikationspfade zwischen den Agenten deﬁniert und geeignete Implementierungen einer Event-Infrastruktur ausgewählt und Entscheidungen bezüglich der Verarbeitungsparadigmen (siehe folgenden Abschnitt) getroﬀen. 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 Speziﬁkation 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 diﬀerenzieren. 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 ﬁnden 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

6.3. Complex Event Processing (CEP)

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 eintreﬀen [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

6. Ereignisorientierung

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

6.3. Complex Event Processing (CEP)

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-Speziﬁkation zum Management verteilter SoftwareKomponenten mittels Web-Services („Web Services Distributed Management: Management Using Web Services (MUWS)“) [speziﬁziert 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 oﬃziellen Standard. MUWS entstand unter dem Einﬂuss einer Speziﬁkation der Firma IBM, die ein „Common Base Event (CBE)“ deﬁnieren [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 Speziﬁkation. 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 deﬁnieren56 . 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

6. Ereignisorientierung

• 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-NotiﬁcationFamilie und der Speziﬁkation WS-Eventing zwei Möglichkeiten vor. WS-Notiﬁcation und WS-Eventing verbinden CEP beziehungsweise DEBS mit dem Bereich SOA, da sie das pub/sub-Paradigma von DEBS mit Hilfe von Web-Services speziﬁzieren. 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]. WSNotiﬁcation besteht aus drei Speziﬁkationen: WS-BaseNotiﬁcation speziﬁziert einen Nachrichtenaustausch zwischen Web-Services, die gegenseitig als Service-Provider auftreten und eine direkte Event-Verbindung aufbauen [vgl. OASIS, 2006c]. WS-BrokeredNotiﬁcation deﬁniert das Web-Service-Interface für einen Event-Broker [vgl. OASIS, 2006d] und WS-Topics deﬁniert einen Mechanismus zur Organisation und Kategorisierung von Interessensgebieten für Subscriptions anhand sogenannter Topics [vgl. OASIS, 2006e]. Der Standard „XML Events“ deﬁniert 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 deﬁniert (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 speziﬁziert werden. Dazu gehört auch eine Untersuchung benötigter Event-Klassen. Insgesamt muss das Referenzmodell alle benötigten Komponenten (Infrastruktur und EPA) speziﬁzieren 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 beeinﬂusst werden: Die Geschäftsprozessautomatisierung im Bereich Workﬂow-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 stattﬁnden und auf Events beruhen [vgl. bspw. Schulte, 2008, S. 4], [vgl. Jobst und Preissler, 2006], [Greiner et al., 2006]. Der BAM-Begriﬀ 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 ﬀ.], in den sich BAM als der Real-Time-Aspekt einer gesamten BI-Lösung einordnen lässt.

162

6. Ereignisorientierung

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 Einﬂüsse: Monitoring relevanter externer Events mit Einﬂuss auf einzelne Geschäftsprozesse beziehungsweise auf den gesamten Geschäftsbetrieb Die ersten beiden Ebenen lassen sich meist durch den Funktionsumfang von WorkﬂowEngines abdecken. Für historische Auswertungen werden häuﬁg BI-Lösungen (vgl. auch Abschnitt 2.3.1) eingesetzt. Spätestens bei der Überwachung externer Einﬂü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, Workﬂow 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

6.4. Eventverarbeitung und Geschäftsprozessmanagement

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 prozessspeziﬁschen 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 geschaﬀen, 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. Workﬂow-Steuerung Bei der Workﬂow-Steuerung geht es um die Steuerung des automatisierten Prozessablaufs. Die Workﬂow-Steuerung in einer serviceorientierten Architektur wurde bereits am konkreten Beispiel von BPEL vorgestellt (vgl. Abschnitt 5.3.1). Eine Event-basierte Workﬂow-

164

6. Ereignisorientierung

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. Beﬁnden sich diese Ereignisse als Events in einem EPN, würden für die WorkﬂowSteuerung 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 Workﬂow-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 Workﬂow-Managements) und CEP miteinander kombiniert werden (siehe Abbildung 70). Das Referenzmodell nach [Ammon et al., 2008] umfasst zwei Modellierungsebenen: In der Designphase werden Workﬂow-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 WorkﬂowModelle anhand von Events überwacht und Kennzahlen sowie Situationen in einem sogenannten „Enterprise Cockpit“ graﬁsch dargestellt. Hierbei werden zwei Spezialistenrollen und ihre Aufgabenfelder identiﬁziert: Prozess-Modellierer und Event-Modellierer. Das oben dargestellte Referenzmodell trennt dabei zwischen einer „konventionellen“ Workﬂow-Steuerung und der Ereignisverarbeitung für das Monitoring. Die Workﬂow-Steuerung erfolgt technisch nicht Event-gesteuert sondern auf Grundlage von Workﬂow-Modellen (beispielsweise BPEL). Events werden im Rahmen des Business-Activity-Monitorings zur

6.4. Eventverarbeitung und Geschäftsprozessmanagement

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 ﬁndet nicht mehr nach dem Find–Bind–Execute-Prinzip statt (Komponenten in DEBS sind unabhängig vom Aufrufer und reagieren nur auf Events). 2. Die Workﬂow-Steuerung erfolgt nicht mehr in einer Zustandsmaschine nach einem Workﬂow-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, identiﬁziert, wodurch die Workﬂow-Steuerung und das BAM zu den entscheiden-

166

6. Ereignisorientierung

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 beﬁnden, 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.

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

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 öﬀentlich, 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 ﬂieß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 identiﬁziert 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 Fachbegriﬀe, 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äftsprozessdeﬁnition 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 deﬁniert. 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 beeinﬂussen, 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 ﬂexibel anzupassen, fehlt auf Grund der Einschränkungen der Prozessautomatisierungen. Zusätzlich triﬀt 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 ﬂexibel 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 schaﬀt 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 Workﬂow 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 betriﬀt 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 Workﬂow 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öﬀentlichungen zu Workﬂows erwähnt, es wird jedoch selten genauer darauf eingegangen. Die zugehörige Speziﬁkation „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äuﬁg eingesetzten Agenten-Desktop-Systeme nicht auf Speziﬁkationen BPEL4People und WS-HT (und die zusätzlich notwendigen Applikationen) ausgerichtet sind.

172

7. Handlungsfelder und Neuansatz

• EDBPM-Referenzmodelle noch unzulänglich für konkrete Umsetzungen: Der Umfang und das Abstraktionsniveau der bisher veröﬀentlichten 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öﬀentlicht. 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-*-Speziﬁkationen 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 empﬁehlt 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 identiﬁzierten 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 aufgegriﬀen, 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 Speziﬁkationen geschehen. Das Geschäftsprozessmanagement bildet die fachlichen, eine service- und 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 graﬁsch 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

7. Handlungsfelder und Neuansatz

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-Deﬁnitionen 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

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

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 Deﬁnition von Service-Typen. Da einzelne Services nicht identiﬁziert 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

7. Handlungsfelder und Neuansatz

ckelt. Es enthält die Deﬁnition 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 deﬁniert. 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 zutreﬀend sind. Für eine abschließende Bewertung (nach Erstellung des Referenzmodells) müssen zudem Evaluierungskriterien aufgestellt werden.

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

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 Referenzmodellbegriﬀs“ 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 unternehmensspeziﬁscher Modelle dienen. Als Begriﬀ 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 ﬀ.]. Idealerweise ist beides zutreﬀend. 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 anwendungsspeziﬁsche Einschränkungen? • Implementierbarkeit: Wie groß ist der Aufwand, die erstellten Teilmodelle und Speziﬁkationen programmtechnisch umzusetzen? • Wiederverwendbarkeit: Wird die Generierung von Modellen, Speziﬁkationen, Programmteilen, Datenstrukturen oder Daten unterstützt, die in anderen Anwendungen wiederverwendet werden können? 59

Werkzeugspeziﬁsche Kriterien wurden weggelassen.

178

7. Handlungsfelder und Neuansatz

• Modularität: Wird ein modularer Systemaufbau unterstützt, der lokale Änderungen erlaubt, ohne andere Teile zu beeinﬂussen? 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 (Eﬀektivität des Modells) und Veriﬁzierbarkeit (Eﬃzienz 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 deﬁniert. In der zweiten Phase werden die generischen Anwendungsdomänen in einem Contact-Center identiﬁziert. Sie dienen gemeinsam mit den identiﬁzierten Zielen als Grundlage für die dritte Phase, die Identiﬁkation 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 schaﬀen. Die letzte Phase bildet die umsetzungsrelevante Architekturgestaltung, die auch die Anwendung bestehender Standards beinhaltet. Die nachfolgende Abbildung 73 stellt die aufeinanderfolgenden Phasen nochmals graﬁsch dar.

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

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

180

8. Automatisierung durch Serviceorientierung

8.2. Identiﬁkation von Zielen und Architekturprinzipien Bevor Ziele identiﬁziert 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 identiﬁzierten Geschäftsprozessen können diese nicht

8.2. Identiﬁkation 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 Einﬂussfaktoren auf die Ausführungskosten (die Personalkosten) positiv beeinﬂusst 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 betroﬀen, 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 Einﬂussfaktoren 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 Einﬂussfaktoren bestimmt. Diese können wie folgt formuliert werden: „Implementierung einer durchgängigen Kundenorientierung“ (als Forderung der Kundenorientierung) und „Wei-

182

8. Automatisierung durch Serviceorientierung

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. Meﬀert et al., 2008, S. 860]. • Entkopplung der Prozess- und Multikanal-Steuerung: Häuﬁg 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 Zugriﬀe auf das eine System sind jeweils im anderen implementiert. Ein Vorgang der Kommunikationssteuerung kann somit zwangsläuﬁg 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 ﬂexible 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 geschaﬀen. 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. Identiﬁkation 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. Meﬀert 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 ﬀ.]. • 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 ﬂexible, reaktive IT-Echtzeit-Lösungen notwendig (vgl. Abschnitt 3.2.1). Hierbei spielen die Diﬀerenzierung 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) ﬂexibel 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-speziﬁsche 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 Identiﬁkation der Service-Typen die wichtigsten Architekturprinzipien für Contact-Center herauszuarbeiten. Dabei wird der Einﬂuss 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 Einﬂuss 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 Einﬂuss 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

8. Automatisierung durch Serviceorientierung

Abbildung 75: Priorisierung der Architekturprinzipien für die Service-Typen-Deﬁnition

• mittlerer Einﬂuss auf Zielerreichung: Umfassende, einheitliche Servicespeziﬁkation (3), Verwendung oﬀener und verbreiteter Industriestandards (3), Technische Schnittstellenstandardisierung (3)

• geringer Einﬂuss 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 Einﬂussfaktor für die Identiﬁkation 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 ﬀ.]. 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 Identiﬁkation 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: • Unternehmensbereichsspeziﬁsche Domänen: Darunter gliedern sich Funktionen und Daten zur Unterstützung speziﬁscher 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-Identiﬁkation 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 „Fachbegriﬀ“ 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 unternehmensbereichsspeziﬁschen 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 identiﬁziert 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 Proﬁl. 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 „Fachbegriﬀ“ und „dokumentiertes Wissen“ lassen eine weitere Anwendungsdomäne erkennen, die unter dem Begriﬀ 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 ﬁnden. 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 Benutzeroberﬂäche dienen. Sie ﬁnden in großen Contact-Centern häuﬁg 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äuﬁg 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. Identiﬁkation 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 Benutzeroberﬂäche bedürfen.

8.4. Identiﬁkation von Service-Typen In den folgenden Abschnitten wird zunächst der Beitrag der Identiﬁkation von ServiceTypen zur übergeordneten Zielsetzung geklärt. Daran anschließend werden die identiﬁzierten 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 Identiﬁkation einzelner Services nicht ohne einen unternehmens- und projektspeziﬁschen Kontext möglich ist, werden Service-Typen identiﬁziert, 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 diﬀerenzierte Implementierungsaspekte (vor allem Aspekte der Integration) von Bedeutung. Diese werden in den

190

8. Automatisierung durch Serviceorientierung

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 projektspeziﬁschen Anforderungen und Gegebenheiten angepasst werden müssen. Service-Typen dienen so beispielsweise der Vorbereitung von Pﬂichtenheften und Architekturplanungen für konkrete Umsetzungen von Services. Fachliche Aspekte (vor allem die Vorbereitung und die Methodik zur Serviceidentiﬁkation 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 Workﬂows 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 identiﬁzierten Service-Typen im Überblick:

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

8.4. Identiﬁkation von Service-Typen

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 identiﬁzieren (siehe Tabelle 6).

192

8. Automatisierung durch Serviceorientierung

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 • Auﬂistung zur Bereitstellung benötigter Anwendungssysteme am Arbeitsplatz des Agenten • Parameter zur Oberﬂächensteuerung obiger Anwendungssysteme zum vorab Laden, Fokussieren oder Befüllen der darin verwendeten Bildschirmmasken (um unnötige Navigation zum Zielfenster zu vermeiden) • Identiﬁkation benötigter Daten (wie zum Beispiel die Kundennummer) und Business-Objekte • Navigation in Verzeichnisse und Dateien (zum Öﬀnen, Erstellen, Suchen und Speichern von Dokumenten) • Bereitstellung von Wissen in Systemen, mit denen der Agent Wissen im weitesten Sinne abrufen kann. Hierunter fallen beispielsweise: – ﬁrmeneigene Wikis (etwa zur Erklärung von Fachbegriﬀen) – Wissensportale, Internet, Intranet, eigene Suchmaschinen (eventuell mit den entsprechenden Suchbegriﬀen 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

8.4. Identiﬁkation von Service-Typen

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 Zugriﬀ auf die Implementierung kann durch Mandanten verweigert werden (nur Benutzeroberﬂäche oder Clients verfügbar). Finanzielle Aspekte können ebenfalls gegen eine Integration mittels Services sprechen (hoher Aufwand oder geringe Häuﬁgkeit). Einen weiteren Grund können Prozessabläufe darstellen, die bereits an der Oberﬂä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 Speziﬁkation ist „WS-Human Task“ (siehe Abschnitt 5.3.2). Für die Umsetzung empﬁehlt sich eine Verwendung dieser Speziﬁkation, 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 diﬀerenziertere 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

8. Automatisierung durch Serviceorientierung

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 ﬀ.]. 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äuﬁg 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 Identiﬁkation der Inhalte über entsprechende „Uniform Resource Identiﬁer (URI)“ [vgl. Berners-Lee et al., 2005] sinnvoll. URIs gehören zu den notwendigen Parametern

8.4. Identiﬁkation von Service-Typen

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öﬀnet 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

8. Automatisierung durch Serviceorientierung

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 oﬀene 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 Herstellerspeziﬁkationen 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

8.4. Identiﬁkation von Service-Typen

197

darin, dass der Umfang der in SIP speziﬁzierten 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 betriﬀt 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

8. Automatisierung durch Serviceorientierung

Implementierungs- und Integrationsaspekte Hier sind keine Besonderheiten zu nennen. Es ﬁndet 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äuﬁgsten 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 identiﬁzieren. Nachfolgende Tabelle 7 beschreibt diese genauer:

8.4. Identiﬁkation von Service-Typen

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 speziﬁziertes 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

8. Automatisierung durch Serviceorientierung

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 projektspeziﬁsch. 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 treﬀen 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 Eingriﬀ 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 beﬁndet 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 Serviceidentiﬁkation dienen, kann auch die Servicegranularität entsprechend gewählt werden.

202

8. Automatisierung durch Serviceorientierung

• 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 Servicespeziﬁkation: Durch den Zusammenhang zwischen den Prozessmodellen und den Services, die diese umsetzen, speziﬁziert das Prozessmodell einheitlich und umfassend die Fachlichkeit und somit den Inhalt von Services. • Verwendung oﬀener 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 Identiﬁkation von Services und deren Granularität. Konkrete Services können nur in konkreten Projekten und Unternehmen identiﬁziert 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 Deﬁnition 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.

8.5. Entwicklung eines Contact-Center-Prozessmodells

203

• Anlagen: Die nachfolgenden Abschnitte werden durch Graﬁken 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 – speziﬁscher 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 Oberbegriﬀe gemeint, wie sich die Wertschöpfung durch „Kunde betreuen“ genauer zusammensetzt.

204

8. Automatisierung durch Serviceorientierung

3. Hauptprozess: Ein Hauptprozess ist eine „Kette homogener Aktivitäten, die demselben Kosteneinﬂussfaktor 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 identiﬁziert, Inhalte werden nicht modelliert. Ab der Hierarchie der Geschäftsprozesse ﬁndet eine Modellierung (Darstellung) der Inhalte statt. Mit jeder weiteren untergeordneten Hierarchiestufe ﬁndet 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 ﬁnden und speziﬁzieren. 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 ﬁndet 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 identiﬁzierten Geschäftsfeld(er), Kernprozesse, Hauptprozesse und Geschäftsprozesse namentlich genannt und den Hierarchieebenen zugeordnet. Sie dient letztendlich dem Finden von

8.5. Entwicklung eines Contact-Center-Prozessmodells

205

Geschäftsprozessen (Identiﬁkation 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 identiﬁzierbar 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

8. Automatisierung durch Serviceorientierung

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).

8.5. Entwicklung eines Contact-Center-Prozessmodells

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. Automatisierung durch Serviceorientierung

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.

8.5. Entwicklung eines Contact-Center-Prozessmodells

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

8. Automatisierung durch Serviceorientierung

Objekt

Verwendung

Objekttyp Regel • Regeln speziﬁzieren Beziehungen zwischen Ereignissen und Funktionen beziehungsweise Automationen. • UND nach Ereignissen: alle Ereignisse müssen eintreten; UND vor Funktionen: Funktionen ﬁnden 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 Identiﬁkation 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).

8.5. Entwicklung eines Contact-Center-Prozessmodells

211

• Multiple Ereignisse: Ein Geschäftsprozess beziehungsweise seine Teilprozesse können von verschiedenen Ereignissen ausgelöst werden (am Beispiel von Startereignissen etwa diﬀerenziert 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 identiﬁziert (siehe unten). • Stellenproﬁle: Tätigkeiten aus Stellenbeschreibungen oder Stellenproﬁlen 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 Einﬂuss auf die Abfolge (Anordnung) der Teilprozesse untereinander, nicht aber auf deren innere Abfolge und Struktur. Teilprozesse sind entsprechend so zu identiﬁzieren 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 ﬁnden nicht verdeckt innerhalb von Teilprozessen statt. Entsprechend sind einzelne Teilprozesse im Geschäftsprozess zu unterscheiden.

212

8. Automatisierung durch Serviceorientierung

• 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 Oberﬂä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“)?

8.5. Entwicklung eines Contact-Center-Prozessmodells

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

8. Automatisierung durch Serviceorientierung

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

8.5. Entwicklung eines Contact-Center-Prozessmodells

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

8. Automatisierung durch Serviceorientierung

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, ﬁrmeninterne 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.

8.5. Entwicklung eines Contact-Center-Prozessmodells

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 deﬁnieren sich innerhalb einer Applikationsdomäne. Entscheidend ist hier die Fachlichkeit im jeweiligen Unternehmen. • Manuelle Tätigkeiten: Bei der Identiﬁkation 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) ﬁnden, 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 identiﬁzierten Sub-Domänen der Applikationsdomäne Kernprozesse dienen als wichtiger Anhaltspunkt hierfür. Ein Teilprozess speziﬁziert Aktivitäten, indem sie mit Hilfe der Objekte Interaktion und Automation benannt werden. Eine weitere Detaillierung ﬁndet im Rahmen des ContactCenter-Prozessmodells nicht statt, da aus fachlicher Sicht eine ausreichende Detaillierungstiefe für die Serviceidentiﬁkation 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 betreﬀen 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 Identiﬁkation der Service-Typen betrachtet. Es bleibt nun die Frage, wie die identiﬁzierten 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 deﬁnierten 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 Pﬂichtenhefts 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 speziﬁzieren 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

8. Automatisierung durch Serviceorientierung

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 treﬀen. Da dem Architekturprinzip „Verwendung oﬀener 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

8. Automatisierung durch Serviceorientierung

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“

Speziﬁkation 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-Speziﬁkation wurden unter anderem Tasks speziﬁziert, die lokal einem BPEL-Prozess zugeordnet werden. Darüber hinaus wird die Speziﬁkation von Rollen und eine Zuordnung von Tasks zu Rollen (Bearbeiter) innerhalb eines BPELModells vorgesehen [vgl. Agrawal et al., 2007b, S. 3, 10 - 15]. Die Workﬂow-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 Identiﬁkation 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 speziﬁzierte 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 speziﬁziert. 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

8. Automatisierung durch Serviceorientierung

Objekt

WS-HTElement bzw. Attribut

Mögliche Attribute im Prozessmodell

Verwendung

Interaktion

„TaskIdentiﬁkation“ „Beschreibung“

Name (Bezeichnung der Interaktion) und Beschreibung werden als Kurzbezeichnung (Überschrift) und zur detaillierten Aufgabenbeschreibung für den Agenten genutzt. Die Task-Identiﬁkation 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“

Identiﬁkation des Anwendungssystems, das den Fokus auf dem Agenten-Desktop bekommt.

Maske

neues Attribut: Maske

„Masken-Name“

Identiﬁkation der Maske des Anwendungssystems, die aufgerufen wird.

Skript

neues Attribut: Skript

„Skript“

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

Elektronisches Dokument

neues Attribut: ElDokument

„Elektronisches Dokument“

Identiﬁkation eines elektronischen Dokuments mittels einer URI (zum Beispiel „http://ﬁrma.de/wiki/ArbeitsanweisungX“, „ﬁle:///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 ﬁndet 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

8. Automatisierung durch Serviceorientierung

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 projektspeziﬁschen Umsetzung zu klären. 8.6.2. Architektur und Komponenten Aus Umsetzungsperspektive wurden bisher Service-Typen mit Operationen und Parametern identiﬁziert. Mit Hilfe von Prozessmodellen wurde eine konkrete Serviceidentiﬁkation 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 Speciﬁc 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 ﬀ.] 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 speziﬁziert (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 Workﬂow-Engine (BPEL-Engine) gesteuert. Dies ist zurückzuführen auf eine geringere Änderungshäuﬁgkeit innerhalb der Teilprozesse (bedingt durch die Granularität) und einen geringen Einﬂuss 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 deﬁniert). • 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 identiﬁziert. Sie decken außerdem speziﬁsche 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 projektspeziﬁsch erstellt. Die Besonderheiten beim Agenten-Service beziehen sich in erster Linie auf den Modus der Zustellung eines Tasks. Üblicherweise erfolgt in Workﬂow-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äuﬁg als „Pull-Modus“ bezeichnet und ist beispielsweise implizit in den Speziﬁkationen 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 speziﬁzierten 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“ identiﬁzierte 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 speziﬁziert) nicht über eine Benutzeroberﬂä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 speziﬁziert. Üblicherweise erfolgt das Annehmen eines Tasks nach dem „Pull-Modus“. Hierfür würden Benutzer über den Task-List-Client als Benutzeroberﬂä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-DesktopOberﬂä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 Benutzeroberﬂä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 vordeﬁnierten 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-Oberﬂä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 Einﬂuss 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 WorkﬂowSteuerung (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

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

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) speziﬁziert. 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 unternehmensspeziﬁsche 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 Schaﬀung der Event-technischen Grundlagen vorangestellt. Zusätzlich wurde die Erweiterung des Contact-Center-Prozessmodells um die Belange der Ereignisverarbeitung angefügt. 64

Der Begriﬀ „Agents“ ist nicht zu verwechseln mit den Agenten (Sachbearbeitern) eines Contact-Centers. EPA sind Software-Komponenten (siehe Deﬁnition 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 schaﬀen. Dies betriﬀt 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 geschaﬀen 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 Schaﬀung einer entsprechenden Referenzarchitektur. Ergebnisse daraus wurden bisher noch nicht veröﬀentlicht. Eine Diskussion des aktuellen Standes ﬁndet 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 Identiﬁkation 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 identiﬁziert wurden, gibt es nur wenige Unterschiede. Deshalb gelten grundsätzlich dieselben Architekturprinzipien. Die Besonderheiten und Unterschiede bei der Identiﬁkation 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 speziﬁsch 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 oﬀener 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.

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

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. Schaﬀung 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 Deﬁnition darauf spezialisiert, Events über Hierarchien zu verarbeiten und aufgedeckte Zustände durch ein neues, komplexes Event mitzuteilen. Dem gegenüber stehen bewährte Workﬂow-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 Workﬂow modelliert, der Workﬂow muss entsprechend auf das komplexe Event reagieren. Bei Änderungen des CEP-Patterns muss der Workﬂow 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 Workﬂowund 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-speziﬁsche Aufteilung ﬁndet 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 oﬀener 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

9. Steuerung und Überwachung durch Ereignisorientierung

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 Notiﬁcation-Service, realisiert. Die fachliche Schnittstellenstandardisierung ergibt sich dabei aus der Beschreibung von DEBS. Der Notiﬁcation-Service ist zentraler Kommunikationspartner der EPA. Im Rahmen der Event-Zustellung übernimmt er den Web-Service-Aufruf der EPA. Im Gegenzug werden über den Notiﬁcation-Service Events der EPA veröﬀentlicht 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 Notiﬁcation-Service Die Zusammenhänge zeigt Abbildung 91. Die genauere Funktionsweise des NotiﬁcationService 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 Notiﬁcation-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. Notiﬁcation-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 „Notiﬁcation-Service“ wurde in Abbildung 61 (Seite 145) skizziert.

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

239

Nach diesem Muster enthält das Referenzmodell ebenfalls einen Notiﬁcation-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 Notiﬁcation-Services werden Teile der Speziﬁkation 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 speziﬁziert, 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 schaﬀen. Aus diesem Grund erbt der Notiﬁcation-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öﬀentlicht 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 Notiﬁcation-Service als Klassendiagramm). In der Konsequenz bedeutet dies, dass alle EPA, die im Rahmen dieses Referenzmodells identiﬁziert werden, Services sind und entsprechende Web-Service-Schnittstellen implementieren, über die Events zugestellt werden.

Abbildung 92: Operationen und Standardnutzung des Notiﬁcation-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 ﬁndet 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 Notiﬁcation-Service innerhalb der bestehenden SOA-Architektur des Referenzmo-

240

9. Steuerung und Überwachung durch Ereignisorientierung

dells implementiert wird, wird auch der ESB genutzt. Der ESB stellt den NotiﬁcationService 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 Notiﬁcation-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 Notiﬁcation-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).

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

241

Abbildung 94: Event-Darstellung: Zusammenhänge zwischen Prozessmodell und Event im Klassendiagramm nutzbaren oﬃziellen 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 Speziﬁkationen zum „Management Using Web-Services (MUWS)“ [vgl. OASIS, 2006a,b] dienen. Die oben genannten Speziﬁkationen CBE und MUWS sind hilfreich, um notwendige und allgemeine Event-Attribute und -Elemente zu deﬁnieren (Metadaten). Dabei müssen die Event-Aspekte „Form“ (erfüllt durch die Darstellung mittels XML-Schemata), „Signiﬁkanz“ und „Relativität“ [Luckham, 2002, Etzion, 2007] berücksichtigt werden. Entsprechend ergeben sich mindestens folgende Attribute und Elemente: • Version: Version der Event-Speziﬁkation zur Unterscheidung zwischen unterschiedlichen Versionsständen. • Instanz: Lokale und/oder globale Instanz-ID des Events, um es eindeutig zu identiﬁzieren (Primärschlüssel).

242

9. Steuerung und Überwachung durch Ereignisorientierung

• 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 deﬁniert 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. • Zustandsklassiﬁzierung: Klassiﬁzierung (Beschreibung einer Semantik) der beobachteten Zustände von Situationen, meist bei der Überwachung von Systemen (zum Beispiel genaue Abgrenzung und Deﬁnition 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 „Signiﬁkanz“). Die Nachricht besteht aus einem beliebigen XML-Dokument, wofür ein XML-Schema deﬁniert sein muss (Nachrichten-Typ). Der Nachrichten-Typ bildet die Event-Klasse beziehungsweise den Event-Typ, das heißt eine Klassiﬁkation 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 deﬁnieren. 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.

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

243

Abbildung 95: Event-Attribute und -Elemente mit Verbindung zum Prozess-Repository Eine Referenzierung schaﬀt 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 empﬁehlt 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 Deﬁnition 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 Deﬁnition 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 Deﬁnition 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 Einﬂuss auf die Konformität mit MUWS. Hierfür ist lediglich die XMLSerialisierung entscheidend, diese muss der Schemadeﬁnition entsprechen.

244

9. Steuerung und Überwachung durch Ereignisorientierung

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 stattﬁndet (siehe Deﬁnition in Abschnitt 6.3.2). Für die Identiﬁkation 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 Speziﬁkation zu BPEL sieht dies nicht vor [vgl. OASIS, 2007a], entsprechende Erweiterungen sind (noch) nicht von anerkannten Gremien speziﬁziert 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 ﬁndet ein Abonnement der prozessauslösenden Events über die Operation SubscribeOp des Notiﬁcation-Services statt. Dies ist ein (halb)automatischer Schritt, der spätestens mit dem Deployment eines BPEL-Prozesses (Teilprozess) stattﬁnden 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

9. Steuerung und Überwachung durch Ereignisorientierung

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 Notiﬁcation-Services aufgerufen. 3. Zustellung des Events: Der Notiﬁcation-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 deﬁniert, die gleichzeitig als WS-Addressing-Element in 0. über das Abonnement mittels der SubscribeMsg für die Zustellung beim Notiﬁcation-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 ﬁndet 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 Workﬂow-Steuerung anhand eines BPEL-Modells stattﬁndet (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 ﬁndet dies über denselben partnerLink statt, über den auch der receive-Aufruf stattgefunden hat. Nachdem der Aufruf durch den Notiﬁcation-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).

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

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

9. Steuerung und Überwachung durch Ereignisorientierung

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 Notiﬁcation-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 identiﬁzieren, die im Sinne der Signiﬁkanz 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 betreﬀen, 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 Workﬂow-Steuerung zur Verfügung stehen, der Aufruf erfolgt über das Agent-Desktop-System

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

249

XML-Protokoll für CTI-Umgebungen. Darin sind folgende Event-Speziﬁkationen 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, Logoﬀ) [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) deﬁniert 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 Speziﬁkation recherchiert werden. Aus diesem Grund werden in der nachfolgenden Tabelle 14 die notwendigen Elemente deﬁniert und beschrieben. In konkreten Umsetzungsprojekten können diese Elemente angepasst und erweitert werden. Anschließend sind XML-Schemata zu deﬁnieren. Element

Beschreibung

Prozess-ID

Eindeutige Identiﬁkation der Prozessinstanz

Kontakt-ID

Eindeutige Identiﬁkation des zugehörigen Kontakts (Anruf, E-Mail, Fax)

Mögliche Werte

250

9. Steuerung und Überwachung durch Ereignisorientierung

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 Oﬃce), 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)

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

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äuﬁge Bereiche zusammenzuführen: Auf der einen Seite gibt es die klassische Ablaufsteuerung eines Contact-Centers mit den wichtigsten kanalspeziﬁschen 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

9. Steuerung und Überwachung durch Ereignisorientierung

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)

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

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öﬀentlicht (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 (Notiﬁcation-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 Deﬁnition des EPN getroﬀen werden muss.

254

9. Steuerung und Überwachung durch Ereignisorientierung

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 Speziﬁkation 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 deﬁnieren 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 (Signiﬁ- 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

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

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 Benutzeroberﬂäche zur graﬁschen 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 Zugriﬀ auf die Reports und Kennzahlen erfolgt entsprechend rollenbasiert. Häuﬁg ﬁndet eine technische Umsetzung mit Hilfe von Portal-Plattformen (Web-basiert) statt. Einen möglichen Standard zur Umsetzung bietet beispielsweise die Speziﬁkation von [Abdelnur und Hepper, 2003].

256

9. Steuerung und Überwachung durch Ereignisorientierung

• 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 ﬁndet 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 ﬁndet 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 ﬀ.] (Abschnitt 5.2.2) und

258

9. Steuerung und Überwachung durch Ereignisorientierung

[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 beﬁnden 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 treﬀen. 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 treﬀen. 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 beﬁnden und entsprechende Performanzüberlegungen nicht zwingend relevant sind, ﬁndet 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

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

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 ﬁndet 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öﬀentlicht wird. Dieser Stream ist zunächst nur innerhalb des EPA (in diesem Fall innerhalb des Coral8Projekts) sichtbar. Eine Veröﬀentlichung ﬁndet dann statt, sobald der Stream über den Notiﬁcation-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

9. Steuerung und Überwachung durch Ereignisorientierung

WHERE

W.Fachliches_Prozessmodell = G.Fachliches_Prozessmodell AND W.Zahlenwert ) bis zum Eintreﬀen 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. Schaﬀung 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 Einﬂüsse. Das technische Aufdecken externer Einﬂüsse geschieht mittels CEP durch dedizierte EPA mit entsprechenden ECA-Patterns und einer Erweiterung des Hierarchiemodells. Am Ende dessen steht die Veröﬀentlichung 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 ﬁndet dabei die automatisierte Ausnahmebehandlung und gezielte Anpassung bei zustandsbezogener Kennzahlenverletzung mit Hilfe von Workﬂows [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 aufgegriﬀen. Mit dem bisher dargestellten EPN werden Kennzahlen erzeugt, die mit Hilfe ihrer Metriken

262

9. Steuerung und Überwachung durch Ereignisorientierung

den Zustand der automatisierten Geschäftsprozesse (und somit den Zustand der Prozessorganisation) beschreiben. Zum Performance-Netzwerk fehlt noch der regelnde RückEinﬂuss 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 ﬀ.]. 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 geschaﬀen. 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öﬀentlichung eines BAM-Events und keinerlei andere Reaktion (kein Aufruf eines Workﬂows). 2. ECA-Pattern-Erkenner::neues_Startereignis: Ein weiterer dedizierter EPA übernimmt die Entscheidung, welche Variante eines Teilprozesses gestartet wird. Diese Entscheidung ist von zwei Einﬂussfaktoren abhängig: dem Eintreten des eigentlichen Start-Events (Startereignis oder Ergebnis eines vorgelagerten Teilprozesses) und dem Vorhanden- oder Nichtvorhandensein der beeinﬂussenden Situation von oben. Dies wird in einem entsprechenden Pattern oder einer Query festgelegt. Als

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

263

Abbildung 104: Prozessautomatisierung innerhalb eines Performance-Netzwerks Ergebnis erfolgt die Veröﬀentlichung 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öﬀentlicht. Dieses wird durch den 2. EPA registriert und ein entsprechend angepasstes Prozess-Event wird veröﬀentlicht, das automatisch den Teilprozess „Bestellung automatisch über IVR erfassen TP“ startet. Die Dynamisierung der Geschäftsprozesssteuerung ﬁndet 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

9. Steuerung und Überwachung durch Ereignisorientierung

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 identiﬁziert. 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 schaﬀt. 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 schaﬀt 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 gepﬂegt.

266

9. Steuerung und Überwachung durch Ereignisorientierung

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“ speziﬁziert. 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

9.5. Erweiterung des Prozessmodells um Aspekte der Ereignisverarbeitung

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 Notiﬁcation-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 ﬀ.], wobei in diesem Fall nicht auf bestehende Modelltypen zurückgegriﬀen 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 geschaﬀen. 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

9. Steuerung und Überwachung durch Ereignisorientierung

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, ﬁndet entsprechend seinen Ausdruck im Prozessmodell mit der durchgängigen Verwendung des Objekttyps Ereignis. Ereignisse bilden die Verbindung zwischen der Eventverarbeitung in den EPA

9.5. Erweiterung des Prozessmodells um Aspekte der Ereignisverarbeitung

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 Schaﬀung 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 Pﬂichtenhefts ab, etwa bei der Festlegung der Service-Granularität. Mit den fachlichen Modellen werden Verbindungen geschaﬀen zu den zugehörigen technischen Modellen (UML-Diagramme, BPEL-Modelle, EPL-Modelle) und Systemen. Diese bleiben weiterhin in der Hand der IT, sie ﬁnden 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 ﬁndet 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 ﬁnden 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 Einﬂussgröß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 identiﬁziert. 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 Einﬂussgröß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ückgegriﬀen 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

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

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 Einﬂussfaktoren identiﬁziert. 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 Einﬂuss der Fachabteilungen auf die Umsetzung und der negative Einﬂuss 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 Einﬂussfaktoren 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 Identiﬁkation von Services wurden Applikationsdomänen identiﬁziert. 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 deﬁniert. 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 Workﬂow-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 Speziﬁkation 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 deﬁniert 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-*-Speziﬁkationen 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 geschaﬀen werden. Als wesentliche Komponenten wurden die Event-Verarbeitung, der Event-Transport und die Event-Reaktion deﬁniert und ihre auf SOA-Standards basierende Interaktion festgelegt. Für den Event-Transport wurde der Notiﬁcation-Service auf Basis des pub/sub-Kommunikationsparadigmas eingeführt. Er kapselt den Zugriﬀ 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 deﬁniert. 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-speziﬁsche Elemente wurden Klassen von Event-Processing-Agents (EPA) deﬁniert: 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 situationsspeziﬁschen Attribute eines Events (Nutzlast) wurden entsprechend der Anwendungsgebiete drei Event-Typen identiﬁziert: 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-

10.2. Ergebnisse und Bewertung

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 ﬁndet 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 Deﬁnition) 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 Deﬁnition 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äuﬁgkeit pro Jahr“ (Einheit Stück) und „Aufwand“ (Einheit Mitarbeiterjahre) zugeordnet. Eine ABC-Analyse [nach Jung, 2006b, S. 324 ﬀ.] 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-Identiﬁkation 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 Schaﬀung 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 Pﬂichtenheft 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

10.2. Ergebnisse und Bewertung

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 identiﬁziert und abstrakte Klassen für Services, Events und EPA deﬁniert. 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 Eﬀektivität ist grundsätzlich durch die Abdeckung der Anforderungen gegeben. Die Eﬃzienz 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 betroﬀen 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. Wallraﬀ, 2007] keinen Einﬂuss, 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ösungsﬁndung 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 Speziﬁkationen 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 Speziﬁka bleibt außerdem die Frage zu wenig berücksichtigt, inwieweit Event-Patterns identiﬁziert 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öﬀentlicht 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 ﬁnden 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äuﬁg 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 betriﬀt 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 Speciﬁcation Version 1.0. Java Speciﬁcation Request, Java Community Process, 7. Oktober 2003. URL http://jcp.org/en/jsr/summary?id=168. Zugriﬀ am 17.06.2009. Ferri Abolhassan. Vom CIO zum Chief Process Oﬃcer. 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. Zugriﬀ 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. Zugriﬀ 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. Zugriﬀ 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äﬀer-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. Workﬂow: An Introduction, 6. März 2001. URL http://wfmc.org/Specifications-Working-Documents/General. Zugriﬀ am 27.01.2009. Thomas Allweyer. Geschäftsprozessmanagement – Strategie, Entwurf, Implementierung, Controlling. W3L, Herdecke und Bochum, 1. korrigierte Auﬂage, 2005. Thomas Allweyer. BPMN auf gut Deutsch, 16. April http://kurze-prozesse.de/?pageid=78. Zugriﬀ 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 Auﬂage, 2005. Amadeus. About Amadeus, 2009. URL http://www.amadeus.com/amadeus/x5034.xml. Zugriﬀ am 06.05.2009. Amazon. AmazonWebService.wsdl, 2009. URL http://soap.amazon.com/schemas2/ AmazonWebServices.wsdl. Zugriﬀ 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 Wolﬀ. 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. Zugriﬀ 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/. Zugriﬀ 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 Auﬂage, 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 Auﬂage, 2005. Jörg Becker, Patrick Delfmann und Tobias Rieke. Referenzmodellierung – Perspektiven für die eﬃziente Gestaltung von Softwaresystemen. In: Jörg Becker, Patrick Delfmann und Tobias Rieke (Hrsg.), Eﬃziente Softwareentwicklung mit Referenzmodellen, S. 1 – 9. Physica-Verlag, 2007. Berkeley. Information and Service Design, 2008. http://isd.ischool.berkeley.edu/. Zugriﬀ 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 Identiﬁer (URI): Generic Syntax. IETF Standard (RFC 3986), The Internet Society, Januar 2005. URL http://tools.ietf.org/html/rfc3986. Zugriﬀ 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 öﬀnen 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. Auﬂage, 2006. Rolf Bühner. Betriebswirtschaftliche Organisationslehre. Oldenbourg, München und Wien, 10., bearbeitete Auﬂage, 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 Auﬂage, 2004. Jason Bloomberg. When Not to Use an SOA. zapthink, 16. Februar 2004. URL http://www.zapthink.com/report.html?id=ZAPFLASH-02162004. Zugriﬀ 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 eﬃziente 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, Jeﬀrey 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. Zugriﬀ am 27.03.2009. Steen Brahe und Kjeld Schmidt. The story of a working workﬂow 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. Auﬂage, 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. Auﬂage, 2006b. Manfred Bruhn. Marketing, Grundlagen für Studium und Praxis. Gabler, Wiesbaden, 8., überarbeitete Auﬂage, 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. Auﬂage, 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 Workﬂow. 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 Auﬂage, 2008. CCL. Continous Computation Language (CCL). Produkt-Website, Coral8, Inc., 2009. URL http://www.coral8.com/products/ccl.html. Zugriﬀ 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. Zugriﬀ 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. Zugriﬀ am 10.02.2009. Brad Cleveland, Julia Mayben und Günter Greﬀ. Call Center Management – Leitfaden für Aufbau, Organisation und Fürhung von Teleservicecentern. Gabler, Wiesbaden, 2. Auﬂage, 2002. Adolf G. Coenenberg, Thomas M. Fischer und Thomas Günther. Kostenrechnung und Kostenanalyse. Schäﬀer-Poeschel, Stuttgart, 6., überarbeitete und erweiterte Auﬂage, 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. Proﬁting 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. Auﬂage, 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. Zugriﬀ 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. Workﬂowsysteme 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. Auﬂage, 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. Zugriﬀ 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. Zugriﬀ 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/. Zugriﬀ 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. Zugriﬀ 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 Auﬂage, 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 Auﬂage, 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. Workﬂows, 7. Dezember 2004. http://www.bpm-netzwerk.de/content/articles. Zugriﬀ am 27.01.2009.

URL

Jakob Freund und Klaus Götzer. Vom Geschäftsprozess zum Workﬂow. Hanser, München, 2008. Andreas Gadatsch. Grundkurs Geschäftsprozess-Management – Methoden und Werkzeuge für die IT-Praxis. Vieweg, Wiesbaden, 5., erweiterte und überarbeitete Auﬂage, 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 Deﬁnition. 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äﬀer-Poeschel, Stuttgart, 2., überarbeitete und erweiterte Auﬂage, 2002. Günter Greﬀ und Simone Fojut. Das ABC des Call Center Management. Gabler, Wiesbaden, 2., überarbeitete und erweiterte Auﬂage, 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 Diﬀerentiation 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. Auﬂage, 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 – Beneﬁts 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 markt- und 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 Auﬂage, 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 Auﬂage, 2006. Hajo Hippner und Klaus D. Wilde. CRM – Ein Überblick. In: S. Helmke, M. Uebl und W. Dangelmaier (Hrsg.), Eﬀektives 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 Auﬂage, 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/. Zugriﬀ am 26.03.2009. IETF. Internet Protocol Darpa Internet Program Protocol Speciﬁcation. Request for Comment (RFC) 791, The Internet Engineering Task Force, September 1981. URL http://tools.ietf.org/html/rfc791. Zugriﬀ 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. Zugriﬀ am 21.06.2008. ISO9000. Qualitätsmanagementsysteme – Grundlagen und Begriﬀe. ISO-Standard, International Organization for Standadization, Brüssel, 2000. ITWissen. ITWissen – Das große Online-Lexikon für Informationstechnologie, 2009. URL www.itwissen.info. Zugriﬀ am 08.05.2009. Jacada. Jacada WorkSpace, 2009. URL http://www.jacada.com/products/workspace/. Zugriﬀ 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. Auﬂage, 2006a.

Literatur

293

Hans Jung. Allgemeine Betriebswirtschaftslehre. Oldenbourg, München, 10. Auﬂage, 2006b. Hans Jung. Controlling. Oldenbourg, München, 2. Auﬂage, 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öﬀentlichungen 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. Auﬂage, 2006. Werner Kern. Industrielle Produktionswirtschaft. Poeschel, Stuttgart, 4., neu bearbeitete Auﬂage, 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. Auﬂage, 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. Zugriﬀ 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. Zugriﬀ am 20.11.2008. Erich Kosiol. Organisation der Unternehmung. Gabler, Wiesbaden, 2., durchgesehene Auﬂage, 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 Auﬂage, 2007. Philip Kotler, Gary Armstrong und John Saunders. Grundlagen des Marketing. Pearson, München, 4., aktualisierte Auﬂage, 2006. Hans-Ulrich Küpper. Controlling – Konzeption, Aufgaben, Instrumente. Schäﬀer-Poeschel, Stuttgart, 5., überarbeitete Auﬂage, 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 Oﬀermann. 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. Steﬀen 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 Auﬂage, 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 Auﬂage, 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. Auﬂage, 2006. Helmut Laux und Felix Liermann. Grundlagen der Organisation. Springer, Berlin et al., 5. Auﬂage, 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. Zugriﬀ 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 Oﬃnger 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 Diﬀerence Between ESP and CEP? Complexevents.com, 2006. URL http://complexevents.com/?p=103. Zugriﬀ 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. Zugriﬀ am 20.02.2009. David C. Luckham und James Vera. An Event-Based Architecture Deﬁnition Language. IEEE Transactions on Software Engineering, Band 21, Nr. 9, S. 717 – 734, September 1995. URL http://complexevents.com/stanford/rapide. Zugriﬀ 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. Zugriﬀ am 06.02.2009. Avishai Mandelbaum. Service Engineering Winter 2008: References, 2008. URL http://iew3.technion.ac.il/serveng/References/references.html. Zugriﬀ 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 eﬃziente Kunden- und Mitarbeiterbeziehungen, S. 135 – 157. Vahlen, München, 2001. Tiziana Margaria und Bernhard Steﬀen. 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äﬀer-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 Meﬀert, Christoph Burmann und Manfred Kirchgeorg. Marketing – Grundlagen marktorientierter Unternehmensführung. Gabler, Wiesbaden, 10. Auﬂage, 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. Auﬂage, 2007. Eckart Menzler-Trott und Markus Hahnel (Hrsg.). Call Center Evolution – Standards für eﬃziente Kunden- und Mitarbeiterbeziehungen. Vahlen, München, 2001. Eckhart Menzler-Trott. Call-Center Management: Ein Leitfaden für Unternehmen zum eﬃzienten Kundendialog. C. H. Beck, München, 1999. Peter Mertens. Integrierte Informationsverarbeitung 1 – Operative Systeme in der Industrie. Gabler, Wiesbaden, 16., überarbeitete Auﬂage, 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 Wolﬀried 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 Schaﬀer. 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 Auﬂage, 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 notiﬁcations in service runtime environments. In: Baldoni [2008], S. 115 – 125. Microsoft. Customer Care Framework (CCF Home), 2009a. http://www.microsoft.com/serviceproviders/ccf. Zugriﬀ am 06.05.2009.

URL

Microsoft. Telephony Application Programming Interfaces (TAPI, TSPI, MSPI), 2009b. URL http://msdn.microsoft.com/de-de/library/ms950407.aspx. Zugriﬀ am 26.05.2009. Microsoft. COM: Component Object Model Technologies, http://www.microsoft.com/com. Zugriﬀ 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 Zugriﬀ am

Joaching Müller. Workﬂow-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. Zugriﬀ am 23.07.3009.

URL

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

URL

2009.

Fritz Nordsieck. Betriebsorganisation – Lehre und Technik. Poeschel, Stuttgart, 2., bearbeitete Auﬂage, 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. Zugriﬀ 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. Zugriﬀ am 10.06.2009. OASIS. Web Services Base Notiﬁcation 1.3 (WS-BaseNotiﬁcation). OASIS Standard, Organization for the Advancement of Structured Information Standards (OASIS), 1. Oktober 2006c. URL http://docs.oasis-open.org/wsn. Zugriﬀ am 27.03.2009.

Literatur

299

OASIS. Web Services Brokered Notiﬁcation 1.3 (WS-BrokeredNotiﬁcation). OASIS Standard, Organization for the Advancement of Structured Information Standards (OASIS), 1. Oktober 2006d. URL http://docs.oasis-open.org/wsn. Zugriﬀ 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. Zugriﬀ 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. Zugriﬀ 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. Zugriﬀ 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. Zugriﬀ 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. Zugriﬀ 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. Zugriﬀ 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. Zugriﬀ 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/. Zugriﬀ 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. Zugriﬀ 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. Zugriﬀ am 26.03.2009. OMG. Business Process Modeling Notation, V1.1. OMG Available Speciﬁcation formal/2008-01-17, Object Management Group, Januar 2008a. URL http://www.omg.org/spec/BPMN/1.1/PDF. Zugriﬀ am 16.01.2009. OMG. Common Object Request Broker Architecture (CORBA) Speciﬁcation, Version 3.1. OMG Available Speciﬁcation, Object Management Group, Januar 2008b. URL http://www.omg.org/spec/CORBA/3.1. Zugriﬀ 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/.

Zugriﬀ am

Margit Osterloh und Jetta Frost. Prozessmanagement als Kernkompetenz – Wie Sie Business Reengineering strategisch nutzen können. Gabler, Wiesbaden, 5. Auﬂage, 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, Yeﬁm 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. Auﬂage, 2001.

Literatur

301

Michael E. Porter. Wettbewerbsvorteile – Spitzenleistungen erreichen und behaupten. Campus-Verlag, Frankfurt am Main et al., 6. Auﬂage, 2000. Thomas Reichmann. Controlling mit Kennzahlen und Management-Tools – die systemgestützte Controlling-Konzeption. Vahlen, München, 7., überarbeitete und erweiterte Auﬂage, 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 Auﬂage, 2005. Allan Rosenberg. Best Practices in Workforce Management, 5. Oktober 2005. URL http://www.callcentermagazine.com/showArticle.jhtml?articleID=160503291. Zugriﬀ am 10.07.2008. Jürgen Rothlauf. Total Quality Management in Theorie und Praxis. Oldenbourg, München, 2. Auﬂage, 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. Zugriﬀ 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 Zugriﬀ am

August-Wilhelm Scheer. Architektur integrierter Informationssysteme. Springer, Berlin et al., 1991. August-Wilhelm Scheer. ARIS – Modellierungsmethoden, Metamodelle, Anwendungen. Springer, Berlin et al., 4. Auﬂage, 2001. August-Wilhelm Scheer. ARIS-House of Business Engineering – Von der Geschäftsprozessmodellierung zur Workﬂow-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 Auﬂage, 1997. August-Wilhelm Scheer. ARIS – vom Geschäftsprozess zum Anwendungssystem. Springer, Berlin et al., 4., durchgesehene Auﬂage, 2002. August-Wilhelm Scheer. EDV-orientierte Betriebswirtschaftslehre – Grundlagen für ein eﬃzientes 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 lauﬀä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. Auﬂage, 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. Zugriﬀ 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. Auﬂage, 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 Auﬂage, 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 Auﬂage, 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 Auﬂage, 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. Auﬂage, 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 Auﬂage, 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. Auﬂage, 2006. SMI. What is CMMI?, Software Engineering Institut (SMI), Carnegie-Mellon-University, Pittsburgh, 2009. URL http://www.sei.cmu.edu/cmmi/general/index.html. Zugriﬀ am 26.07.2009. Howard Smith und Peter Fingar. Meghan Kiﬀer, 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. Auﬂage, 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. Auﬂage, 2006. Hubert Österle. Business Engineering – Prozeß- und Systementwicklung, Band 1 Entwurfstechniken. Springer, Berlin et al., 2., verbesserte Auﬂage, 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 eﬃziente 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/. Zugriﬀ 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. Scientiﬁc Management. Greenwood, Westpoint, 1972. Kurt H. Thieme und Wolfgang Steﬀen. Call Center – Der professionelle Dialog mit dem Kunden. Verlag Moderne Industrie, Landsberg am Lech, 2. Auﬂage, 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. Auﬂage, 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. Conﬁgurable 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. Auﬂage, 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 Auﬂage, 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. Zugriﬀ 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/. Zugriﬀ 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. Zugriﬀ 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/. Zugriﬀ 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/. Zugriﬀ 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/. Zugriﬀ 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/. Zugriﬀ 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. Zugriﬀ 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. Zugriﬀ 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. Zugriﬀ 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. Zugriﬀ 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/. Zugriﬀ 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/. Zugriﬀ am 22.06.2009. Günter Wallraﬀ. Günter Wallraﬀ 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 Kuﬂik 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 Schaeﬀer und Christian Wolﬀ. Identiﬁcation 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. Zugriﬀ 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. Auﬂage, 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. Workﬂowmanagement. 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 Auﬂage, 2005. Olaf Zwintzscher. Software-Komponenten im Überblick. W3L, Herdecke und Bochum, 2004.

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

Deklinationsklassen-Wandel: Eine diachron-kontrastive Studie zur Entwicklung der Pluralallomorphie im Deutschen, Niederländischen, Schwedischen und Dänischen

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

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

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

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

Deklinationsklassen-Wandel: Eine diachron-kontrastive Studie zur Entwicklung der Pluralallomorphie im Deutschen, Niederländischen, Schwedischen und Dänischen

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

Deklinationsklassen-Wandel: Eine diachron-kontrastive Studie zur Entwicklung der Pluralallomorphie im Deutschen, Niederländischen, Schwedischen und Dänischen

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