OCS Inventory en concesionarias: equipos, software y salida
Un caso anonimizado muestra cómo registrar notebooks, software y despliegues con OCS Inventory, permisos, backup y prueba de baja.
Una notebook de posventa siguió entrando al sistema después de cambiar de responsable. En un caso anonimizado de una concesionaria sobre Ruta 40 en Tunuyán, la planilla de activos tenía seriales vencidos y software sin dueño. OCS Inventory NG 2.12.5 permite cruzar inventario de equipos, software y despliegues con agentes Windows y Linux. Esta nota muestra cómo ordenar alta, baja, permiso y salida.
Dónde se desordena el parque de equipos
El problema aparece cuando compras registra la factura, sistemas instala el equipo y posventa usa la máquina sin que exista un registro único. La documentación de OCS Inventory divide el producto en secciones de servidor, agente, inventario y despliegue. La versión de servidor 2.12.5 fue publicada el 23 de julio de 2026, mientras el sitio oficial advierte que OCS 3.0 está en estado release candidate y sirve para pruebas, no para producción. La cifra externa confirma la fatiga de herramientas: Stack Overflow 2025 informó que 54% de quienes respondieron usa seis o más aplicaciones para hacer su trabajo. En una concesionaria chica, esa dispersión se ve en garantías, turnos, repuestos, facturación y soporte. El objeto que volvió tangible el caso fue una etiqueta blanca con un número de inventario escrito dos veces, una por compras y otra por sistemas. El antagonista era esa planilla duplicada: suficiente para comprar, débil para auditar.
Cómo funciona por dentro OCS Inventory trabaja con agentes y servidor.
El agente instalado en cada equipo recoge datos de hardware, sistema operativo, software instalado, dirección IP y usuario. El servidor de comunicación recibe esos datos por HTTP/HTTPS, los procesa y los guarda en la base usada por OCS. La consola web muestra equipos, software, historial y grupos. El módulo de despliegue puede enviar paquetes o comandos a equipos seleccionados cuando el agente está configurado y el servidor usa HTTPS. 1. Sistemas instala el agente en notebooks, PCs de caja y equipos de taller. 2. El agente envía inventario al servidor con nombre, serial, IP y software. 3. OCS guarda datos en su base y muestra cambios en la consola. 4. Compras vincula factura, garantía y responsable administrativo. 5. Sistemas agrupa equipos por sector y permisos de operación. 6. El backup copia base, paquetes de despliegue y configuración del servidor. 7. Una baja de prueba retira un equipo y deja fecha, usuario y motivo. La base guarda registros estructurados del parque. Los paquetes de despliegue quedan fuera de la base y deben copiarse con el mismo plan. El monitoreo revisa agentes sin reporte, equipos duplicados y despliegues fallidos.
Qué se instala o configura primero
El primer entregable es un inventario de 40 a 60 equipos con responsable, serial, sector, software principal y estado. Se instala OCS Inventory Server 2.12.5, agentes Windows y Unix donde corresponda, HTTPS obligatorio para despliegues, usuarios por rol y exportación CSV. Compras puede leer garantía y factura; sistemas edita agente, grupo y despliegue; gerencia ve cantidades sin borrar registros. El inventario se cruza con una etiqueta física y una baja administrativa. Cada equipo recibe un código único, sector, responsable y fecha de entrega. Cuando cambia de dueño, compras conserva factura y garantía; sistemas conserva historial técnico. Ese cruce evita que una notebook vuelva de taller con otro nombre y el mismo serial. Con dólar oficial vendedor a ARS 1.515, un piloto de 16 a 26 horas técnicas a USD 30/h queda entre USD 480 y USD 780, es decir entre ARS 727.200 y ARS 1.181.700. Incluye servidor, agentes iniciales, roles, exportación, respaldo y prueba de baja. Quedan fuera recorrida física completa, compra de etiquetas y depuración de licencias viejas. UMSA puede usar este patrón en operaciones con soporte distribuido: primero se fija qué dato identifica al equipo, después quién lo administra y al final qué prueba demuestra que la baja cerró.
Dónde se rompe y cómo probarlo
El primer riesgo es agente mudo. La señal aparece cuando un equipo no reporta durante siete días y sigue activo en la planilla. La prueba apaga o bloquea un agente de ensayo y exige que el tablero liste equipo, último reporte y responsable. El segundo riesgo está en despliegues sin HTTPS. La documentación de OCS marca HTTPS como requisito para enviar paquetes. La prueba intenta desplegar un paquete de ensayo sin HTTPS y debe fallar; luego se habilita HTTPS y se registra resultado, hora y equipo. El tercer riesgo es backup parcial. Si se copia la base y se olvidan paquetes o configuración, el servidor vuelve sin capacidad de repetir despliegues. La prueba restaura en un entorno aislado, abre diez equipos, revisa dos paquetes y ejecuta una baja controlada. La concesionaria gana control cuando puede responder quién usa cada equipo, qué software tiene, qué garantía vence y qué pasó cuando salió de circulación.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.