Poner RRHH, Jurídico y Facilities en el mismo GLPI que TI no es pulsar un botón: es una decisión de arquitectura. Enterprise Service Management (ESM) reutiliza el motor de ITSM que ya operas, pero lo que separa un proyecto que escala de uno que se vuelve un caos es cómo se aísla cada área: por entidad, por categoría o por grupo. Equivocar esa elección cuesta retrabajo y, en el caso de RRHH y Jurídico, expone datos confidenciales.
La primera decisión: ¿entidad, categoría ITIL o grupo?
Antes de crear un formulario o un SLA, define la unidad de aislamiento. GLPI ofrece tres caminos para modelar un área fuera de TI, y cada uno tiene un compromiso real entre confidencialidad y esfuerzo de mantenimiento.
| Enfoque | Aislamiento de datos | SLA/calendario propio | Esfuerzo de mantenimiento | Cuándo usarlo |
|---|---|---|---|---|
| Entidad dedicada | Total (tickets, adjuntos e informes separados) | Sí, por entidad | Alto (perfiles, reglas y categorías por entidad) | RRHH y Jurídico, donde hay confidencialidad |
| Categoría ITIL + grupo | Parcial (quien tiene la entidad lo ve todo) | Compartido; el SLA puede variar por categoría | Bajo | Facilities y áreas sin confidencialidad fuerte |
| Subentidad bajo TI | Alto, heredando la gobernanza de la matriz | Sí | Medio | Área que reporta a la misma dirección |
La regla práctica que aplicamos: si un ticket del área puede contener datos que TI no debería leer - nómina, un contrato, un juicio laboral - la respuesta es una entidad dedicada. Para el resto, categoría más grupo lo resuelve con una fracción del esfuerzo.
Aislamiento de datos: el punto ciego de RRHH y Jurídico
En la sustentación de parques GLPI de clientes, el error que más vemos en un proyecto de ESM no es de formulario, es de visibilidad. Alguien crea la entidad "Jurídico", cuida las categorías, pero concede el perfil a los analistas de TI de forma recursiva desde la raíz - y listo: TI pasa a ver todos los tickets de Jurídico, adjuntos incluidos. Peor aún: en GLPI el adjunto hereda la entidad del ticket (el vínculo Document_Item exige que documento e ítem estén en la misma entidad), así que un contrato adjunto a un ticket en una entidad compartida queda visible para todos los que tienen acceso a esa entidad. Por eso, para Jurídico, aislamos por entidad, nunca por categoría.
Antes de liberar cualquier área sensible, ejecutamos esta auditoría para encontrar a quién tiene un acceso demasiado amplio:
-- Auditoria de visibilidad: quien ve tickets de TODAS las areas.
-- Ejecutar en la base de datos de GLPI. El acceso recursivo desde la raiz (entities_id = 0,
-- is_recursive = 1) permite al usuario ver los tickets de todas las entidades hijas.
SELECT u.name AS usuario,
p.name AS perfil,
e.completename AS entidad_base,
pu.is_recursive
FROM glpi_profiles_users pu
JOIN glpi_users u ON u.id = pu.users_id
JOIN glpi_profiles p ON p.id = pu.profiles_id
JOIN glpi_entities e ON e.id = pu.entities_id
WHERE pu.is_recursive = 1
AND pu.entities_id = 0
ORDER BY p.name, u.name;Cada fila es un usuario que lo ve todo. Para las áreas confidenciales, el vínculo perfil-usuario debe apuntar a la entidad específica con is_recursive desactivado. Y cuidado con un detalle de GLPI: la entidad de id 0 es la raíz, un valor válido - no la trates como "vacía".
SLA y calendario por área: el error del 8x5 en Facilities
El SLA en GLPI está atado a un calendario (horario laboral), y el calendario se define por entidad. El error común es crear Facilities heredando el calendario 8x5 de TI y prometer un SLA de mantenimiento de instalaciones que, en la práctica, no corre de noche ni el fin de semana - justo cuando un aire acondicionado de datacenter o un fallo eléctrico exigen respuesta. Antes de publicar el SLA de un área, verifica:
- Calendario: Facilities crítico suele exigir 24x7; RRHH y Jurídico funcionan bien en 8x5.
- Festivos: el calendario de GLPI acepta festivos y cierres - poblarlo, o el SLA cuenta tiempo fuera del horario.
- Escalado: define el grupo técnico del área antes de activar el SLA, o el ticket vence sin destinatario.
Onboarding multiárea: el flujo que paga el ESM
El caso que justifica la inversión más rápido es el onboarding. Un formulario "Nuevo empleado" (nativo en GLPI 11, o FormCreator en GLPI 10) dispara tickets coordinados: TI crea correo y accesos, Facilities prepara el puesto, RRHH gestiona la documentación. Cada ticket nace en la entidad correcta, con el grupo correcto, y notifica al responsable. Un fragmento de una plantilla de notificación que usamos para el aviso de apertura del área:
Asunto: [##ticket.entity##] Onboarding: ##ticket.title## (##ticket.id##)
Se ha abierto una nueva solicitud y espera a tu area.
Ticket......: ##ticket.title##
Entidad.....: ##ticket.entity##
Categoria...: ##ticket.category##
Solicitante.: ##ticket.authors##
Grupo.......: ##ticket.assigntogroups##
Plazo (SLA).: ##ticket.time_to_resolve##
Abrir.......: ##ticket.url##Los ##...## son tags nativas de GLPI, sustituidas en el momento del envío. El error común aquí es crear las categorías del área y olvidar marcarlas como visibles en el helpdesk (el campo is_helpdeskvisible): el empleado abre el portal de autoservicio y no encuentra la categoría de RRHH, porque nació visible solo para la interfaz técnica.
Checklist de implantación
- Mapea los servicios del área (qué atiende) antes de tocar GLPI.
- Decide la unidad de aislamiento con la tabla de arriba (entidad vs. categoría vs. grupo).
- Crea la entidad por la interfaz - nunca vía SQL (GLPI arma el árbol con getSonsOf y un INSERT directo queda invisible en la jerarquía).
- Configura el calendario y el SLA del área.
- Crea las categorías ITIL y marca la visibilidad en el helpdesk.
- Crea el grupo técnico y los perfiles, con el ámbito de entidad correcto (ejecuta la auditoría de recursividad).
- Monta el formulario (nativo en 11 o FormCreator en 10) y pruébalo con un ticket real en preproducción.
- Solo entonces libera a los usuarios y publica las métricas.
Qué medir (rangos honestos)
Con las áreas en el mismo GLPI, comparas lo que antes era incomparable: tiempo medio de respuesta, volumen por categoría y tasa de reapertura, lado a lado entre TI, RRHH y Facilities. No prometas un número mágico: reducir el "correo perdido" suele ser la ganancia más visible en el primer mes, porque toda solicitud se vuelve un ticket rastreable. La ganancia de tiempo en el onboarding depende de cuánto del flujo automatices - cuantas más tareas dispare el formulario solo, mayor el efecto.
En NexTool implantamos y sostenemos GLPI multiárea para clientes, desde el diseño de las entidades hasta el SLA y las reglas de enrutamiento. Si quieres llevar GLPI más allá de TI sin exponer datos de RRHH o Jurídico, nuestros servicios de soporte y sustentación cubren ese diseño de punta a punta.
Revisado por el equipo de NexTool Solutions.
