198 LOIN: Información consciente o caos estructurado

198 LOIN: Información consciente o caos estructurado

Todo parte de una pregunta que parece tonta, pero que es clave: ¿para qué quieres esa información en el modelo? Y lo que parece una obviedad se convierte en una tragedia cuando descubres que la mayoría de las veces nadie se la ha hecho.

Si no sabes para qué se va a usar un dato, es probable que acabes metiendo toneladas de basura que entorpecen, en lugar de ayudar. Un dato no vale por existir, vale por ser útil. Así que la próxima vez que estés modelando, validando o entregando, pregúntate primero esto: ¿quién lo necesita, en qué momento y para qué lo va a usar?

Porque si la respuesta es “por si acaso”, ya vas tarde.

LOD vs LOIN: El divorcio inevitable

Durante años nos han contado que todo giraba en torno al LOD: Level of Detail, Development o Dungeon, dependiendo de lo friki que seas.

El caso es que pensábamos que subir de LOD era como subir de nivel en un videojuego: más geometría, más precisión, más guay. Hasta que nos dimos cuenta de que los modelos eran cada vez más bonitos… pero cada vez menos útiles. Ahí es donde entra el LOIN. Porque el LOIN no te pide que modeles más, sino que modeles mejor.

No se trata de ponerle tornillos a una manilla de puerta, sino de poner justo la información que necesitas según el uso, la fase del proyecto y quién vaya a recibir el modelo. Menos detalle por default y más intención en cada input.

Obesidad modelada: cuando el modelo pesa más que tu proyecto

Si alguna vez has abierto un modelo y has tenido tiempo de hacerte un café, moler el grano, hacer un curso online y aún así no ha terminado de cargar, sabes de lo que hablamos. Esto es lo que bautizamos con cariño como obesidad modelada o diógenes digital. Parámetros por todos lados, familias que parecen obras de arte pero que nadie pidió, y datos que solo están ahí porque alguien pensó que “mejor que sobre”.

Y claro, el resultado es un Frankenstein de información que nadie usa pero todos sufren. Porque lo barato que es guardar un archivo no significa que todo deba estar ahí.

Y porque un modelo que no se puede usar, por más detallado que esté, es un error caro.

IDS: El semáforo que dice si vas bien o la has liado

Aquí es donde el mundo ideal y el mundo real se pueden encontrar. Porque una cosa es definir un LOIN en un PDF precioso, y otra muy distinta es comprobar si el modelo realmente cumple lo que se espera.

Ahí entra IDS, el estándar de BuildingSmart que permite definir y validar automáticamente requisitos concretos para elementos del modelo. ¿Tiene este muro los parámetros correctos? ¿Está el valor dentro del rango esperado? ¿Faltan cosas? ¿Sobran?

IDS no solo permite comprobar esto con herramientas como Zoom o Bonsai, sino que puede hacerlo sin intervención humana, lo que significa que puedes seguir con tu día mientras un autómata te avisa si el modelo no cumple. Ahora, ¿qué falta para que esto se masifique? ¿Por qué no todos lo usan? ¿Y qué herramientas permiten pasar del LOIN teórico a una validación real y útil?

Del OIR al Handover: la cadena de los requisitos que nadie sigue

El LOIN no nace por generación espontánea. Hay una lógica detrás que empieza con los OIR (Organizational Information Requirements), sigue con los AIR (Asset Information Requirements), y culmina con los EIR (Exchange Information Requirements).

En teoría, todo el mundo lo tiene clarísimo. En la práctica, lo que ocurre es que nadie sabe muy bien qué es lo que necesita el otro, y menos aún cuándo lo necesita. El resultado: modelos que entregan mucho de lo que nadie ha pedido, y poco de lo que realmente hace falta.

Si no hay una jerarquía clara de información, si cada fase no define lo que necesita, y si nadie toma la responsabilidad de coordinar todo eso, el modelo se convierte en una mezcla de buenas intenciones y errores sistémicos.

El Facility Management es el hermano feo de la película

Todos lo hemos vivido. Se entrega un modelo con cientos de propiedades para el gestor del activo. Un modelo “maravilloso” que debería permitir gestionar el edificio sin pedir un solo plano extra. La realidad es otra: nombres mal puestos, campos que no sirven, parámetros vacíos o, peor aún, campos que no existen porque nunca se definieron bien. Y lo peor es que todo el mundo finge que está bien. Como si generar un archivo COBie con un plugin fuera suficiente. Como si la operación y el mantenimiento fueran un apéndice y no el objetivo real del modelo.

El Facility Management sigue siendo el gran olvidado, cuando debería ser quien marca el paso desde el principio. Porque al final, si el modelo no sirve para operar, ¿para qué sirvió todo el esfuerzo?

Conclusión: ¿Qué metes en tu modelo y por qué?

Si después de todo este episodio solo te quedas con una cosa, que sea esta: cada dato en tu modelo debería tener una razón de ser.

No se trata de documentar todo por sistema, ni de meter por meter. Se trata de hacer una pregunta básica: ¿esto para qué lo quiero? Y si no hay una respuesta clara, lo más responsable es no meterlo. Porque un modelo con toneladas de información irrelevante no solo pesa más y tarda más: cuesta más, confunde más y funciona peor. Y si queremos que el BIM realmente cumpla su promesa, hay que empezar a modelar con cabeza.

Ahora sí, ve cerrando tu IFC, pasa el IDS y respira tranquilo. Nos vemos en el próximo TDH, donde puede que no seamos perfectos, pero al menos, intentamos que la información no nos explote en la cara.

Recursos citados en el episodio

• Pensar rápido, pensar despacio – Daniel Kahneman
• Autodesk Revit
• Graphisoft Archicad
• Blender
• BIMcollab ZOOM
• Bonsai
• Productivity Tools for Revit
• buildingSMART International
• ADIF – Administrador de Infraestructuras Ferroviarias
• FGV – Ferrocarrils de la Generalitat Valenciana