Planificación y programación de mantenimiento: diferencias operativas
Diferencia entre planificación y programación de mantenimiento: preparación, backlog listo, roles, urgencias y KPI para un programa semanal ejecutable.
El lunes empieza con diez órdenes de trabajo previstas para la semana. Dos esperan repuestos. Una requiere un permiso que todavía no fue gestionado. Tres coinciden con producción en marcha. Otra necesita un instrumentista asignado a una parada diferente.
Las diez tienen fecha. Solo algunas están realmente en condiciones de ejecutarse. Esa diferencia explica por qué la planificación y programación de mantenimiento no pueden tratarse como una sola actividad.
La planificación prepara el trabajo: alcance, tareas, horas, especialidades, materiales, herramientas, permisos y condiciones. La programación toma ese trabajo preparado y decide cuándo ejecutarlo según prioridad, capacidad, turnos, ventanas y restricciones.
Diferencia entre planificación y programación de mantenimiento
La diferencia operativa puede resumirse de forma directa: la planificación define cómo debe prepararse una intervención; la programación decide cuándo entra dentro de una capacidad y una ventana concretas. El calendario es una salida visible del proceso, no el proceso completo.
Concepto clave. Una OT puede estar planificada sin estar todavía programada. También puede tener fecha y no estar realmente preparada si conserva restricciones de material, permisos, ventana o capacidad.
| Criterio | Planificación | Programación |
|---|---|---|
| Decisión principal | Cómo debe ejecutarse el trabajo | Cuándo y con qué capacidad se ejecutará |
| Entrada | OT validada y priorizada | Trabajo suficientemente preparado |
| Datos centrales | Alcance, tareas, horas, especialidad, materiales, herramientas y permisos | Fecha, turno, ventana, capacidad, asignación, secuencia y dependencias |
| Falla típica | Alcance ambiguo o restricciones detectadas tarde | Sobrecarga, conflictos de ventana o cambios continuos |
| Medición | Calidad de preparación, bloqueos y precisión de estimación | Adherencia al programa, trabajo agregado y causas de reprogramación |
Para una referencia externa sobre trabajo planificado, puede consultarse la definición de planned maintenance de IBM, que identifica la preparación previa de tareas y recursos como parte central del trabajo planificado.
Qué significa que una OT esté lista para programar
Entre una orden aprobada y una orden programada conviene distinguir una condición intermedia: trabajo listo para programar. Esa condición separa OT con restricciones suficientemente resueltas de trabajos que siguen bloqueados por alcance, material, ingeniería, permisos, acceso o ventana.
Una OT planificada debería llegar a la etapa siguiente con un nivel de preparación proporcional a la complejidad, el riesgo y la criticidad. No todas las intervenciones requieren el mismo paquete: una inspección repetitiva con procedimiento estable no necesita la misma profundidad que una intervención poco frecuente sobre un equipo crítico.
El checklist no aporta valor si se marca por rutina administrativa. Cada condición debe tener dueño y consecuencia clara cuando falta. Si una OT puede avanzar de estado aunque el material no esté disponible o el permiso no tenga responsable, la etiqueta “lista” pierde credibilidad.
El artículo de OTEX.tech sobre sistema de órdenes de trabajo de mantenimiento puede complementar el ciclo completo de una OT. En esta guía, el foco está en la calidad del handoff antes de comprometer una fecha.
Handoff entre roles operativos
La calidad del proceso depende tanto del contenido técnico como de la transferencia de responsabilidades. Cuando nadie sabe quién confirma materiales, quién negocia la ventana o quién puede romper el programa, esas decisiones terminan en el supervisor durante el turno.
| Decisión | Planner | Programador | Supervisor | Operaciones |
|---|---|---|---|---|
| Definir alcance técnico | Principal | Consulta | Participa | Informa condición operativa |
| Estimar recursos | Principal | Usa el dato | Valida factibilidad | — |
| Seleccionar período de ejecución | Consulta | Principal | Participa | Acuerda ventana |
| Asignar técnico concreto | Define perfil | Puede proponer | Principal según modelo | — |
| Registrar causa de reprogramación | Analiza recurrencia | Registra o valida | Reporta causa real | Aporta causa cuando deriva de operación |
No existe una única distribución válida para todas las plantas. Una organización con planner dedicado puede separar preparación y supervisión diaria; una planta más pequeña puede concentrar funciones en una sola persona. El proceso debe diseñarse para esa capacidad real, no para una estructura idealizada que el equipo no puede sostener.
Cómo construir el programa semanal desde el backlog
El backlog contiene demanda pendiente. La programación semanal necesita separar ese volumen en estados de decisión. Abrir el listado completo, ordenar por prioridad y arrastrar trabajos hasta llenar el calendario crea una imagen de ocupación, pero no necesariamente un programa ejecutable.
“Programar exige resolver conflictos y dejar trazabilidad de las decisiones.”
Establecer el período del programa y la fecha desde la cual los cambios deben registrarse como agregados o reprogramaciones.
Descontar ausencias, guardias, reuniones, trabajos fijos y compromisos ya asumidos antes de cargar la semana.
Confirmar materiales, permisos, condiciones del activo y cambios recientes antes de ubicar OT en el calendario.
Comparar urgencia, ventanas, especialidades, terceros, herramientas y recursos compartidos.
Definir quién puede modificar el programa, por qué causas y cómo se registrará cada desvío.
Si el programa semanal se arma con planillas paralelas, mensajes y estados que no reflejan bloqueos reales, la trazabilidad se pierde antes de llegar a la ejecución.
Ver cómo OTEX lo resuelve →La programación semanal y el despacho diario no son lo mismo. El programa establece compromisos dentro de un horizonte; el despacho organiza la ejecución inmediata. Cuando cada decisión diaria reescribe la semana completa, el equipo pierde una base estable para analizar adherencia y causas de desvío.
Urgencias y reprogramaciones sin perder trazabilidad
Habrá fallas y condiciones que justifiquen alterar la semana. La disciplina está en clasificar el cambio para distinguir emergencias justificadas de desvíos repetitivos del proceso.
“Reprogramado” describe un estado, pero no explica una causa. El registro gana valor cuando conserva fecha original, fecha nueva, motivo, actor que decide el cambio y, cuando aporta al análisis, el trabajo desplazado o el impacto sobre capacidad.
KPI de planificación y programación que conviene separar
Cuando todas las fallas del proceso terminan en un único indicador de cumplimiento semanal, el equipo pierde capacidad de diagnóstico. Conviene medir preparación, programación y calidad de datos con definiciones explícitas.
| Indicador | Qué diagnostica | Regla que debe fijarse |
|---|---|---|
| Trabajo listo para programar | Capacidad de convertir backlog en trabajo ejecutable | Criterios que permiten declarar una OT lista |
| OT bloqueadas por causa | Dónde se acumulan restricciones | Momento de registro y responsable de cerrar el bloqueo |
| Precisión de estimación | Calidad del job plan y del histórico | Tratamiento de esperas y cambios de alcance |
| Adherencia al programa | Capacidad de sostener compromisos | Unidad de medida, fecha de corte, cancelaciones y ejecución parcial |
| Trabajo agregado | Presión emergente y disciplina del programa | Qué se considera agregado y cómo se clasifica una emergencia |
El indicador de adherencia necesita una definición estable. Dos plantas pueden mostrar el mismo porcentaje y medir cosas distintas si una incluye trabajo agregado en el denominador y otra no, o si una considera una OT parcialmente ejecutada como cumplida.
Antes de pedir más técnicos por incumplimientos repetidos, conviene revisar si las causas dominantes son estimaciones débiles, repuestos que aparecen disponibles pero no existen físicamente, cierres sin tiempos reales, estados que no reflejan bloqueos u OT repetitivas descritas de formas incompatibles.
Cómo debe sostenerlo un CMMS/GMAO
Un CMMS/GMAO puede sostener el proceso cuando representa estados, restricciones y decisiones reales. No corrige por sí solo una prioridad sin gobierno, un alcance pobre o un stock mal mantenido.
| Necesidad del proceso | Capacidad a verificar en el CMMS/GMAO |
|---|---|
| Distinguir trabajo pendiente de trabajo preparado | Estados y bloqueos con causas utilizables |
| Evitar programar sin material | Vínculo entre OT, repuesto, disponibilidad y reserva cuando aplique |
| Visualizar capacidad | Carga por técnico, cuadrilla o especialidad |
| Coordinar ventanas | Calendario, fechas objetivo y restricciones visibles |
| Explicar cambios | Historial y motivos de reprogramación |
| Retroalimentar planificación | Tiempos reales, hallazgos, consumos e historial técnico |
Para evaluar el encaje, una demo técnica debería probar un flujo concreto: preparar una OT, detectar una restricción, bloquearla, resolverla, pasarla a trabajo programable, asignar capacidad, programarla, registrar un cambio con causa y revisar qué información vuelve al historial y a los reportes.
Cuando el calendario oficial vive en el CMMS pero las prioridades reales se manejan en WhatsApp, papel o planillas personales, la trazabilidad llega tarde. Agregar campos solo mejora el proceso cuando cada dato tiene dueño, uso y decisión asociada. Para contextos con operación en campo, también puede profundizarse el enfoque de CMMS con app móvil offline.
Cierre operativo
La planificación prepara el trabajo; la programación decide cuándo entra dentro de capacidad, prioridad y ventana. Una OT con fecha no necesariamente está lista para ejecutarse si conserva restricciones abiertas.
El backlog debe separarse por estados de decisión: pendiente, bloqueado, listo para programar y programado. Las reprogramaciones solo sirven como diagnóstico si registran causa específica, fecha y responsable de decisión.
Un CMMS/GMAO aporta valor cuando refleja el proceso real y conserva trazabilidad de bloqueos, cambios y cierre.
Revisá una OT real antes de llevarla al calendario
Tomemos un trabajo de tu backlog y revisemos alcance, materiales, bloqueos, capacidad, ventana, asignación y cierre para ver dónde deja de ser trabajo pendiente y pasa a estar realmente listo para programar.
