Links zu grafischen Darstellungen/ Summaries:

Abbildungen

Management Summaries:

CMMI

ITIL

Wissensgebiete auf Basis des PMBOK:

Integrationsmanagement:

Visio-Integrationsmanagement in Projekten_EPK Darstellung

Wissensgebiet_Integrationsmanagement in Projekten_070802

Teilprozesse des Integrationsmangements:

Prozessstammblatt_070802_Integrationsmanagement_I_ 1

Prozessstammblatt_070802_Integrationsmanagement_I_ 2

Prozessstammblatt_070802_Integrationsmanagement_I_ 3

Prozessstammblatt_070802_Integrationsmanagement_I_ 4

Prozessstammblatt_070802_Integrationsmanagement_I_ 5

Prozessstammblatt_070802_Integrationsmanagement_I_ 6

Prozessstammblatt_070802_Integrationsmanagement_I_ 7

Risikomanagement:

Visio-Risikomanagement in Projekten_EPK Darstellung

Wissensgebiet_Risikomanagement in Projekten_070712

Teilprozesse des Risikomanagements:

Prozessstammblatt_070713_Risikomanagement_R_ 1

Prozessstammblatt_070712_Risikomanagement_R_ 2

Prozessstammblatt_070712_Risikomanagement_R_ 3

Prozessstammblatt_070712_Risikomanagement_R_ 4

Prozessstammblatt_070708_Risikomanagement_R_ 5

Prozessstammblatt_070712_Risikomanagement_R_ 6

Kommunikationsmanagement:

Visio-Kommunikationsmanagement in Projekten_EPK Darstellung

Wissensgebiet_Kommunikationsmanagement in Projekten_070802

Teilprozesse des Kommunikationsmanagements:

Prozessstammblatt_070802_Kommunikationsmanagement_C_ 1

Prozessstammblatt_070802_Kommunikationsmanagement_C_ 2

Prozessstammblatt_070802_Kommunikationsmanagement_C_ 3

Prozessstammblatt_070802_Kommunikationsmanagement_C_ 4

Übrige Wissensgebiete:

Visio-Inhalts- und Umfangsmanagement in Projekten

Visio-Qualtitätsmanagement in Projekten

Visio-Beschaffungsmanagent in Projekten

Visio-Personalmanagement in Projekten

Visio-Terminmanagement in Projekten

Visio-Kostenmanagement in Projekten

Hier können Sie vorab das Inhaltsverzeichnis, Abbildungsverzeichnis und Abkürzungsverzeichnis einsehen (Stichwortverzeichnis).

Im Folgenden ein kurzer Auszug aus der Zielsetzung der Arbeit (die Diplomarbeit wurde in Kooperation mit der TwentyOne GmbH erstellt):

Ziel der Arbeit ist es, Flexibilitätsbedarfe bei dem Entwurf des Prozessmanagementsystems zu beachten und Organisationsstrukturen zu entwerfen, die einer steigenden Komplexität gerecht werden. Das Prozessmanagementsystem wird hierzu „agil“ (Agilität bezeichnet die Fähigkeit schnell auf Veränderungen reagieren zu können) gestaltet. Dies geschieht durch die Verwendung von Ansätzen für agiles Prozessmanagement (vgl. Kapitel 4) welche in konkreten Beispielen angewendet werden (vgl. Kapitel 5.2). Die spezifische Unternehmenssituation der TwentyOne (vgl. Kapitel 2.2: Das Unternehmen), die durch starkes Wachstum und die Positionierung als Mittelständler geprägt ist, erfordert eine Ausrichtung der Strukturen an den Prozessen und hier speziell an denjenigen Prozessen, welche die Kundenschnittstelle darstellen. Folgende Eigenschaften prägen auch die Unternehmenssituation der TwentyOne, die typisch für den Mittelstand ist. … Da die TwentyOne stark wächst und in einem dynamischen Umfeld agiert dürfen die Organisationsstrukturen nicht starr sein. Sie müssen flexibel anpassbar, also agil gestaltet werden. Die historisch gewachsenen, eher informellen Strukturen, sollen durch bewusst gestaltete Strukturen ergänzt oder ersetzt werden. Die schnellen und unbürokratischen Entscheidungswege mögen in der jetzigen Situation (TwentyOne hat noch unter 50 Mitarbeiter) ausreichen. Die Unternehmensleitung hat jedoch erkannt, dass für die Zukunft die Flexibilität und Entscheidungsfreudigkeit durch entsprechende Strukturen gesichert werden muss. Bis zu einer gewissen Unternehmensgröße kann wohl auf eine formale Gestaltung der Organisation verzichtet werden. Eine adäquate Organisation ist für den Mittelstand jedoch als strategische Maßnahme für die Zukunftssicherung unverzichtbar. Eben diese Zukunftssicherung soll durch das Prozessmanagementsystem geschaffen werden. …

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

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.

Es gibt vier grundlegende Transformationsregeln um EPK Modelle in die ECAA Notation zu überführen. Diese sind in der folgenden Grafik dargestellt:

Wenn man nun eine ECAA Regel betrachtet enthält diese implizit eine Selektion. Die folgende Abbildung zeigt die allgemeine Modellierung einer Selektion mit Hilfe der EPK:

Auch die Möglichkeiten der Gestaltung paralleler Abläufe werden direkt von der EPK Notation unterstützt. Man beachte aber stets, dass in beiden Notationen der Kontrollfluss durch einen Operator des gleichen Typs wieder geschlossen werden muss.

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.

Um mit Geschäftsregeln Systeme und Informationssysteme modellieren zu können, müssen diese bestimmt Kerneigenschaften aufweisen, damit sie im Sinne von Modellierungselementen verwendet werden können und das angestrebte Nutzenpotential erschlossen werden kann:

• Orientierung an Geschäftsprozessen: Geschäftsregeln müssen die Geschäftslogik enthalten. Eindeutigkeit und Präzision bei der Beschreibung der Regeln ist hierbei notwendig.
• Deklarative Beschreibung: Die Geschäftsregeln beinhalten nicht den konkreten Lösungsweg im Einzelfall.
• Formuliert in natürlicher Sprache: Hierdurch ist vorerst keine Übersetzung notwendig.
• Atomare Regeln: Eine einzelne Regel darf keine andere Regel enthalten. Dies ist jedoch nur auf der untersten Modellierungsebene möglich. Allgemein gehaltene oder globale Regeln können andere Regeln beinhalten.
• Nachvollziehbarkeit: Der Entstehungshintergrund und die Herkunft der Regel sollte bekannt sein und festgehalten werden. Ist eine Regel aus einer anderen Regel abgeleitet worden, so sollte dies feststellbar sein.
• Strukturiertheit: Es sollten einheitliche Formulierungen gewählt werden um die Vielfalt und damit die Komplexität zu reduzieren.

Für eine Regelmenge die einen bestimmten abgegrenzten Unternehmensbereich, z.B. einen Geschäftsprozess, beschreibt sollten ebenso bestimmte Eigenschaften eingehalten werden. Zuerst müssen die Regeln den Realitätsausschnitt umfassend beschreiben. Dabei dürfen sich die einzelnen Regeln jedoch nicht überschneiden oder widersprechen. Damit bei einer Veränderung des Unternehmensbereichs eine Regelanpassung stattfindet, und die Regeln weiterentwickelt werden, müssen Verantwortlichkeiten für einzelne Ausschnitte der Realität und der damit verbundenen Regeln festgelegt werden.

Abbildung: Formale Beschreibung von Geschäftsregeln in EA, ECA, ECAA Notation

Abläufe mit der ECAA Notation modellieren

Ähnlich wie bei der Ereignisgesteuerten Prozesskette entstehen regelbasierte Abläufe dadurch, dass bei der Ausführung des Aktionsteils der Regel ein Ereignis eintritt, welches andere Regeln auslösen kann. Die Möglichkeiten der Modellierung von Sequenzen, Selektionen, Iterationen und Parallelitäten durch Geschäftsregeln werden im Folgenden erläutert. Dabei zeigen Folgepfeile innerhalb der Aktionskomponente die „auslösende Funktion“ dieser an. Es tritt ein (Folge-)Ereignis, welches für eine andere Regel relevant ist, ein.

Sequenz: Einfache Sequenzen werden durch die EA Regel modelliert. Im Aktionsteil dieser Regel tritt ein Ereignis ein, dass für die nächste Aktivität relevant ist.

Abbildung: Modellierung einer Sequenz mit Geschäftsregeln

Selektion: Ebenso wie bei der EPK kann eine Selektion sowohl exklusiv mit einem XOR oder nicht exklusiv mit einem OR modelliert werden. Man spricht hier auch von einem XOR bzw. OR-Split. Die ECAA Regel beinhaltet immer einen XOR Split, da nach der Bedingungsprüfung (IF) immer eine der beiden Aktionen ausgeführt wird. Die Zusammenführung des Splits ist durch folgende Möglichkeiten zu realisieren:

• Die aufgeteilten Abläufe lösen jeweils ein identisches Ereignis aus. Damit „fließen“ die alternativen Abläufe wieder zusammen.
• Die alternativen Abläufe werden in einer folgenden Geschäftsregel mit einer Disjunktion (Im Kontext der regelbasierten Modellierung werden komplexe Ereignisse die durch einen XOR oder durch einen ODER verknüpft sind als Disjunktionsereignisse bezeichnet) verbunden.

Für weitere Spezifikationen alternativer Teilprozess sei auf Knolmayer u.a. (Vgl. Knolmayer u.a. 1997, S. 16 f)
verwiesen.

Iteration: Durch den XOR Split lassen sich auch iterative Abläufe modellieren, indem in einem der Aktionsteile einer ECAA Regel ein Ereignis ausgelöst wird, das wiederum eine Regel aktiviert, die im Ablauf des Prozesses schon einmal aktiviert wurde.

Parallelität: Parallele Abläufe können grundsätzlich durch zwei Konstruktionsideen modelliert werden:

• Mehrere Regeln werden durch dasselbe Ereignis ausgelöst. Nach Eintreten dieses Ereignisses werden alle aktivierten Geschäftsregeln parallel ausgeführt.
• Im Aktionsteil einer Regel werden mehrere konjunktiv (AND) verknüpfte Ereignisse aktiviert. Diese wiederum sind Auslöser (event) paralleler Abläufe

Zusammengeführt werden die parallelen Teilprozesse, indem in einer weiteren Regel im Eventteil die letzten Aktionen (bzw. deren (Folge-)Ereignisse) der parallelen Prozesszweige konjunktiv verknüpft werden.

Der ECAA Ansatz kann, um in der Unternehmensmodellierung mehr Relevanz zu erlangen, um strukturelle Aspekte (Zuordnung einer Organisationseinheit zu einer Regel oder Regelkomponente, Erweiterung um ein Informationsobjekt, Beschreibung der verbundenen Arbeitsschritte) sowie um temporale Aspekte (Gültigkeitszeiten von Ereignissen, Reaktion auf in einem bestimmten Zeitintervall nicht eingetretenes Ereignis) erweitert werden.

Sequenz: Sequenzielle Abläufe sind sehr einfach durch Ketten, in denen Ereignisse und Funktionen sich abwechseln, zu modellieren. Da keine Operatoren zum Einsatz kommen, hat jedes Ereignis und jede Funktion sowohl einen eingehenden, als auch einen ausgehenden Pfeil. Somit werden die Elemente sequentiell abgearbeitet.

Selektion: Alternative Abläufe werden mit den Operatoren XOR bzw. „ODER“ modelliert. Die Entscheidung über eine der Alternative wird innerhalb der davor stehenden Funktion getroffen. Ereignisse kommen hierfür nicht in Betracht.

Iteration: Nach Knolmayer u.a. werden iterative Teilprozesse mit einer Funktion dargestellt, in der die Entscheidung über Widerholung oder Nicht-Wiederholung erfolgt. Ein XOR Operator wird eingefügt, aus dem ein ausgehender Pfeil die Iteration über den bereits durchlaufenen Teil der EPK darstellt. Dieser ausgehende Pfeil wird ebenso über einen XOR Operator in die EPK wieder eingeschleift. Staud ergänzt, dass die Rückschleife mit einem Ereignis beginnen kann, das den Bedarf an der Wiederholung eines Abschnittes aufzeigt. Die Folgenden Darstellungen zeigen diese Möglichkeiten:

Abbildung : Zyklische EPK

Parallelität: Parallele Abläufe können mit dem UND Operator modelliert werden. Die parallelen Teilprozesse können dabei von einer Funktion ausgehen, die zwei oder mehrere Ereignisse auslöst bzw. von einem Ereignis ausgehen das zwei oder mehrere Funktionen auslöst. Die Teilprozesse werden auch wieder über einen UND Operatorzusammengeführt.

Funktionen: Die in einem Geschäftsprozess zu leistenden Tätigkeiten werden in Funktionen erfasst. Es wird also beschrieben was gemacht werden soll. Funktionen können zerlegt bzw. aggregiert werden. Eine Zerlegung sollte jedoch dort enden, wo die einzelne Funktion in einem Arbeitsablauf bearbeitet wird und keine betriebswirtschaftlich sinnvolle Zerlegung mehr stattfinden kann. Somit beschreibt eine Funktion innerhalb eines EPK Modells je nach Abstraktionsgrad eine Aktivität des Geschäftsprozesses, die bei Bedarf verfeinert werden kann.

Ereignisse: Bei diesem Begriff beschränkt man sich auf betriebswirtschaftlich relevante Ereignisse, die Abläufe im Unternehmen beeinflussen und steuern. Ereignisse beschreiben die Ergebnisse oder die Bedingungen für die Ausführung von Funktionen und können wie diese zusammengefasst oder zerlegt werden. Die Ereignisse müssen sich hier an dem Aggregationsniveau der Funktionen orientieren. Für die Funktionsverknüpfung ist es wichtig zu betonen, dass Ereignisse passive Objekttypen sind.

Prozesswegweiser: Diese Elemente werden in der Praxis häufig verwendet. Sie sind ein Verweis auf andere EPK und symbolisieren den weiteren Verlauf eines Prozesses in einer anderen EPK auf die hierdurch referenziert wird. Es gibt drei Gründe Epks durch Prozesswegweiser miteinander zu verknüpfen:

1.      Ein unübersichtlicher Prozess (bzw. eine unübersichtliche, lange EPK) muss in verschiedene Teilprozesse aufgeteilt werden.

2.   Kleine EPKs werden in zahlreichen anderen Teilprozessen benötigt. Durch den Verweis auf diese wird die Modellierung vereinfacht.

3.   Die Zusammenhänge von Geschäftsprozessen sollen erfasst werden.

Es gibt bei einer Modellierung mit einem Prozesswegweiser immer zwei EPKs. Eine „aufrufende EPK“ enthält einen Prozesswegweiser, der den Aufruf eines anderen Prozesses signalisiert. Eine „aufgerufene EPK“ in der ein Prozesswegweiser anzeigt, dass sie aufgerufen wurde. Daraus leiten sich folgende Regeln ab:

• Der Prozesswegweiser in einer aufrufenden EPK steht an Stelle einer Funktion und gibt sowohl die Verknüpfungsstelle an, als auch welche EPK aufgerufen werden soll.

• Der Prozesswegweiser in einer aufgerufenen EPK, steht anstelle einer Funktion und auch die Verknüpfungsstelle an. Daneben bezeichnet er von welcher EPK der Aufruf kommt.

• Das Ereignis vor dem Prozesswegweiser in der aufrufenden EPK wird nach dem Prozesswegweiser wiederholt. Hierdurch kann man sich das Zusammenführen der zwei EPKsvorstellen.

Operatoren: Die Verknüpfungsoperatoren legen die jeweilige Ablauflogik innerhalb eines Geschäftsprozesses fest. Ein Verknüpfungsoperator kann entweder eine Eingangs- und mehrere Ausgangskanten (Operator = Verteiler) oder mehrere Eingangs- und eine Ausgangskante (Operator = Verknüpfer) haben. Es werden die konjunktiven („UND“), disjunktiven („XOR“) und adjunktiven („ODER“) Operatoren benötigt, da in der Praxis Funktionen von mehreren Ereignissen angestoßen werden und auch mehrere Ereignisse auslösen. Mit diesen Operatoren lassen sich nun zwei verschieden Verknüpfungsarten differenzieren. Die Ereignisverknüpfung verknüpft zwei oder mehrere Ereignisse mittels eines Operators mit einer Funktion. Bei einer Funktionsverknüpfung verbindet der Operator zwei oder mehrere Funktionen mit einem Ereignis. Alle möglichen Kombinationen sind in der unten stehenden Abbildung, eingezeichnet. Man beachte, dass die Funktionsverknüpfung mit einem auslösenden Ereignis nur über eine „UND“ Verknüpfung möglich ist, da, wie bei der Erläuterung der Ereignisse erwähnt, die Passivität dieser keine aktive Entscheidung erlaubt. „ODER“ und „XOR“ Verbindungen sind in diesem Fall also nicht möglich.

Download: Dieser Beitrag mit Quellenangaben

Konstruktionsvorschlag 1: Modularisierung

Der Aufbau der Prozesse erfolgt hier zusammensetzen von Modulen. Die einzelnen Module bestehen aus Schnittstellen und einem Kern. Im Kern ist die eigentliche Funktionalität in freien Bausteinen festgehalten.

Konstruktionsvorschlag 2: Entkopplung der Module

Die erforderliche Flexibilität der Prozesse, d.h. ein Vorhalten von Wandlungsfähigkeit, wird durch die Entkopplung der einzelnen Module erreicht. Somit entstehen autonome Prozessmodule, bzw. Teilprozesse, die situationsbezogen, aber zielgerichtet zusammengeführt werden können.

Konstruktionsvorschlag 3: Modul Intra- und Interflexibilität

Der Konstruktionsvorschlag 1 und 2 erzeugen Flexibilität auf zwei Ebenen:

• Modul-Intraflexibilität: Die freien und entkoppelten Prozessbausteine können innerhalb eines Moduls beliebig kombiniert werden.

• Modul-Interflexibilität: Die entkoppelten Teilprozesse bzw. Prozessmodule können beliebig zu einem Gesamtprozess zusammengeführt werden.

Konstruktionsvorschlag 4: Selbststeuernde Prozesskonfiguration

Durch die gewonnene Flexibilität entsteht Komplexität. Es wird ein „Kopplungssystem“ notwendig, dass die Methodik sowie die notwendigen Umweltinformationen enthält, um die Module zu einem Gesamtprozess zusammenführen zu können. Damit besteht nicht die Notwendigkeit, alle möglichen Modulkombinationen vorzuhalten. Wird Wandlungsbedarf durch eine nicht beeinflussbare Umweltveränderung ausgelöst, wird eine entsprechende Prozessvariante selbständig erzeugt. Aber das Wandlungspotential ist nicht explizit modelliert, sondern liegt in dem skizzierten modul-inter- und intraflexiblen Kopplungssystem.

Konstruktionsvorschlag 5: „Kernmodell“

Im Kernmodell werden zwingend notwendige Prozessmodule festgelegt. Die Notwendigkeit dieses Modells können zum einen spezifische Unternehmensziele oder Prozessziele sein, die es zu erreichen gilt. Zum anderen können rechtliche Verordnungen ein Kernmodell erzwingen. Daneben verhindert das Kernmodell Willkürlichkeit bei der Prozesszusammenstellung und Prozessdurchführung.