UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO UM MODELO DE DATA MART PARA ÁREA DE MARKETING DE UMA OPERADORA DE PLANOS DE SAÚDE Área de Sistemas de Informação por Tiago Zaccaron Pazeto Luiz Eduardo Perfeito Nunes, M.Sc Orientador Jean Carlos Raduenz, Bel. Co-orientador São José (SC), dezembro de 2010

2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO UM MODELO DE DATA MART PARA ÁREA DE MARKETING DE UMA OPERADORA DE PLANOS DE SAÚDE Área de Sistemas de Informação por Tiago Zaccaron Pazeto Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Luiz Eduardo Perfeito Nunes, M.Sc Co-orientador: Jean Carlos Raduenz, Bel. São José (SC), dezembro de 2010

3 SUMÁRIO LISTA DE ABREVIATURAS... iv LISTA DE FIGURAS... v LISTA DE TABELAS... vi RESUMO... vii ABSTRACT... viii 1 INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA EMPRESA MARKETING BUSINESS INTELLIGENCE (BI) DATA WAREHOUSE (DW) DATA MART (DM) Modelo Top-Down Modelo Bottom-up Granularidade OLAP (On-Line Analytical Processing) Cubo ETL (Extract, Transform and Load) QlikView SISTEMAS SIMILARES DESENVOLVIMENTO EMPRESA Área de Marketing da Operadora de Planos de Saúde Fontes de Informações Regras de Negócio DESCRIÇÃO DO PROBLEMA MODELAGEM IMPLEMENTAÇÃO DAS REGRAS DE NEGÓCIO E SEUS SCRIPTS TESTES E VALIDAÇÃO ii

4 3.6 UTILIZAÇÃO DA FERRAMENTA E RESULTADOS ALCANÇADOS CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS iii

5 LISTA DE ABREVIATURAS BD BI CADSUS DBMS DM DW DTS EDW EQIE ETL ETC HOLAP MOLAP OLAP OLTP SAD SGBD ROLAP TCC TI UNIVALI Banco de Dados Business Intelligence Cadastramento Nacional de Usuários do Sistema Único de Saúde Database Management System Data Mart Data Warehouse Data Transformation Service Enterprise Data Warehouse Equipe de Informações Estratégicas Extract, Transform and Load Extração, Transformação e Carga Hybrid On-Line Analytical Processing Multidimensional On-Line Analytical Processing On-line Analytical Processing On-Line Transaction Processing Sistema de Apoio à Decisão Sistemas de Gerenciamento de Banco de Dados Relational On-Line Analytical Processing Trabalho de Conclusão de Curso Tecnologia da Informação Universidade do Vale do Itajaí iv

6 LISTA DE FIGURAS Figura 1. Arquitetura da tecnologia de BI Figura 2. Data Warehouse orientado a assunto Figura 3. Integração dos dados Figura 4. Variação no tempo Figura 5. Dados dinâmicos x dados estáticos Figura 6. As estruturas de dados e sua utilização dentro da corporação Figura 7. Modelo Top-down Figura 8. Modelo Bottom-up Figura 9. Cubo Figura 10. Modelo Estrela Figura 11. Modelo SnowFlake Figura 12. Estrutura OLAP na visão geral da arquitetura DW Figura 13. Processo ETL Figura 14. Exemplo do QlikView Figura 15. Tela QlikView ETL Figura 16. Organograma da Operadora de Planos de Saúde Figura 17. Modelagem das tabelas Fato e Dimensões Figura 18. Modelagem Flocos de Neve Figura 19. Tela Filtros de Clientes Figura 20. Tela de Filtros de Endereços Figura 21. Informações do cadastro dos clientes Figura 22. Informações de endereços dos clientes Figura 23. Receita x Utilização Figura 24. Gráfico Motivo de Exclusão Figura 25. Alta Utilização Figura 26. Quantidade de Vidas Figura 27. Gráfico por Faixa Etária Figura 28. Fluxograma do Processo para coletar informações v

7 LISTA DE TABELAS Tabela 1. Comparativo entre Data Warehouse e Data Mart Tabela 2. Vantagens e desvantagens da abordagem top-down Tabela 3. Vantagens e desvantagens da abordagem buttom-up Tabela 4. Dados Operacionais comparados com Dados de um DW Tabela 5. Descrição da tabela FATO_CLIENTES Tabela 6. Descrição da tabela DIM_RECEITA Tabela 7. Descrição da tabela DIM_UTILIZACAO Tabela 8. Descrição da tabela DIM_PROCEDIMENTO Tabela 9. Descrição da tabela DIM_CLIENTES Tabela 10. Descrição da tabela DIM_MEDICOS Tabela 11. Descrição da tabela DIM_TEMPO vi

8 RESUMO PAZETO, Tiago Zaccaron. Um modelo de Data Mart para área de Marketing de uma Operadora de Planos de Saúde. São José, nº 69 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, São José, A competitividade nas empresas está cada vez mais acirrada, para que uma empresa possa tomar decisões cada vez mais rápidas e corretas, ela precisa obter informações de maneira rápida e clara, caso contrário, uma decisão errada poderá afetar drasticamente seus resultados. Este trabalho objetiva a criação de um modelo de Data Mart (DM) para agilizar a busca por informações para área de Marketing de uma Operadora de Planos de Saúde, para análise e fornecimento de informações para apoio a tomada de decisões de maneira mais rápida, clara e segura, que a utilizada atualmente, sem que seja necessária a busca intensa por planilhas eletrônicas, relatórios solicitados a outras áreas da empresa e o envolvimento da área de Tecnologia da Informação (TI) a cada nova demanda, pois estes relatórios precisam ser validados, sem contar com o tempo para criá-los. Após a conclusão deste trabalho, a área de Marketing não precisa mais aguardar de dois a trinta dias para receber a solicitação de um relatório, pois com as visões desenvolvidas, a mesma pode extrair informações em alguns minutos, ou seja, quase que instantaneamente. Além do ganho no tempo, também consegue extrair informações não pensadas anteriormente, possibilitando novas ações no departamento. Palavras-chave: Marketing; Data Mart; QlikView; Operadora de Planos de Saúde. vii

9 ABSTRACT The competitiveness in business are becoming more intense, that a company can make decisions faster and more accurate, it needs to obtain information quickly and clearly, otherwise, a wrong decision can dramatically affect your results. This work aims to create a model of Data Mart (DM) to speed the search for information on the marketing area of a Provider of Health Insurance for review and providing information to support decision-making faster, clear and safe, that we currently use, without requiring the massive search for spreadsheets, reports requested in other areas of the company and the involvement of the area of Information Technology (IT) to each new demand, as these reports need to be validated without have the time to create them. Upon completion of this work, the marketing area no longer need to wait two to thirty days to receive the request for a report as to the visions developed, it can extract information in a few minutes, or almost instantly. Besides the gain in time, also can extract information not previously thought, opening up new shares in the department. Keywords: Marketing, Data Mart, QlikView; Provider of Health Insurance. viii

10 1 INTRODUÇÃO O uso da área de Marketing para gerar um diferencial competitivo tem sido uma crescente entre tantas outras áreas do mercado, pois ela faz a divulgação da marca, promover os produtos que serão comercializados em sua área de abrangência, assim como a parte de comunição em jornais, revistas, etc., entre outras funções que fazem parte do Marketing. Hoje já se pode perceber que existem vários tipos/aplicações de Marketing, do tradicional ao dirigido. Por exemplo, a Coca-Cola é direcionada a todas as pessoas, porém um plano de saúde para viagens internacionais é direcionado a um grupo específico de pessoas. No entanto, para fazer o Marketing de um produto ou empresa qualquer, normalmente envolve obter informações que podem ser encontradas nas mais variadas fontes de dados (repositórios) que vão desde o tradicional (anotações em papel), aos utilizados por softwares (Banco de Dados - BD). A área de Marketing da Operadora de Planos de Saúde em questão toma suas decisões com base em planilhas eletrônicas, documentos de texto e relatórios solicitados a outros departamentos da empresa. No entanto, a todo o momento surgem novas solicitações e/ou visões desses relatórios, que demandam novos dados ou de dados já coletados, porém em formato (apresentação) diferente. Existem situações em que os dados estão espalhados ou até mesmo invisíveis, ou talvez num grau de complexidade que pode inviabilizar o seu uso, caso não haja uma ferramenta que auxilie na sua extração e/ou compreensão. Por exemplo, se disser o tempo está bom, no contexto de quem vende guarda chuva ou no contexto de que vende guarda sol, quais dados seriam necessários para avaliar o resultado de vendas de cada cenário. O atual modelo usado na área de Marketing pode ser satisfatório, pois mesmo sem utilizar um sistema de informação para obter informações, como os já citados anteriormente, a área consegue utilizar dados resgatados de planilhas, de textos digitais ou de relatórios solicitados a outras áreas. Como se percebe, o uso de tecnologia da informação nesta área pode agregar um valor ainda maior ao trabalho. É sabido que o tempo, a facilidade de acesso, de entendimento, entre outros pontos, dão um maior dinamismo, uma maior facilidade/flexibilidade de uso das informações para a área interessada. Este trabalho se propôs a desenvolver um Data Mart (DM) para tirar proveito da tecnologia da informação, tendo como vantagens a diminuição do tempo, aumento da segurança e a agilidade para obter informações para tomada das decisões, envolvendo o menor número de pessoas possível.

11 Com o uso da nova proposta as informações estariam mapeadas e preparadas, à disposição do usuário para selecionar os dados desejados da maneira que necessitarem (LAUDON & LAUDON, 2007). Conforme Montefusco et al (2008), o DM serve como fonte de dados para as aplicações utilizadas pelos usuários (Front End), assegurando consistência, integração e precisão dos dados. O DM é uma abordagem específica do Data Warehouse (DW), focada em uma área ou departamento. É possível não só obter informações claras e rápidas, mas também associá-las a outros eventos, tais como: faixa etária dos planos de saúde por sexo, ou seja, saber de qual sexo em uma determinada faixa etária tem-se mais clientes ou utilizou-se mais determinado plano; também se pode obter informações para contato com o cliente, usando o seu perfil, por exemplo: telefone, e- mail, endereço, etc.; também é possível saber qual é o cliente em um determinado período que utiliza o plano com uma frequência maior, tudo para que seja possível agir com uma ação preventiva, ou seja, sempre que possível agir de forma proativa para que este cliente diminua a utilização do seu plano. Seguindo os exemplos descritos anteriormente, a área de Marketing pode propor uma campanha de conscientização para evitar o mal uso de determinado produto, orientando o uso correto do mesmo. Esse trabalho está apoiado nos mesmos dados que o gestor utiliza para validá-lo, porém Marketing e gestor vêem os mesmos de forma e formatos diferentes. 1.1 PROBLEMATIZAÇÃO Neste capítulo serão descritas informações referentes ao trabalho, tais como: o problema em questão, objetivos, metodologia e a estrutura do trabalho. Cabe aqui, levantar a diferenciação básica das palavras Dados e Informações, pois em várias partes do texto elas estarão contidas: - Dados: significa os registros nas bases de dados, ou seja, o nome de uma praia ou localização. - Informações: é o agrupamento de vários dados, ou seja, em Florianópolis existem 42 praias. 2

12 1.1.1 Formulação do Problema Hoje a área de Marketing da Operadora de Planos de Saúde consome muito tempo na busca dos dados necessários para obter informações para a tomada de decisão. Esses dados estão contidos em planilhas, documento textual, em outros tipos de arquivo ou em outras áreas, envolvendo a solicitação de relatórios que podem demorar dias para ficarem prontos e ainda precisam ser validados, pois são atos isolados e muitas vezes não repetitivos. Os dados utilizados atualmente não foram pensados/modelados neste sentido, mas sim com enfoque Administrativo e Financeiro. Apesar disso, a empresa tem utilizado esses dados para diversas áreas, desta forma percebeu-se a deficiência para a área de Marketing executar o seu devido trabalho, sem ficar na dependência de tarefas que não são da sua competência. Esta nova maneira de pensar e agir da empresa tem exigido não só da área de Marketing, mas também, da área da Equipe de Informações Estratégicas (EQIE), por causa das solicitações de vários relatórios e consequentemente alocação de recursos para atender a essa demanda, gerando um retrabalho constante, onde sempre há a necessidade de validação Solução Proposta Desenvolver um DM na área de Marketing que auxilie na obtenção de informações para tomada das decisões. Com o uso da nova proposta, as informações estão à disposição dos gestores para selecionar os dados desejados da maneira que necessitarem. 1.2 OBJETIVOS específicos. Nesta seção será descrito o objetivo principal do trabalho, assim como os objetivos Objetivo Geral O objetivo do trabalho é desenvolver um modelo de Data Mart para a área de Marketing de uma Operadora de Planos de Saúde que permita obter informações de maneira mais rápida e prática que a utilizada atualmente, otimizando a tomada de decisões da área de Marketing de forma a melhorar a visualização das informações para desenvolver novas ações na empresa. 3

13 1.2.2 Objetivos Específicos Os objetivos específicos desta pesquisa são: Levantar/ Identificar as necessidades da área de negócio; Projetar as estruturas do Data Mart; Projetar o modelo ETL (Extract, Transform and Load); e Testar e validar a utilização do Data Mart. 1.3 METODOLOGIA Este trabalho foi desenvolvido em seis etapas, que são: estudo, modelagem, desenvolvimento, teste, validação e documentação. A seguir são descritas cada etapa: - Estudo: para desenvolver esta fase, foi efetuado uma fundamentação teórica (pesquisa), dividida em duas subfases. A primeira subfase foi respaldada em livros, artigos, TCC s, na internet, nos sites de busca, ou seja, foram estudados os conceitos de DM, DW, OLAP (On-line Analytical Processing), entre outros. Na segunda subfase foi estudada através de entrevistas a situação atual da área de Marketing da empresa em questão, bem como as suas necessidades. - Modelagem: nesta etapa, a partir do que foi estudado, surgiu a proposta de uma modelagem baseada no modelo Estrela para ser utilizada no desenvolvimento do DM, para suprir as necessidades da área de Marketing/Empresa. - Desenvolvimento: para desenvolver esta fase foi analisado a ferramenta QlikView, onde esta foi utilizada como ferramenta de Front-End para facilitar o acesso do gestor ao modelo proposto na fase de modelagem e que nesta fase foi implementado. - Testes: nesta etapa foi testado o modelo DM desenvolvido, para verificar se existem desconformidades e ou erros, em não existindo divergências, foi desenvolvido uma massa de testes a ser aplicada no modelo, após a sua aprovação pelo desenvolvedor, será solicitada a avaliação do gestor (usar o modelo), passando em ambos os testes, pode-se homologar junto ao usuário final. - Validação: nesta etapa foram utilizados os requisitos levantados junto ao gestor, para validar se as necessidades dos usuários finais foram atingidas. 4

14 - Documentação: durante todo o processo de desenvolvimento foram feitas anotações, para registrar como o trabalho foi desenvolvido, seja dos conceitos estudados ou da parte prática. Nesta fase, os dados levantados nos estudos, na empresa e na visão do desenvolvedor, foram registrados e transcritos segundo o modelo de TCC fornecido pela Universidade do Vale do Itajaí (UNIVALI). Conforme já citado, esta etapa foi composta por duas fases, TCC I e do TCC II, cumprindo com os prazos pré-estabelecidos. 1.4 ESTRUTURA DO TRABALHO Este documento está estruturado em quatro capítulos. O Capítulo 1, Introdução, apresentou detalhes gerais referentes ao trabalho de pesquisa. No Capítulo 2, Fundamentação Teórica, apresentará conceitos da Empresa, Marketing, DW, DM, On-line Analytical Processing (OLAP), Extract, Transform and Load (ETL) e QlikView. O Capítulo 3, Desenvolvimento, apresentará a forma de condução do trabalho, como foi desenvolvido e os resultados apresentados com as visões. O capítulo 4, Conclusão, apresentará as conclusões do acadêmico com base nos resultados obtidos. 5

15 2 FUNDAMENTAÇÃO TEÓRICA Este capítulo apresentará informações da empresa e os conceitos utilizados neste trabalho de pesquisa tais como: Marketing, DW, DM, On-line Analytical Processing (OLAP), Extract, Transform and Load (ETL) e a ferramenta QlikView. 2.1 EMPRESA A Operadora de Planos de Saúde em questão é uma empresa especializada em prestação de serviços na área medico hospitalar, em sua maioria terceirizados. Sua abrangência é de mais de 20 municípios, abrangendo assim a capital do estado e suas proximidades, possui o seu próprio centro de atendimento especializado e de emergência e já analisa a viabilidade para um hospital. É uma empresa de grande porte, que possui dezenas milhares de clientes em sua carteira e para atendê-los com qualidade, trabalha com mais de mil prestadores (hospitais, clínicas, laboratórios, etc.) em sua área de atuação. Os planos de saúde são os seus principais produtos, comercializados por seus funcionários buscando suprir as necessidades de seus clientes. Para conhecer informações adicionais sobre a empresa, ir para a Seção MARKETING O foco deste trabalho é a área de Marketing. Para entender o cliente em foco, será descrito o que é o Marketing. Assim será possível visualizar as respostas para as necessidades da área e suas dificuldades. Kotler (1993 apud BECKER, 2005, p.8), escreve: Marketing é tão básico que não pode ser considerado como uma função isolada. É o negócio inteiro, cujo resultado final depende do ponto de vista do cliente. Desta forma, é possível entender que o Marketing não caminha sozinho dentro das empresas, ele trabalha de forma paralela às outras áreas. Segundo Serrano (2007), Marketing é função única da empresa moderna, e que tem por objetivo conquistar e preservar clientes. Ainda diz que, Marketing é toda atividade dirigida para a satisfação das necessidades e desejos dos clientes, sendo que estes são satisfeitos pela compra de produtos ou serviços. Assim, conhecendo e estudando estas motivações ao consumo, as empresas procuram produzir bens e serviços que atendam ao cliente da melhor forma, ou mostrar produtos que satisfazem uma determinada necessidade dele. Entende-se que reconhecer uma necessidade é

16 uma coisa, mostrar que se tem a solução para ela, é outra. O Marketing se propõe a ser o elo entre estes dois fatos, que a princípio parece simples, mas nem sempre o é. Seguindo a mesma linha de pensamento, Cobra (2001) define Marketing como uma construção de relacionamentos, pois o sucesso das organizações está ligado diretamente na relação entre cliente e empresa, onde o lucro decorre naturalmente desse relacionamento de confiança. Conforme Palmer (2006), Marketing é o processo gerencial que identifica, antecipa e atende, de modo eficiente e rentável, as exigências do cliente. Complementa dizendo que isso acontece, pelo fato de que são os clientes que pagam pelo serviço ou mercadoria que uma empresa produz. De acordo com Almeida (2010), Marketing é a área do conhecimento que engloba todas as atividades referentes às relações de troca. É tão somente entender a necessidade e os anseios dos consumidores e fornecer produtos (bens ou serviços) compatíveis com tais necessidades e anseios. Com base nos conceitos dos autores citados, o Marketing é algo que não pode ser feito de forma isolada, pois é necessário entender o negócio por inteiro, da necessidade do cliente a solução ou vice e versa. O cliente é visto como o centro das atenções numa organização, onde esta irá satisfazê-lo da melhor maneira possível com bens e serviços que se adéquam a sua situação financeira, de modo a suprir suas necessidades. Palmer (2006) diz que o composto de Marketing é uma estrutura conceitual que destaca as principais decisões que gerentes e executivos devem tomar para atender as necessidades dos clientes. Essas ferramentas podem ser utilizadas para desenvolver tanto estratégias de longo prazo como programas táticos de curto prazo. Segundo Kotler (1998), Sistema de Apoio à Decisão de Marketing é um conjunto coordenado de dados, sistemas e ferramentas, pelos quais uma organização reúne e interpreta informações relevantes da empresa e do ambiente, transformando-as em base para a tomada de decisão do Marketing. O autor dá ênfase aos sistemas que organizam informações para tomada de decisão, isto reflete a necessidade da área de Marketing em questão, que hoje não possui nenhum sistema para auxiliar a busca por informações. Como descrito por Palmer (2006) e Kotler (1998), as ferramentas de apoio à decisão ajudam os gestores das empresas na tomada de decisões, trazendo agilidade, segurança e rapidez para que 8

17 não haja perda de tempo em um ambiente operacional. Para que se tenha uma visão do problema é necessário conhecer o cliente. Para saber detalhes sobre a área de Marketing dentro da Operadora de Saúde em questão, ir para a Seção Como já citado neste trabalho, o Marketing, além de divulgar a empresa, auxilia também a trazer novos clientes, chegando a um ponto em que para gerenciar essa gama de clientes necessária a utilização de uma ferramenta que auxilie na tomada de decisão, para isto, serão detalhados a seguir, alguns pontos para se construir esta ferramenta. 2.3 BUSINESS INTELLIGENCE (BI) Sabe-se que o foco do trabalho é um DM para área de Marketing de uma Operadora de Saúde, no entanto, por trabalhar com o Qlikview que é uma ferramenta de BI, esta seção servirá para entender um pouco como funciona a estrutura do conceito de Business Intelligence. BI pode ser entendido como a evolução de Sistemas de Apoio a Decisão (SAD), ou seja, sistema esse que gera relatórios de maneira não rotineira, com ênfase a flexibilidade e a resposta rápida, fazendo uso de tecnologias e metodologias apoiando assim a tomada de decisão (LAUDON & LAUDON, 2004). O conceito de BI pode ser entendido como a utilização de variadas fontes de informação, auxiliando os gestores a definir estratégias de competitividade nos negócios da empresa (BARBIERI, 2001, apud RADUENZ, 2006). Fortulan e Gonçalves Filho (2005, p.59), afirmam que as vantagens do uso de sistemas de BI quando comparados com outros sistemas tradicionais, incluem facilidades de uso, acesso universal às diversas plataformas, possibilidade de configuração para diversos níveis de usuários e capacidade de trabalho com gráficos, sons e vídeos além de textos e números. As vantagens de trabalhar com gráficos, textos e números, são algumas das propostas desse trabalho. Para entender como o BI traz tantas vantagens ao tomador de decisão, vale explicar como é estruturado, para assim compreender por que este conceito ganha cada vez mais espaço nas empresas. O BI utiliza estruturas de armazenamento de dados como: DW e DM e também de tratamento desses dados como: OLAP e Data Mining. Tem como objetivo definir regras e técnicas 9

18 para transformar os dados em informações, atendendo as necessidades dos tomadores de decisões (MORALES, 2010). Figura 1. Arquitetura da tecnologia de BI Fonte: Zero83 (2009). A Figura 1 mostra a estrutura completa de uma ferramenta de Business Intelligence, onde se percebe o processo desde os sistemas utilizados pelos usuários até chegar à ferramenta que dará facilidade ao gestor. Assim, como onde ficam determinados conceitos na estrutura, como: DW, DM, ETL e OLAP, conceitos este que serão apresentados nas próximas seções. Isto demonstra que futuramente o trabalho proposto poderá se tornar uma ferramenta de BI. 2.4 DATA WAREHOUSE (DW) Esta seção irá apresentar o papel do DW para obter um banco de dados agregando valor aos sistemas de informação. Conforme Laudon e Laudon (2004, p.240), DW é um banco de dados que armazena dados correntes e históricos de potencial interesse dos gerentes de toda a empresa. Os dados podem ser originados de sistemas operacionais centrais, sistemas legado, aplicativos de Database Management 10

19 System (DBMS) relacional e de fontes externas, incluindo sites da internet. Eles são copiados para o DW com a frequência desejada, onde são padronizados em um modelo comum e consolidados para que possam ser usados por toda a empresa para análise gerencial e tomada de decisões. Inmon e Hackathorn (1997, p.14) dizem que os dados brutos que entram no DW são oriundos do ambiente operacional não integrado e define DW como uma coleção de dados orientados a assuntos, integrados, variáveis com o tempo, não voláteis, para suporte ao processo gerencial de tomada de decisão. Os autores complementam alguns detalhes a seguir: Orientado por assunto: uma das características mais notáveis do DW é a sua organização em torno dos assuntos da corporação, fazendo com que o projeto seja orientado a dados, como por exemplo: clientes, vendedores, produtos e atividades, conforme mostra a Figura 2 (INMON & HACKTHORN, 1997). Figura 2. Data Warehouse orientado a assunto Fonte: Machado (2000). Integração: esta é a característica mais importante do DW, pois é ela quem completa os dados que podem aparecer de diversas maneiras em diferentes sistemas ou até mesmo em um único sistema. Por exemplo, o campo sexo em um sistema pode ser visto como m ou f, em outro sistema como 0 ou 1, podendo aparecer ainda como masculino ou feminino. Essas variações podem ser notadas em outros campos, como: atributos de medidas (cm, m², jardas, etc.), formato das datas (ddmmyyyy, mmyy, etc.), entre outros, conforme mostra a Figura 3 (INMON & HACKTHORN, 1997). 11

20 Figura 3. Integração dos dados Fonte: Inmon & Hackathorn (1997). Variação no tempo: o DW pode variar no tempo de diversas maneiras. A mais simples é quando os dados representam informações em um amplo período de tempo, cinco a dez anos. Porém, como característica de um bom projeto, as aplicações operacionais possuem um horizonte de tempo pequeno. A segunda maneira é utilizar implícita ou explicitamente, uma data como dia, mês e ano. A terceira maneira é utilizar uma longa série de fotografias, assumindo que estas estejam corretas, não será possível alterá-las, caso contrário, poderá ser corrigida com nova fotografia. A Figura 4 mostra a variância no tempo dos dados do DW (INMON & HACKTHORN, 1997). 12

21 Figura 4. Variação no tempo Fonte: Inmon & Hackathorn (1997). Não volatilidade: esta característica se dá pelo fato de que no DW poderão ocorrer apenas duas operações: a carga inicial e o acesso aos dados, não possibilitando inserções, deleções e alterações diretamente no DW, como acontece no banco de dados do ambiente operacional que são atualizados registro a registro. A Figura 5 mostra as alterações feitas no ambiente operacional, enquanto no DW apresenta apenas duas operações (INMON & HACKTHORN, 1997). Figura 5. Dados dinâmicos x dados estáticos Fonte: Inmon & Hackathorn (1997). Conforme Accorsi (2008), a função principal do DW é o armazenamento de informações de um banco de dados referente a uma ou mais atividades de uma empresa de forma consolidada. Podendo também ser visto como um agrupamento inteligente de dados de uma mesma fonte, como: origem, formato, nomes, tipo de negócio, regras, conexões entre outros, tendo objetivo de trabalho com uma vasta quantidade de dados, principalmente históricos. 13

22 Dias (2009, p.1) diz que DW é um repositório central de dados, históricos e atuais, que podem representar algum valor para os tomadores de decisão dentro de uma organização. Agrupando informações de várias fontes de dados da empresa, tornando possível a análise dos gestores para tomada de decisões. Segundo Back (2010), DW ou armazém de dados é o nome que se dá a uma grande base de dados informacional que tem por objetivo armazenar em um único repositório os dados que foram consolidados, limpos e uniformizados, armazenados em estruturas lógicas dimensionais, possibilitando o seu processamento por ferramentas especiais. O autor anterior ainda define DW como uma base de dados em vários níveis de granularidade, armazenando esses dados em vários graus de relacionamentos, onde os mesmos deverão estar prontos para serem utilizados nas mais diversas formas de consultas. Anzanello (2002) diz que O DW é utilizado para armazenar informações e o OLAP (On- Line Analytic Processing) para recuperá-las, os dois de forma eficiente, onde um depende do outro, resumindo, o OLAP serve para extrair e alavancar totalmente as informações no DW contidas. Assim como o DW, o DM também serve como um repositório de dados e também utilizará uma ferramenta OLAP para recuperá-los. Porém, o DM tem um tamanho menor, de modo a tratar apenas um departamento, enquanto o DW tratará da empresa por completo. 2.5 DATA MART (DM) Os DMs têm o mesmo propósito do DW, no entanto, abrange uma área menor dentro da empresa, atingindo apenas um determinado departamento da empresa, enquanto o DW pode atingir a empresa por completo. Dias (2009) diz que DM é um subconjunto do DW focado em um assunto específico, utiliza um modelo de dados multidimensional, também conhecido como cubo. Já Farina, Meneguzzi e Pires (1999) complementam dizendo que DM é uma forma simplificada de um DW, se concentrando em um único assunto ou área funcional, como vendas, finanças ou Marketing. Dado seu direcionamento a um assunto único, os DM s geralmente utilizam dados de poucas fontes, podendo essas serem sistemas operacionais internos. 14

23 Segundo Dias (2009), DM é uma estrutura de dados para servir as necessidades de análise de um grupo de pessoas, tais como departamento de finanças, recursos humanos, etc. Assim como outros departamentos existentes nas empresas, como o Marketing. Conforme Miyazaki (2009), o objetivo do DM é entregar aos gestores as informações na forma mais precisa e utilizável possível. Os DM s são atualizados frequentemente e destinados a gerenciar uma grande quantidade de dados. De modo geral, pode-se diferenciar o DW do DM da seguinte forma: o DW é uma estrutura corporativa e o DM uma estrutura departamental, conforme mostra a Figura 6 (VIDOTTI, 2001). Figura 6. As estruturas de dados e sua utilização dentro da corporação Fonte: Vidotti (2001). Além da diferença mostrada pela Figura 6, podem ocorrer outras diferenças entre DW e DM referente às suas características particulares, conforme mostra a Tabela 1. Tabela 1. Comparativo entre Data Warehouse e Data Mart DATA WAREHOUSE Corporativo Altamente granular Dados históricos Grandes Volumes de Dados Versatilidade DATA MART Departamental Sumarizado e agregado Dados Recentes Volumes de dados limitados Especificidade Fonte: Vidotti (2001). 15

24 Para Kimball (2007, apud BACK, 2010), o melhor para as empresas é construir vários DMs para depois integrá-los, chegando ao DW, ou seja, deve ser dividido para depois ser conquistado. Já para Inmon (2007, apud BACK, 2010), primeiramente deve-se modelar o DW para toda a empresa e depois dividir e desenvolver os DMs para os departamentos, ou seja, conquistar para dividir. Conforme outros autores, é comum que seja implementado o modelo citado por Kimball, visto as vantagens que serão apresentadas na próxima seção. Os dois modelos citados por Back (2010), dividir para conquistar e conquistar para dividir, são conhecidos como: Bottom-up e Top-down, respectivamente, existindo ainda um outro modelo que seria a união dos dois já comentados, esses modelos serão detalhados a seguir Modelo Top-Down O processo inicia-se na identificação, extração, transformação e carga das bases de dados operacionais para o DW. Após a carga, irão DW servirá os DMs departamentais com os dados. Um projeto desta dimensão, normalmente tem um custo elevado e demanda bastante tempo para implementação, no entanto, ao fim do levantamento inicial, fornecerá uma base de dados integrada e corporativa (MENOLLI, 2004). A Figura 7 mostra como acontece o processo de extração dos dados iniciando pelo OLTP (On-Line Transaction Processing) aplicações às operações do dia-a-dia da organização, passa pela ETL (Extract, Transform and Load), processo que extraí, transforma e carrega os dados, passando pelo DW, até chegar aos Data Marts. OLTP e ETL, que serão descritos com mais detalhes nas seções seguintes. 16

25 Figura 7. Modelo Top-down Fonte: DataPrix (2010). Para Sobral e Souza (2006), DM é um termo usado para uma fração de um DW, de escopo de dados restrito, elaborado para atender especificamente a uma unidade estratégica de negócio, pode-se dizer também que é um subconjunto lógico de um DW completo. A Tabela 2 apresenta as vantagens e desvantagens de utilizar a abordagem top-down. 17

26 Tabela 2. Vantagens e desvantagens da abordagem top-down. Vantagens Herança de arquitetura Todos os DM originados a partir de um DW utilizam a arquitetura e os dados desse DW, permitindo uma fácil manutenção. Visão de empreendimento O DW concentra todos os negócios da empresa, sendo possível, a partir dele, extrair níveis menores de informações. Repositório de metadados centralizado e simples O DW provê um repositório de metadados central para o sistema. Essa centralização permite manutenções mais simples do que aquelas realizadas em múltiplos repositórios. Controle e centralização de regras A arquitetura top-down garante a existência de um único conjunto de aplicações para extração, limpeza e integração dos dados, além de processos centralizados de manutenção e monitoração. Desvantagens Implementação muito longa Os DW são, normalmente, desenvolvidos de modo iterativo por área de assunto, como, por exemplo, vendas, finanças e recursos humanos. Mesmo assim, são necessários, em média, 15 ou mais meses para que a primeira área de assunto entre em produção, dificultando a garantia de apoio político e orçamentário. Alta taxa de risco Não existem garantias para o investimento neste tipo de ambiente. Heranças de cruzamentos funcionais É necessária uma equipe de desenvolvedores e usuários finais altamente capacitados, para avaliar as informações e consultas que garantam à empresa habilidade para sobreviver e prosperar na arena de mudanças de competições políticas, geográficas e organizacionais. Expectativas relacionadas ao ambiente A demora do projeto e a falta de retorno podem induzir expectativas nos usuários. Fonte: Machado (2004). Menolli (2004, p.45) diz que esta proposta se baseia em um DW central, onde todas as decisões sobre as fontes de dados, segurança, estrutura de dados e padrões de dados devem ser analisadas antes de iniciar o desenvolvimento, resultando em um grande trabalho inicial. A próxima seção apresenta o modelo Bottom-up, onde primeiramente cria-se vários DMs para depois uni-los e criar o DW, diferenciando-se do modelo Top-Down. 18

27 2.5.2 Modelo Bottom-up Este modelo é baseado em DMs independentes, os quais irão compor um DW incremental. O desenvolvimento e o retorno são rápidos, porém existe a dificuldade de integrar os metadados, além dos processos de extração e transformação (MENOLLI, 2004). Os metadados são informações com um conjunto de dados, para facilitar o entendimento, são "dados sobre os dados" do DW. A Figura 8 mostra a extração dos dados iniciando pelas aplicações e fontes de dados até chegar ao Data Warehouse. Figura 8. Modelo Bottom-up. Fonte: DataPrix (2010). Machado (2004, apud RADUENZ, 2006, p.75) diz que as novas abordagens baseiam-se neste conceito, pois elas procuram otimizar o processo de desenvolvimento, garantir a consistência dos metadados, facilitar a integração do ambiente e apresentar resultados em tempo mais reduzido. A Tabela 3 apresenta as vantagens e desvantagens de utilizar a abordagem bottom-up. 19

28 Tabela 3. Vantagens e desvantagens da abordagem buttom-up. Vantagens Implementação rápida A construção dos DM é altamente direcionada, permitindo um rápido desenvolvimento. Normalmente, um DM pode ser colocado em produção em um período de seis a nove meses. Retorno rápido A arquitetura baseada em DM com incremento demonstra rapidamente seu valor, permitindo uma base para investimentos adicionais, com um nível mais elevado de confiança. Manutenção do enfoque da equipe Um dos maiores desafios do desenvolvimento de um DW é a manutenção do mesmo enfoque por toda a equipe. A elaboração de DMs incrementais permite que os principais negócios sejam enfocados inicialmente, sem que haja gastos no desenvolvimento de áreas que não são essenciais ao problema. Herança incremental A estratégia de DMs incrementais obriga a entrega de recursos de informação, passo a passo. Isto permite à equipe crescer e aprender, reduzindo os riscos. A avaliação de ferramentas, tecnologias, consultores e vendedores só deve ser realizada Desvantagens Perigo de legamarts Um dos maiores perigos no DW é a criação de DMs independentes. O advento de ferramentas de drag-and-drop facilitou o desenvolvimento de soluções individuais, de acordo com as necessidades da empresa. Estas soluções podem não considerar a arquitetura de forma global. Desta forma, os DMs independentes transformam-se em DMs legados, ou legamarts. Os legamarts dificultam, quando não inviabilizam futuras integrações. Eles são parte do problema e não da solução. Desafio de possuir a visão de empreendimento Durante a construção dos DMs incrementais, é necessário que se mantenha um rígido controle do negócio como um todo. Este controle requer um maior trabalho ao extrair e combinar as fontes individuais do que utilizar um DW. Administrar e coordenar múltiplas equipes e iniciativas Normalmente, esse tipo de arquitetura emprega o desenvolvimento de DM em paralelo. Isto pode conduzir a uma rígida administração, tentando coordenar os esforços e recursos das múltiplas equipes, especialmente nas áreas de regas e semântica empresariais. A maldição de sucesso A arquitetura com DMs incrementais carrega a maldição de sucesso. Nestes casos, os usuários finais do DM encontram-se felizes, querendo mais informação para seus DMs. Ao mesmo tempo, outros usuários de outros DMs aguardam o 20

29 uma vez, a não ser que existam restrições que impeçam o reaproveitamento. incremento de seus DMs. Isto conduz a equipe de DMs a vencer desafios políticos, de recurso e de administração. Fonte: Machado (2004). Com a união dos dois modelos apresentados anteriormente, pode-se dizer que efetuando o planejamento do DW como uma visão macro e após isso, dividi-lo para criar os DMs que devem ser planejados e integrados, construindo assim um DW integrado e incremental, ou seja, a implementação do DW é realizada top-down e no desenvolvimento dos DMs usa-se Bottom-up (MENOLLI, 2004);(RADUENZ, 2006). Sendo assim definidos os modelos de DM, percebe-se que a utilização do modelo Bottom-up é o mais aconselhável, visto que as vantagens referentes a tempo e custo de implantação são mais baixas, satisfazendo os gestores. Independente do modelo que se escolha trabalhar, é necessário definir o nível de granularidade que o DM terá - isto será visto em detalhes a seguir Granularidade O volume dos dados armazenados é afetado pelo nível de granularidade, isso implica no tempo de resposta às consultas feitas pelos usuários. Quanto menor for o nível de granularidade, maior será a quantidade de dados apresentados ao usuário, assim como maior será a quantidade de dados armazenados. Ao contrário disto, quando maior for o nível de granularidade, menor será a quantidade de dados apresentados aos usuários, assim como menor será a quantidade de dados armazenados (CRAMER, 2006). Após os modelos serem definidos e as regras de negócio levantadas, é possível se pensar na modelagem a ser utilizada no processamento analítico das informações, denominado OLAP, o qual será detalhado na próxima seção. 21

30 2.5.4 OLAP (On-Line Analytical Processing) Com base nas pesquisas efetuadas, pode-se dizer que OLAP serve como ferramenta de auxílio aos gestores para analisar as informações apresentadas, de forma a agilizar a tomada de decisões. Para Pinheiro (1999, apud MEIRA & CAZARINI, 2003), OLAP dá a ideia de que os gerentes possam manipular modelos de dados através de suas dimensões, de forma a atender as mudanças que estão ocorrendo em seu segmento de negócio. Dessa forma, os gestores poderão extrair relatórios mais flexíveis. Segundo Raduenz (2006, p.65), OLAP é uma das ferramentas de consulta (front-end) que servem para apresentar respostas aos usuários do DW. Esta tecnologia foi criada devido à necessidade de análises dos dados de forma fácil e flexível, com várias visões do negócio em diversos níveis de detalhes, comparações e tendências. Sistemas OLTP (On-Line Transaction Processing) são quando um usuário de conta corrente efetua saques ou depósitos, pois acessam dados de uma única conta, enquanto que a aplicação OLAP, tem por finalidade agrupar muitos dados para que um gerente de contas bancária possa tomar suas decisões (ANZANELLO, 2002). A Tabela 4 se refere à diferença entre os dados operacionais e dados analíticos, quanto aos requisitos funcionais e desempenho, ou seja, sistemas OLTP e OLAP, respectivamente (VIDOTTI, 2001). Tabela 4. Dados Operacionais comparados com Dados de um DW. Dados Operacionais Baseados em aplicações Detalhados Exatos em relação do momento de acesso Acessados uma unidade por vez Voltados para transações Alta disponibilidade Não contemplam a redundância Estrutura fixa: conteúdos variáveis Pequena quantidade de dados usada em um processo Atendem às necessidades cotidianas Alta probabilidade de acesso Fonte: Adaptado de Centenaro (2003). Dados em um Data Warehouse Baseados em assuntos ou negócios Resumidos ou refinados Representam valores de momentos já decorridos ou instantâneos Acessados um conjunto por vez Voltados para análise Disponibilidade atenuada A redundância não pode ser ignorada Estrutura flexível Grande quantidade de dados usada em um processo Atendem às necessidades gerenciais Baixa, ou modesta probabilidade de acesso 22

31 Conforme Inmon(1997, apud Raduenz, 2006), OLAP é uma categoria da tecnologia de software que permite que, analistas, gerentes e executivos obtenham, de maneira rápida, consistente e interativa, o acesso a uma variedade de visualizações possíveis da informação. Assim pode-se compreender como as estruturas multidimensionais auxiliam no dia-a-dia dos gestores. Os detalhes dessa estrutura serão visto na próxima seção Cubo Para entender melhor como funcionam as estruturas multidimensionais, pode-se comparar a forma que as planilhas usam nas pastas de trabalho ou como os bancos de dados usam tabelas. Essas estruturas são representadas por determinado cubo que facilita o entendimento das dimensões, sendo estes compostos por medidas e N dimensões (PACHECO, 2003), conforme mostra a Figura 9. Figura 9. Cubo Fonte: Pacheco (2003). Como se percebe na Figura 9, cada aresta do gráfico representa uma dimensão e cada célula do cubo representa uma visão diferente para o gestor. A visão multidimensional de dados possibilita vê-los de diferentes pontos de vista (slice and dice), mediante a rotação (pivoting) do cubo e a navegação (drill-up/drill-down) entre os níveis de agregação, onde estes termos serão explicados adiante. Com isso, as informações serão facilmente selecionadas com uma visão global do negócio, possibilitando cálculos e relacionamentos de variáveis de forma simples (RADUENZ, 2006). Drill-down e Drill-up são operações utilizadas para aumentar ou diminuir a granularidade das informações. Pode-se dizer que é uma técnica analítica específica através da qual o usuário navega entre níveis de abrangência de dados a partir do mais resumido (up) para o mais detalhado (down) (CRAMER, 2006). 23

32 Slice and dice, segundo Machado (2000), são operações para realizar navegação por meio dos dados na visualização de um cubo. Esta operação corta uma parte do cubo mantendo a mesma perspectiva de visão dos dados, é como girar o cubo nas mãos. Pivoting segundo Pichiliani (2006) é definido como escolher um ângulo do cubo, por meio da seleção de duas dimensões em torno das quais o cubo agregará a(s) medida(s) dos dados. Ad-hoc, Segundo Oliveira (2002, apud RADUENZ, 2006), é quando o usuário pode gerar consultas de acordo com suas necessidades, e cruzar as informações de uma forma não vista, com métodos que o levam a descoberta daquilo que ele procura. As maneiras de o cubo trabalhar conforme citado anteriormente, como o drill, servem para auxiliar na capacidade de manipular os dados e formas de apresentar as informações com a agilidade que a modelagem multidimensional possui. Conforme Imhoff, Galemmo e Geiger (2003, apud CRAMER, 2006), Modelagem Multidimensional é uma forma de modelagem de dados que acondiciona os dados de acordo com consultas e processos específicos do negócio. Os objetivos são a compreensibilidade dos usuários de negócio e o desempenho de consultas multidimensionais. A seguir serão detalhados dois modelos multidimensionais que são base para modelagem das tabelas. Modelo Star ou Estrela Segundo Machado (2000), o modelo estrela ou star schema é uma estrutura básica de um modelo de dados multidimensional. Essa estrutura possui uma tabela central chamada Fato e um conjunto de tabelas menores denominadas Dimensões, que ficam ao redor da tabela central, conforme é apresentado na Figura 10. Segundo Pichiliani (2006, p.3), para melhorar o desempenho das consultas, teve-se a introdução de um novo conceito em termos de modelagem de dados, que se diferencia do modelo relacional por permitir redundância. 24

33 Figura 10. Modelo Estrela Fonte: adaptado de Cramer (2006). O número de dados armazenados nesse modelo é muito maior que no flocos de neve, sendo este um ponto franco devido a redundância existente (CRAMER, 2006). O modelo flocos de neve é detalhado na próxima seção. Modelo SnowFlake ou Flocos de Neve Este modelo pode ser visto como uma extensão do modelo, no entanto, tem como objetivo principal a normalização das dimensões, (Cramer, 2006). O modelo SnowFlake é de fácil compreensão por desenvolvedores, visto que estão acostumados com sistema OLTP, que aplica as formas normais como em um projeto relacional (MACHADO, 2000). Este modelo também pode ser visto como um modelo de hierarquia, já que as tabelas das Dimensões podem ter relacionamentos com outras dimensões, tornado a organização das tabelas mais complexa (PICHILIANI, 2006), conforme a Figura

34 Figura 11. Modelo SnowFlake Fonte: adaptado de Cramer (2006). Segundo Machado (2000), modelagem multidimensional é uma técnica de geração e visualização de um modelo de dados que descrevem aspectos comuns de negócios, utilizada para sumarizar e reestruturar dados e apresentá-los em visões que suportem a análise dos valores desses dados. Os três elementos básicos são Fatos, Dimensões e Medidas (variáveis). Tabela Fato Fato é tudo que pode ser representado por valores numéricos, sendo estes denominados de métricas ou medidas, (Machado, 2000). Estas métricas são usadas para medir o desempenho do negócio, usando as intersecções com as tabelas de dimensões que se relaciona (KIMBALL, 1998). Anzanello (2002) diz que a tabela de fatos é uma tabela central carregada de forma normalizada, representando as transações com os valores que estão sendo analisados e as chaves estrangeiras das tabelas de dimensão. 26

35 Tabela Dimensão De acordo com Machado (2000), Dimensões são os elementos que estão no contexto de um fato de um assunto de negócios. Dimensão é um nome diferente para determinar um item de dado. As dimensões para fins de análise em um DM devem ser tratadas hierarquicamente. Pichiliani (2006), diz que agrupa os dados relacionados ao negócio. Representam possíveis formas de visualizar os dados, de modo a flexibilizar a manipulação das informações. Complementa dizendo que o Tempo (data) é uma das dimensões mais importantes, pois pode exibir em linha de tempo as ocorrências das consultas. Para uma aplicação OLAP, existem métodos de armazenamento que estão divididos em duas correntes de tecnologia de Sistemas de Gerenciamento de Banco de Dados SGBD (SOBRAL & SOUZA, 2006), cada uma com sua função definida, que devem ser utilizados quando melhor atender as necessidades de análise. São elas: MOLAP (Multidimensional On-Line Analytical Processing) e ROLAP (Relational On-Line Analytical Processing), além da combinação das duas HOLAP (Hybrid On-Line Analytical Processing) (ANZANELLO, 2002). MOLAP: é um conjunto de interfaces de usuário, aplicações e banco de dados, com tecnologia proprietária, que possui características eminentemente dimensionais" (SOBRAL & SOUZA, 2006). ROLAP: os dados são armazenados no modelo relacional como também suas consultas são processadas pelo gerenciador do banco relacional (ANZANELLO, 2002). Ou seja, a consulta é enviada e processada no mesmo servidor de banco de dados, onde se mantém o cubo (RADUENZ, 2006). HOLAP: é a combinação entre ROLAP e MOLAP. A mistura dessas tecnologias traz a vantagem de se extrair a alta performance do MOLAP e a escalabilidade do ROLAP (ANZANELLO, 2002). Esta tecnologia apresenta tanto flexibilidade quanto desempenho (SOBRAL & SOUZA, 2006). A Figura 12 mostra onde exatamente está o OLAP na estrutura de DW e BDs operacionais. 27

36 Figura 12. Estrutura OLAP na visão geral da arquitetura DW Fonte: Raduenz (2006). Para ser possível que uma ferramenta OLAP disponibilize as informações aos gestores, é necessário que seja efetuado o processo ETL (Extract, Transform and Load), que será detalhado na próxima seção ETL (Extract, Transform and Load) Este processo é dividido em três etapas: extração, transformação e carga, sendo responsável pela integridade, qualidade e consolidação das informações extraídas de uma ou mais fontes externas até o armazenamento do DW ou DM (CRAMER, 2006). Traduzindo para o português, é comum usar a sigla ETC (Extração, Transformação e Carga) no lugar de ETL (RADUENZ, 2006). Abreu (2008) diz que ETL é o processo mais crítico e demorado na construção de um DM, pois consiste na extração dos dados de bases irregulares, na transformação e limpeza destes dados e na carga dos dados na base do DM. O processo de ETL de um banco de dados multidimensional é complexo o suficiente para ser considerado o processo mais demorado, isso ocorre devido aos cálculos que são realizados para agregar os dados às dimensões e preencher as estruturas do banco (ANZANELLO, 2002). Esta informação é confirmada por Inmon (2002, apud CRAMER, 2006), "o processo de integração e transformação de dados tipicamente consome até 80% dos recursos de desenvolvimento". A Figura 13 mostra o processo de extração dos sistemas para a base de dados do DM. 28

37 Figura 13. Processo ETL Fonte: ETL-Tools.Info (2010). Existem ferramentas ETL no mercado, tais como: DataStage da IBM, PowerCenter, DTS (Data Transformation Service), dentre várias outras, onde na maioria delas o processo pode ser agendado um horário para execução, garantindo os dados atualizados sem que haja problemas no ambiente de produção. Dentre tantas ferramentas ETL (conforme Apêndice II) para fazer a extração dos dados da base de dados, neste trabalho será utilizado a ferramenta QlikView, que servirá tanto na extração dos dados (ETL) quanto na visualização desses pelos gestores (OLAP) QlikView O QlikView é um software de BI (Business Inteligence) que utiliza uma tecnologia própria para análise de informações relacionais provindas de várias fonte de dados. Este software foi escolhido para ser utilizado como ferramenta front-end que realizará a publicação dos dados para o usuário final. Conforme mostra no Apêndice II, ao comparar o QlikView com outras ferramentas de código proprietário, por exemplo, o SAP Business Object, pode-se perceber que o QlikView permite um fácil manejo e rápido implementação, enquanto o SAP tem sua infraestrutura aberta, onde ambas interagem com o Microsoft Office, sabendo disso, poderia ser utilizado qualquer ferramenta para este trabalho. No entanto, o principal motivo para utilizar a ferramenta QlikView é 29

38 devido ao fato de possuir conhecimentos na mesma e também por esta já estar disseminada em algumas áreas da empresa, onde até o momento a área de Marketing não faz parte desse grupo. A ferramenta possui acesso às mais variadas fontes de dados de aplicativos operacionais, tais como: Oracle, SAP, Salesforce.com; e também bases de dados: SQL Server, MySQL, Oracle e dados locais constantes em planilhas, entre outros. A Figura 14 demonstra exemplo de gráfico e listas que podem ser gerados a partir do QlikView, podendo também criar vários tipos de gráficos, entre outros componentes que irão auxiliar o gestor na tomada de decisão. Figura 14. Exemplo do QlikView Fonte: Elaborado pelo autor. A Figura 14, apresentada anteriormente, mostra o QlikView agindo como ferramenta OLAP, já a Figura 15, apresenta a tela onde serão inseridos os scripts que irão extrair, transformar e carregar os dados da base de dados, dessa forma o QlikView estará agindo como ferramenta ETL. Essa ferramenta pode integrar as ferramentas tradicionais de BI numa única arquitetura, possuindo uma plena integração com o pacote Office da Microsoft (GALICIA, 2009). 30

39 Figura 15. Tela QlikView ETL Fonte: Elaborado pelo autor. Detalhes sobre os requisitos para instalação e os navegadores/celulares suportados pela ferramenta podem ser vistos no Apêndice I. Por este software ser uma ferramenta de BI, este conceito foi apresentado na Seção 2.3. A seguir, serão comentados sistemas similares ao trabalho proposto, tanto com foco no Marketing, quanto em Operadoras de Planos de Saúde, os sistemas que serão descritos a seguir ajudaram os gestores de outras empresas na tomada de decisão. 2.6 SISTEMAS SIMILARES Nesta seção são apresentados alguns sistemas similares ao que será desenvolvido, sistemas estes que estão ligados ao Marketing ou área de saúde, e que utilizam os conceitos de DM ou DW. Meira e Cazarini (2003) escrevem sobre a aplicação de uma ferramenta OLAP/ DM para captar doadores de sangue em um Hemonúcleo. A aplicação teve como objetivo a tomada de decisão na convocação de doadores de sangue e no agendamento de coletas externas. Nesta aplicação, foram criadas duas tabelas Fato, para diferenciar os candidatos à doação e doações que ocorreram, com suas respectivas tabelas de Dimensões. Os autores concluem dizendo que o uso dessas tecnologias na área da saúde é imprescindível, pois uma grande quantidade de dados é 31

40 gerada de diversas fontes, que devem ser tratadas para a utilização dos profissionais da área na tomada de decisão. A ferramenta citada anteriormente é utilizada para obter informações dos usuários que serão convocados para efetuar a retirada de sangue, pois estes serão escolhidos dentre todos os usuários do banco de dados, conforme as regras de negócio definidas. Segundo Dallora et al (2004) uma ferramenta de DM foi desenvolvida para no centro cirúrgico do Hospital das Clínicas da Faculdade de Medicina de Ribeirão Preto. Nesta ferramenta o cubo criado foi composto por especialidade, unidade federativa do pacientes, idade, ano de execução da cirurgia, entre outros dados. Após a carga dos dados foi possível fazer relações como: especialidade versus idade; unidade federativa de procedência do paciente versus especialidade versus ano, entre várias outras correlações. Ainda Dallora et al (2004), informa que com os testes obtidos com o uso dessas ferramentas proporcionaram aos usuários maior agilidade e facilidade de manuseio, velocidade, independência, uma maior visão sobre as informações disponíveis, despertando idéias e possibilidade de novos cruzamentos inicialmente não idealizados. Futuramente, se espera que a abrangência do DM ganhe uma dimensão maior de acordo com as necessidades dos usuários e do surgimento de novos sistemas que serão incorporados como novos DMs de forma a obter o DW corporativo. Seguindo na área de saúde, este exemplo teve como objetivo identificar problemas na grade de horários das cirurgias, assim como os recursos: humanos, materiais, etc. O próximo exemplo visa gerar informações com a flexibilidade de utilizar vários relacionamentos entre as tabelas, auxiliando o tomador de decisão. Kuhnen e Vieira (2004) apresentam um estudo de caso na Unimed de Francisco Beltrão referente à implantação de um DW. O projeto do DW foi construído juntamente com outras duas Unimeds (Londrina e Curitiba), onde foi formado um comitê para definir os modelos e validar os dados, após isso criaram a infraestrutura para armazenar e processar os dados. Na sequência, criaram o modelo de dois DMs, Produção e Usuários, para depois serem liberados no DW, depois houve a validação dos modelos, criação do Banco de Dados e desenvolvimento do processo de carga dos dados, por fim criação o material para auxílio dos usuários e treinamento aos mesmos. 32

41 Ainda Kuhnen e Vieira (2004), descrevem como vantagem do DW os seguintes pontos: 1 relatório com ranking dos clientes com maiores custos ; 2 relatório com quantidade de consulta por usuário ; 3- relatório com consulta que demonstra a quantidade de usuários por faixa etária no Paraná, entre outros relatórios que ajudaram os gestores na tomada de decisão. O exemplo descrito a seguir, fala sobre o Sistema Único de Saúde, que visou obter informações para decidir, qual região ou quais diagnósticos devem ser utilizados em políticas sociais. A DataSus (2010) diz que o sistema CadSus se refere ao Cadastramento Nacional de Usuários do Sistema Único de Saúde, onde este, consiste no processo por meio do qual são identificados os usuários do Sistema Único de Saúde e seus domicílios de residência, com isso será possível a emissão do Cartão Nacional de Saúde para os usuários, assim como a vinculação de cada usuário ao domicílio de residência, isto trará uma maior eficiência na realização das ações de natureza individual e coletiva. O CadSus utiliza um DM para a geração de base de consulta e extração de dados, permite ainda a construção de um banco de dados para diagnóstico, avaliação, planejamento e programação das ações de saúde, assim como a construção de políticas sociais integradas e intersetoriais (educação, trabalho, assistência social, tributos etc.) nos diversos níveis do governo. Saindo da área da saúde e entrando na área de Marketing, o próximo exemplo, descreve um sistema que tem como foco o cliente. Conforme Teradata (2009), a rede Carrefour, maior varejista da Europa, está expandindo seu ambiente de EDW (Enterprise Data Warehouse) da empresa Teradata, com objetivo de suportar análises de negócio dentro do departamento de Marketing. A nova solução permitirá o controle de mais de 14 milhões de famílias, dando ao Carrefour uma visão de 360º em tempo real de seus clientes por uma ampla variedade de canais de contato com o consumidor. Mais de 60 mil categorias de consumidor podem ser gerenciadas pelos profissionais de Marketing do Carrefour, com alto grau de detalhamento. Por exemplo, será possível detectar que determinado cliente fez 50 visitas a qualquer loja Carrefour no período de um ano, ou uma visita por semana, adquirindo em média de 20 a 25 produtos, fazendo seus pagamentos com o cartão de fidelidade Carrefour em 80% das vezes. Assim como o anterior, outro exemplo voltado à área de Marketing é o da VM2 (2006), empresa com ramo no trabalho integrado em consultoria e planejamento estratégico digital, apresenta o serviço de Marketing de Relacionamento. Este serviço que tem foco no cliente é 33

42 utilizado para captação de novos clientes assim como a retenção dos que já existem. O serviço utiliza como base para extração dos dados, o DW, assim como também utiliza o Data Mining para extrair do DW um conjunto de métodos Inteligíveis. 34

43 3 DESENVOLVIMENTO Neste capítulo será apresentada uma descrição da empresa, da área de Marketing e do trabalho, assim como a metodologia de como este foi desenvolvido durante o TCC II, ou seja, até a conclusão deste trabalho. Por fim, foi descrito alguns pontos de risco que poderiam intervir na conclusão do trabalho. 3.1 EMPRESA A Operadora de Planos de Saúde em questão é uma empresa de grande porte, que possui milhares de clientes em sua carteira e para atendê-los com qualidade, trabalha com mais de mil prestadores (hospitais, clínicas, laboratórios, entre outros) em sua área de atuação. A empresa tem como produto principal seus planos de saúde comercializados por seus funcionários buscando suprir as necessidades de seus clientes. Para alcançar suas metas e objetivos, esta empresa tem como missão a satisfação dos clientes e profissionais, conforme descrito a seguir: Missão: "Promover Saúde e Qualidade de Vida, buscando a satisfação dos Clientes e demais Profissionais, com responsabilidade socioambiental". Visão: "Ser reconhecida como empresa de excelência e a melhor promotora de saúde e qualidade de vida". Valores: "Os valores da empresa que constituem seus princípios são: Equidade, Ética, Integridade, Lealdade, Solidariedade e Verdade". Política de Qualidade: "Buscar a satisfação dos clientes através da melhoria contínua dos processos, oferecendo e administrando planos de saúde e serviços com qualidade". Com base nestes objetivos, a empresa apresenta uma estrutura composta por uma hierarquia onde na parte superior está a diretoria executiva, logo abaixo está a diretoria de gestão, seguido de seus gerentes, após estes, estão os supervisores e por fim os funcionários da parte operacional. Como apresentado no exemplo da Figura 1.

44 Figura 16. Organograma da Operadora de Planos de Saúde Fonte: Elaborado pelo autor. A Figura 16 é apenas ilustrativa. Em todas as diretorias existem um ou mais gerentes seguidos de seus supervisores e assim por diante conforme já comentado. Como exemplo, pode-se imaginar que a área de Marketing em uma das caixas Gerente, onde abaixo estão seus respectivos os supervisores divididos em três divisões: Comunicação, Marketing e Produto. Esta área, assim como suas divisões, serão detalhadas na próxima seção Área de Marketing da Operadora de Planos de Saúde Hoje em dia, as empresas dos diversos portes existentes no mercado possuem serviços que se propõem a satisfazer as necessidades dos clientes e como resultado disso, obter sua lucratividade. Na Operadora de Planos de Saúde em questão não é diferente, ela também cria produtos (bens e serviços) de modo a atrair os clientes para suprir suas necessidades. A divisão de Marketing da empresa em questão está divida em três grandes grupos: Comunicação, Produtos e Marketing. É necessário que cada qual cumpra com suas obrigações para que a área alcance suas metas e resultados e por consequência a empresa aos seus anseios. 37

45 A Comunicação é responsável por toda a assessoria de imprensa, ou seja, qualquer matéria divulgada sobre a empresa, em jornais, revistas ou através de outros meio de comunicação, deverá passar por esta divisão, assim como entrevistas com médicos, colaboradores da empresa, entre outros. O grupo Produtos é responsável pela criação e gestão dos planos comercializados. Para criar um novo produto, serão feitas análises de mercados para conhecer as maiores necessidades dos clientes. A gestão dos planos é feita de maneira a acompanhar a quantidade de vidas agregadas a cada novo plano, assim como se a utilização está sendo feita de maneira correta. O Marketing é responsável por qualquer tipo de propaganda como: logotipo, slogan, divulgação em TV, rádio, informativos, panfletos, entre outros, dos mais variados tipos de divulgação e também dos patrocínios. Esta parte da divisão também é responsável pelo orçamento do departamento que é disponibilizado pela empresa. Os três grupos são formados por analistas com conhecimento para administrar da melhor maneira suas atividades, buscando alcançar as metas e resultados da divisão, consequentemente ajudando as da empresa. A missão, visão e negócio desta área serão descritos com mais detalhes a seguir. Como comentado sobre a missão da empresa, agora serão descritos a missão, visão e negócio da área de Marketing, além dos detalhes de como a área age para alcançar suas metas, pois isto auxiliará também a empresa a atingir as metas e resultados. Missão: Desenvolver soluções de Marketing e comunicação em conformidade aos objetivos da empresa, com compromisso social, dentro de princípios éticos, priorizando as metas propostas e buscando a satisfação dos clientes. Visão: Ser o elo entre as metas e os resultados da empresa, integrando os serviços com unidade na identidade de comunicação. Negócio: Atuar na área de comunicação e Marketing de planos de assistência médica e serviços prestados pela Operadora de Planos de Saúde aos seus clientes, bem como desenvolver produtos e serviços que atendam as expectativas da empresa e as necessidades do mercado em que atua. 38

46 No conceito Missão, as soluções são desenvolvidas juntamente com outras áreas, por exemplo: na área de venda poderá ser efetuado um trabalho para atrair novos clientes e/ou clientes que já passaram pela empresa, com o intuito de efetivar um novo plano. Com os novos clientes, a operadora poderá alcançar as metas estabelecidas, assim como os resultados desejados. Para alcançar metas e resultados de forma clara e consciente, é necessário ter boas fontes de informações, as quais estas devem estar num formato de fácil interpretação para que o gestor da área possa não só economizar tempo na tomada de decisão, mas ter segurança nas informações que está recebendo. Hoje em dia, estas informações ainda são obscuras de certa forma, pois não existe na área nenhuma tecnologia que auxilie na busca de informações. Dessa forma, o próximo subcapítulo relata como funciona a busca de informações na área de Marketing Fontes de Informações Toda divisão/departamento de uma empresa qualquer, necessita de informações para gerir suas demandas, assim como tomar decisões corretas para alcançar seus objetivos. Nesta parte do trabalho, será detalhado como a área de Marketing da empresa em questão, busca as suas informações para tomada de decisões. Uma das fontes de informações para a tomada de decisão é a Equipe de Informações Estratégicas (EQIE), que desenvolve os relatórios conforme solicitação dos próprios analistas de Marketing Neste caso eles detalham os objetivos e a necessidade que o relatório deve suprir, assim como os filtros que deverão ser utilizados para confeccionar os scripts para a extração de tal relatório. Os analistas de Marketing também solicitam relatórios a outras áreas da empresa, além da EQIE, tais como: Atendimento ao Cliente, Relacionamento com Empresas, Departamento de Vendas e Divisão de Relacionamento com os Prestadores de Serviço. Para exemplificar, o Marketing solicita ao Relacionamento com Empresas relatórios com informações sobre utilização 1 e a receita 2 que uma ou mais empresas geraram. No entanto, nesses relatórios nem sempre constam informações, em alguns existem apenas dados que deverão ser tratados para virar informações e assim tomar a decisão. 1 Utilização: é o que o usuário utiliza do plano de saúde (consulta, exames, etc.) 2 Receita: é o que o usuário paga pelo plano de saúde contratado 39

47 Laudon (2004) diz que as tecnologias de banco de dados, DW e Data Mining têm funcionado como poderosas ferramentas para profissionais de Marketing, pois capacitam as empresas a unir e analisar os dados de clientes de diversas fontes. Complementa que com esses bancos de dados, os analistas podem identificar os clientes que tem interesse em certos produtos, assim como os altamente lucrativos. Com base na citação anterior, é possível entender o motivo pelo qual um sistema que auxilie os gestores na tomada de decisão é imprescindível, pois o tempo gasto na busca ou espera por relatórios solicitados a outras áreas, é precioso. No entanto para desenvolver uma ferramenta que auxilie os gestores na tomada de decisão, é necessário levantar e entender as regras de negócio, as quais serão descritas a seguir Regras de Negócio As regras de negócio são essenciais para a criação/desenvolvimento de relatórios ou sistemas que auxiliem os gestores na tomada de decisão, são elas: 1. Analisar a utilização dos clientes, que são todos os valores pagos aos médicos pelos atendimentos dos mesmos, seja este uma consulta, exame ou qualquer outra relação entre médico e cliente; 2. Analisar a receita dos clientes/empresas, que são os valores recebidos dos mesmos referentes às suas mensalidades; 3. Clientes que tenham realizado um determinado procedimento (consulta/ exame) em um determinado período deverão aparecer com alerta para utilização; 4. Quantidade de clientes que foram incluídos na base de dados em um determinado período, para saber se esta quantidade está crescendo conforme as metas da empresa; 5. Clientes excluídos, que tiveram suas faturas quitadas e ainda utilizaram o plano, estes clientes deverão ser avaliados, pois poderá ser feito uma ação para tentar trazê-los de volta à empresa; 6. O motivo das exclusões está gravado em uma variável do banco de dados, se esta for preenchida com uma codificação (número) e não em um campo texto (digitado), poderão ser analisados os principais motivos de exclusões, caso contrário não será possível garantir a 40

48 consistência das informações, pois erros de digitação acontecem. Isto servirá para tentar trazer o cliente de volta à empresa. As regras de negócio fazem com que o sistema execute suas operações de forma correta, apresentando dados consistentes e de maneira rápida, no que auxiliará a tomada de decisão. Como apresentado anteriormente, a área de Marketing tem dificuldade para obter as informações em tempo hábil para desenvolver os seus projetos e como conseqüência disso surgem os problemas para tomada de decisões. Para facilitar o entendimento desses eventos e suas consequências, a seguir serão detalhados de maneira mais clara estes problemas. 3.2 DESCRIÇÃO DO PROBLEMA As ferramentas de extração de informações dos bancos de dados estão ganhando um lugar cada vez maior na visão estratégica das empresas, diminuindo o tempo, aumentando a segurança e facilidades para auxiliar os gestores nas tomada de decisões. A área de Marketing da Operadora de Planos de Saúde em questão perdia muito tempo buscando os dados para gerar informações para tomada de decisão. Esta busca pelos dados demanda tempo dos analistas, pois muitas vezes necessitam solicitar relatórios de outras áreas. Os relatórios recebidos podem ser/estar formatados ou não, mas o que realmente interessa é que os mesmos não estão preparados para a sua nova utilização, ou seja, voltados ao negócio da área de Marketing. Para que esses dados possam ser usados no processo de tomada de decisão é necessário todo um preparo e uma validação, e isso demanda tempo do analista de Marketing e o envolvimento de pessoas de diferentes áreas, para que os relatórios fiquem completos e supram as necessidades da área de Marketing. Como visto na seção 2.7, existem sistemas já implantados em outras empresas que realizam o papel de extrair informações para tal área, porém, na área de Marketing desta Operadora de Saúde não há nenhum sistema de informação que auxilie a extração dessas informações para tomada de decisão. 3.3 MODELAGEM Nesta seção estão detalhadas as tabelas de Fato e Dimensão, com base no modelo escolhido para o trabalho, conforme descrito a seguir. 41

49 A modelagem definida para este trabalho foi o modelo estrela, por este se adequar melhor aos projetos de DM - como o trabalho é voltado a uma determinada área da empresa, não será necessário um grande número de dimensões, tornando a granularidade maior, conforme é apresentado na Figura 17. Para criar a modelagem das tabelas Fato e Dimensão foi utilizada a ferramenta Microsoft Visio. Figura 17. Modelagem das tabelas Fato e Dimensões. Fonte: do autor As tabelas Fato e Dimensão apresentadas na Figura 17 estão detalhadas a seguir, juntamente com a descrição de cada campo. A Tabela 5, FATO_CLIENTES, tem como objetivo reunir as informações dos clientes assim como suas receitas (pagamentos) e utilizações. 42

50 Tabela 5. Descrição da tabela FATO_CLIENTES CAMPO COD_CLIENTE COD_UTILIZACAO COD_RECEITA COD_PROCEDIMENTO COD_MEDICO COD_TEMPO MES ANO VL_RECEITA VL_UTILIZACAO QTD_UTILIZACAO FATO_CLIENTES DESCRIÇÃO Código do Cliente Código indicador da Utilização Código indicador da Receita Código de procedimento utilizado Código do médico que prestou serviço Código para dimensão tempo Mês Ano Valor da Receito no Mês/Ano Valor composto pela qtd utilizada x Valor unitário do procedimento Quantidade utilizada no Mês/Ano A Tabela 6, DIM_RECEITA, tem como objetivo apresentar todos os pagamentos que o cliente fez à empresa, esses pagamentos pode ser exemplificado como as mensalidades. Tabela 6. Descrição da tabela DIM_RECEITA CAMPO COD_RECEITA COD_CLIENTE MES ANO VALOR DIM_RECEITA DESCRIÇÃO Código indicador da Receita Código do Cliente Mês que foi efetuado a Receita Ano que foi efetuado a Receita Valor total que o cliente pagou naquele mês A Tabela 7, DIM_UTILIZACAO, tem como objetivo gravar todos os procedimentos que o cliente efetuar, ou seja, serão gravadas as consultas, exames, assim como suas respectivas quantidades. Tabela 7. Descrição da tabela DIM_UTILIZACAO CAMPO COD_UTILIZACAO COD_CLIENTE COD_PROCEDIMENTO MES ANO QTD DIM_UTILIZACAO DESCRIÇÃO Código indicador da Utilização Código do Cliente Código do Procedimento utilizado Mês que foi efetuado a Utilização Ano que foi efetuado a Utilização Qtd utilizada no mês A Tabela 8, DIM_PROCEDIMENTO, tem como objetivo o cadastro dos procedimentos com seus respectivos valores. 43

51 Tabela 8. Descrição da tabela DIM_PROCEDIMENTO CAMPO COD_PROCEDIMENTO NOME_PROCED VALOR DIM_PROCEDIMENTO DESCRIÇÃO Código do Procedimento Nome do Procedimento Valor unitário do Procedimento A Tabela 9, DIM_CLIENTES, possui todo o cadastro de um determinado cliente, como: dados pessoais (nome, CPF, data de nascimento), dados para empresa (número do cartão, situação), assim como dados para contatos (endereços, telefones e ). Tabela 9. Descrição da tabela DIM_CLIENTES CAMPO COD_CLIENTE NUM_CARTAO NOME_CLIENTE CPF DT_NASC SITUACAO TIPO_CLIENTE DT_INCLUSAO DT_EXCLUSAO MOTIVO_EXCLUSAO LOGRADOURO NUM_LOGR COMPLEMENTO BAIRRO CIDADE UF CEP DDD TELEFONE DDD_CELULAR CELULAR DIM_CLIENTES DESCRIÇÃO Código do Cliente Número do cartão do cliente Nome do Cliente Cpf do Cliente Data de Nascimento Situação Atual do cliente Indica o Tipo do Cliente (1 Pessoa Física, 2 Pessoa Juridica) Data de inclusão do cliente na empresa Data de exclusão do cliente Motivo que levou o cliente a ser excluído Nome do Logradouro Número do Logradouro Complemento (se Houver) Bairro Cidade Unidade Federativa CEP DDD telefone residencial Número do Telefone residencial DDD do Celular Número do Celular A Tabela 10, DIM_MEDICOS, possui o cadastro dos médicos que prestam serviços à empresa, ou seja, quem realiza as consultas/ exames dos clientes. Tabela 10. Descrição da tabela DIM_MEDICOS CAMPO COD_MEDICO NOME_MEDICO DIM_MEDICOS DESCRIÇÃO Código do médico que prestou serviço Nome do médico que prestou o serviço 44

52 A Tabela 11, DIM_TEMPO, possui a referência no tempo de carga, onde serão guardados os dados em períodos de tempo, no caso desta tabela, mês e ano. Tabela 11. Descrição da tabela DIM_TEMPO CAMPO COD_TEMPO ANO MES DIM_TEMPO Código para dimensão tempo Ano de referência Mês de referência DESCRIÇÃO Para representar as regras de negócio apresentadas na seção 2.2.3, pode-se pensar em possíveis relacionamentos entre as tabelas descritas anteriormente Fato e Dimensão, conforme descrito a seguir: Regra 1: Para buscar as utilizações dos clientes, a tabela Fato fará os relacionamentos buscando informações das tabelas Dimensão: DIM_TEMPO, DIM_UTILIZACAO, DIM_CLIENTE, DIM_PROCEDIMENTO e DIM_MEDICOS. Regra 2: Para buscar as receitas dos clientes, ou seja, os valores pagos como já descrito anteriormente, a tabela Fato fará os relacionamentos buscando informações das tabelas Dimensão: DIM_TEMPO, DIM_RECEITA e DIM_CLIENTE. Regra 3: Para buscar as quantidades de procedimentos realizados num período, a tabela Fato fará os relacionamentos buscando informações das tabelas Dimensão: DIM_ TEMPO, DIM_UTILIZACAO, DIM_CLIENTES e DIM_PROCEDIMENTOS. Não fará consulta na tabela DIM_MEDICOS, pois para esta regra é relevante apenas a quantidade de procedimentos. Regra 4: Para buscar a quantidade de clientes inclusos na base de dados, a tabela Fato fará relacionamento apenas com a tabela Dimensão: DIM_CLIENTE. Regra 5: Para buscar os clientes excluídos, que tiveram suas faturas quitadas e ainda utilizaram o plano, a tabela Fato fará os relacionamentos buscando informações da tabela Dimensão: DIM_ TEMPO, DIM_CLIENTE, DIM_UTILIZACAO, DIM_RECEITA. Regra 6: esta regra só valerá se o campo no banco de dados for codificado, conforme já apresentado na descrição da regra. Para buscar os principais motivos de exclusões de clientes, a tabela Fato fará relacionamento apenas com a tabela Dimensão: DIM_CLIENTE. 45

53 Com base nos detalhes apresentados nas regras de negócio, serão necessárias uma tabela Fato e seis tabelas Dimensão. O relacionamento entre elas responderá as perguntas que os gestores da área de Marketing precisam para tomada de decisão, perguntas essas referentes às regras de negócio especificadas. Como já comentado, a granularidade utilizada no trabalho foi alta, pois não são necessários detalhes como, por exemplo: em qual data um cliente executou determinado procedimento ou quantos procedimentos esse mesmo cliente executou em um dia. Dessa forma, pode-se pensar em algumas perguntas que a ferramenta responderá, como: quantos procedimentos um cliente fez em um mês ou em um ano, podendo comparar essas informações com o ano anterior, para assim fazer uma análise com informações e não dados analíticos. Conforme já apresentado, optou-se por uma modelagem com base no modelo Estrela (star), pois a princípio responderia de maneira rápida as pesquisas, onde se previu uma tabela Fato e seis tabelas de Dimensão, conforme apresentado na Figura 17, sendo que suas definições estão na seção Essa estrutura foi criada para futuramente receber os dados da base de dados utilizada pelo sistema de gestão da Operadora, onde esses dados serão carregados de forma normalizada e isto ocorrerá durante o desenvolvimento desse trabalho. 46

54 Figura 18. Modelagem Flocos de Neve Fonte: do autor. O modelo Estrela não apresentou os resultados conforme o previsto, ou seja, não estava respondendo de forma satisfatória as necessidades elencadas pelo estudo junto à área de Marketing. Durante os testes efetuados, esta modelagem não respondeu de maneira rápida, demorando nas pesquisas efetuadas, chegando em alguns casos a ocasionar o travamento do computador sem previsão para resposta, esta situação motivou a troca do modelo estrela pelo modelo floco de neve. Para atender o novo modelo foi necessário dividir as tabelas de Dimensão. Após testes efetuados, viu-se que o novo modelo utilizado obteve respostas mais rápidas para as mesmas pesquisas, respondendo de maneira quase que instantânea sem ocasionar travamento. A nova estrutura é apresentada pela Figura 18. Esta alteração ocorreu durante o desenvolvimento, por isso, será mais bem detalhada na próxima seção. 47

55 3.4 IMPLEMENTAÇÃO DAS REGRAS DE NEGÓCIO E SEUS SCRIPTS Para suprir o propósito de todas as regras especificadas no escopo do trabalho, estas tiveram que ser detalhadas com o auxílio de diversos analistas, principalmente o de Marketing, onde estes se reuniram em uma sala para auxiliar na criação das regras, possibilitando assim esclarecer as dúvidas existentes. Necessitou-se de analistas de outras áreas: Faturamento, Contas Médica e Cadastro. As regras foram detalhadas conforme está descrito a seguir. Regra 1: Utilização: são todos os valores pagos aos médicos pelo atendimento dos clientes, seja este uma consulta, exame ou qualquer outra relação entre médico e cliente. Após a conclusão da regra, para se extrair a utilização dos clientes, foi necessário entender o processo do departamento de Contas Médicas, sendo este o responsável por gerar o valor de utilização dos clientes para assim conseguir pesquisar as tabelas e campos necessários para está regra, sendo os passos detalhados a seguir: - primeiramente foi necessário identificar quais tabelas gravam os registros que passam pelo departamento de Contas Médicas; - utilizaram-se todos os procedimentos 3, sendo que estes deveriam estar com valor acima de zero, pois os mesmos poderiam estar com glosa 4, acarretando em valor zerado; e - agruparam-se por meses, as informações dos clientes e dos procedimentos utilizados, somando-se a quantidade utilizada, deixando assim o resultado do script um pouco mais enxuto, ou seja, ao invés de trazer um resultado analítico por completo, trouxe os dados mais agregados, ou seja, a princípio apareceriam dois registros para o cliente Tiago no mês de novembro, em cada registro, ele utilizou uma vez o procedimento 1111, após esse agrupamento, aparecerá que o Tiago utilizou no mês de novembro duas vezes o procedimento Após pesquisar os procedimentos com valor acima de 0 (zero) e agrupá-los pelos meses de utilização, pode-se ter o valor da utilização dos clientes. Passou-se então para a pesquisa da regra 2. Regra 2: Receita: são os valores recebidos dos clientes/empresas referente às suas mensalidades; 3 Procedimento: considera-se uma única consulta, um exame ou um material/medicamento utilizado pelo cliente. 4 Glosa: procedimento não autorizado pela operadora para execução. 48

56 Para chegar ao script final que verifica a receita dos clientes Pessoa Física (PF) ou Pessoa Jurídica (PJ) foi necessário entender o negócio do departamento de Faturamento. Pois é esta área que gera as faturas enviadas aos clientes/ empresas, para assim conseguir pesquisar as tabelas e campos necessários para esta regra, cujos passos serão detalhados a seguir: -primeiramente, o departamento de Faturamento informou que é diferenciada a geração das faturas. Para clientes pessoa física, as faturas são geradas diretamente para a própria pessoa e pessoa jurídica são provenientes do valor total utilizado por seus funcionários; - foi necessário identificar quais tabelas gravam tais registros. Com isso foram criados dois scripts separadamente, pois assim como a geração das faturas, o modo como ficam registrados na base de dados para clientes PF é diferente dos registros para clientes PJ; - identificou-se quais regras deveriam ser utilizadas para cada tipo de fatura (PF e PJ), sendo que o relacionamento entre a fatura e o cliente é diferente nas duas situações; e, - na ferramenta ETL, os registros destes dois scripts foram unidos para melhorar a apresentação da tela desenvolvida para o usuário final. Com os registros de receita formatados foi possível relacioná-los com os registros da regra 1, possibilitando a visualização de um determinado cliente juntamente com sua utilização e receita. Regra 3: Clientes que tenham realizado um determinado procedimento (consulta/ exame) em um prazo de 12 meses, deverão aparecer com alerta para utilização: - depois de criada a regra 1, será possível determinar quais clientes entraram na faixa de alerta quanto a quantidade de procedimentos utilizados. Regra 4: Quantidade de clientes que foram incluídos na base de dados em um determinado período, para saber se esta quantidade está evoluindo conforme as metas da empresa. Para se chegar a esta regra, foi necessário esclarecer com o departamento de Cadastro como deveriam ser consideradas as inclusões de novos clientes. Mesmo que eles existam em um determinado plano, poderiam ter sido migrados de outros, com isso é correto afirmar que estes clientes não são novos em nossa base dados; e - Após possuir a quantidade de clientes inclusos em determinado período, pode-se criar um gráfico para facilitar a visualização do gestor. 49

57 Regra 5: Clientes excluídos, que tiveram suas faturas quitadas e ainda utilizaram o plano, estes clientes deverão ser avaliados, pois poderá ser feita uma ação para tentar trazê-los de volta à empresa: - inicialmente, verificou-se como este tipo de informação estava armazenado no banco de dados. Nesta análise, percebeu-se que existe uma codificação para as exclusões efetuadas e que seria possível selecionar os clientes por um determinado tipo de exclusão; - em seguida, verificou-se quais clientes estavam excluídos; - separou-se os clientes que não haviam sido excluídos por inadimplência 5 ; e, - após, analisou-se quais clientes possuíam utilização baixa do plano. Regra 6: O motivo das exclusões está gravado em uma variável do banco de dados. Se esta for preenchida com uma codificação (número) e não em um campo texto (digitado), poderão ser analisados os principais motivos de exclusões, caso contrário não será possível garantir a consistência das informações, pois erros de digitação acontecem. Isto servirá para tentar trazer o cliente de volta à empresa: - assim como na regra anterior, esta também utilizou os motivos de exclusões para selecionar os clientes; e, - com a primeira análise concluída, foi possível demonstrar os variados tipos de exclusões. As regras descritas anteriormente estão apresentadas em algumas telas na ferramenta criada para o analista de Marketing, onde a visualização desta ferramenta facilita a busca de informações para tomada de decisão. Com as regras de negócio esclarecidas pelo analista de Marketing juntamente com as demais áreas, foi possível dar início a fase de ETL, ou seja, o desenvolvimento dos scripts que farão as extrações dos registros necessários para compor o novo banco de dados. 5 Inadimplência: Cliente com faturas em aberto, ou seja, em atraso. 50

58 Após o desenvolvimento dos scripts que fizeram a extração dos registros das bases de dados, identificou-se alterações na estrutura inicial da modelagem, onde alguns pontos tiveram que ser modificados, pontos estes que serão melhores detalhados mais adiante. Para responder as necessidades da área foram utilizados diversos filtros, além desses, foi preciso incluir no script vários campos para disponibilizar as mais variadas visões. Esses filtros devem estar disponíveis tanto para o cadastro dos clientes quanto para seus endereços. Os filtros possibilitam efetuar uma pesquisa mais detalhada, ou seja, analisar uma quantidade menor de clientes, sendo possível a criação de um produto ou propaganda com determinado foco. Para este script utilizam-se sete tabelas da base de dados, isto foi necessário pelas informações estarem gravadas em locais diferentes. A tela desenvolvida para os filtros de clientes refere-se à Figura 19 na página 66. Já os filtros referentes aos endereços dos clientes servem para a área poder criar pesquisas por localidades, possibilitando saber o número de clientes em uma determinada cidade ou conhecer o de determinado cliente. Para este script, utilizam-se duas tabelas da base de dados. A tela desenvolvida para os filtros de endereços refere-se à Figura 20 na página 67. Nos dois scripts citados anteriormente, existem campos que precisaram ser normalizados, ou seja, transformados de A para Ativo, de E para Excluído e de I para Inativo. Outros campos não necessitaram efetuar tal tratamento, pois existe na base de dados uma codificação específica, porém, por estarem em locais distintos, precisou-se ser criado um vínculo entre eles. Por exemplo, para determinados planos ao invés de aparecer o seu código, aparecerá somente o nome referente a ele, isto foi necessário para melhorar o entendimento no momento de efetuar os filtros. Estas informações estarão a disposição do gestor para utilizar da maneira que lhe convir. Estes dois scripts estão relacionados pelo campo cod_endereco, desta forma quando o analista efetuar filtros na tela de filtros de clientes, ao clicar na tela de endereços, aparecerá os respectivos endereços dos clientes selecionados. Por exemplo, determinada área precisa enviar uma correspondência para alguns clientes, ou saber quais desses clientes possuem para divulgar um produto por meio eletrônico. Estes scripts só puderam ser desenvolvidos após a ajuda da área de Cadastro, que mostrou em quais locais e de que forma as informações estavam gravadas no sistema de gestão, isto auxiliou a pesquisa na base de dados. 51

59 Para confeccionar o script com os contratos, extraiu-se o nome e código de cada contrato, possibilitando o vínculo das tabelas e também a visualização do analista a qual empresa determinado cliente está relacionado. Para desenvolver o script que faria carga da tabela dimensão Tempo, selecionou-se uma tabela da base de dados um campo referente às datas, possuindo mês e ano, utilizando-se de um comando para não haver duplicidades. Esta dimensão se faz necessário para o analista saber de qual período precisa extrair as informações, possibilitando analisar informações atuais com o passado. Para desenvolver o script com as utilizações dos clientes, selecionaram-se registros de cinco tabelas da base de dados. O relacionamento dessas tabelas foi necessário, pois se precisou buscar informações dos procedimentos utilizados pelos clientes. Este script foi concluído com o auxílio da área de Contas Médicas, esta ajuda foi de grande valia para entender como são gravadas as utilizações dos clientes na base de dados. Neste script necessitou selecionar apenas contas que possuíam valor pago maior que 0 (zero), onde os dados foram extraídos de forma mais analítica para ser ajustado na parte front-end da ferramenta, possibilitando responder a regra 1 Utilização dos clientes e também a regra 3 Alta utilização dos clientes. Para selecionar os registros com a receita dos clientes, a qual se refere a regra de negócio 2, foram necessários desenvolver dois scritps, um que buscasse diretamente a receita dos clientes e outro para buscar a receita das empresas, pois estas informações estão gravadas na base de dados de forma distinta. Para os dois scripts foram considerados os grupos de rubricas: Mensalidade 6 e Coparticipação 7. Também será considerado para os dois scritps que as fatura devam ter o campo dt_cancelamento em branco, caso contrário faturas cancelas serão selecionadas. O primeiro script, receita dos clientes, foi desenvolvido buscando diretamente os registros onde estão gravados os valores pagos dos clientes, para isso, tanto o código do cliente, quanto de seu contrato deverá estar preenchido. Já no segundo script, receita das empresas, buscou-se os registros que continham o código do cliente em branco, diferenciando assim os dois tipos de receitas. No entanto, neste último script necessitou-se criar o campo cod_cliente com um valor genérico, pois precisaram ter os mesmos campos. 6 Mensalidade: valor pago pelo plano. 7 Co-participação: percentual do valor utilizado do plano. 52

60 Depois dos dois scripts desenvolvidos, os mesmos foram unidos formando uma única tabela, dessa forma, todas as informações de receita, sejam elas de clientes ou empresas, estavam em um único lugar. Estas informações das receitas dos clientes respondem a regra de negócio 2. Já na visão do gestor, estas informações de valores foram agrupadas por competência e clientes, possibilitando assim a criação da tela Receita x Utilização, facilitando a análise do valor de utilização e receita em uma única tela. Para as regras de negócio de número 1 - Utilização e 2 - Receita, criou-se um relacionamento entre as mesmas, possibilitando criar a tela que mostra todos os clientes com seus respectivos valores para receita e utilização. Dessa forma, deverão aparecer todos os clientes, indiferentemente se tiveram ou não receita e utilização. Na tela desenvolvida para estas regras apresentaram-se os campos: mes_ano, numero_associado, nome_associado, valor_receita e valor_utilizacao. Esta tela é apresentada pela Figura 23 na página 69. Para facilitar a análise dos valores, definiu-se que deverá ser ordenado pelo valor de receita em ordem decrescente, dessa forma é possível analisar os clientes que pagaram suas faturas e utilizaram pouco ou não tiveram utilização de seus planos, podendo assim possibilitar algum brinde para tais clientes, criando um vínculo de fidelização entre eles e a empresa. Para auxiliar a análise do gestor, outra tela foi desenvolvida, a Alerta Alta Utilização, onde as informações contidas na mesma são provenientes do script desenvolvido para regra de negócio 1 - Utilização. Para esta tela as informações foram agrupadas por clientes e procedimentos, somando a quantidade utilizada, isto possibilitou analisar os clientes que estão utilizando muito de um determinado procedimento, com esse novo agrupamento, responde-se a regra de negócio 3 Alta utilização dos clientes, apresentada pela Figura 25 na página 71. Durante a etapa de estudo, verificou-se que existe uma codificação para os motivos de exclusão na base de dados, sendo assim é possível analisar e quantificar os clientes pelos motivos de exclusões, possibilitando a área de criar maneiras para trazer os clientes com determinado tipo de exclusão a empresa novamente. A viabilidade de analisar tais informações responde a regra de negócio 6 Analisar motivos de exclusões. O script para responder a esta regra de negócio foi criado a partir do cadastro dos clientes, onde o registro para tal possui um campo especifico para o motivo de exclusão quando o mesmo estiver excluído, caso contrário este registro estará em branco.. 53

61 Seguindo com a regra de negócio 6, necessitou-se criar a visão do gestor, relacionando-se o cod_motivo_exclusao com a tabela motivo_exclusao para apresentar os nomes de tais motivos, ou seja, ao invés de apresentar ao gestor o código de exclusão, por exemplo: 1, 2, 3, etc., será apresentado o nome do motivo, por exemplo: Opção do cliente ou Opção da empresa. Em resposta a essa regra/necessidade, desenvolveu-se a tela apresentada pela Figura 24 na página 70, para facilitar a análise na mesma foi inserida um gráfico no formato pizza, quantificando os motivos de exclusão, assim é fácil verificar qual motivo possui uma quantidade maior de clientes excluídos. Para responder a regra de negócio 5 Clientes excluídos com faturas quitadas, deve-se selecionar os clientes excluídos na opção de situação dos clientes, isto existe na tela de filtros dos clientes, em seguida clicar na tela Receita x Utilização, assim serão apresentados todos os clientes que pagaram suas faturas e comparar se sua utilização foi baixa ou não. O gestor ainda terá a opção por escolher um determinado motivo de exclusão conforme já apresentado para a regra de negócio 6 Analisar motivos de exclusões. Para desenvolver os scripts que responderão a regra de negócio 4 Quantidade de clientes na base de dados, primeiramente confeccionou-se um script que trouxesse todos os clientes e seus respectivos contratos, porém utilizou-se um comando para não apresentar duplicidade. Juntamente com este primeiro script, outro também foi criado trazendo de uma tabela da base de dados um campo referente às datas, possuindo mês e ano, igualmente ao script da dimensão Tempo e da mesma forma que o anterior, não poderá apresentar duplicidade. Após os dois últimos scripts desenvolvidos, foi criado um verificador para saber se em determinado mês o cliente está ativo ou não. Primeiro seleciona os clientes e meses, após isto é feito uma análise de forma que se o cliente possui data de inclusão menor que o mês posterior e possui a data de exclusão maior ou igual ao mês posterior, este cliente é considerado com a situação de ativo naquele mês. Com isso um campo de verificação será preenchido com o valor 1, caso contrário, cliente inativo, este campo receberá o valor 0. Esta verificação ocorrerá para todos os clientes em todos os meses. Assim, na parte front-end da ferramenta, desenvolveu-se uma tela para apresentar esta quantidade, conforme mostra a Figura 26 na página 72. A tela demonstra a soma do campo verificador, onde este foi preenchido durante a extração das informações, ou seja, se o analista desejar analisar a quantidade de clientes em um determinado contrato, primeiramente selecionará o contrato e os meses que desejar analisar, automaticamente será somado a quantidade de clientes que 54

62 tenha o campo verificador igual a 1 nos meses selecionados, em seguida será apresentado um gráfico de linhas com a quantidade de cliente ativos nos meses. Finalizando o detalhamento dos scripts, é possível esclarecer que conforme identificado na etapa anterior, foi implementado o modelo Flocos de Neve (SnowFlake). No caso, a tabela Dimensão DIM_CLIENTE, que antes trazia dados de endereço e o motivo da exclusão dos clientes, foi alterada, gerando assim duas novas tabelas de dimensão, DIM_ENDERECO e DIM_MOTIVO_EXCLUSAO. Nessas tabelas ficaram somente os dados dos clientes que possuem endereço ou que já foram excluídos, respectivamente. Com a conclusão dos scripts, foram retiradas da modelagem antiga, as tabelas de Dimensão DIM_MEDICOS e DIM_PROCEDIMENTO, pois se identificou que nenhuma das regras levantadas no escopo iria utilizar os dados contidos em tais tabelas, sendo que futuramente, essas informações poderão ser de grande utilidade para o departamento de Marketing. Assim como a modelagem, outro ponto foi alterado, nas primeiras conversas com o analista de Marketing, foi informado que existiam várias fontes de dados. No entanto, após aprofundar os conhecimentos das fontes de dados e desenvolver os scripts que respondessem as regras de negócio, descobriu-se que existe uma única fonte de dados, sendo o sistema de gestão atual que a Operadora utiliza. Ou seja, para o analista, existem várias fontes de dados, pois recebe relatórios de áreas distintas, mas ao analisá-los fora do sistema de gestão, notou-se que existe uma única fonte de dados. Tão logo os scripts foram concluídos e as visões para os gestores desenvolvidas, os testes puderam ser iniciados, pois quanto mais testes forem realizados, menores são as chances de aparecer erros futuros. Desta forma, alguns detalhes que não haviam sido levantados no início foram aparecendo, detalhes estes que se não fossem esclarecidos, poderiam gerar informações erradas aos tomadores de decisão. Sabendo disso, necessitou-se contatar outras áreas para auxiliar na criação das regras. Ao finalizar a construção dos scripts, onde estes já na ferramenta QlikView, fazem a parte de extração, transformação e carga dos dados do sistema de gestão utilizado pela Operadora de Saúde. Deste modo, após a conclusão de todas as cargas e transformações necessárias, as telas que já haviam sido iniciadas, foram complementadas para possibilitar os testes finais da ferramenta. 55

63 3.5 TESTES E VALIDAÇÃO Nesta etapa, no modelo do DM desenvolvido, as cargas foram efetuadas de maneira normalizada e a visões foram desenvolvidas na ferramenta QlikView para o analista da área de Marketing, Estes testes foram iniciados ainda durante o desenvolvimento, onde se encontraram algumas divergências já explicadas na etapa anterior, o restante dos testes se deram ao final do desenvolvimento, possibilitando assim a liberação da ferramenta para validação do analista. A etapa de validação foi dividida em duas partes: na primeira a ferramenta só continha algumas regras de negócio, e a segunda foi executada após a conclusão da ferramenta. Nesta primeira apresentação, mesmo a ferramenta não estando concluída e poucas telas desenvolvidas, marcou-se o que seria a apresentação inicial ao analista da área de Marketing. Neste momento, o analista gostou das visões iniciais nesta primeira apresentação e aproveitou para questionar sobre o desenvolvimento de outras visões, o que agregaria ainda mais valor para o desempenho de sua função, ou seja, regras de negócio que não fizeram parte do escopo deste trabalho. No entanto, por dispor de um período pequeno para desenvolvimento deste trabalho, não foi possível atender as novas solicitações do mesmo. Nesta mesma apresentação, o analista ficou surpreso com as facilidades que a ferramenta trará, chegando a comentar frases como: está ótimo e não vou precisar mais esperar as solicitações que são feitas a outras áreas, pois assim será possível buscar as informações que preciso. Com essas declarações e outras que não foram descritas, foi possível notar o quanto esta área necessitava de uma ferramenta que possibilitasse buscar informações para gestão de forma rápida e prática. Na segunda apresentação, o analista gostou das visões desenvolvidas e tornou a solicitar outras visões que não fizeram parte deste trabalho. Com a aceitação da ferramenta na apresentação, a ferramenta foi liberada ao analista que passou a utilizá-la para validar as informações contidas na mesma. Durante o processo de validação, surgiram alterações como ajustes nas delimitações das telas, pois as mesmas foram desenvolvidas em um notebook e os monitores existentes na área de Marketing são menores. Estes ajustes foram necessários para não existir barra de rolagem nas telas, melhorando a visualização do analista. Após a validação do analista de Marketing e com as correções de tela concluídas, percebeuse que os dados extraídos estavam coerentes com a realidade. O mesmo analista ressaltou que a 56

64 ferramenta auxiliará a pesquisa por informações sobre os clientes e produtos da empresa, agilizando a tomada de decisão da área. Dessa forma, a ferramenta foi liberada para utilização de toda área. Antes, o analista utilizava apenas algumas vezes durante a semana, no caso, para efetuar as validações necessárias. Agora, com a ferramenta concluída, a área de Marketing utiliza a ferramenta para extrair as informações necessárias, onde passou a ser algo que não pode faltar no seu dia a dia. 3.6 UTILIZAÇÃO DA FERRAMENTA E RESULTADOS ALCANÇADOS Com a ferramenta pronta, validada e em operação pela área de Marketing, pode-se comentar sobre os resultados obtidos com esta nova opção para buscar informações sobre os clientes. O resultado mais evidenciado é que antes de existir este trabalho na área de Marketing, a mesma necessitava solicitar seus relatórios a outros departamentos da empresa, que ocasionava lentidão e atrasos para gerar a informações corretas, pois após receberem os relatórios solicitados, a área ainda precisava tratá-los e validá-los, o que demandava tempo e recurso. Agora com a estrutura do DM e a ferramenta concluída, esta área não precisa mais aguardar dias até que as solicitações sejam respondidas, pois conseguem extrair de forma prática, direta, rápida e com segurança as informações que necessitarem. A seguir serão detalhadas as telas criadas na ferramenta, assim como quais dessas respondem as necessidades da área, relacionando com cada regra de negócio. Primeiramente será apresentada a tela com filtros referentes aos clientes, conforme mostra a Figura

65 Figura 19. Tela Filtros de Clientes Na Figura 19, vê-se que é possível selecionar os clientes de várias maneiras dependendo da necessidade de cada momento. É possível buscar apenas os clientes ativos ou excluídos, assim como pelo sexo ou tipo do contrato (PF ou PJ), ou até mesmo selecionar algum dos motivos de exclusão. Nesta tela, também existe a possibilidade de efetuar quanto filtros forem necessários, quanto maior a quantidade de filtros, mais especifica ficará a seleção dos clientes. Todos os filtros apresentados anteriormente servem para facilitar a seleção dos clientes pelo seu plano cadastrado na Operadora, no entanto, em alguns momentos a necessidade não se refere em qual plano o cliente está cadastrado, mas onde o mesmo reside. Por este motivo, criou-se uma tela possibilitando o filtro pelos tipos de endereços (residência, cobrança ou correspondência), assim como por ou ainda pela rua, bairro, cidade ou estado, conforme mostra a Figura

66 Figura 20. Tela de Filtros de Endereços Assim como já descrito, quanto maior a quantidade de filtros utilizados, melhor será a seleção dos clientes. Para melhorar as seleções, nessa ferramenta é possível utilizar os filtros das duas telas para a mesma seleção, ou seja, os filtros de uma tela são adicionados ao da outra. Exemplificando, na tela com os filtros dos clientes, selecionam-se os que são Ativos e o tipo de contrato é Pessoa Jurídica, após isso, na tela de filtros de endereços, selecionam-se apenas os que estão situados na cidade de São José. Com isso, a resposta será apenas os clientes que fazem parte dos filtros utilizados. Independente dos filtros utilizados, sejam eles diversos ou poucos, criou-se duas telas que mostram as informações cadastrais dos clientes e outra com o endereço dos mesmos. As duas telas são apresentadas na Figura 21 para o cadastro dos clientes e na Figura 22 para os endereços. 59

67 Figura 21. Informações do cadastro dos clientes Figura 22. Informações de endereços dos clientes 60

68 Vale ressaltar que, quanto maior a quantidade de filtros, menor será a quantidade de clientes para mostrar na tela, com isso, a ferramenta apresentará a resposta de maneira rápida, sendo este o objetivo principal da criação desta ferramenta. O relatórios recebidos pela área de Marketing referente às regras de negócio 1 e 2, mencionadas na seção 3.1.3, continham os dados em planilhas separadas, onde estas eram unidas por fórmulas da planilha eletrônica, para assim poder analisar os clientes de maneira mais fácil. Verificavam-se quais clientes possuía um valor de Receita alto e o valor de Utilização baixo. Na ferramenta, criou-se uma tela contendo estas duas informações em uma tela, assim facilita e agiliza a análise, através das informações apresentadas na Figura 23. Figura 23. Receita x Utilização Antes da criação das visões para área de Marketing, esta necessitava solicitar um relatório com os clientes excluídos, além disso, também precisava ajustar o relatório de maneira que o mesmo gerasse informações que auxiliasse na tomada de decisão. Agora, com a ferramenta pronta, isto não é mais necessário, pois ao selecionar os clientes excluídos e clicar no botão Motivo de 61

69 Exclusão, será apresentado um gráfico com os motivos de exclusões. A Figura 24 responde as regras de negócio 5 e 6, e dessa maneira não será mais necessário ajustes nos relatórios pela área de Marketing. Figura 24. Gráfico Motivo de Exclusão Uma nova possibilidade que vale a pena citar é a opção gráfico/dados, como pode ser observado na Figura 24, é a opção que o gestor tem de após analisar o gráfico, selecionar qualquer motivo de exclusão, com apenas um clique no próprio gráfico, ou seja, no motivo desejado, isto seleciona todos os clientes com tal motivo de exclusão, o gestor pode clicar no botão Clientes para conhecer quais são os clientes selecionados ou até mesmo no botão Endereços, para saber o endereço dos clientes para, por exemplo, enviar uma correspondência. Essa opção de selecionar a informação no próprio gráfico não é comum, possibilitando assim a área conhecer informações antes nem pensadas. A Figura 25 apresenta os clientes que mais utilizaram o plano, essa tela responde a regra de negócio 3. Os clientes apresentados nessa tela serão avaliados, caso seja evidenciado a utilização 62

70 incorreta do plano, o código do cliente evidenciado será encaminhado ao departamento de Medicina Preventiva para que este verifique quais medidas deverão ser tomadas, possivelmente será incluído em um de seus programas de prevenção. Figura 25. Alta Utilização A regra de negócio 4 foi respondida com a tela de Quantidade de Vidas. Essa regra foi descrita solicitando a quantidade de clientes incluídos na base de dados em um determinado período. No entanto, em uma das entrevistas com o analista de Marketing, o mesmo identificou que se essa tela apresentasse o número de clientes ativos agregaria mais valor à ferramenta, pois será possível comparar a quantidade total de clientes mês a mês, conforme mostra a Figura

71 Figura 26. Quantidade de Vidas Com as visões a área de Marketing pode extrair informações não pensadas antes, como é o caso de analisar a predominância de determinadas faixas etária em uma região, para isso, selecionase as cidades desejadas na tela de Filtros de Endereços e depois se clica no botão Faixa Etária, onde é apresentado um gráfico contendo tais informações, conforme mostra a Figura 27, se necessitar conhecer quais clientes fazem parte de determinada faixa etária, basta clicar sobre a faixa etária desejada no próprio gráfico e depois clicar na tela de Clientes, onde mostrará o cadastro completo dos clientes selecionados. 64

72 Figura 27. Gráfico por Faixa Etária Conforme já apresentado na Figura 24, a Figura 27 também permite efetuar o mesmo tipo de seleção a partir de um clique no gráfico para selecionar determinada faixa etária, possibilitando o clique nas telas de Clientes ou Endereços conforme suas necessidades. Com o desenvolvimento das visões, calcula-se uma redução de 44% na quantidade de passos para concluir o levantamento das informações necessárias, baixando de nove para cinco passos do processo anterior para o novo. Conforme é apresentado na Figura

73 Figura 28. Fluxograma do Processo para coletar informações 66

74 Em relação ao tempo de pesquisa, no processo anterior, eram necessários no mínimo dois dias, podendo se estender em até trinta dias para obter as informações. No novo processo, essas informações podem ser extraídas em poucos minutos, podendo até ser instantâneo, dependendo da sua complexidade de pesquisa. Desta maneira, ao analisar o prazo mínimo no processo anterior, ou seja, dois dias, com o tempo de 5 minutos no novo modelo, calcula-se uma redução de aproximadamente 99,8% no tempo para conseguir as informações necessárias para a diretoria. 67

75 4 CONCLUSÕES Este trabalho objetivou a criação de um DM e o desenvolvimento de visões a partir da ferramenta QlikView, para auxiliar na pesquisa por informações para a área de Marketing de uma Operadora de Saúde, trazendo rapidez, agilidade e segurança das informações no momento da tomada de decisão. O objetivo principal do trabalho foi alcançado, sendo que após a validação da ferramenta, o departamento de Marketing consegue extrair a informações de maneira mais rápida e prática que antes de existir as visões. A escolha de qual ferramenta escolher para utilizar em um trabalho como este é um ponto básico. Neste trabalho, não foi selecionada a melhor ferramenta ou a mais adequada para este tipo de modelo, pois a ferramenta QlikView é padrão na empresa e já está disseminada em outras áreas. A cada momento que se reuniam o analista de Marketing e os analistas das outras áreas para esclarecer as regras de negócio, entendia-se cada vez mais a importância deste trabalho para área de Marketing, pois além de conseguir extrair informações de maneira mais rápida e clara, os analistas que utilizam as visões produzidas por este trabalho, conseguem também atingir as metas da área com mais facilidade, auxiliando assim a empresa a alcançar seus objetivos. A execução deste trabalho foi satisfatória no âmbito profissional, pois aproximou a área estratégica com as áreas de negócio, assim como aumentou o entendimento do analista da área estratégica quanto ao negócio da área de Marketing. Isso já trouxe e continuará trazendo melhorias dentro da empresa, pois facilitará futuras negociações entre as áreas, assim como as novas visões quando solicitadas. Sabendo que os resultados também foram satisfatórios para o gestor, é possível ressaltar alguns pontos positivos: - Rapidez e agilidade na busca pelas informações; - O departamento de Marketing não necessita aguardar vários dias pela entrega dos relatórios solicitados, mas especificamente de dois a trinta dias dependendo da solicitação;

76 - Ferramenta Front-end disponibilizada para área, sendo a mesma construída com um modelo que possibilita a continuidade da mesma; - Não houve necessidade de novos investimentos, pois a empresa já possui a ferramenta utilizada neste trabalho; A estrutura criada com o modelo Flocos de Neve foi pensada para futuramente expandir a ferramenta sem que haja alterações na estrutura atual, possibilitando a inclusão de outras tabelas dimensões, o que agregará ainda mais valor para área. As dificuldades para construção dos scritps foi grande, necessitando também do auxílio das áreas conhecedoras do negócio para concluir as regras corretas para extração das informações. Apesar dessa dificuldade, o resultado teve grande valia, pois aproximou as áreas de negócio com a área de Marketing. Sugestão para trabalhos futuros: Ampliar a estrutura criada para responder a necessidades diversas da área; Criar novas telas com gráficos de novas informações para a análise do gestor. 69

77 REFERÊNCIAS BIBLIOGRÁFICAS ABNT. ABNT - NBR 6023: Informação e Documentação Referências - Elaboração, ABREU, F. S. G. G. Desmistificando o Conceito de ETL. Revista de Sistemas de Informação, Disponível em: < >. Acesso em: 1 jun ACCORSI, D. Você sabe o que é Data Warehouse? Criado em 02/04/2008. Disponível em: < Acesso em: 14 abr VM2, A. Marketing de Relacionamento. Disponível em: < Acesso em: 13 abr ALMEIDA, D. R. da R. Marketing para Micro e Pequenas Empresas. Disponível em: < le/202_1_arquivo_marketingmpe.pdf>. Acesso em: 3 jun ANZANELLO, C. A. OLAP Conceitos e Utilização, Disponível em: Acesso em: 10 mai BACK, M. R. Data Warehouse e Data Mart, Disponível em: < Acesso em: 6 abr BAZZOTTI, C.; GARCIA, E; A importância do sistema de informação gerencial para tomada de decisões. Disponível em: < munica%c3%a7%c3%b5es/art%203%20- %20A%20import%C3%A2ncia%20do%20sistema%20de%20informa%C3%A7%C3%A3o%20ger encial%20para%20tomada%20de%20decis%c3%b5es.pdf>. Acesso em: 31 mai BECKER, T. C. Marketing Turístico Promocional na Serra Gaúcha. Trabalho de Conclusão do Curso de Administração com Habilitação em Comércio Exterior Universidade do Vale do Itajaí, São José, Disponível em: < Acesso em: 6 jun CARÂP, L. J, Marketing Estratégico em Saúde. Disponível em: < Acesso em: 3 jun CENTENARO, A. C. Desenvolvimento e implantação de um Data Warehouse com Data Marts distribuídos em uma cooperativa agroindustrial. Trabalho de Conclusão de Pós-Graduação Universidade Federal de Santa Catarina, Florianópolis, Disponível em < Acesso em: 18 mai COBRA, M. Estratégias de Marketing de serviços. Cobra editora e Marketing, 2001.

78 CRAMER, R. Estudo Analítico de ferramentas Open Source para ambientes OLAP. Especialização em MBA gerenciamento de banco de dados Universidade do Extremo Sul Catarinense, Criciúma, Disponível em: < Acesso em: 1 jun DALLORA, M. E. L. V. et al. Proposta de utilização de um Data Mart no centro cirúrgico do Hospital das Clínicas da Faculdade de Medicina de Ribeirão Preto Universidade de São Paulo, São Paulo, Disponível em: < Acesso em: 3 jun DATA MART. Disponível em: < Acesso em 8 mar DATAPRIX, DATA MART. Disponível em: < Acesso em: 3 jun DATASUS, Disponível em: < Acesso em: 4 jun DIAS, B. O. Projeto de Data Mart utilizando ferramentas Open Source, Disponível em: < Acesso em: 14 abr FARINA, A. G.; MENEGUZZI, C. R.; PIRES, L. P. Estruturas de Banco de Dados para Suporte a Data Warehousing/Data Mart. Porto Alegre, RS Disponível em: < >. Acesso em: 3 jun FORTULAN, M. R; GONCALVES FILHO, E. V. Uma proposta de aplicação de Business Intelligence no chão-de-fábrica, Disponível em: < Acesso em: 21 set GALICIA, I. T. Ferramentas de Business Inteligence Disponível em: < Acesso em: 13 set INMON, W. H.; HACKATHORN, R. D. Como usar o Data Warehouse. Ed. Infobook: Rio de Janeiro, KIMBALL, R. Data Warehouse Toolkit; São Paulo: Makron Books, KOTLER, P. Administração de Marketing: Análise, Planejamento, Implementação e Controle. 5º Edição, Editora Atlas S.A. São Paulo SP, KUHNEN, C.; VIEIRA, V. A. Vantagem obtidas com a utilização da implantação do Data Warehouse: Um estudo de caso na Unimed de Francisco Beltrão Disponível em: < Acesso em: 6 jun LAUDON, K. C.; LAUDON, J. P. Sistemas de Informação Gerenciais. 5.ed. Person Education do Brasil: São Paulo

79 LAUDON, K. C.; LAUDON, J. P. Sistemas de Informação Gerenciais. 7.ed. Person Education do Brasil: São Paulo MACHADO, F. N. R. Projeto de Data Warehouse: Uma Visão Multidimensional. São Paulo: Érica MEIRA, K. M. G.; CAZARINI, E. W; Proposta de Aplicação da Ferramenta OLAP/ Data Mart para apoiar a captação de doadores de sangue em um Hemonúcleo Disponível em: < >. Acesso em: 3 jun MENOLLI, A. L. A. Definição de uma arquitetura de Data Warehousing para gestão em ciência e tecnologia no Brasil. Dissertação (Mestrado em Ciências da Computação) Universidade Estadual de Maringá, Maringá, Disponível em: < Acesso em: 12 abr MIYAZAKI, F. E. Aplicação de Data Mart no Sistema MÊS (Manufacturing Execution System) para Aumento da Qualidade da Informação no Controle de Gestão. Trabalho de conclusão de Curso de Especialização em Análise, Projeto e Gerência de Sistemas com Ênfase em Inteligência em Negócios Universidade Estadual de Londrina, Londrina, Disponível em: < Acesso em: 6 abr MONTEFUSCO, A. C. et al. Business Intelligence: As empresas do segmento de Call Center no Brasil podem ser mais eficientes na contratação e retenção de funcionários. Disponível em: < Acesso em: 8 mar MORALES, A. B. T. Sistemas de Apoio a Decisão Negócios Inteligentes na WEB. Disponível em: < Acesso em: 14 set NOGUEIRA, A. L. B.; OLIVEIRA, L. R. J. Uma Análise da Aplicabilidade de Data Warehouse em Ambientes Empresariais, Disponível em: < >. Acesso em: 13 abr PACHECO, V. S. Implementação de cubos OLAP sobre um Data Warehouse, baseado em estudo de caso de uma instituição financeira. Trabalho de Conclusão do Curso de Informática II e apresentado ao curso de Ciência da Computação Universidade Luterana do Brasil, Gravataí, Disponível em: < Valeria_Silveira_Pacheco.pdf>. Acesso em: 8 mar PALMER, A. Introdução ao Marketing Teoria e Prática. São Paulo: Ática PICHILIANI, M. C. Construindo cubos OLAP em Java com o Mondrian, Disponível em: < Acesso em: 1 jun RADUENZ, J. C. Desenvolvimento de um modelo de BI fundamentado no MPS-BR Nível G, para auxiliar no processo de análise das informações da EDM Informática. Trabalho de conclusão do curso de Ciência da Computação Universidade do Vale do Itajaí, São José, SCHIMIGUEL, J. Data Warehousing: Integração de Dados Organizacionais para a Tomada de Decisão. Revista Técnica. FIPEP, São Paulo, SP, v. 3, n. 1/2,p , jan./dez Disponível 72

80 em: < Acesso em: 17 mai SERRANO, D. O que é Marketing. Criado em 16/02/2007. Disponível em: < Acesso em: 2 jun SILVA, A. A; Relação Entre Operadoras de Planos De Saúde e Prestadores de Serviços Um Novo Relacionamento Estratégico. Porto Alegre, Disponível em: < lva_relacaooperadorasplanos.pdf>. Acesso em: 30 mai SILVA, N. A. Marketing Empresarial. Disponível em: < Acesso em: 7 mar SOBRAL, F. M.; SOUZA, M. A. M. Proposta de Data Mart para o Plano de Saúde do Senado Federal. Monografia de Especialização, Publicação UNB.LABREDES.MFE.008/2006, Departamento de Engenharia Elétrica - Universidade de Brasília, Brasília, 08/2006. Disponível em: < Acesso em: 3 jun TERADATA. Carrefour expande utilização de Data Warehouse da Teradata. Criado em: 11/5/2009.Disponível em: < te=131>. Acesso em 12 abr TOCCATO. Disponível em: < Acesso em: 13 set VIDOTTI, J. C. Projeto de um Data Warehouse: Análise de Custo/Benefício. Trabalho de Conclusão de Curso Universidade Federal de Mato Grosso, Cuiabá, Disponível em: < Acesso em: 17 mai ZERO83. Business Intelligence para otimização do processo produtivo e de tomada de decisão Disponível em: < Acesso em: 14 set

81 APÊNDICES

82 I QLIKVIEW Neste anexo serão apresentados detalhes da ferramenta Qlikview que não foram descritos no trabalho. Todas as Figuras e textos complementares foram extraídos de Requisitos da ferramenta Fonte: Toccato (2010). 75

83 Suporte a navegadores e celulares Fonte: Toccato (2010). 76

84 Requisitos do Qlikview Server Fonte: Toccato (2010). Detalhes do Qlikview Publisher Fonte: Toccato (2010). 1 O QlikView é uma tecnologia de análise em memória; exigências de memória para os produtos QlikView estão diretamente relacionados à quantidade de dados analisada 2 A autenticação personalizada requer o QlikView Server Enterprise Edition 3 Outros navegadores podem funcionar com o Cliente AJAX do QlikView Analyzer, mas não foram testados pela QlikTech 4 Teste limitado pode haver alguns limites de funcionalidade 5 Dispositivos testados - BlackBerry: Bold e Pearl; HTC Touch Diamond; Nokia: 6555, E71, 5800 Xpress Music e E90 Communicator; Sony Ericsson: Xperia X1, P1i; LG KC910; Samsung Omnia SGH-i900; outros dispositivos móveis podem funcionar, mas não foram testados pela QlikTech 6 Recomendado somente para fins de desenvolvimento e teste 7 O QlikView é um módulo adicional licenciado do QlikView Server. Ele é instalado ao se aplicar uma licença a um QlikView Server existente 77

85 II COMPARATIVO ENTRE FERRAMENTAS Nesta seção, complementando as informações do Apêndice I, serão apresentadas algumas comparações e vantagens das ferramentas de BI. Todas as Figuras e textos complementares foram extraídos/baseados de (GALICIA, 2009). Pode-se detalhar algumas características genéricas das ferramentas de BI, como: acesso a informação; apoio a tomada de decisão e orientação ao usuário final. A seguir serão apresentadas algumas vantagens referentes a ferramentas de código proprietário, como: QlikView, SAP Business Object e IBM Cognos, assim como as de código aberto, como: Pentaho, Eclipse Birt e Jasper Soft. A figura a seguir apresenta as vantagens do QlikView. Vantagens do QlikView. Fonte: Galicia (2009). 78

86 A figura a seguir apresenta as vantagens do SAP Business Object. Vantagens do SAP Business Object. Fonte: Galicia (2009). A figura a seguir apresenta as vantagens do IBM Cognos. Vantagens IBM Cognos. Fonte: Galicia (2009). Além das figuras apresentadas acima, o autor produziu uma comparação entre as ferramentas de código aberto, que será apresentada a seguir, onde o software é distribuído e desenvolvido sem nenhum custo. 79

87 Comparativo das ferramentas de código livre. Fonte: Galicia (2009). 80

88 Comparativo das ferramentas de código livre. Fonte: Galicia (2009). 81