Last modified on 10 July 2024, at 11:40

MRO (Plugin)

Revision as of 11:40, 10 July 2024 by CWI (Talk | contribs) (See also)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The MRO plugin provides a set of UBIK® objects which allow to represent and document maintenance, repair and operations work on the mobile client. An respective implementation of this set of features is available on UBIK® WinX.

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.

IC Attention.pngThe 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

Check 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.

Inspection Task

A Inspection 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).

See also