.svg)
Lo que la gestión de cambios de ingeniería debe mantener alineado
Cada cambio de ingeniería produce una respuesta autorizada a una pregunta concreta: qué revisión de esta pieza es válida, a partir de qué fecha y en qué centros. Tres sistemas necesitan esa respuesta. El PLM contiene el registro de ingeniería. El ERP contiene el registro de compras y costes. El MES contiene las instrucciones de trabajo que ejecuta la planta.
Cuando esos tres sistemas discrepan, rara vez es visible. Cada sistema informa de su propia revisión como actual y cada uno es internamente coherente. Nada genera un error. La discrepancia surge en la inspección, en una queja del cliente o durante una auditoría, semanas o meses después de la aprobación.
Por eso la gestión de cambios de ingeniería se mide mal. Los equipos realizan un seguimiento de los tiempos del ciclo de órdenes de cambio de ingeniería, lo que les indica cuánto tiempo llevó la aprobación. No les dice si el cambio aprobado está vigente en todas partes donde debería estarlo. Un cambio que obtiene la aprobación en tres días y llega al MES en tres semanas sigue enviando la pieza incorrecta.
Las cinco etapas del proceso de gestión de cambios de ingeniería
La disciplina se divide en cinco etapas, y la terminología es importante porque cada una produce un artefacto diferente.
- Solicitud: un ingeniero de calidad plantea una solicitud de cambio de ingeniería (ECR) describiendo el problema y la solución propuesta.
- Evaluación: Ingeniería, calidad y compras establecen qué afecta el cambio, qué ensamblajes, qué proveedores y qué órdenes de trabajo abiertas.
- Aprobación: el comité de cambios autoriza la solicitud, que se convierte en una orden de cambio de ingeniería (ECO), el instrumento que autoriza el cambio.
- Efectividad: Los cambios están fechados, por lo que cada sistema sabe a partir de qué número de serie, lote o fecha se aplica la nueva revisión.
- Propagación: Las revisiones aprobadas y su fecha de entrada en vigor llegan a todos los sistemas y socios que deben aplicarlas.
El control de cambios de ingeniería es el marco que rige estos cinco aspectos: quién puede aprobar qué y qué pruebas se conservan. Las cuatro primeras etapas ocurren dentro de un mismo sistema, generalmente el PLM. La quinta cruza los límites del sistema, y es precisamente por eso que es la etapa donde se producen los fallos.
Por qué los cambios aprobados siguen llegando tarde a planta
La propagación falla de cuatro formas reconocibles, y ninguna de ellas parece un fallo en el momento en que ocurre.
La reintroducción manual de datos es la más común. Un ingeniero envía la nueva revisión por correo electrónico a planificación, alguien la escribe en el ERP y la transcripción es correcta hasta el día en que deja de serlo.
Las ventanas de procesamiento por lotes pierden la fecha de entrada en vigor. Una sincronización nocturna transfiere el número de revisión pero omite la fecha en que se vuelve válida, por lo que el ERP trata el cambio como efectivo de inmediato, mientras que el MES continúa con la instrucción anterior hasta su próxima actualización.
La conversión de estructuras introduce desviaciones silenciosas. La lista de materiales de ingeniería en el PLM no tiene la misma forma que la lista de materiales de fabricación que necesita el ERP. Cuando esa conversión se realiza mediante scripts en lugar de estar gobernada, un componente sustituido puede terminar en el ensamblaje incorrecto. Esta es la misma brecha que rompe el hilo digital en un sentido más amplio.
La notificación a proveedores sigue siendo informal. Las revisiones se envían como archivos adjuntos por correo electrónico y el proveedor no tiene una forma fiable de saber si el plano que tiene es el actual.
Las cuatro comparten una causa: una vez que un cambio sale del PLM, ningún sistema es responsable de él.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
