Por qué no se puede confiar en los resultados de ingeniería, incluso cuando los datos son correctos

No es un problema de datos. Es un problema de procesos

Cuando todo parece correcto... pero nada parece fiable

El diseño está hecho. El modelo es preciso, el dibujo está completo y Vault confirma la revisión correcta y el estado del ciclo de vida. En todos los aspectos visibles, los datos están en orden.

Entonces, ¿por qué el equipo de producción sigue pidiendo al ingeniero que vuelva a comprobar el PDF?

¿Por qué fabricación solicita una nueva exportación STEP aunque ya exista una? ¿Por qué Compras compara la exportación de la lista de materiales con el plano antes de hacer un pedido?

Es evidente que nada está mal. Pero tampoco hay nada totalmente fiable.

La verdadera cuestión no es si el archivo existe. Es si alguien confía en que el archivo sea la última versión.

Esa brecha, entre los datos que existen y los datos en los que se confía, es uno de los retos más persistentes en los flujos de trabajo de ingeniería. Y rara vez empieza en el propio diseño.

Es un problema de proceso, no de Vault

Autodesk Vault hace exactamente aquello para lo que ha sido diseñado. Estructura los datos de ingeniería, impone el versionado, gestiona los estados del ciclo de vida y mantiene la coherencia de la información de diseño.

El reto comienza una capa por encima de eso. Se encuentra en el flujo de trabajo que los equipos crean en torno a Vault, concretamente en cómo se crean y preparan los entregables una vez finalizado el trabajo de diseño.

Vault gestiona el diseño. El proceso gestiona los resultados. A veces, estas dos cosas no hablan el mismo idioma.

Cuando la creación de resultados depende de pasos manuales, tiempos individuales o reglas incoherentes, la conexión entre el diseño y el producto final se debilita. Incluso cuando los datos de Vault son correctos, los archivos que se utilizan fuera de él pueden no reflejar ese mismo estado.

Siete fuentes de incoherencia en los resultados de los flujos de trabajo de ingeniería

Aquí es donde entra la variabilidad. Cada punto es pequeño por sí solo. Juntos, determinan la fiabilidad de los resultados.

1. El tiempo no está definido

Las salidas se crean en momentos diferentes según quién las genere. Un ingeniero exporta inmediatamente después de un cambio. Otro espera hasta la publicación. Un tercero sólo genera archivos cuando alguien se los pide.

Por lo tanto, el mismo diseño puede existir como múltiples salidas, cada una representando un punto diferente en el tiempo. Desde fuera, no hay forma clara de distinguirlos.

Cuando los resultados carecen de un contexto claro, la fecha de creación se convierte en la única pista sobre cuándo se generaron. La mayoría de los usuarios posteriores nunca lo comprueban.

2. El estado del ciclo de vida y los archivos de salida se distancian

Un diseño marcado como "Liberado" comunica un estado claro. Pero el archivo PDF o STEP asociado puede haberse generado antes, antes de que se aprobara la revisión final.

El ciclo de vida refleja el estado actual. El entregable refleja uno anterior. Ese desajuste es invisible para cualquiera que no conozca el historial completo de ese archivo.

3. Propiedad distribuida sin normas compartidas

A medida que los equipos crecen, la generación de resultados se distribuye. Cada ingeniero adopta un enfoque ligeramente diferente sobre cuándo y cómo se crean los archivos.

Las diferencias son pequeñas pero acumulativas.

• Cuándo exportar (¿antes o después de la publicación?)

• Qué formatos incluir (¿sólo PDF? ¿STEP? ¿DXF?)

• Cómo nombrar el archivo (¿con revisión? ¿con fecha? ¿con ambos?)

• Dónde colocarlo (¿bóveda? ¿carpeta compartida? ¿enviado por correo electrónico?)

Ninguna acción individual es incorrecta. Pero colectivamente, producen salidas que son incoherentes desde el exterior.

4. La denominación y los metadatos se aplican de forma incoherente

Algunos resultados llevan referencias de revisión completas y metadatos de elementos en el nombre de archivo. Otros se basan en la estructura de carpetas o en prácticas informales de nomenclatura para comunicar el contexto. Algunos archivos están repletos de información, mientras que otros son meras exportaciones que requieren conocimientos previos para su interpretación.

Seis meses después, alguien abre un archivo y no tiene forma fiable de saber qué estado del diseño representa.

5. Los resultados pasan por demasiados pasos manuales

Los resultados de ingeniería a menudo necesitan llegar a lugares fuera de Vault. Un PDF puede compartirse con un revisor, un archivo STEP puede enviarse a un proveedor y un DXF puede estar disponible para la fabricación.

Este movimiento forma parte del flujo de trabajo.

El riesgo comienza cuando cada paso depende de una acción manual. Alguien exporta el archivo, lo copia, le cambia el nombre o lo envía en función de una solicitud.

Cada paso puede ser correcto. Pero cada paso manual introduce variaciones.

El archivo puede generarse en el momento equivocado del ciclo de vida. Puede colocarse en una ubicación pero no en otra. Puede que se actualice en Vault pero no se actualice donde otros esperan encontrarlo.

El problema no es la distribución. Es la falta de una forma controlada de generar y entregar esos resultados.

6. Los desencadenantes de salida no están definidos

En muchos flujos de trabajo, no hay un único evento que desencadene sistemáticamente la creación de salidas. Los archivos se generan cuando alguien se acuerda, cuando se sigue una lista de comprobación o cuando llega una solicitud.

Cuando la creación de salidas depende de una iniciativa individual en lugar de un desencadenante de flujo de trabajo definido, las salidas se generan de forma incoherente. Algunos diseños tienen paquetes de archivos completos y actualizados. Otros los tienen parciales u obsoletos.

7. Las exportaciones de listas de materiales y las salidas de archivos no están alineadas

Las salidas de archivos y las exportaciones de datos estructurados, como los datos de la lista de materiales, los atributos de los artículos y las relaciones de ensamblaje, se generan con frecuencia de forma independiente en momentos diferentes, en formatos diferentes y por personas diferentes.

El archivo STEP puede reflejar la revisión B. La exportación de la lista de materiales puede haberse generado durante la revisión A. Ambos parecen ser "lo último" en sus respectivos sistemas. No se puede confiar plenamente en ninguno de los dos si se utilizan juntos.

Cuando las pequeñas variaciones se convierten en un problema sistémico

Cada uno de estos factores es manejable por sí solo. Pero rara vez aparecen aislados.

Cuando los plazos no están definidos, la propiedad está distribuida y los resultados dependen de pasos manuales, el resultado no es una incoherencia ocasional. Se trata de un flujo de trabajo en el que es difícil mantener la previsibilidad.

El diseño permanece controlado. Los resultados no reflejan sistemáticamente ese control.

El objetivo no es un sistema perfectamente configurado. El objetivo no es un sistema perfectamente configurado, sino un flujo de trabajo que permita utilizar un archivo sin vacilar.

El coste real:
La verificación se convierte en la norma

Esto no suele manifestarse como un fallo visible. Los archivos no se equivocan constantemente. Las entregas no se rechazan con regularidad.

En cambio, el coste aparece como una verificación repetida.

• Se pide a los ingenieros que confirmen si un archivo está actualizado.

• Fabricación solicita una nueva exportación en lugar de utilizar la disponible.

• Compras compara los datos de la lista de materiales con los planos antes de actuar.

• Los revisores comprueban las marcas de tiempo antes de confiar en un archivo.

Nada de esto se registra como reproceso. Pero añade esfuerzo al proceso.

La confianza se sustituye por la verificación, y ésta pasa a formar parte del flujo de trabajo.

Cómo son realmente los resultados coherentes

Los resultados coherentes no se definen por dónde se almacenan, sino por cómo se crean y entregan.

• Se generan siempre en el mismo punto del ciclo de vida.

• Reflejan el estado aprobado de la última versión del diseño.

• Siguen normas coherentes de nomenclatura y metadatos.

• Se entregan en el lugar adecuado sin intervención manual.

Cuando se cumplen estas condiciones, los equipos posteriores ya no tienen que cuestionar los archivos que reciben.

La verificación no desaparece, pero se convierte en la excepción y no en la norma.

A dónde apunta esto para los equipos de ingeniería

El camino hacia unos resultados coherentes no consiste en restringir el destino de los archivos. Se trata de definir cómo se crean y entregan.

• ¿En qué momento del ciclo de vida deben generarse los resultados?

• ¿Qué formatos deben incluirse?

• ¿Cómo deben denominarse?

• ¿Dónde deben entregarse?

Cuando estas decisiones se codifican en un flujo de trabajo automatizado y fiable, los resultados son predecibles.

Y cuando los resultados son predecibles, pueden utilizarse sin vacilación.

Esa fiabilidad es la que permite todo lo que viene después, desde el traspaso de la fabricación hasta la integración y automatización de ERP.