Template de Dados: Processamento de Sinistros
O Seu Template de Dados para Processamento de Sinistros
- Atributos recomendados para coleta
- Atividades-chave a monitorizar
- Orientação de Extração para Duck Creek Claims
Atributos de Processamento de Sinistros
| Nome | Descrição | ||
|---|---|---|---|
ID do Sinistro ClaimId | O identificador único para um único sinistro de seguro, servindo como o identificador primário do caso. | ||
Descrição O ID do Sinistro é a chave fundamental que conecta todos os eventos e atividades associados a um único sinistro de seguro, desde a submissão até o encerramento. Ele garante que todo o ciclo de vida de um sinistro possa ser rastreado de forma coesa. Na análise de process mining, este atributo é essencial para construir a visão do caso, permitindo que os analistas rastreiem a jornada completa de cada sinistro, meçam os tempos de ciclo de ponta a ponta e analisem as variantes do processo. Por que é importante Este é o Case ID essencial que conecta todos os eventos relacionados no processo, permitindo uma visão completa e ponta a ponta do ciclo de vida do sinistro. Onde obter Esta é uma chave primária na entidade ou tabela principal de sinistros no Duck Creek Claims. Consulte a documentação do sistema para o nome específico da tabela e do campo. Exemplos CL-2023-001234CL-2023-005678CL-2024-009101 | |||
Nome da Atividade ActivityName | O nome da atividade de negócio ou evento que ocorreu em um ponto específico no tempo para um sinistro. | ||
Descrição Este atributo descreve uma etapa ou tarefa específica realizada no processo de sinistros, como 'Sinistro Registrado', 'Regulador Atribuído' ou 'Pagamento Emitido'. Cada atividade representa um ponto distinto no ciclo de vida do sinistro. A análise da sequência e frequência dessas atividades é o cerne do Process Mining. Permite a descoberta de modelos de processo, a identificação de gargalos, a deteção de ciclos de retrabalho e a análise de desvios do processo em relação a um modelo padrão. Por que é importante O Nome da Atividade define as etapas do fluxo do processo, sendo fundamental para descobrir, analisar e monitorar o processo de sinistros. Onde obter Tipicamente derivado de logs de eventos, nomes de transações ou registos de alteração de status no Duck Creek Claims. Isto pode exigir mapeamento de múltiplos campos ou tabelas de origem. Exemplos Sinistro SubmetidoPerito AtribuídoInvestigação Iniciada.Pagamento EmitidoSinistro Encerrado | |||
Tempo do Evento EventTime | O timestamp que indica quando uma atividade ou evento específico ocorreu. | ||
Descrição O Tempo do Evento fornece a data e hora precisas para cada atividade registrada no ciclo de vida do sinistro. Esta informação temporal é crítica para a análise de desempenho. Na análise, este timestamp é usado para calcular tempos de ciclo entre atividades, identificar tempos de espera, medir a duração total do caso e analisar o desempenho do processo em diferentes períodos de tempo. É a espinha dorsal de qualquer métrica de processo baseada em tempo. Por que é importante Este timestamp é crucial para o cálculo de todas as métricas baseadas no tempo, como tempos de ciclo e durações, permitindo a análise de desempenho e a identificação de bottlenecks. Onde obter Este é um campo de timestamp padrão associado a logs de eventos ou transações no Duck Creek Claims. Procure por campos como 'CreateDate', 'Timestamp' ou 'EventDate'. Exemplos 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
Departamento Department | O departamento ou equipe responsável pela atividade ou pelo sinistro em um determinado momento. | ||
Descrição Este atributo especifica o grupo funcional ou departamento, como 'Receção Inicial', 'Unidade de Investigação' ou 'Equipa de Liquidação', que gere o sinistro. Fornece um contexto organizacional para o fluxo do processo. A análise por departamento é fundamental para compreender o desempenho do processo a um nível agregado. Ajuda a identificar gargalos interdepartamentais, medir a eficiência a nível de equipa e compreender como o trabalho flui por toda a organização. Por que é importante Permite a análise de desempenho por área funcional, destacando as transferências entre departamentos e os gargalos específicos de cada equipe. Onde obter Consulte a documentação do Duck Creek Claims. Esta informação é frequentemente associada ao perfil do usuário atribuído ou a uma atribuição de fila/grupo de trabalho. Exemplos Sinistros de AutomóvelSinistros de Propriedade - Grande PerdaUnidade de Investigações EspeciaisProcessamento de Pagamento | |||
Estado do Sinistro ClaimStatus | O status geral do sinistro em um determinado momento, como Aberto, Pendente ou Encerrado. | ||
Descrição O Estado do Sinistro representa a fase atual do sinistro no seu ciclo de vida. Fornece um resumo de alto nível da posição do sinistro no processo global. Este atributo é útil para criar vistas de alto nível do inventário de sinistros e para filtrar casos. É particularmente importante para identificar o resultado final de um sinistro (por exemplo, 'Encerrado - Pago', 'Encerrado - Negado'), o que é essencial para a análise de resultados e para a compreensão das taxas de rejeição. Por que é importante Fornece uma visão geral do estado atual e do resultado final do sinistro, crucial para a análise de resultados e a filtragem de casos. Onde obter Consulte a documentação do Duck Creek Claims. Este é um campo fundamental no registro principal do sinistro. Exemplos AbertoPendente - Aguardando InformaçõesEncerrado - LiquidadoEncerrado - Negado | |||
Gravidade do Sinistro ClaimSeverity | Uma classificação da complexidade financeira ou operacional do sinistro, como Baixa, Média ou Alta. | ||
Descrição A Gravidade do Sinistro indica o impacto antecipado ou a complexidade de um sinistro. Pode basear-se na estimativa inicial de perdas, na natureza do incidente ou noutras regras de negócio predefinidas. Este atributo é vital para a análise de desempenho, uma vez que sinistros de alta gravidade normalmente exigem mais etapas, tempos de processamento mais longos e recursos especializados. Segmentar os KPIs por gravidade ajuda a estabelecer metas de desempenho realistas e a compreender como a complexidade afeta a eficiência e os resultados do processo. Por que é importante Ajuda a segmentar os sinistros por complexidade, permitindo uma análise de desempenho mais detalhada e um benchmarking realista dos tempos de ciclo e custos. Onde obter Consulte a documentação do Duck Creek Claims. Este pode ser um campo dedicado ou derivado do valor da reserva de perda inicial. Exemplos BaixaMédiaElevadoCatastrófico | |||
Regulador de Sinistros Atribuído AssignedAdjuster | O nome ou ID do regulador de sinistros (ajudicador) responsável pelo manuseio do sinistro em uma determinada atividade. | ||
Descrição Este atributo identifica o utilizador ou recurso que executa uma atividade. Pode mudar ao longo do ciclo de vida do sinistro, à medida que o caso é transferido entre diferentes reguladores ou equipas. É essencial para analisar o desempenho dos recursos, a distribuição da carga de trabalho e as transferências de responsabilidade. Dashboards focados na produtividade dos reguladores, na variação da carga de trabalho e na identificação de gargalos dependem fortemente deste atributo para entender como o trabalho é alocado e processado. Por que é importante Permite a análise do desempenho de recursos, balanceamento da carga de trabalho e padrões de colaboração, ajudando a identificar gargalos e necessidades de treinamento. Onde obter Consulte a documentação do Duck Creek Claims. Procure por campos de usuário, proprietário ou responsável em tabelas relacionadas a tarefas de sinistro, eventos, ou à entidade principal do sinistro. Exemplos John SmithJane DoeRobert Brownadjuster_1138 | |||
Tipo de Sinistro ClaimType | A categoria do sinistro de seguro, como Automóvel, Imóveis ou Responsabilidade Civil. | ||
Descrição O Tipo de Sinistro classifica os sinistros com base na linha de negócio ou na natureza da perda. Esta é uma dimensão fundamental para segmentar e analisar os dados de sinistros. Este atributo é utilizado para comparar o desempenho do processo entre diferentes tipos de sinistros. Por exemplo, um sinistro de 'Automóvel - Perda Total' segue um processo muito diferente e tem KPIs distintos de um sinistro de 'Imóvel - Danos por Água'. Analisar por Tipo de Sinistro fornece contexto e permite comparações de desempenho mais significativas e iniciativas de melhoria de processo personalizadas. Por que é importante Esta é uma dimensão crítica para a segmentação da análise, pois diferentes tipos de sinistro têm frequentemente processos, SLAs e níveis de complexidade distintos. Onde obter Consulte a documentação do Duck Creek Claims. Este é um atributo central no registro principal do sinistro. Exemplos Automóvel Particular - ColisãoPropriedade Comercial - IncêndioCompensação por Acidentes de TrabalhoResponsabilidade Civil Geral | |||
Valor do Sinistro LossAmount | O valor financeiro estimado ou real da perda reportada no sinistro. | ||
Descrição Este atributo representa o valor inicial estimado da perda associada ao sinistro. É uma métrica financeira essencial que frequentemente influencia o encaminhamento, a severidade e o nível de investigação necessário para o sinistro. Na análise, o montante da perda é utilizado para segmentar sinistros e compreender como o impacto financeiro se correlaciona com o comportamento do processo. Por exemplo, sinistros de maior valor podem seguir caminhos diferentes ou ter tempos de ciclo mais longos. Fornece um contexto financeiro crucial para os dados do processo operacional. Por que é importante Fornece contexto financeiro ao sinistro, permitindo a análise de como o valor de um sinistro impacta seu caminho de processamento, duração e resultado. Onde obter Consulte a documentação do Duck Creek Claims. Este é um campo financeiro essencial no sinistro, frequentemente referido como 'Perda Reportada' ou 'Reserva Inicial'. Exemplos 1500.0025000.50125000.00 | |||
Data-Alvo para Resolução ResolutionTargetDate | A data-alvo para a qual se espera que o sinistro seja resolvido, com base nos SLAs ou em metas internas. | ||
Descrição Este atributo armazena a data-limite para o encerramento do sinistro. Esta data é frequentemente determinada por requisitos regulamentares, acordos de nível de serviço (SLAs) ou indicadores internos de desempenho (KPIs), e pode variar com base no tipo de sinistro ou na sua severidade. Esta é a base para o cálculo do KPI 'Taxa de Resolução de Sinistros no Prazo' e para apoiar o dashboard 'Adesão à Meta de Resolução de Sinistros'. Permite a monitorização proativa de sinistros em risco de violar o seu SLA e ajuda a priorizar o trabalho. Por que é importante Permite a medição do desempenho em relação aos SLAs e metas internas, o que impacta diretamente a satisfação do cliente e a conformidade. Onde obter Consulte a documentação do Duck Creek Claims. Este pode ser um campo de data de SLA específico ou calculado com base na data de submissão do sinistro e nas business rules. Exemplos 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
É Automatizado IsAutomated | Um flag booleano indicando se a atividade foi realizada automaticamente pelo sistema, sem intervenção humana. | ||
Descrição Este sinalizador distingue entre tarefas concluídas por utilizadores humanos e as executadas por automação do sistema, como notificações automáticas, validação inicial de dados ou etapas de processamento direto. A análise deste atributo é fundamental para compreender o nível de automação no processo de sinistros. Ajuda a medir o impacto das iniciativas de automação, identifica oportunidades para uma automação adicional e garante que as etapas automatizadas estão a funcionar como esperado, sem criar problemas a jusante. Por que é importante Ajuda a medir o impacto da automação na eficiência e no custo, e identifica oportunidades para o processamento direto. Onde obter Esta informação pode ser inferida do 'utilizador' associado a um evento (por exemplo, 'SYSTEM' ou 'BATCH'), ou de um sinalizador específico no registo do evento. Exemplos truefalse | |||
É Retrabalho IsRework | Um flag calculado que indica se uma atividade faz parte de um ciclo de retrabalho. | ||
Descrição Este atributo booleano é definido como true se uma atividade for repetida para um sinistro depois de outras atividades distintas já terem ocorrido. Por exemplo, se o processo passa de 'Perda Avaliada' de volta para 'Investigação Iniciada'. Este atributo é essencial para quantificar e analisar o retrabalho. Apoia o KPI 'Taxa de Retrabalho de Sinistros' e o dashboard 'Padrões de Retrabalho e Reprocessamento de Sinistros', permitindo a filtragem direta e o destaque de atividades e casos que implicam retrabalho. Isso ajuda a identificar ineficiências e problemas de qualidade no processo. Por que é importante Quantifica o retrabalho ao nível da atividade, facilitando a medição, visualização e análise das causas e impactos das ineficiências de processo. Onde obter Este não é um campo do sistema de origem. É calculado durante a preparação dos dados, utilizando algoritmos que detectam sequências repetidas de atividades dentro de um case. Exemplos truefalse | |||
End Time EndTime | O timestamp que indica quando uma atividade foi concluída. | ||
Descrição Este atributo marca a hora de conclusão de uma atividade. Enquanto o StartTime indica quando uma atividade começou, o EndTime fornece o complemento do cálculo de duração para aquela tarefa específica. No Process Mining, ter um horário de início e um horário de fim para as atividades permite uma análise de desempenho muito mais profunda. Permite o cálculo preciso do 'Tempo de Processamento' (o tempo de trabalho ativo numa tarefa) e do 'Tempo de Espera' (o tempo gasto entre tarefas). Esta distinção é crucial para identificar gargalos com precisão. Por que é importante Permite o cálculo de tempos de processamento de atividades precisos, distinguindo o tempo de trabalho ativo do tempo ocioso/de espera, o que é crítico para uma análise de gargalos precisa. Onde obter Pode estar disponível como um campo de timestamp separado nos logs de eventos ou pode ser derivado como o StartTime da próxima atividade na sequência para o 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 de sinistro é tomada para negar um sinistro, este atributo fornece o motivo subjacente a essa decisão. Isso é tipicamente selecionado de uma lista predefinida de códigos ou descrições. A análise dos motivos de rejeição é crucial para o dashboard 'Claim Decision & Rejection Insights'. Ajuda a identificar problemas comuns com as submissões, potenciais padrões de fraude ou áreas onde a linguagem da apólice pode ser pouco clara. Este insight pode impulsionar melhorias no processo de entrada ou nas regras de subscrição. Por que é importante Explica por que os sinistros são negados, fornecendo insights acionáveis para melhorar o processo de entrada, reduzir submissões inválidas e identificar oportunidades de treinamento. Onde obter Consulte a documentação do Duck Creek Claims. Este campo é geralmente preenchido quando o status de um sinistro muda para 'Negado' ou um estado similar. Exemplos Não é um Perigo CobertoApólice ExpiradaSinistro DuplicadoFraude Suspeita | |||
Número da Apólice PolicyNumber | O identificador único da apólice de seguro sob a qual o sinistro foi registrado. | ||
Descrição Este atributo associa o sinistro à apólice de seguro de origem. Fornece contexto sobre a cobertura, os termos e o cliente associado ao sinistro. Embora nem sempre usado diretamente na análise de fluxo de processo, o Número da Apólice é essencial para enriquecer os dados do sinistro. Permite a junção com dados de apólice e cliente para analisar como o desempenho do processo varia por segmento de cliente, tipo de apólice ou idade da apólice, proporcionando uma visão de negócio mais holística. Por que é importante Associa o sinistro ao cliente e à apólice, permitindo uma análise mais ampla de como o desempenho do processo impacta diferentes segmentos de clientes ou tipos de apólice. Onde obter 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 | |||
Resolução dentro do Prazo. IsOnTimeResolution | Um flag calculado que indica se um sinistro foi encerrado até a sua data-alvo de resolução. | ||
Descrição Este atributo booleano é obtido da comparação do timestamp da atividade 'Sinistro Encerrado' com a 'ResolutionTargetDate' para esse sinistro. Sinaliza cada sinistro como dentro do prazo (true) ou atrasado (false). Este atributo apoia diretamente o KPI 'Taxa de Resolução de Sinistros no Prazo'. Permite uma fácil agregação e visualização da adesão ao SLA em dashboards, e possibilita a análise detalhada para identificar características comuns de sinistros atrasados (por exemplo, tipos de sinistro específicos, departamentos ou caminhos de processo). Por que é importante Mede diretamente a conformidade com o SLA a nível de sinistro, permitindo filtragem poderosa e análise de causa raiz para sinistros em atraso. Onde obter Este não é um campo do sistema de origem. É calculado durante a preparação dos dados, comparando o timestamp da atividade final com o campo 'ResolutionTargetDate'. Exemplos truefalse | |||
Sistema de Origem SourceSystem | O sistema do qual os dados de evento foram extraídos. | ||
Descrição Este atributo identifica a aplicação de origem dos dados do sinistro. Neste contexto, será sempre 'Duck Creek Claims'. Embora possa parecer redundante se todos os dados vierem de um único sistema, é crucial para a governança de dados, a rastreabilidade e em cenários futuros onde os dados possam ser mesclados de múltiplos sistemas. Fornece contexto sobre a origem e a estrutura dos dados. Por que é importante Fornece linhagem de dados essencial e contexto, o que é crítico para a governança de dados e a resolução de problemas, especialmente em ambientes com múltiplos sistemas integrados. Onde obter Geralmente, trata-se de um valor estático adicionado durante o processo de extração e transformação de dados para rotular a origem dos dados. Exemplos Duck Creek Claims | |||
Tempo de Processamento ProcessingTime | A duração do trabalho ativo para uma atividade específica, calculada como Hora de Fim menos Hora de Início. | ||
Descrição Tempo de Processamento, também conhecido como tempo ativo ou tempo de manuseio, mede quanto tempo um recurso esteve ativamente trabalhando em uma tarefa específica. É calculado subtraindo o StartTime do EndTime de uma atividade. Esta métrica é um componente central da análise de desempenho. Ela ajuda a distinguir entre ineficiências causadas por tarefas de longa duração (alto tempo de processamento) versus atrasos causados pela espera por recursos ou informações (alto tempo de espera). Isso é crucial para identificar a verdadeira fonte dos gargalos. Por que é importante Mede o tempo de trabalho ativo de uma atividade, ajudando a diferenciar entre tarefas ineficientes e longos tempos de espera na análise de gargalos. Onde obter Este não é um campo do sistema de origem. É calculado durante a preparação dos dados, subtraindo o 'StartTime' do 'EndTime' para cada atividade. Exemplos 360086400300 | |||
Última Atualização de Dados LastDataUpdate | O timestamp da atualização de dados mais recente do sistema de origem. | ||
Descrição Este atributo indica a data da última atualização do conjunto de dados. Serve como um ponto de referência para a atualidade dos dados em análise. Nos dashboards e análises, é usado para informar os utilizadores sobre a atualidade dos insights. Ajuda a gerir as expectativas sobre se as transações mais recentes estão incluídas na visão do processo. Por que é importante Informa os utilizadores sobre a atualidade dos dados, o que é crucial para interpretar a análise e tomar decisões atempadas. Onde obter Este timestamp é gerado durante o processo de extração, transformação e carregamento de dados (ETL) e é geralmente armazenado nos metadados do dataset. Exemplos 2024-05-21T02:00:00Z | |||
Valor de Indenização SettlementAmount | O valor financeiro final acordado para liquidar o sinistro. | ||
Descrição Este atributo regista o valor da indenização calculado e autorizado para pagamento. Esta é uma métrica-chave baseada em resultados para cada sinistro que culmina em pagamento. Este atributo é crucial para a análise financeira e para dashboards como 'Tempo de Autorização e Emissão de Pagamento'. Pode ser comparado com o 'Montante da Perda Inicial' para analisar a precisão da reserva e é fundamental para entender os resultados financeiros do processo de sinistros. Por que é importante Representa o principal resultado financeiro de um sinistro, essencial para relatórios financeiros e para analisar a precisão das estimativas iniciais de perdas. Onde obter Consulte a documentação do Duck Creek Claims. Esta informação é geralmente armazenada em tabelas de transações financeiras ou relacionadas a pagamentos, associadas ao sinistro. Exemplos 1450.7522000.00115800.20 | |||
Atividades de Processamento de Sinistros
| Atividade | Descrição | ||
|---|---|---|---|
Decisão sobre o Sinistro Tomada | Esta atividade representa a decisão oficial sobre o sinistro, como 'Aprovado', 'Parcialmente Aprovado' ou 'Negado'. É um marco crucial, inferido de uma alteração no status final da decisão. | ||
Por que é importante Este é um marco fundamental na tomada de decisão. O tempo que antecede este ponto e o resultado da decisão são cruciais para a análise e eficiência do processo. Onde obter Inferido a partir de uma alteração num campo dedicado de 'Decisão de Sinistro' ou 'Estado de Sinistro' para um estado final como 'Aprovado' ou 'Recusado'. O timestamp desta alteração é capturado. Captura Inferido a partir de uma atualização no estado primário ou campo de decisão do sinistro. Tipo de evento inferred | |||
Pagamento Autorizado | Representa a aprovação formal do valor de indenização calculado a ser pago. Geralmente, este é um passo distinto que envolve um gerente ou uma autoridade separada, registrado como uma transação de aprovação explícita. | ||
Por que é importante Este é um ponto de controlo fundamental e um potencial gargalo antes do pagamento. A duração desde a 'Decisão do Sinistro Tomada' até este ponto é medida pelo KPI 'Tempo Médio de Aprovação de Sinistro'. Onde obter Geralmente, trata-se de um evento explícito num workflow ou módulo financeiro, onde um utilizador com permissões específicas aprova o pagamento. Seria encontrado num log de aprovações. Captura Um evento de aprovação explícita registrado em um workflow ou log de transação. Tipo de evento explicit | |||
Pagamento Emitido | Esta atividade marca a execução da transação financeira para pagar o sinistro. É um evento claro e explícito gerado quando o pagamento é enviado por cheque, EFT ou outros métodos. | ||
Por que é importante Isto significa a conclusão da obrigação financeira de um sinistro aprovado. O tempo entre 'Payment Authorized' e 'Payment Issued' revela a eficiência do departamento financeiro. Onde obter Capturado da tabela de transações financeiras no Duck Creek Claims, que regista todos os pagamentos de saída com um código de transação e timestamp específicos. Captura Uma entrada discreta de log de transação financeira é criada quando o pagamento é processado. Tipo de evento explicit | |||
Sinistro Encerrado | Esta é a atividade final, que marca o encerramento administrativo do processo de sinistro após o pagamento ter sido emitido ou o sinistro ter sido liquidado. É registada pela atualização de status final para 'Closed'. | ||
Por que é importante Esta atividade marca o fim bem-sucedido do processo. É o ponto final para o cálculo do 'Tempo Médio de Ciclo Fim a Fim do Sinistro' e de outras métricas de duração importantes. Onde obter Inferido do timestamp da alteração de estado final para 'Fechado' ou 'Liquidado' na tabela de dados principal do sinistro. Captura Inferido do estado final do sinistro ser definido como 'Fechado'. Tipo de evento inferred | |||
Sinistro Negado | Esta atividade representa um desfecho alternativo para o processo, no qual o sinistro é oficialmente negado. É registado quando o status final do sinistro é definido como 'Negado' ou 'Rejeitado'. | ||
Por que é importante Este é um resultado crucial que requer análise separada. Compreender por que e quando os sinistros são negados ajuda a melhorar os processos de receção e a gerir a conformidade. Onde obter Inferido do timestamp da alteração de estado final do sinistro para um estado de 'Recusado', 'Rejeitado' ou 'Encerrado sem Pagamento' na tabela de entidade do sinistro. Captura Inferido do estado final do sinistro ser um motivo de recusa. Tipo de evento inferred | |||
Sinistro Submetido | Este é o primeiro evento, representando a receção do Primeiro Aviso de Sinistro (FNOL) pela seguradora. É tipicamente registado como uma transação explícita quando um agente ou tomador de seguro introduz as informações iniciais do sinistro no sistema. | ||
Por que é importante Esta atividade marca o início de todo o ciclo de vida do sinistro. Analisar o tempo desde este evento até outros é crucial para compreender a duração total do processamento e a eficiência da entrada de sinistros. Onde obter Normalmente, este é um evento explícito registado numa tabela de log de sinistros ou FNOL quando um novo registo de sinistro é criado pela primeira vez no Duck Creek Claims. Captura Evento registrado na criação inicial de um novo registro de sinistro. Tipo de evento explicit | |||
Indenização Calculada | Após uma decisão de aprovação, esta atividade representa o cálculo do valor final de liquidação ou pagamento. Pode ser uma etapa explícita ou inferida a partir da finalização dos valores de pagamento no módulo financeiro do sistema. | ||
Por que é importante Esta atividade é crucial para medir o KPI de 'Taxa de Retrabalho de Indenização'. Múltiplas ocorrências deste evento para um único sinistro indicam ineficiências, erros ou negociações na fase de indenização. Onde obter Pode ser uma entrada explícita no log de transações ou inferido a partir de atualizações no campo 'Valor do Acordo' nos dados financeiros do sinistro. Os logs de auditoria neste campo são a fonte primária. Captura Evento registrado quando o valor final do pagamento é calculado e salvo. Tipo de evento explicit | |||
Informações Adicionais Recebidas | Marca o recebimento da informação solicitada, o que permite que o processamento do sinistro continue. Isso pode ser registrado manualmente pelo regulador ou automaticamente se a informação for submetida via um portal digital. | ||
Por que é importante O tempo entre 'Informação Solicitada' e 'Informação Recebida' é um período de espera crítico. Analisar essa duração ajuda a identificar dependências externas e gargalos de comunicação. Onde obter Isso pode ser um evento explícito de uma integração com um sistema de gestão documental, ou um registo manual ou alteração de status realizada pelo regulador de sinistros após receber os documentos. Captura Evento registrado quando um documento é carregado ou uma entrada manual é inserida por um regulador de sinistros. Tipo de evento explicit | |||
Informações Adicionais Solicitadas | Esta atividade ocorre quando o regulador de sinistros determina que são necessárias mais informações e envia uma solicitação ao segurado ou a um terceiro. Geralmente, é um evento explícito ligado ao módulo de comunicação ou correspondência do sistema. | ||
Por que é importante A alta frequência desta atividade pode indicar problemas no processo inicial de recolha de dados. Também introduz um tempo de espera significativo, impactando o tempo de ciclo geral. Onde obter Capturado a partir de logs relacionados com comunicações de saída (por exemplo, cartas, e-mails) ou de uma transação específica de 'Pedido de Informações' no Duck Creek Claims. Captura Registrado quando uma correspondência ou tarefa para solicitação de informações é gerada. Tipo de evento explicit | |||
Investigação Concluída. | Representa a conclusão das atividades de investigação, onde todos os fatos necessários foram apurados. Isso é geralmente inferido quando o status do sinistro passa de 'Em Investigação' para um status de tomada de decisão como 'Decisão Pendente'. | ||
Por que é importante Concluir a investigação é um marco importante que desbloqueia as fases de tomada de decisão e liquidação. Atrasos aqui têm um impacto significativo nas etapas subsequentes. Onde obter Inferido do timestamp de uma atualização de estado de sinistro de um estado de 'investigação' para um estado de 'revisão' ou 'decisão'. Captura 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. É frequentemente inferida de uma alteração no status do sinistro para 'Em Investigação' ou um estado semelhante. | ||
Por que é importante Isto marca o início de uma fase intensiva em recursos. Medir a duração da investigação é fundamental para o KPI 'Duração Média da Investigação' e ajuda a gerir uma parte crítica do processo. Onde obter Inferido do timestamp de uma atualização de estado de sinistro para 'Investigação em Andamento' ou 'Inspeção Pendente' no campo principal de estado do sinistro. Captura Derivado de uma mudança no status do sinistro que indica o início das atividades de investigação. Tipo de evento inferred | |||
Perito Atribuído | Este evento regista a atribuição de um regulador ou gestor de sinistros ao sinistro registado. O sistema regista esta atribuição, criando um ponto claro de transferência de responsabilidade e estabelecendo a titularidade do sinistro para o seu ciclo de vida. | ||
Por que é importante Crucial para analisar a alocação de recursos, a carga de trabalho do perito e identificar atrasos na atribuição de sinistros. É um ponto crucial de transição que pode introduzir tempo de espera. Onde obter Monitorizado através de uma atualização ao campo 'Assigned Adjuster' na tabela principal de dados de sinistros. Um log de histórico ou auditoria para este campo fornece o timestamp. Captura Registrado em uma trilha de auditoria quando o campo do regulador é preenchido ou alterado. Tipo de evento explicit | |||
Revisão Inicial Concluída. | Representa a conclusão da primeira revisão completa do sinistro pelo regulador (ajudicador) designado. Isso é geralmente inferido quando o status do sinistro muda após a atribuição, como passar de 'Atribuído' para 'Em Revisão' ou 'Em Investigação'. | ||
Por que é importante Este marco ajuda a medir o tempo até à primeira ação de um perito de sinistros e pode indicar potenciais atrasos na sua carga de trabalho. É o primeiro grande marco com intervenção humana. Onde obter Inferido a partir de uma alteração de estado no campo de estado do sinistro, por exemplo, uma transição para 'Revisão Inicial Concluída' ou 'Informação Pendente'. O timestamp desta alteração de estado é utilizado. Captura Inferido a partir da alteração no campo de estado do sinistro após a designação do regulador. Tipo de evento inferred | |||
Sinistro Avaliado | Este marco assinala o ponto em que as reservas financeiras são estabelecidas ou atualizadas com base nos resultados da investigação. Significa a estimativa do impacto financeiro do sinistro e é capturado quando os montantes das reservas são introduzidos ou ajustados. | ||
Por que é importante Este é um ponto de controlo financeiro crucial no processo. Analisar quando este ocorre fornece insights sobre a velocidade da avaliação financeira e a sua precisão. Onde obter Frequentemente, trata-se de uma transação financeira explícita registada no log de transações financeiras do sinistro ou na tabela de histórico de reservas no Duck Creek Claims. Captura Transação financeira registrada para a definição ou atualização de reservas de sinistro. Tipo de evento explicit | |||
Sinistro Registado | Marca a aceitação formal e o registro do sinistro submetido, momento em que um ID de Sinistro único é oficialmente atribuído. Este é frequentemente um evento de sistema automatizado após a validação inicial dos dados. | ||
Por que é importante Formaliza o início do sinistro e desencadeia processos subsequentes, como a designação do regulador. O tempo entre o envio e o registro pode indicar problemas iniciais de qualidade de dados ou de carga do sistema. Onde obter Inferido do timestamp quando o ID primário do Sinistro é gerado e o estado do sinistro muda de 'pendente' ou 'submetido' para 'aberto' ou 'registado' na tabela de entidade principal do sinistro. Captura Derivado do timestamp de criação do registro principal do sinistro ou de uma mudança de status para 'Aberto'. Tipo de evento inferred | |||
Guias de Extração
Etapas
- Acessar o Utilitário de Configuração do Duck Creek Data Hub: Faça login no ambiente Duck Creek e navegue até o aplicativo Data Hub. Você precisará de permissões apropriadas para criar ou modificar configurações de exportação de dados.
- Criar uma Nova Tarefa de Exportação de Dados: Dentro do utilitário Data Hub, inicie o processo para criar uma nova tarefa de exportação. Dê um nome descritivo, como ProcessMind_Claims_Event_Log_Export.
- Definir a Fonte de Dados: Configure a tarefa para se conectar ao banco de dados SQL principal do Data Hub. Você precisará fornecer o nome do servidor, o nome do banco de dados e as credenciais para um usuário com acesso de leitura aos schemas relevantes.
- Inserir a Consulta de Extração: Navegue até a seção de definição da consulta da tarefa de exportação. Copie o script completo da seção query abaixo e cole-o no editor de consultas.
- Definir Parâmetros da Consulta: Localize a seção de parâmetros na configuração. Defina e atribua valores para os parâmetros @StartDate e @EndDate referenciados na consulta para especificar o período de extração desejado. Por exemplo, '2023-01-01' e '2023-12-31'.
- Mapear Colunas de Saída: Configure as definições do arquivo de saída. Certifique-se de que as colunas definidas na declaração SELECT (ClaimId, ActivityName, EventTime, etc.) sejam mapeadas corretamente para as colunas no arquivo de saída. Os nomes dos cabeçalhos no arquivo de saída devem corresponder exatamente a esses nomes.
- Configurar o Arquivo de Saída: Especifique o formato de saída como CSV. Defina o delimitador como vírgula (,) e a codificação de caracteres como UTF-8 para garantir a compatibilidade com o ProcessMind.
- Definir o Destino: Especifique o caminho do arquivo ou a localização na rede onde o arquivo CSV gerado será salvo. Certifique-se de que o sistema tenha permissões de gravação para este local.
- Agendar a Tarefa de Exportação: Configure o agendamento da tarefa. Para uma análise inicial, você pode executá-la manualmente. Para monitoramento contínuo, configure um agendamento recorrente (por exemplo, diário ou semanal).
- Executar e Recuperar o Arquivo: Execute a tarefa para gerar o arquivo de log de eventos. Uma vez concluído, recupere o arquivo CSV do destino especificado na etapa 8.
- Preparar para Upload: Antes de fazer o upload para o ProcessMind, abra o arquivo CSV para realizar uma verificação final. Verifique se os cabeçalhos estão corretos, o formato da data é consistente (YYYY-MM-DD HH:MI:SS) e os dados aparecem conforme o esperado.
Configuração
- Pré-requisitos: É necessário ter acesso ao módulo Duck Creek Data Hub. O usuário ou conta de serviço que executa a tarefa de exportação deve ter permissões de leitura nas tabelas de banco de dados subjacentes do Data Hub (p. ex., [DataHubSchema].[FactClaimTransaction], [DataHubSchema].[DimClaim], [DataHubSchema].[DimStatusHistory]).
- Configuração do Período de Dados: A consulta utiliza os parâmetros @StartDate e @EndDate. É crucial configurá-los para definir a janela de extração. Para uma primeira análise, um período de 6 a 12 meses é recomendado para capturar casos concluídos e em andamento suficientes.
- Filtragem: A consulta inclui um espaço reservado /* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ dentro da Common Table Expression (CTE). Descomente e modifique esta linha para filtrar linhas de negócio específicas (p. ex., 'Personal Auto', 'Commercial Property') para reduzir o volume de dados e focar a análise.
- Ciclo de Atualização do Data Hub: Esteja ciente da latência dos dados do Data Hub. Os dados não são em tempo real e são tipicamente atualizados em um cronograma (p. ex., diariamente). Os dados extraídos estarão tão atualizados quanto a última atualização bem-sucedida do Data Hub.
- Formato de Saída: A tarefa de exportação deve ser configurada para produzir um arquivo simples, preferencialmente CSV. Certifique-se de que o qualificador de texto esteja configurado para aspas duplas (") para lidar com quaisquer vírgulas dentro dos campos de dados.
a Consulta de Exemplo config
`config
-- 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;
`