NexTool Solutions

Un cambio bien gestionado en GLPI no es el que tiene más campos rellenados, es el que puedes revertir a las 2 de la madrugada cuando falla. Esta guía recorre el ciclo de vida completo de los cambios en GLPI: de qué sección y columna sale cada dato, cómo modelar tipos de cambio que el GLPI nativo no tiene, y las trampas que hemos visto tumbar ventanas de mantenimiento en los entornos que damos soporte a clientes.

El modelo de datos detrás del cambio

Todo cambio vive en la tabla glpi_changes. Además de los campos obvios (nombre, contenido, urgencia, impacto, prioridad), lo que distingue un cambio de un ticket común son las columnas de texto que GLPI expone en la sección de análisis y planes del formulario:

• impactcontent - análisis de impacto: qué se rompe si sale mal.
• controlistcontent - lista de control: puntos de verificación.
• rolloutplancontent - plan de implementación (el núcleo lo rotula "Deployment plan"): el paso a paso del despliegue.
• backoutplancontent - plan de retroceso/rollback (el núcleo lo rotula "Backup plan"): cómo deshacerlo.
• checklistcontent - lista de comprobación de validación tras la implementación.

Saber que esta información son columnas separadas, y no texto suelto en la descripción, es lo que permite auditar la gobernanza directamente en la base de datos, como mostramos más abajo.

"Tipo de cambio" en GLPI: el campo que no existe

El error más común de quien viene de herramientas como ServiceNow es buscar un selector "Tipo: Normal / Emergencia / Estándar". No existe en el GLPI nativo. El cambio tiene categoría (itilcategories_id), urgencia, impacto y prioridad, pero no un campo de tipo ITIL. Modelas la clasificación con categorías ITIL dedicadas, lo que además alimenta informes y reglas de negocio.

El ciclo de vida, estado por estado

GLPI mueve el cambio por su propia máquina de estados, más rica que la del ticket. El estado actual está en la columna status de glpi_changes:

1. Nuevo (1) - registrado en Asistencia > Cambios, con descripción, justificación, impacto y riesgo.
2. Evaluación (4) - análisis de impacto y riesgo; relleno de las secciones de análisis y planes.
3. Aprobación (11) - ronda de validación con los aprobadores.
4. Aceptado (12), Prueba (13), Calificación (14) - planificación y ejecución de las tareas (glpi_changetasks), cada una registrada en la línea de tiempo.
5. Resuelto (5) - revisión tras la implementación; confirma el éxito y registra lecciones aprendidas.
6. Cerrado (6) - documentación final y cierre.

Cada tarea de cambio lleva actiontime (tiempo real) y state (por hacer/hecho), lo que permite comparar el esfuerzo planificado frente al gastado, dato que usamos para calibrar las estimaciones de las próximas ventanas.

Aprobación: validación nativa frente a multinivel

La aprobación nativa se graba en glpi_changevalidations (estado 2 = en espera, 3 = aprobado, 4 = rechazado). El detalle que pilla a casi todos: la validación de GLPI es informativa, no es una barrera. Nada impide mover el cambio de Aprobación a Prueba con la validación aún pendiente; GLPI no bloquea la transición. Si tu gobernanza exige que nadie implemente sin una aprobación registrada, la validación nativa por sí sola no lo resuelve. Ahí entra Approval Flow, con aprobación multinivel y rutas condicionales que realmente frenan el avance.

Plantilla de notificación de la solicitud de aprobación

En Configurar > Notificaciones, la plantilla del evento de validación de cambio usa las etiquetas de GLPI. Un cuerpo escueto reduce las idas y venidas:

Asunto: [Cambio ##change.id##] Aprobación solicitada - ##change.title##

Hola,

Un cambio espera tu aprobación.

Título:     ##change.title##
Categoría:  ##change.category##
Urgencia:   ##change.urgency##
Impacto:    ##change.impact##
Prioridad:  ##change.priority##

Descripción:
##change.content##

Aprobar o rechazar en:
##change.url##

Mantener urgencia, impacto y prioridad en el cuerpo evita que el aprobador tenga que abrir el cambio solo para decidir. Eso reduce el tiempo en estado Aprobación, que es donde la mayoría de las ventanas se retrasan.

Diagnóstico: cambios sin plan de rollback

En el soporte, el campo que más encontramos vacío es justo el más crítico: backoutplancontent. La sección de planes viene plegada en la interfaz, así que el técnico rellena la descripción y las tareas pero nunca el plan de retroceso, y el fallo solo aparece cuando el cambio sale mal y nadie sabe revertirlo. Ejecutamos este SELECT cada viernes, antes de la ventana del fin de semana:

SELECT c.id,
       c.name AS cambio,
       c.status,
       IF(c.backoutplancontent = '' OR c.backoutplancontent IS NULL,
          'SIN ROLLBACK', 'ok') AS plan_retroceso
FROM glpi_changes c
WHERE c.is_deleted = 0
  AND c.status NOT IN (5, 6)          -- excluye Resuelto y Cerrado
ORDER BY c.date DESC;

Cualquier fila con SIN ROLLBACK es un cambio que no debería entrar en ventana. Lo convertimos en regla de negocio: sin plan de retroceso rellenado, la aprobación no sale.

Buenas prácticas de soporte

• Documenta backoutplancontent antes de pedir la aprobación, no después de implementar.
• Vincula el cambio a su problema de origen (glpi_changes_problems) para mantener la trazabilidad de causa raíz a acción correctiva.
• Crea plantillas de cambio para los recurrentes (estándar) y dispensa la validación en ellos.
• Programa fuera de las horas pico y registra el actiontime real para calibrar estimaciones.
• Cierra el ciclo con la revisión tras la implementación, incluso cuando todo salió bien; es lo que se convierte en base de conocimiento.

Si la operación necesita una barrera de aprobación que de verdad frene el avance y una gobernanza de cambios auditable, el soporte NexTool configura ese flujo con el módulo Approval Flow sobre el GLPI que ya usas.

Revisado por el equipo de NexTool Solutions.