Compras aeroespaciales optimizadas: demo guiada de las soluciones de Lokad

Back to Lokad TV

00:00:00 Compras aeroespaciales: incertidumbre y prioridades economicas
00:05:58 Visibilidad de la flota, objetivos de servicio y costes de inversion
00:11:47 Rotables, consumibles e inversiones ordenadas economicamente
00:17:23 Prioridades bajo restricciones presupuestarias y operativas
00:23:56 Clasificar inversiones por ganancias de servicio por dolar
00:29:43 Validar datos y modelizar demanda incierta
00:35:48 Combinar incertidumbre de demanda y de tiempos de reparacion
00:41:42 Integracion de sistemas y oportunidades de desinversion
00:47:15 Intercambios, prioridades de reparacion e integracion de proveedores
00:53:29 Preparacion de datos y requisitos de implementacion
00:58:44 Simulaciones historicas y trazabilidad de decisiones
01:04:10 Prioridades economicas, consumibles y retrasos de proveedores
01:09:14 Prevision de mantenimiento y seguimiento de la adhesion a las recomendaciones
01:14:05 Automatizacion de compras, plataformas de procurement y prioridades de reparacion
01:19:52 Conclusiones principales y cierre

Resumen

Conor Doherty y Fabian Hoehner demuestran como Lokad convierte demanda incierta, tiempos de reparacion y presupuestos limitados en decisiones de compra aeroespaciales priorizadas. El enfoque evalua cada unidad adicional segun su contribucion esperada al servicio, o a evitar aircraft-on-ground, en relacion con su coste. El mismo razonamiento apoya la desinversion, la priorizacion de reparaciones y los traslados de stock. Lokad funciona junto a los sistemas existentes, con supply chain scientists y expertos operativos que refinan los calculos. Las simulaciones historicas ayudan a explicar decisiones pasadas, mientras que la automatizacion depende del valor y la complejidad de las compras implicadas.

Resumen extendido

Las compras aeroespaciales implican elegir entre usos rivales de recursos escasos. Comprar otro repuesto puede reducir el riesgo de dejar un avion en tierra, pero tambien compromete dinero que podria proteger otra operacion mas importante. En esta demostracion en directo, Conor Doherty y Fabian Hoehner explican como Lokad evalua esas decisiones. La pregunta central es cuanto servicio adicional, o cuanta evitacion de AOG, puede comprar razonablemente cada dolar. Las cantidades de inventario se derivan de esa comparacion, junto con las restricciones bajo las que opera el negocio.

La demostracion empieza con una flota aerea ilustrativa y un pool de rotables: piezas que pueden repararse y volver al servicio. Su disponibilidad depende tanto de la demanda como del tiempo que pasan en procesos de reparacion y logistica. Cinco unidades en propiedad no ofrecen la misma proteccion que cinco unidades serviceables disponibles de inmediato. Lokad extrae datos transaccionales de los sistemas existentes para establecer esa imagen operativa y despues calcula recomendaciones de inversion. En el ejemplo, unos 68 millones de dolares de stock proporcionan un nivel de servicio esperado del 95,7 %; una inversion adicional de aproximadamente 1,2 millones de dolares lo acerca al 98 %. Las mejoras posteriores se vuelven cada vez mas caras.

Las recomendaciones se ordenan unidad por unidad. Una unidad adicional de un PN concreto compite con unidades adicionales de otros PNs, incluidas piezas con precios y patrones de demanda muy distintos. La primera unidad suele cubrir mas incertidumbre que la segunda o la tercera. Ese beneficio decreciente importa: comprar varias unidades de una pieza puede ser menos valioso que repartir la inversion. La esencialidad tambien importa. Una pieza no-go relativamente barata puede justificar una mayor disponibilidad que una pieza cara cuya ausencia tenga consecuencias menos graves. Una lista ordenada tambien facilita aplicar limites de presupuesto, capacidad de compra y restricciones de recepcion.

Esas comparaciones requieren tratar la incertidumbre de forma realista. La demanda aeroespacial suele ser escasa e irregular, mientras que los tiempos de reparacion pueden variar sustancialmente. Los promedios ocultan precisamente las situaciones excepcionales contra las que una aerolinea quiere protegerse. Por ello, Lokad modeliza distribuciones de demanda y de tiempos de reposicion, combinandolas para estimar la demanda en posibles horizontes futuros. Hoehner ilustra como las reparaciones pueden agruparse alrededor de una duracion corta cuando todo va bien y de una duracion mucho mas larga cuando surgen complicaciones. Sustituir ese patron por un unico promedio puede tergiversar el stock requerido. Los eventos de mantenimiento conocidos, las listas de materiales probabilisticas y las tendencias cambiantes de turnaround time tambien pueden alimentar los calculos.

Las estimaciones financieras hacen que los trade-offs resultantes se puedan discutir. El coste de un evento AOG puede ser dificil de establecer, pero una estimacion aproximada da a los equipos una base para comparar decisiones y revisar supuestos. El conocimiento operativo sigue siendo esencial: una funda de asiento o una cafetera puede tener consecuencias que las clasificaciones tecnicas de aeronavegabilidad no capturan por si solas. Los usuarios examinan recomendaciones mediante inspectores de articulos y dashboards de apoyo, cuestionan resultados sorprendentes y ayudan a refinar el modelo. Las compras caras de rotables normalmente siguen requiriendo validacion experta y cotizaciones de proveedores; los consumibles y expendables de menor valor ofrecen mayor margen para ejecucion automatica.

El mismo razonamiento se extiende a desinversion, reparaciones y asignacion. La desinversion compara el efectivo liberado con la proteccion de servicio que se abandona. La priorizacion de reparaciones identifica que unidades no serviceables justifican con mayor urgencia gasto o aceleracion. Los traslados comparan costes de transporte y aumento de riesgo en la ubicacion suministradora con los beneficios en otro lugar y con la alternativa de comprar mas stock. Son decisiones economicas relacionadas, aunque cada una requiere sus propios detalles operativos. Una oportunidad teorica de desinversion, por ejemplo, aun depende de encontrar un comprador y establecer un valor de mercado realista.

Lokad opera como un sistema de inteligencia junto al software transaccional. Sus supply chain scientists adaptan la solucion a los datos y procesos del cliente; los proveedores no necesitan adoptar una nueva plataforma. Las decisiones utiles tambien ayudan a revelar que defectos de datos merecen atencion, evitando intentos indefinidos de limpiarlo todo primero. Hoehner describe unos seis meses como implementacion tipica, con variacion sustancial. Las ejecuciones historicas quedan disponibles para investigacion, permitiendo a los equipos distinguir una restriccion presupuestaria de un mal supuesto o de un riesgo aceptado. La disciplina general es continua: cuantificar la incertidumbre, comparar consecuencias y mejorar decisiones a medida que se acumula evidencia.

Transcripcion completa

Conor Doherty: Bienvenidos a la primera demo en directo de Lokad. Hoy les mostraremos como Lokad genera decisiones de inversion y desinversion en el sector aeroespacial. Hoy les mostraremos que PNs deben tener prioridad.

Hoy les mostraremos como debe dividirse un presupuesto limitado, y como sus restricciones, ya sean plazos de proveedor, tiempos de turnaround, costes o el propio presupuesto, influyen en las decisiones que generamos para ustedes. Este es un evento en directo, asi que por favor envien sus preguntas. Probablemente las responderemos dentro de unos 30 minutos. Depende de cuanto divaguemos.

Pero, quienes somos? Soy Conor, director de marketing aqui en Lokad. Y me acompana en el estudio mi muy buen amigo y director de cuentas estrategicas, Fabian Hoehner. Guten Tag, Herr Hoehner, wie geht’s?

Fabian Hoehner: Hola, Conor.

Conor Doherty: Das ist wunderbar. Entonces, Fabi, como la gente puede ver en la esquina de la pantalla, o deberia poder verlo ya, pronto miraremos una cuenta demo de compras aeroespaciales. Nos centraremos en compras, pero algunas personas que estan presentes, y que lo veran despues, no estan necesariamente tan familiarizadas con Lokad. Algunas si, pero muchas no.

Tomemos entonces un minuto antes de entrar en materia. Podrias responder dos preguntas rapidas? Una: como ve exactamente Lokad el problema de las compras en el sector aeroespacial? Y dos: si la gente solo ve los primeros minutos, que conceptos clave deberia llevarse?

Fabian Hoehner: No me preguntaste eso en la preparacion, asi que esto es…

Conor Doherty: No, no lo hice. Queria improvisacion.

Fabian Hoehner: Si. De acuerdo. Habra una mezcla de personas familiarizadas y no familiarizadas. Asi que intentaremos mantenerlo a alto nivel, pero profundizar un poco en algunas areas. Las dos cosas que me gustaria que la gente se llevara son, por un lado, como gestionamos la incertidumbre.

Incertidumbre, en los temas de los que hablamos, significa principalmente incertidumbre de proveedores, es decir, tiempos de turnaround, tiempos de entrega, y por otro lado incertidumbre de la demanda. Y el segundo aspecto es la optimizacion economica, la priorizacion economica. Con un recurso disponible limitado, como hago lo mejor posible, basicamente? Como compro de forma eficiente en ese caso? Esas son las dos areas principales que me gustaria que la gente se llevara hoy.

Conor Doherty: Entonces, en una frase, por cada euro, dolar o cualquier moneda en la que operen, por cada euro que invierten en inventario, cual es esencialmente la ganancia esperada de nivel de servicio?

Fabian Hoehner: Si. Para ser mas preciso, lo que se quiere hacer, y entraremos en detalle, es maximizar la ganancia de nivel de servicio por dolar, o reducir el AOG, aircraft on ground, por dolar gastado. Es la ruta mas eficiente hacia el objetivo, y esperamos que ese sea uno de los mensajes principales para quienes nos escuchan hoy.

Conor Doherty: Bien. Ahora que hemos puesto la mesa, no enterremos mas el titular. Vamos directamente a la cuenta demo.

Max, nuestro productor, puedes cambiar cuando quieras, asegurate de que todo este bien. Subcto. Muy bien. Fabi, estoy mirando mi propia pantalla porque mi vista es terrible, pero que estamos mirando exactamente?

Por favor, explicaselo a la gente para que entienda: cual es el contexto aqui? Es aviacion? Es MRO? Es IA? Estamos haciendo IA?

Fabian Hoehner: Si, siempre hacemos IA, por supuesto. Entraremos en detalle sobre lo que hacemos en terminos de IA, pero efectivamente estamos en una cuenta demo. Lokad en 20 segundos: disenamos soluciones personalizadas de optimizacion de inventario para nuestros clientes en distintas areas, y hoy nos centraremos en aeronautica. Podria ser MRO, mantenimiento, reparacion y overhaul, pero nos centraremos en un ejemplo basicamente de una aerolinea.

La pregunta principal que nos haremos es: para una flota dada, como obtengo la ruta mas eficiente de inversion, y potencialmente de desinversion, para mi stock? Esa es la pregunta general. Muy rapido, donde estamos ahora. Pueden ver que estamos en go.lokad.com.

Esta es una cuenta demo. Todos nuestros clientes estan en la misma plataforma. Es una aplicacion multi-tenant, pero escribimos una solucion individual para cada cliente. Eso es lo que hace que las demos sean, en cierto modo, dificiles, porque cada cliente es muy diferente.

Conor Doherty: Diferente. Si, claro.

Fabian Hoehner: Asi que este es, diria, nuestro USP: personalizar lo que hacemos. El foco de hoy sera mostrar los dos principios a los que aludi al principio. Por un lado, como vemos la incertidumbre.

La palabra clave sera prevision probabilistica. Las personas que nos siguen un poco lo han escuchado muchas, muchas veces, pero hoy vamos a hacerlo muy practico. Y luego, segundo: optimizacion economica para un ejemplo especifico. Si hay preguntas, por supuesto, haganlas mientras avanzamos.

A menudo mi respuesta sera: “si, si es logico, podemos construirlo, o ya lo hemos construido en el pasado”, pero hoy estamos mirando un ejemplo especifico. Eso es lo que propongo examinar. Alguna pregunta adicional? Si no, empezamos.

Conor Doherty: Yo diria que empecemos, porque ya hay muchas preguntas. Como la gente sabe, he hablado con muchas personas antes de esto. Asi que hay algunas preguntas muy concretas a las que volveremos despues, pero como dije, si algo destaca para cualquiera que este mirando, comenten abajo y lo desgranaremos a su debido tiempo.

Fabian Hoehner: Si. Y tu me conoces, asi que interrumpeme. Si no, yo…

Conor Doherty: Lo hare, no te preocupes.

Fabian Hoehner: Me meto en mi propio flujo. Muy bien. Esto es, de nuevo, una cuenta demo, y lo que vemos aqui es solo una vista general. Podria hacer clic en cualquier cosa, pero hoy vamos a profundizar solo en dos o tres pantallas.

En este caso, estamos mirando un dashboard de vision general. Vamos a usar una piramide invertida. Empezaremos con la vision general y luego iremos bajando hasta el nivel mas bajo. Esto seria una vista de gestion donde podemos ver el rendimiento del pool.

En este caso, pueden ver que es un pool. Podria venir de varias aerolineas. Lo fundamental es que estamos mirando una flota, en este caso Triple 7. Que sea de una o varias aerolineas no importa; lo importante son las piezas que necesito para dar servicio a esa flota.

Ese sera el concepto general aqui. En este caso pueden ver una visualizacion historica de consumo y, por supuesto, sube porque Lokad optimiza, asi que las cosas siempre mejoran. Y algunas vistas adicionales sobre la situacion operativa actual. Donde esta mi stock?

En aeronautica siempre hablamos de bucles. Este sera un concepto muy importante. Obviamente, la mayoria de las personas que miran hoy estan muy familiarizadas con ello. Pero stock no equivale simplemente a stock en aeronautica.

Se trata de tener stock serviceable y stock unserviceable, y saber donde esta dentro del proceso. Tener cinco unidades, tener cinco unidades serviceable, tener cuatro unidades en un ciclo de reparacion, una unidad serviceable: esas son interpretaciones muy distintas de la realidad. Asi que esto es basicamente un dashboard de vision general. Como habriamos llegado aqui? Seria integrando…

Conor Doherty: Literalmente estaba a punto de hacerte exactamente esa pregunta, abriendo la boca para preguntarla.

Fabian Hoehner: Si. Normalmente, en este caso, los datos, de donde vienen? De distintos sistemas ERP, sistemas MRP, pero en el fondo datos transaccionales que llevamos a la plataforma, Lokad siendo una plataforma de inteligencia. El sistema transaccional, ERP, MRP, solo dice “donde estan mis cosas”, el nivel transaccional. Tomamos eso diariamente y luego hacemos, diria, la manipulacion big data para obtener el insight de “tengo 186 unidades que ahora mismo estan en un proceso de retorno”. Bien, o…

Conor Doherty: No, estuvo bien.

Fabian Hoehner: Perfecto. Entonces, vision general de alto nivel, y ahora vamos a entrar directamente en el resultado. Empezaremos con como podria verse el resultado de una optimizacion, y en este caso lo que miramos aqui es la optimizacion de inversion.

Estamos mirando una inversion que queremos obtener para, en este caso, un nivel de servicio objetivo del 98 %. Podemos ver que aqui hay un pequeno simulador con un desplegable, asi que puedo simular diferentes escenarios que ya he pre-calculado, en este caso para hacerlo rapido. Tambien podriamos disenar esto de otra forma, con un pequeno campo para introducir valores y probar yo mismo, pero en este caso lo hemos pre-calculado para hacerlo mas rapido. Y lo que vemos aqui, para una situacion dada, es nuestro stock actual, en este caso 68 millones, y esos 68 millones se espera que me den un nivel de servicio del 95,7 %.

Conor Doherty: Mhm.

Fabian Hoehner: 95,7 % de disponibilidad respecto a los tiempos de entrega individuales de todas las distintas piezas, y ponderado por su consumo.

Conor Doherty: De acuerdo.

Fabian Hoehner: Lo siguiente que hacemos es seleccionar, en este caso vayamos a nuestro 98 aqui. Seleccionamos: “de acuerdo, queremos tener un 98 % de disponibilidad media ponderada por consumo, etc.” Y en este caso, el simulador me dice: “de acuerdo, necesito invertir 1,2 millones”, y alcanzare mi objetivo, en este caso 97,99. Eso es lo que habria obtenido.

Ese es el nivel mas alto. Podria jugar con eso, y si lo hicieramos, veriamos algo muy tipico en aeronautica, que estoy seguro de que la mayoria de la audiencia conoce muy bien: la cola larga es donde estan los costes. Asi que, si miramos, pase de 98 o 98,5 a 99,5.

Probemos ir a 99. Asi que tenemos el 1 %. Lo que vemos es que el primer punto porcentual que queriamos ganar, o los primeros dos puntos, nos cuestan un millon de dolares de inversion, y luego conseguir el siguiente costara 2,5. Ese aumento exponencial para ganar esos puntos de nivel de servicio es extremadamente importante cuando hablamos, al principio, de la tecnologia.

Por que es importante? Que estamos haciendo diferente? El gran encaje de Lokad en esta industria es entender como tratar la demanda dispersa y erratica, que es la mayoria de los problemas aeronauticos. Eso significa: como entender mejor la probabilidad de los extremos, es decir, esos percentiles por encima del 90 %, porque ahi es basicamente donde juega la aeronautica. La aeronautica es un sector extremadamente averso al riesgo; quedarse sin stock cuesta muchisimo dinero.

Conor Doherty: Si. Mucho mas que la pieza individual en muchos casos.

Fabian Hoehner: Tradicionalmente, en aeronautica, todo el mundo esta sobrestockado. “Ante la duda, compra otra.” Ese es el enfoque tipico.

Entender cuan probable es un escenario de 99 o 99,5 es extremadamente importante al nivel de la pieza individual. Volveremos a eso a un nivel mas detallado. A alto nivel, por que miramos todos esos extremos?

Porque ahi es donde jugamos en aeronautica. Nadie quiere saber cual es la media. Eso significaria que tienes suficiente stock en el 50 % de los casos. Eso no te importa.

Quieres saber cuan probable es cubrir los extremos. Asi que, mirando eso, de nuevo vamos de alto nivel a bajo nivel. Aqui tenemos la inversion, y ahora esta es mi inversion total. Queremos saber cuales son, tipicamente para el cliente, las cantidades. En este caso tenemos, de forma muy directa, una lista de “estos son mis articulos y estas son las cantidades en las que estamos invirtiendo”.

Conor Doherty: Para aclarar, en este punto estamos mirando rotables o consumibles? Esto son solo rotables.

Fabian Hoehner: Si, rotables.

Conor Doherty: Si, absolutamente. Pero veremos consumibles despues, o tocaremos la logica alli.

Fabian Hoehner: Si, tocaremos la logica, pero…

Conor Doherty: Pero estas son basicamente las piezas mas caras. Por eso las estamos mirando.

Fabian Hoehner: Viste que los valores que estamos viendo aqui seran bastante importantes, porque si, efectivamente miramos rotables. La mayoria de los conceptos son transferibles a consumibles. La principal diferencia es que la pieza rotable, por definicion, tiene una rotacion, es decir, un bucle, en lugar de varios bucles de reparacion.

En teoria, puedes hacerlo internamente, o tienes scrap. Y un consumible simplemente lo compras y sale. Asi que hay algunas diferencias en las matematicas, pero los principios subyacentes a los que me referia al principio, la incertidumbre, o cuantificar la incertidumbre, y la priorizacion basada en economia, siguen siendo los mismos.

Conor Doherty: De acuerdo.

Fabian Hoehner: La pregunta ahora es por que recomendamos cuatro, tres, cinco, y asi sucesivamente. Para eso entraremos un poco mas en detalle, pero primero seguiremos relativamente a alto nivel. Lo que vemos aqui es, de nuevo, la misma lista que antes, pero con informacion adicional. Y lo primero que intuitivamente queremos ver, asi que voy a mostrar bastantes pantallas con muchos numeros.

Te dire a ti y a la audiencia que cosas deberian mirar. En este caso, esta es mi lista y estas son las piezas que recomiendo comprar. Pueden ver cuatro unidades aqui, tres alla, cinco, etc. Lo importante es lo que la optimizacion deberia estar haciendo intuitivamente.

Explicare como llegamos ahi. Iremos cada vez mas profundo. Pero primero, tiene sentido intuitivamente? Intuitivamente, que deberia hacer una optimizacion que busca eficiencia?

Si la eficiencia es reduccion de AOG por dolar gastado, o aumento del nivel de servicio por dolar gastado, deberiamos ver que las piezas que son, A, relativamente baratas y, B, muy importantes, estan sobreponderadas en disponibilidad respecto a piezas caras y no importantes. Si miramos esta lista, veamos las dos primeras piezas porque tienen un precio unitario bastante similar. Y lo que vemos es que una pieza esta mucho mas alta. El nivel de servicio final, el nivel de servicio actual, es lo que estoy cubriendo con el stock actual que poseo.

El nivel de servicio final es adonde llego despues de la optimizacion. En este caso, llevamos esta a 94 % y esta a 80 %. Por que? Si lo miramos, esta tiene una essentiality: no-go. Y esta es go-if.

En resumen, la consecuencia de una ruptura de stock aqui es mucho mas cara. Por eso esta relativamente sobrestockada, y esa deberia ser la intuicion. Si bajamos por la lista, deberiamos ver lo mismo. Aqui vemos una pieza a 99. De hecho, dime si es demasiado pequeno, de acuerdo?

Conor Doherty: Eso esta mejor. Gracias. Si, al menos para mi, porque estoy casi ciego.

Fabian Hoehner: Si. Aqui podemos ver que es 99,5. La pieza es relativamente barata, 8.000 dolares, y es una pieza no-go. Asi que esa intuicion deberia mantenerse siempre: las piezas que almacenamos agresivamente respecto a otras deberian ser no-go y bastante baratas, mientras que las que almacenamos menos agresivamente deberian ser… aqui vemos que es una pieza go que no es realmente cara, pero solo go.

Esa es la logica subyacente inicial, la que debe mantenerse. Ahora la pregunta es: como llegamos exactamente a cuatro, tres, cinco, etc.? Intuitivamente tiene sentido. Bien.

Segundo paso: como llegamos exactamente a eso? Aqui es donde, por primera vez, ya vemos a alto nivel que hay un concepto de priorizacion economica escondido ahi. Ahora, como llegamos ahi con mas detalle? Esto es lo que llamamos una priorizacion ordenada. En este caso, una lista de inversiones ordenada.

Lo que hacemos aqui es mirar cada compra individual, o en este caso cada posibilidad de inversion que tenemos, y simular cual seria la consecuencia economica de invertir en esa pieza. Si miran las dos o tres primeras lineas, pueden ver que es el mismo PN, pero no es la misma unidad de mantenimiento de stock, porque estamos comprando la primera pieza, luego la segunda, luego la tercera. Eso es basicamente lo que hacemos en todas partes. Simulamos la compra de cada pieza individual que podriamos comprar. Asi que esta lista aqui es basicamente interminable. Podria hacer scroll indefinidamente, y eso es lo que hacemos.

Conor Doherty: Esta limitada por el presupuesto, supongo, porque veo que esta ordenada de nuevo. La inversion total aumenta a medida que bajas. Asi que imagino que podrias fijar un limite estricto, como “solo tengo X; mi presupuesto es X. No es infinito. Por tanto, optimiza hasta este punto y no mas alla.” Fabian Hoehner: Si. En este caso, no esta limitado por el presupuesto, sino por mi objetivo, que aqui es 98 %. Pero tienes toda la razon. Basicamente, el 98 % da como resultado un presupuesto de 1,2 o 1,25 millones. Asi que lo que vamos a hacer es exactamente eso.

Vamos a desplazarnos hacia abajo hasta llegar a una inversion total de 1,25. En este caso lo hicimos de otra manera. Intentamos llegar al 98 % y 1,2 fue el resultado. Pero podria haber hecho lo inverso. Podria haber dicho…

Conor Doherty: Si, claro.

Fabian Hoehner: Es lo mismo, simplemente visto desde una perspectiva diferente. Bien. Ahora veamos algunos ejemplos para mostrar, basicamente, como funciona esta logica de priorizacion economica. Un buen test, tambien para las personas de la audiencia que hacen su propia optimizacion, es siempre: puedes decirme, si te digo “tienes 100.000 dolares, cual seria el articulo mas importante que deberias comprar hoy?”

Ese es un concepto muy importante. No sera para esta primera pieza, pero en general sirve para priorizar cada accion que tomas, porque con esa logica puedes introducir cualquier restriccion que tengas: “mi equipo de compras solo puede gestionar cinco piezas al dia”, “mi almacen solo puede recibir diez al dia”, cualquiera que sea la restriccion, o “tengo un millon de presupuesto”. Si no tienes una vista priorizada, es muy dificil si solo tienes un si/no. Por ejemplo: “mi objetivo es que la pieza A este al 99 %, la pieza B al 95 %, y la pieza C al 91 %.”

Extremo, pero de acuerdo. En ese caso es solo si o no, y no tienes un sistema de ranking. Ese concepto es increiblemente importante aqui, porque lo que podemos hacer es precisamente priorizar. Siempre lo necesitas: tiempo limitado, presupuesto, lo que sea. Asi que, de nuevo, la pregunta para la audiencia seria: “puedes identificar cual es el unico articulo mas importante que necesito hoy?” Y, de nuevo, no importa solo el primero: cuales son los 50 mas importantes?

Eso es efectivamente lo que podemos hacer aqui, y lo haremos mirando la primera linea. Estamos mirando el 1338. Vamos a mirar el 1338 durante bastante tiempo, asi que tengan paciencia.

Vemos que actualmente no tenemos ninguno en stock. Estamos considerando comprar uno. Vemos cuantos se solicitaron durante el ultimo ano. Luego compramos una unidad que cuesta 1.200 dolares, y actualmente tenemos nivel de servicio cero, o nivel de servicio esperado cero.

Por que? Tenemos cero en stock. Si tienes cero, no vas a cubrir ninguna incertidumbre. Eso es basicamente lo que significa.

Mi nivel de servicio esperado significa: cuanta incertidumbre sobre el futuro estoy cubriendo? Que significa exactamente, lo veremos en el siguiente paso. Como dije, vamos de alto nivel a bajo nivel. Podrias detenerte en: “estos son los articulos que deberias comprar”, y ya esta. Pero, obviamente, queremos ir un poco mas profundo y entender de donde viene.

Conor Doherty: Me meto un segundo, porque ese es un buen punto. Recibi varias versiones de la misma pregunta: “la idea es interesante, suena genial”, porque algunas personas ya conocen Lokad, “pero como se ve esto para, digamos, mi equipo de planificacion?” Porque acabas de decir: “miren estos dashboards, aqui estan las decisiones ordenadas.”

Luego dijiste “vamos a entrar en un analisis mucho mas profundo”, pero tambien dijiste que podrias detenerte aqui. Asi que, esencialmente, tu equipo de planificacion podria detenerse en este punto. Ya tienes las decisiones. Si confias en el sistema, puedes ejecutar. Si quieres saber mas, puedes investigar por que esta unidad, este PN, esta por encima de aquel, etc.

Fabian Hoehner: Si.

Conor Doherty: De acuerdo.

Fabian Hoehner: Efectivamente. Suponiendo que hayamos configurado el sistema. Podemos hablar de cuanto tiempo toma, pero digamos que despues de seis meses tienes un sistema funcionando. Podrias decir simplemente: “confio en el sistema”, y las recomendaciones se exportan y se ejecutan en los sistemas operativos.

De nuevo, no somos un sistema transaccional. Somos un sistema de inteligencia. Estamos ahi para ejecutar simulaciones complicadas y luego devolver la inteligencia al sistema operativo.

Conor Doherty: Adelante.

Fabian Hoehner: Ya lo dije. Dicho eso…

Conor Doherty: Si.

Fabian Hoehner: Habria muy pocas personas que, si recordamos las piezas que miramos antes, una pieza de 46.000 dolares, no la ejecutarian automaticamente. Y esto no es…

Conor Doherty: Si.

Fabian Hoehner: Asi no funciona. Son piezas para las que realmente necesitas pedir una cotizacion. En aeronautica, esto no es como el e-commerce de Amazon.

No, pedirias el precio de la pieza, y el precio que tenemos aqui es una hipotesis hasta que se valida. Es un proceso manual, o puede automatizarse, pero mi punto es: las piezas rotable que miramos aqui probablemente no sean algo que automatizarias por completo. Podrias, por supuesto, pero efectivamente…

Conor Doherty: La ejecucion de la decision no necesariamente, pero el analisis y la generacion real de la decision estan automatizados.

Fabian Hoehner: Tu pregunta es basicamente: “que mira la gente?” Yo diria que, normalmente, si no merece el tiempo, por ejemplo si las piezas estan por debajo de 2.000 dolares o si estuvieramos mirando C&E, entonces puedes, y de hecho lo hacemos, automatizarlo todo. Se actualizan los sistemas operativos diariamente y se empuja automaticamente una orden. Si hablamos de inversiones rotable, eso normalmente es algo que expertos revisan para validar muchas cosas.

En ese caso, hacemos algo muy parecido a lo que hacemos aqui. Tenemos la recomendacion, que te dice “compra cinco unidades de esto”. Luego tienes a un experto que hace este trabajo, que cuestiona ese resultado. Al principio lo cuestiona para construir, disenar y mejorar el sistema con nosotros, y luego tambien para investigar. El proceso de investigacion, el razonamiento de como llego a “compra cinco unidades”, es exactamente lo que estoy haciendo aqui, lo que les estoy mostrando. Como llegue a eso? Asi que, volviendo a si no me hubieras interrumpido, ya estaria hecho, pero bueno.

Conor Doherty: Mis disculpas.

Fabian Hoehner: Miramos el 1338 y dijimos: “comprar una unidad nos lleva al 47 %.” Asi que cubre el 47 % de la incertidumbre. El delta de 0 a 47 es 47.

Luego lo ponemos en relacion con todo el catalogo. Cual es mi delta sobre el catalogo? Eso depende del consumo de esa pieza. Evidentemente, una pieza con mayor consumo tendra un mayor impacto aqui, etc.

Luego, mi ganancia sobre el nivel de servicio global, la reduccion de AOG en dolares. Como llegamos a eso? De nuevo, lo construimos a medida, y no espero que muchas personas de la audiencia, ni siquiera nuestros clientes cuando empezamos con ellos, tengan un numero fijo y digan: “se lo que cuesta un AOG”. Nuestro enfoque siempre es decir: “mejor estar aproximadamente en lo correcto que exactamente equivocado.” En este caso, eso significa que si, es muy dificil precisar: cuanto nos cuesta un AOG?

Normalmente, lo que quieres ver aqui es, por ejemplo, cuantos AOG tuve que estuvieron relacionados con eventos, o en los que un evento de stock fue la causa, y cual es mi estimacion de alto nivel del coste. Tambien podemos ver si tuve que hacer una compra de emergencia, algo asi. Cual es el valor de eso? De esta forma puedo intentar derivar un valor aproximadamente correcto.

De nuevo, el argumento es: mejor tener un numero en dolares que no tener ninguno. Porque si no tienes uno, siempre estas volando un poco a ciegas con niveles de servicio, donde no puedes realmente discutir “deberiamos estar en 99 o en 99,5?” No lo se. Pero en cuanto pones dolares a algo, puedes discutir, y tambien puedes discutir entre departamentos.

Conor Doherty: Si.

Fabian Hoehner: Y tambien puedes cambiarlo con el tiempo. Esta bien. Si un ano despues dices: “de acuerdo, creo que nuestras estimaciones son incorrectas aqui, o en este tipo de flota son correctas, pero en este otro tipo de flota deberia ser mas caro”, no importa. En cuanto cuantificas las cosas, realmente puedes…

Conor Doherty: Das un lenguaje comun para que la gente discuta diferencias de opinion.

Fabian Hoehner: Exactamente. Perfecto. Eso nos lleva, al final, a la reduccion de AOG por dolar gastado, o a la ganancia de nivel de servicio por dolar gastado. Ambas cosas nos llevan a un score que esencialmente indica donde esta mi ruta de inversion mas eficiente. Ahora los llevare solo a la segunda y tercera linea, y luego seguiremos.

La segunda linea muestra, en realidad, la misma pieza. Es el mismo ID, pero no estamos comprando la misma pieza. Esta vez compramos la segunda unidad. La primera ya la compramos, asi que ahora solo podemos invertir en una segunda unidad. Y lo que vamos a ver es que esta nos llevara a… siempre puedes decirme que haga zoom.

Conor Doherty: No, esta bien. Esta bien.

Fabian Hoehner: Me inclino un poco. Asi que nos lleva al 72 % en este caso, lo que significa que obtenemos un 25 % adicional de nivel de servicio. La primera, obviamente, cubre la mayor incertidumbre. Que era, 50 %, y la segunda solo 25.

Cual es la consecuencia logica? La segunda pieza, y esto es bastante obvio, tiene menos valor para nuestra operacion. Por lo tanto, veremos que todos los valores disminuyen. Mi aumento de nivel de servicio es menor, mi coste AOG es menor y, por tanto, mi ranking score es menor.

De acuerdo, no es una revolucion decir que “la segunda pieza vale menos que la primera”. Evidentemente no puedo comprar la segunda antes que la primera. Pero ahora miramos la tercera linea. Misma logica, exactamente lo mismo.

Solo gano 14 % para esa pieza. Sigo pagando 1.200. Asi que mi ranking score bajara. La parte interesante es ahora la cuarta linea, donde vemos simplemente un numero de pieza diferente.

Todo es diferente en esa pieza. Tiene una solicitud de tiempo de entrega diferente. Aqui se ve un TAT subyacente diferente. Potencialmente tiene un tiempo de entrega subyacente diferente.

El precio es diferente. Todo es diferente en esa pieza. Sin embargo, lo que sigue siendo igual es mi logica de ranking: cual es mi reduccion de AOG? Tambien podemos hablar de eso sobre mi inversion.

Ese es el concepto central que vamos a aplicar aqui. Hago un pequeno parentesis. Por supuesto, en realidad vamos mas lejos en complejidad, y tambien en estos calculos anadimos algunos factores sobre no-go, if, etc. En este caso, eso esta incluido en el coste AOG.

Para simplificar, el coste AOG es mayor si tienes una pieza no-go. Eso puede ser extremadamente complicado. Luego tenemos, y esto no es porque seamos genios, el feedback que recibimos de nuestros clientes. Basicamente miras un resultado, y llamamos a esto optimizacion experimental. Muestras una lista a alguien y dices: “esto es lo que haria en tu lugar”, y luego hablas con los expertos, y los expertos dicen: “si, de acuerdo, cinco suena razonable, pero yo habria puesto veinte.”

En ese caso, hay algo que me falta, porque los expertos operativos normalmente saben lo que hacen. Podria ser que estemos mirando una funda de asiento. Podrias decir: “tecnicamente no es una pieza no-go. Se puede volar con ella.”

Pero operaciones te dira: “si, pero se ve horrible”, y el coste de que alguien entre en un avion bonito y vea, por ejemplo, que “tenemos que poner una cinta roja ahi, no podemos…” Si. Eso es un no-go. Asi que eso es extremadamente caro.

Dato curioso: las maquinas de cafe, no-go. No puedes no tener maquinas de cafe. Tecnicamente, si, el avion vuela sin ellas, pero… estas son las cosas que aprendemos juntos y luego adaptamos la receta. Tambien puede variar de una aerolinea a otra. Cuales son las prioridades?

Cuales no? Lo que hacemos aqui es ordenar todo por el ranking score: cual es la ganancia de nivel de servicio por dolar gastado, la evitacion de AOG por dolar gastado, y bajar por esta lista. Pueden ver que disminuye de forma constante. Asi, una pieza que cuesta 46.000 dolares y una pieza que cuesta 5.000 dolares se vuelven comparables, porque la pregunta es simplemente: en que punto tiene sentido comprar el sexto articulo de una pieza barata o el segundo de una pieza cara?

Eso es exactamente lo que hacemos aqui. La siguiente pregunta es: como llegamos a estos valores, o, en realidad, que se ve a nivel operativo? Preguntaste antes que mirarian las operaciones. Mirarian una lista como esta.

Eso seria absolutamente razonable. Pero luego tambien entrarian en lo que aqui llamamos un item inspector. En este caso, y tambien para nosotros, al final es un dashboard KPI, pero explica como llegamos a los valores que vimos antes.

Normalmente, esto podria ser usado por los clientes para investigar ellos mismos, pero tambien por nuestros supply chain scientists. Son las personas que codifican y actuan como sparring partners. Imagino que la mayoria de la gente esta familiarizada con el concepto de supply chain scientists. Si te unes a esta charla, probablemente ya has visto algo de Lokad. En resumen, son las personas que implementan y cuestionan ida y vuelta con el cliente.

Usamos las mismas pantallas de evaluacion que el cliente podria usar para juzgar o evaluar: es razonable la decision que estamos dando? Siempre bajamos desde arriba: “compra cinco”, hasta el por que. Primero vimos un ranking economico, y ahora miramos todos los detalles. Si no estamos de acuerdo, normalmente vendriamos aqui y veriamos: tenemos la misma vision de la realidad? Porque, especialmente al principio de un proyecto, la mayoria de los casos en los que no estamos alineados se deben a… tienes una idea?

Conor Doherty: El valor economico de las decisiones?

Fabian Hoehner: No, datos. Siempre son datos. Basicamente, no estas alineado con la realidad que estas mirando. Nuestros clientes complejos, y las empresas aeronauticas, normalmente han hecho muchas compras. Ver seis sistemas ERP distintos con legado es bastante habitual, y tres Excels por aqui y por alla.

Conseguir simplemente la interpretacion correcta, o la misma interpretacion, de la misma realidad no es facil. Asi que el primer paso es: tenemos la misma mirada sobre la realidad? Vemos las mismas unidades que, en este caso… miremos otra pieza, a ver si encontramos una. Si, tenemos la misma cantidad de unidades que estan ahora en un proceso de retorno, en un proceso de reparacion, en el proceso logistico?

Si, no, tal vez? Eso es bastante importante. Y supongamos que los datos son efectivamente coherentes. Entonces miramos: cual es nuestra proyeccion de demanda?

Como llegamos a eso? Aqui es donde… hablamos de priorizacion economica. Al principio dije que habia dos conceptos principales que queria que la gente se llevara: priorizacion economica. Cubrimos parte de eso. Y dije incertidumbre, prevision probabilistica, y eso es lo que vamos a mirar ahora.

De nuevo, para algunas personas esto sera bastante evidente, pero ire un poco despacio para que todos puedan seguir. Lo que vemos aqui es un historial de consumo extremadamente tipico. Por cierto, seguimos con nuestro favorito, el 1338. De acuerdo. Asi que…

Conor Doherty: La misma pieza en este viaje. De acuerdo.

Fabian Hoehner: Estamos recorriendo el viaje de esta pieza, efectivamente. Lo que vemos es un historial de consumo muy tipico, disperso y erratico. Nada, uno, uno, uno, dos, luego dos, uno. Eso significa que es extremadamente dificil de prever.

Y si lo miraras, y se que en aeronautica muy poca gente haria eso, pero si lo miraras desde una perspectiva de consumo medio tomando una media movil, esto es lo que verias. Te ayuda en algo? En este caso te dice 0,17 unidades. De acuerdo, genial.

Que me aporta eso? Practicamente nada. La vista que quieres tener, y lo que vamos a hacer, es una vista probabilistica que nos dira: cual es la probabilidad de consumo sobre un horizonte dado? Cuando digo sobre un horizonte dado, empecemos simple. Y de nuevo, para todos los que hayan hecho estadistica…

Conor Doherty: Asume que soy idiota. Puedes hablarme con condescendencia. Esta bien.

Fabian Hoehner: Esa sera una suposicion dificil de hacer. Asi que este histograma aqui, empecemos simple, seria o fue una representacion de la realidad. Solo el pasado. En realidad, por supuesto, miramos hacia adelante, hacemos prevision, hacemos cosas super inteligentes, pero por simplicidad digamos que solo miramos el pasado.

Que hace aqui un histograma? Simplemente decimos, no se si… si, creo que se pueden ver las pequenas barras. Supongamos que una periodo que miramos esta entre esas barras. Digamos 30 dias, y ahora digo al azar: si el pasado representa el futuro, y elegimos aleatoriamente un punto ahi.

En ese caso, eso significaria: con que frecuencia encuentro una demanda de uno en una ventana de 30 dias? Con que frecuencia encuentro cero? Con que frecuencia encuentro dos, tres, etc.? Eso es lo que esto dice.

Dice que, aleatoriamente, en el 25 % de los casos encontraremos cero. En el 34 % de los casos encontraremos 1, 2, 3, 4, 5, etc. Ese es el caso teorico, y aqui podemos ver que, si tuviera este intervalo, seria una demanda de tres. Si el intervalo fuera mas grande, incluiria todo eso.

Ahora bien, esa es la teoria simple. La practica, y aqui es donde entramos en lo que dije al principio, apreciar y abrazar la incertidumbre, es: cual es el horizonte sobre el que prever? Porque no son 30 dias. 30 dias significaria un numero fijo, y nosotros insistimos mucho en que la incertidumbre existe y no puedes planificarla fuera de la imagen. Es agradable asumir que siempre son 30 dias para tener un valor determinista y facilitar la planificacion, pero eso no significa que sea mas real. La realidad es que a veces tarda 30 dias, a veces 50, a veces 60, a veces 180, o…

Conor Doherty: no llega en absoluto.

Fabian Hoehner: Exactamente, scrap. Aqui estamos mirando piezas rotable. Las piezas rotable normalmente se reparan. Asi que no estamos mirando tiempos de entrega, sino normalmente turnaround times.

Cuanto tarda mi pieza en volver a ser serviceable? Recibo mi pieza, entra el avion, sale la pieza unserviceable. La reemplazo con una pieza serviceable que tenia en stock, y la pieza unserviceable entra entonces en un largo bucle eterno. Idealmente, tengo los datos para identificar cada estacion de eso y tener muchas pequenas distribuciones, pero lo fundamental para mi es entender: cuales son todos los posibles retrasos a los que podria enfrentarme?

Ese es el horizonte sobre el que quiero hacer la prevision, porque quiero entender los extremos. Si una pieza pudiera repararse en un dia, no necesitarias stock en absoluto, o no necesitarias stock extra. Una unidad seria suficiente. Cada vez que entra un avion, sale una pieza unserviceable, entra una serviceable, se repara la unserviceable: un stock de uno seria suficiente. La realidad obviamente no es esa, pero vemos que determinar este periodo es absolutamente esencial, y eso es exactamente lo que hacemos aqui.

Esto, en este caso, se llama replenishment tiempo de entrega; puede ser un turnaround time, no importa. Bueno, si importa, pero desde la perspectiva del principio, lo que queremos entender es: cual es el horizonte sobre el que hacemos la prevision? Vemos que esta suavizado, obviamente, y vemos que es una distribucion bimodal. Cual podria ser una explicacion? Normalmente, en aeronautica, este pico alrededor de 80 seria que todo va fluido.

Tienes una pieza, la envias al taller de reparacion, se repara, todo perfecto. Y esto representa el hecho de que algo esta roto, necesita arreglarse y lleva tiempo. Esto te da una bonita distribucion bimodal. El mensaje importante aqui es que es una interpretacion muy distinta decir que, en la mayoria de los casos, digamos en el 80 % de los casos, esta alrededor de 80, y en el 20 % de los casos esta en 150, frente a decir que siempre es la media, 110 unidades.

Conor Doherty: lo cual ocurre muy raramente en esa distribucion.

Fabian Hoehner: Si. Evidentemente esto esta suavizado, son datos demo, etc. Pero podria ser un caso muy real que se ve con bastante frecuencia. O todo va fluido, en cuyo caso son 80 dias, o no, y entonces son 120.

No estoy sacando ninguna conclusion aqui. No estoy diciendo: “elige uno de los escenarios.” No. Solo digo que lo que quieres hacer es entender que la incertidumbre existe y hacer prevision sobre todos los futuros posibles que existen. En este caso, dije al principio: “de acuerdo, simplemente tomemos una ventana de 30 dias.” 30 dias. En este caso, es una probabilidad muy pequena, inferior al 1 %. Pero lo esencial es que vamos a construir una distribucion, una distribucion de demanda, sobre todos los horizontes de demanda posibles. Asi que imaginen, si se hace exactamente asi o no no importa para la parte visual, imaginen que ahora tienen cien distribuciones distintas sobre todos los distintos horizontes que existen.

Las tomamos y las condensamos en una sola distribucion, que es esta. Que hace eso? Nos da la demanda sobre todos los futuros posibles. Por que estos ultimos diez minutos?

Porque esto nos da la representacion mas precisa de la demanda sobre un futuro incierto, y eso es increiblemente importante. Cuando hablamos de aeronautica, como dijimos al principio, lo unico que me importa son los extremos. Mis escenarios por encima del percentil 90. En este caso, es extremadamente importante entender donde estoy en esta distribucion. Vamos a hacer clic en algunos ejemplos.

Aqui vamos. Vemos que es muy tipico tener estas distribuciones infladas en cero y sesgadas a la derecha. Eso significa que tienes una cola larga que ves todo el tiempo, y que de hecho no tener demanda sobre el horizonte es a menudo el escenario mas probable. Pero, de nuevo, entender exactamente cuan probables son los outliers es donde esta la importancia. Si esta pieza cuesta 20.000 dolares, la pregunta es: por estos porcentajes extra, digamos estos 7 % extra, aunque no sea exactamente el calculo correcto, queremos invertir otros 40.000 dolares o solo queremos comprar las primeras unidades? Eso es exactamente lo que hicimos antes.

Por eso es absolutamente critico entender la forma de la distribucion. Ese es el primer paso. Y si queremos entrar en mas detalle, o volver a nuestra pieza, recordemos, quizas aqui: si pusieramos una pieza, obtendriamos un nivel de servicio esperado del 47 %. La segunda nos llevaria al 72, luego al 87, y si…

Conor Doherty: es lo que estaba en la lista.

Fabian Hoehner: Muy bien. Tu…

Conor Doherty: Estaba prestando atencion.

Fabian Hoehner: Genial. Si volvemos aqui y miramos de nuevo, veremos que estabamos en 47 para la primera, luego 72, y asi sucesivamente. Esto es basicamente el camino inverso para entender como llegamos alli. Explica como obtuvimos exactamente ese numero. Respiro un segundo, asi que si…

Conor Doherty: Creo que en este punto ya tengo algunas preguntas enviadas, y es un buen momento para pasar a esto, porque una de las cosas que me preguntaron una y otra vez cuando hable con la gente antes de este evento fue: como encaja todo lo que la gente acaba de ver en un workflow preexistente? Porque, obviamente, cualquier empresa, cualquier cliente que tengamos o cualquier futuro cliente potencial, tendra su propio software y sus workflows existentes. Entonces, Lokad… hay que arrancarlo todo para poner esto en marcha? Se coloca al lado? Como funciona?

Fabian Hoehner: Si, seria una pregunta bastante mala si eso fuera cierto.

Conor Doherty: Si, exactamente, obviamente.

Fabian Hoehner: No, nosotros nos colocamos encima. Y voy a mostrar una cosa, literalmente solo durante unos segundos, para mostrar lo que hay en el fondo de esto. Esto es…

Conor Doherty: eso es IA, verdad?

Fabian Hoehner: Si, todo esto es magia. Obviamente, magia negra. No, este es nuestro lenguaje de programacion, llamado Envision.

Al final, Lokad es varias cosas. Por un lado, es una plataforma big data muy potente disenada para la optimizacion de inventario, y efectivamente hay muchas funcionalidades de IA. Por ejemplo, podemos escribir este lenguaje con agentes internos, etc. Pero lo que queria mostrar aqui es… preguntaste por los datos.

Nos adaptamos a todos. No esperamos que nadie pre-disene nada. Solo queremos las extracciones brutas, y una gran parte del trabajo es manipular los datos de nuestro lado, hacerlos correctos, o hacer correcta la manipulacion de los datos para que tengan sentido. Es decir, coherencia de datos.

Por ejemplo, para darte un ejemplo, el valor razonable de una pieza es algo bastante complejo de conseguir. En aeronautica, tienes muchas piezas que llevan mucho tiempo ahi. Puedes amortizar una pieza durante ocho anos y entonces el valor contable de esa pieza sera un dolar. Pero la pieza sigue pudiendo reemplazarse, y la nueva compra cuesta, no se, 50.000 dolares. Entonces, cual es el valor correcto que debes asumir? Cual es el fair value de la pieza?

No es una respuesta facil. Tienes dos sistemas diferentes. El sistema contable dice que es un dolar, porque dejas un dolar contable ahi. Y si quieres volver a comprarla, son 50.000.

Como consigues que los datos sobre eso sean correctos? Eso toma tiempo, requiere discusion y, desde nuestra perspectiva, sobre todo requiere flexibilidad. Por eso tenemos, por muchas razones, pero en el fondo por eso tenemos un lenguaje de programacion para adaptarnos a eso. Todos nuestros clientes tienen configuraciones muy distintas, y simplemente nos colocamos encima.

Ya tengan AMOS, TRAX, SAP, y la mayoria de las veces una mezcla de todo, eso es parte del sistema de inteligencia. Lo construimos. Responde eso a la pregunta?

Conor Doherty: Si, mas o menos, porque la razon por la que preguntaba era que estoy parafraseando la pregunta. La preocupacion era mas evitar transacciones duplicadas, porque si tienes multiples sistemas, tengo que reconciliar entre el sistema A y Lokad, y viceversa? Ese era basicamente el sentido de fondo de la pregunta.

Fabian Hoehner: Si. Si preguntas si hay duplicacion de funciones, creo que debemos retroceder un paso. Tienes tus sistemas transaccionales, que estan para las transacciones. Entonces…

Conor Doherty: ERP.

Fabian Hoehner: Si. ERP, M… Basicamente, saco una unidad del stock y la instalo. Eso es algo que quieres ver en milisegundos. Todo debe actualizarse en todas partes.

Eso no es Lokad. Nosotros ejecutamos simulaciones complejas que pueden tardar 20 minutos. Esta bien. Aqui ves que esta pre-calculado.

No tarda practicamente nada porque lo hemos pre-calculado. Este probablemente fluiria en unos segundos, pero lo mas complicado podria tardar mas, y eso esta bien, porque ese no es nuestro trabajo transaccional. Nuestro trabajo es inteligencia: proporcionar los mejores insights, el mejor apoyo a la decision, las mejores decisiones automatizadas, y luego devolverlas a los sistemas automatizados. Para llegar ahi, tenemos bastantes dashboards de insight.

Un sistema de informes. Sistema de registros, luego encima normalmente un sistema de informes: Tableau, cual es el otro? Da igual. Power BI, este tipo de cosas, y luego el sistema de inteligencia es la clase en la que estamos nosotros.

Para hacer eso, si, por supuesto. Una vez que tengo los datos, construimos muchos dashboards que dan una explicacion. Por ejemplo, estos dashboards de investigacion que miramos aqui tambien son, obviamente, un sistema de informes. Este dashboard es simplemente un informe. Quiero decir, el calculo ocurre en otra parte. Pero, para responder a tu pregunta, duplicamos cosas? Si, puede que dupliques algunas cosas, pero globalmente nuestra ambicion no es convertirnos en un sistema de informes. Eso es solo para nosotros internamente y tambien para que los clientes validen lo que hacemos, porque no queremos mirar solo codigo. Quieres ver que hace.

Conor Doherty: De acuerdo. Hablando de lo que hace, cuando hablamos al principio, dije que mirariamos decisiones de inversion y desinversion. Me di cuenta de que nos hemos centrado mucho en las decisiones de inversion.

Podrias mostrarnos algo del estilo: “tengo demasiado”? De nuevo, estabamos hablando de rotables. “Tengo demasiado stock. Como puedo identificar unidades de las que probablemente deberia desprenderme para liberar capital?”

Fabian Hoehner: Si. Como si hubieras sabido que tengo eso por ahi. Brillante.

Si. Basicamente, en este caso, de nuevo, el dashboard esta disenado como queramos. Es un dashboard de demostracion. Es simplemente una eleccion que hicimos aqui.

En este caso, tenemos oportunidades de desinversion e inversion en el mismo dashboard general. Y en este caso, lo que estamos mirando son efectivamente oportunidades de desinversion. Al final, la desinversion es casi lo mismo que la inversion, pero cuando miramos una inversion, tomamos el stock actual que tenemos y nos preguntamos: que pasaria si anadiera una unidad mas, y otra, y una tercera, y una cuarta, y asi sucesivamente, de cada posibilidad de stock? Luego construimos nuestro score de ranking.

Lo que hacemos aqui para una oportunidad de desinversion es mirar todo el stock que poseemos y hacer lo mismo. Nos preguntamos: si desinvirtiera una unidad de stock que poseo, cuanto nivel de servicio pierdo y cuanto efectivo libero? Esa es esencialmente la misma logica, y no voy a recorrerla toda, pero basicamente, lo que quieres ver en una lista asi son articulos con un precio unitario alto, y quieres ver una perdida baja de nivel de servicio. En este caso, podemos ver que perdemos menos de un por ciento en esa pieza.

Y si miramos la perdida total, esta redondeada. Ni siquiera podemos verla. Obviamente, hay algunas piezas de las que simplemente tienes demasiado. Luego ves el aumento de AOG que resulta de eso, y despues el ranking.

Probablemente deberiamos anadir algunos ceros para que se pudiera ver. Pero si bajamos, puedes ver que va a aumentar. En resumen, la sensacion que deberias tener aqui es precio unitario alto, baja perdida de nivel de servicio, y esa es la logica invertida. Y luego, en teoria, incluso puedes encontrar un punto ideal entre ambos y decir: “de acuerdo, quiero invertir en todos estos y desinvertir hasta llegar a un punto optimo.”

Eso es mas bien teorico, porque la realidad es mas compleja en cuanto a cuales son los valores justos de mercado. Asi que, de nuevo, esto no es Amazon, donde sales y dices: “oh, tengo 10 unidades de mas de una pieza que cuesta 85.000 dolares, vendido.” No, tienes que venderlas. Tienes que encontrar a alguien, hacer una transferencia de ubicacion, etc.

Pero estos son efectivamente dashboards muy valiosos para que los clientes desinviertan activos y luego puedan decir: “de acuerdo, si, esto tiene sentido. Tenemos al menos cinco aqui que, basicamente, solo sirven para un evento de cola muy, muy larga.” Realmente, si toda nuestra flota tiene un problema el mismo dia, ahi seria necesario. Esa es la idea general de la desinversion.

Conor Doherty: Si. Para mi, de nuevo, al diferenciar como asignariamos presupuesto dependiendo de, perdon, como generariamos decisiones basadas en decisiones de inversion o desinversion y como difieren ligeramente. Una pregunta de seguimiento enviada con antelacion. Una persona de compras operativas queria saber: “como deberia cambiar, o como cambia, una recomendacion de compra dependiendo de si la unidad se adquiere para intercambio o para compra directa?”

Fabian Hoehner: Depende. La respuesta siempre es…

Conor Doherty: Estas preguntas requieren bastante tiempo, asi que te pido respuestas concisas. Soy consciente de que, si no entramos en todos los detalles, podemos hacer seguimiento y no pasa nada.

Fabian Hoehner: Si, por supuesto.

Conor Doherty: Pero una respuesta general.

Fabian Hoehner: Si. Entonces, la pregunta aqui seria: en este caso, normalmente miramos el pool que posees. Cual es el nivel de stock total que tengo? Estas son todas las inversiones que van a aumentar tu nivel global de pool.

Si es solo para un intercambio, entonces el numero del pool normalmente no cambia, porque lo intercambias y lo devuelves en un cierto momento. Asi que ahi la pregunta seria mas de evaluacion. Podrias hacerlo porque tienes demasiadas en un… En teoria tienes suficientes piezas, pero todas estan atrapadas en un bucle de reparacion. No necesitas realmente mas stock, pero necesitas cubrir un periodo hasta que vuelvan. Eso seria esencialmente una optimizacion diferente.

Lo que estamos mirando aqui son inversiones que entran en el pool. Eso tambien entraria en la priorizacion de reparaciones. Al final, la pregunta subyacente seria: si tengo una cantidad dada de piezas en mi proceso de reparacion, cuales de esas piezas deberia priorizar para reparar? A veces puedes cambiarlo, pero cada empresa tiene, si vamos a la vista general, vimos que actualmente tenemos 500 unidades pasando por un proceso de reparacion. No todas son igual de importantes.

Y lo que podriamos hacer aqui, y lo hacemos basicamente con una lista priorizada en la que decimos: de acuerdo, estas deberian ser… Luego tenemos acciones de expedite, donde puedes ver basicamente cuales son las prioridades y si podrias acortar los tiempos de entrega, porque para el proveedor no importa. Tiene 20 de tus piezas, las esta reparando todas y no sabe cuales son importantes para ti. Pero nosotros decimos: “aun tenemos cinco serviceable disponibles, y solo porque la enviamos antes no necesitamos recuperarla antes.” Esto podria ser algo muy tipico cuando hablo de priorizacion. De nuevo, cual tiene el impacto mas importante para nosotros? Asi que, si, al final son simplemente listas de que hacemos para obtener el mayor impacto.

Conor Doherty: De acuerdo. Puedo seguir? Estas bien? Perfecto.

Como mencionaste a los proveedores, eso lleva a otra pregunta clave y concreta que se hizo. La tengo escrita aqui. Viene de alguien que ha visto anteriormente a proveedores negarse a unirse a una nueva plataforma por los costes de onboarding o las cuotas de suscripcion. Esencialmente: “los proveedores necesitan cambiar la forma en que trabajan con el cliente para que Lokad pueda hacer todo esto o generar valor?”

Fabian Hoehner: Proveedores en que sentido, los proveedores de los clientes?

Conor Doherty: Si. Si. Entonces…

Fabian Hoehner: No, normalmente, ellos son… Quiero decir, necesitamos los datos de los proveedores? La respuesta corta: no. Solo necesitamos los datos del cliente, porque ellos tienen todos los datos.

Podemos? Si, en realidad integramos algunos proveedores adicionalmente, normalmente para timestamps. Entonces, tu eres el MRO, tu reparas. Yo soy la aerolinea.

Yo simplemente envio mis datos a Lokad, y lo unico que se es que envio la pieza y se cuando vuelve. Si tengo tus datos de que “actualmente esta en un proceso de reparacion, actualmente esta en la frontera, o lo que sea, ha sido inspeccionada”, si tengo esos datos, y tenemos algunos clientes con buena relacion con nuestros clientes, podria ser tan sencillo como una hoja Excel que se sube a Lokad de forma regular, entonces podemos actualizar mejor esos puntos de datos.

Entonces, para responder a tu pregunta, si estoy integrado con mi proveedor y tengo los datos en mi sistema ERP, en ese caso simplemente extraigo los datos del ERP, esta bien. Hecho. Pero somos muy flexibles, y probablemente esa es la ventaja que tenemos para integrarnos con un proveedor tercero. De nuevo, somos una empresa de IT.

Para nosotros probablemente es mucho mas facil integrarnos con un tercero, con cualquier tipo de flujo de datos, que para una gran organizacion meter datos de terceros en un sistema ERP. Eso es un proyecto de transicion. Para nosotros, son un par de dias. Esa es probablemente la gran diferencia.

Conor Doherty: De acuerdo. Pero en conclusion, de nuevo, hay al menos dos categorias de datos. Estan los nice-to-have y luego estan los must-have.

Y tener los datos de proveedor que acabas de describir es nice-to-have. Esencialmente, es agradable tenerlos. Ayuda, pero no es un dealbreaker.

Fabian Hoehner: Si, absolutamente. Solo para ser claro, si, buen punto.

Conor Doherty: Quiero ser concreto, verdad?

Fabian Hoehner: Si. La pregunta de los datos siempre es buena. Que tipo de datos necesitamos?

Basicamente, en aeronautica tienes que rastrearlo todo. Asi que hay suficientes datos. La pregunta es: “tenemos suficientes?” Si, los tienes.

La pregunta es: son bonitos? Estan limpios? No, nunca. Pero hay datos suficientes, y luego empieza el trabajo de conseguir la misma interpretacion de los datos.

Los datos son solo datos, pero como los interpretas? Esa es la pregunta. Si, el historial de consumo es obviamente importante. Niveles de stock, catalogo, si, todo, pero tambien los estandares.

Y luego hay muchos datos nice-to-have. Niveles historicos de stock por ubicacion, cosas asi. Y, obviamente, timestamps de proveedor, que son super dificiles. Normalmente no los ves.

Solo ves el turnaround time como dos valores: salida y entrada, y eso es todo. Si tienes los timestamps intermedios, eso es realmente potente, pero si no los tienes, entonces solo tienes una distribucion amplia de esos valores. De lo contrario, tienes varias distribuciones.

Conor Doherty: Comentaste antes, con respecto a datos potencialmente desordenados, que “entonces empieza el trabajo.” Pero para aclarar, y esto tambien se pregunto en cuanto a preparacion de datos, que se requiere de los clientes? Y esto conecta, supongo, con lo que dijiste antes sobre el supply chain scientist.

Fabian Hoehner: Si. Normalmente, nuestra actitud es hacerlo juntos, porque, de nuevo, para eso estamos disenados. Somos una plataforma de big data.

Somos rapidos en eso. Normalmente somos mucho mas rapidos que nuestros clientes incluso preparando los datos. Solo necesitamos extracciones brutas. Dicho esto, obviamente, tener personas familiarizadas con los datos, que sepan donde estan los datos, es importante, aporta valor y acelera un proyecto.

No voy a decir que no sea excelente tener personas que ya hayan mirado los datos y sepan lo que significan. Pero, por lo demas, nuestro enfoque es ir al nivel de decision. Esa es la belleza. Si te digo, de nuevo, “compra cuatro piezas, haz esto”, los problemas subyacentes se vuelven bastante obvios. Hacer una mision de limpieza de datos…

Basicamente, he visto muchas empresas que dicen: “no estamos listos. Queremos limpiar nuestros datos primero.” Y luego hablas con ellas dos anos despues, y la respuesta es: “seguimos limpiando nuestros datos”, porque es increiblemente dificil saber por donde empezar. Siempre hay datos desordenados, una categorizacion incorrecta, jerarquias de productos. Si.

Si. De acuerdo, bien. Para nosotros, seria bueno tener una mejor categorizacion. El mapeo de intercambiabilidad, obviamente, las intercambiabilidades en aeronautica, de una via, de dos vias, son super importantes.

Asi que si, no esta limpio. Seria mucho mejor tenerlo limpio? Si, absolutamente. Pero al ir hasta la decision, tambien veras de forma muy obvia donde hay datos que tienen valor?

Si, porque digamos, intercambiabilidad: una pieza nueva, puedo usarla en un equipo antiguo o no? Si, o… Eso se vuelve bastante obvio si doy una recomendacion equivocada. Obviamente, si tengo una pieza compatible en ambos sentidos, quiero tenerla de forma mas agresiva. Eso es interesante.

Entonces, si mi recomendacion es muy equivocada para un usuario, digo “cinco”, y el usuario dice: “oye, por que? Ya no necesitamos la pieza antigua. La nueva puede reparar la antigua y la nueva, asi que queremos 20.” En ese caso, al mirar el inspector, etc., llegamos muy rapido a la conclusion: “ah, si, no sabiamos que esta pieza funcionaba para estos dos escenarios de demanda.”

Por que? Porque no teniamos los datos correctos. Y entonces sabes: “si, estos son datos que vale la pena corregir”, porque estamos mirando puntos de datos que realmente nos ayudan. Mientras que si limpias solo por limpiar, nunca vas a llegar a ninguna parte y nunca vas a dejar de limpiar.

Conor Doherty: Bien.

Fabian Hoehner: De que te ries?

Conor Doherty: Alguien nos felicita… Alex acaba de referirse a si mismo como listo. Es bastante listo. Es un chico listo. Si.

Asi que, de nuevo, una de las preguntas, y he fusionado varias versiones de esta pregunta en una version general, pero se refiere esencialmente a la implementacion. En concreto, esfuerzos de integracion, requisitos de datos, ya has tocado los requisitos de datos, pero esfuerzos de integracion, requisitos de datos, seguridad, soporte, escalabilidad en una gran base de proveedores, ingenieria, comentarios sobre eso, requisitos de calendario, etc. Entiendo que depende de cada caso, cuanto mide un trozo de cuerda? Lo entiendo, pero seria una respuesta general para las personas que estan viendo y podrian estar interesadas.

Fabian Hoehner: Seis meses.

Conor Doherty: De acuerdo. Aproximadamente, puede ser mas rapido, puede ser mas largo.

Fabian Hoehner: Si. Y si. De acuerdo.

Entonces, normalmente, depende de todo, pero dos meses para obtener los datos y conseguir una comprension aproximada de lo que estas mirando, es decir, salud de datos de alto y bajo nivel, donde simplemente tienes la misma interpretacion de los datos. Dos meses para una optimizacion aproximada. En realidad somos bastante rapidos en eso, y luego otros dos meses para ajustar, pero tambien correr en paralelo, porque la forma en que operamos es, de nuevo, que todos ya estan haciendo lo que hacemos aqui.

Las empresas con las que trabajamos ya toman decisiones diariamente sobre “que deberia comprar? En que deberia invertir?” Asi que, basicamente, lo ejecutas en paralelo a sus procesos, y ahi es donde obtienes mejora. Eso me lleva, de hecho, a una pequena funcionalidad en terminos de historico: como comparas con el pasado, o como evaluas?

Una funcionalidad que me gusta destacar es que, en la plataforma, somos completamente compatibles con evaluar el pasado. Que quiero decir con eso? Si miramos el historial, puedo ver todas las ejecuciones pasadas que tengo. Por ejemplo, puedo ver literalmente lo que hice hoy.

Puedo mirar el dashboard que ejecute hace unas horas. Y lo que puedo hacer aqui, y lo que puedes ver que hice, es que asumi que me preguntarias sobre presupuesto. Asi que, en este caso, puse el presupuesto en, perdon, 1 millon en lugar de 10 millones. Y ahora, si volvemos a nuestro 98 %, antes, cual era la inversion, recuerdas?

Conor Doherty: 1,2… 2 millones.

Fabian Hoehner: Muy bien. Entonces, lo que estamos haciendo aqui ahora es que solo llegamos a 900.000, porque ahora puse una limitacion de 1 millon. Y podemos jugar con este dashboard. Puedo ejecutarlo.

Puedo hacerlo con cualquier dashboard que haya tenido en el pasado. Puedo decirte que la mayoria de la gente no piensa que esta sea una funcionalidad muy importante, pero en realidad es increiblemente valiosa, especialmente si quieres volver en el tiempo a cualquier momento y ver que hicimos. Muchas veces, cuando tienes una situacion AOG, las empresas, no quiero decir que entren en panico, pero entran en modo investigacion para decir: “como ocurrio? Que hicimos mal?”

Y en ese caso, se vuelve increiblemente dificil, quiero decir, estamos hablando de tiempos de entrega de seis meses para una pieza, y se vuelve increiblemente dificil cuestionar tu sistema y lo que haces si no eres capaz de situarte en el punto en el que estabas en enero de 2026. Pero en ese caso puedo entrar en mi simulacion de 2026, y potencialmente vere que “si, queriamos conseguir una tercera unidad de esta. Era interesante comprarla. Sin embargo, estabamos limitados y solo teniamos un presupuesto de, no se, 10 millones, y por eso no la compramos.”

Pero entonces lo sabemos. La consecuencia seria: “si, deberiamos aumentar nuestros presupuestos y tener mas dinero disponible.” O la consecuencia tambien podria ser: “en realidad, si, no priorizamos eso correctamente.” Deberiamos haber dado una penalizacion mas alta por estar sin stock, y entonces la consecuencia es que cambiamos el algoritmo. Eso es absolutamente crucial. Pasas de una investigacion, diria, algo inutil, a cuestionar el sistema subyacente, y la consecuencia es que entonces dices: “el algoritmo hizo lo que se suponia que debia hacer y esta bien.”

Si. A veces tienes eventos extremos y tienes roturas de stock. Aqui decimos que vamos al 98 %. Eso significa que en el 2 % tendremos roturas de stock.

Eso es simplemente estadistica. Pero tambien podrias decir: “mira mas alla de eso. Deberiamos cambiar el algoritmo para que en el futuro sea mejor”, pero eso es un proceso continuo. La optimizacion es un proceso continuo.

Es un flujo continuo en el que intentas aspirar a la perfeccion, que por definicion nunca alcanzas. Por eso, tener algo que te permita mirar el historico, y ejecutar datos nuevos sobre codigo antiguo, es importante. Puedo tomar los calculos, la ponderacion, la penalizacion que damos a una pieza de cara al cliente, etc.

Puedo ejecutar datos de hoy con un codigo o algoritmo de hace seis meses, o viceversa, tomar datos antiguos y decir: “de acuerdo, que haria si los pusiera en el optimizador de hoy?” Y, de nuevo, muy poca gente preguntara por eso, pero es una funcionalidad extremadamente potente, creada inicialmente para corregir bugs, porque eso es importante. Si los datos cambian de un dia para otro, puede que ya no tengas el bug, y eso es terrible porque sabes que hay algo, pero no puedes localizarlo. En fin, me desvio.

Conor Doherty: De acuerdo, no te desvies. Es bueno tener la informacion concreta en el registro. Tenemos algunas preguntas mas.

Estas listo para continuar? Seguimos. Perfecto.

Fabian Hoehner: No, perdon.

Conor Doherty: Muy bien. Esta, de nuevo, no es explicitamente sobre compras. Es mas bien sobre otra opcionalidad.

Esencialmente: genial. “Puede Lokad decidir si deberiamos comprar otra unidad o mover una unidad existente entre ubicaciones?” Nos estamos alejando un poco del tema de hoy. No vamos a abrir otro dashboard, pero una respuesta de alto nivel?

Fabian Hoehner: Si. Entonces…

Conor Doherty: Si. Siguiente pregunta.

Fabian Hoehner: De acuerdo. Hecho. No.

Aqui es donde entra la priorizacion economica. Al final, y probablemente esto va a ser muy aburrido, mi respuesta siempre sera: “si es logica, podemos hacerlo.” Cual es la logica que deberiamos aplicar aqui? La pregunta es simplemente que primero quieres simular: cual es la probabilidad de necesidad?

En este caso, para un problema de asignacion, primero necesitas simular la demanda por ubicacion. Por ejemplo, tienes MBK en 100 estaciones externas; tienes que hacerlo. Obviamente es dificil. Es mas dificil prever cuando es aun mas esparso, pero tienes que hacerlo. Siempre decimos: “no es la facilidad del calculo lo que decide el nivel de simulacion, sino la decision que quieres tomar.”

Entonces, si quiero simular la necesidad de una pieza por ubicacion, necesito prever a nivel de ubicacion. Ahora, para responder a la pregunta: que debemos hacer? Necesitamos comprar mas para el stock central o necesitamos reasignar? Al final es una cuestion economica.

Es simplemente la pregunta de cual es el coste de mover la pieza en relacion con… Mueves la pieza. Eso significa que expones a mas riesgo la estacion de la que estas moviendo la pieza, y entonces riesgo incrementado mas coste logistico frente a coste de inversion externa. Ese es el coste de capital. Si, al final es bastante logico y calculable.

Si, y para nosotros la conclusion siempre es que podemos hacerlo al euro, dolar, libra, lo que sea. Pero la pregunta siempre es: que tan grande es el problema y con que frecuencia aparece? Tambien puedes resolverlo con una simple regla de tres. Pero si es una pregunta relevante y de alto valor, entonces podemos ir exactamente a ese nivel.

Conor Doherty: De acuerdo. Algunas…

Fabian Hoehner: Dime si no esta claro.

Conor Doherty: No, no, no. Perfectamente claro. Tambien soy consciente de que hay otras preguntas por cubrir, y no quiero ralentizar. De nuevo, cualquier cosa que no este clara, ya he recibido algunos mensajes de personas diciendo que quieren hacer seguimiento, porque esto llevaria demasiado tiempo: “de acuerdo, que pasa con esta situacion? y esta situacion?”

Fabian Hoehner: Solo para ser claro, no quiero… Mi punto es que queria asegurarme de que entendieramos esos dos principios: incertidumbre, es decir, diferentes incertidumbres, turnaround time y demanda mezcladas, nos dan una vision de la incertidumbre, y priorizacion economica. Con eso, podemos responder practicamente al 95 % de todas las preguntas subyacentes. Sea lo que preguntaste al principio, consumibles y expendables. Ahora hemos hablado del bucle.

De acuerdo, el bucle es mas complicado, pero al final C&E es lo mismo. Es simplemente stock que entra y sale, asi que es 100 % scrap, si quieres decirlo asi. Y el principio subyacente es algo parecido. Puedes hacer exactamente la misma optimizacion economica.

Puedes hacerlo, pero no tienes que hacerlo. Si el problema subyacente es simple, tambien puedes resolverlo de forma mas simple. No tenemos que hacerlo con ese tipo de optimizacion. Pero esa seria normalmente la recomendacion fuerte. De nuevo, si solo tenemos que hacer algo rapido y sucio, siempre podemos empezar rapido y sucio para tener algo mejor que lo existente y automatizado, porque lo automatizado casi siempre gana al humano.

Y luego pasar a la segunda etapa. Si, tengo muchisimos otros dashboards, pero no quiero entrar en ellos. Simplemente, asignacion: si, por supuesto puedes tener un dashboard que te diga “necesitas asignar desde una ubicacion a otra.” De acuerdo, genial. De nuevo, no quiero entrar en las matematicas aqui.

Conor Doherty: Si, eso sera tema de un seguimiento. Va a enturbiar el agua.

Fabian Hoehner: Las cosas de alto nivel que queria senalar, pero si, tenemos, diria que siempre depende de que defines como modulo. Son los distintos tiempos de entrega sobre turnaround times escalando un modulo? Depende. O es simplemente compras dentro del modulo? Pero puedes decir que tenemos 20 modulos diferentes, asi que aqui se ven algunas ideas.

Conor Doherty: Si. De hecho, sobre esa nota, otra vez, quizas alguien se perdio una seccion anterior, pero es una pregunta en vivo, asi que la haremos. Es de Saddaf, espero pronunciarlo correctamente. “Puedes comentar un poco mas como Lokad maneja los retrasos de proveedores al calcular la cantidad optima de compra?”

Fabian Hoehner: Si. Quiero decir…

Conor Doherty: Puedes mostrar de nuevo si quieres volver al dashboard, por si alguien se lo perdio antes.

Fabian Hoehner: Si, claro. La pregunta es: que es un retraso frente a algo que simplemente necesitas apreciar? Un retraso significa que tienes un valor esperado y ahora esta tardando mas. Asi que hay dos respuestas a eso.

Una seria la accion de expedite. Basicamente, asumiste que tardaria 30 dias y ahora estas en el dia 40. En ese caso, lo que normalmente proporcionamos es una lista priorizada de a quien llamar primero. Porque, de nuevo, si tengo una pieza con 10 dias de retraso pero tengo cinco serviceable disponibles, no me importa que este retrasada.

Realmente no es importante para mi. Por otro lado, si tengo una que ni siquiera esta retrasada, estamos en el dia 25, pero estoy sin stock y se que es super urgente, probablemente quiero coger el telefono y decirles: “oye, puedes realmente hacer lo que sea para que entre la pieza?” Esa es la mitad de la respuesta sobre como tratamos los retrasos. La pregunta es: puedes hacer algo?

Y luego dar a los usuarios la posibilidad de priorizar, verdad? Y esto siempre es: cual es el impacto de que algo vaya mal? Esa es la primera mitad de la respuesta. Y la segunda mitad es lo que hemos mirado aqui…

Conor Doherty: Cual es la definicion de retrasado?

Fabian Hoehner: Si. Al final, mas bien diriamos que simplemente hay distintos tiempos de entrega. Si, esta bien que en algun contrato diga “60 dias”. Si en realidad siempre tarda 120, lo que quieres hacer es apreciarlo en tu recomendacion de compra.

Eso es exactamente lo que hicimos aqui. No dices “siempre son 80” o “siempre son 120”, no importa, distintos numeros aqui. Dices “hay todas estas posibilidades”, y luego, de nuevo, la distribucion de demanda que vemos aqui es una distribucion de demanda sobre todos los posibles tiempos de entrega. Por eso hacemos todo esto.

Para abrazar la incertidumbre que es incontrolable, y ahi los turnaround times y los tiempos de entrega de proveedores son una parte importante. Y, para ser muy claro, no entramos en ello, pero esto tambien se preve. Siempre hable de forma simplificada: basicamente decimos que miramos el pasado y el pasado representa el futuro.

Obviamente somos conscientes de que el pasado no siempre representa el futuro. Estuvimos durante el COVID con nuestros clientes y despues del COVID, asi que vimos la caida, luego la recuperacion, y aumentos increibles en turnaround times. Tambien podriamos ver, si un turnaround time fuera en esta direccion, que no diriamos “el pasado representa el futuro”. No.

Obviamente, entonces preveemos turnaround times y luego preveemos demanda sobre distribuciones previstas de turnaround time. Y anticipo una pregunta mas. De nuevo, dije que estamos mirando el ultimo ano. Obviamente podemos mirar checks que vienen. Entonces si tengo un… Si, adelante si tienes una pregunta.

Conor Doherty: No, no, eso en realidad va a ser parte de una posterior. Asi que por favor continua.

Fabian Hoehner: De acuerdo, entonces la pregunta tipica seria: como prevees la demanda futura? Simplemente miras el pasado? Depende. Si tienes una operacion de mil aviones y, por tanto, un gran MRO, y tienes mucha masa estadistica, entonces mirar el pasado es en realidad una representacion bastante buena del futuro.

Sin embargo, si tienes mas informacion, y esa es siempre la pregunta, cual es el nivel de informacion que tienes? Por ejemplo, sabes que tienes tu serie de D-checks entrando. Entonces, por supuesto, vamos a tomar la BOM probabilistica, el bill of materials, que en si mismo es incierto, en teoria. Algunas piezas sabes que las vas a reemplazar, entonces tienes una probabilidad del 100 % de reemplazar una pieza consumible. Pero otras solo sabes que vas a abrir…

Conor Doherty: y entonces ves corrosion y no la esperabas.

Fabian Hoehner: Si. O sabes que, basandote en C-checks pasados, reemplazas la pieza en el 30 % de los casos. Eso es un bill of materials probabilistico donde dices: “estas son las 100 piezas que voy a necesitar con sus probabilidades.” Y si se que este evento va a ocurrir en dos meses, entonces puedo planificarlo.

Eso es exactamente lo que hacemos. Ahora bien, la realidad es, por supuesto, mas complicada porque cuando dices “tenemos un C-check en dos meses”, cuantas veces sera realmente en dos meses? Tambien hay incertidumbre ahi. Asi que, de nuevo, cuando digo que he introducido dos incertidumbres principales, en realidad podemos tener aun mas, y eso siempre va a aumentar mi incertidumbre, aumentar las distribuciones, pero al final se reduce a la misma pregunta: cuanta cobertura obtengo si invierto en una pieza mas, y vale la pena? Estoy dispuesto a gastar, no se cuanto cuesta esta, 10.000 dolares para conseguir otro, que es, 0 coma, u otro 4 %, o lo que sea?

Conor Doherty: Claro para mi. De nuevo, tambien es bueno senalarlo: por eso tener los dashboards aqui es tan critico. Una pregunta de seguimiento, es de Metan, perdon si lo pronuncio mal. Trata sobre un punto muy clave que ya se habia planteado, que es que generar, digamos, el mejor conjunto de decisiones de inversion, desinversion o asignacion es increible, pero si hay falta de adherencia, es decir, si la gente simplemente no ejecuta, eso es un problema.

Entonces esta pregunta es: como sabes realmente, esta es una pregunta publica, “como sabes realmente si la empresa, digamos un cliente, compro de verdad la pieza sugerida?” Basicamente hablabas de trazabilidad antes. Podemos rastrear que “X porcentaje de las veces se siguieron estas decisiones?”

Fabian Hoehner: Ah, de acuerdo. Si. Entonces…

Conor Doherty: Auditoria simple, auditabilidad, perdon.

Fabian Hoehner: Como rastrearias eso, Conor?

Conor Doherty: Con un ordenador.

Fabian Hoehner: Si. De acuerdo. Genial. En resumen, vemos la ejecucion. Si recibo diariamente los historiales de transacciones de todo.

Eso incluye la compra. Literalmente veo si alguien siguio mi recomendacion. Obviamente estoy simplificando mucho aqui, pero digamos que el lunes recomende cinco. El run paso el domingo por la noche. El lunes por la manana, el operador ve: “de acuerdo, cinco recomendadas.”

Y luego, en el run del martes, veo cinco. Entonces puedo decir: “tengo 100 % de adherencia.” Estoy simplificando mucho, y en realidad es mas complicado que eso, porque puedes tener, obviamente en este tipo de preguntas, largos retrasos antes de hacer una propuesta y demas. Pero, en resumen, si, hacemos seguimiento de eso, y para algo automatizado, si hablamos de consumibles, puedes rastrearlo muy bien.

Ahi es mucho mas facil. Tienes pura masa. Eso es mas facil. Aqui, en todo el lado rotable del que hemos hablado, yo diria que el feedback humano es probablemente lo mas importante. Literalmente, estas listas las miramos con nuestros clientes, y de nuevo, somos muy buenos en matematicas, estadistica, pero cuando digo nosotros, quiero decir…

Conor Doherty: si, eres un genio absoluto.

Fabian Hoehner: No, quiero decir, es una plataforma muy fuerte, y tenemos ingenieros inteligentes, y esa es nuestra expertise. Llevamos en los sectores aeronauticos unos 13 anos. Hemos construido bastante expertise, pero nunca afirmamos conocer la aeronautica mejor que nuestros clientes. Cuando llega un retrofit? De nuevo, cuando estamos con empresas aeronauticas, estas son personas muy apasionadas. Cuando ven un avion, saben inmediatamente que avion es, cuales son las piezas que hay dentro, etc. Nosotros somos mas el lado estadistico.

Que significa eso? Siempre dependemos mucho de la expertise y del feedback de los usuarios, y tambien disenamos los dashboards al 100 % para ellos. Si nos dicen: “si, quiero que esto se vea diferente. Quiero colores diferentes. Quiero lo que sea.”

Si, escuchamos y lo disenamos para ese proposito. Reconstruirlo, redisenarlo, es medio dia para nosotros. Ni siquiera. Si quieres, puedo hablar de IA, pero ese es otro tema.

Conor Doherty: No, seguire adelante. Esto es mas bien un comentario. Perdon, espera. Si.

Basicamente trata sobre cuanto del proceso manual de compras puede realmente eliminarse si se trabaja con Lokad, porque no quiero tergiversarlo. Tocaste esto antes cuando hablaste de rotables. De nuevo, dependiendo del precio que pagues, obviamente seguiras teniendo un experto en el loop para validar una compra de 90.000 dolares, pero cuanto de ese proceso puede realmente… cuanto del tiempo invertido en ese proceso puede liberarse? Y la misma pregunta cuando hablamos de C&E.

Fabian Hoehner: Si, voy a retomar mi respuesta anterior.

Conor Doherty: Si, solo estoy leyendo.

Fabian Hoehner: Si. No, claro. Pero depende de la complejidad de lo que haces. Y diria que C&E se puede automatizar realmente en un grado muy alto.

Y cuando digo eso, quiero decir mas alla… Si, se que mucho ya esta automatizado con los puntos de reorder. Tenemos min-max. Podemos automatizar eso, pero con un sistema mucho mas inteligente. Algo asi podria potencialmente, por ejemplo, resetear puntos de reorder, si queremos, diariamente, para que ejecute la decision que queremos.

Lo hacemos para algunos clientes. Y diria que tambien hay enormes ahorros de tiempo en eso. Pero cuando, de nuevo, compras piezas por millones de dolares, diria que en ese punto se trata menos del ahorro de tiempo, que definitivamente existe y es bastante grande, y mas de ser mejores. Ese es realmente el juego. Evitas unos cuantos AOG, y entonces los costes se vuelven irrelevantes, hasta cierto punto.

Conor Doherty: Creo que he cubierto, porque ya son las 5:45. Llevamos unos 75 minutos. Se que habia una salida fija alrededor de las seis, asi que creo… ah no, hay una ultima, perdon, hay una ultima pregunta. Creo que cualquiera que haya visto la demo la entendera, pero para ser concreto la pregunta es: en que se diferencia Lokad de otras plataformas de procurement que encontraremos en el sector, como por ejemplo Aeroxchange, porque una persona esta comparando activamente dos categorias y quiere entender la distincion entre optimizacion de decisiones y cosas como procesar RFQs, comparar cotizaciones, procesar POs, etc.?

Fabian Hoehner: Entonces, hay distintos aspectos que… No, solo digo que hay distintos aspectos que Aeroxchange hace, pero a alto nivel quiero decir que no somos, per se, una plataforma de procurement. De nuevo, un sistema de inteligencia. Asi que la diferencia…

Conor Doherty: Toma de decisiones.

Fabian Hoehner: Si. De nuevo, tienes tus sistemas transaccionales. Nosotros estamos encima. Somos el cerebro, y devolvemos las mejores decisiones posibles que la estadistica y la business intelligence pueden proporcionar, y que luego deberian ejecutarse. Aeroxchange tambien tiene mas funcionalidades de procurement para automatizar la funcion de compras en si, la comunicacion.

Eso no es lo que hacemos. De nuevo, podemos integrarnos con distintos proveedores, para casar cosas y tener comunicacion, pero no listamos precios ni cosas asi. Ese no es nuestro modelo de negocio. Asi que no nos llamaria una plataforma de procurement. Diria decision automation, decision support y sistema de inteligencia, como resumen.

Conor Doherty: Ah, de acuerdo. Una ultima, de nuevo, es mas comentario. La gente parece sentirse mas comoda, comprensiblemente, enviando DMs que comentando en publico. Y leo literalmente: “bien, pero estoy mas interesado en reparaciones. Puede este enfoque aplicarse para priorizar reparaciones y expediting?”

Fabian Hoehner: Si. Esa fue facil, verdad? Si.

Conor Doherty: Dale un poco de juego al publico con esa.

Fabian Hoehner: No, mas en serio, es de nuevo la misma logica. Ahora, en lugar de comprar una pieza, pregunto si deberia reparar mi unserviceable. Digamos que tienes 10 unserviceables y cero en stock. Entonces, en lugar de comprar, simplemente lo haces serviceable.

Hacerlo serviceable, en ese caso, es una reparacion que tiene un bucle de reparacion, que es un turnaround time, y cuesta algo. Ya sea interna o externa, ambas tienen un coste, pero hagamos reparacion externa porque es mas simple. Digamos que cuesta 50.000 hacer la pieza serviceable. La pregunta es, primero, como priorizo?

Porque tengo un presupuesto de reparacion que quiero enviar, o incluso una capacidad fisica. Soy capaz de procesar 50 piezas al dia. Cuales son las mas urgentes? E incluso cuales son economicamente factibles de reparar o no?

Por ejemplo, despues del COVID, eso fue un tema grande. Para algunos de nuestros clientes, el efectivo se convirtio obviamente en un problema serio. Simplemente no habia efectivo. Entonces la pregunta es: que haces?

Porque sigues teniendo todos tus leases y demas, pero ya no entra mas efectivo. Lo primero que podias hacer era exactamente eso: simplemente detener reparaciones, porque hay una gran salida de efectivo solo reparando piezas unserviceable. Puedes canibalizar tu stock existente y dejarlas unserviceable, lo que en ese momento era muy razonable: dejar cosas sin reparar, porque obviamente, si no tienes demanda, durante el COVID, vuela el 20 % de la flota, eso va a reducir bastante tu demanda de piezas serviceable. Simplemente paras, pero no puedes, y este es de nuevo el problema, decir: “ya no reparo.”

Necesitas una lista priorizada. Necesitas priorizar entre algunas piezas que son cruciales, que aun necesitas reparar porque si no las tienes, esto realmente te va a romper el cuello, mientras que otras, si tienes 10 en stock y cinco unserviceables, sabes que? Vas a estar bien asumiendo un poco mas de riesgo y dejando un par mas unserviceable, o reparando solo una.

Asi que la misma logica. Si. Y entonces los turnaround times se vuelven aun mas importantes. Si luego tienes timestamps adicionales, probabilidad de scrap, muy importante ahi. Si, pero la misma logica subyacente, y tambien mostramos dashboards para eso, pero eso lleva por otro camino.

Conor Doherty: Muy bien. Mi pensamiento final es: si tuvieras que resumir, de nuevo, cerrando el circulo, los puntos clave que la gente deberia llevarse de esto, si acaba de conectarse ahora o si salta directamente a la seccion Q&A, como resumirias el enfoque de compras, inversion y desinversion en aerospace? Y de nuevo, cuales son los puntos clave para la gente?

Fabian Hoehner: Primero, deberian avergonzarse de no escucharlo todo. Segundo…

Conor Doherty: Muy bien. El tercero para…

Fabian Hoehner: Voy a repetir: aprecia la incertidumbre. Eso significa que la incertidumbre existe en muchas formas, ya sean turnaround times, demanda o bill of materials probabilistica. Existe en todas partes, y no la saques de la imagen simplificando. Simplemente apreciala, y hay tecnologia para hacerlo mejor.

Y luego, segundo, prioriza con consecuencias economicas. En aeronautica, normalmente, la consecuencia es ganancia de nivel de servicio o evitacion de AOG por dolar gastado. Estos son conceptos centrales para llevarse. Y que hacemos en Lokad? Tenemos una plataforma potente para hacerlo, y tenemos brillantes supply chain scientists que la disenan junto con nuestros clientes. Y eso es Lokad en pocas palabras para aeronautica.

Conor Doherty: Muy bien. Fabi, no tengo mas preguntas. Muchas gracias por acompanarme hoy. Es un placer tenerte en el estudio, y espero que todos los demas hayan disfrutado escuchando tu voz tanto como yo.

Fabian Hoehner: Demasiado amable.

Conor Doherty: Eres un credito para la humanidad, senor.

Fabian Hoehner: Gracias.

Conor Doherty: No hay problema. Y gracias a todos por vernos. Gracias por sus comentarios, sus preguntas.

Un agradecimiento especial a todas las personas con las que hable durante el ultimo mes o asi. Quiero decir, promocionamos este evento durante aproximadamente un mes. Conecte con mucha gente, pregunte a muchas personas: “que queriais ver?” Y, como podeis ver, tome el feedback e intente adaptar lo que vimos hoy, o lo que mostramos hoy, a los deseos de la audiencia.

Ahora, si hay cosas que no cubrimos y que realmente os interesan, no dudeis en conectar con Fab y conmigo directamente en LinkedIn. Podeis vernos claramente. Nos gusta hablar. Somos encantadores.

Haced clic en el perfil, enviadnos un mensaje. O, si ya estais convencidos y quereis reservar una llamada y aprender un poco mas, deberia haber un enlace en el chat. Si no, podeis enviarnos un email directamente a contact@lokad.com. Como Fabi mostro un poco antes, hay otros modulos de los que podemos hablar en aerospace.

No los cubrimos hoy, pero volveremos en un momento futuro para cubrirlos. Pero hasta ese dia, no queda nada mas que decir salvo: si, volved al trabajo. Ah, de acuerdo. Por favor.