Sistema de seguimiento de problemas

Paquete de software informático que administra y mantiene listas de problemas.

Un sistema de seguimiento de problemas (también ITS , sistema de tickets de problemas , ticket de soporte , gestión de solicitudes o sistema de tickets de incidentes ) es un paquete de software informático que administra y mantiene listas de problemas . [1] Los sistemas de seguimiento de problemas se utilizan generalmente en entornos colaborativos , especialmente en colaboraciones grandes o distribuidas, pero también pueden ser empleados por personas como parte de un régimen de gestión del tiempo o de productividad personal . Estos sistemas a menudo abarcan la asignación de recursos , la contabilidad del tiempo, la gestión de prioridades y el flujo de trabajo de supervisión, además de implementar un registro de problemas centralizado.

Fondo

En el ámbito institucional, los sistemas de seguimiento de problemas se utilizan habitualmente en el centro de atención al cliente de una organización para crear, actualizar y resolver los problemas notificados por los clientes o incluso los notificados por otros empleados de esa organización. Un ticket de soporte debe incluir información vital sobre la cuenta involucrada y el problema detectado. [2] Un sistema de seguimiento de problemas a menudo también contiene una base de conocimiento que contiene información sobre cada cliente, resoluciones a problemas comunes y otros datos similares.

Un sistema de seguimiento de problemas es similar a un " bugtracker " y, a menudo, una empresa de software vende ambos, y algunos bugtrackers pueden usarse como un sistema de seguimiento de problemas y viceversa. El uso constante de un sistema de seguimiento de problemas o errores se considera uno de los "sellos distintivos de un buen equipo de software". [3] Un elemento de ticket, dentro de un sistema de seguimiento de problemas, es un informe en ejecución sobre un problema en particular, su estado y otros datos relevantes. Se crean comúnmente en un entorno de soporte técnico o centro de llamadas y casi siempre tienen un número de referencia único, también conocido como número de caso , problema o registro de llamadas , que se utiliza para permitir que el usuario o el personal de ayuda localicen, agreguen o comuniquen rápidamente el estado del problema 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 ranuras pendientes para un ingeniero adecuado, determinando así el miembro del personal que se ocuparía de la consulta y la prioridad de la solicitud.

La base conceptual compartida entre los sistemas de seguimiento de problemas y los rastreadores de errores es que un problema válido debe ser susceptible de una resolución decisiva (como "completado", "arreglado" o un consenso grupal de que el problema no vale la pena resolver, como "no es un problema" o "no se solucionará"); que cada problema es único (los informes de problemas duplicados en la mayoría de los casos se fusionan rápidamente en un solo problema o ticket activo); y, más allá de la etapa de selección, que existe exactamente una persona asignada con la responsabilidad formal de hacer avanzar el problema (esta batuta formal a menudo rebotará muchas veces a medida que el problema evoluciona). En los rastreadores de errores, los problemas generalmente están relacionados con la calidad o las características con respecto a una base de código (que es inherentemente un entorno de gestión de proyectos ), mientras que en los sistemas de seguimiento de problemas generalizados, los tickets a menudo están relacionados con el servicio o se basan en la relación, con vínculos más estrechos con las preocupaciones de gestión de relaciones con el cliente (CRM). [4]

Asuntos

Los problemas pueden tener varios aspectos. Cada problema del sistema puede tener un valor de urgencia asignado, en función de la importancia general de ese problema. Los problemas de urgencia baja o nula 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 presentación, [5] descripciones detalladas del problema que se experimenta, soluciones intentadas o alternativas y otra información relevante. Cada problema mantiene un historial de cada cambio.

Funciones

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

  • Introducción de disfunciones, errores y solicitudes (por ejemplo, de forma manual o por correo electrónico)
  • Distribución y asignación de cuestiones a los responsables
  • Seguimiento de la manipulación, tiempos empleados y calidad del trabajo
  • Garantizar la observación de los procesos internos mediante un control forzado con ayuda de flujos de trabajo
  • Análisis estadístico del número de tickets
  • Generación automática de tickets por sistemas de alarma, p. ej. monitorización de red
  • Cumplimiento de acuerdos de servicios externos (Service Level Agreement, SLA )
  • Recopilación sistemática de preguntas y respuestas para preguntas frecuentes
  • Asignación de una prioridad a cada problema en función de la importancia general de ese problema, el cliente, la fecha de presentación y el SLA.
  • Contiene descripciones detalladas del problema experimentado, soluciones intentadas o alternativas y otra información relevante.
  • Mantenimiento de un historial de cada cambio

Flujo de trabajo

Se presenta un escenario de ejemplo para demostrar cómo funcionaría un sistema común de seguimiento de problemas:

  1. Un técnico de atención al cliente recibe una llamada telefónica , un correo electrónico u otra comunicación de un cliente sobre un problema. Algunas aplicaciones proporcionan un sistema de mensajería integrado y un informe automático de errores a partir de bloques de gestión de excepciones .
  2. El técnico verifica que el problema sea real y no solo percibido. El técnico también se asegurará de obtener suficiente información sobre el problema del cliente. Esta información generalmente incluye el entorno del cliente, cuándo y cómo ocurre el problema y todas las demás circunstancias relevantes.
  3. El técnico crea el problema en el sistema, ingresando todos los datos relevantes proporcionados por el cliente.
  4. A medida que se trabaja en ese problema, el técnico actualiza el sistema con nuevos datos. Cualquier intento de solucionar el problema debe quedar registrado en el sistema de problemas. Lo más probable es que el estado del ticket cambie de abierto a pendiente.
  5. Una vez que el problema se haya solucionado por completo, se marca como resuelto en el sistema de seguimiento de problemas.

Si el problema no se resuelve por completo, el ticket se volverá a abrir una vez que el técnico reciba nueva información del cliente. Un proceso de automatización de Run Book que implementa las mejores prácticas para estos flujos de trabajo y aumenta la eficacia del personal de TI se está volviendo muy común.

Uso en diferentes sectores

Gobierno

Algunos servicios gubernamentales utilizan un sistema de seguimiento de problemas para llevar un registro de los mismos y mostrarlos al público. Los sistemas de seguimiento de problemas pueden mostrar todas las tareas que el gobierno aún debe realizar (en una cola de espera), las tareas finalizadas, las tareas en curso, la secuencia de pedidos, etc. [ cita requerida ] Las tareas finalizadas también se pueden prever con el informe, mostrando qué se ha hecho exactamente sobre el problema. [ cita requerida ]

Los sistemas de seguimiento de cuestiones se utilizan, por ejemplo, para rastrear qué proyectos de ley están siendo sometidos a votación y sus resultados. [6]

Los problemas de transporte e infraestructura (por ejemplo, obstrucciones en las carreteras, quejas, etc.) también pueden presentarse mediante sistemas de seguimiento de problemas. [7] Los servicios gubernamentales pertinentes pueden luego abordarlos.

Véase también

Referencias

  1. ^ Bertram, Dane. La naturaleza social del seguimiento de problemas en la ingeniería de software Archivado el 8 de noviembre de 2016 en Wayback Machine . Tesis doctoral. Universidad de Calgary, 2009.
  2. ^ Murphy, Ian (11 de noviembre de 2021). "Explicación del sistema de seguimiento de errores o tickets".
  3. ^ Joel Spolsky (8 de noviembre de 2000). "Painless Bug Tracking" (Seguimiento de errores sin dolor) . Consultado el 29 de octubre de 2010 .
  4. ^ Murphy, Ian (11 de noviembre de 2021). "Explicación de la gestión de relaciones con el cliente mediante CRM".
  5. ^ Método y aparato para realizar operaciones remotas en un entorno de seguimiento de problemas, 2013-08-29 , consultado el 2019-04-05
  6. ^ Por ejemplo: "Ayuda para el seguimiento del Senado: el Senado de Florida". flsenate.gov . Consultado el 17 de enero de 2021 . "Resultados de búsqueda legislativa". congress.gov . Consultado el 17 de enero de 2021 . "GovTrack.us: Seguimiento del Congreso de Estados Unidos". govtrack.us . Consultado el 17 de enero de 2021 .
  7. ^ Realizar un seguimiento del progreso de una falla o un problema de carretera informado
:Esta categoría tiene un nombre engañoso, ya que enumera sistemas de seguimiento de errores y problemas.:Software de soporte técnico y seguimiento de incidencias en DMOZ:Esta categoría enumera los sistemas de seguimiento de problemas desarrollados en Java .
Obtenido de "https://es.wikipedia.org/w/index.php?title=Sistema_de_seguimiento_de_problemas&oldid=1251980104"