Seu template de dados de gestão de despesas
Seu template de dados de gestão de despesas
- Atributos recomendados para uma análise completa
- Atividades principais para monitorar e garantir uma descoberta de processo precisa
- Guia prático para extração de dados
Atributos de Gestão de Despesas
| Nome | Descrição | ||
|---|---|---|---|
|
ID do Relatório de Despesas
ExpenseReportId
|
O identificador único de um relatório, que agrupa todas as atividades relacionadas, do envio ao reembolso. | ||
|
Descrição
O ID do Relatório de Despesas é o identificador principal (case ID) do processo. Cada ID representa um conjunto de despesas enviadas para reembolso. Esse atributo é crucial para rastrear a jornada ponta a ponta, permitindo reconstruir todo o ciclo de vida, incluindo envios, aprovações, rejeições e pagamentos.
Por que é importante
Permite agrupar todos os eventos relacionados em uma única instância de processo, a base de qualquer análise de Process Mining.
Onde obter
Esta é a chave primária nos dados de relatórios de despesas, geralmente disponível via API do Expensify como 'reportID'.
Exemplos
RPT_84321RPT_99012RPT_10573
|
|||
|
Nome da Atividade
ActivityName
|
O nome do evento de negócio ocorrido em um momento específico para um relatório de despesas. | ||
|
Descrição
O Nome da Atividade descreve uma etapa específica, como 'Relatório Enviado' ou 'Aprovado pelo Gestor'. Ele forma a base do mapa do processo, permitindo visualizar o fluxo de trabalho, identificar caminhos comuns e notar desvios ou gargalos. Analisar a sequência das atividades é fundamental para entender a eficiência e a conformidade.
Por que é importante
Este atributo define as etapas no mapa do processo, permitindo visualizar e analisar o fluxo, variações e loops de retrabalho.
Onde obter
Este atributo é derivado do mapeamento de mudanças de status, comentários ou logs de histórico do Expensify para uma lista padronizada de atividades.
Exemplos
Relatório de Despesas EnviadoAprovado pelo GerenteRejeitado pelo FinanceiroReembolso Executado
|
|||
|
Tempo do Evento
EventTime
|
O timestamp que indica quando uma atividade ou evento específico ocorreu para um relatório de despesas. | ||
|
Descrição
O Event Time fornece a data e hora exata de cada atividade. Essa informação é vital para calcular tempos de ciclo, durações e esperas entre etapas. Permite analisar gargalos, tendências de performance e SLAs. Sem timestamps precisos, a análise fica limitada apenas à descoberta do fluxo básico.
Por que é importante
Timestamps são essenciais para análises temporais, como cálculo de tempos de ciclo, identificação de gargalos e monitoramento de desempenho.
Onde obter
Este é o timestamp de criação associado a cada entrada de log ou mudança de status nos dados do Expensify.
Exemplos
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:12:05Z
|
|||
|
Aprovador
Approver
|
O nome ou ID do usuário responsável por aprovar ou rejeitar o relatório. | ||
|
Descrição
O atributo Aprovador identifica o gestor ou membro do financeiro que atua sobre o relatório. Isso é essencial para analisar comportamentos específicos, como tempos de aprovação, taxas de rejeição e carga de trabalho. Entender o desempenho dos aprovadores ajuda a identificar necessidades de treinamento, redistribuir tarefas e agilizar o fluxo.
Por que é importante
Este atributo é fundamental para analisar gargalos de aprovação, distribuição de carga de trabalho e taxas de rejeição por aprovador.
Onde obter
Esta informação é encontrada no histórico ou log do workflow, geralmente associada a eventos de aprovação ou rejeição. O campo pode estar como 'managerEmail'.
Exemplos
jane.doe@example.comjohn.smith@example.comfinance.approver@example.com
|
|||
|
Autor
Submitter
|
O funcionário que criou e enviou o relatório de despesas. | ||
|
Descrição
O atributo Solicitante identifica o funcionário que busca o reembolso. Esses dados analisam padrões por colaborador, departamento ou cargo. Ajuda a entender quais grupos enfrentam mais atrasos ou violam mais políticas, contribuindo para melhorar a experiência do funcionário.
Por que é importante
Permite analisar o desempenho do processo sob a ótica do colaborador, ajudando a identificar grupos com problemas ou atrasos recorrentes.
Onde obter
Este é um campo primário no objeto de relatório de despesas, geralmente rotulado como 'policyEmail' ou 'submitterEmail'.
Exemplos
sara.jones@example.comkevin.lee@example.commaria.garcia@example.com
|
|||
|
Departamento do Colaborador
EmployeeDepartment
|
O departamento ou unidade de negócio à qual o solicitante pertence. | ||
|
Descrição
Este atributo indica o departamento do funcionário (ex: Vendas, Engenharia ou Marketing). É uma dimensão crucial para comparar tempos de ciclo, taxas de rejeição e conformidade entre diferentes áreas, revelando necessidades de treinamento ou problemas específicos.
Por que é importante
Permite análises detalhadas (drill-down) para comparar o desempenho e conformidade entre diferentes unidades de negócio.
Onde obter
Esta informação pode estar em uma tag no relatório ou no perfil do usuário no Expensify. Pode exigir cruzamento com dados de um sistema de RH externo.
Exemplos
VendasMarketingEngenhariaFinanças
|
|||
|
Indicador de Violação de Política
PolicyViolationFlag
|
Indicador booleano que é verdadeiro se o relatório foi sinalizado por violação de política. | ||
|
Descrição
Este indicador mostra se o relatório violou políticas, como limites de gastos ou falta de comprovantes. O sistema do Expensify costuma sinalizar isso automaticamente. O atributo é essencial para o dashboard de Conformidade, ajudando a quantificar falhas e focar em melhorias.
Por que é importante
Mede diretamente a conformidade e ajuda a identificar relatórios que exigem auditoria, sendo essencial para Dashboards de compliance.
Onde obter
Relatórios do Expensify costumam ter um campo específico indicando violação, como 'hasViolations' ou flag similar.
Exemplos
verdadeirofalse
|
|||
|
Valor Total do Relatório
ReportTotalAmount
|
O valor monetário total do relatório de despesas. | ||
|
Descrição
Este atributo representa a soma de todas as despesas em um único relatório. É uma métrica financeira crítica para identificar gastos de alto valor que exijam mais rigor ou fluxos de aprovação diferenciados, além de ajudar a entender padrões de gastos.
Por que é importante
Permite analisar relatórios de alto valor e tendências de gastos, sendo crucial para Dashboards financeiros e de compliance.
Onde obter
Disponível no objeto de relatórios do Expensify, geralmente chamado de 'total' ou 'amount'.
Exemplos
150.752500.0089.50
|
|||
|
Aprovação na primeira tentativa
IsFirstPassApproval
|
Sinalizador calculado que é verdadeiro se o relatório foi aprovado sem rejeições ou revisões. | ||
|
Descrição
Este sinalizador booleano indica se o relatório passou pelo processo sem rejeições ou devoluções. É uma medida direta de qualidade e eficiência, alimentando o KPI de Taxa de Aprovação de Primeira. Uma taxa alta sinaliza envios de qualidade e políticas bem compreendidas.
Por que é importante
Mede a qualidade dos envios iniciais e a eficiência do fluxo, destacando a frequência de retrabalho.
Onde obter
Calculado verificando a sequência de atividades de um ExpenseReportId. Se não houver 'Rejeitado' ou 'Devolvido para Revisão', o indicador é verdadeiro.
Exemplos
verdadeirofalse
|
|||
|
Categoria de Despesa
ExpenseCategory
|
A categoria atribuída a um item de despesa individual dentro de um relatório. | ||
|
Descrição
Classifica o gasto (ex: Viagem, Alimentação, Software). Geralmente definida pela categoria principal do relatório para análise de tendências e conformidade.
Por que é importante
Ajuda a analisar padrões de gastos, desvios e tempos de aprovação por tipo de despesa.
Onde obter
Localizado nos itens de linha ('transactions'). Exige regra de agregação para atribuir ao nível do caso.
Exemplos
Passagem AéreaHospedagemRefeiçõesMateriais de escritório
|
|||
|
Event End Time
EventEndTime
|
O timestamp de término de uma atividade. Útil para medir tarefas com duração específica. | ||
|
Descrição
Embora muitas atividades sejam instantâneas, algumas, como a 'Revisão do Gestor', têm início e fim. O Event End Time marca a conclusão dessa tarefa. Usado com o Start Time, ele calcula o processing time exato de cada etapa, detalhando onde o tempo está sendo realmente gasto.
Por que é importante
Permite calcular tempos de processamento, ajudando a distinguir entre tempo de trabalho ativo e tempo de espera (ociosidade).
Onde obter
Geralmente não é um campo direto. É derivado pegando o timestamp do próximo evento na sequência para o mesmo caso.
Exemplos
2023-10-26T10:05:12Z2023-10-27T15:00:00Z
|
|||
|
Meio de Pagamento
PaymentMethod
|
O método utilizado para reembolsar o funcionário. | ||
|
Descrição
Este atributo descreve como o funcionário foi pago (ex: Depósito, PayPal ou Cartão Corporativo). Analisar o método de pagamento ajuda a entender a fase final do processo, identificando se certas formas de pagamento geram mais atrasos.
Por que é importante
Oferece contexto para a fase de reembolso e pode ser usado para analisar atrasos ou custos associados a diferentes métodos de pagamento.
Onde obter
Esta informação está geralmente disponível nos detalhes de reembolso de um relatório fechado.
Exemplos
ACHPayPalBill.com
|
|||
|
Moeda
Currency
|
O código da moeda para os valores no relatório de despesas. | ||
|
Descrição
O atributo Moeda especifica a unidade monetária do valor total, como BRL, USD ou EUR. Isso é vital para empresas globais garantirem a interpretação correta dos dados financeiros. Todos os valores devem ser analisados junto com este atributo para evitar somas incorretas.
Por que é importante
Garante análises financeiras precisas ao fornecer o contexto necessário para todos os valores monetários.
Onde obter
Este é um campo padrão no objeto de relatório do Expensify, geralmente chamado de 'currency'.
Exemplos
USDEURGBPCAD
|
|||
|
Motivo da Rejeição
RejectionReason
|
O motivo fornecido pelo aprovador ao rejeitar um relatório ou devolvê-lo para revisão. | ||
|
Descrição
Quando um relatório é rejeitado, o aprovador costuma justificar o motivo. Este atributo de texto captura essa razão, oferecendo um insight qualitativo valioso. Analisar os motivos de rejeição ajuda a identificar erros comuns, políticas confusas ou falhas de treinamento, auxiliando diretamente no aumento da taxa de aprovação de primeira.
Por que é importante
Fornece dados qualitativos que explicam o motivo do retrabalho, algo crucial para a análise de causa raiz das rejeições de relatórios.
Onde obter
Esta informação costuma estar nos comentários ou no log de histórico associado a um evento de rejeição.
Exemplos
Recibo ausente para item acima de $75Categoria de despesa incorreta selecionadaDespesa duplicada enviada
|
|||
|
Nome da Política
PolicyName
|
O nome da política de despesas aplicada ao relatório. | ||
|
Descrição
No Expensify, grupos diferentes podem ter políticas distintas. Este atributo identifica a política regente, permitindo comparar eficiência e conformidade entre diferentes fluxos de aprovação.
Por que é importante
Permite segmentar a análise pelas regras aplicadas, fundamental para entender variações causadas por políticas diferentes.
Onde obter
Este é um campo padrão no objeto de relatório no Expensify, geralmente chamado de 'policyID' ou 'policyName'.
Exemplos
Política de Funcionários EUAPolítica do Time de Vendas UKPolítica de Viagens Executivas
|
|||
|
Resultado da Auditoria
AuditOutcome
|
O resultado de uma auditoria manual ou automática realizada no relatório de despesas. | ||
|
Descrição
Este atributo registra o resultado da auditoria, como 'Aprovado', 'Reprovado' ou 'Aprovado com Ressalvas'. É relevante para empresas com etapas formais de auditoria. Analisar esses resultados ajuda a entender os níveis de conformidade e a eficácia dos controles atuais.
Por que é importante
Mede o resultado das verificações e é vital para analisar a eficácia do processo de auditoria.
Onde obter
Provavelmente é um atributo conceitual ou armazenado como tag ou comentário. Sua existência depende da configuração específica do processo no Expensify.
Exemplos
AprovadoFalha - Violação de PolíticaAprovado com Ressalvas
|
|||
|
Sistema de Origem
SourceSystem
|
O sistema do qual os dados foram extraídos. | ||
|
Descrição
Este atributo identifica a origem dos dados ('Expensify'). É importante para a governança de dados, especialmente quando informações de vários sistemas são combinadas, ajudando a rastrear a linhagem e o contexto do processo.
Por que é importante
Fornece contexto essencial para a linhagem dos dados e ajuda a diferenciar processos quando dados de múltiplos sistemas de origem são carregados no mesmo ambiente.
Onde obter
Este é um valor estático ('Expensify') que deve ser adicionado durante o processo de transformação de dados.
Exemplos
ExpensifyExpensifyAPI-v2.0
|
|||
|
Status do Relatório
ReportStatus
|
O estado atual do relatório de despesas em seu ciclo de vida. | ||
|
Descrição
O Status do Relatório indica a posição atual no processo, como 'ABERTO', 'ENVIADO', 'APROVADO', 'REEMBOLSADO' ou 'FECHADO'. Ele oferece um panorama do progresso. No Process Mining, este atributo costuma definir o Nome da Atividade, mas também serve para analisar quanto tempo os relatórios ficam em cada estado.
Por que é importante
Indica o estado atual do caso e costuma ser a fonte para gerar o Log de Atividades para o Process Mining.
Onde obter
Este é um campo padrão no objeto de relatório do Expensify, geralmente chamado de 'status' ou 'state'.
Exemplos
ENVIADOAPPROVEDREEMBOLSADOCLOSED
|
|||
|
Tempo de ciclo total
TotalCycleTime
|
O tempo total decorrido desde a criação do primeiro evento até a conclusão do último evento de um relatório. | ||
|
Descrição
O Tempo de Ciclo Total é um cálculo por caso que mede a duração ponta a ponta do processo de um relatório. É um KPI chave para a eficiência geral, calculado pela diferença entre o timestamp da primeira atividade (ex: 'Relatório Criado') e da última (ex: 'Reembolso Executado').
Por que é importante
Este é um KPI primário para medir a velocidade geral do processo e identificar casos muito longos que podem indicar problemas sistêmicos.
Onde obter
Este atributo é calculado pela diferença (MAX(EventTime) - MIN(EventTime)) para cada ExpenseReportId.
Exemplos
6048001209600259200
|
|||
|
Tempo de Processamento
ProcessingTime
|
O tempo de duração gasto em uma única atividade. | ||
|
Descrição
O Processing Time é uma métrica que calcula o tempo entre o início e o fim de uma atividade, representando o tempo ativo dedicado a uma tarefa. Por exemplo, ele mede quanto tempo um gestor manteve um relatório aberto antes de aprová-lo. Essa métrica ajuda a distinguir o trabalho ativo do tempo de espera, oferecendo uma visão profunda da eficiência do processo.
Por que é importante
Ajuda a distinguir tempo de processamento ativo de espera passiva, permitindo identificar gargalos com precisão.
Onde obter
Calculado durante a transformação de dados, subtraindo o EventTime do EventEndTime.
Exemplos
864003600600
|
|||
|
Última Atualização de Dados
LastDataUpdate
|
O timestamp que indica quando os dados para este registo foram atualizados pela última vez a partir do sistema de origem. | ||
|
Descrição
Este atributo registra quando os dados foram extraídos e atualizados. Garante transparência sobre a atualidade dos dados, permitindo que os usuários confiem nos insights e tomem decisões baseadas em informações recentes.
Por que é importante
Garante que os usuários saibam quão atualizados estão os dados, algo crítico para a relevância e a precisão da análise de processos.
Onde obter
Geralmente é o timestamp do job de extração de dados, adicionado durante o processo de ETL.
Exemplos
2023-11-20T08:00:00Z2023-11-21T08:00:00Z
|
|||
Atividades de Gestão de Despesas
| Atividade | Descrição | ||
|---|---|---|---|
|
Aprovado pelo Financeiro
|
O financeiro ou aprovador final revisou e deu o aval definitivo. Esta ação é logada no histórico e geralmente altera o status para 'Aprovado'. | ||
|
Por que é importante
Esta é a etapa final de aprovação antes do reembolso. O tempo gasto aqui é crítico para o tempo de ciclo total e para o KPI de Lead Time de Reembolso.
Onde obter
Capturado do histórico, registrando a aprovação final pela equipe financeira com timestamp.
Captura
Registrado como a ação de aprovação final no histórico do workflow.
Tipo de evento
explicit
|
|||
|
Aprovado pelo Gerente
|
O gestor direto ou aprovador de primeiro nível revisou e aprovou o relatório. Este evento é extraído do log do workflow de aprovação, que registra a ação e o timestamp. | ||
|
Por que é importante
Marco crítico no fluxo de aprovação. Analisar o tempo desde o envio até este evento ajuda a identificar gargalos na gestão e medir o KPI de tempo de aprovação do gestor.
Onde obter
Capturado do histórico ou trilha de auditoria, que registra a ação de aprovação, nome do aprovador e timestamp.
Captura
Registrado como uma ação de aprovação distinta no histórico do relatório.
Tipo de evento
explicit
|
|||
|
Reembolso Executado
|
O pagamento foi enviado ao funcionário, concluindo o reembolso. Isso é capturado nos logs de processamento de pagamentos ou via atualização de status final no Expensify. | ||
|
Por que é importante
Este é um ponto final chave para medir tempos de ciclo sob a ótica do funcionário, sendo crítico para os KPIs de Tempo Médio de Ciclo e Lead Time de Reembolso.
Onde obter
Inferido quando o status muda para 'Reimbursed'. O sistema fornece o timestamp via integração de pagamento.
Captura
Derivado da mudança de status para 'Reimbursed' com seu timestamp.
Tipo de evento
inferred
|
|||
|
Relatório de Despesas Criado
|
Marca o início de um novo relatório. Capturado como evento explícito com timestamp quando salvo pela primeira vez no Expensify. | ||
|
Por que é importante
Esta atividade é o ponto de partida de toda a análise, sendo crucial para medir o tempo de ciclo total, da criação ao reembolso.
Onde obter
Este evento é capturado a partir do timestamp de criação no histórico ou logs de auditoria do Expensify. Todo objeto de relatório possui uma data de criação.
Captura
Registrado na criação e salvamento inicial do relatório de despesas.
Tipo de evento
explicit
|
|||
|
Relatório de Despesas Enviado
|
O funcionário envia oficialmente o relatório para iniciar o workflow de aprovação. É uma transição chave da entrada de dados para a revisão, capturada pela mudança de status e timestamp. | ||
|
Por que é importante
Esta atividade é um marco crítico que inicia o ciclo de aprovação. Serve como ponto de partida para medir os tempos de revisão do gestor e do financeiro.
Onde obter
Inferido pela mudança de 'Open' ou 'Draft' para 'Processing' ou 'Submitted' com seu timestamp.
Captura
Derivado da mudança de status para 'Processing' com timestamp de envio.
Tipo de evento
inferred
|
|||
|
Relatório Devolvido para Revisão
|
Um aprovador (gestor ou financeiro) devolve o relatório para correção. Geralmente inferido pela mudança de status para 'Open' após estar em 'Processing'. | ||
|
Por que é importante
Esta atividade representa retrabalho, uma grande fonte de ineficiência. Rastreá-la ajuda a quantificar loops, medir o KPI de Taxa de Retrabalho e identificar as causas raiz.
Onde obter
Inferido pela mudança de status de 'Processing' ou 'Submitted' para 'Open'. O timestamp marca o evento.
Captura
Derivado da mudança de status de 'Processing' para 'Open'.
Tipo de evento
inferred
|
|||
|
Relatório Fechado
|
O relatório é encerrado formalmente após todas as ações, incluindo reembolso e sincronização contábil. Este evento é identificado por um status final como 'Fechado'. | ||
|
Por que é importante
Oferece um ponto final definitivo para o processo, separado do reembolso, o que é útil para analisar as etapas finais de contabilidade e arquivamento.
Onde obter
Inferido pela mudança para um estado terminal como 'Closed', geralmente após o reembolso e exportação contábil.
Captura
Derivado da mudança de status para 'Closed' com seu timestamp.
Tipo de evento
inferred
|
|||
|
Despesa Adicionada ao Relatório
|
Representa o momento em que um funcionário adiciona um item específico ao relatório, como um comprovante digitalizado ou despesa manual. Isso é registrado como uma entrada no log de histórico detalhado. | ||
|
Por que é importante
Analisar o tempo entre a criação e a adição de itens revela atrasos na coleta de evidências ou preparação pelo colaborador.
Onde obter
Da trilha de auditoria, que registra ações como a inclusão de entradas individuais de despesa.
Captura
Registrado no histórico do relatório a cada nova despesa adicionada.
Tipo de evento
explicit
|
|||
|
Lançamento Contábil Realizado
|
Os dados financeiros foram exportados e lançados no ERP ou sistema contábil. É a etapa final, marcando a conclusão do processo sob a ótica contábil. | ||
|
Por que é importante
Representa o encerramento final do relatório de despesas no sistema financeiro. É fundamental para medir o processo ponta a ponta e garantir a sincronização dos dados.
Onde obter
Capturado via logs de integração entre Expensify e o software contábil. Pode exigir a combinação de dados de ambos os sistemas.
Captura
Registrado no histórico de integração quando os dados são sincronizados com o sistema contábil.
Tipo de evento
explicit
|
|||
|
Reembolso Agendado
|
Após a aprovação final, o relatório entra na fila de pagamento. Este evento marca a transição da fase de aprovação para a de desembolso, capturado quando o status muda para 'Reimbursing'. | ||
|
Por que é importante
Marca o início do prazo de desembolso. Analisar o tempo até o pagamento real ajuda a localizar atrasos financeiros.
Onde obter
Inferido pela mudança para 'Reimbursing' ou 'Processing Payment' com seu timestamp.
Captura
Derivado de mudança de status indicando fila de pagamento.
Tipo de evento
inferred
|
|||
|
Rejeitado pelo Financeiro
|
O departamento financeiro revisou e rejeitou o relatório, interrompendo o reembolso. Este evento fica registrado no histórico do workflow com timestamp e motivo. | ||
|
Por que é importante
Identifica gargalos e falhas na revisão final. Essencial para analisar a taxa de rejeição geral e riscos de compliance.
Onde obter
Capturado do histórico, registrando a rejeição pela equipe financeira, usuário e timestamp.
Captura
Registrado como uma ação de rejeição distinta no histórico do relatório.
Tipo de evento
explicit
|
|||
|
Rejeitado pelo Gestor
|
O aprovador de primeiro nível rejeitou o relatório, o que geralmente interrompe o fluxo. Isso é registrado como um evento de rejeição, frequentemente acompanhado por uma justificativa. | ||
|
Por que é importante
Analisar rejeições é vital para entender a Taxa de Rejeição de Relatórios. Ajuda a identificar causas comuns de falha e áreas que precisam de melhoria.
Onde obter
Capturado do histórico, registrando a rejeição, quem rejeitou e o timestamp. O status muda para 'Rejected'.
Captura
Registrado como uma ação de rejeição distinta no histórico do relatório.
Tipo de evento
explicit
|
|||
|
Violação de Política Identificada
|
Verificação automática que identifica desvios da política (ex: acima do orçamento ou sem recibo). Capturado via flag de violação no relatório ou item. | ||
|
Por que é importante
Expõe problemas de conformidade e quais políticas são mais violadas, permitindo treinamentos focados. Essencial para o KPI de Contagem de Violações.
Onde obter
Inferido quando a flag 'Policy Violation' se torna verdadeira. O timestamp é o momento da ativação dessa flag.
Captura
Derivado do timestamp de atualização do atributo de violação de política.
Tipo de evento
inferred
|
|||