GLPI 11 en colegios: tickets, activos y salida probada
Caso anonimizado de colegio profesional en Cuyo: cómo unir tickets, activos, documentos y permisos con GLPI 11 sin perder backup ni trazabilidad.
Notebook, ticket y factura: si los tres quedan separados, soporte pierde contexto. En un colegio profesional de Cuyo con 1.800 matriculados, cada reclamo de mesa de ayuda abría una búsqueda por chats, inventario y carpetas de compras. GLPI 11 ordena tickets, activos, documentos y permisos en una misma base. Este caso explica qué carga administración, qué ve soporte y cómo probar baja, respaldo y salida.
Qué revela un ticket cuando el activo tiene dueño
El dato global ayuda a dimensionar el desorden. Stack Overflow 2025 informó que 45,5 % de los respondentes usa entre una y cinco aplicaciones de software para trabajar, y 35,4 % usa entre seis y diez. En una institución chica, esa mezcla suele terminar en tickets por un lado, inventario por otro y facturas en una carpeta aparte. La factura recurrente de soporte sin activo asociado es el hecho que encarece cada reclamo mensual. El caso empezó con una etiqueta blanca de inventario pegada sobre una notebook Lenovo ThinkPad. El código se leía, pero nadie podía decir qué ticket había pedido el cambio de disco, qué proveedor lo había hecho ni qué garantía seguía vigente. GLPI permite abrir tickets, asociarlos a activos y adjuntar documentos. Esa unión reduce búsqueda administrativa porque cada reclamo conserva usuario, equipo, estado, técnico, fecha y archivo. La documentación de gestión de tickets de GLPI describe incidentes, solicitudes, impacto, prioridad, estados y vínculos entre tickets. Para un colegio profesional, el indicador útil separa reclamos cerrados con evidencia de reclamos que siguen esperando dato externo. El reporte semanal muestra esa cola por área y por proveedor.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, administración carga activo, número interno, proveedor, factura y ubicación. Segundo, soporte abre o recibe un ticket con solicitante, síntoma, categoría, prioridad y activo asociado. Tercero, GLPI guarda estado, técnico asignado, historial, comentario y documentos. Cuarto, el perfil del usuario define si puede crear, leer, editar o borrar; la documentación de acciones en GLPI muestra que las acciones dependen de permisos del perfil. Quinto, compras adjunta presupuesto, garantía o remito. Sexto, dirección mira estadísticas y tickets vencidos. Séptimo, una prueba restaura base, archivos y configuración en otro host. GLPI toma como entrada tickets, activos, usuarios y documentos; entrega listas, estados, estadísticas y trazabilidad. La base guarda registros. El directorio de archivos conserva documentos subidos, imágenes y adjuntos. El administrador técnico mantiene usuarios, perfiles, backup y actualizaciones. Si GLPI falla, soporte pierde historial y compras vuelve a preguntar por garantía; por eso la restauración forma parte del alcance inicial. El límite humano aparece en la baja de usuarios. Si el matriculado cambia de contacto o el proveedor deja de trabajar, el ticket debe conservar responsable nuevo y acceso viejo cerrado. El sistema sirve cuando esa operación queda escrita, con fecha, perfil que ejecutó el cambio y documento asociado.
Qué se instala o configura primero
La primera etapa puede cubrir mesa de ayuda, activos principales, documentos y perfiles. Conviene empezar con equipos de administración, impresoras de atención al público, enlaces de internet y software con licencia. El primer entregable verificable es una búsqueda por activo que muestre tickets abiertos, facturas, garantía, usuario responsable y última intervención. El costo de arranque para una institución de este tamaño puede ubicarse entre USD 650 y USD 2.000, equivalentes a ARS 997.750 y ARS 3.070.000 con dólar oficial vendedor de ARS 1.535 consultado para esta corrida. Incluye relevamiento, carga inicial de hasta 150 activos, perfiles, categorías, plantillas, backup y prueba de salida. Quedan afuera inventario físico completo de edificios, mesa de ayuda telefónica y normalización de diez años de documentación vieja. UMSA suele pedir una prueba de baja antes de cerrar el piloto: se desactiva un usuario, se reasigna un ticket, se intenta abrir un activo sin permiso y se restaura un adjunto. Si esas cuatro acciones dejan evidencia, el colegio ya tiene un circuito defendible ante comisión directiva.
Dónde se rompe y cómo probarlo Primer riesgo: tickets sin activo.
La señal aparece cuando soporte informa horas trabajadas y nadie sabe sobre qué equipo. La prueba exige activo o servicio asociado antes de pasar a estado resuelto. Segundo riesgo: perfiles amplios. La señal aparece cuando administración puede borrar un ticket cerrado. La prueba usa un usuario de mesa de entradas, uno de soporte y uno de dirección; cada acción se registra. Tercer riesgo: backup incompleto. La guía de actualización de GLPI pide identificar base, directorio de instalación, configuración, archivos y plugins. La señal aparece cuando vuelve la base y faltan adjuntos. La prueba restaura un ticket con factura y documento. Cuarto riesgo: estadísticas sin acuerdo. La señal aparece cuando soporte cuenta tickets cerrados por fecha de resolución y dirección por fecha de creación. La prueba escribe la definición dentro del tablero. El cierre incómodo es operativo: cada reclamo sin activo vuelve a cobrar tiempo el mes siguiente.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.