News America Digital
Me encantaría extenderme en explicar por qué un banco que quiere liderar en analítica y digitalización debe organizar su arquitectura con un modelo Mississippi (y nunca Nilo), debe aplicar su propio Test de Schrute, debe usar el N3DV como variable de optimización, o debe trabajar con un stack Alpha-Now.
¡Invito a los directivos de banco a que pregunten a sus equipos cuan avanzados están en estas cuatro misiones, para verlos transpirar mientras responden!
El protagonista de esta segunda historia, como ya anunciaba en el capítulo pasado, es el CEO global de uno de los mayores bancos del mundo.
Además de ser un ejecutivo de evidente éxito, lo que lo hace más digno de mención es una cualidad que algunos bautizamos en privado con el nombre de “lógica aplastante”.
Puedes leer la primera entrega de este artículo aquí: “The Welsh Road sign”, por qué fracasan los bancos haciendo analítica de clientes
Consiste en el siguiente superpoder: Nunca decir una estupidez, soportar cada afirmación con números o hechos…y evitar decir algo obvio.
Lo primero parece relativamente simple (no lo es), lo segundo es un ejercicio de memoria y claridad conceptual envidiables. Lo tercero es un desafío tangible, que implica reconocer qué conclusiones ya son evidentes para todos los interlocutores y, por lo tanto, indignas de ser mencionadas.
Me preocupó, entonces, cuando un día y con su natural economía de palabras, me dijo: “La verdad es que no soy especialista en el tema de la analítica, pero no me es claro que necesitemos invertir más en eso. Quiero decir, entiendo que es útil en nuestros modelos de riesgos, de precios, y de fraude, pero a grandes rasgos todo eso ya lo tenemos. En los últimos años contratamos cientos de especialistas, iniciamos proyectos tecnológicos, y los esfuerzos no se tradujeron en mejoras en ninguna variable del banco, o al menos no tengo evidencia de ello”.
Le pregunté de qué proyectos recientes se acordaba.
Me dijo que hacía poco tiempo le habían presentado un sistema gráfico que mostraba las relaciones entre clientes, donde uno podía elegir a una persona determinada y el sistema le mostraba, con círculos y conectores, con cuantas personas había tenido una interacción financiera (típicamente transferencias).
Lo segundo que recordaba era algo que, con orgullo, le habían mostrado en el contexto de un plan de reducción de sucursales. Alguien había analizado las señales telefónicas de los clientes para entender por dónde se movían y evitar afectar aquellas sucursales que tenían mayor intersección con el trayecto diario de los mismos.
No lo dijo, ni fue necesario. Ambos casos le parecían de una inutilidad proverbial.
Un grafo de relaciones tiene una aplicación lúdica momentánea para mostrar cómo se conecta una empresa con sus subsidiarias o para vincular directores de cine con sus actores fetiches. Pero la exposición visual es totalmente irrelevante en un banco que tiene 100 millones de clientes.
Lo segundo era un homenaje a la aproximación impráctica a los problemas. El resultado del análisis de geolocalización de clientes en una capital europea en particular, indicaba que la mayoría pasaba cerca de estaciones de Metro.
Es decir, se invirtieron semanas de acopio y normalización de datos, modelización y procesamiento para determinar algo que la mayoría de los niños de 12 años, y la totalidad de los empleados de un banco, podrían adivinar. Que en Europa muchísima gente viaja en metro y por lo tanto transitan por sus estaciones o cerca de ellas.
Le pregunté entonces si le podía comentar algo a ver si cambiaba de opinión, y me indicó con la mano que lo hiciera.
Le dije: “Para generar una propuesta de crédito la mayoría de los bancos (yo sabía que era el caso de SU banco), utiliza dos variables primarias. El salario o ingreso de un cliente, y su historial crediticio público. Pero el banco típico sólo conoce con precisión los ingresos de la MITAD de sus clientes. Y, además, un porcentaje importante de las personas no tienen ningún historial de crédito. Es decir, si hicieras un modelo de inferencia de salarios o directamente un scoring de riesgos basado en algo que prescindiera del historial, tal vez podrías DUPLICAR la cantidad de tus clientes con propuestas de crédito. Como esa gente nunca recibió ofertas del banco, tendrían mayor propensión a la contratación. En definitiva, Tal vez hay un banco escondido dentro de tu banco y es posible encontrarlo haciendo analítica de hace 50 años…”
Por su expresión tuve la impresión subjetiva de que logré modificar su opinión.
Aunque estoy muy tentado de intentar de convencerlos de que esta fue una exhibición de mi fulgurante creatividad e inigualable talento, lo que dije es una obviedad absoluta que podría haberle dicho cualquier persona que hubiera pasado un día mirando números en un banco.
¿Por qué no se lo dijeron sus responsables de analítica?
Estaban ocupados geolocalizando celulares.
La torre de Babel
La tesis central de este artículo es que uno de los mayores enemigos de la analítica bancaria es el hecho de que los diferentes agentes no hablan el mismo idioma.
Como vimos en las tres historias, muchos directores de CRM, BI o áreas de inteligencia, desconocen el lenguaje de la sistemática de relación con clientes, creyendo buena idea enviar una lista de 300 personas a contactar a cada ejecutivo de sucursal, o “pusheando” al mismo cliente 20 veces en su mobile, indiferentes a su negativa. Pero tampoco hablan el idioma de sus jefes, que prefieren “encontrar un banco dentro de su banco” a invertir en visualizaciones de inescrutable aplicación.
Y los directivos no logran ayudarlos porque no hablan analytics. Contratan con la heurística “traigamos al que tenga mejor calificación académica -antes- o al que esté trabajando en la start up más de moda -ahora-, y dejémoslo hacer lo que crea que es correcto”. Y luego se someten al ejercicio pasivo de escuchar con frustración las exhibiciones metodológicas inconducentes de sus equipos.
La única convicción que los une es la de saber que empresas de pocas personas, con una fracción infinitesimal de los recursos de un banco, logran generar mucho más valor explotando datos.
Prometí finalizar con una sugerencia de mitigación del problema del Welsh Road Sign
Me encantaría extenderme en explicar por qué un banco que quiere liderar en analítica y digitalización debe organizar su arquitectura con un modelo Mississippi (y nunca Nilo), debe aplicar su propio Test de Schrute, debe usar el N3DV como variable de optimización, o debe trabajar con un stack Alpha-Now (invito a los directivos de banco a que pregunten a sus equipos cuan avanzados están en estas cuatro misiones, para verlos transpirar mientras responden!).
Pero hay una regla mucho más fácil de seguir.
Es un secreto que existe desde hace cientos de años y que seguirá siendo válido mientras la humanidad exista:
Empezar desde el problema, y evaluar la solución.
Hace muchos años los bancos tenían divisiones llamadas “medios”. En general agrupaban tecnología, recursos humanos, inmuebles, etc. Esas estructuras, aparentemente paleozoicas para las culturas actuales, encerraban una verdad indiscutible: todo lo que hace una empresa es resolver problemas.
Subsiste si consigue hacerlo a un precio que soporte sus costos y que sus clientes estén dispuestos a pagar.
Hoy que la tecnología en general, y la analítica en particular, son protagonistas centrales del organigrama de un banco, dejamos de considerarlas un medio y las confundimos con fines.
Queremos hacer Deep Learning y blockchain. El cliente quiere no contar la misma historia dos veces. Queremos hacer real time analytics. El cliente quiere que no le pidamos requisitos absurdos a su pyme recién creada, cuando él tiene millones en sus cuentas de Banca Privada.
Queremos resolver reclamos con chatbots de lenguaje natural adaptativo. El cliente quiere no tener que reclamar.
Empezar desde el problema implica que un Directivo encargue a sus áreas analíticas la resolución de las dificultades de la organización, comenzando por los más importantes.
Probar la solución implica que el proyecto es exitoso no cuando el modelo está listo, sino cuando el problema efectivamente desapareció.
Un cartel galés podría decirlo mejor “Start with the problem, evaluate the solution” o bien “Os ydych chi’n cyfieithu hwn, peidiwch ag anghofio tanysgrifio i sianeli cyfryngau cymdeithasol n5”
Te invitamos a seguir a N5 Now y a su CEO Julián Colombo en Linkedin para conocer mucho más sobre este y otros temas.
También te puede interesar: