Una guía para elegir tecnología, procesos y soporte capaces de conectar la mesa de ayuda con activos, inventario, niveles de servicio y trazabilidad empresarial.
Elegir una plataforma ITSM con GLPI no consiste solamente en comparar pantallas para registrar tickets. La decisión afecta cómo IT recibe pedidos, prioriza incidentes, administra sus recursos, demuestra el cumplimiento de los SLA y conserva evidencia de cada intervención. En empresas medianas y grandes, esa continuidad entre personas, procesos y activos es bastante más importante que la cantidad de funciones que aparecen en una demo.
La evaluación debería comenzar por el modelo operativo: qué servicios presta IT, quién puede solicitarlos, qué equipos o aplicaciones soportan cada servicio, cómo se escala un incidente y qué información necesita la gerencia. Después corresponde validar si la herramienta puede sostener ese modelo con reglas, permisos, integraciones y reportes. Hacerlo al revés suele producir una mesa de ayuda prolija por fuera, pero llena de excepciones manuales por dentro.
Qué debería unificar una plataforma ITSM
Una solución empresarial debería permitir que el dato se mueva a lo largo de todo el ciclo de atención. Un usuario informa una falla; la mesa clasifica el incidente; las reglas determinan prioridad y equipo responsable; el técnico consulta el activo involucrado; el SLA controla los tiempos; y el cierre alimenta reportes o conocimiento reutilizable. Esa secuencia evita reconstruir contexto desde correos, planillas y chats.
GLPI reúne capacidades de help desk, gestión de activos e inventario dentro de una misma plataforma. También incorpora catálogo de servicios, reglas de negocio, niveles de servicio, base de conocimiento, perfiles y entidades. La pregunta útil no es si cada función existe, sino si puede configurarse para la estructura, los controles y el volumen reales de la organización.
8 criterios para evaluar una plataforma ITSM con GLPI
Cobertura de procesos, no sólo tickets
Relevá incidentes, solicitudes, problemas, cambios, aprobaciones y conocimiento. No todas las organizaciones necesitan madurez máxima desde el primer día, pero la plataforma debe permitir avanzar sin reemplazar el sistema cuando crezca la operación.
Pedí una demostración basada en procesos propios. Un incidente crítico, un alta de usuario y una solicitud de compra revelan mucho más que una recorrida genérica por el menú.
Experiencia de usuarios y técnicos
Evaluá portal de autoservicio, formularios, correo, catálogo, notificaciones, búsqueda y accesibilidad móvil. El formulario debe pedir la información necesaria sin trasladar al usuario la complejidad interna de IT.
Para los técnicos importan las colas de trabajo, acciones masivas, plantillas, tareas, seguimientos y una vista clara del historial. Cada clic innecesario se multiplica por miles de atenciones.
Activos e inventario con contexto
Una lista de notebooks no constituye gestión de activos. Verificá descubrimiento e inventario, normalización, relación con usuarios y ubicaciones, estados, componentes, software, licencias, contratos, garantías y ciclo de vida.
El punto decisivo es poder relacionar un ticket con el equipo o componente afectado. Así es posible detectar recurrencias, revisar antecedentes, analizar costos y tomar decisiones de renovación con datos.
SLA, OLA y automatización
Comprobá calendarios laborales, tiempos de respuesta y resolución, pausas justificadas, escalamiento y alertas preventivas. Los niveles de servicio deben variar según servicio, prioridad, cliente o contrato.
Las reglas de negocio deberían categorizar, asignar, definir prioridad y disparar notificaciones de manera consistente. Automatizar decisiones repetitivas reduce demoras; automatizar un proceso mal diseñado sólo acelera el desorden.
Integraciones y arquitectura
Inventariá los sistemas que deben intercambiar información: directorio corporativo, correo, monitoreo, seguridad, ERP, compras, recursos humanos, telefonía o colaboración. Revisá API, webhooks, conectores, autenticación y mecanismos de importación.
También evaluá topología, ambientes, alta disponibilidad, respaldo, recuperación, actualización y observabilidad de la propia plataforma. La integración no termina cuando “la API responde”: requiere manejo de errores, trazabilidad y responsables.
Gobierno, seguridad y múltiples entidades
Las empresas regionales suelen necesitar separar compañías, sedes, áreas o clientes sin perder una visión consolidada. Validá jerarquías, herencia de configuraciones, perfiles, permisos, segregación de funciones y alcance de los datos.
Incluí autenticación centralizada, registro de cambios, políticas de retención, protección de datos personales y evidencia para auditoría. Un administrador no debería recibir privilegios globales sólo porque gestiona una unidad.
Reportes y visibilidad operativa
Definí indicadores antes de elegir tableros: cumplimiento de SLA, backlog, antigüedad, recurrencia, carga por equipo, tasa de reapertura, satisfacción, disponibilidad de activos y calidad del inventario.
Los reportes deben permitir ir del indicador al caso que lo explica. Un promedio favorable puede esconder incidentes críticos vencidos; por eso hacen falta segmentación, historial y datos exportables.
Operación, costo total y soporte
Compará infraestructura, suscripciones, implementación, migración, integraciones, capacitación, actualizaciones y horas internas. El costo de entrada rara vez representa el costo total de propiedad.
En Argentina y América Latina, sumá disponibilidad horaria, idioma, conocimiento del entorno local y capacidad de escalar casos. El soporte debe cubrir la aplicación y también el modelo operativo configurado sobre ella.
Matriz de evaluación: cómo comparar opciones con evidencia
Una matriz ponderada evita que la decisión quede dominada por una función llamativa o por el menor precio inicial. Los pesos siguientes son un punto de partida: cada empresa debería ajustarlos según riesgos, regulación, dispersión geográfica y madurez.
| Criterio | Peso sugerido | Evidencia que debería solicitarse |
|---|---|---|
| Procesos ITSM y experiencia de atención | 20% | Demostración con incidentes, solicitudes, aprobaciones, catálogo y conocimiento. |
| Activos, inventario y trazabilidad | 20% | Descubrimiento real, normalización, relaciones, historial y asociación con tickets. |
| SLA y automatización | 15% | Reglas ejecutadas sobre casos propios, calendarios, alertas y escalamiento. |
| Integración y arquitectura | 15% | Prueba de API o conector, diseño de ambientes, respaldo y recuperación. |
| Seguridad y gobierno | 10% | Matriz de roles, entidades, auditoría, autenticación y segregación de datos. |
| Reportes y métricas | 10% | Tableros con datos de la prueba, filtros, detalle y exportación. |
| TCO, adopción y soporte | 10% | Presupuesto a tres años, plan de adopción, niveles de soporte y responsabilidades. |
Calificá cada criterio, por ejemplo, de 1 a 5 y multiplicalo por su peso. Agregá una columna de riesgos y otra de supuestos pendientes. Una opción puede obtener buen puntaje funcional y, aun así, quedar condicionada por una integración crítica no probada o por un esquema de soporte insuficiente.
Cómo probar GLPI antes de decidir
Una prueba de concepto de una plataforma ITSM con GLPI debería reproducir una porción pequeña pero completa de la operación. No hace falta cargar todo el inventario ni diseñar cada catálogo. Sí conviene comprobar el flujo de punta a punta con datos, perfiles y volúmenes representativos.
Definir el caso
Elegí un incidente frecuente, una solicitud con aprobación y un activo real. Establecé de antemano qué resultado se considera exitoso.
Configurar el mínimo
Creá usuarios, perfiles, entidades, categorías, reglas, calendarios y SLA. Documentá qué fue estándar y qué requirió adaptación.
Integrar y medir
Probá al menos identidad, correo o inventario. Medí tiempos, pasos manuales, calidad de datos, errores y trazabilidad.
Operar una semana
Involucrá usuarios y técnicos. Registrá fricciones, consultas, cambios de configuración y capacidad del equipo para administrarla.
La prueba debe incluir escenarios incómodos: reasignaciones, tickets reabiertos, activos duplicados, vencimientos, usuarios de otra entidad, indisponibilidad de una integración y restauración de respaldo. Las plataformas se diferencian menos en el camino ideal que en su respuesta ante excepciones.
Cuándo GLPI suele encajar y cuándo conviene revisar condiciones
Buen encaje potencial
- La empresa quiere integrar service desk, activos e inventario.
- Necesita flexibilidad para modelar entidades, roles, reglas y catálogo.
- Busca una adopción gradual y control sobre el despliegue.
- Cuenta con gobierno del proyecto y soporte especializado.
- Valora una plataforma extensible y con ecosistema de complementos.
Condiciones a resolver
- No hay responsables definidos para procesos, datos ni plataforma.
- Se pretende migrar todo de una vez sin depurar categorías o activos.
- Las integraciones críticas no tienen dueño ni especificación.
- El equipo espera que la herramienta diseñe por sí sola el modelo ITSM.
- No existe tiempo asignado para capacitación, pruebas y mejora continua.
GLPI puede soportar operaciones de gran escala, pero la escalabilidad no se presume: se diseña y se prueba. El caso publicado por el propio proyecto sobre Econocom informa 260.000 tickets y dos millones de activos gestionados; es una referencia de capacidad posible, no una garantía automática para cualquier arquitectura. Dimensionamiento, base de datos, integraciones, retención y disciplina operativa siguen siendo determinantes.
Errores frecuentes al implementar ITSM
Copiar el proceso anterior
Digitalizar formularios y autorizaciones obsoletas conserva la demora. Antes de configurar, eliminá pasos sin valor y definí excepciones.
Cargar inventario sin gobierno
Si no existen identificadores, responsables y reglas de actualización, la base pierde confiabilidad y los técnicos vuelven a sus planillas.
Medir únicamente cantidad
Cerrar muchos tickets no equivale a entregar buen servicio. Combiná volumen con SLA, recurrencia, reaperturas, satisfacción y antigüedad.
Personalizar antes de adoptar
Modificar demasiado pronto eleva mantenimiento y dificulta actualizaciones. Primero probá configuración estándar, reglas y complementos mantenidos.
Checklist para seleccionar una plataforma ITSM con GLPI
- Servicios, usuarios, canales y prioridades están definidos.
- Los procesos críticos fueron documentados con responsables.
- Tickets y activos pueden relacionarse y conservar historial.
- El inventario tiene fuentes, frecuencia y criterios de calidad.
- SLA y OLA contemplan calendarios, pausas y escalamiento.
- Roles y entidades respetan la segregación necesaria.
- Las integraciones prioritarias fueron probadas, no sólo declaradas.
- Respaldo, recuperación, actualización y monitoreo tienen diseño.
- Los indicadores responden preguntas operativas concretas.
- El costo total incluye implementación, operación y evolución.
- Existe un plan de migración, capacitación y adopción.
- El soporte local tiene alcance, horarios y escalamiento claros.
Preguntas frecuentes sobre GLPI e ITSM
¿GLPI es sólo una herramienta de tickets?
No. GLPI combina help desk con gestión de activos e inventario, además de catálogo, niveles de servicio, reglas, conocimiento, contratos y otras funciones. El alcance efectivo depende del diseño y de los módulos que la organización decida implementar.
¿Conviene implementar todos los procesos a la vez?
Generalmente no. Es más seguro comenzar con procesos de alto impacto y alcance controlado, estabilizar datos y responsabilidades, medir resultados y ampliar por etapas. Una adopción gradual reduce riesgo sin impedir diseñar una arquitectura de largo plazo.
¿Qué diferencia hay entre inventario e ITAM?
El inventario identifica componentes y configuraciones. ITAM agrega propiedad, estado, costo, contrato, licencia, responsable y ciclo de vida. Para aportar valor, ambos deben vincularse con usuarios, ubicaciones, servicios e intervenciones.
¿GLPI puede manejar distintas empresas o sedes?
Sí, su modelo de entidades permite organizar activos, usuarios, perfiles y tickets en estructuras jerárquicas. La configuración debe probar herencia, visibilidad y permisos para evitar accesos indebidos o una fragmentación innecesaria.
¿El software abierto elimina los costos de ITSM?
No. Puede cambiar el modelo de licenciamiento y dar mayor control, pero siguen existiendo costos de infraestructura, implementación, migración, soporte, capacitación, integraciones y operación. La comparación correcta utiliza costo total y riesgo, no sólo licencia.
¿Por qué es importante contar con soporte local?
Porque la continuidad depende tanto de la aplicación como de su configuración, integraciones y procesos. Un equipo local puede acelerar diagnóstico, coordinar con las áreas internas, acompañar actualizaciones y traducir necesidades empresariales a decisiones técnicas.
La decisión combina plataforma, proceso y operación
La mejor plataforma ITSM con GLPI no es la que acumula más módulos, sino la que puede sostener el modelo de servicio de la empresa con información confiable, controles claros y esfuerzo operativo razonable. Para comprobarlo, conviene evaluar procesos reales, relacionar tickets con activos, probar automatizaciones e integraciones y asignar responsables para la mejora continua.
En CTL acompañamos proyectos de GLPI desde el relevamiento y el diseño hasta la implementación, integración, capacitación y soporte. El objetivo es que la plataforma produzca trazabilidad y decisiones mejores, no simplemente una nueva bandeja de tickets.
¿Querés evaluar GLPI para tu operación?
Revisemos procesos, inventario, integraciones y niveles de servicio para definir un alcance realista y una hoja de ruta empresarial.
Contenido preparado para CTL. Fuentes técnicas de referencia: documentación y sitio oficial de GLPI.