00:00:13 Desafíos de implementar pruebas de concepto en la supply chain.
00:01:00 Cuándo funcionan bien las pruebas de concepto y cómo difiere la supply chain.
00:02:29 La supply chain 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 supply chain.
00:06:30 Importancia de un enfoque holístico y de los lead times en la optimización de la supply chain.
00:08:00 Importancia de enfocarse en los aspectos que no cambian de una iniciativa.
00:08:54 Dificultad de recopilar datos en las pruebas de concepto.
00:11:55 Problemas de simplificar una iniciativa a meramente hacer forecast.
00:13:54 Las limitaciones de los forecast de series de tiempo.
00:15:17 Experiencias dolorosas con las pruebas de concepto y sus inconvenientes.
00:17:36 Alternativas a las pruebas de concepto para evaluar proveedores de software para soluciones de supply chain.
00:20:25 El futuro de las pruebas de concepto en la industria de la supply chain y sus limitaciones.
00:21:31 Importancia de adoptar un enfoque holístico para la optimización de la supply chain.
00:22:52 Evaluar el rendimiento del proveedor de forma semanal en lugar de depender de las pruebas de concepto.
Resumen
En una entrevista, Joannes Vermorel, fundador de Lokad, y el presentador Kieran Chandler discuten optimización de supply chain y las limitaciones de las pruebas de concepto (POCs). Vermorel explica por qué Lokad a menudo rechaza solicitudes de POCs, citando perjuicios para ambas partes. Considera que los POCs funcionan mejor para problemas definidos de forma muy precisa, como elegir un cliente de correo electrónico, pero resultan insuficientes en procesos complejos y transformadores como la optimización de la supply chain. Las supply chains involucran múltiples partes y representan un desafío distribuido que los POCs suelen simplificar en exceso. Aconseja enfocarse en aspectos estables y adoptar perspectivas holísticas y basadas en datos. Además, Vermorel sugiere evaluar regularmente el desempeño de los proveedores y terminar las relaciones que no muestren un progreso satisfactorio.
Resumen Extendido
En la entrevista, el presentador Kieran Chandler y Joannes Vermorel, fundador de Lokad, entablan una discusión detallada sobre las pruebas de concepto (POCs) en el contexto del software de supply chain y sus limitaciones. Vermorel explica por qué Lokad rechaza con frecuencia las solicitudes de POCs de posibles clientes, citando un posible perjuicio tanto para la empresa del cliente como para Lokad.
Vermorel comienza reconociendo que los POCs han existido durante dos décadas y no son intrínsecamente perjudiciales. Funcionan de manera efectiva cuando se aplican a un problema definido de forma precisa. 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. Se trata de un problema estandarizado con una solución conocida. El usuario tiene expectativas claras y conoce los puntos críticos. Este proceso ya no es transformador; simplemente implica pasar de un cliente de correo electrónico a otro.
Sin embargo, el desafío surge cuando los POCs se aplican a la optimización de la supply chain, a la que Vermorel se refiere como “lo opuesto” a un problema definido de forma precisa. 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 ve amplificada debido a la naturaleza interconectada de la supply chain.
Profundizando en la idea de un “problema abierto”, Vermorel describe la optimización de la supply chain como el deseo de optimizar, lo que requiere intrínsecamente medición. El establecimiento de una medida significativa en términos monetarios requiere un esfuerzo considerable, y las métricas obtenidas son solo el comienzo. El recorrido continúa con el perfeccionamiento de la “receta numérica” para evaluar el impacto de las acciones en las operaciones de la empresa. Ofrece un ejemplo para evaluar el costo preciso de cada faltante de stock o el impacto específico en la lealtad del cliente.
Cuando se le pregunta si los POCs son ineficaces exclusivamente para la Supply Chain Quantitativa o para la industria de la supply chain en su conjunto, Vermorel afirma que la mayoría de los problemas de supply chain son difíciles de encuadrar como POCs debido a su naturaleza interconectada. Explica que las supply chains involucran múltiples partes: proveedores, clientes, almacenes, y plantas de producción. Representan un desafío distribuido, a diferencia de uno localizado, como optimizar un proceso de manufactura de forma aislada.
Vermorel destaca que las supply chains están intrínsecamente conectadas con proveedores y clientes, lo que hace difícil identificar algo que sea tanto local como significativo. Advierte que, aunque es fácil realizar optimizaciones locales en las supply chains, estos esfuerzos suelen resultar en simplemente trasladar los problemas. Por ejemplo, un esfuerzo considerable para optimizar un producto en una ubicación puede, inadvertidamente, crear problemas en otra parte de la supply chain.
Vermorel explica que la optimización de la supply chain es un desafío para los POCs porque tienden a centrarse en micro-optimizaciones sin considerar el panorama general. Esto puede ocasionar problemas para proveedores y clientes. Además, los lead times complican aún más el proceso, ya que es difícil optimizar una supply chain en un plazo inferior al propio lead time. Esto a menudo resulta en que los POCs tarden mucho más de lo anticipado.
Chandler y Vermorel discuten la importancia de tener en cuenta el panorama general al intentar optimizar las supply chains. Mencionan que los POCs a menudo no consideran los lead times completos necesarios para una verdadera comprensión de la supply chain. Vermorel aconseja adoptar un enfoque capitalista en cada paso de la metodología, centrando la atención en lo que no cambiará independientemente del proveedor o la solución elegida.
Un desafío al que se enfrentan durante los POCs es la recopilación y medición de datos. Vermorel opina que no se puede optimizar lo que no se mide, por lo que la recopilación de datos debe ser una prioridad. Sin embargo, la realidad a menudo hace que reunir datos para los POCs sea más difícil de lo esperado. Esto se debe a la complejidad de situaciones del mundo real, como redes minoristas con múltiples almacenes, unidades de producción y puntos de distribución.
Vermorel ofrece un ejemplo de cómo la demanda histórica puede ser difícil de evaluar con precisión. Problemas como los faltantes de stock, promociones y otras anomalías pueden sesgar los datos históricos de pedidos, dificultando la comprensión de los verdaderos patrones de demanda. Cuando los POCs se encuentran con estos problemas, a menudo recurren a los métodos clásicos de forecasting, como los forecast de series de tiempo semanales. Este enfoque simplifica el problema pero ignora las complejidades y matices de la optimización de la supply chain.
Backtesting, o el uso de datos históricos para probar forecast, es otra herramienta utilizada en la optimización de la supply chain. Aunque funciona desde una perspectiva estadística, Vermorel argumenta que solo representa una fracción del panorama general en la gestión de supply chain. Por ejemplo, los patrones de compra pueden verse afectados por factores como precios negociados y cantidades mínimas de pedido (MOQs), que no se tienen en cuenta en el backtesting.
Vermorel destaca que la optimización de la supply chain no es un problema unidimensional que se pueda resolver centrándose únicamente en la forecasting accuracy. Argumenta que es necesario revisar y ajustar los procesos existentes para hacer posible la optimización. El principal problema de centrarse en el forecast es que se ignora el panorama general y se depende de un tipo específico de forecast que puede no ser aplicable a todas las situaciones.
Vermorel señala que las supply chains han sido digitalizadas durante décadas, pero muchas empresas aún dependen de hojas de Excel e ignoran los números generados por diversos sistemas. Sugiere que las empresas deberían enfocarse en lo fundamental, como consolidar datos en un data lake y crear una documentación significativa que refleje la semántica de su supply chain.
Al centrarse en los aspectos estables de una supply chain, como proveedores, unidades de producción, almacenes y canales de distribución, las empresas pueden desarrollar 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 en asegurar 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 supply chain y buscar un proveedor que pueda ofrecer una perspectiva holística y basada en datos. Aunque los POCs pueden ofrecer algunas ideas, advierte que se espere 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 debería ser un compromiso a largo plazo. Las empresas pueden participar en iniciativas lean y evaluar el rendimiento del proveedor de forma semanal para asegurar que se logre progreso. Si el avance es insatisfactorio, 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 POCs no funcionan y también a comprender cuáles son las alternativas disponibles para un cliente al elegir entre la multitud de software de supply chain que existen. Entonces, Joannes, los POCs han existido durante dos décadas, por lo que no pueden ser todos malos. ¿En qué industrias funcionan realmente?
Joannes Vermorel: Las pruebas de concepto funcionan bien cuando se tiene un problema preciso y limitado que se desea abordar, cuando no es necesario pensar en posibilidades masivas y abiertas. Por ejemplo, el arquetipo de un área en la que un POC funcionaría bien sería si te pidiera que eligieras tu cliente de correo electrónico, ya que has utilizado un cliente de correo electrónico, digamos Microsoft Outlook o Gmail, durante años. Así, sabes lo que debes esperar, conoces tus puntos críticos. Se trata de 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; lo fue hace décadas cuando la gente empezó a usar el correo electrónico, pero a estas alturas, no es más que pasar de un cliente de correo electrónico a otro. Los POCs funcionan bien para esos problemas súper tácticos y bien definidos. El gran desafío es que la Supply Chain Quantitativa es algo así como lo opuesto. Es algo que transformará fundamentalmente tu empresa, y es, en esencia, algo completamente no local. No puedes ejecutar una supply chain de forma local desde tu escritorio. Es porque existe una red que abarca muchas ubicaciones, potencialmente muchos países, lo que complica realmente las cosas.
Kieran Chandler: Entonces, ¿qué es lo que caracteriza eso como un problema abierto?
Joannes Vermorel: La supply chain es, ante todo, la idea de que queremos optimizar, y para optimizar, es necesario medir. El mero hecho de querer medir las cosas en euros o dólares requiere un esfuerzo considerable para obtener una medición que realmente tenga sentido. La métrica, el punto de partida, es en realidad un camino para perfeccionar la forma en que tu receta numérica evalúa si estás haciendo algo bueno o malo para tu empresa. Obviamente, atender a los clientes es bueno, tener una cantidad enorme de faltantes de stock es malo, pero la cuestión es exactamente cómo evaluar el costo preciso de cada faltante de stock, el impacto preciso en la lealtad del cliente para cada cliente.
Kieran Chandler: Entonces, cuando dices que las pruebas de concepto fundamentalmente no funcionan, ¿es solo para la Supply Chain Quantitativa que no funcionan, o es para la industria de la supply chain en su conjunto?
Joannes Vermorel: La mayoría de los problemas de la supply chain son muy difíciles de encuadrar como pruebas de concepto. Por definición, las supply chains involucran múltiples partes: tienes muchos proveedores, muchos clientes, almacenes y plantas de producción. Es, en esencia, un desafío muy distribuido, a diferencia de algo que sería extremadamente local, como la optimización de un proceso de manufactura que está completamente aislado del resto del mundo. Las supply chains están completamente conectadas a tus proveedores y clientes. Así que, prácticamente, por definición, es difícil encontrar algo que sea tanto local como significativo, porque el problema con las supply chains es que es muy fácil realizar una optimización local. El punto es que cuando haces eso, generalmente lo que ocurre es que simplemente se trasladan los problemas. Entonces, sí, has hecho un gran esfuerzo. Es decir, has creado un problema para tu proveedor y quizá para un par de clientes al mismo tiempo al hacer eso. No has resuelto el panorama general; solo has micro-optimitado algo de forma local. Eso hace que la supply chain 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, hay que tener en cuenta los lead times. Así que, siempre que tratamos con una industria en la que los lead times son, digamos, en la que debes planificar y ejecutar las cosas pensando con tres meses de antelación, significa que, sin importar cómo optimices las recetas numéricas para tu supply chain, una iteración toma prácticamente tanto como tu lead time para materializarse. Esto significa que realmente no puedes hacer nada en un plazo inferior a tu lead time, y más realísticamente, necesitarás dos o tres iteraciones. Así, si tienes lead times de aproximadamente tres meses, y estamos hablando de dos o tres iteraciones, estamos hablando de seis a nueve meses. No es excesivamente largo para un software empresarial, pero empezamos a alejarnos bastante de lo que la gente imagina cuando piensa en una prueba de concepto rápida.
Kieran Chandler: Desenredemos eso un poco. Entonces, lo que estás diciendo es que, en un proof of concept, básicamente se está observando solo una pequeña parte, y para que una solución realmente funcione y se demuestre a sí misma, necesita contemplar la imagen completa. Y luego, lo segundo que mencionaste tiene que ver con los tiempos de entrega, y estás diciendo que un proof of concept normalmente es bastante corto, por lo que no se toman en cuenta los tiempos de entrega completos para obtener realmente los resultados y entender lo que está sucediendo. ¿Cuánto tiempo deberías perseverar realmente con un proof of concept antes de que veas algún resultado?
Joannes Vermorelr: La cuestión es que si esperas hasta finalizar tus mediciones y quede absolutamente claro que puedes medir los beneficios y codificar, te tomará demasiado tiempo. Por eso, normalmente, lo que sugerimos es tener una metodología que sea altamente capitalista en cada paso y esté impulsada por la visión. Con “altamente capitalista en cada paso” me refiero a que, sin importar cómo quieras optimizar tu supply chain, necesitarás datos para ejecutar esta optimización. El proceso tomará un poco de tiempo, pero es algo independiente de cualquier proveedor o solución que elijas, incluso si lo haces internamente o con una compañía externa. Necesitarás realizar este proceso. Si puedes ejecutar tu iniciativa de manera que te enfoques en lo que no cambiará respecto al proveedor que se elija, en caso de haber 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 muy probablemente superará lo que piensas que es elegible para un esfuerzo del tamaño de un proof of concept.
Kieran Chandler: Eso probablemente sea bastante sorprendente para muchos de nuestros espectadores, porque en los proof of concept, la recolección de datos debería ser la parte fácil que se provee al iniciar el proof of concept. Entonces, ¿por qué es tan difícil?
Joannes Vermorel: Siempre es difícil porque la realidad tiene sus propias maneras de asegurarse de que tus intentos de proof of concept fallen 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 de retail que involucra un par de almacenes, un par de unidades de producción y quizás un par de localizaciones de distribución. Ahora inicias tu iniciativa diciendo.
Kieran Chandler: Hablemos de los clientes que están satisfechos con cómo los atiendes. Entonces, te das cuenta de que quieres iniciar tu proof of concept, 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 clientes deberían ser fáciles. Sí y no, porque pueden ocurrir muchas situaciones extrañas, como que un cliente te envíe un pedido que no puedes satisfacer debido a un faltante de stock. Registras diligentemente en el sistema que el pedido no pudo ser cumplido. Al día siguiente, el cliente realiza otro pedido, incluso mayor. ¿Por qué? Porque no cumpliste con el pedido del día anterior. Pero, si hubieras cumplido el primer pedido, probablemente no habría habido un segundo pedido al día siguiente. Así que, deseas reflejar la demanda histórica, no solo el flujo histórico bruto de pedidos del cliente que se vieron impactados por diversas razones. Te das cuenta de que es más complicado de lo que parece.
Kieran Chandler: Entonces, ¿qué sucede típicamente con una iniciativa de proof of concept cuando enfrentas todos esos problemas?
Joannes Vermorel: Intentas encontrar formas de simplificar los problemas e inevitablemente regresas a un proof of concept clásico de forecast, como un forecast de series temporales semanal. Piensas en términos de forecast de la demanda basado en la demanda histórica, y puedes realizar back testing de eso de inmediato. Ignoras los faltantes de stock, las promociones y todos los factores extraños. El resultado final es algo que encaja con la definición de un proof of concept, pero al hacer eso, te has desviado completamente del problema que estabas tratando de resolver.
Kieran Chandler: Hablemos un poco sobre el back testing. Eso es observar los datos históricos del pasado, hacer forecasts y comparar ambos. ¿Por qué es que el back testing realmente no funciona?
Joannes Vermorel: El back testing funciona desde una perspectiva estadística, pero tiene límites. Desde una perspectiva de supply chain, el back testing es solo una pequeña herramienta numérica que es apenas una fracción del panorama completo. Si comienzas a pensar en optimizar los patrones de compra de tus equipos, resulta que quizás todas esas cantidades mínimas de pedido no están grabadas en piedra. Tal vez esas compras infrecuentes se deban a que tu equipo de compras negoció precios bajos, pero con cantidades mínimas de pedido excesivamente altas. Esto obliga a tu equipo a colocar un retraso adicional entre 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 simplemente algo unidimensional, como disminuir el error desde una perspectiva de precisión en el forecast. 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 se haga posible. Además, necesitas pensar en lo que realmente estás midiendo. El problema es que estos pequeños proyectos de proof of concept, que inevitablemente vuelven a los benchmarks de precisión de series temporales, terminan teniendo un error expresado como un porcentaje en lugar de dólares. Nuevamente, estamos muy lejos de cualquier fundamento empresarial.
Kieran Chandler: Entonces, ¿el verdadero problema con el forecast es que te estás enfocando solamente en ese aspecto y no en la imagen completa? Es un tipo muy específico de forecast. Reunir todos los datos relevantes es difícil, por lo que puedes estar seguro de que tu proof of concept va a ser un forecast clásico de series temporales con datos semanales de entrada y forecast semanal de salida, y se supone que eso es todo. Supongo que lo que estamos describiendo hoy proviene un poco del dolor de la experiencia, de las cosas que has intentado en el pasado y de los POCs que has hecho. Entonces, ¿cuáles son algunos de los problemas clave que has experimentado cuando has realizado POCs?
Joannes Vermorel: Lo peor es que, a veces, puedes tener un éxito total en el POC, y eso fue probablemente lo que más dolió. Como empresa de software empresarial, no ganas cada lead que se te presenta, así que perder leads es simplemente parte de la vida. Lo que realmente duele es cuando ganas el POC porque, sí, en el POC rindes al máximo, potencialmente con un margen enorme, y luego, cuando intentas trasladarlo a una situación de producción, las cosas se descontrolan completamente y no cumplen con ninguna de las expectativas del cliente. Te das cuenta de que es porque pasaste de un problema de juguete a un problema real. Tal vez lo que habías hecho para el problema de juguete funcionaba muy bien en este alcance limitado con una métrica bien definida, pero ignoró por completo todos los fundamentos empresariales. Al pasar a la situación de producción, te das cuenta de que tu solución ni siquiera se acerca a proporcionar una respuesta.
Lo peor es que, debido a que los supply chains han sido digitalizados durante un par de décadas, para las grandes empresas, te das cuenta de que la solución que estás introduciendo en la compañía será como los intentos previos. Producirá una masa de números que serán completamente ignorados por todos. Inevitablemente, todos los equipos de supply chain vuelven a sus hojas de Excel habituales, ignorando por completo los números disfuncionales producidos por otro sistema más.
Kieran Chandler: Ahora miremos las cosas desde la perspectiva de una empresa. Lo bueno de los POCs es que puedes ver las diferentes formas en que los proveedores de software abordan un problema y cómo reaccionan de hecho a ciertos desafíos. Además de eso, ¿cuáles son las alternativas que las empresas pueden utilizar en lugar de un POC? ¿Qué más podrían hacer para ver cómo se desempeñan diferentes compañías?
Joannes Vermorel: La alternativa es centrarse en lo fundamental. Estaba señalando que existe el desafío de consolidar datos. La forma moderna de hacerlo actualmente es construir un data lake. El siguiente paso es proporcionar una documentación significativa desde una perspectiva de supply chain. Para tener éxito, necesitas centrarte en lo que no cambia. Tu supply chain 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 datos, consolida también la documentación relevante, porque el gran desafío siempre es la semántica de los datos.
¿Qué significan estos datos? Cuando tenemos una fecha de pedido, ¿se refería a la fecha en que generaste el pedido para enviarlo al proveedor, a la fecha en que se registró la entrada en tu sistema, o a la fecha en que tu proveedor confirmó haber recibido el pedido? Hay una docena de posibilidades. La pregunta es, ¿dónde está documentado todo eso? 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 Supply Chain Quantitativa, sí, está Lokad como una plataforma de computación en la nube para ejecutar a escala todas esas recetas numéricas. Pero lo que es altamente capitalista para el cliente es la consolidación de todos los datos relevantes, entender la semántica del supply chain, elaborar métricas que reflejen verdaderamente el interés financiero a largo plazo de tu empresa, lo cual es difícil. Elaborar los procesos que funcionen bien con las limitaciones físicas de tu supply chain, y todo eso está internamente y es en gran medida independiente del conjunto de herramientas que utilizas para ejecutar esos cálculos numéricos.
Kieran Chandler: Si empezamos a juntar todo y a concluir hoy, los POCs han existido en la industria de supply chain por décadas. Quiero decir, ¿realmente puedes imaginar un tiempo en el que los POCs no existan en absoluto?
Joannes Vermorel: Obviamente, todavía habrá jóvenes que no saben mejor y que pedirán otro PoC. Sabes, eso es simplemente un hecho de la vida. Y tal vez tengan razón, porque, de nuevo, hay situaciones, incluso en supply chains, donde un PoC 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 ágil y demás. Este es un problema en el que puedes comprar una impresora de códigos de barras más y probarla en tu almacén favorito. Entonces, hay situaciones y problemas en los que un PoC es simplemente la opción a seguir. Sin embargo, cuando quieres pensar en un desafío de optimización a nivel de supply chain que realmente adopte una perspectiva holística sobre tu supply chain, diría que no esperes demasiado de experimentos a pequeña escala. Es simplemente que, inevitablemente, te darás cuenta de que el problema es complejo, y si no te esfuerzas lo suficiente, simplemente fallarás porque ni siquiera lo intentaste lo suficiente.
Kieran Chandler: Entonces, como mensaje clave final de hoy, ¿es que los PoCs pueden darte cierto tipo de perspectiva, pero no esperes demasiado, y en realidad no funcionan en su totalidad?
Joannes Vermorel: Sí, y lo opuesto a un PoC no debería ser un compromiso de diez años con un proveedor. Quiero decir, esa es también otra cosa. No es porque no estés haciendo un PoC que no puedas decir, “Supongo que podemos trabajar con un proveedor. Lo que nos gustaría es iniciar iniciativas, ya sabes, una industria lean, así que no tiene que ser muy costosa, y luego simplemente avanzaremos contigo semana tras semana.” En lugar de prestar atención al hecho de que se supone que debemos enmarcar las iniciativas en un plazo de diez semanas, es más bien, ¿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 aún parecen muy lentas, entonces deberías abandonar, incluso en un plazo más corto que el de un PoC típico. La pregunta es más bien: piensas a diez años vista, pero esa es tu visión. Te concentras en un elemento que será altamente capitalista para tu empresa durante la próxima década. Pero cuando se trata de echar a un proveedor empresarial porque simplemente no está cumpliendo, es más bien una evaluación semanal en la que revisas si las cosas están progresando y si se está generando algún tipo de impulso. Estás buscando todas esas pequeñas señales, con una planificación indefinida en mente.
Kieran Chandler: Vamos a tener que dejarlo ahí, pero tendremos que ver si hemos asustado a todos.
