Understand CMMS: asset registers, work orders, preventive and condition-based maintenance, EAM, BIM 7D, Digital Twin, integrations, implementation and acceptance.
Check it out!
Um CMMS — Computerized Maintenance Management System, ou sistema informatizado de gestão da maintenance, é uma plataforma usada para estruturar, programar, registrar e controlar atividades de maintenance sobre assets físicos. Seu núcleo é a associação entre asset register técnico, maintenance plans, work orders de serviço, recursos, materials, history de intervenções e indicadores de desempenho.
In practice, a CMMS transforms maintenance from a set of scattered tasks into a traceable process. Instead of depending on spreadsheets, individual schedules, or isolated records, the organization can know which asset requires intervention, why, at what frequency, who performed the work, which parts were used, how long the equipment was unavailable, and what the result of the activity was.
CMMS, porém, não é sinônimo de gestão de assets, EAM, BIM 7D ou Digital Twin. A gestão de assets é uma disciplina mais ampla, orientada ao value, performance, risk, and lifecycle; o EAM amplia a gestão para funções empresariais e todo o ciclo de vida; o BIM/AIM pode fornecer estrutura e informação técnica do asset; e um Digital Twin pode acrescentar sincronização, contexto operacional, modelos e análises. O CMMS ocupa principalmente o workflow operacional da maintenance.
For this reason, CMMS implementation should not begin with software selection. The starting point is to define assets, criticality, maintenance strategies, minimum data, processes, responsibilities, integrations, and quality criteria. Digitizing an inconsistent process only makes the inconsistency faster and harder to correct.
What is a CMMS and which processes does it actually control?
A CMMS centralizes information and workflows associated with maintenance. IBM and SAP converge on this definition by treating the system as a platform for organizing asset data, work orders, preventive maintenance, inspections, resources, parts, and history, with a focus on availability, reliability, and operational efficiency.
A função central do CMMS não é simplesmente “abrir chamados”. O sistema precisa conectar o objeto mantido ao trabalho executado e transformar cada intervenção em history utilizável para planejamento, análise e decisão.
| Object | Typical CMMS information | Operational use |
| asset | tag, manufacturer, model, serial number, location, criticality | identify and prioritize the equipment |
| plan | frequency, trigger, procedure, resources | schedule preventive maintenance |
| work order | cause, activity, responsible party, dates, status | control execution and traceability |
| labor | role, competence, hours | plan capacity and record effort |
| material | part, inventory, quantity, application | support maintenance and replenishment |
| failure | mode, cause, consequence | feed reliability analysis |
| measurement | hours, cycles, condition, reading | trigger maintenance by usage or condition |
| document | manual, procedure, drawing, checklist | provide information at the point of work |
| history | interventions, failures, costs, downtime | analyze performance and recurrence |
The work order is the transactional backbone of a CMMS
The work order records the work that needs to be performed and what actually occurred. It should link the asset, problem, priority, responsible party, procedure, material, time, evidence, cause, and result. Without this connection, the CMMS becomes only a digital calendar.
A CMMS is not a ticketing system. Value appears when each work order connects asset, cause, planning, execution, evidence, and result into usable technical history.
Uma ordem madura diferencia pelo menos solicitação, triagem, planejamento, programação, execução, teste/retorno ao serviço, encerramento técnico e encerramento administrasset. A quantidade de estados pode variar, mas o processo precisa deixar claro quem decide, quem executa e qual evidência encerra o trabalho.
The asset register needs to be more than an equipment list
The register should reflect a coherent hierarchy: site, system, subsystem, equipment, and component where necessary. Identity, location, function, and technical relationships need to remain stable because they connect history, documents, failures, spares, and indicators.
ISO 14224:2016, although sector-specific to petroleum, petrochemical, and natural gas industries, is a useful reference on the importance of standardizing equipment, failure, and maintenance data. Its value here lies in the principle: without consistent taxonomy, the maintenance database loses comparability and analytical quality.
CMMS, EAM, asset management, ERP, BIM, and Digital Twin: differences
These concepts partially overlap, but they are not equivalent. The right architecture prevents the CMMS from becoming a repository for everything or duplicating functions already performed by other systems.
| System / discipline | Primary scope | Relationship with the CMMS |
| CMMS | operational maintenance | central system for maintenance work orders, plans, history, and resources |
| EAM | enterprise asset lifecycle | may incorporate CMMS and extend into capital, procurement, risk, and finance |
| Asset management | value, performance, risk, and lifecycle | defines objectives and decisions that the CMMS helps execute and measure |
| ERP | enterprise processes | integrates procurement, inventory, costs, contracts, people, and finance |
| BIM / AIM | structured asset information | can provide identity, location, properties, and documentation |
| BMS / SCADA / DCIM / EPMS | system supervision and operation | provide events, alarms, states, and measurements |
| IoT / historian | data acquisition and history | provides condition, usage, and time series |
| Digital Twin | synchronized decision-oriented representation | can generate diagnostics, forecasts, or recommendations that become CMMS workflows |
CMMS and EAM should not automatically be used as synonyms
The CMMS has historically been centered on maintenance execution. EAM has a broader scope and can follow assets from planning, acquisition, and installation through operations, maintenance, and decommissioning, integrating financial, risk, and portfolio decisions.
Na prática, plataformas modernas aproximam os dois conceitos e a fronteira comercial varia por fornecedor. Por isso, em especificações e RFPs é melhor contratar capacidades e processos do que depender apenas do rótulo CMMS ou EAM.
CMMS is also not asset management
ISO 55000:2024 and ISO 55001:2024 position asset management as a discipline aimed at realizing value from assets by balancing performance, risk, and expenditure in alignment with organizational objectives. A CMMS can be an important tool within this system, but it does not replace policy, objectives, governance, decision-making, and lifecycle management.
CMMS executes and records maintenance; asset management decides how assets should generate value throughout the lifecycle. Confusing a tool with a management system reduces operational maturity.
Data architecture: what a CMMS needs to know about each asset
Implementation depends more on the quality of the information model than on the number of screens. Before migrating data, the organization needs to decide which objects exist, how they relate, which fields are mandatory, who owns each information item, and how changes will be governed.
Hierarchy and identity
Each asset should have a unique identifier and a relationship with its functional location and system. Replacing the physical equipment should not destroy the history of the function; on the other hand, serial number, manufacturer, and installed-item data need to follow the replacement.
Essa distinção entre posição funcional e equipamento instalado é crítica em plantas, edifícios e Data Centers. Ela permite responder perguntas diferentes: “qual sistema atende esta área?” e “qual equipamento específico está instalado aqui agora?”.
Minimum data for maintenance
A useful register typically includes identification, class, location, manufacturer, model, serial number, status, installation date, criticality, key parameters, applicable parts, plans, documents, warranties, and relationships with upstream/downstream systems.
A common mistake is importing thousands of fields because they exist in BIM, ERP, or commissioning spreadsheets. The CMMS should receive only the information needed for the maintenance process, maintaining links or integrations to other systems where more appropriate.
Failure, cause, and action need to be codifiable
Free text is important for context, but reliability analysis depends on consistent classifications. Failure code, failure mode, cause, corrective action, consequence, and downtime make it possible to identify recurrence and compare asset families.
Without standardization, the same occurrence may be recorded as “failure,” “defect,” “will not start,” “breakdown,” or “electrical problem,” fragmenting the database and reducing the value of the history.
Documents and evidence need to reach the technician
Manuals, procedures, drawings, diagrams, checklists, photographs, certificates, and safety instructions need to be associated with the asset or task. The value of information lies not in merely existing in a repository, but in being available when the activity is planned and executed.
More data does not mean better maintenance. The CMMS needs to receive the information required for the work and preserve identity, context, and source of truth; excessive fields without governance increase noise and asset-register maintenance cost.
How CMMS supports corrective, preventive, and condition-based maintenance
The CMMS should support different strategies without confusing them. The strategy comes from maintenance engineering and criticality; the system executes, schedules, records, and measures.
Corrective maintenance
A failure or anomaly generates a request, triage, and work order. The workflow records priority, symptoms, diagnosis, intervention, materials, downtime, cause, and return to service. For critical assets, the work order needs to retain sufficient evidence for later analysis.
Preventive maintenance
Preventive plans can be triggered by calendar, operating hours, cycles, mileage, or another counter. The CMMS calculates due dates, generates work orders, and tracks plan compliance.
Frequency should not be treated as immutable. History, manufacturer recommendations, legal requirements, criticality, and performance may justify plan review. The system needs to preserve traceability of these changes.
Condition-based and predictive maintenance
When sensors, inspections, or specialist systems provide condition information, the CMMS can receive readings or events and open inspections/work orders according to limits and rules. In more advanced architectures, analytics or a Digital Twin can identify degradation and send a recommendation to the maintenance workflow.
Isso não significa que o CMMS deva executar análise de vibração, termografia, FDD ou machine learning internamente. Muitas vezes é melhor que sistemas especialistas produzam a evidência e o CMMS permaneça como sistema de registro e execução da ação.
Planning and scheduling are different
Planning means defining task scope, procedure, risks, resources, parts, tools, duration, and conditions. Scheduling means choosing when to execute, considering priority, asset availability, team, materials, and operating window.
A healthy backlog distinguishes identified work, planned work, and work actually scheduled. Mixing these states produces misleading indicators and pressures the team to execute work orders that are not yet ready.
Technical closeout feeds the next cycle
The closed work order should record what was found, what was done, which components were replaced, cause, time, material, and final condition. This feedback updates history, plans, inventory, indicators, and reliability analyses.
If the technician merely marks the work as “completed,” the organization loses precisely the information that justifies having a CMMS.
CMMS integration with BIM 7D, AIM, IoT, BMS, SCADA, and Digital Twin
The operational phase produces and consumes information across several systems. ISO 19650-3 establishes an information-management process for the operational phase of assets; this does not mean AIM or the CDE should replace the CMMS. The challenge is to define responsibilities and exchanges among systems.
BIM/AIM as technical asset context
BIM and AIM can provide location, classification, properties, documentation, and spatial/functional relationships. The CMMS provides maintenance history, work orders, plans, failures, and resources. Integration makes sense when there is a common identity capable of linking the asset across both environments.
O BIM 7D é uma convenção de mercado associada ao uso de informação na operations e maintenance. O CMMS pode ser uma das plataformas operacionais desse ecossistema, mas BIM 7D não é um software de maintenance.
BMS, SCADA, DCIM, and IoT as state sources
Automation and supervisory systems are responsible for control, alarms, telemetry, and operation. They can trigger events relevant to maintenance, but they should not necessarily replicate work orders, inventory, or labor planning.
Good integration turns a technical event into context: correct tag, criticality, priority, suppression rule, persistence, opening condition, and closure criterion. Sending every alarm directly to the CMMS creates an avalanche of work orders and reduces confidence in the system.
Digital Twin as a diagnostic and decision layer
A Digital Twin can combine operational state, history, models, and rules to detect deviations, estimate condition, or recommend intervention. The CMMS closes the loop by turning the recommendation into a work order, execution, evidence, and feedback.
This separation is important: the twin does not need to replace the maintenance system, and the CMMS does not need to reproduce all of the twin’s analytical capabilities.
A Digital Twin can diagnose or predict; the CMMS turns the decision into executable work and returns evidence to the cycle. Integration creates value when systems maintain clear roles.
ERP, inventory, and procurement
ERP integrations prevent duplication of suppliers, materials, cost centers, purchasing, and financial postings. The CMMS can reserve a part and record consumption; the ERP can remain the system of record for accounting inventory and procurement.
Defining the system of record by domain prevents divergences. For each data item—asset, material, person, cost, document, condition—there should be a clear owner responsible for creation and updates.
How to specify, implement, migrate, and accept a CMMS
Implementation needs to be treated as an operational and data transformation, not merely software configuration. The greatest risk is putting into production a technically functional platform with a poor asset register, inadequate workflows, and low operational adoption.
Governance needs to exist before configuration
Antes de parametrizar telas, a organização precisa definir quem é dono do processo, quem é dono dos dados e quem pode alterar regras estruturantes. Isso inclui asset hierarchy, taxonomias, criticidade, maintenance plans, códigos de failure, perfis de acesso, integrations, KPIs e work-order closure criteria.
Uma implantação sem governance tende a produzir múltiplas versões da mesma realidade: a maintenance altera tags, o ERP mantém outra descrição, o BIM usa outro identificador e a automação referencia um terceiro nome. O CMMS precisa entrar em uma arquitetura com system of record definido por domínio e regras explícitas de sincronização.
| Domain | Typical governance responsibility | Decision that needs to be defined |
| asset | engenharia / gestão de assets | who creates tag, class, hierarchy, and criticality |
| maintenance | maintenance engineering | who approves plans, frequencies, and procedures |
| work orders | operations / maintenance | who prioritizes, plans, schedules, and closes |
| materials | suprimentos / almoxarifado | which system is master for item, balance, and cost |
| documents | engenharia / gestão documental | where the valid version resides and how it is linked to the asset |
| integrations | IT/OT | source, frequency, error handling, and reconciliation |
| security | TI / cibersecurity | roles, segregation, authentication, audit trail, and administration |
Requirements should originate from use cases
Antes da RFP, a organização precisa definir quais problemas pretende resolver: reduzir corretivas emergenciais, melhorar preventive-maintenance compliance, controlar backlog, integrar estoque, aumentar reliability, rastrear custos, organize documents ou conectar maintenance ao BIM 7D e a operational data and Digital Twin.
Cada caso de uso deve produzir verifiable requirement. “Ter dashboard” é fraco; “mostrar backlog planejado por criticidade, especialidade e semana, com drill-down para work orders” é testável.
Map the AS-IS process and design the TO-BE before configuration
A configuration não deveria automatizar cegamente o processo existente. O AS-IS and TO-BE mapping permite identificar controles paralelos, approvals redundantes, retrabalho, lacunas de responsabilidade e exceções que precisam ser resolvidas antes de virarem regras do sistema.
Quando o fluxo possui múltiplos estados, eventos, decisões e responsáveis, a BPMN modeling ajuda a explicitar a lógica antes da parametrização. O resultado pode então ser traduzido em workflows and technical approvals no CMMS, com papéis, estados, SLA, exceções e evidências definidos.
Procurement should assess capability, not just a feature list
Na contratação, o procurement deve transformar os casos de uso em uma matriz rastreável de requisito, resposta do fornecedor, configuration prevista, integração necessária, cenário de teste e evidência de aceite. Essa estrutura reduz respostas comerciais genéricas e permite comparar propostas sobre a mesma base técnica.
A technical proposal evaluation deve verificar aderência funcional, arquitetura, modelo de dados, security, APIs, mobility, capacidade de migração, suporte, roadmap, limites de customização e dependências de licenciamento. Em implantações críticas, uma abordagem de Owner’s Engineering pode manter independência entre fornecedor, integrador e aceite do proprietário.
O contrato também deve conectar requirements, evidence, and acceptance criteria desde a especificação. Assim, cada requisito relevante possui forma objetiva de demonstração e não fica sujeito à interpretação apenas no encerramento do projeto.
Recommended implementation process
- Define objectives, scope, and KPIs.
- Estabelecer governance e responsáveis.
- Modelar hierarquia e taxonomia de assets.
- Definir criticidade e estratégias de maintenance.
- Desenhar workflows de solicitação, planejamento, programação, execução e encerramento.
- Definir dados obrigatórios e regras de qualidade.
- Sanear e migrar asset register e historys necessários.
- Configure plans, procedures, resources, and materials.
- Integrar sistemas — ERP, BIM/AIM, BMS, SCADA, IoT e demais fontes conforme o caso de uso.
- Testar cenários ponta a ponta.
- Treinar planejadores, técnicos, supervisores e administradores.
- Operar pilot, medir qualidade e corrigir processos.
- Realizar aceite e estabilização.
- Expandir por assets, sites ou funcionalidades com governance.
Pilot and wave-based rollout reduce operational risk
Colocar toda a organização no novo CMMS em um único corte pode concentrar riscos de asset register, integração, treinamento e operations. Em ambientes com muitos sites ou classes de assets, é mais seguro validar o modelo em um pilot representasset e ampliar por ondas controladas.
O pilot não deve escolher apenas o cenário mais simples. Ele precisa incluir critical assets, work orders corretivas e preventivas, mobility and field operations, materials, documents, approvals e pelo menos as integrations que sejam determinantes para o processo. O objetivo é provar que o modelo funciona sob condições reais antes da escala.
| Phase | Objective | Criterion to advance |
| configuration | validate data model and workflows | critical requirements configured and testable |
| pilot | execute real processes within a controlled scope | users operate without material manual workarounds |
| wave 1 | expand to priority classes/sites | stable data quality and indicators |
| subsequent waves | scale while maintaining standards and governance | lessons incorporated and support capacity available |
Data migration is an information-engineering project
Migrating everything is not necessarily better. Duplicate records, inconsistent tags, decommissioned equipment, expired plans, and histories without context should be cleansed before or during migration.
A quality matrix can verify tag uniqueness, completeness of critical fields, hierarchical linkage, valid class, location, criticality, applicable plan, documents, and asset status. Migration acceptance should use sampling and quantitative reconciliation, not merely a count of imported records.
Migration needs staging, reconciliation, and a cutover rule
Uma migração robusta normalmente passa por extração, saneamento, transformação, carga de teste, validação, correção e carga final. É recomendável trabalhar com ambiente de staging para aplicar regras de normalização sem alterar diretamente a origem e para registrar quais campos foram transformados.
Quando identificadores mudam, deve existir uma tabela de correspondência entre códigos antigos e novos. Isso preserva a traceability de historys, documents, work orders e integrations. Registros rejeitados também precisam ser contabilizados e classificados por motivo; simplesmente descartá-los durante a carga impede reconciliação.
O plan de cutover define a passagem da base antiga para a nova: congelamento de alterações, última extração, carga delta quando necessária, validação, abertura do sistema e tratamento das work orders que estavam em andamento. Sem essa regra, a organização corre o risco de iniciar o CMMS com uma lacuna entre o último dado migrado e o primeiro dado criado em produção.
Indicators need to measure the process, not merely produce dashboards
KPIs podem incluir preventive-maintenance compliance, backlog, aging, emergências, disponibilidade, MTTR, MTBF quando tecnicamente aplicável, reincidência, tempo de planejamento, aderência à programação, closeout quality, custo e consumo de sobressalentes.
No indicator should be interpreted in isolation. Reducing MTTR by sacrificing quality or increasing the percentage of completed work orders by closing activities without evidence are examples of optimizing the number at the expense of the outcome.
Tests need to prove the end-to-end process
Testar apenas telas e campos não é suficiente. O test plan deve reproduzir cenários operacionais completos: uma anomalia é identificada, priorizada, planejada, recebe material e recurso, é programada, executada, documentada, encerrada e passa a compor history e indicadores.
| Test level | What needs to be proven | Example |
| configuration | rules, fields, states, permissions, and automations | critical work order requires approval and mandatory evidence |
| integração | correct exchange with external systems and failure handling | contador do BMS atualiza o asset e dispara plan por uso |
| migração | database completeness, consistency, and reconciliation | tag, plan, documents e history permanecem associados |
| UAT | user executes the real case according to the approved process | planner schedules and technician completes the work order in the field |
| security | access, segregation, audit trails, and administration | technician cannot change taxonomy or master plan |
| continuity | recovery and operation during failure | backup restored and integration resumed without improper loss |
O User Acceptance Test — UAT deve ser conduzido por usuários-chave da operations, não apenas pelo fornecedor ou pela equipe de TI. O sistema está pronto quando quem planeja, programa, executa e supervisiona consegue realizar cenários reais com os dados e responsabilidades que existirão em produção.
Go-live readiness needs to be a formal decision
Go-live should not occur simply because the implementation date has arrived. A readiness decision should consolidate open items and verify whether critical elements are acceptable: data, workflows, integrations, profiles, materials, documentation, training, support, contingency, and platform administration.
- critical data migrated and reconciled;
- critical software or configuration defects closed;
- essential integrations tested for volume and exceptions;
- usuários-chave treinados e aprovados no UAT;
- procedimentos de suporte, escalonamento e administração definidos;
- contingency plan available for system unavailability;
- data and process owners formally defined;
- backlog and open work orders prepared for transition.
Acceptance criteria
| Dimension | Acceptance evidence |
| asset register | hierarchy, tags, and critical fields validated |
| plans | correct generation by calendar, counter, or condition |
| workflow | states, roles, approvals, and SLA tested |
| work orders | creation, planning, execution, evidence, and closeout functioning |
| materials | reservation, consumption, and inventory integration where applicable |
| mobility | field operation, attachments, and synchronization tested |
| integrations | APIs/events reconciled with source systems |
| security | profiles, segregation, audit, and authentication verified |
| reports | KPIs reconciled with test data |
| migração | sampling, counts, and quality approved |
| operations | key users execute real scenarios without vendor intervention |
| continuity | backup, recovery, support, and administration documented |
Go-live does not end implementation: stabilization begins
Nas first weeks de produção, o foco muda de configuration para operational stabilization. O período de hypercare deve acompanhar erros de asset register, dúvidas de processo, integration failures, work orders reabertas, tempos de atendimento, closeout quality e volume de chamados de suporte.
É importante separar defeito da plataforma, erro de parametrização, data problem, lack of training e process inadequacy. Sem essa classificação, a organização tende a tratar todos os sintomas como “problema do sistema” e perde a capacidade de corrigir a causa correta.
| Horizon | What to observe | Stabilization signal |
| first weeks | erros críticos, integrations, suporte, execução de work orders | essential processes operate without recurring manual workarounds |
| 30–60 days | qualidade de asset register, fechamento, backlog e aderência aos plans | dados e workflows apresentam consistência operacional |
| 60–90 days | KPIs, user behavior, and management capability | indicadores são confiáveis e já suportam decisões de maintenance |
| continuous cycle | taxonomies, plans, integrations, and rules | mudanças são tratadas por governance e melhoria contínua |
Success should be measured by operational capability
Uma implantação bem-sucedida não é aquela que “entregou todos os módulos”. É aquela em que a organização consegue identificar o correct asset, planejar o trabalho, garantir recursos, executar com informação válida, record evidence, recuperar history e usar os dados resultantes para melhorar maintenance, reliability e decisões de ciclo de vida.
For this reason, adoption and quality targets can be as important as software availability: percentage of work orders with correctly identified assets, completeness of mandatory fields, adherence to the preventive plan, work orders closed with cause and evidence, reduction of duplicate records, integration reconciliation, and effective use of field mobility.
When a CMMS does not solve the problem
A CMMS does not correct the absence of a maintenance strategy, an ownerless asset register, inadequate procedures, disorganized inventory, or a culture of closeout without evidence. It also does not replace reliability engineering, asset management, or operational supervision.
A implantação gera valor quando o sistema formaliza um processo tecnicamente coerente, conecta informação confiável e produz history capaz de melhorar a próxima decisão. O objetivo não é informatizar work orders de serviço; é construir um sistema operacional de maintenance rastreável, mensurável e integrado ao ciclo de vida do asset.
CMMS se aceita por operational evidence, não por aparência. Cadastro, plans, work orders, integrations, mobility, reports e usuários precisam executar cenários ponta a ponta com dados reconciliados.
Technical references
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 55000:2024 — Asset management — Vocabulary, overview and principles. Geneva: ISO, 2024.
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 55001:2024 — Asset management — Asset management system — Requirements. Geneva: ISO, 2024.
[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 14224:2016 — Petroleum, petrochemical and natural gas industries — Collection and exchange of reliability and maintenance data for equipment. Geneva: ISO, 2016.
[4] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-3:2020 — Information management using building information modelling — Part 3: Operational phase of the assets. Geneva: ISO, 2020.
[5] IBM. What is a CMMS? IBM Think. Updated Dec. 5, 2025.
[6] IBM. CMMS vs. EAM: Two asset management tools that work great together. IBM Think.
[7] SAP. What is CMMS software? SAP Brasil.
[8] SAP. What is enterprise asset management (EAM)? SAP Brasil.
Frequently asked questions
CMMS stands for Computerized Maintenance Management System. It is a platform for centralizing maintenance data and workflows, including assets, plans, work orders, resources, materials, and history.
To structure and trace the maintenance process, from identifying the need through planning, scheduling, execution, evidence, closeout, and intervention history.
Not necessarily. CMMS is centered on maintenance operations; EAM typically broadens the scope to the enterprise asset lifecycle, integrating maintenance with capital, procurement, risk, finance, and other functions.
No. A CMMS is an important operational tool, but asset management is a broader discipline focused on value, performance, risk, and lifecycle, according to ISO 55000.
BIM 7D is a convention associated with the use of information in operations and maintenance. BIM/AIM can provide identity, location, properties, and documents, while the CMMS records plans, work orders, failures, resources, and history.
Yes. Events, counters, alarms, or conditions can generate inspections and work orders, provided there are integration rules, asset identity, filtering, and criteria to avoid excessive events with no operational value.
No. Specialist systems, sensors, or analytics can detect degradation and produce diagnostics or recommendations. The CMMS typically transforms that information into an inspection or intervention workflow and records execution.
The minimum set depends on the use case, but typically includes asset hierarchy and register, criticality, plans, procedures, documents, materials, resources, and histories of sufficient quality to support decisions.
Preventive-maintenance compliance, backlog, aging, emergencies, availability, MTTR, MTBF where applicable, recurrence, schedule adherence, cost, material consumption, and closeout quality.
Acceptance should test data, workflows, generation of plans and work orders, integrations, profiles, mobility, reports, migration, security, continuity, and end-to-end scenarios executed by key users.
Additional technical resources
Operations, maintenance, and assets
- BIM 7D: operations, maintenance, Facility Management, and asset management — information for the operational phase.
- Engineering Asset Management — asset register, criticality, lifecycle, and performance.
- Maintenance Engineering — strategies, plans, indicators, and maintenance improvement.
- Reliability and Availability Engineering — failures, criticality, and operational continuity.
Integration and operational data
- Digital Twin: architecture, BIM, IoT, and asset management — diagnostics, prediction, and workflow integration.
- DCIM, BMS, and EPMS in Data Centers — specialist systems and operational data.
- BIM Information Management: ISO 19650 — governance and structured information management.
