Cómo modernizar sistemas bancarios sin interrumpir la operación
Migrar un core bancario no es un proyecto de tecnología: es un ejercicio de gestión de riesgo. Las fases, los puntos de reversión y los errores que salen caros.
El problema no es técnico
La mayoría de los proyectos de modernización bancaria no fracasan por una limitación tecnológica. Fracasan porque nadie definió qué pasa si la migración sale mal a las dos de la mañana de un lunes de quincena.
Un core bancario procesa transacciones que no se pueden perder ni duplicar. Eso cambia por completo el cálculo: la pregunta no es cuánto tarda la migración, sino cuánto tarda revertirla.
Las cuatro fases
1. Inventario de lo que realmente corre
Antes de proponer arquitectura, hay que saber qué hay. En instituciones con quince o veinte años de operación, siempre aparecen integraciones que nadie documentó y procesos batch que alguien dejó corriendo en un servidor olvidado.
2. Convivencia, no reemplazo
El sistema nuevo y el viejo operan en paralelo durante un período definido. Es más caro y más lento, pero es lo que permite comparar resultados con datos reales antes de apagar nada.
3. Migración por dominio
Nunca todo de una vez. Se migra un dominio funcional, se valida durante un ciclo completo de operación, y solo entonces se avanza al siguiente.
4. El punto de reversión
Cada fase necesita una respuesta escrita a la pregunta: si esto falla, ¿cómo volvemos al estado anterior y cuánto tarda? Si no hay respuesta, la fase no está lista para ejecutarse.
Los tres errores que salen caros
Migrar en temporada alta. Quincena, cierre de mes, fin de año. Parece obvio y sin embargo se sigue haciendo por presión de calendario.
Subestimar la validación. El tiempo de pruebas casi siempre se recorta cuando el proyecto se atrasa. Es exactamente al revés: es lo último que debería recortarse.
No incluir al área de operaciones desde el inicio. Quien va a usar el sistema todos los días detecta problemas que ningún ambiente de pruebas reproduce.
Qué exigirle a su proveedor
Antes de firmar, pida el plan de reversión por fase, el criterio de aceptación de cada entrega, y el nombre de quien responde a las dos de la mañana. Si alguna de esas tres respuestas es vaga, el riesgo lo está asumiendo su institución.
¿Este tema describe la situación de su organización?
Conversemos sobre su casoSeguir leyendo
Qué debe exigirle a un proveedor de integración de sistemas críticos
Doce preguntas concretas para hacer antes de firmar. Si el proveedor no puede responderlas con especificidad, el riesgo lo asume su organización.
Cumplimiento5 riesgos regulatorios de TI que enfrentan las cooperativas en Costa Rica
Trazabilidad incompleta, respaldos sin verificar, accesos sin revocar. Los hallazgos que más se repiten en supervisión y cómo anticiparlos antes de que aparezcan en un informe.