Pablo Medina (Corona): IA para la toma de decisiones en almacenes
“La inteligencia artificial empieza por una decisión, no por una tecnología”
IA con impacto en las operaciones
El curso ejecutivo sobre inteligencia artificial desarrollado por el MIT CTL y Mecalux ofrece a directivos una visión práctica de cómo aplicar esta tecnología a la toma de decisiones en la cadena de suministro. El programa combina sesiones ejecutivas, casos de estudio y talleres prácticos orientados a identificar aplicaciones de alto valor que generen resultados de negocio.
Pablo Medina es uno de los asistentes de la primera edición del curso ejecutivo sobre inteligencia artificial organizado por el MIT CTL y Mecalux. El gerente de Distribución de la multinacional Corona, dedicada a la fabricación de productos para el hogar y la construcción, comparte su experiencia desde el Massachusetts Institute of Technology.
-
¿Cuál fue su principal aprendizaje del curso ejecutivo en el MIT?
Que la inteligencia artificial empieza por una decisión, no por una tecnología. Llegué pensando en algoritmos y salí pensando en preguntas más simples: ¿qué decisión queremos mejorar?, ¿quién la toma?, ¿cada cuánto y cómo la medimos hoy? Sin esa línea base, ningún piloto puede demostrar nada.
El segundo aprendizaje fue entender que el machine learning y la optimización son socios, no rivales. El curso mostró cinco niveles de integración, desde no usar IA hasta modelos que lo deciden todo. La mayor parte del valor probado en almacenes está hoy en los dos primeros: el modelo predice y la herramienta de planificación sigue mandando.
La regla que me traje es elegir el nivel más simple que resuelva el cuello de botella. Para una cadena integrada como la de Corona, eso cambia la conversación: no se trata de cuánta IA ponemos, sino de en qué decisión y con qué nivel de profundidad.
Pablo Medina construyó un modelo de optimización para Corona junto con el MIT durante el curso -
¿Qué ideas le resultaron más interesantes?
Me resultó muy útil ver cada tipo de machine learning aplicado a un caso real. Durante el curso analizamos cómo distintas empresas han utilizado estos modelos en sus operaciones. Uber Freight, por ejemplo, empleó el aprendizaje no supervisado, que descubre patrones sin etiquetas, para localizar instalaciones a partir de la agrupación de puntos GPS de camiones detenidos. También vimos casos de aprendizaje supervisado, que aprende a partir de datos con la respuesta correcta, como los drones de IKEA que leen etiquetas en las estanterías o el modelo de Zalando que imita a su algoritmo de enrutamiento para estimar recorridos en milisegundos. Otro de los ejemplos presentados fue el de Amazon, que aplicó el aprendizaje por refuerzo ─basado en probar distintas decisiones en un entorno simulado─ a las compras de inventario.
De los casos que vimos en el curso, el que más me marcó fue el modelo supervisado desarrollado por el MIT CTL, que predice tiempos de tránsito en forma de rango, en lugar de dar un único valor. Un trayecto estimado de 10 días parece mejor que uno de 11, hasta que ves que el primero puede variar más de dos días y el segundo apenas medio día. En Colombia, donde la geografía y las vías hacen que el transporte sea muy variable, esa diferencia es clave para definir inventarios de seguridad, citas de muelle y turnos.
También me hizo pensar en el caso de Amazon: su modelo para decidir cuánto comprar de cada producto prometía una reducción del inventario de cerca del 23% en simulación, pero al final la cifra disminuyó a un 12% en una prueba real de 26 semanas. Fue un buen resultado, pero la lección es medir antes de escalar.
-
¿Hubo algo que le hiciera replantearse su visión sobre la IA?
Lo que más cuestionó mi visión fue descubrir que la IA no es neutral. Un estudio del MIT mostró que un copiloto de IA generativa no solo mejoraba las decisiones, sino que también influía en la importancia que las personas daban al riesgo y a la rentabilidad a la hora de decidir. Por eso, el grado de autonomía debe definirse para cada tipo de decisión, con un responsable claro.
El machine learning y la optimización son socios, no rivales
-
¿El curso le ha ayudado a identificar nuevas oportunidades para la IA en su empresa? ¿Cómo lo aplicaría a un reto concreto de Corona?
El curso me dio un marco para un reto que ya teníamos. En Corona construimos con el MIT un modelo de optimización para el llenado de vehículos y la planificación de rutas, y aprendimos que el algoritmo es solo una parte. La otra es que los usuarios puedan trabajar con él y que los datos de entrada sean fiables.
El curso mostró cómo los agentes de IA pueden coordinar herramientas de optimización. Un agente supervisor recibe un objetivo, como despachar los pedidos del día siguiente. Un agente de datos consulta los sistemas y valida la información, el optimizador construye el plan y un agente de ejecución lo convierte en tareas y alertas. Las personas fijan metas y límites, aprueban excepciones y toman el control cuando hay dudas.
La clave es avanzar por etapas. Primero, datos fiables y un copiloto que explique el plan; después, más autonomía solo donde los errores sean baratos y reversibles. Lo plantearía como un piloto de 90 días en un centro de distribución: primero en paralelo con la operativa actual y después de forma asistida, con criterios claros para continuar o parar.
Las ventajas en productividad aparecen en las tres etapas del proceso. En la entrada, los agentes validan pedidos, pesos, dimensiones, ventanas de entrega y flota disponible antes de cada ejecución. Así, el modelo de llenado (bin packing) y el de planificación de rutas (VRP) trabajan con datos completos y se evitan ejecuciones repetidas. En el proceso, el planificador evalúa escenarios en minutos y se concentra en las excepciones, en lugar de ajustar planes a mano. En la salida, un agente convierte el plan en secuencias de carga, instrucciones y alertas, y registra cada desviación para corregir los datos de la siguiente ejecución. El resultado esperado es mayor ocupación por vehículo, menos viajes y kilómetros, menos horas de planificación y planes que se ejecutan tal como se diseñaron.
-
¿Qué fue lo que más valoró del intercambio de experiencias con directivos de otros sectores?
La autonomía se debe otorgar decisión por decisión, con un responsable claro Descubrir que los problemas se parecen mucho más de lo que creía. En mi mesa había personas del sector retail, la industria manufacturera y las operaciones logísticas, y casi todos reconocíamos la misma dificultad: datos dispersos, decisiones tomadas en silos y pilotos que nunca pasan a la fase operativa.
Eso le da sentido a algo que el curso enfatizó: los patrones se transfieren entre industrias. Un caso de transporte de carga o de comercio electrónico puede enseñarle mucho a una empresa manufacturera como la nuestra si uno se pregunta dónde existe esa misma decisión en su operación.
También valoré el papel de “amigo crítico”. En los talleres, mis compañeros cuestionaron mis líneas base y mis supuestos con una franqueza difícil de encontrar dentro de la propia empresa. Y aprendí que cuando varios equipos comparten el mismo supuesto de riesgo, no es un problema de una compañía: es una brecha de toda la industria.
-
¿Qué le diría a un colega que estuviera considerando participar en un curso similar?
Que vaya, pero que no vaya con las manos vacías. El curso se aprovecha mucho más si uno llega con una decisión real de su operación, con un responsable y con algunos números sobre cómo funciona hoy, aunque sean rangos.
También le diría que no espere un curso de programación. El valor está en salir con un método para pensar: cómo leer un caso, cómo escoger el tipo de aprendizaje adecuado, con qué nivel de profundidad integrarlo y cómo diseñar un piloto que termine en una decisión y no en una demostración.
Por último, que piense desde el principio en las personas. Los modelos son la parte más fácil; lo difícil es lograr que supervisores, áreas de TI y proveedores de software confíen en el resultado y lo usen. Y que, al volver, envíe la primera solicitud de datos esa misma semana, porque ahí empieza de verdad el piloto.