Control de Configuración

Continuamos hoy la serie de artículos dedicados a algunas de las contribuciones del programa espacial a la gestión de proyectos, hablando sobre el Control de Configuración o Gestión de la Configuración.

El control de configuración, hoy habitualmente entendido como una disciplina más o menos independiente dentro de los equipos de ingeniería, con su propio equipo de técnicos, es el encargado de asegurar la configuración de un determinado producto a todo lo largo de su vida.

¿Qué significa esto? Pues, dicho de forma sencilla, que tengamos controlada en todo momento la configuración interna de cualquier producto que haya salido de nuestra línea de producción, independientemente de los cambios de diseño o mejoras implementadas a lo largo de la vida del proyecto. Gracias al control de configuración podemos saber cómo era exactamente el producto que vendimos a determinado cliente hace 5 años, que probablemente no sea idéntico al que salió de nuestra fábrica ayer. De esta forma podemos realizar un adecuado mantenimiento entregando los repuestos adecuados en todo momento, y nos permite también, en caso de avería o accidente, poder investigarlo con efectividad, al conocer exactamente la arquitectura interna de ese determinado producto.


Dicho así, la cosa parece simple, pero en la realidad no lo es tanto. Y es que si pensamos en productos tan complejos como un avión o un vehículo espacial, por ejemplo, constituidos por millones de piezas diferentes y con líneas de producción que a menudo se extienden a lo largo de décadas, el número de cambios implementados entre diferentes artículos salidos de la línea de producción puede fácilmente contarse por millares. Y muy a menudo son cambios invisibles para el cliente final, pero importantes a la hora de realizar el mantenimiento o, como decimos, de investigar un accidente, por ejemplo.

Los cambios pueden ser de muy diferente tipo. Están los cambios de versión, por ejemplo, estos son los más evidentes, donde el producto final sí muestra una determinada diferencia, por pequeña que sea, con respecto a otros productos similares. Pero a menudo existen cambios que no modifican la versión, por no variar el aspecto o prestaciones del producto final, y tratarse por tanto de cambios indiferentes para el comprador. Por ejemplo, el cambio de un determinado tratamiento de protección sobre una pieza porque el que se aplicaba hasta entonces ha sido prohibido por cuestiones medioambientales (esto está sucediendo mucho últimamente); o un cambio de material en una pieza por otro de similares características, pero diferente. O una mejora en el diseño de una pieza interna para hacerla más económica de fabricar, más fácil de montar, más ligera o menos propensa a los fallos… En fin, las razones de los cambios pueden ser, y son, de múltiple naturaleza, pero os aseguro que los cambios en este tipo de productos son constantes, continuos a lo largo de toda la vida del proyecto. Una vez que diseñas un producto de esta complejidad, puedes estar seguro de que tendrás que mantener activo un equipo de diseño hasta el mismo día en que se decida cerrar la línea de producción, sólo para implementar cambios día tras día.

La necesidad de mantener el control de los cambios y el perfecto conocimiento de la configuración de cada producto es evidente en algunos casos, pero quizás no tanto en otros. Si cambiamos el diseño interno de una zona o de un conjunto de piezas, es evidente que tenemos que saber cuáles eran exactamente las piezas que montaba determinado producto, para poder suministrar un repuesto adecuado si es necesario. También debemos poder examinar rápidamente los planos y los documentos de cálculo de aquel producto en concreto, por ejemplo para examinar si un determinado daño sufrido en servicio es admisible o necesita reparación o reemplazo.

Pero en otros casos, la necesidad de conocer en detalle la configuración tiene un motivo distinto. Supongamos, por ejemplo, que realizamos un cambio aparentemente indiferente, como cambiar un anodizado crómico en una pieza de aluminio (protección anticorrosión) por un anodizado tartárico, por razones medioambientales (todos los tratamientos con cromo están siendo prohibidos en buena parte del mundo). En principio, el cambio puede parecer indiferente, y si la pieza no cambia, a efectos de recambios podría darnos igual, y podríamos reemplazar una pieza antigua con anodizado crómico por una nueva con anodizado tartárico. Pero supongamos que dentro de 10 años descubrimos que el anodizado tartárico produce una reacción química con el oxígeno del aire a las 5 de la tarde de los días 25 de abril de año bisiesto en los que llueva y salga el arco iris, y que eso produce la desintegración inmediata de la pieza (cambiad la chorrada por cualquier descubrimiento imprevisto que afecte a la seguridad, y que fuera desconocido hasta entonces). Esto lo descubrimos después de investigar un accidente en el que un avión que llevaba una pieza crítica con anodizado tartárico tuvo la mala suerte de volar a las 5 de la tarde de un 25 de abril de año bisiesto en una zona donde había salido el arco iris, y se estrelló. Tras la investigación, se decide sustituir todas las piezas con anodizado tartárico que equipen toda la flota mundial de aviones. Y para eso, tenemos que saber exactamente qué aviones equipan ese tipo de piezas, y dónde…

¿A qué obliga esto? Primero, a conservar absolutamente toda la documentación (planos, documentos de cálculo estructural, certificados de los materiales empleados, etc) de todos y cada uno de los productos que salen por la puerta de nuestra fábrica. Cada versión del producto, aunque sólo se cambie un tornillo, debe contar con su propio juego de documentación. Esto obliga a reidentificar los productos, a que cada uno tenga una identificación propia; hay que cambiar el número identificativo de la pieza, por ejemplo, y necesitamos una trazabilidad que nos muestre rápidamente qué productos incorporan esa pieza determinada, etc.

Esto obliga no sólo a una continua edición de nueva documentación (el trabajo de modificaciones en esta fase es un 10% de modificación técnica, y un 90% de burocracia para generar nueva documentación), sino a mantener una detallada base de datos que nos permita controlar todo este maremágnum. Pues bien, el mantenimiento de dicha base de datos, la generación de los procedimientos (normas) que aseguren la correcta trazabilidad de los productos, etc, es decir, todo lo que podríamos considerar la gestión que rodea a estas actividades, es la misión del control de configuración.

Bueno, menuda introducción… Sí, ya sé, entráis aquí esperando leer sobre cohetes y astronautas y robots en Marte, y os doy la chapa con esto, pero así los jovencitos no os llevaréis sorpresas si alguno decide meterse a ingeniero pensando en diseñar cohetes y luego se encuentra manejando papeles el 70% de su tiempo ;-)

Bien, al grano: ¿cuándo y cómo nació esto del control de configuración, tal y como lo conocemos hoy en día? Pues la idea debió empezar a gestarse más o menos tras el final de la Segunda Guerra Mundial, y el primer proyecto en el que se implantó esta técnica fue para el desarrollo de uno de los primeros motores a reacción para la Fuerza Aérea de los Estados Unidos, durante los años 50. Después, la metodología se fue desarrollando hasta editarse la primera norma oficial por parte de la USAF en 1962.

Claramente, la necesidad había nacido en el campo de la aviación, con el desarrollo de aeronaves y motores cada vez más complejos, que hacían evidente la necesidad de una gestión de este tipo. Pero con lo que el Control de Configuración llegó a su culmen fue con el proyecto Apollo, también desarrollado durante los años 60. Podemos decir que el Apollo constituyó la prueba de fuego de esta disciplina recién nacida.

Como sabéis, el Apollo sigue siendo a día de hoy el mayor proyecto de ingeniería de toda la historia. El desarrollo de los cohetes y las naves encargados de llevar al hombre hasta la Luna implicaron a millones de personas, que desarrollaron productos compuestos a su vez por miles de millones de elementos diferentes. Y, como siempre, sometidos a constantes cambios.

Si bien el Control de Configuración ya existía como tal, el proyecto Apollo exigió el perfeccionamiento de sus metodologías, pudiéndose considerar por tanto como los orígenes de las modernas técnicas de control de configuración. En realidad, el Apollo fue tan extremadamente complejo que buena parte de las herramientas de planificación y gestión de proyectos que usamos en la actualidad tienen sus orígenes remotos relacionados de alguna forma con el programa que llevó al hombre a la Luna. Ya se sabe que la necesidad agudiza el ingenio, y desde luego el Apollo generó muchísimas necesidades de gestión de todo tipo.

Hoy en día, el Control de Configuración ha extendido sus fronteras. Si en un principio nació en un contexto aeronáutico derivándose rápidamente al área espacial, tampoco tardó en contagiar a la incipiente industria de la informática. Ya en los años 60 los primeros desarrollos de software empezaron a utilizar técnicas de control de configuración, y probablemente sea en la actualidad el área que más extensivo uso realiza de estas técnicas. Y es que no sólo el software y la informática en general están también en continuo cambio, sino que probablemente sean el área que más rápidamente evoluciona en nuestra sociedad actual. Para ellos también, el control de configuración es una clara necesidad.