Una edición manual sin regla es improvisación

El planificador mueve el trabajo a mano a las dos de la tarde. Lleva años haciéndolo igual, adelantando un producto a otro porque llamó el cliente, porque el camión llega tarde, porque la planta dice que la envasadora necesitará atención antes del fin de semana. Tarda noventa segundos en el cronograma. Nadie más en la planta se entera de que ocurrió, ni por qué, ni si sirvió de algo.

Esa edición de noventa segundos es el tema de esta entrada. No porque las ediciones manuales estén mal. Con frecuencia son exactamente lo correcto, y cualquier argumento que diga lo contrario malinterpreta el trabajo. El problema es el silencio que las rodea. Una edición hecha sin regla es un acto aislado. El siguiente planificador hereda un cronograma que no puede explicar del todo, y la planta nunca puede saber si la edición fue una buena decisión, porque nadie anotó el razonamiento.

La edición no es el enemigo

Los planificadores llevan información que el cronograma no tiene. El camión de un proveedor que no ha llegado. Un aviso de cancelación de un cliente que no tomará la mercancía esta semana. Una máquina que, según la planta, está a punto de fallar aunque el calendario la muestre disponible. En un estudio observacional de planificadores en el trabajo, las solicitudes externas dispararon la mayor parte de lo que hacían, y dedicaron más tiempo a transmitir información al resto de la organización que a tomar decisiones de programación. El planificador es un centro de coordinación. Cuando entra en el cronograma y mueve un trabajo, normalmente está codificando algo que el modelo nunca vio.

Por eso una herramienta de programación que trata al planificador como un obstáculo está mal construida. El juicio humano es real, es específico de la planta y no va a desaparecer. La investigación sobre por qué las técnicas de programación de investigación operativa e IA tienen una adopción limitada en la práctica apunta a esta brecha: las técnicas modelan un problema limpio y el planificador humano se encarga del desordenado. La edición suele ser la respuesta correcta.

Los dos modos de fallo de las ediciones sin gobernar

Lo peligroso no es la edición. Es la ausencia de una regla a su alrededor. Esa ausencia produce dos modos de fallo: uno toca el cronograma con demasiado ímpetu y el otro con demasiado silencio.

El primero es la planta que edita por reflejo. El planificador desconfía de la herramienta, mueve los trabajos por costumbre y trata el cronograma del algoritmo como un borrador que siempre hay que corregir. La investigación sobre automatización y humanos tiene un nombre para este patrón de desconfianza hacia un sistema. En estudios controlados, la gente evita un algoritmo después de verlo errar, incluso cuando el algoritmo es más preciso que ellos. El disparador es el error visible, no el historial general.

Existe un fallo espejo, y una política que valga la pena también lo limita: el planificador que acepta la respuesta de la herramienta sin cuestionarla porque el sistema lo dijo. La sobreconfianza y la desconfianza borran por igual el juicio del planificador; solo una regla mantiene a raya cualquiera de las dos direcciones.

El segundo modo de fallo es la edición que nadie registra. La edición se hace, el día se salva y la razón se evapora. Este parece inofensivo y es el más corrosivo de los dos. Nadie puede reconstruir por qué el cronograma se ve como se ve. A quien hizo la edición no se le puede preguntar, porque cambió de turno o de planta. Las consecuencias de cambio de mover un trabajo son invisibles para el siguiente planificador, porque el cronograma solo muestra el resultado final. Y la planta no puede aprender, porque no hay registro de qué se intentó y cuánto costó en tiempo.

La literatura de programación ya resolvió la pregunta que esto plantea, al menos para los cambios disparados por software. La investigación sobre reprogramación distingue estrategias de políticas: una política es la regla que decide cuándo se toca el cronograma. Las opciones canónicas son periódica, es decir, el cronograma se reconstruye a una cadencia fija; impulsada por eventos, es decir, una perturbación definida dispara la reconstrucción; e híbrida, una combinación de ambas. La cuestión es que «cuándo tocamos el cronograma» se trata como una decisión tomada de antemano, no como algo improvisado en el momento. Esta entrada simplemente extiende la misma disciplina a las ediciones que un humano hace a mano.

Qué significa «respaldada por una política» en la práctica

Una edición respaldada por una política responde tres preguntas en una sola página.

¿Cuándo se permite una edición manual? La planta nombra sus disparadores. Una entrega de material que no llega. Un aviso de cancelación de un cliente. Una máquina que se ha caído. Los disparadores pueden tomar las formas de la reprogramación: una regla impulsada por eventos («la secuencia solo puede cambiarse a mano cuando una entrega llega tarde») o una híbrida («reoptimizamos todos los viernes y solo editamos a mano dentro de la semana»). Lo que importa es que la planta decida de antemano qué perturbaciones merecen tocar el cronograma.

¿Quién puede hacerla? La planta nombra los roles. La respuesta puede ser una lista corta: el planificador, el líder de turno en su ausencia, el gerente de planta para los cambios que cruzan un límite de turno. El sentido de escribir la lista no es montar una burocracia de permisos. El día de un planificador ya está lleno de solicitudes externas; una política que canalice cada cambio por una aprobación paralizaría el rol de coordinación. La lista existe para que una edición sea atribuible a un rol con la autoridad para hacerla.

¿Qué se registra? Aquí es donde la herramienta se gana el sueldo. Cuando el planificador edita el cronograma, la herramienta debe hacer la edición visible y acotada: solo se tocan las filas que el planificador cambió, sobre la edición corre la misma validación que corrió sobre la construcción original, y el cronograma se marca para que cualquiera que lo abra sepa que lo ajustó una persona y no lo produjo un algoritmo. La herramienta registra qué cambió. La política registra por qué, en el lenguaje de la propia planta, junto a la razón que el planificador ya conoce.

Existe una versión de esto que ocurre antes de la edición en lugar de después. Una herramienta de programación con un modo Semi-Auto permite a la planta fijar la secuencia de producción y deja que el software optimice las asignaciones de máquinas dentro de esa secuencia fija. Esa es una política por adelantado: la planta decide la regla y el software ejecuta dentro de ella. La edición manual es la excepción del momento, y es exactamente el caso en el que la política escrita importa más.

El efecto dominó del cambio

Esta es la razón operativa por la que importa el registro. El tiempo que tarda una máquina en cambiar de producto depende de qué producto corrió antes de cuál. El tiempo de cambio depende de la secuencia: adelantar un trabajo a otro cambia el tiempo de cambio en el límite de ambos lados, y esos cambios se propagan por el resto del cronograma. La literatura de revisión sobre problemas de programación con tiempos de preparación es amplia precisamente porque este efecto es real.

Un planificador que mueve un trabajo conoce la razón inmediata, pero el efecto dominó del cambio puede extenderse mucho más allá de la fila que editó. Una edición respaldada por una política da cuenta de esto porque se hace a sabiendas, con la secuencia visible, y porque la razón queda registrada para que el efecto pueda cuestionarse después. Una edición no registrada no puede cuestionarse. Quien la hizo puede haber tenido una buena razón; la planta nunca podrá sopesar esa razón contra el tiempo que la edición costó realmente.

De la heroicidad al hábito

La planta madura no prohíbe las ediciones manuales. Las gobierna. Una regla documentada dice cuándo se permite una edición y quién puede hacerla. La herramienta hace la edición visible y acotada, registra qué cambió y marca el cronograma como ajustado a mano. La planta anota el porqué. Tres cosas, ninguna burocracia, y juntas convierten la heroicidad del planificador en un hábito repetible y auditable.

La edición nunca fue el problema. La política ausente lo era. El trabajo de una herramienta de programación es hacer fácil la edición respaldada por una política y visible la que no se gobierna. El trabajo de la planta es escribir la regla. Ambos lados son simples. La disciplina es la parte difícil, y empieza con la próxima edición de noventa segundos.