RFC 1297 (rfc1297) - Page 2 of 12

NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist ("NOC TT REQUIREMENTS")

RFC 1297                  NOC TT REQUIREMENTS               January 1992


PURPOSES OF A NOC TROUBLE TICKET SYSTEM

   A good Network Operations Trouble Ticket System should serve many
   purposes:

      1) SHORT-TERM MEMORY AND COMMUNICATION ("Hospital Chart").  The
      primary purpose of the trouble ticket system is to act as short-
      term memory about specific problems for the NOC as a whole.  In a
      multi-operator or multi-shift NOC, calls and problem updates come
      in without regard to who worked last on a particular problem.
      Problems extend over shifts, and problems may be addressed by
      several different operators on the same shift.  The trouble ticket
      (like a hospital chart) provides a complete history of the
      problem, so that any operator can come up to speed on a problem
      and take the next appropriate step without having to consult with
      other operators who are working on something else, or have gone
      home, or are on vacation.  In single-room NOCs, an operator may
      ask out loud if someone else knows about or is working on a
      problem, but the system should allow for more formal communication
      as well.

      2) SCHEDULING and WORK ASSIGNMENT.  NOCs typically work with many
      simultaneous problems with different priorities.  An on-line
      trouble ticket system can provide real time (or even constantly
      displayed and updated) lists of open problems, sorted by priority.
      This would allow operators to sort their work at the beginning of
      a shift, and to pick their next task during the shift.  It also
      would allow supervisors and operators to keep track of the current
      NOC workload, and to call in and assign additional staff as
      appropriate.

      It may be useful to allow current priorities of tickets change
      according to time of day, or in response to timer alerts.

      3) REFERRALS AND DISPATCHING.  If the trouble ticket system is
      thoroughly enough integrated with a mail system, or if the system
      is used by Network Engineers as well as Network Operators, then
      some problems can be dispatched simply by placing the appropriate
      Engineer or Operator name in an "assigned to" field of the trouble
      ticket.

      4) ALARM CLOCK.  Typically, most of the time a trouble ticket is
      open, it is waiting for something to happen.  There should almost
      always be a timer associated with every wait.  If a ticket is
      referred to a phone company, there will be an escalation time
      before which the phone company is supposed to call back with an
      update on the problem.  For tickets referred to remote site
      personnel, there may be other more arbitrary timeouts such as



Johnson