This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
en:support:cpm [2014/11/26 10:46] duc.le |
en:support:cpm [2018/03/06 13:57] Martin Oehm |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ==== Definition ==== | ||
+ | **CPM** stands for **C**ritical **P**ath **M**ethod. 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 [[:en:software:tim:roles#processmanager|Processmanager]] to keep track of the whole process. The CPM function is only available in the [[:en:software:tim:todo-processmanager4g|Processmanager-Client]]. {{ :en:software:tim:activities_status.png?direct&700 }} | ||
- | ==== Definition ==== | + | 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 [[:en:software:tim:todo_clients#element_15|ToDo-Client]]. |
- | **CPM** stands for **C**ritical **P**ath **M**ethod. | + | |
- | 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 [[en:software:tim:rights#Processmanager|Processmanager]] to keep track of the whole process. The CPM function is only available in the [[en:software:tim:todo-processmanager4g|Processmanager-Client]]! | + | |
- | {{ en:software:tim:activities_status.png?direct&700 |}} | + | |
- | + | ||
- | In ToDo-Client the traffic-light is not visible, and the actor only see the time that remains for working off their part of the task. See also [[en:software:tim:todo_clients#Element 15|ToDo-Client]]. | + | |
- | >> Caution! The processing time in [[en:software:tim:todo_clients#Element 15|ToDo-Client]] is not associated with CPM! | + | >> Caution! The processing time in [[:en:software:tim:todo_clients#element_15|ToDo-Client]] is not associated with CPM! |
---- | ---- | ||
- | ====Processing time==== | ||
- | The processing time of a task can be entered in Signavio. It specifies how long the employee may need for a task until it has to be finished. | + | ==== Processing time ==== |
- | ==== Critical path==== | + | 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 tasks, 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. | + | |
- | The longer path is the upper one in the first branch, because the two tasks have a processing time of 5 hours each, which is a longer period as the 9 hours of the lower path. | + | |
- | The longer path is the lower one in the second branch. | + | |
- | So there is for the whole process an entire processing time of 5 hours + 5 hours + 2 hours + 7 hours = 19 hours . | + | ==== Critical path ==== |
- | {{ :en:support:critical_path.png |}} | + | 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. | ||
+ | |||
+ | {{ :en:support:critical_path.png }} | ||
---- | ---- | ||
- | ==== Times of a task ==== | + | ==== Times of a task ==== |
=== EST - Earliest start time === | === EST - Earliest start time === | ||
- | The earliest start time can be calculated via the forward planning of the process. The EST of the first task is the starting time of the process. | ||
- | For all following tasks, it is calculated from the sum of all processing times of the previous tasks along the critical path. | ||
- | === EFT - Earliest end 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 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 task. | + | |
+ | === EFT - Earliest finish time === | ||
+ | |||
+ | 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. | ||
=== LFT - Latest finish time === | === LFT - Latest finish time === | ||
- | The latest finish time is calculated via the backward planning. That means it is indicated eather a planned end for the process or the end is calculated from the length of the [[ #critical path | critical path ]]. | + | 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|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 LFT of the last task is equivalent to the planned or calculated end. The processing time of the following task is deducted from the LFT of the following task for calculating the LFT of the previous task. | + | |
=== LST - Latest start time === | === LST - Latest start time === | ||
- | The latest start time of a task is equivalent to the LFT of the previous task or rather the LFT of the task minus the processing time of this task. | ||
- | === Buffer of a task with an AND branch === | + | 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 a task can be calculated as: Buffer = LST (latest start time) - EST (earliest start time). | + | |
- | This is the buffer which can be used by the task for a later starting, or for overrunning the time of work without putting the schedule of the whole process at risk. | + | === 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 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 traffic-light symbol ==== | ==== The traffic-light symbol ==== | ||
+ | |||
=== Green light === | === Green light === | ||
+ | |||
The process is still in scheduled time. No buffer time was needed so far. | The process is still in scheduled time. No buffer time was needed so far. | ||
- | \\ === Yellow light === | ||
- | The traffic-light of a task is yellow if the task is going to use buffer time. | ||
- | That means, the task has exceeded its earliest start time but due to a task, that runs parallel and in which the process has to wait to proceed, the task got included a buffer. | ||
- | If you look at the following [[#Examples | example]] it is clear how the buffer calculation works: The task with a time of 9 hours has a buffer of 1 hour because the process has to wait for the tasks with each 5 hours. | ||
- | \\ === Red light === | ||
- | If a task is not completed within the scheduled latest finish time, the traffic-light turns red because the task exceeded its scheduled time frame. | ||
- | Based on [[#Examples | example]] you can see that the traffic-light turns red as soon as the task exceeded the time of 5 hours. Or the traffic-light turns red as soon as the task with scheduled 9 hours needs more than 10 hours for finishing. That means the buffer is used up for this task. | ||
- | If a task or a set of tasks (see [[#examples]]) is not completed on schedule and so 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. | + | === Yellow light === |
- | > If the traffic-light is red once, it will stay red for the rest of the process because no task can be done in the scheduled time. | + | 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 [[#examples|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 === |
- | ==== Scheduled times ==== | + | |
- | {{ :en:support:unbenannt.png |}} | + | |
- | === Scheduled start === | + | |
- | 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 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 [[#examples|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 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 an activity or a set of activities (see [[#examples|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 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. | + | > 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. |
- | The [[ #critical path| 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. | + | ---- |
+ | ==== Scheduled times ==== | ||
- | ---- | + | {{ :en:support:unbenannt.png }} |
- | ==== Hand over buffer ==== | + | |
- | For handing over the buffer in a process, the checkbox **Hand over buffer** in Signavio must be activated. This can also be done later for individual instances. This can be achieved by [[ en:software:tim:instance_context_properties | Properties of a process instance]]. | + | === Scheduled start === |
- | {{ :en:support:handover_buffer.png |}} | + | 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. |
+ | <code> | ||
- | If **Hand over buffer** is activated, buffer which arised by early completion of an activity, i.e. befor the end of their process time, are hand over directly to the following activities. The buffer is generated from unused processing time of an activity. | + | === Scheduled end === |
- | The processing time of the following tasks is generated from the own processing time of the activity and the arised buffer. If the scheduled processing time of a task is exceeded, a negative buffer is generated which will be substracted from the processing time of the following task. But there will be remaining always a processing time of one hour at least. | + | </code> |
- | actual processing time = scheduled processing time + possibly arised buffer | + | |
- | ==Hand over buffer in an AND-Gateway== | + | 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|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. |
- | {{ :en:support:buffer.png |}} | + | >> 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. |
- | 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 task. This buffer is hand over directly to the next task, which uses 30 minutes of the buffer. \\ | + | |
- | From this 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. | + | |
+ | ==== 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 [[:en:software:tim:instance_context_properties|Properties of a process instance]]. | ||
+ | {{ :en:support:handover_buffer.png }} | ||
+ | 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. | ||
+ | <code> | ||
+ | actual processing time = scheduled processing time + possibly arised buffer | ||
+ | </code> | ||
+ | == Hand over buffer in an AND-Gateway == | ||
- | ---- | + | {{ :en:support:buffer.png }} |
+ | 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. | ||
+ | |||
+ | ---- | ||
==== Requirement ==== | ==== Requirement ==== | ||
- | 3 points are required for activating the CPM modul: | ||
- | - A processing time is entered on each node | + | 4 points are required for activating the CPM module: |
- | - The process has no loop, because no minimum term can be calculated anymore (see [[#CPM modul deactivated]]) | + | |
- | - CPM calculation is activated in the process | + | |
- | * **Signavio**: Count Critical must be activated (see [[#CPM modul deactivated]]) | + | |
- | * **iGrafx**: //Follows// | + | |
+ | - A processing time is entered on each activity | ||
+ | - The process has no loop, because no minimum term can be calculated anymore (see [[#cpm_modul_deactivated|CPM modul deactivated]]) | ||
+ | - Exact one terminating end has to be included in the process model (a normal end event is not sufficient) | ||
+ | - CPM calculation is activated in the process | ||
+ | * **Signavio**: Count Critical must be activated (see [[#cpm_modul_deactivated|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 [[:en:software:igrafx_documentation#endings|iGrafx Endings]]) | ||
---- | ---- | ||
- | |||
- | |||
==== Examples ==== | ==== Examples ==== | ||
- | {{ :en:support:hours.png |}} | + | |
+ | {{ :en:support:hours.png }} | ||
---- | ---- | ||
Line 132: | Line 127: | ||
=== Tasks green === | === Tasks green === | ||
- | The light is green, if the tasks are in the scheduled processing time. | + | 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. |
- | 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. | + | |
=== Tasks yellow === | === Tasks yellow === | ||
- | 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. | + | 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. | + | 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. |
=== Task red === | === Task red === | ||
- | A task is red, if it is not done after the processing time or rather after the processing time including buffer. | + | 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. |
- | 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. | + | 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) |
- | 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) | + | |
+ | ---- | ||
- | ----- | ||
=== CPM modul deactivated === | === CPM modul deactivated === | ||
- | {{ :en:support:loop.png?direct&300 |}} | ||
- | 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. | ||
- | ----- | + | {{ :en:support:loop.png?direct&300 }}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. |
+ | |||
+ | ---- | ||
+ | |||
+ | ==== Edit processing times subsequently and desired start times ==== | ||
- | ====Edit processing times subsequently and desired start times==== | ||
This window is found in the context menu of the process instance or its property menu. | This window is found in the context menu of the process instance or its property menu. | ||
+ | {{ :en:support:times.png }} | ||
- | {{ :en:support:times.png |}} | + | ^Element^Description| |
+ | |**Name** |Name of the activity in the process| | ||
+ | |**desired start** |If the checkbox is activated, the desired start time takes effect.| | ||
+ | |**desired starttime** |A [[#desired_start_time|Desired start time]] for an activity can be specified here, if necessary.| | ||
+ | |**Duration** |The duration of an activity can be changed here for this process instance.| | ||
+ | |**LFT** |The latest finish time of a task is displayed here.| | ||
+ | |**Start** |The actual start of an activity is displayed here.| | ||
+ | |**End** |The end date is displayed here if the task has been finished.| | ||
+ | |**Disc symbol** |If changes were made, they need to be saved for each line by clicking this symbol.| | ||
- | |< 100% 300px>| | + | === Desired start time === |
- | ^ Element ^ Description ^ | + | |
- | | **Name** | Name of the activity in the process | | + | |
- | | **desired start** | If the checkbox is activated, the desired start time takes effect. | | + | |
- | | **desired starttime** | A [[#Desired start time]] for an activity can be specified here, if necessary. | | + | |
- | | **Duration** | The duration of an activity can be changed here for this process instance. | | + | |
- | | **LFT** | The latest finish time of a task is displayed here. | | + | |
- | | **Start** | The actual start of an activity is displayed here. | | + | |
- | | **End** | The end date is displayed here if the task has been finished. | | + | |
- | | **Disc symbol** | If changes were made, they need to be saved by clicking this symbol. | | + | |
- | ===Desired start time=== | + | 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. |
- | In the activities tab, a desired start time can be set for each task. This ensures, if a previous task has been completed in an early stage, the processing time of the following task is not used immediately. The left time is added to the task correspondingly, so the original scheduled processing time is used only from the desired start time. | + | ==== Special cases in the CPM calculation ==== |
+ | With version 4.6 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 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. | ||
+ | |||
+ | === Processes with multiple ends === | ||
+ | |||
+ | 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. | ||
+ | |||
+ | {{ :en:support:cpm-multiple-ends-en.png }} | ||
+ | |||
+ | 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**. | ||
+ | |||
+ | === Processes with loops === | ||
+ | |||
+ | 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. | ||
+ | |||
+ | {{ :en:support:cpm-loops-en.png }} | ||
+ | |||
+ | Here the critical path is calculated for one process cycle. | ||
+ | |||
+ | \\ | ||