Un AMFE de producto ayuda a un equipo de diseño a ordenar preguntas sobre fallos posibles antes de que una referencia llegue a fabricación o uso. El análisis parte de las funciones y partes del producto: qué podría fallar, qué efecto tendría, qué causas merecen consideración y qué controles de diseño ya existen. No predice con certeza todos los fallos ni demuestra que el diseño sea seguro o conforme.

Sirve para hacer visible el razonamiento y las decisiones que necesitan revisión.

La distinción clave es el objeto analizado. Bosch separa Product FMEA de Process FMEA: el primero trata componentes e interfaces del producto a lo largo de su ciclo de vida; el segundo trata el proceso de fabricación. La diferencia se complica cuando una cuestión toca ambos lados. Una característica del diseño que condiciona el ajuste de dos piezas puede requerir un análisis del producto; un método de ensamblaje que varía entre turnos apunta al proceso.

Algunas cuestiones cruzan ambas áreas y conviene documentar qué equipo revisa cada parte.

Qué entra en el análisis

Bosch Product FMEA analiza partes e interfaces del producto a lo largo del ciclo de vida; Process FMEA se ocupa de la operación de fabricación. Fuente: BOSCH-FMEA-BOOKLET-14; localizador: §2.1–2.2, p. 6. En esta guía el análisis se limita a la referencia de diseño, mientras que la ejecución de planta queda fuera.

Eso no significa que un AMFE de producto cubra automáticamente todas las fases, usos y condiciones imaginables. Antes de empezar, declara qué producto, versión, función, interfaces y fase se revisan. Si la revisión se limita a la unión de una carcasa con una tapa, dilo. No presentes el resultado como revisión integral si los conectores, el software, el servicio, el transporte o la retirada quedaron fuera.

El límite se puede plantear por referencia, familia, subsistema o cambio, según el método de la organización. Si se reutiliza trabajo anterior, confirma que el diseño, la función, el material y la aplicación siguen siendo comparables. El nombre de una pieza no garantiza que el modo de fallo ni el efecto sean los mismos. Una modificación aparentemente pequeña puede cambiar cargas, tolerancias o dependencias; la evaluación debe identificar por qué una referencia anterior sirve de apoyo.

Producto y proceso: una pregunta para cada análisis

El AMFE de producto pregunta cómo las partes o interfaces diseñadas podrían dejar de cumplir la función prevista y qué consecuencias tendría. El AMFE de proceso pregunta qué puede fallar en las operaciones de fabricación, manipulación o inspección. Por ejemplo, el diseño puede incluir una junta que no selle en determinada condición; el proceso puede colocar la junta incorrecta o no detectar su ausencia. Las descripciones se relacionan, pero no son intercambiables.

Mantén referencias cruzadas cuando el mismo asunto atraviesa ambas áreas. El equipo de diseño puede revisar el modo que depende de la geometría; el equipo de proceso, el método que posiciona la pieza; calidad puede reunir la evidencia de pruebas o producción. La estructura concreta depende de las responsabilidades locales. No uses el AMFE de producto para convertir una variación de fabricación en una característica de diseño ni al revés.

El límite también ayuda a decidir quién debe participar. Alguien que conoce la función prevista puede describir efectos; ingeniería de materiales puede explicar condiciones relevantes; fabricación puede señalar interacciones de proceso; servicio puede aportar modos observados en campo, si existen datos pertinentes. La lista no es obligatoria. Invita a quienes tengan información útil y registra las lagunas en vez de rellenarlas con opiniones presentadas como hechos.

Cómo construir una fila útil

El booklet plantea la metodología como análisis cualitativo de riesgo organizado, no como garantía de que todos los modos hayan sido encontrados. Fuente: BOSCH-FMEA-BOOKLET-14; localizador: §1.1, pp. 3–4. Por eso una fila documenta hipótesis y controles examinados, pero no certifica que el diseño esté libre de fallos.

Una fila tiene más valor si separa conceptos que suelen confundirse:

Campo de razonamiento Pregunta Ejemplo hipotético de una carcasa con tapa
Función ¿Qué debe hacer la parte o interfaz en el alcance declarado? Mantener la unión cerrada en la condición de uso definida por el equipo.
Modo potencial ¿De qué manera podría dejar de cumplir la función? La interfaz podría no conservar el cierre previsto.
Efecto Si ocurre el modo, ¿qué consecuencia tendría en el nivel examinado? La función del conjunto podría quedar limitada; el efecto final depende del sistema en que se integra.
Causa potencial ¿Qué condición de diseño podría contribuir? Una combinación de geometría y deformación que el equipo aún debe evaluar.
Control de diseño existente ¿Qué evita o detecta el problema en el diseño actual? Un análisis dimensional o una prueba de verificación ya definida para esta interfaz.

Para el caso hipotético de una referencia, documentar función, modo de fallo, efecto y controles de diseño mantiene separados diseño y controles de proceso. Fuente: BOSCH-FMEA-BOOKLET-14; localizador: §2.1 p. 6. Es una propuesta local; valida cada entrada con la especificación y evidencia del diseño revisado.

Los datos de la tabla son inventados para explicar la estructura. No describen una pieza real, una prueba ejecutada ni una predicción. Antes de convertirlos en una fila de un estudio, define la función con el requisito de diseño, comprueba si el modo es físicamente plausible y formula el efecto en el nivel correcto.

Si el posible efecto se describe solo como «el conjunto falla», quizá hace falta desglosar cómo lo notaría el usuario o qué función se pierde, pero no inventes consecuencias sin fundamento.

No juntes modo y causa en una frase como «la junta falla por mal diseño». La expresión ya da por hecho el modo, la causa y hasta el juicio sobre el diseño. Separa primero la forma de fallo («no se mantiene el sellado»), su posible causa («compresión insuficiente bajo la condición especificada») y la evidencia que falta para sostener esa relación. Si el grupo todavía no sabe por qué podría ocurrir, deja la causa como hipótesis abierta.

Comprobar una fila antes de priorizarla

Antes de asignar una prioridad, relee la fila como si fueras una persona que no participó en la reunión. ¿Se entiende la función sin conocer las abreviaturas internas? ¿El modo describe una forma de fallo y no una causa? ¿El efecto está escrito desde el nivel correcto del producto? ¿Se indica si el control ya existe o si es una acción propuesta? Si una respuesta obliga a adivinar, la fila necesita aclaración antes de convertirse en una conclusión.

En el soporte de sensor hipotético, la evidencia podría incluir el requisito funcional, la versión del modelo de diseño, las condiciones que la simulación representó y el registro que identifica el control de diseño actual. Esos datos no prueban por sí mismos que el producto sea aceptable; permiten comparar la hipótesis con las condiciones que el equipo declaró.

Si el modelo excluyó una condición relevante, anota esa diferencia y pide a la autoridad de diseño que determine si hace falta otra comprobación.

Conviene etiquetar cada elemento como dato, supuesto o pregunta abierta. «El dibujo indica tres tornillos» puede ser un dato si se verificó la versión controlada; «tres tornillos bastan para soportar la carga» es una conclusión que requiere fundamento. «El conjunto podría vibrar» puede ser una hipótesis hasta que el requisito, análisis o prueba la evalúe. Esta separación evita que una frase plausible se copie a otras referencias como si estuviera demostrada.

Si el análisis usa evidencia de una referencia anterior, identifica qué es equivalente y qué cambió: material, geometría, carga, interfaz, entorno o proceso de diseño. La comparación puede revelar que la experiencia previa no aplica; también puede reducir trabajo si la equivalencia está realmente documentada. No asumas similitud por compartir nombre comercial o familia. Registra quién aprobó la reutilización y qué diferencias quedaron fuera del alcance.

Un control existente es una actividad del diseño que ya puede prevenir el modo o descubrirlo antes de liberar la solución, según cómo lo defina el procedimiento aplicado. No cuentes una acción futura como control presente. «Haremos una prueba adicional» no acredita que hoy exista esa prueba; registra por separado la acción propuesta y la condición actual. Indica qué se verifica, contra qué criterio y en qué revisión del diseño, si esa información está disponible.

Caso hipotético: soporte de sensor en una unidad compacta

Imagina una unidad compacta que integra un sensor sobre un soporte atornillado. El escenario es inventado y no representa un equipo concreto. El equipo analiza el diseño de la interfaz del soporte, no la frecuencia con que un operario aprieta el tornillo. La función es mantener la posición relativa necesaria para la función del sensor según el requisito que el equipo tendría que identificar.

Si no existe un requisito medible o una condición de uso clara, ese vacío aparece antes de puntuar nada.

La conversación podría empezar con la pregunta «¿qué podría impedir que el soporte mantuviera su posición?» y generar varias hipótesis: flexión del soporte, interfaz insuficiente, aflojamiento, incompatibilidad dimensional o una condición ambiental. Cada hipótesis requiere valoración propia y evidencia pertinente. Un modo puede ser «desplazamiento del sensor»; el efecto inmediato podría ser que la medición no corresponda al punto previsto; una causa de diseño posible sería una rigidez insuficiente en una geometría concreta.

Ninguna de estas frases demuestra que el modo vaya a ocurrir.

Para no confundir análisis con registro de ideas, el equipo puede reservar una fila por función y modo claramente delimitado. Si hay dos efectos con consecuencias distintas, mantén esas consecuencias separadas. Si el modo solo puede suceder cuando concurren varias condiciones, describe esa interacción. Una fila demasiado amplia dificulta identificar qué diseño o control responde a qué riesgo; demasiadas filas duplicadas crean apariencia de exhaustividad sin mejorar el análisis.

En el ejemplo, supongamos que la revisión del diseño identifica una simulación ya ejecutada para determinada carga, pero no hay prueba que represente la condición ambiental que el equipo considera relevante. La simulación es evidencia del análisis bajo sus supuestos, no respuesta automática a todas las condiciones. El siguiente paso es comparar sus condiciones y límites con el requisito de uso, y decidir si los datos bastan o si se requiere otra evaluación.

No hay un umbral genérico que diga cuándo una simulación reemplaza una prueba.

Si el equipo propone cambiar el espesor del soporte, documenta la relación entre la medida y la hipótesis. ¿Qué modo intenta reducir? ¿Qué efectos secundarios puede introducir en peso, montaje o interfaz? ¿Qué análisis o prueba mostraría si el cambio cumple el requisito? El equipo de diseño y la autoridad aprobadora responden conforme al proceso real de la organización. El ejemplo no asigna puntuaciones ni declara aceptable el soporte.

Tras la decisión, la fila debe conservar qué quedó revisado y qué sigue pendiente. Si otra función del producto puede compartir la misma interfaz, anota si esa extensión se comprobó o solo se recomendó investigar. No uses «se revisó el soporte» como sinónimo de «se revisaron todas las referencias». El resultado vale para el diseño, versión y condiciones que realmente entraron en el análisis.

Prioridad y escalas sin un corte inventado

Comparar severidad, ocurrencia y detección solo sería un método Bosch específico si se declaran sus escalas; el lector no debe inferir un umbral de aceptación. Fuente: BOSCH-FMEA-BOOKLET-14; localizador: §3.4.4, p. 33. La decisión final debe seguir los criterios de diseño y aprobación aplicables al producto.

Bosch describe una metodología particular con términos y escalas de ese booklet. Si la organización adopta otro manual vigente o un criterio aprobado por cliente, debe seguir ese método concreto y registrar su edición y alcance. No combines una definición de una fuente con escalas de otra sin comprobar compatibilidad. La misma letra o nombre puede representar criterios distintos entre versiones y organizaciones.

Una puntuación resume entradas según reglas; no convierte una estimación cualitativa en una probabilidad estadística validada. Si se asignan categorías de severidad, ocurrencia y detección, explica qué significan, qué información las respalda y cómo se resuelven desacuerdos. El número resultante puede ordenar una conversación dentro del sistema escogido, pero no demuestra que el diseño sea aceptable o no aceptable por sí solo.

Antes de decidir acciones, revisa si hay obligaciones regulatorias, criterios de cliente o requisitos internos que aplican a la referencia. Un análisis FMEA no sustituye evaluaciones de seguridad, ensayos, análisis de cumplimiento ni autorizaciones necesarias. Si una puntuación parece baja pero el efecto potencial afecta una obligación importante, sigue el proceso especializado y escala la decisión a quien tenga autoridad.

Conectar hallazgos con decisiones de diseño

Una acción propuesta debería responder a un modo o causa descritos y especificar el resultado que se espera comprobar. «Mejorar el soporte» no permite revisar la decisión. «Cambiar la geometría para responder a la hipótesis de flexión y repetir el análisis bajo las condiciones acordadas» conecta medida, supuestos y evidencia; sigue siendo una propuesta hasta que ingeniería la evalúe y apruebe.

En el seguimiento, registra estado de la acción, dueño, versión del diseño afectada y evidencia de verificación. Si el cambio no se ejecutó, no borres la fila ni la marques resuelta porque se actualizó una presentación. Si se descartó la propuesta, conserva el motivo y la alternativa escogida. La trazabilidad debe llevar desde el modo de fallo hasta la disposición de diseño que cerró o mantuvo abierta la cuestión.

Una modificación puede generar nuevos modos de fallo o alterar las estimaciones de otras filas. Revisa las interfaces relacionadas antes de incorporar el cambio a la línea base. El análisis puede iterarse cuando se obtienen hechos nuevos, cuando cambia el diseño o cuando aparece un uso distinto. No existe aquí un plazo de actualización universal; la organización define cuándo reabre o revisa el análisis.

Una tabla es útil cuando permite reconstruir la decisión. ¿Qué parte del diseño se examinó? ¿Qué evidencia sustentó cada hipótesis? ¿Qué riesgo se aceptó, redujo o dejó pendiente y quién autorizó la disposición? Esas preguntas ayudan a detectar afirmaciones que el documento no respalda y a mantener la puntuación en su papel de apoyo al razonamiento.

Límites del método y de la fuente

La fuente es el booklet de Bosch; no se consultó una norma vigente AIAG/VDA/IEC/ISO que imponga una plantilla de Product FMEA. Fuente: BOSCH-FMEA-BOOKLET-14; localizador: edition/copyright page; §1.1. Atribuye el método a esa publicación y verifica por separado cualquier requisito aplicable a tu diseño.

El Booklet 14 es una metodología publicada por Bosch. Sus términos, tablas y puntuaciones deben atribuirse a esa publicación y a su edición; este artículo no los presenta como contenido vigente de AIAG/VDA, IEC, ISO, ley o requisito obligatorio. Tampoco se consultó una norma de FMEA distinta. Si un contrato, regulación, cliente o sistema de gestión exige un método, consulta ese texto específico y aplica la versión pertinente.

AMFE de producto y AMFE de proceso pueden compartir parte de la terminología, pero no cubren el mismo objeto. Este artículo se mantiene en el diseño de una referencia y utiliza un ejemplo hipotético. No proporciona un análisis de riesgo de un producto comercial, no certifica una revisión de seguridad y no demuestra que una fila particular esté completa.

Preguntas frecuentes

¿Qué es un AMFE de producto?

Es una forma estructurada de revisar modos potenciales de fallo de las partes e interfaces de un producto, junto con sus efectos, causas posibles y controles de diseño. Bosch describe esta distinción en su propio booklet; la elección del método concreto depende del contexto aplicable.

¿En qué se diferencia del AMFE de proceso?

El AMFE de producto examina el diseño de partes e interfaces; el de proceso examina operaciones de fabricación. Un problema de montaje puede requerir revisar el proceso, mientras que una interacción geométrica prevista en el diseño pertenece al análisis del producto.

¿El AMFE de producto demuestra que no habrá fallos?

No. El método estructura una revisión cualitativa, pero no demuestra que se hayan identificado todos los modos ni garantiza el comportamiento del producto. Las conclusiones dependen de la información, los límites y los controles examinados.

¿El número de prioridad define si un diseño se acepta?

No por sí solo. Si se usa una escala de severidad, ocurrencia y detección, identifica su método, reglas y contexto. No conviertas una puntuación aislada en umbral universal; la decisión debe seguir los criterios de diseño y aprobación aplicables.

¿Cuándo se prepara un AMFE de producto?

Cuando el equipo necesita estructurar una revisión de modos potenciales de fallo de un producto o diseño dentro del proceso que haya establecido. La fuente Bosch diferencia producto de proceso, pero no prescribe una etapa universal de aprobación para todas las organizaciones.