Blog de coolOrange

La integración con un sistema ERP no debería obligarte a replantearte cómo se identifican las materias primas en Autodesk Vault

Escrito por Akash Agilan | 24 sept 2026, 7:36:42

Cuando un equipo de ingeniería inicia un proyecto de integración con un ERP, la conversación suele centrarse en lo que hay que desarrollar: cómo se transfieren las listas de materiales, cómo se crean los artículos, cómo se asignan los estados del ciclo de vida a los códigos de estado del ERP. Lo que recibe menos atención es la suposición implícita en toda ruta de integración estándar: que el entorno de Vault ya está estructurado tal y como espera la integración.

En lo que respecta a la gestión de materias primas, esa suposición tiene consecuencias reales. Si un equipo de ingeniería ya cuenta con un proceso establecido para identificar las materias primas en Vault y dicho proceso no se ajusta a lo que la capa de integración está diseñada para leer, la cuestión pasa a ser si hay que reconstruir el flujo de trabajo existente o adaptar la integración para que funcione con él. La respuesta es más importante de lo que podría parecer a primera vista.

 

Cómo se transfieren normalmente los datos de las materias primas de Vault al ERP

En una integración estándar de Vault a ERP, la gestión de las materias primas sigue una ruta definida. Los archivos que representan materias primas se marcan mediante propiedades asignadas en Inventor. Durante la transferencia de la lista de materiales (BOM) y de los artículos, la integración lee esas propiedades de Vault asignadas y las utiliza para completar los detalles de las materias primas en el artículo correspondiente del ERP.

Cuando el entorno de Vault sigue esta estructura, el proceso resulta fiable y coherente. Las propiedades correctas están presentes en los archivos adecuados, la integración las lee durante la transferencia y el artículo del ERP recibe datos precisos sobre las materias primas sin que el equipo de ingeniería tenga que intervenir manualmente en cada paso.

 

Cuando un flujo de trabajo existente toma un camino diferente

Un cliente llegó a este proyecto de integración con un proceso de identificación de materias primas ya establecido. Una propiedad de Vault marcaba los archivos como materias primas, y el equipo de ingeniería mantenía una lista aprobada de descripciones de materias primas y números de stock en un archivo CSV almacenado en Vault. Ese CSV era la fuente de verdad operativa: recogía qué materias primas había decidido el equipo que eran válidas para el trabajo de diseño actual, y el marcado de propiedades en Vault se basaba en él.

El equipo había elaborado esta lista por motivos específicos de su entorno. El ERP contenía muchas más referencias de stock de las que el equipo de diseño quería mostrar a los diseñadores: materiales heredados, registros históricos de compras y opciones que pertenecían al aprovisionamiento de producción, en lugar de a decisiones de ingeniería activas. Consultar el ERP directamente cada vez que se buscaba un material habría devuelto todas esas opciones y habría introducido una dependencia en tiempo real de la conexión con el ERP durante el trabajo de diseño. Al mantener en su lugar una lista más breve y seleccionada en Vault, el equipo centró la selección de materiales en lo que estaba realmente aprobado y era relevante, y la responsabilidad de esa lista recayó en el equipo de ingeniería, en lugar de en compras o producción. El archivo CSV ya se había registrado en Vault y se actualizaba allí como parte del proceso de trabajo del equipo.

El flujo de trabajo llevaba en marcha el tiempo suficiente como para que reconstruirlo en torno a la estructura de integración estándar no fuera un punto de partida práctico. La cuestión era si powerGate, la solución de integración de Vault con el ERP de coolOrange, podría funcionar con el enfoque basado en el archivo CSV que el equipo ya estaba utilizando, en lugar de obligarles a adoptar la estructura de propiedades mapeada por Inventor que exige la vía estándar.

 

Adaptar la integración al proceso ya existente

En lugar de pedir al cliente que cambiara la forma en que se identificaban las materias primas en Vault, se configuró powerGate para que leyera el archivo CSV durante la transferencia de la lista de materiales (BOM) y de los artículos. En lugar de consultar los detalles de las materias primas a partir de las propiedades asignadas de Inventor, la integración lee el CSV almacenado en Vault, localiza la fila correspondiente basándose en la descripción de la materia prima y transmite la información pertinente al artículo del ERP.

El resultado a nivel del ERP es el mismo que en una implementación estándar: el artículo recibe datos precisos sobre las materias primas durante la transferencia. Lo que ha cambiado es la fuente de la que lee la integración para obtener esos datos. El CSV asume el papel que desempeñan las propiedades asignadas de Inventor en la ruta estándar, y el resto del proceso de transferencia de la lista de materiales y de los artículos continúa sin modificaciones.

El formato del archivo es un detalle que el equipo resolvió en función de cómo lo lee la automatización: el CSV resultaba más fiable que Excel para el tipo de búsqueda que realiza powerGate durante la transferencia. Lo que importa desde el punto de vista operativo es que la integración ahora lee de forma coherente desde la misma fuente que el equipo de ingeniería ya mantiene, sin necesidad de que exista una estructura de datos paralela junto a ella.

 

Qué significa esto para los equipos que se enfrentan a una situación similar

Los proyectos de integración con ERP que dan por sentado un entorno de Vault «limpio» pueden generar más trastornos de los que la propia integración se supone que debe resolver. Cuando los equipos de ingeniería se enteran de que su proceso actual de gestión de materias primas debe reestructurarse antes de que pueda proseguir la integración, el alcance del proyecto se amplía antes de que se haya transferido ni una sola lista de materiales y la confianza en la integración decae antes de que haya tenido la oportunidad de demostrar su valor.

La alternativa es una capa de integración lo suficientemente flexible como para adaptarse al entorno de ingeniería tal y como está. Esto no es un argumento en contra del enfoque estándar: el flujo de trabajo predeterminado de powerGate para las materias primas, a través de propiedades de Inventor asignadas, es el punto de partida adecuado para la mayoría de las implementaciones y resulta más fácil de mantener a lo largo del tiempo. Pero esto significa que desviarse de ese camino no tiene por qué bloquear la integración ni obligar a los equipos a una reconstrucción que no esperaban cuando comenzó el proyecto.

Para los equipos de ingeniería cuyo proceso de identificación de materias primas en Vault ya está establecido y funciona, la integración puede adaptarse para leer a partir de él. El proceso que el equipo ha creado se mantiene tal cual. La integración con el ERP funciona en paralelo a él, en lugar de exigir su sustitución.