Seu Template de Dados de Gestão de Problemas
Seu Template de Dados de Gestão de Problemas
- Campos de dados essenciais para análise de causa raiz
- Marcos de processo padronizados para acompanhamento
- Orientação específica de extração para BMC Helix ITSM
Atributos de Gestão de Problemas
| Nome | Descrição | ||
|---|---|---|---|
|
Atividade
Activity
|
A tarefa específica ou evento de mudança de status que ocorreu. | ||
|
Descrição
Este atributo representa a etapa específica do ciclo de vida, como 'Registro de Problema Gerado', 'Causa Raiz Identificada' ou 'Base de Soluções Atualizada'. No BMC Helix, vêm do Histórico de Status, Logs de Auditoria ou timestamps de transação. É o núcleo da descoberta de processos. Analisando a sequência dessas atividades, a ferramenta constrói o mapa do processo, revelando o fluxo real comparado ao desenhado. Destaca loops, retrabalho e desvios do procedimento padrão. Nomes de atividades precisos são essenciais para entender o que ocorreu. Esses dados permitem medir tempos de transição, como o intervalo entre identificar a causa raiz e abrir uma requisição de mudança.
Por que é importante
Define os nós no mapa de processo e permite a visualização do workflow.
Onde obter
Derivado do histórico de status do PBM:Problem Investigation ou do PBM:AuditLogSystem
Exemplos
Registro de Problema GeradoAtribuído ao Grupo de SuporteInvestigação IniciadaCausa raiz identificada
|
|||
|
Registro de Problema
ProblemRecord
|
O identificador exclusivo para o caso de investigação de problema. | ||
|
Descrição
Este atributo serve como o identificador central do caso. No BMC Helix ITSM, é o campo 'Problem ID' (ex: PBI00000012345) do formulário PBM:Problem Investigation. Ele vincula todas as atividades, desde o registro inicial até o fechamento e revisão pós-implementação. Na análise de Process Mining, é usado para agrupar eventos individuais em uma única instância de processo. Permite visualizar a jornada ponta a ponta de uma investigação. Sem ele, seria impossível correlacionar as ações de diferentes grupos e coordenadores. Funciona como a chave primária para o Event Log e é essencial para agregações em nível de caso, como calcular o tempo total de ciclo por problema ou contar problemas por nível de prioridade.
Por que é importante
É a chave fundamental necessária para construir a visão do processo e rastrear o ciclo de vida de questões específicas.
Onde obter
Formulário PBM:Problem Investigation, campo 'Problem ID'
Exemplos
PBI00000004512PBI00000004513PBI00000004514
|
|||
|
Tempo do Evento
EventTime
|
O timestamp de quando a atividade específica ocorreu. | ||
|
Descrição
Este atributo registra a data e hora exatas de uma atividade. No BMC Helix ITSM, corresponde a campos como 'Submit Date', 'Last Modified Date' ou timestamps nas tabelas de histórico de mudanças de status. Na análise, ordena os eventos cronologicamente e calcula durações. Permite medir o tempo de ciclo entre quaisquer dois pontos do processo, como o 'Tempo de Investigação' ou o 'Lead Time de Publicação de Solução de Contorno'. Timestamps precisos são vitais para identificar gargalos. Calculando a diferença de tempo entre eventos consecutivos, analistas apontam onde ocorrem os atrasos, seja na atribuição inicial ou na fase final de revisão.
Por que é importante
Permite o cálculo de todos os KPIs baseados em duração e o sequenciamento de eventos.
Onde obter
Tabelas de histórico ou logs de auditoria associados ao PBM:Problem Investigation
Exemplos
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
|
|||
|
Sistema de Origem
SourceSystem
|
O sistema de origem dos dados. | ||
|
Descrição
Este atributo identifica o sistema de onde os dados foram extraídos, neste caso, 'BMC Helix ITSM'. É crucial em ambientes multi-sistema onde o Process Mining pode agregar dados de várias ferramentas de ITSM, desenvolvimento ou fornecedores externos. Na análise, serve como uma tag de metadados que valida a origem do registro. Se a visão combinar dados do BMC Helix e de um sistema de desenvolvimento (como Jira), este atributo ajuda a segmentar a análise pela ferramenta de origem. Também auxilia na solução de problemas técnicos. Se houver falhas na qualidade dos dados, saber o sistema de origem permite que os engenheiros de dados rastreiem o problema até a rotina de extração ou banco de dados específico.
Por que é importante
Fornece rastreabilidade e contexto, especialmente em visões de processos que envolvem múltiplos sistemas.
Onde obter
Codificado de forma fixa durante o processo de extração
Exemplos
BMC Helix ITSMRemedy OnDemandBMC ITSM Prod
|
|||
|
Última Atualização de Dados
LastDataUpdate
|
O timestamp de quando os dados foram extraídos ou atualizados pela última vez. | ||
|
Descrição
Este atributo indica quando os dados foram carregados pela última vez no aplicativo de Process Mining. Garante que os analistas saibam o quão atualizada está a informação. Geralmente é gerado pelo script de extração ou pipeline de dados. Na análise, evita decisões baseadas em dados obsoletos. Por exemplo, ao olhar 'Registros de Problemas Abertos', saber que a atualização foi há uma hora ou há uma semana muda totalmente a interpretação da carga de trabalho. Também serve para cargas incrementais. Ao rastrear a última atualização, o processo de ETL busca apenas registros alterados desde então, otimizando a performance e reduzindo a carga no sistema.
Por que é importante
Garante a atualização dos dados e auxilia em estratégias de carregamento incremental.
Onde obter
Hora do sistema no momento da extração
Exemplos
2023-11-01T00:00:00Z2023-11-01T12:00:00Z
|
|||
|
Categoria da causa raiz
RootCauseCategory
|
A classificação da causa subjacente do problema. | ||
|
Descrição
Este atributo contém a categoria selecionada quando a causa raiz é identificada (ex: 'Erro de Software', 'Falha de Hardware', 'Lacuna de Processo'). No BMC Helix, isso geralmente é selecionado nos menus 'Root Cause' ou categorização genérica. É essencial para a visão de 'Eficácia e Qualidade da Correção'. Ele permite correlacionar tipos de causa raiz com taxas de retrabalho ou tempos longos de investigação. Pode revelar, por exemplo, que problemas de software levam o dobro do tempo para resolver do que falhas de hardware. Também serve para calcular a 'Taxa de Categorização de Causa Raiz'. Muitos valores 'Desconhecidos' ou 'Outros' sugerem a necessidade de treinamento técnico ou categorias mais granulares.
Por que é importante
Permite a análise de tendências de problemas sistêmicos e apoia a gestão de problemas proativa.
Onde obter
Formulário PBM:Problem Investigation, campos da aba 'Root Cause' ou de categorização
Exemplos
Módulo de SoftwareInfraestrutura de RedeErro Humano
|
|||
|
CI de Serviço
ServiceCI
|
O serviço de negócio ou item de configuração principal afetado. | ||
|
Descrição
Este atributo identifica o Item de Configuração (CI) de serviço relacionado, como 'Serviço de E-mail', 'SAP' ou 'Rede Wi-Fi'. No BMC Helix, costuma ser o campo 'Service+' ou o relacionamento de CI principal. Na análise, permite segmentar problemas por produto ou serviço. Ajuda a liderança de TI a entender quais serviços são mais frágeis e geram mais investigações. Isso alimenta o dashboard de 'Volume de Vazão e Prioridade' com uma dimensão de produto. Correlacionar este atributo com o 'Tempo de Ciclo de Investigação' pode mostrar se serviços complexos (como sistemas bancários core) exigem naturalmente mais tempo de investigação do que serviços comuns (como impressão).
Por que é importante
Vincula o desempenho do processo a produtos ou serviços de negócio específicos.
Onde obter
Formulário PBM:Problem Investigation, campo 'ServiceCI' ou 'CI Name'
Exemplos
Serviço de e-mailSistema de Folha de PagamentoVPN corporativa
|
|||
|
Contagem de Incidentes Relacionados
RelatedIncidentCount
|
O número de incidentes vinculados a este registro de problema. | ||
|
Descrição
Este atributo quantifica o impacto contando o número de incidentes associados. No BMC Helix, é geralmente a contagem de registros no formulário HPD:Help Desk relacionados ao problema. Ele impulsiona o KPI de 'Densidade de Vinculação de Incidentes'. Uma contagem alta indica um problema de grande impacto gerando muito ruído no service desk. Correlacionar isso com 'Prioridade' garante que problemas de alto volume recebam tratamento crítico. Também ajuda a priorizar o backlog. Um problema com 500 incidentes vinculados deve ser priorizado em relação a um problema 'Crítico' com apenas 1, já que resolver o primeiro liberará muito mais capacidade no service desk.
Por que é importante
Quantifica o impacto operacional e a dor do usuário associada ao problema.
Onde obter
Calculado contando as linhas relacionadas em HPD:Associations ou HPD:Help Desk
Exemplos
15120
|
|||
|
Coordenador de Problemas
ProblemCoordinator
|
O usuário individual designado para coordenar a investigação. | ||
|
Descrição
Este atributo nomeia o responsável específico pelo registro de problema. No BMC Helix ITSM, é o campo 'Coordenador do Problema'. Esta pessoa é a dona do ciclo de vida do problema, mesmo que delegue tarefas. Alimenta o dashboard de 'Distribuição de Carga do Grupo de Suporte', ajudando gestores a identificar pessoas sobrecarregadas enquanto outras têm capacidade. Também permite analisar performance individual, identificando necessidades de treinamento ou talentos de destaque. No Process Mining, atua como um atributo de recurso. Ajuda a visualizar o fluxo de trabalho entre pessoas e destaca pontos únicos de falha onde o processo depende excessivamente de um único especialista.
Por que é importante
Permite a análise de recursos e o balanceamento de carga de trabalho em nível individual.
Onde obter
Formulário PBM:Problem Investigation, campo 'Problem Coordinator'
Exemplos
John DoeJane SmithAdministrador do Sistema
|
|||
|
Data de vencimento do SLA
SLADueDate
|
A data e hora alvo para a resolução do problema. | ||
|
Descrição
Este atributo armazena o prazo para a resolução do problema conforme o SLA. No BMC Helix, costuma ser a 'Target Resolution Date' ou um timestamp calculado de marco de SLA. É a base para o dashboard de 'Tendências de Conformidade e Violação de SLA'. Comparando este timestamp com a 'Resolução Verificada', o sistema calcula se o SLA foi cumprido ou violado. Visualizar esta data permite analisar a folga operacional. Os problemas são resolvidos com dias de antecedência ou minutos antes do prazo expirar? Esse insight é vital para o planejamento de capacidade.
Por que é importante
É o ponto de referência para calcular todas as métricas de conformidade e pontualidade.
Onde obter
Formulário PBM:Problem Investigation, campo 'Target Resolution Date'
Exemplos
2023-12-01T17:00:00Z2023-12-02T09:00:00Z
|
|||
|
Fator de Investigação
InvestigationDriver
|
O motivo pelo qual a investigação do problema foi iniciada. | ||
|
Descrição
Este atributo classifica o gatilho do registro de problema, como 'Volume de Incidentes', 'Incidente Crítico', 'Notificação de Fornecedor' ou 'Análise Proativa de Tendências'. No BMC Helix, este é o campo 'Investigation Driver'. Ele alimenta o dashboard de 'Tendências de Identificação Proativa', permitindo medir a transição do combate reativo a incêndios (responder a incidentes) para a gestão proativa (identificar riscos antes que se manifestem). Analisar fluxos por 'Investigation Driver' revela comportamentos distintos. Problemas 'Proativos' podem ficar mais tempo na fila por não causarem interrupções imediatas, enquanto os gerados por 'Incidentes Críticos' são priorizados com urgência.
Por que é importante
Distingue entre trabalho reativo e proativo, um indicador-chave de maturidade.
Onde obter
Formulário PBM:Problem Investigation, campo 'Investigation Driver'
Exemplos
ReativoProativoIncidentes Recorrentes
|
|||
|
Grupo de suporte
SupportGroup
|
A equipe técnica atualmente atribuída à investigação do problema. | ||
|
Descrição
Este atributo reflete o grupo de suporte específico (ex: 'Admin de Servidor', 'Suporte de DB') responsável pelo problema no momento do evento. No BMC Helix, é o campo 'Assigned Group'. É crítico para os dashboards de 'Distribuição de Carga' e 'Análise de Reatribuição'. Permite filtrar o mapa do processo por equipe, revelando quem lida com maior volume e onde estão os gargalos de investigação. Analisar transferências entre grupos ajuda a identificar o comportamento de 'ping-pong', onde um ticket pula entre times sem resolução. Isso costuma apontar responsabilidades nebulosas ou falhas na gestão de conhecimento da organização.
Por que é importante
Permite a análise organizacional e detecção de gargalos em nível de equipe.
Onde obter
Formulário PBM:Problem Investigation, campo 'Assigned Group'
Exemplos
Service Desk Nível 1Suporte de Back OfficeAdministração de Rede
|
|||
|
Prioridade
Priority
|
A prioridade calculada do problema com base no impacto e na urgência. | ||
|
Descrição
Este atributo indica a prioridade do problema (ex: Crítica, Alta, Média, Baixa). No BMC Helix, geralmente é um campo calculado com base no Impacto e na Urgência. Na análise, alimenta o dashboard de 'Volume de Vazão e Prioridade', permitindo verificar se os recursos estão alinhados às necessidades do negócio. Problemas 'Críticos' deveriam ter atribuições mais rápidas e ciclos mais curtos do que os de prioridade 'Baixa'. Filtrar por prioridade ajuda a focar as melhorias. Um gargalo em um processo de prioridade baixa pode ser aceitável, mas o mesmo atraso em um processo crítico representa um risco sério à continuidade do negócio e ao SLA.
Por que é importante
Segmenta a análise por criticidade de negócio e apoia a análise de SLA.
Onde obter
Formulário PBM:Problem Investigation, campo 'Priority'
Exemplos
CríticoAltoMédioBaixo
|
|||
|
SLA violado
IsSLABreached
|
Um marcador que indica se a resolução do problema excedeu o tempo permitido. | ||
|
Descrição
Este atributo booleano indica se o problema violou o SLA. É calculado comparando o timestamp de 'Resolução Verificada' com o 'Prazo do SLA' ou extraído do status de SLM. É vital para o dashboard de 'Tendências de Conformidade e Violação de SLA', permitindo segmentar o processo de forma binária: conforme vs. não conforme. Isso facilita isolar características de processos falhos (ex: 'Casos violados sempre envolvem o Grupo X?'). Serve como filtro principal para análise de causa raiz de falhas no processo. Analistas podem filtrar por 'SLA Violado = Sim' e examinar o mapa para ver onde o tempo foi perdido (ex: espera longa por aprovação de fornecedor).
Por que é importante
Simplifica o relatório de conformidade e a análise de falhas.
Onde obter
Formulário SLM:Measurement ou calculado
Exemplos
verdadeirofalse
|
|||
|
ID da Requisição de Mudança Relacionada
RelatedChangeRequestId
|
O identificador da requisição de mudança iniciada para corrigir o problema. | ||
|
Descrição
Este atributo contém o ID da Requisição de Mudança (ex: CRQ0000...) vinculada ao problema. Representa a transição da investigação para a implementação da correção definitiva. É fundamental para o KPI 'Lead Time da Causa Raiz para a Mudança'. Ele permite que a ferramenta de Process Mining meça o atraso entre achar a causa e iniciar a mudança, um ponto comum onde o processo perde fôlego. Também ajuda a validar a 'completude do processo'. Um registro fechado como 'Concluído', mas sem mudança relacionada (ou solução de contorno), pode indicar uma violação de processo: a causa foi achada, mas nunca corrigida.
Por que é importante
Vincula o processo de gestão de problemas ao processo de gestão de mudanças.
Onde obter
Associações PBM:Investigation ou guia de Relacionamento
Exemplos
CRQ00000021345CRQ00000021346
|
|||
|
Número de reatribuições
ReassignmentCount
|
O número total de vezes que o grupo de suporte foi alterado. | ||
|
Descrição
Este atributo conta quantas vezes a atividade 'Atribuído ao Grupo de Suporte' ocorre em um único caso. É uma medida direta de atrito no processo e eficiência de roteamento. Ele alimenta o gráfico de 'Análise de Reatribuição de Grupos'. Valores altos (ping-pong) indicam falha na triagem inicial ou falta de dono claro para problemas complexos. É um indicador antecipado de aumento no tempo de ciclo. Gestores usam isso para identificar treinamentos. Se o Service Desk reatribui problemas de 'Banco de Dados' para 'Redes' e 'Redes' devolve para 'Banco de Dados', a contagem de reatribuições sobe, sinalizando a necessidade de melhores scripts de diagnóstico inicial.
Por que é importante
Identifica desperdícios, atritos e falta de propriedade no processo.
Onde obter
Calculado a partir do histórico de atividades
Exemplos
015
|
|||
|
Região
Region
|
A região geográfica associada ao problema. | ||
|
Descrição
Este atributo especifica a localização geográfica (ex: 'América Latina', 'EMEA') onde o problema surgiu ou é gerido. No BMC Helix, costuma estar nos campos 'Region' ou 'Site'. Na análise, permite a segmentação geográfica. Ajuda a identificar se certas regiões têm maior volume de problemas ou resoluções mais lentas, o que pode indicar disparidades na equipe de suporte ou na qualidade da infraestrutura local. É valioso para organizações globais garantirem um serviço consistente. Se o 'Tempo de Investigação' no 'Brasil' for o dobro do 'México', isso sinaliza a necessidade de revisar a alocação de recursos ou a aderência ao processo naquela região.
Por que é importante
Permite a comparação geográfica do desempenho do processo.
Onde obter
Formulário PBM:Problem Investigation, campo 'Region'
Exemplos
AmericasEMEAAPAC
|
|||
|
Status da Solução de Contorno
WorkaroundStatus
|
Indica se uma solução de contorno válida foi identificada e publicada. | ||
|
Descrição
Este atributo rastreia o estado da solução temporária (Workaround). Pode ser um booleano (Tem Solução de Contorno) ou uma string de status. No BMC Helix, costuma derivar do preenchimento do campo 'Workaround' ou de uma flag de status. É fundamental para o dashboard de 'Performance de Publicação de Soluções de Contorno'. Ele mostra o quão bem a equipe mitiga o impacto enquanto pesquisa a causa raiz. Filtrar por 'Sem Solução de Contorno' destaca casos onde o negócio sofre o impacto total. Também auxilia auditorias de qualidade. Fechar um problema sem uma correção definitiva (Requisição de Mudança) E sem uma solução de contorno é geralmente uma falha de processo que exige revisão.
Por que é importante
Mede a eficácia da mitigação de impacto durante a investigação.
Onde obter
Formulário PBM:Problem Investigation, verificação de conteúdo do campo 'Workaround'
Exemplos
AtivoNenhumAposentado
|
|||
|
Tempo de Ciclo de Investigação
InvestigationCycleTime
|
A duração desde o início da investigação até a identificação da causa raiz. | ||
|
Descrição
Este é um atributo de duração calculado que mede o tempo entre 'Investigação Iniciada' e 'Causa Raiz Identificada'. Representa o tempo de agregação de valor real na gestão de problemas. Essa métrica alimenta o dashboard de 'Tempo de Ciclo de Investigação de Causa Raiz'. Ajuda gestores a entender a complexidade técnica e a eficiência das equipes. Anomalias (ex: tempos curtíssimos) podem indicar diagnósticos precipitados, enquanto tempos longos indicam investigações travadas. Comparando essa métrica entre grupos e prioridades, a organização identifica quais times precisam de melhores ferramentas, treinamento ou suporte de fornecedores para diagnosticar problemas mais rápido.
Por que é importante
É a principal métrica de eficiência para a fase de investigação técnica.
Onde obter
Calculado a partir dos timestamps das atividades
Exemplos
4500000120000
|
|||
Atividades de Gestão de Problemas
| Atividade | Descrição | ||
|---|---|---|---|
|
Atribuído ao Grupo de Suporte
|
A atribuição do registro de problema a uma equipe técnica específica. Capturada pelo monitoramento de mudanças no campo 'Assigned Group'. | ||
|
Por que é importante
Essencial para medir transições, efeitos pingue-pongue e o KPI de 'Tempo Médio para Atribuição Inicial'.
Onde obter
Formulário PBM:Problem Investigation, histórico do campo 'Assigned Group' ou log de auditoria.
Captura
Compara o campo 'Assigned Group' antes e depois da atualização
Tipo de evento
inferred
|
|||
|
Causa raiz identificada
|
O momento em que o registro do problema transita para um estado que indica que a causa é conhecida. Inferido quando o Status muda para 'Root Cause Identified'. | ||
|
Por que é importante
Um marco crítico para o dashboard de 'Tempo de Ciclo de Investigação da Causa Raiz'. Sinaliza a mudança da análise para a solução.
Onde obter
Formulário PBM:Problem Investigation, campo 'Status' = 'Root Cause Identified'.
Captura
Compara o campo de status para a transição para Causa Raiz Identificada
Tipo de evento
inferred
|
|||
|
Investigação Iniciada
|
A transição do registro de problema para uma fase de análise ativa. Isso é inferido quando o campo Status muda para 'Under Investigation'. | ||
|
Por que é importante
Marca o início da fase de trabalho real, apoiando o KPI de 'Tempo de Ciclo de Investigação'.
Onde obter
Formulário PBM:Problem Investigation, campo 'Status' = 'Under Investigation'.
Captura
Compara o campo de status para a transição para Sob Investigação
Tipo de evento
inferred
|
|||
|
Registro de Problema Cancelado
|
O encerramento de um registro de problema antes da resolução. Capturado quando o status se torna 'Cancelled' ou 'Rejected'. | ||
|
Por que é importante
Identifica esforço desperdiçado ou duplicatas válidas. Representa um ponto final alternativo.
Onde obter
Formulário PBM:Problem Investigation, campo 'Status' = 'Cancelled' ou 'Rejected'.
Captura
Compara o campo de status para a transição para Cancelado
Tipo de evento
inferred
|
|||
|
Registro de Problema Fechado
|
O fechamento administrativo final do registro do problema. Este evento encerra a instância do processo. | ||
|
Por que é importante
O evento de término padrão. Necessário para análise completa do tempo de ciclo e cálculo da 'Densidade de Vinculação de Incidentes'.
Onde obter
Formulário PBM:Problem Investigation, campo 'Status' = 'Closed'.
Captura
Compara o campo de status para a transição para Fechado
Tipo de evento
inferred
|
|||
|
Registro de Problema Gerado
|
A criação inicial de um registro de Investigação de Problema no sistema. Este evento é capturado quando uma nova entrada é salva no formulário PBM:Problem Investigation. | ||
|
Por que é importante
Marca o início da instância do processo. Crítico para o cálculo dos tempos de ciclo totais e métricas de resposta inicial.
Onde obter
Formulário PBM:Problem Investigation, timestamp de 'Submit Date' ou log de criação de 'Status' = 'Draft'.
Captura
Registrado quando o registro de PBM:Problem Investigation é criado
Tipo de evento
explicit
|
|||
|
Requisição de Mudança Iniciada
|
A vinculação de uma Requisição de Mudança de Infraestrutura à Investigação do Problema. Isso sinaliza o início da fase de implementação. | ||
|
Por que é importante
Crítico para o KPI de 'Tempo de Espera da Causa Raiz para Mudança' e para identificar silos entre os processos de Problema e Mudança.
Onde obter
Tabela PBM:Investigation_Associations ou preenchimento do campo 'Infrastructure Change ID'.
Captura
Registrado quando a associação é criada em PBM:Investigation_Associations
Tipo de evento
explicit
|
|||
|
Resolução Verificada
|
O ponto onde a correção definitiva é confirmada como bem-sucedida. Inferido pela mudança do Status para 'Solution Implemented' ou 'Completed'. | ||
|
Por que é importante
Usado para 'Taxa de Aderência ao SLA de Problemas'. Confirma que o trabalho técnico foi concluído.
Onde obter
Formulário PBM:Problem Investigation, campo 'Status' = 'Solution Implemented' ou 'Completed'.
Captura
Compara o campo de status para a transição para Solução Implementada
Tipo de evento
inferred
|
|||
|
Solução de Contorno Definida
|
A entrada ou atualização de texto no campo 'Workaround' do registro do problema. Este evento indica que uma solução temporária foi documentada. | ||
|
Por que é importante
Apoia o KPI 'Lead Time de Publicação de Solução de Contorno'. Indica a mitigação do impacto do incidente.
Onde obter
Formulário PBM:Problem Investigation, alterações no campo de texto 'Workaround'.
Captura
Compara o conteúdo do campo 'Workaround' para atualizações não nulas
Tipo de evento
inferred
|
|||
|
Base de Soluções Atualizada
|
A transição do registro para o status 'Solution Database', indicando que uma correção definitiva foi proposta ou identificada. | ||
|
Por que é importante
Rastreia o progresso da definição da solução antes da implementação.
Onde obter
Formulário PBM:Problem Investigation, campo 'Status' = 'Solution Database'.
Captura
Compara o campo de status para a transição para Base de Soluções
Tipo de evento
inferred
|
|||
|
Coordenador Reatribuído
|
Uma alteração no Coordenador de Problemas individual dentro de um grupo de suporte. Capturado monitorando o campo 'Problem Coordinator'. | ||
|
Por que é importante
Ajuda a analisar a distribuição de carga de trabalho e gargalos de recursos individuais.
Onde obter
Formulário PBM:Problem Investigation, histórico do campo 'Problem Coordinator'.
Captura
Compara o campo 'Problem Coordinator' antes e depois da atualização
Tipo de evento
inferred
|
|||
|
Erro Conhecido Promovido
|
A criação de um registro de Erro Conhecido vinculado à investigação do problema. Este é um evento de criação de registro relacionado. | ||
|
Por que é importante
Indica a formalização do problema para comunicação mais ampla e rastreamento de longo prazo.
Onde obter
Criação de um registro no PBM:Known Error vinculado ao ID do PBM:Problem Investigation.
Captura
Registrado quando o registro de PBM:Known Error é criado
Tipo de evento
explicit
|
|||
|
Revisão Pós-Implementação Realizada
|
A conclusão da fase de PIR. Capturada por uma transição de status para fora de um estado de PIR ou pelo fechamento de uma Tarefa de PIR vinculada. | ||
|
Por que é importante
Apoia diretamente a 'Conformidade de Revisão Pós-Implementação' e auditorias de qualidade de processo.
Onde obter
Formulário PBM:Problem Investigation, flag específica 'PIR Required' ou conclusão de Task vinculada do tipo 'PIR'.
Captura
Derivado da conclusão do status PIR ou fechamento da Task PIR
Tipo de evento
inferred
|
|||