Seu Template de dados de Change Management
Seu Template de dados de Change Management
- Atributos recomendados para coleta
- Principais atividades para acompanhar e garantir uma descoberta precisa do processo
- Orientações para extrair dados do ServiceNow
Atributos do Change Management
| 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
|
|||
Atividades do Change Management
| 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
|
|||
Guias de extração
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.
Não é necessário cartão de crédito. Configure tudo em poucos minutos.