· 

CDE, ¿repositorio único o matrioska?

La definición del Common Data Environment (CDE) o entorno común de datos, es uno de los conceptos más difusos y borrosos que aparecen en la serie EN ISO 19650. Personalmente, creo que su indefinición y generalidad, ha sido buscada conscientemente para que pueda ser aplicable por cualquier agente, situación y sobretodo, para que pueda seguir vigente en un futuro impredecible de nuevos casos de uso y tecnologías colaborativas emergentes.

 

El presente artículo, no se centrará en definir los componentes básicos que definen un CDE, como son los estados de información o los metadatos necesarios para su clasificación, revisión y consumo. Si esto os interesa, tenéis un excelente artículo de Manuel Bauzas en este enlace y el documento Introducción a la serie EN ISO 19650 de BuildingSMART donde todo esto se detalla. Por el contrario, la motivación para escribir estas líneas es poner el foco en la sobre-simplificación del concepto CDE que podemos encontrar en el sector.

 

Esta suele darse, tanto en presentaciones comerciales, en noticias del tipo "La empresa X, elije el software Y como su CDE" e incluso, y esto me parece más serio, en cómo se aborda el concepto CDE como un repositorio único en algunas guías publicadas por administraciones públicas.  

 

Para aquellos que no reparéis a qué simplificaciones me refiero, os dejo los siguientes ejemplos:

  • El CDE es solo un gestor documental con funcionalidades BIM.
  • El CDE es una única solución software para el diseño colaborativo.
  • El CDE completo lo define el Adjudicador. 

      Pienso que, mientras todos seamos conscientes que este reduccionismo es puramente parte de la economía del lenguaje, creo que será algo aceptable. Pero sinceramente, empiezo a tener dudas de si el concepto simplificado no está devorando al concepto original. Y es que, a veces, una verdad a medias es la peor de las mentiras.  

 

Para pensar sobre ello, solo vamos a necesitar recordar brevemente la definición de CDE:

 

"fuente de información acordada para cualquier proyecto o activo donde recopilar, gestionar y difundir cada contenedor de información por medio de un proceso gestionado".

 

En resumen, y permitidme simplificar ahora a mí.

 

El CDE, es el proceso|ecosistema, que utilizamos para compartir la información de un proyecto entre los agentes implicados.

  

Creo que, con estos antecedentes, ya podemos entrar en materia y justificar por qué el CDE se asemeja más a una matrioska que a un repositorio único. Para ello nos apoyaremos en las 3 simplificaciones anteriores: 

¿Es el CDE un gestor documental con funcionalidad BIM?

Nadie niega que el gestor documental, es una de las piezas más importantes en la transferencia de información que componen el CDE. Junto con el correo electrónico, suele ser uno de los elementos para la transferencia de información (preexistentes a la venida del BIM), entre los agentes de un proyecto.

 

Si bien, muchos profesionales del sector, esperaban recibir recomendaciones en relación a la gestión de modelos de información de esos gestores documentales. La realidad es que ni la ISO 19650, ni los anejos o documentos nacionales llegan a especificar nada al respecto. Y la realidad es que sí, existen funcionalidades críticas a demandar al gestor documental especialmente cuando no existan otros componentes en el CDE. Por ejemplo,  debe tener funcionalidades de visualización de modelos, acceso a elementos y propiedades del modelo. En la siguiente tabla, puede verse un ejemplo de esas funcionalidades necesarias al gestor documental en un proyecto con modelos de información. 

Funcionalidad Recomendación
Visores BIM sin descarga (IFC, Nativos, ...) Alta
Visualizar árbol del modelo, atributos Alta
Trabajo concurrente en documentos office Alta
Incluir comentarios sobre el modelo 3D Media
Gestión de BCF's Media
Posibilidad de incluir modelos subfederados Media
Realizar consultas visuales al modelo (conteo, mediciones) Opcional
Posibilidad de hacer interferencias y Clash Detection Opcional
Comparador de cambios en versiones del modelo Opcional
Extraer o publicar información del modelo (planos, listados) Opcional

Ej. recomendaciones de ACCIONA relativas a la funcionalidad de los gestores documentales 

Pero, que la gestión documental gane en funcionalidad “BIM”, no significa que sea un concepto intercambiable con el CDE. En el Gestor documental, el elemento mínimo a gestionar es el documento (Repositorio de cajas negras de información, codificada, con metadatos y flujos asociados). En cambio, en un CDE el elemento mínimo a gestionar está por debajo de la entidad documento, pues son los datos existentes dentro de él. (Una base de datos de la información del proyecto).

 

Ejemplo: Imaginemos un CDE compuesto únicamente por un gestor documental sin visor de modelos donde se almacenan 20 sub-modelos de un tamaño aproximadamente 4 TB. El gestor no nos permitiría acceder a ninguna pieza de información por debajo del fichero. Para cada consulta, requerirá descargar los modelos e incluso disponer de otra segunda solución que nos permitiera acceder a la información buscada. 

Este escenario anterior, en la práctica, no sería viable en proyectos de cierta envergadura por su ineficiencia.

 

En resumen, la gestión de la información, es mucho más que la mera gestión de los documentos.

¿Es el CDE una única solución software para el diseño colaborativo?

La gestión de la información de un proyecto es tan compleja y variable, que difícilmente puede abordarse como un proceso homogéneo. Cada tipología de información, los intervinientes, los procesos, la fases y los objetivos que se buscan cubrir, definen unas necesidades particulares de interacción en ese CDE. Estos requisitos y funcionalidades específicas de un proceso definen un caso de uso del CDE.

 

Ejemplo: En un mismo proyecto puede ser necesario usar el CDE para la gestión documental entre los equipos de una obra, y al mismo tiempo, necesitar el CDE para coordinar la producción colaborativa entre las ingenierías del proyecto. 

Ej: Evaluación de ecosistemas propietarios de software en casos de uso específicos del CDE. (Se ha borrado los nombres reales de las casas de software).
Ej: Evaluación de ecosistemas propietarios de software en casos de uso específicos del CDE. (Se ha borrado los nombres reales de las casas de software).

¿Pudiera un único sistema integrar ambas funciones? Seguramente sí, de hecho, ya existen en el mercado plataformas que cubren varios usos del CDE de forma parcial o completa. (De forma análoga a cómo un mismo software cubre varios usos BIM).

 

Pero, vayamos más allá. ¿Sería factible que ese mismo sistema integre los siguientes casos de uso? la captura de datos de seguridad y salud a pie de campo, la gestión contractual entre las partes, el control de las tareas de los procesos de obra, la información GIS medioambiental, la gestión de reclamaciones o la gestión de órdenes de cambio... Todas ellas, son fuentes de información compartidas y casos de uso potenciales a implementar en el CDE del proyecto. 

 

Actualmente, las principales casas de software están creando su propuesta de ecosistema de CDE que cubre los casos de uso más comunes. Ninguna de ellas lo está pudiendo abordar desde un único software. En el gráfico adjunto puede verse un análisis hecho en ACCIONA sobre algunos casos de uso del CDE y cómo las diferentes compañías cubren o no dicha función. 

 

Además, conforme aparezcan nuevos casos de usos, será más difícil abordarlo desde un único software o ecosistema. Incluso, si todo esto fuera posible, querríamos hacerlo…¿Dónde quedarían los beneficios ya interiorizado en el sector del OpenBIM relativos a la transparencia, perdurabilidad, accesibilidad e independencia?

 

En resumen, existen diferentes casos de uso a resolver por soluciones CDE en lo relativo a la gestión de la información del proyecto y esto puede conllevar el uso de un ecosistema de soluciones software

¿El Adjudicador define todo el CDE?

Según la norma EN ISO 19650, el adjudicador es el responsable de definir el CDE de proyecto. Esto tiene todo el sentido, ya que el principal fin de la información generada en el proyecto, es cumplir con los requisitos de información del adjudicador...Pero entonces, si estamos de acuerdo ¿Dónde está el problema de esta simplificación?

 

Bien, en este caso la sobre-simplificación está en el adjetivo “completo”. Si continuamos leyendo la norma, también encontraríamos que la parte adjudicataria principal puede definir el CDE del equipo de desarrollo e incluso que cada una de las partes adjudicatarias podrían definir otras que afecten a sus espacios privados (Work in progress). ¿Esto cómo se traduce? Pues que el adjudicatario definirá las partes del CDE que le interese, dejando aguas abajo, abierto el resto de componentes del CDE al resto de agentes.

 

¿Por qué sucede esto? Pues, por un lado, es debido a que hay casos de uso del CDE que carecen de un valor claro para el adjudicador y con todo derecho no los define.

 

Ejemplo: Un cliente define el gestor documental del proyecto. La parte contratante principal requiere además una herramienta para el control de la calidad a pie de campo.  Ambas soluciones son partes del CDE del proyecto. 

 

En otras situaciones, el cliente solo querrá definir una parte especifica de un uso BIM:

 

 

Ejemplo: Un cliente solo quiere definir la parte del CDE (el uso) relativo a la entrega documental del proyecto y para ello define un gestor documental específico únicamente para las entregas a cliente. La gestión documental entre los equipos de diseño o las transferencias internas de datos entre constructor y subcontratistas no están cubiertas por la solución del cliente y deberán ser definidas por el resto de agentes si así lo consideran. 

Por último, y este caso puede ser algo más difícil de comprender. Puede darse el caso de que un agente defina un uso del CDE concreto en base a unas funcionalidades, que, al no contemplar otras funcionalidades críticas para otro agente, convierta esta solución en poco productiva. Esto puede desembocar en que aparezcan diferentes soluciones para un mismo caso de uso.

Ejemplo: En el caso de un proyecto diseño y construcción, la constructora y la ingeniería principal buscan definir el uso de la producción colaborativa en el CDE. La constructora elige un software A basado a sus necesidades (Trazabilidad, Visores IFC, BCF´s y con aplicaciones móviles para su visualización en obra). Las ingenierías, analizan el Software A y ven que no les encaja ya que no se ha tenido en cuenta funcionalidades críticas para su trabajo (la federación de disciplinas, el control de cambios, auditoría de modelos o la automatización de la producción documental). Es por ello, que definen la colaboración entre las ingenierías en un software B. Finalmente, los espacios de colaboración quedan definidos de la siguiente forma:

CDE, producción colaborativa Estados de la información
Relaciones Work in Progress Shared
Constructor - Constructor Software A Software A
Constructor - Ingenierías <No aplica> Software A
Ingenierías  - Ingenierías Software B Software B

En resumen, las necesidades de los diferentes equipos de trabajo y los estados de la información pueden requerir implementarse en componentes de CDE diferentes para un mismo uso.  

Conclusiones

Como resumen de los puntos anteriores podemos afirmar que:

  • El CDE es más que la gestión documental y la coordinación de BIM.
  • El CDE puede estar compuesto de múltiples soluciones que cubren casos de uso distintos.
  • Un mismo caso de uso del CDE puede estar implementado en varias soluciones software dependiendo del estado de la información o las funcionalidades requeridas por los agentes.

El CDE, debemos verlo como un ecosistema de soluciones de colaboración entre los agentes del proyecto. El número de soluciones que lo componen vienen derivadas de la complejidad del proyecto, los agentes implicados, los casos de uso a implementar y los estados de la información (y seguramente otras variables como la fase de proyecto o el marco contractual).

 

Resulta urgente, que empecemos a desglosar en nuestros EIR y BEP´s, los diferentes casos de uso/ soluciones que componen nuestro CDE. Cuanto antes empecemos a trabajar así, antes pondremos el foco en el verdadero reto del intercambio de la información, la transferencia de información (y metadatos) entre los diferentes software que conforman el CDE del proyecto y el aseguramiento de una única fuente de verdad actualizada.  

Anexo - Ejemplo real de CDE en un contrato Diseño y Construcción

A continuación, se define un ejemplo real de un contrato Diseño y Construccion. En él se muestra un ejemplo de cómo conformar el CDE en un proyecto complejo. Se han tomado las mismas dimensiones explicadas en el documento para su definición. (Agentes implicados, Casos de uso a desplegar y Estado de la información). 

1. El adjudicador define los casos de uso y a los agentes a involucrar en cada área del CDE para la información en estado “Publicado” (Información contractual). En el ejemplo, se define la gestión documental (❶), las ordenes de cambio y RFI´s (❸) y la gestión contractual (❷), en este último caso solo de sus adjudicatarios principales.

2. De igual forma, el adjudicador define la información a gestionar en estado “compartido” (pre-contractual) de los casos de uso de su interés. En el caso concreto de la gest. documental (❶) define la solución software para la aprobación de la documentación generada por parte del adjudicador (Estado S5 en las guías británicas). Dando libertad al resto de agentes para implementar otras soluciones en el resto de estados compartidos de los agentes. (S0-S4). 

3. El adjudicatario principal define los espacios de colaboración compartidos. Tanto los estados compartidos de su equipo de desarrollo (S0-S4) de la gestión documental (❶), como otros los casos de uso del CDE donde el adjudicador no definió a los adjudicatarios por estar fuera de su contrato (❷), e incluso, aquellos nuevos casos de uso de interés para el adjudicatario principal (❹,❺) que no fueron definidos de ninguna forma por el adjudicador. 

4. Por último, los diferentes adjudicatarios (o equipos de trabajo) definen las soluciones propias para el Work in progress. En este caso, el Ad. Principal ha solicitado que para el caso de uso “❸ Ordenes de cambio y RFI´s” se busque una plataforma común y esta ha sido aprobada por las partes.

Autor

Fernando Blanco, Master en Informática gráfica e ingeniero de informática de sistemas.

Empezó a trabajar en 2007 en metodología BIM en el centro de Innovación de ACCIONA. Allí formó la primera unidad BIM de la compañía, desde donde desplegaron los primeros proyectos e implantaciones de la empresa. Tras 10 años como responsable del equipo, pasa en 2017 al departamento de Transformación Digital como Responsable BIM Corporativo de ACCIONA en el negocio de construcción.

Es miembro de la junta directiva de la asociación buildingSMART, vocal del subcomité 13 de AENOR sobre modelos de información en construcción y participó como experto técnico en la iniciativa esBIM del Ministerio de Fomento.