Quieres predecir demanda pero no sabes si tus datos dan para eso. Requisitos técnicos, datos necesarios y señales de que tu empresa puede (o no) hacerlo.
📌 En resumen
Para hacer predicción de demanda con datos reales, una empresa necesita al menos 18-24 meses de histórico, datos a nivel de producto o SKU, variables contextuales relevantes y una frecuencia de registro suficiente. Sin estos mínimos, el modelo no puede distinguir patrones estacionales de eventos puntuales. Las variables contextuales más útiles incluyen calendario de promociones, festivos locales, precios y acciones de la competencia cuando están disponibles. Si los datos están dispersos en varios sistemas sin reconciliar, el primer paso es consolidarlos antes de construir ningún modelo. La frecuencia ideal de registro es diaria o semanal; datos solo mensuales limitan mucho la capacidad predictiva del modelo.
«Queremos predecir la demanda, pero no sabemos si nuestros datos dan para eso.» Es la pregunta más honesta que puede hacer un director de operaciones o de supply chain. Porque entre las demos de IA que predicen todo con un 95% de precisión y la realidad de una empresa con datos en 4 sistemas diferentes, hay un abismo. Y vale la pena saber en qué lado estás antes de invertir.
Un modelo de predicción de demanda no necesita datos perfectos, pero sí necesita datos que cumplan unos mínimos. Estos son los cuatro requisitos que evaluamos antes de recomendar un proyecto de forecasting:
Para capturar estacionalidad —que es el patrón más potente en predicción de demanda— necesitas al menos 18-24 meses de datos. Idealmente, 3 años. Si solo tienes 6 meses de histórico, el modelo no puede distinguir un patrón estacional de un evento puntual.
Los datos diarios permiten modelos más precisos que los semanales, y los semanales más que los mensuales. Si tu registro de ventas es mensual por categoría, sin detalle por producto o por día, la capacidad predictiva se reduce significativamente. No necesitas datos al minuto, pero sí al menos semanales y por producto o categoría relevante.
La demanda no solo depende del tiempo. Depende de precios, promociones, festivos, clima, eventos del sector. Si tu empresa registra cuándo hace promociones, cuándo sube precios, qué campañas lanza, esas variables mejoran enormemente la predicción. Si no las registra, el modelo puede funcionar, pero será menos preciso.
Los datos necesitan estar en bases de datos, hojas de cálculo estructuradas o exports automatizables. Si el histórico de ventas son PDFs escaneados de albaranes, hay un problema previo que resolver antes de pensar en predicción.
Para un proyecto de forecasting de demanda típico, estos son los bloques de datos que usamos:
💡 Consejo
Un buen modelo de forecasting no necesita datos perfectos. Necesita datos consistentes. Si tus ventas del martes siempre están registradas un 15% por debajo de la realidad porque el ERP no captura cierto canal, el modelo puede trabajar con eso siempre que el sesgo sea constante. Lo que mata a un modelo es la inconsistencia: datos que unas veces están y otras no, formatos que cambian sin aviso.
Si estás valorando un proyecto de predicción de demanda, haz esto antes de hablar con cualquier proveedor:
Con ese análisis básico en la mano, cualquier conversación con un proveedor será más productiva. Sabrás qué datos tienes, en qué estado están y qué preguntas concretas necesitas responder.
| Requisito | Por qué importa | Señal de riesgo | Qué hacer primero |
|---|---|---|---|
| Histórico suficiente | Permite aprender estacionalidad y patrones | Menos de un ciclo razonable o series rotas | Ampliar histórico o replantear alcance |
| Granularidad coherente | Evita mezclar unidades, clientes o periodos incompatibles | Datos agregados sin posibilidad de bajar detalle | Definir nivel de decisión correcto |
| Variables explicativas | Ayudan a explicar picos, campañas o incidencias | Solo hay ventas pasadas y nada más | Cruzar con calendario, stock o promociones |
| Acceso automatizable | Hace viable pasar del análisis a producción | Dependencia total de exports manuales | Resolver extracción antes del modelo |
La diferencia más visible no estuvo en el modelo, sino en la conversación previa. En el caso que llegó preparado, el equipo ya había decidido qué horizonte mirar, qué decisión iba a cambiar y quién validaba los resultados. En el que no, se hablaba de “predecir ventas” sin acordar si la unidad de decisión era producto, tienda, semana o familia. El primer proyecto avanzó; el segundo necesitó volver atrás y ordenar datos y expectativas.
Por eso conviene leer este checklist junto al caso real de forecasting de demanda, revisar la plataforma de datos y tener a mano una idea realista de cuánto tarda un proyecto de datos o IA. Si ya estás pensando en presupuesto, la página de precios orientativos ayuda a poner marco comercial.
Depende del negocio, pero lo importante es cubrir suficientes ciclos y cambios relevantes. Si solo tienes unos pocos meses y además fueron atípicos, conviene ser prudente.
Sí, si sabes qué limitaciones asumes y el caso sigue siendo útil. Lo que no suele funcionar es ignorar esas limitaciones y esperar precisión alta desde el primer día.
En entornos pyme suele bloquear más el dato: cómo está registrado, si puede cruzarse y si la decisión operativa que debe usar el forecast está clara.
No conviene mezclar varias granularidades sin explicitarlo, rellenar huecos a mano sin dejar rastro o intentar arreglar la falta de histórico prometiendo más sofisticación en el modelo. En forecasting, un dato limitado pero bien entendido suele valer más que una base grande y confusa.
Siguiente paso recomendado
El primer paso hacia un forecasting fiable: una base de datos unificada con las fuentes clave conectadas.
Sin compromiso · Respuesta en < 24h
Autor
Fundador y Consultor de Datos e IA
David Aldomar es fundador y consultor principal de MERIDIAN Data & IA, consultora especializada en ayudar a pymes y empresas medianas en España a tomar mejores decisiones con sus datos. Su trabajo se centra en cuatro áreas: diseño e implantación de plataformas de datos (data warehouses, pipelines ETL con dbt, integración de ERPs y CRMs), reporting y dashboards ejecutivos en Power BI, automatización de procesos de negocio con herramientas como n8n, y desarrollo de soluciones de inteligencia artificial aplicada — desde modelos de forecasting de demanda hasta copilots internos basados en RAG con LangChain y FastAPI. Ha liderado proyectos en sectores como logística y transporte, retail y distribución, servicios financieros, manufacturing y construcción, siempre con un enfoque pragmático: diagnóstico corto, entregables concretos y transferencia de conocimiento al equipo del cliente para que sea autónomo desde el primer día. Antes de fundar MERIDIAN, acumuló experiencia en consultoría de datos y transformación digital trabajando con stacks variados — desde entornos Microsoft (SQL Server, Power BI, Azure) hasta ecosistemas open source (Python, dbt, BigQuery). Su filosofía es que un buen proyecto de datos no se mide por la tecnología que usa, sino por las decisiones de negocio que permite tomar. Escribe regularmente en el blog de MERIDIAN sobre reporting, gobierno del dato, automatización e IA aplicada, con guías prácticas orientadas a responsables de negocio y equipos técnicos de empresas que quieren sacar partido real a sus datos sin depender de grandes consultoras.
Fuentes
Si tu contexto es comercial, aqué tienes el ejemplo más cercano.
Un ejemplo de implantación para entender qué datos y decisiones hacen falta.
La base técnica para integrar histórico, señales y reglas de negocio en el forecast.
Así aterrizamos estos requisitos en un proyecto real.
Plazos y dependencias habituales para no vender internamente un calendario irreal.
Cómo se suele estructurar económicamente un proyecto analítico o predictivo.
Seguir leyendo
6 min lectura
8 min lectura
7 min lectura