Seu Template de dados para processamento de sinistros
Seu Template de dados para processamento de sinistros
- Atributos recomendados para coletar
- Principais atividades para acompanhar
- Orientações para extrair dados do Duck Creek Claims
Atributos do processamento de sinistros
| Nome | Descrição | ||
|---|---|---|---|
| Horário do evento EventTime | Timestamp que indica quando uma atividade ou evento específico ocorreu. | ||
| Descrição O horário do evento informa a data e a hora exatas de cada atividade registrada no ciclo de vida do sinistro. Essas informações temporais são essenciais para analisar a performance. Na análise, esse timestamp é usado para calcular os tempos de ciclo entre atividades, identificar tempos de espera, medir a duração total do caso e analisar a performance do processo em diferentes períodos. Ele é a base de qualquer métrica de processo relacionada ao tempo. Por que isso importa Este timestamp é essencial para calcular todas as métricas relacionadas ao tempo, como tempos de ciclo e durações, permitindo analisar a performance e identificar gargalos. Onde encontrar Este é um campo de timestamp padrão associado aos logs de eventos ou transações no Duck Creek Claims. Procure campos como 'CreateDate', 'Timestamp' ou 'EventDate'. Exemplos 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| ID do sinistro ClaimId | Identificador exclusivo de um sinistro, usado como ID principal do caso. | ||
| Descrição O ID do sinistro é a chave fundamental que conecta todos os eventos e atividades relacionados a um mesmo sinistro, do envio ao encerramento. Ele permite acompanhar de forma integrada todo o ciclo de vida do sinistro. Na análise de Process Mining, este atributo é essencial para criar a visão do caso. Com ele, analistas podem acompanhar a jornada completa de cada sinistro, medir os tempos de ciclo de ponta a ponta e analisar as variantes do processo. Por que isso importa Este é o ID do caso essencial para conectar todos os eventos relacionados no processo e oferecer uma visão completa, de ponta a ponta, do ciclo de vida do sinistro. Onde encontrar Esta é uma chave primária na tabela ou entidade principal de sinistro do Duck Creek Claims. Consulte a documentação do sistema para identificar o nome específico da tabela e do campo. Exemplos CL-2023-001234CL-2023-005678CL-2024-009101 | |||
| Nome da atividade ActivityName | Nome da atividade de negócio ou do evento ocorrido em um momento específico durante o processamento de um sinistro. | ||
| Descrição Este atributo descreve uma etapa ou tarefa específica realizada no processo de sinistros, como 'Sinistro enviado', 'Regulador de sinistros atribuído' ou 'Pagamento emitido'. Cada atividade representa um ponto distinto do ciclo de vida do sinistro. Analisar a sequência e a frequência dessas atividades é a base do Process Mining. Isso permite descobrir modelos de processo, identificar gargalos, detectar ciclos de retrabalho e analisar desvios em relação a um modelo padrão. Por que isso importa O nome da atividade define as etapas do fluxo do processo e é fundamental para descobrir, analisar e monitorar o processo de sinistros. Onde encontrar Em geral, é derivado de Event Logs, nomes de transações ou registros de mudança de status no Duck Creek Claims. Talvez seja necessário mapear dados de vários campos ou tabelas de origem. Exemplos Sinistro enviadoRegulador de sinistros atribuídoInvestigação iniciadaPagamento emitidoSinistro encerrado | |||
| Departamento Department | Departamento ou equipe responsável pela atividade ou pelo sinistro em determinado momento. | ||
| Descrição Este atributo especifica o grupo funcional ou departamento, como 'Entrada inicial', 'Unidade de investigação' ou 'Equipe de liquidação', responsável pelo sinistro. Ele fornece contexto organizacional para o fluxo do processo. Analisar os dados por departamento é essencial para entender a performance do processo de forma agregada. Isso ajuda a identificar gargalos entre departamentos, medir a eficiência das equipes e entender como o trabalho flui pela organização. Por que isso importa Permite analisar a performance por área funcional e destacar handoffs entre departamentos e gargalos específicos de cada equipe. Onde encontrar Consulte a documentação do Duck Creek Claims. Essas informações costumam estar associadas ao perfil do usuário atribuído ou a uma fila ou grupo de trabalho. Exemplos Sinistros de automóveisSinistros patrimoniais: grandes perdasUnidade de investigações especiaisProcessamento de pagamentos | |||
| Gravidade do sinistro ClaimSeverity | Classificação da complexidade financeira ou operacional do sinistro, como baixa, média ou alta. | ||
| Descrição A gravidade do sinistro indica o impacto ou a complexidade esperados de um caso. Ela pode se basear na estimativa inicial do prejuízo, na natureza do incidente ou em outras regras de negócio predefinidas. Este atributo é essencial para analisar a performance, pois sinistros de alta gravidade costumam exigir mais etapas, prazos de processamento maiores e recursos especializados. Segmentar os KPIs por gravidade ajuda a definir metas de performance realistas e a entender como a complexidade afeta a eficiência e os resultados do processo. Por que isso importa Ajuda a segmentar os sinistros por complexidade, permitindo análises de performance mais detalhadas e comparações realistas de tempos de ciclo e custos. Onde encontrar Consulte a documentação do Duck Creek Claims. Pode haver um campo específico para esse dado, ou ele pode ser derivado do valor inicial da reserva para o sinistro. Exemplos BaixaMédioAltoCatastrófico | |||
| Regulador atribuído AssignedAdjuster | Nome ou ID do regulador responsável pelo tratamento do sinistro em determinada atividade. | ||
| Descrição Este atributo identifica o usuário ou recurso que realiza uma atividade. Ele pode mudar ao longo do ciclo de vida do sinistro, conforme o caso passa entre diferentes reguladores ou equipes. É essencial para analisar a performance dos recursos, a distribuição da carga de trabalho e os handoffs. Dashboards sobre o volume de casos tratados pelos reguladores, as variações na carga de trabalho e a identificação de gargalos costumam depender bastante deste atributo para mostrar como o trabalho é distribuído e realizado por cada pessoa. Por que isso importa Permite analisar a performance dos recursos, equilibrar a carga de trabalho e entender os padrões de colaboração, ajudando a identificar gargalos e necessidades de treinamento. Onde encontrar Consulte a documentação do Duck Creek Claims. Procure campos de usuário, responsável ou pessoa atribuída em tabelas relacionadas a tarefas, eventos ou à entidade principal do sinistro. Exemplos John SmithJane DoeRobert Brownadjuster_1138 | |||
| Status do sinistro ClaimStatus | O status geral do sinistro em determinado momento, como Aberto, Pendente ou Encerrado. | ||
| Descrição O status do sinistro representa sua situação atual ao longo do ciclo de vida. Ele resume em que etapa do processo o sinistro se encontra. Esse atributo é útil para criar visões gerais do estoque de sinistros e filtrar casos. É especialmente importante para identificar o resultado final de um sinistro, como 'Encerrado - Pago' ou 'Encerrado - Negado', informação essencial para analisar os resultados e entender as taxas de rejeição. Por que isso importa Apresenta uma visão da situação atual e do resultado final do sinistro, essencial para analisar os resultados e filtrar casos. Onde encontrar Consulte a documentação do Duck Creek Claims. Este é um campo fundamental no registro principal do sinistro. Exemplos AbertoPendente - Aguardando informaçõesEncerrado - LiquidadoEncerrado - Negado | |||
| Tipo de sinistro ClaimType | Categoria do sinistro, como automóvel, patrimônio ou responsabilidade civil. | ||
| Descrição O tipo de sinistro classifica os casos de acordo com o ramo de negócio ou a natureza do prejuízo. É uma dimensão fundamental para segmentar e analisar os dados de sinistros. Este atributo permite comparar a performance do processo entre diferentes tipos de sinistro. Por exemplo, um sinistro de 'Automóvel: perda total' segue um processo bem diferente de um sinistro de 'Patrimônio: danos causados por água' e tem KPIs distintos. Analisar os dados por tipo de sinistro oferece contexto e permite comparações de performance mais relevantes e iniciativas de melhoria de processos mais direcionadas. Por que isso importa Esta é uma dimensão essencial para segmentar a análise, pois diferentes tipos de sinistro costumam ter processos, SLAs e níveis de complexidade distintos. Onde encontrar Consulte a documentação do Duck Creek Claims. Este é um atributo essencial do registro principal do sinistro. Exemplos Automóvel particular: colisãoPatrimônio comercial: incêndioIndenização trabalhistaResponsabilidade civil geral | |||
| Valor do prejuízo LossAmount | O valor financeiro estimado ou real do prejuízo informado no sinistro. | ||
| Descrição Este atributo representa o valor inicialmente estimado do prejuízo relacionado ao sinistro. É uma métrica financeira importante, que costuma influenciar o encaminhamento, a gravidade e o nível de investigação necessário. Na análise, o valor do prejuízo é usado para segmentar sinistros e entender como o impacto financeiro se relaciona com o comportamento do processo. Por exemplo, sinistros de maior valor podem seguir caminhos diferentes ou ter tempos de ciclo mais longos. Esse atributo fornece um contexto financeiro essencial para os dados operacionais do processo. Por que isso importa Fornece contexto financeiro sobre o sinistro e permite analisar como seu valor afeta o caminho de processamento, a duração e o resultado. Onde encontrar Consulte a documentação do Duck Creek Claims. Este é um campo financeiro essencial do sinistro, geralmente chamado de 'Prejuízo informado' ou 'Reserva inicial'. Exemplos 1500.0025000.50125000.00 | |||
| Data prevista para resolução ResolutionTargetDate | A data prevista para a resolução do sinistro, com base em SLAs ou metas internas. | ||
| Descrição Este atributo armazena o prazo para encerrar o sinistro. A data costuma ser definida por exigências regulatórias, acordos de nível de serviço (SLAs) ou indicadores-chave de performance (KPIs) internos, e pode variar conforme o tipo ou a gravidade do sinistro. Esse dado serve de base para calcular o KPI 'Taxa de resolução de sinistros no prazo' e acompanhar o Dashboard 'Aderência à meta de resolução de sinistros'. Ele permite monitorar proativamente os sinistros com risco de descumprir o SLA e ajuda a priorizar o trabalho. Por que isso importa Permite medir a performance em relação aos acordos de nível de serviço (SLAs) e às metas internas, com impacto direto na satisfação do cliente e na conformidade. Onde encontrar Consulte a documentação do Duck Creek Claims. Pode haver um campo específico para a data do SLA, ou ela pode ser calculada com base na data de abertura do sinistro e nas regras de negócio. Exemplos 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
| É automatizada IsAutomated | Indicador booleano que informa se a atividade foi realizada automaticamente pelo sistema, sem intervenção humana. | ||
| Descrição Este indicador diferencia as tarefas realizadas por pessoas daquelas executadas automaticamente pelo sistema, como notificações automáticas, validação inicial de dados ou etapas de processamento direto. Analisar este atributo é essencial para entender o nível de automação do processo de sinistros. Ele ajuda a medir o impacto das iniciativas de automação, identificar oportunidades para ampliar a automação e verificar se as etapas automatizadas estão funcionando como esperado, sem causar problemas nas etapas seguintes. Por que isso importa Ajuda a medir o impacto da automação na eficiência e nos custos, além de identificar oportunidades de processamento direto. Onde encontrar Essa informação pode ser inferida a partir do 'usuário' associado a um evento, como 'SYSTEM' ou 'BATCH', ou de um indicador específico no registro do evento. Exemplos truefalse | |||
| É retrabalho IsRework | Indicador calculado que informa se uma atividade faz parte de um ciclo de retrabalho. | ||
| Descrição Este atributo booleano recebe o valor true quando uma atividade é repetida para um sinistro após a realização de outras atividades diferentes. Por exemplo, quando o processo volta de 'Prejuízo avaliado' para 'Investigação iniciada'. Este atributo é essencial para quantificar e analisar o retrabalho. Ele dá suporte ao KPI 'Taxa de retrabalho em sinistros' e ao Dashboard 'Padrões de retrabalho e reprocessamento de sinistros', permitindo filtrar e destacar diretamente as atividades e os casos com retrabalho. Assim, ajuda a localizar ineficiências e problemas de qualidade no processo. Por que isso importa Quantifica o retrabalho no nível da atividade e facilita a medição, a visualização e a análise das causas e dos impactos das ineficiências do processo. Onde encontrar Este campo não existe no sistema de origem. Ele é calculado durante a preparação dos dados com algoritmos que detectam sequências repetidas de atividades em um caso. Exemplos truefalse | |||
| Foi resolvido no prazo IsOnTimeResolution | Indicador calculado que informa se o sinistro foi encerrado até a data prevista para resolução. | ||
| Descrição Este atributo booleano é calculado comparando a data e hora da atividade 'Sinistro encerrado' com a 'ResolutionTargetDate' do sinistro. Ele indica se cada sinistro foi resolvido no prazo (true) ou com atraso (false). Este atributo dá suporte direto ao KPI 'Taxa de resolução de sinistros no prazo'. Ele facilita a agregação e a visualização da aderência ao SLA em Dashboards e permite aprofundar a análise para identificar características comuns dos sinistros atrasados, como tipos de sinistro, departamentos ou caminhos do processo específicos. Por que isso importa Mede diretamente a conformidade com o SLA em cada sinistro e permite filtrar e fazer análise de causa raiz dos casos em atraso. Onde encontrar Este campo não existe no sistema de origem. Ele é calculado durante a preparação dos dados, comparando a data e hora da atividade final com o campo 'ResolutionTargetDate'. Exemplos truefalse | |||
| Horário de término EndTime | Data e hora em que uma atividade foi concluída. | ||
| Descrição Este atributo registra o horário de conclusão de uma atividade. Enquanto StartTime indica quando ela começou, EndTime fornece o outro dado necessário para calcular a duração daquela tarefa. Em Process Mining, ter os horários de início e término das atividades permite analisar a performance com muito mais profundidade. Isso possibilita calcular com precisão o 'Tempo de processamento', ou seja, o tempo de trabalho ativo em uma tarefa, e o 'Tempo de espera', gasto entre tarefas. Essa distinção é essencial para identificar gargalos com precisão. Por que isso importa Permite calcular com precisão o tempo de processamento das atividades e diferenciar o tempo de trabalho ativo do tempo ocioso ou de espera, algo essencial para analisar gargalos com precisão. Onde encontrar Pode estar disponível como um campo separado de data e hora nos registros de eventos ou ser derivado do StartTime da atividade seguinte na sequência do mesmo caso. Exemplos 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
| Motivo da rejeição RejectionReason | O motivo específico pelo qual um sinistro foi negado ou rejeitado. | ||
| Descrição Quando uma decisão determina que um sinistro deve ser negado, este atributo informa o motivo. Em geral, ele é selecionado em uma lista predefinida de códigos ou descrições. A análise dos motivos de rejeição é fundamental para o Dashboard 'Análise de decisões e rejeições de sinistros'. Ela ajuda a identificar problemas recorrentes nas solicitações, possíveis padrões de fraude ou trechos pouco claros nas apólices. Esse insight pode orientar melhorias no processo de entrada de solicitações ou nas regras de subscrição. Por que isso importa Explica por que os sinistros são negados e gera insights acionáveis para melhorar o processo de entrada, reduzir solicitações inválidas e identificar oportunidades de treinamento. Onde encontrar Consulte a documentação do Duck Creek Claims. Em geral, este campo é preenchido quando o status do sinistro muda para 'Negado' ou uma situação semelhante. Exemplos Evento não cobertoApólice vencidaSinistro duplicadoSuspeita de fraude | |||
| Número da apólice PolicyNumber | Identificador único da apólice de seguro vinculada ao sinistro. | ||
| Descrição Este atributo vincula o sinistro à apólice de seguro de origem. Ele fornece contexto sobre a cobertura, as condições e o cliente relacionados ao sinistro. Embora nem sempre seja usado diretamente na análise do fluxo do processo, o número da apólice é valioso para enriquecer os dados do sinistro. Ele permite cruzar esses dados com informações da apólice e do cliente e analisar como a performance do processo varia por segmento de cliente, tipo ou tempo de vigência da apólice, oferecendo uma visão mais completa do negócio. Por que isso importa Vincula o sinistro ao cliente e à apólice, permitindo analisar de forma mais ampla como a performance do processo afeta diferentes segmentos de clientes ou tipos de apólice. Onde encontrar Consulte a documentação do Duck Creek Claims. Este é um campo de referência padrão na entidade principal do sinistro. Exemplos PA-987654321CP-123456789WC-555444333 | |||
| Sistema de origem SourceSystem | Sistema do qual os dados de eventos foram extraídos. | ||
| Descrição Este atributo identifica o aplicativo de origem dos dados do sinistro. Neste contexto, o valor será sempre 'Duck Creek Claims'. Mesmo que pareça redundante quando todos os dados vêm de um único sistema, ele é essencial para a governança e a rastreabilidade dos dados, além de ser útil caso dados de vários sistemas sejam combinados no futuro. O atributo informa a origem e a estrutura dos dados. Por que isso importa Fornece informações essenciais sobre a linhagem e o contexto dos dados, fundamentais para a governança e a solução de problemas, especialmente em ambientes com vários sistemas integrados. Onde encontrar Em geral, é um valor estático adicionado durante a extração e a transformação dos dados para identificar sua origem. Exemplos Sinistros no Duck Creek | |||
| Última atualização dos dados LastDataUpdate | Timestamp da atualização mais recente dos dados do sistema de origem. | ||
| Descrição Este atributo indica quando o conjunto de dados foi atualizado pela última vez. Ele serve como referência para avaliar o quanto os dados analisados estão atualizados. Em Dashboards e análises, ele informa quando os insights foram atualizados. Assim, você pode avaliar se a visão do processo já inclui as transações mais recentes. Por que isso importa Informa quando os dados foram atualizados pela última vez, o que é essencial para interpretar a análise e tomar decisões no momento certo. Onde encontrar Este timestamp é gerado durante o processo de extração, transformação e carregamento (ETL) dos dados e costuma ser armazenado nos metadados do conjunto de dados. Exemplos 2024-05-21T02:00:00Z | |||
| Valor do acordo SettlementAmount | O valor financeiro final acordado para liquidar o sinistro. | ||
| Descrição Este atributo registra o valor do acordo calculado e autorizado para pagamento. É uma métrica importante de resultado para cada sinistro que gera um pagamento. O atributo é essencial para análises financeiras e para Dashboards como 'Tempo de autorização e emissão do pagamento'. A comparação com o 'Valor do prejuízo' inicial permite analisar a precisão das reservas e ajuda a entender os resultados financeiros do processo de sinistros. Por que isso importa Representa o principal resultado financeiro de um sinistro e é essencial para relatórios financeiros e análises da precisão das estimativas iniciais de prejuízo. Onde encontrar Consulte a documentação do Duck Creek Claims. Essas informações costumam ficar em tabelas de transações financeiras ou de pagamentos associadas ao sinistro. Exemplos 1450.7522000.00115800.20 | |||
Atividades do processamento de sinistros
| Atividade | Descrição | ||
|---|---|---|---|
| Decisão sobre o sinistro tomada | Esta atividade representa a decisão oficial sobre o sinistro, como 'Aprovado', 'Aprovado parcialmente' ou 'Negado'. É um marco decisivo, inferido pela mudança para um status de decisão final. | ||
| Por que isso importa Este é um marco importante na tomada de decisão. O tempo até este ponto e o resultado da decisão são aspectos centrais para analisar o processo e sua eficiência. Onde encontrar Inferido pela mudança de um campo específico de 'Decisão do sinistro' ou 'Status do sinistro' para um status final, como 'Aprovado' ou 'Negado'. O timestamp dessa mudança é registrado. Coleta Inferido pela atualização do campo principal de status ou de decisão do sinistro. Tipo de evento inferred | |||
| Pagamento autorizado | Representa a aprovação formal do pagamento do valor calculado para a liquidação. Muitas vezes, é uma etapa distinta que envolve um gerente ou outra autoridade e é registrada como uma transação explícita de aprovação. | ||
| Por que isso importa Este é um ponto de controle importante e um possível gargalo antes do pagamento. O KPI 'Tempo médio de aprovação de sinistros' mede o tempo entre 'Decisão sobre o sinistro tomada' e este ponto. Onde encontrar Em geral, este é um evento explícito em um fluxo de trabalho ou módulo financeiro, no qual um usuário com permissões específicas aprova o pagamento. O registro fica no log de aprovações. Coleta Evento explícito de aprovação registrado em um fluxo de trabalho ou log de transações. Tipo de evento explicit | |||
| Pagamento emitido | Esta atividade marca a execução da transação financeira de pagamento do sinistro. É um evento explícito, gerado quando o pagamento é enviado por cheque, transferência eletrônica de fundos (EFT) ou outro meio. | ||
| Por que isso importa Este evento indica que a obrigação financeira de um sinistro aprovado foi cumprida. O tempo entre 'Pagamento autorizado' e 'Pagamento emitido' mostra a eficiência da área financeira. Onde encontrar Capturado na tabela de transações financeiras do Duck Creek Claims, que registra todos os pagamentos enviados com um código de transação específico e um timestamp. Coleta Uma entrada específica é criada no log de transações financeiras quando o pagamento é processado. Tipo de evento explicit | |||
| Sinistro encerrado | Esta é a atividade final, que marca o encerramento administrativo do arquivo do sinistro após a emissão do pagamento ou a liquidação do sinistro. Ela é registrada pela atualização final do status para 'Encerrado'. | ||
| Por que isso importa Esta atividade marca o fim bem-sucedido do processo. É o ponto final para calcular o KPI 'Tempo médio de ciclo do sinistro de ponta a ponta' e outras métricas importantes de duração. Onde encontrar Inferido pelo timestamp da mudança final do status para 'Encerrado' ou 'Liquidado' na tabela principal de dados do sinistro. Coleta Inferido quando o status final do sinistro é definido como 'Encerrado'. Tipo de evento inferred | |||
| Sinistro enviado | Este é o primeiro evento: o recebimento pela seguradora do primeiro aviso de sinistro (FNOL). Em geral, ele é registrado como uma transação explícita quando um agente ou segurado insere no sistema as informações iniciais do sinistro. | ||
| Por que isso importa Esta atividade marca o início de todo o ciclo de vida do sinistro. Analisar o tempo entre este evento e os seguintes é essencial para entender a duração total do processamento e a eficiência da entrada de dados. Onde encontrar Em geral, este é um evento explícito registrado em uma tabela de log de sinistros ou de FNOL quando um novo registro de sinistro é criado no Duck Creek Claims. Coleta Evento registrado na criação inicial de um novo registro de sinistro. Tipo de evento explicit | |||
| Sinistro negado | Esta atividade representa um desfecho alternativo do processo: o sinistro é negado oficialmente. O evento é registrado quando o status final do sinistro é definido como 'Negado' ou 'Rejeitado'. | ||
| Por que isso importa Este é um resultado crítico que deve ser analisado separadamente. Entender por que e quando os sinistros são negados ajuda a melhorar os processos de entrada e a gerenciar a conformidade. Onde encontrar Inferido pelo timestamp da mudança final do status do sinistro para 'Negado', 'Rejeitado' ou 'Encerrado sem pagamento' na tabela da entidade de sinistro. Coleta Inferido quando o status final do sinistro indica um motivo de negativa. Tipo de evento inferred | |||
| Análise inicial concluída | Representa a conclusão da primeira análise abrangente do sinistro pelo regulador atribuído. Em geral, isso é inferido quando o status do sinistro muda após a atribuição, por exemplo, de 'Atribuído' para 'Em análise' ou 'Em investigação'. | ||
| Por que isso importa Este marco ajuda a medir o tempo até a primeira ação do regulador e pode indicar possíveis acúmulos de trabalho. É o primeiro grande ponto de controle conduzido por uma pessoa. Onde encontrar Inferido por uma mudança no campo de status do sinistro, por exemplo, para 'Análise inicial concluída' ou 'Aguardando informações'. Usa-se o timestamp dessa mudança de status. Coleta Inferido pela mudança no campo de status do sinistro após a atribuição do regulador. Tipo de evento inferred | |||
| Informações adicionais recebidas | Marca o recebimento das informações solicitadas, permitindo que o processamento do sinistro continue. O regulador pode registrar esse evento manualmente, ou o sistema pode registrá-lo automaticamente quando as informações são enviadas por um portal digital. | ||
| Por que isso importa O tempo entre 'Informações solicitadas' e 'Informações recebidas' é um período de espera crítico. Analisar essa duração ajuda a identificar dependências externas e gargalos de comunicação. Onde encontrar Pode ser um evento explícito de uma integração com um sistema de gerenciamento de documentos ou um registro manual ou mudança de status feita pelo regulador ao receber os documentos. Coleta Evento registrado após o envio de documentos ou a inserção manual feita por um regulador. Tipo de evento explicit | |||
| Informações adicionais solicitadas | Esta atividade ocorre quando o regulador identifica a necessidade de mais informações e envia uma solicitação ao segurado ou a terceiros. Muitas vezes, ela é um evento explícito vinculado ao módulo de comunicação ou correspondência do sistema. | ||
| Por que isso importa Uma frequência alta desta atividade pode indicar problemas no processo inicial de coleta de dados. Ela também gera um tempo de espera significativo, afetando o tempo de ciclo geral. Onde encontrar Capturado nos logs de comunicações enviadas, como cartas e e-mails, ou em uma transação específica de 'Solicitação de informações' no Duck Creek Claims. Coleta Registrado quando uma correspondência ou tarefa de solicitação de informações é gerada. Tipo de evento explicit | |||
| Investigação concluída | Representa a conclusão das atividades de investigação, quando todos os fatos necessários foram reunidos. Em geral, isso é inferido quando o status do sinistro muda de 'Em investigação' para um status de tomada de decisão, como 'Aguardando decisão'. | ||
| Por que isso importa A conclusão da investigação é um marco importante que libera as etapas de tomada de decisão e liquidação. Atrasos nessa fase têm um impacto significativo nas etapas seguintes. Onde encontrar Inferido pelo timestamp de uma atualização do status do sinistro, de um status de 'investigação' para um status de 'análise' ou 'decisão'. Coleta Derivado de uma mudança no status do sinistro que indica o fim das atividades de investigação. Tipo de evento inferred | |||
| Investigação iniciada | Esta atividade marca o início da fase formal de investigação do sinistro. Muitas vezes, ela é inferida pela mudança do status do sinistro para 'Em investigação' ou um status semelhante. | ||
| Por que isso importa Este é o início de uma fase que exige muitos recursos. Medir a duração da investigação é essencial para o KPI 'Duração média da investigação' e ajuda a gerenciar uma etapa crítica do processo. Onde encontrar Inferido pelo timestamp de uma atualização do status do sinistro para 'Investigação em andamento' ou 'Aguardando inspeção' no campo principal de status do sinistro. Coleta Derivado de uma mudança no status do sinistro que indica o início das atividades de investigação. Tipo de evento inferred | |||
| Prejuízo avaliado | Este marco indica quando as reservas financeiras são definidas ou atualizadas com base nos resultados da investigação. Ele representa a estimativa do impacto financeiro do sinistro e é registrado quando os valores das reservas são inseridos ou ajustados. | ||
| Por que isso importa Este é um ponto de controle financeiro crítico do processo. Analisar quando ele ocorre oferece insights sobre a rapidez e a precisão da avaliação financeira. Onde encontrar Muitas vezes, este é um evento financeiro explícito registrado no log de transações financeiras do sinistro ou na tabela de histórico de reservas do Duck Creek Claims. Coleta Transação financeira registrada para definir ou atualizar as reservas do sinistro. Tipo de evento explicit | |||
| Regulador de sinistros atribuído | Este evento registra a atribuição de um regulador ou responsável pelo tratamento ao sinistro registrado. O sistema registra essa atribuição, criando um ponto claro de handoff e definindo quem será responsável pelo sinistro ao longo de seu ciclo de vida. | ||
| Por que isso importa É essencial para analisar a alocação de recursos e a carga de trabalho dos reguladores, além de identificar atrasos na atribuição de sinistros. Este é um ponto importante de handoff, que pode gerar tempo de espera. Onde encontrar Acompanhe a atualização do campo 'Assigned Adjuster' na tabela principal de dados do sinistro. O histórico ou log de auditoria desse campo fornece o timestamp. Coleta Registrado em uma trilha de auditoria quando o campo do regulador é preenchido ou alterado. Tipo de evento explicit | |||
| Sinistro registrado | Marca a aceitação e o registro formal do sinistro enviado, momento em que um ID de sinistro exclusivo é atribuído oficialmente. Muitas vezes, este é um evento automatizado do sistema após a validação inicial dos dados. | ||
| Por que isso importa Formaliza o início do sinistro e aciona processos subsequentes, como a atribuição de um regulador. O tempo entre o envio e o registro pode indicar problemas na qualidade inicial dos dados ou na carga do sistema. Onde encontrar Inferido pelo timestamp de geração do ID de sinistro principal e pela mudança do status do sinistro de 'pendente' ou 'enviado' para 'aberto' ou 'registrado' na tabela principal da entidade de sinistro. Coleta Derivado do timestamp de criação do registro principal do sinistro ou da mudança de status para 'Aberto'. Tipo de evento inferred | |||
| Valor da liquidação calculado | Após a aprovação, esta atividade representa o cálculo do valor final da liquidação ou do pagamento. Pode ser uma etapa explícita ou ser inferida pela finalização dos valores de pagamento no módulo financeiro do sistema. | ||
| Por que isso importa Esta atividade é essencial para medir o KPI 'Taxa de retrabalho na liquidação'. A ocorrência repetida deste evento em um mesmo sinistro indica ineficiências, erros ou negociações durante a etapa de liquidação. Onde encontrar Pode ser uma entrada explícita no log de transações ou ser inferido pelas atualizações do campo 'Valor da liquidação' nos dados financeiros do sinistro. Os logs de auditoria desse campo são a principal fonte. Coleta Evento registrado quando o valor final do pagamento é calculado e salvo. Tipo de evento explicit | |||
Guias de extração
Etapas
- Acesse o utilitário de configuração do Duck Creek Data Hub: Faça login no ambiente Duck Creek e acesse o aplicativo Data Hub. Você precisará das permissões adequadas para criar ou modificar configurações de exportação de dados.
- Crie um novo trabalho de exportação de dados: No utilitário Data Hub, inicie o processo para criar um novo trabalho de exportação. Dê a ele um nome descritivo, como ProcessMind_Claims_Event_Log_Export.
- Defina a fonte de dados: Configure o trabalho para se conectar ao banco de dados SQL principal do Data Hub. Você precisará informar o nome do servidor, o nome do banco de dados e as credenciais de um usuário com acesso de leitura aos esquemas relevantes.
- Insira a consulta de extração: Acesse a seção de definição de consulta do trabalho de exportação. Copie o script completo da seção de consulta abaixo e cole-o no editor de consultas.
- Defina os parâmetros da consulta: Localize a seção de parâmetros na configuração. Defina os valores dos parâmetros @StartDate e @EndDate usados na consulta para especificar o período de extração desejado. Por exemplo, '2023-01-01' e '2023-12-31'.
- Mapeie as colunas de saída: Configure as opções do arquivo de saída. Verifique se as colunas definidas na instrução SELECT (ClaimId, ActivityName, EventTime etc.) estão mapeadas corretamente para as colunas do arquivo de saída. Os nomes dos cabeçalhos no arquivo devem corresponder exatamente a esses nomes.
- Configure o arquivo de saída: Especifique CSV como formato de saída. Defina a vírgula (,) como delimitador e UTF-8 como codificação de caracteres para garantir a compatibilidade com o ProcessMind.
- Defina o destino: Especifique o caminho do arquivo ou o local de rede onde o arquivo CSV gerado será salvo. Verifique se o sistema tem permissão de gravação nesse local.
- Agende o trabalho de exportação: Configure o agendamento do trabalho. Para a análise inicial, você pode executá-lo manualmente. Para monitoramento contínuo, configure uma programação recorrente, por exemplo, diária ou semanal.
- Execute o trabalho e recupere o arquivo: Execute o trabalho para gerar o arquivo de registro de eventos. Quando terminar, recupere o arquivo CSV no destino especificado na etapa 8.
- Prepare o arquivo para carregamento: Antes de carregar o arquivo no ProcessMind, abra o CSV para fazer uma verificação final. Confira se os cabeçalhos estão corretos, se o formato de data é consistente (YYYY-MM-DD HH:MI:SS) e se os dados estão como esperado.
Configuração
- Pré-requisitos: É necessário ter acesso ao módulo Duck Creek Data Hub. O usuário ou a conta de serviço que executa o trabalho de exportação precisa ter permissões de leitura nas tabelas do banco de dados subjacente ao Data Hub, por exemplo, [DataHubSchema].[FactClaimTransaction], [DataHubSchema].[DimClaim], [DataHubSchema].[DimStatusHistory].
- Configuração do período: A consulta usa os parâmetros @StartDate e @EndDate. É essencial defini-los para estabelecer o período de extração. Para uma primeira análise, recomenda-se um período de 6 a 12 meses, para incluir casos concluídos e em andamento em quantidade suficiente.
- Filtragem: A consulta inclui o espaço reservado /* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ na expressão de tabela comum (CTE). Remova os comentários e ajuste essa linha para filtrar ramos de negócio específicos, por exemplo, 'Personal Auto' ou 'Commercial Property', reduzindo o volume de dados e direcionando a análise.
- Ciclo de atualização do Data Hub: Considere o atraso na atualização dos dados do Data Hub. Os dados não são atualizados em tempo real; normalmente, a atualização segue um cronograma, por exemplo, todas as noites. Os dados extraídos estarão atualizados até a última atualização bem-sucedida do Data Hub.
- Formato de saída: Configure o trabalho de exportação para gerar um arquivo simples, de preferência CSV. Defina aspas duplas (") como qualificador de texto para lidar com vírgulas nos campos de dados.
Consulta de exemplo sql
-- Common Table Expression (CTE) to fetch core claim attributes
-- This improves readability and performance by querying base tables once.
WITH ClaimBase AS (
SELECT
DC.ClaimId,
DC.ClaimNumber,
DC.ClaimType,
DC.Severity AS ClaimSeverity,
DC.CurrentStatus AS ClaimStatus,
FC.LossAmount,
DA.AdjusterName AS AssignedAdjuster,
DD.DepartmentName AS Department,
-- Timestamps for various events
FC.FNOLReportedDate AS ClaimSubmittedTime,
FC.ClaimRegisteredDate AS ClaimRegisteredTime,
FC.AdjusterAssignmentDate AS AdjusterAssignedTime,
FC.PaymentIssuedDate AS PaymentIssuedTime,
FC.ClaimClosedDate AS ClaimClosedTime
FROM
[DataHubSchema].[DimClaim] AS DC
LEFT JOIN
[DataHubSchema].[FactClaim] AS FC ON DC.ClaimKey = FC.ClaimKey
LEFT JOIN
[DataHubSchema].[DimAdjuster] AS DA ON FC.AssignedAdjusterKey = DA.AdjusterKey
LEFT JOIN
[DataHubSchema].[DimDepartment] AS DD ON FC.DepartmentKey = DD.DepartmentKey
WHERE
FC.FNOLReportedDate BETWEEN @StartDate AND @EndDate
/* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ -- Optional: Uncomment to filter by Line of Business
)
-- 1. Claim Submitted
SELECT
cb.ClaimId,
'Claim Submitted' AS ActivityName,
cb.ClaimSubmittedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Submitted' AS ClaimStatus, -- Status at the time of this event
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimSubmittedTime IS NOT NULL
UNION ALL
-- 2. Claim Registered
SELECT
cb.ClaimId,
'Claim Registered' AS ActivityName,
cb.ClaimRegisteredTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Registered' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimRegisteredTime IS NOT NULL
UNION ALL
-- 3. Adjuster Assigned
SELECT
cb.ClaimId,
'Adjuster Assigned' AS ActivityName,
cb.AdjusterAssignedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Assigned' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.AdjusterAssignedTime IS NOT NULL
UNION ALL
-- 4. Initial Review Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Initial Review Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus IN ('Assigned', 'Registered') AND sh.NewStatus IN ('Under Review', 'Investigation')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Under Review', 'Investigation'))
UNION ALL
-- 5. Additional Information Requested
SELECT
cb.ClaimId,
'Additional Information Requested' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationRequestSent'
UNION ALL
-- 6. Additional Information Received
SELECT
cb.ClaimId,
'Additional Information Received' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationResponseReceived'
UNION ALL
-- 7. Investigation Started (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Started' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Under Investigation'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus = 'Under Investigation')
UNION ALL
-- 8. Investigation Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus = 'Under Investigation' AND sh.NewStatus = 'Pending Decision'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.PreviousStatus = 'Under Investigation' AND s2.NewStatus = 'Pending Decision')
UNION ALL
-- 9. Loss Assessed (Reserve Set/Updated)
SELECT
cb.ClaimId,
'Loss Assessed' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount -- Use transaction amount for this event
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'ReserveSet'
UNION ALL
-- 10. Claim Decision Made (Inferred from status change)
SELECT
cb.ClaimId,
'Claim Decision Made' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus IN ('Approved', 'Partially Approved', 'Denied')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Approved', 'Partially Approved', 'Denied'))
UNION ALL
-- 11. Settlement Calculated
SELECT
cb.ClaimId,
'Settlement Calculated' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'SettlementCalculated'
UNION ALL
-- 12. Payment Authorized
SELECT
cb.ClaimId,
'Payment Authorized' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'PaymentAuthorized'
UNION ALL
-- 13. Payment Issued
SELECT
cb.ClaimId,
'Payment Issued' AS ActivityName,
cb.PaymentIssuedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'PaymentIssued' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.PaymentIssuedTime IS NOT NULL
UNION ALL
-- 14. Claim Denied
SELECT
cb.ClaimId,
'Claim Denied' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Denied' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Denied'
UNION ALL
-- 15. Claim Closed
SELECT
cb.ClaimId,
'Claim Closed' AS ActivityName,
cb.ClaimClosedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Closed' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimClosedTime IS NOT NULL; Pronto para começar?
Com este Template, você tem tudo de que precisa para começar a otimizar o processamento de sinistros. Comece hoje sua jornada com os dados e descubra insights valiosos.
Elimine o acúmulo de sinistros: otimize o processamento agora
Alcance 70% de processamento direto, reduzindo custos e atrasos.
Teste grátis por 14 dias, sem necessidade de cartão de crédito.