supply chain science

Joannes Vermorel

Las tarifas que Lokad cobra a sus clientes empresariales son sencillas1: una tarifa mensual fija por una combinación de software+expertos2. Para sorpresa de algunos, nuestras tarifas mensuales tienden a mantenerse fijas a lo largo del tiempo, en lugar de disminuir drásticamente al final de la fase de incorporación. La mayoría, sin embargo, no se sorprende, ya que enfrentar otra demostración absurda de codicia por parte de un proveedor es simplemente otro lunes en el mundo del enterprise software. Sin embargo, esto no es una muestra de avaricia desenfrenada según los manuales. Más bien, esta tarifa es lo que se requiere para lograr un rendimiento duradero de supply chain performance.

Iron worker over cityscape

La ruta más rentable para los proveedores de software empresarial es, y siempre ha sido, take the money and run. Las tarifas de licencia iniciales son comparables a imprimir dinero. En comparación con la licencia, la integración es más ardua. Los riesgos son mayores y los márgenes más estrechos. Como resultado, los grandes proveedores suelen subcontratar completamente esta parte, cultivando una red de integradores que pueden asumir la presión por ellos. Sin embargo, la parte menos rentable, desde la perspectiva del proveedor, es - de lejos - el mantenimiento. De manera anecdótica, esta es la razón por la cual los proveedores, a pesar de cobrar tarifas de mantenimiento considerables, aún imponen actualizaciones a sus clientes. Las tarifas de mantenimiento, a pesar de ser sustanciales, ni siquiera se acercan a lo que se requeriría para que el proveedor sostenga su propio legado.

El supply chain optimization es un caso especial, sin embargo, ya que los proveedores (no Lokad) han “logrado” eliminar el mantenimiento. Este “éxito”, sin embargo, ciertamente no es el que sus clientes habían imaginado.

Desde la década de 1980, los proveedores (como Lokad, pero décadas antes) han estado entregando software para automatizar supply chain decisions3. Desde entonces, casi todas las grandes empresas han adquirido no una, sino a menudo varias de estas soluciones. Incluso los ERPs, que significan Enterprise Resource Planning, obtuvieron su nombre en la década de 1990 a partir de esta ambición de automatizar la parte de la “planificación”. De lo contrario, los ERPs se llamarían ERMs, denotando Enterprise Resource Management.

Sin embargo, la automatización de supply chain decisions no se materializó. Los sistemas han sido desplegados, pero ya sea que estén acumulando polvo o esquivando su misión original4. Como resultado, la gran mayoría de las supply chain todavía se gestionan a través de spreadsheets, demostrando que aunque esas soluciones de optimización se consideraran un éxito al principio, algo salió mal con el mantenimiento.

Esas fallas son lucrativas en lo que a los proveedores de software se refiere. El proveedor se queda con las tarifas de licencia, posiblemente en forma de un compromiso multianual (en el caso de SaaS). Dado que las soluciones no están funcionando – al menos no la parte de optimización – se requiere poco o ningún mantenimiento. A los clientes no les preocupan las capacidades del software que de todos modos no están utilizando, y en consecuencia, no presionan mucho al proveedor. De la solución original, solo un fragmento permanece en uso - generalmente, una puerta de entrada de datos sencilla para gestionar reglas básicas de automatización integradas en los sistemas de la empresa (por ejemplo, los ajustes min/max para SKUs).

En el otro extremo del espectro, Lokad sí logra ofrecer supply chain decisions automatizadas de nivel de producción. Sin embargo, se requieren esfuerzos continuos de un grupo de trabajo dedicado al cliente - los supply chain scientists en la jerga de Lokad - para que esto suceda. El scientist es el encargado de elaborar, y luego mantener, la receta numérica que genera las supply chain decisions de interés.

La receta numérica resultante puede dejarse sin supervisión. Esto es, en esencia, lo que significa la automatización de nivel de producción en el contexto de supply chain optimization. Así, el supply chain scientist puede ser eliminado de la ecuación en cualquier momento sin causar ningún daño a la empresa.

Dicho esto, la supply chain es una bestia en constante cambio, lo que naturalmente acarrea efectos en cadena. Si bien nuestros algoritmos pueden manejar cambios en la magnitud de los flujos, aún no disponemos de algoritmos que puedan abordar todos los otros cambios sutiles necesarios para mantener la receta numérica de nivel de producción.

Como resultado, los supply chain scientists se ven enfrentados a una serie de tareas que deben abordarse una vez que Lokad esté en producción:

  • Disponibles nuevos datos5, y la receta numérica debe actualizarse para aprovechar estos nuevos datos. Por el contrario, algunas fuentes de datos se eliminan progresivamente, y las dependencias numéricas deben cortarse en consecuencia. En empresas de gran tamaño, el applicative landscape está en constante evolución, no solo durante la actualización del ERP.

  • La estrategia de la empresa cambia. La receta numérica es el reflejo de la intención estratégica del cliente, y este reflejo va mucho más allá de elegir valores para un puñado de parámetros. No es común que el supply chain scientist reescriba por completo porciones de la receta para acomodar inflexiones en la estrategia, pero esto ocurre ocasionalmente.

  • Se debe mantener la confianza. El liderazgo de la supply chain necesita que el supply chain scientist proporcione evidencia continua de que la receta numérica se comporta correctamente. Se espera que el scientist no solo produzca nueva instrumentación para reflejar fresh o revised performance indicators, sino también que responda a cualquier pregunta que el liderazgo pueda plantear.

  • Se debe mantener la transparencia. El scientist es responsable de ‘white-boxing’ la receta numérica. Esto implica entrenar a los equipos para que tengan un nivel adecuado de comprensión, lo que a su vez les permite aprovechar al máximo la automatización proporcionada por la receta numérica. A medida que los equipos se rotan, los nuevos integrantes deben ser (re)entrenados.

Si fallamos en alguna de estas tareas, los practitioners de la supply chain no tendrán más opción que recurrir a sus spreadsheets.

Por lo tanto, mientras la receta numérica puede dejarse sin supervisión durante semanas6, su relevancia se deteriora invariablemente con el tiempo. Como tal, se requieren recursos de ingeniería continuos para mantener la receta numérica relevante. A pesar del progreso reciente en artificial intelligence, diseñar una pieza de software capaz de auto-mantenimiento sigue estando muy lejos del estado actual del arte. Quizás resulte polémico escribirlo, pero la tarea parece tan difícil como el desafío de alcanzar la inteligencia artificial general.

Aunque se requieran contribuciones continuas del supply chain scientist, se podría pensar erróneamente que estos esfuerzos se reducirán una vez que la receta numérica esté en producción. Nuestra experiencia ha demostrado lo contrario. La complejidad de la receta numérica se expande invariablemente para igualar cualquier nivel de recursos de ingeniería que esté disponible7.

En la última década, hemos observado repetidamente un punto de inflexión en lo que respecta a la inversión de recursos. Si los recursos iniciales invertidos en la configuración de la receta8 superan lo que la empresa proyecta invertir anualmente en su mantenimiento, entonces la receta no recibe el nivel adecuado de cuidado necesario para preservar su estatus de nivel de producción. El síntoma más frecuente de este descuido es una acumulación prolongada de tareas para todas aquellas piezas importantes, aunque no inmediatamente críticas: documentación, revisiones de código, limpieza del código, instrumentación, etc.

Ninguna tecnología o proceso garantiza el éxito empresarial9, pero un mantenimiento inadecuado es una receta probada para llevar a una empresa de vuelta al punto de partida - antes de ahogarla sumariamente en un mar de spreadsheets. No permitas que tu empresa se convierta en otro punto de datos en nuestro creciente registro de fallos en la supply chain perfectamente evitables.

  1. El mundo del software empresarial está lleno de situaciones excepcionales, con empresas que son adquiridas, fragmentadas, fusionadas y/o que caen en bancarrota. De vez en cuando, tenemos que renunciar a la simplicidad para mantenernos en sintonía con lo que sea que haya ocurrido con el cliente original. ↩︎

  2. El modelo de negocio de Lokad probablemente se describa mejor como Supply Chain as a Service. En la jerga de Lokad, los supply chain scientists son los empleados que lideran la iniciativa de supply chain en nombre de nuestros clientes. Ver Supply chain as a Service ↩︎

  3. Decisiones diarias mundanas como las decisiones de reabastecimiento de inventario, decisiones de lotes de producción, decisiones de asignación de stock y de transporte, etc. ↩︎

  4. Hay una gran cantidad de pseudo-automatizaciones circulando: ajustes de inventarios min/max donde se espera que el planificador actualice el mínimo y el máximo; stocks de seguridad donde se espera que el planificador ajuste los niveles de servicio objetivo; forecasts de demanda fraccionados donde se espera que el planificador redondee – en el momento adecuado – debido a la presencia de MOQs; etc. Todas esas tareas tratan al planificador como una especie de “coprocesador humano” del sistema, trasladando invariablemente la carga, en la práctica, de vuelta a los spreadsheets. ↩︎

  5. Los datos más recientes podrían ser simplemente una tabla existente dentro de una aplicación. Las aplicaciones empresariales son vastas, y la mayoría de las veces la gente solo utiliza una pequeña fracción de las capacidades disponibles. Si el proceso se revisa para aprovechar capacidades que, hasta ahora, han quedado sin usar, los nuevos datos podrían volverse relevantes para propósitos de supply chain. ↩︎

  6. A menos que ocurra algo dramático como una guerra, un confinamiento, una migración de ERP, una inundación, ransomware, una huelga, un nuevo CEO, un terremoto, una reorganización, una nueva tarifa, un recorte presupuestario, una tormenta de nieve, una nueva regulación, etc. En otras palabras, un evento que exija una revisión inmediata de la receta numérica. Afortunadamente, tales situaciones son raras, con solo un par de instancias como máximo por trimestre. ↩︎

  7. La configuración de la receta numérica puede verse como una aplicación directa de la Ley de Parkinson, que establece que el trabajo se expande para llenar el tiempo asignado para su finalización. ↩︎

  8. Un horizonte temporal típico es de 6 a 9 meses para esta fase. ↩︎

  9. Algunas tecnologías sí proporcionan casi certeza de enormes gastos generales, sin embargo. No todas las tecnologías son iguales, y mucho menos están igualmente dispuestas a abordar los desafíos de la supply chain. Ver Factors of success in predictive supply chains ↩︎

Regresar al Blog ›

Más publicaciones

El rol de IT El rol de IT
Sobre el ruido, NPCs, chatbots y supply chain Sobre el ruido, NPCs, chatbots y supply chain
La resiliencia de supply chain requiere ancho de banda La resiliencia de supply chain requiere ancho de banda