00:19 Introducción
04:33 Dos definiciones para ‘algoritmo’
08:09 Big-O
13:10 El desarrollo hasta ahora
15:11 Ciencias auxiliares (recapitulación)
17:26 Algoritmos modernos
19:36 Superando la “optimalidad”
22:23 Estructuras de datos - 1/4 - Lista
25:50 Estructuras de datos - 2/4 - Árbol
27:39 Estructuras de datos - 3/4 - Grafo
29:55 Estructuras de datos - 4/4 - Tabla hash
31:30 Recetas mágicas - 1/2
37:06 Recetas mágicas - 2/2
39:17 Comprensión de tensores - 1/3 - La notación ‘Einstein’
42:53 Comprensión de tensores - 2/3 - Avance del equipo de Facebook
46:52 Comprensión de tensores - 3/3 - Perspectiva de la cadena de suministro
52:20 Meta técnicas - 1/3 - Compresión
56:11 Meta técnicas - 2/3 - Memorización
58:44 Meta técnicas - 3/3 - Inmutabilidad
01:03:46 Conclusión
01:06:41 Próxima clase y preguntas de la audiencia
Descripción
La optimización de las cadenas de suministro se basa en resolver numerosos problemas numéricos. Los algoritmos son recetas numéricas altamente codificadas destinadas a resolver problemas computacionales precisos. Los algoritmos superiores significan que se pueden lograr resultados superiores con menos recursos informáticos. Al centrarse en los aspectos específicos de la cadena de suministro, el rendimiento algorítmico puede mejorar enormemente, a veces en órdenes de magnitud. Los algoritmos de “supply chain” también deben abarcar el diseño de las computadoras modernas, que ha evolucionado significativamente en las últimas décadas.
Transcripción completa
Bienvenidos a esta serie de clases sobre cadena de suministro. Soy Joannes Vermorel y hoy presentaré “Algoritmos modernos para la cadena de suministro”. Las capacidades informáticas superiores son fundamentales para lograr un rendimiento superior de la cadena de suministro. Pronósticos más precisos, optimización más detallada y optimización más frecuente son deseables para lograr un rendimiento superior de la cadena de suministro. Siempre hay un método numérico superior justo un poco más allá de los recursos informáticos que puedes permitirte.
Los algoritmos, para simplificarlo, hacen que las computadoras vayan más rápido. Los algoritmos son una rama de las matemáticas y este es un campo de investigación muy activo. El progreso en este campo de investigación a menudo supera el progreso del hardware informático en sí. El objetivo de esta clase es comprender de qué se tratan los algoritmos modernos y, más específicamente, desde una perspectiva de la cadena de suministro, cómo abordar los problemas para poder aprovechar al máximo esos algoritmos modernos para su cadena de suministro.
En términos de algoritmos, hay un libro que es una referencia absoluta: Introducción a los algoritmos, publicado por primera vez en 1990. Es un libro que hay que leer. La calidad de la presentación y la escritura es simplemente excepcional. Este libro vendió más de medio millón de copias durante sus primeros 20 años de vida e inspiró a toda una generación de escritores académicos. De hecho, la mayoría de los libros recientes sobre teoría de la cadena de suministro que se han publicado en la última década han estado frecuentemente muy inspirados en el estilo y la presentación que se encuentran en este libro.
Personalmente, leí este libro por primera vez en 1997 y en realidad era una traducción al francés de la primera edición. Tuvo una influencia profunda en toda mi carrera. Después de leer este libro, nunca volví a ver el software de la misma manera. Sin embargo, una palabra de precaución es que este libro adopta una perspectiva sobre el hardware informático que era predominante a fines de los años 80 y principios de los 90. Como hemos visto en las clases anteriores de esta serie, el hardware informático ha progresado de manera bastante dramática en las últimas décadas y, por lo tanto, algunas de las suposiciones hechas en este libro se sienten relativamente anticuadas. Por ejemplo, el libro asume que los accesos a la memoria tienen un tiempo constante, sin importar cuánta memoria quieras abordar. Esto ya no es la forma en que funcionan las computadoras modernas.
Sin embargo, creo que hay ciertas situaciones en las que ser simplista es una propuesta razonable si lo que ganas a cambio es un grado mucho mayor de claridad y simplicidad de exposición. Este libro hace un trabajo increíble en este aspecto. Si bien aconsejo tener en cuenta que algunas de las suposiciones clave hechas a lo largo del libro están desactualizadas, sigue siendo una referencia absoluta que recomendaría a toda la audiencia.
Aclaremos el término “algoritmo” para la audiencia que quizás no esté tan familiarizada con la noción. Existe la definición clásica donde es una secuencia finita de instrucciones de computadora bien definidas. Este es el tipo de definición que encontrarás en los libros de texto o en Wikipedia. Aunque la definición clásica de un algoritmo tiene sus méritos, creo que es decepcionante, ya que no aclara la intención asociada con los algoritmos. No es cualquier tipo de secuencia de instrucciones lo que interesa; es una secuencia muy específica de instrucciones de computadora. Por lo tanto, propongo una definición personal del término algoritmo: un algoritmo es esencialmente un método de software orientado al rendimiento, detallado y orientado a la resolución de problemas.
Desglosemos esta definición, ¿de acuerdo? Primero, la parte de resolución de problemas: un algoritmo está completamente caracterizado por el problema que intenta resolver. En esta pantalla, lo que puedes ver es el pseudocódigo del algoritmo Quicksort, que es un algoritmo popular y bien conocido. Quicksort intenta resolver el problema de ordenación, que es el siguiente: tienes una matriz que contiene entradas de datos y quieres un algoritmo que devuelva la misma matriz pero con todas las entradas ordenadas en orden creciente. Los algoritmos se centran completamente en un problema específico y bien definido.
El segundo aspecto es cómo juzgas que tienes un mejor algoritmo. Un algoritmo mejor es algo que te permite resolver el mismo problema con menos recursos informáticos, lo que en la práctica significa más rápido. Por último, está la parte detallada. Cuando decimos el término “algoritmos”, viene con la idea de que queremos analizar problemas muy elementales que son modulares y se pueden componer infinitamente para resolver problemas mucho más complicados. Eso es realmente de lo que se tratan los algoritmos.
Uno de los logros clave de la teoría de algoritmos es proporcionar una caracterización del rendimiento de los algoritmos de manera bastante abstracta. No tendré tiempo hoy para adentrarme en los detalles de esta caracterización y el marco matemático. La idea es que, para caracterizar el algoritmo, queremos analizar el comportamiento asintótico. Tenemos un problema que depende de una o varias dimensiones clave de cuello de botella que caracterizan el problema. Por ejemplo, en el problema de ordenación que presenté anteriormente, la dimensión característica suele ser el número de elementos que se van a ordenar. La pregunta es, ¿qué sucede cuando la matriz de elementos a ordenar se vuelve muy grande? Voy a referirme a esta dimensión característica con el número “n” como convención.
Ahora, tengo esta notación, la notación Big O, que quizás hayas visto al tratar con algoritmos. Solo voy a esbozar algunos elementos para darte una idea de lo que está sucediendo. Primero, digamos, por ejemplo, que tenemos un conjunto de datos y queremos extraer un indicador estadístico simple como un promedio. Si digo que tengo un algoritmo Big O de 1, significa que puedo devolver una solución a este problema (calcular el promedio) en tiempo constante, independientemente de si el conjunto de datos es pequeño o grande. El tiempo constante, o Big O de 1, es un requisito absoluto cuando quieres hacer algo que sea en tiempo real en el sentido de la comunicación de máquina a máquina. Si no tienes algo que sea en tiempo constante, es muy difícil, a veces imposible, lograr un rendimiento en tiempo real.
Típicamente, otro aspecto clave de rendimiento es Big O de N. Big O de N significa que tienes una complejidad para el algoritmo que es estrictamente lineal al tamaño del conjunto de datos de interés. Esto es lo que obtienes cuando tienes una implementación eficiente que puede resolver el problema leyendo los datos una vez o un número fijo de veces. La complejidad Big O de N generalmente solo es compatible con la ejecución por lotes. Si quieres tener algo que sea en línea y en tiempo real, no puedes tener algo que recorra todo el conjunto de datos, a menos que sepas que tu conjunto de datos tiene un tamaño fijo.
Más allá de la linealidad, tienes Big O de N al cuadrado. Big O de N al cuadrado es un caso muy interesante porque es el punto óptimo de explosión de producción. Significa que la complejidad crece de forma cuadrática en relación al tamaño del conjunto de datos, lo que significa que si tienes 10 veces más datos, tu rendimiento será 100 veces peor. Este es típicamente el tipo de rendimiento donde no verás ningún problema en el prototipo porque estás jugando con conjuntos de datos pequeños. No verás ningún problema en la fase de pruebas porque, nuevamente, estás jugando con conjuntos de datos pequeños. Tan pronto como vayas a producción, tendrás un software que es completamente lento. Con frecuencia, en el mundo del software empresarial, especialmente en el mundo del software empresarial de la cadena de suministro, la mayoría de los problemas de rendimiento abismal que se pueden observar en el campo son causados en realidad por algoritmos cuadráticos que no se habían identificado. Como resultado, observas el comportamiento cuadrático que es simplemente súper lento. Este problema no se identificó desde el principio porque las computadoras modernas son bastante rápidas y N al cuadrado no es tan malo siempre y cuando N sea bastante pequeño. Sin embargo, tan pronto como estés lidiando con un conjunto de datos a gran escala de producción, duele mucho.
Esta conferencia es en realidad la segunda conferencia de mi cuarto capítulo en esta serie de conferencias de la cadena de suministro. En el primer capítulo, el prólogo, presenté mis puntos de vista sobre la cadena de suministro como un campo de estudio y una práctica. Lo que hemos visto es que la cadena de suministro es una gran colección de problemas complejos, en lugar de problemas simples. Los problemas complejos no pueden abordarse con metodologías ingenuas porque tienes comportamientos adversarios por todas partes, y por lo tanto, necesitas prestar mucha atención a la metodología en sí. La mayoría de los métodos ingenuos fallan de manera bastante espectacular. Eso es exactamente lo que he hecho en el segundo capítulo, que está completamente dedicado a metodologías adecuadas para estudiar las cadenas de suministro y mejorar la práctica de la gestión de la cadena de suministro. El tercer capítulo, que aún no está completo, es esencialmente un enfoque en lo que llamo “personal de la cadena de suministro”, una metodología muy específica donde nos enfocamos en los problemas en sí mismos en lugar de las soluciones que podemos pensar para abordar el problema. En el futuro, alternaré entre el capítulo número tres y el capítulo actual, que trata sobre las ciencias auxiliares de la cadena de suministro.
Durante la última conferencia, vimos que podemos obtener más capacidades de cálculo para nuestra cadena de suministro a través de hardware informático mejor y más moderno. Hoy, estamos mirando el problema desde otro ángulo: buscamos más capacidades de cálculo porque tenemos un mejor software. De eso se tratan los algoritmos.
Un breve resumen: las ciencias auxiliares son esencialmente una perspectiva sobre la cadena de suministro en sí misma. La conferencia de hoy no trata estrictamente sobre la cadena de suministro; se trata de algoritmos. Sin embargo, creo que es de importancia fundamental para la cadena de suministro. La cadena de suministro no es una isla; el progreso que se puede lograr en la cadena de suministro depende en gran medida del progreso que ya se ha logrado en otros campos adyacentes. Me refiero a esos campos como las ciencias auxiliares de la cadena de suministro.
Creo que la situación es bastante similar a la relación entre las ciencias médicas y la química durante el siglo XIX. A principios del siglo XIX, las ciencias médicas no se preocupaban en absoluto por la química. La química aún era la novedad y no se consideraba una propuesta válida para un paciente real. Avancemos rápidamente hasta el siglo XXI, la propuesta de que puedes ser un excelente médico sin saber nada de química se consideraría completamente absurda. Se acepta que ser un excelente químico no te convierte en un excelente médico, pero en general se acepta que si no sabes nada sobre la química del cuerpo, no puedes ser competente en cuanto a las ciencias médicas modernas se refiere. Mi opinión para el futuro es que durante el siglo XXI, el campo de la cadena de suministro comenzará a considerar el campo de los algoritmos de manera muy similar a como el campo de las ciencias médicas comenzó a mirar la química a través del siglo XIX.
Los algoritmos son un campo de investigación enorme, una rama de las matemáticas, y solo rascaremos la superficie de este campo de investigación hoy. En particular, este campo de investigación ha acumulado resultados sorprendentes tras resultados sorprendentes durante décadas. Puede ser un campo de investigación bastante teórico, pero no significa que sea solo teoría. De hecho, es un campo de investigación bastante teórico, pero ha habido toneladas de descubrimientos que se han implementado en la práctica.
De hecho, cualquier tipo de teléfono inteligente o computadora que estés usando hoy en día está literalmente utilizando decenas de miles de algoritmos que se publicaron originalmente en algún lugar. Este historial es en realidad mucho más impresionante en comparación con la teoría de la cadena de suministro, donde la gran mayoría de las cadenas de suministro no se están ejecutando en función de los hallazgos de la teoría de la cadena de suministro, al menos todavía. Cuando se trata de computadoras modernas y algoritmos modernos, prácticamente todo lo relacionado con el software está completamente impulsado por todas esas décadas de hallazgos de la investigación algorítmica. Esto está en el núcleo mismo de prácticamente todas las computadoras que estamos usando hoy en día.
Para la conferencia de hoy, he seleccionado una lista de temas que creo que son bastante ilustrativos de lo que debes saber para abordar el tema de los algoritmos modernos. Primero, discutiremos cómo podemos superar supuestamente los algoritmos óptimos, especialmente para la cadena de suministro. Luego, echaremos un vistazo rápido a las estructuras de datos, seguido de recetas mágicas, compresión de tensores y, finalmente, técnicas meta.
Primero, me gustaría aclarar que cuando digo “algoritmos para la cadena de suministro”, no me refiero a algoritmos destinados a resolver problemas específicos de la cadena de suministro. La perspectiva correcta es mirar los algoritmos clásicos para problemas clásicos y revisar esos problemas clásicos desde una perspectiva de cadena de suministro para ver si realmente podemos hacer algo mejor. La respuesta es sí, podemos.
Por ejemplo, el algoritmo de ordenación rápida, según la teoría general de algoritmos, es óptimo en el sentido de que no se puede introducir un algoritmo que sea arbitrariamente mejor que la ordenación rápida. Entonces, en este sentido, la ordenación rápida es tan buena como puede ser. Sin embargo, si nos enfocamos específicamente en la cadena de suministro, es posible lograr mejoras sorprendentes en la velocidad. En particular, si nos fijamos en problemas de ordenación donde la cardinalidad de los conjuntos de datos de interés es baja, como fechas, precios, niveles de stock, o categorías, todos esos son conjuntos de datos de baja cardinalidad. Por lo tanto, si tienes suposiciones adicionales, como estar en una situación de baja cardinalidad, entonces puedes usar el ordenamiento por casilleros. En producción, hay muchas situaciones en las que puedes lograr velocidades absolutamente monumentales, como 500 veces más rápido que la ordenación rápida. Por lo tanto, puedes ser órdenes de magnitud más rápido de lo que se suponía que era óptimo solo porque no estás en el caso general sino en el caso de la cadena de suministro. Eso es algo muy importante, y creo que aquí radica la clave de los resultados sorprendentes que podemos lograr aprovechando los algoritmos para la cadena de suministro.
Creo que esta perspectiva es equivocada por al menos dos razones. Primero, como hemos visto, no es necesariamente el algoritmo estándar el que es de interés. Hemos visto que hay un algoritmo supuestamente óptimo como la ordenación rápida, pero si tomas el mismo problema desde un ángulo de cadena de suministro, puedes lograr mejoras masivas en la velocidad. Por lo tanto, es de interés primordial estar familiarizado con los algoritmos, aunque solo sea para poder revisar los clásicos y lograr mejoras masivas en la velocidad solo porque no estás en el caso general sino en el caso de la cadena de suministro.
La segunda razón por la que creo que esta perspectiva es equivocada es que los algoritmos tienen mucho que ver con las estructuras de datos. Las estructuras de datos son formas en las que puedes organizar los datos para poder operar de manera más eficiente en los datos. Lo interesante es que todas estas estructuras de datos forman un vocabulario de algún tipo, y tener acceso a este vocabulario es esencial para poder describir situaciones de cadena de suministro de manera que se presten a una fácil traducción al software. Si comienzas con una descripción utilizando términos comunes, generalmente terminas con cosas que son extremadamente difíciles de traducir al software. Si esperas que un ingeniero de software, que no sabe nada sobre la cadena de suministro, implemente esta traducción por ti, eso podría ser una receta para problemas. De hecho, es mucho más fácil si conoces este vocabulario, para que puedas hablar directamente los términos que se prestan fácilmente a la traducción de las ideas que tienes al software.
Vamos a revisar las estructuras de datos más populares y simples. La primera sería la lista. La lista se puede utilizar, por ejemplo, para representar una ruta de entrega, que sería la secuencia de entregas que se deben realizar, con una entrada por entrega. Puedes enumerar la ruta de entrega a medida que avanzas en ella. Una lista también puede representar un flujo de trabajo, que es una secuencia de operaciones necesarias para fabricar cierto equipo, o una cadena de mando, que determina quién debe tomar ciertas decisiones.
De manera similar, los árboles son otra estructura de datos omnipresente. Por cierto, los árboles algorítmicos están al revés, con la raíz en la parte superior y las ramas en la parte inferior. Los árboles te permiten describir todo tipo de jerarquías, y las cadenas de suministro tienen jerarquías por todas partes. Por ejemplo, una lista de materiales es un árbol; tienes un equipo que quieres fabricar, y este equipo está hecho de ensamblajes. Cada ensamblaje está hecho de subensamblajes, y cada subensamblaje está hecho de piezas. Si expandes completamente la lista de materiales, obtienes un árbol. De manera similar, un catálogo de productos, donde tienes familias de productos, categorías de productos, productos, subcategorías, etc., con frecuencia tiene una arquitectura similar a un árbol. Un organigrama, con el CEO en la parte superior, los ejecutivos de nivel C debajo, y así sucesivamente, también se representa mediante un árbol. La teoría algorítmica te brinda una multitud de herramientas y métodos para procesar árboles y realizar operaciones de manera eficiente en ellos. Siempre que puedas representar datos como un árbol, tienes un arsenal completo de métodos matemáticos para trabajar de manera eficiente con esos árboles. Por eso esto es de gran interés.
Ahora bien, los grafos te permiten describir todo tipo de redes. Por cierto, un grafo, en el sentido matemático, es un conjunto de vértices y un conjunto de aristas, con aristas que conectan dos vértices entre sí. El término “grafo” puede ser un poco engañoso porque no tiene nada que ver con gráficos. Un grafo es simplemente un objeto matemático, no un dibujo ni nada gráfico. Cuando sabes cómo buscar grafos, verás que las cadenas de suministro tienen grafos por todas partes.
Algunos ejemplos: un surtido en una red minorista, que es fundamentalmente un grafo bipartito, conecta productos y tiendas. Si tienes un programa de lealtad donde registras qué cliente ha comprado qué producto a lo largo del tiempo, tienes otro grafo bipartito que conecta clientes y productos. En el mercado de accesorios automotrices, donde tienes reparaciones que ejecutar, típicamente necesitas usar una matriz de compatibilidad que te dice la lista de piezas que tienen compatibilidad mecánica con el vehículo de interés. Esta matriz de compatibilidad es esencialmente un grafo. Existe una enorme cantidad de literatura sobre todo tipo de algoritmos que te permiten trabajar con grafos, por lo que es muy interesante cuando puedes caracterizar un problema como compatible con una estructura de grafo porque todos los métodos conocidos en la literatura están disponibles de inmediato.
Finalmente, la última estructura de datos que cubriré hoy es la tabla hash. La tabla hash es básicamente la navaja suiza de los algoritmos. No es nueva; ninguna de las estructuras de datos que he presentado son recientes según ningún estándar. La tabla hash es probablemente la más reciente de todas, data de la década de 1950, por lo que no es reciente. Sin embargo, la tabla hash es una estructura de datos increíblemente útil. Es un contenedor que contiene pares de claves y valores. La idea es que con este contenedor, puedes almacenar una gran cantidad de datos, y te brinda un rendimiento de O(1) para buscar, insertar y eliminar. Tienes un contenedor donde puedes, en tiempo constante, agregar datos, verificar si los datos están presentes o no (mirando la clave) y potencialmente eliminar datos. Esto es muy interesante y útil. Las tablas hash están literalmente en todas partes y se utilizan ampliamente dentro de otros algoritmos.
Una cosa que señalaré, y volveremos a este punto más adelante, es que el rendimiento de una tabla hash depende en gran medida del rendimiento de la función hash que tengas.
Ahora, echemos un vistazo a las recetas mágicas y cambiaremos completamente a una perspectiva diferente. Los números mágicos son fundamentalmente un anti-patrón. En la conferencia anterior, la que trata sobre el conocimiento negativo para la cadena de suministro, discutimos cómo los anti-patrones generalmente comienzan con una buena intención pero terminan con consecuencias no deseadas que deshacen los beneficios supuestamente aportados por la solución. Los números mágicos son un anti-patrón de programación bien conocido. Este anti-patrón de programación consiste en escribir código lleno de constantes que parecen completamente aleatorias, lo que hace que tu software sea muy difícil de mantener. Cuando tienes toneladas de constantes, no está claro por qué tienes esas restricciones y cómo se eligieron.
Por lo general, cuando ves números mágicos en un programa, es mejor aislar todas esas constantes en un lugar donde sean más manejables. Sin embargo, hay situaciones en las que una elección cuidadosa de constantes hace algo completamente inesperado, y tienes beneficios casi mágicos y completamente no deseados al usar números que parecen haber caído del cielo. Esto es exactamente de lo que trata el algoritmo muy corto que estoy presentando aquí.
En la cadena de suministro, con mucha frecuencia, queremos poder lograr una simulación de algún tipo. Las simulaciones o los procesos de Monte Carlo son uno de los trucos básicos que puedes usar en una miríada de situaciones de cadena de suministro. Sin embargo, el rendimiento de tu simulación depende en gran medida de tu capacidad para generar números aleatorios. Para generar simulaciones, generalmente hay un grado de aleatoriedad generada involucrada, por lo que necesitas un algoritmo para generar esta aleatoriedad. En lo que respecta a las computadoras, generalmente es seudorandomicidad, no es verdadera aleatoriedad; es algo que parece números aleatorios y tiene las características estadísticas de los números aleatorios, pero en realidad no lo es.
La pregunta es, ¿qué tan eficientemente puedes generar números aleatorios? Resulta que hay un algoritmo llamado “Shift”, publicado en 2003 por George Marsaglia, que es bastante impresionante. Este algoritmo genera números aleatorios de muy alta calidad, creando una permutación completa de 2 a la potencia de 64 menos 1 bits. Va a circular a través de todas las combinaciones de 64 bits, menos uno, con cero como punto fijo. Hace esto con esencialmente seis operaciones: tres desplazamientos binarios y tres operaciones XOR (o exclusivo), que son operaciones bit a bit. Los desplazamientos también son operaciones bit a bit.
Lo que vemos es que hay tres números mágicos en medio de eso: 13, 7 y 17. Por cierto, todos esos números son números primos; esto no es un accidente. Resulta que si eliges esas constantes muy específicas, obtienes un excelente generador de números aleatorios que resulta ser súper rápido. Cuando digo súper rápido, me refiero a que literalmente puedes generar 10 megabytes por segundo de números aleatorios. Esto es absolutamente enorme. Si volvemos a la conferencia anterior, podemos ver por qué este algoritmo también es tan eficiente. No solo tenemos solo seis instrucciones que se mapean directamente a instrucciones compatibles nativamente con el hardware informático subyacente, como el procesador, sino que tampoco tenemos ninguna rama. No hay ninguna prueba, y esto significa que este algoritmo, una vez ejecutado, aprovechará al máximo la capacidad de canalización del procesador porque no hay ramificación. Literalmente podemos aprovechar al máximo la capacidad de canalización profunda que tenemos en un procesador moderno. Esto es muy interesante.
La pregunta es, ¿podríamos elegir cualquier otro número para que funcione este algoritmo? La respuesta es no. Solo hay unas pocas docenas o tal vez alrededor de cien combinaciones diferentes de números que realmente funcionarían, y todas las demás te darán un generador de números de muy baja calidad. Ahí es donde está lo mágico. Verás, esta es una tendencia reciente en el desarrollo algorítmico, encontrar algo completamente inesperado donde encuentras una constante semi-mágica que te brinda beneficios completamente no deseados al mezclar operaciones binarias muy inesperadas de algún tipo. La generación de números aleatorios es de vital importancia para la cadena de suministro.
Pero, como estaba diciendo, las tablas hash están en todas partes, y también es de gran interés tener una función hash genérica de super alto rendimiento. ¿Existe? Sí. Ha habido clases enteras de funciones hash disponibles durante décadas, pero en 2019, se publicó otro algoritmo que ofrece un rendimiento sin precedentes. Este es el que puedes ver en la pantalla, “WyHash” de Wang Yi. Esencialmente, puedes ver que la estructura es muy similar al algoritmo XORShift. Es un algoritmo que no tiene ramificación, al igual que XORShift, y también utiliza la operación XOR. El algoritmo utiliza seis instrucciones: cuatro operaciones XOR y dos operaciones Multiply-No-Flags.
Multiply-No-Flags es simplemente la multiplicación básica entre dos enteros de 64 bits, y como resultado, recoges los 64 bits altos y los 64 bits bajos. Esta es una instrucción real disponible en los procesadores modernos, implementada a nivel de hardware, por lo que cuenta como una sola instrucción de computadora. Tenemos dos de ellas. Nuevamente, tenemos tres números mágicos, escritos en forma hexadecimal. Por cierto, esos son números primos, nuevamente, completamente semi-mágicos. Si aplicas este algoritmo, tienes una función hash no criptográfica absolutamente excelente que casi opera a la velocidad de memcpy. Es muy rápido y de gran interés.
Ahora, cambiemos a algo completamente diferente de nuevo. El éxito del deep learning y muchos otros métodos modernos de aprendizaje automático se basa en algunas ideas algorítmicas clave sobre los problemas que pueden ser acelerados masivamente por hardware de computación dedicado. Eso es de lo que hablé en mi conferencia anterior cuando hablaba de procesadores con instrucciones superescalares y, si quieres más, GPUs e incluso TPUs. Vamos a revisar esta idea para ver cómo surgió todo de manera bastante caótica. Sin embargo, creo que las ideas relevantes se han cristalizado en los últimos años. Para entender dónde nos encontramos hoy en día, tenemos que retroceder hasta la notación de Einstein, que fue introducida hace poco más de un siglo por Albert Einstein en uno de sus artículos. La intuición es simple: tienes una expresión y que es una suma desde i igual a 1 hasta i igual a 3 de c_y por x_y. Tenemos expresiones escritas de esa manera, y la intuición de la notación de Einstein es decir, en este tipo de situación, deberíamos escribirlo omitiendo por completo la suma. En términos de software, la suma sería un bucle for. La idea es omitir por completo la suma y decir que por convención, hacemos la suma en todos los índices para la variable i que tiene sentido.
Esta simple intuición produce dos resultados muy sorprendentes pero positivos. El primero es la corrección del diseño. Cuando escribimos explícitamente la suma, corremos el riesgo de no tener los índices adecuados, lo que puede llevar a errores de índice fuera de rango en el software. Al eliminar la suma explícita y afirmar que tomaremos todas las posiciones de índice válidas por definición, tenemos un enfoque correcto por diseño. Esto solo es de gran interés y está relacionado con la programación de matrices, un paradigma de programación del que hablé brevemente en una de mis conferencias anteriores.
La segunda idea, que es más reciente y de gran interés en la actualidad, es que si puedes escribir tu problema en la forma en que se aplica la notación de Einstein, tu problema puede beneficiarse de una aceleración masiva de hardware en la práctica. Esto es un cambio de juego.
Para entender por qué, hay un artículo muy interesante llamado “Tensor Comprehensions” publicado en 2018 por el equipo de investigación de Facebook. Introdujeron el concepto de comprensiones de tensores. Primero, permíteme definir las dos palabras. En el campo de la informática, un tensor es esencialmente una matriz multidimensional (en física, los tensores son completamente diferentes). Un valor escalar es un tensor de dimensión cero, un vector es un tensor de dimensión uno, una matriz es un tensor de dimensión dos, y puedes tener tensores con dimensiones aún más altas. Los tensores son objetos con propiedades similares a las matrices adjuntas a ellos.
La comprensión es algo parecido a un álgebra con las cuatro operaciones básicas: suma, resta, multiplicación y división, así como otras operaciones. Es más extenso que el álgebra aritmética regular; por eso tienen una comprensión de tensores en lugar de un álgebra de tensores. Es más completo pero no tan expresivo como un lenguaje de programación completo donde puedes hacer lo que quieras.
La idea es que si miras la función MV (def MV), es fundamentalmente una función, y MV significa matriz-vector. En este caso, es una multiplicación de matriz-vector, y esta función realiza una multiplicación entre la matriz A y el vector X. Vemos en esta definición que la notación de Einstein está en juego: escribimos C_i = A_ik * X_k. ¿Qué valores debemos elegir para i y k? La respuesta es todas las combinaciones válidas para esas variables que son índices. Tomamos todos los valores de índices válidos, hacemos la suma y, en la práctica, esto nos da una multiplicación de matriz-vector.
En la parte inferior de la pantalla, puedes ver el mismo método MV reescrito con bucles for, especificando explícitamente los rangos de valores. El logro clave del equipo de investigación de Facebook es que siempre que puedas escribir un programa con esta sintaxis de comprensión de tensores, han desarrollado un compilador que te permite beneficiarte ampliamente de la aceleración de hardware utilizando GPUs. Básicamente, te permiten acelerar cualquier programa que puedas escribir con esta sintaxis de comprensión de tensores. Siempre que puedas escribir un programa en esta forma, te beneficiarás de una aceleración de hardware masiva, y estamos hablando de algo que será dos órdenes de magnitud más rápido que un procesador regular. Este es un resultado impresionante por sí mismo.
Ahora veamos qué podemos hacer desde una perspectiva de la cadena de suministro con este enfoque. Un interés clave para la práctica moderna de la cadena de suministro es el pronóstico probabilístico. El pronóstico probabilístico, que abordé en una conferencia anterior, es la idea de que no vas a tener un pronóstico puntual, sino que vas a pronosticar todas las diversas probabilidades para una variable de interés. Consideremos, por ejemplo, un pronóstico de tiempo de entrega. Quieres pronosticar tu tiempo de entrega y tener un pronóstico de tiempo de entrega probabilístico.
Ahora supongamos que tu tiempo de entrega se puede descomponer en el tiempo de entrega de fabricación y el tiempo de entrega de transporte. En realidad, lo más probable es que tengas un pronóstico probabilístico para el tiempo de entrega de fabricación, que será una variable aleatoria discreta que te dará la probabilidad de observar un tiempo de un día, dos días, tres días, cuatro días, etc. Puedes pensar en ello como un gran histograma que te da las probabilidades de observar esta duración para el tiempo de entrega de fabricación. Luego tendrás un proceso similar para el tiempo de entrega de transporte, con otra variable aleatoria discreta que proporciona un pronóstico probabilístico.
Ahora quieres calcular el tiempo de entrega total. Si los tiempos de entrega pronosticados fueran números, simplemente harías una suma simple. Sin embargo, los dos tiempos de entrega pronosticados no son números; son distribuciones de probabilidad. Por lo tanto, tenemos que combinar estas dos distribuciones de probabilidad para obtener una tercera distribución de probabilidad, que es la distribución de probabilidad para el tiempo de entrega total. Resulta que si asumimos que los dos tiempos de entrega, tiempo de entrega de fabricación y tiempo de entrega de transporte, son independientes, la operación que podemos hacer para realizar esta suma de variables aleatorias es simplemente una convolución unidimensional. Puede sonar complejo, pero en realidad no es tan complejo. Lo que he implementado, y lo que puedes ver en la pantalla, es la implementación de una convolución unidimensional entre un vector que representa el histograma de las probabilidades del tiempo de entrega de fabricación (A) y el histograma asociado con las probabilidades del tiempo de entrega de transporte (B). El resultado es el tiempo total, que es la suma de esos tiempos de entrega probabilísticos. Si usas la notación de comprensión de tensores, esto se puede escribir en un algoritmo muy compacto de una sola línea.
Ahora, si volvemos a la notación Big O que introduje anteriormente en esta conferencia, vemos que tenemos fundamentalmente un algoritmo cuadrático. Es Big O de N^2, siendo N el tamaño característico de los arreglos para A y B. Como mencioné, el rendimiento cuadrático es un punto óptimo de los problemas de predicción. Entonces, ¿qué podemos hacer para abordar este problema? Primero, tenemos que considerar que este es un problema de la cadena de suministro, y tenemos la ley de los números pequeños que podemos usar a nuestro favor. Como discutimos en la conferencia anterior, las cadenas de suministro son predominantemente sobre números pequeños. Si estamos mirando los tiempos de entrega, podemos asumir razonablemente que esos tiempos de entrega serán más pequeños que, digamos, 400 días. Eso ya es bastante tiempo para este histograma de probabilidad.
Entonces, lo que nos queda es un Big O de N^2, pero con N menor que 400. 400 puede ser bastante grande, ya que 400 veces 400 es 160,000. Ese es un número significativo, y recuerda que agregar a esta distribución de probabilidad es una operación muy básica. Tan pronto como comencemos a hacer pronósticos probabilísticos, querremos combinar nuestros pronósticos de varias formas, y es muy probable que terminemos haciendo millones de estas convoluciones, simplemente porque fundamentalmente, estas convoluciones no son más que una suma glorificada proyectada en el ámbito de las variables aleatorias. Por lo tanto, incluso si hemos limitado N a ser menor que 400, es de gran interés llevar la aceleración de hardware a la mesa, y eso es precisamente lo que podemos lograr con la comprensión de tensores.
Lo importante es recordar que tan pronto como puedas escribir ese algoritmo, quieres aprovechar lo que sabes sobre los conceptos de la cadena de suministro para aclarar las suposiciones aplicables y luego aprovechar las herramientas que tienes para obtener aceleración de hardware.
Ahora, vamos a hablar de las técnicas meta. Las técnicas meta son de gran interés porque se pueden aplicar en capas superiores de los algoritmos existentes, y así, si tienes un algoritmo, existe la posibilidad de que puedas utilizar una de estas técnicas meta para mejorar su rendimiento. La primera idea clave es la compresión, simplemente porque datos más pequeños significan un procesamiento más rápido. Como hemos visto en la conferencia anterior, no tenemos acceso uniforme a la memoria. Si quieres acceder a más datos, debes acceder a diferentes tipos de memoria física, y a medida que la memoria crece, llegas a diferentes tipos de memoria que son mucho menos eficientes. La caché L1 dentro del procesador es muy pequeña, alrededor de 64 kilobytes, pero es muy rápida. La RAM, o memoria principal, es varias veces más lenta que esta pequeña caché, pero puedes tener literalmente un terabyte de RAM. Por lo tanto, es de gran interés asegurarse de que tus datos sean lo más pequeños posible, ya que esto casi invariablemente hará que tus algoritmos se ejecuten más rápido. Hay una serie de trucos que puedes utilizar en este sentido.
En primer lugar, puedes limpiar y ordenar tus datos. Esto es el ámbito del software empresarial. Cuando tienes un algoritmo que se ejecuta con datos, a menudo hay muchos datos no utilizados que no contribuyen a la solución de interés. Es esencial asegurarse de que no termines con los datos de interés entremezclados con datos que se ignoran.
La segunda idea es el empaquetado de bits. Hay muchas situaciones en las que puedes empaquetar algunas banderas dentro de otros elementos, como punteros. Es posible que tengas un puntero de 64 bits, pero es muy raro que realmente necesites un rango de dirección de 64 bits en su totalidad. Puedes sacrificar algunos bits de tu puntero para insertar algunas banderas, lo que te permite minimizar tus datos con casi ninguna pérdida de rendimiento.
Además, puedes ajustar tu precisión. ¿Necesitas 64 bits de precisión de punto flotante en la cadena de suministro? Es muy raro que realmente necesites esta precisión. Por lo general, 32 bits de precisión son suficientes, e incluso hay muchas situaciones en las que 16 bits de precisión son suficientes. Puede que pienses que reducir la precisión no es significativo, pero con frecuencia, cuando puedes dividir el tamaño de los datos por un factor de dos, no solo aceleras tu algoritmo en un factor de 2; literalmente lo aceleras en un factor de 10. El empaquetado de datos produce beneficios completamente no lineales en términos de velocidad de ejecución.
Por último, tienes la codificación de entropía, que es esencialmente compresión. Sin embargo, no necesariamente quieres utilizar algoritmos tan eficientes para comprimir como, digamos, el algoritmo utilizado para un archivo ZIP. Quieres algo que pueda ser un poco menos eficiente en términos de compresión pero mucho más rápido en la ejecución.
La compresión gira fundamentalmente en torno a la idea de que puedes intercambiar un poco de uso adicional de la CPU para disminuir la presión sobre la memoria, y en casi todas las situaciones, este es el truco de interés.
Sin embargo, hay situaciones en las que quieres hacer exactamente lo contrario: intercambiar memoria para reducir en gran medida el consumo de la CPU. Eso es precisamente lo que estás haciendo con el truco de la memorización. La memorización es fundamentalmente la idea de que si una función se llama muchas veces durante la ejecución de tu solución, y se llama a la misma función con las mismas entradas, no necesitas volver a calcular la función. Puedes registrar el resultado, ponerlo a un lado (por ejemplo, en una tabla hash) y cuando vuelvas a visitar la misma función, podrás verificar si la tabla hash ya contiene una clave asociada con la entrada o si la tabla hash ya contiene el resultado porque se ha precalculado. Si la función que estás memorizando es muy costosa, puedes lograr una gran aceleración. Donde se vuelve muy interesante es cuando comienzas a usar la memorización no con la memoria principal, como hemos visto en la conferencia anterior, la DRAM es muy costosa. Se vuelve muy interesante cuando comienzas a poner tus resultados en disco o SSD, que son baratos y abundantes. La idea es que puedes intercambiar SSD a cambio de una reducción de la presión de la CPU, que es, de alguna manera, lo contrario exacto de la compresión que acabo de describir.
La última meta-técnica es la inmutabilidad. Las estructuras de datos inmutables son fundamentalmente estructuras de datos que nunca se modifican. La idea es que los cambios se superponen. Por ejemplo, con una tabla hash inmutable, cuando agregas un elemento, lo que vas a devolver es una nueva tabla hash que contiene todo en la antigua tabla hash más el nuevo elemento. La forma muy ingenua de hacerlo es hacer una copia completa de la estructura de datos y devolver la copia completa; sin embargo, es muy ineficiente. La clave de las estructuras de datos inmutables es que cuando modificas la estructura de datos, devuelves una nueva estructura de datos que solo implementa el cambio, pero esta nueva estructura de datos recicla todas las partes de la antigua estructura de datos que no han sido modificadas.
Casi todas las estructuras de datos clásicas, como listas, árboles, grafos y tablas hash, tienen sus contrapartes inmutables. En muchas situaciones, es de gran interés utilizarlas. Por cierto, hay lenguajes de programación modernos que se han ido completamente hacia la inmutabilidad, como Clojure, por ejemplo, para aquellos de ustedes que puedan estar familiarizados con este lenguaje de programación.
¿Por qué es de gran interés? Primero, porque simplifica enormemente la paralelización de algoritmos. Como hemos visto en la conferencia anterior, no es posible encontrar un procesador que funcione a 100 GHz para procesadores de computadoras de escritorio generales. Lo que puedes encontrar, sin embargo, es una máquina con 50 núcleos, cada núcleo funcionando a 2 GHz. Si quieres aprovechar esos muchos núcleos, debes paralelizar tu ejecución, y luego tu paralelización corre el riesgo de tener errores muy desagradables llamados condiciones de carrera. Se vuelve muy difícil entender si el algoritmo que has escrito es correcto o no porque puedes tener varios procesadores que, al mismo tiempo, intentan escribir en la misma parte de la memoria de la computadora.
Sin embargo, si tienes estructuras de datos inmutables, esto nunca sucede por diseño, simplemente porque una vez que se presenta una estructura de datos, nunca cambiará, solo surgirá una nueva estructura de datos. Por lo tanto, puedes lograr una mejora masiva en el rendimiento con el enfoque inmutable simplemente porque puedes implementar más fácilmente versiones paralelas de tus algoritmos. Ten en cuenta que por lo general, el cuello de botella para implementar mejoras en el rendimiento algorítmico es el tiempo que lleva implementar los algoritmos. Si tienes algo que, por diseño, te permite aplicar algún tipo de principio de concurrencia sin miedo, puedes implementar mejoras en el rendimiento algorítmico mucho más rápido, con menos recursos en términos del número de programadores involucrados. Otro beneficio importante de las estructuras de datos inmutables es que facilitan en gran medida la depuración. Cuando modificas destructivamente una estructura de datos y encuentras un error, puede ser muy difícil entender cómo llegaste allí. Con un depurador, puede ser una experiencia bastante desagradable encontrar el problema. Lo interesante de las estructuras de datos inmutables es que los cambios no son destructivos, por lo que puedes ver la versión anterior de tu estructura de datos y comprender más fácilmente cómo llegaste al punto donde te enfrentas a algún tipo de comportamiento incorrecto.
En conclusión, mejores algoritmos pueden sentirse como superpoderes. Con mejores algoritmos, obtienes más del mismo hardware informático, y esos beneficios son indefinidos. Es un esfuerzo único y luego tienes un potencial indefinido porque has obtenido acceso a capacidades de cálculo superiores, considerando la misma cantidad de recursos informáticos dedicados a un determinado problema de la cadena de suministro de interés. Creo que esta perspectiva ofrece oportunidades para mejoras masivas en la gestión de la cadena de suministro.
Si miramos un campo completamente diferente, como los videojuegos, han establecido sus propias tradiciones algorítmicas y hallazgos dedicados a la experiencia de juego. Los impresionantes gráficos que experimentas con los videojuegos modernos son el producto de una comunidad que pasó décadas repensando todo el conjunto de algoritmos para maximizar la calidad de la experiencia de juego. La perspectiva en los videojuegos no es tener un modelo 3D que sea correcto desde una perspectiva física o científica, sino maximizar la calidad percibida en términos de la experiencia gráfica para el jugador, y han ajustado los algoritmos para lograr resultados impresionantes.
Creo que este tipo de trabajo apenas ha comenzado para las cadenas de suministro. El software empresarial de la cadena de suministro está estancado y, en mi percepción, no estamos utilizando ni siquiera el 1% de lo que el hardware informático moderno puede hacer por nosotros. La mayoría de las oportunidades están por delante y se pueden capturar a través de algoritmos, no solo algoritmos de cadena de suministro como algoritmos de enrutamiento de vehículos, sino también al revisar algoritmos clásicos desde una perspectiva de cadena de suministro para lograr mejoras masivas en el camino.
Ahora, echaré un vistazo a las preguntas.
Pregunta: Has estado hablando de las especificidades de la cadena de suministro, como los números pequeños. Cuando sabemos de antemano que tenemos números pequeños en nuestras decisiones potenciales, ¿qué tipo de simplificación trae esto? Por ejemplo, cuando sabemos que podemos pedir uno o dos contenedores como máximo, ¿puedes pensar en ejemplos concretos de cómo esto influiría en el nivel de granularidad de las previsiones holísticas que se utilizarán para calcular la función de recompensa de stock?
En primer lugar, todo lo que he presentado hoy está en producción en Lokad. Todas estas ideas, de una forma u otra, son muy aplicables a la cadena de suministro porque están en producción en Lokad. Debes darte cuenta de que lo que obtienes de un software moderno es algo que no ha sido ajustado para aprovechar al máximo el hardware de computación. Solo piensa que, como presenté en mi última conferencia, hoy en día tenemos computadoras que son mil veces más capaces que las computadoras que teníamos hace unas décadas. ¿Funcionan mil veces más rápido? No lo hacen. ¿Pueden abordar problemas que son fantásticamente más complicados que los que teníamos hace unas décadas? No lo hacen. Así que no subestimes el hecho de que hay grandes potenciales de mejora.
El ordenamiento de cubetas que he presentado en esta conferencia es un ejemplo sencillo. Hay operaciones de ordenamiento por todas partes en la cadena de suministro, y según mi conocimiento, es muy raro que tengas algún software empresarial que aproveche algoritmos especializados que se ajusten bien a situaciones de cadena de suministro. Ahora, cuando sabemos que tenemos uno o dos contenedores, ¿aprovechamos esos elementos en Lokad? Sí, lo hacemos todo el tiempo, y hay un montón de trucos que se pueden implementar a ese nivel.
Los trucos suelen estar a un nivel inferior, y los beneficios simplemente se propagarán a la solución general. Debes pensar en descomponer los problemas de llenado de contenedores en todas sus subpartes. Puedes obtener beneficios aplicando las ideas y trucos que he presentado hoy a un nivel inferior.
Por ejemplo, ¿qué tipo de precisión numérica necesitas si estamos hablando de contenedores? Tal vez números de 16 bits con solo 16 bits de precisión sean suficientes. Eso hace que los datos sean más pequeños. ¿Cuántos productos distintos estamos ordenando? Tal vez solo estamos ordenando unos pocos miles de productos distintos, por lo que podemos usar el ordenamiento de cubetas. La distribución de probabilidad es un número menor y más pequeño, por lo que en teoría, tenemos histogramas que pueden ir desde cero unidades, una unidad, tres unidades, hasta el infinito, pero ¿vamos hasta el infinito? No, no lo hacemos. Tal vez podamos hacer algunas suposiciones inteligentes sobre el hecho de que es muy raro que nos enfrentemos a un histograma donde superemos las 1,000 unidades. Cuando tenemos eso, podemos aproximar. No necesariamente necesitamos tener una precisión de 2 unidades si estamos tratando con un contenedor que contiene 1,000 unidades. Podemos aproximar y tener un histograma con cubetas más grandes y este tipo de cosas. No se trata tanto, diría yo, de introducir principios algorítmicos como la comprensión de tensores, que son increíbles porque simplifican todo de una manera muy genial. Sin embargo, la mayoría de las mejoras algorítmicas en el resultado final resultan en un algoritmo más rápido pero ligeramente más complicado. No necesariamente es más simple porque generalmente, el algoritmo más simple también es algo ineficiente. Un algoritmo más apropiado para un caso podría ser un poco más largo de escribir y más complejo, pero al final, se ejecutará más rápido. Esto no siempre es el caso, como hemos visto con las recetas mágicas, pero lo que quería mostrar era que necesitamos revisar los bloques de construcción fundamentales de lo que estamos haciendo para construir realmente software empresarial.
Pregunta: ¿En qué medida se implementan estos conocimientos en los proveedores de ERP, APS y los mejores de su clase como GTA?
Lo interesante es que estos conocimientos son fundamentalmente, la mayoría de ellos, completamente incompatibles con el software transaccional. La mayoría del software empresarial se construye en torno a una base de datos transaccional, y todo se canaliza a través de la base de datos. Esta base de datos no es una base de datos específica de la cadena de suministro; es una base de datos genérica que se supone que puede manejar todas las situaciones posibles que puedas imaginar, desde finanzas hasta computación científica, registros médicos y más.
El problema es que si el software que estás analizando tiene una base de datos transaccional en su núcleo, entonces los conocimientos que he propuesto no se pueden implementar por diseño. Es como si el juego hubiera terminado. Si miras los videojuegos, ¿cuántos videojuegos se construyen sobre una base de datos transaccional? La respuesta es cero. ¿Por qué? Porque no puedes tener un buen rendimiento gráfico implementado sobre una base de datos transaccional. No puedes hacer gráficos por computadora en una base de datos transaccional.
Una base de datos transaccional es muy buena; te brinda transaccionalidad, pero te encierra en un mundo donde casi todas las mejoras algorítmicas que puedas pensar simplemente no se pueden aplicar. Creo que cuando comenzamos a pensar en APS, no hay nada avanzado en estos sistemas. Han estado estancados en el pasado durante décadas y están estancados porque en el núcleo de su diseño están completamente diseñados alrededor de una base de datos transaccional que les impide aplicar cualquiera de los conocimientos que han surgido del campo de los algoritmos en las últimas cuatro décadas, probablemente.
Esa es la esencia del problema en el campo del software empresarial. Las decisiones de diseño que tomes en el primer mes del diseño de tu producto te perseguirán durante décadas, esencialmente hasta el fin de los tiempos. No puedes actualizar una vez que hayas decidido un diseño específico para tu producto; estás atrapado con él. Al igual que no puedes simplemente reingenierizar un automóvil para que sea un automóvil eléctrico, si quieres tener un automóvil eléctrico muy bueno, reingeniarás todo el automóvil en torno a la idea de que el motor de propulsión será eléctrico. No se trata simplemente de cambiar el motor y decir: “Aquí tienes un automóvil eléctrico”. No funciona así. Este es uno de esos principios de diseño fundamentales donde una vez que te hayas comprometido a producir un automóvil eléctrico, debes repensar todo en torno al motor para que sea compatible. Desafortunadamente, los ERPs y APS que se centran mucho en las bases de datos simplemente no pueden utilizar ninguno de estos conocimientos, me temo. Siempre es posible tener una burbuja aislada donde te beneficies de estos trucos, pero será un complemento añadido; nunca llegará al núcleo.
En cuanto a las impresionantes capacidades de Blue Yonder, por favor, ten paciencia, ya que Lokad es un competidor directo de Blue Yonder, y me resulta difícil ser completamente imparcial. En el mercado de software empresarial, tienes que hacer afirmaciones ridículamente audaces para mantenerte competitivo. No estoy convencido de que haya sustancia en ninguna de esas afirmaciones. Cuestiono la premisa de que alguien en este mercado tenga algo que calificaría como impresionante.
Si quieres ver algo impresionante y ultra impresionante, mira la última demostración del Unreal Engine o los algoritmos especializados de videojuegos. Considera los gráficos por computadora en el hardware de próxima generación PlayStation 5; es absolutamente impresionante. ¿Tenemos algo en el mismo nivel de logro tecnológico en el campo del software empresarial? En lo que respecta a Lokad, tengo una opinión muy sesgada, pero al mirar el mercado de manera más general, veo un océano de personas que han estado tratando de maximizar las bases de datos relacionales durante décadas. A veces traen otros tipos de bases de datos, como bases de datos de grafos, pero eso se pierde por completo el punto de los conocimientos que he presentado. No proporciona nada sustancial para brindar valor al mundo de la cadena de suministro.
El mensaje clave aquí para la audiencia es que es una cuestión de diseño. Debemos asegurarnos de que las decisiones iniciales que se tomaron en el diseño de su software empresarial no sean el tipo de cosas que, por diseño, impidan que se utilicen estas clases de técnicas en primer lugar.
La próxima conferencia se llevará a cabo dentro de tres semanas, el miércoles a las 3 p.m. hora de París. Será el 13 de junio y revisaremos el tercer capítulo, que trata sobre el personal de la cadena de suministro, rasgos de personalidad sorprendentes y empresas ficticias. La próxima vez, hablaremos sobre queso. ¡Nos vemos entonces!
