Honestidad sobre la incertidumbre y límites del modelo
Los límites del modelo: qué ocurre con poco histórico, las advertencias estructuradas y por qué cada recomendación es auditable, sin cajas negras.
El principio de diseño
Con poco histórico, ningún método estadístico "adivina" el futuro. Lo que distingue un sistema honesto de uno que proyecta falsa confianza no es cuánto sabe, sino cuánto declara que no sabe.
AInventory está diseñado para que cada recomendación vaya acompañada de información explícita sobre:
- La calidad del histórico del SKU (nivel de la cascada estadística).
- Qué distribución eligió el sistema y por qué.
- Si el pronóstico parece venir sesgado.
- Qué política ganó y cuál fue el costo esperado de cada una.
El objetivo es que el planificador nunca tenga que confiar a ciegas en un número: siempre puede rastrear de dónde viene.
El sistema de warnings estructurados
Los warnings siguen una estructura de cuatro severidades. Cada uno indica el nivel de la cascada estadística del SKU y el grado de confianza en la recomendación:
BLOQUEANTE — Sin histórico
El sistema no puede producir ninguna recomendación para este SKU. La severidad BLOQUEANTE significa que si el planificador acepta la recomendación sin intervención, estará tomando una decisión sin respaldo cuantitativo alguno. El SKU se marca para revisión manual obligatoria.
ALTA — Poco histórico
El sistema produce una recomendación, pero los parámetros estadísticos están estimados con alta incertidumbre (bootstrap paramétrico por Method of Moments con muy pocas observaciones). La distribución elegida puede estar bien o puede estar equivocada; con tan pocos datos, no hay forma de distinguirlo con confianza. El planificador debe tratar la recomendación como una propuesta inicial que requiere revisión.
MEDIA — Histórico moderado
La estimación es más confiable (MLE estabilizado) pero sigue siendo moderada. La prueba Shapiro-Wilk se ejecuta y puede o no rechazar la normalidad. Si no la rechaza, la distribución Normal se acepta; si la rechaza, se registra cuál distribución alternativa se usó.
INFO — Errores no normales (histórico moderado)
La prueba Shapiro-Wilk rechazó la hipótesis de normalidad en el nivel de histórico moderado. El sistema usó Gamma o Lognormal (según el argmin AIC) en lugar de Normal. Este warning es informativo —no implica que la recomendación sea incorrecta—, pero indica que el planificador debe saber que la distribución de errores no es simétrica.
INFO — Bootstrap empírico activo (producto maduro, histórico en crecimiento)
El SKU está en el nivel de producto maduro pero con un número moderado de filas de histórico disponibles. El bootstrap no paramétrico es técnicamente válido, pero su cobertura de cuantiles mejora con más datos; la recomendación es confiable y el planificador puede querer monitorearlo a medida que crece el histórico.
Trazabilidad de cada recomendación
Para cada SKU procesado, el sistema registra y expone al planificador:
- Nivel de cascada asignado y n correspondiente.
- Distribución elegida (Normal, Gamma, Lognormal o bootstrap no paramétrico) y el criterio de selección (AIC, Shapiro-Wilk o por defecto).
- Política ganadora y valor de k*, junto con el ranking de costo esperado de las cinco políticas.
- Warnings activos con su código y severidad.
- Parámetros del forecast usados como base (si el pronóstico tiene sesgo aparente, esto es visible en los errores históricos).
Ninguno de estos datos está oculto en el motor de cálculo: son parte de la salida estándar del optimizador y se presentan junto a la recomendación.
Overrides manuales y auditoría
Cuando el planificador decide no seguir la recomendación del sistema —por contexto comercial, negociación con proveedores u otro criterio que el modelo no puede capturar—, puede registrar un override manual. El sistema exige una justificación de al menos 10 caracteres antes de aceptar el override.
Todos los overrides quedan registrados en el historial de auditoría con:
- El valor recomendado por el sistema.
- El valor ingresado manualmente.
- La justificación escrita.
- El usuario y la marca de tiempo.
Esto permite auditar retrospectivamente si los overrides mejoraron o empeoraron los resultados frente a lo que hubiera hecho el sistema automáticamente. Para los detalles operativos de cómo registrar un override, ver la guía Ajustar reabastecimiento manualmente.
La combinación de warnings estructurados, trazabilidad de método y auditoría de overrides responde a una decisión de diseño: el sistema debe ser un asistente auditable, no un oráculo opaco. El planificador tiene la última palabra; el sistema tiene la obligación de mostrar su trabajo.