5 errores en ciencia de datos que afectan a tu negocio

Conoce los cinco errores comunes que te impiden generar valor a tu negocio a partir de la analítica avanzada.

Cada vez más empresas adoptan la ciencia de datos. Pero muchas no han podido obtener valor comercial a partir de sus inversiones en big data, IA y machine learning.¹ Además, la evidencia sugiere que la brecha entre las organizaciones que han sacado ventaja y las que no se está ampliando. ²

Para comprender mejor los errores que se cometen al implementar la ciencia de datos y saber cómo evitarlos, estudiamos tres de los 10 principales bancos del sector privado de la India, identificamos los cinco errores más comunes relacionados con la analítica y sugerimos las soluciones correspondientes para resolverlos.

Error 1: obstinarse con una solución

Hiren, un científico de datos recién contratado por uno de los bancos estudiados, es la clase de científico que las organizaciones anhelan.³ Se especializa en el uso del algoritmo k-nearest neighbors, útil para identificar y clasificar grupos de datos. “Cuando era estudiante, lo usaba para clasificar simulaciones”, nos explicó. “No podía esperar para aplicarlo en casos reales”.

Hace unos meses, Hiren cumplió ese sueño, cuando utilizó dicho algoritmo para identificar segmentos industriales rentables entre la cartera de cuentas corrientes comerciales del banco. Su recomendación: elijan dos de los 33 segmentos. Esta solución decepcionó al equipo empresarial. Dado que ya conocían estos segmentos, podían determinar la rentabilidad de cada uno mediante cálculos muy sencillos. Utilizar el algoritmo k-nearest neighbors para esta tarea fue como usar un misil autodirigido cuando hubiera bastado sólo una pistola de agua.

En este caso, y en algunos otros que analizamos, el error consistió en aplicar la ciencia de datos por capricho, lo cual puede manifestarse de varias formas. Hiren no necesitaba una solución tan elaborada, pero en otras situaciones, vimos que los buenos resultados en un campo se utilizaron como excusa para aplicar la ciencia de datos en otro donde no era tan apropiada o efectiva. Sin duda, este error no surge de la ejecución técnica, sino de su mala aplicación.

Después de que Hiren comprendió mejor el negocio, regresó con una nueva propuesta: una vez más insistió en usar el algoritmo k-nearest neighbors, pero ahora a nivel cliente (no industrial). Como resultado, consiguieron nuevos insights para explotar segmentos desconocidos. El mismo algoritmo en un contexto más adecuado ofreció mucho mayores posibilidades de obtener valor comercial.

Parece evidente que las soluciones analíticas funcionan mejor cuando se desarrollan y aplican de acuerdo al contexto empresarial, pero descubrimos que para muchos gerentes no lo es tanto. Deslumbrados por el aura tecnológica, pierden de vista su contexto. Esto sucede con mayor frecuencia cuando una solución ha funcionado bien en un área o cuando lleva una etiqueta llamativa como “IA” o “machine learning”. Los científicos de datos, quienes manejan sólo la metodología analítica, no siempre pueden ofrecer una perspectiva más holística.

Para no caer en este error, los ejecutivos senior de nuestro estudio recurren a la capacitación. En un banco, los científicos de datos recién contratados deben tomar cursos sobre productos, cada uno impartido por expertos en el tema y trainees de gerentes de productos. Al mismo tiempo, el jefe de ciencia de datos ofrece capacitación a los gerentes comerciales de todos los niveles. El programa incluye conceptos básicos, con un énfasis en técnicas de solución específicas y casos de aplicación. En general, las intervenciones para abordar este problema tienen como objetivo facilitar la cruza de conocimientos entre científicos de datos, gerentes y expertos de área con el fin de que comprendan mejor el trabajo de los demás.

Asimismo, vimos que algunas empresas modificaron sus procesos para evitar decantarse por soluciones caprichosas. Una compañía aeroespacial de EU utiliza un método que denomina las Siete Vías, el cual propone que los distintos equipos identifiquen y comparen al menos siete posibles soluciones y luego justifiquen explícitamente su elección final.

Error 2: desconocer el origen de los datos

Pranav, científico de datos experto en modelos estadísticos, estaba desarrollando un algoritmo para recomendar clientes a los ejecutivos responsables de aprobar préstamos para PyMEs. Con base en los memorandos de aprobación de crédito (MAC) de los últimos 10 años, comparó la salud financiera de los prestatarios en el momento de su solicitud con su estado financiero actual.

En un par de meses, Pranav tenía una herramienta de software para soportar un modelo de alta precisión que implementó el equipo de financiamientos. Por desgracia, seis meses después, las tasas de morosidad aumentaron. Perplejos, los gerentes senior asignaron a un ejecutivo experto para que trabajara con Pranav y juntos averiguaran qué estaba sucediendo.

La epifanía se produjo cuando el ejecutivo descubrió el origen de los inputs. Pranav no sabía que los MAC estaban preparados sólo para préstamos preseleccionados, con buenas probabilidades de ser aprobados. Es decir, que los datos de las solicitudes de préstamo rechazadas no se utilizaron para el modelo, por lo cual había un sesgo de selección. Así, Pranav no consideró un criterio decisivo: los cheques sin fondos. Como era de esperar, había muy pocos cheques sin fondos entre los prestatarios preseleccionados.

La solución en este caso fue fácil: Pranav agregó los datos sobre las solicitudes rechazadas en preselección y el parámetro “cheques sin fondos” se convirtió en un elemento clave de su modelo. La herramienta funcionó según se esperaba.

Lo complicado para las empresas es identificar las fuentes de datos antes de aplicar los modelos analíticos. Esto es un desafío porque los legos, e incluso los mismos expertos, no siempre saben cómo el modelo arroja outputs. Y cuando los expertos entienden el funcionamiento del modelo en cuestión, no reconocen los sesgos en los datos que utilizan.

Los bancos de nuestro estudio evitan este error al exigir que los científicos de datos se familiaricen más con las fuentes que utilizan. Por ejemplo, un científico siguió los procesos de un gerente para identificar los datos necesarios que garantizaran los resultados que buscaba. Y también vimos que un equipo mixto implementó un proceso formal, mediante el cual identificaban posibles variables y sus respectivos orígenes para buscar sesgos. El objetivo era cuestionar los supuestos y “limpiar” los datos, evitando así problemas a causa de las circunstancias en las que se crearon o recopilaron.⁴

Error 3: solución adecuada, timing equivocado

Kartik, científico de datos experto en machine learning, tardó un mes en desarrollar un modelo para analizar el desgaste de las cuentas de ahorro del banco para el que trabaja y luego pasó tres meses más ajustándolo para mejorar su precisión. Cuando presentó su modelo, el equipo de productos estaba impresionado, pero no lo implementaron porque ya habían gastado su presupuesto anual.

Ansioso por no volver a fallar, el año siguiente Kartik presentó su modelo antes de que comenzara el ciclo de presupuestación. Pero ahora la instrucción no era retener cuentas, sino adquirirlas. Una vez más, el proyecto quedó sin apoyo. Finalmente, el tercer año Kartik consiguió la aprobación, pero perdió el entusiasmo: “Ahora quieren implementarlo”, nos dijo consternado, “¡pero el modelo se ha deteriorado y tendré que volver a construirlo!”

El error en casos así es la poca sincronía entre la ciencia de datos y las prioridades y procesos del negocio. Para evitarlo, es necesario vincular los departamentos en términos espaciales, estructurales y administrativos. 

Por ejemplo, un banco incluyó científicos de datos en los equipos comerciales por proyecto. De esta manera, los científicos se codeaban con el equipo empresarial día a día, por lo que eran más conscientes de sus prioridades y plazos y, a veces, lograban anticipar sus necesidades. Asimismo, vimos que se ha puesto a ambos equipos a trabajar en un mismo espacio, que sigan un mismo proceso o que los científicos de datos participen en las reuniones y actividades del equipo comercial.

En términos generales, los científicos deberían concentrar sus esfuerzos en los problemas más importantes para la empresa.⁵ Pero existe una salvedad: a veces, la ciencia de los datos produce insights inesperados que deberían captar la atención de los líderes senior, independientemente de si se alinean con las prioridades actuales.⁶ Por lo tanto,  si surge una idea desalineada, pero que, no obstante, podría brindar un valor significativo a la empresa, es responsabilidad de los científicos de datos comunicarlo a la gerencia.

Descubrimos que para facilitar este trabajo exploratorio, los ejecutivos bancarios solían asignar científicos adicionales a cada proyecto, cuya única tarea es encontrar soluciones alternativas. Si estas resultan viables, el jefe de analítica las presenta a la alta dirección. Este enfoque dual reconoce la interdependencia epistémica entre la ciencia de datos y los profesionales de negocios, en un escenario en el que la analítica busca resolver las necesidades comerciales, detectar oportunidades para innovar y transformar las prácticas comerciales vigentes.⁷ Ambos roles son importantes para extraer el máximo valor comercial.

Error 4: herramienta adecuada, usuario equivocado

Sophia, analista de negocios, trabajó con su equipo para desarrollar un motor de recomendaciones capaz de ofrecer nuevos productos y servicios a clientes específicos del banco. Con la ayuda del equipo de marketing, agregaron el motor a la aplicación móvil del banco, la banca por internet y los correos electrónicos. Pero nunca pudieron materializar el proyecto: los clientes no aceptaban las sugerencias como se había anticipado.

Para descubrir por qué, telemarketing encuestó a una muestra de clientes renuentes a comprar los nuevos productos. El misterio se resolvió en seguida: los clientes dudaban de la credibilidad de las recomendaciones virtuales.

Sintiéndose insatisfecha, Sophia visitó varias sucursales del banco y, sorprendida, descubrió cuánta confianza tenían los clientes en los ejecutivos de cuentas. Realizó algunos experimentos informales y se convenció de que era mucho más probable que los clientes aceptaran las sugerencias del nuevo modelo, si un ejecutivo se las presentaba. Cuando supo que el problema no era técnico, sino de aplicación, Sophia se reunió con gerentes senior de distintas sucursales y propuso relanzar el motor de recomendaciones como apoyo para ejecutivos. La iniciativa fue un rotundo éxito.

Esta clase de inconvenientes destacan la necesidad de prestar atención a cómo se comunican y utilizan los outputs de analítica. Por lo menos, las pruebas de usuario deben ser una parte explícita del ciclo vital de un proyecto. O mejor aún, la ciencia de datos podría desarrollarse dentro de un marco de diseño centrado en el ser humano, pues no sólo debe considerarse su experiencia, sino que en algunos casos puede convertirse en el foco principal de un proyecto.

Si bien no hallamos casos en donde la analítica se integrara al diseño u otras prácticas concentradas en el ser humano, el shadowing de los procedimientos descritos puede funcionar como una especie de análisis de experiencia del usuario. El shadowing, es decir observar el proceso natural del usuario o de los compañeros de trabajo, contribuye a un mejor entendimiento de los mismos datos, los usuarios y los canales más adecuados para entregar soluciones.

Error 5: descuidar la implementación

La iniciativa de “recuperación” de un banco, que tenía como objetivo recuperar clientes perdidos, no mostraba resultados desde hacía meses. Y la reunión entre científicos de datos y gerentes de producto, en donde iban a reajustar la iniciativa, tampoco fue bien.

Dhara y Viral, científicos de datos, querían enfocarse en cómo identificar clientes con mayores probabilidades de regresar al banco, pero los gerentes Anish y Jalpa querían hablar sobre la próxima campaña y estaban presionándolos para que asumieran su implementación inmediata. Después de la reunión, Viral expresó su frustración a Dhara: “Si los científicos y analistas hacen todo, ¿por qué el banco necesita gerentes de producto? Nuestro trabajo es crear soluciones, el suyo ejecutar”.

Sin embargo, en la siguiente reunión, Viral parecía haber cambiado de opinión. Se esforzó en comprender por qué los gerentes seguían insistiendo en que ellos asumieran la responsabilidad por implementar el modelo. Descubrió que muchas veces antes, el área de sistemas les había dado listas de clientes que recuperar, sin ningún resultado positivo. Usar las listas era todo un reto, en parte porque era casi imposible rastrear a los clientes, así que los gerentes tenían esa actitud porque anticipaban un fracaso más.

Lee también: El rol de la Nube y la ciencia de datos en el ecosistema financiero

Habiendo entendido el contexto, Viral y Dhara agregaron una aplicación front-end para el telemarketing del banco, la administración de correos electrónicos, el personal de sucursales y los equipos de recursos. Así, todos contaban con una herramienta que alimentaba las listas de analítica con información real de sus interacciones con clientes y, finalmente, el proyecto avanzó.

Actuar como Viral y Dhara requiere de mucha empatía e iniciativa. Dejaron de lado sus papeles de científicos de datos y actuaron como líderes de proyecto. Pero las empresas no tendrían por qué obligar a sus empleados a proceder así y quizá ni siquiera sea recomendable. No sólo sería desperdiciar la experiencia técnica de los científicos, que representa un recurso escaso y costoso, sino que se pierde tiempo y desgasta las relaciones laborales.

En cambio, las organizaciones pueden involucrar científicos de datos en la implementación de soluciones. Un banco de nuestro estudio probó añadiendo un estimado del valor comercial generado a partir de las acciones de los científicos de datos en sus evaluaciones de desempeño. De este modo, los motivó a garantizar la implementación de sus propuestas. Los ejecutivos reconocieron que, en consecuencia, los científicos operaban fuera de sus responsabilidades asignadas, pero consideraron que la entrega de valor justificaba el desvío de recursos y que podría corregirse caso por caso, si es que las responsabilidades principales de los científicos de datos se veían demasiado afectadas.

LOS ERRORES QUE IDENTIFICAMOS ocurrieron invariablemente entre las áreas de analítica y el resto de la compañía. Esto sugiere que se debería promover la ciencia de datos como un concepto más amplio al interior de las empresas para fomentar la coordinación entre esta área y el diagnóstico de problemas, la administración de procesos y la implementación de soluciones. Se pueden vincular e integrar mejor los equipos de analítica mediante la capacitación, el shadowing o la oferta de incentivos formales. Los beneficios van desde la reducción de fallas hasta ciclos de proyectos más cortos y, por supuesto, la consecuente obtención de un valor comercial más alto.

REFERENCIAS
1. R. Bean and T.H. Davenport, “Companies Are Failing in Their Efforts to Become Data-Driven,” Harvard Business Review, Feb. 5, 2019, https://hbr.org.

2. T.H. Davenport, N. Mittal, and I. Saif, “What Separates Analytical Leaders From Laggards?” MIT Sloan Management Review, Feb. 3, 2020, https://sloanreview.mit.edu.

3. The names of people and organizations are pseudonyms, in keeping with our agreements with the companies.

4. S. Ransbotham, “Deodorizing Your Data,” MIT Sloan Management Review, Aug. 24, 2015, https://sloanreview.mit.edu.

5. T. O’Toole, “What’s the Best Approach to Data Analytics?” Harvard Business Review, March 2, 2020, https://hbr.org.

6. S. Ransbotham, “Avoiding Analytical Myopia,” MIT Sloan Management Review, Jan. 25, 2016, https://sloanreview.mit.edu.

7. P. Puranam, M. Raveendran, and T. Knudsen, “Organization Design: The Epistemic Interdependence Perspective,” Academy of Management Review 37, no. 3 (July 2012): 419-440.

LA INVESTIGACIÓN

Este artículo se basa en un profundo estudio sobre la analítica de datos aplicada en tres grandes bancos indios del sector privado, con activos colectivos que superan los 200 millones de dólares.

El estudio incluyó observaciones in situ; entrevistas semiestructuradas con 57 ejecutivos, gerentes y científicos de datos; y el análisis de registros de archivo.

Los cinco obstáculos y sus soluciones surgieron de un proceso analítico inductivo basado en datos cualitativos.

Las pruebas de usuario deben ser parte explícita del ciclo vital de un proyecto, incluso en algunos casos puede convertirse en su foco principal.

POR MAYUR P. JOSHI, NING SU, ROBERT D. AUSTIN Y ANAND K. SUNDARAM

Síguenos en Google News