Seu Template de dados para processamento de sinistros

Guidewire ClaimCenter
Seu Template de dados para processamento de sinistros

Seu Template de dados para processamento de sinistros

Este é o seu espaço dedicado a otimizar o processamento de sinistros. O Template apresenta os atributos de dados essenciais para coleta, as atividades importantes para acompanhamento e orientações claras para extrair os dados. Use-o para garantir que todas as informações necessárias sejam capturadas e permitir uma análise completa do processo.
  • Atributos recomendados para coleta
  • Principais atividades para acompanhar
  • Orientações para extração de dados do Guidewire ClaimCenter
Novidade em Event Logs? Saiba como criar um Event Log para Process Mining.

Atributos do processamento de sinistros

Estes campos de dados recomendados são essenciais para criar um Event Log completo e analisar com eficiência os fluxos de trabalho de processamento de sinistros.
3 Obrigatório 4 Recomendado 14 Opcional
Nome Descrição
Horário do evento
EventTime
A data e a hora exatas em que a atividade ocorreu.
Descrição

Esse registro de data e hora marca o momento exato em que uma atividade foi registrada no sistema. Ele é fundamental para todas as análises de processo baseadas em tempo.

A ordenação cronológica de EventTime para um único ID do caso permite reconstruir o fluxo do processo. A diferença de tempo entre eventos consecutivos é usada para calcular tempos de ciclo, tempos de espera e tempos de processamento, essenciais para analisar a performance, identificar gargalos e monitorar SLAs.

Por que isso importa

Esse registro de data e hora é essencial para ordenar eventos, calcular tempos de ciclo e durações e identificar atrasos no processo.

Onde encontrar

Encontrado junto aos dados de eventos ou atividades nas tabelas de histórico ou auditoria do Guidewire ClaimCenter, geralmente em um campo como 'CreateTime' ou 'UpdateTime'.

Exemplos
2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z
ID do sinistro
ClaimID
Identificador exclusivo de cada sinistro, usado como identificador principal do caso.
Descrição

O ID do sinistro é a base da análise do processo de sinistros, pois identifica cada caso de forma exclusiva, da abertura ao encerramento. Ele conecta todas as atividades, documentos, pagamentos e comunicações relacionados, oferecendo uma visão completa e coerente do ciclo de vida do sinistro.

No Process Mining, cada evento do conjunto de dados está associado a um ID do sinistro, o que permite reconstruir o fluxo do processo de ponta a ponta. Isso é essencial para analisar o tempo de ciclo, identificar variações no processo e acompanhar a jornada do sinistro entre diferentes departamentos e reguladores.

Por que isso importa

É a chave fundamental que conecta todos os eventos relacionados e permite rastrear e analisar toda a jornada de um único sinistro.

Onde encontrar

Esta é uma chave primária no Guidewire ClaimCenter, geralmente encontrada como Claim.ClaimNumber ou em um campo semelhante na entidade principal Claim.

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

Este atributo descreve uma etapa ou marco específico do processo de sinistros, como 'Sinistro criado', 'Investigação iniciada' ou 'Pagamento emitido'. A sequência dessas atividades para um determinado ID do caso forma o fluxo do processo.

Analisar a sequência, a frequência e o tempo entre as atividades é a base do Process Mining. Isso permite descobrir modelos de processo, identificar gargalos, detectar ciclos de retrabalho e analisar desvios do processo.

Por que isso importa

Define as etapas do processo, permitindo visualizar mapas de processo e analisar o fluxo e os gargalos.

Onde encontrar

Normalmente, esse dado é obtido de tabelas de eventos ou registros de auditoria no ClaimCenter, mapeando eventos específicos do sistema ou mudanças de status para nomes padronizados de atividades.

Exemplos
Sinistro criadoDecisão sobre responsabilidade definidaPagamento emitidoSinistro encerrado
Causa da perda
LossCause
O motivo ou a causa específica do evento que gerou a perda, como colisão, incêndio ou dano causado por água.
Descrição

Este atributo fornece detalhes sobre o motivo do registro do sinistro. A causa da perda costuma determinar as etapas necessárias da investigação, o tipo de especialista envolvido e a complexidade geral do sinistro.

Analisar o processo por causa da perda pode revelar padrões ocultos. Por exemplo, sinistros relacionados a danos causados por água podem ter mais retrabalho ou exigir mais especialistas do que sinistros por roubo. Esses insights ajudam a criar procedimentos de tratamento mais especializados e eficientes.

Por que isso importa

Fornece contexto sobre a natureza do sinistro e permite analisar como diferentes causas de perda afetam o fluxo e a duração do processo.

Onde encontrar

É um campo padrão da entidade Claim, geralmente chamado 'LossCause'.

Exemplos
ColisãoIncêndioDano causado por águaRoubo
Regulador responsável
AssignedAdjuster
O nome ou ID da pessoa responsável pelo sinistro ou por uma atividade específica.
Descrição

Este atributo identifica a pessoa reguladora responsável por um sinistro em determinado momento. Ela pode ser responsável pelo sinistro inteiro ou por tarefas específicas.

Analisar os dados por regulador responsável é essencial para equilibrar a carga de trabalho, gerenciar a performance e identificar oportunidades de treinamento. Isso ajuda a responder perguntas como: 'Quais reguladores têm mais sinistros sob sua responsabilidade?', 'Há diferenças de performance entre os reguladores?' e 'O trabalho está distribuído de forma equilibrada?'.

Por que isso importa

Acompanha o envolvimento das pessoas, permitindo analisar a carga de trabalho, comparar a performance e identificar gargalos relacionados a recursos.

Onde encontrar

Disponível na entidade Claim ou Exposure do ClaimCenter, geralmente vinculado ao objeto User, por exemplo, Claim.Assignee.

Exemplos
j.doem.smiths.jones
Status do sinistro
ClaimStatus
O status geral do sinistro no momento do evento, como aberto, encerrado ou negado.
Descrição

Este atributo representa o estado geral do sinistro. Entre os principais status estão 'Aberto', 'Encerrado', 'Negado' e 'Reaberto'. O status final do sinistro é uma métrica de resultado essencial.

Acompanhar as mudanças no status do sinistro ajuda a definir marcos e resultados importantes do processo. Esse dado é usado para identificar a resolução final, calcular taxas de rejeição e analisar a frequência com que sinistros são reabertos após o encerramento, o que muitas vezes indica problemas no processo ou insatisfação do cliente.

Por que isso importa

Indica o resultado do sinistro e é essencial para analisar taxas de rejeição, padrões de encerramento e frequência de reabertura.

Onde encontrar

É um campo central da entidade Claim, geralmente chamado 'State' ou 'Status'.

Exemplos
AbertoEncerradoNegadoReaberto
Tipo de sinistro
ClaimType
A categoria do sinistro de seguro, como automóvel, patrimonial ou responsabilidade civil.
Descrição

O tipo de sinistro é uma classificação fundamental, baseada na linha de negócio ou na natureza da perda. Cada tipo pode seguir um processo diferente, ter um nível de complexidade próprio e estar sujeito a regulamentações específicas.

Segmentar a análise do processo por tipo de sinistro é essencial para obter insights relevantes. Isso permite comparar a performance entre linhas de negócio, identificar gargalos específicos de cada tipo e adaptar as iniciativas de melhoria às características de cada categoria de sinistro.

Por que isso importa

Permite segmentar os sinistros, já que tipos diferentes, como automóvel e patrimonial, costumam seguir processos distintos e ter metas de performance diferentes.

Onde encontrar

Derivado da entidade Policy ou Claim no ClaimCenter, geralmente com base no código da linha de negócio (LOB).

Exemplos
Automóvel de passeioImóvel comercialResponsabilidade civil geralAcidentes de trabalho
Data da ocorrência
LossDate
A data em que ocorreu o incidente ou a perda que deu origem ao sinistro.
Descrição

A data da ocorrência é a data do evento em si, como um acidente de carro ou um dano ao imóvel, que deu origem ao sinistro. Ela é diferente da data em que o sinistro foi comunicado ou criado.

O intervalo entre a data da ocorrência e a atividade 'Sinistro criado', conhecido como atraso na comunicação, é um KPI importante. Analisá-lo pode revelar insights sobre o comportamento dos clientes e a eficácia dos canais de comunicação inicial do sinistro.

Por que isso importa

Fornece contexto essencial sobre a origem do sinistro e ajuda a analisar o atraso na comunicação, ou seja, o tempo entre o incidente e o registro do sinistro.

Onde encontrar

É um campo de data fundamental da entidade Claim, geralmente chamado 'LossDate'.

Exemplos
2023-05-102023-04-202023-05-28
Data prevista para resolução
ResolutionTargetDate
A data em que se espera que o sinistro seja resolvido, de acordo com os SLAs internos ou regulatórios.
Descrição

A data prevista para resolução é o prazo definido para encerrar o sinistro, muitas vezes determinado por fatores como jurisdição, tipo de sinistro e condições da apólice. Ela serve como referência para medir a performance e a conformidade.

Este atributo é essencial para criar Dashboards e KPIs de cumprimento de SLA. Ao comparar a data real da atividade 'Sinistro encerrado' com a data prevista, a análise pode sinalizar automaticamente os sinistros atrasados, medir a taxa de cumprimento do prazo e identificar os tipos de sinistro ou departamentos com dificuldade para atingir as metas.

Por que isso importa

É a referência para medir o cumprimento do Acordo de Nível de Serviço (SLA) e identificar sinistros com risco de atraso.

Onde encontrar

Pode ser um campo personalizado ou derivado de regras de negócio configuradas no ClaimCenter, possivelmente relacionadas a métricas específicas de sinistros.

Exemplos
2023-06-142023-07-202023-08-28
Departamento
Department
A unidade de negócio ou o departamento responsável por tratar a atividade do sinistro.
Descrição

Este atributo indica o departamento ou time ao qual o regulador responsável pertence, como 'Sinistros de automóveis', 'Sinistros patrimoniais' ou 'Unidade de investigações especiais'. Ele fornece contexto organizacional para o processo.

Analisar os dados por departamento é essencial para entender a performance do processo em toda a organização. Isso ajuda a identificar atrasos nas transferências entre departamentos, comparar a eficiência dos times e alocar recursos de forma mais eficaz na área de sinistros.

Por que isso importa

Fornece contexto organizacional, permitindo analisar a performance de diferentes times e identificar problemas nas transferências entre departamentos.

Onde encontrar

Normalmente, essas informações estão associadas ao perfil do usuário ou grupo responsável no ClaimCenter.

Exemplos
Divisão de sinistros de automóveisUnidade de sinistros patrimoniaisUnidade de investigações especiais (SIU)
É automatizado
IsAutomated
Indicador que informa se uma atividade foi realizada automaticamente pelo sistema ou por uma pessoa.
Descrição

Este atributo booleano diferencia as atividades executadas pelo sistema, como a criação automática de reservas ou o envio de correspondências geradas pelo sistema, daquelas realizadas manualmente por um regulador.

Analisar este atributo é essencial para entender o nível de automação do processo de sinistros. Isso ajuda a identificar pontos com muita intervenção manual, medir a eficácia das iniciativas de processamento direto e encontrar novas oportunidades de automação, identificando tarefas repetitivas e baseadas em regras que ainda são realizadas por pessoas.

Por que isso importa

Diferencia as atividades realizadas pelo sistema daquelas realizadas por pessoas, algo essencial para analisar a automação e identificar gargalos manuais.

Onde encontrar

Muitas vezes, esse dado precisa ser derivado. Por exemplo, eventos registrados por um usuário genérico do sistema podem ser sinalizados como automatizados.

Exemplos
truefalse
É retrabalho
IsRework
Indicador que informa se uma atividade faz parte de um ciclo de retrabalho, ou seja, se representa o retorno a uma etapa anterior do processo.
Descrição

Este atributo calculado sinaliza as atividades que fazem parte de um ciclo de retrabalho. Por exemplo, se o processo passa de 'Investigação concluída' para 'Investigação iniciada', a segunda atividade 'Investigação iniciada' será sinalizada como retrabalho.

Identificar retrabalho é fundamental para revelar ineficiências do processo e problemas de qualidade. O Dashboard de frequência de retrabalho e rejeição usa esta métrica para quantificar com que frequência os sinistros se desviam do 'caminho ideal'. Analisar as causas do retrabalho pode melhorar significativamente a qualidade e a velocidade do processo.

Por que isso importa

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

Onde encontrar

É calculado na ferramenta de Process Mining por meio da análise da sequência de atividades de cada caso.

Exemplos
truefalse
Estado da jurisdição
JurisdictionState
O estado ou a jurisdição que rege o sinistro e determina os requisitos regulatórios.
Descrição

Este atributo especifica a jurisdição legal, como o estado dos US, sob a qual o sinistro está sendo tratado. As regulamentações de seguros podem variar bastante entre jurisdições e afetar as etapas exigidas do processo, os prazos de comunicação e a documentação.

Este atributo é essencial para monitorar a conformidade. Analisar o processo por jurisdição ajuda a verificar se os requisitos regulatórios específicos de cada estado estão sendo cumpridos. Também pode explicar variações nos tempos de ciclo ou nos caminhos do processo causadas por exigências legais, e não por ineficiências operacionais.

Por que isso importa

Essencial para a análise de conformidade, pois as regulamentações variam entre jurisdições e afetam o processo de sinistros.

Onde encontrar

Campo padrão da entidade Claim, geralmente chamado 'JurisdictionState'.

Exemplos
CANYTXFL
Horário de término
EndTime
O registro de data e hora que indica quando uma atividade foi concluída.
Descrição

O horário de término marca a conclusão de uma atividade, especialmente de tarefas com duração mensurável, como 'Investigação' ou 'Análise de documentos'. Muitas atividades analisadas com Process Mining são instantâneas, e o horário de início é suficiente. Já as atividades com início e fim definidos são representadas com mais precisão usando os dois registros de data e hora.

Este atributo permite calcular com precisão o tempo de processamento da atividade, separado do tempo de espera. Assim, você identifica quais tarefas específicas consomem mais tempo, em vez de apenas observar longos intervalos entre etapas.

Por que isso importa

Permite medir com precisão quanto tempo uma atividade leva para ser concluída, separando o tempo de processamento do tempo de espera.

Onde encontrar

Talvez seja necessário derivar esse dado identificando um evento posterior que conclua logicamente a atividade, como uma 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 de onde os dados foram extraídos.
Descrição

Este atributo identifica a origem dos dados do evento. Em um ambiente corporativo moderno, os eventos relacionados a sinistros podem vir de vários sistemas, como um sistema central, por exemplo, o Guidewire, um sistema de gestão de documentos ou um portal do cliente.

Especificar o sistema de origem é essencial para a governança de dados, a investigação de inconsistências e a compreensão do ambiente tecnológico do processo. Isso ajuda a diferenciar as etapas centrais do processo das atividades de apoio realizadas em sistemas periféricos.

Por que isso importa

Identifica a origem dos dados, essencial para a governança de dados e para análises que envolvem vários sistemas integrados.

Onde encontrar

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

Exemplos
Guidewire ClaimCenter v10API do portal do clienteDocumentum
Solicitação repetida de informações
RepeatedInfoRequestFlag
Indicador que informa se a atividade 'Informações adicionais solicitadas' ocorreu mais de uma vez para o mesmo sinistro.
Descrição

Este indicador booleano recebe o valor verdadeiro quando há mais de uma atividade 'Informações adicionais solicitadas' para um sinistro. Isso costuma apontar ineficiências na etapa inicial de coleta de informações.

Este atributo dá suporte direto ao KPI de taxa de solicitações repetidas de informações. Ele ajuda a quantificar o problema de uma apuração inicial incompleta, que pode causar atrasos significativos e frustração para o cliente. Analisar os sinistros sinalizados pode ajudar a melhorar os checklists e os procedimentos dos reguladores, garantindo que todas as informações necessárias sejam solicitadas de uma só vez.

Por que isso importa

Identifica ineficiências na coleta inicial de informações, quando ela não é completa e gera atrasos e retrabalho.

Onde encontrar

Calculado na ferramenta de Process Mining pela contagem das ocorrências da atividade 'Informações adicionais solicitadas' em cada caso.

Exemplos
truefalse
Status do SLA
SLAState
Indica se o sinistro foi encerrado até a data prevista para resolução.
Descrição

Este atributo calculado informa, por categoria, se cada sinistro encerrado cumpriu o SLA. Ele é derivado da comparação entre a data e a hora da atividade 'Sinistro encerrado' e a data prevista para resolução.

Este atributo dá suporte direto ao Dashboard de cumprimento da data prevista para resolução do sinistro, simplificando a análise em categorias claras, como 'No prazo' ou 'Atrasado'. Ele facilita a filtragem e a agregação dos dados para calcular a taxa geral de cumprimento do SLA e aprofundar a análise das causas dos atrasos.

Por que isso importa

Apresenta o resultado do cumprimento do SLA em categorias claras, facilitando a filtragem, a agregação e a análise da performance dentro do prazo.

Onde encontrar

Campo calculado: IF (ActualCloseDate <= ResolutionTargetDate, 'No prazo', 'Atrasado').

Exemplos
No prazoAtrasado
Tipo de apólice
PolicyType
O tipo específico de apólice de seguro em que o sinistro foi registrado.
Descrição

O tipo de apólice oferece uma classificação mais detalhada do que o tipo de sinistro, especificando o produto de seguro, como 'Residencial', 'Automóvel comercial' ou 'Responsabilidade cibernética'. Esse nível de detalhe pode revelar variações no processo relacionadas a produtos específicos.

Analisar o processo por tipo de apólice ajuda a identificar ineficiências específicas de cada produto. Por exemplo, sinistros de uma apólice recém-lançada podem seguir um processo menos maduro e sofrer atrasos. Essa análise pode orientar o desenvolvimento de produtos e a padronização de processos.

Por que isso importa

Permite analisar o processo de produtos de seguro específicos e identificar variações no tratamento de acordo com as características da apólice.

Onde encontrar

Essa informação está na entidade Policy, vinculada à entidade Claim.

Exemplos
Seguro residencial multirriscosResponsabilidade civil de automóveis comerciaisSeguro de transporte marítimo e terrestre
Última atualização dos dados
LastDataUpdate
O registro de data e hora que indica quando os dados foram atualizados ou extraídos pela última vez do sistema de origem.
Descrição

Este atributo informa a data e a hora da extração mais recente de dados do sistema de origem. É um campo de metadados essencial para entender o nível de atualização da análise.

Os Dashboards e as análises devem exibir essa informação em destaque para que as pessoas saibam o quanto os dados são atuais. Isso ajuda a avaliar se os insights refletem o estado atual das operações ou se têm como base dados mais antigos.

Por que isso importa

Indica o nível de atualização dos dados e ajuda as pessoas a entenderem o quanto a análise do processo é atual.

Onde encontrar

Esse valor é gerado e armazenado durante o processo de ETL e representa a data e a hora do carregamento dos dados.

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

Este atributo registra o valor de cada pagamento feito para um sinistro. Um único sinistro pode ter vários pagamentos ao longo do seu ciclo de vida.

Esse dado é essencial para a análise financeira no contexto do Process Mining. Ele pode ser usado para acompanhar o total pago por sinistro, analisar o tempo de aprovação dos pagamentos de acordo com o valor e relacionar ineficiências do processo a resultados financeiros. Por exemplo, sinistros com ciclos mais longos podem estar associados a pagamentos totais maiores.

Por que isso importa

Acompanha as transações financeiras de um sinistro e permite analisar os valores pagos e sua relação com as atividades do processo.

Onde encontrar

Encontrado em entidades relacionadas a pagamentos e vinculadas ao sinistro, geralmente em uma tabela de transações ou cheques.

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

Este atributo representa o valor da perda informado por quem registrou o sinistro. Muitas vezes, é uma estimativa inicial que pode mudar durante a investigação e a definição das reservas.

Analisar o valor solicitado ajuda a segmentar os sinistros pelo impacto financeiro. Sinistros de alto valor costumam seguir um processo mais rigoroso e complexo do que os de baixo valor. Comparar o processo entre diferentes faixas de valor pode revelar oportunidades para simplificar o tratamento de sinistros menores ou aplicar controles mais rigorosos aos de maior valor.

Por que isso importa

Permite segmentar os sinistros por valor financeiro, já que os de alto valor podem seguir processos diferentes e mais complexos.

Onde encontrar

Essa informação talvez não esteja em um único campo e pode ser derivada das estimativas iniciais de perda registradas nas exposições.

Exemplos
5000.00150000.00750.50
Obrigatório Recomendado Opcional

Atividades do processamento de sinistros

Estes são os principais passos do processo e marcos importantes que você deve registrar no Event Log para descobrir e analisar o processo de sinistros com precisão.
7 Recomendado 7 Opcional
Atividade Descrição
Exposição criada
Esta atividade indica a criação de uma exposição, que representa uma responsabilidade potencial específica ou um tipo de perda relacionado ao sinistro (por exemplo, danos ao veículo ou lesão). No Guidewire, este é um evento explícito.
Por que isso importa

As exposições são fundamentais para segmentar e analisar os sinistros. Acompanhar sua criação ajuda a entender as variações do processo conforme a complexidade do sinistro e o tipo de perda.

Onde encontrar

Registrado a partir de CreateTime de um novo registro na tabela cc_exposure. Cada registro está vinculado a um único ID do sinistro.

Coleta

Identifique a data e hora de criação de um novo registro na tabela da entidade Exposure.

Tipo de evento explicit
Pagamento aprovado
Representa a aprovação formal de um pagamento de liquidação. Este é um evento crítico para auditoria, registrado explicitamente quando um usuário autorizado aprova a transação.
Por que isso importa

Este marco importante libera a etapa final do pagamento. Analisar o tempo antes e depois desta atividade ajuda a isolar atrasos causados pelo fluxo de aprovação ou pela disponibilidade dos gestores.

Onde encontrar

Em geral, este é um evento explícito registrado na tabela cc_history, relacionado a uma entidade cc_check ou cc_transaction, que registra a alteração de status de 'Aguardando aprovação' para 'Aprovado'.

Coleta

Acompanhe a alteração de status para 'Aprovado' de uma transação de pagamento específica.

Tipo de evento explicit
Pagamento emitido
Esta atividade marca a etapa final do processo de pagamento, quando o pagamento é oficialmente emitido e enviado ao sistema financeiro. Trata-se de uma transação financeira explícita e registrada.
Por que isso importa

Esta atividade é essencial para medir a eficiência do envio de pagamentos. Ela ajuda a diferenciar atrasos na aprovação de atrasos na emissão efetiva dos valores.

Onde encontrar

Registrado a partir de IssueDate ou de uma alteração de status para 'Emitido' ou 'Enviado' na entidade cc_check ou cc_transaction. Em geral, este é um evento explícito com data e hora registradas.

Coleta

Identifique IssueDate ou a data e hora da alteração de status para 'Emitido' no registro do 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, registrado explicitamente.
Por que isso importa

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

Onde encontrar

Este evento é registrado quando o primeiro registro cc_reserveline associado a uma exposição do sinistro é criado. CreateTime da transação indica a data e hora do evento.

Coleta

Encontre a data e hora de criação mais antiga entre todas as linhas de reserva das 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 registro de sinistro no Guidewire ClaimCenter. O evento é registrado explicitamente quando uma nova entidade Claim é salva no banco de dados pela primeira vez.
Por que isso importa

Como principal evento de início, esta atividade é essencial para medir o tempo de ciclo do sinistro de ponta a ponta. Ela serve de referência para todos os KPIs subsequentes de performance e duração.

Onde encontrar

Este é um evento explícito, registrado a partir de CreateTime na tabela cc_claim. A criação de um novo registro com um ID do sinistro exclusivo aciona o evento.

Coleta

Identifique a data e hora de criação do novo registro na tabela da entidade Claim principal.

Tipo de evento explicit
Sinistro encerrado
Marca o encerramento bem-sucedido de um sinistro, após a conclusão de todas as atividades e pagamentos. Este é o principal evento de encerramento bem-sucedido, inferido por uma alteração no status principal do sinistro.
Por que isso importa

Como principal evento de encerramento, esta atividade é essencial para calcular o tempo de ciclo de ponta a ponta e medir o cumprimento dos SLAs. Ela indica a conclusão do ciclo de vida do sinistro.

Onde encontrar

Inferido quando o campo State da tabela cc_claim muda para 'Closed'. A data e hora do evento são indicadas por CloseDate no registro do sinistro.

Coleta

Identifique quando o campo de status principal do sinistro é atualizado para 'Closed'.

Tipo de evento inferred
Sinistro negado
Representa a decisão final de negar um sinistro e marca o encerramento do processo. O evento é inferido quando o status do sinistro muda para encerrado com o motivo 'Negado'.
Por que isso importa

Este é um evento de resultado crítico. Analisar a frequência, os motivos e os caminhos do processo que levam às negativas ajuda a identificar problemas na abertura do sinistro, na investigação ou na interpretação da apólice.

Onde encontrar

Inferido quando o campo State da tabela cc_claim muda para 'Closed' e o campo CloseReason é 'Denied' ou tem um valor semelhante. A data e hora do evento são indicadas por CloseDate.

Coleta

Filtre as alterações de status do sinistro para 'Closed' cujo código de motivo indique uma negativa.

Tipo de evento inferred
Decisão sobre responsabilidade definida
Indica o momento em que a responsabilidade ou culpa por uma exposição é determinada. Em geral, o evento é inferido por uma alteração de status na entidade Exposure.
Por que isso importa

Este marco decisório é crítico, pois libera as etapas de liquidação e pagamento. Analisar o tempo até essa decisão ajuda a identificar gargalos nas etapas de investigação e avaliação.

Onde encontrar

Inferido da tabela cc_history, acompanhando uma alteração em State ou em um campo personalizado de status de responsabilidade na entidade cc_exposure. A data e hora do registro de histórico indicam quando o evento ocorreu.

Coleta

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

Tipo de evento inferred
Informações adicionais recebidas
Marca a conclusão de uma solicitação de informações adicionais. O evento é registrado quando a Activity (tarefa) correspondente à solicitação de informações é marcada como 'Concluída'.
Por que isso importa

Este é o ponto final do KPI 'Tempo de ciclo da coleta de informações adicionais'. O longo intervalo entre a solicitação e o recebimento é uma causa comum de atraso no processo de sinistros.

Onde encontrar

Registrado a partir de CloseTime de um registro cc_activity cujo ActivityPattern está relacionado a uma solicitação de informações. O status da atividade deve ser 'Concluída'.

Coleta

Identifique a data e hora de conclusão de uma tarefa de solicitação de informações externas.

Tipo de evento explicit
Informações adicionais solicitadas
Representa uma solicitação enviada ao solicitante do sinistro ou a terceiros para obter mais informações ou documentos. Em geral, o evento é registrado como uma Activity (tarefa) criada explicitamente no ClaimCenter.
Por que isso importa

Esta atividade marca o início da medição do KPI 'Tempo de ciclo da coleta de informações adicionais'. Ocorrências frequentes podem indicar problemas no processo de FNOL ou ineficiência na coleta de informações.

Onde encontrar

Registrado a partir de CreateTime de um registro cc_activity cujo ActivityPattern está relacionado à solicitação de documentos ou informações a uma parte externa.

Coleta

Identifique a criação de uma tarefa para solicitar informações externas.

Tipo de evento explicit
Investigação iniciada
Indica o início formal da fase de investigação de um sinistro ou exposição. Muitas vezes, o evento é inferido pela criação da primeira Activity (tarefa) relacionada à investigação no Guidewire.
Por que isso importa

Esta atividade marca o início de uma fase importante, que costuma ser longa. Analisar o tempo até o início da investigação e a duração da própria investigação ajuda a revelar gargalos importantes.

Onde encontrar

Inferido a partir de CreateTime de um registro cc_activity cujo ActivityPattern está relacionado à investigação (por exemplo, 'Investigação inicial', 'Contatar testemunha').

Coleta

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

Tipo de evento inferred
Sinistro atribuído
Representa a atribuição de um sinistro a um usuário específico (regulador) ou grupo responsável pelo tratamento. Em geral, o evento é inferido pelo monitoramento de alterações nos campos de atribuição da entidade Claim.
Por que isso importa

Acompanhar as atribuições é essencial para analisar a carga de trabalho dos reguladores, identificar gargalos no encaminhamento e medir o tempo até a primeira ação do responsável pelo caso.

Onde encontrar

Inferido da tabela cc_history, acompanhando alterações nos campos AssignedUser ou AssignedGroup associados a um ID do sinistro específico. A data e hora da alteração indicam quando o evento ocorreu.

Coleta

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

Tipo de evento inferred
Sinistro reaberto
Representa a mudança do status de um sinistro de 'Closed' para 'Open' para que sejam realizados trabalhos adicionais. O evento é inferido a partir de uma sequência específica de alterações de status.
Por que isso importa

Esta atividade indica retrabalho. Um grande volume de sinistros reabertos pode apontar problemas na liquidação inicial, danos não identificados ou outras falhas no processo, aumentando os custos e reduzindo a eficiência.

Onde encontrar

Inferido da tabela cc_history, identificando uma alteração no campo State da entidade cc_claim de 'Closed' para 'Open' ou outro status ativo.

Coleta

Monitore o campo de status principal do sinistro para identificar uma transição de encerrado para aberto.

Tipo de evento inferred
Valor da liquidação calculado
Esta atividade representa o momento em que o valor da liquidação é definido, mas ainda não foi aprovado para pagamento. O evento pode ser inferido pela criação de um pagamento com status 'Aguardando aprovação'.
Por que isso importa

Marca a transição da avaliação para o pagamento. É o ponto de partida para medir o KPI 'Tempo de autorização do pagamento' e revelar atrasos na cadeia de aprovação.

Onde encontrar

Inferido a partir de CreateTime de um registro cc_check ou cc_transaction cujo status inicial seja 'Aguardando aprovação' ou um status semelhante anterior a 'Aprovado'.

Coleta

Identifique a criação de um registro de pagamento ou transação com status anterior à aprovação.

Tipo de evento inferred
Recomendado Opcional

Guias de extração

Como extrair seus dados do Guidewire ClaimCenter

Pronto para começar?

Use este Template para preparar seus dados para análise e descobrir insights sobre o processamento de sinistros. Comece a otimizar seus fluxos de trabalho hoje.

Agilize o processamento de sinistros e resolva casos mais rápido

Reduza o acúmulo de casos, previna fraudes e busque atingir 70% de processamento direto, sem intervenção manual.

Começar o teste grátis

Não é necessário informar cartão de crédito. A configuração leva apenas alguns minutos.