Critical Path Method (CPM)

Definition

CPM stands for Critical Path Method. The system displays the CPM status as traffic lights, which indicate the schedule of the process. This way, the process manager can keep track of the whole process. The CPM function is only available for the user with the role of process owner and process manager.

Open

For users with the role member, the traffic-light is not visible, and the actor only sees the processing time that remains for working off their part of the task. The Status-icon is displaying the elapsing time by changing its color.

Processing time

The processing time can be entered in each process activity during the modeling process. It specifies how long the user may need for a task within an activity until they have to be finished.

Critical path

The critical path describes the longest possible path of the process according to the processing time. The processing time of the activities, which are in the critical path, is added and result in the longest processing path. The critical path is shown in red on the following picture. In the first part of this sample process, the longer path is the upper one because the two activities have a processing time of 5 hours each, which is a longer period than the 9 hours of the lower path. In the second branch the path, which has a longer processing time, is the lower one.

Open

So there is an entire processing time of 5 hours + 5 hours + 2 hours + 7 hours = 19 hours for the whole process.

Times of a task

EST - Earliest start time

The earliest start time can be calculated via the forward planning of the process. The EST of the first activity is the starting time of the process. For all the following activities, it is calculated from the sum of all processing times of the previous activities along the critical path.

EFT - Earliest finish time

The earliest finish time is also calculated via the forward planning of the process. The EFT results from the addition of the EFT and the processing time of the activity.

LFT - Latest finish time

The latest finish time is calculated via the backward planning. That means it is indicated either a planned end for the process or the end is calculated from the length of the critical path. The LFT of the last activity is equivalent to the planned or calculated end. The processing time of the following activity is deducted from the LFT of the following task for calculating the LFT of the previous activity.

LST - Latest start time

The latest start time of an activity is equivalent to the LFT of the previous activity, or rather the LFT of the activity minus the processing time of this activity.

Buffer of an activity with an AND branch

The buffer of an activity can be calculated as Buffer = LST (latest start time) - EST (earliest start time). This is the buffer that can be used by the activity for a later starting or for overrunning the time off work without putting the schedule of the whole process at risk.

The traffic-light symbol

Greenlight

The process is still in scheduled time. No buffer time was needed so far.

Yellow light

The traffic-light of activity is yellow if the task is going to use buffer time. That means, the activity has exceeded its earliest start time but due to another activity, which runs parallel and for which the process has to wait until proceeding (AND Gateway), the activity got a buffer. The following example shows you how the buffer calculation works: The activity with a time of 9 hours has a buffer of 1 hour because the process has to wait for the activities with 5 hours each.

Red light

If an activity is not completed within the scheduled latest finish time, the traffic light turns red because the activity exceeded its scheduled time frame. Based on example, you can see that the traffic light turns red as soon as the activity exceeded the time of 5 hours. Or the traffic light turns red as soon as the activity with scheduled 9 hours needs more than 10 hours for finishing. That means the buffer exceeded for this activity.

If an activity or a set of activities (see examples) is not completed on schedule and the scheduled time of the whole process has been exceeded, the traffic light turns red because the process can not be finished in time anymore.

If the traffic light is red once, it will stay red for the rest of the process because no activity can be done at the scheduled time.

Scheduled end

If a scheduled end date is specified at the start of a process instance, the earliest start times of the activities/tasks are calculated from this date. The critical path of the process must be calculated first for calculating the scheduled start time. The resulting time will be subtracted from the scheduled end date, and therefore the scheduled start of the process results. Based on this scheduled start, the earliest start times of each task are calculated now.

If a scheduled start and a scheduled end are registered at the start of the instance, all calculations are performed based on the scheduled start and the scheduled end is neglected.

Hand over buffer

For handing over the buffer in a process, the checkbox Hand over buffer must be activated in the process properties. This can also be done later for individual instances. This can be achieved by Properties of a process instance.

If hand over buffer is activated, the buffer, which raised by early completion of activity i.e. before the end of its processing time, is handed over directly to the following activities. The buffer is generated from unused processing time of an activity. The processing time of the following activities is generated from the own processing time of the activity and the raised buffer. If the scheduled processing time of an activity is exceeded, a negative buffer is generated which will be subtracted from the processing time of the following activities. But there will always be a remaining processing time of one hour at least.

Hand over buffer in an AND-Gateway

As you can see in the example, a buffer of one hour raises in the upper activity within the AND-branch. In the lower activity, a buffer of one hour raises in the first activity.
This buffer is handed over directly to the next activity, which uses 30 minutes of the buffer. There you can see that a buffer of one hour raised in the upper branch.
In the lower branch, a total buffer of half an hour/30 minutes raised. The activity after an AND-branch gets the smallest originated buffer.
In this case, the activity gets the 30 minutes added to its own processing time.

Requirements

Four points are required for activating the CPM module:

1. Processing time is entered on each activity

2. The process has no loop because no minimum term can be calculated anymore (see CPM module deactivated)

3. Exactly one terminating end has to be included in the process model (a normal end event is not sufficient)

4. CPM calculation is activated in the process

Special cases in the CPM calculation

It is possible to calculate the critical path for processes with subprocesses, multiple ends and loops.

Processes with subprocesses

To calculate the critical path for a process with subprocesses, the durations of the sub-processes must be available. Therefore, the duration of a subprocess is calculated as the sum of the activities' durations of the subprocesses. E.G. if a subprocess consists of four activities with a duration of one hour each, the cumulated duration of the subprocess is four hours. That duration is now used to calculate the main process' critical path.

Processes with multiple ends

The critical path for processes with multiple ends can be calculated by using the PredefinedDecisionHandler. The following example clarifies the approach. 

The process consists of three activities with a duration of one hour each. However, the process can terminate after task 1 and task 2 respectively. Based on this assumption, the process can either have a duration of one hour, two hours or three hours. In order to provide a consistent CPM calculation, the system has to be informed which path is the most probable one by defining it via PredefinedDecisionHandler .

Processes with loops

The CPM calculation for processes with loops is done in similar fashion. Either all loop transitions are marked with the prefix “loop_” in their name or by using the PredefinedDecisionHandler . This is because a CPM calculation with loops is not possible. Loops can be run through arbitrarily. Therefore, the critical path can only be calculated, while ignoring process loops entirely. The following example clarifies the approach.

Here, the critical path is calculated for one process cycle.