00:00:00 Coste oculto de los ajustes manuales de previsiones
00:04:34 La escasez de planificadores expertos dana la practica
00:09:08 La granularidad del software infla el trabajo de revision
00:13:42 Arreglar el software de prevision y permitir correcciones rapidas
00:18:16 Integrar el conocimiento del practicante en el sistema
00:22:50 Incentivos de proveedores perpetuan la complejidad dependiente de overrides
00:27:24 La inercia organizativa conserva paradigmas obsoletos
00:31:58 La adopcion tecnologica sigue patrones historicos previsibles
00:36:32 Reasignar responsabilidad a sistemas y scientists
00:41:06 Empresa y proveedor comparten responsabilidad algoritmica
00:45:40 Los clientes deben comunicar conocimiento de dominio a proveedores
00:50:14 Objetivar hechos para resolver conflictos directivos
00:54:48 El Supply Chain Scientist posee la calidad de la receta numerica
00:59:22 La supply chain cuantitativa se difundira en la industria
01:03:56 La actualizacion diaria reduce la dependencia de previsiones largas
01:08:29 Retrasarse aumenta el riesgo; el mercado filtra a los rezagados
Resumen
Los ajustes manuales son un impuesto que consume atencion, tiempo y dinero, convirtiendo expertos escasos en vigilantes de correcciones transitorias. Los proveedores ganan con previsiones granulares que generan revision infinita. Es mejor incorporar el conocimiento humano en la receta numerica para que una hora de codigo o parametros reemplace miles de overrides. Si paga dos veces por la misma decision, no gestiona una supply chain: subvenciona un casino.
Resumen extendido
La gran ficcion de muchas supply chains es que el override manual es prudencia. En realidad, es un impuesto cobrado por sistemas que mantienen ocupadas a las personas en vez de hacerlas productivas. El recurso mas escaso no es el almacen ni el capital, sino quienes saben jugar el juego de forma rentable. Cuando pasan el dia retocando previsiones, no invierten: cuidan salidas que caducan enseguida.
En la planificacion dominante, la prevision se convierte en plan y el plan asigna recursos. Quien controla el plan controla la cartera de la empresa. Los proveedores monetizan esto con mas granularidad, mas numeros que revisar y mas asientos que vender. La alternativa no es negar la intuicion humana, sino incorporarla donde compone: en la receta numerica, no en cada salida.
La responsabilidad se aclara. El proveedor responde por la integridad del sistema y un Supply Chain Scientist identificado posee la receta que transforma hechos en decisiones. Las discrepancias pasan de la politica a los hechos: tipos de interes, distribuciones de lead time, costes de servicio. Actualizar decisiones a diario reduce la latencia y supera perseguir pequenos aumentos de precision con semanas de proceso.
Transcripcion completa
Conor Doherty: Esto es Supply Chain Breakdown, estamos de vuelta, y hoy vamos a descomponer el coste oculto de los ajustes manuales. Soy Conor, director de Comunicacion en Lokad, y a mi izquierda, como siempre, el fundador de Lokad, Joannes Vermorel. Antes de empezar, dejad un comentario: uno, ¿el ajuste manual forma parte diaria de vuestro proceso de planificacion? Y dos, ¿hay situaciones en las que os parezca adecuado que los humanos cuestionen o corrijan el sistema?
Enviad vuestras preguntas cuanto antes y se las planteare a Joannes dentro de unos 20 o 25 minutos. Dicho esto, Joannes, me alegro de verte de nuevo. El coste oculto de los ajustes manuales, nuestro primer tema del ano. ¿Cual es el alcance de nuestra critica hoy?
Joannes Vermorel: El alcance de la critica es que el juego de la supply chain se juega mal. Eso es practicamente todo. Y cuando digo mal, me refiero aqui a esos ajustes de previsiones, porque hablamos especificamente de eso. No es cualquier tipo de ajuste. Esos ajustes de prevision perjudican directamente la capacidad de jugar el juego de la supply chain.
¿Y que entiendo por juego de la supply chain? Basicamente, conviertes tus valiosos dolares o euros en cosas fisicas. Las transformas, las transportas, las reempaquetas, las distribuyes y al final de la cadena las vendes a un precio superior. Luego repites. Ese es el juego de la supply chain, y quieres jugarlo con la maxima rentabilidad posible.
Lo que digo es que si sobrescribes una prevision, cada vez que lo haces estas danando literalmente a tu empresa. Haces algo que impacta negativamente su capacidad de jugar este juego de forma rentable.
Conor Doherty: Una pregunta lateral: el tema son los ajustes manuales y, por definicion, pueden aplicarse a cualquier cambio en un sistema. Pero, seamos realistas, casi siempre son previsiones. Normalmente previsiones de demanda; no tasas de scrap, ni lead times, ni precios, ni asignaciones. Son retoques de prevision de demanda.
¿Por que ocurre? Podria haberse llamado ajustes manuales de previsiones de demanda. ¿Por que son tan comunes en ese punto concreto?
Joannes Vermorel: Primero, ¿por que tanto foco? Porque en la teoria dominante de supply chain, la prevision de demanda no es solo una prevision. Es la capa fundacional del plan, y el plan es a la vez una prevision y un compromiso. Los numeros que pones en el futuro dicen implicitamente: esto es lo que va a pasar.
En cuanto dices eso, deja de ser solo una prevision y se convierte en un compromiso. Todo el mundo debe hacer lo necesario para que ese futuro se vuelva real. Por eso, en la teoria dominante, el plan esta en un pedestal. Es central, casi como el rey, y modificarlo es modificar el plan.
Modificar el plan importa porque modifica la asignacion de recursos. Quien controla el plan controla, en ultima instancia, como la empresa asigna sus recursos. De ahi la tentacion de retocar sin fin, porque los efectos aguas abajo son muy importantes. Eso explica por que la gente lo hace tanto. Falta explicar por que es una practica perversa y por que perjudica a la empresa.
¿Por que perjudica? Por dos razones. La primera es que el recurso mas escaso en una empresa, desde el punto de vista de supply chain, son las personas que saben jugar bien este juego. Ese es el cuello de botella. Hay mucha gente capaz de hacer tareas mundanas, pero si quieres que la supply chain apoye a la empresa y sea un centro de beneficio, no un centro de coste, necesitas personas capaces de jugarlo rentablemente.
Esas personas son raras y escasas. Cada vez que hacen un ajuste manual, eso no acumula valor. Dedican una hora y al dia siguiente el sistema vuelve a generar la prevision. La correccion desaparece.
No es acumulativo porque, en lugar de usar ese recurso escaso para crear algo duradero, hacen una correccion con fecha de caducidad: la fecha de la propia prevision corregida. Si corrijo manualmente la prevision de la semana que viene, al final de esa semana la correccion ha desaparecido. Es perecedera por diseno.
Tenemos dos pilares. El primero: las personas que saben jugar el juego de la supply chain son escasas, y si hacen ajustes manuales todo su trabajo se tira por la ventana en unas semanas o un mes como maximo. No acumula.
El segundo problema es la cantidad de ajustes. La evolucion del software de planificacion infla enormemente el volumen de ajustes necesarios. Volvamos a los anos setenta: el software de prevision era basico, a nivel de categoria y mensual. Producian pocas previsiones y habia pocas ediciones.
Pero el proveedor quiere mejorar el producto. En los ochenta dice: antes solo teniamos categorias y meses; ahora podemos hacer semanas y subcategorias. Pasas de, digamos, 500 numeros a 5.000.
¿Y como gana dinero el proveedor? Vendiendo licencias por asiento. Al aumentar la especificacion del producto, genera mas previsiones, mas granulares en tiempo, geografia y todo lo demas. Como hay muchas mas previsiones, se necesitan mas personas para revisarlas y ajustarlas. Mas personas significa mas asientos.
No fue necesariamente intencional, pero desde la perspectiva del proveedor es un circulo virtuoso: el producto parece mas sofisticado, se vende mas caro y exige mas usuarios para gestionar correcciones infinitas. Mas asientos, mas ingresos, mas sofisticacion.
Ademas, hay un incentivo perverso bajo la promesa de previsiones mas precisas. Es tangencialmente cierto: pueden ser un poco mas precisas, pero no como los proveedores afirman. Tal vez la nueva generacion sea un 1 % mejor. Ellos diran que es 99 % mejor. No lo es.
Es incremental. Hace unos 15 anos llegamos a una meseta sobre lo buena que puede ser una prevision de serie temporal. No ha avanzado mucho. Con el cloud, sin embargo, puedes hacer explotar la granularidad: SKU, tienda, sitio, fabrica, todo. Explota el numero de previsiones y explota el numero de personas necesarias para corregirlas.
Los proveedores ganan. ¿La empresa gana? No. Gasta mas recursos que nunca para corregir un flujo infinito y autoinducido de previsiones. Por eso digo que perjudica la capacidad de jugar el juego de la supply chain.
No estas jugando el juego de la supply chain. Estas jugando el juego del proveedor de software de supply chain.
Conor Doherty: Cuando anuncie este tema, quise recoger informacion anonima de conversaciones con la audiencia y usarla para desafiarte. No quiero caricaturizar la posicion contraria. Mucha gente dira: tenemos un sistema sofisticado, quiza no tan sofisticado como el sistema de inteligencia que defiendes en tu libro, pero si tenemos un modelo que genera previsiones y lo usamos.
Lo usamos principalmente, y los ajustes son muy puntuales. Los aplicamos cuando vemos que falta un poco de informacion de mercado, algo que solo esta en mi cabeza como planner. En esas situaciones, ¿sigues pensando que no aporta valor, que es coste y desperdicio?
Joannes Vermorel: Si. Porque hay que mirar las consecuencias. Cuantas mas correcciones haces, mas personas participan en el software, y mas prepara el proveedor la situacion para que hagan falta mas personas. Para el proveedor es virtuoso; para la empresa cliente es vicioso.
Es como un casino. No te haras rico en el casino; la casa siempre gana. Si juegas a este juego, el unico ganador sera el proveedor. Lo he visto durante casi 20 anos. Pensar que puedes vencer al proveedor es como pensar que puedes vencer a la casa. Tal vez una vez por suerte, pero racionalmente no.
Puede que disfrutes el proceso. Los proveedores no son ingenuos: haran que sea agradable, porque quieren mas asientos. Para vender mas asientos, el proceso debe ser agradable.
Entonces, ¿cual es la alternativa? La objecion es: Joannes, no podemos dejar previsiones rotas. Estoy de acuerdo. Hay que corregir la herramienta que genera las previsiones. Hay que intervenir ahi.
Es tratar la enfermedad en lugar de los sintomas recurrentes. Las previsiones las produce software, asi que hay que corregir el software. Si alguien dice: soy practitioner de supply chain, no especialista en software, la respuesta es: tienes un problema de software. La practica moderna de supply chain exige dominar la forma moderna de hacer software. Ya estas tocando numeros generados por software, asi que el argumento es debil.
La solucion es cambiar el software. ¿Con que frecuencia? Todo el tiempo. No niego que los practitioners tengan insights que solo ellos poseen. El presidente de Estados Unidos puede publicar algo en Truth Social y desatar el caos. No puedes tener cada contingencia loca en el sistema.
El sistema es software, no Skynet ni una IA omnisciente. Es una automatizacion limitada que no lo sabe todo. Lo que necesitas es poder intervenir en ese software, y que el software este disenado para que una correccion tarde alrededor de una hora.
Una correccion end-to-end para incorporar un insight critico: cambio regulatorio, anuncio online, un barco bloqueando un puerto, una nevada masiva, una crisis. Todo eso ocurre. El software debe poder corregirse en una hora. Si tienes eso, estas bien.
Conor Doherty: Esto ayuda a encuadrar la discusion. No decimos que nunca haya una situacion en la que un practitioner experimentado tenga un insight valioso. Decimos: ¿ese caso puntual revela un patron que el sistema debe absorber para no generar manana la misma recomendacion rota que alguien tiene que corregir cada dia?
En grandes empresas esos insights llegan a diario, por tanto el sistema cambia a diario. ¿En que se diferencia de un override de prevision? En que aqui sobrescribes el sistema, no las salidas.
La diferencia es de varios ordenes de magnitud. Si sobrescribes salidas, puedes tener que cambiar miles de numeros. Si sobrescribes el software, a menudo cambias un meta-parametro o una linea de codigo. Algo complejo en el mercado puede traducirse en un juicio y una linea de codigo. Aproximadamente correcto es mejor que exactamente equivocado.
Al mover la intervencion de la salida a la receta numerica reduces la friccion enormemente. Y a veces descubres que ese insight forma parte de un patron mas amplio. Entonces no haces solo un parche: mejoras de forma duradera la receta numerica.
Eso es acumulativo. La mayoria de correcciones no lo son, pero en la experiencia de Lokad tal vez una de cada diez lo es mucho. Asi extraemos los insights mas valiosos de las personas escasas y los hacemos permanentes en el sistema.
Conor Doherty: Es convertir el sistema en un activo productivo. Sigues aplicando tu insight, pero no sosteniendo la mano del sistema todos los dias para preparar un pedido. Lo conviertes en un mejor activo y liberas tiempo.
Pasas de un override rutinario a un override puntual cuyo efecto compuesto mejora el activo. El sistema aprende, sin Skynet, porque el practitioner aprende.
Joannes Vermorel: No invoco ningun genio. Lokad hace esto desde hace diez anos. El sistema aprende porque hay humanos inteligentes en el proceso que aprenden. Esta alternativa es parsimoniosa con esas personas escasas.
No abusa de ellas. Las preserva para que puedan mejorar el sistema y hacer las otras cosas necesarias para jugar bien: relaciones con proveedores, relaciones con clientes, etc. Pero solo puedes hacer eso si no estas apagando incendios contra tu propio sistema de prevision.
Conor Doherty: Para equilibrar, ASCM diria que el consenso en S&OP es una etapa central de la decision en una empresa exitosa, no un modo de fallo. En tu libro, pagina 330, llamas a las correcciones manuales rutinarias una senal de un grave defecto de diseno. ¿Hay una prueba practica para distinguir overrides nacidos de defectos de diseno de los que responden a volatilidad real?
Joannes Vermorel: Es un juego que no puedes ganar. El proveedor actua contra ti. La casa siempre gana. Te enfrentas a un proveedor con mas de cien clientes, que ha jugado este juego mucho mas que tu.
Si defines una clase de overrides legitimos, el proveedor la hara producto. En dos anos tendras funciones sofisticadas para esa clase. Seran buenas, pero introduciran complejidad; la complejidad requiere mas tiempo y mas personas; volvemos a mas asientos.
No se resuelve asi. Es como esperar que un vendedor de caballos del siglo XIX promueva los automoviles. No pasara. Siempre encontrara razones para seguir con caballos. Hay un bloqueo de incentivos. En la historia, esos actores simplemente quebraron y salieron del mercado.
En supply chain, por opacidad y otros factores, esto se ha degradado mucho. Pero el mercado encontrara su camino. El mercado no educa, filtra. Filtra aunque la gente no entienda lo que ocurre.
Conor Doherty: Otro coste, para ti, es mantener a la gente dentro del loop. En tu libro dices que muchos proveedores convierten a los usuarios en coprocesadores humanos del sistema. Los practitioners IBP y S&OP dirian lo contrario: el proceso no puede reemplazar la decision humana, sobre todo en trade-offs cross-functional que no aparecen en los datos. ¿Tiene merito esa posicion?
Joannes Vermorel: Para evaluarla hay que dar un paso atras, porque hay conflicto de interes. Si eres parte del equipo S&OP, tienes interes en preservar S&OP. Imagina el siglo XIX: una gran empresa necesita caballos y tiene un departamento experto en comprar buenos caballos a buen precio. ¿Esa persona sera entusiasta al pasar a coches? No.
La opinion de las personas en conflicto debe tratarse con cautela. Y eso se aplica tambien a Lokad. Soy proveedor, vendo mi producto, por tanto sed escepticos conmigo. Asumid que tengo sesgos.
Cuando tratamos tecnologias en evolucion, conviene buscar analogias historicas. El juego de una tecnologia que llega y desplaza a otra se ha repetido cientos de veces. Los patrones son siempre los mismos.
Douglas Adams lo explicaba muy bien: si descubres una tecnologia antes de los 25, para ti siempre existio; entre 25 y 35 es un desarrollo emocionante; despues de 35 es herejia y deberia prohibirse. Es gracioso y muy cierto. Niels Bohr decia que la ciencia progresa funeral a funeral. Es la misma idea.
Conor Doherty: Otra objecion es que el sistema no puede manejar ciertas cosas o que el juicio humano supera al sistema actual. Puede ser cierto en contextos concretos, pero hay que mirar el contexto. Una empresa de cientos de millones o mil millones de facturacion ya tiene un presupuesto IT enorme. Si gasta cientos de millones en ERP, puede permitirse la intervencion tecnologica de la que hablamos.
Joannes Vermorel: Eso es lo desesperante. Muchas empresas estan atrapadas en ideas cuya validez termino a principios de los 2000. El paradigma de los overrides manuales fue valido, diria, de 1975 a 1995. Los ordenadores eran malos, los lenguajes y compiladores tambien, y la capacidad limitada. Los humanos tenian ventaja tocando numeros.
Eso expiro en 1995, fue absurdo en 2005 y loco en 2015. Usar caballo en 1910 no era absurdo; en 1920 empezaba a serlo; en 1950 si lo era. El dano aumenta con el tiempo.
Conor Doherty: Tambien hubo una campana agresiva de proveedores para convencer a la gente de mantener los caballos.
Joannes Vermorel: Falto escepticismo. Hablamos de una docena de proveedores globales con miles de millones de ingresos, haciendo lobby. Lokad es pequeno; hacemos YouTube y LinkedIn, pero no tenemos grandes ferias.
No esperes que los incumbents encerrados en una tecnologia obsoleta propongan la alternativa. Kodak casi invento la fotografia digital internamente. Tenian informes muy precisos, con una linea temporal de 15 anos, diciendo que llegaria y ganaria. Aun asi fallaron. Disrumpirse a uno mismo es dificil. La mayoria de empresas falla.
Conor Doherty: Hablemos de responsabilidad. Mucha gente dice: aunque todo eso sea cierto, al menos con overrides sabemos a quien culpar. Si la prevision dice pedir 200 y Janice cambia a 2.000, cuando sobran 1.500 unidades se quien es responsable. En un sistema de inteligencia, ¿donde esta la accountability, el audit trail?
Joannes Vermorel: La historia ya resolvio esto. En los anos sesenta, los primeros sistemas de negocio de IBM hacian contabilidad y aritmetica. Tenian bugs. Hoy damos por hecho que los ordenadores hacen aritmetica perfectamente, pero entonces no era obvio.
El contable preguntaba: soy responsable de la contabilidad, ¿voy a confiar la aritmetica a IBM? ¿Y si esta mal? ¿Culpamos a IBM? La respuesta fue si. Los contables confiaron en las maquinas para aritmetica basica y demandarian al proveedor si fallaba. IBM hizo bien sus maquinas y el problema desaparecio.
Aqui la accountability no desaparece; cambia. El proveedor es responsable de la integridad del sistema programatico. En Lokad, un Supply Chain Scientist es responsable de la integridad de la receta numerica que transforma hechos en decisiones.
Cada cliente tiene un Supply Chain Scientist con nombre, personalmente responsable de la calidad del resultado. Lokad debe darle el soporte para que esa responsabilidad sea manejable. Es como un piloto de avion: responsable de llevar a los pasajeros vivos, mientras el fabricante es responsable de la integridad del avion.
Hay mucha tecnologia, pero tambien accountability en cada etapa.
Conor Doherty: En el caso de Lokad, la responsabilidad de la integridad del algoritmo, el avion de la analogia, recae en Lokad y en el Supply Chain Scientist.
Joannes Vermorel: Hay corresponsabilidad. Si los practitioners del cliente omiten un insight critico, nosotros no somos expertos en cada negocio. Queremos ejecutar sus insights con diligencia. Si hay una regulacion nueva en una provincia canadiense que afecta turbinas eolicas, el cliente debe decirselo al proveedor. Eso mejora el activo.
Lokad es responsable, pero si los insights criticos nunca se comunican, no pretendemos saber mas del negocio del cliente que el cliente. La persona escasa sigue siendo el practitioner que sabe.
Conor Doherty: Esto vuelve al inicio: no negamos que existan insights en la cabeza de los practitioners. Decimos que el humano en el loop actual no es el loop que defendemos. Si el loop mejora un activo para no repetir manana el error de hoy, de acuerdo. Si es babysitting diario y consenso linea por linea, ahi diferimos.
Joannes Vermorel: Piensa en Toyota. Produces coches y algunos salen con defectos. Opcion uno: tener un equipo listo para reparar cada coche cuando vuelve tras 20 kilometros. ¿Toyota haria eso? No. Arreglaria la fabrica para que no produjera esos defectos.
Corregir la receta numerica es arreglar la fabrica. El override manual es el equipo de reparacion a la salida. Por eso digo que es una locura.
Conor Doherty: Antonio comenta que los overrides manuales desaparecen en el siguiente ciclo, pero repetidos podrian indicar una desconexion entre expectativas de negocio y direccion, quiza entre ganancias financieras de largo plazo y la mejor estimacion de demanda. ¿Como pueden los analistas cerrar esa brecha?
Joannes Vermorel: Necesitas un metodo que haga evidente la desconexion. Si el CEO se equivoca, no vas a ganar una pelea con el CEO. Lo que puedes hacer es objetivar: coste del dinero, tipos de interes, lead times observados, hechos. Mi sistema toma hechos y genera decisiones. Si no te gusta la decision, discrepamos sobre los hechos.
Los hechos no son opiniones. Si el CEO dice que el tipo de interes es incorrecto, llamemos al CFO. Hay que objetivar el sistema para jugar racionalmente, sin incentivos perversos. Eso es lo que Lokad construye: hechos dentro, decisiones fuera.
Hay subjetividad en decidir que cuenta como hecho, especialmente en negocio, pero hay que clarificar esa frontera. Como en contabilidad: el contable no causa las perdidas, solo muestra los libros segun reglas contables. Con mejores sistemas supply chain, las batallas politicas sobre numeros se reducen.
Conor Doherty: Alguien de retail pregunta: en nuestra oficina algunos dicen simplemente cambialo. A veces planner, a veces manager, a veces ventas. Cuando se equivocan, al menos sabemos a quien culpar. ¿Como gestiona Lokad la responsabilidad?
Joannes Vermorel: Igual. La receta numerica esta asociada a un Supply Chain Scientist con nombre. Si falla una vez al ano, se tolera. Si falla cada dia y funciona para otros clientes, quizas hay un problema con el scientist.
No es Skynet. No es una IA autonoma sin accountability gestionando la supply chain.
Conor Doherty: Dices que no es lo que dices, pero a veces la gente recibe esa impresion.
Joannes Vermorel: Lo malinterpretan, y nuestros competidores estan encantados de presentarlo asi. Nosotros defendemos responsabilidad clara. En la supply chain clasica, la responsabilidad de las decisiones finales esta completamente difusa. Con previsiones colaborativas, todos tocan la prevision y nadie sabe quien responde de que. El statu quo es horrible en accountability.
Conor Doherty: Boris pregunta si hay un umbral de visibilidad o legitimidad para motores de decision economica y sistemas de inteligencia supply chain tras el cual el software tradicional pierde credibilidad.
Joannes Vermorel: Ocurrira. Es como el paso a los coches. Kodak veia el futuro e incluso el calendario, algo muy dificil. Steve Jobs con el iPhone tambien acerto el futuro y el momento.
Mi conviccion es que las supply chains transicionaran a este modelo, porque los bancos ya lo hicieron con el trading cuantitativo. Por eso lo llamo Quantitative Supply Chain. Cada ano veo empresas que reinventan sin Lokad exactamente los mismos principios. Eso muestra que la idea ha llegado.
En algun momento habra percolacion: suficientes personas reinventaran y aplicaran estos principios, y el mundo cambiara. Intentamos acelerar ese proceso.
Conor Doherty: Pregunta practica: ¿donde se ve el primer beneficio al reducir overrides?
Joannes Vermorel: Es una pregunta del viejo paradigma. En 1910, con carreteras malas, el caballo aun puede parecer competitivo. Pero adoptar coches habilita muchas eficiencias difusas. En Lokad, un beneficio clave es refrescar previsiones y decisiones todos los dias, a escala.
Aunque el modelo de prevision no mejore, estar mas actualizado ya aporta mucho. Los overrides introducen semanas de retraso. Y cuanto mas lejos predices, peor predices. Reducir dependencia de previsiones lejanas es una ganancia neta.
Conor Doherty: Seguimiento: nuestros lead times siempre estan mal; los proveedores fallan fechas. ¿Cuanto puede manejarse?
Joannes Vermorel: Todo, si piensas probabilisticamente. No buscamos una prevision correcta unica. No sabemos el futuro; la incertidumbre es irreductible. Pero incertidumbre no significa ausencia de informacion.
Un avion de Airbus puede tener siete anos de backlog; unas fresas pueden llegar manana o pasado. Ambos tienen incertidumbre, pero no del mismo tipo. El petroleo puede tener precio negativo, como algunos creian imposible, pero tambien sabemos que no sera negativo durante mucho tiempo. Hay conocimiento imperfecto, no ignorancia total. El sistema debe trabajar con conocimiento imperfecto.
Conor Doherty: Ultima pregunta: si esta tecnologia aun esta en fase temprana, ¿cuanto tardara en pasar a mainstream?
Joannes Vermorel: Es dificil por el calendario. Sera lento en algunos verticales y muy rapido en otros. El futuro ya esta aqui, pero no distribuido uniformemente. Empresas protegidas por monopolios pueden tardar decadas; no tienen presion.
De Gaulle descubrio en los anos sesenta que el ejercito frances aun mantenia gatos por una razon que venia de Azincourt, cuando las ratas comian cuerdas de arcos. Siglos despues, con mosquetes, la practica seguia. Algunas industrias tendran retrasos asi.
E-commerce y retail iran rapido; tambien aviacion, oil and gas y sectores con mentalidad de ingenieria. Luego vendra el lujo: no tiene presion tecnologica inmediata, pero tiene margenes y gente inteligente.
Conor Doherty: Los beneficios existen, pero la presion para perseguirlos varia. Los monopolios estatales probablemente llegaran al final, cuando nadie recuerde por que existian los overrides. Para concluir: ¿donde pagas dos veces por la misma decision? Esa frase resume el coste oculto. Si diez personas ajustan, pagas muchas veces.
Joannes Vermorel: El dolor crece exponencialmente. Hoy el coste de no transicionar parece soportable, como no usar coches en 1910. Pero cada dia la brecha aumenta. En algun momento ya no puedes recuperarte y la empresa desaparece.
Es como resistirse a los ordenadores y seguir con maquinas de escribir. Llega un momento en que el mercado te sanciona con quiebra. El mercado no educa; filtra. Filtra sin coordinacion y aunque los participantes no entiendan lo que ocurre. Es hermoso y un poco aterrador, pero asi funciona el mercado libre.
Conor Doherty: Joannes, muchas gracias. No quedan preguntas ni tiempo. Gracias por estar aqui y por volver al estudio. Gracias a todos por asistir, registraros, enviar preguntas y conversar antes de esta sesion. Si quereis seguir la conversacion, contactad con Joannes o conmigo en LinkedIn. Ya veis nuestros nombres; conectad con nosotros. Nos vemos la proxima vez en Breakdown. Por favor, volved al trabajo.
