Sistema de seguimiento de incidentes
Un sistema de seguimiento de incidentes (denominado en inglés como issue tracking system, trouble ticket system o incident ticket system) es un paquete de software que administra y mantiene listas de incidentes, conforme son requeridos por una institución. Los sistemas de este tipo son comúnmente usados en la central de llamadas de servicio al cliente de una organización para crear, actualizar y resolver incidentes reportados por usuarios, o inclusive incidentes reportados por otros empleados de la organización. Un sistema de seguimiento de incidencias también contiene una base de conocimiento que contiene información de cada cliente, soluciones a problemas comunes y otros datos relacionados. Un sistema de reportes de incidencias es similar a un Sistema de seguimiento de errores (bugtracker) y, en algunas ocasiones, una compañía de software puede tener ambos, y algunos bugtrackers pueden ser usados como un sistema de seguimiento de incidentes, y viceversa.
Un ticket es un archivo contenido en el sistema de seguimiento que contiene información acerca de intervenciones de software hechas por personal de soporte técnico o terceros a pedido de un usuario final que ha reportado un incidente que está impidiéndoles trabajar en sus computadoras cuando ellos esperaban poder hacerlo. Los tickets se crean generalmente en un ambiente de help desk o call center. Típicamente el ticket tiene un número único de referencia, también conocido como un número de caso, incidente o reporte de llamada, el cual es usado para permitir al cliente o al personal de soporte localizar, añadir o comunicar el estado del incidente o requerimiento.
Estos tickets también son llamados así debido a su origen como pequeñas tarjetas con un pequeño muro a manera de un sistema de planificación de trabajo acumulado. Cuando este tipo de soporte comenzaba, los operadores o personal recibía una llamada o consulta de un usuario podía llenar una tarjeta con los detalles del usuario y un breve resumen de su requerimiento y lo colocaba en una posición (usualmente la última) en una columna de "pendientes" para que una persona apropiada pueda determinar qué persona debía encargarse de la consulta y la prioridad del requerimiento.
Arquitectura
El diseño más común de sistema de seguimiento de incidentes es relativamente simple. Una base de datos en el principal repositorio de almacenamiento para todos los datos. Estos datos son manejados por la capa de negocio de la aplicación. Esta capa brinda a los datos en bruto más estructura y significado. preparándola para ser comprensible por los usuarios. Los ahora datos comprensibles por humanos son presentados al soporte técnico por otra aplicación de software o página web. El usuario final del sistema de seguimiento de incidentes puede crear nuevos incidentes por completar, leer incidentes existentes, añadir detalles de los mismos o resolverlos. Cada vez que el usuario del sistema efectúa un cambio, el sistema de seguimiento de incidentes registra la acción y quién la hizo, llevando un histórico de las acciones tomadas. Cada usuario del sistema puede tener incidentes asignados, esto es, cada usuario es responsable por la apropiada resolución de ese incidente. Esto es presentado generalmente al usuario en un formato de lista. El usuario puede tener la opción de reasignar un incidente a otro usuario, de ser necesario. Por seguridad, un sistema de seguimiento de incidentes autenticará sus usuarios antes de permitirles el acceso al sistema. No hay una fecha exacta en la que se creó el primer sistema de tickets, pero se sabe que los sistemas de seguimiento de problemas y solicitudes han estado en uso desde la década de 1960 en algunos entornos de tecnología de la información. Con el tiempo, los sistemas de tickets se han expandido para ser utilizados en una amplia variedad de industrias y aplicaciones, incluyendo el soporte técnico, la atención al cliente, la gestión de proyectos y más.
Incidentes
Los incidentes pueden tener muchos aspectos. Cada incidente en el sistema puede tener un nivel de urgencia asignado, basado en la importancia total de ese incidente. Los incidentes críticos son los más severos que deben ser resueltos en la forma más expedita posible, tomando precedencia sobre todos los demás incidentes. Los incidentes de urgencia baja o cero son menores, y deben ser resueltos como lo permita el tiempo. Otros detalles de los incidentes incluyen la experiencia del cliente con el incidente (sea interna o externa), fecha de registro, descripciones detalladas del problema experimentado, intentos de soluciones y otra información relevante. Como se notó previamente, cada incidente mantiene un historial de cada cambio.
Flujo de trabajo
Un escenario de ejemplo es presentado para demostrar cómo un sistema típico de seguimiento de incidencias puede trabajar:
- Un técnico de servicio al cliente recibe una llamada telefónica, correo electrónico, u otra comunicación de un cliente acerca de un programa. Algunas aplicaciones proveen reporte automático de errores a partir de bloques de manejo de excepciones.
- El técnico verifica que el problema es real y no sólo percibido. El técnico podría también asegurarse de que se ha obtenido suficiente información acerca del problema por parte del cliente. Esta información generalmente incluye el ambiente del cliente, cuándo y cómo ocurre el incidente, y otras circunstancias relevantes.
- El técnico crea el incidente en el sistema, ingresa toda la información relevante tal como fue proporcionada por el cliente.
- Conforme se trabaja en el incidente, el sistema es actualizado con nuevos datos por el técnico. Cada intento de reparar el problema debe ser anotado en el sistema de incidentes.
- Después de que el incidente es totalmente solucionado, es marcado como resuelto en el sistema de seguimiento de incidentes.
El problema puede no ser totalmente corregido, aun cuando pueda estar marcado como resuelto. El problema puede deberse al diseño, un incidente conocido, o tener una solución parcial adecuada.
Véase también
| Control de autoridades |
|
|---|
Datos: Q1480561