Parte de avería: qué registrar al detectar un fallo

El primer registro no tiene que resolver la avería

Un parte de avería cumple una función concreta: dejar constancia de que alguien ha detectado una condición que merece atención y aportar suficientes datos para que otra persona pueda orientarse. Su valor está en la precisión de la observación, no en que quien lo abre adivine por qué ocurrió. Una prueba sencilla consiste en imaginar que el aviso lo recibe otro turno: ¿puede identificar el activo, ubicar el síntoma y entender qué dato falta?

Conviene separar tres capas. La primera es el hecho observado: “se ve una gota bajo la unión”, “la pantalla muestra código E17” o “el motor no arranca al pulsar marcha”. La segunda es el contexto: hora, zona, condición de operación, alarma relacionada o cambio reciente que la persona conozca. La tercera es una posible explicación: “podría haber una junta dañada”. Esa última frase puede ser útil si se marca como hipótesis, pero no debe ocupar el lugar del hecho.

Una fuga observada y una junta defectuosa no son la misma afirmación: la primera describe lo que se vio; la segunda atribuye un mecanismo que requiere comprobación.

Si después se descubre que el líquido venía de una limpieza o de un equipo vecino, la observación sigue siendo válida. En cambio, escribir “junta rota” como un hecho puede orientar la revisión hacia una causa todavía no comprobada.

Qué campos resuelven preguntas inmediatas

El apéndice D de NPR 8831.2F de NASA presenta formularios de ejemplo y dice que deben responder a las necesidades de sus usuarios, las capacidades del CMMS y otros sistemas de automatización (línea 142). NASA NPR 8831.2F, apéndice D, línea 142 En D.1.2 recomienda fecha y hora de recepción, número único, ubicación, prioridad, contacto, título, descripción y otros datos, pero aclara que no todos deben repetirse si ya constan en el CMMS o pueden obtenerse de otros datos (líneas 154–202).

NASA NPR 8831.2F, D.1.2, líneas 154–202

Al llevar esta lista a una plantilla, revisa qué campos ya completa el CMMS. Copiar manualmente un valor en dos sitios puede dejar registros distintos tras una actualización; cuando el sistema lo permita, enlaza con la ficha existente. Es una decisión de diseño, no una función que NASA garantice. El número identifica cada ticket; NASA señala que el código de barras puede agilizar la entrada y reducir errores.

El título puede incluir palabras de búsqueda, mientras que comentarios, materiales utilizados, taller, horas y mecánico describen el trabajo realizado. Es un ejemplo institucional de NASA, no un formulario normativo para una planta española.

La lista se entiende mejor si se traduce a las preguntas de quien recibe el aviso:

La tabla es una propuesta de lectura, no una transcripción de un formulario obligatorio.

En el ejemplo de NASA, un contacto y un teléfono correctos permiten que el taller pida aclaraciones; quien recibe el trabajo asigna la prioridad según la escala del centro. Son funciones del formulario descrito, no un reparto universal de tareas. NASA NPR 8831.2F, apéndice D.1.3, línea 241

Conviene distinguir el número único del ticket y la identificación del activo. El primero permite seguir el aviso dentro del sistema; la segunda ayuda a localizar el equipo. NASA los trata como datos distintos en su ejemplo. Si falta la referencia del activo, una ubicación concreta puede orientar la consulta, pero no sustituye una identificación confirmada. El campo de prioridad también depende de la escala que use cada planta: el artículo no establece niveles ni criterios para asignarlos.

En el caso hipotético, el título “equipo averiado” aporta poca orientación. “Vibración perceptible en carcasa al arrancar” nombra una condición y un momento sin atribuir una causa. Si se dispone de la etiqueta del activo, añádela a una ubicación que el siguiente turno reconozca. Cuando la zona tenga nombres locales, incluir ambos términos puede facilitar la búsqueda sin crear un identificador nuevo.

La fecha y hora deben reflejar cuándo se recibió o detectó el aviso según el sistema utilizado. No mezcles la hora de recepción con el inicio estimado del síntoma: si se conocen ambas, anótalas por separado y marca como aproximada la que no se haya confirmado. NASA define la fecha y hora de su ejemplo como las de recepción en el centro de trabajo; el equipo debe aclarar qué evento registra su propio campo.

Por ejemplo: “recibido a las 09:20; el turno anterior sitúa el inicio sobre las 08:50”.

La ubicación debería permitir llegar al punto sin depender del recuerdo de quien reporta. “Planta” puede ser demasiado amplia; “cerca del transportador azul” puede orientar, pero conviene acompañarla de la zona o el activo cuando se conozca.

Cómo describir un síntoma sin convertirlo en diagnóstico

Para que otro turno pueda contrastar el aviso, describe qué ocurrió, sobre qué elemento y en qué momento. “Gotea bajo la brida durante el ciclo de lavado” es más informativo que “bomba defectuosa”. “La pantalla mostró E17 a las 09:20” es más comprobable que “fallo eléctrico”. Si el aviso usa una señal acústica o visual, indicar qué señal apareció resulta más útil que traducirla de inmediato a un modo de fallo no confirmado.

Repetición y certeza son cosas distintas. “Ocurrió tres veces durante este turno” comunica una repetición observada; “falla siempre” puede ser una generalización basada en pocos episodios. Si el sistema permite añadir comentarios, se puede apuntar la base: tres arranques observados, una lectura en una pantalla, una alarma registrada o una nota del relevo. La intención no es crear un expediente de investigación en el parte, sino que otra persona pueda comprender de dónde sale la descripción.

Un ejemplo hipotético muestra la diferencia:

• Observación: “El ventilador no arrancó al pulsar el mando local a las 09:20”.
• Contexto conocido: “El indicador de disponibilidad estaba encendido; no se dispone de lectura eléctrica”.
• Hipótesis inicial, pendiente: “Posible problema de mando o alimentación”.

La hipótesis deja abiertas varias explicaciones y señala qué dato falta. No indica que la persona que reporta haya probado el circuito. Si alguien sí realizó una comprobación permitida por sus funciones, el parte puede describirla sin transformarla en instrucción para otros: qué se observó, quién lo hizo y cuándo. Las acciones que requieren competencia, procedimiento o permiso deben permanecer en sus canales aprobados; la plantilla del parte no sustituye esas reglas.

La misma lógica sirve cuando el resultado solicitado es más claro que el síntoma. El ejemplo de NASA admite que el campo inicial describa el problema observado o el resultado deseado. NASA NPR 8831.2F, apéndice D.1.3, línea 241 Eso permite una frase como “la puerta de la sala no cierra” o “se solicita ajustar el cierre”, pero la segunda formulación debe leerse como petición, no como diagnóstico de que el mecanismo necesita ajuste.

El registro puede mantener separados “situación comunicada” y “resultado solicitado”.

Aviso, investigación y acción correctiva son niveles diferentes

El informe de evaluación FRACAS de BSEE distingue sistemas de reporte que se limitan a notificar un fallo de otros que incorporan un proceso iterativo de acciones correctivas. BSEE, Failure Reporting Task 3, §5.2 En el modelo más básico, se identifica y comunica el incidente. El proceso más amplio añade investigación, mitigación, análisis y evaluación continuada.

Esta comparación se presenta en §5.2, páginas impresas 96–97 (PDF 112–113), dentro de un informe estadounidense sobre sistemas de reporte, con atención al ámbito offshore. No define el procedimiento de toda empresa ni convierte cada parte en una investigación formal.

El recorrido puede tener varios momentos:

1. Aviso: una persona registra la condición que observó.
2. Evaluación inicial: quien recibe el caso decide qué información adicional hace falta y qué prioridad local corresponde.
3. Investigación: cuando el caso lo requiere, se contrastan causas posibles con evidencia.
4. Acción: se decide y ejecuta una respuesta dentro del sistema autorizado.
5. Seguimiento: se registra qué quedó hecho y qué falta verificar.

Esta secuencia ordena tareas distintas; no es una secuencia universal prescrita por NASA o BSEE.

Como convención local, puede servir separar el registro inicial de lo que se añada después: conservar en el aviso la descripción y su procedencia; vincular a la investigación las comprobaciones y el razonamiento; y dejar el resultado de la acción en el seguimiento correspondiente. BSEE describe procesos de reporte correctivo con más etapas que una notificación simple, pero el informe no prescribe esta distribución de campos para otras organizaciones.

Sus ejemplos no autorizan a trasladar responsabilidades, plazos o formularios a otra organización.

Si el aviso solo dice “resuelto”, queda una pregunta abierta: ¿se reparó el equipo, se dejó fuera de servicio, se observó que la condición no se reproducía o se derivó a otro responsable? El estado debe seguir las categorías que utilice el sistema local para ese caso. El parte inicial debe conservar lo que la persona sabe al abrirlo; el seguimiento posterior completa el estado cuando se realicen otras actividades.

No conviene retroescribir una conclusión para que parezca conocida desde el principio.

Un caso hipotético desde el aviso hasta la derivación

Supongamos que durante el turno de tarde una operaria ve una pequeña mancha de fluido bajo una unidad de bombeo. No conoce el tipo de fluido ni puede atribuir la mancha a una unión concreta. Un parte útil podría decir: “A las 16:10 se observa una mancha de líquido bajo la unidad U-14, lado norte, después del ciclo de limpieza. No se ha identificado el origen. Aviso realizado por el turno de tarde.”

Cada dato es hipotético y no describe un incidente real.

El texto no afirma que la bomba tenga una fuga, porque la mancha podría proceder de otra fuente. Tampoco prescribe qué hacer con el equipo. Las decisiones sobre operación, aislamiento, aviso inmediato o respuesta de emergencia deben seguir la evaluación y los procedimientos del lugar; el ejemplo solo muestra cómo preservar la diferencia entre lo visto y lo inferido. Si hay una condición que activa un procedimiento local urgente, el parte documental no reemplaza esa comunicación.

Cuando el técnico recibe el aviso, puede usar la ubicación y el momento para contrastar los registros disponibles. Más tarde, si se identifica el origen, la conclusión se añade al registro de seguimiento como hallazgo posterior, vinculada a quien la comprobó y a la evidencia utilizada. Si no se confirma, la hipótesis puede quedar descartada. Esta separación permite que el historial muestre cómo cambió el entendimiento del evento.

Cuando falta un dato, registrar la incertidumbre

No siempre quien abre el aviso puede consultar el número de activo, la pantalla de alarmas o a quien presenció el inicio. Marca lo desconocido como pendiente y deja una referencia local para encontrar el punto. No elijas el equipo más probable solo para completar un campo obligatorio.

Si repites información de otra persona, atribúyela: “el turno anterior comenta que el ruido empezó al final del ciclo” no significa que quien registra lo haya oído. NASA contempla comentarios sobre el trabajo, pero no prescribe una taxonomía universal de testimonios. NASA NPR 8831.2F, apéndice D.1.3, línea 249

Para el relevo, deja claro qué se observó, quién lo comunicó y qué falta confirmar. Si el sistema separa observación, estado y asignación, usa esos campos según sus definiciones; si no, “observado”, “referido por” y “pendiente” distinguen el origen de cada dato.

Errores de registro que dificultan el relevo

Al revisar un aviso, comprueba que la persona de contacto no figure automáticamente como responsable de reparar; que una impresión como “suena mal” indique dónde y cuándo se percibió; y que una causa siga marcada como hipótesis mientras nadie la compruebe. Tampoco confundas la hora de creación del ticket con el inicio estimado del síntoma.

No hace falta inventar una medición: “ruido metálico al arrancar, observado desde el pasillo de la estación 4” deja claros tanto el dato como su alcance.

Si después se abre una orden de trabajo, conserva el vínculo con el aviso según el proceso local. NASA presenta los tickets de trouble call como alternativa a una orden estándar para trabajos pequeños de su contexto; no prescribe esa división para otras organizaciones.

Qué puede afirmarse y qué debe quedar pendiente

NASA muestra campos para su propio ticket y permite evitar datos que el CMMS ya conserva; el ejemplo no fija una plantilla para todas las plantas. NASA NPR 8831.2F, apéndice D, líneas 142 y 154–202 BSEE compara niveles de reporte y acción correctiva en el ámbito offshore estadounidense, no una norma española. BSEE, Failure Reporting Task 3, §5.2

El primer aviso no debe dar por hechas la investigación ni la verificación posteriores. Cada organización define quién abre el registro, cómo lo prioriza y cuándo lo vincula a una orden. El parte debe dejar visible qué se comunicó, qué se comprobó y qué sigue pendiente.

Preguntas frecuentes

¿Qué diferencia hay entre síntoma y causa?

El síntoma es lo observado —por ejemplo, una alarma o una fuga visible—; la causa es una explicación que debe comprobarse. En el parte conviene etiquetar cualquier explicación inicial como hipótesis.

¿Qué información mínima ayuda a localizar la avería?

Registra fecha y hora, ubicación concreta, equipo o referencia disponible, quién comunica el aviso y una descripción breve de lo ocurrido. La plantilla puede variar según el sistema local.

¿El parte de avería equivale a una orden de trabajo?

No necesariamente. NASA indica que su ticket puede sustituir a una orden estándar para trabajos pequeños (normalmente 20 horas o menos), que suelen no estar planificados ni estimados. Es el contexto de ese sistema, no una regla para toda empresa. NASA NPR 8831.2F, apéndice D.1.1

¿El aviso confirma que se ha corregido el problema?

No. El parte documenta la notificación. La inspección, el diagnóstico, la intervención y la comprobación posterior son etapas distintas; el registro inicial no prueba por sí solo que la causa esté confirmada o que el equipo haya quedado conforme.