Volver al blog

Documentación de obra terminada que se genera automáticamente

El enfoque tradicional respecto a la documentación de obra terminada consiste en recopilarla una vez finalizada la construcción. El problema es que, para entonces, el registro ya es erróneo. Nosotros consideramos la documentación de obra terminada como un subproducto del propio trabajo, y no como un producto final que se entrega al término de la obra.

as-builtgisfield-operationscompliance

El problema de los planos de obra terminada

Se supone que todo proyecto de infraestructura debe generar un informe de obra terminada: un documento o plano que refleje lo que realmente se ha construido, en contraposición a lo que se diseñó. El diseño indica que el cable discurre por el lado norte de la carretera. El equipo lo tendió por el lado sur porque había una tubería de gas que lo impedía. El informe de obra terminada debe reflejar esa realidad.

En la práctica, la documentación de obra terminada es uno de los entregables menos fiables en los proyectos de infraestructura. No porque los equipos sean descuidados, sino por el momento y la forma en que se elabora el registro. El proceso habitual es el siguiente: una vez finalizada la construcción, alguien recopila las notas de campo y las fotos del equipo de obra; un delineante abre los planos de diseño originales y los modifica para reflejar lo que realmente ha ocurrido. Este proceso suele comenzar semanas después de que la construcción haya finalizado. El equipo de obra ya se ha marchado. Las notas de campo están incompletas. Las fotos no siempre dejan claro qué ha cambiado y qué se ha mantenido igual. El delineante está reconstruyendo una historia a partir de fragmentos, y el resultado es un registro de obra terminada que es mejor que nada, pero peor de lo que cualquiera aceptaría si supiera cómo se ha elaborado.

El problema se agrava con el tiempo. El siguiente proyecto toma como referencia el plano de obra, diseña basándose en él y envía un equipo al terreno, donde descubren que el plano de obra anterior era erróneo. Ahora tienen que adaptarse a la discrepancia, y el nuevo plano de obra hereda la inexactitud del anterior, además de cualquier nueva desviación. Tras tres o cuatro ciclos de esto, el registro de lo que realmente hay en el terreno solo guarda un parecido superficial con los planos.

Por qué fracasa la «asamblea a posteriori»

El problema fundamental es la sincronización. Cuando separas el acto de realizar el trabajo del acto de registrarlo, se crea una brecha que no hace más que agrandarse.

El registro a posteriori pierde detalles. Un trabajador de campo que anota lo que ha hecho al final del día recuerda las decisiones importantes —cambiar el trazado del cable, añadir una caja de conexiones adicional—. No recuerda las coordenadas exactas, las distancias precisas ni los pequeños ajustes. Un trabajador de campo que va registrando sobre la marcha lo capta todo, porque tiene la información delante de sus ojos.

Los sistemas independientes pierden el contexto. Cuando el proyecto se encuentra en un sistema y los planos de obra terminada en otro, el único vínculo entre ambos es la memoria de una persona. ¿Qué orden de trabajo dio lugar a qué modificación en los planos de obra terminada? Si no puedes responder a esa pregunta consultando una base de datos, no podrás responderla de forma fiable en absoluto.

El montaje por lotes hace que se pierda el historial. Cuando un delineante modifica los planos semanas después de la construcción, no existe un registro de auditoría que relacione un cambio concreto en el plano con un informe específico procedente de la obra. El plano de obra es una instantánea única. Nadie puede reconstruir cómo se llegó a ese estado, qué cambios están respaldados por pruebas y cuáles son meras suposiciones del delineante.

El traspaso al equipo de operaciones conlleva la responsabilidad de los errores. La documentación de obra terminada suele ser el último entregable antes de que se cierre un proyecto y el activo se transfiera al equipo de operaciones. Si dicha documentación es errónea, el equipo de operaciones lo descubre de la peor manera posible —durante una reparación, una ampliación o una emergencia—, cuando el coste de una información errónea es mayor.

El mapa como un plano de obra actualizado

Nuestro enfoque no genera un registro de obra terminada al final del proyecto. El registro de obra terminada es el mapa en el que tu equipo ha estado trabajando a lo largo de todo el proyecto, y se va completando a medida que avanza el trabajo.

Los elementos del mapa constituyen el registro. Cuando un técnico de campo edita un elemento —desplaza un punto, ajusta el trazado de un cable o añade un nuevo punto de empalme—, esa modificación constituye la actualización del estado real. Se lleva a cabo en el lugar de trabajo, con las coordenadas GPS capturadas desde el dispositivo, en el momento en que se realiza el trabajo. No hay ningún paso adicional.

Cada modificación está controlada por versiones. Cada cambio genera una entrada de versión: quién realizó el cambio, cuándo y cuál era el estado anterior. El historial de versiones se comprime, pero nunca se elimina. Puedes reconstruir el estado de cualquier función en cualquier momento: no solo el estado actual, sino toda la evolución desde el diseño hasta la construcción.

Las versiones enviadas desde el terreno se someten a revisión por parte del administrador. Un trabajador de campo no modifica directamente el mapa compartido. Envía una versión —un conjunto de cambios propuestos— que revisa un administrador. El administrador ve las diferencias: qué ha cambiado, dónde y cómo se compara con el estado actual. Si el cambio tiene sentido, se aplica. Si no es así, se rechaza con una nota. Esto significa que el registro de obra terminada cuenta con un control de calidad integrado en cada actualización, y no añadido al final.

La detección de conflictos evita las sobrescrituras silenciosas. Si dos trabajadores de campo editan la misma zona, el sistema detecta el solapamiento y lo señala para su resolución. La actualización de un equipo no sobrescribe silenciosamente la de otro. En el montaje tradicional de planos de obra, las notas de campo contradictorias de diferentes equipos suelen conciliarse según el criterio del delineante. En un sistema con versiones, el conflicto sale a la luz y se resuelve de forma explícita.

Del diseño a la obra terminada en un solo sistema

El proceso que permite obtener un plano de obra finalizado tiene el siguiente aspecto:

Importar el diseño. Carga los planos de diseño originales —Shapefile, GDB, GeoPackage, DXF— en el mapa como elementos preliminares. Estos elementos se almacenan en un área de preparación donde pueden revisarse, filtrarse por zona, comprobarse si colisionan con datos existentes y asignarse a las capas correspondientes. La importación constituye la línea de base del diseño.

Planifica el trabajo basándote en el diseño. Las tareas se crean en el mapa con una geometría que indica dónde deben realizarse los trabajos y los requisitos de recursos que especifican qué materiales y mano de obra se necesitan. La geometría de la tarea constituye el plan.

Ejecutar y registrar. Los trabajadores de campo realizan el trabajo y, a continuación, envían informes con datos geográficos de GPS que indican dónde se llevó a cabo realmente el trabajo. Los datos geográficos del informe reflejan la realidad. Si el cable discurría por el lado sur en lugar de por el norte, los datos geográficos del informe lo reflejan tal y como ocurrió en ese momento, según el dispositivo que se encontraba allí.

Actualizar el mapa. Los trabajadores de campo editan los elementos del mapa para reflejar lo que se ha construido. Mover la línea de cable a su trazado real. Añadir la caja de conexiones adicional que no figuraba en el diseño. Eliminar el elemento previsto que no se ha construido. Enviar la versión para que la revise el administrador.

Revisar y publicar. Un administrador revisa la versión enviada desde el terreno, la compara con el diseño de referencia y los informes, y la publica en el mapa compartido. El mapa publicado pasa a ser el mapa de situación real: no se trata de un documento independiente, sino del mismo mapa que utilizará el equipo de operaciones en adelante.

El traspaso es automático. Cuando finaliza el proyecto, el equipo de operaciones hereda el estado actual del mapa. No es necesario elaborar, revisar ni entregar ningún documento final de obra. El mapa que ven es el mismo que el equipo de construcción ha mantenido a lo largo de todo el proyecto. Cada elemento cuenta con un historial de versiones. Cada cambio se puede rastrear hasta su registro sobre el terreno y su aprobación por parte de la administración.

El registro de auditoría que realmente importa

El valor de este enfoque no radica solo en la comodidad. Radica en la procedencia.

Cuando un regulador, un cliente o un ingeniero de operaciones pregunta «¿qué hay realmente bajo tierra aquí y cómo lo sabes?», la respuesta es de carácter estructural:

  • El elemento del mapa cuenta con un historial de versiones que muestra todos los cambios, desde el diseño hasta la construcción.
  • Cada entrada de la versión registra quién la envió, la fecha y hora, y el administrador que la aprobó.
  • Los informes de campo que motivaron cada cambio están vinculados, junto con la geometría GPS, las fotos y los registros de consumo de materiales.
  • El registro de importación muestra la línea de base del diseño original que se cargó al inicio.
  • Todo se puede exportar —GeoJSON, CSV, registro de auditoría— desde el mismo sistema que lo generó.

Compáralo con la respuesta tradicional: «aquí tienes un PDF que un delineante elaboró seis semanas después de que terminara la obra». Una de estas respuestas inspira confianza. La otra suscita dudas.

Resumen

  • Los registros de obra terminada son uno de los entregables menos fiables en los proyectos de infraestructura, ya que se recopilan tras la construcción a partir de notas de campo dispersas y recuerdos que se desvanecen.
  • El problema fundamental es el tiempo: separar la ejecución de los trabajos de su registro crea una brecha que se amplía con cada ciclo de proyecto.
  • La recopilación por lotes a posteriori pierde detalles, contexto y procedencia, y entrega registros inexactos a los equipos de operaciones, que descubren los errores en el peor momento posible.
  • Cuando el mapa es el registro de obra terminada y los trabajadores de campo lo actualizan a medida que trabajan, el registro se crea solo, con coordenadas GPS, historial de versiones y revisión administrativa en cada paso.
  • Los planos de diseño se importan como referencia. Las tareas representan el plan. Los informes capturan la realidad. Las modificaciones de elementos reflejan lo que se ha construido. El historial de versiones lo conecta todo.
  • Las versiones enviadas desde el terreno pasan por una revisión administrativa con una comparación visual, de modo que el registro «tal y como se construyó» cuenta con un control de calidad en cada actualización, en lugar de una única revisión al final del proyecto.
  • La detección de conflictos garantiza que las ediciones superpuestas de diferentes equipos salgan a la luz y se resuelvan, en lugar de ser conciliadas en silencio según el criterio de un delineante.
  • El traspaso a operaciones es automático: el mapa que mantuvo el equipo de construcción es el mapa que hereda el equipo de operaciones, con la procedencia completa de cada elemento.