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
- Atributos recomendados para coletar
- Atividades-chave a monitorizar
- Guia de extração para BMC Helix ITSM
Atributos de Gestão de Solicitações de Serviço
| 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
|
|||
Atividades de Gestão de Solicitações de Serviço
| 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
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
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
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
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
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
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
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
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
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
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
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
|
|||