In order to access the new settings as well as the new “Downtime” section of the back-office application, a new privilege has been added to Roles.
Bundle up the users who are meant to be able to do the following in back-office:
- Mark locations as operational/out of operation
- View and Edit the Operational Log of a location
- Access the “Downtime” section in back-office where downtime events can be registered, resolved and edited.
Enabling Operational Logging for Locations
By default, no locations are enabled for registration of Downtime or Operational hours. This has to be done individually to the locations for which it is relevant.
This is done via the Locations section in back office. On the settings panel for each location, a new setting has been added called "Enable Operational Logging".
Enabling this setting will open up for toggling the locations between "In Operation" and "Out of Operation" as well as allowing you to do downtime registrations for that location.
Also note, that enabling this on a location will all users who has access to that particular location, to access it through the "Operations" tile in the mobile app.
For reporting purposes, individual downtime events can be categorized. Categories are created under “Configuration” where you find the editor for “Downtime Categories”.
Individual downtime events can be decorated with multiple categories at a time and is meant to work as a convenient filter when browsing the list of registered downtime events as well as allowing you to do reporting on accumulated downtime with the categories as a pivot point.
Force assignment creation for all downtime events
Depending on how you want to work with downtime events, you may want to force the creation of an assignment whenever a downtime event is registered in the system. From the “Configuration” section you are able to enable this feature by selecting “Create assignment when a new downtime is started”.
When this is enabled, you are able to specify a User Group, which should be set as the assignee of the automatically created assignments as well as define, which categories the assignments should be decorated with.
Automatic assignment creation for newly registered downtime will set their initial state to be Blocking. In short, the location will automatically be marked with a red bar on the Location Overview dashboards and operators/technicians will not be able to mark the location as In Operation via the mobile app.
In the following, you will find 3 rather simple examples on the different ways you can make use of Downtime Reporting depending on how you want it to work and depending on whether you want to make use of assignments and registration of operational hours.
Usage Scenario 1: Pure Downtime Registration
At the very core of this feature lies the ability to capture information about downtime periods on your locations.
A downtime event can be initiated either by an operator/technician who is using the app, or it can be registered in the back-office application by users who have appropriate access.
The app is intended to be a way for allowing staff on the go to easily register downtime immediately when it occurs. If the staff isn’t equipped with the Mobaro mobile app, downtime events can also be “phoned in” to office staff who can then start the downtime registration on their behalf.
While downtime events can be started from both the app and back-office, handling the individual events can only be done in back-office. When closing an open downtime event, the accumulated amount of downtime, which the event incurred, is registered.
Key points are:
- Focus is on registering events that lead to downtime
- Downtime registrations are initiated either by operator/technician through the mobile app or office staff through the back-office application
- Downtime registration is closed and finalized by office staff in the back-office application
Usage Scenario 2: Downtime and Ops Hours
In addition to registering downtime, we also support capturing information about operational hours on the locations. Combined with downtime registrations, we are able to calculate not just the accumulated downtime over a period of time but can give a rather precise downtime percentage where the downtime is held up against the amount of operational hours the ride had/should have had.
By marking the locations as “in operation” or “out of operation” as a part of the daily routine, we can calculate the amount of operational hours for the individual locations.
This can be done either through the mobile app or through back-office.
Operational hours are calculated as the time span between a location being marked as “operational” and it being toggled as “out of operation”. These open/close events are listed under the locations’ individual operational log.
Users in back-office are able to edit and delete these events if needed.
Marking a location as in operation or out of operation has no direct effect on scheduled checklists or assignments. It is strictly meant as a way to capture exact operational hours for the individual locations with the purpose of being able to calculate the exact downtime/uptime percentage. The only thing that can have an effect on a ride’s operational status is, of course, the presence of an open downtime event.
If a downtime event is created for a location, which is marked as in operation, this will force the location into an “out of operation” state. This is reflected in both the app and back-office
From the location’s operational log, it’s clear that the operational status was interrupted by the creation of a downtime event.
Whenever the event is cleared, the operator/technician is able to mark the ride as operational again. Doing this, will start the uptime counter again. Do note, that the downtime event is not finalized yet, as reflected from the back-office overview. The downtime is now listed as “Resolved” – but in order to close this event entirely, it needs to be finalized by the administrative personnel where a final description of the issue can be logged and the accumulated downtime which the downtime event led to can be registered.
Usage Scenario 3: Assignment Management for Downtime Events
Assignments for downtime is meant to act as a way of tying assignments into your downtime workflow in order to track the corrective actions that might be needed in order to resolve a downtime registration. Assignments can be set up to be created automatically [!] for every new downtime registration or can be done on-demand as a manual action on the individual downtime registrations in back-office.
Manually creating an assignment for a downtime registration is done from back-office by inspecting one of the downtime events from the list.
On the list of details for the downtime registration you’ll find the option to “Create Assignment” – checking this box will allow you to specify the assignment’s description, the assignee as well categorize the assignment.
When inspecting the downtime registration, there’s a clear one-to-one with the assignment. The assignment will show up in the assignee’s list as any other assignment. Additionally, on the assignment list in back-office the assignment is decorated with an icon indicating that it originates from a downtime registration.
Clicking the icon also takes you directly to the associated downtime registration.
When an assignment is created for a downtime registration, it is moved into a “Blocking” state. Blocking meaning that the assignment, by default, needs to be solved before the location is able to be marked as In Operation again. A location with a blocking downtime registration will also be unable to be marked as In Operation via the mobile app. The location will be explicitly marked with “Blocking downtime” and the button to toggle the state of the location will be disabled
As previously described in Workflow Example 3 and 4 assignment can be completed either as a part of the downtime registration or outside the downtime registration. They are not strictly dependent on each other.