Entrega orientada al producto para la cadena de suministro - Clase 1.3

00:22 Introducción
02:40 ¿Por qué un producto? Porque el capitalismo
08:18 ¿Qué debería hacer el producto?
10:05 Desventajas de escala del software
12:50 Compremos un producto SCO ya hecho
21:58 SCM vs SCO
25:58 Interludio
28:21 SCO no es un producto de software común
33:26 Ingredientes de software para SCO
42:49 Sin embargo, las hojas de cálculo no son el objetivo final
46:51 Python tampoco es el objetivo final
58:52 SC no es una división de TI
01:03:19 En conclusión, dos desafíos a superar
01:07:04 Próxima clase y preguntas de la audiencia

Descripción

El objetivo de una Supply Chain Quantitativa es entregar o mejorar una aplicación de software que automatice una serie de decisiones rutinarias (por ejemplo, reabastecimientos de inventario, actualizaciones de precios). La aplicación se considera un producto que debe ser diseñado. La teoría de la cadena de suministro está ahí para ayudarnos a entregar una aplicación que dirija a la empresa hacia el rendimiento de la cadena de suministro, al tiempo que sea compatible con todas las restricciones que implica la producción.

Transcripción completa

Hola a todos, muchas gracias por unirse a esta serie de clases sobre cadena de suministro. Soy Joannes Vermorel y presentaré “Entrega orientada al producto para la optimización de la cadena de suministro”.

Entonces, primero, cuando hablo de un producto, me refiero a un producto de software. Para aquellos de ustedes que alguna vez hayan tenido el privilegio de investigar lo que hay debajo del capó de una aplicación de software empresarial moderna, puede ser una experiencia bastante interesante.

Para aquellos familiarizados con la obra de H.P. Lovecraft, hay algunas similitudes inquietantes. Lovecraft ha producido una serie de novelas y uno de los temas recurrentes es la idea del conocimiento prohibido. No es que el universo no pueda ser conocido, puede serlo. Es solo que lo único que protege a la humanidad es la ignorancia. La ignorancia no es un problema; es precisamente lo que nos protege de un universo demasiado aterrador para que nuestras mentes lo toleren. Esta idea se ha reciclado en muchos juegos modernos, especialmente en los juegos de rol, donde además de los tradicionales puntos de salud, los personajes tienen puntos de cordura. Si haces ciertas cosas que dañan tu cordura, pierdes puntos de cordura. El desafío con el software empresarial es poder crearlo mientras se preserva tu cordura, que es uno de los requisitos para agregar valor a la empresa. Así que, sigamos adelante.

¿Por qué un producto y, en particular, un producto de software? Veamos de cerca cómo operan tradicionalmente las cadenas de suministro. Tradicionalmente, había muchas personas en el terreno moviendo cosas, manipulando paquetes, conduciendo vehículos y realizando todo el trabajo manual. También había muchas personas involucradas en la producción, así como en las tiendas. Lo que ha estado sucediendo gradualmente en las últimas décadas es que el número de personas con trabajos de cuello azul ha estado disminuyendo constantemente. Hoy en día, en términos de producción, las cosas están muy automatizadas. Aún hay algunas industrias, como la textil, donde es difícil automatizar todo, por eso esas industrias se han trasladado a donde la mano de obra es más barata. La realidad es que los requisitos de mano de obra se han reducido enormemente.

Terminas con una situación bastante extraña donde, si miras hacia el futuro con vehículos autónomos acechando, muchas empresas tendrán más trabajadores de cuello blanco que manejan hojas de cálculo de Excel spreadsheets para gestionar la cadena de suministro que personas con trabajos de cuello azul en el terreno para realizar las operaciones de trabajo manual. Esto es a lo que me refiero cuando hablo de trabajo administrativo.

Otro aspecto peculiar es que las cadenas de suministro se han digitalizado para muchas empresas durante al menos dos décadas. No es que vayamos a introducir software en las cadenas de suministro; las cadenas de suministro ya están impulsadas y operadas mediante software. Pero cuando observamos el papel de los humanos en estos sistemas de software, los humanos se utilizan literalmente como coprocesadores humanos en un sistema de cadena de suministro promedio. Hay tipos específicos de operaciones que la CPU regular, el procesador de la máquina, no puede realizar, por lo que toda la tarea se delega en un humano. En conjunto con recetas numéricas simplistas, como el análisis ABC, el inventario mínimo-máximo y recetas similares, los humanos terminan pasando sus días apagando incendios. Siempre están lidiando con excepciones y condiciones que no se ajustan al marco estándar.

Desde una perspectiva de costos, todo esto es un gasto operativo (OpEx). Necesitas pagar a un ejército de empleados todos los días para manejar todas las decisiones mundanas que tu empresa necesita tomar a diario. Estas incluyen qué comprar, dónde colocar el inventario, si mover una unidad de un almacén a una tienda, y muchas otras decisiones de rutina. Los humanos toman estas decisiones y apagan incendios para lidiar con las deficiencias de las decisiones automáticas generadas ingenuamente por el sistema.

Mi propuesta para ti hoy es que queremos pasar de OpEx a gasto de capital (CapEx). Ese es todo el punto de esta entrega orientada al producto. Queremos construir un activo, ¿y por qué? Porque es capitalista. Si observas las 100 empresas más rentables del mundo en la actualidad, la mitad de ellas, en términos de ganancias, son empresas de software. Representan la esencia de las empresas ultracapitalistas, donde tienes una inversión inicial y luego terminas con un dispositivo o artefacto que genera valor agregado con una inversión marginal mínima.

Volviendo al tema de mi conferencia anterior, necesitamos robotización para poner el control de nuevo en manos de la gestión. La automatización y los humanos deben trabajar juntos; los humanos no deberían estar allí para lidiar con las deficiencias de políticas de inventario tontas como el mínimo-máximo. En cambio, deberían estar allí para agregar valor, mejorar las recetas numéricas y actuar como estrategas. Había un antiguo lema de IBM que decía: “Las máquinas deben trabajar; las personas deben pensar”. Ese es el tipo de pensamiento que se refleja en esta presentación. Queremos convertir la cadena de suministro en un activo capitalista, y para hacerlo, necesitamos convertir la cadena de suministro en una máquina que entregue un producto de software.

¿Qué hace realmente este producto? Resulta que hace algo bastante simple: toma decisiones. No decisiones arbitrarias y abiertas, sino decisiones mundanas y rutinarias como qué producir, cuántas unidades comprar a un proveedor y cuántas unidades mover de una ubicación a otra. A primera vista, puede parecer que hay muchas decisiones involucradas en la gestión de la cadena de suministro. Sin embargo, cuando se analizan las tareas, incluso las cadenas de suministro más complicadas solo requieren que se tomen unas pocas docenas de tipos de decisiones todos los días. Esto no es abrumador y es bastante razonable en términos del número total de características. Curiosamente, estas decisiones son en gran medida exclusivas, por lo que hay límites en lo que se puede hacer utilizando un enfoque de dividir y conquistar. Una vez que has decidido comprar 100 unidades a un proveedor, no puedes tener otro subsistema decidiendo comprar 200 unidades en su lugar. En algún momento, debes decidir cuántas unidades comprar y mover de una ubicación a otra. Estas decisiones son discretas, limitadas en alcance y en gran medida exclusivas. Lo que queremos es un software que genere decisiones de pedido de manera completamente automatizada todos los días.

Una cosa que creo que a menudo se entiende mal sobre el software es la noción de deseconomías de escala. Mientras que las economías de escala son familiares para la mayoría de las personas, lo contrario es cierto en el software, donde agregar un cuarto más de características puede duplicar el costo. Este concepto explica por qué las pequeñas empresas emergentes pueden competir con las grandes empresas, porque se centran en una fracción más pequeña de características, el costo de llevar su producto al mercado puede ser significativamente menor que el de una gran empresa.

Con la idea de las deseconomías de escala en mente, debemos decidir si construir, comprar o tomar otro enfoque para nuestro producto de optimización de la cadena de suministro. Si elegimos comprar el producto a un proveedor, debemos considerar las características que el proveedor de software tendrá que ofrecer para atender al mercado.

Entonces, consideremos comprar un producto de optimización de la cadena de suministro listo para usar. En estas diapositivas, proporciono una revisión de solo una pequeña fracción de todas las cosas que necesitamos abordar. Tengo experiencia de primera mano en esto, ya que cuando comencé Lokad en 2008, comencé con un pequeño producto de software orientado más hacia la previsión que hacia la optimización de la cadena de suministro. A medida que comencé a trabajar con clientes, me di cuenta de que había tantas características y capacidades que no tenía, y a medida que avanzaba con otros clientes, encontraba aún más capacidades faltantes. Parecía ser un proceso interminable de descubrir nuevos requisitos.

Echemos un vistazo solo a las características principales. Primero, tenemos empresas que son B2C o B2B, que exhiben patrones completamente diferentes en la gestión de la cadena de suministro. Por ejemplo, las empresas B2B suelen tener menos clientes, pero esos clientes realizan pedidos de cantidades mucho mayores. Esto crea diferentes tipos de riesgos, como el riesgo de perder un solo cliente que representa una parte significativa del volumen de negocios de la empresa. Luego, hay modelos de negocio más complejos como B2B2C o B2B2B.

Considere los diversos tipos de sitios que deben cubrirse, como tiendas, almacenes e instalaciones de producción. Cada tipo de sitio viene con su propio conjunto de desafíos. Las tiendas, por ejemplo, son propensas a inexactitudes en el inventario, incluso con tecnología RFID, simplemente porque los clientes pueden mover los productos. Los almacenes y las instalaciones de producción, como granjas u operaciones mineras, tienen sus propios problemas y incertidumbres en el rendimiento de la producción.

Las redes de la cadena de suministro pueden tener diferentes niveles o escalones, que van desde sistemas de un solo escalón hasta sistemas de múltiples escalones. La complejidad de gestionar la cadena de suministro aumenta significativamente a medida que aumenta el número de escalones. La topología de la red es otro aspecto importante a considerar. Una topología de árbol es la ruta clásica de la cadena de suministro hacia adelante, donde algunos sitios de producción despachan a varios almacenes, que a su vez distribuyen a numerosas tiendas. Sin embargo, pueden existir otras topologías, como los grafos acíclicos dirigidos (DAG), donde una tienda puede ser atendida por varios almacenes.

Entonces, básicamente, no es solo un árbol en términos de gráficos, puede reconectarse, aunque aún es solo hacia adelante. Pero lo mismo puede ocurrir con un Grafo Acíclico Dirigido (DAG) cuando tienes múltiples proveedores. Incluso puedes tener bucles en el gráfico de tu cadena de suministro, lo que sucede cuando se involucran reparaciones. Por ejemplo, en la industria minera o en la industria aeronáutica, hay toneladas de bucles de reparación con equipos reparables.

Ahora bien, el inventario en sí no tiene una sola naturaleza; varía mucho. No puedes simplemente decir: “Oh, tengo esta idea de que tengo SKUs y ya está”. No, no es así, porque primero tienes materias primas que se miden literalmente en cantidades como gramos, kilogramos o volumen. Luego tienes las unidades que son las unidades limpias y bonitas, que son las más comunes. Pero también puedes tener mucho inventario que ocurre con mucha frecuencia, por ejemplo, en la industria farmacéutica o en el negocio de alimentos, donde el lote viene con fechas de vencimiento específicas. Incluso puedes tener inventario completamente serializado, donde cada unidad tiene su propio número de serie. En términos de optimización de la cadena de suministro, eso cambia completamente el juego, por lo que es un problema completamente diferente cuando estás analizando cada una de esas cosas.

Luego, obviamente, tienes todos los problemas de los marketplaces. En Lokad, tenemos clientes en literalmente todas las situaciones posibles. Tenemos clientes que venden en un marketplace de terceros, pueden tener su propio marketplace o pueden tener ambos. Puede ser algo secundario para que puedan usarlo para liquidar las cosas que no vendieron. Hay muchas situaciones.

Ahora, solo como ejemplo, piensa por un momento en lo que es un pedido. Tienes el pedido al contado, donde básicamente compras algo directamente en el mostrador y es tuyo. Pero también puedes tener un pedido que dice: “Lo estoy comprando, pero no quiero que este artículo se entregue de inmediato; quiero que se entregue dentro de un mes”. Obviamente, desde una perspectiva de optimización de la cadena de suministro, es un juego completamente diferente porque si sabes de antemano que tendrás que entregar una cierta cantidad de cosas en una fecha específica, no quieres pronosticarlo, por lo que es algo completamente diferente.

Y luego tienes un pedido configurado, que es, por ejemplo, cuando compras una computadora en línea y puedes elegir cuánta memoria, cuánto disco duro, qué tipo de sistema operativo, qué idioma se configurará para tu computadora y cómo será tu teclado, entre otras cosas. Entonces, puedes tener un configurador masivo, y eso cambia el panorama nuevamente. Esto también ocurre con cosas como bicicletas o autos y cambia por completo el panorama cuando tienes este tipo de cosas porque te brinda opciones y formas de ver el problema de optimización de la cadena de suministro que son completamente diferentes.

Incluso para los precios, puedes tener el precio por unidad que es fijo, súper simple y súper lineal, pero no es lo único. Puedes tener descuentos por cantidad, por ejemplo, si compras diez unidades, entonces obtienes un descuento. O puedes tener programas de lealtad donde algunos clientes con una tarjeta de lealtad pueden obtener un descuento, pero solo en ciertos tipos de productos o solo dependiendo de ciertas condiciones. E incluso en B2B, puedes tener cosas muy frecuentes que se negocian, por lo que es literalmente una transacción donde se venderán muchas cosas, pero tienes un precio de catálogo regular. Sin embargo, un proveedor puede dar un descuento a un cliente porque son importantes, y así es como se hace. En resumen, apenas he estado hablando durante minutos ahora, y solo he cubierto lo básico. Ni siquiera he comenzado a tocar las cosas imprescindibles. Así que solo haz una pausa por un momento e intenta pensar en cómo se verá un producto de software empresarial listo para usar que se supone que brinda optimización de la cadena de suministro. La cantidad de características que se deben cubrir es literalmente insana, y cuando intentas pensar en cómo juntar todas esas cosas en un monolito, literalmente pierdes la razón. Volvemos a esta idea de que no es que el universo no se pueda conocer, es solo que si estás expuesto a la verdad desnuda del universo, pierdes tu cordura.

Entonces, tenemos un problema importante, y aquí tenemos que diferenciar la gestión de la cadena de suministro de la optimización de la cadena de suministro. Esa es una distinción que ya introduje en una de mis conferencias anteriores. Existe una gran confusión entre el lado de la gestión y el lado de la optimización. La gestión se trata de contabilidad, apoyo a los flujos de trabajo y principalmente procesos de entrada de datos. Si quieres representar todas las cosas que acabo de describir, es mucho terreno por cubrir, pero se puede hacer. Un ERP “obeso” puede hacer eso. Sí, terminarás con 10,000 tablas, será bastante feo, pero es posible. Pero no te equivoques, el ERP (que debería llamarse ERM, Enterprise Resource Management) no va a hacer mucho. Simplemente se encargará de hacer un seguimiento de esas cosas. Entonces tendrás toneladas de entidades: MOQs, verificado; descuentos por cantidad, verificado; tiendas, verificado; almacenes, verificado, pero no necesitas tener ningún grado de inteligencia. Se trata simplemente de contrapartes digitales mundanas para reflejar los datos, haciendo posible ingresar los datos en el sistema, y eso es todo.

Es posible porque aquí podemos hacer trampa un poco con esta regla de “un cuarto más de características duplica el costo”. Hay algo que no dije realmente al respecto: funciona si mantienes tus características completamente segregadas. Mientras las características no interactúen entre sí, está bien; no estás sujeto a esta maldición de las desventajas de escala. Desde una perspectiva de entrada de datos, no hay problema. No necesitas tener la interfaz de usuario que te permita manejar los MOQs conectados con lo que te permite agregar una tienda adicional a la red. Esas dos cosas pueden estar completamente segregadas.

Sin embargo, cuando se trata de la optimización de la cadena de suministro, lo mismo no es cierto. Si tienes MOQs, tendrán profundas implicaciones en la frecuencia con la que haces pedidos, en la frecuencia con la que entregarás cosas desde tu almacén a tus tiendas. Hay muchas consecuencias de gran alcance. No puedes segregar las cosas porque, en última instancia, tu cadena de suministro es solo un sistema en el que todo tiene influencia en todo. Entonces, desde una perspectiva de optimización de la cadena de suministro, literalmente tienes el problema de que todas esas cosas tienen que estar conectadas si quieres lograr la optimización, y ahí es donde las cosas se desmoronan.

En el lado de la gestión, potencialmente puedes terminar con un producto. Sin embargo, para la optimización de la cadena de suministro, la respuesta es que no puedes. Quiero decir, puedes pretender hacerlo, pero literalmente no puedes. Incluso en Lokad, que comenzó no como una empresa de predicción de suministro que se especializa en la optimización de la cadena de suministro predictiva, sino más bien como una previsión como servicio. Si vuelves al blog de Lokad en 2008, inicialmente comencé con la previsión de series de tiempo, lo cual fue un grave error. Aun así, así es como comencé. Incluso para la previsión de series de tiempo, que es un pequeño subconjunto de todo el problema, es inmanejable. Esa es mi conclusión después de estar en este negocio durante más de 12 años.

Si tenemos que volver al mundo específico de la producción de software, es algo muy único. A menos que hayas sido entrenado como ingeniero de software y estés familiarizado con la forma en que las grandes y exitosas empresas de software producen software, es probable que sepas muy poco al respecto. Resulta que es un mundo muy específico con muchos aspectos vastamente contraintuitivos. Las empresas tradicionales, especialmente aquellas con una mentalidad de ingeniería mecánica clásica o una mentalidad de marketing, luchan enormemente para entender cómo funciona el software en absoluto.

Cubriremos estos aspectos con más detalle en futuras conferencias, pero hay un libro que realmente me gusta, producido por Joel Spolsky, un ex empleado de Microsoft que trabajó en los primeros equipos de Microsoft Excel. También es cofundador de Stack Overflow y Trello. En 2004, cuando yo era solo un estudiante, leí su libro y su blog. El libro se titula “Joel on Software” y te da una idea humorística de cómo se ve dirigir un negocio exitoso de software. Es muy diferente de lo que la mayoría de las personas fuera de esta industria esperan. Agregaré los detalles de este libro en la descripción del video.

Pero tengamos en cuenta que la optimización de la cadena de suministro no es un producto de software promedio. Por lo general, cuando lidias con un producto de software promedio, quiero decir, sí, tienes algunos comportamientos adversos, dependiendo del tipo de producto de software. Si estás lidiando con una red social, puedes tener muchas personas publicando contenido odioso, lo cual es un juego completamente diferente. Sin embargo, cuando se trata de software empresarial clásico, como Microsoft Word o Excel, es un producto en el que quieres tener el diseño correcto, pero no hay ninguna emergencia en absoluto. En el caso de los productos de software tradicionales, está bien pasar años refinando tu diseño y producto. Es una inversión a largo plazo y debes mirar décadas hacia adelante. No hay razón para apresurar nada en términos de desarrollo. Sin embargo, la optimización de la cadena de suministro no funciona así. No tienes elección, ya que las cosas suceden todo el tiempo y el terreno es muy accidentado.

Puedes tener situaciones extremas como la pandemia u otros problemas como el ransomware, que pueden cerrar la mitad de tu red. Necesitas tomar decisiones inteligentes para aprovechar al máximo las capacidades que aún tienes a tu disposición. Puedes enfrentar la inmovilización de flotas debido a incidentes trágicos, movimientos políticos como aranceles que interrumpen tu estrategia, o desastres naturales como tsunamis o incendios y olas de calor, como los de California o Australia. Estos eventos suceden y cuando lo hacen, necesitas poder reaccionar literalmente en horas.

Tienes tu producto de software, pero necesitas realizar cambios y quieres realizar cambios programáticos. Recuerda, si estás en la mentalidad de entregar un activo de software, tienes un pequeño equipo que impulsa el software que, a su vez, impulsa tu cadena de suministro. No tienes un ejército de empleados haciendo lucha contra incendios todo el día. Incluso si tienes un ejército de empleados, necesitas capacitarlos y cuando sucede algo completamente inesperado, terminas con un ejército que no ha sido entrenado para esa situación específica. En mi experiencia, cuanto más personas tienes que gestionar, más tiempo lleva lograr cualquier cosa.

Hace solo unos días, un barco de carga perdió más de 1,800 contenedores debido a las malas condiciones climáticas. Estas cosas simplemente suceden y no puedes esperar eliminarlas. La cadena de suministro no es como la fabricación, donde puedes tener un sitio de producción con todo bajo control. Por definición, las cadenas de suministro ocurren en un mundo amplio, donde la mayor parte del tiempo no tienes control sobre los elementos. Hay tantas fuerzas fuera de tu control que necesitas poder lidiar con eventos sorprendentes. Ya sabes que sucederán sorpresas, así que necesitas estar preparado. Estar preparado no significa tener todo cuidadosamente planificado; se trata de tener un sistema donde puedas reaccionar en horas si es necesario. Esa es la esencia de lo que puedes hacer para abordar el problema de manera realista.

Ahora, ¿qué necesitamos en términos de ingredientes de software para la optimización de la cadena de suministro? Primero, necesitamos un almacenamiento de datos versátil para representar todos los diversos tipos de fuentes de datos. Hay tantas cosas que queremos representar, por lo que queremos algo muy versátil en este sentido, con mucha estructura y variedad.

En segundo lugar, deseas lógica programable. Estoy volviendo a esta idea: si no tienes lógica programable, ¿cómo lidiar con todos estos problemas? ¿Cómo unir todas estas cosas? No puedes comprar un producto prefabricado que tenga todo preprogramado para ti; eso no funciona.

A continuación, necesitas interfaces de usuario versátiles porque la forma en que deseas ver tus problemas variará enormemente de una situación a otra. Los KPI serán completamente diferentes de una empresa a otra, por lo que necesitas una interfaz de usuario versátil donde puedas presentar los números de la manera que consideres adecuada; de lo contrario, será una gran limitación.

También deseas capacidades de colaboración porque la cadena de suministro es trabajo en equipo por definición. Hay muchas personas involucradas y está distribuido, por lo que las capacidades de colaboración deben estar en el núcleo.

Por último, y tal vez de manera más controvertida, deseas capacidades programables que sean accesibles para personas que no son ingenieros de software capacitados. Esto es importante por varias razones. En primer lugar, no hay muchos ingenieros de software capacitados en el mercado laboral, por lo que es muy competitivo contratarlos. En segundo lugar, se requiere tanto esfuerzo y dedicación para convertirse en un talentoso ingeniero de software que es un desafío ser un especialista en supply chain al mismo tiempo.

No es muy común encontrar personas que tengan competencias duales en ambos campos. Lo mismo se aplicaría si estuvieras buscando a alguien que sea tanto programador como abogado, o programador y médico. Sí, encontrarás algunas personas con estas habilidades, pero ¿puedes hacerlo a gran escala o contratar más de ellos de manera confiable cada año si eres una empresa grande? Según mi experiencia dirigiendo Lokad durante una década, simplemente no funciona.

Deseas algo programable, pero no necesitas ser un ingeniero de software profesionalmente capacitado para lidiar con la programación. Recuerda, necesitas tener a alguien con competencia en cadena de suministro porque necesitas poder enfrentar en cuestión de horas las correcciones de programación a tu sistema sin abrir un ticket y pasarlo a IT. Si tienes que hacerlo de esa manera, entonces llevará semanas resolver los problemas, no horas. Entonces, ¿qué tipo de software puede resolver realmente el problema?

Bueno, Excel puede. No es bonito y puede que no se sienta como el pináculo del software moderno, pero cumple su función. Marca todas las casillas.

¿Almacenamiento de datos versátil? Sí, hasta cierto punto, puedes poner muchos datos de cualquier tipo en Excel. ¿Lógica programable? Absolutamente, Excel es completamente programable. ¿Interfaz de usuario versátil? Sí, puedes tener gráficos de barras, gráficos de líneas y muchas formas de presentar datos. En términos de interfaces de usuario, es muy versátil. Puede que no sea el más pulido, pero en términos de versatilidad, puede hacer mucho.

En cuanto a las capacidades de colaboración, es un poco rudimentario. Tienes algunas versiones de Excel en línea, que son marginalmente mejores, pero fundamentalmente, puedes compartir tus hojas de cálculo. El problema con la falta de funciones de colaboración no es que sea una aplicación de escritorio. El problema es la mentalidad que hay detrás de las hojas de cálculo, que no es adecuada para un trabajo colaborativo intenso. Por lo general, si tienes un colega que creó una hoja muy compleja, es más fácil recrear la hoja que tratar de entender lo que hicieron. Entonces, el problema con la falta de funciones de colaboración es la mentalidad que acompaña a las hojas de cálculo, que inherentemente tiene límites fuertes para la colaboración.

Sin embargo, Excel es completamente accesible para no desarrolladores, e incluso hay Visual Basic for Applications para tareas más complicadas. En términos de ingredientes, Excel marca todas las casillas correctas, lo que, creo, explica en gran medida el éxito que tiene operativamente en la mayoría de las cadenas de suministro.

En mi experiencia, la mayoría de las cadenas de suministro del mundo, desde las empresas más pequeñas hasta las más grandes y desde aquellas que nunca han invertido un centavo en software empresarial hasta aquellas que han invertido millones de dólares en software empresarial complicado para la optimización de la cadena de suministro, están impulsadas por Excel. Hay muy pocas excepciones. A veces, las personas usan Excel para revisar la configuración de mínimos y máximos en otro software, pero el mantenimiento de esta configuración se delega a quienes trabajan con Excel.

Excel está impulsando el mundo de la cadena de suministro hoy en día, y creo que no es una coincidencia. En su núcleo, las hojas de cálculo abordan fundamentalmente muchos de los problemas correctos. Se presentan muchas otras opciones como superiores, pero fallan por defecto si no sabes programar. Si no puedes programar, eso significa que cuando te enfrentes a un problema importante o una emergencia, estás en problemas. Las personas volverán a las hojas de cálculo de Excel en situaciones como la falta de una interfaz de usuario versátil o cuando una solución no sea accesible para no desarrolladores. Si solo un equipo de TI puede obtener resultados, las personas pueden abrir inicialmente tickets y esperar pacientemente, pero en tres meses, es probable que todos vuelvan a usar hojas de cálculo de Excel porque es más rápido. Excel no es el objetivo final, pero cualquier cosa que presentemos como un reemplazo superior deberá cumplir con los requisitos correctos.

¿Cómo podemos mejorar algo? En términos de almacenamiento de datos versátil, Excel es bueno pero no muy escalable. Procesar millones de líneas se convierte en un problema, incluso con las versiones modernas de Excel que pueden manejar un millón de líneas. Los problemas de rendimiento surgen rápidamente al operar a gran escala. La lógica programable en Excel es posible, pero es muy frágil y quebradiza. Si introduces inadvertidamente un error o un error en tu hoja de cálculo, depurarlo y localizar la fuente del problema se convierte en una pesadilla. La lógica se duplica infinitamente, lo que resulta en miles de copias de la misma lógica, lo que dificulta la identificación y corrección de errores.

La interfaz de usuario no es ideal, ya que no es completamente basada en web y los datos siempre están entrelazados con la interfaz. Existen capacidades de colaboración, pero son desordenadas. La colaboración debe ocurrir a nivel de lógica programable. Muchos proveedores de optimización de la cadena de suministro ofrecen colaboración en los resultados, como ajustar los pronósticos manualmente y permitir que varias personas participen. Sin embargo, este es el enfoque equivocado. Las colaboraciones deben ocurrir, pero deben ocurrir a nivel lógico, a nivel de lógica programable. Excel es muy accesible para no desarrolladores, pero cuando quieres hacer algo un poco más complicado, se vuelve desafiante. En la gestión de la cadena de suministro, queremos lidiar con todos los futuros posibles, lo que significa trabajar con pronósticos probabilísticos, variables aleatorias y abordar la incertidumbre. Si bien esto es posible en Excel, es bastante complicado. Excel es fácil para tareas simples, pero para situaciones más complejas, necesitas convertirte en un mago de Excel.

La mantenibilidad es importante, ya que quieres construir un activo con un valor creciente con el tiempo. Con las hojas de cálculo, es difícil lograr esto y es difícil crear algo realmente preciso, al menos en el sentido de un producto de software.

Las palabras de moda del día son IA y Python, con todas las tendencias y el bombo que rodea a la ciencia de datos. Sin embargo, para la gestión de la cadena de suministro, creo que Python es inferior a Excel.

No me malinterpretes; amo Python y creo que es un lenguaje brillante. Incluso se lo enseño a mi hija de 10 años. Sin embargo, hay varias razones por las que Python no es la mejor opción para la gestión de la cadena de suministro. Primero, requiere ingenieros de software. Aunque Python es uno de los lenguajes de programación más accesibles, cuando quieres hacer algo más complejo, necesitas un equipo de ingeniería de software, lo que crea desafíos cuando necesitas personas que sean expertas tanto en cadena de suministro como en ingeniería de software.

Python tiene características agradables, pero la forma en que se manejan las dependencias es bastante compleja y la gestión de paquetes es deficiente. Los paquetes son bloques de construcción que proporcionan capacidades adicionales, y cuando dices que quieres usar Python, no solo te refieres al lenguaje, sino también a todo el ecosistema de paquetes en el que estás interesado, como NumPy, Pandas, TensorFlow y SciPy, todas dependencias de terceros o bibliotecas de software. La gestión de paquetes ha sido deficiente durante más de una década y, aunque está mejorando, el progreso es lento. Hay muchos aspectos del diseño del sistema que dificultan su mejora.

El rendimiento también es deficiente, en su mayoría por diseño. El rendimiento de cálculo se refiere a la calidad del trabajo realizado por Python para aprovechar la potencia de cálculo bruta disponible en tu computadora. Sorprendentemente, Microsoft Excel hace un trabajo mucho mejor en este sentido. Excel está altamente optimizado, aprovechando sistemas multi-CPU, multi-core y ejecutando lógica compilada nativamente. Microsoft ha invertido mucho en hacer que Excel sea extremadamente rápido.

En contraste, Python tiene problemas inherentes que a menudo resultan en un rendimiento 100 veces más lento de lo que tu máquina podría teóricamente ofrecer. Si bien puede parecer aceptable para algunos, dada la potencia de las computadoras modernas, no es ideal para empresas con volúmenes de transacciones que superan los $50 millones. Quieres algo que ofrezca un buen rendimiento desde el principio.

La idea de usar una biblioteca de terceros como NumPy para abordar la falta de rendimiento de Python solo agrega complejidad. Puede que estés resolviendo el problema de rendimiento, pero estás creando un nuevo problema al introducir la complejidad adicional de NumPy, con la que debes lidiar y mantener a lo largo del tiempo. Esto también eleva el nivel en el lado de la ingeniería de software del problema.

Al intentar implementar soluciones en Python para la gestión real de la cadena de suministro, surgen varios problemas, como excepciones de referencia nula, excepciones de falta de memoria y tiempos de cálculo prolongados. Puedes encontrarte esperando 20 minutos para que se complete un cálculo, sin saber si alguna vez terminará o si deberías simplemente detener el proceso y reiniciarlo. Simplemente no lo sé, por lo que quieres cosas en las que tengas una muy, muy buena idea de cuánto tiempo va a llevar completar. Por cierto, si vuelvo a Excel, hoy en día, cuando hay una operación que lleva un poco de tiempo completar, Excel te dará una indicación bastante confiable, una barra de progreso sobre cuánto tiempo va a llevar. Entonces, nuevamente, quieres, y eso es parte de lo que me refiero como la preparación para la producción. Quieres tener algo que sea porque, nuevamente, es probable que el software que estás produciendo se ejecute sin supervisión, durante la noche o durante el lote nocturno, por ejemplo. Quieres algo que no requiera que un científico de datos cuide todo el proceso.

Y nuevamente, si tienes problemas con los científicos de datos, entonces necesitas la tercera competencia: experto en cadena de suministro, experto en ingeniería de software y ahora experto en científico de datos. Es posible tener esas tres cualidades en una persona, pero buena suerte para contratar a más de una persona al año, incluso si eres una gran empresa que tiene todas esas habilidades. Es simplemente muy raro.

Entonces queremos tener algo que mejore. Por cierto, lo primero que queremos mejorar es la defensa en profundidad. Los ransomwares están en aumento y cada vez que pones algo programable en tu organización, te expones al ransomware. Porque de repente, cuando tienes un programa, el programa en la máquina puede hacer un montón de cosas, incluyendo secuestrar la propia máquina en la que se está ejecutando. Sé que hay muchas formas de mitigar los problemas; puedes aislar cosas, puedes restringir, puedes tener derechos limitados y hay muchas formas de limitar los problemas. Sin embargo, cada vez que tienes algo como un lenguaje de programación genérico de propósito general, tu área de superficie de ataque, ese es un término técnico, es absolutamente gigantesca.

Básicamente, cada vez que estás insertando código así, te expones masivamente en términos de problemas de seguridad. Y recuerda, la forma en que normalmente se hace en un negocio de ingeniería de software regular es que el código se revisa entre pares. Revisas el código, tienes un proceso de revisión de código, alguien produce el código y hay un colega que va a revisar el código para asegurarse de que no haya trampas en el código. Pero si vuelvo al hecho de que el software tiene que ser robusto, tienes que poder responder en cuestión de horas. No podrás, desde una perspectiva de optimización de la cadena de suministro, tener un proceso de revisión de código en su lugar. Simplemente no es compatible con los retrasos y las emergencias a las que te enfrentarás.

Entonces, necesitas tener algo que te brinde defensa en profundidad por diseño. Luego quieres tener algo con un rendimiento transparente, donde sí, las cosas pueden llevar tiempo, pero necesitas estar en control. Necesitas saber de antemano cuánto tiempo va a llevar. Si no tienes eso, te expones a toneladas de problemas muy estúpidos, como tener una ventana de dos horas para entregar resultados y llegar tarde. ¿Y sabes qué? Los camiones ya se han ido. Es demasiado tarde. Entonces necesitas tener algo donde se cuide de eso.

Y lo mismo ocurre con las actualizaciones transparentes. Esa es la belleza de Excel. No tienes que preocuparte por el mantenimiento de Excel. Microsoft firmó un pacto en sangre hace décadas, que decía: si has producido una hoja de cálculo de Excel, la próxima versión de Excel que llegue al mercado podrá admitir tus hojas de cálculo. Y lo más increíble es que si miras Excel hoy en día, admite muchos formatos de Excel de competidores que ni siquiera existen más. Aún puedes leer hojas de cálculo que se produjeron con Lotus Notes y cosas por el estilo. La propuesta de valor de Microsoft en términos de actualizaciones transparentes es que la lógica que has producido funcionará para siempre, y sí, seguirán mejorando Excel durante décadas, pero ¿sabes qué? Se encargan de eso. Eso no es algo que veas cuando miras la transición de Python 2 a Python 3; fue una pesadilla y llevó una década. Entonces, Python es genial para muchas cosas, pero imagina que esas actualizaciones ocurran en los peores momentos, cuando tienes la peor pandemia, el peor arancel, la peor emergencia y necesitas que las cosas estén listas y funcionando. No puedes permitirte tener un tiempo de inactividad de seis meses solo porque necesitas ocuparte de una actualización. Eso no es algo compatible con la optimización de la cadena de suministro.

Entonces ahora tenemos que pensar en qué pasaría si consideráramos algo que pudiera ser diseñado teniendo en cuenta la cadena de suministro. Ese será el tema de la próxima conferencia.

Ahora, además, la cadena de suministro no es la división de TI. Cuando digo una entrega orientada al producto, nuevamente, no es que el software sea solo un medio, no un fin. No venderás tu software por licencias o una tarifa como lo hace, digamos, Microsoft. En esta visión que estoy presentando frente a ustedes en esta conferencia, TI es responsable de las prácticas fundamentales, las prácticas fundamentales de TI, como lo que debes hacer o no hacer en términos de seguridad, copias de seguridad, infraestructura básica, tu red, cómo administrar y sincronizar todo en términos de datos a nivel de la empresa, y proporcionar toda la orientación y capacitación.

Pero la idea es que la cadena de suministro debe ser dueña de las decisiones de la cadena de suministro. Deben ser dueños de todo el aparato que genera esas decisiones de la cadena de suministro, por lo que esa es su propiedad principal. En la conferencia anterior, dije lo que define al científico de la cadena de suministro: el científico de la cadena de suministro es alguien que es dueño de las decisiones numéricas producidas por el código. No es un sistema que produce decisiones; son recetas numéricas que han sido escritas por uno o varios científicos de la cadena de suministro, y esos científicos de la cadena de suministro son dueños colectivamente de esas decisiones numéricas. Se hacen cargo de eso, y la responsabilidad de la cadena de suministro es asegurarse de que todas las decisiones en la empresa sean consistentes. Si hay una promoción en marcha o un gran impulso de marketing, las cosas deben producirse a tiempo para que estén listas para ser servidas. No quieres terminar en una situación catastrófica donde estás promocionando algo cuando ya estás en una situación de escasez de stock, donde gastas dinero en un impulso de marketing para algo que ni siquiera puedes vender porque no tienes el stock o la capacidad para fabricarlos o proporcionar el servicio a tiempo, etc.

Entonces, tenemos dos divisiones que tienen enfoques muy diferentes. En mi visión ideal de lo que debería ser el departamento de TI, el departamento de TI no es una división donde pasas tickets. Esa no es la forma en que funciona. El departamento de TI está a cargo de la infraestructura básica. Es algo que funciona sin problemas todo el tiempo. Ni siquiera prestas atención, al igual que el Wi-Fi está funcionando. No prestas atención al Wi-Fi; solo prestas atención al Wi-Fi cuando no funciona. Un buen departamento de TI proporciona toda la infraestructura para que ni siquiera prestes atención a ellos. Ni siquiera te das cuenta de que existen porque simplemente funciona, al igual que tus correos electrónicos funcionan perfectamente, etc. De eso se trata un buen núcleo de TI. Y luego, TI es el tipo de personas que vienen a ayudarte a establecer todas esas prácticas que te dan una mano. La lógica programable es un poco difícil, así que a veces, ¿dónde vas a obtener la capacitación para mejorar un poco en programación? Bueno, la respuesta es que debería ser TI. No deberían venir a decirte: “Lo vamos a codificar por ti”, sino más bien: “Te vamos a entrenar para que puedas implementarlo tú mismo. Te ayudaremos con algunos conceptos, tal vez te ayudaremos con algunas cosas que son un poco más técnicas de lo que deberían ser”. A veces, tienes complejidad accidental, así que TI está ahí para apoyarte. Pero fundamentalmente, no están ahí para hacer el trabajo por ti. Deberían ser mentores y entrenadores, asegurándose de que nadie cometa un error terminal que exponga a toda la empresa a algo como un riesgo de ransomware o algo que podría ser un riesgo sistémico, en términos de TI, para la empresa.

Como prueba de fuego, si tu interacción entre TI y la cadena de suministro se realiza a través de documentos donde enumeras especificaciones o requisitos, esta no es la forma adecuada de tener una buena relación entre esas dos divisiones. Cuando digo una buena relación, me refiero a algo que realmente agregue valor a la empresa.

En conclusión, aquí tenemos dos desafíos desde el lado tradicional de la gestión de la cadena de suministro, que puede haber estado programando pero solo en el borde de las hojas de cálculo de Excel, sin siquiera darse cuenta inicialmente de que ya era una forma de programación. Tienes que superar tus miedos. Tienes que pensar que el mundo de mañana, tu división, estará a cargo de entregar un producto que funcione como un producto de software, y eso es un cambio enorme. Sí, pero es algo con lo que puedes lidiar. ¿Por qué? Porque si tienes las herramientas adecuadas, sí, hay programación involucrada, pero no es fundamentalmente, radicalmente más difícil que Excel. Nuevamente, el desafío no está en la técnica de la herramienta; literalmente está en la complejidad de la cadena de suministro en sí. El problema es difícil no porque tu herramienta sea difícil de manejar, sino porque tienes una cadena de suministro complicada en primer lugar.

Para la parte de la audiencia que tal vez esté más del lado de los científicos de datos o del lado de TI, lo que tienes que superar es la confianza excesiva. He visto, una y otra vez, a científicos de datos, y me incluyo en esta categoría, que tenían demasiada confianza en su capacidad para llevar un prototipo a producción. Esto es difícil, y las cadenas de suministro tienen una forma de explotar en tu cara de la manera más sorprendente. Solo puedo recordar una anécdota donde hace años, comenzamos con una empresa líder de comercio electrónico de piezas de automóviles europea. Estábamos manejando el reabastecimiento de sus piezas con nuestra tecnología de pronóstico, haciendo sugerencias para el reabastecimiento de piezas, sirviendo piezas de automóviles. La semana siguiente, vimos que todos nuestros pronósticos estaban equivocados por un factor de dos. La demanda se había duplicado. Lo que había sucedido era que su competidor número uno había decidido ir a varios países al mismo tiempo, literalmente en el momento en que estábamos comenzando nuestro pronóstico, uno de los competidores había decidido ir a todas las televisiones nacionales y comenzar a transmitir su servicio en línea. Lo interesante es que mi cliente ni siquiera estaba al tanto de eso, y tenían mejores resultados de optimización de motores de búsqueda. Estaban más optimizados en términos de SEO, por lo que básicamente, las personas veían el anuncio de televisión del competidor, pero naturalmente no recordaban el nombre del competidor. Entonces, iban a Google y escribían “piezas de automóviles” hasta que terminaban en el sitio web de mi cliente. Para demostrar lo genial que era Lokad, la primera semana cuando comenzamos, estábamos equivocados por un factor de dos, y estábamos pensando, “¿Qué diablos está pasando?” Tuvimos que revisar todo porque cuando ves que la demanda se duplica, no es que todo se duplique; algunas cosas se multiplican por 10, y muchas cosas quedan intactas.

Eso es lo que tienes que poder reaccionar rápidamente. De eso se trata: miedo y confianza excesiva. Muchas gracias por el tiempo.

Ahora, echaré un vistazo a las preguntas a través del chat.

Pregunta: ¿Puede el software tomar la decisión sobre qué proveedor hacer un pedido adicional en caso de necesitar más para mañana? Por ejemplo, envases de 200 gramos de fresas en oficinas en Australia pueden tener 10 proveedores que entregan los mismos productos al centro de distribución el mismo día.

Absolutamente, y aquí tenemos que diferenciar los dos lados de la gestión de la cadena de suministro y la optimización de la cadena de suministro. Está el lado de la gestión de la cadena de suministro, que consiste literalmente en tener todas las tuberías de extracción de datos en su lugar, incluido el EDI, donde puedes enviar un pedido electrónico a un proveedor sin ninguna intervención humana. Así que tienes un puente electrónico de extremo a extremo. Pero luego, eso significa que necesitas tener, en el lado de la optimización, un software que se ejecute continuamente durante todo el día y, en algún momento, pueda notificar al lado de la gestión, diciendo: “Por favor, ejecuta este pedido”. Y luego, en el lado de la gestión, que será gestionado por TI, se aseguran de que este pedido se ejecute completamente. Es solo una cuestión de pura transaccionalidad; ya no hay inteligencia. Has recibido un pedido que dice “esta cantidad”, y es el lado de la optimización el que se encarga de asegurarse de que cuando generas una cierta cantidad, cumples con todas las restricciones, como la lista exacta de proveedores que son elegibles para servir estos productos, si les queda algún stock y cómo tomar la decisión correcta entre todos los proveedores competidores, etc. Puede haber muchas cosas sucediendo. Absolutamente, sí, pero literalmente tenemos que separar la ejecución mundana, que es la parte transaccional que se encuentra en el lado de la gestión de la cadena de suministro, de tener el ingrediente de optimización en el momento en que decides que necesitas reordenar más.

Pregunta: ¿Sabes que estás compitiendo con los Campeonatos Mundiales de eSports en este momento?

No, no estoy compitiendo con esos campeonatos de eSports en este momento, pero es muy genial. Por cierto, en Lokad, jugamos frecuentemente a Dota 2, así que el equipo directivo también juega. Algunos de nuestros empleados quieren jugar a League of Legends, pero como CEO de la empresa, lo desapruebo firmemente.

Pregunta: He visto que muchas empresas no tienen un ERP o WMS en primer lugar, y que la gestión está trabajando en la optimización de la cadena de suministro.

Bueno, absolutamente. No puedes evitar la optimización de la cadena de suministro desde el primer día; tienes que tomar esas decisiones. La optimización de la cadena de suministro ya existía incluso antes de que se implementara cualquier tipo de software de gestión de la cadena de suministro. Incluso si retrocedemos 60 años atrás cuando no había software, la gente aún tenía que tomar decisiones. Así que la optimización de la cadena de suministro ya era algo; la gente lo hacía con papel y lápiz. Si miras los primeros trabajos de la cadena de suministro, como la Fórmula de Wilson, también conocida como la fórmula EOQ, tiene un siglo de antigüedad. Claramente precede al software. Así que sí, la optimización de la cadena de suministro es algo que sucede desde el primer día, sin importar si tienes software o no en tu organización.

Ahora, de hecho, necesitas tener sistemas de TI adecuados, pero es una mentalidad completamente diferente. La gestión de la cadena de suministro se trata de hacer tareas mundanas muy bien, como la entrada de datos, potencialmente con soporte para códigos de barras y otras cosas. Pero se trata de tareas muy mundanas, simplemente representando los datos. El problema es que la gente quiere algo que haga tanto la gestión de la cadena de suministro como la optimización de la cadena de suministro, y como resultado, terminas con un producto que está demasiado complicado, generalmente lleno de errores y necesitas tener características malas como alertas y excepciones, que deberías evitar. Volveré a eso en una conferencia posterior.

Fundamentalmente, hoy en día, implementar un WMS o un ERP, si aún no tienes uno, es cuestión de semanas. Si ya tienes uno, puede ser cuestión de meses si desenredas esta cosa de tus decisiones.

Pregunta: ¿Cuándo puede la dirección de la empresa darse cuenta de que es hora de pasar de rastrear información a optimizar las decisiones de la cadena de suministro y eventualmente comenzar a enfocarse en la optimización de la cadena de suministro?

Lo primero es darse cuenta en primer lugar de que hay dos problemas y que la misma pieza de software nunca abordará ambos aspectos. Creo que esa es la gran ilusión, y los proveedores de software han sido increíblemente confusos en esta área. Si observas a los mayores proveedores de ERP, su mensaje es sobre la optimización de la cadena de suministro, pero todo lo que realmente entregan y todo lo que su producto realmente hace está en el lado de la gestión de la cadena de suministro, que es mucho menos atractivo porque no hay IA ni inteligencia real. En el mundo del software, se conoce como aplicaciones CRUD (Crear, Leer, Actualizar, Eliminar). Los ERPs son simplemente colecciones gigantescas de pantallas CRUD donde cada pantalla puede crear, leer, actualizar o eliminar líneas de una base de datos relacional, y eso es todo. Un ERP es básicamente, simplificando un poco, una colección de miles de tablas para varias entidades. Para cada entidad que se puede agrupar lógicamente, tienes una o dos pantallas, y eso es todo. Entonces, si vuelvo a tu pregunta sobre la dirección, el problema es que si eres un gerente, lees el folleto del proveedor de ERP y los proveedores de ERP te dicen que esto va a optimizar tu cadena de suministro. La respuesta es: no, absolutamente no. Lo que va a hacer es mejorar la productividad y garantizar una contabilidad precisa de tu cadena de suministro. Esto ya es mucho, ya que puede reducir drásticamente el robo, la merma, los bienes extraviados y mejorar la productividad con códigos de barras para un almacén. Hay mucho valor agregado en estos productos. No estoy desestimando el valor que aporta un ERP o WMS; es enorme, pero no se trata de la optimización de la cadena de suministro. Un WMS, por ejemplo, es por diseño algo que se preocupa por el almacén; no se preocupa por toda la cadena de suministro que incluye clientes y proveedores. Está diseñado para centrarse en ubicaciones específicas, no en toda la cadena.

Pregunta: ¿Cómo puedes hacer la transición suave de Python a Envision o hacer que trabajen juntos?

Los hemos hecho trabajar juntos en algunas situaciones históricamente. Para la audiencia, Envision es un lenguaje de programación específico del dominio diseñado por Lokad que ha sido desarrollado únicamente para la optimización predictiva de cadenas de suministro. En la próxima conferencia, demostraré Envision para que las personas puedan tener una mejor comprensión de lo que estoy hablando, con fragmentos de código reales.

Históricamente, usamos Python y Envision juntos porque, cuando comenzamos, Envision tenía capacidades muy limitadas, por lo que faltaban muchas cosas y estábamos utilizando Python por defecto en muchas situaciones. Con el tiempo, hemos ampliado gradualmente las capacidades de Envision, de modo que hemos ido eliminando gradualmente la necesidad de tener componentes de Python. No solo son componentes de Python; también es una serie de herramientas que deben conectarse, como Airflow.

Por cierto, la sintaxis de Envision ha sido alineada a propósito en muchos aspectos con Python. Tomé la decisión consciente de diseñar la sintaxis de Envision de manera que no fuera antagonista para los programadores de Python, de modo que si estás familiarizado con Python, puedes aprender Envision en una semana. Difiere de formas sutiles y profundas, pero en cuanto a la sintaxis, hay muchos aspectos que son iguales. Python tiene muchos méritos, como la simplicidad y la pureza de diseño. Incluso si digo que Python no cumple con todos los requisitos y crea problemas graves en producción que no se pueden solucionar, no significa que Python no tenga méritos. Eso no es lo que estoy diciendo. Creo que Python tiene muchos méritos. Nuevamente, estamos hablando específicamente de cómo ejecutar cadenas de suministro en producción, que es un problema muy específico.

Pregunta: ¿Cómo harías que un cliente entienda que su ERP no está optimizando nada?

Eso es muy difícil porque, francamente, la peor situación es cuando un cliente potencial viene a mí y dice: “Nuestro ERP, un ERP heredado, no está entregando ningún valor, y ahora queremos pasar al siguiente ERP que ofrece optimización de cadena de suministro”. Esa es una situación terrible para mí porque tengo que decirle al cliente que lo que están buscando no es un producto, sino dos: uno que reemplace su ERP y maneje mejor el lado de la gestión, y otro que haga la optimización.

Cuando piensas en esos ERPs heredados, les tengo mucho respeto, especialmente a esos productos AS/400 con una terminal de línea de comandos en mainframes antiguos de IBM. Desde el lado de la gestión del problema, generalmente están haciendo un trabajo muy justo. Lo que los clientes realmente están buscando podría ser una interfaz web en lugar de una línea de comandos, pero ¿esto hará que sus equipos en el terreno sean más productivos? Cuestiono eso. Las líneas de comandos con terminales de texto pueden ser increíblemente rápidas y productivas sin distracciones.

Por lo tanto, es bastante difícil porque tenemos que desenredar todas las tonterías que nuestros competidores promueven. Además, tenemos que explicar que el ERP no va a optimizar la cadena de suministro y que no existe tal cosa como la IA o el blockchain, solo clases de modelos estadísticos. Desafortunadamente, perdemos a la mayoría de nuestros clientes potenciales en esta etapa. Esa es una de las razones por las que estoy haciendo estas conferencias en primer lugar, porque lleva horas llegar al fondo del asunto y explicar por qué necesitamos ver el problema de la manera en que yo lo veo.

Pregunta: ¿Cuál es tu recomendación para una plataforma que aborde la complejidad de planificar múltiples productos con una distribución de demanda probabilística?

Bueno, Lokad, por supuesto. Pero ten en cuenta que, al ser el CEO de Lokad y el propietario mayoritario de la empresa, tengo un conflicto de intereses en mi opinión. Estoy profundamente convencido de que Lokad es la plataforma que necesitas, pero por favor entiende que también es la empresa que poseo y dirijo. Haré todo lo posible por mantenerme objetivo en ese sentido.

Por cierto, Lokad ha sido literalmente diseñado para lidiar con la distribución de demanda probabilística, y no solo con la distribución de demanda probabilística. También aborda la distribución estocástica del tiempo de entrega, la distribución estocástica de devoluciones y más. Necesitamos analizar todos los futuros posibles con probabilidades, considerando todo tipo de incertidumbres. La demanda es una muy importante, generalmente la más importante, pero no es la única.

Creo que he respondido todas las preguntas. Solo revisando si me he perdido algo… No hay más preguntas. Así que, gracias a todos por ver esta conferencia y nos vemos la próxima semana, el mismo día, a la misma hora. Hasta pronto. Adiós.

Referencias

• Joel on Software: Y sobre asuntos diversos y ocasionalmente relacionados que serán de interés para desarrolladores de software, diseñadores y gerentes, y para aquellos que, ya sea por buena fortuna o mala suerte, trabajan con ellos en alguna capacidad - Por Joel Spolsky, 2004