ITSM ServiceNow é o modelo de gerenciamento de serviços de TI executado sobre a plataforma ServiceNow, no qual incidentes, problemas, mudanças, requisições, catálogo, conhecimento e níveis de serviço compartilham o mesmo conjunto de dados. Estruturar esse modelo na prática depende de três decisões que antecedem a ferramenta: quando sair do legado, o que precisa estar pronto antes de automatizar e como sustentar a adoção depois do go-live.
Este artigo trata da execução. A definição dos processos e o panorama da disciplina estão no guia sobre serviço de TI para empresas. Aqui o recorte é o projeto de ITSM ServiceNow: critérios de migração, desenho de SLA, faseamento e adoção.
Quando migrar de uma ferramenta ITSM legada para o ServiceNow
A decisão de migrar para o ITSM ServiceNow raramente é respondida por comparação de funcionalidades. Ferramentas legadas de service desk registram incidentes, controlam filas e emitem relatórios, e é por isso que continuam em operação por anos depois de terem deixado de sustentar o modelo de serviços da organização.
O gatilho da migração costuma ser estrutural, não funcional. Ele aparece quando a operação precisa responder perguntas que a ferramenta atual não consegue responder com dados próprios.
- Qual serviço de negócio foi afetado por este incidente, e quais outros dependem do mesmo componente?
- Qual foi o impacto real desta mudança, medido antes e depois da janela de execução?
- Quantas requisições do catálogo são concluídas sem intervenção humana?
- Qual o custo e o ciclo de vida do ativo envolvido neste chamado?
- Quantas integrações precisam ser mantidas para que o service desk enxergue o ambiente?
Quando essas respostas dependem de planilhas, de exportações periódicas ou de um analista que conhece o ambiente de memória, o problema deixou de ser a ferramenta e passou a ser a arquitetura de dados por trás dela.
| Dimensão | Ferramenta ITSM legada | ITSM ServiceNow |
|---|---|---|
| Modelo de dados | Chamado como registro isolado | Chamado relacionado a serviço, CI, ativo e usuário |
| Integrações | Ponto a ponto, mantidas individualmente | Camada de integração compartilhada entre workflows |
| Automação | Scripts e regras por processo | Workflows sobre o mesmo modelo de dados |
| SLA | Tempo de atendimento do ticket | Nível de serviço por oferta, com contexto de disponibilidade |
| Escopo de evolução | Limitado ao service desk | ITSM, ITOM, ITAM, SecOps e áreas de negócio na mesma plataforma |
| Custo relevante | Licença e sustentação da ferramenta | Licença, mais a arquitetura que deixa de ser refeita a cada projeto |
O business case de um projeto de ITSM ServiceNow raramente fecha apenas na comparação de licenças. Ele fecha quando entram no cálculo o custo de manter integrações redundantes, o retrabalho de analistas que consolidam informação manualmente e o risco de mudanças executadas sem análise de impacto confiável. O método para transformar isso em número está detalhado no artigo sobre como medir o ROI do ServiceNow.
O que precisa estar pronto antes de automatizar
Automação sobre processo indefinido apenas acelera a execução de erros. A sequência que sustenta um projeto de ITSM ServiceNow começa pelo modelo, não pelo fluxo.
Essa ordem é também o que o ITIL 5 reforça ao deslocar a medição de outputs para outcomes: maturidade não é quantidade de fluxos publicados, e sim a capacidade de sustentar valor mensurável sobre dados confiáveis.
Catálogo de serviços antes do formulário
Um catálogo de serviços no ITSM ServiceNow não é uma lista de formulários de solicitação. É a definição do que a TI entrega, para quem entrega, com qual prazo acordado e sob qual responsabilidade. Quando o catálogo é construído a partir dos formulários existentes, a organização apenas digitaliza o modelo antigo e herda suas inconsistências.
A ordem correta é definir as ofertas de serviço, os responsáveis por cada uma e os compromissos associados. Os formulários e as regras de aprovação vêm depois, como consequência da definição.
CMDB e CSDM como camada de contexto
O que diferencia um chamado no ITSM ServiceNow de um chamado em qualquer ferramenta de tickets é o contexto. Esse contexto vem da CMDB e da estrutura definida pelo CSDM, que relacionam aplicações, serviços de negócio, componentes de infraestrutura e ofertas.
Não é necessário ter a CMDB completa para iniciar o ITSM, e exigir isso costuma travar o projeto por trimestres. O que é necessário é ter o modelo do CSDM definido e os serviços críticos mapeados antes de prometer análise de impacto automatizada. O caminho está descrito no guia de implementação de CMDB e CSDM, e o desenho dessa fundação é o escopo dos serviços de CMDB da 4MATT.
Papéis, filas e critérios de priorização
Matriz de impacto e urgência, critérios de escalonamento, grupos de atribuição e responsáveis por aprovação precisam estar acordados antes da configuração. São decisões organizacionais que o ITSM ServiceNow executa, não decisões que a plataforma toma. Projetos que deixam esse acordo para a fase de testes tendem a entrar em go-live com filas genéricas e priorização informal.
SLA e automação de fluxos no ITSM ServiceNow
SLA é o ponto em que a maioria das implementações de ITSM ServiceNow fica a meio caminho. O cronômetro do ticket é configurado, os relatórios passam a mostrar percentual de cumprimento e a percepção do negócio sobre a qualidade do serviço permanece a mesma.
SLA de ticket e SLA de serviço não medem a mesma coisa
| Aspecto | SLA de ticket | SLA de serviço |
|---|---|---|
| Objeto medido | Registro individual | Oferta de serviço entregue ao negócio |
| Início da contagem | Abertura do chamado | Indisponibilidade ou degradação percebida |
| Pausas | Aguardando usuário, aguardando terceiro | Janelas acordadas de manutenção |
| Responsável | Grupo de atendimento | Dono da oferta de serviço |
| Pergunta respondida | O time atendeu no prazo? | O serviço esteve disponível como acordado? |
| Uso executivo | Desempenho operacional do service desk | Conversa com as áreas de negócio e com o regulador |
As duas medições são legítimas e se complementam. O erro é apresentar a primeira como se fosse a segunda. Um service desk pode cumprir 98% dos SLAs de atendimento enquanto um serviço crítico acumula indisponibilidade recorrente, porque cada ocorrência foi tratada dentro do prazo do ticket. A disciplina que organiza essa distinção está detalhada no guia de gerenciamento do nível de serviços.
O ServiceNow ITSM permite operar os dois níveis quando as ofertas de serviço estão modeladas e relacionadas aos itens de configuração. Sem essa relação, resta apenas o cronômetro.
O que muda em instituições financeiras
Em instituições autorizadas a funcionar pelo Banco Central do Brasil, o registro de incidentes deixa de ser apenas insumo operacional e passa a ser evidência regulatória. A Resolução CMN nº 4.893, de 26 de fevereiro de 2021, em vigor desde 1º de julho de 2021, dispõe sobre a política de segurança cibernética e sobre os requisitos para contratação de serviços de processamento e armazenamento de dados e de computação em nuvem, e substituiu as Resoluções 4.658/2018 e 4.752/2019.
Três exigências da norma têm efeito direto sobre o desenho dos fluxos. A resolução determina o registro, a análise da causa e do impacto e o controle dos efeitos dos incidentes relevantes para as atividades da instituição. Determina a comunicação tempestiva ao Banco Central das ocorrências de incidentes relevantes e das interrupções de serviços relevantes que configurem situação de crise. E determina a elaboração de relatório anual que aborde, entre outros pontos, os incidentes relevantes ocorridos no período e os resultados dos testes realizados.
Traduzido para a configuração do ITSM ServiceNow, isso significa que a classificação de relevância precisa ser um campo governado e não um julgamento do analista de plantão, que o fluxo de incidentes relevantes precisa ter etapa própria de notificação com prazo controlado, que a análise de causa raiz precisa ser um registro obrigatório e rastreável e não um documento anexo, e que o relatório anual precisa ser extraível da própria base, sem reconstrução manual. A prática de análise pós-incidente está detalhada no artigo sobre post-mortem de incidentes.
O mesmo raciocínio se aplica à automação de fluxos no ITSM ServiceNow. Em ambiente regulado, cada etapa automatizada precisa produzir trilha de auditoria, preservar segregação de funções nas aprovações e manter o histórico de quem aprovou o quê, com base em qual informação. Automação que reduz cliques mas apaga evidência cria um passivo de conformidade.
Implementação de ITSM ServiceNow por fases
O faseamento de um projeto de ITSM ServiceNow reduz risco porque cada onda entrega valor operacional e gera os dados que sustentam a onda seguinte. A divisão abaixo é um ponto de partida, e o escopo de cada onda varia conforme o porte da operação e a maturidade dos processos atuais.
| Onda | Escopo típico | Pré-requisito | Resultado esperado |
|---|---|---|---|
| 1. Fundação | Incidente, requisição, catálogo inicial, base de conhecimento | Modelo de serviços definido, papéis acordados | Canal único de entrada e backlog visível |
| 2. Contexto | CMDB dos serviços críticos, CSDM, relação chamado e CI | Fontes de dados identificadas e Discovery planejado | Análise de impacto com base em relacionamento |
| 3. Controle | Mudança, problema, SLA por oferta de serviço | Contexto da onda 2 em operação | Decisão de mudança com risco avaliado |
| 4. Automação | Fluxos de requisição sem intervenção, integrações, autoatendimento | Processos estáveis e volumetria conhecida | Redução de atividade manual recorrente |
| 5. Inteligência | Recursos de IA aplicados a triagem, sumarização e conhecimento | Dados consistentes e conhecimento curado | Ganho de tempo com controle e rastreabilidade |
A tentação recorrente é antecipar a onda 5. Recursos de inteligência artificial aplicados sobre uma base de conhecimento desatualizada e uma CMDB incompleta produzem recomendações erradas com aparência de precisão, o que custa mais confiança do que a automação economiza em tempo.
Adoção depois do go-live
Uma implementação de ITSM ServiceNow tecnicamente correta pode falhar por adoção. O sintoma é conhecido: a plataforma entra em produção, o WhatsApp e o e-mail continuam sendo o canal real de solicitação, e o dado da ferramenta deixa de representar a operação.
A adoção depende de três decisões tomadas durante o projeto, não depois dele. Nenhuma delas é um plano de comunicação, e nenhuma delas se resolve com treinamento no mês do go-live.
Fechar os canais paralelos com uma alternativa melhor
Desligar o e-mail do service desk sem que o portal resolva a demanda com menos esforço apenas cria resistência. O portal precisa ser o caminho mais rápido, e não apenas o caminho oficial. Isso inclui autoatendimento que efetivamente conclui a solicitação, e não formulários que geram um chamado para alguém executar manualmente.
Envolver os grupos executores no desenho, não na homologação
Times que participam da definição de filas, critérios e formulários chegam ao go-live com o modelo compreendido. Times que veem o fluxo pela primeira vez no treinamento chegam com uma ferramenta imposta.
Tratar o primeiro trimestre como parte do projeto
Ajuste de formulários, correção de regras de atribuição, revisão de SLAs mal calibrados e curadoria de conhecimento são atividades previsíveis. Quando o time de projeto sai no dia do go-live, esses ajustes ficam sem dono e a percepção de que a ferramenta não funciona se consolida.
Indicadores que mostram adoção real
- Percentual de chamados abertos pelo portal ou pelo assistente virtual, em relação ao total.
- Percentual de requisições concluídas sem intervenção manual.
- Taxa de reabertura e de reclassificação de chamados, que indica se a categorização está compreendida.
- Uso efetivo da base de conhecimento, medido por artigos acessados antes da abertura do chamado.
- Proporção de mudanças executadas com registro prévio, comparada às mudanças emergenciais.
- Percentual de incidentes com item de configuração preenchido, que mede se o contexto está sendo usado.
O último indicador é o mais revelador. Ele mostra se a organização está de fato operando serviços no ITSM ServiceNow ou apenas registrando tickets em uma plataforma nova, com a mesma prática anterior e um custo de licença maior.
ITSM ServiceNow conectado a CMDB, ITOM e ITAM
O retorno de um projeto de ITSM ServiceNow cresce quando as disciplinas deixam de operar isoladas. O ITSM organiza como os serviços são solicitados e suportados. O ITOM dá visibilidade sobre a infraestrutura e os eventos que sustentam esses serviços. O ITAM controla o ciclo de vida dos ativos de hardware e software envolvidos. A CMDB, estruturada pelo CSDM, é a camada que conecta os três.
Na prática, isso muda o que o analista vê ao abrir um chamado no ITSM ServiceNow: qual serviço está afetado, qual ativo está envolvido, qual o contrato de suporte vigente e qual mudança recente tocou o mesmo componente. Uma visão geral de como esses módulos se organizam na plataforma está no guia sobre o que é ServiceNow.
Como a 4MATT conduz um projeto de ITSM ServiceNow
A 4MATT é ServiceNow Elite Partner no Brasil, com mais de 80 especialistas certificados, e recebeu o Technology Excellence Partner Award 2024–2025. A abordagem começa pela arquitetura do serviço e não pela configuração do formulário.
O trabalho parte do diagnóstico do modelo atual, dos processos, das integrações e dos pontos de fricção. Em seguida define a arquitetura de serviços e dados, com o catálogo, as ofertas, os responsáveis e a relação com CMDB e CSDM. A configuração dos workflows vem depois dessa definição, seguida pelas integrações, pela automação das atividades recorrentes e pelo modelo de governança que sustenta a evolução após o go-live.
Essa sequência reduz customização desnecessária e cria uma fundação que acompanha a evolução da plataforma, em vez de precisar ser refeita a cada nova capacidade adotada.
Perguntas frequentes sobre ITSM ServiceNow
Vale a pena migrar de uma ferramenta ITSM legada para o ServiceNow?
A migração para o ITSM ServiceNow se justifica quando a limitação deixou de ser funcional e passou a ser estrutural, ou seja, quando a operação precisa relacionar chamados a serviços, ativos e itens de configuração e a ferramenta atual não sustenta esse modelo de dados. Se a necessidade é apenas registrar e encaminhar chamados, o ganho tende a não compensar o esforço do projeto.
É possível migrar o histórico de chamados da ferramenta antiga?
Tecnicamente sim, mas a decisão deve ser tomada por critério de uso, não por volume. Histórico migrado sem o modelo de dados equivalente ocupa a base sem produzir análise confiável. A prática comum é migrar registros abertos e um recorte histórico definido por necessidade de auditoria ou de análise de recorrência, mantendo o restante em consulta na ferramenta de origem pelo prazo de retenção aplicável.
Precisa ter a CMDB pronta antes de iniciar o ITSM?
Não. Exigir CMDB completa antes de iniciar o ITSM ServiceNow costuma adiar o projeto sem reduzir risco. O que precisa estar definido antes é o modelo do CSDM e o mapeamento dos serviços críticos, o suficiente para que a análise de impacto entregue na onda de controle tenha base real.
Como definir SLA por serviço e não apenas por ticket?
Para trabalhar com SLA por serviço no ITSM ServiceNow é necessário ter as ofertas de serviço modeladas, com dono definido, janelas de manutenção acordadas e relação com os itens de configuração que sustentam cada oferta. Sem esses elementos, o único SLA possível é o tempo de atendimento do chamado, que mede o desempenho do time e não a disponibilidade do serviço.
O que muda em um projeto de ITSM ServiceNow no setor financeiro?
Muda o peso da evidência. Em instituições autorizadas pelo Banco Central, a Resolução CMN nº 4.893/2021 exige registro e análise de causa e impacto de incidentes relevantes, comunicação tempestiva ao regulador e relatório anual. Isso torna obrigatórios controles que em outros setores são opcionais, como classificação governada de relevância, trilha de auditoria nas automações e segregação de funções nas aprovações.
Quanto tempo leva uma implementação de ITSM ServiceNow?
O prazo depende do escopo da primeira onda, do número de grupos executores envolvidos, da quantidade de integrações e da maturidade dos processos atuais. O fator que mais alonga cronogramas não é a configuração da plataforma, e sim o tempo necessário para a organização acordar catálogo, papéis e critérios de priorização. Estimativas confiáveis só surgem depois do diagnóstico.
Como garantir que o time vai adotar o ServiceNow depois da implementação?
A adoção do ITSM ServiceNow se constrói durante o projeto, não depois. Os três fatores com maior efeito são envolver os grupos executores no desenho dos fluxos e não apenas na homologação, garantir que o portal seja o caminho mais rápido antes de fechar os canais paralelos, e manter time de projeto atuando no ajuste fino durante o primeiro trimestre após o go-live. Sem isso, a operação real migra para canais informais e o dado da plataforma deixa de representar o que acontece.