Introducing downtime

Follow

This article is an introduction to downtime. It introduces the basic use of downtime including the different states a downtime can enter during a workflow. Furthermore we introduce the general terminology of downtime.

 

Why use downtime?

With Downtime you can register interruptions which result in downtime on a location as well as register assignments related to a particular downtime incident.

Downtime reporting can have three different focus points:

1. Pure downtime registration focus on the events that lead to downtime.
2. By registering downtime and adding focus on operational hours you get an indication of your lost operational hours because of a downtime.
3. Furthermore by adding assignment management for downtime events you can track the corrective actions that have been done in order to resolve a downtime registration.

 

Downtime states

Each downtime registration is decorated with a state depending on its place in the workflow. The states are: open, blocking, resolved and closed. 

Open is the initial state of a downtime registration, regardless if it is created from the mobile or web app. The Open state can be handled from two fronts:

1. From the mobile app where the operator/technician can mark the location as operational again or from the web app where an administrative person can mark the downtime as ended, in which cases it will be moved into a resolved state.
2. From the web app where an assignment can be attached to it, which will move it into a blocking state.

 

Blocking is the state of an open downtime, which has an open assignment attached to it. This is the initial state of a downtime registration, if you setup Mobaro to automatically create assignments in case of a downtime. A downtime will enter the blocking state if an assignment is manually created.

In the mobile app, the location will be marked with the message “Blocking downtime” and the ability to mark the location as open will be disabled. Operators/technicians will have to resolve the associated assignment, which leads the downtime to a resolved state. 

Note: Administrative staff can force the location back into an operational state from the web app if needed. This is done to support situations where the issue has been resolved and the location is operational again, but the assignment should be kept and be set to active outside the downtime registration it arose from.

 

Resolved is the state of a downtime, which has been resolved, and the location is yet again in operation or allowed to be marked as operational. A location does not automatically get marked as in operation after a downtime registration has been resolved. This needs to be done manually either from the mobile or web app:

• Open downtime registrations can be moved into the resolved state from the mobile app, by marking the location as in operation.
• A blocking downtime registration will automatically be moved into the resolved state when the associated assignment is resolved.

The resolved state is used to indicate that a downtime registration has been concluded from the point of view of the technicians or operators. The last step is for the administrative staff to close the downtime registration and do the final report on the amount of actual downtime. This is done in the web app by selecting a downtime Registration and pressing “Close Downtime”.

 

Closed is the final state, and indicates that the downtime registration has been concluded.

 

General terminology

The following list includes distinctive terminology related to the use of downtime. 

• Open/Close events is the act of marking a location as either “in operation” or “out of operation”. Operational hours are calculated based on the timespan between each “open” event and the following “close” event. This can be done by the operators/technicians from the mobile app as well as by the administrative staff on the location tab in the web app.
• Downtime registration refers to the single downtime interruption which can be registered by operations or technicians through the mobile app or created by administrative staff in the web app.
• Downtime categories are made and customized by administrative staff, and are added to downtime for reporting purposes to register the cause of the downtime. A single downtime can be associated with one or more categories.
• Actual downtime is the amount of time the downtime has incurred, when the downtime registration is finalized by administrative staff. This is done in the web app and is the foundation for the calculation of the total amount of downtime for an individual location.
• Operational log is attached to each location and is accessible from the Locations tab in the web app. It provides a timeline of all open/close events registered on any individual location. Administrative staff can add, delete and edit these. The log of open/close events is used to calculate the accumulated operation hours for a location.