00:00:00 Introduccion
00:03:17 Por que existen los forward deployed engineers?
00:09:48 Por que fracasan los proyectos de IA en grandes empresas
00:13:35 El soporte experto debilita el software plug-and-play?
00:18:33 Valida la tendencia FDE el enfoque de Lokad?
00:22:55 Automatizacion frente a decisiones consecuentes
00:28:07 Como aborda un Supply Chain Scientist a un nuevo cliente
00:32:26 Evaluar expertos en horizontes largos
00:36:12 Es la adopcion del producto la metrica correcta de exito?
00:40:06 Por que la automatizacion es un problema de cero a uno
00:43:09 Impacto financiero frente a impacto economico
00:48:05 Por que la toma de decisiones requiere expertise de dominio
00:52:32 Como identifica Lokad buenos Supply Chain Scientists
00:55:22 Automatizacion hospitalaria frente a decisiones medicas
00:57:09 Refutan los FDE los modulos de optimizacion plug-in?
00:58:43 El problema de coste de los servicios FDE
01:01:04 Conclusion
Resumen
Conor Doherty y Joannes Vermorel examinan por que los forward deployed engineers se han convertido en una de las ultimas tendencias del software empresarial. Analizan la escasez de talento y las iniciativas de IA fallidas que impulsan su auge, distinguiendo la automatizacion rutinaria de las decisiones con consecuencias financieras. Joannes sostiene que la automatizacion debe eliminar trabajo por completo, mientras que los sistemas de decision requieren mantenimiento continuo, juicio economico y profunda expertise de dominio. La conversacion compara los FDE con los Supply Chain Scientists de Lokad, cuestiona la adopcion como metrica de exito y explora si el costoso soporte humano expone las limitaciones del software empresarial supuestamente plug-and-play.
Transcripcion completa
Conor Doherty: Son casi las 6, que en Paris basicamente ya es de noche. Asi que si, estamos trabajando mucho en Francia, segun los estandares franceses. Son casi las 6 de la tarde aqui en Paris, y Joannes y yo acabamos de terminar el podcast sobre forward deployed engineers. Al final fue bastante distinto de lo que yo pensaba.
Evidentemente, habia preparado mis preguntas, pero luego la conversacion evoluciono. Pense que ibamos a hablar sobre todo de que es un forward deployed engineer, de si es hype o no. Cubrimos eso, pero tambien acabamos hablando de como evaluar la oferta de un FDE dentro del software empresarial, para que deberia usarse realmente ese rol, y de contrastarlo con el puesto de Supply Chain Scientist en Lokad. Asi que lo disfrute mucho. Espero que ustedes tambien, y digannoslo en LinkedIn.
Pueden contactar con Joannes y conmigo si quieren hacer otras preguntas. Pero yo me voy a casa ahora. Asi que disfruten la conversacion. Bueno, Joannes, gracias por acompanarme.
Te he traido hoy para hablar del auge de los forward deployed engineers. He hecho mis deberes sobre esto. No es un puesto nuevo. De hecho, tiene raices militares, pero en los circulos de software, y especificamente en los de software empresarial, es una posicion muy reciente.
Para dar un poco de contexto sobre la escala de la que hablamos, lei esta manana que AWS esta invirtiendo alrededor de mil millones, en realidad algo mas de mil millones de dolares, para desarrollar su departamento de forward deployed engineers, o FDE. Y Combinator, la famosisima aceleradora, tiene actualmente, en este momento, esto es 27 de agosto, mas de 100 startups anunciando estos roles concretos, no engineers, sino forward deployed engineers.
Que es, en terminos sencillos? He sintetizado algunas definiciones, porque obviamente varian, pero en lineas generales un forward deployed engineer, o FDE, es un ingeniero de software de cara al cliente que trabaja directamente dentro del equipo de un cliente, o con el, fisicamente o a distancia, para construir, personalizar y entregar software complejo que resuelva problemas complejos del mundo real. Y como estoy seguro de que se te ocurrio a ti, y se me ocurrio a mi en cuanto lo oi y lo lei, y como estoy seguro de que se le ocurrio a todo el mundo que conoce Lokad, eso suena muy parecido a un Supply Chain Scientist. Hay diferencias, llegaremos a ellas mas tarde, pero mi primera pregunta, a alto nivel, es esta.
Llevamos cuatro anos dentro del boom de la IA. ChatGPT salio en otono de 2022, y ahora estamos casi en otono de 2026. Parece que fue mas rapido, pero han sido cuatro anos. Tenemos IA escribiendo su propio codigo en muchos contextos y, sin embargo, hemos vuelto, como si el tiempo fuera un circulo plano, a “si quieres que esto funcione, necesitas contratar a mi experto para que venga y lo haga funcionar para ti”. Entonces, Joannes, por que existe este rol hoy?
Joannes Vermorel: Si, estamos volviendo por completo al tipo de configuracion que historicamente hizo la fortuna de IBM. La idea del forward deployed engineer era practicamente la configuracion por defecto de IBM en los anos 70 y 80: enviar montones de ingenieros, diria yo, al sitio del cliente para instalar el mainframe. Ese era, diria, el modelo por defecto.
De hecho, hemos estado alejandonos de eso durante las dos ultimas decadas, y ahora vuelve con fuerza. Mi perspectiva general sobre por que esta volviendo es que hay muchas fuerzas, pero una de ellas es simplemente el efecto sociologico de la contratacion. Algunas empresas tienen un exito increible atrayendo talento en comparacion con otras. Y si eres, digamos, recuerdo haber leido hace unos anos que Google recibia algo asi como 4 millones de candidaturas al ano.
Era informacion de hace una decada. Probablemente sigue siendo el orden de magnitud. Y lo interesante es que algunas empresas tienen exito y otras no. Como cifra diminuta y totalmente anecdotica, en Lokad, cuando publicamos una oferta en LinkedIn, veo que muy a menudo tenemos muchos mas candidatos que empresas enormes, con mas de 100 000 empleados, cuando publican un puesto comparable.
Conor Doherty: Te refieres especificamente al rol de Supply Chain Scientist, verdad?
Joannes Vermorel: Si, en LinkedIn lo presentamos como business analyst.
Conor Doherty: Ah, es verdad.
Joannes Vermorel: Porque de lo contrario, la gente delante del ordenador ni siquiera sabe realmente de que hablamos. Asi que cuando publicamos en LinkedIn, ponemos business analyst y solemos recibir muchos mas candidatos que empresas extremadamente grandes. Lo que veo, en terminos generales, es que hay empresas de todos los tamanos que consiguen atraer muchisimo talento, y muchas otras, normalmente mas antiguas y mas grandes, que no lo consiguen. Eso crea una inclinacion muy natural a decir: si podemos contratar a todas esas personas, o a mas de esas personas que se presentan a nosotros, luego revenderemos sus buenos servicios a esos clientes.
Y si puedes combinarlo con una plataforma de software, vendes el tiempo de esas personas inteligentes que puedes contratar, y ademas enganchas a la empresa cliente a las tecnologias fundacionales que vendes. Entonces puede convertirse en una jugada muy rentable durante mucho tiempo. Si hablamos de AWS, hablamos de personas que ayudaran a los clientes a adoptar la oferta cloud de Amazon. Lo mismo ocurre si contratas forward deployed engineers de Palantir: esas personas construiran sobre la plataforma Palantir. Y, hasta cierto punto, en Lokad ocurre algo parecido: los Supply Chain Scientists construyen sobre la plataforma Lokad.
Pero fundamentalmente creo que la fuerza subyacente, mas grande que la tecnologia, es este efecto sociologico: parece que el talento acude en masa a unas pocas empresas que reciben un numero enorme de candidaturas, mientras que muchas otras reciben muy pocas. Asi acabas, en cierto modo, con empresas que acaparan talento. Y luego existe esta inclinacion natural a decir: puedo contratar solo lo que necesito, o puedo decidir expandirme y usar el hecho de que soy tan bueno atrayendo talento para revender esos talentos de ingenieria a los clientes.
Conor Doherty: Es cierto. De nuevo, obviamente es multifactorial.
Joannes Vermorel: Si.
Conor Doherty: Otro hilo que vale la pena seguir, y de nuevo vuelve a la idea de que el tiempo es un circulo plano. Creo que hace 18 meses hicimos un evento en directo sobre el generative AI value gap. Hicimos un episodio grabado un par de meses antes. Hablabamos de que hay mucha investigacion, incluso de grandes consultoras, que dice que muchos de los proyectos en los que la gente esta metiendo cientos de millones de dolares no se adoptan y, ademas, no generan valor. Para preparar esto volvi a mirar cuantas de mis notas siguen siendo relevantes hoy. Sorpresa: todas. De hecho, hubo un estudio del MIT el ano pasado, sobre 400 empresas, grandes empresas estadounidenses, y el 95 % de ellas declaro que el dinero gastado en proyectos de IA no habia producido nada.
El lenguaje usado fue “ningun impacto medible”. Muchos de estos puestos de forward deployed engineers estan muy asociados con hacer que los proyectos de IA funcionen. Estoy seguro de que hay aplicaciones de nicho donde la necesidad es simplemente levantar un sistema de registro, y envias a alguien a hacerlo. Pero muchas veces OpenAI, Anthropic, incluso gente de nuestro ambito, venden proyectos de IA con el FDE, o el FDE hara que el proyecto de IA funcione dentro de tu contexto.
Asi que, de nuevo, hablaste de empresas acaparando talento, claro, y es casi como una inversion en necesidades futuras. Pero al mismo tiempo, al menos segun muchas instituciones, hay una necesidad muy presente, porque muchos proyectos de IA en los que las empresas gastan millones de dolares casi a ciegas no estan aportando nada. Y el mercado ha dicho: sabes que, tengo un experto que puede ayudarte a arreglarlo. Te resuena eso?
Joannes Vermorel: Si, pero atribuiria la causa raiz a algo un poco distinto.
Conor Doherty: De acuerdo.
Joannes Vermorel: Las grandes empresas, todas las empresas, normalmente han dominado y calibrado por completo la cantidad exacta de competencia y habilidades que necesitas para cada puesto. Como resultado, acabas con una piramide en la empresa donde la mayor parte de la piramide esta llena de personas que estan exactamente en su pico de competencia. Ya sabes, es el principio de Peter: seras ascendido hasta alcanzar tu punto de incompetencia.
Ahora imagina una empresa de 50 000 personas donde casi todo el mundo esta exactamente al limite de la incompetencia. No son incompetentes; estan justo por debajo. Y ahora introduces una tecnologia que, en si misma, no es tan complicada, pero claramente es una complicacion adicional. Entonces te das cuenta de que literalmente casi toda la piramide no puede con ello, porque es algo que los saca de su zona de capacidad. Es un poco duro, pero piensa en una empresa que lleva decadas existiendo y que normalmente ha logrado exprimir cada punto porcentual de rentabilidad de su estructura de costes.
Eso significa que si empleabas a personas mas competentes de lo que realmente se necesitaba, estabas dejando dinero sobre la mesa. Asi que muchas empresas, a lo largo de decadas, acaban eliminando por las fuerzas naturales del mercado cualquier excedente de competencia. Esa es mi perspectiva habitual. Por eso, cuando llegan estas tecnologias de software disruptivas, acaban necesitando apoyo. Si intentan desplegarlas internamente, chocan con que practicamente todos en la piramide ya estan al maximo de lo que pueden gestionar, y si anades otra cosa simplemente ya no es manejable. No lo consiguen.
Por eso creo que muchas de esas iniciativas de IA fallan. Necesitas personas con mucho margen, personas extra inteligentes, competentes y capaces por encima de lo que exige su trabajo actual, para que puedan pensar el futuro de su trabajo una vez que mezclas IA en la imagen. Con las tecnologias de IA, normalmente lo que ocurre es que tienes que repensar el trabajo, y entonces puedes hacerlo con una productividad potencialmente 10 veces mayor. Pero ese trabajo requiere un replanteamiento muy cuidadoso, mucho mas alla de lo que historicamente se necesitaba para mantener el statu quo.
Conor Doherty: Mientras decias eso se me cristalizo una idea. No la habia escrito, pero voy a intentar sacarla. La idea de la IA, al menos como se vendio, era automatizar tanto como fuera posible, pero tambien poder escalar mucho mas alla de lo necesario o de lo posible usando, digamos, una fuerza laboral humana, o desde luego lo que una persona podia hacer. Y ahora estamos en la etapa en la que, si quieres que la IA funcione, necesitas a alguien con mucho margen de competencia para hacerla funcionar.
Joannes Vermorel: Si.
Conor Doherty: Entonces, perdon, el punto es este, y luego puedes seguir: eso no vicia, o simplemente socava, todo el concepto de pagar y enchufar, o comprar software nuevo de estanteria y que ya este listo, porque ahora tienes que comprar a otra persona para que funcione para ti?
Joannes Vermorel: Si. Dejame darte una anecdota reciente. Hace muy poco contacte con mi proveedor movil a traves de su hotline. Una experiencia maravillosa. Historicamente tenian como dos primeros minutos de avisos legales desesperantemente lentos, que no me importan, y luego “pulse uno para esto, pulse dos para aquello”, etc.
Tenian ese laberinto de numeros para llegar a lo que querias, y finalmente a un operador, porque ninguno de los caminos llevaba realmente a ninguna parte. Incluso eso estaba un poco roto. Lo que hay que imaginar es que los ingenieros, haciendo lo mejor que podian en esa empresa, apenas eran capaces de mantener algo que era un arbol de decision con numeros para dirigir a la gente. Eso ya era su pico de ingenieria y ya estaban fallando un poco. Y ahora han renovado recientemente el sistema con IA. Esa IA tiene el peor reconocimiento de voz imaginable. No entiende nada.
Me llevo como 20 minutos discutir con esa maldita IA hasta que por fin consegui un operador, porque lo que queria hacer no era posible con ese sistema. Fue un caso epico de mala ingenieria, pero en realidad era muy predecible. Si tienes personas que ya estan al limite de su capacidad de ingenieria para construir un arbol de decision, y eso ya les supone un desafio, si les pides hacer un triaje fluido basado en IA para llamadas entrantes, va a salir muy mal. Y fue interesante porque todo era malo: el reconocimiento de voz era terrible; se notaba que el guion y la base de conocimiento que tenia que usar para tratar la situacion eran malos.
Era un problema multicapa donde cada pieza de software era mala. El reconocimiento de voz elegido era malo. La sintesis de voz era mala. El LLM elegido era malo. La base de conocimiento con la que habian alimentado al LLM era mala. Era como una pieza de software mediocre en muchas capas. Y si volvemos a por que falla, imagina una situacion en la que tu IT ya esta luchando para hacer cosas muy simples. Y conozco a la gente que trabaja en IT en esa empresa concreta; no son precisamente los mas brillantes.
Es el tipo de empresa que tiene muchisimos problemas para conseguir a alguien decente de cualquier escuela de ingenieria en Francia. Asi que no sorprende que cualquier cosa que intenten con IA sea una catastrofe. Y por eso el hecho de que necesiten ayuda es simplemente la consecuencia de que, en cuanto introduces novedad, tus equipos no pueden con ello porque apenas pueden con el statu quo.
Conor Doherty: Si.
Joannes Vermorel: E incluso el statu quo ya los tiene bastante estirados.
Conor Doherty: Yo habia escrito la palabra flujo, pero novedad es mejor, porque creo que captura el espiritu de uno de los mayores diferenciadores aqui. Historicamente, Lokad siempre ha emparejado la idea de que tienes el software, pero tambien tienes el experto. Y la razon por la que tienes el experto es que tu supply chain estara llena de matices, de casos limite que van a surgir. Evidentemente hay decisiones diarias que seran rutinarias, pero estaran gobernadas por mucho flujo. Nunca fue: si, compra esto de estanteria.
Todo el marketing, y en realidad la funcion real del servicio, era que esto tiene que construirse alrededor de tus problemas, alrededor de tu realidad. Nuestro Supply Chain Scientist tiene que interactuar contigo para construir la capa de toma de decisiones.
Joannes Vermorel: Si.
Conor Doherty: Ves la emergencia del rol de FDE en empresas similares, y hablamos de pares, competidores, lo que sea, como una validacion de que siempre has sostenido que todo tiene que construirse desde cero? Que no puedes simplemente tener codigo copiado y pegado para todo?
Joannes Vermorel: Si y no. Primero, la realidad es que casi todos los problemas que tienes cuando entras en el mundo del software empresarial consisten en pegar software entre si. Ese es casi todo el problema. Puedes tener un LLM de estanteria por aqui, un servidor web de estanteria por alla, una base de datos transaccional de estanteria en otro sitio. Pero tienes que pegar esas cosas, y como tu empresa existe desde hace 50 anos, tienes decadas de cosas ya instaladas. No puedes darte el lujo de decir: simplemente conecto este producto y funciona.
Esa es una situacion greenfield que funciona en una pyme. No funciona en el espacio empresarial. Para ser justos con el mercado, creo que la idea de usar muchos consultores e integradores para hacer esta fontaneria a medida existe desde hace mucho tiempo. La gente era muy realista.
La diferencia principal, creo, aparece con la automatizacion. Esa es la diferencia clave. Normalmente, si se trata solo de configurar un sistema de registro y conectar tus sistemas de registro, podias hacerlo con integradores que solian ser buenos con sistemas de registro. Y esas cosas no son inteligentes. En terminos de diseno de software, son basicamente aplicaciones CRUD: create, read, update, delete. Es lo mas vanilla posible.
Tienen una funcion simple: mantener los registros. La automatizacion es otra cosa. En Lokad nos centramos en decisiones, pero incluso antes de las decisiones hay muchisimas cosas que son simplemente automatizaciones basicas. Y ahi veo muchos bloqueos, sobre todo porque siempre que tenias una entrada de texto libre, un dato no estructurado, una imagen, lo que fuera, estabas bloqueado y tenias que poner un humano en el bucle. Con estas tecnologias de IA, la casi totalidad de la automatizacion rutinaria se vuelve posible. Ni siquiera hablo de la capa de decision como Lokad.
Hablo de cosas como: un cliente debe enviar una copia de su documento de identidad. Recibes una imagen. Es una imagen de un documento de identidad? Si. No. Si no tienes un sistema que pueda decir si es una imagen de un documento de identidad, necesitas un humano que mire y se ponga en medio. Por eso creo que la automatizacion es mucho mas amplia que las decisiones. Son literalmente todos los pasos super granulares de tus procesos, y la mayoria son muy inconsecuentes. Solo tienen que hacerse. Lo que quieres es que se hagan sin un humano en el bucle, sabiendo que es una cosa increiblemente rutinaria, con stakes no muy altos, muy directa. Pero si solo miras el paradigma CRUD, create, read, update, delete, ese paradigma no te da una manera de automatizar eso. Necesitas algo mas. Ahi es donde creo que los forward deployed engineers pueden aportar mucho valor: proporcionando la inteligencia necesaria para automatizar mas alla de CRUD, porque la mayoria de los integradores no son capaces de hacer nada mas alla de CRUD.
Conor Doherty: Absolutamente. Es un punto que merece aclararse. El contexto de la discusion aqui, al menos en su mayor parte, y desde luego en lo que respecta a la comparacion con la capa de Lokad, la capa de system of intelligence, es que la gran mayoria de la investigacion que hice y los puestos que mire consisten basicamente en construir codigo de IA que ayude a la gente a tomar decisiones. Si tomamos el ejemplo del ERP como sistema de registro, eso es un sistema de registro.
Tienes tus datos transaccionales. Como paso de eso a cuales son las decisiones que debo tomar hoy, manana, etc.? Ahi es donde mucha gente usa forward deployed engineers, o al menos en el espacio del software empresarial. Ahi es donde los estan poniendo.
Y en su lenguaje, es una mision. Entras, puede tardar seis meses, un ano, dos semanas. En cambio, cuando hablas del Supply Chain Scientist, no es algo a corto plazo. Es una relacion continua por razones muy concretas.
Joannes Vermorel: Si. De nuevo, sobre todo porque la casi totalidad de lo que el mercado considera forward deployed engineers no son decisiones. Solo automatizan lo rutinario. La decision ya se ha tomado.
No es esa la cuestion. Literalmente se trata de automatizar. Y cuando digo automatizar, piensa que pueden ser cosas muy sencillas: por ejemplo, llega un registro en una pantalla y en algunas situaciones debe copiarse y pegarse en el software A, y en otras en el software B, y la frontera entre esos dos casos es un poco difusa. Esa es una situacion donde, boom, forward deployed engineer. Si puedes tener una regla hiper simple que codificas en Excel, no necesitas a esas personas. Pero si es mas matizado, entonces si, quiza las necesitas. Mi lectura es que la rentabilidad solo se alcanzara cuando saquen personas de la imagen. Si no hay una ganancia neta sustancial de productividad, no habra retorno de la inversion. Y de nuevo, si dices que tu mision tiene un limite de tiempo, entonces por definicion no estas tratando decisiones. Estas tratando automatizacion.
Conor Doherty: Es un punto justo.
Joannes Vermorel: Si, es un punto justo. Una decision, algo que tiene stakes financieros asociados, necesita ser monitorizada y revisada. Por eso los Supply Chain Scientists no se evaporan.
Por eso cuando empezamos una iniciativa con un cliente, se quedan. Si vas a escribir una receta numerica que literalmente puede gastar millones de dolares al dia, y lo hara, porque si recomiendas que se debe reordenar, tienes una receta numerica que te da tu lista de reposicion. Es literalmente tu lista de gasto. Son dolares que vas a gastar por esa receta numerica. Tiene que mantenerse, porque no mantenerla seria una locura.
En algun momento habra un cambio de mercado. Invalidara las hipotesis de tu receta numerica, y sera un desastre. Asi que evidentemente hace falta mantenimiento, y necesitas a alguien inteligente para hacerlo. Pero si hablamos de automatizaciones basicas, entonces no: puedes tener algo que necesita a alguien inteligente para construir la automatizacion, pero luego esa automatizacion puede funcionar practicamente hasta el fin de los tiempos.
Por ejemplo, si quieres reconocimiento de cheques manuscritos. Una vez que tienes un sistema que puede hacer ese reconocimiento de escritura, puede funcionar casi indefinidamente. Pero fundamentalmente no viene con stakes altos. Es reconocimiento de escritura. Conservas la imagen, tienes el reconocimiento y puedes automatizar. Esta bien. No necesitas necesariamente mantener cerca al ingeniero que diseno el algoritmo de reconocimiento de escritura.
Conor Doherty: Se me ocurre que una dimension central que vale la pena explorar es si contratas un FDE a traves de otra empresa o trabajas con Lokad y tienes un Supply Chain Scientist. El punto es que traes a un experto que en ese momento no conoce tu empresa, no tiene el codigo escrito, o no deberia tenerlo escrito, porque necesita entrevistar, necesita entender la supply chain para extraer esa informacion y presumiblemente aplicar expertise de dominio. Si, no creo que estemos en posicion de comentar como hace eso un FDE. No tenemos FDE.
Como aborda eso un Supply Chain Scientist? Es el dia uno, habla con clientes. Sobre el papel suena muy simple: hablar con gente, obtener informacion. Pero que tipo de informacion, en un contexto de supply chain, es relevante para que un FDE o un SCS empiece a construir codigo? Puedes elegir cualquier problema de juguete.
Joannes Vermorel: En nuestro caso en Lokad, lo que realmente tiene que hacer el Supply Chain Scientist es esencialmente inspeccionar el paisaje aplicativo. Eso va a ser una discusion tecnica con IT, simplemente para entender que datos estan disponibles. La regla es que los datos son lo que son. Asi que no te quejes. La empresa esta operando con esos datos. Por tanto, la hipotesis por defecto es que son suficientes.
Nunca son perfectos, pero son suficientes. Asi que inspeccionar el paisaje es una parte importante. Y luego la otra parte es entender que hace realmente la empresa para el mercado, con sus socios, y como todo eso deberia cuantificarse para tener un modelo economico de la empresa.
Tiene que tener sentido, porque el Supply Chain Scientist sera responsable de elaborar una receta numerica. Esa receta numerica consumira los datos. Vale, ese es el punto uno. Pero al final evaluara todas las distintas opciones que tenemos en euros o dolares.
Y para tener una evaluacion que no sea absurda, necesitas una comprension profunda del negocio. Necesitas entender que valoran realmente los clientes. Que restricciones son realmente dolorosas para los proveedores? Donde estan los cuellos de botella dentro de la supply chain?
Que cuenta como recurso escaso? Porque todo es escaso, si, pero algunas cosas en supply chain pueden ser mucho mas escasas. Puedes estar limitado en lugares muy concretos. Tienes que ser consciente de ello.
Y luego tambien tienes que modelizar todas las fuerzas que tienen, diria, efectos duraderos pero que son dificiles de evaluar de inmediato. Un ejemplo seria que si vendes por encima del precio de tus competidores, siendo todo lo demas igual, habra desgaste con el tiempo. Perderas gradualmente cuota de mercado. Si todo lo demas es igual y simplemente eres un poco mas caro que tus competidores, con el tiempo, salvo que el mercado este regulado o algo parecido, tus clientes se iran a competidores.
Pero la cosa es que esto sera invisible en cuestion de semanas porque hay muchos habitos, etc. El Supply Chain Scientist esta ahi para tener una perspectiva inteligente de largo plazo sobre la economia de la empresa, aprovechando los datos pero sin ser ciego a los efectos de largo plazo que solo pueden entenderse, y diria estimarse, porque nunca pueden medirse realmente. No vamos a hacer experimentos durante una decada. Hay muchas cosas que solo pueden venir de una comprension de alto nivel. Un ejemplo seria: si haces hard luxury, nunca quieres dar descuentos a ningun cliente. Si vendes un reloj caro, quieres decirle al cliente que no esta gastando dinero, que es una inversion, que ese reloj valdra aun mas dentro de diez anos. Que sea cierto o no es otra cuestion, pero si empiezas a hacer descuentos, eso desde luego no puede ser cierto. Por eso muchas cosas tienen que venir de una comprension de alto nivel, y no vas a hacer experimentos con tus clientes para evaluarlas.
Conor Doherty: Ah, entonces tu…
Joannes Vermorel: No.
Conor Doherty: Ah, porque habia anotado horizontes. Quiero hablar de evaluar, de nuevo evaluar el impacto del experto. Da igual si es un FDE o un SCS, para esta discusion no importa, pero mencionaste un muy buen ejemplo que me recordo una idea que oi en la oficina hace un par de dias. No voy a decir quien, pero era sobre aeroespacial, sobre ordenes de compra de motores.
Y el punto con este cliente es que por definicion es un compromiso de varios anos. No voy a entrar en detalles porque podria estar en registro publico, pero digamos que compran diez motores. Y el horizonte temporal de este proyecto es de unos cinco anos. Asi que dentro de cinco anos sabran realmente si fue buena idea, el 27 de agosto, comprar todos esos motores.
Si tienes un FDE, esa persona hace tiempo que se fue. Pero si sigues trabajando con Lokad, al menos hay continuidad en la valoracion.
Joannes Vermorel: Si. Y va en ambos sentidos. Mi lectura es que los FDE deberian entregar ganancias de productividad que puedan evaluarse literalmente por completo el dia que termina la mision.
Conor Doherty: De acuerdo.
Joannes Vermorel: Tienes un proceso que deberia automatizarse. Pasas potencialmente de 100 personas a cero para hacer el trabajo, y quiza una para supervisar. Ese es el entregable. El FDE, de nuevo, como no estamos en la capa de decision, no hay stakes.
Automatizas las cosas por completo. Sacas a las personas, y esa es tu condicion de victoria. No hay otra. Es realmente: puedo hacer que este trabajo que antes hacian 100 personas lo haga esencialmente cero, con un poco de supervision de IT para asegurar que todo siga funcionando? Eso es todo. Un ejemplo en Lokad: la traduccion de nuestro sitio web a muchos idiomas ahora esta completamente automatizada. La cuestion es monitorizar la automatizacion, no jugar a ser traductores.
Conor Doherty: Pero tenemos decision.
Joannes Vermorel: Lo entiendo, eso es exactamente lo que digo: los FDE no trataran decisiones. Piensa en la traduccion, es una tarea mucho mejor. Si, requiere inteligencia. Si, es algo que no puedes traducir con un sistema burdo; de nuevo, create, read, update, delete, tu base SQL no puede traducir. Eso es lo que los FDE hacen bien. Tomas un proceso que esta muy bien definido. Sabes que deberias obtener al final del pipeline, y lo que reingenierizas es que sacas a las personas del camino critico. Robotizas esa pieza.
Y la razon por la que la mision puede terminar es que no hay decision implicada. No una decision real. No en el sentido en que la defino en este libro, que es esencialmente una asignacion de recursos. No hay asignacion de recursos.
Es simplemente un proceso en el que algo tenia que hacerse y ahora se hace sin supervision, basicamente sin nadie. Pero no habia stakes especificos. Tenia que hacerse y ahora se hace automaticamente, cumpliendo con el objetivo de calidad que tengas. Y ya esta.
Conor Doherty: Hablando de objetivos de calidad, el siguiente punto era, y de nuevo no voy a nombrar nombres, pero recomiendo mucho a cualquiera que escuche que busque “deployed engineers” y su ciudad y la palabra jobs, y vera generalmente de que hablo. Estoy dando una descripcion representativa de los criterios de evaluacion de un FDE segun muchas empresas que anuncian estos puestos. Es la adopcion de productos. Eso no es trivial, evidentemente: si haces algo y literalmente nadie lo usa, es un problema.
Podria ser el mejor software de toma de decisiones del mundo, pero si nadie lo usa, eso es un problema. Todos lo entendemos. Pero eso por si solo basta para decir que fue un gasto valioso de dinero, tiempo, esfuerzo y oportunidad? Para el proveedor de software, la adopcion, en el sentido de que mucha gente pasa mucho tiempo, es super critica porque asi se crea adherencia.
Joannes Vermorel: Si.
Conor Doherty: Pero para la empresa cliente que lo recibe, es una trampa enorme.
Joannes Vermorel: Si. No quieres algo que sea adoptado. Quieres algo que simplemente funcione.
Conor Doherty: Desarrolla eso porque no lo entendi.
Joannes Vermorel: Cual es la tasa de adopcion de tu filtro anti-spam?
Conor Doherty: Ah, vale. Entiendo.
Joannes Vermorel: La gente adopto el anti-spam? No. El anti-spam esta ahi. Hace su trabajo y ya ni siquiera notas que tienes un anti-spam.
Simplemente esta ahi. Hace el trabajo y lo hace extraordinariamente bien. El 99 % de tus correos basura se filtran. Nunca te das cuenta de que estaba ahi. Esta hecho.
Asi es como se ve la automatizacion. Si, asi se ve la automatizacion. Es algo que se integra y queda hecho. Ese es el problema cuando la gente piensa en adopcion de automatizacion: de que estamos hablando?
Existe realmente un desafio de adopcion para el anti-spam? Historicamente si lo hubo, porque a finales de los 90 los filtros anti-spam eran malisimos. La gente tenia que personalizar reglas y hacer muchas cosas para que su buzon estuviera al menos un poco sano. Pero avanzamos hasta hoy y generalmente es excelente. Y normalmente las empresas que acaban marcadas como spam se lo han buscado, simplemente porque enviaron millones de emails y millones de personas los marcaron como “esto es spam”. Ahora sus emails ya no pasan.
El problema que tengo es que cuando la gente piensa que una tecnologia exitosa es adopcion, esta adoptando las metricas del proveedor de software o tecnologia. Y lo que digo es que en B2B, porque hablamos de B2B, no quieres una pieza de software que mantenga ocupados a tus empleados muchos minutos al dia. Cada minuto que tu empleado pasa tratando con software le cuesta a tu empresa. Quieres que la cosa aborde el problema tan por completo que esos problemas se vuelvan invisibles. Se convierten en el zumbido de fondo de tu empresa y nadie piensa en ello.
Simplemente esta ahi. Hace lo que tiene que hacer.
Conor Doherty: Pero para llegar a ese punto, y estoy de acuerdo, me gusta la analogia, no es simplemente cero a uno. Sabemos que no es cero a uno; hay automatizacion.
Joannes Vermorel: No. Para la automatizacion, siempre es estrictamente cero a uno. Nunca he visto otra cosa. Piensa en cosas de bajo riesgo. Hace unos 15 anos vi personas en companias de seguros cuyo trabajo era pulsar un boton, confirmar si era un documento de identidad, si, no, pulsar un boton, siguiente imagen, confirmar que era un documento de identidad. Y esas personas, no, no, no. Siempre fue cero a uno.
El problema es que hay una falacia completa de gatear, caminar, correr. No. Para la automatizacion no funciona asi. Cuando se trata de millones de dolares, por ejemplo, por eso digo que no hablamos de lo mismo. Lokad opera en el reino de las decisiones, decisiones financieras. Esto requiere decisiones con consecuencias financieras importantes. Ahi esta la diferencia. Y hablamos de decisiones que no tienen limite superior en cuanto a lo buenas que pueden llegar a ser. Volvamos a un software que clasifica una imagen para decir: es un documento de identidad?
Si o no? Si tienes algo que, en una evaluacion, ya esta muy por encima de la precision humana, entonces has terminado. No tiene sentido seguir. Y si no hay maniobras adversariales, gente intentando enganar, y hay muchas situaciones asi, entonces el trabajo esta resuelto. Has resuelto el problema por completo y debes pasar a otra cosa.
Ese es el tipo de problemas de los que hablo. Una version IA seria: tu proveedor te envia un PDF de una factura y quieres extraer el numero de factura en la codificacion de tu proveedor. Se puede hacer automaticamente. Una vez que tienes eso, esta hecho.
Si, puedes tener a alguien que abra el PDF y haga copiar y pegar. Pero si tienes una automatizacion que lo hace, ya esta. Si tienes una evaluacion que muestra que estas casi perfecto, no tiene sentido la adopcion gradual. No tiene sentido. Por eso digo que para la automatizacion solo hay cero y uno, nunca adopcion gradual.
Conor Doherty: Si comparamos manzanas con manzanas, para empresas que proporcionan o venden FDE como servicio para construir el tipo de software de toma de decisiones que nosotros tambien podriamos construir, entonces hablamos de metricas de evaluacion distintas. Y para ti, lo mencionaste antes, no lo dijiste explicitamente pero lo insinuaste: decisiones financieras, impacto financiero. La linea para ti es que la unica forma de evaluar a cualquier experto que traes para tomar decisiones, tomar este dinero y comprar esto, asignar ese stock alli, programar personas para hacer estas cosas, tiene que ser el impacto financiero, al menos como estrella polar.
Joannes Vermorel: Si. Yo diria economico. La distincion es que cuando piensas en terminos economicos hay cosas que no apareceran en tus estados financieros, por ejemplo todos los efectos de largo plazo.
Conor Doherty: Correcto.
Joannes Vermorel: Como el goodwill. No quieres enemistar a tus clientes ni hacer cosas que destruyan tus costes directos e indirectos.
Conor Doherty: Exactamente.
Joannes Vermorel: Todos los costes indirectos, todas las cosas en las que tienes que pensar a largo plazo. Tu perspectiva economica es mucho mas prospectiva que la financiera, que tiende a ser la version de corto plazo de la perspectiva economica.
Conor Doherty: Para quienes escuchan, podrias explicar un poco lo del goodwill? Puede que no sea inmediatamente claro que quieres decir, y como desglosar ese motor economico o esa perspectiva economica, porque es un punto muy interesante.
Joannes Vermorel: Por ejemplo, si dejas que la gente compre productos en un e-commerce y les dices que el articulo se entregara en menos de siete dias, pero en realidad en, digamos, el 30 % de los casos fallas. A corto plazo, si muestras una promesa de entrega corta, puedes aumentar tus ventas. Pero si tienes un porcentaje considerable de fallos en los que no cumples las fechas de entrega que diste a tus propios clientes, te construyes una reputacion terrible. Y con el tiempo perderas cuota de mercado. Puede que no se vea inmediatamente, pero se vera.
Por eso, hace unos anos, ahora ya no se hace tanto, algunas plataformas de e-commerce decian “lo tenemos en stock” cuando no era verdad. Si muestras un articulo online y dices “lo tengo en stock”, si, probablemente duplicaras tus ventas frente al mismo producto diciendo “no lo tengo en stock, pero hare un pedido cuando usted lo pida”. Pero si no eres honesto con tus clientes, arruinaras tu reputacion, y en unos anos habras perdido toda tu cuota de mercado si juegas a eso. Ese es el goodwill del que hablo: toda la fe que tus clientes tienen en ti para seguir haciendo negocios contigo en el futuro.
Conor Doherty: Si, la perspectiva economica, y de nuevo prefiero el termino perspectiva economica.
Joannes Vermorel: Es correcto.
Conor Doherty: Es bueno ordenar eso frente a perspectiva financiera. Pero lograr que la gente lo aprecie es, creo, una parte central de la perspectiva del SCS o del FDE, pero ciertamente para nosotros de la perspectiva del SCS. Es entender que, por ejemplo, las penalizaciones por stockout, el coste de no tener algo, no necesariamente aparece directamente, pero obviamente existe. Si no tienes algo, no lo vendes.
Joannes Vermorel: Y diria que si piensas en FDE, en cuanto dices que esos FDE no estan ahi para hacer automatizacion rutinaria sino para tocar la capa de decision, entonces mi posicion es que necesitas verticalizacion. Necesitas personas expertas en el dominio. Si tratas solo automatizacion rutinaria, esta bien: tomas ingenieros de software inteligentes, pueden ser FDE, lo resolveran. Pero si quieres tocar la capa de decision, entonces no puedes tener personas supuestamente universalmente competentes en todo. No funcionara. Necesitas expertise vertical para tener esta comprension economica correcta.
Conor Doherty: Pero no puedo simplemente elicitar eso? Por ejemplo, dia uno, soy un FDE. Llego. Vale. Cuanto varian sus lead times de media? No puedo simplemente elicitar esa informacion? Por que necesito ser experto de dominio? Por que no puedo ser tecnicamente brillante y hacer preguntas?
Joannes Vermorel: De nuevo, si asumimos que eres Leonardo da Vinci, un genio polimata…
Conor Doherty: Si.
Joannes Vermorel: De acuerdo. Pero si acabas de salir de la universidad, puede que no lo seas. Mi experiencia en Lokad es que cuando tomamos personas inteligentes de una escuela de primer nivel, Ivy League o equivalente, se necesitan unos dos anos para que personas muy brillantes puedan tener una evaluacion de alto nivel correcta de lo que ocurre en la supply chain de una gran empresa. Cultivar ese juicio lleva tiempo. Tipicamente, nuestro objetivo en Lokad es que en seis meses, partiendo de una persona muy inteligente, tengas a alguien capaz de mantener una cuenta. Muchas de las decisiones arquitectonicas super criticas sobre el diseno de la receta numerica ya se han tomado.
Asi que mantener un sistema puede lograrse en seis meses. Pero para tomar esas decisiones con precision y sabiduria, hace falta mas bien dos anos, incluso empezando con personas muy inteligentes y con foco exclusivo en una vertical.
Conor Doherty: Si. Es cierto.
Joannes Vermorel: El problema, a mi juicio, es que si tienes personas que hacen una mision tras otra, y se supone que son misiones de corto plazo de unos meses, no hay magia. No podran tener esa perspectiva economica bien formada. Asi que la mayor parte de lo que saldra de ellos, si empiezan a trabajar en la capa de decision, sera falso. Es asi. Y en Lokad, incluso para nosotros, los primeros cinco anos fueron extremadamente dificiles. Los primeros anos de Lokad fueron atroces.
No habia entendido lo que tenia que entender. En mi defensa, la casi totalidad de los libros sobre supply chain son completamente falsos, y lo siguen siendo.
Conor Doherty: Creo que ya hemos cubierto ese terreno.
Joannes Vermorel: Sin embargo, yo me estaba comportando exactamente como un FDE sin verdadera expertise vertical, y si, eso provoco mucho dolor y miseria. Asi que mi opinion es que si las empresas contratan FDE, deben asegurarse de que se centren en automatizacion estricta y absoluta, donde el criterio sera muy simple: headcount. Y para la capa de decision, asegurense absolutamente de tener personas realmente verticalizadas. Cuando lo piensas, es sentido comun. Lokad trata problemas de supply chain, pero imagina que quieres contratar a alguien para lidiar con fraudes financieros en el sistema bancario. Es un area increiblemente especializada. Yo no afirmaria saber exactamente como operan los estafadores cuando intentan literalmente estafar bancos con estructuras transnacionales, identidades falsas, documentos falsos, etc. Esa no es mi expertise. Si piensas que puedes traer a un ingeniero inteligente recien salido de la escuela de ingenieria y tratar problemas que requieren especializacion vertical muy profunda, simplemente no funcionara. Esas personas necesitaran tiempo, potencialmente anos, para convertirse realmente en expertos del dominio. Y eso socava la promesa del FDE: contratas a esos tipos, hacen su mision de tres meses, bam, payback, se van a casa y tienes un retorno rentable.
Conor Doherty: Para quienes escuchan, y esto se basa en la idea de que tienes habilidades tecnicas pero todavia no expertise de dominio. Como sabes, y te pido tu experiencia anecdotica, como sabes si alguien seria un buen SCS? Porque sale de una grande ecole, obviamente no sabe nada de supply chain todavia, o muy probablemente no sabe nada de las peculiaridades y excentricidades.
Entonces, como sabes, Joannes, que esta persona es una buena inversion, que tiene habilidades suficientes, etc.?
Joannes Vermorel: Generalmente evaluamos la capacidad bruta de aprender, eso es todo. Y creo que la mayoria de las empresas que venden FDE hacen exactamente lo mismo. Simplemente dicen: tomamos personas inteligentes que pueden aprender muy rapido, acumulamos ese talento, y funciona. Lo que digo no es que no funcione. Digo que si quieres operar al nivel de la automatizacion, lo que necesitas es formar a la gente en el arte de hacer software, y estaras bien. Sera muy agnostico. Puedes tener una perspectiva completamente horizontal; pueden abordar cualquier vertical y estara bien, si tratas solo automatizacion estricta.
Si quieres tratar la capa de decision, digo que tomas personas inteligentes y luego esas personas tienen que ser formadas para esta vertical. Asi que la pregunta sera: compras un FDE, un forward deployed engineer, para tu vertical; ese FDE ha sido formado explicitamente para esta vertical, si o no? Y si la empresa simplemente dice: no, contratamos a los mejores, confien en nosotros, ira bien, no ira bien.
Lo que digo es que si quieres a alguien tratando una capa de toma de decisiones que decidira sobre situaciones avanzadas de fraude en el sistema bancario, mas vale que tenga una comprension real de lo que ocurre en el sistema bancario. Si quieres a alguien que tomara decisiones para un sistema avanzado de diagnostico medico que implica la vida de pacientes, quiero que esa persona sea muy competente en ciencias medicas ademas de ser ingeniero de software.
Cuando lo piensas, es realmente obvio.
Conor Doherty: Bueno, vale. Si. Si. Estoy de acuerdo.
Joannes Vermorel: Pero volviendo atras, tomemos el hospital para contrastar dos misiones de FDE. Una, y he visto las dos, es que las personas se registran varias veces en varias divisiones del hospital, y por tanto tienes que reconciliar que en realidad es el mismo paciente.
Conor Doherty: Si.
Joannes Vermorel: Si no, acabas con muchos duplicados, porque mucha gente se registra aqui, y luego alla, y hay problemas. Hay muchos registros duplicados. No podras resolver este problema de reconciliar duplicados con un sistema burdo. Asi que traes un FDE, y esas personas automatizan la reconciliacion de esos duplicados.
Conor Doherty: Perfecto.
Joannes Vermorel: Ahora, ese es un problema que no requiere verdadera expertise medica. Ocurre en un hospital, pero al final se trata de reconciliar personas identicas con posibles errores tipograficos en nombre, apellido, direccion, numero de telefono y demas. Ahora bien, si quieres algo que vaya a tomar una decision sobre cualquier cosa medica, una decision con consecuencias para la vida del paciente y financieramente para el hospital, entonces quieres a alguien bien versado en ciencias medicas. La linea no es tan sutil en la practica, y creo que muchas empresas tienden a confundir si tratan automatizacion inteligente o decisiones inteligentes. Las dos cosas tienen, en la practica, vibes y requisitos muy distintos.
Conor Doherty: Como pensamiento final, si tuviera que sacar al menos un par de conclusiones, y puedes decirme si estas de acuerdo o no. Crees que es justo decir que, segun lo que hemos discutido hoy y desde luego la emergencia y popularizacion de este rol, la afirmacion que hemos oido durante un par de anos, o varios anos, de que si quieres optimizar tu toma de decisiones solo tienes que comprar un modulo adicional, enchufarlo y listo, esta muerta? Estas de acuerdo?
Joannes Vermorel: Si. Si.
Conor Doherty: Pero nosotros siempre pensamos eso. Quiero decir, crees que esto nunca funciona? Crees que el mainstream ahora esta diciendo tacitamente: si, si, eso no funciona? Eso es lo que deberia haber dicho.
Joannes Vermorel: No lo se. Claramente los proveedores que venden FDE estan diciendo eso.
Conor Doherty: Si. Bueno, es verdad.
Joannes Vermorel: Pero los otros proveedores que no venden FDE siguen diciendo lo contrario. Diria que el tiempo lo dira. Pero sigo viendo que el mercado esta absolutamente lleno de proveedores ERP que venden un modulo de optimizacion de inventario.
Quiero decir, todavia hay como mil empresas haciendo eso. Asi que el tiempo lo dira. Quiza si, con el tiempo. Claramente es una tendencia interesante, pero no estoy seguro de que sea dominante todavia. Parte del problema es que las empresas que venden FDE tambien son extremadamente caras, y esa es una de las debilidades de esas empresas de perfil muy alto, como OpenAI, Anthropic, Amazon: son empresas que pagan salarios que tienden a ser un poco extravagantes comparados con las normas del mercado. Por ejemplo, OpenAI ha estado contratando rutinariamente personas con paquetes anuales multimillonarios.
El problema no es que yo evalue que esas personas no lo valen. Digo simplemente que si toda tu estructura de costes, desde la perspectiva del proveedor, tiene que tener en cuenta a ese tipo de personas…
Conor Doherty: Si.
Joannes Vermorel: Tu punto de precio para cobrar por tus FDE probablemente sera irrazonablemente alto. Eso es algo que digo. Y por cierto, si miras la historia de Palantir, ha sido una historia de idas y vueltas: progresan en el dominio, luego progresan muchisimo, y luego reducen escala simplemente porque son super caros, y muchos de sus clientes, despues del entusiasmo inicial, dicen: es demasiado caro, tenemos que reducir.
Conor Doherty: Bueno, para separar un poco esa idea, si te entendi correctamente, esencialmente estas de acuerdo conmigo en el punto de que hacerlo bien, sea lo que sea, hacer bien el proyecto de IA, podria ser prohibitivo. Y como resultado de eso, seguira habiendo gente, proveedores que vendan esencialmente, no voy a decir aceite de serpiente, pero que te vendan: si, si, compra este modulo, lo optimizara todo. Y eso es una alternativa mas barata. Es imperfecta, pero es una alternativa mas barata que comprar un FDE.
Asi que creo que realmente no hay contradiccion en esos terminos. Puede seguir existiendo como producto aunque la existencia de un FDE socave de alguna manera la optimizacion de un modulo de optimizacion. Es algo filosofico, pero creo que ese era el punto al que llegabamos.
Joannes Vermorel: Si. Si. Exactamente.
Conor Doherty: Bueno, Joannes, lo he disfrutado mucho, pero no tengo mas preguntas. Muchas gracias por tu tiempo. Y para cualquiera que este escuchando, debo senalar que hay puestos de Supply Chain Scientist abiertos en Lokad. Asi que si les interesa, revisen nuestro LinkedIn o enviennos un email a contact@lokad.com.
Y dicho esto, no queda nada mas que decir excepto: vuelvan al trabajo.
