Automatización BIM: qué cambia cuando el flujo trabaja por ti
El botón exporta veinte archivos en un instante. Tres proceden de la versión equivocada y dos no contienen los datos de coordinación, pero nadie puede negar la velocidad. La demostración había prometido precisamente eso: hacerlo deprisa. Vamos a incorporar la extravagante exigencia de hacerlo bien. Una automatización BIM útil necesita alcance, referencias y una forma de explicar las excepciones; de lo contrario, solo consigue que el problema llegue antes a más gente.
La automatización BIM empieza a ser útil cuando permite repetir un trabajo con entradas conocidas, reglas comprensibles y resultados que se pueden comprobar. Vamos a diseñar un ejemplo hipotético: una entrega semanal de arquitectura, estructuras e instalaciones que hoy depende de perseguir respuestas por mensajería. El objetivo es que cada persona pueda ver qué falta, por qué falta y qué debe ocurrir después. Exportar mientras tomas café puede llegar al final; primero vamos a evitar que ese café acompañe una entrega incorrecta.
Tabla de contenidos
Encuentra el atasco antes de fabricar el botón
Imagina que el viernes por la mañana una coordinadora tiene que reunir los modelos, comprobar sus versiones, pedir que se rellenen datos y preparar los archivos de intercambio. Si solo observas el tiempo que tarda la exportación, parece evidente qué automatizar. Pero quizá la exportación consume quince minutos y la espera de una confirmación consume dos días. Ahorrar diez minutos en el tramo que ya funciona puede ser agradable sin cambiar la fecha de la entrega.
Recorre un paquete desde que una disciplina dice «he terminado» hasta que otra persona puede utilizarlo. Anota qué entra en cada paso, quién actúa, qué comprueba y qué necesita para continuar. Después distingue trabajo efectivo de espera: descargar y revisar un archivo es una actividad; esperar a que alguien aclare si ese archivo es válido es otra cosa. Si las mezclas, terminarás encargando al desarrollador que acelere Revit cuando el cuello de botella está en un acuerdo que nadie ha definido.
En este ejemplo encontraríamos tareas mecánicas, como comprobar códigos vacíos; decisiones técnicas, como aceptar una excepción; operaciones de salida, como exportar; y coordinación, como asignar la devolución a una disciplina. Esa separación ayuda a decidir qué delegar al sistema. Una regla puede detectar un dato ausente y dirigir el resultado al responsable. No por eso puede decidir qué valor representa la intención del proyecto. Son capacidades distintas, aunque el botón tenga sitio para prometer las dos.
Escoge un primer tramo con principio y final observables. Por ejemplo: recibir una revisión identificada, comprobar tres requisitos acordados y devolver un informe con elementos localizables. Hay una entrada, un resultado y alguien que puede valorar si el trabajo sirve. «Automatizar el BIM de la oficina» todavía no tiene ninguna de esas tres cosas, pero quedará excelente en una diapositiva acompañada de engranajes.
Si tu proceso necesita aclararse antes de poder dibujarlo, ese trabajo también forma parte del proyecto. Programar una ambigüedad no la resuelve: obliga al código a elegir una interpretación que quizá nadie haya aceptado. Me parece una forma innecesariamente cara de descubrir que las personas no estaban hablando de lo mismo.
Empieza con una comprobación que permita actuar
La primera versión del ejemplo trabajaría en lectura. Recibiría las versiones seleccionadas, revisaría el ámbito acordado y produciría un informe sin modificar el modelo. Así puedes discutir la interpretación de las reglas antes de autorizar cambios. También puedes compararla con una revisión de muestra y descubrir si el comprobador entiende «equipos de esta entrega» como lo entiende la persona responsable.
Una regla necesita algo más que «todos los elementos deben tener código». Tendrías que indicar qué modelos y categorías entran, qué fases o situaciones se excluyen, qué dato se consulta y qué condición debe cumplir. Podríamos pedir, por ejemplo, un código de activo para los equipos mecánicos incluidos en un intercambio concreto, admitiendo una excepción explícita para equipos provisionales. No estamos proponiendo ese requisito para cualquier proyecto: lo estamos usando para mostrar cuántas decisiones escondía la palabra «todos».
El resultado debería separar al menos lo que cumple, lo que incumple y lo que no se ha podido evaluar. Un parámetro vacío y un archivo que no se ha podido abrir requieren respuestas diferentes. Si el sistema cuenta ambos como «sin errores detectados», la pantalla verde estará ofreciendo una tranquilidad bastante imaginativa. Cada resultado necesita la referencia del modelo y su versión, la regla aplicada, el elemento afectado cuando exista y una explicación del dato observado.
Antes de bloquear entregas, prueba casos conocidos: un equipo con código correcto, otro sin código, uno fuera de alcance y un modelo que no esté disponible. Comprueba tanto el resultado como la acción siguiente. ¿El responsable puede encontrar el elemento? ¿Entiende qué debe corregir? ¿Puede distinguir un fallo de su modelo de un fallo del servicio? Automatizar la generación de un informe que exige otra reunión para interpretarse tiene un ahorro muy discutible.
El IFC exportado merece un control separado del archivo de autoría. Las especificaciones de IFC de buildingSMART describen el esquema de intercambio; los requisitos del proyecto determinan qué necesitas conservar dentro de él. Que el exportador termine no demuestra que las propiedades, identificadores y relaciones relevantes hayan llegado al receptor. Incluye una muestra conocida en la prueba y revisa lo que existe en el archivo de salida, no solo lo que había en Revit antes de pulsar exportar.
Convierte las respuestas en estados y decisiones visibles
Cuando la comprobación sea suficientemente fiable para el alcance elegido, puedes conectarla con el flujo de entrega. Una secuencia posible sería preparado, en validación, bloqueado, pendiente de aceptación y publicado. Es una propuesta para este ejemplo, no una nomenclatura universal. Lo que importa es que cada estado tenga un significado, un responsable y unas condiciones de salida; poner cinco etiquetas nuevas al mismo «creo que ya está» no mejora gran cosa.
Supongamos que instalaciones comparte su revisión y la regla encuentra equipos sin código. El paquete queda bloqueado para ese uso y devuelve el listado a la disciplina. Si la revisión llega sin los modelos necesarios, la validación debería quedar incompleta, no aprobada. Si las reglas terminan y solo hay advertencias aceptables, la persona autorizada podría revisar una excepción. El sistema prepara la evidencia y controla el recorrido; la decisión conserva su autor.
Una excepción útil identifica el modelo, la versión, la condición que se acepta, el motivo y hasta cuándo o para qué entrega vale. Si permites «ignorar este aviso para siempre», quizá estés creando una segunda norma que solo conocen quienes encontraron la casilla. En el caso hipotético, un colaborador podría aportar una clasificación distinta: aceptarla para una coordinación concreta no implica aceptarla también para la entrega de activos que vendrá después.
Es aquí donde los permisos dejan de ser un detalle de administración. Una persona puede corregir datos y subir una revisión sin tener autoridad para aceptar una desviación. Otra puede consultar el informe sin modificar las reglas. La guía del UK BIM Framework sobre CDE sirve para profundizar en el vínculo entre los estados de la información y su flujo. Nuestra automatización debe encajar en ese proceso, no inventar una aprobación paralela porque el script ya tiene credenciales.
Conserva las decisiones junto al paquete y sus versiones. Si alguien pregunta meses después por qué se publicó una revisión con una advertencia, deberías poder mostrar la regla utilizada y la aceptación correspondiente. No se trata de coleccionar nombres para una futura caza de culpables. Se trata de que una entrega siga siendo comprensible cuando ya nadie recuerde qué se habló en aquella reunión tan productiva que, naturalmente, no dejó acta.
Publica un resultado comprobado y prepara la recuperación
Solo después incorporaría la creación del paquete. Antes de ejecutar, muestra qué modelos se van a usar, qué archivos se producirán y dónde terminarán. Si hay riesgo de sustituir una entrega existente, esa consecuencia debe ser explícita y requerir la autorización que corresponda. Una vista previa útil permite detectar una selección equivocada; una barra de progreso solo permite contemplar cómo se materializa.
La salida puede prepararse en una ubicación temporal para evitar presentar como completa una entrega que todavía está generándose. Después se comprueba que están los archivos esperados y que se pueden evaluar las condiciones mínimas del intercambio. La forma de promover ese paquete al destino final depende del almacenamiento: no debes asumir que mover varios archivos entre sistemas constituye una operación indivisible. Puedes utilizar un manifiesto y un estado de publicación que solo se complete cuando todas las piezas estén confirmadas.
Ese manifiesto podría relacionar cada modelo de entrada con sus salidas, la configuración de exportación, las reglas y el resultado de las comprobaciones. Si estructuras falla, el informe tiene que decir qué se ha generado y qué falta. No debería anunciar «entrega publicada» solo porque arquitectura acabó bien. La honestidad del estado es parte del producto; ahorra más investigaciones que una animación especialmente convincente.
Piensa también en una repetición. Si la conexión se corta después de enviar el paquete pero antes de recibir la confirmación, volver a pulsar podría crear duplicados o sustituir algo correcto. El sistema necesita una forma de reconocer el intento y consultar su estado antes de repetir efectos. No todos los destinos ofrecen las mismas garantías; por eso hay que diseñar y probar la recuperación para el servicio concreto, en lugar de confiar en un segundo clic terapéutico.
Mantén una contingencia manual documentada: qué puede ejecutar una persona, con qué configuración, cómo comprueba la salida y dónde registra el resultado. La ruta manual no debe borrar los controles ni convertirse en un privilegio secreto del autor del script. Debe permitir continuar una entrega bajo responsabilidad conocida cuando falle una dependencia. Automatizar puede reducir trabajo repetido; no debería convertir una caída de servicio en una prohibición de trabajar.
Elige una herramienta que puedas mantener después de la demo
Para prototipar comprobaciones dentro del entorno de modelado, Dynamo puede ayudar a hacer visible la secuencia de datos y operaciones. Python permite organizar lógica, tratar archivos y generar informes, pero usarlo no implica por sí solo que pueda modificar Revit desde cualquier proceso. Cuando necesites acceso al modelo, tendrás que respetar el contexto de ejecución de la API y las operaciones que permita la integración elegida. El lenguaje no expide permisos mágicos.
Un complemento con la API de Revit puede ofrecer una interfaz más controlada para un flujo recurrente dentro de la aplicación. Un servicio externo puede coordinar trabajos, recibir resultados o consultar una plataforma mediante su API. Son piezas que pueden combinarse, no una competición en la que gana automáticamente la más compleja. Elige según dónde vive la información, quién ejecutará el proceso y qué podrá mantener el equipo cuando cambien las versiones.
Antes de ampliar el piloto, decide quién es propietario de las reglas y quién de la herramienta. Separa la configuración que varía por proyecto de la lógica que debería comportarse igual. Conserva versiones y casos de prueba que incluyan fallos, exclusiones y recuperación. Una actualización de Revit, del exportador o del requisito puede cambiar el resultado aunque tu código no haya recibido una sola línea nueva. «Ayer funcionaba» describe una observación; como estrategia de mantenimiento se queda algo corta.
Mide el recorrido completo durante ciclos comparables: tiempo efectivo de preparación, espera hasta poder revisar, devoluciones por datos incompletos y esfuerzo de soporte. Cuenta también las falsas alarmas y las excepciones. Si una regla genera avisos que nadie atiende, revisa su alcance, su severidad o su utilidad. Conservarla para presumir de cobertura puede acostumbrar al equipo a ignorar precisamente la pantalla que algún día mostrará un problema serio.
El primer recorrido debería permitir saber qué impide entregar y quién tiene la siguiente acción, sin reconstruirlo a base de mensajes. Pruébalo con una excepción antes de ampliar el flujo. Un botón que se detiene y explica el motivo puede aportar más que otro que termina siempre. Ese segundo tipo también sabe producir resultados incorrectos con una puntualidad excelente.
Respuestas