Las cadenas de suministro involucran una variedad de software empresarial. Estas capas de software se han implementado gradualmente, y a veces de manera caótica, en las últimas cuatro décadas1. El venerable EDI (Intercambio Electrónico de Datos) puede estar junto a un prototipo de blockchain. Estos sistemas operan predominantemente aspectos mundanos pero esenciales de la cadena de suministro, como producción, almacenamiento, transporte, facturación, cumplimiento, etc.

¿Cuántas personas se necesitan para cambiar una bombilla de la cadena de suministro?

Estos sistemas no se implementaron con la intención de ofrecer un entorno de datos limpio para fines de investigación y desarrollo. Este hecho explica por qué la mayoría de las iniciativas de pronóstico y, en general, la mayoría de las iniciativas de ciencia de datos, fracasan en la cadena de suministro. A modo de evidencia anecdótica, generalmente es más rápido mover físicamente todas las mercancías almacenadas en un almacén a otro sitio que migrar toda la infraestructura de TI a un nuevo sitio.

Como consecuencia de esta complejidad, la implementación de iniciativas de cadena de suministro “modernas” inevitablemente involucra demasiados especialistas. Para una empresa de tamaño considerable, el proyecto típico de cadena de suministro involucra:

  • El consultor que dirige el proyecto y asiste a la alta dirección.
  • El especialista en infraestructura de TI que evalúa los riesgos asociados con la infraestructura de TI adicional.
  • El administrador de bases de datos que identifica las tablas relevantes en los sistemas correspondientes.
  • El especialista en ETL que diseña el flujo de datos logísticos.
  • El consultor de TI que brinda apoyo adicional en las partes técnicas.
  • El coordinador del proyecto que interactúa entre los profesionales de TI y los profesionales de la cadena de suministro.
  • El analista de negocios que crea la mayoría de los informes para la dirección.
  • El científico de datos que se encargará de la parte de modelado predictivo.
  • El soporte técnico del proveedor que navega por los errores de la tecnología que se está introduciendo.
  • El vendedor que gestiona las expectativas y promociona “cosas” durante el proceso.
  • El profesional de la cadena de suministro que representa la “voz del cliente”.
  • El ejecutivo de la cadena de suministro que lidera la iniciativa.

Sin embargo, tener muchos especialistas en el caso crea sus propios problemas. Nadie, ni siquiera la alta dirección, realmente entiende lo que está sucediendo. Las partes de TI son inevitablemente opacas para todos excepto los profesionales de TI. Por otro lado, TI está luchando tanto y en tantos frentes, no solo en la cadena de suministro, que le queda muy poco ancho de banda para resolver los detalles de los problemas que intenta resolver. Finalmente, la ciencia de datos agrava el problema con otra disciplina que es en su mayoría opaca para los consultores, los profesionales de TI y los profesionales de la cadena de suministro.

Además, terceros, consultores, empresas de TI y proveedores de tecnología tienen sus propias agendas, que no están alineadas con las de la empresa. Hay dinero que se puede ganar al garantizar cierta fricción adicional2 en cada etapa del proceso. Esto permite comenzar con un presupuesto provisional ajustado, que “sorprendentemente” tiende a aumentar constantemente a medida que se necesitan más y más recursos para la iniciativa.

Parte de la complejidad mencionada anteriormente es irreducible, pero otra parte es bastante accidental. El viejo chiste de que cada CEO sabe que la mitad de su empresa no está haciendo nada de valor, pero no sabe cuál mitad.

En este sentido, la estrategia de Lokad, como proveedor de tecnología, ha sido abordar frontalmente esta complejidad accidental. La esencia de esto es simple: reducir drásticamente el número de especialistas involucrados. Una persona, es decir, el Supply Chain Scientist, se encarga de todo el proceso de TI, que comienza con datos de entrada sin procesar y termina con decisiones de supply chain finalizadas. El Supply Chain Scientist asume la responsabilidad total de todo lo que sucede a lo largo del proceso, incluyendo aspectos inteligentes, como el aprendizaje automático.

El software empresarial clásico no es compatible con la supply chain porque un “configurador” no es lo suficientemente expresivo para hacer frente a la diversidad de problemas a los que se enfrentan las cadenas de suministro. Se necesita un lenguaje de programación3. Desafortunadamente, los lenguajes de programación genéricos, como Python, no son compatibles con el rol de Supply Chain Scientist. La barrera de habilidades es demasiado alta y esos roles, dentro de la empresa, se convierten en ingenieros de software. Sin embargo, no hay nada de malo en tener ingenieros de software, simplemente se debe reintroducir la experiencia en supply chain a lo largo del camino a través de especialistas que no sean ingenieros de software. Muy pronto, la mayoría de los roles mencionados anteriormente forman parte de la iniciativa.

Sin embargo, para que el Supply Chain Scientist asuma tantos roles, se necesita un entorno de programación dedicado: uno que permita al científico abordar los desafíos de optimización predictiva de una cadena de suministro con la menor cantidad de problemas4. La respuesta tecnológica de Lokad a este problema fue Envision, un lenguaje específico del dominio.

El concepto de Envision se basa en la idea de que es mejor estar aproximadamente correcto que exactamente equivocado. Un experto que puede tener toda la situación de la cadena de suministro en mente tiene muchas más probabilidades de producir una solución sensata que 10 expertos, cada uno familiarizado solo con una faceta de la situación. Además, la solución producida por una sola mente, en comparación con la solución producida por un comité, casi siempre es más simple y más fácil de mantener.

En la mayoría de los campos de ingeniería, la ventaja de tener un comité trabajando en el problema mitiga la fricción adicional introducida por la mera existencia del comité. Sin embargo, en la cadena de suministro, esto rara vez es el caso. La consistencia de extremo a extremo de la estrategia, obtenida como producto de una sola mente, o al menos de unas pocas, tiende a superar la mayoría de las optimizaciones “locales” que un comité inevitablemente ofrece. Alinear la oferta y la demanda es fundamentalmente un desafío a nivel de sistema5.

El valor principal del Supply Chain Scientist es operar a nivel de sistema, abarcando toda la cadena de suministro, desde los registros electrónicos en bruto hasta la estrategia diseñada por la alta dirección de la empresa. Sin embargo, lejos de ser un solitario, el científico recibe mucha ayuda. TI facilita el acceso a los datos relevantes (sin intentar preprocesar los datos). Las operaciones documentan los procesos en marcha, las restricciones operativas y los diversos costos indirectos. El marketing aclara los costos de oportunidad que no se pueden leer en los libros de contabilidad, por ejemplo, los costos de faltante de stock. La alta dirección cristaliza la visión, aclarando qué es lo que el científico debe optimizar en primer lugar, etc.

Al final, las decisiones de la cadena de suministro6 no son el producto de un “sistema” donde la responsabilidad se diluye entre muchas personas, frecuentemente docenas. Todas esas decisiones son el producto de las recetas numéricas implementadas por el Supply Chain Scientist, una sola mente, que se hace responsable de su desempeño en relación con la empresa en su conjunto. Esta persona es falible, pero recibe mucha ayuda, que incluye colegas dispuestos a hacerse cargo si surge la necesidad. En mi experiencia, esta es la única forma de comenzar a optimizar una cadena de suministro, incluso si cualquier comité de tamaño considerable inevitablemente enterrará a todos los observadores bajo KPI, gráficos e informes en un intento de demostrar lo contrario.


  1. Para tener una idea de cómo podría ser el software de ingeniería de la cadena de suministro dentro de un par de siglos, recomiendo A Deepness in the Sky (1999), uno de los mejores libros de Vernor Vinge. Es posible que incluso el advenimiento de los arqueólogos programadores como una profesión establecida ocurra en nuestra vida. ↩︎

  2. Con frecuencia, la fricción adicional comienza incluso antes de la iniciativa de la cadena de suministro en sí. Tener consultores “ayudando” a la empresa con los procesos de RFI y RFQ duplicará tanto los retrasos como los presupuestos con casi total certeza. ↩︎

  3. Esta necesidad de programabilidad se cumple hoy en día con Microsoft Excel. La gran mayoría de las cadenas de suministro actuales se gestionan a través de hojas de cálculo, incluso cuando se supone que se utilizan sistemas más sofisticados como APS (planificación y programación avanzada). ↩︎

  4. Muchos conceptos de TI son mejor abstraídos de los científicos de la cadena de suministro. Por ejemplo: programación orientada a objetos, codificación de texto, gestión de paquetes, gestión de redes, gestión de discos, gestión de memoria, administración de Linux, administración de bases de datos, recuperación ante desastres, protocolos de API, computación distribuida, multihilo, ataques de inyección, ataques de canal lateral, etc. ↩︎

  5. Russell Ackoff ilustra el pensamiento a nivel de sistema con el diseño de un automóvil. Si el CEO de un fabricante de automóviles les pidiera a sus empleados que identificaran, para cada parte del automóvil, la mejor parte encontrada en el mercado (los mejores frenos, los mejores ejes, …) juntar todas esas partes ni siquiera resultaría en un automóvil real. Las partes no encajarían. La parte “mejor” solo tiene sentido cuando se considera el automóvil en su conjunto, no de forma aislada. ↩︎

  6. ¿Cuánto comprar? ¿Cuánto producir? ¿Cuándo aumentar / disminuir el precio? ¿Cuánto stock mover? Etc. ↩︎