ENTREGA ORIENTADA AL PRODUCTO PARA LA SUPPLY CHAIN (RESUMEN DE CONFERENCIA 1.3)

learn menu

El objetivo de supply chain optimization (SCO) es entregar o mejorar una aplicación de software que automatice una, de otro modo, costosa serie de tareas repetitivas, decisiones mundanas, liberando así el ancho de banda gerencial para asuntos más urgentes. Esta aplicación, al igual que el supply chain en sí, debe considerarse un activo en lugar de un costo operativo, dado su inherente valor a largo plazo para la organización.

product-oriented-delivery-for-supply-chain

Mira la Conferencia

El supply chain no es OpEx

Las metodologías tradicionales de supply chain tienden a aprovechar la mano de obra en lugar de software. Esto se refleja en equipos de oficinistas con hojas de cálculo de Excel, elaborando y revisando decisiones de forma casi diaria. Los efectos secundarios principales de esto son mayores gastos generales y un aumento en el manejo de crisis, sin mencionar las enormes cantidades de ancho de banda dedicadas al procesamiento y atención manual de las innumerables y inevitables excepciones y emergencias comunes en el supply chain.

El supply chain, como se ha expresado 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 mala interpretación de la verdadera relación del supply chain con un negocio. Sin embargo, dado los vastos recursos que deben dedicarse al mantenimiento de las orquestaciones tradicionales del supply chain, la clasificación como OpEx no sorprende.

En un sistema tradicional de supply chain, el salario, beneficios, capacitación, gastos tecnológicos, etc., deben asignarse por oficinista, lo que hace que el supply chain sea algo que requiere ajustes manuales constantes por diseño. Esto representa un desembolso desproporcionado para lo que, en efecto, es una serie de tareas repetitivas y mundanas, típicamente realizadas a diario1.

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

El supply chain es CapEx

La postura de Lokad es que el supply chain debería reconsiderarse como gasto de capital (CapEx), ya que es, en conjunto, un activo estratégico para la empresa, al igual que los edificios, la maquinaria y los vehículos2. Al tratar el supply chain como un activo productivo en lugar de una actividad continua – y costosa – una empresa puede hacerlo más escalable y rentable, similar a 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 mundanas diarias que, de otro modo, requerirían una costosa intervención humana.

Esta mano de obra, con toda probabilidad, produciría decisiones de cierta precisión, pero a un costo mucho mayor – tanto financiero como en términos de ancho de banda – que las realizadas por una contraparte basada en software. Diariamente, dicha receta numérica - supply chain optimization (SCO) - funcionaría de manera silenciosa e independiente, similar a cualquier otra pieza de maquinaria de alto valor en una organización.

Aspectos que el SCO debe considerar

El abanico de consideraciones para el SCO de cualquier empresa es extenso y varía según el tipo de negocio. Esto, desde el principio, descalifica la noción misma de adquirir un SCO estándar, listo para usar.

Considera el SCO en el contexto de una empresa B2B frente a una B2C. Esta última puede tener varios órdenes de magnitud más de clientes que la primera, y por lo tanto, perder un cliente promedio puede ni siquiera ser perceptible – como en el caso de un supermercado con miles de clientes habituales. Las empresas B2B probablemente no tengan 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.

Así, el valor inherente de un solo cliente varía según la perspectiva, y esta perspectiva determina los objetivos de nivel de servicio y existencias de seguridad que una empresa debería establecer. Más allá de este indudable primer principio, tanto las empresas B2B como B2C tienen restricciones únicas que hacen que la noción misma de aprovechar un SCO estándar sea increíblemente difícil, incluyendo:

Inventario: ¿Se mueven rápido o despacio los SKUs? ¿Son perecederos Perishable o no? Pedidos: ¿Los clientes hacen pedidos inmediatos o planificados? ¿Son configurables los pedidos? Precios: ¿Cuánto cobramos? ¿Los precios son fijos? ¿Tenemos tarjetas de lealtad o bonificaciones?

La variabilidad introducida solo por estos factores – y hay muchos más – hace que intentar implementar un producto SCO estándar sea un ejercicio costoso y fútil.

Cosas que el SCO debe hacer

El SCO no es una pieza de software típica. A diferencia de cualquier otro activo, el supply chain es un conjunto disperso de actores, materiales y fuerzas – tanto naturales como del mercado. En consecuencia, las exigencias al SCO superan con creces cualquier expectativa sobre software aparentemente comparable, como un ERP que funcione en segundo plano. No se espera agilidad de dicho software, mientras que un SCO no solo debe ser ágil sino decisivo.

Una dimensión clave de esta agilidad es la capacidad de respuesta del SCO ante amenazas adversas – o incluso existenciales. Estas son las clases de amenazas que plantean riesgos financieros extraordinarios para el negocio y demandan una intervención pronta y contundente. Excel, a pesar de todas sus fortalezas, no está diseñado para responder a este tipo de amenazas, y mucho menos para ofrecer recomendaciones de decisión cuando ocurren.

Por ejemplo, Excel queda completamente inoperable cuando toda la flota de una aerolínea queda en tierra debido a una repentina retirada, o cuando estallan guerras y se desencadenan tsunamis. Cualquiera de estos eventos podría resultar catastrófico para el supply chain, por lo que se necesita un SCO que sea capaz de responder a emergencias con recomendaciones inteligentes. Además, estas amenazas deben ser calculadas y atendidas 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 del supply chain, muchas de las cuales están sobrecargadas incluso según estándares burocráticos. El SCO es la mejor manera de programar la capacidad de respuesta ante las amenazas que enfrenta una red distribuida física y geográficamente, como el supply chain.

Ingredientes secretos del SCO

La implementación exitosa del SCO requiere una serie de funciones e ingredientes individuales en el software, pero las categorías amplias se pueden resumir de la siguiente manera:

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

Aunque aplicaciones como Excel indiscutiblemente satisfacen la mayoría de los requisitos mencionados anteriormente, no es una panacea para el supply chain y no cumple con las demandas del SCO tal como se describe en este documento. En otras palabras, el hecho de que Excel pueda usarse para fines de SCO con cierto éxito no significa que sea la mejor opción – o incluso una buena – para este propósito3.

Por ejemplo, aunque puede almacenar y procesar grandes cantidades de datos, Excel no está diseñado para procesar de manera estable cientos de miles – si no millones – de líneas de datos para una red extendida de tiendas. Hay que reconocer que Excel es muy expresivo en términos de 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 en la programación significa que el forecast probabilístico en Excel es excepcionalmente difícil. El forecast probabilístico es la base misma de políticas de decisión como el reabastecimiento de inventario priorizado, algo de lo que el SCO significativo carece efectivamente sin4.

En resumen, un SCO exitoso requiere, entre otras cosas, software diseñado con el supply chain en mente, en lugar de intentar imponer software preempaquetado, como Excel, en la mezcla corporativa.

Notas


  1. Ejemplos de rutina incluyen reabastecimientos de inventario y actualizaciones de precios. ↩︎

  2. Esto no se entiende en sentido literal, es decir, para propósitos fiscales. Es más un punto filosófico y habla del significado y valor real del supply chain dentro del marco general de un negocio. Dicho de manera simple, los costos del supply chain no deben considerarse análogos a galletas para la sala de descanso. ↩︎

  3. Este es un argumento teleológico, no una crítica sin fundamento. Excel es una herramienta muy buena y es apta para muchas funciones de oficina. Dejando esa concesión a un lado, afirmar que Excel no es adecuado para el tipo de SCO a gran escala descrito aquí debería ser tan controvertido como decir que, en promedio, un bisturí es un mejor instrumento quirúrgico que una cuchara. (Inversamente, tampoco recomendaría comer helado con un bisturí.) ↩︎

  4. Para resumir, solo se discutieron algunas limitaciones aquí. Sin embargo, la conferencia dedica capítulos enteros a dilucidar las debilidades del SCO de Excel y Python. ↩︎