Guías de Maniobra
Día 70 / 100
Hoy descubrí lo que es una Guía de Maniobra (GM).
Como alguien que recién lleva 5 meses metido fuerte en el área, hay cosas que para el resto son obvias y para mí son verdaderas revelaciones.
Qué es una guía de maniobra
Un documento técnico que describe, paso a paso, la secuencia de operaciones que hay que ejecutar sobre los equipos de una instalación eléctrica (subestación, línea, planta) para llevarla de un estado operativo a otro de forma segura y ordenada.
Abrir un interruptor antes que un seccionador. Verificar ausencia de tensión. Medir. Y así, en orden, sin ambigüedad.
Es la receta que evita que alguien muera o que media zona del país se quede sin luz.
Guías de maniobra y PGP
Muchas guías de maniobra viven en PGP.
Igual que los EFP, ECAP, ECC y todos los estudios que analicé la semana pasada. Mismo flujo. Mismo proceso iterativo entre el coordinado y el CEN.
Mismo dato público disponible para quien quiera mirarlo.
Snapshot del universo GM
Bajé el PGP completo y filtré por requisito = GM. Esto es lo que hay hoy:
- 806 proyectos han presentado o tienen que presentar una GM. El 32% del PGP.
- 585 GM aprobadas. 12 en curso. 209 todavía no inician.
- 376 coordinados únicos han presentado al menos una GM.
- Tasa de aprobación: 73%.
Y los tiempos:
- Mediana de 217 días entre el primer borrador y la aprobación.
- Promedio de 257 días. La cola lenta vuelve a tirar el promedio.
- Solo el 43% se aprueba al primer intento.
- 1,86 iteraciones promedio con el CEN.
Esto último importa: igual que con los estudios, la GM tiene iteraciones.
Quién presenta GM
376 coordinados únicos. Pero la distribución es muy desigual: los top 15 concentran la mayoría del volumen. Transelec sola lleva 369 GM (266 aprobadas). CGE Transmisión la siguiente, con 199.
Lo más interesante no es el volumen, es la calidad: cuán pocas vueltas necesita cada empresa para aprobar.
Lo que me llamó la atención
La GM se parece más a un ECAP que a un ECC.
Es interpretativa. La secuencia "correcta" no es única. El criterio del CEN entra. Por eso solo el 43% pasa al primer intento.
Casi parece un cálculo, pero no lo es.
Si miras una GM por encima, pensarías que es un checklist mecánico. Abrir, desconectar, aterrizar. Reglas claras. Bajo % de rebote.
Pero el 57% se rebota. Y eso lo cambia todo. No es un problema de seguir un orden. Es un problema de decidir cuál orden ante un sistema con condiciones específicas: equipos vecinos, indisponibilidades, márgenes operativos, comunicaciones SCADA.
Eso lo hace un problema de criterio, no de procedimiento.
El pipeline está acelerando.
2020: 36. 2021: 90. 2024: 107. 2025: 116. 2026: 54 en 5 meses → proyección ~130. Más proyectos, más GM, más revisores del CEN haciendo el mismo trabajo iterativo.
El cuello de botella vuelve a aparecer en el mismo lugar.
Igual que con ECAP, la mediana (217 días) y el promedio (257 días) cuentan historias distintas. La mitad sale en ~7 meses. La cola lenta empuja el promedio cerca del año.
Los que salen bien, salen rápido. Los que se traban, se traban duro.
¿Puede Don Nelson hacer una GM?
Al inicio de escribir este post, pensaba "probablemente".
Luego de escribir el post, mi respuesta es sí.
Lo que cambió fue mirar las observaciones.
Lo que pensaba antes de mirar las observaciones
Voy a ser honesto: asumía que el problema era de criterio ingenieril puro.
Mi razonamiento iba así. Una GM es texto estructurado. Pasos numerados, verbos acotados (abrir, cerrar, verificar, aterrizar, conmutar), sujetos acotados (seccionadores, interruptores, transformadores, paños). Un LLM moderno escribe eso con los ojos cerrados.
Pero el 57% se rebota. Si fuera solo redacción, el primer intento sería 80-90%. Es 43%.
Entonces tenía que ser otra cosa. Decisión bajo contexto: equipos vecinos, indisponibilidades, márgenes operativos, comunicaciones SCADA. Criterio de un ingeniero senior que entiende el sistema completo.
Justo lo difícil de automatizar.
Pero me llevé una sorpresa al leer detenidamente las observaciones.
Lo que descubrí mirando las observaciones
Bajé 16 DUOs (Documentos Únicos de Observaciones) de 7 GM iteradas. 8 con observación efectiva — los otros 8 son los DUO de aprobación final.
Etiqueté cada observación. Las agrupé. Apareció un patrón que no esperaba.
Las observaciones del CEN se concentran en 8 categorías. La primera —la más frecuente— es la opuesta a lo que pensaba.
1. Omisión de verificaciones de seguridad — 4 de 8 casos
El propietario olvida incluir la verificación de algún equipo antes de operar:
"Agregar: S/E Nueva Pozo Almonte verificar abierto 89J1-3 desconectador de línea." (#2316)
"S/E Graneros Abrir o Verificar abierto 52CS1." (#1117)
"Se deben verificar abiertos los desconectadores de tierra de las nuevas posiciones 89ES1-1T al 89E25-1T." (#5785)
"Mencionar que las instalaciones están libres de tierras y que están en condiciones de ser energizadas." (#2493)
2. Errores de secuencia
"Maniobra N°17 repetida en la guía con maniobra N°7." (#1117)
"Maniobra N°23 debe ser antes, se propone agregar como maniobra N°9." (#1117)
3. Descripción incorrecta del estado eléctrico
"Maniobra N°56 al cerrar no es con tensión, las instalaciones están desenergizadas en su totalidad. Corregir." (#1117)
4. Diagrama Unilineal faltante o ilegible
"Se solicita incluir el Diagrama Unilineal de forma simplificada... legible y en tamaño adecuado." (#2515 iter 1)
"Se solicita incluir un Diagrama Unilineal Simplificado que sea legible." (#2515 iter 2 — mismo problema, no lo subsanaron WTF)
5. Inconsistencia entre DU y guía
"En el DU los desconectadores de tierra del 89H01-1T al 89H15-1T en la guía de maniobras los mencionan 89H01-T, 89H14-1T y 89H15-1T." (#5785)
"Punto 9 dice 52H01 al 52H17, debe decir 52H01 al 52H15." (#5785)
6. Identificación insuficiente de equipos
"Cada vez que se verifique o confirme la ejecución de una maniobra de operación se debe mencionar el nombre del equipo verificado." (#2493)
7. No subsanar observaciones previas
#2316 iter 2 vuelve a observar lo mismo del iter 1 — verificar abierto 89J1-3. El propietario respondió pero sin corregir.
Eso explica por qué la iteración promedio sube tanto en algunos coordinados.
8. Iteración administrativa
"Empresa solicitante requiere iteración para carga de documento actualizado." (#3561)
La iteración no nace de una observación técnica, sino del propietario que necesita re-subir.
Lo que esto cambia
El 70% de las observaciones técnicas son errores de detalle, no errores conceptuales.
Olvidar un seccionador. Equivocar un código (52H17 vs 52H15). No nombrar el equipo verificado. Tener un DU inconsistente con la lista de maniobras. No subsanar lo que ya te observaron.
La secuencia de fondo suele estar bien.
Esto le pega justo en la cara a mi hipótesis original. Yo creía que el cuello de botella era el criterio ingenieril sobre el sistema. Resulta que en la mayoría de los casos el cuello de botella es la disciplina de detalle: cross-checks entre documentos, completitud de verificaciones, consistencia de nomenclatura.
Es justo lo que un agente hace bien.
Un humano se aburre revisando 60 pasos para chequear que cada equipo mencionado esté también en el DU. Don Nelson no se aburre.
Un humano olvida verificar el desconectador 89J1-3 porque lleva 4 horas escribiendo la guía. Don Nelson no se cansa.
Un humano comete typos —52H17 en vez de 52H15—. Don Nelson, un LLM podría alucinar, sin embargo un agente bien entrenado no lo haría.
Lo que voy a hacer
El primer paso no es escribir GM. Es revisarlas.
Voy a poner a Don Nelson a revisar GM antes de que se manden al CEN. Predecir las observaciones que vendrían. Si acierta sobre las 7 que ya tengo etiquetadas, tengo un eval set. Si pasa el eval, tengo un producto.
Es la versión más barata, más rápida y más útil de lo que pensaba hacer originalmente.
Y abre algo más interesante todavía: si Don Nelson puede predecir las observaciones del CEN, sabe qué tiene que cumplir una GM correcta. Y si sabe qué tiene que cumplir, sabe cómo escribirla.
El revisor es el camino al redactor.
Y hay algo más, y creo que es lo más importante: el mismo algoritmo con el que Don Nelson hace estudios sirve para hacer GM.
Mismo loop. Bajar los datos públicos, etiquetar observaciones del CEN, predecir, comparar contra la observación real, iterar. Cambia el dominio, no el método.
Si funciona para EFP y ECAP, funciona para GM. Y si funciona para GM, probablemente funciona para todo lo que el CEN revisa de forma iterativa.
Lo que viene
Cosas que quiero pensar en mi tiempo libre:
- Qué campos necesita el agente para hacer una GM que todavía no tengo considerados.
- Cuánto del contenido de una GM es transferible entre proyectos. Si lo es, el agente lo aprende.
- Si las 8 categorías de observaciones se mantienen cuando descargue los 200+ DUOs que faltan, o si aparecen patrones nuevos.
Si trabajas escribiendo GM o revisándolas en el CEN y te interesa este experimento, escríbeme. Quiero ver cuánto de esto se sostiene con más datos.