Los responsables de negocio y los profesionales TIC de las entidades bancarias son perfectamente conscientes de esta situación, pero no lo son tanto de los costes añadidos que están asumiendo debido a los fallos y las deficiencias de su softwareque además de afectar a su operativa, impactan en el consumo de infraestructura y en el tiempo necesario para su resolución. Este consumo de tiempo y de recursos son costes que, en última instancia, acaban penalizando la cuenta de resultados.

En muchas entidades el servicio y el cliente significan sacrificar al negocio. Escuchando a CIOs y profesionales TI de la banca española, queda meridianamente claro que las áreas de TI han optado por no jugarse el servicio ni la satisfacción del cliente -interno y externo-, pero esa filosofía tiene inevitablemente un coste que requiere del visto bueno de las áreas financieras, del CEO y, en última instancia, de los Consejos de Dirección.

Ninguna de estas tres figuras estaría muy satisfecha de saber que el coste del collar para tener satisfecho al perro no deja de crecer y esto es justamente lo que está pasando y es también uno de los objetivos, al margen de crisis y activos tóxicos, de las operaciones de fusión.

Los datos no mienten. A pesar de la voluntad y el compromiso innovador de la banca, el gasto que asume el sector para mantener su negocio rodando sigue siendo superior al destinado a innovar. Ya lo era en 2008 con unas partidas del 49,3% y del 50,7% destinadas a innovación y mantenimiento, respectivamente; y en los últimos años el peso de la última partida no ha hecho sino seguir creciendo hasta situarse en la actualidad en alrededor del 40% y 60%, respectivamente. 

¿Qué hay detrás de esta abultada partida para el mantenimiento? La respuesta, de acuerdo con nuestra experiencia, es clara: el rendimiento tecnológico no es todo lo óptimo que debería y está lastrando la capacidad de los bancos para innovar.

A nadie se le escapa que el entorno tecnológico de un banco, especialmente el de los que no han nacido en el mundo digital y cuyas raíces se unen en el mundo mainframe, no es sencillo. Basta un dato: de media, en el periodo de un año, entre un 40% y un 60% de sus componentes técnicos cambia y, según nuestros datos, el 50% del total de componentes presenta alguna mala praxis. Y lo que es aún más preocupante, cuando se modifica o se actualiza el software, la mayoría de malas praxis persisten porque ni están identificadas ni existen mecanismos para su detección y modificación.

La problemática es generalizada con independencia de los entornos. Aunque es cierto que muchos de los nuevos bancos han nacido en el mundo digital y también que los más veteranos han migrado parte de sus aplicaciones a la nube, todavía hoy muchos de los procesos verdaderamente nucleares de la banca (onboarding de clientes, corebanking, gestión de cobros y pagos, riesgo y cumplimiento) acaban en el mainframe; el mal llamado ‘legacy’ teniendo en cuenta que estos denominados sistemas están en plena forma en muchas entidades a razón de sus garantías en términos de fiabilidad, escalabilidad y seguridad.

Como sabe muy bien IBM, todo lo que acaba en el mainframe tiene un coste que no es banal, y ocurre que lo que acaba en la nube también lo tiene, como bien saben AWS o MS.

Además, las carencias en materia de rendimiento no solo incrementan los costes, también impactan en otros indicadores clave como, por ejemplo, la disponibilidad. Las entidades siguen teniendo problemas de disponibilidad de alguna de sus operativas básicas con más frecuencia de lo que sería deseable y, además, estos fallos pueden tener un efecto multiplicador en momentos críticos en los que se disparan el número de operaciones, como se demostró durante la pandemia de la Covid-19 y todavía hoy sucede.

En la mayoría de los casos y, a pesar de que los bancos aseguran tener plenamente interiorizada la cultura de la calidad de software, los orígenes de estos fallos, errores y deficiencias se encuentran habitualmente en las arquitecturas y en el software, con la particularidad (Ley de Pareto) de que pocas casuísticas son responsables de la mayoría de los problemas. A esta situación se suma, además, un problema añadido que es la alta dependencia de los bancos de proveedores terceros, los responsables de las ineficiencias en gran medida.

Por otra parte, aunque las entidades financieras también disponen de una miríada de soluciones de monitorización y herramientas APM, no logran tener una visión única, completa y al detalle de lo que está sucediendo.

Automatizar la mejora continua del rendimiento

Como consecuencia de todo ello, al final del día, y de la noche, cuando se trata de rendimiento, la banca podría ganar más de lo que gana, porque hay un margen importante para el ahorro, que es justamente el fin último de una Central del Rendimiento – Oficina Técnica del Rendimiento como BOA (Boost & OptimizeApplications).

La plataforma BOA, que actualmente gestiona más de 500 millones de procesos de negocio -fundamentalmente en el sector de banca y seguros, tiene un triple objetivo: mejorar el rendimiento de las aplicaciones e infraestructuras TI a través de la detección y eliminación de problemas, incrementar los tiempos de respuesta y facilitar la reducción de los costes totales.

BOA opera en cinco fases que se retroalimentan (captura de datos, censo de procesos y de las detecciones diarias, análisis de los datos y detección de oportunidades de mejora, seguimiento del desarrollo y verificación del cumplimiento e impacto en los objetivos en base a una serie de KPIs) y en las que la automatización inteligente es cada vez mayor. En la actualidad, los algoritmos de BOA cubren el 79% de los problemas o malas prácticas, un punto importante si tenemos en cuenta, como mencionaba antes, que en el entorno TI las 50 casuísticas más comunes son responsables del 80% de los problemas.

Además de automatización e inteligencia para la mejora continua y la eliminación de las eficiencias que lastran el rendimiento, BOA proporciona una visión completa y orientada al negocio de lo que está sucediendo a través de dashboards o cuadros de mando, con KPIs o indicadores clave para los distintos perfiles: desarrollo, arquitectura, canal negocio, dirección y producción.

Se trata de que los problemas e ineficiencias no pasen desapercibidos o sean objeto de control, porque cuando este control no existe, el negocio está obligado, sin saberlo, a soportar unos sobrecostes -en costes de infraestructura y sobrecostes derivados de la reiterada modificación del software- que, según nuestra experiencia, rondan el 15% de las inversiones en tecnología, que no es poco.