Template de Dados: Processamento de Sinistros

Guidewire ClaimCenter
Template de Dados: Processamento de Sinistros

Seu Modelo de Dados de Processamento de Sinistros

Bem-vindo ao seu recurso dedicado para otimizar o processamento de sinistros. Este template descreve os atributos de dados essenciais a coletar, as atividades críticas a monitorar e fornece orientações claras para a extração de dados. Utilize-o para garantir que todas as informações necessárias para uma análise de processo abrangente sejam capturadas.
  • Atributos recomendados para coletar
  • Atividades-chave para monitorar
  • Orientação de Extração para Guidewire ClaimCenter
É novo em event logs? Saiba como criar um event log para Process Mining.

Atributos de Processamento de Sinistros

Estes campos de data recomendados são cruciais para construir um event log completo e analisar eficazmente os seus workflows de processamento de sinistros.
3 Obrigatório 4 Recomendado 15 Opcional
NomeDescrição
Hora do Evento
EventTime
A data e hora precisas em que a atividade ocorreu.
Descrição

Este timestamp marca o momento exato em que uma atividade foi registrada no sistema. É fundamental para toda a análise de processo baseada em tempo.

A ordenação cronológica do EventTime para um único ID de Sinistro permite a reconstrução do fluxo do processo. A diferença de tempo entre eventos consecutivos é utilizada para calcular tempos de ciclo, tempos de espera e tempos de processamento, que são críticos para a análise de desempenho, identificação de gargalos e monitoramento de SLA.

Por que é importante

Este timestamp é essencial para ordenar eventos, calcular tempos de ciclo e durações, e identificar atrasos no processo.

Onde obter

Encontrado junto com dados de evento ou atividade nas tabelas de histórico ou auditoria do Guidewire ClaimCenter, frequentemente como um campo 'CreateTime' ou 'UpdateTime'.

Exemplos
2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z
ID do Sinistro
ClaimID
O identificador único para cada sinistro de seguro, servindo como o identificador primário do case.
Descrição

O ID do Sinistro é a pedra angular da análise do processo de sinistros, identificando de forma única cada caso desde a submissão até o encerramento. Ele vincula todas as atividades, documentos, pagamentos e comunicações associadas, garantindo uma visão completa e coerente do ciclo de vida de um sinistro.

Em Process Mining, cada evento no conjunto de dados está ligado a um ID do Sinistro, permitindo a reconstrução do fluxo de processo de ponta a ponta. Isso é essencial para analisar tempos de ciclo, identificar variantes de processo e rastrear a jornada de um sinistro por diferentes departamentos e reguladores.

Por que é importante

É a chave fundamental que conecta todos os eventos relacionados, tornando possível rastrear e analisar toda a jornada de um único sinistro.

Onde obter

Esta é uma chave primária no Guidewire ClaimCenter, tipicamente encontrada como Claim.ClaimNumber ou um campo similar na entidade central Sinistro.

Exemplos
000-123-45678000-987-65432001-456-11223
Nome da Atividade
ActivityName
O nome da atividade de negócio ou evento que ocorreu em um ponto específico do ciclo de vida do sinistro.
Descrição

Este atributo descreve uma etapa ou marco específico no processo de sinistros, como 'Sinistro Criado', 'Investigação Iniciada' ou 'Pagamento Emitido'. A sequência destas atividades para um dado Claim ID forma o process flow.

A análise da sequência, frequência e duração entre as 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.

Por que é importante

Ele define as etapas do processo, permitindo a visualização de mapas de processo e a análise do fluxo e dos gargalos do processo.

Onde obter

Isto é tipicamente derivado de tabelas de eventos ou logs de auditoria no ClaimCenter, frequentemente mapeando eventos de sistema específicos ou mudanças de status para nomes de atividades padronizados.

Exemplos
Sinistro CriadoDecisão de Responsabilidade TomadaPagamento EmitidoSinistro Encerrado
Ajustador Atribuído
AssignedAdjuster
O nome ou ID do usuário atribuído para tratar o sinistro ou uma atividade específica.
Descrição

Este atributo identifica o regulador de sinistros individual responsável por um sinistro num determinado momento. Um regulador pode ser atribuído a todo o sinistro ou a tarefas específicas dentro dele.

A análise por Regulador Atribuído é crucial para o equilíbrio da carga de trabalho, a gestão de desempenho e a identificação de oportunidades de formação. Ajuda a responder a perguntas como: 'Quais reguladores têm a maior carga de cases?', 'Existem variações de desempenho entre os reguladores?' e 'O trabalho está distribuído de forma equitativa?'.

Por que é importante

Rastreia o envolvimento do usuário, permitindo a análise da carga de trabalho, comparação de desempenho e identificação de gargalos relacionados a recursos.

Onde obter

Disponível na entidade Sinistro ou Exposição no ClaimCenter, geralmente vinculado ao objeto Usuário (ex.: Claim.Assignee).

Exemplos
j.doem.smiths.jones
Causa do Sinistro
LossCause
O motivo ou causa específica do evento de perda (por exemplo, Colisão, Incêndio, Danos por Água).
Descrição

Este atributo fornece um contexto detalhado sobre a razão pela qual o sinistro foi apresentado. A Causa da Perda/Dano frequentemente dita as etapas de investigação necessárias, o tipo de especialistas exigidos e a complexidade geral do sinistro.

A análise do processo pela Causa da Perda/Dano pode revelar padrões ocultos. Por exemplo, sinistros relacionados com 'Danos por Água' podem ter uma taxa de retrabalho mais elevada ou exigir mais envolvimento de especialistas em comparação com sinistros de 'Roubo'. Estes insights ajudam a criar procedimentos de tratamento mais especializados e eficientes.

Por que é importante

Fornece contexto sobre a natureza do sinistro, permitindo a análise de como diferentes causas de sinistro impactam o fluxo e a duração do processo.

Onde obter

Este é um campo padrão na entidade Sinistro, tipicamente chamado 'LossCause'.

Exemplos
ColisãoIncêndioDanos por ÁguaRoubo
Status do Sinistro
ClaimStatus
O status geral do sinistro no momento do evento (por exemplo, Aberto, Fechado, Negado).
Descrição

Este atributo reflete o estado de alto nível do sinistro. Os status chave incluem 'Aberto', 'Fechado', 'Negado' e 'Reaberto'. O status final de um sinistro é uma métrica de resultado crítica.

O acompanhamento das alterações no Claim Status ajuda a definir marcos e resultados chave do processo. É usado para identificar a resolução final de um sinistro, calcular as taxas de rejeição e analisar a frequência de sinistros reabertos após o fecho, o que frequentemente indica problemas no processo ou insatisfação do cliente.

Por que é importante

Indica o resultado de um sinistro, essencial para analisar taxas de rejeição, padrões de encerramento e frequências de reabertura de sinistros.

Onde obter

Este é um campo central na entidade Sinistro, tipicamente nomeado 'Estado' ou 'Status'.

Exemplos
AbertoEncerradoNegadoReaberto
Tipo de Sinistro
ClaimType
A categoria do sinistro de seguro, como Automóvel, Imóvel ou Responsabilidade Civil.
Descrição

O Tipo de Sinistro é uma categorização fundamental do sinistro, baseada na linha de negócio ou na natureza da perda. Diferentes tipos de sinistros frequentemente seguem processos distintos, apresentam níveis de complexidade variados e estão sujeitos a regulamentações diversas.

Segmentar a análise de processos por Tipo de Sinistro é crucial para obter insights significativos. Isso permite comparar o desempenho do processo entre diferentes linhas de negócio, identificar gargalos específicos de cada tipo e adaptar as iniciativas de melhoria de processo às características únicas de cada categoria de sinistro.

Por que é importante

Permite a segmentação de sinistros, pois diferentes tipos (ex.: Automóvel vs. Imóvel) frequentemente seguem processos distintos e têm metas de desempenho diferentes.

Onde obter

Derivado da entidade Apólice ou Sinistro no ClaimCenter, frequentemente baseado no código da Linha de Negócio (LOB).

Exemplos
Automóvel PessoalPropriedade ComercialResponsabilidade Civil GeralCompensação de Acidentes de Trabalho
Data Alvo de Resolução
ResolutionTargetDate
A data até a qual o sinistro deve ser resolvido de acordo com SLAs internos ou regulatórios.
Descrição

A Data Alvo de Resolução é um prazo estabelecido para o encerramento do sinistro, muitas vezes determinado por fatores como jurisdição, tipo de sinistro e termos da apólice. Ela serve como uma referência para medir o desempenho e a conformidade.

Este atributo é crítico para a construção de dashboards e KPIs de aderência ao SLA. Ao comparar a data real de 'Sinistro Fechado' com esta data alvo, a análise pode sinalizar automaticamente sinistros atrasados, medir as taxas de desempenho no prazo e identificar quais tipos de sinistros ou departamentos têm dificuldade em atingir suas metas.

Por que é importante

Este é o parâmetro para medir a conformidade com o Acordo de Nível de Serviço (SLA) e identificar sinistros com risco de atraso.

Onde obter

Este pode ser um campo personalizado ou derivado com base em regras de negócio configuradas no ClaimCenter, possivelmente relacionado a métricas específicas de sinistros.

Exemplos
2023-06-142023-07-202023-08-28
Data do Sinistro
LossDate
A data em que ocorreu o incidente ou a perda que desencadeou o sinistro.
Descrição

A Data do Sinistro é a data do evento real (por exemplo, acidente de carro, danos à propriedade) para o qual o sinistro está sendo feito. Esta é distinta da data em que o sinistro foi reportado ou criado.

O lapso de tempo entre a Data do Sinistro e a atividade 'Sinistro Criado' (conhecido como lapso de notificação) é um KPI importante. A análise disso pode fornecer insights sobre o comportamento do cliente e a eficácia dos canais de primeira notificação de sinistro.

Por que é importante

Fornece contexto crucial sobre a origem do sinistro e ajuda a analisar o atraso de notificação (tempo do incidente até o envio do sinistro).

Onde obter

Este é um campo de data fundamental na entidade Sinistro, frequentemente chamado 'LossDate'.

Exemplos
2023-05-102023-04-202023-05-28
Departamento
Department
A unidade de negócio ou departamento responsável pelo tratamento da atividade do sinistro.
Descrição

Este atributo indica o departamento ou equipa a que pertence o regulador atribuído, como 'Sinistros Automóveis', 'Sinistros de Propriedade' ou 'Unidade de Investigações Especiais'. Fornece um contexto organizacional para o processo.

A análise por Departamento é crucial para compreender o desempenho do processo a nível organizacional. Ajuda a identificar atrasos na passagem de tarefas entre departamentos, comparar a eficiência entre equipas e alocar recursos de forma mais eficaz em toda a organização de sinistros.

Por que é importante

Fornece contexto organizacional, permitindo a análise de desempenho entre diferentes equipes e destacando problemas de passagem de tarefas interdepartamentais.

Onde obter

Esta informação é tipicamente associada ao perfil do usuário ou grupo atribuído dentro do ClaimCenter.

Exemplos
Divisão de Sinistros de AutomóveisUnidade de Sinistros PatrimoniaisUnidade de Investigações Especiais (SIU)
É Automatizado
IsAutomated
Um indicador que mostra se uma atividade foi realizada automaticamente pelo sistema ou por um usuário humano.
Descrição

Este atributo booleano distingue entre atividades executadas por um sistema (por exemplo, criação automática de reserva, correspondência gerada pelo sistema) e aquelas realizadas manualmente por um regulador.

A análise deste atributo é fundamental para compreender o nível de automação no processo de sinistros. Ajuda a identificar pontos críticos de intervenção manual, medir a eficácia das iniciativas de straight-through processing e encontrar novas oportunidades de automação ao identificar tarefas repetitivas e baseadas em regras que são atualmente executadas por humanos.

Por que é importante

Distingue entre atividades gerenciadas pelo sistema e atividades manuais, o que é crucial para a análise de automação e identificação de gargalos manuais.

Onde obter

Isto frequentemente precisa ser derivado. Por exemplo, eventos registrados por um usuário genérico de 'sistema' podem ser sinalizados como automatizados.

Exemplos
truefalse
É Retrabalho
IsRework
Um indicador de que uma atividade representa um ciclo de retrabalho, ou seja, um retorno a uma etapa anterior do processo.
Descrição

Este atributo calculado sinaliza atividades que fazem parte de um ciclo de retrabalho. Por exemplo, se o processo volta de 'Investigação Concluída' para 'Investigação Iniciada', a segunda atividade 'Investigação Iniciada' seria marcada como retrabalho.

Identificar o retrabalho é fundamental para descobrir ineficiências de processo e problemas de qualidade. O dashboard de Frequência de Retrabalho e Rejeição depende desta métrica para quantificar com que frequência os sinistros se desviam do 'caminho feliz' ideal. Analisar as causas do retrabalho pode levar a melhorias significativas na qualidade e velocidade do processo.

Por que é importante

Destaca ineficiências de processo e problemas de qualidade ao sinalizar explicitamente atividades que fazem parte de um ciclo de retrabalho.

Onde obter

Isto é calculado dentro da ferramenta de process mining, analisando a sequência de atividades para cada caso.

Exemplos
truefalse
Estado de Jurisdição
JurisdictionState
O estado ou jurisdição que rege o sinistro, o que dita os requisitos regulatórios.
Descrição

Este atributo especifica a jurisdição legal (por exemplo, o estado dos EUA) sob a qual o sinistro está a ser tratado. Os regulamentos de seguros podem variar significativamente entre jurisdições, impactando as etapas do processo necessárias, os prazos de comunicação e a documentação.

Este é um atributo vital para a monitorização da conformidade. A análise do processo por jurisdição garante que os requisitos regulatórios específicos de cada estado estão a ser cumpridos. Também pode explicar variações nos cycle times ou nos process paths que são impulsionadas por restrições legais, e não por ineficiência operacional.

Por que é importante

Crucial para a análise de conformidade, visto que diferentes jurisdições possuem regulamentações distintas que afetam o processo de sinistros.

Onde obter

Um campo padrão na entidade Sinistro, geralmente nomeado como 'JurisdictionState'.

Exemplos
CANYTXFL
Hora de Término
EndTime
O timestamp indicando quando uma atividade foi concluída.
Descrição

A Hora de Término marca a conclusão de uma atividade, especialmente para tarefas com duração mensurável, como 'Investigação' ou 'Revisão de Documentos'. Embora muitas atividades de Process Mining sejam instantâneas (onde a StartTime é suficiente), atividades com início e fim distintos são melhor representadas com ambos os timestamps.

Este atributo permite o cálculo preciso do tempo de processamento da atividade, distinto do tempo de espera. Ajuda a identificar quais tarefas específicas são demoradas, em vez de apenas observar longos atrasos entre diferentes etapas.

Por que é importante

Ele permite a medição precisa do tempo que uma atividade leva para ser concluída, separando o tempo de processamento do tempo de espera.

Onde obter

Isto pode precisar ser derivado encontrando um evento subsequente que conclua logicamente a atividade (ex: mudança de status de 'Em Andamento' para 'Concluído').

Exemplos
2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z
Sistema de Origem
SourceSystem
O sistema do qual os dados foram extraídos.
Descrição

Este atributo identifica a origem dos data de eventos. Num cenário empresarial moderno, os eventos relacionados com sinistros podem ter origem em múltiplos sistemas, como um sistema central como o Guidewire, um sistema de gestão documental ou um portal do cliente.

Especificar o sistema de origem é crucial para a governança de data, a resolução de inconsistências de data e a compreensão do panorama tecnológico do processo. Ajuda a diferenciar entre as etapas centrais do processo e as atividades de suporte de sistemas periféricos.

Por que é importante

Identifica a origem dos dados, crucial para a governança de dados e para análises que envolvem múltiplos sistemas integrados.

Onde obter

Este é tipicamente um valor estático adicionado durante o processo de extração, transformação e carregamento de dados (ETL).

Exemplos
Guidewire ClaimCenter v10API do Portal do ClienteDocumentum
Solicitação de Informação Repetida
RepeatedInfoRequestFlag
Um indicador que aponta se 'Informações Adicionais Solicitadas' ocorreu mais de uma vez para o mesmo sinistro.
Descrição

Este boolean flag é definido como verdadeiro se um sinistro tiver mais de uma atividade de 'Informações Adicionais Solicitadas'. Este cenário frequentemente aponta para ineficiências na fase inicial de recolha de informações.

Este atributo suporta diretamente o KPI 'Taxa de Pedidos de Informação Repetidos'. Ajuda a quantificar o problema da recolha inicial incompleta de factos, que pode levar a atrasos significativos e frustração do cliente. A análise de sinistros com este flag pode ajudar a melhorar as checklists e os procedimentos para os reguladores, garantindo que todas as informações necessárias são solicitadas de uma só vez.

Por que é importante

Identifica ineficiências onde a coleta de informações não é feita completamente na primeira vez, levando a atrasos e retrabalho no processo.

Onde obter

Calculado na ferramenta de process mining contando as ocorrências da atividade 'Informações Adicionais Solicitadas' por caso.

Exemplos
truefalse
Status do SLA
SLAState
Indica se o sinistro foi encerrado dentro da data-alvo de resolução.
Descrição

Este atributo calculado fornece um status categórico de conformidade com o SLA para cada sinistro encerrado. Ele é derivado comparando o timestamp da atividade 'Sinistro Encerrado' com a 'Data Alvo de Resolução'.

Este atributo apoia diretamente o dashboard de 'Adesão ao Prazo de Resolução de Sinistros', simplificando a análise em categorias claras como 'Dentro do Prazo' ou 'Atrasado'. Ele permite fácil filtragem e agregação para calcular a taxa geral de conformidade com o SLA e aprofundar as razões dos atrasos.

Por que é importante

Fornece um resultado claro e categórico para a conformidade com o SLA, facilitando a filtragem, agregação e análise do desempenho no prazo.

Onde obter

Campo calculado: IF (ActualCloseDate <= ResolutionTargetDate, 'On Time', 'Late').

Exemplos
No PrazoAtrasado
Tempo de Processamento
ProcessingTime
A duração gasta trabalhando ativamente em uma atividade.
Descrição

O Tempo de Processamento mede o tempo em que uma atividade está ativamente sendo trabalhada, calculado como a diferença entre seu 'End Time' e 'Start Time'. Isso é distinto do tempo de ciclo, que inclui períodos de espera.

Esta métrica calculada é crucial para a análise de desempenho, pois isola o verdadeiro esforço exigido para uma tarefa do tempo ocioso ou de espera. Ela ajuda a identificar com precisão quais etapas são genuinamente demoradas e onde ganhos de eficiência podem ser alcançados por meio de treinamento, melhores ferramentas ou redesenho de processos.

Por que é importante

Mede o tempo de trabalho ativo para uma atividade, ajudando a distinguir o tempo de valor agregado do tempo de espera.

Onde obter

Campo calculado: EndTime - StartTime. Requer que ambos os timestamps estejam disponíveis nos dados de origem.

Exemplos
PT8HPT15MP2D
Tipo de Apólice
PolicyType
O tipo específico de apólice de seguro sob a qual o sinistro foi registrado.
Descrição

O Tipo de Apólice oferece uma classificação mais granular do que o Tipo de Sinistro, detalhando o produto de seguro específico, como 'Residencial', 'Automóvel Comercial' ou 'Ciber Responsabilidade'. Este nível de detalhe pode revelar variações de processo ligadas a produtos específicos.

Analisar o processo por Tipo de Apólice ajuda a descobrir ineficiências específicas do produto. Por exemplo, sinistros para uma apólice recém-lançada podem seguir um processo menos maduro, resultando em atrasos. Esta análise pode subsidiar o design de produtos e os esforços de padronização de processos.

Por que é importante

Permite a análise de processos para produtos de seguro específicos, ajudando a identificar variações no tratamento com base nas especificidades da apólice.

Onde obter

Esta informação está localizada na entidade Policy, que está ligada ao Sinistro.

Exemplos
Multirriscos HabitacionalResponsabilidade Civil Automóvel ComercialMarítimo Interior
Última Atualização de Dados
LastDataUpdate
O timestamp indicando quando os dados foram atualizados pela última vez ou extraídos do sistema fonte.
Descrição

Este atributo fornece o timestamp da extração de data mais recente do sistema de origem. É um campo de metadata essencial para compreender a atualização da análise.

Os dashboards e as análises devem exibir esta informação de forma proeminente para que os utilizadores estejam cientes da atualidade dos data. Ajuda a avaliar se os insights refletem o estado atual das operações ou se são baseados em data mais antigos.

Por que é importante

Indica a atualidade dos dados, garantindo que os usuários entendam quão recente é a análise do processo.

Onde obter

Este valor é gerado e armazenado durante o processo de ETL, representando o timestamp do carregamento dos dados.

Exemplos
2024-07-28T04:00:00Z2024-07-29T04:00:00Z
Valor do Pagamento
PaymentAmount
O valor efetivo pago por uma atividade de pagamento.
Descrição

Este atributo regista o valor de cada pagamento individual efetuado para um sinistro. Um único sinistro pode ter múltiplos pagamentos ao longo do seu ciclo de vida.

Isto é essencial para a análise financeira no contexto de process mining. Pode ser usado para acompanhar o desembolso total por sinistro, analisar os tempos de aprovação de pagamento com base no valor e ligar as ineficiências do processo a resultados financeiros. Por exemplo, sinistros com longos cycle times podem correlacionar-se com pagamentos totais mais elevados.

Por que é importante

Rastreia as transações financeiras dentro de um sinistro, permitindo a análise dos valores de pagamento e sua relação com as atividades do processo.

Onde obter

Encontrado em entidades relacionadas a Pagamentos ligadas ao sinistro, frequentemente em uma tabela de transações ou cheques.

Exemplos
4500.00125000.00500.00
Valor Reclamado
ClaimedAmount
O valor monetário total inicialmente reclamado pelo segurado.
Descrição

Este atributo representa o valor da perda/dano conforme reportado pelo reclamante. Frequentemente, é uma estimativa inicial que pode mudar à medida que o sinistro é investigado e as reservas são estabelecidas.

A análise do Claimed Amount ajuda a segmentar os sinistros por impacto financeiro. Sinistros de alto valor frequentemente seguem um processo mais rigoroso e complexo do que os de baixo valor. A comparação do processo para diferentes faixas de valor pode revelar oportunidades para otimizar o tratamento de sinistros menores ou aplicar controlos mais rigorosos para os maiores.

Por que é importante

Permite segmentar sinistros por valor financeiro, pois sinistros de alto valor podem seguir processos diferentes e mais complexos.

Onde obter

Esta informação pode não ser um campo único, mas pode ser derivada das estimativas iniciais de perdas registradas nas exposições.

Exemplos
5000.00150000.00750.50
Obrigatório Recomendado Opcional

Atividades de Processamento de Sinistros

Estas são as etapas e marcos cruciais do processo a serem registados no seu event log para uma descoberta e análise precisas do processo de sinistros.
7 Recomendado 7 Opcional
AtividadeDescrição
Exposição Criada
Esta atividade significa a criação de uma exposição, que representa uma responsabilidade potencial específica ou um tipo de perda/dano no âmbito do sinistro (por exemplo, danos no veículo, lesões). Este é um event explícito no Guidewire.
Por que é importante

As exposições são fundamentais para a segmentação e análise de sinistros. Rastrear sua criação ajuda a entender as variações do processo com base na complexidade do sinistro e no tipo de perda.

Onde obter

Capturado do CreateTime de um novo registro na tabela cc_exposure. Cada registro está vinculado a um único ID de Sinistro.

Captura

Identificar o timestamp de criação de um novo registro na tabela de entidade Exposure.

Tipo de evento explicit
Pagamento Aprovado
Representa a aprovação formal de um pagamento de liquidação. Este é um evento de auditoria crítico e é explicitamente capturado quando um usuário com autoridade aprova a transação.
Por que é importante

Este marco fundamental desbloqueia a etapa final do pagamento. A análise do tempo antes e depois desta atividade ajuda a isolar atrasos causados por workflows de aprovação ou disponibilidade do gestor.

Onde obter

Isto é frequentemente um evento explícito registrado na tabela cc_history relacionado a uma entidade cc_check ou cc_transaction, que registra uma mudança de status de 'Aguardando Aprovação' para 'Aprovado'.

Captura

Acompanhar o evento de mudança de status para 'Aprovado' para uma transação de pagamento específica.

Tipo de evento explicit
Pagamento Emitido
Esta atividade marca a etapa final no processo de pagamento, onde o pagamento é oficialmente emitido e enviado ao sistema financeiro. É uma transação financeira explícita e registada.
Por que é importante

Esta atividade é crucial para medir a eficiência do processo de envio de pagamentos. Ajuda a diferenciar entre atrasos na aprovação e atrasos na emissão efetiva dos fundos.

Onde obter

Capturado do IssueDate ou de uma mudança de status para 'Emitido' ou 'Submetido' na entidade cc_check ou cc_transaction. Este é frequentemente um evento com carimbo de data e hora explícito.

Captura

Identificar a IssueDate ou o timestamp da mudança de status para 'Emitido' no registro de pagamento.

Tipo de evento explicit
Reserva Inicial Definida
Marca a criação da primeira transação de reserva financeira para uma exposição, estimando o custo potencial do sinistro. Este é um evento financeiro crítico e é explicitamente registrado.
Por que é importante

Este marco é crucial para a análise financeira e para entender a rapidez com que a responsabilidade potencial é avaliada. Atrasos podem impactar o planejamento financeiro e os relatórios.

Onde obter

Este evento é capturado a partir da criação do primeiro registro cc_reserveline associado a uma exposição no sinistro. O CreateTime da transação é o timestamp do evento.

Captura

Encontrar o timestamp mínimo de criação de todas as linhas de reserva para as exposições de um determinado sinistro.

Tipo de evento explicit
Sinistro Criado
Esta atividade marca o primeiro aviso de sinistro (FNOL) e a criação oficial de um novo registo de sinistro no Guidewire ClaimCenter. É capturada explicitamente quando uma nova entidade de Claim é gravada na database pela primeira vez.
Por que é importante

Como o evento inicial principal, esta atividade é essencial para medir o tempo de ciclo de sinistro de ponta a ponta. Ele fornece a linha de base para todos os KPIs subsequentes de desempenho e duração.

Onde obter

Este é um evento explícito capturado do CreateTime da tabela cc_claim. A criação de um novo registro com um ID de Sinistro único serve como o gatilho do evento.

Captura

Identificar o timestamp de criação do novo registro na tabela de entidade base Claim.

Tipo de evento explicit
Sinistro Encerrado
Marca o fechamento bem-sucedido de um sinistro após a conclusão de todas as atividades e pagamentos. Este é o principal evento final de sucesso, inferido a partir de uma alteração no status principal do sinistro.
Por que é importante

Como o evento final principal, esta atividade é essencial para calcular o tempo de ciclo de ponta a ponta e medir a aderência aos SLAs. Ela significa a conclusão do ciclo de vida do sinistro.

Onde obter

Inferido de uma mudança no campo State da tabela cc_claim para 'Closed'. O timestamp do evento é o CloseDate no registro do sinistro.

Captura

Identificar quando o campo de status mestre do sinistro é atualizado para 'Fechado'.

Tipo de evento inferred
Sinistro Negado
Representa a decisão final de negar um sinistro, servindo como um ponto final para o processo. Este evento é inferido da mudança de status do sinistro para um estado fechado com o motivo 'Negado'.
Por que é importante

Este é um evento de resultado crítico. A análise da frequência, razões e caminhos do processo que levam às negações ajuda a identificar problemas na entrada do sinistro, investigação ou interpretação da apólice.

Onde obter

Inferido de uma mudança no campo State da tabela cc_claim para 'Closed', combinado com o campo CloseReason sendo 'Denied' ou um valor similar. O timestamp do evento é o CloseDate.

Captura

Filtrar por mudanças de status de sinistro para 'Fechado' onde o código de motivo indica recusa.

Tipo de evento inferred
Decisão de Responsabilidade Tomada
Significa o ponto em que uma decisão sobre responsabilidade ou culpa foi determinada para uma exposição. Este evento é geralmente inferido de uma mudança de status na entidade Exposição.
Por que é importante

Este é um marco de decisão crítico que precede as fases de liquidação e pagamento. A análise do tempo até esta decisão ajuda a identificar gargalos nas etapas de investigação e avaliação.

Onde obter

Inferido da tabela cc_history ao rastrear uma mudança no campo State ou um campo de status de responsabilidade customizado na entidade cc_exposure. O timestamp do registro de histórico indica a hora do evento.

Captura

Monitore os logs de auditoria ou tabelas de histórico para atualizações no estado da exposição ou no status da responsabilidade.

Tipo de evento inferred
Informações Adicionais Recebidas
Marca a conclusão de um pedido de informações adicionais. Isso é registrado quando a 'Activity' (tarefa) correspondente ao pedido de informações é marcada como 'Completed' (Concluída).
Por que é importante

Este é o ponto final para o KPI 'Tempo de Ciclo de Coleta de Informações Adicionais'. Longas durações entre a solicitação e o recebimento são fontes comuns de atraso no processo de sinistros.

Onde obter

Capturado do CloseTime de um registro cc_activity onde o ActivityPattern se relaciona a uma solicitação de informação. O status da atividade deve ser 'Concluída'.

Captura

Identificar o timestamp de conclusão de uma tarefa de solicitação de informação externa.

Tipo de evento explicit
Informações Adicionais Solicitadas
Representa uma solicitação enviada ao reclamante ou a um terceiro para mais informações ou documentação. Geralmente, é registrada como uma 'Atividade' (tarefa) explícita criada no ClaimCenter.
Por que é importante

Esta atividade é o ponto de partida para a medição do KPI 'Tempo de Ciclo de Recolha de Informações Adicionais'. Ocorrências frequentes podem indicar processos FNOL incompletos ou uma recolha de informações ineficiente.

Onde obter

Capturado do CreateTime de um registro cc_activity onde o ActivityPattern está relacionado à solicitação de documentação ou informação de uma parte externa.

Captura

Identificar a criação de uma tarefa de solicitação de informação externa.

Tipo de evento explicit
Investigação Iniciada
Indica o início formal da fase de investigação para um sinistro ou exposure. Isso é frequentemente inferido da criação da primeira 'Activity' (tarefa) relacionada à investigação no Guidewire.
Por que é importante

Esta atividade marca o início de uma fase crucial, muitas vezes demorada. A análise do tempo até o início da investigação e da duração da própria investigação revela grandes gargalos.

Onde obter

Inferido do CreateTime de um registro cc_activity onde o ActivityPattern está relacionado à investigação (por exemplo, 'Initial Investigation', 'Contact Witness').

Captura

Identificar a primeira criação de uma tarefa com um padrão ou assunto relacionado à investigação.

Tipo de evento inferred
Liquidação Calculada
Esta atividade representa o ponto em que um valor de liquidação foi determinado, mas ainda não aprovado para pagamento. Pode ser inferida a partir da criação de um pagamento num estado de 'Aguardando Aprovação'.
Por que é importante

Marca a transição da avaliação para o pagamento. É o ponto de partida para medir o KPI 'Lead Time de Autorização de Pagamento', revelando atrasos na cadeia de aprovação.

Onde obter

Inferido do CreateTime de um registro cc_check ou cc_transaction onde seu status inicial é 'Pending Approval' ou um estado similar antes de 'Approved'.

Captura

Identificar a criação de um registro de pagamento ou transação em status pré-aprovado.

Tipo de evento inferred
Sinistro Atribuído
Representa a atribuição de um sinistro a um usuário (regulador) ou grupo específico para tratamento. Geralmente, é inferido ao monitorar mudanças nos campos de atribuição na entidade Sinistro.
Por que é importante

O acompanhamento das atribuições é fundamental para analisar a carga de trabalho dos peritos, identificar gargalos de encaminhamento e medir o tempo até a primeira ação pelo responsável atribuído.

Onde obter

Inferido da tabela cc_history ao rastrear mudanças nos campos AssignedUser ou AssignedGroup associados a um ID de Sinistro específico. O timestamp da mudança indica quando o evento ocorreu.

Captura

Monitore os logs de auditoria ou tabelas de histórico para atualizações nos campos de atribuição de sinistros.

Tipo de evento inferred
Sinistro Reaberto
Representa um sinistro sendo movido de um estado 'Fechado' de volta para um estado 'Aberto' para realizar trabalho adicional. Este evento é inferido a partir de uma sequência específica de mudança de status.
Por que é importante

Esta atividade significa retrabalho. Grandes volumes de sinistros reabertos indicam problemas com a liquidação inicial, danos não identificados ou outras falhas no processo, levando ao aumento de custos e ineficiência.

Onde obter

Inferido da tabela cc_history ao identificar uma mudança no campo State da entidade cc_claim de 'Closed' de volta para 'Open' ou outro estado ativo.

Captura

Monitore o campo de status mestre do sinistro para uma transição de um estado fechado para um aberto.

Tipo de evento inferred
Recomendado Opcional

Guias de Extração

Como obter seus dados do Guidewire ClaimCenter