¿Qué es el Riesgo en Confiabilidad?
El riesgo no es sinónimo de peligro. Es una función de dos variables: la probabilidad de que ocurra un evento indeseable y el impacto de ese evento si ocurre.
Toda actividad organizacional involucra riesgos — algunos pequeños, otros de consecuencias que podrían afectar la supervivencia del negocio. Lo que distingue a un programa de gestión de riesgos maduro no es la ausencia de riesgos, sino la capacidad de identificarlos, cuantificarlos y actuar sobre ellos con decisiones informadas.
El riesgo es la probabilidad de que ocurra un evento indeseable y el impacto de ese evento al ocurrir.
El riesgo es la combinación de la probabilidad de ocurrencia de un daño y la severidad de ese daño.
El riesgo es un evento o condición incierta que, si ocurre, tiene un efecto sobre al menos un objetivo del proyecto.
Independientemente de la definición adoptada, el principio unificador es el mismo: la gestión de riesgos requiere considerar la combinación de probabilidad de ocurrencia e impacto de esa ocurrencia. El ingeniero de confiabilidad debe integrar formalmente este análisis en cada etapa del ciclo de vida del producto — no solo cuando algo ya salió mal.
La norma ISO 31000 (actualizada en 2009) establece los principios y directrices generales para la gestión de riesgos. Los registradores ISO han comenzado a enfatizar la gestión de riesgos como parte de sus prácticas de auditoría, haciendo de esta competencia un requisito creciente para los profesionales de calidad y confiabilidad.
El Proceso Continuo de Gestión de Riesgos
La gestión de riesgos no es un evento único — es un proceso iterativo con siete actividades interconectadas cuyo elemento más crítico es la comunicación.
El proceso de gestión de riesgos se aplica tanto a proyectos de desarrollo de productos como a decisiones de negocio de cualquier naturaleza: adquisición de equipos, cambios en flujos de trabajo, estrategias de precios o relocalización de operaciones. La decisión frecuentemente se reduce a la menor de dos exposiciones al riesgo: moverse demasiado rápido o no moverse con suficiente velocidad.
Fuente: CRE Primer, Quality Council of Indiana, Sección III — Risk Management.
Para proyectos o actividades mayores, un plan de mitigación de riesgos es el documento guía que orienta todo el proceso y registra el estado de las actividades de gestión. El plan de riesgo debe ser gestionado por un responsable de riesgos independiente de la actividad de diseño y su gerencia — esto garantiza la objetividad del análisis.
Tipos de Riesgo
Los riesgos de desempeño, costo y cronograma pueden segmentarse en cinco áreas primarias — pero la práctica real abarca categorías mucho más amplias que el ingeniero de confiabilidad debe conocer.
La práctica del CRE exige mantener una lista de verificación sistemática que obligue al ingeniero a considerar y evaluar múltiples categorías de riesgo en cada proyecto. Sin este proceso formal, el análisis queda a merced de lo que el equipo recuerda en ese momento.
Fuente: CRE Primer — Frank (2016), Nikonova (2008). Sección III, II.A.2.
Análisis de Árbol de Fallas (FTA)
El FTA es un método deductivo de arriba hacia abajo: parte de un evento indeseable ya definido (el "evento tope") y trabaja hacia atrás para encontrar todas las combinaciones de fallas que podrían causarlo.
El FTA es una metodología sistemática y deductiva que define un único evento indeseable específico y determina todas las razones posibles que podrían causar que ese evento ocurra. El evento indeseable constituye el evento tope del árbol y generalmente representa una falla catastrófica del producto.
A diferencia del FMEA — que predice la falla del producto a partir de la falla de componentes —, el FTA identifica qué partes son responsables de una falla de producto ya identificada. El FMEA es una técnica analítica cualitativa; el FTA puede ser una técnica cuantitativa.
Los símbolos del árbol de fallas se dividen en dos categorías: símbolos de eventos (evento tope, evento básico, evento no desarrollado, evento de entrada) y símbolos de compuertas lógicas (AND, OR, OR exclusivo, votación n de m). Las compuertas AND representan componentes en serie y se computan por la ley multiplicativa de probabilidades; las compuertas OR representan redundancia y se computan por la ley aditiva.
¿Cuándo usar FTA vs. FMEA?
- La seguridad del público, operadores o personal de mantenimiento es primordial
- Se puede identificar un número pequeño de "eventos tope" claramente diferenciados
- La evaluación cuantificada del riesgo es la preocupación principal
- Hay alto potencial de falla por errores humanos o de software
- La funcionalidad del producto es altamente compleja o interconectada
- El producto no es reparable una vez iniciado (sistemas espaciales)
- Los eventos tope no pueden ser definidos o limitados a un número pequeño
- Múltiples perfiles funcionales exitosos son factibles
- La identificación de "todos los modos de falla posibles" es importante
- El producto tiene poca intervención humana o de software
- Se requiere un análisis secuencial de todos los modos de falla del sistema
- La meta es la priorización de acciones correctivas de diseño y proceso
Fuente: CRE Primer — Reliability Toolkit (1993), Sección III, II.B.1.
Más allá de la evaluación inicial del diseño, el FTA puede usarse como herramienta de diagnóstico de campo una vez que el producto está disponible en el mercado. Sus aplicaciones adicionales incluyen: análisis funcional de sistemas complejos, evaluación de requisitos de seguridad, identificación de defectos de diseño potenciales, simplificación del mantenimiento y eliminación lógica de causas de falla observadas.
FMEA y FMECA — Análisis de Modos de Falla
El FMEA es la herramienta de confiabilidad más universalmente aplicada: un método sistemático para identificar todos los modos de falla potenciales de un sistema, sus efectos sobre el sistema y la probabilidad de que ocurran.
Un FMEA provee al ingeniero de diseño o confiabilidad una técnica sistemática para analizar un sistema, subsistema o componente con respecto a todos los modos de falla potenciales. El método asigna una probabilidad de que el modo de falla realmente ocurra, y evalúa el efecto de esa falla sobre el resto del sistema.
La adición de la porción de criticidad al análisis — que permite asignar un valor o calificación a la criticidad del efecto de la falla sobre el sistema completo — convierte el FMEA en un FMECA. Cuando se omite la criticidad, el análisis se denomina simplemente FMEA.
Los máximos beneficios del FMEA / FMECA se obtienen en etapas tempranas del ciclo de diseño, antes de que el diseño quede finalizado — cuando los cambios son menos costosos y más efectivos.
El Número de Prioridad de Riesgo (RPN)
Escala 1–10 (1 = improbable, 10 = casi seguro)
Escala 1–10 (1 = imperceptible, 10 = riesgo de seguridad)
Escala 1–10 (1 = detección segura, 10 = indetectable)
Las acciones correctivas se priorizan comenzando por los RPNs más altos y los problemas de seguridad más críticos. Una vez implementadas las acciones, se recalcula el RPN revisado para confirmar la reducción del riesgo. Es importante recordar que un RPN alto puede resultar de diferentes combinaciones de P, S y D — un valor de Severidad extremo (por ejemplo, S = 10, riesgo para la vida) debe recibir atención prioritaria independientemente del RPN resultante.
Tipos de FMEA
Un FMEA riguroso debe responder: ¿La descripción del sistema es compatible con su especificación? ¿Los diagramas de bloque muestran dependencias funcionales en todos los niveles? ¿Las fuentes de datos de modos de falla están descritas? ¿Las clasificaciones de severidad están provistas? ¿Los resultados se usan para mejorar otras decisiones del programa? ¿Las acciones recomendadas son claras y tienen responsable asignado?
Categorías de Severidad — MIL-STD-1629A
| Clase | Categoría | Descripción |
|---|---|---|
| I | Catastrófica | Una falla que puede causar muerte o pérdida de misión |
| II | Crítica | Una falla que puede causar lesiones severas o daño mayor al sistema |
| III | Marginal | Una falla que puede causar lesiones menores o degradación en el desempeño de la misión |
| IV | Menor | Una falla que no causa lesiones ni daño al sistema, pero puede resultar en falla del sistema y mantenimiento no programado |
Fuente: MIL-STD-1629A (1980) — Procedures for Performing a Failure Mode, Effects and Criticality Analysis. Citado en CRE Primer Sección III.
Análisis de Fallas de Modo Común
Una falla de modo común ocurre cuando un solo evento provoca la falla simultánea de múltiples sistemas — invalidando el beneficio de la redundancia incorporada al diseño.
Las fallas de modo común resultan cuando los eventos en un sistema no son estadísticamente independientes: un evento puede causar la falla de sistemas simples o múltiples. La identificación y análisis del potencial de fallas de modo común es crítica en sistemas de alta confiabilidad, porque la redundancia añadida a esos sistemas puede quedar anulada cuando un componente temprano en la cadena es propenso a fallar.
Ejemplos típicos de fallas de modo común:
- →Sistemas de sensores que no detectan la falla de un componente
- →Mecanismos de conmutación para unidades redundantes que fallan
- →Sistemas comunes de energía o combustible que fallan (afectando todos los subsistemas)
- →Componentes de software comunes a varios sistemas que fallan
- →Acciones de mantenimiento (o su omisión) que causan falla
- →Indicadores del sistema que no alertan al personal operativo
- →Una falla que causa aumento de carga en el sistema y fallas en cascada aguas abajo
- →Acciones humanas que causan falla en múltiples rutas del sistema
Los eventos habilitadores no son fallas del sistema en sí mismos, pero pueden crear fallas de modo común. Ejemplos: sistemas de advertencia desactivados para mantenimiento, controles de operación configurados incorrectamente, personal no siguiendo procedimientos, o elementos del sistema en espera desactivados por cualquier razón. El mantenimiento y las acciones del operador son frecuentemente los principales contribuyentes a las fallas de modo común.
"A menudo, como en los accidentes aéreos, puede haber una serie de eventos inesperados que resultan en una falla dramática del sistema. La falla de modo común requiere conocimiento práctico y experiencia por parte del ingeniero diseñador."— CRE Primer, Quality Council of Indiana — Sección III, Análisis de Falla de Modo Común
Análisis de Peligros (Hazard Analysis)
El análisis de peligros es un proceso que contextualiza el riesgo: identifica dónde ocurre, qué objeto está en riesgo, qué factores contribuyen y cuál es la naturaleza del peligro.
El propósito de la identificación de peligros es mostrar el contexto del peligro potencial. Este contexto incluye: identificar la fase del perfil de misión (el dónde), el componente involucrado (el qué), el objeto en riesgo (el quién), los factores contribuyentes y la naturaleza del peligro.
Para organizar un resumen de riesgos, el CRE Primer recomienda seleccionar un enfoque primario entre: el perfil de misión (secuencia de eventos que el producto experimenta desde concepto hasta disposición) o la lista de materiales (BOM). El método de perfil de misión es sugerido para análisis de sistemas, pues permite a los equipos enfocarse en los peligros específicos de cada fase operacional.
El perfil de misión abarca eventos que van desde la adquisición y recepción del componente, pasando por almacenamiento, ensamble, prueba, empaque y envío, hasta instalación, operación, mantenimiento, reparación, desmantelamiento y disposición. Cada una de estas fases puede generar peligros distintos que deben ser evaluados sistemáticamente.
Calificación del peligro
Una vez identificados los peligros, deben ser calificados considerando dos dimensiones: frecuencia (qué tan probable es que el peligro ocurra) y severidad (cuán dañino sería si ocurriera). Para llegar al nivel de peligro, se multiplican los valores de frecuencia y severidad, o se combinan en una matriz.
| Frecuencia → | Catastrófica | Crítica | Marginal | Menor |
|---|---|---|---|---|
| Frecuente | I — Intolerable | I — Intolerable | I — Intolerable | II — Indeseable |
| Probable | I — Intolerable | I — Intolerable | II — Indeseable | II — Indeseable |
| Ocasional | I — Intolerable | II — Indeseable | II — Indeseable | III — Aceptable* |
| Remoto | II — Indeseable | III — Aceptable* | III — Aceptable* | IV — Negligible |
| Improbable | III — Aceptable* | III — Aceptable* | IV — Negligible | IV — Negligible |
| Increíble | IV — Negligible | IV — Negligible | IV — Negligible | IV — Negligible |
* Aceptable si representa el estado del arte, o si es un riesgo residual asociado a la reducción de riesgo. Fuente: CRE Primer Sección III, II.B.4 — Tabla 3.22.
Métodos adicionales de evaluación de riesgos
El CRE Primer documenta varios métodos complementarios de evaluación de riesgos que el ingeniero puede combinar para obtener una visión más completa:
Matriz de Riesgo e Integración con el Proceso de Diseño
Un programa efectivo de gestión de riesgos se integra con las fases del proceso de diseño desde el inicio — no como auditoría final, sino como proceso paralelo a toda la actividad de desarrollo.
Los programas de análisis de riesgos se establecen para permitir a las empresas tomar decisiones informadas. El riesgo aceptable es aquel que: 1) es menor o igual al riesgo máximo tolerable, y 2) es tan bajo como razonablemente sea práctico. Todo programa de gestión de riesgos exitoso requiere soporte de la alta dirección.
¿Qué puede salir mal? → Identificación del peligro. | ¿Qué tan frecuente y cuán dañino es? → Calificación del peligro. | ¿Qué puede hacerse para prevenirlo? → Control del peligro. Para productos simples, este proceso de tres pasos puede ser totalmente adecuado. Para productos complejos con perfiles de misión extensos, se requiere una metodología más sofisticada.
El responsable de riesgos debe ser independiente de la actividad de diseño y su gerencia para mantener la objetividad del proceso. Las revisiones de diseño al final de cada fase son el vehículo natural para revisar y actualizar el resumen de riesgos correspondiente a esa fase.
Seguridad del Sistema (System Safety)
La seguridad del sistema no es un atributo que se inspecciona al final — es el resultado de diseñar intencionalmente la seguridad en el producto desde sus primeras etapas conceptuales.
El análisis de seguridad relacionado con datos de retroalimentación de clientes, datos de diseño y datos de campo debe ser recolectado, analizado y utilizado para mejorar la seguridad del producto para el usuario final o el público en general. Cualquier sistema de análisis y retroalimentación de datos de confiabilidad debe abarcar todas las fases del ciclo de vida del producto.
El CRE Primer establece que ante cada ocurrencia de falla deben registrarse: fecha y hora de la falla; condiciones operacionales y ambientales al momento de la falla; descripción del modo de falla y su efecto sobre el sistema; acciones para reparar la falla; tiempo de operación activo del equipo; nivel de clasificación del operador; determinación inicial de causa de falla; análisis formal de falla; acción correctiva recomendada; implementación y seguimiento de la acción correctiva.
Diseñando, ensamblando y entregando seguridad
La seguridad del sistema se evalúa mediante estándares desarrollados por organizaciones como UL, ANSI, IEC e ISO. Los laboratorios de prueba reconocidos nacionalmente (NRTL), como Underwriters Laboratories (UL), ETL y TÜV, prueban productos de forma independiente y objetiva para certificar su nivel básico de seguridad. El proceso de conformidad de seguridad del producto comprende tres pasos: evaluación de componentes, evaluación de la aplicación de componentes y evaluación global del sistema, y vigilancia continua de la manufactura.
La tabla de actividades de seguridad por fase de diseño del CRE Primer muestra que la seguridad no es un paso final: desde el análisis de concepto (revisión de historial de fallas de partes, FMEA conceptual, factores humanos) hasta manufactura e instalación (PPAP/APQP, FMEA de proceso, entrenamiento sobre riesgo residual), pasando por especificación del sistema, desarrollo de subsistemas y pruebas de validación.
Mitigación de Riesgos
El objetivo final de toda la cadena de identificación y análisis de riesgos es llevar los riesgos a niveles aceptables. La mitigación define las prioridades y las acciones para lograrlo.
Para ser efectiva, la reducción del riesgo debe dirigirse a la causa del peligro — no solo a sus síntomas. El CRE Primer establece una jerarquía explícita de prioridades para las actividades de control de riesgo:
-
P1Diseños inherentemente seguros. La primera y mejor opción para el control del riesgo es eliminar el riesgo del producto diseñando la condición peligrosa fuera del producto. Este es el control más robusto porque no depende del comportamiento humano ni de dispositivos adicionales.
-
P2Medidas de protección, incluyendo alarmas. Cuando el peligro no puede ser eliminado por diseño, la siguiente opción es interponer obstáculos entre el usuario y el peligro, o anunciar condiciones peligrosas mediante alarmas, interlocks, guardas físicas o señales automatizadas.
-
P3Información al usuario sobre el riesgo residual. Cuando no es posible eliminar ni proteger contra el peligro, el usuario debe ser informado sobre el riesgo residual existente. Es responsabilidad de toda la cadena de suministro (diseñador, fabricante, almacenador, distribuidor) comunicar cualquier riesgo residual conocido.
Las actividades de control de peligros comprenden un amplio espectro de mecanismos que el ingeniero puede implementar:
Riesgo y responsabilidad civil
Un único juicio por responsabilidad civil puede arruinar una empresa. Esta es la razón por la que muchas organizaciones involucran profesionales legales y de seguridad de productos a lo largo de todo el proceso de desarrollo. Cuando se compara con el costo de la litigación costosa y los juicios de daños punitivos, el costo de un programa de seguridad de productos se convierte en una póliza de seguro razonablemente priced.
A menudo los usuarios buscan daños por responsabilidad porque un producto crea un riesgo que la empresa no pudo predecir durante el diseño y manufactura. Estos litigios son exitosos porque la empresa tiene la responsabilidad de advertir a los usuarios sobre peligros descubiertos después de la venta. La trazabilidad del producto ayuda a la empresa a localizar productos en manos del usuario para proporcionar información adicional de seguridad o ejecutar un retiro de mercado.
La Gestión de Riesgos como Ventaja Competitiva
La gestión de riesgos no es una obligación regulatoria — es el mecanismo por el cual la organización convierte la incertidumbre en decisiones de diseño superiores y productos más seguros.
El Dominio II del BoK del CRE — Gestión de Riesgos — integra un conjunto de herramientas complementarias que operan a diferentes niveles de abstracción: el FTA para razonar hacia las causas de fallas catastróficas específicas, el FMEA para catalogar sistemáticamente todos los modos de falla posibles, el análisis de modo común para identificar vulnerabilidades sistémicas en diseños redundantes, el análisis de peligros para contextualizar el riesgo en el perfil de uso real, y la matriz de riesgo para priorizar la acción.
Ninguna de estas herramientas opera en aislamiento — su valor máximo se obtiene cuando forman parte de un programa de gestión de riesgos integrado con las fases del proceso de diseño, liderado por un responsable de riesgos independiente, y respaldado por la comunicación continua como elemento central de todo el proceso.
"El riesgo aceptable es aquel que es menor o igual al máximo riesgo tolerable, y tan bajo como sea razonablemente práctico. Un programa de gestión de riesgos solo puede tener éxito con el apoyo de la dirección."— CRE Primer, Quality Council of Indiana — Sección III, Risk Management
La Gestión de Riesgos (Dominio II) del BoK 2025 comprende tres grandes subdominios: A — Identificación (técnicas de gestión de riesgos y tipos de riesgo), B — Análisis (FTA, FMEA, falla de modo común, análisis de peligros, matriz de riesgo y seguridad del sistema), y C — Mitigación. Este dominio es uno de los de mayor peso en el examen CRE dada su aplicabilidad transversal a todas las industrias y fases del ciclo de vida del producto.