Ir al contenido

Sistema de seguimiento de incidentes

De Wikipedia, la enciclopedia libre

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

[editar]

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

[editar]

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

[editar]

Un escenario de ejemplo es presentado para demostrar cómo un sistema típico de seguimiento de incidencias puede trabajar:

  1. 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.
  2. 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.
  3. El técnico crea el incidente en el sistema, ingresa toda la información relevante tal como fue proporcionada por el cliente.
  4. 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.
  5. 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.

Ámbitos de aplicación

[editar]

Los sistemas de manipulación ( ITS) se utilizan en diversas aplicaciones.[1][2]​ Algunos ejemplos son:

  • Puntos de contacto en el sistema administrativo
  • Proyectos técnicos
  • Una solución de software de servicio de asistencia que se utiliza para recoger, procesar, seguir y gestionar las reclamaciones.[3][4]

En tecnología informática, ITSse utiliza para configurar, ampliar, solucionar problemas y probarel sistema del proyecto. Las razones para utilizar ITS incluyen:

  • mejorar la calidad del trabajo realizado
  • hacer el proceso más transparente
  • conservación del historial
  • sacar conclusiones de la historia para el futuro y optimizar el proceso

El sistema de tickets también es, en parte, un componente del software de gestión de servicios o del software para planificación de recursos de una empresa.[5]​ Mientras tanto, el sistema de tickets también puede utilizarse, por ejemplo, en el ámbito de la gestión de proyectos, para delegar tareas de proyectos y realizar un seguimiento de su progreso. Para poder asignar empleados a solicitudes individuales, a menudo también se utilizan funciones como la planificación de recursos, así como un tablón de horarios.

Véase también

[editar]

Referințe

[editar]
  1. «Carrier Variety Used in Immobilization of His6-OPH Extends Its Application Areas». www.researchgate.net. Consultado el 16 de octubre de 2023. 
  2. «AI-Based Modeling: Techniques, Applications and Research Issues Towards Automation, Intelligent and Smart Systems». link.springer.com. Consultado el 16 de octubre de 2023. 
  3. «10 Complaint Management Systems to Resolve Customer Grievances». geekflare.com. Consultado el 16 de octubre de 2023. 
  4. «Common Features of a Ticketing System You Need to Know». www.helponclick.com. Consultado el 16 de octubre de 2023. 
  5. «The necessity of ticketing systems in manufacturing». www.adtance.com. Consultado el 16 de octubre de 2023.