Comprenda PIM y AIM en BIM: requisitos de información ISO 19650, handover, Asset Register, identidad persistente, COBie, systems of record, trigger events y transición a operación.
¡Descúbrelo!
PIM y AIM son dos modelos de información con finalidades diferentes a lo largo del ciclo de vida de un activo. El Project Information Model (PIM) soporta la fase de entrega — diseño, coordinación, contratación, construcción, pruebas y entrega — mientras que el Asset Information Model (AIM) soporta la gestión y la operación del activo. La diferencia no está en utilizar otro software u otro formato de archivo, sino en cambiar la finalidad, los usuarios, las decisiones soportadas, los requisitos y la gobernanza de la información.
Esta distinción es importante porque un proyecto puede terminar la obra con miles de documentos, modelos y registros y, aun así, iniciar la operación sin información utilizable. Los proyectos generan un gran volumen de conocimiento, pero la operación solo necesita una parte de ese contenido y, al mismo tiempo, necesita información que frecuentemente surge después del diseño: fabricante efectivamente instalado, número de serie, garantía, fecha de entrada en operación, resultados de pruebas, configuración final, plan de mantenimiento, criticidad, documentos del proveedor y vínculos con sistemas operacionales.
El handover, por lo tanto, no debería tratarse como una transferencia de carpetas o una copia integral del PIM a un repositorio de operación. Es una transición controlada de información, en la que los datos se seleccionan, se reconcilian con la condición instalada, se validan frente a los requisitos del activo, se conectan a identificadores persistentes y se encaminan a los sistemas que pasarán a mantenerlos. Lo que no posee valor operacional puede permanecer como registro del proyecto; lo que posee valor debe llegar a la operación con calidad demostrable.
Este proceso conecta la serie ISO 19650, requisitos OIR/AIR/PIR/EIR, LOIN, CDE, COBie, commissioning, as-built, BIM 7D, Facility Management, CMMS/EAM, gestión de activos y Digital Twin. Cuanto antes el propietario u operador defina las decisiones que dependerán de la información, menor será el costo de reconstruir registros después de la entrega y mayor será la posibilidad de que el AIM comience su vida como una fuente confiable de contexto para el activo.
PIM y AIM son modelos de información, no archivos BIM
La primera distinción necesaria es entre information model y modelo geométrico. Un modelo de información puede combinar múltiples information containers: modelos disciplinares y federados, planos, documentos, bases estructuradas, registros, especificaciones, informes, listas de activos, evidencias de pruebas, fotografías, certificados y otros conjuntos de información relacionados con una finalidad.
Qué caracteriza al PIM
El PIM está orientado a la fase de entrega. Su contenido se produce y organiza para desarrollar, coordinar, verificar, contratar, construir y entregar el proyecto. Puede contener información que nunca tendrá utilidad operacional, pero que fue necesaria para una decisión de diseño o para demostrar conformidad durante la ejecución.
| Elemento del PIM | Uso típico durante la entrega | ¿Debe necesariamente pasar al AIM? |
| modelos disciplinares | autoría y desarrollo técnico | no íntegramente |
| modelo federado | coordinación y análisis de interfaces | solo si tiene un uso operacional definido |
| planos y especificaciones | contratación y ejecución | solo versiones relevantes para el activo entregado |
| informes de clash/BCF | coordinación y resolución de issues | normalmente como registro, no como dato operacional activo |
| cantidades y estudios | presupuesto y decisión de diseño | solo cuando exista uso posterior |
| submittals de proveedores | validación técnica | sí, cuando están vinculados a activos mantenidos |
| registros de cambios | trazabilidad | sí, cuando explican la configuración final |
| as-built | condición entregada | normalmente es una fuente crítica para el AIM |
El PIM cambia intensamente. Se crean y descartan alternativas, se revisan modelos, se sustituyen especificaciones y evolucionan las decisiones. Esta volatilidad es normal en la fase de entrega, pero no debe transferirse indiscriminadamente a la operación.
Qué caracteriza al AIM
El AIM está orientado a la gestión del activo. Su contenido debe responder preguntas operacionales: qué existe, dónde está, cuál es su función, cómo fue configurado, qué documentos se aplican, quién es responsable, cuándo debe mantenerse, qué cambios ocurrieron y qué riesgos o requisitos están asociados.
| Dimensión del AIM | Ejemplos de información |
| identidad | asset tag, código patrimonial, GUID, identificador corporativo |
| ubicación | site, edificio, planta, sala, coordenada o zona |
| clasificación | sistema, disciplina, clase del activo, criticidad |
| configuración | tipo, fabricante, modelo, capacidad, parámetros y setpoints |
| ciclo de vida | fabricación, instalación, commissioning, garantía, sustitución |
| documentación | manuales, certificados, planos, informes, fichas técnicas |
| mantenimiento | periodicidades, tareas, estrategia, recursos e historial |
| condición y desempeño | inspecciones, fallas, mediciones e indicadores |
| relaciones | sistema al que pertenece, upstream/downstream, espacios atendidos |
| gobernanza | owner del dato, system of record, status, versión y última validación |
ISO 19650-3 estructura la gestión de la información durante la fase operacional. Esto refuerza que el AIM no es un producto entregado una única vez: es una capacidad de información que debe seguir actualizándose a medida que el activo recibe mantenimiento, sustituciones, ampliaciones, cambios de uso y nuevos proyectos.
PIM y AIM pueden coexistir
La transición no es necesariamente un instante único. Durante la ejecución, el PIM puede seguir evolucionando mientras partes de la información de activos ya se preparan, validan o incorporan al entorno operacional. En ampliaciones de un activo existente, un AIM existente también puede proporcionar información de entrada para un nuevo PIM; al final de ese nuevo proyecto, la información validada vuelve para actualizar el AIM.
Esto crea un ciclo, no una flecha simple:
AIM existente → requisitos e información de partida → nuevo PIM → ejecución y commissioning → información validada → actualización del AIM.
El as-built no es el AIM
As-built describe la condición ejecutada en un determinado nivel de documentación. AIM es más amplio. Puede utilizar el as-built como fuente, pero también necesita información no geométrica, reglas de gobernanza, registros operacionales y conexión con sistemas que seguirán cambiando durante la vida del activo.
Confundir as-built con AIM crea un problema recurrente: se entrega un modelo actualizado geométricamente, pero siguen faltando números de serie, garantías, vínculos documentales, planes de mantenimiento e identificadores corporativos.
As-built no es AIM. La condición ejecutada es una fuente esencial, pero el modelo de información del activo debe agregar identidad, documentación, relaciones, gobernanza e información necesaria para la operación.
Los requisitos de información determinan qué pertenece al PIM y al AIM
PIM y AIM no deben montarse por acumulación. La lógica correcta comienza por las decisiones que deben ser soportadas y deriva de ellas los requisitos de información.
OIR conecta la información con los objetivos de la organización
Los Organizational Information Requirements (OIR) describen necesidades de información asociadas a los objetivos y funciones de la organización. Una empresa puede necesitar conocer riesgo de indisponibilidad, capacidad instalada, costo de ciclo de vida, consumo energético, estado de garantías, ocupación de espacios o exposición regulatoria. Estos objetivos ayudan a determinar qué información de los activos debe existir y ser confiable.
AIR define lo que la gestión del activo necesita saber
Los Asset Information Requirements (AIR) transforman necesidades organizacionales en requisitos relacionados con los activos. Son decisivos para el AIM porque especifican qué datos, documentos y relaciones serán necesarios en la operación.
Un AIR útil no pide “todos los datos disponibles”. Relaciona información con decisiones y procesos.
| Decisión operacional | Información necesaria | Posible sistema consumidor |
| programar mantenimiento preventivo | activo, clase, criticidad, tarea, periodicidad | CMMS/EAM |
| controlar garantía | fabricante, modelo, serie, inicio/fin, condiciones | CMMS/ERP/documental |
| localizar equipo | identificador, espacio, sistema y posición | AIM/CAFM/IWMS/BIM |
| evaluar sustitución | edad, fallas, mantenimiento, desempeño y costo | EAM/BI/gestión de activos |
| investigar falla | configuración, historial, documentos y relaciones | CMMS/AIM/CDE |
| planificar reforma | condición actual, espacio, interfaces y documentación | AIM/PIM/CDE |
| auditar conformidad | certificados, inspecciones, fechas y evidencias | GED/CDE/CMMS |
Este enfoque reduce dos pérdidas opuestas: exceso de información sin uso y ausencia del dato necesario en el momento de la operación.
El AIM debe derivarse de decisiones operacionales, no de todo lo que el proyecto puede producir. OIR y AIR ayudan a transformar una necesidad real en un requisito de información verificable.
PIR organiza las necesidades del proyecto
Los Project Information Requirements (PIR) establecen qué necesita saber la organización para tomar decisiones sobre un proyecto específico. Pueden generar información que pertenece solo a la fase de entrega — alternativas de solución, estudios temporales, análisis de constructibilidad — e información que debe sobrevivir al proyecto porque será utilizada en la operación.
EIR transforma la necesidad en una obligación de intercambio
Los Exchange Information Requirements (EIR) especifican la información que debe intercambiarse en appointments e hitos. Conectan los requisitos con los equipos responsables de la producción y deben declarar contenido, formato, momento, criterios de aceptación y responsabilidades.
Un requisito de handover que diga únicamente “entregar BIM as-built” es insuficiente. El equipo debe saber qué activos deben tener registro, qué propiedades son obligatorias, cómo se vincularán los documentos, qué identificadores deben preservarse, qué formato será aceptado y cómo verificará la operación el resultado.
LOIN evita modelado excesivo y datos insuficientes
El nivel de información necesaria debe definirse según la finalidad. Los activos críticos pueden exigir propiedades, documentación y relaciones mucho más completas que los componentes sin necesidad de mantenimiento individual. Aplicar el mismo nivel de información a todos los objetos aumenta el costo sin aumentar necesariamente el valor del AIM.
Una matriz de requisitos puede combinar clase de activo × hito × uso × información geométrica × información alfanumérica × documentación. Esta estructura permite planificar progresivamente qué deberá producirse y cuándo cada campo pasa a ser exigible.
La transición PIM → AIM debe tratarse como un proceso de ingeniería
El handover es el punto en el que la calidad de la información pasa a afectar directamente mantenimiento y operación. Por eso, la transición debe tener criterios de readiness, evidencias y aceptación, del mismo modo que otros entregables técnicos.
No todo el PIM debe sobrevivir
El contenido temporal puede tener valor histórico o contractual sin integrar el AIM operacional. Estudios rechazados, versiones intermedias, simulaciones sin uso futuro, objetos auxiliares y registros de coordinación resueltos pueden permanecer en el archivo del proyecto sin ocupar la capa activa de información del activo.
La decisión debería responder tres preguntas:
- ¿esta información soporta alguna decisión, obligación o proceso operacional?
- ¿debe permanecer accesible como registro, pero no como dato operacional activo?
- ¿existe otra fuente autoritativa más adecuada para mantenerla?
No todo el AIM nace en el diseño
Gran parte de los atributos más importantes para mantenimiento solo pueden conocerse después de la compra y la instalación. Un diseño puede especificar una “bomba centrífuga de 30 m³/h”, mientras que el AIM necesita saber qué unidad fue realmente comprada e instalada, su fabricante, modelo, serie, fecha de puesta en marcha, garantía, motor asociado, configuración final y documentación específica.
Esto significa que procurement, proveedores, ejecución y commissioning son productores de información del AIM. Si el contrato solo exige datos al cierre, la organización pierde la oportunidad de validar progresivamente la calidad y termina reconstruyendo registros en un momento de alta presión por la entrega.
El Asset Register debe definirse antes de la recopilación a escala
Antes de exigir decenas de propiedades, es necesario decidir qué es un activo controlado individualmente. No todo objeto BIM necesita recibir un asset tag o existir como ítem en el CMMS.
Los criterios comunes incluyen mantenimiento individual, criticidad, garantía, reposición, obligación legal, necesidad de inspección, valor relevante, riesgo operacional o necesidad de historial propio.
| Elemento | ¿Tratar como activo individual? | Justificación típica |
| UPS | sí | criticidad, mantenimiento, garantía e historial |
| cámara IP | frecuentemente sí | serie, mantenimiento, firmware y ubicación |
| luminaria común | depende de la estrategia | puede mantenerse por lote/área |
| válvula de aislamiento crítica | frecuentemente sí | aislamiento y mantenimiento |
| tornillo o conexión | normalmente no | ausencia de proceso operacional individual |
| detector de incendios | depende del sistema y de los requisitos | la inspección y la identificación pueden exigir control unitario |
Esta decisión precede a COBie, CMMS o cualquier formato de registro. De lo contrario, la organización digitaliza una taxonomía de activos que nunca fue definida.
La identidad persistente es la columna vertebral de la transición
Un mismo equipo puede aparecer en un modelo BIM, una hoja de procurement, un informe de commissioning, CMMS, ERP y BMS. Si cada sistema utiliza un identificador diferente sin un mapeo gobernado, la información se fragmenta.
La estrategia de identificación debe definir identificadores primarios, aliases y reglas de cambio. Un GUID de IFC o un identificador interno del software pueden ser útiles, pero no deben asumirse como la única clave corporativa. Lo importante es que la organización pueda reconciliar inequívocamente registros entre sistemas.
Sin identidad persistente, no existe continuidad informacional. BIM, procurement, commissioning, CMMS y ERP deben poder reconocer el mismo activo incluso cuando utilizan sistemas e identificadores técnicos diferentes.
Reconciliar diseño, procurement y condición instalada
La transición debe tratar divergencias entre lo especificado, comprado, instalado, probado y aceptado. La cadena puede representarse así:
| Estado | Pregunta de control |
| diseñado | ¿qué fue previsto técnicamente? |
| aprobado | ¿qué proveedor/producto fue aceptado? |
| comprado | ¿qué ítem fue efectivamente adquirido? |
| instalado | ¿qué unidad está físicamente en el lugar? |
| configurado | ¿qué parámetros y ajustes fueron aplicados? |
| probado | ¿qué resultados demuestran desempeño? |
| aceptado | ¿qué pendientes o salvedades permanecen? |
| operacional | ¿qué sistema pasa a mantener el registro? |
Un AIM confiable debe reflejar el estado aceptado, no solo el estado previsto en diseño.
Commissioning completa información que el modelo no produce por sí solo
Las pruebas funcionales e integradas pueden generar setpoints, curvas, resultados, evidencias, configuraciones, certificados, listas de pendientes y condiciones de aceptación. Cuando estos elementos son necesarios para mantenimiento u operación, deben asociarse con los activos y sistemas correspondientes.
Commissioning, por lo tanto, no es solo una etapa física anterior a la entrega; es una fuente de información operacional.
COBie puede estructurar parte de la transferencia
COBie puede organizar datos de facilities, espacios, tipos, componentes, sistemas, documentos, garantías y otra información de handover. Es útil cuando el contrato y los sistemas de destino adoptan esta estructura, pero no debe confundirse con el AIM completo.
El AIM es más amplio y puede realizarse mediante diferentes combinaciones de sistemas e information containers. COBie es un mecanismo estructurado de intercambio y puede ser una de las entradas utilizadas para construir o actualizar este entorno.
La operación debe realizar la aceptación de la información
La validación del AIM no puede limitarse a verificar si un archivo abre o si los campos están completos. Es necesario probar si la información sirve al proceso real.
Una batería de aceptación puede verificar ubicación de activos, códigos, relaciones, documentos, garantías, importación a CMMS, asociación de planes de mantenimiento, acceso por usuarios, consultas de sistemas, trazabilidad de cambios y capacidad de recuperar evidencias.
El indicador más importante es simple: ¿el equipo operacional puede trabajar con los datos sin reconstruirlos manualmente?
AIM es una arquitectura gobernada, no necesariamente un único sistema
En la práctica, la información del activo queda distribuida. ISO 19650-3 admite que el AIM sea realizado mediante una combinación de sistemas nuevos y existentes adecuadamente conectados y gobernados. Esto es más realista que imaginar un único software que contenga toda la verdad operacional.
Defina systems of record por dominio de información
El concepto de system of record ayuda a decidir qué plataforma es autoritativa para cada clase de dato.
| Dominio | Posible fuente autoritativa | Sistemas consumidores |
| registro técnico del activo | EAM/CMMS o master data de activos | BIM, BI, mobile, ERP |
| documentos controlados | CDE/GED | CMMS, BIM, portal técnico |
| geometría y ubicación espacial | AIM/BIM/GIS | mantenimiento, ingeniería, emergencia |
| órdenes e historial de mantenimiento | CMMS/EAM | BI, gestión de activos |
| costo y registro financiero | ERP | EAM, BI |
| telemetría | BMS/SCADA/historian/IoT | Digital Twin, BI, mantenimiento |
| ocupación y espacios | CAFM/IWMS | FM, BIM, BI |
| configuración de automatización | sistema de control + documentación | mantenimiento, ingeniería |
Ninguna arquitectura es universal. Lo importante es declarar quién mantiene cada dato y cómo lo consumen los demás sistemas.
El AIM no necesita residir en un único software. El requisito es gobernanza: cada dominio de información debe tener una fuente autoritativa, owner y una regla de integración con los demás sistemas.
AIM no es sinónimo de CDE
El CDE puede controlar documentos, modelos y estados de la información, pero muchos datos operacionales tienen sistemas especializados. Órdenes de trabajo, historiales de fallas, telemetría o movimientos patrimoniales pueden no pertenecer al CDE como fuente principal.
El CDE sigue siendo importante como mecanismo de gobernanza y acceso a information containers, pero la arquitectura debe reconocer que la operación es heterogénea.
AIM no es sinónimo de CMMS o EAM
CMMS/EAM ejecuta procesos de mantenimiento y gestión del activo: planes, órdenes, historial, recursos, costos, fallas, backlog e indicadores. Puede almacenar una parte significativa de los datos del AIM, pero normalmente no sustituye modelos, planos, documentos complejos, registros espaciales u otros sistemas especializados.
La mejor integración evita duplicar datos sin necesidad. En lugar de copiar manuales a varios sistemas, por ejemplo, el CMMS puede mantener un vínculo controlado al documento oficial en el repositorio corporativo.
AIM no es sinónimo de BIM 7D
“BIM 7D” es una denominación de mercado para usos vinculados con operación, mantenimiento y Facility Management. AIM es un concepto formal de gestión de la información dentro de la serie ISO 19650. Un proyecto puede utilizar BIM 7D como lenguaje comercial o funcional y, al mismo tiempo, estructurar el AIM con requisitos y gobernanza consistentes.
AIM no es Digital Twin
Un Digital Twin normalmente agrega sincronización con el estado real, telemetría, eventos, análisis o modelos de comportamiento para soportar casos de uso específicos. Un AIM puede existir sin Digital Twin y sigue siendo esencial porque proporciona identidad, contexto, documentación y relaciones necesarias para conectar datos en tiempo real con un activo conocido.
Un twin construido sin un registro confiable solo asocia mediciones con entidades mal gobernadas.
Facility Management y gestión de activos utilizan el AIM de formas diferentes
Facility Management puede utilizar información de espacios, servicios, ocupación, contratos y desempeño del entorno construido. La gestión de activos puede enfocarse en valor, riesgo, desempeño y ciclo de vida. Mantenimiento puede enfocarse en tareas, fallas y disponibilidad. El mismo AIM puede soportar estos procesos siempre que los requisitos hayan sido estructurados para ellos.
Calidad, cambio y gobernanza mantienen el AIM confiable después del handover
Un AIM puede estar correcto el día de la entrega y quedar obsoleto en pocos meses si la organización no posee un proceso de actualización. La fase operacional es dinámica: los equipos fallan, se sustituyen, cambian los parámetros, se reforman espacios y nuevos proyectos alteran la configuración del activo.
Los trigger events deben iniciar procesos de información
La gestión operacional debe definir eventos que exigen revisión o actualización de information containers. Algunos ejemplos son sustitución de equipos, modificación de un setpoint crítico, reforma, cambio de ocupación, mantenimiento que altera configuración, actualización regulatoria, incidente, expansión o nuevo proyecto.
| Trigger event | Posibles actualizaciones |
| sustitución de equipo | tag, serie, fabricante, modelo, garantía, documentos, modelo |
| reforma de ambiente | geometría, espacio, activos, documentación y clasificación |
| cambio de automatización | lógica, setpoints, narrativa, pantallas y documentación |
| mantenimiento relevante | condición, configuración, evidencia e historial |
| nuevo proyecto | creación de PIM y posterior reconciliación con el AIM existente |
| desactivación | status, ubicación, historial y documentación de retirada |
El evento debe tener un owner y un criterio de cierre. Sin esto, el activo físico cambia y la información digital permanece congelada.
El AIM debe mantenerse, no solo entregarse. Las sustituciones, reformas, cambios de configuración y nuevos proyectos deben activar una actualización controlada de la información para evitar divergencias entre el registro digital y el activo físico.
Engineering Change Management · ISO 55000 y Gestión de Activos
La gestión de cambios conecta ECM, as-built y AIM
Los cambios técnicos deben dejar trazabilidad: origen, análisis, aprobación, implementación, pruebas y actualización documental. Engineering Change Management es una disciplina importante en esta continuidad porque reduce el riesgo de que la configuración real diverja silenciosamente de los registros.
En entornos críticos, el cambio puede exigir actualización coordinada del modelo, diagramas, lista de activos, parámetros, procedimientos, CMMS y documentos de operación.
La calidad de la información necesita dimensiones explícitas
“Completo” no significa “correcto”. La calidad del AIM debe evaluar distintas dimensiones.
| Dimensión | Ejemplo de verificación |
| completitud | ¿todos los activos críticos poseen campos obligatorios? |
| validez | ¿los valores siguen el formato, unidad y dominio permitidos? |
| unicidad | ¿existen tags duplicadas? |
| integridad referencial | ¿los documentos y sistemas apuntan a registros válidos? |
| consistencia | ¿fabricante/modelo son iguales entre bases relacionadas? |
| exactitud | ¿el registro corresponde al equipo instalado? |
| actualidad | ¿se reflejó el último cambio del activo? |
| trazabilidad | ¿es posible identificar el origen y la aprobación del dato? |
| usabilidad | ¿el sistema de destino puede consumir la información? |
La automatización puede verificar parte de esta calidad, pero la inspección técnica y la reconciliación de campo siguen siendo necesarias para atributos que dependen de la realidad instalada.
Seguridad y acceso deben ser proporcionales al riesgo
Un AIM puede contener información sensible: topologías, sistemas críticos, accesos, ubicación de equipos, configuraciones o datos operacionales. La organización debe clasificar la información y definir privilegios, compartición y auditoría compatibles con el riesgo.
No todos los usuarios necesitan acceso a todos los information containers. Una gobernanza adecuada separa disponibilidad operacional de exposición innecesaria.
Las métricas ayudan a medir readiness y mantenimiento del AIM
Los indicadores pueden revelar si el modelo informacional continúa siendo confiable: porcentaje de activos con registro aceptado, tasa de documentos vinculados, divergencias entre CMMS y campo, backlog de actualización, tiempo para incorporar un cambio, tasa de tags duplicadas, fallas de integración y porcentaje de órdenes abiertas contra activos sin documentación válida.
La métrica no debe incentivar cantidad de datos. El objetivo es medir la capacidad de encontrar y utilizar información confiable en el proceso correcto.
Proceso recomendado para estructurar PIM, transición y AIM
- Definir objetivos organizacionales y casos de uso operacionales. Identificar decisiones que dependerán de la información del activo.
- Estructurar OIR y AIR. Traducir objetivos en requisitos de información operacional.
- Definir PIR y EIR de cada proyecto. Especificar información necesaria durante la entrega y en los intercambios.
- Definir el Asset Register. Establecer clases y criterios para activos controlados individualmente.
- Definir identificadores y taxonomías. Crear claves persistentes entre BIM, procurement y operación.
- Mapear systems of record. Determinar qué plataforma será autoritativa para cada dominio de datos.
- Planificar PIM y entregas de información. Integrar BEP, TIDP, MIDP, CDE y criterios de calidad.
- Definir LOIN y atributos por hito. Evitar exigir información antes de que exista o detalle sin uso.
- Capturar información progresivamente. Incorporar datos de diseño, proveedores, compras y ejecución a medida que maduran.
- Controlar cambios y sustituciones. Mantener la relación entre diseñado, aprobado, comprado e instalado.
- Incorporar commissioning. Asociar pruebas, configuraciones, certificados y evidencias con los activos correctos.
- Reconciliar con la condición as-built. Verificar identificación, ubicación, relaciones y documentación frente al activo entregado.
- Validar calidad e integridad. Ejecutar checks automatizados y revisión técnica/operacional.
- Probar los sistemas de destino. Importar datos, reconciliar conteos, vínculos y excepciones antes de la aceptación.
- Formalizar handover y transferencia de gobernanza. Registrar baseline aceptada, pendientes y responsabilidades operacionales.
- Mantener el AIM mediante trigger events y change control. Actualizar la información siempre que cambien el activo físico o sus requisitos.
El resultado esperado no es un “modelo BIM final” más pesado. Es continuidad informacional: el conocimiento producido durante diseño e implementación llega a la operación de la forma necesaria, en sistemas gobernados, con identidad persistente, calidad verificable y un proceso de actualización. El AIM solo genera valor cuando continúa representando el activo que la organización realmente posee y opera.
Referencias técnicas
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-1:2018 — Organization and digitization of information about buildings and civil engineering works, including BIM — Information management using BIM — Part 1: Concepts and principles. Geneva: ISO, 2018. Disponible en: ISO.
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-2:2018 — Information management using BIM — Part 2: Delivery phase of the assets. Geneva: ISO, 2018. Disponible en: ISO.
[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-3:2020 — Information management using BIM — Part 3: Operational phase of the assets. Geneva: ISO, 2020. Disponible en: ISO.
[4] UK BIM FRAMEWORK. Guidance and resources for information management using the ISO 19650 series. Disponible en: UK BIM Framework.
[5] NATIONAL INSTITUTE OF BUILDING SCIENCES. Construction to Operations Building Information Exchange — COBie V3. Disponible en: NIBS.
Preguntas frecuentes
PIM es Project Information Model, el modelo de información utilizado principalmente en la fase de entrega para desarrollar, coordinar, verificar, construir y entregar el proyecto.
AIM es Asset Information Model, el modelo de información que soporta la gestión y la operación del activo a lo largo de la fase operacional.
No. Son modelos de información y pueden reunir modelos geométricos, documentos, datos estructurados, registros y otros information containers.
No. La transición debe seleccionar información con valor operacional, preservar lo que debe permanecer como registro y evitar cargar contenido temporal sin uso.
No. Información como serie, garantía, instalación, pruebas, configuración y mantenimiento puede surgir durante procurement, ejecución, commissioning y operación.
No. As-built registra la condición ejecutada en un determinado nivel. El AIM es más amplio e incluye datos, documentos, relaciones, gobernanza e información operacional.
No. COBie es una estructura de intercambio que puede transportar parte de los datos necesarios para construir o actualizar un AIM.
No. CMMS ejecuta procesos de mantenimiento y puede ser el system of record de parte de la información del activo, pero el AIM puede involucrar varios sistemas y containers.
No exactamente. BIM 7D es una denominación de mercado para usos BIM en operación; AIM es un concepto de gestión de la información relacionado con el activo en la serie ISO 19650.
Definiendo systems of record, trigger events, responsabilidades, gestión de cambios, identificadores persistentes, integraciones y criterios de validación después de cambios en el activo.
Materiales técnicos complementarios
Requisitos y gestión de la información
- Gestión de la Información en BIM: ISO 19650
- Requisitos de Información BIM: OIR, AIR, PIR y EIR
- BEP BIM
- MIDP y TIDP en BIM
- LOIN en BIM
- CDE BIM
- IDS BIM
- Gestión BIM e Información de Ingeniería
Handover, operación y gestión de activos
- COBie en BIM
- BIM 7D
- Facility Management
- CMMS
- ISO 55000 y Gestión de Activos
- Gestión de Activos de Ingeniería
- Ingeniería de Mantenimiento
Arquitectura, interoperabilidad e integración
- Archivo IFC en BIM
- Open BIM
- bSDD en BIM
- Digital Twin
- Integración de Sistemas, APIs y Conectores
- Entorno Común de Datos y Gestión de la Información BIM
- Gobernanza Documental
