Qué se puede hacer con programación BIM: 9 problemas que el código resuelve
La programación BIM suele entrar en un proyecto por una puerta bastante poco épica: una tabla que hay que limpiar otra vez, cuarenta vistas que deben llamarse de una forma concreta o un parámetro que alguien lleva dos tardes copiando de una columna a otra. No hace falta imaginar una inteligencia artificial diseñando edificios. A veces el primer gran avance consiste simplemente en dejar de renombrar planos a mano.
Programar en BIM significa describir una tarea con suficiente precisión para que una herramienta pueda repetirla. Esa herramienta puede ser un grafo de Dynamo, un script de Python, un complemento desarrollado con una API o un servicio que conecta varias aplicaciones. La forma cambia, pero la pregunta de fondo es la misma: ¿podemos convertir una decisión que ya entendemos en un proceso verificable?
La investigación sobre esta búsqueda repite mucho el ahorro de tiempo, aunque rara vez explica qué ocurre después del primer script. Y ahí está la parte interesante. Una automatización útil no solo ejecuta rápido; selecciona bien, informa de lo que ha hecho, contempla excepciones y puede mantenerse cuando cambia el proyecto. Vamos a recorrer nueve problemas reales siguiendo ese hilo, desde el dato más sencillo hasta las integraciones que ya afectan a todo el equipo.
Tabla de contenidos
1. Encontrar datos incompletos antes de que lleguen a la entrega
Imagina que el modelo debe llevar código de clasificación, estado de mantenimiento y referencia de zona en determinados elementos. Revisarlo visualmente no escala y una tabla de Revit ayuda solo hasta cierto punto. Con programación puedes recoger el conjunto afectado, leer los parámetros y separar elementos correctos, incompletos y no evaluables.
La diferencia está en cómo defines “afectado”. No basta con pedir todas las puertas si las temporales o las de determinadas fases quedan fuera. Tampoco conviene considerar correcto un parámetro que existe pero está vacío. El script necesita reflejar el requisito real, no una versión cómoda para el programador.
Cuando funciona, el resultado no debería ser un semáforo sin explicación. Necesitas identificador, regla, valor encontrado y motivo. Así la revisión deja de ser una caza manual y se convierte en una lista de decisiones. Si la herramienta devuelve cero errores porque el nombre del parámetro estaba mal escrito, no has automatizado el control de calidad; has automatizado la tranquilidad falsa.
2. Normalizar nombres sin convertir el modelo en una ruleta
Los nombres de vistas, familias, tipos y láminas crecen con el proyecto. Al principio todos siguen la convención. Después aparece una vista llamada “COPIA definitiva 2”, otra conserva el prefijo de una fase anterior y una tercera utiliza un guion diferente. No es un drama aislado, pero acaba afectando a filtros, exportaciones y entregables.
Un flujo puede analizar los nombres, proponer una versión normalizada y mostrar una vista previa. La palabra importante es proponer. Renombrar directamente todo lo que no coincida con un patrón resulta tentador hasta que descubres que dos elementos producirían el mismo nombre o que una excepción tenía sentido.
Este caso enseña una idea que volverá varias veces: separar análisis y modificación. Primero recoges y clasificas; después presentas cambios; por último ejecutas solo los confirmados. El ahorro no desaparece por añadir una revisión. Al contrario, hace posible que el equipo utilice la herramienta sin pedir una copia de seguridad y cruzar los dedos.
3. Crear documentación repetitiva sin clonar errores
Generar vistas, colocarlas en láminas o aplicar configuraciones es otra tarea habitual. Si el proyecto tiene una estructura estable, el código puede crear la documentación a partir de niveles, zonas o disciplinas. Esto evita repetir una secuencia larga y reduce pequeñas diferencias entre paquetes que deberían ser equivalentes.
Pero la documentación no es solo una colección de objetos. Una vista puede necesitar plantilla, escala, recorte, nomenclatura y posición. Una lámina puede estar ocupada o depender de una composición especial. El programa debe saber qué condiciones son obligatorias y cuáles necesitan intervención. Forzar cada caso dentro de la misma cuadrícula suele producir planos muy uniformes y muy poco útiles.
Yo automatizaría primero el esqueleto: crear los elementos previsibles, aplicar configuraciones y señalar conflictos. Dejaría las decisiones gráficas singulares a quien prepara la entrega. Programar no consiste en eliminar a la persona del flujo, sino en reservarle la parte que realmente necesita criterio.
4. Pasar información entre Revit y Excel sin copiar y pegar
Antes o después, muchos flujos BIM terminan en una hoja de cálculo. Puede contener códigos corporativos, información de activos, mediciones o revisiones del cliente. El problema no es usar Excel; es perder el control sobre qué versión manda y copiar valores sin saber cuáles han cambiado.
Una integración puede exportar datos con identificadores estables, permitir la revisión y reimportar únicamente campos autorizados. Para hacerlo bien necesitas un contrato: qué columnas son editables, cómo se validan los tipos, qué ocurre con filas nuevas y cómo se resuelven conflictos si el modelo también cambió. Sin ese contrato, el script solo mueve más deprisa el mismo desorden.
También conviene conservar un informe de diferencias. Qué valor había, cuál se propone y qué elemento recibirá el cambio. Una celda vacía puede significar “borrar”, “sin dato” o “no tocar”; si no lo decides antes, alguien lo decidirá accidentalmente al ejecutar. Esto parece una tontería hasta que una columna en blanco limpia cientos de parámetros.
5. Revisar IFC con reglas que puedas volver a ejecutar
Cuando recibes IFC de varias disciplinas, la programación permite consultar entidades, propiedades y relaciones sin depender de abrir cada archivo y recorrerlo a mano. Bibliotecas como IfcOpenShell pueden formar parte de un flujo que comprueba esquema, extrae información y aplica reglas acordadas.
El reto vuelve a estar en el requisito. “El IFC debe estar bien” no sirve. “Los espacios de las plantas incluidas deben tener código y nombre” ya se acerca a una regla. Todavía faltan excepciones, severidad y una salida que permita localizar el elemento, pero al menos puedes probarla con casos que pasen y fallen.
No mezcles desde el principio datos y geometría. Leer propiedades suele ser más ligero que generar sólidos. Si buscas una clasificación, no necesitas procesar toda la representación geométrica. Y si buscas colisiones, recuerda que una intersección matemática no siempre es una incidencia BIM. Necesitarás tolerancias, exclusiones y una manera de agrupar el ruido.
6. Convertir una incidencia geométrica en trabajo coordinable
Detectar que dos objetos se cruzan es solo el comienzo. El equipo necesita saber dónde ocurre, qué elementos participan, quién debe revisarlo y si ya se había detectado antes. La programación puede enriquecer el resultado geométrico con datos del modelo, aplicar reglas de asignación y generar una incidencia en el sistema de coordinación.
Este flujo muestra por qué los identificadores y la trazabilidad importan. Si cada ejecución crea cien incidencias nuevas para los mismos conflictos, la automatización empeora el proyecto. Hay que reconocer casos existentes, actualizar su estado y conservar el vínculo con la versión del modelo que produjo el resultado.
También debes admitir resultados dudosos. Puede que falte el responsable, que un elemento no tenga sistema o que la ubicación no se transforme correctamente. Una cola de excepciones revisable es mejor que inventar valores para que todas las filas estén completas. En coordinación, un “no lo sé todavía” bien localizado tiene más valor que una asignación automática equivocada.
7. Comparar versiones sin revisar todo desde cero
Cuando llega una nueva entrega, la pregunta rara vez es solo si el archivo abre. Queremos saber qué ha cambiado y si ese cambio afecta a nuestra revisión. El código puede comparar inventarios, parámetros o propiedades entre versiones y concentrar la atención en elementos nuevos, eliminados o modificados.
No siempre existe una correspondencia perfecta. Los identificadores pueden cambiar por la forma en que se ha exportado o reconstruido el modelo. La herramienta necesita diferenciar una coincidencia segura de una aproximación. Combinar nombre, tipo, posición y otras propiedades puede ayudar, pero también introduce incertidumbre que debe aparecer en el informe.
La comparación es útil cuando reduce el espacio de revisión, no cuando promete una verdad absoluta. Presenta categorías de cambio, confianza y casos sin correspondencia. Así el profesional decide dónde mirar. Ocultar esa incertidumbre detrás de un porcentaje muy preciso solo consigue que el informe parezca más científico de lo que es.
8. Conectar aplicaciones sin montar un festival de CSV
A medida que el flujo madura, ya no basta con trabajar dentro de una herramienta. Puede que una incidencia creada en una plataforma de coordinación deba actualizar un panel interno, o que una nueva versión de un archivo active una validación. Las APIs y los webhooks permiten conectar esos eventos sin depender de exportaciones manuales.
Aquí la dificultad deja de ser únicamente BIM. Aparecen autenticación, permisos, límites del proveedor, reintentos y estados parciales. Si un servicio recibe dos veces el mismo evento, debe reconocerlo. Si la plataforma externa no responde, la operación tiene que quedar pendiente y no desaparecer. Una integración que funciona solo durante la demostración es una presentación, no un sistema.
Empieza con un recorrido pequeño y observable. Un evento, una acción y un registro que permita seguirlo. Añade después deduplicación, reintentos y alertas. No conectes cinco sistemas a la vez porque el diagrama quede bonito; cuando algo falle a las seis de la mañana, agradecerás saber en qué salto se quedó.
9. Construir una herramienta propia cuando el proceso ya está maduro
Los ocho problemas anteriores pueden empezar como scripts. Algunos crecerán hasta necesitar una interfaz, configuración por proyecto, permisos, instalación y soporte. En ese punto ya no estás creando una automatización personal, sino un pequeño producto interno. La API del software permite desarrollarlo, pero el código es solo una parte.
Una herramienta compartida debe validar entradas, explicar errores y dejar claro qué versión se ejecuta. La lógica BIM conviene separarla de la interfaz y del acceso al modelo para poder probarla. También necesitas decidir quién aprueba cambios, cómo se distribuyen y qué versiones del software se soportan realmente.
Este salto no siempre compensa. Si el proceso cambia cada semana o solo lo utiliza una persona, mantener un complemento puede costar más que el trabajo manual. La señal adecuada es que el problema ya está entendido, se repite, afecta a varias personas y tiene una salida verificable. Construir antes de llegar ahí es una forma elegante de programar requisitos móviles.
Cómo elegir por dónde empezar sin aprenderlo todo
Después de ver nueve posibilidades, es fácil pensar que necesitas dominar Dynamo, Python, C#, APIs web y media ingeniería de software. No. Elige un problema pequeño que conozcas bien y una herramienta proporcionada. Dynamo puede servir para visualizar un flujo acotado; Python para concentrar lógica; una API y un lenguaje como C# para un complemento que deba distribuirse.
Haz una primera versión que solo lea y genere un informe. Prueba con ejemplos válidos, inválidos y ambiguos. Cuando confíes en la selección, añade la modificación o la integración. Documenta supuestos y mide el tiempo total, incluido revisar, corregir y mantener. El objetivo no es demostrar que sabes programar, sino comprobar que el proceso mejora.
Y conserva siempre una alternativa manual. No porque esperes que todo falle, sino porque los proyectos no pueden detenerse mientras alguien depura una actualización. La automatización responsable reduce dependencia y hace explícito el conocimiento; no cambia una persona imprescindible por un script imprescindible.
La programación BIM resuelve decisiones repetidas, no problemas difusos
Los nueve casos comparten la misma progresión. Primero entendemos el dato y la regla. Después hacemos visible el resultado. Solo entonces modificamos, conectamos o escalamos. Saltarse ese orden produce herramientas rápidas que nadie se atreve a ejecutar sobre el modelo bueno.
Programar puede ahorrar trabajo repetitivo, pero su valor más serio es otro: obliga a explicar cómo decidimos. Qué elemento entra, qué condición debe cumplir, qué excepción aceptamos y qué hacemos cuando no sabemos. Ese criterio se puede revisar, versionar y compartir con el equipo.
Si tienes una tarea delante, no empieces preguntando qué lenguaje está de moda. Pregunta qué parte se repite, qué parte exige juicio y cómo comprobarías el resultado. Cuando puedas responder a eso, la tecnología suele ser la decisión fácil. Y cuando no puedas, probablemente aún no necesitas código: necesitas entender mejor el proceso.
Respuestas