La semana pasada tuve la inmensa alegría de conversar con un antiguo compañero con el que compartí momentos profesionales y personales inolvidables. Una vez puestos al día sobre lo importante, comenzamos a hablar de nuestros trabajos, y ahí fue cuando me comentó que estaba metido en esto del BIM. ¡Todo un valiente en la administración… que falta hacen!, pensé.
Mi compañero mostraba, por una parte, la emoción de estar involucrado en algo novedoso como lo es BIM, pero acabó confesándome la tremenda dificultad que tenía para ponerse de acuerdo con el equipo de proyecto en muchas cuestiones que creía importantes.
Después de escucharle durante un rato, me di cuenta de que estaba enredado con asuntos complejos, pero que no tenía resueltas las cuestiones más básicas e imprescindibles para enmarcar la gestión de un “proyecto BIM”. Efectivamente, después de unas pocas preguntas, no tuve otra ocurrencia que decirle: “¡tenemos que hablar…!”
En este post trataré precisamente de anticipar esta conversación pendiente. Voy a comentar algunas de las trampas en las que caemos cuando empezamos en esto del BIM y los pasos previos que todo director de proyecto debe dar antes de enfrentarse a las complejidades de las herramientas que pueden utilizarse en BIM. Por último, veremos algunas opciones de apoyo que podemos elegir para ejercer nuestra labor de dirección en este tipo de proyectos.
BIM etapa de madurez 1. Por donde se debiera comenzar
En la norma UNE-EN ISO 19650-1 se definen tres etapas de madurez aplicables a la gestión BIM de proyectos. La etapa 1 corresponde a la gestión de la información de un proyecto en la que son de aplicación parcial las normas UNE-EN ISO 19650-1 y la UNE-EN ISO 19650-2. Se emplean datos estructurados y no estructurados, y la gestión de la documentación y de la información se realiza mediante un entorno común de datos. La etapa de madurez 2 se diferencia de la 1 en que son de aplicación la totalidad de las normas ISO mencionadas y se utilizan modelos de información federados.
Como siempre, os planteo la necesidad de entender en profundidad los términos empleados. En el post 3 ya he comentado lo que es un dato estructurado y no estructurado, pero ¿sabemos lo que es un entorno común de datos?, ¿y un modelo federado?
A nadie que esté aprendiendo a tocar un instrumento se le ocurriría incorporarse a una orquesta sinfónica sin haber tocado en solitario o con grupos reducidos durante algún tiempo. ¿Por qué, entonces, todos queremos empezar a trabajar en BIM en la etapa de madurez 2 y con modelos digitales complejos?, o dicho de otro modo, ¿por qué empezamos la casa por el tejado?
Como la diferencia entre la etapa 1 y la 2 estriba principalmente en el empleo de modelos federados, vamos a entrar en detalles sobre este concepto.
El rincón del diccionario
Para comprender las normas y los estándares, antes, ineludiblemente, debemos clarificar su terminología. (De hecho, creo que la visita a este rincón va a ser un clásico de todas las entradas de este blog).
En este caso, trataremos de desentrañar la definición de modelo federado de la norma UNE-EN ISO 19650-1. Dice esta norma: la federación es la “creación de un modelo de información compuesto por contenedores de información independientes”…esto es como la canción “Círculos viciosos” de Sabina, en la que iba concatenando preguntas. Nosotros diríamos también en este caso: ¿y que es un modelo de información?
Un modelo de información es un “conjunto de contenedores de información estructurada o no estructurada”… Y Sabina añadiría: ¿y qué es un contenedor de información?
Un contenedor de información es un “conjunto de información persistente y recuperable desde un archivo, sistema o aplicación de almacenamiento jerarquizado”. Y aclara la norma que se puede tratar de “un subdirectorio, un archivo de información (que incluye modelo, documento, tabla, programación […]”.
Parece muy claro que un contenedor de información no se refiere siempre a un modelo digital, aunque un modelo digital sea siempre un contenedor de información. Por lo tanto, un modelo federado puede estar formado por contenedores que no tengan nada que ver con el “gemelo digital” que tanto nos cautiva. Importante, ¿verdad?
No hay BIM si no definimos las necesidades (requisitos) de información
Podemos gestionar un proyecto BIM con modelos digitales o sin modelos digitales, pero nunca sin definir los requisitos de información. Es más, el uso de los modelos digitales es un servicio contratable, pero la definición de los diferentes requisitos de información (PIR, AIR, EIR) es una tarea específica del director del proyecto, difícil de delegar y de contratar. Con ellos debe satisfacer las necesidades de información de su organización y de la propia gestión del proyecto, atendiendo a todas las fases de su ciclo de vida: desarrollo y operación.
Aunque ya lo hemos tratado en otro post, es importante recordar que un requisito de información (entiéndase, necesidades de información) equivale a especificar qué información necesita el proyecto (ya sea existente o que deba generase como parte de sus actividades), cómo producirla, quién debe desarrollarla, a quien va dirigida, cuándo debe producirse y de qué información depende.
Estas preguntas nos ponen delante de un espejo que nos produce vértigo, que, como mi amigo, lo podemos achacar al desconocimiento de los recovecos de la producción digital, a lo difícil que son estas nuevas tendencias, etc. Sin embargo, en mi opinión, la verdadera causa del desasosiego es que no estamos habituados a planificar la gestión de la información de los proyectos, que es un ingrediente fundamental para su gestión. Ya lo era antes de la aparición de BIM, pero ahora resulta imprescindible.
Recordemos que los requisitos de información de un proyecto se pueden dividir entre los que cumplimentará la propia organización y los que serán objeto de una o varias contrataciones. Éstos se denominan requisitos de intercambio de información (EIR), que pueden ser completados en parte por los contratistas en su plan de ejecución BIM, pero su definición se incluye en las responsabilidades de la dirección del proyecto.
Una aproximación a la definición los requisitos de información y a los de intercambio de información
La primera acción para establecer los requisitos de información de un proyecto es hacer una lista con todos los documentos que se vayan a necesitar en cada una de sus fases. Si queremos emplear las normas BIM, tenemos que cumplimentar esta lista para las fases de desarrollo y para la de operación del activo. Las fases de desarrollo incluyen las de diseño y la de construcción. Habrá documentos que pertenecerán a todas las fases (con diferente información o grado de detalle) y otros que son exclusivos de una o de varias.
Además de anticipar la información de cada fase, también debemos cumplimentar el grado de detalle que se precisa en cada momento.
Pongamos varios ejemplos:
Un documento del tipo “Plano topográfico” existirá desde la fase de anteproyecto, seguirá empleándose en la de diseño constructivo y en la obra, y será útil en la fase de operación. En cada caso, su contenido irá variando por la aparición de nuevos datos (cambios por el movimiento de tierras) o por el grado de detalle que se incorpore para cada fase, en función del uso necesario. Importante: será el mismo documento y se denominará siempre igual. Lo distinguiremos por sus metadatos, algo de lo que hablaremos en futuros posts.
El “Acta de comprobación replanteo de la obra”, por el contrario, está asociado exclusivamente a la fase de obra y no se necesita para la fase de operación (nótese que este documento, muy importante en los proyectos de la administración, no procede de un modelo digital).
El “Plan de explotación” es propio de la fase de operación del activo, pero utiliza información generada en las fases anteriores (los planos de obra civil, pero simplificados, las características de los equipos electromecánicos, etc). Empleará algunos de los documentos utilizados en obra, pero sin la información de detalle que fue necesaria para la construcción.
En los proyectos en los que estoy involucrado, la planificación inicial de la documentación requiere definir aproximadamente doscientos cincuenta documentos, que en las fases siguientes se despliegan, creciendo en número y en el detalle de la información contenida. Por ejemplo, al comienzo necesitamos el documento “Planos de obra civil” (es uno de los doscientos cincuenta a los que me refería antes), pero a medida que avanzamos en el diseño, vamos desdoblando este documento para tener la información necesaria en cada fase y creciendo su número.
Algunas recomendaciones para la planificación de la información
Para cubrir esta etapa tan relevante no se necesita una herramienta sofisticada: basta con una hoja Excel. Sin embargo, si no tenemos un esquema de organización, un sistema lógico donde situar los documentos a medida que los identifiquemos, nos desorientaremos con facilidad durante el proceso y, lo que es más grave, nos costará más compartirlo con los demás participantes.
Una opción de clasificación que me ha parecido interesante, y que comparto con vosotros, es emplear los procesos de nuestro sistema de gestión y los de dirección de proyectos y obras para asociar cada documento con el proceso donde se produce o con alguno en los que se emplea más frecuentemente como entrada. Por cierto, no olvidaros de nombrar cada documento y los de los archivos asociados. Todos los participantes en el proyecto deben utilizarlos.
Para los que no dispongais de este marco organizativo os hago el siguiente resumen urgente:
- Los trabajos de dirección de proyectos y obras se definen mediante procesos que se organizan en grupos de procesos y áreas de conocimiento.
- Los grupos de procesos se refieren a la clasificación según sean de inicio (los que configuran el proyecto), planificación, ejecución (los que son necesarios para la aplicación de lo planificado), de control (comparan lo ejecutado con lo planificado y proponen cambios) y los de cierre (con un objeto algo más amplio que un simple as-built).
- Las áreas de conocimiento agrupan los procesos según las materias objeto de gestión: alcance, coste, cronograma, calidad, medio ambiente, seguridad y salud, contratación, riesgos, interesados, etc. Estas áreas se coordinan en la de integración, que incluye los procesos a cargo del director del proyecto, del project manager.
Pues nada, si entendemos lo anterior, no hay más que ponerse manos a la obra sabiendo que no hay solución perfecta a la organización de los documentos, ni aún aplicando el esquema conceptual anterior, aunque éste aporta una lógica a las decisiones que supera a las basadas en el gusto o intuición particular.
En esta descomposición de documentos deben figurar todos lo necesarios, con independencia de quien los genere. No hay documentos de asistencia técnica o de contratista o de la organización, por ejemplo. El enfoque más correcto es pensar que incluimos los documentos que necesita el proyecto y que el subconjunto que asignemos a una contratación (los que llamamos requisitos de intercambio de información) son simplemente una parte de nuestro árbol de desglose.
Por último, he de recordaros que no es necesario hacer este trabajo para cada proyecto. Cada organización debiera tener este desglose de información como parte de los estándares disponibles, como un activo de la propia organización.
¿Y si contrato un BIM Project?
Esta es una opción que nos ha pasado a todos por la cabeza cuando empezamos a trabajar en esto. Ya expliqué en un post anterior cuál es la diferencia entre un Director de proyecto y un Project manager. ¿Sabemos cuál es la función de un BIM manager y en qué se diferencia de un Project manager?
Un BIM manager es sencillamente el responsable de gestionar una de las áreas de conocimiento de las que mencionamos anteriormente, en concreto, se encarga de gestionar la información: participa en la planificación de la información, en la ejecución de lo planificado, en su control y en su cierre. Por muy complicada que sea esta gestión, esta enfocada estrictamente a la información.
Es claro, entonces, que el BIM manager no sustituye la labor del director del proyecto, del mismo modo que no lo hace un “Contract manager” (figura que también os sonará) si lo incorporamos al equipo de proyecto para gestionar los contratos.
Además, la gestión de un proyecto se ve de distinta forma desde la perspectiva del contratista que desde la dirección de obra, sencillamente porque son proyectos diferentes, puesto que tienen objetivos distintos, aunque compartan el producto resultante.
Por lo tanto, la gestión BIM del promotor y de la dirección de obra son complementarias y diferentes: la dirección del proyecto u obra gestiona la información definiendo requisitos y validando su cumplimiento, una vez generada la información; un contratista, lo hace planificando el cumplimiento de los requisitos mediante un plan de ejecución BIM y produciendo la información de su contrato (empleando quizá modelos sofisticados) y la información exigida de su propio funcionamiento (contratos, información laboral, etc).
Contratar un BIM manager para organizar un proyecto u obra tiene grandes probabilidades de convertirse en un fracaso. El mercado ofrece principalmente modeladores, grandes expertos en manejo de programas especializados que pueden haber adquirido algo de formación en la gestión de la información general, pero que normalmente desconocen las disciplinas de dirección de proyectos y no disponen de metodologías necesarias para ese fin.
Por ejemplo, es normal que solo un fracción de los planos de un proyecto provengan de un modelo digital (por ejemplo, un 60 %) . ¿Cómo se gestionan los demás planos?, ¿y los demás documentos? Pues sobre estas cuestiones, poca ayuda podemos esperar actualmente del mercado, ya que está orientado principalmente a las técnicas de la modelación y no a las necesidades del enfoque de la dirección de los proyectos. Y es lógico, ya que la producción de la información digital recaerá en ellos, en el sector privado.
Conclusiones
Los directores de proyectos y obra nos perdemos a las primeras de cambio en el mundo BIM porque no acabamos de entender cuál es nuestra función y no vemos la diferencia con la de las partes contratadas, que son las responsables de producir la información empleando en algunos casos, modelos digitales.
La principal función del director de un proyecto BIM es determinar las necesidades de información y cuáles de ellas serán satisfechas en el curso de un contrato. Para ello no se precisan habilidades específicas de modelación digital. También debe asumir la configuración del entorno común de datos (CDE).
Al contratista le corresponde anticipar todos los detalles de cómo va a desarrollar la información, mediante la redacción del Plan de Ejecución BIM, y a producirla de ese modo y en el momento oportuno. La dirección del proyecto aprueba y valida esa información si es conforme a los requisitos.
La Dirección de un proyecto BIM abarca muchas mas funciones que las de un BIM manager, que se circunscriben al área de conocimiento de gestión de la información. No se ocupa éste de ninguna de las restantes (calidad, cronograma, contratación, etc) y mucho menos de la integración, que es el área de conocimiento propia de la Dirección del proyecto.
Es difícil encontrar en el mercado un servicio de apoyo a la Dirección de un proyecto BIM ya que tanto la formación como la oferta de consultoría están orientados a los procesos propios de las partes contratadas y, más concretamente, a la gestión de la información relacionada con el modelo digital, pero en cualquier proyecto éste tipo de información solo es una parte, y no necesariamente la más relevante.
2 comentarios en «[#6] ¿POR QUÉ NOS PERDEMOS LOS DIRECTORES DE PROYECTOS EN EL MUNDO BIM?»
Gracias, Rafael. Me ha encantado el post y creo que es muy acertado profundizar en la diferencia entre el BIM Manager y el Director de proyecto. Eso sí, la extracción de requisitos (técnicos y información) y su traslado a los documentos de una licitación pública merecen otra/s entradas. 😉
Efectivamente, Carlos, la gestión de requisitos es la gran olvidada. Es una actividad con poco glamour, sin embargo, su adecuada extracción nos informa de lo que hay que hacer y de su calidad; su cumplimento nos dice el proyecto termina y con que calidad.