Control de existencias en almacén

El agente de IA lee continuamente los datos de inventario del data warehouse, compara el nivel actual con el objetivo y notifica a los responsables antes de que se produzca el déficit. A diferencia de la exportación manual a Excel una vez por semana, el sistema opera de forma ininterrumpida: cada SKU crítica se verifica según un calendario, y la alerta llega en el momento en que aún hay tiempo para reaccionar. El conjunto específico de pasos se configura según los procesos de la empresa — a continuación, el escenario típico para producción y retail.

Qué hace la automatización

1. Extrae datos de inventario del data warehouse o la capa BI con la periodicidad definida — desde 15 minutos hasta una vez al día según la criticidad de la SKU.
2. Normaliza SKU, almacenes y unidades de medida — lleva los datos a una estructura de referencia unificada para que las métricas sean comparables entre ubicaciones.
3. Calcula el pronóstico de consumo para el horizonte de planificación por cada posición, considerando la demanda histórica, la estacionalidad y los pedidos abiertos en el sistema.
4. Compara el nivel actual de inventario con el mínimo permitido (safety stock) y con el punto de agotamiento previsto.
5. Determina qué posiciones requieren reacción: por debajo del nivel crítico en este momento o que lo rebasarán dentro del horizonte de planificación.
6. Envía alertas estructuradas a Slack, Telegram o email indicando SKU, almacén, inventario actual, pronóstico y responsable.
7. Registra los eventos en el log — para auditoría, análisis de incidentes y análisis retrospectivo de la precisión del pronóstico.
8. Genera un digest periódico de inventarios para el responsable del área — sin necesidad de elaborar el informe manualmente.

Qué NO hace la automatización

• No realiza pedidos a proveedores de forma automática. El trigger de compra sigue siendo responsabilidad del comprador o del director — el sistema prepara la decisión, no la toma.
• No reemplaza el ERP ni lleva el registro de movimientos. Opera sobre los sistemas de registro existentes como capa analítica, no como fuente de verdad.
• No garantiza la precisión del pronóstico con datos inestables. Si el historial de ventas contiene vacíos, duplicados o promociones sin etiquetar, el agente de IA cometerá errores — y ese es el límite honesto del método.

La automatización está construida como una solución custom-code sobre el data warehouse o la capa BI existente de la empresa. El agente de IA actúa como orquestador: lee las fuentes, ejecuta el módulo de pronóstico, aplica las reglas de negocio y transfiere el resultado al canal de notificaciones. Todo lo relacionado con el registro de movimientos permanece en el ERP — el sistema no duplica sus funciones.

Flujo de datos

1. Conector al data warehouse: el agente de IA accede al data mart de existencias e historial de ventas mediante conexión SQL o BI API.
2. Capa de normalización: correlaciona los catálogos de SKU, almacenes y unidades de medida. Si la empresa dispone de varios sistemas contables, esta capa los unifica en un formato común.
3. Módulo de pronóstico: calcula el consumo esperado por cada SKU en el horizonte de planificación. El método depende de la estabilidad de la demanda — desde la media móvil hasta un modelo ML con componentes estacionales.
4. Reglas de control: a la salida del pronóstico se aplican reglas de negocio — safety stock mínimo, tiempo de reposición del proveedor, prioridad de SKU.
5. Motor de notificaciones: las alertas generadas se envían a Slack o Telegram (canal Communications) con reglas de routing — qué grupo de SKU corresponde a qué responsable.
6. Capa de logging: cada evento, cada alerta, cada cambio de pronóstico se escribe en un almacenamiento separado para su análisis a posteriori.

Cómo está estructurada la implementación

1. Realizar una auditoría de las fuentes de datos: dónde se encuentran las existencias, dónde el historial de ventas, con qué retraso se actualizan, qué calidad tienen los catálogos.
2. Recopilar las reglas de negocio sobre safety stock y prioridades de SKU — con el responsable de compras y el director operativo.
3. Seleccionar el método de pronóstico por grupos de SKU: para la demanda estable es suficiente la media móvil, para las posiciones estacionales se necesita un modelo independiente.
4. Implementar el conector al data warehouse y la capa de normalización, verificar la reproducibilidad de los cálculos en datos históricos.
5. Configurar el motor de notificaciones con un canal de prueba y validar el formato de las alertas con los destinatarios finales — texto, frecuencia, agrupación.
6. Realizar un lanzamiento paralelo (shadow run) durante 2-4 semanas: el sistema genera alertas, pero la respuesta sigue siendo manual — esto proporciona material para la calibración.
7. Pasar al modo de producción, establecer un SLA de respuesta y comenzar a recopilar métricas de precisión del pronóstico y déficits omitidos.

Componentes de la solución

El enfoque custom-code no se elige al azar: las plataformas low-code estándar no gestionan bien la lógica contable no estándar — almacenes multinivel, movimientos internos, consignación. Para empresas con una estructura simple es posible una implementación más sencilla; para fabricantes y retailers con varias fuentes contables, el custom-code se amortiza.

La automatización requiere una fuente de datos estable y una jerarquía de almacén gestionable. A continuación — qué debe estar listo en la empresa antes del inicio de la implementación.

Datos y accesos

• Data warehouse o capa BI con una vista de existencias por SKU y almacenes, actualizada al menos una vez al día.
• Historial de ventas o consumo de al menos 6-12 meses — sin esto el módulo de pronóstico no podrá calibrarse.
• Un directorio único de SKU o reglas de mapeo definidas entre los sistemas contables, si hay varios.
• Acceso (read-only) a las fuentes mediante SQL, BI API o exportación programada.
• Canal de notificaciones en Communications — workspace de Slack o Telegram listo con permisos de bot.

Preparación del equipo

• Un responsable por parte de operaciones — un comprador o director de área que define el safety stock y las prioridades de SKU.
• Data engineer o analista con acceso al data warehouse — al menos en la fase de implementación.
• Responsable del proceso de compras que aprueba el SLA de respuesta a las alertas.

Plazos de implementación

Para un proyecto típico con un data warehouse y un canal de notificaciones, el plazo desde el inicio hasta el lanzamiento en producción es de 6-10 semanas. De estas, 1-2 semanas se destinan a la auditoría de datos, 2-4 semanas — a la implementación del conector, el módulo de pronóstico y las reglas, 2-4 semanas — al shadow run y la calibración. Las empresas con varios sistemas contables heterogéneos o con una estructura de almacén compleja superan estos plazos — en tales casos, la implementación se discute por separado.