This shows you the differences between two versions of the page.
en:support:cpm [2014/12/16 16:31] 127.0.0.1 external edit |
en:support:cpm [2021/07/01 09:52] |
||
---|---|---|---|
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: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! | ||
- | |||
- | ---- | ||
- | ====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. | ||
- | |||
- | ==== Critical path==== | ||
- | 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 . | ||
- | |||
- | {{ :en:support:critical_path.png |}} | ||
- | |||
- | ---- | ||
- | |||
- | ==== 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 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 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. | ||
- | |||
- | === 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 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 === | ||
- | 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 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. | ||
- | |||
- | ---- | ||
- | |||
- | ==== The traffic-light symbol ==== | ||
- | === Green light === | ||
- | 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. | ||
- | |||
- | > 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. | ||
- | |||
- | ---- | ||
- | ==== 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 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| 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. | ||
- | |||
- | |||
- | ---- | ||
- | ==== 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]]. | ||
- | |||
- | {{ :en:support:handover_buffer.png |}} | ||
- | |||
- | |||
- | 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. | ||
- | 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. | ||
- | actual processing time = scheduled processing time + possibly arised buffer | ||
- | |||
- | ==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 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. | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | ---- | ||
- | |||
- | |||
- | ==== Requirement ==== | ||
- | 3 points are required for activating the CPM modul: | ||
- | |||
- | - A processing time is entered on each node | ||
- | - 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// | ||
- | |||
- | |||
- | ---- | ||
- | |||
- | |||
- | |||
- | ==== Examples ==== | ||
- | {{ :en:support:hours.png |}} | ||
- | |||
- | ---- | ||
- | |||
- | === Tasks green === | ||
- | |||
- | 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. | ||
- | |||
- | === 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. | ||
- | |||
- | 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 === | ||
- | |||
- | 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) | ||
- | |||
- | |||
- | ----- | ||
- | === 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. | ||
- | |||
- | ----- | ||
- | |||
- | ====Edit processing times subsequently and desired start times==== | ||
- | This window is found in the context menu of the process instance or its property menu. | ||
- | |||
- | |||
- | {{ :en:support:times.png |}} | ||
- | |||
- | |< 100% 300px>| | ||
- | ^ 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 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. | ||
- | |||
- | |||