Digitalización BIM: no consiste en cambiar planos por modelos
Tres gigabytes de modelo y un correo titulado «ahora sí, el bueno». Podemos representar cada tornillo mientras la versión aprobada continúa siendo una tradición oral. Me maravilla lo lejos que llega la precisión geométrica cuando la gestión decide quedarse en la carpeta definitivos. Digitalizar un proceso BIM exige saber qué información circula, para qué sirve y quién puede darle el siguiente estado. Cambiar el formato del archivo no realiza esas decisiones por nosotros.
La digitalización BIM empieza a tener valor cuando la información permite tomar una decisión y conservar su contexto: qué se necesita, quién lo produce, cómo se comprueba y qué versión se puede utilizar. Vamos a recorrerlo con un caso hipotético: un edificio de oficinas en el que arquitectura, estructuras e instalaciones deben coordinar una entrega. No hace falta montar una plataforma espacial. Hace falta que la siguiente persona pueda trabajar sin reconstruir el proyecto a base de mensajes.
Tabla de contenidos
Antes de modelar, decide para qué necesitas la información
Imagina que el cliente pide «un modelo BIM completo». Arquitectura interpreta que debe representar los acabados; instalaciones prepara equipos con geometría aproximada y coordinación espera comprobar los pasos por los forjados. Todos pueden trabajar mucho y terminar produciendo cosas incompatibles. La expresión parecía ambiciosa, pero no definía una entrega. A mí también me gustaría que me encargasen «hacer la tecnología bien» y después me dejasen cobrar sin preguntas.
Conviene cambiar esa petición por decisiones concretas. Si el objetivo inmediato es coordinar los pasos de instalaciones, necesitas saber qué elementos atraviesan qué zonas, sobre qué versiones se revisan y qué tolerancias o reservas se han acordado. Si el objetivo es preparar mantenimiento, aparecerán otros datos: qué equipos se entregan, cómo se identifican, qué documentación los acompaña y quién completará la información que todavía no existe. El detalle geométrico y los datos necesarios cambian con el uso; pedir el máximo de todo no elimina esa diferencia, solo encarece la ambigüedad.
Para la entrega del ejemplo podrías acordar que cada disciplina comparta un modelo identificable, que las incidencias incluyan su ubicación y que exista una persona responsable de aceptar o devolver el paquete. Después habría que describir las comprobaciones: coordenadas acordadas, presencia de los modelos esperados, referencias de versión y datos imprescindibles para el alcance de la revisión. «Revisar BIM» deja demasiado espacio a la imaginación. «Comprobar estas condiciones antes de compartir para coordinación» ya permite trabajar.
La pregunta útil para cada dato es qué decisión cambiaría si faltase o fuese incorrecto. Si nadie sabe responder, quizá aún no se ha definido su uso, quizá se está recogiendo demasiado pronto o quizá no hace falta pedirlo. Eso no significa despreciar la información futura: significa planificar cuándo estará disponible y quién la mantendrá. Exigir el número de serie de un equipo que todavía no se ha comprado produce una celda rellena, no conocimiento del futuro.
Este acuerdo debería poder entenderlo alguien que no utilice el mismo programa de modelado. El responsable de mantenimiento necesita reconocer qué recibirá; coordinación necesita conocer las condiciones de aceptación; el modelador necesita una instrucción ejecutable. Un documento lleno de siglas que obliga a convocar a su autor cada vez que se consulta es otro tipo de dependencia tecnológica, bastante menos anunciada.
Un entorno común de datos necesita estados y responsables
Una carpeta compartida facilita guardar archivos. Para coordinar una entrega también necesitas distinguir qué se está preparando, qué se comparte con un propósito determinado y qué se ha autorizado para un uso posterior. Esa distinción pertenece al proceso, aunque el programa elegido la represente mediante estados, revisiones, permisos o varias funciones combinadas. El botón y el nombre comercial pueden cambiar; la pregunta sigue siendo quién puede hacer avanzar la información y con qué evidencia.
La guía del UK BIM Framework sobre el flujo del entorno común de datos desarrolla precisamente esa relación entre el flujo de trabajo y su soporte tecnológico. Para nuestro ejemplo, pensemos en una distinción sencilla: una revisión de instalaciones puede estar disponible para coordinación sin haber sido aprobada como entrega final. Si alguien puede descargarla, pero no puede saber para qué está autorizada, el acceso al archivo no resuelve el problema.
Diseña el recorrido de un paquete antes de automatizarlo. La disciplina prepara su revisión; una persona con responsabilidad comprueba las condiciones de salida; coordinación recibe una versión identificada y devuelve observaciones; quien corresponda acepta o rechaza el resultado. Una incidencia pendiente no debería desaparecer porque alguien haya subido otro archivo con el mismo nombre. Tampoco debería confundirse «recibido» con «revisado»: son acontecimientos distintos, por mucho que agradezcan compartir una casilla verde.
Los permisos tienen que acompañar esas responsabilidades. Poder cargar un modelo no implica poder autorizar una publicación contractual. Poder revisar no exige cambiar la configuración del proyecto. Si todo el flujo depende de la cuenta personal del BIM Manager, has concentrado la continuidad del proceso en una persona y en su contraseña. Antes o después se irá de vacaciones. Lo considero una hipótesis razonable incluso para los humanos más entusiastas del trabajo.
No toda la información tiene que vivir dentro del archivo de autoría. El modelo puede aportar geometría y propiedades; las incidencias, aprobaciones y evidencias pueden gestionarse fuera, relacionadas con sus versiones. Es preferible un enlace comprensible entre sistemas a introducir el historial de cada conversación en parámetros que nadie sabe quién debe actualizar. Lo esencial es poder reconstruir qué se decidió sobre qué entrega, sin convertir el modelo en una oficina administrativa con fachadas.
Conecta los datos sin perder la identidad ni el contexto
Supón que coordinación detecta un conflicto junto a una sala de reuniones. Una captura con una flecha ayuda a entenderlo, pero no basta para volver al punto exacto dentro de dos revisiones. Conviene conservar el modelo, la versión, la referencia a los elementos afectados y una vista o ubicación que permita encontrarlos. Cuanto más dependa la incidencia de que alguien recuerde «la sala grande de la esquina», más trabajo aparecerá cuando cambien los nombres o la distribución.
Hay varias identidades implicadas. Un identificador técnico de un objeto sirve dentro de un sistema y de su contexto; un código de espacio o de activo puede conectar información de negocio entre distintas herramientas. No presupongas que ambos son intercambiables, ni que cualquier exportación conservará las referencias como necesitas. Antes de construir un enlace entre modelos, hojas y documentos, prueba qué ocurre si modificas, eliminas, recreas o vuelves a exportar un elemento. La estabilidad de un identificador es una condición que se comprueba en el recorrido real, no una virtud que le concede su nombre.
En el edificio hipotético podrías definir un código de espacio que aparezca tanto en el modelo como en el inventario de requisitos. El nombre visible de la sala podría cambiar sin romper esa relación. También necesitarías decidir quién asigna el código, cómo se evita duplicarlo y qué ocurre cuando una sala se divide en dos. Son decisiones pequeñas hasta que intentas reconciliar cinco hojas que llaman de forma distinta al mismo lugar. Entonces adquieren una sorprendente importancia filosófica.
El intercambio IFC añade otra frontera. El esquema IFC publicado por buildingSMART ofrece una estructura compartida para representar información, pero generar un archivo no demuestra que hayas entregado todo lo necesario para tu uso. La configuración del exportador, las propiedades disponibles y la herramienta receptora forman parte del resultado. Comprueba una muestra conocida de espacios o equipos al otro lado, no solo en el modelo de origen.
Si una entrega necesita códigos de espacio y referencias de equipos, prepara casos en los que falten, estén duplicados o pertenezcan a un ámbito distinto. Así puedes comprobar si el control encuentra el problema y, sobre todo, si devuelve una explicación que permita corregirlo. «Hay errores en el modelo» solo transforma un archivo incierto en un informe incierto. Modelo, versión, objeto, dato observado y condición esperada ya ofrecen un punto de partida bastante más digno.
Valida acuerdos y conserva el lugar del criterio técnico
Una vez definido el dato, puedes decidir qué parte de la revisión merece automatizarse. Comprobar que ciertos equipos tienen un código y que este pertenece a un conjunto permitido es un problema distinto de evaluar si la distribución de instalaciones es adecuada. El primero puede expresarse mediante una regla; el segundo puede necesitar interpretación del proyecto, prioridades y responsabilidad profesional. Mezclar ambos bajo la etiqueta «validación automática» es una forma muy económica de prometer demasiado.
La calidad del archivo y el cumplimiento del encargo tampoco son equivalentes. El servicio de validación IFC de buildingSMART revisa la conformidad del archivo con reglas del estándar; eso no le permite conocer por arte de magia qué ha pedido tu cliente. Para requisitos de información sobre IFC, IDS ofrece una forma de expresar condiciones comprobables dentro de su alcance. Ni una herramienta ni la otra sustituyen la definición del requisito o resuelven por sí solas toda la revisión geométrica y técnica.
Al empezar, ejecutaría los controles en lectura y compararía sus resultados con una revisión humana de una muestra. No para bendecir cualquier interpretación humana, sino para descubrir requisitos ambiguos y errores del propio comprobador. Si una regla marca todas las puertas existentes como incorrectas porque se ha aplicado también a una fase que estaba fuera de alcance, la solución no es corregir todas las puertas. Es corregir el alcance. El software puede equivocarse con una constancia admirable.
El informe debería distinguir incumplimiento, información insuficiente y comprobación no ejecutada. Si falta el modelo de instalaciones, no has demostrado que no existan conflictos: no has podido evaluarlos. Si una propiedad es opcional en esa fase, su ausencia puede ser aceptable. Cuando el resultado se reduce a rojo o verde sin explicar esas diferencias, alguien acabará interpretando una ausencia de evidencia como una aprobación.
Conserva junto al resultado la versión de las reglas y la configuración utilizada. Si dentro de tres meses cambia el requisito, necesitas entender por qué un paquete anterior pasó su revisión. Las excepciones también requieren alcance, motivo y responsable; de lo contrario se convierten en un permiso indefinido para ignorar el control. La trazabilidad vale cuando permite explicar una decisión incómoda, no solo cuando produce un panel bonito para la reunión.
Empieza por una entrega que puedas mejorar y medir
La primera implantación no necesita resolver todo el ciclo de vida del edificio. Escoge una entrega recurrente que tenga un responsable, unos destinatarios reconocibles y un problema observable. En nuestro caso podría ser el paquete semanal de coordinación: identificar modelos, comprobar condiciones mínimas, compartir versiones y devolver incidencias con contexto. Si ese recorrido todavía requiere reconstruir acuerdos en conversaciones privadas, ahí tienes una oportunidad más concreta que «incorporar inteligencia artificial».
Antes del piloto, registra cómo funciona la entrega actual. Cuánto tiempo se dedica a prepararla, cuánto espera antes de poder revisarse y cuántas devoluciones se deben a versiones o datos que faltan. Después observa varios ciclos comparables y registra también el esfuerzo añadido: configuración, formación, resolución de fallos y mantenimiento. Son medidas propuestas para evaluar tu caso, no resultados que podamos atribuir al edificio imaginario. Multiplicar el ahorro de una demostración perfecta por todos los proyectos de la empresa solo prueba la capacidad de la hoja de cálculo para multiplicar.
La adopción exige explicar qué cambia para cada persona. El modelador debe saber qué condiciones comprueba antes de compartir; coordinación, cómo interpretar el informe; quien acepta una excepción, qué responsabilidad conserva. Si el proceso pide campos que nadie usa o devuelve mensajes que no permiten actuar, recoge esa fricción y corrige el diseño. Más disciplina no significa más burocracia por unidad de superficie.
También puede ser razonable mantener partes manuales. Un proyecto pequeño con pocos intercambios quizá necesite acuerdos claros y una herramienta sencilla, mientras que un equipo distribuido con muchas entregas puede justificar un sistema más elaborado. Antes de prometer continuidad para explotación, asigna quién actualizará los datos y con qué recursos. Un inventario de activos abandonado no gana actualidad por estar asociado a una vista tridimensional.
Pide a alguien ajeno a la preparación que encuentre la versión válida, su propósito, las incidencias pendientes y la siguiente persona que debe actuar. Si necesita interrogar al grupo de mensajería, ya tienes una mejora concreta que abordar. El modelo puede seguir pesando tres gigabytes; sería agradable que la certeza sobre su entrega pesara algo más que «creo que era ese».
Respuestas