Digitalización BIM: no consiste en cambiar planos por modelos
La empresa aseguraba haber completado su digitalización BIM. Los planos ahora salían de Revit, los modelos ocupaban varios gigabytes y cada disciplina tenía una carpeta con un color distinto. Sin embargo, para saber si estructuras había entregado la versión correcta había que escribir un correo; los códigos de espacios viajaban en Excel; y la aprobación del cliente se conservaba en una conversación que empezaba con «según hablamos». Habían cambiado el soporte, pero el proceso seguía funcionando con arqueología.
Digitalizar no consiste en sustituir líneas por objetos tridimensionales. Un modelo puede contener mucha geometría y muy poca información útil. El cambio aparece cuando requisitos, decisiones, intercambios y responsabilidades se representan de forma que el equipo pueda consultarlos, validarlos y seguir su historia. BIM ofrece un buen armazón para hacerlo, aunque no lo hace por el mero hecho de instalar software.
Tabla de contenidos
El primer modelo llegó antes que las preguntas
El encargo era un edificio de oficinas con arquitectura, estructuras e instalaciones. El equipo empezó a modelar con rapidez porque «ya trabajaba en BIM». Dos semanas después, cada disciplina había interpretado de forma distinta los niveles de información, la nomenclatura y el uso de los modelos. Arquitectura esperaba coordinar espacios; instalaciones creía que bastaba con geometría aproximada; el cliente quería extraer datos de activos, pero aún no había definido cuáles.
El problema no se resolvía dibujando más. Faltaba traducir el encargo en requisitos de información: qué decisiones debía apoyar cada entrega, qué datos eran necesarios, quién los producía y cómo se comprobarían. Sin ese marco, un modelo detallado podía ser inservible para el uso previsto. También podía resultar carísimo, que es una forma bastante convincente de aprender la diferencia.
El equipo volvió al inicio y describió varios usos concretos: coordinación espacial, medición de determinadas partidas y preparación de información para mantenimiento. Para cada uso fijó objetos, propiedades, momento de entrega y responsable. La conversación dejó de girar alrededor de un nivel de detalle abstracto y empezó a responder preguntas verificables.
Modelar, informatizar y transformar no son la misma cosa
Modelar representa el edificio mediante objetos y relaciones. Informatizar sustituye un soporte manual por uno digital: una tabla en papel pasa a Excel, una revisión con rotulador se convierte en comentarios sobre PDF. Ambas cosas pueden aportar valor. La transformación del proceso exige algo más: que la información fluya con estados, reglas y responsables sin reconstruirse cada vez.
En la empresa, el parte de entrega era un correo libre. Alguien descargaba archivos, comprobaba nombres y copiaba datos a una hoja de seguimiento. Digitalizar ese tramo significó definir un contenedor de información con identificador, versión, estado y propósito. El sistema sabía si un archivo era trabajo en curso, compartido para coordinación o publicado. Una nueva versión no borraba la anterior ni la convertía mágicamente en obsoleta sin dejar rastro.
El resultado no fue eliminar todas las conversaciones. Fue impedir que una conversación privada actuase como base de datos. Las personas seguían decidiendo; el entorno conservaba qué se había decidido y sobre qué versión.
El CDE dejó de ser una carpeta con aspiraciones
El entorno común de datos se organizó alrededor de estados y permisos, no solo directorios. Cada disciplina controlaba su trabajo en curso. Al compartir, declaraba propósito y versión. Coordinación podía aceptar, rechazar o solicitar cambios, y la publicación requería una aprobación explícita. El nombre del archivo continuaba siendo útil, pero ya no cargaba con toda la semántica del proyecto.
Los permisos siguieron la responsabilidad. Un modelador podía cargar una revisión; no necesariamente publicar un paquete contractual. El cliente podía consultar entregables sin editar configuraciones internas. Este diseño evitaba dos problemas habituales: acceso excesivo «para no bloquear» y procesos que solo funcionan con la cuenta del BIM Manager.
También se acordó qué vivía fuera del modelo. Las incidencias, aprobaciones y estados no necesitaban incrustarse en parámetros de Revit. El modelo aportaba objetos e identificadores; el CDE mantenía el flujo y su historia. Intentar que un único archivo contenga geometría, decisiones, documentos, responsabilidades y clima emocional del equipo suele terminar con un archivo muy pesado y ninguna respuesta clara.
Los identificadores conectaron la conversación con los objetos
Para coordinar no bastaba con capturas. Una incidencia debía indicar modelo, versión, objeto y vista o ubicación. En Revit, el identificador del elemento permitía volver al origen dentro de un contexto controlado. En IFC, los identificadores y propiedades acordadas ayudaban a conservar la referencia durante el intercambio. La estabilidad debía probarse en el flujo real, especialmente si exportaciones sucesivas podían recrear objetos.
El equipo comprobó que varias tablas usaban códigos distintos para los mismos espacios. Unificó el identificador de negocio y definió quién podía asignarlo. El nombre visible podía cambiar; el código que conectaba espacio, requisito y activo debía permanecer. Así, una corrección dejaba de depender de buscar «Sala reuniones grande» en tres sistemas.
Los enlaces se validaban al publicar. Si un elemento obligatorio carecía de código, el paquete mostraba un bloqueo o una advertencia según el uso. El control no rellenaba automáticamente el valor con una ocurrencia creativa. Señalaba el hueco y dirigía la acción a quien conocía la decisión.
IFC se convirtió en un intercambio, no en un souvenir
Hasta entonces, exportar IFC demostraba que el equipo podía generar un archivo. La nueva definición de entrega indicaba para qué serviría: federación, revisión de propiedades y medición de categorías concretas. La configuración de exportación se versionó y se probó con ejemplos conocidos.
Después de generar el archivo, se comprobaba su contenido. Un IFC sintácticamente válido podía perder clasificaciones, conjuntos de propiedades o coordenadas necesarias. La validación distinguía estructura del archivo y cumplimiento del requisito. Abrirlo sin error era el principio, no la ceremonia de graduación.
Los fallos se devolvían con evidencia: entidad, identificador, propiedad encontrada y condición esperada. De este modo, el proveedor podía corregir el origen y no parchear una copia sin contexto. Cuando una excepción era aceptable, se registraba con alcance y responsable. El intercambio ganaba trazabilidad sin fingir que todos los modelos eran perfectos.
La validación hizo visibles los acuerdos
El equipo transformó requisitos estables en reglas: presencia de propiedades, valores permitidos, relaciones y coordenadas. Primero se ejecutaban en modo lectura y producían un informe. Durante varios ciclos se compararon con la revisión humana para detectar falsos positivos y requisitos mal expresados.
Las reglas no sustituían el juicio técnico. Podían comprobar que un espacio tuviera uso y superficie, pero no decidir si la organización espacial respondía bien al programa. Podían señalar una discrepancia entre modelos, no asignar automáticamente la responsabilidad contractual. La digitalización preparaba evidencia y reducía trabajo repetido; la decisión seguía teniendo autor y consecuencias.
Cada resultado conservaba versión de modelo, regla y configuración. Esto permitía explicar por qué una entrega había pasado un control meses atrás aunque la norma interna hubiese cambiado. Sin esa información, un dashboard verde solo es decoración corporativa.
La adopción empezó con una entrega pequeña
La empresa evitó imponer el sistema completo a todos los proyectos. Eligió una entrega recurrente, acotó tres disciplinas y midió espera, devoluciones, incidencias sin contexto y tiempo de preparación. El piloto permitió ajustar estados y mensajes antes de ampliar el alcance.
La formación no se centró solo en botones. Cada perfil entendió qué información producía, qué significaba compartir y qué ocurría después. Los responsables de proceso participaron en las reglas. El equipo técnico mantuvo configuraciones y pruebas. Así, BIM dejó de ser una obligación del departamento de modelos y pasó a ser una forma compartida de producir información.
Hubo resistencia razonable. Algunos pasos iniciales exigían más disciplina que enviar un archivo por correo. El equipo respondió mostrando qué retrabajo evitaban y eliminando campos que nadie utilizaba. Pedir datos «por si acaso» es una excelente manera de conseguir que todos aprendan a rellenar basura con gran eficacia.
Las métricas evitaron venderse la transformación a sí mismos
Se compararon ciclos antes y después: tiempo hasta iniciar revisión, número de versiones no identificadas, devoluciones, incidencias aclaradas por mensaje y esfuerzo de publicación. También se anotaron soporte, configuración y mantenimiento. El valor no se calculó multiplicando una demostración perfecta por cien proyectos imaginarios.
La mejora más evidente fue la capacidad de conocer el estado sin convocar una investigación. Coordinación veía qué estaba compartido, qué regla bloqueaba una entrega y quién tenía la siguiente acción. El cliente podía relacionar una aprobación con un paquete concreto. Los modelos no se hicieron mágicamente mejores; el proceso dejó de esconder sus dudas.
Algunas automatizaciones se retiraron porque generaban demasiado ruido. Otras se mantuvieron como ayudas sin bloquear. Medir permitió distinguir una regla útil de una obsesión parametrizada.
Cuándo BIM añade coste sin devolver valor
No todos los encargos necesitan el mismo sistema. Si un proyecto es pequeño, tiene pocos intercambios y no reutilizará información, una estructura pesada de modelos y controles puede superar el beneficio. La decisión debe seguir usos, riesgo, número de agentes y ciclo de vida, no una obligación estética de parecer digital.
Tampoco conviene perseguir un gemelo digital si nadie mantendrá los datos después de la entrega. Un modelo conectado pierde valor cuando sensores, activos y cambios dejan de actualizarse. Antes de prometer continuidad, hay que asignar propiedad, presupuesto y proceso de mantenimiento.
La madurez importa. Si la organización aún no puede identificar versiones o responsables, añadir IA predictiva no arreglará la base. Puede resumir documentos o señalar anomalías, pero no inventar gobernanza fiable. Digitalizar desorden produce desorden consultable desde el móvil.
El modelo pasó a formar parte de una decisión
Al final del proyecto, la empresa seguía entregando planos y modelos. La diferencia era que cada paquete respondía a usos definidos, conservaba su estado y podía validarse. Los identificadores conectaban objetos con incidencias; IFC tenía un propósito verificable; el CDE guardaba decisiones y permisos; y las personas sabían dónde intervenía su criterio.
Eso es la digitalización BIM que merece el esfuerzo. No medir el progreso en gigabytes ni cambiar un dibujo por una vista 3D, sino diseñar cómo nace, se comprueba, se comparte y se mantiene la información. Empieza por una decisión real del proyecto, define qué datos necesita y prueba el recorrido completo con una entrega pequeña.
Si para saber cuál es la versión aprobada todavía tienes que preguntar en el grupo, no pasa nada: ya has encontrado el siguiente proceso que digitalizar. El modelo puede esperar un momento; el correo lleva años esperándonos.
Respuestas