Template de Dados: Processamento de Sinistros
Seu Modelo de Dados de Processamento de Sinistros
- Atributos recomendados para coletar
- Atividades-chave para monitorar
- Orientação de Extração para Guidewire ClaimCenter
Atributos de Processamento de Sinistros
| Nome | Descriçã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 | |||
Atividades de Processamento de Sinistros
| Atividade | Descriçã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 | |||
Guias de Extração
Etapas
- Verificação de Pré-requisitos: Confirme se você possui as permissões e credenciais necessárias para acessar o banco de dados do data mart Guidewire DataHub / InfoCenter com privilégios de leitura. Certifique-se de que os jobs de ETL que populam o data mart de sinistros estão sendo executados com sucesso e que os dados estão atualizados.
- Conexão com o Banco de Dados: Utilize um cliente SQL padrão (como DBeaver, SQL Server Management Studio ou ferramentas similares) para estabelecer uma conexão com o servidor de banco de dados do data mart.
- Exploração do Esquema: Antes de executar a consulta completa, familiarize-se com o esquema do data mart. Identifique as tabelas primárias de sinistros, exposições, atividades e transações financeiras. As tabelas-chave geralmente possuem sufixos como _dim (dimensão) e _fact (fato). Isso ajudará a validar os nomes de tabelas e colunas de placeholder no script fornecido.
- Preparar a Consulta SQL: Copie o script SQL completo fornecido na seção query para o editor de consultas do seu cliente SQL.
- Personalizar Placeholders: Revise cuidadosamente o script e substitua todos os valores de placeholder. Isso inclui o nome do banco de dados/esquema (ex.: [YourDataMart]), parâmetros de intervalo de datas ('[StartDate]', '[EndDate]') e quaisquer valores de configuração específicos do sistema (ex.: padrões de atividade, códigos de status).
- Execução da Consulta: Execute a consulta SQL modificada contra o data mart. O tempo de execução pode variar dependendo do intervalo de datas selecionado e do volume de dados em seu sistema.
- Revisão Inicial dos Dados: Após a conclusão da consulta, inspecione as primeiras centenas de linhas do conjunto de resultados. Verifique se as colunas ClaimID, ActivityName e EventTime estão preenchidas conforme o esperado e se diferentes tipos de atividade estão presentes.
- Exportar para CSV: Exporte o conjunto de resultados completo do seu cliente SQL para um arquivo CSV. Nomeie o arquivo de forma descritiva, por exemplo, guidewire_claimcenter_event_log.csv.
- Formatar para o ProcessMind: Certifique-se de que o arquivo CSV esteja salvo com codificação UTF-8. Verifique se o arquivo possui uma linha de cabeçalho que corresponde aos apelidos das colunas na consulta SQL. O arquivo está agora pronto para ser carregado no ProcessMind.
Configuração
- Fonte de Dados: Guidewire DataHub/InfoCenter Claims Data Mart. Este é um banco de dados dimensional pré-agregado, projetado para relatórios e análises, e separado do banco de dados de produção ativo do ClaimCenter.
- Autorizações Necessárias: Acesso somente leitura ao banco de dados SQL que hospeda o data mart. Você precisará de um nome de usuário, senha e detalhes de conexão (endereço do servidor, nome do banco de dados).
- Status do Job ETL: A precisão desta extração depende da execução bem-sucedida e pontual dos jobs ETL do Guidewire que populam o data mart. Verifique o horário da última execução bem-sucedida para entender a atualidade dos dados.
- Filtragem por Intervalo de Datas: A query fornecida inclui cláusulas WHERE com os placeholders '[StartDate]' e '[EndDate]'. Recomenda-se começar com um intervalo de datas limitado (por exemplo, 3 a 6 meses) para gerenciar o desempenho. O filtro de data é aplicado no CreateTime do sinistro.
- Valores Específicos da Configuração: O Guidewire é altamente configurável. Você deve ajustar os valores nas cláusulas WHERE para corresponder à configuração da sua organização. Isso inclui:
- Nomes de ActivityPattern (por exemplo, 'fnol', 'investigation', 'Request additional information')
- Códigos de ClaimStatus, ExposureStatus e CloseReason (por exemplo, 'denied', 'closed')
- Códigos de TransactionStatus (por exemplo, 'pendingapproval', 'approved', 'issued')
- Desempenho: Consultar grandes tabelas de histórico ou de auditoria pode consumir muitos recursos. Recomenda-se executar a query durante as horas de menor movimento para conjuntos de dados muito grandes. Certifique-se de que as colunas ClaimID ou ClaimNumber estejam indexadas nas tabelas relevantes.
a Consulta de Exemplo sql
`sql
-- This query extracts a process mining event log for claims processing from a Guidewire DataHub/InfoCenter Data Mart.
-- Replace placeholders: [YourDataMart], [StartDate], [EndDate], and any configuration-specific string literals.
WITH ClaimHistory AS (
-- Pre-process claim history to identify status changes, especially for Reopened events.
SELECT
ClaimID,
Status,
UpdateTime,
LAG(Status, 1) OVER (PARTITION BY ClaimID ORDER BY UpdateTime) AS PreviousStatus
FROM [YourDataMart].[dbo].[ClaimHistory_dim] -- Placeholder for claim history/audit table
),
BaseClaims AS (
-- Select the set of claims to be analyzed based on a date range.
SELECT
c.ClaimID AS ClaimPublicID, -- Using PublicID as it's often the user-facing ID
c.ClaimNumber AS ClaimID,
c.AssignedAdjusterName AS AssignedAdjuster,
c.PolicyType AS ClaimType,
c.ClaimStatus AS ClaimStatus,
c.LossCause AS LossCause,
c.CreateTime
FROM [YourDataMart].[dbo].[Claim_dim] c
WHERE c.CreateTime >= '[StartDate]' AND c.CreateTime < '[EndDate]'
)
-- 1. Claim Created
SELECT
bc.ClaimID AS ClaimID,
'Claim Created' AS ActivityName,
bc.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
UNION ALL
-- 2. Claim Assigned
-- This captures the first assignment event from the history table.
SELECT
bc.ClaimID,
'Claim Assigned' AS ActivityName,
MIN(ch.UpdateTime) AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ClaimHistory_dim] ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.EventType = 'Assignment' -- Assumes an EventType column exists to identify assignment changes
GROUP BY bc.ClaimID, bc.AssignedAdjuster, bc.ClaimType, bc.ClaimStatus, bc.LossCause
UNION ALL
-- 3. Exposure Created
SELECT
bc.ClaimID,
'Exposure Created' AS ActivityName,
e.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Exposure_dim] e ON bc.ClaimPublicID = e.ClaimID
UNION ALL
-- 4. Initial Reserve Set
-- Finds the very first reserve transaction for any exposure on the claim.
SELECT
x.ClaimID,
'Initial Reserve Set' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY t.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Reserve'
) x
WHERE x.rn = 1
UNION ALL
-- 5. Investigation Started
-- Finds the creation of the first investigation-related activity.
SELECT
x.ClaimID,
'Investigation Started' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY a.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Investigation%'
) x
WHERE x.rn = 1
UNION ALL
-- 6. Additional Info Requested
SELECT
bc.ClaimID,
'Additional Info Requested' AS ActivityName,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%'
UNION ALL
-- 7. Additional Info Received
SELECT
bc.ClaimID,
'Additional Info Received' AS ActivityName,
a.CompletionTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%' AND a.CompletionTime IS NOT NULL
UNION ALL
-- 8. Liability Decision Made
-- Captures when an exposure's liability decision is first set.
SELECT
x.ClaimID,
'Liability Decision Made' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
eh.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY eh.UpdateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ExposureHistory_dim] eh ON bc.ClaimPublicID = eh.ClaimID
WHERE eh.LiabilityDecision IS NOT NULL AND eh.PreviousLiabilityDecision IS NULL -- Captures the first time it was set
) x
WHERE x.rn = 1
UNION ALL
-- 9. Settlement Calculated
-- Captures the creation of a payment transaction that is pending approval.
SELECT
bc.ClaimID,
'Settlement Calculated' AS ActivityName,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.TransactionStatus = 'PendingApproval'
UNION ALL
-- 10. Payment Approved
SELECT
bc.ClaimID,
'Payment Approved' AS ActivityName,
t.ApprovalDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.ApprovalDate IS NOT NULL AND t.TransactionStatus = 'Approved'
UNION ALL
-- 11. Payment Issued
SELECT
bc.ClaimID,
'Payment Issued' AS ActivityName,
t.IssueDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.IssueDate IS NOT NULL AND t.TransactionStatus = 'Issued'
UNION ALL
-- 12. Claim Denied
SELECT
bc.ClaimID,
'Claim Denied' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Denied' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 13. Claim Closed
SELECT
bc.ClaimID,
'Claim Closed' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Closed' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND NOT EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 14. Claim Reopened
SELECT
bc.ClaimID,
'Claim Reopened' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Open' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.PreviousStatus = 'Closed' AND ch.Status <> 'Closed';
`Etapas
- Verificação de Pré-requisitos: Confirme se você possui as permissões e credenciais necessárias para acessar o banco de dados do data mart Guidewire DataHub / InfoCenter com privilégios de leitura. Certifique-se de que os jobs de ETL que populam o data mart de sinistros estão sendo executados com sucesso e que os dados estão atualizados.
- Conexão com o Banco de Dados: Utilize um cliente SQL padrão (como DBeaver, SQL Server Management Studio ou ferramentas similares) para estabelecer uma conexão com o servidor de banco de dados do data mart.
- Exploração do Esquema: Antes de executar a consulta completa, familiarize-se com o esquema do data mart. Identifique as tabelas primárias de sinistros, exposições, atividades e transações financeiras. As tabelas-chave geralmente possuem sufixos como _dim (dimensão) e _fact (fato). Isso ajudará a validar os nomes de tabelas e colunas de placeholder no script fornecido.
- Preparar a Consulta SQL: Copie o script SQL completo fornecido na seção query para o editor de consultas do seu cliente SQL.
- Personalizar Placeholders: Revise cuidadosamente o script e substitua todos os valores de placeholder. Isso inclui o nome do banco de dados/esquema (ex.: [YourDataMart]), parâmetros de intervalo de datas ('[StartDate]', '[EndDate]') e quaisquer valores de configuração específicos do sistema (ex.: padrões de atividade, códigos de status).
- Execução da Consulta: Execute a consulta SQL modificada contra o data mart. O tempo de execução pode variar dependendo do intervalo de datas selecionado e do volume de dados em seu sistema.
- Revisão Inicial dos Dados: Após a conclusão da consulta, inspecione as primeiras centenas de linhas do conjunto de resultados. Verifique se as colunas ClaimID, ActivityName e EventTime estão preenchidas conforme o esperado e se diferentes tipos de atividade estão presentes.
- Exportar para CSV: Exporte o conjunto de resultados completo do seu cliente SQL para um arquivo CSV. Nomeie o arquivo de forma descritiva, por exemplo, guidewire_claimcenter_event_log.csv.
- Formatar para o ProcessMind: Certifique-se de que o arquivo CSV esteja salvo com codificação UTF-8. Verifique se o arquivo possui uma linha de cabeçalho que corresponde aos apelidos das colunas na consulta SQL. O arquivo está agora pronto para ser carregado no ProcessMind.
Configuração
- Fonte de Dados: Guidewire DataHub/InfoCenter Claims Data Mart. Este é um banco de dados dimensional pré-agregado, projetado para relatórios e análises, e separado do banco de dados de produção ativo do ClaimCenter.
- Autorizações Necessárias: Acesso somente leitura ao banco de dados SQL que hospeda o data mart. Você precisará de um nome de usuário, senha e detalhes de conexão (endereço do servidor, nome do banco de dados).
- Status do Job ETL: A precisão desta extração depende da execução bem-sucedida e pontual dos jobs ETL do Guidewire que populam o data mart. Verifique o horário da última execução bem-sucedida para entender a atualidade dos dados.
- Filtragem por Intervalo de Datas: A query fornecida inclui cláusulas WHERE com os placeholders '[StartDate]' e '[EndDate]'. Recomenda-se começar com um intervalo de datas limitado (por exemplo, 3 a 6 meses) para gerenciar o desempenho. O filtro de data é aplicado no CreateTime do sinistro.
- Valores Específicos da Configuração: O Guidewire é altamente configurável. Você deve ajustar os valores nas cláusulas WHERE para corresponder à configuração da sua organização. Isso inclui:
- Nomes de ActivityPattern (por exemplo, 'fnol', 'investigation', 'Request additional information')
- Códigos de ClaimStatus, ExposureStatus e CloseReason (por exemplo, 'denied', 'closed')
- Códigos de TransactionStatus (por exemplo, 'pendingapproval', 'approved', 'issued')
- Desempenho: Consultar grandes tabelas de histórico ou de auditoria pode consumir muitos recursos. Recomenda-se executar a query durante as horas de menor movimento para conjuntos de dados muito grandes. Certifique-se de que as colunas ClaimID ou ClaimNumber estejam indexadas nas tabelas relevantes.
a Consulta de Exemplo sql
`sql
-- This query extracts a process mining event log for claims processing from a Guidewire DataHub/InfoCenter Data Mart.
-- Replace placeholders: [YourDataMart], [StartDate], [EndDate], and any configuration-specific string literals.
WITH ClaimHistory AS (
-- Pre-process claim history to identify status changes, especially for Reopened events.
SELECT
ClaimID,
Status,
UpdateTime,
LAG(Status, 1) OVER (PARTITION BY ClaimID ORDER BY UpdateTime) AS PreviousStatus
FROM [YourDataMart].[dbo].[ClaimHistory_dim] -- Placeholder for claim history/audit table
),
BaseClaims AS (
-- Select the set of claims to be analyzed based on a date range.
SELECT
c.ClaimID AS ClaimPublicID, -- Using PublicID as it's often the user-facing ID
c.ClaimNumber AS ClaimID,
c.AssignedAdjusterName AS AssignedAdjuster,
c.PolicyType AS ClaimType,
c.ClaimStatus AS ClaimStatus,
c.LossCause AS LossCause,
c.CreateTime
FROM [YourDataMart].[dbo].[Claim_dim] c
WHERE c.CreateTime >= '[StartDate]' AND c.CreateTime < '[EndDate]'
)
-- 1. Claim Created
SELECT
bc.ClaimID AS ClaimID,
'Claim Created' AS ActivityName,
bc.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
UNION ALL
-- 2. Claim Assigned
-- This captures the first assignment event from the history table.
SELECT
bc.ClaimID,
'Claim Assigned' AS ActivityName,
MIN(ch.UpdateTime) AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ClaimHistory_dim] ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.EventType = 'Assignment' -- Assumes an EventType column exists to identify assignment changes
GROUP BY bc.ClaimID, bc.AssignedAdjuster, bc.ClaimType, bc.ClaimStatus, bc.LossCause
UNION ALL
-- 3. Exposure Created
SELECT
bc.ClaimID,
'Exposure Created' AS ActivityName,
e.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Exposure_dim] e ON bc.ClaimPublicID = e.ClaimID
UNION ALL
-- 4. Initial Reserve Set
-- Finds the very first reserve transaction for any exposure on the claim.
SELECT
x.ClaimID,
'Initial Reserve Set' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY t.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Reserve'
) x
WHERE x.rn = 1
UNION ALL
-- 5. Investigation Started
-- Finds the creation of the first investigation-related activity.
SELECT
x.ClaimID,
'Investigation Started' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY a.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Investigation%'
) x
WHERE x.rn = 1
UNION ALL
-- 6. Additional Info Requested
SELECT
bc.ClaimID,
'Additional Info Requested' AS ActivityName,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%'
UNION ALL
-- 7. Additional Info Received
SELECT
bc.ClaimID,
'Additional Info Received' AS ActivityName,
a.CompletionTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%' AND a.CompletionTime IS NOT NULL
UNION ALL
-- 8. Liability Decision Made
-- Captures when an exposure's liability decision is first set.
SELECT
x.ClaimID,
'Liability Decision Made' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
eh.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY eh.UpdateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ExposureHistory_dim] eh ON bc.ClaimPublicID = eh.ClaimID
WHERE eh.LiabilityDecision IS NOT NULL AND eh.PreviousLiabilityDecision IS NULL -- Captures the first time it was set
) x
WHERE x.rn = 1
UNION ALL
-- 9. Settlement Calculated
-- Captures the creation of a payment transaction that is pending approval.
SELECT
bc.ClaimID,
'Settlement Calculated' AS ActivityName,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.TransactionStatus = 'PendingApproval'
UNION ALL
-- 10. Payment Approved
SELECT
bc.ClaimID,
'Payment Approved' AS ActivityName,
t.ApprovalDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.ApprovalDate IS NOT NULL AND t.TransactionStatus = 'Approved'
UNION ALL
-- 11. Payment Issued
SELECT
bc.ClaimID,
'Payment Issued' AS ActivityName,
t.IssueDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.IssueDate IS NOT NULL AND t.TransactionStatus = 'Issued'
UNION ALL
-- 12. Claim Denied
SELECT
bc.ClaimID,
'Claim Denied' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Denied' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 13. Claim Closed
SELECT
bc.ClaimID,
'Claim Closed' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Closed' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND NOT EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 14. Claim Reopened
SELECT
bc.ClaimID,
'Claim Reopened' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Open' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.PreviousStatus = 'Closed' AND ch.Status <> 'Closed';
`Etapas
- Verificação de Pré-requisitos: Confirme se você possui as permissões e credenciais necessárias para acessar o banco de dados do data mart Guidewire DataHub / InfoCenter com privilégios de leitura. Certifique-se de que os jobs de ETL que populam o data mart de sinistros estão sendo executados com sucesso e que os dados estão atualizados.
- Conexão com o Banco de Dados: Utilize um cliente SQL padrão (como DBeaver, SQL Server Management Studio ou ferramentas similares) para estabelecer uma conexão com o servidor de banco de dados do data mart.
- Exploração do Esquema: Antes de executar a consulta completa, familiarize-se com o esquema do data mart. Identifique as tabelas primárias de sinistros, exposições, atividades e transações financeiras. As tabelas-chave geralmente possuem sufixos como _dim (dimensão) e _fact (fato). Isso ajudará a validar os nomes de tabelas e colunas de placeholder no script fornecido.
- Preparar a Consulta SQL: Copie o script SQL completo fornecido na seção query para o editor de consultas do seu cliente SQL.
- Personalizar Placeholders: Revise cuidadosamente o script e substitua todos os valores de placeholder. Isso inclui o nome do banco de dados/esquema (ex.: [YourDataMart]), parâmetros de intervalo de datas ('[StartDate]', '[EndDate]') e quaisquer valores de configuração específicos do sistema (ex.: padrões de atividade, códigos de status).
- Execução da Consulta: Execute a consulta SQL modificada contra o data mart. O tempo de execução pode variar dependendo do intervalo de datas selecionado e do volume de dados em seu sistema.
- Revisão Inicial dos Dados: Após a conclusão da consulta, inspecione as primeiras centenas de linhas do conjunto de resultados. Verifique se as colunas ClaimID, ActivityName e EventTime estão preenchidas conforme o esperado e se diferentes tipos de atividade estão presentes.
- Exportar para CSV: Exporte o conjunto de resultados completo do seu cliente SQL para um arquivo CSV. Nomeie o arquivo de forma descritiva, por exemplo, guidewire_claimcenter_event_log.csv.
- Formatar para o ProcessMind: Certifique-se de que o arquivo CSV esteja salvo com codificação UTF-8. Verifique se o arquivo possui uma linha de cabeçalho que corresponde aos apelidos das colunas na consulta SQL. O arquivo está agora pronto para ser carregado no ProcessMind.
Configuração
- Fonte de Dados: Guidewire DataHub/InfoCenter Claims Data Mart. Este é um banco de dados dimensional pré-agregado, projetado para relatórios e análises, e separado do banco de dados de produção ativo do ClaimCenter.
- Autorizações Necessárias: Acesso somente leitura ao banco de dados SQL que hospeda o data mart. Você precisará de um nome de usuário, senha e detalhes de conexão (endereço do servidor, nome do banco de dados).
- Status do Job ETL: A precisão desta extração depende da execução bem-sucedida e pontual dos jobs ETL do Guidewire que populam o data mart. Verifique o horário da última execução bem-sucedida para entender a atualidade dos dados.
- Filtragem por Intervalo de Datas: A query fornecida inclui cláusulas WHERE com os placeholders '[StartDate]' e '[EndDate]'. Recomenda-se começar com um intervalo de datas limitado (por exemplo, 3 a 6 meses) para gerenciar o desempenho. O filtro de data é aplicado no CreateTime do sinistro.
- Valores Específicos da Configuração: O Guidewire é altamente configurável. Você deve ajustar os valores nas cláusulas WHERE para corresponder à configuração da sua organização. Isso inclui:
- Nomes de ActivityPattern (por exemplo, 'fnol', 'investigation', 'Request additional information')
- Códigos de ClaimStatus, ExposureStatus e CloseReason (por exemplo, 'denied', 'closed')
- Códigos de TransactionStatus (por exemplo, 'pendingapproval', 'approved', 'issued')
- Desempenho: Consultar grandes tabelas de histórico ou de auditoria pode consumir muitos recursos. Recomenda-se executar a query durante as horas de menor movimento para conjuntos de dados muito grandes. Certifique-se de que as colunas ClaimID ou ClaimNumber estejam indexadas nas tabelas relevantes.
a Consulta de Exemplo sql
`sql
-- This query extracts a process mining event log for claims processing from a Guidewire DataHub/InfoCenter Data Mart.
-- Replace placeholders: [YourDataMart], [StartDate], [EndDate], and any configuration-specific string literals.
WITH ClaimHistory AS (
-- Pre-process claim history to identify status changes, especially for Reopened events.
SELECT
ClaimID,
Status,
UpdateTime,
LAG(Status, 1) OVER (PARTITION BY ClaimID ORDER BY UpdateTime) AS PreviousStatus
FROM [YourDataMart].[dbo].[ClaimHistory_dim] -- Placeholder for claim history/audit table
),
BaseClaims AS (
-- Select the set of claims to be analyzed based on a date range.
SELECT
c.ClaimID AS ClaimPublicID, -- Using PublicID as it's often the user-facing ID
c.ClaimNumber AS ClaimID,
c.AssignedAdjusterName AS AssignedAdjuster,
c.PolicyType AS ClaimType,
c.ClaimStatus AS ClaimStatus,
c.LossCause AS LossCause,
c.CreateTime
FROM [YourDataMart].[dbo].[Claim_dim] c
WHERE c.CreateTime >= '[StartDate]' AND c.CreateTime < '[EndDate]'
)
-- 1. Claim Created
SELECT
bc.ClaimID AS ClaimID,
'Claim Created' AS ActivityName,
bc.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
UNION ALL
-- 2. Claim Assigned
-- This captures the first assignment event from the history table.
SELECT
bc.ClaimID,
'Claim Assigned' AS ActivityName,
MIN(ch.UpdateTime) AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ClaimHistory_dim] ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.EventType = 'Assignment' -- Assumes an EventType column exists to identify assignment changes
GROUP BY bc.ClaimID, bc.AssignedAdjuster, bc.ClaimType, bc.ClaimStatus, bc.LossCause
UNION ALL
-- 3. Exposure Created
SELECT
bc.ClaimID,
'Exposure Created' AS ActivityName,
e.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Exposure_dim] e ON bc.ClaimPublicID = e.ClaimID
UNION ALL
-- 4. Initial Reserve Set
-- Finds the very first reserve transaction for any exposure on the claim.
SELECT
x.ClaimID,
'Initial Reserve Set' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY t.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Reserve'
) x
WHERE x.rn = 1
UNION ALL
-- 5. Investigation Started
-- Finds the creation of the first investigation-related activity.
SELECT
x.ClaimID,
'Investigation Started' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY a.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Investigation%'
) x
WHERE x.rn = 1
UNION ALL
-- 6. Additional Info Requested
SELECT
bc.ClaimID,
'Additional Info Requested' AS ActivityName,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%'
UNION ALL
-- 7. Additional Info Received
SELECT
bc.ClaimID,
'Additional Info Received' AS ActivityName,
a.CompletionTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%' AND a.CompletionTime IS NOT NULL
UNION ALL
-- 8. Liability Decision Made
-- Captures when an exposure's liability decision is first set.
SELECT
x.ClaimID,
'Liability Decision Made' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
eh.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY eh.UpdateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ExposureHistory_dim] eh ON bc.ClaimPublicID = eh.ClaimID
WHERE eh.LiabilityDecision IS NOT NULL AND eh.PreviousLiabilityDecision IS NULL -- Captures the first time it was set
) x
WHERE x.rn = 1
UNION ALL
-- 9. Settlement Calculated
-- Captures the creation of a payment transaction that is pending approval.
SELECT
bc.ClaimID,
'Settlement Calculated' AS ActivityName,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.TransactionStatus = 'PendingApproval'
UNION ALL
-- 10. Payment Approved
SELECT
bc.ClaimID,
'Payment Approved' AS ActivityName,
t.ApprovalDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.ApprovalDate IS NOT NULL AND t.TransactionStatus = 'Approved'
UNION ALL
-- 11. Payment Issued
SELECT
bc.ClaimID,
'Payment Issued' AS ActivityName,
t.IssueDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.IssueDate IS NOT NULL AND t.TransactionStatus = 'Issued'
UNION ALL
-- 12. Claim Denied
SELECT
bc.ClaimID,
'Claim Denied' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Denied' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 13. Claim Closed
SELECT
bc.ClaimID,
'Claim Closed' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Closed' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND NOT EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 14. Claim Reopened
SELECT
bc.ClaimID,
'Claim Reopened' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Open' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.PreviousStatus = 'Closed' AND ch.Status <> 'Closed';
`