Supply Chain Quantitativa vs APS clásico

Joannes Vermorel

Mientras que los supply chains tuvieron un temprano comienzo en la digitalización en los 80’s y 90’s con el inventory management electrónico y EDI (Electronic Data Interchange), muchos software vendors – y por lo tanto la mayoría de sus clientes – se quedaron rezagados en las dos décadas siguientes. Aunque es relativamente sencillo renovar las interfaces de usuario, por ejemplo, transformar aplicaciones de escritorio en aplicaciones web, generalmente es mucho más desafiante revisar las elecciones de diseño arquitectónico central que sustentan una piece of software. La mayoría de esas soluciones jamás fueron diseñadas para computación en la nube, machine learning o una experiencia de usuario mobile-first, por nombrar algunas.

Lokad aboga por procesos y tecnologías que aprovechan al máximo lo que la potencia de cómputo en red moderna puede ofrecer a los supply chains a través de mejores optimizaciones predictivas. Nos referimos a este enfoque como la perspectiva de Supply Chain Quantitativa. Sin embargo, para los profesionales de supply chain, este mensaje puede resultar algo confuso, ya que Quantitative Supply Chain no es una variación de las antiguas formas de optimizar la supply chain, sino una bestia completamente distinta.

Así, examinemos de cerca los módulos tradicionales que se encuentran habitualmente en los sistemas APS líderes¹ (Advance Planning and Scheduling), con especial interés en los reabastecimientos de stock en una red de 2 escalones – por ejemplo, warehouses y tiendas – y comparemos esos módulos con la forma en que Lokad ofrece optimización predictiva. Por brevedad, en lo que sigue, nos referiremos indistintamente a la Supply Chain Quantitativa (la visión) o a Lokad (la implementación del software).

Módulo de Calendario

Un módulo de calendario provee mecanismos para afinar las situaciones de pedido, es decir, para decidir cuándo comprar, en casos en los que un ciclo de compra fijo resulta inevitable.

La mera idea de que los profesionales de supply chain deban afinar su cronograma de pedidos es la forma equivocada de abordar el problema. Los pedidos vienen acompañados de múltiples tipos de restricciones: calendario, MOQs, presupuesto, etc. Algunas restricciones pueden ser laxas, como “sin cronograma, cualquier día sirve excepto el 4 de julio y el 25 de diciembre”, o estrictas, como “el contenedor debe estar exactamente lleno”. En cualquier caso, el sistema debe buscar – dentro de todas las opciones de pedido factibles – aquellas que maximicen el ROI. Este proceso, la “optimización”, debe estar estrictamente automatizado. No hay razón para afinar nada manualmente. Los solucionadores numéricos de alto rendimiento no estaban disponibles de forma rutinaria en los 80’s, pero hoy en día eso ya no es así.

Así, en Lokad, recopilamos todas las restricciones relevantes, las cuales se tratan como datos, es decir, la “base de datos” de los cronogramas de pedidos autorizados, y luego desplegamos los solucionadores numéricos adecuados para realizar la tarea.

Ver también Humans in modern supply chain.

Módulo de Eventos

El módulo de event gestiona los picos y caídas de la demanda debido a eventos planificados, tales como lanzamientos de new product, publicidad, promotions de precios, lanzamientos de catálogos y flyers.

Los primeros modelos de forecast (por ejemplo, Holt-Winters), descubiertos en los 50’s y 60’s, estaban todos centrados en las time-series. Así, la mayoría de los APS adoptaron perspectivas centradas en time-series. Desafortunadamente, los supply chain problems no pueden enmarcarse fácilmente en series temporales: stock-outs, promociones, lanzamientos y descontinuaciones son tantos fenómenos que no encajan en el marco matemático tradicional asociado con las series temporales. Por ello, para hacer frente a los modelos de forecast de time-series rotos por diseño, los APS recurren a “correcciones” manuales que se aplican tanto a los datos históricos –por ejemplo, suavizar el incremento de promociones pasadas– como a los forecast de demanda, introduciendo sesgos en las estimaciones futuras.

En Lokad, nuestro enfoque es tratar esas “perturbaciones” como datos históricos simples. Nunca sabremos con certeza lo que habría ocurrido si una promoción pasada no se hubiera desencadenado. Lo único de lo que tenemos certeza es la característica de la promoción – es decir, las fechas de inicio y finalización, el mecanismo de descuento, el alcance, etc. – y sus ventas resultantes. Por ello, el modelo estadístico debe ser diseñado desde el principio para procesar los datos históricos tal como existen, en lugar de quedarse “atrapado” en una perspectiva estrecha de time-series.

Lokad recopila los eventos relevantes y procesa todos estos datos con modelos estadísticos orientados a problemas de alta dimensión, que generalmente se encuadran bajo el paraguas genérico de algoritmos de “machine learning”. La última versión de nuestra tecnología de forecast se centra en differentiable programming. Sin embargo, aún es un trabajo en progreso, ya que el campo del machine learning sigue evolucionando rápidamente. La necesidad de ajustar manualmente los resultados del forecast debe tratarse como un defecto de software a corregir, y no como una oportunidad para aprovechar a los profesionales de supply chain como “human coprocessors”.

En la práctica, la mayor parte del desafío consiste en recopilar los datos relevantes tanto de eventos pasados como futuros (p. ej., promociones planificadas), lo cual tiene poco que ver con la estadística. Además, los sistemas analíticos, sea Lokad o un APS, no son el lugar adecuado para realizar altos volúmenes de entradas de datos manuales. Esas entradas pertenecen al ámbito transaccional – también conocido como el ERP – que recoge todos los facts² sobre la supply chain.

Módulo de Gestión de Expedición de Pedidos

Un módulo de order expedite management actúa como una herramienta de alerta temprana, y proporciona a los compradores una vista diaria actualizada de los pedidos atrasados y envíos cortos.

El enfoque entero de las exceptions y alerts es una perspectiva bastante anticuada para mitigar problemas en sistemas complejos de la industria del software. Este enfoque fue fuertemente adoptado por los proveedores de software en los 80’s y 90’s, porque las exceptions y alerts son sencillas de implementar sobre una base de datos SQL. Solo se requiere una sentencia SELECT con algunas condiciones WHERE. Sin embargo, en conjunto, este enfoque hace un uso deficiente del recurso escaso que representan los profesionales de supply chain, ya que tiende a sobrecargarlos rápidamente, al punto de que las alerts dejan de ser “alerts” y se pierde la sensación de urgencia o de acción a tomar.

Lokad favorece y entrega una estricta priorización basada en el ROI de los “items” de interés que se presentan a los profesionales de supply chain. Como regla general, producir 1 millón de números al día es fácil, pero generar 10 números que valga la pena que un humano lea cada día es difícil. Los pedidos atrasados no siempre son determinantes: quizá los stock levels siguen siendo elevados, o tal vez se trate de un problema recurrente para ese proveedor que ha persistido desde siempre. Los envíos cortos también deben procesarse automáticamente para corregir los pagos al supplier en consecuencia, pero no siempre requieren una respuesta inmediata. Para que un “item” tenga ROI, el “item” debe ser actionable, y el ROI representa el ROI estimado asociado a la acción. Lokad destaca por entregar priorizaciones hechas a la medida que se ajustan perfectamente a las especificidades de la supply chain de interés.

Módulo de Deal/Forward Buy

Los módulos de deal/forward buy permiten al comprador ingresar datos del deal en el sistema antes del período correspondiente. Esto posibilita que el sistema adquiera inventario de replenishment que coincida con la ventana del deal, calcule las cantidades de forward buy y determine cuándo comprarlas.

La mayoría de los APS se implementaron inicialmente con una perspectiva ingenua en la que se asumía que el unit price era autosuficiente –en cuanto a precios– para calcular una cantidad de pedido optimizada. Sin embargo, la realidad presentaba un nivel de detalle superior. Los proveedores frecuentemente tienen estructuras de precios complejas: MOQs, escalas de precio, descuentos en cuotas trimestrales, deals temporales, etc.

Lokad trata todos esos elementos como input data and input constraints y aprovecha una resolución numérica directa de un problema acotado para entregar una cantidad de pedido optimized. Por ejemplo, un descuento temporal del supply ofrece a la empresa un incentivo económico para sobrestockear temporalmente: la cantidad de pedido se convierte en la compensación numérica entre el descuento extra (ganancias lineales) y el riesgo de sobrestock (costos super-lineales). Entregamos la cantidad de pedido que optimiza directamente ese compromiso, además de todas las demás fuerzas económicas relevantes.

Módulo de Análisis de Pedidos

Los módulos de order analysis identifican potenciales faltantes de stock. Estos módulos proporcionan la información actualizada necesaria para entender el estado del stock de items tales como importaciones o aquellos fabricados a medida — items con largos plazos de entrega para los cuales a menudo existen dos, tres o más pedidos pendientes.

Este es otro caso de diseño de software algo simplista por su “ease-of-implementation”. En los 80’s, era difícil realizar cualquier tipo de análisis a nivel de red, por lo que la mayoría de los proveedores de software optaron por un diseño que imponía un “aislamiento de SKU”. Cada SKU se procesa de forma aislada, y los estimadores estadísticos calculados —como la probabilidad esperada de stock-out para el próximo ciclo de pedidos— son completamente específicos para el SKU en cuestión.

En Lokad, observamos que cada SKU compite con todos los demás por el presupuesto de la empresa. Así, realmente no importa si la probabilidad de faltante de stock de un SKU dado es alta o baja. Lo único que importa es si el retorno de pedir más de ese SKU es lo suficientemente alto como para no ser superado por alguna opción alternativa – es decir, pedir más de otro SKU – disponible para la empresa. Por ejemplo, si el SKU está asociado a un producto de alto costo, con un margen muy bajo y es comprado únicamente por un gran cliente corporativo, que según el equipo de ventas está a punto de irse, mantener el service level para ese SKU es una receta segura para generar inventario muerto.

En la práctica, Lokad entrega prioritized order quantities que reflejan directamente la economía de extremo a extremo de la supply chain.

Módulo de Transferencia de Overstock

Los módulos de overstock transfer ayudan a los compradores a gestionar el overstock en los warehouses. Permiten trasladar el inventario excedente de una ubicación a otra que tenga suficiente demanda, para evitar realizar compras adicionales al vendor.

En la supply chain, casi siempre es possible – pero generalmente no profitable – mover algo de la ubicación A a la B. Así, al enfrentar una red en la que el mismo item puede almacenarse en muchas ubicaciones, es natural tratar cualquier movimiento de stock entre dos lugares como una decisión potential.

Así, Lokad posee capacidades integradas para llevar a cabo optimización a nivel de red de esta naturaleza, básicamente probando por fuerza bruta todas las opciones disponibles para los movimientos de stock. La parte más desafiante de esta tarea es reflejar adecuadamente la economic friction asociada con mover el stock. De hecho, la fricción típicamente no se refleja correctamente en los movimientos de stock a nivel de SKU. Por ejemplo, los costos de transporte tienden a ser altamente no lineales: si se debe despachar un camión, se debe aprovechar al máximo su capacidad disponible.

Desafortunadamente, el número de options crece mucho más rápido que el número de SKUs. Consideremos una red que incluye 2000 items almacenados en 10 warehouses, lo que resulta en 10 x 2000 = 20,000 SKUs en total. El número total de edges a considerar para los movimientos de stock es 10 x (10 - 1) * 2000 = 180,000 edges, un número mucho mayor que el original de SKUs. Para los lectores familiarizados con algoritmos, es un caso sencillo de complejidad cuadrática.

Sin embargo, al considerar la potencia de procesamiento disponible en la actualidad, este caso específico de complejidad cuadrática no suele representar un problema – siempre que el software subyacente haya sido diseñado adecuadamente para este tipo de exploración numérica. De hecho, las redes de supply chain muy raramente exceden las 10,000 ubicaciones, incluso en las compañías más gigantes; y se pueden usar algunas heurísticas para reducir dramáticamente el número de edges a explorar en la práctica, ya que muchos pares de ubicaciones resultan ilógicos, como rebalancear stocks entre Paris y Sydney.

Sin embargo, en los 80’s y 90’s, debido al hardware de cómputo disponible en ese entonces, los APS ya tenían problemas para manejar el número de SKUs. Naturalmente, en ese contexto, lidiar con problemas de complejidad cuadrática estaba simplemente fuera de cuestión.

Avanzando rápidamente hasta la actualidad, muchos vendors tuvieron que introducir módulos separados para abordar cualquier problema que implicase optimización a nivel de red. No existe una verdadera motivación empresarial para contar con un módulo separate. Esta situación refleja, en gran parte, que el vendor original ha estado parcheando su producto de software para enfrentar una clase de problemas que chocan con decisiones de diseño tomadas dos décadas atrás.

En contraste, Lokad decidió abordar de frente esta clase de problemas que son ciudadanos de primera clase en nuestro stack de software. Naturalmente, la resolución real del desafío aún implica esfuerzos en la práctica, porque todos los costos y restricciones de transporte deben hacerse explícitos.

Módulo de Planificación

Los módulos de planning permiten a los equipos de ventas o marketing preplanificar pedidos para eventos específicos, tales como promociones o pedidos especiales. Los equipos pueden crear un pedido planificado en el sistema con más de un año de antelación a la fecha prevista del pedido.

El enfoque de Lokad comienza estableciendo una clara separación entre hechos y predicciones. Consideremos una red minorista B2B. Si un cliente anuncia el 10 de febrero que ordenará 1000 unidades, con una fecha de entrega esperada para el 1 de marzo, entonces, este anuncio es un hecho. Si este cliente tiene la costumbre de revisar a última hora su fecha de entrega prevista -típicamente posponiéndola por 1 semana- entonces este patrón debe tenerse en cuenta. Sin embargo, este análisis de patrones recae en el lado de predicciones del problema.

Lokad aborda esta clase de problemas con una tecnología que ofrece general probabilistic forecasts y no solo demand probabilistic forecasts. Cualquier afirmación realizada sobre el futuro, como una fecha de llegada esperada, tiende a ser incierta hasta cierto grado. Las supply chain requieren herramientas predictivas versátiles y de alta dimensión, que es exactamente la razón por la que Lokad se encaminó por la vía de differentiable programming.

Además, los hechos no deben ser recogidos por la capa de analytics, ni por Lokad ni por el APS. No es porque el software no pueda hacerlo. Diseñar software para recopilar hechos es relativamente sencillo, pero porque genera una gran cantidad de accidental vendor lock-in. De hecho, tan pronto como las entradas de datos fluyen a través de un sistema en la empresa, dicho sistema se convierte en el controlador maestro de facto de estos datos.

Nuestra experiencia en Lokad indica que las capas de analytics anticuadas frecuentemente perduran incluso hasta una década después de haber quedado obsoletas, simplemente porque se perderían datos críticos de misión si este sistema se desactivara. Mientras tanto, el proveedor original del software sigue cobrando tarifas de mantenimiento, lo que le da al proveedor un gran incentivo para crear el problema en primer lugar.

Módulo de proyecciones

Los módulos de proyecciones permiten a los compradores crear informes que proyectan la future demand y las compras futuras con hasta un año de antelación. Estos forecast pueden compartirse con los proveedores, para permitirles planificar more accurately sus respectivas capacidades de suministro.

Los naked forecast son perjudiciales y ya no pueden considerarse una práctica sensata de supply chain. Consulta el naked forecasts antipattern para obtener más información. Esto no significa que Lokad no tenga capacidades de forecasting, we do. Sin embargo, sostenemos que el enfoque clásico de forecasting de series temporales es simplemente erróneo y debe terminar. Las series temporales clásicas pueden funcionar para productos de muy alto volumen y muy estables, pero para cualquier otro caso -y especialmente para la demanda errática o intermitente- el probabilistic forecasting es el camino a seguir.

Además, los modelos de forecasting de series temporales históricas -por ejemplo, Holt-Winters o Arima- tuvieron enormes deficiencias cada vez que el historial del producto era demasiado corto, demasiado errático, demasiado atípico o presentaba un volumen demasiado bajo, … La mayoría de los proveedores de software respondieron a esos problemas con dos enfoques, igualmente disfuncionales a su manera:

• Human coprocessors: dado que el modelo de forecasting frecuentemente termina produciendo resultados sin sentido, los operadores humanos -es decir, los planners- son utilizados por el sistema como “coprocessors” para anular manualmente los forecast cada vez que “los números no parecen correctos”. Desafortunadamente, la tarea es interminable, ya que los forecast deben actualizarse de forma continua, forzando a los planners a un ciclo sin fin de anulaciones manuales. Tal tarea también produce efectos secundarios indeseados, en los que los operadores humanos pasan a considerar que los forecast están equivocados y tienden a corregirlos incluso cuando no lo están, a menudo basándose únicamente en una corazonada.
• Model competition: dado que cada modelo de forecasting de series temporales tiene sus propias fortalezas y debilidades, se supone que una competencia entre muchos modelos de forecasting debería arrojar buenos resultados permitiendo que el sistema “escoja” el mejor modelo en cada situación. Desafortunadamente, esto falla por dos razones. Primero, todos los modelos dependen de un marco time-series y, por lo tanto, están sujetos a las mismas limitaciones. Segundo, todos los modelos son “clásicos” y no logran proporcionar los probabilistic forecasts que la supply chain requiere.

Además, el forecasting no se trata solo de la demanda. Los Lead times también deben ser forecast. Además, la estructura de la supply chain importa. En B2B, un flujo constante de ventas puede ocultar el hecho de que todos los pedidos provienen del mismo cliente. Si se pierde a este cliente, muchos artículos se convierten al instante en sobrestock o en dead stock. Una adecuada predictive optimization de la supply chain debe tener en cuenta este riesgo. La tecnología de Lokad ha sido diseñada en consecuencia.

En lo que respecta al intercambio de forecast con los proveedores, aunque una mejor coordinación entre compradores y proveedores siempre resulta preferible, hemos observado que las coordinaciones forecast-driven exitosas entre empresas han sido pocas y escasas. Los proveedores, de todas formas, tienen muchos clientes propios³. Así, incluso si los forecast entregados por los compradores locales fueran precisos, el proveedor no tiene forma de conciliar todos esos forecast dispares: la suma de los forecast NO es el forecast de la suma.

Módulo de Seguridad

Sorprendentemente, para algunos APS, las características de security no están presentes por defecto en el sistema, sino que se ofrecen como un módulo separado. El propósito de un módulo de security es prevenir el acceso a ciertos usuarios. También permite a la dirección asegurar las acciones de los componentes y restringir la visualización de áreas importantes del sistema, tales como factores de control de la empresa, mantenimiento de artículos, mantenimiento de proveedores, pedidos, acuerdos y otros componentes.

En el argot del software, aquí se habla de las preocupaciones transversales de autenticación y autorización.

• La autenticación garantiza que los usuarios finales que realizan cualquier acción en el sistema sean realmente la persona que el sistema cree que son. Aquí, Lokad adopta el enfoque moderno de que la autenticación must be delegated siempre que sea posible. Los usuarios finales no deberían tener que lidiar con otra contraseña adicional. En cambio, Lokad utiliza SAML como el estándar de facto de la industria para delegar la autenticación a la gestión federada de identidades (FIM).
• La autorización proporciona un control granular sobre quién puede hacer qué dentro del sistema. Aquí, Lokad cuenta con un extenso sistema canónico de ACL (Access-Control List), que también es la práctica de facto en los sistemas empresariales modernos. Lokad además ofrece algunas capacidades de personalización, que complementan la ACL desde una perspectiva de experiencia de usuario.

Lokad activa todas sus características de security por defecto, sin importar qué paquete se haya vendido originalmente a cualquiera de nuestros clientes. Creemos que el optional security⁴ es una práctica terrible por parte de los proveedores de software. Asegurar el software ya es extremadamente difícil; tal práctica solo lo empeora.

Para ser justos, el enfoque de ACL es probablemente la preocupación menos desafiante de todo lo relacionado con la software security. Una pregunta más interesante es: ¿cuánto security by design entrega la propia arquitectura del sistema? Sin embargo, responder a esta pregunta va más allá del alcance del presente artículo.

Exportar a Excel

El módulo export to Excel ofrece una manera sencilla de transportar datos para su uso en otros sistemas o para análisis.

Debido a que es razonablemente sencillo producir hojas de Excel⁵, muchos proveedores -incluyendo a Lokad- cuentan con capacidades en esta área. Sin embargo, un examen más minucioso indica que la mayoría de los proveedores solo ofrecen capacidades a medio cocer. Revisemos los puntos destacados de las implementaciones good de export-to-excel:

• Complete historization: el sistema debería ofrecer la posibilidad de rastrear y volver a descargar cada hoja de Excel exportada. De hecho, al enfrentarse a cifras incorrectas en la hoja de cálculo -un problema que will ocurrirá (si no fuera solo por entradas de datos incorrectas)- no contar con una trazabilidad completa en la ruta de código que terminó generando esta hoja de cálculo complicará enormemente, ralentizará -y en ocasiones impedirá- cualquier intento de depuración y corrección del problema.
• Maxing-out the spreadsheet capabilities: los profesionales esperan poder generar hojas de cálculo fat de hasta 1 millón de líneas⁶, es decir, en realidad, el límite del propio Excel. Por lo tanto, el sistema debería ser capaz de generar hojas de cálculo robustas para not estorbar a los profesionales que solo desean realizar su propio análisis de datos dentro de una herramienta familiar. Por no decir que, además, los profesionales esperan que esas exportaciones fat sean ágiles.
• Built-in protection against spreadsheet attacks: Excel es un vector de ataque peligroso para las grandes organizaciones. Desafortunadamente, asegurar las hojas de cálculo generadas por el sistema cannot ser una ocurrencia tardía, sino que tiene que ser una parte integral del diseño, prácticamente desde el Day 1.
• Programmatic configurability of the exports: tener que lidiar con dos piezas de software - a saber, el APS y Excel - ya resulta bastante doloroso para los profesionales de la supply chain. La situación no debería empeorar con hojas de cálculo que requieran siempre algún procesamiento extra posterior a la extracción para volverse utilizables. Esto implica que todo ocurra before de la extracción, dentro del APS. Por lo tanto, el APS necesita capacidades programáticas para preparar adecuadamente las hojas de cálculo antes de la exportación.

Lokad ofrece todo lo anterior, mientras que la mayoría de nuestros competidores no lo hace. El diablo está en los detalles.

Conclusión

Nuestra convicción es que Lokad es un software simpler que la mayoría de los APS en el mercado. Sin embargo, nuestra capacidad para ofrecer supply chain performance a través de tecnologías predictivas es mayor. De hecho, la mayor parte de la complejidad de los APS es accidental, derivada de decisiones de diseño de software tomadas hace décadas frente a problemas de software introspectivos que ya pertenecen al pasado. Sin embargo, la mayoría de las decisiones arquitectónicas en el software, una vez tomadas, no pueden deshacerse.