00:22 Introducción
02:40 ¿Por qué un producto? Porque el capitalismo
08:18 ¿Qué debe hacer el producto?
10:05 Deseconomías de escala en el software
12:50 Comprémos un producto SCO listo para usar
21:58 SCM vs SCO
25:58 Interludio
28:21 SCO no es tu producto de software promedio
33:26 Ingredientes de software para SCO
42:49 Sin embargo, las hojas de cálculo no son el fin del juego
46:51 Python tampoco es el fin del juego
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 lección y preguntas de la audiencia
Descripción
El objetivo de una Supply Chain Quantitativa es ya sea entregar o mejorar una aplicación de software que robotice un conjunto de decisiones rutinarias (p.ej. reabastecimientos de inventario, actualizaciones de precios). La aplicación se concibe como un producto a ser diseñado. La teoría de supply chain está ahí para ayudarnos a entregar una aplicación que oriente a la compañía hacia el rendimiento de supply chain, siendo 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 “Entrega orientada a producto para la optimización de supply chain.”
Primero, cuando hablo de un producto, me refiero a un producto de software. Para aquellos de ustedes que alguna vez han tenido el privilegio de investigar lo que sucede bajo el capó de una pieza de software empresarial moderna, puede ser toda una experiencia.
Para quienes están 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í puede. Es solo que lo único que preserva 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 soporten. 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 sin perder la cordura, lo cual es uno de los requisitos para agregar valor a la empresa. Así que, procedamos.
¿Por qué un producto, y en particular, un producto de software? Observemos de cerca cómo operan tradicionalmente las supply chain. 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 ha estado sucediendo gradualmente en las últimas décadas es que el número de personas con trabajos de cuello azul ha disminuido constantemente. Hoy en día, en términos de producción, las cosas están ampliamente automatizadas. Aún existen 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 requerimientos de mano de obra bruta se han reducido tremendamente.
Terminas con una situación bastante peculiar en la que, si miras hacia el futuro con la proximidad de vehículos autónomos, muchas empresas tendrán más empleados de cuello blanco manejando hojas de cálculo de Excel para gestionar la supply chain que personas de cuello azul en el terreno para realizar labores manuales. A esto me refiero cuando hablo del trabajo administrativo.
Otro aspecto peculiar es que las supply chain han sido digitalizadas en muchas empresas durante al menos dos décadas. No es que vayamos a introducir software en las supply chain; las supply chain ya son gestionadas y operadas mediante software. Pero cuando observamos el rol de los humanos en estos sistemas de software, los humanos son literalmente utilizados como coprocesadores humanos en el sistema promedio de supply chain. Existen tipos específicos de operaciones que la CPU regular, el procesador de la máquina, no puede realizar, y por ello la tarea completa se delega a un humano. En conjunción con recetas numéricas simplistas numerical recipes, tales como el análisis ABC, 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 una perspectiva de costos, todo esto es gasto operativo (OpEx). Necesitas pagar a un ejército de empleados administrativos cada día para manejar todas las decisiones mundanas que tu empresa necesita tomar a diario. Esto incluye qué comprar, dónde ubicar el inventario, si mover una unidad de un almacén a una tienda, y muchas otras decisiones rutinarias. Los humanos toman estas decisiones y se dedican a apagar incendios para hacer frente a las deficiencias de las decisiones automáticas generadas de manera 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 objetivo principal de esta entrega orientada a 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 beneficio, son empresas de software. Representan la esencia de las empresas ultra-capitalistas, donde se realiza una inversión inicial, y luego se obtiene 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 devolver el control a la gerencia. 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 simplonas como el min-max. En su lugar, deberían estar para agregar valor, mejorar las recetas numéricas y actuar como estrategas. Existí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 subyace en esta presentación. Queremos transformar la supply chain en un activo capitalista, y para lograrlo, necesitamos convertir 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 abiertas, sino las 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 supply chain. Sin embargo, al analizar las tareas, incluso las supply chain más complicadas solo requieren que se tomen unas pocas docenas de tipos de decisiones cada día. Esto no es abrumador y resulta bastante razonable en términos de la cantidad de características. Curiosamente, estas decisiones son en gran medida excluyentes, por lo que existen límites a lo que se puede hacer mediante un enfoque de divide y vencerás. Una vez que has decidido comprar 100 unidades a un proveedor, no puedes permitir que otro subsistema decida 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, de alcance limitado 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, lo contrario ocurre en el software, donde agregar un 25% más de características puede duplicar el costo. Este concepto explica por qué las pequeñas startups pueden rivalizar con las grandes empresas: porque se enfocan en una fracción menor de características, el costo para 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 adoptar otro enfoque para nuestro producto de optimización de supply chain. Si elegimos comprar el producto a un proveedor de software, debemos considerar las características que el proveedor tendrá que entregar para atender el mercado.
Entonces, consideremos comprar un producto de optimización de supply chain 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é en Lokad en 2008, empecé con un pequeño producto de software orientado más hacia el forecast que a la optimización de supply chain. Al comenzar a trabajar con clientes, me di cuenta de que había tantas características y capacidades que no tenía, y a medida que trabajaba con otros clientes, encontraba aún más capacidades ausentes. Parecía ser un proceso interminable de descubrimiento de nuevos requerimientos.
Echemos un vistazo solo a las características centrales. Primero, tenemos empresas que son B2C o B2B, las cuales muestran patrones completamente diferentes en la gestión de supply chain. Por ejemplo, las empresas B2B suelen tener menos clientes, pero esos clientes hacen 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 negocio 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 centros 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 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 de árbol es el camino clásico de la supply chain directa, 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 acíclicos dirigidos (DAGs), donde una tienda puede ser servida por varios almacenes.
Entonces, básicamente, no se trata solo de un árbol en términos de grafos, puede reconectarse, aunque siga siendo únicamente en dirección hacia adelante. Pero lo mismo puede ocurrir con un Grafo Acíclico Dirigido (DAG) cuando tienes múltiples proveedores. Incluso puedes tener bucles en tu grafo de supply chain que ocurren cada vez que se involucran reparaciones. Por ejemplo, en la industria minera o en la industria de la aviación, hay toneladas 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 esta 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 además, puedes tener gran cantidad de inventario que ocurre con mucha frecuencia, por ejemplo, en la industria farmacéutica o alimentaria, donde el lote viene con fechas de caducidad específicas. Luego, incluso puedes tener inventario completamente serializado, donde cada unidad tiene su propio número de serie. En términos de optimización de supply chain, eso cambia completamente el juego, por lo que es un problema totalmente diferente cuando se observa 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, que pueden tener su propio marketplace, o ambos. Puede ser algo secundario para que puedan utilizarlo para liquidar las cosas que no vendieron. Existen muchas situaciones.
Ahora, solo por 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 diga: “Lo estoy comprando, pero no quiero que se entregue de inmediato; quiero que se entregue dentro de un mes.” Obviamente, desde una perspectiva de optimización de supply chain, es un juego completamente diferente porque si sabes de antemano que tendrás que entregar cierta cantidad de cosas en una fecha específica, no quieres hacer un forecast de eso, así que es algo completamente distinto.
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á en tu computadora, y cómo será tu teclado, entre otras cosas. Así, puedes tener un configurador masivo, y eso cambia el panorama nuevamente. Esto también ocurre en cosas como bicicletas o automóviles y cambia completamente el panorama cuando tienes este tipo de elementos, porque te ofrece opciones y maneras de abordar el problema de optimización de supply chain que son completamente diferentes.
Incluso para los precios, puedes tener el precio por unidad que es fijo, súper simple y muy 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 una tarjeta de lealtad pueden obtener un descuento, pero solo en ciertos tipos de productos o dependiendo de ciertas condiciones. Y luego puedes incluso tener, en B2B, cosas muy frecuentes que se negocian, así que es literalmente una transacción en la que se venden muchas cosas, pero tienes un precio de catálogo regular. Sin embargo, un proveedor puede otorgar un reembolso a un cliente porque es importante, y así es como se hace. En resumen, apenas he estado hablando por unos minutos, y solo he cubierto lo esencial. Ni siquiera he comenzado a tocar las cosas imprescindibles. Así que 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 debe ofrecer optimización de supply chain. La cantidad de funciones a cubrir es literalmente una locura, y cuando intentas juntar todas esas cosas en un monolito, literalmente pierdes la cabeza. Volvemos a esta idea de que no es que el universo no pueda ser conocido, es solo que si te expones a la cruda verdad del universo, pierdes la cordura.
Entonces, tenemos un gran problema, y aquí debemos diferenciar la gestión de supply chain de la optimización de supply chain. 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 la contabilidad, el soporte de flujos de trabajo y, sobre todo, de procesos de entrada de datos. Si deseas representar todas las cosas que acabo de describir, es mucho terreno por cubrir, pero es factible. Un ERP “obeso” puede hacerlo. 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 hará mucho. Solo llevará el 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 introducirlos en el sistema, y eso es todo.
Es posible porque, aquí, podemos hacer trampa un poco con esa regla de “un cuarto más de funciones duplica el costo.” Hay algo que no dije realmente al respecto: funciona si mantienes tus funciones completamente segregadas. Siempre y cuando 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 añadir una tienda extra a la red. Esas dos cosas pueden estar completamente segregadas.
Sin embargo, cuando se trata de la optimización de supply chain, lo mismo no es cierto. Si tienes MOQs, tendrán profundas implicaciones en la frecuencia con la que realizas 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 simplemente un sistema en el que 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 estar conectadas si deseas 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 supply chain, la respuesta es que no puedes. Quiero decir, puedes pretenderlo, pero literalmente, no puedes. Incluso en Lokad, que no comenzó como una empresa predictiva de supply chain que se especializara en optimización predictiva de supply chain, sino como forecast as a service. Si vuelves al blog de Lokad en 2008, inicialmente empecé con el forecast de series de tiempo, lo cual estuvo gravemente equivocado. No obstante, así es como comencé. Incluso para el forecast de series de tiempo, que es un subconjunto diminuto de todo el problema, es inmanejable. Esa es mi conclusión tras más de 12 años en este negocio.
Si tenemos que volver al mundo específico de la producción de software, es algo muy único. A menos que hayas sido formado como ingeniero de software y estés familiarizado con la forma en que las grandes y exitosas compañías 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 totalmente 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.
En futuras conferencias abordaremos estos aspectos con mayor detalle, 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 apenas era estudiante, leí su libro y su blog. El libro se titula “Joel on Software,” y te ofrece de manera humorística una comprensión de lo que implica dirigir un negocio de software exitoso. Es muy diferente a lo que la mayoría de la gente 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 común. Usualmente, cuando tratas con un producto de software promedio – quiero decir, sí, tienes algunos comportamientos adversariales, dependiendo del tipo de producto de software. Si se trata de una red social, puede haber muchas personas publicando contenido de odio, lo cual es un juego completamente diferente. Sin embargo, al tratar con software empresarial clásico, como Microsoft Word o Excel, es un producto en el que deseas tener el diseño adecuado, pero no hay ninguna urgencia. 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 pensar en décadas. No hay razón para apresurar nada en términos de desarrollo. Sin embargo, la optimización de supply chain no funciona así. No tienes la opció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 enfrentar inmovilización de flota debido a incidentes trágicos, movimientos políticos como aranceles que alteran tu estrategia, o desastres naturales como tsunamis o incendios y olas de calor, como los de California o Australia. Estos eventos ocurren, y cuando lo hacen, necesitas poder reaccionar literalmente en horas.
Tienes tu producto de software, pero necesitas generar un cambio, y deseas generar un cambio programático. Recuerda, si tienes la mentalidad de entregar un activo de software, cuentas con un pequeño equipo que impulsa el software y, a su vez, impulsa tu supply chain. No tienes un ejército de empleados administrativos apagando incendios durante todo el día. Incluso si tienes un ejército de empleados administrativos, necesitas capacitarlos, y cuando ocurre algo completamente inesperado, terminas con un ejército que no ha sido capacitado para esa situación específica. En mi experiencia, mientras más personas tengas para gestionar, más tiempo se tarda en lograr algo.
Hace apenas unos días, un barco de carga perdió más de 1,800 contenedores debido a malas condiciones climáticas. Estas cosas simplemente suceden, y no puedes esperar eliminarlas. Supply chain no es como la manufactura, donde podrías tener un sitio de producción con todo rigurosamente controlado. Por definición, supply chain ocurre 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 ser capaz de enfrentarte a eventos sorprendentes. Ya sabes que sucederán sorpresas, así que debes estar preparado. Estar preparado no significa tener todo cuidadosamente planificado; 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 cuanto a 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, así que queremos algo muy versátil en este sentido, con mucha estructura y variedad.
En segundo lugar, deseas lógica programable. Vuelvo a esta idea: si no tienes lógica programable, ¿cómo enfrentas todos estos problemas? ¿Cómo unes todas estas cosas? No puedes comprar un producto comercial que tenga todo preprogramado para ti; eso no funciona.
Luego, necesitas interfaces de usuario versátiles porque la forma en que deseas abordar tus problemas variará enormemente de una situación a otra. Los KPI serán completamente diferentes de una empresa a otra, así 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, por definición, trabajo en equipo. Hay muchas personas involucradas, y es distribuido, por lo que las capacidades colaborativas deben estar en el centro.
Por último, y quizás 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 simultáneamente un Supply Chain Scientist.
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 de manera confiable a más de ellas cada año si eres una gran empresa? Por 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 contar con alguien con competencia en supply chain porque debes ser capaz de afrontar, en cuestión de horas, aplicar las correcciones programáticas a tu sistema sin tener que abrir un ticket y pasarlo a TI. Si tienes que hacerlo de esa manera, entonces se tardan 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 se sienta como el pináculo del software moderno, pero hace el trabajo. Cumple con todos los requisitos.
¿Almacenamiento de datos versátil? Sí, en cierto modo, 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 cuanto a versatilidad, puede hacer mucho.
En cuanto a las capacidades colaborativas, es algo rudimentario. Tienes algunas versiones de Excel que están en línea, las cuales 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 acompaña a las hojas de cálculo, la cual no es adecuada para un trabajo colaborativo intenso. Usualmente, si tienes un colega que creó una hoja muy compleja, es más fácil recrearla en lugar de intentar descifrar lo que hizo. Así que, el problema con la falta de funciones colaborativas es la mentalidad que conllevan las hojas de cálculo, que inherentemente tiene fuertes límites para la colaboración.
Sin embargo, Excel es completamente accesible para quienes no son 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 correctos, lo que, creo, explica en gran medida el éxito operativo que tiene en la mayoría de las supply chains.
En mi experiencia, la mayoría de las supply chains 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 los ajustes de min-max en otro software, pero el mantenimiento de estos ajustes se delega a quienes trabajan con Excel.
Excel está impulsando el mundo de la supply chain hoy en día, y creo que no es una coincidencia. En esencia, las hojas de cálculo abordan fundamentalmente muchos de los problemas correctos. Muchas otras opciones se presentan como superiores, pero fallan por defecto si no puedes programar. Si no puedes 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 es accesible para quienes no son desarrolladores. Si solo es un equipo de TI el que puede ofrecer resultados, la gente puede inicialmente abrir tickets y esperar pacientemente, pero en tres meses, es probable que todos vuelvan a utilizar las hojas de cálculo de Excel porque es más rápido. Excel no es el objetivo final, pero sea cual sea la alternativa superior que propongamos, deberá cumplir con los requisitos adecuados.
¿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 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 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 errores.
La interfaz de usuario no es ideal, ya que no es completamente basada en la web y los datos siempre están enredados con la interfaz. Existen capacidades colaborativas, pero son desorganizadas. La colaboración debería ocurrir a nivel de lógica programable. Muchos proveedores de optimización de supply chain ofrecen colaboración en los resultados, como ajustar manualmente los forecast y permitir que varias personas participen. Sin embargo, este es el enfoque equivocado. Las colaboraciones deben ocurrir, pero tienen que suceder a nivel lógico, al nivel de la lógica programable. Excel es muy accesible para los no desarrolladores, pero cuando se quiere hacer algo un poco más complicado, se vuelve desafiante. En la gestión de supply chain, queremos tratar con todos los futuros posibles, lo que significa trabajar con forecast probabilísticos, variables aleatorias y abordar 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 es complicado crear algo verdaderamente preciso, 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 en torno a la ciencia de datos. Sin embargo, para la gestión de supply chain, creo que Python es inferior a Excel.
No me malinterpretes; 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 se requiere contar con personas que sean a la vez expertas en supply chain y en ingeniería de software.
Python tiene buenas características, 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 ofrecen 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 —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 lo hacen difícil de mejorar.
El rendimiento también es pobre, mayormente por diseño. El rendimiento de cómputo se refiere a la calidad del trabajo realizado por Python para explotar la potencia bruta de cálculo 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 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. Aunque a algunos les pueda parecer aceptable, dado el poder de las computadoras modernas, no es ideal para empresas con volúmenes de transacciones que superan los 50 millones de dólares. Deseas 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 estás creando un nuevo inconveniente al introducir la complejidad adicional de NumPy, con la que tendrás que 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 supply chain, surgen diversos problemas, como excepciones de referencia nula, excepciones de falta de memoria y tiempos de cómputo prolongados. Puede que te encuentres esperando 20 minutos a que una computación finalice, sin estar seguro de si terminará alguna vez o si deberías simplemente matar el proceso y reiniciarlo. Simplemente no lo sé, por lo que deseas cosas en las que tengas una idea muy, muy clara de cuánto tiempo tomará completarse. Por cierto, si vuelvo a Excel, hoy en día cuando hay una operación que toma un poco de tiempo completarse, Excel te dará un indicador bastante confiable, una barra de progreso sobre cuánto tiempo tomará. Así que, de nuevo, quieres, y eso es parte de lo que llamo la preparación para producción. Quieres tener algo que, de nuevo, el software que estás produciendo probablemente va a correr sin supervisión, durante la noche o durante el lote nocturno, por ejemplo. Quieres algo que no requiera que un data scientist esté vigilando todo el proceso.
Y de nuevo, si tienes el problema con los data scientists, entonces necesitas la tercera competencia: experto en supply chain, experto en ingeniería de software, y ahora un experto en data scientist. Es posible tener esas 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 cuenta con todas esas habilidades. Es simplemente muy raro.
Así que queremos tener algo que mejore. Por cierto, lo primero que queremos mejorar es la defensa en profundidad. Los ransomware están en aumento, y cada vez que introduces algo programable en tu organización, te expones a 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 formas de mitigar los problemas; puedes usar sandbox, puedes restringir, puedes tener derechos limitados, y hay muchas maneras de limitar 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, cada vez que integras código de esa manera, te expones enormemente a problemas de seguridad. Y recuerda, la forma en que normalmente se hace en un negocio de ingeniería de software es que el código es revisado por pares. Así que revisas el código, tienes un proceso de revisión de código, alguien produce el código, y un colega lo revisa para asegurarse de que no haya travesuras 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 supply chain, tener un proceso de revisión de código en marcha. Simplemente no es compatible con los retrasos y las emergencias que enfrentarás.
Por lo tanto, necesitas tener algo que te brinde defensa en profundidad por diseño. Luego, deseas tener algo con rendimiento transparente, donde sí, las cosas pueden tomar tiempo, pero necesitas tener el control. Necesitas saber de antemano cuánto tiempo tomará. Si no lo tienes, te expones a un montón de problemas muy estúpidos, como si tuvieras una ventana de dos horas para entregar resultados y llegas tarde. ¿Y sabes qué? Los camiones ya se han ido. Es demasiado tarde. Así que necesitas tener algo en lo que eso esté resuelto.
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 de sangre hace décadas, que decía: si has producido una hoja de cálculo en Excel, sea cual sea la próxima versión de Excel que llegue al mercado, será capaz de soportar tus hojas de cálculo. Y lo más increíble es que, si miras Excel hoy en día, soporta muchos formatos de Excel de competidores que ya ni siquiera existen. Aún puedes leer hojas de cálculo que fueron producidas con Lotus Notes y ese tipo de cosas. Así que 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é? Está resuelto. Eso no es algo que veas cuando miras 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 ocurran en los peores momentos, donde tienes la peor pandemia, la peor tarifa, la peor emergencia, y necesitas que todo esté en funcionamiento 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.
Así que ahora necesitamos pensar en qué pasaría si realmente consideráramos algo que pudiera estar 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 IT. Cuando hablo de una entrega orientada a producto, nuevamente, no es que el software sea solo un medio, y no un fin. No estarás vendiendo tu software por licencias o una tarifa como, digamos, hace Microsoft. En esta visión que estoy trazando frente a ti en esta conferencia, IT es responsable de las prácticas esenciales, las prácticas fundamentales de IT, como lo que deberías o no deberías hacer en términos de seguridad, respaldos, infraestructura central, tu red, cómo gestionar y sincronizar todo en términos de datos a nivel empresarial, y proporcionar toda la orientación y entrenamiento.
Pero la idea es que supply chain necesita tener el control de las decisiones de supply chain. Ellos deben poseer todo el aparato que genera esas decisiones de supply chain, por lo que esa es su propiedad principal. En la conferencia anterior, dije lo que define al Supply Chain Scientist: el Supply Chain Scientist es alguien que posee las decisiones numéricas producidas por el código. No es un sistema el que produce decisiones; son recetas numéricas que han sido documentadas por uno o varios Supply Chain Scientists, y esos Supply Chain Scientists colectivamente poseen esas decisiones numéricas. Asumen la propiedad de 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 curso o un gran impulso de marketing, las cosas deben producirse a tiempo para estar listas para ser atendidas. No quieres terminar en una situación catastrófica donde estás impulsando algo cuando ya estás en una situación de casi faltante 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 para 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 IT, el departamento de IT no es una división donde se pasen tickets. Así no es como funciona. El departamento de IT está a cargo de la infraestructura central. Es ese tipo de cosa que simplemente funciona sin inconvenientes todo el tiempo. Ni siquiera le prestas atención, al igual que el Wi‑Fi funciona. No prestas atención al Wi‑Fi; solo lo notas cuando no funciona. Un buen departamento de IT entrega toda la infraestructura para que ni siquiera te des cuenta de ellos. Ni siquiera te das cuenta de que existen porque simplemente funciona, al igual que tus correos electrónicos que trabajan impecablemente, etc. De eso se trata un buen IT central. Y luego, IT 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 un poco difícil, así que a veces, ¿dónde vas a conseguir el coaching para mejorar un poco en la programación? Bueno, la respuesta es que debería ser IT. 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 te ayudemos con algunas cosas que son un poco más técnicas de lo que deberían ser.” A veces, tienes complejidad accidental, así que IT 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 pueda representar un riesgo sistémico, en términos de IT, para la compañía.
Como prueba de fuego, si tu interacción entre IT y supply chain se realiza a través de documentos en los que se enlistan especificaciones o requisitos, esta no es la manera adecuada de tener una buena relación entre ambas divisiones. Cuando digo 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, en el que quizá se ha estado haciendo programación pero solo de forma periférica en hojas de Excel, sin darse cuenta inicialmente de que ya era una forma de programación. Tienes que superar tus miedos. Tienes que 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 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 fundamental ni radicalmente más difícil que Excel. De nuevo, el desafío no está en la tecnicidad de la herramienta; es literalmente en la complejidad de la supply chain en sí. El problema es difícil no porque tu herramienta sea difícil 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 del área de IT, lo que debes superar es la sobreconfianza. He visto, una y otra vez, data scientists, y me incluyo en esa categoría, que confiaban excesivamente en su capacidad de llevar un prototipo a producción. Esto es duro, y las supply chains tienen la manera de explotar en tu cara de la forma más sorprendente. Solo puedo recordar una anécdota en la que, hace años, comenzamos con una importante compañía europea de ecommerce de autopartes. Estábamos manejando sus reposiciones de partes con nuestra tecnología de forecast, haciendo sugerencias para las reposiciones de partes, sirviendo autopartes. La semana siguiente, vimos que todos nuestros forecasts estaban equivocados por un factor de dos. La demanda se había duplicado. Lo que había pasado 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 estábamos iniciando 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 la optimización de los 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 recordaba naturalmente el nombre del competidor. Entonces, iban a Google y escribían “car parts” hasta que terminaban en el sitio web de mi cliente. Para demostrar lo genial que era Lokad, la primera semana, al comenzar, estábamos equivocados por un factor de dos, y pensábamos, “¿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 aumentando 10 veces, y muchas otras simplemente permanecen sin cambios.
Eso es más o menos de lo que se trata, y necesitas poder reaccionar rápidamente. De eso se trata: miedo y sobreconfianza. Muchas gracias por su tiempo.
Ahora, voy a 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 fresas de 200 gramos 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 es literalmente tener todas las 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 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 que, 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á manejado por IT, 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 se encarga de asegurarse de que, al generar cierta cantidad, se cumplan todas las restricciones, como la lista exacta de proveedores que son elegibles para servir estos productos, si tienen stock disponible, y cómo hacer la elección correcta entre todos los proveedores competidores, etc. Podría haber muchas cosas en juego. 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 componente de optimización en el momento en que decides que necesitas reordenar más.
Pregunta: ¿Sabes que en este momento estás compitiendo con los eSports World Championships?
No, no estoy compitiendo con esos campeonatos de eSports en este momento, pero es muy genial. Por cierto, en Lokad, frecuentemente jugamos Dota 2, así que el equipo directivo también juega. Algunos de nuestros empleados quieren jugar League of Legends, pero como CEO de la compañía, desapruebo firmemente.
Pregunta: He visto que muchos negocios no tienen 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 existía 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, la gente aún tenía que tomar decisiones. Así que la optimización de la supply chain ya era una realidad; la gente lo hacía con lápiz y papel. Si observas 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, independientemente de si cuentas con software o no en tu organización.
Ahora, en efecto, necesitas contar con sistemas adecuados de IT, 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 básicas, simplemente 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 lleno de errores, y que incluye características no deseadas como alertas y excepciones, las cuales deberías evitar. Volveré sobre 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 desvinculas eso de tus decisiones.
Pregunta: ¿Cuándo puede la dirección del negocio darse cuenta de que es momento de pasar de rastrear información a optimizar decisiones de supply chain y, eventualmente, empezar a enfocarse en la optimización de la supply chain?
La primera cosa es que, primero, tienes que darte cuenta de que hay dos problemas, y que la misma pieza de software nunca abordará ambos ángulos. Creo que esa es la gran ilusión, y los proveedores de software han sido increíblemente confusos en este ámbito. Si observas a los mayores proveedores de ERP, su mensaje es sobre la optimización de la supply chain, pero todo lo que en realidad 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 inteligencia real. En el mundo del software, se le 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 registros 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 puede agrupar lógicamente, tienes una o dos pantallas, y ya está. Entonces, si vuelvo a tu pregunta sobre la dirección, el problema es que, si eres gerente, lees el folleto del proveedor de ERP, y estos te dicen que esta solución va a optimizar tu supply chain. La respuesta es: no, absolutamente no. Lo que va a hacer 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, las mercancías perdidas y mejorar la productividad con códigos de barras para un almacén. Hay un gran valor agregado en estos productos. No estoy descartando el valor que un ERP o un WMS aporta; es enorme, pero no se trata de la optimización de la supply chain. Un WMS, por ejemplo, es por diseño algo que se ocupa del almacén; no se ocupa de toda la supply chain que incluye clientes y proveedores. Está diseñado para enfocarse 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 únicamente para la optimización predictiva de supply chains. En la próxima conferencia, estaré demostrando Envision para que la gente pueda tener un mejor entendimiento de lo que estoy comentando, con fragmentos reales de código.
Históricamente, usamos Python y Envision juntos porque, cuando comenzamos, Envision tenía capacidades muy limitadas, así que faltaban muchas cosas, y en muchas situaciones recurríamos a Python por defecto. Con los años, hemos ampliado gradualmente las capacidades de Envision, de manera que hemos ido eliminando progresivamente la necesidad de contar con componentes en Python. No se trata solo de componentes de Python; también es una serie de herramientas que deben integrarse, como Airflow.
Por cierto, la sintaxis de Envision se ha alineado intencionadamente en muchos aspectos con Python. Tomé la decisión consciente de diseñar la sintaxis de Envision de una manera que no resultara antagónica para los programadores de Python, de modo que, si estás familiarizado con Python, puedes aprender Envision en una semana. Se diferencia en aspectos sutiles y profundos, pero en cuanto a sintaxis, hay muchos aspectos que son iguales. Python tiene muchos méritos, como la simplicidad y la pureza de su diseño. Incluso si digo que Python no cumple con todos los requisitos y crea problemas severos en producción que no pueden solucionarse, no significa que Python carezca de méritos. No es eso lo que quiero decir. Creo que Python tiene muchos méritos. Repito, estamos hablando específicamente de cómo operar 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á aportando ningún valor, y ahora queremos pasar al siguiente ERP que ofrezca optimización de la supply chain.” Esa es una situación terrible para mí, porque tengo que decirle al cliente que lo que busca no es un producto, sino dos: uno que reemplace su ERP y maneje mejor el lado de la 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 terminal de línea de comandos en las antiguas mainframes de IBM. Desde el lado de la gestión del problema, generalmente hacen un trabajo muy aceptable. 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 dudo. 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 empujan nuestros competidores. Además, tenemos que explicar que el ERP no va a optimizar la supply chain y que no existe algo como IA o blockchain, simplemente 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 estoy dando estas conferencias en primer lugar, porque 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 de demanda probabilística?
Bueno, Lokad, por supuesto. Pero ten en cuenta que, siendo el 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 en eso.
Por cierto, Lokad ha sido literalmente diseñado para lidiar con la distribución de demanda probabilística, y no se trata solo de la distribución de demanda probabilística. 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, teniendo en cuenta todos los tipos de incertidumbres. La demanda es una de las más importantes, usualmente la más relevante, pero no es la única.
Creo que he repasado todas las preguntas. Solo reviso si me perdí de algo… No hay más preguntas. Así que, gracias a todos por ver esta conferencia, y nos vemos la próxima semana, mismo día, 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 mala suerte, trabajan con ellos en alguna capacidad - Por Joel Spolsky, 2004
