Un modelo BIM puede estar técnicamente bien hecho y, aun así, nacer dentro de un sistema que no puede sostenerlo. Puede tener geometría correcta, parámetros consistentes y una producción disciplinada, y seguir sin responder al propósito para el que fue solicitado, porque nadie verificó, antes de modelar, si existían las condiciones de información, gobernanza y coordinación necesarias para que ese modelo cumpliera su función dentro del proyecto.
Este artículo se apoya en experiencia profesional real de integración eléctrica en un proyecto industrial de alta complejidad, y desarrolla una pregunta que antecede a cualquier decisión de modelado: ¿existen las condiciones de información, gobernanza y coordinación necesarias para integrar un modelo que pueda cumplir su propósito? Auditar esa pregunta antes de comenzar a producir puede reducir la exposición a retrabajos y decisiones apoyadas en información insuficiente que después suelen atribuirse únicamente a la calidad del modelo.
Antes de comenzar a producir
Es habitual que la producción BIM se entienda como el punto de partida de un proyecto: se abre la herramienta de modelado, se configura una plantilla, y el trabajo comienza. Esta manera de proceder da por hecho algo que rara vez se verifica: que existe, detrás del modelo, un sistema de información suficientemente confiable para sostenerlo.
La experiencia que sustenta este artículo sugiere una secuencia distinta. Antes de que exista un modelo conviene preguntar para qué debe servir, qué información lo alimenta, bajo qué reglas se desarrollará, quién toma las decisiones que lo afectan, dónde reside la información del proyecto y cómo deberá evolucionar durante la vida del activo. Una auditoría inicial no debería limitarse a preguntar si un modelo está bien hecho: debe intentar establecer si existe un sistema de información suficientemente confiable para comenzar a integrar.
Modelar no es lo mismo que integrar
En SORA, modelar es parte del trabajo; integrar es el objetivo. Producir geometría y datos asociados es necesario, pero no es, por sí solo, suficiente: integrar exige comprender cómo esa información se relaciona con el propósito del modelo, con las demás disciplinas, con las reglas del proyecto, con el sistema de información que lo sostiene, con la realidad construible, y con las etapas posteriores de la vida del activo. Modelar puede reducirse a producir geometría y datos dentro de un archivo; integrar exige, además, situar ese archivo dentro del entorno común de datos donde habrá de publicarse, del control de versiones vigente, de las responsabilidades asignadas, de la nomenclatura y los parámetros compartidos, y de los procesos de coordinación establecidos.
Esta es una conclusión que se deriva del argumento, no una consigna: el objetivo no es producir un modelo, sino que ese modelo tenga sentido, sea confiable y sea utilizable dentro de un sistema que lo excede. La integración, en ese sentido, no comienza necesariamente dentro de una herramienta de modelado: comienza antes.
La primera pregunta: ¿para qué servirá el modelo?
Una de las preguntas que esta experiencia sitúa antes que cualquier otra es simple de formular y, sin embargo, se omite con frecuencia: antes de modelar, es necesario saber para qué se va a utilizar el modelo. Los requisitos de un modelo no son equivalentes según su uso previsto. No es lo mismo producir información para apoyar decisiones de diseño, para coordinar entre disciplinas, para sostener la construcción, para documentar la condición ejecutada como As-Built, o para servir como base de información durante la operación y el mantenimiento del activo.
Un modelo destinado a construcción debe poder sostener construcción: sus dimensiones, sus clearances y sus puntos de conexión deben responder a una realidad ejecutable. Un modelo destinado a operación y mantenimiento necesita representar adecuadamente la condición construida y contener, o relacionarse de manera trazable con, la información necesaria para apoyar la gestión posterior del activo: el modelo no tiene por qué convertirse en el repositorio único de esa información para cumplir esa función. Determinar el propósito no es un paso administrativo previo al modelado: determina qué información es necesaria, qué nivel de detalle se requiere y qué controles deben existir antes de comenzar a producir.
Auditar el sistema detrás del modelo
La experiencia que sustenta este artículo puede describirse, de manera conceptual, como una secuencia de trabajo observada —no como una metodología oficial ni como un procedimiento universal—: requisición formal de información, centralización en una ruta compartida, análisis de si lo recibido resulta suficiente, reconocimiento del contexto BIM del proyecto —versión de la herramienta de modelado, plataforma, entorno común de datos, responsables de coordinación—, verificación de la gobernanza vigente, revisión o solicitud del Plan de Ejecución BIM, configuración de la plantilla y los parámetros compartidos, y solo entonces la integración propiamente dicha.
Esta secuencia permite una distinción central para el argumento de este artículo. Desde la perspectiva estricta de la producción eléctrica, la información mínima para comenzar a modelar puede limitarse a planos y fichas técnicas; otros elementos, como especificaciones o formatos específicos, pueden no bloquear de inmediato el trabajo según el caso. Pero integrar ese modelo dentro de un proyecto exige, además, conocer dónde se centraliza la información, cómo se publica, quiénes son los responsables, cómo opera la coordinación, qué establece el BEP y para qué servirá el modelo. Información suficiente para modelar no es lo mismo que condiciones suficientes para integrar. La primera puede existir mientras la segunda permanece ausente, y un proyecto puede avanzar produciendo geometría durante semanas antes de que esa ausencia se vuelva evidente.
Un BEP no debería ser solamente una plantilla
El caso que sustenta este artículo corresponde a un proyecto industrial de alta complejidad, en el que la experiencia se incorporó para trabajar la especialidad eléctrica. Al incorporarse la especialidad se observaron, dentro del alcance correspondiente, condiciones que dificultaban ese trabajo: falta de claridad en los procesos, dificultad para localizar la información necesaria, ausencia de responsables claramente identificables y una estructura de información difícil de interpretar. En ese momento no se encontró disponible para el alcance revisado un Plan de Ejecución BIM que permitiera orientar la integración, y los modelos recibidos no ofrecían un control de actualización y versiones suficiente para trabajar con el grado de confianza requerido.
Más adelante se revisó una versión del BEP. Desde el alcance evaluado, conservaba una estructura general que todavía no respondía con suficiente precisión a varias necesidades operativas del proyecto. Esta observación conduce a un principio que la experiencia permite sostener: un proyecto tiene un objetivo, y el BEP debería estructurar cómo la información y los actores contribuirán a producir ese resultado. La nomenclatura, la coordinación, la publicación, las responsabilidades, el entorno común de datos y la estructura de los modelos son mecanismos al servicio de ese objetivo, no el objetivo mismo. Un BEP puede estar correctamente presentado —con el formato esperado, los apartados convencionales, la terminología reconocible— y, aun así, resultar insuficiente si no responde a las necesidades reales del proyecto que dice gobernar. La experiencia sugiere, además, que un BEP debería poder evolucionar junto con el proyecto, en lugar de fijarse como documento estático desde su primera versión.
Marcos como la familia de normas ISO 19650 pueden ofrecer una referencia relevante para estructurar la gestión de información de un proyecto de esta naturaleza. Este artículo no evalúa si el proyecto descrito cumplió o no con esa familia normativa: no existe, dentro de la experiencia que lo sustenta, evidencia suficiente para sostener una afirmación de esa naturaleza, y convertir la auditoría en un ejercicio de cumplimiento normativo excedería lo que aquí puede demostrarse.
El modelo no puede evaluarse aislado
Sería impreciso afirmar que la constructibilidad de una especialidad puede determinarse simplemente abriendo su modelo. Una instalación eléctrica puede parecer correcta observada de manera aislada, y presentar problemas reales al relacionarse con arquitectura, estructura, climatización, protección contra incendio o las rutas que comparte con otras instalaciones. La integración de una especialidad no puede evaluarse observando únicamente la disciplina que se pretende integrar: para identificar sus interfaces reales, es necesario estudiar el proyecto en su conjunto.
Esto también aplica a la capacidad misma de evaluar. La experiencia de obra y el conocimiento BIM son capacidades complementarias, y ninguna, por separado, resulta suficiente para este tipo de evaluación. Un modelo puede verse correctamente modelado, no presentar interferencias evidentes y parecer ordenado, y aun así no responder adecuadamente a la construcción, a la operación o al mantenimiento, si quien lo evalúa no puede relacionar lo que ve en el modelo con lo que exige la realidad construida.
Cuando la estructura existente aumenta el riesgo
No toda situación observada admite la misma respuesta. En determinadas situaciones fue necesario reconstruir total o parcialmente modelos existentes porque continuar sobre su estructura habría aumentado la incertidumbre y el costo técnico de interpretación. No se trató de una decisión estética: su estructura resultaba difícil de interpretar, contenía parámetros cuyo significado ya no era claro o utilizaba nomenclaturas que habían perdido continuidad con el resto del proyecto.
Esto no debe leerse como una regla general —"si un modelo está mal, hay que rehacerlo"—: sería una simplificación que la experiencia no sostiene. El principio es más preciso: la decisión de conservar, corregir o reconstruir un modelo debe ser consecuencia de entender su estructura real y el costo técnico de continuar trabajando sobre ella, no una reacción automática frente a un modelo que, a primera vista, no cumple con el estándar esperado.
Simplificar también puede ser gobernar
Los lineamientos eléctricos desarrollados dentro de esta experiencia trabajaron aspectos como identidad, sistemas, nomenclatura, worksets, plantillas de vista, cédulas y nombres de tableros, entre otros. El objetivo no fue aumentar la sofisticación del modelo, sino simplificar la información y hacerla interpretable, de modo que una persona con el conocimiento técnico necesario pudiera comprender su estructura sin depender exclusivamente del conocimiento tácito de quien la creó.
De esta experiencia puede sostenerse un aprendizaje, no una regla universal: complejidad no equivale a madurez BIM. Una estructura sofisticada que no puede interpretarse ni sostenerse en el tiempo puede resultar menos útil que una estructura sencilla, consistente y trazable. Gobernar la información de un modelo no siempre significa añadir controles: en ocasiones significa reducir lo que no aporta claridad, hasta que la estructura restante pueda sostenerse sin depender de que una sola persona recuerde por qué se hizo así.
Qué condiciones mínimas permiten comenzar
Una auditoría de este tipo también debe observar el sistema alrededor del modelo, no únicamente su contenido interno: la estructura de carpetas del entorno común de datos, quiénes son responsables de ellas, cómo se controlan las versiones y con qué periodicidad se publica la información. Sobre los actores del proyecto, resulta necesario identificar, al menos, su nombre, su responsabilidad específica y un canal de contacto confiable. Cuando no está claro quién decide, quién aprueba o quién coordina, se pierde trazabilidad, con independencia de qué tan completa parezca la documentación disponible.
Sin embargo, una auditoría de este tipo no necesita resolver absolutamente todo antes de permitir que comience la producción. Lo que esta experiencia considera necesario es poder determinar, al menos, dónde se centraliza la información, cómo y con qué periodicidad se publica, quiénes son los responsables, para qué se utilizará el modelo, y qué condiciones mínimas permiten integrarlo con un grado razonable de confianza. Pueden existir pendientes: la diferencia relevante es que estén identificados, sean visibles para quien deba gestionarlos, y puedan gestionarse de manera activa, en lugar de ignorarse hasta manifestarse como un problema en obra.
Identificar un pendiente, sin embargo, no significa necesariamente que el trabajo pueda continuar sin ajustes: su impacto debe evaluarse respecto de la actividad que depende de él. Algunos pendientes pueden gestionarse durante la producción sin detenerla; otros condicionan determinadas decisiones; y algunos pueden hacer técnicamente inconveniente continuar hasta obtener mayor claridad. Buscar una perfección documental completa antes de comenzar a trabajar no es, en esta experiencia, una condición razonable ni necesaria.
Convertir hallazgos en acciones
Frente a las condiciones descritas, la respuesta no consistió en comenzar a modelar de todos modos, ni en detener el proyecto a la espera de condiciones ideales. Consistió en auditar lo disponible, formalizar los hallazgos en un documento, proponer lineamientos concretos, presentarlos al equipo de coordinación y, a partir de ahí, integrar la especialidad bajo condiciones más controladas que las que existían al inicio. La intención de ese ejercicio no fue señalar responsables, sino sumar a lo que ya existía, aunque todavía no ofreciera un grado de confianza suficiente.
Una auditoría que únicamente produce una lista de deficiencias tiene un valor limitado: documenta un problema, pero no necesariamente lo transforma en una condición de trabajo distinta. Resulta más útil cuando permite determinar qué conservar, qué corregir, qué reconstruir, qué información solicitar todavía, y bajo qué condiciones concretas puede comenzar a integrarse la especialidad. La auditoría termina siendo valiosa cuando se traduce en acciones que enriquecen la gobernanza y la trazabilidad del proyecto, no cuando se agota en el diagnóstico.
La auditoría como punto de partida de la integración
Comenzar a producir sin haber comprendido el sistema de información que rodea al modelo puede contribuir, según sugiere esta experiencia, a retrabajo, a interferencias que pudieron anticiparse, a decisiones tomadas sobre información desactualizada y a responsabilidades mal atribuidas cuando algo debe corregirse. Este artículo no cuantifica esos efectos ni sostiene que ocurran de manera necesaria en todo proyecto: la experiencia que lo sustenta permite afirmar que el riesgo existe, no medir su magnitud.
La pregunta que abrió este artículo —¿existen las condiciones de información, gobernanza y coordinación necesarias para integrar un modelo que pueda cumplir su propósito?— no se responde una sola vez ni se agota en una lista de verificación. Se responde, de manera parcial y siempre provisional, antes de comenzar a modelar, y se revisa a medida que el proyecto avanza. Auditar esas condiciones no es un paso previo, prescindible, a la verdadera integración: es la forma en que la integración comienza.
Etiquetas