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:
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.
En la actualidad, los bancos se encuentran en una situación expectante, las nuevas regulaciones, y la llegada de una nueva generación de empresas que aprovecharon la tecnología de punta para ofrecer soluciones financieras más eficientes y efectivas que las brindadas por las instituciones financieras tradicionales.
Estos recién llegados se llevan gran parte del negocio que los bancos no querían o no podían hacer. Esta es la "desagregación" de los bancos y las fintech".
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:
Dos desafíos que pueden solucionarse con el desarrollo de una correcta plataforma omnicanal.
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, que usualmente no habían encontrado hasta ahora en la banca.
Si los bancos quieren adaptarse a las necesidades actuales, necesitan entender el potencial que tiene una plataforma omnicanal integrando servicios y productos que ofrecerán una gran experiencia de usuario. Pero a su vez, se debe asociar y colaborar con Fintech y empresas de TI, para adoptar rápidamente las tecnologías y nuevos servicios que permitan obtener un mayor nivel de transaccionalidad, ofreciendo la misma al cliente una experiencia integrada y sin diferencias respecto al canal que utilice.
Luego, actuar en consecuencia con una inversión en tecnología y en cultura empresarial apuntando a brindar experiencias financieras centradas en sus clientes y también en sus nuevos aliados.
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.
Cada banco cuenta con su propio equipo de tecnología. Un grupo de profesionales imprescindibles que siempre operan bajo presión:
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:
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.
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.
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.
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.
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.
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.
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.
Novedades
Eventos
Publicaciones
Talento
Podcast
Convocatorias