Mediciones y presupuestos en entornos BIM. Estructura de la información (parte 2)

                                                                                                   Actualizado a 15 de noviembre de 2021

Introducción

Uno de los debates más activos en el ámbito BIM es cómo debe ser la estructura de la información dentro de un modelo de datos. Cómo y con qué criterios debe establecerse esa estructura. Esta consideración es importante cuando hablamos de mediciones y presupuesto, ya que el documento que se genere debe tener una estructura de capítulos, subcapítulos y unidades de obra, para que que sea reconocible en nuestro ámbito de trabajo y que se base en unos estándares y referencias de aplicación común.

Estándares

Todos los estándares que existen en la actualidad sobre la estructura de la información de un modelo de datos son de iniciativa privada y carecen de una reglamentación que sea de obligado cumplimiento. La única aproximación legal a las mediciones de un proyecto arquitectónico está en el RD 1098/2001 de 12 de octubre del Reglamento General de la Ley de Contratos de las Administraciones Públicas. Allí, en el artículo 130 se establece que «El cálculo de las distintas unidades de obra se basará en la determinación de los costes directos e indirectos precisos para su ejecución…» Y pocas consideraciones más, que describen vagamente y de manera muy genérica cómo debe ser el documento de mediciones, presupuesto y certificación de un proyecto.

Lo más cercano a una referencia completa la tenemos en el único estándar que podríamos considerar de carácter público, aunque su origen y desarrollo sea una iniciativa privada, es el estándar IFC (Industry Foundation Classes) cuya difusión es abierta y de libre acceso.

Carátula de presentación del estándar IFC versión 4.1.0.0

Como explico con más detalle un poco más adelante, en la actualidad podríamos considerarnos un poco presos de la estructura de información propuesta por los software de modelado. Esto quiere decir que, al menos en un primer paso inicial, la información contenida en el modelo de datos se ordena según la configuración de sistema del software de modelado que corresponda. Estas configuraciones están blindadas internamente y no tenemos más remedio que jugar con ellas cuando extraemos los datos contenidos dentro del modelo.

El problema viene cuando descubrimos que esa estructura de datos no es la que habitualmente manejamos en nuestros documentos de presupuestos y mediciones. La consecuencia es que esta información hay que reordenarla según otros criterios. Ese proceso de reestructuración de la información es el que en mi opinión debilita en la actualidad el proceso de extracción de mediciones a partir de un modelo geométrico de datos.

Aunque a mucha gente todavía les cuesta entender, sobre todo a aquellos a los que podríamos llamar de la vieja escuela, si hablamos de BIM, tenemos que entender el proyecto de arquitectura como una gran base de datos. Hasta la geometría son datos que van a ser interpretados por una máquina. Por lo tanto, tenemos que darnos estrategias para gestionar de manera efectiva ese volumen de datos de manera que podamos sacar del modelo aquella información que de respuesta a una necesidad concreta. 

Los modelos BIM son datos que están para dar multitud de respuestas a necesidades. Fuente: Ofimática website

En el caso de las mediciones y presupuestos, va a ser fundamental asignar códigos a los elementos del modelo, como puertas, ventanas o muros, de manera que podamos relacionar esas entidades con una base de datos de referencia en la que se describa la unidad de obra con la actividad necesaria para ejecutar el elemento en cuestión, así como su precio unitario.

Ejemplo de asignación de un código a un elemento de un proyecto de arquitectura Fuente: elaboración propia

En este sentido, cabe destacar el esfuerzo realizado por la asociación FIE-BDC, producto de la asociación de diferentes fabricantes de software en España.  Aunque no es un estándar creado específicamente para entornos BIM, define un estándar abierto para el intercambio de datos entre diferentes plataformas de mediciones y presupuesto, materializado en el llamado archivo .bc3, cuya lectura es posible desde cualquiera de las plataformas que han colaborado en su desarrollo.

Estructura de la información tradicional: capítulos, subcapítulos y partidas

En España, el documento de mediciones y presupuesto se organiza tradicionalmente por capítulos, subcapítulos y unidades de obra o partidas presupuestarias. Esta organización del documento, que va desde conceptos generales a mas concretos, permite hacer una búsqueda por tesauro de las diferentes unidades de obra que definen un proyecto. 

Esta estructura general del documento también va a permitir aislar determinadas actividades de obra para obtener valores subtotales, porcentajes sobre el total o análisis de precios por subcontrata. Además, es tradicional organizar la estructura general de capítulos según una secuencia cronológica de obra. Esta estructura de documento por tanto va a permitir hacer un análisis financiero del proyecto con una fiabilidad bastante alta y que además se va a poder conectar con una planificación temporal al poder enlazar partidas presupuestarias con un hito temporal.

Capítulos

Los capítulos se corresponderían con el primer nivel de ordenación del documento. Normalmente los capítulos se crean con un criterio que agrupa unidades de obra pertenecientes a un mismo sistema del edificio y cuyas actividades podríamos considerar que son una especialidad profesional concreta.

Así pues, capítulos típicos de la medición de un proyecto arquitectónico podría ser Movimiento de tierras, Cimentaciones o Red horizontal de saneamiento. 

Las actividades ordenadas en los capítulos, pese a poder ser muy diversas, van a tener una serie de condiciones comunes y su ejecución será realizada por especialistas o profesionales en ese ámbito. 

Es tradicional también que la ordenación general de capítulos del documento de mediciones se corresponda con la planificación temporal de la obra, de manera que los capítulos iniciales serán los primeros que se ejecuten y los últimos, los que se ejecutan al final de la obra. Esta consideración no siempre es rigurosa, aunque es recomendable ajustar el orden de los capítulos a la secuencia temporal de la obra.

El listado general de capítulos puede ser diverso y dependerá de muchos factores, como la tipología de la obra (edificación, civil, rehabilitación…) su complejidad, el volumen presupuestario y cualquier otro criterio que el proyectista crea necesario introducir en el documento.

Ejemplo de relación de capítulos para un proyecto de vivienda unifamiliar. Fuente: elaboración propia

El gran objetivo de una organización, ya sea pública o privada debe o debería ser el estandarizar esta colección de capítulos en función de la tipología de proyectos y aplicarla siempre en los proyectos que desarrolle.

Subcapítulos

En un nivel más concreto de agrupación tendríamos los subcapítulos. Descolgando del capítulo principal, los subcapítulos definen tareas más concretas dentro del ámbito más general descrito en el capítulo. Este criterio de descomposición se puede llevar hasta el nivel que se decida, dependiendo sobre todo de la complejidad de la obra y también de los parciales que se quieran obtener. Podría darse el caso de generar subcapítulos atendiendo a las diferentes subcontratas que participan en una obra, facilitando así la obtención de subtotales y la posterior contratación de la obra.

Ejemplo de subcapítulos del capítulo Movimiento de Tierras extraídos de la base de precios PREOC. Fuente: PREOC

Ejemplo de relación de unidades de obra dentro del capítulo de Cimentación para un proyecto de vivienda unifamiliar. Fuente: elaboración propia

Generalmente las unidades de obra se extraen de una base de precios que se tenga disponible, como lo es la de base de precios de Centro o Guadalajara. Este listado de unidades es una muy buena base de partida ya que se describe con precisión como debe realizarse la unidad de obra en concreto, de que materiales esta compuesta, en qué condiciones deben colocarse, la calificación del operario que debe ejecutar la unidad, que criterios de medición deben aplicarse para su certificación y en realidad muchísimas otras condiciones que el proyectista crea que debe cumplir dicha unidad de obra o partida. Normalmente, en la propia descripción detallada de la unidad de obra se hace referencia a la normativa vigente que debe de cumplir el elemento o sistema descrito. 

Las unidades de obra se completan con un precio unitario, que variará en función de la unidad geométrica con la que se describa (m2, ml, m3, kg…). Dicho precio será consecuencia del llamado precio descompuesto en el que se analiza los tiempos que son necesarios para su ejecución, los materiales que lleva la unidad de medida y otros conceptos como los costes indirectos y los medios auxiliares o de seguridad. Asociado a la unidad de obra y completando los datos asociados, se informa de su medición, en la que se concreta cuantos elementos se sitúan en la obra y cuál es su ubicación en el espacio.

Ejemplo de descripción de una unidad de obra, en este caso un medio auxiliar del capítulo de Seguridad y Salud. Fuente: Research Gate

Estructura de la información a partir de archivos de autoría nativa. Revit

Como comentaba con anterioridad al hablar de la estructura de información de los modelos, hoy en día nos encontramos que al realizar el modelo geométrico y de datos de un proyecto de arquitectura en un software de modelado como es Revit, nos vemos en la obligación de gestionar una estructura de información que es inalterable.

Es la llamada configuración de sistema que, si nos centramos en Revit, ordena la información según un criterio establecido por el fabricante del software y que no podemos alterar. A continuación describo como Revit ordena  la información dentro del modelo de datos.

Categorías

En Revit, el sistema almacena la información, en un primer nivel de agrupación, en las llamadas categorías. Las categorías en Revit discriminan o clasifican los objetos atendiendo a su función concreta. Así pues, existen en Revit las categorías de Puertas, Ventanas, Muros o Suelos. Todos los objetos creados en Revit deben quedar ordenados en alguna de las categorías propuestas por lo que el modelador o proyectista tendrá que decidir para determinados elementos o familias, cual es la categoría que le corresponde, atendiendo a la función que cumple dicho elemento dentro del proyecto. Esta elección va a ser innegociable en las llamadas familias de sistema en las que la elección de la categoría a la que pertenecen esos elementos es de sistema. Esto sucede con suelos, muros, cubiertas, entre otras.

Listado de diferentes categorías en Revit dentro de la disciplina de Arquitectura. Fuente: Interfaz de Revit

Cuando queremos colocar un objeto dentro de nuestro modelo en Revit, tenemos que elegir cuál es la categoría, de entre el listado que se nos ofrece, donde queremos colocarlo. No existe otra opción. La única concesión que nos hace el sistema cuando no acabamos de estar seguros de la naturaleza del objeto es la posibilidad de ordenar el elemento en la categoría llamada Modelo genérico, que vendría a ser una especie de cajón de sastre o el poco recomendable capítulo llamado «Varios».

Cuando trabajamos con Revit resulta fundamental familiarizarse con las categorías, ya que buena parte de las acciones que se desarrollan en el modelo, como la gestión de visibilidad, filtros, etiquetados o asignación de parámetros, entre otras, se realizan por categoría. Podríamos concluir que, si quieres dominar Revit, debes tener un conocimiento profundo de sus categorías propuestas. Las categorías de Revit serían el equivalente a los capítulos del documento de mediciones y presupuesto.

Familias

El segundo nivel de agrupación de los objetos en Revit son las familias. Las familias son los objetos u elementos que constituyen nuestro modelo geométrico 3d del proyecto arquitectónico. Las familias en Revit, sea cual sea su naturaleza o función, deben quedar ordenadas dentro de una categoría de sistema. Esto sucede de manera interna en las llamadas familias de sistema. Al igual que sucede con las categorías, en Revit se incluyen una serie de familias que son de sistema, es decir, cuya nomenclatura o descripción es inalterable. Esta condición se aplica a los elementos básicos de un proyecto de arquitectura como son los suelos, muro o cubiertas.  Todos estos elementos se crean dentro de Revit como familias de sistema cuya denominación no podemos cambiar. Así pues, cuando queremos crear un muro en Revit, este debe ordenarse en cualquier de las tres que se nos ofrecen, esto es muro básico, muro apilado o muro cortina. 

Ejemplo de familias de sistema dentro de Revit. Fuente: Interfaz de Revit

Sin embargo, buena parte de las familias en Revit son de «libre» creación, en cuanto a su descripción o nomenclatura. Son las llamadas familias cargables o componentes. Cuando creamos una familia de este tipo en Revit, podemos elegir su nombre según nuestras necesidades o estándares, aunque cabe recordar que debe quedar clasificada en algunas de las categorías de sistema propuestas. Las familias en Revit serían el equivalente a los subcapítulos de un documento de mediciones.

Tipos

El tercer nivel de agrupación en Revit son los llamados tipos. Dentro de cada una de las familias en Revit vamos a tener la posibilidad, en este caso ilimitada, de crear tipos. Estas tipologías nos van a permitir tener, asociadas a las familias u objetos del proyecto, una colección o catálogo de objetos con diferentes propiedades. Por poner un ejemplo, dentro de la familia de puertas de madera vamos a tener la posibilidad de tener una colección de tipos con diferentes dimensiones, o tipos de apertura, color o cualquier otra propiedad específica del elemento. Esta capacidad de Revit es gracias a que los objetos son paramétricos y por tanto sus propiedades pueden variar de un tipo a otro. Los tipos en Revit serían el equivalente a las unidades de obra de un documento de mediciones.

Ejemplo de una familia de celosía con diferentes tipologías dentro de Revit. Fuente: elaboración propia

Tabla de equivalencia entre la estructura de información de Revit y el de un documento tradicional de mediciones. Fuente: elaboración propia

Tabla de equivalencia entre la estructura de información IFC y el de un documento tradicional de mediciones. Fuente: elaboración propia-

Criterios de ubicación IFC

Ordenación de las entidades de un modelo IFC según el edificio y nivel al que pertenecen. Fuente: elaboración propia

Para saber más…

• Ponencia de M. Luisa Collado López. Propuesta de estructura de elaboración de presupuestos de obras de construcción en España.
• Estándar FIE-BDC. Estándar abierto de Formato de intercambio de bases de datos de la construcción
• RD 1098/2001 de 12 de octubre del Reglamento General de la Ley de Contratos de las Administraciones Públicas. Real Decreto: Ley de Contratos de la Administración Pública.
• Base de precios Centro- Guadalajara. Base de precios de referencia en España creada por el Colegio de aparejadores de Guadalajara
• Criterios de la base de datos de construcción BEDEC. Estándar creado por el ITEC (Instituto de la Tecnologia de la Construcción de Cataluña) para la gestión de bases de datos de construcción.