Viele Unternehmen behandeln die Themen Projekt- und Prozessmanagement als eigenständige Disziplinen, indem sie z.B. unterschiedliche Organisationseinheiten mit der jeweiligen Systemgestaltung betrauen. Unsere Beratungspraxis zeigt, dass spätestens bei der Implementierung eines Prozessmanagementsystems oder dem Aufbau eines Multiprojektmanagements eine übergreifende Betrachtung erforderlich wird. Eine wesentliche Schnittstelle beider Systeme ist die standardisierte Beschreibung von Projekten als Geschäftsprozesse. Dies sichert einerseits eine qualitativ hochwertige Abwicklung von Projekten und andererseits ihre Vergleichbarkeit aus Sicht der Unternehmensführung. Dieser Artikel zeigt eine in der Praxis mehrfach bewährte Möglichkeit, um diese Schnittstelle zu gestalten und damit Projektmanagement in das Prozessmanagementsystem zu integrieren.
Die Begriffe "Projekt" und "Prozess" werden meist inflationär eingesetzt und ihre Bedeutung ist in vielen Fällen nicht klar abgegrenzt. Vor allem Personen, die nicht selbst "Projektmanager" oder "Prozessmanager" sind, tendieren oft dazu, die Begriffe abweichend von ihrer eigentlichen Bedeutung oder gleichbedeutend zu verwenden. Daher stellt sich als erstes die Frage: Wo liegen die Gemeinsamkeiten und Unterschiede zwischen Projekt und Prozess?
Projekte sind durch die Einmaligkeit in der Gesamtheit ihrer Bedingungen definiert. Damit ist gemeint, dass sich zwei Projekte stets aufgrund bestimmter Rahmenbedingungen voneinander unterscheiden. Beispielsweise unterscheiden sich zwei Straßenbauprojekte durch unterschiedliche Geländebedingungen und verschiedene Stakeholder. Die Aufgaben in Projekten sind häufig stark vernetzt. Das Fehlen einer spezifizierten bzw. standardisierten Vorgehensweise bringt eine hohe Unsicherheit in der Zielerreichung mit sich. Daher können Projekte häufig nicht in der bestehenden Aufbauorganisation abgewickelt werden. Statt dessen bedürfen Projekte einer interdisziplinären Zusammenarbeit, für deren Koordination eine temporäre Organisation (Team) gebildet wird, die mit dem Projektende wieder aufgelöst wird.
Im Geschäftsprozessmanagement betrachten wir mit Prozessen permanente Aufgaben, die den Grundfunktionen des Unternehmens entsprechen und damit in dessen Stammorganisation erfüllt werden. In diesem Zusammenhang sprechen wir von wiederkehrenden Abläufen, deren Vorgehensweisen in Arbeitsanweisungen, Prozessbeschreibungen oder anderen Regelwerken spezifiziert sind. Der hohe Spezifikationsgrad und die Routine in der Aufgabenerfüllung gewährleisten in der Regel die Zielerreichung. Jeder, der einen Prozess ausführt, muss sich deshalb vollständig an dessen Definition halten und hat dabei keinen Gestaltungsfreiraum.
Verschiedene Normen und Modelle im Projektmanagement sprechen von Prozessen, Projektprozessen, Projektmanagementprozessen, Führungsprozessen und weiteren Bezeichnungen, die meist nicht eindeutig und vor allem nicht einheitlich definiert sind. Hier ist es zunächst wichtig, die weitgehende Definition eines Prozesses im Sinne von Ablauf (procedere) von der wesentlich engeren Betrachtung im Geschäftsprozessmanagement zu unterscheiden.
Im Geschäftsprozessmanagement geht es darum, dokumentierte, zielgerichtete, standardisierte und nicht zuletzt verbindliche Abläufe zu gestalten. Im Projektmanagement hingegen gehen wir von einmaligen, komplexen und dynamischen Situationen aus, die ein flexibles Handeln erfordern. Wie kann eine Betrachtung und Gestaltung von Projekten als Geschäftsprozesse funktionieren?
Wir unterscheiden zwei Dimensionen von Prozessen in Projekten: Prozesse zur Erarbeitung der Produkte/Ergebnisse des Projekts (inhaltliche Dimension, project scope) und Prozesse zur Planung, Steuerung und Koordination der Projektinhalte, der Teamarbeit sowie des Wissenstransfers (Managementdimension). Von dieser Unterteilung geht z.B. die geplante Norm DIN 69901 aus, die ebenfalls die inhaltliche Dimension (Projektprozess) von der Managementdimension (Projektmanagementprozess) abgrenzt.
Wenn wir nicht den Projektinhalt sondern die Planung und Steuerung der Inhaltserarbeitung betrachten, so weisen diese Managementaufgaben unabhängig vom Projekt eine ähnliche Struktur auf. Die Aufgaben im Rahmen der Planung, Steuerung und des Abschlusses von Projekten sind in ihrer Grundfunktion unabhängig vom Projektinhalt. Betrachtet man diese Aufgaben über mehrere Projekte hinweg, so erkennt man, dass sie viele Eigenschaften der Definition von Geschäftsprozessen annehmen. Das Erstellen eines Projektstrukturplans, das Formulieren von Projektzielen, die Ausarbeitung eines Projektauftrags oder die Bildung einer Projektorganisation sind - projektübergreifend betrachtet wiederkehrende Aufgaben. Deren Unsicherheit in der Zielerreichung ist zumindest bei erfahrenen Projektleitern unbedeutend. Der Ablauf ihrer Arbeitsschritte kann abhängig von der Betrachtungsebene auch sequentiellen Charakter annehmen, selbst wenn ihr Inhalt stets ein anderer ist. Eine Prozessorientierung im Projektmanagement ist auch bei den gängigen Projektmanagement-Normen und -Standards wie dem PMBOK Guide oder der neuen DIN 69901 vorhanden. Umfangreiche Aufgaben wie die Projektplanung sind in vielen Fällen in einem Prozessschritt gewissermaßen in einer "Black Box" zusammengefasst.
Viele Unternehmen behandeln die Themen Projekt- und Prozessmanagement als eigenständige Disziplinen, indem sie z.B. unterschiedliche Organisationseinheiten mit der jeweiligen Systemgestaltung betrauen. Unsere Beratungspraxis zeigt, dass spätestens bei der Implementierung eines Prozessmanagementsystems oder dem Aufbau eines Multiprojektmanagements eine übergreifende Betrachtung erforderlich wird. Eine wesentliche Schnittstelle beider Systeme ist die standardisierte Beschreibung von Projekten als Geschäftsprozesse. Dies sichert einerseits eine qualitativ hochwertige Abwicklung von Projekten und andererseits ihre Vergleichbarkeit aus Sicht der Unternehmensführung. Dieser Artikel zeigt eine in der Praxis mehrfach bewährte Möglichkeit, um diese Schnittstelle zu gestalten und damit Projektmanagement in das Prozessmanagementsystem zu integrieren.
Die Begriffe "Projekt" und "Prozess" werden meist inflationär eingesetzt und ihre Bedeutung ist in vielen Fällen nicht klar abgegrenzt. Vor allem Personen, die nicht selbst "Projektmanager" oder "Prozessmanager" sind, tendieren oft dazu, die Begriffe abweichend von ihrer eigentlichen Bedeutung oder gleichbedeutend zu verwenden. Daher stellt sich als erstes die Frage: Wo liegen die Gemeinsamkeiten und Unterschiede zwischen Projekt und Prozess?
Projekte sind durch die Einmaligkeit in der Gesamtheit ihrer Bedingungen definiert. Damit ist gemeint, dass sich zwei Projekte stets aufgrund bestimmter Rahmenbedingungen voneinander unterscheiden. Beispielsweise unterscheiden sich zwei Straßenbauprojekte durch unterschiedliche Geländebedingungen und verschiedene Stakeholder. Die Aufgaben in Projekten sind häufig stark vernetzt. Das Fehlen einer spezifizierten bzw. standardisierten Vorgehensweise bringt eine hohe Unsicherheit in der Zielerreichung mit sich. Daher können Projekte häufig nicht in der bestehenden Aufbauorganisation abgewickelt werden. Statt dessen bedürfen Projekte einer interdisziplinären Zusammenarbeit, für deren Koordination eine temporäre Organisation (Team) gebildet wird, die mit dem Projektende wieder aufgelöst wird.
Im Geschäftsprozessmanagement betrachten wir mit Prozessen permanente Aufgaben, die den Grundfunktionen des Unternehmens entsprechen und damit in dessen Stammorganisation erfüllt werden. In diesem Zusammenhang sprechen wir von wiederkehrenden Abläufen, deren Vorgehensweisen in Arbeitsanweisungen, Prozessbeschreibungen oder anderen Regelwerken spezifiziert sind. Der hohe Spezifikationsgrad und die Routine in der Aufgabenerfüllung gewährleisten in der Regel die Zielerreichung. Jeder, der einen Prozess ausführt, muss sich deshalb vollständig an dessen Definition halten und hat dabei keinen Gestaltungsfreiraum.
Verschiedene Normen und Modelle im Projektmanagement sprechen von Prozessen, Projektprozessen, Projektmanagementprozessen, Führungsprozessen und weiteren Bezeichnungen, die meist nicht eindeutig und vor allem nicht einheitlich definiert sind. Hier ist es zunächst wichtig, die weitgehende Definition eines Prozesses im Sinne von Ablauf (procedere) von der wesentlich engeren Betrachtung im Geschäftsprozessmanagement zu unterscheiden.
Im Geschäftsprozessmanagement geht es darum, dokumentierte, zielgerichtete, standardisierte und nicht zuletzt verbindliche Abläufe zu gestalten. Im Projektmanagement hingegen gehen wir von einmaligen, komplexen und dynamischen Situationen aus, die ein flexibles Handeln erfordern. Wie kann eine Betrachtung und Gestaltung von Projekten als Geschäftsprozesse funktionieren?
Wir unterscheiden zwei Dimensionen von Prozessen in Projekten: Prozesse zur Erarbeitung der Produkte/Ergebnisse des Projekts (inhaltliche Dimension, project scope) und Prozesse zur Planung, Steuerung und Koordination der Projektinhalte, der Teamarbeit sowie des Wissenstransfers (Managementdimension). Von dieser Unterteilung geht z.B. die geplante Norm DIN 69901 aus, die ebenfalls die inhaltliche Dimension (Projektprozess) von der Managementdimension (Projektmanagementprozess) abgrenzt.
Wenn wir nicht den Projektinhalt sondern die Planung und Steuerung der Inhaltserarbeitung betrachten, so weisen diese Managementaufgaben unabhängig vom Projekt eine ähnliche Struktur auf. Die Aufgaben im Rahmen der Planung, Steuerung und des Abschlusses von Projekten sind in ihrer Grundfunktion unabhängig vom Projektinhalt. Betrachtet man diese Aufgaben über mehrere Projekte hinweg, so erkennt man, dass sie viele Eigenschaften der Definition von Geschäftsprozessen annehmen. Das Erstellen eines Projektstrukturplans, das Formulieren von Projektzielen, die Ausarbeitung eines Projektauftrags oder die Bildung einer Projektorganisation sind - projektübergreifend betrachtet wiederkehrende Aufgaben. Deren Unsicherheit in der Zielerreichung ist zumindest bei erfahrenen Projektleitern unbedeutend. Der Ablauf ihrer Arbeitsschritte kann abhängig von der Betrachtungsebene auch sequentiellen Charakter annehmen, selbst wenn ihr Inhalt stets ein anderer ist. Eine Prozessorientierung im Projektmanagement ist auch bei den gängigen Projektmanagement-Normen und -Standards wie dem PMBOK Guide oder der neuen DIN 69901 vorhanden. Umfangreiche Aufgaben wie die Projektplanung sind in vielen Fällen in einem Prozessschritt gewissermaßen in einer "Black Box" zusammengefasst.
…Viele Unternehmen behandeln die Themen Projekt- und Prozessmanagement als eigenständige Disziplinen, indem sie z.B. unterschiedliche Organisationseinheiten mit der jeweiligen Systemgestaltung betrauen. Unsere Beratungspraxis zeigt, dass spätestens bei der Implementierung eines Prozessmanagementsystems oder dem Aufbau eines Multiprojektmanagements eine übergreifende Betrachtung erforderlich wird. Eine wesentliche Schnittstelle beider Systeme ist die standardisierte Beschreibung von Projekten als Geschäftsprozesse. Dies sichert einerseits eine qualitativ hochwertige Abwicklung von Projekten und andererseits ihre Vergleichbarkeit aus Sicht der Unternehmensführung. Dieser Artikel zeigt eine in der Praxis mehrfach bewährte Möglichkeit, um diese Schnittstelle zu gestalten und damit Projektmanagement in das Prozessmanagementsystem zu integrieren.
Die Begriffe "Projekt" und "Prozess" werden meist inflationär eingesetzt und ihre Bedeutung ist in vielen Fällen nicht klar abgegrenzt. Vor allem Personen, die nicht selbst "Projektmanager" oder "Prozessmanager" sind, tendieren oft dazu, die Begriffe abweichend von ihrer eigentlichen Bedeutung oder gleichbedeutend zu verwenden. Daher stellt sich als erstes die Frage: Wo liegen die Gemeinsamkeiten und Unterschiede zwischen Projekt und Prozess?
Projekte sind durch die Einmaligkeit in der Gesamtheit ihrer Bedingungen definiert. Damit ist gemeint, dass sich zwei Projekte stets aufgrund bestimmter Rahmenbedingungen voneinander unterscheiden. Beispielsweise unterscheiden sich zwei Straßenbauprojekte durch unterschiedliche Geländebedingungen und verschiedene Stakeholder. Die Aufgaben in Projekten sind häufig stark vernetzt. Das Fehlen einer spezifizierten bzw. standardisierten Vorgehensweise bringt eine hohe Unsicherheit in der Zielerreichung mit sich. Daher können Projekte häufig nicht in der bestehenden Aufbauorganisation abgewickelt werden. Statt dessen bedürfen Projekte einer interdisziplinären Zusammenarbeit, für deren Koordination eine temporäre Organisation (Team) gebildet wird, die mit dem Projektende wieder aufgelöst wird.
Im Geschäftsprozessmanagement betrachten wir mit Prozessen permanente Aufgaben, die den Grundfunktionen des Unternehmens entsprechen und damit in dessen Stammorganisation erfüllt werden. In diesem Zusammenhang sprechen wir von wiederkehrenden Abläufen, deren Vorgehensweisen in Arbeitsanweisungen, Prozessbeschreibungen oder anderen Regelwerken spezifiziert sind. Der hohe Spezifikationsgrad und die Routine in der Aufgabenerfüllung gewährleisten in der Regel die Zielerreichung. Jeder, der einen Prozess ausführt, muss sich deshalb vollständig an dessen Definition halten und hat dabei keinen Gestaltungsfreiraum.
Verschiedene Normen und Modelle im Projektmanagement sprechen von Prozessen, Projektprozessen, Projektmanagementprozessen, Führungsprozessen und weiteren Bezeichnungen, die meist nicht eindeutig und vor allem nicht einheitlich definiert sind. Hier ist es zunächst wichtig, die weitgehende Definition eines Prozesses im Sinne von Ablauf (procedere) von der wesentlich engeren Betrachtung im Geschäftsprozessmanagement zu unterscheiden.
Im Geschäftsprozessmanagement geht es darum, dokumentierte, zielgerichtete, standardisierte und nicht zuletzt verbindliche Abläufe zu gestalten. Im Projektmanagement hingegen gehen wir von einmaligen, komplexen und dynamischen Situationen aus, die ein flexibles Handeln erfordern. Wie kann eine Betrachtung und Gestaltung von Projekten als Geschäftsprozesse funktionieren?
Wir unterscheiden zwei Dimensionen von Prozessen in Projekten: Prozesse zur Erarbeitung der Produkte/Ergebnisse des Projekts (inhaltliche Dimension, project scope) und Prozesse zur Planung, Steuerung und Koordination der Projektinhalte, der Teamarbeit sowie des Wissenstransfers (Managementdimension). Von dieser Unterteilung geht z.B. die geplante Norm DIN 69901 aus, die ebenfalls die inhaltliche Dimension (Projektprozess) von der Managementdimension (Projektmanagementprozess) abgrenzt.
Wenn wir nicht den Projektinhalt sondern die Planung und Steuerung der Inhaltserarbeitung betrachten, so weisen diese Managementaufgaben unabhängig vom Projekt eine ähnliche Struktur auf. Die Aufgaben im Rahmen der Planung, Steuerung und des Abschlusses von Projekten sind in ihrer Grundfunktion unabhängig vom Projektinhalt. Betrachtet man diese Aufgaben über mehrere Projekte hinweg, so erkennt man, dass sie viele Eigenschaften der Definition von Geschäftsprozessen annehmen. Das Erstellen eines Projektstrukturplans, das Formulieren von Projektzielen, die Ausarbeitung eines Projektauftrags oder die Bildung einer Projektorganisation sind - projektübergreifend betrachtet wiederkehrende Aufgaben. Deren Unsicherheit in der Zielerreichung ist zumindest bei erfahrenen Projektleitern unbedeutend. Der Ablauf ihrer Arbeitsschritte kann abhängig von der Betrachtungsebene auch sequentiellen Charakter annehmen, selbst wenn ihr Inhalt stets ein anderer ist. Eine Prozessorientierung im Projektmanagement ist auch bei den gängigen Projektmanagement-Normen und -Standards wie dem PMBOK Guide oder der neuen DIN 69901 vorhanden. Umfangreiche Aufgaben wie die Projektplanung sind in vielen Fällen in einem Prozessschritt gewissermaßen in einer "Black Box" zusammengefasst.
Im Rahmen des Geschäftsprozessmanagements werden diese "Black Boxes" aufgelöst, indem eindeutig definierte Prozesse gestaltet werden, die sich durch eine Folge festgelegter Arbeitsschritte auszeichnen. Es wird nicht nur vorgegeben, was zu tun ist, sondern auch in welcher Reihenfolge es zu tun ist. Damit soll eine routinemäßige Abwicklung des Geschäftsprozesses hergestellt werden, die eine definierte Qualität der Prozessergebnisse (Outputs) gewährleisten. Dabei differenziert sich das Geschäftsprozessmanagement von den oben angeführten Modellen und Normen, da es die Prozesse in ihrem Ablauf zum Beispiel in Form von Flussdiagrammen beschreibt und damit die "Black Boxes" auflöst.
"Projekte managen" ist ein Prozess der bei jedem Projekt, das im Unternehmen abgewickelt wird, gestartet und ausgeführt wird. Damit liegt es nahe, im Sinne des Prozessmanagements eine Standardisierung des Prozesses anzustreben. Spätestens beim Aufbau eines Multiprojektmanagements im Unternehmen ist der Bedarf nach einer Gestaltung des Prozesses "Projekte managen" gegeben, da ein Multiprojektmanagement auf einem funktionierenden und standardisierten Einzelprojektmanagement aufbaut. Der Prozess "Projekte managen" regelt dabei, welche Arbeitsschritte einzuhalten sind, wer für die Aufgabenerfüllung zuständig ist und definiert die Schnittstellen zur Multiprojektmanagement-Ebene.
Im Folgenden soll am Beispiel eines Beratungsunternehmens, das einerseits Beratungsleistungen in der Managementberatung anbietet und andererseits als Trainingsanbieter am Markt positioniert ist, aufgezeigt werden, wie der Geschäftsprozess "Projekte managen" im Prozessmanagementsystem integriert werden kann. Alle anfallenden Aufgaben werden von einem Prozessteam wahrgenommen. Dieses setzt sich zusammen aus internen Personen des Unternehmens, die Wissen und Erfahrung im Projektmanagement und/oder in der Prozessgestaltung aufweisen.
Als erstes muss der Geschäftsprozess "Projekte managen" in die "Prozesslandkarte" (Bild 1) eingeordnet werden. Dann werden die bestehenden Projekte im Unternehmen analysiert, um festzustellen, welche Projektarten (Organisationsprojekte, IT-Projekte, Kundenprojekte, etc.) und welche Projektklassen (z.B. kleine, mittlere oder große Projekte) im Unternehmen abgewickelt werden. Wenn sich die Projektlandschaft sehr heterogen darstellt, kann dies die Bildung von Prozessvarianten (z.B. nach Projektarten und/oder -klassen) zur Folge haben. Ob ein konkreter Bedarf zur Variantenbildung besteht, muss im Einzelfall aufgrund der Abweichungen im Prozess entschieden werden.
Die Prozesslandkarte stellt den Überblick über die in einer Organisation existierenden Prozesse dar. In einer Prozesslandkarte sind jene Prozesse dargestellt, die einerseits die Leistung für den Kunden erbringen (Kerngeschäftsprozesse) und andererseits auch alle Prozesse, die diese Leistungserbringung steuern (Managementprozesse), unterstützen (Supportprozesse) und verbessern (Mess-, Analyse- und Verbesserungsprozesse). Im Vergleich zu einem Organigramm steht hier ein Denken "vom Kunden zum Kunden" im Vordergrund, im Unterschied zum Bereichs- und Abteilungsdenken, das sich entlang der Hierarchie im Unternehmen ausrichtet.
Prozesslandkarten sind immer unternehmensspezifisch gestaltet, da sie die Besonderheiten und Zusammenhänge des Unternehmens darstellen. In diesem Sinne ist auch der Prozess "Projekte managen" in die Prozesslandkarte zu integrieren. Die in Bild 1 angeführte Prozesslandkarte gliedert sich in die vier Kategorien Management-Prozesse, Kerngeschäftsprozesse, Unterstützende Prozesse und Mess-/Analyse- und Verbesserungsprozesse. Ausgehend von dieser Unterteilung stellt sich die Frage, zu welcher Kategorie der Projektmanagementprozess zu zählen ist. Ausgangspunkt für diese Aufgabe bildet die unternehmensspezifische Bedeutung des Prozesses "Projekte managen".
In Unternehmen, die nicht sehr viele Projekte abwickeln und bei denen Projektmanagement vorwiegend der Organisation interner Vorhaben dient (z.B. Infrastrukturprojekte, Projekte zur Umsetzung organisatorischer Maßnahmen, etc.), bietet es sich an, Projektmanagement als einen Supportprozess zu definieren.
Trägt Projektmanagement dagegen bedeutend zur Wertschöpfung bei, so tendieren Unternehmen dazu, den Prozess "Projekte managen" als Kerngeschäftsprozess zu definieren. Dies gilt auch für den in Bild 1 angeführten Prozess "Beratungsprojekte managen". Projektmanagement ist in diesem Fall ein wesentlicher Erfolgsfaktor in der Abwicklung von Kundenaufträgen. Dies trifft typischerweise bei projektorientierten Unternehmen zu.
Für die Integration des Prozesses "Projekte managen" in die Prozesslandkarte gibt es keine allgemein gültigen Regelungen, vielmehr kommt es darauf an, auf die unternehmensspezifischen Rahmenbedingungen einzugehen und eine für das Unternehmen passende Zuordnung zu finden. Die oben angeführten Überlegungen helfen bei der Einordnung. Da die Prozesslandkarte Gültigkeit für das gesamte Unternehmen hat, ist diese Entscheidung mit dem Management abzustimmen bzw. vom Management zu treffen.
Im Beispiel des Beratungsunternehmens wurde in Abstimmung mit dem Management entschieden, zwei Prozessvarianten zu bilden. Zum einen werden Kundenprojekte abgewickelt und zum anderen interne Projekte. Die beiden Prozesse sind hinsichtlich des Ablaufs, des Umfangs der Dokumente sowie der durchzuführenden Tätigkeiten abweichend gestaltet. Ein allgemein gültiger Prozess "Projekte managen" hätte die Projektleiter eingeschränkt bzw. einen zu hohen Projektmanagementaufwand für interne Projekte bedeutet. Die Einordnung in die Prozesslandschaft erfolgt ebenfalls in zwei Kategorien. Der Prozess "Beratungsprojekte managen" ist ein Kerngeschäftsprozess, da in einem Beratungsunternehmen die Kundenaufträge als Projekte abgewickelt werden. Der Prozess "interne Projekte managen" unterstützt die Aufrechterhaltung der Geschäftstätigkeit, in dem z.B. Produktenwicklungen als internes Projekt durchgeführt werden und ist daher den Supportprozessen zugeordnet. Dieser Prozess soll in diesem Beitrag weiter verfolgt und gestaltet werden.
Bild 1: Die Prozesslandkarte.
Mit der Einordnung in die Prozesslandkarte ist lediglich eine "Black Box" vorhanden, die nun weiter detailliert und gestaltet wird. Die angewandte Methode zur Gestaltung von Prozessen sieht ein Top-Down-Vorgehen vor, das den Prozess zunehmend detailliert. Dieses Vorgehensmodell bezieht sich auf ein Ebenenmodell, nach dem alle in der Prozesslandkarte angeführten Prozesse gestaltet sind. Das Ebenmodell wird im Regelfall beim Aufbau des Prozessmanagement-Systems vom Systemverantwortlichen (z.B. Prozessmanager) erstellt. Bild 2 zeigt ein Beispiel eines Ebenenmodells, das in diesem Fall zur Anwendung kam.
Bild 2: Das Modell der Prozessebenen.
Auf der obersten Ebene befindet sich die Prozesslandkarte, welche die Hauptprozesse des Unternehmens abbildet. Die in der Prozesslandkarte abgebildeten Hauptprozesse sind unternehmensspezifisch und von der jeweiligen Geschäftstätigkeit geprägt. Die Prozesslandkarte sollte vom Management erstellt oder zumindest freigegeben werden. Die Hauptprozesse unterteilen sich auf der nächsten Ebene in einzelne Prozesse, die meist eine Wertschöpfungskette bilden, d.h. die Prozessergebnisse bauen aufeinander auf. Diese Prozesse werden dann zum Beispiel in Form eines Flussdiagramms visualisiert und dokumentiert, um eine gemeinsame Sichtweise/Beschreibung des Prozesses für die weitere Detaillierung zu schaffen. Das Flussdiagramm bildet den zeitlichen Ablauf der Tätigkeiten ab, die zur Erzeugung des Prozess-Outputs erforderlich sind.
Die Prozesse sollten übersichtlich modelliert sein, damit die betroffenen Personen sie leicht verstehen und damit auch akzeptieren können. D.h. die Prozessmodelle sollten nicht "ganze Wände befüllen", sondern auf einer bis maximal drei A4-Seiten Platz finden. Erfordert ein Prozessschritt eine detailliertere Modellierung, so wird ein eigener Teilprozess (Ebene 4) erstellt. Auf der untersten Ebene dieses Modells sind die Dokumente und IT-Systeme abgebildet.
Die im entsprechenden Beratungsunternehmen gepflegten Projektmanagement-Standards unterteilen das Projektmanagement in vier Phasen: Initialisierung, Planung, Steuerung und Abschluss. Diese Unterteilung wurde gleichzeitig herangezogen, um den Hauptprozess "interne Projekte managen" zu detaillieren. Der Hauptprozess "interne Projekte managen" unterteilt sich im angeführten Beispiel in die Prozesse "Projekt initialisieren", "Projekt planen", "Projekt steuern" und "Projekt abschließen".
Bild 3: Der Hauptprozess "interne Projekte managen".
Ausgehend von diesen vier Prozessen setzt sich die Detaillierung fort, indem für jeden Prozess ein Flussdiagramm erstellt wird (Bild 4). Vertikal ist der Arbeitsfluss abgebildet, der die einzelnen Arbeitsschritte in der durchzuführenden Reihenfolge aufzeigt. Horizontal ist der Informations- und Dokumentenfluss in Form von Detailunterlagen dargestellt. Ebenfalls auf der Ebene 5 sind die IT-Systeme modelliert. Diese Information ist in den Spalten Input und Output zu sehen, die alle zu verwendenden und zu erstellenden Unterlagen sowie die einzusetzenden IT-Systeme aufzeigt. Mit der Verantwortung ist der organisatorische Bezug hergestellt, indem für jeden Prozessschritt festgelegt wird, wer den Schritt durchführt, entscheidet, mitarbeitet bzw. informiert wird. Wer für die Ausführung der Arbeitsschritte verantwortlich ist, wird bei der Gestaltung des Prozesses festgelegt und mit der Freigabe des Prozesses vom Management bestätigt.
In der Darstellung des Arbeitsflusses muss das Team die "Flughöhe" bestimmen, d.h. es legt fest, wie fein die Arbeitsschritte im Prozess detailliert werden. Z.B. kann im Prozess stehen "Projektorganisation bilden", "Projektstrukturplan erstellen", "Projektressourcenplan erstellen" oder die Erstellung der Projektpläne in einem Arbeitsschritt "Projekt im Detail planen" zusammengefasst werden. In der ersten Variante wird der Projektmanager insofern eingeschränkt, da die Reihenfolge der Arbeitsschritte im Prozess einzuhalten ist. Die zweite Variante ist zum Beispiel mit der Gruppe Planungsprozesse des PMBOK Guide zu vergleichen und lässt dem Projektmanager mehr Freiraum, da er entscheiden kann, welche Pläne für das jeweilige Projekt relevant sind.
Eine sehr detaillierte Darstellung ist aber nicht nur modellierungstechnisch wenig sinnvoll, sondern würde auch dem Projektmanager eine Vorgehensweise vorschreiben, die ihn in der notwendigen Flexibilität beschränken, die durch den Projektcharakter impliziert wird. Die Methoden und Instrumente im Projektmanagement, unabhängig von welchem Standard (z.B. PMBOK Guide, IPMA, PRINCE2) sie stammen, sind ein Werkzeugkoffer, der dem Projektmanager zur Verfügung steht. Der Projektmanager muss entscheiden, in welcher Situation ihm welches Werkzeug weiterhilft. Dies soll nicht durch einen standardisierten Geschäftsprozess vorgeschrieben werden, der dann für alle Projekte (zumindest einer bestimmten Kategorie) gilt.
Die Herausforderung in der Gestaltung des Geschäftsprozesses "Projekte managen" liegt also darin, Standards zu schaffen, ohne den Projektmanager und das Projektteam darin einzuschränken, auf die Rahmenbedingungen des jeweiligen Projekts mit der notwendigen Flexibilität einzugehen. Erfordern unterschiedliche Projektarten (z.B. IT-Projekte, Organisationsprojekte) verschiedene Vorgehensweisen im Projektmanagement, so besteht die Möglichkeit, für bestimmte Projektarten eigene Geschäftsprozesse zu definieren (z.B. interne Projekte managen, Kundenprojekte managen).
Im konkreten Beispiel des Projektplanungsprozesses (Bild 4) ist klar geregelt, dass vor der Erstellung der Projektplanung eine Kostenstelle für das Projekt in SAP anzulegen ist. Damit ist gewährleistet, dass bereits der Planungsaufwand entsprechend verbucht werden kann. Für jedes interne Projekt muss bereits vor der Planung eine Kostenstelle vorhanden sein, sodass die während der Planung anfallenden Ressourcenaufwendungen verbucht werden können.
Bei der Erstellung der Projektplanung ist es dem Projektmanager und seinem Planungsteam überlassen, in welcher Reihenfolge die Pläne ausgearbeitet werden. Jedoch gibt der Prozess vor, dass die Planung gemäß den Regelungen des Projektmanagementhandbuches durchzuführen ist, welches als Input-Dokument angeführt ist. Das Projektmanagementhandbuch beschreibt das Projektmanagement-System des Unternehmens und enthält alle Regelungen und Standards sowie einen Methodenkoffer.
Ebenso zeigt der Prozess, dass ein Projekthandbuch zu erstellen ist. Welche Pläne zum Beispiel in Abhängigkeit des Projektumfangs oder der Projektart zu erstellen sind, wird nicht durch den Prozess selbst geregelt, sondern ist in den Input-Dokumenten (Projekthandbuch, Projektmanagementhandbuch) spezifiziert. So ist zum Beispiel für kleinere Entwicklungsprojekte mit einem Umfang von weniger als 15 Personentagen die Durchführung einer Risikoanalyse nicht verpflichtend sondern optional.
Im letzten wesentlichen Schritt des Projektplanungsprozesses werden die Planungsergebnisse mit dem Auftraggeber besprochen und der Leistungsumfang sowie die Ressourcenbereitstellung ausgehandelt. Es kann zum Beispiel sein, dass sich im Rahmen der Detailplanung eine sinnvolle Erweiterung des Projektumfangs ergibt, die in den ursprünglichen Zielsetzungen und damit den veranschlagten Ressourcen nicht vorgesehen war. Kommt es zu keiner Einigung zwischen Projektauftraggeber und Projektmanager, so muss der Planungsprozess nochmals durchlaufen bzw. der Projektabschluss veranlasst werden. Ist hingegen eine Einigung erzielt, so wird der Projektauftrag unterzeichnet und der Projektplanungsprozess ist abgeschlossen.
Bild 4: Der Projektplanungsprozess.
Eine Integration des Projektmanagements in das Prozessmanagementsystem eines Unternehmens ist praxisorientiert umsetzbar, wenn das Projektmanagement von den inhaltlichen Prozessen zur Erstellung der Projektprodukte getrennt betrachtet wird. Auf dieser Ebene wird auch eine gerade im Geschäftsprozessmanagement geforderte Standardisierung möglich. Ein entscheidendes Kriterium ist jedoch, dem Projektmanager die Flexibilität zu lassen, auf projektspezifische Rahmenbedingungen einzugehen. Dem Projektmanager auf Arbeitsschrittebene vorzugeben, welche Reihenfolge er zum Beispiel bei der Erstellung von Projektplänen einzuhalten hat, würde nicht den Anforderungen der Realität von Projekten entsprechen und dem grundlegenden Zweck von Projektmanagement widersprechen bzw. so komplex sein, dass das Prozessmodell in der Praxis nicht mehr anwendbar ist. Das Design des Geschäftsprozesses muss dabei unterschiedliche Projektarten sowie Projektklassen (z.B. große, mittlere und kleine Projekte) berücksichtigen, um einen unnötigen Projektmanagement-Mehraufwand aufgrund der Standardisierung zu vermeiden. Mit der Gestaltung des Geschäftsprozesses "Projekte managen" verfügt ein Unternehmen über beste Voraussetzungen, eine standardisierte Abwicklung von Projekten zu gewährleisten
Manfred Noe
22.10.2008