Seu Template de Dados de Gestão de Mudanças
Seu Template de Dados de Gestão de Mudanças
- Atributos recomendados para coletar
- Atividades principais para monitorar e garantir uma descoberta de processo precisa
- Orientações para extração de dados do ServiceNow
Atributos da Gestão de Mudanças
| Nome | Descrição | ||
|---|---|---|---|
|
ID da Requisição de Mudança
ChangeRequestNumber
|
O identificador exclusivo da mudança, servindo como ID principal para agrupar todos os eventos relacionados. | ||
|
Descrição
O ID da Mudança é a base da análise do processo. É um número exclusivo atribuído a cada solicitação, como 'CHG0030001', que vincula todas as atividades e tarefas. No Process Mining, este atributo reconstrói a jornada completa de cada mudança. Permite rastrear o ciclo desde a criação até o fechamento, oferecendo uma visão coerente do progresso. Agrupar por este ID é essencial para calcular tempos de ciclo, identificar loops de retrabalho e entender as variantes do processo.
Por que é importante
Este ID é essencial para rastrear todo o ciclo da mudança, permitindo analisar o fluxo, a duração e a conformidade de cada solicitação.
Onde obter
Tabela ServiceNow: change_request, Campo: number
Exemplos
CHG0030001CHG0030045CHG0030112
|
|||
|
Tempo do Evento
EventTime
|
O timestamp preciso de quando a atividade ou evento ocorreu. | ||
|
Descrição
O Event Time registra a data e hora exatas de cada atividade ou mudança de status. Esse timestamp é essencial para ordenar os eventos e realizar análises de duração. No Process Mining, este atributo permite calcular tempos de ciclo, execução e espera entre etapas. É vital para dashboards de desempenho, como 'Tempo de Ciclo de Aprovação' e 'Fluxo Ponta a Ponta'. Timestamps precisos são a base para detectar atrasos e medir a eficiência do processo frente aos SLAs.
Por que é importante
Este timestamp é crucial para ordenar os eventos e calcular métricas de tempo, como tempos de ciclo e adesão ao SLA.
Onde obter
Tabela ServiceNow: sys_audit, Campo: sys_created_on. Fornece o timestamp de cada alteração registrada.
Exemplos
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
|
|||
|
Nome da Atividade
ActivityName
|
O nome de um evento ou tarefa específica ocorrida no processo de gestão de mudanças. | ||
|
Descrição
O Nome da Atividade descreve uma etapa ou mudança de status no ciclo da mudança. Exemplos: 'Mudança aguardando avaliação', 'Aprovação solicitada' e 'Mudança implementada'. Elas formam os nós do mapa do processo. Analisar essas atividades permite examinar detalhadamente o fluxo. Rastreando a sequência e frequência, a organização identifica caminhos comuns, desvios e gargalos onde as mudanças param. Isso é fundamental para visualizar o processo e calcular métricas como tempos de transição.
Por que é importante
Forma a espinha dorsal do mapa do processo, permitindo visualizar o fluxo, identificar gargalos e analisar desvios.
Onde obter
Derivado de mudanças no campo 'state' ou outros campos de status na tabela 'change_request', geralmente capturados via 'sys_audit'.
Exemplos
Mudança AprovadaImplementação IniciadaMudança FechadaMudança Cancelada
|
|||
|
End Time
EndTime
|
O timestamp de conclusão da atividade. Geralmente deriva do início da atividade seguinte. | ||
|
Descrição
O Horário de Término marca a conclusão de uma atividade. Como sistemas costumam logar apenas o início, o fim é frequentemente inferido pelo início da atividade seguinte no mesmo caso. Essencial para calcular o tempo de processamento. Entender a duração de cada etapa é fundamental para achar gargalos e ineficiências. Para a última atividade de um caso, o Término é igual ao Início.
Por que é importante
Permite calcular o tempo de execução de cada atividade, algo crucial para localizar gargalos e medir a duração de etapas específicas.
Onde obter
Calculado geralmente durante a transformação de dados, usando o StartTime do próximo evento do mesmo CaseId.
Exemplos
2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
|
|||
|
Estado da Mudança
ChangeState
|
O estado atual ou histórico da mudança, como 'Assess', 'Authorize', 'Implement' ou 'Closed'. | ||
|
Descrição
O atributo Estado da Mudança representa o status em um dado momento, resumindo onde ela está no ciclo de vida. Diferente da Atividade (evento), o Estado é a condição resultante. Na análise, o Estado categoriza casos e resultados. É fundamental para filtros, permitindo analisar apenas mudanças 'Fechadas' ou investigar por que muitas travam em 'Authorize'. Suporta KPIs como a Taxa de Falha em Mudanças quando existe um estado de 'Falha'.
Por que é importante
Oferece um panorama do status da mudança, permitindo analisar resultados, filtrar casos e identificar mudanças travadas.
Onde obter
Tabela ServiceNow: change_request, Campo: state
Exemplos
AvaliaçãoAutorizaçãoAgendadoImplementarRevisãoEncerradoCancelado
|
|||
|
Grupo de atribuição
AssignmentGroup
|
A equipe ou grupo responsável pela mudança. | ||
|
Descrição
O Grupo de Atribuição indica qual equipe é responsável pela mudança no momento, como 'Aprovação CAB' ou 'Administradores de Banco de Dados'. É uma dimensão crítica para analisar o desempenho entre áreas. Serve para medir a eficiência das equipes, identificar gargalos em grupos específicos e analisar handoffs. Dashboards como 'Eficiência de Handoff entre Funções' dependem desses dados para localizar atrasos causados por dependências entre equipes.
Por que é importante
Permite analisar a performance por equipe, destacando gargalos específicos e medindo a eficiência das passagens de bastão entre áreas.
Onde obter
Tabela ServiceNow: change_request, Campo: assignment_group
Exemplos
Aprovação do CABEquipe de RedeSuporte de ServidorAdministradores de Banco de Dados
|
|||
|
Item de Configuração
ConfigurationItem
|
O componente de TI, serviço ou sistema específico que é alvo da mudança. | ||
|
Descrição
O Item de Configuração (CI) é o ativo da CMDB afetado pela mudança, como um servidor, software ou serviço de negócio. Este atributo traz contexto crítico. No Process Mining, permite segmentar a análise pelo tipo de ativo. Por exemplo, o dashboard de 'Análise de Duração de Testes' usa isso para comparar tempos entre sistemas, ajudando a identificar quais CIs estão ligados a ciclos de teste mais longos.
Por que é importante
Oferece contexto de negócio essencial, permitindo filtrar análises por aplicação ou serviço para identificar problemas em componentes específicos.
Onde obter
Tabela 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 para a mudança, como 'Alto', 'Moderado' ou 'Baixo'. | ||
|
Descrição
O Nível de Risco resulta da avaliação da mudança. Ele quantifica potenciais consequências negativas, ajudando a definir o rigor da aprovação. Este atributo é central no dashboard 'Padronização da Avaliação de Risco', verificando a consistência das notas. Analisar o fluxo por risco também revela se mudanças perigosas seguem caminhos de aprovação mais rígidos, o que é uma checagem vital de conformidade.
Por que é importante
Essencial para auditorias de conformidade, garantindo que mudanças de alto risco recebam a devida atenção e sigam fluxos mais rigorosos.
Onde obter
Tabela ServiceNow: change_request, Campo: risk
Exemplos
AltoModeradoBaixo
|
|||
|
Prioridade
Priority
|
O nível de prioridade da mudança, determinado pelo impacto e urgência. | ||
|
Descrição
A Prioridade indica a importância de uma mudança e determina a ordem de tratamento. Geralmente deriva do impacto e urgência, com valores como 'Crítica', 'Alta', 'Moderada' e 'Baixa'. Analisar por prioridade é essencial para garantir que mudanças críticas sejam processadas primeiro. Isso alimenta o dashboard de 'Desempenho de Mudanças Críticas', permitindo rastrear tempos de ciclo e taxas de falha para os casos mais importantes. Desvios onde mudanças de baixa prioridade andam mais rápido que as críticas indicam problemas na alocação de recursos.
Por que é importante
Essencial para avaliar se os recursos estão alocados nas mudanças mais críticas e para monitorar seu desempenho separadamente.
Onde obter
Tabela ServiceNow: change_request, Campo: priority
Exemplos
1 - Crítico2 - Alto3 - Moderada4 - Baixo
|
|||
|
Tipo de Altera00o
ChangeType
|
A classificação da mudança, como 'Standard', 'Normal' ou 'Emergency'. | ||
|
Descrição
O Tipo de Mudança categoriza a requisição conforme sua natureza, risco e fluxo de aprovação. Mudanças Padrão são pré-aprovadas, Mudanças Normais seguem o fluxo completo e Mudanças de Emergência usam um caminho acelerado. Esta é uma dimensão fundamental para a análise, já que cada tipo possui um modelo de processo legítimo e distinto. Comparar o desempenho entre mudanças Normais e de Emergência revela insights sobre adesão ao processo e eficiência. Também é usado em dashboards como 'Padronização de Avaliação de Risco' para garantir tratamento consistente a mudanças similares.
Por que é importante
Permite segmentar a análise, já que diferentes tipos de mudança seguem fluxos distintos e têm expectativas de desempenho específicas.
Onde obter
Tabela ServiceNow: change_request, Campo: type
Exemplos
PadrãoNormalEmergência
|
|||
|
Código de Encerramento
CloseCode
|
Um código que indica o resultado do fechamento da mudança, como 'Sucesso' ou 'Insucesso'. | ||
|
Descrição
O Código de Fechamento dá o parecer final da mudança, registrando se foi bem-sucedida, se teve problemas ou se sofreu rollback. Este atributo alimenta o KPI 'Taxa de Falha em Mudanças'. Analisando a distribuição desses códigos, a empresa quantifica o sucesso de suas iniciativas. Filtrar o mapa do processo por códigos 'sem sucesso' é uma técnica poderosa para análise de causa raiz, revelando padrões que levam à falha.
Por que é importante
Mede diretamente o resultado de uma mudança, fornecendo os dados necessários para calcular a taxa de falha e analisar suas causas raiz.
Onde obter
Tabela ServiceNow: change_request, Campo: close_code
Exemplos
Bem-sucedidaBem-sucedida com ProblemasSem Sucesso / Rolled Back
|
|||
|
É Retrabalho
IsRework
|
Um sinalizador booleano verdadeiro se uma atividade representa a repetição de uma etapa anterior no mesmo caso. | ||
|
Descrição
Identifica atividades de retrabalho. Isso ocorre quando o processo volta a uma etapa já concluída, como uma mudança rejeitada após aprovação. Este campo é crucial para quantificar ineficiências. Alimenta o KPI 'Taxa de Retrabalho' e dashboards de análise de falhas. Filtrando por 'É Retrabalho', analistas isolam as causas (como avaliações incompletas) para agir e reduzir desperdícios.
Por que é importante
Quantifica a ineficiência ao sinalizar repetições, ajudando a identificar e resolver causas raiz de loops e desperdício de esforço no processo.
Onde obter
Calculado na transformação de dados ao detectar se a mesma atividade (ou uma anterior no fluxo padrão) já ocorreu para aquele CaseId.
Exemplos
verdadeirofalse
|
|||
|
Estado do SLA
SlaState
|
O status da mudança em relação ao SLA, como 'No Prazo', 'Em Risco' ou 'Violado'. | ||
|
Descrição
O Estado do SLA indica se a mudança está progredindo dentro dos prazos definidos. Este status pode ser monitorado em cada etapa. Este atributo é essencial para monitorar a conformidade com acordos de nível de serviço. É a fonte principal para o dashboard 'Visão Geral de Desempenho de SLA' e para o KPI 'Taxa de Adesão ao SLA'. Analisar onde e por que os SLAs são violados permite tratar atrasos sistêmicos e melhorar a previsibilidade da entrega.
Por que é importante
Fornece uma medida direta de desempenho em relação aos prazos, permitindo o monitoramento proativo e análise de violações de SLA para melhorar a entrega.
Onde obter
Pode vir da tabela 'task_sla' do ServiceNow ou ser calculado com base nos campos de data de vencimento.
Exemplos
No PrazoEm RiscoViolado
|
|||
|
Impacto
Impact
|
O efeito potencial da mudança nas operações, avaliado em escalas como Alto, Médio ou Baixo. | ||
|
Descrição
O Impacto mede o efeito potencial no negócio caso a solicitação de mudança não seja tratada corretamente. É um dado essencial, junto com a Urgência, para determinar a Prioridade global da mudança. Analisar pelo Impacto ajuda a garantir que mudanças em serviços críticos sejam gerenciadas com o devido cuidado. É usado no dashboard 'Desempenho de Mudanças Críticas' para monitorar mudanças de alto impacto. Também serve 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 é importante
Ajuda a priorizar mudanças com base em seu impacto potencial nos negócios e serve para validar se mudanças de alto impacto são gerenciadas com a diligência adequada.
Onde obter
Tabela ServiceNow: change_request, Campo: impact
Exemplos
1 - Alto2 - Médio3 - Baixo
|
|||
|
Sistema de Origem
SourceSystem
|
O sistema de onde os dados vieram, geralmente 'ServiceNow'. | ||
|
Descrição
Identifica a origem dos dados do processo. Embora neste caso seja o ServiceNow, é crucial para governança e fusão de dados de múltiplos sistemas. Garante uma linhagem clara e ajuda a validar a fonte. Para empresas com várias ferramentas de ITSM, permite filtrar e comparar processos entre diferentes plataformas.
Por que é importante
Garante uma linhagem de dados clara, documentando a origem dos dados do processo, o que é vital para governança e análises multissistema.
Onde obter
Geralmente é um valor estático adicionado durante o processo de extração e transformação (ETL).
Exemplos
ServiceNowServiceNow_PRODSNOW_ITSM
|
|||
|
Tempo de Ciclo
CycleTime
|
O tempo total decorrido da criação ao fechamento da mudança. | ||
|
Descrição
O Tempo de Ciclo é uma métrica que mede a duração total da jornada de uma mudança. É calculado pela diferença entre o timestamp do primeiro evento e o do último registro da requisição. Este KPI é fundamental para medir a velocidade do processo. Ele alimenta o dashboard 'Fluxo de Processo de Mudança de Ponta a Ponta', oferecendo uma visão macro do desempenho. Analisar as tendências de tempo de ciclo e compará-las por Tipo de Mudança ou Prioridade ajuda a identificar oportunidades estratégicas de melhoria.
Por que é importante
Mede a duração de ponta a ponta do processo de mudança, sendo um indicador-chave da velocidade e eficiência geral.
Onde obter
Calculado no nível do caso durante a análise, subtraindo o StartTime mínimo do StartTime máximo para cada CaseId.
Exemplos
60480012096002592000
|
|||
|
Tempo de Processamento
ProcessingTime
|
A duração de uma única atividade, calculada pela diferença entre o Fim e o Início. | ||
|
Descrição
O Tempo de Processamento, ou duração da atividade, mede o tempo gasto trabalhando ativamente em uma tarefa. É o resultado do Fim menos o Início da atividade. Essa métrica é fundamental para análise de desempenho. Ela permite identificar as etapas mais lentas, que são os alvos principais de otimização. Dashboards que analisam a duração de testes ou ciclo de avaliação de risco baseiam-se diretamente nesta métrica.
Por que é importante
Mede a duração das atividades individuais, permitindo identificar as etapas mais demoradas que são candidatas ideais para otimização.
Onde obter
Calculado durante a transformação de dados: EndTime - StartTime.
Exemplos
259200360086400
|
|||
|
Última Atualização de Dados
LastDataUpdate
|
O timestamp que indica quando os dados para este registo foram atualizados pela última vez a partir do sistema de origem. | ||
|
Descrição
Informa a data/hora da última extração. É um metadado crítico para entender a atualidade dos dados analisados. Analistas usam isso para confirmar que as informações são recentes, evitando que decisões operacionais sejam tomadas com base em dados obsoletos.
Por que é importante
Indica a atualização dos dados, garantindo que as análises e dashboards se baseiem em informações recentes e relevantes.
Onde obter
Campo de metadados gerado no processo de ETL, indicando o horário da extração dos dados.
Exemplos
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Urgência
Urgency
|
A velocidade com que a mudança precisa ser resolvida, avaliada como Alta, Média ou Baixa. | ||
|
Descrição
A Urgência define a rapidez necessária para a mudança, refletindo a sensibilidade temporal sob a ótica do negócio. Junto com o Impacto, define a Prioridade. Embora a Prioridade seja o foco da análise, a Urgência dá contexto. Ela serve para investigar por que certos casos são urgentes e se o processo os atende sem perder estabilidade. Ajuda a entender se a organização vive em modo reativo e urgente demais.
Por que é importante
Dá contexto sobre a sensibilidade temporal, ajudando a analisar se o processo trata solicitações urgentes de forma eficaz.
Onde obter
Tabela ServiceNow: change_request, Campo: urgency
Exemplos
1 - Alto2 - Médio3 - Baixo
|
|||
|
Usuário Atribuído
AssignedToUser
|
O usuário individual responsável pela mudança em um momento específico. | ||
|
Descrição
Identifica a pessoa atribuída à mudança. Pode mudar várias vezes conforme o caso avança entre etapas e equipes. Analisar por usuário ajuda a entender a carga de trabalho, o desempenho e necessidades de treinamento. Também é vital para analisar handoffs e a eficiência da passagem de bastão.
Por que é importante
Auxilia no acompanhamento da carga de trabalho e do desempenho individual, sendo crucial para analisar atrasos de handoff entre diferentes recursos.
Onde obter
Tabela ServiceNow: change_request, Campo: assigned_to
Exemplos
Beth AnglinDavid LooAbel Tuter
|
|||
Atividades da Gestão de Mudanças
| Atividade | Descrição | ||
|---|---|---|---|
|
Mudança Agendada
|
A mudança aprovada recebeu datas planejadas de início e fim e agora está oficialmente no calendário. Isso é inferido quando o estado da solicitação muda para 'Scheduled'. | ||
|
Por que é importante
Separa as fases de planejamento e aprovação da implementação ativa. O tempo neste estado indica atrasos entre a aprovação e o início do trabalho real.
Onde obter
Inferido de uma mudança no campo 'state' na tabela change_request para 'Scheduled'. O timestamp é capturado da entrada correspondente no log de auditoria.
Captura
Rastreie mudanças do campo state para 'Scheduled' no histórico de auditoria da tabela change_request.
Tipo de evento
inferred
|
|||
|
Mudança Aprovada
|
A mudança recebeu todas as autorizações para seguir para agendamento e implementação. É um marco capturado quando a aprovação final é concedida e o campo 'approval' muda para 'approved'. | ||
|
Por que é importante
Marco que encerra a fase de aprovação. Essencial para medir tempos de ciclo e achar gargalos na tomada de decisão.
Onde obter
Inferido pela mudança do campo 'approval' na tabela change_request para 'approved'. O timestamp é obtido do histórico de auditoria desta mudança.
Captura
Captura o registro de data e hora de quando o campo 'approval' muda para 'approved'.
Tipo de evento
inferred
|
|||
|
Mudança Cancelada
|
A mudança foi retirada ou abortada antes da conclusão. É um estado final alternativo capturado quando o estado é 'Canceled'. | ||
|
Por que é importante
Analisar mudanças canceladas pode revelar ineficiências, como requisições criadas desnecessariamente ou que ficaram travadas por tanto tempo que se tornaram obsoletas.
Onde obter
Inferido pela definição do campo 'state' na tabela change_request como 'Canceled'. O timestamp é capturado do log de auditoria para esta mudança de estado.
Captura
Captura o registro de data e hora de quando o campo 'state' é atualizado para 'Canceled'.
Tipo de evento
inferred
|
|||
|
Mudança Fechada
|
A mudança foi concluída com sucesso e revisada. É o ponto final de sucesso, capturado quando o estado muda para 'Closed'. | ||
|
Por que é importante
Marca a conclusão bem-sucedida do ciclo da mudança. É o evento final para medir a duração ponta a ponta e a adesão ao SLA.
Onde obter
Inferido pela definição do campo 'state' na tabela change_request como 'Closed'. O timestamp é extraído do histórico de auditoria para esta mudança de estado final.
Captura
Captura o registro de data e hora de quando o campo 'state' é atualizado para 'Closed'.
Tipo de evento
inferred
|
|||
|
Mudança Implementada
|
O trabalho de implementação terminou e a mudança está pronta para revisão ou testes. Inferido quando o estado muda de 'Implement' para 'Review'. | ||
|
Por que é importante
Marco crítico que encerra a fase de implementação. Evento essencial para calcular a 'Taxa de Falha' e a 'Taxa de Retrabalho'.
Onde obter
Inferido de uma transição de estado saindo de 'Implement' para um estado posterior como 'Review'. O timestamp é capturado do histórico de auditoria do campo 'state' na tabela change_request.
Captura
Identifique quando o campo 'state' muda de 'Implement' para 'Review'.
Tipo de evento
inferred
|
|||
|
Requisição de Mudança Criada
|
Marca a criação de um novo registro de mudança. É o início oficial do processo, capturado quando uma nova entrada surge na tabela change_request. | ||
|
Por que é importante
Evento de início principal. Analisar o tempo desta atividade até as outras revela o lead time total e ajuda a achar atrasos logo no começo.
Onde obter
Corresponde ao timestamp de criação do registro (sys_created_on) na tabela change_request do ServiceNow.
Captura
Use o timestamp 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. É um marco crucial antes da aprovação e geralmente é inferido quando a mudança sai de 'Assess' para 'Authorize' ou 'Awaiting Approval'. | ||
|
Por que é importante
Rastrear a duração da fase de avaliação é vital para o KPI de 'Ciclo Médio de Avaliação de Risco', ajudando a padronizar o processo e achar lentidões.
Onde obter
Inferido pela transição do campo 'state' na tabela change_request de 'Assess' para 'Authorize'. O timestamp do evento é capturado do log de auditoria desta mudança.
Captura
Identifique quando o campo 'state' muda de 'Assess' para um estado subsequente como 'Authorize'.
Tipo de evento
inferred
|
|||
|
Aprovação Solicitada
|
Indica que a mudança foi formalmente enviada para aprovação (gestor ou CAB). Capturado quando o status de aprovação vira 'requested'. | ||
|
Por que é importante
Marca o início do ciclo de aprovação. Medir o tempo deste evento até 'Change Approved' calcula diretamente o KPI de 'Tempo Médio de Aprovação'.
Onde obter
Inferido pela mudança do campo 'approval' na tabela change_request para 'requested'. O timestamp é registrado a partir da tabela sys_audit para este campo.
Captura
Timestamp de quando o campo 'approval' na tabela change_request é definido como 'requested'.
Tipo de evento
inferred
|
|||
|
Implementação Iniciada
|
O trabalho de implementação da mudança começou efetivamente. Isso é registrado quando o status da solicitação de mudança é atualizado para 'Implement', sinalizando a transição do planejamento para a execução. | ||
|
Por que é importante
Início do trabalho prático de implementação. Ponto de partida para medir a 'Duração Média de Implementação' e a eficiência da equipe.
Onde obter
Inferido pela mudança do campo 'state' na tabela change_request para 'Implement'. O timestamp é extraído do log de auditoria para esta transição de estado.
Captura
Captura o registro de data e hora da mudança de estado para 'Implement' no histórico de auditoria da change_request.
Tipo de evento
inferred
|
|||
|
Mudança em Avaliação
|
A mudança foi enviada e aguarda avaliação técnica e de negócio. Geralmente inferido quando o estado muda para 'Assess', indicando o fim da fase de rascunho. | ||
|
Por que é importante
Esta atividade ajuda a medir o tempo de handoff inicial do solicitante para a equipe de avaliação. Atrasos aqui podem indicar problemas na qualidade dos dados ou falta de avaliadores.
Onde obter
Inferido de uma mudança no campo 'state' na tabela change_request, geralmente para 'Assess'. O timestamp é extraído do histórico de auditoria (sys_audit) para esta alteração.
Captura
Rastreie mudanças do campo state para 'Assess' no histórico de auditoria da tabela change_request.
Tipo de evento
inferred
|
|||
|
Mudança Reaberta
|
A mudança retornou a um estado anterior, como 'Implement' ou 'Assess', após ter avançado. Este evento é inferido por uma transição não linear e significa retrabalho. | ||
|
Por que é importante
Crucial para identificar loops e calcular a 'Taxa de Retrabalho'. Reaberturas frequentes indicam problemas na qualidade da implementação, nos testes ou no planejamento.
Onde obter
Inferido pela análise da sequência de mudanças de estado no histórico de auditoria da change_request. Uma transição de um estado posterior (ex: 'Review') para um anterior (ex: 'Implement') indica uma reabertura.
Captura
Detecta uma transição não sequencial para um estado anterior no histórico do campo 'state'.
Tipo de evento
inferred
|
|||
|
Mudança Rejeitada
|
A mudança foi negada por um aprovador ou pelo CAB. Representa um estado final, a menos que seja retrabalhada. Capturado quando o campo 'approval' é definido como 'rejected'. | ||
|
Por que é importante
Rastrear rejeições ajuda a identificar causas comuns de negativa, como falta de dados. Isso ajuda a melhorar a qualidade das próximas solicitações.
Onde obter
Inferido pela mudança do campo 'approval' na tabela change_request para 'rejected'. O timestamp é capturado do histórico de auditoria.
Captura
Captura o registro de data e hora de quando o campo 'approval' muda para 'rejected'.
Tipo de evento
inferred
|
|||
|
Revisão em Andamento
|
Uma revisão pós-implementação (PIR) está sendo feita para avaliar o sucesso da mudança. Isso é registrado quando o estado da requisição muda para 'Review'. | ||
|
Por que é importante
Analisar a duração da fase de revisão ajuda a identificar atrasos na validação do sucesso das mudanças e aponta casos onde esta etapa obrigatória foi ignorada.
Onde obter
Inferido pela mudança do campo 'state' na tabela change_request para 'Review'. O timestamp é obtido do log de auditoria para esta alteração de estado.
Captura
Captura o registro de data e hora da mudança de estado para 'Review' no histórico de auditoria da change_request.
Tipo de evento
inferred
|
|||