El BEP que sí se usa: cómo escribir un Plan de Ejecución BIM que no muera en un cajón

Hace un tiempo nos pidieron auditar la coordinación de un proyecto que venía con problemas, y lo primero que hicimos fue pedir el plan de ejecución BIM (BEP). Llegó: sesenta y cuatro páginas, portada prolija, organigrama con roles que ya no existían en el equipo, y una matriz de responsabilidades donde figuraba un software que nadie del proyecto había abierto jamás. Cuando preguntamos quién lo había leído, la respuesta fue un silencio incómodo. El documento se había escrito para ganar la licitación, se había entregado, y se había muerto ahí. Y esto no es la excepción: en nuestra experiencia, la mayoría de los BEP del sector son copy-paste de una plantilla que nadie pensó cumplir.

Para qué sirve un BEP cuando nadie lo lee: el problema real

La pregunta suena cínica pero es el diagnóstico correcto. Un BEP que nadie consulta no es un documento de gestión: es un gesto comercial. El problema es que el proyecto igual necesita las decisiones que el BEP debía fijar —quién modela qué, con qué nivel de desarrollo, cómo se nombran los archivos, cuándo se federa, quién aprueba—, y si el documento no las fija, se toman igual, pero de forma implícita, tarde y contradictoria. Cada disciplina resuelve por su cuenta, y la coordinación se convierte en negociar sobre hechos consumados.

Un BEP vivo hace lo contrario: convierte esas decisiones en acuerdos explícitos antes de que cuesten plata. No es burocracia; es la diferencia entre discutir una regla en la semana uno o discutir un reproceso en el mes ocho.

Las secciones que hacen el 80% del trabajo

Después de escribir y sufrir muchos BEP, llegamos a una convicción: hay cuatro secciones que concentran casi todo el valor, y el resto es contexto.

• Usos BIM del proyecto: para qué se modela. Coordinación, cómputos, documentación, obra. Todo lo demás se deriva de esto.
• Matriz de modelos y responsables: qué modelos existen, quién es dueño de cada uno, en qué software y con qué frecuencia se publica.
• Matriz de LOD por elemento y etapa: el corazón, que merece sección propia más abajo.
• Estructura del CDE y flujo de aprobación: dónde vive la información y cómo cambia de estado, en línea con lo que plantea la ISO 19650.

Si tu BEP tiene esas cuatro secciones resueltas con precisión, ya gobierna el proyecto. Si tiene sesenta páginas pero esas cuatro son genéricas, tenés un PDF muerto con buena tipografía.

BEP pre-contrato vs. post-contrato

La distinción viene de la ISO 19650 y es de las pocas burocracias que defendemos sin matices. El BEP pre-contrato es una propuesta: le decís al cliente cómo pensás abordar sus requisitos, con qué equipo y qué capacidad. Es razonable que sea breve y algo tentativo, porque todavía no conocés el proyecto a fondo.

El BEP post-contrato es otra cosa: es el documento operativo, acordado con todas las partes designadas, con nombres reales, fechas reales y modelos reales. ¿Cuál es el error típico? Entregar el pre-contrato, ganar el trabajo, y nunca escribir el post-contrato. El proyecto entero queda gobernado por un documento comercial escrito antes de conocer al equipo. Después nos sorprende que no se cumpla.

Matriz de LOD por elemento y etapa: el corazón del documento

Si hay una sección que separa un BEP útil de uno decorativo, es esta. Decir "el modelo se entregará en LOD 300" no significa nada, porque un proyecto no tiene un LOD: tiene cientos de tipos de elementos que necesitan niveles distintos en momentos distintos. La estructura necesita más desarrollo temprano que las terminaciones; las instalaciones necesitan LOD alto para coordinar, pero quizás nunca necesiten el nivel de fabricación.

La matriz cruza elementos contra etapas y fija el nivel esperado en cada intersección. Es trabajosa de armar la primera vez, pero es lo que permite verificar entregas de forma objetiva y, sobre todo, lo que evita pagar modelado que nadie va a usar — un tema que da para discusión propia sobre qué LOD pedir en cada etapa. En un proyecto de vivienda que coordinamos, ajustar esa matriz al inicio nos permitió recortar cerca de un tercio del esfuerzo de modelado previsto sin perder ningún uso BIM comprometido.

Cómo mantener vivo el BEP durante el proyecto

Un BEP se muere por abandono, no por mala redacción. Tres prácticas lo mantienen respirando. Primero, versionarlo: el BEP es un documento del CDE como cualquier otro, con revisiones fechadas, y cuando el proyecto cambia —cambia el equipo, cambia el software, cambia el alcance— el BEP cambia con él. Segundo, usarlo en las reuniones de coordinación: cada desvío detectado se contrasta contra lo que el BEP dice, y si el BEP dice otra cosa, se corrige el BEP o se corrige el desvío, pero nunca se ignora la diferencia. Tercero, auditarlo en los hitos: antes de cada entrega importante, media hora de verificación contra la matriz de LOD y el MIDP.

¿Suena a trabajo? Lo es. Pero es trabajo barato comparado con la alternativa, que es coordinar un proyecto donde las reglas viven en la memoria de cada uno. Nuestra postura es simple: preferimos un BEP de doce páginas que el equipo consulta todas las semanas antes que uno de sesenta que impresiona en la licitación y muere en un cajón. Si estás por arrancar un proyecto y el BEP te queda grande, escribinos: armarlo bien al principio cuesta una fracción de lo que cuesta no tenerlo.