- Esta es la segunda parte del episodio 058 AAPP.
- Si no lo has escuchado, para este, y escúchalo primero.
Segunda pregunta del millón ¿Se pueden pedir formatos cerrados?
- Una vez superado el debate sobre si se puede pedir BIM, surge el tema de los formatos.
- Pero para responder a esto tenemos que hablar de principios.
Los 2 principios clave
- Los principios son "normas no escritas" pero que se tienen en cuenta a la hora de redactar una ley. De hecho en algunas leyes si que aparecen de forma explícita estos principios, pero no hay una ley de referencia cuyo objetivo sea desarrollar un principio en sí.
- En su día publique 3 post sobre el tema de las licitaciones públicas, y muchos de los argumentos que daba sigo pensando que son válidos, pero en la parte de los principios he aprendido que estaba equivocado.
- Uno de los argumentos para defender que las AAPP podían pedir formatos cerrados, se basaba en que los principios no tiene la misma importancia que las leyes, y que en cualquier caso, había principios que entraban en conflicto, como el de neutralidad tecnológica vs Eficiencia o vs Vinculación tecnológica, y que las AAPP podía usar el que más les interesara en cada caso.
- Ahora sé que los principios están mucho más presentes en las leyes de lo que parece a primera vista, y no se puede usar el que más nos interese en cada caso.
Neutralidad tecnológica
- Este principio dice que se deben usar estándares abiertos y de forma complementaria estándares cerrados pero que sean de uso generalizado por la ciudadanía.
- No confundir con el principio de no discriminación, que no es el hecho de poder acceder a la información, sino de poner requisitos que sólo están disponibles para algunos licitadores.
- El de no discriminación es el principio que cumplimos simplemente poniendo la frase "o similiar" al lado de todos requisitos concretos.
- Neutralidad es que similiar o no, debe ser accesible con independencia de la tecnología usada.
- Por ejemplo, podríamos pedir que se trabaje con el modelador Revit o similar (no discriminación), pero el formato de entrega principal debería seguir siendo IFC (neutralidad tecnológica).
- Alguien podría estar pensando que el principio de neutralidad tecnológica también obligaría a las administraciones que son diseñadoras/gestoras a trabajar internamente con estándares abiertos.
- Pero el RD 4/2010 no habla explícitamente del trabajo interno de las AAPP, y en cualquier caso dice:
- "En las relaciones con los ciudadanos y con otras Administraciones públicas, el uso en exclusiva de un estándar no abierto sin que se ofrezca una alternativa basada en un estándar abierto se limitará a aquellas circunstancias en las que no se disponga de un estándar abierto que satisfaga la funcionalidad satisfecha por el estándar no abierto en cuestión y sólo mientras dicha disponibilidad no se produzca."
Vinculación tecnológica
- Este principio permite saltarse el principio de no discriminación, cuando:
- Estamos hablando de un producto o bien para propio consumo de la administración.
- Y la administración ya tiene un producto o bien previo para su propio consumo, con el que debe ser compatible.
- Ejemplo:
- La primera vez que el congreso de los diputados, licitó para autoabastecerse de teléfonos móviles, no dijo que marca de teléfono quería, para cumplir con el principio de no discriminación.
- Pero luego, al ganar un licitador que les proporcionó iphones, en una segunda licitación para desarrollar aplicaciones, podían usar el principio de vinculación tecnológica para pedir que las apps tenían que ser para sistemas IOS, aunque esto discriminara a las empresas que desarrollen en exclusiva para android.
- El iphone es un producto o bien físico, las app son un producto o bien digital.
¿Entonces qué?
- Para cumplir con el principio de neutralidad tecnológica:
- Está claro que en BIM ahora mismo formatos abiertos tenemos el IFC.
- Garantiza que todo el mundo puede acceder a la información con el software BIM que quiera, incluso un visor gratuito.
- Y además, aunque todas las casas de software descataloguen sus soluciones, siempre podremos desarrollar nuestro propio visor aunque hayan pasado 50 años.
- De forma complementaria podríamos pedir formatos cerrados, siempre que estén muy extendido su uso. Aquí todos estamos pensando en el formato .RVT de Revit, pero hasta que Revit no tenga las mismas cuotas de mercado que AutoCAD (que pasará), no podemos pedirlo.
- He insisto, no es por discriminación de los que usen archicad, por ejemplo, es por acceso libre a la información.
- Esto a la administración con rol de promotora, le basta y le sobra.
- El proyecto y la obra se puede hacer bajo metodología BIM, pero los entregables van a seguir siendo .pdf, .dwg y ahora de regalo un .ifc.
- Para tareas de control y revisión, no necesitan modelos nativos, casi ni necesitan el ifc tampoco.
- Y posiblemente, lo mejor sería definir en los pliegos de las licitaciones, cómo queremos que se trabaje, metodología BIM, y olvidarnos un poco de los entregables.
- El objetivo no es tener un entregable 3D, es que el proyecto se haga de forma eficiente.
- Otro debate distinto es si se puede hacer metodología BIM colaborativa licitando el diseño por un lado, la construcción por otro y el mantenimiento por otro.
- Pero siempre nos quedará el "little BIM" o BIM level 1 de los Ingleses.
- También licitaciones de diseño y construcción.
El problema viene con las AAPP diseñadoras/gestoras
- El hecho de que la administración en cuestión haya desarrollado internamente el proyecto entero, o el proyecto básico, no supone un problema.
- Crea la licitación compartiendo un IFC, y luego los licitadores que sean listos, contactarán de forma extraoficial con los técnicos de la administración para que les pasen el archivo nativo.
- Que nadie se ruborice, porque esto se ha hecho siempre con los planos presupuestos, que se entregan en pdf y bc3, pero luego todos llaman para que les pasen los .dwg y .prestobra.
- Pero como muchas (por no decir todas) de estas administraciones van a ser las que luego gestionen y mantengan ese edificio o infraestructura, les interesa mucho que además de que se les entregue el edificio terminado, se el entregue también el edificio virtual terminado, gemelo digital como lo están llamando ahora.
- Para tareas de reformas y mantenimiento, los técnicos de la administración necesitan formatos nativos editables compatibles con el software que ellos hayan comprado.
- Es decir, que si el departamento de mantenimiento de la guardia civil o el de la universidad Complutense, o el de Correos, o el de la Fábrica de Moneda, usan Revit para diseñar y documentar sus pequeñas reformas y tareas de mantenimiento, necesitan que ese gemelo digital esté en formato .rvt de Revit.
- Pero el principio de neutralidad tecnológica nos impide pedir .rvt como formato complementario, porque no está suficientemente extendido.
- Y no podemos usar el principio de vinculación tecnológica, porque el producto o bien objeto de la licitación es un edificio real, y este no tiene ningún problema de incompatibilidad con nada.
- Lo único que les queda a las administraciones que quieren aprovechar la licitación de servicios de proyecto o concesión de obras, para llevarse un gemelo digital gratis (completamente lícito, y que todos los clientes privados hacen), es pedir el IFC y el formato nativo sin especificar ninguno en concreto, y cruzar los dedos para que el que gane la licitación use Revit.
- En realidad esto es un problema menor, porque en el caso de España, aunque no hay datos oficiales, si que las casas de software tienen sus estudios de mercado, y de cuando estaba en Asidek, manejabamos el dato, de que Revit supone el 89% de los modeladores de arquitectura, Archicad el 10% y 1% el resto.
- Así que en 9 de cada 10 licitaciones públicas, la administración conseguiría su gemelo digital en formato nativo editable .rvt sin pedirlo explícitamente y cumpliendo la ley.
- En Reino Unido, que si tenemos una encuesta anual seria, Revit está en el 63% (incluyendo también MEP), Archicad en el 20%, y el 17% en el resto.
Cuando el modelo es el producto
- Si la administración tiene la mala suerte de que al final nos dan un gemelo digital perfectamente elaborado, pero en un formato nativo distinto al que necesitamos, tenemos dos opciones:
- Contratar a dedo (piden tres ofertas, como las empresas privadas) a un proveedor que le haga el modelo en el formato específico que ellos necesiten, siempre que les cueste menos de 15.000€, que es el límite para contratar sin licitar.
- Si fueran más de 15.000€, pueden dividirlo por lotes, por ejemplo una empresa que haga la arquitectura y estructura y otra las instalaciones, o la misma empresa, pero el servicio de escaneado en un contrato y el de modelado en otro.
- Antes había una limitación de 15.000€ al año por proveedor, ya no.
- Enfocar el gemelo digital como un producto o bien para el propio consumo de la administración, y entonces utilizar el principio de vinculación tecnológica, para pedir que el producto debe ser compatible con el software de modelado que la administración tenga.
- Revit sería el iphone, y pedir un rvt sería pedir apps para IOS.
- En el caso de pedir un modelo del estado actual, típico escaneado más modelado, si el edificio es pequeño con 15.000€ en servicios vale.
Conclusiones
- En España, las AAPP pueden pedir BIM.
- Pueden pedir que se trabaje en Revit o similar (pero decir esto y nada es lo mismo).
- Pero no pueden pedir formatos cerrados concretos que no estén generalizados. Pueden pedir IFC más nativo, a sabiendas de que en el 90% de los casos el nativo será Revit.
- Para el otro 10% de los casos, pagar a parte por un modelo nativo, mediante un contrato menor, que no necesite licitación. O si es algo muy grande, argumentando vinculación tecnológica porque el "gemelo digital es un producto de uso interno de la administración para labores de operación y mantenimiento".
Obsesión por los entregables
- Con las posibilidades de las leyes actuales, las AAPP deberían centrarse en pedir que se trabaje en BIM y fomentar las licitaciones de diseño+construcción.
- 0 interferencias en fase de proyecto.
- Mediciones directas del modelo.
- Establecer un CDE.
- Etc.
- Y luego, si esa administración se encarga de la operación y mantenimiento, y sólo si está preparada para sacarle partido a un gemelo digital, entonces preocuparse porque al final de la obra, le entreguen el "3D" con la información.
Cambios necesarios
- A medida que más administraciones con funciones internas de operación y mantenimiento, tengan implantado sistemas de Gestión de activos empresariales y/o Sistema de gestión integrada del espacio de trabajo, tener una copia virtual del edificio será más crítico.
- Y pasará una de estas 3 cosas:
- Cambiarán las leyes para que en una licitación de obra se establezca que la entrega del edificio virtual (en nativo y editable) es tan importante como la del edificio físico.
- Y por lo tanto poder pedir formatos concretos por vinculación tecnológica.
- O cambiará el mercado y aparecerá un formato abierto y editable.
- Y no me refiero a editar un IFC con el bloc de notas o con el visor de ACCA, https://www.accasoftware.com/es/visor-ifc
- Elementos paramétricos, producción de planos, opciones de diseño, fórmulas, tablas, etc.
- O cambiará el mercado y el formato .rvt será "hackeado" como pasó en su día con el .dwg, y todos los software podrán guardar en .rvt.
- Esto ya está pasando: Open Design Alliance tiene un SDK para trabajar con archivos .rvt y .rfa.
- Lo comentamos en el episodio 049 Noticias diciembre 2019.
- De las 3 opciones, yo tengo clara la que va a llegar primero.
- Pero lo que no puede ser es que la administración, osea todos nosotros, paguemos por un proyecto en BIM y luego volvamos a pagar por un modelo.
¿Quieres escuchar otro episodio? Los tienes todos en la sección de Podcast de esta web.
AVISO: Este post es sólo un apoyo al audio del podcast. Leerlo de forma independiente podría llevar a conclusiones incompletas o incluso opuestas a las que se quieren transmitir.