Seu Template de Dados para Gestão de Solicitações
Seu Template de Dados para Gestão de Solicitações
- Atributos recomendados para coletar
- Principais atividades para monitorar na descoberta de processos
- Orientação passo a passo para extração de dados
Atributos da Gestão de Solicitações de Serviço
| Nome | Descrição | ||
|---|---|---|---|
|
Atividade
ActivityName
|
O nome do evento ou tarefa específica que ocorreu no ciclo de vida da solicitação de serviço. | ||
|
Descrição
O atributo Atividade registra o nome de cada passo ou mudança de status no processo. Pode incluir eventos como "Solicitação criada", "Aprovada", "Atribuída ao agente" ou "Fechada".\n\nAnalisar essas atividades permite visualizar o fluxo real, identificar caminhos comuns e detectar desvios do padrão. É a base para entender o que realmente acontece durante o atendimento de um pedido.
Por que é importante
Atributo obrigatório que define os passos no mapa do processo. É a base de toda a análise, permitindo achar gargalos, loops de retrabalho e falhas de conformidade.
Onde obter
Derivado de mudanças nos campos 'State' ou 'Stage' das tabelas 'sc_request'/'sc_req_item' ou da trilha de auditoria (sys_audit).
Exemplos
Solicitação de Serviço CriadaSolicitação atribuída ao grupoSolicitação de Serviço ResolvidaInformação solicitada ao usuário
|
|||
|
Hora de Início
EventTime
|
O timestamp indicando quando uma atividade ou evento começou. | ||
|
Descrição
Este atributo registra a data e hora exatas de cada atividade. Ele fornece a sequência cronológica para montar o mapa do processo e fazer análises de tempo.\n\nTimestamps precisos são vitais para calcular tempos de ciclo, espera e processamento. Esses dados permitem achar gargalos, violações de SLA e tendências de desempenho ao longo do tempo.
Por que é importante
Timestamp obrigatório para ordenar os eventos. É a base de todas as análises de desempenho e duração, como tempo de ciclo e identificação de gargalos.
Onde obter
Geralmente encontrado nos campos "sys_updated_on" ou "sys_created_on" das tabelas do ServiceNow (ex: sc_request, sc_task) ou na trilha de auditoria (sys_audit).
Exemplos
2023-04-15T10:00:00Z2023-04-15T11:30:15Z2023-04-16T09:05:45Z
|
|||
|
ID da Solicitação de Serviço
ServiceRequestID
|
O identificador exclusivo de cada registro de solicitação de serviço. | ||
|
Descrição
O ID da Solicitação é a chave única que identifica cada pedido feito por um usuário ou sistema. Ele conecta todos os eventos, do registro inicial ao fechamento. No Process Mining, este ID é essencial para reconstruir toda a jornada de cada solicitação, permitindo uma análise completa do seu ciclo de vida.
Por que é importante
Este é o ID do Caso obrigatório. Ele une todas as atividades em uma única instância, permitindo analisar fluxos, variações e tempos de ciclo.
Onde obter
Tabela de Solicitação [sc_request], campo "number".
Exemplos
REQ0010001REQ0010025REQ0010112
|
|||
|
Sistema de Origem
SourceSystem
|
O sistema de onde os dados se originaram. | ||
|
Descrição
Este atributo identifica o sistema de origem dos dados, que neste caso é o ServiceNow. É útil quando dados de vários sistemas são mesclados para uma visão holística.\n\nEm análises de fonte única, ele fornece contexto importante para governança e gestão, garantindo que qualquer usuário saiba de onde vêm as informações analisadas.
Por que é importante
Fornece metadados essenciais para governança de dados, rastreabilidade e contexto, especialmente ao combinar informações de vários sistemas corporativos.
Onde obter
Este é tipicamente um valor estático adicionado durante o processo de extração e transformação de dados.
Exemplos
ServiceNow
|
|||
|
Última Atualização de Dados
LastDataUpdate
|
O timestamp da extração ou atualização de dados mais recente. | ||
|
Descrição
Indica quando os dados foram extraídos e carregados na ferramenta de Process Mining, garantindo transparência sobre a atualidade das informações.\n\nOs analistas usam isso para saber se estão vendo dados recentes, o que é crucial para o monitoramento operacional e decisões em tempo real. Ajuda a alinhar expectativas sobre o quão atuais são os insights.
Por que é importante
Garante que os usuários saibam quão recentes são os dados, algo crucial para a confiança na análise e decisões rápidas.
Onde obter
Campo de metadados adicionado durante a ingestão, refletindo o horário de conclusão da tarefa de ETL.
Exemplos
2023-10-27T04:00:00Z
|
|||
|
Atribuído A
AssignedTo
|
O usuário individual responsável por trabalhar na solicitação em um dado momento. | ||
|
Descrição
Identifica o agente ou técnico atribuído à solicitação. Ele muda conforme o pedido passa por diferentes pessoas.\n\nAnalisar o campo "Assigned To" é vital para entender a carga de trabalho, o desempenho individual e como as transferências afetam o tempo de resolução. Ajuda a otimizar o uso de recursos e aponta necessidades de treinamento para reduzir reatribuições.
Por que é importante
Permite analisar a carga de trabalho, desempenho e transferências entre agentes. Vital para gestão de recursos.
Onde obter
Tabelas de Item de Solicitação [sc_req_item] ou Tarefa de Catálogo [sc_task], campo "assigned_to".
Exemplos
Beth AnglinDavid LooHoward Johnson
|
|||
|
Categoria
Category
|
A classificação principal do pedido, como Hardware ou Software. | ||
|
Descrição
A Categoria fornece uma classificação geral da solicitação. É usada para rotear o pedido para o time certo e para relatórios de volume. No Process Mining, a Categoria é uma ferramenta poderosa para análise dimensional. Ela permite comparar fluxos, tempos de ciclo e taxas de automação entre diferentes tipos de pedidos, revelando variações ocultas. Por exemplo: o fluxo de uma solicitação de 'Hardware' pode ser totalmente diferente de uma de 'Software'.
Por que é importante
Permite segmentar e comparar processos entre diferentes tipos de serviço, ajudando a identificar problemas específicos de cada categoria.
Onde obter
Tabela de Item de Solicitação [sc_req_item], geralmente através da categoria do Item de Catálogo [sc_cat_item] associado.
Exemplos
HardwareSoftwareSolicitação de AcessoRede
|
|||
|
Estado
State
|
O status operacional atual da solicitação de serviço. | ||
|
Descrição
O atributo Estado indica a fase atual do pedido (ex: Aberto, Em andamento, Pendente, Fechado). Mudanças neste campo geram as atividades do mapa de processo.\n\nAnalisar o Estado é crucial para entender quanto tempo os pedidos ficam parados, especialmente em espera. Isso ajuda a identificar filas e atrasos, como o tempo em "Aguardando Informações do Usuário", um motivo comum para ciclos demorados.
Por que é importante
Oferece visão sobre o status da solicitação a qualquer momento, permitindo analisar tempos de espera, filas e a duração de etapas específicas do processo.
Onde obter
Tabelas de Solicitação [sc_request] ou Item de Solicitação [sc_req_item], campo "state" ou "stage".
Exemplos
AbertoTrabalho em AndamentoAguardando informações do usuárioFechado Concluído
|
|||
|
Grupo de atribuição
AssignmentGroup
|
A equipe ou grupo responsável pelo atendimento da solicitação. | ||
|
Descrição
O Grupo de Atribuição representa a equipe (ex: Service Desk, Operações de Rede) responsável pelo pedido em uma fase específica. É um atributo essencial para analisar o fluxo entre diferentes áreas.\n\nAo rastrear mudanças no grupo, as empresas visualizam transferências (handoffs) entre times, medem o tempo de fila em cada backlog e identificam atrasos ou dependências entre equipes, o que é fundamental para a colaboração multifuncional.
Por que é importante
Acompanha a distribuição de trabalho, destaca transferências entre times e ajuda a achar gargalos ou problemas de desempenho em equipes específicas.
Onde obter
Tabelas de Item de Solicitação [sc_req_item] ou Tarefa de Catálogo [sc_task], campo "assignment_group".
Exemplos
Service DeskSuporte de TI L2Provisionamento de Hardware
|
|||
|
Prioridade
Priority
|
O nível de prioridade da solicitação de serviço, que influencia sua urgência. | ||
|
Descrição
A prioridade é uma classificação que define a importância e a urgência de uma solicitação. Geralmente baseada no impacto e na urgência, ela orienta os agentes sobre quais pedidos atender primeiro.\n\nAnalisar os dados por prioridade é fundamental para saber se as solicitações críticas estão sendo resolvidas mais rápido que as comuns. Isso permite filtrar os dashboards para verificar se os SLAs de pedidos urgentes estão sendo cumpridos e ajuda a validar se o sistema de priorização está funcionando como deveria.
Por que é importante
Permite segmentar solicitações para garantir que itens de alta prioridade sejam resolvidos primeiro. Essencial para análise de SLA.
Onde obter
Tabelas de Solicitação [sc_request] ou Item de Solicitação [sc_req_item], campo "priority".
Exemplos
1 - Crítico2 - Alto3 - Moderada4 - Baixo
|
|||
|
SLA cumprido
MadeSLA
|
Um campo booleano que indica se a solicitação foi resolvida dentro do prazo do SLA. | ||
|
Descrição
Indica se o pedido cumpriu o SLA de tempo de resolução. É uma métrica crítica de resultado que mede o desempenho frente aos compromissos assumidos.\n\nAnalisar este marcador ajuda a medir o KPI de Taxa de Adesão ao SLA. Serve para comparar os caminhos de pedidos que cumpriram o prazo versus os que atrasaram, revelando padrões que causam falhas. É essencial para monitorar riscos e melhorar o serviço continuamente.
Por que é importante
Mede o desempenho em relação aos compromissos de serviço e permite a análise de causa raiz de quebras de SLA.
Onde obter
Tabela Task SLA [task_sla] do ServiceNow, campo "has_breached". O valor precisa ser invertido (ex: MadeSLA = NOT has_breached).
Exemplos
verdadeirofalse
|
|||
|
Aberto por
OpenedBy
|
A pessoa que abriu inicialmente a solicitação de serviço. | ||
|
Descrição
Identifica quem criou a solicitação. Pode ser o próprio afetado, um gestor ou um sistema automático.\n\nAnalisar quem abriu o pedido ajuda a notar padrões, como departamentos que enviam muitos pedidos complexos. Isso pode orientar treinamentos específicos ou indicar a necessidade de melhorar a base de conhecimento para incentivar o autoatendimento.
Por que é importante
Auxilia na análise de padrões de solicitações por usuário ou departamento, orientando treinamentos e melhorias.
Onde obter
Tabela de Solicitação [sc_request], campo "opened_by".
Exemplos
Abel TuterFred LuddyDon Goodliffe
|
|||
|
Canal
ContactType
|
O método usado pelo solicitante para enviar o pedido de serviço. | ||
|
Descrição
O Tipo de Contato define como o pedido foi feito. Canais comuns incluem portal de serviços, e-mail, telefone ou alertas automáticos.\n\nEntender o canal é importante para analisar variações causadas pelo método de envio. Por exemplo, pedidos via portal tendem a ser mais estruturados e rápidos do que por e-mail. Essa análise ajuda a incentivar o uso dos canais mais eficientes.
Por que é importante
Ajuda a identificar como os diferentes canais de entrada afetam a eficiência e os tempos de ciclo.
Onde obter
Tabelas de Solicitação [sc_request] ou Interação [interaction] do ServiceNow. O campo geralmente se chama "contact_type".
Exemplos
PortalEmailTelefoneSelf-service
|
|||
|
Código de resolução
ResolutionCode
|
Um código que categoriza a resolução final da solicitação de serviço. | ||
|
Descrição
O Código de Resolução classifica como o pedido foi encerrado (ex: Atendido por Automação, Erro do Usuário). \n\nEste atributo é vital para o dashboard de Análise de Causa Raiz de Atrasos. Ao correlacionar códigos de resolução com tempos longos de ciclo ou altas taxas de retrabalho, os analistas acham problemas sistêmicos. Se pedidos com o código "Informação Incompleta" atrasam sempre, o problema está na coleta inicial de dados.
Por que é importante
Oferece dados estruturados sobre os resultados da resolução, permitindo a análise de causa raiz de atrasos, retrabalho e outras ineficiências.
Onde obter
Tabela de Item de Solicitação [sc_req_item] ou tarefa relacionada, o campo geralmente é "close_code" ou "resolution_code".
Exemplos
Resolvido (permanente)Não resolvido (não reproduzível)Solicitação atendidaCancelado pelo usuário
|
|||
|
Contagem de Reaberturas
ReopenCount
|
Quantas vezes o pedido foi reaberto após ter sido marcado como resolvido. | ||
|
Descrição
É um contador de quantas vezes um pedido resolvido voltou para o estado aberto ou em andamento. Qualquer valor acima de zero mostra que a primeira resolução falhou.\n\nÉ um indicador direto de retrabalho e essencial para o KPI de Taxa de Resolução de Primeira Tentativa. Números altos de reabertura sugerem má qualidade na solução ou erro de interpretação das necessidades do usuário, gerando ineficiência e insatisfação.
Por que é importante
Quantifica o retrabalho e a qualidade da resolução. Um número alto de reaberturas indica ineficiências, baixas taxas de acerto na primeira tentativa e queda na satisfação do cliente.
Onde obter
Tabelas de Solicitação [sc_request] ou Item de Solicitação [sc_req_item], campo "reopen_count".
Exemplos
012
|
|||
|
É Automatizado
IsAutomated
|
Um marcador que indica se a atividade foi executada por um sistema ou automação. | ||
|
Descrição
Diferencia tarefas feitas por humanos daquelas feitas por sistemas (workflows ou integrações). Por exemplo, o envio de um pedido de aprovação pode ser automático, enquanto a atribuição de um agente pode ser manual.\n\nAnalisar este atributo é a chave para medir e aumentar o nível de automação. Ajuda a achar tarefas manuais demoradas que poderiam ser automatizadas para reduzir custos e ganhar eficiência.
Por que é importante
Permite medir as taxas de automação e ajuda a identificar tarefas manuais que podem ser automatizadas, aumentando a eficiência.
Onde obter
Derivado ao verificar se o usuário que realizou a ação é um usuário de sistema ou integração.
Exemplos
verdadeirofalse
|
|||
|
É resolução de primeira tentativa
IsFirstPassResolution
|
Um indicador de que a solicitação foi resolvida na primeira tentativa, sem reaberturas. | ||
|
Descrição
Este marcador é "true" apenas se o pedido foi resolvido e fechado sem nunca ser reaberto. É o principal indicador da qualidade do atendimento do service desk.\n\nApoia diretamente o KPI de Resolução de Primeira Tentativa. Uma taxa alta indica serviço eficiente e de qualidade. Analisar os casos que falham aqui revela causas como falta de treinamento, documentação ruim ou diagnóstico inicial errado.
Por que é importante
Mede a qualidade e a eficiência do processo de resolução. Uma taxa baixa de resolução de primeira tentativa indica problemas ocultos que causam retrabalho e frustração no cliente.
Onde obter
Calculado no nível do caso. Considera-se resolução de primeira tentativa (FPR) se o 'ReopenCount' for zero.
Exemplos
verdadeirofalse
|
|||
|
É Retrabalho
IsRework
|
Um marcador calculado que indica se uma atividade é uma repetição de uma etapa anterior no mesmo caso. | ||
|
Descrição
Este marcador identifica loops de retrabalho. Fica como "true" se uma atividade se repete no mesmo pedido (ex: pedido atribuído ao mesmo time duas vezes). \n\nÉ essencial para o dashboard de Handoffs e Incidentes de Retrabalho e para o KPI de Taxa de Retrabalho. Permite visualizar e medir loops ineficientes que costumam ficar escondidos em dados agregados.
Por que é importante
Sinaliza e quantifica o retrabalho, permitindo analisar causas e impactos de loops ineficientes que elevam custos.
Onde obter
Calculado durante a transformação dos dados ao verificar ocorrências anteriores da mesma atividade no mesmo caso.
Exemplos
falseverdadeiro
|
|||
|
End Time
EndTime
|
O timestamp que indica quando uma atividade ou evento foi concluído. | ||
|
Descrição
O Tempo Final marca a conclusão de uma atividade. É o timestamp da próxima atividade, fechando a duração da atual. Esse dado é vital para saber quanto tempo cada etapa do processo consome.\n\nAo comparar o início e o fim, os analistas calculam tempos de processamento e de espera, o que é essencial para achar gargalos, medir a eficiência de recursos e monitorar metas de tempo.
Por que é importante
Este atributo é necessário para calcular a duração de cada atividade, item fundamental na análise de desempenho, identificação de gargalos e estudos de uso de recursos.
Onde obter
Este é um atributo derivado, calculado com base no "StartTime" do evento seguinte no mesmo caso.
Exemplos
2023-04-15T10:05:10Z2023-04-15T11:45:00Z2023-04-16T09:15:30Z
|
|||
|
Pontuação de satisfação
SatisfactionScore
|
A nota de satisfação dada pelo solicitante ao fechar o pedido. | ||
|
Descrição
Este atributo registra a nota de satisfação (geralmente de 1 a 5) dada pelo usuário final após a resolução. É uma medida direta da qualidade percebida do serviço.\n\nEstes dados são essenciais para o dashboard de Análise de Impacto na Satisfação do Cliente. Eles permitem correlacionar métricas de processo, como tempo de ciclo e retrabalho, com a experiência final do cliente, provando o valor das melhorias operacionais.
Por que é importante
Vincula métricas de desempenho aos resultados do cliente, ajudando a quantificar o impacto das falhas do processo na experiência do usuário.
Onde obter
Geralmente encontrado na tabela de Pesquisa [asmt_assessment_instance] relacionada, que está vinculada ao pedido original.
Exemplos
5431
|
|||
|
Tempo de Ciclo do Caso
CaseCycleTime
|
O tempo total transcorrido desde a criação até o fechamento final da solicitação. | ||
|
Descrição
O Tempo de Ciclo do Caso (Case Cycle Time) mede a duração total de uma solicitação, do primeiro ao último evento. Representa o tempo total de processamento sob a ótica do cliente. Este é um KPI fundamental para medir a eficiência do processo. Ele é usado em dashboards para monitorar o desempenho e analisar tendências. Pode ser segmentado por Categoria ou Prioridade para identificar quais pedidos demoram mais para serem concluídos.
Por que é importante
Este é um KPI crítico que mede o desempenho do processo de ponta a ponta. É essencial para o monitoramento estratégico e para achar áreas que precisam de melhoria.
Onde obter
Calculado subtraindo o 'StartTime' mínimo do 'EndTime' máximo para cada 'ServiceRequestID' único.
Exemplos
2 10:30:000 04:15:2210 00:05:00
|
|||
|
Tempo de Processamento
ProcessingTime
|
O período de tempo gasto ativamente trabalhando em uma atividade específica. | ||
|
Descrição
O Tempo de Processamento, também chamado de tempo ativo ou handling time, é o período gasto executando uma tarefa. É a diferença entre o fim e o início de uma atividade, sem contar o tempo em que o pedido ficou parado na fila.\n\nEssa métrica é vital para o dashboard de Análise de Gargalos e Filas. Ao somar os tempos de processamento por atividade, os analistas conseguem identificar quais etapas consomem mais recursos e esforço, permitindo priorizar melhorias nas tarefas que mais tomam tempo.
Por que é importante
Mede a duração do trabalho ativo em cada atividade, ajudando a identificar os passos mais demorados do processo e localizar gargalos operacionais.
Onde obter
Calculado como 'EndTime' menos 'StartTime' para cada registro de evento.
Exemplos
0 00:05:100 01:14:450 00:09:55
|
|||
Atividades da Gestão de Solicitações de Serviço
| Atividade | Descrição | ||
|---|---|---|---|
|
Informação solicitada ao usuário
|
Ocorre quando o agente de atendimento precisa de mais informações do solicitante para prosseguir. Isso geralmente é identificado quando o estado da solicitação muda para algo como "Aguardando informações do usuário". | ||
|
Por que é importante
Esta atividade é vital para o dashboard de Análise de Atraso por Informação do Solicitante, ajudando a medir o tempo perdido esperando respostas dos usuários.
Onde obter
Identificado quando o campo de estado do sc_req_item muda para um status designado como "aguardando informações". A alteração é registrada na tabela sys_audit.
Captura
Identifica o timestamp quando
Tipo de evento
inferred
|
|||
|
Solicitação aprovada
|
Esta atividade indica que o pedido foi aprovado oficialmente e pode seguir para o atendimento. É registrada quando o aprovador marca o registro de aprovação como "approved". | ||
|
Por que é importante
Este marco indica a mudança da fase de aprovação para a de atendimento. Analisar este tempo é crucial para entender atrasos antes do início do trabalho.
Onde obter
Identificado quando o campo de estado do registro sysapproval_approver relacionado muda para "approved", o que aciona uma mudança de estado no sc_req_item.
Captura
Identifique o timestamp de quando o campo sysapproval_approver.state muda para "approved".
Tipo de evento
inferred
|
|||
|
Solicitação Atribuída ao Agente
|
Esta atividade ocorre quando um agente específico é designado para o pedido. É registrada monitorando as mudanças no campo "Assigned to" na solicitação ou em suas tarefas de atendimento. | ||
|
Por que é importante
Crucial para medir transferências, calcular a carga de trabalho por agente e analisar o tempo de fila antes de o trabalho começar.
Onde obter
Identificado por uma alteração no campo assigned_to na tabela sc_req_item ou sc_task. O histórico de alterações é registrado na tabela sys_audit.
Captura
Rastreie mudanças no campo assigned_to na tabela sys_audit.
Tipo de evento
inferred
|
|||
|
Solicitação de Serviço Criada
|
Esta atividade inicia o ciclo de vida da solicitação, registrada quando o usuário faz o pedido via catálogo. O sistema marca isso como o evento de criação de um novo registro na tabela sc_req_item (Requested Item). | ||
|
Por que é importante
Evento inicial do processo. É essencial para calcular o tempo total de ciclo e analisar o volume de pedidos e padrões de envio.
Onde obter
Evento explícito capturado do campo sys_created_on do registro na tabela sc_req_item.
Captura
Use o timestamp
Tipo de evento
explicit
|
|||
|
Solicitação de Serviço Encerrada
|
Marca o fim definitivo do ciclo de vida da solicitação de serviço. Isso geralmente ocorre de forma automática após um período definido no estado "Resolved", durante o qual o usuário ainda pode reabrir a solicitação. | ||
|
Por que é importante
Principal evento de fim bem-sucedido. O tempo entre resolvido e fechado também pode ser analisado para validar políticas de fechamento automático.
Onde obter
Identificado quando o campo de estado do sc_req_item é atualizado para um estado final de fechamento, como "Closed Complete". Isso é registrado na tabela sys_audit.
Captura
Identifica o timestamp quando
Tipo de evento
inferred
|
|||
|
Solicitação de Serviço Resolvida
|
Esta atividade indica que o agente de atendimento terminou o trabalho e enviou uma solução. Ela é registrada quando o estado da solicitação muda para "Resolved" ou similar. | ||
|
Por que é importante
Este é um marco crítico que geralmente para o cronômetro do SLA. Ele marca o fim do trabalho de atendimento ativo e é essencial para o cálculo do tempo total de resolução.
Onde obter
Identificado quando o campo de estado do sc_req_item é atualizado para "Resolved" ou um estado terminal similar antes do fechamento final. A alteração é rastreada na tabela sys_audit.
Captura
Identifica o timestamp quando
Tipo de evento
inferred
|
|||
|
Aprovação Solicitada
|
Representa o momento em que uma solicitação é enviada para aprovação de um gestor ou aprovador designado. Geralmente é identificado quando o estado da solicitação muda para "Pending Approval" ou similar. | ||
|
Por que é importante
Monitorar aprovações ajuda a achar gargalos na autorização e mede quanto tempo os pedidos esperam antes de o atendimento começar de fato.
Onde obter
Identificado quando o campo de estado do sc_req_item muda para um valor de aprovação pendente ou pela criação de um registro correspondente na tabela sysapproval_approver. As alterações são registradas na tabela sys_audit.
Captura
Identifica o timestamp quando
Tipo de evento
inferred
|
|||
|
Informação fornecida pelo usuário
|
Esta atividade marca o momento em que o solicitante fornece a informação necessária. É identificada quando o pedido sai do status "Aguardando Informações do Usuário" e volta para um estado ativo. | ||
|
Por que é importante
Combinada com "Informação solicitada ao usuário", esta atividade permite medir com precisão os atrasos causados pelo solicitante e ajuda a avaliar a eficiência do processo de comunicação.
Onde obter
Identificado quando o campo de estado do sc_req_item muda de um status de "aguardando informações" para um status ativo. Isso geralmente é acionado quando o usuário adiciona um comentário ou responde a um e-mail.
Captura
Identifique o timestamp de quando o estado muda de "Aguardando informações do usuário" para "Trabalho em andamento".
Tipo de evento
inferred
|
|||
|
Requisição Rejeitada
|
Esta atividade representa os casos em que um pedido é formalmente rejeitado na fase de aprovação. É um caminho alternativo para o encerramento, registrado quando um aprovador marca o pedido como "rejected". | ||
|
Por que é importante
Monitorar rejeições ajuda a identificar pedidos inválidos ou mal direcionados, além de falhas no processo de envio, servindo como uma trilha de exceção importante.
Onde obter
Identificado quando o campo de estado do registro sysapproval_approver relacionado muda para "rejected". Isso geralmente define o sc_req_item pai como um estado fechado e incompleto.
Captura
Identifique o timestamp de quando o campo sysapproval_approver.state muda para "rejected".
Tipo de evento
inferred
|
|||
|
Solicitação atribuída ao grupo
|
Indica que a solicitação de serviço foi atribuída a uma equipe ou grupo de atendimento específico. Este evento é identificado ao detectar uma mudança no campo de grupo de atribuição (assignment group) no item da solicitação ou em suas tarefas associadas. | ||
|
Por que é importante
Rastrear atribuições por grupo ajuda a analisar a carga de trabalho entre times e achar atrasos no roteamento das solicitações.
Onde obter
Identificado por uma alteração no campo assignment_group na tabela sc_req_item ou sc_task. O histórico de alterações é registrado na tabela sys_audit.
Captura
Rastreie mudanças no campo assignment_group na tabela sys_audit.
Tipo de evento
inferred
|
|||
|
Solicitação Cancelada
|
Esta atividade é o estado terminal de pedidos cancelados antes da conclusão. É registrada quando o status muda para "Cancelled" ou "Closed Cancelled". | ||
|
Por que é importante
Este é um evento de fim malsucedido. Analisar por que os pedidos são cancelados ajuda a entender melhor as necessidades do usuário ou ineficiências do processo.
Onde obter
Identificado quando o campo de estado do sc_req_item é atualizado para um estado final de cancelamento, como "Closed Cancelled". A alteração é registrada na tabela sys_audit.
Captura
Identifica o timestamp quando
Tipo de evento
inferred
|
|||
|
Solicitação Reaberta
|
Esta atividade registra os casos em que um pedido resolvido volta ao estado aberto. Isso é identificado pela mudança de status de "Resolved" para "Work in Progress" ou equivalente. | ||
|
Por que é importante
Mede o retrabalho diretamente e é vital para o KPI de "Taxa de Resolução de Primeira Tentativa". Números altos indicam soluções de baixa qualidade ou incompletas.
Onde obter
Identificado por uma mudança no campo de estado do sc_req_item, movendo-se de um estado resolvido ou fechado de volta para um estado aberto ou em andamento. Essa alteração é registrada na tabela sys_audit.
Captura
Detecta mudança de estado de 'Resolvido' para 'Em Andamento' no sys_audit.
Tipo de evento
inferred
|
|||
|
Tarefa de Execução Criada
|
Representa a criação de um item de trabalho ou tarefa específica necessária para atender à solicitação. Este é um evento explícito registrado quando um novo registro é criado na tabela Catalog Task. | ||
|
Por que é importante
Para pedidos complexos, analisar a criação e conclusão de tarefas individuais oferece uma visão detalhada da execução.
Onde obter
Evento explícito capturado do campo sys_created_on de um registro na tabela sc_task vinculado ao sc_req_item.
Captura
Use o timestamp
Tipo de evento
explicit
|
|||
|
Vendedor Externo Acionado
|
Representa a transferência de uma solicitação ou tarefa para um fornecedor externo. Isso pode ser identificado pela atribuição a um grupo específico de fornecedor ou por um marcador (flag) na solicitação. | ||
|
Por que é importante
Esta atividade permite analisar o desempenho dos fornecedores e seu impacto no ciclo de vida do pedido, dado essencial para o dashboard de Ciclo de Engajamento de Fornecedores Externos.
Onde obter
Geralmente identificado por indução, como um assignment_group de fornecedor ou um marcador específico no registro sc_req_item ou sc_task.
Captura
Identifica mudança do grupo de atribuição para um grupo de fornecedor conhecido.
Tipo de evento
inferred
|
|||