La única impresora de cocina llevaba caída desde ayer: la revisión de cada mañana en hostelería

El problema

Cuando el pool club se llena a la una, nadie se acuerda de que la monitorización estaba en verde a las nueve. Se acuerdan de las comandas que nunca llegaron a cocina, de la cola en el único datáfono que funcionaba o de los cargos a habitación que nunca llegaron a la factura del cliente. Todo eso se veía esa misma mañana: la impresora de la cocina de playa llevaba en error desde la tarde anterior, dos de los cuatro comanderos estaban sin batería o en un cajón, la línea de internet de respaldo llevaba cinco días caída y el interfaz del PMS tenía 37 cargos pendientes. El proveedor del TPV atiende hasta las siete de la tarde; el bar cierra a la una. Las señales están en el back office del TPV, el controlador de red, las consolas de los cajones de efectivo y del PMS y los portales de los proveedores; la revisión que importa las junta por servicio.

Qué he hecho

• Servicios: sin prueba de apertura cerca de abrir, servicios grandes y eventos sin nadie de IT de guardia, y actualizaciones de equipos programadas dentro de la congelación antes de un servicio.
• TPV y pagos: menos TPV y comanderos funcionando de los que necesitan los clientes, impresoras de cocina o KDS caídas donde hay comida, datáfonos caídos, y cajones de efectivo en error, sin cambio o con el depósito lleno.
• Red y sistemas del cliente: línea de internet principal o de respaldo caída, puntos de acceso Wi-Fi, switches y firewall, el interfaz del PMS para los cargos a habitación, la IPTV de las habitaciones y los codificadores de tarjetas.
• Proveedores: tickets abiertos fuera del SLA de cada proveedor, contratos vencidos o a punto de vencer, y servicios que abren o cierran fuera del horario de soporte del proveedor.
• report.html con los servicios día a día y los equipos por zona, opening-pack.md como checklist para los responsables de cada zona, y CSV de servicios, equipos, cobertura de proveedores e incidencias.
• Una prueba de solo lectura en PowerShell que hace ping a cada equipo de la red del local y guarda la última vez que respondió.

Cómo está hecho

Python solo con la librería estándar. La demo es un beach club con hotel boutique inventado, con restaurante, pool club, bar de atardecer y 24 habitaciones, 16 servicios en una semana con una noche de Halloween para 900 personas, 74 equipos y cinco proveedores, con los problemas puestos a propósito. 15 tests, un runbook para la revisión de cada mañana y un workflow de GitHub Actions que ejecuta los tests y regenera los datos de la demo y la captura.

Qué aprendí

De mis primeros años en IT dando soporte a clientes de hostelería, con TPV como ICG y HIOPOS, cajones CashDro, PMS hotelero e IPTV, y después de unas 200 preaperturas de corners de marcas de lujo en grandes almacenes. En una de ellas la conexión falló a dos horas de abrir; lo resolví con un router USB temporal mientras revisaba la línea y la sala de comunicaciones de la planta con los técnicos de los grandes almacenes. La lección que da forma a la herramienta es que un servicio está tan preparado como su equipo más débil y el proveedor que lo arreglaría a esa hora, así que el veredicto es por servicio, y la línea de respaldo, el comandero de repuesto y el horario del proveedor forman parte del plan.

Siguientes pasos

• Ejecutarlo cada mañana durante dos semanas con el inventario real de equipos y el plan de servicios, y ajustar los clientes por TPV y la prueba de apertura con los responsables de cada zona.
• Leer el estado de los equipos del back office del TPV y del controlador de red en lugar de la prueba de ping.
• Enviar a cada responsable el checklist de su servicio antes de abrir, y registrar los minutos perdidos al cerrar para las revisiones mensuales con los proveedores.

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