GLPI no tiene por qué quedarse encerrado en TI. Con entidades, categorías y reglas de negocio bien diseñadas, la misma instancia atiende a RR. HH., Jurídico, Facilities y Finanzas como un Centro de Servicios Compartidos (CSC). Lo que separa un CSC que funciona de un montón de tickets es la decisión de arquitectura tomada antes del primer formulario.
Decisión de arquitectura: una entidad por área o una categoría por área?
Esta es la primera elección y la más cara de revertir. En GLPI, una entidad es una frontera multiinquilino: aísla datos, SLAs, perfiles y catálogo. Una categoría ITIL es solo una etiqueta de clasificación dentro de una entidad. Usar una entidad por área da aislamiento fuerte, pero exige administración; usar categorías mantiene todo simple, pero depende de grupos y reglas para enrutar y proteger los datos.
| Criterio | Una entidad por área | Una categoría por área |
|---|---|---|
| Aislamiento de datos | Fuerte (un perfil no recursivo no ve las áreas hermanas) | Débil (depende de grupo y regla) |
| SLA independiente por área | Nativo | Manual, vía regla + SLA por categoría |
| Informe consolidado | Exige perfil recursivo o entidad raíz | Trivial (una sola entidad) |
| Esfuerzo de administración | Alto (perfiles, permisos, cron) | Bajo |
| Indicado para | RR. HH. y Jurídico (datos confidenciales) | Facilities y Finanzas (baja confidencialidad) |
Regla práctica: use entidades cuando haya un requisito real de confidencialidad (RR. HH. y Jurídico suelen exigirlo) o SLAs y perfiles muy distintos. Use categorías cuando las áreas comparten el mismo grupo de agentes y la confidencialidad es baja. Es común un diseño híbrido: entidad separada para RR. HH. y Jurídico, y Facilities y Finanzas como categorías dentro de la entidad corporativa.
Paso a paso para el primer departamento fuera de TI
- Modele la frontera: decida entidad o categoría con la matriz anterior antes de crear nada.
- Cree la entidad (Administración > Entidades) o el árbol de categorías (Configuración > Categorías de tickets), marcando siempre la visibilidad recursiva cuando la estructura sea compartida.
- Cree un grupo de agentes por área (Administración > Grupos) y marque "Puede asignarse a tickets".
- Defina el SLA/OLA del área (Configuración > Niveles de servicio) con tiempos de respuesta y de resolución realistas.
- Configure reglas de negocio (Reglas > Reglas de negocio para tickets) para asignar automáticamente grupo, categoría y SLA según el origen del ticket.
- Monte el catálogo: formularios nativos (GLPI 11) o el plugin Formcreator (GLPI 10) con los campos del área.
- Ajuste perfiles y permisos: el agente de RR. HH. no debe ver la cola de TI, y viceversa.
- Active el cron externo (siguiente sección) antes de anunciar el servicio.
Diagnóstico: quién usa realmente el centro
Antes y después de expandir, mida. La consulta siguiente lee directamente la base de datos y muestra volumen y tiempo hasta la solución por entidad y categoría en los últimos 30 días. Ejecútela en una réplica o fuera del horario pico.
-- Volumen y tiempo hasta la solución por entidad/categoría (30 días)
SELECT e.completename AS entidad,
IFNULL(c.completename, '(sin categoria)') AS categoria,
COUNT(t.id) AS tickets,
ROUND(AVG(TIMESTAMPDIFF(HOUR, t.date, t.solvedate)), 1) AS horas_hasta_solucion
FROM glpi_tickets t
JOIN glpi_entities e ON e.id = t.entities_id
LEFT JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.date >= NOW() - INTERVAL 30 DAY
AND t.is_deleted = 0
GROUP BY e.completename, c.completename
ORDER BY tickets DESC;Si aparecen muchas filas con "(sin categoria)", es señal de catálogo incompleto o de agentes abriendo tickets sin clasificar - el primer síntoma de un CSC que va a perder trazabilidad.
Cron externo: por qué el SLA de RR. HH. no se dispara a tiempo
En el soporte diario de entornos multiárea, el patrón que falla de forma más silenciosa es la entidad sin cron externo. TI, con tráfico alto, dispara el cron interno en cada carga de página y nadie nota el problema. La entidad de Jurídico, con pocas visitas al día, acumula escalados de SLA que solo se ejecutan cuando alguien abre la interfaz. El ticket que nos llega suele ser "los correos de vencimiento de Jurídico llegan todos en lote hacia las 9 h" - justo cuando el primer usuario inicia sesión y el cron interno por fin procesa la cola represada. La corrección es siempre mover la ejecución al cron del sistema operativo (MODE_EXTERNAL) y reducir la dependencia del disparador por carga de página.
# /etc/cron.d/glpi - cron externo de GLPI (se ejecuta como el usuario del servidor web)
# Dispara notificaciones, escalado de SLA y cierre automático.
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php &>/dev/nullDespués de programarlo, entre en Configuración > Acciones automáticas y confirme que las tareas críticas (envío de notificaciones, escalado de SLA y cierre de tickets) se ejecutan en modo CLI y no "GLPI" (ejecución al cargar la página). En un entorno con varias áreas, dejarlas en modo interno es la causa número 1 de "el plazo venció pero nadie fue avisado".
El error común: categoría no recursiva y visibilidad rota
El error que más aparece en soporte es sutil: una categoría creada en la entidad raíz sin marcar la visibilidad para las entidades hijas simplemente no aparece en el formulario del departamento. Sin la categoría correcta, el agente abre el ticket como un "Incidente" genérico o escribe la clasificación en el título - y el informe del área nace defectuoso. Lo mismo ocurre con los perfiles: un agente de RR. HH. con alcance de perfil no recursivo solo ve la entidad exacta donde está, no las subentidades. Al crear categorías en la raíz, marque "Hijo" (visible en las subentidades), con entities_id = 0 e is_recursive = 1; al crear perfiles de área, decida conscientemente si el alcance es recursivo.
Gobernanza: evite la explosión de categorías
- Limite el árbol a 2 niveles por área; más que eso y nadie clasifica bien.
- Nombre las categorías por la acción del solicitante ("Solicitar reembolso"), no por la jerga interna.
- Revise trimestralmente las filas "(sin categoria)" del diagnóstico.
- Un responsable por área, a cargo del catálogo y de los SLAs.
- No replique la misma categoría en varias entidades a mano; hágala recursiva desde la raíz.
Empiece por TI, que ya está acostumbrada al service desk, y expanda de forma gradual. Cada nueva área entra con frontera definida, grupo de atención, SLA y cron externo validado - no con un catálogo improvisado.
Necesita diseñar la frontera entre entidades y categorías antes de escalar su CSC? NexTool implementa y da soporte a GLPI multiárea para clientes B2B, desde el modelado de entidades hasta el cron y las reglas de enrutamiento.
Revisado por el equipo de NexTool Solutions.
