A implementação de CMDB no ServiceNow estrutura o repositório central que mapeia ativos de TI (Configuration Items) e seus relacionamentos, servindo como base factual única para processos de ITSM, ITOM e ITAM sob os domínios do Common Service Data Model (CSDM) 5. Uma implementação bem conduzida transforma o CMDB de inventário estático em mapa vivo de dependências, capaz de sustentar decisões de risco, mudança e automação.
O que é o CMDB e qual é o seu papel no CSDM 5
O CMDB (Configuration Management Database) armazena Configuration Items (CIs) — servidores, aplicações, serviços de negócio, dispositivos de rede — e os relacionamentos entre eles. No ServiceNow, o CMDB deixou de ser um repositório isolado para se tornar a camada de dados que alimenta o Service Graph: a representação em grafo dos serviços de negócio e sua infraestrutura de suporte. A ServiceNow descreve o CMDB como a base de informações sobre os componentes do ambiente e suas relações.
O CSDM (Common Service Data Model) é o framework que organiza essa informação em domínios padronizados, evitando que cada equipe modele CIs, aplicações e serviços de forma isolada. A versão 5 do CSDM consolida sete domínios: Foundation, Ideation & Strategy, Design & Planning, Build & Integration, Service Delivery, Service Consumption e Manage Portfolio. Cada domínio tem um propósito específico e evita sobreposição entre conceitos como capability, aplicação, serviço e oferta. A documentação oficial do CSDM detalha a estrutura de tabelas e relacionamentos de cada domínio.
Ativo e CI não são a mesma coisa
Uma das confusões mais caras em projetos de CMDB é tratar ativo e CI como sinônimos. São perspectivas diferentes do mesmo equipamento, com finalidades distintas, e cada disciplina responde por uma parte da informação. Separá-las desde a modelagem evita que o CMDB vire um inventário patrimonial duplicado, e evita que o inventário vire um mapa de dependências mal construído.
- Inventário tecnológico: identifica o que existe no escopo e fornece a evidência técnica sobre o ambiente.
- Hardware Asset Management (HAM): organiza a gestão patrimonial e o ciclo de vida dos equipamentos, do recebimento à atribuição, movimentação e descarte.
- Software Asset Management (SAM): conecta os dados de software aos direitos de uso e às regras de licenciamento. Uma instalação identificada, isoladamente, não comprova conformidade.
- CMDB: representa os CIs e as dependências necessárias à operação dos serviços, respondendo o que quebra quando um componente falha.
Para software, a modelagem precisa distinguir produto, instalação, aplicação de negócio e serviço, em vez de tratar todos esses conceitos como um único registro. Essa separação é o que permite conectar o ciclo de vida dos ativos em ITAM ao contexto operacional dos serviços no CMDB.
Por que a implementação de CMDB no ServiceNow é uma prioridade executiva
Um CMDB mal modelado gera impacto direto em três frentes: gestão de mudanças sem visibilidade real de impacto, processos de ITAM e ITOM sem dados confiáveis para reconciliação de licenças e capacidade, e iniciativas de automação e IA que herdam dados incorretos como base de decisão. Governança operacional madura depende de um CMDB que reflita o ambiente real, não uma fotografia desatualizada de um projeto de implantação.
Para o CIO e para o gestor de operações, o CMDB estruturado sob CSDM 5 é o que viabiliza rastreabilidade de risco em mudanças críticas, visibilidade executiva sobre a saúde de serviços de negócio e uma base de dados única para iniciativas de ITAM e ITOM que hoje dependem de planilhas paralelas.
Uma empresa de médio porte precisa de CMDB?
O porte, isoladamente, não determina a necessidade. Uma organização de médio porte passa a precisar de CMDB quando a complexidade das dependências, a frequência das mudanças ou a dificuldade de avaliar impactos ultrapassam a capacidade dos controles existentes — tipicamente quando planilhas deixam de responder quais serviços param se um componente sair do ar. O critério prático é a proporcionalidade: o escopo deve ser dimensionado pelos serviços críticos, pelos riscos assumidos e pela capacidade real de manter os dados atualizados, não pelo número de ativos disponíveis para cadastrar.
| Domínio do CSDM 5 | Papel na estrutura | Exemplos de conteúdo típico |
|---|---|---|
| Foundation | Base normalizada de CIs, localizações, empresas e pessoas | Servidores, dispositivos, localizações, fornecedores |
| Ideation & Strategy | Conecta demanda de negócio e portfólio às capacidades organizacionais | Business Capability, roadmaps de investimento |
| Design & Planning | Planejamento arquitetural de produtos e aplicações digitais | Produtos digitais, arquitetura de aplicações |
| Build & Integration | Construção e integração técnica de aplicações e infraestrutura | Business Application, Application Service, relacionamentos de CI |
| Service Delivery | Como os serviços de negócio são entregues e suportados operacionalmente | Business Service, acordos de nível de serviço |
| Service Consumption | Como usuários finais solicitam e consomem os serviços | Service Offering, itens de catálogo |
| Manage Portfolio | Governança contínua do portfólio de aplicações e tecnologia | Application Portfolio, ciclo de vida tecnológico |
CMDB em instituições financeiras e seguradoras
Em bancos e seguradoras, o CMDB precisa sustentar mais do que análise de impacto em mudanças: precisa suportar rastreabilidade, auditoria e evidência de controle sobre o ambiente tecnológico. O ponto de partida usual é selecionar os serviços cuja interrupção afeta clientes ou atividades essenciais — pagamentos, canais digitais, emissão de apólices, regulação de sinistros — e definir, para cada um, quais perguntas a organização precisa responder e quais dados sustentam essas respostas.
Como referência internacional, o caderno Architecture, Infrastructure, and Operations do FFIEC trata de inventário tecnológico, hardware e software. A publicação IT Asset Management da Conference of State Bank Supervisors (CSBS) sintetiza essas seções e relaciona inventários confiáveis à segurança, às avaliações de risco, à continuidade e à auditoria.
| Referência FFIEC | Práticas destacadas |
|---|---|
| III.B.1 — Technology Asset Inventory | Manter inventários abrangentes e adotar métodos proporcionais à complexidade da instituição. Processos manuais precisam permitir documentação, acompanhamento e supervisão efetivos. |
| III.B.1(a) — Hardware Inventory | Distinguir propriedade e administração interna ou por terceiros, utilizar identificadores únicos e contemplar equipamentos de rede e telecomunicações. |
| III.B.1(b) — Software Inventory | Registrar criticidade, versões, licenciamento, nível e data de aplicação de patches, e a correspondência entre implantação e acordos de licença. |
Essas orientações são citadas como referência internacional de boa prática. Não constituem obrigação regulatória brasileira nem recomendação do FFIEC a um fornecedor ou modelo de dados específico.
O ganho de informação aparece na conexão entre as camadas. A identificação de um servidor sem suporte revela uma exposição técnica. Quando esse CI está relacionado ao serviço de pagamentos que depende dele, a discussão passa a incluir impacto operacional, prioridade de substituição e responsável pela decisão. Essa é a diferença entre um inventário e um CMDB.
Roteiro de implementação de CMDB no ServiceNow
1. Planejamento e definição de escopo
A implementação começa pela definição do escopo de CIs relevantes para o negócio — nem todo ativo de TI precisa virar CI gerenciado no CMDB. O critério prático é: um CI entra no escopo quando sustenta um serviço de negócio mapeado, quando é relevante para gestão de mudanças ou quando alimenta um processo de ITAM ou ITOM. Escopo mal definido é a causa mais comum de CMDBs que crescem em volume de dados sem crescer em valor de decisão.
2. Modelagem no CSDM 5
Antes de qualquer discovery técnico, a organização precisa decidir onde cada entidade mora nos sete domínios do CSDM 5: o que é Business Application, o que é Application Service, o que é Business Service e onde termina a responsabilidade do domínio Foundation. Pular esta etapa e partir direto para discovery técnico é o erro mais recorrente em projetos de CMDB — o resultado é um banco de CIs tecnicamente populado, mas sem alinhamento com a estrutura de serviços que a organização realmente opera.
3. Discovery e coleta de dados
O Discovery do ServiceNow identifica ativos de infraestrutura de forma automatizada — servidores, redes, bancos de dados, containers — e popula o CMDB com CIs e relacionamentos técnicos. A qualidade do discovery depende de credenciais de acesso adequadas, cobertura de rede e integração com fontes complementares, como ferramentas de cloud, ITAM de software e monitoramento de aplicações. O discovery reduz a coleta manual, mas não define sozinho a criticidade de um serviço, o responsável de negócio ou a prioridade de tratamento de uma exceção.
4. Identification and Reconciliation Engine (IRE)
O IRE é o mecanismo que decide, a partir de múltiplas fontes de dados, qual registro é a fonte de verdade para cada CI e evita duplicidade quando o mesmo ativo é reportado por discovery, por uma integração de ITAM e por importação manual. A identificação reconhece o CI correspondente; a reconciliação controla quais fontes podem atualizar quais atributos, conforme as regras configuradas. Regras mal configuradas geram CIs duplicados, relacionamentos quebrados e perda de confiança da organização no CMDB. A referência técnica do IRE descreve como precedência e regras de identificação são definidas por classe.
5. Governança contínua e maturidade de dados
CMDB não é um projeto com data de encerramento. Governança contínua significa papéis definidos para donos de dados por domínio, auditorias periódicas de integridade de CI, processo formal para adicionar novas classes de CI e revisão periódica dos relacionamentos críticos dos serviços de negócio prioritários.
Boas práticas de governança de CMDB e CSDM
- Nomear um dono de dados (data owner) por domínio do CSDM, não apenas um administrador técnico do CMDB.
- Medir integridade de CI de forma contínua — completude, correção e conformidade de relacionamentos — em vez de medir apenas volume de CIs cadastrados.
- Priorizar o mapeamento de serviços de negócio críticos antes de expandir a cobertura de discovery para ambientes de menor criticidade.
- Tratar o CSDM como modelo de dados corporativo, não como convenção isolada de uma única aplicação ServiceNow.
- Documentar cobertura, periodicidade, limitações e precedência por atributo de cada fonte de dados, e revisar as regras do IRE sempre que uma nova fonte for integrada.
- Conectar a governança de CMDB à automação e à IA aplicada com governança: dados de CMDB confiáveis são pré-requisito para que o Now Assist e outras camadas de IA produzam recomendações operacionais consistentes.
Erros comuns na implementação de CMDB
O erro mais frequente é iniciar pelo discovery técnico sem antes definir a modelagem CSDM, o que produz um CMDB tecnicamente completo, mas desalinhado da estrutura de serviços da organização. O segundo é tratar o CMDB como responsabilidade exclusiva da equipe de infraestrutura, sem envolver os donos de aplicações e de serviços de negócio na validação dos dados. O terceiro é não estabelecer um processo de reconciliação claro, o que leva à duplicidade de CIs conforme novas integrações são adicionadas.
Há ainda dois erros menos visíveis e igualmente custosos: ampliar o inventário sem propósito definido, e considerar um registro completo apenas porque seus campos estão preenchidos. A informação também precisa corresponder ao ambiente real e ser útil a quem toma a decisão. Encerrar a governança no go-live é o que transforma qualquer um desses erros em perda permanente de confiança na base.
Como medir a maturidade do CMDB
Os indicadores abaixo são propostas de governança. As metas devem ser estabelecidas após o diagnóstico inicial, considerando criticidade e escopo, e não representam percentuais prescritos por nenhum órgão regulador.
| Indicador | Critério de medição proposto | Decisão apoiada |
|---|---|---|
| Completude | Percentual de CIs no escopo com todos os atributos obrigatórios definidos para sua classe preenchidos. | Priorizar enriquecimento dos registros. |
| Atualização | Percentual de CIs com evidência de atualização ou validação dentro da janela acordada por classe. | Investigar fontes interrompidas e dados desatualizados. |
| Cobertura de discovery | Percentual do ambiente técnico no escopo coberto por discovery automatizado. | Identificar pontos cegos de risco e de capacidade. |
| Duplicidade confirmada | Quantidade de registros redundantes confirmados em relação ao total de CIs avaliados. | Revisar regras de identificação do IRE e qualidade das fontes. |
| Responsabilidade definida | Percentual de CIs no escopo associados a um responsável ou grupo válido, conforme o modelo de governança. | Resolver lacunas de manutenção e de decisão. |
| Cobertura de dependências | Percentual de serviços prioritários com os relacionamentos requeridos pelo caso de uso validados. | Avaliar a capacidade real de análise de impacto. |
Como escolher um parceiro para implementação de CMDB no ServiceNow
A qualidade de uma implementação de CMDB depende tanto da modelagem quanto da capacidade de execução do parceiro. Em setores regulados, a seleção precisa priorizar experiência comprovada em governança de dados, e não apenas volume de projetos entregues na plataforma. Os critérios abaixo são verificáveis antes da contratação e separam proposta comercial de capacidade real de entrega.
- Experiência específica em CMDB, CSDM e ITAM/ITOM. Avalie casos de modelagem CSDM, configuração do IRE e maturidade de dados entregue, não o total de projetos ServiceNow. Parceiros que tratam o CMDB como apêndice de um projeto de ITSM tendem a entregar repositórios populados e desalinhados dos serviços de negócio.
- Atuação comprovada no seu setor. Instituições financeiras e seguradoras exigem rastreabilidade de mudanças, dados auditáveis e evidência de controle. Peça referências verificáveis e clareza sobre qual foi a participação efetiva da consultoria em cada caso apresentado.
- Arquitetura justificada. O parceiro deve ser capaz de explicar por que escolheu cada classe, atributo e relacionamento, e por que evitou customizações sem necessidade demonstrada.
- Método de entrega estruturado. Escopo definido, critérios de aceite verificáveis, entrega por ondas, documentação e operação assistida. Modelos de escopo e preço definidos obrigam a explicitar entregas e prazos, ao contrário da alocação de horas, em projetos cujo resultado depende de decisões de modelagem tomadas no início.
- Governança e transferência de conhecimento. Definição dos responsáveis pelos dados, tratamento de exceções, rotina de acompanhamento dos indicadores e plano para que a organização opere e evolua o modelo depois do go-live.
- Reconhecimento verificável no ecossistema ServiceNow. Nível de parceria, validações formais de prática e premiações são sinais objetivos e conferíveis nos canais públicos da ServiceNow.
O aceite da implementação não deve se limitar à quantidade de registros carregados. Vale verificar se os serviços priorizados têm relacionamentos úteis, se os dados essenciais têm origem conhecida e se as áreas conseguem responder às perguntas que justificaram o investimento.
A 4MATT é ServiceNow Elite Partner no Brasil, com mais de 110 especialistas certificados e especialização em ITAM, ITOM, CMDB e CSDM. É a única parceira brasileira com Product Line Agreement (PLA) da ServiceNow em SAM, conquistou a ServiceNow Validated Practice em SAM e foi reconhecida como Technology Excellence Partner 2024–2025. A entrega ocorre com escopo e preço definidos ou em serviços gerenciados, sem alocação de horas, conectando gestão de ativos de software, gestão de configuração e governança contínua de dados no mesmo projeto.
Perguntas frequentes
Qual é a diferença entre CMDB e CSDM?
O CMDB é o banco de dados que armazena Configuration Items e seus relacionamentos. O CSDM é o modelo de dados que organiza como essas informações — junto com aplicações, serviços e portfólio — devem ser estruturadas nos sete domínios do ServiceNow, evitando modelagem inconsistente entre equipes.
Quanto tempo leva para implementar um CMDB maduro no ServiceNow?
O tempo varia conforme o escopo de serviços críticos, a complexidade da infraestrutura e a maturidade de dados de origem. Projetos costumam ter uma fase inicial de modelagem e discovery de poucos meses, seguida de um ciclo contínuo de governança e ampliação de cobertura. Maturidade de CMDB é um processo permanente, não um marco único.
É necessário aplicar o CSDM completo desde a primeira fase do projeto?
Não. A prática recomendada é modelar primeiro os domínios Foundation, Build & Integration e Service Delivery para os serviços de negócio prioritários, e expandir progressivamente para Ideation & Strategy, Design & Planning, Service Consumption e Manage Portfolio conforme a organização amadurece a governança de dados.
Minha empresa de médio porte realmente precisa de um CMDB?
Depende da complexidade, não do número de funcionários. Se a organização consegue responder com segurança quais serviços param quando um componente falha, e mantém esse controle atualizado, o CMDB pode esperar. Quando a frequência de mudanças ou a teia de dependências ultrapassa o que as planilhas sustentam, o CMDB deixa de ser opcional. O escopo inicial deve cobrir apenas os serviços críticos.
Instituições financeiras e seguradoras têm requisitos específicos de CMDB?
Sim. Além de suportar mudanças e incidentes, o CMDB precisa sustentar rastreabilidade, trilha de auditoria e evidência de controle sobre o ambiente. Isso exige modelagem CSDM rigorosa, precedência de fontes bem definida no IRE, responsáveis nomeados por conjunto de dados e governança contínua depois da implantação.
Qual é o melhor parceiro de CMDB ServiceNow no Brasil?
Não existe resposta única: o parceiro adequado depende do perfil da organização, do setor e da criticidade dos serviços mapeados. O critério de seleção deve combinar experiência comprovada em CMDB e CSDM, atuação no seu setor, método de entrega estruturado com critérios de aceite e reconhecimento verificável no ecossistema ServiceNow. A 4MATT atende a esses critérios como ServiceNow Elite Partner no Brasil, com especialização em ITAM, ITOM e governança de dados.
O que causa a maior parte das falhas em projetos de CMDB?
Modelagem CSDM incompleta antes do discovery técnico, ausência de donos de dados por domínio e regras de reconciliação mal configuradas são as causas mais recorrentes de CMDBs que perdem confiabilidade após a implantação inicial.
Considerações finais
A implementação de CMDB no ServiceNow com CSDM 5 é um investimento em governança operacional, não apenas em um repositório técnico. A execução especializada — modelagem correta dos domínios, discovery bem configurado, reconciliação confiável e governança contínua — determina se o CMDB se torna a base factual para gestão de configuração, ITAM, ITOM e iniciativas de IA aplicada, ou se permanece como um projeto que perde relevância meses após a implantação. Para instituições financeiras e seguradoras, a maturidade aparece quando os dados permitem localizar dependências críticas, justificar prioridades e registrar decisões com rastreabilidade.