Seu Template de dados de Change Management

ServiceNow
Seu Template de dados de Change Management

Seu Template de dados de Change Management

Este Template oferece uma abordagem estruturada para coletar os dados essenciais necessários ao Process Mining eficaz do seu Workflow de Change Management. Ele apresenta os atributos e as atividades recomendados para acompanhamento, além de orientações práticas para a extração dos dados. Use este recurso para preparar seus dados para uma análise completa e para a otimização.
  • Atributos recomendados para coleta
  • Principais atividades para acompanhar e garantir uma descoberta precisa do processo
  • Orientações para extrair dados do ServiceNow
Novo em Event Logs? Aprenda como criar um Event Log de Process Mining.

Atributos do Change Management

Estes são os campos de dados recomendados para incluir no seu Event Log e realizar uma análise abrangente do seu processo de gerenciamento de mudanças.
3 Obrigatório 7 Recomendado 9 Opcional
Nome Descrição
Hora do evento
EventTime
O registro preciso de data e hora em que uma atividade ou evento específico ocorreu.
Descrição

A Hora do evento registra a data e a hora exatas em que uma atividade foi executada ou uma alteração de status foi registrada. Esse registro de data e hora é essencial para ordenar os eventos cronologicamente e para todas as análises baseadas em duração.

No Process Mining, esse atributo permite calcular tempos de ciclo, tempos de processamento e tempos de espera entre atividades. Ele é essencial para Dashboards que analisam a performance, como Change Approval Cycle Time e End-to-End Change Process Flow. Registros de data e hora precisos são a base para identificar atrasos e medir a eficiência do processo em relação aos SLAs.

Por que isso importa

Este registro de data e hora é essencial para sequenciar os eventos corretamente e calcular todas as métricas baseadas em tempo, incluindo tempos de ciclo, durações e aderência ao SLA.

Onde obter

Tabela do ServiceNow: sys_audit, Campo: sys_created_on. Isso fornece o registro de data e hora de cada alteração registrada.

Exemplos
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
ID do Change Request
ChangeRequestNumber
O identificador exclusivo de um Change Request, usado como o ID principal do caso para agrupar todos os eventos relacionados.
Descrição

O ID do Change Request é a base da análise do processo de gestão de mudanças. É um número exclusivo atribuído a cada Change Request, como 'CHG0030001', que conecta todas as atividades, aprovações e tarefas.

No Process Mining, esse atributo é usado para reconstruir a jornada de ponta a ponta de cada mudança. Ele permite que os analistas acompanhem todo o ciclo de vida, da criação ao encerramento, oferecendo uma visão coerente de como cada mudança avança pelo sistema. Analisar os processos agrupados por esse ID é essencial para calcular tempos de ciclo, identificar loops de retrabalho e entender as variantes do processo.

Por que isso importa

Este ID é essencial para acompanhar todo o ciclo de vida de uma mudança, permitindo uma análise completa do fluxo, da duração e da conformidade do processo para cada solicitação.

Onde obter

Tabela do ServiceNow: change_request, Campo: number

Exemplos
CHG0030001CHG0030045CHG0030112
Nome da atividade
ActivityName
O nome de um evento ou tarefa específico que ocorreu no processo de gestão de mudanças.
Descrição

O Nome da atividade descreve uma etapa distinta ou uma alteração de status no ciclo de vida de um Change Request. Exemplos incluem 'Change Awaiting Assessment', 'Approval Requested' e 'Change Implemented'. Essas atividades formam os nós do mapa de processo descoberto.

Analisar essas atividades permite examinar detalhadamente o fluxo do processo. Ao acompanhar a sequência e a frequência das atividades, as organizações podem identificar caminhos comuns, desvios do processo padrão e gargalos nos quais as mudanças costumam ficar paradas. Isso é fundamental para visualizar o processo e calcular métricas como os tempos de transição entre etapas.

Por que isso importa

Ele forma a estrutura central do mapa de processo, permitindo visualizar o fluxo, identificar gargalos e analisar desvios.

Onde obter

Derivado de alterações no campo 'state' ou em outros campos de status importantes da tabela 'change_request', geralmente capturadas na tabela 'sys_audit'.

Exemplos
Change aprovadoImplementação iniciadaChange fechadoChange cancelado
Estado da mudança
ChangeState
O estado atual ou histórico do Change Request, como 'Assess', 'Authorize', 'Implement' ou 'Closed'.
Descrição

O atributo Estado da mudança representa o status de um Change Request em determinado momento. Ele fornece um resumo de alto nível de onde a mudança está em seu ciclo de vida. Diferentemente da Activity, que representa um evento específico, o State é a condição resultante desse evento.

Na análise, o Estado da mudança é usado para categorizar casos e entender seus resultados. Ele é fundamental para filtrar mudanças, por exemplo, para analisar apenas mudanças 'Closed' ou investigar por que muitos Changes estão parados no estado 'Authorize'. Ele dá suporte direto a KPIs como Change Failure Rate quando existe um estado 'Failed'.

Por que isso importa

Fornece uma visão do status do Change Request, permitindo analisar resultados, filtrar casos e identificar mudanças paradas.

Onde obter

Tabela do ServiceNow: change_request, Campo: state

Exemplos
AvaliarAutorizarAgendadoImplementarAnalisarEncerradoCancelado
Grupo de atribuição
AssignmentGroup
A equipe ou o grupo responsável pelo Change Request.
Descrição

O Grupo de atribuição indica qual equipe é atualmente responsável pelo Change Request, como 'CAB Approval', 'Network Engineering' ou 'Database Administrators'. Essa é uma dimensão essencial para analisar a performance do processo em diferentes áreas funcionais.

Este atributo é usado para medir a eficiência no nível da equipe, identificar gargalos em grupos específicos e analisar a eficácia das transferências entre equipes. Dashboards como 'Cross-Functional Handoff Efficiency' e 'Change Implementation Throughput' dependem muito desses dados para localizar atrasos causados por dependências entre equipes.

Por que isso importa

Permite analisar a performance por equipe, destacando gargalos específicos de cada grupo e medindo a eficiência das transferências entre diferentes áreas funcionais.

Onde obter

Tabela do ServiceNow: change_request, Campo: assignment_group

Exemplos
Aprovação do CABEquipe de redesSuporte a servidoresAdministradores de banco de dados
Hora de término
EndTime
O registro de data e hora em que uma atividade foi concluída. Geralmente, ele é derivado do horário de início da atividade seguinte.
Descrição

A Hora de término marca a conclusão de uma atividade. Embora os sistemas de origem geralmente registrem o início de um evento, o horário de término costuma ser inferido. Normalmente, ele é calculado como o registro de data e hora da atividade seguinte na sequência do mesmo caso.

Este atributo é essencial para calcular a duração de cada atividade, conhecida como tempo de processamento. Entender quanto tempo cada etapa leva é fundamental para identificar gargalos e ineficiências no processo. Para a atividade final de um caso, a Hora de término é igual à Hora de início.

Por que isso importa

Permite calcular o tempo de processamento das atividades, essencial para identificar gargalos e medir a duração de etapas específicas do processo.

Onde obter

Normalmente, este atributo é calculado durante a transformação dos dados, usando o StartTime do próximo evento para o mesmo CaseId.

Exemplos
2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
Item de configuração
ConfigurationItem
O componente, serviço ou sistema de TI específico que é objeto da mudança.
Descrição

O Configuration Item (CI) é o ativo da Configuration Management Database (CMDB) que será afetado pela mudança. Pode ser um servidor, um aplicativo de software, um dispositivo de rede ou um serviço de negócio.

Este atributo fornece um contexto essencial para a mudança. No Process Mining, ele permite segmentar a análise pelo tipo de ativo que está sendo alterado. Por exemplo, o Dashboard 'Change Testing Duration Analysis' usa esse atributo para comparar os tempos de teste de diferentes aplicativos ou sistemas, ajudando a identificar quais CIs estão associados a ciclos de teste mais longos.

Por que isso importa

Fornece um contexto de negócio essencial, permitindo filtrar a análise pelo aplicativo, serviço ou sistema afetado para identificar problemas específicos de cada componente.

Onde obter

Tabela do ServiceNow: change_request, Campo: cmdb_ci

Exemplos
SAP ERPOracle Database 19cServiço de e-mailWebServer-01
Nível de risco
RiskLevel
O nível de risco avaliado da mudança, como 'High', 'Moderate' ou 'Low'.
Descrição

O Nível de risco é o resultado do processo de avaliação de risco de um Change Request. Ele quantifica o potencial de consequências adversas caso a mudança seja implementada, ajudando a determinar o nível necessário de análise e aprovação.

Este atributo é essencial para o Dashboard 'Risk Assessment Standardization', no qual é usado para verificar se mudanças semelhantes recebem classificações de risco consistentes. Analisar os fluxos do processo por nível de risco também pode revelar se mudanças de alto risco estão seguindo corretamente um caminho mais rigoroso de aprovação e testes em comparação com mudanças de baixo risco, o que é uma verificação importante de conformidade.

Por que isso importa

É essencial para a análise de conformidade e para garantir que mudanças de alto risco recebam o nível adequado de análise e sigam um processo mais rigoroso.

Onde obter

Tabela do ServiceNow: change_request, Campo: risk

Exemplos
AltaModeradaBaixa
Prioridade
Priority
O nível de prioridade do Change Request, determinado por seu impacto e urgência.
Descrição

A Prioridade indica a importância de um Change Request e determina a ordem em que ele deve ser tratado. Ela geralmente é derivada do impacto e da urgência da mudança, com valores como 'Critical', 'High', 'Moderate' e 'Low'.

Analisar por prioridade é essencial para garantir que mudanças de alta prioridade sejam processadas mais rapidamente do que mudanças de baixa prioridade. Isso dá suporte ao Dashboard 'Critical Change Performance', permitindo que os analistas acompanhem tempos de ciclo e taxas de falha especificamente para as mudanças mais importantes. Qualquer desvio em que mudanças de baixa prioridade sejam concluídas mais rapidamente do que mudanças de alta prioridade indica um problema na alocação de recursos ou na execução do processo.

Por que isso importa

É essencial para avaliar se os recursos estão sendo alocados corretamente às mudanças mais críticas e para monitorar sua performance separadamente.

Onde obter

Tabela do ServiceNow: change_request, Campo: priority

Exemplos
1 - Crítica2 - Alta3 - Moderada4 - Baixa
Tipo de mudança
ChangeType
A classificação da mudança, como 'Standard', 'Normal' ou 'Emergency'.
Descrição

O Tipo de mudança categoriza o Change Request com base em sua natureza, risco e requisitos de aprovação. Mudanças Standard são pré-aprovadas, mudanças Normal seguem o processo completo e mudanças Emergency usam um caminho acelerado.

Esta é uma dimensão fundamental para a análise do processo, pois diferentes tipos de mudança têm modelos de processo distintos e legítimos. Comparar a performance de mudanças Normal e Emergency pode revelar insights importantes sobre a aderência e a eficiência do processo. Ela também é usada em Dashboards como 'Risk Assessment Standardization' para garantir que mudanças semelhantes sejam tratadas de forma consistente.

Por que isso importa

Permite segmentar a análise, pois diferentes tipos de mudança seguem fluxos de processo autorizados distintos e têm expectativas de performance próprias.

Onde obter

Tabela do ServiceNow: change_request, Campo: type

Exemplos
PadrãoNormalEmergencial
Código de encerramento
CloseCode
Um código que indica o resultado no momento em que o Change Request foi encerrado, como 'Successful' ou 'Unsuccessful'.
Descrição

O Código de encerramento fornece a disposição final de um Change Request concluído. Ele registra formalmente se a mudança foi implementada com sucesso, apresentou problemas ou foi revertida.

Este atributo é uma entrada direta para o KPI 'Change Failure Rate'. Ao analisar a distribuição dos códigos de encerramento, as organizações podem quantificar o sucesso de suas iniciativas de mudança. Filtrar o mapa de processo por mudanças com o código de encerramento 'Unsuccessful' é uma técnica poderosa de análise de causa raiz, revelando padrões comuns do processo que levam a falhas.

Por que isso importa

Mede diretamente o resultado de uma mudança, fornecendo os principais dados necessários para calcular a taxa de falha de mudanças e analisar as causas raiz das mudanças malsucedidas.

Onde obter

Tabela do ServiceNow: change_request, Campo: close_code

Exemplos
Bem-sucedidoBem-sucedido com problemasMalsucedido / Revertido
É retrabalho
IsRework
Um indicador booleano que é verdadeiro quando uma atividade representa a repetição de uma etapa anterior no mesmo caso.
Descrição

Este atributo calculado identifica atividades que constituem retrabalho. O retrabalho ocorre quando o processo precisa voltar a uma etapa já concluída, como quando uma mudança é rejeitada após a aprovação e enviada novamente para avaliação.

Este indicador é essencial para quantificar a ineficiência do processo. Ele dá suporte direto ao KPI 'Change Rework Rate' e ao Dashboard 'Change Failure and Rework Analysis'. Ao filtrar as atividades em que 'Is Rework' é verdadeiro, os analistas podem isolar e estudar as causas do retrabalho, como avaliações iniciais incompletas ou mudanças nos requisitos, e agir para reduzir desperdícios.

Por que isso importa

Quantifica diretamente a ineficiência do processo ao sinalizar trabalhos repetidos, ajudando a identificar e tratar as causas raiz de loops no processo e do esforço desperdiçado.

Onde obter

Calculado durante a transformação dos dados, detectando se a mesma atividade, ou uma atividade anterior no fluxo padrão, já ocorreu para o CaseId informado.

Exemplos
truefalse
Estado do SLA
SlaState
O status da solicitação de mudança em relação ao seu Acordo de Nível de Serviço (SLA), como "No prazo", "Em risco" ou "Violado".
Descrição

O estado do SLA indica se a solicitação de mudança está avançando dentro dos prazos definidos pelo SLA. Esse status pode ser acompanhado em cada etapa do processo.

Esse atributo é essencial para monitorar a conformidade com os compromissos de nível de serviço. Ele é a principal fonte de dados do Dashboard "Visão geral da performance do SLA de mudanças" e do KPI "Taxa de aderência ao SLA de mudanças". Analisar onde e por que os SLAs são violados permite que a organização corrija atrasos sistêmicos e aumente a previsibilidade da prestação de serviços.

Por que isso importa

Mede diretamente a performance em relação aos prazos, permitindo o monitoramento proativo e a análise de violações de SLA para melhorar a prestação de serviços.

Onde obter

Esses dados podem ser obtidos da tabela "task_sla" no ServiceNow, que acompanha SLAs relacionados a tarefas como solicitações de mudança, ou calculados com base nos campos de data de vencimento.

Exemplos
No prazoEm riscoFora do prazo
Impacto
Impact
O efeito potencial da mudança sobre as operações de negócio, classificado em uma escala como Alto, Médio ou Baixo.
Descrição

O Impacto mede o efeito potencial sobre o negócio caso o Change Request não seja tratado corretamente. É um dado essencial, junto com a Urgência, para determinar a Prioridade geral da mudança.

Analisar por Impacto ajuda a garantir que mudanças que afetam serviços críticos sejam gerenciadas com o cuidado adequado. Ele é usado no Dashboard 'Critical Change Performance' para isolar e monitorar mudanças com alto impacto no negócio. Também é usado para verificar a consistência da avaliação de risco, garantindo que mudanças de alto impacto não recebam um nível de risco baixo sem justificativa.

Por que isso importa

Ajuda a priorizar mudanças com base em seu possível efeito sobre o negócio e é usado para validar se mudanças de alto impacto estão sendo gerenciadas com a devida diligência.

Onde obter

Tabela do ServiceNow: change_request, Campo: impact

Exemplos
1 - Alta2 - Média3 - Baixa
Sistema de origem
SourceSystem
O sistema do qual os dados foram extraídos, normalmente o 'ServiceNow'.
Descrição

Este atributo identifica a origem dos dados do processo. Embora, neste caso, seja esperado o ServiceNow, ele é um campo essencial para a governança de dados e para cenários em que dados de vários sistemas são combinados.

Na análise, ele garante a rastreabilidade clara dos dados e ajuda a validar sua origem. Para organizações com várias ferramentas de ITSM ou sistemas integrados, esse atributo permite filtrar e comparar processos em diferentes plataformas.

Por que isso importa

Fornece uma rastreabilidade clara dos dados, garantindo que a origem dos dados do processo esteja documentada, algo essencial para a governança de dados e a análise de vários sistemas.

Onde obter

Normalmente, este é um valor estático adicionado durante o processo de extração e transformação de dados (ETL).

Exemplos
ServiceNowServiceNow_PRODSNOW_ITSM
Tempo de ciclo
CycleTime
O tempo total transcorrido entre a criação e o encerramento de uma solicitação de mudança.
Descrição

O tempo de ciclo é uma métrica no nível do caso que mede a duração total do ciclo de vida de uma solicitação de mudança. Ele é calculado pela diferença entre o timestamp do primeiro evento e o timestamp do último evento de uma determinada solicitação de mudança.

Esse é um KPI essencial para medir a velocidade geral do processo. Ele é usado no Dashboard "Fluxo do processo de mudança de ponta a ponta" para oferecer uma visão geral da performance do processo. Analisar as tendências do tempo de ciclo e compará-las em diferentes dimensões, como Tipo de mudança ou Prioridade, ajuda as organizações a identificar oportunidades de melhoria estratégica do processo.

Por que isso importa

Mede a duração de ponta a ponta do processo de mudança, oferecendo um indicador importante da velocidade e da eficiência gerais do processo.

Onde obter

Calculado no nível do caso durante a análise dos dados, subtraindo o StartTime mínimo do StartTime máximo para cada CaseId.

Exemplos
60480012096002592000
Última atualização dos dados
LastDataUpdate
O registro de data e hora que indica quando os dados deste registro foram atualizados pela última vez a partir do sistema de origem.
Descrição

Este atributo fornece o registro de data e hora da última extração de dados. É um campo de metadados essencial para entender o nível de atualização dos dados analisados.

Os analistas usam esse registro para confirmar que estão trabalhando com informações atualizadas e entender a recência dos dados. Ele é especialmente importante para Dashboards operacionais que monitoram a performance contínua do processo, garantindo que as decisões não sejam baseadas em dados desatualizados.

Por que isso importa

Indica o nível de atualização dos dados, garantindo que as análises e os Dashboards sejam baseados em informações atuais e relevantes.

Onde obter

Este é um campo de metadados gerado durante o processo de extração e transformação de dados (ETL), indicando o momento da extração.

Exemplos
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Urgência
Urgency
A velocidade com que uma mudança precisa ser resolvida, classificada em uma escala como Alta, Média ou Baixa.
Descrição

A Urgência define a rapidez com que uma mudança precisa ser implementada. Ela reflete a sensibilidade ao tempo da solicitação do ponto de vista do negócio. Junto com o Impacto, é usada para calcular a Prioridade geral.

Embora a Prioridade seja o principal campo de análise, a Urgência fornece contexto adicional. Ela pode ser usada para investigar por que determinadas mudanças são marcadas como urgentes e se o processo consegue atendê-las com eficiência sem comprometer a estabilidade. Ajuda a responder se a organização está frequentemente operando de forma reativa e com alto nível de urgência.

Por que isso importa

Fornece contexto sobre a sensibilidade ao tempo de uma mudança, ajudando a analisar se o processo lida de forma eficaz com solicitações críticas em relação ao prazo.

Onde obter

Tabela do ServiceNow: change_request, Campo: urgency

Exemplos
1 - Alta2 - Média3 - Baixa
Usuário atribuído
AssignedToUser
O usuário responsável pelo Change Request em determinado momento.
Descrição

Este atributo identifica a pessoa responsável por trabalhar no Change Request. Ele pode mudar várias vezes ao longo do ciclo de vida, conforme a solicitação passa por diferentes etapas e equipes.

Analisar por usuário ajuda a entender a distribuição da carga de trabalho, a performance individual e as necessidades de treinamento. Também é essencial para analisar transferências, especialmente quando combinado com o Grupo de atribuição, permitindo verificar com que eficiência o trabalho é passado entre as pessoas.

Por que isso importa

Ajuda a acompanhar a carga de trabalho e a performance de cada usuário e é essencial para analisar atrasos nas transferências entre diferentes recursos.

Onde obter

Tabela do ServiceNow: change_request, Campo: assigned_to

Exemplos
Beth AnglinDavid LooAbel Tuter
Obrigatório Recomendado Opcional

Atividades do Change Management

Estas são as principais etapas e marcos do processo que você deve registrar no seu Event Log para descobrir com precisão o processo de gerenciamento de mudanças.
7 Recomendado 6 Opcional
Atividade Descrição
Change agendado
A mudança aprovada recebeu uma data planejada de início e término e agora está oficialmente no calendário de implementação. Isso é inferido quando o estado do Change Request muda para 'Scheduled'.
Por que isso importa

Esta atividade separa as etapas de planejamento e aprovação da fase de implementação ativa. O tempo gasto nesse estado pode indicar atrasos entre a aprovação e o início do trabalho.

Onde obter

Inferido a partir da alteração do campo 'state' da tabela change_request para 'Scheduled'. O registro de data e hora é obtido na entrada correspondente do log de auditoria.

Captura

Acompanhe as alterações do campo state para 'Scheduled' no histórico de auditoria da tabela change_request.

Tipo de evento inferred
Change aprovado
O Change Request recebeu todas as autorizações necessárias para avançar para as fases de agendamento e implementação. Este é um marco crítico, capturado quando a aprovação final é concedida e o campo 'approval' é definido como 'approved'.
Por que isso importa

Este marco encerra a fase de aprovação. Ele é essencial para medir os tempos do ciclo de aprovação e identificar gargalos no processo de tomada de decisão.

Onde obter

Inferido a partir da alteração do campo 'approval' da tabela change_request para 'approved'. O registro de data e hora é obtido no histórico de auditoria dessa alteração.

Captura

Capture o registro de data e hora de quando o campo 'approval' se torna 'approved'.

Tipo de evento inferred
Change cancelado
O Change Request foi retirado ou interrompido em algum momento antes da conclusão da implementação. Este é um estado final alternativo, capturado quando o estado é definido como 'Canceled'.
Por que isso importa

Analisar mudanças canceladas pode revelar ineficiências no processo, como solicitações criadas sem necessidade ou que ficaram presas na aprovação por tempo demais e se tornaram obsoletas.

Onde obter

Inferido a partir da definição do campo 'state' da tabela change_request como 'Canceled'. O registro de data e hora é obtido no log de auditoria dessa alteração de estado.

Captura

Capture o registro de data e hora de quando o campo 'state' é atualizado para 'Canceled'.

Tipo de evento inferred
Change fechado
O Change Request foi concluído e revisado com sucesso e agora é considerado finalizado. Este é o principal ponto final de sucesso do processo e é capturado quando o estado da mudança passa para 'Closed'.
Por que isso importa

Esta atividade marca a conclusão bem-sucedida do ciclo de vida da mudança. É o evento final para medir a duração do processo de ponta a ponta e a aderência ao SLA.

Onde obter

Inferido a partir da definição do campo 'state' da tabela change_request como 'Closed'. O registro de data e hora é obtido no histórico de auditoria dessa alteração final de estado.

Captura

Capture o registro de data e hora de quando o campo 'state' é atualizado para 'Closed'.

Tipo de evento inferred
Change implementado
O trabalho de implementação foi concluído, e a mudança está pronta para revisão, verificação ou testes. Esta atividade é inferida quando o estado do Change Request muda de 'Implement' para 'Review'.
Por que isso importa

Este é um marco crítico que encerra a fase de implementação. É um evento importante para calcular os KPIs 'Change Failure Rate' e 'Change Rework Rate'.

Onde obter

Inferido a partir de uma transição de estado de 'Implement' para um estado posterior, como 'Review'. O registro de data e hora é obtido no histórico de auditoria do campo 'state' da tabela change_request.

Captura

Identifique quando o campo 'state' muda de 'Implement' para 'Review'.

Tipo de evento inferred
Change Request criado
Esta atividade registra a criação de um novo registro de Change Request no sistema. É o início oficial do processo de gestão de mudanças e é capturada quando uma nova entrada é inserida na tabela change_request.
Por que isso importa

Este é o principal evento de início do processo. Analisar o tempo entre esta atividade e as demais revela o lead time total e ajuda a identificar atrasos logo no início do processo.

Onde obter

Este evento corresponde ao registro de data e hora da criação (sys_created_on) na tabela change_request do ServiceNow.

Captura

Use o registro de data e hora sys_created_on da tabela change_request.

Tipo de evento explicit
Risco e impacto avaliados
Representa a conclusão da análise de risco e impacto do Change Request. Este é um marco importante antes da solicitação de aprovação e geralmente é inferido quando a mudança sai do estado 'Assess' e passa para 'Authorize' ou 'Awaiting Approval'.
Por que isso importa

Acompanhar a duração da fase de avaliação é essencial para o KPI 'Avg. Risk Assessment Cycle Time'. Isso ajuda a padronizar o processo de avaliação e identificar onde as análises estão demorando demais.

Onde obter

Inferido a partir da transição do campo 'state' da tabela change_request de 'Assess' para 'Authorize'. O registro de data e hora do evento é obtido no log de auditoria dessa alteração de estado.

Captura

Identifique quando o campo 'state' muda de 'Assess' para um estado posterior, como 'Authorize'.

Tipo de evento inferred
Aprovação solicitada
Esta atividade indica que o Change Request foi formalmente enviado para aprovação, normalmente a um gerente ou a um Change Advisory Board (CAB). O evento é capturado quando o status de aprovação do Change Request é definido como 'requested'.
Por que isso importa

Isso marca o início do ciclo de aprovação. Medir o tempo entre este evento e 'Change Approved' calcula diretamente o KPI 'Average Change Approval Time'.

Onde obter

Inferido a partir da alteração do campo 'approval' da tabela change_request para 'requested'. O registro de data e hora é obtido na tabela sys_audit para esse campo.

Captura

Registro de data e hora de quando o campo 'approval' da tabela change_request é definido como 'requested'.

Tipo de evento inferred
Change aguardando avaliação
O Change Request foi enviado e agora aguarda avaliação técnica e de negócio. Normalmente, isso é inferido quando o estado do Change Request muda para 'Assess' ou para um status semelhante, indicando que ele saiu da fase de rascunho.
Por que isso importa

Esta atividade ajuda a medir o tempo inicial de transferência entre o solicitante e a equipe de avaliação. Atrasos nessa etapa podem indicar problemas na qualidade dos dados iniciais ou na disponibilidade de recursos para a avaliação.

Onde obter

Inferido a partir de uma alteração no campo 'state' da tabela change_request, normalmente para um valor como 'Assess'. O registro de data e hora é obtido no histórico de auditoria (sys_audit) dessa alteração de campo.

Captura

Acompanhe as alterações do campo state para 'Assess' no histórico de auditoria da tabela change_request.

Tipo de evento inferred
Change reaberto
O Change Request voltou a um estado anterior, como 'Implement' ou 'Assess', depois de alcançar uma etapa posterior. Este evento é inferido a partir de uma transição de estado não linear e indica retrabalho.
Por que isso importa

Esta atividade é essencial para identificar loops de retrabalho e calcular o 'Change Rework Rate'. Reaberturas frequentes indicam problemas na qualidade da implementação, nos testes ou no planejamento.

Onde obter

Inferido pela análise da sequência de alterações de estado no histórico de auditoria do change_request. Uma transição de um estado posterior, como 'Review', para um estado anterior, como 'Implement', indica um evento de reabertura.

Captura

Detecte uma transição não sequencial e regressiva no histórico do campo 'state'.

Tipo de evento inferred
Change rejeitado
O Change Request foi negado por um aprovador ou pelo CAB. Esta atividade representa um estado terminal para a solicitação, a menos que ela seja retrabalhada e reenviada. O evento é capturado quando o campo 'approval' é definido como 'rejected'.
Por que isso importa

Acompanhar as rejeições ajuda a identificar motivos comuns para a negativa, como informações incompletas ou risco elevado. Essa análise pode melhorar a qualidade dos futuros Change Requests.

Onde obter

Inferido a partir da alteração do campo 'approval' da tabela change_request para 'rejected'. O registro de data e hora é obtido no histórico de auditoria.

Captura

Capture o registro de data e hora de quando o campo 'approval' se torna 'rejected'.

Tipo de evento inferred
Implementação iniciada
O trabalho de implementação da mudança começou efetivamente. Isso é capturado quando o estado do Change Request é atualizado para 'Implement', indicando a transição do planejamento para a execução.
Por que isso importa

Isso marca o início do trabalho prático de implementação. É o ponto de partida para medir o KPI 'Average Implementation Duration' e analisar a eficiência da equipe.

Onde obter

Inferido a partir da alteração do campo 'state' da tabela change_request para 'Implement'. O registro de data e hora é obtido no log de auditoria dessa transição de estado.

Captura

Capture no histórico de auditoria do change_request o registro de data e hora da alteração de estado para 'Implement'.

Tipo de evento inferred
Revisão em andamento
Uma revisão pós-implementação (PIR) está sendo realizada para determinar se a mudança foi bem-sucedida e atingiu seus objetivos. Isso é capturado quando o estado do Change Request é definido como 'Review'.
Por que isso importa

Analisar a duração da fase de revisão ajuda a identificar atrasos na validação do sucesso da mudança. Também destaca mudanças fora de conformidade nas quais essa etapa foi ignorada.

Onde obter

Inferido a partir da alteração do campo 'state' da tabela change_request para 'Review'. O registro de data e hora é obtido no log de auditoria dessa alteração de estado.

Captura

Capture no histórico de auditoria do change_request o registro de data e hora da alteração de estado para 'Review'.

Tipo de evento inferred
Recomendado Opcional

Guias de extração

Como obter seus dados do ServiceNow

Pronto para começar?

Use este Template para preparar seus dados e obter insights sobre seu processo de Change Management no ServiceNow. Comece hoje a otimizar sua eficiência.

Acabe com as mudanças malsucedidas e aumente agora o sucesso no ServiceNow!

Identifique gargalos com facilidade e alcance uma taxa de sucesso de 95% nas mudanças.

Começar o teste grátis

Não é necessário cartão de crédito. Configure tudo em poucos minutos.