Una orden de trabajo (OT) no es simplemente un formulario en blanco. Es un registro que ayuda a coordinar una actividad desde que surge una necesidad hasta que queda asentado lo que ocurrió. En la práctica se deben poder distinguir, como mínimo, la observación inicial, la revisión del alcance, la aprobación aplicable, la ejecución registrada y el cierre administrativo o técnico que corresponda.
Una OT aprobada conforme al proceso del centro puede autorizar y dirigir el trabajo. Esa autorización local no sustituye el permiso de seguridad, la evaluación de riesgos ni los demás controles que correspondan a la tarea.
El apéndice D de la directiva NASA NPR 8831.2F presenta formularios de gestión del mantenimiento utilizados como ejemplo en el contexto interno de la agencia: incluye campos de activos, prioridad, fechas, tareas, recursos y aprobación, además de apartados de comentarios y cierre.
NODIS muestra la revisión F con vigencia indicada del 7 de octubre de 2015 al 30 de junio de 2027 y Change 1 de septiembre de 2016.
NASA advierte que la directiva no vincula al público salvo cuando una ley o contrato así lo establezca; por eso se usa aquí como referencia documental, no como norma de una planta española. NASA NODIS Appendix D: lector líneas 5–6 (vigencia; HTML retenido líneas 105–106), línea 13 (Change 1; HTML retenido línea 117), línea 267 (alcance público; HTML retenido línea 900); §D.3.1, HTML retenido desde línea 404; §D.3.3a, HTML retenido línea 562
Solicitud, orden, permiso y cierre no son sinónimos
Una solicitud comunica una necesidad; una orden organiza el trabajo que se haya aceptado en el proceso local. Un permiso o control de seguridad responde a otra pregunta y puede tener su propio responsable y vigencia. El cierre registra lo ocurrido, pero no demuestra por sí solo la causa de una avería ni que haya desaparecido un riesgo.
El artículo 3 del Real Decreto 1215/1997 establece obligaciones generales sobre adecuación y mantenimiento de equipos de trabajo. No exige un documento llamado “OT” ni convierte una orden interna en permiso legal. La referencia se limita a su ámbito español; NASA aporta un ejemplo institucional estadounidense, no una plantilla obligatoria. BOE, Real Decreto 1215/1997, art. 3, PDF pp. 3–4
Un ciclo de registro que se puede entender
Como síntesis editorial, el registro puede leerse en cuatro tramos: se recibe una necesidad; se revisa qué información y autorización local hacen falta; se documenta el alcance y la ejecución; y se registra el cierre junto con los seguimientos que continúen abiertos. NASA muestra formularios para algunas de esas fases, pero no prescribe esta secuencia para otros centros. Los responsables y criterios dependen del procedimiento local.
Qué campos ayudan a reconstruir el trabajo
El formulario de NASA incluye diferentes bloques. D.3.1 describe un modelo genérico de orden de mantenimiento y señala que los formularios reales deben adaptarse a las necesidades del centro y al CMMS usado. En la versión web de NODIS, D.3.1 empieza en HTML línea 404; las tablas y apartados siguientes muestran ejemplos de identificadores, activo, prioridad, fechas, tareas, estimaciones, materiales, aprobaciones y comentarios.
La misma nota de adaptación impide presentar esos campos como una plantilla universal. NASA NODIS, NPR 8831.2F, Appendix D, D.3.1, HTML lines 404 onward
| Grupo de información | Para qué ayuda | Precaución al leerlo |
|---|---|---|
| Identidad y activo | Enlazar trabajo con el equipo o ubicación correctos | El nombre debe permitir distinguir activos similares |
| Solicitud y observación | Conservar la necesidad recibida y sus datos de origen | No confundir el texto reportado con un diagnóstico |
| Alcance y tareas | Expresar lo que se revisó para la orden | No copiar una tarea de otro equipo sin comprobar su aplicabilidad |
| Prioridad y fechas | Facilitar la gestión temporal según criterios locales | La etiqueta de prioridad necesita una definición interna |
| Recursos estimados | Anticipar materiales o tiempo previstos | Una estimación no es el consumo o tiempo real |
| Asignación y aprobación | Registrar funciones y estados del flujo | No es sustituto automático de autorización de seguridad |
| Comentarios y cierre | Dejar evidencia de lo anotado durante y al finalizar | El cierre no equivale por sí solo a un análisis causal |
Un esquema de trabajo puede mantener campos “estimado” y “real” en columnas separadas. Si la previsión era de cuatro horas y el registro final muestra siete, la diferencia es una observación de gestión que puede requerir explicación. No se debe modificar retroactivamente la estimación para hacerla coincidir con el resultado, ni presentar la diferencia como una causa confirmada sin análisis.
Las fechas también requieren significado. “Fecha de apertura” podría ser el momento en que se creó el registro; “fecha de recepción”, cuando llegó la solicitud; y “fecha de inicio”, un evento posterior. Si se intercambian por conveniencia, el historial puede dejar de permitir una comparación clara. Los nombres deben reflejar lo que el sistema registra realmente, con zona horaria y fuente de evento cuando resulte pertinente.
La prioridad no significa lo mismo en todas las organizaciones. Una escala local puede representar urgencia, impacto de producción, riesgo, disponibilidad de recursos o una combinación. Si se usa una categoría como “alta”, documenta qué sistema la define y qué decisión afecta. No inferimos a partir del formulario NASA que los criterios de priorización sean transferibles a una fábrica de otro país o sector.
Solicitud, aprobación y cierre en el ejemplo NASA
El apéndice D diferencia el seguimiento de una solicitud de la orden de mantenimiento. En su proceso, el centro de control de trabajo registra fecha, estado y responsable de la acción a medida que la solicitud avanza; NASA indica que esto proporciona un historial de la solicitud.
Ese historial documenta su recorrido, pero no equivale por sí solo a un diagnóstico, a la aprobación de una orden ni a una constancia de que el trabajo terminó. NASA NODIS, Appendix D, §D.2, HTML retenido línea 396
La orden tiene otro papel en esa muestra: una vez que recibe la aprobación final, proporciona autorización y dirección a los talleres y documenta fases de trabajo y una estimación de coste. El documento de continuación amplía el formulario, y el formulario de materiales y equipos requeridos registra esos recursos. NODIS indica que las plantillas reales deben adaptarse a las necesidades del centro y a su CMMS.
Por eso la utilidad de la muestra está en mostrar que distintos documentos pueden acompañar una orden, no en afirmar que cada organización deba crear esos mismos anexos. NASA NODIS, §§D.3.1 y D.3.3a, HTML retenido líneas 404 y 562
La distribución también está descrita como parte de ese contexto: después de la aprobación final, la orden se distribuye a los talleres, al responsable de materiales, al cliente si solicitó el trabajo y a otras personas según la política del centro. Si se distribuye electrónicamente, pueden enviarse extractos con los datos necesarios para cada destinatario; la fuente no propone una única vista compartida para todos.
En consecuencia, al leer un registro digital conviene distinguir quién conserva el expediente íntegro y qué información recibe cada participante, sin interpretar una pantalla parcial como todo el historial. NASA NODIS, §D.3.3b, HTML retenido línea 566
Al completarse la orden, NASA indica que se cierra, se registra la fecha de finalización y se añade la información al historial de instalaciones; esa fecha se comunica al centro de control de trabajo. El campo de persona responsable de una acción en el historial de solicitud identifica quién actuó en esa etapa; no basta para concluir que esa persona fuera quien aprobó la orden.
Es un ejemplo concreto de traspaso entre seguimiento de solicitud, ejecución documentada y cierre. No prescribe los nombres de estados ni los responsables que deben usar otros centros, y tampoco demuestra que una orden cerrada descarte una investigación o seguimiento separado. NASA NODIS, §D.3.3c, HTML retenido línea 570
Una comprobación práctica de enlaces y fechas
La diferencia entre WICN y W.O. # permite probar si el sistema conserva la relación entre aviso y trabajo. Para ilustrarlo, supón que un aviso ficticio REQ-14 termina generando dos órdenes de prueba, OT-8 y OT-9; en otro caso, OT-30 agrupa dos avisos ficticios. No son números ni casos NASA. Solo representan las dos relaciones que NODIS admite en su descripción del formulario.
| Comprobación | Qué revisar en los registros | Qué hacer con una discrepancia |
|---|---|---|
| Recorrer los vínculos | Desde cada solicitud, localizar las órdenes asociadas; desde cada orden, volver a las solicitudes que cubre. | Anotar un enlace ausente como una carencia de trazabilidad, no completar la relación por suposición. |
| Comparar prioridades | Separar la prioridad solicitada de la asignada en la orden. | Conservar ambas si el sistema las registra y consultar el criterio local para explicar el cambio. |
| Interpretar fechas | Diferenciar la fecha requerida para empezar, la fecha límite solicitada y la fecha real de finalización. | No sustituir un evento por otro para que el registro parezca coherente; documentar qué campo representa cada fecha. |
| Seguir alcance y recursos | Relacionar las tareas y horas estimadas con la orden y, cuando exista, la hoja separada de materiales/equipos. | Mantener la estimación distinta del dato final y enlazar continuaciones por el identificador de la orden. |
| Leer el cierre | Comprobar que la fecha de finalización y la información incorporada al historial pueden localizarse. | No inferir de una orden cerrada que se aprobaron otros controles o que no queda seguimiento. |
El valor de esta comprobación es detectar si una persona puede reconstruir el recorrido, no demostrar que una herramienta mejora el mantenimiento. NODIS señala que sus formularios reales deben adaptarse al centro y al CMMS; una organización puede usar otros nombres o relaciones. Las preguntas sirven para revisar la coherencia del registro existente, no para imponer campos nuevos.
Las cifras de una orden también necesitan contexto
La muestra NASA separa varios tipos de cifra. En las líneas de trabajo, HRS expresa el tiempo de labor requerido y normalmente se basa en un estándar de estimación. El resumen estima horas y costes de labor y materiales por grupo de trabajo; también puede reflejar contingencias, gastos generales o recargos. El campo “Estimate Basis” identifica la base o el estándar utilizado.
Esos elementos describen una previsión, no el resultado real ni una promesa de duración. NASA NODIS, NPR 8831.2F, Appendix D, §D.3.2, HTML retenido líneas 494, 506 y 515
La hoja de materiales y equipos está separada del formulario principal. Puede incluir un identificador, descripción, unidad de medida, cantidad, coste unitario y total, además de disponibilidad o fecha prevista de entrega. NODIS describe estos campos en su ejemplo y explica que la plantilla debe adaptarse al centro y al sistema utilizado.
Una cifra sin unidad, alcance o base de cálculo resulta difícil de comparar con otra orden, aunque ambas aparezcan como “horas” o “coste total”. NASA NODIS, NPR 8831.2F, Appendix D, §§D.3.1–D.3.2, HTML retenido líneas 404–405 y 531–551
Al revisar un caso local, pregunta primero si la estimación y el dato de cierre describen el mismo alcance y el mismo grupo de trabajo. Después comprueba si la base de estimación se conserva y si los costes de material están separados de la mano de obra.
Una diferencia entre cuatro horas estimadas y siete registradas puede ser una señal para investigar, pero no identifica por sí sola el motivo: pudieron cambiar el alcance, la disponibilidad de recursos o las condiciones del trabajo. Esa lista de preguntas es una lectura editorial de los campos, no un método NASA para evaluar productividad ni una causa de desviación demostrada.
La disponibilidad de una pieza tampoco cuenta toda la historia. El registro puede indicar que un material estaba en stock o cuándo se esperaba su entrega, pero esa anotación no demuestra que la pieza se instalara ni que su ausencia causara una demora. Si el sistema local registra recepción, consumo y devolución por separado, esos eventos deberían conservar sus propias fechas e identificadores.
La muestra NASA orienta sobre datos que pueden acompañar la orden; no demuestra que todos estén presentes en una implementación concreta.
Ejemplo hipotético: de observación a registro
Supongamos que un operario de una línea ficticia de envasado registra a las 10:14 un ruido intermitente cerca del conjunto marcado “P-204”. No atribuye la causa ni propone una reparación. La solicitud conserva la hora, ubicación, activo, descripción literal y medio de contacto, y queda con estado “pendiente de revisión”. Toda esta situación es inventada para explicar la diferencia entre observación y autorización; no representa un incidente real.
Después, una persona responsable del proceso revisa si la información identifica el equipo y determina si hace falta ampliar el reporte. En el ejemplo, el registro puede enlazar una referencia de alcance una vez que sea revisada conforme al proceso local. La página no dice cuál debería ser ese alcance ni qué trabajo se realizaría. Cualquier nombre de rol, prioridad o identificador se mantiene como dato ficticio y no se convierte en un requisito normativo.
Si posteriormente se decide una actividad, el sistema podría guardar una estimación de recursos y, al terminar, los datos realmente reportados. En el campo de comentarios se anotaría un resumen de alto nivel y una referencia al seguimiento pendiente si la observación requiere otra evaluación. No se escriben pasos técnicos, condiciones de intervención o instrucciones de operación en esta explicación.
Un ejemplo de tabla hipotética podría verse así:
| Campo | Valor de ejemplo | Interpretación |
|---|---|---|
| Identificador | OT-FICT-204 | Código inventado, no asignado por NASA |
| Activo/ubicación | P-204 / línea ficticia A | Identificación didáctica |
| Solicitud recibida | 10:14, ruido intermitente observado | Hecho reportado, no causa |
| Estado de revisión | Pendiente | No es aprobación de trabajo |
| Alcance revisado | [referencia local pendiente] |
Marcador vacío; no se inventa una tarea |
| Estimación | [según revisión competente] |
Sin número ficticio que parezca benchmark |
| Actual y cierre | [completar con registro real autorizado] |
No se atribuye un resultado al ejemplo |
Los marcadores muestran información ausente en vez de rellenarla con datos plausibles. Este formato de muestra no es una plantilla descargable ni una recomendación de campos obligatorios. Ayuda a ver qué significa mantener separados el reporte, la revisión, lo previsto y lo realmente documentado.
Registrar lo observado y lo realizado
El cierre puede conservar el estado asignado, la fecha, la persona que completó el registro y las referencias que siguen abiertas. Si aparece una condición inesperada, se anota como observación y se remite a la evaluación correspondiente: “se observó una condición distinta de la prevista” no afirma que esa condición sea la causa.
Cuando el proceso local lo requiera, materiales y tiempo realmente registrados pueden vincularse con la OT; el ejemplo NASA muestra esos campos en su propio contexto, sin convertirlos en requisitos universales.
Límites de seguridad y normativa
Una OT no reemplaza la evaluación de riesgos, las instrucciones vigentes del fabricante, el procedimiento del centro ni los permisos que correspondan. El artículo 3 del RD 1215/1997 establece deberes generales sobre equipos de trabajo; no prescribe un formato universal de OT. NASA presenta sus formularios como ejemplos adaptables y limita el alcance de la directiva a la agencia salvo incorporación por ley o contrato.
Esta página es educativa: no evalúa una instalación, no determina quién autoriza una tarea concreta y no ofrece instrucciones de intervención.
Identificadores y relaciones entre registros
Una OT puede enlazarse con el aviso inicial, el activo, una referencia de alcance y un seguimiento posterior, aunque esos datos vivan en sistemas distintos. Conviene conservar identificadores estables y definir qué significa cada estado local: recibir una solicitud, revisar su alcance, autorizar según el proceso del centro y cerrar el registro son eventos diferentes. El ejemplo NASA emplea códigos y campos propios; no obliga a copiar esa nomenclatura.