{"id":81690,"date":"2026-09-19T14:42:07","date_gmt":"2026-09-19T17:42:07","guid":{"rendered":"https:\/\/a3aengenharia.com\/?post_type=articles&p=81690"},"modified":"2026-09-19T14:42:32","modified_gmt":"2026-09-19T17:42:32","slug":"cobie-bim-datos-activos-handover-integracion-facility-management","status":"publish","type":"articles","link":"https:\/\/a3aengenharia.com\/es-es\/contenido\/articulos-tecnicos\/cobie-bim-datos-activos-handover-integracion-facility-management\/","title":{"rendered":"COBie en BIM: Datos de Activos, Handover e Integraci\u00f3n con Facility Management"},"content":{"rendered":"\n

COBie \u2014 Construction to Operations Building information exchange<\/strong> \u2014 es una especificaci\u00f3n de intercambio de informaci\u00f3n creada para organizar y transferir datos necesarios para la operaci\u00f3n y mantenimiento de facilities y activos. Su valor no est\u00e1 en \u201cgenerar una hoja de c\u00e1lculo BIM\u201d, sino en reducir una de las p\u00e9rdidas m\u00e1s recurrentes del ciclo de vida: el proyecto termina f\u00edsicamente, pero el equipo de operaci\u00f3n recibe documentos dispersos, registros incompletos e informaci\u00f3n que debe reconstruirse manualmente.<\/p>\n\n\n\n

La versi\u00f3n actual del est\u00e1ndar es COBie V3<\/strong>, publicada en el contexto de NBIMS-US V4. Moderniza la estructura tradicional de COBie, mantiene el principio de organizar informaci\u00f3n no gr\u00e1fica asociada a espacios, productos, equipos y operaci\u00f3n y admite distintos formatos de intercambio. El est\u00e1ndar contin\u00faa orientado al handover, pero su aplicaci\u00f3n es m\u00e1s amplia: los datos pueden producirse y verificarse progresivamente desde el dise\u00f1o, pasar por procurement, fabricaci\u00f3n, instalaci\u00f3n y commissioning y llegar a la operaci\u00f3n en condiciones utilizables.<\/p>\n\n\n\n

COBie tambi\u00e9n debe posicionarse correctamente dentro de la arquitectura BIM. No sustituye IFC, PIM, AIM, BIM 7D, CMMS, CAFM\/IWMS ni Facility Management. COBie es una estructura de entrega de datos<\/strong>. El modelo BIM puede ser una de las fuentes; el AIM organiza la informaci\u00f3n operacional del activo; el CMMS ejecuta procesos de mantenimiento; FM gobierna servicios y desempe\u00f1o. El valor aparece cuando estas capas poseen identificadores, requisitos, responsabilidades y systems of record compatibles.<\/p>\n\n\n\n

La tesis de este art\u00edculo es que COBie debe tratarse como un proceso de ingenier\u00eda de la informaci\u00f3n y un requisito de handover<\/strong>, no como una actividad administrativa de cierre. La organizaci\u00f3n debe definir previamente qu\u00e9 activos importan, qu\u00e9 datos tienen uso operacional, qui\u00e9n produce cada informaci\u00f3n, en qu\u00e9 hito se verifica, c\u00f3mo se reconcilia la condici\u00f3n instalada y c\u00f3mo se aceptar\u00e1 el resultado en el sistema de destino. Sin esto, es posible entregar un archivo formalmente completo y operacionalmente in\u00fatil.<\/p>\n\n\n\n

Qu\u00e9 es COBie y por qu\u00e9 existe<\/h2>\n\n\n\n

COBie organiza datos que normalmente quedan fragmentados entre planos, modelos, memorias, fichas t\u00e9cnicas, submittals, informes de commissioning, garant\u00edas y manuales de operaci\u00f3n y mantenimiento. El principio es transformar estos registros en informaci\u00f3n estructurada, relacionable y reutilizable durante el handover.<\/p>\n\n\n\n

El problema que COBie intenta resolver<\/h3>\n\n\n\n

En el modelo tradicional de entrega, mucha informaci\u00f3n importante es conocida por agentes diferentes y en momentos distintos. El dise\u00f1ador define tipo y desempe\u00f1o; el fabricante informa modelo y documentaci\u00f3n; el proveedor confirma datos comerciales; la obra registra el equipo instalado; el commissioning produce pruebas y par\u00e1metros; la operaci\u00f3n finalmente debe registrar el activo y organizar su mantenimiento.<\/p>\n\n\n\n

Cuando no existe un flujo estructurado, estos datos llegan al final como archivos independientes. El equipo de operaci\u00f3n debe descubrir qu\u00e9 manual corresponde a cada equipo, verificar qu\u00e9 modelo fue realmente instalado, localizar n\u00fameros de serie, introducir registros en el CMMS y reconstruir v\u00ednculos entre espacios, sistemas y activos. El costo no est\u00e1 solo en la digitaci\u00f3n: los errores de identificaci\u00f3n afectan garant\u00eda, mantenimiento, repuestos, trazabilidad y decisiones de ciclo de vida.<\/p>\n\n\n\n

COBie act\u00faa precisamente en esta interfaz entre construction<\/strong> y operations<\/strong>. La intenci\u00f3n es capturar datos en la fuente y preservar sus relaciones hasta la transferencia.<\/p>\n\n\n\n

COBie es un entregable de datos, no un software<\/h3>\n\n\n\n

La distinci\u00f3n entre conceptos evita especificaciones confusas.<\/p>\n\n\n\n

Elemento<\/td>Funci\u00f3n predominante<\/td>Relaci\u00f3n con COBie<\/td><\/tr>
Modelo BIM<\/td>representar objetos, espacios, sistemas, propiedades y relaciones<\/td>puede producir o recibir parte de los datos COBie<\/td><\/tr>
IFC<\/td>esquema abierto para intercambio de informaci\u00f3n del entorno construido<\/td>COBie tiene una relaci\u00f3n hist\u00f3rica con una MVD de IFC y puede entregarse en formato IFC<\/td><\/tr>
COBie<\/td>estructurar datos de handover y activos mantenibles<\/td>mecanismo de intercambio y entrega<\/td><\/tr>
PIM<\/td>informaci\u00f3n producida y gestionada durante la fase de entrega del activo<\/td>fuente de parte de la informaci\u00f3n que podr\u00e1 sobrevivir al handover<\/td><\/tr>
AIM<\/td>informaci\u00f3n necesaria para gestionar la fase operacional<\/td>puede recibir informaci\u00f3n transferida mediante COBie, pero es m\u00e1s amplio<\/td><\/tr>
CMMS<\/td>\u00f3rdenes, planes, fallas, historial, recursos y mantenimiento<\/td>puede consumir datos COBie para carga o actualizaci\u00f3n de registros<\/td><\/tr>
CAFM\/IWMS<\/td>facilities, espacios, workplace, servicios y portafolio<\/td>puede consumir datos espaciales y de activos seg\u00fan la arquitectura adoptada<\/td><\/tr>
Facility Management<\/td>gobernar el entorno construido, servicios y soporte al negocio<\/td>define necesidades operacionales que justifican el dato<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Esta arquitectura muestra por qu\u00e9 la pregunta \u201c\u00bfvamos a usar COBie o BIM?\u201d es inadecuada. COBie es una parte posible del ecosistema de informaci\u00f3n, no una alternativa a BIM.<\/p>\n\n\n\n

No todo objeto del modelo debe convertirse en activo COBie<\/h3>\n\n\n\n

El objeto modelado y el activo gestionado no son autom\u00e1ticamente lo mismo. Una familia de luminarias puede necesitar existir en el modelo para coordinaci\u00f3n y cantidades, pero la operaci\u00f3n puede no tener inter\u00e9s en controlar individualmente cada unidad. En cambio, una UPS, un chiller, una bomba cr\u00edtica o un tablero pueden necesitar identificaci\u00f3n, n\u00famero de serie, garant\u00eda, documentaci\u00f3n, mantenimiento e historial individual.<\/p>\n\n\n\n

La decisi\u00f3n debe orientarse por uso operacional<\/strong>. Criticidad, garant\u00eda, mantenimiento programado, inspecci\u00f3n legal, costo, reposici\u00f3n, trazabilidad y consecuencia de falla ayudan a definir el nivel de informaci\u00f3n necesario.<\/p>\n\n\n\n

Situaci\u00f3n<\/td>Tendencia de tratamiento<\/td><\/tr>
activo cr\u00edtico con mantenimiento individual<\/td>registro detallado por componente<\/td><\/tr>
equipo con garant\u00eda relevante<\/td>fabricante, modelo, serie, fechas y documentos controlados<\/td><\/tr>
\u00edtem sustituible sin trazabilidad individual<\/td>los datos pueden permanecer a nivel de tipo\/clase<\/td><\/tr>
componente sin uso operacional<\/td>puede no integrar el alcance COBie<\/td><\/tr>
activo sujeto a inspecci\u00f3n u obligaci\u00f3n legal<\/td>identificaci\u00f3n, documentos y evidencias tienden a ser esenciales<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Una buena especificaci\u00f3n comienza, por lo tanto, por la pregunta \u201c\u00bfqu\u00e9 necesita hacer la operaci\u00f3n con este dato?\u201d<\/strong>, y no por la pregunta \u201c\u00bfqu\u00e9 par\u00e1metros existen en la familia BIM?\u201d.<\/p>\n\n

COBie debe comenzar por el uso operacional, no por el modelo.<\/strong> El hecho de que un par\u00e1metro exista en BIM no significa que deba exigirse en el handover.<\/p>

OIR, AIR, PIR y EIR<\/a> \u00b7 LOIN en BIM<\/a><\/p><\/div>\n\n\n\n\n

COBie no se limita a edificios nuevos<\/h3>\n\n\n\n

El est\u00e1ndar puede apoyar entregas al final de obras nuevas, reformas, cambios de propietario o de gestor y otros eventos de transferencia. La propia evoluci\u00f3n de COBie V3 ampli\u00f3 el lenguaje para acomodar mejor situaciones de infraestructura y relaciones entre elementos. Esto no significa que COBie sea la soluci\u00f3n universal para cualquier activo; significa que su l\u00f3gica de handover estructurado puede aplicarse fuera de una obra predial convencional cuando exista adherencia al caso de uso.<\/p>\n\n\n\n

Estructura de COBie V3: tablas, campos, relaciones y formatos<\/h2>\n\n\n\n

COBie V3 es m\u00e1s rico que la imagen popular de la \u201choja de c\u00e1lculo con Equipment y Space\u201d. Organiza informaci\u00f3n en grupos l\u00f3gicos que cubren facility, espacios, productos, activos, procesos operacionales y registros suplementarios.<\/p>\n\n\n\n

Familias de informaci\u00f3n de COBie V3<\/h3>\n\n\n\n

La estructura publicada por NIBS agrupa tablas en cinco familias principales:<\/p>\n\n\n\n

Familia<\/td>Tablas COBie V3<\/td>Finalidad predominante<\/td><\/tr>
Informaci\u00f3n general<\/td>Company, Facility<\/td>identificar proyecto\/facility y organizaciones relacionadas<\/td><\/tr>
Informaci\u00f3n espacial<\/td>Level, SpaceType, Space, Zone, Coordinate<\/td>estructurar ubicaci\u00f3n y contexto espacial<\/td><\/tr>
Informaci\u00f3n de productos y activos<\/td>Type, Component, System, Attribute<\/td>describir tipos, instancias, sistemas, propiedades y relaciones<\/td><\/tr>
Informaci\u00f3n operacional<\/td>Instruction, Job, Event, Package, Risk<\/td>registrar instrucciones, actividades, eventos, paquetes y riesgos aplicables<\/td><\/tr>
Informaci\u00f3n suplementaria<\/td>Resource, Document, PickList<\/td>vincular recursos, documentos y valores controlados<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Esta divisi\u00f3n es importante porque COBie no trata solo \u201cequipos\u201d. La operaci\u00f3n debe comprender d\u00f3nde est\u00e1 el activo, a qu\u00e9 sistema pertenece, qu\u00e9 documentos se aplican, qu\u00e9 actividades pueden existir y qu\u00e9 relaciones dan contexto al registro.<\/p>\n\n\n\n

Facility, Level, Space y Zone: contexto antes del equipo<\/h3>\n\n\n\n

La calidad del registro del activo depende de una estructura espacial coherente. Un componente sin ubicaci\u00f3n v\u00e1lida es dif\u00edcil de encontrar f\u00edsicamente, inspeccionar, asignar a un equipo o relacionar con un ambiente.<\/p>\n\n\n\n

Facility<\/code> establece la unidad principal de entrega. Level<\/code> organiza niveles o estratos relevantes. SpaceType<\/code> permite agrupar espacios de naturaleza similar, Space<\/code> identifica los ambientes y Zone<\/code> permite establecer agrupaciones funcionales que no necesitan coincidir con pisos o compartimentos f\u00edsicos.<\/p>\n\n\n\n

En COBie V3, la adopci\u00f3n de Level<\/code> en lugar de la l\u00f3gica hist\u00f3rica centrada solo en \u201cFloor\u201d ayuda a acomodar contextos que no son exclusivamente edificios convencionales.<\/p>\n\n\n\n

Type y Component: clase e instancia deben separarse<\/h3>\n\n\n\n

Una de las relaciones m\u00e1s importantes es distinguir Type<\/strong> de Component<\/strong>.<\/p>\n\n\n\n

Type<\/code> representa caracter\u00edsticas comunes a un conjunto de productos o equipos: fabricante, modelo, descripci\u00f3n, referencia, desempe\u00f1o y atributos compartidos. Component<\/code> representa una instancia instalada, con identidad propia y relaci\u00f3n con espacio, sistema u otros registros.<\/p>\n\n\n\n

Separar los dos niveles reduce duplicidad. No tiene sentido repetir la misma ficha t\u00e9cnica en cientos de componentes cuando la informaci\u00f3n es de tipo. En cambio, n\u00famero de serie, ubicaci\u00f3n final o tag patrimonial pueden ser datos espec\u00edficos de la instancia.<\/p>\n\n\n\n

Dato<\/td>Normalmente asociado a<\/td>Ejemplo<\/td><\/tr>
fabricante<\/td>Type<\/td>Schneider Electric<\/td><\/tr>
modelo<\/td>Type<\/td>modelo comercial del equipo<\/td><\/tr>
potencia nominal<\/td>Type\/Attribute, seg\u00fan la regla<\/td>30 kW<\/td><\/tr>
tag del activo<\/td>Component<\/td>CH-01<\/td><\/tr>
n\u00famero de serie<\/td>Component<\/td>serie individual<\/td><\/tr>
ubicaci\u00f3n instalada<\/td>Component\/Space<\/td>sala t\u00e9cnica espec\u00edfica<\/td><\/tr>
manual del producto<\/td>Type\/Document<\/td>manual com\u00fan a la l\u00ednea<\/td><\/tr>
informe de prueba del equipo instalado<\/td>Component\/Document<\/td>evidencia espec\u00edfica de esa unidad<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

La regla debe estar definida contractualmente; la tabla sirve para mostrar la l\u00f3gica de normalizaci\u00f3n de datos, no para imponer un \u00fanico modelado a cualquier proyecto.<\/p>\n\n\n\n

System y relaciones funcionales<\/h3>\n\n\n\n

Operaci\u00f3n y mantenimiento frecuentemente piensan en sistemas<\/strong>, no solo en componentes aislados. Un equipo puede depender de alimentaci\u00f3n, comunicaci\u00f3n, climatizaci\u00f3n, agua, control u otras interfaces. System<\/code> permite organizar componentes en contextos funcionales relevantes.<\/p>\n\n\n\n

COBie V3 tambi\u00e9n incorpor\u00f3 mejoras para representar relaciones entre registros, incluido el campo PartOf<\/code> en determinadas estructuras. Esto mejora la capacidad de expresar jerarqu\u00eda y composici\u00f3n sin depender solo de nombres informales.<\/p>\n\n\n\n

El modelado de estas relaciones debe ser proporcional al uso. Crear una estructura extremadamente detallada sin un proceso que la utilice aumenta el costo de mantenimiento de los datos. Sin embargo, ignorar dependencias cr\u00edticas reduce el valor operacional del handover.<\/p>\n\n\n\n

Document, Job, Event, Instruction y Risk ampl\u00edan el contexto operacional<\/h3>\n\n\n\n

Una de las diferencias entre una lista de activos y una entrega de informaci\u00f3n es la capacidad de conectar contexto de uso.<\/p>\n\n\n\n

Document<\/code> permite asociar documentaci\u00f3n; Job<\/code> puede representar actividades relevantes; Event<\/code> registra eventos; Instruction<\/code> proporciona instrucciones y tambi\u00e9n informaci\u00f3n general del submittal; Risk<\/code> permite estructurar informaci\u00f3n de riesgo dentro del alcance del est\u00e1ndar. Estos elementos no transforman COBie en un CMMS o sistema de gesti\u00f3n de riesgos. Proporcionan una estructura de intercambio para informaci\u00f3n que puede ser necesaria en procesos posteriores.<\/p>\n\n\n\n

El punto de ingenier\u00eda es mantener la relaci\u00f3n trazable. Un manual entregado en una carpeta gen\u00e9rica tiene mucho menos valor que un documento vinculado al tipo o componente correcto. Una garant\u00eda sin activo, fecha y proveedor relacionados pierde utilidad operacional.<\/p>\n\n\n\n

Campos Required, If Specified y referencias<\/h3>\n\n\n\n

COBie diferencia la obligatoriedad de los campos. Existen requisitos m\u00ednimos del est\u00e1ndar y campos que se vuelven obligatorios cuando son especificados por el contratante. Tambi\u00e9n existen relaciones de referencia entre tablas.<\/p>\n\n\n\n

Esto crea una consecuencia contractual importante: el owner debe definir lo que desea adem\u00e1s del m\u00ednimo<\/strong>, especialmente cuando pretende alimentar procesos espec\u00edficos.<\/p>\n\n\n\n

Situaci\u00f3n<\/td>Consecuencia de especificaci\u00f3n<\/td><\/tr>
campo siempre requerido por el est\u00e1ndar<\/td>debe cumplir las reglas del COBie aplicable<\/td><\/tr>
campo exigido cuando se especifica<\/td>solo debe exigirse si el requisito est\u00e1 claramente definido<\/td><\/tr>
referencia entre tablas<\/td>depende de integridad referencial y claves coherentes<\/td><\/tr>
dato adicional del propietario<\/td>debe tener definici\u00f3n, origen, formato, responsable y criterio de calidad<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Exigir \u201cCOBie completo\u201d sin identificar versi\u00f3n, campos, activos y uso crea margen para interpretaciones incompatibles.<\/p>\n\n\n\n

COBie V3 no es solo XLSX<\/h3>\n\n\n\n

La hoja de c\u00e1lculo es la representaci\u00f3n m\u00e1s conocida, pero COBie V3 admite m\u00faltiples formatos aprobados, incluidos SpreadsheetML, JSON y representaciones basadas en IFC<\/strong>, adem\u00e1s de formatos de intercambio relacionados con la especificaci\u00f3n.<\/p>\n\n\n\n

Esta evoluci\u00f3n es importante para automatizaci\u00f3n. JSON facilita workflows machine-to-machine; IFC puede mantener COBie dentro de un ecosistema openBIM; SpreadsheetML sigue siendo \u00fatil para revisi\u00f3n humana, filtros y workflows en herramientas tabulares.<\/p>\n\n\n\n

La elecci\u00f3n del formato debe considerar qui\u00e9n produce, qui\u00e9n valida y qui\u00e9n consume<\/strong>. Un formato t\u00e9cnicamente elegante que no puede importarse en el sistema de destino crea una etapa adicional de conversi\u00f3n y riesgo.<\/p>\n\n

COBie V3 no es sin\u00f3nimo de Excel.<\/strong> SpreadsheetML sigue siendo \u00fatil para revisi\u00f3n humana, pero JSON e IFC ampl\u00edan las posibilidades de automatizaci\u00f3n e integraci\u00f3n.<\/p>

Archivo IFC en BIM<\/a> \u00b7 Open BIM<\/a><\/p><\/div>\n\n\n\n\n

COBie en la arquitectura de informaci\u00f3n: AIR, PIM, AIM, IFC, BIM 7D y CMMS<\/h2>\n\n\n\n

Una entrega COBie robusta nace de la arquitectura de informaci\u00f3n del proyecto. El archivo final es solo una manifestaci\u00f3n del proceso.<\/p>\n\n\n\n

AIR debe justificar el contenido operacional<\/h3>\n\n\n\n

En la l\u00f3gica de ISO 19650, los requisitos de informaci\u00f3n deben estar vinculados a decisiones y objetivos. Para la fase operacional, el Asset Information Requirements (AIR)<\/strong> es especialmente relevante porque define la informaci\u00f3n necesaria para apoyar la gesti\u00f3n de activos.<\/p>\n\n\n\n

El AIR no necesita ser \u201cuna lista COBie\u201d. Debe expresar necesidades de la organizaci\u00f3n. Despu\u00e9s, estas necesidades pueden mapearse a campos COBie, propiedades IFC, documentos u otras estructuras.<\/p>\n\n\n\n

Un requisito como \u201cgestionar la garant\u00eda de los equipos cr\u00edticos\u201d puede demandar identificaci\u00f3n del activo, tipo, fabricante, modelo, n\u00famero de serie, fecha de instalaci\u00f3n, per\u00edodo de garant\u00eda, proveedor y documento asociado. COBie es un posible mecanismo para transferir este conjunto de datos.<\/p>\n\n\n\n

PIM es fuente; AIM es el destino operacional m\u00e1s amplio<\/h3>\n\n\n\n

Durante la fase de entrega, la informaci\u00f3n se produce y gestiona en el Project Information Model (PIM)<\/strong>Durante el handover, parte de este contenido tendr\u00e1 valor para la operaci\u00f3n y deber\u00e1 contribuir al Asset Information Model (AIM)<\/strong>.<\/p>\n\n\n\n

La transici\u00f3n no consiste en copiar todo el PIM. Estudios temporales, alternativas rechazadas, objetos sin relevancia operacional e informaci\u00f3n duplicada pueden no tener valor en el AIM. La informaci\u00f3n que sobrevive debe seleccionarse, reconciliarse con la condici\u00f3n instalada y validarse frente a los requisitos del activo.<\/p>\n\n\n\n

COBie puede funcionar como uno de los puentes entre estos entornos, especialmente para datos estructurados de activos, espacios y documentaci\u00f3n.<\/p>\n\n\n\n

IFC y COBie trabajan en niveles diferentes<\/h3>\n\n\n\n

IFC es un esquema amplio para la representaci\u00f3n digital del entorno construido. COBie es una vista de informaci\u00f3n orientada al handover y la operaci\u00f3n. La relaci\u00f3n hist\u00f3rica entre COBie e IFC sigue siendo importante: COBie fue definido como una Model View Definition de IFC y COBie V3 mantiene representaciones alineadas con ese ecosistema.<\/p>\n\n\n\n

En la pr\u00e1ctica, un workflow puede producir COBie a partir de modelos IFC, exportar ambos como entregables o utilizar sistemas intermedios. Lo importante es evitar la suposici\u00f3n de que \u201ctener IFC\u201d significa autom\u00e1ticamente \u201ctener COBie correcto\u201d. El modelo puede tener geometr\u00eda perfecta y aun as\u00ed no contener n\u00famero de serie, garant\u00eda o documentaci\u00f3n final; a la inversa, un dataset COBie puede tener datos tabulares adecuados sin representar toda la riqueza geom\u00e9trica y relacional del modelo.<\/p>\n\n\n\n

BIM 7D es uso; COBie es intercambio<\/h3>\n\n\n\n

BIM 7D es una convenci\u00f3n de mercado asociada a usos de BIM en operaci\u00f3n y mantenimiento. COBie puede apoyar estos usos, pero no es sin\u00f3nimo de BIM 7D.<\/p>\n\n\n\n

BIM 7D puede incluir navegaci\u00f3n espacial, activos, documentos, condici\u00f3n, integraci\u00f3n con mantenimiento, sensores y otros casos de uso. COBie tiene un alcance mucho m\u00e1s espec\u00edfico: estructurar informaci\u00f3n que pueda transferirse y consumirse.<\/p>\n\n\n\n

CMMS necesita una identidad com\u00fan<\/h3>\n\n\n\n

El CMMS proporciona procesos que COBie no proporciona: \u00f3rdenes de trabajo, planes, programaci\u00f3n, recursos, piezas, fallas, historial e indicadores de mantenimiento. Para importar datos COBie, el sistema de destino debe mapear clases, jerarqu\u00edas, tags, campos y relaciones.<\/p>\n\n\n\n

BIM\/AIM puede proporcionar ubicaci\u00f3n, clasificaci\u00f3n y documentaci\u00f3n; CMMS registra historial operacional. La integraci\u00f3n solo se sostiene cuando existe una identidad com\u00fan del activo<\/strong>.<\/p>\n\n\n\n

Informaci\u00f3n<\/td>Posible system of record<\/td>Integraciones t\u00edpicas<\/td><\/tr>
geometr\u00eda y contexto espacial<\/td>BIM\/AIM<\/td>CMMS, CAFM\/IWMS, Digital Twin<\/td><\/tr>
registro operacional del activo<\/td>CMMS\/EAM o AIM, seg\u00fan la arquitectura<\/td>BIM, ERP, BMS<\/td><\/tr>
\u00f3rdenes e historial de mantenimiento<\/td>CMMS<\/td>AIM, analytics, ERP<\/td><\/tr>
alarmas y estado en tiempo real<\/td>BMS\/SCADA\/IoT<\/td>CMMS, Digital Twin, analytics<\/td><\/tr>
documentos controlados<\/td>GED\/CDE\/AIM<\/td>CMMS, BIM, operaci\u00f3n<\/td><\/tr>
compras e informaci\u00f3n financiera<\/td>ERP<\/td>EAM\/CMMS, gesti\u00f3n de activos<\/td><\/tr>
dataset de handover<\/td>COBie<\/td>importaci\u00f3n\/actualizaci\u00f3n de los sistemas anteriores<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

No existe obligaci\u00f3n de adoptar exactamente esta distribuci\u00f3n. La organizaci\u00f3n debe definir sus systems of record<\/strong> y evitar que cinco plataformas mantengan versiones competidoras del mismo dato sin una regla de sincronizaci\u00f3n.<\/p>\n\n\n\n

El handover comienza en el proyecto, no en el cierre<\/h3>\n\n\n\n

Fabricante, modelo, n\u00famero de serie, garant\u00eda, documentaci\u00f3n, par\u00e1metros, pruebas, repuestos y relaciones no surgen todos al mismo tiempo. El dise\u00f1o define una parte; procurement confirma otra; la instalaci\u00f3n crea identidad individual; commissioning produce evidencias y par\u00e1metros finales.<\/p>\n\n\n\n

Por eso, exigir que todo est\u00e9 completo en el \u00faltimo mes de la obra es estructuralmente inadecuado. La informaci\u00f3n debe recopilarse cuando existe una fuente confiable y verificarse antes de que el agente responsable deje el proyecto.<\/p>\n\n

El handover es consecuencia de un proceso de informaci\u00f3n bien gobernado.<\/strong> Intentar reconstruir fabricante, modelo, serie, garant\u00eda y documentos al cierre transfiere costo y riesgo a la operaci\u00f3n.<\/p>

PIM y AIM en BIM<\/a> \u00b7 Facility Management<\/a><\/p><\/div>\n\n\n\n\n

C\u00f3mo especificar y contratar una entrega COBie<\/h2>\n\n\n\n

El requisito \u201centregar COBie\u201d es insuficiente. Una especificaci\u00f3n contractual debe definir versi\u00f3n, alcance, activos, campos, fuentes, responsabilidades, hitos, formato, calidad y aceptaci\u00f3n<\/strong>.<\/p>\n\n\n\n

Comience por el uso final<\/h3>\n\n\n\n

El proceso recomendado por el propio COBie es definir qu\u00e9 se desea, cu\u00e1ndo ser\u00e1 entregado y qui\u00e9n lo producir\u00e1 y revisar\u00e1. Esto converge con una buena pr\u00e1ctica de gesti\u00f3n de la informaci\u00f3n: comenzar por el uso final.<\/p>\n\n\n\n

Una matriz de requisitos puede relacionar la necesidad operacional con el dato solicitado.<\/p>\n\n\n\n

Caso de uso operacional<\/td>Activos cubiertos<\/td>Datos necesarios<\/td>Evidencia\/consumo<\/td><\/tr>
gesti\u00f3n de garant\u00edas<\/td>equipos con garant\u00eda controlada<\/td>fabricante, modelo, serie, fechas, proveedor, documento<\/td>CMMS\/EAM + garant\u00eda<\/td><\/tr>
mantenimiento preventivo<\/td>activos planificados individualmente<\/td>tag, tipo, ubicaci\u00f3n, par\u00e1metros, documentos, actividades<\/td>CMMS<\/td><\/tr>
inspecci\u00f3n regulatoria<\/td>sistemas sujetos a obligaci\u00f3n espec\u00edfica<\/td>identificaci\u00f3n, certificado, fechas y documento vigente<\/td>CMMS\/GED<\/td><\/tr>
gesti\u00f3n de repuestos<\/td>equipos cr\u00edticos<\/td>fabricante, modelo, especificaci\u00f3n y recursos asociados<\/td>CMMS\/ERP<\/td><\/tr>
ubicaci\u00f3n de equipos<\/td>activos distribuidos<\/td>facility, level, space, zone, coordinate cuando corresponda<\/td>CAFM\/BIM\/CMMS<\/td><\/tr>
an\u00e1lisis de riesgos<\/td>activos\/sistemas cr\u00edticos<\/td>criticidad, relaciones, riesgos y documentaci\u00f3n<\/td>gesti\u00f3n de activos<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Este mapeo evita recopilar datos \u201cporque el template tiene una columna\u201d.<\/p>\n\n\n\n

Defina el Asset Register antes de discutir campos<\/h3>\n\n\n\n

Una de las decisiones m\u00e1s cr\u00edticas es definir qu\u00e9 tipos y componentes ser\u00e1n controlados<\/strong>. El inventario debe gobernarse mediante reglas, no por la opini\u00f3n de cada disciplina.<\/p>\n\n\n\n

Los criterios pueden incluir criticidad, costo, obligaci\u00f3n legal, mantenimiento individual, garant\u00eda, vida \u00fatil, reposici\u00f3n, necesidad de identificaci\u00f3n f\u00edsica e impacto de falla. El resultado puede ser una matriz por clase de activo indicando si debe existir Type<\/code>, Component<\/code>, documentaci\u00f3n, serializaci\u00f3n, garant\u00eda y plan de mantenimiento.<\/p>\n\n\n\n

Especifique versi\u00f3n y formato<\/h3>\n\n\n\n

El contrato debe declarar qu\u00e9 versi\u00f3n de COBie es aplicable y en qu\u00e9 formato ser\u00e1 aceptada. Esto es especialmente importante porque todav\u00eda existen workflows y materiales basados en COBie 2.4, mientras COBie V3 introdujo cambios estructurales relevantes.<\/p>\n\n\n\n

Tambi\u00e9n es necesario definir convenciones: codificaci\u00f3n, idioma, unidades, fechas, valores nulos, caracteres, nombres, clasificaciones, anexos y referencias externas.<\/p>\n\n\n\n

Matriz de responsabilidad por informaci\u00f3n<\/h3>\n\n\n\n

Ning\u00fan agente conoce todos los datos. La responsabilidad debe acompa\u00f1ar el origen de la informaci\u00f3n.<\/p>\n\n\n\n

Informaci\u00f3n<\/td>Fuente probable<\/td>Responsable t\u00edpico de la producci\u00f3n<\/td>Verificaci\u00f3n t\u00edpica<\/td><\/tr>
espacios y zonas<\/td>dise\u00f1o\/arquitectura<\/td>dise\u00f1ador\/coordinador BIM<\/td>coordinaci\u00f3n + owner<\/td><\/tr>
tipo y desempe\u00f1o especificado<\/td>dise\u00f1o\/especificaci\u00f3n<\/td>dise\u00f1ador de la disciplina<\/td>ingenier\u00eda del owner<\/td><\/tr>
fabricante y modelo adquirido<\/td>procurement\/submittal<\/td>proveedor\/contratista<\/td>fiscalizaci\u00f3n\/ingenier\u00eda<\/td><\/tr>
n\u00famero de serie<\/td>instalaci\u00f3n<\/td>instalador\/proveedor<\/td>campo\/commissioning<\/td><\/tr>
ubicaci\u00f3n final<\/td>as-built<\/td>contratista\/modelado<\/td>fiscalizaci\u00f3n + BIM<\/td><\/tr>
garant\u00eda<\/td>contrato\/proveedor<\/td>procurement\/proveedor<\/td>gesti\u00f3n contractual<\/td><\/tr>
informe de prueba<\/td>commissioning<\/td>ejecutor\/agente de Cx<\/td>commissioning authority\/owner<\/td><\/tr>
plan operacional<\/td>operaci\u00f3n\/mantenimiento<\/td>FM\/mantenimiento<\/td>owner<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Los t\u00edtulos reales var\u00edan seg\u00fan el contrato. Lo esencial es que exista alguien claramente responsable de crear, actualizar, verificar y aceptar.<\/p>\n\n\n\n

Los data drops transforman COBie en un proceso<\/h3>\n\n\n\n

Las entregas intermedias son muy recomendables en proyectos mayores porque permiten verificar estructura y calidad progresivamente. No necesitan contener todos los datos finales.<\/p>\n\n\n\n

Hito<\/td>Contenido que puede madurar<\/td><\/tr>
concepto \/ dise\u00f1o inicial<\/td>Facility, niveles, espacios, zonas, clases y estrategia de activos<\/td><\/tr>
desarrollo de dise\u00f1o<\/td>tipos, sistemas, atributos y requisitos de informaci\u00f3n<\/td><\/tr>
documentaci\u00f3n para contrataci\u00f3n<\/td>alcance COBie consolidado, clases, responsabilidades y criterios<\/td><\/tr>
procurement<\/td>fabricante, modelo, submittals, documentaci\u00f3n y garant\u00eda prevista<\/td><\/tr>
instalaci\u00f3n<\/td>componentes, tags, series, ubicaci\u00f3n final y relaciones instaladas<\/td><\/tr>
commissioning<\/td>resultados, documentos, configuraciones, pendientes y evidencias<\/td><\/tr>
handover<\/td>dataset reconciliado, validado y aceptado<\/td><\/tr>
operaci\u00f3n<\/td>actualizaci\u00f3n del AIM\/sistemas seg\u00fan cambios y nuevos eventos<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

El objetivo no es burocratizar el proyecto con entregas duplicadas. Es detectar problemas mientras todav\u00eda existe capacidad de corregirlos en origen.<\/p>\n\n

Los data drops son control de calidad, no burocracia adicional.<\/strong> Distribuyen la producci\u00f3n de informaci\u00f3n a lo largo del proyecto y permiten corregir errores antes del handover.<\/p>

BEP BIM<\/a> \u00b7 MIDP y TIDP<\/a><\/p><\/div>\n\n\n\n\n

BEP, TIDP y MIDP deben reflejar la entrega de datos<\/h3>\n\n\n\n

Si COBie es contractual, el Plan de Ejecuci\u00f3n BIM debe explicar c\u00f3mo se ejecutar\u00e1 el proceso. Los planes de entrega deben indicar cu\u00e1ndo se producen los conjuntos de informaci\u00f3n, por qui\u00e9n y c\u00f3mo se integran al plan maestro.<\/p>\n\n\n\n

Esto incluye herramientas, exportadores, validaciones, entornos, responsabilidades, criterios de nomenclatura, coordinaci\u00f3n entre modelos y datos, control de versiones y tratamiento de no conformidades.<\/p>\n\n\n\n

Los criterios de aceptaci\u00f3n deben estar definidos antes de la primera entrega<\/h3>\n\n\n\n

No es posible evaluar objetivamente un dataset si el proyecto descubre los criterios de calidad al cierre. El contratante debe establecer previamente:<\/p>\n\n\n\n