Die obige Abbildung soll die „Anwendungslogik“ der Prozesse verdeutlichen, welche die Leistungserstellung, des Unternehmens für das die Diplomarbeit erstellt wird, konstituieren. Beispielhaft wird hier nur der Prozess “Risikomanagement” mit den Teilprozessen R_1 bis R_6 aufgeführt.

Dabei zeigt die Abbildung die Dimensionen der Agilität, die sichergestellt werden sollte, auf. Das Unternehmenswachstum das auf der Abszisse abgetragen ist und die angestrebten Entwicklungsstufen des CMMI, welche in der Zukunft angestrebt werden können, verkörpern eine Form von Agilität. Die Entwicklungsstufen geben dabei den möglichen Entwicklungspfad vor, lassen aber Spielraum für die unternehmensindividuelle Ausgestaltung. Werden im Geschäftsjahr 2008 im Bereich des Projektmanagements die Projektplanung, die Projektverfolgung und Steuerung und das Management von Lieferantenvereinbarungen und im Bereich Ingenieurdisziplinen das Anforderungsmanagement sowie im Bereich der Unterstützung eine Messung und Analyse, eine Qualitätssicherung von Prozessen und Produkten sowie ein Konfigurationsmanagement im Sinne des CMMI (Definition der spezifischen Ziele und Auswahl der für TwentyOne sinnvollen Praktiken etc.) ausgestaltet, kann der Reifegrad “definiert” als Verbesserungsziel (“nächste Stufe”) bis zum Geschäftsjahr 2010 angestrebt werden. Die Verbesserungsaktivitäten sollten sich somit auf das Prozessmanagement (Organisationsweiter Prozessfokus, Organisationsweite Prozessdefinition, Organisationsweites Training) ausdehnen, ein integriertes Projektmanagement und verbessertes Risikomanagement forcieren, die Ingenieurdisziplinen weiter systematisieren und strukturieren (Anforderungsentwicklung, technische Umsetzung, Produktintegration, Verifikation, Validation) und eine fundierte Entscheidungsanalyse und -findung etablieren.

Der Leistungserstellungsprozess sowie die Wertsicherung und das Lernen werden den Prozessgruppen parallel zu der Ordinate gegenübergestellt. Die Prozessmodule (bspw. das Risikomanagement) werden mit Hilfe der dispositiven Geschäftsregeln an die
verschiedenen Projekttypen (z. B. Kleinprojekt = Typ A, Projekt= Typ B) angepasst. Der mit dem x gekennzeichnete Punkt zeigt dabei, welche Teilprozesse (R_1 – R_2) für welchen Projekttyp durchgeführt werden müssen, wobei der Gestaltungsrahmen für den Prozessgestalter durch Geschäftsregeln aufgespannt wird (solche dispositiven Regeln -vgl. jeweiligen Datenblättern Interne Dokumente – sichern also Agilität, da man mit ihnen unterschiedlichste Umweltzustände abbilden kann). Die übrigen Teilprozesse (schwarzer Punkt) müssen projektindividuell ausgestaltet werden. Operative Geschäftsregeln können hier den konkreten Prozessverlauf noch weiter spezifizieren.

Als dritte „Dimension“ der Agilität ist folgendes Vorgehen entwickelt worden. Das betreffende Unternehmen kann nun für jedes Prozessmodul (z.B. Risikomanagement) und dessen Teilprozesse feststellen, ob sie schon im Unternehmen durchgeführt werden oder ob sie für die Zukunft geplant sind. Zum Einsatz kann hier die Matrix mit den Process Groups und den Knowledge Areas (Vgl. PMBOK) mit den jeweiligen Teilprozessen kommen.

Ähnlich der Ampelfunktion bei der Anwendung der Geschäftsregeln (siehe Abbildung am Anfang des Beitrags) kann in der Matrix jeder Teilprozess betrachtet und evaluiert werden. Ein weiteres Instrument in diesem Zusammenhang ist die Übersicht/ Checkliste über die Projektmanagementmethoden(Vgl. Gareis/ Stummer, Projekte & Prozesse, 2006). In dieser kann für die verschiedenen Projekttypen festgelegt werden welche Methoden angewandt werden „müssen“ und welche angewandt werden „können“.

Die zu untersuchenden Bodies of Knowledge sind auf verschiedenen “Ebenen” anzusiedeln. Die folgende Abbildung versucht dies grafisch darzustellen:

Das CMMI ist grundsätzlich generischer als das PMBOK. Dies schließt jedoch nicht aus, dass mit Hilfe des CMMI konkrete Lösungsvorschläge erarbeitet werden können. Die Zielsetzung des CMMI lässt jedoch bei der Auswahl geeigneter Maßnahmen mehr Freiraum. Aus dem PMBOK können konkrete Prozesse bzw. deren Input und Output sowie Werkzeuge & Techniken gewonnen werden.

Das Project Management Body of Knowledge (PMBOK) Werk wird in der Kategorie „Standards und Richtlinien“ vom Project Management Institute, Inc. (PMI) publiziert. Der vollständige Name ist „A Guide to Project Management Body Of Knowledge“.

Der PMBOK Leitfaden ist in drei Blöcke aufgeteilt. Der erste Block führt in die Thematik des Projektmanagements ein. Neben grundlegenden Definitionen wird der Kontext in dem Projektmanagement stattfindet beschrieben. In dem zweiten Teil werden alle Projektmanagementprozesse beschrieben, die von dem Projektteam gebraucht werden, um ein Projekt managen zu können. Diese 44 Projektmanagementprozesse werden in fünf Projektmanagementgruppen gegliedert. Die Prozessgruppen sind „Initiating Process Group“, „Planning Process Group“, Executing Process Group“, Monitoring and Controlling Process Group“ und „Closing Process Group“. Die 44 Projektmanagementprozesse werden abschließend in neun “Project Management Knowledge Areas” gegliedert. Diese Struktur wird in der folgenden Strukturdarstellung aufgezeigt:

Für jede Project Management Area, bzw. für jeden involvierten Projektmanagementprozess werden der Input, Tools & Techniques und der Output spezifiziert.

Im folgenden Beitrag wird das ITIL Framework dargestellt. Im unteren Bereich des Beitrags wird eine Präsentation veröffentlicht die das Basis-ITIL-Framework “Service Support” beinhaltet und eine Bewertung dieser Basisgruppe ermöglichen soll:

ITIL

Entwicklungshintergrund

Die Abkürzung ITIL steht für „Information Technology Infrastructure Library“. Es besteht aus einer Sammlung von Dokumenten, die sich mit den Untergruppen des IT-Managements auseinander setzen und beinhaltet ein Prozessmodell für den gesamten Bereich des IT-Service-Managements. ITIL ist ursprünglich eine Entwicklung der britischen Regierung. Herausgeber, Mitte der 80er-Jahre, war die „Central Computer and Telecommunications Agency“ der britischen Regierung. Das Ziel war es Mittel und Wege zu finden die stetig steigenden IT-Kosten der Behörden in den Griff zu bekommen.

Die Ausarbeitungen bilden ein neutrales also herstellerunabhängiges Best-Practices-Regelwerk. ITIL bietet einen Standard für strategische, operative und taktische Geschäftsprozesse und Steuerungsmechanismen an. Neben dem systematischen Aufbau von Prozessen können IT Infrastrukturen effizient gesteuert und entwickelt werden. Folgende Punkte sind nach Elsässer die wichtigsten Merkmale von ITIL:

• Ein Best Practices-Rahmenwerk, das allgemein gültig abgefasst ist und aus bewährten Lösungsansätzen der IT-Praxis vieler Organisationen besteht.
• Ein nicht proprietärer und herstellerunspezifischer De-facto-Standard für das IT-Management und die IT-Services.
• Eine systematische Vorgehensweise im IT-Management Oberster Grundsatz bei ITIL ist die Ausrichtung der IT als Lieferant von Dienstleistungen (IT-Service-Management-Orientierung)
• Eine Leitlinie für Prozessoptimierungen, d.h. die IT-Prozesse sollten sich an den Geschäftsprozessen orientieren.
• Oberster Grundsatz bei ITIL ist die Ausrichtung der IT als Lieferant von Dienstleistungen (IT-Service-Management-Orientierung)
• Bereitstellung von Vorgaben und Anregungen um Anpassungen an neue Anforderungen schnell realisieren zu können.
• Permanenter Ausbau und Weiterentwicklung.
• Klare Definition von wenigen Hauptprozessen und Darbietung als Sammlung von Prozessmodellen.
• Unterschiedliche Zertifizierungsmodelle durch ITIL-Gremien.

Aufbau

Seit dem Jahre 2002 besteht das Framework ITIL aus sieben Hauptbereichen (auch Sets oder Module genannt), mit über 20 Einzelprozessen die einen Rahmen vorgeben, wie ein optimaler IT-Service aussehen könnte und wie dieser implementiert werden kann.
In den aktuellen Versionen sind folgende Kategorien beschrieben:

• Basisgruppe 1: Service Support (beinhaltet alle Aktivitäten, die für die Unterstützung eines geregelten Betriebes benötigt werden. Er soll für die Nutzer eines DV – Verfahrens zentralisiert, meist in Form eines Service Desk, von einer Stelle abrufbar sein.) Es gibt hier fünf Basisprozesse

1.1 Incident-Management

1.2 Problem-Management

1.3 Configuration-Management

1.4 Change-Management

1.5 Release-Management

• Basisgruppe 2: Service Delivery (sind alle Aktivitäten und Prozesse, welche der strategischen Unterstützung des IT-Managements dienen. Hier werden auch die Service Level Agreements für die Leistungserbringung mit dem Kunden abgestimmt) Es gibt hier fünf Grundprozesse:

2.1 Service-Level-Management

2.2 Financial-Management

2.3 Availability-Management

2.4 Capacity-Management

2.5 Continuity- Management

• Information and Communication Technology-Infrastructure Management (ICT – IM): Hier wird die eigentliche Infrastruktur betrieben. Es werden im Wesentlichen die Gebiete IT-Deployment, IT-Operation, IT-Design and Plan und IT-Technical Support abgedeckt.

• Security Management: Hauptaufgabe ist das zur Verfügung stellen von Informationen und der Schutz vor unbefugtem Zugriff.

• Planning to implement: In diesem Buch wird die Planung, Einführung und fortlaufende Verbesserung der ITIL Prozesse behandelt.

• The Business Perspektive: Gegenstand der Publikation ist die Geschäftsbeziehung zwischen Kunden und Lieferanten der Serviceleistung.

• Application Management: Im Wesentlichen umfasst dies die Gebiete Software Life Cycle Support und Testing IT-Services for operational use.

Abbildung: ITIL Komponenten im Überblick

Die beiden Basis-ITIL-Frameworks (Service Support und Service Delivery) bilden das Zentrum eines IT Services innerhalb einer Firma und decken das Tagesgeschäft im IT-Service ab. ITIL ist stark auf die IT-Services fokussiert. Dies ist nicht das Kerngeschäft des Unternehmens in dessen Auftrag die Diplomarbeit erstellt wird. Es erscheint dem Autor sinnvoll eine strenge Selektion der ITIL Best Practices vorzunehmen um eventuelle Transfermöglichkeiten aus diesem Body of Knowledge zu evaluieren. Eine Übersicht über den Bereich “Service Support” ist hier dargestellt. Diese Präsentation ist folgendermaßen aufgebaut:

• Zuerst wird der Service Support grafisch aufgearbeitet.

• Es werden alle Disziplinen des Service Support mit einer „Registerkarte“ überblickartig dargestellt. (diese Darstellung gliedert sich in Kurzbeschreibung, Beispiele, Aufgaben und Funktionen, Ziele, Prozess, Einführung/Schnittstellen/ Key Performance Indicators)

• Nach jeder Disziplin kommt jeweils ein Slide das die Disziplin grafisch aufbereitet und Raum für eine Evaluation gibt. Hier soll nicht zuletzt mit Hilfe des Weblog diskutiert werden, ob ITIL bzw. einzelne ITIL Prozesse sich für das betreffende Unternehmen eignen und transferiert werden können oder nicht.

Download: Dieser Beitrag mit Quellenangaben

Das Basis-ITIL-Framework “Service Delivery” wird baldmöglichst aufgearbeitet werden.

Auf der Seite “Bodies of Knowledge” wird eine Basis für die Auswahl von Prozesse aus dem Capablity Maturity Model Integration dargestellt. Die Auswahl von zu transferierenden Prozessen, Zielen und Praktiken kann auf dieser Grundlage stattfinden.

Die einzelnen Prozessgebiete werden in dem hinterlegten Dokument wie folgt dargestellt:

Die Bewertung bezieht sich auf die Vereinbarkeit mit agilen Praktiken, Methoden und Vorgehensweisen und basiert auf der Präsentation “Agil/Lean Development and CMMI” auf den Seiten des SEI. Diese Bewertung wird auf der Seite “Bodies of Knowledge” weiter vertieft.

Die Begriffe, welche CMMI verwendet werden in Kommentaren (AGn) detailliert. Daneben gibt es Kommentare die zusätzliche inhaltliche Erläuterungen der Prozessgebiete enthalten. Auch Instrumente werden stellenweise vorgeschlagen. Diese Ergänzungen basieren auf dem Buch von Kneuper, R.: CMMI, Verbesserung von Softwareprozessen mit CMMI. Es werden die Prozessgebiete “Projektmanagement”, “Prozessmanagement”, “Unterstützung” und “Ingenieurdisziplinen” mit ihren jeweiligen Zielen und Praktiken ausgeführt.