ENTREGA ORIENTADA AL PRODUCTO PARA LA CADENA DE SUMINISTRO (RESUMEN DE LA CONFERENCIA 1.3)

El objetivo de la optimización de la cadena de suministro (SCO) es entregar o mejorar una aplicación de software que automatice una serie costosa de decisiones repetitivas y mundanas, liberando así el ancho de banda gerencial para asuntos más urgentes. Esta aplicación, al igual que la cadena de suministro en sí, debe considerarse un activo en lugar de un costo operativo, dada su inherente y a largo plazo valor para la organización. Sin embargo, los requisitos de software para dicho activo van mucho más allá del alcance de las teorías y herramientas convencionales de la cadena de suministro, incluido el intrépido Excel, que es un elemento básico en la oficina.

Ver la conferencia

La cadena de suministro no es OpEx

Las metodologías tradicionales de la cadena de suministro tienden a aprovechar la mano de obra en lugar del software. Esto se refleja en equipos de empleados con hojas de cálculo de Excel, que diseñan y revisan decisiones de manera manual casi a diario. Los principales efectos secundarios de esto son un mayor gasto general y un aumento en la lucha contra incendios, sin mencionar las enormes cantidades de ancho de banda dedicadas al procesamiento y abordaje manual de las innumerables excepciones y emergencias comunes en la cadena de suministro.

La cadena de suministro, como se expresó anteriormente, se trata como un gasto operativo (OpEx), que se refiere a los gastos diarios incurridos en la operación de un negocio. Esta designación refleja una grave falta de comprensión de la verdadera relación de la cadena de suministro con un negocio. Sin embargo, dado los vastos recursos que deben dedicarse a mantener las orquestaciones tradicionales de la cadena de suministro, no es sorprendente la clasificación de OpEx.

En un sistema de cadena de suministro tradicional, el salario, los beneficios, la capacitación, los gastos tecnológicos, etc., deben asignarse por empleado, lo que hace que la cadena de suministro requiera un ajuste manual constante por diseño. Esto representa un gasto desproporcionado para lo que en realidad son una serie de tareas repetitivas y mundanas, que se realizan típicamente a diario¹.

Esto ni siquiera tiene en cuenta el ancho de banda perdido asociado con la ejecución manual de tareas mundanas, sin mencionar la lucha constante contra incendios cuando surgen excepciones. Calcular el costo en dólares de toda esa concentración mal asignada es difícil, pero sus contribuyentes pródigos incluyen no solo a los empleados, sino también a sus supervisores, gerentes e incluso ejecutivos de alto nivel.

La cadena de suministro es CapEx

La posición de Lokad es que la cadena de suministro debe ser replanteada como gasto de capital (CapEx), ya que es, en resumen, un activo estratégico para la empresa, al igual que los edificios, maquinarias y vehículos². Al tratar la cadena de suministro como un activo productivo en lugar de una actividad en curso - y costosa -, una empresa puede hacerla más escalable y rentable, al igual que las empresas de software que construyen sus negocios en torno a un producto subyacente. En este caso, el producto es una receta numérica diseñada para generar automáticamente todas las decisiones diarias mundanas que de otro modo requerirían una costosa intervención humana.

Es probable que esta mano de obra produzca decisiones de cierta precisión, pero a un costo mucho mayor, tanto financiero como en términos de ancho de banda, que las decisiones tomadas por un software. A diario, una receta numérica como la optimización de la cadena de suministro (SCO) funcionaría silenciosamente e independientemente, al igual que cualquier otra maquinaria de alto valor en una organización.

Aspectos que SCO debe considerar

La gama de consideraciones para el SCO de cualquier empresa es extensa y varía según el tipo de negocio. Esto, desde el principio, descalifica la idea misma de comprar un SCO estándar listo para usar.

Considere el SCO en el contexto de una empresa B2B versus una B2C. Esta última puede tener varios órdenes de magnitud más clientes que la primera, por lo que perder un cliente promedio ni siquiera sería notable, como en el caso de un supermercado con miles de clientes habituales. Las empresas B2B probablemente no tienen ese lujo, ya que generalmente tienen muchos menos clientes que las B2C, por lo que perder incluso un solo cliente podría resultar devastador, como en el caso de un proveedor cuyos clientes son supermercados.

Por lo tanto, el valor inherente de un solo cliente cambia según la perspectiva de cada uno, y esta perspectiva informa los objetivos de nivel de servicio y existencias de seguridad que una empresa debe establecer. Más allá de este primer principio indudable, tanto las empresas B2B como las B2C tienen restricciones únicas que hacen que la idea misma de aprovechar un SCO estándar sea increíblemente difícil, incluyendo:

Inventario: ¿Los SKU se mueven rápido o lento? ¿Son perecederos o no? Pedidos: ¿Los clientes hacen pedidos espontáneos o planificados? ¿Son los pedidos configurables? Precios: ¿Cuánto cobramos? ¿Los precios son fijos? ¿Tenemos tarjetas de lealtad o bonificaciones?

La variabilidad introducida solo por estos factores - y hay innumerables más - significa que intentar implementar un producto SCO estándar es un ejercicio costoso en vano.

Cosas que SCO debe hacer

SCO no es un software típico. A diferencia de cualquier otro activo, la cadena de suministro es una serie dispersa de actores, materiales y fuerzas, tanto naturales como de mercado. En consecuencia, las demandas sobre SCO superan con creces cualquier cosa esperada de un software aparentemente comparable, como un ERP funcionando en segundo plano. No se espera agilidad de este tipo de software, mientras que un SCO no solo debe ser ágil sino también decisivo.

Una dimensión clave de esta agilidad es la capacidad de respuesta del SCO ante amenazas adversas, incluso existenciales. Estas son las clases de amenazas que representan riesgos financieros extraordinarios para un negocio y requieren una intervención rápida y coherente. Excel, a pesar de todas sus fortalezas, no está diseñado para responder a este tipo de amenazas, y mucho menos para proporcionar recomendaciones de decisiones cuando ocurren.

Por ejemplo, Excel no dice nada cuando toda la flota de una aerolínea se queda en tierra debido a un retiro repentino, o cuando hay guerras y tsunamis. Cualquiera de estos eventos podría resultar catastrófico para la cadena de suministro, por lo que se necesita un SCO capaz de responder a emergencias con recomendaciones inteligentes. Además, estas amenazas deben ser calculadas y respondidas rápidamente. El horizonte temporal para abordar estas amenazas se mide en horas, no en días (y ciertamente no en meses).

Este nivel de capacidad de respuesta no es factible con las prácticas tradicionales de gestión de la cadena de suministro, muchas de las cuales están infladas incluso según los estándares burocráticos. SCO es la mejor manera de programar la capacidad de respuesta a las amenazas que una red física y geográficamente distribuida como la cadena de suministro encuentra.

Ingredientes secretos de SCO

La implementación exitosa de SCO requiere una serie de características e ingredientes de software individuales, pero las categorías principales se pueden resumir de la siguiente manera:

• Almacenamiento de datos versátil: SCO puede almacenar y proporcionar acceso a grandes cantidades de datos.
• Lógica programable: SCO se puede adaptar para abordar diferentes problemas.
• Interfaces de usuario versátiles: SCO muestra datos relacionados con las áreas de interés.
• Capacidades de colaboración: SCO permite que muchas personas interactúen con él.
• Accesible para no especialistas: SCO es operable por todos.

Aunque aplicaciones como Excel satisfacen en cierta medida la mayoría de los requisitos mencionados anteriormente, no es una panacea para la cadena de suministro y no cumple con las demandas de SCO como se describe en este documento. En otras palabras, el hecho de que Excel se pueda utilizar para fines de SCO con cierto éxito no significa que sea la mejor opción, ni siquiera una buena opción, para este propósito³.

Por ejemplo, aunque puede almacenar y procesar grandes cantidades de datos, Excel no está diseñado para procesar de manera estable cientos de miles, e incluso millones, de líneas de datos para una red extendida de tiendas. Para darle crédito a Excel, es muy expresivo en términos de su lógica de programación en el contexto de funciones que no son de SCO, pero no es adecuado para realizar cálculos con variables aleatorias, entre otras limitaciones.

A primera vista, esto puede parecer una limitación trivial, pero esta deficiencia de programación significa que el pronóstico probabilístico en Excel es excepcionalmente difícil. El pronóstico probabilístico es la base misma de políticas de decisión como el reabastecimiento de inventario prioritizado, algo de lo que SCO carece de manera efectiva⁴.

En resumen, el SCO exitoso requiere, entre otras cosas, software diseñado teniendo en cuenta la cadena de suministro, en lugar de intentar imponer software preempaquetado, como Excel, en la mezcla corporativa.

Notas