Coordinación BIM automatizada: del choque a la decisión

La máquina encontró ochocientas interferencias durante la noche. Por la mañana, seis personas buscan la versión correcta, una captura y alguien que sepa qué significa «revisar». Hemos automatizado la producción de preguntas y dejado intacto el trabajo de responderlas. Una distribución del esfuerzo muy ambiciosa. La coordinación mejora cuando los resultados permiten tomar una decisión y comprobarla después; contar más choques no concede ese resultado por acumulación.

La coordinación BIM automatizada merece evaluarse por el recorrido que acorta entre un problema y una decisión verificable. Para explicarlo, pensemos en un caso hipotético de coordinación entre arquitectura, estructura e instalaciones. Seguiremos un conducto que atraviesa una viga, desde la recepción de los modelos hasta la comprobación de la solución. El ejemplo permite ver qué tareas puede preparar un sistema y qué decisiones siguen necesitando criterio y responsabilidad técnica.

Recibir una entrega que permita comparar resultados

Antes de buscar una interferencia hay que saber qué estamos comparando. En nuestro ejemplo, el conducto pertenece a una entrega de instalaciones y la viga a una entrega de estructura. Si una de ellas es anterior a la revisión prevista, el resultado puede describir un conflicto que ya no existe o pasar por alto uno nuevo. Automatizar la comprobación de archivos presentes, identificadores de versión y estados de entrega suele aportar más valor inicial que añadir otra regla geométrica. La primera materia prima de una coordinación fiable es saber qué ha entrado.

Propondría registrar un paquete de revisión: modelos incluidos, disciplina, versión y propósito de la comprobación. La referencia debe permitir volver a ese conjunto, aunque después se publiquen otros archivos. También conviene comprobar las condiciones acordadas para combinarlo: posición, unidades cuando corresponda y configuración de intercambio. Si falta instalaciones, el sistema podría permitir una revisión parcial de arquitectura y estructura, pero debería identificarla como parcial. Que no aparezca el conducto no equivale a haberle encontrado una solución especialmente elegante.

Para algunas comprobaciones de información sobre IFC, IDS de buildingSMART permite expresar requisitos de forma interpretable por software. Puede ayudar a verificar datos que el proyecto necesita para sus reglas. No reemplaza el acuerdo sobre qué se entrega ni convierte una comprobación de propiedades en detección de interferencias. Cada control debe explicar qué verifica y con qué resultado. Recibir un modelo con información suficiente y decidir si su diseño es adecuado son preguntas relacionadas, pero diferentes.

Una recepción automatizada debería producir un estado comprensible: conjunto preparado, preparado con limitaciones o bloqueado por una condición concreta. El coordinador necesita saber qué falta y qué revisión sigue siendo posible. Eso permite corregir la entrada antes de generar un informe que otros tomarán como completo. También evita celebrar una caída espectacular en el número de choques cuando la causa es que una disciplina se quedó fuera. Los indicadores verdes no suelen investigar de oficio por qué les ha ido tan bien.

Convertir las reglas en preguntas que conduzcan a una acción

Una regla útil necesita describir qué elementos compara y por qué importa el resultado. Para el conducto y la viga, podríamos empezar por una comprobación geométrica de intersección en las disciplinas y fase previstas. Habría que definir exclusiones, tolerancias y tratamiento de geometría auxiliar. Copiar la misma tolerancia para todo el edificio simplifica la configuración, pero puede confundir condiciones que necesitan interpretaciones distintas. Un roce entre acabados y una invasión de un elemento estructural no deberían recibir automáticamente la misma prioridad.

Además, no todo lo que importa es una intersección. Un equipo puede necesitar un espacio de mantenimiento que no está representado como un sólido físico; una bandeja puede pasar sin chocar y dejar una instalación inaccesible. La condición debe poder formularse con la información disponible. Si necesitamos una zona de reserva, hay que acordar cómo representarla o calcularla. Introducir «accesibilidad» en el nombre de la regla no hace que una comprobación geométrica entienda por sí sola cómo se utilizará el edificio.

La regla debería anticipar también quién revisará el resultado y qué decisiones puede provocar. Detectar el conducto contra la viga no decide si se cambia el trazado, se revisa un hueco previsto o se estudia otra solución estructural. El sistema puede reunir evidencia y proponer una clasificación inicial. La resolución necesita al responsable técnico que corresponda y, en ocasiones, una decisión entre varias disciplinas. La automatización se vuelve útil cuando reduce el trabajo previo a esa conversación, sin presentar una elección de diseño como consecuencia inevitable de una intersección.

Para comprobar una regla, prepararía ejemplos con resultado esperado: un conflicto claro, un encuentro permitido y un caso límite. Guardaría la versión de la configuración junto con la ejecución. Si más adelante cambiamos la tolerancia para reducir ruido, podremos observar qué casos dejamos de señalar. No basta con contar cuántos avisos han desaparecido. Reducir el volumen por cansancio puede resultar comprensible un viernes; como política permanente, corre el riesgo de automatizar precisamente la ceguera que queríamos corregir.

Transformar resultados en incidencias con contexto

Una ejecución puede producir muchos resultados para una misma decisión. Varios tramos de conducto y sus accesorios podrían señalar repetidamente el paso por la misma zona estructural. Enviar cada par como una incidencia independiente multiplica asignaciones y comentarios sin multiplicar necesariamente los problemas. Una agrupación por entorno, elementos y regla puede ayudar, siempre que se trate como propuesta revisable. Dos conflictos cercanos también pueden tener causas distintas. La proximidad organiza candidatos; no firma una conclusión técnica.

Antes de asignar, el coordinador debería poder distinguir un resultado que requiere corrección, uno que necesita información y uno que no representa un problema para ese uso. Esta revisión inicial suele llamarse triage: ordenar y decidir qué atención necesita cada caso. Registrar el motivo de descarte ayuda a mejorar la regla después. Si cada semana descartamos el mismo tipo de encuentro, hay una decisión del sistema pendiente de ajustar. Mantenerlo indefinidamente porque «el software lo detecta» convierte la revisión humana en un accesorio de limpieza.

La incidencia sobre nuestro conducto debería conservar modelos y versiones, elementos implicados, regla, descripción y una vista suficiente para entender el entorno. BCF API de buildingSMART ofrece un marco de intercambio de temas, comentarios y puntos de vista, con referencias a componentes. Si utilizamos herramientas distintas, conviene probar que el contexto llegue al destino previsto y que las referencias se puedan resolver. Una exportación correcta en el origen no demuestra por sí sola que la persona responsable pueda retomar el caso en su aplicación.

La asignación necesita responder a quién debe realizar la siguiente acción, no simplemente a qué disciplina contiene el objeto más fácil de mover. El modelador de instalaciones puede estudiar un trazado, pero quizá necesite una decisión de estructura o una aclaración de arquitectura antes de modificarlo. La incidencia debería reflejar ese bloqueo y el acuerdo alcanzado. Si la matriz propone un responsable automáticamente, debe permitir una revisión con rastro de la decisión. La eficiencia no mejora enviando muy deprisa una pregunta a alguien que no puede resolverla.

Los avisos también deberían seguir ese contexto. Una incidencia pendiente de comprobar tras una nueva entrega requiere una acción distinta de otra a la espera del cliente. Enviar el mismo recordatorio a todas las personas cada mañana convierte una señal en ruido y enseña a ignorarla. Conviene dirigir cada aviso a quien puede actuar, explicar qué cambió y agrupar cuando ayude. El correo no adquiere capacidad de coordinación por repetirse con una puntualidad impecable.

Comprobar la solución y conservar la historia del problema

Supongamos que instalaciones modifica el trazado y responde «corregido». Ese comentario expresa una acción declarada; para cerrar el conflicto habrá que revisar la nueva entrega en el conjunto que corresponda. El sistema puede volver a ejecutar la regla y relacionar el resultado con la incidencia anterior. Si el encuentro ya no aparece, habrá una evidencia para proponer el cierre. Aun así, pueden quedar condiciones fuera del alcance de esa regla, como el espacio necesario para mantenimiento o las consecuencias de desplazar el conducto hacia otra zona.

También hay resultados que desaparecen por motivos ajenos a la solución. El objeto puede haberse eliminado, cambiar de referencia o quedar fuera del conjunto revisado. Por eso conviene conservar qué se comprobó y distinguir ausencia de resultado, referencia no localizada y condición satisfecha. Cerrar automáticamente todo lo que no aparece en una ejecución nueva produciría una bandeja muy limpia. La coordinación necesita una limpieza algo más exigente: poder explicar por qué se considera atendido cada caso.

La comparación entre versiones requiere comprobar la persistencia de los identificadores disponibles y tratar las ambigüedades. No se debería vincular un conflicto nuevo a uno antiguo solo porque comparte una zona aproximada. Puede ser una ayuda para localizar candidatos, con confirmación cuando haga falta. Mantener la historia permite conocer propuestas anteriores, decisiones aceptadas y reincidencias. Reiniciar la lista cada semana elimina parte del trabajo de comparación y, de paso, casi toda la memoria que justificaba registrar incidencias.

Una excepción aceptada necesita motivo, alcance, responsable y, cuando corresponda, condición de revisión. Una reserva provisional en una fase temprana no tiene por qué seguir siendo aceptable en ejecución. Conservar el contexto permite distinguir una solución de una aceptación temporal y evitar que los dos estados terminen bajo el mismo «cerrado». La herramienta puede organizar ese registro. La responsabilidad de aceptar una condición técnica pertenece a quienes estén autorizados para hacerlo dentro del proyecto.

Con ese circuito, la reunión puede centrarse en decisiones bloqueadas o que afectan a varias disciplinas, mientras las correcciones ordinarias siguen su recorrido fuera de ella. No hay una promesa de eliminar desacuerdos ni de acortar todas las sesiones. A veces el edificio presenta una dificultad real que merece tiempo. Lo que sí podemos evitar es consumir ese tiempo en reconstruir el conjunto de archivos o buscar la captura que daba sentido a la pregunta.

Medir si la automatización está quitando trabajo o repartiéndolo

El número bruto de interferencias no permite evaluar por sí solo la coordinación. Cambia con el tamaño del modelo, las reglas y el conjunto de revisión. Resulta más informativo observar cuánto tarda un resultado en recibir atención, cuánto tiempo permanece bloqueado y cuántas incidencias vuelven a abrirse. También interesa qué proporción se descarta y por qué. Ninguna cifra cuenta toda la historia, pero juntas ayudan a localizar si el esfuerzo se concentra en problemas reales o en administrar la salida del sistema.

Para un primer alcance, mediría especialmente cuántos casos llegan con contexto suficiente para actuar. Si la persona asignada tiene que pedir archivo, planta y versión en cada comentario, todavía hay trabajo mecánico que preparar mejor. Podríamos revisar una muestra de incidencias y anotar las aclaraciones necesarias, sin inventar una precisión estadística que la muestra no permite. El objetivo es aprender qué falta en el recorrido y comprobar si la siguiente mejora reduce esa dificultad.

El mantenimiento de reglas y conexiones necesita un responsable. Cambian los modelos, las convenciones y las necesidades de fase; una configuración útil puede dejar de serlo. Los casos conocidos que el sistema no detecta son tan importantes como los falsos positivos que sí vemos. Revisarlos permite decidir qué nueva condición merece automatizarse y cuál seguirá necesitando inspección humana. Un panel que solo mide sus propios aciertos corre el riesgo de parecer extraordinariamente satisfecho consigo mismo.

Empezaría con recepción de versiones, unas pocas reglas que conduzcan a acciones y un circuito claro de verificación. En proyectos pequeños puede bastar un proceso más sencillo; en otros, la repetición y el volumen justificarán más integración. El criterio es si el equipo dedica menos esfuerzo a perseguir contexto y más a resolver el edificio. Una automatización que desplaza las horas desde modelar hasta limpiar informes necesita revisión, aunque técnicamente se ejecute sin errores.

Acuerda qué convierte un resultado en una incidencia útil y qué evidencia permite cerrarla. Después automatiza la preparación y la comprobación que puedas repetir con criterio. Si la reunión sigue empezando por localizar de qué versión habla el informe, no necesita otra exportación masiva. Necesita que la anterior aprenda a identificarse antes de pedir la palabra.