00:15 Introducción
02:28 Nevera Inteligente
05:28 Sesgo de supervivencia
07:28 La historia hasta ahora
08:46 Sobre los tabúes (recapitulación)
12:06 Heurísticas de rechazo (recapitulación)
13:34 Conocimiento positivo de baja calidad
15:27 Antipatrones de software, 1/2
20:11 Antipatrones de software, 2/2
25:34 Antipatrones de Supply Chain
27:00 Forecast desnudos
32:36 El nivel de servicio del 100%
37:06 La iniciación Jedi
44:31 El Horror No Euclidiano
51:45 Abogado del diablo
57:35 Recapitulación, conocimiento negativo para las supply chains
01:01:04 Conclusión
01:02:45 Próxima conferencia y preguntas del público
Descripción
Los antipatrones son los estereotipos de soluciones que parecen buenas pero no funcionan en la práctica. El estudio sistemático de los antipatrones fue pionero a finales de los años 90 en el campo de la ingeniería de software. Cuando son aplicables, los antipatrones son superiores a los resultados negativos crudos, ya que son más fáciles de memorizar y razonar. La perspectiva del antipatrón es de suma importancia para la supply chain, y debería considerarse como uno de los pilares de su conocimiento negativo.
Transcripción completa
Hola a todos, bienvenidos a esta serie de conferencias de supply chain. Soy Joannes Vermorel, y hoy presentaré el 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 cuando contrata a un director de supply chain con tal vez dos o tres décadas de experiencia. ¿Qué es lo que la empresa está buscando, y podríamos, en cierta medida, replicar la adquisición de esta experiencia en un período de tiempo mucho más corto? Eso es exactamente de lo que trata el conocimiento negativo.
Cuando miramos a una persona muy experimentada, alguien que ha estado trabajando durante dos décadas en un campo, ¿realmente estamos buscando que esta persona replique soluciones, procesos o tecnologías que implementaron hace una o dos décadas en otras empresas? Probablemente no. Aunque podría suceder marginalmente, sospecho que generalmente, esa es una razón muy marginal en el mejor de los casos.
Cuando buscas a una persona muy experimentada, el objetivo no es necesariamente replicar las cosas tal como se hicieron en el pasado. El valor clave que quieres adquirir es tomar a alguien que sabe cómo evitar todo tipo de errores y tiene la experiencia para asegurar que muchas ideas muy ingenuas y malas no se implementarán en tu empresa. Hay un dicho que dice que en teoría, la práctica y la teoría son lo mismo, pero en la práctica, no lo son. Eso es exactamente el quid del conocimiento negativo.
Mi propuesta para ti es que las malas ideas de negocio están por todas partes. Cuando digo malas, me refiero a ideas que, si se implementaran, resultarían completamente no rentables para la empresa. Para ilustrar esto, simplemente puse 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 puedes buscar en una base de datos de patentes. Y he aquí, obtenemos 130,000 resultados de patentes presentadas sobre frigoríficos inteligentes.
Toma este número con un grano de sal, ya que probablemente hay muchos duplicados. Sin embargo, una inspección superficial de los resultados indica que muy claramente, tenemos varios cientos, si no varios miles de empresas que, durante las últimas décadas, se han esforzado por hacer investigación y desarrollo para presentar una patente sobre refrigeradores inteligentes. Cuando miras el tipo de ideas que se encuentran en esas patentes, verás que siempre es una combinación de tomar este electrodoméstico muy ubicuo, un frigorífico, y añadir algo, como electrónica barata. Combinamos los dos, y voilà, tenemos una solución de algún tipo.
¿Para qué tipo de problema, sin embargo? Es muy poco claro. Solo para darte la esencia de la mayoría de las patentes, es el tipo de idea donde, si tienes un frigorífico que tiene algún tipo de sensores, el propio frigorífico va a detectar si te estás quedando sin leche y automáticamente hará un reabastecimiento por ti. Estamos en 2021, y hasta donde yo sé, los frigoríficos inteligentes no existen. No es que no sean técnicamente factibles, lo son mucho. Es solo que literalmente no hay mercado para ellos. Entonces, tenemos una gran cantidad de soluciones en el mercado buscando un problema. Durante las últimas dos décadas, creo que he presenciado dos veces al año, en promedio, una startup promoviendo un frigorífico inteligente de algún tipo. Curiosamente, nunca volví a saber de ninguna de esas startups. Realmente no llevé la cuenta, pero sospecharía fuertemente que cada una de las startups que he visto promoviendo un frigorífico inteligente durante las últimas dos décadas ha fracasado. Sin embargo, mientras que la idea es muy generalizada y popular, como lo demuestran esas miles de patentes, las consecuencias de esas ideas, que son malas porque probablemente la mayoría de esas startups simplemente se declararon en quiebra, 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 se difundieron pero no resultaron ser muy exitosas.
Hay un ejemplo histórico muy notable de la Segunda Guerra Mundial. El Ejército de los EE. UU. realizó una encuesta sobre aviones que regresaban a la base para recoger la ubicación de los impactos de bala en la aeronave. Lo que ves en la pantalla era esencialmente la recopilación de la ubicación de las balas según se observó 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 blindaje en las áreas que recibían más impactos, las áreas que obviamente estaban bajo la mayor cantidad de fuego durante la batalla.
Luego, otro caballero, Abraham Wald, dijo que no, esto es exactamente lo contrario. Lo que pasa es que lo que ves son aviones que lograron regresar a la base. Lo que no ves es que, para todas las áreas donde no ves impactos de bala, es muy probable que cuando hubo un impacto de bala en esta área, resultó ser letal ya sea para el avión o para la tripulación, o ambos. Entonces, si tienes que agregar algún blindaje, tienes que hacerlo precisamente en todas las áreas donde no ves aviones regresando a la base con impactos de bala. Esas son las áreas que necesitan ser protegidas.
Lo que Abraham señaló es que había un fenómeno conocido como sesgo de supervivencia, donde lo que observas son esencialmente los supervivientes, no todos los aviones que no lograron regresar a la base. La idea del conocimiento negativo es exactamente así: tomas esta fotografía y el negativo, y es el resto lo que realmente necesita captar tu atención porque ahí es donde ocurren las cosas realmente malas. Esa es la esencia, diría yo, del conocimiento negativo.
Esta es la cuarta conferencia en 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 la supply chain, tanto el campo de estudio como la práctica. Lo que hemos visto es que la supply chain es esencialmente una colección de problemas perversos, en contraposición a los problemas mansos. Los problemas perversos son muy difíciles de abordar porque no se prestan a estudios fáciles ni a una práctica fácil. Hay algo fundamentalmente adverso en términos de estudio y práctica con los problemas perversos. Por eso el segundo capítulo está dedicado a las metodologías.
En esta conferencia actual, estamos tomando un enfoque cualitativo, al igual que lo que hicimos con la persona de la supply chain, que fue la primera conferencia de este capítulo. Ampliaremos el tipo de enfoques cualitativos que podemos tener para entregar mejoras a las supply chains de manera controlada, confiable y potencialmente medible al final.
Recapitulación: Aunque esta es una conferencia dedicada al conocimiento negativo, esta 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 personajes de la supply chain, presenté mis puntos de vista sobre los estudios de caso. Dije que los estudios de caso positivos, es decir, estudios de caso que presentan resultados positivos asociados con una solución de interés, vienen con conflictos de interés masivos que esencialmente socavan completamente cualquier confianza que podríamos 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 pueden estar presentes, son mucho menos intensos.
En esta conferencia sobre personajes de la supply chain, presenté un fantástico estudio de caso negativo, “Los últimos días de Target Canadá” de Joe Castaldo, que detalló un fracaso de la supply chain a escala épica que finalmente llevó a la quiebra de Target Canadá. Este es un tipo de conocimiento negativo, donde el objeto de estudio es literalmente cosas que no funcionaron, en contraposición a lo que podemos hacer para tener algo que realmente funcione.
Ahora, ¿podríamos usar estudios de caso negativos como una práctica fundamental para nuestro conocimiento negativo para la 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 súper raros. Supondría, solo como una estimación, que en realidad hay más de 100 veces más patentes sobre frigoríficos inteligentes, que son completamente inútiles, que estudios de caso negativos sobre supply chains. Entonces, tenemos un problema muy práctico: aunque esos estudios de caso negativos son de suma relevancia y de muy alto interés científico, resulta que son extremadamente raros. Tenemos tan poco de ello que es muy difícil tener este material como la base de nuestro conocimiento negativo para la supply chain.
El segundo problema es la inteligibilidad. Esos estudios de caso negativos, como el fantástico artículo “Los últimos días de Target Canadá”, muestran que hay docenas de problemas ocurriendo al mismo tiempo, y todos esos problemas están completamente enredados para finalmente llevar a un fracaso épico. El problema es que esos estudios de caso son literalmente la vida real en juego, 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. Hay un problema más pedestre: ¿cómo comunicas eso a una audiencia más amplia?
En mi última conferencia sobre optimización experimental, también vimos otro tipo de conocimiento negativo: heurísticas de rechazo. Estos eran esencialmente trucos simples que se pueden usar cuando hay una propuesta en términos de una solución cuantitativa presentada como un posible candidato para la mejora de tu supply chain. Puedes usar una serie de heurísticas o reglas simples para descartar soluciones que, con un grado de certeza muy alto, 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 la supply chain, tanto los artículos científicos como el software de supply chain se adaptarían y cambiarían su discurso, lo que confundiría más la situación. Esas heurísticas son muy eficientes, pero si llegaran a ser populares, aún conservarían su validez, pero perderían su eficiencia como filtros, simplemente porque la gente prestaría atención para trabajar alrededor de esas heurísticas.
Por eso estas heurísticas, aunque muy interesantes, no pueden ser utilizadas como fundamentos para nuestro conocimiento negativo que queremos constituir para la supply chain.
Además, no debemos confundir el conocimiento negativo con el conocimiento positivo de baja calidad. La diferencia es realmente una cuestión de intención. Por ejemplo, la intención de las existencias de seguridad es dar a las empresas una forma controlada de impulsar la calidad del servicio que obtendrán. La intención es positiva; es una solución para algo que debería funcionar. Ahora, la realidad es que el modelo de stock de seguridad se basa en suposiciones completamente abusivas: se supone que la demanda futura y los tiempos de entrega son normalmente distribuidos, aunque estas suposiciones son factualmente incorrectas. Nunca he observado ningún conjunto de datos de supply chain donde la demanda o los tiempos de entrega fueran normalmente distribuidos. Las distribuciones de interés son en realidad distribuidas por Zipf, como abordé en mis conferencias anteriores sobre los principios cuantitativos para la supply chain. Desde una perspectiva adecuada, el stock de seguridad es falsificado, pero aún así, el stock de seguridad está definitivamente anclado en el ámbito del conocimiento positivo, aunque podría ser discutiblemente 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é encantado de complacer si algunas personas quieren hacerme preguntas sobre cualquiera de esos elementos durante la sesión de preguntas y respuestas.
Cuando se trata de conocimiento negativo real de interés práctico, hay un libro llamado “Anti-Patrones: Refactorización de Software, Arquitecturas y Proyectos en 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 las buenas ideas consumidas por el éxito del proyecto. Los autores se preguntan si una buena idea sigue siendo una buena práctica después de que se implementa el producto, y la respuesta es esencialmente no. Hay una ventaja del primer movimiento que es muy específica para la industria del software, y como resultado, tenemos un problema. Prácticamente cualquier conjunto de reglas que usarías para predecir el éxito de cualquier cosa en la industria del software es autodestructivo, debido al hecho de que los mejores enfoques tienden a ser consumidos por el éxito que generan. Los autores de “Anti-Patrones” notaron que es casi imposible, en su opinión, garantizar el éxito de una iniciativa de software. Sin embargo, también notaron que la situación es muy asimétrica cuando se trata de fracasos. Observaron que es posible predecir, con un grado de confianza muy alto (a veces rozando la certeza), que un proyecto dado está a punto de fracasar. Esto es muy interesante porque no puedes garantizar el éxito, pero puedes tener algo así como una ciencia que garantiza el fracaso. Aún mejor, este conocimiento de elementos que garantizan el fracaso parece ser extremadamente estable con el tiempo y muy independiente de las tecnicidades de la empresa o del vertical que se considera.
Si volvemos a la idea inicial de la nevera inteligente, podemos ver que todas esas patentes de neveras inteligentes son increíblemente diversas en las soluciones que presentan. Pero resulta que todas esas patentes de neveras inteligentes conducen a fracasos empresariales porque todas caen bajo el mismo paraguas: 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 viaje estudiando las causas raíz 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 estrechez de miras, la avaricia, la ignorancia, el orgullo y la envidia. Estos problemas van a ser independientes del contexto y las tecnologías involucradas porque son invariantes de la naturaleza humana misma. Cuando se busca un director de supply chain con dos décadas de experiencia, va a ser alguien que simplemente ha vivido más tiempo y ha interiorizado la mayoría de los problemas que surgen cuando tienes humanos reales involucrados, con todo tipo de defectos.
La idea de los autores es que es bueno formalizar este conocimiento para hacerlo más digerible e inteligible, de modo que será más fácil comunicar y razonar sobre estos problemas. Esa es la esencia de los anti-patrones: un formato para capturar fragmentos de conocimiento negativo.
En su libro, los autores presentan una plantilla para un anti-patrón, que comienza con un nombre pegadizo que es fácil de memorizar. Necesitas 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. Quieres identificar las causas raíz reales y las consecuencias que normalmente se asocian con ellas. Quieres caracterizar las fuerzas en juego, los síntomas y las consecuencias no deseadas que la gente no espera, que socavarán completamente los beneficios esperados de la solución inicial.
Los autores argumentan que necesitas presentar evidencia anecdótica, y por eso utilizan empresas ficticias en sus anti-patrones. Esto se hace para evitar los tabúes involucrados en discutir empresas reales y personas reales, lo que podría impedir que se establezca una comunicación honesta. La plantilla de anti-patrón 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 funciona en el mundo real, donde las consecuencias no deseadas se mitigan y idealmente se eliminan.
Esta conferencia no es sobre anti-patrones de supply chain, pero solo para dar dos ejemplos de anti-patrones de software de los que puede que hayas oído hablar, el primero es el Martillo Dorado. El Martillo Dorado es la idea de que cuando tienes un martillo dorado en tu mano, todo lo demás es un clavo. Este anti-patrón esencialmente afirma 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 presentas otro problema a la misma persona, la misma persona diría que este otro problema también podría resolverse con un programa de Java. Si presentas 20 problemas diferentes, cada vez la respuesta será: “Creo que un programa de Java estaría bien”. Este es un sesgo masivo donde las personas con experiencia en una tecnología dada tienen la tendencia 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 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, hay muchas situaciones donde las posibilidades son infinitas, y es tentador decir: “En lugar de probar 20 enfoques diferentes que van a fallar, pensemos muy bien en el diseño, y una vez que estemos absolutamente seguros de que tenemos la solución correcta en mente, entonces implementaremos la solución”. Desafortunadamente, esto es muy difícil de ejecutar, y generalmente conduce a la parálisis por análisis, donde se invierte más tiempo y esfuerzo en considerar toneladas de opciones potenciales en lugar de simplemente probar una solución y ver si funciona o no.
Ahora, obviamente, hemos discutido que este libro era sobre anti-patrones 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 perversos, y la supply chain moderna tiene mucho que ver con la entrega de un producto de software. Por lo tanto, hay 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-patrones de supply chain, que se pueden encontrar en forma escrita en el sitio web de Lokad, con una presentación más extensa disponible para aquellos interesados.
El primero es Naked Forecast. Inspirado en el cuento corto “La ropa nueva 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 duración de los que todos se quejan: producción, marketing, ventas, compras e incluso supply chain, siendo la división de forecast típicamente parte de la supply chain. Ha habido intentos de mejorar la precisión del forecast durante la última década o dos, pero parece que no importa cuánto esfuerzo se ponga en el caso, hay una serie interminable de excusas de las personas a cargo del forecast para justificar su pobre precisión.
La cuestión es que hay esta próxima iniciativa donde la intención es poner en orden la precisión del forecast, para solucionar este problema de inexactitud del forecast de una vez por todas. Eso es el anti-patrón del Naked Forecast en juego. Las consecuencias no deseadas de eso son, primero, no va a entregar forecasts significativamente más precisos. Segundo, pasar por otra iniciativa solo va a crear una organización aún más bizantina donde lo que comenzó como una pequeña práctica para entregar el forecast se vuelve cada vez más complejo, con más personas involucradas en la producción de esos forecasts. Al final del camino, 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 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 precisos de acuerdo a una métrica, digamos el error absoluto medio”. Todo parece muy sencillo, con un problema bien definido. Sin embargo, el problema es que todo eso es muy ingenuo porque no hay una correlación directa entre la precisión del forecast y la rentabilidad de la empresa. Lo que deberías estar buscando son formas de mejorar la rentabilidad de la empresa, por lo que deberías 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 ningún feedback del negocio real. La precisión del forecast es solo un artefacto numérico; no es un retorno real y tangible de la inversión para el negocio. Como dato anecdótico, si hubiera recibido un cheque extra de mil dólares cada vez que tuve una discusión por teléfono con un director de supply chain que me decía que estaban comenzando 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 estén desnudos, no va a funcionar. Necesitas vestirlos, y esas ropas son 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, como cuánto comprar, cuánto producir, o si subir o bajar los precios, nunca obtienes el feedback real que importa. El feedback real que importa no es el KPI de back-test en la medición; lo que importa son esas decisiones. Por lo tanto, en términos de solución refactorizada para abordar el anti-patrón del Naked Forecast, básicamente es decidir que las mismas personas que generan el forecast tienen que vivir con las consecuencias de esos forecasts cuando se trata de las decisiones de supply chain que se implementan encima de él.
El segundo sería el Mítico 100% Nivel de Servicio. La situación típicamente comienza de la siguiente manera: la junta de directores se reúne y, en algún lugar de la prensa o en las redes sociales, algunas personas se quejan ruidosamente sobre la calidad del servicio. No se ve bien para la empresa, ya que parece que la empresa no está cumpliendo con las promesas que hizo. La junta pone una enorme presión sobre el CEO para que haga algo sobre este problema de calidad de servicio, que está impactando negativamente en la marca, la imagen y potencialmente el crecimiento de la empresa. El CEO dice: “Realmente necesitamos poner fin a esta interminable serie de problemas de calidad de servicio”. Entonces, el CEO se dirige al VP de Supply Chain y le pide que ponga fin a estos problemas de calidad de servicio. El VP de Supply Chain, a su vez, pide al Director de Supply Chain que haga lo mismo, y el Director de Supply Chain pide al Supply Chain Manager que aborde el problema. El Supply Chain Manager entonces sube el nivel de servicio a algo muy alto, cerca del 100%.
Y he aquí, incluso si a corto plazo terminas con niveles de servicio marginalmente más altos, muy pronto los problemas de calidad de servicio regresan. Estos niveles de servicio más altos no son sostenibles, y terminas con fluctuaciones de inventario, inventario desperdiciado y, aunque la intención era aumentar el nivel de servicio, frecuentemente obtienes niveles de servicio más bajos seis o doce meses después.
La causa raíz aquí no es solo la ignorancia sino también el pensamiento deseoso. Matemáticamente hablando, si quieres un nivel de servicio del 100%, significa una cantidad infinita de inventario, lo cual técnicamente no es posible. Tienes este poderoso pensamiento deseoso de que puedes abordar completamente este problema, aunque no es posible. En el mejor de los casos, puedes mitigar los problemas de calidad de servicio; nunca puedes eliminarlos completamente.
En términos de evidencia anecdótica, he visto que muchas empresas luchan más porque tienen esta mentalidad del mítico objetivo de nivel de servicio del 100%. Si tu empresa no está dispuesta a aceptar que, para algunos productos (no todos o los más importantes), los niveles de servicio se reducirán a propósito, entonces te diriges a un problema grave. La única forma de mejorar realmente la calidad del servicio es aceptar primero que si el enfoque está en todo, es equivalente a decir que el enfoque no está en nada. Mientras no estés dispuesto a aceptar que, para algunas SKUs, tendrás un nivel de servicio más bajo a propósito como un resultado aceptable, no podrás mejorar tu calidad de servicio 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 la Supply Chain Quantitativa. Los impulsores económicos muestran que tienes el costo de los faltantes de stock y el costo de mantenimiento, 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 presionar en esta dirección es muy equivocado porque solo va a dañar 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 antipatrón, Iniciación Jedi, se puede ver cuando la alta dirección de muchas grandes empresas está bajo constante presión de los medios debido a la constante corriente de palabras de moda que se dirigen hacia ellos. 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 perderse algo, que actúa como una fuerza poderosa, aplicando 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 tiene una división con ingenieros jóvenes y entusiastas que tienen palabras de moda en sus títulos de trabajo, como investigadores de inteligencia artificial, ingenieros de blockchain o Supply Chain Scientists. El lema es “dominar la fuerza”, siendo la fuerza la palabra de moda de interés en ese momento. La dirección toma a personas jóvenes o inexpertas y les dice que hagan algo grande para la empresa, pero sin estar involucrados o familiarizados con los aspectos técnicos de estos conceptos.
Lo que sucede es que estos equipos crean prototipos interesantes que finalmente no logran entregar valor real para la empresa. Como consecuencia, aunque comenzó con la idea de que la empresa sería revolucionada de acuerdo con la palabra de moda del día, las prácticas y tecnología heredadas siguen siendo prevalentes, no modificadas por la palabra de moda o el equipo extra construido alrededor de ella.
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 están obteniendo ningún retorno de su inversión. El equipo de data science crea prototipos de Python elegantes 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. Eso es exactamente el tipo de Iniciación Jedi por la que cae la alta dirección: leen en la prensa que la data science es la nueva tendencia, por lo que contratan un equipo de data science. Como dato anecdótico, veo que estos equipos no solo son bastante jóvenes e inexpertos, sino que también permanecen así con el tiempo. Eso se debe a que la rotación es muy grande. Puedes tener una empresa que es muy sólida y robusta, donde la rotación promedio es típicamente de cinco a diez años, excepto para el equipo de data science, donde las personas permanecen en promedio durante 18 meses. Una de las razones por las que no sale nada de valor de estos equipos es que las personas entran, hacen algunos prototipos y luego se van. Para la empresa, no hay capitalización, y nunca logra transformar realmente la empresa.
En términos de refactorizar esta solución, primero, no hay solución alternativa más que liderar con el ejemplo. Si quieres hacer data science, entonces la alta dirección necesita estar muy familiarizada con la data science. Por ejemplo, Jeff Bezos ha demostrado familiaridad con las técnicas de machine learning de vanguardia de su tiempo. Amazon puede tener mucho éxito con el machine learning, pero sucede porque la alta dirección está muy familiarizada con la letra pequeña. Liderar con el ejemplo es esencial.
En segundo lugar, debes asegurarte de que cuando contratas a estos ingenieros jóvenes, entusiastas y potencialmente talentosos, los enfrentas con problemas reales, no con problemas meta. Necesita 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 análisis ABC para tu empresa, estos no son problemas reales. Son solo números inventados. Si contratas a estas personas y las pones a cargo del reabastecimiento real, y las haces responsables de las cantidades exactas a reabastecer de una serie de proveedores, eso es muy real. Esta es la razón por la que, hace una década, Lokad pasó internamente de data scientists a Supply Chain Scientists. El punto era tener un compromiso completamente diferente y alejarse de este anti-patrón de Iniciación Jedi.
El horror no euclidiano. En este contexto, tienes una empresa que opera una gran supply chain y el panorama de IT es muy complejo. Hay varias piezas de software empresarial, como ERP, WMS y EDI, que son complejas por sí mismas. Luego tienes todo el pegamento que conecta estas cosas entre sí, y el cuadro completo es asombrosamente complejo. Entonces, ¿cómo sabes que estás realmente en una empresa que está enfrentando 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 rampante en la división de IT. Las personas de IT parecen abrumadas y parecen no entender lo que está sucediendo en el sistema que se supone que deben administrar y ejecutar. Otro síntoma es que ves problemas de IT que impactan la producción a diario. Estos son los síntomas clave de la solución no aclimatada.
La consecuencia de tener un panorama de IT no aclimatado es que los cambios que necesitan ser introducidos en la empresa, y usualmente, cuando hay un cambio que debe ser introducido en la empresa, hay un cambio que debe ser introducido en los sistemas de IT también. 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 donde incluso los cambios pequeños toman una eternidad. Siempre que hay algún grado de cambio, usualmente hay toneladas de regresiones. Como dice la gente, das dos pasos hacia adelante y tres pasos hacia atrás, luego dos pasos hacia adelante de nuevo y un paso hacia atrás. El cambio no solo es lento, sino que también viene con un flujo constante de regresión. La situación no mejora realmente con el tiempo; en el mejor de los casos, se estanca.
En términos de causas raíz, la gerencia realmente no se preocupa por los detalles, y la gerencia no-IT realmente no se preocupa por todos esos sistemas de IT. Esto resulta en un enfoque que llamo incrementalismo, donde cualquier cambio que quieran que ocurra en el sistema de IT de la empresa, esos cambios serán solicitados por las supply chains, por ejemplo. Siempre que haya un cambio que necesite ocurrir, la gerencia siempre dirá: “Por favor, toma el camino más fácil, el camino que requiere la menor cantidad de esfuerzo y tiempo para que podamos ver esto implementado lo más rápido posible”. Eso es de lo que 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 único que se introduce en el sistema lo hace un poco más complejo, un poco más inmanejable y un poco más difícil de probar. Aunque cada cambio individual es inconsecuente, cuando acumulas una década de docenas de cambios introducidos en los sistemas de IT a diario, terminas con un océano de complejidad. Cada cambio ha hecho el sistema más complejo, y se ha perdido completamente la visión general. Avanza una década, y terminas con un sistema masivo y enrevesado que parece una locura.
Como una pequeña evidencia anecdótica, puedes ver que todavía hay empresas de ecommerce muy grandes donde, como consumidor, puedes ver rutinariamente que tienen tiempos de inactividad. Este tipo de cosas nunca deberían suceder. Como empresa de ecommerce en 2021, tu tiempo de actividad debería ser algo así 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 software muy común en lo que respecta al software empresarial. No hay razón para no tener algo que siempre esté encendido. Sin embargo, la realidad es que cuando ves que el ecommerce se cae, generalmente no es el carrito de compras el que falla; es una solución no aclimatada que está justo detrás del ecommerce. El ecommerce que se cae es solo un reflejo de un problema que ocurrió en algún lugar del panorama de IT.
Si queremos refactorizar la solución no aclimatada, deberíamos dejar de buscar la solución más fácil para provocar un cambio. Necesitamos pensar no en una solución fácil, sino en una solución simple. Una solución simple difiere de la solución fácil de una manera crucial: hace que todo el panorama sea un poco más ordenado y más sensato, facilitando la introducción de más cambios más adelante. Podrías decir: “Pero es solo una cuestión puramente técnica, así que este es el trabajo de IT”. Yo diría que no, absolutamente no. Es muy mucho un problema de supply chain. Adoptar una solución simple no es una cuestión de tener una solución simple desde una perspectiva de IT; es tener una solución simple desde una perspectiva de supply chain.
La simplicidad de la solución, y su consecuencia prevista de facilitar la implementación de cambios posteriores, depende de tu hoja de ruta. ¿Qué tipo de cambios futuros quieres introducir en tu panorama de IT? IT, como división, no tiene tiempo para ser expertos en supply chain y 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 gestión de supply chain la que tenga esta visión y tenga que dirigir el desarrollo, potencialmente con el apoyo de IT, en una dirección donde los cambios se vuelvan cada vez más fáciles de implementar con el tiempo.
Finalmente, como último anti-patrón para 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. La iniciativa se pone en marcha, y unos meses después, típicamente seis meses o así, el proveedor tiene muy poco que mostrar por ello. Se ha empujado mucho dinero hacia el proveedor, y hay muy poco que mostrar por ello. Por cierto, en 2021, seis meses es mucho tiempo. Si tienes una iniciativa de software que no entrega resultados tangibles y de producción en seis meses, deberías estar muy preocupado porque, en mi experiencia, si no puedes entregar resultados tangibles en seis meses, es probable que la iniciativa esté condenada, y nunca tendrás un ROI positivo para la empresa.
Lo que sucede es que la dirección ve que el proyecto se retrasa, y hay muy poco que mostrar por ello. La alta dirección, en lugar de volverse cada vez más agresiva con respecto al proveedor de tecnología y estar a la vanguardia del proveedor de tecnología, de repente cambia de bando y se vuelve muy defensiva con el proveedor. Esto es muy desconcertante. Empiezas una gran iniciativa, das mucho dinero a otra empresa, y la iniciativa avanza pero mal y tiene poco que mostrar por ello. En lugar de aclarar que la iniciativa está realmente fallando, la dirección se pone en doble y empieza 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 hacen una cantidad suficiente de daño, en algún momento empiezas a gustarte esas personas.
La dirección y la iniciativa en sí se vuelven demasiado grandes para fracasar, y como consecuencia, hay toneladas de dinero desperdiciado y una cantidad masiva de oportunidad perdida, especialmente en términos de tiempo. A medida que la iniciativa avanza, se pierde dinero, pero lo más importante, se pierde tiempo: seis meses, un año, dos años. El verdadero costo es el tiempo. Como una especie de evidencia anecdótica de este tipo de cosas, puedes leer muy rutinariamente en la prensa que hay fracasos a escala épica en la implementación de ERP para proyectos que duran casi una década o a veces de cinco a diez años. Piensas, ¿cómo puedes tener un proyecto de cinco años? La respuesta es, la gente sigue apostando por este proyecto, y literalmente se necesitan años y años para finalmente admitir que fue un fracaso completo y que nunca funcionaría.
Otro dato anecdótico es que, habiendo estado en el interior presenciando esas implementaciones de ERP fallidas a escala épica y de varios años, frecuentemente sucede que el proyecto cesa no porque la gente esté de acuerdo en que el proveedor ha fallado realmente. La forma en que se juega es que en algún momento, la alta dirección involucrada en la decisión de traer al proveedor en primer lugar simplemente se muda a otras empresas. Cuando básicamente todas esas personas que fueron inicialmente parte de la decisión de traer 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 dar por terminado el día.
En términos de una solución refactorizada, creo que las empresas tienen que ser más tolerantes con el fracaso. Tienes que ser duro con los problemas pero suave con las personas. Si cultivas una cultura donde dices cosas como, “Tenemos que acertar a la primera”, esto es muy perjudicial porque significa que no tendrás menos fracasos. Es un malentendido de la mente humana y la naturaleza humana pensar que si tienes una cultura que tolera el fracaso, en realidad obtienes más fracasos. Sí, obtienes marginalmente más pequeños fracasos, pero lo que obtienes es gente inclinada a reconocer errores y seguir adelante. Si, por el contrario, tienes una cultura de “acertar 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 redoblar la apuesta en esta cosa que no está funcionando solo para preservar su cara y potencialmente moverse a otra empresa para que no tengan que enfrentar las consecuencias de sus errores.
Para resumir, tenemos conocimiento positivo versus conocimiento negativo. El conocimiento positivo es esencialmente sobre resolver problemas; es una especie de inteligencia de doctorado, inteligencia de resolución de problemas, donde tenemos rompecabezas y podemos progresar de una solución a una mejor solución. Es posible evaluar que una solución es mejor que la otra, y el pináculo de este tipo de pensamiento es lograr una solución óptima. Sin embargo, lo que la gente piensa que está buscando - soluciones óptimas que son perfectamente válidas e inmortales - lo que obtienen son soluciones muy efímeras.
Como ejemplo, a lo largo de la vida de Lokad, mi empresa, pasamos por seis generaciones de motores de forecast. El conocimiento positivo es efímero en el sentido de que este conocimiento, esta solución, está en riesgo cuando algo mejor aparece, y simplemente descartarás este pedazo de conocimiento. En Lokad, pasamos por el tedioso ejercicio de reescribir nuestra propia tecnología de forecast desde cero seis veces desde el principio en 2008. Es por eso que digo que el conocimiento positivo es muy efímero porque se vuelve obsoleto rápidamente a medida que aparecen nuevas y mejores soluciones.
Por el contrario, si miras el conocimiento negativo, es una perspectiva completamente diferente. Piensas en términos de errores perversos, y el tipo de inteligencia que quieres capturar es la inteligencia callejera, el tipo que te ayuda a sobrevivir en una mala calle por la noche. El enfoque no está tanto en los rompecabezas o cosas que son muy complicadas de entender e involucran transferencia; se trata más de lo que no sabes o los tabúes. No es lo que no sabes; es lo que la gente no te dirá, o el tipo de cosas donde la gente incluso te mentirá solo porque quieren 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 de progreso; es una mentalidad de supervivencia. Solo quieres sobrevivir para poder luchar otro día. Esa es una perspectiva muy diferente, y eso es exactamente lo que las empresas buscan instintivamente cuando buscan un director de supply chain muy experimentado. Quieren asegurarse de que a través de esta persona, la empresa vivirá otro día. Lo que puede ser sorprendente es que el conocimiento negativo tiende a ser mucho más duradero. Estos son prácticamente los defectos de la naturaleza humana que están involucrados, y no cambian con el tiempo solo porque hay una nueva tecnología, enfoque o método. Estas cosas están aquí para quedarse.
En conclusión, diría que el conocimiento negativo es de suma relevancia para todos los problemas perversos, siendo la supply chain solo el foco de interés de esta conferencia, pero no es el único á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 las supply chains del mundo real. No podemos esperar capturar todo a través de los anti-patrones, pero creo que podemos capturar una parte decente. Después de leer un libro sobre anti-patrones de software, mi opinión subjetiva fue que había adquirido el equivalente a cinco años de experiencia en ingeniería de software en solo 200 páginas. Mi esperanza es que para una colección de anti-patrones de supply chain, también podríamos replicar este efecto, donde alguien podría adquirir algo como cinco años de experiencia en mucho menos tiempo, quizás 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. Las supply chains modernas viven o mueren por los productos de software que las respaldan, y la pregunta es cómo razonamos sobre esos productos de software y cómo elegimos los correctos y los proveedores correctos. A pesar de tener mi buena parte de conflictos de interés, es un problema interesante, y la pregunta es cómo podemos tener una metodología donde incluso si todas las personas tienen sesgos, podemos obtener algún tipo de resultados imparciales del método.
Ahora, responderé las preguntas.
Pregunta: ¿Qué constituye un buen forecast en un entorno de optimización probabilística y cómo medir la calidad? ¿Existe un papel para los enriquecimientos manuales?
Un buen forecast probabilístico tiene métricas para las 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 como la entropía cruzada o la probabilidad se aplican a los forecasts probabilísticos. Más importante aún, habrá cosas que descubrirás 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. Hablamos brevemente de esto en la conferencia anterior sobre optimización experimental. El proceso es el mismo para los forecasts clásicos o probabilísticos. Si quieres tener ejemplos reales de forecasts probabilísticos, esto se tratará extensamente en las conferencias posteriores. Lamento desviarme un poco al responder a esta pregunta.
Pregunta: ¿Qué opinas de usar AI (Appreciative Inquiry) para apoyar tu AI (Artificial Intelligence)? ¿Qué técnicas utilizarás para descubrir lógicamente grandes conjuntos de datos, y por qué están disminuyendo las tasas de conversión a pesar del buen rendimiento general? ¿Qué abordar causando la actividad?
La IA, como un conjunto de algoritmos, es principalmente deep learning en este momento. El deep learning es un conjunto de técnicas que son muy capaces de lidiar con datos altamente desestructurados. La pregunta que realmente deberías hacerte es cómo conectar eso con la realidad. En la 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 agregado cuando miras una empresa muy grande con toneladas de transacciones. Si miras las granularidades que realmente importan, no tienes tantos datos.
La indagación apreciativa, en términos de metodologías, es realmente sobre 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 la ciencia de datos, ¿cuál es una forma alternativa de hacerles creer en la ciencia de datos y en los enfoques basados en decisiones? ¿Cómo empezar pequeño y desplegar a lo grande?
Primero, si tienes personas que no creen en una tecnología, está perfectamente bien. Tomemos a Warren Buffett, por ejemplo. Es un inversor muy rico que pasó su vida invirtiendo en empresas que entiende. Invierte en empresas con modelos de negocio simplistas, como empresas de transporte ferroviario o empresas de alquiler de muebles. Warren Buffett dijo: “No estoy interesado en entender todas esas tecnologías”. Por ejemplo, cuando la gente le preguntó 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. Solo voy a invertir en empresas que entiendo”.
Mi punto es, para la gestión, creo que es una completa ilusión aventurarse en áreas que no entiendes. En algún momento, si no estás dispuesto a hacer el esfuerzo, simplemente no va a funcionar. Ese es el anti-patrón Jedi en juego: la gestión no está dispuesta a hacer ningún esfuerzo, y piensan que simplemente contratar a ingenieros jóvenes e inteligentes hará el truco. Si ese fuera el caso, Amazon no habría tenido el éxito que tuvo. Si fuera posible para una cadena de retail tradicional contratar a unos pocos ingenieros para iniciar un sitio web de ecommerce y competir con Amazon, todos lo habrían hecho. Hasta alrededor de 2005, esas empresas tenían significativamente más recursos y capacidades de ingeniería que la propia Amazon.
El problema es que es una ilusión, y eso es lo que se trata el conocimiento negativo: 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 sobre cosas nuevas. Cuando realmente tomas la buena parte de la nueva tecnología, generalmente 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 súper avanzadas tecnologías de blockchain 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 toneladas de tecnicismos matemáticos accidentales que son muy difíciles, pero esa no es la esencia del problema.
Entonces, mi respuesta sería, si la gerencia quiere creer en cuentos de hadas, no hay mucho que se pueda hacer en esa situación. Si la gerencia está dispuesta a invertir en ciencia de datos, también deberían estar dispuestos a invertir un poco de tiempo en 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, 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
