En muchos proyectos se solicita "un modelo completo", "LOD 400" o "todos los parámetros" antes de responder una pregunta más importante: ¿qué decisión debe permitir esa información? Cuando el propósito no está claro, el equipo produce más archivos y más datos, pero no necesariamente mejores resultados.
La gestión de información comienza antes del modelado. Requiere transformar necesidades organizacionales, del proyecto, del activo y de cada intercambio en requisitos que puedan entenderse, asignarse y verificarse. Esa es la función de una matriz de requisitos de información.
El problema no suele ser la falta de datos
Los proyectos fallan cuando una solicitud es ambigua: no identifica la población de activos a la que aplica, el momento de entrega, el responsable, el formato, el criterio de aceptación ni la evidencia esperada. Al llegar el intercambio, cada participante interpreta la solicitud de manera distinta.
Una frase como "entregar la información del tablero" no es comprobable. En cambio, un requisito útil puede indicar qué tableros están incluidos, qué propiedades se esperan, para qué se utilizarán, quién las entrega, en qué gate se revisan y cómo se demuestra su conformidad.
De la necesidad al requisito verificable
La serie ISO 19650 establece conceptos y principios para gestionar información a lo largo del ciclo de vida del activo. La Parte 2 desarrolla el proceso durante la fase de entrega, mientras que la Parte 4 aporta criterios y decisiones para los intercambios de información y la calidad de los modelos de información. A septiembre de 2026, las ediciones 2018 de las Partes 1 y 2 continúan vigentes, aunque ISO ya indica que están en proceso de revisión; cada proyecto debe comprobar la edición contractual aplicable. La plantilla SORA toma esa lógica como referencia práctica: no reproduce la norma ni certifica cumplimiento.
Cada fila de la matriz conecta ocho elementos:
- Tipo de necesidad: organizacional (OIR), del proyecto (PIR), del activo (AIR) o del intercambio (EIR).
- Propósito: la decisión, uso o resultado que la información debe habilitar.
- Objeto y alcance: el activo, sistema, documento o población aplicable.
- Necesidad de información: qué debe entregarse, separando geometría, información alfanumérica y documentación.
- Responsabilidad: quién prepara y quién revisa.
- Punto de control: puede asociarse a estados del CDE —como WIP, Shared o Published— o a hitos —como Commissioning y Handover—, siempre conforme al proceso del proyecto.
- Aceptación: la condición objetiva que debe cumplirse.
- Validación y evidencia: cómo se comprueba y qué registro conserva la decisión.
Separar geometría, datos y documentos evita convertir el "nivel de detalle" en una exigencia genérica. Una secuencia de operación puede no necesitar geometría, pero sí estados, alarmas e interlocks claros. Un modelo de coordinación puede requerir forma y ubicación adecuadas al propósito, aunque no necesite todos los datos de operación. Un registro de activos puede exigir información alfanumérica precisa sin aumentar el detalle visual.
¿Dónde encaja IDS?
Information Delivery Specification (IDS) de buildingSMART permite expresar requisitos alfanuméricos de forma interpretable por software y comprobarlos en modelos IFC. Es especialmente útil para propiedades, clasificaciones, materiales, cantidades y relaciones. No sustituye la revisión geométrica ni valida por sí solo reglas de diseño. Por eso la matriz distingue el método de validación: IDS puede ser uno de ellos, junto con revisión documental, federación, detección de interferencias, pruebas de campo o auditorías cruzadas.
Una herramienta conectada con el ecosistema SORA
La matriz no pretende vivir aislada. Es el punto de origen de una cadena de continuidad técnica:
- Los requisitos determinan qué información se necesita.
- La matriz RACI establece quién decide, ejecuta, consulta y recibe información.
- El MIDP/TIDP organiza cuándo se produce y entrega.
- La nomenclatura conserva la identidad y trazabilidad de los contenedores.
- El sistema QA/QC verifica si el resultado cumple.
Esto acompaña la evolución de SORA más allá de una práctica BIM aislada: Ingeniería → Información → Coordinación → Construcción → Commissioning → Entrega. La información funciona como hilo conductor entre decisiones técnicas, ejecución y operación.
Qué incluye la herramienta
El archivo contiene:
- configuración del proyecto y del intercambio;
- catálogos editables;
- 20 requisitos iniciales para información, BIM, coordinación, documentación, eléctrica, BMS/BAS, EPMS, commissioning y entrega;
- controles de campos obligatorios;
- estados de revisión y aprobación;
- un dashboard con un gate de decisión de cinco salidas;
- guía de uso, referencias y límites.
El gate no permite confundir "archivo completado" con "información aprobada". Distingue entre alcance no configurado, configuración incompleta, requisitos incompletos, pendiente de aprobación y apto para intercambio.
Cómo comenzar
Empieza por definir el proyecto, el activo, la parte designante o cliente y el intercambio. Revisa después la aplicabilidad de cada requisito de ejemplo; elimina, adapta o agrega filas según el contrato, la jurisdicción y el plan de ejecución. Si un requisito no aplica, documenta el motivo. Asigna responsables reales y redacta criterios que otra persona pueda comprobar sin interpretar la intención del autor.
La plantilla es un punto de partida profesional, no un requisito contractual universal. La versión aplicable de las normas, los requisitos del cliente, la legislación, los fabricantes y las condiciones del proyecto siempre deben prevalecer.
Una matriz de requisitos bien construida no elimina la ambigüedad de un proyecto, pero impide que se traslade sin control hasta el modelo, el dato o el documento final.
Fuentes de referencia
¿Tu organización necesita una herramienta adaptada a sus procesos?
Cuéntanos el contexto, los roles, los entregables y los controles que necesitas. SORA puede ayudarte a estructurar una solución técnica específica y definir el alcance adecuado.
Hablar sobre una herramienta adaptada →Etiquetas
