Automatización BIM: qué cambia cuando el flujo trabaja por ti
El jueves a última hora, el equipo BIM prepara una entrega. La geometría está razonablemente bien, los modelos se han sincronizado y nadie recuerda haber visto un error grave. Aun así, la publicación no empieza con una comprobación, sino con una ronda de mensajes: quién ha rellenado los parámetros, qué vínculo falta por actualizar, si el archivo de estructuras es el definitivo y quién se atreve a pulsar el botón. La escena resulta familiar porque el problema no está en Revit. Está en un flujo que solo existe dentro de la cabeza de varias personas.
Automatizar ese trabajo no consiste en fabricar un botón enorme con la palabra «ENTREGA» y confiar en la providencia digital. Consiste en convertir decisiones repetidas en reglas visibles, separar lo que una máquina puede comprobar de lo que todavía necesita criterio y dejar rastro de cada resultado. Cuando eso ocurre, el flujo empieza a trabajar para el equipo. No porque piense por él, sino porque deja de exigirle memoria para hacer siempre lo mismo.
Tabla de contenidos
El cuello de botella llevaba corbata de reunión
En nuestro caso, la publicación semanal reunía arquitectura, estructuras e instalaciones. Cada disciplina debía actualizar sus vínculos, completar un conjunto de parámetros, revisar vistas, exportar IFC y dejar los archivos en una carpeta común. El procedimiento estaba escrito, pero la práctica dependía de una coordinadora que preguntaba, recordaba y reconstruía el estado real a base de respuestas en Teams. Había un protocolo; lo que faltaba era un sistema.
La primera tentación fue automatizar las exportaciones. Es una tarea visible y agradecida: pulsas un botón, aparecen varios archivos y durante unos minutos todo parece estar bajo control. Sin embargo, una exportación rápida de un modelo incompleto solo produce un error con puntualidad británica. Antes de tocar Dynamo, Python o la API de Revit, el equipo dibujó el proceso desde que una disciplina decía «he terminado» hasta que el paquete se consideraba publicable.
Ese dibujo mostró cuatro tipos de trabajo. Había comprobaciones mecánicas, como detectar parámetros vacíos o vínculos descargados; decisiones técnicas, como aceptar una excepción justificada; acciones sobre archivos, como exportar y nombrar; y coordinación, es decir, saber quién debía intervenir cuando algo fallaba. La automatización BIM podía asumir buena parte del primer y tercer grupo. El segundo seguía necesitando una persona. El cuarto no desaparecía, pero podía dejar de depender de la persecución manual.
Este matiz cambia el proyecto. Si automatizas una tarea aislada, ahorras clics. Si automatizas estados, controles y transiciones, reduces incertidumbre. Los clics molestan; la incertidumbre cuesta entregas.
El flujo empezó por leer, no por corregir
La primera versión del sistema no modificaba ningún modelo. Abría una copia controlada, comprobaba que los vínculos esperados estuvieran presentes, recorría las categorías acordadas y revisaba los parámetros necesarios para la entrega. Después generaba un informe con tres estados sencillos: correcto, advertencia y bloqueo. Puede parecer poco ambicioso, pero leer antes de escribir es una de las mejores costumbres que puede adquirir una automatización. También las personas, aunque eso ya requeriría otra API.
Los controles se definieron con ejemplos. «Todos los elementos deben tener código» era demasiado vago: ¿todos incluye líneas de detalle, masas o piezas provisionales? «Los muros, puertas, ventanas y equipos mecánicos incluidos en el intercambio deben tener el parámetro Código_Activo informado» sí se podía convertir en una regla. Para cada requisito se acordaron alcance, condición, severidad y responsable. El script no inventaba el criterio; ejecutaba un criterio que el equipo había conseguido explicar.
El informe también guardaba contexto. No bastaba con indicar que faltaban 126 valores. Incluía modelo, categoría, identificador del elemento, regla incumplida y momento de la comprobación. En Revit, un resultado útil debe permitir volver al objeto. En IFC ocurre lo mismo: si conservas el identificador estable y la propiedad evaluada, una incidencia puede rastrearse; si entregas una captura y un «esto está mal», has automatizado la fabricación de acertijos.
Durante dos semanas, la coordinadora comparó el informe con su revisión habitual. Aparecieron falsos positivos, categorías que no debían entrar y una regla que trataba como error lo que en fase de anteproyecto era una excepción perfectamente razonable. Aquellas discrepancias no demostraban que la automatización hubiese fallado. Demostraban que el proceso contenía decisiones tácitas que nunca se habían documentado.
Los estados sustituyeron al «creo que ya está»
Una vez afinados los controles, cada modelo dejó de estar simplemente «hecho» o «no hecho». El flujo distinguía preparado, en validación, bloqueado, aprobado con excepciones y publicado. El cambio parece administrativo, pero evita una confusión frecuente: terminar de modelar no equivale a estar listo para compartir. Un modelo puede tener toda su geometría y seguir bloqueado por un vínculo incorrecto, una clasificación incompleta o una configuración de exportación equivocada.
Al pasar a validación, el sistema ejecutaba las reglas y adjuntaba el informe. Si encontraba un bloqueo, no lanzaba la exportación y asignaba la incidencia al responsable de la disciplina. Si solo había advertencias, permitía solicitar una excepción. Esa excepción necesitaba motivo, persona que la aceptaba y vigencia. De ese modo, «lo sabemos, ya se corregirá» dejó de ser una frase que se evapora al cerrar la reunión y pasó a ser una decisión trazable.
La trazabilidad no se añadió para buscar culpables. Se añadió para poder entender el paquete publicado dentro de tres meses. Qué versión de cada modelo intervino, qué reglas se ejecutaron, qué advertencias se aceptaron y con qué configuración se generaron los IFC. Cuando una automatización produce archivos sin registrar esas respuestas, solo acelera el misterio.
La exportación llegó cuando ya no era el problema principal
Solo entonces se automatizaron los archivos de salida. La rutina elegía las vistas o conjuntos acordados, aplicaba una configuración versionada y construía los nombres a partir de datos del proyecto. Antes de escribir nada, mostraba una vista previa: modelos incluidos, destino, nombres resultantes y posibles sustituciones. Después generaba el paquete en una ubicación temporal, comprobaba que los archivos existieran y movía el conjunto completo a su destino final.
Esta secuencia evitaba dejar una entrega a medias si una disciplina fallaba. También permitía distinguir entre validar el modelo y validar el resultado. Un IFC puede generarse sin errores y, aun así, perder propiedades, clasificaciones o coordenadas relevantes. Por eso el flujo hacía una segunda comprobación sobre los archivos exportados: presencia de los modelos previstos, estructura básica, identificadores y un pequeño conjunto de propiedades críticas. La sintaxis correcta es necesaria; el cumplimiento del propósito es otra conversación.
El equipo mantuvo la posibilidad de ejecutar manualmente cada etapa. Automatizar no debería convertir una incidencia ordinaria en una ceremonia de recuperación. Si fallaba el servicio que movía archivos, era posible exportar con la misma configuración y registrar el resultado. La ruta manual no era un atajo secreto, sino una contingencia documentada. Un flujo robusto sabe trabajar bien y también sabe fallar con educación.
Las excepciones dejaron de esconderse en el proceso
Al tercer ciclo apareció un modelo recibido de un colaborador externo con una clasificación distinta. La regla lo bloqueó, aunque la entrega necesitaba incluirlo. Antes, la solución habría sido desactivar el control o corregir el archivo a toda prisa. El nuevo flujo permitió aceptar una excepción limitada a ese modelo y a esa publicación, con una nota que explicaba el motivo y una tarea posterior para normalizarlo.
Esa diferencia es importante. Saltarse una regla borra el problema; gestionar una excepción reconoce que el problema existe, limita su alcance y asigna la decisión. La automatización no elimina situaciones ambiguas. Las obliga a salir de debajo de la alfombra, donde suelen vivir cómodamente junto a varias familias de Revit llamadas «Copia 2 definitiva».
También se definieron límites. El sistema podía señalar una incoherencia entre la fase del elemento y la vista de entrega, pero no decidir por sí solo cuál representaba mejor la intención del proyecto. Podía comparar áreas o detectar valores atípicos, no reinterpretar una exigencia normativa. Incluso una IA capaz de proponer anomalías seguía funcionando como asistente: presentaba indicios; el responsable técnico confirmaba la decisión.
Medir el cambio sin inventarse una película de éxito
El equipo quería saber si el trabajo había merecido la pena, pero evitó convertir cada minuto ahorrado en una cifra anual con dos decimales. Midió variables observables durante varios ciclos: tiempo empleado en preparar la entrega, número de interrupciones a la coordinadora, bloqueos encontrados antes de exportar, paquetes repetidos y excepciones abiertas. También registró el mantenimiento del propio sistema, porque los scripts no se alimentan de luz solar.
El beneficio más claro no fue que Revit exportara más deprisa. Fue que a media mañana todos podían ver qué impedía publicar y quién tenía la siguiente acción. Las conversaciones cambiaron de «¿cómo vamos?» a «hay dos bloqueos concretos en instalaciones». Esa visibilidad redujo esperas y evitó revisar varias veces modelos que todavía no estaban preparados.
No todas las reglas sobrevivieron. Una comprobación generaba tantos avisos poco relevantes que el equipo dejó de atenderla. Se simplificó y, cuando siguió sin aportar decisiones, se retiró. Mantener controles ruidosos para presumir de cobertura es una manera bastante sofisticada de reconstruir el caos original.
Qué hace falta para que el flujo siga trabajando mañana
La automatización pasó a tener propietario, versiones y un pequeño registro de cambios. Cada actualización de Revit o modificación del BEP activaba pruebas con modelos conocidos. Las reglas críticas tenían casos correctos, incorrectos y ambiguos. La configuración no vivía incrustada en un grafo imposible de leer, sino separada del código cuando necesitaba cambiar por proyecto.
También se documentó quién podía modificar las reglas, quién aceptaba excepciones y cómo se recuperaba una publicación fallida. Esa gobernanza puede parecer menos emocionante que enseñar un dashboard, pero es lo que diferencia una demostración de una herramienta de producción. Si una persona se marcha de vacaciones y el flujo deja de entenderse, no estaba automatizado: estaba domesticado por su creador.
La elección tecnológica quedó subordinada al problema. Dynamo resultaba útil para prototipar controles cercanos al modelo y hacer visible la lógica. Python facilitaba organizar reglas, generar informes y conectar varias etapas. La API de Revit ofrecía más control cuando había que construir una herramienta estable integrada en la oficina. Ninguna opción era «la buena» por sí sola. La buena era la que el equipo podía probar, mantener y ejecutar con los permisos adecuados.
Automatizar BIM es diseñar una forma más explícita de trabajar
Al cabo de varios ciclos, la entrega seguía necesitando criterio profesional. Arquitectura continuaba decidiendo qué excepciones eran aceptables y coordinación seguía respondiendo por el paquete final. Lo que había desaparecido era buena parte del trabajo de recordar, preguntar, recopilar y repetir comprobaciones. El flujo no sustituyó al equipo; le devolvió atención.
Ese es el cambio que merece perseguir la automatización BIM. No una colección de botones espectaculares, sino un proceso donde las reglas se entienden, los estados son visibles, los resultados se pueden comprobar y los fallos conducen a una acción concreta. Empieza por un cuello de botella real, automatiza primero la lectura, deja las decisiones delicadas bajo control humano y mide también el coste de mantener la solución.
Cuando el sistema consigue que una entrega deje de depender de la memoria heroica de una coordinadora, ya está haciendo algo valioso. Si además exporta los IFC mientras el equipo toma café, estupendo. Pero no confundamos el efecto especial con la película.
Respuestas