Protocolos BCF para una coordinación eficiente sin perder datos
La coordinación BIM exige mucho más que detectar interferencias entre disciplinas. Cada incidencia contiene una decisión, una ubicación concreta dentro del modelo, una persona responsable y un historial de cambios que debe conservarse hasta el cierre del proyecto. Cuando esa información se transmite mediante capturas de pantalla, correos aislados o comentarios sin contexto, el equipo pierde tiempo y aumenta el riesgo de ejecutar una corrección equivocada.
El formato BCF, sigla de BIM Collaboration Format, permite separar las incidencias del archivo nativo del modelo y compartirlas entre distintas plataformas. Su valor está en mantener una comunicación estructurada: quién identificó el problema, qué elementos están implicados, desde qué vista se observa y cuál es su estado. Aplicado mediante un protocolo claro, facilita una coordinación eficiente sin perder datos relevantes del proceso BIM.
Qué es BCF y qué información conserva
BCF es un estándar abierto orientado al intercambio de incidencias relacionadas con modelos BIM. No sustituye a un archivo RVT, IFC o a otro formato de autoría; funciona como una capa de comunicación vinculada a esos modelos. Un archivo BCF puede contener un tema o issue, una descripción, un identificador, el autor, la fecha, el estado, la prioridad y los participantes responsables.
Uno de sus componentes más útiles es la vista gráfica. Esta puede incluir la posición de la cámara, el recorte de la escena, la orientación y los identificadores de los objetos visibles. Gracias a estos datos, un coordinador puede abrir una incidencia y regresar a una representación muy cercana a la que utilizó quien detectó el conflicto, sin tener que buscar manualmente el punto dentro de un modelo complejo.
La información geométrica no se limita a una imagen estática. Una captura ayuda a interpretar el problema, pero los identificadores de los elementos permiten relacionar la incidencia con objetos concretos. Si la plataforma conserva correctamente esos identificadores, el receptor puede localizar una viga, una bandeja eléctrica, un conducto o un equipo sin depender de una descripción ambigua como “revisar zona norte”.
Por qué se pierden datos durante la coordinación
La pérdida de información suele producirse cuando el equipo convierte una incidencia técnica en un mensaje informal. Un correo puede incluir una imagen, pero no necesariamente guarda el estado del asunto, la versión del modelo utilizada, el responsable de la respuesta o la fecha límite. Al reenviar el mensaje, también se puede perder el contexto que explicaba la prioridad y el alcance de la corrección.
Otro problema aparece cuando cada aplicación utiliza nombres distintos para describir el mismo estado. “Pendiente”, “abierto”, “en revisión” y “por validar” pueden representar situaciones diferentes o exactamente la misma. Sin una taxonomía compartida, los informes de coordinación acumulan incidencias que parecen activas aunque ya hayan sido resueltas, mientras otras quedan cerradas antes de una comprobación real.
También existen riesgos técnicos. La actualización de un modelo puede modificar identificadores, eliminar elementos o cambiar la posición de una vista. Un archivo BCF correctamente creado no garantiza por sí solo que la referencia siga siendo válida en el futuro. Por esa razón, el protocolo debe combinar el estándar con reglas de versionado, nomenclatura, conservación de archivos y verificación de vínculos.
Elementos de un protocolo BCF fiable
Antes de intercambiar archivos, el proyecto debe definir qué plataforma actúa como fuente principal de incidencias y qué herramientas se utilizarán para crear, revisar y cerrar los temas. El protocolo también debe indicar la versión de BCF admitida, el método de entrega, la periodicidad de sincronización y el formato de los identificadores de modelos y elementos.
La descripción de cada incidencia debe ser breve, verificable y útil para quien la recibe. Conviene separar el problema observado de la acción solicitada. Por ejemplo, “el conducto invade el espacio de mantenimiento del cuadro eléctrico” identifica una condición; “desplazar el trazado y comprobar el acceso frontal” define la respuesta esperada. Esta separación evita que una solución provisional se interprete como una decisión final.
| Campo del protocolo | Función en la coordinación | Riesgo si se omite |
|---|---|---|
| Identificador único | Permite rastrear la incidencia durante todo su ciclo | Duplicación de temas y respuestas inconexas |
| Estado | Indica si está abierta, en revisión, resuelta o cerrada | Informes desactualizados |
| Prioridad | Ordena el trabajo según impacto y urgencia | Atención desproporcionada a problemas menores |
| Autor y responsable | Distingue quién reporta y quién debe actuar | Tareas sin propietario |
| Vista y selección de elementos | Sitúa el problema en el modelo | Pérdida de contexto espacial |
| Versión de modelos | Relaciona la incidencia con una entrega concreta | Correcciones sobre archivos equivocados |
| Comentarios e historial | Conserva decisiones y evidencias | Repetición de análisis ya realizados |
La nomenclatura debe ser consistente en todos los proyectos. Un identificador puede incorporar disciplina, zona, nivel y número secuencial, siempre que la estructura no sea excesivamente larga. Lo importante es que el código sea estable y no cambie cada vez que se modifica la descripción. Las propiedades variables, como prioridad o fase, deben gestionarse en campos separados.
Flujo de trabajo desde la detección hasta el cierre
La creación de una incidencia comienza con una revisión del modelo federado o de los modelos disciplinares. Al identificar un conflicto, el autor debe comprobar que no existe otro tema equivalente. Después captura la vista, selecciona los elementos implicados y registra una descripción que permita reproducir la observación. En esta fase, conviene adjuntar una imagen solo como apoyo visual, no como sustituto de los metadatos BCF.
El siguiente paso consiste en asignar el tema a una disciplina, una empresa o una persona concreta. “Arquitectura” puede ser una categoría válida para filtrar, pero no siempre define quién debe responder. Un responsable nominal o un equipo claramente delimitado reduce la posibilidad de que el asunto permanezca sin atención. La fecha de respuesta y la prioridad deben obedecer a criterios previamente pactados.
Durante la revisión, el receptor debe abrir la incidencia sobre la misma versión de los modelos a la que hace referencia. Si esa versión ya no está disponible, el coordinador debe conservarla o asociar el tema con una entrega equivalente. La respuesta debería indicar qué se ha modificado, en qué archivo, mediante qué versión y si la solución puede afectar a otras disciplinas.
El cierre requiere una comprobación independiente o una validación definida por el nivel de riesgo. Cambiar el estado a “resuelto” significa que alguien ha aplicado una corrección; “cerrado” debería significar que la corrección ha sido revisada y aceptada. Mantener esta diferencia genera un historial más fiable y facilita las auditorías de coordinación, las reuniones de seguimiento y la trazabilidad de las decisiones.
Integración con Revit, IFC y gestión del proyecto
En entornos Revit, BCF puede complementar las herramientas de revisión, los modelos vinculados y los controles de interferencias. El coordinador puede utilizar la vista BCF para localizar elementos y después revisar parámetros, restricciones, fases, familias y relaciones dentro del archivo nativo. La incidencia actúa como guía de navegación y registro de decisión, mientras que la modificación se realiza en el entorno de autoría correspondiente.
Cuando se trabaja con IFC, es esencial conocer cómo se han generado y conservado los identificadores globales de los objetos. El GUID de un elemento permite establecer una referencia entre aplicaciones, pero puede cambiar si el modelo se exporta de forma diferente o si un objeto se recrea en lugar de modificarse. Las exportaciones deben validarse con pequeñas muestras antes de adoptar el flujo en todo el proyecto.
La coordinación tampoco termina cuando se aprueba el diseño. Las incidencias que afectan a equipos, accesos, espacios técnicos o requisitos de mantenimiento pueden aportar valor durante la operación del edificio. Un sistema de gestión de activos bien conectado con la información del modelo ayuda a conservar decisiones que más tarde serán útiles para mantenimiento preventivo, inspecciones y futuras reformas.
Para evitar confusiones, cada intercambio debe incluir un registro de la entrega: fecha, modelos utilizados, versión del archivo BCF, número de incidencias abiertas y responsable de la publicación. Este control puede integrarse en un CDE, una plataforma de coordinación o un repositorio documental con permisos y revisiones. Lo importante es que exista una fuente reconocida y que las copias locales no se conviertan en la única evidencia del estado del proyecto.
Reglas operativas para equipos multidisciplinares
Un protocolo útil debe ser suficientemente preciso para evitar interpretaciones, pero también sencillo para que los técnicos lo apliquen durante una jornada de producción. Las reglas más efectivas suelen concentrarse en la calidad mínima de cada incidencia, la responsabilidad de respuesta y la conservación del historial.
Criterios que deben quedar definidos:
- Estados permitidos y significado exacto de cada uno.
- Plazos de respuesta según prioridad y disciplina.
- Campos obligatorios antes de publicar un tema.
- Convención para modelos, vistas, zonas y versiones.
La calidad del intercambio mejora cuando las reuniones utilizan la lista BCF como agenda y no como simple inventario. Cada tema debe revisarse según su estado, responsable y fecha prevista. Las decisiones adoptadas en la reunión se incorporan al historial de la incidencia, evitando que una resolución verbal quede separada de la evidencia digital.
Controles recomendables antes de cerrar una entrega:
- Verificar que cada tema tiene vista y elementos seleccionados.
- Comprobar que no existen incidencias duplicadas.
- Revisar enlaces, archivos adjuntos y permisos de acceso.
- Comparar los estados con el informe de coordinación.
La formación del equipo debe incluir casos reales: una interferencia entre estructura y MEP, una observación de accesibilidad, un cambio de requerimiento y una incidencia que afecta al mantenimiento. Practicar estos escenarios permite distinguir entre un comentario de diseño, una no conformidad, una solicitud de información y un conflicto geométrico. Cada tipo puede requerir responsables, prioridades y criterios de cierre distintos.
Métricas para comprobar la trazabilidad
La eficiencia de un flujo BCF no se mide únicamente por la cantidad de incidencias cerradas. También importa el tiempo medio de respuesta, el porcentaje de temas reabiertos, la proporción de incidencias duplicadas y la cantidad de asuntos sin responsable. Estas métricas revelan si el equipo está resolviendo problemas o simplemente cambiando estados para mantener actualizado un tablero.
Otra medida relevante es la estabilidad de las referencias. Si muchas incidencias pierden sus elementos asociados después de una exportación IFC o una actualización de Revit, existe un problema en el proceso de identificación o en la gestión de versiones. Registrar cuántos temas pueden localizarse correctamente en cada entrega ayuda a detectar fallos antes de que afecten a la documentación constructiva.
La trazabilidad también puede evaluarse revisando una muestra de incidencias cerradas. Para cada una debería ser posible reconstruir el recorrido completo: modelo en el que se detectó, vista utilizada, responsable asignado, respuesta recibida, modificación realizada y validación final. Cuando esa secuencia está disponible, las decisiones son auditables y el conocimiento del proyecto no depende de la memoria de una sola persona.
Un sistema BCF maduro conecta coordinación geométrica, información alfanumérica y control documental. Conserva el contexto de cada observación, mantiene la responsabilidad visible y permite relacionar las decisiones con las entregas del modelo. Así, el intercambio deja de ser una sucesión de mensajes dispersos y se convierte en un registro técnico que acompaña al proyecto desde la revisión inicial hasta la operación del activo.