Ejemplo hipotético de una orden de trabajo de mantenimiento

Una orden rellenada se entiende por sus momentos

Una orden legible separa la petición inicial, el alcance revisado, lo previsto y lo asentado al terminar. El caso siguiente usa una línea y códigos imaginarios; no reproduce una orden real ni un formulario oficial.

Pensemos en una solicitud recibida a las 10:14: «sonido intermitente observado» en el activo ficticio P-204. Esa frase conserva lo comunicado; no identifica una avería. En el escenario, alguien asigna el código OT-FICT-204, enlaza una revisión de alcance local, estima dos horas y, al finalizar el caso inventado, registra dos horas y media. La media hora de diferencia se puede calcular; su motivo no está dado.

La tabla separa clases de datos; no es un modelo para rellenar. Los identificadores y sus enlaces dependen del sistema que conserva el registro.

En este caso, 2,5 menos 2,0 son 0,5 horas, un 25 % de la estimación inicial. La cuenta describe solo los valores ficticios; comparar horas reales exige que coincidan el alcance, la unidad y los límites temporales.

Tres formularios de Appendix D, tres trabajos documentales

NPR 8831.2F, Appendix D, reúne ejemplos para la gestión de mantenimiento NASA. La introducción dice que las muestras deben adaptarse a las necesidades del centro, a las capacidades del CMMS y a los sistemas de automatización relacionados. Los formularios no son una plantilla única: el apéndice presenta un trouble-call ticket (D.1), una solicitud de servicios (D.2) y una orden de trabajo de mantenimiento (D.3). Cada uno representa un punto distinto en la gestión del trabajo.

D.1: registrar un aviso pequeño

La sección D.1 describe un trouble-call ticket recibido por teléfono o correo. Puede utilizarse como alternativa a una orden estándar para trabajos pequeños, habitualmente de 20 horas de trabajo o menos, que por lo general no se planifican ni estiman. El propio texto lo presenta como una opción de ese contexto, no como definición de toda orden de trabajo.

Los campos propuestos muestran cómo se transforma una comunicación inicial en un registro utilizable. Incluyen la fecha y hora de recepción, número de ticket, ubicación, prioridad, persona de contacto y teléfono, título breve, descripción detallada y comentarios.

El formulario también deja constancia del taller, las horas de mano de obra por oficio, quién ejecutó el trabajo, materiales usados cuando exceden las existencias de banco, clasificación local y fecha de finalización. La descripción breve incorpora palabras clave para buscar trabajos similares; la descripción detallada puede recoger el trabajo solicitado o el resultado deseado.

Las instrucciones asignan responsabilidades en distintas etapas. La recepción registra lo que obtiene de la solicitud y determina algunos códigos o datos según el sistema del centro. Una supervisión revisa y asigna el ticket. Quien ejecuta anota lo realizado, materiales usados y condiciones inusuales; luego la supervisión comprueba que el formulario esté completo y registra horas.

Cuando vuelve al centro de control, los datos de conclusión pasan al CMMS y al historial de mantenimiento. Si se detecta una necesidad posterior, la fuente prevé que se registre otro ticket o una solicitud de servicios.

Esta secuencia permite leer qué clase de información pertenece a cada momento: recepción, asignación, ejecución, revisión y conclusión. Por ejemplo, “sonido intermitente observado” puede quedar en la descripción de entrada. Si más tarde hay una observación documentada sobre lo realizado, corresponde a comentarios del trabajo. La primera frase no se convierte retroactivamente en diagnóstico por aparecer junto a un estado final.

La guía también explica que no todos los datos deben duplicarse. Si el CMMS ya dispone de una información o puede obtenerla de otro dato, la muestra no requiere volver a registrarla en el ticket; pone el código financiero como ejemplo. En una lectura práctica, una casilla vacía puede significar que ese dato vive en otro módulo, no necesariamente que el sistema carezca de él. Para saberlo hay que conocer cómo está configurado el registro local.

D.2: documentar una petición y su autorización

D.2 empieza desde la perspectiva de quien solicita un servicio. Su propósito es dejar claro qué se pide y proporcionar información suficiente para identificar, describir, autorizar, seguir y atribuir responsabilidad por la petición. Por eso tiene campos que no cumplen la misma función que los datos de un aviso D.1.

La solicitud incluye organización y persona de contacto, fecha, ubicación, prioridad solicitada, fecha de finalización pedida, descripción del trabajo y cualquier coordinación conocida. Un campo específico, “Estimate Only”, indica que el originador solicita solo una estimación de coste en vez de la ejecución inmediata. La solicitud también contempla datos de financiación y firmas según el circuito indicado. La organización de mantenimiento añade número de control, fecha de recepción y, cuando corresponda, número de orden.

Las categorías de coste previstas se desglosan en mano de obra, materiales, equipo y otros costes; después se registra el total estimado. El estado de aprobación distingue trabajo aprobado con los fondos indicados, aprobación sujeta a financiación del originador o rechazo. La firma autorizante y su fecha respaldan la autorización para cargar los fondos especificados en el formulario NASA. Son elementos de esa muestra y de su contexto institucional, no una afirmación de que cualquier empresa deba usar esas casillas.

El flujo descrito también aclara por qué “estimación” y “aprobación” ocupan campos separados. Cuando se pide solo un coste, el centro de control envía la solicitud a quienes preparan la estimación. El paquete devuelto puede contener el detalle del cálculo, un plan de trabajo, una petición de fondos y una ventana tentativa o condicional de programación. La estimación comunica una previsión; el campo de estado comunica qué decisión aparece en el registro.

Para trabajo que requiere planificación y estimación y recibió aprobación preliminar, D.2 describe la preparación de un paquete detallado que vuelve a la autoridad correspondiente para revisión y aprobación final. Si se aprueba, se completan el número de orden, el estado y los comentarios y se notifica al solicitante. Si se deniega, el formulario prevé consignar la decisión y el motivo.

Un bloque de estado interno, no impreso en la muestra, registra fecha, situación y quién tiene la solicitud para actuar; así queda una historia del trámite.

La propia fuente deja abierta la ruta que seguirá un servicio aceptado: puede completarse mediante un trouble-call ticket, una orden de trabajo o un contrato separado según urgencia, alcance y coste, dentro del proceso de gestión de mantenimiento del centro. La solicitud D.2, por tanto, no es sinónimo de la orden que documenta ejecución. Es la entrada y seguimiento de una petición, que puede desembocar en distintos instrumentos.

D.3: documentar el trabajo autorizado y su cierre

D.3 muestra una orden de trabajo de mantenimiento. Appendix D indica que el formulario proporciona autorización y dirección a los talleres y documenta las fases del trabajo y la estimación de costes. Entre sus elementos figuran el número de orden, el número de control de entrada relacionado, prioridad, fechas de inicio y finalización requeridas, contacto, activo, título y descripción general del alcance.

Después presenta líneas de trabajo numeradas, oficio o taller, tareas, horas requeridas, instrucciones especiales y referencias a anexos o planos.

La sección de estimación reúne horas y costes por taller, costes de mano de obra y materiales, reservas o recargos y total. También identifica la base de la estimación. La firma de aprobación y su fecha autorizan la liberación y ejecución de esa orden dentro del circuito NASA; el campo de fecha de finalización registra cuándo se completó. Si se necesitan más líneas o detalles de materiales y equipos, el apéndice muestra hojas complementarias asociadas al mismo número de orden.

La relación entre solicitud y orden tiene un matiz útil. D.3 señala que una orden puede cubrir más de una petición y que una petición puede dar lugar a más de una orden. Los identificadores de entrada y de ejecución responden a preguntas distintas: el primero permite seguir la solicitud; el segundo sigue la orden y las acciones relacionadas a lo largo de su vida. No se deben fundir solo porque una pantalla los presente juntos.

Tras la aprobación final, la fuente describe la distribución de la orden a los talleres, al responsable de materiales y al cliente cuando corresponda. La distribución puede ser electrónica y los destinatarios pueden recibir solo los datos que necesitan. Una vez terminado el trabajo, se registra la fecha de finalización y la información se añade al historial de la instalación.

El cierre forma parte del historial del trabajo; no es por sí mismo una explicación causal de una observación inicial. NASA NODIS, Appendix D, §§D.1.1–D.1.3 y D.2.1–D.2.3, lector HTML líneas 20–101; §§D.3.1–D.3.3, lector HTML líneas 103–158

De la fecha requerida a la asignación diaria

En D.3, la prioridad de una orden puede diferir de la que pidió quien originó la solicitud. RSD recoge la fecha requerida de inicio. NASA explica que es la fecha en que el trabajo puede comenzar o está previsto que comience, según el caso; puede depender de la disponibilidad de la instalación o del tiempo necesario para llegar a la RCD, la fecha de conclusión requerida.

Si el ejemplo P-204 mostrara ambos formularios, conservaría por separado la prioridad solicitada y la que figura en la orden. Sustituir una por otra ocultaría una decisión del trámite. NASA NODIS, Appendix D, §D.3.2, HTML líneas 440–446

En el proceso descrito por NASA, después de la aprobación final la orden se asigna a un plan de carga del taller. El plan suele prepararse por trimestre y mirar 18 meses hacia delante; su último tramo incluye trabajo estimado y aprobado que aún no tiene programación. Esa asignación inicia la ejecución y activa la adquisición de materiales para el periodo de inicio asignado.

El caso ficticio no contiene una fecha que permita afirmar cuándo ocurrió ese paso. NASA NODIS, Appendix D, §D.4.3, HTML líneas 668–673

El plan también sitúa el trabajo frente a la capacidad de cada taller. La muestra separa horas brutas disponibles, ajustes por actividades que restan disponibilidad y horas netas; después resta los compromisos programados y el trabajo arrastrado del periodo anterior para calcular lo que queda disponible.

En P-204, las dos horas estimadas describen el trabajo, pero no revelan si el taller tiene capacidad para encajarlo: para eso hace falta mirar el resto de la carga y el arrastre del periodo. NASA NODIS, Appendix D, §D.4.2, HTML líneas 582–623

El master schedule baja el horizonte a semanas. Normalmente cubre de seis a diez y señala los trabajos que esperan materiales y deberían empezar durante ese periodo; los materiales de plazo largo pueden llevar la programación más lejos. También coordina órdenes que requieren varios talleres y distribuye horas según la capacidad disponible.

Por eso, que una orden aprobada figure en el plan de carga no permite saber en qué semana empieza P-204; ese dato se busca en el registro semanal. NASA NODIS, Appendix D, §§D.5.1 y D.5.3, HTML líneas 681 y 764–768

La shop schedule cubre el día a día: asigna trabajadores y equipos a las órdenes. En esa etapa se incorporan las horas asignadas a cada orden y empleado; el resto de los campos procede de datos ya registrados en el CMMS u otros procesos.

Al seguir el P-204, la pregunta cambia en cada nivel: ¿está en el plan?, ¿qué semana le asignaron?, ¿quién y con qué equipo lo ejecuta ese día? Solo los registros de esos niveles permitirían responderlo para el caso. NASA NODIS, §§D.6.1–D.6.2, HTML líneas 780–784

Cómo distinguir una entrada de otra

Una misma descripción breve puede aparecer en documentos diferentes, pero lo que se espera registrar cambia según la pregunta que se está atendiendo.

En P-204, la estimación previa hace que D.1 sea solo una comparación: NASA describe allí trabajos que por lo general no se planifican ni estiman. D.2 sería pertinente si se solicitó una estimación de coste; D.3, si el trabajo quedó planificado y autorizado.

Al elegir el registro, identifica qué evento debe conservarse y qué documento cumple esa función en el sistema local.

Comparar horas con la misma base

Para comparar dos registros, define si las horas cubren el alcance completo o una tarea, y si incluyen esperas. Mantén la misma unidad y los mismos límites de inicio y fin. Las cifras de P-204 solo permiten calcular una diferencia; sin esos criterios y el expediente del trabajo, no explican su origen.

Mantener la procedencia y evitar duplicados

Appendix D distribuye los datos según su origen y etapa: quien solicita describe la necesidad, la ejecución registra lo realizado y el circuito NASA deja constancia de la aprobación. La configuración local puede asignar responsabilidades de otro modo, pero debe permitir separar lo recibido de lo añadido durante la gestión.

D.1 indica que no hace falta repetir información disponible en el CMMS o derivable de otros campos. Antes de copiar una ubicación o un código, identifica qué registro mantiene el valor y qué vínculo permite recuperarlo. D.3 asocia las hojas complementarias y referencias a planos con el número de orden, lo que permite localizar el detalle sin duplicarlo en la orden principal.

Alcance de las fuentes

NODIS identifica NPR 8831.2F con fecha efectiva del 7 de octubre de 2015, Change 1 del 2 de septiembre de 2016 y fecha de expiración indicada del 30 de junio de 2027. El sitio señala que la directiva obliga a personal NASA y que no vincula al público salvo por ley o contrato. Appendix D es una referencia interna NASA, no un formulario establecido para una planta española.

En España, el artículo 3 del Real Decreto 1215/1997 recoge obligaciones generales del empresario relativas a equipos de trabajo, mantenimiento y condiciones de utilización; no define los campos de una orden ni adopta el flujo NASA. Estas referencias delimitan el contexto, no evalúan el cumplimiento de una instalación. NASA NODIS, NPR 8831.2F, Appendix D BOE, Real Decreto 1215/1997, art. 3, PDF pp. 3–4