Digitalización de documentación técnica de ingeniería

Una versión es cada estado guardado de un archivo mientras se trabaja en él. Un proyectista puede generar diez versiones de un plano en una tarde. Una revisión, en cambio, es una edición formal del documento que se somete a comprobación y, si procede, se emite a terceros. Mezclar ambas cosas es el error más habitual al digitalizar: el sistema numera cada guardado como si fuera una revisión y la lista de emisiones se llena de ruido.

El convenio de revisiones debe estar configurado por proyecto, porque cada cliente o pliego puede imponer el suyo. Algunos usan letras para las emisiones preliminares y números a partir de la emisión para construcción; otros encadenan el número de revisión con un código de propósito («para información», «para aprobación», «para construcción»). El software debe aceptar el convenio sin obligar a renombrar archivos a mano.

El estado dice para qué sirve un documento en este momento. Lo importante no es la lista de estados, sino qué transiciones se permiten, quién puede provocarlas y qué ocurre automáticamente en cada una. Un modelo de partida razonable podría ser este:

1. En elaboración: solo el autor y su equipo lo ven y lo modifican. Se acumulan versiones de trabajo.
2. En comprobación: el autor lo bloquea y lo envía a revisión. Nadie puede editarlo; los revisores comentan sobre una copia.
3. Aprobado: se genera la revisión formal, se congela el archivo y se crea un PDF de referencia con los datos de la revisión en el cajetín.
4. Emitido: se ha enviado a destinatarios concretos mediante una transmisión registrada (quién, cuándo, con qué propósito).
5. Superado: existe una revisión posterior emitida. Sigue consultable, pero se muestra con una marca visible y no se ofrece por defecto.
6. Anulado: el documento deja de formar parte del proyecto. Se conserva con el motivo de la anulación.

En ingeniería la aprobación suele tener varios niveles: el autor elabora, otro técnico comprueba y un responsable aprueba. En documentos que afectan a varias disciplinas se añaden revisiones cruzadas: el plano de estructura lo revisa también quien diseña las instalaciones que lo atraviesan. Estos circuitos se pueden expresar como una matriz por tipo de documento y disciplina, configurable sin programar.

Un ejemplo concreto: un plano de armado de una losa pasa a comprobación. El sistema notifica al comprobador de estructuras y, por ser un documento con huecos de paso, también al responsable de instalaciones. Cada uno deja comentarios anclados a una zona del plano. El autor responde a cada comentario indicando si lo incorpora o por qué no. Solo cuando todos los comentarios están cerrados, el aprobador puede firmar. El registro final conserva los comentarios, las respuestas, las fechas y la identidad de cada firmante.

• Firma: basta con una acción autenticada y registrada; si se requiere firma electrónica cualificada, hay que integrarla con un prestador de servicios de confianza.
• Rechazo: devuelve el documento a elaboración con el motivo y conserva los comentarios para la siguiente ronda.
• Delegación: debe quedar registrada con fechas, para que una ausencia no bloquee el proyecto ni oculte quién firmó realmente.
• Plazos: avisos cuando un documento lleva demasiado tiempo en comprobación, porque ahí se acumulan los retrasos invisibles.

Los permisos de una carpeta compartida son demasiado gruesos para documentación técnica. Lo que cada persona puede hacer depende de tres cosas a la vez: el proyecto, su rol en él y el estado del documento. Un proyectista edita sus documentos en elaboración, pero solo lee los aprobados. Un subcontratista ve únicamente lo que se le ha emitido y nunca las versiones de trabajo. Un cliente consulta las emisiones para aprobación y deja sus comentarios, pero no accede a los cálculos internos.

Conviene añadir dos medidas sencillas: que las descargas de documentos emitidos lleven una marca con la revisión y la fecha de descarga, y que el sistema registre cada acceso a documentos sensibles. No impiden una fuga, pero hacen visible qué copia circula y facilitan comprobar si alguien trabajó con una revisión superada.

La búsqueda funciona si los documentos llevan metadatos fiables: proyecto, disciplina, tipo, zona o sistema, autor y revisión. Lo más robusto es que el código del documento se genere a partir de esos campos y no al revés, para que no haya dos fuentes de verdad. Si el cliente impone su propio sistema de codificación, el documento puede tener dos códigos, el interno y el del cliente, vinculados en la ficha.

La migración de la documentación histórica merece un plan aparte. Raramente compensa clasificar todo: suele bastar con migrar con detalle los proyectos vivos y cargar los cerrados como archivo consultable con metadatos mínimos. Lo que sí hay que decidir antes de empezar es qué revisión se considera vigente en cada documento migrado, porque esa decisión no la puede tomar un programa por sí solo.

1. ¿Hay incidentes recientes por trabajar con una revisión superada o por no poder demostrar qué se envió? Si los hay, el control de estados y emisiones es la prioridad.
2. ¿Participan externos (subcontratistas, clientes, dirección facultativa)? Entonces los permisos por estado y las transmisiones registradas son imprescindibles desde la primera versión.
3. ¿El convenio de revisiones y codificación cambia según el cliente? Hace falta que sea configurable por proyecto.
4. ¿Los documentos se generan en herramientas CAD o BIM concretas? Valora qué integración ofrecen antes de decidir si el sistema guarda los nativos, solo los PDF de referencia o ambos.
5. ¿Existe ya un gestor documental genérico en la empresa? Puede bastar con configurarlo bien; un desarrollo a medida tiene sentido cuando los circuitos de aprobación, la codificación o la relación con otros sistemas (requisitos, compras, obra) no encajan en él.

Una buena forma de validar cualquier propuesta es pedir que se recorra un caso real de vuestro archivo: un plano que haya tenido tres revisiones, con comentarios de dos disciplinas y una emisión a un subcontratista. Si el sistema reproduce esa historia con claridad, va por buen camino. Si quieres estudiar cómo encajaría en vuestros proyectos, podemos analizarlo con vosotros a partir de ese mismo ejemplo.