Sistema de seguimiento de incidencias

Un sistema de seguimiento de incidencias (también conocido como ITS , sistema de tickets de incidencias , sistema de tickets de soporte , sistema de gestión de solicitudes o sistema de tickets de incidentes ) es un paquete de software que gestiona y mantiene listas de incidencias . ^{[ 1 ]} Los sistemas de seguimiento de incidencias se utilizan generalmente en entornos colaborativos , especialmente en colaboraciones grandes o distribuidas, pero también pueden ser empleados por individuos como parte de un régimen de gestión del tiempo o de productividad personal . Estos sistemas suelen abarcar la asignación de recursos , el control del tiempo, la gestión de prioridades y el flujo de trabajo de supervisión, además de implementar un registro centralizado de incidencias.

En el ámbito institucional, los sistemas de seguimiento de incidencias se utilizan habitualmente en los centros de atención al cliente para crear, actualizar y resolver incidencias reportadas por los clientes, o incluso por otros empleados de la organización. Un ticket de soporte debe incluir información esencial sobre la cuenta involucrada y la incidencia detectada. ^{[ 2 ]} Un sistema de seguimiento de incidencias también suele contener una base de conocimientos con información sobre cada cliente, soluciones a problemas comunes y otros datos similares.

Un sistema de seguimiento de incidencias es similar a un " bugtracker " y, a menudo, una empresa de software vende ambos. Algunos bugtrackers pueden utilizarse como sistemas de seguimiento de incidencias, y viceversa. El uso constante de un sistema de seguimiento de incidencias o errores se considera una de las características distintivas de un buen equipo de desarrollo de software. ^{[ 3 ]}

Un ticket, dentro de un sistema de seguimiento de incidencias, es un informe continuo sobre un problema específico, su estado y otros datos relevantes. Suelen crearse en un servicio de asistencia técnica o centro de llamadas y casi siempre tienen un número de referencia único, también conocido como número de caso , incidencia o registro de llamada , que permite al usuario o al personal de asistencia localizar, actualizar o comunicar rápidamente el estado de la incidencia o solicitud del usuario.

Estos tickets se denominan así por su origen como pequeñas tarjetas dentro de un sistema tradicional de planificación de trabajo montado en la pared, cuando comenzó este tipo de soporte. Los operadores o el personal que recibían una llamada o consulta de un usuario rellenaban una pequeña tarjeta con los datos del usuario y un breve resumen de la solicitud, y la colocaban en una posición (normalmente la última) en una columna de espacios pendientes para el ingeniero correspondiente, determinando así el miembro del personal que atendería la consulta y la prioridad de la solicitud.

La base conceptual común entre los sistemas de seguimiento de incidencias y los sistemas de seguimiento de errores es que una incidencia válida debe ser susceptible de una resolución decisiva (como "completada", "corregida" o un consenso grupal de que la incidencia no merece la pena resolverse, como "no es un problema" o "no se corregirá"); que cada incidencia es única (los informes de problemas duplicados se fusionan rápidamente en una única incidencia o ticket activo en la mayoría de los casos); y, más allá de la fase de selección, que existe una persona con la responsabilidad formal de dar seguimiento a la incidencia (esta responsabilidad formal suele cambiar de manos varias veces a medida que la incidencia evoluciona). En los sistemas de seguimiento de errores, las incidencias suelen estar relacionadas con la calidad o las funcionalidades de una base de código (lo que es inherentemente un entorno de gestión de proyectos ), mientras que en los sistemas generalizados de seguimiento de incidencias, los tickets suelen estar relacionados con el servicio o las relaciones, con vínculos más estrechos con las cuestiones de gestión de relaciones con el cliente (CRM). ^{[ 4 ]}

Los problemas pueden tener varios aspectos. A cada problema del sistema se le puede asignar un nivel de urgencia, según su importancia general. Los problemas de baja o nula urgencia son menores y deben resolverse cuando el tiempo lo permita.

Otros detalles de los problemas incluyen el cliente que experimenta el problema (ya sea externo o interno), la fecha de envío, ^{[ 5 ]} descripciones detalladas del problema que se está experimentando, soluciones o alternativas intentadas y otra información relevante. Cada problema mantiene un historial de cada cambio.

Los sistemas de seguimiento de incidencias cumplen diferentes funciones, en particular:

• Registro de disfunciones, errores y solicitudes (por ejemplo, manualmente o por correo electrónico a través de sistemas de gestión de respuestas).
• Distribución y asignación de los asuntos a las personas responsables.
• Supervisión del manejo, el tiempo empleado y la calidad del trabajo.
• Garantizar la observación de los procesos internos mediante control forzoso con ayuda de flujos de trabajo.
• Análisis estadístico del número de entradas
• Generación automática de tickets mediante sistemas de alarma, por ejemplo, monitorización de red.
• Cumplimiento de acuerdos de servicio externos (Acuerdo de Nivel de Servicio, SLA )
• Recopilación sistemática de preguntas y respuestas para FAQ
• Assignment of a priority to each issue based on the overall importance of that issue, the customer, date of submission, SLA
• Containing a detailed descriptions of the problem being experienced, attempted solutions or workarounds, and other relevant information
• Maintaining of a history of each change

An example scenario is presented to demonstrate how a common issue tracking system would work:

1. A customer service technician receives a telephone call, email, or other communication from a customer about a problem. Some applications provide built-in messaging system and automatic error reporting from exception handling blocks.
2. The technician verifies that the problem is real, and not just perceived. The technician will also ensure that enough information about the problem is obtained from the customer. This information generally includes the environment of the customer, when and how the issue occurs, and all other relevant circumstances.
3. The technician creates the issue in the system, entering all relevant data, as provided by the customer.
4. As work is done on that issue, the system is updated with new data by the technician. Any attempt at fixing the problem should be noted in the issue system. Ticket status most likely will be changed from open to pending.
5. After the issue has been fully addressed, it is marked as resolved in the issue tracking system.

If the problem is not fully resolved, the ticket will be reopened once the technician receives new information from the customer. A Run Book Automation process that implements best practices for these workflows and increases IT personnel effectiveness is becoming very common.

• Help desk software
• Comparison of help desk issue tracking software
• Comparison of issue-tracking systems
• Climate Action Tracker
• Government by algorithm
• Issue log
• National Priorities List
• Suggestion box
• Open-source software development
• Prioritization
• Push–pull strategy
• Resource allocation
• User innovation