Pregunta si el software puede modelar tu planta

Cuando los compradores comparan herramientas de programación, sopesan lo inteligente que suena el optimizador. La prueba real es si la herramienta puede representar la planta: etapas de lote y de flujo, cambios direccionales, retrasos de transferencia, calendarios de turnos e inactividad.

La demo lidera con el algoritmo

La demo típica de software de programación lidera con el algoritmo. Una diapositiva sobre cómo la búsqueda encuentra mejores cronogramas y los puntos de referencia no dejan de mejorar. Esa es la apuesta fácil, y es la misma apuesta para cada planta de la sala. La pregunta que nadie hace en la demo es la que decide si la herramienta funciona siquiera: ¿puede contener los hechos físicos de esta planta? Una etapa de lote que alimenta a una continua, un cambio que tarda tres veces más en un sentido que en el otro, veinte minutos para bombear material entre etapas, un calendario de turnos que cierra el viernes por la tarde. Si el modelo no puede contener esos hechos, el algoritmo ingenioso está optimizando una planta que no existe.

Planes que parecen óptimos y mueren en la planta

La literatura de programación ha documentado durante décadas la brecha entre los cronogramas optimizados y los ejecutados. La teoría optimiza bajo supuestos estáticos y deterministas; la planta corre una realidad dinámica y estocástica. Cuando un cronograma no sobrevive al contacto con la planta, la respuesta estándar es reprogramar, lo que puede retrasar o invalidar el trabajo que debía proteger. La inestabilidad del cronograma es un fenómeno estudiado. Cuando el cronograma no deja de moverse, quienes operan la línea dejan de confiar en él y el esfuerzo se va en perseguir revisiones. No hace falta ninguna estadística; los gerentes de planta lo han vivido. La sofisticación del optimizador se mide sobre un modelo simplificado, mientras la planta corre la realidad complicada. La brecha entre ambos es una brecha de modelado.

La prueba real es el modelo, no el optimizador

El factor decisivo en la selección de software de programación es, por tanto, la fidelidad del modelo, no la sofisticación del optimizador. La fidelidad del modelo es cuán fielmente representa la herramienta el proceso: el comportamiento de las etapas de lote frente a las de flujo, la dirección de los cambios, los retrasos de transferencia y de traspaso, los calendarios de turnos y la inactividad. La sofisticación del optimizador, el lenguaje de la optimización, es la apuesta del algoritmo: lo inteligente que suena el optimizador cuando el proveedor lo presenta. Una herramienta de programación solo es tan confiable como el modelo de proceso que hay debajo del optimizador. Un optimizador potente sobre un modelo que no puede representar la física de la planta produce cronogramas que no pueden ejecutarse, diga lo que diga la apuesta.

Cinco hechos físicos que una herramienta de programación debe contener

¿Qué significa «representar el proceso» en la práctica? Cinco hechos físicos. Pregúntalos a cualquier herramienta.

Etapas de lote y de flujo en una misma ruta. Una mezcladora trabaja por lotes en un ciclo; una envasadora corre a una tasa por hora, y una ruta contiene ambas. ¿Puede la herramienta contener la física por etapa, o fuerza una única velocidad de línea combinada?

Cambios cuya dirección importa. Pasar de un producto a otro tarda distinto que volver. En los valores ilustrativos de abajo, el lavado hacia un producto claro tarda mucho más que el aclarado en la otra dirección. ¿Puede la herramienta contener un valor de cambio que difiera según la dirección?

Retrasos de transferencia y de traspaso. El material tarda en moverse entre etapas, por bomba, cinta transportadora o carretilla elevadora. ¿Puede la herramienta encadenar un arranque aguas abajo a una finalización aguas arriba más el tiempo de transferencia, o el material llega al instante?

Calendarios de turnos, excepciones e inactividad. Las noches, los fines de semana, los festivos y la inactividad reservada son hechos de capacidad. ¿Puede la herramienta programar trabajo dentro de las ventanas laborales, o planifica en tiempo transcurrido como si la planta nunca se detuviera?

Una espera visible cuando la línea se queda sin material. Cuando una etapa aguas abajo supera al suministro de aguas arriba, el cronograma debe mostrar una espera, no asumir que el material ya estaba allí. ¿Puede la herramienta mostrar la inanición?

Una herramienta que no puede contener uno de estos produce cronogramas que la planta no puede seguir.

Cuánto valen los cinco hechos en valores

Los cinco hechos no son abstracciones. Cada uno es un valor que una planta puede declarar y una herramienta puede contener o perder. Anota los tuyos antes de cualquier demo, en las unidades que use tu planta. Los valores de abajo son ilustrativos y específicos de cada planta; los tuyos diferirán.

Configuración Valor ilustrativo
Cambio, de producto oscuro a producto claro De 60 a 90 minutos
Cambio, de producto claro a producto oscuro De 15 a 30 minutos
Etapa de lote: tamaño de lote y ciclo 2.000 kg en un ciclo de 45 minutos
Etapa de flujo: tasa de producción de la línea 6.000 kg por hora
Transferencia entre etapas 20 minutos
Patrón de turnos Cinco días, dos turnos

Ahora pregunta qué hace una herramienta cuando no puede contener uno de ellos. Un modelo que combina una etapa de lote y una de flujo en una única velocidad de línea planifica la etapa rápida contra un suministro que la lenta no puede entregar. Un modelo que lleva un único valor de cambio para ambas direcciones trata igual la transición larga y la corta, y una semana que cabe sobre el papel no cabe en la planta. Un modelo que mueve el material entre etapas al instante arranca la etapa aguas abajo en el minuto en que terminó la de aguas arriba. Un modelo que planifica en tiempo transcurrido trata las noches y los fines de semana como horas de trabajo, y un cronograma de tres días aterriza como uno de cinco.

Ninguno de estos es exótico, y cada uno mueve el cronograma por su cuenta. Juntos producen un cronograma que la planta no puede ejecutar. Ningún optimizador sobre semejante modelo puede recuperarse, porque el modelo nunca contuvo los hechos que habrían expuesto el error.

El optimizador está acotado por el modelo

El optimizador está acotado por el modelo, y así es exactamente como funciona Schantt. El algoritmo de programación solo puede actuar sobre lo que representa el modelo. En el modo Auto la herramienta puede reordenar la secuencia de producción, agrupando los productos para que los cambios largos ocurran rara vez; eso solo funciona porque el modelo contiene valores de cambio direccionales. En el modo Semi-Auto la planta fija la secuencia de producción y el software optimiza el resto: qué máquina, qué día, cuándo arranca cada lote. En ambos modos el objetivo es el tiempo total de producción calculado sobre la física modelada, incluidos los ciclos de lote, los cambios, las transferencias, los calendarios y las esperas. El algoritmo solo es tan bueno como el modelo de proceso que hay debajo.

La fidelidad y el mantenimiento de los datos se compran juntos

La profundidad del modelado y el mantenimiento de los datos se compran juntos. La prueba de fidelidad incluye, por tanto, una pregunta sobre la introducción de datos: ¿pueden siquiera introducirse y mantenerse al día los valores propios de la planta, los tiempos de cambio, las velocidades de línea, los tamaños de lote, los tiempos de transferencia y la ruta de proceso? Schantt admite la introducción de configuración en masa con validación, de modo que un libro de valores se carga de una pasada. Pero el planificador es dueño de los números. La herramienta importa y valida; no los mide ni los mantiene. Un modelo preciso alimentado con tiempos de cambio desactualizados es un modelo preciso de la planta del año pasado. Un cronograma solo es tan bueno como los datos que hay debajo.

Cuando la sofisticación del optimizador gana legítimamente

Algunas plantas son genuinamente estáticas. Con una mezcla de productos estable, etapas equilibradas y un colchón generoso entre ellas, se aplica el modelo de programación estático y determinista, y la sofisticación del optimizador puede ser el factor diferenciador. La afirmación de esta entrada es que la fidelidad importa al menos tanto, no que siempre gana. Si la física de tu planta es suave, compara algoritmos libremente. Si es real, compara modelos primero.

Aplica primero la prueba de fidelidad del modelo

Así que aplica la prueba de fidelidad del modelo antes de comparar apuestas de algoritmos. ¿Puede la herramienta representar etapas de lote y de flujo en una misma ruta? ¿Puede contener un valor de cambio que difiera según la dirección? ¿Puede encadenar un arranque aguas abajo a una finalización aguas arriba más un tiempo de transferencia? ¿Programa dentro de calendarios de turnos e inactividad y muestra una espera cuando la línea se queda sin material? Si el modelo no puede contener la física de la planta, ningún optimizador sobre él puede ser confiable, diga lo que diga la diapositiva de puntos de referencia. La apuesta del algoritmo merece ser escuchada. No merece ser escuchada primero. La fidelidad del modelo es la prueba que te dice si el resto de la conversación trata sobre tu planta o sobre una planta que no existe.

¿Listo para optimizar su cronograma de producción?

Pruebe Schantt gratis — no se requiere tarjeta de crédito. Pase de una hoja de cálculo a un Gantt optimizado en 60 minutos.

Pruebe Schantt gratis