Baixar este arquivo PDF - Revista Científica Phronesis

Transcrição

Análise da Eficiência de uma Solução de Business Intelligence
Aplicada a uma Seguradora para Gerar Relatórios Regulatórios
Leandro Mendonça Dias1, Aldo Rovani Santos1, Acácia Castilho 1, Fabio Correa Xavier1
1
Instituto Brasileiro de tecnologia avançada (IBTA) – São Paulo, SP – Brasil
[email protected]; [email protected];
acá[email protected]; [email protected]
Resumo. Soluções de Business Intelligence (BI) e Data Warehouse (DW) já se tornaram
realidade no mercado, inclusive em companhias seguradoras. O objetivo do DW é armazenar
informações oriundas dos diversos sistemas da empresa, em um único local consolidado, para a
extração de informações estratégicas. Supõe-se que, se as principais fontes de dados de
companhia são contempladas, é possível extrair uma grande possibilidade de relatórios,
inclusive os de envio periódico e obrigatório para a Superintendência de Seguros Privados
(SUSEP), órgão regulador das seguradoras no Brasil. O que deve ser observado é se o tipo de
informações que um DW típico deve possuir suporta os dados exigidos pelo órgão. O objetivo
deste artigo é testar se a construção de uma solução de BI pode apoiar uma seguradora a
reportar tais dados. Para isto, deve-se confrontar a estrutura sugerida de um DW com a
natureza das informações regulatórias. Será também analisada uma arquitetura de BI completa,
envolvendo seus componentes, como os repositórios de dados, temporários ou não, e as camadas
de integração e exploração de dados, e será verificado a partir de qual etapa do
desenvolvimento desta arquitetura, ou com quais itens dela, é possível extrair os dados
necessários. Realmente é necessário ter uma fonte única de dados para a extração dos registros
oficiais, sendo exigência de ferramentas do mercado securitário especializadas em gerar dados
para SUSEP. No entanto, se um DW é concebido para armazenar informações consolidadas e
estratégicas, e a fiscalização exige informações estatísticas e transacionais, a camada de
integração de dados torna-se o elemento mais importante da arquitetura. Como esta se encontra
em um momento antes da confecção do próprio DW, um projeto de BI pode ser dividido em duas
etapas distintas: uma para geração dos dados obrigatórios e outra, opcional, para construção de
um DW para tomada de decisões estratégicas.
Palavras-chave: Business intelligence. BI. Data warehouse. DW. Arquitetura de BI. Operational
data store. ODS. Relatórios regulatórios. Circular SUSEP 360. Seguros.
ABSTRACT
Business Intelligence (BI) and Data Warehouse (DW) solutions are a market reality, insurance
companies included. DW aim is store information originated from company’s several data
sources into a unique consolidated spot in order to extract strategic information. It is assumed that
if company’s main data sources are referred to, it is possible to extract a several brand of reports,
including those periodic and/or mandatory submissions to Superintendence of Private Insurance
(SUSEP) that is Brazil’s insurance regulatory agency. What should be noticed is if the type of
information that a typical DW contains supports the data required by the superintendence. This
study’s objective is to assure that a BI solution will be able to support all information required by
inspection on an insurance company. To do that, it is necessary compare DW suggested structure
with inspection information nature. A complete BI architecture will be analyzed also, involving
components such as data repositories, temporary or not, and the layers of integration and data
exploration, and will be checked from each stage of architecture’s development, or with each of
its items, its possibility to extract the required data. It is necessary to have a single data source for
the extraction of official records, being an exigency for specialized tools in security market in
order to generate data to SUSEP. Once DW is designed to store consolidated and strategic
information, and inspection requires statistical and transactional information, the data integration
layer becomes the most important architecture element. As it is located on a point before DW
itself creation a BI project could be divided into two distinct stages: the first one to generate
required data and the second one, optional, to construct a DW for strategic decision-making.
Keywords: Business intelligence. BI. Data warehouse. DW. BI architecture. Operational data
store. ODS. Regulatory reports. Brazil Insurance Regulator’s reports. Insurance.
1. Introdução
O objeto a ser estudado é a aplicabilidade de uma arquitetura recomendada de um ambiente de
BI, conforme Machado (2013, p.37), em uma empresa de seguros, com o objetivo de gerar
relatórios estatísticos e contábeis para a Superintendência de Seguros Privados (SUSEP), que em
seu documento Circular 360 determina a obrigatoriedade de diversas informações.
A arquitetura de BI tem como principal componente o Data Warehouse (DW), e inclui
outros elementos, como o Operational Data Store (ODS), os Data Marts (DM), os Cubos, as
ferramentas de Extração, Transformação e Carga (Extract Transform Load, ETL) e as
ferramentas de On-line Analytical Processing (OLAP). Cada elemento deve ser avaliado se é ou
não fundamental no processo de armazenar as informações necessárias para os relatórios da
SUSEP.
Deve-se também avaliar se as estruturas dos arquivos descritos na Circular 360 são
compatíveis com uma modelagem desejável de dados de DW que, conforme Machado (2013,
p.65), tem características próprias.
Em um estudo de caso, foi solicitada a uma Seguradora a tarefa de automatizar a geração
de relatórios obrigatórios que a SUSEP especifica na Circular 360, onde são descritos os layouts
dos arquivos no formato DBF (dBase Files), de conteúdo estatístico e transacional e com
registros contábeis, bem como seus prazos de entregas, sob pena de multa e impedimento de
venda de seguros pela companhia no caso de inconformidades com a circular.
A empresa possui cerca de 10 sistemas em diversas tecnologias e ambientes variados,
além de controles manuais de planilhas. Tais sistemas e planilhas possuem as mais diversas
Revista Phronesis – Ano I – vol. 2 – Nov/2015 – © Faculdade IBTA
2
funções, como por exemplo, emissão de apólices, gestão de sinistros, contabilidade geral da
companhia etc.
Neste cenário complexo, como existe pouca interligação automática entre os sistemas, e com a
SUSEP exigindo informações que não são alimentadas em todos os sistemas, o processo para
geração dos arquivos da Circular é feito de forma manual, com alta dependência de pessoas
especializadas, que precisam entender as várias regras de negócio, as diferentes estruturas de
dados, de forma complexa e em um trabalho intenso em um período curto de tempo. Tal cenário
frequentemente está sujeito a trabalhos extras, riscos de falhas de informações e atrasos.
Uma solução comumente proposta é a construção de um DW que unifique as informações
requeridas de todos os sistemas legados, onde seja possível consolidar e validar os dados e
integrá-los com uma ferramenta (de um fornecedor a ser pesquisado no mercado) especializada
em gerar os relatórios da Circular 360, sendo tal ferramenta já homologada pelo mercado
securitário (isto é, que já seja utilizada por outras companhias seguradoras). Tal ferramenta tem a
função de terceirizar a preocupação com eventuais mudanças de formato e regras que a própria
SUSEP pode realizar sobre a circular, bem como a preocupação de realizar todas as críticas
possíveis, além de facilitar a manipulação com o obsoleto formato DBF.
O trabalho em questão pode trazer benefícios às companhias seguradoras como um todo,
visto que o cenário sistêmico descrito é comumente encontrado em outras seguradoras, e uma
análise do mesmo pode diminuir os riscos de multa e proibição de vendas de produtos de seguros
por atraso e falhas nas entregas dos arquivos solicitados.
Além disso, a literatura na internet sobre a Circular SUSEP 360 é restrita, muitas vezes
remetendo apenas ao site da própria SUSEP, onde a fonte mais detalhada de explicação é o
próprio documento Circular Número 360 de 2008, que é composto em grande parte de leiautes
dos arquivos e algumas recomendações sobre sua geração. Pretende-se enriquecer o assunto e
deixá-lo disponível para consulta a todos os interessados, visto que as bibliografias do mercado
securitário e da tecnologia da informação (TI) não se completam sobre este assunto.
Outro ponto em que esse trabalho pode contribuir é o esclarecimento sobre os reais
objetivos de um projeto de BI e os componentes de sua arquitetura, visto que o termo “data
warehouse” tem sido utilizado de forma indiscriminada por pessoas não especialistas em BI e TI,
que o usam apenas como sinônimo de “base de dados unificada”. Profissionais securitários
podem se beneficiar, pois, com um entendimento do que realmente um DW pode oferecer, eles
podem ter condições de avaliar se um projeto de BI é eficiente como repositório de dados com
fins de informações para SUSEP.
3
2. Revisão da Literatura
Aqui é apresentado o conjunto teórico sobre o qual a pesquisa é embasada, para fundamentar
conhecimentos já publicados que foram utilizados na investigação deste trabalho.
2.1 Definições
A seguir, os termos técnicos utilizados na exposição deste artigo.
2.1.1 Business Intelligence
O termo Business Intelligence (inteligência empresarial) “[...] é um termo abrangente que
inclui aplicações, infraestrutura e ferramentas, bem como as melhores práticas que possibilitam o
acesso e a análise de informações para melhorar e otimizar decisões e desempenho. ”
(GARTNER, 2015, tradução nossa)
2.1.2 Data Warehouse
Um Data Warehouse (DW), cuja tradução literal é “armazém de dados”, é um repositório central
de dados que armazena de forma consolidada informações históricas das atividades de uma
empresa. Deve armazenar dados limpos e padronizados para toda empresa, permitir a análise de
grandes volumes de dados, além de possuir indicadores de negócio que auxiliem na tomada de
decisões.
Para Turban (2009, p.57), é uma “coleção de dados orientada por assunto, integrada,
variável no tempo e não volátil, que proporciona suporte ao processo de tomada de decisões da
gerência”.
Os sistemas de DW possuem um repositório de metadados (metadata em inglês), que são
dados de alto nível que contém informações sobre os dados que estão armazenados no sistema,
descrevendo o conteúdo do DW, fonte de origem dos dados, destino dos dados, regras utilizadas,
frequência de atualização, entre outros.
2.1.3 Operational Data Store
Um Operational Data Store (ODS), como o próprio nome diz, se trata do armazenamento de
dados operacionais, ou seja, um banco de dados que integra dados de várias fontes operacionais
da empresa, para trabalhos adicionais sobre os dados, que são enviados para um data warehouse,
para outras operações e para relatórios, principalmente operacionais.
O ODS também é usado para “a integração de dados, verificação da qualidade de dados e
alimentação de outros sistemas com bons dados limpos. ” (NORRIS-MONTANARI, 2007a,
tradução nossa).
4
Este armazenamento de dados “não contém dados históricos, ao contrário do data
warehouse. [...]. Esses dados incluem [...] dimensões integradas exigidas pelo negócio, bem
como as transações. ” (NORRIS-MONTANARI, 2007b, tradução nossa, grifo nosso).
2.1.4 OLTP
O termo OLTP (Online Transaction Processing ou Processamento de Transações em Tempo
Real) refere-se aos sistemas que “lidam com os negócios rotineiros no andamento de uma
empresa. ” (TURBAN, 2009, p.36). Ou seja, são as aplicações da companhia que registram as
transações inerentes ao seu negócio. Exemplos: para um banco, OLTP pode se referir aos
sistemas que suportam as transações como saques, depósitos etc.; para uma empresa varejista,
OLTP pode ser o sistema de vendas.
2.1.5 ETL
O termo Extract-Transform-Load refere-se a ferramentas de extração (leitura de uma ou mais
origens de dados), transformação (conversão desses dados da sua forma original para uma nova
forma que siga regras estabelecidas) e carga (colocação dos dados em um DW ou em outro banco
de dados).
2.1.6 Staging Area
Uma Staging Area (área de preparação/estágio) é um local temporário de armazenamento e
processamento com o objetivo de facilitar a integração dos dados vindos do OLTP antes de
atualizá-los no ODS e/ou no DW, através do processo de ETL, incluindo a limpeza dos dados.
Segundo Machado (2013, p.40), com ela é possível “extrair os dados no momento em que
estão disponíveis e posteriormente integrá-los, [...] [facilitando] as extrações dos sistemas
operacionais durante períodos fora de picos de operações. ” Ou seja, a staging receberá os dados
diretamente das diversas fontes OLTP, mas apenas quando estas estiverem aptas a enviarem
dados, para não interferir no desempenho das mesmas. Já o ODS e principalmente o DW não
terão nenhuma conexão com a camada OLTP ou dependência de sua disponibilidade.
2.1.7 Data Mart
Um Data Mart (DM) é um repositório de dados que é um subconjunto do DW, mas aplicado a
um assunto específico ou com dados direcionados a uma área específica da empresa, contendo
apenas dados relevantes a ela. Exemplos: DM de Estoque, DM da Controladoria, DM de Vendas
Anual, DM de Vendas Mensal, DM de Prêmios de Seguros etc.
2.1.8 OLAP e Cubos
O processamento analítico online (On-line Analytical Processing) é o conjunto de ferramentas
para exploração de um DW sob múltiplas perspectivas. Seus usuários são gestores que
conseguem fazer análises diversas, descobertas de informações estratégicas, e,
consequentemente, tomada de decisões.
5
Um cubo (ou um cubo OLAP), segundo Turban (2009, p.118), é a representação de dados
associada a alguma medida e, embora seja chamado de cubo, pode ter duas, três ou mais
dimensões. Por exemplo, uma empresa pode querer resumir dados de vendas por produto, por
cliente e por cidade. Cada célula de um cubo formado por essa combinação conterá a contagem
do número de vezes que essa combinação ocorreu na base, e as células em branco equivalerão a
zero.
2.1.9 Granularidade de Dados
Granularidade é o nível de sumarização e detalhe dos dados disponíveis, sendo um aspecto
importante no projeto de um DW. Quanto mais detalhes, menor o nível de granularidade (ou seja,
“grãos” menores). Quanto menos detalhes, maior é a granularidade (ou seja, “grãos” maiores).
Em sistemas operacionais ou transacionais, a granularidade é tida como certa, pois são
armazenados no nível mais baixo de granularidade, por envolver muitos detalhes. Mas em um
DW, é questão crítica, pois a afeta o volume de dados armazenados e quais os tipos de consultas
que podem ser atendidas. (MACHADO, 2013, p.59)
2.1.10 Modelagem ER
O modelo de entidade e relacionamento (ER) é um modelo abstrato baseado no relacionamento
entre as entidades, onde os relacionamentos e as entidades podem possuir atributos, de modo a
representar a realidade e um sistema de informação de maneira conceitual. Está interligado à
normalização de dados, que é um processo onde se pode, gradativamente, substituir entidades e
relacionamentos por outros de modo a reduzir a redundância de dados, as dependências parciais e
as chances de inconsistências e perdas acidentais de informações, permitindo um armazenamento
consistente de um banco de dados e um acesso eficiente a ele (conhecido como Terceira Forma
Normal).
2.1.11 Modelagem Multidimensional
A modelagem multidimensional é um modelo normalmente usado em DW, diferente da típica
modelagem entidade-relacionamento, sendo mais simples, mais expressiva e mais fácil de
entender. Para Machado (2013, p.79, grifo nosso):
A Modelagem multidimensional uma técnica de concepção e visualização de um modelo
de dados de um conjunto de medidas que descrevem aspectos comuns de negócios. É
utilizada especialmente para sumarizar e reestruturar dados e apresenta-los em visões
que suportem a análise dos valores desses dados.
A modelagem entidade-relacionamento é muito útil em sistemas que trabalham com
transações, mas deve ser evitada na concepção de um DW, visto que este é um banco de dados
com o propósito de consultas de dados, objetivando o simples entendimento e o alto desempenho
de acesso.
6
2.1.12 Modelo estrela, fatos e dimensões
Conforme Machado (2013, p.92), o modelo estrela (star schema) é a estrutura básica de um
modelo multidimensional, sendo composto por uma grande entidade central chamada fato (fact
table), cercada de entidades menores chamadas dimensões (dimension tables).
O fato é aquilo que pode ser representado por valores numéricos ou medidas, sendo que
estes podem mudar com o tempo, já que o fato acompanha a evolução das transações e eventos
da companhia. E a dimensão refere-se a cada um dos elementos que participam de algum fato,
sendo uma forma de análise desses dados.
No exemplo da Figura 1, o centro da estrela é o fato vendas, e ao redor dela estão
dimensões que participam do assunto vendas: produto, vendedor, cliente, tempo e região.
Figura 1 – Modelo estrela representando o assunto vendas.
Fonte: MACHADO, Felipe Nery Rodrigues. Tecnologia e Projeto de Data Warehouse.
2.1.13 SUSEP
É a sigla para Superintendência de Seguros Privados. É o “[...] órgão responsável [no Brasil todo]
pelo controle e fiscalização dos mercados de seguro, previdência privada aberta, capitalização e
resseguro. Autarquia vinculada ao Ministério da Fazenda [...] [cuja missão é] regular,
supervisionar e fomentar os mercados de seguros, resseguros, previdência complementar aberta,
capitalização e corretagem, promovendo a inclusão securitária e previdenciária, bem como a
qualidade no atendimento aos consumidores. ” (SUSEP, 2015a)
7
2.1.14 Circular 360 da SUSEP ou Circular SUSEP 360
Documento de 15 de fevereiro de 2008 de autoria da SUSEP, esta circular “estabelece, altera e
consolida os arquivos de dados a serem encaminhados à SUSEP pelas Sociedades Seguradoras,
Sociedades de Capitalização, Entidades Abertas de Previdência Complementar, autorizadas a
operar no País, e a Caixa Econômica Federal (CAIXA). ” (SUSEP, 2015b)
Os arquivos exigidos podem ter obrigatoriedade de envio anual, semestral ou mensal, em
datas previamente estabelecidas ou podem ser solicitados por demanda. Com as informações
estatísticas e históricas que recebe das companhias, a SUSEP consegue fiscalizar e acompanhar a
situação das empresas envolvidas, conhece o mercado brasileiro de seguros na prática e suas
tendências e, com esses dados em mãos, pode elaborar novas normas.
Por ser um documento extenso, que engloba cerca de 50 arquivos com pelo menos 300
campos diferentes, foram selecionados apenas alguns assuntos da Circular para este trabalho. A
circular é dividida em nove anexos, cada um tratando de um assunto diferente e tendo uma data
específica de entrega das seguradoras à SUSEP, sendo que o quadro 1 apresenta quais anexos são
tratados neste trabalho.
Quadro 1 – Exemplos de anexos da Circular 360 da SUSEP.
Anexo
V
VI
VIII
IX
Assunto
Elaboração e Atualização Periódica de
Tábua Biométrica – Previdência Privada
Aberta, VGBL e Vida em Grupo
Seguros Compreensivos
Periodicidade
Registros contábeis auxiliares
obrigatórios em meio magnético
Seguro de Automóveis,
RCF-V e APP
Data limite de envio
Anual
31 de julho
Anual
31 de Março
5 (cinco) dias úteis
após o pedido da
SUSEP
31 de Março e 30 de
Setembro
Mensal
Semestral
Fonte: SUSEP, Circular nº 360.
2.1.15 Seguros, Prêmios, Sinistros e Registros Contábeis
O seguro é um contrato entre um segurado (pessoa física ou jurídica) e uma companhia
seguradora, onde o segurado transfere um risco a qual está exposto (uma perda ou dano, por
exemplo) para a seguradora, e esta assume o risco mediante uma importância paga pelo segurado
(chamada prêmio).
O sinistro é a ocorrência do evento relacionado ao risco coberto, durante o período de
vigência do plano de seguro (por exemplo, a morte de um segurado ou o dano a uma propriedade
sua); se o mesmo é aprovado, paga-se ao segurado uma indenização, que é o valor que a
sociedade seguradora deve pagar ao segurado ou beneficiário.
8
Os registros contábeis incluem os valores de prêmios e indenizações movimentados, além
do balancete da empresa e o razão analítico, que devem ser reportados pelas seguradoras à
SUSEP.
2.1.16 Seguro de Automóveis
Seguro que cobre perdas e danos (colisão, incêndio, roubo, prejuízos causados a terceiros etc.)
ocorridos a veículos terrestres automotores.
2.1.17 Seguros Compreensivos
Seguros que cobrem, basicamente, riscos de bens (patrimônio) em residências, empresas e
condomínios. Podem incluir coberturas de responsabilidade civil, de despesas médicas e outras
não patrimoniais. Os planos compreensivos garantem, em geral, três riscos: incêndio, queda de
raio e explosão. Além desses riscos, os compreensivos conjugam diversas coberturas adicionais,
tais como vendaval, queda de aeronaves, perda de aluguel etc. (SUSEP, 2015c)
2.1.18 Seguro de Vida e Tábua Biométrica
O seguro de vida é o contrato que garante a proteção financeira para familiares e dependentes do
segurado quando este morre. Também pode auxiliar o próprio segurado em caso de invalidez
permanente ou doença grave.
A Tábua Biométrica, conhecida também como Tábua de Mortalidade, Tábua de Vida ou
Tábua Atuarial, está relacionada aos seguros de vida e previdência privada. Conforme Oliveira
(2012, p.13):
A tábua de mortalidade para uma dada população é uma ferramenta [...] [para] estudos
atuariais e demográficos em geral. [...] Tábuas de mortalidade são muito usadas em
situações de previsões e estudos de demanda para serviços de saúde, educação e
relacionados ao mercado de trabalho, para estimativas de custo da seguridade social e de
prêmios de seguros privados.
3. Estado da Arte
A Circular 360, já apresentada na seção anterior, é de domínio público e pode ser acessada no site
da SUSEP.
Os modelos de arquitetura de BI têm vasta literatura na internet, sendo condensada por
Machado (2013, p.37) que apresenta as funções de elementos importantes para este trabalho,
como o DW, o ODS, a Staging Area, os Data Marts e suas interligações via ETL, bem como os
resultados das informações estratégicas em forma de cubos OLAP e relatórios, conforme a Figura
2.
9
Figura 2 – Arquitetura de tecnologia de BI.
Fonte: Os autores.
As modelagens ER (Figura 3) e Multidimensional (Figura 4) já são padrões aceitos no
mercado e têm funções distintas, sendo que a primeira é muito utilizada em sistemas
transacionais e a segunda em soluções de BI envolvendo DW, conforme citado na seção de
definições. E os dados de origem em um projeto de BI podem apresentar modelagens distintas,
por se tratarem de sistemas transacionais distintos, que podem envolver bancos de dados de
diversos tipos e conceitos, planilhas Excel e similares, arquivos de log etc. e podem ser
constituídos por sistemas padrões de mercado, sistemas ERPs (Enterprise Resource Planning,
planejamento de recurso corporativo) ou soluções de software próprias.
10
Figura 3 – Exemplo de modelagem relacional.
Fonte: FILHO, Ly Freitas. Data Warehouse.
Figura 4 – Exemplo de modelagem dimensional.
Fonte: FILHO, Ly Freitas. Data Warehouse.
Para Machado (2013, p.65), não se pode simplesmente mover um modelo de dados
transacional para um banco de dados separado, inserindo nele dados históricos, e considerá-lo
11
como um DW, pois não será possível os usuários trabalharem com esses dados por conta da
complexidade muito alta para que possam fazer suas consultas, além do fato de que modelos
transacionais são construídos respeitando a Terceira Forma Normal e não respondem com rapidez
a consultas típicas de apoio a decisão, que podem requerer vários relacionamentos entre tabelas.
Na próxima seção, apresentam-se os materiais e métodos utilizados para o desenvolvimento
da pesquisa deste trabalho, bem como os processos utilizados na investigação.
4. Plano de Pesquisa
A metodologia da pesquisa utilizada consistiu nas fases de especificação da amostra, coleta de
dados e, finalmente, cruzamento das informações coletadas.
4.1 Especificação da Amostra (Material)
A seguir estão especificadas origem, forma e natureza de cada uma das amostras estudadas
(sistema de origem de dados e relatórios da SUSEP).
4.1.1 Sistema de Origem (OLTP)
Neste artigo, são sendo utilizados exemplos de informações comumente usadas em uma
seguradora, focando em dados de emissões e prêmios e dados de sinistros e indenizações. Um
sistema (OLTP) securitário serviu de base para essas informações transacionais e, mesmo que sua
modelagem não siga as boas práticas de normalização de dados nem de nomenclatura de objetos,
tal sistema atende as regras do negócio e as estruturas básicas de informações de prêmios e
sinistros.
A ferramenta Microsoft Access®, contendo tabelas devidamente remodeladas conforme o
sistema transacional, serviu de repositório para estas amostras. Devida à complexidade do
sistema, o mesmo foi reduzido e adaptado, de forma que está sendo contemplada apenas parte das
tabelas e campos que contenham informações requeridas pela SUSEP 360 e que possam
contribuir ao estudo deste trabalho.
Está sendo focada apenas uma origem de dados, ou seja, apenas um sistema transacional
está servindo de fonte dos dados a serem testados nas hipóteses possíveis de DW. Em um projeto
real de BI ou mesmo de geração de dados à SUSEP, haveria várias fontes distintas, como
sistemas operacionais diversos, planilhas Excel, arquivos de log etc., com dados que precisariam
ser cruzados, somados ou substituídos entre si. Mas para o objetivo deste trabalho, uma origem
única é o suficiente para refletir a eficiência ou não no tratamento de dados do sistema
transacional tanto para fins de SUSEP como para fins de BI.
As Figuras 5 e 6 apresentam os modelos relacionais das tabelas que foram criadas no
Access, referentes aos dados levantados de prêmios e sinistros, respectivamente.
12
Figura 5 – Modelo relacional representando as tabelas de prêmios do sistema transacional.
Fonte: Os autores.
13
Figura 6 – Modelo relacional representando as tabelas de sinistros do sistema transacional.
Fonte: Os autores.
4.1.2 Relatórios SUSEP 360
Sobre as informações referentes à Circular 360, foram selecionados para este estudo alguns
arquivos relacionados a seguro de automóveis, seguros compreensivos, tábua biométrica e alguns
14
registros contábeis relacionados a prêmios emitidos, sinistros pagos, sinistros avisados e sinistros
pendentes, conforme listagem do Quadro 2.
Quadro 2 – Arquivos da Circular 360 tratados neste trabalho.
Anexo
V - Tábua Biométrica
Arquivo
AT_MOR.DBF
V - Tábua Biométrica
SA_MOR.DBF
VI - Seguros
Compreensivos
VI - Seguros
Compreensivos
VIII - Registros
contábeis
VIII - Registros
contábeis
VIII - Registros
contábeis
VIII - Registros
contábeis
IX - Seguro de
Automóveis
IX - Seguro de
Automóveis
R_COMP.DBF
S_COMP.DBF
PREMIT.DBF
SINAV.DBF
SINPAG.DBF
SINPEND.DBF
R_AUTO.DBF
S_AUTO.DBF
Assunto
Segurados/participantes ativos que possuem
planos com a cobertura de morte
Saídas de segurados/participantes ativos que
possuem planos com a cobertura de morte.
Dados estatísticos dos seguros compreensivos
(apólices vigentes)
Dados estatísticos dos seguros compreensivos
(sinistros avisados)
Arquivo de registro de emissão.
Arquivo de registro de sinistros avisados e
reavaliados, relativos à emissão própria.
Arquivo de registro de sinistros pendentes de
pagamento, relativos à emissão própria.
Arquivo de registro de sinistros pendentes de
pagamento, relativos à emissão própria.
Dados estatísticos da carteira de automóveis
(apólices vigentes)
Dados estatísticos da carteira de automóveis
(sinistros avisados)
Embora a Circular 360 especifique que os arquivos sejam gerados no formato DBF (Data
Base File), suas estruturas foram adaptadas para o Access, onde a manipulação é mais amigável e
com mais recursos.
As Figuras 7 a 10 apresentam as estruturas dos arquivos DBF selecionados importados
para o Access.
15
Figura 7 – Modelo relacional representando as tabelas R_COMP e S_COMP.
Fonte: Os autores.
Figura 8 – Modelo relacional representando as tabelas PREMIT, SINPAG, SINAV e SINPEND.
Fonte: Os autores.
16
Figura 9 – Modelo relacional representando as tabelas AT_MOR e SA_MOR.
Fonte: Os autores.
17
Figura 10 – Modelo relacional representando as tabelas R_AUTO e S_AUTO.
Fonte: Os autores.
Dada a grande quantidade de campos envolvidos na seleção de tabelas SUSEP acima
expostas, serão utilizados apenas alguns campos, de modo que cada tabela, por pertencer a um
assunto distinto e ter um nível de granularidade diferente, deve representar o sucesso ou não da
transição de dados do sistema transacional de origem para os relatórios da SUSEP e para a
solução de DW.
18
4.2 Coleta de Dados (Métodos)
Aqui se apresenta como foi feita a investigação dos dados, ou seja, como as amostras foram
manipuladas, observadas e analisadas. Este estudo de caso trata de três camadas de dados:
sistema OLTP, estrutura de BI e relatórios SUSEP.
4.2.1 Sistema de Origem (OLTP)
Para a coleta dos dados utilizados na base descrita na amostra, foram usados exemplos
manipulados, ou seja, dados mascarados através de algoritmo, provenientes de um sistema
corporativo. Tais dados foram devidamente alterados com intuito de não divulgar informações
confidenciais, mas não perderam características importantes, principalmente da sua estrutura.
Estes dados fictícios foram carregados no repositório Access, simulando um ambiente
operacional, sendo selecionada apenas uma parcela do total de registros.
4.2.2 Estrutura de BI
Também foi desenhada uma estrutura típica de BI, contendo bases de DW e ODS, além de scripts
de ETLs que carregaram os dados do sistema de origem para esta estrutura. Os dados importados
foram confrontados com a amostra de arquivos/campos da SUSEP, com o intuito de testar as
possibilidades de transferências de dados entre o sistema origem, a solução de BI e os relatórios
da SUSEP.
4.2.2.1 Criação do DW
Para o DW, seguindo as boas práticas, as estruturas dos dados foram criadas seguindo o modelo
estrela (star schema). Para este estudo da área de seguros, foi criada uma tabela fato (que
representa algo que ocorreu e que pode ser medido) para o assunto “prêmios” e suas emissões e
pagamentos (Figura 11) e outra tabela fato para o assunto “sinistros” e suas ocorrências, avisos e
liquidações (Figura 12). Cada uma dessas tabelas fato está relacionada às suas tabelas de
dimensões (que representam algo que é consultado por algum critério, como data, local, produto
etc.). E ambas foram constantemente remodeladas durante a confecção deste estudo, até
chegarem ao modelo atual, visto que, durante a fase em que os dados do sistema de origem foram
mapeados e trabalhados (via ETL), novas necessidades foram surgindo, conforme será citado na
seção sobre cruzamento de dados.
19
Figura 11 – Modelo estrela representando os dados de prêmios do DW.
Fonte: Os autores.
20
Figura 12 – Modelo estrela representando os dados de sinistros do DW.
Fonte: Os autores.
4.2.2.2 Criação do ODS
Para a elaboração do ODS, simplesmente replicou-se a estrutura das tabelas de origem do OLTP,
pelo fato de existir apenas uma fonte de dados e, principalmente, pelo fato de que esta fonte de
dados já foi remodelada para melhor atender os objetivos deste trabalho, como explicado
anteriormente.
Isso significa que, quando este trabalho fizer referências aos dados do ODS, pode-se
entender que tais referências poderiam ser aplicadas também aos dados do OTLP. Por exemplo,
uma leitura de uma tabela da camada ODS se comportaria da mesma forma (em termos de dados,
e não de desempenho) que uma leitura da tabela correspondente ao sistema transacional de
origem, visto que a estrutura desenhada é idêntica.
4.2.3 Camada de dados SUSEP
Para os dados SUSEP, conforme já descrito anteriormente, algumas tabelas da Circular 360
foram selecionadas e suas estruturas foram adaptadas do formato DBF para o repositório Access,
21
gerando uma série de tabelas vazias. Para o preenchimento das mesmas, foi simulada a geração
dos dados a partir da massa existente no DW e no ODS, conforme será descrito na seção de
cruzamento de dados.
4.3 Fases da Coleta de Dados
A coleta dos dados necessários a partir do Sistema de Origem foi feita uma única vez, não tendo
sido necessário complementar a massa de dados com mais registros ou tabelas. Conforme já
citado anteriormente, pode-se assumir que esses também são os dados da camada ODS. A Figura
13 apresenta uma das tabelas (tabela de emissão de apólices) importadas para dentro do Access,
após a manipulação e adaptação de dados.
Figura 13 – Exemplo de dados carregados na camada ODS (tabela transacional de apólices).
Fonte: Os autores.
Após a importação dos dados brutos, foi feito uma série de trabalhos (ETL) de conversão
e condensação dos dados do ODS para o modelo de DW já citado anteriormente, que foi
constantemente incrementado conforme as necessidades observadas na fase de ETL. A Figura 14
apresenta uma das tabelas do DW (fato de prêmio) preenchidas no Access.
22
Figura 14 – Exemplo de dados carregados na camada DW (tabela fato de prêmios).
Fonte: Os autores.
Uma segunda série de trabalhos de ETL foi feita para gerar os dados necessários à
SUSEP. Em alguns momentos foram utilizados somente dados do DW; em outros, foi necessário
buscar dados do ODS; e ainda houve casos em que a informação requisitada pela SUSEP não se
encontrava nem no DW nem no ODS (nestes casos, assume-se que tal informação possa estar em
alguma outra tabela do OLTP que não foi mapeada, ou, no pior dos casos, assume-se que tal
informação não exista em forma de sistema computacional e precise ser alimentada
posteriormente de forma manual nas tabelas da SUSEP). A próxima seção, sobre cruzamento de
dados, tratará com mais detalhes sobre essas necessidades de fontes de dados diferentes. A Figura
15 apresenta uma das tabelas da SUSEP (tabela AT_MOR) preenchida dentro do Access.
Figura 15 – Exemplo de dados carregados na camada SUSEP (tabela AT_MOR).
Fonte: Os autores.
23
4.4 Cruzamento de Dados
Este estudo pretende avaliar se apenas o DW é suficiente para gerar os dados da SUSEP, ou se é
necessário buscar dados de outras fontes, como o ODS (que reflete a estrutura do sistema de
origem OTLP), os DMs (que refletem a estrutura do DW) e os cubos OLAP (montados a partir
do DW e DMs).
O cruzamento de dados seguiu o seguinte critério: para cada um dos arquivos da SUSEP
selecionados, verificou-se campo a campo se tal informação poderia ou não ser alimentada
apenas com dados provenientes das tabelas do DW. Em caso positivo, foi indicado qual campo (e
tabela) dentro do DW possui o dado de origem. Em caso negativo, entende-se que a informação
necessária à SUSEP deveria ter origem nas tabelas do ODS, e foi indicado qual campo (e tabela)
do ODS a possui.
No momento em que for demonstrado que um determinado campo SUSEP poderia ser
alimentado pelo DW, não deve ser necessário verificar qual sua origem dentro do ODS. E no
momento em que for encontrado pelo menos um campo SUSEP que já não poderia ser
alimentado pelo DW, não deverão ser verificados os demais campos daquela tabela, visto que
basta uma informação inexistente no DW para inviabilizar sua geração de dados para o arquivo
SUSEP em questão.
O Quadro 3 apresenta a origem de dados dos campos da tabela AT_MOR da SUSEP em
relação ao DW e ao ODS, onde estão listadas as seguintes informações: a relação dos campos da
própria tabela, uma breve descrição do campo (a descrição completa encontra-se na seção de
anexos deste trabalho) e a origem desta informação, ou seja, a tabela e campo a partir da camada
DW ou ODS. Exemplificando: o campo CPF da tabela AT_MOR pode ser encontrado na tabela
do DW chamada Dim_Segurado, no campo Doc_Segurado. Já o campo DATA_INGR não é
encontrado no DW, apenas no ODS, na tabela TB_APOLICE, no campo
dt_Inicio_Vigencia_Apolice ou no campo dt_Inicio_Vigencia_Endosso. De forma análoga, os
Quadros 4 - 7 representam, respectivamente, as tabelas SA_MOR, R_COMP, S_COMP e
PREMIT.
Quadro 3 – Cruzamento entre a tabela AT_MOR e as tabelas do DW e ODS.
Campo SUSEP
PRODUTO
COBERTURA
DATA_NASC
Descrição
Tabela/Campo DW
Dim_Produto/
Produto
cod_Prod_Circ_360_V
Dim_Cobertura/
Cobertura
cod_Cob_Circ_360_V
Dim_Segurado/
Data de nascimento
Data_Nascimento
Tabela/Campo ODS
X
X
X
24
DATA_INGR
Data de ingresso no
plano
CPF
CPF do segurado
SEXO
Sexo do segurado
VALOR
Valor do prêmio
X
Dim_Segurado/
Doc_Segurado
Dim_Segurado/
Sexo
Fato_Premio/
Val_Premio_Emitido
TB_APOLICE/
dt_Inicio_Vigencia_
Apolice ou
TB_APOLICE/
dt_Inicio_Vigencia_
Endosso
X
X
X
Fonte: Os autores.
Quadro 4 – Cruzamento entre a tabela SA_MOR e as tabelas do DW e ODS.
Campo SUSEP
Descrição
PRODUTO
Produto
COBERTURA
Cobertura
MOT_SAIDA
Motivo de Saída
DATA_NASC
Data de nascimento
DAT_EVENTO
Data de ocorrência
DATA_AVISO
Data do aviso
CPF
CPF do segurado
SEXO
Sexo do segurado
Tabela/Campo DW
Dim_Produto/
cod_Prod_Circ_360_V
Dim_Cobertura/
cod_Cob_Circ_360_V
Dim_Cobertura/
cod_Motivo_Circ_360_V
Dim_Segurado/
Data_Nascimento
Fato_Sinistro/
id_Tempo_Ocorrencia
Fato_Sinistro/
id_Tempo_Aviso
Dim_Segurado/
Doc_Segurado
Dim_Segurado/
Sexo
Tabela/Campo ODS
X
X
X
X
X
X
X
X
Fonte: Os autores.
Quadro 5 – Cruzamento entre a tabela R_COMP e as tabelas do DW e ODS.
Campo SUSEP
PROCESSO
Descrição
Número do
processo
TIPO
Tipo
CLASSE
Classe
APOLICE
Número da
apólice
Tabela/Campo DW
Dim_Produto/
Num_Processo
Dim_Produto/
cod_Tipo_Circ_360_VI
Dim_Produto/
cod_Classe_Circ_360_VI
Dim_Produto/
Num_Apolice ou
Dim_Segurado/
Num_Apolice
Tabela/Campo ODS
X
X
X
X
25
Campo SUSEP
ENDOSSO
COD_END
ITEM
Descrição
Número do
endosso
Código de
endosso
Item de
identificação
COBERTURA
Cobertura
UF
UF do local do
risco
Tabela/Campo DW
X
Dim_Tipo_Endosso/
cod_End_Circ_360_VI
Dim_Cobertura/
cod_Cob_Circ_360_VI
Dim_Segurado/
UF
Início de
vigência
X
FIM_VIG
Fim de vigência
X
VAL_FRANQ
IMP_SEG
PREMIO
Valor da
franquia
contratada
Importância
segurada
Valor do prêmio
X
TB_APOLICE/
Item
X
INICIO_VIG
Tabela/Campo ODS
TB_APOLICE/
Endosso
X
X
TB_APOLICE/
dt_Inicio_Vigencia_
Apolice ou
TB_APOLICE/
dt_Inicio_Vigencia_
Endosso
TB_APOLICE/
dt_Fim_Vigencia_
Apolice ou
TB_APOLICE/
dt_Fim_Vigencia_
Endosso
TB_APOLICE/
Val_Franquia
X
Fato_Premio/
Val_Importancia_Segurada
Fato_Premio/
Val_Premio_Emitido
X
X
Fonte: Os autores.
Quadro 6 – Cruzamento entre a tabela S_COMP e as tabelas do DW e ODS.
Campo SUSEP
Descrição
TIPO
Tipo
CLASSE
Classe
APOLICE
Número da apólice
ENDOSSO
Número do endosso
Tabela/Campo DW
Dim_Produto/
cod_Tipo_Circ_360_VI
Dim_Produto/
cod_Classe_Circ_360_VI
Dim_Produto/
Num_Apolice ou
Dim_Segurado/
Num_Apolice
X
Tabela/Campo ODS
X
X
X
TB_APOLICE/
Endosso
26
ITEM
Item de identificação
COBERTURA
Cobertura
UF
UF do local do risco
VAL_FRANQ
INDENIZ
D_AVISO
D_LIQ
D_OCORR
X
Dim_Cobertura/
cod_Cob_Circ_360_VI
Dim_Segurado/
UF
Valor da franquia
X
contratada
Valor da indenização Fato_Sinistro/
paga
val_Indenizado
Fato_Sinistro/
Data do aviso
id_Tempo_Aviso
Fato_Sinistro/
Data da liquidação
id_Tempo_Liquidacao
Fato_Sinistro/
Data de ocorrência
id_Tempo_Ocorrencia
TB_APOLICE/
Item
X
X
TB_APOLICE/
Val_Franquia
X
X
X
X
Fonte: Os autores.
Quadro 7 – Cruzamento entre a tabela PREMIT e as tabelas do DW e ODS.
Campo SUSEP
NUM_PROC
TIPO_MOV
UF_DEP
Descrição
Número do
processo
Tipo de
movimento
UF da
dependência ou
unidade
Emissora
COD_RAMO
Código do ramo
na SUSEP
NUM_APOL
Número da
apólice
NUM_END
NUM_PROP
DT_PROP
Número do
endosso
Número da
proposta
Data da proposta
Tabela/Campo DW
Dim_Produto/
Num_Processo
Dim_Tipo_Endosso/
cod_End_Circ_360_VIII_Pre
Dim_Segurado/
UF
Dim_Produto/
Ramo ou
Dim_Segurado/
Ramo_Apolice ou
Dim_Cobertura/
Ramo
Dim_Produto/
Num_Apolice ou
Dim_Segurado/
Num_Apolice
X
X
X
Tabela/Campo ODS
X
X
X
X
X
TB_APOLICE/
Endosso
TB_APOLICE/
Num_Proposta
TB_APOLICE/
Dt_Proposta
27
Campo SUSEP
CPF_SEG
QTD_SEG
Descrição
CPF/CNPJ do
segurado
Quantidade de
segurados
Tabela/Campo DW
Dim_Segurado/
Doc_Segurado
Fato_Premio/
quant_Segurados
CPF_TOM
CPF/CNPJ do
tomador
X
QTD_TOM
Quantidade de
tomadores
X
DT_EMIS
Data de emissão
X
DT_INI_VIG
Data de início
de vigência
X
DT_FIM_VIG
Data de fim de
vigência
X
PR_EMIT
Prêmio emitido
PR_COS_CED
AD_FRAC
Prêmio do
cosseguro
cedido
Valor do
adicional de
fracionamento
CUST_APOL
Custo da apólice
IOF
Imposto sobre
operações
financeiras
Fato_Premio/
val_Premio_Emitido
Fato_Premio/
val_Premio_Cosseguro_
Cedido
Fato_Premio/
val_Adicional_
Fracionamento
Fato_Premio/
val_Custo_Apolice
Fato_Premio/
val_IOF
Tabela/Campo ODS
X
X
Não mapeado no ODS,
assume-se que se
encontra em outra parte
do OLTP.
assume-se que se
do OLTP.
TB_APOLICE/
dt_Emissao_
Apolice ou
TB_APOLICE/
dt_Emissao_
Endosso
TB_APOLICE/
dt_Inicio_Vigencia_
Apolice ou
TB_APOLICE/
dt_Inicio_Vigencia_
Endosso
TB_APOLICE/
dt_Fim_Vigencia_
Apolice ou
TB_APOLICE/
dt_Fim_Vigencia_
Endosso
X
X
X
X
X
28
Campo SUSEP
COMIS
Descrição
Comissão de
corretagem
COMIS_COSS
Comissão do
cosseguro
cedido
PRO_LAB
Pró-labore a ser
pago
Tabela/Campo DW
Fato_Premio/
val_Comissao_Corretagem
X
CPF_ESTIP
CPF/CNPJ do
estipulante
IS
Importância
segurada
Fato_Premio/
val_Pro_Labore
X
Fato_Premio/
val_Importancia_Segurada
Tabela/Campo ODS
X
assume-se que se
do OLTP.
X
assume-se que se
do OLTP.
X
Fonte: Os autores.
Para a elaboração deste estudo, as tabelas SINAV, SINPAG, SINPEND, R_AUTO e
S_AUTO também foram mapeadas e utilizadas para fins de ETL, mas como as tabelas
AT_MOR, SA_MOR, R_COMP, S_COMP e PREMIT representadas nos quadros anteriores já
ilustram as necessidades de busca de informações do DW ou ODS, não se faz necessário trazer
seus mapeamentos neste trabalho.
Sobre as tabelas SUSEP ilustradas nos quadros anteriores, nota-se que vários campos
podem se preenchidos com dados oriundos no DW, mas existem também outros campos que só
podem ser preenchidos com dados vindos do ODS ou do OLTP. Esta necessidade de buscar
dados fora do DW acontece com a maioria das tabelas, conforme mostra o quadro 8.
Quadro 8 – Relação de tabelas SUSEP e necessidade da origem de dados.
Tabela SUSEP
AT_MOR
SA_MOR
R_COMP
S_COMP
PREMIT
Necessidade de buscar
informações fora do DW
Sim
Não
Sim
Sim
Sim
Quantidade de campos que
requerem dados fora do DW
1
0
5
3
10
Isto significa que, para geração dos dados SUSEP em estudo, existe a necessidade de
carregar dados não só do DW, mas também do ODS (ou até mesmo do OLTP, caso o sistema de
origem não seja representado pelo ODS em sua totalidade).
Nota-se também que elementos como os DMs e o OLAP, mesmo sendo itens constantes e
importantes da arquitetura de BI, não serão objetos deste estudo, visto que apenas o ODS e o DW
foram suficientes para fazer o confronto dos dados e levantamento das hipóteses.
29
Resultados e discussões
A seguir são expostos e discutidos os resultados obtidos na pesquisa, bem como as hipóteses
levantadas a partir da análise desses resultados.
5. Apresentação das Hipóteses de Estudo
Os arquivos exigidos pela SUSEP possuem vários tipos de granularidade, ou seja, diferentes
níveis de detalhes. Alguns são arquivos de conteúdo estatístico, com alta granularidade, ou seja,
um baixo nível de detalhes, sendo tão sumarizados quando os dados de um DW. Entretanto,
outros arquivos têm granularidade baixa, ou seja, possuem um alto nível de detalhes,
contemplando informações de cada transação, como, por exemplo, as emissões, os sinistros e os
itens segurados, além de detalhes muito específicos que variam de acordo com o ramo de seguro.
Sendo assim, as informações que irão compor os relatórios não podem vir somente de um DW,
pois este somente deveria ter uma granularidade alta, por conter informações consolidadas para
fins estratégicos. Logo, parte das informações a serem reportadas à SUSEP deve refletir a
natureza transacional dos sistemas legados da companhia, função que o DW não faz.
Deve-se ressaltar que as boas práticas de BI recomendam que a extração de informações
para o DW não seja feita diretamente dos sistemas OLTP, por concorrer com as transações feitas
em tempo real, e como existem várias fontes diferentes de dados (algumas em sistemas
operacionais e outras em simples arquivos e planilhas), sendo que estas origens distintas podem
ter dados que se completam e se duplicam, é também boa prática que os mesmos devam ser
integrados e consolidados em um repositório à parte para compor os relatórios. Esta base de
dados unificada deve receber, por uma camada ETL, os dados relevantes da companhia, camada
esta que deve se preocupar com as regras de negócios para compor e unificar as informações
vindas de origens distintas.
Embora este processo de criação de uma base única para a companhia lembre a
composição de um DW, na verdade ele abrange apenas uma parte da arquitetura, que é a geração
de dados para o ODS, que participa do momento anterior ao envio de dados para a composição
do BI propriamente dito. O ODS é um dos componentes não indispensáveis de uma arquitetura
de BI, e pode existir de forma temporária apenas, mas torna-se o elemento mais importante da
arquitetura se a companhia tem como meta a geração de relatórios operacionais como os da
SUSEP, visto que este tipo de armazenamento de dados também reflete a natureza transacional
dos sistemas envolvidos, podendo gerar de forma mais fiel os dados regulatórios. E a camada
ETL que alimenta o ODS é de grande importância, pois é a responsável por fazer a integração
entre as diferentes origens OLTP para uma base única de dados.
Conforme Leão (2015):
[...] Uma camada ODS na terceira forma normal (e só pode ser assim) [...] permitirá
gerar relatórios nos templates exigidos pela SUSEP, de maneira mais fácil, utilizando
uma ferramenta com foco em gerar relatórios [...]. A utilização de uma camada
dimensional será mais útil caso [...] necessite oferecer aos [...] usuários a possibilidade
de gerar consultas ou painéis de informação [com objetivo estratégico de apoio à tomada
de decisão].
30
O Quadro 9 demonstra as principais diferenças entre um ODS e um DW, conforme
apontado por Schroeck (2001, tradução nossa).
Quadro 9 – Comparação ODS/DW.
ODS
Transações similares às de um sistema OLTP.
Contêm dados atuais e quase atuais.
Tipicamente somente dados detalhados,
frequentemente resultando em grande volume
de dados.
Carga de dados em tempo real e quase em
tempo real.
Geralmente modelado para suportar atualização
rápida de dados.
DW
Consultas processam grande volume de dados.
Contém dados históricos.
Contêm dados sumarizados e detalhados,
geralmente menores em tamanho do que um
ODS.
Tipicamente carga de dados em lote.
Geralmente modelado de forma dimensional e
ajustado para aperfeiçoar o desempenho de
consultas.
Atualizado no nível de campo de dados.
Os dados são acrescentados, não atualizados.
Usado para tomada de decisão detalhada e Usado para tomada de decisões de longo prazo
relatórios operacionais.
e relatórios gerenciais.
Trabalhadores do conhecimento (representantes Pessoas estratégicas (executivos, gestores das
do serviço ao cliente, gerentes diretos).
unidades de negócio).
Fonte: SCHROECK, Michael J. ODS: The Cornerstone of Information Integration.
Complementando, existem ferramentas no mercado securitário que são especializadas em
gerar informações para a SUSEP (incluindo a Circular 360), como, por exemplo: GEPRO®
(Gestão de Provisões e Registros Oficiais) da Confitec, OIM® (Módulo de Informações
Operacionais) da ITG, CORE-SUS® da CoreOn, entre outros. Mas para uma implantação
eficiente destes sistemas, uma das preocupações é que os mesmos acessem uma fonte única de
dados, visto que, quando uma empresa seguradora possui vários sistemas trabalhando em
paralelo, existe a possibilidade de haver informações redundantes ou mesmo incompletas, se
analisadas isoladamente. Por isso, existe a necessidade de uma base de dados única e integrada.
E, como visto anteriormente, esta fonte única de dados não poderia ser um DW, já que vários
relatórios oficiais da SUSEP 360 exigem um grau de detalhamento operacional que um DW
não poderia oferecer, mas que um ODS pode.
Logo, uma companhia seguradora tem, conforme hipóteses levantadas por este trabalho,
as seis opções a seguir de como contemplar uma solução de BI como apoio à geração de dados
periódicos de fiscalização:
5.1 Solução de BI completa
Pode-se construir uma arquitetura completa de BI, que tem um ODS funcional e não temporário
que, além da sua função primária de receber dados dos sistemas OLTP e enviá-los para o DW,
servirá também como fonte de dados para a geração dos arquivos para SUSEP, visto que o ODS
estará no mesmo nível de granularidade dos sistemas de origens e dos arquivos da Circular 360.
31
Tal estrutura conta também com um DW que, embora não sirva para a geração de tais
relatórios oficiais da SUSEP, cumprirá sua função estratégica de BI, tendo um papel mais amplo
dentro da companhia, caso a mesma deseje aproveitar todo o esforço investido na coleta,
transformação e integração dos seus dados em uma base única. Ou seja, é uma solução que
contempla a SUSEP e também o BI, por conter um ODS e um DW, conforme representado pela
Figura 16. Nesta e nas próximas cinco figuras, a região delimitada pela linha pontilhada é o
objeto de estudo deste trabalho.
Figura 16 – Arquitetura de tecnologia de BI completa, incluindo DW e ODS.
Fonte: Os autores.
5.2 Solução de BI parcial
Uma segunda opção seria construir uma arquitetura parcial similar à que seria utilizada para uma
solução completa de BI. Esta também contaria com um ODS funcional e não temporário,
recebendo dados transacionais das origens e estando preparado para os relatórios da SUSEP. Mas
seria uma estrutura sem um DW propriamente dito, ou seja, o ODS é a última etapa do processo
dentro do escopo de uma arquitetura de BI.
Pode-se decidir por esta opção caso a empresa esteja apenas focada em poder gerar os
dados requisitados pela SUSEP, mas caso não esteja interessada em uma solução de BI (ou não
32
tenha recursos para uma). Desta forma, será utilizado todo o mecanismo que foi criado para a
preparação dos dados que uma solução de BI utilizaria (neste caso, sob a forma de ODS e o ETL
que o alimenta). Ou seja, é uma solução que contempla a SUSEP, mas não contempla o BI, por
não possuir um DW (embora contenha parte de uma estrutura de BI, possuindo um ODS),
conforme representado pela Figura 17.
Figura 17 – Arquitetura de tecnologia de BI parcial, com ODS, mas sem DW.
Fonte: Os autores.
5.3 Solução de BI expansível
Assim como o modelo anterior, esta arquitetura tem um ODS funcional e não tem um DW.
Todavia, se a empresa quiser investir em um projeto de BI no futuro, já terá uma estrutura para
aproveitar e dar continuidade, economizando recursos e tempo. Aplica-se também ao caso de
empresas que queiram dividir a criação da solução em dois projetos distintos, um para o BI e
outro para a SUSEP, algo que pode ocorrer por questões de prioridades da companhia, por conta
de limitações de recursos ou até mesmo por causa de departamentos diferentes envolvidos na
implantação.
Assim, é uma solução que contempla a SUSEP no momento atual e pode contemplar o BI
em um momento futuro, por já conter um ODS implantado (Figura 18).
33
Figura 18 – Arquitetura de tecnologia de BI parcial (contém um ODS) e ainda sem DW, mas expansível.
Fonte: Os autores.
5.4 Solução de BI incompleta
Uma arquitetura de BI comum, como alternativa existente, pode não precisar contemplar um
ODS, ou pode possuir um ODS como repositório temporário. O foco desta opção seria
prioritariamente gerar os dados para o DW e atender as demandas de BI, e não está focando em
relatórios que não sejam gerenciais nem estratégicos. Isto é, relatórios operacionais como os
solicitados pela SUSEP, que necessitam de informações transacionais, não seriam contemplados
por esta arquitetura.
Isto é, trata-se de uma solução que contempla o BI (por possuir um DW), mas não a
SUSEP (por não possuir um ODS), conforme a Figura 19 representa.
34
Figura 19 – Arquitetura de tecnologia de BI incompleta, com DW, mas sem ODS.
Fonte: Os autores.
5.5 Solução de BI incorreta
Podem existir arquiteturas em que as empresas não utilizem as boas práticas de estruturas de BI, e
montem um DW que não seja multidimensional e reflita os dados transacionais, ou montem uma
solução em que várias tabelas transacionais são agregadas às tabelas do DW. Essas soluções
fugiriam do modelo padrão de DW, apenas com o objetivo de extrair relatórios que não sejam
típicos de BI, isto é, para que seja possível extrair do DW os dados transacionais para outros tipos
de relatórios, principalmente operacionais (como, por exemplo, os arquivos da SUSEP 360).
Esta solução pode ter problemas de desempenho do DW quando o mesmo é acessado para
fins de BI, por existir mais relações entre tabelas do que normalmente existiria em um modelo
estrela típico. Há também a possibilidade de que o mesmo ocorra quando o DW é acessado para
atender a geração de dados da Circular 360, devido ao grande volume de dados históricos. Isto é,
mesmo que todos os dados necessários à SUSEP estejam armazenados em um repositório único
com dados transacionais, não é garantia que os mesmos possam ser extraídos de forma eficiente
se adotado este modelo.
Assim, é uma solução que contempla o BI de forma incorreta (com um DW refletindo
dados transacionais) e pode contemplar ou não a SUSEP, conforme representado pela Figura 20.
35
Figura 20 – Arquitetura de tecnologia de BI incorreta, com DW refletindo dados transacionais.
Fonte: Os autores.
5.6 Sem solução de BI
Existe a possibilidade de a empresa não contemplar o que já existe na literatura e no mercado,
como as vantagens das soluções de ETL, ODS e DW, e investir em soluções locais e até mesmo
paliativas para a geração de relatórios para SUSEP. Tais soluções seriam, por exemplo, a geração
de relatórios diretamente a partir dos sistemas de origem (com ou sem integração entre estes
sistemas) ou a integração dos dados dos sistemas de forma manual, sem seguir boas práticas
como as utilizadas no ETL da geração de um ODS.
Assim, é uma solução que não contempla o BI (por não possuir DW nem ODS) e pode ter
dificuldades em contemplar a SUSEP (Figura 21).
36
Figura 21 – Arquitetura de tecnologia de BI inexistente (sem DW nem ODS).
Fonte: Os autores.
Este tipo de estratégia está sujeito a vários riscos, como, por exemplo: a duplicidade dos
dados, a falta de integridade dos dados, uma falsa visão da informação, manutenções constantes
na geração dos relatórios etc. Estes riscos estão associados a problemas como a falta de uma
camada onde tratar os dados, a ausência de um dicionário de dados que traduza os sistemas de
origem (metadados), a falta de flexibilidade no processo, entre outros. E, pelo fato de estar
conectado diretamente ao OLTP, ainda pode-se citar um baixo desempenho e até mesmo paradas
críticas na extração de dados (inclusive nos próprios sistemas transacionais) e, como
consequência, atrasos na geração dos relatórios periódicos e a impossibilidade de geração de
relatórios emergenciais e sob demanda.
6. Conclusões
A solução de BI incompleta, que contém um DW, mas não uma ODS, pode ser uma solução que
cause certo equívoco entre os profissionais que queiram montar uma base única para gerar os
dados para SUSEP, caso tais profissionais não entendam as diferenças de modelagem e
granularidade entre um DW e um ODS e quando não se atentam para o nível de detalhamento
que a Circular 360 solicita em seus diversos relatórios oficiais.
Tal equívoco pode ter origem em uma interpretação errônea de que DW seja sinônimo
de base única. Sabe-se que um repositório com dados integrados de toda a corporação é a chave
37
para a geração de relatórios como os apresentados neste estudo, já que são relatórios globais, que
abrangem toda a companhia. Entre as seis hipóteses apresentadas, existem cinco em que o DW
e/ou o ODS representam tal figura de base única de dados. Mas somente três destas soluções, as
que possuem pelo menos a camada de ODS em suas estruturas, são aquelas em que é possível
gerar tais relatórios para a Circular SUSEP 360. Isto por que o ODS representa os dados da
companhia integrados em um repositório único, e na granularidade compatível com o OLTP e
com os relatórios exigidos.
Para Inmon (2000, tradução nossa, grifo nosso), “o valor real do ODS aparece na
capacidade de armazenar dados integrados, [...] [que] são sempre difíceis de construir, mas, uma
vez construídos, têm valor corporativo real”. Ou seja, o ODS cumpre tanto o papel de enviar
dados integrados para o DW como o papel de alimentar os relatórios operacionais de toda a
empresa. Mesmo que o DW seja a figura mais conhecida e mais referenciada do que o ODS,
tanto na literatura especializada como no mercado, o ODS tem papel fundamental em reunir e
unificar os dados da companhia.
Conforme Kelley (2007, tradução nossa, grifo nosso):
[...] [Há] várias organizações começando a construção de um armazenamento de dados
operacionais (ODS), mas chamando-o de data warehouse. Então quando eles realmente
começam a olhar para o data warehouse, [...] ele não funciona muito bem. O que
acontece é frustração. [...] [O ideal] é que cada organização olhe para a forma como os
dados serão utilizados e, em seguida, construa a estrutura de dados mais adequada para
as necessidades, [...] principalmente por causa da finalidade do ODS (mais de natureza
operacional) e da finalidade do DW (mais de natureza estratégica) [serem diferentes].
Ou seja, quando for feita uma interpretação adequada dos componentes de uma
arquitetura de Business Intelligence, diferenciando um Data Warehouse de um Operational Data
Store, e quando for feita uma análise apropriada do nível de detalhamento que a SUSEP solicita
para os arquivos da Circular 360, uma solução de BI será eficiente ao ser aplicada em uma
seguradora para gerar tais relatórios de fiscalização da área de seguros, além de relatórios
estratégicos que suportem a tomada de decisão.
38
Anexos
Os Quadros 10 a 19 mostram os layouts dos arquivos utilizados neste trabalho conforme a
Circular 360 da SUSEP.
Quadro 10 – Layout do arquivo R_COMP.
#
CAMPO
1
COD_SEG
2
PROCESSO
3
TIPO
4
CLASSE
5
APOLICE
6
ENDOSSO
7
COD_END
8
ITEM
9
COBERTURA
10
UF
11
INICIO_VIG
DESCRIÇÃO
Código da Seguradora - FIP. Exemplo:
08001
Preencher com número do processo
referente ao plano.
Preencher de acordo com a tabela III.
Obs.: O envio desta informação
somente será obrigatório a partir da
remessa de 31 de março de 2004.
Preencher com o respectivo número da
apólice. O número deve estar alinhado
à direita, e completado com zeros à
esquerda
(Ex.:
“00000000000001A1330”).
Preencher com o respectivo número do
endosso. No caso de registro de
apólice, o campo “endosso” deve ser
preenchido
com
o
valor
“0000000000”. O número deve estar
alinhado à direita, e completado com
zeros à esquerda.
Preencher com o código de endosso,
conforme estabelecido na tabela IV.
No caso de registro de apólice,
preencher com o valor 0.
Preencher com o item de identificação
do risco em caso de apólice coletiva.
Caso contrário, preencher com o valor
zeros à esquerda.
preencher com o valor 0.
Preencher com o código da Unidade
Federativa do local do risco. Ex: RJ.
Preencher com a data de início de
vigência da apólice ou do endosso AAAAMMDD.
TIPO
TAMANHO
CASAS
DECIMAIS
C
5
1
C
20
2
N
1
3
N
2
4
C
20
5
C
10
6
N
1
7
C
6
8
N
4
9
C
2
10
C
8
11
39
#
CAMPO
12
FIM_VIG
13
TIPO_FRANQ
14
VAL_FRANQ
15
IMP_SEG
16
PREMIO
17
CORRE
TAGEM
18
PERC_DESC
DESCRIÇÃO
Preencher com a data de término de
vigência da apólice ou do endosso –
AAAAMMDD.
Preencher com o tipo de franquia
contratada, de acordo com o
estabelecido na tabela VI.
Obs.: O envio desta informação
somente será obrigatório a partir da
remessa de 31 de março de 2004.
Preencher com o valor da franquia
contratada, de acordo com o tipo de
franquia informado. Obs.: O envio
desta informação somente será
obrigatório a partir da remessa de 31
de março de 2004.
Preencher com o valor da importância
segurada contratada. Em caso de
registro de endosso de alteração de IS,
o mesmo deve ser preenchido com o
novo valor de IS vigente no período de
endosso.
Preencher com o valor total do prêmio
da apólice ou endosso para a cobertura.
Obs.: O custo de apólice, bem como o
IOF e o adicional de fracionamento
devem ser excluídos.
Preencher com o valor total da
comissão de corretagem. Informação
será por apólice/endosso.
Preencher com percentual total de
desconto concedido em função da
análise do risco. Obs.: O envio desta
informação somente será obrigatório a
partir da remessa de 31 de março de
2004.
TIPO
TAMANHO
CASAS
DECIMAIS
C
8
12
C
1
13
N
9
14
N
11
15
N
9
16
N
7
17
N
5
18
TIPO
TAMANHO
CASAS
DECIMAIS
C
5
-
N
1
0
N
2
0
Quadro 11 – Layout do arquivo S_COMP.
#
CAMPO
1
COD_SEG
2
TIPO
3
CLASSE
DESCRIÇÃO
08001
Obs.: O envio desta informação somente
será obrigatório a partir da remessa de
31 de março de 2004.
40
#
4
5
6
7
8
9
10
11
12
13
CAMPO
DESCRIÇÃO
apólice. O número deve estar alinhado à
APOLICE
direita, e completado com zeros à
esquerda (Ex.:
“00000000000001A1330”).
endosso. No caso de registro de apólice,
o campo “endosso” deve ser preenchido
ENDOSSO
com o valor “0000000000”. O número
deve estar alinhado à direita, e
completado com zeros à esquerda.
do risco em caso de apólice coletiva.
ITEM
“000001”. O número deve estar alinhado
esquerda.
Preencher com o código da cobertura
COBERTURA contratada, de acordo com o código
estabelecido na tabela V.
Preencher com o código da Unidade
UF
Federativa do local do risco. Ex: RJ.
Preencher com o valor total (em R$) da
participação do segurado nos prejuízos.
VAL_
Obs.: O envio desta informação somente
FRANQ
será obrigatório a partir da remessa de
31 de março de 2004.
indenização paga na cobertura. Para o
caso de sinistro avisado e não pago, a
INDENIZ
seguradora deve informar o valor
estimado desta indenização.
Preencher com a data do aviso do
D_AVISO
sinistro AAAAMMDD.
Preencher com a data de liquidação do
sinistro AAAAMMDD. Para o caso de
mais de um pagamento parcial, informar
D_LIQ
a data do primeiro pagamento. Para o
caso de valor estimado, preencher com
“00000000”.
Preencher com a data de ocorrência do
D_OCORR
sinistro – AAAAMMDD.
TIPO
TAMANHO
CASAS
DECIMAIS
C
20
-
C
10
-
C
6
-
N
4
0
C
2
-
N
9
0
N
11
0
C
8
-
C
8
-
C
8
-
41
Quadro 12 – Layout do arquivo AT_MOR.
#
CAMPO
1
COD_EMP
2
REF_INFO
3
PRODUTO
4
COBERTURA
5
DATA_NASC
6
DATA_INGR
7
CPF
DESCRIÇÃO
Código da Seguradora/Entidade - FIP
Exemplo: 08001
Ano de referência da informação –
AAAA
Preencher com os seguintes códigos,
de acordo com o
produto:
PT – Previdência Privada Tradicional
PBL – Plano Gerador de Benefício
Livre (PGBL),
Plano com Atualização Garantida e
Performance
(PAGP) ou Plano com Remuneração
Garantida e
Performance (PRGP)
FGB – Fundo Gerador de Benefício
(FGB)
VGL – Vida Gerador de Benefício
Livre (VGBL),
Vida com Atualização Garantida e
Performance
(VAGP) ou Vida com Remuneração
Garantida e
Performance (VRGP)
VGA – Vida em Grupo –
empregado/empregador
VGB – Vida em Grupo – associações
VGC – Vida em Grupo – clubes de
seguro
de acordo com a
cobertura:
1 – cobertura de morte por qualquer
causa
causa com
indenização adicional por acidente
Preencher com a data de nascimento
do segurado/participante
(AAAAMM)
Preencher com a data de ingresso do
segurado/participante no plano
(AAAAMM)
Preencher com CPF do
segurado/participante (informar
somente os números)
TIPO
TAMANHO
CASAS
DECIMAIS
C
5
-
C
4
-
C
3
-
C
1
-
C
6
-
C
6
-
C
11
-
42
#
CAMPO
8
SEXO
9
VALOR
DESCRIÇÃO
Preencher com o sexo do
segurado/participante (M ou F)
Preencher com o valor total de
contribuição arrecadada/prêmio
direto pelo segurado/participante no
ano de referência
TIPO
TAMANHO
CASAS
DECIMAIS
C
1
-
N
11
0
TIPO
TAMANHO
CASAS
DECIMAIS
C
5
-
C
4
-
C
3
-
C
1
-
Quadro 13 – Layout do arquivo SA_MOR.
#
CAMPO
1
COD_EMP
2
REF_INFO
3
PRODUTO
4
COBERTURA
DESCRIÇÃO
Código da Seguradora/Entidade - FIP
Exemplo: 08001
Ano de referência da informação –
AAAA
de acordo com o
produto:
PT – Previdência Privada Tradicional
PBL – Plano Gerador de Benefício
Livre (PGBL),
Plano com Atualização Garantida e
Performance
(PAGP) ou Plano com Remuneração
Garantida e
Performance (PRGP)
FGB – Fundo Gerador de Benefício
(FGB)
VGL – Vida Gerador de Benefício
Livre (VGBL),
Vida com Atualização Garantida e
Performance
(VAGP) ou Vida com Remuneração
Garantida e
Performance (VRGP)
VGA – Vida em Grupo –
empregado/empregador
VGB – Vida em Grupo – associações
VGC – Vida em Grupo – clubes de
seguro
de acordo com a cobertura:
causa
causa com
indenização adicional por acidente
43
#
CAMPO
5
MOT_
SAIDA
6
DATA_NASC
7
DAT_EVENTO
8
DATA_AVISO
9
CPF
10
SEXO
DESCRIÇÃO
de acordo com o
motivo de saída:
100 – morte natural, incluindo
resgate associado à
morte nos produtos de códigos
PBL/VGL/FGB
200 – morte acidental, exceto por
acidente de
trabalho, incluindo resgate associado
à morte nos
produtos de códigos PBL/VGL/FGB
300 – morte por acidente de trabalho,
incluindo
resgate associado à morte nos
produtos de PBL/VBL/FGB
400 – invalidez por acidente, exceto
por acidente de
trabalho
500 – invalidez por acidente de
trabalho
600 – invalidez por doença, exceto
por doença
profissional
700 – invalidez por doença
profissional
800 – sobrevivência
900 – Cancelamento ou resgate total
não associado à
morte/invalidez
Preencher com a data de nascimento
do segurado/participante
(AAAAMM)
Preencher com a data de ocorrência
do evento (AAAAMM)
Preencher com a data em que o
evento foi avisado à
seguradora/entidade (AAAAMM)
Preencher com CPF do
segurado/participante (informar
somente os números)
Preencher com o sexo do
segurado/participante (M ou F)
TIPO
TAMANHO
CASAS
DECIMAIS
C
3
-
C
6
-
C
6
-
C
6
-
C
11
-
C
1
-
44
Quadro 14 – Layout do arquivo SINAV.
#
CAMPO
DESCRIÇÃO
TIPO
TAMANHO
1
SEQUENCIA
N
10
2
COD_CIA
C
5
2
3
DT_BASE
N
6
3
4
TIPO_MOV
N
2
4
5
COD_RAMO
C
4
5
6
NUM_SIN
C
20
6
7
NUM_APOL
C
20
7
8
NUM_END
C
20
8
9
CPF_SEG
C
14
9
10
QTD_SEG
Sequência numérica no arquivo
Código da Cia. na SUSEP –
corresponde ao código da seguradora
ou resseguradora na SUSEP.
Data Base – corresponde ao mês
referente aos lançamentos das
informações solicitadas. AAAAMM
Tipo de Movimento
201-Aviso de sinistro
204-Reavaliação de sinistro
211-Cancelamento de sinistro
214-Reabertura de sinistro
Código do ramo na SUSEP – Caso o
prêmio da apólice não seja
integralmente contabilizado em um
único ramo, a empresa deverá enviar
um registro para cada ramo
contemplado na apólice, de acordo as
regras previstas no plano de contas.
(Exemplo: apólice do ram)
Número de sinistro avisado –
corresponde ao número dado pela
seguradora à comunicação da
ocorrência de um evento (sinistro) que
o segurado é obrigado a fazer à
seguradora, assim que dele tenha
conhecimento. Inclui o dígito
verificador, se for o caso.
Número da apólice/certificado –
corresponde ao número do contrato do
seguro e deve ser preenchido de
acordo com a legislação vigente,
incluindo o dígito verificador, se for o
caso.
Número do endosso/fatura –
corresponde ao número do documento
que contém a renovação e/ou
alterações contratuais, deve ser
preenchido de acordo com a legislação
vigente, incluindo o dígito verificador,
se for o caso. Caso o tipo de
movimentação for Emissã
CPF/CNPJ do segurado, se a
quantidade de segurados for maior que
1, informar o principal.
Quantidade de segurados.
CASAS
DECIMAIS
1
N
4
10
45
#
CAMPO
11
CPF_BEN
12
QTD_BEN
13
DT_REG
14
DT_AVISO
15
DT_OCOR
16
VR_COS_CED
17
VR_MOV
18
DT_MOV
19
TP_SIN
DESCRIÇÃO
CPF/CNPJ do beneficiário, se a
quantidade de beneficiários for maior
que 1, informar o principal.
Quantidade de Beneficiários.
Data de registro – data em que a
empresa registrou o aviso do segurado.
AAAAMMDD
Data de aviso – data em que o
segurado comunicou a ocorrência do
sinistro. AAAAMMDD
Data de ocorrência do sinistro.
AAAAMMDD
Valor de cosseguro cedido –
corresponde ao total do valor
salvado/ressarcimento em cosseguro
cedido à congêneres.
Valor do movimento – corresponde ao
movimentado no sinistro relativo a
salvado/ressarcimento de acordo com
o tipo de movimento.
Data do movimento – Corresponde a
data em que foi feito o movimento do
salvado/ressarcimento AAAAMMDD
Tipo de sinistro
01-Indenização Administrativa
02-Despesa Administrativa
03-Indenização Judicial
04-Despesa Judicial
TIPO
TAMANHO
CASAS
DECIMAIS
C
15
11
N
4
12
D
8
13
D
8
14
D
8
15
N
16
16
N
16
17
D
8
18
N
2
19
46
Quadro 15 – Layout do arquivo PREMIT.
#
CAMPO
DESCRIÇÃO
TIPO
TAMANHO
1
SEQUENCIA
N
10
2
COD_CIA
C
5
2
3
NUM_PROC
C
20
3
4
DT_BASE
D
6
4
5
TIPO_MOV
N
3
5
6
UF_DEP
C
2
6
7
UF_RISCO
C
54
7
8
COD_RAMO
C
4
8
9
NUM_APOL
Código da Cia. na SUSEP – corresponde
ao código da seguradora ou
resseguradora na SUSEP.
Corresponde ao número do processo na
SUSEP referente ao produto.
informações solicitadas (AAAAMM)
Tipo de Movimento
101-Emissão de Apólice.
102-Endosso de cobrança adicional de
prêmio.
103-Endosso de restituição de prêmio.
104-Cancelamento de Apólice com
restituição de prêmio.
105-Cancelamento de Endosso com
106-Cancelamento de Apólice sem
107-Cancelamento de Endosso sem
108-Endosso sem movimentação de
prêmio.
UF da Dependência ou da Unidade
Emissora – campo referente à Unidade
da Federação onde está localizada a
unidade emissora ou dependência.
UF’S dos locais de risco contidos na
apólice. Esta informação deve ser
gravada em uma lista sem repetição das
UF’S (exemplo: MGRJSP)
prêmio da apólice não seja integralmente
contabilizado em um único ramo, a
empresa deverá enviar um registro para
cada ramo contemplado na apólice, de
acordo as regras previstas no plano de
contas. (Exemplo: apólice do ram)
seguro e deve ser preenchido de acordo
com a legislação vigente, incluindo o
dígito verificador, se for o caso.
CASAS
DECIMAIS
1
C
20
9
47
#
CAMPO
10
NUM_END
11
NUM_PROP
12
DT_PROP
13
CPF_SEG
14
QTD_SEG
15
CPF_TOM
16
QTD_TOM
17
DT_EMIS
18
DT_INI_VIG
19
DT_FIM_VIG
20
PR_EMIT
21
PR_COS_
CED
22
AD_FRAC
23
CUST_APOL
24
IOF
DESCRIÇÃO
que contém a renovação e/ou alterações
contratuais, deve ser preenchido de
caso. Caso o tipo de movimentação for
Emissão
Número da Proposta – corresponde ao
número da proposta que gerou a
apólice/endosso.
Data da Proposta (AAAAMMDD)
CPF/CNPJ do segurado, se a quantidade
de segurados for maior que 1, informar o
principal.
CPF/CNPJ do Tomador do seguro (se
houver). Se a quantidade de tomadores
for maior que 1, informar o principal.
Quantidade de Tomadores.
Data de emissão da apólice/endosso –
data correspondente à emissão da
apólice/endosso. AAAAMMDD
Data de início de vigência do seguro – é
a data correspondente ao início de
vigência constante da apólice/endosso.
AAAAMMDD
Data do fim da vigência do seguro – é a
data correspondente ao fim de vigência
constante da apólice/endosso.
AAAAMMDD
Prêmio emitido – corresponde ao valor
do prêmio emitido (sem os
emolumentos) constante da
apólice/endosso.
Prêmio de cosseguro cedido –
corresponde ao total do valor do prêmio
cedido a congêneres em cosseguro.
Valor do adicional de fracionamento do
seguro – corresponde à parcela do valor
dos juros e taxa de administração
cobrados pelo parcelamento do prêmio
emitido.
Valor do custo da apólice.
Valor do imposto – corresponde ao valor
da IOF
TIPO
TAMANHO
CASAS
DECIMAIS
C
20
10
C
20
11
D
8
12
C
14
13
N
4
14
C
14
15
N
4
16
D
8
17
D
8
18
D
8
19
N
16
20
N
16
21
N
16
22
N
16
23
N
16
24
48
#
CAMPO
25
COMIS
26
COMIS_
COSS
27
PRO_LAB
28
CPF_ESTIP
29
IS
DESCRIÇÃO
Valor da comissão de corretagem do
seguro – corresponde ao valor total da
comissão e agenciamento referente ao
prêmio emitido.
Valor da comissão do cosseguro
(cedido) – corresponde ao total do valor
da comissão referente ao prêmio cedido
em cosseguro.
Valor do pro labore a ser pago –
corresponde ao valor a ser pago pelo
gerenciamento do seguro quando
pactuado.
CPF/CNPJ do Estipulante (se houver).
Valor da maior IS para cobertura de um
risco isolado.
TIPO
TAMANHO
CASAS
DECIMAIS
N
16
25
N
16
26
N
16
27
C
14
28
N
16
29
Quadro 16 – Layout do arquivo SINPAG.
#
CAMPO
DESCRIÇÃO
TIPO
TAMANHO
1
SEQUENCIA
N
10
2
COD_CIA
C
5
-
3
DT_BASE
N
6
-
4
TIPO_MOV
N
2
0
5
COD_RAMO
C
4
-
6
NUM_SIN
ao código da seguradora ou
resseguradora na SUSEP.
informações solicitadas. AAAAMM
Tipo de Movimento
207-indenização parcial
208-indenização total
Número de sinistro avisado –
corresponde ao número dado pela
seguradora à comunicação da ocorrência
de um evento (sinistro) que o segurado é
obrigado a fazer à seguradora, assim que
dele tenha conhecimento. Inclui o dígito
CASAS
DECIMAIS
0
C
20
-
49
#
CAMPO
7
NUM_APOL
8
NUM_END
9
CPF_SEG
10
QTD_SEG
11
CPF_BEN
12
QTD_BEN
13
DT_REG
14
DT_AVISO
15
DT_OCOR
16
VR_
COS_CED
17
VR_MOV
18
DT_MOV
19
TP_SIN
DESCRIÇÃO
que contém a renovação e/ou alterações
contratuais, deve ser preenchido de
caso. Caso o tipo de movimentação seja
Emissão de apólice, preencher este
campo com zeros na sua totalidade.
principal.
quantidade de beneficiários for maior
que 1, informar o principal.
Data de registro – data em que a
empresa registrou o aviso do segurado
(AAAAMMDD).
Data de aviso – data em que o segurado
comunicou a ocorrência do sinistro
(AAAAMMDD).
Data de ocorrência do sinistro
(AAAAMMDD).
Valor de cosseguro cedido –
corresponde ao total do valor
salvado/ressarcimento em cosseguro
cedido à congêneres.
Valor do movimento – corresponde ao
movimentado no sinistro relativo a
salvado/ressarcimento de acordo com o
tipo de movimento.
Data do movimento – Corresponde a
data em que foi feito o movimento do
salvado/ressarcimento AAAAMMDD
Tipo de sinistro
04-Despesa Judicial
TIPO
TAMANHO
CASAS
DECIMAIS
C
20
-
C
20
-
C
14
-
N
4
0
C
15
-
N
4
0
D
8
-
D
8
-
D
8
-
N
16
2
N
16
2
D
8
-
N
2
-
50
#
CAMPO
20
TIPO_REC
21
NUM_BAN_S
EG
22
NUM_AGE_S
EG
23
NUM_CON_S
EG
24
NUM_TRAN
SACAO
25
NUM_BAN
26
NUM_AGE
27
NUM_CON
DESCRIÇÃO
1-Dinheiro, 2-Cheques, 3-Créd. Conta,
4-Bem reposto
Número do Banco onde a seguradora
possui conta (somente para pagamento
em cheque ou crédito em conta), caso
contrário, preencher com zeros.
Número da agência onde a seguradora
Número da conta onde a seguradora
Número do cheque, ou crédito em conta
Número do Banco do segurado, caso
pagamento em cheque, caso contrário,
preencher com zeros.
Número da agência do segurado, caso
preencher com espaços.
Número da conta do segurado, caso
preencher com espaços.
TIPO
TAMANHO
CASAS
DECIMAIS
N
1
-
N
4
-
C
5
-
C
20
-
C
20
-
N
4
-
C
5
-
C
20
-
Quadro 17 – layout do arquivo SINPEND.
#
CAMPO
DESCRIÇÃO
TIPO
TAMANHO
1
SEQUENCIA
N
10
2
COD_CIA
C
5
-
3
DT_BASE
N
6
-
4
TIPO_MOV
N
2
0
5
COD_RAMO
ao código da seguradora ou resseguradora
na SUSEP.
Data Base – corresponde ao mês referente
aos lançamentos das informações
solicitadas (AAAAMM)
O último tipo de movimento registrado no
sinistro de acordo com a tabela de tipos de
movimento.
CASAS
DECIMAIS
0
C
4
-
51
#
6
7
CAMPO
NUM_SIN
NUM_APOL
8
NUM_END
9
CPF_SEG
10
QTD_SEG
11
CPF_BEN
12
QTD_BEN
13
DT_REG
14
DT_AVISO
15
DT_OCOR
16
VR_COS_
CED
17
VR_PENDEN
TE
18
VR_TOT
DESCRIÇÃO
TIPO
TAMANHO
Número de sinistro avisado – corresponde
ao número dado pela seguradora à
comunicação da ocorrência de um evento
(sinistro) que o segurado é obrigado a
fazer à seguradora, assim que dele tenha
conhecimento. Inclui o dígito verificador,
se for o caso.
Número do endosso/fatura – corresponde
ao número do documento que contém a
renovação e/ou alterações contratuais,
deve ser preenchido de acordo com a
legislação vigente, incluindo o dígito
principal.
quantidade de beneficiários for maior que
1, informar o principal.
Data de registro – data em que a empresa
registrou o aviso do segurado
(AAAAMMDD)
Data de aviso – data em que o segurado
comunicou a ocorrência do sinistro
(AAAAMMDD).
Data de ocorrência do sinistro
(AAAAMMDD).
Valor de cosseguro cedido – corresponde
ao valor de cosseguro cedido a
congêneres.
Valor pendente de pagamento –
corresponde ao valor pendente de
pagamento do sinistro.
Valor total do sinistro – corresponde ao
valor total do sinistro, ou seja, o que já foi
pago mais o que ainda está pendente
C
20
CASAS
DECIMAIS
-
C
20
-
C
20
-
C
14
-
N
C
4
15
0
-
N
D
4
8
0
-
D
8
-
D
8
-
N
16
2
N
16
2
N
16
2
52
#
19
CAMPO
TP_SIN
DESCRIÇÃO
Tipo de sinistro
04-Despesa Judicial
TIPO
TAMANHO
CASAS
DECIMAIS
-
N
2
TIPO
TAMANHO
CASAS
DECIMAIS
C
5
-
C
20
-
C
10
-
C
1
-
C
6
-
C
1
-
C
1
-
C
1
-
Quadro 18 – Layout do arquivo R_AUTO.
#
CAMPO
1
COD_SEG
2
APOLICE
3
ENDOSSO
4
COD_END
5
ITEM
6
TIPO_PES
7
MODALIDADE
8
TIPO_PROD
DESCRIÇÃO
08001
esquerda (Ex.:
00000000000001A1330”).
preenchido com o valor
zeros à esquerda.
conforme estabelecido na tabela VII.
preencher com o valor “0”.
do veículo em caso de apólice coletiva.
zeros à esquerda.
Preencher com a letra correspondente
ao tipo de pessoa. Exemplo: Física (F)
e Jurídica (J).
Preencher com o código
correspondente à modalidade.
Exemplo: VMR - Valor de Mercado
Referenciado (1), VR - Valor
Determinado (2), Produtos com uma
única cobertura de RCF (3) e seguro
popular (4)
correspondente ao tipo de produto.
Exemplo: Padrão (1) e Perfil (2).
53
#
CAMPO
9
COBERTURA
10
COD_MODELO
11
ANO_MODELO
12
COD_TARIF
13
REGIAO
14
COD_CONT
15
TIPO_FRANQ
16
VAL_FRANQ
17
PERC_FATOR
18
TAB_REF
19
IS_CASCO
DESCRIÇÃO
Preencher com o tipo de cobertura
contratada, de acordo com o código
estabelecido na tabela III.
Preencher com o código do modelo do
veículo na tabela FIPE (ver tabela IX).
Caso o modelo não exista na tabela
FIPE, deve ser preenchido com
“999999-9”.
Preencher com o ano do modelo do
veículo (AAAA).
Preencher com o código de categoria
tarifária em que o veículo se enquadra,
conforme estabelecido no Anexo IV.
Preencher com o código da região de
risco, conforme estabelecido na tabela
VIII.
Preencher com o código do tipo de
contrato de seguro:
1 – para valor de mercado referenciado
(V. M. R.),
2 – para valor definido (V. D.).
Preencher com o tipo de franquia
contratada, de acordo com o
estabelecido na tabela VI.
Preencher com o valor da franquia
contratada, em valor monetário.
Preencher com o percentual de ajuste
aplicado ao valor do veículo na tabela
de referência.
Preencher com a tabela de veículos
utilizada:
Exemplo: Molicar (1), FIPE (2), Jornal
do carro (3), Outras (4). No caso de
VD, preencher com “0”.
segurada contratada para cobertura de
casco. Em caso de registro de endosso
de alteração de IS, o mesmo deve ser
preenchido com o novo valor de IS
vigente no período de endosso. No
caso de VMR, preencher com o valor
da
TIPO
TAMANHO
CASAS
DECIMAIS
C
1
-
C
8
-
C
4
-
C
4
-
C
2
-
C
1
-
C
1
-
N
6
0
N
5
2
C
1
-
N
7
0
54
#
CAMPO
20
IS_RCDMAT
21
IS_RCDC
22
IS_RCDMOR
23
IS_APP_MA
24
IS_APP_IPA
DESCRIÇÃO
TIPO
TAMANHO
responsabilidade civil facultativa de
veículos – danos materiais. Em caso de
endosso
veículos – danos corporais. Em caso de
endosso.
veículos – danos morais. Em caso de
endosso
acidentes pessoais de passageiros –
Morte Acidental. Em caso de registro
de endosso de alteração de IS, o
mesmo deve ser preenchido com o
endosso.
Invalidez Permanente por Acidente.
Em caso de registro de endosso de
alteração de IS, o mesmo deve ser
vigente no período de endosso.
N
7
CASAS
DECIMAIS
0
N
7
0
N
7
0
N
7
0
N
7
0
55
#
CAMPO
25
IS_APP_DMH
26
PRE_CASCO
27
PRE_CAS_CO
28
PRE_RCDMAT
29
PRE_RCDC
30
PRE_RCDMOR
DESCRIÇÃO
Despesas Médico-Hospitalares. Em
caso de registro de endosso de
alteração de IS, o mesmo deve ser
vigente no período do endosso.
emitido para cobertura de casco.
devem ser excluídos. Entende-se por
prêmio emitido o valor emitido direto
pela Seguradora, constante da apólice,
sem dedução de cosseguro e/ou
resseguro cedido.
cedido em cosseguro da cobertura de
casco.
emitido para cobertura de
veículos – danos materiais.
veículos – danos corporais.
veículos – danos morais. Obs.: O custo
de apólice, bem como o IOF e o
adicional de fracionamento devem ser
excluídos.
TIPO
TAMANHO
CASAS
DECIMAIS
N
7
0
N
6
0
N
6
0
N
6
0
N
6
0
N
6
0
56
#
CAMPO
31
PRE_APP_MA
32
PRE_APP_IA
33
PRE_APP_DM
34
PRE_OUTROS
35
INICIO_VIG
36
FIM_VIG
37
PERC_BONUS
38
CLAS_BONUS
39
PERC_CORR
DESCRIÇÃO
emitido para cobertura de acidentes
pessoais de passageiros – Morte
Acidental.
pessoais de passageiros – Invalidez
Permanente por Acidente.
pessoais de passageiros – Despesas
Médico-Hospitalares.
Preencher com o valor do prêmio
emitido para as coberturas de
acessórios, equipamentos, carrocerias e
outras coberturas, as quais são
contabilizadas no ramo 31 do FIP, tais
como assistência 24 horas, carro
reserva etc.. Obs.: O custo de apólice,
bem como o IOF e o adicional de
fracionamento devem ser excluídos
Preencher com a data de início de
vigência da apólice ou do endosso AAAAMMDD.
Preencher com a data de término de
vigência da apólice – AAAAMMDD.
Deve ser preenchido com o percentual
de desconto por não ocorrência de
sinistro de casco, incidente sobre o
prêmio total. Caso o Segurado não
tenha direito ao bônus, preencher com
“00”.
Deve ser preenchido com a classe de
desconto por não ocorrência de sinistro
de casco. Caso o Segurado não tenha
direito ao bônus, preencher com “0”.
Preencher com o valor percentual da
comissão de corretagem.
TIPO
TAMANHO
CASAS
DECIMAIS
N
7
0
N
7
0
N
7
0
N
6
0
C
8
-
C
8
-
N
2
0
C
1
-
N
5
2
57
#
CAMPO
DESCRIÇÃO
TIPO
TAMANHO
CASAS
DECIMAIS
C
1
-
C
8
-
N
3
-
C
1
-
C
8
-
C
8
-
ao sexo do condutor utilizado para
taxação.
Exemplo: Masculino (M); Feminino
(F).
40
SEXO
41
DATA_NASC
42
TEMPO_HAB
43
UTILIZACAO
44
CEP_UTIL
45
CEP_PER
No caso de produto do tipo Perfil, este
campo deverá ser obrigatoriamente
preenchido com os códigos acima,
caso contrário, este campo poderá ser
preenchido com ‘0’, na eventualidade
da seguradora não possuir esse dado.
Data de Nascimento do condutor
utilizado para taxação
(AAAAMMDD). No caso de produto
do tipo Perfil, este campo deverá ser
obrigatoriamente com uma data válida,
caso contrário, este campo poderá ser
preenchido com ‘00000000’, na
eventualidade da seguradora
Preencher com o tempo de habilitação
do condutor utilizado para taxação, em
número de meses. No caso de a
seguradora não possuir esse dado,
preencher com ‘0’.
Preencher com o código de utilização
do veículo, conforme estabelecido na
tabela X. No caso de a seguradora não
possuir esse dado, preencher com ‘0’.
Código de Endereçamento Postal da
utilização do veículo. No caso de
produto do tipo Perfil, este campo
deverá ser obrigatoriamente
preenchido com um CEP válido, caso
contrário, este campo poderá ser
preenchido com ‘00000000’.
localidade de pernoite do veículo. No
caso de produto do tipo Perfil, este
eventualidade
58
Quadro 19 – Layout do arquivo S_AUTO.
#
CAMPO
1
COD_SEG
2
APOLICE
3
ENDOSSO
4
ITEM
5
MODALIDADE
6
TIPO_PROD
7
COBERTURA
8
COD_MODELO
9
ANO_MODELO
10
COD_TARIF
11
REGIAO
DESCRIÇÃO
08001.
esquerda
(Ex.:“00000000000001A1330”).
preenchido com o valor 0000000000”.
O número deve estar alinhado à direita,
e completado com zeros à esquerda.
do veículo em caso de apólice coletiva.
zeros à esquerda.
correspondente à modalidade.
Exemplo: VMR - Valor de Mercado
Referenciado (1), VR - Valor
Determinado (2), Produtos com uma
única cobertura de RCF (3) e seguro
popular (4).
correspondente ao tipo de produto.
Exemplo: Padrão (1) e Perfil (2).
Preencher com o tipo de cobertura
contratada, de acordo com o código
estabelecido na tabela III.
Preencher com o código do modelo do
veículo na tabela FIPE (ver tabela IX).
Caso o modelo não exista na tabela
FIPE, deve ser preenchido com
“999999-9”.
Preencher com o ano do modelo do
veículo – AAAA.
Preencher com o código da categoria
tarifária em que o veículo se enquadra,
Preencher com o código da região de
risco, conforme estabelecido na tabela
VIII.
TIPO
TAMANHO
CASAS
DECIMAIS
C
5
-
C
20
-
C
10
-
C
6
-
C
1
-
C
1
-
C
1
-
C
8
-
C
4
-
C
3
-
C
2
-
59
#
CAMPO
12
COD_CONT
13
EVENTO
14
INDENIZ
15
VAL_SALVAD
16
D_SALVADO
17
VAL_RESS
18
D_RESS
19
D_AVI
20
D_LIQ
21
D_OCORR
22
CAUSA
DESCRIÇÃO
Preencher com o código do tipo de
contrato de seguro:
1 – para valor de mercado referenciado
(V. M. R.), 2 – para valor definido (V.
D.).
Preencher com o código de sinistro de
acordo com a tabela XI.
indenização efetivamente paga ao
segurado, de acordo com o evento
informado, sem desconto de cosseguro
e/ou resseguro. Para o caso de sinistro
avisado e não pago, a seguradora deve
informar o valor estimado desta
indenização.
Preencher com o valor do salvado.
Preencher com a data de recuperação
do salvado, referente ao sinistro
gerador do registro – AAAAMMDD.
Caso não haja informação para este
campo, preencher com “00000000”.
Preencher com o valor do
ressarcimento.
Preencher com a data de recuperação
do ressarcimento, referente ao sinistro
gerador do registro (AAAAMMDD).
Caso não haja informação para este
campo, preencher com “00000000”.
Preencher com a data do aviso do
sinistro, de acordo com o evento
informado (AAAAMMDD). Caso não
haja informação para este campo,
preencher com “00000000”.
Preencher com a data de liquidação do
sinistro, de acordo com o evento
informado (AAAAMMDD). Obs.: Em
caso de valor estimado, preencher com
“00000000”.
Preencher com a data de ocorrência do
sinistro (AAAAMMDD).
Preencher com o código da causa
geradora do sinistro, conforme
estabelecido na tabela V.
TIPO
TAMANHO
CASAS
DECIMAIS
C
1
-
C
1
-
N
7
-
N
6
-
C
8
-
N
6
-
C
8
-
C
8
-
C
8
-
C
8
-
C
1
-
60
#
CAMPO
23
SEXO
24
D_NASC
25
CEP
DESCRIÇÃO
ao sexo do condutor sinistrado.
Exemplo: Masculino (M); Feminino
(F). No caso de produto do tipo Perfil,
este campo deverá ser
obrigatoriamente preenchido com os
códigos acima, caso contrário, este
campo poderá ser preenchido com
‘0’, na eventualidade da seguradora
não possuir esse dado.
Data de Nascimento do condutor
sinistrado – AAAAMMDD. No caso
de produto do tipo Perfil, este campo
deverá ser obrigatoriamente
preenchido com uma data válida, caso
eventualidade da seguradora não
possuir esse dado.
localidade de ocorrência do sinistro.
No caso de produto do tipo Perfil, este
eventualidade da seguradora não
possuir esse dado.
TIPO
TAMANHO
CASAS
DECIMAIS
C
1
-
C
8
-
C
8
-
REFERÊNCIAS
CONFITEC. GEPRO: Gestão de Provisões e Registros Oficiais. Disponível em:
<http://www.confitec.com.br/landings/gepro.php>. Acesso em: 27 set. 2015
COREON.
Produtos
/
CORE-SUS.
Disponível
<http://www.coreon.com.br/index.php/produtos/core-sus>. Acesso em: 27 set. 2015
em:
ESPINOSA, Rudolfo. D’ORDS: Dimensional Operational Reporting Data Store. 29 mai.
2009.
Disponível
em:
<http://www.informationmanagement.com/infodirect/2009_125/business_intelligence_operational_data_store_dords_repo
rting_dimensional-10015534-1.html>. Acesso em: 17 out. 2015.
FILHO,
Ly
Freitas.
Data
Warehouse.
<http://slideplayer.com.br/slide/1248078/>. Acesso em: 26 set. 2015.
Disponível
em:
61
GARTNER. Business Intelligence (BI). Disponível
glossary/business-intelligence-bi>. Acesso em: 26 set. 2015.
em:
<http://www.gartner.com/it-
INMON, William H. ODS Types. 1 jan. 2000. Disponível em: <http://www.informationmanagement.com/issues/20000101/1749-1.html>. Acesso em: 20 mar. 2015.
INMON, William H. The Operational Data Store. 1 jul. 1998. Disponível em:
<http://www.information-management.com/issues/19980701/469-1.html>. Acesso em: 20 mar.
2015.
ITG.
Soluções
/
Mercado
Segurador.
Disponível
<http://www.itg.com.br/solucoes/mercado-segurador>. Acesso em: 27 set. 2015
em:
KELLEY, Chuck, BARBUSINSKI, Les. Is it wrong to build a billing application off the
ODS?
4
ago.
2005.
Disponível
em:
<http://www.informationmanagement.com/news/ask_the_experts/-1034382-1.html>. Acesso em: 3 out. 2015.
KELLEY, Chuck, TANNENBAUM, Adrienne. Do you see the ODS and the DW blending into
a single data store? 2 jan. 2007. Disponível em: <http://www.informationmanagement.com/news/ask_the_experts/-1072737-1.html>. Acesso em: 3 out. 2015.
LEÃO, José Valdoberto. [IBTA BI-21] ideia de trabalho de TCC - DW X SUSEP. [mensagem
pessoal]. Mensagem recebida por leandromd @ gmail.com em 2 jun. 2015
MACHADO, Felipe Nery Rodrigues. Tecnologia e Projeto de Data Warehouse. 6. ed. São
Paulo: Érica, 2013.
MACHADO, Felipe Nery Rodrigues; ABREU, Maurício. Projeto de Banco de Dados: Uma
Visão Prática. 11. ed. São Paulo: Érica, 2004.
MOSS, Larissa. How will an ODS make the lives of business users and IT technicians easier?
2 mai. 2005. Disponível em: <http://www.information-management.com/news/ask_the_experts/1027079-1.html>. Acesso em: 3 out. 2015.
NORRIS-MONTANARI, Joyce. Oh Where, Oh Where, Did the ODS Go? 1 mar. 2007.
Disponível em: <http://www.information-management.com/issues/20070301/1076524-1.html>.
Acesso em: 3 out. 2015.
OLIVEIRA, Mário; FRISCHTAK, Ricardo; RAMIREZ, Milton; BELTRÃO, Kaizô; PINHEIRO,
Sonoe. Tábuas Biométricas de Mortalidade e Sobrevivência - Experiência do Mercado
Segurador Brasileiro - 2010. Rio de Janeiro: Escola Nacional de Seguros - Funenseg, 2012.
Disponível
em:
<http://www.atuarios.org.br/docs/eventos/palestra/Livro_Tabuas_Portugues.pdf>. Acesso em: 26
set. 2015.
62
SCHROECK, Michael J. ODS: The Cornerstone of Information Integration. 1 jan. 2001.
Disponível em: <http://www.information-management.com/issues/20010101/2923-1.html>.
Acesso em: 3 out. 2015.
SHERMAN, Rick. ODS Redux, Part 1. 1 jun. 2005. Disponível em: <http://www.informationmanagement.com/issues/20050601/1028744-1.html>. Acesso em: 3 out. 2015.
SUSEP.
A
Origem
dos
Seguros
Compreensivos.
Disponível
em:
<http://www.susep.gov.br/setores-susep/cgpro/coseb/Seguros_Compreensivos.pdf>. Acesso em:
8 mar. 2015
SUSEP. Apresentação. Disponível em: <http://www.susep.gov.br/menu/a-susep/apresentacao>.
Acesso em: 8 mar. 2015
SUSEP.
Circular
SUSEP
No
360.
Disponível
em:
<http://www.susep.gov.br/textos/circ360.pdf/view?searchterm=seguradoras>. Acesso em: 8 mar.
2015
TUDO SOBRE SEGUROS. Entenda o Seguro de Vida. Disponível em:
<http://www.tudosobreseguros.org.br/sws/portal/pagina.php?l=178>. Acesso em: 17 out. 2015.
TUDO
SOBRE
SEGUROS.
Fundamentos
do
Seguro.
Disponível
em:
<http://www.tudosobreseguros.org.br/sws/portal/pagina.php?l=266>. Acesso em: 26 set. 2015.
TURBAN, Efraim; SHARDA, Ramesh; ARONSON, Jay; KING, David. Business Intelligence:
Um Enfoque Gerencial para a Inteligência do Negócio. Porto Alegre: Bookman, 2009.
63

Baixar este arquivo PDF - Revista Científica Phronesis

Transcrição

Documentos relacionados

endosso do ramo de rcta-c

Declaração do procurador - Prevenção à Lavagem de Dinheiro

PC - AP Premiado - Home Sancor Seguros Brasil

PC - Vida Mulher - Home Sancor Seguros Brasil

Nunca vou me machucar ou adoecer.

RESOLUÇÃO CNSP Nº 14, DE 17 FEVEREIRO DE 2000. Dispõe

apólice apólice de seguro 10.834475 maritima

coface do brasil seguros de crédito interno sa

A lagartinha comilona

Apólice com vigência: 27/02/2016 a 27/02/2017 (Seguradora