Time to Market - Clave para sostener la ventaja competitiva en el sector financiero

Time to Market como factor clave de éxito en el Sector Financiero.

1. Síntomas comunes del problema.

Las instituciones financieras que sufren retrasos en llevar nuevas soluciones tecnológicas al mercado suelen mostrar varios síntomas claros. En primer lugar, ciclos de desarrollo excesivamente largos: proyectos que deberían tomar meses se extienden a años. Un estudio reciente en bancos encontró que, en promedio, se tarda 8,4 meses en lanzar un nuevo producto digital, y alarmantemente casi la mitad de los directivos bancarios admiten que “para cuando lanzan el producto, este ya está desactualizado”. En segundo lugar, incumplimiento habitual de plazos internos: más de la mitad de las instituciones han experimentado retrasos significativos (3 meses o más) en lanzamientos planificados durante el último año​. Estos retrasos generan un efecto cascada dentro de la organización, con la necesidad de reprogramar otras iniciativas. De hecho, un 64% de los bancos reconoció que los retrasos les obligaron a aplazar o cancelar otros proyectos en su portafolio ​[1].

Otro síntoma es la elevada frecuencia de sobrecostos y explicaciones al directorio. Equipos ejecutivos detectan el problema cuando constantemente deben aprobar presupuestos adicionales o convocar reuniones de emergencia por proyectos de TI atrasados. Un informe reveló que en dos tercios de los casos con demoras, se desperdician tiempo y recursos (retrabajos, horas extra)​, y en un porcentaje similar los responsables tuvieron que comparecer ante la junta directiva para explicar los contratiempos. Adicionalmente, se observa una respuesta lenta a movimientos competitivos: la organización va a la zaga de sus competidores Fintech o de banca digital. Por ejemplo, es típico que un banco tradicional lance una funcionalidad cuando un competidor ya ha capturado cuota de mercado con una solución similar. Internamente, esto suele venir acompañado de frustración en los equipos (tanto de negocio como de TI) por la lentitud de los procesos, altas tasas de rotación del personal técnico especializado, y una acumulación de “deuda de innovación” (ideas en el backlog que nunca ven la luz en tiempo útil). En resumen, time to market lento, proyectos continuamente reprogramados y pérdida de ventanas de oportunidad son síntomas inequívocos de este dolor organizacional​.

2. Efectos negativos de las demoras.

Los retrasos prolongados en la entrega de nuevas soluciones tecnológicas generan efectos adversos considerables en costo, competitividad y experiencia del cliente:

• Costos y rendimiento financiero: Un lanzamiento tardío usualmente conlleva sobrecostos. El esfuerzo adicional de desarrollo, pruebas y gestión aumenta el gasto más allá de lo presupuestado. Según una encuesta en bancos, 66% de los proyectos retrasados incurren en tiempo y dinero desperdiciados​. Además, posponer la salida de un producto implica un costo de oportunidad elevado: ingresos que se dejan de percibir mientras la solución no está disponible. En el estudio referido, los encuestados estimaron pérdidas acumuladas de unos £51 millones en ingresos por retrasos en un solo año​. Desde una perspectiva amplia, una entrega lenta erosiona la rentabilidad: se prolonga el periodo de recuperación de la inversión y puede afectar indicadores bancarios clave. Un informe advierte que los bancos que “no logren lanzar nuevos productos con rapidez verán reducirse sus márgenes de interés neto”, ya que no capitalizan a tiempo oportunidades de mercado para hacer crecer sus ingresos [1].

• Competitividad y posicionamiento de mercado: El entorno financiero es altamente dinámico, la rapidez es una ventaja estratégica. Los retrasos minan la capacidad de competir con Fintechs o con bancos líderes en digitalización. Si una entidad tarda demasiado en ofrecer un producto innovador, los rivales pueden adelantarse y capturar a los clientes deseados, reduciendo la cuota de mercado disponible. De hecho, 3 de cada 4 ejecutivos bancarios afirman que deben poder lanzar productos en cuestión de meses, no años, para sobrevivir en el mercado actual​. No cumplir con esa expectativa resulta en pérdida de relevancia: la marca comienza a percibirse como rezagada tecnológicamente. Incluso desde el punto de vista de cumplimiento estratégico, la lentitud puede atraer escrutinio de reguladores preocupados por la resiliencia e innovación de la entidad (51% de los bancos con retrasos reportaron mayor presión de los entes regulatorios ante dichas demoras)​ [1]. En resumen, cada retraso prolongado es una oportunidad para que un competidor gane terreno y para que el banco pierda posicionamiento y ventaja competitiva.

• Experiencia del cliente y fidelización: Quizás el impacto más crítico en el largo plazo es sobre la satisfacción y retención de los clientes. Hoy los consumidores financieros esperan iteraciones frecuentes de mejoras – nuevas funciones en la app móvil, procesos más rápidos, productos adaptados a sus necesidades. Cuando estas expectativas no se cumplen por retrasos internos, la experiencia del cliente se ve perjudicada. Los signos incluyen clientes frustrados por la falta de funcionalidades modernas o por la lentitud en la atención de sus necesidades. Según un análisis, la persistencia de sistemas lentos produce respuestas tardías y experiencias poco fluidas para el usuario​ [2]. Esto erosiona la satisfacción y provoca que algunos busquen alternativas más innovadoras. Un estudio global indicó que la banca está perdiendo uno de cada cinco clientes (20%) debido a una experiencia deficiente, al no ofrecer lo que realmente importa a los usuarios​ [3]. En otras palabras, la incapacidad de entregar mejoras a tiempo contribuye a una percepción negativa que deriva en deserción de clientes hacia competidores que brindan servicios más eficientes. También hay un impacto reputacional: los bancos que continuamente aplazan lanzamientos claves pueden ganarse fama de poco innovadores o poco centrados en el cliente, alimentando esa “fatiga de innovación” que les cuesta lealtad de su base de usuarios.

En síntesis, los retrasos reiterados encarecen la operación, reducen ingresos y ganancias, debilitan la posición competitiva de la entidad y degradan la experiencia del cliente – un trío de consecuencias (Costo, Competitividad, CX) que amenaza la salud del negocio financiero​. El costo del retraso no solo se mide en dinero, sino en valor perdido: oportunidades no aprovechadas, mercados cedidos y confianza de clientes erosionada.

3. Causas raíz de estas demoras.

Detrás de los retrasos en el Time-to-Market tecnológico en bancos subyacen causas raíz multidimensionales, que suelen agruparse en factores organizacionales, regulatorios y tecnológicos. A continuación, se exploran cada uno de estos ámbitos y cómo contribuyen al problema:

● Causas organizacionales y culturales:

Las estructuras y prácticas internas de muchas instituciones financieras tradicionales tienden a ralentizar la innovación. En primer lugar, la cultura corporativa bancaria típicamente es jerárquica y conservadora, optimizada por décadas para la estabilidad y el control de riesgos antes que para el trabajo colaborativo y la innovación. Esto provoca resistencia cultural a modos de trabajo alternativos. Los bancos suelen tener formas de trabajo muy arraigadas que chocan con la flexibilidad que exige la entrega continua de tecnología​ [4]. Por ejemplo, equipos acostumbrados a silos (departamentos de negocio separados de TI, cada uno con sus propios objetivos) pueden oponer resistencia a colaborar de manera transversal, obstaculizando iniciativas de transformación. De hecho, uno de los obstáculos más citados es la separación entre el negocio y el área de tecnología, lo que dificulta alinear a todos hacia una ejecución rápida​. Esta desconexión implica que las áreas de negocio no se involucran plenamente en el ciclo de desarrollo (o lo hacen muy tarde), y TI trabaja sin el feedback continuo del usuario final, generando rehacer y lentitud [5].

Otro factor organizacional es la gobernanza burocrática y orientada a cumplimiento. En bancos grandes, cualquier desarrollo de soluciones pasa por múltiples comités, aprobaciones secuenciales y documentación pesada antes de avanzar. Si bien estos controles buscan mitigar riesgos, terminan extendiendo plazos notablemente. Adicionalmente, puede haber falta de alineación y patrocinio desde la alta dirección. Sin un apoyo claro de liderazgo para priorizar la rapidez y aceptar ciertos riesgos calculados, los mandos medios tienden a optar por lo “seguro” que a menudo es más lento. Una encuesta de transformación en banca resalta que la falta de apoyo decidido de la dirección y la resistencia general al cambio son barreras frecuentes para implementar mejoras en la forma de trabajar​. Finalmente, aspectos de capital humano también inciden: muchas entidades financieras tienen una plantilla en TI con habilidades en sistemas tradicionales, y escasez de talento nuevo especializado en tecnologías emergentes​. Esta brecha de habilidades dificulta adoptar con éxito herramientas modernas o nuevos métodos, haciendo que los esfuerzos de aceleración no despeguen por completo.

En resumen, culturas aversas al riesgo, silos departamentales, procesos burocráticos y limitaciones de talento conforman un sustrato organizacional poco propicio para la adaptabilidad, convirtiéndose en causas raíz de los retrasos.

● Causas regulatorias y de cumplimiento:

El sector financiero está altamente regulado, y las exigencias regulatorias influyen directamente en la velocidad de lanzamiento de nuevas soluciones. Cada producto o función nueva debe cumplir con normativas de seguridad, privacidad, prevención de lavado de dinero, protección del consumidor financiero, entre otras. Esto introduce pasos adicionales y complejos en el ciclo de desarrollo:

• Revisiones extensivas de cumplimiento: Antes de lanzar, los equipos legales y de cumplimiento normativo deben revisar que la solución siga al pie de la letra todas las regulaciones aplicables (p. ej., Basel, GDPR, PSD2, leyes locales). Estas revisiones suelen ser manuales y detalladas, pudiendo tomar semanas o meses, ralentizando la salida al mercado​. En muchas instituciones, cumplimiento y riesgos se involucran muy tarde en el proceso (cuando el producto está casi listo), encontrando a veces incumplimientos que obligan a retrabajos y demoras importantes.

• Marcos regulatorios que no avanzan a la par de la innovación: Los reguladores, buscando estabilidad, a veces limitan temporalmente ciertas innovaciones hasta entenderlas bien (por ejemplo, servicios en la nube, criptomonedas, etc.). Los bancos pueden verse obligados a esperar aprobaciones o lineamientos específicos del regulador antes de lanzar ciertas funcionalidades. Esto es patente en servicios financieros innovadores donde la regulación va un paso atrás de la tecnología, creando incertidumbre y lentitud para no incumplir normas. Incluso regulaciones tradicionales (ej. requerimientos de reporte, capital, etc.) implican que cualquier cambio tecnológico deba ser evaluado respecto a su impacto regulatorio, añadiendo otra capa de complejidad.

• Procesos internos rígidos de gestión de riesgos: Ligado a lo anterior, internamente los bancos instauran comités de riesgo y auditoría que deben dar visto bueno a nuevas implementaciones, preocupados por no comprometer la seguridad o estabilidad. Si bien es crítico evitar fallos que afecten a clientes o incumplimientos, en la práctica estos procesos pueden actuar como cuello de botella. Un blog de la industria señaló que el cumplimiento regulatorio estricto suele convertirse en una “bottleneck significativo que frena el lanzamiento de nuevas ofertas”​ [6]. El 75% de los equipos de compliance en servicios financieros reportan una creciente presión regulatoria que hace sus aprobaciones más lentas y costosas​.

En suma, los bancos deben navegar entre mantener la innovación y no transgredir normas. La necesidad de proteger al consumidor y la integridad del sistema financiero puede venir al costo de la eficiencia: paperwork, validaciones y autorizaciones adicionales que, si no se gestionan proactivamente, se convierten en causas raíz de demoras significativas en los lanzamientos. Una de las grandes tareas es integrar cumplimiento de forma más efectiva, pero mientras eso no ocurra plenamente, los requerimientos regulatorios continúan siendo un factor estructural de retraso en el sector financiero​.

● Causas tecnológicas y técnicas:

La tercera capa de causas proviene del ecosistema tecnológico heredado y la infraestructura de TI típica de bancos establecidos. Varios elementos destacan:

• Sistemas legacy monolíticos: Muchos bancos operan sobre sistemas centrales (core bancario, mainframes) y aplicaciones desarrolladas décadas atrás. Estos legacy systems son fiables para la operativa diaria, pero difíciles de modificar o integrar con rapidez. Un informe indica que casi 90% de los bancos supervisados por el BCE dependen de al menos un sistema informático obsoleto en actividades críticas​ [2]. Esta realidad acarrea pobre adaptabilidad: es complicado lanzar nuevos productos rápidamente sobre esas plataformas rígidas​. Cualquier cambio menor requiere un esfuerzo enorme de desarrollo y pruebas para no romper la compleja madeja de interdependencias. Como resultado, el lanzamiento de funcionalidades innovadoras se ve limitado por la lentitud del sistema base.

• Arquitectura de TI compleja y fragmentada: Con los años, los bancos han ido sumando capas sobre sus sistemas básicos – por ejemplo, canales digitales encima del core bancario – creando un “espagueti tecnológico” difícil de gestionar​ [7]. Aplicaciones dispares, integraciones punto a punto y procesos duplicados entre silos provocan ineficiencias. Mantener esta arquitectura consume la mayor parte del esfuerzo de TI (se estima que los bancos gastan 78% de sus presupuestos de TI solo en mantenimiento de sistemas existentes​ [2]. Esto deja pocos recursos para desarrollos nuevos y alarga los tiempos, pues cada desarrollo debe navegar un entorno no simplificado. Las dependencias técnicas ocultas significan que un retraso en un componente se propaga a toda la solución.

• Deuda técnica acumulada: La “deuda técnica” son todos esos parches y soluciones provisionales implementados en el pasado para salir del paso, pero que nunca se refactorizaron correctamente. En banca, la deuda técnica es alta debido a inversiones tecnológicas de varias décadas​. Funcionalidades redundantes, código antiguo no documentado, múltiples versiones de la misma herramienta coexistiendo – todo ello ralentiza el ritmo al introducir incertidumbre y necesidad de saneamiento antes de avanzar. Si esta deuda no se aborda, cada nuevo desarrollo hereda parte del lastre, sufriendo retrasos imprevistos. McKinsey destaca que limpiar la pila tecnológica heredada es un prerrequisito crítico para ejecutar una transformación digital con ritmo, pero a menudo se subestima su importancia​ [5].

• Herramientas y procesos de desarrollo tradicionales: Históricamente, las áreas de TI bancarias seguían metodologías waterfall, con pocas automatizaciones en pruebas o despliegues. En muchos casos, aunque se intenta modernizar, persisten procesos manuales (por ejemplo, pruebas de QA extensivas sin automatizar, aprobaciones de cambios en cabina de control de forma manual) que alargan cada ciclo. Igualmente, la infraestructura on-premise tradicional implica que aprovisionar un nuevo entorno o ajustar capacidad puede tardar semanas, a diferencia de entornos cloud que serían instantáneos. Esta falta de elasticidad y automatización en la entrega técnica es una causa importante de por qué, aun teniendo buenas ideas, la ejecución técnica tarda tanto en completarse.

En resumen, la combinación de tecnología obsoleta, arquitecturas enmarañadas, alta deuda técnica y prácticas de desarrollo tradicionales constituye el núcleo técnico del problema. Los bancos que no han modernizado su plataforma tecnológica encuentran que, sin importar cuánto optimicen su gestión de desarrollo de soluciones, la plataforma en sí no les permite moverse rápido. Identificar y atacar estas causas (por ejemplo, mediante modernización del core, microservicios, automatización de pipeline, etc.) es clave para aliviar el dolor del retraso.

4. Soluciones existentes para acelerar el Time-to-Market.

Conscientes de este “dolor” del retraso, muchas instituciones financieras están adoptando soluciones y enfoques modernos cuyo objetivo es acelerar la entrega de valor tecnológico sin sacrificar calidad ni seguridad. Entre las principales estrategias destacadas se encuentran:

• Métodos y Frameworks Ágiles: La adopción de métodos/marcos ágiles como Scrum o Kanban, en la gestión de desarrollo de soluciones de software ha sido una respuesta clave para acortar ciclos de desarrollo. En lugar del antiguo enfoque waterfall (donde un proyecto pasa meses en análisis, luego en desarrollo, luego pruebas), la agilidad propone iteraciones cortas y entregables incrementales. Los equipos multidisciplinarios (incluyendo negocio, desarrollo, QA y operaciones) trabajan en sprints de pocas semanas para entregar funcionalidades utilizables continuamente. En el sector financiero, esto se traduce en que nuevas mejoras de canales digitales, por ejemplo, pueden liberarse quincenal o mensualmente en lugar de una vez al año. La colaboración cercana y la retroalimentación frecuente con usuarios permiten detectar desviaciones temprano y ajustarlas rápidamente, evitando grandes retrasos acumulados al final​. Muchos bancos han establecido equipos producto-plataforma para impulsar iniciativas específicas (banca móvil, onboarding digital, etc.) con notable reducción en tiempos de salida al mercado. Por ejemplo, ING y BBVA han reportado éxito convirtiendo gran parte de su organización a modelos ágiles, logrando lanzar versiones de productos en semanas​ [4]. En suma, Agile ataca las ineficiencias de proceso, permitiendo enfocarse en entregar valor rápidamente y ajustando prioridades según feedback continuo del cliente.

• DevOps y Automatización: Complementando a Agile, la filosofía DevOps integra el desarrollo y las operaciones de TI para optimizar el ciclo completo desde código hasta puesta en producción. En la práctica, DevOps introduce herramientas y prácticas como Integración Continua (CI), Despliegue Continuo (CD), pruebas automatizadas, infraestructura como código, monitoreo continuo, etc. Todas ellas buscan eliminar fricciones manuales en la ruta del software hacia el usuario final. En bancos que tradicionalmente tenían muros entre desarrolladores (que codifican) y operativos (que implementan en producción), DevOps rompe ese silo y fomenta la responsabilidad compartida. Implementar pipelines automatizados de build, test y deployment puede reducir dramáticamente el tiempo que toma llevar una nueva versión a producción de forma segura. Por ejemplo, el uso de CI/CD permite que cada pequeño cambio de código sea validado automáticamente en minutos u horas, en lugar de esperar a una ventana de release trimestral. Esto ha llevado a liberaciones mucho más frecuentes (diarias o semanales) en entidades que antes actualizaban sistemas quizá semestralmente​. Los beneficios están documentados: mayor eficiencia operativa y menor tiempo de comercialización de productos, dando a los bancos una ventaja competitiva al responder antes a las necesidades del mercado​. Además, DevOps aporta consistencia y calidad, ya que la automatización reduce errores humanos y asegura que requisitos de seguridad, pruebas y cumplimiento se apliquen de forma repetible en cada despliegue. En la banca norteamericana, por ejemplo, JP Morgan Chase ha sido pionero en incorporar Agile/DevOps a gran escala, logrando acelerar su delivery sin incrementar riesgo​. Cabe mencionar que DevOps también habilita respuestas más eficientes a cambios regulatorios: si una norma exige un ajuste en software, con pipelines automatizados el banco puede implementar la adaptación y desplegarla rápidamente en todos sus sistemas​ [8].

• Plataformas Low-Code/No-Code: Otra tendencia creciente es el uso de plataformas de desarrollo de bajo código para acelerar la creación de aplicaciones internas y de cara al cliente. Estas plataformas (como Microsoft PowerApps, Google AppSheets, Outsystems, Mendix, etc.) proporcionan entornos visuales y componentes preconstruidos donde se puede “programar” con poco código manual, lo que acelera el desarrollo hasta 5x o 10x más rápido en ciertos casos. En el sector financiero, los casos de uso abundan: desde apps sencillas para automatizar procesos de backoffice hasta prototipos de nuevas funcionalidades para clientes. La ventaja es que amplían quién puede desarrollar soluciones – analistas de negocio o usuarios avanzados pueden crear aplicaciones básicas sin esperar largos ciclos de TI. Gartner proyecta que para 2025, el 70% de las nuevas aplicaciones usarán tecnologías Low-Code/No-Code, frente al ~25% en 2020, señalando la fe en esta estrategia para reducir la fricción y acelerar la entrega. Ya hay bancos aprovechando Low-Code para, por ejemplo, lanzar rápidamente MVPs de nuevos servicios digitales y probarlos con usuarios antes de invertir en un desarrollo full. Las plataformas Low-Code modernas también se integran con sistemas legacy a través de APIs, lo que permite envolver sistemas antiguos con capas sin tener que reemplazarlos de inmediato. Eso sí, se tiene cuidado con gobernanza para evitar proliferación descontrolada de apps. En suma, Low-Code brinda una vía paralela para innovar con rapidez y menos dependencia de desarrolladores escasos, lo que resulta muy valioso dado que el talento en TI especializado es limitado en el sector [9].

• Modernización tecnológica (Cloud, MicroServicios, APIs): Más allá de métodos de trabajo, muchas soluciones pasan por actualizar la plataforma tecnológica para posibilitar rapidez. La migración a la nube es un habilitador importante: despliegues en cloud ofrecen escalabilidad bajo demanda y aprovisionamiento instantáneo de entornos, evitando esperas de hardware. También facilitan prácticas como blue-green deployments o canary releases para desplegar sin interrupciones. Deloitte destaca que el uso de infraestructura cloud pública o híbrida, junto con DevOps, acelera el Time-to-Market y reduce significativamente el tiempo y costo de implementar cambios​ [10]. Asimismo, rediseñar aplicaciones monolíticas hacia arquitecturas de microservicios y exponer funcionalidades vía APIs abiertas permite que distintos equipos trabajen en partes del sistema en paralelo y que integraciones con Fintechs terceras se realicen más rápido. Muchos bancos están creando plataformas abiertas (Open Banking) donde mediante APIs lanzan nuevos servicios en colaboración con Fintechs en meses, algo impensable en la banca tradicional aislada. Todas estas iniciativas técnicas – contenedores, automatización de pruebas, arquitectura modular – conforman un stack moderno que reduce drásticamente los tiempos de desarrollo, pruebas y lanzamiento en comparación con la plataforma legacy.

En conjunto, Agile, DevOps, Low-Code y la modernización de la plataforma representan un paquete de soluciones complementarias. No son excluyentes, sino que a menudo se implementan juntas: por ejemplo, un banco puede adoptar métodos/marcos ágiles y prácticas DevOps en sus equipos, al mismo tiempo que introduce una plataforma Low-Code para ciertos desarrollos y migra parte de su infraestructura a la nube. El objetivo final es el mismo: ganar velocidad y flexibilidad. Los resultados donde se ha logrado implementar exitosamente son prometedores – se reportan aumentos de productividad de desarrollo del 20-30% en 18 meses, reducciones de tiempos de lanzamiento de funcionalidades de varios meses a pocas semanas, y mejoras en la calidad percibida por el cliente gracias a entregas más frecuentes​ [11].

Por supuesto, cada institución adecúa la mezcla de soluciones a su realidad: algunas invierten fuertemente en crear una cultura empresarial; otras enfocan primero en cambiar su core banking hacia uno más moderno y flexible; otras establecen laboratorios digitales separados para innovar más rápido que la estructura principal. Pero en todos los casos la meta es mitigar el dolor que hemos descrito, haciendo que “la próxima gran idea” llegue a manos del cliente lo antes posible, antes de que la oportunidad se desvanezca.

5. ¿Por qué estas soluciones no siempre funcionan?

A pesar de la adopción extendida de métodos/marcos ágiles, DevOps y demás iniciativas, muchas instituciones financieras no están obteniendo todos los beneficios esperados en términos de aceleración del lanzamiento. Existen diversos obstáculos y brechas que explican por qué estas soluciones no terminan de resolver completamente el problema en la práctica de muchos bancos:

• Resistencia cultural y organizacional persistente: Transformar la cultura de una organización grande es un proceso largo. Aunque se introduzcan métodos y frameworks ágiles, “hacer agile” no es lo mismo que “ser agile”. En numerosos bancos, la alta dirección anuncia la adopción de Agile/DevOps, pero los mandos medios y equipos siguen atados a mentalidades tradicionales. Por ejemplo, puede que se implementen eventos ágiles (daily scrums, sprints) pero la toma de decisiones siga siendo lenta y centralizada, lo cual socava la agilidad real. La aversión al riesgo arraigada en la banca tampoco desaparece de la noche a la mañana; esto se traduce en que las experimentaciones rápidas que Agile/DevOps promueven muchas veces se frenan por temor a equivocarse. Un análisis señala que los bancos, por su naturaleza cautelosa, pueden tener dificultades para abrazar el enfoque iterativo y de experimentación, chocando con una cultura organizativa rígida y aversa al cambio​ [4]. Además, si el personal no recibe suficiente capacitación, es común que simplemente renombren roles (de “Jefe de Proyecto” a “Scrum Master”, por ejemplo) pero sigan operando igual que antes, en una especie de “agile de mentira”. Esta resistencia tácita impide que las iniciativas de mejora de velocidad alcancen su potencial.

• Silos y falta de alineación integral: Muchas instituciones implementan Agile en algunos departamentos, pero no logran escalarlo a nivel organización. Esto crea situaciones híbridas donde un equipo trabaja de forma ágil, pero depende de otro departamento (por ejemplo, seguridad, legal o arquitectura) que trabaja con procesos tradicionales. El resultado es que las ganancias de velocidad de un lado se ven neutralizadas por esperas en otro. Un síntoma típico es: “Desarrollamos la aplicación en un sprint, pero luego tardó 3 meses en pasar por aprobaciones de seguridad y cambios”. La falta de alineación transversal hace que las soluciones no funcionen plenamente porque la cadena sigue siendo tan fuerte como su eslabón más débil. Estudios de casos sugieren que sin un apoyo y coordinación desde la cima, donde se derriben silos y se involucre a todas las áreas en la transformación, las iniciativas Agile/DevOps quedan confinadas y su impacto es limitado ​[4].

• Restricciones de sistemas legacy y deuda técnica no resueltas: Agile y DevOps pueden optimizar cómo se desarrolla y despliega software, pero no pueden por sí solos arreglar un core bancario obsoleto. Muchos bancos se encuentran intentando ser ágiles sobre una base tecnológica inflexible. El resultado es frustrante: los equipos adoptan Scrum, automatizan pruebas, etc., pero cuando quieren desplegar cambios importantes, chocan con las limitaciones del sistema legacy que solo permite releases cada cierto tiempo o requiere paradas. Si la modernización de la plataforma no avanza en paralelo, los métodos modernos operan con un freno puesto. Por ejemplo, un banco puede tener excelentes prácticas DevOps en su banca digital, pero si esas aplicaciones siguen dependiendo de batchs nocturnos del core para actualizar datos, la entrega al cliente final sigue sin ser en tiempo real. Integrar DevOps con entornos legacy es difícil; muchas herramientas modernas no encajan bien con tecnología antigua, y el personal experto en legacy a veces no domina las nuevas prácticas. Esta fricción técnica reduce los beneficios obtenibles. En pocas palabras, la deuda técnica puede “comerse” las ventajas de Agile/DevOps si no se aborda: McKinsey advierte que ignorar la renovación tecnológica impedirá “ejecutar la transformación digital al ritmo necesario”​ [5], que es exactamente lo que vemos cuando estas soluciones no logran velocidad debido a cuellos de botella técnicos.

• Cumplimiento y riesgo no integrados al nuevo modelo: Otra razón es que los procesos de compliance y gestión de riesgo siguen operando al margen de Agile/DevOps en muchos bancos. Idealmente, prácticas como DevSecOps buscarían “Shift-left”, incorporando seguridad y cumplimiento desde el inicio en los procesos. Pero en la realidad, a menudo los equipos de cumplimiento normativo mantienen sus metodologías tradicionales de revisión exhaustiva al final, lo cual reintroduce retrasos. Un informe de Crowe remarca que involucrar a riesgo y cumplimiento solo al final “dificulta lanzar nuevos productos de forma rápida y fluida”, recomendando integrarlos desde el principio​ [12]. En numerosas instituciones financieras, esa integración profunda no ha ocurrido aún, sea por falta de herramientas (por ej., escasez de automatización en controles regulatorios) o por separación organizativa. Consecuencia: las iniciativas avanzan rápido hasta que llegan a la “muralla” del comité de riesgos, donde se detienen semanas. Mientras no se adapten también las funciones de control, las ganancias de velocidad serán parciales.

• Implementación superficial o incorrecta de los métodos/marcos: Algunas organizaciones adoptan Agile/DevOps como una moda, pero sin aplicar los principios correctamente. Por ejemplo, pueden adoptar Agile sin empoderar al equipo ni tener un Enfoque al Cliente claro, lo que termina en caos o retrabajo. O confundir velocidad con falta de procesos y provocar errores que luego demoran más. Si una transformación fracasa en sus primeros intentos (por mala implementación), puede generar cinismo organizacional y un retorno a los viejos hábitos, dejando las cosas peor que antes. Igualmente, el uso de Low-Code puede toparse con límites (no todo se puede resolver con Low-Code, y a veces las apps creadas así tienen problemas de rendimiento o escalabilidad, requiriendo intervención de TI tradicional). Sobrestimar las herramientas sin invertir en capacitación y cambio de procesos lleva a que los resultados no sean los esperados y la iniciativa pierda impulso.

• Problemas de coordinación en gran escala: En bancos de gran tamaño, escalar Agile y DevOps a cientos de equipos es en sí un desafío. Surgen inconsistencias en la adopción, dificultades para sincronizar dependencias entre múltiples equipos, y riesgo de desalineación estratégica. Sin un marco de escalamiento (como LeSS, S@S, SAFe u otros) bien aplicado, la organización puede derivar en decenas de equipos moviéndose rápido pero en direcciones distintas, lo que luego requiere reajustes que toman tiempo. Algunas instituciones se topan con “muros” al intentar escalar, y terminan reintroduciendo burocracia para coordinar, anulando parte de los beneficios. Gestionar este equilibrio es complicado y muchos bancos están a mitad de camino, con agilidad a nivel equipo pero sin lograr esa respuesta veloz de punta a punta que impacte al cliente final.

En conclusión, las soluciones existen y han probado su eficacia, pero “el diablo está en los detalles”. Muchas organizaciones financieras se encuentran en una transición incompleta: han incorporado nuevos métodos y tecnologías, pero no han removido todos los obstáculos estructurales que frenan su efectividad. Como describen expertos, implementar Agile/DevOps en banca requiere superar desafíos únicos: cultura arraigada, silos, cumplimiento estricto, sistemas legacy [4]. Si estos desafíos no se abordan integralmente, las iniciativas quedarán a medio gas.

Por eso vemos que, a pesar de 5-10 años de esfuerzos, todavía numerosas instituciones no alcanzan la velocidad deseada – “muchos bancos iniciaron transformaciones ágiles hace años, pero prácticamente todos han enfrentado dificultades similares” [13]. La clave es la perseverancia y un enfoque holístico: combinar la adopción de Agile/DevOps/Low-Code con un cambio cultural profundo, una reingeniería de procesos de gobierno y riesgo, y la modernización tecnológica necesaria. Las organizaciones que logran alinear estos frentes empiezan a superar el síndrome de los retrasos crónicos. Aquellas que no, seguirán experimentando que las soluciones prometidas “no les funcionan del todo”, hasta que ataquen las verdaderas raíces del problema. Como se suele decir en el sector: la agilidad no es un destino, sino un viaje continuo – y en ese viaje muchas instituciones financieras todavía están en camino, aprendiendo a liberarse de sus viejas inercias para finalmente ganar la carrera de la velocidad en la innovación tecnológica.

Referencias.

[1] Boosting Net Interest Margins: Why banks must not wait to innovate. https://saascada.com/insights/boosting-net-interest-margins-why-banks-must-not-wait-to-innovate.

[2] Digitalization of Banking System. https://em.bank/blog/fintech/digitalization-of-banking-systems/

[3] Banks are losing 20% of customers due to poor customer experience. https://www.10xbanking.com/news/banking-customer-experience-trends

[4] Agile Transformation in Banking: How to Overcome Common Challenges. https://www.greyamp.com/blogs/agile-transformation-challenges-banking

[5] Why most digital banking transformations fail—and how to flip the odds. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-forward/why-most-digital-banking-transformations-fail-and-how-to-flip-the-odds

[6] Faster Compliance, Better Financial Products for Everyone. https://blog.finspector.ai/faster-compliance-better-financial-products-for-everyone/

[7] Dealing with Slow Moving IT Problems in the Banking Industry. https://www.plektonlabs.com/dealing-with-slow-moving-it-problems-in-the-banking-industry/

[8] Agile and DevOps in banking today. https://bankautomationnews.com/allposts/agile-and-devops-in-banking-today/

[9] Faster Financial Software Development Using Low Code: Focusing on the Four Key Metrics. https://www.infoq.com/articles/financial-software-low-code/

[10] Fast and frequent value delivery: How financial institutions can harness the power of Agile, DevOps, and cloud to focus on progress, not perfection. https://www2.deloitte.com/content/dam/Deloitte/us/Documents/process-and-operations/us-agile-banking.pdf

[11] Cómo los bancos pueden potenciar la velocidad y la productividad de la tecnología. https://www.mckinsey.com/featured-insights/destacados/como-los-bancos-pueden-potenciar-la-velocidad-y-la-productividad-de-la-tecnologia/es

[12] Launch new bank products faster with integrated risk management. https://www.crowe.com/insights/launch-new-bank-products-with-integrated-risk-management

[13] What do you think of agile in the banking sector. https://www.reddit.com/r/agile/comments/10vl5hc/what_do_you_think_of_agile_in_the_banking_sector/?rdt=40254

Déjanos tus comentarios, dale like si te gusta y comparte si crees que pueda servir a alguien más. 

_______________________________________________________________________________________________________

Para mayor información escríbenos a: contacto@agilisters.com

WhatsApp: +52-5619976748

_______________________________________________________________________________________________________

¡Transforma tu organización con nuestra experiencia!

En Agilisters®, entendemos los desafíos que enfrentan las organizaciones al abordar nuevos paradigmas por cambios y disrupciones del mercado. Nuestro equipo de expertos en Agilidad de Negocios está para ayudarles. Juntos, podemos transformar su enfoque y preparar a su organización. 

¡Ponte en contacto con nosotros hoy mismo para obtener más información sobre cómo podemos apoyarles en enfrentar y superar los desafíos en su camino hacia la agilidad de negocios!

AVISO IMPORTANTE: Este es el blog de Agilisters.com, empresa privada que divulga y promueve la agilidad de negocios en LATAM