NexTool Solutions

La gestión de problemas es lo que separa una operación que apaga el mismo incendio cada semana de una que lo elimina de raíz. Dando soporte a entornos GLPI de clientes, el patrón que más vemos no es la falta de proceso, es el problema abierto, sorteado con un rodeo y marcado como Resuelto el mismo día - cerrando el ciclo antes de que la causa raíz quede documentada. Esta guía muestra dónde vive cada dato del problema en GLPI, cómo clasificar sin inventar un campo que no existe y las trampas que hacen que una investigación se pierda.

Incidente vs problema: la diferencia está en el dato, no solo en el discurso

La confusión clásica del ITSM es creer que "el incidente se convierte en problema". En GLPI ni siquiera comparten tabla: el incidente vive en glpi_tickets, el problema en glpi_problems, cada uno con su propia máquina de estados. Son objetos distintos con objetivos opuestos:

• Incidente: restaurar el servicio lo más rápido posible. Es curativo y tiene un SLA de resolución.
• Problema: encontrar y eliminar la causa raíz para que el incidente no vuelva. Es preventivo y va a otro ritmo.

Ejemplo de campo: el servidor de correo se cae todos los lunes. Cada caída es un incidente resuelto reiniciando el servicio. La investigación que descubre que el backup semanal agota la memoria y tumba el servicio es el problema. Cerrar los incidentes sin abrir el problema garantiza que el lunes siguiente traiga el mismo ticket.

La sección Análisis: dónde vive realmente la causa raíz

Lo que diferencia el formulario del problema del de un ticket común es la sección Análisis, que escribe en tres columnas de texto dedicadas de glpi_problems (expuestas como opciones de búsqueda 60, 61 y 62):

• impactcontent - Impactos: lo que el problema afecta mientras no se resuelve.
• causecontent - Causas: aquí vive la causa raíz. Es el campo más importante de todo el proceso.
• symptomcontent - Síntomas: cómo se manifiesta el problema para quien abre un incidente.

La trampa de campo más común que encontramos: la sección Análisis viene plegada en el formulario. El técnico rellena el título y la descripción, registra el rodeo en la línea de tiempo y nunca abre la sección - así que causecontent queda vacío. El resultado: seis meses después, nadie sabe por qué se abrió ese problema ni qué se descubrió. Una causa raíz que nunca llega a causecontent no se convierte en conocimiento, se convierte en rumor.

Incidente, problema o cambio: matriz de decisión

Antes de abrir cualquier registro, el equipo necesita saber qué está abriendo. Esta es la matriz que usamos en el triaje:

Fíjate en que problema y cambio no compiten: el flujo maduro es problema (descubre la causa) - cambio (implementa la corrección) - base de conocimiento (documenta), todo encadenado.

Vinculando los incidentes: la pestaña Tickets y el tipo de vínculo

Lo que da cuerpo a un problema son los incidentes ligados a él. En el formulario del problema, la pestaña Tickets asocia los tickets relacionados, escribiendo en la tabla glpi_problems_tickets. El detalle que casi todos ignoran: el vínculo tiene tipo. Vincular como "Vinculado a" es diferente de vincular como "Duplicado", y eso cambia la lectura de los informes de recurrencia. Estandariza el tipo de vínculo en el equipo, si no el conteo de incidentes por problema deja de tener sentido - fue uno de los primeros ajustes que hicimos en entornos que heredamos sin gobernanza.

El ciclo de vida y la trampa del "Resuelto" demasiado pronto

El problema tiene su propia máquina de estados en la columna status de glpi_problems, y no es igual a la del cambio. Los estados que el problema realmente usa son:

1. Nuevo (1) - registrado, aún sin investigar.
2. Aceptado (7) - triado y asumido por el equipo.
3. En curso / asignado (2) y planificado (3) - investigación en marcha.
4. En espera (4) - esperando a un tercero, proveedor o ventana.
5. En observación (8) - rodeo aplicado, monitorizando si la causa se eliminó de verdad.
6. Resuelto (5) y Cerrado (6) - causa eliminada y ciclo cerrado.

Aquí está el error común que más caro sale: aplicar el rodeo y marcar el problema como Resuelto el mismo día. Resuelto significa "la causa raíz se acabó", pero un rodeo no elimina ninguna causa - solo esconde el síntoma. En soporte pasamos a usar el estado En observación (8) justo para esto: el rodeo está en pie, el problema sigue vivo en el panel, y solo lo movemos a Resuelto después de que la corrección definitiva entre y pase un periodo sin reincidencia. Cerrar demasiado pronto es como cantar victoria con el incendio todavía humeando tras la pared.

Rodeo, solución definitiva y el puente hacia el cambio

Un problema lleva dos desenlaces que no pueden confundirse:

• Rodeo (workaround): restaura el servicio sin tocar la causa. Documéntalo en la línea de tiempo o como tarea del problema (glpi_problemtasks) para uso inmediato de la primera línea.
• Solución definitiva: elimina la causa raíz. Se registra en la pestaña Solución, escribiendo en glpi_itilsolutions (con itemtype = 'Problem'), y a menudo exige un cambio para implementarse.

Cuando la corrección toca infraestructura, abre el cambio directo desde el problema: el vínculo se escribe en glpi_changes_problems y mantiene la trazabilidad causa raíz - acción correctiva. Es esa línea la que luego permite demostrar que el problema se resolvió de verdad y no solo se cerró.

Plantilla de notificación de cierre de problema

En Configurar > Notificaciones, la plantilla del evento de problema usa las etiquetas de GLPI. Un cuerpo de cierre que obligue a registrar la causa raíz reduce los problemas cerrados sin lección aprendida:

Asunto: [Problema ##problem.id##] Cerrado - ##problem.title##

Hola,

El problema siguiente se ha cerrado.

Título:      ##problem.title##
Categoría:   ##problem.category##
Estado:      ##problem.status##
Incidentes:  ##problem.numberoftickets##

Síntomas:
##problem.symptoms##

Causa raíz:
##problem.causes##

Detalles: ##problem.url##

Las etiquetas ##problem.causes## y ##problem.symptoms## tiran directo de causecontent y symptomcontent. Si la notificación de cierre llega con esos bloques vacíos, es señal clara de que el problema se cerró sin causa raíz documentada - y el propio correo se convierte en el auditor del proceso.

Diagnóstico: problemas con incidentes de sobra y causa de menos

En soporte ejecutamos periódicamente un SELECT que cruza lo que más importa: problemas aún abiertos con muchos incidentes vinculados pero sin causa raíz rellenada. Es la cola de retrabajo inminente:

SELECT p.id,
       p.name AS problema,
       p.status,
       COUNT(pt.tickets_id) AS incidentes,
       IF(p.causecontent = '' OR p.causecontent IS NULL,
          'SIN CAUSA RAIZ', 'ok') AS causa
FROM glpi_problems p
LEFT JOIN glpi_problems_tickets pt ON pt.problems_id = p.id
WHERE p.is_deleted = 0
  AND p.status NOT IN (5, 6)          -- excluye Resuelto y Cerrado
GROUP BY p.id
HAVING causa = 'SIN CAUSA RAIZ'
    OR incidentes >= 3
ORDER BY incidentes DESC;

Cada fila con SIN CAUSA RAIZ y varios incidentes es un problema que consume esfuerzo de rodeo sin avanzar hacia la solución. Convertir esta consulta en un panel semanal cambia la conversación de la reunión de operación: en lugar de "cuántos tickets cerramos", pasa a ser "qué causas eliminamos".

Buenas prácticas de soporte

• No esperes decenas de incidentes: 3 ocurrencias con el mismo síntoma ya justifican un problema.
• Rellena causecontent antes de cerrar, aunque la causa parezca obvia; es lo que se convierte en conocimiento.
• Usa En observación mientras el rodeo funciona; marca Resuelto solo cuando la causa esté eliminada.
• Estandariza el tipo de vínculo de los incidentes para que el conteo de recurrencia signifique algo.
• Vincula el problema al cambio (glpi_changes_problems) siempre que la corrección toque infraestructura.
• Revisa los problemas abiertos cada semana; un problema olvidado es un incidente garantizado en el futuro.

Si la operación necesita que los problemas recurrentes se detecten solos - en lugar de depender de que alguien note el patrón - el módulo Problem Flow identifica incidentes repetidos por categoría y frecuencia y abre el problema con los tickets ya vinculados. El soporte NexTool configura ese flujo sobre el GLPI que ya usas, desde el disparador de detección hasta el panel de causas eliminadas.

Revisado por el equipo de NexTool Solutions.