ERP y Vault, conectados por un agente

Hay una frontera que atraviesa casi todas las empresas de manufactura que conozco, y casi ninguna la tiene en el organigrama. De un lado vive ingeniería, con sus archivos, revisiones y BOMs dentro de Autodesk Vault. Del otro vive el negocio, con sus items, órdenes y costos dentro del ERP. Y en medio, sosteniendo la operación con las dos manos, casi siempre hay una persona exportando a Excel, copiando y pegando.

La brecha que nadie presupuesta

Esa frontera cuesta dinero de formas que rara vez se miden. Números de parte que no coinciden entre los dos sistemas. Revisiones que ingeniería liberó hace semanas y que el ERP nunca conoció. BOMs que viajan por correo como adjuntos, envejeciendo desde el momento en que se exportan. Cada una de esas inconsistencias termina en una llamada, una reunión o un pedido fabricado con la revisión equivocada.

En campo he observado que un ingeniero puede gastar entre 3 y 8 horas semanales en operaciones repetitivas de PDM. Una parte importante de ese tiempo es exactamente esto: mover información de un sistema a otro para que el negocio y la ingeniería hablen el mismo idioma. No es un dato instrumentado, es observación directa de proyectos reales, pero cualquiera que trabaje en manufactura reconoce la escena.

Un agente en la frontera

Cuando construimos VaultPilot junto a Avant Leap, decidimos que el ERP no podía ser un anexo. Es una de las 9 categorías de herramientas del agente, con el mismo peso que la búsqueda, los ciclos de vida, las propiedades, las operaciones masivas, los BOMs, los ECOs, los jobs y los reportes: 28 herramientas en total, todas invocables desde lenguaje natural.

La consecuencia práctica es simple de describir: la conversación en la que trabajas tu PDM es la misma en la que tocas la frontera con el negocio. Sin cambiar de sistema, sin exportaciones intermedias, sin que la información envejezca en un adjunto de correo.

Y aquí viene la parte que me importa más que la comodidad: las reglas no cambian en la frontera. Las operaciones que tocan datos pasan por las mismas compuertas que el resto del agente. Dry-run con confirmación antes de escribir: primero ves exactamente qué va a cambiar, después autorizas. Validación contra el esquema real, para que el agente no invente propiedades que no existen. Verificación de cada escritura con relectura posterior, porque un éxito reportado no es un éxito comprobado. Y todo corre con las credenciales del propio usuario, no con una cuenta de administrador escondida en un servidor.

La regla y la excepción

En mi sesión de Autodesk University lo resumí en una frase: un script automatiza la regla, un agente maneja la excepción. La frontera entre ingeniería y negocio está hecha de excepciones: el item que existe en un sistema y no en el otro, la revisión que se adelantó al proceso, el BOM que cambió después de la última exportación. Por eso los conectores rígidos entre PDM y ERP suelen quedarse cortos: automatizan el caso feliz y dejan las excepciones, que son justo lo que duele, en manos del copiador humano.

Un agente con compuertas invierte esa ecuación: maneja la excepción conversando contigo, y te deja a ti la decisión final sobre cada escritura. La autonomía hace el trabajo. La autorización sigue siendo tuya.