O relacionamento bancário e o financiamento das PME: Uma revisão da literatura
Implantação de Processos de Gestão de Relacionamento com o Cliente - CRM em Instituição...
Transcript of Implantação de Processos de Gestão de Relacionamento com o Cliente - CRM em Instituição...
Faculdade de Tecnologia
Departamento de Engenharia Elétrica
Curso de Especialização em Gestão de Tecnologia da Informação
WEBER ESTEVAN RODER KAI
Implantação de Processos de Gestão de
Relacionamento com o Cliente - CRM
em Instituição Bancária
Brasília
2013
Weber Estevan Roder Kai
Implantação de Processos de Gestão de
Relacionamento com o Cliente – CRM
em Instituição Bancária
Brasília
2013
Weber Estevan Roder Kai
Implantação de Processos de Gestão de
Relacionamento com o Cliente – CRM
em Instituição Bancária
Monografia apresentada ao Departamento
de Engenharia Elétrica da Universidade
de Brasília como requisito parcial para a
obtenção do grau de Especialista.
Orientador: Prof. Romualdo Alves Pereira Júnior
Universidade de Brasília
Faculdade de Tecnologia
Departamento de Engenharia Elétrica
Brasília
Junho de 2013
© 2013 Weber Estevan Roder Kai. Qualquer parte desta publicação
pode ser reproduzida, desde que citada a fonte.
Kai, Weber Estevan Roder
Implantação de Processos de Gestão de Relacionamento com o
Cliente – CRM em Instituição Bancária / Weber Estevan Roder Kai. –
Brasília: O autor, 2013. 80 p.; Ilustrado; 25 cm.
Monografia de Especialização – Universidade de Brasília.
Faculdade de Tecnologia. Departamento de Engenharia Elétrica, 2013.
Inclui Bibliografia.
1. Tecnologia da Informação. 2. CRM. 3. Bancos Públicos. I. Título.
CDU 004.056
Ata de Defesa de Monografia Monografia de Especialização Lato Sensu, defendida sob o título Implantação de
Processos de Gestão de Relacionamento com o Cliente – CRM em Instituição
Bancária, por Weber Estevan Roder Kai, em 11 de Outubro de 2013, no Auditório da
Faculdade de Tecnologia da UnB, em Brasília - DF, e aprovada pela banca
examinadora constituída por:
Prof.
Romualdo Alves Pereira Júnior
UnB
Orientador
Prof.
Manoel Fernando da Mota Tenorio
UnB
Prof.
Nome do 3º Membro da Banca
UnB
Prof. PhD. Rafael Timóteo de Sousa Jr.
Coordenador do Curso de Especialização em Gestão da Tecnologia da Informação
CEGTI 2011/2012
Agradecimentos
Agradeço a todos que estiveram presentes durante a construção deste
trabalho. Ao meu orientador Romualdo, aos professores, aos meus colegas de
trabalho, aos meus colegas de curso, aos meus pais, à minha namorada Mariana, à
UnB e ao Banco Pub deixo expressa aqui toda a minha gratidão. Muito obrigado!
A genialidade da concorrência do livre-mercado é que
O cliente decide quem vence e quem perde.
E a longo prazo, o cliente é o principal vencedor.
Donald J. Carry, CEO da AMR/American Airlines (1999).
Lista de Figuras
Figura 1: Modelo simplificado do processo de marketing (Fonte: Kotler e Armstrong;
2007, p. 4.). ............................................................................................................... 28
Figura 2: Modelo expandido do processo de marketing (Fonte: Kotler e Armstrong;
2007, p. 23.). ............................................................................................................. 31
Figura 3: Mapa conceitual da metodologia utilizada. ................................................. 40
Figura 4: Diagnóstico dos Problemas Tecnológicos (Fonte: Relatório de Consultoria
Externa). .................................................................................................................... 45
Figura 5: Soluções Propostas aos Problemas Identificados (Fonte: Relatório de
Consultoria Externa). ................................................................................................. 46
Figura 6: Sugestão de Equipe Dedicada para Solucionar os Problemas (Fonte:
Relatório de Consultoria Externa). ............................................................................ 47
Figura 7: Infraestrutura Inicialmente Planejada da Unidade de Relacionamento. ..... 57
Figura 8: Proposta Final da Infraestrutura da Unidade de Relacionamento. ............. 59
Figura 9: Proposta de Contingência da Unidade de Relacionamento. ...................... 61
Figura 10: Resultado do Modelo de Cluster (Fonte: Relatório de Entrega do Modelo
de Cluster). ................................................................................................................ 62
Figura 11: Cestas Estatísticas do Modelo de Basket Analysis (Fonte: Relatório de
Entrega do Modelo de Basket Analysis). ................................................................... 63
Figura 12: Quantidade de Clientes em Cada Cesta - Modelo de Basket Analysis
(Fonte: Relatório de Entrega do Modelo de Basket Analysis). .................................. 64
Figura 13: Clientes com Cestas Completas - Modelo de Basket Analysis (Fonte:
Relatório de Entrega do Modelo de Basket Analysis). .............................................. 64
Figura 14: Curva de Sobrevivência do Produto “Título de Capitalização” (Fonte:
Relatório de Entrega do Modelo de Lifetime Value). ................................................. 69
Lista de Tabelas
Tabela 1: Categorias de ferramentas de CRM (Fonte: Quadros; 2010, p. 91.). ........ 33
Tabela 2: Resumo de Técnicas de Mineração de Dados. ......................................... 36
Tabela 3: Perguntas utilizadas nas entrevistas com os empregados do Banco Pub.41
Tabela 4: Lista de Problemas Identificados (Fonte: Relatório de Consultoria Externa).
.................................................................................................................................. 44
Tabela 5: Aplicações de Software de BI Disponíveis no Banco Pub (Fonte: Caderno
de Hardware e Software). ......................................................................................... 50
Tabela 6: Lista de Relatórios Previstos Inicialmente no Módulo CRM Analítico........ 51
Tabela 7: Tempo Gasto para Geração de Amostras – Modelos Fixos. ..................... 55
Tabela 8: Tempo Gasto para Geração de Amostras – Modelos Pontuais. ............... 55
Tabela 9: Lista de SGBDs Disponíveis no Banco Pub (Fonte: Caderno de Hardware
e Software). ............................................................................................................... 56
Tabela 10: Primeira Parte da Matriz de/ para do Modelo de Cross-Sell (Fonte:
Relatório de Entrega do Modelo de Cross-Sell). ....................................................... 66
Tabela 11: Segunda Parte da Matriz de/ para do Modelo de Cross-Sell (Fonte:
Relatório de Entrega do Modelo de Cross-Sell). ....................................................... 67
Sumário
Ata de Defesa de Monografia ...................................................................................... 3
Dedicatória .................................................................................................................. 4
Agradecimentos .......................................................................................................... 5
Lista de Figuras ........................................................................................................... 7
Lista de Tabelas .......................................................................................................... 9
Sumário ..................................................................................................................... 10
Resumo ..................................................................................................................... 12
Abstract ..................................................................................................................... 14
1 Delimitação do Problema ....................................................................................... 16
1.1 Introdução ........................................................................................................ 16
1.2 O CRM no Banco Pub ..................................................................................... 16
1.3 A Mineração de Dados no Banco Pub ............................................................. 18
1.4 A Inteligência de Clientes no Banco Pub ......................................................... 19
1.5 Formulação da Situação Problema .................................................................. 20
1.6 Objetivos e Escopo .......................................................................................... 23
1.6.1 Objetivo Geral ........................................................................................... 23
1.6.2 Objetivos Específicos ................................................................................ 23
1.6.3 Escopo ...................................................................................................... 24
1.7 Justificativa ...................................................................................................... 24
1.8 Hipóteses ......................................................................................................... 25
1.8.1 Hipótese sobre o Atraso Causado pelas Demandas Pontuais .................. 25
1.8.2 Hipótese sobre o Atraso Causado pelo Tempo de Processamento do SAS
........................................................................................................................... 25
1.8.3 Hipótese sobre os Atrasos Causados por Erros de Processamento ......... 25
1.8.4 Hipótese sobre o Risco do CRM Demorar para Ser Implantado ............... 25
1.8.5 Hipótese sobre o Risco de Retrabalho ...................................................... 25
1.9 Organização do Trabalho ................................................................................ 26
2 Revisão de Literatura e Fundamentos ................................................................... 27
2.1 A Importância do Cliente .................................................................................. 27
2.2 O Modelo de Marketing .................................................................................... 28
2.3 O CRM ............................................................................................................. 29
2.3.1 Vantagens do CRM ................................................................................... 30
2.3.2 Ferramentas de CRM ................................................................................ 31
2.4 A Sabedoria de Clientes .................................................................................. 33
2.5 A Mineração de Dados .................................................................................... 35
2.6 Database Marketing ......................................................................................... 37
3 Metodologia ............................................................................................................ 39
4 Resultados ............................................................................................................. 41
5 Discussão ............................................................................................................... 71
6 Conclusões e Trabalhos Futuros ............................................................................ 73
6.1 Limitações Encontradas ................................................................................... 73
6.2 Conclusões ...................................................................................................... 73
6.3 Trabalhos Futuros ............................................................................................ 75
6.4 Conquistas Alcançadas ................................................................................... 76
Referências e Fontes Consultadas ........................................................................... 77
Lista de Siglas ........................................................................................................... 79
Resumo
Este trabalho é o resultado de um estudo realizado em um banco público
brasileiro para investigar a perda de eficiência durante a implantação do seu
processo de CRM causada por deficiências na infraestrutura tecnológica deste
processo e que poderiam ser resolvidas através de soluções já disponíveis no
próprio banco. O conselho diretor de um banco público brasileiro decidiu implantar a
gestão do relacionamento com o cliente, ou CRM. A implantação iniciou-se com o
planejamento e desenho da estrutura organizacional para operar o processo, e logo
depois começou o desenho do processo em si. Foi adquirida uma ferramenta
corporativa para executar a maior parte das tarefas do CRM com prazo de
implantação completa de quatro anos. Porém houve uma mudança no cenário
externo que demandou algumas ações imediatas do banco, e antes mesmo de
qualquer implantação parcial da ferramenta de CRM adquirida, algumas demandas
foram encaminhadas à unidade para execução manual em caráter de emergência.
Como não havia experiência ou cultura de CRM dentro da organização, foi
contratada uma consultoria externa para ensinar os primeiros passos, e a partir daí
iniciou-se uma busca para obter conhecimentos sobre o seu cliente, suas
necessidades e seus padrões de consumo e comportamento. A consultoria indicou
que neste momento emergencial as técnicas de mineração de dados, ou data
mining, deveriam ser utilizadas como principal ferramenta. E por isso também foi
iniciado um processo de busca, coleta e centralização de dados sobre produtos,
clientes, canais e suas interações entre si, em diversos sistemas corporativos. A
aplicação de software utilizada para executar a mineração de dados foi o SAS, que
já estava em uso na unidade como banco de dados e para alguns processamentos
simples de informações mensais. Porém, ao utilizar-se desta infraestrutura de
hardware, software e armazenamento, houve alguns atrasos no tempo inicialmente
previsto nas entrega de amostras para análise, modelagem e testes de mineração
de dados e modelagem estatística. Foi realizado um estudo comparando a
infraestrutura utilizada por esta unidade com as infraestruturas já disponíveis no
banco e que demandam baixo esforço para implantação, e verificou-se que com
pequenas mudanças, baixo investimento e pouco tempo estas poderiam ser
substituídas para economizar esforço de desenvolvimento e de operação de
processos de mineração de dados aplicados em CRM.
Abstract
This work is the result of a study conducted in a Brazilian public bank to
investigate the loss of efficiency during deployment of its CRM process caused by
deficiencies in technological infrastructure of this process that could be resolved
through solutions already available in bank itself. The board of a Brazilian public bank
decided to implement customer relationship management, or CRM. The deployment
began with the planning and design of the organizational structure to operate the
process, and soon after began the design of the process itself. It was acquired a
corporate tool to perform the most of the CRM tasks with full deployment within four
years. But there was a change in the external environment that demanded some
immediate bank actions, and even before any partial deployment of the CRM tool
being acquired, some demands were referred to the unit for manual execution on an
emergency basis. Since there was no experience or culture of CRM within the
organization, an outside consultant was hired to teach the first steps, and from there
a search was begun for getting knowledge about its customer, its needs and its
consumption patterns and behavior. The consultant indicated in this emergencial
moment that the techniques of data mining should be used as the main tool. And so it
was initiated a process of searching, collecting and centralizing data about products,
customers, channels and their interactions with each other, in various corporate
systems. The software used to perform data mining was the SAS, which was already
used on the unit as the database and some simple processing of monthly data. But
there were some delays in the time originally planned for delivery of samples for
analysis, modeling and testing of data mining and statistical modeling by utilization of
this hardware, software and storage infrastructure. It was conducted a study
comparing the infrastructure used by this unit with the infrastructures already
available in the bank that require low effort for deployment, and it was found that with
minor changes, low investment and short time these could be replaced to save
development effort and operation of data mining processes applied in CRM.
16
1 Delimitação do Problema
1.1 Introdução
O conselho diretor de um banco público brasileiro, cujo nome real não será
revelado por questões de sigilo estratégico, e de ora em diante denominado Banco
Público, ou simplesmente Banco Pub, com aproximadamente cem mil empregados e
aproximadamente sessenta e cinco milhões de clientes, e que já tinha por estratégia
de negócio oferecer as menores taxas do mercado, recebeu a missão de melhorar
ainda mais a atratividade de seus produtos de crédito através de maiores reduções
de taxas e tarifas, com objetivo alegado de, através da competitividade, forçar os
outros bancos atuantes no país a melhorar seus preços.
Para que esta redução fosse sustentável e não haver riscos de ter que
retornar os preços ao patamar anterior, este conselho diretor atuou internamente em
duas frentes, na melhoria da eficiência total e no aumento da carteira de todo o
portfólio de produtos.
Um foco maior foi direcionado para a expansão da base de clientes, inclusive
em produtos que não são empréstimos, como por exemplo, produtos de captação ou
prestação de serviços bancários, com a alegação de que a queda dos custos
possuía um alcance limitado, e já fora atingido.
Finalmente, o conselho diretor do Banco Pub decidiu que era necessário
implantar o Customer Relationship Management, ou CRM, objetivando reduzir os
custos com marketing, reter os clientes lucrativos e melhorar o desempenho em
todos os segmentos do seu portfólio.
1.2 O CRM no Banco Pub
Para executar esta implantação foi criado um projeto interno, e em 2011 este
finalizou suas atividades de planejamento, e culminou com a criação de uma nova
unidade interna específica para tratar do relacionamento com o cliente. Esta unidade
será denominada Unidade de Relacionamento com o Cliente, ou simplesmente
17
Unidade de Relacionamento. A Unidade de Relacionamento iniciou uma licitação
para contratar uma solução de CRM integrada aos sistemas transacionais em
produção. O vencedor da licitação foi um consórcio composto por uma empresa
brasileira e uma americana, que propôs a adoção da plataforma Epiphany por
quarenta e cinco milhões de reais.
A solução adquirida seria composta inicialmente por quatro módulos, a serem
implantados em fases.
O primeiro módulo recebeu o nome de Repositório Central, que será uma
base de dados para atender às necessidades de mineração de dados. Até o início
deste estudo ainda não havia sido realizada uma discussão se a arquitetura do
Repositório Central será relacional ou multidimensional. O Banco Pub não possui em
seu portfólio de soluções outras arquiteturas de armazenamento de dados
escaláveis recentes, conhecidas como BigData, NoSQL e NewSQL.
O segundo módulo recebeu o nome de Outbound Marketing, ou OM, que
servirá para a gestão de campanhas. Nele será possível cadastrar as árvores de
decisões baseadas em eventos dos clientes, chamadas de réguas de
relacionamento. Assim, após escolher os clientes participantes de cada campanha e
os caminhos possíveis que eles poderão percorrer, o Banco Pub já terá uma ação
personalizada pronta para execução após cada interação ou ausência de contato
com o cliente.
O terceiro módulo recebeu o nome de Sales and Services, ou SS. Este
módulo faz o CRM colaborativo, ou seja, trata-se de um portal corporativo para os
usuários que terão contato com os clientes. Durante um atendimento, os usuários da
rede de agências, do telemarketing ou do suporte pós-venda conseguirão visualizar
várias informações, auxiliando no contato. Este módulo vai registrar o que ocorreu
neste contato e o grau de satisfação do cliente, servindo ainda como base para
estudos futuros.
O quarto módulo contratado recebeu o nome de CRM analítico. Este módulo
foi planejado como um repositório de relatórios para realização de consultas triviais
de forma repetitiva.
Depois de algum tempo, foi efetuado um aditivo contratual para aquisição de
mais um módulo. Este módulo adicional recebeu o nome de Interaction Advisor, ou
IA, que será integrado aos canais, e durante uma operação do cliente, executará
uma tomada de decisão automática e instantânea para fazer, ou não, uma oferta ao
18
cliente. O sistema então aprenderá com os sucessos e erros destas ofertas, que irão
compor uma fórmula que será utilizada para gerar um score para cada cliente. Este
score então será utilizado pelo próprio IA para selecionar os clientes em ofertas
futuras, e ainda poderá ser utilizado para selecionar os clientes em outras
campanhas no OM.
É importante observar que cada módulo possui internamente uma base de
dados independente. Durante a carga de outros sistemas eles passam por um
módulo de carga denominado de staging, e por transformações em uma base
temporária intermediária denominada de base integradora.
A Unidade de Relacionamento definiu que todas as ações de CRM serão
executadas manualmente sob regime de contingência até a finalização da
implantação do Epiphany.
1.3 A Mineração de Dados no Banco Pub
A área de soluções de tecnologia da informação, ou TI, definiu a aplicação de
software SAS como plataforma estatística e de mineração de dados.
O SAS é uma aplicação de software estatística organizada internamente em
conjunto de dados, e estes são compostos por observações e variáveis. Esta
organização de dados é semelhante às tabelas, registros e campos de um Sistema
Gerenciador de Banco de Dados, ou SGBD.
Em operação normal, o SAS realiza acesso sequencial em seus conjuntos de
dados, da primeira até a última observação.
Ele foi instalado em um servidor Sun Fire 15000, com oito processadores
SPARC e sistema operacional SunOS 5.10, e as áreas usuárias podem solicitar a
instalação nas estações de trabalho, que utilizam-se de um módulo chamado
SAS/Connect para compartilhar informações, em uma arquitetura do tipo cliente-
servidor.
O Banco Pub já utilizava o SAS antes da criação da Unidade de
Relacionamento. Atualmente a aplicação de software está instalada em um servidor
compartilhado por várias unidades, mas com cada grupo de usuários acessando
somente sua área do sistema de arquivos, através de ajustes de permissão de
leitura e escrita.
19
Após o fechamento mensal dos sistemas corporativos, são gerados arquivos
para importação em outros sistemas que são enviados ao servidor SunOS em várias
pastas de várias unidades.
Cada unidade inicia o processamento de seus arquivos, submetendo uma
série de programas em linguagem nativa da aplicação de software SAS para
transformação de variáveis e convertendo para um formato nativo do SAS.
Todo este processo consome algum tempo e além disso, o fechamento de
muitos sistemas não é realizado no último dia útil do mês. Alguns sistemas são
fechados somente após acerto de todas as irregularidades, já outros sistemas
possuem prazos de fechamento definidos por normas, como por exemplo, alguns
sistemas contábeis possuem prazo de setenta e duas horas para finalizar as
regularizações, e outros sistemas só executam o fechamento no primeiro final de
semana disponível, devido ao alto volume de processamento.
Algumas áreas liberam as informações para uso por outras áreas somente
após finalizarem todos os seus processamentos, já outras áreas optaram por
centralizar todas as atividades no SAS e o utilizam tanto para mineração de dados
quanto como para armazenamento de dados, nas funções de um SGBD.
Assim, o servidor costuma estar sempre com muita atividade e com muitos
usuários simultâneos.
Para evitar lentidão durante a jornada de trabalho dos empregados e para
diminuir o tempo de execução de programas longos, recorre-se ao artifício de
submeter vários programas SAS para executar durante o final de semana, e desta
forma aproveitar a menor concorrência que ocorre nestes períodos.
1.4 A Inteligência de Clientes no Banco Pub
Dentro da Unidade de Relacionamento, foi criado um setor com a finalidade
de entender os clientes do Banco Pub, principalmente através da mineração de
dados, chamado de Gerência de Inteligência de Clientes, ou simplesmente
Inteligência de Clientes, que ficou incumbida de prever o comportamento dos
clientes em até três anos.
Diversas unidades da matriz solicitam informações pontuais, como a
quantidade de clientes em cada segmento mercadológico, quantidade de produtos
de cada segmento, saldo de alguns produtos, volume de captação e distribuição
20
regional. Esta gerência também herdou esta tarefa de responder às demandas
eventuais sobre informações de clientes.
Para início dos trabalhos de estruturação da gerência, o Banco Pub contratou
a consultoria técnica de uma empresa britânica, para efetuar a transferência de
conhecimentos em CRM e estatística, e para a criação de modelos preditivos.
A Inteligência de Clientes ficou incumbida de acompanhar a criação dos
modelos estatísticos necessários até a implantação das ferramentas de CRM
adquiridas.
Para produção dos estudos e modelos, estão sendo utilizadas somente as
aplicações de software já implantadas no Banco Pub, que são a aplicação de
software estatística SAS para mineração de dados e a suíte MS Office para
consolidação e apresentação dos resultados.
Para melhor entendimento do volume de trabalho, quando os trabalhos de
implantação do Epiphany se iniciaram foram mapeados os sistemas que forneceriam
informações para o CRM, e a conclusão final foi que seria necessário reunir dados
de cento e dezessete sistemas corporativos para compor o perfil do seu cliente.
Ainda, foi identificada a necessidade de um histórico de sessenta meses destes
dados, para possibilitar análises do comportamento dos clientes e análises
preditivas.
1.5 Formulação da Situação Problema
Para criação dos modelos de forma manual, definiu-se que seriam utilizadas
as informações históricas de trinta e seis meses. A geração de bases com estas
informações levou seis meses, englobando a tarefa de entendimento de produtos,
mapeamento de variáveis e sistemas corporativos, solicitação e restauração de
backups pela área de tecnologia, geração de programas e processamento.
Infelizmente, após um erro operacional, as bases foram apagadas por
engano.
A gerência decidiu que não havia tempo para gerar as bases novamente, pois
havia limite de prazo no contrato da empresa de consultoria. As bases deveriam ser
recriadas na medida em que fossem necessárias, e o desenvolvimento dos modelos
deveria iniciar imediatamente.
A consultoria solicitou a preparação de diversas amostras em formato SAS,
porém com a geração de variáveis transformadas que não estavam disponíveis nas
21
bases. Isto levou os empregados a gerar cada uma das bases para extração de
amostras manualmente no SAS.
Um dos problemas é que a área de marketing costuma receber as bases para
processamento com muito atraso. Se ocorrerem erros de processamento e estas
rotinas precisarem ser executadas mais de uma vez, o atraso acaba sendo ainda
maior. Segundo os analistas da Unidade de Relacionamento, o prazo médio de
recepção dos dados é de sessenta dias corridos a partir do último dia útil do mês.
Outro problema ocorre quando a equipe não possui os dados necessários.
Nestes casos é preciso efetuar negociação de dados com diversos gestores, copiar
os arquivos, importar no SAS e efetuar verificação de integridade. Devido à
necessidade de obter o layout dos arquivos encaminhados e fazer conversão de tipo
de dados, através de programação em SAS, por diversas vezes o serviço é muito
atrasado.
Segundo os empregados do Banco Pub, para a nova geração das amostras
dos diversos modelos foram necessárias várias semanas para cada uma, entre
discussão, escolha de variáveis e processamento.
Porém, após a validação dos modelos, será necessária a aplicação mensal,
gerando os scores gerados para cada cliente, para cada modelo. De acordo com a
metodologia proposta, seria preciso recriar as bases no mesmo formato das
amostras, mas com toda a carteira de clientes, escalando o problema muitas vezes.
Também será necessário executar monitoramento dos modelos, e
eventualmente realizar manutenção, quando estes não estiverem respondendo
satisfatoriamente. Neste caso todos os passos de desenvolvimento teriam que ser
executados novamente.
Enquanto ocorriam os estudos da modelagem estatística, a Inteligência de
Clientes ficou sobrecarregada com demandas internas e das outras áreas da
empresa, pois as outras áreas da Unidade de Relacionamento não possuem
ferramentas de relatórios, de consultas ou até mesmo meios de acesso aos dados.
A própria Unidade de Relacionamento precisa de várias informações de
clientes, do mercado e da empresa antes de iniciar uma campanha. Estas
informações são reunidas em um único documento chamado briefing, e de acordo
com as informações coletadas, são tomadas decisões diferentes sobre os rumos de
cada campanha.
22
Para solicitações de informações eventuais de outras áreas e geração dos
briefings são necessárias várias consultas, que a Inteligência de Clientes está
realizando pontualmente e manualmente no SAS, e exportadas e formatadas no MS
Office para apresentação, consumindo muito tempo de execução.
Agravando esta situação, temos a tendência de que à medida que as
primeiras demandas forem sendo entregues, mais gestores de produtos devem
formalizar pedidos de campanhas ou informações pontuais, aumentando cada vez
mais esta sobrecarga.
Outro problema ocorre pelo fato do SAS ser uma aplicação de software
estatística, e sua finalidade é realizar cálculos que necessitam somente de um
acesso por cada observação, como média, moda, análise de frequências, e outros.
Por este motivo, ele foi otimizado somente para realizar acesso sequencial em seus
dados, da primeira até a última observação. Para aproveitar desta otimização, cabe
ao programador construir algoritmos sequenciais. De outra forma, qualquer
necessidade de filtragem de dados ou segundo acesso, demanda uma nova leitura
de todo o conjunto de dados. Por esta razão, pequenas consultas demoram o
mesmo tempo que consultas complexas, ainda que critérios de filtragem sejam
aplicados.
Estes problemas poderiam ser minimizados por técnicas de programação
avançadas, mas os usuários nem sempre combinam conhecimento do problema
com experiência de programação, impossibilitando eventuais melhorias.
Esta situação é muito preocupante, pois a execução manual de rotinas
prejudica muito a qualidade do trabalho, e os prazos ficam muito apertados devido à
necessidade de muitas verificações e eventualmente de reprocessamento devido a
erros.
Outra preocupação advém da tendência desta situação melhorar apenas após
a implantação da plataforma Epiphany, ou seja, após quarenta e um meses. Mas
este prazo pode ser estendido se o Banco Pub considerar necessário. Alguns dos
motivos que podem levar a um adiamento no prazo são as necessidades de maior
tempo para a equipe redigir o caderno de especificação e requisitos funcionais para
a equipe de desenvolvimento e as necessidades de aumento de tempo para a
homologação das entregas.
23
Todo este esforço está tirando a Inteligência de Clientes do seu foco, pois
todo o esforço está concentrado em rotinas operacionais de geração de bases de
dados.
A análise dos resultados e o entendimento dos motivos que levam o cliente a
adotar determinado comportamento, bem como estratégias de aproveitamento de
oportunidades estão sendo adiadas para um momento futuro, quando houver mais
fôlego da equipe. Não está havendo tempo hábil para atingir um estágio de
sabedoria de clientes.
Há o risco do foco da Inteligência de Clientes permanecer no nível
operacional, em processamento e tratamento de dados, para a execução das
demandas pontuais, aplicação e manutenção dos modelos, ao invés da busca pelo
conhecimento do seu cliente e descoberta novas oportunidades.
Por último, o contrato com a consultoria externa possui um prazo limitado
para trabalho e entrega, que pode ser adiado somente por poucos meses. Caso seja
empregado muito tempo na geração das bases, haverá pouco tempo para debates
sobre a metodologia empregada e eventuais correções necessárias, o que traz
riscos para a qualidade das entregas.
Diante deste cenário, busca-se descobrir se existem métodos de trabalho
mais eficientes para o alcance dos resultados esperados, e que ao mesmo tempo
demandem pouco esforço de mudanças, principalmente por já estarem disponíveis
na organização estudada.
1.6 Objetivos e Escopo
1.6.1 Objetivo Geral
Este trabalho objetiva estudar os impactos que a ausência de gestão de
processos de TI podem causar nos processos de mineração de dados de CRM no
banco Pub.
1.6.2 Objetivos Específicos
Os objetivos específicos deste trabalho são:
1. Estudar como o nível de maturidade na gestão da infraestrutura tecnológica
pode influenciar na agilidade de desenvolvimento dos modelos estatísticos
preditivos para CRM no Banco Pub;
24
2. Estudar a possibilidade de minimizar os problemas identificados no CRM do
Banco Pub com o emprego de outras ferramentas que já estejam disponíveis
na organização.
1.6.3 Escopo
O escopo deste estudo está limitado ao ambiente de dados da Inteligência de
Clientes utilizado para gerar modelos preditivos no Banco Pub.
Não faz parte deste estudo propor estratégias de TI ou de negócio, ou ainda
averiguar as causas da ausência de governança de TI na Unidade de
Relacionamento, ou justificar a sua importância.
1.7 Justificativa
Este estudo foi motivado pela importância de se atingir a excelência da
administração pública através da qualidade a todos os interessados.
Segundo Lima (2007), a qualidade desde o mantenedor até ao destinatário é
o caminho para se chegar a excelência na gestão pública, que é o destino.
Para o autor, a excelência na gestão pública é composta de três elos:
Processo, resultado e efeito, cada um respectivamente relacionado a uma virtude:
Eficiência, eficácia e efetividade.
Deste modo, a organização pública precisa ser capaz de fazer o máximo com
os recursos que têm disponíveis, e fazer cada vez mais com cada vez menos,
tornando-se continuamente mais eficiente em seus processos.
Porém, ao mesmo tempo, não pode dar valor exagerado à eficiência, a ponto
de sacrificar o resultado. O resultado é o efeito produzido pelos seus processos, e a
organização pública precisa ter eficácia, atingindo bons resultados, ou seja, realizar
a grande totalidade das metas e indicadores estabelecidos previamente.
E por último, a organização também não pode dar valor exagerado aos
resultados, a ponto de sacrificar o efeito. Ele ainda afirma que o efeito é o fiel da
balança que vai mostrar se a missão institucional está sendo cumprida, e qual o
nível de desempenho atingido.
Para melhor compreensão o autor cita contraexemplos, como uma instituição
de saúde que pode vacinar a totalidade da população a custos baixos e as doenças
não diminuírem, ou uma instituição de ensino dar aulas a todas as crianças com
custos baixos e, no final, estas acabam por não aprender nada.
25
Portanto, de acordo com Lima (2007), o efeito é a referência para a
excelência nas avaliações das instituições, por ser o resultado em sua plenitude, e
pode até mesmo desqualificar eficácia e eficiência eventualmente atingidas.
1.8 Hipóteses
Ao avaliar os problemas existentes atualmente que poderiam ser contornados
com ferramentas existentes na organização, tornam-se necessárias as avaliações
de algumas hipóteses.
1.8.1 Hipótese sobre o Atraso Causado pelas Demanda s Pontuais
Se existem meios disponíveis na empresa capazes de gerar as informações
solicitadas com menos esforço, então as demandas pontuais podem gerar atrasos
desnecessários.
1.8.2 Hipótese sobre o Atraso Causado pelo Tempo de Processamento do SAS
Se existem aplicações de software disponíveis na empresa capazes de
armazenar informações do perfil do cliente e acessar somente os registros
necessários durante uma consulta, então o SAS pode demorar demais para
processamento devido à necessidade de percorrer qualquer dataset
sequencialmente.
1.8.3 Hipótese sobre os Atrasos Causados por Erros de Processamento
Se existe alguma solução disponível na empresa para melhorar os
programas, tanto no esforço computacional quanto na confiabilidade, então
podemos minimizar os erros de processamento que ocorrem frequentemente.
1.8.4 Hipótese sobre o Risco do CRM Demorar para Ser Implantado
Se existe alguma solução disponível na empresa para diminuir os esforços
empregados na modelagem preditiva de forma contingencial, então podemos mitigar
o risco de haver problemas causados por atrasos na implantação do Epiphany.
1.8.5 Hipótese sobre o Risco de Retrabalho
Se houver necessidade de ajustes nos modelos, ou até mesmo refazer o
desenvolvimento dos mesmos, então investimentos em infraestrutura adequada
pode trazer redução do prazo total, e poderá ser um investimento certo e não um
desperdício.
26
1.9 Organização do Trabalho
No capítulo 1 vimos o contexto da organização e os problemas enfrentados
que serão estudados neste trabalho.
No capítulo 2 veremos a teoria dos processos de CRM, para estudarmos as
principais técnicas aplicadas e as principais ferramentas de tecnologia de uma
unidade de negócio desta natureza.
No capítulo 3 será apresentada a forma e execução da coleta de dados para
realização deste estudo.
No capítulo 4 serão exibidos os dados coletados que foram relevantes como
evidências para confirmação ou refutação das hipóteses levantadas.
No capítulo 5 será feita a análise e interpretação dos resultados.
No capítulo 6 veremos as conquistas alcançadas com o estudo, as limitações
enfrentadas, e a relação entre os fatos verificados e a teoria.
No final, seguem a referência bibliográfica e a lista de siglas.
27
2 Revisão de Literatura e Fundamentos
2.1 A Importância do Cliente
Para Brown (2001), devido à queda nas margens de lucro e aumento de
concorrência, manter uma estratégia de competição de mercado baseada em preço
está cada vez mais difícil, e para piorar este cenário, a ocorrência de muitas
fragmentações nos tipos de consumidores e nas mídias disponíveis impede que
métodos e técnicas tradicionais de marketing de massa alcancem consumidores
potenciais e obtenham a mesma eficácia nos resultados anteriores.
Ele afirma que por este motivo, o marketing precisou ficar mais dirigido, mais
eficiente e mais eficaz, e assim, esta necessidade levou rapidamente o marketing na
direção oposta ao tradicional marketing de massa e muitas organizações em direção
ao marketing centrado no cliente.
Para Swift (2001), o cliente deve ser colocado como elemento principal das
áreas de marketing, vendas, atendimento e produção, direcionando a ele recursos,
tempo e serviços, e vendo o mesmo como o responsável pela lucratividade,
crescimento a longo prazo e força da empresa.
Ele afirma que as organizações perceberam que a melhor alternativa para
manter um crescimento lucrativo e estável é tratar bem os clientes atuais, executar o
que for necessário para mantê-los e aumentar o volume de negócios com os
mesmos.
Ainda, segundo o autor acima, o significado do termo cliente só foi
compreendido pelas empresas depois de passados quase cem anos do seu
surgimento, no início do século XX, e demorou até que as empresas líderes
passassem a cultivar seus clientes como especiais e deixassem de defini-los em
função de seus produtos.
28
De acordo com Brown (2001), as empresas lucrativas e em expansão são
aquelas cujo ponto focal é o cliente de alto valor, ou seja, o cliente satisfeito, leal e
que gera lucros.
2.2 O Modelo de Marketing
Para Kotler e Armstrong (2007), o marketing é confundido com vendas e
propaganda, devido ao excesso de comerciais, mala direta e ofertas por telefone e
internet existente nos dias atuais. Porém eles consideram que este significado do
termo marketing deveria ser alterado para “satisfazer as necessidades dos clientes”,
pois quando isto for alcançado, as vendas e propagandas serão meras ferramentas,
e neste ponto a organização realizará vendas com facilidade.
Segundo eles, o processo de marketing pode ser definido em um modelo
simples de cinco passos, ilustrado na figura 1 a seguir:
Figura 1: Modelo simplificado do processo de marketing (Fonte: Kotler e Armstrong; 2007, p. 4.).
Para Kotler e Armstrong (2007), cada passo pode ser expandido conforme
abaixo:
1) No primeiro passo, a organização deve analisar as necessidades, os
desejos dos clientes e o mercado em que atuam, pesquisando clientes e o
mercado e administrando informações de marketing e dados dos clientes;
2) Após obter compreensão do cliente e mercado, no segundo passo a
organização elabora uma estratégia de marketing orientada ao cliente,
selecionando os clientes que vai servir através da segmentação de
mercado e da definição do alvo de marketing, e cria uma proposta de valor
através da diferenciação em relação aos seus concorrentes e do seu
posicionamento de mercado;
3) Após definir quais são seus clientes e qual valor irá entregar, a
organização cria um programa de marketing que realmente cumprirá a
29
estratégia definida, através da definição de seu produto, da definição do
preço, de forma que crie valor real para os clientes, do gerenciamento das
cadeias de suprimento e distribuição, e definindo as promoções, que
comunicarão as vantagens oferecidas aos clientes;
4) Os três passos anteriores permitirão que a organização se dedique ao
passo mais importante, que será visto logo à frente e trata-se da
construção de um relacionamento lucrativo com o cliente;
5) O quinto passo será visto mais adiante, no item 2.3.1.
2.3 O CRM
Para Swift (2001), o Customer Relationship Management, ou CRM, é uma
abordagem empresarial que objetiva compreender e influenciar os clientes através
de meios de contato, e que aumenta a venda, a lealdade, a permanência e a
lucratividade dos mesmos, possibilitando obter um retorno sobre o investimento, ou
ROI, positivo.
Ele afirma que uma das premissas do CRM é que o custo de se manter um
cliente atual é muito menor que o custo de conquistar um cliente novo, na proporção
de um para cinco. Os clientes mais lucrativos são justamente os clientes leais, pois
não há custo de aquisição.
De acordo com Swift (2001), o CRM vai permitir a retenção dos clientes
existentes, dos canais lucrativos de interação e a expansão da base de clientes com
clientes certos, e os clientes certos vão direcionar o crescimento, a lucratividade e o
aumento do lucro individual por cliente.
Ele afirma que o processo de CRM pode ser organizado em identificação e
segmentação de clientes, oportunidades de marketing, campanhas e interação pelos
canais, e o objetivo do CRM é aumentar as oportunidades, melhorando a
comunicação com o cliente certo, fazendo a oferta certa pelo canal certo na hora
certa.
Para Swift (2001):
1) Atingir o cliente certo significa gerenciar o ciclo de vida do cliente,
realizando seu potencial de participação na carteira;
2) Oferecermos a oferta certa significa trazer clientes reais e potenciais para
as ofertas, personalizando-as ao máximo para cada tipo de cliente;
30
3) Utilizarmos o canal certo significa executar a coordenação da
comunicação em cada ponto de contato, ter a capacidade de utilizar o
canal preferido pelo cliente e a capacidade de estudar os dados
capturados nos canais para aprendizado contínuo;
4) E a hora certa significa comunicar-se com o cliente de forma relevante e
em tempo real.
2.3.1 Vantagens do CRM
Para Brown (2001), as principais vantagens do CRM com relação ao
marketing de massa são a redução dos custos com marketing, a concentração nas
necessidades dos clientes específicos, facilitando a interação, a possibilidade de
melhor verificação da eficácia de uma campanha, permitir que a empresa saia da
competição por preço e entre em competição por valor agregado, evita o desperdício
de investimento em clientes que não dão retorno e possibilita o direcionamento
destes investimentos em clientes mais rentáveis, diminui o tempo do ciclo de
marketing, diminuindo o tempo de desenvolvimento e vendas de um novo produto,
aumento na eficiência dos canais disponíveis, aproveitando melhor cada contato
com os clientes.
Ele afirma que o CRM possibilita identificar os clientes e identificar os
melhores clientes, alavancar as vendas ou saber o que os mesmos não vão
comprar, saber o momento da venda e detalhes desta ação, conquistar sua lealdade
e descobrir suas preferências, definir o perfil do cliente lucrativo, melhorar os canais
que são oferecidos aos clientes, criar modelos preditivos de vendas e reter os
melhores clientes.
Para Kotler e Armstrong (2007), a organização que construir relacionamentos
com os clientes através da entrega de valor superior, atingirá o quinto passo do
modelo de marketing visto no item 2.2, e criará clientes satisfeitos que
permanecerão fiéis e comprarão mais. Ainda, permitirá que a organização obtenha
valor dos clientes ao longo do tempo, que podem render valores altíssimos para
clientes que permanecem por vários anos. Por último, fornecerá à organização a
oportunidade de realizar outras ofertas aos clientes, aumentando a participação de
cliente, e também a participação de mercado.
A figura 2, a seguir, apresenta o resumo do processo de marketing expandido,
de acordo com Kotler e Armstrong (2007):
31
Figura 2: Modelo expandido do processo de marketing (Fonte: Kotler e Armstrong; 2007, p. 23.).
2.3.2 Ferramentas de CRM
Para Quadros (2010), os sistemas de CRM são divididos em oito categorias,
conforme abaixo:
1) A categoria Sales Forces Automation, ou S.F.A., serve para aumentar a
eficácia e eficiência das áreas de vendas, gerenciando as oportunidades
identificadas junto aos clientes;
2) A categoria Enterprise Marketing Automation, ou E.M.A., serve para
aumentar a eficácia e eficiência das áreas de marketing, principalmente
através da alimentação do S.F.A. com clientes potenciais;
3) A categoria Gerenciamento de Serviços está relacionada com a área de
atendimento pós-venda;
4) A categoria e-CRM envolve os sistemas de autoatendimento, onde o
cliente pode realizar operações sem a necessidade de um atendente;
32
5) Na categoria Mobile CRM encontram-se as ferramentas disponíveis para
acesso através de telefones celulares e smartphones, notadamente com
as mesmas funcionalidades das categorias S.F.A. e Gerenciamento de
Serviços;
6) A categoria CRM verticais inclui os sistemas de CRM já customizados para
uma atividade vertical específica. Segundo Quadros (2003), um sistema
de CRM vertical diferencia-se pelo fato de possuir clientes efetivamente
utilizando a ferramenta em seu segmento de negócio específico, e não
através de customizações de um sistema de CRM desenhado para
atender vários segmentos;
7) A categoria Social CRM engloba as ferramentas que permitem a criação
de diferencial competitivo através das oportunidades identificadas por
computação social, ou seja, em plataformas de negócio colaborativas, que
oferecem benefício comum através de transparência e confiança mútua
entre os clientes;
8) Na categoria CRM analítico estão os sistemas que armazenam dados, e
permitem a extração de informações estratégicas. São os sistemas de
CRM criados com as ferramentas de Data Warehousing, Data Mining,
Reporting e Business Intelligence, ou BI.
A tabela 1, a seguir, apresenta as categorias de ferramentas de CRM, de
acordo com a classificação sugerida por Quadros (2010):
33
Tabela 1: Categorias de ferramentas de CRM (Fonte: Quadros; 2010, p. 91.).
2.4 A Sabedoria de Clientes
Para Swift (2001), no conhecimento de negócio há quatro estágios de
maturidade, que são: Relatórios, análise, predição e sabedoria. A seguir, veremos a
definição de cada um destes estágios, na visão do autor:
1) O estágio denominado “relatórios” é caracterizado pela geração de
informes focados na unidade ou nos produtos para orientar as ações dos
34
empregados, e também em síntese de resumos para acompanhamento da
administração.
2) O estágio denominado “análise” é comparado a um grande conselheiro.
Neste estágio a organização executa consultas personalizadas sob
demanda, executa algumas comparações e modelos, tem clareza nas
perguntas, motiva os empregados através de maiores conhecimentos e
permite descoberta de informações novas. Mas neste estágio a
organização ainda não consegue todas as respostas.
3) O estágio denominado “predição” é caracterizado pela capacidade da
empresa conhecer o presente e predizer o futuro, principalmente em
comportamentos e tendências, e é um dos fatores de sucesso de
organizações em nível mundial.
4) Finalmente, o estágio de “sabedoria” vai permitir que a empresa aproveite
grandes oportunidades. Neste estágio a organização detém o
conhecimento da empresa, de seus clientes, de seus concorrentes e de
seu mercado de atuação. As empresas líderes criam sabedoria para obter
confiança para a tomada de decisões estratégicas através da gestão de
seus relacionamentos e conhecimentos.
Ainda segundo Swift (2001), as empresas precisam prever as necessidades
dos clientes e ter os produtos e serviços que eles precisam antes mesmo deles
tornarem-se seus clientes, e principalmente, antes dos concorrentes.
Para Brown (2001), após a conquista do cliente, é possível o aprendizado de
seus costumes, atos e vontades, e com isso, o aproveitamento de novas
oportunidades.
Ele afirma que o conhecimento dos clientes atuais vai permitir à organização
conhecê-lo e entendê-lo, e assim obter novos clientes, e por isso as organizações
implantaram meios e técnicas de obter conhecimento de seus clientes, em rumo ao
estágio de “sabedoria”.
Swift (2001) destaca que as vantagens desta sabedoria são espantosas e
positivas, pois os clientes sentirão que você atende suas necessidades. Ao mesmo
tempo, a empresa economiza tempo e outros recursos, seus e dos clientes, e torna-
se responsiva, flexível e competitiva, podendo até mesmo oferecer um preço mais
vantajoso.
35
2.5 A Mineração de Dados
Para Swift (2001), a mineração de dados é o processo de busca em bancos
de dados para retirada e exibição de conhecimentos novos, não percebidos
normalmente, para auxílio em tomada de decisões.
Ele afirma que a mineração de dados pode ser aplicada para melhorar o
desempenho em áreas funcionais em que haja necessidade ou oportunidade, e que
tenham dados disponíveis, e neste contexto, a mineração de dados possui dois
objetivos principais: A verificação de hipóteses e a descoberta de oportunidades,
que veremos a seguir:
1. Na verificação de hipóteses, a empresa deve desenvolver uma hipótese
previamente e confirmar totalmente esta hipótese com os dados
disponíveis. Uma das premissas desta técnica é a empresa já possuir uma
suposição de comportamento, e aplicá-la para validar este conhecimento;
2. Na descoberta de oportunidades, a empresa vai utilizar os dados da
organização para descobrir novos conhecimentos de negócio.
O autor classifica a descoberta de oportunidades em dois tipos: Predição e
descrição, conforme abaixo:
2.1. A predição consiste na criação de modelos que irão descobrir
comportamentos futuros, através de comportamentos passados,
prevendo um resultado através de dados conhecidos;
2.2. A descrição consiste em algoritmos e técnicas para descobrir padrões
nos dados a serem entendidos.
Para Swift (2001), na predição podem ser utilizadas técnicas estatísticas
como a regressão, técnicas de redes neurais, ou técnicas de classificação através
indução, por estruturas de decisão ou por regras, sendo que estas podem tanto ser
criadas por humanos ou através de aprendizagem pela máquina.
Ele ainda classifica as técnicas de descrição, conforme abaixo:
2.2.1. Visualização de dados: Técnica que pode ser utilizada para
perceber padrões, relacionamentos ou comportamentos
estranhos. Podem ser criados histogramas, gráficos de dispersão,
ou diagramas para mostrar a relação entre duas ou mais variáveis;
2.2.2. Agrupamento: Técnica que segmenta as populações em grupos,
que podem ser exclusivos ou sobrepostos. Esta técnica é utilizada
36
para facilitar as análises de negócio e simplificar a complexidade,
uma vez que é possível criar um modelo específico para cada
segmento mais facilmente;
2.2.3. Associação ou afinidade: Técnica que descobre a correlação de
um item, ou conjunto de itens, com outros itens, ou conjunto de
itens. Podem ser utilizadas para indicar padrões de compras, ou
também para associar eventos ao longo do tempo;
2.2.4. Sumarização: Técnica utilizada para reduzir grandes
quantidades de dados a resumos significativos de fácil
entendimento, produzindo resultados analíticos excepcionais.
A tabela 2 a seguir apresenta um quadro resumo das técnicas de mineração
de dados, conforme classificação realizada por Swift (2001):
Tabela 2: Resumo de Técnicas de Mineração de Dados. Verificação de Hipóteses
Descoberta de Oportunidades Predição Estatísticas Regressão
Redes Neurais
Classificação Indução por Estruturas de Decisão Criadas por Humanos
Aprendizado pelas Máquinas
Indução por Regras Criadas por Humanos
Aprendizado pelas Máquinas
Descrição Visualização Histograma
Gráficos de Dispersão
Diagramas de Relação
Agrupamento
Associação Padrões
Tempo
Sumarização
De acordo com o autor, a mineração de dados pode ser utilizada em
marketing dirigido, na retenção de clientes, em definição de cesta de produtos, na
segmentação de clientes, na análise da lucratividade, em vendas cruzadas e em
gerenciamento de campanhas. Ainda, a mineração de dados também pode ser
aplicada para predizer os comportamentos dos clientes com considerável sucesso.
Além destas técnicas, Swift (2001) lembra que uma empresa pode
desenvolver outros modelos, alguns para prever a probabilidade de clientes que
deixarão a carteira e outros para calcular o potencial de lucros, e através de
combinações, decidir quais clientes deve tentar reter. A organização ainda poderá
37
desenvolver modelos para entender a necessidade dos clientes, e usar estas
informações para aumentar a lucratividade deles.
2.6 Database Marketing
Para Bretzke (2000), a definição de Database Marketing aceita como padrão
é aquela definida pelo “National Center for Database Marketing”, que é o
gerenciamento dinâmico de base de dados inteligíveis, atualizados, com
informações relevantes sobre os clientes atuais e potenciais. Para ela, o Database
Marketing pode ser utilizado para identificar os clientes atuais e potenciais mais
propensos a responder a ações de marketing, desenvolver um relacionamento de
alta qualidade de longo prazo e com compras repetidas, construindo lealdade, servir
como base para desenvolver modelos preditivos, e para capacitar interações
desejadas no tempo certo com formato certo para o cliente certo e que encantarão o
mesmo. Terá como objetivo melhorar o ROI das ações de marketing e aumentar o
lucro.
Segundo a autora, as empresas confundem os conceitos de Database
Marketing e Data Warehouse, pois ambos são oferecidos em conjunto com
mineração de dados e com o mesmo discurso, e por isso, muitas vezes quem não
está familiarizado com o Database Marketing pode entender que o Data Warehouse
é mais abrangente e capaz de substituí-lo.
Para Bretzke (2000), não se deve confundir o Database Marketing com o Data
Warehouse, pois estes divergem em objetivos, escopo, funções, interfaces e modos
de operação, conforme abaixo:
1) O Data Warehouse é um sistema que irá integrar os dados da empresa
em um único repositório, depurado, consolidado e consistente para
fornecer informações confiáveis, personalizadas e sob demanda, para
auxiliar nas tomadas de decisão estratégicas, e tem como objetivo filtrar
uma pequena porção de dados de uma base que tem como escopo a
empresa toda, tem funções administrativas e de controle, apresenta os
dados limpos e íntegros e armazenam informações históricas;
2) Já o Database Marketing tem como objetivo mostrar o máximo de
informações do cliente, armazena apenas os dados necessários para
montar o perfil dos clientes, tem funções transacionais utilizadas nas áreas
38
de vendas e comunicação, apresenta todos os dados do cliente em uma
única tela, e tem seus dados atualizados a cada contato com o cliente.
Ainda, de acordo com a mesma, é possível realizar o CRM sem o Data
Warehouse, mas nunca sem o Database Marketing.
39
3 Metodologia
Por um período de nove meses, de fevereiro a outubro de 2012, foram
realizadas pequenas entrevistas com os empregados, principalmente durante
reuniões, observações participantes e coleta de artefatos, com o objetivo de debater
as necessidades de TI da Unidade de Relacionamento.
As entrevistas ocorreram com os seis empregados, sendo um gerente, dois
consultores e três analistas, sendo três com formação em TI, um formado em
estatística, um formado em matemática aplicada, e um gerente com formação em TI
e cursando estatística.
As observações participantes tiveram como objetivo confirmar alguns relatos
dos empregados, e envolveram a medição do tempo de execução das atividades de
geração de amostras, e a execução de algumas rotinas no ambiente SAS, para
confirmar as dificuldades apontadas.
A coleta de artefatos envolveu a consulta de relatórios gerados por consultoria
externa para análise dos problemas de TI da Unidade de Relacionamento, na
realização de consultas em um sistema do Banco Pub para buscar por aplicações de
software disponíveis na organização, na consulta aos requisitos das soluções de
CRM planejadas inicialmente para estudo das funcionalidades de cada ferramenta, e
na consulta a relatórios de modelos preditivos entregues após a construção.
A figura 3 a seguir ilustra a metodologia utilizada para este estudo:
41
4 Resultados
Durante o desenvolvimento dos modelos estatísticos, os gestores da área de
Inteligência de Clientes controlavam o andamento dos trabalhos por mensagens
eletrônicas, que eram trocadas entre estes e a consultoria externa. E a cada 15 dias,
os empregados eram chamados para reuniões, para solucionar os atrasos
recorrentes nas entregas das amostras apontados nestas mensagens. De acordo
com estes gestores, caso futuramente houvesse algum problema no contrato ou na
qualidade do modelo, essas comunicações poderiam ser utilizadas pela consultoria
para reduzir sua responsabilidade sobre um eventual resultado insatisfatório.
Nestas reuniões, os empregados eram convidados a expor os problemas que
estavam levando à perda de agilidade no Banco Pub, e por isso causando a perda
do prazo combinado para a entrega das amostras.
Nestas oportunidades os empregados foram entrevistados sobre as questões
relacionadas abaixo:
Tabela 3: Perguntas utilizadas nas entrevistas com os empregados do Banco Pub.
1) Quais os motivos que levaram ao atraso na entrega das amostras?
2) Estes motivos já foram eliminados para as próximas amostras?
3) Quanto esforço é necessário para eliminar os problemas remanescentes?
4) Observações livres caso consideradas oportunas.
As respostas foram compiladas pelos empregados da Gerência de
Inteligência de Clientes e foi gerado um relatório, que será mantido em sigilo por
motivos estratégicos, mas cujo resultado será resumido abaixo:
O maior motivo para a perda de prazo era a concorrência de atividades
simultâneas, no caso entre a geração de amostras e as demandas pontuais. Como
42
os sistemas não estavam entregues, todas as demandas da Unidade de
Relacionamento eram realizadas manualmente, e estes trabalhos demandavam
muito esforço, principalmente pela arquitetura não adequada.
O segundo maior motivo apontado para a perda dos prazos, era o tamanho
da própria atividade de geração de amostras em si, que necessitava de muito
esforço. No princípio, a Unidade de Relacionamento acreditava que o
desenvolvimento dos modelos ocorreria uma vez, e que uma vez prontos,
ocorreriam somente manutenções pontuais esporádicas. Por este motivo não
chegou a ser considerada a realização de investimentos para uma arquitetura
específica para esta atividade, mas somente a criação de uma base cruzada com
todas as variáveis disponíveis em todas as bases disponíveis. Porém após a perda
acidental desta base, o esforço todo teve que ser refeito de forma pontual. Além
disso, ainda temos o retrabalho constante, devido à erros na especificação inicial ou
mudanças na solicitação durante a geração da amostra.
O último motivo apontado pelos empregados para a perda dos prazos, era a
baixa maturidade dos programas executados. Mais especificamente, os programas
possuem problemas de tempo de execução, considerados não otimizados e muito
lentos. Este problema seria generalizado, assim as rotinas mensais não estariam
otimizadas, o que influencia em todas as atividades. Os programas das demandas
pontuais também estariam ruins, o que influencia na concorrência das atividades. E
os programas de geração de amostras também estariam ruins, e a combinação de
todos os fatores estaria influenciando e colaborando para a perda do prazo.
Todos os empregados confirmaram que os motivos acima não foram
superados, e que ainda iriam influenciar as demandas futuras.
Os três empregados com formação em TI ainda estimaram que com uma
equipe composta por três membros, seria possível eliminar os problemas em dois
anos.
Nas observações livres, os empregados demonstraram uma preocupação
grande com a alta probabilidade de continuidade por muito tempo deste ambiente
tecnológico ruim. Os empregados estimaram que uma eventual melhoria ocorreria
somente após 48 meses, que foi o prazo fornecido pelo fornecedeor para a entrega
do Epiphany. Como todos os membros da equipe estavam alocados em atividades,
não havia recurso disponível para executar as mudanças necessárias para eliminar
os problemas citados anteriormente.
43
Além dos problemas descoberto internamente, a Unidade de Relacionamento
contratou uma consultoria externa para indicar melhorias na metodologia de criação
de modelos e preparação de amostras, com foco em recomendações de TI,
solicitando a presença de um consultor especialista em processamento de grande
volume de dados. Este consultor realizou entrevistas individuais com todos os
empregados, analisou e compilou os relatos de dificuldades, prospectou as
potenciais soluções e enviou um relatório apontando as recomendações para a
infraestrutura.
O documento enviado foi analisado e percebeu-se que os principais
problemas apontados em reuniões pelos empregados também foram percebidos
pelo consultor externo, exceto as demandas pontuais que não estavam no escopo
do consultor. Algumas figuras e tabelas foram retiradas deste relatório e serão
apresentadas aqui, mas sua fonte será mantida em sigilo por motivos estratégicos
do banco Pub.
A tabela 4 a seguir foi retirada deste relatório e relaciona os problemas
identificados com as soluções propostas pelo consultor externo:
44
Tabela 4: Lista de Problemas Identificados (Fonte: Relatório de Consultoria Externa). R
eco
me
nd
açõ
es
de
Ma
ior
Pra
zo
Iden
tifi
car
req
uis
ito
s e
mo
del
ar r
epo
sitó
rio
cen
tral
co
m
tod
as a
s in
form
açõ
es n
eces
sári
as e
arq
uit
etu
ra d
e ex
traç
ão
e tr
ansf
orm
ação
de
dad
os
de
man
eira
a:
-Ter
bo
a p
erfo
rman
ce n
a ca
rga
de
dad
os
de
sist
emas
fo
nte
s e
exec
uçã
o d
as t
ran
sfo
rmaç
ões
nec
essá
rias
-Ter
bo
a p
erfo
rman
ce n
a ex
ecu
ção
de
mo
del
os
-Gu
ard
ar d
ado
s co
m a
gra
nu
lari
dad
e e
his
tóri
co
nec
essá
rio
s
-Gar
anti
r q
ual
idad
e e
inte
grid
ade
do
s d
ado
s -T
er d
ado
s at
ual
izad
os
par
a an
ális
e Id
enti
fica
r te
cno
logi
a
de
ban
co d
e d
ado
s ad
equ
ada
par
a im
ple
men
tar
esse
no
vo
rep
osi
tóri
o
Rev
er a
rqu
itet
ura
de
soft
war
e p
ara
ser
po
ssív
el e
xecu
tar
tod
os
os
pro
cess
os
de
bas
e fu
ll n
o s
ervi
do
r
Se d
etec
tad
o q
ue
o h
ard
war
e é
inad
qu
ado
par
a o
s vo
lum
es
de
pro
cess
amen
to, i
den
tifi
car
e ad
qu
irir
har
dw
are
adeq
uad
o p
ara
o a
mb
ien
te S
AS
de
man
eira
a e
xecu
tar
os
bat
ches
de
carg
a /
tran
sfo
rmaç
ão d
e d
ado
s b
em c
om
o a
ex
ecu
ção
do
s m
od
elo
s em
um
tem
po
red
uzi
do
e p
erm
itir
fore
cast
s ad
equ
ado
s p
ara
um
ho
rizo
nte
de
3 m
eses
(c
on
sid
erar
pla
tafo
rmas
esp
ecia
lizad
as, c
om
o E
xad
ata,
Te
rad
ata
e N
etee
za);
Inve
stig
ar a
po
ssib
ilid
ade
de
a
aplic
ação
SA
S su
po
rtar
pro
cess
amen
to p
aral
elo
; Im
ple
men
tar
esq
uem
a d
e fa
ilove
r d
e m
anei
ra a
gar
anti
r
dis
po
nib
ilid
ade
adeq
uad
a
Cri
ar a
mb
ien
tes
sep
arad
os
de
des
envo
lvim
ento
, tes
tes
inte
grad
os
e p
rod
uçã
o; e
du
car
a ár
ea u
suár
ia e
m c
om
o
uti
lizar
ess
es a
mb
ien
tes
Re
com
en
da
çõe
s d
e C
urt
o P
razo
* M
on
ito
rar
tod
os
os
com
po
nen
tes
de
solu
ção
(m
emó
ria,
CP
U, d
isco
, red
e, e
tc)
par
a id
enti
fica
r ga
rgal
os
de
per
form
ance
e s
olu
ções
ad
equ
adas
* D
ocu
men
tar
seq
uên
cia
com
ple
ta d
e p
roce
ssam
ento
s d
e d
atas
ets
SAS
e id
enti
fica
r
qu
ais
dem
ora
m m
ais
(esp
ecia
lmen
te
TRA
NS_
FIN
AL2
, CA
RTÕ
ES_F
INA
L e
BA
SE_F
INA
L)
* To
mar
açõ
es c
orr
etiv
as a
deq
uad
as a
gar
galo
s id
enti
fica
do
s -
aum
enta
r m
emó
ria,
ree
stru
tura
r
arq
uiv
os,
red
esen
har
pro
cess
amen
to, o
tim
izar
re
de,
etc
* A
um
enta
r ta
man
ho
do
dis
co a
tual
res
erva
do
p
ara
a ár
ea d
e In
telig
ênci
a d
e C
lien
tes
Au
tom
atiz
ar a
lgu
ns
pro
cess
os
um
a ve
z q
ue
form
ato
s d
e ar
qu
ivo
s se
est
abili
zem
(h
á ta
mb
ém o
m
esm
o is
sue
na
un
idad
e q
ue
lhes
en
via
os
dad
os.
)
Exec
uta
r o
qu
e fo
r p
oss
ível
no
ser
vid
or;
dia
gno
stic
ar c
ausa
s d
e in
terr
up
çõe
s
Gra
vi
da
de
A
lta
Méd
ia
Alt
a
Méd
ia
Méd
ia
???
Méd
ia
Su
má
rio
de
Co
nst
ata
çõe
s
Dad
os
mu
ito
des
atu
aliz
ado
s (D
+ 6
0)
e p
oss
ivel
men
te
inco
nsi
sten
tes
par
a a
exec
uçã
o d
e m
od
elo
s p
red
itiv
os;
d
ado
s d
e se
gmen
taçã
o e
stão
em
D+1
20
Às
veze
s é
dif
ícil
sab
er o
nd
e es
tão
alg
un
s ca
mp
os
na
estr
utu
ra d
e d
ado
s at
ual
, o q
ue
gera
dem
ora
s n
o
pro
cess
o
Pro
cess
o d
e ex
traç
ão e
pre
par
ação
de
dad
os
par
a m
od
elag
em, b
em c
om
o p
roce
sso
de
exec
uçã
o d
os
mo
del
os,
leva
m t
emp
o d
emas
iad
o
Há
mu
ito
s p
roce
sso
s se
mi-
man
uai
s n
a p
rep
araç
ão d
e
dad
os
Pro
ble
mas
no
am
bie
nte
inte
rro
mp
em p
roce
ssam
ento
,
qu
e p
reci
sa s
er r
ein
icia
do
; Pro
cess
os
dem
ora
do
s sã
o
exec
uta
do
s n
as e
staç
ões
de
trab
alh
o, o
qu
e ge
ra m
aio
r p
rob
abili
dad
e d
e in
terr
up
ção
e r
ein
ício
Ain
da
não
rec
ebi a
lgu
mas
info
rmaç
ões
so
bre
a
arq
uit
etu
ra d
e h
ard
war
e e
red
e, a
par
ente
men
te n
ão
há
esq
uem
a d
e fa
ilove
r d
e co
mp
on
ente
s p
rin
cip
ais
e o
har
dw
are
po
de
ser
em p
arte
res
po
nsá
vel p
or
len
tid
ão
no
pro
cess
amen
to
Não
exi
stem
am
bie
nte
s se
par
ado
s d
e
des
envo
lvim
ento
, tes
tes
e p
rod
uçã
o, e
spec
ialm
ente
p
ara
roti
nas
de
carg
a e
tran
sfo
rmaç
ão d
e d
ado
s,
gera
nd
o in
efic
iên
cias
nas
ati
vid
ades
Ca
teg
ori
a
QU
ALI
DA
DE
AG
ILID
AD
E
PER
FOR
MA
NC
E
AG
ILID
AD
E
DIS
PO
NIB
ILID
AD
E
PER
FOR
MA
NC
E
PR
OD
UTI
VID
AD
E
45
De acordo com a tabela 4 anterior, podemos perceber que a Inteligência de
Clientes enfrenta problemas para desenvolver modelos preditivos, e que os
empregados atribuem estas dificuldades a problemas de maturidade de processos
de tecnologia, como programas não otimizados ou parametrizados, modelagem de
dados, problemas de cargas de dados e desempenho de ambiente. A consultoria
também pede para a Inteligência de Clientes analisar a possibilidade de uso de
soluções baseadas em Big Data, como Exadata, Teradata e Neteeza.
A figura 4 a seguir também foi retirada do mesmo relatório e relaciona os
problemas enfrentados pela equipe com a configuração atual da arquitetura de TI:
Figura 4: Diagnóstico dos Problemas Tecnológicos (F onte: Relatório de Consultoria Externa).
Na figura 4 acima, podemos ver que o consultor detectou gargalos na
arquitetura de TI, como a carga dos dados que são feitas sem sincronismo, a
modelagem dos dados que não é adequada e também na infraestrutura, como o
hardware inadequado.
O consultor externo apontou algumas soluções, conforme figura 5 a seguir:
46
Figura 5: Soluções Propostas aos Problemas Identifi cados (Fonte: Relatório de Consultoria Externa).
47
De acordo com a figura 5 anterior, o ideal seria a inclusão de uma etapa de
Extract, Transform and Load, ou ETL, que consiste em extrair os dados do sistema
legado, efetuar conversão ou cálculos com os dados, e realizar a carga em outro
sistema. Neste caso, o sistema seria um Data Warehouse, que precisaria ser
incluído na arquitetura também. Após estas etapas, os dados poderiam ser
trabalhados pela Inteligência de Clientes no SAS.
Sobre a correção dos problemas, o relatório apresenta a figura 6 a seguir:
Figura 6: Sugestão de Equipe Dedicada para Solucion ar os Problemas (Fonte: Relatório de Consultoria Externa).
De acordo com a figura 6 anterior, o consultor considerou que os problemas
não podem ser resolvidos rapidamente, exigindo uma equipe dedicada por dez
semanas só para as implantações emergenciais de curto prazo, porém, a equipe da
Unidade de Relacionamento é composta por um gerente e cinco técnicos, e a
solução apontada possui restrições de aplicação, já que aponta a necessidade de
um gerente e quatro técnicos por dois meses.
48
Ainda, a consultoria considerou um universo de soluções bem mais
abrangente, como por exemplo, através da inclusão de dois novos sistemas, um de
ETL, e outro de Data Warehouse, sugerindo a avaliação de compra de
equipamentos específicos para as atividades de TI apoiadas em Big Data, a criação
de uma equipe somente para as melhorias de TI, pois a mesma considerou que os
problemas detectados não podem ser resolvidos por soluções simples, exigindo uma
mudança radical em toda a infraestrutura tecnológica.
Porém quase todas estas decisões estão fora do poder de decisão da
Unidade de Relacionamento, pois existe uma área específica no Banco Pub para
cuidar de TI. Ainda, a aquisição de aplicações de software e equipamentos precisa
passar por licitação, que costuma ser um processo bastante complexo, e algumas
vezes demorado.
Desta forma, ainda é preciso tentar resolver alguns problemas sem novas
aquisições de aplicações de software e através alterações na infraestrutura
tecnológica projetada inicialmente, principalmente nos sistemas que não começaram
a ser implantados.
Nas entrevistas, o principal problema apontado pelos empregados foi o
excesso de demandas pontuais. Quatro empregados que participam do controle ou
execução deste tipo de demanda afirmaram que estas levam um dia para serem
programadas, mais um dia para execução, e mais algumas horas para análise,
conferência e organização do resultado em formato para apresentação.
Os empregados ainda afirmaram que todo este esforço acaba por atrasar as
modelagens estatísticas, pois muitas demandas acabam priorizadas com relação às
tarefas já em execução por serem urgentes e pelo fato de não haver outra forma de
se obter estas informações. Além disso, muitas vezes os estudos são infrutíferos, ou
precisam ser refeitos com outras premissas, pois partiram de hipóteses erradas.
Os mesmos empregados afirmaram que se houvesse alguma ferramenta
exploratória simples, muitas demandas poderiam ser entregues, e várias hipóteses
poderiam ser confirmadas ou refutadas por esta eventual ferramenta, reduzindo o
esforço empregado com demandas pontuais.
Observa-se então, que o primeiro gargalo percebido na Unidade de
Relacionamento é a concorrência entre a execução de demandas pontuais e as
atividades de mineração de dados.
49
A mineração de dados e obtenção de conhecimento do cliente muitas vezes
fica em segundo plano para que sejam executadas demandas de menor
complexidade, mas muito urgentes, como a compilação de informações em forma de
relatórios.
Os relatórios são importantes para as instâncias hierarquicamente superiores,
porém uma vez detectada a recorrência desta necessidade, a Unidade de
Relacionamento deveria possuir meios de levantar informações de maneira ágil e
sem esforço, e principalmente independente das outras atividades, sem causar
atrasos em outras entregas importantes ou em entregas com prazos definidos em
contratos.
Para reduzir a quantidade de demandas pontuais que são encaminhadas à
Inteligência de Clientes, seria preciso oferecer uma ferramenta que permitisse aos
outros empregados consultar as bases de dados. Esta ferramenta teria que ser
versátil o suficiente para gerar relatórios personalizados sob demanda.
Foi observado também que existem soluções disponíveis na organização para
esta finalidade. A busca foi realizada em uma ferramenta interna com o cadastro de
todas as aplicações de software adquiridas, denominada “Caderno de Hardware e
Software”. A origem deste sistema será mantida em sigilo por motivos estratégicos
do Banco Pub.
Após uma busca na categoria “sistemas de apoio à tomada de decisão”,
foram encontradas duas aplicações de software capazes de atender a esta
necessidade, o Business Objects e o Pentaho BI, conforme pode ser observado na
tabela 5 a seguir:
50
Tabela 5: Aplicações de Software de BI Disponíveis no Banco Pub (Fonte: Caderno de Hardware e Software).
Caderno de Hardware/Software
Relatório Parametrizado de Software
Gerado em 05/11/2012 - 13h12
Nome do Software Versão Fabricante
BUSINESS OBJECTS 6.5.1
SAP BUSINESS
OBJECT
BUSINESS OBJECTS CLIENT XI R2
SAP BUSINESS
OBJECT
DECISION TIME 1.1 SPSS BI
PENTAHO DATA INTEGRATION 4.3.0 SOFTWARE LIVRE
Foi percebido que a ferramenta concebida originalmente para ser a grande
fonte de informação da Unidade de Relacionamento foi o CRM analítico.
Consultando-se os requisitos desta ferramenta, percebeu-se que, a princípio, ela
não foi definida como um módulo de BI, mas sim como um módulo de relatórios pré-
definidos, conforme pode ser observado na tabela 6 a seguir, cuja fonte é um
caderno de especificações do CRM Analítico, que será mantido em sigilo por
motivos de estratégia do Banco Pub:
51
Tabela 6: Lista de Relatórios Previstos Inicialmente no Módulo CRM Analítico. Tipo Bloco Aplicação Cartões de Crédito Aplicação Crédito Imobiliário Aplicação Crédito Rotativo Aplicação Empréstimos Cadastro Cadastro de Clientes Cadastro Entidades do Governo Canal Internet Banking Canal Agências (Caixas) Canal Central de Atendimento Canal Terminais de Auto-atendimento (salas,
Correspondentes Bancários e banco 24hs) Captação Aplicações Financeiras Captação Depósitos Captação Poupança Fidelização Consórcio Fidelização Seguros, Capitalização e Previdência Outros Risco de Crédito Serviço Cartões de Débito e Cheque eletrônico Serviço Cesta de Serviços Serviço Convênios Serviço Débito Automático Serviço Geo-análises Serviço Credenciamento Serviço Ouvidoria Externa
Porém, caso a definição do CRM Analítico fosse alterada para utilizar a
arquitetura multidimensional, as demandas pontuais poderiam ser entregues com
menos esforço e em menos tempo, e ainda, várias hipóteses poderiam ser testadas
sem esforço.
Mas a grande vantagem seria permitir que os demais usuários pudessem
obter várias informações necessárias sozinhos, causando a eliminação da
sobrecarga sobre a equipe, e liberando a mesma para dedicação maior na
modelagem estatística.
O segundo grande problema apontado pelos empregados é o esforço
necessário para gerar quaisquer amostras para desenvolvimento de modelos. Cinco
empregados que participam desta atividade relataram que leva muito tempo para
construir uma amostra.
Estes empregados relataram que a dificuldade desta atividade está na falta de
dados preparados para amostragem imediata e a complexidade para se fazer
quaisquer transformações na base disponível. Por exemplo, com as ferramentas
utilizadas para esta atividade, uma transformação simples, como a conversão de
52
data de nascimento em idade, acabava por ser demorada, uma vez que exige ao
menos uma passagem por todos os sessenta e cinco milhões de clientes, e
demandava no mínimo seis horas de processamento.
A consultoria externa contratada para fazer a modelagem estatística, sugeriu
a construção de seis modelos para aplicação em atividades de CRM: Cluster, basket
analysis, cross-sell, lifetime value, churn e recuperação.
O modelo de cluster serve para separar os clientes com perfil semelhante em
grupos, para tratamento diferenciado, ou em campanhas, ou em novas modelagens
estatísticas de forma estratificada.
O modelo de basket analysis busca a relação que existe entre produtos
através do tempo, ou seja, encontrando quais produtos teoricamente levam ao
consumo de demais produtos.
O modelo de cross-sell compara quais produtos o cliente possuía e quais
passou a possuir, pretendo-se prever quais produtos os clientes estão propensos a
adquirir, em ordem de prioridade.
O modelo de lifetime value calcula o valor do ciclo de vida do cliente, através
da combinação da rentabilidade atual dos clientes com a rentabilidade potencial.
Esta informação pode então servir para diversas análises.
O modelo de churn busca descobrir quais clientes estão prestes a abandonar
a carteira, cancelando algum produto, e permitindo ofertas que possam garantir sua
fidelização.
O modelo de recuperação busca identificar os clientes que cancelaram
produtos e que poderiam retornar à carteira com facilidade, ou seja, serem
recuperados.
Para a construção dos modelos de basket analysis, cross-sell e lifetime Value
foram considerados agrupamentos dos produtos oferecidos, obtendo-se dezesseis
grupos de produtos:
1) Conta Corrente: Contém todos os produtos do tipo conta corrente, como
por exemplo, conta corrente comum, conta digital sem tarifas ou conta-
salário;
2) Poupança: Agrupamento de várias modalidades de cadernetas de
poupança;
3) Seguros: Agrupa os seguros de vida, residencial e automóveis;
4) Previdência: Produtos de previdência privada;
53
5) Título de Capitalização: Trata-se de uma modalidade de investimento com
pagamento único ou mensal, e retorno no final do prazo aplicado;
6) Títulos Imobiliários: Títulos lastreados em imóveis dados como garantias
dos financiamentos imobiliários, utilizados para arrecadar recursos para
tesouraria;
7) Fundos de Renda Fixa e Renda Variável: Opções de investimentos
negociados a taxa pré-fixadas ou variáveis de acordo com outros índices
econômicos;
8) Débito Automático: Não se trata de um produto, mas da ocorrência de
pagamento de boleto bancário cadastrado em débito automático. Seu
estudo é muito importante para as organizações bancárias, pois fideliza
muito os clientes;
9) Consórcio: Grupo que abriga as modalidades residencial e automóveis.
Trata-se de um produto misto, pois até o cliente ser sorteado, é um
investimento, pois só ocorre aporte de recursos. Caso ocorra a
contemplação em sorteio, o produto vira um empréstimo sem incidência de
juros;
10) Cheque Especial: É um empréstimo associado à conta corrente, e pode
ser utilizado também através de meios eletrônicos, bastando haver uma
movimentação em uma conta sem recursos dentro do limite máximo
contratado;
11) Consignação: Empréstimo cujas parcelas são debitadas da conta-salário
na ocorrência de crédito de verbas salariais;
12) Crédito Pré-aprovado: É uma modalidade de empréstimo que pode ser
feita pelo próprio correntista diretamente nos caixas eletrônicos com
liberação imediata dos recursos, pois a análise de crédito é feita
previamente;
13) Credito Imobiliário: Todos os empréstimos para financiamento de imóveis
residenciais ou comerciais, novos ou usados, dentro ou fora do Sistema
Financeiro de Habitação;
14) Cartão de Crédito: Modalidade de empréstimo sem juros até o vencimento
da fatura do cliente, e que agrupa as bandeiras Visa e Mastercard;
54
15) Outros Empréstimos ou Financiamentos: Grupo que abriga as demais
modalidades de empréstimos que não possuem significância para formar
um grupo isolado;
16) Demais Produtos: Grupo que abriga os demais produtos que não
apresentaram significância estatística. Curiosamente o produto Certificado
de Depósito Bancário, ou CDB, entrou neste grupo. O CDB é um
investimento cujos recursos são utilizados pelos bancos para empréstimos
entre si, retornando um pouco dos juros pagos neste empréstimo ao
cliente.
Além destes modelos, o Banco Pub solicitou à consultoria externa, através de
aditivo contratual, mais alguns modelos para uso em campanhas pontuais. Estes
modelos buscam prever quais clientes possuem propensão de contratação à
determinado produto e foram denominados modelos pontuais: Consignado, pré-
aprovado, materiais de construção, conta corrente, letras imobiliárias.
Estes modelos levam em consideração o mesmo grupo de produtos do
modelo de basket analysis, exceto materiais de construção, que é um financiamento
específico para materiais de construção, e letras imobiliárias, que considerou
somente um tipo de títulos imobiliários.
A consultoria externa solicitou amostras de oito a doze milhões de clientes,
que correspondem a aproximadamente cinco por cento da população estudada, mas
cada uma com uma característica diferenciada conforme o modelo que seria
desenvolvido. Por exemplo, uma destas amostras deveria ter informações sobre o
perfil do cliente e sobre a posse de produtos, em outra, o cliente deveria ter ao
menos um produto em cada mês, durante os últimos trinta e seis meses estudados,
em outra o cliente deveria ter ao menos um produto no último mês do período em
estudo, e em outra o cliente deveria ter abandonado algum produto durante os
últimos trinta e seis meses.
Porém, se o teste de uma hipótese levava a resultados não aproveitáveis, a
consultoria solicitava novas amostras com variáveis diferentes, ou com clientes
selecionados de formas diferentes. Para exemplificar, se o saldo de conta corrente
não foi significativo estatisticamente para algum modelo, mas sabe-se que saldo tem
muita importância para o negócio em estudo, a consultoria solicitava a troca desta
variável pelas médias dos últimos três, seis e doze meses, para novos testes de
hipóteses. Outro exemplo, se a posse de um produto importante não foi significativa,
55
deveria ser criada uma variável binária indicando se o cliente aumentou ou diminuiu
a quantidade de produtos no mês para novos testes.
Combinados a quantidade de hipóteses com o grande volume de
processamento, foram empregadas quatro semanas para gerar cada amostra dos
modelos de cluster, basket analysis, cross-sell e life-time value. Para os modelos de
churn e recuperação não houve registros de prazo, mas os empregados especulam
que levaram aproximadamente o mesmo tempo de quatro semanas.
Para alguns modelos pontuais mais simples e de escopo menor também não
houve registro de tempo, mas apesar da simplicidade muito menor, especula-se que
levaram duas semanas para geração das amostras.
O tempo gasto com a geração de amostras para a construção de modelos
que serão executados todos os meses foi obtido através de entrevistas com os
empregados da Inteligência de Clientes e pode ser observado na tabela 7 a seguir:
Tabela 7: Tempo Gasto para Geração de Amostras – Modelos Fixos. Modelo Prazo em Semanas
Cluster 4
Basket Analysis 4
Cross-Sell 4
Lifetime Value 4
Churn ? (Aprox. 4)
Recuperação ? (Aprox. 4)
O tempo gasto com a geração de amostras para a construção de modelos
que serão executados apenas uma única vez foi obtido através de entrevistas com
os empregados da Inteligência de Clientes e pode ser observado na tabela 8 a
seguir:
Tabela 8: Tempo Gasto para Geração de Amostras – Modelos Pontuais. Modelo Prazo em Semanas
Consignado 2
Pré-aprovado 2
Materiais de Construção 2
Conta Corrente 2
Letras Imobiliárias 2
Durante as participações na Unidade de Relacionamento foi realizada a
geração de três amostras, e foi confirmado o tempo de quatro semanas para
56
geração de cada uma para envio à consultoria externa. Foram geradas uma amostra
para o modelo de cross-sell e duas amostras para o modelo de lifetime value.
De acordo com as informações obtidas, também foi possível perceber que a
utilização do SAS como base de dados está causando gargalos nas atividades da
Unidade de Relacionamento.
Foi observado também que existem soluções internas de SGBDs disponíveis
para implantação imediata. Através de busca no “Caderno de Hardware e Software”,
na categoria SGBDs, foram encontrados as aplicações de software Oracle, SQL
Server e PostgreSQL, conforme pode ser observado na tabela 9 a seguir:
Tabela 9: Lista de SGBDs Disponíveis no Banco Pub (Fonte: Caderno de Hardware e Software).
Considerando-se os SGBDs disponíveis, observamos que o módulo
Repositório Central poderia utilizar a arquitetura relacional. Esta decisão não afetaria
as necessidades da Unidade de Relacionamento previstas inicialmente, pois as
informações gerenciais seriam fornecidas pelo CRM analítico.
A figura 7 a seguir mostra a infraestrutura planejada inicialmente pela Unidade
de Relacionamento, com a definição da arquitetura do Repositório Central como
arquitetura relacional:
57
Figura 7: Infraestrutura Inicialmente Planejada da Unidade de Relacionamento.
O CRM analítico seria uma base de dados gerencial e o Repositório Central
seria a base de dados analítica. Cada uma teria um propósito distinto, e por isso
teriam arquiteturas diferentes.
Outro problema que todos os empregados reconheceram foi que os
programas executados no ambiente do SAS não estão otimizados. Analisando-se a
metodologia aplicada na criação dos programas, percebeu-se que os mesmos foram
criados através de tentativa e erro, com o objetivo de validar os testes de uma
eventual hipótese.
Após validadas as hipóteses os programas não foram reescritos
considerando-se aspectos como tempo, esforço computacional ou espaço de
armazenamento. Por isso foram mantidos em produção todos os passos
intermediários de levantamento de hipóteses durante o desenvolvimento, como por
exemplo, a criação de variáveis e tabelas intermediárias, mas que poderiam ser
removidas do resultado final.
Além dos programas de processamentos de rotina internos, todos os
programas entregues pela consultoria externa, e que foram criados em amostra
58
pequenas, foram colocados em produção sem recodificação visando otimização, e
por isso demandam esforço extra durante a sua execução.
Porém para adaptá-los ao formato ideal após os mesmos estarem aplicados
nos dados de produção será preciso empregar muita atenção para se evitar a perda
de dados, e desta forma o esforço empregado seria muito grande.
Para minimizar este risco, é preciso criar um ambiente de desenvolvimento
separado, com menos dados, onde poderiam ser testadas muitas hipóteses mais
rapidamente, com mais qualidade e segurança. Este ambiente seria apenas uma
replicação do ambiente de produção em escala menor, com atualização de forma
automatizada.
O esforço empregado para otimizar os programas seria reduzido e o trabalho
seria mais simples, até que os mesmos alcancem uma qualidade aceitável para
execução em escala maior em produção.
Esta solução ainda permitiria maior controle dos processos rotineiros, pois
após um programa melhorado passar para outro ambiente, seriam criados artefatos
e planilhas de execução. Tudo isso traria maior segurança às atividades de rotina,
pois evitaria que rotinas importantes deixassem de ser executadas.
Uma vez garantidas todas as execuções essenciais, não ocorreriam atrasos
devido a alguma base não estar disponível e ao mesmo tempo ajudaria a padronizar
todas as bases do ambiente de produção.
Durante as participações na Unidade de Relacionamento, foi confirmada a
possibilidade de ganhos com a recodificação dos programas aplicados em produção
através de recodificação de alguns programas que estavam em produção. Os
programas reescritos foram os modelos de cluster, basket analysis, cross-sell e
lifetime value. Após serem recodificados, o tempo total de execução caiu de noventa
e seis horas para quatro horas.
A figura 8 a seguir mostra uma proposta de infraestrutura para a Unidade de
Relacionamento, com a inclusão de ambientes de desenvolvimento e produção, que
permitiria outras otimizações como a citada acima, porém minimizando o risco de
ocorrência de erros durante este processo:
59
Figura 8: Proposta Final da Infraestrutura da Unida de de Relacionamento.
Por último, nas entrevistas, todos os empregados apontaram uma grande
preocupação com a grande probabilidade da continuidade deste método de trabalho
por muito tempo, até que a base corporativa planejada no início do projeto fique
pronta, e permita a grande otimização do trabalho desejada pelos empregados.
Os seis empregados acreditam que o Repositório Central levará muito tempo
para ser debatido, especificado, desenvolvido, testado e implantado em sua versão
inicial. E depois haverá mais um tempo para correção de problemas novos ou
daqueles despercebidos anteriormente, e mais algum tempo para povoamento das
informações. Existe uma probabilidade alta de demora até que se torne efetivamente
a origem das amostras usadas na mineração de dados e na aplicação dos modelos
em produção.
Como ainda não existe um escopo definido, não é possível estimar com
precisão o prazo de entrega do mesmo, mas os empregados estimam que este
tempo possa variar de vinte e quatro a quarenta e oito meses. Porém mesmo
considerando-se o prazo mais otimista, todos consideram que é um tempo muito
60
longo para se manter o método de trabalho aplicado atualmente no desenvolvimento
de modelos.
Para piorar, como os mesmo estarão executando especificação de requisitos
dos módulos do CRM, mais as demandas pontuais e aprimoramentos dos modelos
de mineração de dados, existe uma grande probabilidade de sobrecarga e atrasos.
Alguns empregados chegaram a sugerir uma base temporária menor para
execução de algumas demandas, utilizando-se os mesmos SGBDs Oracle, SQL
Server ou PostgreSQL.
A captura dos dados seria feita através de VIEWS contendo filtros, o que iria
acelerar o acesso aos dados, pois os SGBDs modernos podem executar buscas
mais rapidamente que o SAS realizando acesso sequencial nas bases contendo
milhões de clientes.
Esta base de dados poderia teria rotinas automáticas e executaria rotinas
batch diversas, como cálculos de score na base de clientes, sob determinados
eventos, ou durante a carga, acelerando a geração de diversos dados, minimizando
os erros e melhorando a qualidade das informações.
O objetivo seria criar uma plataforma contingencial segura até que todos os
módulos do CRM sejam implantados, reduzindo o impacto de eventuais riscos de
atrasos nas entregas.
Esta base de contingência permitiria ainda o desenvolvimento paralelo da
ferramenta de BI. Após a entrega do Repositório Central, a coleta de dados pelo
SAS e pelo BI seriam apenas redirecionadas para o Repositório Central, e esta base
temporária poderia ser desativada sem grandes impactos.
A figura 9 a seguir mostra uma proposta temporária de infraestrutura para a
Unidade de Relacionamento, até que a ferramenta Epiphany seja implantada:
61
Figura 9: Proposta de Contingência da Unidade de Re lacionamento.
Em agosto de 2012, a consultoria realizou a entrega de quatro modelos que
foram desenvolvidos: Cluster, basket analysis, cross-sell e lifetime value.
O resultado do modelo de cluster pode ser observado na figura 10 a seguir:
62
Figura 10: Resultado do Modelo de Cluster (Fonte: Relatório de Entrega do Modelo de Cluster).
A validação do modelo de cluster se resumiu em verificar a quantidade ideal
de grupos, que poderia variar entre cinco e oito, de acordo com sugestões das
rotinas executadas na aplicação de software estatística SAS.
A quantidade de oito grupos sugeridos foi validada, considerando-se as
hipóteses iniciais. Porém os empregados perceberam que nos agrupamentos foram
consideradas apenas as variáveis renda, quantidade de contratos e tempo de
relacionamento.
O Banco Pub considerou que este modelo precisará de aprimoramentos muito
em breve, pois os empregados mais experientes acreditam que o volume de
negócios deveria ter entrado no modelo.
A consultoria afirmou que a variável foi descartada por decisões estatísticas
automáticas de rotinas do SAS, porém o Banco Pub ainda acredita que talvez o
modelo pudesse ser aprimorado através de alguma transformação da variável de
volume.
O modelo de basket analysis partiu inicialmente de dezesseis agrupamentos
de produtos e após análises estatísticas de correlações entre variáveis, foi possível
obter esta relação entre os produtos no tempo, e estas relações compuseram as
denominadas cestas estatísticas.
63
A figura 11 a seguir mostra o resultado inicial do modelo de basket analysis
entregue pela consultoria, também chamado de “cestas estatísticas”:
Figura 11: Cestas Estatísticas do Modelo de Basket Analysis (Fonte: Relatório de Entrega do Modelo de Basket Analysis).
Através das combinações das cestas estatísticas acima, levando-se em conta
as relações temporais existentes entre elas, chegou-se a quarenta e oito
combinações, denominadas “cestas de produtos”.
A partir deste resultado, foi verificado em qual das quarenta e oito cestas cada
cliente se encontra, de forma a atribuir apenas uma cesta de produto para cada
cliente, de acordo com a “melhor correspondência”.
Os resultados finais deste modelo são a vinculação entre cliente e cesta de
produtos, a sumarização da quantidade de cliente em cada uma das cestas, e o grau
de completude de cesta, ou seja, se o cliente possui todos os produtos da cesta em
que está vinculado.
Na figura 12 a seguir podemos ver a quantidade de clientes em cada cesta de
produtos:
64
Figura 12: Quantidade de Clientes em Cada Cesta - M odelo de Basket Analysis (Fonte: Relatório de Entrega do Modelo de Basket Analysis).
Na figura 13 a seguir podemos ver a porcentagem de clientes que possuem
todos os produtos da cesta, em cada cesta de produtos:
Figura 13: Clientes com Cestas Completas - Modelo d e Basket Analysis (Fonte: Relatório de Entrega do Modelo de Basket Analysis).
65
A partir destes indicadores, é possível trabalhar com cada cliente, buscando o
preenchimento de sua cesta com as ofertas faltantes, ou através de migração para
uma cesta maior.
Sobre este modelo, o Banco Pub considerou que este trabalho poderia ser
aprimorado, pois a quantidade de cestas de produtos foi considerada muito grande
para trabalho na rede de agências. O agrupamento de produtos utilizado no início
também não foi considerado perfeito, pois foi definido de forma arbitrária. Acredita-
se que este modelo pode ser aprimorado.
A metodologia utilizada foi através da comparação de novas aquisições ao
longo do tempo com a sua condição atual, e da construção de uma matriz de
transições utilizando-se conceitos de cadeias de Markov.
As tabelas 10 e 11 a seguir apresentam o resultado do modelo de cross-sell
entregue pela consultoria:
66
Tabela 10: Primeira Parte da Matriz de/ para do Modelo de Cross-Sell (Fonte: Relatório de Entrega do Modelo de Cross-Sell).
Pre
vid
ên
cia
0,0
6%
0,0
3%
0,0
4%
0,0
4%
0,2
7%
0,0
7%
0,0
4%
94
,75
%
0,1
1%
0,0
7%
0,0
7%
0,0
6%
0,0
7%
0,0
5%
0,0
5%
0,0
6%
Po
up
an
ça 0,1
9%
0,1
9%
0,1
7%
0,2
9%
0,5
9%
4,1
2%
96
,15
%
0,3
4%
0,5
7%
0,2
8%
0,1
1%
0,2
7%
0,2
7%
0,2
1%
0,2
9%
0,3
2%
De
ma
is
Pro
du
tos 0
,54
%
0,2
8%
0,3
6%
0,0
4%
4,8
3%
85
,06
%
0,3
8%
0,3
7%
0,0
1%
0,4
5%
0,1
9%
0,7
1%
0,5
4%
0,1
6%
0,8
4%
0,8
2%
Tít
ulo
s
Imo
bil
iári
os
0,0
0%
0,0
0%
0,0
1%
0,0
0%
91
,92
%
0,0
0%
0,0
0%
0,0
1%
0,0
0%
0,0
1%
0,0
0%
0,0
1%
0,0
1%
0,1
1%
0,0
0%
0,0
0%
Cre
dit
o
Imo
bil
iari
o
0,2
7%
0,0
7%
0,0
4%
93
,95
%
0,0
0%
0,4
2%
0,1
3%
0,3
9%
0,1
9%
0,3
8%
0,0
6%
0,3
3%
0,3
6%
0,0
2%
0,1
8%
0,8
5%
Co
nsi
gn
aca
o
0,2
6%
0,3
4%
94
,38
%
0,1
0%
0,0
0%
0,2
7%
0,1
8%
0,0
5%
0,2
1%
0,2
5%
0,0
8%
0,2
1%
0,1
8%
0,1
3%
0,1
8%
0,2
5%
Cré
dit
o
Pré
-ap
rov
ad
o
0,2
3%
91
,57
%
0,2
2%
0,1
3%
0,3
3%
0,0
7%
0,1
5%
0,0
9%
0,5
5%
0,4
1%
0,3
0%
0,2
6%
0,3
3%
0,0
8%
0,3
0%
0,2
3%
Ca
pit
ali
zaca
o
94
,51
%
0,7
3%
0,6
0%
0,3
7%
0,0
0%
0,9
2%
0,3
7%
0,5
1%
1,1
2%
0,5
5%
0,4
2%
0,4
7%
0,5
2%
0,2
3%
0,3
9%
0,6
1%
De
\Pa
ra
Ca
pit
ali
zaca
o
Cré
dit
o
Pré
-ap
rov
ad
o
Co
nsi
gn
aca
o
Cre
dit
o
Imo
bil
iari
o
Tít
ulo
s
Imo
bil
iári
os
De
ma
is
Pro
du
tos
Po
up
an
ça
Pre
vid
ên
cia
Dé
bit
o
Au
tom
áti
co
Ca
rtã
o d
e
Cré
dit
o
Co
nsó
rcio
Co
nta
Co
rre
nte
Ch
eq
ue
Esp
eci
al
Fu
nd
os
RF
x e
RV
r
Ou
tro
s E
mp
r/
Fin
an
c
Se
gu
ros
67
Tabela 11: Segunda Parte da Matriz de/ para do Modelo de Cross-Sell (Fonte: Relatório de Entrega do Modelo de Cross-Sell).
Se
gu
ros
0,6
3%
0,8
9%
1,1
3%
0,5
7%
0,0
0%
1,1
8%
0,3
6%
0,5
4%
1,6
8%
0,9
4%
0,5
1%
0,7
3%
0,8
7%
0,2
6%
1,0
5%
91
,10
%
Ou
tro
s E
mp
r/
Fin
an
c
0,1
3%
0,3
0%
0,1
5%
0,1
5%
0,0
0%
0,6
3%
0,1
1%
0,2
0%
0,3
9%
0,2
4%
0,1
9%
0,1
9%
0,2
0%
0,0
2%
90
,38
%
0,2
0%
Fu
nd
os
RF
x e
RV
r
0,0
5%
0,0
0%
0,0
2%
0,0
2%
0,6
9%
0,0
0%
0,0
2%
0,1
1%
0,0
5%
0,0
3%
0,0
3%
0,0
5%
0,0
5%
97
,52
%
0,0
2%
0,0
2%
Ch
eq
ue
Esp
eci
al
0,1
9%
0,1
7%
0,2
0%
0,3
6%
0,3
3%
1,3
3%
0,2
1%
0,1
6%
0,3
2%
0,4
3%
0,2
7%
0,4
5%
92
,59
%
0,0
3%
0,7
1%
0,4
0%
Co
nta
Co
rre
nte
0,1
4%
0,1
2%
0,1
7%
0,3
0%
0,0
0%
4,1
8%
0,2
5%
0,1
6%
0,3
4%
0,2
7%
0,2
8%
92
,92
%
0,0
0%
0,0
0%
0,4
8%
0,2
3%
Co
nsó
rcio
0,0
1%
0,0
1%
0,0
0%
0,0
0%
0,0
0%
0,0
1%
0,0
0%
0,0
1%
0,0
1%
0,0
0%
95
,11
%
0,0
0%
0,0
0%
0,0
3%
0,0
0%
0,0
0%
Ca
rtã
o d
e
Cré
dit
o
0,5
3%
0,5
3%
0,5
3%
0,6
2%
0,6
7%
1,7
3%
0,3
8%
0,4
1%
1,4
3%
92
,52
%
0,5
5%
0,6
9%
0,7
1%
0,2
7%
0,6
4%
0,5
9%
Dé
bit
o
Au
tom
áti
co
2,2
6%
4,7
6%
1,9
8%
3,0
7%
0,3
6%
0,0
2%
1,2
7%
1,9
2%
93
,02
%
3,2
0%
1,8
1%
2,6
7%
3,3
0%
0,8
8%
4,4
9%
4,3
2%
De
\Pa
ra
Ca
pit
ali
zaca
o
Cré
dit
o
Pré
-ap
rov
ad
o
Co
nsi
gn
aca
o
Cre
dit
o
Imo
bil
iari
o
Tít
ulo
s
Imo
bil
iári
os
De
ma
is
Pro
du
tos
Po
up
an
ça
Pre
vid
ên
cia
Dé
bit
o
Au
tom
áti
co
Ca
rtã
o d
e
Cré
dit
o
Co
nsó
rcio
Co
nta
Co
rre
nte
Ch
eq
ue
Esp
eci
al
Fu
nd
os
RF
x e
RV
r
Ou
tro
s E
mp
r/
Fin
an
c
Se
gu
ros
68
A leitura destas tabelas ocorre da linha para a coluna, por exemplo, um cliente
que possui capitalização, tem 2,26% de probabilidade de adquirir o débito
automático. Caso o cliente possua mais de um produto, toma-se o maior valor. Por
exemplo, um cliente que possui capitalização e crédito pré-aprovado, tem 4,76% de
probabilidade de adquirir o débito automático.
Após a validação do modelo em toda a base, foi percebido que para
aproximadamente setenta por cento dos clientes, o modelo acerta a compra de pelo
menos um dos três primeiros produtos indicados. E na maioria dos casos, acerta
dois produtos entre três indicados. O resultado foi considerado bom pelo Banco Pub,
porém, foi considerado que esta taxa de acerto pode ser melhorada.
Porém devido à proximidade do final do contrato, foi entregue somente a
tentativa de prever o tempo de permanência do cliente com determinado produto.
Este valor seria então combinado com a rentabilidade atual já calculada por
outra unidade do Banco Pub para prever a rentabilidade estatística de cada cliente,
e a rentabilidade potencial ficaria para uma oportunidade posterior.
O resultado deste modelo são dezessete tabelas contendo as curvas de
sobrevivência dos dezesseis grupos de produtos iniciais, mais uma curva
característica de sobrevivência de clientes em geral.
A figura 14 a seguir mostra o resultado do modelo para o produto Título de
Capitalização. É possível perceber claramente o abandono massivo de clientes em
12, 24, 36 e 60 meses, que são os prazos mais comuns de contratação:
69
Figura 14: Curva de Sobrevivência do Produto “Títul o de Capitalização” (Fonte: Relatório de Entrega do Modelo de Lifetime Value).
Para cada grupo de produto, foram calculadas várias curvas de sobrevivência.
Na aplicação do modelo, utilizam-se características dos clientes e de seus contratos
para encontrar sua curva correspondente para aquele produto, e obtém-se a sua
probabilidade de permanência com o produto ao longo do tempo.
Após a validação do modelo, percebeu-se que cinco grupos de produtos não
estavam representando as características de permanência dos clientes, e
precisariam ser recalculadas.
Percebeu-se então, que os modelos de cluster e de basket analysis precisam
ser refeitos, por critérios negociais, e os modelos de cross-sell e lifetime value
precisam ser aprimorados, portanto percebemos que haverá necessidade de se
refazer todos os passos, como geração de amostras, desenvolvimento, validação e
teste.
Os empregados da Unidade de Relacionamento que executaram as tarefas
de validação das entregas foram questionados sobre esta tarefa, e eles ressaltaram
que para cada modelo validado é preciso construir uma base e um programa
diferente.
70
Este processo está sujeito a erros e retrabalho, e por consequência, para
cada submissão do programa, é preciso esperar horas para o processamento da
base completa, que contém dezenas de milhões de clientes, o que foi considerado
longo e cansativo pelos empregados.
Todo este esforço foi considerado excessivo pelos empregados, uma vez que
alguns modelos deveriam ser descartados ou refeitos.
Os empregados reconhecem que houve benefício com todo este esforço, que
foi a não confirmação de algumas hipóteses. Porém como o esforço nem sempre
produziu resultado aproveitável, todos consideraram que deveria haver um método
mais eficiente para esta atividade, e que o esforço deveria ser empregado em
atividades mais produtivas.
71
5 Discussão
Para minimizar os problemas descobertos neste estudo, poderiam ser
realizadas algumas mudanças nas ferramentas da Unidade de Relacionamento.
A primeira sugestão seria a adoção de um sistema de BI, para que os
relatórios rotineiros e os levantamentos pontuais fossem criados rapidamente sem
necessidade de desenvolvimento. Temos então como consequência que o módulo
CRM analítico poderia ser implantado na arquitetura multidimensional.
Uma vez que existe capacidade tecnológica na organização para implantação
de BI capaz de minimizar este problema, temos como primeiro resultado a
confirmação da primeira hipótese, e portanto as demandas pontuais geram atrasos
que poderiam ser evitados.
Uma vez que as necessidades de informações pontuais sumarizadas seriam
atendidas, temos como consequência a segunda proposta, que é a definição da
arquitetura do módulo Repositório Central como relacional, e não multidimensional,
já que seu objetivo é diferente do objetivo de um sistema de BI.
Uma vez que este problema pode ser minimizado com mudanças na
infraestrutura tecnológica da organização com soluções já existentes internamente,
temos como resultado a confirmação da segunda hipótese e, portanto a utilização do
SAS como SGBD causa atrasos excessivos no processamento.
Temos como terceira sugestão a separação de ambientes no servidor SunOS,
criando-se um ambiente para criação, e outro ambiente para a execução dos
modelos. Após a validação do teste de conceito, os programas seriam reescritos
antes de serem enviados para o ambiente de produção.
Este ambiente possibilitaria também a otimização de programas já
executados atualmente em produção, sem grandes impactos.
72
Uma vez que existe alguma solução disponível na empresa para reduzir o
esforço computacional e aumentar a confiabilidade dos programas, então temos
como resultado a confirmação da terceira hipótese e, portanto os erros de
processamento podem ser minimizados.
Para reduzirmos o tempo e esforço de geração de cada amostra de
modelagem estatística, temos como última sugestão a criação de uma instância
SGBD relacional para armazenar os dados do Database Marketing até que o
Repositório Central fique pronto, visando melhorar a performance da aplicação de
software SAS em caráter emergencial.
Uma vez que este risco pode ser mitigado através de soluções já existentes
internamente, temos como resultado a confirmação da quarta hipótese e, portanto
minimizaremos eventuais problemas causados por atrasos na implantação do
Epiphany.
Estas mudanças permitiriam que eventuais necessidades de repetição no
desenvolvimentos dos modelos pudessem ser realizadas várias vezes sem grandes
esforço.
Portanto confirmamos a última hipótese, e mudanças adequadas na
infraestrutura serão um investimento, que trará redução do tempo total.
73
6 Conclusões e Trabalhos Futuros
6.1 Limitações Encontradas Durante a realização deste trabalho, um dos grandes limitadores foi o grau de
sigilo das informações. Muitas das ações de CRM no Banco Pub estão ligadas ao
planejamento estratégico e, portanto, as informações possuem restrições de
divulgação. Esta limitação foi contornada através da reconstrução de figuras e
informações importantes, e naquelas onde isto não foi possível, através da
manutenção do sigilo da fonte.
Outra limitação encontrada foi o baixo controle das rotinas de TI executadas
pelo Banco Pub.
A maioria destas rotinas era executada várias vezes sem critérios específicos.
Muitas vezes as rotinas não estavam devidamente programadas, e, durante a
execução, ou havia erros no ambiente ou eram inseridos erros pelo usuário. Ainda,
quase todas as rotinas eram executadas sem o registro de início e de fim.
Para contornar esta limitação, o método preferido para a coleta foi a
realização de entrevistas com os empregados.
Este método foi confiável para aferição do tempo médio das rotinas, já que
devido ao excesso de execuções pelos empregados, existe uma familiaridade
quanto à expectativa de sua finalização. Porém para detalhamento das causas de
erros e possíveis melhorias foram necessárias investigações adicionais mais
trabalhosas.
6.2 Conclusões
Durante a execução das atividades de CRM, o simples foco no atendimento
de prazos tende a evoluir para uma sobrecarga operacional.
74
Analisando-se a situação, percebe-se que normalmente ocorre uma relação
desproporcional entre causa e efeito, que neste caso se traduz entre esforço
aplicado versus resultado obtido.
Através de pequeno esforço com a implantação de ferramentas simples, será
possível aumentar muito a produtividade e obter o alinhamento da TI com a
estratégia de negócio.
Adotando-se um sistema de BI reduz-se muito a necessidade de execução de
rotinas manuais, pois os consumidores de informações ficam atendidos pela
ferramenta sem a necessidade de esforço em desenvolvimento de relatórios.
Uma vez implantado o BI, todas as bases de dados com o perfil dos clientes
podem ser simples repositórios de dados analíticos, simplificando a etapa de
planejamento e permitindo a implantação mais rápida.
Com a separação de ambientes de desenvolvimento e produção, será
possível automatizar rotinas periódicas e programas entregues, aliviando a
sobrecarga causada pela execução de rotinas demoradas ou tratando erros de
processamento.
A criação de uma base temporária de perfil dos clientes, com escopo menor e
entrega mais rápida, permitirá o atendimento de diversas demandas, reduzindo a
pressão pela entrega da base de dados completa desenhada originalmente.
Sem estas pressões, será possível estender o prazo de entrega da base
completa, empregar maior atenção no seu planejamento e implantação, e para
eventuais erros cometidos, será possível alocar tempo adequado para seu
tratamento, melhorando a qualidade final.
Todas estas ferramentas permitirão que o Banco Pub atinja o estágio de
sabedoria de clientes e consiga construir relacionamentos duradouros e lucrativos
com seus clientes.
Com este estudo, atingimos os objetivos específicos deste trabalho, pois
confirmamos que o nível baixo de maturidade na gestão da infraestrutura
tecnológica influenciou negativamente na agilidade de desenvolvimento dos modelos
estatísticos preditivos do Banco Pub, e confirmamos que lá já havia outras
ferramentas disponíveis capazes de minimizar os problemas existentes.
E também atingimos o objetivo geral deste trabalho, pois confirmamos que a
ausência de gestão de processos de TI causa um grande impacto negativo nos
processos de mineração de dados de CRM.
75
6.3 Trabalhos Futuros Como este estudo teve seu foco em verificar os gargalos na infraestrutura que
poderiam ser eliminados com soluções existentes na organização, outras
necessidades e problemas existentes não foram observados. Por isso ainda há
muita oportunidade para novos estudos e melhorias. Por exemplo, outro grande
problema apontado nas reuniões, que não fez parte deste estudo e que também
pode ser observado no relatório da consultoria externa é a falta de planejamento
com a modelagem das bases de dados.
Algumas amostras acabam por demorar mais que o tempo ideal devido à
complexidade de se montá-las manualmente durante as etapas de seleção de
variáveis e de seleção de registros para estudo de hipóteses.
Outro grande problema deste processo é a nomeação das variáveis, pois
como algumas variáveis são mensais, na amostra final é preciso adicionar sufixos
indicando o mês em que foram observadas. O problema costuma aparecer porque
muitas variáveis de uso consagrado já possuem nomes extensos e o SAS não
permite nomes de variáveis com mais de trinta e dois caracteres. Nestes casos, o
programador é forçado a criar um novo termo e a preparar um dicionário informando
estas alterações, para que todos se adaptem ao novo nome.
Outro trabalho indicado para estudos futuros seria a quantificação do
benefício que poderia ser obtido através da otimização de vários programas
executados rotineiramente. Como nunca houve dois ambientes, um de
desenvolvimento e outro de produção, com recodificação das rotinas após a
validação, temos muitos programas que não estão otimizados.
Foi realizado um pequeno teste e dois programas reescritos tiveram redução
de metade do tempo de execução, e talvez este benefício pudesse ser estendido a
mais rotinas.
Mas é preciso efetuar mais análises, enumerando as rotinas não otimizadas e
seu tempo de execução, já que existe a possibilidade do ganho não ser tão grande.
Outro risco que precisa ser avaliado é o aumento de complexidade que estas
otimizações trazem aos códigos reescritos. Os programas otimizados costumam
ficar incompreensíveis para usuários iniciantes, e exigem uma documentação mais
detalhada.
76
Então, neste estudo seria necessário confrontar os custos de programação e
documentação contra os custos de processamento e manutenção para avaliar quais
seriam os ganhos e as perdas reais, e ainda seria preciso levar esta decisão ao nível
hierárquico superior para avaliar se este eventual ganho estaria entre as prioridades
da Unidade de Relacionamento.
6.4 Conquistas Alcançadas Algumas conquistas foram alcançadas com este trabalho, no Banco Pub e
para o autor deste estudo.
O Banco Pub decidiu recentemente adotar a infraestrutura de contingência
recomendada neste estudo. A base de contingência citada foi implantada, mas ainda
não foi povoada e não está em uso atualmente. A expectativa é que esta base possa
trazer muitos benefícios em curto prazo até que o Repositório Central fique pronto.
O Banco Pub também decidiu adotar a arquitetura multidimensional para o
CRM Analítico e relacional para o Repositório Central. Esta decisão foi tomada após
vários debates entre os empregados, e estes debates foram fomentados pela
realização deste estudo. O Banco Pub decidiu de vez abandonar a ideia inicial para
este módulo, que consistia em uma coleção de relatórios.
Já para o autor deste trabalho, houve grande aprendizado através da
realização do curso, em todas as áreas da gestão de TI, com por exemplo, os
arcabouços de governança de TI, gerenciamento de projetos e planejamento
estratégico.
Entre todas as disciplinas aproveitadas, cabe destacar a disciplina de Análise
de Cenários, que apresentou um conteúdo totalmente novo, e também pouco
explorado no Banco Pub.
Outro grande avanço para o autor, foi o aprendizado do método científico
utilizado neste trabalho, conforme organização citada no item 1.9, restringindo
claramente os tópicos em estudo bibliográfico, explicação do método de coleta,
apresentação dos dados sem análise, análise dos resultados, e apresentação dos
problemas, e, conquistas atingidas e futuras.
Esta metodologia será utilizada futuramente para todos os trabalhos
científicos posteriores, por permitir um trabalho completo sem apresentar repetição,
pois não ocorre sobreposição de assuntos em cada um dos tópicos.
77
Referências e Fontes Consultadas
BRETZKE, M. Marketing de relacionamento e competição em tempo real com CRM
(Customer relationship management). São Paulo: Atlas, 2000. 224 p. ISBN 85-
224-2478-0.
BROWN, S. A. CRM – Customer Relationship Management. São Paulo: Makron
Books, 2001. 331 p. ISBN 85-346-1220-X.
GREENBERG, P. CRM, customer relationship management na velocidade da luz:
conquista e lealdade de clientes em tempo real na internet. Rio de Janeiro:
Campus, 2001. 409 p. ISBN 85-352-0818-6.
KOTLER, P.; ARMSTRONG, G. Princípios de Marketing. 12. ed. São Paulo: Pearson
Prentice Hall, 2007. 600 p. ISBN 978-85-7605-123-7.
KOTLER, P. Marketing 3.0: as forças que estão definindo o novo marketing centrado
no ser humano. Rio de Janeiro: Elsevier, 2010. 215 p. ISBN 978-85-352-3869-
3.
LIMA, P. D. B. Excelência em gestão pública: a trajetória e a estratégia do
gespública. Rio de Janeiro: Qualitymark, 2007. 227 p. ISBN 85-73037-35-0.
OLIVEIRA, W. J. CRM & e-business. Florianópolis: Visual Books, 2000. 154p. ISBN
85-85943-97-1.
PEPPERS, D.;ROGERS, M. Empresa 1:1: instrumentos para competir na era da
interatividade. Rio de Janeiro: Campus, 1997. 381 p. ISBN 85-352-0202-1.
QUADROS, M. CRM: teoria, prática e ferramentas. Florianópolis: Visual Books,
2010. 320 p. ISBN 978-85-7502-265-8.
STONE, M.; WOODCOCK, I.; MACHTYNGER, L. CRM – Marketing de
relacionamento com os clientes. São Paulo: Futura, 2001. 273 p. ISBN 85-
7413-065-6.
78
SWIFT, R. CRM, customer relationship management: o revolucionário marketing de
relacionamento com o cliente. Rio de Janeiro: Campus, 2001. 493 p. ISBN 85-
352-0812-7.
ZENONE, L. C. (Coordenador) Customer Relationship Management (CRM)
conceitos e estratégias: mudando a estratégia sem comprometer o negócio.
São Paulo: Atlas, 2001. 156 p. ISBN 85-224-2895-6.
79
Lista de Siglas
BI Business Intelligence
CA IDMS Computer Associates Integrated Database Management System
CDB Certificado de Depósito Bancário
CDU Classificação Decimal Universal
CEGTI Curso de Especialização em Gestão de Tecnologia da Informação
CEO Chief Executive Officer
CRM Customer Relationship Marketing
D + n Após ‘n’ Dias Corridos
DF Distrito Federal
DW Data Warehouse
E.M.A. Enterprise Marketing Automation
e-CRM Electronic CRM
ETL Extract, Transform and Load
HW Hardware
IA Interaction Advisor
ISBN International Standard Book Number
MS Microsoft
ODBC Open Data Base Connectivity
OM Outbound Marketing
OS Operating System
PhD Doctor of Philosophy
ROI Return over Investment
S.F.A. Sales Forces Automation
SAS Statistical Analysis System
SGBD Sistema Gerenciador de Banco de Dados
SPARC Scalable Processor Architecture
SQL Structured Query Language
SS Sales and Service
TI Tecnologia da Informação
TDS Tabular Data Stream
UnB Universidade de Brasília