Una tienda que salta al 4G nueve veces en una semana y un córner sin línea: el IT de una cadena de tiendas

El problema

El IT central de una cadena de tiendas ve cien tiendas a través de una consola de monitorización, un listado de equipos y una cola de tickets, y en ninguna de ellas hay nadie de informática. En una semana normal, una tienda de centro comercial salta al router 4G nueve veces, sigue vendiendo y nadie se da cuenta de que la SIM va por el 93% de su límite de datos hasta que el router se queda sin velocidad un sábado por la tarde; catorce routers de respaldo no se han probado nunca; todas las tiendas de una región pierden el túnel con la central hacia las ocho de la tarde y el service desk lo registra como diecisiete problemas distintos; un córner dentro de unos grandes almacenes abre en diez días y su línea sigue sin instalar, porque el operador no puede pasar del cuarto de comunicaciones de los grandes almacenes; tres tiendas con el mismo modelo de impresora de tickets acumulan atasco tras atasco; una tienda abre cuatro veces la mediana de tickets, casi todos porque las PDA pierden el Wi-Fi en el almacén; dos tiendas cerraron hace semanas con los portátiles y los datáfonos todavía dentro; y dos personas empiezan mañana sin cuenta. No es la comprobación de preparación de un local que publiqué la semana pasada, que mira los sistemas de un local de hostelería antes del servicio, ni el seguimiento de la preapertura de un hotel: es el IT central cuidando de toda una red de tiendas, semana tras semana, y decidiendo quién va a dónde.

Qué he hecho

• Conectividad: disponibilidad de la línea principal en la semana, saltos al router de respaldo y tiempo en respaldo, routers de respaldo sin probar nunca, SIM de respaldo cerca de su límite de datos, tiendas sin línea de respaldo, el túnel con la central por tienda y por región, y conexiones de AnyConnect fallidas.
• Equipos: PC de tienda y de trastienda sin sincronizar o con una versión de Windows sin soporte, impresoras desconectadas o con poco tóner, impresoras de tickets que se atascan una y otra vez y el modelo que hay detrás, datáfonos que no reportan, PDA desconectadas y SAI que han fallado su autotest.
• Tickets: tickets por tienda frente a la mediana de la red, incidencias repetidas, fuera de SLA, visitas pendientes y tickets abiertos con proveedores.
• Aperturas y cambios: la checklist de cada tienda que abre en las próximas cuatro semanas, tiendas cerradas con equipos sin recuperar, cierres y reformas; y la parte de usuarios, ligera a propósito: altas sin cuenta, bajas todavía activas y cuentas compartidas de tiendas cerradas (la revisión de accesos que publiqué la semana pasada va más a fondo).
• Un estado rojo, ámbar o verde por tienda con sus motivos, una cuadrícula de tiendas por región, la lista de visitas y envíos ordenada por región y técnico de campo, las llamadas a proveedores, report.html, store-review.md para la reunión semanal de operaciones de tienda con la tendencia frente a la semana anterior, CSV de cada área y un exportador de solo lectura en PowerShell para Microsoft Graph, Active Directory y Entra ID.

Cómo está hecho

Python solo con la librería estándar. Cada problema pertenece a una tienda y dice lo que necesita: una visita del técnico de campo, un envío, una llamada al proveedor o trabajo en remoto, así que la lista de cada técnico sale de las comprobaciones en lugar de escribirse a mano. La conectividad usa los últimos siete días y los compara con la semana anterior; los tickets usan los últimos treinta días y la mediana de la red, y un ticket en espera del proveedor no cuenta para el SLA. Las tiendas en reforma no se revisan hasta que reabren, y de una tienda cerrada solo se miran sus equipos y sus cuentas. Los datos de conectividad e impresoras son las exportaciones de la herramienta de monitorización, y el estado y el tóner de las impresoras son los objetos SNMP estándar de impresora. La demo es una cadena de ópticas inventada con 122 tiendas en España y Portugal, entre tiendas de calle, centros comerciales y córners dentro de unos grandes almacenes, revisada un martes por la mañana con los problemas puestos a propósito. 14 tests, un runbook con el ciclo semanal y el orden del día de la reunión, y un workflow de GitHub Actions que ejecuta los tests y regenera los datos de la demo y la captura.

Qué aprendí

De dar soporte a las boutiques y puntos de venta de marcas de lujo, con sus impresoras, la VPN de Cisco AnyConnect y el alta de cada persona nueva (red, correo, AS400 y aplicaciones de negocio); de unas 200 preaperturas de córners de marca dentro de grandes almacenes; de Intune y Microsoft Graph; de ser responsable de los procesos de incidencias y cambios; y de dar soporte a unos 2.500 usuarios en oficinas europeas. En una de esas aperturas la conectividad se cayó dos horas antes de abrir: volví a dar servicio al córner con un router USB 4G provisional mientras revisaba la conexión de la tienda y el cuarto de comunicaciones de la planta con los técnicos de los grandes almacenes. Las lecciones que hay detrás de la herramienta son que una tienda en respaldo está a un fallo de no poder vender; que un respaldo sin probar es una esperanza; que una región entera fallando a la misma hora es una sola causa, no diecisiete tickets; que la línea de un córner depende del cuarto de comunicaciones del anfitrión, así que hay que reservar pronto la visita conjunta y tener un router 4G listo para el día de la apertura; que un modelo de impresora que se atasca en tres ciudades es una llamada al proveedor; que una tienda con cuatro veces la mediana suele tener un único problema; y que quien empieza mañana necesita su cuenta esta mañana.

Siguientes pasos

• Ejecutar las exportaciones y la revisión cada lunes por la noche y enviar a cada técnico de campo su parte de la lista.
• Leer los tickets desde la Table API de ServiceNow en lugar de una exportación de lista.
• Guardar el histórico semanal de cada tienda para ver su tendencia en un trimestre.

¿Quieres llevarlo a tu entorno o adaptarlo a tu caso? Escríbeme y lo vemos.