Seu Template de dados para integração de clientes KYC
Seu Template de dados para integração de clientes KYC
- Atributos recomendados para coleta
- Principais atividades a acompanhar
- Orientações para extração de dados
Atributos da integração de clientes KYC
| Nome | Descrição | ||
|---|---|---|---|
| Hora de início EventStartTime | Data e hora que indicam quando uma atividade ou evento começou oficialmente. | ||
| Descrição Este atributo registra a data e hora exatas em que uma atividade específica começou. Ele fornece a ordem cronológica necessária para reconstruir o fluxo do processo e é essencial para todas as análises baseadas em tempo. Em Process Mining, a hora de início é usada para calcular a duração das atividades, o tempo de espera entre elas e o tempo de ciclo total do caso. Ela forma a base temporal do Event Log e é fundamental para analisar a performance e os gargalos. Por que isso importa Esta data e hora são essenciais para ordenar os eventos cronologicamente e calcular todas as métricas baseadas em tempo, como tempos de ciclo e durações. Onde encontrar Pode ser encontrado nas tabelas de trilha de auditoria, Event Log ou histórico de Workflow do Fenergo, geralmente com nomes como 'Timestamp', 'StartDate' ou 'CreationDate'. Exemplos 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Nome da atividade ActivityName | Nome do evento de negócio ou da tarefa específica que ocorreu em determinado momento do processo de integração. | ||
| Descrição O nome da atividade descreve uma etapa ou marco da jornada de integração do cliente, como 'Triagem inicial realizada' ou 'Solicitação aprovada'. A sequência dessas atividades forma a base do mapa do processo. A análise desse atributo permite visualizar o fluxo do processo, identificar caminhos comuns e alternativos e medir a frequência de cada etapa. Isso é essencial para entender quais ações estão sendo realizadas e em que ordem. Por que isso importa Este atributo define as etapas do processo e permite criar um mapa do processo e analisar o fluxo e as variações. Onde encontrar Essas informações geralmente estão nas tabelas de Workflow ou de registro de auditoria do Fenergo, associadas às transições de status do caso ou à conclusão de tarefas. Exemplos Dados e documentos solicitadosAnálise de conformidade iniciadaSolicitação aprovada | |||
| Solicitação do cliente CustomerApplication | Identificador exclusivo de uma jornada de integração de cliente, usado como identificador principal do caso. | ||
| Descrição A solicitação do cliente é o identificador central que agrupa todas as atividades e os eventos relacionados ao processo de integração KYC de um cliente. Ela permite acompanhar a solicitação de ponta a ponta, desde o envio inicial até a resolução final, seja com aprovação, rejeição ou encerramento. Em Process Mining, esse atributo é fundamental para reconstruir a jornada completa de cada solicitação. Ele permite analisar os fluxos do processo, os tempos de ciclo, as variações e os gargalos de cada solicitação, oferecendo uma visão clara de como cada caso é tratado. Por que isso importa Este é o ID do caso essencial que conecta todos os eventos relacionados e permite analisar o processo de integração do cliente de ponta a ponta. Onde encontrar Em geral, esta é a chave primária da entidade de gestão de casos ou de gestão do ciclo de vida do cliente no sistema central do Fenergo. Exemplos APP-2023-00123APP-2023-00124APP-2023-00125 | |||
| Sistema de origem SourceSystem | Sistema de registro de onde os dados foram extraídos. | ||
| Descrição Este atributo identifica o sistema de origem dos dados do evento. Neste processo, o sistema será sempre o Fenergo, mas, em conjuntos de dados combinados, ele ajuda a diferenciar as fontes de dados. Na análise, ele é usado principalmente para filtrar dados de sistemas específicos ou verificar a procedência dos dados. Isso garante clareza em ambientes que combinam dados de vários sistemas para oferecer uma visão abrangente do processo. Por que isso importa Identifica a origem dos dados, essencial para a governança e a validação dos dados e para garantir que a análise use a fonte correta. Onde encontrar Em geral, é um valor estático adicionado durante a extração dos dados para identificar a origem dos registros. Exemplos FenergoFenergo CLM | |||
| Última atualização dos dados LastDataUpdate | Data e hora que indicam quando os dados deste processo foram atualizados ou extraídos pela última vez. | ||
| Descrição Este atributo registra a data e hora da atualização mais recente dos dados. Ele contextualiza a atualidade dos dados analisados e ajuda a entender se os insights refletem as operações mais recentes. Em Dashboards e relatórios, essas informações mostram aos usuários o quão atuais são os dados. Elas ajudam a definir expectativas sobre se a análise reflete as operações em tempo real ou um retrato histórico. Por que isso importa Fornece um contexto essencial sobre a atualidade dos dados e ajuda os usuários a entender o quão recente é a análise do processo. Onde encontrar Este valor é gerado e registrado no conjunto de dados durante o processo de extração e carregamento de dados (ETL). Exemplos 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Data-limite do SLA SlaTargetDate | Data até a qual se espera que o caso de integração do cliente seja concluído. | ||
| Descrição A data-limite do SLA representa o prazo acordado para concluir todo o processo de integração de uma solicitação de cliente. É um parâmetro essencial para medir a performance real. Este atributo é fundamental para o Dashboard 'Monitoramento da Conformidade com o SLA' e para calcular o KPI 'Taxa de cumprimento do SLA'. Ele permite gerenciar proativamente os casos com risco de descumprir o SLA e ajuda a priorizar o trabalho. Por que isso importa Define a data prevista para a conclusão, essencial para monitorar a Conformidade com o SLA e priorizar casos atrasados. Onde encontrar Esta data costuma ser calculada com base na data de envio da solicitação e nas regras de negócio configuradas no módulo de gestão de SLA do Fenergo. Exemplos 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| Departamento do usuário UserDepartment | Departamento ou unidade de negócio à qual pertence o usuário que iniciou a atividade. | ||
| Descrição Este atributo fornece o contexto organizacional do usuário que realizou uma atividade, como 'Conformidade', 'Operações de integração' ou 'Vendas'. Em geral, ele é obtido das informações do perfil do usuário. Esta dimensão é essencial para analisar as transferências de trabalho entre departamentos e identificar gargalos entre áreas. Ela também dá suporte direto ao Dashboard 'Distribuição das atividades da equipe', permitindo agrupar o trabalho por equipe ou departamento. Por que isso importa Permite analisar a performance do processo por departamento e destacar transferências de trabalho, atrasos e distribuição da carga de trabalho entre departamentos. Onde encontrar Talvez seja necessário combinar esses dados com uma tabela separada de usuários ou dados mestres de RH usando o ID 'InitiatingUser'. O Fenergo também pode armazenar essa informação no perfil do usuário. Exemplos ComplianceIntegração de clientesGarantia da qualidade | |||
| Hora de término EventEndTime | Data e hora que indicam quando uma atividade ou evento foi concluído. | ||
| Descrição Este atributo registra a data e hora exatas em que uma atividade específica terminou. Ele complementa a hora de início e define a duração efetiva de uma tarefa. Em Process Mining, a hora de término é usada junto com a hora de início para calcular o tempo de processamento de cada atividade. Isso é essencial para identificar quais etapas do processo consomem mais tempo e analisar a eficiência dos recursos. Por que isso importa Permite calcular o tempo de processamento das atividades, algo fundamental para identificar tarefas demoradas e gargalos de performance. Onde encontrar Pode ser encontrado nas tabelas de trilha de auditoria ou histórico de Workflow do Fenergo, geralmente com nomes como 'EndDate' ou 'CompletionDate', ou pode ser derivado da hora de início do evento seguinte. Exemplos 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| Pontuação de risco RiskScore | Pontuação numérica que representa o nível de risco calculado para o cliente. | ||
| Descrição A pontuação de risco é uma medida quantitativa do risco potencial associado a um cliente, calculada com base em vários fatores, como jurisdição, setor e resultados da triagem. Em geral, o mecanismo de regras do Fenergo calcula essa pontuação. Este atributo permite relacionar os níveis de risco ao comportamento do processo. Por exemplo, a análise pode revelar se clientes de alto risco têm tempos de ciclo mais longos ou precisam de mais intervenção manual. Isso é útil para o Dashboard 'Análise detalhada de risco e Conformidade'. Por que isso importa Quantifica o risco do cliente e permite analisar como os níveis de risco afetam a duração do processo, o retrabalho e os resultados. Onde encontrar Este é um resultado essencial do módulo de avaliação de risco do cliente do Fenergo. Ele é armazenado na entidade do caso ou do cliente. Exemplos 154585 | |||
| Status da solicitação ApplicationStatus | Resultado atual ou final da solicitação do cliente. | ||
| Descrição Este atributo indica o resultado da solicitação ao fim do processo ou seu estado atual, caso ainda esteja em andamento. Os valores mais comuns incluem 'Aprovado', 'Rejeitado' ou 'Em andamento'. Esta é uma dimensão essencial para a análise de resultados. Ela permite filtrar e comparar os fluxos do processo de acordo com o resultado final, o que é fundamental para o Dashboard 'Retrabalho e rejeição de solicitações' e para calcular KPIs como a taxa de rejeição de solicitações. Por que isso importa Define o resultado de um caso e permite comparar os caminhos das solicitações aprovadas e rejeitadas e entender as taxas de sucesso. Onde encontrar Em geral, este é o status final registrado na entidade do caso no sistema de gestão de casos do Fenergo. Exemplos AprovadoRejeitadoAguardando ConformidadeEncerrado | |||
| Usuário que iniciou InitiatingUser | ID ou nome do usuário que realizou a atividade. | ||
| Descrição Este atributo identifica o funcionário ou usuário do sistema responsável por executar uma determinada tarefa ou evento. Pode ser um ID de usuário exclusivo, um nome ou uma função. A análise por usuário ajuda a entender a distribuição da carga de trabalho e a performance individual, além de identificar necessidades de treinamento. É essencial para o Dashboard 'Distribuição das atividades da equipe' e para aprofundar a análise das atividades realizadas por pessoas ou equipes específicas. Por que isso importa Registra qual usuário realizou uma ação e permite analisar a distribuição da carga de trabalho, a performance da equipe e a alocação de recursos. Onde encontrar Essas informações geralmente são armazenadas nos registros de auditoria ou nas tabelas de histórico de tarefas do Fenergo, junto com os detalhes do evento, com nomes como 'UserID', 'UserName' ou 'ModifiedBy'. Exemplos j.doea.smithSYSTEM | |||
| Canal da solicitação ApplicationChannel | Canal pelo qual a solicitação do cliente foi enviada. | ||
| Descrição Este atributo identifica a origem do envio da solicitação, por exemplo, um portal online, uma agência física ou um gerente de relacionamento. A origem pode influenciar a qualidade dos dados e os requisitos de processamento. Esta dimensão é usada no Dashboard 'Eficiência por origem e tipo de solicitação' para comparar a performance dos diferentes canais. Ela ajuda a entender quais canais são mais eficientes e quais podem precisar de otimização do processo. Por que isso importa Identifica a origem das solicitações e permite analisar a eficiência dos canais, os custos e a experiência do cliente. Onde encontrar Essas informações podem ser registradas em um formulário inicial de entrada de dados no Fenergo ou recebidas de um sistema anterior. Exemplos Portal onlineAgênciaGerente de relacionamentoAplicativo móvel | |||
| Contagem de solicitações de informações adicionais AdditionalInfoRequestCount | Número total de vezes que foram solicitadas informações adicionais para uma solicitação. | ||
| Descrição Esta métrica conta as ocorrências da atividade 'Informações adicionais solicitadas' em cada caso. Uma contagem maior indica mais trocas de informações, o que pode atrasar o processo e prejudicar a experiência do cliente. Este atributo dá suporte direto ao KPI 'Casos com solicitações de informações adicionais'. Ele é usado para identificar solicitações com um número excessivo de pedidos, o que pode indicar problemas na coleta inicial de dados ou requisitos complexos para o caso. Essa análise ajuda a simplificar a coleta de informações. Por que isso importa Quantifica o atrito para o cliente e os atrasos no processo causados por informações iniciais incompletas, ajudando a melhorar a etapa de coleta de dados. Onde encontrar Esta métrica calculada é obtida contando o número de eventos 'Informações adicionais solicitadas' para cada ID de 'CustomerApplication'. Exemplos 013 | |||
| É automatizada IsAutomated | Indicador booleano que mostra se a atividade foi realizada pelo sistema, e não por um usuário. | ||
| Descrição Este atributo diferencia as tarefas executadas automaticamente pelo sistema, como a triagem inicial e as verificações do sistema, daquelas realizadas manualmente por um usuário. Em geral, isso é determinado verificando se o usuário executor é uma conta de sistema ou de serviço. Analisar este indicador é essencial para entender o nível de automação do processo. Ele ajuda a quantificar o impacto da automação na eficiência, nos custos e na velocidade, além de identificar oportunidades para automatizar outras etapas. Por que isso importa Diferencia as atividades realizadas por pessoas daquelas realizadas pelo sistema, algo essencial para analisar a automação e entender os custos dos recursos. Onde encontrar Em geral, este atributo é derivado do campo 'InitiatingUser'. Uma lista de IDs de usuários do sistema conhecidos é usada para definir o indicador como verdadeiro. Exemplos truefalse | |||
| É retrabalho IsRework | Indicador booleano que mostra se uma atividade faz parte de um ciclo de retrabalho. | ||
| Descrição Este atributo identifica atividades que representam um retrocesso no processo, como voltar à 'Análise de documentos' depois do início da 'Análise de Conformidade' ou qualquer ocorrência de 'Informações adicionais solicitadas'. Identificar o retrabalho é essencial para entender as ineficiências e os pontos de atrito do processo. Este indicador permite calcular diretamente o KPI 'Taxa de ciclos de retrabalho' e ajuda a visualizar e quantificar o impacto de etapas repetitivas e sem valor no fluxo do processo. Por que isso importa Destaca ciclos de retrabalho ineficientes no processo, ajudando a quantificar o desperdício e identificar oportunidades de melhoria para aumentar a taxa de acerto na primeira tentativa. Onde encontrar Este indicador é derivado de técnicas de Process Mining que analisam a sequência das atividades. Por exemplo, se a 'Atividade A' é seguida pela 'Atividade B' e depois a 'Atividade A' ocorre novamente no mesmo caso, a segunda ocorrência da 'Atividade A' é retrabalho. Exemplos truefalse | |||
| Está em Conformidade com o SLA IsSlaCompliant | Indicador booleano que mostra se o caso foi concluído até a data-limite do SLA. | ||
| Descrição Este atributo é um indicador binário da performance do SLA em um caso concluído. Ele recebe o valor 'true' se a data e hora da atividade final de encerramento forem iguais ou anteriores a 'SlaTargetDate' e 'false' caso contrário. Este campo calculado simplifica o monitoramento e a geração de relatórios do SLA. Ele permite agregar dados facilmente para calcular o KPI geral 'Taxa de cumprimento do SLA' e filtrar os casos para analisar as características do processo em situações de Conformidade ou não com o SLA. Por que isso importa Mede diretamente a performance do SLA e permite calcular facilmente o KPI da taxa de cumprimento do SLA e filtrar os casos fora de Conformidade. Onde encontrar Este valor é derivado da comparação entre a data e hora da atividade final do caso, como 'Solicitação aprovada' ou 'Solicitação rejeitada', e 'SlaTargetDate'. Exemplos truefalse | |||
| ID do cliente CustomerId | Identificador exclusivo do cliente ou da entidade jurídica em processo de integração. | ||
| Descrição O ID do cliente é a referência exclusiva da entidade do cliente no sistema de dados mestres. Enquanto o número da solicitação é o ID do caso no processo, o ID do cliente vincula a atividade de integração a um cliente específico. Este atributo permite analisar o histórico de integração de um único cliente, por exemplo, para verificar se ele passou por vários processos de integração ao longo do tempo. Ele também permite combinar os dados do processo com outros dados relacionados ao cliente e obter uma visão de negócio mais abrangente. Por que isso importa Vincula o processo de integração a uma entidade de cliente exclusiva e permite fazer análises centradas no cliente e enriquecer os dados. Onde encontrar Este ID é armazenado no registro do cliente ou da entidade jurídica no Fenergo e associado ao caso de integração. Exemplos CUST-98765CUST-98766CUST-98767 | |||
| Motivo da rejeição RejectionReason | Código ou descrição que explica por que uma solicitação foi rejeitada. | ||
| Descrição Quando o status final de uma solicitação é 'Rejeitado', este atributo informa o motivo específico. Alguns exemplos são 'Reprovado na verificação de antecedentes', 'Documentação incompleta' ou 'Perfil de alto risco'. Este atributo é essencial para a análise de causa raiz de solicitações reprovadas. Ele dá suporte direto ao Dashboard 'Retrabalho e rejeição de solicitações', categorizando as falhas para ajudar a identificar problemas recorrentes e implementar ações corretivas que aumentem a taxa de aprovação na primeira tentativa. Por que isso importa Fornece insights essenciais sobre os motivos das falhas nas solicitações e permite fazer uma análise de causa raiz para reduzir as taxas de rejeição. Onde encontrar Geralmente, pode ser encontrado em um campo de código de motivo ou de observações associado ao status final de rejeição no Workflow do caso no Fenergo. Exemplos Correspondência com lista de sançõesDocumentos inválidosViolação de políticaCliente desistiu | |||
| País Country | País de domicílio ou jurisdição da solicitação do cliente. | ||
| Descrição Este atributo especifica o país associado ao cliente, que muitas vezes determina as regras regulatórias e os fatores de risco aplicáveis ao processo de integração. A análise do processo por país permite comparar tempos de ciclo, níveis de risco e complexidade entre jurisdições. Ela ajuda a entender como as diferenças regionais afetam a performance operacional e a garantir a Conformidade com as regulamentações locais. Por que isso importa Permite segmentar o processo por região geográfica, algo essencial para analisar o impacto regulatório e a performance regional. Onde encontrar Essas informações fazem parte dos dados principais do cliente, coletados durante o processo de solicitação e armazenados na entidade do cliente no Fenergo. Exemplos USAGBRSGPDEU | |||
| Responsável pelo caso CaseOwner | Usuário ou equipe responsável por gerenciar a solicitação durante todo o seu ciclo de vida. | ||
| Descrição O responsável pelo caso é a pessoa ou o grupo que assume a responsabilidade principal por um caso de integração. Em geral, essa pessoa ou grupo responde pela conclusão do caso dentro do prazo e com sucesso. Este atributo ajuda a analisar a carga de trabalho e a performance de quem gerencia os casos. Ele pode mostrar se determinados responsáveis têm tempos de ciclo mais longos ou taxas de rejeição mais altas, o que pode indicar necessidades de treinamento ou desequilíbrios na alocação de recursos. Por que isso importa Identifica a pessoa ou equipe responsável por um caso e permite analisar a performance de quem gerencia os casos. Onde encontrar Em geral, este é um campo específico da entidade principal do caso no Fenergo, que indica a atribuição do caso. Exemplos s.jonesonboarding_team_am.chen | |||
| Tipo de cliente CustomerType | Classificação do cliente em processo de integração, como pessoa física, empresa ou trust. | ||
| Descrição Este atributo divide os clientes em categorias de acordo com sua estrutura jurídica ou relação com a instituição financeira. Cada tipo de cliente costuma seguir um caminho de integração diferente, com níveis variados de complexidade e requisitos de due diligence. A análise do processo por tipo de cliente ajuda a identificar diferenças de performance entre os segmentos. Ela é essencial para o Dashboard 'Eficiência por origem e tipo de solicitação', que compara tempos de ciclo e taxas de aprovação e orienta melhorias específicas no processo. Por que isso importa Permite comparar a performance do processo entre diferentes segmentos de clientes, que muitas vezes têm níveis variados de complexidade e SLAs. Onde encontrar Essas informações geralmente são armazenadas na entidade do cliente no Fenergo e vinculadas ao caso da solicitação. Exemplos Pessoa físicaEmpresaTrustSociedade | |||
Atividades da integração de clientes KYC
| Atividade | Descrição | ||
|---|---|---|---|
| Análise de conformidade concluída | Marca a aprovação formal da equipe de conformidade e indica que todos os requisitos regulatórios foram atendidos. É inferida da conclusão de uma tarefa ou de uma mudança de status para 'Conformidade aprovada'. | ||
| Por que isso importa Como marco importante, a conclusão desta atividade é essencial para o tempo de ciclo total. Ela encerra o período usado para medir o 'Tempo médio de análise de conformidade' e identificar gargalos na função de conformidade. Onde encontrar Inferida da data e hora de conclusão da tarefa 'Análise de conformidade' no fluxo de trabalho da Fenergo ou do evento de atualização de status no histórico do caso. Coleta Use a data e hora de conclusão da tarefa de análise de conformidade ou da atualização de status. Tipo de evento inferred | |||
| Análise de conformidade iniciada | Esta atividade marca o início da análise pela equipe de conformidade, uma etapa crítica e muitas vezes demorada. Ela é inferida quando o caso é atribuído à fila de trabalho da equipe ou quando o status muda para 'Aguardando análise de conformidade'. | ||
| Por que isso importa Esta atividade é o ponto de partida para medir o KPI 'Tempo médio de análise de conformidade'. Ela ajuda a identificar quanto tempo os casos aguardam antes de começarem a ser tratados pela equipe de conformidade. Onde encontrar Inferida do log de auditoria do caso na Fenergo, registrando a data e hora da mudança de status para 'Em análise de conformidade' ou da atribuição do caso a um responsável ou equipe de conformidade. Coleta Identifique a data e hora da mudança de status para 'Em análise de conformidade' ou o evento de atribuição. Tipo de evento inferred | |||
| Análise de documentos concluída | Indica a conclusão do processo manual ou automatizado de verificação da autenticidade e da exatidão de todos os documentos enviados pelo cliente. Em geral, esse evento é inferido da conclusão de uma tarefa do fluxo de trabalho ou de uma mudança de status na Fenergo. | ||
| Por que isso importa Este é um marco crítico em que ocorrem muitos atrasos. Analisar a duração e os resultados dessa atividade ajuda a localizar gargalos no processamento de documentos e a acompanhar KPIs como 'Taxa de aprovação na primeira tentativa'. Onde encontrar Inferida da data e hora de conclusão da tarefa 'Verificação de documentos' no fluxo de trabalho do caso ou de uma atualização de status para 'Documentos aprovados' no log do histórico do caso. Coleta Use a data e hora de conclusão da tarefa de análise de documentos ou de uma mudança de status relacionada. Tipo de evento inferred | |||
| Avaliação de risco concluída | Representa a conclusão do processo interno de classificação de risco, no qual o cliente recebe uma classificação com base em vários fatores. Essa conclusão é inferida de uma mudança de status ou do preenchimento de um campo de classificação de risco. | ||
| Por que isso importa Este é um marco importante para a tomada de decisões, que muitas vezes determina o caminho seguinte do fluxo de trabalho. Analisar sua duração ajuda a simplificar uma etapa crítica de conformidade e a garantir consistência na avaliação de riscos. Onde encontrar Inferida do log do histórico do caso, identificando quando o status muda para algo como 'Risco avaliado' ou quando o campo final 'Classificação de risco do cliente' é preenchido. Coleta Use a data e hora em que a classificação de risco é finalizada ou em que um status relacionado é definido. Tipo de evento inferred | |||
| Caso criado | Esta atividade marca o início do processo de integração para KYC, quando uma nova solicitação de cliente é criada formalmente na Fenergo. Em geral, é um evento explícito, registrado com uma data e hora específicas quando o registro do caso é salvo pela primeira vez. | ||
| Por que isso importa Como evento de início, esta atividade é essencial para calcular o tempo de ciclo total da integração e analisar o volume processado. Ela serve de referência para todas as medições seguintes do processo e para o acompanhamento dos SLAs. Onde encontrar Em geral, essa informação é obtida da data e hora de criação da entidade principal do caso na Fenergo, normalmente em tabelas relacionadas a casos ou fluxos de trabalho de integração de clientes. Coleta Use a data e hora de criação do registro do caso de integração. Tipo de evento explicit | |||
| Caso encerrado | Esta é a atividade final, que indica que o caso de integração foi encerrado administrativamente no Fenergo e que nenhuma outra ação é esperada. Isso se aplica tanto às solicitações aprovadas quanto às rejeitadas e pode ser inferido a partir do status final 'Encerrado'. | ||
| Por que isso importa Esta atividade marca o ponto final de todo o processo. Ela garante o cálculo preciso do tempo de ciclo de todos os casos, independentemente do resultado, e confirma que o processo foi concluído. Onde encontrar Inferido a partir do registro de auditoria do caso no Fenergo, identificando a data e hora em que o status do caso é definido como 'Encerrado', 'Concluído' ou outro estado final. Coleta Identifique a data e hora da alteração final de status para 'Encerrado' ou 'Concluído'. Tipo de evento inferred | |||
| Solicitação aprovada | Esta atividade representa a decisão final de aprovar a solicitação de integração do cliente. É inferida quando o status do caso muda para um estado final como 'Aprovado' ou 'Integração aprovada'. | ||
| Por que isso importa Este marco importante indica um resultado bem-sucedido antes das etapas finais de ativação da conta. É essencial para calcular as taxas de aprovação e analisar as características dos clientes integrados com sucesso. Onde encontrar Inferida do histórico ou do log de auditoria do caso, identificando a data e hora da mudança final de status para 'Aprovado' ou outro estado positivo equivalente. Coleta Identifique a data e hora da mudança final de status para 'Aprovado'. Tipo de evento inferred | |||
| Solicitação rejeitada | Esta atividade é um evento final que representa a decisão definitiva de rejeitar a solicitação de integração do cliente. É inferida quando o status do caso muda para um estado final como 'Rejeitado' ou 'Recusado'. | ||
| Por que isso importa Como etapa final importante do processo, esta atividade é essencial para calcular a 'Taxa de rejeição de solicitações' e analisar os motivos das falhas. Ela ajuda a identificar os motivos mais comuns de rejeição e a melhorar a qualidade das solicitações. Onde encontrar Inferida do log de auditoria do caso, registrando a data e hora em que o status final muda para 'Rejeitado'. O motivo da rejeição costuma ser armazenado em um campo relacionado. Coleta Identifique a data e hora da mudança final de status para 'Rejeitado'. Tipo de evento inferred | |||
| Conta ativada | Indica que a conta do cliente foi criada e ativada com sucesso no sistema bancário central ou no sistema subsequente relevante após a aprovação. Isso pode ser inferido a partir de uma atualização de status final no Fenergo após a aprovação. | ||
| Por que isso importa Esta atividade confirma a transferência bem-sucedida do processo de integração para o status de cliente ativo. Medir o tempo entre a aprovação e a ativação pode revelar atrasos na configuração operacional. Onde encontrar Isso pode ser inferido a partir de um status do caso, como 'Conta ativa' ou 'Integração concluída'. Também pode ser um evento explícito registrado por uma integração com um sistema subsequente. Coleta Procure uma alteração de status após a aprovação ou um evento de registro de integração bem-sucedida. Tipo de evento inferred | |||
| Dados e documentos solicitados | Este evento indica que o sistema ou um agente de integração solicitou formalmente ao cliente as informações e os documentos necessários. Em geral, é registrado como um evento explícito quando um Template de comunicação padronizado é enviado. | ||
| Por que isso importa Esta atividade marca o início de uma etapa que depende do cliente. Medir o tempo entre esse momento e o recebimento dos documentos é essencial para analisar a jornada do cliente e identificar atrasos na comunicação. Onde encontrar Obtida de um Event Log de comunicações com o cliente ou do log de conclusão da tarefa 'Solicitar documentos'. Também pode ser inferida de uma mudança de status para 'Aguardando informações do cliente'. Coleta Procure um evento registrado de comunicação com o cliente ou a conclusão de uma tarefa. Tipo de evento explicit | |||
| Documentos recebidos | Esta atividade indica que o cliente carregou ou enviou os documentos necessários, que agora estão disponíveis na Fenergo para análise. Em geral, é inferida quando o status do caso muda para 'Documentos recebidos' ou 'Aguardando análise'. | ||
| Por que isso importa Este marco encerra o período de espera do cliente e inicia o ciclo de análise interna. É essencial para medir o tempo de resposta do cliente e o tempo de espera nas filas internas de processamento. Onde encontrar Inferida da trilha de auditoria do caso, que registra a data e hora da mudança de status para 'Documentos recebidos' ou um estado semelhante. Também pode estar associada a eventos de carregamento de documentos. Coleta Identifique a data e hora da mudança de status para 'Documentos recebidos' ou 'Pronto para análise'. Tipo de evento inferred | |||
| Informações adicionais solicitadas | Representa um ciclo de retrabalho em que a equipe de integração precisa voltar ao cliente para esclarecer dúvidas ou solicitar documentos ausentes. É um evento explícito, geralmente registrado quando uma comunicação é enviada ao cliente. | ||
| Por que isso importa Esta atividade é um dos principais indicadores de ineficiência do processo e de uma experiência ruim para o cliente. Acompanhar sua frequência ajuda a identificar as causas raiz do retrabalho e a monitorar o KPI 'Taxa de ciclos de retrabalho'. Onde encontrar Obtida de um Event Log de comunicações com o cliente ou de uma mudança de status para 'Aguardando informações adicionais'. A primeira opção é mais precisa para registrar o momento exato da solicitação. Coleta Procure eventos de comunicação registrados ou uma mudança de status para 'Aguardando resposta do cliente'. Tipo de evento explicit | |||
| Triagem inicial realizada | Representa a conclusão das verificações preliminares, automatizadas ou manuais, como a validação básica de dados ou a consulta a listas de sanções. Muitas vezes, é inferida a partir de uma mudança de status no fluxo de trabalho do caso na Fenergo, por exemplo, de 'Novo' para 'Triagem concluída'. | ||
| Por que isso importa Acompanhar esse marco inicial ajuda a identificar problemas de qualidade dos dados e gargalos na etapa de pré-qualificação. Também permite separar a fase inicial automatizada dos processos de análise manual mais intensivos. Onde encontrar Inferida do histórico do caso ou do log de auditoria, identificando a data e hora em que o status muda para indicar que a triagem foi concluída, como 'Triagem aprovada' ou 'Aguardando documentos'. Coleta Identifique no histórico do caso a mudança de status para 'Triagem concluída' ou equivalente. Tipo de evento inferred | |||
| Verificações de antecedentes iniciadas | Esta atividade marca o momento em que são iniciadas verificações externas de antecedentes, AML ou crédito. Em geral, é um evento explícito registrado quando uma integração com um serviço de terceiros é acionada. | ||
| Por que isso importa Acompanhar o início e a conclusão dessas verificações é essencial para entender os atrasos causados por dependências externas. Isso ajuda a separar o tempo do processo interno do tempo de espera externo. Onde encontrar Em geral, essa informação é obtida dos logs do sistema que registram chamadas de API a provedores externos de triagem ou da criação de uma tarefa específica de 'Verificação de antecedentes' no caso da Fenergo. Coleta Procure logs de integrações com serviços externos ou a criação de uma tarefa de 'Triagem'. Tipo de evento explicit | |||
Guias de extração
Etapas
- Acesse o módulo de relatórios: Entre no aplicativo Fenergo com uma conta de usuário que tenha as permissões necessárias para o módulo de relatórios e análises. Acesse o módulo, geralmente disponível no menu principal do aplicativo.
- Crie um novo relatório: Inicie a criação de um relatório personalizado. Escolha um nome e uma descrição que indiquem claramente a finalidade, por exemplo, 'Event Log de integração KYC para Process Mining'.
- Defina a fonte de dados principal: Selecione o objeto ou a visualização de dados que registra o ciclo de vida do caso. Geralmente, é uma visualização pré-configurada, como
[CaseWorkflowHistory]ou[LifecycleEventsView]. Esse objeto deve conter identificadores de caso, nomes de eventos ou status e datas e horas. - Configure as colunas do relatório (atributos): Use a interface de criação de relatórios para adicionar colunas. Mapeie os campos de origem do modelo de dados do Fenergo para os atributos necessários no Event Log. Por exemplo, mapeie
CaseIDdo Fenergo paraCustomerApplication,EventTimestampparaEventStartTimeeEventPerformerparaInitiatingUser. - Defina a lógica das atividades: Esta é a etapa mais importante. Configure o relatório para gerar uma linha separada para cada uma das 14 atividades necessárias. Para isso, crie blocos lógicos ou conjuntos de dados filtrados para cada atividade e combine-os usando UNION ou uma função equivalente no criador de relatórios.
- Defina a lógica de 'Case Created': Crie o primeiro bloco. Filtre a fonte de dados pelo evento inicial de criação do caso. Isso geralmente se baseia na data e hora mais antiga associada ao caso ou em um tipo de evento chamado 'Case Created'. Mapeie
CreationDateparaEventStartTime. - Defina a lógica das atividades com base no status: Para atividades identificadas por mudanças de status, como 'Documents Received' e 'Application Approved', crie blocos separados. Filtre a fonte de dados pelo valor específico do campo
Statuse useStatusChangeDatecomoEventStartTime. - Defina a lógica das atividades com base em tarefas: Para atividades associadas a tarefas do Workflow, como 'Compliance Review Completed', crie blocos que filtrem por
TaskNameeTaskCompletionDate. Use a data de conclusão comoEventStartTime. - Defina os filtros gerais do relatório: Aplique filtros ao relatório para delimitar os dados. Defina um
Date Rangeespecífico paraEventStartTimee evite exportações muito grandes. Para a análise inicial, recomendamos um período de 3 a 6 meses. Filtre pelo tipo de caso específico, como 'KYC Customer Onboarding'. - Execute e confira o relatório: Execute o relatório na interface do Fenergo. Confira as primeiras 100 a 200 linhas para verificar se a estrutura dos dados está correta, se todas as colunas foram preenchidas como esperado e se há diferentes atividades.
- Exporte os dados: Exporte todos os resultados do relatório para um arquivo CSV ou Excel. Esse será o arquivo bruto do Event Log.
- Prepare os dados finais: Abra o arquivo CSV exportado. Se não foi possível gerar diretamente as colunas
SourceSystemeLastDataUpdateno relatório, adicione-as manualmente. Defina 'Fenergo' comoSourceSystemem todas as linhas e use a data e hora da exportação comoLastDataUpdate.
Configuração
- Pré-requisitos: O usuário precisa ter acesso ao módulo de relatórios e análises do Fenergo e permissão para criar e executar relatórios personalizados.
- Principais fontes de dados: O relatório deve usar principalmente os objetos de gerenciamento de casos e histórico de Workflow do Fenergo. Entre as fontes comuns estão
[CaseDetails],[CaseStatusHistory]e[WorkflowTaskHistory]. Os nomes exatos podem variar conforme a configuração do Fenergo. - Período: É essencial definir um filtro de período para a data e hora do evento e manter a performance. Comece com os 3 a 6 meses mais recentes. Para análises históricas, execute o relatório em lotes, por exemplo, por trimestre ou ano.
- Principais filtros: Sempre filtre pelo processo ou tipo de caso específico, como 'KYC Customer Onboarding', para excluir dados irrelevantes. Dependendo dos objetivos da análise, talvez também seja necessário filtrar pelo tipo de entidade jurídica ou pela jurisdição.
- Definição das atividades: Defina cada atividade usando critérios de filtro específicos em campos como
Status,TaskNameou um campo dedicadoEventType. Esses campos são essenciais para isolar cada evento do processo. - Considerações de performance: Relatórios que combinam muitas fontes de dados ou abrangem um período extenso podem ser lentos. Se possível, programe a execução fora dos horários de pico. Evite incluir colunas desnecessárias na exportação, pois isso aumenta o tempo de processamento.
Consulta de exemplo sql
/*
This is a logical representation of the configuration needed in the Fenergo Reporting & Analytics module.
The module uses a graphical interface, but this query structure illustrates the required data sources, filters, and unions.
Fields like [CaseLifecycleData].[CaseID] are placeholders for actual Fenergo fields selected in the UI.
*/
-- Base data selection for common attributes
WITH CaseAttributes AS (
SELECT
C.CaseID AS CustomerApplication,
C.SlaTargetDate AS SlaTargetDate,
C.FinalRiskScore AS RiskScore,
C.CurrentStatus AS ApplicationStatus
FROM [CaseDetails] C
WHERE C.CaseType = 'KYC Customer Onboarding'
)
-- 1. Case Created
SELECT
A.CustomerApplication,
'Case Created' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
L.CompletionTimestamp AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CASE_CREATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 2. Initial Screening Performed
SELECT
A.CustomerApplication,
'Initial Screening Performed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Initial Screening' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 3. Data & Documents Requested
SELECT
A.CustomerApplication,
'Data & Documents Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Initial Document Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 4. Documents Received
SELECT
A.CustomerApplication,
'Documents Received' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 5. Document Review Completed
SELECT
A.CustomerApplication,
'Document Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Document Verification' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 6. Background Checks Initiated
SELECT
A.CustomerApplication,
'Background Checks Initiated' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'EXTERNAL_CHECK_INITIATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 7. Risk Assessment Completed
SELECT
A.CustomerApplication,
'Risk Assessment Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Risk Assessment' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 8. Compliance Review Initiated
SELECT
A.CustomerApplication,
'Compliance Review Initiated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Compliance Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 9. Additional Information Requested
SELECT
A.CustomerApplication,
'Additional Information Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Additional Information Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 10. Compliance Review Completed
SELECT
A.CustomerApplication,
'Compliance Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Compliance Review' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 11. Application Approved
SELECT
A.CustomerApplication,
'Application Approved' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Approved'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 12. Application Rejected
SELECT
A.CustomerApplication,
'Application Rejected' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Rejected'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 13. Account Activated
SELECT
A.CustomerApplication,
'Account Activated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Active'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 14. Case Closed
SELECT
A.CustomerApplication,
'Case Closed' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Closed'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]' Pronto para começar?
Com este Template de dados, você já pode identificar ineficiências e simplificar a integração de clientes KYC no Fenergo. Comece hoje a otimizar as operações e melhorar a satisfação dos clientes.
Simplifique a integração de clientes KYC e acelere as aprovações
Junte-se às empresas que reduziram o tempo de integração para apenas 24 horas.
Não é necessário informar o cartão de crédito. Comece em poucos minutos.