¿Qué hace cuando pronostica un artículo con demanda intermitente, como una pieza de repuesto, con una demanda promedio de menos de una unidad por mes? La mayor parte del tiempo la demanda es cero, pero la parte es significativa en un sentido comercial; no se puede ignorar y se debe pronosticar para asegurarse de tener el stock adecuado.

Tus elecciones tienden a centrarse en algunas opciones:

Opción 1: Redondea a 1 cada mes, por lo que tu pronóstico anual es 12.

Opción 2: Redondee a 0 cada mes, de modo que su pronóstico anual sea 0.

Opción 3: método de pronóstico "igual que el mismo mes del año pasado" para que el pronóstico coincida con el real del año pasado.

Hay desventajas obvias para cada opción y no mucha ventaja para ninguna de ellas. La opción 1 a menudo resulta en un sobre pronóstico significativo. La opción 2 a menudo da como resultado una previsión significativamente inferior a la esperada. La opción 3 da como resultado un pronóstico que casi garantiza que perderá significativamente el real, ya que no es probable que la demanda aumente exactamente en el mismo período. Si DEBE pronosticar el artículo, normalmente recomendaríamos la opción 3, ya que es la respuesta más probable que el resto de la empresa entendería. 

Pero una mejor manera es no pronosticarlo en absoluto en el sentido habitual y, en su lugar, utilizar un "punto de reorden predictivo" relacionado con el nivel de servicio deseado. Para calcular un punto de reorden predictivo, puede usar el algoritmo de arranque de Markov patentado de Smart Software para simular todas las demandas posibles que podrían ocurrir durante el tiempo de entrega, luego identifique el punto de reorden que producirá su nivel de servicio objetivo.

Luego, puede configurar su sistema ERP para pedir más cuando el inventario disponible supere el punto de reorden en lugar de cuando se pronostique que llegará a cero (o cualquier reserva de existencias de seguridad que se ingrese). 

Esto hace que los pedidos tengan más sentido común sin las suposiciones innecesarias que se requieren para pronosticar una pieza de bajo volumen demandada intermitentemente.

Si últimamente tenías la cabeza en alto, es posible que hayas notado alguna locura adicional fuera de la cancha de baloncesto: el fracaso del Silicon Valley Bank. Aquellos de nosotros en el mundo de la cadena de suministro tal vez hayamos descartado la quiebra del banco como un problema de otra persona, pero ese lamentable episodio también contiene una gran lección para nosotros: la importancia de hacer bien las pruebas de estrés.

Él El Correo de Washington Recientemente se publicó un artículo de opinión de Natasha Sarin llamado “Los reguladores se perdieron los problemas de Silicon Valley Bank durante meses. Este es el por qué." Sarin describió las fallas en el régimen de pruebas de estrés impuesto al banco por la Reserva Federal. Un problema es que las pruebas de estrés son demasiado estáticas. El factor de estrés de la Fed para el crecimiento del PIB nominal fue un escenario único que enumeraba valores supuestos durante los próximos 13 trimestres (ver Figura 1). Esas 13 proyecciones trimestrales pueden ser la opinión consensuada de alguien sobre cómo se vería un mal día para el cabello, pero esa no es la única forma en que podrían desarrollarse las cosas. Como sociedad, se nos enseña a apreciar una mejor manera de mostrar las contingencias cada vez que el Servicio Meteorológico Nacional nos muestra las trayectorias proyectadas de los huracanes (consulte la Figura 2). Cada escenario representado por una línea de color diferente muestra una posible trayectoria de tormenta, y las líneas concentradas representan la más probable. Al exponer las rutas de menor probabilidad, se mejora la planificación de riesgos.

Al realizar pruebas de estrés en la cadena de suministro, necesitamos escenarios realistas de posibles demandas futuras que podrían ocurrir, incluso demandas extremas. Smart proporciona esto en nuestro software (con mejoras considerables en nuestros métodos Gen2). El software genera una gran cantidad de escenarios de demanda creíbles, suficientes para exponer el alcance completo de los riesgos (consulte la Figura 3). Las pruebas de estrés tienen que ver con la generación de cantidades masivas de escenarios de planificación, y los métodos probabilísticos de Smart son una desviación radical de las aplicaciones S&OP deterministas anteriores, ya que se basan completamente en escenarios.

La otra falla en las pruebas de estrés de la Fed fue que fueron diseñadas con meses de anticipación pero nunca actualizadas para las condiciones cambiantes. Los planificadores de la demanda y los gerentes de inventario aprecian intuitivamente que las variables clave como la demanda de artículos y el tiempo de entrega del proveedor no solo son muy aleatorias, incluso cuando las cosas son estables, sino que también están sujetas a cambios abruptos que deberían requerir una reescritura rápida de los escenarios de planificación (consulte la Figura 4, donde la demanda promedio salta dramáticamente entre las observaciones 19 y 20). Los productos Gen2 de Smart incluyen nueva tecnología para detectar tales "cambios de régimen” y cambiando automáticamente los escenarios en consecuencia.

Los bancos se ven obligados a someterse a pruebas de estrés, por muy defectuosas que sean, para proteger a sus depositantes. Los profesionales de la cadena de suministro ahora tienen una manera de proteger sus cadenas de suministro mediante el uso de un software moderno para realizar pruebas de estrés de sus planes de demanda y decisiones de gestión de inventario.

Figura 1: Escenarios utilizados por la Fed para hacer pruebas de estrés a los bancos.

Figura 2: Escenarios utilizados por el Servicio Meteorológico Nacional para predecir las trayectorias de los huracanes

Figura 3: Escenarios de demanda del tipo generado por Smart Demand Planner

Figura 4: Ejemplo de cambio de régimen en la demanda del producto después de la observación #19

¿Cuál es la diferencia y por qué es importante para la planificación del inventario?

Aquellos que son nuevos en el juego de planificación de piezas a menudo se confunden con las muchas variaciones en los nombres de las piezas. Este blog señala distinciones que tienen o no importancia operativa para alguien que administra una flota de piezas de repuesto y cómo esas diferencias afectan la planificación del inventario.

Por ejemplo, ¿cuál es la diferencia entre piezas de "repuesto" y piezas de "reemplazo"? En este caso, la diferencia es su origen. Se compraría una pieza de repuesto al fabricante del equipo, mientras que una pieza de repuesto se compraría a otra empresa. Para alguien que administra una flota de repuestos, la diferencia sería dos entradas diferentes en su base de datos de piezas: la fuente sería diferente y el precio unitario probablemente sería diferente. Es posible que también haya una diferencia en la vida útil de las piezas de las dos fuentes. Las piezas "OEM" pueden ser más duraderas que las piezas más baratas del "mercado de accesorios". (Ahora tenemos cuatro términos diferentes que describen estas piezas). Estas distinciones serían importantes para optimizar un inventario de repuestos. El software que calcula los puntos de pedido óptimos y las cantidades de los pedidos llegaría a diferentes respuestas para piezas con diferentes costos unitarios y diferentes tasas de reemplazo.

Quizás la distinción más grande es entre partes "consumibles" y "reparables" o "giratorias". La distinción clave entre ellos es su costo. Es una tontería tratar de reparar un tornillo desgastado; simplemente tíralo y usa otro. Pero también es una tontería tirar un componente de $50,000 si se puede reparar por $5,000. Optimizar la gestión de inventario para flotas de cada tipo de pieza requiere matemáticas muy diferentes. Con los consumibles, las partes pueden considerarse anónimas e intercambiables. Con los “giratorios”, cada parte debe modelarse esencialmente de forma individual. Tratamos a cada uno como un ciclo a través de estados de "operativo", "en reparación" y "en espera/repuesto". Las decisiones sobre piezas reparables a menudo se manejan mediante un proceso de presupuesto de capital, y la pregunta analítica más destacada es "¿cuál debería ser el tamaño de nuestro grupo de repuestos?"

Hay otras distinciones que se pueden hacer entre las partes. La criticidad es un atributo importante. Las consecuencias de la falla de una pieza pueden variar desde “podemos tomarnos nuestro tiempo para obtener un reemplazo” hasta “esto es una emergencia; que esas máquinas vuelvan a funcionar pronto”. Al determinar cómo administrar las piezas, siempre debemos lograr un equilibrio entre los beneficios de tener un mayor stock de piezas y los costos en dólares. La criticidad cambia el equilibrio hacia ir a lo seguro con inventarios más grandes. A su vez, esto dicta objetivos de planificación más altos para las métricas de disponibilidad de piezas, como los niveles de servicio y las tasas de llenado, lo que conducirá a mayores puntos de pedido y/o cantidades de pedidos.

Si buscas en Google “tipos de repuestos”, descubrirás otras clasificaciones y distinciones. Desde nuestra perspectiva en Smart Software, las palabras importan menos que los números asociados con las piezas: costos unitarios, tiempo medio antes de la falla, tiempo medio de reparación y otros aportes técnicos a nuestros productos que resuelven cómo administrar las piezas para obtener el máximo beneficio.

A menudo nos encontramos con métodos de planificación de puntos de pedido basados en Excel. En esta publicación, detallamos un enfoque que utilizó un cliente antes de continuar con Smart. Describimos cómo funcionaba su hoja de cálculo, los enfoques estadísticos en los que se basaba, los pasos que los planificadores siguieron en cada ciclo de planificación y sus motivaciones declaradas para usar (y realmente gustarles) esta hoja de cálculo desarrollada internamente.

Su proceso mensual consistía en actualizar un nuevo mes de datos reales en la "hoja de puntos de pedido". Una fórmula incrustada volvió a calcular el punto de pedido (ROP) y el nivel de pedido hasta (máx.). Funcionó así:

• ROP = Demanda LT + Stock de Seguridad
• Demanda LT = demanda diaria promedio x días de tiempo de entrega (se supone constante para simplificar las cosas)
• Inventario de seguridad para piezas con plazos de entrega prolongados = Desviación estándar x 2,0
• Stock de seguridad para piezas con plazos de entrega cortos = Desviación estándar x 1,2
• Max = ROP + cantidad mínima de pedido dictada por el proveedor

Los promedios históricos y las desviaciones estándar utilizaron 52 semanas de historial continuo (es decir, la semana más nueva reemplazó a la semana más antigua en cada período). La desviación estándar de la demanda se calculó utilizando la función "stdevp" en Excel.

Cada mes, se volvió a calcular un nuevo ROP. Tanto la demanda promedio como la desviación estándar fueron modificadas por la demanda de la nueva semana, que a su vez actualizó la ROP.

El ROP predeterminado siempre se basa en la lógica anterior. Sin embargo, los planificadores harían cambios bajo ciertas condiciones:

1. Los planificadores aumentarían el Min para piezas económicas para reducir el riesgo de recibir un golpe de entrega a tiempo (OTD) en una pieza económica.

2. La hoja de Excel identificó cualquier parte con una ROP recién calculada que era ± 20% diferente de la ROP actual.

3. Los planificadores revisaron las piezas que superaban el umbral de excepción, propusieron cambios y obtuvieron la aprobación de un gerente.

4. Los planificadores revisaron los elementos con aciertos OTD y aumentaron el ROP en función de su intuición. Los planificadores continuaron monitoreando esas partes durante varios períodos y bajaron el ROP cuando sintieron que era seguro.

5. Una vez que se determinaron el ROP y la cantidad máxima, el archivo de resultados revisados se envió a TI, quien lo cargó en su ERP.

6. El sistema ERP luego gestionaba el reabastecimiento diario y la gestión de pedidos.

Objetivamente, este fue quizás un enfoque superior al promedio para la gestión de inventario. Por ejemplo, algunas empresas desconocen el vínculo entre la variabilidad de la demanda y los requisitos de existencias de seguridad y confían exclusivamente en la regla de los métodos o la intuición. Sin embargo, hay problemas con su enfoque:

1. Actualizaciones manuales de datos
Las hojas de cálculo requerían actualización manual. Para volver a calcular, se requerían varios pasos, cada uno con su propia dependencia. Primero, era necesario ejecutar un volcado de datos desde el sistema ERP. En segundo lugar, un planificador necesitaría abrir la hoja de cálculo y revisarla para asegurarse de que los datos se hayan importado correctamente. En tercer lugar, necesitaban revisar el resultado para asegurarse de que se calculó como se esperaba. En cuarto lugar, se requerían pasos manuales para devolver los resultados al sistema ERP.

2. Talla única para todas las existencias de seguridad
O en este caso, “una de dos tallas sirve para todos”. La elección de utilizar una desviación estándar de 2x y 1,2x para artículos con plazos de entrega largos y cortos, respectivamente, equivale a niveles de servicio de 97,71 TP3T y 88,41 TP3T. Este es un gran problema ya que es lógico que no todas las partes de cada grupo requieran el mismo nivel de servicio. Algunas partes tendrán un mayor dolor por falta de existencias que otras y viceversa. Por lo tanto, los niveles de servicio deben especificarse en consecuencia y ser proporcionales a la importancia del artículo. Descubrimos que estaban experimentando golpes OTD en aproximadamente 20% de sus piezas de repuesto críticas, lo que requería anulaciones manuales del ROP. La causa raíz fue que en todos los artículos con plazos de entrega cortos estaban planificando un objetivo de nivel de servicio de 88.4%. Por lo tanto, lo mejor que pudieron haber obtenido fue almacenar 12% de ese momento, incluso si "según el plan". Hubiera sido mejor planificar objetivos de nivel de servicio de acuerdo con la importancia de la pieza.

3. El inventario de seguridad es inexacto.  Los artículos que se planean para esta empresa son repuestos para apoyar equipos de diagnóstico. La demanda en la mayoría de estas partes es muy intermitente y esporádica. Por lo tanto, la elección de usar un promedio para calcular la demanda de tiempo de entrega no era irrazonable si acepta la necesidad de ignorar la variabilidad en los tiempos de entrega. Sin embargo, la confianza en un Distribución normal determinar el inventario de seguridad fue un gran error que resultó en inventarios de seguridad inexactos. La empresa declaró que sus niveles de servicio para artículos con plazos de entrega prolongados se encontraban en el rango de 90% en comparación con su objetivo de 97,7%, y que compensaron la diferencia con los envíos urgentes. Los niveles de servicio logrados para artículos con plazos de entrega más cortos fueron de aproximadamente 80%, a pesar de que el objetivo era 88,4%. Calcularon las existencias de seguridad de forma incorrecta porque su demanda no tiene "forma de campana", pero eligieron las existencias de seguridad asumiendo que así era. Esta simplificación da como resultado la falta de objetivos de nivel de servicio, lo que obliga a la revisión manual de muchos elementos que luego deben ser "supervisados manualmente durante varios períodos" por un planificador. ¿No sería mejor asegurarse de que el punto de reorden cumpliera con el nivel de servicio exacto que deseaba desde el principio? Esto garantizaría que alcance sus niveles de servicio y minimice la intervención manual innecesaria.

Hay un cuarto problema que no está en la lista pero que vale la pena mencionar. La hoja de cálculo no pudo rastrear tendencias o patrones estacionales. Los promedios históricos ignoran la tendencia y la estacionalidad, por lo que la demanda acumulada durante el tiempo de entrega utilizada en el ROP será sustancialmente menos precisa para las piezas de tendencia o estacionales. El equipo de planificación reconoció esto pero no sintió que fuera un problema legítimo, razonando que la mayor parte de la demanda era intermitente y no tenía estacionalidad. Es importante que el modelo detecte la tendencia y la estacionalidad de los datos intermitentes, si existen, pero no encontramos que sus datos exhiban estos patrones. Entonces, acordamos que esto no era un problema. para ellos. Pero a medida que el ritmo de planificación aumenta hasta el punto de que la demanda se reparte a diario, incluso la demanda intermitente muy a menudo resulta tener una estacionalidad de día de la semana y, a veces, de semana del mes. Si no corre a una frecuencia más alta ahora, tenga en cuenta que puede verse obligado a hacerlo pronto para mantenerse al día con una competencia más ágil. En ese momento, el procesamiento basado en hojas de cálculo simplemente no podrá mantenerse al día.

En conclusión, no use hojas de cálculo. No conducen a análisis hipotéticos significativos, requieren demasiado trabajo y la lógica subyacente debe simplificarse para que el proceso sea lo suficientemente rápido como para que sea útil. En resumen, opte por soluciones especialmente diseñadas. Y asegúrese de que se ejecuten en la nube.