Propagación de cambios de ingeniería
Cómo debería moverse un cambio aprobado por ingeniería, compras, control de proyecto, construcción y puesta en marcha.
BoRo Studio · Parte del trabajo de BoRo sobre arquitectura operacional para la entrega de proyectos Solar + BESS.
Aprobar no es propagar
La mayoría de los procesos de cambio están diseñados hasta el momento de la aprobación. Hay un formulario, una revisión, una firma y un número de revisión. Lo que pasa después de la firma normalmente se supone, no se diseña.
Un cambio aprobado que no llegó a las funciones que tienen que actuar sobre él no cambió nada en terreno. Hasta que se propaga, el proyecto tiene dos realidades: la que aprobó ingeniería y la que todos los demás siguen ejecutando.
Qué necesita cada función de un cambio
Compras necesita saber qué órdenes abiertas y qué requisiciones aún no emitidas se ven afectadas, antes de la próxima emisión. Control de proyecto necesita la consecuencia en alcance y costo, para que el pronóstico deje de describir un proyecto que ya no existe.
Construcción necesita el plano vigente en el frente de trabajo y una declaración explícita de que el anterior quedó superado. Puesta en marcha necesita saber si cambian los procedimientos de prueba y los criterios de aceptación. Son cuatro informaciones distintas, con cuatro relojes distintos. Reenviar la misma notificación a todos no entrega ninguna.
Dónde suele detenerse la propagación
Rara vez se detiene en un límite entre sistemas. Se detiene en un límite de propiedad: el punto donde actuar sobre el cambio no es el trabajo definido de nadie. Típicamente compras y puesta en marcha no tienen un dueño nombrado para los cambios de ingeniería entrantes, así que esos traspasos dependen de que un jefe de proyecto se acuerde.
La segunda detención frecuente es la brecha entre que una revisión se emite y que una revisión está en uso. Control documental registra que la revisión C existe. No registra que la cuadrilla sigue con la revisión B en la mano.
Qué contiene una ruta de propagación diseñada
Una clasificación, para que un cambio que afecta a compras se enrute distinto de uno que no. Un receptor nombrado en cada función afectada. Un acuse que signifique algo específico: no que el mensaje se leyó, sino que la orden se revisó, el pronóstico se actualizó o el plano se reemplazó en el frente de trabajo.
También necesita un estado visible para el cambio mismo, desde aprobado hasta completamente absorbido, para que cualquiera pueda ver qué funciones siguen en la realidad anterior. Ese estado es lo que vuelve medible la latencia de coordinación.
Dónde ayudan los sistemas y dónde no
Una vez diseñada la ruta, hay partes que son buenas candidatas para un sistema: enrutar por clasificación, seguir los acuses, mostrar el estado de absorción por proyecto. Son las partes tediosas y repetitivas que hoy una persona hace de memoria.
Lo que un sistema no puede hacer es decidir quién es dueño del cambio en compras, o qué cuenta como absorbido en construcción. Esas son decisiones de modelo operativo. Automatizar una ruta que nadie acordó solo hace más rápido el desacuerdo.