Si está leyendo esto es porque en este portal ya leyó cosas interesantes o porque alguien lo recomendó o porque va a evaluar el contenido por primera vez. Pero, de todos modos, a veces es difícil saber si estamos frente a un experto o, por lo menos, frente a buenas recomendaciones.

Mi recomendación: contraste lo que lee con su experiencia y haga el ejercicio de validar la lógica de lo que le proponen. Una manera es verificar “efecto-causa-efecto”, como decía el Dr. Goldratt. Es decir, si nos proponen que un efecto tiene cierta causa, podemos predecir que, si esa causa existiera, también debería existir otro efecto. Esto también se conoce en Teoría de Restricciones como “reserva de efecto predicho”. Veamos un ejemplo reciente.

«The Future of Commerce Trend Report 2022» (Por Shopify.com)

No creo que esté mostrando aquí un portal desconocido, y es fuente de artículos y de reportes muy acabados, como el “The Future of Commerce Trend Report 2022” (Descargar reporte), que me recomendaron recientemente. Es un reporte de 140 páginas y en la 105 encuentro la segunda recomendación para la cadena suministro: “Redistribuya inventario más cerca de sus clientes”, y en el detalle dice:

«La redistribución de su inventario a lugares más cercanos a sus clientes reduce los costes al mantener la mercancía dentro de zonas de envío, lo que le permite ofrecer envíos en el mismo día o en dos días sin incurrir en costes adicionales, y aumenta la resiliencia frente a los problemas regionales de la cadena de suministro.

Si tiene un negocio de venta al por menor, considere la posibilidad de convertir las tiendas en minicentros de distribución. La conversión de una sola tienda minorista en un minicentro de cumplimiento tiene el potencial de reducir los costes de última milla en más de un 60%. Estos espacios híbridos de venta al por menor son también una oportunidad para ofrecer opciones de recogida en la acera y de «click-y-cobrar».»

Vamos por partes.

Primera afirmación: enviar (incurrir en un costo de flete) a una ubicación cercana a sus clientes, permitiría enviar (otro costo de flete) en un tiempo de uno o dos días, pero dice que sin incurrir en costos adicionales.

Aquí hay supuestos que habría que validar para que esta afirmación sea correcta en los dos aspectos: «que reduce costo y que reduce tiempo». Los supuestos son:

Segunda afirmación: la tienda como mini-CD (…) aumenta la resiliencia frente a los problemas regionales de la cadena de suministro. Supongo que se refiere a que usar la tienda como punto de acopio para ventas con plazos cortos de entrega (1 – 2 días) contribuye a mitigar los problemas asociados con los frecuentes faltantes y excedentes de stock (¿hay otros “problemas regionales”?). Y es que, si la tienda tiene alta disponibilidad de todos los SKUs, no veo porqué un cliente esperaría uno o dos días. 🤔

Es decir, como tenemos problemas para mantener disponibilidad a un costo razonable en las tiendas, convenzamos a los clientes de pedir y esperar el envío desde el CD a la tienda, para que sea retirado o enviado desde la tienda. Así no tenemos el problema del agotado en tienda. (¡Pero precisamente esto era para resolver la falta de disponibilidad en tienda y no se resuelve!). Seamos justos, acá brindaríamos al cliente visibilidad sobre la disponibilidad: Si en todo momento sabe qué no hay, su opción es esperar. 🚨 También tiene la opción de comprar a la competencia.

Yo soy comprador por internet y espero más de dos días, pero si voy a una tienda, espero encontrar de entrega inmediata. Hace poco busqué unas pilas especiales en una tienda por departamentos y las encontré en el sitio web. Acto seguido fui a la tienda física a comprarlas, para encontrarme con la sorpresa de que eso solo se vende por internet (supongo que hay que leerlo todo en la página). Hice la compra por internet, pero a otro proveedor. O sea que no les sirvió de nada usar la tienda como mini-CD en ese caso. Además, que es “mini-HUB”, o sea que es de paso, no de acopio.

Y la tercera afirmación es que podría reducir el costo de última milla en más de un 60% usando las tiendas como mini-CDs. Me parece que quedó establecido que, si es entrega a domicilio, menos viajes reducen el costo, no lo contrario. Pero, además, si se trata de entrega a domicilio desde la tienda, eso ya es posible si la tienda mantiene buena disponibilidad en primer lugar. ⚠️ Y buena disponibilidad no implica necesariamente que la tienda se convierta en un mini CD ⚠️

No. La solución a la mala disponibilidad y a los excedentes no es usar las tiendas como mini-CD (¿no son eso hoy sin ponerles nombres complicados?). La solución ya la he descrito en otros artículos y es simple: Por ejemplo, los invito a revisar Cross Docking ¡No lo intente en casa!.

Conclusión

Después de analizar estas recomendaciones, el resto del reporte pierde mucha fuerza. Decir cosas que parecen novedosas pero que son lo mismo de siempre con otras palabras, o directamente son erróneas, me llevó a escribir esta alerta, y también a ser más exigente conmigo mismo al hacer recomendaciones.

Matías Birrell Rodríguez

De profesión, ingeniero civil de industrias, con mención en mecánica, con un MBA en finanzas. Pero principalmente, experto en Teoría de Restricciones y autor de libros acerca de este tema, habiendo trabajado y aprendido directamente con el Dr. Goldratt en Goldratt Group. Adicionalmente es director de www.goldfish.cl, empresa que ofrece aplicaciones en la nube, simples y asequibles, para aplicar estos conceptos a las decisiones diarias.

¿Quieres optimizar tus procesos? Contáctame

La entrada Recomendaciones de expertos en management, ¿cómo filtrarlas? se publicó primero en Ingenieria Industrial Online.

Traducción Libre de Javier Arévalo – Goldratt Consulting Partner Latin America

El comercio del retail moderno, como muchos otros ámbitos y campos, ya no es solo un simple juego de oferta y demanda como antes, si es que alguna vez lo fue. En nuestra realidad actual, los consumidores lo quieren todo, aquí y ahora. Cada vez más servicios pasan por la digitalización y la personalización, y los retailers están conscientes de que el uso de la tecnología ya no es una opción, sino una necesidad. Con interminables posibilidades de mejoras tecnológicas en diferentes ámbitos en esta industria y un limitado presupuesto de IT; la pregunta del millón es: ¿Qué tipo de tecnología tengo que adoptar para crear una verdadera diferencia comercial?

Según mi experiencia durante los últimos 15 años, todos los retailers están de acuerdo en que la principal limitación en este tipo de comercio, es el tráfico. No obstante, éste se encuentra entre las variables más difíciles de predecir en un mundo en constante cambio que se enfrenta a la pandemia de Covid-19 en los últimos años. Sin embargo, los retailers exitosos son aquellos que tienen capacidades integradas para convertir altos porcentajes de su tráfico en compradores, con un ticket promedio más alto y un mejor margen de utilidad.

La necesidad de un nuevo modelo de gestión de la moda y el comercio retail en la era post-Covid-19

Con el brote de Covid-19, el mundo ha cambiado drásticamente y a la par el retail y la industria de la moda. La pandemia aceleró algunas tendencias que comenzaron antes de su aparición y uno de los cambios más impactantes, fue la rápida transición de los clientes a plataformas online. Para las marcas tradicionales de establecimientos físicos y las cadenas de retail, esta transición significa una competencia feroz en términos de precio y servicio con las plataformas de comercio electrónico ya establecidas, y al mismo tiempo hace que el tráfico en sus tiendas físicas sea errático, lo que impacta directamente la rentabilidad de las tiendas.

Además, este cambio puso de manifiesto otros desafíos, desde la necesidad de los retailers para reaccionar rápidamente, hasta las preferencias de los consumidores que cambian de una tendencia a otra, e incluso se enfrentan a la escasez de mano de obra, lo que en algunos casos ha dificultado el funcionamiento de las tiendas físicas.

También, toda la gestión del flujo y la cadena de suministro enfrentan desafíos sin precedentes, ya que las operaciones del retail a nivel global tienen retrasos y costos cada vez mayores. Por ello, cualquier predicción a largo plazo es cada vez más desafiante y la precisión de los pronósticos se deteriora constantemente. Por ejemplo, ¿cómo pueden los retailers de moda planificar su inventario, cuando ni siquiera están seguros de que llegarán a sus tiendas a tiempo para el inicio de la temporada? En esta realidad caótica, se vuelven esenciales las predicciones a corto plazo y la capacidad de controlar el inventario, las ventas y la rotación del producto durante la temporada de compras.

Asimismo, en un mundo que se vuelve cada vez más ecológico, crece la conciencia de los costos ambientales causados por el exceso de producción. Con las malas predicciones de hoy, la sostenibilidad no se podrá asegurar.

La trampa de la venta a precio completo

En general, las temporadas en la moda se planifican con mucha anticipación. A lo largo de mi extensa carrera con profesionales de este campo en todo el mundo, he notado algunos factores clave que influyen en este flujo de trabajo. Los retailers determinan los estilos, las cantidades y otros parámetros claves, como la moda predominante y la forma en que se distribuirá la ropa entre las tiendas, lo cual generalmente toma de 6 a 12 meses previos al inicio de una temporada. Sin embargo, los retailers saben que es imposible vender el 100 por ciento de la mercancía a precio completo por diversas razones. Los expertos retailers de moda pueden terminar la temporada con un 85 por ciento o incluso un 90 por ciento de ventas de productos a precio completo; sin embargo, sólo entre el 50 y el 75 por ciento de las ventas están en el precio completo y el resto se vende con grandes descuentos durante las rebajas de fin de temporada.

No hace falta ser un experto para entender por qué las ventas a precio completo en la moda son tan bajas. Cuando un amplio surtido se actualiza constantemente en la tienda en función de las predicciones, que se hicieron mucho antes de que comenzara la temporada, es inevitable terminar con una alta cantidad de productos que se mueven lentamente en los estantes. De hecho, es común ver que a medida que comienzan las ventas de fin de temporada, hasta el 50 por ciento del surtido de una tienda contribuye a menos del 5 por ciento de las ventas.

Los productos de baja rotación se acumulan con el tiempo, reducen el atractivo de las estanterías y bloquean el espacio disponible para nuevas colecciones. Dichos artículos también son el principal motor de los grandes descuentos a los que estamos acostumbrados a ver en los anuncios de «fin de temporada».

Pero la moda también genera «best-sellers», que son productos de rápido movimiento, es decir, se venden más rápido de lo previsto originalmente y por lo tanto se quedan sin existencias con mayor prontitud. Esos son los productos que nos gustan en exhibición, pero aprendimos que ya se han agotado. En tanto, el inventario de los productos de bajo movimiento se acumula en la temporada de “best-sellers”,lo  que reduce la capacidad de la tienda para convertir el tráfico en compradores.

Las ventas de fin de temporada son la oportunidad de los retailers para liquidar los productos de bajo movimiento y comenzar la próxima temporada de nuevo. No podemos salir de la espiral de liquidación, si nos limitamos a pensar que esos productos son los villanos; esto sólo nos llevará a criticar nuestra planificación y tratar de optimizar nuestras acciones dentro del enorme ruido. Hay que mirar la realidad con mayor resolución para entender la causa y efecto.

La basura de una tienda es el tesoro de otra

Los productos de lento y rápido movimiento, son en su mayoría, definiciones específicas de su ubicación. De hecho, hay malos productos con diseños y precios incorrectos que no se pueden vender sin un gran descuento; sin embargo, la mayoría de los que se mueven lentamente en una tienda, en realidad son los “best- sellers” en otras. Es decir, mientras veíamos que estos productos bloqueaban las estanterías de algunas tiendas, en realidad eran necesarios para las ventas en otras, donde los productos se agotaron demasiado pronto en la temporada.

Si tuviéramos el algoritmo adecuado para identificar estos productos de movimientos lentos y rápidos en tiempo real tan pronto como comenzara la temporada, podríamos tomar medidas inmediatas para garantizar que el producto correcto llega al lugar y momento indicados para maximizar su venta a precio completo.

Predicción a corto plazo, automatización y optimización

Las cifras y las tendencias actuales demuestran la importancia de que los retailers presten atención y se centren en la predicción a corto plazo y la toma de decisiones de manera inmediata. Según mi experiencia, una de las mejores maneras de lograrlo es cambiar nuestro enfoque de tener un mejor plan hacia la adopción de tecnologías que se adapten a la temporada.

Dichas tecnologías se basan en herramientas de predicción que ayudan a los retailers a predecir a corto plazo y automatizar los procesos de mercadeo en las tiendas. La precisión de las estimaciones a corto plazo impacta en las ventas y las ganancias de la temporada, y optimiza los traslados de reabastecimiento entre tiendas así como la gestión de los productos de rápido movimiento, la liquidación de los de lento movimiento y el surtido general de la tienda durante la temporada.

Después de más de una década de trabajar en el comercio retail, y tras cientos de conversaciones con líderes internacionales del retail, sé con certeza que el uso y la implementación de esas herramientas logran un aumento de entre 5 y 10 por ciento en las ventas por tienda durante todo el año, y una mejoría del 20 por ciento en las ventas de temporada a precio completo. Además, como las acciones se traducen en resultados inmediatos, el rendimiento se puede medir con precisión y en tiempo real.

Más allá de las mejoras financieras, con esta tecnología los retailers pueden transitar más rápido hacia una política de cero residuos, ya que estos algoritmos les ayudarán a no dejar productos en los estantes y estar un paso adelante de la industria del retail convencional.

Roei Raz

Vicepresidente de ventas de Onebeat y exconsultor de los principales grupos del retail alrededor del mundo. Raz tiene una Licenciatura en Ingeniería Industrial y un MBA, ambos de la Universidad de Tel Aviv.

Goldratt Consulting América Latina

La entrada ¿Qué tipo de tecnología tengo que adoptar para crear una verdadera diferencia comercial? | Retail se publicó primero en Ingenieria Industrial Online.

¿Para qué está su empresa en el negocio? ¿Para ganar dinero? Yo sé que esa fue la respuesta en el libro La Meta, sin embargo he visto muchas declaraciones de misión y ninguna dice eso. El dinero es un resultado de cumplir la misión de la empresa. En la continuación del libro La Meta, el Dr. Goldratt nos dice que una buena estrategia tiene tres condiciones necesarias. En los últimos capítulos de No Fue La Suerte, la discusión de Alex con los directores lleva a concluir que los tres pilares de una buena estrategia son: generar un buen entorno a empleados ahora y en el futuro; dar excelente servicio a clientes ahora y en el futuro; y generar buena rentabilidad para accionistas ahora y en el futuro.

Cualquier misión debería ser consistente con esas condiciones necesarias.

¿Dónde inicia todo?

Es fácil darse cuenta de que sin ventas no hay empresa. Y que, habiendo competencia, debemos construir una ventaja competitiva que nos destaque y haga fluir las ventas basadas en intercambio de valor.

Todas las empresas que están vendiendo algo han logrado construir una oferta compuesta de un producto que tiene una relación precio/calidad atractiva. De otro modo no venderían.

Diseñar o encontrar esos productos, luego producirlos o comprarlos, hacer un buen empaque, producir materiales de marketing atractivos, la inversión en publicidad, el despliegue de la fuerza de ventas; todo esto es un gran esfuerzo en tiempo y dinero.

Y la promesa que se le hace al mercado consiste en el producto, el precio y una condición de entrega. La entrega puede ser prometiendo un plazo, o puede ser prometiendo disponibilidad en el punto de venta.

Todo inicia haciendo una promesa atractiva y los clientes la aceptan, generándose las ventas.

¿Qué pasa cuando se incumple la promesa?

Las ventas no se detienen inmediatamente. Hay una frustración de los clientes que se traduce en buscar alternativas. Pero veamos cuál es la parte de la promesa que se incumple con más frecuencia.

Ni el producto se degrada con frecuencia ni el precio se altera con frecuencia. Estos dos aspectos son muy cuidados por las empresas.

Lo habitual es que se incumpla la entrega, ya sea incumpliendo el plazo prometido o simplemente generando un agotado (quiebre o stock out) en el punto de venta.

Los competidores no son mucho mejores en la entrega, pero esto solo genera más frustración.

Tal vez el efecto más nocivo sea al interior de las empresas. El incumplimiento de entrega genera inmediatamente quejas desde el mercado, lo que se traduce en emergencias, reprogramaciones, sobre costos, y mucho stress.

¿Cómo se siente usted cuando incumple un plazo de entrega? ¿O cuando más del 10% de sus productos están agotados en las tiendas? Estos hechos generan una onda de presión a lo largo y ancho de la organización. Por lo menos estoy seguro de que no son fuente de satisfacción para nadie.

¿Y si un competidor tuviera un nivel de servicio muy superior? Es muy probable que las ventas bajen y los márgenes se erosionen. Ahora ya nadie está contento.

La causa del incumplimiento

Las consecuencias de incumplir la promesa son muchas y negativas, eso ya lo intuíamos.

Y basta con tener un poco de experiencia para saber que los incumplimientos son muy frecuentes.

¿Por qué será que, sabiendo lo mal que todos lo pasan al incumplir, las empresas siguen haciendo promesas que incumplen?

Una explicación podría ser que a algunos gerentes no les importa mentir y prometen cosas para conseguir más ventas. Pero ya sabemos que incumplir tiene demasiadas consecuencias negativas, por lo que esta explicación no puede ser la mayoritaria. Son muchas las empresas que incumplen sus promesas de entrega y deben ser muy pocas o ninguna las que basen su estrategia de ventas en mentir.

Entonces, ya que los hechos nos muestran un incumplimiento masivo, la explicación debe ser que se prometen plazos o stock sin tener seguridad de cumplirlo, aunque la intención sea de no fallar, lo que se manifiesta en todas las acciones para resolver las emergencias y la frustración que sienten los responsables.

Es decir, la causa del incumplimiento es simplemente que se está aplicando un conocimiento para hacer la promesa con alta probabilidad de ser incumplida.

¿Y existe alguna solución?

Si la mayoría de las empresas incumple, pareciera que no existe una buena solución, porque si existiera ¡todo el mundo la estaría usando!

No sé cómo se le llama a esa falacia argumental, pero es claramente una falacia. Si algo existe y es muy bueno, todo el mundo debería estar usándolo. (Creo que es falacia ad populum).

Me acordé de un libro que escribió Jeff Cox (coautor de La Meta), El hombre que quiso vender la rueda. Empieza con el invento de la rueda y se la va a ofrecer a constructores de pirámides para elevar la productividad, y le responden algo así: “¿quién está usando esto?, si fuera tan bueno, ya muchos lo usarían, ¿no?”

El conocimiento para calcular una fecha de entrega razonable y que sea altamente probable su cumplimiento existe, es el Control de Carga de Teoría de Restricciones.

El conocimiento para calcular y mantener inventarios adecuados en toda la cadena de suministro existe, es la Administración Dinámica de Amortiguadores de Teoría de Restricciones.

Estos dos métodos son efectivos, nunca he visto un caso de fracaso y son simples de implementar. Pero tienen una “trampa”. Para implementarlos hay que abandonar varias de las creencias que damos por válidas sin cuestionar y que son la base de las metodologías que hoy se usan para prometer fechas o para calcular inventarios. Y los esfuerzos de mejora actuales no cuestionan las creencias básicas, por lo que los resultados prevalecientes siguen siendo los que ya conocemos.

Conclusión

El nivel de servicio, en especial la entrega a tiempo (OTIF) o la disponibilidad (FILL RATE), no son solo unos KPIs para medir la gestión. En empresas con productos físicos, es una condición necesaria para una buena estrategia. Sin ese nivel de desempeño excelente, la vida de los clientes no es tan buena, y mucho peor es la experiencia interna en las empresas, muchas veces causa del “síndrome del trabajador quemado” (ver https://blog.goldfish.cl/consultoria/mundo-vuca-empresa-vuca/). Y, como resultado, la rentabilidad está limitada.

Es posible, y debería ser indispensable, lograr excelente servicio para cimentar una empresa en que valga la pena trabajar, y a la que uno desee comprarle.

Matías Birrell Rodríguez

De profesión, ingeniero civil de industrias, con mención en mecánica, con un MBA en finanzas. Pero principalmente, experto en Teoría de Restricciones y autor de libros acerca de este tema, habiendo trabajado y aprendido directamente con el Dr. Goldratt en Goldratt Group. Adicionalmente es director de www.goldfish.cl, empresa que ofrece aplicaciones en la nube, simples y asequibles, para aplicar estos conceptos a las decisiones diarias.

¿Quieres optimizar tus procesos? Contáctame

La entrada Nivel de servicio: ¿es solo un KPI? se publicó primero en Ingenieria Industrial Online.

Las organizaciones que gestionan operaciones cada vez más robustas, requieren en cierto modo de la asignación de personas y recursos a tareas específicas. Desde hace algún tiempo se ha popularizado un planteamiento en torno al objetivo de la logística, generalmente aceptado como: «El objetivo de la logística consiste en llevar el producto correcto, en la cantidad correcta, en el lugar correcto, en el momento correcto» (acepta variaciones).

Ahora bien, tendencias de optimización abordan nuevos objetivos y plantean nuevos desafíos alrededor de la intralogística: optimización extrema. Es decir, optimización en la asignación de recursos internos, como por ejemplo: el recurso correcto, asignado a la tarea correcta, en el momento correcto.

Cuando aterrizamos el anterior planteamiento en términos prácticos, entendemos que se hace necesario resolver problemas de programación complejos de forma regular, que permitan la gestión de las operaciones de la organización. Un caso puntual consiste en la programación del recurso humano, sujeta a un conjunto complejo de restricciones y requisitos: número de empleados, días laborales, turnos, tiempos inactivos, permisos, políticas internas, etc.

El planteamiento de nuevos desafíos de optimización, guarda una estrecha relación con la posibilidad que nos brinda la tecnología de abordar estos retos. Si bien, la complejidad de las organizaciones es cada vez mayor, los algoritmos cada vez son más refinados, y los solucionadores cada vez más robustos e integrados.

El objetivo de este artículo consiste en utilizar las técnicas robustas del solucionador basado en restricciones OR-Tools de Google, para resolver un problema de programación de empleados sujeto a un conjunto complejo de restricciones.

Caso de aplicación

La compañía Stark Lab ha adquirido un nuevo torno para su área de mecanizado. El volumen de trabajo que tiene el área, demanda que esta nueva máquina sea operada en los 3 turnos del día (mañana, tarde y noche).

La compañía ha contratado a 3 trabajadores para operar la nueva máquina, y planea emplear a un aprendiz (estudiante) como cuarto operario.

El supervisor debe diseñar una programación para los cuatro operarios para un periodo de 7 días (una semana), sujeto a las siguientes condiciones:

• Cada día se divide en tres turnos de 8 horas.
• Todos los días, cada turno se asigna a un solo operario, y ningún operario trabajará más de un turno por día.
• El último día de la programación se realizan actividades de mantenimiento y limpieza profunda en planta. Por tal razón, solo se trabaja el turno de la mañana.
• El operario aprendiz (estudiante), cuenta con la colaboración de la compañía para realizar sus estudios. Por tal razón, no puede trabajar el tercer día de la semana en el turno de la noche.
• Como mínimo deben trabajarse 19 turnos en total en la programación. Esta cantidad de turnos ya considera los turnos destinados a mantenimiento y limpieza del último día de la programación.
• En el caso en el que no se pueda realizar una distribución de turnos igualitaria, la distribución de los turnos debe realizarse de manera uniforme. Esto quiere decir que no puede existir una diferencia mayor a un turno entre las asignaciones para cada operario.

Se desea desarrollar una programación de empleados (asignación de empleados, turnos y días), que cumpla con las restricciones del planteamiento.

¿Qué necesitaremos?

En el desarrollo de este ejercicio emplearemos:

Paso 1: Crear el entorno de trabajo en Colaboratory

Lo primero que vamos a hacer consiste en crear un entorno de trabajo en Google Colaboratory, así que vayamos allá: Abrir cuaderno nuevo.

Verán que tienen un lienzo para programar el modelo, así que en este cuaderno podemos ir generando las líneas de código que explicaremos en los pasos siguientes.

Paso 2: Instalar Google Or Tools

Es necesario instalar la librería de Google Or Tools en nuestro entorno de Colaboratory para poder utilizar nuestro modelo de programación entera.

!pip install ortools

Al ejecutar esta instrucción instalaremos el software del solucionador de Google.

Paso 3: Importar las librerías necesarias

Este modelo empleará programación entera, y por lo tanto instalaremos las librerías dispuestas por Google OR Tools para ello. En este caso utilizaremos un solucionador de programación entera llamado CP-SAT.

#Importar la librería para utilizar CP-SAT
from ortools.sat.python import cp_model

De esta manera, tenemos todo lo necesario para empezar a desarrollar nuestro código.

Paso 4: Crear los datos de entrada del modelo

Los datos de entrada de un problema de programación de empleados suelen ser simples, la complejidad recae en el modelamiento de las restricciones. En este caso, los datos de entrada básicos son: número de empleados, número de turnos por día, número de días del plan de programación.

#Datos de entrada del modelo
operarios = 4
turnos = 3
dias = 7
total_operarios = range(operarios)
total_turnos = range(turnos)
total_dias = range(dias)

turnos_no_laborales = 2
turnos_laborales = (turnos * dias) - turnos_no_laborales

Así mismo, definimos el número de turnos no laborales, recordemos que el planteamiento del problema nos indicó que el último día se trabajaría tan solo un turno (por labores de mantenimiento y limpieza), por lo tanto, dos turnos pueden considerarse como no laborales.

¿Por qué utilizamos una variable llamada operarios y otra llamada total_operarios? Además, ¿Para qué se emplea la función range? Bueno, la variable operarios contendrá el valor entero de la cantidad de operarios del modelo; mientras tanto, la variable total_operarios dado que emplea la función range, contendrá la secuencia de números que nos ayudará a definir a cada operario, lo hace de esta manera: range(4) = 0, 1, 2, 3. Como podemos ver, inicia la secuencia en 0, y finaliza en el entero anterior al parámetro dado, en este caso el parámetro dado fue 4, por lo tanto, el entero anterior será 3.

Paso 5: Crear el modelo de programación

#Crear el modelo
model = cp_model.CpModel()

Paso 6: Crear las variables de asignación

El problema de programación de empleados es un caso de asignación, y por lo tanto, empleamos variables de decisión de asignación. Veamos:

Necesitamos definir qué operario será asignado a qué turno en qué día en específico. Por lo tanto podemos utilizar variables de asignación binarias, que tomen un valor de 1, si esa asignación específica tiene lugar, y tomen valor de 0, en el caso en el que no.

Algebraicamente sería algo así:

En el caso en el que tuviésemos que definir manualmente cada una de las variables de asignación, requeriríamos un total de 84 variables (7 días * 3 turnos * 4 operarios).

Veamos cómo podemos utilizar los ciclos en Python para simplificar la definición de las variables – Eso sí, en lugar de X llamaremos a la variable asignacion, y en lugar de a, b y c, utilizaremos la primera letra de cada parámetro.

# Creamos las variables de asignación
# asignacion[(o, d, t)]: operario 'o' trabaja en el turno 't' el día 'd'.
asignacion = {}
for o in total_operarios:
    for d in total_dias:
        for t in total_turnos:
            asignacion[(o, d, t)] = model.NewBoolVar('turno_n%id%is%i' % (o, d, t))

De esta manera, haciendo uso de ciclos, creamos todas las variables de asignación del modelo; así mismo, definimos su naturaleza (NewBoolVar = Variable booleana). De manera que en el caso de que una asignación se efectúe su resultado será «verdadero / True».

Paso 7: Crear las restricciones del modelo

La complejidad de un problema de programación de recursos se define por la naturaleza de sus restricciones. Si bien las restricciones acotan el conjunto solución, y por ende los tiempos de procesamiento, la dificultad subyace del modelamiento. Veamos cómo abordar cada una de las restricciones que nos plantea el caso de aplicación.

Cada turno se asigna a un solo operario

La sumatoria de todas las asignaciones efectuadas en un día d, en el turno t, deben ser menores o iguales a 1. Eso restringe la posibilidad de que un mismo turno, en un mismo día, sea asignado a dos operarios diferentes.

Por ejemplo:

X₀₀₀ + X₁₀₀ + X₂₀₀ + X₃₀₀ <= 1

Esta restricción nos diría que la sumatoria de todas las asignaciones del día 0, para el turno 0, de los operarios 0, 1, 2 y 3; debe ser menor o igual a 1. Es decir que el turno 0, del día 0 no puede ser asignado a más de un operario.

Veamos cómo Python nos puede simplificar esta formulación de restricciones:

# Cada turno es asignado a un operario en el periodo de programación, o no es asignado
for d in total_dias:
    for t in total_turnos:
        model.Add(sum(asignacion[(o, d, t)] for o in total_operarios) <= 1)

Esta restricción bien podría formularse como que la sumatoria deba ser igual a 1. Sin embargo, recordemos que existen un par de turnos no laborales, y por lo tanto estos no deben ser asignados.

En el caso en el que tuviésemos que definir manualmente cada una de estas restricciones, requeriríamos un total de 21 restricciones (7 días * 3 turnos).

Cada operario trabaja como máximo un turno por día

La sumatoria de todas las asignaciones efectuadas en un día d, para el operario o, deben ser menores o iguales a 1. Eso restringe la posibilidad de que un operario, en un mismo día, sea asignado a dos turnos diferentes.

Por ejemplo:

X₀₀₀ + X₀₀₁ + X₀₀₂ <= 1

Esta restricción nos diría que la sumatoria de todas las asignaciones del día 0, para el operario 0, de los turnos 0, 1, y 2; debe ser menor o igual a 1. Es decir que el operario 0, del día 0 no puede ser asignado a más de un turno.

Veamos cómo Python nos puede simplificar esta formulación de restricciones:

# Cada operario trabaja como máximo un turno por día
for o in total_operarios:
    for d in total_dias:
        model.Add(sum(asignacion[(o, d, t)] for t in total_turnos) <= 1)

En el caso en el que tuviésemos que definir manualmente cada una de estas restricciones, requeriríamos un total de 28 restricciones (7 días * 4 operarios).

Restricción del operario aprendiz

De acuerdo al caso de aplicación, el operario aprendiz no pude trabajar el tercer día de la semana, en el turno de la noche. Esto nos permite abordar restricciones de requerimientos puntuales sobre el modelo.

Recordemos que el índice, tanto de operarios, turnos y días, comienza en 0. Por lo tanto, para efectos de la formulación de la restricción, el tercer día de la semana será el día 2 (los siete días de la semana son 0, 1, 2, 3, 4, 5 y 6); y el turno de la noche, será el turno 2 (turnos 0, 1 y 2 / mañana, tarde y noche).

Por otro lado, los operarios también son nombrados de acuerdo a sus índices: 0, 1, 2 y 3. Podemos arbitrariamente elegir el índice del operario aprendiz; en nuestro caso diremos que se trata del operario 0.

#Restricción del operario (o) 1 para trabajar el día (d) 2, en el turno (t) 2
model.Add(asignacion[(0, 2, 2)] != 1)

El operador != se utiliza para denotar diferente de, por lo tanto, la restricción indica que la asignación del operario 0, el día 2, en el turno 2, deberá ser diferente de 1; es decir que, al tratarse de una variable booleana, deberá ser Falso = 0.

Restricciones de turnos no programados (mantenimiento y limpieza)

De acuerdo al caso de aplicación, el último día de la semana se programan actividades de mantenimiento y limpieza, y que por lo tanto, solo se trabaja en el turno de la mañana. Por esta razón, debemos excluir a los turnos de la tarde y la noche de la programación (turnos 1 y 2) del último día (día 6).

Siguiendo con nuestras denominaciones algebraicas de ejemplo, tendríamos algo así:

X₀₆₁ + X₁₆₁ + X₂₆₁ + X₃₆₁ == 0

X₀₆₂ + X₁₆₂ + X₂₆₂ + X₃₆₂ == 0

Veamos cómo Python nos puede simplificar esta formulación de restricciones:

# Restricción de turnos no programados
model.Add(sum(asignacion[(o, 6, 1)] for o in total_operarios) == 0)
model.Add(sum(asignacion[(o, 6, 2)] for o in total_operarios) == 0)

Restricción de turnos mínimos programados

De acuerdo al caso de aplicación, debe programarse una cantidad de 19 turnos laborales. Es decir, la cantidad de turnos diarios (3) * la cantidad de días del programa (7); menos la cantidad de turnos no programados por mantenimiento y limpieza (2).

#Como mínimo deben trabajarse "turnos_laborales"
min_turnos_totales = []
for o in total_operarios:
    for d in total_dias:
        for t in total_turnos:
            min_turnos_totales.append(asignacion[(o, d, t)])
model.Add(sum(min_turnos_totales) >= turnos_laborales)

Esta restricción involucra a todas las variables de asignación del modelo, y por lo tanto el uso de ciclos es importante para simplificar el desarrollo de la formulación. Básicamente indica que la sumatoria de todas las variables de decisión (asignación) del modelo (que son booleanas, y para este efecto podemos decir que binarias), debe ser mayor o igual al mínimo de turnos laborales exigidos para programación.

La restricción es 1 sola, pero involucra las 84 variables de asignación.

Restricción de uniformidad en la distribución de turnos

El objetivo de estas restricciones es la de distribuir de la manera más uniforme posible los turnos asignados. En términos prácticos, el caso de aplicación indica que, no puede existir una diferencia mayor a un turno entre las asignaciones de los operarios. Es decir, ningún operario podrá tener asignados dos turnos más que otro operario, por ejemplo.

Para lograr esto es necesario realizar una serie de cálculos intermedios sencillos, con el objetivo de identificar: número de turnos asignables, cantidad mínima de turnos por operario, cantidad máxima de turnos por operario, entre otros.

min_turnos_por_operario = ((turnos * dias) - turnos_no_laborales) // operarios
if ((turnos * dias) - turnos_no_laborales) % operarios == 0:
    max_turnos_por_operario = min_turnos_por_operario
else:
    max_turnos_por_operario = min_turnos_por_operario + 1
for o in total_operarios:
    num_turnos_trabajados = []
    for d in total_dias:
        for t in total_turnos:
            num_turnos_trabajados.append(asignacion[(o, d, t)])
    model.Add(min_turnos_por_operario <= sum(num_turnos_trabajados))
    model.Add(sum(num_turnos_trabajados) <= max_turnos_por_operario)

Lo primero que hicimos fue calcular la parte entera de la fracción entre el número de turnos asignables y los operarios; lo que nos indica la cantidad mínima de turnos por operario. Veamos con un ejemplo:

(turnos * días) – turnos no laborales // operarios

(3 turnos por día * 7 días) – 2 turnos // 4 operarios

(3 * 7) – 2 // 4

19 // 4 = 4 turnos por operario

Esto indica que existe la posibilidad de asignar al menos 4 turnos por cada operario. Lo siguiente que se debe considerar es la cantidad máxima de turnos por operario.

En el caso en el cual la cantidad que resulte de dividir el número de turnos asignables entre el número de operarios sea entera sin decimales, esto indicaría que la distribución de los turnos puede realizarse en partes iguales, y por lo tanto la cantidad máxima de turnos por operario será equivalente a la cantidad mínima de turnos por operario.

En los casos en los que esto no ocurra, la cantidad máxima de turnos por operario será equivalente a la cantidad mínima de turnos por operario más 1. Recordemos que la restricción nos indica que la diferencia entre asignaciones de turnos a operarios no puede ser mayor de un turno.

Por todo lo demás, las restricciones de este paso consisten en establecer que la cantidad de turnos asignados por operario deberá ser mayor que la cantidad mínima de turnos por operario y deberá ser menor que a cantidad máxima de turnos por operario.

Paso 8: Crear el solucionador y enumerar las soluciones

# Creal (invocar) el solucionador y resolver
solver = cp_model.CpSolver()
solver.parameters.linearization_level = 0
# Enumerar las posibles soluciones
solver.parameters.enumerate_all_solutions = True

Paso 9: Configurar las salidas del modelo

Este paso consiste en configurar el formato de salida de las soluciones posibles. De forma arbitraria hemos determinado que se impriman las primeras 2 soluciones (solution_limit), de tal manera que el formato de salida tendrá la siguiente estructura:

• Solución i
  • Día d
    • Operario o, trabaja / no trabaja, en el turno t.

class OperariosParcialesSolucion(cp_model.CpSolverSolutionCallback):
    """Print intermediate solutions."""

    def __init__(self, asignacion, operarios, dias, turnos, limit):
        cp_model.CpSolverSolutionCallback.__init__(self)
        self._asignacion = asignacion
        self._operarios = operarios
        self._dias = dias
        self._turnos = turnos
        self._solution_count = 0
        self._solution_limit = limit

    def on_solution_callback(self):
        self._solution_count += 1
        print('Solución %i' % self._solution_count)
        for d in range(self._dias):
            print('Día %i' % d)
            for o in range(self._operarios):
                is_working = False
                for t in range(self._turnos):
                    if self.Value(self._asignacion[(o, d, t)]):
                        is_working = True
                        print('  Operario %i trabaja en el turno %i' % (o, t))
                if not is_working:
                    print('  Operario {} no trabaja'.format(o))
        if self._solution_count >= self._solution_limit:
            print('Detenga la búsqueda después de  %i soluciones' % self._solution_limit)
            self.StopSearch()

    def solution_count(self):
        return self._solution_count

# Muestra las primeras 2 soluciones.
solution_limit = 2
solution_printer = OperariosParcialesSolucion(asignacion, operarios, dias, turnos,
                                                    solution_limit)

Paso 10: Invocar al solucionador y configurar algunas estadísticas

Por último, nos queda invocar al solucionador, y configurar algunos datos estadísticos para enriquecer las salidas del modelo.

solver.Solve(model, solution_printer)

# Estadísticas.
print('\nEstadísticas')
print('  - conflictos      : %i' % solver.NumConflicts())
print('  - ramas de búsqueda       : %i' % solver.NumBranches())
print('  - tiempo de solución      : %f s' % solver.WallTime())
print('  - soluciones encontradas: %i' % solution_printer.solution_count())

Al ejecutar el programa completo, tendremos la siguiente salida:

• Solución 1
  • Día 0
    • Operario 0 no trabaja
    • Operario 1 trabaja en el turno 1
    • Operario 2 trabaja en el turno 2
    • Operario 3 trabaja en el turno 0
  • Día 1
    • Operario 0 no trabaja
    • Operario 1 trabaja en el turno 0
    • Operario 2 trabaja en el turno 2
    • Operario 3 trabaja en el turno 1
  • Día 2
    • Operario 0 trabaja en el turno 0
    • Operario 1 no trabaja
    • Operario 2 trabaja en el turno 2
    • Operario 3 trabaja en el turno 1
  • Día 3
    • Operario 0 trabaja en el turno 1
    • Operario 1 trabaja en el turno 0
    • Operario 2 trabaja en el turno 2
    • Operario 3 no trabaja
  • Día 4
    • Operario 0 trabaja en el turno 1
    • Operario 1 trabaja en el turno 0
    • Operario 2 no trabaja
    • Operario 3 trabaja en el turno 2
  • Día 5
    • Operario 0 trabaja en el turno 2
    • Operario 1 trabaja en el turno 0
    • Operario 2 no trabaja
    • Operario 3 trabaja en el turno 1
  • Día 6
    • Operario 0 trabaja en el turno 0
    • Operario 1 no trabaja
    • Operario 2 no trabaja
    • Operario 3 no trabaja
• Solución 2
  • Día 0
    • Operario 0 no trabaja
    • Operario 1 trabaja en el turno 1
    • Operario 2 trabaja en el turno 2
    • Operario 3 trabaja en el turno 0
  • Día 1
    • Operario 0 no trabaja
    • Operario 1 trabaja en el turno 0
    • Operario 2 trabaja en el turno 2
    • Operario 3 trabaja en el turno 1
  • Día 2
    • Operario 0 trabaja en el turno 0
    • Operario 1 no trabaja
    • Operario 2 trabaja en el turno 2
    • Operario 3 trabaja en el turno 1
  • Día 3
    • Operario 0 trabaja en el turno 1
    • Operario 1 trabaja en el turno 0
    • Operario 2 trabaja en el turno 2
    • Operario 3 no trabaja
  • Día 4
    • Operario 0 trabaja en el turno 1
    • Operario 1 trabaja en el turno 0
    • Operario 2 no trabaja
    • Operario 3 trabaja en el turno 2
  • Día 5
    • Operario 0 trabaja en el turno 1
    • Operario 1 trabaja en el turno 0
    • Operario 2 no trabaja
    • Operario 3 trabaja en el turno 2
  • Día 6
    • Operario 0 trabaja en el turno 0
    • Operario 1 no trabaja
    • Operario 2 no trabaja
    • Operario 3 no trabaja

Detenga la búsqueda después de 2 soluciones

Estadísticas
– conflictos : 973
– ramas de búsqueda : 1730
– tiempo de búsqueda : 0.044052 s
– soluciones encontradas: 2

Hemos formulado un modelo con 84 variables de decisión, 55 restricciones y algunos cálculos intermedios. Podemos observar cómo el modelo ha logrado encontrar soluciones que satisfacen las restricciones planteadas (formuladas). Del mismo modo, podemos observar el tiempo en el cual ha logrado el solucionador hallar la cantidad de soluciones solicitadas (fracciones de segundo).

Es interesante percibir las bondades de este tipo desarrollos, y considerar las posibilidades de aplicación en otros campos diferentes a la programación de empleados; teniendo en cuenta la flexibilidad de la programación basada en restricciones, la potencia de los solucionadores y la capacidad de procesamiento de los equipos en la actualidad.

El código completo de este desarrollo lo puedes encontrar en nuestro cuaderno: Programación de empleados.

La entrada Programación de empleados mediante programación entera se publicó primero en Ingenieria Industrial Online.

Tal como lo hemos abordado ampliamente, una de las aplicaciones más importantes del modelamiento de Cadenas de Suministro, es el diseño de red de abastecimiento, y dentro de esta categoría, el diseño de rutas de transporte (enrutamiento de vehículos).

Los problemas de enrutamiento de vehículos (routing), se encuentran clasificados como problemas de optimización combinatoria, y esto producto de que la cantidad de rutas posibles en un modelo básico, se encuentra determinado por la ecuación (n – 1)!, donde n, es igual al número de ubicaciones que componen el problema de enrutamiento.

Ahora bien, no solo la resolución de los problemas de enrutamiento es considerada como compleja, también lo es la fase preliminar en la que debemos levantar la información de entrada del modelo (inputs), específicamente, la matriz de distancias.

La forma más básica de un modelo VRP, requiere para su resolución la siguiente información mínima de entrada:

La matriz de distancias es un tabulado que registra la longitud entre cada uno de los nodos del modelo, incluido el nodo depósito. Su tamaño será n x n (siendo n el número de nodos del modelo). Asumiendo, por ejemplo, que tenemos un problema que se compone de 1 depósito y 19 ubicaciones, el modelo requerirá de una matriz de distancias con 400 datos.

En artículos anteriores hemos abordado modelos robustos para la resolución de problemas VRP y algunas de sus extensiones (CVRP, por ejemplo). El objetivo de este artículo será la de utilizar funciones espaciales de Python, para obtener una matriz de distancias de acuerdo a ubicaciones reales, con el propósito de resolver un modelo VRP básico.

Caso de aplicación

La Secretaría de Educación de Santiago de Cali, tiene dentro de sus funciones, distribuir el material pedagógico a las diferentes instituciones de formación de la ciudad. La distribución del material se realiza todos los lunes, y para ello, la Secretaría cuenta con dos vehículos con capacidad suficiente para transportar todo el material. El depósito del material (lugar desde donde salen y deben regresar los vehículos), se encuentra en la Alcaldía de Cali; y las instituciones que deben visitarse son 60. Tal como podemos apreciar en la siguiente tabla:

Se desea desarrollar un plan de rutas para cada uno de los vehículos que logre minimizar la distancia total recorrida, al tiempo que asegure la visita de todos los colegios.

¿Qué necesitaremos?

En el desarrollo de este ejercicio emplearemos:

Paso 1: Crear el entorno de trabajo en Colaboratory

Lo primero que vamos a hacer consiste en crear un entorno de trabajo en Google Colaboratory, así que vayamos allá: Abrir cuaderno nuevo.

Verán que tienen un lienzo para programar el modelo, así que en este cuaderno podemos ir generando las líneas de código que explicaremos en los pasos siguientes.

Paso 2: Importar las librerías necesarias

Respecto a las librerías, en la introducción del artículo hicimos una descripción de la funcionalidad de cada una, veamos como importarlas en nuestro entorno:

from sklearn.neighbors import DistanceMetric
from math import radians
import pandas as pd
import numpy as np

De esta manera, tenemos todo lo necesario para empezar a desarrollar nuestro código.

Paso 3: Importar los datos desde Excel

De acuerdo a las necesidades del modelo, podemos desarrollar un código que permita la entrada manual de la información, la captura de los datos desde entornos digitales (Internet, por ejemplo), o podemos, desde luego, alimentar nuestro modelo con información contenida en documentos externos, como es el caso de un archivo de Microsoft Excel.

Esta puede considerarse como una de las ventajas de utilizar Python, su capacidad de integrarse con cualquier fuente de datos. En nuestro caso, toda la información se encuentra contenida en un documento de Excel, el cual presenta el siguiente formato:

Utilizaremos ubicaciones reales, y para eso emplearemos las coordenadas de latitud y longitud.

En Colaboratory, el siguiente fragmento permitirá cargar un archivo al entorno de ejecución:

from google.colab import files

uploaded = files.upload()

for fn in uploaded.keys():
  print('User uploaded file "{name}" with length {length} bytes'.format(
      name=fn, length=len(uploaded[fn])))

Al ejecutar este fragmento de código, se abrirá una ventana emergente del explorador que permitirá cargar nuestra base de datos, en nuestro caso el archivo tienen el nombre de colegios.xlsx.

La siguiente línea de código permitirá almacenar los datos contenidos en el documento en un Dataframe de nuestro entorno, dentro de la variable data.

#Leer el documento de Excel y almacenar los datos en la variable data
data = pd.read_excel('colegios.xlsx')

Podemos en cualquier momento confirmar si la carga de los datos se ha realizado correctamente, para eso imprimiremos las primeras cinco filas del  DataFrame:

data.head()

Al ejecutar esta instrucción tenemos la siguiente salida (Una vista de las 5 primeras filas del marco de datos):

Podemos observar que los datos han sido perfectamente cargados, y que ahora se encuentran almacenados en la variable (DataFrame): data.

Paso 4: Convertir las coordenadas de latitud y longitud en radianes

La mayor parte de las funciones de cálculo de distancias de Sklearn (Scipy) toman las entradas como radianes. Por esta razón, debemos convertir las coordenadas en radianes.

data['Latitud'] = np.radians(data['Latitud'])
data['Longitud'] = np.radians(data['Longitud'])

#Creamos una matriz bidimensional con la latitud y la longitud en radianes
data[['Latitud','Longitud']].to_numpy()

Al ejecutar estas líneas, las coordenadas quedarán convertidas en radianes.

Paso 5: Declarar el tipo de métrica de distancias que se utilizará

En este punto quiero detenerme para mencionar que existen decenas de funciones métricas de distancia rápida. Algunas de las más utilizadas son destinadas a espacios vectoriales de valor real, como: distancias euclidianas, distancias de Manhattan, etc. Prácticas cuando se emplean con coordenadas cartesianas.

En nuestro caso, ya que utilizamos ubicaciones reales y contamos con coordenadas de latitud y de longitud, podemos emplear una función de distancia de vectores bidimensionales que considere la curvatura de la tierra; tal es el caso de las Distancias Haversine (Semiverseno).

Si quieren conocer la fórmula empleada para el cálculo de cada distancia haversine:

Para efectos de nuestro desarrollo, utilizaremos la librería SKLearn para calcular nuestras distancias. Veamos:

dist = DistanceMetric.get_metric('haversine')

dist.pairwise(data[['Latitud','Longitud']].to_numpy())*6373

El fragmento anterior crea un objeto con métricas haversine, y luego utiliza la función pairwise(), para calcular la distancia entre cada uno de los elementos de la matriz (nodos). Cada distancia calculada multiplica el escalar 6373 (radio esférico de la tierra), para calcular las distancias en kilómetros (Para millas multiplicar por 3798).

Paso 6: Crear un marco de datos (tabulado) de matriz de distancias

Una vez que ejecutemos el paso anterior, tendremos nuestras distancias entre nodos calculadas; lo que haremos en este paso será organizar dichos valores en forma de marco de datos o tabulado, obteniendo nuestra matriz de distancias.

distance_matrix = pd.DataFrame(dist.pairwise(data[['Latitud','Longitud']].to_numpy())*6373)

distance_matrix.head()

Al ejecutar esta instrucción tenemos la siguiente salida (Una vista de las 5 primeras filas del marco de datos):

Podemos imprimir la matriz completa:

print(distance_matrix)

Hasta este punto hemos logrado nuestro objetivo principal, que era obtener una matriz de distancias de forma automática tomando como base las coordenadas de longitud y latitud de un conjunto de nodos. Específicamente hemos obtenido 3721 valores de distancia en cuestión de segundos (empleando la métrica haversine).

Lógicamente, estos valores de referencia en la práctica presentan algunas desventajas, como, por ejemplo, la dificultad subyacente de atravesar las ciudades por lugares diferentes que las vías dispuestas para ello. Sin embargo, estos valores pueden ser muy útiles como datos de entrada de un modelo VRP para obtener la secuencia del plan de rutas.

Lo siguiente que haremos, para finalizar nuestro caso de aplicación, será utilizar la matriz de distancias obtenida, en un modelo VRP básico (Si desea profundizar en el modelo, visite el artículo).

Paso 7: Instalar Google Or Tools

Es necesario instalar la librería de Google Or Tools en nuestro entorno de Colaboratory para poder utilizar nuestro modelo VRP.

!pip install ortools

Al ejecutar esta instrucción instalaremos nuestro solucionador del modelo de enrutamiento.

Paso 8: Incorporar el modelo VRP (Previamente formulado)

Como ya lo mencionamos, contamos con un modelo debidamente formulado para resolver problemas VRP básicos. Lo único que modificaremos serán los datos de entrada: Matriz de distancias (distance_matrix), Número de vehículos (2), Depósito (Nodo 0).

"""Problema de enrutamiento de vehículos simple (VRP)

Autor: MSc. Ing. Bryan Salazar López 2021

"""

from ortools.constraint_solver import routing_enums_pb2
from ortools.constraint_solver import pywrapcp


def create_data_model():
    """Datos de entrada del modelo"""
    #Llamaremos la matriz de distancia previamente obtenida
    #Emplearemos dos vehículos como lo indica el problema
    #Definiremos el nodo 0 como el depósito (Secretaría)
    data = {}
    data['matriz_distancias'] = distance_matrix
    data['num_vehiculos'] = 2
    data['deposito'] = 0
    return data


def print_solution(data, manager, routing, solution):
    """Imprime la solución sobre la consola"""
    max_route_distance = 0
    for vehicle_id in range(data['num_vehiculos']):
        index = routing.Start(vehicle_id)
        plan_output = 'Ruta para el vehículo {}:\n'.format(vehicle_id)
        route_distance = 0
        while not routing.IsEnd(index):
            plan_output += ' {} -> '.format(manager.IndexToNode(index))
            previous_index = index
            index = solution.Value(routing.NextVar(index))
            route_distance += routing.GetArcCostForVehicle(
                previous_index, index, vehicle_id)
        plan_output += '{}\n'.format(manager.IndexToNode(index))
        plan_output += 'Distancia de la ruta: {}km\n'.format(route_distance)
        print(plan_output)
        max_route_distance += route_distance
        max_route_distance = max(route_distance, max_route_distance)
    print('Distancia total de todas las rutas: {}km'.format(max_route_distance))



def main():
    """Punto de entrada del programa"""
    # Invocar la data de entrada.
    data = create_data_model()

    # Crea el administrador del índice de rutas.
    manager = pywrapcp.RoutingIndexManager(len(data['matriz_distancias']),
                                           data['num_vehiculos'], data['deposito'])

    # Crea el modelo de enrutamiento.
    routing = pywrapcp.RoutingModel(manager)


    # Crea y registra una devolución de llamada de distancia.
    def distance_callback(from_index, to_index):
        """Retorna la distancia entre dos nodos."""
        # Convierte desde la variable de ruta Index hasta la matriz de distancia NodeIndex.
        from_node = manager.IndexToNode(from_index)
        to_node = manager.IndexToNode(to_index)
        return data['matriz_distancias'][from_node][to_node]

    transit_callback_index = routing.RegisterTransitCallback(distance_callback)

    # Define el costo de cada arco.
    routing.SetArcCostEvaluatorOfAllVehicles(transit_callback_index)

    # Adhiere la dimensión de distancia.
    dimension_name = 'Distancia'
    routing.AddDimension(
        transit_callback_index,
        0,  # Sin holgura
        3000,  # Distancia máxima de viaje del vehículo
        True,  # Iniciar el acumulador en cero
        dimension_name)
    distance_dimension = routing.GetDimensionOrDie(dimension_name)
    distance_dimension.SetGlobalSpanCostCoefficient(100)

    # Configurar los parámetros de búsqueda.
    search_parameters = pywrapcp.DefaultRoutingSearchParameters()
    search_parameters.first_solution_strategy = (
        routing_enums_pb2.FirstSolutionStrategy.PATH_CHEAPEST_ARC)

    # Solucionador del problema.
    solution = routing.SolveWithParameters(search_parameters)

    # Imprimir la solución en la consola.
    if solution:
        print_solution(data, manager, routing, solution)
    else:
        print('No se encuentra solución !')


if __name__ == '__main__':
    main()

Al ejecutar el modelo tendremos:

Un plan de rutas para los dos vehículos que parten desde los depósitos (ahí mismo finalizan sus recorridos), y visitan la totalidad de los nodos. La distancia total optimizada es equivalente a 33 km.

Por último, también es posible exportar la matriz de distancias que hemos obtenido, para eso utilizaremos el siguiente fragmento:

distance_matrix.to_csv('distance_matrix.csv')
files.download('distance_matrix.csv')

El código completo de este desarrollo lo puedes encontrar en nuestro cuaderno: Matriz de distancias para modelar un VRP.

La entrada ¿Cómo calcular una matriz de distancias para modelar un VRP? se publicó primero en Ingenieria Industrial Online.

“¿Quiere mejorar su capacidad de previsión de la demanda?

He desarrollado una nueva forma de utilizar el aprendizaje automático para apoyar las cadenas de suministro. Así es como funciona:

He desarrollado un metamodelo capaz de tratar prácticamente cualquier conjunto de datos de demanda de la cadena de suministro. El metamodelo trabajará con sus datos para crear el mejor modelo ML posible.”

Este es el inicio de un post en Linkedin publicado el 12 de octubre de 2021. La promesa es básicamente “mejoraré tu pronóstico con inteligencia artificial (AI)”.

Y yo pregunto, ¿qué ganamos realmente si esto fuera posible? No estoy ni siquiera cuestionando que un algoritmo de “aprendizaje automatizado” sea capaz de mejorar la precisión del pronóstico. Mi pregunta es más fundamental todavía. Supongamos que, si mejora el pronóstico, ¿qué hemos ganado?

Determinantes del tamaño del inventario

El inventario es necesario solo si los clientes no tienen paciencia para esperar el producto desde que expresan su necesidad, por lo que el objetivo de tener inventario es satisfacer ventas inmediatas. Y sabemos también que la demanda por un producto particular en un punto de venta tiene una alta variabilidad.

Si el objetivo es satisfacer ventas y la demanda tiene amplias fluctuaciones, entonces el inventario que requerimos debe ser suficiente para satisfacer la máxima demanda antes de la próxima reposición, lo que significa que la mayor parte del tiempo debemos mantener inventarios en exceso respecto de la demanda real del momento.

La próxima reposición va a depender del tiempo que nosotros decidamos dejar pasar entre una y otra reposición, y también de cuánto demore en llegar el producto desde que lo pedimos. Ambos tiempos juntos componen el tiempo de reposición.

Mientras mayor el tiempo de reposición, mayor el inventario necesario.

Consecuencias de un inventario grande

Mientras mayor el inventario, más espacio se requiere para almacenarlo, y más capital inmovilizado tendremos. Como espacio y capital son ambos recursos limitados, mientras mayor el inventario, menos variedad podremos ofrecer a los clientes, lo que reduce las ventas.

Y, además, si el tiempo de reposición es largo, entonces tendremos también mayores riesgos asociados al inventario: riesgo de merma y riesgo de obsolescencia. Además, un menor ROI general de la operación.

Incidencia del pronóstico en las consecuencias del inventario

Si nuestro pronóstico está muy equivocado, tendremos ventas perdidas por stock out, y tendremos acumulación de exceso de inventario.

Si mejoramos el pronóstico, vamos a reducir el stock out, y también la acumulación de exceso. Sin embargo, el principal factor que determina el tamaño del inventario es el tiempo de reposición, y un menor error en el pronóstico no reduce en absoluto este factor, por lo que el inventario necesario sigue siendo alto.

Me detengo aquí un minuto, porque ya puedo escuchar el contra argumento “si el pronóstico es exacto, necesito lo justo y necesario”. Estoy de acuerdo. Pero recuerde que la demanda es muy variable: algunos SKUs tendrán una alta venta en el periodo y otros menos, y se alternan. Para un periodo particular, el inventario requerido es la combinación de alta y baja demanda multiplicada por un tiempo largo.

¿Por qué he deducido que el tiempo es largo? Muy fácil, ¿cuántos días de venta necesita uno para pronosticar y cada cuánto tiempo se hace el pronóstico de una línea de productos? ¿Una vez a la semana, al mes, cada dos meses? No es todos los días para todos los SKUs, eso creo que es bastante seguro de suponer.

Por lo tanto, si estoy usando pronóstico, es muy seguro que el tiempo de reposición es largo. Y peor todavía, si además de pronósticos, uso MIN/MAX, el tiempo de reposición también es variable, por lo que debería pronosticar también cuánto será el tiempo hasta la próxima reposición. Y todavía estoy aceptando que podemos mejorar el pronóstico.

De este razonamiento, yo deduzco que un pronóstico más exacto, sin cambiar nada más, no ha reducido mucho ni espacio ni capital inmovilizado. Supongamos que la mejora del pronóstico elimina el stock out, y se incrementan las ventas. El capital inmovilizado no se reducirá muy significativamente. Recuerde que antes había stock outs, lo que significa menos inventario. Ahora hay más inventario de esos productos y menos de los otros, pero el efecto total es que el inventario sigue siendo proporcional al tiempo de reposición, por lo que no puede reducirse mucho.

¿Qué determina la rentabilidad de una empresa?

Tal vez debí empezar por aquí. Una empresa es un sistema y su rentabilidad depende de cuánto margen podemos generar con sus recursos más escasos. Otra manera de verlo es cuánto dinero se puede generar por cada centavo gastado en operar.

En TOC – Teoría de Restricciones, el Dr. Goldratt definió solo tres maneras de medir el dinero en una empresa: 

El trúput es la velocidad de generar dinero a través de las ventas. El inventario es la cantidad de dinero atrapado en el sistema y puede convertirse en trúput. El gasto de operación es el dinero gastado para convertir el inventario en trúput.

Sé que inventario definido así puede confundir. Mejor usemos inversión, y dejemos el término inventario para las unidades de productos almacenadas.

En optimización matemática (programación lineal y no lineal), se define una función objetivo del sistema. En el caso de una empresa, es la utilidad. Y esa función daría infinito si no fuera porque los recursos de la empresa son limitados, por lo que decimos que el óptimo lo determinan las restricciones activas.

En los sistemas ya sabemos que la mayoría de los recursos deben tener holguras (ver refutación al balanceo de líneas) por lo que son unas pocas las restricciones activas.

Entonces, la rentabilidad de una empresa está determinada por cuáles son sus restricciones activas y cómo se usan.

Espacio y capital son dos restricciones que se usan más o menos dependiendo del tamaño del inventario requerido. Si el inventario necesario es mayor, estas dos restricciones se están usando más, incluso al punto de agotarlas. En ese caso nos vemos obligados a aceptar un nivel de stock out porque no podemos incrementar el inventario.

Relación del pronóstico y rentabilidad

Como ya vimos, usar pronósticos está asociado a un tiempo largo de reposición, por lo que las restricciones mencionadas: espacio y capital, estarán utilizadas casi al máximo. Ahora es el momento de responder, ¿cómo mejora la rentabilidad un mejor pronóstico?

Un mejor pronóstico hará que usemos mejor esas restricciones de espacio y capital, pero no logrará que las usemos menos. Es decir, si son restricciones activas, lograremos “mover un poco la aguja” con más ventas al reducir los stock outs, pero no mucho más, porque no ha cambiado el tiempo de reposición y seguiremos usando mucho de esas restricciones.

¿Y si reducimos el tiempo de reposición?

Al reducir el tiempo de reposición aliviamos inmediatamente la necesidad de inventario para satisfacer la máxima demanda. Es decir, podemos tener menos unidades de inventario y al mismo tiempo ese es un inventario proporcionalmente mayor al anterior. Esto logra reducir stock out y reducir el uso de las restricciones espacio y capital simultáneamente.

Al reducir el uso de las restricciones, ahora podemos explotar esas restricciones de un modo mejor ampliando variedad, por ejemplo, logrando incrementar las ventas mucho más.

En un retail típico, los puntos de venta pueden reabastecerse todos los días desde su centro de distribución. Y creo no equivocarme si digo que los puntos de venta reciben mercadería todos los días. Lo que pasa es que el cambio fundamental está en que hacemos la reposición de todos los SKUs todos los días.

¿Cómo influye ahora un mejor pronóstico si ya no estamos copando las restricciones de espacio o capital? Yo creo que no hace ninguna diferencia. Y para un tiempo tan corto, el mejor pronóstico es repetir el pasado inmediato: reponer hoy lo que se consumió ayer.

Pero puede haber cambios en la demanda por cada SKU, y los niveles de inventario no ser adecuados en el tiempo. Para eso necesitamos detectar en qué dirección se mueve la demanda, pero no requerimos un número exacto de unidades a reponer. En TOC tenemos un mecanismo simple que llamamos Administración Dinámica de Amortiguadores, que se puede automatizar y ajusta la inversión de acuerdo con la demanda real. Este es el origen de lo que se ha llamado “Demand Driven”.

Una característica de este sistema es que requiere esfuerzo solo para recolectar los datos diarios, que de todos modos ya se recolectan. Y no se gasta tiempo en procesarlos, porque lo hace un computador (aunque es bueno que haya supervisión humana siempre).

¿Cuándo conviene pronosticar la demanda?

La decisión de capacidad es una decisión estratégica. Normalmente la capacidad no puede variarse fácilmente en cantidades significativas. Incrementar al doble o reducir a la mitad son movimientos que no pueden hacerse con frecuencia y requieren una planificación de las necesidades. Para este tipo de decisiones es que se requiere S&OP (Sales and Operations Planning).

A nivel de capacidad hay mucha agregación estadística. Es fácil deducir eso. Si una empresa fabrica 3000 SKUs distintos, difícilmente tendrá cientos de líneas de producción. Una fábrica muy grande tiene menos de diez líneas, por lo que la demanda por cada línea tiene una gran agregación estadística. Eso permite también deducir que el pronóstico de la demanda agregada para cada línea tiene un error mucho menor que el pronóstico de venta de cada SKU. (Un poco de agregación estadística pueden observar en: Cross Docking: ¡No lo intente en casa!).

En esas circunstancias es aconsejable hacer pronósticos de demanda para planear ampliaciones de capacidad. La dificultad en este tema es cómo las personas no entienden la función exponencial, pero ese es tema para otro artículo.

Por otro lado, la complejidad de las cadenas de suministro actuales también se prestan para aplicaciones de AI para estudiar la utilización de capacidad en distintos nodos, como fábricas, medios de transporte, puertos, contenedores, etc. En ese campo es muy impresionante lo que Throughput Inc. ha logrado con su aplicación ELI (me parece que en honor a Eli Goldratt).

Conclusión

Si me ofrecen un sistema para mejorar el pronóstico de la demanda para reponer en los puntos de venta, ya sé que es un sistema que opera con tiempos largos de reposición para cada SKU, por lo que no puedo esperar una gran mejora en rentabilidad. Sí habrá mejora, pero no muy grande.

En cambio, sin ningún sistema de pronóstico de demanda, pero con un sistema dinámico de ajuste de amortiguadores, con tiempos cortos de reposición, la mejora en rentabilidad será la misma o mejor que la del otro sistema, pero con menos esfuerzo y menos capital, y además se suma la liberación de restricciones para generar más margen todavía.

Matías Birrell Rodríguez

De profesión, ingeniero civil de industrias, con mención en mecánica, con un MBA en finanzas. Pero principalmente, experto en Teoría de Restricciones y autor de libros acerca de este tema, habiendo trabajado y aprendido directamente con el Dr. Goldratt en Goldratt Group. Adicionalmente es director de www.goldfish.cl, empresa que ofrece aplicaciones en la nube, simples y asequibles, para aplicar estos conceptos a las decisiones diarias. OTIF100 (manufactura), Fill Rate 100 (cadena de suministro).

¿Quieres optimizar tus procesos? Contáctame

La entrada ¿Inteligencia Artificial para mejorar pronósticos de la demanda? se publicó primero en Ingenieria Industrial Online.

En un artículo anterior, desarrollamos un modelo capaz de determinar la localización de una instalación (almacén), de acuerdo a un conjunto de ubicaciones existentes (clientes); estas ubicaciones tenían una ponderación determinada (peso, por ejemplo demanda), y basamos nuestro desarrollo en el algoritmo de Centro de Gravedad.

El valor agregado del modelo consistía en la integración de una capa de mapa de calor (para graficar la densidad), un proceso de geocodificación y el uso de un entorno geográfico real. El alcance de este modelo se encuentra determinado por la localización de una sola instalación (depósito, almacén, etc.), y en los casos en los que se requiera determinar múltiples localizaciones, el modelo no aplica.

La pregunta siguiente que nos hacemos es ¿Cómo determinar la localización de múltiples instalaciones? En realidad, hay muchas respuestas para este interrogante, y gran parte de ellas conducen a la agrupación geoespacial (Clustering).

¿Qué es la agrupación geoespacial (Clustering)?

La agrupación geoespacial es un método que se utiliza para asociar un conjunto de objetos espaciales en grupos denominados «clusters«. Los objetos que conforman cada grupo presentan un grado de similitud asociado a un atributo o varios atributos en particular.

El objetivo de la agrupación geoespacial, consiste en determinar una relación entre atributos espaciales (coordenadas, ubicación) y no espaciales (demanda, por ejemplo).

En la literatura encontraremos varios tipos de agrupación geoespacial, cada uno con un enfoque particular, y un campo de aplicación específico; entre los cuales podemos encontrar:

En nuestro caso, que pretendemos determinar la localización de varias instalaciones, considerando la ponderación y ubicación de los puntos existentes, requerimos de un modelo capaz de relacionar atributos espaciales (coordenadas) y no espaciales (peso de cada nodo). Que nos permita, primero agrupar los puntos dados (ubicaciones), y eventualmente, aplicar un algoritmo de Centro de Gravedad, para determinar localizaciones potenciales.

Para tales efectos, vamos a utilizar la agrupación de particiones, que se caracteriza, entre otras, por:

Vale la pena destacar que en cuanto a la agrupación de participaciones, en esta categoría encontraremos varios métodos de partición, y nosotros utilizaremos el método K-Means, un algoritmo de aprendizaje automático (Machine Learning) no supervisado. Para ello utilizaremos Python.

Para sintetizar, el objetivo de este artículo será el de emplear un algoritmo de aprendizaje automático capaz de agrupar nuestros nodos en clusters, de acuerdo a atributos espaciales (coordenadas) y no espaciales (ponderación); para luego, utilizar un algoritmo de Centro de Gravedad en cada clúster para determinar la localización de múltiples instalaciones (almacenes, depósitos, etc.).

En el desarrollo de este ejercicio emplearemos:

Para desarrollar estas herramientas, vamos a plantear un caso típico de localización de múltiples instalaciones a partir de la consideración de otros nodos (nodos de demanda, por ejemplo).

Caso de aplicación

El Departamento de Desarrollo Sostenible de la ciudad de Cali se encuentra implementando una estrategia piloto de recolección de aceite de cocina usado. Ha articulado este proyecto con una Universidad, la cual desarrolló 4 contenedores inteligentes (BIN’s) para la disposición del bioresiduo.

En investigaciones asociadas, la Universidad ha determinado que el reciclaje del aceite es un problema de densidad; esto quiere decir que es vital la ubicación de los contenedores (cobertura), para así mismo optimizar el proceso de disposición y recolección. El proyecto piloto piensa articular a las instituciones de educación como puntos potenciales de recolección. Por medio de las instituciones piensan socializar el programa con la comunidad. El primer reto del proyecto consiste en determinar la ubicación de los contenedores inteligentes (4 unidades). La información relacionada con las instituciones de educación que hacen parte del programa (ubicación geográfica / población estudiantil), se detalla a continuación:

Para tales efectos, desarrollaremos un modelo que apoye el análisis preliminar y la localización de los múltiples contenedores. También, que tenga la capacidad de predecir el grupo (clúster) al que pertenecería un nodo nuevo.

Paso 1: Crear el entorno de trabajo en Colaboratory

Lo primero que vamos a hacer consiste en crear un entorno de trabajo en Google Colaboratory, así que vayamos allá: Abrir cuaderno nuevo.

Verán que tienen un lienzo para programar el modelo, así que en este cuaderno podemos ir generando las líneas de código que explicaremos en los pasos siguientes.

Paso 2: Importar las librerías necesarias

Respecto a las librerías, en la introducción del artículo hicimos una descripción de la funcionalidad de cada una, veamos como importarlas en nuestro entorno:

#Importar las librerías necesarias
import pandas as pd
import numpy as np
import matplotlib.pyplot as plt
from sklearn.cluster import KMeans

De esta manera, tenemos todo lo necesario para empezar a desarrollar nuestro código.

Paso 3: Importar los datos desde Excel

De acuerdo a las necesidades del modelo, podemos desarrollar un código que permita la entrada manual de la información, la captura de los datos desde entornos digitales (Internet, por ejemplo), o podemos, desde luego, alimentar nuestro modelo con información contenida en documentos externos, como es el caso de un archivo de Microsoft Excel.

Esta puede considerarse como una de las ventajas de utilizar Python, su capacidad de integrarse con cualquier fuente de datos. En nuestro caso, toda la información se encuentra contenida en un documento de Excel, el cual presenta el siguiente formato:

Ya veremos cómo, parte de estos datos son prescindibles y otros indispensables.

En Colaboratory, el siguiente fragmento permitirá cargar un archivo al entorno de ejecución:

from google.colab import files

uploaded = files.upload()

for fn in uploaded.keys():
  print('User uploaded file "{name}" with length {length} bytes'.format(
      name=fn, length=len(uploaded[fn])))

Al ejecutar este fragmento de código, se abrirá una ventana emergente del explorador que permitirá cargar nuestra base de datos, en nuestro caso el archivo tienen el nombre de cluster.xlsx.

La siguiente línea de código permitirá almacenar los datos contenidos en el documento en un Dataframe de nuestro entorno, dentro de la variable data.

#Leer el documento de Excel y almacenar los datos en la variable data
data = pd.read_excel('cluster.xlsx')

Podemos en cualquier momento confirmar si la carga de los datos se ha realizado correctamente, para eso imprimiremos las primeras cinco filas del  DataFrame:

data.head()

Al ejecutar esta instrucción tenemos la siguiente salida:

Paso 4: Graficar los puntos dados iniciales (Nodos)

Nuestros puntos iniciales, o las ubicaciones de partida son las instituciones de educación que nos otorga el planteamiento del problema.

Para graficar estos puntos utilizamos el sistema de coordenadas disponible: Latitud y Longitud. Así entonces, debemos extraer estos datos de la hoja de cálculo (DataFrame) que hemos importado al modelo; convertir estas coordenadas en una matriz bidimensional (Latitud y Longitud) y graficar los puntos:

#Graficar los nodos dados (ubicaciones)
Lat= data['Latitud']
Lon = data['Longitud']
Peso = data['Peso']
X = []
for i in range(len(data['Latitud'])):
    X.append(Lat[i])
    X.append(Lon[i])

X = np.array(X)

X = X.reshape(-1, 2,)


plt.scatter(Lat, Lon)
plt.show()

Al ejecutar este fragmento de código, tendremos:

Podemos apreciar cómo se encuentran dispersos los nodos iniciales, formando parte un mismo conjunto que es la población. Las coordenadas son latitud y longitud. Los nodos son, una vez más recordamos, las instituciones educativas, de acuerdo al caso de estudio.

Paso 5: Agrupar los nodos geoespacialmente mediante Machine Learning

Cuando mencionamos Machine Learning, a menudo la primera consideración que tenemos es de complejidad. Pues bien, muchos de los algoritmos que hemos utilizado durante décadas son en realidad de aprendizaje automático, como por ejemplo la regresión lineal. El algoritmo de K-Means que emplearemos de forma automatizada mediante Python, utiliza centroides que minimizan la inercia, o el criterio de suma de cuadrados de cada clúster:

Me pareció conveniente explicar un poco la teoría, pero vayamos a la práctica. Toda vez que tenemos los nodos del modelo, lo siguiente que debemos indicar es la cantidad de agrupaciones que queremos (clúster). Ya que el problema plantea la disposición de 4 contenedores, vamos a dividir la población de nodos en 4 conjuntos.

Luego, correremos el algoritmo K-Means, veamos cómo:

#Ejecutar el algoritmo KMeans
clusters = 4
KMean = KMeans(n_clusters=clusters)
KMean_g = KMean.fit_predict(X)
KMean.fit(X)

Lo siguiente que haremos será establecer los centroides de cada clúster, es decir, la ubicación de nuestros contendores. En primer lugar, el modelo nos dará las coordenadas. Utilizaremos la siguiente línea de código:

#Determinar los centroides de cada clúster
KMean.cluster_centers_

Al ejecutarla tendremos:

Estas son las coordenadas que indican el centro de cada uno de nuestros grupos de nodos. Y teóricamente ahí deberíamos disponer nuestros contenedores.

Paso 6: Graficar los clusters y los centroides (Localizaciones múltiples)

El siguiente paso consiste en graficar todas las coordenadas que ya tenemos: tantos los nodos iniciales, como los los centroides, o las localizaciones solución. Veamos cómo:

#Graficar todas las coordenadas (Puntos y centroides)
plt.scatter(X[:,0], X[:,1], c=KMean_g) #Puntos iniciales

#Centroides
plt.scatter(KMean.cluster_centers_[0][0], KMean.cluster_centers_[0][1], s=50, c='r')
plt.scatter(KMean.cluster_centers_[1][0], KMean.cluster_centers_[1][1], s=50, c='r')
plt.scatter(KMean.cluster_centers_[2][0], KMean.cluster_centers_[2][1], s=50, c='r')
plt.scatter(KMean.cluster_centers_[3][0], KMean.cluster_centers_[3][1], s=50, c='r')

Al ejecutar el fragmento tendremos:

Vemos cómo se han efectuado las agrupaciones de los nodos (colores), y los marcadores rojos indican los centroides. Este debería ser el final de nuestro desarrollo, sin embargo, no sé si lo han notado, siempre hemos hablado de centroides, nunca de centros de gravedad o centros de masa. Bien, no sé si también han identificado que en ningún momento hemos considerado el peso de cada nodo, en este caso la población estudiantil de cada institución.

¿Esto qué implica? Implica que hemos desarrollado un modelo que tiene exclusivamente consideraciones espaciales. De hecho, visualmente puede observarse cómo, básicamente los centroides se ubican en lo que podría considerarse el medio de cada clúster, sin ninguna consideración adicional aparente, por lo menos a la vista.

Pues bien, vamos a solucionarlo, para ello debemos retocar algunos de los pasos anteriores:

Paso 5 (Recargado): Agrupar los nodos geoespacialmente mediante Machine Learning (Considerando atributos espaciales y no espaciales)

Dentro de nuestro marco de datos (DataFrame) tenemos la información relacionada al peso de cada nodo (Población estudiantil). Pues bien, vamos a considerarla al ejecutar el algoritmo K-Means.

#Ejecutar el algoritmo KMeans (Considerando el peso de los nodos)
clusters = 4
KMean = KMeans(n_clusters=clusters)
KMean_g = KMean.fit_predict(X)
KMean.fit(X, sample_weight=Peso)

Lo siguiente que haremos será establecer los centroides de cada clúster, que ahora sí serán Centros de Gravedad; es decir, la ubicación de nuestros contendores. En primer lugar, el modelo nos dará las coordenadas. Utilizaremos la siguiente línea de código:

#Determinar los centroides de cada clúster
KMean.cluster_centers_

Al ejecutarla tendremos:

Los centroides han cambiado, ahora son centros de gravedad afectados por el peso de cada nodo. Es posible que incluso haya cambiado la agrupación de los nodos (composición de los clusters).

Paso 6 (Recargado): Graficar los clusters y los Centros de Gravedad (Localizaciones múltiples)

El siguiente paso consiste en graficar todas las coordenadas que ya tenemos: tantos los nodos iniciales, como los los Centros de Gravedad, o las localizaciones solución. Veamos cómo:

#Graficar todas las coordenadas (Puntos y centroides)
plt.scatter(X[:,0], X[:,1], c=KMean_g) #Puntos iniciales

#Centroides
plt.scatter(KMean.cluster_centers_[0][0], KMean.cluster_centers_[0][1], s=50, c='r')
plt.scatter(KMean.cluster_centers_[1][0], KMean.cluster_centers_[1][1], s=50, c='r')
plt.scatter(KMean.cluster_centers_[2][0], KMean.cluster_centers_[2][1], s=50, c='r')
plt.scatter(KMean.cluster_centers_[3][0], KMean.cluster_centers_[3][1], s=50, c='r')

Al ejecutar el fragmento tendremos:

El resultado respecto a los centroides es diferente. La consideración de un atributo no espacial, en este caso el peso de cada nodo (población estudiantil de cada institución educativa), ha incidido en la ubicación propuesta de las localizaciones solución. Y este debería ser el final de nuestro modelo.

Hemos logrado agrupar nuestros puntos iniciales en clusters, y luego hemos determinado los Centros de Gravedad de cada uno de los clusters.

Por último, veamos una característica de la librería K-Means Análisis predictivo de nodos en clusters, es decir, de acuerdo a unas coordenadas dadas, podemos estimar el grupo al que pertenecerá un nuevo nodo.

Paso 7: Predicción de clusters

En primer lugar ejecutaremos una línea que nos permite identificar a cada nodo dentro de un grupo. Ya que tenemos 4 grupos, estos se identificarán de la siguiente manera: 0, 1, 2, 3.

KMean.labels_

Al ejecutar esta línea tendremos:

Vemos como cada una de las 60 instituciones educativas (nodos), tienen un identificador de grupo dentro del modelo.

Ahor, dadas las coordenadas de un nuevo nodo, podemos predecir el grupo al cual pertenecerá:

sample_test=np.array([-3.433,-76.22])
second_test=sample_test.reshape(1, -1)
KMean.predict(second_test)

Al ejecutar este fragmento tendremos:

Es decir, el algoritmo predice que de acuerdo a las coordenada dadas, el nuevo nodo formaría parte del clúster 0.

Pudimos observar cómo varía el resultado dependiendo de la consideración de atributos netamente geoespaciales, y de atributos no espaciales, como la ponderación de cada nodo.

Integración con mapas de calor y entornos geográficos reales

Uno de los puntos negativos del modelo que acabamos de desarrollar es quizá que no nos permite visualizar gráficamente la densidad de los puntos. Si observamos las gráficas, todos los puntos parecen tener el mismo tamaño, y si bien esta no es una consideración para el funcionamiento del algoritmo; en el análisis preliminar quisiéramos tener esta herramienta. Otra consideración adicional sería la posibilidad de graficar todos nuestros puntos, y los centros de gravedad de cada (clúster) en un entorno geográfico real.

Pues bien, una de las ventajas fundamentales de Python consiste en que podemos integrar distintos desarrollos en nuestros modelos, tal es el caso del desarrollo que efectúanos en un artículo anterior (Mapas de calor y Entornos geográficos reales); de tal manera que podamos complementar nuestro modelo.

No vamos a profundizar en la librerías, ni en la definición de las variables, para eso recomendamos leer el artículo. Veamos entonces, como complementamos este modelo:

import folium
import statistics
from folium.plugins import HeatMap
mediaLong = statistics.mean(Lon)
mediaLat = statistics.mean(Lat)

# Crear un objeto de mapa base Map()
mapa = folium.Map(location=[mediaLat, mediaLong], zoom_start = 13)

# Crear una capa de mapa de calor
mapa_calor = HeatMap( list(zip(Lat, Lon, data["Peso"])),
                   min_opacity=0.2,
                   max_val=data["Peso"].max(),
                   radius=50, 
                   blur=50, 
                   max_zoom=1)

#Creamos el marcador de Centro de Gravedad
tooltip = 'Centro de gravedad'
folium.Marker([KMean.cluster_centers_[0][0], KMean.cluster_centers_[0][1]], popup="Centro", tooltip = tooltip).add_to(mapa)
folium.Marker([KMean.cluster_centers_[1][0], KMean.cluster_centers_[1][1]], popup="Centro", tooltip = tooltip).add_to(mapa)
folium.Marker([KMean.cluster_centers_[2][0], KMean.cluster_centers_[2][1]], popup="Centro", tooltip = tooltip).add_to(mapa)
folium.Marker([KMean.cluster_centers_[3][0], KMean.cluster_centers_[3][1]], popup="Centro", tooltip = tooltip).add_to(mapa)

# Adherimos la capa de mapa de calor al mapa principal
mapa_calor.add_to(mapa)
mapa

Al ejecutar este fragmento tendremos el siguiente resultado:

Ahora tenemos un modelo capaz de agrupar nuestros nodos en clusters de acuerdo a atributos geoespaciales; capaz de determinar los centros de gravedad de cada cluster de acuerdo a atributos no espaciales (en nuestro caso la población de los nodos); capaz de complementarse con una capa de visualización de mapa de calor que nos permite apreciar la densidad y todo esto puede visualizarse en un entorno geográfico real.

Consideraciones finales

Ya lo expresamos anteriormente, la base del algoritmo K-Means es la consideración y minimización de la inercia, y en espacios de muy altas dimensiones, las distancias suelen inflarse, ya que esta no es una medida normalizada.

Sin embargo, para los efectos que hemos empleado, el algoritmo suele arrojar resultados satisfactorios.

El código completo de este desarrollo lo puedes encontrar en nuestro cuaderno: Localización de varias instalaciones mediante agrupación geoespacial y Centro de Gravedad (Python).

La entrada Localización de varios almacenes mediante agrupación geoespacial se publicó primero en Ingenieria Industrial Online.

Ya en artículos anteriores hemos abordado el uso de tecnología como herramienta que permita desarrollar problemas de análisis preliminar y localización de instalaciones, con el objetivo de incrementar el nivel de aplicabilidad de estas herramientas, utilizando algunos entornos de programación, algunos sistemas de información geográfica, librerías de geocodificación; etc., que nos facilitan la adopción de soluciones basadas en entornos reales.

Algunos de los artículos que hemos desarrollado al respecto son:

En estos artículos mencionamos que los mapas de calor aplicados a la localización de instalaciones, son capas de visualización que no nos proporcionan como resultado una localización específica; sí nos proporcionan una visión de densidad basada en un factor de ponderación establecido (Peso). Sin embargo, al utilizar mapas de calor en entornos como por ejemplo Python, podemos integrar a esta herramienta, un método heurístico que nos proporcione una localización específica, como por ejemplo el Centro de Gravedad.

El objetivo de este artículo será el de utilizar mapas de calor y el algoritmo de Centro de gravedad de manera simultánea a través de Python; como herramienta de análisis preliminar y de localización de una instalación.

En el desarrollo de este ejercicio emplearemos:

Para desarrollar estas herramientas, vamos a plantear un caso típico de localización de una instalación (por ejemplo un depósito) a partir de la consideración de otras instalaciones (nodos de demanda, por ejemplo).

Caso de aplicación

La empresa Bio-Food está desarrollando un nuevo modelo de negocio en la ciudad de Cali, Colombia. Este consiste en abastecer de comida saludable a la comunidad por medio de Vending Machines (Máquinas expendedoras). En las etapas de formulación de negocio, algo quedó muy claro: El éxito de su modelo consiste en maximizar la disponibilidad de todos los SKUs en cantidades suficientes. Algunas de las referencias son productos perecederos, de manera que consideran que algunos de sus equipos requerirán visitas diarias de reposición, y otros quizá sean surtidos en más de dos ocasiones por día.

La fase inicial de su proyecto consideró la instalación de 13 equipos expendedores en 13 instituciones de educación superior de la ciudad. La logística inicial de su proyecto fue caótica (en fase piloto), algunos equipos funcionaron como sub-bodegas; algunos equipos fueron abastecidos directamente por los proveedores; y consideran la instalación de una bodega principal desde la cual serán abastecidas todas las máquinas que tienen disponibles.

La fase inicial del proyecto arrojó información alrededor del volumen de ventas de cada equipo. Por esta razón, el departamento de logística considera utilizar esta información para efectuar un análisis preliminar y establecer la localización de la bodega principal. A continuación, se relacionan los movimientos de los equipos (media de unidades vendidas por día):

Utilizar el algoritmo de Centro de Gravedad puede servir como referencia para establecer una ubicación tentativa. Sin embargo, las posibilidades de que las coordenadas solución correspondan con un espacio disponible para la ubicación de la instalación son, de verdad, muy pocas.

Por esta razón, es interesante complementar este modelo mediante una capa de visualización de mapas de calor, que consideren la densidad del volumen de ventas de los equipos. De esta manera, puede complementarse el análisis preliminar para la localización de la bodega principal.

Paso 1: Crear el entorno de trabajo en Colaboratory

Lo primero que vamos a hacer consiste en crear un entorno de trabajo en Google Colaboratory, así que vayamos allá: Abrir cuaderno nuevo.

Verán que tienen un lienzo para programar el modelo, así que en este cuaderno podemos ir generando las líneas de código que explicaremos en los pasos siguientes.

Paso 2: Importar las librerías necesarias

Respecto a las librerías, en la introducción del artículo hicimos una descripción de la funcionalidad de cada una, veamos como importarlas en nuestro entorno:

# importar las librerías necesarias
import pandas as pd
import numpy as np
import folium
import statistics
from folium.plugins import HeatMap
import geopy
from geopy.extra.rate_limiter import RateLimiter

De esta manera, tenemos todo lo necesario para empezar a desarrollar nuestro código.

Paso 3: Importar los datos desde Excel

De acuerdo a las necesidades del modelo, podemos desarrollar un código que permita la entrada manual de la información, la captura de los datos desde entornos digitales (Internet, por ejemplo), o podemos, desde luego, alimentar nuestro modelo con información contenida en documentos externos, como es el caso de un archivo de Microsoft Excel.

Esta puede considerarse como una de las ventajas de utilizar Python, su capacidad de integrarse con cualquier fuente de datos. En nuestro caso, toda la información se encuentra contenida en un documento de Excel, el cual presenta el siguiente formato:

En Colaboratory, el siguiente fragmento permitirá cargar un archivo al entorno de ejecución:

from google.colab import files

uploaded = files.upload()

for fn in uploaded.keys():
  print('User uploaded file "{name}" with length {length} bytes'.format(
      name=fn, length=len(uploaded[fn])))

Al ejecutar este fragmento de código, se abrirá una ventana emergente del explorador que permitirá cargar nuestra base de datos, en nuestro caso el archivo tienen el nombre de vending_machines.xlsx.

La siguiente línea de código permitirá almacenar los datos contenidos en el documento en un Dataframe de nuestro entorno, dentro de la variable data.

#Leer el documento de Excel y almacenar los datos en la variable data
data = pd.read_excel('vending_machines.xlsx')

Paso 4: Geocodificar las ubicaciones

Nosotros podemos partir desde la disponibilidad de las coordenadas geográficas de los puntos disponibles (Equipos expendedores). En cuyo caso, geocodificar las ubicaciones no sería necesario. Sin embargo, en nuestro ejemplo, disponemos del nombre de cada institución donde se encuentran ubicados los equipos, así como la ciudad y el país (todos los equipos se encuentran en la misma ciudad); y es necesario geocodificar estos puntos para obtener las coordenadas de latitud y longitud de cada ubicación.

Para lograrlo, utilizaremos el servicio de la librería Geopy (Llamado Nominatim), el cual puede geocodificar nuestras ubicaciones. El servicio funciona de una manera sencilla, recibe una cadena con la información de nuestra ubicación, por ejemplo: ciudad, país, nombre del lugar; y devuelve las coordenadas de latitud y longitud asociadas a cada cadena.

Las siguientes líneas en primer lugar construyen cada cadena por punto (dirección), es decir, concatenan los datos (país, ciudad y nombre del lugar), y luego son geocodificados por Geopy. Veamos:

# fusionamos los datos país, ciudad y lugar en una misma cadena de dirección
geopy.geocoders.options.default_user_agent = "my-application"
data["direccion"] = data["pais"] + ", " + data["ciudad"] + ", " + data["Institución / Lugar"]
#Envíamos los datos a geocodificación
servicio = geopy.Nominatim()
data["coordenadas"] = data["direccion"].apply(RateLimiter(servicio.geocode,min_delay_seconds=1))

Pueden apreciar que el código establece que tanto las cadenas con las direcciones concatenadas, como las respuestas en manera de coordenadas, queden dentro del mismo DataFrame donde se encuentran los datos de entrada del modelo. Podemos en cualquier momento confirmar si la geocodificación se ha realizado correctamente, para eso imprimiremos las primeras cinco filas del  DataFrame:

data.head()

Al ejecutar esta instrucción tenemos la siguiente salida:

Podemos observar cómo bajo la columna ‘direccion’ se han concatenado las columnas ‘pais’, ‘ciudad’ e ‘Institución / Lugar’, tal como lo establecimos previamente. Así mismo, podemos observar la respuesta de Geopy  bajo la columna ‘coordenadas’.

Paso 5: Calcular el Centro de Gravedad

El algoritmo de Centro de Gravedad es relativamente sencillo, mucho más cuando se cuenta con los datos debidamente organizados. Las operaciones son sencillas, y en Python, se pueden desarrollar fácilmente mediante productos de matrices.

Ahora bien, la base del algoritmo son las coordenadas. En la respuesta obtenida desde Geopy, que se encuentra contenida en la columna ‘coordenadas’ del DataFrame ‘data’, hay información adicional a las coordenadas necesarias. De hecho el servicio nos devuelve un nombre del lugar, una subregión, puede mostrarnos alguna nomenclatura y claro está, las coordenadas de latitud y longitud. Por tal razón, lo primero que debemos hacer es extraer las coordenadas de latitud y longitud, para eso utilizaremos las siguientes líneas:

# Extraer las coordenadas de latitud y longitud en dos variables separadas (listas)
longs = [coord.longitude for coord in data["coordenadas"]]
lats = [coord.latitude for coord in data["coordenadas"]]

Una vez que tengamos las coordenadas de todos los puntos en un par de variables separadas, procedemos a crear nuestro algoritmo de centro de gravedad:

centro_gravedad = {}
centro_gravedad['longs'] = np.dot(longs, data['Unidades vendidas']) / np.sum(data['Unidades vendidas'])
centro_gravedad['lats'] = np.dot(lats, data['Unidades vendidas']) / np.sum(data['Unidades vendidas'])

De esta manera, dentro del arreglo ‘centro_gravedad’ deberán quedar las coordenadas solución. Recordemos que este algoritmo utiliza puntos ponderados, en este caso el peso que determina la ponderación está dado por el volumen de ventas de cada equipo (‘Unidades vendidas’).

Podemos ver el resultado, imprimiendo la variable ‘centro_gravedad’:

print(centro_gravedad)

Estas son las coordenadas solución del método de Centro de Gravedad. Sin embargo, recordemos que debemos complementar el desarrollo del modelo mediante un mapa de calor.

Paso 6: Graficar la capa del mapa de calor y el marcador de Centro de Gravedad

En este caso utilizaremos la librería Folium para ambos fines: la capa del mapa de calor, y el marcador de Centro de Gravedad.

Lo primero que haremos será calcular la media de las latitudes y las longitudes para centrar el mapa que obtendremos.

Lo segundo que haremos será crear nuestro mapa, el cual configuraremos con las medidas centrales y un zoom inicial que podemos modificar de acuerdo a nuestras necesidades.

Lo tercero que haremos será crear nuestra capa de mapa de calor, utilizaremos como peso las ‘Unidades vendidas’ para ponderar cada punto del mapa (Vending Machines). Configuramos algunos parámetros a nuestro criterio como la opacidad, la intensidad, el radio de cada punto.

Por último crearemos el marcador de Centro de Gravedad, para ello utilizaremos las coordenadas solución que hallamos en el paso anterior.

# Calcular la media de las latitudes y las longitudes para centrar el mapa
mediaLong = statistics.mean(longs)
mediaLat = statistics.mean(lats)

# Crear un objeto de mapa base Map()
mapa = folium.Map(location=[mediaLat, mediaLong], zoom_start = 12)

# Crear una capa de mapa de calor
mapa_calor = HeatMap( list(zip(lats, longs, data["Unidades vendidas"])),
                   min_opacity=0.2,
                   max_val=data["Unidades vendidas"].max(),
                   radius=50, 
                   blur=50, 
                   max_zoom=1)

#Creamos el marcador de Centro de Gravedad
tooltip = 'Centro de gravedad'
folium.Marker([centro_gravedad['lats'], centro_gravedad['longs']], popup="Centro", tooltip = tooltip).add_to(mapa)

# Adherimos la capa de mapa de calor al mapa principal
mapa_calor.add_to(mapa)
mapa

Al ejecutar estas líneas tendremos el siguiente resultado:

Podemos utilizar el zoom para explorar diversas visualizaciones de densidad:

El código completo de este desarrollo lo puedes encontrar en nuestro cuaderno: Mapas de Calor y Centro de Gravedad.

En este caso, y a diferencia del artículo mapas de calor utilizando Google Maps, empleamos una capa de visualización de densidad de cada punto, y simultáneamente identificamos unas coordenadas solución de una localización de acuerdo al modelo de Centro de Gravedad (Centro de masa). De esta forma, construimos una herramienta un poco más robusta que permite soportar los procesos de análisis preliminar de localización de instalaciones, ambientada en un entorno geográfico real.

Así mismo, en el desarrollo de la herramienta empleamos algunas instrucciones que nos permiten automatizar procesos de georeferenciación, y de uso de datos a partir de fuentes diversas.

El alcance de este modelo se encuentra determinado por la localización de una sola instalación (depósito, almacén, etc.), y en los casos en los que se requiera determinar múltiples localizaciones, el modelo no aplica.

La entrada Mapas de calor y Algoritmo de Centro de Gravedad utilizando Python se publicó primero en Ingenieria Industrial Online.

“¿Un fill rate mayor a 94%? ¡Imposible! No es posible sostenerlo con un costo aceptable”.

No es la primera vez y creo que no será la última que escuche este tipo de afirmaciones cuando hablo con gerentes generales. Y es que son personas inteligentes y con experiencia, lo que los ha llevado a tener ciertas convicciones que les permiten tomar decisiones rápidamente, sin entretener su escaso tiempo en fantasías.

¿Pero qué es lo que en el pasado ocurrió y lo llevó a tener este convencimiento de que no es posible tener un fill rate cercano a 100% y a la vez que eso sea rentable?

¿Qué es fill rate?

Este es un término en inglés de uso habitual en logística para medir el grado de cumplimiento de un pedido. En su expresión más simple y ácida, es el porcentaje de líneas del pedido que se ha logrado satisfacer completamente.

Claro que, si el pedido tiene solo dos ítems de, digamos 900 unidades del primero y 100 unidades del segundo, y entregamos 800 unidades y 100 respectivamente, con esta definición podríamos tener un fill rate de 50%. Entonces podemos afinar nuestra definición al considerar las cantidades también. Una manera es calcular el fill rate como las unidades entregadas divido por el total. En este caso tendríamos 90%.

Pero si las 900 unidades representan el 50% en dinero, ahora podríamos hacer otro cálculo que nos dé 94.4%.

Ya ve que el fill rate es un KPI que puede significar distintas cosas, pero, aun así, ese gerente consideraba imposible sostenerlo sobre 94%.

¿Cómo se conforman las decisiones?

El caso que estoy relatando es el de un fabricante de bienes de consumo que vende su producción a una cadena de suministro, donde hay mayoristas, distribuidores y retail.

En esa compañía, como en muchas otras, los gerentes tienen estudios superiores, y con bastante seguridad aprendieron las técnicas más conocidas de optimización de costos para la gestión de empresas que comercializan bienes de consumo. Entre otras, balancear líneas de producción, usar MIN/MAX y EOQ, y cálculo de costos unitarios con las últimas técnicas de ABC (costeo basado en actividades).

Cuando uno usa esas técnicas, el resultado inevitable es que la capacidad apenas alcanza para satisfacer la demanda y se acumula mucho inventario. El inventario acumulado utiliza dos recursos fundamentales: espacio en bodega y capital de trabajo. Cuando hay mucho inventario, ambos recursos están a su límite, por lo que sugerir incrementar el inventario inmediatamente incrementa el costo de la operación.

¿Y eso qué tiene que ver con el fill rate?, dirá usted.

Veamos, si hay mucho inventario acumulado, necesariamente eso representa más días de venta. Es decir, la programación de producción debe considerar un horizonte de venta más lejano en el futuro, por lo que cada vez más depende de la exactitud del pronóstico. Lo único que sabemos con certeza acerca del pronóstico es que está equivocado, por lo que esos planes de producción van a terminar con algunos ítems agotados, lo que redunda en un fill rate menor.

Lo único que sabemos con certeza acerca del pronóstico es que está equivocado

Pero es peor todavía: cada vez que a un pedido le falta un ítem, hay reprogramaciones de producción, lo que desperdicia capacidad y ahora debemos pagar un costo mayor para lograr todo el plan de producción.

¿Y los gerentes no se dan cuenta de todo este círculo vicioso?

Es más fácil preguntarlo que responderlo. ¿Cómo pueden saber que eso es un círculo vicioso? O mejor, ¿cómo podrían saber que no están optimizando la operación? Después de todo están siguiendo las “mejores prácticas” y aplicando principios básicos que se enseñan hasta el día de hoy en universidades muy prestigiosas.

Y además son conceptos practicados por muchos otros en la industria.

Después de varios años optimizando, en esa empresa han logrado 94% como un máximo realista y sostenible. Cada vez que intentaron mejorarlo, manteniendo las optimizaciones productivas, se elevaron tanto los inventarios y aparecieron tantas mermas, que la conclusión lógica es que intentar mejorar el fill rate no es rentable, y no es realista que se lo sugieran después de tanta experiencia que demuestra lo contrario.

¿Hay salida?

Esta es una pregunta que hace alguien inconformista. Alguien que no acepta el trade off entre fill rate y costo. El Dr. Goldratt me enseñó que no acepte las contradicciones; que un científico debe pensar hasta lograr eliminarlas. También Genrich Altshuller pensaba así, poniendo como base de TRIZ el convencimiento de que un invento surge de eliminar una contradicción técnica.

Me remito a dos artículos anteriores para ver cómo se invalidan algunos de los conceptos básicos que siguen usando los gerentes. Vea Refutación al balanceo de líneas y La Falacia de MIN/MAX y EOQ para saber por qué esos conceptos están equivocados.

En general, el gran problema actual en la gestión de empresas es desconocer el carácter sistémico de las organizaciones. Estos ejemplos presentados aquí son solo una muestra.

La salida al problema del fill rate sub óptimo es cuestionar los conceptos que dan origen a las decisiones diarias de la fábrica y de la cadena de suministro. Al abandonar esas “creencias”, se debe adoptar otro conjunto de políticas. Afortunadamente ya hemos recorrido ese camino, y conocemos cuáles son los nuevos conceptos y las nuevas políticas. Y hemos visto a cientos de empresas (tal vez miles) que en los últimos 30 años han logrado un fill rate cercano al 100% junto con reducir costos e inventarios.

¿Por qué es lenta la adopción del pensamiento sistémico?

Russell Ackoff respondió esta pregunta hace varios años en un artículo corto. Y dio dos razones, una general y una específica.

La razón general tiene que ver con la educación prevaleciente, donde los errores se castigan, desde el colegio, pasando por la universidad, y hasta en el trabajo. Y la manera más segura de minimizar la cantidad de errores es minimizar la cantidad de oportunidades de cometerlos. Al menos esa es una de las estrategias. Por lo tanto, el instinto de supervivencia y la poca urgencia de hacer algo nuevo lleva a la mayoría de las personas a evitar cambios profundos. Y adoptar el pensamiento sistémico, también en palabras del Dr. Ackoff, es un cambio de era: son tan profundos y numerosos los paradigmas que deben cambiar, que equivale a cambiarle el conjunto de creencias compartidas a un gran grupo de personas; es un cambio de su visión del mundo.

¿Para qué “arriesgarse” con algo que contradice la corriente principal? Es defendible hasta cierto punto esta posición.

La razón específica tiene relación con el pensamiento sistémico mismo, donde los expertos se reúnen en conferencias para presentar sus investigaciones y casos en una jerga casi hermética al resto.

Yo estoy más de acuerdo con lo primero que lo segundo, aunque es verdad que a veces la jerga técnica espanta, pero no puede ser la razón principal.

Temores que bloquean

Antes de su partida, el Dr. Goldratt dejó escrito un prefacio al libro que no pudo escribir acerca de la ciencia de la gerencia. En ese prefacio habla de tres temores que provocan comportamientos en muchos gerentes. Depende del gerente el grado en que le afecte cada uno.

Conclusión

Con una experiencia laboral muy compleja, donde nunca ha experimentado lo que significa eliminar los conflictos y manejar de modo simple un sistema complejo, donde la incertidumbre solo crece e incrementa la complejidad del sistema, el gerente se aferra a las pocas certezas que tiene, esas que adquirió en sus estudios, como si fueran dogmas.

Invito a todos los lectores a revisar sus propias creencias, al menos en administración de empresas, y confiar más en su capacidad de razonamiento. Tendrá sorpresas agradables.

Matías Birrell Rodríguez

De profesión, ingeniero civil de industrias, con mención en mecánica, con un MBA en finanzas. Pero principalmente, experto en Teoría de Restricciones y autor de libros acerca de este tema, habiendo trabajado y aprendido directamente con el Dr. Goldratt en Goldratt Group. Adicionalmente es director de www.goldfish.cl, empresa que ofrece aplicaciones en la nube, simples y asequibles, para aplicar estos conceptos a las decisiones diarias. OTIF100 (manufactura), Fill Rate 100 (cadena de suministro).

¿Quieres optimizar tus procesos? Contáctame

La entrada ¿En qué creen los gerentes? se publicó primero en Ingenieria Industrial Online.

Los principales impulsores de lo que denominamos Industria 4.0 son sin duda la conectividad y el desarrollo vertiginoso de las tecnologías de la información. Uno de los principales factores que nos traen hasta aquí es la incorporación – cada vez mayor – de sensores. La capacidad de integrar sensores a casi cualquier dispositivo hace que también aumente la capacidad de recopilar y transmitir datos en tiempo real, para su posterior análisis. El avance de la tecnología de sensores, su diseño cada vez más compacto, sus precios cada vez más bajos, y su capacidad de integración cada vez mayor, hace que su aplicación trascienda del uso en sistemas de producción, e incluso podemos interactuar con ellos día a día en un entorno doméstico; a este fenómeno se le conoce como la Internet de las Cosas (IoT) y la Internet Industrial de las Cosas (IIoT).

¿Qué logramos a través de la Internet de las Cosas? ¿Cómo puede representar un factor de transformación digital? Básicamente, las proyecciones al año 2021 estiman que cerca de 4.000 millones de personas estén conectadas a Internet; y el siguiente paso implica que no solo las personas, sino las cosas, los procesos, las instalaciones o los negocios en general, puedan conectarse entre sí, formando una red de redes; en este caso, las proyecciones estiman que más de 50 billones de objetos estén conectados a lo que hoy conocemos como Internet (2021).

¿Qué evolución estamos viendo en este contexto? En este sentido, considero que estamos siendo testigos de la materialización de muchas de las ideas más disruptivas de los 90s y de los años 2000; tal es el caso de los gemelos digitales (digital twins).

¿Qué es un gemelo digital (digital twin)?

Un gemelo digital es una representación virtual computarizada de un objeto (entidad), una persona, un activo, sistema o un servicio físico. En esencia, un objeto físico transmite la información deseada la cual es procesada y proyectada en un entorno digital, esta información se actualiza periódicamente a través de los datos de sensores, a través de tecnologías de seguimiento, y en teoría, una mayor frecuencia de actualización y una mayor calidad de los datos, mejorará la precisión del modelo digital.

Los gemelos digitales pueden contener y rastrear el contexto histórico de los objetos digitalizados, y esto puede resultar útil para para probar, registrar, reparar determinados comportamientos de la entidad que se duplica digitalmente, e incluso predecir el comportamiento futuro de la misma. Uno de los principales atractivos de los gemelos digitales consiste en la posibilidad de conectar a un objeto físico para recopilar datos en tiempo real de este. El concepto ha existido desde los primeros días de la computación, pero se está volviendo cada vez más importante en el siglo XXI a medida que se desarrollan las tecnologías habilitadoras, como las tecnologías de seguimiento, Big Data y Cloud Computing.

En teoría, los gemelos digitales deberían funcionar exactamente como el objeto o el sistema del mundo real; para lograrlo, debe articular tres conceptos claves: el objeto (la entidad física), la conectividad entre el mundo físico y el mundo digital (mediante sensores, actuadores y controladores) y la simulación (el entorno 3D que sirve como interfaz entre los usuarios y el gemelo digital).

¿Cuáles son las aplicaciones de los gemelos digitales?

Una organización puede emplear un gemelo digital en múltiples contextos, por ejemplo, es posible obtener una representación virtual de un automóvil, de los ascensores de una unidad residencial, de las bahías de parqueo de un centro comercial, de una planta completa de producción, etc. En este sentido, los gemelos digitales tienen la capacidad potencial de proporcionar formas eficientes de probar cómo funciona cada unidad digitalizada, como un homólogo de la entidad en el mundo real.

Puede considerarse como una evolución de la simulación convencional, toda vez que los parámetros de cada entidad estarían recibiendo información posiblemente en tiempo real de acuerdo a la conectividad establecida: sensores, tecnologías de seguimiento y parámetros de medición.

Una de las principales aplicaciones de los gemelos digitales es la monitorización de productos en busca de fallas, antes de su salida al mercado; en este orden, sería posible predecir problemas, soportar la identificación de soluciones y probar escenarios a través de los entornos digitales.

El alcance de los gemelos digitales guarda directa relación con la naturaleza de los sensores y la capacidad de procesamiento de los datos, y su ámbito de aplicación dependerá del tipo de información que cada dispositivo pueda obtener y procesar de la entidad física. De acuerdo al desarrollo de la industria de sensores, de los procesadores y de la Big Data, los gemelos digitales tienen ámbitos ilimitados de aplicación: Producción, locaciones administrativas, logística, salud, energía, industria aeroespacial, etc.

¿Qué tecnología de seguimiento utilizan los gemelos digitales?

De acuerdo Michal Ukropec (Experto en gemelos digitales), elegir la mejor tecnología de seguimiento es complicado. Existen en el mercado tecnologías como: GPS, BLE, UWB, RFID, WiFi, IoT o cámaras, las cuales no son excluyentes, pero la elección del conjunto de tecnologías dependerá del contexto de aplicación.

Algunas consideraciones que comparte Michal:

Consideraciones al momento de implementar un gemelo digital

Consideremos, por ejemplo, la aplicación de un gemelo digital que represente toda la operación de una planta de producción. Los datos alrededor de la operación llegarán quizá en tiempo real, las líneas reportarán rendimientos, movimientos; las máquinas registrarán su grado de utilización, etc. Los datos que anteriormente estaban disponibles en lotes cada 8, 12, 24 horas, ahora estarán disponibles cada minuto. La pregunta que me surge es ¿Qué va a hacer con esa información? ¿La restricción de su proceso de toma de decisiones se ve limitada por la disponibilidad de información en tiempo real? No lo sé, pero es un interrogante que vale la pena formularse, y evocaré a Javier Arévalo (Goldratt Partner) quien hace poco me mencionaba: “Lo que usted no haga bien en papel y lápiz, difícilmente lo hará bien con tecnología”.

“Lo que usted no haga bien en papel y lápiz, difícilmente lo hará bien con tecnología”.

Es por eso que vale la pena plantearse si la disponibilidad de información en tiempo real de mi sistema (entidad, proceso, producto, etc.) es una necesidad que justifica un proyecto de implementación de gemelos digitales.

El conjunto de datos requerido para la construcción del gemelo digital de un sistema de producción varía de un sistema a otro, sin embargo, puede considerar la información del siguiente cuadro como un caso típico:

Así podemos ver entonces, que el desarrollo de un gemelo digital requiere del conocimiento profundo del objeto físico (entidad, activo, sistema, etc.). Además, de la consideración de las tecnologías de seguimiento, pero sobre todo, del enfoque sistémico que le permita determinar sobre la pertinencia de esta aplicación tecnológica.

Caso de aplicación: Whirlpool Corporation (Polonia)

Whirlpool Corporation en Polonia con 80.000 m², docenas de montacargas y remolcadores. Más de 250 sensores RTLS para el análisis de logística y 60 estaciones de trabajo equipadas con un sistema de pedidos automatizado para la gestión logística. Diagramas de espagueti, análisis de mapas de calor y saturación para identificar cuellos de botella, ineficiencias y otros potenciales de mejora continua.

¿Quieres probar demos de gemelos digitales?

Si quieres probar un demo de gemelo digital desde tu celular, puedes hacerlo a través de:

La entrada ¿Qué son los gemelos digitales? Aplicaciones en la Industria se publicó primero en Ingenieria Industrial Online.