Implantação de Processos de Gestão de Relacionamento com o Cliente - CRM em Instituição Bancária

July 5, 2017 | Autor: Romualdo PereiraJr | Categoria: Customer Relationship Management (CRM)
Share Embed


Descrição do Produto

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

Dedicatória

Dedico este trabalho ao meu amor, Mariana.

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 clienteservidor. 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 Demandas 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 tornase 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: quantidades

de

Técnica dados

utilizada a

para

resumos

reduzir

significativos

grandes 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 Redes Neurais

Regressão

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:

40

Figura 3: Mapa conceitual da metodologia utilizada.

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:

Dados muito desatualizados (D + 60) e possivelmente inconsistentes para a execução de modelos preditivos; dados de segmentação estão em D+120 Às vezes é difícil saber onde estão alguns campos na estrutura de dados atual, o que gera demoras no processo Processo de extração e preparação de dados para modelagem, bem como processo de execução dos modelos, levam tempo demasiado

QUALIDADE

Há muitos processos semi-manuais na preparação de dados

Problemas no ambiente interrompem processamento, que precisa ser reiniciado; Processos demorados são executados nas estações de trabalho, o que gera maior probabilidade de interrupção e reinício

Ainda não recebi algumas informações sobre a arquitetura de hardware e rede, aparentemente não há esquema de failover de componentes principais e o hardware pode ser em parte responsável por lentidão no processamento

Não existem ambientes separados de desenvolvimento, testes e produção, especialmente para rotinas de carga e transformação de dados, gerando ineficiências nas atividades

AGILIDADE

DISPONIBILIDADE

PERFORMANCE

PRODUTIVIDADE

PERFORMANCE

AGILIDADE

Sumário de Constatações

Categoria

Média

???

Média

Média

Alta

Média

Alta

Gravi dade

Executar o que for possível no servidor; diagnosticar causas de interrupções

Automatizar alguns processos uma vez que formatos de arquivos se estabilizem (há também o mesmo issue na unidade que lhes envia os dados.)

* Monitorar todos os componentes de solução (memória, CPU, disco, rede, etc) para identificar gargalos de performance e soluções adequadas * Documentar sequência completa de processamentos de datasets SAS e identificar quais demoram mais (especialmente TRANS_FINAL2, CARTÕES_FINAL e BASE_FINAL) * Tomar ações corretivas adequadas a gargalos identificados - aumentar memória, reestruturar arquivos, redesenhar processamento, otimizar rede, etc * Aumentar tamanho do disco atual reservado para a área de Inteligência de Clientes

Recomendações de Curto Prazo

Criar ambientes separados de desenvolvimento, testes integrados e produção; educar a área usuária em como utilizar esses ambientes

Se detectado que o hardware é inadquado para os volumes de processamento, identificar e adquirir hardware adequado para o ambiente SAS de maneira a executar os batches de carga / transformação de dados bem como a execução dos modelos em um tempo reduzido e permitir forecasts adequados para um horizonte de 3 meses (considerar plataformas especializadas, como Exadata, Teradata e Neteeza); Investigar a possibilidade de a aplicação SAS suportar processamento paralelo; Implementar esquema de failover de maneira a garantir disponibilidade adequada

Rever arquitetura de software para ser possível executar todos os processos de base full no servidor

Identificar requisitos e modelar repositório central com todas as informações necessárias e arquitetura de extração e transformação de dados de maneira a: -Ter boa performance na carga de dados de sistemas fontes e execução das transformações necessárias -Ter boa performance na execução de modelos -Guardar dados com a granularidade e histórico necessários -Garantir qualidade e integridade dos dados -Ter dados atualizados para análise Identificar tecnologia de banco de dados adequada para implementar esse novo repositório

Recomendações de Maior Prazo

44

Tabela 4: Lista de Problemas Identificados (Fonte: Relatório de Consultoria Externa).

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 (Fonte: 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 Identificados (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 Solucionar 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 SAP BUSINESS

BUSINESS OBJECTS

6.5.1

OBJECT SAP BUSINESS

BUSINESS OBJECTS CLIENT

XI R2

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 Aplicação Aplicação Aplicação Aplicação Cadastro Cadastro Canal Canal Canal Canal Captação Captação Captação Fidelização Fidelização Outros Serviço Serviço Serviço Serviço Serviço Serviço Serviço

Bloco Cartões de Crédito Crédito Imobiliário Crédito Rotativo Empréstimos Cadastro de Clientes Entidades do Governo Internet Banking Agências (Caixas) Central de Atendimento Terminais de Auto-atendimento (salas, Correspondentes Bancários e banco 24hs) Aplicações Financeiras Depósitos Poupança Consórcio Seguros, Capitalização e Previdência Risco de Crédito Cartões de Débito e Cheque eletrônico Cesta de Serviços Convênios Débito Automático Geo-análises Credenciamento 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 contasalá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 Cluster Basket Analysis Cross-Sell Lifetime Value Churn Recuperação

Prazo em Semanas 4 4 4 4 ? (Aprox. 4) ? (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 Unidade 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 Relacionamento.

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 - Modelo 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 de 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. Acreditase 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:

Conta Corrente Cheque Especial Fundos RFx e RVr Outros Empr/ Financ Seguros

Débito Automático Cartão de Crédito Consórcio

Previdência

Credito Imobiliario Títulos Imobiliários Demais Produtos Poupança

Crédito Pré-aprovado Consignacao

Capitalizacao

De\Para

0,18%

0,15%

0,37%

0,21% 0,18% 0,13% 0,18% 0,25%

0,33% 0,08% 0,30% 0,23%

0,52%

0,23%

0,39%

0,61%

0,08%

0,30%

0,42% 0,26%

0,25%

0,41%

0,55%

0,47%

0,21%

0,55%

1,12%

0,05%

0,27%

0,07%

0,92%

0,09%

0,00%

0,33%

0,00%

0,51%

0,10%

0,13%

94,38%

0,22%

0,60%

0,37%

0,34%

0,26%

Consignacao

91,57%

0,23%

Crédito Pré-aprovado

0,73%

94,51%

Capitalizacao

0,85%

0,18%

0,02%

0,36%

0,33%

0,06%

0,38%

0,19%

0,39%

0,13%

0,42%

0,00%

93,95%

0,04%

0,07%

0,27%

Credito Imobiliario

0,00%

0,00%

0,11%

0,01%

0,01%

0,00%

0,01%

0,00%

0,01%

0,00%

0,00%

91,92%

0,00%

0,01%

0,00%

0,00%

Títulos Imobiliários

0,82%

0,84%

0,16%

0,54%

0,71%

0,19%

0,45%

0,01%

0,37%

0,38%

85,06%

4,83%

0,04%

0,36%

0,28%

0,54%

Demais Produtos

0,32%

0,29%

0,21%

0,27%

0,27%

0,11%

0,28%

0,57%

0,34%

96,15%

4,12%

0,59%

0,29%

0,17%

0,19%

0,19%

Poupança

0,06%

0,05%

0,05%

0,07%

0,06%

0,07%

0,07%

0,11%

94,75%

0,04%

0,07%

0,27%

0,04%

0,04%

0,03%

0,06%

Previdência

66

Tabela 10: Primeira Parte da Matriz de/ para do Modelo de Cross-Sell (Fonte: Relatório de Entrega do Modelo de Cross-Sell).

Conta Corrente Cheque Especial Fundos RFx e RVr Outros Empr/ Financ Seguros

Débito Automático Cartão de Crédito Consórcio

Previdência

Credito Imobiliario Títulos Imobiliários Demais Produtos Poupança

Crédito Pré-aprovado Consignacao

Capitalizacao

De\Para

1,73% 0,38%

0,02%

1,27%

0,71% 0,27% 0,64% 0,59%

3,30%

0,88%

4,49%

4,32%

0,55%

1,81% 0,69%

92,52%

3,20%

2,67%

1,43%

93,02%

0,41%

0,67%

0,36%

1,92%

0,62%

0,53%

1,98%

3,07%

0,53%

0,53%

Cartão de Crédito

4,76%

2,26%

Débito Automático

0,00%

0,00%

0,03%

0,00%

0,00%

95,11%

0,00%

0,01%

0,01%

0,00%

0,01%

0,00%

0,00%

0,00%

0,01%

0,01%

Consórcio

0,28%

0,27%

0,34%

0,16%

0,25%

4,18%

0,00%

0,30%

0,17%

0,12%

0,14%

0,23%

0,48%

0,00%

0,00%

92,92%

Conta Corrente

0,45%

0,27%

0,43%

0,32%

0,16%

0,21%

1,33%

0,33%

0,36%

0,20%

0,17%

0,19%

0,40%

0,71%

0,03%

92,59%

Cheque Especial

0,02%

0,02%

97,52%

0,05%

0,05%

0,03%

0,03%

0,05%

0,11%

0,02%

0,00%

0,69%

0,02%

0,02%

0,00%

0,05%

Fundos RFx e RVr

0,20%

90,38%

0,02%

0,20%

0,19%

0,19%

0,24%

0,39%

0,20%

0,11%

0,63%

0,00%

0,15%

0,15%

0,30%

0,13%

Outros Empr/ Financ

1,05%

0,26%

0,87%

0,73%

0,51%

0,94%

1,68%

0,54%

0,36%

1,18%

0,00%

0,57%

1,13%

0,89%

0,63%

91,10%

Seguros

67

Tabela 11: Segunda Parte da Matriz de/ para do Modelo de Cross-Sell (Fonte: Relatório de Entrega do Modelo de Cross-Sell).

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ítulo 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 85224-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-38693. 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 857413-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 85352-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

80

WS

Workstation

Lihat lebih banyak...

Comentários

Copyright © 2017 DADOSPDF Inc.