215 Requisitos BIM (EIR) Pedir por pedir

215 Requisitos BIM (EIR) Pedir por pedir

Hay un procedimiento bastante extendido para empezar un proyecto: decidir que se hará con BIM, elegir las herramientas y dejar las necesidades para después. Si queda tiempo, preguntaremos al cliente qué quiere conseguir. Y si no queda, siempre podemos pedirlo todo. Así parece que no nos olvidamos de nada.

Ponemos a prueba ese procedimiento. Comparar alternativas, controlar la ejecución y organizar el mantenimiento parecen objetivos razonables. Pero cada uno necesita información distinta, en momentos distintos y para personas distintas. Ahí empieza el trabajo de definir los requisitos.

Quiero BIM. Ya veremos para qué

Pedir un modelo no explica qué decisión queremos tomar con él. Para comparar alternativas de diseño podemos necesitar espacios, superficies, usos o costes. Rogelio añade la energía y la ventilación, dos cuestiones especialmente relevantes en un centro educativo. Ninguna se resuelve simplemente exigiendo más detalle geométrico.

Rafa recuerda que el cliente también debe aportar información: necesidades, usuarios, crecimiento previsto y condiciones de funcionamiento. Antes de elegir herramientas hay que entender el encargo. Porque empezar por el martillo y buscar después los clavos tiene tradición, pero no garantiza que construyamos lo que hacía falta.

La E cambia algo más que el nombre

Durante años, EIR se utilizó para hablar de requisitos de información del cliente. Con ISO 19650 hablamos de requisitos de intercambio de información. El cambio obliga a mirar las relaciones entre los participantes: quién necesita información de quién y bajo qué condiciones.

Las matrioskas de Evelio explican esa cadena. Podemos ser proveedores de nuestro cliente y clientes de nuestros colaboradores al mismo tiempo. Por eso no basta con reenviar el documento del promotor a todos. Cada participante debe conocer qué información aporta, quién la recibe, cuándo debe entregarla y cómo se aceptará. Y sus requisitos no tienen por qué ser idénticos.

Un IFC, un PDF y una carpeta entran en un pliego

Una lista de archivos puede parecer una definición muy concreta de la entrega. Sin embargo, pedir IFC y PDF deja pendiente el contenido que necesitamos encontrar dentro. La conversación lo aterriza con una lista de datos: puede viajar en una hoja de cálculo, un CSV o un documento de texto. Lo que buscamos es poder utilizarla.

Con el entorno común de datos sucede algo parecido. La discusión acaba demasiado a menudo en una estructura de carpetas, aunque todavía no hayamos definido los procesos, los estados o el flujo de información. El inventario de equipos del colegio ayuda a volver al propósito: el suministrador necesita saber qué campos debe completar. No estudiar todos los requisitos del proyecto para descubrir cuáles le afectan.

La sopa de letras y el horno de la pizzería

OIR, AIR, PIR y EIR parecen una contraseña del wifi, pero intentan ordenar necesidades de información de la organización, del activo, del proyecto y de los intercambios. Rogelio recurre a una pizzería para explicarlos. Evelio propone una promotora con una estrategia de sostenibilidad que debe concretarse en sus edificios y proyectos.

La explicación genera debate. Rafa señala que objetivos y requisitos de información no son lo mismo: querer una empresa sostenible todavía no define los datos necesarios para gestionarla. Esa distinción importa más que memorizar los acrónimos. Además, mantener un edificio puede exigir intercambios de información sin que exista un nuevo proyecto de construcción que recorrer de principio a fin.

El cliente no tiene por qué saber BIM

El cliente puede conocer su actividad y desconocer qué información admite un modelo. También puede llegar con una petición muy clara y una necesidad bastante menos clara. Rogelio cuestiona que las personas y las organizaciones sepan siempre qué necesitan. Rafa recuerda que hay proveedores que tampoco saben para qué sirve lo que ofrecen.

El trabajo del asesor incluye ayudar a descubrir esas necesidades y traducirlas en requisitos técnicos. Evelio distingue ese acompañamiento de decidir por el cliente. Propone insistir en el «¿para qué?» y contrastar cómo trabaja realmente el equipo. A veces basta con reunir a quienes aseguran hacerlo todo igual para descubrir que unos lo hacen más igual que otros.

EIR y BEP: qué necesitas y cómo voy a conseguirlo

El EIR plantea la demanda y el plan de ejecución BIM organiza la respuesta. Normalizar los apartados de esa respuesta puede ayudar a comparar ofertas. Pero la conversación cuestiona cuánto debe intervenir el cliente en los métodos de trabajo del equipo. Pedir modelos separados por disciplinas, por ejemplo, no obliga necesariamente a modelar cada disciplina por separado.

Definir demasiado también tiene sus trampas. Evelio plantea un edificio octogonal para el que se piden cuatro alzados: podemos cumplir la lista y representar mal el edificio. Exigir que todas las fachadas queden correctamente representadas permite responder al propósito. La colaboración entre las partes ayuda a evitar compromisos que parecen precisos y acaban siendo inútiles.

Los datos también pasan factura

Cada dato cuesta producirlo, comprobarlo y mantenerlo actualizado. Pedir más información por si acaso aumenta ese trabajo. Evelio cita un documento de FGV para mantenimiento que excluye expresamente la valoración de usos BIM no solicitados. Ofrecer más tampoco garantiza que la entrega sea mejor.

La discusión se complica al mirar al futuro. ¿Qué información de mantenimiento podemos definir durante el proyecto si todavía no conocemos los equipos que se instalarán? Rogelio defiende trabajar con requisitos que podamos concretar hoy y actualizar la información conforme evoluciona el edificio. Anticipar necesidades tiene límites: adivinar tecnologías, costes o condiciones de reciclaje dentro de décadas ya requiere otro tipo de poderes.

Un requisito que pueda ponerse a prueba

Para empezar no siempre hace falta invocar al Consejo de Sabios. Evelio propone una ficha con finalidad, entrega asociada, responsable, comprobación y dudas pendientes. Las preguntas obligan a pasar de una frase que suena bien a una petición que alguien pueda entender y cumplir.

Rogelio añade tres pruebas: si el requisito puede incumplirse, si encaja con la fase y los honorarios y si quien debe cumplirlo entiende qué tiene que entregar. Rafa insiste en conocer el propósito y la capacidad real para asumir el trabajo. El «malo será» puede cerrar una reunión, pero difícilmente resuelve esas preguntas.

Conclusión

Pedir información es un trabajo técnico y una responsabilidad compartida. Quien la solicita debe entender para qué la necesita. Quien la produce debe comprender qué entrega y tener capacidad para hacerlo. Ambos deben acordar cómo comprobar que el intercambio cumple su propósito. Porque entregar un archivo no demuestra, por sí solo, que hayamos entregado la información solicitada.

Nos interesa conocer tu experiencia.

¿Te ha tocado preparar información que después nadie utilizó?

¿Has trabajado con requisitos que facilitaron de verdad el proyecto?

Cuéntanoslo en los comentarios, en las redes o en [email protected].

Los requisitos absurdos también dan buenas anécdotas, aunque preferiríamos no tener que cumplirlos.