Preparacion de Datos para IA de Pronostico de Demanda en Cadena de Suministro
Una guia practica para construir pipelines de datos para IA de pronostico de demanda en cadena de suministro: mapeo de fuentes de datos, requisitos de calidad por horizonte de pronostico, ingenieria de caracteristicas y despliegue on-premise para cadenas de suministro empresariales.
McKinsey estima que el pronostico de demanda impulsado por IA puede reducir los errores en la cadena de suministro entre un 30-50% y recortar las ventas perdidas por roturas de stock hasta en un 65%. Sin embargo, la mayoria de las iniciativas empresariales de pronostico de demanda se estancan durante la preparacion de datos, no durante el desarrollo de modelos. La razon es estructural: el pronostico de demanda requiere integrar datos de sistemas que nunca fueron disenados para comunicarse entre si — ERP, WMS, POS, CRM y proveedores de datos externos — en un unico conjunto de datos limpio y temporalmente alineado.
El modelo de pronostico en si suele ser la parte mas sencilla del proyecto. Reunir ventas historicas, posiciones de inventario, tiempos de entrega de proveedores, calendarios promocionales y senales macroeconomicas en un conjunto de entrenamiento consistente y validado en calidad es donde se concentra el 60-80% del esfuerzo del proyecto. Esta guia cubre como construir ese pipeline de datos de forma sistematica.
Mapeo de Fuentes de Datos para Pronostico de Demanda
Los modelos de pronostico de demanda consumen datos de multiples sistemas empresariales. Cada fuente tiene formatos distintos, frecuencias de actualizacion y caracteristicas de calidad diferentes.
| Fuente de Datos | Sistema de Origen | Formato Tipico | Frecuencia de Actualizacion | Campos Clave |
|---|---|---|---|---|
| Ventas/pedidos historicos | ERP (SAP, Oracle, NetSuite) | Exportacion CSV/Excel, extraccion API | Diaria a semanal | SKU, cantidad, fecha, canal, segmento de cliente, precio |
| Posiciones de inventario | WMS (Manhattan, Blue Yonder) | Exportacion CSV/Excel | Diaria | SKU, ubicacion, cantidad disponible, en transito, reservado |
| Tiempos de entrega de proveedores | Sistema de compras/SRM | Excel, hojas de seguimiento manual | Mensual a trimestral | Proveedor, SKU/categoria, tiempo de entrega cotizado, historial de tiempo de entrega real |
| Calendario promocional | Sistema de marketing/promocion comercial | Excel, calendarios compartidos | Mensual | Tipo de promocion, fechas de inicio/fin, SKUs afectados, profundidad de descuento |
| Datos de punto de venta | Sistema POS/retail | CSV, EDI 852 | Diaria a semanal | Tienda, SKU, unidades vendidas, precio, devoluciones |
| Historial de precios | ERP o motor de precios | CSV/Excel | Por evento de cambio de precio | SKU, fecha efectiva, precio de lista, precio neto, moneda |
| Datos meteorologicos | API de terceros (NOAA, Weather Company) | JSON/CSV | Diaria | Region, temperatura, precipitacion, alertas de clima severo |
| Indicadores macroeconomicos | Estadisticas gubernamentales, proveedores de datos | CSV | Mensual a trimestral | IPC, crecimiento del PIB, confianza del consumidor, tasa de desempleo |
| Precios de la competencia | Web scraping o feeds de terceros | JSON/CSV | Diaria a semanal | Competidor, categoria de producto, punto de precio, disponibilidad |
No todos los modelos de pronostico necesitan todas las fuentes. La seleccion de fuentes de datos depende del horizonte de pronostico y del contexto empresarial. Un pronostico de reabastecimiento a corto plazo para un minorista de alimentos necesita datos POS diarios y calendarios promocionales. Un pronostico de planificacion de capacidad a largo plazo para un fabricante necesita indicadores macroeconomicos y tendencias de tiempos de entrega de proveedores.
Requisitos de Calidad por Horizonte de Pronostico
Diferentes horizontes de pronostico tienen diferentes tolerancias de calidad de datos. Un pronostico estrategico para planificacion anual de capacidad puede tolerar cierta imprecision en los datos. Un pronostico operativo que impulsa pedidos diarios de reabastecimiento no puede.
| Horizonte de Pronostico | Rango Temporal | Fuentes de Datos Principales | Requisitos de Calidad | Granularidad Aceptable |
|---|---|---|---|---|
| Operativo | 1-14 dias | Datos POS, inventario actual, clima, calendario promocional | Muy alta: menos del 1% de valores faltantes, granularidad diaria, latencia de datos inferior a 24h | Diaria por SKU por ubicacion |
| Tactico | 2-12 semanas | Ventas historicas, inventario, promociones, tiempos de entrega de proveedores | Alta: menos del 3% de valores faltantes, granularidad semanal, actualizacion semanal aceptable | Semanal por SKU por region |
| Estrategico | 3-18 meses | Tendencias de ventas historicas, indicadores macroeconomicos, panorama competitivo | Moderada: menos del 5% de valores faltantes, granularidad mensual, actualizacion mensual | Mensual por categoria de producto por mercado |
| Planificacion a largo plazo | 1-5 anos | Tendencias anuales, investigacion de mercado, cambios demograficos, curvas de adopcion tecnologica | Tolerante: menos del 10% de valores faltantes, granularidad trimestral/anual | Trimestral por familia de producto por segmento |
Requisitos de Frescura de Datos
El valor de los datos de pronostico de demanda decae a diferentes ritmos dependiendo de la fuente:
| Fuente de Datos | Requisito de Frescura | Impacto de Datos Desactualizados |
|---|---|---|
| POS / pedidos de venta | Mismo dia o dia siguiente | Los pedidos de reabastecimiento basados en la demanda de ayer no capturan cambios de tendencia |
| Posiciones de inventario | Mismo dia | Sobrestock o roturas de stock por disponible para promesa incorrecto |
| Calendario promocional | 2-4 semanas de anticipacion | El pronostico no detecta picos de demanda de promociones no contabilizadas |
| Tiempos de entrega de proveedores | Actualizacion mensual | Calculos de stock de seguridad basados en tiempos de entrega desactualizados |
| Clima | Ventana de pronostico de 1-3 dias | No captura demanda impulsada por el clima (productos estacionales, HVAC, bebidas) |
| Macroeconomicos | Mensual a trimestral | Los pronosticos estrategicos no detectan puntos de inflexion economica |
Etapas del Pipeline para Datos de Pronostico de Demanda
Etapa 1: Ingestion y Validacion de Esquema
La etapa de ingestion extrae datos de los sistemas de origen y valida que cada extraccion cumpla con los esquemas esperados. La deriva de esquema — cuando un sistema de origen cambia nombres de columnas, formatos de fecha o agrega/elimina campos durante una actualizacion — es un modo de fallo comun en pipelines de pronostico en produccion.
| Verificacion de Validacion | Que Detecta | Accion ante Fallo |
|---|---|---|
| Presencia de columnas | Campos esperados faltantes despues de actualizacion del sistema | Rechazar archivo, alertar a ingenieria de datos |
| Validacion de tipo de datos | Cadenas en campos numericos, fechas en formato incorrecto | Rechazar filas afectadas, registrar para correccion |
| Umbral de conteo de filas | Extracciones inesperadamente vacias o truncadas | Rechazar si el conteo cae por debajo del 80% del promedio historico |
| Validacion de rango de fechas | Brechas o registros con fecha futura en datos historicos | Marcar brechas para interpolacion, rechazar fechas futuras |
| Consistencia de moneda/unidad | Monedas mixtas o cambios de unidad de medida a mitad de archivo | Normalizar a moneda/unidad base usando tablas de conversion |
Ertas Data Suite maneja la ingestion multiformato a traves de nodos de analisis dedicados para CSV, Excel, PDF y otros formatos comunes de exportacion empresarial. El nodo Format Normalizer estandariza formatos de fecha, representaciones de moneda y codificacion de unidades de medida entre fuentes. Cada paso de validacion es visible en el canvas del pipeline, haciendo inmediatamente claro cuando un archivo de origen se desvia de las expectativas.
Etapa 2: Deduplicacion y Resolucion de Entidades
Los sistemas empresariales frecuentemente producen registros duplicados a traves de errores de integracion, re-ejecuciones de lotes y captura de pedidos multi-sistema. Un unico pedido de cliente podria aparecer tanto en el ERP como en el sistema POS con campos ligeramente diferentes.
La resolucion de entidades entre sistemas es igualmente importante. El mismo producto podria identificarse como SKU "A1234" en el ERP, "1234-A" en el WMS y "Producto A Regular 12oz" en el sistema POS. Sin un maestro de productos unificado, el modelo de pronostico trata estos como tres productos diferentes con historiales de demanda separados.
Tareas clave de deduplicacion y resolucion:
- Deduplicacion de pedidos: Emparejar por ID de pedido, fecha y monto para eliminar duplicados de extracciones multi-sistema
- Armonizacion de productos: Mapear todos los identificadores de producto a un unico SKU canonico usando una tabla de referencia cruzada
- Armonizacion de ubicaciones: Mapear codigos de almacen, numeros de tienda e identificadores de region a una jerarquia consistente
- Deduplicacion de clientes: Emparejar registros de clientes entre CRM y sistemas de pedidos (relevante para pronostico B2B)
Etapa 3: Tratamiento de Valores Faltantes
Los datos faltantes en pronostico de demanda requieren imputacion consciente del dominio, no relleno estadistico generico. Un dia con cero ventas podria significar que no hubo demanda (el producto es estacional) o que el producto estaba agotado (la demanda existio pero no fue capturada). La estrategia de imputacion debe distinguir entre estos escenarios.
| Escenario de Datos Faltantes | Metodo de Deteccion | Estrategia de Imputacion |
|---|---|---|
| Demanda verdaderamente cero | Producto en stock, sin ventas registradas | Registrar como cero — no imputar |
| Rotura de stock (demanda censurada) | Posicion de inventario en cero en la fecha en cuestion | Imputar usando demanda de periodos comparables con stock disponible |
| Caida del sistema | Todos los productos muestran cero ventas para una ubicacion/fecha | Imputar usando promedios del mismo dia de la semana del periodo anterior |
| Producto nuevo (sin historial) | La fecha de lanzamiento del producto es posterior al inicio de la ventana de entrenamiento | Usar demanda de producto analogo, ajustar por supuestos de curva de lanzamiento |
| Producto descontinuado | La fecha de fin de vida del producto esta dentro de la ventana de entrenamiento | Truncar historial en fin de vida; no imputar ceros post-fin de vida |
La demanda censurada inducida por rotura de stock es el escenario mas critico de manejar correctamente. Si el modelo entrena con ventas observadas que incluyen ceros por rotura de stock, aprende que la demanda cae a cero periodicamente — y pronosticara baja demanda precisamente cuando es mas probable que el producto se agote de nuevo, creando un ciclo auto-reforzante.
Etapa 4: Ingenieria de Caracteristicas
Los datos historicos crudos necesitan transformacion en caracteristicas que capturen patrones de demanda. La ingenieria de caracteristicas para pronostico de demanda se divide en varias categorias:
| Categoria de Caracteristica | Ejemplos | Metodo de Ingenieria |
|---|---|---|
| Caracteristicas de rezago | Ventas hace 1 dia, 7 dias, 28 dias, 364 dias | Valores desplazados en el tiempo de ventas historicas |
| Estadisticas rodantes | Media movil de 7 dias, desviacion estandar rodante de 28 dias, tendencia de 13 semanas | Agregaciones basadas en ventana |
| Caracteristicas de calendario | Dia de la semana, mes, trimestre, indicador de festivo, pre/post-festivo | Descomposicion de fecha + consulta de calendario de festivos |
| Caracteristicas promocionales | Indicador de promocion activa, profundidad de descuento, dias desde ultima promo, dias hasta proxima promo | Union con calendario promocional |
| Caracteristicas de precio | Precio actual, indicador de cambio de precio, precio relativo al promedio de 90 dias | Union con historial de precios, calcular metricas derivadas |
| Senales externas | Pronostico de temperatura, cambio de IPC, indice de precios de competidores | Union por fecha y region desde fuentes externas |
| Caracteristicas de inventario | Dias de suministro, indicador de rotura de stock, semanas de cobertura | Calcular a partir de posiciones de inventario y tasa de demanda |
Etapa 5: Alineacion Temporal y Agregacion
Las diferentes fuentes de datos operan en diferentes granularidades temporales. Los datos POS son diarios. Los datos macroeconomicos son mensuales. Los tiempos de entrega de proveedores se actualizan trimestralmente. El pipeline debe agregar o desagregar todas las fuentes a la granularidad objetivo de pronostico.
Reglas de agregacion por tipo de datos:
| Tipo de Datos | Metodo de Agregacion | Metodo de Desagregacion |
|---|---|---|
| Volumen de ventas/demanda | Sumar a granularidad superior | Distribuir proporcionalmente usando patrones diarios historicos |
| Precios | Promedio (o fin de periodo) a granularidad superior | Rellenar hacia adelante con ultimo precio conocido a granularidad diaria |
| Inventario | Instantanea de fin de periodo a granularidad superior | Interpolacion lineal entre instantaneas |
| Indicadores binarios (promo, festivo) | Verdadero-si-alguno a granularidad superior | Aplicar indicador a todos los dias dentro del periodo del evento original |
| Clima | Promedio para temperatura; suma para precipitacion | Los valores diarios ya son la granularidad nativa |
Etapa 6: Validacion y Exportacion
Antes de que el conjunto de datos de entrenamiento llegue al modelo, la validacion integral detecta problemas que de otro modo se manifestarian como errores de pronostico inexplicables.
| Regla de Validacion | Que Detecta | Umbral |
|---|---|---|
| Prueba de estacionariedad de demanda | Rupturas estructurales o cambios de nivel que requieren tratamiento de modelo separado | Valor p de prueba ADF; marcar si no es estacionario sin diferenciacion |
| Correlacion de caracteristicas | Caracteristicas multicolineales que desestabilizan coeficientes del modelo | Eliminar una de cualquier par con correlacion superior a 0.95 |
| Fuga de objetivo | Caracteristicas que contienen informacion futura | Verificar que todas las caracteristicas usen solo datos disponibles en el origen del pronostico |
| Balance de clases (para clasificacion) | Desequilibrio extremo en categorias de demanda (si se clasifican niveles de demanda) | Marcar si la clase minoritaria cae por debajo del 5% |
| Completitud temporal | Brechas en la serie temporal despues de todo el procesamiento | Cero tolerancia para brechas en datos de pronostico operativo |
Exportar en el formato objetivo del modelo — tipicamente CSV o Parquet para modelos tabulares, con divisiones adecuadas de entrenamiento/validacion/prueba basadas en tiempo (nunca aleatorias) para prevenir fuga temporal.
Por Que On-Premise Importa para Datos de Cadena de Suministro
Los datos de cadena de suministro son competitivamente sensibles. La demanda historica por SKU revela el rendimiento del producto. Los tiempos de entrega de proveedores exponen relaciones de compra. El historial de precios muestra la estructura de margenes. Las posiciones de inventario indican la eficiencia operativa. Estos datos, en conjunto, proporcionan una vision integral de las operaciones comerciales que las empresas protegen rigurosamente.
Mas alla de la confidencialidad, muchas empresas tienen politicas de gobernanza de datos que prohiben enviar datos transaccionales a servicios en la nube externos sin una revision de seguridad exhaustiva. Para cadenas de suministro globales, los requisitos de residencia de datos pueden restringir donde se pueden procesar los datos geograficamente.
Ertas Data Suite opera completamente on-premise como una aplicacion de escritorio nativa. Los datos de cadena de suministro nunca salen de la red empresarial. Cada nodo de transformacion registra sus operaciones, produciendo un rastro de auditoria que satisface las revisiones internas de gobernanza de datos y los requisitos de cumplimiento externo. El canvas visual del pipeline da a los analistas de cadena de suministro — que entienden la logica de negocio pero pueden no escribir Python — visibilidad directa de como se estan preparando sus datos para modelos de IA.
Conclusiones Clave
La IA de pronostico de demanda es un problema de integracion de datos antes de ser un problema de modelado. El pipeline debe manejar ingestion multi-fuente, resolucion de entidades, imputacion consciente del dominio (especialmente para demanda censurada durante roturas de stock), alineacion temporal y validacion rigurosa contra fugas y supuestos de estacionariedad.
Los equipos que construyen pipelines de datos observables y reproducibles lanzan modelos de pronostico que mejoran con el tiempo a medida que mejora la calidad de los datos. Los equipos que arman la preparacion de datos con scripts improvisados pasan su tiempo depurando errores de pronostico que se remontan a problemas de datos que no pueden ver.
Turn unstructured data into AI-ready datasets — without it leaving the building.
On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.
Keep reading
On-Premise vs Cloud Data Pipeline Throughput: Enterprise Document Processing Benchmarks
Throughput comparison of on-premise GPU infrastructure vs cloud API services for enterprise document processing at scale — from 100 to 100K documents — with cost analysis and deployment recommendations.
How to Prepare Training Data for Insurance Fraud Detection AI Models
A practical playbook for preparing claims text, adjuster notes, and policy documents as training data for insurance fraud detection AI — covering pipeline stages, data quality requirements, and on-premise deployment for regulated insurers.
Preparing Sensor and IoT Time-Series Data for AI Training Pipelines
A practical guide to building AI training pipelines for sensor and IoT time-series data — covering windowing strategies, normalization methods, anomaly labeling, and train/test splitting for vibration, temperature, pressure, and acoustic sensor types.