Qué debe incluir el control documental en un proyecto aeronáutico

El primer error es limitar el control documental a los planos. En un proyecto aeronáutico la documentación de diseño es solo una parte de una red que incluye especificaciones, análisis, planes y resultados de verificación, y registros de calidad. Lo que importa es que todos compartan identificación, revisiones y relaciones.

• Especificaciones y requisitos: del cliente, derivados, de interfaz con otros sistemas.
• Definición de diseño: planos, modelos 3D, listas de materiales, especificaciones de proceso y de material.
• Justificación: informes de cálculo, análisis de tolerancias, análisis de seguridad, memorias técnicas.
• Verificación: planes de ensayo, procedimientos, informes de resultados, actas de inspección.
• Registros de producción y calidad: hojas de ruta, primeras piezas, no conformidades y sus disposiciones.
• Correspondencia técnica relevante: consultas al cliente, respuestas y decisiones que modifican el alcance.

Cada documento necesita un identificador estable y una revisión explícita. Lo habitual es distinguir entre versiones internas de trabajo, que no salen del equipo, y revisiones formales, que pasan por comprobación y aprobación y quedan congeladas. En aeronáutica se añade un matiz que en otros sectores se pasa por alto: la efectividad. Una revisión de un plano puede aplicar a partir de un número de serie, de un lote o de un estándar de modificación concreto, y las anteriores siguen siendo válidas para las unidades ya fabricadas.

La lista de documentos del proyecto, con la revisión vigente de cada uno, debe obtenerse del sistema en cualquier momento y también tal como estaba en una fecha pasada. Esa capacidad de reconstruir una foto histórica es la que se echa en falta cuando llega una consulta sobre una unidad entregada hace tiempo.

La traza es la relación explícita entre elementos: este requisito se satisface con este diseño, se justifica con este análisis y se verifica con este ensayo, cuyo resultado está en este informe. Mantenerla en una hoja de cálculo es posible al principio, pero se degrada en cuanto empiezan las revisiones, porque nadie actualiza las referencias cruzadas con la disciplina necesaria.

En un sistema bien diseñado, la traza apunta a una revisión concreta de cada documento. Cuando se emite una nueva revisión de un plano, el sistema puede marcar como «pendiente de confirmar» las trazas que salen de él: el análisis de tensiones que se apoyaba en la revisión anterior, el procedimiento de ensayo que medía una cota que ha cambiado. Un ingeniero decide si siguen siendo válidas o necesitan revisión. El software no toma esa decisión, pero impide que pase desapercibida.

• Matriz de cumplimiento generada desde los datos, no mantenida a mano.
• Consulta de impacto: qué se ve afectado si cambia este requisito o este documento.
• Detección de huecos: requisitos sin método de verificación asignado o sin evidencia cerrada.
• Exportación de la matriz en el formato que pida el cliente, con la revisión de cada documento referenciado.

Una no conformidad es la constatación de que algo, una pieza, un proceso o un documento, no cumple lo especificado. Su tratamiento genera documentación que debe quedar unida a la definición de diseño afectada. Un flujo típico registra la descripción y la evidencia del hallazgo, la contención inmediata, el análisis de causa, la decisión sobre el elemento afectado y, si procede, una acción correctiva que puede acabar en una nueva revisión de un plano o de un procedimiento.

Las decisiones sobre el elemento no conforme se suelen expresar con un conjunto cerrado de opciones, como retrabajar, reparar, usar tal cual con justificación o rechazar. Quién puede tomar cada decisión y qué justificación técnica se exige lo define el procedimiento de la organización. El software puede reforzarlo: impedir que se cierre una decisión de «usar tal cual» sin el informe técnico adjunto y sin la firma del rol autorizado, y enlazar la no conformidad con el número de serie afectado para que aparezca en su historial.

Para que un registro sirva como evidencia tiene que ser íntegro y atribuible. Eso implica guardar quién hizo cada acción y cuándo, impedir modificaciones sobre documentos aprobados, conservar las revisiones superadas y disponer de un registro de auditoría que no pueda editarse desde la aplicación. Los periodos de conservación y los formatos los fija la organización según sus obligaciones; el sistema debe permitir aplicarlos y demostrar que se aplican.

• Registro de auditoría de altas, cambios de estado, firmas y descargas.
• Formatos de archivo a largo plazo para la copia de referencia, además del nativo.
• Copias de seguridad probadas con restauraciones periódicas, no solo programadas.
• Control de acceso por programa y por cliente, porque es habitual que convivan proyectos con requisitos de confidencialidad distintos.

1. ¿Puede reconstruir la lista de documentos vigentes en una fecha pasada, con sus revisiones?
2. ¿Las trazas apuntan a revisiones concretas y avisan cuando una revisión nueva las pone en duda?
3. ¿Gestiona la efectividad por número de serie, lote o estándar de modificación?
4. ¿Las no conformidades quedan unidas a los documentos y a las unidades afectadas, y sus decisiones exigen las justificaciones y firmas que marca vuestro procedimiento?
5. ¿Se adapta a vuestros procedimientos aprobados sin obligaros a cambiarlos para encajar en la herramienta?
6. ¿Convive con el PLM, el ERP o la herramienta de requisitos que ya usáis, o duplica su información?

Si varias respuestas son negativas con las herramientas actuales, tiene sentido estudiar una solución que complete lo que falta, a menudo integrada con lo existente más que en sustitución. Recuerda que la decisión sobre cómo demostrar el cumplimiento sigue siendo de la organización. Si quieres revisar vuestro caso, podemos analizar con vosotros qué parte de la cadena documental conviene apoyar con software.