ISO 14224 ofrece una base para recopilar e intercambiar datos de confiabilidad y mantenimiento en un formato estandarizado. Su alcance oficial cubre las industrias del petróleo, petroquímica y gas natural. La norma organiza un lenguaje común para la experiencia operativa y trata categorías de datos de equipo, falla y mantenimiento, además de prácticas de calidad. No convierte registros incompletos en análisis confiable ni sustituye la gobernanza técnica de la empresa.
La aplicación práctica muestra cómo conducir un proyecto de datos inspirado en el objetivo público de ISO 14224 sin reproducir tablas, códigos ni contenido protegido de la norma. Para declarar conformidad, interpretar un requisito o implantar la norma en su alcance, la organización debe consultar la edición vigente con licencia, definir aplicabilidad e involucrar a profesionales competentes.
El problema que resuelve la estandarización
Una planta puede tener miles de notificaciones y seguir sin poder comparar fallas. Un turno registra síntoma, otro registra componente y otro escribe una acción en el campo de causa. Bomba, conjunto de bombeo y sistema de transferencia aparecen como si fueran el mismo nivel. La indisponibilidad empieza al abrir la notificación en un área y al perder la función en otra. El volumen parece grande, pero la población no es coherente.
La estandarización crea tres condiciones. Primero, cada registro queda asociado a un objeto técnico y a un nivel jerárquico definido. Segundo, modo, mecanismo, causa, consecuencia y acción tienen significados distintos. Tercero, tiempos y exposición siguen reglas documentadas. El resultado forma un conjunto reconciliable, comparable y auditable.
Qué permite afirmar la página oficial de ISO
La página oficial identifica ISO 14224:2016 como la tercera edición publicada y la muestra confirmada en su ciclo de revisión. El resumen público describe una base para datos de confiabilidad y mantenimiento durante la vida operativa. Identifica tres grandes categorías: datos de equipo, datos de falla y datos de mantenimiento. También nombra usos en confiabilidad, disponibilidad, mantenimiento, seguridad y ambiente.
El resumen también limita el alcance. Costos directos, fichas técnicas completas, ensayos de laboratorio y métodos completos de análisis no son el foco central declarado. Esa frontera importa. Un vocabulario de fallas no significa que la norma entregue por sí sola un modelo económico, una RCFA o una estrategia de mantenimiento.
Arquitectura mínima de un proyecto de datos
1. Gobernanza
Defina patrocinador, dueño del dato, administradores de catálogo, especialistas por clase y rutina de revisión. El dueño del sistema no decide solo el significado técnico. Un cambio en término, obligatoriedad o regla temporal necesita versión, justificación y fecha de vigencia.
2. Frontera del equipo
Declare dónde se acumula cada evento. Una jerarquía puede incluir instalación, unidad, sistema, equipo e ítem mantenible según el modelo de la empresa. El objetivo es impedir que el mismo evento se asigne unas veces al sistema y otras al componente sin una regla.
3. Diccionario de fallas
Separe función requerida, falla funcional, modo observado, mecanismo, causa y efecto. El modo describe cómo se perdió o degradó la función. El mecanismo describe el proceso físico. La causa explica la condición que inició o permitió el mecanismo cuando existe evidencia. El efecto registra lo observado o producido. Lo desconocido sigue desconocido.
4. Datos de mantenimiento
Registre tipo de trabajo, acción, elemento sustituido, recurso, inicio y fin bajo los hitos seleccionados y condición posterior. La orden muestra lo ejecutado. No debe recibir una causa confirmada solamente porque se cambió una pieza.
5. Calidad y reconciliación
Mida completitud, validez, consistencia, oportunidad, unicidad y trazabilidad. Un registro completo puede estar técnicamente equivocado. La muestra debe volver a notificación, orden, medición y evidencia de campo.
Método de implantación en diez pasos
- Defina el uso. Elija una decisión concreta, como comparar recurrencia por clase o revisar un plan.
- Delimite la población. Fije clases, ubicaciones, período, estado y exposición.
- Mapee campos actuales. Localice dónde se registran equipo, falla, acción, tiempo y consecuencia.
- Diagnostique calidad. Cuente vacíos, texto libre, duplicados, niveles mezclados y tiempos imposibles.
- Cree un diccionario interno. Defina términos, ejemplos, exclusiones y responsables sin copiar contenido protegido.
- Construya un mapeo. Relacione campo actual, significado interno y destino futuro.
- Configure y pruebe. Aplique el diseño a una clase piloto y conserve valores brutos para auditoría.
- Capacite mediante casos. Pida clasificar registros reales anonimizados y explicar las decisiones.
- Revise divergencias. Ajuste catálogo, interfaz o regla cuando especialistas clasifiquen el mismo evento de modo distinto.
- Escale con control. Publique versión, monitoree calidad e impida cambios sin gobernanza.
Caso resuelto: compresores K-301
Todos los números y registros del caso son didácticos. No representan cliente, benchmark, requisito ISO ni desempeño de PM Run. Una unidad posee cinco compresores equivalentes. Ingeniería quería comparar fallas que retiraban capacidad, pero los registros mezclaban síntomas, componentes y acciones.
Premisas del piloto
| Elemento | Definición interna del caso |
|---|---|
| Clase piloto | Cinco compresores centrífugos equivalentes |
| Ventana histórica | 1 de enero a 30 de junio de 2026 |
| Exposición máxima de calendario | 21.720 horas, calculadas como 5 compresores × 181 días × 24 h |
| Horas fuera del estado elegible | 3.480 horas de paradas planificadas, indisponibilidad de los eventos y otros períodos excluidos por la regla del piloto |
| Exposición acumulada | 18.240 horas en estado elegible |
| Evento incluido | Pérdida o degradación de función de compresión más allá del límite interno |
| Evento excluido | Parada planificada y orden sin pérdida de función |
| Fuente | Notificación, orden, historial de proceso y medición reconciliados |
| Unidad temporal | Horas, con zona y hito definidos |
El diagnóstico encontró 27 registros relacionados. Después de reconciliar duplicados y alcance, siete eran eventos funcionales. Nueve eran órdenes planificadas, seis eran notificaciones duplicadas y cinco describían anomalías sin pérdida de función. No se borró ningún registro. Cada exclusión recibió motivo y vínculo con el original.
La exposición se reconcilió desde el máximo físico de 21.720 horas de calendario. La exclusión documentada de 3.480 horas dejó 18.240 horas en estado elegible. Los siete eventos sumaron 26,6 horas de indisponibilidad, con un promedio de 3,8 horas por evento. La tasa descriptiva fue 7 ÷ 18.240 × 1.000 = 0,384 evento por 1.000 horas elegibles. Con solo siete eventos y mecanismos diferentes, esa tasa no sustentó una comparación causal ni un cambio de estrategia; la decisión se mantuvo basada en la separación semántica y la evidencia de cada evento.
Antes de estandarizar
| Texto bruto | Campo usado | Problema |
|---|---|---|
| Vibración alta | Causa | Síntoma registrado como causa |
| Rodamiento cambiado | Descripción de falla | Acción registrada como falla |
| Trip | Texto largo | Efecto sin función ni objeto detallado |
| Falla mecánica | Modo | Categoría demasiado amplia |
| Normalizado | Causa | Resultado del trabajo sin mecanismo |
Diccionario interno del piloto
El equipo no intentó copiar una taxonomía normativa. Creó definiciones internas y registró que la implantación formal dependía de la norma con licencia. Para el piloto, la función era comprimir gas dentro del rango definido. La falla funcional era incapacidad para mantener caudal o presión. El modo era la forma observada de pérdida. El mecanismo era el proceso físico sustentado por evidencia. La causa quedaba sin confirmar cuando no había investigación.
| ID didáctico | Modo observado | Mecanismo sustentado | Causa | Acción | Indisponibilidad |
|---|---|---|---|---|---|
| E01 | Parada de protección | Degradación de rodamiento | Lubricación fuera del parámetro interno | Sustituir y revisar tarea | 6,2 h |
| E02 | Caudal bajo | Depósito en etapa | Contaminante en investigación | Limpiar y tomar muestra | 4,5 h |
| E03 | Fuga externa | Degradación de sello | No confirmada | Contener, sustituir y abrir RCFA | 3,8 h |
| E04 | Parada de protección | Falla de instrumentación confirmada | Conexión degradada | Reparar conexión y probar | 1,7 h |
| E05 | Presión inestable | Mecanismo no confirmado | No confirmada | Recopilar datos adicionales | 2,1 h |
| E06 | Arranque indisponible | Interbloqueo actuado | Condición de proceso válida | Restaurar condición | 0,9 h |
| E07 | Caudal bajo | Holgura interna confirmada | Desgaste acumulado | Reparar y revisar límite | 7,4 h |
La tabla es un modelo didáctico original. No representa códigos, estructura obligatoria ni taxonomía ISO 14224. Su papel es mostrar la separación semántica. El equipo conservó el texto bruto junto al término controlado para que un especialista pudiera auditar la transformación.
Decisión producida
El piloto mostró que parada de protección no era una familia causal. E01 y E04 compartían efecto de parada, pero tenían mecanismos y acciones distintos. Sumarlos como una causa crearía una prioridad falsa. La decisión fue revisar el plan de lubricación para la familia de rodamientos, abrir investigación para el sello sin causa y mantener la falla de instrumentación en una línea propia.
También se decidió que modo y efecto fueran obligatorios en la notificación para esta clase. Mecanismo y causa podían quedar sin confirmar. Completar después exigiría evidencia y un rol autorizado. Esa regla protege el historial contra certeza inventada.
Salida hacia SAP PM
En la arquitectura del caso, equipo y ubicación técnica establecen la dirección. La notificación recibe condición, avería, modo, efecto, método de detección y fechas según configuración. La orden registra operaciones, materiales, tiempo y acción ejecutada. Mediciones y anexos permitidos sustentan evidencia. Los catálogos organizan el lenguaje y el texto técnico preserva contexto.
La documentación oficial de SAP describe datos de falla en notificaciones, incluidos modo, efecto y método de detección en escenarios compatibles. La organización debe verificar versión, proceso y Customizing. La norma no determina automáticamente cómo implementar cada campo en el SAP de una empresa.
PM Run puede apoyar movilidad, planificación, ejecución y retorno de datos sobre SAP PM. No ofrece una taxonomía ISO lista, no declara conformidad ni sustituye la gobernanza de datos maestros. SAP sigue como sistema de registro.
Indicadores y ventana de verificación
El piloto se evaluó durante 180 días y al menos 30 eventos o anomalías clasificables. Se usaría el criterio mayor. Indicadores:
- completitud de los campos del piloto;
- porcentaje no clasificado, seguido sin redistribución artificial;
- acuerdo entre dos especialistas en una muestra;
- duplicidad de eventos después de reconciliar;
- tiempo desde detección hasta notificación formal;
- porcentaje de registros trazables hasta orden y evidencia;
- eventos por exposición solamente después de validar población.
En el ejercicio, la completitud inicial era 46%. Los criterios internos fueron al menos 95%, no clasificado por debajo de 5% sin forzar clasificación, duplicados por debajo de 2% y 100% de trazabilidad de la muestra. Son metas didácticas, no requisitos ISO ni benchmarks.
Cómo elegir la disciplina adecuada
ISO 14224 orienta estructura y calidad del dato dentro de su alcance. La ingeniería de confiabilidad integra decisiones y estrategia. FMEA anticipa modos y efectos. RCFA investiga un evento ocurrido. MTBF resume una población definida. Cada disciplina responde una pregunta diferente y puede usar el mismo historial gobernado.
Límites
- El alcance oficial de ISO 14224 es sectorial y debe respetarse.
- Usarla en otro sector puede orientar diseño, pero no crea conformidad automática.
- El resumen público no sustituye el acceso a la norma con licencia.
- Una taxonomía sin gobernanza de revisión solamente estandariza error.
- Un campo obligatorio puede aumentar llenado y reducir calidad si la definición es débil.
- Comparar plantas exige poblaciones, exposición y reglas equivalentes.
Control de calidad antes del análisis
El piloto K-301 estableció cuatro comprobaciones antes de calcular cualquier indicador. La primera confirmó que equipo, posición y período operativo formaban una población coherente. La segunda buscó registros duplicados del mismo evento mediante proximidad temporal, objeto técnico y descripción. La tercera comprobó la secuencia entre detección, parada, inicio y retorno. La cuarta comparó el término controlado con el texto original y la evidencia adjunta.
Los registros rechazados no se borraron ni se forzaron hacia una clase conveniente. Recibieron un estado de calidad, motivo y responsable de corrección. Esa cola separó carencias de datos maestros, desacuerdo semántico y ausencia real de información. La completitud pasó a medir campos utilizables y no cualquier campo con contenido.
Muestra de concordancia
Dos especialistas clasificaron de forma independiente diez registros del piloto. Ocho tuvieron concordancia total, uno divergió entre efecto y modo, y uno quedó inconcluso por evidencia insuficiente. La revisión conjunta corrigió la definición interna, conservó el estado inconcluso y agregó un ejemplo para entrenamiento. La meta de concordancia se aplicaría después de esa calibración.
Este control reduce un riesgo frecuente: gráficos coherentes construidos con significados diferentes. Antes de comparar unidades, la empresa debe demostrar que las personas reconocen el mismo evento, aplican la misma frontera temporal y conservan el estado desconocido cuando la evidencia no permite clasificar.
Control de cambios de taxonomía y mapeo
El piloto asignó un propietario a cada definición, entrada de catálogo y mapeo de SAP. Una propuesta de cambio debía indicar motivo, registros afectados, fecha de vigencia, regla de migración y aprobación. Los registros existentes no se reescribían silenciosamente porque eso cambiaría la serie histórica sin trazabilidad.
El versionado también cubrió la lógica de extracción. Si un informe trataba un disparo como evento y otro lo unía con una reducción previa, las tasas dejaban de ser comparables. El diccionario registró reglas de inclusión, fuente de exposición, unidades, tratamiento de nulos y versión de consulta. Una nota identificaba cualquier ruptura de serie.
Referencias oficiales
- ISO 14224:2016, página oficial y resumen público, consultada el 23/08/2026.
- ISO/TC 67/WG 4, Reliability Engineering and Technology, consultada el 23/08/2026.
- SAP Help Portal, Failure Data, consultada el 23/08/2026.
Preguntas frecuentes
¿ISO 14224 sirve para cualquier industria?
El alcance oficial comprende petróleo, petroquímica y gas natural. Otras operaciones pueden estudiar sus principios, pero no deben declarar conformidad automática. Se deben revisar aplicabilidad, licencia, requisitos internos y normas del sector correspondiente.
¿La norma ofrece todos los códigos de SAP PM?
La norma y el sistema tienen papeles distintos. La organización debe diseñar el mapeo entre su taxonomía con licencia, proceso y configuración SAP. Copiar términos sin definir uso, nivel y gobernanza no crea datos comparables.
¿Toda notificación necesita una causa?
No se debe inventar causa para llenar un campo. Síntoma, modo, efecto, mecanismo y causa tienen significados distintos. Cuando la causa no se confirmó, el estado desconocido debe mantenerse y puede disparar una investigación según criticidad.
Para conectar ejecución, planificación y retorno de campo con SAP PM, conozca la capa operativa de PM Run. Taxonomía, conformidad y decisiones de ingeniería siguen bajo responsabilidad de la empresa.
