Coordinación BIM automatizada: menos persecución, más decisiones
La reunión de coordinación empezaba a las nueve, pero las decisiones solían aparecer cerca de las diez. La primera hora se consumía averiguando qué modelos eran los últimos, buscando la captura mencionada en un correo y preguntando quién debía responder a una incidencia que llevaba tres semanas cambiando de color. El equipo tenía modelos federados, una plataforma de incidencias y un informe automático de interferencias. También tenía la sensación de coordinar el proyecto con una cuchara.
La coordinación BIM automatizada no consiste en encontrar más choques. Consiste en preparar información fiable para que las personas decidan antes: recibir versiones identificadas, ejecutar reglas útiles, agrupar resultados, conservar el contexto y dirigir cada incidencia hacia quien puede resolverla. La automatización reduce persecución y trabajo mecánico; la responsabilidad técnica no cabe en un botón, por muy redondo que sea.
Tabla de contenidos
La reunión reveló que el atasco estaba antes de la reunión
El coordinador federaba arquitectura, estructuras e instalaciones la tarde anterior. A veces un modelo conservaba el nombre de la semana pasada, aunque su contenido hubiese cambiado. Otras veces el vínculo estaba actualizado en Revit, pero el IFC publicado procedía de una configuración anterior. Antes de analizar geometría, había que reconstruir el paquete.
El equipo empezó definiendo una recepción verificable. Cada modelo llegaba con disciplina, versión, estado y propósito. El flujo comprobaba que estuvieran los archivos esperados, que las coordenadas coincidieran con la referencia acordada y que la configuración de intercambio fuese la prevista. Si faltaba una disciplina, la federación podía ejecutarse para trabajo interno, pero no presentarse como revisión completa.
Este detalle evitó comparar resultados incomparables. Una disminución de interferencias podía significar que el proyecto había mejorado o que faltaba el modelo de climatización. Los dashboards tienen cierta tendencia a celebrar ambas cosas con el mismo verde.
Las reglas empezaron por las decisiones que podían provocar
La matriz de coordinación original contenía muchas combinaciones de categorías y una tolerancia general. Generaba centenares de resultados: conductos contra vigas, bandejas junto a falsos techos, tuberías tocando aislamientos y elementos provisionales que nadie pensaba construir. Revisarlo todo parecía exhaustivo, pero retrasaba los conflictos importantes.
Para cada regla se definieron disciplinas, categorías, fase, tolerancia, severidad y responsable de triage. Un encuentro entre una bajante y una viga principal no tenía el mismo tratamiento que una proximidad entre aislamiento y acabado. Tampoco todas las distancias podían evaluarse como choque geométrico: algunas exigían espacio de mantenimiento o accesibilidad.
Las reglas automáticas se reservaron para condiciones suficientemente estables. El sistema podía calcular intersecciones, distancias y propiedades. No podía decidir por sí solo si era preferible desplazar una viga, modificar un trazado o aceptar una reserva. Ese trabajo seguía en la mesa de coordinación, ahora acompañado de evidencia útil.
Detectar era solo el primer tercio del trabajo
Cada resultado debía conservar modelos y versiones, objetos implicados, regla, vista, posición y severidad propuesta. Cuando el intercambio lo permitía, se utilizaban identificadores IFC o referencias del modelo de origen. Una captura seguía siendo útil para entender el problema, pero dejaba de ser la única pista.
El flujo agrupaba resultados que describían una misma causa. Veinte tuberías atravesando el mismo muro podían corresponder a una única decisión sobre pasos de instalaciones, no a veinte conversaciones independientes. La agrupación utilizaba proximidad, objetos y regla; después una persona confirmaba el conjunto. Automatizar la propuesta ahorraba trabajo sin convertir una heurística en verdad contractual.
También se comparaban ejecuciones. Una incidencia persistente conservaba su historia, una resuelta podía cerrarse tras verificación y una nueva aparecía como tal. El equipo dejó de borrar la lista cada semana, práctica muy eficaz para obtener cero incidencias y ninguna memoria.
El triage separó ruido, coordinación y diseño
Antes de asignar, el coordinador revisaba los grupos. Algunos eran falsos positivos provocados por tolerancias o geometría auxiliar. Otros representaban problemas reales pero aún no requerían una decisión: faltaba información o el modelo no estaba preparado. Los restantes se convertían en incidencias con prioridad y fecha objetivo.
La responsabilidad se asignaba según una matriz acordada, no según quién hubiese modelado el objeto más pequeño. En un conflicto entre estructura e instalaciones, resolver podía exigir una decisión de arquitectura o del responsable de obra. El sistema proponía un propietario a partir de disciplina y regla; coordinación podía corregirlo dejando rastro.
Los estados se simplificaron: abierta, en análisis, propuesta, pendiente de validación y cerrada. «Resuelta» no significaba que alguien hubiese escrito una respuesta. Significaba que la nueva versión ya no incumplía la condición o que una decisión aceptada documentaba la excepción.
BCF permitió mover contexto sin mover modelos enteros
Para intercambios abiertos, BCF ofrecía una forma de compartir incidencias con vista, comentarios y referencias a objetos sin adjuntar otra copia del modelo. El equipo lo utilizó cuando las herramientas de autor y coordinación podían conservar el contexto necesario. No asumió que cualquier exportación e importación mantendría todos los identificadores; lo probó con el flujo y las versiones reales.
En Revit, la persona responsable podía abrir la incidencia, localizar elementos y revisar el entorno. En el federador, coordinación recuperaba el punto de vista y los modelos implicados. La incidencia dejaba de ser «el choque de la captura azul» y se convertía en un objeto trazable.
Cuando una referencia no sobrevivía al intercambio, el sistema conservaba datos auxiliares: modelo, planta, rejillas cercanas, categoría y coordenadas. La interoperabilidad útil no consiste en cumplir un formato sobre el papel, sino en que otra persona pueda retomar la decisión sin comenzar una investigación forense.
Los recordatorios siguieron el estado, no el calendario
La automatización avisaba cuando una incidencia superaba el tiempo acordado o cambiaba una versión sin recibir verificación. No enviaba el mismo correo diario a todo el proyecto. El responsable recibía las acciones que podía ejecutar; coordinación veía bloqueos y tendencias; la dirección obtenía una síntesis, no una copia de cada comentario.
Los tiempos objetivo se ajustaron a severidad y fase. Una interferencia que bloqueaba una entrega necesitaba respuesta distinta a una mejora recomendable para la semana siguiente. El objetivo no era convertir la coordinación en un centro de atención telefónica con SLA decorativos, sino hacer visibles las esperas que afectaban al trabajo.
Las escaladas también tenían límite. Si una incidencia permanecía abierta porque esperaba una decisión del cliente, repetir avisos al modelador no aceleraba nada. El estado debía representar el bloqueo real y dirigir la siguiente acción a la parte adecuada.
El cierre necesitó una comprobación nueva
Cuando una disciplina publicaba una revisión, el flujo volvía a ejecutar las reglas afectadas. Si los objetos ya no chocaban, proponía cerrar. Si la geometría había cambiado pero el requisito seguía incumplido, la incidencia permanecía abierta con el nuevo resultado. Una persona validaba los casos donde la solución alteraba el diseño o requería aceptar una condición.
Esto eliminó buena parte del «corregido» que llegaba sin evidencia. También evitó cerrar por comentario una incidencia que reaparecía en la federación. El sistema no premiaba respuestas; comprobaba condiciones.
Las excepciones se registraban con motivo, alcance, responsable y vigencia. Una reserva aceptada en anteproyecto podía necesitar revisión en ejecución. Cerrar para siempre una condición temporal habría sido cómodo, pero coordinar no consiste en conseguir una bandeja vacía.
Los falsos positivos se trataron como deuda del sistema
El equipo midió cuántos resultados se descartaban, qué reglas generaban ruido y cuánto tiempo requería el triage. Si una comprobación producía muchos avisos sin decisión, se ajustaba o retiraba. Mantenerla solo para presumir de miles de controles habría trasladado el trabajo manual desde el modelo hasta el informe.
También revisó falsos negativos conocidos. Un sistema que solo mide lo que detecta puede parecer excelente ignorando los problemas que nunca buscó. Las reuniones y revisiones humanas aportaban casos para ampliar pruebas, siempre que la condición pudiera formalizarse con estabilidad.
Cada cambio de regla tenía versión y modelos de prueba. Modificar tolerancias para reducir ruido podía ocultar conflictos importantes. Por eso se comparaban resultados antes de desplegar la nueva configuración.
La reunión cambió de inventario a decisión
Con el circuito asentado, la sesión semanal empezaba con pocos bloqueos priorizados. Los asistentes podían abrir contexto, revisar alternativas y asignar una decisión. Las incidencias informativas y las correcciones ordinarias seguían su curso fuera de la reunión.
No desaparecieron los desacuerdos. Estructuras seguía defendiendo sus cantos y las instalaciones conservaban una habilidad notable para necesitar justo ese espacio. La diferencia era que el equipo discutía el problema correcto sobre las versiones correctas, sin dedicar media mañana a encontrarlo.
La agenda se generaba a partir de severidad, dependencia y antigüedad, pero coordinación podía alterarla. La automatización preparaba el terreno; no presidía la reunión ni interpretaba compromisos de proyecto.
Medir coordinación sin contar choques como si fueran tornillos
El número bruto de interferencias resultó poco útil. Dependía del tamaño del proyecto, las reglas y la fase. El equipo siguió tiempo desde detección hasta triage, tiempo bloqueado, porcentaje de resultados descartados, incidencias reabiertas y rondas necesarias para verificar una solución.
También observó cuántas incidencias llegaban con contexto suficiente y cuántas requerían aclaración. Esa métrica mostraba si la automatización reducía persecución. Una coordinación con más incidencias bien descritas podía estar funcionando mejor que otra con una lista corta e incompleta.
Los costes de configuración, federación, revisión y mantenimiento se mantuvieron visibles. Automatizar parte del circuito no eliminaba la función de coordinación. Permitía dedicarla a decisiones con mayor impacto.
Cuándo coordinar manualmente sigue siendo sensato
En equipos pequeños, con pocos modelos y cambios rápidos de diseño, configurar un circuito complejo puede costar más que una revisión directa. También hay decisiones tempranas cuya ambigüedad hace inútil una regla geométrica rígida. En esos casos, una sesión bien preparada y un registro sencillo pueden ser suficientes.
La automatización gana valor cuando aumentan volumen, repetición, disciplinas y necesidad de trazabilidad. Conviene empezar por recepción y contexto antes de añadir detecciones sofisticadas. Si las versiones no son fiables, ninguna clasificación inteligente arreglará la base.
También hace falta propiedad. Alguien debe mantener reglas, tolerancias, integraciones y permisos. Sin ese trabajo, el sistema envejece y la reunión vuelve a perseguir errores, esta vez producidos por su propia automatización.
Menos persecución significa más tiempo para coordinar
El equipo no redujo la coordinación a una ejecución nocturna. Construyó un circuito donde modelos, reglas, incidencias y estados conservaban relación. La máquina preparaba evidencia, agrupaba candidatos, proponía responsables y verificaba cambios. Las personas decidían prioridades, soluciones y excepciones.
Ese reparto es la coordinación BIM automatizada que merece la pena: no detectar por detectar, sino acortar el recorrido entre un problema y una decisión verificable. Empieza asegurando versiones, elige reglas que conduzcan a acciones y mide el ruido que introduces.
Si la reunión vuelve a durar dos horas, al menos que sea porque el edificio plantea decisiones difíciles. Buscar la captura azul puede hacerlo un sistema; discutir por dónde pasa la bandeja todavía es patrimonio profesional.
Respuestas