Por qué fracasan las implementaciones BIM (y casi nunca es por el software)

Casi todo lo que se escribe sobre BIM habla de software. Revit, Navisworks, interoperabilidad, IFC. Pero cuando una implementación falla, rara vez es porque el equipo no supo usar la herramienta. Falla por razones de representación, de autoridad y de memoria, que son problemas mucho más viejos que cualquier herramienta digital.

Vale la pena verlos de frente, porque un equipo que entiende el problema de fondo toma mejores decisiones que uno que solo domina la interfaz.

1. El modelo es el original; los planos son derivaciones

En un flujo de trabajo tradicional, cada plano es un documento independiente. Alguien dibuja la planta, alguien dibuja el corte, y mantenerlos coherentes entre sí es trabajo manual y constante. Cuando cambia algo, cambia en un lado y no en otro, y la incoherencia aparece hasta que alguien la descubre en obra.

BIM invierte esa estructura. Hay un modelo, y todo lo demás (plantas, cortes, tablas de cantidades, vistas 3D) son derivaciones de ese modelo. No son documentos: son maneras de mirarlo. Cambias el modelo y todas las derivaciones se actualizan, porque nunca fueron cosas separadas.

El problema aparece cuando alguien trata una derivación como si fuera el original. El contratista que trabaja sobre un PDF impreso hace tres semanas no está viendo una versión vieja del proyecto: está viendo una fotografía de algo que ya cambió. Y como la fotografía se ve completa y autosuficiente, se usa como si fuera el proyecto entero.

Ahí está la mayor parte del caos de versiones en obra. No es un problema técnico. Es que las derivaciones se usan como originales, y hace falta disciplina explícita (y un procedimiento de emisión con fecha, revisión y responsable) para que el equipo sepa en todo momento cuál es cuál.

2. Ver no es mandar

Este es el punto más importante y el peor entendido.

Un coordinador BIM puede ver todo. Ve las interferencias, ve que la instalación pasa por donde va la trabe, ve que el avance no corresponde a lo estimado, ve que un subcontratista está trabajando sobre información obsoleta. Tiene visibilidad total.

Y no controla nada.

La detección de interferencias no resuelve interferencias: produce un reporte que alguien más tiene que atender, con dinero que alguien más autoriza, en un calendario que alguien más define. La capacidad de observar y la capacidad de decidir son dos cosas distintas, y en la mayoría de las implementaciones BIM solo se entrega la primera.

Por eso tantos proyectos “tienen BIM” y siguen fallando igual. Se instaló un observador sin autoridad. Ve venir el choque, lo documenta con precisión, y el choque ocurre.

La conclusión práctica no es técnica: un modelo sin un mandato de decisión asociado es un instrumento de diagnóstico, no de control.

Lo que convierte el diagnóstico en control son tres definiciones, y se toman antes de empezar:

• Quién resuelve cada tipo de hallazgo. Un reporte dirigido a “el equipo” no es responsabilidad de nadie. Cada categoría de interferencia necesita un responsable con nombre.
• En qué plazo, y qué pasa si vence. Un hallazgo sin fecha de atención se acumula. Un hallazgo cuya fecha vencida no dispara nada, tampoco existe.
• Qué documento lo obliga. Si la coordinación BIM no está en el contrato del subcontratista, participar es voluntario, y la experiencia dice qué pasa con lo voluntario cuando la obra va retrasada.

Esto se resuelve en el contrato y en el organigrama, no en el software.

3. Memoria elegida contra memoria acumulada

Un proyecto de construcción produce una cantidad enorme de conocimiento y casi todo se pierde. Por qué se cambió ese detalle, qué se probó antes y no funcionó, cuál proveedor incumplió, por qué esa solución que parece extraña era la única posible dadas las condiciones del terreno.

Ese conocimiento normalmente vive en la cabeza de dos o tres personas. Y la memoria humana no es un archivo que se llena a voluntad: guarda lo que se le antoja, pierde lo que necesitabas, y reaparece sin permiso años después. Cuando esas personas se van, el proyecto se queda sin historia.

Un modelo gestionado con criterio es otra cosa: puede ser memoria deliberada, donde lo que está registrado está ahí porque alguien decidió que valía la pena. Digo puede a propósito. Un modelo sin gestión acumula tanta basura como cualquier archivero: familias heredadas que nadie revisó, objetos duplicados, parámetros vacíos, información que ya no corresponde a nada. La diferencia entre tener archivos y tener memoria institucional no la hace el software, la hace alguien decidiendo qué entra y qué se depura.

Y viene la contraparte: un modelo solo recuerda lo que decidiste registrar. Si nadie documenta por qué se tomó una decisión, el modelo tendrá la geometría y no la razón. La razón suele valer más que la geometría, sobre todo cuando alguien propone deshacer el cambio dos años después.

El trabajo de un BIM manager no es modelar. Es decidir qué información merece existir.

Los límites, dichos en voz alta

Conviene decir esto, porque quien vende BIM rara vez lo hace.

Ningún modelo, render, recorrido virtual o gemelo digital transmite lo que se sabe estando parado en el espacio. La altura de un techo, cómo entra la luz a las cuatro de la tarde, si un pasillo se siente estrecho, si la escalera incomoda. Eso pasa por el cuerpo y no hay archivo que lo sustituya.

Lo mismo del lado de la obra: el modelo no sabe que ese destajista siempre se atrasa, ni que la ruta de acceso se inunda en temporada de lluvia. Esa información existe, es crítica, y vive en la gente.

Reconocer el límite no debilita el argumento del BIM: lo hace utilizable. El modelo es una herramienta de coordinación y de memoria, extremadamente buena en eso, y no un sustituto del juicio de alguien que conoce el terreno.

Lo que queda

BIM no es un software. Es una decisión sobre cómo se representa un proyecto, quién puede ver qué, qué se recuerda y quién decide.

Cuando una implementación falla, casi siempre es por una de tres cosas: se instaló capacidad de ver sin capacidad de decidir, se siguió trabajando sobre derivaciones como si fueran originales, o nadie definió qué información merecía quedar registrada.

Esas son preguntas de organización, y se contestan antes de abrir el programa.

En Arbant BIM ofrecemos consultoría y coordinación BIM para proyectos en Tijuana y la región. Si estás evaluando implementar BIM en tu despacho o en tu obra, la conversación útil empieza por estas preguntas, no por la licencia.

Todos los artículosHablar de un proyecto