CPM steht für Critical Path Method. In T!M wird der CPM Status als Ampel dargestellt, die einen Überblick über die Zeitplanung des Prozesses verschafft und ist für Processmanager wichtig, um den ganzen Prozess im Überblick zu behalten. Die CPM Funktion steht ausserdem nur im Processmanager-Client zur Verfügung!

Im ToDo-Client ist die Ampel nicht ersichtlich und die Bearbeiter sehen nur die Zeit, die Ihnen bleibt um Ihren Teil der Aufgabe zu bearbeiten. Siehe hierzu auch ToDo-Client.

Achtung! Die Bearbeitungszeit im ToDo-Client steht nicht im Zusammenhang mit CPM!

Die Bearbeitungszeit einer Aufgabe kann in Signavio eingetragen werden. Sie gibt vor wie lange der Mitarbeiter für eine Aufgabe brauchen darf bis sie erledigt sein muss.

Der kritische Pfad beschreibt den längstmöglichen Pfad den der Prozess, bezogen auf die Bearbeitungszeit, gehen kann. Die Bearbeitungszeiten der Aufgaben die sich innerhalb des kritischen Pfades befinden werden addiert und ergeben damit den längsten Bearbeitungsweg. Auf dem folgenden Bild ist der kritische Pfad rot eingezeichnet. Bei der ersten Verzweigung ist der längere Weg der obere, da für die beiden Aufgaben eine Bearbeitungszeit von jeweils 5 Stunden ein längerer Zeitraum nötig ist als für die 9 Stunden des unteren Verzweigungsweges. Bei der zweiten Verzweigung ist die untere Verzweigung die längere.

Für den gesamten Prozess ergäbe sich hiermit eine gesamte Bearbeitungszeit von 5 Stunden + 5 Stunden + 2 Stunden + 7 Stunden = 19 Stunden.

Der FAZ ( Frühester Anfangszeitpunkt) kann über die Vorwärtsplanung der Prozesses errechnet werden. Der früheste Anfangszeitpunkt der ersten Aufgabe entspricht der Anfangszeit des Prozesses. Für alle folgenden Aufgaben errechnet er sich aus der Summe aller Bearbeitungszeiten der vorhergehenden Aufgaben entlang des kritischen Pfades.

Der FEZ (Frühester Endzeitpunkt) wird ebenfalls aus der Vorwärtsplanung des Prozesses errechnet. Der Früheste Endzeitpunkt ergibt sich aus Addition des FAZ und der Bearbeitungszeit der Aufgabe.

Der SEZ (Spätester Endzeitpunkt) errechnet sich aus der Rückwärtsplanung. D.h. es wird entweder ein geplantes Ende für den Prozess angegeben oder das Ende wird aus der Dauer des kritischen Pfades errechnet. Der SEZ der letzen Aufgabe entspricht dem geplanten, bzw. errechneten, Ende. Um den SEZ der vorherigen Aufgabe zu errechnen, wird vom SEZ der folgenden Aufgabe die Bearbeitungszeit der folgenden abgezogen.

Der SAZ einer Aufgabe entspricht SEZ der vorherigen Aufgabe, bzw. SEZ der Aufgabe minus der Bearbeitungszeit dieser Aufgabe.

Der Puffer für eine Aufgabe lässt sich errechnen aus : Puffer = SAZ - FAZ. Dies ist der Puffer den die Aufgabe entweder benutzen kann um später zu beginnen oder in der Bearbeitung überziehen kann, ohne den Zeitplan des gesamten Prozesses zu gefährden.

Der Prozess liegt noch im Zeitplan, der vorgegeben wurde. Bis jetzt wurde keine Pufferzeit verbraucht.

Die Ampel einer Aufgabe wird dann gelb, wenn sie dabei ist zeitlichen Puffer aufzubrauchen. D.h. die Aufgabe hat ihre früheste Anfangszeit überschritten, hat aber aufgrund einer Aufgabe die parallel läuft und auf welche der Prozess warten muss um vorschreiten zu können, wird dieser Aufgabe ein Puffer eingerechnet. Betrachtet man sich das im folgenden Beispiel wird deutlich wie die Pufferberechnung funktioniert: die Aufgabe mit der Dauer 9 Stunden hat einen Puffer von 1 Stunde, da der Prozess auf die Aufgaben mit der Dauer von jeweils 5 Stunden warten muss um fortschreiten zu können.

Wird eine Aufgabe nicht innerhalb ihrer errechneten spätesten Endzeit erledigt, so springt die Ampel auf Rot, da die Aufgabe ihren geplanten Zeitrahmen überschritten hat. Anhand des Beispiel sieht man, dass sobald die Aufgabe mit einer Dauer von 5 Stunden, diese Zeit überschreitet, die Ampel Rot wird, bzw. wird die Ampel Rot, sobald die Aufgabe mit einer Dauer von 9 Stunden länger als 10 Stunden benötigt um fertig gestellt zu werden. Das bedeutet wiederum dass der Puffer für diese Aufgabe verbraucht ist.

Ist eine Aufgabe oder ein Aufgabenblock (siehe Beispiel) nicht im Zeitplan erledigt und dadurch die geplante Zeit des gesamten Prozesses überschritten worden, schaltet die Ampel auf Rot, da der Prozess nicht mehr rechtzeitig fertig gestellt werden kann. > Ist die Ampel einmal Rot, wird das für den restlichen Prozessverlauf auch so bleiben, da keine Aufgabe mehr im Zeitplan erledigt werden kann.

Beim Start einer Prozessinstanz ist es möglich ein geplantes Startdatum anzugeben. Ist ein Startdatum angegeben, so wird davon ausgegangen, dass der Prozess zu diesem Zeitpunkt beginnt. Alle frühesten Anfangszeiten, für die einzelnen Aktivitäten/ Aufgaben, werden ausgehend von diesem Zeitpunkt berechnet. Wird eine Aufgabe vor der geplanten Anfangszeit erledigt, werden die folgenden Aufgaben jedoch nicht nach vorne verlegt, sondern deren Anfangszeit wird weiterhin ausgehend der geplanten Zeit berechnet.

=== Geplantes Ende ===

Wird ein geplantes Enddatum beim Start einer Prozessinstanz angegeben, so werden die frühesten Anfangszeitpunkte der Aktivitäten/Aufgaben ausgehend von diesem Datum berechnet. Um die geplanten Anfangszeit zu berechnen muss der kritischer Pfad des Prozesses berechnet werden. Die sich dabei ergebende Zeit wird nun von dem geplanten Enddatum subtrahiert und ergibt somit den geplanten Beginn des Prozesses. Ausgehend von diesem geplanten Beginn werden nun wiederrum die frühesten Anfangszeiten für die einzelnen Aufgaben ermittelt.

Werden bei Instanzstart ein geplanter Beginn und ein geplantes Ende eingetragen werden alle Berechnungen ausgehen von dem geplanten Beginn ausgeführt und das geplante Ende wird vernachlässigt.

Damit bei einem der Prozess der Puffer weitergegeben wird, muss in Signavio die Checkbox Puffer weitergeben aktiviert sein. Dies kann aber auch nachträglich für einzelne Instanzen geschehen. Erreicht werden kann dies über die Eigenschaften einer Prozessinstanz.

Ist Puffer weitergeben aktiviert, werden Puffer die bei frühzeitiger Erledigung einer Aktivtät, d.h. vor Ablauf ihrer Bearbeitungszeit, enstehen an die direkt nachfolgende(n) Aktivität(en) weitergegeben. Der Puffer bildet sich aus ungenutzter Bearbeitungszeit einer Aktivität. Die Bearbeitungszeit der nachfolgenden Aufgabe bildet sich somit aus der eigenen Bearbeitungszeit der Aktivität und des entstandenen Puffers. Wurde bei einer Aufgabe die geplante Bearbeitungszeit überschritten, so entsteht ein negativer Puffer der von der Bearbeitungszeit der nachfolgenden Aufgabe abgezogen wird, jedoch bleibt immer mindestens eine Bearbeitungszeit von einer Stunden erhalten.

 reele Bearbeitungszeit = eingeplante Bearbeitungszeit + evtl entstandene Puffer

Wie man in dem Beispiel sieht, ensteht bei der oberen Aktivität innerhalb der AND-Verzweigung ein Puffer von einer Stunde. Bei der unteren Verzweigung entsteht bei der ersten Aufgabe ein Puffer von einer Stunde. Dieser wird direkt an die nachfolgende Aufgabe weitergegeben, diese wiederum verbraucht 30 Minuten von diesem Puffer. Daraus wird ersichtlich dass bei der oberen Verzweiung ein Puffer von einer Stunde entstanden ist. Bei der unteren Verzweigung ist im gesamten ein Puffer von einer halben Stunde / 30 min entstanden. Die Aktivität die nach einer AND-Verzweigung folgt, bekommt den kleinsten enstandenen Puffer. In diesem Beispiel bekommt diese Aktivität die 30 Minuten auf ihre eigenen Bearbeitungszeit addiert.

Um das CPM Modul zu aktivieren, sind 4Punkte erforderlich:

1. Auf jeder Node ist eine Bearbeitungszeit eingetragen
2. Der Prozess beinhaltet keine Schleife, da dadurch keine Mindestlaufzeit mehr berechnet werden kann (siehe CPM Modul deaktiviert)
3. Es ist genau ein terminierendes Ende im Prozessmodell vorhanden (ein normales End-Event ist nicht ausreichend).
4. CPM Berechnung ist im Prozess aktiviert

• Signavio: Count Critical muss aktiviert sein (siehe CPM Modul deaktiviert)
• iGrafx: In iGrafx dürfen bei der Verwendung von CPM nur die „dicken“ Endungen genutzt werden. Falls „dünne“ Enden genutzt werden, wird CPM nicht berechnet. (siehe iGrafx Endungen)

—-

Befinden sich die Aufgabe in ihrer eingeplanten Bearbeitungszeit, so ist die Ampel grün. In dem Beispiel ist dies der Fall für die Aufgabe mit 9 Stunden Bearbeitungszeit, solange der Prozess die Gesamtdauer von 9 Stunden noch nicht überschritten hat, bzw. solange der früheste Endzeitpunkt der Aufgabe noch nicht erreicht ist.

Hat eine Aufgabe ihre früheste Endzeit überschritten, es ist jedoch Puffer vorhanden, so wird dieser Puffer aufgebraucht und die Ampel für die zugehörige Aufgabe zeigt die Farbe gelb an.

In diesem Beispiel wäre dies der Fall wenn die untere Aufgabe nach ihren eingeplanten 9 Stunden Bearbeitungszeit noch nicht erledigt ist. Dann wird der Puffer von einer Stunde aufgebraucht und die Ampel ist damit gelb.

Eine Aufgabe wird rot, falls sie nicht innerhalb der Bearbeitungszeit, bzw. Bearbeitungszeit inklusive Puffer, erledigt wird. In dem Beispiel würde die erste obere Aufgabe nach 5 Stunden rot werden (wenn ihre späteste Endzeit überschritten worden ist). Die untere Aufgabe würde nach 10 Stunden rot werden, da sie selbst eine Bearbeitungszeit von 9 Stunden und einen Puffer von 1 Stunden besitzt.

D.h. eine Aufgabe wird rot sobald ihre späteste Endzeit überschritten ist. Wird eine Aufgabe überzogen, so dass es keiner Aufgabe innerhalb des kritischen Pfades mehr möglich ist rechtzeitig vollendet zu werden, werden diese Aufgaben auf rot gesetzt. Wird eine Aufgabe nun doch schneller erledigt als die angegeben Bearbeitungszeit ist es dem Prozess wieder möglich die verlorene Zeit „aufzuholen“ und damit die Aufgaben wieder im Zeitplan zu erledigen (den Ampeln ist es wieder möglich grün zu werden)

Hier ein Beispiel von einem Prozess, in dem das CPM Modul nicht funktionieren kann, da eine Schleife eingebaut ist. Durch diese Schleife kann das CPM-Modul nicht berechnen, wie oft der Prozess durchlaufen wird und somit auch keine Zeiten angeben, bis wann bestimmte Aufgaben erledigt sein müssen.

Dieses Fenster lässt sich über das Kontextmenü der Prozessinstanz, bzw. deren Eigenschaftsmenü erreichen.

Unter dem Reiter Aktivitäten, kann für jede Aufgabe ein gewünschter Startzeitpunkt eingestellt werden. Dieser sorgt dafür, dass falls eine vorherige Aufgabe frühzeitig erledigt worden ist, die Bearbeitungszeit der folgenden nicht sofort verbraucht wird. Diese Aufgabe bekommt nun entsprechend verbleibende Zeit addiert, sodass die eigentlich geplante Bearbeitungszeit erst ab dem gewünschten Startdatum verbraucht wird.

Ab Version 4.6 kann die CPM-Berechnung auch für Prozesse mit Sub-Prozessen, mehreren Prozessenden und Schleifen realisiert werden.

Ab Version 4.6 besteht die Möglichkeit, den kritischen Pfad für Prozesse mit einem oder mehreren Sub-Prozessen zu berechnen. Die Dauer des Sub-Prozesses ist die Summe der Zeiten der Aktivitäten des Sub-Prozesses. Besteht ein Sub-Prozess z.B. aus vier Aktivitäten mit einer Dauer von jeweils einer Stunde, ist die Dauer des Sub-Prozesses vier Stunden.

Verfügt ein Prozess über mehrere Enden, wird der kritische Pfad unter der Annahme berechnet, dass ein „positives“ Prozessergebnis vorliegt. Zur Verdeutlichung dient folgendes Beispiel.

Der Prozess besteht aus drei Aktivitäten mit einer Dauer von jeweils einer Stunde. Nach Aufgabe 1 bzw. Aufgabe 2 kann der Prozess jedoch bereits beendet sein, da Produkte mit zu geringer Qualität im Ausschuss landen. Basierend auf dieser Annahme kann der vorliegende Beispielprozess eine Dauer von einer Stunde, zwei Stunden oder drei Stunden haben. Um prozessübergreifend konsistente CPM-Berechnungen liefern zu können, bezieht sich TIM bei der Berechnung auf das „positive“ Prozessende. Im vorliegenden Beispiel wird der kritische Pfad folglich unter Einbeziehung der drei Aktivitäten Aufgabe 1, Aufgabe 2 und Produkt verkaufen berechnet.

Der kritische Pfad wird für Prozesse mit Schleifen in ähnlicher Weise berechnet, wie für Prozesse mit mehreren Enden. Anstatt ein postitives Prozessende anzunehmen, werden Prozessschleifen in der CPM-Berechnung ignoriert. Eine CPM-Berechnung unter Einbeziehung von Schleifen ist deshalb nicht möglich, da diese beliebig oft durchlaufen werden können. Zur Verdeutlichung dient folgendes Beispiel.

Der kritische Pfad des vorliegenden Beispielprozesses wird unter der Annahme eines Durchlaufs berechnet.

Wie im vorherigen Abschnitt erläutert werden Loops grundsätzlich ignoriert. Allerdings ist die Berechnung ob es sich bei einem Weg um einen Loop handelt rechenintensiv. Daher ist es bei großen Prozessbilder möglich Loops in der Modellierung zu markieren um die Berechnung des CPM zu beschleunigen. Der Pfeil der in einen Loop mündet muss hierfür beschriftet werden. Die Benamung setzt sich dann wie folgt zusammen. Siehe auch Beispiel.

loop_ + Beliebiger Text