Qué representa un cronograma
Un cronograma muestra qué órdenes se han asignado a una ventana y qué capacidad requieren. Puede reunir tareas preventivas y correctivas, siempre con la clasificación y el estado que use el proceso local. La vista coordina; no diagnostica el fallo ni sustituye la orden de trabajo.
La guía FIST 6-2 del U.S. Bureau of Reclamation (USBR) diferencia el backlog, con órdenes previstas pero aún no aprobadas o programadas, del programa semanal, que asigna órdenes por prioridad calculada y compara recursos requeridos con disponibles. Es una referencia de gestión para instalaciones hidroeléctricas y de bombeo de Reclamation, no una plantilla universal ni una norma española.
La distinción aparece en §§5.3 y 5.30 (p. impresa 2, PDF físico 10, líneas web 262–264; p. impresa 5, PDF físico 13, líneas 364–370, FIST 6-2).
Del backlog a una ventana de trabajo
Una orden puede estar abierta y, aun así, no estar lista para el calendario. Quizá falta identificar el activo, precisar el alcance o determinar qué recurso requiere. También puede existir una dependencia pendiente o faltar una decisión de prioridad. Si se le asigna una fecha solo para que la hoja parezca completa, se convierte una incógnita en una promesa visual.
FIST 6-2 describe el backlog como trabajo previsto en órdenes que aún no ha llegado al programa aprobado o programado (§5.3). En el programa semanal, la prioridad calculada y la comparación entre recursos requeridos y disponibles ayudan a asignar las órdenes (§5.30). De ahí sale una lectura útil para una planta: el backlog responde “¿qué trabajo sigue pendiente de encajar?”; el cronograma responde “¿qué órdenes se han colocado en qué ventana con qué capacidad?”.
La primera pregunta no desaparece cuando se abre el calendario.
La diferencia importa cuando se revisa una semana cargada. Si una orden espera material, una aclaración o una asignación, conservar ese estado es más fiel que ponerla en una casilla libre. Cuando el equipo local decide incorporarla al programa, la fila debería reflejar qué cambió: se completó un dato, quedó disponible un recurso o se acordó una ventana. Esos ejemplos explican cómo leer el cambio; no son criterios universales de aprobación.
Conviene mostrar al menos tres situaciones con nombres que tengan sentido en el sistema local: trabajo que requiere revisión, trabajo evaluado que aún no tiene hueco y trabajo asignado a una ventana. Si el GMAO usa otros estados, no hace falta traducirlos a una taxonomía nueva. Basta con que la persona que actualiza el calendario sepa qué evento mueve la orden de una situación a otra y dónde queda constancia de ese cambio.
Un hold merece una lectura distinta de una fecha pendiente. FIST 6-2 incluye los holds entre las entradas que se revisan al preparar el programa semanal (§11.2, p. impresa 19/PDF físico 27, web lines 852–865). La guía no aporta una etiqueta que todas las plantas deban copiar. En una vista local, conserva el motivo que conoce el responsable y la condición que falta para volver a evaluar la orden.
Así, “en espera de pieza” y “pendiente de aclarar alcance” no quedan como un único estado opaco.
En una planta ficticia, una orden puede esperar una pieza y otra necesitar una estimación mejor. No hay que asignarles una fecha para completar la semana: la vista puede mostrar ambas en espera y dejar visible qué información falta. Cuando cambie el motivo, quien mantiene el registro actualiza el estado y revisa si ya existe una ventana viable. Es una forma de hacer legible el backlog, no un código oficial ni una promesa de disponibilidad.
El propio FIST 6-2 describe estados y holds como entradas para revisar la carga; también presenta un workflow site-specific que lleva una orden desde su inicio hasta el cierre (§§5.31–5.32 y 11.2, pp. impresas 5 y 19; PDF físicos 13 y 27; líneas web 368–373 y 852–865). Esa descripción no convierte las etiquetas de una empresa en estados de Reclamation.
Sirve para recordar que un programa depende de la información de las órdenes y de las reglas del centro, no solo de los colores de una vista.
Qué puede contener una fila
La fila no necesita convertirse en un formulario nuevo. Debe contestar las preguntas que aparecen en la reunión de planificación: qué orden se está mirando, a qué activo o alcance corresponde, qué ventana se propone, cuánto tiempo se estima y qué recurso necesita. También es útil indicar el estado y la fecha de actualización, porque un calendario exportado el lunes puede seguir circulando el jueves aunque la asignación ya haya cambiado.
Una estructura editorial sencilla podría leerse así:
| Campo de lectura | Pregunta que resuelve | Ejemplo hipotético |
|---|---|---|
| Orden | ¿Qué registro hay que abrir? | OT-214 |
| Activo o alcance | ¿Dónde se realizará el trabajo? | Bomba auxiliar B |
| Tipo local | ¿Cómo clasifica el centro la tarea? | Preventivo |
| Ventana propuesta | ¿Cuándo se reservaría tiempo? | Martes, turno de mañana |
| Duración estimada | ¿Qué horizonte se está calculando? | 2 horas de ventana |
| Recurso | ¿Qué capacidad se necesita? | Una persona con la competencia asignada |
| Estado y actualización | ¿Es previsión o registro posterior? | Programada; revisada el lunes |
Los datos de la tabla son inventados para mostrar la lectura de una fila. No proceden de una planta real ni deben reutilizarse como tiempos de referencia. La guía FIST 6-2 no prescribe estos campos. En §5.30 habla de prioridad y de comparar los recursos requeridos con los disponibles; §§5.31–5.32 describen un proceso local y el papel de la orden de trabajo en identificar, planificar, aprobar y registrar el trabajo.
El modelo de fila aquí es una síntesis editorial apoyada en esos conceptos, no una reproducción de su formulario.
La palabra “duración” merece una etiqueta. Puede referirse al tiempo de ventana, a horas-persona o a otra unidad que utilice el sistema. No mezcles magnitudes: dos personas durante dos horas representan cuatro horas-persona, pero ocupan una ventana de dos horas si ambas trabajan a la vez. En una hoja real, el responsable debe seguir la unidad que usa la instalación y señalar si el valor es una estimación o un registro observado.
El ejemplo de cuatro horas-persona es aritmético e hipotético, no un benchmark.
También hay que distinguir activo de alcance. Una orden puede cubrir un equipo, varias unidades o una zona. Si el nombre del activo no basta para saber qué registro revisar, la vista puede incluir una referencia corta al alcance. No hace falta copiar todo el texto de la orden; duplicar datos aumenta la posibilidad de que una descripción quede desactualizada cuando cambia el registro de origen.
Prioridad, capacidad y ventana
Una lista ordenada y un calendario muestran cosas distintas. La prioridad ayuda a comparar la importancia asignada a las órdenes; la ventana y los recursos muestran si hay capacidad para situarlas en un periodo. El orden visual no debe sustituir la evaluación local. Una tarea puede aparecer arriba en una lista y seguir sin espacio, recurso o autorización para ejecutarse.
FIST 6-2 §5.30 vincula el programa semanal a la prioridad calculada y a la comparación entre los recursos requeridos y disponibles. §11.1 añade que el programa permite a operaciones planificar despejes operativos (clearances) y equipo de reserva, y a gestión detectar conflictos. §11.2 describe prioridades, entradas de estado y holds para revisar el programa y asignar la semana (pp. impresas 5 y 19; PDF físicos 13 y 27; líneas web 364–367, 846–850 y 852–865, FIST 6-2).
En este contexto, la ventana no es un hueco abstracto: puede depender de coordinación con operaciones y de la capacidad realmente disponible.
Para una reunión semanal, resulta más claro que cada conflicto aparezca como tal. Si dos órdenes requieren la misma especialidad en el mismo tramo, no ocultes una de ellas moviéndola a una fecha sin revisar. Señala las ventanas y recursos que se solapan, conserva la prioridad que haya calculado el proceso local y deja constancia de quién debe resolver la asignación. El calendario facilita la conversación; no toma la decisión por el equipo.
La vista mensual puede servir para localizar concentraciones de carga y la semanal para confirmar asignaciones próximas, siempre que la empresa defina cómo se mantienen. Esa división entre horizontes es una propuesta de lectura, no una frecuencia recomendada por FIST. Una vista extensa puede advertir de una semana saturada, pero no demuestra que el plan vaya a ejecutarse tal cual. La revisión debe volver a los datos de las órdenes y a la información que cambió desde la última actualización.
Un ejemplo de solapamiento
Imagina una planta ficticia que revisa su semana. Una orden preventiva para la bomba auxiliar B tiene una ventana propuesta de dos horas y requiere un recurso técnico concreto. Una orden correctiva, ya evaluada, necesita a la misma persona durante un tramo que coincide parcialmente. En el backlog queda una tercera orden cuya información aún no permite estimar la duración. Los tres ejemplos son hipotéticos y no describen un incidente real.
La primera lectura de la vista no sería “ejecuta la orden A antes que la B”. Sería: dos órdenes se solapan en un recurso, y la tercera no tiene datos suficientes para ocupar una ventana. El equipo puede revisar la prioridad y disponibilidad, y comprobar si hay una ventana compatible con la operación. La fila del backlog conserva su falta de estimación en vez de inventar una duración.
Si se cambia una asignación, el sistema acordado debe reflejar quién la revisó y cuándo.
Supongamos, solo para explicar unidades, que la tarea preventiva se estima en cuatro horas-persona y la correctiva en tres. Si cada una se asigna a una sola persona, el total sería siete horas de trabajo; si se solapan, el calendario puede mostrar menos horas de reloj, pero la misma capacidad de persona no puede estar en dos lugares a la vez.
El cálculo no determina qué tarea es prioritaria, cuánto durará una intervención real ni qué decisión debe tomar una planta. Solo ayuda a detectar que la carga no cabe como está dibujada.
El punto práctico es conservar separadas la estimación, la decisión de asignar ventana y la ejecución registrada. Si se reprograma una orden, su fecha anterior no debe quedar presentada como una intervención completada. Si se cierra, la evidencia está en el registro definido por el centro, no en una casilla coloreada del calendario.
Preventivo y correctivo en la misma vista
El cronograma puede reunir preventivos y correctivos para que el equipo vea la carga completa, pero conserva el tipo y el estado que asigna la orden local. Una tarea preventiva puede necesitar otra ventana si cambia la disponibilidad; una correctiva puede estar evaluada y lista, o seguir esperando información. El calendario no permite deducir cuál de esas condiciones aplica.
Usa la columna de tipo como filtro, no como sustituto del alcance o del estado. Si la reunión muestra solo órdenes asignadas, deja claro que el backlog queda fuera de esa vista. El diagnóstico y la secuencia de intervención pertenecen a la orden y al procedimiento aplicable. La fila ayuda a revisar carga, recursos y ventanas; su etiqueta clasifica el trabajo, no indica cómo ejecutarlo.
Cambios y estado de la orden
Una ventana puede cambiar cuando falta un recurso, cambia la estimación o aparece una dependencia. Conserva el historial que necesite el proceso y enlaza la vista con la orden vigente, en vez de duplicar comentarios en varias hojas. FIST 6-2 describe estados de órdenes hasta el cierre y contempla status inputs y holds al revisar el programa (§§5.31–5.32, 11.2). La secuencia y los nombres de estado son site-specific; el manual no establece una taxonomía para todas las empresas.
Para separar previsión de ejecución, define qué registro marca el cierre y quién puede actualizarlo. Si comparas duración planificada y observada, usa la misma unidad y órdenes de alcance parecido. Un retraso puede responder a un cambio de alcance, falta de recurso o dependencia, pero si el registro no lo dice, deja la causa como desconocida. No conviertas la diferencia en una medida de rendimiento individual.
Qué cambia en una revisión semanal
Antes de la reunión, actualiza qué órdenes siguen abiertas y cuáles ya tienen ventana. Durante la revisión, el equipo puede confirmar recursos y señalar colisiones; después, quien mantenga el sistema registra la decisión y la fecha. Es una forma de organizar la reunión, no un procedimiento establecido por FIST.
Una tabla corta ayuda a que la conversación no se pierda en etiquetas:
| Pregunta de revisión | Dato que se consulta | Salida visible |
|---|---|---|
| ¿Qué órdenes siguen pendientes? | Estado actual de cada orden | Backlog sin fecha inventada |
| ¿Qué carga puede entrar en la semana? | Prioridad, recursos requeridos y disponibles | Órdenes asignadas a ventanas |
| ¿Hay un conflicto? | Solapamiento de recurso o coordinación | Incidencia que requiere decisión |
| ¿Qué cambió desde la última revisión? | Fecha, estado y motivo registrado | Historial actualizado |
La tabla resume preguntas de gestión; no es un formato FIST ni una lista de seguridad. §§10.1–10.2 describen la planificación previa a la ejecución como práctica de Reclamation, con una salvedad para algunas instalaciones pequeñas donde separar funciones puede no ser práctico o rentable (p. impresa 18/PDF físico 26, web 819–841). §11.1 explica que el programa permite a operaciones planear clearances y equipo de reserva, y a gestión detectar conflictos (p. impresa 19/PDF físico 27, web 846–850).
La ventana puede depender de coordinación que no aparece en una orden aislada; apunta al registro autorizado en vez de copiar detalles técnicos a la vista.
Al exportar el calendario, conserva el origen y la fecha de actualización. Una copia sirve para la reunión, pero el sistema compartido sigue siendo la referencia cuando cambian las órdenes.
Límites de lo que muestra el calendario
Una fecha prevista no prueba ejecución. FIST 6-2 describe estados de órdenes hasta el cierre (§5.31) y entradas de estado y holds para revisar el programa (§11.2). Que la programación no equivalga a una ejecución es una inferencia editorial sobre esos estados. Para saber qué ocurrió, consulta el registro que el centro reconoce como cierre.
El calendario tampoco confirma que estén resueltos los permisos o controles aplicables; FIST 6-2 se cita como referencia de planificación de Reclamation, no como norma española.
Preguntas frecuentes
¿Qué debe mostrar el cronograma?
La orden, el activo o alcance, la ventana, el recurso, la duración estimada y el estado, junto con su última actualización.
¿Preventivo y correctivo se planifican igual?
No necesariamente. Conserva la clasificación y el estado que usa el proceso local; la fecha de calendario no sustituye la evaluación de cada orden.
¿Quién cambia una ventana de mantenimiento?
La persona o función que indique el procedimiento local; registra el cambio, su motivo y la nueva fecha en el sistema acordado.
¿Qué hacer si dos órdenes compiten por un recurso?
Deja visible el conflicto y revisa prioridad, disponibilidad y ventanas con las personas responsables; el orden visual no resuelve la asignación.
¿Una fecha en el calendario confirma que el trabajo se ejecutó?
No. La fecha es una previsión; comprueba el estado y el registro de la orden para saber qué ocurrió.
Una vista que se pueda actualizar
Un cronograma se vuelve difícil de usar cuando mezcla órdenes pendientes, ventanas propuestas y trabajos cerrados sin explicar la diferencia. Mantén la referencia a la orden, usa las unidades que reconozca el proceso y deja visible la fecha de actualización. Si las personas responsables pueden volver desde la fila al registro actual, la vista sirve para coordinar sin fingir que contiene toda la información técnica.
La guía de Reclamation aporta una distinción concreta entre backlog y programa semanal, y describe cómo prioridad, recursos, estados y coordinación entran en su propio proceso. El esquema de campos y los ejemplos de esta página son propuestas editoriales para leer una vista de planta; no son un formulario oficial. La decisión final sobre clasificación, ventana y estado corresponde a los procedimientos de la organización que mantiene la orden.