Seu Template de dados de gestão de mudanças

Este atributo registra o nome da atividade realizada em um momento específico de uma solicitação de mudança. Essas atividades são derivadas de transições de status, etapas do Workflow ou entradas específicas de log no Jira, como 'Change Submitted For Review' ou 'Implementation Started'.

Analisar a sequência e a frequência dessas atividades é o núcleo do process mining. Isso permite descobrir os fluxos reais do processo, identificar gargalos entre as etapas e analisar variantes do processo em comparação com o procedimento operacional padrão.

Ele define as etapas do processo, o que é essencial para descobrir mapas de processo, analisar variantes e identificar gargalos.

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

A hora de início, ou timestamp do evento, marca a data e a hora exatas em que uma atividade foi registrada para uma solicitação de mudança. Cada atividade no Event Log, da criação ao encerramento, tem um timestamp associado.

Este atributo é essencial 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 de eventos. Também serve de base para o monitoramento de performance, os cálculos de cumprimento de SLA e a identificação de gargalos.

Este registro de data e hora é a base de toda análise de performance e duração, permitindo calcular tempos de ciclo e identificar atrasos.

O registro de data e hora de cada entrada no Event Log do histórico da issue no 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 funciona como o identificador do caso no process mining, conectando 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 reconstruir o ciclo de vida completo de cada mudança. Ele é essencial para acompanhar mudanças individuais em etapas como avaliação de risco, aprovação, implementação e revisão. Todas as métricas, KPIs e Dashboards dependem desse atributo para agregar e correlacionar corretamente os dados de eventos de uma mudança específica.

Este é o identificador fundamental do caso, tornando possível rastrear toda a jornada de uma solicitação de mudança e analisar sua performance.

Esta é a chave padrão da issue do Jira, encontrada no campo key das issues do tipo Change request.

Este atributo especifica o sistema de origem dos dados do processo. Neste contexto, o valor é sempre 'Jira Service Management'.

Em um contexto empresarial mais amplo, no qual os dados podem ser combinados a partir de vários sistemas, este campo é essencial para a linhagem dos dados, a solução de problemas e a compreensão das variações do processo específicas de cada sistema. Ele garante clareza sobre a origem dos dados analisados.

Fornece uma visão clara da procedência dos dados, algo essencial ao combinar dados de vários sistemas ou para fins de auditoria.

Este é um valor estático adicionado durante a extração dos dados 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 nível de atualização dos dados na ferramenta de Process Mining.

Analisar este atributo ajuda você a entender o quanto os dados do processo estão atualizados, algo 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 desatualizados.

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

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

Este atributo armazena a data até a qual a solicitação de mudança deve ser concluída para cumprir o SLA. Ele é a referência usada para medir o tempo real de conclusão.

Esta data é fundamental para monitorar a performance em relação aos compromissos assumidos. Ela é a base do Dashboard 'Monitor de performance do SLA de mudanças' e do KPI 'Taxa de cumprimento do SLA de mudanças'. Ao comparar a data real de resolução com essa meta, as organizações podem medir a eficácia da entrega de serviços.

Este é o principal dado usado para calcular o cumprimento do SLA e identificar quais mudanças correm risco de ultrapassar seus prazos.

Este geralmente é o campo duedate do 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 e categoriza o possível impacto negativo de uma mudança. O nível é determinado durante a etapa de avaliação de riscos e geralmente influencia o Workflow de aprovação necessário.

No Process Mining, este atributo é essencial para análises baseadas em risco. Ele dá suporte ao Dashboard 'Precisão e resultado da avaliação de riscos', correlacionando o risco inicial com o resultado real. Ele também é a principal dimensão do KPI 'Taxa de falha de mudanças 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 do processo e os Workflows de aprovação são eficazes para diferentes perfis de risco, além de ajudar a correlacionar o risco com as taxas de falha das mudanças.

Este geralmente é um campo personalizado no Jira Service Management. Os nomes comuns incluem 'Risk Level' ou 'Impact'.

O campo de prioridade ajuda as equipes a definir a ordem em que as solicitações de mudança devem ser tratadas. Ele reflete uma combinação de impacto e urgência e orienta o agendamento e a alocação de recursos.

Analisar a prioridade permite comparar a performance de mudanças de alta e baixa prioridade. Por exemplo, você pode verificar se as mudanças de alta prioridade realmente têm tempos de ciclo menores ou se ficam presas nos mesmos gargalos que as demais. Isso é valioso para otimizar o foco dos recursos e atender às expectativas do negócio.

Permite analisar a performance do processo com base na prioridade do negócio, garantindo que as mudanças críticas sejam aceleradas conforme o esperado.

Este é o campo padrão priority de uma issue do Jira.

O responsável é o usuário encarregado da etapa ou atividade atual no Workflow 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, conforme ela passa por diferentes pessoas e equipes.

Este atributo é usado para analisar a distribuição da carga de trabalho, identificar gargalos específicos de usuários e entender a alocação de recursos. O Dashboard 'Carga de trabalho das atividades da equipe de mudanças' usa esses dados para mostrar quais pessoas ou grupos estão executando mais atividades.

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

Este é o campo padrão assignee de uma issue do Jira.

Este atributo indica o status da solicitação de mudança, como 'Aguardando aprovação', 'Em andamento' ou 'Fechada'. O campo de status no Jira é fundamental para o mecanismo de Workflow, e as alterações nesse campo são os principais fatores que determinam o fluxo do processo.

Analisar o status permite acompanhar o progresso das mudanças ativas e entender os resultados das mudanças concluídas, por exemplo, 'Fechada - bem-sucedida' em comparação com 'Fechada - malsucedida'. Ele é essencial para criar Dashboards de throughput e analisar loops de retrabalho nos quais o status retorna a um estado anterior.

Ele oferece uma visão clara do progresso e do resultado final de uma solicitação de mudança, algo essencial para analisar throughput e retrabalho.

Este é o campo padrão status de uma issue do Jira. Os status disponíveis são definidos na configuração de Workflow do projeto.

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

Ele fornece um indicador claro e imediato da performance no Dashboard 'Monitor de performance do SLA de mudanças'. Isso simplifica a criação de KPIs como 'Taxa de cumprimento do SLA de mudanças' ao calcular previamente o status de cada caso. Assim, fica fácil filtrar e agregar os dados para identificar quais tipos de mudança, equipes ou serviços estão mais associados a violações de SLA.

Fornece um resultado binário claro sobre a performance do SLA em cada caso, simplificando os relatórios e a análise do cumprimento do SLA.

Calculado comparando o registro de data e hora da atividade final 'Mudança fechada' com o atributo 'TargetCompletionDate'.

O tipo de mudança categoriza a solicitação com base em sua natureza, urgência e impacto. Os tipos mais comuns incluem 'Standard', para mudanças pré-aprovadas e de baixo risco; 'Normal', para mudanças rotineiras que exigem aprovação completa; e 'Emergency', para mudanças urgentes destinadas a corrigir incidentes.

Este atributo é essencial para a análise do processo, pois diferentes tipos de mudança geralmente seguem caminhos distintos e têm SLAs diferentes. Ele é usado para calcular o KPI 'Taxa de mudanças emergenciais' e para filtrar Dashboards e comparar a performance e o risco associados a cada tipo.

Ele permite segmentar o processo para analisar diferentes Workflows, como mudanças padrão e emergenciais, que têm expectativas de performance e riscos específicos.

Este geralmente é um campo personalizado em projetos do Jira Service Management. O nome do campo pode variar, mas costuma ser 'Change Type'.

Este atributo calculado identifica solicitações de mudança que retornaram a uma etapa anterior para receber alterações, por exemplo, passando de 'Aguardando aprovação' de volta para 'Planejamento'. Isso indica que o envio inicial estava incompleto ou incorreto, ou não atendia aos critérios necessários.

Este indicador é a base do KPI 'Taxa de retrabalho de mudanças' e do Dashboard 'Análise de retrabalho e rejeição de mudanças'. Ao sinalizar os casos de retrabalho, os analistas podem filtrá-los facilmente e investigar as causas-raiz, como planejamento inicial inadequado, requisitos pouco claros ou avaliação de riscos insuficiente.

Destaca a ineficiência do processo ao sinalizar explicitamente os casos que exigiram trabalho extra e não planejado, permitindo analisar as causas-raiz do retrabalho.

Calculado pela análise da sequência de atividades no Event Log. Um retrabalho é detectado quando uma atividade de uma etapa posterior é seguida por uma atividade de uma etapa anterior.

Este atributo identifica a equipe responsável por trabalhar na mudança. Embora o Jira tenha o campo 'Assignee' para indivíduos, o campo 'Team' costuma ser usado para atribuir o trabalho a um grupo funcional, como 'Operações de rede' ou 'Administradores de banco de dados'.

Isso é essencial para o Dashboard 'Carga de trabalho das atividades da equipe de mudanças'. Ele permite analisar a performance e os gargalos no nível da equipe, e não apenas no nível individual, o que costuma ser mais útil para o planejamento e a gestão de recursos.

Facilita a análise da carga de trabalho e da performance no nível da equipe ou do departamento, destacando gargalos sistêmicos.

Este geralmente é um campo personalizado no Jira, pois não existe um campo padrão 'Team'. Ele pode ser do tipo 'Group Picker' ou uma simples lista de seleção.

Este atributo indica se a mudança resultou em um efeito negativo, como um incidente em produção. Isso geralmente envolve vincular a issue da solicitação de mudança a uma ou mais issues de incidente no Jira.

Esses dados são essenciais para calcular os KPIs 'Taxa de incidentes pós-implementação' e 'Taxa de falha de mudanças'. Eles fornecem uma medida direta da qualidade da mudança e da eficácia dos processos de planejamento, testes e avaliação de riscos. Analisar quais mudanças levam a incidentes ajuda a aprimorar os controles e evitar falhas futuras.

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

Este dado geralmente é obtido verificando as issues vinculadas no Jira, especificamente se uma issue de mudança tem links 'é causada por' provenientes de issues de incidente.

Este atributo registra o motivo subjacente da mudança, como 'Implementação de nova funcionalidade', 'Correção de bug' ou 'Atualização de infraestrutura'. Ele fornece um contexto importante além do resumo ou da 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 novas funcionalidades?' ou 'As atualizações de infraestrutura têm uma taxa de falha maior?'.

Fornece contexto de negócio para uma análise mais aprofundada, correlacionando o objetivo de uma mudança com sua performance e seu resultado.

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

O relator é a pessoa que criou a issue da solicitação de mudança no Jira. Geralmente, é o responsável pela mudança ou alguém que a inicia em nome de uma equipe.

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

Ajuda a identificar as origens das solicitações de mudança, que podem ser analisadas para melhorar a qualidade dos envios iniciais.

Este é o campo padrão reporter de uma issue do Jira.

Quando uma solicitação de mudança é fechada, o campo de resolução fornece informações específicas sobre o resultado. Por exemplo, 'Concluída' indica sucesso, enquanto 'Não será realizada' ou 'Duplicada' informam outros motivos de encerramento. Isso oferece mais contexto do que o status 'Fechada' sozinho.

Este atributo é essencial para analisar as taxas de sucesso e falha das mudanças. Por exemplo, o KPI 'Taxa de incidentes pós-implementação' pode ser melhor compreendido filtrando as mudanças com resolução 'Falhou' ou 'Revertida'. Ele ajuda a diferenciar 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, algo essencial para calcular com precisão as taxas de sucesso e falha.

Este é o campo padrão resolution do Jira, normalmente definido quando uma issue passa para uma categoria de status 'Done'.

Este atributo vincula a solicitação de mudança a um serviço de negócio específico definido no Configuration Management Database (CMDB), como 'Serviço de e-mail' ou 'CRM de clientes'. Esse é um conceito essencial para entender o impacto de negócio de uma mudança.

Analisar as mudanças por serviço de negócio ajuda a priorizar esforços e comunicar o impacto às partes interessadas. Isso permite identificar quais serviços estão passando por mais mudanças, quais correm mais risco e onde os incidentes relacionados a mudanças estão concentrados. Essa visão é fundamental para gerenciar mudanças técnicas sob uma perspectiva orientada ao negócio.

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

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