Seu template de dados para Gestão de Solicitações de Serviço

BMC Helix ITSM
Seu template de dados para Gestão de Solicitações de Serviço

Seu template de dados para Gestão de Solicitações de Serviço

Este template oferece uma visão clara dos atributos de dados essenciais e das principais atividades a serem rastreadas na gestão de solicitações. Também inclui orientações práticas sobre como extrair esses dados com eficiência do BMC Helix ITSM. Use este recurso para agilizar sua preparação de dados e iniciar suas iniciativas de Process Mining com confiança.
  • Atributos recomendados para coletar
  • Atividades-chave a monitorizar
  • Guia de extração para BMC Helix ITSM
É novo em event logs? Saiba como criar um event log para Process Mining.

Atributos de Gestão de Solicitações de Serviço

Estes campos de dados são essenciais para criar um Event Log abrangente, permitindo uma análise profunda do seu processo de gestão de solicitações.
5 Obrigatório 6 Recomendado 10 Opcional
Nome Descrição
Atividade
ActivityName
O nome do evento ou tarefa específica que ocorreu em um ponto no tempo dentro do ciclo de vida da solicitação de serviço.
Descrição

Este atributo descreve uma etapa específica ou mudança de status no processo, como 'Solicitação em Revisão', 'Atendimento em Andamento' ou 'Solicitação de Serviço Resolvida'. Cada atividade representa um único evento na jornada de ponta a ponta.

Analisar a sequência e frequência das atividades é o núcleo do Process Mining. Isso permite a descoberta de mapas de processos, identificação de gargalos e análise de variantes. Entender quais atividades ocorrem, em que ordem e com que frequência é crucial para a otimização do processo.

Por que é importante

As atividades formam os blocos de construção do mapa de processos. Rastreá-las permite visualizar e analisar o fluxo do processo, revelando como o trabalho é realmente realizado.

Onde obter

Isso costuma ser derivado de mudanças nos campos 'Status' e 'Motivo do Status' no formulário 'SRM:Request' ou logs de atendimento relacionados (ex: Incidente, Ordem de Trabalho).

Exemplos
Solicitação aguardando aprovaçãoAtendimento em AndamentoSolicitação de Serviço ResolvidaSolicitação de Serviço Encerrada
Hora de Início
EventStartTime
O `timestamp` indicando quando uma atividade ou evento específico começou.
Descrição

Este atributo registra a data e hora exatas em que uma atividade começou. Cada evento, do envio inicial ao encerramento final, deve ter um tempo de início para estabelecer a sequência cronológica.

Este timestamp é crítico para todas as análises temporais de Process Mining. É usado para calcular tempos de ciclo, durações de atividades, tempos de espera e conformidade de SLA. Ele possibilita a descoberta de gargalos e a análise de desempenho do processo ao longo do tempo.

Por que é importante

O start time fornece a ordem cronológica dos eventos, o que é essencial para calcular as durações do processo, identificar atrasos e entender a linha do tempo.

Onde obter

Isso corresponde aos campos de timestamp nos logs de auditoria ou tabelas de histórico de status associadas ao formulário 'SRM:Request', como a 'Data de Envio' para o evento inicial.

Exemplos
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
ID da Solicitação de Serviço
ServiceRequestId
O identificador exclusivo para cada solicitação de serviço, servindo como a chave primária para rastrear todo o ciclo de vida.
Descrição

O ID da Solicitação de Serviço identifica de forma exclusiva cada solicitação enviada por um usuário ou sistema. Ele serve como o fio condutor que vincula todos os eventos subsequentes, desde o registro inicial até o encerramento final, permitindo uma análise completa de ponta a ponta da jornada de cada solicitação.

No Process Mining, este ID é essencial para reconstruir a sequência de atividades de cada case. Ele permite que a ferramenta agrupe todos os eventos relacionados, como 'Solicitação Enviada', 'Solicitação Atribuída' e 'Solicitação de Serviço Encerrada', em uma única instância de processo, formando a base para toda a análise.

Por que é importante

Este é o identificador fundamental do case. Sem ele, é impossível rastrear a jornada de ponta a ponta, tornando a descoberta e a análise de processos impossíveis.

Onde obter

Este é geralmente o campo 'InstanceId' ou 'Número da Solicitação' no formulário 'SRM:Request' no BMC Helix ITSM.

Exemplos
SR000010572931SR000010572932SR000010572933
Sistema de Origem
SourceSystem
Identifica o sistema do qual os dados foram extraídos.
Descrição

Este atributo especifica a origem dos dados do processo. Para esta visualização, ele seria definido como 'BMC Helix ITSM'.

Em ambientes com múltiplos sistemas integrados, este campo é crucial para entender a linhagem dos dados e particioná-los com base na fonte. Isso garante clareza e rastreabilidade, especialmente ao mesclar dados de diferentes plataformas.

Por que é importante

Fornece contexto sobre a origem dos dados, importante para governança, rastreabilidade e resolução de problemas em ambientes com múltiplos sistemas.

Onde obter

Este é um valor estático adicionado durante o processo de extração e transformação de dados, não um campo dentro do próprio BMC Helix ITSM.

Exemplos
BMC Helix ITSM
Última Atualização de Dados
LastDataUpdate
O timestamp de quando os dados deste processo foram atualizados pela última vez a partir do sistema de origem.
Descrição

Este atributo indica a data e hora da extração de dados mais recente do BMC Helix ITSM. Ele fornece contexto sobre a atualidade dos dados, garantindo que os usuários saibam o período coberto pela análise.

Este é um metadado crítico para qualquer dashboard de Process Mining. Ele permite que os usuários entendam se os insights são baseados em dados quase em tempo real ou em um retrato histórico, o que afeta a validade e a relevância das conclusões.

Por que é importante

Informa os usuários sobre o quão recentes são os dados, essencial para tomar decisões baseadas na performance mais atualizada do processo.

Onde obter

Este timestamp é gerado e adicionado durante o processo de extração e carregamento de dados.

Exemplos
2024-05-21T08:00:00Z
Agente atribuído
AssignedAgent
O usuário individual atualmente atribuído para trabalhar na solicitação de serviço.
Descrição

Este atributo identifica o agente de TI ou membro da equipe de suporte específico responsável pela solicitação em um determinado momento. Mudanças neste campo indicam uma transferência ou reatribuição.

Este atributo é crucial para a análise de desempenho e carga de trabalho. Ele permite rastrear quantas solicitações cada agente trata, seu tempo médio de resolução e a frequência de reatribuições. Esses dados apoiam a gestão de recursos e a identificação de oportunidades de treinamento.

Por que é importante

Rastrear o agente atribuído é essencial para analisar transferências, medir o desempenho individual e entender a distribuição de carga na equipe de suporte.

Onde obter

Isso corresponde ao campo 'Responsável' ou 'Atribuído a' no registro de atendimento (ex: Ordem de Trabalho, Incidente) associado à solicitação de serviço.

Exemplos
Bob SmithAlice JohnsonCharlie Brown
End Time
EventEndTime
O timestamp que indica quando uma atividade ou evento específico foi concluído.
Descrição

O End Time marca a conclusão de uma atividade. Embora muitas atividades em sistemas de ITSM sejam mudanças de status instantâneas, algumas possuem uma duração mensurável. Ter um End Time permite o cálculo preciso da duração dessas atividades.

Na análise, o End Time é usado em conjunto com o Start Time para calcular o tempo de processamento de atividades individuais. Isso ajuda a identificar quais tarefas específicas, e não apenas o tempo de espera entre elas, estão consumindo mais tempo no processo.

Por que é importante

Permite o cálculo dos tempos de processamento das atividades, fundamental para identificar etapas ineficientes e entender onde os recursos investem seu tempo.

Onde obter

Isto pode ser derivado. O End Time de uma atividade costuma ser o Start Time da próxima atividade sequencial para o mesmo case. Para a atividade final, seria o timestamp de resolução ou fechamento.

Exemplos
2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
Equipe designada
AssignedTeam
O grupo de suporte ou equipe atualmente atribuída à solicitação de serviço.
Descrição

Este atributo identifica o grupo funcional responsável por tratar a solicitação, como 'Help Desk', 'Equipe de Rede' ou 'Administração de Banco de Dados'. Uma alteração neste campo significa uma transferência de responsabilidade entre equipes.

A análise baseada na equipe atribuída ajuda a identificar gargalos no nível do time, analisar transferências entre equipes e avaliar a eficiência de diferentes grupos. É fundamental para os dashboards de Retrabalho e Reatribuição e de Eficiência de Triagem, revelando padrões de como o trabalho é roteado na organização.

Por que é importante

Possibilita a análise do fluxo entre diferentes grupos funcionais, ajudando a identificar ineficiências de roteamento e medir o desempenho por equipe.

Onde obter

Isso corresponde ao campo 'Grupo Atribuído' no registro de atendimento (ex: Ordem de Trabalho, Incidente) associado à solicitação de serviço.

Exemplos
Service DeskSuporte de InfraestruturaSuporte a Aplicações Nível 2
Prioridade
Priority
O nível de prioridade atribuído à solicitação de serviço, indicando seu impacto no negócio e urgência.
Descrição

A Prioridade define a ordem e velocidade de tratamento dos pedidos. Valores comuns incluem 'Crítica', 'Alta', 'Média' e 'Baixa', baseados no impacto e urgência.

Analisar por prioridade é essencial para checar se pedidos críticos são processados mais rápido que os de baixa prioridade. É uma dimensão chave nos Dashboards de tempo de resolução e SLA, garantindo que os recursos foquem nas necessidades de negócio mais vitais.

Por que é importante

Ajuda a avaliar se o processo prioriza o trabalho corretamente e atende aos níveis de serviço para pedidos com diferentes níveis de impacto no negócio.

Onde obter

Este é o campo 'Prioridade' no formulário 'SRM:Request'.

Exemplos
CríticoAltoMédioBaixo
Status da Solicitação
RequestStatus
O status da solicitação de serviço no momento do evento, como 'Em Andamento', 'Pendente' ou 'Fechado'.
Descrição

Este atributo captura o estado da solicitação de serviço em diferentes pontos do seu ciclo de vida. O status fornece contexto para cada atividade e costuma ser a fonte da qual o próprio atributo 'Atividade' é derivado.

Analisar por status ajuda a entender quanto tempo as solicitações passam em determinados estados, como 'Pendente com Cliente' ou 'Aguardando Aprovação'. Isso é essencial para identificar gargalos e atrasos causados por dependências externas ou filas internas, alimentando diretamente o dashboard de Identificação de Gargalos.

Por que é importante

Oferece um retrato do estado do pedido, permitindo analisar o tempo em espera versus tempo ativo, chave para identificar gargalos.

Onde obter

Este é o campo 'Status' no formulário 'SRM:Request'. Valores históricos podem ser encontrados no log de auditoria.

Exemplos
PlanejamentoEm ProgressoPendenteResolvidoEncerrado
Tipo de Serviço
ServiceType
A categoria ou tipo de serviço que está sendo solicitado pelo usuário.
Descrição

O Tipo de Serviço classifica a natureza da solicitação, por exemplo, 'Solicitar Novo Software', 'Redefinição de Senha' ou 'Onboarding de Novo Funcionário'. É uma dimensão fundamental para filtrar e segmentar os dados do processo.

Na análise de processos, este atributo é usado para comparar o desempenho de diferentes tipos de solicitações. Ajuda a responder perguntas como: 'Quais tipos de serviço demoram mais para serem resolvidos?' ou 'Quais tipos têm mais retrabalho?'. Isso é crítico para os dashboards de Tempo de Resolução e Conformidade de SLA.

Por que é importante

Permite segmentar as solicitações para comparar fluxos, identificar problemas específicos de cada tipo e direcionar esforços de otimização com eficácia.

Onde obter

Esses dados costumam ser encontrados no 'Título' ou em um campo de categorização no formulário 'SRM:Request', derivados do serviço selecionado no catálogo.

Exemplos
Novo Pedido de HardwareSolicitação de acesso a softwareConfiguração de acesso VPN
Canal de Submissão
SubmissionChannel
O método ou canal pelo qual a solicitação de serviço foi enviada.
Descrição

Este atributo registra como a solicitação foi iniciada: via portal de self-service, e-mail, telefone ou alerta automatizado. Diferentes canais podem levar a variantes de processo e tempos de resolução distintos.

Analisar o processo pelo canal de entrada pode revelar ineficiências ou melhores práticas associadas a métodos específicos. Por exemplo, solicitações via portal podem ser resolvidas mais rápido devido à melhor qualidade inicial dos dados, enquanto as de e-mail podem exigir mais triagem manual.

Por que é importante

Auxilia na compreensão de como o canal de entrada afeta a eficiência, a qualidade dos dados e o tempo de ciclo, permitindo melhorias focadas em canais específicos.

Onde obter

Isso geralmente pode ser inferido de campos como 'Tipo de Cliente' ou 'Fonte Relatada' no formulário 'SRM:Request' ou tickets de atendimento associados.

Exemplos
Portal de autoatendimentoEmailTelefoneGerado pelo Sistema
Categoria de resolução
ResolutionCategory
A classificação da solução fornecida para resolver a solicitação.
Descrição

Este atributo fornece uma categorização estruturada de como uma solicitação foi resolvida, como 'Correção de Software', 'Treinamento de Usuário' ou 'Correção de Dados'. Ele vai além de um simples código de fechamento para descrever a natureza da resolução.

Isso é essencial para o dashboard de Precisão da Categoria de Resolução, onde pode ser comparado ao tipo de serviço inicial para verificar a consistência. Analisar categorias de resolução ajuda a identificar tendências e informa a gestão proativa de problemas, como quando muitas solicitações são resolvidas via treinamento.

Por que é importante

Oferece insights sobre o tipo de solução aplicada, ajudando a identificar tendências em problemas recorrentes e oportunidades para gestão proativa de problemas.

Onde obter

Esta informação faz parte dos campos de categorização operacional e de produto no ticket de atendimento, frequentemente rotulada como 'Categoria de Resolução'.

Exemplos
Administração de ContasFalha de hardwareAtualização de SoftwareInformação Fornecida
Código de Encerramento
CloseCode
Um código indicando o resultado final ou o motivo do encerramento da solicitação de serviço.
Descrição

O Código de Fechamento fornece uma forma padronizada de classificar a resolução de uma solicitação de serviço. Exemplos incluem 'Resolvido pelo Service Desk', 'Cancelado pelo Usuário' ou 'Solicitação Duplicada'.

Analisar os códigos de fechamento ajuda a entender os resultados comuns das solicitações. Pode destacar problemas como um alto número de solicitações canceladas pelos usuários, o que pode indicar um processo demorado, ou muitas duplicatas, o que poderia apontar para um problema de sistema ou comunicação. Este atributo alimenta o dashboard de Precisão da Categoria de Resolução.

Por que é importante

Fornece dados estruturados sobre o desfecho dos pedidos, permitindo analisar a eficácia da resolução e os motivos de cancelamento.

Onde obter

Esta informação é geralmente encontrada em um campo de 'Resolução' ou 'Código de Fechamento' no ticket de atendimento associado à solicitação.

Exemplos
Bem-sucedidaCancelado pelo UsuárioNão é mais necessárioResolução Automatizada
Data Alvo do SLA
SlaTargetDate
A data e hora em que se espera que a solicitação de serviço seja resolvida, de acordo com seu Acordo de Nível de Serviço (SLA).
Descrição

A Data Limite do SLA é um timestamp calculado que representa o prazo para a conclusão da solicitação de serviço. Ela é determinada pelas regras do acordo de serviço, que geralmente levam em conta fatores como a prioridade e o tipo da solicitação.

Este atributo é fundamental para o dashboard de Visão Geral de Conformidade de SLA. Ele serve como a referência em relação à qual o tempo real de resolução é medido. Ao comparar o 'EventEndTime' da atividade de resolução final com esta data limite, podemos determinar se o compromisso de serviço foi cumprido.

Por que é importante

Esta é a principal referência para medir o desempenho do serviço em relação aos compromissos, sendo essencial para o monitoramento e relatórios de conformidade de SLA.

Onde obter

Esta data é calculada e armazenada pelo módulo de Gestão de Nível de Serviço (SLM) e pode ser encontrada em formulários SLM relacionados vinculados à solicitação.

Exemplos
2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
Departamento do solicitante
RequestorDepartment
O departamento ou unidade de negócio do usuário que enviou a solicitação.
Descrição

Este atributo identifica o departamento organizacional da pessoa que solicita o serviço, como 'Financeiro', 'Recursos Humanos' ou 'TI'. Essas informações geralmente vêm do perfil do usuário no sistema.

Segmentar a análise do processo por departamento permite identificar necessidades específicas, padrões de solicitação e áreas para treinamento focado ou melhorias de serviço. Ajuda a responder perguntas como: 'O departamento financeiro enfrenta tempos de espera maiores em suas solicitações?'.

Por que é importante

Viabiliza a análise do consumo de serviços e performance por unidade de negócio, destacando tendências ou problemas específicos de cada departamento.

Onde obter

Esta informação é geralmente recuperada do perfil do usuário associado ao campo 'Solicitado para' no formulário 'SRM:Request'.

Exemplos
FinançasVendasRecursos HumanosTecnologia da Informação
É Retrabalho
IsRework
Um sinalizador booleano indicando se uma solicitação de serviço passou por retrabalho, como retornar a uma etapa anterior.
Descrição

Esta flag identifica solicitações que passaram por um loop ou retrabalho. Por exemplo, uma solicitação que volta de 'Atendimento em Andamento' para 'Solicitação em Revisão'.

Este atributo alimenta o dashboard de Análise de Retrabalho e Reatribuição e o KPI de Taxa de Retrabalho. Ele permite quantificar a frequência de retrabalho e analisar causas comuns, como avaliações iniciais incorretas ou informações incompletas, que levam a ineficiências.

Por que é importante

Quantifica a ineficiência sinalizando casos que se desviam do 'fluxo ideal', ajudando a identificar causas raiz de loops e retrabalho.

Onde obter

Este é um atributo calculado derivado da sequência de atividades no Event Log. É necessária lógica para detectar movimentos retrocessos no fluxo do processo.

Exemplos
verdadeirofalse
Escalado
IsEscalated
Um sinalizador booleano que indica se a solicitação de serviço foi escalonada.
Descrição

Esta flag é 'true' se a solicitação sofreu um escalonamento funcional ou hierárquico. O escalonamento ocorre quando uma solicitação não progride como esperado, está prestes a violar o SLA ou requer aprovação superior.

Este atributo é fundamental para o dashboard de Análise de Eficiência de Escalonamento. Ele permite filtrar e analisar os caminhos das solicitações escaladas para entender seus gatilhos, o tempo de resolução pós-escalonamento e a eficácia do processo.

Por que é importante

Permite isolar e analisar o subconjunto de pedidos que exigiram escalonamento, ajudando a identificar fraquezas no processo padrão ou gatilhos para problemas complexos.

Onde obter

Geralmente não é um campo único. É derivado da verificação de atividades específicas de escalonamento no log de auditoria ou mudanças de prioridade que seguem um protocolo.

Exemplos
verdadeirofalse
Número de transferências
HandoffCount
O número total de vezes que uma solicitação de serviço foi reatribuída entre diferentes agentes ou equipes.
Descrição

Esta métrica calculada conta quantas vezes o 'AgenteAtribuído' ou a 'EquipeAtribuída' mudam em uma única solicitação. Um alto número de transferências pode indicar fragmentação do processo ou roteamento ineficiente.

Este atributo é a base para o KPI de Média de Transferências por Solicitação e é usado no dashboard de Retrabalho e Reatribuição. Analisar casos com muitas transferências ajuda a identificar oportunidades para melhorar a triagem, fornecer treinamentos ou simplificar a resolução para reduzir atrasos.

Por que é importante

Mede a fragmentação do processo e a carga de comunicação. Um alto número de transferências costuma estar correlacionado a tempos de resolução maiores e menor eficiência.

Onde obter

Esta é uma métrica calculada obtida pela contagem de valores distintos no atributo 'AgenteAtribuído' ou 'EquipeAtribuída' para cada ID de solicitação exclusivo.

Exemplos
0135
SLA violado
IsSlaBreached
Um sinalizador booleano indicando se a solicitação de serviço foi resolvida após a data limite do SLA.
Descrição

Esta flag calculada é definida como 'true' se o timestamp de resolução final for posterior à 'Data Limite do SLA'. Fornece um resultado binário simples para o desempenho do SLA por solicitação.

Este atributo é essencial para o dashboard de Visão Geral de Conformidade de SLA e o KPI de Taxa de Aderência ao SLA. Ele permite agregar taxas de conformidade globais e filtrar solicitações fora do prazo para analisar as causas raiz das falhas de SLA.

Por que é importante

Simplifica a análise de performance do SLA convertendo a comparação de horários em um sinalizador booleano, facilitando a visualização das taxas de conformidade.

Onde obter

Este é um campo calculado. A lógica é: SE 'Timestamp de Resolução' > 'DataLimiteSLA' ENTÃO true SENÃO false.

Exemplos
verdadeirofalse
Tempo de Ciclo
CycleTime
O tempo total decorrido desde a criação da solicitação de serviço até sua resolução final.
Descrição

Cycle Time, também conhecido como duração de ponta a ponta, mede a vida total de uma solicitação de serviço. É calculado pela diferença entre o timestamp do primeiro evento (ex: 'Solicitação Submetida') e o último evento de resolução (ex: 'Solicitação Resolvida').

Este é um dos KPIs mais fundamentais no Process Mining, alimentando diretamente o Dashboard de Tempo de Resolução. Analisar o tempo de ciclo médio e filtrá-lo por dimensões como tipo de serviço ou prioridade revela a eficiência global e destaca as áreas mais lentas.

Por que é importante

Esta é uma medida primária de eficiência do processo. Entender e reduzir o tempo de ciclo é frequentemente um objetivo central de iniciativas de melhoria.

Onde obter

Esta é uma métrica calculada. Ela é derivada subtraindo a 'Data de Envio' da 'Data de Fechamento' ou 'Data de Resolução' para cada ID de solicitação exclusivo.

Exemplos
2 dias 4 horas8 horas e 30 minutos15 dias
Obrigatório Recomendado Opcional

Atividades de Gestão de Solicitações de Serviço

Estas etapas e marcos principais do processo devem ser capturados no seu Event Log para uma descoberta e visualização precisas do processo.
6 Recomendado 8 Opcional
Atividade Descrição
Atendimento em Andamento
O agente ou equipe atribuída começou a trabalhar ativamente no atendimento da solicitação de serviço. Isso indica que a solicitação saiu de uma fila para um estado de trabalho ativo.
Por que é importante

Marca o início do trabalho de atendimento que gera valor. Analisar o tempo nesta fase ajuda a entender a produtividade e a complexidade do atendimento.

Onde obter

Inferido de uma mudança de status no formulário SRM:Request para 'In Progress'.

Captura

Timestamp do evento de atualização onde o campo 'Status' do SRM:Request muda para 'Em Andamento'.

Tipo de evento inferred
Solicitação Atribuída
A solicitação de serviço foi atribuída a um agente ou equipe específica responsável pela conclusão do trabalho. Isso marca o fim da fase de triagem.
Por que é importante

Este marco é crítico para medir o tempo de triagem e analisar a carga de trabalho. Reatribuições frequentes podem indicar problemas de roteamento ou gaps de habilidades.

Onde obter

Este evento pode ser capturado explicitamente no log de auditoria dos campos 'Grupo Atribuído' ou 'Responsável' no SRM:Request ou formulários relacionados (ex: WOI:WorkOrder).

Captura

Timestamp do log de auditoria que mostra um valor não nulo sendo definido no campo 'Responsável' pela primeira vez.

Tipo de evento explicit
Solicitação de serviço cancelada
A solicitação de serviço foi retirada pelo solicitante ou pelo service desk antes da conclusão do atendimento. Este é um estado terminal para a solicitação.
Por que é importante

Rastrear cancelamentos ajuda a identificar padrões, como usuários enviando solicitações incorretas ou serviços que não são mais necessários, o que pode orientar melhorias no catálogo de serviços.

Onde obter

Inferido de uma mudança de status no formulário SRM:Request para 'Canceled'.

Captura

Timestamp do evento de atualização onde o campo 'Status' do SRM:Request muda para 'Cancelado'.

Tipo de evento inferred
Solicitação de Serviço Encerrada
A solicitação de serviço está formalmente encerrada e movida para um estado de arquivo apenas para leitura. Isso ocorre após a resolução e o término de qualquer período de confirmação.
Por que é importante

Esta atividade representa o fim definitivo do processo. O tempo entre 'Resolvido' e 'Fechado' pode destacar ineficiências no procedimento de encerramento.

Onde obter

Inferido da mudança de status final no formulário SRM:Request para 'Closed'.

Captura

Timestamp do evento de atualização onde o campo 'Status' do SRM:Request muda para 'Fechado'.

Tipo de evento inferred
Solicitação de serviço enviada
Esta atividade marca a criação e o envio de uma nova solicitação de serviço por um usuário. Ela é capturada quando uma nova entrada é criada no formulário SRM:Request com um status inicial, geralmente 'Enviado'.
Por que é importante

Este é o ponto de partida para todo case de solicitação, essencial para medir a duração total do ciclo de vida e analisar os volumes de entrada.

Onde obter

Este evento é inferido do timestamp de criação e do status inicial (ex: 'Enviado') de um registro no formulário SRM:Request.

Captura

Identifique o timestamp de criação para um novo ID de Solicitação no formulário SRM:Request quando o status for 'Submitted'.

Tipo de evento inferred
Solicitação de Serviço Resolvida
O atendimento da solicitação de serviço foi concluído e a resolução foi comunicada ao solicitante. A solicitação aguarda confirmação final ou será fechada automaticamente após um período definido.
Por que é importante

Um marco crítico que define o fim do ciclo de entrega do serviço. É o ponto principal para medir o tempo de resolução e a aderência ao SLA.

Onde obter

Inferido de uma mudança de status no formulário SRM:Request para 'Resolved' ou 'Completed'.

Captura

Timestamp do evento de atualização onde o campo 'Status' do SRM:Request muda para 'Resolvido' ou 'Concluído'.

Tipo de evento inferred
Informação Solicitada ao Usuário
O agente de atendimento precisa de informações adicionais do solicitante para prosseguir com o trabalho. A solicitação é geralmente colocada em estado 'Pendente'.
Por que é importante

Esta atividade é crucial para calcular o 'Tempo de Espera por Informação Externa', identificando com que frequência as solicitações param devido a informações incompletas.

Onde obter

Inferido de uma mudança de status no formulário SRM:Request para 'Pending' com um motivo como 'Customer Hold' ou 'Awaiting Information'.

Captura

Timestamp da mudança de status para 'Pendente' combinada com um motivo de status específico.

Tipo de evento inferred
Requisição Rejeitada
A solicitação de serviço foi negada durante uma fase de aprovação. Este é um estado terminal que interrompe o processo antes que o atendimento comece.
Por que é importante

Analisar solicitações rejeitadas pode destacar problemas em justificativas, critérios de elegibilidade ou políticas de aprovação.

Onde obter

Inferido de uma mudança de status no formulário SRM:Request para 'Rejected'.

Captura

Timestamp do evento de atualização onde o campo 'Status' do SRM:Request muda para 'Rejeitado'.

Tipo de evento inferred
Resolução confirmada pelo usuário
O solicitante confirmou ativamente que o serviço foi entregue de forma satisfatória e a solicitação está resolvida. Isso geralmente aciona o fechamento final da solicitação.
Por que é importante

Fornece um indicador claro da satisfação do cliente e encerra formalmente a interação de serviço. Ele separa a resolução do processo da aceitação do cliente.

Onde obter

Este evento pode ser capturado nos logs de trabalho ou notas de atividade do SRM:Request quando um usuário confirma via portal ou e-mail. Nem sempre é um status discreto.

Captura

Analise os logs de trabalho (SRM:WorkInfo) para entradas específicas que indicam confirmação do usuário ou conclusão de pesquisa.

Tipo de evento explicit
Solicitação aguardando aprovação
A solicitação de serviço foi enviada a um aprovador ou grupo de aprovação designado e aguarda uma decisão antes que o atendimento comece. Este é um passo comum para solicitações que envolvem custos ou direitos de acesso.
Por que é importante

Esta atividade isola atrasos relacionados a aprovações, permitindo a análise dos tempos de ciclo de aprovação e a identificação de gargalos na cadeia de aprovação.

Onde obter

Inferido de uma mudança de status no formulário SRM:Request para um valor como 'Waiting Approval'.

Captura

Timestamp do evento de atualização onde o campo 'Status' do SRM:Request muda para 'Aguardando Aprovação'.

Tipo de evento inferred
Solicitação aprovada
A solicitação de serviço foi formalmente aprovada pela parte responsável, permitindo que o processo de atendimento prossiga. Este evento geralmente segue o status 'Aguardando Aprovação'.
Por que é importante

Marca o fim do sub-processo de aprovação e é um marco importante para rastrear quanto tempo as aprovações levam e seu impacto no tempo total.

Onde obter

Inferido de uma mudança de status no formulário SRM:Request de 'Waiting Approval' para um status subsequente como 'Planning' ou 'In Progress'. A decisão de aprovação em si é registrada nos formulários de aprovação relacionados.

Captura

Timestamp da mudança de status saindo de 'Aguardando Aprovação' após uma decisão positiva.

Tipo de evento inferred
Solicitação em revisão
A solicitação de serviço está passando por revisão inicial e triagem pelo service desk para determinar sua natureza, prioridade e a equipe de atendimento adequada. Isso geralmente é representado por uma mudança de status no registro da solicitação.
Por que é importante

Rastrear esta atividade ajuda a medir a eficiência da triagem e identifica atrasos entre o envio e a atribuição, o que é crucial para o KPI de 'Tempo Médio de Triagem'.

Onde obter

Inferido de uma mudança de status no formulário SRM:Request para um valor como 'In Review' ou 'Planning'.

Captura

Timestamp do evento de atualização onde o campo 'Status' do SRM:Request muda para 'Em Revisão'.

Tipo de evento inferred
Solicitação Retomada
A solicitação de serviço saiu de um estado pendente ou de espera, geralmente após as informações necessárias terem sido fornecidas pelo usuário. O trabalho na solicitação é retomado pelo agente de atendimento.
Por que é importante

Marca o fim de um período de espera, permitindo medir com precisão os tempos externos e seu impacto no cumprimento do SLA.

Onde obter

Inferido quando o status do SRM:Request muda de 'Pending' de volta para 'In Progress'.

Captura

Timestamp do evento de atualização onde o campo 'Status' do SRM:Request muda de 'Pendente' para 'Em Andamento'.

Tipo de evento inferred
Solução Implementada
O trabalho técnico necessário para atender à solicitação de serviço foi concluído pelo agente. A solicitação está agora pronta para confirmação com o usuário antes de ser formalmente resolvida.
Por que é importante

Esta atividade separa a conclusão técnica da resolução formal, ajudando a identificar quaisquer atrasos entre a conclusão do trabalho e a confirmação do usuário.

Onde obter

Isso pode ser inferido de uma mudança de status em um ticket de atendimento (ex: status da Ordem de Trabalho para 'Concluído') antes que o SRM:Request pai seja marcado como 'Resolvido'.

Captura

Timestamp de quando um ticket de atendimento (Ordem de Trabalho, Incidente, etc.) vinculado ao SRM:Request é marcado como concluído.

Tipo de evento inferred
Recomendado Opcional

Guias de Extração

Como obter seus dados do BMC Helix ITSM