Problemas y soluciones comunes

La causa más común es la colisión de claves compuestas: si dos registros comparten el mismo identificador único, uno sobrescribe al otro.

También puede ocurrir si los criterios de filtro de la asignación de datos excluyen los registros que espera ver.

Los pedidos gestionados o retirados entre la ejecución de los informes desaparecerán en la próxima actualización, pero es posible que sigan apareciendo en las excepciones generadas a partir de los datos del día anterior.

Los pedidos recién creados no aparecerán hasta la próxima actualización de datos.

El sistema filtrará automáticamente hasta el producto maestro. En la previsión solo se incluirán los productos presentes en tu archivo maestro de productos. Sin embargo, si un gran porcentaje de tu archivo de entrada está fuera del alcance (por ejemplo, más del 50% de las filas), esto indica que es necesario ajustar la exportación de origen.

Comprueba el índice de cobertura de tus productos con regularidad. Después de cada carga de datos, verifica qué porcentaje de productos de tus archivos de entrada de ventas y previsiones coinciden con el producto maestro. Si la cobertura cae por debajo del 80%, investiga si el alcance de exportación de origen ha cambiado o si es necesario actualizar el producto maestro.

Out-of-scope los productos incluidos en los insumos del plan pueden provocar que los totales sean inflados. Si sus archivos EDI o SIOP incluyen productos de otras plantas, la señal de previsión agregada será mayor de lo que debería ser. Antes de cargarlos, asegúrate de filtrar los archivos de entrada del plan según el mismo tipo de producto que el de tu producto maestro.

Comprueba la fecha y hora de la excepción: si tiene más de un día, es posible que la recomendación esté obsoleta.

Si la recomendación es claramente errónea (por ejemplo, ignora un pedido grande que aparece en el gráfico), envía tus comentarios con el pulgar hacia abajo e informa de la excepción específica a tu equipo de soporte.

La fecha de impacto muestra cuándo comienza el problema del inventario (por ejemplo, cuando se agotan las existencias o el exceso supera el umbral).

La fecha límite debe tener en cuenta el plazo de entrega para que tengas tiempo de actuar antes de que el problema se materialice. Si Act By coincide con la fecha de impacto, es posible que no se incorpore el plazo de entrega; comuníquelo a su equipo de soporte.

Hay demasiados volume/inactive productos de bajo alcance. Los productos con una demanda escasa e intermitente son difíciles de superar para cualquier modelo en un promedio simple. Usa una regla de preprocesamiento para adaptar la previsión a productos con un historial de demanda significativo (por ejemplo, al menos 6 meses de demanda distinta de cero).

Capacitación sobre el historial obsoleto o contaminado. Si su historial de pedidos se remonta a muchos años, es posible que los patrones de demanda antiguos no reflejen la realidad actual. Considera la posibilidad de aplicar una regla de preprocesamiento para limitar el historial de formación a los 3 o 5 años más recientes, o para reemplazar los períodos anómalos (por ejemplo, el COVID) por valores normalizados.

La demanda se dispara debido a los pedidos únicos. Un solo pedido grande al por mayor puede crear una falsa tendencia al alza en los datos de entrenamiento. Usa una regla de preprocesamiento para limitar los valores de demanda mensual anómalos a un múltiplo de la media final (por ejemplo, 5 veces).

Las reglas de consenso se aplicaron en una dirección equivocada. El agente de LLM puede malinterpretar el lenguaje de las reglas. Se puede aplicar la expresión «disminución del 27%» como aumento. Compare siempre los resultados del consenso comparándolos con los valores de referencia comparando productos y meses específicos. Usa un lenguaje de multiplicación explícito («multiplica por 0,725») en lugar de un lenguaje direccional («disminuye un 27,5% «).

El modelo se basa en un período de crecimiento. Si los últimos años mostraron un crecimiento que no continúa, el modelo extrapola una tendencia que ya no existe.

Las reglas de consenso están acumulando ajustes al alza. Cada una de las reglas que aumentan la previsión (sesgo de desabastecimiento, aumento de la tendencia, aumento estacional) pueden agravarse. Revisa qué reglas están activas y comprueba si todas se aplican a los mismos productos.

Deleted/discontinued los productos aún están dentro del ámbito de aplicación. Los productos con una demanda a la baja que aún se están pronosticando mostrarán una sobreprevisión sistemática.

Las señales de previsión externas no se están incorporando. Si tienes datos del plan cargados (por ejemplo, previsiones de clientes mediante EDI o planes de producción SIOP) pero tus reglas de consenso no los aplican, la previsión se ajusta de forma predeterminada a la línea de base estadística, que puede no captar las señales de demanda que ven tus planificadores. Comprueba que las reglas de consenso modifican realmente el resultado comparando la exportación con la ConsensusForecast exportación de la previsión (referencia). Si son idénticas, las reglas no se activan.

Las escasas combinaciones de productos y sitios hacen que el agregado disminuya. Si realiza pronósticos con una granularidad entre producto y sitio, pero muchas combinaciones tienen una demanda cero o cercana a cero, el modelo produce pronósticos pequeños distintos de cero para las combinaciones inactivas. Estas no suman mucho de forma individual, sino que, en conjunto, hacen que la previsión total quede por debajo de los valores reales. Usa una regla de preprocesamiento para excluir las combinaciones con un historial de demanda insuficiente, o rellena tu plan de forma condicional con cero para indicar de forma explícita que «no se espera demanda» en el caso de las combinaciones inactivas.

El modelo no ha captado ninguna tendencia de crecimiento reciente. Los modelos estadísticos ponderan los datos históricos. Si su empresa ha crecido significativamente en los últimos meses, pero el modelo tiene años de historial de menor volumen, estará a la zaga de la tendencia. Por lo general, esto mejora con el tiempo a medida que el modelo acumula datos más recientes. Mientras tanto, considere una regla de consenso que utilice un promedio final de los datos reales recientes como base para las semanas de pronóstico externas.

Year-over-year desajuste de estacionalidad. Si el patrón de demanda de este año difiere del de años anteriores (por ejemplo, un aumento estacional más temprano, lanzamientos de nuevos productos), es posible que el modelo subestime las previsiones durante el período divergente. Compruebe si el sesgo insuficiente se concentra en semanas o meses específicos que difieran del patrón del año anterior.

Las señales externas solo ayudan a corto plazo. Si tiene reglas de consenso que incorporan las previsiones de los clientes (EDI) durante las primeras semanas, la precisión mejorará notablemente a corto plazo y disminuirá cuando las reglas dejen de aplicarse. Esto es lo que se espera. Considera la posibilidad de ampliar las normas para que abarquen más semanas con un enfoque combinado (por ejemplo, una 50/50 combinación de señales externas y puntos de referencia para las semanas a medio plazo).

La base de referencia vuelve a ser una media a largo plazo en horizontes más largos. Los modelos estadísticos pierden confianza en horizontes más largos y tienden hacia la media histórica. Si la demanda reciente está por encima de la media histórica, las últimas semanas parecerán poco sesgadas. Se trata de un comportamiento del modelo, no de un problema de configuración.

La volatilidad de la demanda hace que los horizontes más largos sean intrínsecamente más difíciles. Si su demanda tiene una alta variabilidad de una semana a otra (coeficiente de variación > 0,5), incluso un modelo perfecto mostrará un error alto en horizontes más largos. Concentre la evaluación de la precisión en las primeras 3 a 4 semanas, que es el período de planificación práctico para la mayoría de las operaciones.

Es posible que la señal externa no cubra suficientes productos. Por lo general, las previsiones de EDI o de los clientes solo cubren un subconjunto de su catálogo de productos (normalmente entre un 30 y un 50%). Los productos sin señal externa siguen utilizando la línea de base. Comprueba tu tasa de cobertura: si está por debajo del 50%, el impacto en la precisión global será limitado.

Es posible que la señal externa no sea lo suficientemente precisa como para ayudar. Mida la precisión de la previsión externa de forma independiente antes de utilizarla en las reglas. Si su WAPE es peor que el valor de referencia, incorporarlo perjudicará en lugar de ayudar. Considere la posibilidad de limitar la regla a sitios o productos específicos en los que se demuestre que la señal externa es mejor (por ejemplo, un WAPE ponderado por volumen inferior al 50%).

La señal externa no indica ceros. Muchos sistemas EDI solo envían registros de productos con pedidos activos; omiten los productos sin demanda en lugar de informar explícitamente de cero. Si tu regla de consenso dice «si el EDI es igual a 0, establece la previsión en 0», nunca se activará porque no hay ningún registro. Es necesario generar cero registros sintéticos durante el preprocesamiento para las combinaciones de producto y sitio que no tengan una señal externa ni un historial de ventas reciente.

La precisión de la señal externa varía según el horizonte. Las previsiones de los clientes suelen ser más precisas para la próxima semana inmediata (básicamente pedidos confirmados) y se degradan rápidamente. Una regla que utilice la señal externa directamente durante todas las semanas puede afectar a la precisión en horizontes más largos. Considera un enfoque escalonado: reemplazo directo durante las semanas 1 a 3, combinado durante las semanas 4 a 6 y valor basal solo durante las semanas 7 o más.

Es posible que la regla haya sido invalidada por una regla de mayor prioridad. Las reglas se aplican por orden de prioridad. Una regla posterior puede deshacer una anterior. Comprueba el orden de las reglas.

Es posible que la condición de la regla no coincida con ningún producto. Si la regla hace referencia a un atributo del producto (p. ej., product_group_id) que no está en los metadatos del artículo, no coincidirá silenciosamente con nada.

El lenguaje de la regla se malinterpretó. El agente LLM genera código a partir del lenguaje natural. La redacción ambigua puede producir resultados inesperados. Sea lo más específico y literal posible. Usa nombres de campo exactos, multiplicadores explícitos y condiciones claras.

La dimensión no coincide en la unión. El motor de consenso une las entradas del plan con la línea base en las columnas de dimensiones (ID del producto, ID del sitio, fecha). Si los nombres de las columnas difieren entre las entradas de referencia y las del plan (por ejemplo, la línea base usa item_id mientras que EDI usa product_id), la unión no produce coincidencias y todas las reglas se ajustan a la línea base predeterminada. Compruebe que la asignación de dimensiones de su configuración de flujo de datos se asigne correctamente entre los dos esquemas.

El formato de fecha no coincide. La línea base puede almacenar las fechas como 2026-03-02, mientras que las entradas del plan las almacenan como 2026-03-02. T00:00:00.000Z Si la unión requiere una coincidencia exacta, las fechas que tengan en cuenta la zona horaria y las que no tengan en cuenta la zona horaria no coincidirán. Comprueba que las columnas de fechas estén convertidas al mismo formato antes de unirte.

Las entradas del plan no están cargadas. Verifique que los archivos de entrada de su plan (EDI, SIOP, etc.) se hayan ingerido correctamente. Comprueba el recuento de registros en el sistema: si no hay filas para una entrada del plan, es posible que el archivo no se haya cargado.

El forecast_id de consenso coincide con el forecast_id de referencia. Si ambas exportaciones comparten el mismo forecast_id, el motor de consenso produjo una copia directa de la línea base sin procesarla. Esto indica un problema a nivel del sistema: ponte en contacto con tu equipo de soporte con los códigos forecast_id y demand_plan_run_id.

Es posible que la condición del site/product filtro haga referencia a una columna incorrecta. Si la regla dice «aplicar a los sitios de [lista]», pero el código generado comprueba una columna que no existe o que tiene valores diferentes, es posible que el filtro pase todas las filas de forma silenciosa. Para verificarlo, comprueba de forma puntual algunos productos específicos que NO deberían estar afectados por la regla.

El orden de prioridad de las reglas puede invertirse. Las reglas se aplican como una cadena en la que las reglas posteriores prevalecen sobre las anteriores. Si se aplica una regla general (por ejemplo, «usar la base de referencia para todo») después de una regla específica (por ejemplo, «usar EDI para estos 50 sitios»), la regla general anulará la regla específica. Asegúrese de que las descripciones de las reglas indiquen claramente el orden de prioridad.

Añade una regla de redondeo como paso final de consenso. Una simple regla de «redondear al entero más cercano» que se aplica después de todas las demás reglas de consenso borrará los valores fraccionarios. Los valores inferiores a 0,5 se redondean a cero, lo que resulta apropiado para combinaciones de muy baja demanda.

Considere la posibilidad de redondear a cantidades operativas. Si tus productos se envían en tamaños de paquete estándar (por ejemplo, cajas de 12 o palés de 48), redondear al tamaño de paquete válido más cercano puede mejorar la usabilidad y la precisión de la previsión. Para ello, es necesario incluir datos sobre el tamaño del paquete en tu página maestra de productos. Comparta su MOQ o los datos sobre el tamaño del paquete con su equipo de soporte para explorar esta opción.

Compruebe la granularidad. Un producto puede tener 52 semanas de demanda a nivel de producto, pero solo 3 semanas en cualquier combinación individual de producto y sitio. Si se aplica un umbral mínimo de historial a nivel de producto y sitio, se excluirán la mayoría de las combinaciones. En su lugar, considere aplicar el umbral a nivel de producto o reducirlo significativamente.

Realice una prueba antes de la implementación. Antes de activar una regla de preprocesamiento, cuenta el número de combinaciones de producto y sitio que superan el filtro en comparación con el total actual. Si se excluye más del 20%, es probable que la regla sea demasiado agresiva. Comience con un umbral indulgente y ajústelo gradualmente.