Data Science ha fallado

Resumen

Una sesión enfocada en por qué la data science corporativa a menudo ha entregado resultados inferiores en supply chains y cómo solucionarlo rápidamente. Exploraremos el verdadero propósito de los equipos de data science, cómo usarlos de forma efectiva y cómo aumentar su impacto a partir de hoy.

Transcripción completa

Conor Doherty: Esto es Supply Chain Breakdown, y hoy analizaremos por qué creemos que la data science corporativa ha fallado.

Otro punto de vista poco controvertido aquí en Lokad. Mi nombre es Conor; soy Director de Comunicaciones aquí en Lokad.

Y a mi izquierda, como siempre, el fundador de Lokad, Joannes Vermorel. Ahora, antes de comenzar la discusión, comenta abajo: ¿estás en desacuerdo de inmediato con nuestro punto de vista? ¿Ha fallado, en general, la data science corporativa?

Lo descubriremos a lo largo de la discusión. Envía tus preguntas y comentarios. Alexey está manejando el chat en vivo hoy—salúdale, Alexey.

Y con eso, Joannes, vayamos directo al grano. Entonces, para empezar: la data science corporativa—perdón—ha fallado. Esta es una afirmación provocadora. Es muy acorde con la imagen, pero, ¿es una exageración?

Joannes Vermorel: Desde mi punto de vista, no lo es. He tenido la oportunidad de conversar, creo, con unas 200 compañías—sobre lo que están haciendo en cuanto a supply chain y data—y hasta ahora diría que la cuasi‑totalidad de ellas no tiene ni un solo éxito rotundo con la data science.

Más específicamente, me refiero a compañías no tecnológicas—dejando de lado a las grandes tecnológicas como Microsoft, Amazon, etc. Me refiero a compañías no tecnológicas que operan supply chains de gran tamaño. Y cuando digo “ha fallado la data science,” me refiero al equipo corporativo que opera bajo el nombre de equipo de data science.

¿Ha entregado este equipo algo que contribuya genuinamente a la rentabilidad de la compañía? Una prueba de fuego es: si esas compañías liquidaran este equipo de la noche a la mañana, ¿se vería perjudicada su rentabilidad de manera sustancial—al extremo, incluso, irían a la quiebra?

Si la data science realmente estuviera aportando un valor significativo, entonces eliminar el equipo debería perjudicar profundamente a la compañía. Mi opinión es que, en literalmente todas las compañías que he observado, podríamos eliminar el equipo de data science y apenas sería un inconveniente.

Conor Doherty: Bien, pero define el problema según como lo ves. ¿Cómo ves una división de data science? ¿Cuál crees que es el mandato—la función—en la que están fallando?

Joannes Vermorel: Ese es el problema: la data science es un medio, no un fin. Si tomamos una analogía—al final del siglo XIX—esta gran novedad, la electricidad. La electricidad es fantástica; se pueden hacer tantas cosas con ella. Es una invención que definirá el próximo siglo.

Ahora imagina una compañía que crea un “departamento de electricidad.” Puedes ver que introducir un departamento de electricidad es incorrecto—no porque la electricidad sea mala, sino porque el departamento de electricidad en sí es malo. Ese es mi punto con la data science.

No estoy diciendo que la data science, como subcampo de la informática, haya fallado. Se están haciendo cosas increíbles con modelos, técnicas y perspectivas para lidiar con los datos—esto es como un cohete, y GenAI es solo la última iteración de este cohete.

Sin embargo, si introduces una división de data science, terminas con el mismo tipo de tontería que un departamento de electricidad en tu compañía. Esto es un medio, no un fin. No quieres electricidad por el simple hecho de tener electricidad; quieres lo que puedes hacer con ella—y va a estar extremadamente difundido.

Tendrá un significado completamente diferente para las fábricas en comparación con las finanzas. La gente de fábricas diría, “La electricidad es genial; podemos tener motores moviendo cosas pesadas.” Las finanzas dirían, “Si tenemos una máquina de computación muy avanzada—esa es IBM—quizás podamos hacer cálculos por nosotros.” Es electricidad de nuevo, pero completamente diferente.

Lo mismo ocurre con la data science. La data science corporativa falla porque, si la aíslas en una división propia, terminas con algo que nunca logra entregar algo verdaderamente impactante—porque realmente nunca reciben el mandato para hacerlo. No están dentro de una división que ya tenga una misión.

No están dentro de finanzas; no están dentro de marketing. Y los casos en que funciona son cuando las personas operan dentro de un departamento existente con un mandato claro.

Conor Doherty: Hay dos formas de encuadrar esto: negativa y positiva. Empecemos por lo que está mal, específicamente. ¿Cómo ves actualmente el despliegue de los equipos de data science—y por qué está mal?

Joannes Vermorel: El arquetipo es: la alta dirección ve en la prensa que la data science es algo real. La gente se emociona mucho: “¡Consíganme algo de AI!” La junta se reúne y dice, “No podemos quedarnos fuera. Necesitamos esto.”

Contratan a un grupo de personas muy inteligentes y con inclinación técnica, y esas personas dicen, “Mira todos esos proyectos open‑source relucientes: pandas, PyTorch—lo que se te ocurra.” Son todos esos juguetes relucientes. Traigamos esos proyectos open‑source; son de una calidad increíble y aportan sofisticación a la mesa.

Esas herramientas han sido fundamentales para que las grandes tecnológicas alcancen éxitos rotundos. Así que la gente dice, “Tenemos todos los ingredientes: increíbles proyectos open‑source y personas inteligentes—vamos a emular a las grandes tecnológicas.” La consecuencia: no resulta.

La gente construye cosas. El patrón típico es un prototipo extremadamente sofisticado y prometedor—en apenas un par de semanas. Tres semanas después: ¡bam!, un prototipo muy sofisticado, impresionante. Un año después, sigue sin estar en producción. Cinco años después, aún no hay nada a nivel de producción en este departamento—y ciertamente nada revolucionario.

Sí, de un lado y otro habrá cosas menores impulsadas por datos, pero en francés se diría que es la quinta rueda del coche: algo no críticamente importante.

Conor Doherty: Has mencionado “producción,” y quiero volver al purgatorio de los pilotos. Pero también mencionaste propósito, meta, dirección, función—palabras que se adentran en la teleología. Entonces, nuevamente, ¿cuál es, en tu opinión, la meta de un equipo de data science—por qué existe, si es que existe?

Joannes Vermorel: Ese es el problema—existe por el mismo motivo por el que existiría un “departamento de electricidad” en tu compañía. Planteado de esa manera, puedes ver el problema: suena incorrecto porque es un medio, no un fin—aun cuando seas un proveedor de electricidad.

Incluso EDF, un proveedor nacional de electricidad en Francia, no tiene un “departamento de electricidad.” Todo el negocio es electricidad. Necesitas pensar en lo que quieres lograr. Por ejemplo, si el marketing dice, “Queremos optimizar el gasto en Google Ads,” entonces haz la optimización del gasto en Google Ads.

No “hacen data science”; hacen esa optimización. Resulta que hay muchos datos involucrados. En cuanto adoptas una perspectiva operativa, deja de llamarse data science. Por eso digo que la data science corporativa ha fallado: cada vez que veo un equipo aún llamado “data science,” refleja a personas que están perdidas. No tienen un propósito—y generalmente no hay nada de importancia en producción.

Tendrán algunos widgets aquí y allá, pero si han existido por una década y observamos fuera de las grandes tecnológicas, nunca he visto a esos equipos sosteniendo el destino de la compañía en sus manos. En el mejor de los casos, es algo extremadamente secundario.

Conor Doherty: Has auditado compañías tecnológicas y has estado en compañías más pequeñas—no FAANG. Presumiblemente has visto equipos de data science exitosos. ¿Qué diferencia a los buenos de que, en general, la data science corporativa falle?

Joannes Vermorel: He auditado más de 100 startups. Es completamente diferente cuando audito una compañía que se dedica a la detección de fraudes.

Obviamente, ese es el objetivo: detectar fraudes. Luego segmentan los tipos de fraude; podrían tener un equipo dedicado a estafas de pig‑butchering, con heurísticas y algoritmos específicos para detectarlos, abordarlos y reportarlos de manera efectiva a las autoridades pertinentes.

La data science en esas compañías tecnológicas funciona porque es, literalmente, su raison d’être. Comienzan con un problema que quieren resolver—digamos, detección de fraudes, o detección de anomalías en ingeniería mecánica. Para abordar el problema, en algún momento se invocan herramientas sofisticadas.

No empiezan diciendo, “Tenemos este ingenioso paquete open‑source; deberíamos usarlo.” Comienzan con un gran problema poco abordado que resolver. Ven que las soluciones simples fallan, y después de validarlo, sacan los cañones pesados para resolverlo.

A menudo, se dan cuenta de que el problema no se resuelve porque todo lo disponible es inadecuado. Open source es fantástico, pero inadecuado para su problema específico. Así, desarrollan su propia solución tecnológica y, como subproducto, componentes open‑source que son subsegmentos de su solución.

Exactamente como lo hacen las grandes tecnológicas con grandes problemas—luego deciden open‑sourcear partes de su solución. Por ejemplo, Airflow—de Facebook—es un sistema de programación de tareas distribuido a gran escala con dependencias; lo desarrollaron internamente, y en algún momento fue solo una parte de una solución mayor que open‑sourcearon.

Típicamente, ese es el camino de esas tecnologías. Lo que está mal es pensar que puedes tomar esas piezas y reutilizarlas en una gran compañía, incluso si tu camino es completamente diferente. Esas piezas tecnológicas son excelentes, pero provienen de caminos específicos.

La mayoría de las veces no serán apropiadas para una gran corporación que tiene problemas completamente diferentes en la naturaleza a las de las grandes tecnológicas, como una compañía como Meta. La gran mayoría de las compañías en la Tierra no tienen nada que ver con los problemas de Meta.

Conor Doherty: Cualquiera familiarizado con el contenido de Lokad sabe que a menudo estás en desacuerdo con la forma en que se gasta el presupuesto en las corporaciones. ¿Hay algo único y pernicioso—únicamente negativo—sobre la manera en que se gasta dinero en la data science, más allá de simplemente desperdiciarlo?

Joannes Vermorel: No—de nuevo, la falta de consecuencias. Debido al estereotipo de que los equipos de data science están extremadamente aislados, casi no hay consecuencias de segundo orden. No contaminan el resto de la compañía; el daño se limita en gran medida al dinero desperdiciado en el equipo.

Están tan aislados que ni siquiera consumen mucho del tiempo de la alta dirección; quizá una o dos reuniones al año. La buena noticia es que es un problema contenido: un gasto derrochador que no va más allá de eso.

Conor Doherty: Están tan aislados—¿a qué te refieres?

Joannes Vermorel: Podrías imaginar otros fenómenos—tendencias de signaling de virtud—que mantienen a todos ocupados, agotando el ancho de banda mental de todo el equipo ejecutivo. Eso es muy perjudicial. La data science no es así. Está súper aislada y no representa una carga cognitiva para la alta dirección.

Para mí, esto es una larga tradición; se repite con palabras de moda cambiantes. Hace veinticinco años, la palabra clave era “data mining.” Las compañías crearon equipos de data mining. Luego equipos de “digitalización,” equipos de “innovación,” ahora equipos de “data science”—y pronto, equipos de “generative AI.”

Si tienes un equipo corporativo nombrado por un medio—como “electricity”—en lugar de un fin—como “fraud detection”—esto es incorrecto. No deberías tener un equipo nombrado por un medio; debería estar nombrado por el fin.

La nomenclatura importa: define cómo las personas abordan sus trabajos, el tipo de personas que contratas y cómo elaboran su hoja de ruta. Si tienes un equipo de “data science,” idearán—adivina qué—una hoja de ruta de data science. Si dices “fraud detection team,” la hoja de ruta se convierte en, “¿Cómo eliminamos esos fraudes?”

En Lokad, en realidad dejamos de contratar “data scientists” hace una década. Ahora contratamos “supply chain scientists.” Puede sonar como un pequeño cambio, pero al contratar estamos diciéndoles literalmente a los candidatos: si te unes a nosotros, tu misión será lograr que los supply chains de nuestros clientes funcionen tan fluidos como humanamente sea posible.

Te daremos las mejores herramientas y capacitación; no estarás solo. Pero, al final, si puedes lograrlo con aritmética básica y algunas heurísticas—genial. No estamos aquí para publicar artículos sobre algoritmos sofisticados. Si una heurística increíblemente simple resuelve el problema, buen trabajo; el mantenimiento se vuelve más sencillo.

En contraste, cuando contratábamos “data scientists,” la gente se oponía: “No podemos resolver esto con un método super‑tonto—no es state‑of‑the‑art. Necesito deep learning para mi currículum.” Para nosotros: no, no lo necesitas. Si algo mucho más simple que deep learning lo resuelve, no necesitas deep learning.

Conor Doherty: Antes de continuar, estamos contratando supply chain scientists. Si estás interesado, envía tu CV a nuestro gerente de reclutamiento.

Agregando algo de contexto: fuentes como Gartner reportan que solo el 48% de las iniciativas digitales cumplen o superan los objetivos de resultados comerciales, y múltiples encuestas muestran que los proyectos de AI/ML se quedan estancados en la pre‑producción. Claramente existe un “purgatorio de pilotos.” No se dice que sea un problema univariado—pero en ese problema multivariado, ¿cuánto peso le das a las divisiones de data science en ese fenómeno?

Joannes Vermorel: Es abrumador. Normalmente, cuando emprendes una iniciativa digital que es digitalizar—implementar un sistema de registro—funciona. Por ejemplo, gastos gestionados a través de hojas de cálculo y correos electrónicos: configuras un sistema de gestión de gastos. Seis meses después, la aplicación y las prácticas están en su lugar, y funciona.

Los sistemas de registro son iniciativas casi de riesgo cero—aunque a veces los proveedores son extremadamente malos. Por el contrario, en el ámbito de los sistemas de inteligencia, la cuasi‑totalidad falla. Si se origina en un equipo de data science, según mi experiencia, falla todo el tiempo.

En Lokad, incluso hemos tenido clientes con configuraciones lado a lado: Lokad generando decisiones de supply chain y el equipo interno de data science que lo había estado haciendo durante media década antes que nosotros—aún allí, generando cosas que no se usan, simplemente ignoradas. La complejidad corporativa los mantiene.

La data science es extremadamente útil—como la electricidad. Es una herramienta versátil donde haya datos—y hoy en día eso es en todas partes. ¿Es digna de interés? Absolutamente. Pero no justifica tener su propio equipo. Necesita estar en cada equipo donde existan datos: marketing, finanzas, producción, compras, planificación, etc.

Conor Doherty: Seamos constructivos. Según lo que dijiste, ¿estás sugiriendo que cada miembro del equipo mejore sus habilidades en data science; o que cada equipo deba tener un miembro de data science; o que un equipo central preste miembros sobre una base de ticket? ¿Qué mundo estás aconsejando?

Joannes Vermorel: Para cada función en la empresa, existe potencial en aprovechar los datos para lograr lo que la función hace—mejor y más rápido. Tomemos un ejemplo más simple que supply chain: el gasto en marketing en Google Ads.

Google Ads son complejos: puedes ofertar tarifas variables para miles de palabras clave; rastrear rendimiento, costo por clic, costo por resultado. Es bastante técnico. Puedes construir esta competencia internamente con verdaderos expertos, o externalizarla completamente a una agencia que maneje la optimización.

Ambos enfoques son válidos siempre y cuando exista una competencia genuina en algún lugar—internamente o externamente. Necesitas personas con verdadera afinidad por todo lo que engloba la data science. No se puede omitir una comprensión profunda—pero se ve a través del lente de la función que estás optimizando.

Conor Doherty: Una pregunta que recibí en privado—abogado del diablo para Joannes: ¿no es “fracaso” demasiado duro si el analytics aún informa reuniones y reportes? Si la dirección se siente mejor informada, ¿eso no agrega valor?

Joannes Vermorel: Ese es exactamente el tipo de caso en el que la data science se aísla y no tiene consecuencias negativas—salvo que aquí es peor: estás distrayendo a los ejecutivos con reportes que les hacen sentir bien. Si lo que se desea son estadísticas descriptivas para la alta dirección, ese es el rol de BI.

Ya tienes un equipo de Business Intelligence; no necesitas duplicar ese presupuesto para data science. Por cierto, las divisiones de BI también tienen problemas. Marketing debería asumir la responsabilidad de elaborar sus propios indicadores; no deberían externalizar eso a data science.

Si el único resultado son métricas que hacen sentir bien a la dirección—en el mejor de los casos, son redundantes con BI. Fúndelo de nuevo en BI; no necesitas una división separada. Mi criterio es riguroso: ¿la empresa se vería perjudicada de manera medible, financieramente, si el equipo de data science desapareciera?

Mejorar la moral de la dirección es bueno, pero me preocupa el P&L—cuántos dólares extra aportamos a la empresa. Producir miles o millones de números al día es super fácil y entretenido; producir diez números al día que valga la pena leer es extremadamente difícil.

¿Estás produciendo esos diez números? Mi experiencia: no. Ellos generan muros de métricas, sí—pero no los tan valiosos que, de ser eliminados, dañarían a la empresa.

Conor Doherty: Muchas de esas métricas provienen de arriba. Marketing es un departamento; ventas es un departamento. No son responsables de los indicadores que se les imponen. Y si ya tienes BI produciendo estadísticas descriptivas…

Joannes Vermorel: Exactamente—en el mejor de los casos son redundantes. Fúndelo en BI; no hay necesidad de una división separada.

Conor Doherty: Una pregunta más de un mensaje privado: “No puedo simplemente despedir a mi equipo de data science. ¿Cómo puedo mejorar las cosas desde el primer día?” Realísticamente, ¿qué se puede hacer?

Joannes Vermorel: He hecho esto para algunos jugadores de ecommerce bastante grandes. Sugerí dividir el equipo y redistribuirlo en otras divisiones. Si tienes media docena de personas: pon a dos en finanzas, dos en marketing, dos en planificación. Dile a esos gerentes que ahora están a cargo de estas personas competentes y de su uso productivo.

Si gestionas esta unidad y quieres ser un héroe, convence a la alta dirección de dividir y dispersar la competencia entre las divisiones. El mejor enfoque que he visto—pero que solo funciona para empresas muy grandes—es transformar el equipo central en coaches y mentores de data science dentro de cada departamento.

Olvídate de entregar un prototipo funcional para marketing; cinco de ustedes entrenarán a marketing para que puedan hacer cosas interesantes con datos; entrenen a ventas de igual manera. Esto funciona en empresas de €5B en adelante—lo suficientemente grandes para sostener un equipo solo para evangelizar. Debe ser transitorio—12, 18, 24 meses, no más de dos años—y luego disolverse.

De lo contrario, terminas con una burocracia semiescondida que desperdicia dinero.

Conor Doherty: Preguntas del chat. De Neil Knight: ¿Crees que los data scientists son ignorados porque son internos—o porque no son útiles? Encuentro que los consultores a menudo son escuchados porque pueden llegar a las mismas conclusiones que la dirección (McKinsey, Bain, Accenture, etc.). ¿Qué opinas?

Joannes Vermorel: Hay un proverbio francés: nadie es profeta en su tierra. Ser un forastero ayuda, pero, para reconocer a los consultores, no es solo eso. Una cosa que hacen bien es enfocarse en problemas genuinos e importantes.

Podemos discrepar en cuanto a las habilidades técnicas para resolver, pero cuando se trata de profundizar en lo que realmente importa para la alta dirección, ellos son buenos. Eso es lo que la data science no está haciendo. Debido a que están aislados, no pueden enfrentar problemas con un gran retorno—esos requieren grandes transformaciones.

He visto equipos de data science elegir proyectos preferidos que son inconsecuentes. Hacemos un cálculo rápido y acordamos que hay un problema veinte veces mayor justo al lado. Dicen, “Sí, pero ese problema es delicado; necesitaríamos aprobaciones en varios niveles; podríamos causar fricciones.”

Ahí es donde ganan los buenos consultores: se centran en lo que importa, no en proyectos preferidos que tememos abordar. Incluso si lo que hacen es crudo, se concentran en cuestiones muy reales. La data science, al estar al margen—no siendo parte de marketing, finanzas, etc.—nunca obtiene la autoridad para transformar la empresa y aprovechar los datos.

Toma, por ejemplo, la detección de fraudes: cuando detectas un fraude, necesitas la autoridad para decir, “No atenderemos a este cliente; rechaza el pago de inmediato.” Habrá falsos positivos—clientes honestos afectados. La cuestión es el equilibrio entre falsos positivos y verdaderos positivos.

Si le dices al equipo de data science, “Mientras haya aunque sea un falso positivo al año, no podemos poner esto en producción”, jamás entrará en producción. Este es un compromiso. Necesitas la autoridad para decir, “En general, es muy bueno; los aspectos negativos están controlados”, y luego refinar los métodos.

Conor Doherty: Gracias, Joannes. Pasando a Amarinder: ¿Cuál es tu opinión sobre el rol del gerente de producto o del product scientist? ¿Es este un mejor medio para entregar el valor final del que hablas?

Joannes Vermorel: Los gerentes de producto están muy en el ámbito de los sistemas de registro. La gestión de productos es crítica allí porque el cielo es el límite en términos de funcionalidades; necesitas una hoja de ruta y priorización, y decir “no” para evitar una aplicación monstruosa.

Para los sistemas de inteligencia—procesos de toma de decisiones automáticos como la detección de spam—tienes falsos positivos/falsos negativos que mejorar. No puedes mejorar eso solo conversando con los usuarios o arbitrando funcionalidades. Otro ejemplo es el ranking de búsqueda—¿cómo mejoras la página de resultados de Google? Muy difícil; no se trata de funcionalidades.

La gestión de productos es importante, pero pertenece a los sistemas de registro. La data science que realmente tiene impacto tiene que ver con decisiones—por lo tanto, sistemas de inteligencia. La gestión de productos o los “management scientists” tienen un rol que desempeñar, pero es menor y proviene del lado de los sistemas de registro.

Conor Doherty: Avance para la próxima semana: dedicaremos el episodio a sistemas de registro, sistemas de reportes y sistemas de inteligencia. Estén atentos al promo y asistan.

Reflexión final, Joannes. Un llamado a la acción para los que están de acuerdo contigo: ¿cuál es mi paso inicial—qué hago ahora para generar un cambio?

Joannes Vermorel: Fundamentalmente: hay mucho que puedes hacer con tus datos. La gran mayoría de las empresas no aprovechan al máximo sus datos. La intuición detrás de la data science proviene de un buen lugar: tienes tantos datos que no se están utilizando para mejorar el negocio.

En Lokad se trata de predictive optimization de supply chains—eso es lo que hacemos—pero hay muchas otras cosas. Otro buen ejemplo es la “simpatía mecánica”: personas que abrazan la tecnicidad, de modo que no se trata solo de conjeturas fundamentadas—personas con verdadera afinidad por el desafío.

Lo que no está bien es tomar eso y decir, “Necesito crear una división.” Eso es incorrecto—un anti‑patrón; una forma vaga de abordar el problema. Piensa en la “división de electricidad.” La electricidad iba a ser sumamente importante para todas las divisiones—lo mismo para la data science.

Como líder, reta a cada división a aprovechar al máximo los datos que existen en la empresa para su función. Cada líder de división debe ser responsable de obtener lo mejor para su área. Esto requerirá habilidades de tipo data science—internas, externas, con o sin consultores.

Es un mensaje más difícil porque los líderes serán desafiados en algo incómodo. Piensa en la electricidad y en las plantas de fábrica: con bombillas, puedes operar de noche. Cambia todo. ¿Lo harás? Muchas preguntas—pero necesitas hallar las respuestas dentro de la función.

Involucra a las personas, pero no puedes eludir el hecho de que la tecnología transforma lo que haces de una manera tan profunda que no puedes, de manera realista, externalizar el problema a otra división y darlo por terminado.

Conor Doherty: Elección final, Joannes: podemos detenernos ahora o responder a una pregunta de alguien a quien sé que es fan de toda la vida. Vamos a ello. Joshua pregunta: desde tu experiencia dirigiendo “supply chain as a service,” si la mayoría de los clientes aún tienen ERPs, hojas de cálculo y políticas que silenciosamente hacen las llamadas diarias, ¿cuánto desplaza Lokad realmente el enfoque de la toma de decisiones? ¿Qué se requiere para que la capa analítica se convierta en la que toma las decisiones en lugar de ser solo otro asesor?

Joannes Vermorel: En Lokad nos mantenemos firmes en entregar decisiones automáticas. Contamos con numerical recipes que generan decisiones sin intervención. Mientras necesitemos ajustar números, seguimos iterando en la receta para no tener que modificar nada; luego realizamos mantenimiento para que continúe funcionando sin intervención.

Se requieren meses de operación dual, especialmente para grandes empresas, para ganar confianza—decisiones de calidad de producción día tras día. En una gran empresa, tomará meses. A medida que avanzamos, todos comienzan a darse cuenta de que ahora tenemos preguntas mucho más interesantes para formular: por ejemplo, ¿qué es “quality of service”?

Si me dices que quality of service es “service level”, no coincido—no es service level. Para el DoD, eso sería “operational readiness”. Para un presupuesto dado, ¿qué espectro de operaciones es factible versus inviable? Estas son preguntas difíciles.

Cuando implementamos este enfoque, las personas tienen tiempo de pensar en profundidad sobre estas cuestiones. Procesar los datos aporta muchos elementos a la discusión: nuevas clases enteras de preguntas pueden encontrar respuesta en los datos.

A diferencia de un equipo de data science que intenta obtener respuestas por sí solo, aquí la operación es la que impulsa: “Queremos hacer esto; tenemos un cuello de botella.” Observa los datos; analiza el cuello de botella; logra una mejor asignación; luego el siguiente cuello de botella. Si aíslas la data science, obtienes una solución buscando un problema.

Las personas elaboran una solución y luego buscan un problema que se ajuste aproximadamente. Con una función operativa—por ejemplo, asignar dólares para partes de aeronaves—tienes un desafío concreto. Iteras en mejores soluciones para un problema real.

Conor Doherty: Una pregunta de seguimiento de Joshua: cuando ese cambio ocurre hacia tu perspectiva, ¿cuánto cambio de política se requiere generalmente para que un cliente se comprometa? ¿Es usualmente un pequeño ajuste, o una reestructuración fundamental de cómo se rigen las decisiones de supply chain?

Joannes Vermorel: Es lo segundo, pero no tienes que hacer todo en un solo día. Para algunas industrias incluso tenemos testimonios—transformaciones que llevan una década y aún continúan.

Para organizaciones complejas—el mantenimiento de grandes aeronaves es extremadamente complejo—se requiere tiempo. Con Air France Industries, la transformación es masiva a una década vista. Abordamos ámbitos de decisiones uno a uno; creo que allí tenemos más de veinte ámbitos diferentes.

Típicamente tomó un par de meses para que cada ámbito se implementara y se volviera de calidad de producción. Esto es de dominio público—estudios de caso e entrevistas con directores.

Conor Doherty: Espero que eso haya ayudado. Estamos un poco fuera de tiempo, pero fue bueno responder a todas las preguntas. Gracias, Joannes, por tu tiempo—y a todos los demás, gracias por asistir y por sus preguntas.

Algunas personas prefieren enviar un DM en privado; me lo hacen llegar en vivo y, como ves, se los plantearé a Joannes exactamente con la redacción que me fue presentada. Si tienen preguntas, envíennos un DM o publíquenlas en los comentarios.

Nos quedaremos y las responderemos. Que tengas una buena noche. Nos vemos la próxima semana para el siguiente episodio. Y… vuelvan al trabajo.