Planificación y programación avanzada: qué tiene que cumplir un programa de producción

Damos por supuesto que usted conoce su proceso y que nunca ha comprado software de programación.

Restricciones de programación que una línea real tiene que cumplir

Empiece por las restricciones, porque el software sólo resulta interesante en la medida en que sea capaz de representarlas. Una máquina fabrica una orden cada vez, y el tiempo para pasar de la orden que está fabricando a la siguiente depende normalmente de cuáles sean esas dos órdenes. De color claro a oscuro basta un repaso; de oscuro a claro hay que purgar y limpiar. Eso es la preparación dependiente de la secuencia: el tiempo de preparación no es una propiedad de una operación, sino de un par de operaciones sobre un recurso concreto, porque el mismo cambio de color cuesta una cosa en una prensa grande y otra en una pequeña, y en algunas líneas depende además del estado de la máquina. Es la restricción que más a menudo falta en el sistema de registro, y por eso un plan salido del ERP parece tantas veces una lista ordenada y no una secuencia.

Luego están las restricciones que no van asociadas a una sola máquina, y que en muchas líneas aprietan más que la matriz de preparación. Un troquel, un molde o un banco de ensayo sólo puede estar en un sitio a la vez, así que dos celdas que por separado podrían fabricar la orden no pueden hacerlo las dos. Un operario cualificado es el mismo tipo de recurso escaso: tres personas en el turno y una sola certificada para esa clase de soldadura significa que esa clase tiene una capacidad de uno. El aire comprimido, un horno o un puente grúa se reparten en un área, así que dos órdenes que caben por separado pueden no caber juntas.

La disponibilidad de material es una condición previa dura y una entrada blanda. La orden no puede empezar antes de que llegue el componente, pero la fecha de llegada es una promesa de un proveedor con su propia fiabilidad. El programa debería mostrar, por tanto, qué órdenes dependen de una entrega que todavía no ha llegado, para que la exposición se vea en el plan en lugar de quedar promediada dentro de un plazo de entrega y descubrirse la mañana en que el material no aparece.

Los calendarios pesan más de lo que la gente espera. Los patrones de turno varían por área, no por planta: el tratamiento térmico trabaja de noche y el montaje no, y un cambio de formato en viernes que no pueda terminarse antes del fin del turno se hará dos veces. Las ventanas de mantenimiento, los festivos y la parada anual son periodos en los que un recurso existe en la lista de activos y no está disponible para producción.

Y hay reglas de proceso que no tienen nada que ver con la capacidad. El curado, el secado, el enfriamiento y la cuarentena imponen esperas mínimas entre operaciones, y a menudo también máximas: curar al menos cuatro horas, recubrir antes de veinticuatro, usar el adhesivo mezclado dentro de su vida útil, lavar la pieza antes de que aparezca óxido superficial. Un programador que entiende las esperas mínimas pero no las máximas generará sin avisar planes que tiran material a chatarra. Algunos pares de operaciones tienen que ser consecutivos porque la pieza no se puede dejar a medias; algunos lotes hay que hacerlos al tamaño de la cuba y no a la cantidad de la demanda.

Por qué la explosión de MRP da fechas que nadie puede cumplir

El MRP hace algo genuinamente útil, y no es programar. Explota la demanda a través de las listas de materiales, la netea contra el stock y las órdenes abiertas, la desplaza con un plazo de entrega fijo por artículo, y le dice qué fabricar o comprar y más o menos cuándo empezar. Para poder hacerlo con miles de referencias, supone que hay capacidad disponible siempre que la aritmética la pida.

Ese supuesto falla sin hacer ruido. Dos órdenes quieren la prensa a las diez y el MRP coloca las dos ahí. El desplazamiento por plazo de entrega es un número que se fijó una vez, una media de tiempo de cola, de proceso y de transporte en unas condiciones que ya no se dan, y los cambios de formato o no están o están escondidos dentro como un suplemento plano que no depende de la secuencia. El resultado es aritméticamente consistente y físicamente inalcanzable, lo cual es peor que estar equivocado, porque en el sistema parece correcto.

La planta absorbe la diferencia. Alguien resecuencia a mano, normalmente bien, con un conocimiento que vive en una o dos cabezas, y el plan pasa a ser una sugerencia. Todo lo que se deriva de él hereda el error: las fechas de entrega comprometidas, el momento de comprar, el dimensionamiento de la plantilla, la cifra de capacidad que se le da a comercial. Cuando un planificador responde inflando los plazos de entrega, la protección es real y el coste también, porque un plazo inflado es trabajo liberado antes de tiempo, que se convierte en producto en curso parado entre puestos.

El Excel que sustituye a esas fechas es una mejora genuina con un techo. Funciona porque el planificador lleva en la cabeza la matriz de cambios y los conflictos de utillaje, y falla al escalar, cuando él se va de vacaciones, y ante la pregunta de qué se rompe si se acepta esta orden.

Qué cambia la programación a capacidad finita

La programación a capacidad finita da la vuelta a la pregunta. En lugar de preguntar cuándo debería empezar una operación si nada se interpusiera, coloca las operaciones sobre recursos que ya tienen trabajo encima, respetando preparaciones, calendarios, utillaje y precedencias, e informa de las fechas que salen de ahí. Las fechas pasan a ser una salida y no una entrada.

Las consecuencias son prácticas. La secuencia en cada recurso es explícita, así que se puede explotar la matriz de preparación: donde la preparación se lleva una parte apreciable de la capacidad disponible, agrupar productos compatibles recupera horas de cambio sin inversión. Si ese es su caso o no es un número que puede medir esta semana, y conviene medirlo antes, porque en una línea con cambios de cinco minutos y un problema de material la secuenciación no recupera casi nada. Los cuellos de botella se vuelven visibles como cargas y no como opiniones. Como el plan está restringido, añadir una orden muestra qué desplaza, que es lo que hace posible un compromiso de entrega creíble.

También cambia la liberación. Un plan de capacidad infinita libera trabajo tan pronto como los desplazamientos lo permiten; un plan finito libera cuando la restricción puede asumirlo, lo que baja el producto en curso y acorta la distancia entre fabricar un defecto y encontrarlo. Nada de esto es gratis: el modelo hay que mantenerlo, y es tan honesto como los tiempos que contiene.

Planificar, programar y despachar son tres trabajos distintos

Confundirlos es el motivo más habitual de que un proyecto de programación acabe produciendo algo que no usa nadie. La planificación trabaja en semanas y meses. Responde si la demanda es factible en agregado, si hace falta un segundo turno en marzo, a qué comprometerse con los proveedores. La unidad es una familia y una semana; más precisión sería falsa, porque la demanda tampoco es precisa.

La programación trabaja en horas y días. Responde cuál es la secuencia en cada recurso para los próximos turnos, con las preparaciones que esa secuencia implica, y es lo que significa el APS en el sentido más estricto.

El despacho trabaja en minutos. Responde qué empieza a continuación el operario de esta celda, dada la parada, la primera pieza rechazada, el material que no llegó. Su sitio es aquello que el operario mira de verdad — un terminal de MES, una lista de despacho, una secuencia pegada a la máquina — y lo que importa es que esté cerca del trabajo y que se le permita desviarse del programa, porque la realidad también vota.

El modo de fallo es usar una herramienta a la altura equivocada: programar al minuto con tres semanas de vista, o planificar capacidad a partir de una lista de despacho. El otro es prohibir la desviación en la capa de despacho, lo que convierte el sistema en un obstáculo y garantiza que se le dé la vuelta.

Qué datos necesita un APS: rutas de fabricación, tiempos de ciclo, cambios de formato

Un motor de programación es un cálculo sobre sus datos maestros. Si los datos son decorativos, la salida es decorativa y segura de sí misma.

Las rutas de fabricación tienen que reflejar cómo se fabrica realmente la pieza, alternativas incluidas. Si una orden puede ir en tres máquinas pero la ruta nombra una, el programador encola trabajo ahí e informa de un cuello de botella que usted no tiene. Si una ruta se salta una operación que siempre ocurre — un desbarbado, una inspección, una espera de enfriamiento — todas las fechas se quedan cortas en esa misma medida.

Los tiempos de ciclo hay que medirlos, no heredarlos. Los tiempos estándar de la mayoría de los ERP se metieron en el arranque y reflejan un utillaje y un operario que quizá ya no existan. No necesita tiempos perfectos, sólo tiempos cuyo error sea pequeño y no sesgado: una ruta en la que todas las operaciones son optimistas en el mismo margen se acumula en un programa que al final de la semana se equivoca en un turno.

Los tiempos de cambio de formato son el dato que más a menudo falta por completo, y el más valioso. Una matriz completa de todos los pares de producto rara vez se puede mantener. Lo que funciona es agrupar los productos en familias según lo que realmente determina la preparación — color, material, utillaje, temperatura, ancho — y definir tiempos entre familias, con excepciones sólo donde importan. Cuente con mantener esa matriz familia a familia por grupo de recursos y no una sola para la planta, porque la misma transición rara vez cuesta lo mismo en dos máquinas distintas.

El producto en curso actual es la parte que la gente olvida. Un programa para mañana parte del estado que tiene la planta esta noche: qué está a medias, dónde está, qué hay montado en cada máquina. Si ese estado se teclea al final del turno desde un parte en papel, el programador está optimizando una fábrica que existió hace horas.

Los datos malos se delatan solos. Un recurso siempre saturado y todo lo demás parado, que normalmente significa que las rutas lo embudan artificialmente. Los planificadores sobrescriben las mismas órdenes todos los días, lo que significa que falta una restricción en el modelo. Las órdenes se confirman en bloque en el mismo minuto, lo que significa que las confirmaciones se teclean después y las horas de inicio son ficción. El instinto es ajustar el motor; la causa casi siempre son los datos maestros.

Cómo juzgar un programa

La entrega a tiempo es el resultado que importa, medida contra la fecha que se le dio al cliente y no contra la última revisión interna, o la cifra mejorará mientras la experiencia del cliente no.

Las horas totales de cambio de formato por semana son la medida más limpia de si la secuenciación está haciendo algo, y se convierten directamente en capacidad.

El producto en curso y el tiempo de flujo dicen si el plan está liberando con sensatez. Un programa que mejora la entrega a tiempo inundando la planta de liberaciones tempranas ha trasladado el problema a los pasillos.

La adherencia al programa — cuánto de lo planificado para un turno se fabricó realmente, y en la secuencia prevista — es la medida honesta de si el plan es creíble. Un programa con métricas teóricas excelentes que la planta dejó de seguir antes de comer es un documento.

La utilización es la trampa. Mantener ocupada cada máquina en un recurso que no es la restricción produce inventario, no producción, y una línea cargada cerca de su techo en todas partes no tiene nada con lo que absorber la variabilidad, así que las colas crecen de forma no lineal y los plazos empeoran mientras la cifra de utilización mejora. Vigílela en la restricción y en el resto ignórela en buena medida.

Política de reprogramación y nerviosismo del programa

Un motor capaz de replanificar en segundos invita a replanificar constantemente. Resístase. Si la secuencia cambia cada vez que se mueve algo, la planta aprende que el plan de las ocho no es el plan de las diez, y vuelve a fabricar lo que le parezca razonable. Esa inestabilidad se llama nerviosismo, y destruye la confianza más deprisa que un programa mediocre.

El patrón que funciona es un horizonte congelado y una política. Dentro de la ventana la secuencia no cambia salvo por bloqueos reales, de modo que las preparaciones ya empezadas no se tiran; fuera de ella se permite reoptimizar. La regla práctica es replanificar con una frecuencia no mayor que la longitud de la ventana congelada, y fijar esa ventana a partir de dos cosas que puede observar en el área: cuánto dura una preparación y cada cuánto aparece un bloqueo real. Un taller de mecanizado con órdenes de una hora y un choque de utillaje casi a diario congelará unas horas y replanificará cada turno; una planta de proceso con campañas de una semana congelará días. En cualquier caso, las ejecuciones programadas se complementan con ejecuciones disparadas por eventos ante una avería, una entrega que falta o una orden urgente.

Dos cosas hacen que la política funcione. La lista de excepciones tiene que ser explícita: qué cuenta como motivo para romper el congelado y quién puede autorizarlo. Y cuando el programa sí cambia, el encargado tiene que poder ver por qué, porque un cambio sin explicar se lee como que el software no es de fiar.

Dónde encaja el APS junto al ERP y al MES, y quién decide qué

El ERP es el dueño del mundo comercial y de materiales y es la fuente de qué hay que fabricar y para cuándo. El APS es el dueño de la secuencia: toma la demanda y el material del ERP, las restricciones de su propio modelo y el estado de planta de la ejecución. El MES es el dueño de la ejecución y del registro de la misma, y es además el sensor del APS, sin el cual el programador es ciego al presente.

El bucle sólo se cierra si circula en los dos sentidos: del APS al MES va el programa, del MES al APS va lo que pasó de verdad. Un fichero diario de confirmaciones basta para planificar mañana y no basta para replanificar esta tarde.

Las responsabilidades hay que escribirlas antes del arranque, porque las discusiones son previsibles. Quién puede cambiar una fecha de entrega. Quién mantiene la matriz de cambios de formato y los tiempos de ciclo, y con qué periodicidad de revisión. Quién puede sobrescribir la secuencia en la celda, y si esa sobrescritura queda registrada. Qué sistema manda cuando el ERP y el programador no se ponen de acuerdo sobre lo que hay en stock. Dejar esto implícito es el motivo habitual de que una implantación técnicamente sólida se atasque.

Cómo hacer una evaluación que le diga algo

Una demostración del proveedor con datos del proveedor sólo demuestra que el software arranca. Júzguelo en su planta; el ejercicio sale barato si lo acota.

Elija un área con restricciones reales — preparaciones importantes, utillaje compartido, órdenes que compiten — en lugar de la planta entera, y coja un periodo pasado de cuatro a ocho semanas del que sepa qué se fabricó y qué llegó tarde. Dele al candidato los datos maestros que tiene hoy, no una versión limpiada para la prueba, porque el estado de sus datos es una de las cosas que está midiendo.

Después pídale que reproduzca un programa para ese periodo y compare. ¿Representa el modelo sus restricciones, o necesita que las incómodas se simplifiquen hasta desaparecer? ¿Maneja las esperas máximas igual que las mínimas, si su proceso tiene una caducidad o una vida útil de mezcla? ¿Cuánto tiempo de cambio de formato consume su secuencia frente a lo que usted gastó realmente, y qué dice de las órdenes que entregó tarde? Luego ejecute los escenarios que importan: el cuello de botella parado dos días, una orden urgente a mitad de semana, una entrega que llega una semana tarde.

Después siente a un planificador delante de la herramienta una tarde entera. La pregunta no es si el motor es listo, sino si una persona puede ver por qué tomó una decisión y ajustarla sin pelearse con la herramienta; un programador con el que nadie puede discutir es un programador que no usará nadie. Pregunte cuánto cuesta mantener el modelo cuando cambia un producto, una máquina o un tiempo de preparación, y en cuántos sitios hay que tocarlo. La mayoría de los programas se degradan no porque el motor se equivocara, sino porque nadie se hizo dueño del modelo cuando terminó el proyecto.

Dónde encaja Meta Smart Factory

Los módulos de APS y MRP de Meta Smart Factory hacen la parte de capacidad finita de todo esto, contra un modelo de restricciones que cubre preparaciones dependientes de la secuencia, utillaje compartido, cualificación de operarios y calendarios de turno por área, con ejecución de escenarios para las alteraciones anteriores. Como viven en la misma plataforma que el módulo de MES, no hay traspaso nocturno de ficheros entre la ejecución y el programador, de modo que el estado de planta está tan actualizado como lo permitan sus puntos de confirmación y la disciplina de registro de sus operarios. Eso es una condición, no un detalle: si la mitad de las confirmaciones se meten en el descanso y el puesto de montaje manual no tiene punto de lectura, la arquitectura no le salva. Decidir dónde están esos puntos es trabajo de implantación, no un subproducto de ella. La costura con el ERP para órdenes, listas de materiales y confirmaciones forma parte del mismo trabajo.

Las partes que deciden si todo esto funciona no nos toca ponerlas a nosotros: tiempos de ciclo medidos, una matriz de cambios de formato de la que alguien sea dueño, rutas de fabricación que se correspondan con cómo se fabrica realmente la pieza y una política de reprogramación escrita. Si está empezando con esto, el primer paso útil no es una demo sino la comparación histórica descrita arriba, sobre un área restringida, con sus datos tal y como están.