La pregunta está mal planteada (y aun así hay que responderla)
“¿openBIM o nativo?” suena a elegir bando. Para un fabricante es una pregunta de canales de salida: cada formato es un envase de tu dato para una audiencia. La comparación honesta:
| IFC (abierto) | Nativo (Revit, Archicad…) | |
|---|---|---|
| Interoperabilidad | Universal, norma ISO | Solo su ecosistema |
| Verificación automática | Sí (IDS) | Limitada, propietaria |
| Longevidad | Décadas; no caduca con versiones | Atada al ciclo del software |
| Experiencia del proyectista | Correcta y mejorando | Óptima EN su software |
| Coste de mantener | Uno (si se genera del dato) | Uno POR software y versión |
| Riesgo estratégico | Ninguno estructural | Dependencia de un tercero |
La estrategia sensata (la que recomendamos siempre)
- IFC como base garantizada: todo el catálogo, con propiedades estándar (bSDD / ISO 23387). Es lo que pasa las validaciones y lo que no caduca.
- Nativos donde tu ICP concreto los pida: si tus prescriptores viven en un software, dales su formato — como cortesía comercial, no como única copia de la verdad.
- Todo generado desde el dato maestro. La regla que evita el desastre: los formatos son salidas; si un envase diverge, se regenera — nunca se edita a mano.
El anti-patrón es el inverso y lo vemos constantemente: el catálogo “vive” en archivos nativos hechos a mano, el IFC es una exportación ocasional y el dato diverge en silencio.
Dónde encaja BESCO
Exactamente en la regla 3: Sync mantiene el dato maestro y Channels genera las salidas — IFC siempre, nativos según tier — procesando client-side (la tecnología de ifcvieweronline.eu). Sin bandos: envases al servicio del dato, no al revés.
Fuentes
- Estándares abiertos de buildingSMART (IFC, IDS, bSDD) — technical.buildingsmart.org
- ISO 16739-1:2024 (IFC) e ISO 23387:2020 (plantillas de datos)