[#8] INTRODUCCIÓN A LA CONFIGURACIÓN Y USO DE UN ENTORNO COMÚN DE DATOS

La gestión de la información es clave para una dirección eficaz de proyectos y obras. No aplicar una sistemática adecuada genera problemas, sobrecostes y riesgos de cometer errores graves, pero, sobre todo, impide trabajar colaborativamente, algo ya impensable en la actualidad.

Para dejar atrás las prácticas convencionales son necesarias dos acciones importantes: identificar la documentación que se empleará o generará a lo largo de la vida de la infraestructura (diseño, construcción y operación) y organizar la gestión de la información (quién, para quien, cómo y cuándo se debe producir). En definitiva, definir lo que en BIM se denominan Requisitos de Información del Proyecto (PIR).

Los dos pasos anteriores son de naturaleza conceptual y se resuelven sin herramientas tecnológicas especiales, sin embargo en el último post se anticipó que para gestionar la información se precisa una solución técnica específica para la gestión documental y unos flujos de trabajo asociados. A esto se denomina Entorno Común de Datos (CDE), una herramienta básica e irrenunciable para la gestión avanzada de un proyecto o de una obra.

Me comprometí a escribir una entrada sobre esta materia lo antes posible, pero debo confesaros que la amplitud del reto me convirtió temporalmente en un procastinador. No veía la manera de hincarle el diente a un tema tan extenso y con tantas ramificaciones, ni de cómo explicarlo de un modo resumido y entendible para quien no esté introducido en las técnicas de dirección de proyectos.

Para empujarme a escribir reduje las expectativas de esta entrada. No será un manual para que implantéis y configuréis un Entorno Común de Datos (me suelo venir arriba con facilidad); me daré por satisfecho si fuera capaz de identificar algunos hilos maestros que os permitan descubrir la importancia de esta materia y avanzar por vuestra cuenta.

Aunque yo me inicié en el uso de estas herramientas hace más de quince años, cuando los estándares para la dirección de proyectos me eran desconocidos, creo para una aproximación óptima sigue siendo necesaria una mínima base conceptual como la que encontrareis en el post #7, principalmente en lo que se refiere a la asignación de responsabilidades (matriz RACI) y a la definición de las funciones para la producción de la información.

LA FUNCIÓN HACE AL ÓRGANO

En la reseña biográfica de este blog resumí el proceso que en el año 2007 me empujó, junto a mi compañero Julio Salgado, a buscar una manera de trabajar más profesional, menos intuitiva y más eficiente.

Ya habíamos experimentado antes cómo la exigencia en un área de gestión contagiaba a otras. Esto sucedió cuando dirigíamos la obra de una importante depuradora con un esfuerzo y dedicación inversamente proporcional al grado de planificación; era una obra donde nos enterábamos de los procedimientos constructivos poco antes de empezar los tajos y el cronograma era un papel enorme que decoraba el despacho, pero poco más.

Esto cambió cuando la coordinadora de seguridad y salud comenzó a preguntar lo obvio y razonable: ¿cómo se van a ejecutar los trabajos?, ¿dónde se ponen las grúas y los demás medios auxiliares?, etc. Esta información, imprescindible para la seguridad y salud, nos permitió anticipar los posibles problemas en la calidad de la ejecución de la obra. Paradójicamente, la seguridad y salud nos ayudó a trabajar de un modo más organizado y con más calidad.

Algo parecido nos sucedió más tarde, alrededor de 2008, cuando por casualidad nos contactó el responsable de una empresa desconocida para nosotros: ACONEX. Nos planteó problemas de gestión de la información y de la comunicación que nos resultaban familiares, pero también de soluciones que ni se nos habían pasado por la imaginación. Nos habló de la configuración de la información, de estatus de documentos, de flujos de aprobación, etc. En definitiva, nos estaba presentando, ni más ni menos, las características de un Entorno Común de Datos, cuando aún faltaban años para la irrupción de BIM.

Al igual que nos sucedió con la seguridad y salud, la mejora de la gestión de la documentación nos obligó a anticipar la documentación que íbamos a emplear en las obras, a identificarla con un código y a emplear flujos de trabajo. En resumen, nos hizo ver que era posible trabajar de un modo más organizado y en colaboración con el contratista y, sin darnos cuenta, nos introdujo anticipadamente en el mundo BIM.

Creo que emplear un Entorno Común de Datos es poner unos cimientos que harán viable cualquier sistema de dirección de proyectos, desde el más simple hasta la gestión BIM en el nivel de madurez 2. Merece la pena ponerse a ello ya que os va a demandar, de un modo natural, un mayor grado de organización, con las ventajas que conlleva, y os introducirá hacia el mundo BIM por su parte más sustancial: la gestión de la información.

CONFIGURACIÓN DEL ENTORNO COMÚN DE DATOS

El Entorno Común de Datos (CDE) se emplea cuando una organización debe producir documentos que serán aprobados por otra, de un modo controlado. En términos de la norma ISO 19650 , que establece los requisitos para una gestión BIM, hablamos de la parte contratada, la que desarrolla la documentación, y de la parte contratante, quien la recibe y aprueba.

Recordemos que no es necesario que medie un contrato para asignar esos roles. Por ejemplo, el equipo de dirección de obra también puede ejercer el papel de parte contratante cuando elabora un documento que deba ser aprobado por su organización. A su vez, un contratista de una obra también es parte contratante respecto a los subcontratistas, por lo que cabe hablar de un CDE entre ambos.

La configuración del CDE corresponde a la dirección de la obra, y establece la organización, las reglas básicas y la información necesaria para la gestión de la información producida. No debe confundirse con el Plan de Ejecución BIM, que es responsabilidad del contratista y tiene otros objetivos.

Algunas cuestiones que forman parte de la configuración del CDE son:

• Organizaciones y personal (funciones) que tendrán acceso al CDE
• Organigrama del proyecto en el que se muestran los diferentes ámbitos de gestión y las organizaciones implicadas.
• Definición de los roles de los miembros de las organizaciones que intervendrán en el proyecto
• Fases del proyecto asociadas a intercambios de información clave.
• Ámbitos de gestión de la información.
• Definición de los estatus de los documentos.
• Permisos de accesos y de cambios de documentos.
• Codificación de documentos: ID y metadatos:
  • Definición de los campos de codificación
  • Definición de disciplinas
  • Definición de tipos de documentos
  • Definición de áreas funcionales
• Características de la solución técnica del CDE.
• Definición de flujos de trabajo.
• Sistema de revisión de versiones.
• Gestión de las comunicaciones

DESCRIPCIÓN BÁSICA DE UN PROCESO SIMPLE DE PRODUCCIÓN DE INFORMACIÓN

Para comprender y generalizar el proceso de producción de información es muy importante tener en mente las características de los diferentes agentes (roles o funciones) que intervienen:

Equipo de trabajo	Conjunto de individuos organizados para realizar una tarea específica.
Equipo de desarrollo	Formado por la parte contratada principal y sus partes contratadas. El promotor también puede constituir un equipo de desarrollo ya que puede actuar como parte contratada, cuando tiene que producir información.
Parte contratada	Proveedor de información relacionada con obras, bienes o servicios. Pese al nombre, no es necesario que exista una relación contractual.
Parte contratada principal	Es una parte contratada que provee información a la parte contratante.
Parte contratante	Receptor de información relacionada con obras, bienes o servicios. Tampoco es necesario que exista una relación formal, de hecho este término no se refiere exclusivamente al cliente. Un contratista puede ser una parte contratante respecto a sus subcontratistas.

Por otra parte, recordemos las responsabilidades definidas en la matriz RACI:

Responsable	Es la persona que debe realizar una tarea. Tiene capacidad para tomar decisiones vinculadas directamente con ella e incluso para delegar a un tercero su ejecución, sin perder la responsabilidad de realizarla.
Autorizador	Debe vigilar el proceso, verificar que se completó y responder por la tarea. Tiene que hacer que se complete y que se cumplan los requisitos previstos aplicables para la organización receptora del trabajo. Será una única persona, ya que esta responsabilidad no puede ser compartida. Excepcionalmente puede coincidir con el responsable.
Consultor	Es la persona consultada durante el proceso de producción de la información. Proporciona información útil para realizar o completar la tarea.
Parte informada	Es una persona o grupo de personas que, a diferencia de los consultores, son receptores de la información al concluir el proceso. Excepcionalmente pueden ser informados con anterioridad a finalizar el proceso, pero la comunicación es de carácter unidireccional.

El tercer elemento conceptual son los diferentes estatus de un documento, que establecen los usos permitidos a lo largo de la producción de la información. Generalmente se emplean los siguientes: Trabajo en curso (work in progress, WIP), Compartido, Publicado y Archivado.

En la siguiente gráfica se resume un proceso genérico de producción de información. En ella se identifican la mayor parte de los agentes y conceptos indicados anteriormente. El recorrido se inicia en la zona de trabajo en curso, a la que se puede volver en función de las iteraciones asociadas a las revisiones. Os animo a que sigáis en esta figura el proceso que describiré a continuación.

Imaginemos que se trata de producir un anejo del proyecto relativo al cálculo de la estructura de un porche. El equipo de trabajo designado por el contratista elabora el primer documento, que es revisado por el responsable de ese equipo. El documento se denomina, por ejemplo, EstructuraPorticoPorche_V01.1. (Obsérvese cómo varía la denominación de la versión a lo largo del proceso).

Este documento se comparte con el equipo del contratista (en WIP no era visible para nadie más que el equipo de trabajo). Supongamos que el Jefe de obra, en calidad de autorizador, determina que esta primera versión no cumple los requisitos y lo rechaza. El equipo de trabajo realiza otra versión del documento, que denomina EstructuraPorticoPorche_V01.2. Si el autorizador del contratista (el jefe de obra, en este ejemplo) considera que ahora sí cumple los requisitos, le cambia el estatus a “autorizado para compartir” (o compartido) y envía el documento al área compartida con la dirección de obra en su versión 1: EstructuraPorticoPorche_V01. (ha desaparecido el contador de revisiones del equipo del contratista)

El equipo de dirección de obra lo estudia y puede determinar rechazarlo, aprobarlo con comentarios (lo que significa que puede emplearse la información para que el proyecto avance, pero que se espera una nueva versión con cambios menores) o bien aprobarlo. La aprobación suele reservarse al director facultativo.

Cuando el documento en su versión 1 se rechaza, se repite el proceso, de manera que el equipo de trabajo genera la versión EstructuraPorticoPorche_V02.i, donde i se corresponde con el número de iteraciones que deben realizarse hasta que el autorizador del contratista lo comparte con la dirección de obra.

Nótese que no hay un único CDE. El contratista tiene un área compartida con sus equipos de trabajo y otra área con la dirección de obra. A su vez, la dirección de obra podrá tener un área compartida con su asistencia técnica, donde se gestiona la información que ésta deba producir para la dirección de obra, pero que no forma parte de la documentación contractual del contratista.

FLUJOS DE TRABAJO

El trasiego de información descrito anteriormente podría materializarse mediante sucesivos correos electrónicos, pero no sería posible controlar el estado de revisión de cada documento ni organizar incluso procesos de revisión poco complejos, como el representado en la siguiente figura, que corresponde a la aprobación de un anexo de seguridad y salud.

En este ejemplo, el flujo se inicia cuando el autorizador de contratista comparte un documento para su aprobación. El primer paso de este flujo corresponde a una revisión en paralelo, de manera que la aceptación de uno cualquiera de los tres miembros (director de obra, supervisor de calidad, Jefe de unidad de AT) genera el envío automático del documento al coordinador de seguridad y salud, a quien corresponde su aprobación. En ese segundo paso, los revisores podrán incluir comentarios en el propio documento o en otros que adjunten al flujo.

Si el documento es correcto, el coordinador, en este caso, cambiará su estatus a “aprobado” y se transmitirá a todos los intervinientes u otros agentes que figuren en el flujo. Este documento y su archivo tendrán una identificación según los campos acordados y unos metadatos que permitirán su posterior localización.

LOCALIZACIÓN DE DOCUMENTOS: ARBOLES DE DIRECTORIOS Y METADATOS

Una de las funciones que le pedimos a un gestor documental es la facilidad para encontrar los documentos y la fiabilidad de que se trate de la última versión. Tanta es nuestra necesidad de saber donde los hallaremos, que confundimos frecuentemente la planificación de los documentos con la creación de un árbol de directorios. Nos genera mucha tranquilidad saber que contamos con cajones para guardar los documentos, pero no caemos en la cuenta de que los directorios son, en realidad, una consecuencia de la planificación de la información, y no su origen.

Aconex, que es una solución técnica muy madura para la gestión de la documentación de proyectos, no emplea directorios. ThinkProject, que es otra solución técnica que he empleado, aparentemente utiliza carpetas, pero es todo un espejismo. Las carpetas las organiza a partir de los metadatos de cada documento. Así, cuando buscamos un documento en esas carpetas, en el fondo, estamos activando un filtro en nuestro gestor documental.

En conclusión, la localización de los documentos en un gestor documental no se basa en una estructura de directorios o carpetas, si no en la adecuada codificación empleada en el registro de los documentos, que incluye su identificación (ID) y los metadatos. Si queréis profundizar en estas cuestiones os aconsejo este manual de building SmartSpain y esta otra de UK Bim Alliance, de lectura obligada para los que queráis profundizar en esta importante materia.

¿POR DÓNDE EMPIEZO PARA CONFIGURAR MI CDE?

En el caso de que queráis aplicar en vuestras obra una gestión de la información basada en el concepto de CDE tendréis que decidir si el CDE lo creáis en vuestra organización o si compráis el servicio.

Aparentemente, un CDE se puede montar con un gestor o un repositorio de archivos y unos flujos de trabajo asociados. Esta percepción es un tanto temeraria si no tenéis experiencia previa y puede dar muchos problemas en la práctica. En mi tierra hay una expresión que se pone en boca de quien sin tener conocimiento se lanza a ejecutar una tarea: “eu tamén vou, que tamén sei“. ¡No seáis temerarios!

En estos casos, mi consejo es comprar el servicio a una empresa especializada, como puede ser ACONEX o ThinkProject. Este servicio comienza y finaliza con la obra y no afectará a los sistemas informáticos de vuestra organización, aparte de albergar otras muchas ventajas.

Uno de los principales efectos colaterales beneficiosos del empleo de un sistema externo, estructurado profesionalmente y que ha recogido buenas prácticas de infinidad de proyectos, es que nos va a obligar a trabajar con una sistemática común y con garantías de mantener la configuración del sistema de gestión. Como decía en el apartado anterior, la función hace al órgano, y lo mismo sucede si empleamos una herramienta apropiada: hace que todos los involucrados trabajen alineados.

Ahora bien, los suministradores de estos servicios no son consultores, así que la dirección de obra deberá liderar la configuración del sistema de gestión, aunque pueda contar con los proveedores de servicios y con el contratista de la obra para recabar sugerencias. Ya os advertí que la dirección de proyectos obliga a los directores de obra a abandonar la tradicional posición reactiva y nos coloca como auténticos líderes del proyecto u obra.

CONCLUSIONES

• La organización de la información de un proyecto comienza con la identificación detallada de la documentación que se empleará a lo largo de la vida de la infraestructura (diseño, construcción y operación) y con la organización de su gestión (quién, para quién, cómo y cuándo se debe producir).
• Una parte fundamental de la gestión documental es definir el sistema de codificación de los documentos y los metadatos que se asignarán. La localización posterior de estos documentos y el conocimiento de su estatus se basan en esa información, y no en el lugar que ocupen en un sistema de directorios o carpetas.
• Para organizar la producción de la información, la dirección del proyecto o de la obra debe implantar y configurar un Entorno Común de Datos (CDE), que es una combinación de una solución técnica de gestión de documentos y un sistema de flujos de trabajo.
• La responsabilidad de organizar y configurar el CDE es de la dirección del proyecto o de la obra, no del contratista ni, en su caso, del suministrador de los servicios de gestión documental.
• Aunque es posible que una organización cuente con un sistema de gestión documental que pueda disponer de las funcionalidades básicas de un CDE, resulta más operativo contratar la solución técnica a empresas especializadas, como pueden ser Aconex o ThinkProject.
• Planificar la información de un proyecto o de una obra y emplear el CDE es un ejercicio con indudables ventajas para la gestión general del proyecto pero, sobre todo, es el modo más auténtico y práctico de incorporarse al mundo BIM.