Un estado como «completada» o «cerrada» parece describir un punto final. En los sistemas de mantenimiento, sin embargo, puede indicar que se terminó una fase, que se confirmaron ciertas operaciones, que se contabilizaron consumos o que la edición del registro quedó limitada. Esos efectos no son intercambiables: dependen del producto, de la versión y, en algunos casos, del modelo asignado a la orden.
Esta guía se limita a tres conjuntos de documentación: IBM Maximo Asset Management V7.1, descrito en un manual IBM de julio de 2009; Dynamics 365 Supply Chain Management Asset Management, según Microsoft Learn; y SAP S/4HANA Cloud Public Edition Asset Management, documentación de release 2608. No extrapola el manual antiguo de Maximo a Maximo Manage actual. Tampoco recomienda cómo configurar un sistema.
La pregunta es más acotada: qué significan los estados que el proveedor documenta y qué efectos dice que tienen.
La comparación se centra en cuatro preguntas: qué trabajo se declara terminado, qué operaciones incluye el estado, qué efecto administrativo produce y qué depende del flujo configurado.
Maximo Asset Management V7.1: COMP precede a CLOSE
El manual IBM Redbooks SG24-7761-00 identifica expresamente Maximo Asset Management V7.1. En su sección 8.1.1 presenta COMP como el estado de trabajo completado y CLOSE como el estado de orden cerrada. La distinción importa: COMP no equivale automáticamente a que el registro ya no admita cambios.
El texto de V7.1 describe posibilidades de edición antes del cierre, y señala reglas específicas para órdenes en historial y para el uso de la acción Edit History Work Order. Las reglas exactas dependen de los permisos y opciones aplicables en esa versión. IBM Redbooks, §8.1.1, pp. 140–141
En términos prácticos de lectura, COMP responde a una pregunta de progreso: ¿se declara terminado el trabajo asociado a esta orden? CLOSE responde a otra: ¿se cerró la orden como registro de trabajo? El manual indica que CLOSE cierra la orden y no permite editarla desde Work Order Tracking.
También describe una acción para modificar cierta información histórica y tareas de órdenes cerradas, pero excluye mano de obra, materiales, servicios y herramientas. Es una excepción delimitada; no equivale a un permiso general para alterar el trabajo original.
La frontera temporal es igualmente importante. El Redbook es una fuente primaria de IBM para V7.1 y se publicó en 2009. Puede describir esa edición, pero no demostrar que la interfaz, los nombres o los efectos sean iguales en Maximo Manage o en otras versiones posteriores. Por eso, la afirmación aquí se mantiene acotada a V7.1 y a las páginas impresas citadas. Una instalación distinta requiere consultar su propia documentación oficial y reglas locales.
Auditoría de cambios, fuera del alcance de V7.1
IBM Support describe una capacidad distinta del historial de estados del Redbook. Su página explica que ciertos cambios, incluidos los estados de órdenes de trabajo, se registran históricamente por defecto. Para otros atributos, E-audit puede habilitarse por objeto y atributo.
Al guardar el registro, la tabla de auditoría incluye una copia de los datos cambiados, el nombre de usuario, el tipo de operación (inserción, actualización o eliminación) y un identificador único de transacción. IBM Support, “Audit Tracking in Maximo”, líneas 32–39
La página no identifica la versión de Maximo ni especifica un par de valores anterior/nuevo o un campo de hora concreto. Por eso, este ejemplo no amplía lo afirmado sobre V7.1. El registro puede ayudar a atribuir un cambio guardado en la aplicación; no prueba que se ejecutara el mantenimiento ni que una prueba funcional tuviera un resultado satisfactorio.
Dynamics 365: el estado pertenece a un modelo de ciclo de vida
Microsoft presenta un modelo menos parecido a una lista universal de estados y más relacionado con el flujo que se asigna a la orden. En Asset Management, un tipo de orden se asocia a un modelo de ciclo de vida; ese modelo reúne los estados disponibles. Microsoft ofrece como ejemplos Created, In Process y Finished, pero el conjunto y la secuencia pueden variar con el tipo y el modelo utilizados.
Por ello, encontrar una etiqueta «Finished» en una instalación no basta para inferir el mismo recorrido en otra. Microsoft Learn, “Work order types”
La página de estados de ciclo de vida hace explícito que el estado puede relacionarse con comportamientos. Entre las opciones que documenta están permitir añadir o borrar líneas, permitir programación, fijar fecha y hora real de inicio o fin, contabilizar journals, procesar checklists, actualizar estados de programación y ejecutar validaciones. La documentación explica esas posibilidades como opciones del estado.
No significa que todas estén activas en cada flujo ni que la palabra del estado describa por sí sola todas sus consecuencias. Microsoft Learn, “Work order lifecycle states”
Un detalle útil es la relación entre estado de orden y fase del proyecto. Microsoft indica que cada estado de ciclo de vida debe relacionarse con una fase de proyecto, y que la fase correspondiente debe estar activa para el tipo de proyecto. Esa relación puede determinar qué tareas financieras o de proyecto están disponibles.
Es una dependencia funcional del modelo de Supply Chain Management con Project management and accounting, no una equivalencia entre «cerrado» en Dynamics y «cerrado» en otro software. Microsoft Learn, “Forecasts, work orders, and projects”
Finished y Ended en contexto
La documentación de consumo describe una secuencia concreta: cuando se completa un trabajo de mantenimiento, se registran consumos de horas, artículos y gastos en journals; se validan y contabilizan esos journals; después puede actualizarse el estado de ciclo de vida. Como ejemplo, Microsoft menciona cambiar el estado a Ended para indicar que la orden está completa. La palabra «ejemplo» es clave.
La página no presenta Ended como etiqueta obligatoria o universal de todas las instalaciones de Asset Management. Microsoft Learn, “Register consumption”
La secuencia separa trabajo registrado, consumo, contabilización y cambio de estado. La configuración puede automatizar la contabilización; además, el acceso a las líneas depende del estado y de la fase del proyecto. Microsoft también indica que un error de validación puede cancelar la actualización del estado. Al leer un historial, conviene distinguir si el journal existe, si se validó y si llegó a contabilizarse; no son tres formas de nombrar el mismo evento.
Al revisar una orden concreta, contrasta el tipo y el modelo asignados con los journals y las validaciones registradas.
Consumo registrado e historial del activo en Dynamics 365
Microsoft describe el Asset BOM como una vista del historial de artículos usados en un activo durante toda su vida.
La página explica que ese historial se alimenta después de registrar el consumo de artículos en una orden de trabajo y sirve, por ejemplo, para observar si una pieza se reemplaza con frecuencia o qué artículos figuran actualmente.
Por eso conviene separar el journal de consumo de la lista histórica del activo: son dos vistas relacionadas, no una sola confirmación del trabajo físico. Microsoft Learn, “Asset BOMs”, líneas 31–35
La sincronización automática depende de una configuración concreta: el estado del ciclo de vida debe estar creado para órdenes terminadas o completadas y su opción Update asset BOM debe ser Yes; la actualización ocurre cuando la orden cambia a ese estado.
Microsoft también exige seleccionar los grupos de artículos usados para registrar repuestos. La página permite actualizar líneas manualmente y recomienda revisar el BOM cuando artículos relacionados hayan caducado o hayan sido sustituidos. En la vista Current aparecen solo líneas activas; All incluye también las que tienen una fecha de expiración anterior. [Microsoft Learn, “Asset BOMs”, líneas 36–40, 49–64]
En una revisión hipotética, pregunta por separado si existe consumo registrado en la orden, si el artículo aparece en el historial del activo y si el flujo configurado sincroniza ambos registros. Si falta una línea, comprueba primero los grupos y el estado de ciclo de vida; la documentación también contempla la actualización manual.
Una línea en el BOM tampoco demuestra por sí sola que el componente se instalara, que el equipo recuperara su función o que superara una prueba. El registro ayuda a seguir artículos y sustituciones; no sustituye evidencia de instalación, inspección o prueba funcional.
SAP S/4HANA Cloud Public Edition 2608: OMWC no cubre POST
La documentación 2608 de SAP diferencia dos estados con propósitos distintos para órdenes de mantenimiento: OMWC (Main Work Completed) y TECO (Technically Completed). En el flujo por fases descrito por SAP, OMWC confirma operaciones con ejecución PRE y MAIN; no confirma las operaciones POST. TECO, en cambio, confirma las tres fases: PRE, MAIN y POST. La distinción está expresada por SAP en la página “Main Work Completed”. SAP Help Portal, release 2608, “Main Work Completed”
SAP también describe efectos distintos. Al establecer OMWC, las operaciones PRE y MAIN reciben ese estado y pasan a la subfase Work Finished; la fase y subfase de las operaciones POST permanecen sin cambio. El encabezado de la orden queda en la subfase Main Work Completed.
Con TECO, cuando se cumplen las condiciones del flujo documentado, la orden pasa a Technically Complete y el estado técnico se fija en el encabezado y las operaciones. El punto no es presentar una receta, sino entender qué parte del trabajo representa cada estado en esa versión del producto.
La página de SAP advierte que algunos efectos de negocio ocurren con TECO y no con OMWC: solicitudes de compra que aún no se convirtieron en pedidos se marcan para borrado y se eliminan reservas de componentes de stock que todavía no se emitieron. Esos efectos son razones para no tratar OMWC y TECO como dos etiquetas visuales equivalentes.
La página los describe en el contexto de SAP S/4HANA Cloud Public Edition y del flujo correspondiente; no afirma que cada cliente tenga todas las fases configuradas de la misma manera.
Hay una segunda separación en el propio proceso de SAP. La documentación de Proactive Maintenance coloca Completion después de la ejecución y del trabajo técnico; Complete (Business) aparece como una etapa empresarial/financiera posterior. En otras palabras, TECO no debe presentarse como «todo terminó en cualquier sentido». Es una marca técnica dentro del ciclo documentado.
La etapa empresarial puede seguir requiriendo tareas propias, y la página no permite inferir que una fase sustituya a la otra. SAP Help Portal, Proactive Maintenance, release 2608
Al revisar SAP, distingue el estado del encabezado del de cada operación.
Comparar dimensiones, no traducir etiquetas
Una tabla puede ordenar las preguntas, pero no establecer correspondencias:
| Dimensión de lectura | Maximo Asset Management V7.1 | Dynamics 365 SCM Asset Management | SAP S/4HANA Cloud Public Edition 2608 |
|---|---|---|---|
| Vocabulario citado | COMP y CLOSE | Estados del modelo; ejemplo de Ended | OMWC y TECO |
| Qué separa la documentación | Trabajo completado frente a orden cerrada | Estado, modelo y comportamiento asociado | PRE/MAIN frente a PRE/MAIN/POST |
| Efecto administrativo destacado | Historial y reglas de edición | Journals, validaciones, fases de proyecto y opciones | Cambios en reservas y solicitudes no convertidas en pedidos al usar TECO |
| Límite de inferencia | No equivale a prueba ni a permisos actuales de otra versión | El mismo nombre puede variar según modelo y opciones | OMWC no cubre POST; TECO no equivale a Complete (Business) |
Conserva el nombre original y la edición citada al comparar estados.
Tres lecturas hipotéticas, sin equivalencias
Imagina que una persona revisa tres pantallas de sistemas distintos después de una intervención. En una instalación con Maximo V7.1 encuentra COMP. La pregunta útil no es «¿equivale a TECO?», sino si el registro todavía está antes de CLOSE y qué documentos vinculados describen el trabajo, la prueba y la revisión.
Si encuentra CLOSE, consulta el historial y las reglas aplicables a esa versión para saber qué información se puede añadir mediante la función específica. No infiere que todos los detalles técnicos estén en el mismo registro.
En Dynamics 365, supongamos que la orden muestra Ended. Para interpretar ese dato, se identifica el tipo y el modelo de ciclo de vida documentado para esa orden y se revisan sus journals. La guía de Microsoft pone Ended como un ejemplo posterior a registrar y contabilizar consumos; el escenario no presupone que cada entorno use esa secuencia ni que el estado contenga el detalle de horas, materiales o gastos.
Si se necesita confirmar un consumo, se consulta su journal, no una etiqueta que quizá resume una transición.
En SAP 2608, imagina que una orden aparece OMWC. La documentación permite concluir que PRE y MAIN fueron marcadas como completadas en el flujo por fases descrito, pero no que POST se completó. Si el estado es TECO, SAP describe que se incluyen PRE, MAIN y POST y que pueden activarse los efectos de cierre indicados. Ninguna de esas observaciones afirma por sí sola que la orden haya llegado a Complete (Business) ni que exista una prueba de aceptación satisfactoria.
Qué prueba un estado y qué debe documentarse aparte
El estado hace visible una decisión registrada dentro de la aplicación. Para responder si una función se comprobó, se necesita una evidencia que identifique la función, el método o condición usada y el resultado que quedó asentado. Para responder si se cerró el expediente administrativo, se revisan los documentos y transacciones que la aplicación considera parte de ese proceso. Son preguntas relacionadas, pero no iguales.
Las fuentes no fijan un criterio universal para autorizar el retorno al servicio.
Si un expediente se utiliza para una revisión posterior, conviene conservar un vínculo verificable entre la orden, los registros de ejecución, los consumos o materiales, la prueba funcional y el resultado, y la decisión de quien tenga autoridad según el procedimiento local. Esta es una pauta de lectura documental, no una obligación legal atribuida a los proveedores. Los campos exactos deben contrastarse con las reglas actuales del centro y la versión instalada.
Preguntas frecuentes
¿COMP y CLOSE significan lo mismo en Maximo 7.1?
No. En el Redbook de Maximo Asset Management V7.1, COMP indica que se ejecutó el trabajo y CLOSE que la orden está cerrada. El manual señala que Work Order Tracking no permite editarla en CLOSE; una acción aparte permite cambiar ciertos datos históricos y tareas, pero no labor, materiales, servicios ni herramientas.
¿Ended es un estado final universal en Dynamics 365 Asset Management?
No. La documentación presenta Ended como ejemplo después de registrar y contabilizar journals; los estados disponibles y sus efectos dependen del modelo de ciclo de vida relacionado con el tipo de orden.
¿OMWC confirma todas las operaciones de una orden SAP?
No. En SAP S/4HANA Cloud 2608, OMWC confirma las operaciones PRE y MAIN, no POST. TECO documenta la finalización de las tres fases.
¿Un estado de cierre demuestra que el equipo superó una prueba?
No por sí solo. Los estados descritos reflejan etapas o efectos dentro de cada sistema; la prueba y su resultado requieren evidencia propia según el procedimiento aplicable.