Each downtime registration is decorated with a state depending on its place in the workflow.
Mobaro supports four distinct states:
Open: (an) Initial state of a downtime registration, no matter whether created from the Mobaro app or directly from the back-office application. The Open state can be handled from two fronts:
- From the app where the operator/technician can mark the location as operational again or In the back-office application, in which case it will be moved into a Resolved state.
- In the back-office where an assignment can be attached to it, which will move it into a Blocking state.
As a small aside, the downtime can also be closed immediately in the back-office application if needed.
Blocking: Refers to an open downtime registration, which has an open assignment attached to it. This is the initial state of a downtime registration in the case of Usage Scenario 3 where all downtime registrations are created with an attached assignment. Any downtime registration can also be bumped from Open to Blocking if an assignment is manually created from the downtime registration.
An assignment attached to a downtime registration is an indication of a requirement for a formal sign-off of the downtime event before the location can be reopened. From the app, the location will be marked with the message “Blocking downtime” and the ability to mark the location as open will be disabled.
In this state, operators/technicians will have to resolve the associated assignment before being able to reopen the location. From the back-office, however, staff can force the location back into an operational state 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: Refers to a downtime registration, which has been resolved, meaning that the location is yet again in operation or allowed to be marked as operational again. A location does not automatically get marked as in operation again after a downtime registration has been resolved. This needs to be done manually either from the app or via the back-office.
Non-blocking downtime registrations can be moved into the Resolved state from the app, by marking a location, which has an open downtime registration, as in operation.
A blocking downtime registration will automatically be moved into the Resolved state when the associated assignment is resolved.
Overall, the Resolved state is primarily used to indicate that a downtime registration has been concluded from the point of view of the technicians/operators. Either by reopening the location or by solving the assignment associated with the downtime registration. At this point, the ride can be operational again – what is left, is for the administrative staff to close the downtime registration and do the final report on the amount of operational downtime, which the registration gave rise to. This is done in the back-office by selecting a downtime Registration and pressing “Close Downtime”.
Closed: Final state. This indicates a downtime registration, which has been concluded and where the administrative staff has done the final registration of the total amount of downtime the registration led to.
The different states are meant to indicate where the downtime registration is in its workflow and to communicate what role should be responsible for carrying it to the next phase. To hammer it home, let’s go through a few different workflows.
The following cross-functional flowcharts are set up with the “Role” following the y-axis and an indication of the downtime registration’s state along the x-axis.
Workflow Example 1
In the above example, we see the downtime registration being created by the Operator who’s stationed at the location. The downtime is simply created in the Open state and the entire situation revolving around is resolved. Once the Operator marks the location as In Operation again, the downtime registration is moved into the Resolved state.
Do note, that it’s the action of re-opening the location, which moves the downtime registration into the Resolved state – not the other way around. If a downtime registration is otherwise marked as Resolved, the affected location will not automatically be marked as In Operation. This is strictly a manual action.
Once the downtime registration is in the Resolved state, staff needs to finalize it in the back-office application. This is where the individual registrations are signed-off with a description and the accumulated amount of downtime incurred.
Workflow Example 2
In this example, we’re working out of a setup which has automatic assignment creation activated for all downtime registrations.
Again, the downtime registration is started by the Operator via the mobile app. Once received, the system automatically creates an associated assignment for the downtime registration. This immediately moves the downtime into the Blocking state.
In order to progress the downtime into the Resolved state, the Technician needs to solve the associated assignment. Once done, the downtime state is automatically progressed and the Operator is once again allowed to mark the location as In Operation.
Yet again, once in the Resolved state it’s the back-office staff’s job to finalize the downtime registration to progress it into the Closed state.
Workflow Example 3
This example is identical to Workflow Example 2 with the exception that the assignment associated to the downtime registration isn’t created automatically. Instead, the back-office staff does this manually.
Workflow Example 4
In the above case, we have the situation of a downtime registration ending up in the Blocking state due to having an open assignment associated with it (either created automatically or done manually by the back-office staff).
Different from Workflow Example 2, where the assignment was closed to progress the downtime registration into the Resolved state, something else is happening here.
In this example, the location is able to become operational again before the assignment can be solved. This can be a situation where a location is made operational with a minor workaround, but a permanent fix requires more work which can be postponed until after-hours. And to maintain auditability with the downtime registration, the whole assignment history is needed on the assignment directly associated to the downtime registration.
The essence of it being to be able to mark the location as operational (since the downtime has ended) but keep the associated assignment live on. In such cases, back-office personnel, and only back-office personnel, can Close the downtime registration without solving the assignment. When doing so, the downtime registration is finalized and marked as Closed. From here, the Operator as well as the Technician or the back-office staff themselves are able to mark the ride as In Operation again.
The assignment lives on and will need to be solved by the technician but they are free to do so at a later point in time without affecting the downtime registration – but the association between the downtime registration and the assignment persists.