Un flujo de trabajo BIM (en inglés, workflow BIM) es el recorrido que sigue la información de un proyecto desde que alguien la pide hasta que se publica como entregable y queda archivada. Visto desde quien firma, tiene ocho pasos: pedir la información, producirla, comprobarla, compartirla y coordinarla, verificarla contra la normativa, autorizarla y aceptarla, publicarla y archivarla. Entre esos pasos hay puertas: momentos en que una persona decide si la información avanza. Esta guía recorre cada paso, dice quién decide en cada puerta, qué se comprueba y qué evidencia debería quedar, y separa lo que se puede automatizar de lo que no, porque automatizar un paso no es automatizar la decisión.
La secuencia es nuestra. Ordena el proceso de gestión de la información de la ISO 19650 tal como lo explican guías públicas y le añade la verificación normativa, que la norma no trata. La ISO 19650 es de pago y aquí no se reproduce: lo que se le atribuye sale de sus fichas de catálogo y de la guía de conceptos de Build Digital. El marco completo está en la guía ISO 19650 para el BIM Manager.
Qué es un flujo de trabajo BIM y por qué la palabra tiene dos sentidos
En el sector, «flujo de trabajo BIM» (o workflow BIM) nombra dos cosas distintas:
- El proceso entre personas. Quién produce cada información, quién la revisa, quién la autoriza y quién la acepta, en qué orden y con qué documentos. Es lo que describe la ISO 19650 y lo que fijan los requisitos de información y el BEP de cada proyecto. Está hecho de decisiones.
- La automatización. Una cadena de pasos que ejecuta un programa: lanzar una comprobación, avisar a alguien, guardar un registro, reunir unos ficheros. Está hecha de tareas repetibles.
Las dos hacen falta y no son intercambiables. Una automatización puede lanzar una comprobación cada noche, pero no puede decidir si una incidencia es real ni aceptar una entrega en nombre del cliente. Cuando un flujo automático se salta una puerta, el error no desaparece: llega más tarde, y muchas veces a obra.
Build Digital, en su guía de conceptos de la ISO 19650-1, describe el ciclo de entrega de información de punta a punta: el cliente define al principio qué información necesita y por qué, los proveedores explican cómo la van a dar, las partes acuerdan funciones, planes y formación, deciden cuánta información hace falta en cada etapa y cómo se va a verificar, la producen con sus procesos y su tecnología y, al final, la entregan para que el activo se pueda operar y mantener. Los ocho pasos de esta guía son ese ciclo visto desde una entrega concreta.
El recorrido de una entrega, de un vistazo
| Paso | Quién decide | Qué se decide en la puerta | Qué evidencia queda |
|---|---|---|---|
| 1. Pedir la información | El adjudicador pide; el adjudicatario principal responde | Qué se entrega, cuándo, con qué nivel de información y cómo se revisará | El EIR y el BEP, con su versión |
| 2. Producir | El equipo de tareas | Nada todavía: es trabajo en curso | Las versiones en el entorno común de datos |
| 3. Comprobar | El responsable del equipo de tareas | Si la información está hecha como se acordó y es correcta | El registro de control de calidad |
| 4. Compartir y coordinar | El responsable del equipo de tareas aprueba compartir; el coordinador cierra la coordinación | Si otros pueden trabajar encima y qué incidencias quedan abiertas | El estado Compartido y el registro de incidencias |
| 5. Verificar la normativa | Quien responde del proyecto | Qué hacer con cada resultado | Un resultado por regla, con su cita |
| 6. Autorizar y aceptar | El adjudicatario principal autoriza; el adjudicador acepta | Si responde a lo pedido y si le sirve al cliente | Quién decidió, cuándo y sobre qué versión |
| 7. Publicar | Nadie nuevo: se ejecuta la decisión del paso 6 | — | El contenedor en Publicado, de solo lectura |
| 8. Archivar | Durante el proyecto nadie: lo registra la solución que hace de CDE. Qué se conserva al cierre lo fija el contrato | — | Qué información estaba vigente en cada momento |
Los roles son los que explica la guía de la ISO 19650: el adjudicador encarga el trabajo, el adjudicatario principal responde del encargo ante él y cada equipo de tareas produce su parte. En tu organización pueden llamarse promotor, BIM Manager, coordinador BIM o jefe de proyecto. Lo que importa es que cada decisión se pueda atribuir a una persona concreta.
El ciclo no se recorre una vez: se repite en cada hito de entrega de cada fase del proyecto, con los nombres de fase que use tu contrato (anteproyecto, proyecto básico, proyecto de ejecución u obra, en España; en otros países cambian).
Pedir la información: requisitos, BEP y nivel de información
Todo flujo empieza antes del primer muro. El adjudicador escribe en el EIR qué información necesita, cuándo y con qué nivel de información necesario. El adjudicatario principal responde con el BEP, que dice cómo la va a producir su equipo, y con el plan de entregas. Según Build Digital, cada equipo de tareas prepara su programa de desarrollo de información de la tarea (TIDP), con la secuencia, las dependencias y la duración de lo que va a producir; el adjudicatario principal los reúne en el programa general de desarrollo de la información (MIDP) de su equipo y fija una matriz de responsabilidades, a menudo llamada RACI.
- La puerta: antes de producir, el BEP tiene que estar acordado. Si no dice qué se entrega en cada hito, con qué nivel de información y cómo se va a revisar, todas las puertas siguientes se discuten sin referencia.
- La evidencia: el EIR, el BEP y el plan de entregas, cada uno con su versión.
- Qué se puede automatizar: recordar las fechas de los hitos y comprobar que cada entregable del plan tiene responsable y fecha. Qué se pide y si el BEP responde a ello lo deciden personas.
Cómo se escribe el BEP está en la guía del plan de ejecución BIM (BEP), y cómo se pide la información sin malentendidos, en LOD y LOIN: en qué se diferencian.
Producir: el trabajo en curso
Cada equipo de tareas produce su información en su espacio de trabajo en curso (work in progress), que los demás todavía no usan. Aquí no hay una puerta formal, pero sí dos hábitos que ahorran discusiones después: nombrar los ficheros con la nomenclatura del BEP desde el primer día, como explica la guía de nomenclatura según la ISO 19650, y modelar los datos que pide el nivel de información de la próxima entrega, no los de la última.
- Qué se puede automatizar: las tareas repetitivas de modelado y de datos, como renombrar elementos según el patrón del BEP o rellenar un parámetro que se calcula a partir de otros. Toda escritura automática en el modelo debería dejar rastro, y las que borran o sustituyen información, pasar antes por la confirmación de una persona.
Comprobar antes de compartir
Antes de que la información salga del trabajo en curso, el equipo que la produjo la comprueba contra los métodos y los estándares acordados y revisa su contenido contra los requisitos. Build Digital lo dice sin rodeos: la información de un equipo de tareas se comparte según el EIR, el BEP y los planes de entrega, y solo después de que su responsable la haya revisado y comprobado.
- La puerta: el responsable del equipo de tareas decide si la información sale.
- Qué se comprueba: la organización y la nomenclatura, la geometría y la ubicación, la información y los parámetros, y la salud del fichero. La lista de control de calidad del modelo BIM lo baja a capas, y la guía para auditar un modelo de Revit antes de entregarlo cubre avisos, purga, vínculos y subproyectos.
- La evidencia: un registro con qué se revisó, contra qué versión del BEP, qué salió y qué no se pudo comprobar.
- Qué se puede automatizar: casi todo lo que tiene una regla escrita: el nombre contra el patrón del BEP, que un parámetro obligatorio exista y no esté vacío, los avisos de Revit, los duplicados. Que un valor relleno sea verdadero, no: una resistencia al fuego copiada de otro tipo pasa cualquier comprobación de presencia.
Compartir y coordinar entre disciplinas
Compartir no es entregar. La información pasa al estado Compartido para que los demás equipos coordinen sobre algo estable, pero todavía no es un entregable final. Coordinar es comprobar que los modelos encajan: que un conducto no atraviesa una viga, que queda espacio para mantener un equipo, que la estructura prevé los pasos de instalaciones y que todos usan los mismos niveles, ejes y origen.
- La puerta: cuándo se da por cerrada la coordinación de esa entrega. La decide el coordinador, no la herramienta. Según Build Digital, cuando la coordinación en Compartido termina y los modelos son compatibles se pasa a la revisión y la autorización.
- La evidencia: un registro de incidencias con su estado, su responsable y su plazo, no una captura suelta en un correo. Para intercambiarlas entre programas existe el formato BCF, que explicamos en el glosario BIM.
- Qué se puede automatizar: la detección de interferencias entre disciplinas (choques o colisiones), la creación de las incidencias y el aviso a cada responsable. Qué interferencia es real, cuál se acepta y quién la resuelve es criterio del coordinador: muchas de las que encuentra una máquina no son problemas reales.
Verificar contra la normativa
La ISO 19650 organiza cómo circula la información; no dice si los elementos del modelo respetan la normativa de construcción del país. Esa comprobación es aparte, y que entre o no en la revisión de cada entrega lo decide el proyecto.
- La puerta: quien responde del proyecto decide qué hacer con cada resultado: corregir, justificar una excepción o dejar constancia de lo que no se pudo juzgar.
- Qué se comprueba: los elementos sobre los que una norma fija un requisito medible, como anchos de paso en recorridos de evacuación, alturas libres o dimensiones de escaleras. Y antes, que el modelo traiga el dato que la norma mide: el ancho libre de paso de una puerta, no la anchura nominal de su familia. Qué comprueba OrionBIM de todo eso depende de las reglas cargadas para el país, como se explica al final de la guía.
- La evidencia: un resultado por regla y por elemento, con la cita literal del artículo del que sale el umbral, y lo que no se pudo juzgar declarado como tal.
- Qué se puede automatizar: la comparación de un dato con un umbral citado, que es determinista: mismo modelo, misma regla, mismo resultado. Qué norma y qué edición aplican, las excepciones y lo que el modelo no representa son de una persona. Una IA puede ayudar a leer y a explicar un resultado; no debe emitir el veredicto.
- OKEl dato del modelo está dentro del umbral de la regla citada.
- RevisarHay una señal que exige juicio profesional antes de darla por buena.
- Fuera de rangoEl dato del modelo queda fuera del umbral de la regla citada.
- No auditableNo hay base para juzgar ese punto: ni incumplimiento ni aprobado.
El detalle está en la guía de verificación normativa del modelo BIM y, para un país concreto, en la de la normativa de construcción en República Dominicana.
Autorizar y aceptar: las dos decisiones antes de publicar
Pasar de Compartido a Publicado son dos decisiones sucesivas. El adjudicatario principal revisa el modelo de su equipo y lo autoriza; el adjudicador lo revisa y lo acepta. Según su ficha de catálogo, la parte 4 de la ISO 19650 detalla el proceso y los criterios de decisión de cada intercambio de información, para asegurar la calidad del modelo de información resultante. Si tu contrato la cita, es donde buscar con qué criterios se acepta o se rechaza una entrega. Build Digital describe esa revisión como una autorización de quien encarga el trabajo; el reparto en dos decisiones sucesivas, con las fuentes que lo respaldan, está en la guía del CDE, de Compartido a Publicado.
- La evidencia: Build Digital enumera las preguntas que el entorno común de datos tiene que poder responder: quién comprobó la información y cuándo, quién la aprobó y cuándo, qué estado tenía antes de compartirse, quién la autorizó y cuándo, y quién la aceptó y cuándo.
- Qué se puede automatizar: reunir el paquete del hito (modelo, planos, registro de revisión, resultados), comprobar que todo sale de la misma versión, pedir la firma y registrarla. La autorización y la aceptación, no.
Quién decide cada paso y qué evidencia conviene exigir está en la guía del estado Compartido al Publicado en el CDE.
Publicar y archivar: lo que tiene que poder leerse dentro de un año
Publicar ejecuta la decisión del paso anterior. Según Build Digital, en el estado Publicado la información gráfica, los datos y los documentos autorizados se consideran entregables finales. Archivar guarda lo que se compartió y se publicó, también lo que después se sustituyó, para poder reconstruir qué estaba vigente cuando se tomó cada decisión.
- Estado 1Trabajo en cursoWork in progressLa información que un equipo de tareas está desarrollando
- Estado 2CompartidoSharedAprobada por su equipo para que la consulten las demás partes
- Estado 3PublicadoPublishedInformación autorizada para su uso como entregable
- Estado 4ArchivadoArchivedEl registro de lo que se compartió y se publicó
La prueba de que el flujo funcionó es sencilla: un tercero que abra el registro un año después debería poder responder, sin llamarte, qué se publicó, contra qué se revisó, con qué resultado y quién respondió de cada decisión.
Qué se puede automatizar en un flujo de trabajo BIM y qué no
La línea no separa lo fácil de lo difícil. Separa lo que tiene una regla escrita de lo que exige criterio, y lo que ejecuta de lo que decide.
| Tipo de tarea | Ejemplos | ¿Se automatiza? |
|---|---|---|
| Comprobar con una regla escrita | El nombre contra el patrón del BEP, un parámetro obligatorio, un dato contra un umbral citado | Sí, y con el mismo resultado cada vez |
| Detectar | Interferencias entre disciplinas, avisos del fichero, duplicados | Sí; decidir qué es un problema real, no |
| Avisar y registrar | Notificar a un responsable, guardar quién hizo qué y cuándo | Sí |
| Preparar | Reunir los entregables de un hito, comprobar que comparten versión | Sí |
| Interpretar | Qué norma aplica, una excepción, una solución alternativa | No: es criterio |
| Decidir | Compartir, autorizar, aceptar, firmar | No: es de una persona que responde de ello |
Tres condiciones para que una automatización ayude sin quitarle la decisión a nadie:
- Se detiene en cada puerta y espera a la persona que decide.
- Deja rastro de lo que ejecutó: sobre qué versión, con qué regla y con qué resultado.
- Declara lo que no pudo comprobar en vez de darlo por bueno.
Qué hace OrionBIM aquí y qué no
OrionBIM trabaja sobre todo en los pasos 4, 5 y 6 de este recorrido. A 1 de octubre de 2026:
- Verifica el modelo contra la normativa (paso 5). Lee el modelo desde Revit, en vivo, con su propio complemento, y lo contrasta regla por regla con las reglas de la normativa del país donde se construye. Cada comprobación devuelve uno de cuatro resultados, OK, Revisar, Fuera de rango o No auditable, con su cita literal cuando hay juicio, y ninguno lo decide una IA. A 1 de octubre de 2026, mientras la revisión humana de las reglas ya cargadas sigue en curso, OrionBIM muestra como «Revisar» todo resultado que el evaluador habría dado como OK o Fuera de rango. Un OK no dice que el proyecto esté en regla: eso lo valida quien firma el proyecto. Hoy solo tiene reglas de República Dominicana, y ninguna del nuevo Código de Construcción (CDCRD) está aprobada.
- Exige firma humana para publicar (paso 6). Para marcar una entrega como Publicada en el registro de OrionBIM (no publica en ACC ni en otra solución de CDE) hacen falta tres cosas a la vez: que exista el veredicto, que no sea «No auditable» y que lo firme una persona, con registro de quién y cuándo. Un «No auditable» se puede firmar para dejar constancia, pero no habilita ninguna publicación. Es la compuerta de OrionBIM: no sustituye la autorización y la aceptación que fije el proyecto.
- Detecta colisiones entre disciplinas (paso 4). El complemento de Revit incluye una herramienta de detección de colisiones entre disciplinas. Qué colisión es real y quién la resuelve sigue siendo decisión del coordinador.
- Permite dibujar flujos de trabajo automatizados. La portada enseña un ejemplo de flujo de cierre de entrega que se dibuja, no se programa: encadena una revisión del modelo, la comprobación de la nomenclatura contra el BEP y la detección de colisiones, se detiene en un paso de aprobación en el que decide una persona y solo después crea las incidencias en formato BCF y avisa del cierre. Si esa persona rechaza, el flujo se detiene y no se crea ninguna incidencia. Ese flujo no corrige el modelo ni da por bueno el proyecto.
Y lo que no hace:
- No sustituye las decisiones que la ISO 19650 asigna a cada parte: compartir, autorizar y aceptar siguen siendo de esas partes.
- No audita sin regla aprobada. Si no la hay para el país del proyecto, o si el modelo no trae el dato que la regla necesita, el resultado es «No auditable». Nunca se aplica la norma de otro país para rellenar el hueco.
- No convierte una automatización en una decisión. El flujo se para donde tiene que decidir una persona.
Si quieres ver el ejemplo del flujo de cierre de entrega y cómo se emite un dictamen con su cita, puedes verlo en la portada de OrionBIM.
Fuentes
- ISO 19650-2:2018 - Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling — Part 2: Delivery phase of the assetsOrganización Internacional de Normalización (ISO), consultada 2026-10-01
- ISO 19650-4:2022 - Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling — Part 4: Information exchangeOrganización Internacional de Normalización (ISO), consultada 2026-10-01
- The Information Delivery Cycles - Build DigitalBuild Digital, consultada 2026-10-01
- Information Delivery Planning - Build DigitalBuild Digital, consultada 2026-10-01
- Common Data Environment (CDE) Solution and WorkflowBuild Digital, consultada 2026-10-01