Cajeros Aglar

El reto

Una red nacional de cajeros automáticos genera incidentes a toda hora — corte de enlace, error de impresora, atasco de cartuchos, soft reset de la plataforma — y cada uno tiene su SLA, su criticidad y su escalamiento. El proveedor de servicio técnico necesita registrar el ticket en segundos, asignarlo al especialista correcto, escalar de Mesa de Servicios a Servicio Técnico cuando aplica, y dejar trazabilidad inmutable de cada cambio de estado para defender el cumplimiento de SLA frente al banco-cliente.

La operación venía corriendo sobre una app PHP histórica con ~85 tablas, miles de unidades de servicio y cientos de miles de tickets acumulados. El reto no era reescribir desde cero — era modernizar la UI a una SPA viva sin tocar el schema productivo y sin congelar la operación durante la migración.

La solución

Una plataforma ITSM en dos capas que conviven: el legacy PHP 7.4 sigue operativo para pantallas no migradas, y una SPA React 19 + Vite con API Node.js + Express 5 toma el control pantalla por pantalla — Dashboard, Tickets, Unidades de Servicio, Especialistas, Mantenimiento, SLA, Usuarios, Reportes… — sobre la misma base MySQL 8, sin migraciones disruptivas.

Modelo de dominio específico de ATMs

• Catálogos def_* que reflejan el lenguaje real del negocio: regiones, localidades, marcas (NCR, Diebold, Wincor, OKI), modelos, niveles de especialista, prioridades, estados de ticket, incidentes, plataformas, sistemas operativos, tipos de enlace, criticidades.
• Unidades de servicio con ficha técnica completa: IP/gateway/máscara, hostname, marca/modelo, serie, lote, RAM, disco, procesador, ubicación, dirección, fechas de instalación y entrega de lote, tipo de enlace y proveedor, criticidad, plataforma, estado operativo (operativo / fuera de servicio / mantenimiento), encargado y supervisor. Panel colapsable a los 5 campos primarios para lectura rápida desde el ticket.
• Tickets con cabecera + movimientos (tbl_tickethead + tbl_ticketmov): histórico inmutable de cada cambio de estado, especialista y prioridad por ticket, con timestamps separados para solicitud, asignación, asistencia y solución — medibles contra SLA.

Workflow y reglas de escalamiento reales

• Ciclo de ticket ABIERTO → ASIGNADO → EN PROCESO → RESUELTO → CERRADO con registro de cada transición.
• Cascada Nivel → Especialista: al crear un ticket, el grupo arranca en “MESA DE SERVICIOS” (nivel 1) y las opciones de especialista se filtran dinámicamente por nivel seleccionado.
• Flags “asistencia técnica” se habilitan solo cuando el grupo es “Servicio Técnico” — refleja la regla real del proveedor.
• Módulo afectado contextual: las opciones del campo se acotan al tipo de unidad (ATM, kiosco, agencia), evitando elegir módulos imposibles para ese dispositivo.
• Filtrado geográfico jerárquico: regiones → localidades con acordeón colapsable, búsqueda y filtros combinables (estado, ubicación, especialista, texto libre) sobre listados de tickets y de unidades.

SLA, dashboard y reporting

• Planes SLA configurables por proveedor con detalles por nivel/criticidad/horario, asociados a unidades de servicio, sirviendo como referencia de cumplimiento contra los timestamps registrados en cada ticket.
• Mantenimientos preventivos además de los correctivos del ticket: contratos, controles, movimientos, observaciones y resúmenes por unidad — pensado para la operación de campo recurrente, no solo para incidentes.
• Dashboard con KPIs: total/abiertos/críticos/cerrados del día, tiempo medio de respuesta, tickets recientes, top cajeros con más tickets, distribución por estado y por módulo, rezagados (envejecidos). Gráficos con Recharts.
• Catálogos administrables desde la UI: pestañas para crear/editar/eliminar marcas, modelos, prioridades, estados, regiones, localidades, niveles, proveedores SLA e incidentes — CRUD genérico parametrizado por nombre de catálogo en un único endpoint.

Migración progresiva sin freeze

• 49 endpoints REST en la API Node organizados en dominios (auth, tickets, cajeros, mantenimientos, especialistas, usuarios, regiones, localidades, catálogos, SLA, dashboard, reportes), todos protegidos por middleware JWT.
• Autenticación con compatibilidad legacy: bcrypt + JWT en la nueva API con compatibilidad hacia las contraseñas PHP existentes; bloqueo de cuenta tras intentos fallidos y auditoría de logins heredables.
• Optimización de rendimiento histórica preservada: paginación por cursor, índices estratégicos y cache de prioridades llevaron consultas de 15–30 s a 2–3 s (mejora de 90–95 %) en la app PHP — la SPA opera sobre el mismo schema optimizado.
• Despliegue local 100 % reproducible con docker compose up: MySQL 8 + API Node + Nginx sirviendo el bundle React, con seeds de inicialización montados automáticamente (esquema completo + usuario admin).
• Modelo dual coexistente: la UI PHP legada vive en php.viejo/ y comparte la misma BD; la SPA opera sobre las mismas tablas, permitiendo migración progresiva pantalla por pantalla sin tocar datos.

Resultados

• Schema robusto en producción: AUTO_INCREMENT histórico arriba de 270 000 tickets y 660 000 movimientos sobre 1 800+ unidades de servicio — la migración a la SPA se hace sobre datos reales, no sobre un toy dataset.
• Operación nacional cubierta: 3 regiones, 12+ localidades, catálogo de 4 marcas / 8 modelos de cajeros, y separación clara de roles Mesa de Servicios / Servicio Técnico / Ingeniería con tres niveles de escalamiento.
• Migración pantalla por pantalla verificable: Dashboard, Tickets, Detalle de Ticket, Form, Unidades, Especialistas, Mantenimiento, SLA, Usuarios, Configuración y Reportes ya en React; el resto del legacy sigue operativo en paralelo.
• Cero freeze de operación: cada commit del último mes refleja iteración activa de reglas de negocio (cascada Nivel→Especialista, gate de asistencia técnica, default MESA DE SERVICIOS, scope de módulo afectado por unidad, colapso del panel de unidad) en la versión nueva mientras la legada sigue procesando tickets reales.

Por qué importa

Cajeros Aglar es un caso vivo de modernización pragmática: cuando un cliente tiene una app heredada que funciona pero envejece, no siempre la respuesta es “reescribir desde cero”. Acá demostramos que se puede levantar una SPA moderna sobre el schema productivo, migrar pantalla por pantalla sin tocar datos, mantener la operación corriendo, y al final llegar con una app nueva, mantenible y veloz — con menos riesgo y sin la cuenta gigante de un big bang.

Es el patrón que aplicamos cuando un cliente nos llega con un sistema crítico que no se puede apagar pero que ya pasa factura en mantenimiento, agilidad de cambios o experiencia de usuario.