Qué es un entorno común de datos (CDE) y cómo implementarlo

Un entorno común de datos (CDE, por sus siglas en inglés; ECD en español) es la fuente acordada de información de un proyecto: el único lugar donde cada plano, modelo y documento se guarda, se revisa, se aprueba y se publica siguiendo un proceso definido. No es solo un repositorio. Es una herramienta más un conjunto de reglas sobre estados, nomenclatura, revisiones, permisos y flujos de aprobación. Para implementarlo, primero se acuerdan esas reglas y después se configura la plataforma.

Qué es un CDE y qué no es

La ISO 19650 describe el entorno común de datos como la fuente de información acordada para un proyecto o activo, que sirve para recopilar, gestionar y difundir cada contenedor de información mediante un proceso gestionado. Un contenedor es cualquier archivo con nombre propio: un plano en PDF, un modelo en formato IFC, una hoja de metrados.

De esa definición salen tres ideas prácticas:

• Acordada. Todas las partes aceptan que lo que está en el CDE es lo que vale. Lo que circula por correo o por chat no cuenta.
• Proceso gestionado. Un archivo no cambia de estado porque alguien lo movió de carpeta. Cambia porque una persona con ese rol lo revisó y lo aprobó.
• Cada contenedor. El control es por archivo, no por entrega completa. En un mismo envío, un plano puede quedar aprobado y otro rechazado.

Las partes 1 y 2 de la norma se publicaron en 2018.

En el Perú, la inversión pública adopta BIM de forma progresiva dentro del Plan BIM Perú, que lidera el MEF. Si tu proyecto es público, consulta la normativa vigente antes de fijar tus requisitos de información.

Los cuatro estados de la información

La ISO 19650 plantea que todo contenedor está en uno de cuatro estados.

Entre un estado y el siguiente hay un control. Para pasar de trabajo en curso a compartido, el propio equipo autor verifica, revisa y aprueba. Para pasar de compartido a publicado, quien lidera el encargo revisa y autoriza, y el cliente acepta.

Muchos proyectos añaden códigos del tipo S0, S1 o S2 para precisar el uso permitido. Provienen del anexo nacional británico de la norma. Fuera de ese contexto no son obligatorios, pero sirven como punto de partida.

Nomenclatura, versiones y revisiones

Una convención de nombres permite saber qué es un archivo sin abrirlo y evita duplicados. Se construye con campos fijos unidos por un separador. Una estructura muy extendida es esta:

Proyecto-Originador-Volumen-Nivel-Tipo-Disciplina-Número

Un ejemplo ilustrativo: TOR-ABC-ZZ-N03-PL-E-0201 sería el plano 0201 de estructuras, nivel 3, emitido por la empresa ABC para el proyecto TOR. Lo que importa es que la lista de valores permitidos sea corta, esté escrita y nadie la improvise.

Dos conceptos se confunden con frecuencia:

• Versión. Cada vez que se sube el archivo de nuevo. La genera el sistema: V1, V2, V3.
• Revisión. La etiqueta formal que el autor asigna cuando emite el documento: A, B, R01. Una revisión puede acumular varias versiones internas.

El estado y la revisión deben viajar como datos del archivo y no solo dentro del nombre. Así se pueden filtrar, reportar y auditar.

Flujos de aprobación y roles

Un flujo de aprobación define quién revisa, en qué orden y en cuánto tiempo. Sin plazo por paso, la revisión se vuelve una cola invisible.

Los roles mínimos son cinco:

• Autor. Produce la información y responde por su contenido.
• Revisor. Comprueba que cumple los requisitos y deja sus observaciones por escrito.
• Aprobador. Autoriza el cambio de estado. No debería ser la misma persona que el autor.
• Gestor de información. Administra la estructura, los permisos y la convención de nombres.
• Cliente o supervisión. Acepta la información publicada.

Asigna los permisos por grupo y no por persona. Cuando alguien entra o sale del proyecto, basta con moverlo de grupo. Separa también ver de descargar: un subcontratista puede consultar un plano sin llevarse el archivo.

Cómo implementarlo en cinco pasos

Esta secuencia sirve para una constructora que hoy trabaja con carpetas compartidas.

1. Nombra un responsable. Una persona administra el CDE y resuelve dudas. Sin dueño, las reglas se diluyen en pocas semanas.
2. Escribe las reglas en una página. Estructura de carpetas, estados, convención de nombres y etiqueta de revisión. Inclúyelas en el plan de ejecución BIM.
3. Configura permisos y flujos. Grupos por empresa o disciplina, y uno o dos tipos de flujo con pasos, responsables y plazos.
4. Migra solo lo vigente y fija una fecha de corte. Desde ese día, lo que no está en el CDE no existe. La historia antigua queda archivada aparte.
5. Mide y ajusta cada mes. Días que tarda una revisión, archivos rechazados por nombre incorrecto y consultas de obra causadas por un plano desactualizado.

Ejemplo: el recorrido de un plano

El equipo de estructuras trabaja el plano 0201 en su carpeta de trabajo en curso y sube tres versiones mientras lo ajusta. Cuando pasa su control interno, lo emite como revisión A y lo comparte. El coordinador BIM lo usa de referencia y detecta un cruce con un ducto. Estructuras corrige, emite la revisión B y la envía al flujo de aprobación. El revisor observa un detalle, el autor lo levanta, el aprobador autoriza y el plano queda publicado. La revisión A pasa a archivo. En obra se construye con la B.

Errores frecuentes

• Usar una carpeta compartida como CDE. Una carpeta guarda archivos. No registra quién aprobó qué, no distingue estados y no impide trabajar con una revisión superada.
• No tener convención de nombres. Aparecen «plano final», «plano final 2» y «plano final corregido». Nadie sabe cuál rige.
• Aprobar por correo o por chat. La aprobación queda en la bandeja de una persona. Cuando esa persona deja el proyecto, la evidencia se pierde.
• Dejar los modelos fuera. Si solo subes los PDF, el modelo vive en otro lado y la coordinación vuelve a depender de envíos manuales.

Cómo se hace en Wayki

Wayki es el sistema de inteligencia operativa para la ejecución de proyectos de construcción. Su entorno común de datos es la capa base: lo que allí se registra alimenta las alertas y prioridades del resto del sistema.

Cómo se registra. En el entorno común de datos de Wayki configuras por proyecto los atributos de los archivos, sus estados, las reglas de nomenclatura y la etiqueta de revisión. Cada archivo conserva sus versiones y un registro de actividad que no se puede editar. Los flujos de revisión son plantillas con pasos, responsables, validadores y plazo en días, y al cerrarse pueden copiar los archivos aprobados a su carpeta de destino. Los permisos se asignan por usuario o por grupo en cada carpeta. Los modelos se publican desde los complementos para Revit y Navisworks.

Qué hace Wayki con eso. Cuando un flujo de revisión vence o lleva en un paso más días de los que su plazo permite, aparece en el Centro de riesgos con una acción sugerida. Al publicarse una nueva versión de un plano, Wayki compara las dos versiones, señala las zonas que cambiaron y lleva el cambio al Centro de riesgos junto con las incidencias y RFI marcados sobre ese plano. Esas detecciones salen de reglas y comparaciones determinísticas, no de un modelo de IA.

Si quieres verlo con tu propia estructura de carpetas, solicita una demo.

Preguntas frecuentes

¿CDE y ECD son lo mismo?

Sí. CDE es la sigla en inglés de common data environment y ECD es la sigla en español de entorno común de datos. Ambas nombran el mismo concepto de la ISO 19650.

¿Una carpeta compartida en la nube es un CDE?

No por sí sola. Le faltan estados de la información, un flujo de aprobación con responsables y un registro de quién autorizó cada documento. Puede ser parte de la solución si alguien añade y hace cumplir esas reglas, pero suele quedarse corta cuando participan varias empresas.

¿La ISO 19650 obliga a usar un software específico?

No. La norma describe procesos y responsabilidades para gestionar la información, no productos. Lo que pide es una fuente acordada con estados, revisiones y controles entre un estado y el siguiente.

¿Cuál es la diferencia entre versión y revisión?

La versión es cada carga del archivo y la numera el sistema. La revisión es la etiqueta formal con la que el autor emite el documento, por ejemplo A, B o R01. Una misma revisión puede acumular varias versiones internas.