A history of aerospace problems (1)

Es realmente, más que un libro, un informe técnico de la NASA, publicado en 1996, por uno de sus ingenieros en el Marshall Space Flight Center de Alabama, R. S. Ryan, retirado precisamente ese año y que trabajó en diferentes proyectos desde el Apolo.

Salvo indicación específica, las figuras y tablas son extraídas del texto original. Cualquier error de traducción y las interpretaciones son responsabilidad mía.

INTRODUCCIÓN

Solucionar un problema NO es buscar culpables a quienes cargarles el marrón (para eso están los que no tienen ningún tipo de responsabilidad, como los becarios, las subcontratas o los materiales, no?), sino establecer una baliza que sirva, a los demás y a nosotros mismos, de lo que NO hay que repetir.

Una herramienta muy útil es dedicar el tiempo necesario a estudiar el pasado. Porque seguro que alguien ya pasó por eso antes: Qué ocurrió, cómo se solucionó, qué se usó (sea tecnología, técnicas, instalaciones) y qué se aprendió.

Y cuando ya se sabe lo que pasaron otros, ajustar ese conocimiento al problema actual.

Solucionar un problema (sea en el transbordador espacial o en el taller de una empresa de medio pelo) no es aplicar parches y apaños para ir tirando. Requiere combinar:

• Conocimientos y habilidades del personal involucrado
• Disponer de las herramientas necesarias (sean propias o de otros que sepan más).
• Tener las instalaciones necesarias.
• Acceso a las tecnologías que nos facilitarán solucionar el problema.

 ASPECTOS GENERALES

¿POR QUÉ ES BUENA IDEA ESTUDIAR LOS PROBLEMAS? (en vez de sólo solucionarlos rápido)

Hay cosas muy complicadas (no es lo mismo pintar una torre eólica que construir un transbordador espacial) que requieren hilar muy fino y que en ocasiones implican aspectos que apenas están desarrollados o implementados industrialmente. Pero también es cierto que en casi todos los sectores están apareciendo especificaciones muy exigentes (y se aplican a pintar una torre eólica o a construir un transbordador espacial).

En algunos casos, esos productos-sistemas-estructuras requieren un funcionamiento impecable y, por tanto, son muy sensibles a cambios muy pequeños.

Que algo funcione depende del estado de desarrollo en el que se encuentre el producto o el proceso que se use para fabricarlo.

Producto	Desde una gran variedad inicial hasta alcanzar un diseño predominante. Desde una innovación creciente hasta un producto estandarizado
Proceso	Desde depender de una gran especialización en la manufactura hasta una producción generalizada y con poca especialización
Organización	Desde los emprendedores hasta una empresa basada en tareas/procedimientos estructurados casi mecánicos y sin motivación para innovar
Mercado	Desde uno muy especializado e inestable (pero con gran retroalimentación) hasta un producto básico homogéneo y sin diferenciación
Competencia	Desde pequeñas empresas con productos propios a multitud de empresas con productos genéricos

Pero también influye el efecto de las novedades en las tecnologías y productos ya establecidos. Para evitar quedar obsoletos, los de antes buscan un impulso para que los de ahora no les quiten del medio. Pero suele pasar que los nuevos vienen para quedarse y los viejos se retiran, si pueden, con el orgullo de haber hecho un buen trabajo.

En la fase inicial de un producto, donde manda el desarrollo y la implementación, conocer el pasado es una guía fundamental para determinar las necesidades.

Cuando lo que manda el es proceso productivo, el foco está en su afinado (casi en su significado musical) para optimizarlo y conseguir una mayor fiabilidad al menor coste posible. Aquí también hay que tener en cuenta la prevención de problemas, para lo que también es útil conocer el pasado.

¿Y en la transición entre ambas fases? Pues dado que ahí se decide si ese producto va adelante o no, conocer el pasado también es de ayuda.

En aquellos sistemas a los que se pide un gran rendimiento (con razón o sin ella) se precisa una atención especial para no perder las ventajas obtenidas gracias a la eficiencia de funcionamiento y coste. Una eficiencia que suele implicar desarrollar nuevas tecnologías.

En conseguir esto de la eficiencia el trabajo no es solitario ni unidireccional. Hay una serie de interrelaciones entre personas, herramientas y desarrollo tecnológico. Dentro unos cuantos aforismos:

• Un equipo suele funcionar al nivel de su componente más débil.
• Con el liderazgo y las sinergias adecuadas, un equipo puede funcionar por encima del nivel de su mejor componente.
• El liderazgo técnico desde abajo.
• Una empresa funciona a dos niveles:
• La parte que hace el trabajo fino de mejora de lo que ya se hace.
• La parte que explora caminos nuevos que pueden terminar en cambios drásticos tanto de producto como de proceso.

El análisis histórico de los problemas tiene dos grandes utilidades

• Es fuente de conocimiento con la suficiente profundidad y consideración de aspectos sutiles no habituales en el contexto académico.
• Proporciona información y rutas para desarrollar nuevos análisis y las consiguientes prioridades que se precisan en el problema actual.
• Permite identificar esas tecnologías competidoras que posibiliten el impulso de las establecidas.

Ya en 1996 había recortes presupuestarios. Y ya se señalaba también que esos recortes implicaban trasladar el peso presupuestario desde el diseño hacia la producción y la operatividad. Consecuencia: Reducción de la flexibilidad del producto.

Nada es para siempre y en ingeniería no se construye para una durabilidad ilimitada. De lo que se trata es de decidir qué se considera una vida en servicio adecuada.

Por otro lado, las cosas no existen aisladas e individuales. Funcionan interconectadas: La salida de unas es la entrada de otras. Con el diseño se busca prever y controlar, en la medida de lo posible, que los intercambios sean beneficiosos (o no muy perjudiciales, si nos decantamos por el pesimismo). Se diseña pensando en el fallo.

No hay diseños rompedores si se parte de una selección inicial incorrecta; y la mejor idea inicial puede fracasar por un mal diseño.

En muchas ocasiones, el diseño se replantea para solucionar un marrón y reajustar lo necesario para que vuelva a funcionar. Sin pensar en el origen. Sólo para evitar que vuelva a fallar y salir del paso lo más pronto posible. Pero modificar un diseño con esto en mente, puede destapar otros modos de fallo no tenidos en cuenta o manifestar modos de fallo latentes. Lo ideal es volver al inicio del diseño y ajustarlo de nuevo.

Por aquellos años 90 andaba de moda lo de la gestión total de la calidad (TQM), la ingeniería concurrente y el horror del just-in-time (como se ha podido comprobar con el batacazo industrial de la actual pandemia). Pero recordemos lo básico: Un diseño es tan bueno como lo sea quien lo diseña y quienes lo llevan a la práctica. Por eso es tan importante tener un trabajo en equipo que consiga:

1. Sacar lo mejor de cada integrante (sea en conocimientos, creatividad, gestión, escalado, producción).
2. Tener un liderazgo claro que establezca la visión y los objetivos a conseguir.

Y para ello hay que buscar la combinación correcta de teoría y conocimientos. Porque, por ahora, la parte humana sigue siendo fundamental, con sus fortalezas y debilidades. En una empresa siempre se debe aprender y enseñar.

Para solucionar (no parchear) un problema puede pasar que lo que se tiene y se sabe no sea lo más adecuado. Y cuando llega el siguiente trabajo se piensa que será igual de problemático, complicando más el procedimiento con la idea de evitar que pase lo mismo. Pero en ciencia suele funcionar mejor lo simple que lo complejo. Y en las causas de un fallo también suele influir algo pequeño y casi nunca tenido en cuenta. Simplicidad y robustez es lo que se necesita para enfrentarse a lo nuevo.

Porque las herramientas avanzan lo que queramos: Ordenadores más potentes, programas más complejos-versátiles-precisos, ensayos que proporcionan información más útil (sobre todo si de verdad entendemos qué información proporcionan, lo que no siempre es tan evidente. Mucha gente sólo quiere que el ensayo de un valor superior al especificado para seguir el trabajo), nuevos materiales y técnicas constructivas, normativa más actualizada...

Hay técnicas de análisis de fallos (como FEMA y otras más modernas) que funcionan casi de forma automática en los ordenadores.

Por esa parte no hay problemas. Donde los hay es en la falta de innovación en la resolución de problemas técnicos, motivada, en mi opinión, en la cada vez preparación teórica de los ingenieros. Ingenieros que no saben el fundamento (y lo que es peor, las limitaciones) de los ensayos mecánicos, más allá del valor del límite elástico. Que no saben cómo se comportan un material o cómo se degrada por la acción del medio en el que se encuentra. Que se limitan a copiar-pegar de un proyecto al siguiente y no se retroalimentan de lo bueno y lo malo de sus proyectos anteriores. Y así tenemos fallos que se van transmitiendo (y como si fuera un virus, multiplicándose) de un proyecto a otro.

Siempre queda la excusa de que eso es lo que quiere el cliente final, o que no hay tiempo o (volviendo al principio) le echamos la culpa a quienes no tienen la responsabilidad.