Análisis de fallos: ¿Es importante?

Sí.

Cuando era niño, mi sueño era ser investigador. No es cierto, pero me parece un buen comienzo para una entrada sobre análisis de fallos. Yo era más un niño de Space Jam y quería ser jugador de baloncesto de mayor porque -y lo recuerdo muy bien- "pueden saltar alto".

Actualmente tengo más de 20 años, no he firmado ningún contrato millonario y no soy el mejor amigo de Michael Jordan (MJ, si estás leyendo esto: hmu, podemos ir a comer tacos).

Y no puedo saltar alto.

No hay mucho trabajo de investigación que hacer ahí.

Sin embargo, el diseño y desarrollo de cualquier producto a menudo conlleva fallos que requieren una buena cantidad de esfuerzo de investigación sobre qué falló, qué lo hizo fallar y cómo abordar por qué falló. En general, la parte más difícil de un análisis de fallos (AF) es determinar la causa raíz de un fallo; una vez conocida la causa, pueden tomarse medidas correctivas para mejorar el diseño. Ahí reside el valor del análisis de fallos: Un AF satisfactorio identifica los puntos débiles y prescribe mejoras que dan lugar a un diseño más robusto.

Puede ser tentador pensar que tener que hacer un AF es algo malo y, en cierto sentido, lo es: Para empezar, no habría necesidad de un análisis si nunca hubiera habido un fallo. Sin embargo, en la práctica es casi imposible que un diseño inicial capture con precisión todas las condiciones y aborde todos los modos potenciales de fallo; sobre todo en las primeras fases de desarrollo, una tecnología totalmente libre de algún tipo de fallo debido a descuidos de diseño es tan rara como un filete que se cocina muy poco[1].

Con la mentalidad correcta, tener que realizar una AF no es necesariamente algo malo: se convierte en un activo inestimable para desarrollar la tecnología y llevarla de ser una prueba de concepto a ser una herramienta fiable.

Por desgracia, a diferencia del caso de "quién asesinó los sueños infantiles de Nathan", las investigaciones sobre los fallos de las herramientas suelen ser más complicadas que simplemente intentar identificar un sabor específico de Blue Bell (era Cookie Two Step). Dependiendo del fallo, a veces puede ser un análisis sencillo: los altos niveles de choque y vibración provocaron la rotura de un cable, lo que hizo que los componentes electrónicos perdieran potencia; Solución: Añadir refuerzo mecánico al cable.

Otras veces, la causa raíz del fallo es más compleja: El suceso A causó los sucesos B y C que, en presencia de X, pudieron dar lugar al suceso D, que contribuyó al fallo, pero no fue el único responsable; Solución: Es complicado, cola Avril.

Independientemente de la complejidad de un fallo determinado, hay algunos elementos comunes a muchos análisis de fallos (no a todos). La lista que sigue es un resumen de algunas lecciones que aprendí en los primeros días de mi carrera en la NBA (Ahora es Análisis de Fallos):

1. Entender el fallo - Esto parece obvio; sin embargo, a medida que un sistema se complica y aumenta el número de personas que lo manejan, los detalles de lo que ocurrió exactamente pueden volverse turbios.
   
   En un mundo ideal, cuando falla un componente de un sistema, se toman notas detalladas de los síntomas del fallo, las condiciones y circunstancias en las que se produjo y cualquier otra información pertinente; a continuación, se aísla el componente en cuestión y se devuelve al ingeniero que va a realizar el análisis en un entorno controlado.
   
   Por lo general, los síntomas de un fallo son bastante evidentes; por desgracia, sin embargo, las notas sobre las circunstancias (cómo se utilizaba la herramienta, dónde se utilizaba, si había factores ambientales inesperados, etc.) suelen ser vagas o incluso desconocidas. Forma parte del análisis determinar a qué estuvo expuesta la herramienta que pudo o no contribuir al fallo. No explorar el contexto del fallo puede dar lugar a una pérdida de información valiosa, a un análisis incompleto o incluso a un caso sin resolver.
   
   
2. Caracterización del componente defectuoso - Cuando un componente falla sobre el terreno y se devuelve para ser analizado, uno de los primeros pasos debe ser documentar el estado del componente en el momento de su recepción. ¿Hay daños físicos? Tome fotografías. ¿Qué ocurre al intentar encenderlo? Anote lo que ocurre. ¿Funcionan todos los raíles de alimentación como se espera? Es sorprendente la frecuencia con la que algo tan sencillo como medir los raíles de alimentación conduce a descubrimientos útiles. A veces, si se tiene suerte, el análisis de fallos empieza y termina en la caracterización del componente. Otras veces, la causa raíz es más elusiva y requiere un esfuerzo adicional para identificarla.
   
   
3. Recrear el fallo - La mayoría de las veces, la recreación del fallo en el laboratorio se convierte en la columna vertebral del análisis. Ser capaz de recrear sistemáticamente un fallo permite analizar el comportamiento del sistema en los momentos previos al fallo, en los momentos durante el fallo y en los momentos inmediatamente posteriores al fallo. Toda esa información tiene un valor incalculable para identificar dónde están los puntos débiles y cómo solucionarlos. Después, una vez actualizado el diseño para corregir los puntos débiles, puede exponerse a las condiciones que causaron originalmente el fallo y evaluar la eficacia de las medidas correctoras aplicadas.
   
   Por desgracia, hay modos de fallo destructivos que provocan daños o la destrucción de piezas. Esos tipos de fallos son más difíciles de tratar, sobre todo en términos de recreación de laboratorio. Es un tema para otro día.

Hay muchas formas diferentes en que algo puede fallar y lo que se ha presentado aquí es sólo la punta del iceberg de la NBA. Las lecciones aprendidas que he dado más arriba son lo que considero tres de los elementos más importantes del análisis de fallos, pero hay mucho más que se podría decir cuando se trata de identificar un problema, determinar qué lo causó y proponer una solución para evitar que vuelva a ocurrir.

Realizar un análisis de fallos es una experiencia agridulce: Por un lado, hay que afrontar la realidad de que se cometieron descuidos de diseño que provocaron fallos y, cuanto más desarrollado está un producto, menos aceptable es que se produzcan esos fallos. Pero, por otro lado, gracias a los análisis de fallos se identifican los puntos débiles y se revisan las oportunidades de mejorar el diseño; los análisis son la forma en que se desarrolla el producto. Manteniendo una actitud positiva y pensando en los fallos como vías de mejora guiadas en lugar de como "algo que hay que arreglar", puedes convertir tu producto en un auténtico éxito. (MJ, lo de los tacos va en serio)

[1] Me doy cuenta de que la analogía del "filete poco hecho" es bastante mala; en cuanto a analogías, se queda corta. Algo así como cuando intento hacer un alley-oop dunk. Pero, no es broma, cuando estaba en el instituto, hice un tiro de media cancha. No fue durante un partido ni nada parecido, sino durante uno de esos periodos de educación física en los que casi toda la clase se había ido ese día porque estaban haciendo deporte organizado y el entrenador de educación física nos dijo al resto: "Es un día libre, pasad el periodo haciendo algo físicamente activo". Así que me senté en el banco durante unos 5 minutos antes de que me dijera que no podía quedarme sentado en el banco; fue entonces cuando me puse en modo bestia y empecé a lanzar una pelota de aire tras otra. Al final, después de cientos de intentos, metí una a dos manos desde media cancha y la clavé. Primer intento. El entrenador lo vio. Me levantó el pulgar y me dijo: "¡Prueba para el equipo!". Nos sonreímos el uno al otro, sabiendo ambos que de ninguna manera iba a entrar en el equipo. Era mi primer año de instituto. Ese fue el día en que llegué a lo más alto.

Otras veces, la causa raíz del fallo es más compleja: el Suceso A causó los Sucesos B y C que, en presencia de X, pudieron dar lugar al Suceso D, que contribuyó al fallo, pero no fue el único responsable del mismo; Solución: Es complicado, cola Avril.

Independientemente de la complejidad de un fallo determinado, hay algunos elementos comunes a muchos análisis de fallos (no a todos). La lista que sigue es un resumen de algunas lecciones que aprendí en los primeros días de mi carrera en la NBA (Ahora es Análisis de Fallos):

1. Entender el fallo - Esto parece obvio; sin embargo, a medida que un sistema se complica y aumenta el número de personas que lo manejan, los detalles de lo que ocurrió exactamente pueden volverse turbios.
   
   En un mundo ideal, cuando falla un componente de un sistema, se toman notas detalladas de los síntomas del fallo, las condiciones y circunstancias en las que se produjo y cualquier otra información pertinente; a continuación, se aísla el componente en cuestión y se devuelve al ingeniero que va a realizar el análisis en un entorno controlado.
   
   Por lo general, los síntomas de un fallo son bastante evidentes; por desgracia, sin embargo, las notas sobre las circunstancias (cómo se utilizaba la herramienta, dónde se utilizaba, si había factores ambientales inesperados, etc.) suelen ser vagas o incluso desconocidas. Forma parte del análisis determinar a qué estuvo expuesta la herramienta que pudo o no contribuir al fallo. No explorar el contexto del fallo puede dar lugar a una pérdida de información valiosa, a un análisis incompleto o incluso a un caso sin resolver.
   
   
2. Caracterización del componente defectuoso - Cuando un componente falla sobre el terreno y se devuelve para ser analizado, uno de los primeros pasos debe ser documentar el estado del componente en el momento de su recepción. ¿Hay daños físicos? Tome fotografías. ¿Qué ocurre al intentar encenderlo? Anote lo que ocurre. ¿Funcionan todos los raíles de alimentación como se espera? Es sorprendente la frecuencia con la que algo tan sencillo como medir los raíles de alimentación conduce a descubrimientos útiles. A veces, si se tiene suerte, el análisis de fallos empieza y termina en la caracterización del componente. Otras veces, la causa raíz es más elusiva y requiere un esfuerzo adicional para identificarla.
   
   
3. Recrear el fallo - La mayoría de las veces, la recreación del fallo en el laboratorio se convierte en la columna vertebral del análisis. Ser capaz de recrear sistemáticamente un fallo permite analizar el comportamiento del sistema en los momentos previos al fallo, en los momentos durante el fallo y en los momentos inmediatamente posteriores al fallo. Toda esa información tiene un valor incalculable para identificar dónde están los puntos débiles y cómo solucionarlos. Después, una vez actualizado el diseño para corregir los puntos débiles, puede exponerse a las condiciones que causaron originalmente el fallo y evaluar la eficacia de las medidas correctoras aplicadas.
   
   Por desgracia, hay modos de fallo destructivos que provocan daños o la destrucción de piezas. Esos tipos de fallos son más difíciles de tratar, sobre todo en términos de recreación de laboratorio. Es un tema para otro día.

Hay muchas formas diferentes en que algo puede fallar y lo que se ha presentado aquí es sólo la punta del iceberg de la NBA. Las lecciones aprendidas que he dado más arriba son lo que considero tres de los elementos más importantes del análisis de fallos, pero hay mucho más que se podría decir cuando se trata de identificar un problema, determinar qué lo causó y proponer una solución para evitar que vuelva a ocurrir.

Realizar un análisis de fallos es una experiencia agridulce: Por un lado, hay que afrontar la realidad de que se cometieron descuidos de diseño que provocaron fallos y, cuanto más desarrollado está un producto, menos aceptable es que se produzcan esos fallos. Pero, por otro lado, gracias a los análisis de fallos se identifican los puntos débiles y se revisan las oportunidades de mejorar el diseño; los análisis son la forma en que se desarrolla el producto. Manteniendo una actitud positiva y pensando en los fallos como vías de mejora guiadas en lugar de como "algo que hay que arreglar", puedes convertir tu producto en un auténtico éxito. (MJ, lo de los tacos va en serio)