Investigar una parada sin código de causa

Reconstruye los hechos de una parada sin código de causa antes de clasificarla, atribuirla o convertir el registro en una conclusión operativa.

Una parada sin código de causa no dice que no haya ocurrido nada. Dice que el registro todavía no permite describir el motivo con la precisión que exige vuestra clasificación. El peor atajo es escoger una etiqueta para que el informe deje de tener huecos. Ese gesto ordena una tabla, pero puede mezclar un hecho, una sospecha y una decisión que nadie ha validado.

La decisión útil es reconstruir los hechos antes de clasificar o atribuir una causa. Empiece por delimitar qué activo se detuvo, en qué intervalo, qué fuentes conservan evidencia y qué parte de la secuencia sigue sin comprobar. Después separe lo observado de lo que alguien interpreta. El código puede esperar; una evidencia mal atribuida es más difícil de corregir cuando pasa a informes, reuniones o cambios de turno.

La ficha pública de ISO 22400-2:2014 sitúa los KPI dentro de la gestión de operaciones de fabricación. No publica la regla local que una planta usa para codificar una parada ni autoriza inferencias sobre un activo concreto. Esta página toma ese límite en serio: sirve para ordenar la lectura de registros operativos y de sus elementos temporales, no para sustituir la norma completa ni un procedimiento interno. Fuente: ISO 22400-2

El alcance también es importante por seguridad, calidad y responsabilidad. Un código de causa puede influir en prioridades, explicaciones de producción o revisiones posteriores. Por eso esta guía no decide si una condición es segura, no recomienda mantenimiento, no asigna responsabilidad individual y no calcula OEE, disponibilidad, rendimiento ni pérdidas. Si el evento toca cualquiera de esos ámbitos, siga las autorizaciones, criterios y escaladas que correspondan a la instalación.

Trate el código vacío como un estado de evidencia

El campo vacío no es una avería de la disciplina. A veces la parada se registró automáticamente y nadie añadió contexto; otras, la persona que la vio no tenía la información necesaria; también puede haber dos fuentes con horas distintas. Antes de corregir el campo, conviene describir cuál de esas situaciones existe. “Sin código por falta de contraste entre registros” es más útil que una categoría elegida por descarte.

ISO 22400 define indicadores clave de rendimiento usados en la gestión de operaciones de fabricación. La referencia es útil aquí por una razón acotada: un indicador se interpreta dentro de una gestión de operaciones, no como una explicación automática de cada evento local. Fuente: ISO 22400-2

Un código de causa es una clasificación. La marca de inicio de una parada, una alarma, un comentario de operador o una orden abierta son evidencias potenciales. No ocupan el mismo lugar. Si se escribe “causa: sensor” porque apareció una alarma con ese nombre, el registro salta de una señal a una conclusión. Puede acertar, pero no deja claro qué se comprobó ni qué queda por comprobar.

Abra la reconstrucción con una etiqueta de estado que el equipo ya conozca: pendiente de evidencia, en contraste, clasificación propuesta o clasificada según validación local. No cree un catálogo paralelo para esta guía. La etiqueta debe evitar una lectura equivocada, no añadir otra taxonomía. Si el sistema solo admite un código, conserve una nota o enlace que indique por qué ese valor todavía no describe una causa confirmada.

También hay que distinguir un dato ausente de una fuente que no existe. Puede no haber código, pero sí existir un historial de estados, una alarma, una nota de parte, una orden o una observación en campo. El trabajo no consiste en producir una narración completa. Consiste en reunir referencias que permitan a otra persona revisar qué ocurrió sin depender de la memoria de quien cerró el turno.

Fije el evento antes de buscar explicaciones

Empiece por una ficha mínima del evento. Anote el identificador disponible, el activo o etapa afectada, la hora de inicio, la hora de fin si consta, la zona horaria o reloj de referencia y la fuente de cada valor. Si no hay fin confirmado, escriba “fin no confirmado” en vez de estimar una duración. Si hay dos horas de inicio, mantenga ambas con su procedencia hasta saber por qué difieren.

ISO 22400-2:2014 especifica una selección de KPI que se usan en la práctica actual. Esa formulación no convierte una lista local de códigos de parada en un conjunto ISO ni garantiza que todos los registros de una fábrica se puedan comparar sin revisar su definición. Fuente: ISO 22400-2

La primera pregunta es física y operativa: ¿qué dejó de hacer el activo o el proceso? Evite responder con “la línea se paró” si el hecho verificable es más estrecho, por ejemplo, que una estación dejó de aceptar material o que un equipo entró en un estado determinado. Tampoco reduzca el alcance si la fuente muestra que el flujo aguas abajo quedó sin alimentación. Describa el alcance conocido y marque el resto como no confirmado.

La segunda pregunta es temporal: ¿qué evidencia cae dentro de la misma ventana? Una alarma a las 09:12 puede ser relevante para una parada que empezó a las 09:11, pero no basta con que comparta el turno. Anote el intervalo y la fuente. Si una aplicación redondea minutos y otra conserva segundos, no fuerce una falsa precisión. Registre el desfase y, si importa para clasificar, pida la verificación que corresponda.

La tercera pregunta es de identidad: ¿los registros hablan del mismo activo? Los nombres de equipo, etiquetas de proceso y números de orden a veces no coinciden entre sistemas. Una coincidencia de horario no corrige esa diferencia. Guarde los identificadores tal como aparecen, con una nota de correspondencia solo cuando alguien pueda respaldarla. Ese detalle evita que un evento de un equipo vecino termine anexado a la parada equivocada.

Una ficha breve puede quedar así: “Evento provisional P-71; estación E-04; inicio 09:11 según historial de estados; fin no confirmado; alarma AL-09 a las 09:12 según HMI; nota de parte sin código; relación entre P-71 y AL-09 pendiente de contraste”. No afirma una causa. Deja un punto de partida que otra persona puede auditar.

Reúna las fuentes sin convertirlas en un relato

Cada fuente responde a una pregunta distinta. El historial de estados puede ayudar a situar una transición. Una pantalla puede mostrar una señal. Una nota de turno puede recoger una observación. Una orden puede indicar que alguien abrió una solicitud. Ninguna de esas fuentes recibe automáticamente prioridad universal. El orden depende de la regla local, de la calidad del dato y de la pregunta que se está intentando responder.

La ficha de ISO indica que los KPI se presentan mediante su fórmula, elementos correspondientes, comportamiento temporal, unidad o dimensión y otras características. Para una parada sin código, el valor práctico de esa idea es exigir contexto de lectura: de qué elemento procede el dato, en qué tiempo se observó y qué característica local se conoce. No es una fórmula para clasificar paradas. Fuente: ISO 22400-2

Construya una lista de evidencias, no una cronología adornada. Para cada entrada bastan cinco campos: fuente, identificador o ubicación, marca de tiempo, hecho que muestra y estado de revisión. “HMI, AL-09, 09:12:04, alarma visible, pendiente de contraste” es más claro que “parece que saltó una alarma”. La segunda frase ya introduce una interpretación que luego cuesta localizar.

Cuando dos fuentes discrepan, no elija la más cómoda. Puede haber una diferencia de reloj, de retención de datos, de etiquetado o de alcance. Declare la discrepancia: “inicio 09:11 en historial A; 09:14 en registro B; alineación de relojes no comprobada”. Esa nota preserva una limitación real. El código de causa debe esperar si depende de resolverla.

No convierta una comunicación en prueba técnica. “El turno anterior dijo que era atasco” aporta una hipótesis y una fuente humana; no acredita que exista un atasco ni que explique toda la parada. Registre quién o qué canal lo comunicó, el momento y, si existe, la evidencia citada. Después deje claro qué observación tendría que aparecer para confirmar o descartar esa hipótesis.

La reconstrucción gana cuando conserva los huecos. Si no existe registro de una intervención, no complete el relato con una acción probable. Si una alarma fue reconocida, no concluya que se resolvió la condición. Si una nota menciona una pieza, no deduzca que esa pieza fue sustituida. El registro puede mostrar “evidencia no localizada” y seguir siendo útil; una certeza ficticia no lo es.

Separe hecho, hipótesis y clasificación propuesta

La misma frase no debería contener las tres capas. “La línea se detuvo por fallo de válvula” puede incluir un hecho, una hipótesis y un código implícito. Divídala. Hecho: “E-04 dejó de aceptar material a las 09:11, según historial”. Hipótesis: “se revisa una posible relación con la señal V-3”. Clasificación: “sin proponer hasta contrastar la relación”. Ese formato es menos espectacular y mucho más revisable.

ISO 22400-2:2014 también indica el grupo de usuarios donde se emplean los KPI y la metodología de producción a la que corresponden. Por tanto, el lector necesita conocer el contexto de uso antes de trasladar una categoría o comparar registros entre procesos. La ficha pública no define la metodología concreta de su línea. Fuente: ISO 22400-2

Un hecho debe ser reproducible por otra persona que acceda a la misma fuente. No hace falta que sea definitivo, pero sí debe indicar qué se observó y dónde. “La alarma AL-09 figuraba activa a las 09:12:04 en la captura HMI-22” es una observación. “La alarma causó la parada” ya es una relación explicativa. La diferencia parece pequeña hasta que aparecen registros que muestran otra secuencia.

Una hipótesis puede servir para organizar el siguiente paso. Escríbala con su condición: “posible relación con V-3; falta revisión del registro X”. No cambie “posible” por “probable” solo porque se repita en varias conversaciones. La repetición no aumenta la evidencia. Si hay alternativas, anótelas cuando influyan en la clasificación, sin forzar una lista larga de causas imaginables.

La clasificación propuesta debe decir qué evidencia la apoya y quién o qué regla debe validarla. Por ejemplo: “propuesta: categoría local C-12, pendiente de confirmar que AL-09 corresponde al evento P-71 conforme a la regla de codificación vigente”. Así, quien valida puede aceptar, corregir o devolver la propuesta sin tener que reconstruir de cero la cadena de razonamiento.

Evite categorías que describen el resultado en lugar de la causa. “Parada de producción” puede ser la condición observada, no el motivo. “Tiempo perdido” no clasifica qué ocurrió. Esta página no calcula pérdidas y no necesita una etiqueta económica para reconstruir el evento. Mantener esa separación evita que una cifra o una urgencia de cierre determine el código antes de que exista evidencia suficiente.

Use una secuencia breve para decidir si ya se puede clasificar

La secuencia no sustituye una investigación formal. Ayuda a decidir si el registro tiene el mínimo necesario para pasar de “sin código” a una clasificación local. Puede ejecutarse en una revisión corta y detenerse cuando falte un dato que la regla local considere esencial.

  1. Delimite el evento. Confirme qué activo, proceso o etapa están afectados y cuál es la ventana de tiempo que puede respaldarse con fuentes identificadas.
  2. Liste las evidencias. Guarde identificadores, horas, observaciones y estado de contraste sin reescribirlos como una causa.
  3. Marque las discrepancias. Anote diferencias de reloj, activo, orden o estado. No las esconda mediante un promedio o una hora aproximada.
  4. Formule hipótesis separadas. Indique qué evidencia las respalda y qué comprobación falta, sin usar la hipótesis como código final.
  5. Aplique la regla local. Solo entonces decida si hay evidencia suficiente para clasificar, mantener pendiente o escalar el registro.

ISO 22400-2:2014 relaciona los KPI referidos al equipo con unidades de trabajo, según IEC 62264. La observación recuerda que el alcance del equipo importa al leer un dato. No permite deducir cómo debe codificarse una parada ni reemplaza la relación de activos de una instalación. Fuente: ISO 22400-2

La decisión puede expresarse con tres resultados sencillos. “Clasificable” significa que la evidencia y la regla local permiten asignar el código. “Provisional” significa que hay una propuesta o parte del contexto, pero falta una comprobación identificada. “No clasificable todavía” significa que la ventana, el activo, la fuente o la relación esencial no se han establecido. Esos estados no sustituyen los valores de vuestro sistema; sirven para hacer visible el grado de certeza.

No use el tiempo transcurrido como sustituto de la validación. Una parada de hace dos días puede seguir sin evidencia suficiente, mientras que una reciente puede estar bien documentada. Si el cierre de periodo obliga a informar, declare el estado de la clasificación y la limitación. El informe puede indicar que una causa está pendiente sin convertirla en un dato cerrado para facilitar la comparación.

La escala también importa. Si una misma explicación aparece en varios eventos, no agrupe todos bajo un código común solo por semejanza verbal. Cada parada necesita comprobar su activo, ventana y evidencia. Puede crear una revisión de patrón separada, pero esa revisión no demuestra por sí misma la causa de cada evento individual.

Documente la decisión para que pueda corregirse

Una clasificación bien documentada debe poder revisarse sin adivinar por qué se eligió. Conserve el código asignado, el estado de validación, los identificadores de evidencia, la regla o canal usado y la fecha de la decisión. Si el sistema permite comentarios, escriba una frase que explique el límite: “código C-12 validado con evidencia E-1 y E-2; no cubre causa técnica raíz”.

Esta distinción protege la corrección posterior. Una clasificación puede cambiar cuando aparece un registro tardío, se reconcilia un reloj o se descubre que dos entradas correspondían a eventos distintos. Corregirla no es un fracaso si se conserva la versión anterior y el motivo del cambio. Lo que daña la trazabilidad es cambiar un código sin dejar qué evidencia nueva justificó el cambio.

Evite usar el campo de causa como una nota general. “Se revisará”, “producción baja” o “mantenimiento avisado” pueden ser información útil, pero no responden a una misma pregunta. Ubíquelas en el registro de seguimiento, contexto o escalada que corresponda. El código debe mantener el significado que la clasificación local le atribuye; de otro modo, las comparaciones posteriores pierden consistencia.

Si la evidencia está repartida, use enlaces, referencias o identificadores internos. No copie capturas completas ni transcriba conversaciones extensas a un campo que nadie podrá verificar después. La mejor documentación conserva suficiente camino de vuelta a la fuente: qué buscar, dónde y con qué marca temporal. La persona que revise el evento debe poder distinguir los datos originales de la explicación añadida después.

La página pública de ISO describe el alcance y la forma de presentación de una selección de KPI, pero no hace pública una taxonomía de causas de parada para aplicar en cualquier fábrica. Esa es una limitación deliberada de esta guía: el método organiza evidencia y no declara conformidad con ISO ni sustituye las definiciones de la organización. Fuente: ISO 22400-2

Cuando debe detener la clasificación y escalar

Detenga la clasificación cuando falte el dato que sostiene el vínculo principal. Puede ser la identidad del activo, una marca temporal fiable, la procedencia de una alarma, la autorización para acceder a un registro o una diferencia que la regla local exige reconciliar. “Pendiente” no es una respuesta cómoda, pero es más exacta que una etiqueta que el equipo tendrá que deshacer más tarde.

También escale si la parada se relaciona con un posible riesgo de seguridad, una desviación de calidad, una obligación reglada, una cuestión laboral o un impacto contractual que requiera otro proceso. La reconstrucción de hechos puede ayudar a entregar la información inicial, pero no determina la decisión especializada. No compense la falta de autoridad con una categoría más rotunda.

Si alguien solicita “una causa para el informe”, responda con el estado de evidencia: qué se sabe, qué fuente lo muestra, qué hipótesis está abierta y qué falta para clasificar. Esa respuesta es más útil que prometer una certeza que el registro no contiene. Permite que dirección u operaciones decidan cómo mostrar la limitación sin alterar la investigación.

El próximo paso es concreto. Tome una parada sin código reciente, cree la ficha mínima, añada tres referencias de evidencia si existen y separe una hipótesis de los hechos. Después compruebe la regla local de clasificación. Si no puede completar uno de esos pasos, documente el vacío y escale por el canal correspondiente. No convierta el código vacío en una causa por presión de cierre.

Preguntas frecuentes

¿Debo asignar un código de causa para cerrar el parte?

No inventes un código para completar el parte. Usa el estado provisional o pendiente que contemple el sistema local y deja la evidencia que falta. Un cierre administrativo no convierte una hipótesis en un hecho.

¿Qué dato reviso primero si no hay código de causa?

Empieza por el activo afectado y la ventana temporal. Después conserva las marcas de tiempo y los identificadores de cada fuente disponible. Sin ese marco no es posible saber qué registros pertenecen realmente al mismo evento.

¿Una alarma basta para clasificar la parada?

No necesariamente. Una alarma puede ser una evidencia útil, pero hay que comprobar su relación temporal y de alcance con la parada. La clasificación requiere la regla local y la evidencia que esa regla exija.

¿Puedo usar la opinión del turno como causa?

Puedes registrarla como hipótesis atribuida a su fuente. No la presentes como causa confirmada hasta que se haya contrastado con los registros y el proceso de validación aplicable.

¿Esta reconstrucción sirve para calcular pérdidas u OEE?

No. Su objetivo es reconstruir hechos antes de clasificar una parada. El cálculo de pérdidas, rendimiento, disponibilidad u OEE necesita definiciones, datos y reglas propias.