Seu Template de Dados de Gestão de Mudanças

Este atributo registra o nome da atividade ocorrida em um momento específico para uma solicitação de mudança. Essas atividades são derivadas de transições de status, etapas de fluxo de trabalho ou entradas de log específicas no Jira, como 'Mudança Enviada para Revisão' ou 'Implementação Iniciada'.

Analisar a sequência e a frequência dessas atividades é o núcleo do Process Mining. Ele permite a descoberta dos fluxos reais do processo, a identificação de gargalos entre as etapas e a análise das variantes do processo em relação ao procedimento operacional padrão.

Define as etapas do processo, sendo essencial para gerar mapas, analisar variantes e identificar gargalos.

Normalmente derivado do histórico do ticket do Jira, especificamente das transições de status ou atualizações em campos personalizados que representam marcos do processo.

O Horário de Início, ou timestamp do evento, marca a data e hora precisas em que uma atividade foi registrada para uma solicitação de mudança. Cada atividade no event log, da criação ao fechamento, possui um timestamp associado.

Este atributo é crítico para todas as análises baseadas em tempo no Process Mining. Ele é usado para calcular tempos de ciclo, durações entre atividades, tempos de espera e para determinar a sequência dos eventos. Forma a base para o monitoramento de desempenho, cálculos de adesão ao SLA e identificação de gargalos.

Este registro de data e hora (timestamp) é a base para todas as análises de desempenho e duração, permitindo o cálculo dos tempos de ciclo e a identificação de atrasos.

O timestamp de cada entrada no log de histórico do ticket do Jira. Para o evento de criação, este é o campo created.

O ID da Solicitação de Mudança é a chave primária que identifica exclusivamente cada iniciativa de mudança no Jira Service Management. Ele serve como o identificador de caso para o Process Mining, vinculando todos os eventos, mudanças de status e atualizações em uma visão coesa do processo de ponta a ponta.

Na análise, esse ID permite a reconstrução do ciclo de vida completo de cada mudança. Ele é essencial para rastrear mudanças individuais em vários estágios, como avaliação de risco, aprovação, implementação e revisão. Todas as métricas, KPIs e dashboards dependem deste atributo para agregar e correlacionar corretamente os dados de eventos de uma mudança específica.

Este é o identificador fundamental do caso, permitindo rastrear toda a jornada de uma solicitação de mudança e analisar seu desempenho.

Esta é a chave padrão do ticket do Jira (Issue Key), encontrada no campo key para tickets do tipo solicitação de mudança.

Este atributo especifica o sistema de origem de onde vieram os dados do processo. Neste contexto, o valor é consistentemente 'Jira Service Management'.

Em um contexto empresarial mais amplo, onde os dados podem ser mesclados de vários sistemas, este campo é crucial para a linhagem de dados, resolução de problemas e compreensão das variações de processo específicas de cada sistema. Ele garante clareza sobre a origem dos dados que estão sendo analisados.

Fornece uma procedência de dados clara, essencial ao combinar dados de vários sistemas ou para fins de auditoria.

Este é um valor estático adicionado durante a extração para identificar a origem do conjunto de dados.

Este atributo registra a data e a hora em que os dados foram extraídos pela última vez do sistema de origem. Ele representa o quão recentes são os dados dentro da ferramenta de Process Mining.

Analisar este atributo ajuda os usuários a entender quão atuais são os dados do processo, o que é importante para dashboards operacionais e monitoramento em tempo real. Ele fornece contexto para a análise, garantindo que as decisões não sejam tomadas com base em dados obsoletos.

Indica a atualidade dos dados, garantindo que as análises sejam relevantes e baseadas em informações recentes.

Este é um campo de metadados preenchido pela ferramenta de extração de dados no momento da coleta dos dados.

Este atributo armazena a data em que se espera que a solicitação de mudança seja concluída para cumprir seu SLA. É o parâmetro de referência em relação ao qual o tempo de conclusão real é medido.

Esta data é fundamental para monitorar o desempenho em relação aos compromissos assumidos. É a base para o dashboard 'Monitor de Desempenho de SLA de Mudança' e para o KPI 'Taxa de Adesão ao SLA de Mudança'. Ao comparar a data de resolução real com esta meta, as organizações podem medir sua eficácia na entrega de serviços.

Este é o ponto de dados principal para calcular a adesão ao SLA e identificar quais mudanças correm o risco de descumprir seus prazos.

Este é frequentemente o campo duedate no Jira ou um valor de uma métrica de SLA configurada no Jira Service Management.

O Nível de Risco é uma avaliação obrigatória na maioria dos processos de gestão de mudanças, categorizando o potencial impacto negativo de uma mudança. O nível é determinado durante a fase de avaliação de risco e muitas vezes influencia o fluxo de aprovação necessário.

No Process Mining, este atributo é crítico para análises baseadas em risco. Ele alimenta o dashboard 'Precisão e Resultado da Avaliação de Risco' ao correlacionar o risco inicial com o resultado real. É também a dimensão principal para o KPI 'Taxa de Falha de Mudança por Nível de Risco', ajudando a avaliar se as mudanças de alto risco estão sendo gerenciadas de forma eficaz.

Permite analisar se os controles de processo e fluxos de aprovação são eficazes para diferentes perfis de risco, ajudando a correlacionar risco com taxas de falha.

Este é normalmente um campo personalizado no Jira Service Management. Nomes comuns incluem 'Nível de Risco' ou 'Impacto'.

O campo Prioridade ajuda as equipes a determinar a ordem de atendimento das solicitações de mudança. Ele reflete uma combinação de impacto e urgência, orientando o agendamento e a alocação de recursos.

Analisar a prioridade permite comparações de desempenho entre mudanças de alta e baixa prioridade. Por exemplo, é possível verificar se as mudanças de alta prioridade realmente têm ciclos mais curtos ou se ficam presas nos mesmos gargalos que as outras. Isso é valioso para otimizar o foco dos recursos e atender às expectativas do negócio.

Permite analisar o desempenho do processo com base na prioridade de negócio, garantindo que mudanças críticas sejam agilizadas.

Este é o campo padrão priority (Prioridade) em um ticket do Jira.

O Responsável (Assignee) é o usuário individual encarregado da etapa ou atividade atual no fluxo de gestão de mudanças. O responsável pode mudar várias vezes ao longo do ciclo de vida de uma solicitação de mudança à medida que ela transita entre diferentes pessoas e equipes.

Este atributo é usado para analisar a distribuição da carga de trabalho, identificar gargalos específicos por usuário e entender a alocação de recursos. O dashboard 'Carga de Trabalho da Equipe de Mudança' depende desses dados para mostrar quais indivíduos ou grupos estão lidando com a maior quantidade de atividades.

Isso ajuda a analisar o desempenho dos recursos e a distribuição da carga de trabalho, identificando gargalos individuais ou de equipe.

Este é o campo padrão assignee (Responsável) em um ticket do Jira.

Este atributo indica o status da solicitação de mudança, como 'Aguardando Aprovação', 'Em Andamento' ou 'Fechado'. O campo de status no Jira é fundamental para o seu motor de fluxo de trabalho, e as alterações nesse campo são os principais motores do fluxo do processo.

Analisar o status permite acompanhar o progresso das mudanças ativas e entender os resultados das concluídas, por exemplo, 'Fechado - Com Sucesso' versus 'Fechado - Com Falha'. É fundamental para construir dashboards de vazão (throughput) e analisar loops de refação onde um status reverte para um estado anterior.

Oferece uma visão clara do progresso e resultado final, sendo crucial para análises de vazão (throughput) e retrabalho.

Este é o campo padrão status de um ticket do Jira. Os status disponíveis são definidos na configuração do fluxo de trabalho do projeto.

Este é um atributo calculado que compara a data de resolução real de uma solicitação de mudança com sua 'Data de Conclusão Prevista'. O resultado é um status simples, como 'Cumprido' ou 'Violado'.

Isso fornece um indicador claro e imediato de desempenho para o dashboard 'Monitor de Desempenho de SLA de Mudança'. Simplifica a criação de KPIs como 'Taxa de Adesão ao SLA de Mudança' ao pré-calcular o status para cada caso. Isso permite filtrar e agregar facilmente os dados para ver quais tipos de mudanças, equipes ou serviços estão mais frequentemente associados a violações de SLA.

Fornece um resultado binário claro para o desempenho do SLA em cada caso, simplificando o relatório e a análise da conformidade com o SLA.

Calculado comparando o timestamp da atividade final 'Change Closed' com o atributo 'TargetCompletionDate'.

Esta é uma métrica calculada que mede o tempo decorrido entre a atividade 'Mudança Enviada para Revisão' e a atividade 'Solicitação de Mudança Aprovada'. Ela isola a fase de aprovação do ciclo de vida da mudança para uma análise focada.

Esta métrica apoia diretamente o dashboard 'Tempo do Ciclo de Aprovação de Mudanças' e o KPI correspondente. É usada para identificar gargalos no processo de aprovação, seja em grupos de aprovação específicos, tipos de mudança ou níveis de risco. Reduzir esse tempo pode acelerar significativamente o processo geral de entrega de mudanças.

Mede diretamente a eficiência da fase de aprovação, ajudando a identificar e resolver atrasos na autorização das mudanças.

Calculado subtraindo o timestamp de 'Change Submitted For Review' do timestamp de 'Change Request Approved' para um ID de mudança específico.

O Tipo de Mudança categoriza a solicitação de mudança com base em sua natureza, urgência e impacto. Os tipos comuns incluem 'Padrão' para mudanças de baixo risco pré-aprovadas, 'Normal' para mudanças rotineiras que exigem aprovação total e 'Emergencial' para mudanças urgentes para corrigir incidentes.

Este atributo é essencial para a análise do processo, pois diferentes tipos de mudança costumam seguir caminhos distintos e ter SLAs diferentes. Ele é usado para calcular o KPI 'Taxa de Mudanças Emergenciais' e para filtrar dashboards para comparar o desempenho e o risco associados a cada tipo.

Permite segmentar o processo para analisar fluxos diferentes, como mudanças padrão vs. emergenciais, que possuem riscos e expectativas distintos.

Este é normalmente um campo personalizado em projetos do Jira Service Management. O nome do campo pode variar, mas frequentemente é chamado de 'Tipo de Mudança'.

Este atributo calculado identifica solicitações de mudança que foram enviadas de volta a um estágio anterior para modificações, por exemplo, passando de 'Aguardando Aprovação' de volta para 'Planejamento'. Isso sinaliza que o envio inicial estava incompleto, incorreto ou não atendia aos critérios necessários.

Esta sinalização é a base para o KPI 'Taxa de Refação de Mudança' e para o dashboard 'Análise de Refação e Rejeição de Mudança'. Ao sinalizar os casos de refação, os analistas podem filtrá-los facilmente e investigar as causas raiz, como planejamento inicial deficiente, requisitos pouco claros ou avaliação de risco insuficiente.

Evidencia a ineficiência sinalizando casos com trabalho extra não planejado, permitindo analisar as causas do retrabalho.

Calculado analisando a sequência de atividades no event log. Um retrabalho é detectado quando uma atividade de um estágio avançado é seguida por uma de um estágio anterior.

Este atributo identifica a equipe designada para trabalhar na mudança. Embora o Jira tenha um campo 'Responsável' para indivíduos, um campo 'Equipe' é frequentemente usado para atribuir trabalho a um grupo funcional, como 'Operações de Rede' ou 'Administradores de Banco de Dados'.

Isso é crucial para o dashboard 'Carga de Trabalho da Equipe de Mudança'. Ele permite a análise de desempenho e gargalos em nível de equipe, em vez de apenas individual, o que geralmente é mais útil para o planejamento e gestão de recursos.

Facilita a análise de carga de trabalho e desempenho por equipe ou departamento, destacando gargalos sistêmicos.

Geralmente é um campo personalizado no Jira, pois não há um campo padrão 'Equipe'. Pode ser do tipo 'Seletor de Grupo' ou uma lista de seleção simples.

Este atributo captura o motivo subjacente da mudança, como 'Implementação de Novo Recurso', 'Correção de Bug' ou 'Upgrade de Infraestrutura'. Ele fornece um contexto crucial além do resumo ou descrição.

Na análise, o motivo de uma mudança pode ser correlacionado com outras métricas, como tempo de ciclo, taxa de falha e nível de risco. Isso ajuda a responder perguntas como: 'As mudanças relacionadas a correções de bugs são aprovadas mais rapidamente do que as implementações de novos recursos?' ou 'Os upgrades de infraestrutura têm uma taxa de falha mais alta?'.

Fornece contexto de negócios que permite uma análise mais profunda, correlacionando o propósito de uma mudança com seu desempenho e resultado.

Este é normalmente um campo personalizado no Jira Service Management, muitas vezes uma lista de seleção ou campo de texto.

Este atributo indica se a mudança resultou em um desfecho negativo, como um incidente de produção. Isso geralmente envolve vincular o ticket de solicitação de mudança a um ou mais tickets de incidente no Jira.

Esses dados são essenciais para calcular os KPIs 'Taxa de Problemas Pós-Implementação' e 'Taxa de Falha de Mudança'. Ele fornece uma medida direta da qualidade da mudança e da eficácia dos processos de planejamento, teste e avaliação de risco. Analisar quais mudanças levam a problemas ajuda a refinar controles e evitar falhas futuras.

Mede a qualidade e o sucesso de uma mudança rastreando se ela causou problemas operacionais posteriores.

Isso é normalmente derivado da verificação de tickets vinculados no Jira, especificamente se um ticket de Mudança possui links do tipo 'é causado por' (is caused by) de tickets de Incidente.

O Relator (Reporter) é o indivíduo que criou o ticket de solicitação de mudança no Jira. Geralmente é o proprietário da mudança ou alguém que a inicia em nome de uma equipe.

Analisar o relator pode ajudar a identificar quais departamentos, equipes ou indivíduos estão iniciando mais mudanças. Pode ser usado para detectar tendências nas fontes de mudança e fornecer feedback ou treinamento a grupos que enviam solicitações de mudança incompletas ou de baixa qualidade com frequência.

Ajuda a identificar as origens das solicitações, permitindo melhorar a qualidade dos pedidos iniciais.

Este é o campo padrão reporter (Relator) em um ticket do Jira.

Quando uma solicitação de mudança é fechada, o campo Resolução fornece informações específicas sobre o resultado. Por exemplo, 'Concluído' indica sucesso, enquanto 'Não será feito' ou 'Duplicado' fornecem outros motivos de fechamento. Isso oferece mais contexto do que apenas o status 'Fechado'.

Este atributo é essencial para analisar as taxas de sucesso e falha das mudanças. Por exemplo, o KPI 'Taxa de Problemas Pós-Implementação' pode ser melhor compreendido ao filtrar por mudanças com uma resolução 'Falhou' ou 'Rollback'. Ele ajuda a distinguir mudanças implementadas com sucesso daquelas que foram canceladas ou rejeitadas após a aprovação.

Fornece contexto detalhado sobre o resultado final de uma mudança, o que é crucial para calcular com precisão as taxas de sucesso e falha.

Este é o campo padrão resolution no Jira, que geralmente é definido quando um ticket é movido para uma categoria de status 'Concluído'.

Este atributo vincula a solicitação de mudança a um serviço de negócio específico definido no Banco de Dados de Gerenciamento de Configuração (CMDB), como 'Serviço de E-mail' ou 'CRM do Cliente'. Este é um conceito-chave para entender o impacto de uma mudança no negócio.

Analisar mudanças por serviço de negócio ajuda a priorizar esforços e comunicar o impacto às partes interessadas. Permite visualizar quais serviços estão passando por mais mudanças, quais estão em maior risco e onde os incidentes relacionados a mudanças estão concentrados. Isso é vital para gerenciar mudanças técnicas sob uma perspectiva centrada no negócio.

Conecta mudanças técnicas ao impacto no negócio, permitindo priorização e análise de risco com base na criticidade do serviço afetado.

Este é frequentemente um campo personalizado no JSM, muitas vezes vinculado ao Jira Assets (antigo Insight) ou a outro CMDB.