Flujos de trabajo documentales en el CDE: El archivo como motor del proceso informativo ISO 19650

En el mundo AEC tradicional, la gestión de las aprobaciones de un documento de proyecto sigue típicamente este camino: alguien prepara el archivo, lo adjunta a un correo electrónico, lo envía a quien debe revisarlo, espera una respuesta, lo reenvía a otros para comentarios, recopila los feedbacks, carga una versión revisada en un drive compartido, envía otro correo electrónico, espera la aprobación formal.
Es un proceso frágil, no trazado, fácilmente olvidado, dependiente de la memoria individual y totalmente inadecuado para un proyecto complejo con decenas de disciplinas y cientos de contenedores informativos en paralelo.

En un CDE conforme a los principios ISO 19650, los flujos de trabajo documentales sirven para superar esta lógica: son flujos operativos estructurados que guían el contenedor informativo a través de actividades de verificación, revisión, aprobación, compilación de datos y eventual publicación. Pueden ser activados por la carga de un archivo, por una nueva revisión, por un cambio de estado o por una acción del usuario, y están compuestos por pasos secuenciales, responsables, formularios asociados, condiciones de avance y notificaciones.

El punto central es que el archivo ya no es solo un objeto a archivar, sino que se convierte en el desencadenante de un proceso gobernado, trazable y repetible.

Si los estados del contenedor indican dónde se encuentra la información en el ciclo de vida — WIP, Shared, Published, Archived — el flujo de trabajo documental describe cómo el contenedor avanza de un estado a otro, quién debe intervenir, qué controles deben realizarse y qué evidencias deben permanecer en el registro de auditoría.

En este artículo entramos en detalle sobre qué es un flujo de trabajo documental en un CDE, cómo se configura, qué patrones son efectivos y cómo las plataformas CDE más maduras transforman el archivo en motor activo del proceso.

El paradigma: del archivo como objeto al archivo como evento

El salto conceptual que los flujos de trabajo documentales introducen es radical. En el modelo tradicional, el archivo es un objeto: existe, se lee, se modifica, se archiva. En el modelo CDE ISO 19650, el archivo es un evento: su carga subyace a un proceso, su cambio de estado produce notificaciones, su revisión activa nuevos pasos.

Este paradigma tiene implicaciones operativas profundas.

El archivo activa un flujo de trabajo

Una plataforma CDE evolucionada transforma cada documento en un elemento activo del proceso. El archivo cargado activa un flujo de trabajo — un flujo operativo estructurado que guía verificaciones, controles, aprobaciones y compilaciones.

Los usuarios pueden elegir entre flujos de trabajo predefinidos, configurados según los procesos de la organización, y activarlos con una acción simple. Una vez lanzado, el flujo de trabajo se conecta directamente al contenedor informativo y acompaña todas las fases operativas, con una visualización clara del estado de avance.

Cada paso tiene un sujeto involucrado

Para cada paso del flujo de trabajo se identifican los sujetos involucrados, que reciben una notificación y pueden acceder inmediatamente al archivo, a las instrucciones operativas y a las actividades de su competencia. No hay ambigüedad sobre «quién hace qué»: la actividad se asigna de manera explícita y trazable.

El proceso es repetible y estandarizado

A diferencia de la gestión por correo electrónico, un flujo de trabajo definido en el CDE es repetible. El mismo procedimiento de verificación estructural, por ejemplo, puede aplicarse a todos los contenedores informativos estructurales de todos los proyectos de la organización, garantizando coherencia en el proceso.

Anatomía de un workflow documental CDE

Un workflow documental en un CDE conforme a la ISO 19650 está compuesto por elementos estructurales recurrentes. Comprenderlos es el primer paso para diseñar workflows efectivos.

El trigger: qué activa el workflow

El trigger es el evento que inicia el proceso. Puede ser:

• carga de un nuevo contenedor informativo – el trigger más común. El archivo se deposita en una carpeta del CDE y esto activa el workflow asociado a ese tipo de contenido;
• carga de una nueva revisión – una variante específica: el archivo ya existe, pero la carga de una nueva versión activa un nuevo ciclo de verificación;
• cambio manual de estado – el Task Team declara el contenedor «listo para Shared» y esto inicia el proceso de verificación interdisciplinaria;
• plazo temporal – algunos workflows están programados en base temporal, por ejemplo, una verificación periódica mensual de ciertos contenidos;
• acción de un usuario – solicitud explícita de aprobación, de revisión, de cierre de fase.

Los pasos: las fases del proceso

Cada workflow está compuesto por pasos secuenciales (o paralelos, en workflows más sofisticados). Cada paso tiene:

• un responsable – un usuario o un rol que debe actuar;
• una acción prevista – verificación, revisión, aprobación, cumplimentación de formulario;
• una condición de avance – qué debe suceder para pasar al siguiente paso;
• un tiempo máximo (opcional) – SLA más allá del cual se activa una escalada;
• formularios asociados (opcional) – checklist, hojas de verificación, datos estructurados a recopilar.

Las transiciones: cómo se pasa de un paso a otro

Las transiciones no son automáticas: son el resultado de acciones explícitas por parte de los responsables. En un workflow CRA típico:

• aprueba: el contenedor avanza al siguiente paso;
• solicita cambios: el contenedor regresa al Task Team con comentarios;
• rechaza: el workflow se cierra con resultado negativo;
• delega: la responsabilidad del paso se transfiere a otro usuario.

Cada transición deja una huella permanente en el audit trail: quién, cuándo, con qué resultado, con qué comentarios.

Los destinatarios: quién recibe las notificaciones

El workflow debe identificar claramente a quién notificar en cada transición. Un CDE evolucionado gestiona esto automáticamente, enviando notificaciones por correo electrónico. Las notificaciones deben ser contextuales: no solo «hay algo que hacer», sino «debes aprobar el modelo estructural del bloque B rev. P03, antes del 30 del mes».

La salida: qué sucede cuando el workflow termina

Al finalizar, el workflow produce diferentes salidas:

• cambio de estado del contenedor (de WIP a Shared, de Shared a Published, etc.);
• registro en el audit trail del camino completado;
• generación del contenedor historizado de los estados;
• notificaciones de finalización a todos los stakeholders relevantes.

Esquema de un workflow documental CDE

El proceso CRA: Check, Review, Approve

El corazón operativo de casi cualquier flujo de trabajo documental CDE es el proceso CRA (Check, Review, Approve). Se articula en tres fases consecutivas, cada una con responsabilidades y objetivos distintos.

Check — la verificación técnica

El Check es la primera fase. Es una verificación técnica realizada por el Task Team productor o por un referente (típicamente el BIM Coordinator o grupo encargado). El objetivo es asegurar que el contenedor informativo cumpla con los requisitos técnicos básicos antes de ser expuesto a otros sujetos.

¿Qué se verifica en el Check?

• conformidad a las convenciones de nomenclatura del Pliego Informativo;
• completitud de los metadatos obligatorios;
• presencia de todos los elementos previstos por el LOIN para la fase;
• posibles validaciones automáticas (ej. check IDS en los modelos IFC)

El check es realizado por el responsable técnico del Task Team productor. Si el resultado es positivo, el contenedor pasa a Review; si el resultado es negativo, el contenedor regresa a trabajo al Task Team con indicaciones de corrección.

Review — la revisión interdisciplinaria

La Review es la fase de revisión interdisciplinaria y de coordinación. El contenedor — ahora en estado Shared — se expone a los otros Task Teams y al sujeto encargado principal para verificar la coherencia con los otros contenedores del proyecto.

¿Qué se verifica en la Review?

• coherencia interdisciplinaria (detección de conflictos si modelo);
• alineación con otros contenedores relacionados (ej. coherencia entre arquitectónico y estructural);
• correspondencia a los requisitos del Pliego Informativo;
• recopilación de comentarios, problemas (típicamente a través de BCF) y solicitudes de modificación.

La revisión es realizada por otros Task Teams, Lead Appointed Party, y eventualmente el sujeto proponente.

Si el resultado es positivo, el contenedor pasa a Approve; si el resultado es negativo, el contenedor regresa al Task Team (retrabajo) con los problemas abiertos.

Approve — la aprobación formal

El Approve es la fase final y contractual. El contenedor es formalmente aprobado por el Appointing Party (o por el Lead Appointed Party si así lo prevé el Pliego Informativo) y puede pasar al estado Published.

¿Qué se verifica en el Approve?

• completitud del proceso CRA anterior;
• resolución de todos los problemas abiertos;
• conformidad contractual al Pliego Informativo;
• idoneidad para el propósito declarado.

La aprobación final es realizada por el Appointing Party o Lead Appointed Party según CI.

Si el resultado es positivo, el contenedor se convierte en Published; si el resultado es negativo, el contenedor regresa a la Review o al Check dependiendo de la gravedad de las deficiencias.

Proceso CRA en el flujo de trabajo del documento CDE

Variaciones del proceso CRA

El CRA clásico de tres fases no es el único esquema posible. Según la naturaleza del contenedor y las reglas del Pliego Informativo, pueden existir:

• CRA simplificado: Check + Approve, sin Review interdisciplinario (típico para documentos internos no sujetos a coordinación);
• CRA extendido: Check + Review técnica + Review cualitativa + Approve (para contenedores críticos como modelos estructurales o de instalaciones);
• CRA con auditoría externa: CRA + verificación de tercera parte (para contenedores sujetos a validación normativa externa).

Flujos de trabajo predefinidos: la biblioteca de procesos de la organización

Una de las características más poderosas de un CDE maduro es la posibilidad de definir una biblioteca de flujos de trabajo predefinidos, es decir, plantillas de proceso preconfiguradas según los procedimientos estándar de la organización.

¿Por qué son necesarios los flujos de trabajo predefinidos?

Sin flujos de trabajo predefinidos, cada proyecto redefiniría desde cero los procedimientos de verificación y aprobación, con tres consecuencias negativas:

• incoherencia entre proyectos: cada encargo tendría su propio proceso;
• desperdicio de tiempo: cada vez se reinventa la rueda;
• riesgo de no conformidad: sin estandarización, es fácil saltar pasos críticos.

Los flujos de trabajo predefinidos responden a estas necesidades ofreciendo plantillas reutilizables, configuradas según los procedimientos de la organización y activables con una acción simple.

Ejemplos de flujos de trabajo predefinidos típicos

Una biblioteca de flujos de trabajo predefinidos en una organización AEC madura puede incluir:

• flujo de trabajo de verificación de un modelo IFC disciplinario (arquitectónico, estructural, MEP);
• flujo de trabajo de aprobación de un dibujo técnico (plano, sección, detalle constructivo);
• flujo de trabajo de revisión de un documento contractual (pliego, informe técnico, cronograma);
• flujo de trabajo de prueba de un elemento constructivo (estructural, de instalaciones, contra incendios);
• flujo de trabajo de entrega al Facility Management;
• flujo de trabajo de gestión de variantes en curso de obra;
• flujo de trabajo de validación de datos de sostenibilidad (EPD, LCA, informe CSRD).

Configurabilidad vs estandarización

El CDE debe equilibrar dos necesidades opuestas:

• estandarización: los flujos de trabajo deben ser coherentes dentro de la organización;
• configurabilidad: los flujos de trabajo deben poder adaptarse a las especificidades de cada proyecto.

Flujos de trabajo basados en roles: estandarizar sin rigidez

El verdadero salto de calidad de un CDE maduro es la gestión de flujos de trabajo basados en roles – no en personas.

El problema de los flujos de trabajo basados en usuarios

Un flujo de trabajo configurado en usuarios específicos tiene un problema estructural: es rígido y frágil. Si Mario es el verificador estructural y se va de vacaciones, el flujo de trabajo se bloquea. Si Luisa cambia de rol, el flujo de trabajo debe reconfigurarse. Si el proyecto cambia de manos, todo debe replantearse.

Los flujos de trabajo basados en roles

La solución es asociar cada paso a una función lógica en lugar de a una persona. Los roles típicos:

• BIM Manager: supervisión general de la gestión de la información;
• BIM Coordinator: coordinación disciplinaria;
• CDE Manager: gestión operativa del entorno;
• Information Manager: gobernanza informativa general;
• Verificador estructural, MEP, arquitectónico: responsables de disciplina;
• Appointing Party Representative: representante del cliente.

En el momento de iniciar el flujo de trabajo, la plataforma solicita asociar cada rol a la persona correcta dentro del equipo del proyecto. El template permanece estandarizado, la aplicación es flexible y adaptable.

Ventajas operativas

• resiliencia: si la persona asignada está ausente, se puede cambiar la asociación rol-persona sin tocar el flujo de trabajo;
• escalabilidad: el mismo template puede aplicarse a decenas de proyectos con equipos diferentes;
• conformidad UNI 11337-7: la norma italiana sobre roles BIM se convierte en el marco semántico de los flujos de trabajo;
• sencillez de gestión: la configuración operativa se reduce a un mapeo de roles-personas.

Módulos asociados a los flujos de trabajo: la recolección de datos estructurada

Un flujo de trabajo documental CDE avanzado no se limita a gestionar aprobaciones: recoge datos estructurados a lo largo del proceso. El mecanismo son los módulos (listas de verificación digitales, fichas de verificación, controles de calidad) asociados a los pasos del flujo de trabajo.

¿Qué son los módulos?

Un módulo es un conjunto estructurado de campos – textuales, numéricos, booleanos, de opción múltiple, con adjuntos – que recoge información específica sobre un contenedor informativo en un momento determinado de su ciclo de vida.

Ejemplos concretos:

• módulo de verificación estructural: completado por el verificador en el paso de Check, con campos sobre normativas de referencia, coeficientes de seguridad, conformidad a las cargas del proyecto;
• módulo de prueba de incendio: completado al final de la fase constructiva, con campos sobre los REI, sobre los compartimentos, sobre las vías de escape;
• módulo de handover FM: completado en la última fase del proyecto, con datos técnicos para la gestión operativa (manuales, mantenimiento, proveedores, garantías).

Visibilidad condicionada por fase

La característica distintiva es la visibilidad condicionada: los módulos pueden ser visibles o modificables solo en determinadas fases del flujo de trabajo, garantizando que cada usuario opere exclusivamente sobre la información de su competencia.

El módulo de verificación estructural es:

• invisible durante la fase WIP;
• completado solo por el verificador estructural durante la fase de Check;
• visible solo para lectura a los Task Team en la fase de Review;
• congelado y consultable después de la aprobación.

Esto permite gestionar verificaciones, completaciones y validaciones de manera guiada, controlada y progresiva, paso a paso.

Módulos como condición de avance

En flujos de trabajo más sofisticados, la completación de un módulo se convierte en condición de avance; sin la completación del módulo de verificación, el flujo de trabajo no puede progresar. Esto transforma los módulos de simples formularios a verdaderos gate de proceso, garantizando que los datos críticos sean recogidos antes del avance.

Del módulo individual a la base de datos del proyecto

Los datos recogidos en los módulos no permanecen aislados en el contenedor individual. Un CDE avanzado los agrega a nivel de proyecto, haciéndolos consultables en forma tabular, filtrables, ordenables e interrogables. Este es el paso de la gestión documental a la gestión inteligente de la información.

Gestión de revisiones: flujos de trabajo y nuevas versiones

Un tema a menudo subestimado es cómo un CDE avanzado gestiona la relación entre flujos de trabajo y revisiones del contenedor informativo. ¿Qué sucede cuando se carga una nueva versión de un archivo mientras está en curso un flujo de trabajo sobre la versión anterior?

El principio: el flujo de trabajo se interrumpe, la historia permanece

Cuando se carga una revisión actualizada de un contenedor informativo, el flujo de trabajo en curso sobre la versión anterior se interrumpe en el estado en que se encuentra y permanece consultable como referencia histórica. Sobre la nueva versión puede entonces iniciarse un nuevo proceso, coherente con el contenido actualizado del archivo.

Este comportamiento tiene un valor normativo y operativo importante:

• no se pierde la trazabilidad del proceso interrumpido;
• no se crea confusión entre flujos de trabajo de la vieja y la nueva versión;
• el audit trail mantiene evidencia completa de lo que ha sucedido en cada revisión.

Ejemplo concreto

El BIM Coordinator carga la versión 02 de un modelo estructural. Se activa el flujo de trabajo de verificación, que avanza hasta el paso de Review. En Review se detectan incongruencias con el modelo arquitectónico y el Task Team decide revisar el modelo.

Carga la versión 03. En este punto:

• el flujo de trabajo sobre la versión 02 permanece «interrumpido en Review», con todos los comentarios y los problemas abiertos consultables como histórico;
• sobre la versión 03 se inicia un nuevo flujo de trabajo de verificación desde el principio;
• el audit trail registra tanto el recorrido parcial de la versión 02 como el nuevo recorrido de la versión 03;
• no se pierde ningún dato, no se mezcla ningún proceso.

Implicaciones para la elección de la plataforma

No todas las plataformas gestionan correctamente este escenario. Algunas sobrescriben el flujo de trabajo, otras lo mantienen pero sin vincularlo a la nueva versión, otras lo eliminan silenciosamente. Un CDE conforme a ISO 19650 debe garantizar el comportamiento correcto: interrupción trazada, no eliminación, consultabilidad permanente del histórico.

Patrones de flujo de trabajo recurrentes en el sector AEC

A lo largo de los años se han consolidado algunos patrones de flujo de trabajo recurrentes que representan mejores prácticas reconocidas. Aquí están los más comunes.

Patrón 1 — Flujo de trabajo CRA clásico de tres pasos

El flujo de trabajo estándar ISO 19650-2 :

• Check (Equipo de tarea productor) → verificación técnica interna;
• Review (otros Equipos de tarea + Parte designada líder) → revisión interdisciplinaria;
• Approve (Parte designante) → aprobación formal.

Este flujo de trabajo se utiliza en el caso de los contenedores informativos destinados al paso del estado Shared al estado Published, con valor contractual.

Patrón 2 — Flujo de trabajo de validación automática IDS

Es específico para modelos IFC:

• carga del modelo IFC
• validación automática IDS (disparo automático)
• verificación manual si la validación es positiva
• notificación de corrección si la validación es negativa

Es recomendable utilizar este flujo de trabajo para todos los contenedores de tipo modelo IFC en proyectos que adoptan estándares IDS (recomendado para proyectos BIM complejos).

Patrón 3 — Flujo de trabajo de firma digital con marca temporal

Es para documentos contractuales:

• verificación del documento;
• revisión de la Parte designada líder;
• firma digital por parte de la Parte designante;
• aplicación de la marca temporal;
• publicación con código de idoneidad contractual;

Este flujo de trabajo debe utilizarse para los contenedores informativos con valor contractual jurídicamente relevante.

Patrón 4 — Flujo de trabajo de rework loop estructurado

Es para la gestión de iteraciones:

• flujo de trabajo principal (ej. CRA)
• si es rechazado → apertura automática de un sub-flujo de trabajo de corrección con:
  • asignación al Equipo de tarea productor;
  • lista de problemas a resolver;
  • SLA de respuesta;
  • verificación de que todos los problemas han sido cerrados antes de regresar al flujo de trabajo principal.

Este flujo de trabajo es para proyectos complejos con alta probabilidad de iteraciones (ej. nuevas construcciones complejas, infraestructuras).

Patrón 5 — Flujo de trabajo de aprobación paralela

Cuando múltiples partes deben aprobar simultáneamente sin dependencia secuencial:

• carga del contenedor;
• envío paralelo a verificador A + verificador B + verificador C;
• recopilación de las aprobaciones con gestión de conflictos;
• aprobación final solo si todos han aprobado.

Este flujo de trabajo es adecuado para los contenedores que requieren validación multidisciplinaria (ej. un documento de coordinación, una variante compleja).

Patrón 6 — Flujo de trabajo de entrega al Facility Management

Al finalizar el proyecto:

• verificación de completitud en los contenedores Published;
• validación de los datos técnicos para el FM;
• completación de formularios de entrega (manuales, garantías, mantenimiento);
• archivación definitiva.

Este flujo de trabajo es para la fase final del proyecto, el paso de la construcción a la gestión operativa.

Herramienta gratuita para diseñar tus flujos de trabajo

Para aplicar concretamente lo descrito, hemos preparado dos herramientas gratuitas que puedes usar de inmediato:

Prueba el constructor de flujos de trabajo interactivo: crea tu flujo de trabajo personalizado: añade pasos, asigna roles, asocia formularios, configura transiciones. Ve en tiempo real el flujo generado y descarga la configuración en formato legible.

Cómo un CDE evolucionado implementa los flujos de trabajo documentales

No todas las plataformas CDE gestionan los flujos de trabajo de la misma manera. Las implementaciones más maduras se distinguen por algunas características operativas que marcan la diferencia en el uso diario.

Configuración visual de los flujos de trabajo

Una plataforma evolucionada permite configurar los flujos de trabajo visualmente con editores de arrastrar y soltar, diagramas de flujo modificables, vista previa del proceso — en lugar de requerir la escritura de reglas complejas o archivos de configuración. Esto hace que la configuración sea accesible para los BIM Managers y los CDE Managers, sin requerir habilidades de desarrollo de software.

Biblioteca de flujos de trabajo reutilizables

Una plataforma madura ofrece una biblioteca de flujos de trabajo preconfigurados y permite a la organización crear los suyos, guardarlos como plantillas y reutilizarlos en múltiples proyectos.

Integración con formularios estructurados

El flujo de trabajo debe poder activar formularios en los pasos apropiados, con lógica condicional (visibles, rellenables, obligatorios). La plataforma debe gestionar la cumplimentación de los formularios como parte integral del proceso, no como una función separada.

Audit trail completo y no modificable

Cada flujo de trabajo genera un audit trail completo: quién ha actuado, cuándo, con qué resultado, con qué comentarios. Este registro debe ser inmutable — ni siquiera el administrador debe poder alterarlo — y exportable para auditorías externas, litigios, verificaciones de terceros.

Integración con el ecosistema de aplicaciones

En ecosistemas maduros, el flujo de trabajo no es un silo: se integra con las aplicaciones especializadas de la plataforma. Un flujo de trabajo de verificación de un modelo IFC puede activar detección de conflictos, seguimiento de problemas BCF, comparación entre revisiones, validación IDS. Esto transforma el flujo de trabajo en un verdadero orquestador de procesos.

El CDE como ecosistema: los workflows en las plataformas reales

En el ecosistema usBIM de ACCA, la gestión de los workflows documentales es el corazón operativo de usBIM.platform, el CDE conforme a la ISO 19650. Cada contenedor informativo cargado puede activar un workflow, con visualización clara del estado de avance, identificación de los sujetos involucrados en cada paso, notificaciones automáticas, formularios asociados con visibilidad condicionada por fase, gestión coherente de las revisiones con historicidad de los workflows interrumpidos.

Alrededor de la plataforma, las aplicaciones especializadas se integran como acciones ejecutables dentro de los pasos del workflow:

• usBIM.clash para la detección de interferencias activada en el paso de Revisión;
• usBIM.bcf para la gestión de los problemas abiertos durante la Revisión con el estándar BCF;
• usBIM.compare para la comparación automática entre revisiones cuando se inicia un nuevo workflow;
• usBIM.dataquality para la validación automática IDS de los modelos IFC conforme a los requisitos del Pliego Informativo fundamental para workflows de tipo «Pattern 2 (validación automática IDS)»
• usBIM.writer, usBIM.editor para la edición de documentos en las fases de WIP y de rework
• usBIM.facility para los workflows de entrega al Facility Management.

La filosofía es hacer que el workflow no solo sea un proceso de aprobación, sino un orquestador de todas las actividades técnicas necesarias para la producción y validación del contenedor informativo. Un workflow de verificación estructural no es solo «alguien aprueba»: es una secuencia de acciones concretas (clash, validación IDS, seguimiento de problemas, comparación de revisiones, verificación LOIN, compilación de formulario estructural) orquestadas por la plataforma.

Errores comunes en la implementación de workflows documentales

La experiencia muestra que algunos errores se repiten con una frecuencia preocupante. Conocerlos ayuda a evitarlos.

• replicar los procesos de email en el CDE: muchas organizaciones, en su primer acercamiento al CDE, configuran workflows que replican paso a paso los procesos por email existentes. El resultado es un workflow innecesariamente complejo, lleno de pasos redundantes, que no aprovecha las capacidades de automatización de la plataforma. La estrategia correcta es repensar el proceso aprovechando el paradigma CDE, no transponerlo acríticamente;
• workflows demasiado rígidos: workflows con demasiados pasos, demasiadas condiciones obligatorias, demasiados pasos formales tienden a generar frustración en los usuarios y a incentivar el bypass del sistema (ej. los usuarios se envían archivos por email para «acelerar»). Un workflow efectivo es el más simple posible pero no más simple de lo necesario; 
• no definir los tiempos: workflows que no respetan los tiempos de respuesta y criterios de aceptación definidos en el EIR y en el pGI tienden a bloquearse porque «no hay urgencia»;
• asignación a usuarios individuales en lugar de roles: como ya se mencionó, asignar pasos a usuarios específicos en lugar de a roles produce workflows frágiles. Es uno de los errores más comunes en las primeras implementaciones de un CDE.
• formularios demasiado largos o no obligatorios: un formulario de 50 campos se completa de manera superficial. Un formulario opcional no se completa en absoluto. La mejor práctica es pocos campos, claramente obligatorios, con validación automática donde sea posible.
• falta de formación de los usuarios: el workflow más sofisticado es inútil si los usuarios no saben usarlo. La implementación de workflows CDE requiere formación estructurada de los equipos, no solo documentación. El ROI de la formación es altísimo en los primeros 3-6 meses de adopción;
• ninguna revisión periódica de los workflows: los workflows deben ser revisados periódicamente en función de los datos de uso: dónde se bloquean, cuánto duran, qué pasos generan más rework. Sin esta iteración, los workflows se vuelven obsoletos e ineficaces.

Preguntas frecuentes (FAQ)

¿Qué es un workflow documental en un CDE?

Un workflow documental en un CDE conforme a la ISO 19650 es un flujo operativo estructurado activado por la carga de un contenedor informativo, que guía actividades de verificación, revisión, aprobación y compilación de datos. Está compuesto por pasos secuenciales con responsables, formularios, condiciones de avance y notificaciones automáticas, y realiza operativamente el proceso CRA (Check, Review, Approve) normado por la ISO 19650-2.

¿Qué es el proceso CRA (Check, Review, Approve)?

El CRA es el proceso de verificación, revisión y aprobación para el paso de los contenedores informativos de WIP a Shared a Published:

• check: verificación técnica interna del Task Team;
• review: revisión interdisciplinaria;
• approve: aprobación formal de la Appointing Party. Cada fase tiene responsables, condiciones de avance y puede producir rework hacia las fases anteriores.

¿Cómo se activa un workflow en un CDE?

Un workflow en un CDE conforme puede ser activado por: carga de un nuevo contenedor informativo, carga de una nueva revisión, cambio manual de estado, vencimiento temporal, acción explícita de un usuario.

¿Cuál es la diferencia entre workflows basados en usuarios y workflows basados en roles?

Un workflow basado en usuarios asigna los pasos a personas específicas (ej. «Mario debe aprobar»). Es rígido: si Mario está ausente, el workflow se bloquea. Un workflow basado en roles asigna los pasos a funciones lógicas (ej. «el verificador estructural debe aprobar»). En el momento del inicio, la plataforma solicita asociar el rol a la persona correcta. Es más resiliente, escalable y reutilizable entre proyectos.

¿Qué son los formularios asociados a los flujos de trabajo?

Los formularios son conjuntos estructurados de campos (listas de verificación, hojas de verificación, controles) asociados a los pasos de un flujo de trabajo. Recogen datos estructurados a lo largo del proceso. En un CDE avanzado tienen visibilidad condicionada por fase: son visibles o rellenables solo en las fases de competencia de cada usuario. Los formularios pueden ser obligatorios para el avance del flujo de trabajo, convirtiéndose en puertas de proceso.

¿Qué sucede con el flujo de trabajo cuando se carga una nueva versión?

Cuando se carga una nueva versión de un contenedor informativo, el flujo de trabajo en curso sobre la versión anterior se interrumpe en el estado en que se encuentra y permanece consultable como referencia histórica. En la nueva versión comienza un nuevo flujo de trabajo coherente con el contenido actualizado. El rastro de auditoría conserva ambos caminos, garantizando plena trazabilidad.

¿Se pueden tener flujos de trabajo predefinidos reutilizables?

Sí. Una plataforma CDE avanzada ofrece una biblioteca de flujos de trabajo predefinidos — plantillas preconfiguradas según los procedimientos de la organización — activables con una acción simple. Las plantillas son típicamente paramétricas: los roles y algunas variables (tiempos máximos, formularios opcionales) se personalizan en el momento del inicio, preservando la estandarización del proceso y la flexibilidad aplicativa.

¿Cuáles son los patrones de flujo de trabajo más comunes en el sector AEC?

Los patrones recurrentes incluyen: CRA clásico de tres pasos (Check, Review, Approve), flujo de trabajo de validación automática IDS para modelos IFC, flujo de trabajo de firma digital para documentos contractuales, flujo de trabajo de rework loop para la gestión de iteraciones, flujo de trabajo de aprobación paralela para contenidos multidisciplinarios, flujo de trabajo de handover al Facility Management para la fase final del proyecto.

¿Cómo se integran los flujos de trabajo con las aplicaciones especializadas del CDE?

En un ecosistema maduro, los pasos del flujo de trabajo pueden activar aplicaciones especializadas: detección de conflictos, validación IDS, seguimiento de problemas BCF, comparación entre revisiones, edición documental, firma digital. El flujo de trabajo se convierte así en un orquestador de procesos que coordina no solo aprobaciones sino también actividades técnicas. Es el nivel más avanzado de integración.

¿Qué es el rastro de auditoría de un flujo de trabajo?

El rastro de auditoría es el registro permanente y no modificable de todas las acciones realizadas durante un flujo de trabajo: quién ha actuado, cuándo, con qué resultado, con qué comentarios. Es el fundamento de la trazabilidad requerida por la ISO 19650 y es indispensable para auditorías de conformidad, litigios contractuales y verificaciones de terceros. Un CDE conforme garantiza que el rastro de auditoría sea inmutable y exportable.

¿Es posible modificar un flujo de trabajo ya iniciado?

Depende de la plataforma y de la fase. En general, un flujo de trabajo en curso no debería ser modificado estructuralmente porque esto comprometería la trazabilidad. Algunas plataformas permiten pequeñas modificaciones (por ejemplo, reemplazar a la persona asociada a un rol) manteniendo la pista. Las modificaciones estructurales requieren típicamente el cierre del flujo de trabajo y el inicio de uno nuevo.

¿Cómo se evalúa la efectividad de un flujo de trabajo?

La efectividad de un flujo de trabajo se evalúa analizando métricas operativas: tiempo medio de finalización, número de rework, porcentaje de SLA cumplidos, puntos de bloqueo recurrentes, carga de trabajo por rol. Un CDE maduro proporciona estas métricas a través del panel de control del proyecto, permitiendo iterar sobre los flujos de trabajo en base a datos objetivos.

Glosario esencial

• Approve – fase final del proceso CRA: aprobación formal del contenedor por parte de la Appointing Party.
• Audit trail – registro permanente y no modificable de las acciones realizadas durante un flujo de trabajo.
• BCF – BIM Collaboration Format. Estándar openBIM para la gestión de problemas.
• Check – Primera fase del proceso CRA: verificación técnica interna del Task Team productor.
• CRA – Check, Review, Approve. Proceso de verificación, revisión y aprobación normado por la ISO 19650-2.
• Gate de proceso – Condición obligatoria (por ejemplo, cumplimentación de formulario) que debe ser satisfecha para el avance del flujo de trabajo.
• Formulario – Conjunto estructurado de campos asociado a un paso del flujo de trabajo para la recopilación de datos estructurados.
• Review – Segunda fase del proceso CRA: revisión interdisciplinaria del contenedor.
• Rework loop – Ruta de retorno del contenedor a fases anteriores después de la detección de no conformidades.
• SLA – Service Level Agreement. Tiempo máximo definido para la finalización de un paso.
• Step – Fase elemental de un flujo de trabajo, con responsable, acción prevista y condición de avance.
• Template de workflow – Flujo de trabajo preconfigurado, reutilizable y paramétrico, guardado en la biblioteca de la organización.
• Transición – Paso de un paso al siguiente en un flujo de trabajo, determinado por una acción explícita.
• Trigger – Evento que activa automáticamente un flujo de trabajo (carga de archivo, revisión, vencimiento, etc.).
• Workflow predefinido – Plantilla de flujo de trabajo preconfigurada según los procedimientos de la organización.