Inhaltsverzeichnis

Inhaltsverzeichnis   

1  Einleitung  1

2  Grundlagen des IT-Servicemanagements  4

2.1  Fokus und Ziele des IT-Servicemanagements.  4

2.2  ITIL als de-facto Standard für das ITSM  6

2.2.1  Service Delivery  7

2.2.2  Service Support.  9

2.3  Cobit und ISO 20000.  11

3  BP-MWerkzeuge.  12

3.1  Grundlagen und Ziele des BP-MAnsatzes  12

3.1.1  Geschäftsprozesse: Kern- und Sekundärprozesse  12

3.1.2  Frühere Ansätze  13

3.1.3  BPM heute - Grundlagen und Ziele  14

3.2  Phasen des BPMs  17

3.2.1  Phasenmodelle  17

3.2.2  Strategische Ebene  19

3.2.3  Prozessmodellierung /Design  20

3.2.4  Implementierung und Durchführung  23

3.2.5  Konzepte des Prozesscontrollings  27

3.3  BP-MTools und -Suites.  29

3.4  Potenziale von BP-MTools im ITSM  30

3.4.1  Schnittmengen der Konzepte BPM und ITSM  30

3.4.2  BP-MTools im Fokus ITSM  34

3.5  Ableitung und Beschreibung der Fragestellungen dieser Arbeit.  36

4  Evaluation.  37

4.1  Methodische Vorgehensweise der Evaluation.  37

4.2  Bestehende Konzepte zur BP-MSoftwarebewertung  39

4.3  Entwicklung des Kriterienkatalogs  41

4.3.1  Anforderungen an einen Kriterienkatalog.  41

4.3.2  Ableitung von Kategorien und Kriterien  44

4.3.3  Bewertungsmaßstab und Gewichtung der Kriterien  49

4.4  Auswahl und Beschreibung der Evaluationsobjekte  56

4.4.1  BOC Adonis/Adoit  56

4.4.2  IDS-Scheer Aris.  57

4.4.3  EMPRISE Bonapart  58

4.5  Evaluation der Tools  58

4.5.1  Aris  59

I

Inhaltsverzeichnis

4.5.1.1  Nicht-Funktionale Kriterien  59

4.5.1.1.1  Systemvoraussetzungen und Performanz  59

4.5.1.1.2  Datenhaltung und Datenkonsistenz  60

4.5.1.1.3  Konzept der Mehrbenutzerfähigkeit  60

4.5.1.1.4  Hilfefunktion und Dokumentation.  61

4.5.1.1.5  Menüführung und allgemeine  

Bedienbarkeit   62

4.5.1.1.6  Import- und Exportfunktionalitäten  63

4.5.1.2  Modellierung  65

4.5.1.2.1  Modellerstellung.  65

4.5.1.2.2  Modellverwaltung und Sichtenkonzept  66

4.5.1.2.3  Strategische Planung  69

4.5.1.2.4  ITIL Referenzmodell  70

4.5.1.2.5  Weitere ITSM Referenzmodelle  75

4.5.1.2.6  ITSM spezifische Modellklassen  75

4.5.1.2.7  Anpassbarkeit des Metamodells  76

4.5.1.3  Analyse und Simulation.  77

4.5.1.3.1  Statische Analysen von Modellen  77

4.5.1.3.2  Simulation.  79

4.5.1.3.3  Dynamische Analysen  80

4.5.1.4  Implementierung, Durchführung und Auswertung  81

4.5.1.4.1  Vorgehensmodelle zur Einführung von  

ITSM   81

4.5.1.4.2  Automatische Ablaufunterstützung.  83

4.5.1.4.3  Prozesscontrolling  85

4.5.2  Bonapart  86

4.5.2.1  Nicht-Funktionale Kriterien  86

4.5.2.1.1  Systemvoraussetzungen und Performanz  86

4.5.2.1.2  Datenhaltung und Datenkonsistenz  87

4.5.2.1.3  Konzept der Mehrbenutzerfähigkeit  88

4.5.2.1.4  Hilfefunktion und Dokumentation.  89

4.5.2.1.5  Menüführung und allgemeine  

Bedienbarkeit   90

4.5.2.1.6  Import/Export Funktionalität  90

4.5.2.2  Modellierung  91

4.5.2.2.1  Modellerstellung.  91

4.5.2.2.2  Modellverwaltung und Sichtenkonzept  92

4.5.2.2.3  Strategische Planung  94

4.5.2.2.4  ITIL Referenzmodell  94

II

Inhaltsverzeichnis

4.5.2.2.5  Weitere ITSM Referenzmodelle  97

4.5.2.2.6  ITSM spezifische Modellklassen  98

4.5.2.2.7  Anpassbarkeit des Metamodells  99

4.5.2.3  Analyse und Simulation.  100

4.5.2.3.1  Statische Analysen von Modellen  100

4.5.2.3.2  Simulation.  101

4.5.2.3.3  Dynamische Analysen  103

4.5.2.4  Implementierung, Durchführung und Auswertung  103

4.5.2.4.1  Vorgehensmodelle zur Einführung von  

ITSM   103

4.5.2.4.2  Automatische Ablaufunterstützung.  105

4.5.2.4.3  Prozesscontrolling  107

4.5.3  Adonis/Adoit  108

4.5.3.1  Nicht-Funktionale Kriterien  108

4.5.3.1.1  Systemvoraussetzungen und Performanz  108

4.5.3.1.2  Datenhaltung und Datenkonsistenz  109

4.5.3.1.3  Konzept der Mehrbenutzerfähigkeit  110

4.5.3.1.4  Hilfefunktion und Dokumentation.  110

4.5.3.1.5  Menüführung und allgemeine  

Bedienbarkeit   111

4.5.3.1.6  Import- und Exportfunktionalitäten  112

4.5.3.2  Modellierung  113

4.5.3.2.1  Modellerstellung.  113

4.5.3.2.2  Modellverwaltung und Sichtenkonzept  114

4.5.3.2.3  Strategische Planung  116

4.5.3.2.4  ITIL Referenzmodell  117

4.5.3.2.5  Weitere ITSM Referenzmodelle  120

4.5.3.2.6  ITSM spezifische Modellklassen  121

4.5.3.2.7  Anpassbarkeit des Metamodells  123

4.5.3.3  Analyse und Simulation.  124

4.5.3.3.1  Statische Analysen  124

4.5.3.3.2  Simulation.  126

4.5.3.3.3  Dynamische Analyse  128

4.5.3.4  Implementierung, Durchführung und Auswertung  129

4.5.3.4.1  Vorgehensmodelle zur Einführung von  

ITSM   129

4.5.3.4.2  Automatische Ablaufunterstützung.  130

4.5.3.4.3  Prozesscontrolling  131

4.6  Gesamtergebnis  132

III

Inhaltsverzeichnis

5  Diskussion der Ergebnisse  135

5.1  Nutzen der Tools für BPM  135

5.1.1  Modellierung  135

5.1.2  Analyse und Simulation  139

5.1.3  Prozessdurchführung und -controlling  141

5.2  Nutzen der Tools im ITSM  143

5.2.1  Tool-Vergleich anhand der Kriterien des ITSMs.  144

5.2.2  Stärken und Schwächen von BP-MTools im ITSM  147

6  Zusammenfassung und Ausblick  152

IV

Abbildungsverzeichnis   

Abbildungsverzeichnis   

Abbildung  1: Zentrale ITIL-Prozessbereiche in Anlehnung an Zarn05 , S. 20.  

Abbildung  2: BP-MZyklus in Anlehnung an Allw05 , S. 91.  

Abbildung  3: BPMS-Architektur in Anlehnung an Allw05 , S. 346  

Abbildung  4: BP-MTools in Anlehnung an HaHa05 , S. 1  

Abbildung  5: Grafischer Überblick der Vorgehensweise der Evaluation.  

Abbildung  6: Funktionsebenen von BP-MTools in Anlehnung an Freu06 ,  

Abbildung  7: Aris BSC-Beispielmodell  

Abbildung  8: Aris ITIL Einstiegsmodell  

Abbildung  9: Aris ITIL Funktionszuordnungsdiagramm  

Abbildung  10: Aris ITIL Aktivitäts-Inputs/Outputs und Rollen  

Abbildung  11: Aris ITIL Datenmodell-Ausschnitt „Änderung“  

Abbildung  12: Aris ITIL Vorgehensmodell (Ausschnitt)  

Abbildung  13: Bonapart ITIL Prozessübersicht Change Management  

Abbildung  14: Bonapart Ausschnitt Prozess "Änderungsanträge aufnehmen"  

Abbildung  15: Bonapart Prozess "Release Management planen und  

implementieren"   

Abbildung  16: Adoit ITIL Einstiegsmodell  

Abbildung  17: Adoit ITIL Prozessübersicht Change Management.  

Abbildung  18: Adoit ITIL Prozess Change Management (Ausschnitt)  

Abbildung  19: Adoit SLA-Objektattribute.  

Abbildung  20: Netzdiagramm Gesamtergebnis.  

Abbildung  21: Auswertung „Modellierung“  

Abbildung  22: Auswertung ITSM  

V

Einleitung   

Tabellenverzeichnis   

Tabelle 1:  Kriterienkatalog für Modellierungstools in Anlehnung an Nütt02  40

Tabelle 2:  Kriterienkatalog.  45

Tabelle 3:  Bewertungsgrade der Kriterien  50

Tabelle 4:  Gewichtungsklassen  52

Tabelle 5:  Klassenzuordnung.  54

Tabelle 6:  Klassengewichtung  55

Tabelle 7:  Auswertung  133

Tabelle 8:  Auswertung „Modellierung“  138

Tabelle 9:  Auswertung „Analyse und Simulation“  140

Tabelle 10:  Auswertung „Prozessdurchführung und -controlling“  142

Tabelle 11:  Auswertung ITSM.  147

VI

Abkürzungsverzeichnis ADB ........ Aris Database ADL ......... Adonis Definition Language AQL ......... Adonis Query Language ARIS........ Architektur Integrierter Informationssysteme ATF ......... Adobe Transfer Function

BPEL........ Business Process Execution Language for Webservices BPM ........ Business Process Management BPML ....... Business Process Modeling Language BPMS....... Business Process Management System BPR ......... Business Process Reengineering BSLA ....... Business Service Level Agreement CASE ....... Computer Aided Software Engineering CI ........... Configuration Item CMDB ...... Configuration Management Database

Cobit ....... Control Objectives for Information and related Technology CPU......... Central Processing Unit CRM ........ Customer Relationship Management DB .......... Database DBMS ...... Database Management System DHS ........ Definitive Hardware Store DOC ........ Document DSL ......... Definitive Software Library DV .......... Datenverarbeitung EA........... Enterprise Architecture EAI.......... Enterprise Application Integration eEPK ....... Erweiterte Ereignisorientierte Prozesskette EFQM....... European Foundation for Quality Management EPK ......... Ereignisgesteuerte Prozesskette ERM ........ Entity Relationship Model ERP ......... Enterprise Ressource Planning GB .......... Gigabyte GPM ........ Geschäftsprozessmanagement HOBE....... House of Business Engineering HTML....... Hypertext Markup Language i.d.R. ....... in der Regel

ICT.......... Information and Communications Technology ISO ......... International Standards Organisation

IT ........... Information Technology ITIL ......... IT Infrastructure Library ITSCMM ... IT Service Capability Maturity Model ITSM ....... IT Service Management KGI ......... Key Goal Indicator KPI.......... Key Performance Indicator KSA......... Kommunikationsstrukturanalyse MB .......... Megabyte MHz......... Megahertz OGC ........ Office of Governance Commerce OLA ......... Operational Level Agreement OLAP ....... Online Analytical Processing PDCA....... Plan-Do-Check-Act PDF ......... Portable Document Format PIR.......... Post Implementation Review RfC.......... Request for Change RTF ......... Rich Text Format SCM ........ Supply Chain Management SLA ......... Service Level Agreement SOA ........ Service Oriented Architecture SOX ........ Sarbanes-Oxley-Act SQL ......... Structured Query Language TCP/IP ..... Transmission Control Protocol/Internet Protocol TQM ........ Total Quality Management UC .......... Underpinning Contract UML ........ Unified Modeling Language WSDL ...... Webservice Description Language WWW ...... World Wide Web XML......... Extensible Markup Language XPDL ....... XML Process Definition Language

1 Einleitung

IT-Abteilungen sind zunehmend gefordert, auf steigende Kundenanforderungen an die Qualität von IT-Leistungen zu reagieren. Zudem sind IT-Organisationen heutzutage einem Wettbewerb ausgesetzt, der den Druck ausübt, Leistungen möglichst kostengünstig anzubieten. Einen Lösungsansatz, der das Ziel hat, den Anforderungen der Kunden gerecht zu werden, stellt das IT-Servicemanagement ¹ dar. ITSM impliziert eine neue Sichtweise des IT-Managements, die dazu führt, dass von technischen Details abstrahiert und der Kundennutzen in den Vordergrund gestellt wird (vgl. [BKP02], S. 30). Für die Umsetzung des ITSMs in IT-Abteilungen ist ein kontinuierlicher Wandlungsprozess erforderlich. So müssen vorhandene Abläufe innerhalb der IT-Organisation schrittweise durch neue Prozesse ersetzt werden, die die Produktion von IT-Services nach Anforderungen der Abnehmer ermöglichen (vgl. [Zarn05], S. 30; [HZB04], S. 1; [Somm04], S. 40). Einzuführende Prozesse können sich dabei an Referenzmodellen, wie z.B. ITIL ² , orientieren, die „Common-Practice“ ³ -Vorgaben für ITSM liefern (vgl. [HZB04], S. 1). Bei der Implementierung neuer Prozesse ist die Modellierung von geplanten Abläufen ein erster Schritt. Auf diese Weise werden unter Berücksichtigung unternehmensspezifischer Rahmenbedingungen detaillierte Arbeitsschritte, Verantwortlichkeiten, Prozess-Inputs/-Outputs, Qualitätsparameter und Ziele von ITSM-Prozessen festgelegt (vgl. [BKP02], S. 29). Nach der Umsetzung der geplanten Prozesse ist laufend zu überprüfen, ob die definierten Prozessziele erreicht werden. Diese Prozessbewertung ist von zentraler Bedeutung, um die Qualität der angebotenen IT-Services und die Kundenzufriedenheit zu gewährleisten. Die genannten Aufgaben der Modellierung und der Überprüfung laufender Prozesse werden ebenso auf der fachlichen Ebene im Rahmen des „Business Process Managements“(BPM) ⁴ postuliert. Im Kontext des Managements von Geschäftsprozessen

¹ Im Folgenden wird die Abkürzung „ITSM“ verwendet.

² IT Infrastructure Library (vgl. Kapitel 2)

³ Ebenfalls wird in der Literatur der Ausdruck „Best Practice“ verwendet (vgl. [Zarn05];

[Somm04]).

⁴ Die Ausdrücke „Business Process Management” (kurz: BPM), „Prozessmanagement“ und „Ge-

schäftsprozessmanagement” werden in dieser Arbeit synonym verwendet. Eine Definition

und weitere Erläuterungen des Konzepts finden sich in Kapitel 3.1.

ist die Verwendung von BPM-Tools ⁵ vorteilhaft (vgl. [Freu06], S. 27). Zentrale Vorteile des Tool-Einsatzes sind beispielsweise die einfache Anpassung von Modellen und die automatisierte Überprüfung existierender Prozesse (Prozesscontrolling). Huppertz fordert die Verwendung von Prozessmanagement-Tools ebenfalls im Bereich des ITSMs für die Modellierung und das Controlling von Service-Prozessen. Es wird weiterhin vorgeschlagen, BPM-Tools im Bereich ITSM zusätzlich zu speziellen „ITSM-Tools“ ⁶ und „CRM ⁷ -Tools“ einzusetzen (vgl. [Hupp06], S. 90ff), um Modellierungs- und Prozesscontrolling-Funktionalitäten nutzen zu können. Brenner geht darüber hinaus und betont die Notwendigkeit von „ITSM BPM Tool[s]“, die die Durchführung taktischer und operativer ITSM-Prozesse unterstützen (vgl. [Brenn06], S. 10).

Allerdings war das Hauptanwendungsgebiet dieser Tools bisher die Geschäftsebene, so dass sich die Frage stellt, ob sich diese Werkzeuge auch für den Einsatz im ITSM eignen. BPM-Tool-Hersteller werben derweil mit Funktionalitäten, die die Erfüllung von ITSM-Aufgaben versprechen. So werden beispielsweise Referenzmodelle für Prozesse des ITSMs angeboten. Dadurch soll die Einführung von ITSM-Prozessen erleichtert werden. Des Weiteren existieren Tool-Hersteller, die mit der Unterstützung der Durchführung von Prozessen des Service Supports ⁸ und des Service Delivery ⁹ , das taktische Aufgaben beinhaltet, werben. 10

Es bleibt jedoch unklar, inwieweit diese Tools tatsächlich einen Nutzen im Einsatzgebiet des ITSMs stiften, da keine herstellerunabhängige Literatur existiert, die Stärken und Schwächen von BPM-Werkzeugen im ITSM-Kontext herausstellt. Die Be-antwortung dieser Fragestellung stellt das Kernziel dieser Arbeit dar. Dazu sind mit ITSM und BPM zwei unterschiedliche Managementkonzepte zu berücksichtigen, die zu Beginn der Arbeit in den Kapiteln 2, 3.1 und 3.2 vorgestellt

⁵ „BPM-Tools“ bieten grundsätzlich Funktionen, die das Potenzial haben, die Planung, das Pro-

zesscontrolling und die Durchführung von Prozessen zu unterstützen (vgl. [Strn06], S.

5ff).

⁶ ITSM-Tools eignen sich vor allem für die Durchführung von ITSM- (bzw. ITIL-) Prozessen.

Heinrich und Lehner teilen ITSM-Tools in die Gruppen „Monitoring und Infrastruktur Ana-

lyse Tools“, „Software Delivery Tools“ und „Service Desk Tools“ ein (vgl. [HeLe05], S.

295). Eine Übersicht über Tools dieser Kategorien findet sich unter [Elsä05], S. 193f.

⁷ Customer Relationship Management (vgl. [Krcm05], S. 469)

⁸ Siehe dazu Erläuterungen in Kapitel 2.2.1.

⁹ Siehe dazu Erläuterungen in Kapitel 2.2.2.

¹⁰ Vgl. für die Beschreibung oben genannter Funktionalitäten beispielsweise „BOC Adoit“,

http://www.boc-eu.com.

werden. Darauf aufbauend wird eine Kategorisierung von Tools vorgenommen, die Funktionen für die Aufgabenerfüllung im Bereich des BPMs bereitstellen. Für das Verständnis der Rolle von BPM-Tools im ITSM werden in Kapitel 3.4.1 auf theoretischer Ebene die Gemeinsamkeiten der beiden Managementkonzepte herausgestellt, um anschließend Anwendungsmöglichkeiten von BPM-Werkzeugen im Rahmen des ITSMs vorzustellen. An dieser Stelle wird sich zeigen, dass die Unterstützung der BPM-Phasen durch diese Tools sowohl auf der Geschäftsebene als auch auf der IT-Ebene ein Indikator für die Qualität von BPM-Werkzeugen ist. Deshalb wird in Kapitel 3.5 zusätzlich das Ziel der Beurteilung der Unterstützung der BPM-Phasen durch entsprechende Softwaretools ausgegeben.

Zur Lösung der aufgestellten Fragestellungen wird eine Evaluation von drei BPM-Tools, die stellvertretend für Werkzeuge in diesem Bereich ausgewählt wurden, durchgeführt. Diese Tools sind zum einen im deutschsprachigen Raum weit verbreitet und besitzen laut Herstellerangaben zum anderen das Potenzial zur Unterstützung von ITSM-Aufgaben. Die Evaluation erfolgt durch die Bewertung der Tools mit Hilfe eines Kriterienkatalogs, der in Kapitel 4.3 entwickelt wird. Dieser Katalog umfasst Kriterien, die die Basis für die Beantwortung beider Fragestellungen darstellen. Die Anwendung des Kriterienkatalogs geschieht in Kapitel 4.5, in dem die Tools „Aris“, „Adonis/Adoit“ und „Bonapart“ evaluiert werden. Die Vergabe von Bewertungspunkten zu jedem Kriterium ermöglicht im Anschluss (Kapitel 4.6) die Ermittlung eines Gesamtergebnisses durch die Anwendung der Nutzwertanalyse. An dieser Stelle wird kumuliert dargestellt, welches Tool die aufgestellten Kriterien insgesamt am besten erfüllt.

Schließlich werden die Ergebnisse der Evaluation detailliert ausgewertet, um einen Vergleich über die Stärken und Schwächen der Tools jeweils im BPM- und ITSM-Bereich zu gestatten. Ebenso können an dieser Stelle Rückschlüsse über die generelle Eignung von BPM-Tools im Einsatzgebiet des ITSMs gezogen werden.

2 Grundlagen des IT-Servicemanagements

Dieses Kapitel vermittelt die Grundlagen des IT-Servicemanagements (ITSM) und die Konzepte für dessen Umsetzung in der Praxis. Mit ITIL und Cobit werden zwei Rahmenwerke ¹¹ für das IT-Servicemanagement vorgestellt. Zudem werden Möglichkeiten einer Software-Unterstützung des Servicemanagements aufgezeigt.

2.1 Fokus und Ziele des IT-Servicemanagements

Für die Unterstützung der Geschäftsprozesse von Unternehmen spielt die IT eine zunehmend größere Rolle. IT ermöglicht nicht nur die Vereinfachung und Beschleunigung von bestehenden Abläufen im Unternehmen, sondern erlaubt in vielen Fällen die Produktion von Gütern und Dienstleistungen, die ohne technische Hilfe nicht realisierbar wären (vgl. [Somm04], S. 13).

Gleichzeitig traten in der Vergangenheit jedoch zwangsläufig Probleme auf. Zum einen hat die vermehrte Durchdringung der IT im Unternehmen zu immer größerer Komplexität der technischen Einrichtungen geführt. Ferner stiegen der Aufwand der Organisation der IT-Infrastruktur und somit Anforderungen an die Kompetenzen von Mitarbeitern für die Administration (vgl. [Somm04], S. 13f). Auf der anderen Seite wuchsen ebenso die Ansprüche der Mitarbeiter der fachlichen Bereiche an die IT. Ein reibungsloser Betrieb von IT-Systemen wird dort für die Aufgabenerfüllung zwingend vorausgesetzt. Die Entwicklung hat gezeigt, dass die IT in vielen Fällen die Anforderungen nicht erfüllen konnte, so dass Geschäftsprozesse nicht störungsfrei abliefen. Die Akzeptanz der IT-Bereiche, die häufig nur mit geringem Budget ausgestattet waren, sank folglich in den Unternehmen (vgl. [Zarn05], S. 6f).

Zur Lösung der entstandenen Probleme reichten bisherige Ansätze des IT-Managements nicht aus. Die Disziplin des ITSMs ist ein neues Konzept mit dem Ziel, IT-Leistungen an die Bedürfnisse des Kunden auszurichten (vgl. [Zarn05], S. 8). Im

¹¹ Eine Übersicht über weitere Initiativen und Standards des ITSMs wird in [HeLe05], S. 293

veranschaulicht.

Mittelpunkt steht dabei der Begriff des „IT-Services“, der im Folgenden kurz erklärt wird:

IT-Services sind Dienstleistungen, die aus technischen und nicht-technischen Komponenten bestehen und Anwendern zur Nutzung zur Verfügung gestellt werden (vgl. [Elsä05], S. 19). Diese Leistungen werden durch „IT-Service-Provider“ erbracht und an Service-Kunden verkauft. Ein IT-Service-Provider kann dabei eine interne IT-Abteilung oder einen externen Dienstleister darstellen. Auf Seiten des Dienstempfängers (Service-Kunde) ermöglichen die IT-Services ¹² die Unterstützung von Geschäftsprozessen.

Durch die Orientierung an IT-Services ist eine Sichtweise entstanden, die den Kundennutzen in den Vordergrund stellt und von technischen Details abstrahiert. ITSM zielt auf die Verbesserung der Qualität von angebotenen IT-Services ab, um die An-forderungen von Service-Kunden zu erfüllen (vgl. [BKP02], S. 30). Eine „kontinuierliche Überwachung und Steuerung der IT-Services“ und der Ersatz von „traditionellen, technologieorientierten Management-Prozessen“ durch „serviceorientierte Prozesse“ sind dabei der Kern des ITSMs (vgl. [Zarn05], S. 8). Weiterhin stellt Zarnekow die folgenden vier Merkmale heraus, die das ITSM charakterisieren (vgl. [Zarn05], S. 9f):

N Marktorientierung: Business und IT sind nicht mehr nur Projektpartner, sondern Kunden und Lieferanten. Dabei werden Leistungen und Kosten vertraglich festgelegt.

N Serviceorientierung: Gegenstand des Angebotsportfolios von IT-Lieferanten sind IT-Services, die von Kunden eingekauft werden. N Lebenszyklusorientierung: Im Gegensatz zum traditionellen IT-Management, in dem nur Entwicklungskosten für IT-Anwendungen berücksichtigt wurden, werden im ITSM vor allem auch Produktions- und Wartungskosten von IT-Services gemessen. Diese Kosten übersteigen die Entwicklungskosten und sind deshalb von großer Bedeutung für das IT-Controlling.

¹² Weitere Ausführungen zum Begriff des IT-Services finden sich in [Hupp06], S. 15ff und

[MeSp04], S. 15ff.

N Prozessorientierung: Im Zuge des ITSMs werden keine funktionalen Einheiten betrachtet, sondern die Prozesse, die dazu dienen, anforderungskonforme IT-Services bereitzustellen.

2.2 ITIL als de-facto Standard für das ITSM

Die Information Technology Infrastructure Library (ITIL) ist ein Rahmenwerk, das Best-Practice-Vorschläge für das ITSM zusammenfasst. ITIL, das Ende der achtziger Jahre von der britischen OGC ¹³ entwickelt wurde, hat sich als de-facto-Standard im Bereich des ITSMs durchgesetzt (vgl. [BKP02], S. 9). Grundlage der folgenden Beschreibung ist ITIL v2. Eine dritte Version, „ITIL-Refresh“, ist zurzeit noch in Bearbeitung und wird im Laufe des Jahres 2007 publiziert (vgl. [ITILv3]). Die überragende Bedeutung von ITIL für das ITSM wird durch eine Reihe von Studien belegt. Eine aktuelle Umfrage der Universität Duisburg-Essen kommt zu dem Ergebnis, dass insgesamt 72% der befragten Personen Unternehmen ¹⁴ angehören, die ITIL vollständig oder teilweise einsetzen (vgl. [Schm07], S. 102ff). ITIL verfolgt das Ziel, die Effizienz und Effektivität von IT-Dienstleistern zu erhöhen, um den Kunden qualitativ hochwertige IT-Services zur Verfügung stellen zu können. Für die Ziel-Umsetzung schlägt ITIL die Ausrichtung von IT-Abläufen an Prozessen vor, die sich in der Praxis bewährt haben. Diese Referenzprozesse, die allgemeingültiger Natur sind, stellen den Kern von ITIL dar. Die Aktivitäten, aus denen die Prozesse bestehen, werden als Grundvoraussetzungen für die Erbringung von IT-Services hoher Qualität angesehen (vgl. [BKP02], S. 31f). Die ITIL-Prozesse sind Teil von verschiedenen Prozessbereichen, die jeweils in Buchform veröffentlicht wurden. Einen Überblick über die zentralen Prozessbereiche von ITIL gibt Abbildung 1. „Die Grundlage von ITIL“(vgl. [Somm04], S. 51) setzt sich aus den beiden Büchern „Service Support“ ¹⁵ und „Service Delivery“ ¹⁶ zusammen. Im Folgenden werden diese beiden Prozessbereiche beschrieben. Informationen

¹³ OGC: Office of Governance Commerce, IT-Dienstleister der britischen Regierung (vgl.

[BKP02], S. 9).

¹⁴ Im Rahmen der Umfrage wurde die Frage des ITIL-Einsatzes von 87 Personen beantwortet.

60% der befragten Personen gehören Firmen an, die aus dem IT-Bereich stammen.

¹⁵ “Service Support”-Originalquelle: [BHJL00]

¹⁶ “Service Delivery”-Originalquelle: [BHJK01]

zu „Business Perspective“ sowie den Prozessbereichen „Application Management“, „Infrastructure Management“ (siehe Abbildung 1) und „Planning to implement Service Management“ ¹⁷ finden sich in [Zarn05], [BKP02] und [HeCa02]. Auf diese Bereiche wird des Weiteren nicht näher eingegangen.

2.2.1 Service Delivery

Service Delivery beinhaltet taktische Prozesse, die der „Planung, Bereitstellung und Durchführung“ (vgl. [Elsä05], S. 45) von IT-Services dienen. Im Mittelpunkt steht dabei der Prozess „Service Level Management“. Der Prozess bezweckt, mit dem Kunden Vereinbarungen über die Lieferung der IT-Services in der gewünschten Qualität zu treffen. Diese Vereinbarungen werden durch „Service Level Agreements“ (SLAs) dokumentiert. Darin erfolgt die Festlegung der Funktio- ¹⁷ “Planningto implement Service Management”-Originalquelle: [LPRW02]

nalitäten eines Services, der Höhe der Mindestverfügbarkeit und weiterer Leistungskennzahlen sowie Vertragsstrafen und Service-Preise. Um sich als Service-Provider selbst vertraglich abzusichern, werden innerhalb der IT „Operative Level Agreements“ (OLAs) definiert. Ist der Service-Anbieter von externen Lieferanten abhängig, wird die Verwendung von „Underpinning Contracts“ (UCs) empfohlen. In dem Fall, dass der Service-Provider aufgrund fremder Fehler die eigene Servicevereinbarung mit dem Kunden nicht erfüllen kann, können somit Vertragsstrafen auf die Lieferanten abgewälzt werden (vgl. [Zarn05], S. 25).

Der „Finance-Management“-Prozess kann in drei Bereiche aufgeteilt werden. Durch das „Budgeting“ können zukünftig auftretende Kosten der IT abgeschätzt werden. „Accounting“ ermöglicht im Bereich des ITSMs die Berechnung der Kosten, die für einen IT-Service anfallen. Durch die Methode des „Charging“ können angefallene Service-Kosten an die Kunden weitergegeben werden (vgl. [Somm04], S. 104ff). Das „Capacity Management“ hat die Aufgabe, die Voraussetzungen zu schaffen, dass zu jedem Zeitpunkt ausreichende IT-Kapazitäten zur Verfügung stehen. Um unnötige Kosten zu vermeiden, ist auch dem Entstehen von Überkapazitäten vorzubeugen. Durch Methoden des „Business Capacity Managements“ wird die Kapazitätsnachfrage der Kunden nach IT-Services abgeschätzt. Die Aufgaben „Service Capacity Management“ und „Ressource Capacity Management“ ermitteln durch Moni-toring existierende Auslastungen von IT-Services bzw. der gesamten IT-Infrastruktur (vgl. [Somm04], S. 110ff).

Das Ziel des „Availability Managements“ ist die Einhaltung von Verfügbarkeiten, die im Service Level Management verhandelt wurden. Dazu zählt auch das Auftreten von Fehlern zu minimieren, um eine möglichst hohe Zuverlässigkeit („Reliability“) von Services zu gewährleisten. Mit „Maintainability“ wird gefordert, dass IT-Services die Eigenschaft haben, mit geringem Aufwand gewartet werden zu können. Da auch externe Dienstleister (Teil-) Verantwortung für die Verfügbarkeit von IT-Services besitzen, wird durch „Serviceability“ die Unterstützung des Prozesses Service Level Management bei der Verhandlung mit Service-Lieferanten gefordert (vgl. [BKP02], S. 181f)

Im „Continuity Management“ stehen Ereignisse im Fokus, deren Eintreten katastrophale Beeinträchtigungen von Services und Systemen auslösen, die nur mit erhebli-

chem Aufwand wiederherzustellen sind. Ziel des IT-Continuity Managements ist es, im Fall einer Katastrophe die Services möglichst schnell wiederherstellen zu können. Zentrale Aufgaben sind deshalb die Feststellung von Auswirkungen von Service-Ausfällen auf das Unternehmen, die Ermittlung von Risiken für katastrophale Vorfälle und die Planung von Maßnahmen, die im Katastrophenfall zu einer zügigen Rückkehr in den Normalbetrieb führen (vgl. [Somm04], S. 123ff).

2.2.2 Service Support

Die Prozesse des Service Supports beinhalten operative Aktivitäten, die für die Unterstützung und den Betrieb von IT-Services erforderlich sind. Der „Service Desk“ stellt keinen ITIL-Prozess dar, sondern bildet eine Organisationseinheit, die alleiniger Ansprechpartner („Single Point of Contact“) für Anwender und Kunden der Geschäftsprozesse ist. Über den Service Desk werden Prozesse der Bereiche Support und Delivery, die eine Kunden- bzw. Anwenderinteraktion erfordern, abgewickelt (vgl. [BHJL00], S. 29).

Der Prozess des „Incident Managements“ hat das Ziel, Störungen (Incidents), die Benutzer dem Service Desk melden, in möglichst kurzer Zeit zu beheben. Zudem werden generelle Anwenderfragen, die sich nicht auf akute Störungen beziehen (Service Requests), beantwortet. Liegt eine Störung vor, so erfolgt eine Priorisierung nach Dringlichkeit des Vorfalls. Ist die Art der Störung bekannt, folgt ihre vollständige Behebung oder eine vorläufige Lösung (Workaround). Ein Workaround beseitigt nicht die Ursache einer Störung, gestattet aber kurzfristig eine störungsfreie Nutzung von IT-Services. Bei unbekannten Incidents sind weitergehende Untersuchungen notwendig.

Das „Problem Management“ ist für die Lösung der Ursachen von Incidents zuständig. Dabei werden die Ursachen in ITIL als „Probleme“ (engl. „Problems“) definiert. Ziel ist es, potenzielle Incidents durch Beseitigung von Problemen nicht entstehen zu lassen. Der „Error-Control“-(Sub-) Prozess dient dabei im Kern der Ursachenfindung. Das Ergebnis ist ein „Known-Error“. Das Vorgehen, wie ein bekanntes Problem gelöst werden kann, beschreibt der „Error-Control“-Prozess. Resultat dieses Prozesses ist ein „Request for Change“ (RfC).

Dieser Änderungsantrag (RfC), der Vorschläge für die Problembeseitigung durch Veränderung oder Neuanschaffung von „CIs“ ¹⁸ enthält, wird an das „Change Management“ weitergeleitet. Das Change Management hat die Aufgabe zu prüfen, welche Auswirkungen die beantragten Veränderungen auf die IT-Infrastruktur haben und welche Risiken damit verbunden sein können. Weiterhin überwacht das Change Management die Durchführung von Änderungen und kontrolliert folglich die Auswirkungen auf die betroffenen CIs, die schließlich in einem „Post Implementation Review“ (PIR) dokumentiert werden. Für Änderungen mit hoher Dringlichkeit oder großem Umfang müssen der Change Manager bzw. das „Change Advisory Board“ konsultiert werden.

Das „Configuration Management“ stellt den übrigen zentralen ITIL-Prozessen eine Datenbank zur Verfügung, in der CIs und deren Zusammenhänge vollständig abgebildet sind. Die Aufgabe dieses ITIL-Prozesses ist insbesondere die Pflege der „Configuration Management Database“ (CMDB). Der Vorteil dieser Datenbank ist die ständige Aktualität und die Transparenz über die gesamte IT-Infrastruktur, so dass Entscheidungen in anderen Prozessen auf Basis detaillierter und konsistenter Daten getroffen werden können.

Entscheidet das Change Management, Veränderungen durchzuführen, ist das „Release Management“ für die Implementierung zuständig. Ein „Release“ besteht dabei aus einer Menge von CIs, die neu eingesetzt werden sollen. Es ist Aufgabe des Release Managements, nur getestete Releases einzuführen, um das Risiko von Service-Ausfällen zu minimieren. Die Speicherung von Software-Releases erfolgt in der „Definitive Software Library“ (DSL). Hardware-Releases werden im „Definitive Hardware Store“ (DHS) vorgehalten.

¹⁸ Configuration Item. Ein CI bezeichnet „alle Komponenten, die für die Erbringung von IT-

Services benötigt werden“ (vgl. [Somm04], S. 69). Hierbei kann es sich beispielsweise um

Hardware, Software oder Dokumente handeln.

2.3 Cobit und ISO 20000

Während ITIL konkrete Vorschläge für die Durchführung von Prozessen im ITSM gibt, definiert Cobit ¹⁹ Kontrollziele für IT-Prozesse, deren Erreichung eine zuverlässige Anwendung der IT in den Geschäftsprozessen erlaubt (vgl. [Ande05], S. 174). Cobit ist ein Standard für IT-Governance ²⁰ , der im Bereich IT-Revision ²¹ eingesetzt werden kann und „Sicherheit, Qualitätssicherung und Ordnungsmäßigkeit der IT“ (vgl. [HeLe05], S. 293) gewährleisten soll. Cobit definiert 34 IT-Prozesse, die den Bereichen („Domains“) „Planung und Organisation“, „Beschaffung und Implementierung“, Auslieferung und Unterstützung“ sowie „Überwachung und Beurteilung“ zugeordnet sind. Die Prozesse beinhalten Zielbeschreibungen (Kontrollziele), die in Ziele für Geschäftstätigkeiten, Organisations- und Kommunikationsziele und IT-Kontrollziele unterteilt werden können (vgl. [Bitt06]; [ITGI05]). Der Standard ISO IEC 20000 ist die internationale Umsetzung des britischen Standards „BS 15000“ für IT-Service-Management. Der Standard ist stark an die ITIL-Prozessbereiche Service Support und Service Delivery orientiert und formuliert für die Prozesse genaue Mindestanforderungen. Es wird das Ziel verfolgt, durch Einhaltung der Anforderungen definierte Qualitätslevel von IT-Services zu gewährleisten. Der Standard legt Kriterien für IT-Organisationen fest, die eine Prüfung und Zertifizierung nach ITIL gestatten (vgl. [Zarn05], S. 15; [ISO20000a]; [ISO20000b]).

¹⁹ Control Objectives for Information and related Technology (vgl. [ITGI05]).

²⁰ Vgl. [HeLe05], S. 64ff

²¹ Vgl. [HeLe05], S. 197ff

3 BPM-Werkzeuge

Um die Einführung und Durchführung von ITSM zu unterstützen, empfiehlt sich in größeren IT-Abteilungen der Einsatz von Software-Tools, mit denen die zwangsläufig hohe Komplexität bewältigt werden kann (vgl. [BHJL00], S. 245). Im Umfeld des ITSMs unterscheidet Huppertz - neben speziellen ITSM-Tools - CRM-Tools, System-Management-Tools und Prozessmanagement-Tools (vgl. [Hupp06], S. 93). Der Fokus dieser Arbeit liegt auf der Betrachtung von Prozessmanagement-Tools (BPM-Tools). Dieses Kapitel stellt zunächst das theoretische Konzept des BPMs vor (Kapitel 3.1 und 3.2), um im Anschluss genauer auf das Potenzial von BPM-Tools in allgemeiner- und ITSM-spezifischer-Hinsicht eingehen zu können (Kapitel 3.3, 3.4 und 3.5).

3.1 Grundlagen und Ziele des BPM-Ansatzes

Nach der Erläuterung des Begriffs „Geschäftsprozess“ werden in diesem Kapitel frühere Ansätze des BPMs vorgestellt. Anschließend erfolgt eine Darstellung der heutigen Ziele von BPM und der aktuellen Bedeutung dieses Konzepts für die Praxis.

3.1.1 Geschäftsprozesse: Kern- und Sekundärprozesse

Funktionale Organisationsstrukturen - in der Praxis weit verbreitet - gliedern Unternehmen nach Verrichtungen bzw. Funktionen (vgl. [Schr03], S. 129). Eine Funkti-onsorientierung verursacht im Unternehmen eine hohe Anzahl von Schnittstellen zwischen den funktionalen Bereichen. Schnittstellen stellen Brüche dar und „verursachen Koordinations- und Kontrollaufwand, erzeugen Missverständnisse und Fehler, verzögern Entscheidungen, verbrauchen Zeit, erschweren die Kommunikation, führen zu Informationsverlusten und mindern insgesamt die Ergebnisqualität sowie die Produktivität“(vgl. [ScSe04] S. 53). Der Fokus liegt auf der Ausführung von Teilaktivitäten, die das Endergebnis für den Kunden außer Acht lassen. Gadatsch spricht in diesem Zusammenhang von „Abteilungs-Silos“: Direkte Kommunikation zwischen den Abteilungen findet dabei nicht statt (vgl. [Gada03], S. 6).

Die Orientierung an durchgehenden Geschäftsprozessen kann eine Lösung für die Probleme, die die Funktionsorientierung verursacht, darstellen. Schmelzer definiert Geschäftsprozesse als „funktionsüberschreitende Verkettungen wertschöpfender Aktivitäten, die von Kunden erwartete Leistungen erzeugen und deren Ergebnisse strategische Bedeutung für das Unternehmen haben […]“(vgl. [ScSe04], S. 56). In einem Geschäftsprozess sind die Aktivitäten ferner per Definition abteilungsübergreifend, zusammenhängend und kundenorientiert.

Für die Typisierung von Geschäftsprozessen gibt es verschiedene Ansätze. An dieser Stelle wird die Einteilung von Geschäftsprozessen nach primären und sekundären Prozessen im Sinne von Schmelzer und Sesselmann (vgl. [ScSe04], S. 55ff) sowie Becker et al. (vgl. [BKR00], S. 4ff) verwendet. Primärprozesse tragen direkt zur Wertschöpfung bei und enden beim externen Kunden, der Sach- oder Dienstleistungen in Anspruch nimmt. Beispiele sind Vertriebsprozesse, Produktionsplanungsprozesse und Serviceprozesse. Die genannten Prozesse benötigen zur erfolgreichen Abwicklung unterstützende Prozesse (Sekundärprozesse), die keinen Kontakt zu externen Kunden haben, sondern Leistungen für interne Zwecke erbringen. Sekundärprozesse oder „Supportprozesse“ können z.B. IT-Prozesse, Personalmanagementprozesse oder Controlling-Prozesse sein (vgl. [ScSe04], S. 55ff).

3.1.2 Frühere Ansätze

Schon in den 30er Jahren des 20. Jahrhunderts wurde die Bedeutung von Prozessen in der Organisationsgestaltung von Unternehmen erkannt (vgl. [Körm95], S. 259; [Meis01]; [Nord31]). Eine bessere Übersicht über die betrieblichen Abläufe und eine einfachere Umsetzung einer Flussorientierung in der Organisation wurden damals als Ziele herausgestellt. Ca. 40 Jahre später greift Kosiol den Prozessgedanken wieder auf und stellt einen Ansatz vor, bei dem aus den Unternehmenszielen Aufgaben abgeleitet werden, die Abteilungen und Stellen zugeordnet werden. Diese bilden die Basis für weitere Zerlegungen, die Arbeitsgänge zum Ergebnis haben und konkreten Aufgabenträgern zugeordnet werden (vgl. [Kosi76]).

Die von Kosiol vorgestellte „Top-Down“ Vorgehensweise zur Definition von Prozessen hatte sich jedoch in der Praxis nicht etabliert. Einen entgegengesetzten Ansatz

für Prozessmanagement stellte 1983 Gaitanides vor. Hier sollten „Buttom-Up“ Teilprozesse verändert werden, um in bestimmten Unternehmensbereichen Verbesserungen zu erzielen (vgl. [Körm95], S. 259; [Gait83]).

Gleichzeitig wurde der Prozessgedanke auch immer stärker in Konzepten des Qualitätsmanagements in den Vordergrund gestellt. Konzepte bzw. Standards wie „Total Quality Management“ ²² (TQM) oder „ISO 9000“ ²³ sind ein Beispiel dafür (vgl. [Benn01] S. 4)

Anfang der 90er Jahre setzte sich mit „Business Process Reengineering“ (BPR) ein neuer Ansatz durch, der auf Hammer und Champy zurückgeht (vgl. [Gada03], S. 4]). Es wurde erkannt, dass sich die betrieblichen Funktionsbereiche zunehmend zu autonomen Einheiten entwickelten. Für jeden Bereich gab es spezialisierte Anwendungssysteme („Silo Applikationen“) (vgl. [Strn06]). Der Aufwand für die Entwicklung von Schnittstellen auf technischer und fachlicher Ebene stieg. Eine Lösung des Problems sollte der Fokus auf Prozesse sein.

Das Ziel von BPR ist dabei eine „radikale“ Neukonzeption von Kernprozessen in Unternehmen. Es werden zunächst bestehende, wertschöpfende Prozesse analysiert. Anschließend erfolgt jedoch keine Verbesserung von Prozessen, die Schwachstellen beinhalten, sondern eine komplette Neuentwicklung dieser Abläufe. Im Zuge der Etablierung dieser neuen Prozesse wird keine Rücksicht auf vorhandene Ressourcen im Unternehmen genommen. „Die Erblast jahrzehntelanger ‚Elektrifizierung der Abläufe’“(vgl. [GSVR94], S. 4) wird eliminiert. In [Hamm94], S. 48 werden die Änderungen für Unternehmen mit den Wörtern „radikal“, „dramatisch“ und „fundamental“ beschrieben. Am Ende stehen idealerweise Veränderungen, die signifikante Verbesserungen der Dimensionen Qualität, Kosten, Zeit, Services und Kundennutzen mit sich bringen.

3.1.3 BPM heute - Grundlagen und Ziele

BPR-Projekte haben die Unternehmen zwar auf eine prozessorientierte Sicht gelenkt, jedoch hat sich gezeigt, dass die „Radikalität“ des Ansatzes von BPR in Unterneh- ²² vgl.[ScSe04], S. 9

²³ vgl. [ScSe04], S. 25ff

men auf große Widerstände gestoßen ist. Dies war ein Grund, warum BPR-Projekte oft gescheitert sind (vgl. [ScSe04], S. 252-254). Ein ebenso großer Nachteil des BPR, in [Salk03], S. 18 als „second wave of BPM“ bezeichnet, bestand darin, dass die Implementierung neuer Prozesse weitestgehend nur einzeln per Hand geschehen konnte. Neue Prozesse wurden meist in ERP-Systemen ²⁴ oder in anderen Standardapplikationen realisiert, die Prozesse durch internen Programmcode abbildeten. Dadurch war es kaum möglich, erneute Änderungen an Prozessen vorzunehmen, ohne aufwendig Software zu entwickeln oder anzupassen. (vgl. [Low03], S. 73). Heutzutage gibt es viele Entwicklungen, die den Wettbewerbsdruck auf Unternehmen gesteigert haben und weiter steigern werden (vgl. [Mise06], S. 12). Beispielsweise werden durch Globalisierung, technischen Fortschritt und wechselnde Kundenwünsche Unternehmen immer stärker gefordert, schnell und flexibel auf Veränderungen zu reagieren. Somit ist gerade die Flexibilität, durch Anpassung von Produkten und Prozessen schnellstmöglich auf Veränderungen von Kundenwünschen, Technologien und Märkte einzugehen, heute entscheidend (vgl. [ScSe04], S. 2). BPM in der heutigen Form („the third wave“, vgl. [Salk03]) ist ein Ansatz, der den dazu notwendigen Wandel für alle Ebenen eines Unternehmens unterstützt. Es ist eine Grundlage, flexibel auf neue Rahmenbedingungen (Kundenwünsche, regulatorische Vorschriften etc.) einzugehen und Veränderungen im Unternehmen zu bewirken (vgl. [ScSe04], S. 2; [Mise06], S. 12). Die Vision von BPM, die in [Low03] und [Salk03] beschrieben wird, geht so weit, dass neue Prozessdefinitionen direkt vollautomatisch von Process-Engines ausgeführt werden können (vgl. [Strn06], S. 2). Die Folge wären erhebliche Zeit- und Kosteneinsparungen bei der Umsetzung von neuen Anforderungen. Eine Softwareentwicklung oder der Einsatz von Standard-Unternehmenssoftware wäre hinfällig. In [ScAE05], S. 11 wird beschrieben, wie mit Hilfe der „Service Oriented Architecture“ ²⁵ (SOA) im Kontext des BPMs eine höhere Flexibilität erreicht werden kann.

Neben den genannten Einflüssen von außen gibt es nach wie vor Herausforderungen innerhalb von Unternehmen, die auf Problemen in der Effektivität und Effizienz basieren. Ein Mangel an Effektivität kann sich beispielsweise durch wenig kundenge-

²⁴ ERP:Enterprise Ressource Planning (vgl. [Krcm05], S. 185)

²⁵ Vgl. [Krcm05], S. 274

rechte Produkte äußern. Effizienz-Defizite entstehen durch Prozesse, die viel Zeit in Anspruch nehmen, hohe Kosten verursachen und/oder zu qualitativ schlechten Ergebnissen führen.

BPM hat den Anspruch Effektivitäts- und Effizienzprobleme gleichermaßen zu lösen. Schmelzer und Sesselmann definieren BPM (Geschäftsprozessmanagement) wie folgt:

„Unter Geschäftsprozessmanagement wird ein integriertes Konzept von Führung, Organisation und Controlling verstanden, das eine zielgerichtete Steuerung der Geschäftsprozesse ermöglicht und das gesamte Unternehmen auf die Erfüllung der Bedürfnisse der Kunden und anderer Interessensgruppen (Mitarbeiter, Kapitalgeber, Eigentümer, Lieferanten, Partner, Gesellschaft) ausrichtet.“ (vgl. [ScSe04], S. 5) Mit „Führung“ ist gemeint, dass es für jeden Geschäftsprozess Mitarbeiter gibt, die für die Zielerreichung des Prozesses verantwortlich sind. Läuft ein Prozess nicht nach Plan, so haben diese Verantwortlichen die Aufgabe, Gegenmaßnahmen zu treffen, um Prozesseffektivität und Effizienz nicht zu gefährden. „Organisation“ steht für Aufgaben, die dazu dienen, für eine homogene Prozesslandschaft im Unternehmen zu sorgen. Dazu müssen unter anderem neue Prozesse entworfen werden und in die bestehende Prozessarchitektur integriert werden. In diesem Schritt sind Kriterien zu berücksichtigen, die schließlich einen effizienten und effektiven Ablauf von Prozessen ermöglichen. Zudem ist bei dem Design und der Implementierung von Prozessen die Ausrichtung auf die Kundenbedürfnisse und eine schnelle Reaktion auf sich verändernde Anforderungen entscheidend (vgl. [ScSe04], S. 5f).

Die Aufgabe des (Prozess-) „Controlling“ ist es, Prozessziele zu definieren und diese im Prozessablauf laufend zu messen (vgl. [ScSe04], S. 6). So können Rückmeldungen über den Erfolg von Prozessen gegeben werden. In Kapitel 3.2 erfolgt eine genauere Beschreibung der Aufgaben des BPMs.

Die aktuelle Relevanz des Themas BPM in der Praxis zeigt eine Studie aus dem Jahr 2005 (vgl. [SGKA05], S. 3). In dieser Studie, unter anderem durchgeführt von der TU Wien und der Fachhochschule Bonn-Rhein-Sieg, wurden 176 Unternehmen zum Thema Geschäftsprozessmanagement befragt. Für 57,1% der befragten Unternehmen ist demnach das Thema BPM als „sehr wichtig“ eingestuft worden. 39,3% der Teilnehmer ordneten BPM für ihr Unternehmen als „wichtig“ ein. 77,1% der Firmen

schätzten die Wichtigkeit von BPM für die Zukunft als weiterhin „zunehmend“ ein. Es zeigt sich, dass BPM in der Praxis eine wachsende Bedeutung erhält.

3.2 Phasen des BPMs

Nachdem im letzten Kapitel bereits die Ziele und die aktuelle Relevanz des BPM-Konzepts erläutert wurden, werden im Folgenden anhand von Phasen die zentralen Aufgabenbereiche des Ansatzes in einer logischen Reihenfolge dargelegt.

3.2.1 Phasenmodelle

Um die Effizienz und die Effektivität von Geschäftsprozessen zu verbessern, sind strukturierte Vorgehensweisen notwendig. Kernaufgabe des BPMs ist es, Veränderungen zu planen („Plan“), auszuführen („Do“), den Erfolg der Maßnahmen zu prüfen („Check“) und die Lösung als Standard zu implementieren („Act“) (vgl. [ScSe04], S. 255). Dieses Vorgehen wird auch als „PDCA-“ oder „Deming-Zyklus“ ²⁶ bezeichnet und hat eine kontinuierliche Verbesserung zum Ziel. In der Literatur werden verschiedene Phasenmodelle des BPMs vorgestellt, die allesamt Verbesserungskreisläufe beschreiben.

Becker et al. beschreiben in [BKR00], S. 21 ein Modell, das stark an die allgemeinen Phasen des Projektmanagements angelehnt ist. Schmelzer und Sesselmann bieten ebenfalls ein Modell zur Einführung/Durchführung von BPM an (vgl. [ScSe04], S. 303ff). Auch wenn die Phasen unterschiedlich benannt sind, werden in beiden Modellen die gleichen Kernschritte erörtert. Einen anderen Fokus hat das „HOBE“ ²⁷ -Modell von Scheer. Hier werden weniger organisatorische Maßnahmen zur Etablierung des BPMs im Unternehmen vorgestellt. Im HOBE-Konzept steht die technische Umsetzung von BPM im Vordergrund. Es wird in der Modellierungsphase auf die „EPK-Methodik“ ²⁸ eingegangen und somit der Bezug zu „ARIS“ ²⁹ -Modellierungs-

²⁶ Deming-Zyklus:Verbesserungsmethodik des Qualitätsmanagements nach W. E. Deming

(vgl. [ScSe04], S. 266)

²⁷ HOBE: House Of Business Engineering (vgl. [Sche02], S. 54ff)

²⁸ EPK: Ereignisgesteuerte Prozesskette (Prozessmodellierungsmethode) (vgl. [Sche02], S. 20)

²⁹ Aris: Architektur Integrierter Informationssysteme (vgl. [Sche02])

werkzeugen hergestellt. Ziel ist auch die technische Implementierung der Geschäftsprozesse, die die letzte Phase des Modells formuliert. In jeder Phase werden Werkzeuge und IT-Systeme präsentiert, mit denen die spezifischen Aufgaben erfüllt werden können. Eine Weiterentwicklung des HOBE-Modells ist das „House of Business Process Management“(vgl. [ScAE05], S. 3f). Die ehemals vier Ebenen wurden zu zwei Ebenen zusammengefasst. Eine Strategie-Ebene ergänzt das Modell und stellt auf diese Weise auch die Anforderungen an Geschäftsprozesse heraus. Die Phasen des BPMs werden zyklisch durchlaufen, wenn der Anspruch des BPMs, eine kontinuierliche Verbesserung zu erzielen, erfüllt werden soll. Miserez stellt dazu einen Ansatz vor, der in ähnlicher Form auch häufig im angelsächsischen Raum vorzufinden ist (vgl. [Mise06], S. 17). Hier werden in einem Kreislauf die Phasen „Modeling“, „Execution“ und „Analysis“, denen jeweils Teilschritte zugeordnet sind, durchlaufen. Allerdings fehlen Tätigkeiten, die dem Bereich Strategie zuzuordnen sind. Jost und Kruppke stellen dazu in [Jost04], S. 21 ein BPM-Lebenszyklus Modell vor, das ebenfalls Strategien mit einschließt.

Der BPM-Zyklus wird besonders einfach durch Allweyer deutlich gemacht (vgl. [Allw05], S. 91):

Die Schritte „strategisches Prozessmanagement“, „Prozessentwurf“, „Prozessimplementierung“ und „Prozesscontrolling“ sind in einem Regelkreis angeordnet. Der Zyklus berücksichtigt dabei eine betriebswirtschaftliche Sichtweise auf BPM sowie gleichzeitig eine technische Sichtweise. Dieses Modell-Schema soll in den folgenden Kapiteln dazu dienen, die wichtigsten Aufgaben und Phasen des BPMs herauszustellen. Dabei bilden die Phasen dieses Modells die Ausgangsbasis für die Erläuterungen. Informationen aus den weiter oben genannten Vorgehensmodellen werden ebenso aufgegriffen und fließen an den entsprechenden Stellen mit ein.

3.2.2 Strategische Ebene

Die Einführung von BPM in Unternehmen kann einer Reihe von Zielen dienen. Je nach Ziel sind unterschiedliche BPM-Projekte durchzuführen. Im Sinne des Compliance-Managements müssen beispielsweise bestimmte Geschäftsprozesse dokumentiert werden, um die Einhaltung von Vorschriften zu ermöglichen und zu belegen (vgl. [Glob05]). Beispiele für derartige Gesetze sind der „Sarbanes-Oxley-Act“ (SOX) ³⁰ und „Basel II“ ³¹ . Ebenso kann BPM ein Mittel für die Umsetzung von Qualitätsmanagement sein. Konzepte wie „EFQM“ ³² , „Kaizen“ ³³ , „Six Sigma“ ³⁴ oder ISO 9000 fordern beispielsweise eine ständige Verbesserung von Prozessen. In diesen Beispielen ist das Prozesscontrolling von überragender Bedeutung. Durch die Dokumentation von Prozessen, die durch BPM erreicht wird, wird auch sichtbar, welche Anforderungen das Business an die IT hat. Infolgedessen können Geschäftsprozesse als Grundlage für die Entwicklung oder den Einkauf von Anwendungssystemen dienen. Hier wird deutlich, dass die Phase der Implementierung/Durchführung von besonderer Relevanz ist (vgl. [ScSe04], S. 32f).

Es zeigt sich folglich, dass es kein generelles Vorgehen geben kann, da Ziele und Anforderungen von Unternehmen nicht homogen sind. Ein BPM-Vorgehensmodell ist daher für jedes BPM-Projekt anzupassen. Besonders die Detailtiefe der Modellierung unterscheidet sich stark je nach BPM-Fokus (vgl. [BKR00], S. 157ff). Notwen-

³⁰ Vgl.[Webe06], S. 28

³¹ Vgl. [Webe06], S. 29

³² Vgl. [Zink04], S. 67ff

³³ Vgl. [ScSe04], S. 16f

³⁴ Vgl. [ScSe04], S. 270ff und [KLR04].

dige Tätigkeiten im Rahmen des Projektmanagements für BPM-Vorhaben sind in [BKR00], S. 15ff zu finden. Zentral sind dabei die Kommunikation der Projektziele und die Überzeugung der Mitarbeiter von der Relevanz des Projekts. Im Folgenden wird die Einführung von BPM nicht als Mittel zum Zweck der Verwirklichung von Teilaspekten wie Compliance-Management betrachtet, sondern als Mittel, besser auf veränderte Kundenanforderungen reagieren zu können und die Effizienz und Effektivität von Geschäftsprozessen zu maximieren (siehe Kapitel 3.1.2). Ausgangspunkt ist damit die Unternehmensstrategie. Es muss bekannt sein, welche Kundengruppen das Unternehmen besitzt und welche Anforderungen diese an das Unternehmen stellen (vgl. [ScSe04], S. 81). So können Kernprozesse abgeleitet werden, die dazu dienen, die Kundenanforderungen möglichst exakt zu erfüllen. Für die somit identifizierten Prozesse müssen im nächsten Schritt Ziele und Kennzahlen definiert werden, an denen der Erfolg eines Prozesses gemessen werden kann. Ziele und Kennzahlen für Prozesse sind ebenfalls der Unternehmensstrategie zu assimilieren. Ein Werkzeug zur Entwicklung von Prozesszielen und Ableitung von Kennzahlen ist die „Balanced Scorecard“ ³⁵ . In [ScSe04], S. 210 wird aufgezeigt, wie BPM von der Anwendung dieser Methodik profitieren kann. Beispiele für Kennzahlen und Messgrößen finden sich in [ScSe04], S. 403. Aufgrund sich verändernder Marktbedingungen sollten Kundengruppen, Kundenanforderungen, Prozessziele und Kennzahlen „mindestens einmal jährlich“ (vgl. [ScSe04], S. 82) überprüft werden.

3.2.3 Prozessmodellierung/Design

Anhand der (primären) Kernprozesse sind in der Phase der IST-Modellierung deren Teilprozesse zu bestimmen. Aufgrund der hohen Komplexität werden dazu Teams gebildet, die jeweils für die Modellierung einer begrenzten Anzahl von Prozessen verantwortlich sind (vgl. [BKR00], S. 122).

³⁵ Die Balanced Scorecard ist ein Werkzeug zur Strategieumsetzung. Eine Einführung ist in

[KaNo92] zu finden. Ein Beispiel für die Verwendung des Werkzeugs im IT-Bereich zeigt

[Kütz02].

Teilprozesse ³⁶ bestehen aus Prozessschritten, die ihrerseits aus Arbeitsschritten zusammengesetzt sind (vgl. [ScSe04], S. 84f). So ergeben sich verschiedene Modellierungstiefen. Dabei ist es aufgrund des hohen Aufwands nicht immer sinnvoll, bis auf Ebene der Arbeitsschritte zu modellieren. Außerdem gibt es mitunter diverse Teilprozesse, die nicht direkt Kernprozessen zugeordnet werden können und demzufolge nicht bei der Modellierung berücksichtigt werden müssen. Die modellierten Prozesse sind einer Konsolidierung zu unterziehen, die verwendete Begriffe angleicht und Schnittstellen von Prozessmodellen erkennt. Ziel ist das Erstellen eines integrierten Gesamtmodells, das eine konsistente Sicht auf den IST-Zustand der Prozesslandschaft des Unternehmens zulässt (vgl. [BKR00], S. 129).

Durch die Analyse der IST-Modelle lassen sich bereits Probleme und Schwachstellen erkennen, die in der SOLL-Modellierung besonders berücksichtigt werden können. Die Prozessmodelle können als Vorlage für SOLL-Modelle dienen, so dass Prozesse, die bereits zielkonform ablaufen, in der SOLL-Modellierung nicht neu erstellt werden müssen. Die IST-Modellierung erzeugt allerdings einen hohen Aufwand. Zudem wird kritisiert, dass die Kreativität bei der SOLL-Modellierung durch bereits abgebildete IST-Modelle leidet (vgl. [BKR00], S. 122). So findet beispielsweise die IST-Modellierung in [ScSe04] keine Berücksichtigung. Becker et al. sind jedoch der Meinung, dass eine zumindest „rudimentäre […] IST-Modellierung immer sinnvoll ist“ (vgl. [BKR00], S. 122).

Durch die SOLL-Modellierung wird an die strategische Ebene angeknüpft. Der zu modellierende Detailgrad ³⁷ und die Ziele von Teilprozessen sollten im Einklang mit übergeordneten strategischen Entscheidungen stehen. Im Kontext des Projektmanagements werden Teams gebildet, die jeweils Teilaufgaben bei der Modellierung wahrnehmen. Stehen diese Rahmenbedingungen fest, erfolgt die (Top-Down-) Modellierung von Geschäftsprozessen (vgl. [BKR00], S. 170). Schrittweise werden in der Folge Teilprozesse, Prozessschritte und Arbeitsschritte definiert. Jedem Geschäftsprozess wird ein Prozessverantwortlicher zugeordnet, der für die Erreichung der Prozessziele Verantwortung trägt. Die Arbeitsschritte führen

³⁶ Vorschläge für das Vorgehen bei der Identifizierung von Teilprozessen werden in [BKR00],

S. 125ff postuliert.

³⁷ Nicht immer ist eine möglichst tiefgehende Modellierung sinnvoll. Kosten und Nutzen detail-

lierter Strukturierungen sollten berücksichtigt werden (vgl. [BKR00], S. 172).

Prozessmitarbeiter aus, die bereits im Modell zugeteilt wurden. Die Ausführung von Prozessaktivitäten kann auch durch IT-Ressourcen erfolgen, die im Prozessmodell berücksichtigt werden. An dieser Stelle ist es sinnvoll, Daten, Rollen, IT-Ressourcen und weitere Objekte im Kontext der Prozesse in separaten Modellen abzubilden. So können wichtige Beziehungen zwischen Elementen, die nicht durch einen Prozessablauf determiniert sind, abgebildet werden (vgl. [BKR00], S 171ff). Ein bekanntes Konzept, das Modelle in Sichten einteilt und somit unter anderem zu ganzheitlichen Unternehmensmodellen beitragen kann, die über Prozessabläufe hinausgehen, stellt ARIS dar (vgl. [Sche02], S. 41ff).

Im Zuge der Ablaufgestaltung können durch Maßnahmen, wie beispielsweise Weglassen oder Parallelisierung von Aktivitäten, Effizienz-Steigerungen erreicht werden (vgl. [ScSe04], S. 90f). Für Inputs von Geschäftsprozessen sind Lieferanten zuständig, die interner oder externer Herkunft sein können. Prozessoutputs werden durch Kunden eingefordert. Mit Hilfe von Leistungsvereinbarungen (SLAs) können Inputs und Outputs eindeutig dokumentiert werden. Bei Abweichungen greifen Maßnahmen ein, die den Druck, kontinuierlich die gleiche Leistung zu liefern, erhöhen. Ferner sind Einsparungen von Prozesszeiten und Prozesskosten zu erzielen (vgl. [ScSe04], S. 92).

Die Beurteilung der erstellten SOLL-Modelle kann im gewissen Rahmen bereits vor der Implementierung der Prozesse im Unternehmen geschehen. Mit Hilfe einer computergestützten Simulation ³⁸ der Prozessmodelle werden zum einen syntaktische und semantische Fehler in der Prozessbeschreibung verdeutlicht. Zum anderen können Prozesse ex-ante auf ihre Effizienz untersucht werden, indem die Einhaltung von geplanten Prozesskennzahlen simuliert wird. Eine Voraussetzung für die Simulation sind detailliert definierte Modelle, die beispielsweise genaue Zeitangaben für Aktivitäten beinhalten. Dementsprechend ist der Aufwand der Vorbereitung und der Durchführung einer Simulation generell hoch, so dass auch hier ein hinreichendes Kosten-Nutzen-Verhältnis gegeben sein sollte (vgl. [BKR00], S. 178). Durch den Einsatz von Referenzmodellen bei der Modellierung kann auf vordefinierte Modelle zurückgegriffen werden, die bereits Lösungsvorschläge für Abläufe in

³⁸ Eine Einführung zur Verwendung von Simulation im Bereich BPM ist in [Gad02], S. 169ff zu

finden.

bestimmten Branchen liefern. Becker et al. klassifizieren den Nutzen von Referenzmodellen durch die Kategorien „Kostenminimierung, Erlösmaximierung und Risikominimierung“ (vgl. [BKR00], S. 179). Zeitintensive und kostenintensive Strukturierungen von Unternehmensprozessen entfallen infolgedessen zu großen Teilen. Anhand der vordefinierten Modelle wird das Erlernen von Modellierungsmethoden unterstützt. Auf diese Weise können Kosten eingespart werden. Weiterhin führt das branchenspezifische Know-how, das in den Modellen vorhanden ist, zu Prozessen, die nach ihrer Implementierung dazu beitragen, Kosten zu senken und Erlöse zu generieren. Das Risiko der Modellierung von fehlerhaften Geschäftsprozessen auf höheren Abstraktionsebenen wird stark gesenkt, da die Qualität von Referenzmodellen bereits geprüft wurde.

Den nächsten Schritt der Modellbildung stellt die Konsolidierung der Teilmodelle dar, die durch die einzelnen Projektteams entwickelt wurden. Modelle müssen anein-ander angepasst werden, um ein konsistentes und redundanzfreies Gesamtmodell zu erhalten. Für diese Aufgaben und das Finden von Fehlern in Modellen können Tools ³⁹ verwendet werden, in denen vorzugsweise die gesamte Modellierung vollzogen wird, um aufwendiges Importieren aus verschiedenen Quellen zu vermeiden (vgl. [BKR00], S. 181). Sobald das Gesamtmodell verabschiedet ist, sollte das Modell im gesamten Unternehmen kommuniziert werden.

3.2.4 Implementierung und Durchführung

Nach Allweyer steht zu Anfang der Phase „Prozessimplementierung“ das betriebliche Change Management (vgl. [Allw04], S. 301ff). Für die Implementierung neuer Prozesse ist es entscheidend, dass die Mitarbeiter rechtzeitig über Änderungen informiert werden. Ferner sollten sie von den Vorteilen der Prozessänderungen überzeugt werden, damit frühzeitig Ängste abgebaut werden. Anreizsysteme können dabei die Motivation fördern. Ebenso sind Schulungen notwendig, so dass die betroffenen Mitarbeiter ihre neuen Aufgaben fachlich verstehen und bewältigen können (vgl. [Mise06], S. 20).

³⁹ Vgl. dazu Kapitel 4

Neben den Mitarbeitern, die Aufgaben in Geschäftsprozessen wahrnehmen, spielen die technischen Ressourcen, die die Prozesse unterstützen, eine entscheidende Rolle. Die meisten (größeren) Unternehmen setzen dazu Standard-ERP-Systeme ein (vgl. [Allw05], S. 306). ERP-Systeme haben den Anspruch, Funktionen für eine Vielzahl betrieblicher Anwendungszwecke bereitzustellen (vgl. [Fingar03], S. 236) und ganze Geschäftsprozesse zu unterstützen. Dennoch ist es notwendig, diese Standard-Systeme an die spezifischen Prozesse jedes Unternehmens anzupassen. Dazu bieten ERP-System-Hersteller Referenzmodelle an, die veranschaulichen, welche Geschäftsprozesse durch ihr Produkt in welcher Form abgedeckt werden. Das Unternehmen SAP stellt beispielsweise Modelle zur Verfügung, die zusätzlich an den entsprechenden Stellen Informationen über die Customizing ⁴⁰ -Möglichkeiten bereitstellen (vgl. [Allw05], S. 319). Im nächsten Schritt ist ein Abgleich von den definierten SOLL-Modellen der Phase „Modellierung“ mit den Referenzmodellen der ERP-Hersteller notwendig. Hierdurch kann erkannt werden, inwiefern die Software einem Customizing unterzogen werden muss, um die SOLL-Prozesse möglichst exakt abzubilden. In vielen Fällen reicht Customizing jedoch nicht aus, um die Software an die Anforderungen von Unternehmen anzugleichen. Folglich muss zusätzlich entsprechende Software entwickelt werden, die durch Schnittstellen zu ERP-Systemen weitere Funktionalitäten integrieren. Vor dem Hintergrund des Aufwands, zusätzliche Programme zu schreiben, besteht die Gefahr, dass die Unternehmensprozesse an die in ERP-Systemen implementierten Prozesse angepasst werden. Dadurch könnten bei Kernprozessen individuelle Vorteile gegenüber der Konkurrenz aufgegeben werden, wenn ein standardisierter ERP-Prozess verwendet wird. Sinnvoller ist die Nutzung von ERP-Paketen für (Sekundär-) Prozesse, die nicht direkt der Wertschöpfung beitragen. Insofern können Best-Practices für (Standard-) Prozesse genutzt werden, die sich in verschiedenen Unternehmen wenig unterscheiden (vgl. [Allw05], S. 318). Neben dem Weg Prozesse über Standardsoftware umzusetzen, kann auch Individualsoftware der Prozessimplementierung dienen. Wie oben angedeutet, ist dies beispielsweise auch dann erforderlich, wenn ein verwendetes ERP-System Kernfunktionen nicht beinhaltet. Dabei können Prozesse den Startpunkt einer Softwareentwicklung darstellen, um die Anforderungen zu definieren. ARIS ist dabei ein Beispiel für

⁴⁰ Customizing: Bezeichnung für die Anpassung von Standardsoftware (vgl. [Krcm05], S. 186)

ein Konzept, das eine Methodik für die systematische Umsetzung von Anforderungen, die (unter anderem) in Prozessen definiert sind, in Informations- und Kommunikationstechnik beschreibt (vgl. [Sche02], S. 38ff).

Einen anderen Ansatz Geschäftsprozesse technisch einzuführen stellen „Workflow-Management-Systeme“ ⁴¹ dar. Diese Systeme sind die elektronische Umsetzung der klassischen Vorgangsbearbeitung. Dokumente werden dabei nicht papierbasiert von Mitarbeiter zu Mitarbeiter weitergeleitet, sondern in Form von elektronischen Vorgangsmappen in „virtuelle Postkörbe“ desjenigen Mitarbeiters abgelegt, der nach der Prozessdefinition den nächsten Schritt der Vorgangsbearbeitung übernimmt (vgl. [Allw05], S. 322). Für die Bearbeitung von Arbeitsaufträgen können durch Workflow-Management-Systeme automatisch entsprechende Programme an verschiedenen Arbeitsplatzrechnern geöffnet werden. Darüber hinaus können beispielsweise auch bestimmte Programmfunktionen eines ERP-Systems aufgerufen werden, so dass ein Mitarbeiter nur noch bestimmte Eingabefelder auszufüllen hat (vgl. [Allw05], S. 322). Letztlich dienen Workflow-Management-Systeme zwar der „Prozessplanung und Prozesssteuerung, nicht aber der Prozessausführung im Detail“ (vgl. [Gada03], S. 247). Für die Bereitstellung von spezifischen Funktionen sind andere Systeme (z.B. ERP) verantwortlich. Laut Gadatsch ist ebenfalls die Integration von Workflow-Modulen in ERP-Systemen möglich. Der zentrale Vorteil dabei ist, dass Geschäftsprozesse über die verschiedenen ERP-Module hinweg definiert werden können. Allerdings sind die Workflows auf die Funktionalitäten des ERP-Systems beschränkt (vgl. [Gada03], S. 320ff).

Durch „Enterprise Application Integration“ ⁴² (EAI) gibt es die Möglichkeit, beliebige Anwendungen zu koppeln. Die Benutzung eines EAI-Systems erlaubt die Nutzung vorhandener, heterogener Systeme und vermindert die Anzahl zu programmierender Schnittstellen zwischen diesen Systemen. Während ferner der Datenfluss zwischen verschiedenen Anwendungen vereinfacht wird, wird der Kontrollfluss, der Abläufe von Geschäftsprozessen widerspiegelt, wenig unterstützt. Die Lösung der Probleme

⁴¹ Eine Definition zu „Workflow“ findet sich unter [Gada03], S. 33. In [Holl95] werden Konzep-

te von Workflow-Management-Systemen erläutert.

⁴² Vgl. [Allw05], S. 338 ff