Está trabajando en un ensamblaje en Vault.
Las restricciones se están resolviendo, las cotas se están ajustando y está iterando sobre una decisión de diseño que aún no está del todo clara. Está probando variaciones, comprobando el ajuste y moviéndose entre componentes para comprender cómo se comporta todo junto.
Está en ello. Entonces recuerdasque hay que compartir eldibujo.
Se necesita un PDF antes de la publicación. Se necesita un archivo STEP para un proveedor. Alguien está esperando una vista previa rápida.
Usted se detiene. Pasa del ensamblaje al dibujo, activa una exportación y comprueba la ubicación de salida, el nombre del archivo y el formato.
Luego vuelve al diseño. Y el momento desaparece. La última decisión en la que estabas trabajando ya no está delante de ti. Tienes que reconstruirla.
El trabajo de diseño no suele detenerse porque el diseño sea difícil. Se detiene porque hay algo más que requiere atención.
Autodesk Vault proporciona estructura, control de versiones y un sistema central para gestionar los datos de ingeniería.
Sin embargo, en muchos entornos, los flujos de trabajo creados en torno a él van más allá del diseño y se convierten en una serie de pasos adicionales.
Antes de que nada pueda avanzar, es necesario que existan salidas.
Un ingeniero finaliza un cambio en un ensamblaje, se detiene para abrir o actualizar el dibujo, exporta un PDF para su revisión, genera un STEP o DXF para su uso posterior y se asegura de que los archivos siguen las normas internas de nomenclatura y almacenamiento.
Se trata de tareas manuales dentro de flujos de trabajo de ingeniería gestionados en Autodesk Vault.
Requieren salir del contexto de diseño, navegar por cuadros de diálogo, comprobar la configuración y verificar los resultados. Una vez hecho esto, el ingeniero vuelve al modelo y continúa.
Este patrón se repite varias veces durante una misma tarea.
Cada interrupción rompe la continuidad del proceso de diseño.
Cuando el ingeniero vuelve al modelo, el sistema sigue mostrando la misma geometría, pero el razonamiento que subyace al último cambio ya no está activo.
Hace una pausa para volver a evaluar las restricciones que estaban a medio ajustar, comprobar qué cotas ya estaban validadas y recordar por qué se modificó un componente.
No se trata de reelaborar, sino de reconstruir.
El sistema conserva los datos, pero no el contexto de la toma de decisiones. El ingeniero tiene que reconstruir ese contexto manualmente.
El modelo sigue ahí. Pero no el pensamiento que lo sustenta.
A lo largo de un día, esto sucede repetidamente, y las interrupciones del flujo de trabajo CAD empiezan a afectar a la productividad de la ingeniería de una forma difícil de medir, pero fácil de experimentar.
A medida que se acumulan estas interrupciones, la estructura del trabajo empieza a cambiar.
Un ingeniero empieza a hacer un seguimiento de lo que queda por hacer fuera del propio diseño. Todavía hay que exportar un archivo STEP. Hay que actualizar el PDF tras el siguiente cambio. Todavía hay que cambiar el nombre de algunos archivos antes de publicarlos.
Estas tareas existen junto al trabajo de diseño, no dentro de él.
El ingeniero se mueve entre la resolución de un problema de diseño y la gestión de una lista creciente de acciones necesarias. Dado que el sistema no impone cuándo se realizan estas tareas, se gestionan entre los pasos de diseño, siempre que haya un momento para hacerlo.
El trabajo continúa, pero no en una única dirección.
Cada paso individual está justificado.
Exportar un PDF es necesario. Proporcionar un archivo STEP es necesario. Organizar las salidas forma parte del proceso.
Desde la perspectiva del sistema, todo se comporta como se espera.
El problema sólo se hace visible cuando estas acciones se experimentan juntas. Aparecen en diferentes momentos, provocadas por diferentes necesidades, a menudo por diferentes personas.
Ningún paso crea fricción por sí solo. Pero juntos, fragmentan el proceso de diseño de una forma difícil de atribuir a una única causa.
Los ingenieros de CAD pierden tiempo en los flujos de trabajo en torno a Autodesk Vault no porque el diseño sea complejo, sino porque estos flujos de trabajo requieren frecuentes pasos manuales como exportar archivos, preparar entregables y cambiar de contexto.
Cuando el enfoque se interrumpe repetidamente, la forma en que se toman las decisiones empieza a cambiar.
Un ingeniero prueba menos variaciones, deja de iterar una vez que una solución funciona y confía más a menudo en enfoques conocidos en lugar de explorar alternativas. No por falta de capacidad, sino porque mantener el contexto requiere esfuerzo.
Cada iteración adicional aumenta la probabilidad de volver a ser interrumpido.
No se pierden horas de golpe. Se pierden minutos, una y otra vez, hasta que la atención se fragmenta.
El sistema admite resultados correctos, pero el flujo de trabajo circundante influye en la cantidad de exploración que se realiza antes de alcanzarlos.
Las tareas en torno al diseño no son el problema. Son necesarias para los procesos posteriores.
El problema es cuando se realizan en el mismo momento en que el ingeniero está resolviendo un problema de diseño.
En muchos flujos de trabajo de ingeniería creados en torno a Autodesk Vault, la generación de resultados y la actividad de diseño están estrechamente vinculadas. El ingeniero diseña, prepara inmediatamente los resultados y vuelve al diseño.
Esto crea una dependencia entre dos tipos diferentes de trabajo: la resolución de problemas y la preparación de resultados.
Si se separan, el comportamiento cambia. El diseño continúa sin interrupción, mientras que las salidas se generan independientemente del momento del diseño. El ingeniero ya no tiene que decidir cuándo cambiar.
La reducción del trabajo manual en los flujos de trabajo conectados a Autodesk Vault empieza por separar estas responsabilidades.
Las interrupciones no sólo desconcentran. También introducen variabilidad en cómo se crean los resultados.
Los archivos se generan en diferentes momentos, con diferentes configuraciones y, a veces, con diferentes suposiciones. Con el tiempo, los resultados no siempre son coherentes ni fiables.
Aquí es donde comienza el siguiente reto: por qué los resultados creados manualmente suelen ser incoherentes y difíciles de confiar.