Notícias
El Plan de Ejecución del BIM y los Requisitos de Intercambio de Información desarrollados bajo una misma metodología
Hacia el año 2006, cuando empecé a aprender sobre BIM y a intentar implementarlo en proyectos, el término más glamuroso que se conocía en aquel momento era el de “BIM Execution Plan”. Para el reducido número de Bimners de la época, este documento estaba envuelto en cierto halo de misterio, ya que existían muy pocas referencias sobre cómo redactarlo, quien era el responsable de hacerlo y, lo más importante, cual debía ser su contenido. Hablar del BEP era como hablar de sexo en mi adolescencia. Algo de lo que muchos hablaban, pero casi nadie practicaba. Para que os situéis, en esa época el famoso “The BIM Handbook” de Chuck Eastman todavía no se había publicado.
Al cabo del tiempo, la universidad de Pensilvania publicó la “Guide for BIM Execution planning”, en la que proponía, no sólo una metodología para la planificación del BIM, sino también una plantilla para su redacción.
Obviamente, dicha plantilla sirvió de inspiración para muchos profesionales, que vieron en ella una referencia para el desarrollo de sus propios BEP. También fue uno de los primeros casos claros de “Culto al carguero” que recuerdo, ya que muchos de mis colegas se esforzaban más en rellenar diligentemente los espacios en blanco de la plantilla que en entender cuál era el sentido de cada apartado y, mucho menos, en desarrollar su propia manera de hacer adaptada al contexto de sus encargos.
La necesidad de establecer requisitos del cliente
Paralelamente, las partes contratantes también empezaron a implementar BIM y, con ellas, surgió la necesidad de incluir en los procesos de contratación documentos que detallasen la forma en que deseaban que sus proveedores implementasen el BIM en los encargos para los que se les contrataban.
Al principio, esto generó cierta confusión, porque la reacción más inmediata de muchos consultores fue la de usar el BEP para esta función. Esto no era muy ortodoxo, ya que este documento tenía sentido como herramienta de planificación y no una herramienta de especificación de requisitos (incluso en la etapa precontractual, su función sigue siendo la misma).
En mi caso, creo que mi primer trabajo al respecto consistió en desarrollar los requisitos para la implementación del BIM para los primeros proyectos de un conocido club de futbol en el año 2015. En aquel momento lo llamamos “Especificaciones Generales”, pero su estructura era la misma de los BEP que ya estábamos implementando en los dos primeros encargos para este mismo cliente, en los que actuábamos como BIM Managers del proyuecto. Esto nos obligó a explicar muy bien al resto de proveedores el sentido y uso de estos dos documentos, ya que, mientras el primero explicaba las expectativas de la parte contratante, el segundo especificaba de qué forma estos requisitos se implementaban en los diferentes encargos gestionados por dicha parte.
Obviamente, esta misma idea se desarrolló con otros nombres, siendo el término “Employer Information Requeriments” el más extendido a nivel internacional, al estar recogido en la PAS-1192 publicada en 2013 por la British Standards Institution. Como era de esperar, esta se coinvirtió en la nueva referencia para mucha gente, estableciendo que dichos requisitos debían agruparse en tres apartados.
- Information management
- Comercial management.
- Competence assessment.
También tuvo mucha difusión la versión publicada por el BIM Task Grup, que todavía se puede consultar en la web de Scottish Future Trust, y que estructura el documento en los siguientes apartados:
Actualmente, este término ha evolucionado hacia un concepto más amplio denominado “Exchange Informatin Requeriments”, recogido en la ISO 19650-1. Aunque este estándar todavía no ha establecido el contenido exacto de este documento, sí que parece seguir el enfoque precedente, declarando que el EIR “set out managerial, commercial and technical aspects of producing project information”.
El BEP como respuesta al EIR
Tanto la PAS como la reciente ISO 19650 establecen que el BEP debe describir de qué forma los EIR de las partes contratantes se implementaran en un encargo concreto. El problema es que estas dos referencias internacionales (la de la Penn State Univeristy para el BEP y la del EIR en cualquiera de sus versiones) no tienen la misma estructura. Con el paso del tiempo, diferencia se ha ido acrecentando, ya que los diferentes agentes que han ido generando este tipo de documentos han ido desarrollando su propia manera de hacerlo acorde con sus necesidades (cómo es lógico). De hecho, sólo una pequeña parte de los EIR y BEP que han caído en mis manos sigue los esquemas anteriormente descritos. Incluso cuando un EIR incluye una plantilla para la redacción del BEP, lo más habitual es que esta siga una estructura completamente diferente.
En mi opinión, esto representa un inconveniente, ya que dificulta que, por un lado, las partes contratadas sepan que parte del EIR describe cada punto que deben tener en cuenta en la redacción del BEP. Hay que tener en cuenta que no todos los EIR describen todo lo necesario ni con la suficiente concreción, así que al equipo de desarrollo del encargo no le queda otra que hacer un análisis comparativo a fin de evitar omisiones e identificar claramente las lagunas del EIR que deban resolverse durante la redacción del BEP.
Las partes contratantes también sufren las consecuencias de estructurar de forma diferente los EIR y el BEP, ya que deben revisar la correspondencia de lo descrito en el BEP con lo requerido en su EIR, aunque es cierto que si ellas mismas son las autoras de la plantilla del BEP que han de usar las partes contratadas les será más fácil.
Por otra parte, hay que tener en cuenta que no siempre habrá sólo una parte contratante que ponga sobre la mesa su EIR, tal y como contempla la ISO, los EIR pueden ser múltiples, ya sea porque se agreguen (diversos agentes al mismo nivel de contratación) o se encaden (subcontratación). De hecho, estrictamente hablando, puesto que la ISO 19650 atañe únicamente a la gestión de la información (“Appointed party: provider of information concerning works, godos or services”), se podría interpretar que los proveedores de servicios también deberían aportar sus respectivos EIR al proceso de redacción del BEP, ya que en ocasiones van a ser los demandantes de información proveniente de sus compañeros de contrato o, incluso, de sus clientes.
Por tanto, parece que lo más práctico seria que los EIR y los BEP compartieran una misma estructura para facilitar la trazabilidad de la correspondencia entre ambos.
Pero entonces ¿Cuál debería ser la estructura de estos documentos? ¿Es posible organizar su contenido bajo una misma estructura? ¿Se puede estandarizar su contenido al menos hasta un cierto nivel, con el fin de que sea más fácil integrar los diversos EIR de los agentes que intervienen en un encargo?
El EIR y el BEP como la descripción de una metodología de trabajo
Siempre se ha dicho que el BIM es una metodología de trabajo. Por tanto, parece lógico describir su implementación como desde esta perspectiva. Según el diccionario, una metodología es la aplicación de un procedimiento con un fin concreto. Esto encaja muy bien con una idea que para nosotros es fundamental, que el uso del BIM tenga un objetivo. Es más, como veremos más adelante, también debe tener un propósito.
A partid de aquí, lo lógico sería describir dicha metodología siguiendo los siguientes pasos:
1. Describir el Contexto
Tanto si se trata de requisitos de los actores que participan en el encargo (EIR) como de la planificación de la implementación del BIM en el mismo (BEP), es importante contextualizarlo. Es decir, describir cuales son los antecedentes, el ámbito de aplicación, las referencias usadas, las normas de aplicación, etc. Nosotros también añadimos los datos de contacto en caso de consultas y un glosario de términos en este apartado.
2. Describir los Propósitos y los Objetivos
Se define el Por Qué y el Para Qué se pretende implementar BIM en e encargo. Esta parte es la más importante ya que es la que le da sentido al uso del BIM y merece la pena trabajarla bien desde el principio. Además, el resto de los apartados dependen de esta parte, pudiendo negociar su alcance siempre y cuando se mantenga lo que aquí se estipule. paradójicamente, nuestra experiencia nos demuestra que esta suele ser la parte que menos se trabaja, especialmente la de los propósitos. En la mayor parte de la literatura existente, se habla sólo de la necesidad de definir objetivos. (el Para Qué). Sólo la ISO 19650 hace alguna referencia directa a la necesidad de definir los propósitos “The appointing party should state their purposes for requiring information deliverables” (ISO 19650-1).
3. Describir los Entregables
Se define Qué se necesita producir para alcanzar los objetivos definidos en el apartado anterior teniendo en cuenta su propósito y Cuando deben darse estos intercambios.
4. Describir los Procesos
Se define Cómo deben obtenerse los entregables descritos en el paso anterior y Quien participa en cada proceso. Por tanto, este capítulo recoge los usos del BIM aplicables al encargo, los cuales quedan justificados por la obtención de entregables concretos según unos determinados propósitos y objetivos. También incluye la descripción de otros procesos, como los de Inicio y Coordinación, o los mecanismos de control de calidad.
5. Describir los Recursos
Finalmente, se definen los recursos necesarios para ejecutar los procesos anteriores. Es decir, Con Qué. Dentro de este apartado encontramos aspectos tanto técnicos como humanos. Estamos hablando de software, pero también de las competencias requeridas por los diferentes agentes que participan en el encargo.
Esta estructura es compatible tanto con la principal referencia para el EIR como su homónima para el BEP, ordenando sus apartados siguiendo el propio proceso de definición de una metodología. En este caso, la de implementar BIM en un encargo.
El desarrollo de los EIR y el BEP como un proceso de toma de decisiones
La ventaja de este planteamiento es que el desarrollo de las diferentes partes sigue un orden adecuado para la toma de decisiones. Va de lo estratégico a lo técnico, estableciendo lo que se quiere obtener con independencia de cómo se debe obtener
Por tanto, se puede diseñar un proceso de redacción de este tipo de documentos que siga estos 5 pasos:
Como se puede ver, dicho proceso puede usarse para ayudar a una parte contratante a desarrollar sus requisitos de información, especialmente cuando debe atender a las necesidades de diferentes departamentos dentro de una misma organización o para fusionar requisitos de varios clientes internos.
Por otra parte, cuando se usa esta estructura para la elaboración del EIR, lo lógico es incluir una plantilla para la redacción del BEP por parte de los futuros proveedores. Puesto que el esquema es el mismo, la plantilla puede ofrecerse previamente rellenada con todo lo que contiene el EIR facilitando su uso como punto de partida por parte de quien deba desarrollar el encargo.
A continuación, se observa un ejemplo de contenidos de un EIR y de su plantilla para el BEP.
Su contenido inicial es el mismo, con la diferencia de que el primero es un documento de consulta y, el segundo, un documento de trabajo que podrá modificar lo establecido en el EIR a tenor de las negociaciones pre o post contractuales que pueda haber.
En este sentido, el uso de esta metodología durante la redacción del BEP todavía resulta más útil, puesto que su desarrollo implica poner en común requisitos de varias fuentes, ya sean clientes o proveedores, con diferentes estructuras y niveles de concreción. Durante el proceso de negociación, se podrán establecer los propósitos y objetivos de todas las partes, priorizándolos y, después, desarrollar todo lo demás en consonancia.
Consideracions finals
Definir los propósitos y objetivos requiere un trabajo de reflexión previo por parte de los implicados. Cuando se trata del EIR, esto implica que una organización que pretende implementar BIM en los encargos que gestiona se tome un tiempo para analizar qué es lo que realmente necesita y por qué. En el caso del BEP, ocurre lo mismo, por lo que la planificación del encargo debe contemplar un tiempo que permita que todas las partes desarrollen, con conocimiento de causa, cada una de sus partes. Sin duda, el hecho de conocer los propósitos que motivan cada objetivo perseguido ayudará en gran medida a entender las circunstancias de cada parte y a optimizar los esfuerzos tanto compartidos como individuales en el desarrollo de los entregables.
Por otra parte, la estructura aquí expuesta está pensada como un marco de trabajo que permita evolucionar sus contenidos a lo largo del tiempo. Nosotros llevamos más de cuatro años implementándolo y no hemos dejado de introducir mejorar en cada nueva versión, buscando sobre todo facilitar la comprensión y asimilación de su contenido por parte de los implicados, ya sean clientes o proveedores. Por esta razón, podemos asegurar que se trata de un sistema que funciona y resulta coherente. No obstante, estoy seguro de que existen otras soluciones igual de válidas, así que vuestra opinión será bienvenida.
Podéis encontrar más información sobre esta metodología y como implementarla en la “Guía para la implementación de BIM en la licitación pública”. Aunque enfocada a la contratación pública, sus recomendaciones son perfectamente válidas en el ámbito privado.
