00:00:00 Introducción a las complejidades de la programación
00:02:30 Interdependencia y desafíos de nivel de servicio en el sector aeroespacial
00:06:14 Discusión sobre la Lista de Materiales y Recursos
00:13:15 Desafíos diarios de programación y limitaciones humanas
00:20:45 Introducció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 Aprovechando el poder computacional para la optimización de la programación
00:57:39 Crítica a las limitaciones de FIFO en MRO
01:04:15 Toma de decisiones y automatización en la cadena de suministro
Resumen
En una entrevista reciente, Conor Doherty, Director de Comunicación de Lokad, y Simon Schalit, COO, discutieron el avance de Lokad en la optimización de la programación para el sector aeroespacial, especialmente en la fabricación de aeronaves y las operaciones de MRO. Destacaron la complejidad de coordinar numerosas partes, habilidades y equipos interdependientes, que los métodos tradicionales tienen dificultades para gestionar. El enfoque de Lokad se desplaza de una Lista de Materiales (BOM) a una Lista de Recursos (BOR), considerando todos los recursos necesarios y su variabilidad. Utilizando algoritmos computacionales, Lokad puede generar rápidamente soluciones prácticas, minimizando el riesgo financiero y el tiempo de inactividad. Esta integración de la automatización y las perspectivas estratégicas humanas es crucial para una programación eficiente y efectiva en entornos complejos.
Resumen Extendido
En una entrevista reciente en Lokad, Conor Doherty, Director de Comunicación, se sentó con Simon Schalit, COO y Jefe de Supply Chain Science, para adentrarse en las complejidades de la optimización de la programación, especialmente 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 escenario, enfatizando la naturaleza intrincada 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 manera 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 un motor de avión implica coordinar numerosas partes, habilidades y equipos. Destacó que a diferencia de otros segmentos de la cadena de suministro donde las decisiones a menudo se pueden tomar de forma independiente, en MRO y fabricación, especialmente en aeronáutica, cada elemento es interdependiente. La falta de una sola pieza de cien puede detener todo el proceso, volviendo inútiles las otras 99 piezas.
Simon explicó que esta interdependencia requiere un cambio de la perspectiva tradicional de la Lista de Materiales (BOM) a un enfoque más completo de la Lista de Recursos (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 variabilidad de cada recurso. Por ejemplo, las piezas pueden estar sujetas a variabilidad en el tiempo de entrega, 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 horarios en función de 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 horario pueden tener consecuencias impredecibles en cascada, 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 tiempo de inactividad es costoso. La fortaleza del algoritmo radica en su capacidad para simular varios “qué pasaría si” escenarios, 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 (Primero en entrar, primero en salir). Si bien FIFO es simple y rápido, no tiene en cuenta la importancia financiera y estratégica variable de diferentes tareas. Simon argumentó que se necesita un enfoque más matizado, que considere el contexto y las restricciones específicas de cada tarea, para una programación efectiva.
En conclusión, Simon y Conor destacaron la importancia de integrar herramientas computacionales con conocimientos estratégicos humanos. Si bien los humanos son excelentes en la planificación estratégica, no están equipados para manejar las complejidades granulares de la programación en operaciones a gran escala. Al aprovechar los algoritmos, las empresas pueden tomar decisiones de programación más eficientes y financieramente sólidas.
Simon concluyó afirmando que el futuro de la toma de decisiones en la cadena de suministro radica en la automatización, especialmente en entornos complejos como la industria aeroespacial. Él enfatizó que el enfoque de Lokad combina el poder computacional necesario para la toma de decisiones granulares con la supervisión estratégica proporcionada por expertos humanos, ofreciendo una solución sólida 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 tienes que gestionar una enorme red de piezas, herramientas y personas, y esa red puede cambiar en cualquier momento.
El invitado de hoy, Simon Schalit, es COO y Jefe de Ciencia de la Cadena de Suministro en Lokad, y se unió a mí en el estudio para discutir cómo su equipo abordó este problema. Ahora, él y yo hablamos principalmente sobre la programación en la industria aeroespacial, pero todo lo que discutimos hoy se aplica igualmente a cualquier industria de fabricación. Como siempre, si te gusta lo que escuchas, dale me gusta a este video, suscríbete al canal de YouTube y síguenos en LinkedIn. Y con eso, les 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 ciencia de la cadena de suministro ha realizado para lograr un avance en ese campo. Entonces, antes de adentrarnos en esos detalles, desde tu propia perspectiva, y puedes tomar la industria aeroespacial como ejemplo concreto para las personas, ¿cuál es exactamente el problema de programación que nuestro equipo de ingenieros, nuestro equipo de Supply Chain Scientists, está tratando de solucionar? ¿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 un gran segmento de un avión, digamos un motor, te enfrentas a algo que es increíblemente complejo. Complejo, por supuesto, desde una perspectiva de ingeniería, pero también si consideras simplemente la cantidad de piezas, habilidades y equipos que necesitarás reunir para poder llevar a cabo la tarea que te han asignado, ya sea fabricación o reparación.
En la mayoría de los segmentos de la cadena de suministro, cuando tomas decisiones, podrías argumentar que las decisiones podrían considerarse independientes sin que este modo de pensar sea demasiado perjudicial. Por ejemplo, si decido comprar el artículo A y el artículo A está agotado, aún podré vender el artículo B o el artículo C. Puede haber consecuencias, pero en general, ese es el caso. Pensar de forma independiente no es demasiado perjudicial.
Cuando se trata de MRO o fabricación, especialmente en el entorno aeroespacial, eso se vuelve completamente falso. Si quieres ser capaz de reparar, digamos, un motor y necesitas 100 piezas para poder reparar ese motor, tener 99 de esas piezas y faltar una no te llevará más lejos que no tener absolutamente ninguna de esas piezas.
Conor Doherty: ¿A qué te refieres?
Simon Schalit: Porque el motor aún no puede… el avión aún no puede volar incluso si te falta solo una de esas piezas. Incluso si tienes 99 de ellas, el avión aún no puede volar. Entonces te enfrentas a un problema en el que no debes intentar tener cada pieza; necesitas tener todas las piezas y, de hecho, todos los recursos disponibles en el lugar correcto en el momento correcto. De lo contrario, simplemente no puedes hacer nada.
Y de hecho, eso cambia completamente el problema. Porque incluso si dijeras: “Bien, tengo un nivel de servicio del 99%”, que la mayoría de las personas en la mayoría de las empresas dirían: “Sí, eso es un nivel de servicio alto”. Si estás mirando un nivel de servicio del 99% de forma independiente, eso es bastante alto. Pero si dices: “Bien, necesito 100 piezas, y para esas 100 piezas, voy a tener un nivel de servicio del 99% para cada una de ellas individualmente”, es decir, una probabilidad del 99% de que estén allí en el momento en que las espero, de hecho, si dijeras que son independientes, el nivel de servicio combinado de este caso muy simple sería en realidad extremadamente bajo. Sería inferior al 40%.
Entonces significa que incluso con un nivel de servicio del 99%, si necesitas 100 piezas o recursos diferentes para estar disponibles, la posibilidad de que no puedas llevar a cabo tu reparación o tu paso de fabricación en realidad no es un accidente; se convierte en la norma. Tiene más del 50% de probabilidad de que realmente suceda. Por lo tanto, eso te sitúa en un mundo que es extremadamente diferente a tu toma de decisiones habitual en la cadena de suministro. 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 cadenas de suministro y tu proceso de toma de decisiones en la cadena de suministro para que sean resilientes ante esto. Así que ese es un tema muy diferente en su totalidad.
Conor Doherty: De acuerdo, gracias. Y mencionaste algunos términos allí, y solo quiero separarlos un poco porque hablaste de piezas y luego comenzaste a hablar de recursos. Ahora, supongo que no los estabas usando como sinónimos; estabas haciendo una distinción allí. Entonces, ¿podrías proporcionar un poco más de claridad allí? Cuando dices recursos, no estás hablando puramente de piezas físicas. Nuevamente, 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, las personas se referirán al concepto de una lista de materiales. Una lista de materiales es básicamente la lista de piezas que necesitas reunir para terminar algo: un avión, un motor, lo que sea. El problema es que esto es solo parte del problema. Vas a necesitar otros tipos de recursos para llevar a cabo la tarea.
Principalmente, esos recursos van a ser habilidades que provienen de las personas y equipos que van a ser cosas que no necesariamente consumes, pero que vas a usar. Y muy a menudo, pueden ser bastante costosos y no tienes una cantidad infinita de ellos, como un banco de pruebas, por ejemplo, si estás hablando de aeronáutica. Por lo tanto, no es suficiente tener todas las piezas disponibles. Vas a necesitar asegurarte de tener el equipo, el banco de pruebas, la grúa, lo que sea, y las personas para operar y ensamblar las piezas de manera segura y técnicamente válida.
Entonces, cuando hablamos del problema de esas listas de materiales y cómo se utilizan, preferimos referirnos a un concepto de lista de recursos, que es más preciso en el sentido de que abarca el problema en su totalidad en lugar de solo los materiales.
Conor Doherty: De acuerdo, ahora que has reintroducido el término lista de materiales, que supongo que cualquiera que esté viendo esto probablemente esté familiarizado, la perspectiva de la lista de recursos, ¿puedes contrastar esas dos en términos concretos? Entonces, toma una decisión, esboza una decisión, por ejemplo, para un MRO utilizando un avión solo para simplificar, y explica cómo se desarrollaría una perspectiva de BOM en tiempo real versus una perspectiva de lista de recursos más sofisticada.
Simon Schalit: De acuerdo, por favor. Por lo general, la actividad de MRO o la actividad de fabricación sigue diferentes pasos que deben realizarse en un cierto orden. Las cosas deben hacerse antes, las cosas deben hacerse después. Pero cada paso se puede definir con su propia lista de recursos, lo que significa la lista de piezas que necesitas para llevar a cabo este paso de reparación en particular, la lista de habilidades, no de personas, porque puedes tener diferentes personas con diferentes habilidades, la lista de habilidades necesarias para llevar a cabo, y la lista de equipos.
Por lo general, las piezas se consumirán en el sentido de que se montarán. 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 una perspectiva de tiempo durante un cierto período de tiempo. Lo mismo ocurre con los equipos. Los tres elementos, piezas, habilidades y equipos, vienen con su propio conjunto de variabilidades.
Las variabilidades de las piezas generalmente son si están en stock o no, que es una forma simple de decirlo. Detrás de eso se encuentra el concepto de variabilidades de tiempo de entrega, en su mayoría, 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 está asociada a la habilidad proviene de si la persona estará presente y disponible, pero principalmente presente para llevar a cabo la tarea. Por lo tanto, viene con todas las variabilidades que están 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 en realidad, ese es el tipo de variabilidad que es aún más difícil de comprender y controlar que el tiempo de entrega porque no puedes obligar a alguien a no estar enfermo. Si la persona está enferma, está enferma.
Y, por supuesto, está la disponibilidad del equipo, que nuevamente se consume durante un cierto período de tiempo, pero que, por supuesto, es menos probable que esté enfermo. Lo equivalente sería estar roto, en reparación o tal vez aún atrapado en otro motor o avión que está siendo reparado y aún no se ha liberado de esa tarea en particular. Entonces, 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, en ese sentido, nuevamente, para tomar un ejemplo concreto, y nuevamente, podemos comparar cómo un MRO tradicional con una perspectiva de lista de materiales y luego, digamos, uno de nuestros clientes con una perspectiva de lista de recursos, podemos contrastar cómo abordarían un escenario. Estamos tratando de arreglar, 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 de BOM. Entonces, nuevamente, una perspectiva física determinista de BOM. Sé cuántas piezas necesito, 100 piezas para arreglar ese motor. Llegas el lunes por la mañana, tenemos todas las piezas. Simon y Connor están ausentes. Como, Simon está enseñando algo, Connor se lastimó la espalda levantando algo pesado, así que no estamos disponibles.
Entonces tienes todas las piezas, así que en esa parte de la ecuación tienes suerte. Tienes las 100 piezas. En realidad, tienes todas las herramientas, tal vez se necesiten 20 herramientas, digamos 20 herramientas. Entonces tienes 100 piezas, tienes las 20 herramientas, pero te faltan las habilidades críticas. Y ni siquiera todas las habilidades, solo Simon para adjuntar una cierta pieza, necesitas una licencia para hacer eso, y Connor para supervisar. Entonces, ¿qué sucede allí en términos de decisiones si tienes una perspectiva de lista de recursos?
Simon Schalit: No es tener la lista de recursos lo que 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 qué tan probable es que ocurra un incidente como el que acabas de describir. Necesitas organizarte de una manera que pueda hacer frente a ese tipo de problema.
Pero tomemos tu ejemplo. Digamos que tenemos todas las piezas, tenemos todo el equipo, pero las personas simplemente no están allí, lo cual es bastante frecuente por muchas razones. Actualmente, la forma en que las personas hacen frente a eso es que cada mañana en el taller, digamos que estamos hablando de un gran taller que hace reparaciones, cada mañana y tal vez incluso dos veces al día, las personas a cargo de las diferentes líneas de reparación se reunirán y tratarán de reconstruir el horario para el día.
Verán qué falta, ya sea piezas o personas, y dirán: “Ok, 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 seres humanos y no tenemos mucho tiempo? ¿Cuál es la cantidad mínima de cambios que podemos hacer en el horario para que sea viable y no se aleje demasiado del objetivo que teníamos para el día?”
El problema es que esta lógica, esta especie de lógica de esfuerzo mínimo, no funciona muy bien. Eso es lo que la gente hace porque no necesariamente tienen otra cosa a su disposición, pero no funciona muy bien por una razón muy simple.
Cambiar un poco el plan deriva de la idea de que en una situación simple, esos cambios mínimos tendrán consecuencias mínimas porque hay cierta continuidad o linealidad en la cantidad de consecuencias en comparación con la cantidad de cambios que haces. Existe esta especie de suposición, por lo que haces cambios mínimos porque eso no es demasiado complejo y esperas que no tenga muchas consecuencias.
El problema es que cuando hablamos de programación, estamos hablando de reorganizar potencialmente decenas, si no cientos, de actividades diferentes, cada una con sus propias restricciones y variabilidad asociada. Entonces, la idea de que haya 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 solo un plan que funciona.
Conor Doherty: Permíteme intentar reflejarlo y me corriges si he entendido mal porque es un punto muy interesante. Antes, hablé de Simon y Conor ausentes y la necesidad de trabajar en el motor A. Digamos que Joannis, con un bolígrafo y papel o una hoja de cálculo de Excel, dice: “Bueno, Max, nuestro ingeniero que también es nuestro camarógrafo detrás de la cámara, en realidad tiene las habilidades que Simon y Conor tienen. Solo lo sacaré de lo que iba a hacer. Sí, puede trabajar en el motor A. Problema resuelto”. Entonces, simplemente muevo a una persona, algo sencillo.
¿Pero es posible que hacer eso realmente introduzca consecuencias desproporcionadas? Porque con la misma cantidad de tiempo que Max tarda en 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 esa combinación tiene un mayor retorno 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 deben 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 realizado, sino que todo lo que habías planeado que debía suceder después bajo la condición de que la tarea A se haya realizado no puede suceder.
Entonces, si sacas a alguien de otra cosa y le dices: “Haz la tarea A”, podrás hacer B, C y D. Pero el problema es que esta persona debía hacer otra cosa, que no se va a hacer 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 qué efecto mariposa tiene el mayor impacto financiero y qué opción debo 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é cerca de ser óptimo es simplemente ridículo.
Conor Doherty: Quiero tener mucho cuidado con cómo nos presentamos aquí porque el mensaje no es que las personas sean tontas. Mi comprensión de esto, después de haber asistido a conferencias de MRO, es que estamos tratando con personas muy inteligentes y talentosas. Simplemente 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 los cuales tiene impactos financieros, varias veces al día, todos los días, para una compañía aeroespacial multimillonaria. Esa es una propuesta irrazonable. ¿Tu propuesta no es hacer eso sino hacer algo diferente?
Simon Schalit: Sí, tienes razón. Es necesario señalar que las personas han estado haciendo eso por una buena razón. Primero, porque no había alternativa, y también porque confiaban en la suposición de que, sí, por supuesto, suceden problemas. Hay situaciones en las que tendrás que reorganizar todo, pero no sucederá con demasiada frecuencia. Para el resto de la cadena de suministro en general, sí, no sucede con demasiada frecuencia. Pero en este contexto particular, sucede todos los días. Ese es el problema. Por eso los humanos se sentirán abrumados, no porque sean incompetentes o tontos, sino simplemente porque los humanos no están preparados para manejar este problema.
Entonces, cómo proponemos hacerlo de manera diferente es, por supuesto, tener una máquina, una computadora, que lo haga, un algoritmo. No es algo nuevo. Este tipo de problema de organización ha sido abordado por las computadoras durante algún tiempo, especialmente con el aumento de la potencia computacional en las últimas décadas. El problema aquí es que te encuentras 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 generalmente no funcionan de manera muy satisfactoria y, lo que es aún más importante, no funcionan lo suficientemente rápido. Ahí es donde está el problema. Si le pides a una computadora que resuelva un problema como ese y si construyes un algoritmo lo suficientemente bueno, es probable que tengas una buena solución si dedicas suficiente tiempo y potencia computacional a ese problema en particular. Va a ser difícil; muchas soluciones ni siquiera llegan a este punto, pero se puede hacer.
El problema es que la situación en la que te encuentras es el lunes por la mañana. El taller necesita comenzar a trabajar si aún no lo están haciendo porque generalmente es, imaginemos, el lunes por la mañana. Necesitan reprogramar todo porque faltan ciertas partes y faltan ciertas personas. No tienes unas pocas horas por delante para resolver el problema; tienes unos pocos minutos porque necesitas ponerte en marcha. Cada minuto cuenta y en la aeronáutica, cada minuto es costoso. Entonces, necesitas resolver ese problema en unos pocos segundos o unos pocos minutos como máximo, y es un asunto muy urgente.
Ahí es donde se vuelve realmente difícil. Entonces, lo que hemos desarrollado es un algoritmo que nos va a permitir resolver ese problema de manera suficientemente buena. Es imposible demostrar que tu solución va a ser óptima, pero al menos es una solución muy buena en comparación con otras soluciones que podrías encontrar, y donde puedes demostrar que, en términos financieros, vas a tener una solución muy buena en cuestión de minutos. Nuestros clientes suelen ser bastante estrictos en cuanto al número de minutos que tenemos para resolver el problema.
La idea detrás de esto, no voy a entrar en los detalles de las matemáticas y las computadoras, pero se trata de utilizar la capacidad de la computadora y confiar en el hecho de que lo que estás buscando no es la solución en sí misma, sino cómo estructuras el solucionador que va a ser capaz de resolver el problema en unos pocos minutos. En realidad, eso es una especie de problema meta. Sería muy interesante hablar de eso durante horas, pero no tenemos tiempo ahora. La clave es que no quieres encontrar la solución; quieres encontrar el solucionador que va a encontrar la solución basándose en la solución ideal anterior que has tenido tiempo de calcular durante la noche o cuando tenías más tiempo.
Conor Doherty: Desde la perspectiva del cliente, quieren la solución, quieren que se genere la nueva secuencia lo más rápido posible. Solo quiero profundizar un poco en un punto que mencionaste porque desde la perspectiva de gestionar las expectativas en esta conversación, no estamos presentando la idea de que siempre tendrás en seis minutos, creo, o de tres a seis minutos, puedes regenerar un enorme cronograma de operaciones para, digamos, reparar un motor para 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 pasaste 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: Haciendo esta nueva secuencia de eventos con estos recursos disponibles, se obtiene un resultado específico en términos financieros.
Simon Schalit: Sí, está bien, eso es exactamente lo que hacemos y lo que también quieres porque eso es algo necesario. No solo quieres regenerar un cronograma, también quieres darle a tus clientes la posibilidad de cambiar la realidad de alguna manera. Eso es lo que llamarías un escenario de “qué pasaría si”.
Por ejemplo, si una persona falta hoy, vamos a llegar tarde. Puedo encontrar una buena solución, pero la buena solución que encuentro todavía me deja una persona menos, así que no va a ser mejor que lo que tenía con esa persona adicional. Todo va a estar un poco retrasado. Entonces, quiero darle a mi cliente la posibilidad de generar un escenario donde él diga: “Ok, me faltó una persona hoy. Necesito recuperar el tiempo perdido. Tal vez podría agregar a alguien además de mi horario regular mañana o tal vez abrir un día adicional donde el taller se suponía que estaría cerrado”. Quiero saber qué pasaría, cuánto tiempo ganaría si abriera un sábado, por ejemplo, donde el taller podría estar cerrado regularmente.
Entonces, quieres que la herramienta sea capaz, por supuesto, de simular lo que realmente está sucediendo porque eso es probablemente 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 entiendan cuáles serían las consecuencias de estas medidas de emergencia porque estas medidas de emergencia se llaman así por una razón. No recurres a ese tipo de cosas para tu actividad regular porque cuestan dinero. Por lo general, cuestan mucho dinero. Por eso no las usas regularmente.
Conor Doherty: Por ejemplo, precios AOG para obtener piezas en el último momento.
Simon Schalit: Exactamente, es como si te faltara una pieza y eso causara una parada de trabajo, el precio que estás dispuesto a pagar por esa pieza en particular puede ser muy alto. Es algo que, por supuesto, es cierto en la industria aeronáutica y es algo que es 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: Exactamente. Entonces, lo que quieres es darle al cliente una estimación de la ganancia para que puedan tener eso en cuenta al considerar el costo de esa medida de emergencia y tomar una decisión informada sobre si recurrir a esa medida de emergencia tiene sentido desde una perspectiva financiera. Necesitan saber eso para tomar la decisión y documentarla para defender esa decisión dentro de la empresa. Porque cuando recurres a medidas de emergencia costosas, vas a tener que rendir cuentas a tu jefe o a la empresa en general.
Conor Doherty: Nuevamente, quiero ser muy cuidadoso con el lenguaje aquí. Has mencionado escenarios de emergencia de “qué pasaría si”, pero antes en la conversación, hablaste sobre la percepción de las emergencias y cómo eso está un poco distorsionado. La comprensión de las personas de lo que constituye una emergencia es un poco ingenua tal vez. Entonces, ¿podrías separar eso?
Cuando hablamos de producir o reparar un APU o fabricar un APU, estamos hablando de muchas piezas, muchas herramientas y muchas personas. Si estamos hablando 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 falta un elemento de la lista de recursos, dada la escala de los recursos de los que estamos hablando, ¿es “emergencia” el término correcto para reflejar algo que seguramente sucede bastante o que al menos es probabilísticamente muy probable?
Simon Schalit: Sí, bueno, hay una cosa que debemos entender. Si estamos hablando de aeronáutica, la aeronáutica es, por naturaleza o por diseño, una industria muy aversa al riesgo por muy buenas razones. El problema es que en la cadena de suministro, cada decisión que tomas, sin excepción, es una apuesta. Estás apostando que el futuro no va a ser demasiado diferente de lo que esperas que sea. Realizas tus apuestas en base a esta suposición.
Esta apuesta puede ser arriesgada o no arriesgada, y podríamos entrar en esta metáfora de la apuesta donde quieres actuar más como el casino que como el jugador. Pero en esencia, la parte importante es que cuando se trata de la programación, el contexto del que estábamos hablando, la apuesta que estás haciendo sobre el futuro es extremadamente compleja. La idea de que el futuro se va a desarrollar exactamente como esperabas o como estaba planeado no es realista. No va a suceder como lo planeas.
Conor Doherty: Perdóname por interrumpirte, pero 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 desde ahí.
Simon Schalit: Sí, vas a planificar todos tus recursos en base a la suposición de que esos recursos van a estar ahí. Planificaste una secuencia de eventos que en teoría deberían encajar. Pero dada la gran cantidad, 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 todas las cosas estén realmente allí en el lugar correcto y en el momento correcto simultáneamente es inferior al 40%. Entonces, no va a suceder.
El problema es que, dado que las empresas son aversas al riesgo, el reflejo que tienen es decir: “Ok, si un nivel de servicio del 99% no es suficientemente alto, voy a ir más alto”. Cuando hablas de piezas, lo que quieres decir con un nivel de servicio del 99% es que vas a hacer pedidos de piezas para que lleguen antes, incluso antes, solo para tener en cuenta la variabilidad en el tiempo de entrega, el tiempo que tardan las piezas en llegar realmente. Porque esa es la principal incertidumbre que tienes con las piezas.
Entonces, vas a tomar más y más margen hasta llegar del 99% al nivel de servicio del 99.9%. Excepto si necesitas 100 piezas o más de 100 piezas, la cantidad de dinero que necesitarías para poder llegar a un nivel de servicio combinado que sea satisfactorio es algo que no puedes permitirte. Entonces, el enfoque tradicional de decir: “Voy a aumentar el nivel de servicio hasta el punto en que me sienta cómodo y eso garantizará que pueda llevar a cabo el plan que he ideado”, no es necesariamente una forma válida de trabajar.
Por supuesto, vas a necesitar niveles de servicio altos porque se trata de aeronáutica. Pero lo que vas a necesitar es una forma de cambiar tu plan de la manera más eficiente y rentable que garantice que el nuevo plan que tienes que idear sobre la marcha sea el mejor plan que puedas diseñar en base a la información que tienes. De hecho, eso marca una gran diferencia en comparación con simplemente pensar que las cosas van a salir según lo planeado y tener humanos todas las mañanas sin las herramientas correctas tratando de idear un nuevo plan.
Conor Doherty: Entonces, nuevamente, para resumir eso, el argumento que estás haciendo es que cuando lo tomas, y no vamos a profundizar demasiado en las matemáticas, pero desde una perspectiva puramente matemática, cuando trazas o simplemente enumeras todas las piezas físicas que necesitas, todas las herramientas físicas que necesitas, y luego todas las habilidades abstractas o personas físicas necesarias para completar una secuencia de acciones, y también consideras que ninguna de estas cosas sucede de forma aislada. Quiero decir, no reparas un solo motor y luego estas personas se van a casa. Trabajan en otra cosa. Hay una naturaleza interconectada en todas estas secuencias.
Entonces, cuando llegas el lunes por la mañana, matemáticamente, la probabilidad de que falte algo 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 te mueves tratando de descubrir qué hacer a continuación, a dónde ir, quién está aquí, qué está disponible, etc., trabajando, enviando hojas de cálculo de Excel, todo eso tiene consecuencias financieras significativas e inmediatas. ¿He entendido correctamente?
Simon Schalit: Correcto, y también agregaría que es el tiempo que pierdes reorganizando el plan y el tiempo perdido al seguir un nuevo plan que está lejos de ser óptimo. Por lo general, esta segunda parte no es tan dolorosa porque es un poco más difícil de cuantificar, pero en realidad es muy, muy costosa. Debes imaginar que cuando se trata de actividades de MRO o 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 generando dinero. Entonces, incluso un pequeño aumento en la eficiencia de tu capacidad para hacer nuevos planes sobre la marcha puede tener un tremendo impacto desde una perspectiva financiera.
Conor Doherty: También me doy cuenta, y acabas de decir eso, acabo de tomar nota. Hemos estado hablando principalmente sobre las implicaciones directas, como la consecuencia directa inmediata de que la persona falte, es decir, esa parte del motor no se repara. Pero indirectamente, también hay un efecto dominó no solo en los otros procesos porque muchas veces, seamos realistas, esto no ocurre en el vacío. Pasas de uno a otro, o esta parte se agrega a esta parte nuevamente. Las subensamblajes de la lista de materiales hacen las partes más grandes por completo. Pero también hay obligaciones contractuales que deben considerarse. Quiero decir, si no logras devolver un avión a circulación, dependiendo de si eres un MRO, eso también tiene consecuencias financieras.
Entonces hay consecuencias directas, hay consecuencias indirectas, pero nuevamente, la idea principal aquí es que hay cientos, si no miles, de decisiones que intervienen en un horario ó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, todavía es probable que suceda al día siguiente o al día siguiente o al día siguiente. Esto conlleva costos financieros.
Simon Schalit: Sí, y en realidad, en la práctica, seamos muy prácticos aquí. En el trabajo diario, lo que he presenciado en esas empresas es que el ejercicio de hacer un nuevo plan lleva tanto tiempo y es tan difícil que el taller se enfocará solo en el problema que conocen hoy. No tienen tiempo para nada más. Entonces, lo que sucede es que al día siguiente, existen nuevos problemas, como problemas antiguos que aún no se han solucionado, más nuevos problemas.
Pero si observas los detalles de los nuevos problemas, la mitad de ellos podrías haberlos conocido el día anterior. Podrían haber sido predichos. Pero en la práctica, lo que hemos presenciado es que las personas están tan enfocadas en el problema que tienen que resolver hoy que no necesariamente tienen el tiempo o la capacidad intelectual para poder anticipar los problemas de los próximos días, lo que puede hacer que los problemas sean cada vez más grandes con el tiempo y generalmente conduce a retrasos acumulados en las actividades de MRO o actividades de fabricación. Por supuesto, las infracciones contractuales en sus obligaciones contractuales.
Conor Doherty: Nuevamente, ese es un punto muy válido porque al igual que los procesos no ocurren de forma aislada, las externalidades o simplemente las consecuencias de las acciones no ocurren en el vacío. Entonces, nuevamente, la acumulación de la lista de pendientes y, por extensión, el impacto financiero continúa en segundo plano, ya sea que estés dispuesto a reconocerlo, pensarlo o actuar al respecto. Incluso si actúas al respecto y piensas “he resuelto ese problema”, en segundo plano, porque hay una variable que te perdiste, porque nuevamente, soy humano, eres humano, somos humanos, el libro mayor, la factura, el medidor sigue funcionando en segundo plano. Es posible que ni siquiera sepas que está sucediendo.
Bueno, avancemos un poco más porque en cuanto a los detalles de la optimización de la programación, como lo vemos, hemos hablado de los aspectos del inventario de las piezas, herramientas. Cuando hablas de las habilidades, ¿simplemente estás… permíteme reformular esta pregunta. ¿Las decisiones tal como las presentamos a los clientes, simplemente se trata, por ejemplo, de tomar esa pieza, esa herramienta y enviar a Simon allí para trabajar en ese motor, o es un poco más complejo que eso?
Simon Schalit: Bueno, va a ser un poco más complejo en el sentido de que generalmente viene con un conjunto completo 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 debe asignarse a ese avión o 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 en particular durante este período de tiempo. El sistema debe garantizar que no violamos ninguna de las restricciones establecidas para cada una de las tareas que vamos a realizar.
En cuanto a la complejidad, si hablamos de las piezas, generalmente eso es bastante simple. 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. Entonces, generalmente, puedes intercambiar cuando sea posible, pero decides cuándo asignar y tratas de asignar en el último minuto posible para evitar la reasignación. Pero esa es la parte simple. Curiosamente, esa es en la que las personas se enfocarán más porque generalmente sienten que tienen más control sobre ella.
Pero para la asignación de personas y equipos, generalmente van juntos, 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ás diferentes habilidades de diferentes personas al mismo tiempo, ya sea por motivos técnicos o simplemente por motivos de seguridad. Simplemente operar una grúa cuando estás moviendo un motor en medio del taller requiere al menos dos personas, solo por razones de seguridad. Uno que pueda operar la grúa y otro que esté allí solo para asegurarse de que no estemos haciendo nada mal y de que el camino esté despejado. Como mínimo, eso es lo que sucedería.
Entonces no puedes pensar en todos esos recursos, especialmente los recursos calificados, como entidades completamente independientes. Eso sería demasiado fácil. La mayoría de las veces, quieres pensar en ellos como si vinieran con restricciones donde necesitan estar disponibles en el mismo lugar al mismo tiempo para la misma tarea. Y tienes una opción donde las tareas pueden ser realizadas por una, dos, tres, cuatro personas al mismo tiempo, 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 estás consumiendo esas habilidades, no están presentes en otro lugar.
Eso hace que el problema sea bastante difícil. Para hacer la tarea A, si necesitas dos personas, necesitas que estén disponibles en un momento determinado. Entonces, lo que sea que estuvieran haciendo, necesitan terminar aproximadamente al mismo tiempo para que ambos puedan estar disponibles para pasar a esa tarea en particular. Y eso en realidad no es trivial porque la mayoría de las veces, uno de ellos probablemente estará esperando a que el otro termine, y eso cuesta bastante. Quieres evitar eso tanto como sea posible. Cada minuto cuenta. Esas habilidades valen mucho dinero.
Conor Doherty: Ok, y nuevamente, para alguien que escucha, puede sonar como magia. Soy consciente de eso porque lo que parece que estás diciendo es que Lokad ahora se enfoca en la programación. Ya hemos discutido sobre el inventario, tenemos otros materiales sobre eso. Podemos decirte, toma esto, asegúrate de que esta parte y esta herramienta estén en ese lugar en ese momento, y que Simon vaya allí y trabaje durante esta cantidad de tiempo comenzando en este momento y terminando en este momento. ¿Es eso lo que estás diciendo?
Simon Schalit: Sí, eso es más o menos lo que estamos diciendo. Pero de hecho, si tomas el problema en su conjunto, hay, diría, dos elementos que separados entre sí podrían considerarse así, no son fáciles y, de hecho, son casi imposibles para un ser humano hacerlo correctamente sin la ayuda de la computadora. Hay una parte de apuestas, como entender las consecuencias de tus apuestas, y hay una parte de arreglo, la parte de reorganización, la parte de planificación.
En el lado de las apuestas, tiene que ver con entender la estrategia y hacer las cosas en función del 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 intuición. Básicamente, actuarán como un jugador en el casino con todos los sesgos y emociones que eso conlleva. Si recientemente han tenido un problema con una pieza que causó una gran perturbación, es probable que compren en exceso, pongan un gran margen en esa pieza porque se quemaron con esa en particular. Eso es un sesgo.
La máquina, si está ajustada correctamente, seguirá una estrategia exactamente como el casino. Misma apuesta, 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 entender que hay, aunque sea difícil de calcular, una estrategia óptima, y no quieres desviarte de esta estrategia óptima.
Entonces, en esta parte en particular, no es magia. Se trata de asegurarnos de obtener de las mentes de las personas, de las personas que realmente son buenas en este negocio, las ideas estratégicas clave y las traducimos en una estrategia dentro de la computadora. Eso es lo que hace un Supply Chain Scientist. No es magia. Es un proceso constante de construcción de la estrategia.
La reorganización, no es magia. Nuevamente, es una combinación de poder computacional y algunos trucos matemáticos. El poder computacional está al alcance de la mayoría de las personas, especialmente si utilizas cloud computing como lo hacemos nosotros. Pero no somos los únicos; definitivamente, no somos los únicos. Muchas personas tienen acceso a incluso más poder computacional, mucho más que nosotros. Pero utilizado 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 funcionará, o incluso si lo hace, llevará demasiado tiempo. Lo que quieres es asegurarte de que el enfoque matemático se adapte a las restricciones, al tipo de estructura que es específica de ese tipo particular de problema.
Conor Doherty: Bueno, lo que quería seguir es un punto clave, que nuevamente se relaciona con un mensaje más amplio que siento que debe subrayarse sobre lo que Lokad intenta hacer. Dijiste que podrías tener, digamos, un profesional en la empresa cliente que obviamente tiene una gran visión. El objetivo es obtener esa información y incorporarla a la estrategia, digamos, al proceso de toma de decisiones, que es el algoritmo que produce las decisiones.
La razón de esto es, seguro, creo que estarías de acuerdo, y corrígeme si me equivoco, 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 cuando se trata de reparar un avión completo 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 gran 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 tuviera que 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 gran 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 una cuestión de quién eres; los humanos simplemente no pueden hacer eso. Está más allá de lo que puedes hacer sin la herramienta. Pero los humanos son increíblemente buenos en la estrategia a un nivel más alto, en comprender 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 para la empresa poder atender a sus clientes de cierta manera con cierta confiabilidad 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 los 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 científico de la cadena de suministro debe hacer es hacerles explicar por qué es importante. Si es importante, significa que piensas que tu costo de quedarte sin stock es alto. Vamos más allá. ¿Qué significa eso, alto en dólares, en euros, en términos financieros? Una vez que hayas 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, producirá 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 vuelve inútiles a los humanos, pero hará lo que la mente humana no puede hacer.
Conor Doherty: Transición perfecta. Entonces, en ese sentido, anteriormente, he asistido a conferencias y ferias de MRO. Una de las plantillas que tenemos para nuestros carteles en un stand es una mano directamente sobre un cubo de basura de papel, una papelera, y simplemente está dejando caer trozos de papel arrugado en ella. En estos trozos de papel hay ciertos términos, y los adaptamos dependiendo de si estamos en un evento minorista o aeroespacial. En este evento, teníamos FIFO y Min-Max, Safety Stock en los trozos de papel que caen en el cubo. Es algo provocativo.
Obviamente, la gente se acerca y, si lo entienden, comentan al respecto. Pero también funciona porque si en realidad no sabes que somos críticos con estos conceptos, te acercas y dices: “Oh, hey, estoy interesado en eso. ¿Puedes contarnos más?”
Simon Schalit: Sí.
Conor Doherty: Ahora bien, el hecho es que a mucha gente le gusta mucho FIFO. Ese es el que más hemos escuchado. Cuando hablas, mencionaste anteriormente sobre tener soluciones en emergencias que funcionen rápido. Es de vital importancia trabajar rápido. Entonces, la pregunta, si representara a alguien que simplemente no está de acuerdo contigo, podría decir: “Bueno, ya tengo una heurística. Ya tengo un solucionador de toma de decisiones generales, un solucionador muy básico que funciona súper rápido en tiempo real, y eso es FIFO, primero en entrar, primero en salir”. ¿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 súper rápido y sí, es muy fácil de entender para los seres humanos porque, quiero decir, primero en entrar, primero en salir, ¿qué hay más directo que eso? Además, la gran ventaja es que parece tener sentido. Si algo llegó primero, quieres ocuparte de eso primero porque probablemente sea el que más probabilidades tenga de retrasarse si, considerando todas las cosas, todo es igual y debería llevar el mismo tiempo.
Sin embargo, al igual que con muchos conceptos obsoletos en la cadena de suministro, no necesariamente malos, solo un poco obsoletos, se basa en algunas suposiciones. La primera suposición es que te encuentras en un entorno simple. ¿Qué quiero decir con eso? Si trabajas utilizando FIFO, es primero en entrar, primero en salir. La suposición es que cada motor, cada avión en el que estás trabajando, si aún estamos 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 de la estrategia, son exactamente iguales. Desde una perspectiva de gestión de riesgos, todos son iguales. Llegar tarde a uno o llegar tarde a otro es exactamente lo mismo.
¿Es cierto en la realidad? Absolutamente no. Tienes diferentes clientes, tienes diferentes tipos de aviones, por lo que no va a 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 hacer para resolver el problema que enfrentas en un avión o un motor no son necesariamente los mismos y probablemente no sean los mismos que los esfuerzos que necesitas hacer para resolver el problema en otro. Incluso si los motores son iguales, la factura de reparación, las cosas que necesitas hacer en esos motores, no son las mismas. Incluso si fueran iguales, las piezas que están rotas dentro de esos dos no son exactamente idénticas. Eso es parte de la incertidumbre que tienes cuando abres un motor. Descubres qué está roto, qué está corroído.
Conor Doherty: No sabía que eso iba a estar ahí.
Simon Schalit: Exactamente. Entonces decir que “Oh, me voy a enfocar en el motor A porque llegó antes que el motor B” no tiene mucho sentido. Lo más probable es que, incluso si dedicaras todos tus esfuerzos al motor A, te llevaría mucho tiempo solucionar el problema. Mientras que tal vez en el motor B, puedes solucionarlo muy rápidamente.
Sí, podrías decir: “Todavía estoy avanzando en el motor A”, pero si terminas el motor B, ya no está en tu taller. Entonces tienes espacio para que entre otro motor, tienes espacio para inspeccionar este motor y saber 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 eso antes, lo cual te ayudará a financiar el resto de tus operaciones.
Entonces vas a tener consecuencias asociadas al orden en el que haces las cosas. Cada minuto invertido en las diferentes actividades no tiene el mismo valor porque no tiene las mismas consecuencias. No desbloquea el mismo potencial.
FIFO es completamente ajeno a eso. FIFO es una visión simplista de tus cadenas de reparación o fabricación. No me malinterpretes, no es malo. Entre todas las soluciones que podrías usar sin las herramientas adecuadas, esa es probablemente 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 nuevamente, 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 horarios o secuencias separadas. Por lo general, hay mucho más. Entonces tienes que tabularlo en tu cabeza o con una hoja de Excel o simplemente usando el solucionador. Tienes que tener en cuenta mucho más. Y el punto es que los costos no son lineales. No son necesariamente los mismos, y debes tenerlo en cuenta o tener algo que te brinde información sobre las implicaciones financieras de trabajar en esto en comparación con trabajar en aquello.
Simon Schalit: Y por supuesto, está el problema simple de asignación donde 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 al 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 pieza, hay un buen argumento de que la pieza debería ir al motor B. Porque eso es lo único que falta. Puede ir, mientras que la pieza única que tienes, si la pones en el motor A, no hace nada porque todavía faltan otras cuatro piezas. FIFO no tiene en cuenta eso.
Conor Doherty: Bueno, nuevamente, y quiero subrayar rápidamente un punto que se mencionó anteriormente. Cuando 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 estúpido, ingenuo ni nada por el estilo. En muchos casos, nuevamente, es la mente humana abordando el problema y a menudo utilizando las mejores herramientas disponibles. En ausencia de herramientas argumentablemente superiores, las personas recurren a lo que al menos es comprensible y que a primera vista parece funcionar.
Según mi comprensión basada en esta larga conversación, el diagnóstico del valor base a menudo es muy limitado en términos de alcance financiero. Lo que quiero decir con eso es que “Oh, bueno, el motor está fuera, eso es un valor financiero que se ha agregado, o se ha agregado valor, esa cosa está hecha”. Y una idea clave que pareces estar explicando hoy es que hay consideraciones financieras directas y mayores indirectas que, seamos honestos, la mente humana simplemente no puede ver por naturaleza. Hablaste sobre la naturaleza del diseño. Por naturaleza, simplemente no puede comprender a gran escala las a menudo no linealidades y las consecuencias financieras externas de la toma de decisiones. Lo que nos lleva de vuelta a utilizar la automatización, a utilizar un científico de la cadena de suministro que sea capaz de extraer esta información y convertirla en un motor de decisión repetible.
Simon Schalit: Sí, bueno, nuestra posición al respecto es bastante clara. El futuro de la toma de decisiones en la cadena de suministro se trata de la automatización. Y cuanto más complejos sean los contextos, más importante se vuelve. Para nosotros, eso es hacia donde nos dirigimos.
Conor Doherty: Para concluir, para las personas que están escuchando y han escuchado algunas afirmaciones increíbles, afirmaciones increíblemente precisas y consecuentes sobre lo que se puede hacer, para alguien que todavía piensa: “Simon, lo que estás describiendo es algo 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 sucediendo en los últimos años, y esa es la dirección hacia la que se dirige la cadena de suministro en general. Automatización a gran escala y automatización a niveles cada vez más bajos de granularidad. ¿Por qué? Porque tenemos el poder computacional y, gracias a los científicos de la cadena de suministro, el concepto y el papel de los científicos de la cadena de suministro. Tenemos la capacidad de llevar los datos e información necesarios, estratégicos y financieros, al algoritmo, a la computadora, para que la estrategia que se aplica a gran escala sea aquella diseñada por los 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 era el contexto, pero dijiste sobre este tema, que la incredulidad de las personas o que no crean que sea posible es sorprendente considerando que esto es efectivamente lo que las personas están tratando de hacer en tiempo real. Entonces cualquier persona, nuevamente, un tomador de decisiones clave, una parte interesada clave, en una mañana de lunes necesita revisar el horario porque Simon y Conor están ausentes. Lo que están haciendo en tiempo real es lo que estamos describiendo utilizando una computadora, utilizando algoritmos. Son básicamente el mismo proceso. Estás buscando una solución optimizada. Entonces no es magia, es simplemente 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. Doloroso para ellos y en cierta medida doloroso para la empresa porque no están llegando a una solución optimizada, no por falta de habilidad sino por falta de herramientas. Y lo que estamos trayendo es la herramienta que es necesaria para reemplazar realmente el elemento humano que es deficiente a nivel granular y mantener 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 nuevamente por tu tiempo y gracias a todos por ver.
