Plataforma omnicanal: una base para la evolución tecnológica de la banca

‍

Para hablar de una plataforma omnicanal, primero debemos entender qué es la omnicanalidad.

Este concepto suele referirse a una estrategia de marketing para alinear los canales online y offline. Ofrecer la misma experiencia al cliente en todos los puntos de contacto.

Aunque esta forma de entender la omnicanalidad puede ser acertada, se queda corta cuando queremos entender el papel que juega en un banco. Es mucho más que una mera experiencia de marketing:

• Permite reducir tiempos de desarrollo, con el correspondiente ahorro en costos que esto implica.
• Genera menores tensiones entre las áreas de negocio, ya que facilita el trabajo, sobre todo, a los profesionales de TI.
• Mejora la capacidad de adaptarse ante cualquier imprevisto que pueda suceder, sin que el negocio tenga que paralizarse.

A lo largo de este artículo descubrirás cuales son las características de una plataforma omnicanal que pueda actualizar el negocio de la banca y adaptarlo a las necesidades de sus clientes.‍

Desafíos de la banca: ¿a qué retos se enfrentan estas organizaciones?

En la actualidad, los bancos se encuentran en una situación complicada a causa de la política conservadora respecto a la innovación.

Siguen anclados en los mismos procesos y temáticas de hace décadas y ahora han aparecido otros jugadores en el sector que están poniendo estas organizaciones contra las cuerdas: las fintech.

‍Estas empresas han llegado con propuestas innovadoras que solucionan muchas de las carencias que sufren los bancos y sus clientes.

La experiencia de Ginko trabajando con la banca nos ha permitido identificar cuáles son los dos grandes retos en los que se tiene que enfocar:

• Convertir al cliente en el protagonista.
• Dejar de replicar desarrollos para evitar errores y ahorrar en recursos.

Dos desafíos que pueden solucionarse con el desarrollo de una correcta plataforma omnicanal.
‍

Convertir al cliente en el protagonista

Mientras que la mayoría de los bancos han permanecido inmóviles ante los cambios que se desarrollaban en el sector, las Fintech y otras organizaciones se adelantaron.

‍Los nuevos actores de la industria de servicios financieros han puesto al cliente en el centro de la conversación.

‍Este enfoque «cliente céntrico» ha permitido a los usuarios disfrutar de una gran experiencia a nivel online y offline, que no habían encontrado hasta ahora en la banca de toda la vida.

Si los bancos quieren adaptarse a las necesidades actuales, necesitan entender el potencial que tiene una plataforma omnicanal cuyos servicios y productos ofrecen una gran experiencia de usuario (UX & CX). A su vez, que ofrezca la misma experiencia al cliente con independencia de cuál sea el canal que utilice.

Y después, actuar en consecuencia con una inversión en tecnología y en cultura empresarial que permita aprovechar estas oportunidades.
‍

Evitar errores y ahorrar en recursos

Cada vez que un banco necesita desarrollar un nuevo proyecto, lo entiende como un proyecto totalmente nuevo y aislado del resto de sus desarrollos, lo que implica que no aprovecha los conocimientos y el trabajo generado en procesos anteriores.

‍Lo más habitual es que existan una serie de procesos previos que se podrían aprovechar para solucionar el mismo problema.

Sin embargo, en lugar de ahorrar tiempo y dinero, están duplicando o triplicando los recursos invertidos.

‍Si en la entidad financiera existiera una unidad de desarrollo donde pudieran acceder a este tipo de procesos en forma de API (Application Programming Interface) el resultado se vería reflejado tanto en una mejor experiencia de usuario, como en una forma más eficiente de llevar adelante los desarrollos.

Las principales características de una plataforma omnicanal que da resultados

Cada banco cuenta con su propio equipo de tecnología. Un grupo de profesionales imprescindibles que siempre operan bajo presión:

• Asumen más tareas de las que pueden realizar en un día.
• Cuentan con presupuestos muy limitados para objetivos gigantescos.
• Se sienten al límite de energías y sufren de mucho estrés.

Que siempre se haya hecho así, no quiere decir que sea beneficioso para nadie. Ni para el banco, ni para quienes trabajan en él, ni para el usuario final.

Como te hemos contado hasta ahora, el principal problema es que cada vez que el banco tiene que realizar cualquier desarrollo, el área de TI tiene que comenzar desde el principio.

‍El esfuerzo y el tiempo requerido para desarrollar una idea y transformarla en algo concreto genera interacciones muy largas, y por supuesto consecuencias que repercuten en el famoso time to market (tiempo de lanzamiento que se tarda un producto o servicio desde que es concebido hasta que llega al usuario).

Algo que podría desarrollarse en cuestión de un par de semanas puede derivar en un trabajo de varios meses simplemente por este detalle.

Una buena plataforma omnicanal es una herramienta que, entre otras ventajas, permite replicar procesos.

Estas son las características que sí o sí debe tener:

• API abierta
• Escalable
• Componentes independientes
• Ambientes Cloud
• No lock-in (sin dependencia del proveedor o tecnología)

A continuación te contamos cuál es el papel que desarrolla cada una de estas características en relación al modelo de negocio de un banco.

‍

‍

API abierta

Una API abierta es una especificación que define el intercambio de datos o de funcionalidades de acuerdo a un estándar.

En cualquier operación (sea un framework, un lenguaje o un producto concreto) puede existir un API que esté construida de acuerdo a dicho estándar y que permita aprovechar desarrollos anteriores o facilitar desarrollos futuros.

Y lo más importante es que no solo se ahorra en estos tiempos de desarrollo o de inversión, sino que, además, permite acortar períodos de pruebas y QA, porque se entiende que proviene de un desarrollo que ya está funcionando.

Con un ejemplo siempre es más visible.

Hasta ahora, los bancos cuentan con los medios y mecanismos para transmitir información de un proyecto a otro. La tienen organizada en lo que se conoce como «bus de servicios».

‍Sin embargo, en la práctica no es usable. Este bus de información cuenta con tantos datos que necesita crear una API ad hoc para crear una lógica de negocio.

En el día a día habrá personas consumiendo los mismos datos del bus de servicios, con objetivos muy concretos, pero que tendrán que replicar los procesos. Procesos desarrollados a partir de API que después no podrán utilizarse de nuevo.

La API abierta es una solución. Cualquier desarrollo en el banco es susceptible de utilizar una API abierta. Un ejemplo claro son todas las operaciones relacionadas con el saldo.

Para esa misma opción se pueden desarrollar trabajos de lo más diversos aprovechando desarrollos anteriores.
‍

Escalable

La escalabilidad es una característica que hace referencia a la posibilidad de dar respuesta a demandas variables.

A grandes rasgos, implica poder pedirle más al sistema cuando existe una demanda creciente de usuarios, pero también exigirle menos —con el correspondiente ahorro— cuando se encuentre en un período de menor demanda.

Busca la flexibilidad: invertir más cuando sea necesario un empujón técnico y reducirlo cuando no sea así.

Un caso que ejemplifica esta situación es, de nuevo, el simple hecho de consultar el saldo.

‍Esta es una acción que es mucho más habitual a finales y a principios de mes, que es cuando la gente recibe su ingreso en cuenta.

En ese momento es fundamental que la plataforma omnicanal del banco esté preparada para aumentar (o reducir) automáticamente las capacidades técnicas y que no aparezca ningún problema.

‍

Componentes independientes

Puede parecer evidente, pero lo más importante de un componente independiente es que pueda ser desplegado de manera independiente.

Esto significa que a la hora de realizar una determinada funcionalidad para el negocio, pueda efectuarse sin la necesidad de afectar al sistema completo.

‍Pongamos dos situaciones de ejemplo para entender qué implica esta independencia.

Hay bancos que al tener que actualizar alguna parte del sistema, necesitan paralizar toda su actividad. 

¿El motivo? Cada uno de los componentes depende del resto. Por lo tanto, ninguna funcionalidad puede seguir activa si una de ellas no está en funcionamiento.

Con un componente independiente, el resto de los componentes, que también son independientes, podrán seguir operando con normalidad.

Lo mismo sucede con el caso de que exista una falla o un error. Para solucionarlo, no debería ser necesario paralizar todos los procesos —con las complicaciones para los usuarios que eso implica.

Si la falla se encontrase en un componente independiente, podría trabajarse sobre ella, inactivar su acción de forma exclusiva y que el usuario siga disfrutando del normal funcionamiento del sistema.

‍El objetivo es diseñar microservicios autónomos e independientes que después puedan beneficiarse de la flexibilidad de un sistema escalable.

‍Otro ejemplo muy habitual es el caso del inicio de sesión del usuario. La autenticación o log-in es una pieza clave en la plataforma online de la banca. Por eso es tan importante convertirla en un componente independiente con el que se pueda trabajar de forma aislada.

‍

‍

Diseñada para ambientes cloud

Los ambientes cloud pueden ser públicos o privados.

Un ambiente público es, por ejemplo, el de Amazon® o Microsoft®, a quienes se le puede pagar por una pequeña parte de su nube para montar un desarrollo.

Cuando hablamos de sistemas privados, nos referimos a bancos que montan su propio sistema de nube interna para conseguir los mismos objetivos. 

En Ginko estamos preparados para diseñar estructuras que permitan a las empresas operar de manera correcta en ambientes cloud, públicos o privados, a través de PSD.

‍Un tipo de ambientes que permite  disponibilizar los recursos, administrarlos, sin necesidad de desarrollarlos.

La clave se encuentra en que esta nube proveerá una capacidad de cómputo ilimitada. Es decir, permitirá dar siempre una respuesta inmediata a la demanda del usuario.
‍

No lock-in‍

Uno de los grandes problemas a los que se enfrentan muchas organizaciones es el lock-in tecnológico.

‍Es decir, el quedarse «atrapado» en una determinada arquitectura que ya no satisface las necesidades de los equipos de desarrollo y de la que tampoco se puede «escapar» porque el banco depende de ella.

Y al final el banco se quedaría «colgado» de un framework durante toda su vida. No tiene ningún sentido.

Con PSD, la arquitectura con la que te ayudamos a construir tu plataforma omnicanal, no existe ningún tipo de lock-in.

‍El banco puede dejar de usarlo sin perder nada de lo que haya desarrollado hasta ese momento, y reemplazarlo por otro servicio.

En Ginko creemos en el software evolutivo

Un software que, lejos de nacer y morir, cuenta con una vida completa de desarrollos.

Creemos en proyectos que acompañan a la propia evolución de la empresa y que se adaptan a las necesidades concretas en cada momento.

‍Contar con arquitectura evolutiva, con una buena plataforma omnicanal en el banco, es el primer paso para enfrentarse a los retos y a los desafíos que presenta el mundo actual.

Incorporar hoy las características de este tipo de arquitecturas, es asegurarse un lugar en el futuro. Un futuro cada vez más presente.

‍