1 Einleitung
2 Grundlagen des IT-Servicemanagements
2.1 Fokus und Ziele des IT-Servicemanagements
2.2 ITIL als de-facto Standard für das ITSM
2.2.1 Service Delivery
2.2.2 Service Support
2.3 Cobit und ISO 20000
3 BPM-Werkzeuge
3.1 Grundlagen und Ziele des BPM-Ansatzes
3.1.1 Geschäftsprozesse: Kern- und Sekundärprozesse
3.1.2 Frühere Ansätze
3.1.3 BPM heute - Grundlagen und Ziele
3.2 Phasen des BPMs
3.2.1 Phasenmodelle
3.2.2 Strategische Ebene
3.2.3 Prozessmodellierung /Design
3.2.4 Implementierung und Durchführung
3.2.5 Konzepte des Prozesscontrollings
3.3 BPM-Tools und -Suites
3.4 Potenziale von BPM-Tools im ITSM
3.4.1 Schnittmengen der Konzepte BPM und ITSM
3.4.2 BPM-Tools im Fokus ITSM
3.5 Ableitung und Beschreibung der Fragestellungen dieser Arbeit
4 Evaluation
4.1 Methodische Vorgehensweise der Evaluation
4.2 Bestehende Konzepte zur BPM-Softwarebewertung
4.3 Entwicklung des Kriterienkatalogs
4.3.1 Anforderungen an einen Kriterienkatalog
4.3.2 Ableitung von Kategorien und Kriterien
4.3.3 Bewertungsmaßstab und Gewichtung der Kriterien
4.4 Auswahl und Beschreibung der Evaluationsobjekte
4.4.1 BOC Adonis/Adoit
4.4.2 IDS-Scheer Aris
4.4.3 EMPRISE Bonapart
4.5 Evaluation der Tools
4.5.1 Aris
4.5.1.1 Nicht-Funktionale Kriterien
4.5.1.1.1 Systemvoraussetzungen und Performanz
4.5.1.1.2 Datenhaltung und Datenkonsistenz
4.5.1.1.3 Konzept der Mehrbenutzerfähigkeit
4.5.1.1.4 Hilfefunktion und Dokumentation
4.5.1.1.5 Menüführung und allgemeine Bedienbarkeit
4.5.1.1.6 Import- und Exportfunktionalitäten
4.5.1.2 Modellierung
4.5.1.2.1 Modellerstellung
4.5.1.2.2 Modellverwaltung und Sichtenkonzept
4.5.1.2.3 Strategische Planung
4.5.1.2.4 ITIL Referenzmodell
4.5.1.2.5 Weitere ITSM Referenzmodelle
4.5.1.2.6 ITSM spezifische Modellklassen
4.5.1.2.7 Anpassbarkeit des Metamodells
4.5.1.3 Analyse und Simulation
4.5.1.3.1 Statische Analysen von Modellen
4.5.1.3.2 Simulation
4.5.1.3.3 Dynamische Analysen
4.5.1.4 Implementierung, Durchführung und Auswertung
4.5.1.4.1 Vorgehensmodelle zur Einführung von ITSM
4.5.1.4.2 Automatische Ablaufunterstützung
4.5.1.4.3 Prozesscontrolling
4.5.2 Bonapart
4.5.2.1 Nicht-Funktionale Kriterien
4.5.2.1.1 Systemvoraussetzungen und Performanz
4.5.2.1.2 Datenhaltung und Datenkonsistenz
4.5.2.1.3 Konzept der Mehrbenutzerfähigkeit
4.5.2.1.4 Hilfefunktion und Dokumentation
4.5.2.1.5 Menüführung und allgemeine Bedienbarkeit
4.5.2.1.6 Import/Export Funktionalität
4.5.2.2 Modellierung
4.5.2.2.1 Modellerstellung
4.5.2.2.2 Modellverwaltung und Sichtenkonzept
4.5.2.2.3 Strategische Planung
4.5.2.2.4 ITIL Referenzmodell
4.5.2.2.5 Weitere ITSM Referenzmodelle
4.5.2.2.6 ITSM spezifische Modellklassen
4.5.2.2.7 Anpassbarkeit des Metamodells
4.5.2.3 Analyse und Simulation
4.5.2.3.1 Statische Analysen von Modellen
4.5.2.3.2 Simulation
4.5.2.3.3 Dynamische Analysen
4.5.2.4 Implementierung, Durchführung und Auswertung
4.5.2.4.1 Vorgehensmodelle zur Einführung von ITSM
4.5.2.4.2 Automatische Ablaufunterstützung
4.5.2.4.3 Prozesscontrolling
4.5.3 Adonis/Adoit
4.5.3.1 Nicht-Funktionale Kriterien
4.5.3.1.1 Systemvoraussetzungen und Performanz
4.5.3.1.2 Datenhaltung und Datenkonsistenz
4.5.3.1.3 Konzept der Mehrbenutzerfähigkeit
4.5.3.1.4 Hilfefunktion und Dokumentation
4.5.3.1.5 Menüführung und allgemeine Bedienbarkeit
4.5.3.1.6 Import- und Exportfunktionalitäten
4.5.3.2 Modellierung
4.5.3.2.1 Modellerstellung
4.5.3.2.2 Modellverwaltung und Sichtenkonzept
4.5.3.2.3 Strategische Planung
4.5.3.2.4 ITIL Referenzmodell
4.5.3.2.5 Weitere ITSM Referenzmodelle
4.5.3.2.6 ITSM spezifische Modellklassen
4.5.3.2.7 Anpassbarkeit des Metamodells
4.5.3.3 Analyse und Simulation
4.5.3.3.1 Statische Analysen
4.5.3.3.2 Simulation
4.5.3.3.3 Dynamische Analyse
4.5.3.4 Implementierung, Durchführung und Auswertung
4.5.3.4.1 Vorgehensmodelle zur Einführung von ITSM
4.5.3.4.2 Automatische Ablaufunterstützung
4.5.3.4.3 Prozesscontrolling
4.6 Gesamtergebnis
5 Diskussion der Ergebnisse
5.1 Nutzen der Tools für BPM
5.1.1 Modellierung
5.1.2 Analyse und Simulation
5.1.3 Prozessdurchführung und -controlling
5.2 Nutzen der Tools im ITSM
5.2.1 Tool-Vergleich anhand der Kriterien des ITSMs
5.2.2 Stärken und Schwächen von BPM-Tools im ITSM
6 Zusammenfassung und Ausblick
Abbildungsverzeichnis
Abbildung 1: Zentrale ITIL-Prozessbereiche in Anlehnung an [Zarn05], S. 20
Abbildung 2: BPM-Zyklus in Anlehnung an [Allw05], S. 91
Abbildung 3: BPMS-Architektur in Anlehnung an [Allw05], S. 346
Abbildung 4: BPM-Tools in Anlehnung an [HaHa05], S. 1
Abbildung 5: Grafischer Überblick der Vorgehensweise der Evaluation
Abbildung 6: Funktionsebenen von BPM-Tools in Anlehnung an [Freu06], S. 30
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
Tabellenverzeichnis
Tabelle 1: Kriterienkatalog für Modellierungstools in Anlehnung an [Nütt02]
Tabelle 2: Kriterienkatalog
Tabelle 3: Bewertungsgrade der Kriterien
Tabelle 4: Gewichtungsklassen
Tabelle 5: Klassenzuordnung
Tabelle 6: Klassengewichtung
Tabelle 7: Auswertung
Tabelle 8: Auswertung „Modellierung“
Tabelle 9: Auswertung „Analyse und Simulation“
Tabelle 10: Auswertung „Prozessdurchführung und -controlling“
Tabelle 11: Auswertung ITSM
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
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[1] 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[2], orientieren, die „Common-Practice“[3] -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)[4] postuliert. Im Kontext des Managements von Geschäftsprozessen ist die Verwendung von BPM-Tools[5] 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“[6] und „CRM[7] -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[8] und des Service Delivery[9], 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 Beantwortung 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 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.
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[11] für das IT-Servicemanagement vorgestellt. Zudem werden Möglichkeiten einer Software-Unterstützung des Servicemanagements aufgezeigt.
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-Manage-ments 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 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[12] 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 Anforderungen 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):
- Marktorientierung: Business und IT sind nicht mehr nur Projektpartner, sondern Kunden und Lieferanten. Dabei werden Leistungen und Kosten vertraglich festgelegt.
- Serviceorientierung: Gegenstand des Angebotsportfolios von IT-Lieferanten sind IT-Services, die von Kunden eingekauft werden.
- 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.
- Prozessorientierung: Im Zuge des ITSMs werden keine funktionalen Einheiten betrachtet, sondern die Prozesse, die dazu dienen, anforderungskonforme IT-Services bereitzustellen.
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[13] 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[14] 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“[15] und „Service Delivery“[16] zusammen. Im Folgenden werden diese beiden Prozessbereiche beschrieben. Informationen zu „Business Perspective“ sowie den Prozessbereichen „Application Management“, „Infrastructure Management“ (siehe Abbildung 1) und „Planning to implement Service Management“[17] finden sich in [Zarn05], [BKP02] und [HeCa02]. Auf diese Bereiche wird des Weiteren nicht näher eingegangen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Zentrale ITIL-Prozessbereiche in Anlehnung an [Zarn05], S. 20
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 Funktionalitä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 Monitoring 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 erheblichem 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).
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“[18] 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.
Während ITIL konkrete Vorschläge für die Durchführung von Prozessen im ITSM gibt, definiert Cobit[19] 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[20], der im Bereich IT-Revision[21] 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]).
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).
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.
Funktionale Organisationsstrukturen - in der Praxis weit verbreitet - gliedern Unternehmen nach Verrichtungen bzw. Funktionen (vgl. [Schr03], S. 129). Eine Funktionsorientierung 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).
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“[22] (TQM) oder „ISO 9000“[23] 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.
BPR-Projekte haben die Unternehmen zwar auf eine prozessorientierte Sicht gelenkt, jedoch hat sich gezeigt, dass die „Radikalität“ des Ansatzes von BPR in Unternehmen 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[24] 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-Unter-nehmenssoftware wäre hinfällig. In [ScAE05], S. 11 wird beschrieben, wie mit Hilfe der „Service Oriented Architecture“[25] (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 kundengerechte 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.
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.
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“[26] 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“[27] -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“[28] eingegangen und somit der Bezug zu „ARIS“[29] -Modellierungs-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):
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: BPM-Zyklus in Anlehnung an [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 eben-so aufgegriffen und fließen an den entsprechenden Stellen mit ein.
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)[30] und „Basel II“[31]. Ebenso kann BPM ein Mittel für die Umsetzung von Qualitätsmanagement sein. Konzepte wie „EFQM“[32], „Kaizen“[33], „Six Sigma“[34] 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). Notwendige 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.
[...]
[1] Im Folgenden wird die Abkürzung „ITSM“ verwendet.
[2] IT Infrastructure Library (vgl. Kapitel 2)
[3] Ebenfalls wird in der Literatur der Ausdruck „Best Practice“ verwendet (vgl. [Zarn05]; [Somm04]).
[4] 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.
[5] „BPM-Tools“ bieten grundsätzlich Funktionen, die das Potenzial haben, die Planung, das Prozesscontrolling und die Durchführung von Prozessen zu unterstützen (vgl. [Strn06], S. 5ff).
[6] 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 Analyse 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.
[7] Customer Relationship Management (vgl. [Krcm05], S. 469)
[8] Siehe dazu Erläuterungen in Kapitel 2.2.1.
[9] Siehe dazu Erläuterungen in Kapitel 2.2.2.
[10] Vgl. für die Beschreibung oben genannter Funktionalitäten beispielsweise „BOC Adoit“, http://www.boc-eu.com.
[11] Eine Übersicht über weitere Initiativen und Standards des ITSMs wird in [HeLe05], S. 293 veranschaulicht.
[12] Weitere Ausführungen zum Begriff des IT-Services finden sich in [Hupp06], S. 15ff und [MeSp04], S. 15ff.
[13] OGC: Office of Governance Commerce, IT-Dienstleister der britischen Regierung (vgl. [BKP02], S. 9).
[14] 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.
[15] “Service Support”-Originalquelle: [BHJL00]
[16] “Service Delivery”-Originalquelle: [BHJK01]
[17] “Planning to implement Service Management”-Originalquelle: [LPRW02]
[18] 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.
[19] Control Objectives for Information and related Technology (vgl. [ITGI05]).
[20] Vgl. [HeLe05], S. 64ff
[21] Vgl. [HeLe05], S. 197ff
[22] vgl. [ScSe04], S. 9
[23] vgl. [ScSe04], S. 25ff
[24] ERP: Enterprise Ressource Planning (vgl. [Krcm05], S. 185)
[25] Vgl. [Krcm05], S. 274
[26] Deming-Zyklus: Verbesserungsmethodik des Qualitätsmanagements nach W. E. Deming (vgl. [ScSe04], S. 266)
[27] HOBE: House Of Business Engineering (vgl. [Sche02], S. 54ff)
[28] EPK: Ereignisgesteuerte Prozesskette (Prozessmodellierungsmethode) (vgl. [Sche02], S. 20)
[29] Aris: Architektur Integrierter Informationssysteme (vgl. [Sche02])
[30] Vgl. [Webe06], S. 28
[31] Vgl. [Webe06], S. 29
[32] Vgl. [Zink04], S. 67ff
[33] Vgl. [ScSe04], S. 16f
[34] Vgl. [ScSe04], S. 270ff und [KLR04].
