¿Cuántas personas se necesitan para cambiar una bombilla supply chain?

Joannes Vermorel

Las supply chains implican un mosaico de enterprise software. Estas capas de software se han implementado gradualmente, y a veces de manera desorganizada, a lo largo de las últimas cuatro décadas¹. El venerable EDI (Electronic data interchange) puede estar junto a un prototipo de blockchain. Dichos sistemas operan de forma dominante aspectos mundanos, pero esenciales, de la supply chain: producción, almacenamiento, transporte, facturación, cumplimiento, etc.

Estos sistemas no fueron puestos en marcha con la intención de ofrecer un ambiente de datos limpio para fines de I+D. Este único hecho explica por qué la mayoría de las iniciativas de forecast, y más en general la mayoría de las iniciativas de data science, fracasan en supply chain. A modo de evidencia anecdótica, generalmente es más rápido trasladar físicamente todas las mercancías almacenadas en un warehouse a otro sitio que migrar toda la infraestructura IT a un nuevo lugar.

Como consecuencia de esta complejidad, el despliegue de iniciativas supply chain “modernas” involucra invariablemente a demasiados especialistas. Para una empresa de tamaño considerable, el proyecto típico de supply chain involucra:

• El consultor que dirige el proyecto y asiste a la alta dirección.
• El especialista en infraestructura IT que evalúa los riesgos involucrados con la infraestructura IT extra.
• El administrador de bases de datos que identifica las tablas relevantes en los sistemas pertinentes.
• El especialista en ETL que diseña la tubería que asegura la logística de datos.
• El consultor IT que aporta una mano extra con las partes IT caprichosas.
• El coordinador del proyecto que relaciona al personal IT con el personal de supply chain.
• El analista de negocio que elabora la mayoría de los informes para la dirección.
• El data scientist que se encargará de la parte del modelado predictivo.
• El soporte técnico del proveedor que se encarga de los bugs de la tecnología que se está introduciendo.
• El vendedor del proveedor que maneja las expectativas y realiza upselling de “stuff” a lo largo del proceso.
• El practicante de supply chain que representa la “voz del cliente”.
• El ejecutivo de supply chain que lidera la iniciativa.

Sin embargo, contar con muchos especialistas en el caso crea su propia serie de problemas. Nadie, ni siquiera la alta dirección, entiende realmente lo que está sucediendo. Las partes IT son invariablemente opacas para todos excepto para el personal IT. Por el contrario, IT lucha tanto y en tantas áreas – no solo en supply chain – que les queda muy poca capacidad para resolver los pormenores de los problemas que intentan solucionar. Finalmente, la data science agrava el problema con otra disciplina que es en su mayoría opaca para consultores, personal IT y practicantes de supply chain por igual.

Además, terceros, consultores, empresas IT y proveedores de tecnología tienen agendas propias, que no están alineadas con las de la empresa. Se puede ganar dinero asegurando algo de friction² extra en cada etapa del proceso. Esto permite que las cosas comiencen con un modesto presupuesto provisional, que “sorprendentemente” crece de manera constante con el tiempo conforme se necesitan invertir cada vez más recursos en 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 aporta nada de valor, pero no sabe cuál mitad.

En este sentido, la estrategia de Lokad, como proveedor de tecnología, ha sido abordar de forma frontal esta complejidad accidental. La esencia es simple: reducir dramáticamente el número de especialistas involucrados. Una persona, a saber, el supply chain scientist, se encarga de todo el pipeline IT, que comienza con los datos de entrada sin procesar y termina con las decisiones de supply chain finalizadas. El supply chain scientist asume la plena responsabilidad de todo lo que ocurre a lo largo del pipeline – incluidos los componentes inteligentes, como machine learning.

El software empresarial clásico no es compatible con supply chain porque un “configurator” no es lo suficientemente expresivo como para hacer frente a la inmensa diversidad de problemas que enfrentan las supply chains. Se necesita un lenguaje de programación³. Desafortunadamente, los lenguajes de programación genéricos, como Python, no son compatibles con el rol del supply chain scientist. El nivel de habilidad requerido es demasiado alto, y esos roles, dentro de la empresa, se convierten en ingenieros de software. No hay nada de malo en tener ingenieros de software, pero es necesario reintroducir el expertise 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 listados anteriormente forman parte de la iniciativa.

Sin embargo, para que el supply chain scientist pueda desempeñar tantos roles, es necesario contar con un entorno de programación dedicado: uno que permita al científico abordar los desafíos de la optimización predictiva de una supply chain con la mínima complicación⁴. La respuesta tecnológica de Lokad a este problema fue Envision, a domain-specific language.

El concepto de Envision se basa en la idea de que es mejor ser aproximadamente correcto que estar exactamente equivocado. Un experto que pueda abarcar mentalmente toda la situación de la supply chain tiene muchas más probabilidades de producir una solución sensata que 10 expertos, cada uno familiarizado sólo con una faceta de la situación. Además, la solución producida por una única mente – en comparación con la solución producida por un comité – es casi siempre más simple y fácil de mantener.

En la mayoría de los campos de la ingeniería, los beneficios de contar con un comité trabajando en el problema compensan la fricción extra introducida por la existencia misma del comité. Sin embargo, en supply chain, este raramente es el caso. La consistencia end-to-end de la estrategia, obtenida como producto de una única mente – o al menos, de pocas – tiende a superar la mayoría de las optimizaciones “locales” que invariablemente entrega un comité. Alinear la oferta y la demanda es, fundamentalmente, un desafío a nivel de sistema⁵.

El principal valor del supply chain scientist es operar a nivel de sistema, abarcando toda la supply chain, desde los registros electrónicos sin procesar hasta la estrategia ideada por la alta dirección de la empresa. Sin embargo, lejos de ser un solitario, el científico recibe mucha ayuda. IT facilita el acceso a los datos relevantes (sin intentar preprocess los datos). Operaciones documenta los procesos establecidos, las restricciones operativas y los diversos costes indirectos. Marketing clarifica los costos de oportunidad que no se pueden identificar en los libros contables, por ejemplo, los costos de faltante de stock. La alta dirección cristaliza la visión, aclarando qué es lo que el científico debería estar optimizando en primer lugar, etc.

Al final, las decisiones de supply chain⁶ no son el producto de un “sistema” en el que la responsabilidad se diluye entre muchas, frecuentemente decenas, de personas. Esas decisiones, todas, son el producto de las recetas numéricas implementadas por el supply chain scientist, una única mente, que asume la responsabilidad total de su desempeño en relación con la empresa en su conjunto. Esta persona es falible, pero recibe mucha ayuda, que incluye compañeros listos para asumir el rol si surge la necesidad. En mi experiencia, esta es la única manera de siquiera empezar a optimizar una supply chain, incluso si cualquier comité de tamaño considerable invariablemente entierra a todos los observadores bajo KPIs, gráficos e informes para intentar probar lo contrario.