Seu Template de dados de gestão de problemas

BMC Helix ITSM
Seu Template de dados de gestão de problemas

Seu Template de dados de gestão de problemas

Este Template oferece uma estrutura completa para analisar seus Workflows de investigação de causas raiz no BMC Helix ITSM. Ele apresenta os atributos e as atividades de processo essenciais para criar um Event Log detalhado, além de orientações práticas de extração. Seguindo este guia, você consegue identificar gargalos ocultos e simplificar o caminho até a resolução permanente dos incidentes.
  • Campos de dados essenciais para a análise da causa raiz
  • Marcos de processo padronizados para acompanhamento
  • Orientações específicas de extração para o BMC Helix ITSM
Novo em Event Logs? Aprenda como criar um Event Log de Process Mining.

Atributos da gestão de problemas

Esta tabela contém os campos de dados recomendados necessários para preencher seu Event Log e realizar uma análise completa do ciclo de vida da gestão de problemas.
5 Obrigatório 9 Recomendado 5 Opcional
Nome Descrição
Atividade
Activity
A Task específica ou o evento de alteração de status que ocorreu.
Descrição

Esse atributo representa a etapa específica executada no ciclo de vida de Problem Management, como 'Problem Record Logged', 'Root Cause Identified' ou 'Solution Database Updated'. No BMC Helix, esses dados geralmente são derivados do histórico de status, dos registros de auditoria ou de carimbos de data e hora de transações específicas no módulo Problem Investigation.

Esse atributo é o núcleo da descoberta de processos. Ao analisar a sequência dessas atividades, a ferramenta de Process Mining constrói o mapa do processo, revelando o fluxo real de trabalho em comparação com o processo projetado. Ela destaca loops, retrabalho e desvios do procedimento operacional padrão.

Nomes precisos de atividades são essenciais para entender o que realmente aconteceu durante o ciclo de vida. Esses dados permitem medir os tempos de transição entre etapas específicas, como o tempo entre a identificação de uma causa raiz e o início de uma solicitação de mudança.

Por que isso importa

Ele define os nós do mapa do processo e permite visualizar o Workflow.

Onde obter

Derivado do histórico de status de PBM:Problem Investigation ou PBM:AuditLogSystem

Exemplos
Registro de problema criadoAtribuído ao grupo de suporteInvestigação iniciadaCausa raiz identificada
Horário do evento
EventTime
O carimbo de data e hora em que a atividade específica ocorreu.
Descrição

Esse atributo registra a data e a hora exatas em que uma atividade ocorreu. No BMC Helix ITSM, corresponde a campos como 'Submit Date', 'Last Modified Date' ou a carimbos de data e hora específicos registrados nas tabelas de histórico relacionadas às alterações de status.

Na análise, esse atributo é usado para ordenar os eventos cronologicamente e calcular durações. Ele permite medir os tempos de ciclo entre quaisquer dois pontos do processo, como 'Investigation Cycle Time' ou 'Workaround Publication Lead Time'.

Carimbos de data e hora precisos são essenciais para identificar gargalos. Ao calcular a diferença de tempo entre eventos consecutivos, os analistas conseguem apontar exatamente onde os atrasos estão ocorrendo, seja durante a atribuição inicial ou na fase de revisão final.

Por que isso importa

Ele permite calcular todos os KPIs baseados em duração e ordenar os eventos.

Onde obter

Tabelas de histórico ou registros de auditoria associados a PBM:Problem Investigation

Exemplos
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
Registro de problema
ProblemRecord
O identificador exclusivo do caso de investigação do problema.
Descrição

Esse atributo funciona como o identificador central do caso no processo de Problem Management. No BMC Helix ITSM, normalmente corresponde ao campo 'Problem ID' (por exemplo, PBI00000012345), encontrado no formulário PBM:Problem Investigation. Ele conecta todas as atividades relacionadas, desde o registro inicial do problema até o encerramento final e a revisão pós-implementação.

Na análise de Process Mining, esse atributo é usado para agrupar eventos individuais em uma única instância do processo. Ele permite que os analistas visualizem a jornada completa de uma investigação específica de problema. Sem esse identificador, seria impossível correlacionar a sequência de ações realizadas por diferentes grupos de suporte e coordenadores.

Esse campo funciona como a chave primária do Event Log e é essencial para todas as agregações no nível do caso, como calcular o tempo total de ciclo por problema ou contar a quantidade de problemas por nível de prioridade.

Por que isso importa

É a chave fundamental necessária para construir a visão do processo e acompanhar o ciclo de vida de problemas específicos.

Onde obter

Formulário PBM:Problem Investigation, campo 'Problem ID'

Exemplos
PBI00000004512PBI00000004513PBI00000004514
Sistema de origem
SourceSystem
O sistema de onde os dados foram originados.
Descrição

Esse atributo identifica o sistema de software do qual os dados do processo foram extraídos, neste caso, 'BMC Helix ITSM'. Ele é especialmente importante em ambientes com vários sistemas, nos quais o Process Mining pode agregar dados de diferentes ferramentas de ITSM, desenvolvimento ou fornecedores externos.

Na análise, esse campo funciona como uma tag de metadados que valida a origem do registro. Se a visão de Process Mining combinar dados do BMC Helix para Problem Management com um sistema separado de desenvolvimento de software, como o Jira, esse atributo ajudará a segmentar a análise pela ferramenta de origem.

Ele também ajuda na solução de problemas técnicos. Quando surgem problemas de qualidade dos dados, conhecer o sistema de origem permite que os engenheiros de dados rastreiem o problema até a rotina de extração ou o banco de dados de origem específico.

Por que isso importa

Ele oferece rastreabilidade e contexto, especialmente em visões de processos que envolvem vários sistemas.

Onde obter

Definido durante o processo de extração

Exemplos
BMC Helix ITSMRemedy OnDemandBMC ITSM Prod
Última atualização dos dados
LastDataUpdate
O carimbo de data e hora em que os dados foram extraídos ou atualizados pela última vez.
Descrição

Esse atributo indica quando os dados foram carregados pela última vez no aplicativo de Process Mining. Ele garante que os analistas saibam quão atuais são os dados que estão visualizando. Normalmente, é gerado pelo script de extração ou pela ferramenta de pipeline de dados.

Na análise, isso ajuda a evitar decisões baseadas em dados desatualizados. Por exemplo, se um gestor estiver analisando 'Open Problem Records', saber que os dados foram atualizados há uma hora, e não há uma semana, muda significativamente a interpretação da carga de trabalho atual.

Ele também é usado em cargas incrementais de dados. Ao acompanhar o horário da última atualização, o processo de ETL pode buscar apenas os registros alterados desde a extração anterior, otimizando a performance e reduzindo a carga no sistema.

Por que isso importa

Ele garante a atualização dos dados e ajuda nas estratégias de carregamento incremental.

Onde obter

Horário 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

Esse atributo contém a categoria selecionada quando a causa raiz é identificada, como 'Software Error', 'Hardware Failure' ou 'Process Gap'. No BMC Helix, normalmente é selecionado nos menus 'Root Cause' ou 'Generic Categorization'.

Esse atributo é essencial para a visão 'Fix Effectiveness and Quality'. Ele permite que a organização correlacione tipos específicos de causas raiz com taxas de retrabalho ou investigações longas. Por exemplo, pode revelar que problemas de 'Software Error' levam consistentemente o dobro do tempo para serem resolvidos em comparação com problemas de 'Hardware Failure'.

Ele também é usado para calcular a 'Root Cause Categorization Rate'. Uma porcentagem alta de valores 'Unknown' ou 'Other' nesse campo sugere a necessidade de melhorar o treinamento técnico ou oferecer opções de categorização mais detalhadas.

Por que isso importa

Ele permite analisar tendências de problemas sistêmicos e dá suporte ao gerenciamento proativo de problemas.

Onde obter

Formulário PBM:Problem Investigation, campos das abas 'Root Cause' ou de categorização

Exemplos
Módulo de softwareInfraestrutura de redeErro humano
CI do serviço
ServiceCI
O principal serviço de negócio ou item de configuração afetado.
Descrição

Esse atributo identifica o Item de Configuração de Serviço (CI) relacionado ao problema, como 'Email Service', 'SAP ERP' ou 'Wi-Fi Network'. No BMC Helix, geralmente corresponde ao campo 'Service+' ou ao relacionamento com o CI principal.

Na análise, ele permite segmentar os registros de 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 de problemas. Isso alimenta o Dashboard 'Throughput and Priority Volume' ao adicionar uma dimensão de produto.

Correlacionar esse atributo com 'Investigation Cycle Time' pode mostrar se determinados serviços complexos, como um sistema bancário central, exigem naturalmente períodos de investigação mais longos do que serviços comuns, como impressão.

Por que isso importa

Ele conecta a performance do processo a produtos ou serviços específicos do negócio.

Onde obter

Formulário PBM:Problem Investigation, campo 'ServiceCI' ou 'CI Name'

Exemplos
Serviço de e-mailSistema de folha de pagamentoVPN corporativa
Coordenador de problemas
ProblemCoordinator
O usuário individual responsável por coordenar a investigação.
Descrição

Esse atributo identifica a pessoa responsável pelo registro de problema. No BMC Helix ITSM, corresponde ao campo 'Problem Coordinator'. Essa pessoa é responsável pelo ciclo de vida do problema, mesmo quando as Tasks são delegadas a outras pessoas.

Esse atributo dá suporte ao Dashboard 'Support Group Workload Distribution'. Ele ajuda os gestores a identificar se determinadas pessoas estão sobrecarregadas com investigações enquanto outras têm capacidade disponível. Também permite analisar a performance individual, ajudando a identificar necessidades de treinamento ou profissionais de alto desempenho.

No Process Mining, esse campo funciona como um atributo de recurso. Ele ajuda a visualizar como o trabalho flui entre as pessoas e pode destacar pontos únicos de falha, nos quais o processo depende demais de um especialista específico.

Por que isso importa

Ele permite analisar recursos e equilibrar a carga de trabalho no nível individual.

Onde obter

Formulário PBM:Problem Investigation, campo 'Problem Coordinator'

Exemplos
John DoeJane SmithAdministrador de sistemas
Data de vencimento do SLA
SLADueDate
A data e a hora limite até as quais o problema deve ser resolvido.
Descrição

Esse atributo contém o prazo para a resolução do problema com base no acordo de nível de serviço. No BMC Helix, geralmente corresponde a 'Target Resolution Date' ou a um carimbo de data e hora calculado de um marco do SLA.

Esse atributo é a referência para o Dashboard 'SLA Compliance and Breach Trends'. Ao comparar esse carimbo de data e hora com o carimbo da atividade 'Resolution Verified', o sistema calcula se o SLA foi cumprido ou violado.

Visualizar essa data permite que os analistas entendam quão perto do limite a equipe está concluindo o trabalho. Os problemas estão sendo resolvidos com dias de antecedência ou terminam consistentemente poucos minutos antes do descumprimento? Esse insight orienta o planejamento de capacidade.

Por que isso importa

É a 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
Grupo de suporte
SupportGroup
A equipe técnica atualmente responsável pela investigação do problema.
Descrição

Esse atributo representa o grupo de suporte específico, como 'Server Admin' ou 'Database Support', responsável pelo registro de problema no momento do evento. No BMC Helix, corresponde ao campo 'Assigned Group'.

Esse atributo é essencial para os Dashboards 'Support Group Workload Distribution' e 'Support Group Reassignment Analysis'. Ele permite que os analistas segmentem o mapa do processo por equipe, revelando quais grupos estão lidando com o maior volume e quais são gargalos no processo de investigação.

Analisar as transferências entre grupos de suporte ajuda a identificar o comportamento de 'pingue-pongue', em que um chamado passa de uma equipe para outra sem ser resolvido. Isso geralmente aponta para responsabilidades pouco claras ou uma gestão do conhecimento inadequada na organização.

Por que isso importa

Ele permite analisar a organização e detectar gargalos no nível da equipe.

Onde obter

Formulário PBM:Problem Investigation, campo 'Assigned Group'

Exemplos
Service Desk Nível 1Suporte de back officeAdministração de redes
Motivo da investigação
InvestigationDriver
O motivo pelo qual a investigação do problema foi iniciada.
Descrição

Esse atributo classifica o gatilho do registro de problema, como 'Incident Volume', 'Major Incident', 'Vendor Notification' ou 'Proactive Trend Analysis'. No BMC Helix, corresponde ao campo 'Investigation Driver'.

Esse atributo dá suporte ao Dashboard 'Proactive Identification Trends'. Ele permite que a organização meça a mudança de uma atuação reativa, respondendo a incidentes, para uma gestão proativa de problemas, identificando riscos antes que eles se manifestem.

Analisar os fluxos do processo por 'Investigation Driver' pode revelar comportamentos diferentes. Por exemplo, problemas 'Proactive' podem permanecer mais tempo na fila porque não causam indisponibilidades imediatas, enquanto problemas motivados por 'Major Incident' avançam rapidamente pelo processo.

Por que isso importa

Ele diferencia o trabalho reativo do proativo, um indicador importante de maturidade.

Onde obter

Formulário PBM:Problem Investigation, campo 'Investigation Driver'

Exemplos
ReativoProativoIncidentes recorrentes
Prioridade
Priority
A prioridade calculada do problema com base no impacto e na urgência.
Descrição

Esse atributo indica o nível de prioridade do registro de problema, como Critical, High, Medium ou Low. No BMC Helix, normalmente é um campo calculado a partir das seleções de Impact e Urgency.

Na análise, ele é usado para o Dashboard 'Throughput and Priority Volume'. Ele permite que as organizações verifiquem se os recursos estão alinhados corretamente às necessidades do negócio. Por exemplo, problemas 'Critical' teoricamente deveriam ter tempos de atribuição inicial mais rápidos e tempos totais de ciclo menores do que problemas de prioridade 'Low'.

Filtrar por prioridade ajuda a direcionar os esforços de melhoria. Um gargalo em um processo de prioridade 'Low' pode ser aceitável, mas o mesmo atraso em um processo 'Critical' representa um risco significativo para a continuidade do negócio e a conformidade com o SLA.

Por que isso importa

Ele segmenta a análise por criticidade do negócio e dá suporte à análise de SLA.

Onde obter

Formulário PBM:Problem Investigation, campo 'Priority'

Exemplos
CríticoAltoMédioBaixo
Quantidade de incidentes relacionados
RelatedIncidentCount
A quantidade de incidentes vinculados a esse registro de problema.
Descrição

Esse atributo quantifica o impacto do problema contando a quantidade de incidentes associados a ele. No BMC Helix, normalmente corresponde à contagem de registros no formulário HPD:Help Desk relacionados ao registro PBM.

Esse atributo alimenta o KPI 'Incident Linkage Density'. Uma quantidade alta indica um problema de grande impacto, gerando muito volume para a central de serviços. Correlacioná-lo com 'Priority' garante que problemas de alto volume sejam realmente tratados como críticos.

Ele também ajuda a priorizar o backlog. Um registro de problema com 500 incidentes vinculados provavelmente deve ser priorizado em relação a um problema 'Critical' com apenas 1 incidente, pois resolver o primeiro liberará mais capacidade da central de serviços.

Por que isso importa

Ele quantifica o impacto operacional e o impacto para os usuários associados ao problema.

Onde obter

Calculado contando as linhas relacionadas em HPD:Associations ou HPD:Help Desk

Exemplos
15120
SLA violado
IsSLABreached
Um indicador que mostra se a resolução do problema ultrapassou o tempo permitido.
Descrição

Este atributo booleano indica se o registro do problema violou o acordo de nível de serviço. Ele é calculado comparando o carimbo de data e hora de 'Resolution Verified' com a 'SLA Due Date' ou é extraído diretamente do status do SLM.

Este atributo é fundamental para o Dashboard 'SLA Compliance and Breach Trends'. Ele permite uma segmentação binária simples do processo: em conformidade ou fora de conformidade. Assim, fica fácil isolar as características dos processos que falharam, por exemplo: 'Os casos que violam o SLA sempre envolvem o Support Group X?'.

Ele funciona como um filtro principal para a análise da causa raiz de falhas de processo. Os analistas podem filtrar por 'IsSLABreached = True' e examinar o mapa do processo para identificar onde o tempo foi perdido, como em longos tempos de espera pela aprovação do fornecedor.

Por que isso importa

Simplifica os relatórios de conformidade e a análise de falhas.

Onde obter

Formulário SLM:Measurement ou calculado

Exemplos
truefalse
Contagem 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 'Assigned to Support Group' ocorre em um único caso. Ele mede diretamente o atrito do processo e a eficiência do roteamento.

Este atributo alimenta o gráfico 'Support Group Reassignment Analysis'. Valores altos, indicando um efeito de pingue-pongue, mostram que a triagem inicial está falhando ou que não existe uma responsabilidade clara por problemas complexos. É um indicador antecedente do aumento do tempo de ciclo.

Os gestores usam esse dado para identificar oportunidades de treinamento. Se o Service Desk reatribui consistentemente problemas de 'Database' primeiro para 'Network', e depois 'Network' os envia para 'Database', a contagem de reatribuições aumenta, destacando a necessidade de scripts melhores para o diagnóstico inicial.

Por que isso importa

Identifica desperdícios, atritos e falta de responsabilidade no processo.

Onde obter

Calculado com base no histórico de atividades

Exemplos
015
ID da solicitação de mudança relacionada
RelatedChangeRequestId
O identificador da solicitação de mudança iniciada para corrigir o problema.
Descrição

Esse atributo contém o ID da Change Request, como CRQ0000..., vinculada ao registro de problema. Ele representa a transição da investigação para a implementação de uma correção permanente.

Esse atributo é necessário para o KPI 'Root Cause to Change Lead Time'. Ele permite que a ferramenta de Process Mining meça o atraso entre a descoberta da causa raiz e o início do processo de mudança. Esse é um ponto comum de transferência em que o ritmo se perde.

Ele também ajuda a verificar a 'completude do processo'. Um registro de problema encerrado com status 'Completed', mas sem uma solicitação de mudança relacionada ou uma solução alternativa, pode indicar uma violação do processo, na qual a causa raiz foi encontrada, mas nunca foi realmente corrigida.

Por que isso importa

Ele conecta o processo de Problem Management ao processo de Change Management.

Onde obter

PBM:Investigation Associations ou aba Relationship

Exemplos
CRQ00000021345CRQ00000021346
Região
Region
A região geográfica associada ao problema.
Descrição

Esse atributo especifica a localização geográfica, como 'North America' ou 'EMEA', onde o problema se originou ou está sendo gerenciado. No BMC Helix, geralmente aparece nos campos 'Region' ou 'Site' associados ao solicitante ou ao ativo afetado.

Na análise, ele dá suporte à segmentação geográfica. Ajuda a identificar se determinadas regiões apresentam volumes maiores de problemas ou tempos de resolução mais longos. Isso pode revelar diferenças na disponibilidade de equipes de suporte ou na qualidade da infraestrutura entre diferentes localidades.

Ele é valioso para organizações globais que precisam garantir uma prestação de serviços consistente. Se o 'Investigation Cycle Time' em 'APAC' for o dobro do registrado em 'NAM', isso indica a necessidade de investigar a alocação de recursos ou a adesão ao processo nessa região.

Por que isso importa

Ele permite comparar a performance do processo entre regiões.

Onde obter

Formulário PBM:Problem Investigation, campo 'Region'

Exemplos
AméricasEMEAAPAC
Status da solução alternativa
WorkaroundStatus
Indica se uma solução alternativa válida foi identificada e publicada.
Descrição

Este atributo acompanha o estado da solução temporária (Workaround). Pode ser um simples valor booleano (Has Workaround) ou uma string de status. No BMC Helix, geralmente é derivado da presença de texto no campo 'Workaround' ou de um indicador de status específico.

Este atributo é fundamental para o Dashboard 'Workaround Publication Performance'. Ele mostra com que eficiência a equipe reduz o impacto enquanto investiga a causa raiz. Uma visão do processo filtrada por 'No Workaround' destaca os casos em que o negócio está sofrendo o impacto total durante a investigação.

Ele também apoia auditorias de qualidade. Encerrar um registro de problema sem uma correção permanente (Change Request) E sem uma solução alternativa geralmente indica uma falha de processo que precisa ser analisada.

Por que isso importa

Mede a eficácia da redução do impacto durante a investigação.

Onde obter

Formulário PBM:Problem Investigation, verificação do conteúdo do campo 'Workaround'

Exemplos
AtivoNenhumRetirado
Tempo de ciclo da investigação
InvestigationCycleTime
O tempo entre o início da investigação e a identificação da causa raiz.
Descrição

Este é um atributo de duração calculado que mede o tempo entre a atividade 'Investigation Commenced' e a atividade 'Root Cause Identified'. Ele representa o principal tempo que agrega valor no processo de gestão de problemas.

Essa métrica alimenta o Dashboard 'Root Cause Investigation Cycle Time'. Ela ajuda os gestores a entender a complexidade técnica dos problemas e a eficiência das equipes de investigação. Anomalias aqui, como tempos extremamente curtos, podem indicar uma suposição, enquanto tempos muito longos indicam investigações paradas.

Comparando essa métrica entre 'Support Groups' e 'Priorities', a organização consegue identificar quais equipes precisam de ferramentas, treinamento ou suporte de fornecedores para diagnosticar problemas mais rapidamente.

Por que isso importa

É a principal métrica de eficiência da fase de investigação técnica.

Onde obter

Calculado com base nos carimbos de data e hora das atividades

Exemplos
4500000120000
Obrigatório Recomendado Opcional

Atividades da gestão de problemas

Estas são as etapas fundamentais do processo e as alterações de status que você deve acompanhar para obter visibilidade completa das fases de investigação e resolução.
9 Recomendado 4 Opcional
Atividade Descrição
Atribuído ao grupo de suporte
A atribuição do registro de problema a uma equipe técnica específica. Capturada monitorando alterações no campo 'Assigned Group'.
Por que isso importa

Essencial para medir transferências, efeitos de pingue-pongue e o KPI 'Mean Time to Initial Assignment'.

Onde obter

Formulário PBM:Problem Investigation, histórico do campo 'Assigned Group' ou registro de auditoria.

Captura

Comparar o campo 'Assigned Group' antes e depois da atualização

Tipo de evento inferred
Causa raiz identificada
O momento em que o registro de problema passa para um estado que indica que a causa é conhecida. Inferido quando o Status muda para 'Root Cause Identified'.
Por que isso importa

Um marco crítico para o Dashboard 'Root Cause Investigation Cycle Time'. Sinaliza a passagem da análise para a definição da solução.

Onde obter

Formulário PBM:Problem Investigation, campo 'Status' = 'Root Cause Identified'.

Captura

Comparar o campo de status para identificar a transição para Root Cause Identified

Tipo de evento inferred
Investigação iniciada
A transição do registro de problema para uma fase ativa de análise. É inferida quando o campo Status muda para 'Under Investigation'.
Por que isso importa

Marca o início da fase efetiva de trabalho e dá suporte ao KPI 'Investigation Cycle Time'.

Onde obter

Formulário PBM:Problem Investigation, campo 'Status' = 'Under Investigation'.

Captura

Comparar o campo de status para identificar a transição para Under Investigation

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 isso importa

Identifica esforço desperdiçado ou duplicidades válidas. Representa um ponto final alternativo.

Onde obter

Formulário PBM:Problem Investigation, campo 'Status' = 'Cancelled' ou 'Rejected'.

Captura

Comparar o campo de status para identificar a transição para Cancelled

Tipo de evento inferred
Registro de problema criado
A criação inicial de um registro de investigação de problema no sistema. Esse evento é capturado explicitamente quando uma nova entrada é salva no formulário PBM:Problem Investigation.
Por que isso importa

Marca o início da instância do processo. É essencial para calcular os tempos totais de ciclo e as métricas de resposta inicial.

Onde obter

Formulário PBM:Problem Investigation, carimbo de data e hora de 'Submit Date' ou registro de criação com 'Status' = 'Draft'.

Captura

Registrado quando o registro PBM:Problem Investigation é criado

Tipo de evento explicit
Registro de problema encerrado
O encerramento administrativo final do registro de problema. Esse evento encerra a instância do processo.
Por que isso importa

O evento final padrão. Necessário para a análise completa do tempo de ciclo e o cálculo de 'Incident Linkage Density'.

Onde obter

Formulário PBM:Problem Investigation, campo 'Status' = 'Closed'.

Captura

Comparar o campo de status para identificar a transição para Closed

Tipo de evento inferred
Resolução verificada
O momento em que a correção permanente é confirmada como bem-sucedida. Inferido quando o Status muda para 'Solution Implemented' ou 'Completed'.
Por que isso importa

Usado para a 'Problem SLA Adherence Rate'. Confirma que o trabalho técnico foi concluído.

Onde obter

Formulário PBM:Problem Investigation, campo 'Status' = 'Solution Implemented' ou 'Completed'.

Captura

Comparar o campo de status para identificar a transição para Solution Implemented

Tipo de evento inferred
Solicitação de mudança iniciada
A vinculação de uma Infrastructure Change Request à Problem Investigation. Isso sinaliza o início da fase de implementação.
Por que isso importa

É essencial para o KPI 'Root Cause to Change Lead Time' e para identificar silos entre os processos de Problem Management e Change Management.

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
Solução alternativa definida
A inserção ou atualização de texto no campo Workaround do registro de problema. Esse evento indica que uma solução temporária foi documentada.
Por que isso importa

Dá suporte ao KPI 'Workaround Publication Lead Time' e indica a mitigação do impacto do incidente.

Onde obter

Formulário PBM:Problem Investigation, alterações no campo de texto 'Workaround'.

Captura

Comparar o conteúdo do campo 'Workaround' para identificar atualizações não nulas

Tipo de evento inferred
Banco de soluções atualizado
A transição do registro para o status 'Solution Database', indicando que uma correção permanente foi proposta ou identificada.
Por que isso importa

Acompanha o avanço da definição da solução antes da implementação.

Onde obter

Formulário PBM:Problem Investigation, campo 'Status' = 'Solution Database'.

Captura

Comparar o campo de status para identificar a transição para Solution Database

Tipo de evento inferred
Coordenador reatribuído
Uma alteração no Problem Coordinator individual dentro de um grupo de suporte. Capturada monitorando o campo 'Problem Coordinator'.
Por que isso importa

Ajuda a analisar a distribuição da carga de trabalho e os gargalos de recursos individuais.

Onde obter

Formulário PBM:Problem Investigation, histórico do campo 'Problem Coordinator'.

Captura

Comparar o campo 'Problem Coordinator' antes e depois da atualização

Tipo de evento inferred
Erro conhecido promovido
A criação de um registro de Known Error vinculado à investigação do problema. Esse é um evento de criação de registro relacionado.
Por que isso importa

Indica a formalização do problema para comunicação mais ampla e acompanhamento de longo prazo.

Onde obter

Criação de um registro em PBM:Known Error vinculado ao ID de PBM:Problem Investigation.

Captura

Registrado quando o registro 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 encerramento de uma Task de PIR vinculada.
Por que isso importa

Dá suporte direto a 'Post Implementation Review Compliance' e às auditorias de qualidade do processo.

Onde obter

Formulário PBM:Problem Investigation, sinalizador específico 'PIR Required' ou conclusão de uma Task vinculada do tipo 'PIR'.

Captura

Derivado da conclusão do status de PIR ou do encerramento da Task de PIR

Tipo de evento inferred
Recomendado Opcional

Guias de extração

Como extrair seus dados de gestão de problemas do BMC Helix ITSM

Pronto para começar?

Transforme a estabilidade dos seus serviços aplicando hoje este Template aos seus dados do BMC Helix ITSM. Nossa equipe está à disposição para ajudar se você tiver dúvidas sobre a configuração.

Elimine hoje os gargalos da gestão de problemas

Reduza os tempos de ciclo em 30% e melhore a estabilidade dos serviços.

Comece seu teste grátis

Não é necessário cartão de crédito. Configure em poucos minutos.