Cómo funciona la previsión de demanda dentro de Captia.ai
El módulo responde a una pregunta muy concreta: cuánto va a tener que producir la planta en cada periodo del horizonte que se le pida. No mira una señal física, mira el trabajo que se le va a pedir a la fábrica. Por eso su materia prima no es un sensor, sino dos fuentes que casi nunca están en el mismo sitio: los históricos de producción registrados en la plataforma y los datos de pedido, cartera y previsión comercial que viven en el ERP y en el MES.
La cadena empieza en la integración. Captia.ai integra por API con ERP, MES, CRM o SAP, y Captia Connect captura en el edge lo que ocurre en planta sobre los protocolos disponibles en la instalación (MQTT, OPC UA, Modbus TCP, Modbus RTU sobre RS-485, OpenWebNet, IEC 870-5-102, API REST, webhooks o ficheros CSV), lo normaliza en series temporales y lo envía con buffering local para que una caída de red no abra huecos en el histórico. El módulo trabaja después, sobre ese histórico ya consolidado y con marca de tiempo homogénea.
El procesamiento tiene tres movimientos. Primero reconstruye la demanda pasada real, que no es lo mismo que la producción pasada: lo que se fabricó está limitado por la capacidad que hubo, mientras que lo que se pidió está en el ERP. Segundo, proyecta esa demanda sobre el horizonte y el nivel de agregación que pide la decisión: por planta, por línea, por familia o por referencia. Tercero, y aquí está el trabajo útil, traduce esa proyección a carga de trabajo, porque una demanda en unidades no es accionable hasta que se convierte en horas de línea, en turnos y en material.
La salida vive dentro de la plataforma, no en un fichero aparte: dashboards por activo, línea, rol o planta; reglas y alertas cuando la demanda proyectada supera el umbral que la planta puede atender; eventos trazables en el histórico; reporting periódico; y devolución por API al ERP o al MES cuando la previsión tiene que aterrizar en el plan maestro. Esa devolución es la parte que más se olvida al planificar el proyecto y la que decide si la previsión cambia algo o se queda en una gráfica.
| Capa | Qué aporta | Dónde vive |
|---|---|---|
| Entrada | Históricos de producción normalizados más pedidos, cartera y previsión comercial integrados desde ERP y MES | Captia Connect (edge) e integración por API en Captia.ai |
| Procesamiento | Reconstrucción de la demanda pasada, proyección por horizonte y nivel de agregación, y traducción a carga de trabajo | Módulo de previsión de demanda sobre los modelos industriales de la plataforma |
| Salida | Dashboards, reglas, alertas, eventos, reporting y devolución por API a ERP, MES, CRM o SAP | Captia.ai, y el sistema de gestión donde se planifica |
Conviene separarlo de su módulo hermano. El módulo de forecasting proyecta la evolución futura de una variable a partir de su comportamiento pasado, sea consumo, temperatura o caudal, y es una capacidad genérica de serie temporal. Previsión de demanda es una aplicación acotada de esa capacidad con dos rasgos propios: su variable objetivo no se mide con un sensor sino que se lee del ERP y del MES, y su salida está formulada en el lenguaje del dimensionado. Si lo que se busca es proyectar una señal de proceso, el módulo correcto es forecasting. Si lo que se busca es saber cuántos turnos abrir el mes que viene, es este.
Requisitos de datos: qué hace falta antes de activarlo
El requisito duro, y el que decide si el proyecto es viable, es la integración con ERP y MES. Sin ella el módulo solo ve producción pasada, y la producción pasada es una respuesta censurada: no registra el pedido que se rechazó por falta de capacidad, ni el que se sirvió tarde, ni el que se canceló. Un modelo entrenado únicamente contra producción aprende el límite de la fábrica, no la demanda del mercado, y reproduce ese límite hacia el futuro. Esa integración es un trabajo de ingeniería con nombre propio, descrito en el servicio de integración con ERP de Captia Connect.
El segundo requisito es un maestro de referencias estable y compartido. Si el ERP llama a un producto de una forma y el MES de otra, y ninguno coincide con lo que la planta escribe en el parte, no hay serie histórica que reconstruir: hay varias series cortas de artículos que el sistema cree distintos. Reconciliar códigos, familias y unidades de medida no es preparación del proyecto, es el proyecto.
El tercero es histórico suficiente para que el patrón esté representado. La demanda industrial casi siempre tiene estacionalidad, y una estacionalidad anual no se aprende con menos de un ciclo completo: hacen falta varios para separar la estación del ruido. El alcance concreto se fija en el diagnóstico, no por defecto, y depende del horizonte que se quiera cubrir.
El cuarto es el registro de las excepciones. Una promoción, una parada de un cliente grande, un cambio de gama o la entrada de un competidor son eventos que explican saltos de demanda. Si están anotados en algún sitio del ERP, el módulo puede tratarlos como lo que son. Si no lo están, quedan como ruido inexplicable y degradan cualquier proyección futura.
El quinto es la definición de la unidad de decisión. Previsión por referencia, por familia o por línea son proyectos distintos con requisitos de dato distintos, y la elección la marca la decisión que se va a tomar, no la ambición del modelo. Prever a nivel de referencia cuando la decisión es de turnos añade error sin añadir información. La teoría de por qué la agregación reduce el error relativo está en la guía de forecast industrial.
Casos de aplicación industrial
El caso más recurrente es el dimensionado de turnos y personal. La decisión de abrir un tercer turno, contratar temporales o parar una línea se toma con semanas de antelación y casi siempre con la cartera de pedidos en la mano y poco más. Una previsión que traduzca la demanda proyectada a horas de línea necesarias, y que además avise cuando esas horas superan la capacidad instalada, cambia el momento en que se toma la decisión.
El segundo caso es el aprovisionamiento de material con plazo largo. Cuando el plazo de entrega de un componente supera el horizonte de la cartera firme, la compra se hace por fuerza contra una previsión. Aquí el valor del módulo no es acertar, es hacer explícito contra qué previsión se está comprando y dejar registrado en la plataforma cómo evoluciona esa previsión frente a lo que finalmente ocurre.
El tercero es el dimensionado de stock de producto terminado en plantas con demanda irregular. Cuando la variabilidad es alta, la previsión sirve menos para fijar una cifra que para dimensionar el colchón que absorbe el error, y para saber en qué referencias ese colchón es caro y en cuáles es barato.
El cuarto es la detección de desviación entre lo previsto y lo real, que es donde la previsión se vuelve una herramienta de control y no solo de planificación. Con reglas y alertas en Captia.ai, una desviación sostenida deja de descubrirse en la reunión de cierre de mes y pasa a ser un evento trazable con fecha.
El quinto es el enlace con la energía. Una previsión de demanda es también una previsión de carga de planta, y por tanto una entrada natural para el módulo de optimización de producción y consumo cuando se busca el punto de operación que equilibra producción y consumo.
Cómo se implanta por fases
La implantación sigue las mismas fases que el resto de la plataforma, descritas en el hub de plataforma de datos industriales, con una particularidad: en este módulo el trabajo pesado está en la fase de integración, no en la de modelado.
- Diagnóstico. Qué decisión se quiere mejorar, con qué antelación se toma hoy y con qué información. De ahí salen el horizonte, el nivel de agregación y la periodicidad, que son los tres parámetros que definen el módulo.
- Integración con ERP y MES. Acceso a pedidos, cartera y maestro de referencias, reconciliación de códigos y unidades, y contraste con la producción registrada. Es la fase que decide la viabilidad y la que más suele durar.
- Despliegue del edge. Captia Connect en planta para que la producción real quede registrada con marca de tiempo homogénea y no dependa de un parte manual.
- Puesta en marcha de la plataforma. Dashboards de demanda y carga por línea o planta, usuarios y roles, y las primeras reglas de aviso por capacidad.
- Inteligencia. Con histórico consolidado y contexto suficiente se activa el módulo de previsión de demanda. Antes de este punto no tiene sobre qué trabajar.
- Operacionalización. Workflows, reporting periódico y devolución por API al ERP o al MES, más el seguimiento continuo de la desviación entre previsión y realidad, que es lo que mantiene el módulo honesto con el paso del tiempo.
| Horizonte | Decisión que dimensiona | Dato que la condiciona |
|---|---|---|
| Corto | Secuencia y asignación de líneas dentro del plan ya comprometido | Cartera firme del ERP y estado real de máquina capturado por Connect |
| Medio | Turnos, personal y compra de material con plazo de entrega | Previsión comercial, estacionalidad del histórico y plazos del proveedor |
| Largo | Capacidad instalada, inversión en línea y política de stock | Varios ciclos de histórico y las excepciones registradas que explican los saltos |
Límites y cuándo no aplica
Conviene decirlo con claridad, porque este es el módulo que más proyectos mal planteados genera. Previsión de demanda no aplica, o aporta poco, en estos escenarios:
- Sin integración con ERP o MES. Es el límite duro. Con solo producción registrada el módulo proyecta lo que la planta pudo hacer, no lo que el mercado pidió, y hereda cualquier restricción de capacidad pasada como si fuera demanda. Lo que falta entonces es integración, no analítica.
- Con pocos clientes y demanda por proyecto. Si la facturación depende de un puñado de contratos grandes y discretos, la demanda no es una serie temporal: es una secuencia de decisiones comerciales. Ahí una conversación con el cliente informa mejor que cualquier modelo, y el módulo solo puede aportar contexto histórico.
- Ante rupturas estructurales. Un cambio de gama, la entrada en un mercado nuevo, una fusión o la pérdida de un cliente principal invalidan el pasado como referencia. El módulo no sabe lo que aún no ha ocurrido, y ninguna técnica lo arregla.
- Cuando el maestro de referencias no es estable. Si los códigos cambian, se duplican o no se corresponden entre sistemas, no existe la serie histórica que hay que proyectar. Primero se reconcilia el maestro, después se prevé.
- Cuando la planta no tiene margen de dimensionado. Si el turno es fijo por convenio, la línea trabaja al límite y no hay decisión de compra que tomar, saber la demanda futura no cambia ninguna acción. Sigue sirviendo para justificar inversión, pero no para operar.
- Cuando lo que se busca es proyectar una señal de proceso. Para una variable medida por sensor, el módulo adecuado es forecasting, no este.
Y dos límites transversales. El primero: toda previsión tiene error, y el trabajo del módulo no es eliminarlo sino hacerlo visible y estable para que las decisiones de dimensionado se tomen sabiendo cuánto margen dejar. El segundo: el módulo propone y evidencia, no lanza órdenes de fabricación ni de compra por su cuenta. La acción se ejecuta con las reglas y los workflows de Captia.ai que el equipo define y supervisa.