Modelo de datos de la solicitud de trabajo: campos, estados y triaje

Puntos clave

• Una solicitud es una petición y una orden de trabajo es un compromiso. Una solicitud puede convertirse en cero órdenes de trabajo, en una, o en una línea de un trabajo que ya existe.
• Mantenga nueve estados, no dos. Rechazada, duplicada, fusionada y retirada son datos, y un sistema que las borra destruye la señal de demanda que se compró para medir.
• La urgencia del solicitante, la criticidad del activo y la prioridad final del programador son tres campos. En la línea de abajo discreparon en 20 de 44 solicitudes decididas.
• Un mes de 60 solicitudes da una tasa de aprobación del 60,0% o del 81,8%, una diferencia de 21,8 puntos porcentuales, solo por qué filas entran en el denominador.
• La mediana del tiempo hasta la revisión, con las mismas filas, es de 6,0 horas sobre 58 solicitudes revisadas y de 10,0 horas sobre las 44 distintas.

Una solicitud es una petición, una orden de trabajo es un compromiso

Una solicitud de trabajo es alguien avisando a mantenimiento de que algo necesita atención. No se ha prometido nada, no se ha asignado a nadie y no se ha movido presupuesto.

Una orden de trabajo es la planta comprometiendo mano de obra, repuestos y tiempo con un activo concreto. Tiene un responsable, una prioridad, una duración planificada y un coste.

Una solicitud puede no convertirse en ninguna orden de trabajo, en una sola, o en una tarea añadida a un trabajo ya programado. Dos solicitudes también pueden converger en una única orden de trabajo.

Lo que le cuesta juntar ambas

Junte solicitud y orden de trabajo en una sola tabla y las filas que nunca se convirtieron en trabajo no tienen clave propia. Se editan hasta convertirse en órdenes de trabajo, o se borran.

En el mes que se analiza abajo, 60 solicitudes produjeron 31 conversiones. Un sistema de una sola tabla muestra por tanto 31 filas donde 60 personas pidieron algo.

Eso oculta 29 solicitudes, el 48,3% de todo lo planteado. La mitad oculta es la mitad interesante: los rechazos, los duplicados y las peticiones que nunca recibieron respuesta.

La consecuencia para los informes es precisa, y conviene decirla despacio. Su informe de cartera pendiente se convierte en un informe sobre sus propias decisiones y no sobre la planta, porque la única demanda que puede ver es la que usted ya aceptó.

Qué cubre esta página que las demás no

La diferencia conceptual, argumentada con ejemplos, está en nuestra guía orden de trabajo frente a solicitud de trabajo. Cómo funciona la recepción día a día se trata en sistema de solicitudes de trabajo de mantenimiento.

Lo que añade esta página es el propio registro: los campos, los nueve estados y sus transiciones permitidas, el tratamiento de rechazos y duplicados, las definiciones de tiempos de respuesta y la unión con las órdenes de trabajo que responden a una solicitud.

No vuelve a especificar la orden de trabajo. Eso corresponde a nuestro modelo de datos de la orden de fabricación y al modelo de datos de CMMS más amplio.

La cabecera de la solicitud, campo a campo

Doce campos llevan la petición. Todo lo demás en una solicitud es una decisión sobre la petición, y las decisiones pertenecen al registro de revisión que aparece más abajo.

asset_id debe apuntar a una fila, nunca a texto tecleado. Una solicitud contra "la llenadora" es inservible en cuanto tiene tres llenadoras, y ninguna limpieza posterior recupera cuál se quería decir.

Dónde termina el registro de activos y empieza una ubicación es una cuestión de diseño propia, tratada en nuestro modelo de datos de la jerarquía de activos. La regla corta para las solicitudes: apunte al nodo más profundo que el solicitante pueda identificar realmente desde donde está.

production_impact está separado de la urgencia a propósito. El impacto es una observación sobre la línea en este momento, y la urgencia es una opinión sobre cuándo debería venir alguien.

El solicitante

Seis campos identifican quién pidió y cómo responderle. Todos son baratos, y el primero es el que las plantas hacen mal con más frecuencia.

requester_shift importa porque es la única forma honesta de comparar la recepción en toda una planta. Sin él, un recuento diario bruto no puede decirle si un turno tranquilo estuvo tranquilo o simplemente no avisó.

notify_on_decision no es un detalle. Un solicitante que nunca recibe respuesta deja de plantear solicitudes, y la recepción cae sin que nadie haya decidido que caiga.

La revisión: la decisión de triaje

La revisión es un registro aparte porque es un acto aparte de una persona distinta. La llevan diez campos, y cada uno responde a una pregunta que hará un auditor.

criticality_at_screen es el campo que nadie especifica y que todos echan de menos después. La criticidad de los activos se reevalúa una o dos veces al año, y una unión en vivo reescribe en silencio cada decisión histórica a la mañana siguiente.

decision_reason tiene que estar codificado. Un motivo en texto libre no se puede contar, y todo el sentido de los datos de revisión es contar con qué frecuencia aparece cada motivo.

El vínculo entre una solicitud y el trabajo que causó

La unión es de muchos a muchos, así que necesita su propia tabla. Una clave foránea en cualquiera de los dos lados estará mal antes de un mes en producción.

linked_by es el campo que mantiene honesto el registro sobre quién actuó. Una persona revisa, una persona aprueba y una persona crea la orden de trabajo, y la fila de vínculo es donde se nombra a esa persona.

En el mes de abajo, 31 solicitudes convertidas produjeron 27 órdenes de trabajo distintas, porque cuatro solicitudes se vincularon a un trabajo que ya existía. Eso es 31 ÷ 27 = 1,15 solicitudes por orden de trabajo.

La trampa del recuento está justo ahí. "Órdenes de trabajo procedentes de solicitudes" son 27 y "solicitudes respondidas con trabajo" son 31, y son dos preguntas distintas que parecen la misma.

El ciclo de vida de los estados

Nueve estados, y cada uno es un resultado real del que alguien tiene que poder informar. Un modelo de dos estados, abierta y cerrada, tira todo lo que vale la pena saber.

Seis de los nueve son finales, y es deliberado. Una solicitud que ya ha sido respondida no debe reabrirse, porque reabrirla destruye el tiempo de respuesta que ya se registró contra ella.

Quién la mueve y qué hay que rellenar

Dos reglas hacen esta tabla exigible en lugar de decorativa. No se puede entrar en un estado hasta que estén sus campos obligatorios, y en cada transición se nombra a una persona.

Fíjese también en que Convertida es un movimiento del planificador y exige una fila de vínculo. Una solicitud nunca se cambia sola, y ningún sistema debería crear trabajo a partir de ella sin que una persona lo confirme.

El rechazo es un dato, no un borrado

Una solicitud rechazada es una de las filas más valiosas de todo el modelo. Es el registro de una demanda que la planta decidió conscientemente no atender.

Borrarla, o dejar que simplemente desaparezca de la pantalla del solicitante, destruye esa prueba. Seis campos hacen que un rechazo sea auditable.

notified_at es el campo que cambia el comportamiento en planta. Es la diferencia entre una decisión y una decisión de la que alguien se enteró.

Seis códigos de rechazo bastan para casi cualquier planta. Con más de unos ocho, los revisores empiezan a elegir el primero que parece plausible de la lista.

RJ6 es el que debe existir y el que los proveedores rara vez ofrecen. Algunas solicitudes se rechazan a sabiendas, con el riesgo aceptado por una persona con nombre, y eso es un hecho completamente distinto de "no es una avería".

Vigile también RJ2. Las solicitudes rechazadas porque un trabajo planificado ya las cubre le dicen que el plan de mantenimiento preventivo no es visible para las personas que están en las máquinas.

Los duplicados y las fusiones cambian lo que se cuenta

Un puntero duplicate_of dice que esta fila describe el mismo problema que aquella. No dice que esta fila no debería haber existido nunca.

El puntero crea dos recuentos legítimos: solicitudes brutas y problemas distintos.

En el mes de abajo se plantearon 60 solicitudes. Nueve eran duplicadas y tres se fusionaron en otras solicitudes, así que la demanda distinta es de 48.

El recuento bruto es por tanto un 25,0% más alto que el recuento distinto, ya que 60 ÷ 48 = 1,25. Ninguna de las dos cifras está mal, y citar cualquiera de ellas sin su definición sí lo está.

Por qué la fusión es la peligrosa

Marcar una duplicada conserva la fila y añade un puntero. La fusión, tal como la implementa la mayoría de los sistemas, mueve el contenido de una solicitud a otra y deja una fila donde había dos.

Eso destruye en silencio la señal de demanda. El segundo solicitante desaparece, el segundo submitted_at desaparece, y el tiempo de respuesta para esa persona nunca se mide porque su solicitud ya no existe.

Si fusiona, registre la fusión. Mantenga la fila de origen en estado Fusionada con merged_into relleno, su propio submitted_at, su propio solicitante y su propio screened_at.

El tiempo de respuesta no es el tiempo de reparación

Las solicitudes generan sus propios relojes, y esos relojes miden la capacidad de respuesta del departamento de mantenimiento, no la duración de una reparación. Importan cuatro intervalos, y no son intercambiables.

Cada intervalo necesita su denominador impreso al lado, porque los cuatro se calculan sobre conjuntos de filas distintos.

Dos de ellos una planta puede medirlos honestamente solo con campos de la solicitud. Solicitud a revisión y solicitud a aprobación usan solo submitted_at, screened_at y approved_at, que están todos en la solicitud.

Solicitud a respuesta también se puede medir, y es el que les importa a los solicitantes, pero solo si notified_at se escribe cuando el mensaje se envía de verdad.

Solicitud a inicio del trabajo es distinto. Va a la tabla de órdenes de trabajo a buscar una hora real de inicio, y solo es tan bueno como la disciplina de iniciar los trabajos en el sistema y no en la máquina.

Ninguno de ellos es tiempo de reparación. El tiempo de reparación empieza cuando un técnico coge las herramientas y termina cuando el activo vuelve a funcionar, como define con precisión nuestra guía del tiempo medio de reparación.

La confusión sale cara porque los dos se mueven de forma independiente. Una planta puede reducir el tiempo de solicitud a revisión de dos días a dos horas sin cambiar el MTTR ni un minuto, y eso es una mejora real y comunicable.

Urgencia, criticidad y prioridad son tres campos

Casi todos los sistemas vienen con un solo campo llamado prioridad, y casi todas las plantas lo llenan con tres significados distintos. El resultado es una columna en la que nadie sabe quién tomó la decisión.

La urgencia es una opinión, y tiene derecho a serlo. El operario le está diciendo cuánto le está perjudicando esto ahora mismo, y es información que usted quiere incluso cuando se equivoca.

La criticidad es una propiedad del activo, revisada cada año. No sabe nada de esta mañana.

La prioridad es la decisión, tomada por alguien que ve la urgencia y la criticidad además del programa, los repuestos y las solicitudes de todos los demás.

Un caso resuelto en el que los tres discrepan

Tres solicitudes de la misma semana en la línea LINE‑03, con la urgencia, la criticidad y la prioridad final una al lado de otra.

REQ‑2026‑0412 es un enclavamiento de seguridad en una máquina con criticidad C3. Aquí no manda la criticidad, y el revisor la subió a P1 aunque el activo no tiene nada de especial.

REQ‑2026‑0418 llegó como una nota de baja urgencia de un planificador que recorría la línea. El activo es C1, un rezume se convierte en una fuga, y el revisor la subió a P2 en contra de la opinión del propio solicitante.

REQ‑2026‑0423 es la incómoda. El operario la quería ya, la paletizadora es una unidad de reserva, y el revisor la bajó a P4 y tuvo que escribir un motivo que el operario leería.

Ahora junte los tres campos en uno. REQ‑2026‑0423 llega como P1 y se queda en P1, o el revisor la sobrescribe a P4 y el U1 del operario desaparece para siempre.

En las 44 solicitudes decididas del mes de abajo, la urgencia y la prioridad final coincidieron en 24. El revisor bajó 14 y subió 6, así que 20 de 44, el 45,5%, se cambiaron.

Ejemplo resuelto: un mes de solicitudes en una línea

Línea LINE‑03, un mes natural, 60 solicitudes planteadas por operarios y supervisores. Cada cifra de abajo sale de estas filas.

1. El mes, conciliado

Compruebe la aritmética antes que nada: 31 + 5 + 6 + 9 + 3 + 2 + 2 + 2 = 60. Un mes que no concilia con el recuento bruto tiene filas en un estado sobre el que nadie se ha puesto de acuerdo.

Las solicitudes que llegaron a Aprobada son 31 + 5 = 36. Las solicitudes que se revisaron son 60 menos las 2 que siguen esperando, es decir, 58.

Las 31 conversiones produjeron 27 órdenes de trabajo, cuatro de ellas vinculadas a trabajos que ya estaban en el programa. La demanda distinta, tras quitar 9 duplicadas y 3 fusiones, es de 48.

2. La tasa de aprobación, calculada de dos formas defendibles

Ambos métodos usan las mismas 60 filas y la misma definición de "aprobada". Solo cambia el denominador.

El método B divide por las solicitudes que recibieron una decisión de revisión real sobre demanda distinta: 31 + 5 + 6 + 2 = 44. Excluye las 9 duplicadas, las 3 fusiones y las 2 retiradas, ninguna de las cuales es una decisión sobre un problema distinto, y las 2 que siguen esperando.

El método A da 36 ÷ 60 = 60,0%. El método B da 36 ÷ 44 = 81,8%.

La diferencia es de 21,8 puntos porcentuales, por un denominador que se movió 16 solicitudes. Nada en la planta cambió entre los dos cálculos.

Los dos son defendibles, y un proveedor que cita una tasa de aprobación cita uno de ellos sin decirle cuál. Pregunte, y escriba la respuesta en su estándar de informes el día que entre en producción.

3. Mediana del tiempo hasta la revisión, con las mismas filas

Cada solicitud revisada lleva screened_at menos submitted_at en horas transcurridas. Esta es la distribución completa, una vez para las 58 solicitudes revisadas y otra para las 44 distintas decididas.

Con 58 valores la mediana es la media del 29.º y el 30.º. Los recuentos acumulados son 9, 16, 22, 27, 32, así que ambos valores caen en el intervalo de 6 horas y la mediana es de 6,0 horas.

Con 44 valores la mediana es la media del 22.º y el 23.º. Los recuentos acumulados son 1, 5, 9, 13, 18, 22, 26, lo que sitúa el 22.º en 8 horas y el 23.º en 12 horas.

Eso da (8 + 12) ÷ 2 = 10,0 horas. Mismo campo, mismo mes, mismo reloj: 6,0 horas o 10,0 horas.

La diferencia es de 4,0 horas, una mediana un 66,7% más alta sobre un conjunto de filas 14 solicitudes más pequeño. De nuevo, nada cambió en la línea.

4. Por qué la definición movió la cifra

Las 14 filas excluidas no eran una muestra aleatoria. Las duplicadas y las retiradas se revisan más rápido, porque reconocer una petición que ya ha visto lleva segundos.

Ocho de las nueve solicitudes más rápidas del mes eran duplicadas o retiradas. Quítelas y el extremo rápido de la distribución se hunde, así que la mediana sube por la cola.

Esta es toda la lección del ejemplo. Un indicador de solicitudes es una afirmación sobre un conjunto de filas, y el conjunto de filas es una elección que alguien hizo, normalmente sin escribirla.

La defensa es una sola línea en el encabezado del informe que nombre la población. "Mediana de solicitud a revisión, 58 solicitudes revisadas, duplicadas y retiradas incluidas" es reproducible y "tiempo de respuesta mediano 6 horas" no lo es.

La misma disciplina se aplica a la antigüedad de la cartera pendiente, que es otra mediana sobre un conjunto de filas que cambia de forma a medida que se vacía. Nuestra guía de gestión de la cartera de mantenimiento trabaja ese lado.

Cinco preguntas para un proveedor sobre los datos de solicitudes

1. ¿Una solicitud es un registro aparte con su propia clave? Pídales que muestren una solicitud rechazada hace seis meses, con el motivo del rechazo y el nombre de quien la rechazó, sin abrir una orden de trabajo.
2. ¿Pueden dos solicitudes apuntar a una orden de trabajo, y una solicitud a dos? Pídales que hagan ambas cosas delante de usted y que luego muestren a qué solicitudes responde una orden de trabajo dada.
3. ¿Qué pasa con la segunda solicitud cuando se fusiona? Pregunte cuántas personas avisaron del problema y cuándo se informó a cada una, después de hecha la fusión.
4. ¿La urgencia y la prioridad son dos campos? Pregunte qué eligió el solicitante y qué fijó finalmente el revisor, en una solicitud en la que ambos difieren.
5. ¿Por qué divide exactamente su informe de tiempo de respuesta? Pregunte si las duplicadas, las retiradas y las solicitudes sin revisar están en el denominador, y pida verlo indicado en el propio informe.

La quinta pregunta es la que separa las herramientas. Cualquier sistema le mostrará un tiempo de respuesta medio, y muy pocos imprimirán la población que lo produjo, que es la diferencia que vale la pena probar al comparar software de mantenimiento de equipos.

Cómo ayuda Fabrico

Fabrico es una plataforma de OEE con un CMMS completo integrado, así que las solicitudes, las órdenes de trabajo y los datos de máquina están en un solo sistema.

Las solicitudes avanzan por un flujo de estados con flujos de aprobación, y hay un flujo específico de emergencias y correctivos que registra el tiempo de reacción para las urgentes.

Su equipo las plantea desde la aplicación para iOS, Android o web, con escáneres QR en máquinas y repuestos para que se vincule el activo correcto sin teclear, y con creación de tareas rápida o detallada según quién la rellene.

Las notificaciones push, en la aplicación y por correo electrónico con reglas inteligentes llevan la decisión de vuelta a quien pidió, y el registro de auditoría guarda quién hizo qué.

Los análisis cubren la distribución de tareas, la productividad por empleado, el MTTR y el MTBF, con exportación a Excel, una API REST y conectores para SAP y otros ERP cuando las cifras tienen que salir del sistema.

Lo que Fabrico no hace: no planifica ni programa la producción, no pide repuestos por su cuenta y no tiene un producto de mantenimiento predictivo.

Una orden de trabajo siempre la crea y la confirma su equipo. Una persona revisa la solicitud, una persona la aprueba y una persona crea el trabajo.

Todo lo demás de esta página, incluidos los nueve estados, los códigos de rechazo y la tabla de vínculos, es una especificación con la que poner a prueba a un proveedor, no una lista de funciones.

¿Quiere ver cómo fluirían sus solicitudes desde la máquina hasta una decisión? Reserve una demo de 30 minutos con un consultor de Fabrico, sin compromiso, o contáctenos con sus preguntas.