Automatizar procesos BIM: empieza por el cuello de botella correcto
El equipo había preparado una lista de cinco automatizaciones «urgentes»: renombrar vistas, crear planos, exportar IFC, comprobar parámetros y generar incidencias. Todas parecían buenas candidatas porque todas consumían tiempo y todas habían provocado alguna queja. El problema era que elegir por nivel de fastidio convertía la hoja de ruta en un concurso de anécdotas. Ganaba la tarea de la persona que hubiese sufrido más cerca de la última reunión.
Para automatizar procesos BIM con un poco de cabeza, conviene apartar durante un momento las herramientas. Dynamo, Python, la API de Revit y la IA pueden esperar. Primero hay que encontrar dónde se acumula el trabajo, cuánto tiempo permanece allí y qué decisiones impiden que siga avanzando. En este equipo, el cuello de botella no era ninguna de las cinco tareas de la lista. Estaba en el tramo menos vistoso: recibir modelos, averiguar si estaban listos y devolver incidencias comprensibles.
Tabla de contenidos
Cinco ideas, un proceso que nadie había dibujado
La entrega empezaba cuando tres disciplinas depositaban sus modelos en una carpeta. A partir de ahí, coordinación comprobaba nombres, versiones y vínculos; abría cada archivo; revisaba parámetros; generaba IFC; federaba resultados y redactaba incidencias. Si faltaba algo, enviaba un mensaje. Cuando llegaba la corrección, repetía buena parte del recorrido porque no siempre sabía qué había cambiado.
Renombrar vistas ocupaba horas a final de mes, pero apenas afectaba al avance semanal. Crear planos tenía valor, aunque cada proyecto aplicaba criterios diferentes. La exportación IFC consumía veinte minutos de máquina y muy poca atención humana. En cambio, un modelo podía esperar un día entero hasta que alguien confirmase si estaba listo. Después podía rebotar dos veces porque la incidencia decía «faltan parámetros» sin indicar elementos, propiedades ni severidad.
El equipo dejó de contar clics y empezó a observar tiempos. Registró cuándo llegaba cada modelo, cuándo comenzaba la revisión, cuánto duraba el trabajo activo, cuándo se solicitaba una corrección y cuándo regresaba. La diferencia entre tiempo activo y tiempo total fue reveladora. El script de exportación podía ahorrar minutos; la falta de un estado fiable estaba consumiendo jornadas.
Ahí apareció el cuello de botella correcto: coordinación actuaba como detector de disponibilidad, validador, mensajero y memoria del proceso. Automatizar una exportación dentro de ese atasco habría sido como instalar una puerta automática en una habitación sin salida.
Medir sin convertir cada bostezo en una métrica
El equipo eligió cuatro señales sencillas: espera hasta iniciar la revisión, minutos de trabajo manual, número de devoluciones y porcentaje de incidencias que necesitaban una aclaración. No pretendía construir un observatorio nacional del IFC. Necesitaba comparar candidatos y comprobar después si el cambio había servido.
Durante tres ciclos se vio que la validación no era lenta por recorrer parámetros, sino por preparar el contexto. Había que localizar la versión, cargar vínculos, recordar qué requisitos aplicaban a cada disciplina y transformar hallazgos en mensajes útiles. Además, algunas comprobaciones se repetían después de cada devolución, aunque el cambio afectase solo a una parte del modelo.
También se anotó el coste de los errores. Un nombre de vista incorrecto era molesto y barato de corregir. Aceptar un modelo con coordenadas equivocadas contaminaba la federación y podía invalidar muchas incidencias posteriores. La prioridad debía combinar frecuencia, impacto, estabilidad de la regla y facilidad de verificación. Una tarea repetitiva no es automáticamente una buena automatización si su criterio cambia cada martes.
El piloto empezó antes de abrir Revit
El primer piloto definió un paquete de recepción. Cada disciplina entregaría modelo, identificador de versión y declaración de estado. Al entrar, una rutina comprobaría que el archivo esperado existiera, que el nombre siguiese el convenio y que la versión no fuese anterior a la ya revisada. Después ejecutaría un conjunto pequeño de reglas: presencia de vínculos, coordenadas de referencia, parámetros críticos y categorías incluidas en el intercambio.
Las reglas se escribieron en lenguaje humano antes de programarlas. «Comprueba la información» no servía. «Los equipos mecánicos incluidos en la entrega deben tener Código_Activo y Sistema informados» sí. Para cada control se definieron alcance, resultado esperado, severidad y responsable. Esta preparación eliminó varias ideas que sonaban claras en reunión, pero producían cuatro interpretaciones distintas al buscar un elemento real.
El piloto solo leía. Generaba un informe con modelo, regla, elemento, propiedad y resultado; no corregía parámetros ni descargaba vínculos por su cuenta. Esa limitación reducía el riesgo y facilitaba comparar la máquina con una revisión humana. Si ambos discrepaban, el equipo podía discutir la regla sin preguntarse además qué había modificado el script.
Tras dos entregas, los resultados pasaron a estados. Un modelo podía quedar recibido, validado, bloqueado o aceptado con excepciones. Coordinación ya no preguntaba quién había terminado: veía qué paquete estaba disponible y por qué otro no podía avanzar. La automatización no había resuelto todavía el proyecto, pero había dejado de obligar a una persona a interpretarlo entero cada mañana.
La herramienta se eligió después de conocer la decisión
Para las comprobaciones cercanas a Revit, Dynamo permitía prototipar la lógica y enseñarla al equipo. Era útil mientras las reglas eran pocas y el alcance estaba controlado. Al crecer el número de validaciones y necesitar informes consistentes, Python ofrecía una estructura más cómoda para separar lectura, reglas y salida. Si la solución debía distribuirse, gestionar permisos y vivir integrada en varias versiones de Revit, una aplicación sobre su API aportaba más control, a cambio de mayor desarrollo y mantenimiento.
La IA quedó fuera del núcleo determinista. Podía ayudar a agrupar incidencias parecidas o resumir resultados, siempre mostrando la evidencia original, pero no decidir si un parámetro obligatorio dejaba de serlo. Cuando una condición puede expresarse y verificarse, una regla explícita suele ser más barata de probar y bastante menos imaginativa. Para interpretar comentarios ambiguos, la IA podía asistir; para bloquear una entrega, hacía falta una decisión reproducible.
Esta elección evitó buscar un único martillo tecnológico. El proceso necesitaba lectura fiable, reglas versionadas, una salida entendible y un estado compartido. La interfaz podía cambiar sin alterar esos cuatro compromisos. Empezar por la tecnología habría empujado el diseño hacia lo que la herramienta hacía mejor, no hacia lo que el equipo necesitaba controlar.
Las incidencias dejaron de volver como bumeranes
Antes del piloto, una incidencia solía contener una captura y una frase. Ahora cada hallazgo incluía regla, elemento, valor encontrado, valor esperado y enlace o identificador para localizarlo. En IFC se conservaba el identificador del objeto y la propiedad evaluada; en Revit, el elemento y el modelo de origen. El responsable podía filtrar por severidad y corregir un grupo coherente, en lugar de practicar arqueología digital.
Cuando llegaba una nueva versión, el flujo repetía las comprobaciones y comparaba resultados. Las incidencias resueltas se cerraban, las persistentes conservaban su historial y las nuevas aparecían como tales. Así se redujo el retrabajo de coordinación: ya no era necesario reconstruir qué se había comunicado y qué seguía pendiente.
No todo se convirtió en incidencia automática. Una diferencia geométrica podía requerir interpretar tolerancias, fase y responsabilidad. El sistema reunía los datos y señalaba el conflicto; una persona decidía. Ese reparto importa porque un volumen alto de avisos irrelevantes no es control de calidad. Es spam con casco.
Las excepciones formaron parte del diseño
Un colaborador externo entregó un modelo sin la clasificación acordada, pero necesario para una reunión. El flujo lo bloqueó. En lugar de desactivar la regla, coordinación registró una excepción limitada a esa versión, con motivo, aprobador y fecha de caducidad. El paquete pudo avanzar sin fingir que el requisito se había cumplido.
Las excepciones mostraron qué reglas eran demasiado rígidas y qué problemas se repetían. Si una misma condición se aceptaba cada semana, había que cambiar el requisito, corregir el origen o admitir que el control no representaba el proceso real. Acumular excepciones permanentes solo construye una segunda normativa, esta vez escondida.
También se definió una salida manual. Si la rutina fallaba, el equipo podía ejecutar la validación conocida, usar la misma configuración de exportación y registrar el paquete. La automatización debía reducir el riesgo, no secuestrar la entrega. Un sistema sin contingencia funciona de maravilla hasta que más se le necesita, que es una forma muy informática de puntualidad.
El mantenimiento entró en la estimación
Al comparar las cinco ideas originales, el equipo añadió una columna que había olvidado: quién mantendría la solución. Renombrar vistas era estable y barato. Crear planos dependía de muchas convenciones de proyecto. Las reglas de recepción tenían impacto alto, pero necesitaban revisar requisitos y versiones de software. La exportación IFC exigía probar configuraciones cuando cambiaban Revit o los usos del modelo.
Cada automatización recibió propietario, versión y modelos de prueba. Los cambios en el BEP activaban una revisión de reglas. Los resultados guardaban la versión del validador y de la configuración utilizada. Gracias a ello, un informe podía entenderse meses después y una actualización no llegaba a producción porque «en mi modelo funcionaba».
El coste se midió con honestidad: diseño del proceso, implementación, pruebas, formación, soporte y evolución. El ahorro también se observó en ciclos reales. No se multiplicó una ejecución perfecta por todos los proyectos de la empresa para anunciar una fortuna imaginaria. El piloto debía demostrar menos espera, menos devoluciones y resultados más claros antes de ampliar su alcance.
Cuándo dejar una tarea en paz
La creación automática de planos quedó en espera. Las reglas cambiaban entre proyectos, había muchas excepciones y el daño de colocar vistas equivocadas era fácil de ocultar entre decenas de láminas. El equipo prefirió estandarizar primero criterios y automatizar ayudas parciales: preparar vistas, detectar huecos y proponer una disposición revisable.
También descartó automatizar decisiones normativas ambiguas. Una herramienta podía calcular áreas, revisar valores y reunir evidencia, pero la conformidad final dependía de contexto y responsabilidad profesional. La tarea no desapareció; se dividió entre preparación automática y decisión humana.
No automatizar todavía no es fracasar. A veces es la conclusión más rentable del análisis. Si el proceso ocurre poco, cambia mucho, no tiene datos fiables o su error resulta difícil de detectar, conviene mejorarlo antes de codificarlo.
El resultado fue menos espectacular y bastante más útil
Después de varios ciclos, el equipo seguía usando Revit, IFC y reuniones. Lo que cambió fue el tramo entre recibir un modelo y saber qué hacer con él. Los estados eran visibles, las reglas se podían discutir, las incidencias llevaban contexto y las excepciones dejaban rastro. La coordinadora ya no sostenía el proceso con recordatorios; intervenía donde hacía falta criterio.
Automatizar procesos BIM empieza así: dibuja el recorrido, separa espera de trabajo, mide devoluciones, valora el riesgo y busca la decisión repetida que frena al conjunto. Después diseña un piloto pequeño que lea antes de escribir, produzca evidencia y pueda fallar sin bloquear la oficina. Solo entonces elige Dynamo, Python, una API o una ayuda de IA.
Quizá el primer resultado no tenga un botón bonito para enseñar en una demo. Tendrá algo mejor: un cuello de botella menos y un equipo que sabe por qué.
Respuestas