Negocios en Internet

¿Porqué un nuevo programa bancario falla tanto? ¿Ineficiencia? La respuesta es si

Programas bancarios y problemas… Las noticias muestran transacciones incorrectas, cuentas inexistentes, cambios de números de cuentas bancarias obligatorias, retrasos y mala gestión en las cuentas. Esto es evidencia de un proyecto de software que salió mal debido a la mala calidad del trabajo. ¿Porque un programa bancario (core bank) falla tanto?

¿Puede un sistema de casi 100.000.000 de dólares fallar tanto? La respuesta es un rotundo NO, si se hace un trabajo eficiente. 

¿Por qué sucede esto y cómo podría haberse evitado? La causa podría surgir de una multitud de posibilidades, en este artículo exploramos algunas de las más probables, y las lecciones que podemos aprender de ellas.

Sistemas antiguos y migración

La mayoría de los bancos y grandes instituciones financieras utilizan software que fue escrito originalmente hace mucho tiempo, este tipo de sistemas han demostrado ser muy confiables. Llamamos a estos “sistemas heredados”. Estos sistemas estaban perfectamente adaptados a tecnologías que se utilizaban hace unos años atrás.

Con los cambios y nuevos requerimientos del día a día, el programa inicial se vuelve obsoleto, por ejemplo: hoy existen aplicaciones de celular que nos permiten ingresar a nuestro estado de cuenta y realizar transferencias instantáneamente, estas funciones no existían (o no eran tan comunes) hace 10 años atrás.

Mantenimiento de tecnologías heredadas

La mayoría de estos sistemas están escritos en un lenguaje de programación llamado COBOL. Una gran parte de los desarrolladores de COBOL se han retirado y hay muy pocos jóvenes que están entusiasmados por aprender estos lenguajes de programación muertos o moribundos. En consecuencia, hay una escasez de desarrolladores altamente cualificados para estos sistemas antiguos.

El riesgo lleva a la abstracción

Migrar los sistemas heredados a tecnologías más nuevas es difícil y arriesgado. La planificación y la implementación puede llevar años. La sustitución de un sistema base puede ser extremadamente complejo, generalmente se evita a toda costa este tipo de problemas.

Una táctica para permitir que los bancos avancen ofreciendo nuevas funciones a los usuarios, es envolver estos viejos sistemas usando una técnica llamada Abstracción.  Son tratados como una “caja negra” y no tenemos que preocuparnos por cómo funcionan, sólo tenemos que asegurar sus entradas y salidas. Esta técnica pospone la eventual necesidad de reemplazar estos sistemas.

Arquitectura y Complejidad de los Core Bank

A medida que se crean nuevos productos bancarios, cada vez más sistemas dependientes “cuelgan” el legado creando una imagen cada vez más compleja de cómo se mueven los datos entre estos sistemas. Los sistemas demasiado complejos pueden ser la causa de muchos errores. Una buena arquitectura de IT ayudará a combatir o contener esta complejidad y sus riesgos asociados.

Evolución del código de programación

Los sistemas que han existido durante mucho tiempo a menudo han sido retocados por muchos programadores a lo largo de los años. A veces hay poca transferencia de conocimientos de un desarrollador al siguiente. El programador nuevo no entiende lo que hizo el último y es reacio a cambiar el código existente, “por si acaso lo rompa”. Así que en vez de eso escribe un nuevo código para utilizarse junto al viejo. Ambos conjuntos de código probablemente hacen lo mismo, pero esta acción se perpetúa entre desarrollador y desarrollador y la “maraña” sólo crece y se hace más compleja.

Las pruebas por sí solas no son suficientes para garantizar la calidad

Los estudios de miles de proyectos de IT nos proporcionan hechos de que las pruebas por sí solas no garantizan que se hayan encontrado todos los errores. De hecho, en el mejor de los casos, las pruebas rara vez encontrarán más del 85% de los errores. Las pruebas deben complementarse con técnicas de mejora de la calidad que puedan identificar posibles errores incluso antes de comenzar las pruebas. Algunos de los más efectivos son el análisis estático y las revisiones formales que cubren los requisitos, la arquitectura, el diseño y el código.

Probar “que no hace” o “lo que no debe hacer”

Suponga que usted está haciendo una transacción en su aplicación bancaria, la conexión se pierde y sólo la mitad de la instrucción se envía al banco. ¿Cómo maneja el sistema del banco la mitad de una instrucción? Si ese sistema está conectado a un sistema existente, ¿cómo maneja el sistema existente una instrucción incompleta? Cada vez que hacemos un cambio de sistema siempre probamos que el nuevo sistema hace lo que se supone que debe hacer. También debemos asegurarnos de que no hace lo que no debería, este tipo de pruebas tiende a pasarse por alto.

Horario comprimido, tiempos inflexibles

No cabe duda que la labor para migrar este sistema se habrá sometido a varias pruebas. Con todos estos proyectos, sin embargo, el equipo habrá estado bajo cierta presión de tiempo para completar su trabajo en una fecha determinada. Plazos de entrega muy ajustados es una de las causas más comunes del fracaso de un proyecto de IT .

Habilidades Técnicas

La codificación es un trabajo creativo, que requiere habilidad y experiencia. Por ejemplo, hay muchas maneras de codificar el mismo resultado, un codificador puede lograr un conjunto de funcionalidades en sólo una o dos líneas, otro puede tener que escribir cincuenta. En general, el código más compacto tiende a ser de mayor calidad. Las habilidades de los desarrolladores varían dramáticamente, comparen a un cantante que es perfecto en afinación con otro que ni siquiera puede “acertar una nota”, ambos se llaman a sí mismos “cantantes”. Los desarrolladores de baja competencia pueden introducir más errores que correcciones o funcionalidad.

Presión empresarial para nuevos requisitos

La gerencia siempre está bajo presión para hacer crecer su negocio, y en algunos casos puede perder de vista la importancia de contar con sistemas estables y precisos cuando está bajo presión para ofrecer nuevas características y capacidades.

Nuestra conclusión: Posible Ineficiencia

1 – No tenemos una respuesta segura de que sucedió, pero sabemos una cosa, con las debidas pruebas se pudo haber evitado el desastre generado.

2 – El sistema utilizado es otro factor, ¿por qué no Temenos o Finacle ?

3 – Debilidad en la capacidad de resolución de problemas e implementación por parte de los involucrados

Contrariamente a las creencias de muchas personas, los errores en el software pueden predecirse y medirse. Usando métricas de software estándar.

La verdad es que la sustitución de los sistemas heredados es más que una simple responsabilidad de IT, en algunos casos es una cuestión de supervivencia para la empresa o institución.

Los clientes bancarios pueden ser tolerantes si su aplicación bancaria no está disponible por unas horas, pero no aceptarán saldos incorrectos o transacciones severamente retrasadas. Esto socava la confianza, y sin ella, los clientes se irán a buscar otras instituciones más serias y confiables.

Publicaciones relacionadas