Memorias colaborativas

Objetivos

Asegurar la consistencia de un proyecto en sus principales entregables: Modelos/Planos, Memoria, Presupuesto.

Requisitos

Conocer las herramientas de trabajo colaborativo de la suite de Google o similares.

Introducción

Desde que incluímos la palabra BIM en nuestro vocabulario, hemos aprendido a utilizar softwares de modelado y trabajamos con ellos.

Tenemos formatos de intercambio de archivos porque existen multitud de programas con los que podemos trabajar.

Aparece el “entorno común de datos” (CDE en sus siglas en inglés), donde todos los agentes publican sus modelos y planos, y ya no existen copias o diferentes versiones de archivos, tenemos la información actualizada, y además todos usamos la misma.

Incluso se han desarrollado plataformas colaborativas en las que varios usuarios pueden trabajar con el mismo modelo simultáneamente.

Estamos orgullosos aplicando todas las dimensiones del BIM: extracción de planos, coordinación geométrica, planificación, mediciones, sostenibilidad, mantenimiento… Pero ¿qué ocurre con la Memoria del proyecto?

¿Qué herramientas de control están disponibles para asegurar que la información contenida en los modelos está descrita en una memoria?

Además, en obra, la descripción de las partidas del presupuesto es la que manda, por lo que tendremos que asegurar que partidas, memoria, modelo y planos vayan de la mano.

Hablar de BIM es entender que todas las partes que componen un proyecto están alineadas.

En Modelical nos vemos a menudo en la situación de coordinar a todos los colaboradores del proyecto y todos los documentos entregables del mismo, debido a que trabajar en BIM no es sólo modelar sino gestionar de manera eficiente toda la información que define un proyecto.

El papel del BIM Manager coge fuerza gracias al uso de herramientas y plataformas colaborativas.

Queremos compartir un flujo de trabajo muy sencillo pero muy eficaz que pusimos en marcha en un proyecto con más de 10 colaboradores, centralizado por el estudio de arquitectura, con más de 80 personas trabajando en el mismo.

Procedimiento

Todo va a girar en torno a una tabla de datos colaborativa en la nube, en nuestro caso Google Sheet.

Éste será el diccionario de nuestro proyecto, desde aquí se coordinarán modelo, memoria y presupuesto, pero se necesitarán herramientas de control para asegurar su actualización.

1. Trabajar bajo las plataformas colaborativas

A continuación se desarrolla y explica por pasos el siguiente esquema:

• Definir la estructura de la memoria colaborativa
• Asignar códigos a los capítulos
• Establecer codificación de elementos
• Asignar códigos a los elementos
• Creación de la tabla máster de coordinación
• Documentación en la nube
• Riesgos, consejos, precauciones

Definir la estructura de la memoria colaborativa

Un proyecto se cuenta a través de su memoria, por ello se ha de definir la estructura de la memoria. Un ejemplo de capítulos de una memoria de arquitectura sería el siguiente:

Asignar códigos a los capítulos

A lo largo del desarrollo del proyecto, se van incluyendo los sistemas constructivos que lo definen, clasificados en la estructura de la memoria. Es entonces, cuando hay que establecer prefijos que sirvan de codificación de los elementos que se encuentran bajo un mismo epígrafe, de manera que quedarán identificados y clasificados. Por ejemplo:

Establecer codificación de elementos

Una vez tenemos ya definidos los prefijos con los que serán codificados todos los elementos del proyecto, habrá que analizar caso a caso las necesidades de clasificación de los mismos.

Por ejemplo, los elementos divisorios (DV.) podrían enumerarse del 000 al 999 según el orden de creación, pero también podrían seguir una subclasificación según el material, añadiendo alguna letra, o asignando una serie de números. Por ejemplo:

DV.Y01 (Divisorias de yeso) DV.C01 (Divisorias cerámicas) etc.

En todo caso, la subclasificación corresponderá de nuevo a cómo se cuente en la memoria, para que los códigos sigan teniendo relación con la estructura de la misma.

Este código será el que aparezca en las leyendas de los planos, en el elemento modelado y también en la memoria y el presupuesto, cuando se explique, para poder identificarlo con facilidad.

Asignar códigos a los elementos

El siguiente paso sería asignar códigos a los elementos reales del proyecto, para ello, habrá que coordinarse además con el presupuesto.

¿Qué quiere decir esto? Pues bien, tenemos que tener muy claro cómo se van a medir los diferentes elementos para utilizar en el modelo la familia más adecuada o modelar con unas directrices determinadas, que hagan posible la extracción de datos en las unidades que la medición necesita.

Para ello, se necesita una buena comunicación con el responsable en mediciones y trabajar de manera conjunta desde etapas tempranas.

Si se acuerda una estrategia de modelado que contemple la extracción de mediciones, se puede simplificar mucho el trabajo. Así como se puede seguir una estrategia en cuanto a descripción de partidas, que de igual manera facilite el modelado.

Encontraremos 3 casuísticas básicas:

• Un elemento modelado, lleva un único código que corresponde con una partida del presupuesto en la que se incluye únicamente un elemento. EJ1: Se modela una silla, y en la partida se describe una silla.
• Un elemento modelado, lleva asociado un código que corresponde con una partida del presupuesto en la que se incluyen varios elementos. Ej2: Se modela una ventana y la partida incluye también la caja de persianas. Ej3: Se modela un muro y la partida incluye el ladrillo y el mortero de cemento. Hablamos entonces de sistema constructivo. Esta será la casuística más habitual.
• Un elemento o un sistema constructivo modelado, lleva asociados varios códigos que se corresponden con varias partidas del presupuesto. Ej4: Se modela un muro, donde el parámetro Type Mark se refiere al código que explica la composición del muro, por ejemplo de yeso, mientras que en un parámetro de ejemplar, llamémosle TM_Zócalo, se marca el código del tipo de zócalo que lleva según el diseño. Ej5: Se modela un plato de ducha, donde el parámetro Type Mark se refiere al plato de ducha, y otro parámetro, por ejemplo, TM_Accesorios, se refiere al grifo de la ducha. Cada código corresponde con una partida en el presupuesto, pero se obtienen de un elemento común, atendiendo cada uno a un parámetro determinado.

Creación de la tabla máster de coordinación

Una vez aclarados los sistemas de codificación y clasificación, pasamos a documentar la información, y es para ello que utilizamos la tabla máster de la que hablábamos anteriormente.

En ella aparecen, por filas, todos los sistemas constructivos del proyecto, que deberían aparecer en memoria, presupuesto y modelo. Un sistema constructivo corresponde con una partida, con una explicación en la memoria, con un elemento modelado y con un un código que lo identifica en todos los documentos, colocado en un parámetro a definir dentro del elemento modelado.

Para llevar un mejor control, clasificaremos por pestañas los diferentes epígrafes de la memoria, según su código, atendiendo al prefijo. EJ: Divisorias en una pestaña (DV.), puertas en otra(PT.), cortinas en otra(CC.), etc.

En las columnas, colocaremos los parámetros que consideremos necesarios para el entendimiento y la coordinación, que pueden ser clasificados en 4 grandes bloques: Elemento, Modelo, Presupuesto y Memoria. Teniendo actualizada y coordinada esta tabla, se podrá asegurar el éxito de la consistencia del proyecto.

Bloque elemento:

• Código: Será el código del proyecto del elemento, antes mencionado. Corresponderá con la etiqueta que aparece en los planos y las leyendas.
• Breve descripción: Necesario para dar literalidad a los códigos.

Bloque Modelo:

• Nombre del modelo: Aquí podemos escribir el nombre de los modelos en los que aparece este elemento. Será muy útil si tenemos un gran número de modelos, pero quizás innecesario si el proyecto tiene muy pocos modelos. Siempre que en una misma celda haya más de una información, deben ir con un separador, como puede ser “;” de cara a manipular posteriormente la información.
• Categoría del modelo: Se refiere a qué categoría de familia hay que buscar para encontrar este elemento, de cara a hacer una tabla de planificación con la categoría correcta. Como vimos anteriormente, puede que un elemento se codifique en un parámetro dentro de otro, que no tiene por qué corresponder con la categoría que se utilizaría si este elemento se modelase de forma independiente.

También se puede dar el caso de utilizar una categoría de modelado diferente al elemento en sí, por facilidad de modelado u otras ventajas. Ej: modelar un techo de lamas como una cubierta, para tener la geometría de cada lama.

• Parámetro del modelo: El código del proyecto deberá ponerse en un parámetro determinado dentro del elemento modelado. Es posible que un mismo elemento tenga varios códigos asociados. Colocando debidamente esta información en la tabla máster, no quedará ningún vacío de medición, ya que todas las partidas deben tener asociado un código que debemos encontrar en algún parámetro dentro de las familias de los modelos.

Bloque Presupuesto:

• Código del presupuesto: Normalmente los presupuestos siguen una codificación según la base de datos de la que estén leyendo las partidas. Para tener conectados ambos códigos, éste aparecerá en la tabla, además, es bastante usual que se necesite volcar este código de nuevo al modelo, por lo que la tabla además, es el medio de intercambio de información de las diferentes codificaciones o clasificaciones que deban aparecer. 
• Unidades de medición: Es importante tener esto claro de cara a la descripción y modelado, por tanto es un requisito exigido a las familias, que puedan ser contabilizadas conforme a la unidad de medición.

        Bloque Memoria:

• Título en la memoria: De cara a identificar en la memoria de qué sistema constructivo de la tabla se está hablando. Se aconseja, además, poner el código del elemento en el mismo título.
• Capítulo de la memoria: Se indicará aquí el capítulo de la memoria donde hay que buscar el elemento, bajo el título antes mencionado.

Estos títulos se consideran básicos para la correcta definición y organización del elemento, pero pueden ser añadidos cuantos se consideren necesarios, tanto para su definición como para su control. Por ejemplo, añadir una columna de comentarios es muy útil para dar información adicional.

Documentación en la nube

Así como los modelos pueden estar accesibles utilizando plataformas colaborativas, para la memoria se necesita un sistema similar.

Nuestra propuesta es un documento de texto en la nube. Es práctico tener tantos documentos de texto como pestañas en la tabla máster, de esta manera, habrá un orden más que evidente del proyecto. Para la entrega final, bastará con descargar y unir todos los fragmentos de memoria para conseguir un documento numerado.

Para el equipo de realización de presupuestos, será interesante poder acceder a las memorias para tener la descripción de la partida completamente alineada con lo descrito por el proyectista.

Cuantas más personas trabajen en el proyecto, más sentido tiene este flujo de trabajo.

Riesgos, consejos, precauciones

Tanto la tabla como las memorias, al ser colaborativas, corren el riesgo de ser modificadas por usuarios que no deben, por lo que debemos establecer permisos de edición.

Nuestra recomendación es:

• Para la tabla, establecer permisos por pestañas, ya que en proyectos grandes, están más definidas las parcelas de trabajo de cada usuario. Si se trata de un proyecto en el que todos los proyectistas trabajan de manera transversal, no tiene sentido gestionar permisos.
• Para las memorias, establecer permisos de edición, comentar o sugerir por documento, en función del rol de cada miembro del proyecto. Para el equipo de proyectos, poder trabajar, corregir, comentar simultáneamente un único documento será una comodidad que agiliza el trabajo.

Una ventaja de Google Doc y Google Sheet te permite ver un histórico de edición por celda/palabra, indicando el usuario, y además, rescatar versiones anteriores en cualquier momento. Por lo que es más seguro trabajar bajo este tipo de base de datos en la nube que en un servidor local.

2. Herramientas de control

Con estos pasos, ya estaría montado el sistema que articula y coordina los entregables del proyecto, pero al final los datos de esta tabla se rellenan a mano, por lo que no podemos confiar en que estén realmente coordinados con la información que contienen las memorias, los modelos y el presupuesto.

Lo que no se debe hacer

Para poder procesar y analizar datos, son incompatibles algunas técnicas, como serían agrupaciones de celdas, sombreados manuales, colores, tipos de letra… Ya que todas estas posibilidades sólo atienden al formato, pero no permiten la gestión de la información mediante filtros, si no que tendría que hacerse un control de manera visual manualmente, y eso va en contra de lo que estamos buscando.

Por ejemplo, si un elemento está obsoleto, lo correcto es generar una nueva columna y rellenarla indicando que lo está, de este modo, siempre podremos filtrar los elementos que se encuentran vigentes.

Hacer un tachado, sombreado, etc. del texto, no será una buena práctica y hará que la tabla no pueda utilizarse por otros programas de procesamiento de datos.

Lo que sí se debe hacer

Para llevar el control de los datos, necesitamos de herramientas de control.

Existen múltiples recursos, pero nosotros daremos una serie de consejos para poder hacer este análisis sin necesidad de desarrollar un sistema muy complejo.

• Para comprobar la memoria

En la memoria, lo que necesitaríamos saber es si concuerdan los elementos explicados con los elementos listados en la tabla máster.

Si se utiliza Google Doc para la creación de la memoria, una buena práctica que permitirá luego analizar y listar los elementos que hay descritos en la misma, es la de utilizar los estilos de texto “encabezado”, ya que puedes generar listados automáticamente de todos los encabezados, y por lo tanto será posible comparar el listado de la tabla máster con el listado de elementos descritos en la memoria.

• Para comprobar el presupuesto

Todos los programas de elaboración de mediciones y presupuestos tienen la opción de exportar a formato hoja de cálculo, por lo que comparar una hoja de cálculo con otra, no tendría mayor dificultad.

• Para comprobar los modelos

Del mismo modo que en los programas de mediciones, en los softwares de modelado se pueden obtener tablas de planificación con la información que necesitemos. Es cuestión de hacer las tablas apropiadas, lo cual es sencillo conociendo las categorías y parámetros a listar dentro de cada uno de los modelos, información que se extrae directamente de la tabla máster.

3. Advertencias

Este flujo de trabajo, como dijimos en la introducción, ha sido probado en un proyecto real, liderado desde el estudio de arquitectura. Queremos compartir también los principales problemas que encontramos, ya que hay que tenerlos en cuenta desde el principio.

• En primer lugar, y aunque parezca obvio, disponer de licencias de las plataformas colaborativas propuestas. No podemos olvidar que cada empresa trabaja con unos softwares y plataformas determinadas, por lo que exigir múltiples licencias para participar en un proyecto, puede ser contraproducente económicamente hablando. También en términos de formación, no todo el mundo sabe usar todas las plataformas disponibles en el mercado. Es muy importante acordar qué se usará con antelación, pues nos podemos encontrar con que algún colaborador no tenga acceso a las mismas.

En nuestro caso, cada empresa tenía una cuenta genérica de google para participar en los documentos colaborativos, de tal manera que no se puede saber qué persona en concreto modifica los archivos, pero gestionar los permisos de edición se simplifica y los usuarios dados de alta se reducen. En cuanto a la formación, al utilizarse unas herramientas sencillas de texto y hojas de cálculo, sí que se necesitó un mínimo de soporte, pero todos los participantes ya las conocían con anterioridad.

• En segundo lugar, la comunicación. También es una advertencia común en todos los proyectos. Pero se necesita tener claro cuál será el medio y la forma oficial para implementar cambios. Debido a que la idea de este flujo de trabajo es tener coordinados modelos, memorias y presupuestos, cualquier variación de la descripción de un sistema constructivo, deberá ser debidamente notificada, independientemente de nuestras herramientas de control.

En nuestro caso, utilizamos para la tabla una columna de comentarios, y la problemática fue tener actualizados los mismos.

También hicimos uso de colores de texto distintos en función del momento de las modificaciones.

Cualquiera de estas opciones, debe ser un sistema de comunicación temporal, y resetearse en las entregas oficiales, para evitar tener los documentos sucios, con comentarios obsoletos al estar ya implementados, o múltiples colores en las memorias.

No obstante, sólo con las herramientas colaborativas no bastó, como siempre, mails y reuniones periódicas son necesarias, eso sí, cuidando la mesura, el registro y la correcta documentación de los temas tratados.

• Y en tercer lugar, es muy importante que todos los participantes del proyecto conozcan este sistema de trabajo, y tengan disponible la información. El trabajo realizado, independientemente del rol de la persona que lo hace, debe ir alineado con la documentación común.

Ejemplos:

1. Si un modelador no tiene acceso a la tabla máster, no sabrá por ejemplo que la persiana se mide desde la familia de la ventana, por lo que, no podrá crear correctamente esa familia y tampoco podrá codificarla según su tipo.
2. Si un coordinador de instalaciones, detecta que necesita haber una tapa de registro en una sala, y añade en la memoria la descripción de dicha tapa, pero no la lleva al modelo, ni la codifica, tampoco aparecerá en el presupuesto.
3. Si un proyectista se dedica a especificar elementos constructivos, y cambia la descripción, de tal manera, que esto afecte a las familias del modelo, pero no avisa de ello, por desconocimiento, de nuevo el sistema no estará funcionando según lo esperado y estará descoordinado.

Es decir, todos deben ser conscientes de que todo sistema que aparezca nuevo, desaparezca o se modifique, debe solucionarse en todos los documentos asociados y preocuparse de que así sea, por lo que la información debe estar disponible para todo el mundo independientemente del permiso de edición que se tenga.

Resumen

Tener coordinada la información de la memoria, planos y presupuesto es posible y es sencillo utilizando herramientas de trabajo colaborativo.

Tener una tabla máster, permitirá tener tanto al Project Manager como a todo el equipo de producción, una idea muy visual del desarrollo del proyecto y control de la información del mismo.

Es importante utilizar estas herramientas de manera eficaz, haciendo una buena recopilación de datos y utilizando automatizaciones.

Autora: Cristina Caro