Supply Chain Quantitativa vs APS Clásico

Joannes Vermorel

Mientras que las cadenas de suministro comenzaron tempranamente su digitalización en los años 80 y 90 con la gestión electrónica de inventario y el EDI (Intercambio Electrónico de Datos), muchos proveedores de software, y por lo tanto la mayoría de sus clientes, se quedaron rezagados en las dos décadas siguientes. Si bien es relativamente sencillo actualizar las interfaces de usuario, por ejemplo, convirtiendo aplicaciones de escritorio en aplicaciones web, suele ser mucho más desafiante revisar las elecciones de diseño arquitectónico fundamentales que respaldan un software. La mayoría de esas soluciones nunca fueron diseñadas para la computación en la nube, el aprendizaje automático o una experiencia de usuario centrada en dispositivos móviles, por nombrar algunos ejemplos.

Lokad defiende procesos y tecnologías que aprovechan al máximo lo que la potencia informática moderna en red puede ofrecer a las cadenas de suministro a través de mejores optimizaciones predictivas. Nos referimos a este enfoque como la perspectiva de la Supply Chain Quantitativa. Sin embargo, para los profesionales de la cadena de suministro, este mensaje puede resultar confuso, porque la Supply Chain Quantitativa no es una variación de las antiguas formas de optimizar la cadena de suministro, sino una bestia completamente diferente.

Por lo tanto, echemos un vistazo más de cerca a los módulos tradicionales que se encuentran habitualmente en los sistemas líderes¹ de APS (Planificación y Programación Avanzada), con un interés especial en los reabastecimientos de stock en una red de 2 niveles, como almacenes y tiendas, y comparemos esos módulos con la forma en que Lokad ofrece optimización predictiva. Por razones de concisión, en lo siguiente nos referimos indistintamente a supply chain quantitativa (la visión) o a Lokad (la implementación del software).

Módulo de calendario

Un módulo de calendario proporciona mecanismos para ajustar las situaciones de pedido, es decir, decidir cuándo comprar, cuando un ciclo de compra de pedido fijo es inevitable.

La idea de que los profesionales de la cadena de suministro deben ajustar su calendario de pedidos es la forma incorrecta de abordar el problema. El pedido viene con múltiples tipos de restricciones: calendario, MOQs (Cantidad Mínima de Pedido), presupuesto, etc. Algunas restricciones pueden ser flexibles, como “sin horario, cualquier día 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, entre todas las opciones de pedido factibles, aquellas que maximicen el ROI. Este proceso, la “optimización”, debe ser estrictamente automatizado. No hay razón para ajustar manualmente nada. Los solucionadores numéricos eficientes no estaban disponibles rutinariamente en los años 80, pero hoy en día eso ya no es el caso.

Por lo tanto, en Lokad, recopilamos todas las restricciones relevantes, que a su vez se tratan como datos, es decir, la “base de datos” de los horarios de pedido autorizados, y luego implementamos los solucionadores numéricos adecuados para hacer el trabajo.

Ver también Humanos en las cadenas de suministro modernas.

Módulo de eventos

El módulo de eventos gestiona los aumentos y disminuciones de la demanda debido a eventos planificados, como la introducción de nuevos productos, publicidad, promociones de precios, lanzamientos de catálogos y folletos.

Los primeros modelos de pronóstico (por ejemplo, Holt-Winters), descubiertos en los años 50 y 60, se centraban todos en las series de tiempo. Por lo tanto, la mayoría de los APS adoptaron perspectivas centradas en las series de tiempo. Desafortunadamente, los problemas de la cadena de suministro no se pueden enmarcar fácilmente en series de tiempo: los faltantes de stock, las promociones, las introducciones y las eliminaciones son tantos fenómenos que no encajan en el marco matemático tradicional asociado con las series de tiempo. Por lo tanto, para hacer frente a los modelos de pronóstico de series de tiempo defectuosos, los APS recurren a “correcciones” manuales que se aplican tanto a los datos históricos, por ejemplo, suavizando el aumento de las promociones pasadas, como a los pronósticos de demanda, introduciendo sesgos en las estimaciones futuras.

En Lokad, nuestro enfoque consiste en tratar esas “perturbaciones” como datos históricos simples. Nunca sabremos con certeza qué habría sucedido si no se hubiera activado una promoción pasada. Lo único que sabemos con 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 lo tanto, el modelo estadístico debe estar diseñado frontalmente para procesar los datos históricos tal como existen, en lugar de estar “atascado” con una perspectiva estrecha de series de tiempo.

Lokad recopila los eventos relevantes y procesa todos estos datos con modelos estadísticos orientados a problemas de alta dimensionalidad, que generalmente se engloban bajo el paraguas genérico de algoritmos de “aprendizaje automático”. La última versión de nuestra tecnología de pronóstico se centra en la “programación diferenciable”. Sin embargo, todavía está en desarrollo, ya que el campo del aprendizaje automático en sí mismo está evolucionando rápidamente. La necesidad de ajustar manualmente los resultados del pronóstico debe tratarse como un defecto del software que debe corregirse, no como una oportunidad para aprovechar a los profesionales de la cadena de suministro como “coprocesadores humanos”.

En la práctica, el desafío principal consiste en recopilar los datos relevantes sobre eventos pasados y futuros (por ejemplo, promociones planificadas), lo cual tiene poco que ver con la estadística. Además, los sistemas analíticos, ya sea Lokad o un APS, no son el lugar para realizar grandes volúmenes de entradas de datos manuales. Esas entradas de datos pertenecen al ámbito transaccional, también conocido como ERP, que recopila todos los hechos[^hechos] sobre la cadena de suministro.

Módulo de gestión de aceleración de pedidos

Un módulo de gestión de aceleración de pedidos actúa como una herramienta de advertencia temprana y proporciona a los compradores una vista actualizada diariamente de los pedidos vencidos y los envíos incompletos.

El enfoque completo de excepciones y alertas es una perspectiva bastante anticuada para mitigar problemas dentro de sistemas complejos en la industria del software. Este enfoque ha sido ampliamente adoptado por los proveedores de software en los años 80 y 90, porque las excepciones y alertas son fáciles de implementar sobre una base de datos SQL. Solo se necesita una declaración SELECT con algunas condiciones WHERE. Sin embargo, en general, este enfoque hace un uso deficiente del escaso recurso que representan los profesionales de la cadena de suministro, ya que tiende a sobrecargarlos rápidamente, hasta el punto en que las alertas ya no son “alertas” y se pierde la sensación de emergencia o de que se debe tomar alguna acción.

Lokad favorece y ofrece una estricta priorización basada en el ROI de los “elementos” de interés que se presentan a los profesionales de la cadena de suministro. Como regla general, producir 1 millón de números al día es fácil, producir 10 números que valgan la pena ser leídos por un humano todos los días es difícil. Los pedidos vencidos no siempre importan: tal vez los niveles de stock sigan siendo altos de todos modos, o tal vez sea simplemente un problema recurrente para este proveedor que ha estado ocurriendo desde siempre. Los envíos incompletos también deben procesarse automáticamente para corregir los pagos al proveedor en consecuencia, pero no siempre requieren una respuesta inmediata. Para que un “elemento” tenga un ROI, el “elemento” debe ser accionable, y el ROI representa el ROI estimado asociado a la acción. Lokad se destaca al ofrecer priorizaciones hechas a la medida que se adaptan exactamente a las especificidades de la cadena de suministro de interés.

Módulo de compra anticipada/ofertas

Los módulos de tipo compra anticipada/ofertas permiten al comprador ingresar datos de ofertas al sistema antes del período de oferta. Esto permite que el sistema compre inventario de reposición que coincida con la ventana de oferta, calcule las cantidades de compra anticipada y determine cuándo comprar estas cantidades.

La mayoría de los APS se implementaron inicialmente con una perspectiva ingenua en la que el precio unitario se consideraba autosuficiente, en términos de precios, para calcular una cantidad de pedido optimizada. Sin embargo, la realidad tenía un nivel de detalle más alto. Los proveedores a menudo tienen estructuras de precios complejas: MOQs, descuentos por cantidad, descuentos en cuotas trimestrales, ofertas temporales, etc.

Lokad trata todos esos elementos como datos de entrada y restricciones de entrada y aprovecha una resolución numérica directa de un problema restringido para entregar una cantidad de pedido optimizada. Por ejemplo, un descuento temporal del proveedor brinda un incentivo económico para que la empresa tenga un exceso de stock temporal: la cantidad de pedido se convierte en el compromiso numérico entre el descuento adicional (ganancias lineales) y el riesgo de exceso de stock (costos superlineales). Entregamos la cantidad de pedido que optimiza directamente este compromiso, además de todas las demás fuerzas económicas relevantes.

Módulo de análisis de pedidos

Los módulos de análisis de pedidos identifican posibles faltantes de stock. Estos módulos proporcionan la información actualizada necesaria para comprender el estado del stock de elementos como importaciones o aquellos que se fabrican a medida, que son elementos con un largo tiempo de espera y para los cuales a menudo hay dos, tres o más pedidos pendientes.

Este es otro caso de diseño de software algo simplista en términos de “facilidad de implementación”. En los años 80, era difícil realizar cualquier tipo de análisis en toda la red, por lo que la mayoría de los proveedores de software adoptaron un diseño de software que imponía un “aislamiento de SKU”. Cada SKU se procesa de forma independiente, y los estimadores estadísticos calculados, como la probabilidad esperada de faltante de stock para el próximo ciclo de pedido, son completamente específicos del SKU de interés.

En Lokad, observamos que cada SKU compite con todos los demás SKU por el presupuesto de la empresa. Por lo tanto, no importa realmente si la probabilidad de faltante de stock de un SKU dado es alta o baja. Lo único que importa es si el retorno de la inversión por pedir más de este SKU es lo suficientemente alto como para no ser superado por ninguna otra opción alternativa, es decir, pedir más de otro SKU disponible para la empresa. Por ejemplo, si el SKU está asociado con un producto que tiene un costo alto, un margen muy bajo y solo es comprado por un único cliente corporativo grande, que según el equipo de ventas está a punto de irse, mantener el nivel de servicio para este SKU es una receta segura para crear inventario muerto.

En la práctica, Lokad entrega cantidades de pedido priorizadas que reflejan directamente la economía de extremo a extremo de la cadena de suministro.

Módulo de transferencia de exceso de stock

Los módulos de transferencia de exceso de stock ayudan a los compradores a gestionar el exceso de stock en los almacenes. Permite a los compradores transferir inventario excedente de una ubicación a otra que tenga suficiente demanda, para evitar realizar compras adicionales al proveedor.

En la cadena de suministro, casi siempre es posible -pero generalmente no es rentable- mover algo de la ubicación A a la ubicación B. Por lo tanto, cuando se enfrenta a una red donde el mismo artículo se puede almacenar en muchas ubicaciones, es natural tratar cualquier movimiento de stock entre dos ubicaciones como una decisión potencial.

Por lo tanto, Lokad tiene capacidades incorporadas para realizar una optimización a nivel de red de esta naturaleza, básicamente probando todas las opciones disponibles para los movimientos de stock. La parte más desafiante de la tarea es reflejar adecuadamente la fricción económica asociada con el movimiento del stock. De hecho, la fricción generalmente no se refleja adecuadamente en los movimientos de stock a nivel de SKU. Por ejemplo, los costos de transporte tienden a ser altamente no lineales: si se debe enviar un camión, aprovechemos al máximo su capacidad disponible.

Desafortunadamente, el número de opciones crece mucho más rápido que el número de SKU. Consideremos una red que incluye 2000 artículos almacenados en 10 almacenes, lo que resulta en un total de 10 x 2000 = 20,000 SKU. El número total de aristas que se deben considerar para los movimientos de stock es de 10 x (10 - 1) * 2000 = 180,000 aristas, un número mucho mayor que el número original de SKU. Para los lectores que estén familiarizados con los algoritmos, es un caso sencillo de complejidad cuadrática.

Sin embargo, al considerar la capacidad de procesamiento disponible en la actualidad, este caso específico de complejidad cuadrática es en su mayoría insignificante, siempre y cuando el software subyacente haya sido diseñado adecuadamente para este tipo de exploración numérica. De hecho, las redes de la cadena de suministro rara vez superan las 10,000 ubicaciones, incluso al observar las compañías más gigantes; y se pueden utilizar algunas heurísticas para reducir drásticamente el número de aristas que se deben explorar en la práctica, ya que muchas parejas de ubicaciones son absurdas, como reequilibrar el stock entre París y Sídney.

Sin embargo, en los años 80 y 90, debido al hardware informático disponible en ese momento, los APS ya tenían dificultades para lidiar con la cantidad de SKU. Naturalmente, en este contexto, lidiar con problemas de complejidad cuadrática simplemente estaba fuera de discusión.

Avancemos rápidamente hasta el día de hoy, muchos proveedores tuvieron que introducir módulos separados para lidiar con cualquier tipo de problema que implicara una optimización a nivel de red. No hay una verdadera motivación comercial para tener un módulo separado. Este estado de cosas refleja en su mayoría que el proveedor original ha estado parcheando su producto de software para lidiar con una clase de problemas que entran en conflicto con las decisiones de diseño que se tomaron dos décadas antes.

En contraste, Lokad decidió abordar frontalmente esta clase de problemas que son ciudadanos de primera clase en nuestra pila de software. Naturalmente, la resolución real del desafío aún requiere 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 planificación permiten a los equipos de ventas o equipos de marketing planificar pedidos para eventos específicos, como promociones o pedidos especiales. Los equipos pueden crear un pedido planificado en el sistema más de un año antes de 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 realizará un pedido de 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 en el último minuto su fecha de entrega prevista, generalmente posponiéndola una semana, entonces este análisis de patrones debe tenerse en cuenta. Sin embargo, este análisis de patrones cae en el lado de las predicciones del problema.

Lokad aborda esta clase de problemas con una tecnología que ofrece pronósticos probabilísticos generales y no solo pronósticos probabilísticos de demanda. Cualquier afirmación hecha sobre el futuro, como una fecha de llegada esperada, tiende a ser incierta en cierto grado. Las cadenas de suministro requieren herramientas predictivas versátiles de alta dimensionalidad, que es exactamente por qué Lokad optó por la programación diferenciable.

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

Nuestra experiencia en Lokad indica que las capas de análisis obsoletas suelen persistir durante una década adicional después de que hayan quedado obsoletas, sin ninguna otra razón que no sea el riesgo de perder datos críticos si se apaga este sistema. Mientras tanto, el proveedor de software original 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

El módulo de proyecciones permite a los compradores crear informes que proyectan la demanda futura y las compras futuras hasta con un año de anticipación. Estos pronósticos se pueden compartir con los proveedores, para que puedan planificar de manera más precisa sus respectivas capacidades de suministro.

Los pronósticos aislados son perjudiciales y ya no se pueden considerar como una práctica sensata en la cadena de suministro. Consulta el antipatrón de pronósticos aislados para obtener más información. Esto no significa que Lokad no tenga capacidades de pronóstico, las tenemos. Sin embargo, mantenemos que el enfoque clásico de pronóstico de series de tiempo es simplemente incorrecto y debe terminar. El enfoque clásico de series de tiempo puede funcionar para productos con un volumen muy alto y muy estable, pero para cualquier otra cosa, especialmente la demanda errática o intermitente, el pronóstico probabilístico es el camino a seguir.

Además, los modelos de pronóstico histórico de series de tiempo, como Holt-Winters o Arima, tenían grandes deficiencias cuando la historia del producto era demasiado corta, errática, atípica o de bajo volumen, … La mayoría de los proveedores de software respondieron a esos problemas con dos enfoques, igualmente disfuncionales a su manera:

• Coprocesadores humanos: como el modelo de pronóstico a menudo produce resultados absurdos, los operadores humanos, es decir, los planificadores, se utilizan por el sistema como “coprocesadores” para anular manualmente los pronósticos cuando los “números no parecen correctos”. Desafortunadamente, la tarea es interminable, ya que los pronósticos deben actualizarse continuamente, lo que obliga a los planificadores a un ciclo interminable de anulaciones manuales. Esta tarea también produce efectos secundarios no deseados, donde los operadores humanos consideran que los pronósticos son incorrectos y tienden a corregirlos incluso cuando no lo son, a menudo basándose en una mera intuición.
• Competencia de modelos: como cada modelo de pronóstico de series de tiempo tiene sus propias fortalezas y debilidades, una competencia de muchos modelos de pronóstico, según el razonamiento, debería dar buenos resultados al permitir que el sistema “seleccione” el mejor modelo en cada situación. Desafortunadamente, esto falla por dos razones. Primero, todos los modelos se basan en un marco de series de tiempo y, por lo tanto, están sujetos a las mismas limitaciones. En segundo lugar, todos los modelos son “clásicos” y no pueden proporcionar los pronósticos probabilísticos que requiere la cadena de suministro.

Además, el pronóstico no se trata solo de la demanda. También se deben pronosticar los tiempos de entrega. Además, la estructura de la cadena de suministro es importante. En B2B, un flujo constante de ventas puede ocultar el hecho de que todos los pedidos provienen del mismo cliente. Si se pierde este cliente, muchos artículos se vuelven instantáneamente sobreabastecidos, si no están obsoletos. Una optimización predictiva adecuada de la cadena de suministro debe tener en cuenta este riesgo. La tecnología de Lokad ha sido diseñada en consecuencia.

En cuanto al ángulo específico de compartir pronósticos con proveedores, si bien una mejor coordinación entre compradores y proveedores siempre es preferible, hemos observado que las coordinaciones exitosas impulsadas por pronósticos entre empresas han sido pocas y distantes entre sí. Los proveedores tienen muchos clientes propios de todos modos[^proveedor]. Por lo tanto, incluso si los pronósticos entregados por los compradores locales fueran precisos, el proveedor no tiene forma de conciliar todos esos pronósticos dispares: la suma de los pronósticos NO es el pronóstico de la suma.

Módulo de seguridad

Sorprendentemente, para algunos APS, las características de seguridad no están presentes de forma predeterminada en el sistema, sino que se proporcionan como un módulo separado. El propósito de un módulo de seguridad es evitar el acceso de algunos usuarios. También permite a la administración asegurar las acciones de los componentes y restringir las vistas de áreas importantes del sistema, como los factores de control de la empresa, el mantenimiento de artículos, el mantenimiento de proveedores, los pedidos, las ofertas y otros componentes.

En el argot informático, aquí estamos hablando 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 en la que el sistema cree que son. Aquí, Lokad adopta el enfoque moderno de que la autenticación debe ser delegada siempre que sea posible. Los usuarios finales no deben tener otra contraseña con la que lidiar. En cambio, Lokad aprovecha SAML como el estándar de la industria de facto para delegar la autenticación a la gestión de identidades federadas (FIM).
• La autorización proporciona el control detallado sobre quién puede hacer qué dentro del sistema. Aquí, Lokad cuenta con un extenso sistema canónico de ACL (Lista de Control de Acceso), que también es la práctica de facto de los sistemas empresariales modernos. Lokad también cuenta con algunas capacidades de personalización, que complementan la ACL desde una perspectiva de experiencia de usuario.

Lokad activa todas sus características de seguridad de forma predeterminada, sin importar qué paquete se haya vendido originalmente a alguno de nuestros clientes. Creemos que la seguridad opcional[^seguridad] es una práctica terrible por parte de los proveedores de software. Asegurar el software ya es extremadamente difícil; tal práctica solo empeora las cosas.

Para ser justos, el ángulo de la ACL probablemente sea la preocupación menos desafiante de todo el asunto de la seguridad del software. Una pregunta más interesante es: ¿cuánta seguridad por diseño ofrece la arquitectura misma del sistema? Sin embargo, responder a esta pregunta va más allá del alcance del presente artículo.

Exportar a Excel

El módulo de exportar a Excel proporciona una forma sencilla de transportar datos para su uso en otros sistemas o para su análisis.

Como es razonablemente sencillo producir hojas de cálculo de Excel², muchos proveedores, incluido Lokad, ofrecen capacidades en esta área. Sin embargo, un examen más detenido indica que la mayoría de los proveedores solo ofrecen capacidades a medias. Veamos los puntos destacados de las implementaciones buenas de exportación a Excel:

• Historización completa: el sistema debe ofrecer la posibilidad de rastrear y volver a descargar cada hoja de cálculo de Excel exportada. De hecho, cuando se enfrenta a cifras incorrectas en la hoja de cálculo, un problema que ocurrirá (incluso debido a entradas de datos incorrectas), no tener una trazabilidad completa sobre la ruta de código que generó esta hoja de cálculo complicará enormemente, ralentizará y, a veces, impedirá cualquier intento de depurar y solucionar el problema.
• Maximizar las capacidades de la hoja de cálculo: los profesionales esperan poder generar hojas de cálculo abultadas de hasta 1 millón de líneas³, que es el límite real de Excel. Por lo tanto, el sistema debe ser capaz de generar hojas de cálculo pesadas para no obstaculizar a los profesionales que solo quieren realizar sus propios análisis de datos con una herramienta familiar. Por supuesto, los profesionales también esperan que estas exportaciones sean rápidas.
• Protección incorporada contra ataques a las hojas de cálculo: Excel es un vector de ataque peligroso para las grandes organizaciones. Desafortunadamente, asegurar las hojas de cálculo generadas por el sistema no puede ser una ocurrencia tardía, debe ser una parte integral del diseño, prácticamente desde el primer día.
• Configurabilidad programática de las exportaciones: Tener que lidiar con dos piezas de software, es decir, el APS y Excel, ya es lo suficientemente complicado para los profesionales de la cadena de suministro. La situación no debe empeorar con hojas de cálculo que siempre requieren algún procesamiento adicional posterior a la extracción para poder utilizarse. Esto implica que todo debe suceder antes 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 hacen. El diablo está en los detalles.

Conclusión

Nuestra convicción es que Lokad es un software más simple que la mayoría de los APS en el mercado. Sin embargo, nuestra capacidad para ofrecer rendimiento de la cadena de suministro a través de tecnologías predictivas es mayor. De hecho, la mayor parte de la complejidad del APS es accidental, derivada de las elecciones de diseño de software realizadas hace décadas para resolver problemas de software internos que ya no existen. Sin embargo, la mayoría de las elecciones arquitectónicas de software, una vez realizadas, no se pueden deshacer.