Embed Size (px)
Citation preview
Sistema de Relacionamento com Clientes para Restaurantes
Utilizando Arquitetura Cliente-Servidor
Pedro Gabriel Lancelloti Pinto
Projeto de Graduacao apresentado ao Curso
de Engenharia Eletronica e de Computacao
da Escola Politecnica, Universidade Federal
do Rio de Janeiro, como parte dos requisitos
necessarios a obtencao do tıtulo de Enge-
nheiro.
Orientador: Flavio Luis de Mello
Rio de Janeiro
Agosto de 2017
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
Escola Politecnica - Departamento de Eletronica e de Computacao
Centro de Tecnologia, bloco H, sala H-217, Cidade Universitaria
Rio de Janeiro - RJ CEP 21949-900
Este exemplar e de propriedade da Universidade Federal do Rio de Janeiro, que
podera incluı-lo em base de dados, armazenar em computador, microfilmar ou adotar
qualquer forma de arquivamento.
E permitida a mencao, reproducao parcial ou integral e a transmissao entre bibli-
otecas deste trabalho, sem modificacao de seu texto, em qualquer meio que esteja
ou venha a ser fixado, para pesquisa academica, comentarios e citacoes, desde que
sem finalidade comercial e que seja feita a referencia bibliografica completa.
Os conceitos expressos neste trabalho sao de responsabilidade do(s) autor(es).
iv
AGRADECIMENTO
Gostaria de agradecer a todos aqueles que me apoiaram durante esse difıcil trajeto
que foi a graduacao na Universidade Federal do Rio de Janeiro. Primeiramente, nao
posso esquecer de meus familiares,em especial aos meus pais que sempre estiveram
ao meu lado durante todos os desafios, independente dos resultados finais. Alem
da famılia, agradeco aqui aos meus amigos que sempre me motivaram e estiveram
dispostos a me ajudar a levantar das quedas pelo caminho. Por fim, a todos os meus
professores que se dedicaram ao magisterio mesmo que num paıs onde o ensino e tao
pouco valorizado.
v
RESUMO
Este trabalho busca solucionar um problema de identificacao da base de clientes
em uma rede de hamburguerias do Rio de Janeiro e melhorar sua relacao com esses
clientes. Para isso, a solucao adotada foi a criacao de um sistema CRM (Customer
Relationship Management) desde a modelagem da base de dados, Backend para
o processamento e acesso aos dados ate a construcao de uma aplicacao Android
para auxiliar os funcionarios da rede durante os atendimentos. Como resultado da
implementacao do projeto a empresa conseguiu identificar melhor seus clientes e
seus habitos de consumo podendo oferecer um atendimento personalizado.
Palavras-Chave: CRM, Android, Restaurantes.
vi
ABSTRACT
This work seeks to solve a problem of identification of the customer base in a
network of hamburgers in Rio de Janeiro and improve their relationship with these
clients. For this, the solution adopted was the creation of a CRM system from
the modeling of the database, Backend for processing and access to the data until
the construction of an Android application to help the employees of the network
during the calls.As a result of the implementation of the project, the company was
able to better identify its customers and their consumption habits and can o↵er a
personalized service.
Key-words: CRM, Android, Restaurants.
vii
SIGLAS
API - Application Programming Interface
AWS - Amazon Web Service
CRM - Customer Relationship Menagement
HTML - Hypertext Markup Language
HTTP - Hypertext Transfer Protocol
IDE - Integrated Development Environment
JSON - JavaScript Object Notation
UFRJ - Universidade Federal do Rio de Janeiro
viii
Sumario
1 Introducao 1
1.1 Tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Delimitacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6 Descricao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Fundamentacao Teorica 5
2.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Customer Relationship Management . . . . . . . . . . . . . . . . . . 5
2.3 Processos do CRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 CRM Aplicado em Restaurantes . . . . . . . . . . . . . . . . . . . . . 11
3 Implementacao 14
3.1 Descricao do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Arquitetura da Solucao . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Extrator de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6 Aplicacao Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7 Analise de Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4 Conclusoes 52
4.1 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
ix
Bibliografia 56
x
Lista de Figuras
2.1 Representacao do Sistema CRM por [1] . . . . . . . . . . . . . . . . . 8
2.2 Representacao do Sistema CRM por [2] . . . . . . . . . . . . . . . . . 9
3.1 Representacao Grafica da Solucao Proposta . . . . . . . . . . . . . . 15
3.2 Representacao Grafica da Sequencia de Atendimento . . . . . . . . . 16
3.3 Representacao do Fluxo de Cadastro . . . . . . . . . . . . . . . . . . 22
3.4 Modelo de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Tela de Login da Aplicacao Android . . . . . . . . . . . . . . . . . . . 33
3.6 Notificacao e Tela de Principal . . . . . . . . . . . . . . . . . . . . . . 39
3.7 Menu de opcoes e Tela de Configuracoes . . . . . . . . . . . . . . . . 42
3.8 Tela de Resumo do Cliente . . . . . . . . . . . . . . . . . . . . . . . . 43
3.9 Tela de Edicao do Cliente . . . . . . . . . . . . . . . . . . . . . . . . 43
3.10 Tela para Inserir informacoes . . . . . . . . . . . . . . . . . . . . . . 44
3.11 Tela para Inserir Informacoes de Relacionamento . . . . . . . . . . . 45
3.12 Tela de Detalhe de Compra . . . . . . . . . . . . . . . . . . . . . . . 47
3.13 Recorrencia por Genero . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.14 Tıquete Medio por Genero e Faixa Etaria . . . . . . . . . . . . . . . . 49
3.15 Percentual de Cadastros Completos por Venda em cada Loja . . . . . 50
3.16 Total de Comentarios feitos por Atendente . . . . . . . . . . . . . . . 50
xi
Capıtulo 1
Introducao
1.1 Tema
Atualmente uma promissora rede de restaurantes possui cinco lojas e uma venda
media mensal de 30 mil itens por cada uma destas. Porem apesar do grande volume
de vendas, ainda nao possui nenhuma informacao da qualidade de seus produtos e
atendimento de seus clientes. Visando uma solucao individualizada para o problema
foi pensado um projeto computacional que envolve a criacao de um sistema completo
desde a aquisicao dos dados da compra ate a entrega, o armazenamento e a exibicao
dessas informacoes para os funcionarios da empresa.
1.2 Delimitacao
A aplicacao desenvolvida se limita a funcionar somente em celulares que possua
o sistema operacional Android. Os formatos dos dados enviados e recebidos pelo
sistema devem ser na formato JSON. O sistema deve ser intuitivo. O projeto limita-
se a adquirir informacoes apenas dos pontos de venda de uma empresa especıfica.
1.3 Justificativa
Durante muito tempo a venda foi descorrelacionada com o relacionamento dos
clientes, pensava-se que apenas o valor e a qualidade do produto fossem necessarios
para o retorno do cliente as lojas. No entanto, com o advento dos estudos compor-
1
tamentais humanos percebeu-se que a experiencia do cliente durante a visita a loja
e um fator decisivo para a fidelizacao.
Outro fator primordial para a resolucao deste projeto e o barateamento dos
espacos de armazenamento. Este avanco criou um novo mercado de servicos em nu-
vem, no qual as informacoes podem ser facilmente entregues e acessadas em qualquer
lugar sem ser preciso que o usuario se responsabilize pela manutencao dos servidores
dentro da sua empresa, assim, o poupando espaco fısico e capital investido nas suas
solucoes computacionais.
Somando-se a estes fatores a popularizacao da tecnologia devido aos Smartphones
Android. Atualmente qualquer pessoa pode carregar um mini-computador dentro
de seu bolso, capaz de entregar e receber informacoes sem a necessidade de um cabo
de rede.
Sendo assim, todos esses adventos permitem que os dados relevantes da ex-
periencia de um cliente no estabelecimento sejam armazenados e depois utilizados
na proxima visita de modo a melhorar o atendimento.
1.4 Objetivos
O objetivo geral e desenvolver um sistema computacional capaz de aproximar
a relacao cliente/estabelecimento de modo individualizado. Sendo assim, tem-se
como objetivos especıficos: (1) construir um banco de dados capaz de armazenar
informacoes relevantes sobre os clientes que frequentam a rede, (2) programar um
extrator capaz de adquirir as informacoes da vendas e popular o banco, (3) desen-
volver um Backend capaz de entregar as informacoes em tempo real, (4) codificacao
de um aplicativo Android para visualizar e entregar as informacoes enviadas pelo
Backend.
2
1.5 Metodologia
A execucao deste projeto pode ser dividida em quatro partes fortemente integra-
das: banco de dados, extrator de dados, Backend e aplicacao Android. A partir da
uniao desses componentes o sistema torna-se completo, permitindo a aquisicao, o
armazenamento e a entrega dos dados do cliente durante sua visita ao estabeleci-
mento. Primeiramente, seguindo o fluxo do processo, o extrator e responsavel por
ler os dados da compra realizada no caixa que foi escrita em um arquivo de texto
gerado pelo programa de ponto de vendas. Apos a leitura, o mesmo se conecta ao
banco de dados e escreve as informacoes relativas a compra do cliente, como: itens
comprados, loja e horario da compra. Caso o cliente ainda nao esteja cadastrado
no sistema e opte por se cadastrar, um novo cliente e criado no banco e em seguida
as informacoes da compra sao armazenadas. Em uma segunda hipotese, na qual
o cliente nao deseje se cadastrar, apenas os dados da compra junto ao nome sao
armazenadas.
Apos a primeira etapa de aquisicao de dados, comeca a fase de acesso a estes
atraves do Backend. Para este acesso, esse sistema exige que as informacoes sejam
obtidas atraves de rotas fixas indexadas por enderecos URL e os dados entregues
no formato JSON. Alem disto, o Backend tambem e responsavel por autentificar
o acesso dos usuarios entregando e validando um token individual de acesso. A
ultima etapa do processo encontra-se na aplicacao Android. Esta e responsavel pela
exibicao dos dados para os funcionarios da rede assim como tambem permitir a
insercao de novas informacoes relativas a experiencia do cliente na loja tais como:
reclamacoes, elogios ou um comentario pertinente.
O exito deste projeto pode ser visto atraves de indicadores que buscarao medir
o aumento na taxa de retorno dos clientes devido a nova aplicacao. Outro fator
que tambem indicara o sucesso do aplicativo e o uso constante pelos funcionarios da
rede. Para quantificar essas medidas uma analise do banco devera ser feita para se
obter os indicadores corretos.
3
1.6 Descricao
No capıtulo 2 sera responsavel por dar a base teorica por tras da construcao de
um Sistema CRM. Nele serao abordados desde a teoria mais generica aplicada a esse
tipo de sistema ate estudos mais especıficos na utilizacao dos mesmos para redes de
restaurantes. A importancia desses estudos e fundamental para que a construcao do
sistema seja feita.
O capıtulo 3 apresentara a solucao pensada para a construcao do projeto e os
motivos de escolha para a utilizacao de cada uma. Tambem serao abordadas nele
as especificacoes do Banco de Dados utilizados, do Backend e o desenvolvimento da
aplicacao Android. Antes de chegar nestas especificacoes, um estudo tambem sera
realizado para entender melhor o processo de experiencia do cliente durante sua
visita as lojas da rede. O capıtulo se encerrara analisando os dados e os resultados
da aplicacao do projeto.
As consideracoes finais e implementacoes futuras sao apresentadas no capıtulo 4.
Nele sera feita a analise que julga se o projeto cumpriu as necessidades desejadas,
essa analise se embasara nos resultados obtidos e tambem na comparacao do cenario
antes e apos a implementacao do sistema. No final deste capıtulo serao abordadas
as possıveis melhorias que podem ser implementadas em novas versoes do sistema,
tanto na parte de desempenho, quanto em novas funcionalidades.
4
Capıtulo 2
Fundamentacao Teorica
2.1 Introducao
Neste capıtulo serao abordadas as fontes de fundamentacao teorica as quais ser-
viram de alicerce para a construcao desse projeto. Dentro desse escopo se pode
dividi-las em duas vertentes de pesquisa: os atuais modelos de CRM e os estudos de
casos aplicados ao setor de restaurantes que investiram no atendimento individuali-
zado de seus clientes. Dentro do estudo do que constitui o CRM, serao abordadas
suas perspectivas, tipos e etapas. Baseado nesses fundamentos, foi possıvel uma
modelagem para o sistema que melhor atenderia e identificaria os diversos perfis de
clientes que frequentam o estabelecimento, e que permitem utilizar essas informacoes
para um atendimento mais individualizado.
2.2 Customer Relationship Management
Historicamente o termo CRM surgiu no meio dos anos 90 e rapidamente se dissemi-
nou. Devido a essa fama, a sua definicao acabou possuindo diversas interpretacoes,
porem a maioria foca em uma estrategia de marketing individualizada criada em
funcao da captacao de dados do cliente. Um exemplo deste tipo de abordagem foi
definido por Parvitiyar and Sheth (2001)[3]: ”CRM e uma estrategia para compre-
ender e um processo de adquirir, e manter uma parceria com clientes selecionados
de modo a criar um valor maior para a empresa e para o cliente”(traducao livre).
5
Outros autores como [2] adicionam tambem a importancia de se abandonar a
ideia do CRM apenas como uma implementacao de uma ferramenta tecnologica. E
acrescentado por esses que o CRM e tambem uma forma de aproximar a filosofia
da empresa numa abordagem mais centrada no cliente. Isso incluiria mudancas nas
regras e processos, no atendimento ao consumidor, no treinamento de funcionarios,
no marketing, nos sistemas de informacao e na forma de analises.
Alem das suas diferentes interpretacoes, um sistema de gestao de relacionamento
com o cliente pode ser visto em tres perspectivas diferentes: a funcional, a focada
no cliente e para visao da empresa [4]. Essas divisoes permitem entender o processo
por um ponto de vista complementar ao outro, facilitando o entendimento do sis-
tema como um todo e ajudando a identificar as diferentes estrategias que devem ser
abordadas.
Na literatura, outros autores como [1] definem essas perspectivas como formas
de utilizacoes da ferramenta. Podendo assim correlacionar as perspectivas com tres
tipos: estrategico, operacional e analıtico. Sendo que ainda para outros pesquisado-
res como [3] ha uma quarta forma, o CRM colaborativo. Esse seria responsavel por
interagir com clientes selecionados atraves de plataformas como e-mail, redes sociais
e paginas online. Porem, outros especialistas na area apontam esse tipo como parte
do CRM operacional.
Comecando pelo ponto de vista funcional, procura-se entender o conjunto de pro-
cessos que devem ser postos em pratica para que se possa executar as acoes de
marketing. Dentro dessas acoes pode-se citar: SFA (Sales Force Automation), in-
vestimento de divulgacoes e gerenciamento de conteudo de mıdias sociais. Sendo
assim, o CRM pode ser tambem visto como um fator auxiliar para a geracao de
conteudo de marketing em seus diversos meios de divulgacao.
Complementando essa ideia, tem-se a visao do CRM Operacional. Segundo [1]
alem das ideias incluıdas no ponto de vista funcional, o CRM operacional tambem
se responsabilizaria pela captacao de dados, processamento das transacoes, controle
do fluxo de vendas, marketing e servicos. Outras pesquisas como [2] incluem a
6
importancia do CRM operacional como a base necessaria para se obter informacoes
sobre os clientes e para poder cede-las para as outras formas de utilizacoes do CRM.
Numa outra abordagem, quando analisado pelo ponto de vista focado no cliente
o sistema possui a missao de gerar um valor individual de seus consumidores em
seus diferentes canais de comunicacao. Sendo assim, o CRM deve gerenciar as in-
formacoes de modo a identificar as diferentes formas de abordar o cliente dependendo
do canal de relacionamento escolhido. Por exemplo: um consumidor pode se relaci-
onar com a empresa tanto em suas lojas fısicas quanto nas lojas virtuais da rede e
a experiencia deve ser individualizada em cada um delas de forma diferente.
De forma similar, a visao analıtica do CRM tambem busca gerar um tratamento
individual para o cliente, mas sem se preocupar com o canal de comunicacao que
sera utilizado. Nesse tipo de definicao, o CRM e entendido como o conjunto de
informacoes adquiridas de cada consumidor de forma a entender seu comportamento,
valor para organizacao e a que tipo de segmentacao pertence. Para isso, autores
como [1] sugerem o uso de analises estatısticas para a identificacao desses padroes,
mais especificamente o uso de tecnicas de data mining.
Por fim, na perspectiva empresarial, o CRM e visto como um sistema que im-
pacta internalmente as decisoes de uma companhia. Ao entregar dados do cliente
para a empresa, apos a analise destes, o CRM influencia diretamente nas decisoes
estrategica, podendo informar aos gestores as melhores formas de atrair seus cli-
entes ou de aumentar o valor da marca para eles. Como resultado disso, o CRM
acaba impactando diversas areas de decisao estrategica da empresa, como: pesquisa
e desenvolvimento e cadeia de suprimentos.
De maneira semelhante a perspectiva empresarial, tem-se o CRM estrategico. Este
serve como uma estrategia basica de negocio, que reflete uma visao de longo prazo
que se esforca em criar e retribuir valor ao cliente [5]. Alguns autores como Payne
e Frow [6] citam que o objetivo principal da utilizacao do CRM como ferramenta
estrategica e alinhar os objetivos gerais da companhia com a estrategia de conquista
do cliente.
7
Numa tentativa de tornar essas divisoes mais claras, e comum encontrar na lite-
ratura representacoes graficas do sistema. Autores como Rabbath, Mohd e Ibrahim
[1], buscaram representar essas segmentacoes de acordo com as principais tarefas
desempenhadas em cada tipo de aplicacao do CRM, como pode ser visto na imagem
abaixo:
Figura 2.1: Representacao do Sistema CRM por [1]
Na representacao pode-se notar diversas etapas dentro de cada tipo de aplicacao
do CRM. Na parte estrategica, e destacado o desenvolvimento das estrategias de
negocio e de relacao com o cliente, assim como o processo o de criacao de valor. Nesse
processo, pesquisadores como Payne e Frow [6] dizem existir tres pontos cruciais:
determinar que valor a empresa pode promover para o cliente, o que a companhia
vai receber em valor do cliente e manter constantemente esta troca de valores.
Seguindo para a parte operacional, pode-se ver o processo de integracao dos
multiplos canais de contato com o cliente. Para essa abstracao, a representacao
do sistema por Lun Zhang, Jinlin Li e Yingying Wang [2] se adequa melhor por fo-
car mais nas estruturas fısicas que constituem cada parte do sistema e nao somente
nas acoes, como pode ser visto na figura 2.2:
8
Figura 2.2: Representacao do Sistema CRM por [2]
Na parte inferior da imagem, ve-se um bloco representando o sistema de integracao
entre aplicacao e empresa (Enterprise Application Integration System, EAI ). Esse
componente do processo e citado pelos autores como o responsavel por entregar em
tempo real as informacoes do cliente que impactam nos outros diferentes sistemas
utilizados pela empresas como: ERP (Enterprise Resource Planning), SCM (Supply
Chain Management) e OA (O�ce Automation).
Ainda observando a representacao utilizada por Lun Zhang, Jinlin Li e Yingying
Wang, ve-se a ligacao da parte analıtica do processo com a estrutura de armazena-
mento de dados junto a sua parte de analise de dados. Nesse segmento, tambem
pode-se ver a ligacao entre o CRM analıtico e colaborativo feito por uma CTI (Call
Center Integration System), responsavel por buscar as informacoes dos clientes e
usa-las para gerar um atendimento individualizado nos diversos meios de comu-
nicacao.
9
2.3 Processos do CRM
Os processos do CRM podem ser definidos como as atividades realizadas pela
organizacao ao se preocupar com o relacionamento com o cliente, sendo essas or-
ganizadas de acordo com uma visao longitudinal desse relacionamento [1]. Outras
referencias citam como as decisoes da companhia a respeito da iniciacao de ativida-
des para um grupo especıfico de clientes ou para um cliente individual com quem a
companhia decide estabelecer uma relacao [7].
Quando se trata de discutir as divisoes que constituem o processo de gestao de
relacionamento com os clientes pode-se nomear tres partes principais: comeco do re-
lacionamento, a manutencao e o termino. Porem, um modelo mais completo propoe
subdividir cada dimensao em mais subdivisoes (Reinartz, Kfra↵t e Hoyer, 2004) [4],
sendo a avaliacao feita pelo cliente uma subdivisao comum de todas as etapas mai-
ores. As restantes sao: gestao de aquisicao e recuperacao de clientes para etapa de
comeco do relacionamento, retencao, up-selling/cross-selling e gestao de indicacoes
para etapa de manutencao. A ultima etapa, de termino do relacionamento, possui
apenas uma outra subdivisao que e a gestao de desligamento do cliente.
Durante a fase de inıcio do relacionamento comecam as buscas e as identificacoes
dos clientes. A busca pode ser feita por meio de ferramentas ou de dados externos
que indiquem novos potenciais clientes, assim como clientes que possam ser recupe-
rados para dentro da marca novamente. Outra maneira de captar novos clientes e
utilizando canais de mıdia que atraiam novos consumidores em potencial. Apos a
captacao, tambem faz parte do inıcio de relacionamento identificar entre os potenci-
ais clientes quais possuem o maior valor para a companhia e receber uma impressao
inicial que o cliente tem sobre a marca.
Na segunda etapa do processo tem-se as acoes responsaveis pela manutencao do
relacionamento. Uma caracterıstica importante desta fase e a presenca de um canal
de mao dupla de comunicacao para se ouvir as necessidades do consumidor assim
como informar as solucoes providas para cada individuo. Nesta parte do relaci-
onamento tambem sao utilizadas as informacoes para montar uma estrategia de
venda casada (cross-selling) e complementar (up-selling), numa forma de expandir
10
as vendas da empresa ao mesmo tempo que indicando produtos de interesse para o
consumidor. Por fim, tambem se estimula que o cliente indique a marca para outros
possıveis consumidores atraves de diversos incentivos.
A ultima etapa e o desligamento da relacao entre empresa e cliente. Essa parte do
processo e responsavel por dar fim as relacoes que possam gerar prejuızo ou baixo
retorno financeiro. Sendo assim, o processo de gestao de relacionamento dos clientes
busca por fim buscar uma imagem unica do cliente atraves de todas as plataformas
de contato[1].
2.4 CRM Aplicado em Restaurantes
Ao analisar um mercado como o ramo de restaurantes, a competitividade por
clientes e o primeiro fator a ser alarmado [8] [9]. Apesar das causas dessa disputa
variarem de acordo com a regiao e o nicho de mercado, os mesmos autores citam
como a causa principal o baixo custo de troca para o cliente devido a semelhanca
de preco e qualidade do produto. Outro fator considerado e o avanco da tecnologia
que proporcionou aos consumidores acesso a informacao mais facilmente, forcando as
empresas a se renovarem ou perecerem na tentativa [10]. Como exemplo desta grande
competitividade artigos citam os fechamentos de diversos restaurantes e perdas em
seus rendimentos. Rivas et al. [10] apontam que apenas tres de dez restaurantes
novos conseguiram se manter em sua regiao e em Ali et al. [8] e aferida uma queda
de em media 20% ate 45% da receita anual.
Em resposta a esta crescente competitividade, ferramentas como o CRM vem
se destacando como uma resposta para atrair e manter a fidelidade dos clientes
atraves de um atendimento individualizado. Como consequencia disso, estudos nesta
area de aplicacao comecaram a surgir afim de confirmar os impactos de um bom
servico de atendimento e tambem buscando formatar um modelo de CRM especıfico
para o setor de restaurantes. Esses estudos, apesar de possuırem objetivos finais
semelhantes, acabam adotando caminhos diferentes, uns mais focados em gerar um
11
modelo especıfico de CRM e medir sua efetividade para restaurantes [11][10], outros
focados em relacionar o uso de web-sites para melhorar a relacao entre clientes e
estabelecimentos[8], e tambem em relacionar a qualidade do servico com a lealdade
do consumidor.
Comecando por Rivas et al. [10], suas analises no ramo de restaurantes mexi-
canos no estado de Jalisco tentam estruturar um modelo de CRM que melhor se
adeque aos problemas individuais desse setor. Para isso, os autores comecam o es-
tudo atraves da definicao do que e um CRM ate chegar a analisar as componentes
que impactam no sistema e identifica-las em seu caso de estudo. Neste sentido,
foram identificadas como variaveis que influenciam o sistema: a orientacao do con-
sumidor, as informacoes e tecnologias de comunicacao, a capacidade administrativa
e o conhecimento da competicao no mercado globalizado.
Numa perspectiva mais operacional, Ibrahim et al. [8] elabora um estudo sobre o
uso de web-sites para captacao de dados do cliente. Em seu estudo, a pesquisa foi
feita utilizando formulario constituıdo de duas partes, a primeira contendo perguntas
para obter informacoes demograficas, como: idade, genero e profissao. Na segunda
parte, as perguntas se referem ao relacionamento dos clientes com a interacao dos
web sites de franquias de fast food. Atraves da coleta de dados, o autor sugere uma
plataforma online constituıda de quatro partes: area de login de membros, compra
online, espaco para feedbacks e cartoes fidelidade.
Na pesquisa realizada por Joseph E. Saleeby [9] o autor busca encontrar as
variaveis que ligam a marca ao seus clientes. Para isso, em sua metodologia de
pesquisa foram mapeadas cinco variaveis para investigar a qualidade do servico:
tangibilidade, confiabilidade, capacidade de resposta, seguranca e empatia. Para
medir a influencia dessas variaveis no problema, a pesquisa utilizou um questionario
distribuıdo em sete restaurantes libaneses. Como resultado do estudo, o autor des-
cobriu uma forte relacao entre capacidade de resposta e a seguranca com a qualidade
do servico percebida pelo cliente. Outra constatacao encontrada foi a falta de ca-
pacidade dos donos dos estabelecimentos de perceber a correlacao dessas variaveis
com a fidelidade com cliente.
12
Por fim, Elahe et al. [11] busca correlacionar o efeito geral de ferramentas CRM,
o valor percebido pelo cliente e a qualidade de relacionamento como moderadores
dessas relacoes entre consumidores e restaurantes. Para isso, nessa pesquisa foram
utilizados dados adquiridos em campo e questionarios formulados apos uma revisao
teorica do assunto. Como resultado principal, a pesquisa mostrou uma relacao forte
entre a qualidade do relacionamento e o uso de ferramentas CRM. Alem disso, ou-
tras constatacoes confirmaram ligacoes positivas no valor da marca ao longo prazo,
fidelidade e propagandas. No final, o autor tambem ressalva a importancia de au-
tonomia dos restaurantes para resultados positivos, alem da responsabilidade de
propagar a autonomia para equipe do estabelecimento, ja que o estudo indicou que
o rendimento da equipe aumenta de acordo com a responsabilidade atribuıda.
13
Capıtulo 3
Implementacao
3.1 Descricao do Problema
Uma rede de hamburguerias possui um total de cinco lojas e previsoes para conti-
nuar expandido durante os proximos anos. Dentre as diversas causas que explicam
esse sucesso em meio ao cenario conturbado economico Brasileiro estao a qualidade
de seus produtos junto a irreverencia da marca que busca atrair os clientes atraves
de um marketing arrojado, tanto sua parte visual, quanto na sua abordagem ao
cliente. Alem desses atrativos, a marca tambem busca proporcionar ao seu visitante
um bom atendimento e a valorizacao da experiencia do mesmo durante o seu tempo
em loja.
A estrategia vem se mostrando eficaz e os numeros comprovam isso. Atualmente
as lojas da rede vendem mais de 30 mil itens mensalmente e conta com uma visita
media de 10 mil clientes mensalmente. No entanto, ao contrario do que preconiza
sua ideologia a marca pouco sabe sobre seus clientes alem de uma mera estimativa
demografica baseada em analises de redes sociais. Sendo assim, a empresa decidiu
investir em tecnologia para captar dados mais consistentes sobre seus clientes, cor-
relacionar os diferentes perfis com dados da compra e acessar informacoes sobre a
experiencia de sua clientela durante a visita as suas lojas.
14
3.2 Arquitetura da Solucao
Buscando satisfazer as necessidades da empresa, uma ferramenta CRM mostra-se
adequada ao cenario pois permite captar as informacoes dos clientes e distribuı-las
para diferentes setores da empresa como: marketing, financeiro e compras, possibili-
tando que sejam utilizadas pelos mesmos de forma a aumentar o valor da marca para
o cliente. Sendo assim, para a realizacao do projeto o sistema foi dividido em qua-
tro partes integradas: Extrator de Dados, Backend (API, Application Programming
Interface) e Aplicacao Android, onde cada uma possuı um papel especıfico durante
os diferentes processos de aquisicao, armazenamento e distribuicao dos dados.
Figura 3.1: Representacao Grafica da Solucao Proposta
O esquema representa o fluxo de informacao atraves dos diferentes componentes
do sistema, comecando pelo surgimento do arquivo texto. O extrator detecta a
criacao deste arquivo, realiza em seguida sua leitura para que as informacoes sejam
separadas e enviadas ao banco de dados, onde ficam salvas. Durante esse processo,
o aplicativo esta periodicamente em comunicacao com o Backend em busca de uma
nova venda no registro de dados. No momento em que a API retorna uma venda
diferente da ultima, uma notificacao e acionada na aplicacao movel. Por fim, o
pedaco restante do esquema mostra a capacidade de acesso das informacoes atraves
do Backend por outras plataformas como: paginas web e softwares externos.
Para o entendimento da solucao pensada e necessario primeiro compreender o
fluxo da informacao e suas diferentes fontes. Dessa forma, deve-se seguir o fluxo
do cliente desde a sua chegada a loja ate o fim de sua experiencia dentro dela. O
15
cliente formalmente inicia a sua jornada antes mesmo de chegar a realizar seu pedido.
Isso porque em todas as lojas ha um profissional responsavel em receber os clientes
e apresenta-los aos produtos oferecidos, chamado de Encantador. E importante
informar tambem que alem apresentar a loja, esse profissional tambem e instruıdo
a fazer o cliente se sentir em casa e entender suas necessidades atraves de suas
habilidades interpessoais.
Apos o primeiro contato, o cliente chega ao caixa da loja onde outro profissional
esta preparado para anotar o seu pedido e realizar o pagamento da compra. Para
isso, a franquia utiliza um programa de uma empresa terceirizada que administra
o processo de emissao de nota fiscal e recebimento do pagamento via cartao ou
dinheiro. Apos a confirmacao da compra, o profissional e instruıdo a perguntar o
nome do cliente para que possam chama-lo quando o pedido estiver pronto. O passo
seguinte depende apenas do cliente aproveitar o ambiente da loja enquanto consome
seu lanche. Por fim, o atendente e sempre instruıdo a perguntar a opiniao do cliente
sobre o atendimento e qualidade do pedido.
Figura 3.2: Representacao Grafica da Sequencia de Atendimento
16
Sendo assim, o primeiro desafio foi conseguir uma maneira de identificar o cliente
durante o pedido e conseguir relacionar os dados do mesmo toda vez que esse retornar
a loja. Para isso, foram estudadas as opcoes da plataforma da empresa de sistema
de pontos de vendas e foi encontrada uma opcao de salvar os dados da compra em
um arquivo de texto, que poderia ser entao lido pelo extrator e armazenado no
banco de dados. Alem disso, foi feita a inclusao de uma tela de cadastros onde o
operador de caixa pode inserir outras informacoes do cliente alem do nome, como:
CPF, data de nascimento, e-mail, data de nascimento, telefone e genero que tambem
serao armazenadas no arquivo de texto da compra.
3.3 Extrator de Dados
O primeiro passo para a construcao do extrator de dados e saber a forma como
a informacao se encontra no arquivo de texto. Com esse proposito, foi pedido a
empresa desenvolvedora do programa de pontos de venda a documentacao especıfica
relativa a formatacao das informacoes de venda dentro do arquivo salvo na maquina.
A proxima etapa, e separar essas informacoes devidamente para envia-las ao banco
de dados onde ficarao armazenadas. E importante notar tambem que o conhecimento
dos dados armazenados neste arquivo e essencial para a modelagem do banco de
dados.
Seguindo o manual cedido pela empresa, notou-se que a estrutura das informacoes
no arquivo texto possui cinco tipos de registro, onde cada um possui um codigo
indicador para demarcar o inıcio de suas informacoes. E importante frisar que
muitas informacoes contidas neste arquivo sao colocadas afim de auxiliar o software
de ponto de vendas e nao sao armazenadas no banco de dados deste projeto.
Registro Header de Arquivo - Codigo: 0: Nessa secao sao contidas in-
formacoes relativas a versao do arquivo texto, assim como data, hora e local de
geracao do arquivo. Sendo que as informacoes do local incluem: codigo identifica-
dor da loja e CNPJ.
17
Registro Header de Lote - Codigo 1: Nesta parte do documento estao ar-
mazenadas informacoes da venda, como tipo da venda: balcao, delivery ou mesa.
Outras informacoes ligadas com o valor da compra, desconto e dados fiscais tambem
sao encontrados nessa secao. Alem dessas informacoes, nessa parte tambem e indi-
cado se a compra foi cancelada. Nesse ponto, e importante destacar o funcionamento
de cancelamento de compra. Apos a realizacao de uma compra, caso o cliente opte
por cancelar, o sistema ira gerar um novo arquivo contendo as mesmas informacoes,
porem alterando o caracter indicador de venda cancelada para ”S”.
Registro Detalhe - Codigo 3: Neste registro a empresa decidiu dividir em
quatro segmentos, cada um com seu proprio codigo de segmento. O primeiro sao os
detalhes do cliente, como: nome, CPF (ou CNPJ), endereco, telefone e genero. Logo
em seguida, vem os detalhes do item da compra que contem informacoes do tipo:
quantidade do item escolhido, valor unitario e outras informacoes deste item. Apos,
ha uma subsecao chamada Observacao de Item, onde indica alguma observacao feita
pelo cliente sobre algum detalhe do pedido, por exemplo o ponto da carne. Por fim,
o ultimo segmento contem as informacoes de formas de pagamento utilizadas e seus
valores parciais, como: nome da forma de pagamento e o valor pago nesta forma.
Registro Trailer de Lote - Codigo 5: Nessa secao encontram-se o somatorio
total de produtos na compra, subtotal por produto, subtotal por subproduto e valor
total da compra somando todas as formas de pagamento realizadas sem descontos.
Registro Trailer de Arquivo - Codigo 9: Essa parte do arquivo possui apenas
dados para controle interno da empresa criadora do software do ponto de venda e
nao possuı dados relevantes para a construcao do sistema CRM.
Ainda no manual, a empresa especifica o tamanho de cada campo assim como a
forma de preenchimento caso a informacao nao ocupe o tamanho total fornecido.
Nesse caso, nos campos alfanumericos os espacos restantes sao preenchidos com
espacos ate atingir o limite de seu campo e nos campos numericos os campos sao
completados com zeros a esquerda. Sintetizando essas informacoes, pode-se entender
a seguinte linha do arquivo texto: 3B00001DINHEIRO 000000600000000000000000
18
O primeiro caracter e o tipo de Registro, no caso 3 representa um arquivo. Em
seguida, a letra B, indica o segmento de formas de pagamento. Seguindo a tabela
presente no manual, tem-se o codigo da forma de pagamento que e do tipo numerico
e possuı 5 caracteres de extensao, sendo no caso 00001. Em seguida, esta escrita
o nome da forma de pagamento, que ocupa o espaco de quarenta caracteres, sendo
preenchida com espacos em branco a direita. O resto dos numeros encontrados na
linha tambem esta explıcito no manual e podem ser identificados seguindo a mesma
logica.
Apos entender como a informacao se encontra no documento, a solucao segue
outras duas etapas: a coleta das informacoes no arquivo texto e a escrita desses dados
no banco. Para iniciar a coleta de dados, a solucao deve identificar a presenca de um
novo arquivo texto na maquina e logo em seguida interpreta-lo a fim de segmentar
as informacoes encontradas nesse. Logo apos inicia-se a etapa final que consiste
em abrir uma conexao com o banco e escrever as informacoes nas devidas tabelas.
Apesar da simplicidade dessas duas etapas, dentro delas existem situacoes adversas
que deverao ser contornadas pelo software como: perda de conexao e deteccao de
vendas canceladas.
Considerando-se que a tarefa de abrir um arquivo texto e interpreta-lo pode ser
executada facilmente por qualquer linguagem de programacao, o criterio para a
escolha foi simplificado e o fator decisivo que guiou a decisao foi a experiencia com
a linguagem de programacao, sendo optado pela Python. Alem disso, outros fatores
reforcam a escolha dessa linguagem como a documentacao extensa, comunidade
ativa e diversas bibliotecas para auxiliar na solucao do problema.
O nucleo principal do extrator e o observador. Segundo Bruce Eckel[12] o ob-
servador e uma classe de ”interface”que possui somente um unico metodo chamado
update(). Esse metodo e chamado pelo objeto que esta sob cuidado do observador,
quando este decide que e hora de atualizar todos seus observadores. Sendo assim,
utilizando essa solucao e possıvel saber o momento que um novo arquivo texto e cri-
ado na pasta e tomar as acoes necessarias para processar as informacoes presentes
no texto.
19
Durante a execucao, quando o observador e acionado pela ocorrencia de uma nova
venda, este escreve o nome do arquivo numa fila que contem os nomes de arquivos
gerados desde o inıcio de sua execucao e que ainda nao foram salvos no banco de
dados. Essa fila e lida constantemente por uma thread paralela que abre o arquivo
texto e enviar as informacoes para o banco. E importante tambem destacar que
nessa parte sao realizadas duas validacoes de campo, sendo confiado que o resto e
tratado pela empresa de software do ponto de venda. O unico papel do programa
neste ponto e formatar as informacoes para os padroes de variaveis utilizados no
banco de dados, por exemplo: (data),(valor da venda).
Para uma melhor leitura do codigo, processamento das informacoes contidas no
texto e gerenciamento das escritas das informacoes no banco de dados, foi desenvol-
vida uma classe chamada Cupom. Esta classe possui os seguintes metodos:
init : E o Construtor da Classe. Nesse metodo sao inicializados os atributos
da classe Cupom atraves da leitura do arquivo texto da venda.
connect db: Abre a conexao com o banco de dados e salva relatorios de envio e
falha de comunicacao com o banco.
insert clientSale: Insere um novo cliente no banco de dados e as informacoes
da venda realizada.
insert sale: Insere as informacoes de uma compra num cliente ja cadastrado.
update cancelSale: Responsavel para mudar o indicador de uma venda para
cancelado no banco de dados.
insert lastSale: Atualiza na tabela do cliente a ultima compra.
insert PenulSale: Atualiza na tabela do cliente a penultima compra.
verify email: Verifica o cadastro de um cliente pelo e-mail.
insert products: Insere produtos da venda no banco de dados.
20
insert payments: Insere as informacoes de forma de pagamento.
end connection: Fecha a conexao com o banco de dados.
O primeiro passo antes de enviar as informacoes para o banco e buscar nas in-
formacoes do arquivo texto se esta e realmente uma venda ou o cancelamento de
uma ja existente. Para isso, o extrator busca no Registro Header de Lote o caracter
S na linha 20, caso seja encontrado o metodo update cancelSale da classe Cupom e
ativado.
if (cupom.venda_cancelada == ’S’): # query mudar no banco valor para S
print("Venda Cancelada\n")
#necessario criar funcao tb e passar a query junto com o dado
#Necessario reconhecer qual e o id unico da venda
#para atualizar no banco o status da venda
cupom.update_CancelSale(cursor, cup)
Em seguida, a thread conecta com o banco dados utilizando a biblioteca pyscopg2.
Caso a escrita no banco de dados ocorra sem problemas o programa busca uma
nova compra e repete o ciclo. No entanto, caso ocorra algum tipo de problema
com conexao ao banco a thread continua tentando conexoes periodicas com o banco
enquanto o observador continua escrevendo os cupons de venda na fila. Dessa forma,
em casos de perda de conexao, nenhuma informacao de venda e perdida pois a fila
mantem na memoria os arquivos textos ainda nao salvos no banco. Uma observacao
importante sobre esse processo e o travamento da fila para leitura durante a escrita,
isso permite que mesmo que uma leitura nunca interrompa o processo de insercao
de uma venda fila.
O processo de envio das informacoes para o banco de dados e regido por algumas
regras de negocio. A comecar pela definicao de cliente cadastrado. No sistema
um, cliente so e considerado cadastrado caso possua em suas informacoes o e-mail
ou CPF. Por tanto, antes da emissao das informacoes de venda, o software deve
considerar tres opcoes de fluxo na qual todas possuem uma etapa inicial de busca
pelo CPF ou e-mail ja cadastrado, como mostra a imagem 3.3:
21
Figura 3.3: Representacao do Fluxo de Cadastro
Cliente nao cadastrado e quer se cadastrar: Nessa situacao, um novo re-
gistro e criado no banco e em seguida as informacoes de vendas sao atribuıdas ao
consumidor.
Cliente ja cadastrado: Nesse caso as informacoes de vendas sao ligadas auto-
maticamente ao perfil ja existente no banco de dados.
Cliente nao quer se cadastrar: Nesse caso somente o nome junto aos dados da
compra sao salvos no banco de dados e sao utilizados apenas para guiar o atendente
durante aquela visita, nao podendo ser relacionados numa proxima compra.
Apos lidar com as informacoes do cliente, o extrator salva as informacoes da venda
como: produtos, hora da compra, loja e valor total, em seguida a conexao com o
banco e finalizada e o programa fica a espera do observador para executar novamente
a rotina de captacao das informacoes da venda e envio dessas para o banco de dados.
22
3.4 Banco de Dados
Durante a fundamentacao da solucao para o banco de dados os topicos principais a
se pensar sao: a estrutura fısica e a logica. Quanto a estrutura fısica, essa geralmente
se refere ao aporte de maquinas que serao utilizadas para armazenar, distribuir e
receber dados, sendo geralmente uma das partes mais caras na implementacao deste
tipo de projeto. Quanto a estrutura logica, essa se refere a estrutura dos dados
armazenados nos datacenters, alem da linguagem de estrutura de dados utilizada
para realizar os pedidos de escrita e leitura das informacoes armazenadas.
Visando o aporte financeiro da empresa e seu capital limitado destinado a solucoes
tecnologicas, uma recurso que se encaixa nessas limitacoes e a utilizacao de uma
estrutura de computacao em nuvem, o que reduz os custos da implementacao e da
manutencao de um datacenter dentro da empresa. Fora a vantagem economica,
projetos que utilizam computacao em nuvem levam vantagem por serem escalaveis,
baixo tempo de entrega e comecam a operar mais rapidamente [13], provando assim
ser uma solucao ideal para o projeto.
Apos definir a utilizacao de uma estrutura em nuvem para a parte de armazena-
mento,a proxima etapa e selecionar a empresa para prover esse servico. Nesse ponto,
a companhia escolhida foi a Amazon e o seu servico de Web Services. A decisao
foi baseada no numero grande de servicos em nuvem oferecidos pela empresa, na
possibilidade de integracao entre os diferentes servicos, na escalabilidade e no baixo
preco.
A proxima etapa entao e escolher qual das instancias oferecidas pela empresa sera
contratada. Utilizando uma estimativa alta, considerando que tres funcionarios em
cada uma das cinco loja utilize simultaneamente o aplicativo, tem-se um maximo
de quinze conexoes. Sendo assim, a categoria mais basica da Amazon (db.t2.small)
seria mais que satisfatoria para este caso de uso. Alem disso, a Amazon permite
que esta instancia seja alterada, suprindo assim a demanda no caso de abertura de
novas lojas.
23
Por fim, a ultima etapa e a escolha da forma de estrutura dos dados armazenados.
Nesse ponto, deve-se optar por uma linguagem relacional ou nao relacional. Para esse
caso, a estrutura escolhida foi a relacional, isso porque o desempenho nao depende
de fato da estrutura de dados desde que seja bem implementada [14]. Apos a escolha
da estrutura de dados, deve-se escolher a linguagem de definicao dessa.Para isso foi
definida a PosgreSQL. O motivo da escolha consiste no vasto conteudo disponıvel
gratuito, na afinidade e na possibilidade de integracao com a Python e tambem por
estar disponıvel como linguagem de estrutura de dados na AWS.
Definida a linguagem de estrutura de dados o passo seguinte e a estrutura relaci-
onal dos dados. Para escolha adequada desta e necessario primeiro entender como
funciona a relacao entre os diversos dados do processo. Comecando primeiro pelas
informacoes vindas do software de vendas. Nestas estao contidas os itens da compra,
informacoes da venda (data, hora, local) e os dados do cliente que realizou a compra.
Outro ponto necessario nessa discussao e abordar a forma como serao armazena-
das as opinioes do cliente durante a visita ao estabelecimento. Conversando com
a direcao da empresa foi definido que a entrada dos dados seriam feito pelos aten-
dentes, sendo esses responsaveis captar as impressoes do cliente sobre a visita por
meio de uma conversa informal. Logo em seguida, o atendente pode escolher tres
classificacoes para um comentario da visita: pessoal, reclamacao e elogio. Sendo
que cada venda pode ter mais de um tipo de comentario sendo do mesmo tipo ou
de tipos diferentes. Sendo assim, um esquema de relacao de dados foi proposto da
seguinte maneira:
Figura 3.4: Modelo de Dados
24
Para explicar o modelo, a melhor forma e partir da sua estrutura principal: a
venda. Isso porque toda inclusao de dados necessita do acontecimento de uma venda
para acontecer, ate mesmo o cadastro do cliente que e um processo que precede a
venda. Nesta tabela estao contidos os seguintes dados: hora da venda (hora), data
(data), valor total (valor total), se ela foi cancelada (cancelada) e a quantidade total
de produtos naquela venda (qnt total prod).
Ainda na tabela de vendas, podem ser encontradas as chaves estrangeiras: cliente,
comentario, loja e detalhe venda. A chave estrangeira id cliente cliente liga a venda
ao cliente que ocasionou ela numa relacao muitos pra um, ou seja, um cliente pode
ocasionar multiplas vendas, mas uma venda so pode ter um cliente, a mesma relacao
ocorre com a tabela Loja, porem indicando em qual das lojas a venda ocorreu.
A tabela comentarios, armazena os comentarios sobre uma venda especıfica, po-
dendo essa venda nao ter nenhum comentario relacionado. Para armazenar o conteudo
e tipo de comentario, a tabela tipo comentario e ligada a esta por uma chave es-
trangeira numa relacao um pra um. Nos comentarios tambem e encontrada uma
chave estrangeira para a tabela Funcionarios, representando qual foi o funcionario
que adicionou aquele comentario. O mesmo tipo de relacao e aplicada para o cliente.
A tabela cliente armazena os dados cadastrais de um consumidor, podendo ter
somente o seu nome (nao sendo considerado cadastrado) e/ou CPF ou e-mail para ser
considerado cadastrado. Fora isso, essa tabela tambem pode ser acessada por uma
chave estrangeira presente nas tabelas venda e comentario, sendo assim utilizada
para indicar qual cliente ocasionou a venda ou fez algum tipo de comentario sobre
sua experiencia na loja.
Por fim, as ultimas tabelas que restam sao relacionadas aos produtos. A principal
estrutura nesse segmento de dados e a tabela produto venda.Essa tabela armazena
todos os produtos a venda na loja e seu valor. Ligada a esta, temos numa relacao
um pra um a tabela grupo produto que informa se o produto pertence ao grupo
25
de bebidas, hamburguer ou sobremesas e quantidade total de produtos naquele seg-
mento. Para apontar quais produtos foram incluıdos dentro da venda a estrutura
detalhe venda foi utilizada, contendo apenas as chaves da venda, produto e a quan-
tidade do item vendido.
3.5 Backend
Possuindo ja as solucoes voltadas para a extracao e o armazenamento de dados, o
passo seguinte e prover uma forma segura de acesso e gerenciamento da informacao
coletada. Uma forma rapida de implementacao para isso poderia ser utilizando o
acesso direto ao banco via aplicacao movel. No entanto, nesse caso o gerenciamento
de quais informacoes poderiam ser acessadas seria muito custosa, sendo necessario
criar inumeros perfis de acesso ao banco de dados. Alem disso, colocar a chave de
acesso ao banco dentro de aplicacao permite que essa possa ser encontrada por um
processo de engenharia reversa.
Buscando uma solucao que se adequasse ao tempo de projeto disponıvel, limite
financeiro e seguranca da informacao foi pensado o uso de uma Rest API de acesso
aos dados. Isso porque uma API permitiria o acesso da informacao atraves de
um controle de acesso sem a necessidade de entregar a senha de acesso ao banco
de dados ou a criacao de um perfil de acesso direto ao banco para cada usuario.
Outras vantagens tambem podem ser encontradas nas regras de leitura e escrita das
informacoes, como a validacao dos campos enviados, permitindo que certas tabelas
tenham apenas a permissao de leitura ou de escrita para uma determinada rota de
acesso.
Existem diversas plataformas oferecidas para o desenvolvimento de uma Rest
API. Nesse caso, a plataforma deve ser tal que se integre bem com a linguagem
de estrutura de dados PostgreSql e que se adeque as limitacoes financeiras. Para
isso foi escolhida a Django Rest Framework, que permite a exportacao de um banco
de dados legado para o sistema, alem de ser gratuita e possuir uma comunidade
de suporte grande e ativa. Alem disso, por ser uma extensao do projeto Django,
diversos paralelos podem ser tracados facilitando a familiarizacao com a plataforma.
26
Comecando pela importacao dos modelos de dados, e necessario primeiro fazer
uma ligacao do banco de dados com o database connection engine. Para isso basta
especificar no arquivo de configuracoes ’settings.py’ o endereco, porta e as credenciais
de acesso. Em seguida, executa-se um unico comando no terminal para a importacao
dos modelos de dados:
./manage.py inspectdb >> models.py
Dessa forma, o proprio Django gera os modelos para serem utilizados. O exemplo
a seguir se refere ao modelo gerado para a tabela Cliente:
class Cliente(models.Model):
id_cliente = models.AutoField(primary_key=True)
nome = models.TextField( blank=True, null=True)
telefone = models.TextField( blank=True, null=True)
cpf = models.TextField( blank=True, null=True)
endereco = models.TextField( blank=True, null=True)
primeira_vez = models.NullBooleanField()
data_nascimento = models.DateField(blank=True, null=True)
observacao = models.TextField(blank=True, null=True)
foto = models.TextField( blank=True, null=True)
email = models.TextField( blank=True, null=True)
sexo = models.CharField(max_length=1, blank=True, null=True)
id_ultima_compra = models.ForeignKey(’Vendas’, models.DO_NOTHING, db_column=’id_ultima_compra’, blank=True, null=True)
class Meta:
managed = False
db_table = ’cliente’
Apos a traducao dos modelos, a proxima etapa e preparar as Views de acesso
para cada modelo. Nesse ponto, a vantagem de utilizar a DRF (Djando Rest Fra-
mework) se torna evidente, pois a implementacao dos metodos padroes HTTP ja
sao realizadas automaticamente pela Framework. Como exemplo, o caso do acesso
ao modelo de Lojas:
class LojaViewSet(viewsets.ModelViewSet):
27
permission_classes = (IsAuthenticated,)
queryset = Cliente.objects.all()
authentication_classes = (TokenAuthentication,)
queryset = Loja.objects.all()
serializer_class = LojaSerializer
Observando o codigo pode-se perceber outra facilidade oferecida pela ferramenta:
a inclusao de login para controlar o acesso as informacoes. Nesse caso, permis-
son classes indica que o usuario deve ser autenticado para acessar as informacoes
entregues pela View e authentication classes sinaliza o metodo que realiza essa au-
tenticacao, no caso utilizando Tokens. A escolha de Tokens e justificada pelo fato
deles poderem ser armazenados e utilizados diversas vezes durante uma unica sessao
do usuario.
Alem do controle de acesso, a API tambem permite o cadastro de usuarios por uma
pagina padrao gerada automaticamente e que pode ser acessada somente utilizando
as credencias de administrador da API. Outra facilitacao e a criacao de uma rota
de acesso, onde dado o usuario e a senha, tem-se o Token de acesso retornado.
Seguindo pelo codigo, pode-se ver a definicao de query set. Esta variavel recebe o
conjunto de objetos que serao acessados, isto e, a atribuicao indica em qual tabela
do banco sera feita a busca, insercao, alteracao ou exclusao. Por fim, uma parte
crucial e a serializer class que informa qual campo do Modelo sera entregue por
aquela View. Por exemplo:
class LojaSerializer(serializers.HyperlinkedModelSerializer):
class Meta:
model = Loja
fields = (’id_loja’,’nome’,’nome_fantasia’,’cnpj’)
Neste caso, todos os campos de Loja serao entregues em formato JSON pela View.
Caso alguma chave estrangeira existisse dentro de Loja, um hyperlink de acesso
seria provido pela API, por isso serializer.HyperlinkedModelSerializer. Porem, em
28
algumas situacoes e util que informacoes dessa chave estrangeira sejam acessadas
em conjunto, como por exemplo no caso de Vendas:
class VendasSerializer(serializers.HyperlinkedModelSerializer):
id_loja_loja = LojaSerializer()
id_cliente_cliente = ClienteSerializer()
class Meta:
model = Vendas
fields = (’id_venda’,’id_cliente_cliente’,’id_loja_loja’,’data’,’hora’)
Nesse caso e interessante que as informacoes do cliente e da loja em que a venda
ocorreu venham em conjunto em um unico cursor, otimizando a velocidade do pro-
cesso. No entanto, e importante lembrar que a informacao adicional incrementa o
tamanho do dado entregue, podendo comprometer o trafego de dados.
Apesar da DRF ajudar bastante com a implementacao dos metodos HTTP, em
alguns casos ainda e necessario a customizacao de alguns deles. Para isso, esta
ferramenta permite que eles sejam sobrescritos. Por exemplo, no caso de atualizacao
das informacoes do cliente pelo aparelho celular, deseja-se permitir que estejam
disponıveis dados como email, cpf, telefone, nome e data de nascimento. No entanto,
nao e desejavel que se alterem dados como a ultima compra, ja que esta e inserida
automaticamente pelo extrator. Sendo assim a solucao pode ser vista a seguir:
class ClienteViewSet (viewsets.ModelViewSet):
authentication_classes = (TokenAuthentication,)
permission_classes = (IsAuthenticated,)
queryset = Cliente.objects.all()
serializer_class = ClienteSerializer
filter_backends = (django_filters.rest_framework.DjangoFilterBackend,)
filter_class = ClienteFilter
def update(self, request, *args, **kwargs):
instance = Cliente.objects.get(pk=request.data[’id_cliente’])
instance.nome = request.data[’nome’]
instance.telefone = request.data[’telefone’]
29
instance.data_nascimento = request.data[’data_nascimento’]
instance.endereco = request.data[’endereco’]
instance.cpf = request.data[’cpf’]
instance.email = request.data[’email’]
instance.observacao = request.data[’observacao’]
instance.sexo = request.data[’sexo’]
serializer = ClienteSerializer(data=request.data)
serializer.is_valid(raise_exception= True)
self.perform_update(serializer)
return Response(serializer.data)
Perceba que nesse ponto, todos os dados cadastrais sao atualizados vindos do
pedido (request) de update. No fim e feita uma validacao de campos pelo Serializer,
que captura situacoes como o caso da tentativa de insercao de um tipo de campo
nao adequado. Por fim, o modelo e retornado como resposta indicando que tudo
ocorreu corretamente.
Ainda nessa implementacao uma outra diferenca pode ser notada da implementacao
da View de Lojas: o filtro. O filtro tambem e uma opcao disponıvel no Django Rest
Framework, estando desabilitado como padrao. No caso, quando habilitado, e ne-
cessario definir uma classe que especifique os campos que poderao ser utilizados
como parametros de busca. Desta forma, tem-se:
class ClienteFilter(django_filters.rest_framework.FilterSet):
primeira_vez = django_filters.BooleanFilter(name="primeira_vez")
cpf = django_filters.CharFilter(name="cpf")
nome = django_filters.CharFilter(name="nome", lookup_expr=’icontains’)
email = django_filters.CharFilter(name="email", lookup_expr="icontains")
bairro = django_filters.CharFilter(name="endereco", lookup_expr="icontains")
dayStart =
django_filters.NumberFilter(name="data_nascimento", lookup_expr=’day__gte’)
dayEnd =
django_filters.NumberFilter(name="data_nascimento", lookup_expr=’day__lte’)
monthStart =
30
django_filters.NumberFilter(name="data_nascimento", lookup_expr=’month__gte’)
monthEnd =
django_filters.NumberFilter(name="data_nascimento", lookup_expr=’month__lte’)
class Meta:
model = Cliente
fields = [’primeira_vez’,’cpf’,’nome’,’bairro’,’email’,
’dayStart’,’dayEnd’,’monthStart’,’monthEnd’]
O atributo fields e um tuple que indica os campos que poderao ser passados como
parametros de filtro de pesquisa dentro de um GET. Acima da definicao desses
atributos da classe Meta, tem-se a definicao de cada filtro que depende do tipo de
campo (Number, Char, Integer...). Em seguida, e especificado em name o campo
do modelo que sera comparado na busca e em lookup expr o tipo de comparacao.
A vantagem de um filtro como esse e poder entregar um dado bem especıfico, como
por exemplo, todos os clientes que fazem aniversario em um perıodo especıfico, ou
ainda, todos que morem num bairro especıfico.
Por fim, o ultimo passo na construcao do Backend e a definicao das rotas de acesso
para cada View. Para isso, e necessario definir um endereco de acesso e liga-lo a
View especıfica no arquivo urls.py da seguinte maneira:
router.register(r’api/lojas’, views.LojaViewSet)
Como resultado, a rota sera adicionada ao domınio de hospedagem da API e
podera se acessada por um link do tipo: ’http://dominio.exemplo/api/lojas’ pelos
diversos metodos HTTP habilitados. Recebe-se como resposta o seguinte JSON:
[
{
"id_loja": 1,
"nome": "Leblon",
"nome_fantasia": "Loja LEBLON",
"cnpj": "00000000000000"
},
31
{
"id_loja": 2,
"nome": "Arpoador",
"nome_fantasia": "Loja ARPOADOR",
"cnpj": "00000000000000"
},
{
"id_loja": 3,
"nome": "Barra",
"nome_fantasia": "Loja BARRA",
"cnpj": "00000000000000"
},
{
"id_loja": 0,
"nome": "LOJA PDV TESTE",
"nome_fantasia": "PDV TESTE",
"cnpj": "00000000000000"
},
{
"id_loja": 4,
"nome": "Botafogo",
"nome_fantasia": "Loja BOTAFOGO",
"cnpj": "18000626000597"
},
{
"id_loja": 5,
"nome": "Centro",
"nome_fantasia": "Loja CENTRO",
"cnpj": "00000000000000"
}
]
32
3.6 Aplicacao Android
Nesse projeto a aplicacao Android sera essencialmente utilizada como Frontend
para exibicao, formatacao e envio de dados para o Backend. Nesse sentido, uma
abordagem logica e especificar os passos necessarios para acessar os dados, assim
como na experiencia do usuario do aplicativo.
Sabendo que para acessar os dados e necessario que o usuario esteja autenticado
pelo Backend e que possua um Token de acesso, a primeira tela necessariamente deve
ser uma tela de autenticacao. Alem disso, tambem e necessario que o usuario indique
em qual loja esta trabalhando para que receba as notificacoes corretas. Sendo assim,
utilizando a IDE do Android Studio, construiu-se a tela a seguir para atender essa
necessidade:
Figura 3.5: Tela de Login da Aplicacao Android
33
Na imagem podem ser vistas duas caixas de texto, respectivamente de e-mail para
acesso e de senha. Em seguida, existe uma caixa de rolagem onde pode ser escolhida
a loja da qual o funcionario deseja receber notificacoes. Por fim, um botao que
aciona o acesso. A definicao deste layout de tela e especificada num documento
XML, seguindo regras especıficas para o desenvolvimento de aplicacoes Android. A
exemplificacao deste arquivo e importante para que se entenda a ligacao entre a
parte logica da aplicacao (chamadas de activities) e sua parte visual. Observe o
caso do elemento visual do botao:
<Button
android:id="@+id/email_sign_in_button"
style="?android:textAppearanceSmall"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_marginTop="16dp"
android:text="@string/action_sign_in"
android:textStyle="bold"
android:layout_weight="2.25" />
Neste trecho, pode-se ver varios atributos que definem as caracterısticas fısicas do
botao, como: posicao, margem, aparencia e tamanho. Alem disso, outro atributo
importante e o id, que e um nome identificador que sera utilizado para conectar o
botao visual com sua acao logica, da seguinte forma:
Button mEmailSignInButton =
(Button) findViewById(R.id.email_sign_in_button);
mEmailSignInButton.setOnClickListener(new OnClickListener() {
@Override
public void onClick(View view) {
attemptLogin();
}
});
34
Nesse trecho, findViewById e utilizado para encontrar o botao visual. Em seguida,
apos sua atribuicao, e utilizado o metodo setOnclickListener para criar uma acao
ao botao. Para essa situacao, quando o usuario clicar no botao, a funcao de login e
acionada. Sempre se deseja atribuir uma acao a um elemento visual da aplicacao,
variando apenas o tipo de objeto, porem isto e feito reescrevendo o metodo onClick
com uma nova acao para ser acionada.
Nesse caso, ao pressionar o botao a funcao attemptLogin() e acionada. Esta funcao
pode ser dividida em duas etapas: validacao de campos e troca de informacoes com
o servidor. Em sua primeira parte temos:
private void attemptLogin() {
// Reseta erros.
mEmailView.setError(null);
mPasswordView.setError(null);
// Armazena as os valores dos elementos graficos
// em variaveis
String email = mEmailView.getText().toString();
String password = mPasswordView.getText().toString();
cancel = false;
focusView = null;
// Valida campo de senha
if (!TextUtils.isEmpty(password) && !isPasswordValid(password)) {
mPasswordView.setError(getString(R.string.error_invalid_password));
focusView = mPasswordView;
cancel = true;
}
// Valida campo de e-mail
if (TextUtils.isEmpty(email)) {
mEmailView.setError(getString(R.string.error_field_required));
focusView = mEmailView;
cancel = true;
} else if (!isEmailValid(email)) {
35
mEmailView.setError(getString(R.string.error_invalid_email));
focusView = mEmailView;
cancel = true;
}
if (cancel) {
// Caso algum erro tenha acontecido;
// Seleciona o foco na tela e exibe mensagem de erro.
focusView.requestFocus();
} else {
//Inicia um spinner enquanto tenta se conectar
showProgress(true);
(...)
Como se pode constatar, o codigo comeca primeiro validando os campos. Para
isso e necessario converte-los de campos de entrada para Strings, sendo esta tarefa
realizada pelos metodos ”.getText()”(pega o texto da caixa) e ”.toString()”(converte
para o tipo String). Na parte do campo de senha, esse primeiramente verifica se o
campo esta vazio e se a senha e valida. A funcao de verificacao de senha se resume
apenas a verificar se essa contem o mınimo de 4 caracteres, retornando falso caso
negativo e verdadeiro caso positivo. Em seguida, a validacao do e-mail e realizada
de modo parecido. No entanto a funcao apenas busca por uma extensao especıfica
de e-mail da rede de hamburguerias. Em caso de qualquer uma das falhas, a variavel
booleana altera o seu estado para verdadeiro e o processo de login e interrompido.
Caso positivo, a segunda parte e enviar a senha e usuario para o Backend validar.
Utilizando a biblioteca ionkoush para a administracao dos pedidos HTTP, o seguinte
codigo foi escrito:
JsonObject json = new JsonObject();
json.addProperty("username",email);
json.addProperty("password",password);
Ion.with(LoginActivity.this)
.load("http://"+ipAddress+"/api-token-auth/")
.setJsonObjectBody(json)
36
.asJsonObject()
.setCallback(new FutureCallback<JsonObject>() {
@Override
public void onCompleted(Exception e, JsonObject result) {
if(e != null){
Toast.makeText(LoginActivity.this, "Erro de Login: " + e,
Toast.LENGTH_LONG).show(); //cria balao de texto na view indicada
return;
}
if (result.get("token") != null && result.get("non_field_errors") == null) {
String accessToken = result.get("token").getAsString();
intent =
new Intent(getApplicationContext(), daySummaryActivity.class);
Toast.makeText(LoginActivity.this, "Cara cracha...OK!",
Toast.LENGTH_LONG).show();
//adiciona o token e loja para a prox activity
intent.putExtra("token","Token "+accessToken);
intent.putExtra("idLoja",""+(mLojaSpinner.getSelectedItemPosition()));
//salvando ultimo email usado e loja
SharedPreferences settings =
getSharedPreferences("com.example.ttb.encantt", Context.MODE_PRIVATE);
//salvando dados de login
SharedPreferences.Editor editor = settings.edit();
editor.putString("email",mEmailView.getText().toString());
editor.putInt("idLoja",mLojaSpinner.getSelectedItemPosition());
editor.commit();
startActivity(intent); // inicia proxima tela
}
if(result.get("non_field_errors").
getAsString().equals("Unable to log in with provided credentials.")){
Toast.makeText(LoginActivity.this,
"Usuario e senha n~ao condizem.", Toast.LENGTH_LONG).show();
37
cancel = true;
intent = new Intent(getApplicationContext(), LoginActivity.class);
startActivity(intent);
return;
}
}
});
}
Primeiro, um objeto do tipo JsonObject e criado para encapsular o usuario e
senha em um JSON. Em seguida, esse JSON e enviado para a rota de login ”api-
token-auth”.Apos receber a resposta do servidor, o trecho onComplete e executado.
Dentro dessa parte do codigo, e verificado primeiro se algum erro aconteceu, caso
positivo um balao surge na tela informando o erro. Em seguida, caso nenhum erro
tenha ocorrido, e checado se na resposta as credenciais sao informadas como validas
ou nao. Caso nenhum tipo de erro ocorra, o login utilizado e a loja selecionada sao
salvos na tela inicial para futuros logins utilizando SharedPreferenes.
A parte final deste processo e chamar a segunda tela do aplicativo, a qual mostra
as ultimas compras da loja. Como nesta outra tela precisaremos ainda acessar
informacoes das vendas numa loja especıfica, e necessario utilizar o token de acesso
e saber qual loja foi escolhida para acesso. Esses dados sao passados para nova
Intent utilizando o metodo ”putExtras”como pode ser visto no codigo.
A proxima tela da aplicacao pode ser chamada de tela principal e e usada para
guiar os atendentes em lojas, mostrando quais foram as ultimas compras numa janela
de tempo que pode ser escolhida. E nessa tela tambem que se inicia a atividade de
notificacoes, que busca de tempos em tempos uma nova venda. A tela e a notificacao
se organizam da seguinte forma:
38
Figura 3.6: Notificacao e Tela de Principal
Na notificacao, pode-se ver a direita o ıcone da aplicacao e na esquerda uma
serie de frases que informam o nome do Cliente, o nome da aplicacao e uma frase
informativa de que uma nova compra ocorreu. Ja na imagem da tela principal,
seguindo pela numeracao: (1) nome do aplicativo, (2) botao para menu de opcoes, (3)
nome da loja e (4) informacao basica da venda. Esta ultima, pode variar dependendo
do perfil do cliente: caso este seja cadastrado, o ıcone de perfil se torna dourado e
em caso negativo, cinza. Ainda nesta parte, pode-se ver a hora da venda e ultima
visita do cliente na rede. Em caso de primeira vez na rede de hamburguerias, ou de
visita nao identificada, uma mensagem e escrita no lugar da data.
Para obter essas informacoes, o aplicativo executa periodicamente um novo pedido
GET para o Backend na rota de vendas. Nesse pedido sao passados os parametros
como data, hora inicial e final e loja. Como pode ser visto a seguir:
jsonResult = Ion.with(daySummaryActivity.this)
.load("GET","http://"+ipAddress+"/api/vendas/?")
.setHeader("Authorization",getIntent().getExtras().getString("token"))
.addQuery("format","json")
.addQuery("data",dataInicial)
.addQuery("horaInicial",horaInicial)
39
.addQuery("horaFinal",horaFinal)
.addQuery("id_loja_loja",idLojaString)
.asJsonArray()
.setCallback(new FutureCallback<JsonArray>() {
@Override
public void onCompleted(Exception e, JsonArray result) {
(...) //exibicao da lista caso em caso de sucesso
}
Como resposta, o servidor devolve um JSON com as informacoes de cada cliente
da seguinte maneira:
{
"id_venda": 80679,
"id_cliente_cliente": {
"id_cliente": 29416,
"nome": "TARIQUE PIMENTEL",
"telefone": "219999999",
"cpf": "000000000000",
"endereco": "Endereco Cliente",
"primeira_vez": false,
"data_nascimento": "20/11/1990",
"observacao": "Observacao Teste",
"email": "[email protected]",
"sexo": "M",
"id_penultima_compra": {
"id_venda": 69215,
"id_loja_loja": {
"id_loja": 4,
"nome": "Botafogo",
"nome_fantasia": "TTBURGER BOTAFOGO",
"cnpj": "18000626000597"
},
40
"data": "2017-07-15",
"hora": "00:13:42"
},
"id_ultima_compra": {
"id_venda": 80679,
"id_loja_loja": {
"id_loja": 4,
"nome": "Botafogo",
"nome_fantasia": "TTBURGER BOTAFOGO",
"cnpj": "18000626000597"
},
"data": "2017-07-30",
"hora": "12:04:27"
}
},
(... proximas vendas no mesmo formato...)
Para obter as vendas em tempo real, uma Thread foi criada e definida para ser
executada de perıodo em perıodo, que pode ser definido pelo usuario no menu de
configuracoes do aplicativo. Ao receber as vendas, a ultima venda da lista recebida
e comparada com a anterior. Caso elas sejam divergentes, a notificacao e acionada.
Para a definicao do perıodo de poolling da informacao, basta o usuario clicar no
menu no canto superior e selecionar a opcao configuracoes.
O menu de opcoes oferece algumas possibilidades ao atendente da loja para fa-
cilitar seu atendimento. O primeiro deles, forca o aplicativo a recarregar a tela
principal, buscando assim por novas vendas sem a necessidade de esperar o tempo
de poolling. Ainda no menu, ha opcao de sair que apaga o token de acesso e guia o
usuario para tela de login. Por fim, tem-se o item configuracoes que leva o atendente
para a tela de configuracoes.
Na tela de configuracoes ha quatro opcoes:
41
Figura 3.7: Menu de opcoes e Tela de Configuracoes
Loja: Permite ao usuario mudar a loja em que esta conectado.
Taxa de Atualizacao: Permite alterar a taxa de Poolling das informacoes,
podendo escolher: 5, 10 ou 15 segundos.
Janela de Tempo: Permite alterar a janela de tempo na busca por venda,
podendo escolher: 30, 45, 60, 120, 240 ou 360 minutos.
Modo Desenvolvedor: Nessa configuracao ha apenas a opcao de habilitar ou
desabilitar. Quando habilitado o usuario conecta-se numa data e loja fictıcia onde
pode-se testar todas as funcionalidades do aplicativo sem que se inseriam dados
inconsistentes na base. A opcao foi pensada para ser utilizadas em teste de software
e treinamento de novos funcionarios.
Ao clicar no botao salvar, o aplicativo retorna para a tela principal. A ultima
funcionalidade presente na tela principal e a chamada da tela de resumo do cliente.
Esta tela pode dividida em quatro partes: informacoes do cliente (1), compra do
dia (2), historico de relacionamentos (3) e historico de compras (4). Na primeira
parte, pode ser visto o nome do cliente e sua data de nascimento. Ao clicar no
42
sımbolo de avatar, uma popup window se expande exibindo a observacao que ja foi
feita por algum dos atendentes sobre o cliente.
Figura 3.8: Tela de Resumo do Cliente
Alem disso, um clique no botao guia conduz a tela onde o funcionario pode editar
as informacoes cadastrais do cliente:
Figura 3.9: Tela de Edicao do Cliente
43
Continuando pela tela, pode-se ver os itens da compra. Essa parte e essencial
para que o atendente possa saber o que o cliente consumiu durante a visita, assim
como realizar perguntas sobre o que este achou de cada um dos itens. Logo apos
efetuar estas perguntas, o funcionario tem a opcao de adicionar o comentario feito
pelo cliente a compra clicando em inserir observacoes.
Figura 3.10: Tela para Inserir informacoes
Nesta parte, o usuario pode escolher pela barra de opcoes tres tipos de co-
mentarios: Reclamacao, Elogio ou Comentario Pessoal. Logo abaixo da barra de
opcoes, esta o campo texto onde o usuario deve escrever a informacao passada pelo
cliente. Terminando a escrita e ao clicar o botao salvar, o aplicativo recarrega a tela
de Resumo do Cliente e retorna a esta.
Ao retornar a tela anterior apos a adicao do comentario, este passa a aparecer
juntamente aos comentarios ja presentes no historico de relacionamento. Caso o
usuario queira verificar algum dos comentarios, ou edita-los, basta clicar num dos
elementos da lista.
44
Figura 3.11: Tela para Inserir Informacoes de Relacionamento
Nesta secao, pode-se encontrar algumas informacoes que ajudam o funcionario
em loja a entender o que se passava no dia. Primeiro, as informacoes gerais da
compra como: cliente, data, hora e qual funcionario incluiu aquele comentario. Em
seguida, os itens que o cliente consumiu naquela data auxiliam a entender melhor
o comentario caso seja especıfico sobre algum dos produtos. Por fim, o texto do
comentario finaliza as informacoes daquela experiencia. Caso necessario, o atendente
pode editar ou excluir o comentario, contanto que esse seja seu criador. O bloqueio
e feito comparando o email de login do funcionario com o email de quem escreveu a
informacao:
editarBotao.setOnClickListener(new View.OnClickListener(){
@Override
public void onClick(View view){
//valida usuario que fez comentario e email logado
if (getIntent().getExtras().getString("emailAtendente")
.equals(getIntent().getExtras().getString("emailLogado"))) {
intent =
new Intent(saleCommentActivity.this, insertObsActivity.class);
//passando valores para serem utilizados na prox tela
45
intent.putExtra(
"comentarioVenda",getIntent().getExtras().getString("comentarioVenda"));
intent.putExtra(
"tipoComentario",getIntent().getExtras().getString("tipoComentario"));
intent.putExtra("action","editar"); //flag pra dizer que e uma edic~ao
intent.putExtra(
"token", getIntent().getExtras().getString("token"));
intent.putExtra(
"idVendaDoDia", getIntent().getExtras().getString("idVenda"));
intent.putExtra(
"nomeCliente", getIntent().getExtras().getString("nomeCliente"));
intent.putExtra(
"idCliente", getIntent().getExtras().getString("idCliente"));
intent.putExtra(
"cpfCliente",getIntent().getExtras().getString("cpfCliente"));
intent.putExtra(
"idComentario",getIntent().getExtras().getString("idComentario"));
intent.putExtra(
"idFuncionario",getIntent().getExtras().getString("idFuncionario"));
intent.putExtra(
"emailLogado",intent.getExtras().getString("emailLogado"));
startActivity(intent); //inicia a proxima tela
finish(); //remove tela da memoria apos execucao
}
else{
//cria balao de texto na view indicada informando erro
Toast.makeText(
saleCommentActivity.this,
"N~ao mexe nas coisas dos outros!",
Toast.LENGTH_LONG).show();
}
}
46
});
Novamente, ao concluir uma edicao ou excluir o comentario, o aplicativo recarrega
a pagina de Resumo do Cliente. Nesta, o ultimo segmento restante sao as ultimas
compras do cliente. A interacao dessa lista se assemelha da mesma forma que a dos
comentarios. No entanto, a tela que e chamada ao clicar na compra difere em sua
parte inferior que inclui todos os comentarios anotados naquela venda:
Figura 3.12: Tela de Detalhe de Compra
3.7 Analise de Resultados
Neste secao final serao apresentados os resultados obtidos apos os primeiros meses
de implantacao do projeto. Alem disto, uma analise detalhada dos dados obtidos
sera feita de modo a medir o eficiencia na extracao, armazenamento e tambem um
estudo a parte sobre a aceitacao do aplicativo pelos usuarios.
Para a primeira analise, a abordagem utilizada sera uma comparacao das vendas
armazenadas pela empresa de ponto de vendas e as extraıdas e armazenadas no
47
banco de dados, assim como a quantidade de hamburgueres vendidos por cada loja.
Comparando as vendas no perıodo de (01/06/2017) a (31/06/2017) tem-se:
Dados de Vendas
Loja Total R$
(Extra-
tor)
Total R$
(PDV)
Acuracia Hamburgueres
(Extrator)
Hamburgueres
(PDV)
Leblon 429.788,50 429.684,50 99,97% 7.278 7.276
Arpoador 432.490,82 434.082,32 99,96% 7.117 7.144
Barra 325.357,76 325.386,06 99,99% 5.412 5.413
Botafogo 436.546,08 436.910,68 99,99% 7.451 7.455
Centro 156.862,44 162.741,44 96,39% 2.774 2.821
Como pode-se ver, a maioria das lojas atingiu uma acuracia de 99,9% de extracao
dos dados das vendas realizadas, exceto pela loja do centro. O motivo das perdas
de informacao e conhecido e ocorre da seguinte maneira: ao realizar uma venda,
caso a loja esteja sem internet o extrator salva numa fila na memoria as informacoes
da compra e espera pelo retorno desta para reenviar os dados. Caso, o atendente
ou algum tipo de problema reinicie a maquina durante esse processo as informacoes
sao perdidas pelo extrator. Observe que no caso da loja do Leblon ha um erro de
124 R$, isto nao prova que o extrator enviou duas vendas iguais, ja que tambem
ha possibilidade dele nao ter corrigido uma compra cancelada. A quantidade de
hamburgueres auxilia a identificar a quantidade de vendas perdidas pois em sua
maioria as vendas ocorrem com apenas um hamburguer por pedido, nesse caso
poderıamos estimar um total de 77 vendas perdidas em 30109 vendas realizadas.
Outra parte interessante, mas que nao pode ser comparavel a nenhum dado an-
terior e o perfil de cliente captado apos o perıodo de implementacao. Antigamente,
a marca pouco sabia de informacoes importantes como divisao de genero dos seus
clientes, faixa etaria e o tıquete medio referente a cada fatia desses segmentos. Apos
a analise, utilizando os dados pode-se chegar aos seguintes resultados:
48
Figura 3.13: Recorrencia por Genero
Figura 3.14: Tıquete Medio por Genero e Faixa Etaria
Por fim, tambem foi medido o total de comentarios realizados por cada atendente
de loja e o percentual de cadastros feitos em relacao ao total de vendas durante as
duas primeiras semanas de implementacao do projeto. Esses parametros ajudam a
dar uma ideia da frequencia de uso do aplicativo pelos atendentes, como pode ser
visto a seguir:
49
Figura 3.15: Percentual de Cadastros Completos por Venda em cada Loja
Figura 3.16: Total de Comentarios feitos por Atendente
Analisando esses dados, esperava-se um numero de cadastros maior do que o
realizado. Ao questionar isso para os atendentes, muitos argumentaram a dificuldade
de convencer os clientes a darem suas informacoes. Alem disso tambem foi dito pelos
usuarios do sistema que a quantidade de informacoes pedidas era muito grande,
o que dificultava obter cadastros completos. Em lojas como Leblon, os gerentes
questionaram o perfil do comprador como uma dificuldade extra.
50
Ja ao observar a quantidade de comentarios, ve-se que essa deixou-se a desejar.
Uma possibilidade para isso e que os usuarios ainda estavam se acostumando com
um novo processo a ser introduzido e as expectativas e que os numeros aumentem
a medida que o aplicativo ganhe novas funcionalidades, se tornando cada vez mais
essencial.
51
Capıtulo 4
Conclusoes
4.1 Consideracoes Finais
Para as consideracoes finais deste projeto e importante relembrar primeiramente
as motivacoes que levaram a sua arquitetura. Inicialmente, a rede de hamburgueria
pouco sabia sobre o perfil de seus clientes e seus habitos de consumo. A falta dessas
informacoes causava uma intensa dificuldade em se aproximar dos clientes durante
as suas visitas em loja, o que nao era compatıvel com a identidade da marca.
Antes da execucao do projeto, dificilmente um atendente poderia identificar um
cliente recorrente na loja e ainda mais improvavel que se recordasse das opcoes de
menu escolhidas. Alem disso, as recordacoes sobre a experiencia vivida pelo cliente
dificilmente eram lembradas o que deixava o atendimento totalmente impessoal o
que nao ajudava a gerar valor da marca.
Afim de sanar esse problema foi iniciado este projeto e no fim deste pode-se ver
grandes avancos. Primeiramente, hoje a empresa tornou-se capaz de armazenar
todos os dados de compras e clientes, alem de poder correlacionar essas informacoes
e utiliza-las das mais diversas maneiras, nao somente durante o atendimento, mas
tambem para analises nos setores estrategicos como: marketing, logıstica e compras.
A razao dessa flexibilidade pode ser atribuıda a distribuicao das informacoes do
banco utilizando um Backend, ja que os dados podem ser recebidos em formatos
JSON e facilmente processados por outras aplicacoes.
52
Para exemplificar melhor como a ferramenta pode auxiliar no atendimento use-
mos como exemplo um cliente que teve um experiencia ruim em algumas das lojas
da rede. Imagine, que nessa visita o consumidor venha reclamar que a carne do
seu hamburguer veio mal passada, diferente do especificado por ele no pedido. O
ideal nesse ponto e que numa proxima visita, apos a realizacao do pedido, o aten-
dente informasse ao chapeiro para se certificar que a carne viesse no ponto correto
dessa vez. Antigamente, um processo desse tipo era totalmente improvavel consi-
derando o fluxo de clientes e o tempo medio de retorno das pessoas na loja, porem
apos a implementacao do projeto com apenas dois cliques o atendente pode obter
essa informacao e se certificar que o cliente tenha seu hamburguer conforme sua
preferencia.
Ainda utilizando o mesmo exemplo, imagine que o mesmo erro aconteca multiplas
vezes na mesma loja. Nesse caso, utilizando o Backend para filtrar as reclamacoes
de uma loja especıfica, o problema pode ser identificado rapidamente. Apos a iden-
tificacao, o setor responsavel pelo treinamento de funcionarios poderia contactar o
chapeiro e corrigir a falha nesse processo. Esse e apenas um exemplo dos diversos
casos que podem ser auxiliados devido a implementacao do projeto e que antiga-
mente passavam despercebidos no dia a dia das lojas, provando que a flexibilidade
do sistema implementado que e capaz tanto de melhorar na frente de atendimento
quanto nos processos por tras da experiencia do cliente na loja. Outros casos de uso
tambem podem ser citados como: analises de produtos mais vendidos, regiao com
maiores numeros de clientes para abertura de novas lojas e estrategias de marketing
personalizadas para cada cliente.
4.2 Trabalhos Futuros
Olhando para o futuro, ve-se alguns pontos ainda podem ser melhorados em novas
atualizacoes, tanto para a melhora de desempenho quanto em novas funcionalidades
para o sistema. Tais melhorias sao importantes para mostrar ao usuarios que seus
feedbacks tem sido ouvidos e assim estimula-los a utilizar cada vez mais a aplicacao
no seu dia a dia.
53
Na parte de desempenho, as medidas a serem tomadas mais cruciais se encontram
no extrator de dados e na aplicacao. No caso do extrator de dados, algumas rotas de
acesso poderiam ser mais especıficas para cada tela da aplicacao Android, reduzindo
assim o tamanho das informacoes trafegadas. Por exemplo no caso da lista de
clientes na loja o Backend entrega informacoes que nao sao utilizadas naquela parte
da aplicacao, sendo desnecessarias. Isto pode ser visto observando a imagem da tela
da aplicacao e comparando com os dados entregues pelo Backend. Na tela tem-se:
nome do cliente, data da ultima visita e horario da compra, enquanto no JSON
enviado podemos encontrar todos os dados cadastrais do cliente, loja da compra e
venda.
Na tela utilizam-se apenas os seguintes dados: nome do cliente, hora da compra,
data da ultima visita e o indicador de primeira vez (em caso de primeira compra).
Enquanto isso, o Backend entrega todas as informacoes da venda atual e anterior,
assim como os dados completos dos clientes e da loja em que esta.
Olhando para a aplicacao Android alguns pontos podem ser melhorados. Um
deles por exemplo e o bloqueio de edicao e exclusao dos comentarios. Esse tipo de
bloqueio nao deveria ficar no front da aplicacao pois nao impede de fato que alguem
envie o pedido HTTP de excluir ou editar. Como solucao, essa analise deveria ser
movida para o proprio Backend impedindo de fato a modificacao baseada no usuario
que fez o pedido e em quem escreveu o comentario.
Ainda na aplicacao Android, outro ponto que poderia melhorar o desempenho
e a criacao de uma atividade global para guardar os dados durante as trocas de
atividades. Atualmente esses dados sao passados como dados extras na criacao das
telas, porem devido ao numero grande de informacoes o codigo fica extremamente
extenso e facilmente corrompıvel no caso de esquecimento da insercao de um desses
argumentos.
Uma classe de atividade global faria com que todas essas informacoes fossem
naturais de todas as outras atividades, atuando da seguinte forma:
public class MyApplication extends Application {
54
private String someVariable;
public String getSomeVariable() {
return someVariable;
}
public void setSomeVariable(String someVariable) {
this.someVariable = someVariable;
}
}
Podendo ser acessada da seguinte maneira:
// set
((MyApplication) this.getApplication()).setSomeVariable("foo");
// get
String s = ((MyApplication) this.getApplication()).getSomeVariable();
Considerando modificacoes futuras relativas a novas funcionalidades a mais pedida
pelos usuarios do aplicativo seria a busca por clientes. Esse pedido surgiu numa
maneira dos atendentes poderem agir num pos venda, entrando em contato com o
cliente e gerando retorno para a loja.
Um outro pedido feito para o sistema foi uma ferramenta de visualizacao dos
dados. Atualmente todos os dados sao visualizados no Excel conectando-se direta-
mente no banco de dados, um procedimento geralmente lento. Uma solucao nesse
caso seria a criacao de uma plataforma web com graficos interativos que ajudariam
nas tomadas de decisoes dentro da empresa.
55
Referencias Bibliograficas
[1] KHALID RABABAH, H. M., IBRAHIM, H., “Customer Relationship Mana-
gement (CRM) Processes from Theory to Practice: The Pre-implementation
Plan of CRM System”, International Journal of e-Education, e-Business, e-
Management and e-Learning, v. 1, 2011.
[2] LUN ZHANG, JINLIN LI, Y. W., “Customer Relationship Management System
Framework Design of Beijing Rural Commercial Bank”, IEEE International
Conference on Service Operations and Logistics, and Informatics (SOLI 2008),
pp. 97–101, 2008.
[3] LUN ZHANG, JINLIN LI, Y. W., “Customer Relationship Management: Emer-
ging Practice, Process, and DisciplineCustomer Relationship Management Sys-
tem Framework Design of Beijing Rural Commercial Bank”, Journal of Econo-
mic and Social Research, v. 3, pp. 1–43, 2001.
[4] WERNER REINARTZ, MANFRED KRAFFT, W. D. H., “The Customer
Relationship Management Process: Its Measurement and Impact on Perfor-
mance”, Journal of Marketing Research, v. 41, pp. 293–305, 2004.
[5] PLAKOYIANNAKI, E., TZOKAS, N., “Customer relationship management:
A capabilities portfolio perspective”, Journal of Database Marketing, v. 9,
pp. 228–237, 2002.
[6] PAYNE, A., FROW, P., “A Strategic Framework for Customer Relationship
Management”, Journal of Marketing, v. 69, pp. 167–176, 2004.
[7] AVAZZADEH, E., KARAMI, A., “Customer Relationship Management: Emer-
ging Practice, Process, and Discipline”, Journal of Economic and Social Rese-
arch, v. 3, pp. 1–34, 2001.
56
[8] IBRAHIM ALI, A. Y. C., HOONG, C. S., “The Role of Fast-Food Websites
in Managing Customer Relationships”, International Journal of e-Education,
e-Business, e-Management and e-Learning,, v. 2, 2012.
[9] SALEEBY, J. E., “Examining the Relationship between Service Quality
and Customer Loyalty in Lebanese Restaurants”, International Journal of e-
Education, e-Business, e-Management and e-Learning,, v. 2, 2012.
[10] ILEANA ELIZABETH RUVALCABA RIVAS, J. S.-G., MEJIA-TREJO, J.,
“THE CUSTOMER RELATIONSHIP MANAGEMENT (CRM) IN THE ME-
XICAN RESTAURANT INDUSTRY, THE CASE OF JALISCO STATE”, In-
ternational Journal of Sale s, Retailing and Marketing, v. 4, pp. 103–122, 2015.
[11] AVAZZADEH, E., KARAMI, A., “Data analysis and customer relationship
management (CRM) in the restaurant industry”, Sindhological Studies, v. 1,
pp. 99–106, 2017.
[12] ECKEL, B., Python 3 Patterns, Recipes and Idioms, chapter PART III: Pat-
terns, New York, pp. 129–154, 2008.
[13] TRUONG, D. D., “How Cloud Computing Enhances Competitive Advantages:
A Research Model for Small Businesses”, The Business Review, Cambridge,
v. 15, 2010.
[14] STONEBRAKER, M., “SQL Databases v. NoSQL Databases”, Communicati-
ons of the ACM, v. 53, 2010.
57
