The maintenance module, Andon, provides a communication channel for your operators to notify the maintenance team about problems that occur on the production floor that require their attention. The process of such a notification we refer to as a Call and it goes through the following three phases:
First, the operator initiates the call from the stop registration page when a problem occurs. This commonly aligns with a production stop, but it is not a strict requirement. The operator may pick a particular maintenance role to get hold of, if configured, and keys in a small note of what the problem is and marks the urgency of the call. The urgency is marked as yellow or red, where the latter is considered more urgent, which enables the maintenance team to prioritize their resources accordingly.
While this module does not require any further configuration, the real value comes from notifying the maintenance team through text message- and/or email notifications.
In order to know who to notify of a particular problem. The application must be configured with information about the maintenance team’s phone numbers and/or email addresses and, optionally, their shift schedule if desired.
Call initiation from an operator point of view.
List of active calls from a maintenance team’s point of view. This page is accessed from the navigation menu on the left-hand side in the application.
Configuring the shift schedule enables the system to only send notifications to those that are marked as available at that time. This is often desired for sites that operate 24/7 where notifications outside working hours become an annoyance, especially during the night.
Furthermore, to avoid limiting this module to the maintenance team, the terminology of the crew that is to receive notifications is referred to as a Workers. It could be desirable to inform the management of any issues that take longer than a certain amount of time to fix, or the maintenance team could consist of sub-teams. Therefore, to distinguish between these teams, a Worker is assigned a Role, that identifies the
Calls go through the initiation, taken and resolved phases and notifications can be escalated to different sub-teams depending on how long the Call has been going on for and whether it is in the initiation- or taken phase. For that very reason, the notification escalation enables you to configure two kinds of delays,
The default behavior, without any configuration, is to send an immediate notification to the Workers of a particular team(/Role). If the call delay specifies anything different from 0 minutes, notifications will only ever be sent after that number of minutes have passed, assuming the call haven’t been taken by someone already.
When the Call is in the taken-phase, the taken delay then applies up until the call enters to resolved-phase. During this time, it may be useful to notify managers of calls taking longer than, for example, 1-2 hours to complete, which may have a crucial impact on operation of any upcoming batches/orders.
A worker in the Technician team will receive an immediate notification of text message when a call is initiated, and, when a call has been taken by someone. Secondly, another notification will be sent if it takes more than 60 minutes to resolve a problem. Perhaps, the technician may require further assistance from the team at this point.
Shifts may be configured to define exactly what Workers are available within certain times of the day. The implementation builds on the same concepts known from popular calendars, Outlook, iCalendar etc. and this enables complex shift patterns, which may be repetitive in nature. A schedule can be configured for a group of lines to avoid unnecessary extra work in terms of configuration.
Workers must mark their availability in one of two ways,
Under a particular schedule, there are two views, a grid that represent the upcoming shifts for the next 7 days and a calendar view from which the user can upgrade or downgrade the way they are available.