Is Alarm to Trouble Ticket always one way traffic?Will Harthoorn Back in the last century one of the earliest third party integrations developed for Netcool OMNIbus was a gateway to the Remedy Action Request System (ARS). That gateway allowed an operator to create a trouble ticket from an OMNIbus event and thus initiated the now standard process from event management to incident management. This process is essentially one way the posting back of the trouble ticket number notwithstanding, and the event manager and service request server are treated as two entirely separate systems that occasionally exchange information. The question is, should that remain so, or should the event manager be more closely integrated into the incident management process. We tend to think of incident management as a linear process, which can be drawn as: In most implementations the process transitions from the event manager to the incident manager at the Assign stage and often the users of the event management system lose visibility of progress until their event is closed, either because a clear alarm is received from the repaired device or because the ticket is closed and that in turn clears the initiating alarm. However at a large telco I have noted operators use a tool to update the Summary field of an alarm with information about the fix progress so some feedback is clearly welcome.
The linear process also assumes that only a single string of teams are involved - a monitoring team detecting and diagnosing who hand over to field engineering for the actual fix. However that is rarely the case. In my time in network support I could tell the potential impact of a problem by the number of senior managers hovering around my desk, and more formally there was a User Help team who were |