Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DE SANTA CATARINA
CENTRO TECNOLÓGICO
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO
UMA APLICAÇÃO DE GERENCIAMENTO DO
RELACIONAMENTO COM O CLIENTE PARA O SETOR DE
VAREJO SUPERMERCADISTA
Erivelton Vichroski
Florianópolis
2005
ERIVELTON VICHROSKI
UMA APLICAÇÃO DE GERENCIAMENTO DO
RELACIONAMENTO COM O CLIENTE PARA O SETOR DE
VAREJO SUPERMERCADISTA
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Sistemas de Informação do Centro Tecnológico da Universidade Federal de Santa Catarina, como requisito parcial para a obtenção do grau de Bacharel em Sistemas de Informação.
Profª. Dra. Marta Maria Leite – Orientadora
UMA APLICAÇÃO DE GERENCIAMENTO DO
RELACIONAMENTO COM O CLIENTE PARA O SETOR DE
VAREJO SUPERMERCADISTA
Por
ERIVELTON VICHROSKI
Trabalho de Conclusão de Curso apresentado à Universidade Federal de Santa Catarina, Curso de Graduação em Sistemas de Informação, para obtenção do grau de Bacharel em Sistemas de Informação, pela Banca Examinadora formada por:
_________________________________________________
Orientadora: Profª. Dra. Marta Maria Leite – Orientadora, UFSC.
_________________________________________________
Membro: Profª. Elizabeth Sueli Specialski, Doutora, UFSC.
_________________________________________________
Membro: Eliane Spielmann, Consultora em CRM.
Dedico este trabalho à minha filha Isadora, que em breve estará entre nós.
À minha esposa Tatiane, em especial pela ajuda e compreensão nos momentos de dificuldade.
Aos meus pais que me proporcionaram a vida.
AGRADECIMENTOS
Agradeço a Deus.
Agradeço a minha orientadora, pela valiosa ajuda para concretização deste trabalho.
Aos membros da banca, pelo apoio.
Aos professores e colegas, pelos conhecimentos compartilhados.
Aos colegas de trabalho, pelo companheirismo e apoio.
À minha esposa, pelo apoio e compreensão.
RESUMO
Este trabalho é uma aplicação da ferramenta de data warehousing no processo de
gerenciamento do relacionamento com o cliente na área de varejo supermercadista. A
principal finalidade é melhorar a eficiência e a eficácia da análise dos dados do
comportamento de compra do cliente neste segmento comercial, além de elevar a corretude
das tomadas de decisões estratégicas e gerenciais.
São revisados os conceitos básicos sobre CRM, enfatizando-se como esta filosofia é
transformada em estratégia dentro das organizações. A revisão conceitual também aborda a
caracterização do setor de varejo supermercadista através da conceituação e de como foi
seu desenvolvimento no Brasil. Além disso, procura-se conceituar data warehouse e como
suas características proporcionam suporte à tomada de decisão.
Como aplicação é criado um data mart de clientes, através da utilização de técnicas
de data warehousing e da execução de tarefas como coleta de requisitos e modelagem
multidimensional, usadas tradicionalmente neste tipo de aplicação. Também é ressaltada a
necessidade de planejamento do projeto, bem como características necessárias para
implantação do mesmo.
Como finalização deste trabalho são relatadas as conclusões e os resultados obtidos
acerca da aplicação com o intuito de se justificar e validar os objetivos propostos.
Palavras-chave: CRM, setor supermercadista, data warehouse, data mart, análise do
comportamento de compra do cliente.
LISTA DE FIGURAS
Figura 1 - Estratégia de CRM.................................................................................................21 Figura 2 - Padronização de dados no data warehouse.. .........................................................31 Figura 3 - O data warehouse tem uma forte orientação por assunto......................................32 Figura 4 - Comparação de variação do tempo: sistema operacional versus data warehouse.32 Figura 5 - Não volatilidade do data warehouse.. ...................................................................33 Figura 6 - Nível de granularidade do data warehouse.. .........................................................34 Figura 7 - Componentes do data warehouse. .......................................................................35 Figura 8 - Exemplo de um modelo estrela..............................................................................37 Figura 9 - Exemplo de cubo. ..................................................................................................38 Figura 10 - Ciclo de vida de um DW.. ...................................................................................40 Figura 11 - Diagrama lógico do Fato Venda. .........................................................................51 Figura 12 - Modelo físico proposto para o data mart de clientes. .........................................52 Figura 13 - Plano para o processo back end. ..........................................................................53 Figura 14 - Ferramenta Desktop OLAP Microsoft Excel™, usada nas demonstrações. ........58 Figura 15 - Ambiente Desktop OLAP na ferramenta Open Office.org 1.1.2™ .....................58 Figura 16 - Ambiente Desktop OLAP na ferramenta Discoverer da Oracle™ .....................59
LISTA DE QUADROS
QUADRO 1 – VAREJO ALIMENTAR – TIPO DE LOJA ...................................................24 QUADRO 2 – CLASSIFICAÇÃO DE TIPOS DE VAREJO.................................................25
LISTA DE TABELAS
Tabela 1: Volume de venda de um “Cliente 1” em 30/12/2004.............................................60 Tabela 2: Média mensal do volume de compra do “Cliente 1002” no quarto trimestre de 2004. ........................................................................................................................................60 Tabela 3: Consulta sem retorno para o “Cliente 282”, no quarto trimestre de 2004..............61 Tabela 4: Regiões geográficas mais representativas em termos de venda, na loja “Super Centro”. ...................................................................................................................................61
LISTA DE ABREVIATURAS
ABRAS – Associação Brasileira de Supermercados
CRM – Customer Relationship Management
DDL – Data Definition Language
DW – Data Warehouse
DM – Data Mart
ECF – Emissor de Cupom Fiscal
ETL – Extração, Transformação e Carga
PDV – Ponto de Venda
OLAP – On Line Analytical Processing
OLTP – On Line Transactional Processing
SAF – Sistema de Automação de Vendas
SQL – Structured Query Language
TI – Tecnologia da Informação
TIC – Tecnologia da Informação e Comunicação
SUMÁRIO
1. INTRODUÇÃO.......................................................................................................................13
1.1. DEFINIÇÃO DO PROBLEMA .......................................................................................15
1.2. OBJETIVOS.....................................................................................................................15
1.2.1. Objetivo geral ............................................................................................................15
1.2.2. Objetivos específicos.................................................................................................15
1.3. JUSTIFICATIVA .............................................................................................................16
1.4. MOTIVAÇÃO..................................................................................................................16
1.5. ORGANIZAÇÃO DOS CAPÍTULOS.............................................................................17
2. CRM – CUSTOMER RELATIONSHIP MANAGEMENT .......................................................18
2.1. Definição ..........................................................................................................................18
2.2. Estratégias de Implantação do CRM ................................................................................20
3. O SETOR DE VAREJO SUPERMERCADISTA NO BRASIL ............................................23
3.1. Caracterização ..................................................................................................................23
3.2. Desenvolvimento do Setor Supermercadista no Brasil ....................................................25
3.3. Perfil do Setor Supermercadista Brasileiro ......................................................................26
3.4. Perfil dos Consumidores do Setor Supermercadista Brasileiro........................................28
4. DATA WAREHOUSE COMO SUPORTE AO CRM ANALÍTICO .......................................30
4.1. Definição ..........................................................................................................................30
4.2. Características do Data Warehouse..................................................................................30
4.2.1. Integração ..................................................................................................................31
4.2.2. Orientação por Assunto .............................................................................................32
4.2.3. Variação no Tempo ...................................................................................................32
4.2.5. Granularidade ............................................................................................................33
4.3. Componentes do Data Warehouse ...................................................................................34
4.4. Metodologia para Construção de Data Warehouse ..........................................................38
4.4.1. “O Ciclo de Vida de Kimball”...................................................................................39
4.5. Aplicação do Data Warehouse no processo de CRM Analítico ......................................40
5. JUSTIFICATIVA PARA ADOÇÃO DA METODOLOGIA.................................................42
5.1. PLANEJAMENTO DO PROJETO DO DATA MART ....................................................43
5.1.1. Definição do Escopo..................................................................................................44
5.2. DEFINIÇÃO DOS REQUISITOS DO DATA MART ......................................................47
5.2.1. Requisitos Levantados...............................................................................................48
5.3. MODELAGEM MULTIDIMENSIONAL.......................................................................50
5.3.1. Modelagem Física do Projeto....................................................................................51
5.3.2. Implantação Física do Modelo Proposto ...................................................................52
5.3.3. Arquitetura de Aquisição de Dados (Back End)........................................................53
5.3.4. Arquitetura de Apresentação dos Dados (Front End) ...............................................54
5.4. APLICAÇÃO DO MODELO PROPOSTO.....................................................................56
6. RESULTADOS OBTIDOS.....................................................................................................57
7. CONCLUSÃO.........................................................................................................................62
7.1. Sugestões para Trabalhos Futuros ....................................................................................63
8. REFERÊNCIAS BIBLIOGRÁFICAS ....................................................................................64
APÊNDICE A SCRIPTS SQL/DDL UTILIZADOS PARA CRIAÇÃO FÍSICA DO
MODELO PROPOSTO...............................................................................................................67
APÊNDICE B PROGRAMAS EM LINGUAGEM PL/SQL UTILIZADOS NO
PROCESSO ETL.........................................................................................................................70
APÊNDICE C – ARTIGO...........................................................................................................87
13
1. INTRODUÇÃO
De modo geral toda empresa com fins lucrativos depende de clientes para existir,
ou seja, ela espera que os mesmos paguem pelos serviços ou produtos ofertados. Como
condição básica para permanência no mercado, uma empresa está sempre procurando atrair
novos clientes ou ainda oferecendo vantagens àqueles já conquistados. Para atingir este
objetivo, em muitos casos, as empresas usam estratégias de marketing com o objetivo de
divulgar ou lançar novos produtos ou serviços.
O Marketing oferece muitos recursos que ajudam a obter novos clientes. Estas
atividades não são muito simples e exigem investimentos em campanhas promocionais,
criação de novos serviços ou produtos, comunicação com os clientes, planejamento de
vendas, treinamento de colaboradores visando o ótimo atendimento, dentre outros. Porém,
tão importante quanto conquistar um cliente é mantê-lo. O CRM (Customer Relationship
Management) é uma estratégia oriunda do marketing de relacionamento que tem por
objetivo atender e influenciar o comportamento do cliente para melhorar suas compras, a
retenção, a lealdade e lucratividade deles (SWIFT, 2000). Para isso, procura fazer do
cliente o foco dos negócios, onde todos os processos gravitam em torno dele. Fazer com
que os processos girem em torno do cliente exige modificações na forma como estes
processos são construídos, pois, tradicionalmente, são projetados com base em outro
enfoque, o do produto.
Além do mais, para manterem-se competitivas, as empresas necessitam da
informação como principal arma contra seus concorrentes. Para isso, a busca de
conhecimento sobre o cliente, faz com que essas empresas coloquem as informações do
mesmo no centro de suas infra-estruturas de informações.
14
A retenção de clientes lucrativos, conquistada por empresas bem-sucedidas, se dá
pela obtenção de conhecimento detalhado dos clientes, e não somente através de dados
brutos relacionados com transações e pagamentos financeiros. A Tecnologia da
Informação (TI) auxilia na transformação de dados brutos em informação. Esse processo
facilita que as informações obtidas rapidamente sejam usadas na criação de um ambiente
para a tomada de decisões de negócios compartilhada e inovadora (SWIFT, 2000).
Além do mais, para que as empresas tenham um ambiente ágil para a obtenção da
informação pode-se empregar o conceito de Data Warehouse (DW). Esse consiste em
organizar os dados corporativos da melhor maneira, dando subsídio de informações aos
gerentes e diretores das empresas para tomada de decisão. Tudo isso num banco de dados
centralizado e paralelo aos sistemas operacionais da empresa. Mas, em contrapartida, a
criação de um DW requer tempo, dinheiro e considerável esforço gerencial devido à sua
abrangência no que se refere às áreas da organização. Muitas empresas iniciam este tipo de
projeto tendo como base as necessidades de pequenos grupos ou departamentos. Estes
módulos de armazenamentos de dados são chamados de Data Mart (DM). O maior atrativo
de se optar por um DM é o seu menor custo e prazo de implantação.
Considerando, neste contexto, as empresas do ramo supermercadista, bem como
todas as empresas em que o cliente é a razão de sua existência, a estratégia de
relacionamento com o cliente só pode ser adotada através da combinação conjunta de
processos, tecnologias e procedimentos comportamentais e, além é claro, que a empresa
tenha “foco no cliente” (PEPPERS AND ROGERS, 2001).
15
1.1. DEFINIÇÃO DO PROBLEMA
Atualmente, o gestor da área de CRM no segmento supermercadista necessita de
constante análises dos dados que referenciam os hábitos de consumo do cliente, com o
objetivo de desenvolver ações que promovam a fidelização do mesmo, aumento de
faturamento e uma maior lucratividade para a organização. Este procedimento exige
complexas consultas ao banco de dados operacional para que se consiga extraí-los e
transforma-los em informações. Muitas vezes esta tarefa acontece de forma manual ou
através do auxílio da área de informática.
Além do mais, é desejável que o processo de aquisição e transformação dos dados
seja feito de maneira automática, tornando-o mais ágil e sem necessidade de intervenções
manuais ou repetitivas.
Nestas circunstâncias, temos como problema a demora na aquisição de informações
relevantes e corretas para que se consiga executar de uma forma eficiente e eficaz o
processo de gerenciamento do relacionamento com o cliente.
1.2. OBJETIVOS 1.2.1. Objetivo geral
Aplicar a tecnologia da informação, através da criação de data mart de clientes, a
fim de prover agilidade na análise dos dados dentro do processo de gerenciamento do
relacionamento com o cliente no varejo supermercadista.
1.2.2. Objetivos específicos
Primeiramente, explorar e estudar uma base de dados operacional que contenha
elementos pertinentes ao perfil de compras de clientes do ramo supermercadista.
16
Posteriormente, aperfeiçoar o conhecimento sobre conceito de CRM e das técnicas
de data warehousing.
Finalmente, agregar os conhecimentos adquiridos através da especificação de um
data mart, com intuito de agilizar a análise dos dados (KIMBALL, 1998).
1.3. JUSTIFICATIVA
Como justificativa, vê-se a relação do processo de análise dos dados que
referenciam comportamentos de consumo dos clientes com as ferramentas OLAP (On Line
Analytical Processing), tido atualmente como mais produtivas no que tange a obtenção e
visualização dos dados (THOMSEN, 1997). O problema encontra-se atualmente no ponto
de preparação dos dados para fornecer suporte ao OLAP, e este consiga atender
plenamente os requisitos de análise das informações dentro do processo de gerenciamento
do relacionamento com o cliente. Além do mais, algumas características como
dimensionalização e consolidação dos dados para que se obtenha um melhor desempenho
das consultas (KIMBALL, 1998), apontam a tecnologia de DW, sabida e
reconhecidamente com um ferramental fortemente relacionado com as técnicas OLAP.
1.4. MOTIVAÇÃO
A motivação para realização deste estudo vem da possibilidade de vivenciar na
prática as questões técnicas e teóricas estudadas no decorrer do curso, além da afinidade
com o assunto CRM e do desafio de especificar a ferramenta em questão.
17
1.5. ORGANIZAÇÃO DOS CAPÍTULOS
Inicialmente, o capítulo 2 “CRM - Customer Relationship Management” tratará do
embasamento teórico sobre esse assunto.
No capítulo 3, “O Setor de Varejo Supermercadista”, será feita a caracterização do
tema através da apresentação do conceito, como foi o desenvolvimento do setor,
identificação do perfil de consumidor e das lojas, além da relação dos supermercados com
as estratégias de CRM.
No capítulo 4, “Data Warehouse como suporte ao CRM Analítico”, serão
apresentados assuntos pertinentes à justificativa da adoção de DW como metodologia de
trabalho para a solução do problema aqui proposto, ou seja, o uso de um data mart no
ramo de varejo supermercadista como suporte ao processo de análise dos dados do cliente.
Logo após, no capítulo 5 intitulado “Justificativa para Adoção de Metodologia”,
será apresentada a solução para resolver o problema proposto.
Finalmente, o capítulo 6 contemplará os “Resultados Obtidos”, fazendo uma
avaliação do processo de análise dos dados do cliente após este trabalho, seguida da
“Conclusão”, no capítulo 7.
18
2. CRM – CUSTOMER RELATIONSHIP MANAGEMENT
Neste capítulo serão tratados alguns conceitos básicos sobre CRM, necessários para
uma maior compreensão do assunto. A caracterização das estratégias para CRM dará um
maior entendimento da aplicação desse conceito dentro das organizações.
2.1. Definição
O termo CRM – Customer Relationship Management embora amplamente
utilizado, nunca foi formalmente definido. Segundo Peppers and Rogers Group (2001)
pode se dizer que “CRM é uma infra-estrutura para implementar-se a filosofia one to one
de relacionamento com os clientes”.
O principal objetivo de uma empresa, quando adota a filosofia do CRM, é entender
e influenciar o comportamento dos seus clientes, fazendo com que eles permaneçam fiéis à
empresa, aumente o volume de suas compras e recomendem a empresa para outros
possíveis clientes. Em resumo, o objetivo principal da empresa é obter incremento real das
suas vendas e, conseqüentemente, aumentar sua lucratividade.
Outro ponto a ser discutido, é que CRM pode ser considerado um processo
interativo que transforma informações sobre os clientes em relacionamentos positivos com
os mesmos (SWIFT, 2001, p.13).
A principal justificativa para que as empresas adotem esta filosofia esta baseada na
premissa, atualmente bem conhecida, que custa menos manter os clientes atuais do que
conquistar novos - na realidade custa cinco vezes menos (SWIFT, 2001, p.18) - e do fato
de que o mercado está cada vez mais competitivo e a sobrevivência das empresas requer
manutenção da satisfação dos clientes já conquistados. Um exemplo disto é aos clientes
19
que fazem suas compras de produtos ou serviços pela Internet, pois qualquer insatisfação
dará ao mesmo a possibilidade de mudar de empresa fornecedora com um simples toque do
mouse. Assim, já não basta oferecer o melhor preço ou a melhor ou mais atual tecnologia.
Uma campanha promocional pode atrair alguns clientes por algum tempo, mas a empresa
corre o risco de perdê-los no caso da concorrência fazer uma promoção mais atrativa.
O CRM efetivamente engloba a capacidade de uma empresa em (SWIFT, 2001,
p.16):
• Descobrir clientes;
• Conhecê-los;
• Manter comunicação com eles;
• Assegurar que eles receberam o que desejam da organização-não somente
quanto ao aspecto do produto, mas em cada detalhe de como a organização lida
com eles;
• Verificar se eles recebem o que lhes foi prometido - certamente, desde que seja
lucrativo;
• Assegurar que o cliente seja mantido - mesmo que o cliente não seja lucrativo
atualmente, o objetivo é lucratividade em longo prazo.
CRM não diz respeito a preços, não diz respeito ao envio de grandes quantidades de
correspondências ou muitas ligações irritantes para clientes em potencial. Definitivamente,
não diz respeito à utilização dos canais para direcionar os clientes para os concorrentes
(SWIFT, 2001, p.16).
Fornecer as capacidades para gerar produtos, serviços, respostas, individualização,
personalização em massa e satisfação do cliente está intimamente ligado ao CRM. Estas
ações podem fazer parte do planejamento da empresa, porém, para manter os clientes
20
conquistados é necessário que eles estejam satisfeitos com a empresa a ponto de rejeitarem
a possibilidade de optar pela concorrência.
De acordo com Peppers and Rogers (2001), uma solução do CRM é composta de
três pilares fundamentais: tecnologia, processos e pessoas. O conjunto das pessoas é
formado pelos executivos e colaboradores da organização e a implantação do CRM podem
exigir o desenvolvimento de novas habilidades e competências de todos os envolvidos.
Os processos são a composições do conjunto de todas as rotinas da organização
necessárias para a execução da estratégia do CRM. A tecnologia consiste na infra-estrutura
de hardware e software necessária para dar suporte à estratégia, sendo que a mesma deve
ser implantada como forma de suporte aos processos e aos procedimentos que devem ser
executados pelas pessoas. Assim, não será possível alcançar o sucesso em um projeto de
CRM caso os processos ou os procedimentos adotados pela empresa não sejam
cuidadosamente avaliados e definidos antes da implantação da tecnologia de suporte
(PEPPERS AND ROGERS, 2001, p.52).
2.2. Estratégias de Implantação do CRM
Quando falamos em implantar um projeto de CRM, além do custo e da
disponibilidade de tempo, exigem-se, na maioria das vezes, profundas mudanças na
maneira da empresa se relacionar com seus clientes. Políticas, processos e procedimentos
da empresa frente aos seus consumidores fatalmente deverão ser repensados ou
melhorados para que se consiga o êxito do projeto (PEPPERS AND ROGERS, 2001).
O sucesso deste tipo de projeto advém do cumprimento de alguns objetivos básicos
da própria estratégia de CRM, ou seja, conhecer na íntegra o cliente e suas necessidades,
21
garantir a satisfação do consumidor através do atendimento diferenciado, além aumentar a
eficiência nos serviços prestados (PEPPERS AND ROGERS, 2001).
Podemos distinguir um projeto de CRM de acordo com sua abordagem ou
estratégia de implantação, conforme demonstrado na figura abaixo:
Figura 1 - Estratégia de CRM Fonte: Peppers and Rogers (2001)
A abordagem operacional do CRM visa melhorar o relacionamento direto entre a
empresa e o cliente através de canais como a internet ou call centers. Tais melhorias
advêm do agrupamento de informações com o intuito de se obter, com maior precisão, o
perfil do cliente. Isso faz com que a empresa esteja bem preparada na hora de se relacionar
com o mesmo. Além do mais, esta abordagem se caracteriza através da aplicação da
tecnologia de informação objetivando melhorar a eficiência do relacionamento entre os
clientes e a empresa. Estão entre as tecnologias ou produtos de CRM operacional as
aplicações de automação de força de vendas (SFA), automação de canais de venda,
sistemas de comércio eletrônico e call centers. O CRM operacional prevê ainda a
22
integração de todos os produtos de tecnologia para proporcionar o melhor atendimento ao
cliente (PEPPERS AND ROGERS, 2001).
Por sua vez, a estratégia analítica do CRM trata como o próprio nome diz da análise
dos dados sobre o cliente nas várias esferas da organização. Esta permite descobrir entre
outras informações o grau de fidelização dos clientes, seus diferentes tipos, além das
preferências e rejeições quanto a produtos e serviços. A ligação entre um CRM de
abordagem analítica com um data mart para o setor marketing e/ou vendas é inevitável,
pois juntos oferecem grande auxílio na busca de respostas importantes no que diz respeito
às questões de negócio (PEPPERS AND ROGERS, 2001).
A principal característica da abordagem colaborativa do CRM está na possibilidade
de criar, aumentar e gerenciar a interação com o cliente. Para isso é necessário que a
empresa tenha um meio adequado para a interação - abordada no CRM operacional - e que
possua informações suficientes sobre seus clientes - obtidas através do CRM analítico - de
forma centralizada e, é claro, integrada. Além do mais, a abordagem colaborativa do CRM
procura integrar as estruturas e benefícios dos outras duas abordagens descritas. Enquanto
o CRM operacional está mais focado nos níveis tático e operacional, e o CRM analítico
nos níveis estratégico e tático, o colaborativo procura gerar melhorias nos três níveis
(PEPPERS AND ROGERS, 2001).
23
3. O SETOR DE VAREJO SUPERMERCADISTA NO BRASIL
3.1. Caracterização
A caracterização do setor de varejo supermercadista, dá-se pelo entendimento do
conceito de supermercados, lojas de auto-serviços e varejo alimentar.
Segundo Parente (2000, p. 32),
“os supermercados caracterizam-se pelo sistema auto-serviço, check outs (caixas
registradoras sobre balcão na saída da loja) e produto dispostos de maneira
acessível, que permitem aos fregueses “auto-servirem-se”, utilizando cestas e
carrinhos. [...] A maioria das redes de supermercados no Brasil opera grande
número de lojas que são classificadas como supermercados convencionais”.
De acordo com Rojo (apud ACNIELSEN, 1997) os locais que comercializam
alimentos se classificam em duas categorias, tradicionais e de auto-serviço. As tradicionais
são aquelas nas quais há necessidade de vendedores ou balconistas dispensando maior
atenção aos clientes no que se refere à prestação de informações sobre produtos e serviços
comercializados. Já as lojas de auto-serviços, além de serem enquadradas como
alimentares, têm como característica principal os check outs, ou seja, um ponto de venda
(PDV) equipado com emissor de cupom fiscal (ECF), calculadoras ou quaisquer outros
equipamentos que permitam totalizar e conferir as compras dos clientes. A exposição dos
produtos, neste tipo de estabelecimento, dá-se de maneira acessível, ou seja, permitindo
que os clientes se auto-servirem.
No Brasil, de acordo com Cyrillo (1987), a atividade supermercadista foi
regulamentada em 1968 através da Lei 7208, de 13/11/1968, ficando estabelecido o
seguinte: “supermercado é um estabelecimento de comércio varejista que, adotando o
sistema de auto-atendimento, coloca à disposição e vende gêneros alimentícios e outras
utilidades domésticas”.
24
A “relação tipo de loja” e “área utilizadas para realizar a venda (m2)” define a
característica do comércio de varejo alimentar. O quadro 1 a seguir apresenta uma idéia de
como acontece esta caracterização (DELUCA, 2001):
QUADRO 1 – VAREJO ALIMENTAR – TIPO DE LOJA Tipo de Loja Área de Venda (m2)
Bares 20 – 50
Mercearias 20 – 50
Padarias 50 – 100
Mini-mercados 50 – 100
Loja de Conveniências 50 – 250
Supermercado Compacto 300 – 700
Supermercado Convencional 700 – 2500
Superloja 3000 – 5000
Hipermercado 7000 – 16000
Clube Atacadista 5000 – 12000 Fonte: adaptado de DELUCA, Marcelo A. M. Varejo supermercadista da grande Florianópolis: uma análise das cinco forças competitivas de Porter. Florianópolis: 2001. Pág. 41.
Além da relação “tipo de loja” com “área de venda”, outra forma de classificar o
varejo alimentício está vinculada ao “mix de produtos” (variedade de produtos ofertados),
onde, de acordo com Bermann e Evans (1998), existem cinco tipos de varejista alimentar:
1. Lojas de conveniência, onde sua localização, geralmente, fica em postos de
combustíveis;
2. Supermercados convencionais;
3. Lojas de combinação;
4. Superlojas;
5. Lojas de sortimento reduzido.
25
Vale ressaltar, com exceção das lojas de conveniência, que todos os serviços acima
trabalham com concepção de auto-serviço, ou seja, todos são considerados supermercados.
O quadro 2 a seguir explicita esta situação:
QUADRO 2 – CLASSIFICAÇÃO DE TIPOS DE VAREJO
Fonte: adaptado de DELUCA, Marcelo A. M. Varejo supermercadista da grande Florianópolis: uma análise das cinco forças competitivas de Porter. Florianópolis: 2001. Pág. 43. 3.2. Desenvolvimento do Setor Supermercadista no Brasil
É notória a importância deste setor na economia brasileira, já que desde sua
implantação no Brasil, segundo Nogueira (1993, p.3), há quarenta anos, o setor tem
desempenhado um papel fundamental dada à ênfase à colocação de produtos à disposição
do consumidor brasileiro. Desde os primeiros ensaios de auto-serviço no comércio
varejista, no final dos anos 40, até o surgimento, a partir da década de 60, das grandes
redes em funcionamento atualmente no país, os supermercados têm se transformado
Tipo de Varejo Localização Linha de Produto Preço
Lojas de Conveniências Próxima Amplitude Média Médio e acima do médio
Supermercado Convencional Próxima Grande Sortimento Competitivo
Loja de Combinação Local Isolado Produtos de drogarias e supermercados
Competitivo
Superloja Local Isolado Sortimento completo, incluindo produtos estéticos, veículos, saúde, etc.
Competitivo
Lojas de Sortimento reduzido Próxima Pequeno Sortimento Bastante baixo
26
rapidamente movidos pelo desejo de atender novos padrões de consumo, além de
acompanhar o desenvolvimento da sociedade e da economia brasileira.
Ainda de acordo com Nogueira (1993), os supermercados estão presentes desde os
grandes centros urbanos até as mais remotas localidades, possibilitando a geração de um
número significativo de emprego e movimentando algo em torno de 5% do Produto Interno
Bruto (PIB) brasileiro, além de ser uma excelente via explorada pela indústria de bens de
consumo para que seus produtos cheguem, de forma eficiente e barata, a milhões de
consumidores.
A evolução do setor supermercadista no Brasil fez com os preços fossem deixados,
até certo ponto, em segundo plano, para focalizar-se na oferta de serviços. A disposição
das lojas tendeu a ficar cada vez mais aprimoradas e sofisticadas, quer do ponto de vista
arquitetônico, quer da decoração e da própria exposição das gôndolas - local nas quais são
expostos os produtos à venda. A embalagem ganhou, assim, papel cada vez mais
importante, atender às necessidades de apelo visual para fortalecer a marca e para o
manuseio mecanizado e de controle, este, cada dia mais automatizado. As metas
permanentes, eficiência e rentabilidade, passaram a ser buscadas, também, com a melhoria
dos serviços de retaguarda, na formação de pessoal especializado e na solidificação da
estrutura administrativa das empresas (FERRAZ, 2002, p.54).
3.3. Perfil do Setor Supermercadista Brasileiro
De acordo com o 1º estudo anual do setor supermercadista, realizada pela ABRAS -
Associação Brasileira de Supermercados - (1998), e análises feitas por Ferraz (2002), em
sua dissertação, o setor supermercadista brasileiro se comporta, de maneira geral, da
seguinte forma:
27
• A fidelidade dos consumidores é o que mais preocupa os supermercadistas;
• Em média, 85% das vendas do setor são produtos alimentares (perecíveis e não
perecíveis) e de higiene e limpeza;
• Fatores de riscos externos para o negócio, com a política econômica e fiscal do
governo, é que mais preocupa o setor;
• A “ação de concorrência” que mais impacta neste ramo de negócio é a “guerra de
preços”;
• O porte da empresa supermercadista influencia diretamente no número de
estratégias de crescimento. Por outro lado, investimento em ampliação de lojas e
ações de melhorias acontece com freqüência em todos os portes;
• Pesquisa de satisfação junto aos consumidores é uma das ações competitivas mais
praticadas neste setor;
• Os canais de mídia mais utilizados são o rádio e folhetos distribuídos fora da loja;
• Os critérios de escolha do local de compra mais considerados pelos consumidores,
segundo os próprios supermercadistas e resultados de pesquisas com os clientes,
são as condições de pagamento e o preço;
• Capacitação e treinamento do pessoal são as questões de recursos humanos de
maior preocupação;
• Os supermercados de menor porte estão mais preocupados com os processos
voltados ao consumidor, enquanto de maior porte com a eficiência operacional.
28
3.4. Perfil dos Consumidores do Setor Supermercadista Brasileiro
Ainda de acordo com as conclusões do 1º estudo anual do setor supermercadista e
apreciações de Ferraz (2002), o consumidor setor supermercadista brasileiro se comporta,
de maneira geral, da seguinte forma:
• A forma de pagamento mais utilizada pelos consumidores é em dinheiro;
• “Ir a pé” ao supermercado é a forma de locomoção mais usada entre os
consumidores;
• Dentre os consumidores entrevistados, ou pouco mais da metade é fiel a um único
supermercado;
• O principal critério de escolha para comprar em determinado supermercado ainda é
o item “preço baixo”;
• O que mais chama atenção do consumidor no que se refere às melhorias efetuadas
nas lojas e ações para enfrentar a concorrência, por parte dos supermercadistas, é:
preços mais baixos e maior rapidez nos caixas;
• Múltiplas variedades de opções e ambiente agradável elegeram o shopping center
como o local preferido para as compras em supermercados;
• Apenas 25% da população têm hábito de comprar comida pronta com freqüência
média de uma vez por mês. Deste total, apenas 15% compra em supermercados;
• Cerca de 60% dos consumidores entrevistados sentem-se “seguros/muitos seguros”
quando se fala em qualidade dos produtos vendidos em supermercados. O que mais
como principal ameaça à segurança dos produtos, são aspectos ligados à “operação
e manuseio” das mercadorias.
29
3.5. O Setor Supermercadista e a Estratégia de CRM
Segundo Ferraz (2002), quando se fala em fidelização de clientes neste segmento
de comércio, pode-se dizer que um pouco mais da metade são fieis. O que explica este
comportamento do consumidor supermercadista são basicamente três situações. A primeira
refere-se à conjuntura econômica do país, onde uma atmosfera composta por baixo índice
inflacionário e a instabilidade profissional incentiva à comparação de preços por partes dos
consumidores, tornando-os mais preocupados com o assunto preço.
A segunda situação está ligada à oferta de uma quantidade expressiva de diferentes
produtos e marcas nos quais os consumidores estão expostos. Com isso, as lojas
supermercadistas tornam-se mais diferenciadas, e os consumidores mais seletivos e menos
fieis uma única marca de supermercado.
A terceira e última situação diz respeito à saturação do mercado varejista, criando
um ambiente mais acirrado e competitivo, permitindo aos consumidores mais opções de
locais de compra dentro de uma determinada localização.
Isso nos mostra que para manter-se competitivo, em certas ocasiões, é crucial por
parte dos supermercadistas, a adoção de estratégias ligadas ao CRM já que este foco prevê
muito das necessidades do cliente e reduz drasticamente, se corretamente aplicadas, vários
problemas do setor, em especial a questão da fidelização.
30
4. DATA WAREHOUSE COMO SUPORTE AO CRM ANALÍTICO
4.1. Definição
Um dos principais objetivos da tecnologia da informação nas organizações é
converter dados históricos em informação e por conseqüência em conhecimento
estratégico. O data warehouse, de uma maneira simples, existe para responder questões
que as pessoas têm sobre os negócios da organização, ou seja, é uma ferramenta concebida
para atender o propósito da centralização das informações, apresentação multidimensional
dos dados, facilidade na descoberta de padrões e para proporcionar aos gestores maior
agilidade na tomada de decisão. Além disso, o DW possui uma aplicação mais acentuada
em empresas que possuem informações descentralizadas e com deficiência nos processos
operacionais para a sumarização dos dados. Esta carência, geralmente, compromete o
processo de tomada de decisão.
Kimball (1998), uma figura respeitada no assunto, define DW como sendo um
recurso de consulta e apresentação dos dados de negócio da empresa, construído
especificamente para este fim.
Já Inmon (2002), outro guru no assunto, definiu DW como sendo uma coleção de
dados integrados, orientada por assuntos, variante no tempo e não volátil, que tem por
objetivo dar suporte aos processos de tomada de decisão.
4.2. Características do Data Warehouse
Em geral, os DWs possuem diversas características que os diferem dos bancos de
dados operacionais, os OLTPs (On Line Transactional Processing), uma das principais
31
fontes de informações para os DWs. Uma dessas características é que os dados são
consultados numa única fonte de dados, consolidada através de um banco de dados
separado da base de dados operacional, e organizado para armazenar conhecimentos sobre
o negócio. A separação das bases operacionais impede a perda de desempenho no processo
operacional da organização. Além do mais, o DW apresenta uma arquitetura diferente da
base de dados transacional, ou seja, a criação deste tipo de banco de dados atende a
requisitos específicos como, por exemplo, a modelagem dimensional, questão que será
abordada mais adiante.
Logo abaixo, descreveremos em maior detalhe outras características do DW.
4.2.1. Integração
A integração refere-se à centralização e padronização dos dados, já que os DWs
recebem e agrupam registros de vários sistemas operacionais, tendo de harmonizá-los e
padronizá-los, além de resolver questões como informações incompatíveis, duplicadas ou
inexistentes. Um exemplo disso está representado na figura abaixo:
Figura 2 - Padronização de dados no data warehouse Fonte: Adaptado de Andreatto (1999)
4.2.2. Orientação por Assunto
A orientação por assunto é uma das características mais marcantes de um DW, já
que toda construção da modelagem será realizada em torno dos principais assuntos da
empresa. Enquanto todos os sistemas operacionais estão voltados para processos e
aplicações específicas, os DWs objetivam assuntos. Podemos considerar assuntos como
sendo o conjunto de informações relativas à determinada área estratégica de uma empresa.
Figura 3 - O data warehouse tem uma forte orientação por assunto Fonte: Adaptado de Andreatto (1999)
4.2.3. Variação no Tempo
Em relação à variação no tempo, Imon (2002) frisa em sua publicação que os DW
são variáveis no decorrer do tempo, significando que podemos manter o histórico dos
dados durante um período de tempo muito superior ao dos sistemas operacionais.
Figura 4 - Comparação de variação do tempo: sistema operacional versus data warehouse Fonte: Adaptado de Andreatto (1999)
33
4.2.4. Não Volatilidade
A não volatilidade significa ter somente duas operações no DW, a carga inicial ou
incremental e as consultas aos dados. Isso pode ser afirmado porque a maneira como os
dados são carregados e tratados é completamente diferente dos sistemas transacionais.
Enquanto nesses sistemas temos vários controles e atualizações de registros, no DW temos
somente inserções e seleções de dados. Por exemplo, num sistema de contabilidade
podemos fazer alterações nos registros. Já no DW, o que acontece é somente ler os dados
na origem e gravá-los no destino, ou seja, no banco multidimensional.
Figura 5 - Não volatilidade do data warehouse Fonte: Adaptado de Andreatto (1999)
4.2.5. Granularidade
Esta característica nada mais é do que o nível de detalhamento ou de resumo dos
dados que compões um DW. Quanto menor for o nível de detalhes, maior será o nível de
granularidade. O nível de granularidade está diretamente ligado ao volume de dados
contidos no DW, e ao mesmo tempo o tipo de consulta que pode ser respondida.
34
Quando se tem um nível de granularidade muito alto, o espaço reservado para
armazenamento dos dados, tornam-se bem menores, porém há uma diminuição da
possibilidade de utilização dos dados para atender a consultas detalhadas ou complexas.
Um exemplo esclarecedor é a venda de certo produto em um supermercado, pois o
nível de granularidade muito baixo pode ser caracterizado pelo armazenamento de cada
uma das vendas ocorridas para este produto, e um nível muito alto de granularidade seria o
armazenamento dos somatórios das vendas ocorridas em um mês.
Se levarmos em conta o nível de granularidade muito baixo, é possível responder a
praticamente qualquer consulta, mas uma grande quantidade de recursos computacionais é
necessária para responder perguntas muito específicas. No entanto, no ambiente de DW,
dificilmente um evento isolado é examinado, é mais provável que ocorra a utilização da
visão de conjunto dos dados.
Figura 6 - Nível de granularidade do data warehouse Fonte: Adaptado de Andreatto (1999)
4.3. Componentes do Data Warehouse
Os principais componentes de um DW serão mostrados na figura 7 e discutidos a
seguir:
35
Figura 7 - Componentes do data warehouse Fonte: Adaptado de Kimball (1998, p. 15)
Segundo Kimball (1998), sistemas transacionais, também conhecidos com sistemas
legados, são responsáveis por registrar todas as transações de negócios de uma
organização. Dentre suas características, a velocidade de resposta de uma transação, ou
seja, inclusão, exclusão, alteração e pequenas consultas de dados, são essenciais para um
bom funcionamento destes. Outra característica deste componente do DW é a sua
capacidade reduzida de armazenamento do histórico das transações, variando entre dois a
três meses de histórico.
A área de estagiamento é o ambiente que suporta os dados vindos de diversas fontes
transacionais e com diversos formatos para que sejam padronizados, ou seja, deve
implementar os processos de extração, transformação e carga dos dados (CRAIG, 1999),
também conhecido como processo ETL.
No processo de ETL, a tarefa de extração de dados consiste em analisar os dados
dos sistemas fontes, além de especificar as rotinas de extração (Pereira, 2000). Uma vez
que os dados tenham sido extraídos dos sistemas transacionais, um conjunto de
transformações deve ser processado sobre esses dados. A transformação pode ser simples
ou complexa, dependendo da natureza dos sistemas fontes. Em algumas situações,
múltiplos estágios de transformações são necessários (Pereira, 2000). Por último, a tarefa
����
36
de carga de dados é geralmente um item complexo, e leva em conta à integridade dos
dados que irão popular o Servidor de Apresentação. Segundo a definição de Kimball
(1998) Servidor de Apresentação é aquele onde os dados do DW estarão disponíveis e
preparados para serem visualizados e analisados diretamente pelos usuários finais.
Quando falamos em apresentação de dados em DW, é imprescindível levarmos em
que conta que os dados devam estar armazenados em um modelo dimensional ou
multidimensional. Este modelo, segundo Kimball (1998), é um tipo de modelagem de
dados que vai ao encontro ao modelo entidade relacionamento, possuindo algumas
características deste, mas por outro lado, tem a finalidade de organizar os dados de forma a
melhorar a compreensão do modelo, aperfeiçoar a velocidade das consultas e facilitar
alterações no modelo.
Os elementos que compõem o modelo dimensional são os fatos e as dimensões. O
fato, usualmente representado de forma numérica e aditiva, descreve as medidas do assunto
modelado, as métricas do negócio. As dimensões representam as características e
informações acerca do fato. O conjunto de atributos da dimensão servirá para restringir e
agrupar os fatos nas consultas realizadas.
A implantação física deste modelo geralmente acontece um bando de dados
relacional, e foi chamado por Kimball (1998) e Berson e Smith (1997) de “esquema
estrela”, devido este implementar de forma precisa a modelagem dimensional.
O esquema estrela, representado a seguir na figura 8, consiste basicamente em uma
tabela central, a tabela de fato, com enorme volume de dados, rodeados por pequenas
tabelas, as dimensões. As tabelas periféricas possuem chaves primárias artificiais simples,
que são referenciadas pela tabela de fato. O conjunto de chaves estrangeiras da tabela
central compõe a sua chave primária. Temos geralmente a tabela de fato normalizada e as
tabelas de dimensões não normalizadas.
37
Figura 8 - Exemplo de um modelo estrela Fonte: Adaptado de Benson & Smith (c1997, p. 171)
Por último, para facilitar o acesso e apresentação dos dados aos usuários finais,
contidos no Servidor de Apresentação, temos como suporte as aplicações de Usuário Final.
Estas são ferramentas responsáveis pelo processo de exploração de dados, dotadas de
tecnologia OLAP (On-Line Analytical Processing), que têm como característica principal a
visualização multidimensional dos dados. Existem quatro tipos de visualizações básicas:
• Drill down;
• Drill up o Roll up;
• Slice;
• Dice.
Drill down e Drill up movimentam as visões ao longo das hierarquias, enquanto o
Slice e Dice realização operações de navegações sobre os dados. O uso destes quatro tipos
de visões ou operações sobre um modelo dimensional cria uma visão no formato de um
cubo.
38
A figura 9 dá uma idéia da representação de um cubo. Pode-se verificar as
dimensões tempo, produto e cliente. A inclusão de dados no DW passa uma idéia de
crescimento na largura, comprimento e profundidade do cubo.
Figura 9 - Exemplo de cubo Fonte: O autor
4.4. Metodologia para Construção de Data Warehouse
Atualmente, a tecnologia de DW conta basicamente com duas abordagens de
implementação, a top-down e a bottom-up. Mas, para compreendermos melhor estas
abordagens, se faz necessário conhecer o conceito de Data Mart (DM).
Os DMs, ou o DW em departamentos, são subconjuntos lógicos de um DW. Para
se diminuir o tempo e os custos totais de construção, podemos dividir um DW em partes
menores, distribuídas por departamentos ou assuntos inerentes ao negócio da organização.
As diferenças entre DM e DW são apenas em relação ao tamanho e ao escopo do
problema a ser solucionado. Como o DM está direcionado a uma área específica da
organização, o planejamento e análise do mesmo são mais fáceis de gerenciar.
Na abordagem top-down, sustentada por Inmon (2002), o objetivo é conquistar para
depois dividir, tendo como premissa a modelagem e a construção de todo DW, dotado de
39
todas as informações acerca do negócio e da empresa. Depois disto, disponibilizam-se os
data marts.
Na bottom-up, defendida por Kimball (1998), a idéia é dividir para depois
conquistar. Primeiramente são construídos os DMs, atendendo as necessidades setoriais de
informações, e tendo como critério de ordem de construção a prioridade para o negócio. A
reunião de todos os DMs comporá o DW como um todo. Esta abordagem é detalhada mais
a fundo no item a seguir, através do Ciclo de Vida do DW.
4.4.1. “O Ciclo de Vida de Kimball”
O sucesso de um projeto de DW depende da definição do ciclo de vida que atenda
todas as etapas do processo de desenvolvimento. Kimball (1998) propôs um modelo de
ciclo, que compreende os principais processos de construção de um DW.
Segundo ele, o planejamento é a fase onde são definidos o escopo e justificativa
para o projeto, levantando também as necessidades de recursos de hardware, software e de
recursos humanos para o desenvolvimento do DW. O escopo deve ser definido de forma a
ser algo significativo para empresa e que garanta continuidade do projeto. Além disso, a
definição da equipe e a abordagem para o desenvolvimento fazem parte desta etapa.
A definição dos requisitos de negócio é responsável por toda a especificação do
DW. Acompanham esta fase tarefas como: especificação de regras de negócio, desenho da
arquitetura, modelagem dimensional, escolha de software para DW, instalação de hardware
e software, etc. A metodologia recomenda para esta etapa, constitui na realização de várias
entrevistas com os usuários que dominam a regra de negócio, de forma que as informações
coletadas possam ser úteis na modelagem e implementação. O item mais importante da
40
fase de levantamento de requisitos é a modelagem dimensional, que servirá de base para a
implementação do DW.
O desenvolvimento é a fase onde o DW cria forma. É neste instante que os dados
devem ser populados e os cubos dimensionais devem ser gerados para obter-se o resultado
final do projeto, porém o ciclo ainda não termina, sendo necessário um ciclo contínuo de
aperfeiçoamento e melhoria dos processos, ou seja, o DW deve acompanhar o crescimento
dos processos da empresa.
Planejamento do Projeto
Definição dos
Requisitos de
Negócio
Modelagem Dimensional FProjeto
Desenvolvimento e Projeto da Área
de Transição
Implantação e
Manutenção
Especificação da Aplicação do Usuário
Final
Desenvolvimento da Aplicação do
Usuário Final
Projeto e Arquitetura
Técnica
Instalação e Seleção de Produtos
Administração do Projeto
Figura 10 - Ciclo de vida de um DW Fonte: Adaptado de Kimball (1998, p.33)
4.5. Aplicação do Data Warehouse no processo de CRM Analítico
Um DW bem modelado e que atenda todos os requisitos impostos pela organização
pode ser usado como uma poderosa ferramenta de CRM analítico, pois permite que
empresa conheça o perfil de seu cliente, e a partir daí fazer um trabalho dirigido à sua
fidelização. Como vimos anteriormente, é muito mais lucrativo manter um cliente do que
tentar conquistar novos. A diferença de lucratividade para a empresa fica mais explícita
quando um cliente fidelizado é comparado com cliente perdido pela empresas que terá de
ser reconquistado.
41
Como sabemos, o CRM operacional é feito através do contato direto da empresa
com o cliente. Call centers, malas diretas, internet e outros tipos de canais são utilizados
nesse segmento de CRM, que em alguns casos, para agilizar estes processos, utiliza-se do
CRM analítico, este feito através dos dados contidos nas bases gerenciais da empresa, ou
seja, no Data Warehouse.
Contudo, o DW deve contemplar as análises de campanhas de marketing, perfil do
cliente, análise de vendas, fidelidade, desempenho dos canais de contato, entre outras
análises que fazem parte do CRM analítico.
42
5. JUSTIFICATIVA PARA ADOÇÃO DA METODOLOGIA
Primeiramente, foi apresentada no capítulo 2 a conceituação de CRM para
posteriormente caracterizar o comércio de varejo supermercadista em nosso país e as
justificativas para adoção de estratégias de CRM por parte deste.
No capítulo 4, foram abordadas técnicas de data warehousing, apresentando seu
conceito e surgimento, aplicações e metodologias de construção.
No entanto, a finalidade deste capítulo é propor uma solução através da aplicação
das técnicas expostas visando resolver às dificuldades enfrentadas no processo de análise
de informações de clientes, principalmente o que diz respeito ao hábito de compra dos
mesmos.
Como justificativa para escolha da especificação de um data mart de clientes está
intimamente ligada ao fato de que atualmente gestores da área de CRM, especialmente em
pequenos e médios supermercados, utilizam-se de complexas pesquisas para extrair e
transformar as informações de que precisam do banco de dados operacional. Estes
procedimentos geralmente terminam em uma exploração por cruzamento e quantificação
dos dados. Este tipo de procedimento assemelha-se a uma análise exploratória parecida
com a tecnologia OLAP, vistas anteriormente e, sem sombra de dúvidas, suportada pelo
ambiente de DW.
Outra situação relevante é a dependência existente entre o gestor de CRM e o
departamento informática da organização na obtenção das respostas de questionamentos
complexos sobre os clientes. A união da tecnologia OLAP com a de DW praticamente
eliminará esta dependência, já que determinadas repostas estarão acessíveis com poucos
cliques do mouse.
43
Como metodologia para especificação do data mart será realizada uma adaptação
do modelo “Ciclo de Vida de Kimball” visto anteriormente, com o intuito de adequá-lo ao
propósito deste trabalho. Além do mais, este modelo é adequado para uso na abordagem
bottom-up, conforme vimos no sub-capítulo “Metodologia para Construção de Data
Warehouse”, ou seja, é adequado para a construção do Data Mart de Clientes.
5.1. PLANEJAMENTO DO PROJETO DO DATA MART
O planejado é a fase inicial do projeto de um data mart, tendo como principal
objetivo a definição do escopo. Podemos considerar esta fase como sendo a mais
importante do projeto, pois erros na delimitação do escopo, identificação de necessidades,
restrições e recursos (humanos, equipamentos, financeiro, etc.) podem inviabilizar a
realização do projeto.
Como parte do planejamento tem-se a etapa de definição do escopo onde serão
descritos as metas e objetivos a serem galgados com a execução do projeto. Nesta
importante fase é identificada a existência e a origem de demanda.
Partindo para elaboração do plano, foi realizado um levantamento sobre as
características da empresa, onde foram identificados potenciais usuários e suas
necessidades, além de se conhecer brevemente pontos estratégicos do negócio e como são
acompanhados, bem como identificar os processos centrais da organização para posterior
priorização, que no caso deste trabalho, não se teve muito esforço devido à definição do
problema já estar formulado.
44
5.1.1. Definição do Escopo
5.1.1.1. Introdução
Este trabalho teve como base para definição de escopo um supermercado da grande
Florianópolis/SC, que atua no mercado há cerca de sete anos e desejava obter maior
agilidade na aquisição de informações inteligentes e úteis do cliente. Espera-se com isso
aperfeiçoar seus processos, além de visualizar informações implícitas em seu sistema
transacional em uso atualmente. Outra expectativa depositada no projeto consiste em
aprimorar e auxiliar as tomadas de decisões estratégicas da empresa, principalmente o que
tange a CRM.
A empresa conta, em sua loja no centro da cidade, com um quadro funcional de 200
colaboradores sendo que aproximadamente 30 destes lidam diretamente com informações
gerencias. Além disso, um gestor de CRM e uma equipe com oito integrantes ligados a
projetos voltados para o relacionamento com o cliente contribuem diretamente.
O projeto teve foco nas rotinas operacionais que geram dados através das
transações de vendas ao cliente e visa obter conhecimento mais profundo e detalhado deste
processo, respondendo principalmente questões à margem dos processos operacionais, e de
grande valia nos procedimentos de tomada de decisão e visão estratégica.
5.1.1.2. Justificativa
Como justificativa para elaboração deste projeto, viu-se a relação das situações que
permitiram avaliar a importância do mesmo em relação à organização. Ele deveria:
• Apresentar dados relativos à suas compras rotineiras, buscando traçar um perfil da
clientela atual;
• Relatar a margem de contribuição – diferença do preço de venda do produto
45
descontado do seu preço de custo – em cada venda de cliente identificado através
do cartão de fidelização;
• Sumarizar valor de cupom fiscal médio por cliente e da loja;
• Refletir o impacto das campanhas promocionais ou dados que possam definir
aplicações mais efetivas das mesmas;
• Prover dados estatísticos relativos à importância de se manter ou não programas de
fidelização, descontos especiais, ou outras estratégias comerciais;
• Cruzar informações do tipo de pagamento com perfil de compra de cada cliente.
5.1.1.3. Escopo
O projeto conta com cinco anos de dados históricos, e lida com dados de clientes
que possui cartão de fidelização.
A infra-estrutura computacional utilizada foi a existente e conta com
aproximadamente 40 estações de trabalho, na grande maioria equipada com Sistema
Operacional Linux (Fedora™ e Suse™), servidor composto por dois processadores Intel™
Xeon de 3.06 GHZ, 3 GB de memória RAM, espaço em disco rígido de 100 GB com
redundâncias e proteção à falhas, além do software de banco de dados Oracle™ 10g versão
1.0.3.0 e Sistema Operacional Linux Suse™ Enterprise Server versão 9.0.
Como ferramentas OLAP utilizaram-se planilhas eletrônicas Microsoft Excel™ e
OpenOffice.org™ versão 1.1.2 , além do Discoverer da Oracle™ . O tempo utilizado para
o desenvolvimento do projeto foi de quatro meses.
46
5.1.1.4. Exclusões do Escopo
Tão importante quando a definição do escopo, as exclusões, ou questões deixadas
para serem resolvidas em outro momento, serviram para nortear as ações relevantes e para
gerar uma correta especificação do data mart, contribuindo para não se distanciar dos
objetivos almejados. Foram desconsiderados do projeto:
• Dados de clientes não identificados no momento da venda;
• Produtos de consumo interno e sem vínculo de venda;
• Dados de vendas canceladas.
5.1.1.5. Fatores Críticos de Sucesso
Como fator crítico, levou-se em conta o aproveitamento dos dados de venda gerado
pelo cliente, com o intuito de se conseguir mais oportunidades de torná-lo fiel sem grandes
esforços, bem como tornar a venda de produtos e serviços mais inteligente e lucrativa.
Com o perfil de compra do cliente, foi possível obter uma completa noção de quanto ele
contribuiu para empresa, além de melhorar sua sensibilidade a possíveis interações de
venda e marketing de relacionamento.
Além disso, outras situações que contribuíram para o sucesso do projeto foram:
• A possibilidade de mapear os clientes freqüentadores da loja, podendo assim
fornecer vantagens aos que mais compram;
• Chamar a atenção dos clientes que menos compraram, sem esquecer de
correlacionar o valor agregado de cada compra - volume de compra versus margem
de contribuição;
• Melhorar o tratamento das informações operacionais, trazendo as mesmas para o
nível mais estratégico da empresa de forma clara e concisa para o gestor de CRM;
47
• Obter suporte ao ambiente técnico confiável, com maquinário robusto e tolerante à
falha, além de maior agilidade no processamento e visualização das informações.
5.1.1.6. Levantamento dos Riscos
Conseguir prever os possíveis riscos que o projeto enfrentaria foi de grande valia
para prever e antecipar a resolução de problemas que pudessem prejudicar o sucesso do
projeto. Foram identificados os seguintes riscos:
• Riscos de hardware, como falhas que comprometessem a integridade dos dados;
• Possível sabotagem, interna ou externa do projeto, através de ataques virtuais que
danificassem ou expusessem dados não autorizados;
• Compatibilidade dos sistemas integrados, ou seja, a especificação de uma
padronização coerente dos dados, dando-lhes uma semântica única.
5.2. DEFINIÇÃO DOS REQUISITOS DO DATA MART
Para Kimball (1998) o sucesso de um DW está intimamente ligado ao entendimento
das necessidades e exigências dos usuários que utilização o sistema. Os analistas do projeto
devem entender o fator-chave que norteia o negócio, para determinar, sem sobra de
dúvidas, os requisitos necessários e as expectativas da organização em relação ao projeto.
Resumidamente, os objetivos a serem alcançado no final desta etapa são:
• Detalhes específicos sobre os dados e os elementos principais para incluir numa
implementação inicial do Data Mart;
• Entendimento do uso essencial destes dados iniciais;
• Visão das informações comuns que podem ser usadas por outras áreas da
organização.
48
Uma ferramenta utilizada para levantar os requisitos deste projeto foi a entrevista.
Estas foram realizadas com o gestor de CRM e do TIC (Tecnologia da Informação e
Comunicação) da empresa, tomando-se sempre o cuidado de guiar o levantamento através
de conversas, além de colocar o entrevistado como centro do universo. Durante todas as
etapas das entrevistas o foco principal foi o estudo dos dados e a semântica que os mesmos
denotavam. Além das entrevistas realizadas, foi necessário conhecer mais profundamente a
organização através dos seguintes procedimentos:
• Leitura dos relatórios mensais e anuais da empresa;
• Conhecer a situação financeira da organização;
• Examinar a estrutura e hierarquia da organização;
• Entender as estratégias de marketing da empresa, principalmente aquelas ligadas ao
CRM.
5.2.1. Requisitos Levantados
A análise de perfil e desempenho de compra do cliente foi o desejo dos usuários do
data mart aqui especificado, além de alavancar dados sobre venda para entender melhor o
cliente, produto e desempenho do canal de vendas.
O gestor de CRM e a equipe de projeto ligada ao assunto necessitavam estimar, de
forma rápida e segura, qual o impacto sobre uma possível mudança nas promoções e
preços de alguns produtos seriam destinados a um grupo específico de clientes.
Além disso, existiam perguntas analíticas típicas que precisavam, através da
implementação do data mart, ser respondidas para acesso a informação:
• Qual a recência de um determinado cliente – quando foi sua última compra?
• Qual a freqüência que o cliente compra?
• Qual volume de vendas que a loja teve com um cliente ou grupo de clientes durante
49
certo período?
• Qual é o valor da compra média do cliente em certo período?
• O cliente já participou de uma promoção que termina em três semanas?
• Qual é o comportamento de venda por categorias de produtos e cliente? Há uma
oportunidade para aumentar as vendas? O comportamento mudou durante os
últimos meses?
• Qual a margem de contribuição deixada pelo cliente na compra de uma determinada
categoria produto e em um determinado período?
• Qual o retorno financeiro do cliente, comparando sua margem de contribuição com
o seu volume de compra?
• É possível identificar os clientes oportunistas - aqueles que só compram produtos
em promoção - em um determinado período?
• Qual o canal de venda mais freqüentado por um determinado cliente: internet, 0800
ou loja?
• Quais as regiões geográficas - residência do cliente - mais representativas em
termos de venda?
• Qual freqüência que o cliente adquire produtos considerados de marca própria –
fabricados e comercializados pela própria empresa-?
• Pode-se descobrir informações ocultas ou padrões que mudaram totalmente algumas
estratégias ligadas ao CRM?
É importante ressaltar que os requisitos e questionamentos aqui levantados foram
usados como base para continuação das próximas etapas deste trabalho.
50
5.3. MODELAGEM MULTIDIMENSIONAL
Nesta etapa da metodologia adotada, modelagem dimensional ou multidimensional,
teve como dependência a correta definição dos requisitos funcionais, onde estes servirão de
base para a construção do modelo lógico-dimensional que armazenariam as informações
capazes de responder os questionamentos impostos. Para construí-lo foram necessários três
passos. O primeiro, foi visualizar os assuntos ou o data mart propriamente dito, mostrados
através do levantamento de requisitos. No caso deste trabalho, ficou clara a existência de
um assunto central que seria quantificado ou medido: a venda do cliente.
A segunda etapa foi definir a granularidade, ou nível de detalhamento do fato
venda, a ser seguida. Tratava-se de uma questão essencial para o sucesso do projeto. Foi
selecionada a venda diária sumarizada de produtos por cliente como grão da tabela fato.
Foi o nível mais detalhado possível e possibilitou ao gestor e equipe realizarem análises
minuciosas.
Para qualificar o fato venda fez-se necessário descrever quais seriam as
mensurações adotadas para o mesmo. Com isso foram definidas as seguintes métricas:
quantidade, valor total bruto, valor total líquido e valor da margem de contribuição, média
mensal da margem de contribuição (valor margem de contribuição mensal cliente dividido
pelo número de passagem na loja) e média mensal da venda (valor venda mensal cliente
dividido pelo número de passagem na loja).
A terceira e última, a descrição do fato venda, julgou-se necessário as seguintes
dimensões: tempo em data, tempo em hora, cliente e sua localização geográfica, produto e
suas categorias (foram tratados de famílias, para ficar de acordo a semântica da
organização), forma de pagamento, canal de venda, loja e promoções realizadas. Vale a
pena colocar que as dimensões escolhidas influenciaram diretamente nas respostas de
questões que deveriam ser respondidas.
51
De posse destas informações, foi possível definir o diagrama lógico da modelagem
multidimensional que representou o fato venda descrito a seguir na figura 11.
Figura 11 - Diagrama lógico do Fato Venda
5.3.1. Modelagem Física do Projeto
Na fase de planejamento do projeto, mas precisamente na definição de escopo, foi
definido como pré-requisitos, a utilização do mesmo software SGBD (Sistema Gerenciador
de Banco de Dados) que armazenava os dados transacionais, para acomodar o modelo
físico do data mart.
Como o SGBD Oracle 10g™, atendeu os requisitos não funcionais deste projeto, ou
seja, implementava suporte ao DW, seguiu-se para a definição do modelo físico. Como já
se tinha definido o fato e as dimensões a serem tratadas, buscou-se então identificar os
atributos das dimensões. Novamente, o levantamento de requisitos foi base para esta
definição.
Feita a definição inicial, o próximo passo foi validar os atributos encontrados junto
aos interessados, com o objetivo de eliminar atributos desnecessários ou acrescentarem
novos. O modelo físico resultante do fato venda é mostrado a seguir, na figura 12:
52
Figura 12 - Modelo físico proposto para o data mart de clientes
Após validação da modelagem lógica e física, foram iniciadas as tarefas de
concepção do ambiente, etapa esta que será vista a seguir.
5.3.2. Implantação Física do Modelo Proposto
O ambiente onde foi instalado o data mart, como na etapa anterior, também já havia
sido definido na fase de definição de escopo de projeto, pois se fazia necessário à utilização
do servidor e banco de dados onde atualmente encontra-se em produção o sistema
operacional da organização. Um dos cuidados tomados foi a separação lógica de sistema
operacional do ambiente DW.
Outra questão também definida na fase se escopo foi a camada de apresentação do
data mart e tinha-se como propósito a utilização de três ambientes OLAP: o Microsoft
Excel™, Planilhas do OpenOffice.org™ , além do Discoverer da Oracle™. Estas
53
ferramentas foram consideradas com a própria camada de apresentação dos dados aos
usuários, pois possuíam módulo OLAP de exploração de dados.
Após as definições citadas acima, iniciou-se o planejamento das arquiteturas de
back end e front end do data mart, já direcionadas também ao modelo proposto.
5.3.3. Arquitetura de Aquisição de Dados (Back End)
A primeira atividade, relacionada à definição de como os dados seriam extraídos,
foi explorar o banco de dados operacional e também cumprir um dos objetivos específicos
deste trabalho. Esta tarefa contou com o auxílio do administrador do SGBD da área de TIC
da empresa e teve com meta conhecer a fonte de dados de forma bem detalhada, além de
entender a dinâmica de utilização do banco de dados, uma vez que o processo de ETL
(extração, transformação, carga) e acesso ao data mart estaria sendo executado
paralelamente ao banco de dados transacional.
Optou-se por não criar uma área de estagiamento de dados propriamente dita, já que
existia uma única fonte de dados. Então foi criado o plano do processo de back end,
conforme detalhamento da figura 13.
Figura 13 - Plano para o processo back end
54
No processo de back end, a extração consistiu em acessar e buscar os dados no
sistema transacional, necessários para inserção no Data Mart. Depois de extraídos, eles
sofreram as transformações necessárias, ou seja, foram padronizados de acordo com o
modelo físico proposto, para então serem armazenados na área de checagem ou de
transferência. Aqueles que não necessitaram de modificações foram diretamente levados à
área de checagem.
A área de checagem serviu para que os dados pudessem ser consultados,
manipulados e marcados se foram ou não sincronizados no sentido sistema transacional
data mart, para só então realizar a carga dos fatos.
Este plano foi executado com o auxílio de um conjunto de programas (vide
apêndice B) que providenciaram a conectividade com a fonte de dados, limpeza,
conversões de formato e correções de inconsistências para adequação dos dados ao modelo
proposto. Eles forneceram suporte à linguagem SQL (Structured Query Language), muito
comum nos sistemas de bancos de dados, e a PL/SQL, linguagem de programação
proprietária da Oracle™, utilizada para escrita de Stored Procedures - pequenos programas
em PL/SQL com funcionalidade específica - extremamente eficiente para este projeto.
Finalmente, para controlar a periodicidade do processo ETL, ou seja, realizar a
sincronização dos dados operacionais com os do data mart, foram utilizados os chamados
jobs, também disponibilizados pelo SGBD da Oracle™ e que são que agendamentos no
quais se define o momento em que um determinado procedimento deve ser executado.
5.3.4. Arquitetura de Apresentação dos Dados (Front End)
A camada de acesso aos dados do data mart, a exemplo das etapas anteriores,
também teve seus pré-requisitos de projeto estabelecidos e conhecidos ainda na fase de
planejamento.
55
Além de atender os requisitos definidos no planejamento, as ferramentas adotadas
deveriam proporcionar aos usuários, extrema facilidade nas tarefas de navegação entre os
dados, resumo e comparação, além de trabalhar de acordo com o modelo de dados
implementado.
As ferramentas que atenderam os requisitos foram o MS Excel™ e o
OpenOffice.org™ versão 1.1.2, planilhas eletrônicas que possuem recursos de acesso a
banco de dado e módulo de pesquisa avançada, módulo este composto por um conjunto de
metadados - dados sobre os dados que serão mostrados pelas ferramentas OLAPs - , uma
interface de construção e outra de apresentação de consultas.
Atenção especial teve a ferramenta Discoverer da Oracle™, devido sua utilização
ser feita em larga escala pelos usuários nas rotinas de acesso aos dados transacionais, já
que esta ferramenta dava suporte a dois tipos de ambiente, operacional e DW.
As principais características identificadas no Discoverer foram:
• Ferramenta dotada de visão conceitual multidimensional, suportando o modelo aqui
projetado;
• Interface com usuário amigável e intuitiva, tanto no módulo de administração -
definição e manutenção de metadados - quanto no módulo de usuário, usando
barras de ferramentas e outros recursos básicos que simplificavam a interface;
• Suporte a wizards (assistentes de criação de consultas), que ajudaram bastante na
definição de metadados e na construção de consultas.
Conhecidas as ferramentas da arquitetura de apresentação dos dados, sobrou a
tarefa de planejar a forma de acesso. Experimentou-se inicialmente a ferramenta OLAP
Discoverer por demonstrar flexibilidade de consultas e permitir a criação de condições
associadas à folders (equivalente às tabelas do modelo relacional). Estas condições
favoreceram o uso de vários operadores e conectores lógicos e, conseqüentemente, os
56
usuários, através do uso destas condições, podiam fazer consultas ou criar suas próprias,
extinguindo a necessidade de auxílio da área de informática.
O Discoverer também ofereceu as facilidades básicas de drills e de slice e dice,
assim como pivoteamento – inversão de linhas por colunas em um relatório tabular - além
de permitir que o usuário não fosse obrigado a descer na estrutura de hierarquia passando
por todos os níveis. Se o usuário quisesse poderia pular de facilmente nível na hierarquia
acessada, dando-lhe agilidade no momento da navegação dos dados.
Logo após foi a vez das ferramentas MS Excel™ e Open Office™. O que chamou a
atenção destes aplicativos foi o recurso denominado tabelas dinâmicas, uma interface
OLAP de exploração e cruzamento de informações. Este recurso pode ser alimentado
através de consultas feitas diretamente do data mart ou através da criação de cubo OLAP.
5.4. APLICAÇÃO DO MODELO PROPOSTO
O encerramento de todas as atividades do processo de análise de requisitos e da
configuração de toda arquitetura do sistema, desde aquisição de dados até a camada de
acesso, culminou na colocação do modelo em operação.
Como aplicação do modelo foi realizada a criação das tabelas que acomodaram as
dimensões e os fatos (vide apêndice A), e também dos procedimentos de carga das mesmas
(vide apêndice B).
O que permitiu a validação do modelo e do processo de ETL foi a carga inicial.
Através desta, pode-se avaliar a qualidade das informações, confrontando dados
operacionais como os do DW, e verificar se as perguntas, formuladas no momento da
definição dos requisitos, poderiam se respondidas.
Os resultados obtidos, por sua vez, poderão ser observados no capítulo a seguir.
57
6. RESULTADOS OBTIDOS
Finalmente, todo empenho de modelagem e operacionalização do ambiente foi
finalizado. Durante o processo de construção do data mart se fez necessário realizar
diversas validações do modelo proposto, junto a todos interessados, buscando garantir que
todos os questionamentos realizados na etapa de levantamento de requisitos pudessem ser
respondidos com agilidade aceitável. Serão demonstradas a seguir as respostas obtidas para
algumas das questões levantadas, visando fornecer suporte à validação do modelo.
Considerando que o data mart teve sua criação baseada em dados de clientes reais,
teve-se o cuidado de modificar os dados aqui apresentados a fim de evitar a identificação
dos clientes, inibindo assim a associação da informações apresentadas. Isto se deve ao fato
de haver um contrato firmado entre a empresa e o cliente e este, por sua vez, possuir
cláusulas de confidencialidade.
Para esta demonstração, foram utilizados dados de vendas de clientes realizadas
durante o mês de dezembro de 2004 e o uso da ferramenta Microsoft Excel ™. Isto não
significou que as demais ferramentas OLAP adotadas não foram abordadas, pelo contrário,
todas foram utilizadas para suprir as necessidades dos usuários do data mart, sendo que
todas elas implementam a mesma funcionalidade. Demonstrar todas tornaria esta tarefa
cansativa. Finalmente, o repositório finalizado e explorado permitiu a criação do cubo
OLAP na ferramenta.
Uma das soluções deste trabalho previa a busca de agilidade no processo de análise
dos dados do cliente, sem auxílio da área técnica. O ambiente OLAP encolhido
proporcionou aos usuários conseguir, de forma instantânea e bastante intuitiva, as respostas
dos seus questionamentos.
Para visualizar os ambientes OLAPs disponibilizados, observe as figuras abaixo:
58
Figura 14 - Ferramenta Desktop OLAP Microsoft Excel™, usada nas demonstrações
Figura 15 - Ambiente Desktop OLAP na ferramenta Open Office.org 1.1.2™
59
Figura 16 - Ambiente Desktop OLAP na ferramenta Discoverer da Oracle™
A operação na ferramenta Microsoft Excel™ consistiu em sincronizar de forma
automática os dados do repositório do data mart de cliente e arrastar um item da “Lista de
campos da tabela dinâmica” para o detalhe “Solte seus dados aqui” - veja a figura 14 -,
com objetivo de combinar os campos em busca das respostas procuradas. Esta simplória
operação gerou informações consistentes usadas nas análises que serão vistas a seguir.
Como notação para interpretar as tabelas apresentadas, usou-se a descrição dos
campos com detalhes em negrito e os valores ou dados dos mesmos sem detalhe algum.
Uma pergunta levantada foi qual seria o volume de vendas que a loja X teve com
um cliente ou grupo de clientes durante certo período. O resultado pode ser acompanhado
através da tabela 1:
60
DATA_NORMAL 30/12/2004 NOME_CLIENTE Cliente 1 NOME_LOJA Super Centro Soma de VALOR_VENDA DIA_SEMANA TIPO_CARTAO Quinta-Feira Total geral TITULAR 54,84 54,84 Total geral 54,84 54,84
Tabela 1: Volume de venda de um “Cliente 1” em 30/12/2004
A informação apresentada na tabela 1 permitiu, de forma rápida e segura, levantar
informações de vendas efetuadas ao “Cliente 1” no dia 30/12/2004.
“Qual é o valor da compra média do cliente em certo período?” foi outro
questionamento elaborado na etapa de levantamento de requisitos. A tabela 2 a seguir
demonstra os resultados.
NOME_LOJA Super Centro ANO_MES 2004/12 NOME_CLIENTE Cliente 1002 TRIMESTRE_DO_ANO 4 MEDIA_VENDA_MES MEDIA_MARGEM_MES Dados Total
5,84 1,2 Soma de VALOR_VENDA 210,24
Soma de VALOR_CUSTO 166,73
Total Soma de VALOR_VENDA 210,24 Total Soma de VALOR_CUSTO 166,73
Tabela 2: Média mensal do volume de compra do “Cliente 1002” no quarto trimestre de
2004.
Como pode-se observar, além de responder à pergunta solicitada, a facilidade em
acrescentar informações adicionais foi notória. Observa-se que a informação mostrada na
tabela 2 acima, “MEDIA_MARGEM_MES” - média do preço de venda descontado da
média do custo dos produtos vendidos ao cliente-, relatou ao usuário quanto o “Cliente
1002” contribuiu em média para a empresa no 4º trimestre do ano 2004 e acabou
61
respondendo automaticamente outra questão: “qual o retorno financeiro do cliente,
comparando sua margem de contribuição com o seu volume de compra?”.
Outro questionamento a ser demonstrado é se o cliente participou ou não de
promoção em determinada semana do ano. Suponhamos que o gestor de CRM promovesse
uma campanha com descontos de 15% na 52ª semana do ano de 2004 em produtos da linha
de alimentos infantis, e com isso, gostaria de saber se o cliente X foi sensível ou não ao
apelo. Podemos ver, no caso dos dados da Tabela 3, que o “Cliente 1282” não foi
suscetível à campanha promocional, já que a consulta retornou fazia. O resultado pode ser
visualizado na tabela 3 a seguir.
NOME_LOJA Super Centro ANO 2004 PROMOCAO Desconto de 15 % FAMILIA_PRODUTO Alimentos Infantis NOME_CLIENTE Cliente 1282 SEMANA_DO_ANO 52 Soma de VALOR_VENDA MARGEM_CONTRIBUICAO Total Total geral
Tabela 3: Consulta sem retorno para o “Cliente 282”, no quarto trimestre de 2004.
Finalizando a tarefa do relato dos resultados obtidos, pode-se observar ainda que a
tabela 4 apresenta quais as regiões geográficas – considerando a residência do cliente – são
mais representativas em termos de venda.
NOME_LOJA Super Centro ANO_MES 2004/12 TRIMESTRE_DO_ANO 4 REGIAO Total CENTRO 151.488,40 CONTINENTE 4.406,71 CONVERSOR 10.036,67 LESTE 3.553,94 NORTE 4.506,66 SUL 1.579,32 Total geral 175.571,70
Tabela 4: Regiões geográficas mais representativas em termos de venda, na loja
“Super Centro”.
62
7. CONCLUSÃO
O presente trabalho se dispôs a auxiliar o gestor e equipe de projetos da área de
CRM, no varejo supermercadista, que se utilizam da análise dos dados de clientes para
promover a fidelização, aumento de faturamento e lucratividade da organização.
Para isso, foi fornecida através da construção de um data mart, uma ferramenta
específica que supriu todas as necessidades e requisitos definidos como alvo de atuação
deste trabalho.
Obviamente, como dita o “Ciclo de vida de Kimball”, a utilização rotineira do
produto aqui construído apontará para manutenções e evoluções necessárias, naturais a
qualquer processo, inclusive na construção de data warehouse.
Uma das expectativas deste trabalho foi resolver o problema da dificuldade na
obtenção de informações dos clientes. O fato do processo de extração e preparação dos
dados necessários serem automatizados evitou repetições excessivas de procedimentos
manuais e onerosos na aquisição dos dados e, principalmente, na grande maioria dos casos,
descartou o auxílio da área técnica de informática.
Outro ponto importante vem do fato que a implementação do data mart aqui
proposto deu-se em um ambiente um pouco simples, utilizando-se do mesmo servidor
físico e do mesmo software de banco de dados relacional no qual o produto já é executado
atualmente. Não que a bibliografia da área seja contrária a esse tipo de implementação,
mas em alguns casos vislumbram ambientes ideais com grande estrutura tecnológica. A
utilização da estrutura já existente, por parte deste projeto, gerou baixo custo de construção
e implantação do modelo, unindo o útil ao agradável. Conseguiu-se não criar custos
adicionais e aplicar as técnicas de data warehousing no processo de CRM analítico,
obtendo-se resultados satisfatórios.
63
7.1. Sugestões para Trabalhos Futuros
O anseio por melhores processos de análise dos dados do cliente, ou seja, torná-los
mais ágeis e automáticos, terminará muitas vezes na necessidade de correção e/ou
evolução do modelo aqui proposto.
Como evolução, no que se refere ao fato venda, poderia futuramente levar-se em
conta a quantificação da lucratividade no momento da venda do produto. É importante
ressaltar neste momento que o cálculo e o levantamento desta métrica são de complexidade
elevada, devido às informações contábeis envolvidas.
Por fim, uma evolução natural será através da agregação de novos data marts
visando atender novas necessidades e serviços que já existem ou virão a existir no produto.
Um novo data mart de Atividades de Clientes que teria como característica principal
armazenar as opiniões - elogios, sugestões e reclamações - dos clientes, passando a ser a
parte principal das atividades uma vez que o próprio cliente é que direciona a
comercialização deste ou daquele produto ou serviço, mediante a sua aceitação no
mercado. Uma empresa que conhece bem seus clientes pode trabalhar na solução de
problemas que virão a surgir no futuro ou ainda resolver melhor os problemas surgidos no
presente com o auxílio dos dados obtidos neste tipo de sistema.
64
8. REFERÊNCIAS BIBLIOGRÁFICAS
ACNIELSEN. Estrutura de varejo brasileiro. São Paulo, 1997a
Associação Brasileira de Supermercados. 1º estudo anual do setor de supermercados.
Coord. ABRAS - São Paulo: ABRAS, 1998.
BERMAN, Bary; JOEL, R. Retail management: a strategic appreach. Upper Sadle
River: Prentice Hall, 1998.
BERSON, Alex; SMITH, Stephen J. Data warehousing, data mining and olap. McGraw-
Hill, 1997.
ANDREATTO, Ricardo. Construindo um data warehouse e analisando suas
informações com data mining e olap. Disponível em:
<http://www.datawarehouses.hpg.ig.com.br>. Acesso em: 05 abr. 2005.
CARDOSO, Mario Sérgio; GONÇALVES FILHO, Cid. CRM em ambiente e-business:
como se relacionar com clientes, aplicando novos recursos da web. São Paulo: Atlas,
2001.
DELUCA, Marcelo A. M. Varejo supermercadista da grande Florianópolis: uma
análise das cinco forças competitivas de Porter. 2001. Dissertação (Mestrado em
Administração) – Curso de Pós-Graduação em Administração, Universidade Federal de
Santa Catarina. Florianópolis.
CYRILLO, Denise Cavallini. O papel dos supermercados no varejo de alimentos.
1986. Tese (Doutorado em Economia) – Faculdade de Economia e Administração,
Universidade de São Paulo. São Paulo.
65
FERRAZ, S. F. Uma estratégia para a implantação do gerenciamento do
relacionamento com o cliente - CRM - em supermercados.2002. 109 f. Dissertação
(Mestrado) - Universidade Federal de Santa Catarina. Florianópolis.
CRAIG, Robert S., Microsoft data warehousing building distributed decision support
systems. New York: J. Wiley & Sons Inc, 1999.
INMON, W. H. Building the data warehouse. 3rd ed. New York: John Wiley & Sons,
2002.
KIMBALL, Ralph. The data warehouse lifecycle toolkit: expert methods for designing,
developing, and deploying data warehouses. New York: John Wiley & Sons, c1998.
771p.
NOGUEIRA, Levy. Apresentação. In: Supermercados: 40 anos de Brasil. Coordenação
ABRAS - Associação Brasileira de Supermercados São Paulo: ABRAS, 1993.
PEREIRA, Denise Maciel. Uso do padrão oim de metadados no suporte às
transformações de dados em ambientes de data warehouse. 2000. 217 f. Dissertação
(Mestrado em Informática). Instituto de Matemática e Núcleo de Computação Eletrônica,
Universidade Federal do Rio de Janeiro. Rio de Janeiro.
PARENTE, Juracy. Varejo no Brasil: gestão e estratégia, São Paulo: Atlas, 2000.
PEPPERS AND ROGERS GROUP. CRM series – marketing 1to1. São Paulo: Makron
Books, 2001.
ROJO, Francisco J. G. Supermercados do Brasil: qualidade total, marketing de
serviços, comportamento do consumidor. São Paulo: Atlas, 1998.
Strategy consulting around customer relationship management, CRM. Disponível em
< www.1to1.com>. Acesso em: 15 de ago. 04.
66
SWIFT, Ronald. CRM: o revolucionário marketing de relacionamento com o cliente.
Rio de Janeiro: Campus, 2001.
THOMSEN, E. Olap solutions: building multidimensional information systems. Jonh
Wiley & Sons, 1997.
67
APÊNDICE A
SCRIPTS SQL/DDL UTILIZADOS PARA CRIAÇÃO FÍSICA DO MODELO
PROPOSTO
CREATE TABLE DIM_CANAL ( PK_CANAL NUMBER NOT NULL, NOME_CANAL VARCHAR2 (20) NOT NULL ) ; CREATE TABLE DIM_CLIENTE ( PK_CLIENTE NUMBER NOT NULL, CODIGO_CLIENTE NUMBER NOT NULL, CONTATO_CLIENTE NUMBER (5) NOT NULL, NRO_CARTAOFIDELIZACAO NUMBER (13) NOT NULL, TIPO_CARTAO VARCHAR2 (10) NOT NULL, NOME_CLIENTE VARCHAR2 (50) NOT NULL, TIPO_PESSOA CHAR (1) NOT NULL, TIPO_SEXO CHAR (1) NOT NULL, BAIRRO VARCHAR2 (50) NOT NULL, CIDADE VARCHAR2 (50) NOT NULL, REGIAO VARCHAR2 (20) NOT NULL, DATA_CADASTRO DATE NOT NULL, NUMERO_FAMILIARES NUMBER NOT NULL, GRAU_INSTRUCAO VARCHAR2 (20) NOT NULL, ESTADO_CIVIL VARCHAR2 (20) NOT NULL, RENDA_FAMILIAR VARCHAR2 (30) NOT NULL, DATA_NASCIMENTO DATE ) ; CREATE TABLE DIM_DATA ( PK_DATA NUMBER NOT NULL, ANO VARCHAR2 (4) NOT NULL, MES VARCHAR2 (2) NOT NULL, DIA VARCHAR2 (2) NOT NULL, ANO_MES VARCHAR2 (8) NOT NULL, ANO_MES_DIA VARCHAR2 (10) NOT NULL, EH_FERIADO VARCHAR2 (50) NOT NULL, DIA_SEMANA VARCHAR2 (13) NOT NULL, DIA_SEMANAREDUZIDO VARCHAR2 (3) NOT NULL, DATA_NORMAL DATE NOT NULL, TRIMESTRE_DO_ANO NUMBER (1), SEMANA_DO_ANO VARCHAR2 (3), DIA_DO_ANO VARCHAR2 (3) ) ; CREATE TABLE DIM_FORMAPGTO ( PK_FORMAPGTO NUMBER NOT NULL, CODIGO_PGTO NUMBER (5) NOT NULL, FORMA_PGTO VARCHAR2 (200) NOT NULL ) ; CREATE TABLE DIM_HORA (
68
PK_HORA NUMBER NOT NULL, HORA NUMBER NOT NULL, MINUTO NUMBER NOT NULL, HORA_MINUTO VARCHAR2 (5) NOT NULL ) ; CREATE TABLE DIM_LOJA ( PK_LOJA NUMBER NOT NULL, COD_LOJA NUMBER (5) DEFAULT 0 NOT NULL, NOME_LOJA VARCHAR2 (50) NOT NULL, LOCAL_LOJA VARCHAR2 (50) NOT NULL ) ; CREATE TABLE DIM_PRODUTO ( PK_PRODUTO NUMBER NOT NULL, CODIGO_PRODUTO NUMBER NOT NULL, NOME_PRODUTO VARCHAR2 (50) NOT NULL, CODIGO_FAMILIA VARCHAR2 (8) NOT NULL, SETOR_PRODUTO VARCHAR2 (30) NOT NULL, FAMILIA_PRODUTO VARCHAR2 (30) NOT NULL, SUB_FAMILIA VARCHAR2 (30) NOT NULL, EMBALAGEM VARCHAR2 (20) NOT NULL, QUANTIDADE_EMBALAGEM NUMBER NOT NULL, MEDIDA CHAR (2) NOT NULL, FORMAVENDA VARCHAR2 (11) NOT NULL, PERCENTUALICMS NUMBER NOT NULL, PRODUTO_MARCAPROPRIA CHAR (1) NOT NULL ) ; CREATE TABLE DIM_PROMOCAO ( PK_PROMOCAO NUMBER NOT NULL, PROMOCAO VARCHAR2 (20) NOT NULL, PERCENTUAL_DESCONTO NUMBER (3) NOT NULL ) ; CREATE TABLE FATO_VENDA ( PK_LOJA NUMBER NOT NULL, PK_CANAL NUMBER NOT NULL, PK_DATA NUMBER NOT NULL, PK_HORA NUMBER NOT NULL, PK_FORMAPGTO NUMBER NOT NULL, PK_CLIENTE NUMBER NOT NULL, PK_PRODUTO NUMBER NOT NULL, PK_PROMOCAO NUMBER (5) NOT NULL, QUANTIDADE NUMBER (10,2) NOT NULL, VALOR_VENDA NUMBER (10,2) NOT NULL, VALOR_CUSTO NUMBER (10,2) NOT NULL, MARGEM_CONTRIBUICAO NUMBER (10,2) NOT NULL, MEDIA_VENDA_MES NUMBER (10,2) NOT NULL, MEDIA_MARGEM_MES NUMBER (10,2) NOT NULL ) ; ALTER TABLE FATO_VENDA ADD CONSTRAINT FK_CANAL FOREIGN KEY (PK_CANAL) REFERENCES DMCLIENTE.DIM_CANAL (PK_CANAL) ;
69
ALTER TABLE FATO_VENDA ADD CONSTRAINT FK_CLIENTE FOREIGN KEY (PK_CLIENTE) REFERENCES DMCLIENTE.DIM_CLIENTE (PK_CLIENTE) ; ALTER TABLE FATO_VENDA ADD CONSTRAINT FK_DATA FOREIGN KEY (PK_DATA) REFERENCES DMCLIENTE.DIM_DATA (PK_DATA) ; ALTER TABLE FATO_VENDA ADD CONSTRAINT FK_FORMAPGTO FOREIGN KEY (PK_FORMAPGTO) REFERENCES DMCLIENTE.DIM_FORMAPGTO (PK_FORMAPGTO) ; ALTER TABLE FATO_VENDA ADD CONSTRAINT FK_HORA FOREIGN KEY (PK_HORA) REFERENCES DMCLIENTE.DIM_HORA (PK_HORA) ; ALTER TABLE FATO_VENDA ADD CONSTRAINT FK_LOJA FOREIGN KEY (PK_LOJA) REFERENCES DMCLIENTE.DIM_LOJA (PK_LOJA) ; ALTER TABLE FATO_VENDA ADD CONSTRAINT FK_PRODUTO FOREIGN KEY (PK_PRODUTO) REFERENCES DMCLIENTE.DIM_PRODUTO (PK_PRODUTO) ; ALTER TABLE FATO_VENDA ADD CONSTRAINT FK_PROMOCAO FOREIGN KEY (PK_PROMOCAO) REFERENCES DMCLIENTE.DIM_PROMOCAO (PK_PROMOCAO) ;
70
APÊNDICE B
PROGRAMAS EM LINGUAGEM PL/SQL UTILIZADOS NO PROCESSO ETL.
CREATE TABLE TABLE_CHECAGEM ( DTTRANSACAO DATE NOT NULL, NUUNIDOPER NUMBER (3) NOT NULL, NUPDV NUMBER (4) NOT NULL, NUCUPOMFISCAL NUMBER (6) NOT NULL, NUEAN VARCHAR2 (13) NOT NULL, HRVENDA VARCHAR2 (5) NOT NULL, NUCLIENTE NUMBER NOT NULL, NUCARTAO VARCHAR2 (13) NOT NULL, QTVENDIDA NUMBER NOT NULL, VLVENDIDO NUMBER NOT NULL, NUPRODUTO NUMBER, PK_LOJA NUMBER, PK_CANAL NUMBER, PK_PROMOCAO NUMBER, PK_CLIENTE NUMBER, PK_PRODUTO NUMBER, PK_HORA NUMBER, PK_DATA NUMBER, PK_FORMAPGTO NUMBER, VALOR_CUSTO NUMBER (10,2), MEDIA_VENDA_MES NUMBER (10,2), MEDIA_MARGEM_MES NUMBER (10,2) ) ; CREATE OR REPLACE PACKAGE "DMCLIENTE_AREACHECAGEM" AS ----------------------------- -- POPULA DIMENSOES -- ----------------------------- PROCEDURE POPULEDIMENSAODATA( VDATAINI IN DATE, VDATAFIM IN DATE ); PROCEDURE POPULEDIMENSAOHORA; PROCEDURE POPULEDIMENSAOFORMAPGTO; PROCEDURE POPULEDIMENSAOLOJA( VNOMELOJA IN VARCHAR2,VLOCALLOJA IN VARCHAR2 ); PROCEDURE POPULEDIMENSAOCANAL( VNOMECANAL VARCHAR2 ); PROCEDURE POPULEDIMENSAOPRODUTO; PROCEDURE POPULEDIMENSAOCLIENTE; PROCEDURE POPULEDIMENSAOPROMOCAO; ----------------------------- -- POPULA FATO VEMDA -- ----------------------------- PROCEDURE POPULEFATOVENDA ( VDATEINI DATE, VDATEFIM DATE );
71
END; / CREATE OR REPLACE PACKAGE BODY "DMCLIENTE_AREACHECAGEM" ----------------------------- -- PACOTE POPULA DIMENSOES -- ----------------------------- AS PROCEDURE POPULEDIMENSAODATA (VDATAINI IN DATE, VDATAFIM IN DATE) IS VDATAINI_NEW DATE := TRUNC( VDATAINI ); VDATAFIM_NEW DATE := TRUNC( VDATAFIM ); VFERIADO VARCHAR(50) := ''; BEGIN WHILE VDATAINI_NEW <= VDATAFIM_NEW LOOP INSERT INTO DIM_DATA (PK_DATA, ANO, MES, ANO_MES, DIA, ANO_MES_DIA,EH_FERIADO, DIA_SEMANA, DIA_SEMANAREDUZIDO , DATA_NORMAL,TRIMESTRE_DO_ANO,SEMANA_DO_ANO,DIA_DO_ANO) VALUES ( SEQUENCIA_PK_DIM_DATA.NEXTVAL, TO_CHAR( VDATAINI_NEW,'YYYY' ), TO_CHAR( VDATAINI_NEW,'MM' ), TO_CHAR( VDATAINI_NEW,'YYYY/MM' ), TO_CHAR( VDATAINI_NEW,'DD' ), TO_CHAR( VDATAINI_NEW,'YYYY-MM-DD' ), FUNCTION_EH_FERIADO( VDATAINI_NEW ), INITCAP( TRIM(TO_CHAR( VDATAINI_NEW,'DAY' ))), UPPER( TO_CHAR(VDATAINI_NEW,'DY') ), VDATAINI_NEW, TO_CHAR( VDATAINI_NEW, 'Q'), TO_CHAR( VDATAINI_NEW, 'WW'), TO_CHAR( VDATAINI_NEW, 'DDD') ); VDATAINI_NEW := VDATAINI_NEW + 1; END LOOP; END POPULEDIMENSAODATA; PROCEDURE POPULEDIMENSAOHORA IS VHORAINI DATE := TRUNC( SYSDATE ); VHORAFIM DATE := TRUNC( SYSDATE + 1 ); BEGIN WHILE VHORAINI < VHORAFIM LOOP
72
INSERT INTO DIM_HORA ( PK_HORA,HORA,MINUTO,HORA_MINUTO ) VALUES ( SEQUENCIA_PK_DIM_HORA.NEXTVAL, TO_CHAR( VHORAINI,'HH24' ), TO_CHAR( VHORAINI,'MI' ), TO_CHAR( VHORAINI,'HH24:MI') ); VHORAINI := VHORAINI + ( 1/24/60 ); END LOOP; END POPULEDIMENSAOHORA; PROCEDURE POPULEDIMENSAOFORMAPGTO IS BEGIN INSERT INTO DIM_FORMAPGTO /*( PK_FORMAPGTO,CODIGO_PGTO,FORMA_PGTO )*/ SELECT SEQUENCIA_PK_DIM_FORMAPGTO.NEXTVAL, NUFINALIZADORA, NMFINALIZADORA FROM SGE.TBCBFINALIZADORA WHERE /*VERIFICAÇÃO DE NOVAS FORMAS DE PGTO */ NUFINALIZADORA NOT IN ( SELECT CODIGO_PGTO FROM DIM_FORMAPGTO ); END POPULEDIMENSAOFORMAPGTO; PROCEDURE POPULEDIMENSAOLOJA( VNOMELOJA IN VARCHAR2,VLOCALLOJA IN
VARCHAR2) IS BEGIN INSERT INTO DIM_LOJA ( PK_LOJA,NOME_LOJA,LOCAL_LOJA ) VALUES ( SEQUENCIA_PK_DIM_LOJA.NEXTVAL, VNOMELOJA, VLOCALLOJA ); END POPULEDIMENSAOLOJA; PROCEDURE POPULEDIMENSAOCANAL(VNOMECANAL VARCHAR2) IS BEGIN INSERT INTO DIM_CANAL( PK_CANAL,NOME_CANAL )
73
VALUES ( SEQUENCIA_PK_DIM_CANAL.NEXTVAL, VNOMECANAL ); END POPULEDIMENSAOCANAL; PROCEDURE POPULEDIMENSAOPROMOCAO IS BEGIN INSERT INTO DIM_PROMOCAO SELECT SEQUENCIA_PK_DIM_PROMOCAO.NEXTVAL, PROMOCAO, PCDESCONTO FROM ( SELECT DISTINCT 'DESCONTO DE '|| TO_CHAR(TRUNC(PCDESCONTO))||' %' PROMOCAO, TRUNC(PCDESCONTO) PCDESCONTO FROM SGE.TBVDPROMOCAO WHERE DTINICIO >='01/01/2000' AND PCDESCONTO >= 0 AND PCDESCONTO <= 100 ORDER BY PROMOCAO ) TEMP_TABLE WHERE PROMOCAO NOT IN (SELECT PROMOCAO FROM DIM_PROMOCAO); END POPULEDIMENSAOPROMOCAO; PROCEDURE POPULEDIMENSAOPRODUTO IS BEGIN INSERT INTO DIM_PRODUTO SELECT * FROM ( SELECT FUNCTION_SEQ_PK_PRODUTO,/* SEQUENCIA_PK_DIM_PRODUTO.NEXTVAL */ NUPRODUTO, NMPRODUTO, NUFAMILIA, (SELECT NMFAMILIA FROM SGE.TBCBFAMILIA WHERE NUFAMILIA = SUBSTR(PRODUTO.NUFAMILIA,1,2)||'.00.00') SETOR_PRODUTO,
74
(SELECT NMFAMILIA AS NMFAMILIA FROM SGE.TBCBFAMILIA WHERE NUFAMILIA = SUBSTR(PRODUTO.NUFAMILIA,1,5)||'.00') FAMILIA_PRODUTO, (SELECT NMFAMILIA FROM SGE.TBCBFAMILIA WHERE NUFAMILIA = PRODUTO.NUFAMILIA) SUB_FAMILIA, SGEMBALAGEM, QTUNIDADEEMBALAGEM, SGMEDIDA, TPFORMAVENDA, PCICMS, (SELECT 'S' FROM SGE.TBCBPRODUTO WHERE NUPRODUTO=PRODUTO.NUPRODUTO AND UPPER(NMPRODUTO) LIKE '%HIPPO%' UNION SELECT 'N' FROM SGE.TBCBPRODUTO WHERE NUPRODUTO=PRODUTO.NUPRODUTO AND UPPER(NMPRODUTO) NOT LIKE '%HIPPO%') PRODUTO_MARCAPROPRIA FROM SGE.TBCBPRODUTO PRODUTO WHERE /* EXCLUSÃO DE PRODUTOS DE CONSUMO PRÓPRIO */ NUFAMILIA NOT LIKE '98%' AND NMPRODUTO NOT LIKE 'PRODUTO EXCLUIDO' AND /*VERIFICAÇÃO DE NOVOS PRODUTOS */ NUPRODUTO NOT IN ( SELECT CODIGO_PRODUTO FROM DIM_PRODUTO ) ORDER BY NUPRODUTO ) TABLE_TEMP WHERE /* EXCLUSÃO DE PRODUTOS DE CONSUMO PRÓPRIO */ FAMILIA_PRODUTO IS NOT NULL; END ; PROCEDURE POPULEDIMENSAOCLIENTE IS BEGIN INSERT INTO DIM_CLIENTE SELECT * FROM ( SELECT * FROM ( SELECT FUNCTION_SEQ_PK_CLIENTE, NUCLIENTE, 0 AS NUCONTATO, (SELECT NUCARTAO FROM SGE.TBCBCLIENTECARTAO WHERE NUCLIENTE = CLIENTE.NUCLIENTE AND NUADICIONAL=0 AND STCARTAO='LIBERADO') AS NUCARTAO, 'TITULAR' AS TIPO_CARTAO,
75
NMRAZAOSOCIAL NOME, TPPESSOA TIPO_PESSOA, FUNCTION_TPSEXO_CLIENTE(SUBSTR(NMSEXO,0,1)) AS SEXO, UPPER(NMBAIRRO) BAIRRO, (SELECT UPPER(NMCIDADE) FROM SGE.TBCBCIDADE WHERE NUCIDADE = CLIENTE.NUCIDADE) AS CIDADE, (SELECT UPPER(NMREGIAO) FROM SGE.TBCBREGIAO WHERE NUREGIAO = CLIENTE.NUREGIAO) AS REGIAO, TO_DATE(DTCADASTRO,'DD/MM/YYYY') DTCADASTRO, (SELECT COUNT(*) +1 FROM SGE.TBCBCONTATOCLIENTE WHERE NUCLIENTE = CLIENTE.NUCLIENTE) NROFAMILIARES, UPPER(FUNCTION_GRAUINSTRUCAO_CLIENTE (NMGRAUINSTRUCAO)) AS GRAUINSTRUCAO, UPPER(FUNCTION_ESTADOCIVIL_CLIENTE(NMESTADOCIVIL)) ESTADOCIVIL, UPPER(FUNCTION_FAIXARENDA_CLIENTE(NMFAIXARENDAFAMILIAR)) FAIXARENDA, DTNASCIMENTO FROM SGE.TBCBCLIENTE CLIENTE WHERE NUCLIENTE IN ( SELECT NUCLIENTE FROM SGE.TBCBCLIENTECARTAO) ) TABLE_TEMP1 WHERE NUCARTAO IS NOT NULL UNION SELECT * FROM ( SELECT FUNCTION_SEQ_PK_CLIENTE, NUCLIENTE, NUCONTATO, (SELECT MAX(NUCARTAO) FROM SGE.TBCBCLIENTECARTAO WHERE NUCLIENTE = CONTATO.NUCLIENTE AND NUADICIONAL = CONTATO.NUCONTATO AND STCARTAO='LIBERADO') AS NUCARTAO, 'DEPENDENTE' AS TIPO_CARTAO, NMCONTATO NOME, 'F' TIPO_PESSOA, FUNCTION_TPSEXO_CLIENTE(SUBSTR(NMSEXO,0,1)) AS SEXO, (SELECT UPPER(NMBAIRRO) BAIRRO FROM SGE.TBCBCLIENTE WHERE NUCLIENTE = CONTATO.NUCLIENTE) BAIRRO, (SELECT UPPER(NMCIDADE) FROM SGE.TBCBCIDADE WHERE NUCIDADE = (SELECT NUCIDADE FROM SGE.TBCBCLIENTE WHERE NUCLIENTE = CONTATO.NUCLIENTE)) AS CIDADE, (SELECT UPPER(NMREGIAO) FROM SGE.TBCBREGIAO WHERE NUREGIAO = (SELECT NUREGIAO FROM SGE.TBCBCLIENTE WHERE NUCLIENTE = CONTATO.NUCLIENTE)) AS REGIAO, TO_DATE(DTCADASTRO,'DD/MM/YYYY') DTCADASTRO, (SELECT COUNT(*) +1 FROM SGE.TBCBCONTATOCLIENTE WHERE NUCLIENTE = CONTATO.NUCLIENTE AND NUCONTATO = CONTATO.NUCONTATO ) NROFAMILIARES,
76
'NAO INFORMADO' GRAUINSTRUCAO, 'NAO INFORMADO' ESTADOCIVIL, (SELECT UPPER(FUNCTION_FAIXARENDA_CLIENTE(NMFAIXARENDAFAMILIAR)) FROM SGE.TBCBCLIENTE WHERE NUCLIENTE = CONTATO.NUCLIENTE) FAIXARENDA, DTNASCIMENTO FROM SGE.TBCBCONTATOCLIENTE CONTATO WHERE NUCLIENTE IN ( SELECT NUCLIENTE FROM SGE.TBCBCLIENTECARTAO ) ) TABLE_TEMP2 WHERE NUCARTAO IS NOT NULL ) TABLE_TEMP3 WHERE NUCLIENTE||NUCONTATO NOT IN (SELECT CODIGO_CLIENTE||CONTATO_CLIENTE FROM DIM_CLIENTE); END ; PROCEDURE POPULEFATOVENDA (VDATEINI DATE, VDATEFIM DATE) IS BEGIN SP_POPULE_TABLECHECAGEM ( VDATEINI, VDATEFIM ); SP_POPULE_PKHORA_CHECAGEM ( VDATEINI, VDATEFIM ); SP_POPULE_PKDATA_CHECAGEM ( VDATEINI, VDATEFIM ); SP_POPULE_PKCANAL_CHECAGEM ( VDATEINI, VDATEFIM ); SP_POPULE_PKLOJA_CHECAGEM ( VDATEINI,VDATEFIM ); SP_POPULE_PKCLIENTE_CHECAGEM ( VDATEINI, VDATEFIM ); SP_POPULE_PKPRODUTO_CHECAGEM ( VDATEINI, VDATEFIM ); SP_POPULE_PKPROMOCAO_CHECAGEM ( VDATEINI, VDATEFIM ); SP_POPULE_PKFORMAPGTO_CHECAGEM ( VDATEINI, VDATEFIM ); SP_POPULE_VALORCUSTO_CHECAGEM ( VDATEINI, VDATEFIM ); SP_POPULE_MEDIAS_MES ( VDATEINI, VDATEFIM ); INSERT INTO FATO_VENDA SELECT PK_LOJA, PK_CANAL, PK_DATA, PK_HORA, PK_FORMAPGTO, PK_CLIENTE, PK_PRODUTO, PK_PROMOCAO, SUM(QTVENDIDA) QTVENDIDA, SUM(VLVENDIDO) VLVENDIDO, SUM(VALOR_CUSTO) VALOR_CUSTO,
77
SUM(VLVENDIDO-VALOR_CUSTO) MARGEM, SUM(MEDIA_VENDA_MES) MEDIA_VENDA_MES, SUM(MEDIA_MARGEM_MES) MEDIA_MARGEM_MES FROM TABLE_CHECAGEM TC WHERE TC.DTTRANSACAO >= VDATEINI AND TC.DTTRANSACAO <= VDATEFIM GROUP BY PK_LOJA, PK_CANAL, PK_DATA, PK_HORA, PK_FORMAPGTO, PK_CLIENTE, PK_PRODUTO, PK_PROMOCAO; END POPULEFATOVENDA; END; / CREATE OR REPLACE FUNCTION "FUNCTION_EH_FERIADO" ( VDATA IN DATE ) RETURN VARCHAR2 AS VFERIADO VARCHAR2(80); VCOUNT INTEGER; BEGIN SELECT COUNT(*) INTO VCOUNT FROM SGE.TBCBFERIADO WHERE DTFERIADO = VDATA; IF VCOUNT > 0 THEN SELECT NMFERIADO INTO VFERIADO FROM SGE.TBCBFERIADO WHERE DTFERIADO= VDATA; ELSE VFERIADO := 'NORMAL'; END IF; RETURN UPPER(VFERIADO); END; / CREATE OR REPLACE FUNCTION "FUNCTION_SEQ_PK_PRODUTO" RETURN
INTEGER AS VSEQUENCIA INTEGER ; BEGIN SELECT SEQUENCIA_PK_DIM_PRODUTO.NEXTVAL INTO VSEQUENCIA FROM DUAL; RETURN VSEQUENCIA; END; /
78
CREATE OR REPLACE PROCEDURE "SP_POPULE_MEDIAS_MES" ( VDATAINI IN DATE, VDATAFIM IN DATE ) AS BEGIN UPDATE TABLE_CHECAGEM TC SET MEDIA_VENDA_MES = (SELECT TRUNC (SUM(VLVENDIDO) / COUNT(VLVENDIDO),2) FROM TABLE_CHECAGEM TC1 WHERE TC1.DTTRANSACAO = TC.DTTRANSACAO AND TC1.NUCLIENTE = TC.NUCLIENTE AND TC1.NUCARTAO = TC.NUCARTAO GROUP BY TO_CHAR(TC1.DTTRANSACAO, 'MM/YYYY') ) , MEDIA_MARGEM_MES = (SELECT TRUNC (SUM(VLVENDIDO-VALOR_CUSTO) / COUNT(VLVENDIDO),2) FROM TABLE_CHECAGEM TC2 WHERE TC2.DTTRANSACAO = TC.DTTRANSACAO AND TC2.NUCLIENTE = TC.NUCLIENTE AND TC2.NUCARTAO = TC.NUCARTAO GROUP BY TO_CHAR(TC2.DTTRANSACAO, 'MM/YYYY') ) WHERE TC.DTTRANSACAO >= VDATAINI AND TC.DTTRANSACAO <= VDATAFIM ; END; / CREATE OR REPLACE PROCEDURE "SP_POPULE_PKHORA_CHECAGEM" ( VDATAINI IN DATE, VDATAFIM IN DATE ) AS BEGIN UPDATE TABLE_CHECAGEM TC SET PK_HORA = (SELECT PK_HORA FROM DIM_HORA WHERE HORA_MINUTO = TC.HRVENDA) WHERE TC.DTTRANSACAO >= VDATAINI AND TC.DTTRANSACAO <=VDATAFIM; END; / CREATE OR REPLACE FUNCTION "FUNCTION_TPSEXO_CLIENTE" ( VSEXO CHAR )
79
RETURN CHAR AS VSEXO_NEW CHAR := VSEXO; BEGIN IF VSEXO_NEW IS NULL THEN VSEXO_NEW := 'N'; /* NÃO INFORMADO */ END IF; RETURN VSEXO_NEW; END; / CREATE OR REPLACE PROCEDURE "SP_POPULE_PKLOJA_CHECAGEM" ( VDATAINI IN DATE , VDATAFIM IN DATE ) AS BEGIN UPDATE TABLE_CHECAGEM TC SET PK_LOJA = ( SELECT PK_LOJA FROM DIM_LOJA WHERE COD_LOJA= TC.NUUNIDOPER) WHERE TC.DTTRANSACAO >= VDATAINI AND TC.DTTRANSACAO <= VDATAFIM; END; / CREATE OR REPLACE FUNCTION "FUNCTION_GRAUINSTRUCAO_CLIENTE" ( VGRAUINSTRUCAO VARCHAR2 ) RETURN VARCHAR2 AS VGRAUINSTRUCAO_NEW VARCHAR2(30) := VGRAUINSTRUCAO; BEGIN IF VGRAUINSTRUCAO_NEW IS NULL THEN VGRAUINSTRUCAO_NEW := 'NAO INFORMADO'; END IF; RETURN VGRAUINSTRUCAO_NEW; END; / CREATE OR REPLACE FUNCTION "FUNCTION_ESTADOCIVIL_CLIENTE" ( VESTADOCIVIL VARCHAR2 ) RETURN VARCHAR2 AS VESTADOCIVIL_NEW VARCHAR2 (30) := VESTADOCIVIL;
80
BEGIN IF VESTADOCIVIL_NEW IS NULL THEN VESTADOCIVIL_NEW := 'NAO INFORMADO'; END IF; RETURN VESTADOCIVIL_NEW; END; / CREATE OR REPLACE PROCEDURE "SP_POPULE_TABLECHECAGEM" ( VDATAINI IN DATE, VDATAFIM IN DATE ) AS BEGIN INSERT INTO TABLE_CHECAGEM SELECT A.*, 999999 AS NUPRODUTO, 1 AS PK_LOJA, 1 AS PK_CANAL , 9999 AS PK_PROMOCAO, 999999 AS PK_CLIENTE, 999999 AS PK_PRODUTO, 9999 AS PK_HORA, 99999 AS PK_DATA, 999 AS PK_FORMAPGTO, 0 AS VALOR_CUSTO, 0 AS MEDIA_VENDA_MES, 0 AS MEDIA_MARGEM_MES FROM (SELECT I.DTTRANSACAO,I.NUUNIDOPER, I.NUPDV,I.NUCUPOMFISCAL,NUEAN,I.HRVENDA,NUCLIENTE,NUCARTAO,SUM(QTVENDIDA) AS QTVENDIDA, SUM(VLVENDIDO-VLDESCONTO) AS VLVENDIDO FROM SGE.TBVDPDVVENDAITEM I, (SELECT DISTINCT NUUNIDOPER,NUPDV, NUCUPOMFISCAL, DTMOVIMENTO, TO_NUMBER(SUBSTR(NUCARTAO,4,6)) AS NUCLIENTE, NUCARTAO FROM SGE.TBVDPDVVENDAOPERADOR WHERE NUUNIDOPER = 1 AND DTMOVIMENTO >= VDATAINI AND DTMOVIMENTO <= VDATAFIM AND (TO_NUMBER(SUBSTR(NUCARTAO,4,6)) IN (SELECT CODIGO_CLIENTE FROM
DIM_CLIENTE)) AND NUCARTAO LIKE '001%') CLIENTE WHERE I.NUUNIDOPER = CLIENTE.NUUNIDOPER AND I.NUPDV = CLIENTE.NUPDV AND I.NUCUPOMFISCAL = CLIENTE.NUCUPOMFISCAL AND I.DTTRANSACAO = CLIENTE.DTMOVIMENTO GROUP BY I.DTTRANSACAO,I.NUUNIDOPER, I.NUPDV,I.NUCUPOMFISCAL,NUEAN, I.HRVENDA, NUCLIENTE,NUCARTAO HAVING MAX(I.NUUNIDOPER) = 1) A;
81
END; / CREATE OR REPLACE FUNCTION "FUNCTION_FAIXARENDA_CLIENTE" ( VFAIXARENDA VARCHAR ) RETURN VARCHAR AS VFAIXARENDA_NEW VARCHAR (30) := VFAIXARENDA; BEGIN IF VFAIXARENDA_NEW IS NULL THEN VFAIXARENDA_NEW := 'NAO INFORMADO'; END IF; RETURN VFAIXARENDA_NEW; END; / CREATE OR REPLACE FUNCTION "FUNCTION_SEQ_PK_CLIENTE" RETURN
INTEGER AS VSEQUENCIA INTEGER ; BEGIN SELECT SEQUENCIA_PK_DIM_CLIENTE.NEXTVAL INTO VSEQUENCIA FROM DUAL; RETURN VSEQUENCIA; END; / CREATE OR REPLACE PROCEDURE "SP_POPULE_PKCANAL_CHECAGEM" ( VDATAINI IN DATE, VDATAFIM IN DATE ) AS BEGIN UPDATE TABLE_CHECAGEM TC SET PK_CANAL = 1 WHERE TC.DTTRANSACAO >= VDATAINI AND TC.DTTRANSACAO <= VDATAFIM; /* SOMENTE LOJA NÃO TEVE COMO IDENTIFICAR O CANAL */ END; / CREATE OR REPLACE PROCEDURE "SP_POPULE_PKPROMOCAO_CHECAGEM" ( VDATAINI IN DATE, VDATAFIM IN DATE ) AS BEGIN UPDATE TABLE_CHECAGEM TC SET PK_PROMOCAO =
82
(SELECT PK_PROMOCAO FROM DIM_PROMOCAO WHERE PERCENTUAL_DESCONTO = ( SELECT TRUNC(PCDESCONTO) FROM SGE.TBVDPROMOCAO WHERE NUPRODUTO = TC.NUPRODUTO AND DTINICIO <= TC.DTTRANSACAO AND DTFIM >= TC.DTTRANSACAO AND NUPRODUTO = TC.NUPRODUTO) ); UPDATE TABLE_CHECAGEM TC SET PK_PROMOCAO = 83 /* SEM PROMOCAO */ WHERE TC.DTTRANSACAO >= VDATAINI AND TC.DTTRANSACAO <= VDATAFIM AND PK_PROMOCAO IS NULL; END; / CREATE OR REPLACE PROCEDURE "SP_POPULE_PKDATA_CHECAGEM" ( VDATAINI IN DATE, VDATAFIM IN DATE ) AS BEGIN UPDATE TABLE_CHECAGEM TC SET PK_DATA = (SELECT PK_DATA FROM DIM_DATA WHERE DATA_NORMAL = TC.DTTRANSACAO) WHERE TC.DTTRANSACAO >= VDATAINI AND TC.DTTRANSACAO <=VDATAFIM; END; / CREATE OR REPLACE PROCEDURE "SP_POPULE_PKPRODUTO_CHECAGEM" ( VDATAINI IN DATE, VDATAFIM IN DATE ) AS BEGIN UPDATE TABLE_CHECAGEM TC SET NUPRODUTO = (SELECT NUPRODUTO FROM SGE.TBCBEANPRODUTO WHERE NUEAN= TC.NUEAN) WHERE TC.DTTRANSACAO >= VDATAINI AND TC.DTTRANSACAO <= VDATAFIM;
83
UPDATE TABLE_CHECAGEM TC SET PK_PRODUTO = ( SELECT PK_PRODUTO FROM DIM_PRODUTO WHERE CODIGO_PRODUTO = TC.NUPRODUTO -- (SELECT NUPRODUTO FROM SGE.TBCBEANPRODUTO WHERE -- NUEAN= TC.NUEAN) ) WHERE TC.DTTRANSACAO >= VDATAINI AND TC.DTTRANSACAO <= VDATAFIM; END; / CREATE OR REPLACE PROCEDURE "SP_POPULE_PKCLIENTE_CHECAGEM" ( VDATAINI IN DATE, VDATAFIM IN DATE ) AS BEGIN UPDATE TABLE_CHECAGEM TC SET PK_CLIENTE = ( SELECT PK_CLIENTE FROM DIM_CLIENTE WHERE NRO_CARTAOFIDELIZACAO = TC.NUCARTAO ) WHERE TC.DTTRANSACAO >= VDATAINI AND TC.DTTRANSACAO <= VDATAFIM; /* NÃO IDENTIFICADOS */ UPDATE TABLE_CHECAGEM TC SET PK_CLIENTE = ( SELECT MAX(PK_CLIENTE) FROM DIM_CLIENTE WHERE CODIGO_CLIENTE = TC.NUCLIENTE ) WHERE TC.DTTRANSACAO >= VDATAINI AND TC.DTTRANSACAO <= VDATAFIM AND PK_CLIENTE IS NULL ; END; / CREATE OR REPLACE PROCEDURE "SP_POPULE_PKFORMAPGTO_CHECAGEM" ( VDATAINI IN DATE, VDATAFIM IN DATE )
84
AS BEGIN UPDATE TABLE_CHECAGEM TC SET PK_FORMAPGTO = FUNCTION_COMBINACAO_FORMAPGTO ( TC.NUCUPOMFISCAL,TC.NUPDV, TC.DTTRANSACAO ) WHERE TC.DTTRANSACAO >= VDATAINI AND TC.DTTRANSACAO <=VDATAFIM; END; / CREATE OR REPLACE FUNCTION "FUNCTION_COMBINACAO_FORMAPGTO" ( VCUMPONFISCAL IN INTEGER, VNUPDV IN INTEGER , VDTTRANSACAO IN DATE) RETURN NUMBER AS CURSOR C_FORMAPGTO IS SELECT NUFINALIZADOR FROM SGE.TBCRMOVTOFINALIZADOR WHERE NUCUPOMFISCAL = VCUMPONFISCAL AND NUPDV = VNUPDV AND DTTRANSACAO = VDTTRANSACAO; VFINALIZADOR SGE.TBCRMOVTOFINALIZADOR.NUFINALIZADOR%TYPE; VPKFORMAPGTO_NEW INTEGER; VFORMAPGTO_NEW VARCHAR (200); VFORMAPGTO VARCHAR (200); VINC INTEGER := 0; VRETURN INTEGER := 0; BEGIN FOR EMP_REC IN C_FORMAPGTO LOOP SELECT PK_FORMAPGTO,FORMA_PGTO INTO
VPKFORMAPGTO_NEW,VFORMAPGTO FROM DIM_FORMAPGTO WHERE CODIGO_PGTO = EMP_REC.NUFINALIZADOR; VFORMAPGTO_NEW := VFORMAPGTO_NEW || ',' || VFORMAPGTO; VINC := VINC + 1; END LOOP; IF VINC = 1 THEN VRETURN := VPKFORMAPGTO_NEW; ELSE VFORMAPGTO_NEW := SUBSTR(VFORMAPGTO_NEW,2,LENGTH(VFORMAPGTO_NEW)-1); SELECT COUNT(PK_FORMAPGTO) INTO VINC FROM DIM_FORMAPGTO WHERE FORMA_PGTO = VFORMAPGTO_NEW;
85
IF VINC = 0 THEN SELECT SEQUENCIA_PK_DIM_FORMAPGTO.NEXTVAL INTO VPKFORMAPGTO_NEW FROM DUAL; SP_POPULE_COMBINACAO_FORMAPGTO( VPKFORMAPGTO_NEW,VFORMAPGTO_NEW ); VRETURN := VPKFORMAPGTO_NEW; ELSE SELECT MAX(PK_FORMAPGTO) INTO VRETURN FROM DIM_FORMAPGTO WHERE FORMA_PGTO = VFORMAPGTO_NEW; END IF; END IF; RETURN VRETURN; EXCEPTION WHEN NO_DATA_FOUND THEN RAISE_APPLICATION_ERROR(-20000,' NUPDV ' || VNUPDV || ' NUCUPOMFISCAL ' || VCUMPONFISCAL || ' VDTTRANSACAO '|| TO_CHAR(VDTTRANSACAO)); WHEN OTHERS THEN RAISE_APPLICATION_ERROR(-20000,' NUPDV ' || VNUPDV || ' NUCUPOMFISCAL ' || VCUMPONFISCAL || ' VDTTRANSACAO '|| TO_CHAR(VDTTRANSACAO)); END; / CREATE OR REPLACE PROCEDURE "SP_START_ETL" ( VDATAINI DATE, VDATAFIM IN DATE ) AS VDATA DATE; BEGIN SELECT MAX(DATA_NORMAL) INTO VDATA FROM DIM_DATA; IF VDATAINI > VDATA THEN DMCLIENTE_AREACHECAGEM.POPULEDIMENSAODATA ( VDATAINI,VDATAFIM ); END IF ; --DMCLIENTE_AREACHECAGEM.POPULEDIMENSAOFORMAPGTO; --DMCLIENTE_AREACHECAGEM.POPULEDIMENSAOPRODUTO; --DMCLIENTE_AREACHECAGEM.POPULEDIMENSAOCLIENTE; --DMCLIENTE_AREACHECAGEM.POPULEDIMENSAOPROMOCAO; DMCLIENTE_AREACHECAGEM.POPULEFATOVENDA ( VDATAINI,VDATAFIM ); END; / CREATE OR REPLACE PROCEDURE "SP_POPULE_COMBINACAO_FORMAPGTO" ( VPKFORMAPGTO_NEW IN INTEGER, VFORMAPGTO_NEW IN VARCHAR ) AS PRAGMA AUTONOMOUS_TRANSACTION;
86
BEGIN INSERT INTO DIM_FORMAPGTO (PK_FORMAPGTO,CODIGO_PGTO,FORMA_PGTO) VALUES (VPKFORMAPGTO_NEW,100+VPKFORMAPGTO_NEW,VFORMAPGTO_NEW); COMMIT; EXCEPTION WHEN OTHERS THEN ROLLBACK; END; / CREATE OR REPLACE PROCEDURE "SP_POPULE_VALORCUSTO_CHECAGEM" ( VDATAINI IN DATE, VDATAFIM IN DATE ) AS BEGIN UPDATE TABLE_CHECAGEM TC SET VALOR_CUSTO = QTVENDIDA * (SELECT VLCUSTOUNITICMS FROM SGE.TBETREGISTRODIARIO WHERE NUUNIDOPER = TC.NUUNIDOPER AND NUPRODUTO = TC.NUPRODUTO AND DTREGISTRO = TC.DTTRANSACAO ) WHERE TC.DTTRANSACAO >= VDATAINI AND TC.DTTRANSACAO <= VDATAFIM; UPDATE TABLE_CHECAGEM TC SET VALOR_CUSTO = VLVENDIDO WHERE TC.DTTRANSACAO >= VDATAINI AND TC.DTTRANSACAO <= VDATAFIM AND VALOR_CUSTO IS NULL; END; /
87
APÊNDICE C – ARTIGO
UMA APLICAÇÃO DE GERENCIAMENTO DO RELACIONAMENTO COM O
CLIENTE PARA O SETOR DE VAREJO SUPERMERCADISTA
Erivelton Vichroski
Universidade Federal de Santa Catarina
1. Introdução
Toda empresa com fins lucrativos depende de clientes para existir, ou seja, ela espera que os mesmos paguem pelos serviços ou produtos ofertados. Como condição básica para permanência no mercado, uma empresa está sempre procurando atrair novos clientes ou ainda oferecendo vantagens àqueles já conquistados. Para atingir este objetivo, em muitos casos, as empresas usam estratégias de marketing com o objetivo de divulgar ou lançar novos produtos ou serviços.
O Marketing oferece muitos recursos que ajudam a obter novos clientes; Estas atividades, que por sinal, não são muito simples e exigem investimentos em campanhas promocionais, criação de novos serviços ou produtos, comunicação com os clientes, planejamento de vendas, treinamento de colaboradores visando o ótimo atendimento, dentre outros. Porém, tão importante quanto conquistar um cliente é mantê-lo. O CRM (Customer Relationship Management) é uma estratégia oriunda do Marketing de Relacionamento que tem por objetivo atender e influenciar o comportamento do cliente para melhorar suas compras, a retenção, a lealdade e lucratividade deles (SWIFT, 2000, p. 12). Para isso, procura fazer do cliente o foco dos negócios, onde todos os processos gravitam em torno dele. Fazer com que os processos girem em torno do cliente exige modificações na forma como estes processos são construídos, pois, tradicionalmente, são projetados com base em outro enfoque, o do produto.
Além do mais, para manterem-se competitivas, as empresas necessitam da informação como principal arma contra seus concorrentes. Para isso, a busca de conhecimento sobre os clientes, faz com que essas empresas coloquem as informações dos clientes no centro de suas infra-estruturas de informações.
A retenção de clientes lucrativos, conquistada por empresas bem-sucedidas, se dá pela obtenção de conhecimento detalhado dos clientes, e não somente através de dados brutos relacionados com
transações e pagamentos financeiros. A tecnologia da informação (TI) auxilia na transformação de dados brutos em informação. Esse processo facilita que as informações obtidas rapidamente sejam usadas na criação de um ambiente para a tomada de decisões de negócios compartilhada e inovadora.
Além do mais, para que as empresas tenham um ambiente ágil na obtenção da informação pode-se empregar o conceito de Data Warehouse (DW). Esse consiste em organizar os dados corporativos da melhor maneira, para dar subsídio de informações aos gerentes e diretores das empresas para tomada de decisão. Tudo isso num banco de dados centralizado e paralelo aos sistemas operacionais da empresa. Mas, em contrapartida, a criação de um DW requer tempo, dinheiro e considerável esforço gerencial devido à sua abrangência no que se refere às áreas da organização. Muitas empresas iniciam este tipo de projeto tendo como base às necessidades de pequenos grupos ou departamentos. Estes módulos de armazenamentos de dados são chamados de Data Mart (DM). O maior atrativo de se optar por um DM é o seu menor custo e prazo de implantação.
Considerando, neste contexto, as empresas do ramo supermercadista, bem como todas as empresas em que o cliente é a razão de sua existência, a estratégia do relacionamento com o cliente só pode ser adotada através da combinação conjunta de processos, tecnologias e procedimentos comportamentais e, além é claro, que a empresa tenha “foco no cliente”.
A contextualização acima permitiu visualizar como objetivo geral deste trabalho uma aplicação da tecnologia da informação, através da criação de DM de clientes a fim de prover agilidade no processo de análise dos dados dentro da gestão de relacionamento com o cliente.
Os objetivos específicos foram, primeiramente, explorar e estudar uma base de dados operacional que contenha o perfil de compras de determinados clientes do ramo supermercadista, em seguida aperfeiçoar o conhecimento sobre conceito de CRM
88 e das técnicas de DW, e finalmente, agregar os conhecimentos adquiridos através da especificação de um DM, com a meta de agilizar a análise das informações.
Além disso, através da revisão bibliográfica procurou-se obter conhecimentos necessários com o intuito de elucidar as questões pertinentes aos assuntos tratados nesse artigo, ou seja, foram estudados os conceitos e características dos seguintes temas: CRM, Setor de Varejo Supermercadista e Data Warehouse.
2. CRM – Customer Relationship Management
O termo CRM – Customer Relationship Management embora amplamente utilizado, nunca foi formalmente definido. Segundo Peppers and Rogers Group (2001) pode se dizer que “CRM é uma infra-estrutura para implementar-se a filosofia one to one de relacionamento com os clientes”.
O principal objetivo de uma empresa, quando adota a filosofia do CRM, é entender e influenciar o comportamento dos seus clientes, fazendo com que eles permaneçam fiéis à empresa, aumente o volume de suas compras e recomendem a empresa para outros possíveis clientes. Em resumo, o objetivo principal da empresa é obter incremento real das suas vendas e, conseqüentemente, aumentar sua lucratividade.
Outro ponto a ser discutido, é que o CRM pode ser considerando um processo interativo que transforma informações sobre os clientes em relacionamentos positivos com os mesmos. (SWIFT, 2001, p.13)
A principal justificativa para que as empresas adotem esta filosofia esta baseada na premissa, atualmente bem conhecida, que custa menos manter os clientes atuais do que conquistar novos - na realidade custa cinco vezes menos (SWIFT, 2001, p.18) - e do fato de que o mercado está cada vez mais competitivo e a sobrevivência neste requer manutenção da satisfação dos clientes já conquistados. Um exemplo disto é aos clientes que fazem suas compras de produtos ou serviços pela Internet, pois qualquer insatisfação dará ao mesmo a possibilidade de mudar de empresa fornecedora, com um simples toque do mouse. Assim, já não basta oferecer o melhor preço ou a melhor ou mais atual tecnologia. Uma campanha promocional pode atrair alguns clientes por algum tempo, mas a empresa corre o risco de perdê-los no caso da concorrência fazer uma promoção mais atrativa.
O CRM efetivamente engloba a capacidade de uma empresa em: (SWIFT, 2001, p.16)
• Descobrir clientes; • Conhecê-los; • Manter comunicação com eles; • Assegurar que eles receberam o que
desejam da organização-não somente quanto ao aspecto do produto, mas em
cada detalhe de como a organização lida com eles;
• Verificar se eles recebem o que lhes foi prometido-certamente, desde que seja lucrativo;
• Assegurar que o cliente seja mantido - mesmo que o cliente não seja lucrativo atualmente, o objetivo é lucratividade em longo prazo.
CRM não diz respeito a preços. Não diz respeito ao envio de grandes quantidades de correspondências ou muitas ligações irritantes para clientes em potencial. Definitivamente, não diz respeito à utilização dos canais para direcionar os clientes para os concorrentes. (SWIFT, 2001, p.16). 2.1 Estratégias de Implantação do CRM
Quando falamos em implantar um projeto de CRM, além do custo e da disponibilidade de tempo, exigem-se, na maioria das vezes, profundas mudanças na maneira da empresa se relacionar com seus clientes. Políticas, processos e procedimentos da empresa frente aos seus consumidores fatalmente deverão ser repensados ou melhorados para que se consiga o êxito do projeto. (PEPPERS AND ROGERS, 2001).
O sucesso deste tipo de projeto advém do cumprimento de alguns objetivos básicos da própria estratégia de CRM, ou seja, conhecer na íntegra o cliente e suas necessidades, garantir a satisfação do consumidor através do atendimento diferenciado, além aumentar a eficiência nos serviços prestados (PEPPERS AND ROGERS, 2001).
Podemos distinguir um projeto de CRM de acordo com sua abordagem ou estratégia de implantação:
• CRM Operacional Visa melhorar o relacionamento direto entre a
empresa e o cliente através de canais como a internet ou call centers. Tais melhorias advêm do agrupamento de informações com o intuito de se obter, com maior precisão, o perfil do cliente.
• CRM Analítico Trata da análise dos dados sobre o cliente nas
várias esferas da organização. Esta permite descobrir entre outras informações o grau de fidelização dos clientes, seus diferentes tipos, além das preferências e rejeições quanto a produtos e serviços. A ligação entre um CRM de abordagem analítica com um data mart para o setor marketing e/ou vendas é inevitável, pois juntos oferecem grande auxílio na busca de respostas importantes no que diz respeito às questões de negócio.
• CRM Colaborativo A principal característica da abordagem
colaborativa do CRM está na possibilidade de criar, aumentar e gerenciar a interação com o cliente. Para isso é necessário que a empresa tenha um meio adequado para a interação - abordada no CRM operacional - e que possua informações suficientes
89 sobre seus clientes - obtidas através do CRM analítico - de forma centralizada e, é claro, integrada. Além do mais, a abordagem colaborativa do CRM procura integrar as estruturas e benefícios dos outras duas abordagens descritas. Enquanto o CRM operacional está mais focado nos níveis tático e operacional, e o CRM analítico nos níveis estratégico e tático, o colaborativo procura gerar melhorias nos três níveis (PEPPERS AND ROGERS, 2001).
3. Caracterização do Setor de Varejo Supermercadista no Brasil
Segundo Parente (2000, p. 32), “os supermercados caracterizam-se pelo sistema auto-serviço, check outs (caixas registradoras sobre balcão na saída da loja) e produto dispostos de maneira acessível, que permitem aos fregueses “auto-servirem-se”, utilizando cestas e carrinhos. [...] A maioria das redes de supermercados no Brasil opera grande número de lojas que são classificadas como supermercados convencionais”.
No Brasil, de acordo com Cyrillo (1987), a atividade supermercadista foi regulamentada em 1968 através da Lei 7208, de 13/11/1968, ficando estabelecido o seguinte: supermercado é um estabelecimento de comércio varejista que, adotando o sistema de auto-atendimento, coloca à disposição e vende gêneros alimentícios e outras utilidades domésticas. 3.2. Desenvolvimento do Setor Supermercadista no Brasil
É notória a importância deste setor em nossa economia, já que desde sua instalação no Brasil, segundo Nogueira (1993, p.3), há quarenta anos, os supermercados têm desempenhado um papel fundamental dada à ênfase à colocação de produtos à disposição do consumidor brasileiro.
Desde os primeiros ensaios de auto-serviço no comércio varejista, no final dos anos 40 até o surgimento, a partir da década de 60, das grandes redes em operação atualmente no país, os supermercados têm se transformado rapidamente movidos pelo desejo de atender novos padrões de consumo além de acompanhar o desenvolvimento da sociedade e da economia brasileira.
A evolução do setor supermercadista no Brasil, fez com os preços fossem deixados, até certo ponto, em segundo plano para focalizar-se na oferta de serviços. A disposição das lojas tendeu a ficar cada vez mais aprimoradas e sofisticadas, quer do ponto de vista arquitetônico quer da decoração e da própria exposição das gôndolas - local nas quais são expostos os produtos à venda.
3.3. O Setor Supermercadista e a Estratégia de CRM
Segundo Ferraz (2002), quando se fala em fidelização de clientes neste ramo de comércio, pode-se dizer que um pouco mais da metade são fieis. O que explica este comportamento do consumidor supermercadista são basicamente três situações.
A primeira refere-se à conjuntura econômica do país, onde uma atmosfera composta por baixo índice inflacionário e a instabilidade profissional incentiva à comparação de preços por partes dos consumidores, tornando-os mais preocupados com o assunto preço.
A segunda situação está ligada à oferta de uma quantidade expressiva de diferentes produtos e marcas nos quais os consumidores estão expostos. Com isso, as lojas supermercadistas tornam-se mais diferenciados, e os consumidores mais seletivos e menos fieis um único supermercado.
A terceira situação diz respeito à saturação do mercado varejista, criando um ambiente mais acirrado e competitivo, permitindo aos consumidores mais opções de locais de compra dentro de uma determinada localização.
O exposto nos mostra que para manter-se competitivo, em certas ocasiões, é crucial por parte dos supermercadistas, a adoção de estratégias ligadas ao CRM, já que este enfoque prevê as necessidades do cliente e reduz, em muito, vários problemas do setor, em especial a questão da fidelização. 4. Data Warehouse como Suporte ao CRM Analítico
Kimball (1998), uma figura respeitada no assunto, define o DW como sendo um recurso de consulta e apresentação dos dados de negócio da empresa, construído especificamente para este fim.
Inmon (2002), outro guru no assunto, definiu DW como sendo uma coleção de dados integrados, orientada por assuntos, variante no tempo e não volátil, que tem por objetivo dar suporte aos processos de tomada de decisão.
Em geral, os DWs possuem diversas características que os diferem dos bancos de dados operacionais, os OLTPs (On Line Transactional Processing), uma das principais fontes de informações para os DWs. Uma dessas características é que os dados são consultados numa única fonte de dados, consolidada através de um banco de dados separado da base de dados operacional e organizado para armazenar conhecimentos sobre o negócio. A separação é das bases operacionais impede a perda de desempenho no processo operacional da organização. Por exemplo, imaginemos um supermercado com centenas de caixas registradoras conectadas ao banco de dados transacional e algum diretor
90 tentando extrair uma consulta ou relatório de análise que mostrasse o desempenho da empresa. Outra questão importante é que o DW apresenta uma arquitetura diferente da base de dados transacional, ou seja, a criação deste tipo de banco de dados atende a requisitos específicos. 4.1. Metodologia para Construção de Data Warehouse
Atualmente, a tecnologia de DW conta basicamente com duas abordagens de implementação, a top-down e a bottom-up. Mas, para compreendermos melhor estas abordagens, se faz necessário conhecer o conceito de Data Mart (DM).
Os DMs, ou o DW em departamentos, são subconjuntos lógicos de um DW. Para se diminuir o tempo e os custos totais de construção, podemos dividir um DW em partes menores, distribuídas por departamentos ou assuntos inerentes ao negócio da organização.
As diferenças entre DM e DW são apenas em relação ao tamanho e ao escopo do problema a ser solucionado. Como o DM está direcionado a uma área específica da organização, o planejamento e análise do mesmo são mais fáceis de gerenciar.
Na abordagem top-down, sustentada por Inmon (2002), o objetivo é conquistar para depois dividir, tendo como premissa a modelagem e a construção de todo DW, dotado de todas as informações acerca do negócio e da empresa. Depois disto, disponibilizam-se os data marts.
Na bottom-up, defendida por Kimball (1998), a idéia é dividir para depois conquistar. Primeiramente são construídos os DMs, atendendo as necessidades setoriais de informações, e tendo como critério de ordem de construção a prioridade para o negócio. A reunião de todos os DMs comporá o DW como um todo. Esta abordagem é detalhada mais a fundo no item a seguir, através do Ciclo de Vida do DW. 5. Metodologia Adotada
Inicialmente procurou-se apresentar a conceituação de CRM para então caracterizar o comércio de varejo supermercadista em nosso país e as justificativas para adoção de estratégias de CRM por parte deste. Além disso, foi apresentando o conceito e finalidade de data warehouse.
No entanto, a finalidade de conhecer os assuntos acima foi adquirir conhecimentos necessários para propor uma solução, através da aplicação das técnicas expostas, visando resolver às dificuldades enfrentadas no processo de análise de informações de clientes, principalmente o que diz respeito ao hábito de compra dos mesmos.
Como justificativa para escolha da especificação de um data mart de clientes está intimamente ligada ao fato de que atualmente gestores da área de CRM,
especialmente em pequenos e médios supermercados, utiliza-se de complexas pesquisas para extrair e transformar as informações de que precisam do banco de dados operacional. Estes procedimentos geralmente terminam em uma exploração por cruzamento e quantificação dos dados. Este tipo de procedimento assemelha-se a uma análise exploratória parecida com a tecnologia OLAP, vistas anteriormente e, sem sombra de dúvidas, suportada pelo ambiente de DW.
Outra situação relevante é a dependência existente entre o gestor de CRM e o departamento informática da organização na obtenção das respostas de questionamentos complexos sobre os clientes. A união da tecnologia OLAP com a de DW praticamente eliminará esta dependência, já que determinadas repostas estarão acessíveis com poucos cliques do mouse. 5.1. Planejamento do Data Mart de Clientes
Esta etapa de construção teve como principal objetivo a definição do escopo. Podemos considerar esta fase como sendo a mais importante do projeto, pois erros na delimitação do escopo, identificação de necessidades, restrições e recursos (humanos, equipamentos, financeiro, etc.) podem inviabilizar a realização do projeto.
Como parte do planejamento tem-se a etapa de definição do escopo onde serão descritos as metas e objetivos a serem galgados com a execução do projeto. Nesta importante fase é identificada a existência e a origem de demanda.
Partindo para elaboração do plano, foi realizado um levantamento sobre as características da empresa, onde foram identificados potenciais usuários e suas necessidades, além de se conhecer brevemente pontos estratégicos do negócio e como são acompanhados, bem como identificar os processos centrais da organização para posterior priorização, que no caso deste trabalho, não se teve muito esforço devido à definição do problema já estar formulado. 5.1.1. Definição do Escopo
Este trabalho teve como base para definição de escopo um supermercado da grande Florianópolis (SC), que atua no mercado há cerca de sete anos e desejava obter maior agilidade na aquisição de informações inteligentes e úteis do cliente. Espera-se com isso aperfeiçoar seus processos, além de visualizar informações implícitas em seu sistema transacional em uso atualmente. Outra expectativa depositada no projeto consiste em aprimorar e auxiliar as tomadas de decisões estratégicas da empresa, principalmente o que tange a CRM.
O projeto teve foco nas rotinas operacionais que geram dados através das transações de vendas ao cliente e visa obter conhecimento mais profundo e
91 detalhado deste processo, respondendo principalmente questões à margem dos processos operacionais, e de grande valia nos procedimentos de tomada de decisão e visão estratégica.
O projeto conta com cinco anos de dados históricos, e lida com dados de clientes que possui cartão de fidelização.
A infra-estrutura computacional utilizada foi a existente e conta com aproximadamente 40 estações de trabalho, na grande maioria equipada com Sistema Operacional Linux (Fedora™ e Suse™), servidor composto por dois processadores Intel™ Xeon de 3.06 GHZ, 3 GB de memória RAM, espaço em disco rígido de 100 GB com redundâncias e proteção à falhas, além do software de banco de dados Oracle™ 10g versão 1.0.3.0 e Sistema Operacional Linux Suse™ Enterprise Server versão 9.0.
Como ferramentas OLAP utilizaram-se planilhas eletrônicas Microsoft Excel™ e OpenOffice.org™ versão 1.1.2 , além do Discoverer da Oracle™ . O tempo utilizado para o desenvolvimento do projeto foi de quatro meses.
Tão importante quando a definição do escopo, as exclusões, ou questões deixadas para serem resolvidas em outro momento, serviram para nortear as ações relevantes e para gerar uma correta especificação do data mart, contribuindo para não se distanciar dos objetivos almejados. Foram desconsiderados do projeto:
• Dados de clientes não identificados no momento da venda;
• Produtos de consumo interno e sem vínculo de venda;
• Dados de vendas canceladas. 5.1.2. Fatores Críticos de Sucesso
Como fator crítico, levou-se em conta o aproveitamento dos dados de venda gerado pelo cliente, com o intuito de se conseguir mais oportunidades de torná-lo fiel sem grandes esforços, bem como tornar a venda de produtos e serviços mais inteligente e lucrativa. Com o perfil de compra do cliente, foi possível obter uma completa noção de quanto ele contribuiu para empresa, além de melhorar sua sensibilidade a possíveis interações de venda e marketing de relacionamento.
Além disso, outras situações que contribuíram para o sucesso do projeto foram:
• A possibilidade de mapear os clientes freqüentadores da loja, podendo assim fornecer vantagens aos que mais compram;
• Chamar a atenção dos clientes que menos compraram, sem esquecer de correlacionar o valor agregado de cada compra - volume de compra versus margem de contribuição;
• Melhorar o tratamento das informações operacionais, trazendo as mesmas para o nível mais estratégico da empresa de forma clara e concisa para o gestor de CRM;
• Obter suporte ao ambiente técnico confiável, com maquinário robusto e tolerante à falha, além de maior agilidade no processamento e visualização das informações. 5.1.3. Levantamento dos Riscos
Conseguir prever os possíveis riscos que o projeto enfrentaria foi de grande valia para prever e antecipar a resolução de problemas que pudessem prejudicar o sucesso do projeto. Foram identificados os seguintes riscos:
• Riscos de hardware, como falhas que comprometessem a integridade dos dados;
• Possível sabotagem, interna ou externa do projeto, através de ataques virtuais que danificassem ou expusessem dados não autorizados;
• Compatibilidade dos sistemas integrados, ou seja, a especificação de uma padronização coerente dos dados, dando-lhes uma semântica única. 5.1.4. Requisitos Levantados
A análise de perfil e desempenho de compra do cliente é o desejo dos usuários do data mart aqui especificado, além de alavancar dados sobre venda para entender melhor o cliente, produto e desempenho do canal de vendas.
O gestor de CRM e a equipe de projeto ligada ao assunto necessitavam estimar, de forma rápida e segura, qual o impacto sobre uma possível mudança nas promoções e preços de alguns produtos seriam destinados a um grupo específico de clientes.
Além disso, existiam perguntas analíticas típicas que precisavam, através da implementação do data mart, ser respondidas para acesso a informação:
• Qual a recência de um determinado cliente – quando foi sua última compra?
• Qual a freqüência que o cliente compra? • Qual volume de vendas que a loja teve
com um cliente ou grupo de clientes durante certo período?
• Qual é o valor da compra média do cliente em certo período?
• O cliente já participou de uma promoção que termina em três semanas?
• Qual é o comportamento de venda por categorias de produtos e cliente? Há uma oportunidade para aumentar as vendas? O comportamento mudou durante os últimos meses?
• Qual a margem de contribuição deixada pelo cliente na compra de uma determinada categoria produto e em um determinado período?
• Qual o retorno financeiro do cliente, comparando sua margem de contribuição com o seu volume de compra?
• É possível identificar os clientes oportunistas - aqueles que só compram produtos em promoção - em um determinado período?
92 • Qual o canal de venda mais freqüentado
por um determinado cliente: internet, 0800 ou loja? • Quais as regiões geográficas - residência
do cliente - mais representativas em termos de venda?
• Qual freqüência que o cliente adquire produtos considerados de marca própria – fabricados e comercializados pela própria empresa-?
• Pode-se descobrir informações ocultas ou padrões que mudaram totalmente algumas estratégias ligadas ao CRM?
É importante ressaltar que os requisitos e questionamentos aqui levantados foram usados como base para continuação das próximas etapas deste trabalho. 5.1.5. Modelagem Dimensional
A etapa de modelagem teve como dependência a correta definição dos requisitos funcionais, onde estes servirão de base para a construção do modelo lógico-dimensional que armazenariam as informações capazes de responder os questionamentos impostos. Para construí-lo foram necessários três passos. O primeiro, foi visualizar os assuntos ou o data mart propriamente dito, mostrados através do levantamento de requisitos. No caso deste trabalho, ficou clara a existência de um assunto central que seria quantificado ou medido: a venda do cliente.
A segunda etapa foi definir a granularidade, ou nível de detalhamento do fato venda, a ser seguida. Tratava-se de uma questão essencial para o sucesso do projeto. Foi selecionada a venda diária sumarizada de produtos por cliente como grão da tabela fato. Foi o nível mais detalhado possível e possibilitou ao gestor e equipe realizarem análises minuciosas.
Para qualificar o fato venda fez-se necessário descrever quais seriam as mensurações adotadas para o mesmo. Com isso foram definidas as seguintes métricas: quantidade, valor total bruto, valor total líquido e valor da margem de contribuição, média mensal da margem de contribuição (valor margem de contribuição mensal cliente dividido pelo número de passagem na loja) e média mensal da venda (valor venda mensal cliente dividido pelo número de passagem na loja).
A terceira e última, a descrição do fato venda, julgou-se necessário as seguintes dimensões: tempo em data, tempo em hora, cliente e sua localização geográfica, produto e suas categorias (foram tratados de famílias, para ficar de acordo a semântica da organização), forma de pagamento, canal de venda, loja e promoções realizadas. Vale a pena colocar que as dimensões escolhidas influenciaram diretamente nas respostas de questões que deveriam ser respondidas. Abaixo, na figura 1, é mostrado o modelo lógico gerado:
Figura 1 – Modelagem lógica do Data Mart de Clientes
Com a modelagem lógica foi possível partir
para a modelagem física tendo como base o planejamento do projeto. A partir dai foi definido como pré-requisitos, a utilização do mesmo software SGBD (Sistema Gerenciador de Banco de Dados) que armazenava os dados transacionais, para acomodar o modelo físico do data mart.
Como o SGBD Oracle 10g™, atendeu os requisitos não funcionais deste projeto, ou seja, implementava suporte ao DW, seguiu-se para a definição do modelo físico. Como já se tinha definido o fato e as dimensões a serem tratadas, buscou-se então identificar os atributos das dimensões.
Feita a definição inicial, o próximo passo foi validar os atributos encontrados junto aos interessados, com o objetivo de eliminar atributos desnecessários ou acrescentarem novos. O modelo físico resultante do fato venda é mostrado a seguir, na figura 2:
Figura 2 – Modelagem Física do Data Mart de Clientes 5.1.6. Implantação Física do Modelo Proposto
O ambiente onde foi instalado o data mart, como na etapa anterior, também já havia sido definido na fase de definição de escopo de projeto,
93 pois se fazia necessário à utilização do servidor e banco de dados onde atualmente encontra-se em produção o sistema operacional da organização. Um dos cuidados tomados foi a separação lógica de sistema operacional do ambiente DW.
Outra questão também definida na fase se escopo foi a camada de apresentação do data mart e tinha-se como propósito a utilização de três ambientes OLAP: o Microsoft Excel™, Planilhas do OpenOffice.org™ , além do Discoverer da Oracle™.Estas ferramentas foram consideradas com a própria camada de apresentação dos dados aos usuários, pois possuíam módulo OLAP de exploração de dados.
Após as definições citadas acima, iniciou-se o planejamento das arquiteturas de back end e front end do data mart, já direcionadas também ao modelo proposto. 5.3.3. Arquitetura de Aquisição de Dados (Back End)
No processo de back end, a extração consistiu em acessar e buscar os dados no sistema transacional, necessários para inserção no data mart. Depois de extraídos, eles sofreram as transformações necessárias, ou seja, foram padronizados de acordo com o modelo físico proposto, para então serem armazenados na área de checagem ou de transferência. Aqueles que não necessitaram de modificações foram diretamente levados à área de checagem.
A área de checagem serviu para que os dados pudessem ser consultados, manipulados e marcados se foram ou não sincronizados no sentido sistema transacional data mart, para só então realizar a carga dos fatos.
Este plano foi executado com o auxílio de um conjunto de programas (vide apêndice B) que providenciaram a conectividade com a fonte de dados, limpeza, conversões de formato e correções de inconsistências para adequação dos dados ao modelo proposto. Eles forneceram suporte à linguagem SQL (Structured Query Language), muito comum nos sistemas de bancos de dados, e a PL/SQL, linguagem de programação proprietária da Oracle™, utilizada para escrita de Stored Procedures - pequenos programas em PL/SQL com funcionalidade específica - extremamente eficiente para este projeto.
Finalmente, para controlar a periodicidade do processo ETL, ou seja, realizar a sincronização dos dados operacionais com os do data mart, foram utilizados os chamados jobs, também disponibilizados pelo SGBD da Oracle™ e que são que agendamentos no quais se define o momento em que um determinado procedimento deve ser executado. 5.3.4. Arquitetura de Apresentação dos Dados (Front End)
A camada de acesso aos dados do data mart, a
exemplo das etapas anteriores, também teve seus pré-requisitos de projeto estabelecidos e conhecidos ainda na fase de planejamento.
Além de atender os requisitos definidos no planejamento, as ferramentas adotadas deveriam proporcionar aos usuários, extrema facilidade nas tarefas de navegação entre os dados, resumo e comparação, além de trabalhar de acordo com o modelo de dados implementado.
As ferramentas que atenderam os requisitos foram o MS Excel™ e o OpenOffice.org™ versão 1.1.2, planilhas eletrônicas que possuem recursos de acesso a banco de dado e módulo de pesquisa avançada, módulo este composto por um conjunto de metadados - dados sobre os dados que serão mostrados pelas ferramentas OLAPs - , uma interface de construção e outra de apresentação de consultas.
Atenção especial teve a ferramenta Discoverer da Oracle™, devido sua utilização ser feita em larga escala pelos usuários nas rotinas de acesso aos dados transacionais, já que esta ferramenta dava suporte a dois tipos de ambiente, operacional e DW.
As principais características identificadas no Discoverer foram:
• Ferramenta dotada de visão conceitual multidimensional, suportando o modelo aqui projetado;
• Interface com usuário amigável e intuitiva, tanto no módulo de administração - definição e manutenção de metadados - quanto no módulo de usuário, usando barras de ferramentas e outros recursos básicos que simplificavam a interface;
• Suporte a wizards (assistentes de criação de consultas), que ajudaram bastante na definição de metadados e na construção de consultas.
Conhecidas as ferramentas da arquitetura de apresentação dos dados, sobrou a tarefa de planejar a forma de acesso. Experimentou-se inicialmente a ferramenta OLAP Discoverer por demonstrar flexibilidade de consultas e permitir a criação de condições associadas à folders (equivalente às tabelas do modelo relacional). Estas condições favoreceram o uso de vários operadores e conectores lógicos e, conseqüentemente, os usuários, através do uso destas condições, podiam fazer consultas ou criar suas próprias, extinguindo a necessidade de auxílio da área de informática.
O Discoverer também ofereceu as facilidades básicas de drills e de slice e dice, assim como pivoteamento – inversão de linhas por colunas em um relatório tabular - além de permitir que o usuário não fosse obrigado a descer na estrutura de hierarquia passando por todos os níveis. Se o usuário quisesse poderia pular de facilmente nível na hierarquia acessada, dando-lhe agilidade no momento da navegação dos dados.
Logo após foi a vez das ferramentas MS Excel™ e Open Office™. O que chamou a atenção destes aplicativos foi o recurso denominado tabelas
94 dinâmicas, uma interface OLAP de exploração e cruzamento de informações. Este recurso pode ser alimentado através de consultas feitas diretamente do data mart ou através da criação de cubo OLAP. 6. Resultados Obtidos
Finalmente, todo empenho de modelagem e operacionalização do ambiente foi finalizado. Durante o processo de construção do data mart se fez necessário realizar diversas validações do modelo proposto, junto a todos interessados, buscando garantir que todos os questionamentos realizados na etapa de levantamento de requisitos pudessem ser respondidos com agilidade aceitável. Serão demonstradas a seguir as respostas obtidas para algumas das questões levantadas, visando fornecer suporte à validação do modelo.
Considerando que o data mart teve sua criação baseada em dados de clientes reais, teve-se o cuidado de modificar os dados aqui apresentados a fim de evitar a identificação dos clientes, inibindo assim a associação da informações apresentadas. Isto se deve ao fato de haver um contrato firmado entre a empresa e o cliente e este, por sua vez, possuir cláusulas de confidencialidade.
Como notação para interpretar as tabelas apresentadas, usou-se a descrição dos campos com detalhes em negrito e os valores ou dados dos mesmos sem detalhe algum.
Uma pergunta levantada foi qual seria o volume de vendas que a loja X teve com um cliente ou grupo de clientes durante certo período. O resultado pode ser acompanhado através da tabela 1:
DATA_NORMAL 30/12/2004 NOME_CLIENTE Cliente 1 NOME_LOJA Super Centro Soma de VALOR_VENDA DIA_SEMANA
TIPO_CARTAO Quinta-Feira Total geral
TITULAR 54,84 54,84 Total geral 54,84 54,84
Tabela 1: Volume de venda de um “Cliente 1” em 30/12/2004
A informação apresentada na tabela 1 permitiu, de forma rápida e segura, levantar informações de vendas efetuadas ao “Cliente 1” no dia 30/12/2004.
A seguir, será demonstrado o ambiente que foi disponibilizado como camada de apresentação e visualização dos dados para repositório do data mart de clientes, aqui especificado:
Figura 3 – Ambiente Desktop OLAP Microsoft Excel™.
Figura 4 - Ambiente Desktop OLAP na ferramenta Open Office.org 1.1.2™
Figura 5 - Ambiente Desktop OLAP na ferramenta Discoverer da Oracle™ 7. Conclusão
O presente trabalho se dispôs a auxiliar o gestor e equipe de projetos da área de CRM, no varejo supermercadista, que se utilizam da análise dos dados de clientes para promover a fidelização, aumento de faturamento e lucratividade da organização.
Para isso, foi fornecida através da construção de um data mart, uma ferramenta específica que supriu todas as necessidades e requisitos definidos como alvo de atuação deste trabalho.
Obviamente, como dita o “Ciclo de vida de Kimball”, a utilização rotineira do produto aqui construído apontará para manutenções e evoluções
95 necessárias, naturais a qualquer processo, inclusive na construção de data warehouse.
Uma das expectativas deste trabalho foi resolver o problema da dificuldade na obtenção de informações dos clientes. O fato do processo de extração e preparação dos dados necessários serem automatizados evitou repetições excessivas de procedimentos manuais e onerosos na aquisição dos dados e, principalmente, na grande maioria dos casos, descartou o auxílio da área técnica de informática.
Outro ponto importante vem do fato que a implementação do data mart aqui proposto deu-se em um ambiente um pouco simples, utilizando-se do mesmo servidor físico e do mesmo software de banco de dados relacional no qual o produto já é executado atualmente. Não que a bibliografia da área seja contrária a esse tipo de implementação, mas em alguns casos vislumbram ambientes ideais com grande estrutura tecnológica. A utilização da estrutura já existente, por parte deste projeto, gerou baixo custo de construção e implantação do modelo, unindo o útil ao agradável. Conseguiu-se não criar custos adicionais e aplicar as técnicas de data warehousing no processo de CRM analítico, obtendo-se resultados satisfatórios.
7.1. Trabalhos Futuros
O anseio por melhores processos de análise dos dados do cliente, ou seja, torná-los mais ágeis e automáticos, terminará muitas vezes na necessidade de correção e/ou evolução do modelo aqui proposto.
Como evolução, no que se refere ao fato venda, poderia futuramente levar-se em conta a quantificação da lucratividade no momento da venda do produto. É importante ressaltar neste momento que o cálculo e o levantamento desta métrica são de complexidade elevada, devido às informações contábeis envolvidas.
Por fim, uma evolução natural será através da agregação de novos data marts visando atender novas necessidades e serviços que já existem ou virão a existir no produto. Um novo data mart de Atividades de Clientes que teria como característica principal armazenar as opiniões - elogios, sugestões e reclamações - dos clientes, passando a ser a parte principal das atividades uma vez que o próprio cliente é que direciona a comercialização deste ou daquele produto ou serviço, mediante a sua aceitação no mercado. Uma empresa que conhece bem seus clientes pode trabalhar na solução de problemas que virão a surgir no futuro ou ainda resolver melhor os problemas surgidos no presente com o auxílio dos dados obtidos neste tipo de sistema. 8. Referência Bibliográfica
BERSON, Alex; SMITH, Stephen J. Data warehousing, data mining and olap. McGraw- Hill, 1997. CARDOSO, Mario Sérgio; GONÇALVES FILHO, Cid. CRM em ambiente e-business: como se relacionar com clientes, aplicando novos recursos da web. São Paulo: Atlas, 2001. CYRILLO, Denise Cavallini. O papel dos supermercados no varejo de alimentos. 1986. Tese (Doutorado em Economia) – Faculdade de Economia e Administração, Universidade de São Paulo. São Paulo. FERRAZ, S. F. Uma estratégia para a implantação do gerenciamento do relacionamento com o cliente - CRM - em supermercados.2002. 109 f. Dissertação (Mestrado) - Universidade Federal de Santa Catarina. Florianópolis. INMON, W. H. Building the data warehouse. 3rd ed. New York: John Wiley & Sons, 2002. KIMBALL, Ralph. The data warehouse lifecycle toolkit: expert methods for designing, developing, and deploying data warehouses. New York: John Wiley & Sons, c1998. 771p. PARENTE, Juracy. Varejo no Brasil: gestão e estratégia, São Paulo: Atlas, 2000. PEPPERS AND ROGERS GROUP. CRM series – marketing 1to1. São Paulo: Makron Books, 2001. SWIFT, Ronald. CRM: o revolucionário marketing de relacionamento com o cliente. Rio de Janeiro: Campus, 2001. THOMSEN, E. Olap solutions: building multidimensional information systems. Jonh Wiley & Sons, 1997
![[DIGITE O TÍTULO DA TESE] - projetos.inf.ufsc.br · Web viewWord-key: Basic statistics ... de programação orientada a objetos Java versão cinco, ... modelagem que possibilita](https://img.document.onl/doc/110x75/5c008f9c09d3f20f068b5a0a/digite-o-titulo-da-tese-web-viewword-key-basic-statistics-de-programacao.jpg)
