TIM Wiki / NEW TIM 6 Documentation

CPM stands for Critical Path Method. In T!M the CPM status is displayed as traffic-light which gives an overview about the schedule of the process and is important for the Processmanager to keep track of the whole process. The CPM function is only available in the Processmanager-Client.

In ToDo-Client the traffic-light is not visible, and the actor only sees the time that remains for working off their part of the task. See also ToDo-Client.

Caution! The processing time in ToDo-Client is not associated with CPM!

The processing time can be entered in each process activity. It specifies how long the employee may need for the tasks within an activity until they have to be finished.

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, are 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, wich has a longer processing time, is the lower one.

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

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 following activities, it is calculated from the sum of all processing times of the previous activities along the critical path.

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

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.

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.

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

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

The traffic-light of an 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.

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 in the scheduled time.

It is possible to set a scheduled start time with the start of a process instance. If a start time is set, it is assumed that the process starts at this time. All earliest start times for individual activities / tasks are calculated from this point. If a task is done before the scheduled start time, the following tasks are not moved forward but the start time is still calculated from 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 is registered at the start of the instance, all calculations are performed based on the scheduled start and the scheduled end is neglected.

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 arised by early completion of an 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 arised buffer. If the scheduled processing time of an activity is exceeded, a negative buffer is generated which will be substracted from the processing time of the following activities. But there will always be remaining processing time of one hour at least.

 actual processing time = scheduled processing time + possibly arised buffer

As you can see in the example, a buffer of one hour arises in the upper activity within the AND-branch. In the lower activity, a buffer of one hour arises 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 arised in the upper branch. In the lower branch, a total buffer of half an hour / 30 minutes arised. 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.

4 points are required for activating the CPM module:

1. A processing time is entered on each activity
2. The process has no loop, because no minimum term can be calculated anymore (see CPM modul deactivated)
3. Exact 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

• Signavio: Count Critical must be activated (see CPM modul deactivated)
• iGrafx: If CPM is active, “Big” endings must be used in iGrafx. When “Small” Endings are used, CPM will not be calculated. (see iGrafx Endings)

—-

The light is green, if the tasks are in the scheduled processing time. In the example, it is the case for the task with 9 hours processing time as long as the process has not yet exceeted the total time of 9 hours or until the earliest finish time of the task has not yet reached.

If a task has exceeded its earliest finish time, but there is still buffer available, this buffer is used up and the light of the task is yellow.

In the example, it is the case if the lower task is not done after its scheduled processing time of 9 hours. Then the buffer of one hour is used up and the light is yellow.

A task is red, if it is not done after the processing time or rather after the processing time including buffer. In this example the first task would turn red after 5 hours (if its latest end time has been exceeded). The lower task would turn red after 10 hours because it has a processing time of 9 hours and a buffer of 1 hour.

I.e. a task turns red as soon as the latest finish time has been exceeded. If a task is overran, so that it is no longer possible to complete any task within the critical path in time, the tasks are set to red. If a task is done faster than the specified processing time now, it is possible to “catch up” the lost time in the process and to complete the tasks in time again (the lights can turn green again)

This is an example of a process in which the CPM modul can not work, because a loop is integrated. Because of this loop, the CPM modul can not calculate how often the process will be passed through and can not specify any times until certain tasks must be completed.

This window is found in the context menu of the process instance or its property menu.

In the activities tab, a desired start time can be set for each activity. This ensures that, if a previous activity has been completed in an early stage, the processing time of the following activity is not used immediately. The left time is added to the activity correspondingly, so the original scheduled processing time is used only from the desired start time.

With version 4.6 it is possible to calculate the critical path for processes with subprocesses, multiple ends and loops.

To calculate the critical path for a process with subprocesses, the durations of the subprocesses 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.

The critical path for processes with multiple ends is calculated under the assumption that there is a “positive” process end. 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 consitent, process independent CPM calculation, TIM calculates the critical path based on the “positive” process end. For the process on hand the critical path is therefore calculated considering Task 1, Task 2 and Sell Product.

The CPM calculation for processes with loops is done in similar fassion. Instead of assuming a positive process end, the critical path is calculated while ignoring the process' loops. 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 looops entirely. The following example clarifies the approach.

Here the critical path is calculated for one process cycle.