Plan de ejecución BIM: del EIR al BEP

Un modelo BIM no empieza cuando se traza la primera tubería, el primer ducto o la primera charola. Empieza mucho antes, cuando alguien decide qué información va a contener ese modelo y para qué va a servir.

Pertenezco al Círculo BIM de KINENERGY y, por el rol que desempeñamos, es fácil asumir que un proyecto arranca creando el archivo y modelando. Para mí fue revelador entender todo lo que ocurre antes de trazar cualquier elemento: la estructura de decisiones que determina si el modelo va a ser útil o solo va a estar lleno.

Qué se estandariza antes de modelar

Estandarizar es establecer normas, criterios o especificaciones comunes con el objetivo de lograr un orden en un contexto determinado. Aplicado a un proyecto BIM, es la fase donde se definen las reglas y la estructura que guiarán todo el desarrollo del modelo.

Sin ese acuerdo previo, cada empresa termina inventando su propio sistema. Todos pueden decir que hacen BIM, y cada quien lo hace a su manera. Lo que persigue un estándar es que todos hablemos el mismo idioma.

Ese estándar existe: la ISO 19650, que trata específicamente sobre la gestión de la información. Se compone de seis partes: conceptos y principios, fase de desarrollo de los activos, fase de operación, intercambio de información, seguridad de la información e información de salud y seguridad. En KINENERGY estamos certificados en las partes 1 y 2. La certificación no cambió lo que sabemos hacer técnicamente; cambió el orden con el que gestionamos la información, desde las carpetas hasta la estructura de lo que entregamos.

La cadena de requisitos: OIR, PIR, AIR y EIR

El punto de partida de un proyecto no es el diseño ni el modelo, sino la evaluación de necesidades del cliente: objetivos de organización y de negocio que se van traduciendo en requisitos de información cada vez más concretos.

La ISO 19650 ordena esa traducción en cuatro niveles:

• OIR, requisitos de información de la organización: qué necesita saber la organización para cumplir sus objetivos. Es la premisa de la que cuelga todo lo demás.
• PIR, requisitos de información del proyecto: qué información hace falta para tomar decisiones durante el desarrollo del proyecto.
• AIR, requisitos de información del activo: qué información hace falta para operar el activo una vez construido.
• EIR, requisitos de intercambio de información: qué se entrega, en qué momento y con qué formato.

De ahí salen dos productos distintos. Si el objetivo se detiene en el proyecto, el entregable es un PIM, el modelo de información del proyecto: un modelo BIM terminado. Si el objetivo alcanza la operación, el entregable es un AIM, el modelo de información del activo, la base de lo que después se llama gemelo digital. No es el mismo modelo, y esa diferencia debe decidirse al principio, no al final.

La propuesta comercial responde al EIR

Lo que llega a una consultoría de ingeniería es ese EIR: el propósito del proyecto, los alcances, el plan de trabajo y las ingenierías a desarrollar. La propuesta comercial es la respuesta a esos requisitos, y describe los servicios, los alcances, los entregables y la propuesta económica.

La ISO 19650, sin embargo, espera algo más que una propuesta. Espera un pre-BEP: la primera versión del plan de ejecución BIM, donde el equipo demuestra su capacidad de gestionar información antes de que exista una adjudicación. Ahí se declaran los roles y responsabilidades del equipo, cómo se aloja la información, la estrategia de federación y la infraestructura de software y hardware que se va a utilizar. En KINENERGY tratamos el pre-BEP como parte de la respuesta a un EIR, no como un documento que se resuelve después de ganar el proyecto.

El BEP es la evolución de ese documento: la versión completa, con los requisitos específicos del proyecto ya cerrados.

Qué debe definir el BEP

El plan de ejecución BIM describe cómo el equipo de desarrollo va a generar y gestionar la producción de información de un activo. Funciona como guía de trabajo, y por eso conviene que incluya, como mínimo:

• información base del proyecto: coordenadas, unidades y ubicación;
• el nivel de desarrollo geométrico (LOD) y el nivel de información (LOI);
• las nomenclaturas y el nombramiento de archivos;
• el entorno común de datos (CDE) donde vivirá la información;
• la estrategia de organización de carpetas;
• la estrategia de federación de los modelos;
• los estándares aplicables, los entregables y las versiones de software.

Cuando el cliente ya tiene su propia estructura de nombramiento o su propio CDE, nos regimos por la suya; cuando no la tiene, proponemos la nuestra y la ponemos a su aprobación. Lo que no funciona es dejarlo sin definir: cada dato que falta ahí se termina resolviendo por correo, con revisiones y rebotes que se acumulan sobre el calendario.

LOD y LOI no son lo mismo

Durante mucho tiempo la conversación se cerraba con una sola cifra: un LOD 350. Y ahí quedaba.

El LOD se refiere al nivel de desarrollo geométrico. El LOI se refiere al nivel de información. No son proporcionales entre sí: un modelo puede tener una geometría deliberadamente básica, digamos LOD 200, y sostener un LOI 350, es decir, contener información suficiente para ejecutar el proyecto. Pedir más LOD no garantiza más datos aprovechables, del mismo modo que los sistemas de clasificación son los que permiten que esa información pueda recuperarse después.

Distinguir ambos niveles con el cliente evita una expectativa muy común: que las familias se vean idénticas al catálogo del fabricante y además traigan toda la información. Son dos exigencias distintas, con dos costos distintos.

El costo de sobreinformar el modelo

El propósito de un modelo es ser útil, claro y eficiente. No se trata de llenar el archivo con datos, sino de incluir solo lo necesario según el objetivo de ese proyecto en específico.

Por eso no trabajamos con una plantilla única. Un proyecto de vivienda vertical y uno de sector salud no comparten alcance, ni familias, ni parámetros; partir de una base genérica arrastra información de proyectos anteriores que nadie va a usar y que sí hay que cargar, revisar y depurar. Cada proyecto es distinto, incluso dentro del mismo sector, porque cambia el cliente y su forma de gestionar la información.

Lo mismo ocurre con los parámetros. Muchos clientes trabajan con parámetros propios ligados a sus catálogos de conceptos; una familia descargada de internet no tiene esa liga y obliga a un desarrollo paralelo al que el cliente ya tiene resuelto. Cuando el cliente comparte sus plantillas, basta con entender su forma de organizar la información y producir dentro de ella. Ese acuerdo, junto con la estrategia de federación, es lo que hace posible la coordinación entre disciplinas sin interferencias más adelante.

Definir el propósito, el LOD y el LOI, el CDE y los parámetros antes de abrir el modelo es lo que permite que el proceso de modelado avance sin rehacerse. En KINENERGY tratamos esas definiciones como parte de la conversación inicial con el cliente, y no como algo que se aclara con el modelo ya empezado: es la diferencia entre entregar un modelo que el cliente puede operar y entregar un archivo que hay que volver a construir.