MTTR <\/a>reloj. Los c\u00f3digos de equipo y de aver\u00eda alimentan el MTBF y el an\u00e1lisis de \u00abelementos problem\u00e1ticos\u00bb. Una solicitud duplicada, mal codificada o asociada al equipo equivocado no solo hace perder tiempo al planificador esta semana. Distorsiona el historial de aver\u00edas que la planta utilizar\u00e1 para establecer las frecuencias de mantenimiento preventivo, justificar las inversiones de capital y decidir a qu\u00e9 activos se prestar\u00e1 atenci\u00f3n durante a\u00f1os.<\/p>\n\n\n\nLos duplicados son el caso m\u00e1s evidente. Cuando una bomba empieza a vibrar, tres personas de tres turnos diferentes pueden presentar una solicitud. Si las tres se convierten en \u00f3rdenes 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 \u00abmal funcionamiento\u00bb que nunca se ha ganado. El profesional con el que trabajamos fue muy preciso respecto a la norma: conservar la solicitud m\u00e1s antigua, porque es entonces cuando comenz\u00f3 a contar el tiempo de la aver\u00eda, y cancelar las posteriores con un c\u00f3digo de motivo que indique duplicado<\/em>, no completado<\/em> o no se ha detectado ning\u00fan fallo<\/em>. Un duplicado cerrado como \u00abcompletado\u00bb es una reparaci\u00f3n fantasma.<\/p>\n\n\n\nLos errores de codificaci\u00f3n son m\u00e1s discretos y m\u00e1s habituales. Si se registra una incidencia en la ubicaci\u00f3n funcional principal en lugar de en el equipo, la aver\u00eda se atribuye a la unidad, no a la bomba. Un c\u00f3digo de da\u00f1o \u201cotro\u201d significa que la aver\u00eda no se atribuye a nada. Ambas situaciones hacen que el activo parezca estar en mejor estado de lo que realmente est\u00e1. A ra\u00edz de ello, la planta ampl\u00eda el intervalo de mantenimiento preventivo de un activo que est\u00e1 fallando, ya que los datos indican que est\u00e1 en buen estado.<\/p>\n\n\n\n
Por eso la calidad de las solicitudes es un problema de fiabilidad, no administrativo. Los m\u00e1s perjudicados por las solicitudes incompletas no son los planificadores que las tramitan. Son los ingenieros de fiabilidad, dos a\u00f1os m\u00e1s tarde, que tienen que analizar un historial de fallos que nunca fue real, y el almac\u00e9n, 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\u00edculo aparte.<\/p>\n\n\n\n
\u00bfEn qu\u00e9 consiste el principio de \u201ccalidad de entrada, calidad de salida\u201d en el ciclo de vida de una orden de trabajo?<\/h2>\n\n\n\n
El ciclo de vida de una orden de trabajo tiene dos puntos en los que la intervenci\u00f3n humana debe ser correcta: la solicitud al inicio y la confirmaci\u00f3n al final. Todo lo que ocurre entre ambos (definici\u00f3n del alcance, establecimiento de prioridades, agrupaci\u00f3n de tareas, reserva de piezas, programaci\u00f3n y tramitaci\u00f3n de permisos) consiste en la aplicaci\u00f3n de reglas a los datos que proporcionan esos dos puntos. Si la solicitud est\u00e1 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\u00e1 de nada.<\/p>\n\n\n\n
Esta observaci\u00f3n nos hizo replantearnos nuestra forma de enfocar la gesti\u00f3n de las \u00f3rdenes de trabajo. El profesional con el que colaboramos no pidi\u00f3 un planificador m\u00e1s inteligente. Lo que pidi\u00f3 fue que las solicitudes llegaran ya listas para ser planificadas y que el cierre registrara lo que hab\u00eda ocurrido. Con esas dos cosas, estaba convencido de que se podr\u00eda eliminar la mayor parte del trabajo manual del planificador.<\/p>\n\n\n\n
Esto tambi\u00e9n explica por qu\u00e9 tantas inversiones en CMMS y EAM resultan decepcionantes. El dinero se destina a la parte intermedia: paneles de control, tableros de planificaci\u00f3n y aplicaciones m\u00f3viles para los planificadores. La interfaz de usuario, es decir, el momento en el que un t\u00e9cnico decide qu\u00e9 datos introducir, se deja exactamente como estaba. El sistema se vuelve m\u00e1s r\u00e1pido a la hora de procesar datos err\u00f3neos.<\/p>\n\n\n\n
Para un responsable de mantenimiento, este principio ofrece un diagn\u00f3stico sencillo. Selecciona al azar 50 solicitudes de trabajo recientes y preg\u00fantate, para cada una de ellas, si un planificador habr\u00eda podido definir su alcance sin necesidad de una llamada telef\u00f3nica. Si menos de 30 superan la prueba, la planta no tiene un problema de planificaci\u00f3n ni de programaci\u00f3n. Tiene un problema de recepci\u00f3n de solicitudes, y la soluci\u00f3n corresponde al departamento de recepci\u00f3n.<\/p>\n\n\n\n
La segunda parte del cierre tiene la misma importancia y, a menudo, es peor. Una orden de trabajo confirmada como \u201crealizada\u201d y con un c\u00f3digo de aver\u00eda predeterminado registra una reparaci\u00f3n, pero no un fallo. El par \u00absolicitud-cierre\u00bb constituye la unidad de datos de fiabilidad; si alguna de las dos partes est\u00e1 vac\u00eda, el registro tambi\u00e9n lo est\u00e1.<\/p>\n\n\n\n
\u00bfC\u00f3mo mejora la gesti\u00f3n de solicitudes basada en IA la calidad de las solicitudes de trabajo sin a\u00f1adir campos?<\/h2>\n\n\n\n
El \u00fanico enfoque que ha funcionado a gran escala consiste en trasladar la responsabilidad de la calidad del t\u00e9cnico al propio proceso de recepci\u00f3n. El t\u00e9cnico describe el problema tal y como se lo explicar\u00eda a un compa\u00f1ero, ya sea verbalmente o con una foto, y el sistema se encarga de estructurarlo: identifica el equipo a partir de la ubicaci\u00f3n y la imagen, redacta el texto detallado, propone los c\u00f3digos de aver\u00eda y de objeto a partir de la biblioteca de tareas y formula las pocas preguntas que har\u00eda un buen planificador. El t\u00e9cnico se limita a verificar, en lugar de escribir.<\/p>\n\n\n\n
As\u00ed es como el m\u00f3dulo de \u00f3rdenes de trabajo de MRO360 gestiona la recepci\u00f3n de pedidos. En la pr\u00e1ctica, realiza cuatro acciones en la fase de solicitud.<\/p>\n\n\n\n
\n- Capturas realizadas sobre el terreno, no desde el terminal.<\/strong> Se introducen la voz y la foto; se genera una notificaci\u00f3n completa y codificada, con la ubicaci\u00f3n funcional, el equipo y el texto descriptivo ya rellenados para que el remitente los confirme.<\/li>\n\n\n\n
- Hace las siete preguntas, y solo esas.<\/strong> \u00bfEst\u00e1 fuera de servicio ahora? \u00bfHay alguna soluci\u00f3n alternativa? \u00bfHoras de trabajo dif\u00edciles? \u00bfQu\u00e9 equipos? \u00bfSe necesitan herramientas especiales? \u00bfTiene alg\u00fan 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\u00e9tico.<\/li>\n\n\n\n
- Comprueba si hay duplicados antes de crearlos.<\/strong> Si ya existe una solicitud abierta relacionada con ese equipo, la nueva se fusiona con ella en lugar de crearse como una nueva, conserv\u00e1ndose la marca de tiempo m\u00e1s antigua para que el contador de MTTR sea correcto.<\/li>\n\n\n\n
- Carga previamente el plan de trabajo.<\/strong> Cuando el operador dispone de listas de tareas vinculadas a c\u00f3digos de objeto y de da\u00f1os, 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.<\/li>\n<\/ul>\n\n\n\n
El profesional con el que colaboramos denomin\u00f3 a este tipo de \u00abinteracci\u00f3n con el sistema\u00bb como la clave que, por fin, conseguir\u00eda que los equipos de campo utilizaran correctamente el CMMS. Tambi\u00e9n se\u00f1al\u00f3 que varios proveedores est\u00e1n compitiendo por conseguirlo, raz\u00f3n por la cual consideramos que la captura sin fricciones es un requisito m\u00ednimo, y que el cuestionario de admisi\u00f3n de siete preguntas y la regla de duplicados son los elementos que modifican la carga de trabajo de los planificadores.<\/p>\n\n\n\n
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\u00f3digo de aver\u00eda real. El sistema elimina la necesidad de escribir y la navegaci\u00f3n, que son las razones por las que los t\u00e9cnicos se saltan los campos. No elimina la necesidad de tomar decisiones.<\/p>\n\n\n\n
Preguntas frecuentes<\/h2>\n\n\n\n
\u00bfCu\u00e1l es la diferencia entre una solicitud de trabajo y una orden de trabajo?<\/strong> Una solicitud de trabajo (una notificaci\u00f3n en SAP PM) registra que se ha detectado un problema que requiere atenci\u00f3n. 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 \u00f3rdenes de trabajo, ya que algunas son duplicadas, otras se rechazan y otras se gestionan como rondas de inspecci\u00f3n del operador.<\/p>\n\n\n\n\u00bfQu\u00e9 es una notificaci\u00f3n de mantenimiento en SAP PM?<\/strong> Una notificaci\u00f3n de mantenimiento es el t\u00e9rmino que utiliza SAP para referirse a una solicitud de trabajo. Incluye el objeto de referencia (ubicaci\u00f3n funcional o equipo), un texto breve y otro extenso, la prioridad, el indicador de aver\u00eda y, de forma opcional, c\u00f3digos de objeto, de da\u00f1o y de causa. Los tipos de notificaci\u00f3n M1 (informe de aver\u00eda), M2 (solicitud de mantenimiento) y M3 (informe de actividad) son los tres est\u00e1ndar, aunque la mayor\u00eda de los operadores configuran los suyos propios.<\/p>\n\n\n\n\u00bfQu\u00e9 campos debe incluir una orden de mantenimiento?<\/strong> Como m\u00ednimo: el equipo o la ubicaci\u00f3n funcional, si el activo est\u00e1 actualmente fuera de servicio, si se dispone de un circuito alternativo o una unidad redundante, una estimaci\u00f3n 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.<\/p>\n\n\n\n\u00bfQu\u00e9 es el indicador de aver\u00eda en SAP y por qu\u00e9 es importante?<\/strong> El indicador de aver\u00eda es una casilla de selecci\u00f3n de la notificaci\u00f3n de SAP que se\u00f1ala que el equipo est\u00e1 averiado en el momento de la notificaci\u00f3n. Es el \u00fanico campo est\u00e1ndar que indica al planificador que el activo est\u00e1 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\u00e1tica no pueden fiarse de ninguna de estas m\u00e9tricas.<\/p>\n\n\n\n\u00bfPor qu\u00e9 los planificadores dedican tanto tiempo a las solicitudes de trabajo?<\/strong> Dado que la mayor\u00eda de las solicitudes llegan con solo una ubicaci\u00f3n y una descripci\u00f3n de una l\u00ednea, 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\u00e1ticamente que dedican su semana a este tipo de gestiones en lugar de a elaborar planes de trabajo.<\/p>\n\n\n\n\u00bfC\u00f3mo afectan las solicitudes de trabajo duplicadas al MTBF?<\/strong> 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\u00f3n consiste en conservar la solicitud m\u00e1s antigua y cancelar las dem\u00e1s con un c\u00f3digo de motivo de duplicado.<\/p>\n\n\n\n\u00bfDeber\u00eda convertirse cada solicitud de trabajo en una orden de trabajo?<\/strong> 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.<\/p>\n\n\n\n\u00bfMejoran los campos obligatorios la calidad de las solicitudes de trabajo?<\/strong> Normalmente no. Los campos obligatorios garantizan que se introduzca un valor, pero no que este sea correcto. En los sitios web que exigen c\u00f3digos de da\u00f1os, suele observarse que una gran parte de los casos se codifican como \u201cotros\u201d o como la primera opci\u00f3n de la lista. Los datos parecen completos, pero son err\u00f3neos, lo cual resulta m\u00e1s dif\u00edcil de detectar que los datos que faltan.<\/p>\n\n\n\n\u00bfC\u00f3mo se mide la calidad de las solicitudes de trabajo?<\/strong> La prueba m\u00e1s 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\u00faa cada una de ellas. Otros indicadores complementarios son la tasa de duplicados, el porcentaje de solicitudes presentadas en relaci\u00f3n con una ubicaci\u00f3n principal en lugar de con un equipo concreto, y el porcentaje de \u00f3rdenes de trabajo cerradas con un c\u00f3digo de aver\u00eda por defecto o \u201cotro\u201d.<\/p>\n\n\n\n\u00bfPuede la IA redactar la solicitud de intervenci\u00f3n para el t\u00e9cnico?<\/strong> El m\u00f3dulo de registro integrado con IA puede redactarlo. A partir de una descripci\u00f3n de voz y una foto, el sistema puede identificar el equipo, proponer el texto completo y los c\u00f3digos, comprobar si hay duplicados y plantear al autor las pocas preguntas que le har\u00eda un planificador. El t\u00e9cnico se limita a confirmar, en lugar de escribir. Este es el enfoque que se utiliza en el m\u00f3dulo de \u00f3rdenes de trabajo de MRO360.<\/p>\n\n\n\n\u00bfQui\u00e9n es responsable de la calidad de las solicitudes de trabajo: el departamento de operaciones o el de mantenimiento?<\/strong> Ambos, pero el peso recae en el departamento de operaciones, ya que son los operadores y los t\u00e9cnicos quienes plantean la mayor\u00eda 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\u00f3n 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\u00f3n por parte de los planificadores como soluci\u00f3n permanente.<\/p>\n\n\n\nDescubre cu\u00e1nto te est\u00e1n costando tus solicitudes de trabajo<\/h2>\n\n\n\n
Si m\u00e1s de un tercio de tu cartera de pedidos requiere una llamada telef\u00f3nica 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\u00f3n err\u00f3nea, y te explicaremos c\u00f3mo el proceso de recepci\u00f3n basado en IA de MRO360 cambia lo que llega al escritorio del planificador.<\/p>\n\n\n\n
Reserva una evaluaci\u00f3n de 30 minutos sobre tu solicitud de trabajo.<\/a><\/strong> Trae 50 notificaciones recientes; nosotros nos encargamos de la puntuaci\u00f3n.<\/p>\n\n\n\n<\/p>","protected":false},"excerpt":{"rendered":"
A maintenance work request (a notification in SAP PM, a work request in Maximo or Oracle) is the only point in the work order lifecycle where the person who saw the problem is still in the loop. Everything a planner, scheduler, buyer and reliability engineer does afterwards is built on what that person typed. A […]<\/p>\n","protected":false},"author":7,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[64],"tags":[113],"class_list":["post-47193","post","type-post","status-publish","format-standard","hentry","category-blog","tag-mro"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.verdantis.com\/es\/wp-json\/wp\/v2\/posts\/47193","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.verdantis.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.verdantis.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.verdantis.com\/es\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/www.verdantis.com\/es\/wp-json\/wp\/v2\/comments?post=47193"}],"version-history":[{"count":1,"href":"https:\/\/www.verdantis.com\/es\/wp-json\/wp\/v2\/posts\/47193\/revisions"}],"predecessor-version":[{"id":47195,"href":"https:\/\/www.verdantis.com\/es\/wp-json\/wp\/v2\/posts\/47193\/revisions\/47195"}],"wp:attachment":[{"href":"https:\/\/www.verdantis.com\/es\/wp-json\/wp\/v2\/media?parent=47193"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.verdantis.com\/es\/wp-json\/wp\/v2\/categories?post=47193"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.verdantis.com\/es\/wp-json\/wp\/v2\/tags?post=47193"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"Solicitud](\"https:\/\/www.verdantis.com\/wp-content\/uploads\/2026\/11\/Maintenance-Work-Request_-Getting-the-Intake-Right-1024x576.png\")
<\/figure>\n\n\n\n