Measuring downtime, that is, describing the total amount of lost operational hours a downtime registration might have incurred, is done via the back-office when closing a downtime registration.
This is a manual step to allow for rather precise measurements, but the system does its best to help you with easy registration.
The rule of thumb, when registering downtime durations, is to only register the amount of time the location was out of operation where it should have been operating. This comes easy when handling short-lived downtime registrations, which are opened and closed within a few minutes or hours.
To nail it down, let’s go through general examples.
Scenario 1: Short-lived downtime registration
Consider this simple scenario, for a single location:
In this example, we have a location which is expected to be operational from 06:00 in the morning until 20:00 in the evening. That’s a total of 14 hours of expected operational hours.
In this example, we have a downtime registration that starts at 14:00 and ends at 15:00 resulting in 1 hour of operational downtime.
When closing the downtime registration in back-office (which might only get done at the end of the day), you are expected to verify the amount of downtime. The system looks at the time where the downtime was registered and the time where the registration was moved to the Resolved state – the time between these two are suggested for you, but you are welcome to override this if needed.
In this simple example, we will end up having 13 hours of operational hours registered (over the course of two separate intervals) and 1 hours of downtime.
A slightly different way to look at the same situation is to view how the location moves between the Closed, Open and Blocking state over the course of the day. The same situation would in that case look like this:
On the timeline above, we start the day by having the location marked as Closed. At 06:00 in the morning, the location has passed all inspections and are toggled to.
At 14:00 in the afternoon, a downtime registration is created – this automatically moves the location out of the In Operation state.
At 15:00 the location is again marked as In Operation. This lasts until 20:00 in the evening where the location is, once again, toggled back into the Closed state.
From this, Mobaro calculates the total amount of nominal operational hours to be:
<registered ops hours> + <registered downtime> => 13 + 1 = 14 hours.
In this case, the downtime percentage would be calculated to be 1/14 = 7.1%
Scenario 2: Downtime registration spanning across normal operational hours
Consider a similar scenario, but where the downtime registration exceeds the expected operational hours.
On this particular day, we still have our 14 hours of expected operation for the location. A downtime registration gets initiated 14:00 in the afternoon and isn’t resolved before 22:00 in the evening.
In such situations, you need to be bit alert. The system has registered a timespan of 8 hours for the downtime registration and will suggest that as the duration when closing the registration.
However, registering 8 hours of downtime would result the nominal ops. hours for the location to be higher than it should be as it would be calculated as 8 + 8 = 16 hours. This is due to registering 8 hours of operational hours before the downtime gets registered. If registering 8 hours of downtime in such a case you would end up with a downtime percentage of 50% - however, the nominal operational hours for the location is only 14 and was planned to end at 20:00. In reality, the location only suffered from 6 hours of lost operational hours (from 14:00 to 20:00) which would equal a downtime percentage of 6/14 = 42%.
The takeaway from this is that the downtime duration registered on the individual entries should only represent the amount of lost operational hours.
Scenario 3: Downtime registration spanning over multiple days
Expanding on the previous example, let’s hammer it in with an example where a downtime registration spans across multiple days. Consider the following timeline(s):
In this scenario we have a downtime registration, which is initiated on the first day at 14:00 and resolved the next day at 22:00. Despite perhaps looking a bit different, this situation is really similar to the one described in the 2nd scenario.
From the system’s standpoint, this situation sums up to 8 hours of “Closed” 8 hours of “Open” and 32 hours of downtime. Looking at it this way, this would sum up to 32/40 = 80% of downtime. The 40 being the 8 hours operation added to the 32 hours of downtime.
This is of course wrong, but since the system lacks information about when the location should have closed on day 1, as well as lacking any information about open/close events for the second day, this is up to you to account for when finalizing the downtime registration and registering the final downtime duration.
It takes a bit of mental gymnastics, but the final calculation should be as follows:
Downtime for day 1 should be 6 hours. The location goes down at 14:00 and was expected to operate until 20:00.
Downtime for day 2 should be 14 hours. The downtime is carried over from the previous day and isn’t resolved until late in the evening, but it’s “only” the 14 hours of expected operation for that location, which have been lost.
In conclusion, the total amount of downtime that should be registered is 20 hours – out of a total of 28 hours of expected operational hours for those two days. This would result in a downtime percentage of 71%.