00:00:00 Introducción a las complejidades de la programación
00:02:30 Interdependencia y desafíos en el nivel de servicio en el sector aeroespacial
00:06:14 Discusión sobre Bill of Materials y Bill of Resources
00:13:15 Desafíos diarios de programación y limitaciones humanas
00:20:45 Presentación de algoritmos para una programación eficiente
00:28:30 Medidas de emergencia y precios AOG en el sector aeroespacial
00:36:02 Perspectiva matemática sobre los impactos de la programación
00:43:47 Complejidad y restricciones en la programación de tareas
00:50:17 Aprovechamiento del poder computacional para la optimización de la programación
00:57:39 Crítica a las limitaciones del FIFO en MRO
01:04:15 Toma de decisiones y automatización en supply chain
Resumen
En una entrevista reciente, Conor Doherty, Director de Comunicación en Lokad, y Simon Schalit, COO, discutieron el avance innovador de Lokad en la optimización de la programación en el sector aeroespacial, particularmente en la fabricación de aeronaves y operaciones de MRO. Destacaron la complejidad de coordinar numerosas piezas interdependientes, habilidades y equipos, que los métodos tradicionales tienen dificultades para gestionar. El enfoque de Lokad pasa de un Bill of Materials (BOM) a un Bill of Resources (BOR), considerando todos los recursos necesarios y su variabilidad. Utilizando algoritmos computacionales, Lokad puede generar soluciones prácticas de forma rápida, minimizando el riesgo financiero y los tiempos de inactividad. Esta integración de automatización y conocimientos estratégicos humanos es crucial para una programación eficiente y eficaz en entornos complejos.
Resumen Ampliado
En una entrevista reciente en Lokad, Conor Doherty, Director de Comunicación, se reunió con Simon Schalit, COO y Head of Supply Chain Science, para profundizar en las complejidades de la optimización de la programación, particularmente en el sector aeroespacial. La conversación destacó un avance significativo logrado por Lokad en este ámbito, que tiene profundas implicaciones para la fabricación de aeronaves y las operaciones de Mantenimiento, Reparación y Revisión (MRO).
Conor comenzó estableciendo el contexto, enfatizando la naturaleza complicada de la programación en las industrias de fabricación y reparación. Señaló que gestionar una vasta red de piezas, herramientas y personal, que puede cambiar de forma impredecible, es un desafío formidable. Simon Schalit luego profundizó en esta complejidad utilizando el ejemplo de la aeronáutica, donde la tarea de fabricar o reparar algo tan intrincado como el motor de una aeronave implica coordinar numerosas piezas, habilidades y equipos. Destacó que, a diferencia de otros segmentos del supply chain, donde las decisiones a menudo pueden tomarse de manera independiente, en MRO y fabricación, especialmente en la aeronáutica, cada elemento es interdependiente. La falta incluso de una sola pieza de cada cien puede detener todo el proceso, haciendo que las otras 99 piezas sean inútiles.
Simon explicó que esta interdependencia requiere un cambio desde la perspectiva tradicional del Bill of Materials (BOM) hacia un enfoque más integral del Bill of Resources (BOR). Mientras que un BOM enumera las piezas necesarias para una tarea, un BOR incluye todos los recursos necesarios—piezas, habilidades y equipos. Esta visión holística es crucial porque tiene en cuenta la disponibilidad y la variabilidad de cada recurso. Por ejemplo, las piezas pueden estar sujetas a la variabilidad del lead time, las habilidades dependen de la disponibilidad del personal, y los equipos pueden estar en uso o en reparación.
Conor y Simon discutieron las implicaciones prácticas de este enfoque. En un entorno tradicional de MRO, la planificación diaria a menudo implica ajustar manualmente los cronogramas basándose en la disponibilidad de piezas y personal. Este método, aunque común, es ineficiente y propenso a errores debido a las limitaciones de la mente humana para manejar variables complejas e interdependientes. Simon destacó que incluso cambios menores en un cronograma pueden tener consecuencias en cascada, impredecibles, lo que dificulta lograr un plan óptimo.
La conversación luego se centró en el papel de los algoritmos computacionales para abordar estos desafíos. Simon explicó que el algoritmo de Lokad puede generar rápidamente una solución lo suficientemente buena al considerar el estado actual de todos los recursos. Esta capacidad es vital en la industria aeronáutica, donde cada minuto de inactividad tiene un alto costo. La fortaleza del algoritmo reside en su capacidad para simular diversos escenarios del tipo “what if” scenarios, ayudando a las empresas a comprender las implicaciones financieras de diferentes decisiones y medidas de emergencia.
Conor enfatizó que el objetivo no es encontrar una solución perfecta, sino una práctica que minimice el riesgo financiero y refleje el estado actual de los recursos. Simon estuvo de acuerdo, señalando que la capacidad de generar rápidamente una nueva secuencia de eventos basada en los recursos disponibles es crucial para minimizar el impacto financiero.
La discusión también abordó las limitaciones de las heurísticas tradicionales como FIFO (First In, First Out). Aunque FIFO es simple y rápido, no tiene en cuenta la importancia financiera y estratégica variable de las diferentes tareas. Simon argumentó que se necesita un enfoque más matizado, que considere el contexto específico y las restricciones de cada tarea, para lograr una programación efectiva.
En conclusión, Simon y Conor subrayaron la importancia de integrar herramientas computacionales con conocimientos estratégicos humanos. Aunque los humanos sobresalen en la planificación estratégica, no están preparados para manejar las complejidades minutiosas de la programación en operaciones a gran escala. Al aprovechar los algoritmos, las empresas pueden lograr decisiones de programación más eficientes y financieramente sólidas.
Simon concluyó afirmando que el futuro de la toma de decisiones en supply chain reside en la automatización, particularmente en entornos complejos como el aeroespacial. Enfatizó que el enfoque de Lokad combina el poder computacional necesario para una toma de decisiones granular con la supervisión estratégica proporcionada por expertos humanos, ofreciendo una solución robusta a los desafíos de la optimización de la programación en las industrias de fabricación y reparación.
Transcripción completa
Conor Doherty: Bienvenidos a Lokad. La programación es uno de los conceptos más complicados en las industrias de fabricación y reparación. Esto se debe a que se debe gestionar una red enorme de piezas, herramientas y personas, y esa red puede cambiar en cualquier momento.
El invitado de hoy, Simon Schalit, es COO y Head of Supply Chain Science en Lokad, y se unió a mí en el estudio para discutir cómo su equipo abordó este problema. Ahora bien, él y yo hablamos principalmente sobre la programación en el sector aeroespacial, pero todo lo que discutimos hoy se aplica de igual manera a cualquier industria de fabricación. Como siempre, si disfrutas lo que escuchas, dale like a este video, suscríbete al canal de YouTube y síguenos en LinkedIn. Y con eso, te presento la conversación de hoy con Simon Schalit.
El tema de hoy fue la optimización de la programación y el extenso trabajo que el equipo de supply chain science ha realizado para lograr un avance en ese campo. Así que, antes de entrar en detalles, desde tu propia perspectiva, y tomando el sector aeroespacial como ejemplo concreto, ¿cuál es exactamente el problema de la programación que nuestro equipo de ingenieros, nuestro equipo de supply chain scientists, está tratando de resolver? ¿Cuál es el problema?
Simon Schalit: Bien, tomemos el ejemplo de la aeronáutica, MRO o fabricación. Cuando intentas fabricar o reparar algo de la magnitud de un avión o de un gran segmento de un avión, digamos, un motor, por ejemplo, te enfrentas a algo increíblemente complejo. Complejo, por supuesto, desde una perspectiva de ingeniería, pero también simplemente si consideras la gran cantidad de piezas, habilidades y equipos que vas a necesitar para poder llevar a cabo la tarea que se te asigna, ya sea de fabricación o de reparación.
En la mayoría de los segmentos del supply chain, cuando tomas decisiones, se podría argumentar que las decisiones pueden considerarse independientes sin que este tipo de pensamiento sea demasiado perjudicial. Por ejemplo, si decido comprar el artículo A y el artículo A está faltante de stock, aún podré vender el artículo B o el artículo C. Podría haber consecuencias, pero en general, ese es el caso. Así que pensar de manera independiente no es tan perjudicial.
Cuando se trata de MRO o fabricación, especialmente en el entorno aeroespacial, eso se vuelve completamente falso. Si deseas poder reparar, digamos, un motor y necesitas 100 piezas para repararlo, contar con 99 de esas piezas y faltar una no te servirá de nada, igual que no tener ninguna de ellas.
Conor Doherty: ¿Qué quieres decir?
Simon Schalit: Porque el motor aún no puede hacerlo—el avión aún no puede volar, incluso si falta solo una de esas piezas. Incluso si tienes 99 de ellas, el avión aún no puede volar. Así que te enfrentas a un problema en el que no debes intentar tener cada pieza por separado; necesitas tener todas las piezas y, de hecho, todos los recursos disponibles en el lugar correcto y en el momento adecuado. De lo contrario, simplemente no se puede hacer nada.
Y, de hecho, eso cambia el problema por completo. Porque incluso si dijeras, “Está bien, tengo un 99% nivel de servicio,” lo que la mayoría de las personas en la mayoría de las empresas dirían, “Sí, eso está bien, es un alto nivel de servicio.” Si miras el 99% de nivel de servicio de manera independiente, es bastante alto. Pero si dices, “Está bien, necesito 100 piezas, y para cada una de esas 100 piezas tendré un 99% de nivel de servicio individualmente,” es decir, un 99% de probabilidad de que estén presentes en el momento en que las espero, de hecho, si se considera que son independientes, el nivel de servicio combinado de este caso tan simple sería en realidad extremadamente bajo. Estaría por debajo del 40%.
Así que significa que incluso con un 99% de nivel de servicio, si necesitas que 100 piezas o recursos diferentes estén disponibles, la posibilidad de no poder llevar a cabo tu reparación o paso de fabricación no es en realidad un accidente; se convierte en la norma. Tiene más de un 50% de probabilidad de ocurrir. Esto te sitúa en un mundo que es extremadamente diferente de la habitual toma de decisiones en supply chain. Te coloca en un mundo donde, incluso con niveles de servicio muy altos, que surjan problemas es la norma y no la excepción. Por lo tanto, necesitas construir tus supply chains y tu proceso de toma de decisiones en supply chain para que sean resilientes ante esto. Así que ese es un tema completamente diferente.
Conor Doherty: Bien, gracias. Y mencionaste algunos términos allí, y solo quiero separarlos un poco, porque hablaste de piezas y luego empezaste a hablar de recursos. Ahora, presumo que no los usaste de manera sinónima; estabas haciendo una distinción. Entonces, ¿podrías proporcionar un poco más de claridad? Cuando dices recursos, no estás hablando únicamente de piezas físicas. De nuevo, si estamos hablando de reparar un motor o reparar una APU, sí hay piezas físicas involucradas en el proceso. Pero cuando hablas de recursos, ¿a qué te refieres?
Simon Schalit: Bueno, cuando hablas de reparar o fabricar algo, la gente se refiere al concepto de bill of material. Un bill of material es básicamente la lista de piezas que necesitas juntar para terminar algo—un avión, un motor, lo que sea. El problema es que esto es solo una parte del problema. Vas a necesitar otros tipos de recursos para llevar a cabo la tarea.
Principalmente, esos recursos serán habilidades que provienen de las personas y equipos que no necesariamente consumes, sino que vas a utilizar. Y, a menudo, pueden ser bastante costosos, y no cuentas con una cantidad infinita de ellos, como por ejemplo un banco de pruebas, si estamos hablando de aeronáutica. Así que no basta con tener todas las piezas disponibles. Vas a necesitar asegurarte de tener el equipo—banco de pruebas, grúa, lo que sea—y las personas para operar y ensamblar las piezas de manera segura y técnicamente válida.
Así que cuando hablamos del problema de esos bills of materials y cómo se utilizan, preferimos referirnos a un concepto de bill of resources, el cual es más preciso en el sentido de que abarca el problema en su totalidad en lugar de solo los materiales.
Conor Doherty: Bien, ahora que has reintroducido el término bill of materials, con el que supongo que todos los que están viendo esto están probablemente familiarizados, ¿podrías contrastar en términos concretos la perspectiva del bill of resources con la del bill of materials? Por ejemplo, toma una decisión, esboza una decisión para, digamos, un MRO utilizando un avión, solo para hacerlo simple, y explica cómo se desarrollaría en tiempo real una perspectiva de BOM en comparación con una perspectiva de bill of resources más sofisticada.
Simon Schalit: De acuerdo, por favor. Generalmente, la actividad de MRO o fabricación sigue diferentes pasos que deben realizarse en un cierto orden. Algunas cosas deben hacerse antes, otras después. Pero cada paso puede definirse con su propio bill of resources, es decir, la lista de piezas que necesitas para llevar a cabo ese paso de reparación en particular, la lista de habilidades—no de personas, porque podrías tener diferentes personas con diferentes habilidades—la lista de habilidades que son necesarias para llevarlo a cabo, y la lista de equipos.
Las piezas usualmente se consumirán en el sentido de que serán montadas. Las habilidades no se consumirán de la misma manera en el sentido de que las personas aún tienen esas habilidades, pero se consumirán desde la perspectiva del tiempo durante cierto período. Lo mismo para el equipo. Los tres elementos—piezas, habilidades y equipo—vienen todos con su propio conjunto de variabilidades.
Las variabilidades para las piezas suelen ser si están en stock o no, lo cual es una forma simple de decirlo. Detrás de eso se encuentra el concepto de variabilidades del tiempo de entrega, principalmente, y por supuesto, si realizas el pedido en el momento adecuado o no, pero generalmente principalmente la variabilidad del tiempo de entrega.
La variabilidad que se asocia a la habilidad proviene de si la persona estará presente y disponible, pero sobre todo presente para llevar a cabo la tarea. Así que viene con todas las variabilidades asociadas a los seres humanos en general, como si la persona está enferma, si la planificación se hizo correctamente, si la persona tiene la habilidad válida desde una perspectiva legal, etc. Y de hecho, ese es el tipo de variabilidad que es aún más difícil de captar y controlar que el tiempo de entrega porque no se puede forzar a alguien a no estar enfermo. Si la persona está enferma, está enferma.
Y, por supuesto, está la disponibilidad del equipo, el cual nuevamente se consume durante un cierto período de tiempo, pero que, por supuesto, tiene menos probabilidades de estar enfermo. El equivalente sería que esté roto, en reparación, o quizás todavía atascado en otro motor o aeronave en reparación y aún no liberado de esa tarea en particular. Esos son, diría yo, los tres, y todos vienen con sus variabilidades, y eso es lo que hace que el problema sea difícil.
Conor Doherty: Bueno, sobre esa nota, nuevamente, para tomar un ejemplo concreto, y otra vez, podemos comparar cómo un MRO tradicional con perspectiva de lista de materiales y luego, digamos, tal vez uno de nuestros clientes con perspectiva de lista de recursos, podemos contrastar cómo abordarían un escenario. Estamos intentando reparar, creo que es un A380. Creo que es un A380. El lunes por la mañana, necesitamos reparar el motor A. Llegamos y tienes una perspectiva BOM. Así que de nuevo, una perspectiva BOM determinista física. Sé cuántas piezas necesito—100 piezas para reparar ese motor. Llegas el lunes por la mañana, tenemos todas las piezas. Simon y Connor están ausentes. Por ejemplo, Simon está enseñando algo, Connor se lastimó la espalda levantando algo pesado, así que no estamos disponibles.
Así que tienes todas las piezas, por lo que esa parte de la ecuación tienes suerte. Tienes las 100 piezas. En realidad, tienes todas las herramientas—quizás se necesitan 20 herramientas, digamos simplemente 20 herramientas. Entonces, tienes 100 piezas, tienes las 20 herramientas, pero te faltan las habilidades críticas. Y no incluso todas las habilidades, solo Simon para fijar cierta pieza, necesitas una licencia para eso, y Connor para supervisar. ¿Qué sucede ahí en términos de decisiones si tienes una perspectiva de lista de recursos?
Simon Schalit: No es tener la lista de recursos lo que va a marcar la mayor diferencia. La lista de recursos te permitirá combinar las diferentes incertidumbres que existen en los tres segmentos que acabo de describir y darte cuenta de cuán probable es que ocurra un incidente como el que acabas de describir. Necesitas organizarte de una manera que sea capaz de enfrentar ese tipo de problema.
Pero tomemos tu ejemplo. Digamos que tenemos todas las piezas, tenemos todo el equipo, pero simplemente no están las personas, lo cual es en realidad bastante frecuente por muchas razones. Actualmente, la forma en que las personas enfrentan eso es que cada mañana en el taller, digamos que estamos hablando de un gran taller que realiza reparaciones, cada mañana y quizás incluso dos veces al día, las personas encargadas de las diferentes líneas de reparación se reunirán e intentarán reconstruir el horario del día.
Verán qué es lo que falta, ya sean piezas o personas, y dirán, “Está bien, el plan que teníamos para hoy se ha ido. Simplemente no existe. Entonces, ¿cuál es la cantidad mínima de cambios que podríamos hacer porque somos simplemente seres humanos y no tenemos mucho tiempo? ¿Cuál es la cantidad mínima de cambios que podemos hacer al horario para que sea viable y no se desvíe demasiado del objetivo que teníamos para el día?”
El problema es que esta lógica, este tipo de lógica de mínima inversión, no funciona realmente bien. Eso es lo que las personas hacen porque no necesariamente tienen otra cosa a su disposición, pero no funciona muy bien por una razón muy simple.
Cambiar el plan un poco se deriva de la idea de que en una situación simple, esos cambios mínimos tendrán consecuencias mínimas porque existe una especie de continuidad o linealidad en la cantidad de consecuencias en comparación con la cantidad de cambios que se realizan. Existe ese tipo de suposición, por lo que haces cambios mínimos porque no es demasiado complejo y esperas que no vaya a tener muchas consecuencias.
El problema es cuando hablas de programación, hablas de reorganizar potencialmente decenas, si no cientos de diferentes actividades que cada una viene con sus propias restricciones y variabilidad asociada. Así que la idea de que existe algún vínculo entre la magnitud del cambio y la magnitud del impacto es, digamos, algo ilusorio, desafortunadamente.
Sin embargo, la mente humana es limitada porque ni siquiera puede intentar estimar el impacto general, por lo que intentará limitarse a cambios mínimos esperando que tengan un impacto mínimo. Pero lo único que está absolutamente asegurado es que, incluso si tu plan inicial era un buen plan o incluso cercano a un plan óptimo, en el momento en que haces cambios, no tienes absolutamente ninguna garantía de que tu nuevo plan esté siquiera remotamente cerca de un nuevo plan óptimo. Es simplemente un plan que resulta funcionar.
Conor Doherty: Déjame intentar reflejarlo y puedes corregirme si lo he entendido mal, porque es un punto realmente interesante. Anteriormente, hablé de que Simon y Conor estaban ausentes y se necesitaba trabajar en el motor A. Digamos que Joannis, con un bolígrafo y papel o una hoja de cálculo de Excel, dice, “Oh bueno, Max, nuestro ingeniero que también es nuestro videógrafo detrás de la cámara, en realidad tiene las habilidades que tienen Simon y Conor. Simplemente lo aparto de lo que iba a hacer. Sí, puede trabajar en el motor A. Problema resuelto.” Así que, simplemente muevo a una persona, sencillo.
¿Pero es posible que hacer eso introduzca consecuencias desproporcionadas? Porque con la misma cantidad de tiempo que Max emplea para trabajar en el motor A, podría haber realizado las tareas 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 en los motores B, C, D, E y F, y esos en combinación tienen un mayor rendimiento financiero que simplemente trabajar en el motor A, por ejemplo?
Simon Schalit: Sí, el ejemplo es absolutamente correcto. Lo que las personas deben tener en cuenta es que hay que llevar a cabo esas tareas en un cierto orden. Entonces, si una tarea no se realiza, el problema no es solo que esa tarea no se haya hecho, sino que todo lo que habías planeado que se suponía que ocurriría después, bajo la condición de que la tarea A se hiciera, no puede suceder.
Entonces, si apartas a alguien de otra tarea y dices, “Haz la tarea A”, vas a poder hacer B, C y D. Pero el problema es que se suponía que esa persona iba a hacer otra cosa, lo cual no se va a realizar y también tendrá consecuencias en cascada. Tienes este tipo de efecto mariposa, y lo que es muy difícil para un humano es decir cuál efecto mariposa tiene el mayor impacto financiero y qué opción debería elegir. Eso es realmente difícil, incluso cuando estás en un entorno muy pequeño y no tan complejo. Si llevas eso a la escala de una gran actividad de MRO, pensar que puedes hacer algo que esté cercano a lo óptimo es simplemente ridículo.
Conor Doherty: Quiero ser muy cuidadoso con cómo nos expresamos aquí porque el mensaje no es que las personas sean tontas. Mi entendimiento de esto, habiendo asistido a conferencias de MRO, es que estamos tratando con personas muy inteligentes y muy talentosas. Es simplemente que es irrazonable esperar que un ingeniero muy inteligente o un grupo entero de personas muy inteligentes vuelvan a trabajar una secuencia increíblemente intrincada de eventos, cada paso de la cual tiene impactos financieros, múltiples veces al día, cada día, para una compañía aeronáutica multimillonaria. Esa es una proposición irrazonable. ¿Tu proposición no es hacer eso, sino hacer algo diferente?
Simon Schalit: Sí, tienes razón. Es necesario afirmar que la gente ha estado haciendo eso por una buena razón. Primero, porque no había alternativa, y también porque se basaban en la suposición de que, sí, por supuesto, ocurren problemas. Hay situaciones en las que tendrás que reorganizar todo, pero no va a suceder muy a menudo. Para el resto de la supply chain en general, sí, no sucede muy a menudo. Pero en este contexto particular, sucede todos los días. Ese es el problema. Por eso los humanos se verán abrumados, no porque sean incompetentes o tontos, sino simplemente porque los humanos no están diseñados para manejar este problema.
Así que la forma en que proponemos hacerlo de manera diferente es, por supuesto, que una máquina, una computadora, lo haga, un algoritmo. No es nuevo. Este tipo de problema de organización ha sido abordado por las computadoras desde hace algún tiempo, especialmente con el auge de la computación en la nube en las últimas décadas. El problema aquí es que estás en un contexto increíblemente complejo, como dije, con una secuencia de eventos muy intrincada. Cada evento viene con una compleja lista de recursos, dependencias e incertidumbres.
Las formas tradicionales de abordar eso usualmente no funcionan de manera muy satisfactoria y, lo que es más importante, no funcionan lo suficientemente rápido. Ahí es donde radica el problema. Si le pides a una computadora que resuelva un problema como ese y construyes un algoritmo lo suficientemente bueno, es probable que obtengas una buena solución si dedicas suficiente tiempo y potencia de cómputo a ese problema en particular. Va a ser difícil; muchas soluciones ni siquiera llegan a este punto, pero se puede lograr.
El problema es que la situación en la que estás es el lunes por la mañana. El taller necesita comenzar a trabajar, si es que aún no lo ha hecho, porque normalmente, imaginemos, es lunes por la mañana. Necesitan reprogramar todo porque faltan tales o cuales piezas y estas o estas personas están ausentes. No tienes unas pocas horas por delante para resolver el problema; tienes unos pocos minutos porque necesitas actuar rápidamente. Cada minuto cuenta, y en aeronáutica, cada minuto es costoso. Así que necesitas resolver ese problema en unos pocos segundos o, a más tardar, unos pocos minutos, y es un asunto muy urgente.
Ahí es donde se vuelve realmente difícil. Así que lo que hemos desarrollado es un algoritmo que nos permitirá resolver ese problema de manera lo suficientemente buena. Es imposible probar que tu solución será óptima, pero al menos es una solución muy buena en comparación con otras que podrías encontrar, y donde puedes demostrar que, financieramente hablando, tendrás una solución muy buena en cuestión de minutos. Nuestros clientes generalmente pueden ser bastante estrictos con el número de minutos que tenemos para resolver el problema.
La idea detrás de esto, no voy a entrar en detalles sobre las matemáticas y las computadoras, sino que se trata de utilizar la capacidad computacional y confiar en el hecho de que lo que buscas no es la solución en sí, sino cómo estructuras el solucionador que será capaz de resolver el problema en unos pocos minutos. En realidad, eso es una especie de meta problema. Sería muy interesante hablar de eso durante horas, pero no tenemos ese tiempo ahora. La clave es que no quieres encontrar la solución; quieres encontrar el solucionador que encontrará la solución basado en la solución ideal previa que tuviste tiempo de calcular durante la noche o cuando tuviste más tiempo.
Conor Doherty: Desde la perspectiva del cliente, quieren la solución, quieren que la nueva secuencia se genere lo más rápido posible. Solo quiero profundizar un poco en un punto que mencionaste, porque desde la perspectiva de gestionar expectativas en esta conversación, no estamos presentando la idea de que siempre tendrás en seis minutos, creo, o tres a seis minutos, dijiste que puedes regenerar un horario enorme de operaciones para, digamos, reparar un motor y reflejar el nuevo estado de la lista de recursos.
En términos de gestionar las expectativas de lo que eso significa, no estás diciendo que esto es perfecto, que si pasaras 10 años pensando, no se te ocurriría uno mejor. Simplemente, es una buena solución que refleja lo que está disponible ahora y gestiona tu riesgo financiero.
Simon Schalit: Sí.
Conor Doherty: Hacer esta nueva secuencia de eventos con estos recursos disponibles resulta en un resultado específico financieramente.
Simon Schalit: Sí, de acuerdo, eso es exactamente lo que hacemos y lo que tú también quieres, porque es algo necesario. No solo quieres regenerar un horario, sino que también quieres darle a tus clientes la posibilidad de cambiar la realidad de alguna manera. A eso se le llamaría un escenario de “qué pasaría si”.
Por ejemplo, si hoy falta una persona, vamos a llegar tarde. Puedo encontrar una buena solución, pero la buena solución que encuentro aún me deja una persona corta, por lo que no va a ser mejor que lo que tenía con esa persona adicional. Todo va a estar ligeramente retrasado. Entonces, quiero darle a mi cliente la posibilidad de generar un escenario donde él diga, “Está bien, hoy tuve una persona menos. Necesito recuperar el tiempo perdido. Tal vez podría agregar a alguien además de mi horario regular mañana o quizás abrir por un día adicional cuando el taller se suponía que estaba cerrado.” Quiero saber qué ocurriría, cuánto tiempo ganaría si abriera un sábado, por ejemplo, donde el taller podría estar cerrado de manera regular.
Entonces, quieres que la herramienta sea capaz, por supuesto, de simular lo que realmente está sucediendo porque probablemente eso es lo que vas a hacer hoy, pero también quieres que el cliente sea capaz de simular un escenario de “qué pasaría si” donde integren las medidas de emergencia que podrían tomar en este momento. Pero es importante que ellos entiendan cuáles serían las consecuencias de estas medidas de emergencia, porque se llaman así por una razón. No recurres a ese tipo de cosas para tu actividad regular porque cuestan dinero. Usualmente cuestan mucho dinero. Por eso no las usas de manera regular.
Conor Doherty: Ejemplo como precios AOG para obtener piezas en el último momento.
Simon Schalit: Exacto, es como si te faltara una pieza y eso causara una parada del trabajo; el precio que estás dispuesto a pagar por esa pieza en particular puede ser altísimo. Es algo que, por supuesto, es cierto en la industria aeronáutica y es algo muy conocido en la industria automotriz, por ejemplo. Están dispuestos a enviar piezas que faltan a un precio astronómico.
Conor Doherty: Porque el costo financiero de no enviar nada es aún mayor.
Simon Schalit: Exacto. Entonces, lo que se desea es darle al cliente una estimación de la ganancia para que pueda considerarla al evaluar el costo de esa medida de emergencia y tomar una decisión informada sobre si recurrir a esa medida de emergencia realmente tiene sentido desde una perspectiva financiera. Necesitan saberlo para tomar la decisión y documentarlo para defenderla dentro de la empresa. Porque cuando se recurre a medidas de emergencia costosas, tendrás que rendir cuentas ante tu jefe o ante la empresa en general.
Conor Doherty: De nuevo, quiero tener mucho cuidado con el lenguaje aquí. Has mencionado escenarios de emergencia del tipo “what if”, pero anteriormente en la conversación hablaste sobre la percepción de las emergencias y cómo esa percepción está algo sesgada. La comprensión de la gente sobre lo que constituye una emergencia es quizá algo ingenua. Entonces, ¿podrías diferenciarlos un poco?
Cuando hablamos de producir o reparar una APU o fabricar una APU, estamos hablando de muchas piezas, muchas herramientas y muchas personas. Si hablamos de fabricar un avión completo, aún más: medio millón de piezas, cientos de herramientas, posiblemente cientos de ingenieros y técnicos. Entonces, cuando hablamos de emergencias, como que falte un elemento de la lista de recursos, dado el alcance de los recursos de los que hablamos, ¿es “emergencia” el término correcto para reflejar algo que ciertamente sucede con bastante frecuencia o que al menos es muy probable desde un punto de vista probabilístico?
Simon Schalit: Sí, bueno, hay algo que necesitamos entender. Si hablamos de aeronáutica, la aeronáutica es por naturaleza o por diseño una industria muy adversa al riesgo por muy buenas razones. El problema es que en supply chain, cada decisión que tomas, sin excepción, es una apuesta. Estás apostando a que el futuro no será muy diferente de lo que esperas que sea. Realizas tus apuestas basándote en esa suposición.
Esta apuesta puede ser arriesgada o no, y podríamos adentrarnos en esta metáfora de la apuesta en la que quieres actuar más como el casino que como el jugador. Pero en esencia, la parte importante es que cuando se trata de programación, el contexto del que hablábamos, la apuesta que haces sobre el futuro es extremadamente compleja. La idea de que el futuro se alineará exactamente como esperabas o como estaba planeado no es realista. No va a suceder de la manera que planeas.
Conor Doherty: Perdóname por interrumpirte, pero ese es un buen punto. Cuando dices, por ejemplo, que para reparar un motor, necesito 100 piezas. El lunes por la mañana, necesito 100 piezas, necesito 10 herramientas y necesito cinco ingenieros. Ese es el futuro para el que estoy planeando. ¿Qué tan probable es eso? Por favor, continúa a partir de ahí.
Simon Schalit: Sí, vas a planificar todos tus recursos basándote en la suposición de que esos recursos estarán allí. Planificaste una secuencia de eventos que en teoría debería encajar. Pero dado el inmenso número, esta especie de maldición de la dimensionalidad, no va a suceder. Tomamos el ejemplo de 100 piezas con un nivel de servicio del 99%. Ya ves que la probabilidad de que realmente todo esté en el lugar correcto en el momento correcto simultáneamente es inferior al 40%. Así que no va a suceder.
El problema es que, dado que las empresas son adversas al riesgo, el reflejo que tienen es decir: “Está bien, si un nivel de servicio del 99% no es suficiente, voy a subirlo.” Cuando hablas de piezas, lo que quieres decir con un nivel de servicio del 99% es que vas a hacer pedidos para que las piezas lleguen antes, incluso más temprano, solo para compensar la variabilidad en el tiempo de entrega —el tiempo que tardan en llegar realmente las piezas. Porque esa es la principal incertidumbre que tienes con las piezas.
Entonces, vas a tomar cada vez más margen de seguridad hasta pasar de un nivel de servicio del 99% al 99.9%. Salvo que necesites 100 piezas o más de 100 piezas, la cantidad de dinero que necesitarías para alcanzar un nivel de servicio combinado que sea satisfactorio es algo que simplemente no puedes permitirte. Así que, el enfoque tradicional de decir: “Voy a llevar el nivel de servicio al punto en que me sienta cómodo y eso garantizará que pueda implementar el plan que he ideado,” no es necesariamente una forma válida de trabajar.
Por supuesto, vas a necesitar altos niveles de servicio porque eso es aeronáutica. Pero lo que necesitas es una forma de cambiar tu plan de la manera más eficiente y rentable que garantice que el nuevo plan que tengas que idear sobre la marcha sea el mejor que puedas concebir basándote en la información que tienes. De hecho, eso marca una gran diferencia en comparación con simplemente desear que las cosas salgan según lo planeado y tener humanos cada mañana sin las herramientas adecuadas tratando de idear un nuevo plan.
Conor Doherty: Entonces, de nuevo, para resumir, el argumento que estás haciendo es que cuando lo analizas —y no vamos a profundizar demasiado en las matemáticas—, desde una perspectiva puramente matemática, cuando listas o simplemente enumeras todas las piezas físicas que necesitas, todas las herramientas físicas que necesitas, y luego todas las habilidades abstractas o las personas físicas necesarias para estar presentes y completar una secuencia de acciones, y además consideras que ninguna de estas cosas ocurre de manera aislada. Quiero decir, no reparas un motor y luego estas personas se van a casa. Trabajan en otra cosa. Hay una naturaleza interconectada en todas estas secuencias.
Así que, cuando llegas el lunes por la mañana, matemáticamente, la probabilidad de que algo falte es mucho, mucho mayor de lo que la gente se da cuenta o quiere darse cuenta. Las consecuencias financieras de eso, como literalmente cada segundo que pasas deambulando tratando de averiguar qué hacer a continuación, a dónde ir, quién está allí, qué está disponible, etc., trabajando, enviando hojas de cálculo de Excel —todo ello tiene consecuencias financieras inmediatas y significativas. ¿He entendido correctamente?
Simon Schalit: Correcto, y también añadiría que es el tiempo que pierdes reacomodando el plan y el tiempo perdido al seguir un nuevo plan que es cualquier cosa menos óptimo. Normalmente, esta segunda parte no es tan dolorosa porque es un poco más difícil de cuantificar, pero en realidad es muy, muy costosa. Tienes que imaginar que cuando se trata de actividades de MRO o de fabricación aeronáutica, cada minuto cuenta porque cada minuto es un segmento o una fracción de un avión adicional que podría salir y volar, ya sea un avión nuevo o generador de dinero. Así que incluso un pequeño incremento en la eficiencia de tu capacidad para crear nuevos planes sobre la marcha puede tener un impacto tremendo desde una perspectiva financiera.
Conor Doherty: También se me ocurre, y acabas de mencionarlo, lo he anotado. Hemos estado hablando mayormente sobre las implicaciones directas, como que la consecuencia inmediata de que falte una persona es, bueno, que esa parte del motor no se repara. Pero indirectamente, existe el efecto dominó no solo a los otros procesos, ya que muchas veces, seamos realistas, esto no ocurre en un vacío. Pasas de uno a otro, o esta parte se vuelve a añadir a esa otra. Los subensamblajes del BOM completan las piezas más grandes. Pero también hay obligaciones contractuales que se deben considerar. Quiero decir, si no logras devolver un avión a la circulación, dependiendo de si eres un MRO, eso también tiene consecuencias financieras.
Así que hay consecuencias directas, hay consecuencias indirectas, pero nuevamente, el aspecto clave aquí es que hay cientos, si no miles, de decisiones que intervienen en un cronograma óptimo o muy bueno, y cada una de estas decisiones tiene un impacto financiero. Y cuando salen mal porque falta algo, y aparentemente es muy probable, incluso si no sucede mañana, es probable que ocurra al día siguiente o al siguiente o al siguiente. Esto tiene costos financieros.
Simon Schalit: Sí, y de hecho en la práctica, seamos muy prácticos aquí. En el trabajo diario, lo que he observado en esas empresas es que el ejercicio de hacer un nuevo plan es tan lento y tan difícil que el taller se enfoca solo en el problema que conocen hoy. No tienen tiempo para nada más. Así que lo que sucede es que al día siguiente existen nuevos problemas, como problemas antiguos que aún no se han solucionado, además de problemas nuevos.
Pero si observas los detalles de los nuevos problemas, la mitad de ellos podrías haberlos sabido el día anterior. Pudieron haber sido predichos. Pero en la práctica, lo que hemos observado es que la gente está tan enfocada en el problema que debe resolver hoy que no necesariamente tiene el tiempo o la capacidad intelectual para anticipar los problemas de los próximos días, lo cual puede hacer que los problemas se agraven con el tiempo y conduzca generalmente a retrasos acumulados en las actividades de MRO o en las actividades de fabricación. Así, las violaciones contractuales en sus obligaciones contractuales, por supuesto.
Conor Doherty: De nuevo, ese es un muy buen punto porque, al igual que los procesos no ocurren de forma aislada, las externalidades o simplemente las consecuencias de las acciones no están en un vacío. Así que, nuevamente, la acumulación del retraso y, por extensión, la acumulación del impacto financiero continúa en el fondo, ya sea que estés dispuesto a reconocerlo, a pensarlo o a actuar en consecuencia. O incluso si actúas y piensas, “he resuelto ese problema”, en el fondo, porque hay una variable que pasaste por alto, porque, de nuevo, soy humano, eres humano, somos humanos, el libro de cuentas, la factura, el medidor siguen funcionando en segundo plano. Puede que ni siquiera sepas que está pasando.
Bien, sigamos un poco, porque en cuanto a los detalles de la optimización de la programación tal como la vemos, hemos hablado de los aspectos de inventario de las piezas, herramientas. Cuando hablas de las habilidades, ¿se trata simplemente —déjame replantear la pregunta— de que, por ejemplo, tomes esa pieza, esa herramienta, y envíes a Simon para trabajar en ese motor, o es algo un poco más matizado que eso?
Simon Schalit: Bueno, va a ser algo más matizado en el sentido de que, usualmente, viene con todo un conjunto de complejidades. Básicamente, el resultado se vería como un conjunto de asignaciones recomendadas para materiales, piezas y equipos con una planificación. Esta pieza necesita ser asignada a ese avión o a ese motor. Este equipo en particular debe ser utilizado por ese avión o ese motor durante este segmento de tiempo. Y luego, esta persona en particular, que tiene esta habilidad en particular, debe ser asignada a ese motor o avión durante este periodo. El sistema necesita garantizar que no se violen ninguna de las restricciones que se establecen para cada una de las tareas que vamos a programar.
En términos de complejidad, si hablas de piezas, usualmente eso es bastante sencillo. La pieza se asigna a una tarea porque es parte de la lista de materiales, y eso está bien. Por supuesto, necesitas tener las piezas, lo cual no está garantizado. Así que, generalmente, puedes intercambiarlas siempre que sea posible, pero decides cuándo asignarlas y tratas de hacerlo en el último minuto posible para evitar reubicaciones. Pero esa es la parte sencilla. Curiosamente, es en la que la gente se concentra más, porque es la que generalmente sienten que tienen mayor control.
Pero para la asignación de personas y equipos, generalmente se presentan juntos, y se vuelve un poco más complejo, especialmente porque hay tareas que requieren no solo una habilidad o no solo las habilidades de una persona, sino quizá diferentes habilidades de distintas personas al mismo tiempo, ya sea por razones técnicas o simplemente por razones de seguridad. Simplemente operar una grúa mientras mueves un motor en medio del taller requiere al menos dos personas, solo por razones de seguridad: una que pueda operar la grúa y otra que esté allí para asegurarse de que no estemos haciendo nada mal y que el camino esté despejado. Como mínimo, eso es lo que ocurriría.
Así que no puedes considerar todos esos recursos, especialmente los recursos calificados, como entidades completamente independientes. Eso sería demasiado fácil. Más a menudo que no, debes considerarlos como si vinieran con restricciones, en donde necesitan estar disponibles en el mismo lugar al mismo tiempo para la misma tarea. Y tienes la opción en la que las tareas pueden ser realizadas por una, dos, tres o cuatro personas al mismo tiempo, o no al mismo tiempo, en secuencia o no en secuencia. Una amplia variedad de diferentes tipos de combinaciones donde el algoritmo simplemente necesita encontrar cuál es la mejor solución válida, considerando que mientras utilizas esas habilidades, no están presentes en otro lugar.
Eso hace que el problema sea bastante difícil. Para realizar la tarea A, si necesitas dos personas, estas deben estar disponibles en un momento determinado. Así que, independientemente de lo que estuvieran haciendo, deben terminar aproximadamente al mismo tiempo para que ambas puedan estar disponibles para trasladarse a esa tarea en particular. Y eso no es trivial, ya que, muy a menudo, una de ellas probablemente tendrá que esperar a que la otra termine, y eso cuesta bastante. Así que deseas evitarlo tanto como sea posible. Cada minuto cuenta. Esas habilidades valen mucho dinero.
Conor Doherty: Bien, y de nuevo, para quien escucha, podría sonar como magia. Soy consciente de eso porque lo que parece que estás diciendo es que lo que Lokad hace ahora es, nos enfocamos solo en la programación. Ya hemos hablado de inventario, tenemos otros materiales sobre eso. Podemos decirte: toma esto, asegúrate de que esta pieza y esta herramienta estén en ese lugar a esa hora, y que Simon vaya allí y trabaje durante esta cantidad de tiempo, comenzando a esta hora y terminando a esa hora. ¿Es eso lo que estás diciendo?
Simon Schalit: Sí, eso es prácticamente lo que estamos diciendo. Pero de hecho, si tomas el problema en su totalidad, hay, diría yo, dos elementos que por separado podrían considerarse así, que no son fáciles y, de hecho, son casi imposibles de hacer correctamente sin la ayuda de la computadora. Está la parte de las apuestas, es decir, entender las consecuencias de tus apuestas, y está la parte de la organización, la reubicación, la planificación.
En el lado de las apuestas, se trata de entender la estrategia y hacer que las cosas tengan que ver con el dinero. Una imagen muy simple que usé un poco antes: los humanos, cuando tienen que hacer esas apuestas, confiarán en su conocimiento, en su corazonada. Básicamente, actuarán como un jugador en el casino con todos los sesgos que conlleva y todas las emociones asociadas. Si recientemente han tenido un problema con una pieza que causó una gran perturbación, lo más probable es que sobrecompren, sobreinviertan, coloquen un buffer muy grande en esa pieza porque se quemaron con ese caso en particular. Eso es un sesgo.
La máquina, si se afina correctamente, seguirá una estrategia exactamente como el casino. La misma apuesta, el mismo juego. Uno sigue una estrategia y gana; es el casino. Uno no sigue una estrategia, o al menos no una estrategia documentada y consistente; ese es el jugador, ese es el ser humano. En nuestro caso, el casino gana. El casino siempre gana. No es magia. Es comprender que existe, incluso si es difícil de calcular, una estrategia óptima, y no quieres desviarte de esta estrategia óptima.
Así que, en esta parte en particular, no es magia. Se trata de asegurarnos de extraer de la mente de las personas, de aquellas que son realmente buenas en este negocio, las ideas estratégicas clave y traducirlas en una estrategia dentro de la computadora. Eso es lo que hace un Supply Chain Scientist. No es magia. Es un proceso consistente de construir la estrategia.
La reorganización, no es magia. De nuevo, es una combinación de poder computacional y algunos trucos matemáticos. El poder computacional es accesible para la mayoría de las personas, especialmente si usas computación en la nube de la manera en que lo hacemos. Pero no somos los únicos; definitivamente, no somos los únicos. Muchas personas tienen acceso a un poder computacional incluso mayor, mucho más del que tenemos nosotros. Pero, usado correctamente, puedes resolver ese problema más algunos trucos.
Sin embargo, esos trucos no son puramente matemáticos. Son una combinación de aspectos matemáticos fundamentales, pero aplicados de una manera que tiene en cuenta la forma real del problema. Sí, podrías poner eso en un solucionador general muy grande, dejarlo correr durante horas y esperar obtener una buena solución al final. Probablemente, no vaya a funcionar, o incluso si lo hace, tomará demasiado tiempo. Lo que se busca es asegurarse de que el enfoque matemático esté hecho a la medida para el tipo de restricciones, el tipo de estructura que es específica de ese tipo particular de problema.
Conor Doherty: Bueno, lo que quería profundizar es un punto clave, que nuevamente se vincula con un mensaje más amplio que siento debe subrayarse sobre lo que Lokad intenta hacer. Dijiste que podrías tener, digamos, un practicante en la empresa cliente que obviamente tiene gran perspicacia. El objetivo es obtener esa información e incorporarla a la estrategia, digamos, al proceso de toma de decisiones, que es el algoritmo que produce las decisiones.
La razón de eso es, claro, creo que estarías de acuerdo, y corrígeme si me equivoco, que en cualquier elección o decisión, una persona realmente hábil podría ser tan buena o incluso mejor que un algoritmo, que un proceso automatizado de toma de decisiones. Sin embargo, cuando hablamos de la escala de complejidad al reparar un avión entero o una flota de aviones, posiblemente cientos de miles de piezas, cientos de herramientas, cientos de personas, la idea de que una persona podrá tomar todas esas decisiones a escala mejor que un proceso automatizado de toma de decisiones es simplemente irrazonable. Ese es el adjetivo que uso: irrazonable.
Simon Schalit: Una persona o incluso un equipo.
Conor Doherty: Un equipo, exactamente.
Simon Schalit: La mente humana no está hecha para eso. Y aprovecharé esta oportunidad para abordar algo como esta especie de dualidad entre la computadora y el ser humano. Si fuera a usar la palabra de moda IA, es simplemente una herramienta. Es una herramienta, nada más. El verdadero desafío cuando construimos esos algoritmos es extraer el conocimiento de la mente humana. Lo que me gusta decir es que la mente humana es extremadamente buena en estrategia, pero a nivel táctico, a un nivel más granular, se pierde.
Se pierde debido al mero número de cosas, y se pierde porque, más allá de cierto número de variables, especialmente si no son continuas, no lineales, podrías ser el mejor matemático del mundo, pero no vas a resolver eso en tu cabeza. Eso no es posible. No es cuestión de quién eres; los humanos simplemente no pueden hacer eso. Va más allá de lo que puedes hacer sin la herramienta. Pero los humanos son increíblemente buenos para elaborar estrategias a un nivel superior, entendiendo las consecuencias financieras de las cosas.
En última instancia, son ellos quienes deciden en qué dirección debe ir la empresa, cuán importante es que la empresa pueda atender a sus clientes de cierta manera con una fiabilidad determinada, en comparación con el costo. Tienen una idea de cuáles son esos números. El problema es que no saben que tienen una idea. Tienen corazonadas, y esas corazonadas les han llevado a decir, “Quiero altos niveles de servicio.” Si les preguntaras por qué quieren altos niveles de servicio, dirán que es importante.
Una de las principales cosas que un Supply Chain Scientist necesita hacer es lograr que expliquen por qué es importante. Si es importante, significa que piensas que tu costo de estar faltante de stock es alto. Vamos más allá. ¿Qué significa, alto en dólares, en euros, en términos financieros? Una vez que has extraído ese conocimiento, puedes usarlo para implementar la estrategia, la estrategia óptima de la que hablaba, optimizada en el sentido de que tomará la decisión óptima considerando la información estratégica que se le proporcionó.
En este caso, se generará la secuencia de acciones y la asignación de recursos que mejor se adapte para lograr los objetivos que se establecieron a nivel estratégico. Eso es lo que hace la computadora. No inventa nada. No deja a los humanos sin utilidad, pero hará lo que la mente humana no puede.
Conor Doherty: Transición perfecta. Entonces, sobre ese tema, anteriormente he asistido a conferencias y ferias MRO. Uno de los modelos que tenemos para nuestros pósteres en un stand es una mano directamente sobre un bote de basura de papel, una cesta, y simplemente está dejando caer trozos de papel arrugado en él. En estos pedazos de papel hay ciertos términos, y lo adaptamos dependiendo de si estamos en un evento de retail o aeroespacial. En este evento, teníamos FIFO y Min-Max, Safety Stock en los papeles que caían en el bote. Es algo provocativo.
Obviamente, la gente se acerca, y si lo entienden, comentan al respecto. Pero también, funciona porque, si en realidad no saben que somos algo críticos respecto a estos conceptos, se acercan y dicen, “Oh, hey, me interesa eso. ¿Puedes contarnos más?”
Simon Schalit: Sí.
Conor Doherty: Ahora, la cuestión es que a mucha gente realmente le gusta FIFO. Esa es la de la que más hemos escuchado. Cuando hablaste, mencionaste anteriormente tener soluciones en emergencias que funcionen rápido. Es críticamente importante trabajar rápido. Entonces, la pregunta, si tuviera que representar a alguien que simplemente no está de acuerdo contigo, podría decir, “Bueno, ya tengo una heurística. Ya tengo un solucionador general de toma de decisiones, un solucionador muy básico que funciona super rápido en tiempo real, y eso es FIFO, first in, first out.” ¿Qué le dirías a eso?
Simon Schalit: Bueno, FIFO es definitivamente un algoritmo que ha existido durante mucho tiempo. De hecho, diría que es nuestro mayor competidor en el mercado. El problema con FIFO es que, sí, funciona super rápido, y sí, es muy fácil de comprender para los seres humanos porque, quiero decir, first in, first out, ¿qué puede ser más sencillo que eso? Además, la buena ventaja es que parece tener sentido. Si algo llegó primero, quieres ocuparte de eso primero, porque probablemente sea el que tiene más probabilidad de retrasarse si, en conjunto, todo es igual y debería tomar la misma cantidad de tiempo.
Sin embargo, como ocurre con muchos conceptos pasados de moda en supply chain, no necesariamente son malos, solo un poco anticuados, se basa en algunas suposiciones. La primera suposición es que te encuentras en un ambiente simple. ¿Qué quiero decir con eso? Si trabajas usando FIFO, es first in, first out. La suposición es que cada motor, cada avión en el que trabajas, si seguimos en aeronáutica, es perfectamente intercambiable. En el sentido de que son iguales financieramente desde el punto de vista de la empresa, desde el punto de vista estratégico, simplemente son lo mismo. Desde una perspectiva de gestión de riesgos, todos son iguales. Llegar tarde en uno o en otro es exactamente lo mismo.
¿Es cierto en la realidad? Absolutamente no. Tienes diferentes clientes, tienes diferentes tipos de aviones, así que no será lo mismo. Un día de retraso en uno de ellos no es lo mismo que un día de retraso en otro. Pero incluso si lo fuera, imaginemos un mundo perfecto donde solo atiendes un tipo de avión con un cliente.
El problema es que los esfuerzos que tendrás que invertir para resolver el problema que enfrentas en una aeronave o en un motor no son necesariamente los mismos y probablemente no sean iguales al esfuerzo que necesitas para resolver el problema en otro. Incluso si los motores son iguales, la lista de reparaciones, las cosas que necesitas hacer en esos motores, no es la misma. Incluso si lo fueran, las partes que están rotas en esos dos no son exactamente idénticas. Esa es parte de la incertidumbre que tienes cuando abres un motor. Descubres lo que está roto, lo que está corroído.
Conor Doherty: No sabía que eso iba a estar allí.
Simon Schalit: Exactamente. Así que decir, “Oh, voy a concentrarme en el motor A porque llegó antes que el motor B,” realmente no tiene sentido. Lo más probable es que, incluso si dedicases todo tu esfuerzo al motor A, te tomaría mucho tiempo finalmente arreglar el problema. Mientras que, quizás en el motor B, puedas solucionarlo muy rápidamente.
Sí, podrías decir, “Todavía estoy avanzando en el motor A,” pero si terminas el motor B, ya está fuera de tu taller. Así que tienes espacio para que llegue otro motor, tienes espacio para que este motor sea inspeccionado y sepas de antemano lo que vas a necesitar para él. Has atendido a uno de tus clientes, por lo que potencialmente vas a recibir dinero por ello más temprano, lo cual te ayudará a financiar el resto de tus operaciones.
Así que vas a tener consecuencias ligadas al orden en que haces las cosas. Cada minuto invertido en las diferentes actividades no tiene el mismo valor, porque no tiene las mismas consecuencias. No libera el mismo potencial.
FIFO es completamente ajeno a eso. FIFO es una visión simplista de tus cadenas de reparación o manufactura. No me malinterpretes, no es malo. Entre todas las soluciones que podrías usar sin las herramientas adecuadas, probablemente sea la mejor o al menos una de las mejores. Pero si lo piensas, no quieres simplificar demasiado el problema, especialmente considerando las consecuencias financieras que están en juego.
Conor Doherty: Por supuesto. Y, de nuevo, hemos tomado un ejemplo deliberadamente trivial solo para ilustrar el punto. Pero, por supuesto, no son solo dos procesos. Arreglar el motor A y arreglar el motor B son dos cronogramas o secuencias separados. Normalmente hay muchos más. Así que tienes que tabular en tu cabeza, o con una hoja de Excel, o simplemente usando el solucionador. Tienes que tener muy en cuenta muchas variables. Y el punto es que los costos son no lineales. No son necesariamente iguales, y debes ser consciente de ello o contar con algo que te proporcione información sobre las implicaciones financieras de trabajar en esto versus trabajar en aquello.
Simon Schalit: Y, por supuesto, está el simple problema de asignación en el que tienes el motor A y el motor B, y ambos necesitan la misma pieza. Si el motor A es más antiguo, por defecto, asignarías a motor A. Pero si, por alguna razón, el motor A necesita cinco piezas diferentes que faltan, mientras que el motor B solo necesita esa una pieza, hay un muy buen argumento para que la pieza deba ir al motor B. Porque es lo único que falta. Puede ir, mientras que la pieza única que tienes, si la colocas en el motor A, no hace nada porque aún faltan otras cuatro piezas. FIFO es ajeno a eso.
Conor Doherty: Bueno, de nuevo, y quiero subrayar rápidamente un punto que se hizo anteriormente. Donde sea posible, creo que es importante señalar cuáles son nuestras posiciones. Y ciertamente, nunca he dicho esto públicamente o en privado: aplicar FIFO no es tonto ni ingenuo ni nada por el estilo. En muchos casos, de nuevo, es la mente humana abordando el problema y, a menudo, utilizando las mejores herramientas disponibles. En ausencia de herramientas, posiblemente superiores, las personas optan por lo que al menos es comprensible y lo que a primera vista parece funcionar.
Mi entendimiento, basado en esta larga conversación, es que el diagnóstico de valor base a menudo es muy limitado en términos de alcance financiero. Lo que quiero decir con eso es: “Bueno, el motor se ha caído, se ha agregado valor financiero, o se ha añadido valor, eso ya está.” Y una percepción clave que pareces estar explicando hoy es que existen tanto consideraciones financieras directas como indirectas mayores que, seamos honestos, la mente humana es simplemente ciega a ellas por naturaleza. Hablaste sobre la naturaleza del diseño. Por naturaleza, simplemente no puede comprender a escala las a menudo no linealidades y las consecuencias financieras externas de la toma de decisiones. Lo que nos lleva de vuelta al uso de la automatización, al uso de un Supply Chain Scientist que sea capaz de extraer esta información y convertirla en un motor de decisiones repetible.
Simon Schalit: Sí, bueno, nuestra posición sobre esto es bastante clara. El futuro de la toma de decisiones en supply chain se trata de la automatización. Y cuanto más complejos sean los contextos, más importante se vuelve. Para nosotros, ese es precisamente el camino que seguimos.
Conor Doherty: Para concluir, para las personas que están escuchando y han oído algunas afirmaciones increíbles, afirmaciones increíblemente precisas y con consecuencias importantes sobre lo que se puede hacer, para alguien que aún piensa, “Simon, lo que estás describiendo es inverosímil, es mágico, es imposible,” ¿cuál sería tu respuesta de 30 segundos como pensamiento final?
Simon Schalit: Bueno, ya está sucediendo. Es algo que ha estado ocurriendo durante los últimos años, y esa es la dirección hacia la que se dirige la supply chain en general. Automatización a escala y automatización a niveles cada vez más bajos de granularidad. ¿Por qué? Porque tenemos la potencia computacional y, gracias a supply chain scientists, el concepto y el rol de supply chain scientists. Tenemos la capacidad de aportar los datos e información necesarios, información estratégica y financiera, al algoritmo, a la computadora, para que la estrategia que se aplica a escala sea la que es diseñada por humanos y pueda ser optimizada hacia ese objetivo.
Conor Doherty: También mencionaste antes, en respuesta a una pregunta muy similar, en realidad, no recuerdo cuál fue el contexto, pero dijiste sobre este tema que la incredulidad de la gente o que la gente no cree que sea posible es sorprendente, considerando que esto es efectivamente lo que la gente está tratando de hacer en tiempo real. Así que cualquier persona, nuevamente, un tomador de decisiones clave, un stakeholder clave, un lunes por la mañana necesita revisar el calendario porque Simon y Conor están ausentes. Lo que están haciendo en tiempo real es lo que estamos describiendo usando una computadora, usando algoritmos. Esencialmente, es el mismo proceso. Estás buscando una solución optimizada. Así que no es magia, es solo la intervención tecnológica en ese proceso.
Simon Schalit: Sí, lo están haciendo a mano. Lo están haciendo de una manera muy dolorosa, digamos. Dolorosa para ellos y, en cierta medida, dolorosa para la empresa porque no están llegando a una solución optimizada, no por falta de habilidad, sino por falta de herramientas. Y por eso lo que estamos aportando es la herramienta necesaria para reemplazar realmente el elemento humano que es deficiente a nivel granular y conservar el elemento humano que es ideal, que es el nivel estratégico. Así que combinamos el nivel granular de la computadora y el nivel estratégico del humano.
Conor Doherty: Simon, muchas gracias por tu tiempo. No tengo más preguntas. Ha sido un placer.
Simon Schalit: Para mí también. Gracias de nuevo por tu tiempo y gracias a todos por ver.
