Store IT health review for a retail chain

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.

The problem

A retail chain's central IT sees a hundred stores through a monitoring console, a device list and a ticket queue, and none of the stores has anyone from IT inside. In a typical week a shopping centre store fails over to its 4G router nine times, keeps selling, and nobody notices that the SIM is at 93% of its data cap until the router is throttled on a Saturday afternoon; fourteen backup routers have never been tested; every store in one region loses its tunnel to head office around eight in the evening, and the service desk logs seventeen separate problems; a corner inside a department store opens in ten days and its line is still not installed, because the carrier cannot get past the department store's comms room; three stores with the same receipt printer model log jam after jam; one store raises four times the median number of tickets, nearly all about the handhelds losing Wi-Fi in the stockroom; two stores closed weeks ago with their laptops and terminals still inside; and two people start tomorrow without an account. This is not the venue readiness check I published last week, which looks at a hospitality venue's systems before service, nor the hotel pre-opening tracker: it is central IT looking after a whole estate of stores, week after week, and deciding who goes where.

What I built

Connectivity: primary line availability over the week, failovers to the backup router and time on backup, backup routers never tested, backup SIMs near their data cap, stores with no backup line, the site-to-site tunnel by store and by region, and failed AnyConnect connections.
Devices: store and back-office computers not checked in or on Windows out of support, printers offline or low on toner, receipt printers that jam again and again and the model behind them, card terminals not reporting, handhelds offline and UPS that failed their self-test.
Tickets: tickets per store against the estate median, repeat incidents, past SLA, field visits pending and vendor tickets open.
Openings and changes: the pre-opening checklist of every store opening in the next four weeks, closed stores with devices not recovered, closings and refurbishments; and the users side kept light: joiners without an account, leavers still enabled and shared accounts of closed stores (the access review I published last week goes deeper).
A red, amber or green status per store with its reasons, a store grid by region, the visit and ship list ranked by region and field technician, the vendor calls, report.html, store-review.md for the weekly retail operations meeting with the trend against last week, CSVs for every area, and a read-only PowerShell exporter for Microsoft Graph, Active Directory and Entra ID.

How it is built

Python with the standard library only. Every issue belongs to a store and says what it needs: a visit from the field technician, a shipment, a vendor call or remote work, so the list for each technician falls out of the checks instead of being written by hand. Connectivity uses the last seven days and compares them with the week before; tickets use the last thirty days and the estate median, and a ticket on hold with a vendor does not count against the SLA. Stores in refurbishment are not checked until they reopen, and a closed store is only checked for its devices and accounts. The connectivity and printer data are the exports of the monitoring tool, and the printer status and toner are the standard SNMP printer objects. The demo is a made-up eyewear chain with 122 stores in Spain and Portugal, street stores, shopping centres and corners inside a department store, reviewed on a Tuesday morning with the problems placed on purpose. 14 tests, a runbook with the weekly cycle and the meeting agenda, and a GitHub Actions workflow that runs the tests and rebuilds the demo data and the screenshot.

What I learned

From supporting the boutiques and points of sale of luxury retail brands, with their printers, the Cisco AnyConnect VPN and the onboarding of every new person (network, email, AS400 and business applications); from about 200 pre-openings of brand corners inside department stores; from Intune and Microsoft Graph; from owning the incident and change processes; and from supporting about 2,500 users across European offices. At one of those openings the connectivity failed two hours before the doors opened: I brought the corner back online with a temporary USB 4G router while I checked the store's connection and the floor's comms room with the department store's technicians. The lessons behind the tool are that a store on its backup is one failure away from not selling; that an untested backup is a hope; that a whole region going wrong at the same hour is one cause, not seventeen tickets; that the line of a corner depends on the host's comms room, so the joint visit has to be booked early and a 4G router has to be ready for opening day; that one printer model jamming in three cities is a vendor call; that a store with four times the median usually has one problem; and that tomorrow's starters need their accounts this morning.

Next steps

Run the exports and the review every Monday night and send each field technician their part of the list.
Read the tickets from the ServiceNow Table API instead of a list export.
Keep the weekly history of every store to show its trend over a quarter.

Want to bring it to your environment or adapt it to your case? Get in touch and we can look at it together.

Tech Career Lab · newsletter

¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.

Apúntate y llévate las 33 ideasSign up and get the 33 ideas →