00:15 Introducción
02:28 Nevera inteligente
05:28 Sesgo de supervivencia
07:28 La historia hasta ahora
08:46 Sobre tabúes (resumen)
12:06 Heurísticas de rechazo (resumen)
13:34 Conocimiento positivo de baja calidad
15:27 Antipatterns de software, 1/2
20:11 Antipatterns de software, 2/2
25:34 Antipatterns de supply chain
27:00 Forecasts desnudos
32:36 El nivel de servicio al 100%
37:06 La iniciación Jedi
44:31 El horror no euclidiano
51:45 El abogado del diablo
57:35 Resumen, conocimiento negativo para supply chain
01:01:04 Conclusión
01:02:45 Próxima conferencia y preguntas de la audiencia
Descripción
Los antipatterns son los estereotipos de soluciones que se ven bien pero no funcionan en la práctica. El estudio sistemático de antipatterns fue pionero a finales de los años 90 por el campo de la ingeniería de software. Cuando son aplicables, los antipatterns son superiores a los resultados negativos sin procesar, ya que son más fáciles de memorizar y razonar. La perspectiva de antipatterns es de suma relevancia para supply chain, y debe considerarse como uno de los pilares para su conocimiento negativo.
Transcripción completa
Hola a todos, bienvenidos a esta serie de conferencias de supply chain. Soy Joannes Vermorel, y hoy presentaré conocimiento negativo en supply chain. Para aquellos de ustedes que están viendo la conferencia en vivo, pueden hacer preguntas en cualquier momento a través del chat de YouTube. No estaré leyendo el chat durante la conferencia; sin embargo, volveré al chat al final de la conferencia para la sesión de preguntas y respuestas.
Hoy, el tema de interés es lo que una empresa realmente gana al contratar a un director de supply chain con quizás dos o tres décadas de experiencia. ¿Qué es lo que la empresa busca, y podríamos, en cierta medida, replicar la adquisición de esta experiencia en un periodo de tiempo mucho más corto? De eso trata exactamente el conocimiento negativo.
Cuando observamos a una persona con mucha experiencia, alguien que ha trabajado durante dos décadas en un campo, ¿realmente esperamos que esta persona replique soluciones, procesos o tecnologías que implementó hace una o dos décadas en otras empresas? Probablemente no. Aunque podría suceder marginalmente, sospecho que, en general, esa es una razón muy periférica en el mejor de los casos.
Cuando buscas a una persona con mucha experiencia, el objetivo no es necesariamente replicar las cosas tal como se hicieron en el pasado. El valor clave que deseas adquirir es contar con alguien que sepa cómo evitar todo tipo de errores y tenga la experiencia para asegurar que muchas ideas muy ingenuas y malas no se implementen en tu empresa. Existe el dicho de que en teoría, la práctica y la teoría son lo mismo, pero en la práctica, no lo son. Ese es exactamente el meollo del conocimiento negativo.
Mi propuesta para ustedes es que las malas ideas de negocio están por todas partes. Cuando digo malas, me refiero a ideas que, de ser implementadas, resultarían completamente poco rentables para la empresa. Para ilustrar esto, acabo de ingresar la consulta “smart refrigerators” en el motor de búsqueda de Google Patents. Google Patents es un motor de búsqueda especializado proporcionado por Google, y se puede buscar en una base de datos de patentes. Y he aquí, obtenemos 130,000 resultados de patentes presentadas sobre neveras inteligentes.
Se debe tomar este número con escepticismo, ya que probablemente hay muchos duplicados. Sin embargo, una inspección superficial de los resultados indica que, muy claramente, tenemos varias centenas, si no varios miles de empresas que, durante las últimas décadas, se esforzaron en realizar investigación y desarrollo para presentar una patente sobre neveras inteligentes. Cuando observas el tipo de ideas presentes en esas patentes, verás que siempre es una combinación de tomar este electrodoméstico tan ubicuo, una nevera, y añadirle algo, como electrónica barata. Combinamos ambos, y voilà, obtenemos una solución de algún tipo.
¿Para qué tipo de problema, entonces? Es muy poco claro. Sólo para dar una idea de la mayoría de las patentes, es el tipo de idea en la que, si tienes una nevera que posee algún tipo de sensores, la misma nevera va a detectar si te estás quedando sin leche y automáticamente realizará un reorder para ti. Estamos en 2021, y hasta donde yo sé, las neveras inteligentes son inexistentes. No es que no sean técnicamente factibles – de hecho, lo son. Es solo que literalmente no hay mercado para ellas. Así, tenemos una cantidad masiva de soluciones en el mercado buscando un problema. Durante las últimas dos décadas, creo haber presenciado, en promedio, dos veces al año, una startup promoviendo algún tipo de nevera inteligente. Curiosamente, nunca recibí respuesta de ninguna de esas startups. No seguí un seguimiento detallado, pero sospecho firmemente que cada startup que he visto promocionando una nevera inteligente durante las últimas dos décadas ha fracasado. Sin embargo, aunque la idea está muy extendida y es popular, como lo demuestran esos miles de patentes, las consecuencias de esas ideas, que son malas porque probablemente la mayoría de esas startups simplemente se declaró en bancarrota, no se propagaron.
Aquí, vemos algo muy interesante: a través de la experiencia, puedes acceder a un tipo de conocimiento que no está fácilmente accesible para los observadores en el mercado. Puedes ver el lado oscuro, que son las cosas que faltan, el tipo de cosas que se prometieron y difundieron, pero que no resultaron ser muy exitosas.
Hay un ejemplo histórico muy notable de la Segunda Guerra Mundial. El Ejército de EE.UU. realizó una encuesta en aviones que regresaban a la base para recolectar la ubicación de los impactos de bala en los aviones. Lo que ves en la pantalla era, esencialmente, la recopilación de la ubicación de las balas como se observaba en los aviones que regresaban de los campos de batalla a la base. Inicialmente, los oficiales del ejército seguían la línea de pensamiento de que necesitaban agregar placas de blindaje en las áreas que recibían más impactos, las áreas que obviamente estaban bajo el mayor fuego durante la batalla.
Entonces, otro caballero, Abraham Wald, dijo que no, esto es exactamente lo contrario. La cuestión es que lo que ves son los aviones que lograron regresar a la base. Lo que no ves es que, en todas las áreas donde no se observan impactos de bala, es muy probable que, cuando hubo un impacto en esa área, resultó ser letal ya sea para el avión, para la tripulación o ambos. Por lo tanto, si debes agregar alguna placa de blindaje, debes hacerlo precisamente en todas las áreas donde no ves aviones regresando a la base con impactos de bala. Esas son las áreas que necesitan protección.
Lo que Abraham señaló es que existía un fenómeno conocido como sesgo de supervivencia, donde lo que observas son esencialmente los sobrevivientes, no todos los aviones que no lograron regresar a la base. La idea del conocimiento negativo es exactamente así: tomas esta fotografía y su negativo, y es el resto lo que realmente debe captar tu atención porque ahí es donde suceden las cosas realmente malas. Esa es la esencia, diría yo, del conocimiento negativo.
Esta es la cuarta conferencia de mi serie de conferencias, la primera conferencia del segundo capítulo. En el primer capítulo del prólogo, presenté mis puntos de vista sobre supply chain, tanto en el campo de estudio como en la práctica. Lo que hemos visto es que supply chain es, esencialmente, una colección de problemas intratables, en contraposición a problemas mansos. Los wicked problems son muy difíciles de abordar porque no se prestan a estudios o prácticas sencillas. Fundamentalmente, hay algo adverso en términos de estudio y práctica con los wicked problems. Por eso, el segundo capítulo está dedicado a las metodologías.
En esta conferencia, estamos adoptando un enfoque cualitativo, tal como hicimos con la persona de supply chain, que fue la primera conferencia de este capítulo. Ampliaremos sobre el tipo de enfoques cualitativos que podemos tener para ofrecer mejoras a supply chain de manera controlada, confiable y, potencialmente, medible.
Resumen: Aunque esta es una conferencia dedicada al conocimiento negativo, no es la primera vez en esta serie de conferencias que toco elementos que calificarían como fragmentos de conocimiento negativo. Durante la primera conferencia de este segundo capítulo sobre las personas de supply chain, presenté mis puntos de vista sobre los estudios de caso. Dije que los estudios de caso positivos, es decir, aquellos que muestran resultados positivos asociados con una solución de interés, vienen acompañados de enormes conflictos de interés que minan completamente cualquier confianza que pudiéramos tener en la validez de los resultados. Por otro lado, afirmé que los estudios de caso negativos están bien, porque esos conflictos de interés, aunque puedan estar presentes, son mucho menos intensos.
En esta conferencia sobre las personas de supply chain, presenté un fantástico estudio de caso negativo, “The Last Days of Target Canada” por Joe Castaldo, que detalló un fallo de supply chain a escala épica que finalmente llevó a la bancarrota de Target Canada. Este es una especie de conocimiento negativo, donde el objeto de estudio es, literalmente, aquello que no funcionó, en contraposición a lo que podemos hacer para obtener algo que realmente funcione.
Ahora bien, ¿podríamos usar los estudios de caso negativos como una práctica fundamental para nuestro conocimiento negativo de supply chain? Yo diría que en su mayoría no, por dos razones muy distintas. La primera razón es simplemente que los estudios de caso negativos son extremadamente raros. Supongo, sólo como una estimación, que en realidad hay más de 100 veces más patentes sobre neveras inteligentes, que son completamente inútiles, de las que hay estudios de caso negativos sobre supply chain. Así, tenemos un problema muy práctico: aunque esos estudios de caso negativos son de suma relevancia y de altísimo interés científico, simplemente resultan ser extremadamente escasos. Tenemos tan poco de ellos que es muy difícil utilizar este material como la base de nuestro conocimiento negativo para supply chain.
El segundo problema es la inteligibilidad. Esos estudios de caso negativos, como el fantástico artículo “The Last Days of Target Canada,” muestran que hay docenas de problemas ocurriendo al mismo tiempo, y todos esos problemas están completamente entrelazados para finalmente conducir a un fallo épico. La cuestión es que esos estudios de caso son, literalmente, la vida real en acción, y esos eventos son muy complejos. Es difícil comunicar y razonar sobre esos estudios de caso porque los detalles importan, y son muy densos. Existe un problema más mundano: ¿cómo se comunica eso a una audiencia más amplia?
En mi última conferencia sobre optimización experimental, también vimos otro tipo de conocimiento negativo: las heurísticas de rechazo. Esencialmente, estos eran trucos simples que se pueden usar cuando se presenta una propuesta en términos de una solución cuantitativa como candidata potencial para la mejora de tu supply chain. Puedes utilizar una serie de heurísticas o reglas simples para descartar soluciones que, con un grado muy alto de certeza, simplemente no funcionarán. Sin embargo, aquí tenemos un problema de escalabilidad. Estas heurísticas solo funcionan porque son oscuras. Si llegaran a ser bien conocidas entre los círculos de supply chain, tanto los artículos científicos como el supply chain software se adaptarían y cambiarían su discurso, haciendo la situación más confusa. Esas heurísticas son muy eficientes, pero si llegaran a volverse populares, aún retendrían su validez, pero perderían su eficiencia como filtros, simplemente porque la gente prestaría atención para encontrar maneras de eludir esas heurísticas.
Por eso, estas heurísticas, aunque muy interesantes, no pueden usarse como base para el conocimiento negativo que queremos constituir para supply chain.
Además, no debemos confundir el conocimiento negativo con el conocimiento positivo de baja calidad. La diferencia es, en realidad, una cuestión de intención. Por ejemplo, la intención de los safety stocks es proporcionar a las empresas una forma controlada de impulsar la calidad del servicio que recibirán. La intención es positiva; es una solución para algo que debería funcionar. Ahora, la realidad es que el modelo de safety stock se basa en suposiciones completamente abusivas: se asume que la future demand y los lead times se distribuyen normalmente, aunque estas suposiciones son erróneas de hecho. Nunca he observado ningún conjunto de datos de supply chain en el que la demanda o los lead times se distribuyeran normalmente. Las distribuciones de interés están, en realidad, distribuidas según Zipf, como abordé en mis conferencias anteriores sobre los principios cuantitativos para supply chain. Desde una perspectiva adecuada, el safety stock queda refutado, pero no obstante, el safety stock está definitivamente anclado en el ámbito del conocimiento positivo, aunque se podría argumentar que es un conocimiento positivo de muy baja calidad.
Durante esta conferencia, no tendremos tiempo para profundizar en todos los elementos que, desde mi perspectiva, califican como conocimiento positivo de muy baja calidad, pero estaría encantado de ayudar si algunas personas desean hacerme preguntas sobre alguno de esos elementos durante la sesión de Q&A.
En lo que respecta al conocimiento negativo real de interés práctico, existe un libro llamado “Anti-Patterns: Refactoring Software, Architectures, and Projects in Crisis” que es un hito en la historia de la ingeniería de software. Publicado en 1998, este libro comienza con una observación casual de que en la industria del software, cuando hay buenas ideas y proyectos que aprovechan las buenas ideas, los proveedores de software ven cómo las buenas ideas son consumidas por el éxito del proyecto. Los autores cuestionan si una buena idea continúa siendo una buena práctica después de implementar el producto, y la respuesta es esencialmente no. Existe una ventaja de ser el primero en moverse que es muy específica de la industria del software y, como resultado, tenemos un problema. Prácticamente, cualquier conjunto de reglas que usarías para predecir el éxito de algo en la industria del software se vuelve autoderrotante, debido a que los mejores enfoques tienden a ser consumidos por el éxito que generan. Los autores de “Anti-Patterns” notaron que, en su opinión, es casi imposible garantizar el éxito de una iniciativa de software. Sin embargo, también observaron que la situación es muy asimétrica cuando se trata de fracasos. Comentaron que es posible predecir, con un grado de confianza muy alto (a veces rozando la certeza), que un determinado proyecto está a punto de fracasar. Esto es muy interesante porque no se puede garantizar el éxito, pero sí se puede contar con algo parecido a una ciencia que garantice el fracaso. Mejor aún, este conocimiento de elementos que garantizan el fracaso parece ser extraordinariamente estable a lo largo del tiempo y muy independiente de las particularidades técnicas de la empresa o del sector que se considere.
Si volvemos a la idea inicial del refrigerador inteligente, podemos ver que todas esas patentes de refrigeradores inteligentes son increíblemente diversas en las soluciones que presentan. Pero resulta que todas esas patentes de refrigeradores inteligentes conducen a fracasos empresariales porque todas encajan en la misma categoría: una solución en busca de un problema. La combinación de un electrodoméstico ubicuo con electrónica barata crea una solución, pero ¿es algo que realmente tiene sentido? En este caso, casi nunca.
Los autores de “Anti-Patterns” comenzaron su camino estudiando las causas fundamentales detrás de los fracasos de software e identificaron los siete pecados capitales de la ingeniería de software, que son la prisa, la apatía, la mente cerrada, la avaricia, la ignorancia, el orgullo y la envidia. Estos problemas serán independientes del contexto y de las tecnologías involucradas porque son invariantes de la propia naturaleza humana. Al buscar un director de supply chain con dos décadas de experiencia, se tratará de alguien que simplemente ha vivido más tiempo y ha interiorizado la mayoría de los problemas que surgen cuando hay humanos involucrados, con todo tipo de fallas.
La idea de los autores es que es bueno formalizar este conocimiento para hacerlo más digerible e inteligible, de modo que sea más fácil comunicar y razonar sobre estos problemas. Esa es la esencia de los anti-patterns: un formato para capturar fragmentos de conocimiento negativo.
En su libro, los autores presentan una plantilla para un anti-pattern, que comienza con un nombre llamativo que es fácil de recordar. Es necesario caracterizar la escala, ya sea a nivel de código fuente, a nivel de arquitectura de software, a nivel de empresa o a nivel de industria. Se quiere identificar las verdaderas causas fundamentales y las consecuencias que normalmente se asocian con ellas. Se desea caracterizar las fuerzas en juego, los síntomas y las consecuencias no intencionadas que la gente no espera, las cuales socavarán por completo los beneficios esperados de la solución inicial.
Los autores argumentan que es necesario presentar evidencia anecdótica, y por eso utilizan empresas ficticias en sus anti-patterns. Esto se hace para evitar los tabúes involucrados en discutir sobre empresas reales y personas reales, lo que podría impedir que se establezca una comunicación honesta. La plantilla del anti-pattern debe concluir con una solución refactorizada, que es un camino para transformar lo que es esencialmente una solución equivocada en una variante de esa solución que realmente funcione en el mundo real, donde las consecuencias no intencionadas se mitiguen e, idealmente, se eliminen.
Esta conferencia no trata sobre anti-patterns de supply chain, sino simplemente de dar dos ejemplos de anti-patterns de software que quizás hayas escuchado; el primero es el Martillo Dorado. El Martillo Dorado es la idea de que cuando tienes un martillo dorado en la mano, todo lo demás es un clavo. Este anti-pattern establece esencialmente que si le preguntas a un programador de Java cómo abordaría un nuevo problema, probablemente sugerirá escribir un programa en Java para resolver ese problema. Si le presentas otro problema a la misma persona, ésta dirá que ese otro problema también podría resolverse con un programa en Java. Si presentas 20 problemas diferentes, cada vez la respuesta será: “Creo que un programa en Java estaría bien.” Este es un sesgo masivo en el que las personas con experiencia en una determinada tecnología tienden a reciclar su conocimiento técnico para resolver nuevos problemas, en lugar de tomarse el tiempo para evaluar si su conocimiento es realmente relevante, técnicamente hablando, para abordar el nuevo problema. Es mucho más fácil intelectualmente simplemente recurrir a lo que realmente sabes.
Otro es la Parálisis por Análisis. En el mundo del software, existen muchas situaciones en las que las posibilidades son infinitas, y es tentador decir: “En lugar de probar 20 enfoques diferentes que van a fallar, reflexionemos intensamente sobre el diseño, y una vez que estemos absolutamente seguros de que tenemos la solución correcta en mente, implementaremos la solución.” Desafortunadamente, esto es muy difícil de ejecutar y, generalmente, conduce a la parálisis por análisis, donde se dedica más tiempo y esfuerzo a considerar toneladas de opciones potenciales en lugar de simplemente probar una solución y ver si funciona o no.
Ahora, obviamente, hemos hablado de que este libro trataba sobre anti-patterns de software, y creo que la ingeniería de software tiene muchas similitudes con los problemas que enfrentamos en supply chain, especialmente en la optimización de supply chain. Ambos campos son esencialmente colecciones de problemas complejos, y el supply chain moderno trata en gran medida sobre la entrega de un producto de software. Por lo tanto, existe un cierto grado de superposición entre los problemas de supply chain y los problemas de ingeniería de software, pero estos dos campos no están completamente a años luz de distancia.
Aquí, presentaré cinco anti-patterns de supply chain, que se pueden encontrar por escrito en el sitio web de Lokad, con una presentación más extensa disponible para los interesados.
El primero es Naked Forecast. Inspirado en el cuento “El traje nuevo del emperador” de Hans Christian Andersen, el contexto es una empresa con una iniciativa en curso para mejorar la precisión del forecast. Algunos síntomas incluyen forecasts de larga data de los que todos se quejan —producción, marketing, ventas, compras e incluso supply chain, siendo que la división de forecast suele formar parte de supply chain. Se han hecho intentos para mejorar la precisión del forecast durante las últimas una o dos décadas, pero parece que, sin importar cuánto esfuerzo se invierta en el caso, hay una serie interminable de excusas por parte de los encargados del forecast para justificar su pobre precisión.
La cuestión es que existe esta siguiente iniciativa en la que la intención es poner en orden la precisión del forecast, para solucionar de una vez por todas este problema de forecast inexacto. Ahí es donde entra en juego el anti-pattern Naked Forecast. Las consecuencias no intencionadas de esto son, en primer lugar, que no va a entregar forecasts más precisos de manera significativa. En segundo lugar, emprender una nueva iniciativa va a crear una organización aún más bizantina, donde lo que comenzó como una práctica diminuta para entregar el forecast se hace cada vez más complejo, con más personas involucradas en la producción de esos forecasts. Con el tiempo, terminas con algo que sigue siendo tan inexacto como siempre, pero que ha pasado de ser algo modesto e inexacto a una gran burocracia que sigue siendo tan inexacta como siempre.
Creo que la causa raíz aquí es lo que yo llamo el racionalismo ingenuo o la ilusión de la ciencia. Cuando esta iniciativa comienza, el problema se presenta como si fuera perfectamente objetivo: “Vamos a producir forecasts más accurados de acuerdo con una métrica, digamos, el error absoluto medio.” Todo parece muy directo, con un problema bien definido. Sin embargo, el problema es que todo eso es muy ingenuo, ya que no existe una correlación directa entre la precisión del forecast y la rentabilidad de la empresa. Lo que se debería buscar son maneras de mejorar la rentabilidad de la empresa, por lo que se debe pensar en términos de dólares o euros de error, no en porcentajes de error.
Fundamentalmente, la causa raíz es que estos forecasts son independientes y no reciben ninguna retroalimentación del negocio real. La precisión del forecast es solo un artefacto numérico; no representa un retorno de inversión real y tangible para la empresa. Como dato anecdótico, si hubiera recibido un cheque extra de mil dólares cada vez que tuve una conversación telefónica con un director de supply chain que me dijera que estaban iniciando una nueva iniciativa para mejorar la precisión del forecast, sería un hombre aún más rico.
La conclusión es que, en términos de solución refactorizada, mientras los forecasts sean naked, no van a funcionar. Tienes que vestirlos, y esa vestimenta son las decisiones. Como exploramos en la conferencia anterior con la optimización experimental, si los forecasts no están directamente conectados a decisiones reales y tangibles, tales como cuánto comprar, cuánto producir o si se deben subir o bajar los precios, nunca se obtiene la retroalimentación real que importa. La verdadera retroalimentación que importa no es el KPI del back-test en la medición; lo que importa son esas decisiones. Así, en términos de solución refactorizada para abordar el anti-pattern Naked Forecast, básicamente se trata de decidir que las mismas personas que generan el forecast deben vivir con las consecuencias de esos forecasts cuando se trata de las decisiones de supply chain que se implementan a partir de él.
El segundo sería el Mítico Nivel de Servicio del 100% Service Level. La situación típicamente comienza de la siguiente manera: se reúne el directorio y, en algún lugar de la prensa o en las redes sociales, algunas personas se quejan en voz alta sobre la calidad del servicio. No pinta bien para la empresa, ya que parece que no está cumpliendo las promesas que hizo. El directorio ejerce una enorme presión sobre el CEO para que haga algo respecto a este problema de calidad del servicio, que está afectando negativamente la marca, la imagen y, potencialmente, el crecimiento de la empresa. El CEO dice, “Realmente necesitamos poner fin a estas interminables series de problemas de calidad del servicio.” Entonces, el CEO recurre al VP de Supply Chain y le pide que solucione estos problemas de calidad del servicio. El VP de Supply Chain, a su vez, le pide al Director de Supply Chain que haga lo mismo, y el Director de Supply Chain le solicita al Gerente de Supply Chain que aborde el problema. Luego, el Gerente de Supply Chain aumenta el nivel de servicio hasta algo muy alto, cercano al 100%.
Y he aquí que, incluso si a corto plazo terminas con niveles de servicio marginalmente más altos, muy pronto los problemas de calidad del servicio regresan. Estos niveles de servicio más altos no son sostenibles, y terminas con fluctuaciones en el inventario, inventario desperdiciado y, aunque la intención fue aumentar el nivel de servicio, frecuentemente obtienes niveles de servicio más bajos a los seis o doce meses.
La causa raíz aquí no es solo la ignorancia, sino también el pensamiento ilusorio. Matemáticamente hablando, si deseas un nivel de servicio del 100%, significa una cantidad infinita de inventario, lo cual técnicamente no es posible. Tienes ese poderoso pensamiento ilusorio de que puedes abordar completamente este problema, aunque no es posible. En el mejor de los casos, puedes mitigar los problemas de calidad del servicio; pero nunca podrás eliminarlos por completo.
En cuanto a evidencia anecdótica, he visto que muchas empresas luchan más porque tienen esta mentalidad del mítico objetivo del 100% de nivel de servicio. Si tu empresa no está dispuesta a aceptar que, para algunos productos (no para todos ni para los más importantes), los niveles de servicio serán reducidos a propósito, entonces te diriges a serios problemas. La única manera de mejorar realmente la calidad del servicio es primero aceptar que, si el enfoque está en todo, equivale a decir que el enfoque está en nada. Mientras no estés dispuesto a aceptar que, para algunos SKUs, tendrás un nivel de servicio intencionadamente más bajo como resultado aceptable, no podrás mejorar la calidad de servicio en general.
En términos de soluciones refactorizadas, la solución refactorizada son los impulsores económicos. Es un punto que presenté en la segunda conferencia del primer capítulo, la visión para el Supply Chain Quantitativa. Los impulsores económicos muestran que tienes el costo de faltante de stock y el costo de mantenimiento de inventario, y hay un equilibrio que encontrar. No puedes simplemente presionar por un nivel de servicio del 100% porque está completamente desequilibrado desde una perspectiva económica; no es sostenible. Intentar avanzar en esa dirección es muy equivocado porque solo va a perjudicar a la empresa. La solución es inyectar una dosis saludable de impulsores económicos en tu práctica de supply chain.
Ahora, el tercer anti-pattern, Jedi Initiation, se puede observar cuando la alta dirección de muchas empresas grandes está bajo una presión constante de los medios debido a la incesante corriente de palabras de moda que se les presentan. Estas palabras de moda incluyen inteligencia artificial, blockchain, computación en la nube, big data, IoT, etc. Los influencers les dicen que si su empresa no se adapta a estas tendencias, se volverá obsoleta. Existe un miedo constante a quedarse fuera, lo cual actúa como una fuerza poderosa, ejerciendo una presión constante sobre la alta dirección de la mayoría de las grandes empresas que operan grandes supply chains.
Los síntomas de la Iniciación Jedi se pueden observar si tu empresa cuenta con una división con ingenieros jóvenes y entusiastas que tienen palabras de moda en sus cargos, tales como investigadores en inteligencia artificial, ingenieros de blockchain o data scientists. El lema es “dominar la fuerza”, siendo la fuerza la palabra de moda de interés en ese momento. La dirección toma, presumiblemente, a personas jóvenes o inexpertas y les dice que hagan algo grandioso para la empresa, pero sin involucrarse o estar familiarizados con los aspectos técnicos de estos conceptos.
Lo que ocurre es que estos equipos crean prototipos interesantes que, en última instancia, no logran ofrecer un valor real para la empresa. Como consecuencia, aunque se empezó con la idea de que la empresa sería revolucionada según la palabra de moda del momento, las prácticas tradicionales y la tecnología siguen siendo predominantes, sin ser modificadas por la palabra de moda o el equipo adicional construido a su alrededor.
En términos de evidencia anecdótica, hoy en día, en 2021, la gran mayoría de las empresas con un equipo de data science no obtienen absolutamente ningún retorno de su inversión. El equipo de data science crea prototipos sofisticados en Python utilizando bibliotecas de código abierto que son muy geniales, pero en términos de retorno práctico de la inversión para la gran mayoría del mercado, es exactamente cero. Ese es precisamente el tipo de Iniciación Jedi en el que cae la alta dirección: leen en la prensa que data science es la nueva tendencia, así que contratan a un equipo de data science. Como dato anecdótico, observo que estos equipos no solo son bastante jóvenes e inexpertos, sino que permanecen así con el paso del tiempo. Esto se debe a que la rotación es muy alta. Puedes tener una empresa muy sólida y robusta, donde la rotación promedio es típicamente de cinco a diez años, excepto en el equipo de data science, donde las personas permanecen en promedio 18 meses. Una de las razones por las que no sale nada de valor de estos equipos es que la gente entra, hace algunos prototipos y luego se va. Para la empresa, no hay capitalización, y nunca logra realmente transformar la empresa.
En términos de refactorizar esta solución, primero, no hay otra alternativa que liderar con el ejemplo. Si realmente quieres hacer data science, entonces la alta dirección necesita estar muy informada sobre data science. Por ejemplo, Jeff Bezos ha demostrado familiaridad con las técnicas de machine learning de última generación de su tiempo. Amazon puede tener mucho éxito con machine learning, pero sucede porque la alta dirección está muy familiarizada con los detalles. Liderar con el ejemplo es esencial.
En segundo lugar, debes asegurarte de que cuando contrates a estos ingenieros jóvenes, entusiastas y potencialmente talentosos, los enfrentes con problemas reales, no problemas meta. Tiene que conectarse con la realidad. Esto se remonta a mi conferencia anterior sobre optimización empírica y experimental. Si contratas a un data scientist para hacer segmentación de clientes o un mejor ABC analysis para tu empresa, esos no son problemas reales. Son simplemente números inventados. Si contratas a estas personas y las haces responsables del reabastecimiento real, encargándoles las cantidades exactas a reponer de una serie de proveedores, eso es muy real. Esta es la razón por la cual, hace una década, Lokad hizo la transición interna de data scientists a Supply Chain Scientist.
El horror no euclidiano. En este contexto, tienes una empresa que opera una gran supply chain, y el panorama de TI es muy complejo. Hay varias piezas de software empresarial, tales como ERP, WMS y EDI, que son complejas por sí mismas. Luego tienes todo el pegamento que conecta estas cosas, y el panorama completo es asombrosamente complejo. Entonces, ¿cómo sabes que en realidad estás en una empresa que enfrenta una solución no aclimatada? ¿Cuáles son los síntomas? Los síntomas son que todos en la empresa sienten que hay una incompetencia desenfrenada en la división de TI. La gente de TI luce abrumada y parece que no entiende lo que está pasando en el sistema que se supone debe gestionar y operar. Otro síntoma es que se observan problemas de TI que afectan la producción a diario. Estos son los síntomas clave de la solución no aclimatada.
La consecuencia de tener un panorama de TI no aclimatado es que los cambios que deben implementarse en la empresa —y generalmente, cuando se debe realizar un cambio en la empresa, también se debe hacer un cambio en los sistemas de TI— se realizan de forma muy lenta. Las supply chains modernas están muy impulsadas por sus componentes de software. Todos estos cambios ocurren muy lentamente, y siempre es un proceso tedioso en el que incluso los cambios pequeños demoran una eternidad. Siempre que hay algún grado de cambio, usualmente hay toneladas de regresiones. Como dice el refrán, das dos pasos hacia adelante y tres pasos hacia atrás, luego dos pasos hacia adelante y uno hacia atrás. El cambio no solo es lento, sino que también viene acompañado de un flujo constante de regresión. La situación realmente no mejora con el tiempo; en el mejor de los casos, se estanca.
En términos de causas raíz, a la dirección realmente no le importan los detalles, y la dirección no relacionada con TI realmente no se preocupa por todos esos sistemas de TI. Esto resulta en un enfoque que llamo incrementalismo, donde, por ejemplo, cualquier cambio que quieran implementar en el sistema de TI de la empresa será solicitado por las supply chains. Siempre que hay un cambio que debe realizarse, la dirección siempre dice: “Por favor, tomen el camino más fácil, el camino que requiera la menor cantidad de esfuerzo y tiempo para que podamos verlo implementado lo más rápido posible.” De eso se trata el incrementalismo.
Creo que el incrementalismo es una causa raíz muy peligrosa. El problema con el incrementalismo es que es literalmente una muerte por mil cortes. Cada cambio que se introduce en el sistema lo hace un poco más complejo, un poco más ingobernable y un poco más difícil de probar. Aunque cada cambio individualmente es intrascendente, cuando acumulas una década de decenas de cambios introducidos en los sistemas de TI a diario, terminas con un océano de complejidad. Cada cambio ha hecho que el sistema sea más complejo, y el panorama general se pierde por completo. Avanza una década, y terminas con un sistema masivo y enrevesado que parece una locura.
Como dato anecdótico, puedes ver que aún existen empresas de ecommerce muy grandes donde, como consumidor, puedes notar rutinariamente que tienen tiempos de inactividad. Este tipo de cosas nunca debería suceder. Como empresa de ecommerce en 2021, tu uptime debería ser algo como permitir 10 minutos de inactividad por año. Cada segundo de inactividad es una oportunidad desperdiciada. Diseñar software de carrito de compras en 2021 ya no es ciencia espacial; en realidad, es un software muy sencillo en lo que respecta al software empresarial. No hay razón para no tener algo que esté siempre activo. Sin embargo, la realidad es que cuando ves que el ecommerce se cae, usualmente no es el carrito de compras el que falla; es una solución no aclimatada justo detrás del ecommerce. El hecho de que el ecommerce esté caído es solo un reflejo de un problema que ocurrió en algún lugar del panorama de TI.
Si queremos refactorizar la solución no aclimatada, deberíamos dejar de buscar la solución más fácil para implementar cambios. Necesitamos pensar no en una solución fácil, sino en una solución simple. Una solución simple se diferencia de la solución fácil en un aspecto crucial: hace que todo el panorama sea un poquito más ordenado y sensato, facilitando la implementación de cambios futuros. Podrías decir, “Pero es solo un asunto puramente técnico, así que esto es trabajo de TI.” Yo diría, no, absolutamente no. Es, en realidad, un problema de supply chain. Adoptar una solución simple no se trata de tener una solución simple desde la perspectiva de TI; se trata de tener una solución simple desde la perspectiva de supply chain.
La simplicidad de la solución, y su consecuencia prevista de facilitar la implementación de cambios futuros, depende de tu hoja de ruta. ¿Qué tipo de cambios futuros deseas incorporar en tu panorama de TI? TI, como división, no tiene el tiempo para ser experto en supply chain ni para saber exactamente hacia dónde quieres dirigir la empresa dentro de una década en términos de ejecución de supply chain. Tiene que ser la dirección de supply chain la que tenga esta visión y la que dirija el desarrollo, potencialmente con el apoyo de TI, en una dirección en la que los cambios se hagan cada vez más fáciles de implementar con el tiempo.
Finalmente, como el último anti-patrón por hoy, el abogado del diablo. El contexto es, típicamente, una gran empresa que ha tenido problemas significativos de supply chain y ha decidido optar por un gran proveedor, poniendo mucho dinero sobre la mesa. Se inicia la iniciativa, y unos meses después, típicamente alrededor de seis meses, el proveedor tiene muy poco que mostrar. Se ha inyectado mucho dinero al proveedor, y hay muy poco que demostrar. Por cierto, en 2021, seis meses es mucho tiempo. Si tienes una iniciativa de software que no entrega resultados tangibles y de calidad de producción en seis meses, deberías estar muy preocupado, porque, en mi experiencia, si no puedes entregar resultados tangibles en seis meses, lo más probable es que la iniciativa esté condenada y nunca obtengas un ROI positivo para la empresa.
Lo que ocurre es que la dirección ve que el proyecto se retrasa y hay muy poco que mostrar. La alta dirección, en lugar de volverse cada vez más agresiva respecto al proveedor tecnológico y estar al frente de este, de repente cambia de bando y se vuelve muy defensiva con el proveedor. Esto es muy desconcertante. Inicias una gran iniciativa, das mucho dinero a otra compañía, y la iniciativa avanza, pero de forma deficiente y con poco resultado. En lugar de aclarar que la iniciativa está fallando, la dirección se reafirma y comienza a defender al proveedor, lo cual es muy extraño. Es como si hubiera algún tipo de Síndrome de Estocolmo en juego, donde alguien te hace daño, pero si te hacen suficiente daño, en algún momento empiezas a agradarles.
La dirección y la propia iniciativa se vuelven demasiado grandes para fracasar y, como consecuencia, se desperdician toneladas de dinero y se pierde una cantidad masiva de oportunidades, especialmente en términos de tiempo. A medida que la iniciativa avanza, se pierde dinero, pero lo más importante es que se pierde tiempo: seis meses, un año, dos años. El costo real es el tiempo. Como evidencia anecdótica de este tipo de situación, se lee muy rutinariamente en la prensa acerca de fallos épicos en la implementación de ERP para proyectos que duran casi una década o, a veces, de cinco a diez años. Te preguntas, ¿cómo puede haber un proyecto de cinco años? La respuesta es que la gente sigue invirtiendo en este proyecto, y literalmente se requieren años y años para finalmente admitir que fue un completo fracaso y que nunca funcionará.
Otro dato anecdótico es que, habiendo estado en el interior y presenciado esas implementaciones de ERP fallidas a escala épica y de varios años, con frecuencia sucede que el proyecto se detiene no porque la gente esté de acuerdo en que el proveedor realmente ha fallado. Lo que ocurre es que, en algún momento, la alta dirección involucrada en la decisión de traer al proveedor en primer lugar simplemente se mueve hacia otras empresas. Cuando básicamente todas las personas que inicialmente formaron parte de la decisión de contratar al gran proveedor han dejado la empresa, las otras personas que no se sienten tan comprometidas con este proveedor en particular, simplemente acuerdan colectivamente cerrarlo y darlo por terminado.
En términos de una solución refactorizada, creo que las empresas deben ser más tolerantes al fracaso. Tienes que ser duro con los problemas pero blando con las personas. Si cultivas una cultura en la que dices cosas como, “Tenemos que hacerlo bien a la primera”, esto es muy perjudicial porque significa que no tendrás menos fracasos. Es un malentendido de la mente humana y de la naturaleza humana pensar que, si tienes una cultura que tolera el fracaso, en realidad tendrás más fracasos. Sí, se obtendrán marginalmente más pequeños fracasos, pero lo que se consigue es que las personas se inclinen a reconocer los errores y seguir adelante. Si, por el contrario, tienes una cultura de “hazlo bien a la primera”, entonces básicamente nadie puede perder la cara. Así que, incluso cuando hay algo completamente disfuncional, el instinto de supervivencia de las personas involucradas consiste en reafirmar aquello que no funciona solo para preservar su imagen y, potencialmente, pasar a otra empresa para no tener que enfrentar las consecuencias de sus errores.
Para recapitular, tenemos conocimiento positivo versus conocimiento negativo. El conocimiento positivo se trata esencialmente de resolver problemas; es una especie de inteligencia de nivel doctoral, una inteligencia para resolver problemas, donde hay rompecabezas y se puede progresar de una solución a una mejor. Es posible evaluar que una solución es mejor que otra, y la cúspide de este tipo de pensamiento es lograr una solución óptima. Sin embargo, lo que la gente cree que está buscando – soluciones óptimas que son perfectamente válidas e inmortales – es lo que obtiene: soluciones muy efímeras.
Como ejemplo, a lo largo de la vida de Lokad, mi empresa, pasamos por seis generaciones de engines de forecast. El conocimiento positivo es efímero en el sentido de que este conocimiento, esta solución, está en riesgo cuando surge algo mejor, y simplemente se descarta esa pieza de conocimiento. En Lokad, pasamos por el tedioso ejercicio de reescribir nuestra propia tecnología de forecast desde cero seis veces desde el comienzo en 2008. Por eso digo que el conocimiento positivo es muy efímero, ya que se vuelve obsoleto rápidamente a medida que surgen soluciones nuevas y mejores.
Por el contrario, si observas el conocimiento negativo, es una perspectiva completamente diferente. Piensas en términos de errores garrafales, y el tipo de inteligencia que deseas capturar es la inteligencia callejera, aquella que te ayuda a sobrevivir en una calle peligrosa de noche. El enfoque no está tanto en rompecabezas o en cosas muy complicadas de entender e implican transferencia; se trata más de lo que no sabes o de los tabúes. No es lo que no sabes; es lo que la gente no te dirá, o el tipo de cosas en las que la gente incluso te mentirá solo porque quiere salvar la cara. El conocimiento negativo se trata de luchar contra todos esos tabúes que te impiden ver la realidad tal como es.
Con el conocimiento negativo, la mentalidad no es la del progreso; es una mentalidad de supervivencia. Solo quieres sobrevivir para poder luchar otro día. Esa es una perspectiva muy diferente, y es exactamente el tipo de cosa que las empresas buscan instintivamente cuando optan por un director de supply chain con mucha experiencia. Quieren asegurarse de que, a través de esta persona, la compañía sobreviva otro día. Lo que puede ser sorprendente es que el conocimiento negativo tiende a ser mucho más duradero. Estas son, en gran medida, las fallas de la naturaleza humana involucradas, y no cambian con el tiempo solo porque exista una nueva tecnología, enfoque o método. Estas cosas han llegado para quedarse.
En conclusión, diría que el conocimiento negativo es de suma relevancia para todos los problemas complejos, siendo el supply chain solo el foco de interés de esta conferencia, pero no es la única área donde se puede aplicar el conocimiento negativo.
Los anti-patrones de supply chain son solo algunos ejemplos, pero estoy bastante seguro de que se podrían identificar docenas más para capturar los problemas que siguen ocurriendo en los supply chain del mundo real. No podemos esperar capturar todo a través de anti-patrones, pero creo que podemos abarcar una porción decente. Después de leer un libro sobre anti-patrones de software, mi opinión subjetiva fue que había ganado el equivalente a cinco años de experiencia en ingeniería de software en tan solo 200 páginas. Mi esperanza es que, para una colección de anti-patrones de supply chain, también podamos replicar este efecto, en el que alguien pueda adquirir algo así como cinco años de experiencia en un período de tiempo mucho más corto, tal vez solo unas pocas semanas.
Eso es todo para esta conferencia. La próxima conferencia será sobre la evaluación de proveedores, que es un problema muy interesante. Los supply chain modernos viven o mueren por los productos de software que los respaldan, y la cuestión es cómo razonamos acerca de esos productos de software y cómo elegimos los correctos y a los proveedores correctos. A pesar de tener mi justa medida de conflictos de interés, es un problema interesante, y la cuestión es cómo podemos tener una metodología en la que, incluso si todas las personas tienen sesgos, se puedan obtener resultados sin sesgo a partir del método.
Ahora, atenderé las preguntas.
Pregunta: ¿Qué constituye un buen forecast en un entorno de optimización probabilística, y cómo se mide la calidad? ¿Existe un papel para los enriquecimientos manuales?
Un buen forecast probabilístico tiene métricas para precisiones probabilísticas, pero probablemente eso no es lo que estás buscando. Como parte de una iniciativa de optimización experimental, querrás optimizar. Métricas tales como entropía cruzada o verosimilitud se aplican a los forecast probabilísticos. Más importante aún, habrá aspectos que irás descubriendo gradualmente a medida que identifiques decisiones insanas. El forecast es solo un medio para un fin, que es la decisión. Necesitas prestar atención a las decisiones. Tocamos brevemente este tema en la conferencia anterior sobre optimización experimental. El proceso es el mismo tanto para forecasts clásicos como para forecasts probabilísticos. Si deseas tener ejemplos del mundo real de forecasts probabilísticos, esto se tratará extensamente en conferencias posteriores. Lamento estar divagando un poco al responder esta pregunta.
Pregunta: ¿Qué piensas sobre el uso de AI (Appreciative Inquiry) para apoyar tu AI (Artificial Intelligence)? ¿Qué técnicas utilizarás para analizar de manera lógica grandes conjuntos de datos, y por qué están disminuyendo las tasas de conversión a pesar de un buen rendimiento general? ¿Qué se debe abordar para corregir la situación?
La AI, como conjunto de algoritmos, es principalmente deep learning en este momento. Deep learning es un conjunto de técnicas que resulta muy capaz de lidiar con datos altamente no estructurados. La pregunta que realmente deberías hacerte es cómo conectar eso con la realidad. En el supply chain, los datos tienden a ser muy escasos. La mayoría de los productos en cualquier tienda se venden a menos de una unidad al día. Los grandes conjuntos de datos solo son grandes en conjunto cuando observas una empresa muy grande con toneladas de transacciones. Si observas las granularidades que realmente importan, no dispones de tantos datos.
El Appreciative Inquiry, en términos de metodologías, se trata realmente de la optimización experimental discutida en la conferencia anterior.
Pregunta: Muchos gerentes no entienden el poder de la ciencia de datos, y darles problemas ficticios es un camino seguro. Si no quieren profundizar en el aprendizaje sobre ciencia de datos, ¿cuál es una forma alternativa de hacerles creer en la ciencia de datos y en enfoques que prioricen la decisión? ¿Cómo empezar en pequeño y expandirse a lo grande?
Primero, si tienes personas que no creen en una tecnología, está perfectamente bien. Toma a Warren Buffett, por ejemplo. Es un inversor muy rico que pasó su vida invirtiendo en compañías que entiende. Invierte en empresas con modelos de negocio simplistas, como compañías de transporte ferroviario o empresas de leasing de muebles. Warren Buffett dijo, “No me interesa entender todas esas tecnologías.” Por ejemplo, cuando le preguntaron por qué no invirtió en Google, Buffett respondió, “No entiendo nada de lo que Google está haciendo, así que, aunque pueda ser una buena inversión, no soy lo suficientemente inteligente para eso. Voy a invertir únicamente en compañías que entiendo.”
Mi punto es que, para la dirección, creo que es una completa ilusión aventurarse en áreas que no entienden. En algún momento, si no estás dispuesto a hacer el esfuerzo, simplemente no funcionará. Ese es el anti-patrón Jedi en juego – la dirección no está dispuesta a hacer ningún esfuerzo, y piensa que simplemente contratar ingenieros inteligentes, jóvenes e inteligentes resolverá el problema. Si ese fuera el caso, Amazon no habría tenido el éxito que tuvo. Si fuera posible para una empresa tradicional de cadena minorista simplemente contratar a unos pocos ingenieros para crear un sitio web de ecommerce y competir con Amazon, todos lo habrían hecho. Hasta alrededor de 2005, esas compañías contaban con recursos y capacidades de ingeniería significativamente mayores que las de Amazon.
El problema es que es una ilusión, y de eso se trata el conocimiento negativo: de arrojar luz sobre el tipo de problemas que son ubicuos. Por eso necesitas un título llamativo para comunicar el problema a los gerentes. Tampoco deberías tener miedo de aprender cosas nuevas. Cuando realmente aprovechas la parte buena de la nueva tecnología, por lo general no es tan complicado. No todo es súper técnico; muchas partes podrían explicarse. Por ejemplo, incluso algo como las blockchains – la mitad de esas supuestamente tecnologías blockchain súper avanzadas podrían explicarse a niños de 10 años. Muchas de las ideas detrás de estas tecnologías son, en realidad, bastante simples. Hay montones de tecnicismos matemáticos accidentales que son muy difíciles, pero ese no es el núcleo del problema.
Entonces, mi respuesta para ustedes sería que, si la dirección quiere creer en cuentos de hadas, no hay mucho que se pueda hacer en esa situación. Si la dirección está dispuesta a invertir en ciencia de datos, también debería estar dispuesta a invertir un pequeño tiempo para entender de qué se trata la ciencia de datos. De lo contrario, es simplemente una ilusión.
Eso es todo por hoy. Muchas gracias, y la próxima conferencia será el mismo día, el miércoles, dentro de dos semanas, a la misma hora. Nos vemos entonces.
Referencias
- ‘‘AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis’’. y William J. Brown, Raphael C. Malveau, Hays W. “Skip” McCormick, Thomas J. Mowbray, 1998
