La elegibilidad de máquinas pertenece al motor de programación

Toda sesión de planificación comienza con la misma pregunta silenciosa: ¿qué máquinas pueden correr este producto en esta etapa? Se hace una vez por producto, una vez por etapa, una vez por cronograma, y se responde de memoria, o desde una hoja de cálculo que todos han visto y nadie posee. La respuesta es un hecho de la planta. No cambia con la carga de trabajo, la semana ni el planificador. Es una propiedad fija del equipo y de la clase de producto. Sin embargo, en muchas plantas ese hecho vive fuera del motor de programación, y cada cronograma lo vuelve a aplicar a mano.

Qué hereda un cronograma cuando la elegibilidad vive fuera del motor

Cada cronograma depende de la memoria. El mecanismo es ordinario: el planificador construye un cronograma y, en cada etapa, consulta la misma fuente no modelada: una cabeza, un colega, una hoja de notas. La comprobación es rápida, así que se repite constantemente, y cada repetición es una oportunidad para que la respuesta se desvíe de la planta tal como es realmente. La comprobación también consume tiempo de planificación en cada cronograma, incluso cuando la respuesta es correcta, porque se vuelve a aplicar a cada etapa de la ruta y a cada clase del cronograma. Una re-ejecución repite la comprobación. Un planificador nuevo la repite sin el contexto anterior. Una clase de producto poco familiar recibe una suposición en lugar de una respuesta verificada.

Cuando la suposición es correcta, nada parece estar mal, que es exactamente la razón por la que el fallo permanece invisible. El cronograma asigna trabajo que una máquina no puede procesar, y el desajuste solo sale a la superficie cuando el cronograma se encuentra con la línea y la máquina no puede tomar el trabajo. Para entonces el tiempo se ha gastado y el cronograma tiene que repararse. Nada de esto es exótico, y nada requiere malas personas ni malas plantas. Un cronograma que depende de la memoria de una persona es frágil, y una planta que lleva la elegibilidad en una hoja de cálculo no modelada ha convertido la memoria en un insumo permanente.

La elegibilidad es conocimiento estructural

La elegibilidad es conocimiento estructural, y el conocimiento estructural pertenece al modelo. Un motor de programación solo puede respetar las restricciones que se le dan. Sin un conjunto elegible, no tiene forma de tratar una máquina como otra cosa que un candidato para cualquier producto. Ese es el modo de fallo de la hoja de cálculo no modelada, reproducido. Un mejor planificador o una lista de verificación más estricta no lo arreglan. La solución es dejar de tratar la elegibilidad como contenido del cronograma y empezar a tratarla como estructura de la planta.

Dos preguntas se esconden dentro de la palabra asignación. La primera es qué PUEDE correr: el conjunto elegible, las máquinas que realmente pueden procesar esta clase en esta etapa. La segunda es qué CORRERÁ: la asignación de máquinas dentro de ese conjunto. Son diferentes en su naturaleza. Qué puede correr es un hecho sobre la planta. Qué correrá es el cronograma. La planta decide la elegibilidad una vez. El motor debería llevarla y respetarla en cada cronograma posterior.

Cómo lo modela el motor

La elegibilidad entra al motor como un registro de capacidad, una máquina a la vez. Una máquina lleva una velocidad de línea para las clases de producto que puede procesar como etapa de flujo, y un tamaño de lote con un tiempo de ciclo de lote para las clases que puede procesar como etapa de lote. Esas entradas son el registro. Los productos heredan la capacidad de su clase, así que la elegibilidad se define por clase y por etapa, nunca de forma global: una clase enruta solo por las etapas que requiere, cada máquina pertenece a exactamente una etapa, y no existe capacidad por producto. Las entradas dicen dos cosas: que la máquina puede procesar la clase en esa etapa, y cuánto tarda. Cuando las entradas existen, la máquina es candidata para la clase en esa etapa. Cuando no existen, no lo es.

La aplicación se sigue directamente del registro. En los modos Auto y Semi-Auto, el motor restringe la asignación de máquinas a las que realmente pueden procesar el producto en esa etapa. Una máquina sin entrada de capacidad para una clase no es candidata para esa clase, y otras clases siguen fluyendo por todo el grupo de máquinas. No hay una regla de elegibilidad separada superpuesta; la restricción se desprende de qué entradas existen.

La optimización trabaja entonces dentro del conjunto elegible. El modo Auto optimiza juntos la secuencia de producción y las asignaciones de máquinas. El modo Semi-Auto mantiene fija la secuencia de producción y optimiza las asignaciones de máquinas dentro de ella. Ambos minimizan el tiempo total de producción. Un hecho permanece fuera del modelo: por qué una máquina puede o no procesar una clase. Esa razón se decide en la planta y se introduce como capacidad. La capacidad es un hecho estático y configurado. El motor no la mide ni la aprende.

Qué cambia para el planificador

Con el conjunto elegible implícito en las entradas, el trabajo del planificador cambia. El tiempo de planificación va a las decisiones que el planificador posee: qué trabajos correr y, en Semi-Auto, la secuencia de producción en la que corren. El motor guarda qué puede correr, así que el planificador no lo vuelve a verificar en cada cronograma. Qué debería correr comienza como un juicio de planificación; el motor convierte entonces esa intención en un cronograma viable, en Auto eligiendo también la secuencia de producción, y en Semi-Auto manteniendo fija la secuencia y optimizando las asignaciones de máquinas dentro de ella. De cualquier manera, el objetivo es el mismo: minimizar el tiempo total de producción.

Vale la pena ser precisos sobre el límite de ese cambio, porque solo es real dentro de él. Restringir el conjunto de candidatos como parte de una búsqueda y optimizar la asignación dentro de él son comportamientos de los modos Auto y Semi-Auto. El modo Manual no ejecuta algoritmo alguno, así que nada de eso ocurre allí, pero la misma comprobación de compatibilidad de máquinas sigue ejecutándose como validación por fila: introduce una máquina que no puede procesar la clase de producto y el sistema rechaza la fila. Tampoco es la elegibilidad todo el problema de asignación. Es un hecho estructural entre varios que el motor modela: los cambios, los calendarios, la disponibilidad y el suministro de material dan forma a las asignaciones reales. El punto no es que la capacidad sea la única restricción. Es que una restricción que el motor no modela es una restricción que el planificador lleva a mano.

Con el cambio viene una obligación. La elegibilidad se expresa por lo que está registrado, así que las entradas son un documento de trabajo. Los datos de capacidad deben introducirse y mantenerse como cualquier otra configuración de la planta. El motor no infiere la capacidad de una máquina de ningún otro lugar, y una capacidad que nunca se introdujo deja a la máquina fuera del conjunto elegible. Cuando la omisión es deliberada, el modelo funciona como se pretende. Cuando no lo es, esa es la razón por la que los datos deben mantenerse al día.

Dónde vive la elegibilidad en tu planta

Así que haz la pregunta donde importa: cuando un planificador necesita saber qué máquinas pueden correr esta clase en esta etapa, ¿de dónde sale la respuesta? Si sale de una cabeza o de una hoja de cálculo, el cronograma hereda la memoria, una re-aplicación a la vez. Si sale del modelo, la planta ha decidido una vez, y cada cronograma respeta esa decisión. La misma prueba se aplica a cualquier herramienta de programación que evalúes: ¿es el conjunto elegible una entrada que el motor respeta, o un detalle que el planificador debe volver a aplicar a mano? Decide la elegibilidad una vez, en la planta, introducida como capacidad. Luego deja que el motor la respete en cada cronograma.