7 min de lectura
Un director de marketing entra a una reunión con un dashboard actualizado. Sabe cuántos clientes convirtieron el mes pasado, desde qué canal entraron y cuánto gastaron en promedio. Tiene respuestas precisas a preguntas que apuntan hacia atrás, y no tiene respuesta a lo que necesita para la reunión de planning del jueves: qué segmento va a convertir más el mes que viene, y cuánto vale la pena invertir en cada uno antes de que empiece la campaña. Esa pregunta no se responde con un dashboard mejor. Requiere un modelo predictivo, y el motivo es de dirección temporal, no de herramientas ni de presupuesto.
La distinción que importa no está en el software
BI y Data Science usan muchos de los mismos datos de entrada. La tabla de transacciones del mes alimenta tanto el reporte de ventas consolidado como el modelo de propensión de recompra. El dato es el mismo; la pregunta es distinta. BI responde "¿qué pasó?" y "¿cuánto?". Data Science responde "¿qué va a pasar?" y "¿con quién?".
El análisis de conversión histórica del mes pasado muestra qué ocurrió: qué canal trajo más leads, cuál fue la tasa de cierre, en qué parte del funnel se cayeron más oportunidades. Ese análisis vive en un dashboard. La previsión de qué segmento va a convertir más el mes siguiente ya requiere un modelo. Los datos de entrada pueden ser los mismos; la dirección temporal es opuesta.
Un buen dashboard de stock muestra la rotación por SKU de los últimos seis meses, las líneas que más vendieron, las semanas con picos. Un modelo de previsión de demanda usa esa misma historia para estimar qué pedir el próximo mes por SKU, ajustando por estacionalidad, tendencia y señales del punto de venta. Son dos respuestas construidas sobre los mismos datos, para preguntas que apuntan en direcciones opuestas.
Este es el punto que suele perderse cuando una empresa decide "invertir en datos". La pregunta que quiere responder determina la infraestructura que necesita, y las dos infraestructuras son distintas.
Dos infraestructuras distintas
BI necesita datos limpios, estructurados y accesibles. Necesita visualización que el equipo pueda interpretar sin ayuda técnica. El mantenimiento es predecible: si los datos de entrada cambian, el reporte cambia; si el negocio agrega una dimensión nueva, se agrega al modelo de datos.
Data Science necesita algo diferente desde el principio. Antes de escribir una línea de código, alguien tiene que definir la ventana de predicción: ¿cuántos días hacia adelante predice el modelo? ¿Qué se define exactamente como conversión? ¿Sobre qué población se entrena? Esas son decisiones de negocio disfrazadas de parámetros, no decisiones técnicas, y tomarlas mal contamina todo lo que viene después.
Después del entrenamiento, el modelo necesita monitoreo de degradación. Los patrones de comportamiento cambian con el tiempo. El modelo entrenado hace seis meses puede estar dando predicciones que ya no reflejan la realidad actual. Eso no pasa con un dashboard. Si el dato de hoy está bien, el dashboard de hoy está bien. Con un modelo, el dato puede estar perfecto y el modelo seguir deteriorándose porque el mundo cambió. El mantenimiento de un sistema de Data Science es más activo por diseño; responde a una pregunta más difícil.
La ventana de predicción es donde el proyecto se gana o se pierde
Predecir requiere tomar una decisión antes de modelar. Hay que decidir qué se predice y en qué horizonte temporal. Si una empresa quiere saber qué clientes tienen mayor probabilidad de recompra en los próximos 30 días, ese problema es distinto a predecir los próximos 90. La ventana cambia qué clientes aparecen como positivos en el entrenamiento, qué señales del comportamiento son predictivas, y cómo se valida el modelo. Cambiar la ventana es, en práctica, cambiar el problema.
Cuando alguien llega con la pregunta "¿queremos construir un modelo de propensión?", la primera respuesta es otra pregunta. ¿En qué horizonte temporal trabaja el modelo, y qué acción va a tomar el equipo con el resultado? Sin respuesta clara a esas dos preguntas, el modelo se construye sobre supuestos que nadie validó, y cuando lleguen los resultados nadie sabe bien cómo usarlos.
Dos preguntas antes de decidir en cuál invertir
Antes de elegir entre BI y Data Science, hay dos preguntas que hacerse.
¿La decisión que quieres tomar es retrospectiva o prospectiva?
Si la decisión es entender qué pasó, identificar qué funcionó, reportar resultados o detectar tendencias pasadas, el problema es de BI. Si la decisión es asignar presupuesto, priorizar segmentos, anticipar demanda o personalizar una acción antes de que el cliente haga algo, el problema es de Data Science.
¿Existe un proceso que va a consumir la salida del modelo?
Un modelo predictivo sin un proceso que consuma su salida no sirve. Si el modelo entrega la predicción y el equipo de marketing sabe exactamente qué campaña activa para cada segmento de probabilidad, el proceso está definido. Si la predicción llega a una carpeta de archivos y ahí se queda, el proyecto tiene un problema de diseño que ningún modelo resuelve. BI también produce salidas que necesitan procesos para consumirlas, pero la fricción es menor. El dashboard suele ser ya el proceso, o un paso antes del proceso familiar.
Los dos pueden coexistir, y uno suele ser la base del otro
Un negocio con BI bien construido tiene más posibilidades de hacer bien Data Science. Los datos están limpios, estructurados y con historia. Las definiciones de negocio ya están consensuadas. El equipo tiene práctica en tomar decisiones basadas en información cuantitativa.
Hay una dependencia adicional en el otro sentido, menos obvia y más práctica. El BI es también lo que permite verificar en producción si un modelo predictivo está funcionando. Cuando el modelo predijo que un segmento iba a convertir al 15% y el reporte del mes siguiente muestra que convirtió al 8%, esa comparación entre predicción y realidad observada es lo que hace posible analizar exhaustivamente la degradación del modelo y hacer los ajustes que sean necesarios. El BI cierra el círculo del proyecto de Data Science, validando en producción lo que el entrenamiento propuso.
Eso no significa que BI sea una etapa previa obligatoria. Hay empresas que pasan directamente a modelos predictivos porque el caso de uso justifica la inversión desde el principio. Cuando BI está bien construido, el Data Science no empieza desde cero; cuando no lo está, el primer trabajo del proyecto suele ser limpiar lo que BI debería haber dejado limpio.
Hay un patrón más frecuente de lo que parece. La empresa que salta a modelos predictivos antes de tener BI bien establecido termina haciendo ambas cosas a medias. El proyecto de Data Science se detiene para limpiar datos que deberían haber estado listos antes. El modelo llega, pero sobre fundamentos frágiles. La confusión entre los dos genera proyectos que resuelven bien lo que nadie preguntó. Una empresa que necesitaba entender qué pasó con sus conversiones del último trimestre contrata un proyecto de "data science", construye un modelo de propensión que nadie sabe cómo operar, y llega a la conclusión de que "los datos no estaban listos". El problema, en muchos casos, era que el proyecto resolvió la pregunta equivocada.
El proyecto de más valor antes de construir nada
Definir qué pregunta quieres responder es el proyecto de más valor que se puede hacer sin datos todavía. Un diagnóstico de datos tarda dos días y produce un documento: qué se puede hacer con los datos actuales, qué no se puede, qué haría falta para llegar más lejos, y qué tipo de proyecto resuelve la pregunta real. A veces la conclusión es que lo que el equipo necesita es un dashboard mejor. A veces hay suficiente historia para construir un modelo de previsión. A veces la pregunta todavía no está definida para hacer ninguna de las dos.
Las tres respuestas son valiosas. La tercera, especialmente, porque evita meses de trabajo en la dirección incorrecta. La pregunta correcta, antes de cualquier presupuesto de datos, es la inversión de más retorno que existe.