La importancia de medir las cosas correctas de manera correcta

Indice de contenido

Compartir esta entrada
Share on LinkedIn
Linkedin
Share on Facebook
Facebook
Tweet about this on Twitter
Twitter
Print this page
Print

Los indicadores son asunto de todos los días en la organización de mantenimiento y confiabilidad. Un indicador alejado de las metas puede causar la caída de una jefatura, ocasionar la resolución de un contrato, resultar en premios o penalidades y en la búsqueda de explicaciones de los desvíos.

El Cuerpo del Conocimiento (BoK) de la SMRP (Society of Maintenance and Reliability Professionals) está compuesto de 5 pilares del conocimiento. El primer pilar “Gestión del negocio”, en el ítem 1.3 nos re ere a la medición del desempeño y nos recuerda y/o recomienda entre otras cosas:

  • Los indicadores claves de desempeño (KPI) elegidos deben estar relacionados con los objetivos de la organización.
  • Medir las cosas correctas de la manera correcta es la clave para cualquier proceso exitoso de mantenimiento y confiabilidad.
  • Cada KPI debe ser el resultado de múltiples dimensiones que verifiquen tanto cantidad como calidad.

Voy a referir tres casos en que la incorrecta medición del indicador puede llevar a decisiones erróneas y un caso en que la elección del indicador no es la adecuada. Como suelen decir en el cine o la literatura: “Esta historia es real, sin embargo, algunos nombres y lugares han sido cambiados para proteger la identidad de sus verdaderos protagonistas”.

Caso 1

En una empresa de servicios de mantenimiento, el planner entrega la información mensual para el cálculo del backlog al analista de confiabilidad, tal como está establecido en el flujo de trabajo de esta empresa. El analista realiza el cálculo y encuentra los valores del Backlog, con la expresión:

Ecuación 1 - Backlog (Listo)
Ecuación 1 – Backlog (Listo)

Con la información recibida de planeamiento el valor del cálculo para este indicador nunca superaba la unidad, variaba entre 0,6 y 0,8 semanas. El analista decide informarse cuál es el mejor valor en su clase y encuentra que este es de ¡2 a 4 semanas! (Guía SMRP 5.4.9).

Es decir el valor del backlog para este servicio de mantenimiento era lo mejor. Duda de este valor, puesto que otro indicador que es el cumplimiento de los trabajos programados en horas no superaba el 50% en promedio para un mejor valor en su clase de 90%. Entonces, cómo entender que por un lado el backlog indicara que, la cantidad de trabajo programado para su ejecución fuera tan baja y el indicador de trabajo programado presentara tan bajo cumplimiento.

El siguiente paso fue revisar la definición de backlog y encontrar que para la SMRP habían ahora dos tipos de Backlog: el Backlog Listo (Ready) y el Backlog Planeado (Planned). De ambas, el Backlog listo es el que se corresponde con la definición “clásica” de Backlog. La definición del Backlog listo es como sigue:

Imagen 1 - Backlog listo (Definición)
Imagen 1 – Backlog listo (Definición)

De esta definición se desprende que el Backlog no es solo el trabajo atrasado de la semana anterior que no se completó por falta de recursos de horas-hombre sino también el trabajo que está programado para la semana que inicia. Adicionalmente, la información sobre el trabajo programado no ejecutado (atrasado) el planner lo limitaba al del último mes. Finalmente los trabajos eran computados sobre las horas cronológicas de la orden de trabajo (OT) y no las horas hombre del personal involucrado. Estas tres distorsiones o si queremos llamarlas “no conformidades” producían los errores en el cálculo del Backlog, que resultaba en valores bajos, que no se correspondían con la realidad del trabajo de mantenimiento.

Hechas las correcciones, el valor del backlog pasó a estar en el orden de las 5 semanas, un valor acorde con el estado de la programación de los trabajos en este servicio.

En resumen, los errores en el cálculo del backlog en este caso fueron:

  • No inclusión de las horas programadas de la semana presente.
  • Limitar las horas programadas no ejecutadas al último mes precedente.
  • Usar horas cronológicas de la OT en lugar de las horas hombre de las OT.

• Desconocimiento en las definiciones y elementos del cálculo del Backlog.

Caso 2

Nuevamente fui consultado por otro caso de Backlog, igualmente dentro de un servicio de mantenimiento tercerizado. Esta vez el valor de Backlog era alto en el orden de las 5 a 7 semanas. Esto motivaba el reclamo del cliente a la empresa contratista del servicio de mantenimiento. Este atraso en el cumplimiento de los trabajos, reflejado en el Backlog, implicaba que la contratista del servicio debiera proveer mayor cantidad de personal para ejecutar los trabajos del Backlog a su costo.

Según estaba establecido en el contrato del servicio, las órdenes de trabajo son planeadas por el personal del cliente y enviadas al contratista para programación. Procedieron a revisar la condición de las OT enviadas para programar y se constató que estas OT distaban mucho de ser un trabajo planeado en el sentido de la definición que podemos encontrar en la guía SMRP 5.3.1:

Imagen 2 - Orden de trabajo (Definición)
Imagen 2 – Orden de trabajo (Definición)

La revisión de las OT recibidas para programar mostraba un alto porcentaje de ellas sin incluir materiales, otras incluyendo materiales no requeridos, o incluyendo materiales sin stock en almacén. Las horas planeadas estimadas para los trabajos estaban subestimadas. Es decir, se enviaban a programación órdenes que no habían sido integralmente planeadas contradiciendo la definición de trabajo planeado. Esto simplemente conducía a que estas OT ya estuvieran destinadas a formar parte de Backlog desde el momento en que fueron recibidas por Programación.

Adicionalmente, debido a la deficiente información de las horas estimadas para las OT, se usaba un extraño algoritmo ad hoc que multiplicaba el número de OT en el Backlog por unas horas-hombre promedio estimadas por especialidad. Los errores del cálculo del backlog en este caso fueron:

• Planeamiento no conforme de las órdenes de trabajo enviadas a programación.
• No uso de las horas hombre estimadas en las órdenes de trabajo, sino de una equivalencia arbitraria.

Caso 3

Me explicaba un ingeniero de confiabilidad que en su planta de fabricación de envolturas de plástico medían el MTBF (Tiempo medio entre fallas) por línea de producción. Los valores eran bastante bajos, en particular el último mes había registrado 48 horas de MTBF.

La expresión para el cálculo del MTBF es como sigue:

Ecuación 2 - Tiempo medio entre fallas
Ecuación 2 – Tiempo medio entre fallas

Con el tiempo de operación no había problema, era registrado por el horómetro de la línea. La diferencia estaba en el número de fallas. Cuando revisamos la lista de eventos de paradas no programadas presentadas en el último mes, de los 15 eventos registrados, 10 de ellos señalaban que se había presentado una alarma en el panel del control, pero que no habían producido la parada de la línea, la señal fue reseteada, la producción continuó sin detención ni pérdida.

La definición de falla (failure) en la norma ISO 14224:2006 en el ítem 3.15 dice: “Fin de la capacidad de un ítem para desempeñar la función requerida”. Entonces, de acuerdo con esta definición, los 10 eventos de señal de alarma sin parada no calificaban como falla porque la línea de producción no perdió su capacidad de desempeñar la función requerida, que es la de producir las envolturas de plástico.

Luego, para el cálculo del MTBF solo correspondía considerar los 5 eventos que ocasionaron que la línea de producción parara y “dejara de desempeñar la función requerida” en este caso producir. El valor del MTBF debía ser en este caso de 144 horas.

Esto no deja de lado que la causa o causas de los eventos de señal de alarma (sin parada) deban ser investigadas, evaluadas y corregidas en una parada programada de mantenimiento.

El error en el cálculo del MTBF fue:

  • Considerar como fallas, eventos que no califican como tales, incrementando el denominador en la fórmula con el decremento en el valor del MTBF.

Caso 4

Un ingeniero de confiabilidad y mejora continua en una planta cementera comenta que el indicador de la función mantenimiento es el MTBF, pero que este es calculado sobre todos los equipos de la planta. La justificación de la gerencia es que si el mantenimiento mejora en cada equipo esto se reflejara en toda planta y este “MTBF global” también se reducirá.

Es cierto que si solo se quiere tener un “número” para mostrar en reuniones, esto funciona a la perfección, pero la pregunta es si este indicador nos servirá para tomar medidas preventivas o correctivas para la mejora continua de nuestra gestión de mantenimiento.

El MTBF como lo indica en su nombre está ligado al número de fallas, y los modos y efectos de las fallas están relacionadas con el tipo de equipo bajo análisis. Por ello, el MTBF es mejor utilizado al nivel de activos o componentes y para comparar la confiabilidad de tipos similares de activos. No como se utiliza en el caso reseñado, como un indicador de mantenimiento de una planta en que trabajan equipos diferentes como chancadoras, molinos, hornos, ciclones, ventiladores, transportadores entre otros.

En este caso, el error viene de la etapa de selección del indicador, donde el elegido (MTBF) no es el más adecuado.

En conclusión, al momento de seleccionar los indicadores para medir la gestión del mantenimiento y confiabilidad es recomendable:

  • Definir los objetivos que buscamos para nuestra gestión de mantenimiento y confiabilidad. Usar objetivos del tipo SMART es una buena opción. SMART son las siglas en inglés para Específico (Specific), Medible (Measurable), Obtenible (Attanaible), Relevante (Relevant) y Base en el tiempo (Time).
  • Elegir los indicadores que se asocien mejor con los objetivos que pretendemos alcanzar.
  • Utilizar indicadores estandarizados como son los de las guías de la SMRP (67 indicadores) o los de la norma europea EN 15341:2007 (71 indicadores).
  • Establecer procedimientos o instructivos internos donde se precise las fórmulas y consideraciones para el cálculo de los indicadores.
  • Entrenar al personal responsable de la recolección, procesamiento y cálculo de la data para minimizar las no conformidades.

Autor: Víctor D. Manriquez Ingeniero Mecánico. CMRP – Mag. Energías Renovables Ingeniero de Confiabilidad Docente IPEMAN. Correo: manriquez62@yahoo.es Perú

Compartir esta entrada
Share on LinkedIn
Linkedin
Share on Facebook
Facebook
Tweet about this on Twitter
Twitter
Print this page
Print

Deja un comentario