Task Attributes Basic Model
Attributes needed to support elementary operations

Whether you are already using a modern CMMS or still relying on rudimentary plain old paper procedures, there is a minimal set of attributes that you need to record in order to support elementary operations, e.g. management, classification, reporting, of your maintenance tasks, and a couple of rules to consistently interpret their values.

This article presents a basic model for ordinary corrective tasks with the aim of eliciting inquiring managers who seek to confirm or improve their practices.


MNT is a CMMS that adopts this rationale.


Initialization section

The initialization section holds those attributes required to create and identify a task. It is desirable to ease task filing by reducing the number of attributes and documenting input data normalization and default values:

Code/Title
Free format title or standarized code.
Description
Optional significant details to perform the task.
Requester Type
Normalized task requester type.
Requester Name
Optional free format name of the task requester.
Priority
Normalized with default value, relative priority as seen by the task requester.

Example:

Title/Code
A/C not working in room 303.
Description
Not set
Requester Type
HOUSEKEEPING
Requester Name
Not set
Priority
Not set

Some attributes have been left unset on purpose: Description and Requester Name are optional, and Priority must have a default value, a fact that we wanted to highlight.

Priority should be normalized, e.g. LOW, MEDIUM and HIGH priorities may be defined and a default value specified, e.g. MEDIUM.

Also the requester types need normalization, e.g. HOUSEKEEPING, FRONT DESK, CLIENT, BELL STAFF, etc. In some situations the requester name may be meaningful, e.g. when the requester type is CLIENT you may want to set the requester name to record the name of the client who notified the issue.

There is also the possibility that the maintenance department had standarized the tasks in a way that a short code gives the operators all the information they need at a glance.

Example:

Title/Code
HVAC-23-ROOM-303
...

The department would have defined a coding scheme consisting of four parts: issue category, issue type within category, affected type of resource and the resource instance. The benefits of standard coding rely on the simplicity out of which task classification can be attained.

However, standarizing task codes involves a thorough understanding of the whole range of issues that can arise. The two approaches can be combined to give the better result.

Control section

The control attributes are subject to change during the lifecycle of the task and help the team track the state and other transcient task properties:

State
Current state of the task
Is Blocking
True if the use of an important asset, such as a room, is blocked until the task is completed.

The state of the task is always set to NOT INITIATED when the task is created, i.e. it is a default value. These are all the proposed states:

  • NOT INITIATED: the task has been created but still never attended.
  • IN PROGRESS: at least one worker is currently (real time) dedicated to this task.
  • INTERRUPTED: after some work was done, the task had to be interrupted for any reason.
  • ERROR: the task data is incorrect or unclear and needs the creator or a supervisor to review it.
  • CANCELED: the task was dismissed but keeped in the history.
  • COMPLETED: the task was completed successfully.

Authorship section

Last, but not least, it may be necessary to track authorship of the tasks; this is the simplest class of audit trail and amounts basically to a pair of attributes:

Creator
The person who created the task.
Creation TS
The timestamp of task creation.

There are additional attributes and advanced procedures that would improve the model proposed here, but they lay beyond the scope of this article; in fact, some techniques are inconceivable without the aid of an automated system, such as a CMMS. This and other topics will be covered in future releases.

Share

See also

Products and services

  • IDM: identities and users.
  • MNT: plant maintenance.
  • Posh: point of sales.
  • FDK: hotel front desk.
  • Cres: central reservations system.
  • WebEn: web booking engine.
  • MProv: materials and provisioning.
  • FooBar: food & beverage.
  • Hermess: messages and alerts.
  • Asma: fixed assets.
  • Fin: finances and accounting.
  • Humar: human resources.
  • HotelFace: facebook booking app.
  • SalMar: sales and marketing.
  • HExped: expedia interface.
  • Bro: broker console.
  • Chas: online chat.