Gestión de cambios en proyectos aeroespaciales

Aunque cada organización lo nombra a su manera, el recorrido de un cambio suele tener las mismas etapas. Diseñar el software a partir de ellas, y no de una lista genérica de tareas, evita que se salten pasos cuando hay prisa.

1. Solicitud: alguien identifica la necesidad (obsolescencia, no conformidad repetida, petición del cliente, mejora) y la registra con su motivo.
2. Análisis de impacto: cada disciplina afectada evalúa consecuencias sobre requisitos, diseño, masa, interfaces, coste, plazo, fabricación y verificación.
3. Clasificación: según los criterios del programa, el cambio se considera de un tipo u otro, lo que determina quién debe aprobarlo y si interviene el cliente o una autoridad.
4. Decisión: un comité o responsable autorizado aprueba, rechaza o pide más información, y fija la efectividad.
5. Implementación: se emiten las nuevas revisiones de los documentos afectados y se actualizan las listas de materiales.
6. Verificación y cierre: se comprueba que todo lo previsto se ha hecho y se adjuntan las evidencias antes de cerrar.

Como referencia de cómo se formaliza la clasificación en aviación, el Reglamento (UE) n.º 748/2012 distingue en su Parte 21 entre cambios importantes y secundarios en el diseño de tipo, con caminos de aprobación diferentes. En proyectos espaciales europeos, la gestión de la configuración y de la información se trata en la norma ECSS-M-ST-40C. Lo útil para el diseño del software es que la clasificación sea un dato explícito del cambio, con su justificación, y que determine automáticamente el circuito de aprobación configurado.

Un cambio solo se puede evaluar respecto a algo fijo. Por eso los programas trabajan con líneas base: conjuntos de requisitos y documentos, cada uno en una revisión concreta, que se congelan en hitos del proyecto, como las revisiones de diseño. A partir de ahí, cualquier modificación de un elemento de la línea base debe pasar por el proceso de cambio.

Para el software esto significa poder responder con rapidez a preguntas como: ¿qué requisitos de la línea base actual se ven afectados si cambia esta especificación?, ¿qué documentos han cambiado desde la revisión crítica de diseño y en virtud de qué cambios aprobados?, ¿hay alguna revisión emitida sin un cambio aprobado que la respalde? Esta última consulta es especialmente valiosa: detecta modificaciones que se colaron fuera del proceso.

La gestión de configuración responde a una pregunta aparentemente simple: ¿cómo es exactamente esta unidad? En programas con pocas unidades y larga vida, como satélites, cargas útiles o equipos de vuelo, es frecuente que cada unidad acabe teniendo una configuración ligeramente distinta por cambios introducidos en momentos diferentes, desviaciones aceptadas o reparaciones.

Por eso conviene separar dos vistas. La configuración de diseño es lo que dicen los documentos aprobados para un número de serie dado, aplicando la efectividad de cada cambio. La configuración construida es lo que realmente se montó, con las piezas concretas, sus lotes y cualquier desviación o concesión aceptada durante la fabricación. La diferencia entre ambas vistas debe estar siempre explicada por registros formales; si no lo está, hay un problema que investigar.

• Desviación: autorización previa para fabricar una o varias unidades apartándose temporalmente de la definición aprobada.
• Concesión: aceptación posterior de una unidad ya fabricada que no cumple lo especificado, normalmente tras un análisis.
• Ambas deben quedar ligadas a los números de serie afectados y aparecer en la configuración construida de cada uno.

Cerrar un cambio no es marcar una casilla. Las evidencias típicas son las nuevas revisiones emitidas de todos los documentos afectados, los análisis actualizados, los resultados de los ensayos de verificación que se hayan requerido, la actualización de la lista de materiales y, cuando el cambio afecta a unidades ya fabricadas, el registro de su modificación o la decisión de no modificarlas.

Un ejemplo de regla útil: el sistema no permite cerrar el cambio mientras alguno de los documentos listados como afectados siga en la revisión anterior, o mientras una acción de verificación no tenga resultado adjunto. Otra: al cerrar, se genera automáticamente un resumen con todas las revisiones emitidas y las evidencias, que puede entregarse al cliente si el contrato lo prevé.

Muchas organizaciones ya tienen un PLM para la definición de producto, una herramienta de requisitos y un ERP para compras y fabricación. El riesgo es que la gestión de cambios se convierta en un cuarto sistema con datos duplicados. Lo más sensato suele ser que el flujo de cambios consulte y referencie los elementos donde ya viven, y que publique hacia el ERP la efectividad de cada cambio para que compras y producción trabajen con la configuración correcta.

Si el PLM existente ya ofrece un módulo de cambios adecuado, puede bastar con configurarlo. Un desarrollo a medida tiene sentido cuando el proceso del programa no encaja, cuando hay que integrar varias herramientas que no se hablan entre sí o cuando la relación con proveedores y clientes exige un portal propio.

1. ¿Podéis listar, para una unidad concreta, todos los cambios, desviaciones y concesiones que le aplican? Si cuesta, la configuración construida es la prioridad.
2. ¿El análisis de impacto llega a todas las disciplinas o depende de que alguien se acuerde de avisar?
3. ¿Hay revisiones de documentos emitidas sin un cambio aprobado que las respalde?
4. ¿La clasificación del cambio determina el circuito de aprobación de forma explícita y registrada?
5. ¿Las evidencias de cierre están en el mismo sitio que el cambio o repartidas en correos y carpetas?

Responder a estas preguntas con datos de un programa real es la mejor manera de saber dónde está el hueco. Si quieres, podemos revisarlas contigo y plantear qué parte del proceso conviene apoyar con software y cómo integrarla con lo que ya tenéis.