Seu Template de dados para processamento de sinistros
Seu Template de dados para processamento de sinistros
Este é nosso Template genérico de dados para Process Mining de Processamento de sinistros. Use os Templates específicos de cada sistema para receber orientações mais detalhadas.
Selecione um sistema específico- Orientações estruturadas sobre os atributos de dados essenciais.
- Atividades essenciais do processo para uma visão completa da jornada.
- Uma estrutura flexível, aplicável a qualquer sistema de sinistros.
Atributos do processamento de sinistros
| Nome | Descrição | ||
|---|---|---|---|
| Hora de início StartTime | Data e hora que indicam quando uma atividade ou um evento específico começou. | ||
| Descrição A hora de início indica com precisão a data e a hora em que uma atividade começou. É um dado essencial de cada evento no registro do processo, pois fornece o contexto temporal necessário para analisar a performance. Na mineração de processos, a hora de início é essencial para ordenar os eventos cronologicamente e reconstruir com precisão a jornada do caso. Ela serve de base para calcular indicadores-chave de performance, como tempos de ciclo, tempos de espera e tempos de processamento. Analisar as datas e horas ajuda a identificar atrasos entre etapas, medir o cumprimento dos acordos de nível de serviço (SLAs) e entender a dinâmica temporal do processo de sinistros. Por que isso importa Essa data e hora são essenciais para ordenar os eventos corretamente e calcular todas as métricas relacionadas ao tempo, como tempos de ciclo e gargalos. Onde encontrar Geralmente, é registrada em Event Logs, trilhas de auditoria ou dados de transações, com nomes como 'hora do evento' ou 'data de criação'. Exemplos 2023-03-15T09:00:00Z2023-05-20T14:35:10Z2023-07-01T11:21:05Z | |||
| ID do sinistro ClaimId | Identificador único de um sinistro, usado como ID principal do caso na mineração de processos. | ||
| Descrição O ID do sinistro é uma chave única atribuída a cada sinistro no momento do registro. Ele funciona como o elo central entre todas as atividades, os eventos e os dados relacionados ao longo do ciclo de vida do sinistro, do envio inicial ao encerramento. Na mineração de processos, o ID do sinistro é fundamental para reconstruir a jornada completa de cada caso. Ao agrupar todos os eventos com o mesmo ID, o software pode visualizar o fluxo do processo, identificar variações e calcular métricas por caso. Assim, cada ação, da atribuição ao regulador de sinistros à emissão do pagamento, é associada corretamente ao sinistro correspondente, permitindo uma análise coerente e precisa do processo. Por que isso importa Este é o identificador essencial do caso, que conecta todos os eventos relacionados e permite acompanhar a jornada completa de cada sinistro. Onde encontrar Geralmente, fica no cabeçalho ou no registro principal do arquivo do sinistro ou da transação no sistema de gestão de sinistros. Exemplos CL-2023-001234A789-C54329876543210 | |||
| Nome da atividade ActivityName | Nome da atividade de negócio ou do evento ocorrido em um momento específico do sinistro. | ||
| Descrição O nome da atividade descreve uma etapa, tarefa ou evento específico do ciclo de vida do processamento de sinistros. Essas atividades representam o trabalho realizado, como 'Sinistro registrado', 'Investigação iniciada' ou 'Pagamento emitido'. Cada atividade é um ponto distinto do processo, registrado no Event Log. Na análise de Process Mining, as atividades são os elementos que compõem o mapa do processo. Analisar a sequência, a frequência e a duração dessas atividades revela o fluxo real do processo, os caminhos mais comuns, os gargalos e os desvios do procedimento padrão. Usar nomes de atividade claros e consistentes é essencial para criar um modelo de processo compreensível e que ajude a definir ações. Por que isso importa As atividades são a base do mapa do processo. Elas definem as etapas e tarefas cuja sequência e duração são analisadas para entender a performance do processo. Onde encontrar Geralmente, aparece em Event Logs, trilhas de auditoria ou registros de transações no sistema de gestão de sinistros. Exemplos Sinistro registradoPrejuízo avaliadoPagamento emitidoSinistro negado | |||
| Sistema de origem SourceSystem | Sistema oficial de registro de onde os dados do evento foram extraídos. | ||
| Descrição O atributo Sistema de origem identifica o aplicativo ou a plataforma de TI em que a atividade foi registrada originalmente. Em ambientes complexos, os dados de processamento de sinistros podem vir de vários sistemas, como uma plataforma central de sinistros, um sistema de gestão de documentos ou uma ferramenta de gestão do relacionamento com o cliente (CRM). Conhecer o sistema de origem ajuda a validar os dados e analisar a fragmentação do processo. Isso permite rastrear problemas de qualidade dos dados até a origem e pode revelar ineficiências causadas por transferências manuais de dados ou de trabalho entre sistemas. Essa análise pode apontar oportunidades para melhorar a integração entre sistemas e a automação. Por que isso importa Identifica a origem dos dados dos eventos, algo essencial para validar os dados e analisar a execução do processo em vários sistemas de TI. Onde encontrar Essa informação pode fazer parte da lógica de extração de dados ou estar armazenada em um campo dos Event Logs dos sistemas integrados. Exemplos Plataforma de gestão de sinistrosPortal de CRMSistema de gestão de documentos | |||
| Última atualização dos dados LastDataUpdate | Data e hora da atualização ou extração mais recente de dados do sistema de origem. | ||
| Descrição Última atualização dos dados indica quando os dados do Event Log foram atualizados pela última vez a partir dos sistemas de origem. Essa data e hora mostram o quão recentes são os dados analisados e ajudam as pessoas envolvidas a entender sua atualidade. Em qualquer análise de processo, saber quando os dados foram atualizados é essencial para tomar decisões fundamentadas. Esse atributo ajuda a entender se você está vendo um processo quase em tempo real ou um retrato histórico. Ele é especialmente importante para o monitoramento contínuo em Dashboards e para garantir que as conclusões se baseiem em informações relevantes e atualizadas. Por que isso importa Fornece um contexto importante sobre a atualidade dos dados e ajuda a garantir que as análises e decisões se baseiem em informações atualizadas. Onde encontrar Geralmente, são metadados gerados durante o processo de extração, transformação e carregamento de dados (ETL). Exemplos 2023-10-26T02:00:00Z2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Data prevista para resolução ResolutionTargetDate | Data prevista para a resolução do sinistro, definida com base em acordos de nível de serviço (SLAs) ou regulamentações. | ||
| Descrição A data prevista para resolução, ou data de vencimento, é o prazo para concluir o processo de sinistro. Esse prazo costuma ser definido por exigências regulatórias ou por acordos internos de nível de serviço (SLAs), criados para garantir um atendimento ágil ao cliente. Esse atributo é fundamental para monitorar a conformidade e a performance. Ao comparar a data real de encerramento do sinistro com a data prevista, as organizações podem medir a taxa de cumprimento dos SLAs. A mineração de processos pode destacar as etapas ou variantes com maior probabilidade de levar ao descumprimento de um SLA. Isso permite gerenciar os prazos de forma proativa e priorizar melhorias que contribuam mais para uma resolução dentro do prazo, apoiando diretamente o Dashboard 'Cumprimento de SLAs e prazos'. Por que isso importa Permite medir o cumprimento de SLAs ou prazos regulatórios, um indicador essencial da eficácia do processo. Onde encontrar Geralmente, é calculada com base em regras de negócio quando o sinistro é criado e armazenada no registro principal. Exemplos 2023-04-142023-06-192023-08-30 | |||
| Departamento Department | Unidade de negócio, equipe ou departamento responsável por tratar a atividade ou o sinistro em determinado momento. | ||
| Descrição O atributo Departamento especifica o grupo organizacional responsável pelo sinistro em uma etapa específica do ciclo de vida. Alguns exemplos são 'Aviso inicial de sinistro', 'Unidade de investigação' e 'Departamento de pagamentos'. Essa informação é essencial para entender as transferências de trabalho e a colaboração entre diferentes áreas da organização. Analisar o processo por departamento pode revelar atrasos quando um sinistro passa de uma equipe para outra. Isso ajuda a identificar gargalos entre departamentos e é essencial para avaliar a carga de trabalho e a performance de cada equipe, além de apoiar KPIs como Equilíbrio da carga de trabalho dos reguladores e Dashboards sobre a performance da equipe. Por que isso importa Ajuda a analisar as transferências de trabalho entre equipes e a identificar gargalos entre departamentos, apoiando a análise da performance organizacional. Onde encontrar Geralmente, fica armazenado no registro do sinistro, associado ao usuário atribuído ou à etapa atual do processo. Exemplos Equipe de entradaUnidade de investigações especiaisAvaliação de responsabilidadeFinanças e pagamentos | |||
| Gravidade do sinistro ClaimSeverity | Classificação da complexidade estimada ou do possível impacto financeiro do sinistro, como baixo, médio ou alto. | ||
| Descrição Gravidade do sinistro indica a complexidade, a urgência ou o possível custo financeiro do caso. Essa classificação ajuda a priorizar sinistros e encaminhá-los a reguladores com o nível de experiência adequado. A gravidade pode ser definida por fatores como o valor estimado do prejuízo, a natureza do incidente ou a existência de um processo judicial. Analisar o processo por gravidade do sinistro é essencial para entender se os procedimentos de tratamento estão adequados a cada caso. Por exemplo, é esperado que sinistros graves tenham tempos de ciclo mais longos, mas também que sigam uma investigação mais rigorosa. Esse atributo ajuda a verificar se casos complexos recebem a atenção necessária e se casos simples são processados rapidamente, otimizando a alocação de recursos e a satisfação do cliente. Por que isso importa Ajuda a diferenciar sinistros simples de complexos e permite avaliar se a execução do processo está adequada à complexidade de cada caso. Onde encontrar Muitas vezes, é definida por regras de negócio na entrada do sinistro e armazenada em um campo do registro principal. Exemplos BaixaMédiaAltaCatastrófica | |||
| Hora de término EndTime | Data e hora que indicam quando uma atividade ou um evento específico foi concluído. | ||
| Descrição A hora de término indica com precisão a data e a hora em que uma atividade foi concluída. Quando esse dado está disponível junto com a hora de início, é possível medir exatamente quanto tempo a atividade levou. Esse atributo é muito útil para uma análise detalhada da performance. A diferença entre a hora de início e a hora de término corresponde ao tempo de processamento ou à duração da atividade, uma métrica importante para identificar etapas ineficientes. Analisar os tempos de processamento ajuda a identificar quais atividades consomem mais recursos e onde concentrar os esforços para simplificar as operações. Esse dado é fundamental para criar Dashboards sobre gargalos do processo e performance da equipe. Por que isso importa Permite calcular com precisão os tempos de processamento das atividades, algo essencial para identificar gargalos e analisar a eficiência dos recursos. Onde encontrar Geralmente, aparece em Event Logs ou trilhas de auditoria junto com a hora de início. Pode ser necessário calculá-la quando apenas as mudanças são registradas. Exemplos 2023-03-15T11:30:00Z2023-05-20T15:05:45Z2023-07-01T11:29:15Z | |||
| Regulador de sinistros atribuído AssignedAdjuster | Nome ou ID do usuário, como um regulador de sinistros, responsável por tratar o sinistro ou realizar a atividade. | ||
| Descrição O atributo Regulador de sinistros atribuído identifica o funcionário ou usuário que realizou uma atividade específica ou que é responsável pelo sinistro em determinado momento. Esse atributo associa as etapas do processo às pessoas que as executam. Analisar os dados por regulador é essencial para gerenciar a carga de trabalho, avaliar a performance e identificar necessidades de treinamento. Isso permite que os gerentes comparem a performance entre integrantes da equipe, distribuam o trabalho de forma equilibrada e identifiquem quem tem alto desempenho ou precisa de mais apoio. Essa visão dos recursos é fundamental para Dashboards sobre a performance da equipe e o equilíbrio da carga de trabalho. Por que isso importa Relaciona as atividades do processo às pessoas que as realizam, permitindo analisar a carga de trabalho, a performance da equipe e a alocação de recursos. Onde encontrar Pode ser encontrado em registros de transações, logs de auditoria ou campos de atribuição de usuários no sistema de gestão de sinistros. Exemplos John SmithUSER789Emily Jonesadjuster_team_a | |||
| Tipo de sinistro ClaimType | Categoria do sinistro, que ajuda a segmentar e comparar a performance do processo entre diferentes tipos de sinistro. | ||
| Descrição Tipo de sinistro é uma classificação baseada na linha de negócio ou na natureza do prejuízo, como 'Automóvel', 'Patrimônio', 'Responsabilidade civil' ou 'Incapacidade'. Cada tipo de sinistro pode seguir um fluxo diferente, com níveis de complexidade e SLAs próprios. Segmentar a análise do processo por tipo de sinistro é uma técnica fundamental para obter insights relevantes. Isso permite comparar tempos de ciclo, custos e conformidade do processo entre diferentes categorias. A análise pode revelar, por exemplo, que um processo eficiente para sinistros de automóvel é ineficiente para sinistros patrimoniais, orientando ações de melhoria específicas. Esse atributo é essencial para o Dashboard 'Performance por categoria de sinistro'. Por que isso importa Permite segmentar os sinistros para comparar processos e performance entre diferentes linhas de negócio e identificar problemas específicos de cada categoria. Onde encontrar Campo padrão do registro principal do sinistro, geralmente preenchido quando o sinistro é criado. Exemplos AutomóvelPatrimônioAcidentes de trabalhoResponsabilidade civil geral | |||
| Valor da indenização SettlementAmount | Valor financeiro final pago ao segurado ou a terceiros para resolver o sinistro. | ||
| Descrição O valor da indenização corresponde ao total pago para liquidar um sinistro. É uma métrica de resultado importante, que reflete o impacto financeiro do caso. Geralmente, esse valor é definido após a avaliação do prejuízo e a tomada de uma decisão. Na mineração de processos, esse atributo é essencial para análises de custos. Ele permite calcular KPIs como 'Custo médio por sinistro' e investigar como as variações do processo afetam os resultados financeiros. Por exemplo, a análise pode mostrar que sinistros com ciclos de retrabalho ou tempos de ciclo mais longos tendem a resultar em indenizações maiores. Isso relaciona diretamente a eficiência do processo à performance financeira e serve de base para o Dashboard 'Análise de custos de sinistros'. Por que isso importa Esta é uma métrica de resultado importante, que relaciona diretamente o comportamento do processo ao impacto financeiro e permite analisar o custo-benefício das melhorias. Onde encontrar Fica nos registros financeiros ou de pagamento associados ao sinistro e é finalizado quando o sinistro é encerrado ou pago. Exemplos 1500.0025000.50125.750.00 | |||
| Canal de envio SubmissionChannel | Método ou canal usado para enviar o sinistro inicialmente. | ||
| Descrição Canal de envio identifica como o sinistro foi comunicado inicialmente à empresa. Entre os canais mais comuns estão o portal do cliente, um aplicativo para celular, um agente, um corretor ou o correio tradicional. Analisar o processo por canal de envio pode revelar diferenças importantes na qualidade dos dados, na eficiência e na experiência do cliente. Por exemplo, sinistros enviados por um portal digital podem ter menos erros de entrada de dados e tempos de processamento inicial menores do que os enviados pelo correio. Esses insights podem orientar decisões estratégicas sobre quais canais promover e onde investir em automação e melhoria de processos. Por que isso importa Ajuda a analisar como o canal de entrada afeta a eficiência do processo, a qualidade dos dados e o tempo total de ciclo. Onde encontrar Geralmente, é registrado durante o processo de primeiro aviso de sinistro (FNOL) e armazenado no registro principal do sinistro. Exemplos Portal da webAnalistaTelefoneCorrespondência | |||
| Data do sinistro LossDate | Data em que ocorreu o incidente ou prejuízo que deu origem ao sinistro. | ||
| Descrição A data do sinistro indica quando o evento ocorreu de fato, como um acidente de carro ou um dano ao imóvel. Ela é diferente da data em que o sinistro foi comunicado ou registrado no sistema. O intervalo entre a data do sinistro e a data de registro é conhecido como atraso na comunicação. Analisar esse intervalo ajuda a entender o comportamento dos clientes e a identificar possíveis riscos de fraude, como atrasos incomuns na comunicação. Essa informação oferece uma visão mais completa da experiência com o sinistro, do incidente à resolução, e amplia a análise para além do tempo de processamento interno. Por que isso importa Registra a data do incidente e permite analisar atrasos na comunicação e o período completo entre o evento e o encerramento. Onde encontrar Informada pelo solicitante no aviso inicial do sinistro e armazenada no registro principal. Exemplos 2023-03-102023-05-182023-06-25 | |||
| Motivo da negativa DenialReason | Motivo específico informado quando um sinistro é negado ou recusado. | ||
| Descrição O motivo da negativa é um código ou uma descrição que explica por que o sinistro não foi indenizado. Os motivos podem incluir falta de cobertura na apólice, suspeita de fraude ou ausência de documentos obrigatórios. Analisar os motivos das negativas é essencial para identificar oportunidades de melhoria nos processos internos e na comunicação com os clientes. Por exemplo, se muitos sinistros forem negados por falta de informações, pode ser necessário aprimorar o processo de abertura. A análise de causa raiz dos motivos das negativas pode levar a uma linguagem mais clara nas apólices, a uma melhor orientação dos clientes e à redução do esforço administrativo com sinistros que acabarão sendo negados. Por que isso importa Mostra por que os sinistros não são indenizados e permite analisar as causas raiz para melhorar a comunicação com os clientes e os processos iniciais. Onde encontrar Selecionado em uma lista predefinida ou informado como texto pelo regulador quando ocorre a atividade "Sinistro negado". Exemplos Sem cobertura na apóliceSuspeita de fraudeDocumentação incompletaSinistro duplicado | |||
| Número da apólice PolicyNumber | Identificador único da apólice de seguro vinculada ao sinistro. | ||
| Descrição O número da apólice é a referência única do contrato de seguro que cobre o prejuízo informado. Ele vincula o sinistro a um cliente específico, às condições da apólice, aos limites de cobertura e a outros detalhes contratuais. Embora nem sempre seja usado diretamente na análise do fluxo do processo, o número da apólice é uma informação contextual essencial. Ele permite agregar dados de sinistros por apólice ou cliente, o que pode revelar padrões, como a ocorrência frequente de sinistros de um mesmo segurado. Também permite enriquecer os dados de sinistros com informações da apólice, como tipo de cobertura e valor segurado, para análises e segmentações mais avançadas. Por que isso importa Vincula o sinistro ao contrato de seguro correspondente e permite enriquecer os dados com informações da apólice para uma análise mais aprofundada e contextualizada. Onde encontrar Dado fundamental coletado na abertura do sinistro e armazenado no cabeçalho do registro. Exemplos POL-987654A-100-200-300555444333 | |||
| Status do sinistro ClaimStatus | Status geral do sinistro em determinado momento, como aberto, pendente ou encerrado. | ||
| Descrição Status do sinistro indica a situação do caso em seu ciclo de vida no momento de um evento. Esse status resume em que ponto do processo o sinistro está, por exemplo, 'Em investigação', 'Aguardando informações' ou 'Liquidado'. Enquanto a mineração de processos reconstrói o fluxo detalhado a partir das atividades, o atributo Status do sinistro oferece um contexto valioso. Ele pode ser usado para validar o fluxo do processo, por exemplo, verificando se a atividade 'Pagamento emitido' muda corretamente o status para 'Encerrado', e para analisar quanto tempo os sinistros permanecem em cada situação. Isso ajuda a entender por quanto tempo os casos ficam pendentes e pode revelar atrasos ou ineficiências sistêmicas. Por que isso importa Mostra a situação do sinistro em determinado momento, ajudando a analisar o tempo em cada etapa e a validar o fluxo do processo. Onde encontrar Campo essencial do registro principal do sinistro, atualizado à medida que o caso avança pelo ciclo de vida. Exemplos AbertoPendente: aguardando informações do clienteEncerrado: pagoEncerrado: negado | |||
| Valor solicitado ClaimedAmount | Valor total solicitado inicialmente pelo segurado ao abrir o sinistro. | ||
| Descrição O valor solicitado é a estimativa inicial do prejuízo ou o valor informado pelo solicitante no início do processo. Esse valor pode ser revisado durante as etapas de investigação e avaliação. Esse atributo é útil em diferentes tipos de análise. Ele pode ajudar a definir a gravidade inicial do sinistro e a acompanhar a diferença entre o valor solicitado inicialmente e o valor final da indenização. Analisar essa diferença ajuda a avaliar a precisão das estimativas iniciais e a eficácia das medidas de controle de custos no processo de sinistros. Também é um dado importante para previsões financeiras e cálculo de reservas. Por que isso importa Representa o valor financeiro inicial do sinistro e ajuda a avaliar sua gravidade e a diferença em relação ao valor final da indenização. Onde encontrar Coletado na abertura do sinistro e armazenado na seção financeira do registro. Exemplos 2000.0035000.00500.00 | |||
Atividades do processamento de sinistros
| Atividade | Descrição | ||
|---|---|---|---|
| Análise inicial concluída | Indica a conclusão da primeira análise abrangente do sinistro pelo regulador responsável. Nesta etapa, ele avalia a validade e os detalhes do caso e determina as próximas ações necessárias. | ||
| Por que isso importa Este marco ajuda a medir o tempo de triagem e avaliação inicial. Atrasos nesta etapa podem aumentar significativamente o tempo de ciclo total do sinistro. Onde encontrar Muitas vezes, é identificado por uma mudança de status no sistema, como a passagem de “Novo” ou “Atribuído” para “Em revisão” ou “Em investigação”. Coleta Procure uma mudança de status que indique o fim da avaliação inicial e o início do processamento ativo. Tipo de evento inferred | |||
| Decisão sobre o sinistro tomada | Este é um marco decisivo: com base na investigação, a seguradora decide formalmente aprovar, aprovar parcialmente ou negar o sinistro. Ele representa o resultado oficial do processo de análise e decisão. | ||
| Por que isso importa Este é um ponto de decisão crítico, que define o caminho seguinte do sinistro: pagamento ou negativa. Analisá-lo é essencial para entender o tempo e os resultados das decisões. Onde encontrar Quase sempre, esse evento é registrado no sistema como uma mudança explícita de status para algo como 'Aprovado', 'Negado' ou 'Liquidado'. Coleta Procure a primeira atualização de status para uma decisão final, como 'Aprovado' ou 'Negado'. Tipo de evento inferred | |||
| Pagamento emitido | Esta atividade marca a execução da transação financeira para pagar o sinistro. É o momento em que o pagamento é enviado ao segurado ou ao prestador de serviços. | ||
| Por que isso importa Este é um evento financeiro crítico e, muitas vezes, marca o fim do caminho ideal do processo. É essencial para medir o tempo até o pagamento após a aprovação do sinistro. Onde encontrar Este evento é registrado em um histórico explícito de transações ou em uma atualização final do status do pagamento, muitas vezes acionada pela integração com um sistema financeiro. Coleta Identifique o evento em que um registro de pagamento associado ao sinistro recebe o status 'Pago', 'Emitido' ou 'Desembolsado'. Tipo de evento explicit | |||
| Prejuízo avaliado | Este marco indica o momento em que o impacto financeiro do sinistro é estimado e uma reserva é definida. Ele representa a estimativa formal do custo potencial do sinistro. | ||
| Por que isso importa Este é um evento financeiro importante no processo. Analisar quando e com que frequência as reservas são ajustadas ajuda a avaliar a precisão das estimativas e a eficiência do processo. Onde encontrar Este evento é registrado quando os valores da reserva são lançados pela primeira vez ou ajustados posteriormente nos registros financeiros do sinistro no sistema. Coleta Registre a data e a hora da primeira transação no histórico da reserva financeira do sinistro. Tipo de evento explicit | |||
| Sinistro encerrado | Esta é a atividade administrativa final, que marca o encerramento do arquivo do sinistro após a emissão do pagamento ou a negativa do pedido. Nesta etapa, todas as atividades estão concluídas. | ||
| Por que isso importa Este é o principal evento final do processo. Ele é essencial para calcular o tempo total de ciclo de ponta a ponta de todos os sinistros. Onde encontrar Este evento é registrado pela atualização final do status para 'Encerrado' ou 'Finalizado' no sistema, após a conclusão de todas as outras etapas. Coleta Identifique a data e a hora em que o campo de status principal do sinistro é atualizado para o valor final 'Encerrado'. Tipo de evento inferred | |||
| Sinistro negado | Esta atividade representa o resultado final de um sinistro não aprovado para pagamento. Ela ocorre após a decisão de negar o sinistro e envolve a finalização do registro com o status de negado. | ||
| Por que isso importa Este é um evento final importante em uma das principais variantes do processo. Analisar os sinistros negados é essencial para entender as taxas e os motivos de negativa. Onde encontrar Este evento é registrado quando o status final do sinistro é definido como 'Negado' ou 'Rejeitado'. Coleta Procure uma atualização final de status para 'Negado', 'Rejeitado' ou outro status final semelhante. Ela pode ocorrer depois da decisão inicial. Tipo de evento inferred | |||
| Sinistro registrado | Esta atividade marca a criação oficial do registro do sinistro no sistema de processamento, após o primeiro aviso de sinistro (FNOL). Nesse momento, um ID único do sinistro é atribuído oficialmente e o caso é aberto para processamento. | ||
| Por que isso importa Este é o principal evento de início do processo de sinistros. Ele é essencial para medir o tempo de ciclo total, do registro oficial ao encerramento. Onde encontrar Este evento costuma ser capturado a partir da data e hora de criação do registro principal do sinistro ou do objeto do caso no sistema de origem. Coleta Identifique o evento de criação ou a primeira atualização de status no histórico do sinistro. Tipo de evento explicit | |||
| Informações adicionais recebidas | Marca o recebimento dos documentos ou das informações solicitadas, permitindo que o processamento do sinistro seja retomado. Esta atividade encerra o período de espera iniciado pela solicitação. | ||
| Por que isso importa Este evento encerra o ciclo de solicitação de informações. O tempo entre a solicitação e o recebimento é um indicador importante de dependências externas e gargalos. Onde encontrar Geralmente, é identificado quando o status do sinistro muda de “Aguardando informações” para um status ativo, como “Em revisão”. Coleta Detecte a mudança de status de “Aguardando” para um status de processamento ativo. Tipo de evento inferred | |||
| Informações adicionais solicitadas | Esta atividade ocorre quando o regulador determina que precisa de mais informações do solicitante ou de terceiros para dar andamento ao caso. Muitas vezes, ela inicia um período de espera no processo. | ||
| Por que isso importa Esta atividade marca o início de um ciclo comum de retrabalho ou espera. Analisar sua frequência e duração ajuda a identificar problemas na coleta inicial de dados e na comunicação. Onde encontrar Esta atividade costuma ser registrada por uma mudança de status específica, como “Aguardando informações”, ou pelo registro de um evento de comunicação enviada. Coleta Identifique mudanças de status para “Aguardando informações” ou a criação de uma tarefa ou comunicação relacionada a uma solicitação de informações. Tipo de evento inferred | |||
| Investigação concluída | Indica a conclusão de todas as atividades de investigação, quando os fatos necessários já foram coletados e documentados. Esta etapa é necessária para tomar uma decisão final sobre o sinistro. | ||
| Por que isso importa Este marco marca o fim da etapa de coleta de evidências. O tempo até esse ponto é fundamental para entender a eficiência da investigação. Onde encontrar Geralmente, é identificado quando o status do sinistro muda de 'Em investigação' para um status de decisão, como 'Aguardando decisão' ou 'Pronto para avaliação'. Coleta Identifique a mudança de status que indica o fim da investigação e que o caso está pronto para uma decisão final. Tipo de evento inferred | |||
| Investigação iniciada | Esta atividade marca o início da investigação formal e aprofundada do sinistro. Ela pode envolver a atribuição de especialistas, o agendamento de inspeções ou outras atividades de coleta de evidências. | ||
| Por que isso importa Acompanhar o início da investigação ajuda a isolar e medir a duração desta etapa do processo de sinistros, que costuma ser complexa e demorada. Onde encontrar Muitas vezes, é identificada pela mudança do status do sinistro para “Em investigação” ou um status semelhante, ou pela criação da primeira tarefa relacionada à investigação. Coleta Procure uma mudança de status para “Em investigação” ou a criação da primeira tarefa formal de investigação. Tipo de evento inferred | |||
| Pagamento autorizado | Representa a aprovação formal do pagamento do valor calculado para a indenização. Muitas vezes, é uma etapa distinta, que envolve um gerente ou outra autoridade para evitar fraudes e garantir a precisão. | ||
| Por que isso importa Este é um ponto de controle crítico. Analisar o tempo entre o cálculo e a autorização pode revelar gargalos de aprovação ou problemas de conformidade. Onde encontrar Este evento é registrado por uma transação de aprovação específica ou por uma mudança de status no sistema, como 'Aprovado para pagamento'. Coleta Registre a data e a hora do evento de aprovação do pagamento ou da mudança de status para 'Aprovado para pagamento'. Tipo de evento explicit | |||
| Regulador de sinistros atribuído | Esta atividade registra a atribuição do sinistro a um regulador, responsável ou equipe específica. Ela define quem é responsável por gerenciar o caso ao longo de todo o ciclo de vida. | ||
| Por que isso importa Acompanhar as atribuições é essencial para analisar a distribuição da carga de trabalho e a performance da equipe, além de identificar atrasos nas transferências de sinistros. Onde encontrar Essas informações geralmente são registradas em um log de atribuições ou identificadas pelo acompanhamento de alterações no campo “responsável” ou “atribuído a” do registro do sinistro. Coleta Capture as atualizações nos campos de atribuição de usuário ou grupo associados ao caso do sinistro. Tipo de evento explicit | |||
| Sinistro reaberto | Ocorre quando um sinistro anteriormente encerrado ou negado é reativado para nova análise ou processamento. Isso geralmente acontece após um recurso, com a chegada de novas informações ou quando um erro é identificado. | ||
| Por que isso importa A reabertura de sinistros representa um retrabalho significativo. Acompanhar essa atividade é essencial para identificar falhas no processo, motivos de recurso e impactos nos custos. Onde encontrar Este evento é registrado quando o status muda de 'Encerrado' ou 'Negado' para um status ativo, como 'Em revisão'. Coleta Detecte uma mudança de status de uma situação final, como 'Encerrado', para uma situação ativa que não seja final. Tipo de evento inferred | |||
| Valor da indenização calculado | Após a aprovação, esta atividade corresponde ao cálculo do valor final da indenização ou do pagamento, com base nos limites da apólice, nas franquias e nos prejuízos avaliados. | ||
| Por que isso importa O tempo gasto nesta etapa pode revelar gargalos entre a decisão sobre o sinistro e a autorização do pagamento. É uma etapa importante do processo de liquidação financeira. Onde encontrar Provavelmente, este evento é registrado quando o campo do valor final do pagamento ou da indenização é preenchido e confirmado no módulo financeiro do sistema. Coleta Identifique quando o valor final da indenização é preenchido ou quando um registro de pagamento é criado com o status 'Aguardando aprovação'. Tipo de evento explicit | |||
Guias de extração
Os métodos de extração variam conforme o sistema. Para ver instruções detalhadas,
consulte nosso guia de ETL ou selecione um processo e um sistema específicos.
Pronto para começar?
Comece a aprimorar o processamento de sinistros escolhendo um guia de extração específico para seu sistema ou usando este Template genérico para preparar seu Event Log.
Tenha controle: otimize processos e melhore a performance agora
Identifique ineficiências, impulsione a inovação e alcance seus objetivos mais rápido.
Não é necessário informar cartão de crédito. Comece a otimizar hoje.