O BI é eficiente para relatórios SUSEP?

Estive um tempo longe do blog ocupado fazendo, entre outra coisas, o TCC do MBA de BI.

Eis aqui o meu artigo (enquanto ele não é publicado em algum lugar mais acadêmico e/ou profissional - também publicado no revista virtual da faculdade neste link). Espero que ele seja útil a quem for trabalhar com o assunto.

Abraços e até breve.

Leandro M.D.

nov15

"Livro é sobremesa: tem que ser posto debaixo do nariz do freguês." (Monteiro Lobato)
np - New Model Army - Space

ANÁLISE DA EFICIÊNCIA DE UMA SOLUÇÃO DE BUSINESS INTELLIGENCE APLICADA EM UMA SEGURADORA PARA GERAR RELATÓRIOS REGULATÓRIOS

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 trabalho é 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. Mas 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, e, como ela 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.

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 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.

Revisão de 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.

1 DEFINIÇÕES

A seguir, os termos técnicos utilizados na exposição deste artigo.

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)

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.

1.3 Operational Data Store

Um Operational Data Store (ODS), como o próprio nome diz, trata-se 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).

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).

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.

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).

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.

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.

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.

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.

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)

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).

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.

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

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)

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	Assunto	Periodicidade	Data limite de envio
V	Elaboração e Atualização Periódica de Tábua Biométrica – Previdência Privada Aberta, VGBL e Vida em Grupo	Anual	31 de julho
VI	Seguros Compreensivos	Anual	31 de Março
VIII	Registros contábeis auxiliares obrigatórios em meio magnético	Mensal	5 (cinco) dias úteis após o pedido da SUSEP
IX	Seguro de Automóveis, RCF-V e APP	Semestral	31 de Março e 30 de Setembro

Fonte: SUSEP, Circular nº 360

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.

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.

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.

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)

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.

2 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 FIGURA 2.

FIGURA 2 – Arquitetura de tecnologia de BI

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.

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 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.

Material e Métodos

A seguir, os materiais e métodos utilizados para o desenvolvimento da pesquisa deste trabalho, bem como os processos utilizados na investigação.

3 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.

3.1 Especificação da Amostra (Material)

Abaixo estão especificadas origem, forma e natureza de cada uma das amostras estudadas (sistema de origem de dados e relatórios da SUSEP).

3.1.1 Sistema de Origem (OLTP)

Neste trabalho estã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.

E 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.

FIGURA 5 – modelo relacional representando as tabelas de prêmios do sistema transacional

FIGURA 6 – modelo relacional representando as tabelas de sinistros do sistema transacional

3.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 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	Arquivo	Assunto
V - Tábua Biométrica	AT_MOR.DBF	Segurados/participantes ativos que possuem planos com a cobertura de morte
V - Tábua Biométrica	SA_MOR.DBF	Saídas de segurados/participantes ativos que possuem planos com a cobertura de morte.
VI - Seguros Compreensivos	R_COMP.DBF	Dados estatísticos dos seguros compreensivos (apólices vigentes)
VI - Seguros Compreensivos	S_COMP.DBF	Dados estatísticos dos seguros compreensivos (sinistros avisados)
VIII - Registros contábeis	PREMIT.DBF	Arquivo de registro de emissão.
VIII - Registros contábeis	SINAV.DBF	Arquivo de registro de sinistros avisados e reavaliados, relativos à emissão própria.
VIII - Registros contábeis	SINPAG.DBF	Arquivo de registro de sinistros pendentes de pagamento, relativos à emissão própria.
VIII - Registros contábeis	SINPEND.DBF	Arquivo de registro de sinistros pendentes de pagamento, relativos à emissão própria.
IX - Seguro de Automóveis	R_AUTO.DBF	Dados estatísticos da carteira de automóveis (apólices vigentes)
IX - Seguro de Automóveis	S_AUTO.DBF	Dados estatísticos da carteira de automóveis (sinistros avisados)

Fonte: SUSEP, Circular nº 360

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, 8, 9 e 10 apresentam as estruturas dos arquivos DBF selecionados importados para o Access.

FIGURA 7 – modelo relacional representando as tabelas R_COMP e S_COMP

FIGURA 8 – modelo relacional representando as tabelas PREMIT, SINPAG, SINAV e SINPEND

FIGURA 9 – modelo relacional representando as tabelas AT_MOR e SA_MOR

FIGURA 10 – modelo relacional representando as tabelas R_AUTO e S_AUTO

Dada a grande quantidade de campos envolvidos na seleção de tabelas SUSEP acima, 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.

3.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.

3.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.

3.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.

3.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.

FIGURA 11 – modelo estrela representando os dados de prêmios do DW

FIGURA 12 – modelo estrela representando os dados de sinistros do DW

3.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.

3.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, 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.

3.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)

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.

FIGURA 14 – exemplo de dados carregados na camada DW (tabela fato de prêmios)

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)

3.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, 5, 6 e 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	Descrição	Tabela/Campo DW	Tabela/Campo ODS
PRODUTO	Produto	Dim_Produto/ cod_Prod_Circ_360_V	x
COBERTURA	Cobertura	Dim_Cobertura/ cod_Cob_Circ_360_V	x
DATA_NASC	Data de nascimento	Dim_Segurado/ Data_Nascimento	x
DATA_INGR	Data de ingresso no plano	x	TB_APOLICE/ dt_Inicio_Vigencia_ Apolice ou TB_APOLICE/ dt_Inicio_Vigencia_ Endosso
CPF	CPF do segurado	Dim_Segurado/ Doc_Segurado	x
SEXO	Sexo do segurado	Dim_Segurado/ Sexo	x
VALOR	Valor do prêmio	Fato_Premio/ Val_Premio_Emitido	x

Quadro 4 – Cruzamento entre a tabela SA_MOR e as tabelas do DW e ODS                            

Campo SUSEP	Descrição	Tabela/Campo DW	Tabela/Campo ODS
PRODUTO	Produto	Dim_Produto/ cod_Prod_Circ_360_V	x
COBERTURA	Cobertura	Dim_Cobertura/ cod_Cob_Circ_360_V	x
MOT_SAIDA	Motivo de Saída	Dim_Cobertura/ cod_Motivo_Circ_360_V	x
DATA_NASC	Data de nascimento	Dim_Segurado/ Data_Nascimento	x
DAT_EVENTO	Data de ocorrência	Fato_Sinistro/ id_Tempo_Ocorrencia	x
DATA_AVISO	Data do aviso	Fato_Sinistro/ id_Tempo_Aviso	x
CPF	CPF do segurado	Dim_Segurado/ Doc_Segurado	x
SEXO	Sexo do segurado	Dim_Segurado/ Sexo	x

Quadro 5 – Cruzamento entre a tabela R_COMP e as tabelas do DW e ODS                             

Campo SUSEP	Descrição	Tabela/Campo DW	Tabela/Campo ODS
PROCESSO	Número do processo	Dim_Produto/ Num_Processo	x
TIPO	Tipo	Dim_Produto/ cod_Tipo_Circ_360_VI	x
CLASSE	Classe	Dim_Produto/ cod_Classe_Circ_360_VI	x
APOLICE	Número da apólice	Dim_Produto/ Num_Apolice ou Dim_Segurado/ Num_Apolice	x
ENDOSSO	Número do endosso	x	TB_APOLICE/ Endosso
COD_END	Código de endosso	Dim_Tipo_Endosso/ cod_End_Circ_360_VI	x
ITEM	Item de identificação	x	TB_APOLICE/ Item
COBERTURA	Cobertura	Dim_Cobertura/ cod_Cob_Circ_360_VI	x
UF	UF do local do risco	Dim_Segurado/ UF	x
INICIO_VIG	Início de vigência	x	TB_APOLICE/ dt_Inicio_Vigencia_ Apolice ou TB_APOLICE/ dt_Inicio_Vigencia_ Endosso
FIM_VIG	Fim de vigência	x	TB_APOLICE/ dt_Fim_Vigencia_ Apolice ou TB_APOLICE/ dt_Fim_Vigencia_ Endosso
VAL_FRANQ	Valor da franquia contratada	x	TB_APOLICE/ Val_Franquia
IMP_SEG	Importância segurada	Fato_Premio/ Val_Importancia_Segurada	x
PREMIO	Valor do prêmio	Fato_Premio/ Val_Premio_Emitido	x

Quadro 6 – Cruzamento entre a tabela S_COMP e as tabelas do DW e ODS                             

Campo SUSEP	Descrição	Tabela/Campo DW	Tabela/Campo ODS
TIPO	Tipo	Dim_Produto/ cod_Tipo_Circ_360_VI	x
CLASSE	Classe	Dim_Produto/ cod_Classe_Circ_360_VI	x
APOLICE	Número da apólice	Dim_Produto/ Num_Apolice ou Dim_Segurado/ Num_Apolice	x
ENDOSSO	Número do endosso	x	TB_APOLICE/ Endosso
ITEM	Item de identificação	x	TB_APOLICE/ Item
COBERTURA	Cobertura	Dim_Cobertura/ cod_Cob_Circ_360_VI	x
UF	UF do local do risco	Dim_Segurado/ UF	x
VAL_FRANQ	Valor da franquia contratada	x	TB_APOLICE/ Val_Franquia
INDENIZ	Valor da indenização paga	Fato_Sinistro/ val_Indenizado	x
D_AVISO	Data do aviso	Fato_Sinistro/ id_Tempo_Aviso	x
D_LIQ	Data da liquidação	Fato_Sinistro/ id_Tempo_Liquidacao	x
D_OCORR	Data de ocorrência	Fato_Sinistro/ id_Tempo_Ocorrencia	x

Quadro 7 – Cruzamento entre a tabela PREMIT e as tabelas do DW e ODS

Campo SUSEP	Descrição	Tabela/Campo DW	Tabela/Campo ODS
NUM_PROC	Número do processo	Dim_Produto/ Num_Processo	x
TIPO_MOV	Tipo de movimento	Dim_Tipo_Endosso/ cod_End_Circ_360_VIII_Pre	x
UF_DEP	UF da dependência ou unidade Emissora	Dim_Segurado/ UF	x
COD_RAMO	Código do ramo na SUSEP	Dim_Produto/ Ramo ou Dim_Segurado/ Ramo_Apolice ou Dim_Cobertura/ Ramo	x
NUM_APOL	Número da apólice	Dim_Produto/ Num_Apolice ou Dim_Segurado/ Num_Apolice	x
NUM_END	Número do endosso	x	TB_APOLICE/ Endosso
NUM_PROP	Número da proposta	x	TB_APOLICE/ Num_Proposta
DT_PROP	Data da proposta	x	TB_APOLICE/ Dt_Proposta
CPF_SEG	CPF/CNPJ do segurado	Dim_Segurado/ Doc_Segurado	x
QTD_SEG	Quantidade de segurados	Fato_Premio/ quant_Segurados	x
CPF_TOM	CPF/CNPJ do tomador	x	Não mapeado no ODS, assume-se que se encontra em outra parte do OLTP.
QTD_TOM	Quantidade de tomadores	x	Não mapeado no ODS, assume-se que se encontra em outra parte do OLTP.
DT_EMIS	Data de emissão		TB_APOLICE/ dt_Emissao_ Apolice ou TB_APOLICE/ dt_Emissao_ Endosso
DT_INI_VIG	Data de início de vigência		TB_APOLICE/ dt_Inicio_Vigencia_ Apolice ou TB_APOLICE/ dt_Inicio_Vigencia_ Endosso
DT_FIM_VIG	Data de fim de vigência		TB_APOLICE/ dt_Fim_Vigencia_ Apolice ou TB_APOLICE/ dt_Fim_Vigencia_ Endosso
PR_EMIT	Prêmio emitido	Fato_Premio/ val_Premio_Emitido	x
PR_COS_CED	Prêmio do cosseguro cedido	Fato_Premio/ val_Premio_Cosseguro_ Cedido	x
AD_FRAC	Valor do adicional de fracionamento	Fato_Premio/ val_Adicional_ Fracionamento	x
CUST_APOL	Custo da apólice	Fato_Premio/ val_Custo_Apolice	x
IOF	Imposto sobre operações financeiras	Fato_Premio/ val_IOF	x
COMIS	Comissão de corretagem	Fato_Premio/ val_Comissao_Corretagem	x
COMIS_COSS	Comissão do cosseguro cedido	X	Não mapeado no ODS, assume-se que se encontra em outra parte do OLTP.
PRO_LAB	Pró-labore a ser pago	Fato_Premio/ val_Pro_Labore	x
CPF_ESTIP	CPF/CNPJ do estipulante	X	Não mapeado no ODS, assume-se que se encontra em outra parte do OLTP.
IS	Importância segurada	Fato_Premio/ val_Importancia_Segurada	x

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 acima 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. E 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	Necessidade de buscar informações fora do DW	Quantidade de campos que requerem dados fora do DW
AT_MOR	Sim	1
SA_MOR	Não	0
R_COMP	Sim	5
S_COMP	Sim	3
PREMIT	Sim	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, que 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.

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.

4 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. Mas outros arquivos têm granularidade baixa, ou seja, eles têm 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.

Lembrando 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].

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	DW
Transações similares às de um sistema OLTP.	Consultas processam grande volume de dados.
Contêm dados atuais e quase atuais.	Contém dados históricos.
Tipicamente somente dados detalhados, frequentemente resultando em grande volume de dados.	Contêm dados sumarizados e detalhados, geralmente menores em tamanho do que um ODS.
Carga de dados em tempo real e quase em tempo real.	Tipicamente carga de dados em lote.
Geralmente modelado para suportar atualização rápida de dados.	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 relatórios operacionais.	Usado para tomada de decisões de longo prazo e relatórios gerenciais.
Trabalhadores do conhecimento (representantes do serviço ao cliente, gerentes diretos).	Pessoas estratégicas (executivos, gestores das 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 abaixo de como contemplar uma solução de BI como apoio à geração de dados periódicos de fiscalização:

4.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.

E 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

4.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 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

4.3 Solução de BI expansível

Assim como o modelo anterior, esta arquitetura tem um ODS funcional e não tem um DW. Mas 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. Ou para o 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.

Ou seja, é 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).

FIGURA 18 – Arquitetura de tecnologia de BI parcial (contém um ODS) e ainda sem DW, mas expansível

4.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.

FIGURA 19 – Arquitetura de tecnologia de BI incompleta, com DW, mas sem ODS

4.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.

Ou seja, é 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.

FIGURA 20 – Arquitetura de tecnologia de BI incorreta, com DW refletindo dados transacionais

4.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.

Ou seja, é 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).

FIGURA 21 – Arquitetura de tecnologia de BI inexistente (sem DW nem ODS)

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.

CONCLUSÃO

A solução de BI incompleta, aquela 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 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.

EFFICIENCY ANALYSIS OF A BUSINESS INTELLIGENCE SOLUTION APPLIED ON AN INSURANCE COMPANY IN ORDER TO GENERATE REGULATORY REPORTS

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’s 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 regulator agency. What should be noted 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's really 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 and how 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.

Key-words: Business intelligence. BI. Data warehouse. DW. BI architecture. Operational data store. ODS. Regulatory reports. Brazil Insurance Regulator’s reports. Insurance.

Anexos

As FIGURAS 22 a 34 mostram os layouts dos arquivos utilizados neste trabalho conforme a Circular 360 da SUSEP.

FIGURA 22 – layout do arquivo AT_MOR

Fonte: SUSEP, Circular nº 360

FIGURA 23 – layout do arquivo SA_MOR

Fonte: SUSEP, Circular nº 360

FIGURA 24 – layout do arquivo R_COMP

Fonte: SUSEP, Circular nº 360

FIGURA 25 – layout do arquivo S_COMP

Fonte: SUSEP, Circular nº 360

FIGURA 26 – layout do arquivo PREMIT

Fonte: SUSEP, Circular nº 360

FIGURA 27 – layout do arquivo SINAV

Fonte: SUSEP, Circular nº 360

FIGURA 28 – layout do arquivo SINPAG

Fonte: SUSEP, Circular nº 360

FIGURA 29 – layout do arquivo SINPEND

Fonte: SUSEP, Circular nº 360

FIGURA 30 – layout do arquivo R_AUTO (parte um de três)

Fonte: SUSEP, Circular nº 360

FIGURA 31 – layout do arquivo R_AUTO (parte dois de três)

Fonte: SUSEP, Circular nº 360

FIGURA 32 – layout do arquivo R_AUTO (parte três de três)

Fonte: SUSEP, Circular nº 360

FIGURA 33 – layout do arquivo S_AUTO (parte um de dois)

Fonte: SUSEP, Circular nº 360

FIGURA 34 – layout do arquivo S_AUTO (parte dois de dois)

Fonte: SUSEP, Circular nº 360

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 em: http://www.coreon.com.br/index.php/produtos/core-sus. Acesso em: 27 set. 2015

ESPINOSA, Rudolfo. D’ORDS: Dimensional Operational Reporting Data Store. 29 mai. 2009. Disponível em: http://www.information-management.com/infodirect/2009_125/business_intelligence_operational_data_store_dords_reporting_dimensional-10015534-1.html. Acesso em: 17 out. 2015.

FILHO, Ly Freitas. Data Warehouse. Disponível em: http://slideplayer.com.br/slide/1248078/. Acesso em: 26 set. 2015.

GARTNER. Business Intelligence (BI). Disponível em: http://www.gartner.com/it-glossary/business-intelligence-bi. Acesso em: 26 set. 2015.

INMON, William H. ODS Types. 1 jan. 2000. Disponível em: http://www.information-management.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 em: http://www.itg.com.br/solucoes/mercado-segurador. Acesso em: 27 set. 2015

KELLEY, Chuck, BARBUSINSKI, Les. Is it wrong to build a billing application off the ODS? 4 ago. 2005. Disponível em: http://www.information-management.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.information-management.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 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.

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.information-management.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.