Integración BIM con Excel: datos que puedes seguir

Tres hojas, tres cifras y tres colores igualmente convincentes. Una cantidad viene del modelo, otra incorpora un ajuste y la tercera apareció durante una reunión cuya acta nadie encuentra. Conectar BIM con Excel puede hacer circular todo eso más deprisa. Qué detalle: también puede propagar el error con una eficacia admirable. Antes de celebrar que ya no copiamos y pegamos, vamos a darle a cada dato una identidad, una procedencia y alguien que pueda explicar por qué cambió.

Vamos a seguir un ejemplo hipotético de mediciones de falso techo. El modelo aporta cantidades; planificación decide qué zonas entran en su análisis y puede aplicar un coeficiente explicado. Después quizá necesite devolver un código de actividad. Son operaciones distintas y conviene mantenerlas visibles durante todo el recorrido. El objetivo es actualizar información sin convertir cada nueva entrega en una negociación sobre cuál era la hoja buena.

Define qué trabajo hace Excel antes de conectarlo

Excel puede ser una salida de consulta, un lugar para calcular y revisar o una entrada de cambios hacia el modelo. La primera decisión consiste en identificar cuál de esos papeles necesita el equipo. Si solo quieres agrupar cantidades, exportar una instantánea puede ser suficiente. Una sincronización bidireccional incorpora conflictos y responsabilidades adicionales que no desaparecen porque el conector tenga una casilla con un nombre tranquilizador.

Imagina que el modelo del ejemplo suma 1.000 m² y planificación excluye 100 m² de zonas pendientes. Sobre los 900 m² restantes aplica, solo para ilustrar la cuenta, un coeficiente del 10 % y obtiene 990 m². Las tres cifras describen cosas diferentes. El porcentaje no es una recomendación de medición: tendría que justificarse en el proyecto. El problema empezaría si alguien sustituyese la cantidad del modelo por el resultado y ocultase tanto la exclusión como el ajuste.

Conserva separados el valor extraído, los criterios del análisis y el resultado utilizado. Cada transformación necesita un nombre que explique su significado y una persona responsable. Así puedes discutir si el coeficiente tiene sentido sin sospechar primero que la exportación está mal. La hoja deja de ofrecer una única cifra misteriosa y empieza a mostrar una decisión revisable.

Piensa también dónde vive cada dato. El modelo puede gobernar geometría y determinadas cantidades, planificación sus actividades y otro sistema ciertos identificadores finales. Esa autoridad puede variar por campo y por proceso. Preguntar por «la única fuente de verdad de todo el proyecto» suele producir respuestas solemnes que se deshacen al llegar a la primera columna. Es más útil acordar quién puede modificar cada valor y cómo comunica el cambio.

Cuando la necesidad está clara, compara una extracción nativa, un conector existente o una integración propia según el trabajo completo y sus costes de mantenimiento. No hace falta introducir una vista 3D dentro de la hoja si nadie la necesita para decidir. La mejor conexión puede ser una tabla modesta con referencias correctas. Que podamos añadir geometría no significa que cada informe deba convertirse en una pequeña aplicación BIM con celdas.

Exporta una instantánea con identidad y unidades

La tabla debería declarar de qué modelo y estado procede, cuándo se obtuvo y qué selección o configuración se utilizó. No representa «el BIM» en abstracto: contiene una instantánea de un alcance determinado. Si dos hojas usan fases o categorías diferentes, sus totales pueden discrepar sin que ninguna fórmula esté rota. Esa información tiene que viajar con los datos para que la comparación pueda reconstruirse.

Cada fila necesita una clave que permita relacionarla con su origen. El nombre visible, el número de fila y la posición en una tabla no ofrecen la misma estabilidad. Una referencia de Revit o IFC debe conservar su contexto y sus límites; un código de negocio necesita comprobar unicidad y persistencia. Si un elemento se sustituye o divide, quizá la relación deba revisarse. No trasladarías una actividad a otro objeto solo porque heredó la fila 28; la integración tampoco debería hacerlo.

Trata los identificadores como identificadores. Excel puede interpretar como número un código con ceros iniciales y cambiar su representación o precisión. La ayuda de Microsoft sobre ceros iniciales y números grandes explica cómo conservar esos valores como texto. El formato debe definirse antes de introducir o importar datos: cambiarlo después no reconstruye necesariamente la información que ya se perdió. Los códigos se parecen a números por fuera; no por eso necesitan aritmética.

Las cantidades exigen otro tratamiento. Declara sus unidades y convierte de forma explícita al extraer. La guía de unidades de la API de Revit distingue valores internos, formatos y herramientas de conversión. Una celda que se ve como «m²» no demuestra que la integración haya convertido correctamente el dato de origen. Compruébalo con un elemento cuya cantidad puedas contrastar.

Decide dónde se redondea y conserva precisión suficiente para calcular. Sumar valores ya redondeados por elemento puede producir una cifra distinta de redondear el total al final. Ninguna política debería elegirse accidentalmente porque era la que traía una plantilla. Distingue también cero, dato ausente y no aplicable. Convertir todo en cero hace más cómoda la suma, aunque elimina parte de la explicación que alguien necesitará al revisar la entrega.

Actualizar la hoja exige conservar las decisiones por separado

La siguiente entrega puede añadir elementos, eliminar otros y cambiar cantidades o fases. Regenera la parte procedente del modelo como una nueva instantánea y relaciona por clave los ajustes que deban conservarse. Si esos ajustes viven directamente encima de los datos importados, cada actualización obliga a elegir entre perder trabajo o mantener valores antiguos sin saberlo. Ambas alternativas tienen mucha tradición; ninguna mejora con un botón más rápido.

En el ejemplo, las exclusiones y coeficientes pueden guardarse en una tabla propia con referencia, motivo y responsable. El análisis une esa tabla con las cantidades de la instantánea elegida. Si una referencia desaparece, el ajuste queda pendiente de revisión en vez de desplazarse a la siguiente fila disponible. De esa forma puedes explicar si cambió la geometría, el alcance o una decisión de planificación.

La comparación debería distinguir altas, bajas y modificaciones relevantes. Un total parecido al anterior puede esconder compensaciones entre zonas, y un total distinto puede obedecer a una selección deliberada. Conserva el detalle necesario para volver al origen sin acumular archivos completos indefinidamente por miedo a perder algo. Trazabilidad significa poder seguir una decisión; una carpeta con cincuenta «finales» ofrece otra clase de experiencia.

Las fórmulas y las columnas de entrada también merecen separación. Puedes proteger determinadas zonas y validar datos para ayudar al usuario, pero el importador debe comprobar el contrato por su cuenta. Una columna renombrada, una fila duplicada o una versión incompatible de la plantilla deberían producir una explicación útil. La validación de la hoja facilita trabajar; no sustituye el control de la aplicación que recibirá sus valores.

Así el análisis puede regenerarse y seguir siendo comprensible. La cantidad del modelo no se confunde con la que resulta de aplicar ajustes, y cada diferencia tiene un lugar donde investigarse. Si una columna solo se entiende preguntando a quien la añadió hace tres meses, conviene aclararla antes de automatizar su recorrido. La ausencia de documentación tiene una sorprendente facilidad para convertirse en lógica de negocio heredada.

Devolver datos al modelo necesita una propuesta de cambios

Supongamos que planificación quiere asignar códigos de actividad a los elementos. Ese campo puede tener catálogo y responsable definidos, mientras las cantidades calculadas quedan fuera de la escritura. Limitar el primer intercambio ayuda a revisar su comportamiento. «Sincronizar la hoja» es una expresión demasiado amplia si unas columnas son datos originales, otras cálculos y otras propuestas todavía no aprobadas.

La importación debe validar identificadores, esquema y valores admitidos, y localizar el destino correcto. En Revit importa si el dato pertenece al tipo o a la instancia, si existe el parámetro y si se puede editar en ese contexto. Una fila válida en Excel todavía puede no ser aplicable sobre el modelo. El resultado debe explicar esa diferencia antes de modificar nada.

Para detectar conflictos, conserva el valor que se exportó y compáralo con el actual y el propuesto. Si alguien cambió el modelo mientras la hoja estaba en revisión, no basta con elegir automáticamente la celda que parece más reciente. Puedes tener una política por campo, pero debe ser explícita. La vista previa debería mostrar qué se actualizará, qué coincide y qué requiere decisión, manteniendo una referencia que permita localizar el elemento.

La ejecución tiene que respetar las transacciones y restricciones documentadas de Revit. Antes de aplicar, vuelve a comprobar condiciones críticas para evitar actuar sobre una propuesta que ya perdió vigencia. Después contrasta los valores afectados y distingue aplicados, omitidos y fallidos. Que la hoja haya enviado una petición no acredita que cada parámetro haya cambiado como se esperaba.

La repetición también forma parte del contrato. Volver a importar sin cambios debería tener un comportamiento conocido y no multiplicar comentarios, relaciones o registros de resultado. Si se admite un lote parcial, explica qué queda pendiente; si el trabajo exige coherencia del conjunto, define qué debe revertirse cuando algo falla. No hay una política universal, pero sí una obligación bastante razonable de contar cuál se ha seguido.

Prueba el intercambio antes de confiarle la entrega

Prepara casos pequeños que representen el desorden habitual: código con ceros iniciales, identificador duplicado, referencia inexistente, unidad incorrecta y dato que cambió después de exportar. Añade un ajuste cuyo elemento haya desaparecido y una columna que no pertenezca a la versión admitida. Cada caso debe tener una respuesta esperada. Un importador que acepta cualquier archivo puede resultar muy flexible y completamente incapaz de explicar qué acaba de hacer.

Contrasta además el recorrido entero con un conjunto conocido: cantidad de origen, transformación y resultado del análisis. En el ejemplo, la cuenta de 1.000, 900 y 990 m² es ilustrativa y reproducible porque sus supuestos están expuestos. En un proyecto real necesitarías comprobar la extracción y justificar sus ajustes. Esa evidencia debe obtenerse con las herramientas y versiones que utilizará el equipo, sin confundir una fórmula correcta con una integración validada.

Registra quién mantiene el contrato, cómo se revisan cambios de plantilla y qué ocurre con archivos antiguos. Si la herramienta se comparte, el destinatario necesita reconocer una entrada compatible y saber cómo actuar ante un conflicto. Las credenciales de conexión deben permanecer en el entorno que las gestiona, no escondidas dentro de una hoja que viajará entre varias personas. La comodidad de compartir un archivo no implica compartir también todo lo que permite conectarse.

Cuando el dato requiere mucha concurrencia, permisos precisos o relaciones complejas, quizá convenga que viva en una aplicación y que Excel siga siendo una vista de análisis. Para una consulta puntual, en cambio, una extracción puede aportar casi todo el valor. Dimensionar la conexión evita construir una infraestructura difícil de sostener alrededor de un informe que se utiliza dos veces al año.

Elige una columna que hoy no podrías regenerar si se perdiera la hoja y reconstruye su recorrido: origen, revisión, transformación y responsable. Esa conversación vale más que otra macro que rellene celdas por posición. La integración habrá mejorado cuando puedas explicar una diferencia sin convocar al autor del Excel; mientras tanto, el archivo sigue ejerciendo de oráculo con cuadrícula.