00:00:00 Introducción a la entrevista
00:00:47 Antecedentes de Paul Jan y experiencia docente
00:02:16 El rol de los datos en supply chain y la enseñanza
00:04:00 Colaboración con Lokad y su impacto
00:06:20 Desafíos de supply chain en el mundo real y obstáculos en la enseñanza
00:10:49 Explicación de los “wicked problems” en supply chain
00:14:37 El impacto del mensaje de la empresa en la percepción del producto
00:16:11 Análisis continuo de datos y limitaciones de Excel
00:19:11 Manejo de datos relacionales y deficiencias de Excel
00:21:49 Transición a SQL para el procesamiento de datos
00:24:11 Beneficios de presentar Lokad a los estudiantes
00:26:33 Consideraciones de costo en la enseñanza de supply chain
00:29:13 Uso de Envision y crítica al software empresarial
00:32:24 Pensamiento orientado a soluciones y limitaciones de las herramientas
00:35:16 Mejores herramientas para mejores soluciones de supply chain
00:37:57 Experiencia docente y filosofía de Joannes Vermorel
00:41:15 Estructuras de datos fundamentales y limitaciones del forecast
00:45:31 Métodos de enseñanza visual y fuertes suposiciones
00:48:32 Necesidad de disrupción en la industria de supply chain
00:51:12 Supply chain como una colección de wicked problems
00:54:24 Ser aproximadamente correcto en supply chain
00:57:55 Enseñando la complejidad de los wicked problems en supply chain
01:00:47 Palabras finales y la importancia de la inversión del sector privado
01:03:24 Superar el miedo a la estadística y comentarios finales
Resumen
Conor Doherty, presentador de Lokad TV, recientemente participó en una discusión con Joannes Vermorel, fundador de Lokad, y Paul Jan, un profesor de supply chain en la Universidad de Toronto. La conversación se centró en el campo en evolución de la gestión de supply chain, el papel de los datos y la importancia de la educación. Vermorel introdujo el concepto de “wicked problems” en supply chain, destacando las limitaciones de Excel y la necesidad de herramientas como SQL Server. Jan compartió su experiencia al pasar de Excel a opciones más programáticas, elogiando la herramienta de Lokad, Envision. Ambos enfatizaron la necesidad de una disrupción en la industria y la importancia de la educación en la gestión de supply chain.
Resumen Ampliado
En una entrevista reciente, Conor Doherty, el presentador, participó en una discusión que invita a la reflexión con Joannes Vermorel, el fundador de Lokad, y Paul Jan, un profesor asociado de Operaciones y Supply Chain Management en la Rotman School of Management. La conversación giró en torno al cambiante panorama de la gestión de supply chain, el papel de los datos y la importancia de la educación en este campo.
Paul Jan, con su amplia experiencia en consultoría y en el ámbito corporativo de Estados Unidos, ha estado enseñando cursos de análisis de operaciones y supply chain en la Universidad de Toronto durante aproximadamente cuatro años. Sus cursos, que incluyen una clase fundamental sobre gestión de supply chain y operaciones, así como una clase en colaboración con Lokad, tienen como objetivo cerrar la brecha entre la teoría y la práctica. Jan reconoce que, si bien los datos se han vuelto más prominentes en la industria, a los estudiantes a menudo les falta la confianza para aplicar lo que aprenden en la escuela al mundo real. Aquí es donde entra la colaboración con Lokad, al proporcionar un entorno listo para que los estudiantes trabajen en tareas de supply chain, permitiéndoles centrarse en los aspectos de supply chain en lugar de en las particularidades técnicas de configurar un entorno de programación.
Vermorel introdujo el concepto de “wicked problems” en supply chain, que son problemas que desafían un análisis directo de primer nivel y requieren un camino de descubrimiento. Destacó las limitaciones de Excel para manejar datos modernos de supply chain, afirmando que no escala al nivel requerido por las supply chain de hoy. Vermorel sugirió que la respuesta de Microsoft a este problema es SQL Server y otras herramientas que manejan datos relacionales. También mencionó que el playground de Lokad tiene como objetivo exponer a los estudiantes a la realidad de los datos relacionales.
Jan compartió su experiencia al pasar de Excel a opciones más programáticas, estando de acuerdo con los puntos de Vermorel sobre las limitaciones de Excel. Mencionó que aprendió SQL en uno de sus proyectos y apreció su capacidad para procesar y simplificar datos. Jan también elogió Envision, la herramienta de Lokad, por su simplicidad y facilidad de uso, lo que ha ayudado a simplificar el proceso de ajustar supuestos y a reducir errores que podrían ocurrir en Excel.
La conversación luego se centró en la mentalidad requerida para usar estas herramientas y si se enseña en clase el entendimiento de conceptos como el costo de oportunidad. Jan respondió que, aunque el concepto de costo de oportunidad no es sencillo, los estudiantes con formación en economía pueden comprenderlo. Señaló una brecha entre lo que los ejecutivos y el personal operativo entienden y a lo que prestan atención, siendo que los primeros se enfocan en los resultados financieros y los segundos en métricas tradicionales.
Vermorel estuvo de acuerdo con los puntos de Jan y discutió las limitaciones de pensar dentro del paradigma de Excel. Explicó que, si Excel es la única herramienta que se contempla, se limitan las soluciones que se pueden imaginar. Vermorel criticó la percepción de que las tecnologías digitales están en constante cambio y que el conocimiento en el campo es desechable. Argumentó que muchas materias fundamentales, como la estructura de datos relacionales y los tipos de datos básicos, es poco probable que cambien significativamente con el tiempo.
La entrevista concluyó con Vermorel y Jan enfatizando la necesidad de disrupción en la industria y la importancia de la educación en la gestión de supply chain. Vermorel explicó que la gestión de supply chain implica una serie de problemas complejos debido a la naturaleza interconectada de las empresas modernas. Argumentó a favor del uso de paradigmas y herramientas que puedan abordar estos problemas complejos, en lugar de buscar soluciones exactas que puedan ser incorrectas. Jan, por su parte, describió su enfoque docente como tanto gradual como disruptivo, comenzando con teorías tradicionales antes de introducir las complejidades del mundo real a través de la colaboración con empresas como Lokad. Reconoció la dificultad de enseñar sobre los wicked problems, que son complejos y dependen de las acciones de otros.
Transcripción Completa
Conor Doherty: Bienvenidos de nuevo a Lokad TV. Las habilidades requeridas para sobresalir en supply chain han evolucionado dramáticamente en los últimos 20 años y seguirán haciéndolo por el momento. Por supuesto, nada de esto es novedad para los invitados de hoy. Se une a nosotros de forma remota desde la Rotman School of Management, el profesor asociado de Operaciones y Supply Chain Management, Paul Jan. Paul, bienvenido a Lokad. Gracias por invitarme. Es genial estar aquí.
Ahora, Paul, dije, bienvenido a Lokad, aunque es un poco un eufemismo. Quiero decir, ya estamos muy familiarizados. Has colaborado con nosotros durante un tiempo y, de hecho, nos visitaste aquí en las nuevas oficinas de París. Pero para las personas que no conocen tu trabajo, ¿podrías dar una introducción y describir tus antecedentes, por favor?
Paul Jan: Gracias por invitarme. Mi nombre es Paul Jan. Actualmente soy profesor en la Universidad de Toronto, donde imparto cursos de análisis de operaciones y supply chain. Vengo de un entorno industrial con amplia experiencia en consultoría y también en el sector corporativo de Estados Unidos. He pasado los últimos 15 años, más o menos, tanto en la industria como en consultoría, y ahora estoy enseñando, compartiendo mi conocimiento y experiencia con todos los estudiantes aquí en UofT.
Conor Doherty: ¿Y cuánto tiempo llevas enseñando en la Rotman School of Management?
Paul Jan: He estado en Rotman durante unos cuatro años, y antes de eso, estuve en la Universidad de California, Irvine. Así que, en total, he estado enseñando durante aproximadamente siete años.
Conor Doherty: ¿Y cómo han evolucionado los cursos sobre supply chain incluso en ese corto período?
Paul Jan: Aquí en Rotman, imparto una clase fundamental, que es una introducción a la gestión de supply chain y operaciones. Es allí donde los estudiantes aprenden las teorías fundamentales, las aplicaciones y algunas de las prácticas. También imparto otra clase que es en colaboración con Lokad. Esa clase tiene como objetivo tomar esas teorías y prácticas y ponerlas en acción con una empresa. A lo largo de los años, existe cada vez más información proveniente del ERP de una empresa, e incluso en negocios medianos o pequeños, todos tienen algún tipo de sistema de captura de datos o ERP. Así que los datos se han vuelto más prominentes, y los estudiantes, por lo que he observado, carecen de la confianza y la experiencia para aplicar lo que aprenden en la escuela al mundo real.
Conor Doherty: Bueno, y Joannes, llegaré a ti en un momento, pero solo quiero profundizar en eso porque tienes una amplia experiencia en el sector privado. Cuando seleccionas las teorías fundamentales para enseñar a los estudiantes, ¿cuánto de eso es conocimiento tradicional de supply chain y cuánto está influenciado por tu amplia experiencia?
Paul Jan: En la clase fundamental que imparto, no tengo mucho margen para desviarme. Necesito seguir un programa y los requisitos establecidos por la universidad y el departamento. Así que la mayoría de esos son los modelos y teorías tradicionales que un estudiante aprenderá. Lo que hago es complementar eso con anécdotas, historias o advertencias adicionales para los estudiantes cuando ingresan al mundo laboral. Pero, como requisito de la escuela, la base son las teorías tradicionales, que es lo que aprenderán en esa clase. En la otra, en colaboración con Lokad, tengo la libertad de aplicar un enfoque más práctico. Así que, en términos de estar consciente de las realidades, en términos de las líneas de fondo financieras, que desde una perspectiva financiera, las teorías tradicionales fundamentales no lo toman en cuenta. Pero en la práctica, los ejecutivos se fijarán en el impacto financiero de hacer XYZ. Esa es la diferencia entre ambas y cómo aplico mi experiencia a estas distintas clases.
Conor Doherty: Bueno, gracias, Paul. Y ahora, Joannes, pasando a ti, ¿podrías describir exactamente cuál es la colaboración con Paul como parte de la iniciativa educativa más amplia de Lokad?
Joannes Vermorel: Sí, en Lokad, iniciamos una iniciativa hace aproximadamente un año para hacer que nuestra pila tecnológica estuviera disponible de forma más amplia. Normalmente, Lokad se ofrece como un software empresarial, accesible solo para nuestros prospectos y clientes VIP. Lo que hicimos fue reempaquetarlo en lo que llamamos un playground, que es una versión ligeramente simplificada de Lokad accesible en tr.lo.com. Esto brinda acceso a un entorno de codificación potenciado por Envision y a un pequeño sistema de archivos. En cuanto a propósitos educativos, la idea es realizar una serie de talleres donde los estudiantes puedan tomar un conjunto de datos que sea una versión simplificada de lo que se encuentra en configuraciones reales, pero que siga siendo bastante representativa. No queríamos hacer la tarea demasiado fácil ni demasiado teórica. La idea es poder proporcionar un entorno listo en el que el estudiante pueda comenzar directamente con un conjunto de datos y un pequeño desafío de una tarea de supply chain que deba ejecutarse sobre ese conjunto de datos. Esto refleja el tipo de desafíos que pueden enfrentar las personas al ingresar a una empresa donde existen problemas con los proveedores. Necesitas analizar y determinar quiénes son los proveedores que no logran entregar a tiempo y en su totalidad, o deseas hacer un forecast de la demanda o cualquiera de esas tareas analíticas de supply chain. La idea es que Lokad quiso proporcionar un entorno para ello. La razón es que los estudiantes que estudian materiales de supply chain no son ingenieros de software. Entonces, sí, si le pidieras a un aula llena de futuros ingenieros de software que hicieran eso, podrían tomarse el tiempo de configurar un entorno Python, de configurar su propia tubería de extracción de datos y lógica de parsing, entre otras cosas, para que pudieran trabajar en un conjunto de datos utilizando tecnologías de código abierto. El problema es que, considerando el tiempo disponible para estudiantes que no son ingenieros de software, sino ingenieros de supply chain o futuros ingenieros de supply chain, necesitamos tener un entorno listo para un taller que se centre principalmente en supply chain, y no en las complejidades de cómo analizar un archivo CSV en Python. Ese tipo de cosas debe estar preparado, y es eso lo que podemos hacer con este entorno. Compartimos un entorno donde los datos ya han sido preparados, el script que lee los datos ya está escrito, para que puedan saltar directamente al meollo del problema, que es determinar qué hacer con una supply chain, con un proveedor, con la demanda, y aplicar el razonamiento de supply chain a través de una herramienta programática. Nuestra ambición es permitir que esos curriculums, que típicamente son muy ligeros en cuanto a herramientas técnicas, realicen tareas más avanzadas, pero sin verse completamente abrumados por las puras tecnicidades. En resumen, proporcionamos un entorno que podría replicarse sin problema en 5,000 líneas de código de Python. Eso es muy factible, pero el problema es que, si haces eso, de repente no puedes esperar realizar una fructífera sesión de trabajo de tres horas con tus estudiantes de supply chain. Estarás llevando a cabo una sesión de tres horas pura de codificación en la que simplemente se tratará de descubrir cómo analizar un archivo CSV, lo cual no es muy interesante desde la perspectiva de supply chain.
Conor Doherty: Y Paul, solo una pregunta de seguimiento sobre esto. ¿Qué tan desafiantes son estas habilidades de ingeniería, como la codificación, para el estudiante promedio de supply chain a nivel fundamental?
Paul Jan: Puedo darles un ejemplo del mundo real donde empezamos el semestre hace un par de semanas aquí. Diría que tal vez el 20% de esta nueva clase tiene algún tipo de experiencia previa en codificación, pero en ese caso, habían tomado, por ejemplo, Python en un entorno de aula antes. Así que la mayoría no la tiene. Entonces, cuando entran, creo que están emocionados porque se dan cuenta de que esta es una habilidad que les beneficiará en el futuro ya que hay muchas cosas, muchos más datos, y Excel simplemente se vuelve engorroso cuando se trata de analizar tal gran cantidad de datos. Así que la codificación ayuda a simplificar este proceso. Pero al mismo tiempo, también están un poco asustados, preocupados porque no tienen la experiencia. Es una habilidad muy importante ahora, pero también es algo que falta en la formación de los estudiantes de negocios, no solo de supply chain, sino de negocios en general.
Conor Doherty: Bueno, gracias. Y eso de hecho transiciona perfectamente. Joannes, algo que he esperado mucho tiempo preguntar. Has descrito en el pasado en tus lecciones los problemas de supply chain como siendo complejos. Así que, dos partes en esta pregunta. Una, ¿qué es exactamente lo que quieres decir con problemas complejos en supply chain? Y dos, siguiendo lo que acaba de decir Paul, ¿por qué herramientas como Excel simplemente no están equipadas para enfrentarse a estos problemas complejos?
Joannes Vermorel: La noción de un problema complejo no se origina en mí. Es esencialmente problemas que desafían un análisis directo de primer nivel. Es algo en lo que tiene que haber un camino, sin importar qué, en el que se descubrirá el propio problema.
Un ejemplo de eso es, ¿qué es un buen anuncio? Si te pido calcular el área superficial de una figura geométrica en pulgadas cuadradas o centímetros cuadrados, la figura puede ser muy complicada, por lo que el cálculo podría ser difícil, pero es un problema cerrado. Existe una solución analítica que te dará ya sea la respuesta exacta o una muy buena aproximación.
Pero si te pregunto qué es un buen anuncio, la respuesta realmente depende, y también depende de lo que estén haciendo tus competidores. Por ejemplo, si creas un anuncio fantástico, pero luego tus competidores te copian tanto que tu anuncio, que era brillante, ahora se vuelve indistinguible de toda la competencia; fue un muy buen anuncio pero se convirtió en un mal anuncio solo porque todos lo han copiado.
Ese es el tipo de complejidad. La misma respuesta que das puede potencialmente deshacer la respuesta en sí misma. Es algo raro. Doy una muy buena respuesta y, debido a que es tan buena, se copia y, al ser copiada, se convierte en una mala respuesta. Ese es un tipo de problema complejo.
La supply chain está llena de problemas complejos. Decides ubicar un centro de distribución en algún lugar para superar a otro. Ese otro decide replicar y responde reorganizando sus propios centros de distribución para superarte. Ese es el tipo de situación.
Así que las cosas no son estables. Una respuesta no es estable. Estos problemas complejos son problemas en los que hay una competencia intrínseca. Hay personas que responden a lo que haces. Esto no es como el problema de calcular la superficie de una figura geométrica, que es un problema en el que la respuesta no depende de lo que el resto del universo esté haciendo, de lo que otras personas decidan. Esto está bien aislado.
Y luego también tienes problemas en los que ni siquiera estás seguro de si estás enmarcando el problema correctamente. ¿Qué significa calidad de servicio? Sí, podemos decir que la calidad de servicio se trata de aumentar el nivel de servicio, pero la realidad es que la calidad de servicio está en el ojo del cliente y ¿qué significa siquiera? Es una pregunta muy difícil.
Para algunas personas, podrían pensar que si hay sustitutos, está bien. No esperan que este producto esté disponible. Tal vez si hay sustitutos, está bien. Otras personas pueden no estar de acuerdo. Podrían tener una concepción muy estrecha de lo que realmente necesitan y decir: “Quiero exactamente este código de barras o no funciona.”
Y luego, dependiendo del mensaje que tenga la empresa, de la comunicación más amplia, en realidad podrías amplificar o disminuir si las personas ven otros productos como sustitutos o no. Si tienes una comunicación que dice que esto es completamente único, que no hay sustituto alguno, entonces no te sorprendas de que las personas ni siquiera estén dispuestas a tomar otros de tus propios productos como sustitutos porque esa es tu comunicación. Eso podría ser bueno contra la competencia, pero puede ser más desafiante si quieres convencer a la gente de aceptar alternativas.
Las situaciones son increíblemente variadas. Así que, en resumen, sobre estos problemas complejos, y ese es un pensamiento típico de Lokad, es que generalmente cuando tienes estos problemas complejos, es mejor iterar sobre el problema con datos en lugar de operar sin ellos.
No importa la pregunta que se haga, como si es un buen anuncio, es más fácil responder a esta pregunta si puedes medir las ventas y correlacionar un poco con tu gasto en publicidad, por ejemplo. No significa que resolverá la pregunta completamente, pero estarás más informado en lugar de tratar de responder esta pregunta sin ningún dato.
Usualmente, incluso si estás lidiando con un problema complejo, tener datos disponibles ayuda. El problema es que, debido a la naturaleza compleja, necesitas ser capaz de revisar tu posición sobre qué tipo de analítica y procesamiento implica que no habrá una respuesta única para todos. Procesarás los datos y luego pensarás y, quizás, formularás una pregunta ligeramente diferente dependiendo de lo que esté sucediendo.
Entonces, los problemas complejos, ahí es donde entramos nosotros. Cuando te enfrentas a un problema complejo, tener datos es bueno porque te permite estar más informado, lo cual generalmente es mejor. Pero también significa que tendrás que repetir tu análisis de vez en cuando porque no habrá una respuesta definitiva.
Excel es bueno en este aspecto. Excel te permite revisar tu análisis tan frecuentemente como quieras. El problema es que Excel no escala a la medida que las supply chain modernas requieren. Hoy en día hablamos de decenas de miles de productos, millones de transacciones, muchos datos transaccionales. Excel simplemente no es adecuado para eso.
El desafío clave es que los datos de la supply chain moderna exceden lo que razonablemente puede caber en Excel, y exceden en dos formas. Primero, exceden en el número de líneas. Excel está limitado a un millón de líneas. Pero esta parte en realidad no es el gran problema. En teoría, Microsoft podría reingenierizar Excel un poco y hacer que se extienda a 100 millones de líneas. Eso no es imposible, y de hecho, hay algunos competidores de Excel que pueden hacer eso.
Pero cuando decimos que una supply chain moderna excede, es porque, fundamentalmente, Excel tiene una mentalidad de una sola tabla a la vez. Asume que los datos son como una única tabla plana. Pero la realidad es que los datos transaccionales que se encuentran en una supply chain son de múltiples tablas. Tienes una tabla para proveedores, una tabla para transacciones, una tabla para clientes, una tabla para productos, una tabla para colores o formas o lo que sea.
Entonces, muy frecuentemente acabarás tratando con al menos media docena de tablas. Y lo que te falta es algo parecido a un álgebra relacional, que es realmente el núcleo de tus datos transaccionales. Tus datos en supply chain son transaccionales y relacionales. Tienes, como, media docena de tablas, y ahí es donde Excel realmente no funciona.
No solo tienes esa restricción en cuanto al número de líneas, sino que esto podría arreglarse. Pero, en términos generales, tienes este problema de que estás limitado en cuanto a semántica. Excel no te ofrece esa capacidad de trabajar con múltiples tablas.
Y, a propósito, esto se debe a que Microsoft ni siquiera se ha preocupado en ampliar ese límite de 1 millón. La gente en Microsoft sabe, y lo han sabido desde hace mucho tiempo, que incluso si pueden extenderlo a 100 millones de líneas, la siguiente etapa será, “Oh, necesitamos varias tablas,” y entonces no funcionará muy bien con Excel.
Por eso la respuesta de Microsoft fue, “Si quieres datos relacionales, tienes SQL Server, o tienes herramientas que tratan los datos relacionales como ciudadanos de primera clase,” en lugar de tratar de meter eso en una hoja de cálculo. Y, a propósito, esto es también algo que estamos tratando de hacer con este playground, es exponer a los estudiantes a esta realidad de los datos relacionales ofreciendo un lenguaje que tenga los datos relacionales como ciudadanos de primera clase.
Porque eso es algo que creo que no va a cambiar. Dentro de cuarenta años, los ERP aún tendrán tablas y columnas. Esto se estableció hace cuatro décadas, así que ha sido un aspecto muy estable de la supply chain digital por más de cuatro décadas.
Conor Doherty: Paul, un punto interesante para profundizar allí, ya que tienes una extensa experiencia en el sector privado y fuiste formalmente entrenado en este campo. Cuando estabas surgiendo y desarrollando tu experiencia, supongo que trabajaste con Excel. Y, de ser así, ¿en qué momento dijiste, “Necesito considerar opciones más ricas y programáticas”? Entonces, ¿qué causó la divergencia de Excel?
Paul Jan: La divergencia es lo que Joannes aludió antes. Excel es genial, ya sabes, es una especie de una sola tabla a la vez, y resulta muy engorroso vincular todas estas tablas o pestañas dentro de Excel. E incluso si tienes éxito en hacerlo, también es otra tarea que consume mucho tiempo si necesitas cambiar tus supuestos o variables para verificar todos los cambios que has realizado en Excel.
Muchas veces surgen errores. Casi siempre se cometen fallos al final porque olvidaste cambiar esta variable o ese supuesto, lo que hace que el resultado final se vea algo diferente. Así que, creo que fue tal vez hace un par de años cuando tuve la oportunidad de aprender SQL. No conocía SQL antes, pero lo aprendí en uno de los proyectos, y realmente aprecié el lenguaje y también el poder que tienes para procesar y simplificar, al menos en la primera parte, la de encontrar los datos descriptivos y tratar de detectar las anomalías dentro de los datos.
Esto simplifica al menos la primera parte, encontrar los datos descriptivos y tratar de detectar las anomalías dentro de los datos. Asegurarte de que los datos estén limpios y encontrar formas de integrar diferentes fuentes de datos realmente simplificó las cosas bastante. Fue entonces cuando realmente hice una transición. En ese momento, SQL se convirtió en mi primera opción de herramientas analíticas a las que recurrir para procesar, o más bien preprocesar, los datos para entender cómo se ven y si hay alguna anomalía. Luego, realizaría el primer análisis descriptivo a partir de eso, y Excel se usaría más por la facilidad de visualización. Una vez que eso estuviera completo, lo visualizaríamos más fácilmente con Excel haciendo gráficos y estadísticas.
Me gustaría añadir a lo que Joannes mencionó sobre descubrir a Lokad. Yo también descubrí a Lokad hace un par de años, pero no tomé una iniciativa similar a la que tomé el año pasado para introducirlo a los estudiantes. Debo decir, sinceramente, que temía que el aspecto de codificación desanimara a los estudiantes de utilizar la herramienta y de disfrutar o aprender en la clase. Pero debo decir que estaba equivocado. Dado los últimos meses de nuestras colaboraciones, descubrí que Envision es una herramienta muy fácil de entender. Incluso con mi experiencia en programación y bases de datos, es muy sencilla de comprender, y creo que también es más fácil para los estudiantes porque los códigos se pueden leer casi como en un lenguaje llano.
Es diferente de, por ejemplo, Python y otros, donde a veces las cosas pueden no tener tanto sentido y no se siguen unas a otras sin la explicación de quien escribió el programa. Hasta ahora, ha sido un ejercicio muy útil introducir esto. Realmente simplificó el proceso de ajustar los supuestos, esas cosas que quizás no habíamos considerado en los datos, pero actualizarlos en el código mismo y luego reflejarlos en el dashboard para que el estudiante lo vea.
Todavía lo llamo un nivel introductorio. Para los estudiantes, es para que entiendan, a un nivel general, desde una perspectiva de arriba hacia abajo, lo que hace una empresa y cómo lo hace a partir de estos datos descriptivos, como el número de clientes que tienen, las mayores ventas, la tendencia ABC de su producto. A partir de ahí, pueden comprender cómo configuran las supply chain, y luego profundizamos en su supply chain a partir de ahí. Así que tener este programa, esta experiencia de codificación con Envision, realmente ha ayudado drásticamente en ese aspecto y también ha reducido los errores que podríamos cometer en Excel.
Conor Doherty: Seguiré con vos, Paul, y luego con Joannes. Entonces, bienvenidos, es una pregunta filosófica que les gustará. Se me ocurre que hemos hablado de las herramientas, entonces Envision es la herramienta, pero usar o aprovechar una herramienta viene con una mentalidad. Como acabas de aludir, algo que es la base de lo que Lokad hace con Envision es tomar una perspectiva puramente financiera a los problemas de supply chain y reducir los errores en dólares o euros. Esto es una mezcla, supongo, de economía, pero también es algo filosófico, entendiendo que si hago esto, no puedo hacer aquello, costo de oportunidad.
En términos de mentalidad, entender cómo usar estas herramientas, ¿es eso algo que también tienes que enseñar en la clase o los estudiantes simplemente entienden automáticamente, “Oh sí, costo de oportunidad, simplemente usaré esta herramienta y les queda muy claro”?
Paul Jan: No diría que es algo inmediatamente obvio, pero los estudiantes han recibido formación en economía, así que entienden lo que significa el trade-off, el costo de oportunidad. Incluso en la clase básica de supply chain o de operaciones que enseño aquí, introducimos a los estudiantes al costo excedente, costo de salvamento, y los diferentes costos que pueden venir con la decisión que tomas acerca de cuánto inventario almacenar y cuándo. Estos son comprensibles y relacionables para los estudiantes una vez que les explicas que la forma en que elaboramos este resultado financiero se basa en ABC.
En la práctica, estos resultados financieros son lo que también intentamos cuantificar para los ejecutivos en cualquier tipo de proyecto de consultoría. Los ejecutivos entienden que cuando les dices que este es su costo en dólares o la oportunidad en dólares. Pero para la gente de supply chain, o de operaciones, se rigen mayormente por las métricas tradicionales, las rotaciones, forecast accuracy. Ellos entienden, pero prestan más atención a eso. Así que hay una pequeña brecha entre lo que entienden los ejecutivos y lo que los operativos, o al menos lo que se les instruye a seguir. Desde el punto de vista del estudiante, introducir o explicar estos conceptos no es una tarea difícil.
Conor Doherty: Gracias, Paul. Y Joannes, te vuelvo a ceder la palabra. Nuevamente, basándome en lo que se acaba de decir, entiendo perfectamente por qué cosas como Python, SQL, y obviamente Envision, nuestro lenguaje de dominio específico, pueden resultar desconocidas para los nuevos practicantes de supply chain. Pero el concepto de recursos escasos, usos alternativos, la base de la economía, tiene más de un siglo de antigüedad. Entonces, ¿por qué ese aspecto de la mentalidad económica sería tan diferente en los círculos de supply chain en comparación con, como Paul acaba de describir, que se entiende de forma intuitiva en el aula?
Joannes Vermorel: Me gustaría, primero, comentar la observación de Paul. Cuando dijiste que te preocupaba usar Envision, creo que tenías razón. Sólo para la audiencia, mi creencia personal es que la gran mayoría del enterprise software es una completa porquería, literalmente completa porquería. Y al adquirir software, te estoy mirando a ti. Por ello, es comprensible asumir, por defecto, que va a ser pura porquería y luego llevarse la grata sorpresa si resulta lo contrario. Pero creo que es un supuesto razonable. Creo firmemente que Envision no está en esa categoría, hicimos un buen trabajo. Pero, de nuevo, es razonable esperar por defecto que el enterprise software sea de muy baja calidad, especialmente en comparación con los populares proyectos open source. Es un supuesto justo y muy racional respecto al panorama de las aplicaciones.
Ahora, lo del enfoque mental financiero, y cuando Paul mencionó ABC como en el costeo basado en actividades –por cierto, no ABC analysis, por supuesto–, la cuestión es que resulta muy difícil pensar en problemas si no puedes imaginar la solución. Entonces, cuando la gente dice que quiere pensar en términos de precisión o nivel de servicio, estas son métricas muy clásicas. El tema es que, si lo único que tienes es una hoja de cálculo en Excel, prácticamente eso es todo lo que podrías implementar. Por lo tanto, si sólo puedes pensar en términos de hojas de cálculo, se te complica abordar esos temas porque necesitas pensar en el problema. ¿Cómo voy a convertir todo eso en dólares cuando se te hace realmente difícil pensar en la solución?
La gente a menudo piensa en la solución antes que en el problema. Es muy difícil incluso enunciar un problema sin haber concebido primero una solución. Primero te topas con una solución aproximada y luego, cuando quieres explicar lo que has hecho a otra persona, en realidad inventas el problema que se ajusta a la solución. Instintivamente, la gente imagina primero la solución y, para poder comunicarla, inventa el problema.
Tu capacidad para pensar en soluciones depende de las herramientas que tienes disponibles en tu mente. Si en tu mente sólo cabe Excel, entonces todas las soluciones que puedas concebir serán aquellas que pueden funcionar en Excel. Esto te limita al paradigma de precisión y nivel de servicio, porque son precisamente esas las cosas que puedes hacer en Excel.
Por eso es tan importante en los cursos fundamentales familiarizar a los estudiantes con mejores herramientas, donde puedan pensar, por ejemplo, con tablas, columnas y conceptos como SQL. El problema no es SQL en sí, sino el paradigma que obtienes con SQL: tablas, filtros, agregaciones, columnas, tipos de valores como cadenas frente a números, booleanos. Estas cosas son muy importantes y, de repente, cuando dispones de estos paradigmas, puedes concebir clases de soluciones más elaboradas.
Para pensar en indicadores financieros, necesitas conectar el costo del almacenamiento, por lo que requieres otra tabla que te proporcione algunas suposiciones sobre ese costo. Necesitas también conocer el costo del faltante de stock, así que esa información debe estar disponible en otro lugar. No es que tradicionalmente la gente sea incapaz de pensar en el costo del almacenamiento o el costo del seguro, lo sabe. Pero cuando se trata de imaginar una solución, si lo único que pueden concebir es una hoja de cálculo, es muy difícil para ellos imaginar una hoja capaz de conectar esas 20 variables distintas.
Pero si puedes pensar con datos relacionales, de repente cuentas con las herramientas que te permiten decir: “Está bien, simplemente voy a conectar todos esos costos con tantas tablas como sea necesario.” Y, conceptualmente, si esos costos son individualmente simples, es solo cuestión de agregarlos todos.
Esta es una explicación larga, pero es también la razón por la que la gestión tradicional de supply chain es tan reticente. No tuvieron la oportunidad de recibir una educación en la que realmente pudieran pensar con herramientas más modernas.
Paul Jan: Estoy completamente de acuerdo con la evaluación de Joannes. Si hiciéramos una evaluación de competencias en las operaciones de supply chain de cualquier empresa, creo que hallarías una gran brecha en su comprensión de lo que acabamos de discutir. Ese es, en efecto, el reto de educar a esta nueva generación de jóvenes profesionales en una mentalidad que les impulse a pensar de manera diferente e innovar.
Joannes Vermorel: He estado enseñando durante siete años, no supply chain, sino computación distribuida e ingeniería de software. Mi filosofía, cuando enseñaba en el Eon Normal Superior de París, donde tenía total libertad para decidir qué impartir, era centrarme en temas que siguieran siendo relevantes dentro de cuatro décadas.
Mi mayor temor era enseñar algo que resultara ser solo una moda, algo que, dentro de cinco años, te dieras cuenta de que era simplemente una tecnicidad y ya hubiera desaparecido. Así que mi enfoque siempre fue preguntarme: ¿es esto algo que soportará la prueba del tiempo? ¿Que dentro de 40 años tenga muy buenas probabilidades de seguir siendo relevante?
Por ejemplo, SQL se ha establecido como un estándar desde 1989. Ha ido evolucionando, pero la mayor parte no ha cambiado desde entonces. El modelo subyacente, los datos relacionales, no han cambiado desde finales de los 70. Ha demostrado un éxito increíble, con prácticamente el 99% del mercado ERP utilizando este formato de datos relacionales de una u otra forma.
La gente tiene la impresión de que las tecnologías digitales cambian constantemente, que hay que aprender algo nuevo y que en dos años desaparecerá. Creo que ese es un problema, ya que da la impresión de que ese conocimiento es desechable. Además, da una falsa señal a la dirección de que pueden omitirlo, ya que en dos años será otra cosa.
Si se hace correctamente, contamos con muchos temas que son muy fundamentales. La estructura de datos relacionales sería uno de ellos. Los tipos básicos de datos, texto, booleanos, números, ya eran así a finales de los 70. Incluso Python 3, la última versión, todavía tiene eso en su núcleo. Es algo que es muy poco probable que cambie durante las próximas cuatro décadas.
De manera similar, si pensamos en forecast, la idea de cómo proyectar el futuro, series de tiempo, cuáles son las limitaciones de las series de tiempo, qué nos proporciona un forecast de series de tiempo, qué no ofrece, y qué es lo que este método no puede dar por diseño, eso tampoco cambiará. El forecast más básico, dentro de cuatro décadas, seguirá siendo un forecast de series de tiempo diario, semanal o mensual, y sus limitaciones serán las mismas.
Si tuviera que enseñar forecast, en lugar de centrarme en cuál es el mejor modelo de forecast de series de tiempo, que cambiará, me concentraría en las suposiciones inherentes que se tienen con el forecast de series de tiempo, lo que te ofrece y lo que no, y en las peligrosas limitaciones, además de cómo abordar la incertidumbre.
Entiendo que es un reto muy grande. La mayoría de los profesores universitarios no tuvieron el lujo que yo tuve, en el que a la administración no le importaba en lo más mínimo lo que realmente estaba enseñando.
Conor Doherty: Paul, cuando enseñas forecast de demanda en clase, ¿abordas las distribuciones de probabilidad, para comprender la incertidumbre del futuro?
Paul Jan: En la clase fundamental, lo discutimos, y también en gestión de demanda, forecast, y control de inventario. Pero partimos de la suposición de que las variabilidades, las incertidumbres, siguen la distribución normal, lo que facilita mucho la enseñanza.
Sin embargo, al aplicar el enfoque probabilístico, que analiza la probabilidad de variaciones para un producto, puedes representarlo gráficamente. La gente es visual, así que puede entender por qué un producto se comporta de manera diferente a otro.
Este semestre, estoy considerando incorporar contenido de la clase avanzada en la clase básica como una forma de explicar las incertidumbres y variaciones de manera más visual.
Joannes Vermorel: Hacer fuertes suposiciones con fines pedagógicos está bien. Recuerdo que cuando estaba en la universidad, un profesor de física simplificaba los cálculos asumiendo que una vaca era una esfera. Obviamente, una vaca no es una esfera, pero por el bien del ejercicio, es razonable permitir a los estudiantes hacer un cálculo simplificado. Esto les ayuda a experimentar con los conceptos sin enredarse en los cálculos.
Sin embargo, en el mundo de supply chain, la gente hace suposiciones equivalentes, como asumir que la demanda se distribuye normalmente. Esta es una suposición educativa que no se sostiene en el mundo real. No obstante, los proveedores de enterprise software optan por ello e incorporan estas suposiciones de manera codificada en su software. Esto es una locura. Es como si General Motors codificara suposiciones sobre esferas y pasajeros en sus autos. La gente pensaría que esto es disparatado. No deberías hacer eso para un auto real que va a circular en el mundo real.
Sin embargo, de manera extraña, los proveedores de software de supply chain dicen que no hay problema en tener estas suposiciones codificadas en su software. Esta es mi reacción ante el status quo en esta industria, el cual encuentro algo disparatado. Hace falta una disrupción. Por alguna rara razón, parece que los proveedores de software de supply chain están trasladando estas absurdas suposiciones, introducidas para fines pedagógicos, directamente a su software.
Pero quizás no sea justo exigir eso a los profesores. Tal vez sean los propios proveedores de enterprise software de supply chain quienes necesiten enfrentarse a la realidad.
Conor Doherty: Eso era justamente lo que estaba a punto de preguntar. Desde la perspectiva de Paul en la Rotman School of Management, es su responsabilidad enseñar estos conceptos. Pero, para Lokad, un proveedor de software de supply chain, ¿por qué es la educación algo tan importante? ¿Por qué enfocarse tanto en esto?
Joannes Vermorel: Supply chain es una colección de problemas complejos debido a que estamos reuniendo todas las fuerzas de las empresas. Por definición, supply chain es lo que mantiene unida a la empresa, lo que implica integrar ventas, producción, transporte, marketing, finanzas, todo en conjunto. Esto no es algo sencillo. Las empresas modernas operan en numerosos países, así que no sólo tienes ventas versus marketing, sino que también puedes tener Francia versus Italia versus España.
Supply chain es una serie de problemas complejos, ya sea por diseño o por la naturaleza misma de conectar en supply chain a tantos intereses en conflicto tanto dentro como fuera de la empresa. Necesitamos pensar en términos de paradigmas y herramientas que nos permitan abordar estos problemas complejos, aunque sea de forma aproximada. En lugar de optar por lo aproximadamente correcto, la gente opta por lo exactamente equivocado y se aferra a muchas recetas numéricas que son mucho más precisas de lo que deberían ser.
Conor Doherty: Nos estamos acercando al final, pero quiero devolverte la palabra. La concepción de supply chain de Joannes me resulta profundamente filosófica. Cuando hablamos de problemas de primer y segundo orden, es casi como Wittgenstein. Tengo curiosidad, ¿adoptas tú un enfoque filosófico similar respecto a supply chain? ¿La administración siquiera te lo permite? ¿Desde el primer día, tenemos que replantear toda la esfera de las filosofías de supply chain? ¿Es este el tipo de cosas que le dices a los estudiantes, que debemos replantear por completo la rueda, o es algo más gradual?
Paul Jan: Es gradual y también disruptivo. En la universidad, a medida que un estudiante va aprendiendo, comienza por los fundamentos, luego asiste a alguna clase intermedia de gestión de operaciones de supply chain, y finalmente llega a una clase más avanzada que estoy impartiendo este semestre en colaboración con Lokad. Gradualmente aprenden las teorías y aplicaciones tradicionales. Pero luego llega la disrupción cuando, al menos por mi experiencia, no sé cómo enseñar a los estudiantes la complejidad de supply chain sin que ellos la vivan. Por ello trabajamos con una empresa. Manejan datos reales y piensan con una herramienta. Ven la complejidad, la incertidumbre, y se dan cuenta de que lo aprendido en los cursos anteriores no se puede aplicar de forma directa. Se puede hacer, pero quizá no tenga sentido.
Entonces, es una cuestión filosófica. Y, por cierto, este es un problema abierto. Si visitas la página de Wikipedia sobre Problemas Complejos, verás que todas las disciplinas que enfrentan este tipo de problemas –donde una buena o mala respuesta a la enunciación de un problema depende de lo que hagan los demás– son increíblemente difíciles de enseñar. No es algo exclusivo de supply chain; hay otras áreas donde resulta increíblemente difícil.
Joannes Vermorel: Incluso hay áreas donde, por ejemplo, recientemente tuvimos un invitado sobre trading en mercados públicos, donde si llegas a revelar siquiera cómo lo haces, socavas tu propia solución y, por ende, tu propia fuente de ingresos. Así que el secreto es primordial en estos casos. Si entiendes algo, profesionalmente no deberías hablar al respecto, porque si lo haces, la gente lo usará en tu contra.
Pero mi postura es que Lokad seguirá intentándolo. Seguiremos apoyando a las buenas universidades que, como la University of Toronto, tratan de avanzar en esta dirección. No esperamos una solución definitiva, pero cualquier paso en esa dirección ya es mejor que pretender que ni siquiera existe.
Conor Doherty: Exactamente, aproximadamente correcto. Bueno, Paul, aquí es costumbre ceder la última palabra al invitado. ¿Hay algo que te gustaría decir o aconsejar a la gente, o a tus estudiantes, sobre los exámenes finales?
Paul Jan: Aún no tengo consejos para los finales, pero me gustaría retomar el comentario de Joannes sobre por qué el sector privado está invirtiendo en educación. Inviertes en conferencias, artículos y blogs, y lo aprecio. Muchos de estos estudiantes, tras graduarse, recurren a proveedores, suministradores y sitios web para encontrar información o para comprender qué es la gestión de supply chain, o simplemente para refrescar la memoria.
Por ejemplo, las estadísticas son una asignatura que da mucho miedo a los estudiantes. Así que, no asumir únicamente que todo es normal facilita mucho las cosas porque quita ese miedo. Pero si tienes sustancia real para respaldar diferentes comportamientos, entonces ellos pueden estar más dispuestos a aprender a superar ese miedo. Después de la universidad, tu información se vuelve más accesible para ellos, por lo que se convierte en un refuerzo para sacarnos de esta mentalidad de que podemos aplicar la misma solución a todos los diferentes problemas perversos.
Conor Doherty: Perfecto. Con respecto a eso, en realidad no tengo más preguntas. Joannes, gracias por tu tiempo.
Joannes Vermorel: Muchas gracias por lo tuyo y por tu colaboración continua.
Conor Doherty: Y gracias a todos por ver. Nos vemos la próxima vez.
