Autodesk Vault: una versión, muchos sistemas desconectados

Cuando el departamento de ingeniería publica un diseño en Autodesk Vault, se bloquea la revisión, se finaliza la lista de materiales y se aprueban los dibujos. Desde el punto de vista de ingeniería, el trabajo está terminado. Pero para todos los equipos posteriores, la espera acaba de empezar y la mayoría de ellos no tienen forma fiable de saber si los datos del diseño son los últimos.

Compras espera los datos de los artículos para hacer los pedidos. Fabricación necesita la revisión correcta antes de comprometerse con una tirada de producción. Un sistema PLM necesita la estructura de producto actualizada para gestionar la configuración y el ciclo de vida. Cada equipo depende de la misma versión. Cada uno la recibe a través de un canal diferente, en un plazo diferente, sin una señal compartida de que ingeniería ha cerrado un cambio.

Este es el problema de los sistemas desconectados. Y es más común, y más costoso, de lo que la mayoría de las organizaciones reconocen.

La brecha que nadie diseñó

Nadie se propone construir un flujo de trabajo desconectado. Las empresas invierten en Vault para la gestión de datos de ingeniería, ERP para la planificación de la producción, el aprovisionamiento y el inventario, PLM para el control del ciclo de vida del producto. Cada sistema es la herramienta adecuada para su propósito. El problema es que cuando un cambio de ingeniería se cierra en Vault y avanza una revisión, ese evento se captura y se gobierna dentro de Vault. Nada indica automáticamente a ERP que actualice sus registros de artículos. Nada indica al sistema PLM que la estructura del producto ha cambiado.

La brecha entre sistemas no es un fallo de ninguna herramienta individual. Es una consecuencia estructural de cómo se construyen los ecosistemas de software empresarial. Y salvarla manualmente, que es lo que acaban haciendo la mayoría de las organizaciones, crea una serie de riesgos que se agravan silenciosamente con el tiempo.

Lo que ocurre en la práctica

Esto es lo que hace que este problema pase desapercibido: la conexión manual parece un trabajo normal.

Un ingeniero exporta una lista de materiales y la envía a aprovisionamiento. Un administrador de PLM concilia los registros de artículos tras el cierre de una ECO. Ninguno de estos pasos aparece en un registro de riesgos. Se trata simplemente de cómo se hacen las cosas. El riesgo aparece cuando los cambios se acumulan más rápido de lo que el proceso manual puede seguir.

Compras realiza un pedido basándose en una lista de materiales actualizada hace tres semanas, antes de que se cerraran dos OCE y se revisara la lista de componentes. Fabricación ejecuta un ensamblaje en función de un plano que ingeniería sustituyó en la revisión del diseño del mes pasado. En ambos casos, el equipo de fabricación no ha sido negligente. Confiaban en el sistema en el que trabajan, sin saber que la fuente había cambiado.

Cuando una información incorrecta llega a las operaciones posteriores, el coste es concreto: repetición del trabajo, aceleración de los pedidos de material, paradas de producción. En sectores regulados como el aeroespacial, los dispositivos médicos o la defensa, las consecuencias van más allá. Construir o fabricar con una revisión anulada no es sólo un problema operativo. Afecta a la trazabilidad, las pistas de auditoría y la certificación de productos.

La capa de compensación de la que nadie habla

Esto es lo que hace que este problema sea difícil de abordar: la mayor parte del coste es invisible porque está integrado en la forma de trabajar de las personas.

Los equipos de ingeniería realizan llamadas de verificación que no deberían requerir confirmación manual. El departamento de compras crea plazos de entrega para tener en cuenta la posibilidad de que lo que han recibido no esté actualizado. Fabricación añade puntos de comprobación antes de iniciar la producción. Estos hábitos parecen diligencia. En realidad, son una compensación por un flujo de trabajo que no está haciendo lo que debería.

Y una vez que los equipos se han quemado suficientes veces, dejan de confiar por completo en la ruta automatizada. Los puntos de control manuales se convierten en elementos permanentes. La organización se vuelve más lenta y más dependiente del esfuerzo individual de lo que sugerirían sus inversiones en sistemas.

También hay un coste cultural. Cuando los equipos posteriores no pueden confiar en los datos que reciben, dejan de confiar en el proceso. Se evita la automatización. Las aprobaciones se retrasan. Las decisiones se retrasan hasta que alguien puede confirmarlas a mano. La inversión en sistemas conectados produce sistemas conectados en los que nadie confía plenamente.

La pregunta correcta

La mayoría de las organizaciones miden si se ha completado una transferencia de datos. ¿Llegó la lista de materiales al ERP? ¿Se actualizó el registro PLM? Se trata de puntos de control necesarios, pero plantean la pregunta equivocada.

Conectar dos sistemas es un problema resuelto. Garantizar que un evento de lanzamiento en Vault se propague con precisión a ERP, PLM y MES, sin intervención manual y sin ambigüedad sobre lo que es actual, es un problema más difícil y con mayores consecuencias. No sólo requiere conectividad técnica, sino una lógica de gobierno: qué eventos de Vault deben desencadenar qué acciones, en qué sistemas y para qué equipos.

La verdadera cuestión es la siguiente: cuando ingeniería publica un cambio en Vault, ¿lo reflejan todos los sistemas que dependen de ese cambio, de forma fiable, sin que alguien gestione manualmente la transferencia? Esta pregunta desplaza el marco de la integración a la fiabilidad.

Las organizaciones que han resuelto este problema tienen algo que sus homólogas no tienen: confianza. Compras confía en los datos que recibe. La fabricación no necesita verificar antes de ejecutar. Esa confianza no es sólo una mejora operativa. Cambia la rapidez con la que la empresa puede responder a los cambios, la cantidad de tiempo de ingeniería que se dedica a la coordinación frente al diseño y la fiabilidad con la que se pueden cumplir los compromisos adquiridos con los clientes y las partes interesadas del proyecto.

Por dónde empezar

Las organizaciones que más avanzan en este problema no suelen empezar por la tecnología, sino por un mapa claro de lo que tienen en realidad. ¿Qué sistemas reciben datos de Vault? ¿A través de qué mecanismo? ¿A quién pertenece cada transferencia? ¿Qué ocurre cuando los ingenieros lanzan un cambio?

Ese mapa suele revelar un pequeño número de puntos de transferencia de alto riesgo en los que los procesos manuales tienen más peso. Un ejemplo común: un ECO se cierra en Vault un viernes por la tarde, y compras no se entera hasta que un ingeniero envía un correo electrónico a alguien el lunes. Ese desfase de dos días, multiplicado en cada ciclo de cambio, es donde los compromisos de programación se erosionan silenciosamente.

Abordar esos puntos en primer lugar, con una propagación fiable y basada en eventos en lugar de exportaciones programadas o pasos manuales, produce la mejora visible más rápida.

El objetivo no es eliminar el juicio humano del proceso. Los cambios de ingeniería requieren un contexto y una revisión que ninguna automatización puede sustituir. El objetivo es eliminar el trabajo manual de mover datos entre sistemas, para que las personas encargadas de cada proceso puedan centrarse en las decisiones que realmente las requieren.

Una versión debería significar una fuente de verdad, en todos los sistemas y en todos los equipos que dependen de ella. La mayoría de las organizaciones aún no lo han conseguido. Las que lo consiguen no sólo son más eficientes. Toman mejores decisiones, más rápido, con menos personas que se pasan el día confirmando lo que ya debería saberse.