Imposible eludir el tema del día, del año, de la década y que quizá llegue a serlo del siglo: el coronavirus y sus efectos múltiples. La entrevista siguiente no es “virtual” sino real, aunque a distancia: fue concertada para hablar de software, pero inevitablemente se ha colado la crisis sanitaria. Los costes tecnológicos originados en la adaptación de los sistemas de información de la banca a las circunstancias han aumentado en una media del 15% por el volumen de transacciones que se ha desplazado de las oficinas a los canales web y móvil durante marzo y abril. Es un hallazgo indirecto de la herramienta de optimización del software bancario desarrollado por la empresa alicantina Orizon.

José Manuel Desco y Ángel Pineda

Seguirá aumentando y añadiéndose al crecimiento que era esperable en las condiciones normales. Más difícil de estimar es el empeoramiento de los tiempos de respuesta que, en su caso, pueden dañar la fidelidad de una clientela receptiva a las nuevas modalidades de servicio bancario. Así, pretendiendo rastrear el rendimiento de los sistemas de información, la herramienta de Orizon acaba identificando las repercusiones económicas de la pandemia. El lector debe ser advertido de que la conversación con Ángel Pineda y José Manuel Desco ha sido minuciosa,  rica en detalles y, en consecuencia, larga (lo que no es novedad en este blog).

Antes de transcribir el diálogo, parece justo reseñar que Orizon ha invertido más de 7,5 millones de euros y medio millón de horas de programación en el desarrollo de su tecnología, compromisos que ha soportado con recursos privados y con la suscripción de dos ampliaciones de capital, la última de ellas en 2019. Su plan de negocio prevé alcanzar en 2022 una facturación de 13 millones de euros y duplicar su plantilla hasta alcanzar los 42 profesionales.

¿Es correcto decir que Orizon se dedica a la optimización del rendimiento del software?

Ángel Pineda (Consejero Delegado). Sucintamente sí, es lo que hacemos. Hay una visión clásica en la que el software instalado en un sistema se optimiza cada cierto tiempo, en fechas determinadas, que a mí me parece como hacer dieta un día al año. Es evidente que las empresas, a partir de un cierto tamaño, no dejan de subir software continuamente durante el año. Por lo tanto, o bien la optimización es continua, tomando un mismo punto de medición aceptado por todos los integrantes del sistema – tanto los de desarrollo como los de producción – o, cuando vuelves a mirar, el rendimiento habrá bajado y los tiempos de respuesta tendrán un impacto negativo sobre los costes de infraestructura.

¿Cómo se hacía con aquella visión que llama clásica?

A.P. Cuando el entorno predominante y el número de horas de desarrollo no era ni remotamente el que es ahora, se hacían optimizaciones una vez al año, o cada seis meses, y se procedía a ajustar el sistema. Eso ya no puede ser así, porque no está en juego sólo el coste sino también el tiempo de respuesta en la interconexión de muchos sistemas. Un cliente de Orizon  ejecuta 750.000 procesos al día y tiene comprometidos 500 puntos donde entregar un dato: ¿cómo podría esperar seis meses para hacer un ajuste? Otro cliente tiene 9.000 operativas online diferentes […]

¿Tantas?

A.P. Entre 6.000 y 9.000 operativas diferentes es algo normal en un entorno bancario. Estamos hablando de un canal de oficina, un canal móvil y un canal web. En algunos casos se ejecutan entre 2.000 millones y cientos de miles de millones de transacciones anuales. Es la dimensión actual de los sistemas, con unos entornos tan cambiantes que hay que dedicarles muchas horas de desarrollo. Por eso es importante que quienes hacen desarrollo perciban que alguien está midiendo y detectando puntos problemáticos.

[…] y como resultado se obtendría una mejora del rendimiento.

A.P. Nosotros vemos el rendimiento como la suma de detección, resolución y metodología. Tradicionalmente, se podía decir: “probemos el software para que suba de la forma correcta`, y con esto se daba por seguro que el rendimiento sería óptimo. Luego se ha visto que se subía a producción, se volvía a subir y se volvía a subir […] con un enfoque puramente funcional, que las aplicaciones funcionaran. Pero si introduces el concepto de rendimiento, este incluye el consumo de recursos de infraestructura […] En la banca, por su tamaño y la delicadeza de su papel, sólo se puede reproducir previamente un porcentaje muy bajo, incluso menos del 1% de toda la funcionalidad que tiene un sistema cuando está en producción.

Antes de abundar en la actividad de Orizon, parece imperativo hablar del impacto de la pandemia sobre los procesos bancarios […]  

José Manuel Desco (Director General). Ya existía un canal digital con incrementos interanuales del 30% o más; que ahora subirá al 50% probablemente, a cortísimo plazo. El canal digital tiene una complejidad tecnológica sustancial para la banca, por lo que si antes había que hablar de performance, ahora habrá que hacerlo con más énfasis. En segundo lugar, han despuntado determinados procesos que – se suponía – no necesitaban optimización desde el punto de la operativa bancaria, pero de pronto han resultado ser clave, como la concesión de créditos: ha habido una avalancha de gestión de créditos financiados por el ICO (Instituto de Crédito Oficial)

Una tramitación sencilla para el cliente, pero el banco tiene que medir el riesgo en condiciones de urgencia

J.M.D. Como no eran de uso habitual, los créditos ICO se gestionan con software que las entidades no se preocupaban de optimizar, a diferencia de otras que utilizan masivamente en su operativa diaria En una visión de conjunto, estos cambios como consecuencia de la Covid-19 provocan que, en los procesos de consolidación nocturna, conocidos como batch, la banca haya registrado picos históricos de uso de sus sistemas centrales, los mainframe que soportan el núcleo de su negocio, a pesar de intentos todavía tímidos de trasladar aplicaciones a la nube. Habría un tercer elemento a considerar […]

¿Por qué ha tenido que venir una empresa de Alicante para que la banca española se interese por esta tecnología nacida aquí en lugar de una empresa de Detroit?  

A.P. Bueno, bueno… yo creo que la empresa de Detroit [risas] se preocupa exclusivamente del rendimiento en el entorno mainframe: extrae una traza del código fuente para dar pistas al cliente, que a este le son útiles pero falta un proceso de detección. Es totalmente cierto que los técnicos siguen distinguiendo entre los distintos entornos, pero cuando un informe tiene que llegar al CIO, o quizás más arriba, a estos les importa menos lo que diga la traza […] Lo que sí les importa es cuánto les cuesta el mainframe, cuánto el sistema distribuido o por la factura del cloud […] o  cuál es el tiempo de espera, esto es lo que importa a estas personas que nos contratan porque lo que ellos tienen son problemas finalistas […] La visión de un CIO tiene que mezclar todas las fuentes, que es lo que nosotros hacemos.

La próxima es para José Manuel, a quien conozco desde hace años. ¿Qué carencia había en el mercado que justifique la existencia de Orizon?

José Manuel Desco. Según mi experiencia, en las organizaciones españolas, incluso en muchas grandes, el modelo de desarrollo es laxo, o sea poco disciplinado. Me explicaré. Tenemos clientes en los que el número de diseños técnicos y funcionales es relativamente bajo dentro del ciclo de desarrollo. Y se intenta resolverlo con herramientas de calidad de software, con metodologías, etc. Está muy bien que se haga así, pero el rendimiento exige otro enfoque que permita diagnosticar rápidamente qué le está pasando al entorno en un determinado momento […]  Y esto, francamente, no se está ofreciendo: en el mercado hay herramientas excelentes pero creemos que les falta una dimensión global.

Cuesta creer que no haya conciencia de ese estado de cosas. Estamos hablando de la banca, nada menos

J.M.D. La verdad es que esa conciencia gana terreno, pero también que en muchas organizaciones observamos una cierta resignación […] A menudo proclamamos que el desarrollo de software es un modelo industrial, pero los datos demuestran que tiende a ser más bien artesanal. La consecuencia es que las infraestructuras tecnológicas se sobrecargan, lo que genera un coste asociado.

A eso se refería Ángel […]

J,M.D. Hablar de rendimiento hoy en día es hablar de algo que muchas organizaciones, lo digo sin señalar a nadie, parecen haber olvidado. El 80% de los problemas que se presentan con el software son redundantes, se repiten a lo largo del tiempo […] Nosotros aportamos una tecnología que permite identificar rápidamente dónde están los errores y cómo se pueden resolverlos a un coste razonable.

¿Esos errores están en el origen o en el trasiego constante que tiene todo software?

A.P. En algunos casos vienen del diseño de la base de datos, en otros de una mala aplicación de las metodologías. O simplemente de una falta de disciplina, como decía José Manuel. Hay que tener en cuenta que en un banco, el software muta cada dos años […]

Me quedo con la impresión de que hablamos de un nicho dentro de un nicho más grande pero que sigue siendo un nicho. ¿Por qué razón el caballo de batalla de Orizon es la banca?

J.M.D. Yo no diría que es un caballo de batalla ni tiene por qué ser único. La compañía ha nacido en el ámbito bancario por razones históricas, por la experiencia de personas determinadas. Lo bueno que tiene la banca como cliente es que se trata de gente está preocupada por la tecnología tanto desde el punto de vista del coste como del servicio. Piensa en sus infraestructuras, en sus arquitecturas; no está para probaturas. Por esto, es un entorno muy estable, un mercado maduro y que, además, es medible desde el punto de vista de los servicios que presta a sus clientes.

Me quedo con el adjetivo ´medible´ […]

J.M.D. Medible y estandarizado: hay una entidad, Aqmetrix, que se ocupa de analizar las prestaciones de servicio de decenas de entidades.

A.P. Me ha interesado la idea de que somos un nicho dentro de un nicho. Lo que hacemos es detectar problemas gordos y solucionarlos de manera muy transparente. Para mí, el ciclo de desarrollo tiene un fallo: con el paso de los años, ha seguido cogiendo velocidad y asegurando la funcionalidad de aquello que entrega. Pero las pruebas de rendimiento, que exigen una casuística muy rica, como las pruebas de interconexión y las de un entorno cloud en el que hay caminos críticos […] todo esto se ha ido dejando en manos de producción, donde no se pueden replicar.

¿Por qué no se puede?

A.P. Porque habría que replicar las infraestructuras, las interconexiones y una cantidad de reglas que estrictamente no corresponden a esa fase. En un banco cliente de Orizon, con 14 millones de clientes y 9.000 operativas diferentes, hay tal cantidad de procesos que, si alguien quisiera replicarlos como un proceso previo tendría que dedicarle muchísima logística y muchísimo dinero.

Acabado el desarrollo, ¿cómo se pasa a producción?

A.P. Acabado el desarrollo, si se descubre un fallo, la consecuencia sería una bajada de rendimiento. En realidad, no hay un procedimiento objetivo y formal que diga que el desarrollo no se ha acabado todavía. Esto es precisamente lo que hace nuestra herramienta BOA (Boost & Optimize Applications). Algo que podría expresarse así: ´tú déjame un día en producción y te diré si realmente has acabado el desarrollo`.

¿Qué se mide con BOA?

A.P. El papel de BOA es dar muchísima información diariamente, calcula todos los KPI (key performance indicator) que afectan al código que se ha subido a producción, con todas las métricas de cómo se comporta. A lo que José Manuel diría que todo lo que es medible lo es también en la cuenta de explotación.

¿Qué resultados entrega BOA al cliente?

J.M.D. Básicamente tres. El primero es el coste de la infraestructura que es consecuencia del mal funcionamiento del software; esto significa ahorros objetivos en el TCO del mainframe, en los sistemas medios e incluso en la factura del cloud. Esto es así: si el software funciona bien, los costes bajan. Lo segundo que reportamos son los tiempos de respuesta: si los clientes del banco no se pueden conectar o perciben que un servicio es lento o incompleto (o se corta), significa que la entidad corre riesgo de perder al cliente afectado. En tercer lugar, está el cumplimiento de los datos: si una red de oficinas no tiene cuando abre, a las 8 de la mañana, el informe comercial que se procesa en batch durante la noche, implica al menos dos cosas, que la red de oficinas funcionará mal esa mañana y que el Banco Central Europeo penalizará a la entidad por no haber recibido a tiempo la información preceptiva.

Ahora entiendo la mención inicial de Ángel a los 500 puntos de entrega de datos. ¿Son potencialmente vulnerables a un fallo del software?

J.M.D. Si los directores de oficina no los tienen a las 8 de la mañana, será porque algo funciona mal. Por ejemplo, una sobrecarga que deriva de ese mal funcionamiento o porque los procesos nocturnos no han acabado y al abrir las oficinas tendremos el online y el batch trabajando al mismo tiempo. Le prometo que no es una hipótesis teórica.

¿Orizon vende sus servicios sobre una metodología propia?

J.M.D. Y sobre una tecnología que es nuestra ponemos a disposición de nuestros clientes. Cuando metemos sus datos en un sistema, le enseñamos cómo salen en nuestro panel de control; somos absolutamente transparentes. Todo funciona en el sistema del banco, no en el nuestro: no necesita implantar nuestro software porque nosotros sólo necesitamos la traza, el rastro de lo que está ocurriendo. Y con ese rastro trabajamos.

¿Quién lo procesa?

A.P. Diariamente, exportamos información de las bases de datos Oracle o DB2, que básicamente son las que están en el catálogo mainframe. En el mundo distribuido, exportamos los servidores de aplicación y algunos frontales […] y también cierta información acerca del código. Con todo esto modelamos los costes en base a unas variables técnicas, modelamos los tiempos de respuesta con la fórmula aceptada por el cliente y también modelamos el cumplimiento de la entrega batch. Recibimos todo en BOA, que reside en nuestro propio cloud donde los clientes, por FTP o cualquier otro método envían la información. ¿Qué tipo de información? Métricas; no hay datos de clientes y por tanto no tenemos ningún problema de protección. Tampoco instalamos un agente en el sistema del cliente.

[…] Son métricas nativas

A.P. Exacto. Las combinamos para modelar qué procesos afectan a los costes, al tiempo de respuesta o al cumplimiento regulatorio.

¿Qué recibe el cliente?

A.P. Le devolvemos, de la última subida de software del anterior, un informe sobre qué procesos afectan a esos tres grandes bloques y cómo le afectan. Y le decimos qué líneas de código hay que sustituir por qué otras líneas de código. Cuánto se va a ahorrar y en cuánto estimamos el coste del cambio. En general, son mejoras sencillitas de implementar, porque se trata de errores de mala praxis o pequeños fallos de diseño; esto lo hacemos casi cada día.

¿Del informe se deduce una recomendación?

A.P. Efectivamente: decimos ´donde pone esto, póngase esto otro`.

Además de los entornos mainframe y en los distribuidos como Java. Oracle o SQL, que son el pan de cada día, ¿qué tratamiento merece el recurso de la banca al modelo cloud?

J.M.D. En la banca, el modelo cloud tiene determinadas limitaciones normativas derivadas de los acuerdos Basilea IV y Basilea V. Sin embargo, es una aspiración: todo el mundo espera que tenga menor coste y que sea más flexible.

¿Quiénes son los clientes de Orizon?

J.M.D. Lo único que puedo decir es que trabajamos con tres de los cinco primeros bancos españoles. Fuera de la banca, con compañías de seguros que son elementos parabancarios. Y que estamos intentando vender en otras industrias […]

¿Por ejemplo?

J.M.D. En mi modesta opinión, una que va a explotar es el sector retail, al que le vemos unos problemas de performance graves básicamente porque su cadena logística es muy compleja, con muchos partícipes y porque, como se ha demostrado con el coronavirus, los requisitos que plantea el comercio electrónico son parangonables a los que ha experimentado la banca.