00:00:13 Desafíos de implementar pruebas de concepto en la cadena de suministro.
00:01:00 Cuando las pruebas de concepto funcionan bien y cómo se diferencia la cadena de suministro.
00:02:29 La cadena de suministro como un problema abierto y las dificultades para medir su éxito.
00:03:31 Limitaciones de las pruebas de concepto en la industria de la cadena de suministro.
00:06:30 Importancia de un enfoque holístico y los tiempos de entrega en la optimización de la cadena de suministro.
00:08:00 Importancia de enfocarse en los aspectos no cambiantes de una iniciativa.
00:08:54 Dificultad para recopilar datos en pruebas de concepto.
00:11:55 Problemas de simplificar una iniciativa solo a la previsión.
00:13:54 Las limitaciones de las previsiones de series temporales.
00:15:17 Experiencias dolorosas con pruebas de concepto y sus deficiencias.
00:17:36 Alternativas a los POC en la evaluación de proveedores de software para soluciones de cadena de suministro.
00:20:25 El futuro de los POC en la industria de la cadena de suministro y sus limitaciones.
00:21:31 Importancia de adoptar un enfoque holístico para la optimización de la cadena de suministro.
00:22:52 Evaluación del rendimiento del proveedor de manera semanal en lugar de depender de los POC.
Resumen
En una entrevista, Joannes Vermorel, fundador de Lokad, y el presentador Kieran Chandler discuten la optimización de la cadena de suministro y las limitaciones de los proofs of concept (POCs). Vermorel explica por qué Lokad a menudo rechaza las solicitudes de POC, citando daños para ambas partes. Él cree que los POC funcionan mejor para problemas estrechamente definidos, como elegir un cliente de correo electrónico, pero fallan en procesos complejos y transformadores como la optimización de la cadena de suministro. Las cadenas de suministro involucran a múltiples partes y presentan un desafío distribuido que los POC a menudo simplifican en exceso. Él aconseja enfocarse en aspectos estables y perspectivas holísticas basadas en datos. Vermorel también sugiere evaluar regularmente el rendimiento del proveedor y finalizar relaciones que no muestren un progreso satisfactorio.
Resumen Extendido
En la entrevista, Kieran Chandler, el presentador, y Joannes Vermorel, fundador de Lokad, mantienen una discusión detallada sobre los proofs of concept (POCs) en el contexto del software de cadena de suministro y sus limitaciones. Vermorel explica por qué Lokad frecuentemente rechaza las solicitudes de POC de posibles clientes, citando posibles daños tanto para la empresa del cliente como para Lokad.
Vermorel comienza reconociendo que los POC han existido durante dos décadas y no son inherentemente perjudiciales. Funcionan de manera efectiva cuando se aplican a un problema estrechamente definido. El arquetipo de una situación en la que un POC funcionaría bien es elegir un cliente de correo electrónico como Microsoft Outlook o Gmail. Este es un problema estandarizado con una solución conocida. El usuario tiene expectativas claras y conoce los puntos problemáticos. Este proceso ya no es transformador; simplemente implica la transición de un cliente de correo electrónico a otro.
Sin embargo, el desafío surge cuando los POC se aplican a la optimización de la cadena de suministro, a lo que Vermorel se refiere como “lo opuesto” a un problema estrechamente definido. Sugiere que es un proceso transformador para una empresa, caracterizándolo como un problema no local que abarca múltiples ubicaciones y potencialmente numerosos países. La complejidad se amplifica debido a la naturaleza interconectada de la cadena de suministro.
Ampliando aún más la idea de un “problema abierto”, Vermorel describe la optimización de la cadena de suministro como la idea de querer optimizar, lo que inherentemente requiere medición. El establecimiento de una medición significativa en términos monetarios requiere un esfuerzo sustancial y las métricas obtenidas son solo el comienzo. El viaje continúa con la refinación de la “receta numérica” para evaluar el impacto de las acciones en las operaciones de la empresa. Ofrece un ejemplo de evaluar el costo preciso de cada faltante de stock o el impacto específico en la lealtad del cliente para cada cliente.
Cuando se le pregunta si los POC son ineficaces exclusivamente para la Supply Chain Quantitativa o para la industria de la cadena de suministro en su conjunto, Vermorel afirma que la mayoría de los problemas de la cadena de suministro son difíciles de enmarcar como POC debido a su naturaleza interconectada. Explica que las cadenas de suministro involucran múltiples partes: proveedores, clientes, almacenes de almacenamiento y plantas de producción. Presentan un desafío distribuido, en oposición a uno localizado, como optimizar un proceso de fabricación de forma aislada.
Vermorel enfatiza que las cadenas de suministro están inherentemente conectadas a proveedores y clientes, lo que dificulta identificar algo que sea a la vez local y significativo. Advierte que si bien es fácil realizar optimizaciones locales en las cadenas de suministro, estos esfuerzos suelen resultar en simplemente trasladar los problemas. Por ejemplo, un esfuerzo significativo para optimizar un producto en una ubicación puede crear inadvertidamente problemas en otra parte de la cadena de suministro.
Vermorel explica que la optimización de la cadena de suministro es desafiante para los POC porque tienden a centrarse en micro-optimizaciones sin considerar el panorama general. Esto puede generar problemas para los proveedores y los clientes. Además, los tiempos de entrega complican aún más el proceso, ya que es difícil optimizar una cadena de suministro en un plazo más corto que el propio tiempo de entrega. Esto a menudo resulta en que los POCs lleven mucho más tiempo del previsto.
Chandler y Vermorel discuten la importancia de mirar el panorama general al intentar optimizar las cadenas de suministro. Mencionan que los POC a menudo no consideran los tiempos de entrega completos necesarios para comprender realmente la cadena de suministro. Vermorel aconseja adoptar un enfoque capitalista en cada paso de la metodología, centrándose en lo que no cambiará independientemente del proveedor o solución elegida.
Un desafío que se enfrenta durante los POCs es recopilar y medir datos. Vermorel cree que no se puede optimizar lo que no se mide, por lo que recopilar datos debe ser una prioridad. Sin embargo, la realidad a menudo dificulta la recopilación de datos para los POCs más de lo esperado. Esto se debe a la complejidad de las situaciones del mundo real, como las redes minoristas con múltiples almacenes, unidades de producción y ubicaciones de distribución.
Vermorel proporciona un ejemplo de cómo puede ser difícil evaluar con precisión la demanda histórica. Problemas como faltantes de stock, promociones y otras anomalías pueden sesgar los datos de pedidos históricos, lo que dificulta comprender los verdaderos patrones de demanda. Cuando los POCs se encuentran con estos problemas, a menudo recurren a métodos clásicos de pronóstico, como pronósticos semanales de series de tiempo. Este enfoque simplifica el problema, pero ignora las complejidades y matices de la optimización de la cadena de suministro.
Backtesting, o utilizar datos históricos para probar pronósticos, es otra herramienta utilizada en la optimización de la cadena de suministro. Si bien funciona desde una perspectiva estadística, Vermorel argumenta que solo representa una fracción del panorama general en la gestión de la cadena de suministro. Por ejemplo, los patrones de compra pueden verse afectados por factores como precios negociados y cantidades mínimas de pedido (MOQ), que no se tienen en cuenta en el backtesting.
Vermorel destaca que la optimización de la cadena de suministro no es un problema unidimensional que se pueda resolver centrándose únicamente en la precisión del pronóstico. Argumenta que los procesos existentes deben ser revisados y ajustados para que sea posible la optimización. El principal problema de centrarse en el pronóstico es que pasa por alto el panorama general y se basa en un tipo específico de pronóstico que puede no ser aplicable a todas las situaciones.
Vermorel señala que las cadenas de suministro se han digitalizado durante décadas, pero muchas empresas aún se basan en hojas de cálculo de Excel y ignoran los números generados por varios sistemas. Sugiere que las empresas deben centrarse en los fundamentos, como consolidar los datos en un lago de datos y crear documentación significativa que refleje la semántica de su cadena de suministro.
Al centrarse en los aspectos estables de una cadena de suministro, como proveedores, unidades de producción, almacenes y canales de distribución, las empresas pueden diseñar métricas que reflejen sus intereses financieros a largo plazo. Vermorel enfatiza que el principal desafío radica en comprender la semántica de los datos y garantizar que los datos correctos estén disponibles para la optimización.
Al considerar alternativas a los POCs, Vermorel propone centrarse en lo que no cambia en una cadena de suministro y buscar un proveedor que pueda proporcionar una perspectiva integral basada en datos. Si bien los POCs pueden ofrecer algunas ideas, advierte contra esperar demasiado de experimentos a pequeña escala, ya que los problemas complejos requieren enfoques más profundos.
También sugiere que trabajar con proveedores no debe ser un compromiso a largo plazo. Las empresas pueden participar en iniciativas lean y evaluar el rendimiento del proveedor semanalmente para asegurarse de que se esté progresando. Si el progreso no es satisfactorio, es mejor terminar la relación temprano en lugar de continuar con un proveedor subóptimo.
Transcripción completa
Kieran Chandler: Hoy vamos a entender exactamente por qué los POC no funcionan y también entender cuáles son las alternativas que están disponibles para un cliente para elegir entre la multitud de software de cadena de suministro que existen. Entonces, Joannes, los POC han estado presentes durante dos décadas, por lo que no todos pueden ser malos. ¿En qué industrias realmente funcionan?
Joannes Vermorel: Los proofs of concept funcionan bien cuando tienes un problema cercano y específico que quieres abordar, cuando no tienes que pensar en posibilidades abiertas masivas. Por ejemplo, el arquetipo de un área donde un POC funcionaría bien sería si te pido que elijas tu cliente de correo electrónico porque has usado un cliente de correo electrónico, digamos Microsoft Outlook o Gmail, durante años. Entonces, sabes qué esperar, conoces tus puntos débiles. Este es un problema bastante estandarizado con soluciones estandarizadas, y harás una comparación muy precisa porque sabes exactamente qué buscar. Para tu empresa, esto es fundamentalmente algo que no es transformador; fue transformador hace décadas cuando las personas comenzaron a usar el correo electrónico en conjunto, pero en este punto, solo se trata de pasar de un cliente de correo electrónico a otro. Los POC funcionan bien para esos problemas súper tácticos y bien definidos. El gran desafío es que la cadena de suministro cuantitativa es algo completamente opuesto. Es algo que transformará fundamentalmente tu empresa y es algo fundamentalmente no local. No puedes ejecutar una cadena de suministro localmente desde tu escritorio. Es porque hay una red que abarca muchas ubicaciones, potencialmente muchos países, que las cosas se complican realmente.
Kieran Chandler: Entonces, ¿qué es lo que caracteriza eso como un problema abierto?
Joannes Vermorel: La cadena de suministro es primero una idea que queremos optimizar, y para optimizar, necesitas medir. Solo el hecho de que quieras medir cosas en euros o dólares requiere una cantidad considerable de esfuerzo para obtener una medición que realmente tenga sentido. La métrica, el punto de partida, es en realidad un viaje para refinar la forma en que tu receta numérica evalúa si estás haciendo algo bueno o malo para tu empresa. Obviamente, servir a los clientes es bueno, tener una enorme cantidad de faltantes de stock es malo, pero la pregunta se convierte en cómo evaluamos el costo preciso de cada faltante de stock, el impacto preciso en la lealtad del cliente para cada cliente en particular.
Kieran Chandler: Entonces, cuando dices que los proofs of concept fundamentalmente no funcionan, ¿es solo para la cadena de suministro cuantitativa que no funcionan, o es para toda la industria de la cadena de suministro en general?
Joannes Vermorel: La mayoría de los problemas de la cadena de suministro son muy difíciles de enmarcar como pruebas de concepto. Por definición, las cadenas de suministro involucran múltiples partes: tienes muchos proveedores, muchos clientes, almacenes de almacenamiento, plantas de producción. Es un desafío muy distribuido en esencia, a diferencia de algo que sería extremadamente local, como la optimización de un proceso de fabricación que está completamente aislado del resto del mundo. Las cadenas de suministro están completamente conectadas con tus proveedores y tus clientes. Entonces, prácticamente por definición, es difícil encontrar algo que sea a la vez local y significativo, porque el problema con las cadenas de suministro es que es muy fácil realizar una optimización local. El punto es que cuando haces eso, generalmente lo que terminas haciendo es simplemente mover problemas. Entonces, sí, has hecho una gran cantidad. Entonces, has creado un problema para tu proveedor y tal vez también para un par de clientes al hacer eso. No has resuelto el panorama general; solo has microoptimizado algo localmente. Eso hace que la cadena de suministro sea muy desafiante para las pruebas de concepto en general. Y luego hay otra capa de dificultad en el caso de Lokad. Porque queremos abordar el futuro y las incertidumbres, están los tiempos de entrega que deben tenerse en cuenta. Entonces, cada vez que estamos lidiando con una industria donde los tiempos de entrega son, digamos, tienes que planificar y ejecutar las cosas pensando tres meses antes. Significa que no importa cómo optimices las recetas numéricas para tu cadena de suministro, una iteración lleva prácticamente tanto tiempo como tu tiempo de entrega para que se cumpla. Entonces, eso significa que realmente no puedes hacer nada en un período de tiempo más corto que tu tiempo de entrega, y más realistamente, necesitarás como dos o tres iteraciones. Entonces, si tienes tiempos de entrega de aproximadamente tres meses, y estamos hablando de dos o tres iteraciones, estamos hablando de seis a nueve meses. No es excesivamente largo para el software empresarial, pero comenzamos a alejarnos mucho de lo que la gente piensa cuando piensa en una prueba de concepto rápida.
Kieran Chandler: Vamos a desglosar eso un poco. Entonces, lo que estás diciendo es que desde un punto de vista de prueba de concepto, básicamente solo se está viendo una imagen pequeña, y para que una solución realmente funcione y se demuestre a sí misma, necesita ver todo el panorama general. Y luego, la segunda cosa que mencionaste tiene que ver con los tiempos de entrega, y estás diciendo que una prueba de concepto normalmente es bastante corta, por lo que no estamos teniendo en cuenta los tiempos de entrega completos para realmente obtener los resultados y comprender lo que está sucediendo. ¿Cuánto tiempo deberías perseverar realmente con una prueba de concepto antes de ver algún resultado?
Joannes Vermorelr: El punto es que si esperas hasta que finalices tus mediciones y esté absolutamente claro que puedes medir los beneficios y codificarlos, llevará demasiado tiempo. Es por eso que típicamente, lo que sugerimos es tener una metodología altamente capitalista en cada paso y que esté impulsada por la visión. Lo que quiero decir con capitalista en cada paso es que no importa cómo quieras optimizar tu cadena de suministro, necesitarás datos para ejecutar esta optimización. El proceso llevará un poco de tiempo, pero es independiente de qué proveedor o solución elijas, incluso si quieres hacerlo internamente o con una empresa externa. Tendrás que hacer este proceso. Si puedes ejecutar tu iniciativa de manera que te enfoques en lo que no cambiará con respecto al proveedor que se elija, si es que se elige alguno, al final de la iniciativa, entonces puedes ser altamente capitalista. Por ejemplo, no puedes optimizar lo que no mides, por lo que debes comenzar a recopilar datos para las mediciones. Este esfuerzo en sí probablemente vaya más allá de lo que crees que es elegible para un esfuerzo del tamaño de una prueba de concepto.
Kieran Chandler: Eso probablemente sea bastante sorprendente para muchos de nuestros espectadores porque, en las pruebas de concepto, recopilar los datos debería ser la parte fácil que se suministra cuando se inicia la prueba de concepto. Entonces, ¿por qué es tan difícil?
Joannes Vermorel: Siempre es difícil porque la realidad tiene sus propias formas de asegurarse de que tus intentos de prueba de concepto fracasen de la manera más miserable. Pero más en serio, tomemos una situación real de lo que está sucediendo. Digamos que tienes una red minorista que involucra un par de almacenes, un par de unidades de producción y tal vez un par de ubicaciones de distribución. Ahora comienzas tu iniciativa donde dices.
Kieran Chandler: Hablemos de los clientes que están satisfechos con cómo los atiendes. Entonces, te das cuenta de que quieres comenzar tu prueba de concepto y descubres que obtener todos los datos transaccionales es más difícil de lo que parecía al principio. ¿Por qué es eso?
Joannes Vermorel: Bueno, por ejemplo, podrías decir que los pedidos de los clientes deberían ser fáciles. Sí y no, porque puedes tener muchas situaciones extrañas, como un cliente que te envía un pedido que no puedes cumplir debido a un faltante de stock. Registras diligentemente en el sistema que el pedido no se pudo cumplir. Al día siguiente, el cliente realiza otro pedido, aún más grande. ¿Por qué? Porque no cumpliste con el pedido del día anterior. Pero si hubieras cumplido con el primer pedido, probablemente no habría habido un segundo pedido al día siguiente. Entonces, quieres reflejar la demanda histórica, no solo el flujo histórico de pedidos sin procesar del cliente que se vieron afectados por diversas razones. Te das cuenta de que es más complicado de lo que parece.
Kieran Chandler: Entonces, ¿qué suele suceder con una iniciativa de prueba de concepto cuando te enfrentas a todos esos problemas?
Joannes Vermorel: Tratas de encontrar formas de simplificar los problemas y inevitablemente vuelves a un clásico de prueba de concepto de pronóstico, como un pronóstico de series de tiempo semanal. Piensas en términos de pronosticar la demanda en función de la demanda histórica, y puedes realizar pruebas retrospectivas de inmediato. Ignoras los faltantes de stock, las promociones y todos los factores extraños. El resultado final es algo que se ajusta a la definición de una prueba de concepto, pero al hacer eso, te has desviado por completo del problema que estabas tratando de resolver.
Kieran Chandler: Hablemos un poco sobre las pruebas retrospectivas. Eso implica mirar datos históricos en el pasado, hacer pronósticos y comparar los dos. ¿Por qué las pruebas retrospectivas realmente no funcionan?
Joannes Vermorel: Las pruebas retrospectivas funcionan desde una perspectiva estadística, pero tienen límites. Desde una perspectiva de la cadena de suministro, las pruebas retrospectivas son solo una pequeña herramienta numérica que es solo una fracción de todo el panorama. Si comienzas a pensar en optimizar los patrones de compra de tus equipos, resulta que tal vez todas esas cantidades mínimas de pedido no están talladas en piedra. Tal vez esas compras poco frecuentes se deben al hecho de que tu equipo de compras negoció precios bajos, pero con cantidades mínimas de pedido excesivamente altas. Esto obliga a tu equipo a poner un retraso adicional entre los pedidos de compra, lo que complica todo e infla los tiempos de entrega.
Lo que estoy diciendo es que realizar la optimización no es solo algo unidimensional, como disminuir el error desde una perspectiva de precisión del pronóstico. También se trata de abrazar y revisar todos los procesos existentes y ajustar lo que se está haciendo cuando sea posible para que la optimización realmente sea posible. Además, debes pensar en lo que realmente estás midiendo. El problema es que estos pequeños proyectos de prueba de concepto, que inevitablemente vuelven a los puntos de referencia de precisión de series de tiempo, terminan teniendo un error expresado como un porcentaje en lugar de dólares. Nuevamente, estamos muy lejos de los fundamentos comerciales.
Kieran Chandler: Entonces, ¿el verdadero problema con el pronóstico es que te estás enfocando solo en ese aspecto y no estás viendo el panorama general? Es un tipo muy específico de pronóstico. Reunir todos los datos relevantes es difícil, por lo que puedes estar seguro de que tu prueba de concepto será un pronóstico clásico de series de tiempo con datos semanales de entrada y pronóstico semanal de salida, y se supone que eso es todo. Supongo que lo que estamos describiendo hoy proviene de un poco de dolor de experiencia, las cosas que has intentado en el pasado y las pruebas de concepto que has realizado. Entonces, ¿cuáles son algunos de los problemas clave que has experimentado cuando has realizado pruebas de concepto?
Joannes Vermorel: La peor parte es que a veces puedes tener éxito por completo en la prueba de concepto, y eso probablemente fue lo que más dolió. Como empresa de software empresarial, no ganas cada oportunidad que se presenta, por lo que perder oportunidades es solo una cuestión de vida. Lo que realmente duele es cuando ganas la prueba de concepto porque, sí, en la prueba de concepto te desempeñas mejor, potencialmente por un margen enorme, y luego cuando intentas traducir eso a una situación de producción, las cosas se desmoronan por completo y no cumplen ninguna de las expectativas del cliente. Te das cuenta de que es porque pasaste de un problema de juguete a un problema del mundo real. Tal vez todo lo que habías hecho para el problema de juguete funcionaba muy bien en este alcance limitado con una métrica bien definida, pero ignoraba por completo todos los fundamentos comerciales. Cuando pasas a la situación de producción, te das cuenta de que tu solución ni siquiera se acerca a proporcionar una respuesta.
La peor parte es que debido a que las cadenas de suministro se han digitalizado durante un par de décadas, para las grandes empresas, te das cuenta de que la solución que estás llevando a la empresa va a ser como los intentos anteriores. Producirá una masa de números que serán completamente ignorados por todos. Inevitablemente, todos los equipos de cadena de suministro vuelven a sus hojas de cálculo habituales, ignorando por completo los números disfuncionales producidos por otro sistema más.
Kieran Chandler: Veamos las cosas ahora desde la perspectiva de una empresa. Lo bueno de las pruebas de concepto es que puedes ver las diferentes formas en que los proveedores de software abordan un problema y cómo realmente están reaccionando a ciertos desafíos. Aparte de eso, ¿qué alternativas pueden usar las empresas en lugar de una prueba de concepto? ¿Qué más podrían hacer para ver cómo se desempeñan diferentes empresas?
Joannes Vermorel: La alternativa es centrarse en los fundamentos. Señalé que existe el desafío de consolidar los datos. La forma moderna de hacerlo en la actualidad es construir un lago de datos. El siguiente paso es proporcionar alguna documentación significativa desde una perspectiva de cadena de suministro. Para tener éxito, debes centrarte en lo que no cambia. Tu cadena de suministro probablemente no cambiará en sus formas más fundamentales. Seguirás teniendo proveedores, unidades de producción, almacenes y canales de distribución. Hay muchas cosas que se espera que sean relativamente estables, así que concéntrate en eso. Cuando consolides los datos, también consolida la documentación relevante porque el gran desafío siempre es la semántica de los datos.
¿Qué significa estos datos? Cuando tenemos una fecha de pedido, ¿fue la fecha en que produjiste el pedido para enviarlo al proveedor, la fecha en que se registró la entrada en tu sistema o la fecha en que tu proveedor confirmó la recepción del pedido? Hay una docena de posibilidades. La pregunta es, ¿dónde se documentan todas esas cosas? Si no tienes acceso a los datos y a la semántica de los datos, no hay esperanza de optimizar nada. Nuevamente, por ejemplo, cuando describí un enfoque de cadena de suministro cuantitativa, sí, existe Lokad como una plataforma de computación en la nube para ejecutar a gran escala todas esas recetas numéricas. Pero las cosas que son altamente capitalistas para el cliente son la consolidación de todos los datos relevantes, la comprensión de la semántica de la cadena de suministro, la creación de métricas que realmente reflejen el interés financiero a largo plazo de tu empresa, lo cual es difícil. La creación de procesos que se adapten bien a las limitaciones físicas de tu cadena de suministro, y todo eso está dentro y en gran medida independiente de la herramienta que uses para ejecutar esos cálculos numéricos.
Kieran Chandler: Si comenzamos a unir las cosas y concluimos hoy, las pruebas de concepto han existido en la industria de la cadena de suministro durante décadas. Quiero decir, ¿realmente puedes imaginar un momento en que las pruebas de concepto no existan en absoluto?
Joannes Vermorel: Obviamente, todavía habrá jóvenes que no saben nada mejor y que pedirán una prueba de concepto más. Sabes, eso es solo un hecho de la vida. Y tal vez tengan razón, porque nuevamente, hay situaciones, incluso en las cadenas de suministro, donde una prueba de concepto es realmente el camino a seguir. Si tienes una nueva impresora de códigos de barras que parece ser compatible con el sistema, que tiene las viejas impresoras de códigos de barras, pero la nueva es simplemente mejor, más rápida, más barata, más delgada, y demás. Este es un problema donde puedes comprar una impresora de códigos de barras más y probarla en tu almacén favorito. Entonces, hay situaciones y problemas donde una prueba de concepto es simplemente el camino a seguir. Sin embargo, cuando quieres pensar en un desafío de optimización de toda la cadena de suministro que realmente está tomando una perspectiva holística de tu cadena de suministro, diría que no esperes demasiado de experimentos a pequeña escala. Es solo que inevitablemente te darás cuenta de que el problema es complejo y si no te esfuerzas lo suficiente, simplemente fracasarás porque ni siquiera has intentado lo suficiente en el problema.
Kieran Chandler: Entonces, como mensaje clave final de hoy, ¿es que las pruebas de concepto pueden darte cierta visión, pero no esperes demasiado y realmente no funcionan en su totalidad?
Joannes Vermorel: Sí, y lo opuesto a una prueba de concepto no debería ser un compromiso de diez años con un proveedor. Quiero decir, eso también es otra cosa. No es porque no estés haciendo una prueba de concepto que no puedas decir: “Supongo que podemos trabajar con un proveedor. Lo que nos gustaría es comenzar iniciativas, ya sabes, una industria lean, para que no tenga que ser muy costoso, y luego avanzaremos contigo semana tras semana”. En lugar de prestar atención al hecho de que se supone que debemos enmarcar las iniciativas dentro de diez semanas, es más como, ¿te satisface la velocidad de progreso de la iniciativa? ¿De una semana a otra, estás avanzando a un ritmo satisfactorio?
Si eliges un proveedor y después de tres semanas te das cuenta de que las cosas siguen siendo muy lentas, entonces deberías renunciar, incluso en un período de tiempo más corto que una prueba de concepto típica. La pregunta es más bien, piensas diez años en el futuro, pero esa es tu visión. Te enfocas en un elemento que será altamente capitalista para tu empresa durante la próxima década. Pero cuando se trata de sacar a un proveedor empresarial por la puerta porque simplemente no están cumpliendo, es más una evaluación semanal en la que revisas si las cosas están progresando y si hay algún tipo de impulso que se está construyendo. Estás buscando todas esas pequeñas señales, con una planificación indefinida en mente.
Kieran Chandler: Tendremos que dejarlo aquí, pero veremos si hemos asustado a todos.
