Difference between revisions of "MRO (Plugin)"
m |
m |
||
| Line 1: | Line 1: | ||
The MRO plugin provides a set of {{UBIK}} objects which allow to represent and document maintenance, repair and operations work on the mobile client. | The MRO plugin provides a set of {{UBIK}} objects which allow to represent and document maintenance, repair and operations work on the mobile client. | ||
| − | == | + | == Basic Features == |
Objects classified as MRO objects in general provide a technical and organisational status as well as the overall work progress based on the underlying data branch. | Objects classified as MRO objects in general provide a technical and organisational status as well as the overall work progress based on the underlying data branch. | ||
=== Technical Status === | === Technical Status === | ||
| − | The technical status indicates whether all tasks | + | The technical status indicates whether all tasks on this or on subsequent objects in the underlying data branch have been finished. Also other information is included in this status, e.g. if a inventory object is reported as damaged, its parent objects will receive a certaub status indicating that a problem was reported in the child items. |
=== Organisational Status === | === Organisational Status === | ||
| − | The organisational indicates the amount of confirmed work done in the data branch. It can include a work package already confirmed or tasks that are already locked by their owning workpackage. | + | The organisational status indicates the amount of confirmed work done in the data branch. It can include a work package already confirmed or tasks that are already locked by their owning workpackage. |
| − | == | + | === Work Progress === |
| − | + | The work progress is calculated from the current work progress and from the progress cumulated from subsequent objects in the underlying data branch. This indicator shows the amount of work done in the data branch. | |
| − | The | + | |
| − | + | == MRO Objects == | |
| − | + | A set of specific objects can be used to provide the required structure for MRO: | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | == | + | === Task Owner === |
| − | + | A [[MROCLS_MRO_TASKOWNER|Task Owner]] is an object having a substructure of jobs to be done. It can have a tree of other task owners or work packages underneath that will update the status of the task owner. This status consists of technical, organisational and progress information. With a task owner a user can get an overview of all the work to be done in the underlying job structure. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | == | + | === Work Package=== |
| − | + | A [[MROCLS_MRO_WORKPACKAGE|Work Package]] is a collection of objects to collect and summarize other task owning objects, workpackages, or tasks. A simple workpackage has a certain amount of tasks that have to be finished in order to confirm the workpackage as done. More complex workpackages can also own other underlying workpackages that have to be confirmed. Confirming a workpackage itself requires a progress of 100% of all related tasks, as well as 100% confirmed sub work packages. | |
| + | |||
| + | === Task === | ||
| + | A [[MROCLS_MRO_TASK|Task]] is an object reporting a certain progress to the owning workpackage. There are several specialized types of task objects. All kinds of tasks have a property called '''VALUE''' in common. It is very important, that this property is able to be validated. Therefore, a MetaAttribute (providing a validation timestamp by default) has to be attached on the used MetaProperty. | ||
| + | |||
| + | {{Attention|The MetaProperty ''VALUE'' has to use [[Attributes]] in order to be validated. Otherwise, the calculation of work progress will not be possible.}} | ||
| + | |||
| + | ==== Measurement Task ==== | ||
| + | A [[MROCLS_MRO_MEASUREMENT_TASK|Measurement Task]] inherits from [[MROCLS_MRO_TASK|Task]] and documents a measured value (e.g. read from a pressure gauge). Once a value has been entered, the task is finished. Alternatively, the task can also be closed by the option ''Not Applicable'' to document the situation of not being able to fullfill the measurement (e.g. the pressure gauge is broken). | ||
| + | |||
| + | ==== Progress Task ==== | ||
| + | [[MROCLS_MRO_PROGRESS_TASK| Progress Task]] inherits from [[MROCLS_MRO_MEASUREMENT_TASK|Task]] and reports a certain progress while fullfilling a task. The progress will influence the overall progress of the owning workpackage. If the task cannot be fullfilled, it can also be finished with the option ''Not Applicable''. | ||
| + | |||
| + | ==== Check Task ==== | ||
| + | A [[MROCLS_MRO_CHECK_TASK|Check Task]] inherits from [[MROCLS_MRO_TASK|Task]] and is finished, when the user reports with a positive or negative answer or ''Not Applicable'' (e.g. reporting a yes/no answer for existing equipment). | ||
| + | |||
| + | ==== Inspection Task ==== | ||
| + | [[MROCLS_MRO_INSPECTION_TASK|Inspection Task]] inherits from [[MROCLS_MRO_TASK|Task]] and is finished by reporting ''Done'' or ''Not Applicable''. This is intended for a simple To-Do task that is either done or not. | ||
== See also == | == See also == | ||
Revision as of 12:30, 3 August 2016
The MRO plugin provides a set of UBIK® objects which allow to represent and document maintenance, repair and operations work on the mobile client.
Contents
Basic Features
Objects classified as MRO objects in general provide a technical and organisational status as well as the overall work progress based on the underlying data branch.
Technical Status
The technical status indicates whether all tasks on this or on subsequent objects in the underlying data branch have been finished. Also other information is included in this status, e.g. if a inventory object is reported as damaged, its parent objects will receive a certaub status indicating that a problem was reported in the child items.
Organisational Status
The organisational status indicates the amount of confirmed work done in the data branch. It can include a work package already confirmed or tasks that are already locked by their owning workpackage.
Work Progress
The work progress is calculated from the current work progress and from the progress cumulated from subsequent objects in the underlying data branch. This indicator shows the amount of work done in the data branch.
MRO Objects
A set of specific objects can be used to provide the required structure for MRO:
Task Owner
A Task Owner is an object having a substructure of jobs to be done. It can have a tree of other task owners or work packages underneath that will update the status of the task owner. This status consists of technical, organisational and progress information. With a task owner a user can get an overview of all the work to be done in the underlying job structure.
Work Package
A Work Package is a collection of objects to collect and summarize other task owning objects, workpackages, or tasks. A simple workpackage has a certain amount of tasks that have to be finished in order to confirm the workpackage as done. More complex workpackages can also own other underlying workpackages that have to be confirmed. Confirming a workpackage itself requires a progress of 100% of all related tasks, as well as 100% confirmed sub work packages.
Task
A Task is an object reporting a certain progress to the owning workpackage. There are several specialized types of task objects. All kinds of tasks have a property called VALUE in common. It is very important, that this property is able to be validated. Therefore, a MetaAttribute (providing a validation timestamp by default) has to be attached on the used MetaProperty.
 | The MetaProperty VALUE has to use Attributes in order to be validated. Otherwise, the calculation of work progress will not be possible. |
Measurement Task
A Measurement Task inherits from Task and documents a measured value (e.g. read from a pressure gauge). Once a value has been entered, the task is finished. Alternatively, the task can also be closed by the option Not Applicable to document the situation of not being able to fullfill the measurement (e.g. the pressure gauge is broken).
Progress Task
Progress Task inherits from Task and reports a certain progress while fullfilling a task. The progress will influence the overall progress of the owning workpackage. If the task cannot be fullfilled, it can also be finished with the option Not Applicable.
Check Task
A Check Task inherits from Task and is finished, when the user reports with a positive or negative answer or Not Applicable (e.g. reporting a yes/no answer for existing equipment).
Inspection Task
Inspection Task inherits from Task and is finished by reporting Done or Not Applicable. This is intended for a simple To-Do task that is either done or not.
See also
- MROCLS MRO TASKOWNER (Classification)
- MROCLS MRO WORKPACKAGE (Classification)
- MROCLS MRO TASK (Classification)
- MROCLS MRO MEASUREMENT TASK (Classification)
- MROCLS MRO PROGRESS TASK (Classification)
- MROCLS MRO CHECK TASK (Classification)
- MROCLS MRO INSPECTION TASK (Classification)
- MRO Objects (UBIK WinX)
