El reporte que le tomaba a un banco dos semanas al mes — y cómo lo dejamos en cero

Tres personas del equipo de negocio de MUFG dedicaban cerca de dos semanas cada mes a armar, a mano, uno de sus reportes internos. El proceso involucraba jalar datos de distintos sistemas, cruzarlos, revisar inconsistencias, y formatear todo para entrega — y aun así, el resultado terminaba con errores más de una vez.

El reto real no era técnico en el sentido de 'nos falta un algoritmo sofisticado' — era arquitectónico: cada aplicación y cada usuario de negocio extraía información de un lugar distinto, sin una sola fuente de verdad. Cuando cinco personas parten de cinco versiones ligeramente distintas de los mismos datos, los errores no son casualidad, son matemáticamente inevitables. Antes de proponer una sola tabla o un solo pipeline, empezamos por entender ese síntoma: no preguntamos '¿qué reporte necesitan?', preguntamos '¿de dónde saca cada quien su versión de los números, y por qué no coinciden?'.

Esa primera fase de descubrimiento tomó semanas de entrevistas con cada usuario de negocio que tocaba el reporte, no solo con el área de sistemas — porque el área de sistemas sabía qué tablas existían, pero solo el equipo de negocio sabía cuáles de esas tablas en realidad usaba cada quien, y por qué. De ahí salió el mapa real: no era un problema de un reporte mal hecho, era un problema de cinco fuentes de verdad ligeramente distintas alimentando el mismo número.

Con ese mapa, diseñamos una estrategia de Data Warehouse centralizada donde todas las aplicaciones y usuarios de negocio extraen la información del mismo lugar, no de sus propias copias. Sobre esa base construimos tres capas de control que no son negociables en un proyecto bancario: enmascarado, cifrado y ofuscado de datos sensibles con Informatica Power Center (para que ni siquiera quien construye los reportes vea datos personales en claro sin necesidad); certificados TLS 1.2 con SHA-256/RSA en cada conexión entre sistemas, para que la información nunca viaje sin cifrar; y una estrategia de espejo con DRP pasivo, para que el reporte —que tenía una fecha de entrega fija cada mes— nunca dependiera de que un solo servidor estuviera disponible ese día.

Antes de apagar el proceso manual, lo corrimos en paralelo durante varios ciclos: el reporte automático se generaba y se comparaba contra el que el equipo seguía armando a mano, celda por celda, hasta que las tres personas que antes lo hacían manualmente confiaron en que el número automático era, de hecho, más consistente que el suyo — no al revés. Solo entonces se hizo el corte, con el proceso manual documentado como respaldo por si algo fallaba, no eliminado de un día para otro.

El resultado: el mismo reporte que tomaba dos semanas de trabajo manual repartido entre tres personas, hoy se genera de forma automática, sin la intervención que antes generaba inconsistencias.

Este es, para nosotros, el ejemplo más claro de por qué insistimos en escuchar el proceso real antes de proponer tecnología: la solución no fue 'más inteligencia artificial', fue gobierno de datos y arquitectura bien hechos, validados en paralelo antes de apagar nada. A veces el proyecto más impactante no es el más futurista, es el que le devuelve dos semanas al mes a la gente correcta, con la confianza de que el número que ven es, por fin, el mismo que ve todo el banco.

Servicios relacionados: Data Warehouse, Data Governance, Calidad de Datos, CyberSecurity, DRP.