Modernizar el core: el caso para el comité, no la guía técnica

Imagine un comité que autoriza iniciar el reemplazo del sistema central de la institución durante un fin de semana. Hay más de cuatro años de planeación detrás, ensayos, un piloto interno y las garantías de los proveedores. Sobre el papel, la preparación parece completa.

Eso es, en lo esencial, lo que ocurrió en un banco británico: el consejo de TSB y su subcomité autorizaron entre el 18 y el 19 de abril de 2018 el inicio de la migración, que se ejecutó el fin de semana del 20 al 22. Casi de inmediato aparecieron fallas serias, y el lunes siguiente mostró que preparación y aseguramiento suficiente no son lo mismo.

Por «core» entendemos aquí el sistema de registro del que dependen operaciones críticas: clientes, cuentas, pólizas, pedidos, inventario, cobros, conciliaciones o reportes, según la industria, y con él los demás sistemas (canales, pagos, contabilidad). Este artículo no es una guía técnica. Es el caso para quien tiene que decidir: qué puede aprender un comité del caso público de TSB cuando la migración de datos y funciones críticas se concentra en un solo evento, qué alternativa existe, y cómo se presenta esa alternativa a un comité que pregunta por riesgo, por costo y por fechas. Está escrito para quien responde por la operación, el presupuesto o el riesgo en un banco, una fintech, una aseguradora, una cadena de retail o una empresa regulada.

Lo que publicaron TSB y la PRA sobre el caso

TSB, un banco británico, ejecutó su migración principal a una plataforma nueva en abril de 2018. El propio banco describió el programa como el cambio más complejo que había emprendido y «uno de los más complejos en la historia de la banca británica», con más de cuatro años de planeación [2]. Según el banco, el consejo autorizó el evento principal de migración con base en «un volumen significativo de evidencia objetiva»: atestaciones de la dirección, garantías escritas y orales de proveedores, nueve ensayos generales y eventos de transición exitosos y un piloto con más de 1,600 empleados [2]. La migración tampoco fue un solo evento de principio a fin: según TSB, se hizo por etapas (cajeros, pagos con tarjeta, hipotecas y la app móvil, entre otras), y lo de golpe fue el evento principal de migración de los datos de los clientes [2].

Es decir, no fue improvisación. Hubo planeación, ensayos y aseguramiento. Aun así, según el regulador prudencial británico (PRA) [1] (el propio TSB discrepa de algunos aspectos de la revisión independiente [2][5]):

• Todas las sucursales de TSB y una proporción significativa de sus 5.2 millones de clientes se vieron afectadas por los problemas iniciales.
• TSB tardó hasta diciembre de 2018 en volver a su operación normal.
• El banco ha pagado 32.7 millones de libras en compensaciones [1] a clientes que sufrieron un perjuicio.
• En diciembre de 2022, la PRA y la FCA impusieron conjuntamente a TSB una multa de 48.65 millones de libras [4].
• En abril de 2023, la PRA multó con 81,620 libras [1] al director de informática de entonces, por no haber asegurado que el banco supervisara de forma adecuada la subcontratación de su programa de migración de 2018. Entre otras cosas, según el regulador, no reevaluó con suficiencia las capacidades del tercero ni obtuvo el aseguramiento necesario sobre la preparación de la plataforma antes de dar garantías al consejo.

Hay dos lecciones para un comité, y ninguna es técnica.

La primera: la preparación declarada no sustituye el aseguramiento suficiente. El consejo tenía mucha documentación. Lo que el regulador cuestionó es qué tan sólido era el aseguramiento detrás de ella: según la PRA, el responsable no tomó medidas razonables para que el banco obtuviera suficiente aseguramiento del tercero sobre su preparación, ni consideró lo bastante si hacía falta indagar más antes de dar garantías al consejo [1]. Un «todo en verde» en una presentación no es lo mismo que ese aseguramiento.

La segunda: la responsabilidad puede llegar a personas, no solo a empresas. La multa al director de informática se dio bajo el régimen británico de responsabilidad individual de directivos; en México el marco aplicable es otro y cada institución debe verificarlo. El caso muestra que, bajo el régimen británico aplicable, la supervisión de un tercero puede derivar en responsabilidad individual además de sanciones a la institución; no permite trasladar automáticamente esa consecuencia al marco mexicano.

Lo que este artículo no hace también importa. El comité de una institución mexicana podría preguntar si aquí pasa lo mismo, pero aquí no se comparan sanciones ni incidentes mexicanos. Para una decisión concreta, la institución debe identificar el marco sectorial que le aplica y validarlo con sus áreas jurídica, de Cumplimiento y Riesgos.

Por qué el corte único concentra el riesgo

Martin Fowler, autor y referente de arquitectura de software, lo dice sin rodeos sobre los reemplazos de sistemas heredados: «hemos visto este plan de apariencia simple irse a pique la mayoría de las veces» (traducción propia) [3]. La razón que da es de negocio, no técnica: reemplazar un sistema serio lleva mucho tiempo, y mientras tanto los usuarios no pueden esperar nuevas funciones [3].

Traducido al lenguaje del comité, un corte único junta en un solo momento tres cosas que conviene separar:

1. El valor tiende a llegar al final. Durante años se invierte y el negocio no recibe nada que pueda medir. Si el proyecto se retrasa, no hay nada parcial que mostrar.
2. El riesgo se concentra en un solo día. Los clientes, las sucursales, los canales digitales, los pagos y las conciliaciones cambian a la vez. Si algo falla, puede fallar todo junto.
3. La vuelta atrás suele ser difícil o inexistente. Cuando los datos ya migraron y las operaciones del lunes se escribieron en el sistema nuevo, regresar al anterior deja de ser un botón y se vuelve otro proyecto.

Ver esos tres puntos en una hoja ayuda al comité a cambiar la conversación. La pregunta deja de ser «¿cuándo terminamos?» y pasa a ser «¿qué pasa si algo sale mal el día del corte y cuánto del negocio está expuesto?».

La alternativa: por etapas, con vuelta atrás

Fowler le puso un nombre a la alternativa, tomado de una planta que crece alrededor de un árbol hasta sustituirlo: la higuera estranguladora (strangler fig). La idea es sencilla de explicar a un comité: en vez de apagar el sistema viejo y encender el nuevo, se construye alrededor del viejo, pieza por pieza, y se traslada una función a la vez. Mientras se transfiere una función, el sistema anterior puede seguir atendiendo las que aún no se han trasladado, según el diseño de datos, la operación y los controles. Fowler, citando a Ian Cartwright, Rob Horn y James Lewis, menciona cuatro actividades (el orden en que se listan no implica una secuencia): entender los resultados que se quieren lograr, decidir cómo dividir el problema en partes más pequeñas, entregar esas partes con éxito y cambiar la organización para que esto pueda ocurrir de forma continua [3].

Y es honesto sobre el costo: construir esa capa transitoria puede parecer un desperdicio, pero «el menor riesgo y el valor más temprano del enfoque gradual superan su costo» [3]. Esa afirmación es su criterio, no una medición universal; por eso conviene que su comité la ponga a prueba con sus propios números, como se explica más abajo.

La diferencia práctica con el corte único se ve en una comparación:

La última fila importa. El camino por etapas no es gratis, y quien lo presente así pierde credibilidad ante un CFO.

La vuelta atrás tampoco ocurre sola. Que una etapa se pueda revertir es una propiedad que se diseña: qué función se traslada, cuánto tráfico recibe, qué señal indica que hay que regresar y quién tiene la autoridad para decidirlo. Hay etapas irreversibles legítimas, pero conservan una exposición concentrada dentro de su alcance y deben justificarse explícitamente ante el comité: qué las hace irreversibles, cómo se limita el daño y qué controles compensan la falta de reversión.

Cómo se presenta al comité

Para esta decisión, el comité puede priorizar tres cosas, en este orden, sobre el detalle técnico.

1. El riesgo, con su vuelta atrás

La pregunta que conviene responder en una página: ¿qué es lo peor que puede pasar en cada etapa, y cómo regresamos? Para cada etapa, tres datos: qué parte del negocio toca, qué indicador avisa que algo va mal y cuánto tarda regresar al estado anterior.

Escenario (ilustrativo, sin cliente). Una aseguradora con una póliza de gastos médicos que se administra en un sistema central de hace dos décadas decide empezar por las cotizaciones y no por las pólizas emitidas. La primera etapa traslada el cálculo de cotización a una pieza nueva, mientras el sistema central sigue emitiendo. Si la cotización nueva da resultados distintos a los del sistema actual en un porcentaje que el comité fijó de antemano, el tráfico regresa al cálculo anterior. Lo expuesto es una función, no la operación completa.

2. El costo de no hacer nada

Es la parte que con frecuencia se omite y que puede pesar más. Un comité que solo ve el costo de la modernización compara un número contra cero, y el cero suele ganar. Pero mantener el sistema actual también cuesta, y esa cuenta conviene hacerla con datos propios, no con cifras de terceros. No usamos aquí porcentajes genéricos de mercado sobre el presupuesto que se va a sistemas heredados o sobre el fracaso de reemplazos, porque no son necesarios para decidir este caso. La cuenta del comité debe salir de su propia contabilidad, de sus incidentes y de sus tiempos de cambio:

• cuánto se gasta al año en mantener, parchar y operar el sistema actual;
• cuánto tarda hoy lanzar un producto, una tarifa o un cambio regulatorio, y qué ingreso se aplaza mientras tanto;
• cuántas personas concentran el conocimiento del sistema y qué pasa si una se va;
• qué incidentes o cierres manuales atribuye hoy a limitaciones del sistema central.

Si el comité no tiene esas cifras, ese es en sí mismo el primer hallazgo y el primer entregable.

3. Hitos medibles, no porcentaje de avance

«Vamos al 60 %» es una frase que un programa de reemplazo puede decir hasta el día en que falla. Los hitos de una modernización por etapas se pueden medir en el negocio y no en el proyecto:

• qué parte del tráfico o de las operaciones ya corre por la pieza nueva;
• cuánto tarda ahora en salir un cambio de tarifa, de producto o de regla, frente a lo que tardaba al inicio;
• cuántas veces se ha ejercido y probado la vuelta atrás, y con qué resultado;
• cuánto cuesta mantener la capa de convivencia y en qué fecha se planea retirarla.

Este último punto evita un riesgo conocido de los enfoques por etapas: que la capa transitoria se vuelva permanente. Retirarla debe estar en el plan desde el primer día, con fecha y responsable.

La parte regulatoria no se deja para el final

Si una de las etapas implica mover funciones a la nube o a un tercero, los requisitos de su regulador forman parte del calendario, no son un trámite posterior. En México, la respuesta depende de la entidad y del tercero: las instituciones de crédito, las instituciones de fondos de pago electrónico, las aseguradoras y las afianzadoras tienen cada una reglas propias sobre la contratación y la supervisión de terceros, que pueden prever aviso previo o autorización según el servicio y el lugar donde se preste. Antes de autorizar una etapa, Jurídico y Cumplimiento deben confirmar la obligación, la autoridad, el expediente y el plazo aplicables. Tres preguntas concretas para llevarles: ¿esta etapa requiere aviso o autorización previa ante la CNBV o la CNSF?, ¿con cuánta anticipación?, ¿qué evidencia de aseguramiento del tercero espera ver documentada el regulador? La obligación, la autoridad competente y el plazo dependen de la entidad, la función, los datos, la ubicación del servicio y el tercero contratado. El caso de TSB ilustra que el regulador británico no solo preguntó si el sistema funcionaba: preguntó quién aseguró, ante quién y con qué evidencia [1].

Por eso conviene que cada etapa, al presentarse al comité, traiga adjunta una página de este tipo: qué se mueve, a quién se notifica, qué evidencia de pruebas existe y quién responde.

Cinco preguntas para su próximo comité

1. ¿Cuánto de nuestro negocio quedaría expuesto en el peor día de la primera etapa, y cuánto tardaríamos en volver al estado anterior?
2. ¿Tenemos cuantificado el costo anual de no modernizar, con datos de nuestra contabilidad y no de una presentación de proveedor?
3. ¿Qué evidencia independiente de pruebas de carga y de datos tenemos hoy, y quién, distinto de quien construye, la revisó?
4. ¿Qué hito del negocio, no del proyecto, vamos a ver en los primeros seis meses? Por ejemplo, una función corriendo por la pieza nueva con tráfico real.
5. ¿Qué órgano, función y persona responsable identifica nuestro marco aplicable para supervisar al tercero, y qué evidencia debe conservarse?

Si varias respuestas son «no sé», probablemente no falta un proveedor: falta información para decidir.

Por dónde empezar esta semana

Antes de autorizar un programa mayor, puede comenzar con una hoja con una sola columna de funciones del sistema central (alta de cliente, cotización, emisión, cobro, conciliación, reportes regulatorios) y, junto a cada una, tres marcas: cuánto cambia al año, cuántos otros sistemas dependen de ella y qué pasaría si se detuviera medio día. El comité puede calificar cada función con cinco criterios: valor de negocio verificable, dependencia con otros sistemas, reversibilidad, representatividad de datos y carga, y condición regulatoria. La primera etapa será la que tenga mejor equilibrio para su contexto, no necesariamente la más fácil; una función que no duele nada si se pausa puede dar un piloto sin relevancia. Con ese criterio, el comité tiene un orden que defender.

Qué hace Hábil

Hábil acompaña a organizaciones que necesitan decidir cómo modernizar sistemas centrales sin perder de vista continuidad, control y trazabilidad. Esa es la idea de la página Modernizar el core sin frenar el negocio; para unir sus sistemas y canales, la página Unificar su operación y sus canales.

La primera conversación de diagnóstico es sin costo y sirve para delimitar el sistema, la decisión pendiente y la información que su comité necesitaría para evaluarla. Escríbanos por WhatsApp.