Comprender las preocupaciones en torno al paso de revisión de WIP a Liberado

La gestión de revisiones y aprobaciones en Autodesk Vault es como navegar por un complejo rompecabezas, especialmente cuando las piezas compartidas conectan varios ensamblajes. A primera vista, el proceso parece sencillo, pero ¿qué ocurre cuando se pasa de Work in Progress (WIP) a Released? Lo inesperado: archivos bloqueados, mensajes de error confusos y desajustes de datos que dejan a los equipos rascándose la cabeza.

En este artículo, nos sumergiremos en un escenario del mundo real para descubrir la causa raíz de estos desafíos y proporcionar información práctica para simplificar sus flujos de trabajo. Además, descubra cómo herramientas como powerJobs pueden añadir automatización a la mezcla, ayudándole a sortear incluso los obstáculos de aprobación más complicados.

El problema de los baches de revisión en el WIP → Transiciones liberadas

Una pregunta habitual durante nuestras consultas sobre flujos de trabajo es: «¿Por qué no puedo aprobar archivos sin problemas cuando se bachean revisiones en transiciones WIP → Liberado?». La respuesta radica en la forma en que Autodesk Vault gestiona las dependencias y garantiza la precisión de los datos, lo que puede dar lugar a archivos bloqueados y requisitos de actualización repetitivos cuando se utilizan piezas compartidas entre ensamblajes.

Para entender mejor el problema, veamos un escenario específico.

Escenario: Liberación de ensamblajes con piezas compartidas

Imagine que tiene dos ensamblados, sm01.iam y sm03.iam, que hacen referencia a partes compartidas, sm01.ipt y sm02.ipt. Aquí tienes un desglose paso a paso de las posibles trampas:

1. Configuración inicial:

   • sm01.iam  contiene sm01.ipt.

   • sm03.iam contiene sm01.ipt y sm02.ipt.

   • Todas las piezas y conjuntos se encuentran actualmente en la Revisión A (Rel.A) y en estado de Trabajo en curso.

2. Primer proceso de liberación:

   • El usuario libera sm01.iam junto con sm01.ipt.

   • Con esta acción, sm01.iam y sm01.ipt pasan al estado Liberado, y sm01.ipt avanza a la Revisión B (Rel.B).

3. Segunda liberación bloqueada:

   • Ahora, al intentar liberar sm03.iam, el sistema bloquea la liberación. Esto sucede porque sm03.iam todavía hace referencia a sm01.ipt - Rel.A (nunca liberado), que sigue en Work in Progress.

   • En Autodesk Vault, no puede liberar sm03.iam hasta que haga referencia a la última revisión de sm01.ipt (Rel.B).

   • Para actualizar la referencia es necesario abrir sm03.iam en Inventor, cambiar su dependencia a sm01.ipt - Rel.B, guardar y volver a comprobarlo en Vault.

Estado actual, después de arreglarlo en Inventor:

• sm01.iam Rel.B Publicado en

  • sm01.ipt Rel.B Publicado en

• sm03.iam Rel.B Publicado en

  • sm01.ipt Rel.B Publicado en

  • sm02.ipt Rel.B Publicado en

Otros cambios

Ahora, supongamos que el usuario cambia sm01.iam y sm03.iam de Liberado de nuevo a Trabajo en curso, realiza una modificación en sm01.ipt, libera sm01.iam de nuevo, creando la Revisión C (Rel.C).

El resultado será:

• sm01.iam Rel.C Publicado en

  • sm01.ipt Rel.C Publicado en

• sm03.iam Rel.B Trabajo en curso

  • sm01.ipt Rel.B Trabajo en curso

  • sm02.ipt Rel.A Trabajo en curso

Si el usuario lanza ahora sm03.iam, el resultado será incorrectamente el siguiente:

• sm03.iam Rel.C Publicado en

  • sm01.ipt Rel.B Publicado en

Este resultado no es lógico ni esperado, ya que sm03.iam debería haber hecho referencia a la última revisión de sm01.ipt (Rel.C), pero Vault en su lugar encontró y utilizó el sm01.ipt Rel.B previamente liberado.

Este problema no es un defecto de Vault, sino la consecuencia de un flujo de trabajo que entra en conflicto con las reglas lógicas de revisión de Vault. Al seguir este flujo de trabajo, los usuarios crean involuntariamente incoherencias que la lógica del sistema de Vault no está diseñada para resolver intuitivamente.

Observa cómo se materializa el escenario descrito.

Desafíos de tratar con el salto de revisión de WIP a Liberado en Autodesk Vault

1. Actualizaciones manuales frecuentes de las dependencias

   • La publicación de ensamblajes con piezas compartidas a menudo requiere actualizaciones manuales para garantizar que cada ensamblaje hace referencia a la última revisión de la pieza. En proyectos con muchos ensamblajes, esto puede ralentizar considerablemente los flujos de trabajo, creando un cuello de botella difícil de gestionar, especialmente en entornos de alta dependencia.

2. Inconsistencia de datos y problemas de control de versiones

   • Si se omiten las actualizaciones, los ensamblajes pueden hacer referencia a revisiones de piezas obsoletas, lo que da lugar a datos incoherentes en los ensamblajes. Por ejemplo, si un ensamblaje como sm03.iam se publica sin actualizar su referencia a la última revisión de la pieza, Vault puede extraer una versión anterior, lo que da lugar a información inexacta en la producción. Esta incoherencia complica el seguimiento de los cambios, la gestión de la documentación y el control preciso de las versiones en producción.

3. Mayor complejidad del flujo de trabajo

   • El flujo de trabajo de revisión predeterminado de Autodesk Vault espera que las revisiones se acumulen en la transición Liberado → WIP. El bumping de revisiones durante la transición WIP → Liberado provoca comportamientos contradictorios para los que Vault no está optimizado, lo que añade complejidad y aumenta el riesgo de errores en el proceso.

4. Problemas de rendimiento en entornos de grandes bóvedas

   • La automatización de las actualizaciones de dependencias (por ejemplo, a través de powerJobs) requiere que Vault escanee todos los ensamblajes que hacen referencia a una pieza recién lanzada. En grandes conjuntos de datos, este proceso puede ralentizar el rendimiento del sistema y aumentar la carga del servidor, lo que afecta a la productividad de los equipos que trabajan con plazos ajustados.

Automatizar las actualizaciones con powerJobs (si es absolutamente necesario)

powerJobs puede configurarse para buscar todos los ensamblajes que hacen referencia a una pieza recién lanzada y actualizar sus dependencias a la última revisión. Sin embargo, este método tiene sus limitaciones:

1. Intensidad de recursos: Cada vez que se libera una parte, powerJobs tendría que escanear toda la Bóveda en busca de dependencias, lo que puede llevar mucho tiempo, especialmente para grandes conjuntos de datos.

2. Posible impacto en el rendimiento: La ejecución de powerJobs en cada evento de liberación podría afectar al rendimiento del sistema, dependiendo del tamaño del almacén y del número de conjuntos afectados.

Por lo tanto, aunque powerJobs puede mitigar parte del trabajo manual, debe considerarse como un último recurso y no como una solución preferida. Para la mayoría de los clientes, recomendamos alinearse con los flujos de trabajo de Vault para evitar estos problemas.

Por qué Autodesk Vault favorece los baches de revisión en liberado → Transiciones WIP y mejores prácticas.

El flujo de trabajo predeterminado de Autodesk Vault está diseñado para eliminar revisiones durante la transición Liberado → WIP.

Este enfoque garantiza un control de versiones coherente entre ensamblajes y piezas con dependencias compartidas, reduciendo el riesgo de archivos bloqueados, actualizaciones manuales e incoherencias de datos.

Por el contrario, eliminar revisiones en la transición WIP → Liberado puede alterar la lógica de Vault, provocando conflictos y referencias desalineadas, especialmente cuando varios ensamblajes comparten piezas.

Recomendación: Evite saltar revisiones en la transición WIP → Liberado siempre que sea posible. Seguir el flujo de trabajo previsto por Vault mantiene la integridad de los datos y simplifica la gestión de dependencias. Si este flujo de trabajo alternativo es necesario, herramientas de automatización como powerJobs pueden ayudar a automatizar las actualizaciones, pero pueden afectar al rendimiento del sistema.