Susana Fuentes

Análisis de datos para la

toma de decisiones
Qué hacer para fracasar

OBS Business School 1

Índice
Introducción......................................................................................... 3
Qué hacer para fracasar en una iniciativa de datos ............................... 3
No lograr el apoyo de todo el equipo ejecutivo ...................................................... 3
No prever los cambios en los requerimientos previos ............................................ 4
No gestionar adecuadamente el volumen y multiplicidad de los datos ................... 4
No lograr la utilización por parte de los usuarios finales ........................................ 5
No mantener el foco en la misión del negocio ........................................................ 5
No conseguir superar el spreadmart ...................................................................... 5
Problemas con la calidad de los datos .................................................................... 6
No estar abiertos a cambios en las herramientas ................................................... 7
Externalizar demasiado conocimiento .................................................................... 7
Plazos no realistas con presupuestos no realistas.................................................. 7
No consensuar la versión de la verdad ................................................................... 8
Ausencia de estrategia de business Intelligence .................................................... 8

Qué hacer para fracasar en una iniciativa de Big Data/Machine Learning

............................................................................................................ 8
Comenzar con machine learning sin un objetivo concreto ...................................... 8
Esperar a los datos perfectos ................................................................................. 9
Creer que se tienen datos perfectos ....................................................................... 9
Pensar que la herramienta es lo principal .............................................................. 9
No involucrar lo suficiente al factor subjetivo ........................................................ 9
No tener en cuenta que cualquier resultado tiene que ser operativizado ............. 10
Asumir que todos entienden los resultados .......................................................... 10

Conclusión .......................................................................................... 12

OBS Business School 2

Introducción
Estos días atrás estamos viendo muchos de los pasos a dar necesarios para poder extraer
valor real a la información que maneja una compañía.

Hemos visto cómo es necesario tener una planificación alineada con la estrategia corporativa,
cómo es importantísimo obtener los apoyos y los recursos y que nada se lleva a cabo si no se
le percibe un beneficio.

Aun así, el uso correcto de la información es un camino complicado y lleno de trampas.

Conviene conocerlas para saber esquivarlas y, llegado el caso, saber r econducir la situación.

Recientemente, Gartner señaló un estudio que pretendía demostrar que “entre el 70% y el
80% de los proyectos de datos fallan.” Esta proporción es increíblemente alta si le damos
crédito y puede llegar a desmotivar. El 70% al 80% es una proporción inusualmente alta de
proyectos que no cumplen con sus objetivos. Especialmente, si se toma en cuenta que
business intelligence, es una disciplina bien establecida en las grandes organizaciones.
Además, gran parte de los requerimientos actua les de datos son reportes de consultas pre
establecidos que se aplican en ciertas épocas del año.

Considerando que, desde hace 20 años business intelligence es una estrategia cuya primera
misión es hacer informes, ¿qué puede ser tan formidable para no logr ar llegar a sus metas en
un 70-80% de las veces?

También según Gartner, el fracaso no viene motivado únicamente por una causa sino por
varias. Hagamos un repaso de los riesgos que ver dónde se esconden las trampas.

Qué hacer para fracasar en una iniciativa de datos

No lograr el apoyo de todo el equipo ejecutivo

Lograr que todo el cuerpo ejecutivo apruebe y apoye la instauración de tecnologías

relacionadas con la Inteligencia del Negocio es un paso imprescindible si se quiere disponer
de ciertas garantías de éxito.

Salvo que se haya hecho una previsión excepcionalmente escrupulosa de los requerimientos
técnicos, económicos y humanos, lo más probable es que surjan problemas durante el proceso
de ejecución. Esto puede implicar ciertos retrasos o incluso un a umento de los costes respecto
al presupuesto originalmente estimado.

En el momento en que esos problemas afloren, aquellos miembros del equipo ejecutivo que
no estén de acuerdo con el proyecto, aprovecharán la ocasión para criticarlo y sabotear
cualquier intento de superar las dificultades.

Solución

Para conseguir el apoyo de todo el cuerpo ejecutivo, es necesario identificar de forma

pormenorizada los aspectos en los que sus respectivos departamentos se verán beneficiados.
Una vez el proceso comienza, es fundamental garantizar la obtención de resultados tangibles
y medibles en el corto plazo. De esa manera, será mucho más fácil reforzar el apoyo recibido
y mitigar las críticas prematuras.

OBS Business School 3

No prever los cambios en los requerimientos previos

Los retrasos e incremento de costes durante la ejecución de un proyecto de datos no sólo son
consecuencia de una estimación incorrecta de los requerimientos.

A menudo, las necesidades y prioridades del cliente interno cambian durante el proceso. Esto
puede deberse a múltiples motivos:

• Falta de concreción de algunos requerimientos.

• Desacuerdos en torno a la definición de determinados conceptos y KPIs.

• Desconocimiento inicial del verdadero potencial del proyecto.

Si no se tiene en cuenta esta realidad cambiante, es muy probable que se generen retrasos o
no se pueda llegar a completar el proyecto, debido a un estancamiento en la toma de
decisiones. Los resultados de cualquier iniciativa de datos son un objetivo en movimiento y
no pueden ser tratados como un proyecto de IT . La dirección, los consumidores de
información y los especialistas en BI deben asumir que, una vez dado el paso, la alineación
del consumo de información con la estrategia corporativa es un trabajo constante que
requiere de una inversión constante.

Solución

En primer lugar, es imprescindible que los responsables de los departamentos, así como los
usuarios finales de la tecnología implementada conozcan el potencial de la misma y puedan
solicitar las prestaciones adecuadas.

No obstante, ni siquiera la más cl ara de las explicaciones técnicas puede evitar un cambio de
parecer durante el proceso de implantación. Es por ello que también deben utilizarse
metodologías de desarrollo ágil, las cuales garanticen la realización de las diversas fases del
proyecto, impidiendo la interrupción en momento críticos.

No gestionar adecuadamente el volumen y multiplicidad de los datos

A menudo se tiene la errónea creencia de que las herramientas de Business intelligence son
capaces de recibir y asimilar cualquier tipo de datos provenientes de los sistemas de IT, y
transformarlos directamente en informes y conclusiones útiles. Desgraciadamente, el proceso
no es tan sencillo.

De acuerdo con Forrester, el 64% de los tomadores de decisiones de las empresas tienen
dificultades para extraer conclusiones de sus cuadros de mando.

Las herramientas de Business intelligence sólo lograrán extraer información concluyente y

práctica cuando los datos proporcionados estén en el formato y localización adecuados.

Solución

La realidad se caracteriza por una multiplicidad de fuentes y formatos distintos, los cuales
requieren de un previo formateo y almacenamiento o, más concretamente, un proceso de
extracción, transformación y carga, denominado ETL.

OBS Business School 4

Por supuesto, existen herramientas de Business intelligence con funcionalidades ETL
integradas, pero el proceso sigue requiriendo un conocimiento y configuración previa de las
mismas.

No lograr la utilización por parte de los usuarios finales

De acuerdo con Rita Sallam, vicepresidenta del depart amento de investigación de la

consultora Gartner, el descubrimiento de datos o “ smart data discovery” tiene la capacidad
para ampliar el acceso a análisis complejos a usuarios que no cuentan con una formación
exhaustiva en analítica, lo cual representa cer ca del 70% de los miembros de una
organización.

Sin embargo, uno de los grandes desafíos a la hora de implantar una solución de Business
intelligence es, precisamente, lograr que los usuarios de la misma la utilicen.

Las cifras publicadas por BI Scorecard indican que la adopción de este tipo de tecnologías por
parte de los empleados se mantiene en torno al 22%. En aquellos casos en los que se han
adoptado soluciones móviles, el nivel de adopción alcanza el 42%.

Solución

La aceptación y utilización de las he rramientas de Business intelligence por parte de los

empleados responde tanto al nivel de formación que estos reciban, como a las facilidades que
se les brinden para hacer uso de las mismas.

No mantener el foco en la misión del negocio

La utilización de una determinada tecnología o herramienta de Business intelligence siempre

debe estar al servicio de los objetivos del negocio, nunca al revés.

Sin embargo, son frecuentes los casos en los que la toma de decisiones por parte de las
organizaciones se ve ralentizada debido a impedimentos técnicos, ya sea por imposiciones
desde el departamento de IT o por las propias limitaciones de la herramienta escogida.

Solución

Es necesario que cada organización cuente con un interlocutor capaz de comunicar de forma
práctica y coherente al departamento de IT con el resto de departamentos. En determinadas
organizaciones se implementa un equipo transversal (BICC 1) que contiene personal de todas
las áreas y facilita la comunicación entre IT y negocio. Ya hemos visto el rol de estos equipos
la semana pasada, en el capítulo “El cambiante rol de un departamento de BI”.

No conseguir superar el spreadmart

Muchas compañías ancladas en la cultura de la hoja de cálculo (ver spreadmart en el capítulo

anterior) no quieren superar este c aos de datos, puesto que los “fabricadores” de los
resultados se sientes útiles, propietarios de la información y conciben cualquier iniciativa que
les suponga un cambio en estas tareas como una amenaza a su puesto de trabajo. Por ello,
serán los principales saboteadores de cualquiera. Otras veces, esta resistencia procede de la

1 Siglas de Business Intelligence Competence Center.

OBS Business School 5

desconfianza de estas personas hacia datos que no hayan salido de sus propias manos, sobre
todo si las cifras no son idénticas.

Solución

Los líderes de las iniciativas de BI deben buscar apoyos entre personas que crean en la
transparencia y en resultados basados en hechos y, sobre todo, tener la capacidad de influir
con su visión en el transcurso del proyecto hasta llegar a cambiar la cultura.

Problemas con la calidad de los datos

A menudo, en cualquier iniciativa de BI se cumple el principio GIGO 2, es decir, un informe no

puede aumentar la calidad de la información del origen, por lo que si ésta no es buena ya en
el origen, el resultado producido tampoco lo será. Esto implicará desconfianza en la
información ofrecida por los informes (o cuadros de mando, o modelos o cualquier cosa
basada en dichos datos) y provocará el rechazo de los consumidores de información. El otro
riesgo es que, cuando se plantean problemas de calidad de da tos a los responsables de los
sistemas de información, estos suelen reaccionar con un “no tenemos ningún problema de
calidad, puesto que el sistema funciona”.

Hagamos un breve paréntesis para poner un par de ejemplos reales:

• Una conocida aerolínea española, propietaria de un conocido sistema de fidelización,

decidió en un momento determinado que era el momento de comenzar a explotar la
base de datos de “socios” para hacerles propuestas sobre la mejor manera de redimir
los puntos obtenidos con cada vuelo. P ara ello, buscó un equipo de analistas que
desarrollaran un sistema de recomendaciones que optimizara la relación
beneficio/probabilidad de canjeo. Prácticamente el primer día de trabajo, el equipo se
dio cuenta de que el 83% de la base de datos estaba for mada por hombres, lo que
demostraba con aparente claridad el éxito del programa en el género masculino.
Partiendo de esta premisa, comenzaron a diseñar las propuestas. Transcurridos varias
semanas, se hizo un piloto con un conjunto de clientes que no ofrec ió los resultados
esperados. La dirección se planteó la cancelación de la iniciativa pero antes quiso
conocer los motivos del fracaso. Tras una revisión exhaustiva de la información,
identificaron que el desplegable del aplicativo de introducción de datos del programa
de fidelización ponía el valor “Hombre” por defecto en el proceso de alta de un nuevo
socio, con lo cual, al no obligar al operador a codificar un valor correcto en el campo,
éste no lo cambiaba, produciéndose así una inconsistencia. Y dicha i nconsistencia casi
motivó la cancelación de la iniciativa.

• Otro ejemplo, y no sólo en una compañía concreta, sino en prácticamente la mayoría

de las actuales se puede encontrar en la codificación de las direcciones postales. El
cliente proporciona su dirección, el operador la introduce en el sistema en un campo
que, normalmente, es de texto libre y las cartas llegan a su destino sin incidencias.
Pero cuando entra el juego la analítica y se quiere calcular, por ejemplo, cuántos
clientes se tienen por hogar comienzan los problemas. En una compañía de seguros,
se encontraron hasta 25 maneras diferentes de escribir “ La Vall d'uixó” 3. A nivel postal,

2 Siglas de Gargage In Garbage Out.

3 Municipio perteneciente a la provincia de Castellón, de unos 32.000 habitantes.

OBS Business School 6

 las cartas llegaban perfectamente pero se cometían duplicidades. Por ejemplo, una
comunicación comercial de una nueva tarifa en el seguro de hogar se enviaba dos o
más veces al mismo hogar, puesto que las direcciones eran, desde el punto de vista de
una máquina, diferentes. Cuando se intentó hacer un cierto análisis por hogares, hubo
que tomar acciones adiciones para mejorar la calidad del input que resultó en retrasos
en la obtención de resultados.

No estar abiertos a cambios en las herramientas

Las herramientas de BI aún no son – por lo menos no del todo – una commodity, por lo que
los propios fabricantes aún no ofrecen una solución adecuada para todos los tipos de
necesidad, sino que se centran en un aspecto concreto del análisis y apuestan por hacerlo
mejor que la competencia. Esto hace que una organización, de momento, siempre tenga que
estar atenta a los cambios en el mercado y en la oferta, de manera que se pueda garantizar
que la información es conveniente explotada por su personal.

Solución

Mantener una mentalidad abierta en la que la dirección e IT asuman la realidad y cómo el no

estar abiertos a buscar complementos y alternativas puede suponer un fracaso a la hora de
adoptar la analítica dentro de la organización.

Externalizar demasiado conocimiento

La dirección decide con frecuencia optar por un aparente ahorro de costes externalizando los
esfuerzos que no se consideran estratégicos de las iniciativas de business Intelligence. El
centrar la ejecución de estas iniciativas teniendo demasiado en cuenta sólo los costes, resulta
inevitablemente en sistemas inflexibles y pobremente diseñados. Y, adicionalmente, supone
una pérdida de conocimiento de alto valor cuando la colaboración con el externo finaliza.

Solución

La externalización sólo debe ser llevada a cabo en trabajos que no sean pertenecientes al
negocio de la compañía. La dirección debe ver la información como parte del negocio, puesto
que, en ella se basan las decisiones que afectan al mismo. Perder el control – y parte de la
dirección – de la ejecución de estas iniciativas deriva en resultados no deseados.

Plazos no realistas con presupuestos no realistas

Muchas compañías, debido al desconocimiento y la falta de madurez, infravaloran

constantemente los esfuerzos de las iniciati vas de business Intelligence amparados en el
pensamiento de “pintar un dato no puede ser tan complicado” y asumen que el dato buscado
simplemente está “ahí, perfectamente listo para ser incorporado a un informe”. Por ello, el
nivel de presión al que se ven sometidos los equipos de IT o los equipos de analistas, en
ocasiones, demasiado alto para poder obtener resultados satisfactorios. El equipo de
analistas se centra en la fecha de entrega, en vez de hacerlo en la calidad de la misma, con lo
que el sistema de soporte a la decisión resulta insuficiente.

Solución

La dirección no debe caer en el error de infraestimar el esfuerzo necesario para producir

información útil, especialmente, si se trata de conjuntos de datos completamente nuevos y
los analistas no deben dejar que la presión comprometa la calidad de sus resultados. Para

OBS Business School 7

ello, los primeros deben interesarse por las dificultades que les reportan los analistas y
asignar los recursos apropiados y los segundos deben tener siempre en cuenta que, si los
resultados producidos no sirven para cumplir los objetivos perseguidos, la iniciativa completa
caerá en el olvido.

No consensuar la versión de la verdad

A menudo, para eliminar la disparidad de cifras obtenidas cuando se realiza la misma pregunta
a diferentes áreas, se opta por una definición que puede no estar consensuada con todas las
áreas. Aún siendo la cifra “oficial”, puede no resultar de utilizar para gestionar alguna de las
áreas, con lo que continuarán utilizando “su versión” de la realidad desechando l a oficial.

Solución

Hacer participantes a todas las áreas en la definición de las cifras oficiales y poner a
disposición de todas, “los complementos” que les permitan tomar las decisiones adecuadas
para gestionar con garantías.

Ausencia de estrategia de business Intelligence

Tal como hemos visto en capítulos anteriores, una planificación alineada con la estrategia
corporativa es necesaria para que todas las áreas sepan qué se está haciendo, dónde
tienen/pueden participar y los beneficios que obtendrán de cada iniciativa. La ausencia se
esta estrategia pone las iniciativas de BI en modo “reactivo”, convirtiendo a los equipos de
analistas en cuellos de botella permanentemente carentes de recursos. Adicionalmente, y
cuando se trata de obtener la participación de un área de negocio, no tienen tiempo para
dedicar puesto que “no lo tenían previsto” o “sus prioridades son diferentes”, con lo que la
tan necesaria colaboración transversal se ve comprometida.

Solución

La adecuada comunicación de la estrategia y los momentos previstos para el desarrollo de

cada iniciativa es fundamental si se quieren obtener, tanto los recursos como las
colaboraciones necesarias.

Qué hacer para fracasar en una iniciativa de Big Data/Machine Learning

No sólo hay trampas en las iniciati vas de distribución de información, sino también en las
iniciativas de análisis de la misma, que además, se añaden a las anteriores. Veamos algunas
de las cosas que podemos hacer para fracasar en este tipo de iniciativas.

Comenzar con machine learning sin un objetivo concreto

Es sorprendente cuántas compañías comienzan inversiones en machine learning sin un

objetivo, caso de uso o problema a resolver definido. Conscientes de que se puede obtener
mucho valor y deslumbradas por la cantidad de líneas escritas acerca de big data y machine
learning comienzan “la casa por el tejado” y emplean recursos en capacitarse para resolver
problemas que aún no han encontrado.

Machine learning debe ser empleado para incidir y mejorar puntos dolorosos en la
organización. Una vez que el primer caso ha sido resuelto con éxito, más ideas empezarán a

OBS Business School 8

surgir por sí solas a medida que la organización comienza a conocer cómo aplicar machine
learning y el tipo de problemas que pueden ser resueltos.

Esperar a los datos perfectos

Vuelve a surgir aquí la calidad de la información. En este caso, la compañía, que es consciente
de los problemas analíticos que pueden surgir si la base de datos no está perfecta, comienza
a trabajar en la reparación, compilación, integración y estructuración automatizada de la
información. Comienzan a acometerse acciones para solucionar el problema de los géneros
en la base de datos, el problema de las direcciones postales, o lo que se detecte. Estas
acciones no suelen estar contempladas dentro del proyecto d e machine learning y provocan
retrasos en el mismo.

Adicionalmente, se pierde de vista que un data scientist experimentado está acostumbrado a

trabajar con datos problemáticos y tiene técnicas para arreglar los que necesita, no todos los
de la compañía. Y, de hecho, una de las primeras tareas que suele acometerse al comienzo de
cada tarea de machine learning es una auditoría de calidad para identificar los datos
problemáticos y corregirlos.

No se quiere decir que la calidad de los datos en los orígenes deba ser obviada porque el data
scientist puede corregirla. Lo que se trata de transmitir es que el data scientist puede
seleccionar exactamente el conjunto de datos que necesita para modelar u n aspecto del
negocio y aplicar las correcciones adecuadas, lo que difiere de atacar la calidad del sistema
de información al completo.

Creer que se tienen datos perfectos

En el otro extremo están las organizaciones que asumen que la calidad de sus bases de datos
es perfecta. Las bases de datos perfectas son tan comunes como los unicornios, es decir, no
existen. Y perder de vista este aspecto puede producir que se infraestime el esfuerzo
necesario de auditoría, limpieza y corrección necesario consiguiendo resultados cuya calidad
sólo es acorde a los datos utilizados.

Pensar que la herramienta es lo principal

Otras veces, la compañía asume que la principal capacitación que se necesita es la adquisición
de una herramienta sofistica y popular (¿será popular p or algo, no?) obviando que la
capacitación debe estar en las personas y que, estas pueden producir los mismos resultados
con dicha herramienta u otras. Esto provoca que o bien las iniciativas sean demasiado
costosas en relación al beneficio, con lo que se descartan, o bien las iniciativas nunca son
puestas en marcha porque se carece del personal adecuado que sepa manejar la herramienta.

No involucrar lo suficiente al factor subjetivo

Curiosamente, mientras hablamos de datos y de información, todo lo dicho se asume objetivo.

Y en su mayor parte lo es. En cambio, hay un componente absolutamente valioso de cualquier
iniciativa que son las personas que conocen el día, el negocio, el sector, la manera de
trabajar… que aportan muchas veces la dimensión cualitativ a a las cifras y validan o invalidan
muchas conclusiones.

Las cifras tienen una característica que es al mismo tiempo su ventaja y su desventaja y es
que son frías. No tienen emociones, no hacen distinciones. Al carecer del factor humano,

OBS Business School 9

muchas veces pierden el sentido al encontrarse conclusiones que difícilmente pueden
identificarse con una realidad.

No tener en cuenta que cualquier resultado tiene que ser operativizado

Un modelo hecho con machine learning sólo es el comienzo de la iniciativa. Los resul tados
ofrecidos por el modelo deben ser automatizados, actualizados, integrados dentro de los
sistemas de información actuales de la compañía, y los usuarios formados en su uso. Estas
tareas suelen ser más laboriosas que la elaboración del propio modelo, c on lo que no es raro
que sean las que consumen más de la mitad del tiempo y del presupuesto.

De manera frecuente, estas cuestiones surgen cuando la iniciativa está lanzada o incluso
comenzada, teniendo que replanificar los tiempos de puesta en marcha, prov ocando
aparentes retrasos. O incluso, al volver a replanificar y “represupuestar” toda la iniciativa
para tener en cuenta estos aspectos y revisar los nuevos tiempos y costes, la iniciativa es
cancelada.

Asumir que todos entienden los resultados

Un motivo de frecuentes fracasos de iniciativas de machine learning es asumir que cualquiera

puede comprender los resultados. Los seres humanos necesitamos inconscientemente
verificar la fiabilidad de lo que nos dicen y si no lo entendemos, darle credibilidad de
convierte en un acto de fe.

Pongamos un caso: un conocido laboratorio farmacéutico lanzó hace varios años una iniciativa
de data mining para optimizar la visita médica. Con ella, trataba de ahorrarle a la red visitas
infructuosas a los médicos porque o bien el volumen de prescripción no iba a ser suficiente
para amortizar la visita y los incentivos o bien las probabilidades de que el facultativo
cambiara de marca prescrita eran muy bajas. Esperaban obtener una mejora en el rendimiento
de la inversión comercial de aproximadamente un 10%. Desarrollaron un sistema de
calificación en 5 tramos basado en más de 50 variables diferentes, muchas de las cuales
habían sido aportadas por la propia red de visitadores. Se hizo todo correctamente, se puso
un objetivo claro, se calculó un beneficio esperado, se asignaron recursos bien
dimensionados, se planificó de manera realista y se desplegó sin incidencias.

Pero cuando los visitadores recibieron los nuevos listados de facultativos con la nueva
calificación, sólo sabían quién era “bueno” y quién “malo” pero no “por qué” y, por tanto,
tampoco qué argumentario utilizar con el facultativo. Adicionalmente, la red tampoco
entendió que dicha categorización no era infalible y que podía suceder que un médico
calificado como “bueno” realmente podía no aceptar prescribir o al contrario. Cuando
identificaron que la categorización no era falible perdieron la confianza en la misma y esto,
unido a la dificultad para usarla hizo que dejaran de tener en consideración la ayuda que el
sistema recién desplegado les prestaba.

Otro ejemplo:

El director general de la empresa lleva semanas muy preocupado por las bajas de clientes que
está experimentando la compañía. Los analistas de datos le han dado varios insights
describiendo posibles causas y perfiles, pero no le sirve de nada saber quiénes era los que se
dieron de baja, porque ya se dieron de baja y no hay nada que hacer con ellos.

Lo que este director quiere es anticipar la decisión de baja del cliente para poder actuar antes
de que se produzca la misma. Contrata una empresa colaboradora q ue desarrolla un modelo

OBS Business School 10

predictivo con una red neuronal basándose en los datos históricos de bajas de la compañía
que resulta capaz de predecir con acierto el 82% de las bajas que se producirán.

Durante la presentación del modelo a dirección general para someter a su aprobación la

operativización del mismo, el director pregunta: ¿Quiénes son los clientes más propensos a
darse de baja? La respuesta es: el modelo no da ese resultado, sólo la probabilidad de que se
de baja, pero tiene una tasa de acierto del 82%. El director se resigna y hace otra pregunta:
¿qué hacen estos clientes de especial antes de darse de baja? La respuesta es la misma que
en la pregunta anterior. El director ya se está impacientando y hace la última pregunta: ¿qué
acción debería hacer con estos clientes para evitar que se den de baja? La respuesta es: el
modelo no perfila, pero da la probabilidad de baja con un 82% de acierto.

Llegamos a este punto, el director se enfrenta a una difícil decisión: no sabe el mensaje que
tiene que poner en campañas preventivas a los clientes propensos y tampoco sabe qué
ocasiona la decisión de baja por lo que no sabe qué debe mejorar para evitarlo. Lo que sí sabe
es quién se va a dar de baja.

Este punto, es donde muchas iniciativas de datos “mueren” ante s de llegar a operativizarse.
La caja negra alrededor de lo que el algoritmo hace y por qué lo hace, impide la actuación
correctora o potenciadora. No se sabe el por qué, sólo el qué.

Supongamos que el director decide seguir adelante con la iniciativa y po ner la probabilidad
obtenida en el CRM para que el call center tenga presente quién tiene riesgo de darse de baja
y puedan actuar en consecuencia.

Esto no es más que trasladar el problema de actuación a un ámbito diferente. Cuando un

cliente llame, y el asesor vea en su pantalla que dicho cliente está en riesgo de baja, seguirá
sin saber por qué y, por tanto, será incapaz de montar un argumento eficaz atacando los
motivos de su descontento o los cambios en su comportamiento que están motivando la
alerta.

Tendremos por tanto un algoritmo muy preciso, pero no manejable.

Renunciando a la precisión en aras de la caja “transparente”

Bien, por lo que parece, precisión y transparencia están reñidos. Efectivamente, así es.
Precisión significa complejidad y complejid ad significa capacitación para entender. Por tanto,
transparencia significa sencillez. Y sencillez significa poca precisión.

¿Qué hacer entonces?

Es obvio que si la iniciativa de datos muere en algún punto intermedio antes de llegar a
operativizarse habrá supuesto un coste para la compañía sin retorno ninguno. Visto así, ¿qué
es preferible? ¿comenzar con algo operativizable y medianamente preciso? ¿o hacer un
esfuerzo extra para que la caja negra sea explicable?

Esta pregunta no tiene más que una respuesta subjetiva, basada en la experiencia de esta
humilde servidora. Mi recomendación es orientarnos por el segundo punto: hacer algo preciso
y, por otro lado, hacer algo interpretable. Esta opción, en ocasiones, supone “trabajar dos
veces”, una para producir reglas que puedan utilizarse para controlar la acción de la compañía
y otra para producir un resultado que permita activar las alertas que lanzan dichas acciones.

Si revisamos con cuidado las consecuencias de las diferentes opciones:

OBS Business School 11

 1) Producto preciso, pero no interpretable:

• La iniciativa no llega a terminarse o no llega a ser efectiva. El coste no compensa el

beneficio.
• La alta gerencia se ve obligada a hacer “un acto de fe” en algo que no comprende. Si
los resultados son buenos, nadie atacará la in iciativa, pero si no lo son, aunque no sea
motivado por la precisión de los resultados si no por cualquier otra causa, todo el mal
funcionamiento será achacado al producto.
• Si se consigue operativizar adecuadamente, los resultados suelen ser muy buenos.
• Iniciativas futuras se verán influenciadas por al acto de fe.
• La compañía puede llegar a cuestionarse si los datos sirven para algo .

2) Producto no preciso pero interpretable

• Si los resultados y la eficacia son tibios, se pone en cuestión el retorno de la inver sión.
• Si los resultados son buenos, la compañía se convierte en “ believer”.
• Los resultados son fáciles de operativizar.
• La adoptación es sencilla y poco problemática.
• Se han obtenido reglas e insights que la compañía puede aprovechar para otras
iniciativas.

3) Producto preciso, pero no interpretable + producto no preciso pero interpretable

• Se obtiene lo mejor de los puntos anteriores, evitando los inconvenientes de ambos.

• El esfuerzo de desarrollo de la iniciativa y, con ello su coste final, es más alto, con l o
que el retorno de la inversión tarda más en alcanzarse. Esto puede llegar a ser
complicado de manejar.

El principio KISS 4 es muy adecuado cuando de iniciativas de datos se trata. Cuanto más simple,
más interpretable pero menos valioso y, al contrario. C onseguir encontrar el equilibrio puede
suponer la diferencia entre el éxito o el fracaso de la iniciativa en sentidos de conseguir
llevarla a término.

Conclusión
No todas las trampas están aquí enumeradas pero sí las más frecuentes, recopiladas desde
alguna bibliografía, la experiencia ajena y la experiencia propia de muchos años.

El uso de la información tiene una última trampa que hace que las iniciativas de datos sean
radicalmente diferentes de cualquier otro proyecto y es que nunca se sabe qué se va a obtener
hasta que se obtiene. Esta es su razón de ser y al mismo tiempo su principal riesgo.

4 El principio KISS (del inglés, Keep It Simple, Stupid!) es un acrónimo usado como principio de diseño.

El principio KISS establece que la mayoría de sistemas funcionan mejor si se mantienen simples que si se hacen
complejos; por ello, la simplicidad debe ser mantenida como un objetivo clave del diseño, y cualquier
complejidad innecesaria debe ser evitada.

OBS Business School 12