Calidad de las solicitudes de trabajos de mantenimiento: 7 campos imprescindibles

Una solicitud de trabajo de mantenimiento (una notificación en SAP PM, una solicitud de trabajo en Maximo u Oracle) es el único momento del ciclo de vida de una orden de trabajo en el que la persona que detectó el problema sigue estando al corriente. Todo lo que hacen después el planificador, el programador, el comprador y el ingeniero de fiabilidad se basa en lo que esa persona ha introducido. Una solicitud en la que falte el estado del equipo, los oficios necesarios o una descripción útil no puede solucionarse con una mejor planificación. Solo puede devolverse, interpretarse a ojo o ejecutarse de forma incorrecta.

Un responsable de mantenimiento y fiabilidad de una importante empresa norteamericana del sector del petróleo y el gas lo expresó así durante nuestras sesiones de diseño de productos: si la notificación se envía con calidad y la ejecución se confirma con calidad, la mayor parte de lo que hay entre medias se puede automatizar. Si se hacen bien los dos extremos, el resto se resuelve por sí solo. Si se falla en la fase inicial, nada de lo que venga después podrá salvarlo.

Puntos clave

• La solicitud de trabajo es el documento con mayor impacto en el ámbito del mantenimiento. Un minuto dedicado a garantizar la calidad en el momento de la recepción ahorra horas de trabajo adicional al planificador, evita prioridades erróneas y el almacenamiento incorrecto de piezas.
• Hay siete campos que determinan si una solicitud puede planificarse sin necesidad de una llamada telefónica: equipo y ubicación funcional, «¿está fuera de servicio ahora?», derivación o redundancia, horas estimadas, oficios, herramientas especializadas e impacto en la seguridad.
• Los técnicos no redactan solicitudes incorrectas por descuido. Las redactan porque la pantalla del ERP se diseñó pensando en el planificador, no en alguien que se encuentra frente a una bomba averiada.
• Las solicitudes duplicadas y mal codificadas no solo saturan la lista de tareas pendientes, sino que también distorsionan los indicadores MTBF, MTTR y el análisis de los usuarios problemáticos durante años.
• La mayoría de los operadores intentan solucionar esto mediante formación y campos obligatorios. Ambos métodos fracasan por la misma razón: suponen una dificultad añadida para la persona que dispone de menos tiempo y tiene menos incentivos.
• La solución consiste en trasladar la responsabilidad de la calidad del técnico al proceso de admisión, que es donde la gestión de órdenes de trabajo basada en la inteligencia artificial cobra todo su sentido.

¿Por qué una solicitud de trabajo mal gestionada cuesta más que una orden de trabajo mal gestionada?

Una orden de trabajo errónea afecta a un solo trabajo. Una solicitud de trabajo errónea afecta a todas las decisiones que se toman sobre ese trabajo, ya que cada paso posterior hereda su deficiencia. El planificador define mal el alcance, el motor de prioridades la puntúa incorrectamente, la reserva de piezas es errónea y el registro de fallos que llega al ingeniero de fiabilidad es incorrecto. El error se agrava en cada traspaso.

Piensa en lo que ocurre cuando llega una solicitud en la que solo se indica: “La bomba tiene una fuga, hay que revisarla”.”

• El planificador se detiene. No pueden evaluar el alcance del trabajo sin saber qué bomba es, dónde está la fuga, si la unidad está en funcionamiento o averiada, y si hay una de repuesto en servicio. O bien llaman por teléfono al responsable (si es que lo encuentran, si está de turno, días después) o tienen que adivinar.
• La prioridad no es la correcta. Si no hay una señal que indique que el sistema está caído, la solicitud pasa a la cola de tareas pendientes como de costumbre. Si el equipo está afectando a la producción, nadie se entera hasta que el departamento de operaciones da el aviso.
• No se reservan piezas. Si no hay ningún modo de fallo, no hay que consultar la lista de materiales. Se programa el trabajo, llega el equipo, el kit de juntas no está en stock y un trabajo $400 se convierte en un $9.000 urgente.
• La ejecución queda aplazada. El equipo no puede continuar sin el permiso, el aislamiento o la segunda embarcación; nadie lo ha señalado. La orden de trabajo se devuelve al departamento de planificación con una nota.
• El historial de fallos no sirve para nada. Cuando finalmente se cierra el trabajo, el código de avería es el que el técnico haya seleccionado de un menú desplegable a las 16:00 horas de un viernes. Posteriormente, el ingeniero de fiabilidad realiza un análisis de causas de fallo basándose en datos que nunca fueron ciertos.

El profesional con el que colaboramos describió esto como la diferencia entre una orden de trabajo que es previsto y uno que es abierto. La mayoría de las carteras de pedidos están repletas de órdenes de trabajo pendientes. La solicitud determina cuál te asignan.

La relación coste-beneficio es desequilibrada. El creador dedica aproximadamente un minuto más a rellenar los siete campos que se indican a continuación. El planificador ahorra entre 20 y 45 minutos de seguimiento por cada solicitud. En una planta que genera entre 300 y 500 solicitudes al mes, la diferencia equivale a entre uno y dos puestos de planificador a tiempo completo, sin contar las solicitudes urgentes, los trabajos aplazados ni los datos de fiabilidad erróneos.

¿Qué debe incluir una solicitud de trabajo de mantenimiento de alta calidad?

Una solicitud de trabajo planificable responde a siete preguntas antes de que un planificador la abra. No se trata de los 40 campos que aparecen en la pantalla de notificaciones de SAP, sino de los siete que, si faltan, impiden que el planificador realice su trabajo, extraídos directamente de lo que un responsable de fiabilidad con experiencia afirmó que necesitaba desde el primer día. Pregunta lo suficiente, no todo.

Dos de ellas merecen una atención especial, ya que son las que la pantalla estándar del ERP gestiona peor.

¿Está fuera de servicio ahora mismo? SAP distingue estado del sistema (cuáles serán las repercusiones mientras se realizan las obras) de la indicador de averías (el equipo ha dejado de funcionar). La mayoría de las plantas no utilizan ninguna de las dos opciones de forma sistemática. El profesional con el que trabajamos calificó la brecha entre ambas como la solución alternativa personalizada más habitual que había observado entre los operadores: cada planta crea su propio campo para “fuera de servicio en este momento”, y ninguno de ellos se comunica con los demás. Tratamos este tema en profundidad en nuestro artículo sobre la brecha de impacto en la producción en la priorización de las órdenes de trabajo.

Derivación o redundancia. Los sistemas auxiliares son donde esto más duele. Una bomba de agua de refrigeración o un conjunto de lubricación rara vez cuentan con redundancias, y un fallo en uno de ellos provoca la parada total de la unidad. Sin embargo, casi nunca se plantea la cuestión de la redundancia en la toma de agua, porque no hay margen para ello. La información reside en la mente de quien la genera y, si se le ocurre, en un texto extenso. Una solicitud que la recoja cambia de un solo golpe la prioridad, el calendario y la estrategia de almacenamiento de ese equipo.

La norma que la mayoría de los sitios exigen a los técnicos es que indiquen dos campos: una ubicación funcional y una descripción. Eso basta para abrir una orden de trabajo, pero no para planificarla.

¿Por qué los técnicos redactan solicitudes de trabajo deficientes y por qué la formación no soluciona este problema?

Los técnicos redactan solicitudes escuetas porque la pantalla de solicitud se diseñó pensando en quien la lee, no en quien la redacta. El autor se encuentra en una planta ruidosa, a menudo con guantes puestos, con un activo averiado delante y un turno que terminar. El sistema ERP les exige que busquen un terminal, naveguen por una transacción, elijan entre listas de códigos que no utilizan a diario y escriban textos largos con dos dedos. Lógicamente, escriben lo mínimo imprescindible.

El experto en fiabilidad con el que trabajamos fue muy claro al respecto: a los equipos de campo no les gusta el sistema ERP, y él tampoco esperaba que les gustara. Los casos de mejor adopción que había observado eran aquellos centros que habían dejado de esperar que los operarios fueran meros encargados de introducir datos.

Las tres soluciones habituales se topan todas con el mismo obstáculo.

Formación. Su efecto se mantiene durante los tres meses posteriores a la sesión y va disminuyendo a medida que se renueva el grupo formado. El personal subcontratado, que genera una gran parte de las solicitudes en muchos centros, rara vez recibe formación alguna.

Campos obligatorios. Marcar un campo como obligatorio garantiza que se rellene. No garantiza que el contenido sea correcto. Los sitios web que exigen un código de avería acumulan un retraso en el que las averías se codifican como “otro” o como la primera opción de la lista. Los campos obligatorios trasladan el problema de la calidad de los datos de falta a incorrecto, lo cual es peor, porque los datos erróneos parecen estar completos.

Evaluación de prioridades del planificador. Muchas obras aceptan la solicitud incompleta y encargan a los planificadores que la completen. Esto funciona, pero a costa de una semana de trabajo del planificador. Un planificador que dedica el 40 % de su tiempo a perseguir a los responsables de la obra es un planificador que no está elaborando planes de obra, comprobando los kits ni supervisando las obras. Es la persona más cara de la cadena la que está realizando el trabajo más barato.

Hay otro coste que rara vez se tiene en cuenta. Cada vez que se devuelve una solicitud o se llama por teléfono para preguntar por los profesores, el técnico piensa que tramitar una solicitud es una molestia. La próxima vez, lo arreglan ellos mismos y no presentan ninguna solicitud. El volumen de trabajo pendiente parece más manejable. Ahora falta un fallo en el historial del activo.

¿Cómo afectan a la fiabilidad de los datos las solicitudes de trabajo duplicadas y mal codificadas?

Cada solicitud de trabajo es también un registro de fiabilidad, independientemente de si alguien lo ha pretendido así o no. La marca de tiempo comienza con el MTTR reloj. Los códigos de equipo y de avería alimentan el MTBF y el análisis de «elementos problemáticos». Una solicitud duplicada, mal codificada o asociada al equipo equivocado no solo hace perder tiempo al planificador esta semana. Distorsiona el historial de averías que la planta utilizará para establecer las frecuencias de mantenimiento preventivo, justificar las inversiones de capital y decidir a qué activos se prestará atención durante años.

Los duplicados son el caso más evidente. Cuando una bomba empieza a vibrar, tres personas de tres turnos diferentes pueden presentar una solicitud. Si las tres se convierten en órdenes de trabajo, o si se cierra la solicitud equivocada, la planta registra tres fallos donde en realidad solo hubo uno. El equipo supera un umbral de «mal funcionamiento» que nunca se ha ganado. El profesional con el que trabajamos fue muy preciso respecto a la norma: conservar la solicitud más antigua, porque es entonces cuando comenzó a contar el tiempo de la avería, y cancelar las posteriores con un código de motivo que indique duplicado, no completado o no se ha detectado ningún fallo. Un duplicado cerrado como «completado» es una reparación fantasma.

Los errores de codificación son más discretos y más habituales. Si se registra una incidencia en la ubicación funcional principal en lugar de en el equipo, la avería se atribuye a la unidad, no a la bomba. Un código de daño “otro” significa que la avería no se atribuye a nada. Ambas situaciones hacen que el activo parezca estar en mejor estado de lo que realmente está. A raíz de ello, la planta amplía el intervalo de mantenimiento preventivo de un activo que está fallando, ya que los datos indican que está en buen estado.

Por eso la calidad de las solicitudes es un problema de fiabilidad, no administrativo. Los más perjudicados por las solicitudes incompletas no son los planificadores que las tramitan. Son los ingenieros de fiabilidad, dos años más tarde, que tienen que analizar un historial de fallos que nunca fue real, y el almacén, que guarda repuestos inadecuados para los activos que fallan. Tratamos el problema de las notificaciones duplicadas y su efecto sobre el MTBF en un artículo aparte.

¿En qué consiste el principio de “calidad de entrada, calidad de salida” en el ciclo de vida de una orden de trabajo?

El ciclo de vida de una orden de trabajo tiene dos puntos en los que la intervención humana debe ser correcta: la solicitud al inicio y la confirmación al final. Todo lo que ocurre entre ambos (definición del alcance, establecimiento de prioridades, agrupación de tareas, reserva de piezas, programación y tramitación de permisos) consiste en la aplicación de reglas a los datos que proporcionan esos dos puntos. Si la solicitud está completa y el cierre es veraz, el proceso intermedio puede sistematizarse. Si alguno de los extremos es deficiente, por muy sofisticado que sea el proceso intermedio, no servirá de nada.

Esta observación nos hizo replantearnos nuestra forma de enfocar la gestión de las órdenes de trabajo. El profesional con el que colaboramos no pidió un planificador más inteligente. Lo que pidió fue que las solicitudes llegaran ya listas para ser planificadas y que el cierre registrara lo que había ocurrido. Con esas dos cosas, estaba convencido de que se podría eliminar la mayor parte del trabajo manual del planificador.

Esto también explica por qué tantas inversiones en CMMS y EAM resultan decepcionantes. El dinero se destina a la parte intermedia: paneles de control, tableros de planificación y aplicaciones móviles para los planificadores. La interfaz de usuario, es decir, el momento en el que un técnico decide qué datos introducir, se deja exactamente como estaba. El sistema se vuelve más rápido a la hora de procesar datos erróneos.

Para un responsable de mantenimiento, este principio ofrece un diagnóstico sencillo. Selecciona al azar 50 solicitudes de trabajo recientes y pregúntate, para cada una de ellas, si un planificador habría podido definir su alcance sin necesidad de una llamada telefónica. Si menos de 30 superan la prueba, la planta no tiene un problema de planificación ni de programación. Tiene un problema de recepción de solicitudes, y la solución corresponde al departamento de recepción.

La segunda parte del cierre tiene la misma importancia y, a menudo, es peor. Una orden de trabajo confirmada como “realizada” y con un código de avería predeterminado registra una reparación, pero no un fallo. El par «solicitud-cierre» constituye la unidad de datos de fiabilidad; si alguna de las dos partes está vacía, el registro también lo está.

¿Cómo mejora la gestión de solicitudes basada en IA la calidad de las solicitudes de trabajo sin añadir campos?

El único enfoque que ha funcionado a gran escala consiste en trasladar la responsabilidad de la calidad del técnico al propio proceso de recepción. El técnico describe el problema tal y como se lo explicaría a un compañero, ya sea verbalmente o con una foto, y el sistema se encarga de estructurarlo: identifica el equipo a partir de la ubicación y la imagen, redacta el texto detallado, propone los códigos de avería y de objeto a partir de la biblioteca de tareas y formula las pocas preguntas que haría un buen planificador. El técnico se limita a verificar, en lugar de escribir.

Así es como el módulo de órdenes de trabajo de MRO360 gestiona la recepción de pedidos. En la práctica, realiza cuatro acciones en la fase de solicitud.

• Capturas realizadas sobre el terreno, no desde el terminal. Se introducen la voz y la foto; se genera una notificación completa y codificada, con la ubicación funcional, el equipo y el texto descriptivo ya rellenados para que el remitente los confirme.
• Hace las siete preguntas, y solo esas. ¿Está fuera de servicio ahora? ¿Hay alguna solución alternativa? ¿Horas de trabajo difíciles? ¿Qué equipos? ¿Se necesitan herramientas especiales? ¿Tiene algún impacto en la seguridad? Las preguntas se adaptan a la clase de equipo, por lo que a una luminaria no se le pregunta sobre el aislamiento energético.
• Comprueba si hay duplicados antes de crearlos. Si ya existe una solicitud abierta relacionada con ese equipo, la nueva se fusiona con ella en lugar de crearse como una nueva, conservándose la marca de tiempo más antigua para que el contador de MTTR sea correcto.
• Carga previamente el plan de trabajo. Cuando el operador dispone de listas de tareas vinculadas a códigos de objeto y de daños, el plan correspondiente, la lista de materiales y los requisitos de permiso se adjuntan en el momento de la solicitud, de modo que el planificador abre un borrador de orden de trabajo en lugar de una en blanco.

El profesional con el que colaboramos denominó a este tipo de «interacción con el sistema» como la clave que, por fin, conseguiría que los equipos de campo utilizaran correctamente el CMMS. También señaló que varios proveedores están compitiendo por conseguirlo, razón por la cual consideramos que la captura sin fricciones es un requisito mínimo, y que el cuestionario de admisión de siete preguntas y la regla de duplicados son los elementos que modifican la carga de trabajo de los planificadores.

Lo que esto no hace es eximir a nadie de cumplir con las normas. Las preguntas siguen requiriendo respuestas sinceras, y el cierre del informe sigue necesitando un código de avería real. El sistema elimina la necesidad de escribir y la navegación, que son las razones por las que los técnicos se saltan los campos. No elimina la necesidad de tomar decisiones.

Preguntas frecuentes

¿Cuál es la diferencia entre una solicitud de trabajo y una orden de trabajo? Una solicitud de trabajo (una notificación en SAP PM) registra que se ha detectado un problema que requiere atención. Una orden de trabajo autoriza y planifica los trabajos necesarios para solucionarlo, incluyendo la mano de obra, las piezas, los permisos y un calendario. Cada orden de trabajo debe poder remontarse a una solicitud; no todas las solicitudes se convierten en órdenes de trabajo, ya que algunas son duplicadas, otras se rechazan y otras se gestionan como rondas de inspección del operador.

¿Qué es una notificación de mantenimiento en SAP PM? Una notificación de mantenimiento es el término que utiliza SAP para referirse a una solicitud de trabajo. Incluye el objeto de referencia (ubicación funcional o equipo), un texto breve y otro extenso, la prioridad, el indicador de avería y, de forma opcional, códigos de objeto, de daño y de causa. Los tipos de notificación M1 (informe de avería), M2 (solicitud de mantenimiento) y M3 (informe de actividad) son los tres estándar, aunque la mayoría de los operadores configuran los suyos propios.

¿Qué campos debe incluir una orden de mantenimiento? Como mínimo: el equipo o la ubicación funcional, si el activo está actualmente fuera de servicio, si se dispone de un circuito alternativo o una unidad redundante, una estimación de las horas necesarias, los oficios requeridos, cualquier herramienta especializada y el impacto en materia de seguridad o medio ambiente. Estos siete datos permiten al planificador evaluar el alcance del trabajo sin necesidad de ponerse en contacto con la persona que lo ha solicitado.

¿Qué es el indicador de avería en SAP y por qué es importante? El indicador de avería es una casilla de selección de la notificación de SAP que señala que el equipo está averiado en el momento de la notificación. Es el único campo estándar que indica al planificador que el activo está fuera de servicio en ese momento, y es el que utiliza SAP para calcular el MTBF y el MTTR. Las instalaciones que no lo marquen de forma sistemática no pueden fiarse de ninguna de estas métricas.

¿Por qué los planificadores dedican tanto tiempo a las solicitudes de trabajo? Dado que la mayoría de las solicitudes llegan con solo una ubicación y una descripción de una línea, los planificadores deben ponerse en contacto con el solicitante, inspeccionar el activo o hacer conjeturas antes de poder definir el alcance del trabajo. Las encuestas realizadas a los planificadores de mantenimiento revelan sistemáticamente que dedican su semana a este tipo de gestiones en lugar de a elaborar planes de trabajo.

¿Cómo afectan las solicitudes de trabajo duplicadas al MTBF? Cada solicitud que se convierte en una orden de trabajo se contabiliza como un fallo. Si se registran tres solicitudes para un mismo incidente y las tres se tramitan o se cierran como completadas, la planta registra tres fallos y su MTBF para ese activo se reduce en dos tercios. La solución consiste en conservar la solicitud más antigua y cancelar las demás con un código de motivo de duplicado.

¿Debería convertirse cada solicitud de trabajo en una orden de trabajo? No. Las solicitudes deben revisarse primero para detectar duplicados, trabajos ya incluidos en una orden abierta o en un mantenimiento preventivo programado, y elementos que puedan gestionarse como tareas del operador. Convertirlo todo aumenta el volumen de trabajo pendiente y distorsiona los datos de fallos.

¿Mejoran los campos obligatorios la calidad de las solicitudes de trabajo? Normalmente no. Los campos obligatorios garantizan que se introduzca un valor, pero no que este sea correcto. En los sitios web que exigen códigos de daños, suele observarse que una gran parte de los casos se codifican como “otros” o como la primera opción de la lista. Los datos parecen completos, pero son erróneos, lo cual resulta más difícil de detectar que los datos que faltan.

¿Cómo se mide la calidad de las solicitudes de trabajo? La prueba más sencilla es la tasa de planificabilidad: el porcentaje de solicitudes que un planificador puede evaluar sin ponerse en contacto con el solicitante. Se toma una muestra de 50 solicitudes recientes y se puntúa cada una de ellas. Otros indicadores complementarios son la tasa de duplicados, el porcentaje de solicitudes presentadas en relación con una ubicación principal en lugar de con un equipo concreto, y el porcentaje de órdenes de trabajo cerradas con un código de avería por defecto o “otro”.

¿Puede la IA redactar la solicitud de intervención para el técnico? El módulo de registro integrado con IA puede redactarlo. A partir de una descripción de voz y una foto, el sistema puede identificar el equipo, proponer el texto completo y los códigos, comprobar si hay duplicados y plantear al autor las pocas preguntas que le haría un planificador. El técnico se limita a confirmar, en lugar de escribir. Este es el enfoque que se utiliza en el módulo de órdenes de trabajo de MRO360.

¿Quién es responsable de la calidad de las solicitudes de trabajo: el departamento de operaciones o el de mantenimiento? Ambos, pero el peso recae en el departamento de operaciones, ya que son los operadores y los técnicos quienes plantean la mayoría de las solicitudes. El departamento de mantenimiento es el responsable de la norma (lo que debe incluir una solicitud planificable) y del proceso de recepción que facilita el cumplimiento de dicha norma. En los centros en los que solo el departamento de mantenimiento se preocupa por la calidad de las solicitudes, suele acabarse recurriendo a la clasificación por parte de los planificadores como solución permanente.

Descubre cuánto te están costando tus solicitudes de trabajo

Si más de un tercio de tu cartera de pedidos requiere una llamada telefónica antes de poder planificarse, el problema se encuentra en una fase anterior a la de tus planificadores. Realizaremos la prueba de planificabilidad con una muestra de tus notificaciones recientes, te mostraremos la tasa de duplicados y de codificación errónea, y te explicaremos cómo el proceso de recepción basado en IA de MRO360 cambia lo que llega al escritorio del planificador.

Reserva una evaluación de 30 minutos sobre tu solicitud de trabajo. Trae 50 notificaciones recientes; nosotros nos encargamos de la puntuación.