Todo equipo que trabaja se desgasta, y el desgaste se atiende de formas muy distintas según cuándo se lo detecte.
La Orden de mantenimiento es el registro que convierte cada una de esas intervenciones en un dato asociado al bien sobre el que se trabajó.
El tipo es lo primero que se elige, y no es una etiqueta descriptiva: condiciona qué prioridades quedan disponibles y ordena el trabajo del área.
Es el que se atiende cuando el equipo ya dejó de funcionar y la operación está detenida.
Por definición no admite prioridades bajas, y esa restricción está escrita en el sistema y no librada al criterio de quien carga la orden.
Es el que repara una falla detectada, cuando el equipo todavía funciona o cuando la detención se puede programar.
Se diferencia de la emergencia en que hay margen para planificar, conseguir repuestos y elegir el momento.
Es el que se hace antes de que aparezca la falla, siguiendo un calendario o una cantidad de horas de uso.
Es el más barato de todos, porque evita la detención no programada, y es el que más se posterga cuando nadie lleva el registro.
Es el que devuelve a un instrumento su precisión de medición.
No repara nada roto: ajusta un equipo que funciona pero que dejó de medir dentro de la tolerancia aceptada.
La prioridad de la orden es una lista dependiente, y el campo que la controla es el tipo de mantenimiento.
Eso significa que al elegir el tipo, la lista de prioridades se acota sola a las que tienen sentido para esa clase de trabajo.
Una emergencia solo admite las dos prioridades más altas, y un preventivo nunca admite la más alta de todas.
Es una regla de negocio codificada en el modelo de datos, así que se cumple sin depender de que alguien la recuerde.
La orden nace planificada, pasa a estar en progreso cuando el trabajo arranca, y queda completada cuando se cierra.
Ese recorrido corto es deliberado: tres estados se leen de un vistazo en una Vista de lista o en un Kanban, y no obligan a nadie a elegir entre matices parecidos.
Tres campos calculados trabajan solos sobre las fechas, y son los que convierten al conjunto de órdenes en un tablero de gestión.
El primero cuenta cuántos días faltan para la fecha límite, y queda en negativo cuando la orden se venció, que es la forma más directa de encontrar lo atrasado.
El segundo mide la antigüedad de la orden desde que se creó, que es lo que muestra si algo lleva mucho tiempo esperando atención.
El tercero mide cuántos días llevó el trabajo entre su inicio y su finalización, y es el que permite comparar la duración real de intervenciones parecidas.
Cada orden apunta obligatoriamente a un Activo fijo, así que ninguna intervención queda flotando sin dueño.
La consecuencia práctica aparece en la ficha del equipo, donde se ve todo lo que se le hizo a lo largo del tiempo, con su costo y sus horas.
Ese historial es el que sostiene la decisión de reparar o reemplazar, porque un equipo que acumula intervenciones caras ya está diciendo algo sobre su vida útil.
La orden se crea desde el equipo, se sigue por su estado y se cierra cargando lo que el trabajo consumió.
Lo más cómodo es abrir la ficha del activo fijo y crear la orden desde su Lista relacionada, porque así el vínculo con el equipo queda resuelto solo.
Elegimos el tipo de mantenimiento, cargamos el deadline y describimos en el campo de objetivos qué se espera del trabajo.
Recién después elegimos la prioridad, porque la lista se acota según el tipo y elegir al revés obliga a volver atrás.
La orden distingue al técnico asignado del supervisor, y los dos son usuarios de la Plataforma.
Esa separación permite dos lecturas distintas del mismo conjunto de órdenes: la carga de trabajo de cada técnico y la cartera que cada supervisor tiene abierta.
Al terminar el trabajo cargamos la fecha de finalización, el costo y las horas de mano de obra, y describimos en el campo correspondiente qué se hizo realmente.
Nos conviene completar también la fecha de inicio, porque los días de resolución solo se calculan cuando están cargadas las dos fechas.
El campo de comentarios queda para lo que no entra en ninguna de las dos descripciones, del tipo un repuesto que costó conseguir.
Con las órdenes cargadas, un informe agrupado por activo muestra qué equipos concentran el gasto de mantenimiento de tu empresa.
Otro agrupado por tipo muestra la proporción entre lo preventivo y lo de emergencia, que es la medida más honesta de qué tan bajo control está el parque de equipos.
Estas son las dudas que aparecen al empezar a registrar el mantenimiento de los equipos en el ERP, sobre todo cuando antes se llevaba en una planilla.
Porque la prioridad es una lista dependiente y el tipo de mantenimiento es el que la controla.
Al cambiar el tipo, la lista de prioridades se rearma, así que conviene elegir primero el tipo y después la prioridad.
No. El vínculo con el Activo fijo es obligatorio, y es lo que le da sentido a todo el registro.
Gracias a esa obligación, cada intervención suma al historial del equipo en lugar de quedar suelta.
El deadline es el compromiso, o sea para cuándo el trabajo tiene que estar listo, y se carga al crear la orden.
La fecha de finalización es el hecho, o sea cuándo terminó de verdad, y se carga al cerrarla. La distancia entre las dos es lo que mide el cumplimiento.
No, es un campo calculado que se actualiza solo contra la fecha del día.
Cuando la orden está vencida el número queda en negativo, y ese signo es la forma más rápida de filtrar lo atrasado en una Vista de lista.
Sí, y las horas de mano de obra también.
Un mantenimiento hecho en casa igual consume tiempo pago, y ese consumo es parte de lo que después se compara contra el valor del equipo.
Cargamos una orden por cada intervención, con su propio deadline y su propio cierre.
Ese detalle es justamente lo que permite ver la serie completa y detectar si el intervalo entre intervenciones se está acortando.
Esta sección es para quien escribe requerimientos sobre el ERP y necesita nombrar los campos, las fórmulas y las dependencias con precisión.
El objeto se llama EGAFutura__Orden_mantenimiento__c y tiene dieciocho campos propios además del nombre del registro.
| Campo | Tipo | Nota |
|---|---|---|
| Name | Texto(80) | Nombre del registro, se carga a mano |
| EGAFutura__Activo_fijo__c | Lookup | Obligatorio, apunta a EGAFutura__Activo_fijo__c |
| EGAFutura__Tipo__c | Lista de selección | Obligatorio, controla la lista de prioridad |
| EGAFutura__Estado__c | Lista de selección | Obligatorio, con Planificada por defecto |
| EGAFutura__Deadline__c | Fecha | Obligatorio, es la fecha límite comprometida |
| EGAFutura__Prioridad__c | Lista de selección dependiente | Controlada por Tipo, con Normal por defecto |
| EGAFutura__StartDate__c | Fecha | Fecha de inicio del trabajo |
| EGAFutura__CompletionDate__c | Fecha | Fecha de finalización del trabajo |
| EGAFutura__Cost__c | Moneda(16, 2) | Costo de la intervención |
| EGAFutura__LaborHours__c | Número(6, 2) | Horas de mano de obra |
| EGAFutura__Tecnico_asignado__c | Lookup | Apunta a User |
| EGAFutura__Supervisor__c | Lookup | Apunta a User |
| EGAFutura__Objetivos__c | Área de texto larga(32768) | Qué se espera del trabajo |
| EGAFutura__Trabajo_realizado__c | Área de texto larga(32768) | Qué se hizo efectivamente |
| EGAFutura__Comentarios__c | Área de texto(255) | Notas sueltas de la intervención |
| EGAFutura__Dias_Deadline__c | Fórmula (Número) | Deadline menos la fecha de hoy |
| EGAFutura__Dias_transcurridos__c | Fórmula (Número) | Antigüedad desde la creación del registro |
| EGAFutura__ResolutionDays__c | Fórmula (Número) | Finalización menos inicio, vacío si falta una |
| EGAFutura__EGA_Futura_ID__c | Numeración automática | Identificador que completa el sistema |
La lista no tiene valor por defecto, y el valor almacenado coincide con la etiqueta.
| Label | Valor almacenado |
|---|---|
| Mantenimiento de emergencia | Mantenimiento de emergencia |
| Mantenimiento correctivo | Mantenimiento correctivo |
| Mantenimiento preventivo | Mantenimiento preventivo |
| Mantenimiento de calibración | Mantenimiento de calibración |
El valor por defecto es Planificada.
| Label | Valor almacenado |
|---|---|
| Planificada | Planificada |
| En progreso | En progreso |
| Completada | Completada |
Es una lista dependiente, así que la tabla suma una columna con los tipos que habilitan cada valor.
| Label | Valor almacenado | Disponible cuando el Tipo es |
|---|---|---|
| Crítica | Crítica | Emergencia, correctivo y calibración |
| Alta | Alta | Los cuatro tipos |
| Normal | Normal | Correctivo, preventivo y calibración |
| Baja | Baja | Preventivo y calibración |
Los tres campos de fórmula se recalculan al leer el registro y no se guardan en la base, así que un requerimiento que pida editarlos a mano no es un cambio de valor sino un cambio de definición del campo.
Los días para el deadline y los días transcurridos se mueven todos los días aunque nadie toque la orden, porque comparan contra la fecha del momento. Eso los vuelve excelentes para una Vista de lista y poco confiables para una foto histórica, que se arma con las fechas de origen.
Los valores almacenados de las tres listas coinciden con la etiqueta, en español y con acentos. La consecuencia es que un filtro escrito sin la tilde de Crítica o de calibración devuelve cero filas, y ese cero se parece demasiado a la ausencia de datos.
La dependencia entre Tipo y Prioridad se define en el campo controlador y no en código, así que pedir un cambio en las combinaciones permitidas es un pedido sobre la lista dependiente. Conviene redactarlo indicando qué valores quedan habilitados para cada tipo, en lugar de describir el caso particular que motivó el pedido.
Ventas, compras, inventario, finanzas y equipo, con la información al día y disponible desde cualquier dispositivo. Funciona en la nube, así que no hay servidores que mantener.
Quiero llevar mi Empresa a la Nube