00:22 Introducción
02:40 ¿Por qué un producto? Porque el capitalismo
08:18 ¿Qué debería hacer el producto?
10:05 Deseconomías de escala en el software
12:50 Comprémos un producto SCO de estantería
21:58 SCM vs SCO
25:58 Interludio
28:21 El SCO no es el producto de software promedio
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 IT
01:03:19 En conclusión, dos desafíos a superar
01:07:04 Próxima conferencia y preguntas del público
Descripción
El objetivo de una Supply Chain Quantitativa es ya sea entregar o mejorar una aplicación de software que robotiza un conjunto de decisiones rutinarias (por ejemplo, replenishments, actualizaciones de precios). La aplicación se concibe como un producto a ser ingenierado. La supply chain theory está ahí para ayudarnos a entregar una aplicación que dirija a la empresa hacia el desempeño de supply chain, mientras es compatible con todas las restricciones que implica la producción.
Transcripción completa
Hola a todos, muchas gracias por acompañarnos en esta serie de conferencias de supply chain. Soy Joannes Vermorel y estaré presentando “Product-oriented Delivery for Supply Chain Optimization.”
Primero, cuando hablo de un producto, me refiero a un producto de software. Para aquellos de ustedes que han tenido el privilegio de investigar lo que ocurre bajo el capó de un piece of software, podría ser toda una experiencia.
Para aquellos familiarizados con la obra de H.P. Lovecraft, existen algunas similitudes inquietantes. Lovecraft produjo 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, sí que puede. Es solo que lo único que preserva a la humanidad es la ignorancia. La ignorancia no es un problema; es justamente lo que nos protege de un universo demasiado aterrador para que nuestras mentes lo soporten. Esta idea se ha reciclado en muchos juegos modernos, especialmente en los juegos de rol, donde además de los puntos tradicionales 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 enterprise software es poder crearlo sin perder la cordura, lo cual es uno de los requisitos para añadir valor a la empresa. Así que, continuemos.
¿Por qué un producto, y en particular, un producto de software? Echemos un vistazo de cerca a cómo operan tradicionalmente las supply chains. Tradicionalmente, había muchas personas en el terreno moviendo cosas, barajando 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 gradualmente ha ocurrido en las últimas décadas es que el número de personas con empleos de cuello azul ha estado disminuyendo de manera constante. Hoy en día, en lo que respecta a la producción, todo está altamente automatizado. Aún quedan algunas industrias, como la textil, donde es difícil automatizar todo, razón por la cual esas industrias se han trasladado a lugares donde la mano de obra es más barata. La realidad es que los requisitos de mano de obra pura se han reducido tremendamente.
Acabas con una situación bastante extraña en la que, si se anticipa la llegada de vehículos autónomos, muchas empresas tendrán más trabajadores de oficina manejando spreadsheets para operar la supply chain, que personas con empleos de cuello azul en el terreno para realizar las labores manuales. A esto me refiero cuando hablo de trabajo administrativo.
Otro aspecto peculiar es que las supply chains han sido digitalizadas en muchas empresas desde hace al menos dos décadas. No es como si fuéramos a introducir software en las supply chains; las supply chains ya son gestionadas y operadas mediante software. Pero cuando observamos el papel de los humanos en estos sistemas de software, se utilizan literalmente como co-procesadores humanos en una supply chain cualquiera. Hay tipos específicos de operaciones que la CPU regular, el procesador de la máquina, no puede realizar, y por ello se delega toda la tarea a un humano. En conjunto con numerical recipes, tan simples como el ABC analysis, inventario min-max y recetas similares, los humanos terminan pasando sus días apagando incendios. Siempre están lidiando con excepciones y condiciones que no encajan en el marco estándar.
Desde la perspectiva de costos, todo esto es gasto operativo (OpEx). Necesitas pagar un ejército de empleados administrativos cada día 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 warehouse a una tienda, y muchas otras decisiones rutinarias. Los humanos están tomando estas decisiones y apagando incendios para hacer frente a las deficiencias de las decisiones automáticas generadas de forma ingenua por el sistema.
Mi propuesta para ustedes hoy es que queremos pasar de gasto operativo (OpEx) a gasto de capital (CapEx). Ese es el punto de esta entrega orientada al producto. Queremos construir un activo, ¿y por qué? Porque es capitalista. Si observas las 100 compañías más rentables del mundo en la actualidad, la mitad, en términos de ganancias, son compañías de software. Representan la esencia de las compañías ultra-capitalistas, donde tienes una inversión inicial y luego terminas con un dispositivo o artefacto que genera valor añadido con una inversión marginal mínima.
Volviendo al tema de mi conferencia anterior, necesitamos robotización para devolver el control a la direcció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 ingenuas de inventario como el min-max. En cambio, deberían estar allí para añadir valor, mejorar las numerical recipes y actuar como estrategas. Existía un lema antiguo de IBM que decía, “Las máquinas deben trabajar; las personas deben pensar.” Ese es el tipo de pensamiento que se plasma en esta presentación. Queremos convertir la supply chain en un activo capitalista, y para ello, necesitamos transformar la supply chain 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 o sin límites, sino las decisiones mundanas y rutinarias, como qué producir, cuántas unidades comprar de 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 supply chain. Sin embargo, si se analizan las tareas, incluso las supply chains más complicadas solo requieren unas pocas docenas de tipos de decisiones cada día. Esto no es abrumador y es bastante razonable en términos de la cantidad pura de funciones. Curiosamente, estas decisiones son en gran medida excluyentes, por lo que existen límites a lo que se puede hacer utilizando un enfoque de divide y vencerás. Una vez que has decidido comprar 100 unidades de un proveedor, no puede haber otro subsistema decidiendo comprar 200 unidades en su lugar. En algún momento, tienes que decidir cuántas unidades comprar y mover de una ubicación a otra. Estas decisiones son discretas, limitadas en alcance y en gran medida excluyentes. Lo que queremos es una pieza de software que genere decisiones de orden de manera completamente automatizada cada día.
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 ocurre en el software, donde añadir un 25% más de funciones puede duplicar el costo. Este concepto explica por qué las pequeñas startups pueden rivalizar con las grandes empresas, ya que se centran en una fracción más pequeña de funciones, haciendo que el costo para llevar su producto al mercado sea 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 adoptar otro enfoque para nuestro producto de optimización de la supply chain. Si elegimos comprar el producto a un proveedor, debemos considerar las funciones que el proveedor de software tendrá que entregar para atender el mercado.
Entonces, consideremos comprar un producto de optimización de la supply chain de estantería. En estas diapositivas, ofrezco una revisión de apenas una pequeña fracción de todas las cosas que debemos abordar. Tengo experiencia de primera mano con esto, ya que cuando inicié Lokad en 2008, comencé con un pequeño producto de software orientado más hacia el forecast que hacia la optimización de la supply chain. Al empezar a trabajar con clientes, me di cuenta de que había tantas funciones y capacidades que no tenía, y al pasar a otros clientes, encontré aún más capacidades faltantes. Parecía ser un proceso interminable de descubrir nuevos requerimientos.
Echemos un vistazo a las características centrales. Primero, tenemos empresas que son B2C o B2B, las cuales exhiben patrones completamente diferentes en la gestión de la supply chain. Por ejemplo, las empresas B2B típicamente tienen menos clientes, pero esos clientes ordenan cantidades mucho mayores. Esto crea diferentes tipos de riesgos, como el riesgo de perder un solo cliente que representa una porción significativa de la facturación de la empresa. Luego existen modelos de negocio más complejos como B2B2C o B2B2B.
Considera los diversos tipos de sitios que deben ser cubiertos, como tiendas, almacenes y fábricas. 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 los sitios de producción, como granjas u operaciones mineras, presentan sus propios problemas específicos e incertidumbres en el rendimiento de la producción.
Las redes de supply chain 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 supply chain aumenta significativamente a medida que crece el número de escalones. La topología de la red es otro aspecto importante a considerar. Una topología en forma de árbol es la ruta clásica de la supply chain hacia adelante, donde unos pocos 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 dirigidos acíclicos (DAG), donde una tienda puede ser servida por múltiples almacenes.
Entonces, básicamente, no es solo un árbol en términos de grafos, puede reconectarse, aunque sigue siendo solo hacia adelante. Pero lo mismo puede ocurrir con un Directed Acyclic Graph (DAG) cuando tienes múltiples proveedores. Incluso puedes tener bucles en tu grafo de supply chain que ocurren siempre que se involucren reparaciones. Por ejemplo, en la industria minera o en la industria de la aviation, hay montones de bucles de reparación con equipos reparables.
Ahora, el inventario en sí no tiene una única naturaleza; varía mucho. No puedes simplemente decir, “Oh, tengo la idea de que tengo SKUs y eso es todo.” No, no del todo, 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 claras, que son las más prevalentes. Pero también puedes tener mucho inventario que ocurre con mucha frecuencia, por ejemplo, en farmacéutica o en el negocio de alimentos, donde el lote viene con fechas de caducidad específicas. Luego, incluso puedes tener un inventario completamente serializado, donde cada unidad tiene su propio número de serie. En términos de optimización de la supply chain, eso cambia completamente el juego, por lo que es un problema completamente diferente cuando se analiza cada uno de esos aspectos.
Luego, obviamente, tienes todos los problemas de los marketplaces. En Lokad, tenemos clientes en literalmente cada situación posible. 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 por ejemplo, piensa por un momento en lo que es una orden. Tienes la orden spot, en la que básicamente compras algo directamente, y es tuyo. Pero también puedes tener una orden que diga, “La estoy comprando, pero no quiero que esto se entregue de inmediato; quiero que se entregue dentro de un mes.” Obviamente, desde la perspectiva de la optimización de la supply chain, 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 forecast eso, por lo que es algo completamente distinto.
Y luego tienes una orden configurada, y eso 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á en tu computadora y cuál será tu teclado, entre otras cosas. Así que puedes tener un configurador masivo, y eso cambia el panorama nuevamente. Esto también sucede en cosas como bicicletas o automóviles y cambia completamente el panorama cuando tienes este tipo de cosas porque te da opciones y formas de abordar el problema de la optimización de la supply chain 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 escalas de precios, por ejemplo, si compras diez unidades, obtienes un descuento. O puedes tener programas de lealtad donde algunos clientes con tarjeta de lealtad pueden obtener un descuento, pero solo en ciertos tipos de productos o dependiendo de ciertas condiciones. Y luego, incluso en B2B, hay cosas muy frecuentes que se negocian, así que es literalmente una transacción en la que se venderán muchas cosas, pero tienes un precio de catálogo regular. Sin embargo, un proveedor puede dar un reembolso a un cliente porque son importantes, y así es como se hace. En resumen, apenas llevo minutos hablando y solo he cubierto lo esencial. Ni siquiera he empezado a tocar lo imprescindible. Así que haz una pausa por un momento e intenta pensar en cómo será un producto de software empresarial listo para usar que se supone que debe entregar optimización de supply chain. La cantidad de funciones a cubrir es literalmente una locura, y cuando intentas pensar en cómo unir todas esas cosas en un monolito, literalmente pierdes la cabeza. Volvemos a esa idea de que no es que el universo no pueda ser conocido, es simplemente que si estás expuesto a la verdad desnuda del universo, pierdes la cordura.
Entonces, tenemos un problema mayor, y aquí debemos diferenciar entre la gestión de supply chain y la optimización de supply chain. Esa es una distinción que ya introduje en una de mis conferencias anteriores. Hay 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, de respaldar flujos de trabajo y, sobre todo, de procesos de entrada de datos. Si quieres representar todas las cosas que acabo de describir, es mucho terreno que cubrir, pero es posible. Un ERP “obeso” puede hacer eso. Sí, terminarás con 10,000 tablas, va a 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 limitará a llevar un registro de esas cosas. Así tendrás toneladas de entidades – MOQs, check; escalas de precios, check; tiendas, check; almacenes, check – 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 al sistema, y eso es todo.
Es posible porque, aquí, podemos hacer trampa un poco con respecto a la regla de “una cuarta parte más de funciones duplica el costo”. Hay algo que realmente no mencioné al respecto: funciona si mantienes tus funciones completamente segregadas. Mientras las funciones no interactúen entre sí, está bien; no estás sujeto a esta maldición de las deseconomías de escala. Desde la perspectiva de la entrada de datos, no hay problema. No necesitas tener la interfaz de usuario que te permita manejar los MOQs conectados con lo que sea que te permita agregar una tienda adicional a la red. Esas dos cosas pueden estar completamente segregadas.
Sin embargo, cuando se trata de optimización de supply chain, 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 supply chain es solo un sistema donde todo influye en todo. Así que, desde la perspectiva de la optimización de supply chain, literalmente tienes el problema de que todas esas cosas deben conectarse si deseas entregar optimización, y ahí es donde todo se desmorona.
En el lado de la gestión, potencialmente puedes terminar con un producto. Sin embargo, para la optimización de supply chain, la respuesta es que no puedes. Quiero decir, puedes pretender hacerlo, pero literalmente, no puedes. Incluso en Lokad, que comenzó no como una empresa predictiva de supply chain que se especializa en optimización predictiva de supply chain, sino más bien como forecast as a service. Si retrocedes al blog de Lokad en 2008, inicialmente comencé con el forecast de series de tiempo, lo cual fue severamente equivocado. No obstante, así es como empecé. Incluso para el forecast de series de tiempo, que es un subconjunto diminuto de todo el problema, es ingobernable. Esa es mi conclusión después de estar en este negocio por más de 12 años.
Si tenemos que volver al mundo específico de producir software, es algo muy único. A menos que hayas sido formado como ingeniero de software y estés familiarizado con la forma en que grandes y exitosas empresas de software producen software, lo más probable es que sepas muy poco al respecto. Resulta que es un mundo muy específico con muchos aspectos profundamente contraintuitivos. Las empresas tradicionales, especialmente aquellas con una mentalidad clásica de ingeniería mecánica o de marketing, luchan inmensamente por comprender cómo funciona el software.
Abordaremos estos aspectos con mayor 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. Además, es cofundador de Stack Overflow y Trello. En 2004, cuando solo era estudiante, leí su libro y su blog. El libro se titula “Joel on Software”, y te da de manera humorística una idea de cómo se ve dirigir un negocio de software exitoso. Es muy diferente de lo que la mayoría de las personas fuera de esta industria espera. Agregaré los detalles de este libro en la descripción del video.
Pero tengamos en cuenta que la optimización de supply chain no es un producto de software promedio. Usualmente, cuando tratas con un producto de software promedio – quiero decir, sí, tienes algunos comportamientos adversariales, dependiendo del tipo de producto de software. Si estás tratando con una red social, puedes tener a muchas personas publicando contenido de odio, lo cual es otro juego completamente diferente. Sin embargo, al tratar con software empresarial clásico, como Microsoft Word o Excel, es un producto en el que quieres tener el diseño correcto, pero no hay emergencia alguna. 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 tienes que mirar varias décadas hacia el futuro. No hay razón para apresurarse en términos de desarrollo. Sin embargo, la optimización de supply chain 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 puede 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 enfrentarte a la paralización de flotas debido a incidentes trágicos, medidas políticas como aranceles que alteren 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 ser capaz de reaccionar literalmente en horas.
Tienes tu producto de software, pero necesitas generar cambio, y quieres generar un cambio programático. Recuerda, si tienes la mentalidad de entregar un activo de software, cuentas con un equipo pequeño que maneja el software que, a su vez, impulsa tu supply chain. No tienes un ejército de empleados administrativos apagando incendios todo el día. Incluso si tienes un ejército de empleados administrativos, 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, mientras más gente tengas para gestionar, más tiempo se tarda en lograr algo.
Hace apenas unos días, un carguero perdió más de 1,800 contenedores debido a malas condiciones meteorológicas. Estas cosas simplemente suceden, y no puedes esperar eliminarlas. Supply chain no es como la manufactura, donde puedes tener un sitio de producción con todo estrictamente controlado. Por definición, las supply chains ocurren en un mundo en general, donde la mayoría de las veces no tienes control sobre los elementos. Hay tantas fuerzas fuera de tu control que necesitas ser capaz de hacer frente a eventos sorprendentes. Ya sabes que ocurrirán sorpresas, así que debes estar preparado. Estar preparado no significa tener todo cuidadosamente mapeado; se trata de tener un sistema en el que 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 supply chain? Primero, necesitamos un almacenamiento de datos versátil para representar todos los diversos tipos de fuentes de datos. Hay tantas cosas que queremos representar, que queremos algo muy versátil en ese sentido, con mucha estructura y variedad.
Segundo, quieres lógica programable. Vuelvo a esta idea: si no tienes lógica programable, ¿cómo haces frente a todos estos problemas? ¿Cómo unes todas estas cosas? No puedes comprar un producto listo para usar que tenga todo preprogramado para ti; eso no funciona.
Luego, necesitas interfaces de usuario versátiles porque la forma en que quieres abordar tus problemas variará enormemente de una situación a otra. Los KPIs 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 colaborativas, porque supply chain es trabajo en equipo por definición. Hay muchas personas involucradas, y es distribuido, por lo que las capacidades colaborativas deben estar en el núcleo.
Por último, y quizás de manera más polémica, 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 necesita mucho esfuerzo y dedicación para convertirse en un ingeniero de software talentoso, de modo que es un desafío ser un Supply Chain Scientist simultáneamente.
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 escala o contratar de manera confiable a más de ellos cada año si eres una empresa grande? Según mi experiencia dirigiendo Lokad durante una década, simplemente no funciona.
Quieres 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 supply chain porque debes ser capaz de hacer frente en cuestión de horas para aplicar las correcciones de programación a tu sistema sin tener que abrir un ticket y pasarlo al departamento de IT. Si tienes que hacer eso, entonces se tarda semanas en resolver los problemas, no horas. Entonces, ¿qué tipo de software puede realmente resolver el problema?
Bueno, Excel puede. No es bonito, y puede que no parezca la cúspide del software moderno, pero cumple con la función. Cumple con todos los requisitos.
¿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 refinado, pero en términos de versatilidad, puede hacer mucho.
En términos de capacidades colaborativas, es algo rudimentario. Tienes algunas versiones de Excel que están en línea, que son marginalmente mejores, pero fundamentalmente, puedes compartir tus hojas de cálculo. El problema con la falta de funciones colaborativas no es que sea una aplicación de escritorio. El problema es la mentalidad que conlleva el uso de hojas de cálculo, que no es adecuada para un trabajo colaborativo intenso. Usualmente, si tienes un colega que creó una hoja muy compleja, es más fácil recrear la hoja que intentar descifrar lo que hizo. Así que, el problema con la falta de funciones colaborativas es la mentalidad que acompaña a las hojas de cálculo, que inherentemente tiene fuertes límites para la colaboración.
Sin embargo, Excel es completamente accesible para los no desarrolladores, e incluso cuenta con Visual Basic for Applications para tareas más complicadas. En términos de ingredientes, Excel cumple con todos los requisitos, lo que, creo, explica en gran medida el éxito que tiene operativamente en la mayoría de las supply chain.
En mi experiencia, la mayoría de las supply chain del mundo, desde las empresas más pequeñas hasta las más grandes y desde aquellas que nunca han invertido ni un centavo en software empresarial hasta aquellas que han invertido millones de dólares en software empresarial complicado para la optimización de supply chain, son impulsadas por Excel. Hay muy pocas excepciones. A veces, la gente utiliza Excel para revisar configuraciones de mínimo-máximo en otro software, pero el mantenimiento de estas configuraciones se delega a quienes trabajan con Excel.
Excel está impulsando el mundo del supply chain hoy en día, y creo que no es una casualidad. En su esencia, las hojas de cálculo abordan fundamentalmente muchos de los problemas adecuados. Muchas otras opciones se presentan como superiores pero fallan por defecto si no sabes programar. Si no sabes programar, eso significa que cuando enfrentas un problema mayor o una emergencia, no tienes suerte. La gente recurrirá 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 los no desarrolladores. Si solo es un equipo de IT el que puede obtener resultados, inicialmente la gente puede abrir tickets y esperar pacientemente, pero en tres meses, es probable que todos recurran de nuevo al uso de hojas de cálculo de Excel porque es más rápido. Excel no es el fin del juego, pero sea cual sea el reemplazo superior que presentemos, tendrá que cumplir con los requisitos.
¿Cómo podemos hacer algo mejor? 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 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 bug en tu hoja de cálculo, depurarlo y localizar la fuente del problema se convierte en una pesadilla. La lógica se duplica interminablemente, resultando en miles de copias de la misma lógica, lo que dificulta identificar y corregir los errores.
La interfaz de usuario no es ideal, ya que no es completamente basada en la web y los datos siempre están entrelazados con la interfaz. Existen capacidades colaborativas, pero son desordenadas. La colaboración debería ocurrir a nivel de lógica programable. Muchos proveedores de optimización de supply chain ofrecen colaboración sobre los resultados, como ajustar los forecast manualmente y permitir la participación de varias personas. Sin embargo, este es el enfoque equivocado. Las colaboraciones necesitan suceder, pero tienen que ocurrir a nivel lógico, a nivel de lógica programable. Excel es muy accesible para quienes no son desarrolladores, pero cuando quieres hacer algo un poco más complicado, se vuelve un desafío. En la gestión de supply chain, queremos abordar todos los futuros posibles, lo que significa trabajar con forecast probabilístico, variables aleatorias y afrontar la incertidumbre. Aunque 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 a lo largo del tiempo. Con las hojas de cálculo, es difícil lograr esto, y resulta complicado crear algo realmente exacto, al menos en el sentido de un producto de software.
Las palabras de moda del día son AI y Python, con todas las tendencias y el bombo publicitario que rodea a la ciencia de datos. Sin embargo, para la gestión de supply chain, creo que Python es inferior a Excel.
No me malinterpreten; me encanta 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 supply chain. 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 precisas personas que sean a la vez expertas en supply chain e ingenieras 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 se trata solo del lenguaje, sino también de todo el ecosistema de paquetes que te interesa, como NumPy, Pandas, TensorFlow y SciPy, todos ellos dependencias de terceros o bibliotecas de software. La administració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 hacen difícil mejorarlo.
El rendimiento también es pobre, en su mayoría por diseño. El rendimiento computacional se refiere a la calidad del trabajo realizado por Python para explotar la potencia de cómputo cruda disponible en tu computadora. Sorprendentemente, Microsoft Excel hace un trabajo mucho mejor en este aspecto. Excel está altamente optimizado, aprovechando sistemas multi-CPU, multi-core y ejecutando lógica compilada de forma nativa. Microsoft ha invertido mucho en hacer Excel extremadamente rápido.
En contraste, Python tiene problemas inherentes que a menudo hacen que su rendimiento sea 100 veces más lento de lo que tu máquina podría ofrecer teóricamente. Aunque a algunos les pueda parecer aceptable, dada la potencia de las computadoras modernas, no es lo ideal para empresas con volúmenes de transacciones superiores a $50 millones. Quieres algo que ofrezca un buen rendimiento desde el primer momento.
La idea de usar una biblioteca de terceros como NumPy para abordar la falta de rendimiento de Python solo añade complejidad. Puede que estés resolviendo el problema de rendimiento, pero estarás creando otro al introducir la complejidad añadida de NumPy, con la que tendrás que lidiar y mantener a lo largo del tiempo. Esto también eleva el nivel en el ámbito de la ingeniería de software.
Al intentar implementar soluciones en Python para una gestión real de supply chain, surgen varios problemas, como excepciones por referencias nulas, excepciones por falta de memoria y tiempos de cálculo prolongados. Puede que te encuentres esperando 20 minutos para que se complete un cálculo, sin estar seguro de si terminará o si deberías simplemente matar el proceso y reiniciarlo. Simplemente no lo sé, por lo que quieres algo en lo que tengas una muy, muy buena idea de cuánto tiempo tomará completarse. Por cierto, si vuelvo a Excel, hoy en día, cuando hay una operación que tarda un poco en completarse, Excel te dará un indicador, una barra de progreso bastante confiable sobre el tiempo estimado. Así que, de nuevo, buscas, y eso es parte de lo que llamo la preparación para producción. Quieres tener algo que, de nuevo, dado que el software que estás produciendo probablemente se ejecutará sin supervisión, durante la noche o durante el lote nocturno, por ejemplo, no requiera que un data scientist esté pendiente de todo.
Y, nuevamente, si tienes el problema con los data scientists, entonces necesitas una tercera competencia: experto en supply chain, experto en ingeniería de software y ahora un experto en data scientist. Es posible tener las tres cualidades en una sola persona, pero buena suerte contratando a más de una persona al año, incluso si eres una gran empresa que posee todas esas habilidades. Es simplemente sumamente raro.
Así que 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 incorporas 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 misma máquina en la que se ejecuta. Sé que hay muchas maneras de mitigar los problemas; puedes utilizar sandbox, puedes restringir, puedes tener derechos limitados, y hay múltiples formas de reducir los problemas. No obstante, siempre que tienes algo como un lenguaje de programación genérico de propósito general, tu superficie de ataque, que es un término técnico, es absolutamente gigantesca.
Básicamente, siempre que integras código de esa manera, te expones enormemente en términos de problemas de seguridad. Y recuerda, la forma en que se hace típicamente en un negocio de ingeniería de software es que el código es revisado por pares. Así, revisas el código, tienes un proceso de revisión, alguien produce el código y un colega lo revisa para asegurarse de que no haya irregularidades. Pero si volvemos al hecho de que el software debe ser resistente, tienes que ser capaz de responder en cuestión de horas. Desde una perspectiva de optimización de supply chain, no podrás implementar un proceso de revisión de código. Simplemente no es compatible con los retrasos y emergencias que enfrentarás.
Entonces, necesitas algo que te ofrezca defensa en profundidad por diseño. Luego, deseas algo con rendimiento transparente, donde sí, las cosas pueden tomar tiempo, pero necesitas tener el control. Debes saber de antemano cuánto tiempo tomará. Si no cuentas con eso, te expones a un montón 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. Por lo tanto, necesitas algo que se encargue de ello.
Y lo mismo ocurre con las actualizaciones transparentes. Esa es la belleza de Excel. No tienes que preocuparte por su mantenimiento. Microsoft firmó un pacto en sangre hace décadas, que decía: si has creado una hoja de cálculo en Excel, cualquiera que sea la próxima versión de Excel que llegue al mercado, podrá soportar tus hojas de cálculo. Y lo más increíble es que, si observas Excel hoy en día, soporta muchos formatos de competidores que ni siquiera existen ya. Todavía puedes leer hojas de cálculo producidas con Lotus Notes y cosas por el estilo. Así, la propuesta de valor de Microsoft en cuanto a actualizaciones transparentes es que la lógica que has creado funcionará para siempre, y sí, seguirán mejorando Excel durante décadas, pero ¿sabes qué? Está solucionado. Eso no es algo que veas en la transición de Python 2 a Python 3; fue una pesadilla y tomó una década. Entonces, Python es genial para muchas cosas, pero imagina que esas actualizaciones sucedan en los peores momentos, cuando ocurra la peor pandemia, la peor tarifa, la peor emergencia, y necesites que todo esté operativo y listo. 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 supply chain.
Entonces, ahora tenemos que pensar, ¿y si consideráramos algo que pudiera ser diseñado pensando en supply chain? Ese será el tema de la próxima conferencia.
Ahora, además, supply chain no es la división de TI. Cuando hablo de una entrega orientada a productos, nuevamente, no es que el software sea solo un medio, sino no es un fin en sí mismo. No estarás vendiendo tu software por licencias o por una tarifa, como, digamos, lo hace Microsoft. En esta visión que estoy esbozando ante ustedes en esta conferencia, TI es responsable de las prácticas esenciales, las prácticas centrales de TI, como lo que se debe o no se debe hacer en términos de seguridad, respaldos, infraestructura central, tu red, cómo gestionar y sincronizar todo a nivel de datos empresariales, y de ofrecer toda la orientación y coaching.
Pero la idea es que supply chain debe ser la dueña de las decisiones de supply chain. Tienen que ser dueños de todo el aparato que genera esas decisiones de supply chain, ese es su núcleo de propiedad. En la conferencia anterior, dije lo que define al Supply Chain Scientist: el Supply Chain Scientist 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 plasmadas por uno o varios Supply Chain Scientists, y esos Supply Chain Scientists poseen colectivamente esas decisiones numéricas. Asumen la responsabilidad en ello, y la responsabilidad de supply chain es asegurarse de que todas las decisiones en la empresa sean consistentes. Si hay una promoción en marcha o un gran empuje de marketing, las cosas deben producirse a tiempo para estar listas para ser atendidas. No quieres terminar en una situación catastrófica en la que estés impulsando algo cuando ya te encuentras en una situación de faltante de stock, en la que gastas dinero en un empuje de marketing para algo que ni siquiera puedes vender porque no cuentas con el stock o la capacidad para fabricarlo o para proporcionar el servicio a tiempo, etc.
Así que, tenemos dos divisiones con 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 en la que se pasan tickets. Así no funciona. El departamento de TI está a cargo de la infraestructura central. Es ese tipo de cosa que simplemente funciona a la perfección todo el tiempo. Ni siquiera le prestas atención, tal como cuando el Wi-Fi está operando. No le prestas atención al Wi-Fi; solo lo notas cuando no funciona. Un buen departamento de TI provee toda la infraestructura de manera que ni siquiera te des cuenta de ellos. Ni siquiera percibes su existencia porque simplemente todo funciona, tal como tus correos electrónicos operan sin inconvenientes, etc. De eso se trata un buen núcleo de TI. Y además, TI es el tipo de personas que se acercan a ti y te ayudan a establecer todas esas prácticas que te echan una mano. La lógica programable es algo complicada, así que, ¿de dónde conseguirás el coaching para mejorar un poco en programación? Pues la respuesta es que debería ser TI. Ellos no deberían venir a decir, “Vamos a programarlo por ti,” sino, “Vamos a entrenarte para que puedas implementarlo tú mismo. Te ayudaremos con algunos conceptos, tal vez con aspectos que son un poco más técnicos de lo que deberían ser.” A veces, tienes complejidad accidental, y TI está ahí para apoyarte. Pero, fundamentalmente, no están ahí para hacer el trabajo por ti. Deben 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 a un riesgo sistémico en términos de TI.
Como prueba decisiva, si la interacción entre TI y supply chain se realiza a través de documentos en los que se enumeran especificaciones o requisitos, esa no es la manera adecuada de tener una buena relación entre esas dos divisiones. Cuando hablo de una buena relación, me refiero a algo que realmente aporte valor a la empresa.
En conclusión, tenemos dos desafíos aquí desde el lado tradicional de la gestión de supply chain, que quizás se haya dedicado a la programación solo al límite con hojas de cálculo de Excel, sin percatarse inicialmente de que ya era una forma de programación. Tienes que superar tus miedos. Debes pensar que el mundo del mañana, tu división, estará a cargo de entregar un producto que funcione como un producto de software, y ese es un cambio enorme. Sí, pero es algo con lo que puedes lidiar. ¿Por qué? Porque si cuentas con las herramientas adecuadas, sí, hay programación involucrada, pero no es fundamentalmente, radicalmente más difícil que Excel. Nuevamente, el desafío no reside en la tecnicidad de la herramienta; es literalmente en la complejidad de la supply chain misma. El problema es difícil no porque tu herramienta sea complicada de manejar, sino porque tienes una supply chain complicada desde el principio.
Para la parte de la audiencia que quizás esté más en el lado de data scientist o de IT, lo que deben superar es la sobreconfianza. He visto, una y otra vez, data scientists, y me incluyo en esta categoría, que estaban sobreconfiados en su capacidad para llevar un prototipo a producción. Esto es difícil, y las supply chains tienen una manera de volverse en tu contra de la forma más sorprendente. Solo puedo recordar una anécdota en la que, hace años, comenzamos con una importante empresa europea de autopartes ecommerce. Estábamos manejando sus reposiciones de piezas con nuestra tecnología de forecast, haciendo sugerencias para las reposiciones de piezas, sirviendo autopartes. La semana siguiente, vimos que todos nuestros forecast estaban equivocados por un factor de dos. La demanda se había duplicado. Lo que había ocurrido fue que su competidor número uno había decidido expandirse a múltiples países al mismo tiempo; literalmente, en el momento en que comenzábamos nuestro forecast, uno de los competidores había decidido salir en 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 en optimización para motores de búsqueda. Estaban más optimizados en términos de SEO, así que básicamente, la gente veía el anuncio televisivo del competidor, pero no recordaban de forma natural el nombre del competidor. Entonces, fueron a Google y teclearon “car parts” hasta que terminaron en el sitio web de mi cliente. Para demostrar lo grandioso que era Lokad, la primera semana en la que comenzamos, estábamos equivocados por un factor de dos, y pensamos, “¿Qué demonios está pasando?” Tuvimos que revisar todo porque, cuando ves que la demanda se duplica, no es que todo se duplique; algunas cosas están haciendo 10x, y muchas cosas permanecen intactas.
Así que esa es la clase de situación, y necesitas ser capaz de reaccionar rápidamente. De eso se trata: miedo y sobreconfianza. Muchas gracias por su tiempo.
Ahora, echaré un vistazo a las preguntas a través del chat.
Pregunta: ¿Puede el software tomar la decisión sobre con qué proveedor realizar un pedido extra en caso de necesitar más para mañana? Por ejemplo, bandejas de 200 gramos de fresas en oficinas en Australia pueden tener 10 proveedores entregando 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 supply chain y la optimización de la supply chain. Por un lado, está la parte de la gestión de la supply chain, que consiste literalmente en tener todos los data pipelines en su lugar, incluyendo EDI, donde puedes enviar un pedido electrónico a un proveedor sin intervención humana. Así tienes un puente electrónico de extremo a extremo. Pero entonces, eso significa que necesitas tener, en el lado de la optimización, una pieza de software que funcione de manera continua a lo largo del día y, en algún momento, pueda notificar a la parte de gestión, diciendo, “Por favor, ejecuta este pedido.” Y luego, en la parte de gestión, que será administrada por IT, ellos se aseguran de que este pedido se ejecute completamente. Es simplemente 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 es responsable de asegurarse de que, cuando generes una cierta cantidad, cumplas con todas las restricciones, como la lista exacta de proveedores que son elegibles para servir estos productos, si tienen stock disponible y cómo tomar la decisión correcta entre todos los proveedores competidores, etc. Pueden estar ocurriendo muchas cosas. Absolutamente, sí, pero literalmente tenemos que separar la ejecución mundana, que es la parte transaccional que recae en la gestión de la supply chain, 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 eSports World Championships en este momento?
No, no estoy compitiendo con esos campeonatos de eSports en este momento, pero es muy cool. Por cierto, en Lokad, con frecuencia jugamos Dota 2, así que el equipo de gestión también participa. Algunos de nuestros empleados quieren jugar League of Legends, pero como CEO de la compañía, desapruebo firmemente.
Pregunta: He visto que muchas empresas no cuentan con un ERP o WMS en primer lugar, y que la dirección está trabajando en la optimización de la supply chain.
Bueno, absolutamente. No puedes evitar la optimización de la supply chain desde el primer día; tienes que tomar esas decisiones. La optimización de la supply chain estaba presente incluso antes de que existiera cualquier tipo de software de gestión de la supply chain. Incluso si retrocedemos 60 años, cuando no había software, las personas aún tenían que tomar decisiones. Así que la optimización de la supply chain ya existía; la gente lo hacía con papel y pluma. Si miras los primeros trabajos sobre supply chain, 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 supply chain es algo que ocurre desde el primer día, sin importar si tienes software o no en tu organización.
Ahora, en efecto, necesitas tener sistemas IT adecuados, pero es una mentalidad completamente diferente. La gestión de la supply chain se trata de realizar 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 de representar los datos. El problema es que la gente quiere algo que haga tanto la gestión de la supply chain como la optimización de la supply chain, y como resultado, terminas con un producto que es sobrecomplicado, usualmente con muchos errores, y que incluye características deficientes como alertas y excepciones, las cuales deberías evitar. Volveré a ese tema 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 logras separar esto de tus decisiones.
Pregunta: ¿Cuándo puede la dirección de la empresa darse cuenta de que es hora de pasar del seguimiento de la información a optimizar decisiones de supply chain y, eventualmente, comenzar a enfocarse en la optimización de la supply chain?
Lo primero es que tienes que darte cuenta, desde el inicio, de que hay dos problemas, y que la misma pieza de software nunca abordará ambos enfoques. Creo que esa es la gran ilusión, y los proveedores de software han sido increíblemente confusos en este ámbito. Si miras a los mayores proveedores de ERP, su mensaje habla de la optimización de la supply chain, pero todo lo que realmente entregan y todas las funciones que su producto realiza están en el lado de la gestión de la supply chain, lo cual es mucho menos atractivo porque no hay IA ni verdadera inteligencia. En el mundo del software, se conoce como aplicaciones CRUD (Crear, Leer, Actualizar, Eliminar). Los ERPs son simplemente colecciones gigantes de pantallas CRUD en las que 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 diversas entidades. Para cada entidad que se pueda agrupar lógicamente, tienes una o dos pantallas, y eso es todo. Así que, si vuelvo a tu pregunta sobre la dirección, el problema es que, si eres gerente, lees el folleto del proveedor de ERP, y los proveedores te dicen que esto va a optimizar tu supply chain. La respuesta es: no, absolutamente no. Lo que hará es mejorar la productividad y asegurar una contabilidad precisa de tu supply chain. Esto ya es mucho, ya que puede reducir drásticamente el robo, la merma, los bienes extraviados y mejorar la productividad mediante el uso de códigos de barras en un almacén. Hay mucho valor añadido en estos productos. No estoy descartando el valor que aporta un ERP o WMS; es enorme, pero no se trata de optimizar la supply chain. Un WMS, por ejemplo, es por diseño algo que se preocupa por el almacén; no se ocupa de toda la supply chain que incluye clientes y proveedores. Está diseñado para centrarse en ubicaciones específicas, no en toda la cadena.
Pregunta: ¿Cómo puedes realizar una transición suave de Python a Envision o hacer que trabajen juntos?
Históricamente, los hicimos trabajar juntos en algunas situaciones. Para la audiencia, Envision es un lenguaje de programación específico de dominio diseñado por Lokad que ha sido creado exclusivamente para la optimización predictiva de supply chains. En la próxima conferencia, demostraré Envision para que la gente pueda tener una mejor comprensión de lo que estoy hablando, con fragmentos reales de código.
Históricamente, utilizamos Python y Envision juntos porque, cuando comenzamos, Envision tenía capacidades muy limitadas, por lo que faltaban muchas cosas, y recurríamos a Python en muchas situaciones. A lo largo de los años, hemos expandido gradualmente las capacidades de Envision, de modo que hemos eliminado progresivamente la necesidad de componentes de Python. No se trata solo de componentes de Python; también es una serie de herramientas que deben conectarse, como Airflow.
Por cierto, la sintaxis de Envision se ha alineado a propósito en muchos aspectos con Python. Tomé la decisión consciente de diseñar la sintaxis de Envision de una manera que no fuera antagonista para los programadores de Python, de modo que, si estás familiarizado con Python, puedas aprender Envision en una semana. Se diferencia de maneras sutiles y profundas, pero en cuanto a 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 severos en producción que no se pueden solucionar, no significa que Python carezca de méritos. No es eso lo que estoy afirmando. Creo que Python tiene muchos méritos. Nuevamente, estamos hablando específicamente de cómo ejecutar supply chains en producción, lo cual es un problema muy específico.
Pregunta: ¿Cómo harías entender a un cliente que su ERP no está optimizando nada?
Eso es muy difícil porque, francamente, la peor situación es cuando un prospecto se me acerca y dice, “Nuestro ERP, un ERP legado, no está entregando ningún valor, y ahora queremos pasar al siguiente ERP que ofrezca optimización de la supply chain.” 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 la parte de gestión, y otro que se encargue de la optimización.
Cuando piensas en esos ERPs legados, tengo mucho respeto por ellos, especialmente esos productos AS/400 con un terminal de línea de comandos en los antiguos mainframes de IBM. Desde el lado de la gestión del problema, generalmente hacen un trabajo bastante correcto. Lo que los clientes realmente buscan podría ser una interfaz web en lugar de una línea de comandos, pero ¿hará esto que sus equipos en terreno sean más productivos? Yo lo cuestiono. Las líneas de comandos con terminales de texto pueden ser increíblemente ágiles y productivas, sin distracciones.
Así que es bastante difícil porque tenemos que desenredar todas las tonterías que impulsan nuestros competidores. Además, tenemos que explicar que el ERP no va a optimizar la supply chain y que no existe algo como la IA o blockchain, solo clases de modelos estadísticos. Desafortunadamente, perdemos a la mayoría de nuestros prospectos en esta etapa. Esa es una de las razones por las que realizo estas conferencias, ya que toma 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 distribución probabilística de demanda?
Bueno, Lokad, por supuesto. Pero ten en cuenta que, siendo CEO de Lokad y el accionista mayoritario de la compañía, 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 compañía que poseo y dirijo. Haré todo lo posible por mantenerme objetivo al respecto.
Por cierto, Lokad ha sido literalmente diseñado para manejar la distribución probabilística de la demanda, y no se trata solo de la distribución probabilística de la demanda. También aborda la distribución estocástica de lead time, la distribución estocástica de devoluciones y más. Necesitamos considerar todos los futuros posibles con sus probabilidades, considerando todo tipo de incertidumbres. La demanda es una de las variables más importantes, usualmente la más importante, pero no es la única.
Creo que he revisado todas las preguntas. Solo comprobando si me perdí algo… No hay más preguntas. Entonces, 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 diversos y ocasionalmente relacionados asuntos que resultarán de interés para desarrolladores de software, diseñadores y gerentes, y para aquellos que, ya sea por buena fortuna o desgracia, trabajan con ellos en alguna capacidad - Por Joel Spolsky, 2004
