Proposta e desenvolvimento de um protótipo de um sistema gerenciador de pipeline comercial para pequenas empresas

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ

DEPARTAMENTO ACADÊMICO DE INFORMÁTICA

CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO

ERIK FRANCO LUHM

PROPOSTA E DESENVOLVIMENTO DE UM PROTÓTIPO DE UM

SISTEMA GERENCIADOR DE PIPELINE COMERCIAL PARA

PEQUENAS EMPRESAS

TRABALHO DE CONCLUSÃO DE CURSO

CURITIBA

2015

ERIK FRANCO LUHM

PROPOSTA E DESENVOLVIMENTO DE UM PROTÓTIPO DE UM

SISTEMA GERENCIADOR DE PIPELINE COMERCIAL PARA

PEQUENAS EMPRESAS

Trabalho de conclusão de curso apresentado à disciplina de Trabalho de conclusão de Curso 2, do curso superior de Bacharelado em Sistemas de Informação do Departamento de Informática – DAINF – da Universidade Tecnológica Federal do Paraná – UTFPR, como requisito parcial para obtenção do título de Bacharel.

Orientador: Prof. Dr. Paulo Cézar Stadzisz

CURITIBA

2015

TERMO DE APROVAÇÃO

(A SER FORNECIDA PELA SECRETARIA DO CURSO)

PROPOSTA E DESENVOLVIMENTO DE UM PROTÓTIPO DE UM SISTEMA GERENCIADOR DE PIPELINE COMERCIAL PARA PEQUENAS EMPRESAS

por

ERIK FRANCO LUHM

Este Trabalho de Conclusão de Curso foi apresentado em 13 de Maio de 2016 como requisito parcial para a obtenção do título de Bacharel em Bacharelado em Sistemas de Informação. O candidato foi arguido pela Banca Examinadora composta pelos professores abaixo assinados. Após deliberação, a Banca Examinadora considerou o trabalho.

__________________________________ Prof. Dr. Paulo Cézar Stadzisz

Prof. Orientador

___________________________________ Prof. Marcelo Mikosz Gonçalves

Membro titular

___________________________________ Prof. Dr. João Alberto Fabro

Membro titular

- O Termo de Aprovação assinado encontra-se na Coordenação do Curso -

Ministério da Educação

Universidade Tecnológica Federal do Paraná Campus Curitiba

Diretoria de Graduações / Coordenação / Departamento Bacharelado em Sistemas de Informação

RESUMO

LUHM, Erik F. Proposta e Desenvolvimento de um Protótipo de um Sistema Gerenciador de Pipeline Comercial para Pequenas Empresas. 2016. 74 folhas. Trabalho de conclusão de Curso (Bacharelado em Sistemas de Informação) – Universidade Tecnológica Federal do Paraná. Curitiba, 2016.

Hoje em dia, cada vez mais, organizações procuram soluções para problemas específicos que tenham. Ao invés de implementar um sistema de CRM em âmbito organizacional, que teria um custo muito alto, as empresas optam por soluções em áreas estratégicas do seu negócio. Essa necessidade de um software específico é ainda mais real e palpável quando se trata de micro e pequenas empresas, que dependem de uma margem de lucro muito pequena. Um sistema de Pipeline comercial é um sistema informatizado do âmbito comercial. Ele mantém o registro de todas as vendas e também de todas as oportunidades de vendas que a empresa ou organização possui. O termo

Pipeline, em inglês, quer dizer “duto”, mais especificamente de “duto de transporte” ou

“duto de condução”. Esse termo foi adotado porque o sistema segue uma linearidade com relação ao acompanhamento que faz das oportunidades nele cadastrado. Primariamente as oportunidades são inseridas no sistema como Leads, ou oportunidades novas. O estágio seguinte na progressão é o alcance até o cliente, uma comunicação inicial. Em seguida, o contato com o cliente vira um interesse. Passa-se por uma fase de testes do produto ou serviço, até a venda ou contrato ser concluído.

Palavras-chave: Pipeline. Pipeline Comercial. Comercial. CRM. Métricas. Gestão Comercial. Processo de Venda. Protótipo.

ABSTRACT

LUHM, Erik F. Proposition and Development of a Prototype of a Sales Pipeline System for Small Companies. 2016. 74 pages. Trabalho de conclusão de Curso (Bacharelado em Sistemas de Informação) – Universidade Tecnológica Federal do Paraná. Curitiba, 2016.

Nowadays there is an increasing number of companies that seek solutions for specific problems they have. Instead of implementing an organizational-wide CRM system, companies are investing in cheaper solutions in their strategic business areas. This need is even more noticeable in micro and small companies, that thrive in a small profit margin. A Sales Pipeline is a software for commercial areas. It keeps track of all the sales, opportunities and leads a company has. Pipeline means a “duct”, more specifically a “transport duct” or a “conduction duct”. This term has been adopted because the system follows a linear path in tracking its opportunities. First, the new opportunities are registered in the system, as Leads. The next stage is the client outreach, a first line of contact with the potential client. The third stage in the progression is a dialog with the client, a further communication. Next, the contact and dialog turns into an interest by the client. Then, the potential client goes through a testing phase of the service or product and proceeds to the conclusion of the sale of signing of the contract.

Keywords: Pipeline. Pipeline Comercial. Comercial. CRM. Métricas. Gestão Comercial. Processo de Venda. Protótipo.

LISTA DE ILUSTRAÇÕES

Figura 1: Diagrama representando o Pipeline ... 17

Figura 2: Exemplo de gerenciamento de Pipeline no sistema Siebel ... 21

Figura 4: Tela de gerenciamento de Pipeline no sistema Pipedrive ... 23

Figura 5: Tela de relatório do Pipeline do sistema base ... 23

Figura 6: Tela de gerenciamento de Pipeline no sistema Nutshell ... 24

Figura 7: Tela de gerenciamento de Pipeline do sistema Podio... 25

Figura 8: Modelagem da arquitetura Model-View-Controller utilizada ... 30

Figura 9: Diagrama de Classes do Protótipo ... 32

Figura 10: Diagrama Entidade-Relacionamento ... 34

Figura 11: Diagrama de Caso de Uso - Operações de Cadastro ... 34

Figura 12: Diagrama de Caso de Uso – Pipeline Comercial ... 35

Figura 13: Diagrama de Caso de Uso - Cadastrar Oportunidade, Selecionar Gerente e Vendedor ... 36

Figura 14: Diagrama de Caso de Uso - Avançar ou Regredir Oportunidade ... 36

Figura 15: Diagrama de Caso de Uso - Consultar e Comparar Métricas ... 37

Figura 16: Diagrama de Estado – Login ... 37

Figura 17: Diagrama de Estado – Inserir Nova Oportunidade ... 38

Figura 18: Diagrama de Estado – Atualizar Oportunidade ... 38

Figura 19: Diagrama de Estado – Calcular e Exibir Métricas ... 39

Figura 20: Diagrama de Estado – Cadastrar Usuário ... 39

Figura 21: Tela Principal do Programa – Representação do Pipeline ... 40

Figura 22: Tela de Métricas e Comparação com Campos de Comparação Realçados 41 Figura 23: Tela de Login do Protótipo ... 42

Figura 24: Tela Principal do Vendedor "Seth" ... 43

Figura 25: Tela Principal do Gerente de "Seth" ... 43

Figura 26: Tela Principal do Protótipo ... 44

Figura 27: Campo de Adição de Produto Habilitado ... 45

Figura 28: Campo de Adição de Produto Desabilitado ... 45

Figura 29: Tela de Cadastro de Oportunidade ... 46

Figura 30: Teste de Cadastro de um Novo Cliente ... 48

Figura 31: Tela de Confirmação de Adição ... 48

Figura 32: Registro no BD do Cliente Recém Adicionado ... 49

Figura 33: Teste da Tela de Cadastro de Produto ... 49

Figura 34: Tela de Confirmação de Cadastro de Produto ... 49

Figura 35: Registro no BD do Produto Cadastrado ... 50

Figura 36: Teste da Tela de Cadastro de Nova Oportunidade ... 50

Figura 37: Tela de Confirmação de Cadastro de Oportunidade ... 51

Figura 38: Registro da nova Oportunidade Cadastrada ... 51

Figura 39: Registro da nova Venda Cadastrada ... 51

Figura 40: Tela de Pipeline com As Oportunidades Novas ... 52

Figura 41: Teste de Avanço de Oportunidade na Tela de Pipeline - Estágio Inicial ... 52

Figura 43: Registro da Oportunidade Cadastrada no Pipeline por "Seth" ... 53

Figura 44: Registros na tabela Pipeline_Log ... 53

Figura 45: Disposição das oportunidades obtidas da empresa ... 55

Figura 46: Tela de Métricas com Comparação de Dados ... 56

Figura 47: Diagrama de Classe Aproximado - Controller ... 64

Figura 48: Diagrama de Classe Aproximado - Model ... 66

Figura 49: Diagrama de Classe Aproximado - Model – Assets ... 68

Figura 50: Diagrama de Classe Aproximado - Model - Global Variables ... 70

Figura 51: Diagrama de Classe – View ... 72

LISTA DE QUADROS

Quadro 1: Requisitos Funcionais do Sistema... 27

Quadro 2: Requisitos Não-Funcionais do Sistema ... 28

Quadro 3: Representação do Pipeline Comercial da Empresa Analisada ... 54

LISTA DE ABREVIATURAS E SIGLAS

TI Tecnologia da Informação

SAP Systeme, Anwendungen, Produkte in der Datenverarbeitung

(Sistemas, Aplicações e Produtos em Processamento de Dados) CRM Customer Relationship Management

(Gestão de Relacionamento com o Cliente) MVC Model View Controller

(Modelo Visão e Controlador) UML Universal Modeling Language

(Linguagem Universal de Modelagem) DER Diagrama Entidade-Relacionamento

DAO Data Acess Objects

(Objetos de Acesso a Dados)

ID Número de Identificação

BD Banco de Dados

SQL Structured Query Language

(Lingugem Estruturada de Consulta)

ms Milisegundos

RF Requisitos Funcionais

SUMÁRIO

2.1. CONCEITUAÇÃO EM GESTÃO COMERCIAL ... 14

2.1.1. Visão Geral da Gestão Comercial ... 15

2.1.2. Processo de vendas ... 16

2.1.3. Pipeline ... 17

2.2. MÉTODOS E TÉCNICAS DE GERENCIAMENTODEPIPELINE ... 19

2.3. FERRAMENTAS DE GERENCIAMENTO DE PIPELINE ... 21

3. DESENVOLVIMENTO DO PROJETO ... 26

3.1. VISÃO GERAL DO SISTEMA DE PIPELINE COMERCIAL... 26

3.2. ESPECIFICAÇÃO DE REQUISITOS DO PROTÓTIPO DO SISTEMA ... 26

3.2.1. Requisitos Funcionais do Sistema ... 27

3.2.2. Requisitos Não-Funcionais do Sistema ... 28

3.3. MODELO DE ARQUITETURA DO PROTÓTIPO DO SISTEMA ... 29

3.3.1. Diagrama de Classes ... 31

3.3.2. Diagrama Entidade-Relacionamento ... 31

3.4. MODELOS COMPORTAMENTAIS ... 34

3.4.1. Diagramas de Caso de Uso ... 34

3.4.2. Diagramas de Estado ... 37

3.5. DESIGN DE INTERFACES ... 40

3.6. APRESENTAÇÃO DO PROTÓTIPO DESENVOLVIDO ... 42

3.7. TESTES DO PROTÓTIPO ... 47

3.7.1. Testes de Operações Primárias ... 47

3.7.2. Teste do Pipeline ... 51

4. ESTUDO DE CASO... 54

5. CONCLUSÕES ... 58

6. TRABALHOS FUTUROS ... 60

1. INTRODUÇÃO

Este trabalho de conclusão de curso se propõe ao desenvolvimento de um protótipo de software de Sales Pipeline, ou Pipeline Comercial. Este tipo de software tem como objetivo modelar o processo de fluxo de vendas desde a etapa de prospecção até a conclusão. Softwares deste tipo são utilizados por equipes de vendas, que registram, monitoram e analisam as operações comerciais desde o primeiro contato com Leads (clientes potencialmente interessados) até a conclusão da venda (CEFKIN 2007).

Toda empresa que atua no mercado necessita uma ferramenta de gerenciamento de suas operações comerciais. Não possuir uma ferramenta do tipo pode ter um impacto muito grande no desempenho e, como consequência, na competitividade da empresa. Por esse motivo, o ambiente comercial de uma empresa é muito dinâmico e requer muita experiência da equipe comercial. Estudos analisando a situação das empresas mostram que houve um aumento na quantidade de produtos oferecidos, na complexidade dos produtos e que as empresas têm participado em novos mercados. Novos clientes e oportunidades aparecem frequentemente e a evolução de negociações existentes varia constantemente, o que torna a complexidade do ambiente comercial considerável (TRAILER e DICKIE 2006).

Sistemas para apoio à gestão de pipelines comerciais são amplamente utilizados como parte ou módulo em sistemas de Customer Relationship Management (Gestão de Relacionamento com o Cliente, ou CRM). Por outro lado, estes sistemas exigem grande envolvimento das equipes comerciais e grande investimento para se dispor das ferramentas necessárias. Também, como consequência, estes sistemas são complexos e nem sempre oferecem a agilidade desejada. Em especial, para pequenas empresas, estas dificuldades limitam a adoção de sistemas de apoio à gestão de pipeline comercial e, consequentemente, sua eficiência.

Estre trabalho se insere neste contexto de gerenciamento de pipeline comercial, mais especificamente no uso de ferramentas computacionais para auxiliar a equipe comercial em suas tarefas.

1.1. APRESENTAÇÃO DO PROBLEMA

Soluções de CRM já estão no mercado há mais de 20 anos e formam uma ligação cada vez mais intrínseca entre executivos e equipes comerciais. Os executivos procuram instrumentos que coordenem as relações com os clientes dentre diversos departamentos, uma solução que permita monitorarem vendas que estejam sendo concluídas. Por outro lado, representantes comerciais, que permanecem apenas adicionando dados, não têm acesso a uma ferramenta que os auxilie a gerenciar seus

Pipelines (KIMLA 2014).

Na área comercial existe um equilíbrio entre habilidade, perícia e automação. Pode-se fazer uma analogia com o setor automobilístico, mais precisamente no começo do século XX. Neste período, a automação de carros era precária. Os motoristas precisavam ligar os carros na manivela, deveriam saber operar e, inclusive, saber como manter os carros. Hoje em dia esse cenário é muito simplificado, ao ponto que carros são inteiramente automatizados em muitas de suas funções e são fáceis de dirigir. Esse processo de adaptação ocorre similarmente no âmbito dos sistemas computacionais e sistemas de Pipeline Comercial. Muitos sistemas ainda são inflexíveis e necessitam que os usuários adaptem seus processos ao software, porém isso vem mudando (BAYSAN, et al. 2005). Já existe um melhor equilíbrio entre as habilidades do usuário e o nível de automação para um resultado final desejado (KIMLA 2014).

Atualmente, setores comerciais ainda enfrentam muita dificuldade em sua operação diária. Essas são muitas vezes causadas pelos sistemas de gerenciamento de vendas existentes no âmbito de trabalho (CEFKIN 2007). Problemas do cotidiano enfrentados por esses setores são:

 Tarefas repetitivas

o Quando um vendedor precisa digitar repetidas informações no sistema, ou quando o mesmo precisa passar por várias telas e procedimentos repetidos afim de cumprir com suas tarefas cotidianas (KIMLA 2014).

o O ambiente de vendas é dinâmico e competitivo. Empresas que não conseguem atualizar suas informações rapidamente têm uma desvantagem comercial significante, podendo perder a oportunidade de venda. Em casos mais extremos, pode-se até perder o cliente (BAYSAN, et al. 2005).

 Custo de ferramentas de gerenciamento de vendas no mercado

o Até 5 usuários – Custo: de US$0* a US$15.00 mensais por usuário (* importante ressaltar que alguns sistemas possuem período de teste)

 Exemplos: Podio (Podio 2016).

o De 5 a 20 usuários – Custo: de US$10,00 a US$200,00 por mês por licença de usuário.

 Exemplos: Pipedrive (Pipedrive 2016), base (base 2016), PipelineDeals (PipelineDeals 2016), Nutshell (Nutshell 2016), Zoho (Zoho 2016), SalesForce (Salesforce 2016), Dynamics CRM (Microsoft 2016).

o Mais de 20 usuários – Custo: US$2.000 até poucos milhões de dólares para soluções completas de CRM e gerenciamento de vendas.

 Exemplo: Siebel (Siebel 2016), SAP CRM (SAP 2016).  Armazenamento de informações valiosas de clientes.

o Um sistema de Pipeline comercial precisa armazenar informações valiosas da empresa, e um armazenamento seguro dessas informações é algo essencial.  Pequenas empresas não dispõem de ferramentas que sejam práticas e fáceis de

implantar.

o Implantar uma ferramenta específica em uma pequena empresa pode ser custoso. Quando a empresa é pequena, ainda não reconhecida pelo mercado e tem uma margem de lucro pequena isso se torna quase impossível (CEFKIN 2007).

estágios do pipeline para cada vendedor e para a gerência de uma empresa – e o faça trazendo métricas precisas de progresso do pipeline – traz alívio considerável para todos os departamentos envolvidos (KIMLA 2014).

1.2. JUSTIFICATIVA

O tema do trabalho foi escolhido por ter relação direta com o curso de Bacharelado em Sistemas de Informação, visto que abrange desde o levantamento de requisitos e modelagem ao desenvolvimento de uma solução.

Também foi levado em consideração o fato de existirem múltiplos usuários de diferentes áreas utilizando o sistema, desde o setor gerencial até os setores de venda e marketing. Esse último ponto é indicado como sendo o principal desafio e dificuldade da adoção do sistema de Pipeline Comercial pelos diversos times, e também como importante foco de melhora. Como menciona Nikolaus Kimla (KIMLA 2014), “como as soluções [de CRM] foram primariamente desenvolvidas para a gerência monitorar vendas, não para representantes comerciais controlarem seus pipelines, os últimos passaram a detestar as ferramentas”.

Hoje em dia, diferente de pouco tempo atrás, um gerente de comercial pode ser responsável por uma grande equipe. Também, pode-se ter vários parceiros comerciais, distribuidores e grandes valores em risco tornando impossível para o gerente de comercial ter total controle das oportunidades (KIMLA 2014).

1.3. OBJETIVOS DO TRABALHO 1.3.1. Objetivo Principal

O objetivo principal do trabalho é especificar e desenvolver um protótipo de um software de Pipeline Comercial que considere as diversas dificuldades enfrentadas na área comercial em pequenas empresas e que contribua para a melhoria da eficiência na gestão comercial.

1.3.2. Objetivos Secundários

 Conceituar e detalhar o conceito de Pipeline Comercial.

 Destacar ferramentas e soluções de Pipeline Comercial utilizadas atualmente.  Efetuar um levantamento de requisitos para o protótipo.

 Modelar as especificações do protótipo utilizando modelos padrão UML.  Desenhar a interface do software.

 Desenvolver o protótipo com base nos modelos definidos.  Testar o protótipo nos diferentes estágios.

 Desenvolver um estudo de caso utilizando dados reais ofuscados de uma empresa.

1.4. ESTRUTURA DO DOCUMENTO

No capítulo 2 será apresentado o levantamento bibliográfico do Trabalho de Conclusão de Curso. Pontos mais específicos contemplados nesse capítulo irão desde a conceituação de gestão comercial, métodos e técnicas utilizados, até o estado da arte das ferramentas computacionais de gerenciamento de Pipeline utilizadas hoje em dia.

O capítulo 3 tratará do desenvolvimento do trabalho. Esse tratará das especificações necessárias para o desenvolvimento, tais como uma visão geral do sistema de pipeline, especificação de requisitos e os modelos de arquitetura do sistema, com os diagramas essenciais. No capítulo 3 também será exposto o desenvolvimento das interfaces, será feita uma apresentação do sistema concluído e, finalmente, alguns casos de teste realizados no sistema.

No capítulo 4 será apresentado um estudo de caso com dados reais de uma pequena empresa. Será feita uma análise das funcionalidades do sistema com os dados da empresa e também será traçado um comparativo.

2. LEVANTAMENTO BIBLIOGRÁFICO

Esse capítulo trata da conceituação de gestão comercial, de termos utilizados comercialmente, assim como métodos e técnicas de gestão de pipeline e ferramentas para fazer esse gerenciamento.

2.1. CONCEITUAÇÃO EM GESTÃO COMERCIAL

Qualquer empresa ou organização necessita de uma perspectiva comercial. Essa, por sua vez, pode ser caracterizada por palavras-chave, tais como: lucro, dinheiro, propriedade intelectual, risco, contratos e encomendas. É uma perspectiva de alto nível, dos pontos “macro”, nos quais o responsável deve focar para adquirir a consciência comercial do negócio (DIAS 2010).

 Lucro: todos os serviços ou produtos que uma empresa produz devem ser vendidos por um valor maior do que a soma dos seus custos. Para se aumentar o lucro, é preciso que ou os custos sejam minimizados, ou que o preço de venda seja aumentado. Isso, considerando um mercado em que haja clientes e os mesmos tenham a tendência de procurar os serviços e produtos oferecidos.

 Dinheiro: “Os negócios que produzem lucros que se traduzem de forma consistente em dinheiro são geralmente seguros e bem geridos” (BOYCE and LAKE 2007). A manutenção de fluxo de caixa é um hábito saudável para a organização. Débitos e obrigações financeiras da empresa tem impacto direto no fluxo de caixa, visto que na maioria das vezes não estão alinhados com os recebimentos dos clientes.

 Propriedade Intelectual: “Os direitos de propriedade intelectual dizem respeito ao direito que as empresas têm de explorar suas ideias, protegendo a sua forma e aplicação” (BOYCE and LAKE 2007). Caso a propriedade intelectual seja fator importante nos negócios da empresa, sua exploração fortuitamente trará inovações, que contribuirão para o sucesso da organização.

 Riscos: análises formais de risco são necessárias, durante o estudo de um novo projeto ou contrato, para ter a certeza de que são contempladas questões do âmbito técnico e do cumprimento de prazos.

 Contratos: “O sucesso da empresa é alcançado através da conquista de contratos com clientes que estão interessados no bem ou serviço prestado, consumindo o menor número possível de recursos” (BOYCE and LAKE 2007). É preciso, para tal fim, saber dos interesses de ambas as partes, para que a relação cliente-vendedor seja eficaz e sem conflitos.

 Encomendas: alguns negócios necessitam de poucas encomendas por ano para se sustentarem, enquanto outros necessitam de milhares. De qualquer forma, para empresas crescerem, é preciso aumentar a qualidade e a quantidade de encomendas. Isso, naturalmente, envolve a tomada de decisões de natureza comercial. O diretor comercial é geralmente a pessoa que toma essa decisão, coordenando com todos os envolvidos em toda a cadeia comercial.

É imperativo que os departamentos comerciais sejam geridos de forma eficiente e afinada, de modo a evitar impactos advindos de oscilações no(s) mercado(s) que a empresa atua. “As recessões econômicas aumentam a pressão sobre as vendas das organizações. À medida que as negociações e acordos diminuem e se tornam mais morosos, os ciclos de venda crescem e a competição intensifica-se” (ROLAND e RANDERY 2001).

Na seção 2.1.1 analisar-se-á a visão geral da gestão comercial, com as novas estratégias adotadas e as mudanças causadas pelo avanço tecnológico no campo comercial.

2.1.1. Visão Geral da Gestão Comercial

A gestão comercial é uma das atividades mais críticas dentro de qualquer organização, pois ela tem a responsabilidade de garantir o fluxo de faturamento (i.e. a fonte de sustento) de toda a empresa. Quando organizações se deparam com quedas nas vendas, é importante que se iniciem atividades com o objetivo de aumentar a

produtividade das mesmas. Porém, a estratégia a se tomar deve ser analisada cuidadosamente, de modo que não cause impacto a nenhuma perspectiva de negócio da empresa ou organização. Somente analisando todas as dimensões envolvidas é que se torna possível confirmar a origem do mal desempenho e tomar ações corretivas, focadas na resolução do problema.

É importante ressaltar que o avanço nas tecnologias de informação vem mudando drasticamente como a informação flui no âmbito organizacional. Hoje em dia, setores adquirem funções novas e modificam funções antigas. Por exemplo, hoje em dia o departamento comercial não é mais o responsável por apresentar o produto para o cliente. Isso é função de um departamento de informação ou de tecnologias de informação. Assim, os gestores comerciais e vendedores podem se concentrar em identificar potenciais compradores e tornar clientes desconhecidos em clientes que tragam lucro para a empresa (DIAS 2010).

2.1.2. Processo de vendas

O processo de vendas (Sales Process) representa o percurso seguido durante a venda de um produto ou serviço. É uma abordagem sistemática, constituída por vários diferentes passos-chave que compõem o processo que decorre durante uma venda. Distingue-se do ciclo de vendas na medida em que é um processo visto da perspectiva da empresa que proporciona o produto ou serviço (DIAS 2010). O ciclo de vendas “corresponde ao tempo, da perspectiva do consumidor, que intercede entre a identificação da necessidade e a aquisição do bem/serviço que a satisfaz” (TEMPLE 2007).

São apresentados pela literatura diferentes passos que compõem o processo de vendas, visto que diferentes negócios possuem diferentes especificidades. Porém, todos apresentam a mesma tendência: o processo inicia com um elevado número de potenciais interessados na compra do produto ou serviço e vai diminuindo (afunilando) à medida que se aproxima do final da negociação (DIAS 2010). Isso é causado pela desistência ou desinteresse de clientes ao longo do processo de vendas.

2.1.3. Pipeline

Pipeline é um modelo do processo de vendas. É, na maioria das vezes,

modelado como um funil que contém diversos estágios diferentes, como podemos observar na Figura 1. Ainda na figura 1, é possível observar que o funil é largo no começo, representando o maior volume inicial de oportunidades (Leads) e potenciais clientes, porém, estreito no final, à medida que as investigações, contatos e análises sobre as potenciais vendas avançam ao longo do tempo. Outras possíveis denominações do Sales Pipeline são: “Funil de Vendas” e “Processo de Vendas”.

Figura 1: Diagrama representando o Pipeline Fonte: adaptado de (LEWIS 2001).

O Pipeline não deve ser encarado como uma metodologia a ser seguida meticulosamente por um gestor de comercial, mas como um conjunto de marcações e métricas que representam como as oportunidades de uma venda evoluem. Faz-se necessário dizer, também, que o Pipeline possibilita o acompanhamento do pessoal de vendas do ponto de vista gerencial, nos seguintes aspectos, dentre outros (DIAS 2010):

 Número de vendas concluídas e o valor final de conclusão;

 Quantidade de oportunidades novas que um vendedor está gerando;

cadastradas;

 Percentagem de sucesso de cada vendedor em determinado nível do Pipeline, conseguido através do número de vendas concluídas.

Desde a análise das oportunidades até o fechamento de um novo negócio ou contrato, existem várias dimensões que um gestor comercial tem de controlar. O processo de vendas identifica, define e agrupa, em uma cadeia de eventos, as atividades necessárias que levam à aquisição de novos clientes. Esta sucessão de ações é passível de ser repetida e é mensurável, permitindo assim que o Gestor Comercial conheça o estado das suas investigações e negociações (DIAS 2010).

Como mencionado anteriormente, os níveis compreendidos pelo Pipeline variam de acordo com o negócio e a estratégia adotada pela organização. Organizações grandes, com vários departamentos, podem adotar um número maior de níveis, que se encaixe em sua estratégia de negócio. Ao mesmo tempo, empresas menores podem optar por manter o Pipeline com um número reduzido de níveis, por terem processos mais ágeis e não terem muitos departamentos.

Ao percorrer o “funil” do Pipeline do começo ao fim, pode-se concluir que os primeiros passos representam uma aproximação inicial a um possível cliente, ou Leads. Além de contemplar contatos, o estágio de Leads também abrange novas oportunidades sobre clientes perdidos ou clientes cativos. Esse é o primeiro passo dentro da Pipeline, portanto nele devem ser listados toda e qualquer possibilidade de um potencial cliente.

O segundo é o estágio de Comunicação Inicial. Nele são listados clientes que demonstraram um interesse posterior ao primeiro contato. É a primeira vez que a empresa estabelece uma comunicação com o possível cliente. Nesse estágio deve-se aprender o máximo sobre o cliente e questioná-lo a ponto de definir suas necessidades, fatores de decisão e, em alguns casos, investigar o uso de produtos de concorrentes.

No estágio “Interesse / Testando”, o cliente ainda não está decidido quanto à compra ou ao fechamento do contrato. Portanto, esse estágio consiste em aprimorar a análise feita no estágio anterior relativa ao cliente e, se possível, fazer isso proporcionando uma prova do serviço ou produto que a empresa oferece. Importante

destacar que, tanto nesse quanto no passo anterior é importante manter um canal de comunicação direto com o cliente, a fim de oferecer a solução ou o produto que melhor encaixe na necessidade do cliente.

O quarto estágio, ou o estágio de consideração do cliente, é o estágio que marca a iniciativa da empresa em apresentar o que ela julga ser a melhor solução ou produto para o cliente, para que então esse possa decidir se continua com o processo de venda ou não. Deve-se destacar que é igualmente importante, quando lidando com contratos, conhecer os limites do seu público, a fim de não lhes oferecer um produto ou serviço por um valor inferior ou muito além ao que estejam dispostos a pagar.

Quando o cliente responde que está interessado e começa-se a negociação para fechamento de valores, então esse potencial cliente é passado para a fase de negociação. Nessa fase é enfatizado o fato de que o vendedor compreende as necessidades do cliente e, caso necessário, apresenta qualquer clarificação quanto ao negócio. Quando todas as negociações têm sucesso, o então cliente é passado para o estágio de concluído.

2.2. MÉTODOS E TÉCNICAS DE GERENCIAMENTO DE PIPELINE

Os métodos e técnicas para o gerenciamento do Pipeline comercial de uma empresa variam. Desde papéis em um arquivo de um representante comercial em uma pequena empresa, até sistemas complexos de CRM em empresas de grande porte, com comunicação entre diferentes módulos.

As convenções para registro em um Pipeline variam. Tipicamente um registro em um Pipeline é composto pelo nome do potencial cliente, os produtos ou serviços que o mesmo tem interesse, o montante em dinheiro da compra dos produtos/serviços e uma indicação da probabilidade de conclusão de venda. Os vendedores, ou as pessoas diretamente conectadas com o cliente em potencial, é que são os responsáveis por inserir as informações de previsão, na maioria dos casos. Em teoria, cada nova oportunidade que é detectada é então inserida no Pipeline e mantida regularmente (CEFKIN 2007).

Em um cenário ideal, toda a cadeia de gestão de uma organização deve, a qualquer momento, ser capaz de referenciar o estágio das oportunidades em aberto no

Pipeline. Com isso, a gestão conseguiria ter uma imagem instantânea da performance

futura do negócio. Na prática, por outro lado, existe sempre um atraso entre o estado atual do potencial cliente no Pipeline e o estado registrado no sistema. A escolha do “quando” e de “se” é necessário adicionar uma oportunidade ao Pipeline é uma questão de consideração, negociação e de manipulação pelos vendedores. O que constitui uma “oportunidade” depende da interpretação do vendedor; é na primeira indicação de que o cliente precisa de uma solução? É depois da apresentação de uma solução de negócio a um potencial cliente? Quando uma oportunidade é percebida e inserida, uma gama de considerações surge acerca dos dados e de qual a maneira correta de atualizá-la (CEFKIN 2007).

O método de gerenciar vendas por matrizes é o mais comum em empresas de pequeno porte, por sua facilidade na implementação e de configuração inicial. Outro motivo para a ampla utilização desse método é desvinculação desse método com um formato ou uma tecnologia específica. Pode ser feito tanto com matrizes em papel, quanto utilizando softwares de prateleira.

Um ponto negativo de utilizar softwares de prateleira para a gestão de vendas é a centralização dessa gerência, ou a dificuldade de permitir com que mais de uma pessoa utilize a ferramenta ao mesmo tempo. É também muito precário em termos de geração de estatísticas e predições, visto que esses cálculos precisam ser configurados na ferramenta. Um terceiro aspecto que muitos gestores não consideram ao adotar esse método é o da escalabilidade. Sempre que uma empresa inicia suas atividades, é esperado que o número de suas atividades cresça, é o rumo natural de uma empresa. Porém, muitos gestores que adotam esse método têm dificuldades quando se deparam com volumes grandes de vendas, por conseguinte, causando mal funcionamento da ferramenta ou a inviabilização da mesma, acarretando em despesas inesperadas.

2.3. FERRAMENTAS DE GERENCIAMENTO DE PIPELINE

Atualmente existem algumas ferramentas de gerenciamento de Pipeline estabelecidas, porém são oferecidas como módulo de um sistema CRM. Essas ferramentas necessitam de uma infraestrutura grande, com o objetivo de comportar múltiplos registros e vários usuários no Pipeline simultaneamente. Por esse motivo, o custo de implementação e de implantação dessas ferramentas é muito elevado. Alguns exemplos de sistemas CRM nessa escala que incluem sistemas de Pipeline de vendas são: CRM Dynamics (Microsoft), SAP CRM e Siebel (Oracle). A seguir, pode-se ver na Figura 2 e na Figura 3 os módulos de Pipeline de vendas nos sistemas Siebel e SAP, respectivamente.

Figura 2: Exemplo de gerenciamento de Pipeline no sistema Siebel Fonte: Oracle (Oracle 2016).

Figura 3: Exemplo de Sales Pipeline no SAP Business One Fonte: Prospettiva (Prospettiva 2016).

Por outro lado, existem sistemas que podem ser classificados como sistemas de médio porte. Esses sistemas são oferecidos, na maioria dos casos, como módulos de venda completos. Possuem um custo de implementação menor do que os sistemas CRM citados anteriormente, porém oferecem seus serviços em infraestrutura proprietária, o que cria uma dependência. Uma importante questão, por outro lado, é citar que a escalabilidade nesses sistemas pode ser muito custosa, visto que o sistema de cobrança é por usuário. Organizações que trabalham no varejo e pequenas empresas, que dependem de margens de lucro muito pequenas, são atingidos por esse tipo de sistema de cobrança.

Como exemplos de sistemas de Pipeline de médio porte, podem ser citados os sistemas Pipedrive, base, PipelineDeals, Zoho, SalesForce e Nutshell. Nas figuras a seguir são apresentados exemplos do Pipeline de vendas dos sistemas citados anteriormente.

Figura 4: Tela de gerenciamento de Pipeline no sistema Pipedrive Fonte: (Pipedrive 2016).

Figura 5: Tela de relatório do Pipeline do sistema base Fonte: (base 2016).

Figura 6: Tela de gerenciamento de Pipeline no sistema Nutshell Fonte: (Nutshell 2016).

Sistemas de Pipeline de vendas de pequeno porte são representados por sistemas tais como Podio. Esses sistemas, por sua vez são os sistemas com o menor custo de implementação e de manutenção, visto que podem ser implementados a partir de um único usuário. O Podio, em específico, utiliza a interface com o sistema de documentos em nuvem da Google, o Google Docs, que possibilita que o usuário tenha acesso aos seus dados a partir de uma conta gratuita nesse sistema. A seguir, na Figura 7 pode-se ver a tela de gerenciamento de Pipeline do sistema Podio.

Figura 7: Tela de gerenciamento de Pipeline do sistema Podio Fonte: (Zapier 2016).

3. DESENVOLVIMENTO DO PROJETO

Nesse capítulo será tratado o processo de desenvolvimento do projeto, desde uma visão geral do sistema de pipeline, especificação de requisitos, até o design de interfaces e apresentação do protótipo.

3.1. VISÃO GERAL DO SISTEMA DE PIPELINE COMERCIAL

Como mostrado anteriormente, os sistemas de Pipeline Comercial têm como principal objetivo o acompanhamento e classificação das oportunidades e negociações de uma empresa ou organização. Isso deve ser feito da maneira mais clara e intuitiva possível, com objetivo de prover informações concretas e precisas do ambiente de vendas na organização em tempo real, dando uma vantagem comercial

Ao traçar um comparativo entre os diversos sistemas citados, percebe-se que possuem características similares, tanto ao mostrar os dados aos usuários quanto ao classificar e armazenar esses dados. Destaca-se que todos os sistemas possuem um mecanismo de classificação do estado em que se encontra a venda. Esse mecanismo é o mais importante de um sistema de Pipeline Comercial. O ambiente de vendas é em geral muito competitivo. Portanto, é importante, senão essencial, ter essas informações prontamente disponíveis ao usuário do sistema.

Outro ponto importante de um sistema de Pipeline Comercial é conseguir gerar estatísticas com os registros que foram incluídos no sistema. A medida que é utilizado, este deve armazenar as ações dos usuários temporalmente. Essas informações podem então ser usadas para calcular diversas estatísticas, seja sobre os clientes registrados, vendedores e seus respectivos gerentes. Essas estatísticas, então, podem ser utilizadas por outros departamentos interessados, dentro da organização, com o objetivo de alterar estratégias de trabalho e de vendas da organização.

3.2. ESPECIFICAÇÃO DE REQUISITOS DO PROTÓTIPO DO SISTEMA

A seguir serão especificados os requisitos funcionais e não funcionais do sistema.

3.2.1. Requisitos Funcionais do Sistema

Número do Requisito Descrição

RF01 O sistema deve permitir o login de um usuário cadastrado.

RF02 O sistema deve permitir o cadastro de um novo Gerente por um administrador. RF03 O sistema deve permitir a edição do cadastro de um Gerente por um

administrador.

RF04 O sistema deve permitir o cadastro de novo Vendedor por um administrador ou gerente.

RF05 O sistema deve permitir a edição de um Vendedor por um Administrador ou gerente.

RF06 O sistema deve permitir o cadastro de um novo Cliente por um administrador, gerente ou vendedor.

RF07 O sistema deve permitir a edição de um Cliente cadastrado pelo vendedor que o cadastrou.

RF08 O sistema deve permitir o cadastro de uma nova oportunidade no Pipeline por um administrador, gerente ou vendedor.

RF09 O sistema deve permitir a edição de uma oportunidade no Pipeline por um administrador, gerente ou vendedor.

RF10 O sistema deve permitir que um vendedor consiga ver apenas suas oportunidades no Pipeline.

RF11 O sistema deve permitir o cadastro de um Produto por um administrador ou gerente.

RF12 O sistema deve permitir a edição de um Produto por um administrador ou gerente.

RF13 O sistema deve permitir a atualização de uma oportunidade cadastrada no Pipeline.

RF14 O sistema deve permitir o cadastro de um Administrador por um administrador. RF15 O sistema deve permitir a edição de um Administrador por um administrador. RF16 O sistema deve permitir que um usuário acesse suas métricas.

RF17 O sistema deve permitir que um usuário compare suas métricas.

RF18 O sistema deve restringir que um vendedor enxergue oportunidades que não sejam suas.

RF19 O sistema deve calcular as métricas para cada vendedor e gerente. Quadro 1: Requisitos Funcionais do Sistema

3.2.2. Requisitos Não-Funcionais do Sistema

Número do Requisito Descrição

RN01 O sistema deve processar as ações de usuários em menos de 1000 ms. RN02 O sistema deve permitir mais de 1 usuário ao mesmo tempo.

RN03 O sistema deve estar disponível 99% do tempo. RN04 O sistema deve manter a integridade dos dados. RN05 O sistema deve manter a consistência dos dados.

RN06 O sistema deve ser intuitivo o suficiente para diminuir o tempo de treinamento.

RN07 O sistema deve ter acesso ao banco de dados independentemente da plataforma sobre a qual esteja sendo executado.

RN08 O sistema deve ser executado em diferentes sistemas operacionais: Microsoft Windows, Mac OS e Linux.

RN09 O sistema deve ser desenvolvido em linguagem Java. RN10 O sistema deverá ser cliente-servidor.

RN11 O banco de dados do sistema deve ser PostgreSQL.

RN12 O sistema não apresentará quaisquer dados de cunho privativo.

RN13 O sistema deve poder ser reinicializado manualmente em caso de falha de banco de dados.

RN14 O sistema deve restringir que gerentes enxerguem oportunidades que não sejam de seus vendedores ou suas.

RN15 O sistema deve restringir funcionalidades de acordo com o usuário e seu perfil.

RN16 O sistema deve restringir que vendedores comparem suas métricas apenas com vendedores abaixo do mesmo gerente.

RN17 O sistema deve restringir que gerentes comparem suas métricas apenas com outros gerentes.

RN18 O sistema deve restringir que usuários cadastrem dados em formato incorreto.

RN19 O sistema deve disponibilizar maneiras de navegação fáceis e intuitivas. Quadro 2: Requisitos Não-Funcionais do Sistema

3.3. MODELO DE ARQUITETURA DO PROTÓTIPO DO SISTEMA

A arquitetura escolhida para o desenvolvimento do protótipo de Pipeline Comercial foi a Model View Controller (MVC). É o modelo arquitetural mais amplamente usado na literatura e nas empresas. Ele permite diferenciar os componentes de um software em três camadas, de acordo com sua natureza e assim tornar a compreensão do sistema muito mais fácil. A Figura 8 representa a arquitetura MVC utilizada na implementação do sistema, com o Controller sendo o mediador e as respectivas comunicações e ações entre os componentes. Ele foi desenvolvido dessa maneira porque, caso seja necessário, permite que o banco de dados seja trocado por outro sem impactos muito grandes ao sistema. Todos os métodos estão encapsulados.

O protótipo, implementado de acordo com o MVC mencionado acima, funciona da seguinte maneira: o Controller é responsável por toda e qualquer interação no sistema. Ele faz o papel do mediador entre as interfaces (View) com os objetos e o Banco de dados (Model). Este, recebe ações do usuário por meio das interfaces, formata-as, se for necessário, e toma a ação. Outra função do Controller é, após recebida e formatada a solicitação do cliente via a interface, enviar para o Model essa solicitação para que este tome as ações necessárias.

O View representa as interfaces do sistema. Consiste de todas as telas e dispositivos de interação que o sistema disponibiliza ao usuário. Assim que o usuário efetua uma solicitação, o View é responsável por enviar ao Controller. Esse também é responsável por receber atualizações de componentes (telas solicitadas, alteração de estado de componentes, alteração de texto em campos, etc.) vindas do Controller.

O armazenamento de todas as regras de negócio e de todos os dados do sistema são de responsabilidade do Model. Este recebe do Controller a solicitação canalizada e, então, a processa levando em consideração as regras de negócio implementadas no sistema. O Model também é responsável por enviar respostas de mudanças solicitadas pelo Controller, para que este possa atualizar o View. Somente o

Model tem acesso ao banco de dados e o faz utilizando os DAOs, como será visto a

Devido à grande quantidade de operações com banco de dados, também foram utilizados Data Access Objects (DAO). DAO foi escolhido por dois motivos principais. Primeiro, DAO foi usado para a implementação do sistema com o objetivo de organizar o acesso ao banco de dados em diferentes categorias. O segundo motivo foi isolar o banco de dados em certas operações de dados, para não correr o risco de expor detalhes sobre o banco de dados. O DAO, no caso desse protótipo, foi incluído junto ao Model, da arquitetura MVC, por ter direto acesso ao banco de dados.

Figura 8: Modelagem da arquitetura Model-View-Controller utilizada Fonte: Autoria Própria.

A linguagem escolhida para o desenvolvimento do protótipo foram Java – linguagem do sistema e o sistema gerenciador de BD escolhido para o desenvolvimento foi o PostgreSQL. Java foi escolhida por ser uma linguagem aberta e com uma

compatibilidade de plataformas ampla. PostgreSQL foi escolhido por ser uma solução aberta, robusta e ser nativamente compatível com Java.

3.3.1. Diagrama de Classes

A Figura 9 apresenta o modelo estrutural do protótipo desenvolvido, utilizando um diagrama de classes. Este modelo possui 3 grandes pacotes que representam a organização do software nas três camadas MVC (Controller, View e Model). Cada pacote contém as classes e seus relacionamentos. O diagrama de classes possui apenas uma classe no pacote Controller, que é a classe mediadora do sistema. O pacote de View possui classes de interface, para disponibilizar os dados aos usuários. O pacote Model possui a classe Model, que é a classe mais importante do módulo e comunica diretamente com o Controller. Este pacote também possui dois outros pacotes internos: pacote DAO, que contém os objetos de acesso ao banco de dados, e pacote Assets, que inclui classes para criação de objetos e as variáveis globais utilizadas no sistema. Uma visão mais detalhada deste modelo se encontra em anexo desse trabalho de conclusão de curso.

3.3.2. Diagrama Entidade-Relacionamento

A Figura 10 representa o Diagrama Entidade-Relacionamento (DER) do banco de dados do protótipo desenvolvido. Como o próprio nome do diagrama indica, esse representa as entidades de banco de dados (tabelas) e seus relacionamentos. O diagrama contém a representação das 9 tabelas utilizadas pelo sistema. A tabela central dessa arquitetura é a tabela Pipeline, que concentra todas as informações necessárias para o funcionamento do sistema, tais como o ID do Vendedor responsável pelo cadastro, o ID do cliente e, quando existente, o ID da venda relacionada. Outra tabela igualmente importante é a tabela de log da tabela Pipeline. É por meio desta tabela que as métricas são calculadas.

Figura 9: Diagrama de Classes do Protótipo Fonte: Autoria Própria.

Figura 10: Diagrama Entidade-Relacionamento Fonte: Autoria Própria.

3.4. MODELOS COMPORTAMENTAIS 3.4.1. Diagramas de Caso de Uso

 Alto-nível de operações de Manutenção: os casos de uso deste grupo envolvem os casos para cadastrar e editar gerentes, vendedores, clientes e vendas.

Figura 11: Diagrama de Caso de Uso - Operações de Cadastro Fonte: Autoria Própria.

 Alto-nível de operações do Pipeline Comercial: os casos de uso desse grupo envolvem os casos de operações derivadas do Pipeline Comercial, tais como consultar métricas, avançar e regredir oportunidades e cadastro de oportunidade.

Figura 12: Diagrama de Caso de Uso – Pipeline Comercial Fonte: Autoria Própria.

 Baixo nível de Cadastrar Oportunidade, Selecionar Gerente e Vendedor: os casos de uso representados a seguir são casos derivados de Cadastrar Nova Oportunidade.

Figura 13: Diagrama de Caso de Uso - Cadastrar Oportunidade, Selecionar Gerente e Vendedor Fonte: Autoria Própria.

 Baixo nível de Avançar ou Regredir Oportunidade: os casos de uso abaixo envolvem os casos de avanço e regressão de oportunidade, assim como seus casos derivados

Figura 14: Diagrama de Caso de Uso - Avançar ou Regredir Oportunidade Fonte: Autoria Própria.

 Baixo nível de Consultar e Comparar Métricas: os casos de uso abaixo representam os casos de métricas, tais como a consulta, comparação, disponibilização e seus derivados.

Figura 15: Diagrama de Caso de Uso - Consultar e Comparar Métricas Fonte: Autoria Própria.

3.4.2. Diagramas de Estado

 Operação de Login: o diagrama apresentado na Figura 16 ilustra o fluxo de estados para a operação de login de um usuário no sistema.

Figura 16: Diagrama de Estado – Login Fonte: Autoria Própria.

 Cadastro de nova Oportunidade: o diagrama apresentado pela Figura 17 representa o fluxo de estados para a operação de cadastro de uma nova oportunidade no sistema.

Figura 17: Diagrama de Estado – Inserir Nova Oportunidade Fonte: Autoria Própria.

 Atualização de Oportunidade: o diagrama apresentado na Figura 18 ilustra os diferentes estados da operação de atualização de uma oportunidade.

Figura 18: Diagrama de Estado – Atualizar Oportunidade Fonte: Autoria Própria.

 Calcular e Exibir métricas: o diagrama representado pela Figura 19 ilustra os estados do cálculo e exibição das métricas.

Figura 19: Diagrama de Estado – Calcular e Exibir Métricas Fonte: Autoria Própria.

 Cadastrar Novo Usuário: o diagrama representado a seguir ilustra os estados existentes na operação de cadastro de usuário.

Figura 20: Diagrama de Estado – Cadastrar Usuário Fonte: Autoria Própria.

3.5. DESIGN DE INTERFACES

O processo de desenvolvimento das interfaces levou em consideração diversos aspectos. O primeiro desses aspectos vem diretamente do termo de denominação do protótipo: Pipeline. Um Pipeline, ou duto de transporte, que leva algo do começo do duto ao final. No caso, um duto de oportunidades. Por isso optou-se por fazer a disposição das mesmas de maneira linear e ordenada, como pode-se ver na Figura 21 – Da esquerda para a direita, começando por Leads, passando por todos os diferentes estágios, até chegar à conclusão do negócio.

Um segundo aspecto foi o de utilização do sistema. A interface do sistema deve ser intuitiva, de modo que um novo usuário possa receber o mínimo de instruções para conseguir utilizar o sistema. A arquitetura do sistema possui um sistema de controle de acesso baseado no perfil do usuário. Isso é conseguido através do Login do mesmo ao sistema. A partir desse ponto, o sistema consegue limitar o alcance das ações do usuário através de seu perfil, como por exemplo: Acesso a telas específicas, permissões em operações de negócio, oportunidades de vendedores distintos, etc.

Diferentemente da maioria dos sistemas de Pipeline Comercial, a gestão dos estágios das oportunidades é feita de modo direto. Optou-se por ocultar os produtos de uma potencial venda/oportunidade para diminuir a quantidade e tornar mais objetivas as informações passadas aos usuários.

Figura 21: Tela Principal do Programa – Representação do Pipeline Fonte: Autoria Própria.

A apresentação das métricas de um usuário, assim como a comparação do mesmo com outro usuário é feita na mesma tela. O motivo para tal é o reaproveitamento da estrutura da tela para mais de uma função. A tela foi desenvolvida para usuários que utilizam o sistema frequentemente. Por esse motivo pôde-se incluir uma quantidade grande de dados na tela. É necessário, em uma comparação de dados temporais, que se tenha um período definido. Por isso foi colocado um campo para o usuário preencher com o período que deseja. As comparações são demonstradas como percentagens, situadas entre os números absolutos do usuário e do usuário comparado. Todos esses detalhes podem ser observados na Figura 22 a seguir.

Figura 22: Tela de Métricas e Comparação com Campos de Comparação Realçados Fonte: Autoria Própria.

3.6. APRESENTAÇÃO DO PROTÓTIPO DESENVOLVIDO

O sistema de Pipeline comercial, da maneira como foi arquitetado, necessita que o usuário tenha sido cadastrado e faça login para utilizar o sistema. A Figura 23 representa a tela de login utilizada. É uma tela de login simples, mas é desta maneira que o sistema busca, a partir do cadastro no BD, o papel deste usuário.

Figura 23: Tela de Login do Protótipo Fonte: Autoria Própria.

Assim que o usuário faz o login, o sistema exibe a tela principal do Pipeline. Porém, pode-se notar que o sistema restringe certos campos e os dados que busca do BD de acordo com o perfil do usuário que recém fez login no sistema. Foram cadastrados 2 gerentes e 4 vendedores diferentes, cada um destes com dois Leads cadastrados para si no sistema. A Figura 24 representa a tela principal com o vendedor “Seth” tendo logado e a Figura 25 representa a tela principal com o gerente de “Seth”, “Bartholomeu”, tendo logado. Nota-se que na primeira, aparecem apenas as oportunidades do vendedor logado e na segunda aparecem todas as oportunidadaes de todos os vendedores abaixo de “Bartholomeu”.

Figura 24: Tela Principal do Vendedor "Seth" Fonte: Autoria Própria.

Figura 25: Tela Principal do Gerente de "Seth" Fonte: Autoria Própria.

A tela principal do protótipo é a tela de controle do Pipeline, como ilustrado na Figura 26. Como exemplo, foram inseridos 8 novas oportunidades no sistema, sendo duas para cada cliente e colocadas em diferentes estágios do pipeline. A tela principal pode ser dividida em 4 áreas principais, tal como pode-se ver nas áreas enumeradas da Figura 26. Na área 1 estão os campos de detalhes da oportunidade selecionada. A área 2 é a área do controle de navegação de uma oportunidade no Pipeline. É a partir dela que os usuários do sistema conseguem avançar ou regredir o progresso de uma oportunidade. A área 3 ilustra os menus de navegação entre as diferentes telas do

sistema, como, por exemplo, a tela de cadastro de novos usuários e cadastro de nova oportunidade. Por último temos a área 4, que é o Pipeline. Nela estão ilustradas todas as oportunidades que foram cadastradas no Pipeline e que se encontram nos diversos estágios.

Figura 26: Tela Principal do Protótipo Fonte: Autoria Própria.

Da mesma maneira como são limitados os acessos aos dados cadastrados no sistema, alguns campos também são desabilitados, para que usuários sem a permissão necessária não consigam acessar. Como exemplo, considera-se a situação hipotética de adição de um novo produto. Apenas os perfis de Gerente e Administrador têm permissão para criação de um novo produto, portanto o campo de adição de um novo produto aparece habilitado apenas para os Gerentes e Administradores, como pode-se ver nas figuras Figura 27 e Figura 28.

Figura 27: Campo de Adição de Produto Habilitado Fonte: Autoria Própria.

Figura 28: Campo de Adição de Produto Desabilitado Fonte: Autoria Própria.

A tela de cadastro de nova oportunidade é acessada a partir da tela principal do protótipo e é representada na Figura 29. Um Vendedor ou Gerente pode inserir uma oportunidade sem inserir uma venda relativa, porém, se esse for o caso, deve ser inserido um valor estimado de venda. Estas alternativas possibilitam que uma nova oportunidade seja inserida mais rapidamente e sem muito comprometimento inicial, para evitar perdas de tempo. Posteriormente, se for o caso de uma oportunidade inicial virar uma proposta, a venda pode ser gerada e anexada ao registro no Pipeline.

Toda oportunidade deve possuir um vendedor e um cliente cadastrados, para que haja um representante da empresa (vendedor) em contato com a parte interessada (cliente). Como observa-se na Figura 29, esses campos vem pré-selecionados, de maneira que não haja cadastro acidental.

Figura 29: Tela de Cadastro de Oportunidade Fonte: Autoria Própria.

3.7. TESTES DO PROTÓTIPO

Esta seção apresenta os testes realizados para verificação do protótipo desenvolvido. Parte-se do pressuposto que operações básicas como login, navegação entre telas e troca de usuários estão funcionando corretamente.

3.7.1. Testes de Operações Primárias

O cenário inicial de teste envolve um departamento comercial de uma empresa fictícia com os seguintes parâmetros:

 1 administrador cadastrado  2 gerentes cadastrados  4 vendedores cadastrados  4 clientes cadastrados  5 produtos cadastrados

Os casos de teste que serão tratados nesta seção consistem em operações gerais de cadastro e de operações cotidianas no uso do pipeline.

Teste 1 - Cadastro de um novo Cliente por um Vendedor

O vendedor deve cadastrar um cliente de nome “Cliente Teste” e conferir no banco de dados e no sistema se o mesmo foi adicionado com sucesso. Deve-se conferir também se os campos permitidos estão habilitados e os não permitidos desabilitados. As figuras a seguir ilustram as telas do processo de cadastro de um novo cliente.

Figura 30: Teste de Cadastro de um Novo Cliente Fonte: Autoria Própria.

Figura 31: Tela de Confirmação de Adição Fonte: Autoria Própria.

Após receber a confirmação de adição do cliente, pode-se conferir no banco de dados que o mesmo foi adicionado com sucesso, conforme ilustrado na Figura 32.

Figura 32: Registro no BD do Cliente Recém Adicionado Fonte: Autoria Própria.

Teste 2 – Cadastro de um novo Produto por um Gerente

Neste caso de teste, o gerente deve cadastrar um novo produto denominado “pratos”, que tem o custo de $15,00, o valor sugerido de venda é $30,00, o valor com desconto é de $25,00 e a quantidade em estoque é 300 unidades. Na Figura 33 e na Figura 34 observam-se os dados incluidos na tela de cadastro de produto e a confirmação da operação de cadastro no banco de dados. Deve-se, ainda, conferir no BD se o cadastro foi feito efetivamente realizado.

Figura 33: Teste da Tela de Cadastro de Produto Fonte: Autoria Própria.

Figura 34: Tela de Confirmação de Cadastro de Produto Fonte: Autoria Própria.

Após receber a confirmação de adição de um novo produto, pode-se conferir que o mesmo foi inserido no banco de dados corretamente, como mostra a Figura 35.

Figura 35: Registro no BD do Produto Cadastrado Fonte: Autoria Própria.

Teste 3 – Cadastro de uma nova Oportunidade por um Vendedor

Neste caso de teste, o vendedor “Seth” deve cadastrar uma nova oportunidade para o cliente “Adrian”, com 30 pratos, 30 garfos e 30 copos. O total da compra deve ser incrementado à medida que novos itens vão sendo adicionados na venda. Pode-se ver o processo de cadastro da nova oportunidade na Figura 36 e na Figura 37.

Figura 36: Teste da Tela de Cadastro de Nova Oportunidade Fonte: Autoria Própria.

Figura 37: Tela de Confirmação de Cadastro de Oportunidade Fonte: Autoria Própria.

Após receber a confirmação de que a nova oportunidade foi inserida, confere-se no banco de dados que o registro referente à oportunidade e também referente à venda foram criados com sucesso, como mostram as Figura 38 e Figura 39. Para efeitos de demonstração, as IDs do vendedor “Seth” e do cliente “Adrian” são ambas 4.

Figura 38: Registro da nova Oportunidade Cadastrada Fonte: Autoria Própria.

Figura 39: Registro da nova Venda Cadastrada Fonte: Autoria Própria.

É importante destacar que, quando oportunidades são cadastradas sem produtos, a criação de uma venda não é automática. Pode-se, dependendo da necessidade, fazer o cadastro de produtos em uma oportunidade que ainda esteja no

Pipeline, em um estágio mais avançado.

Para cobrir o teste das funções do pipeline, foram cadastradas mais 4 oportunidades comerciais, uma para cada combinação de vendedor e cliente. A Figura 40 representa o estado de início do teste, com todas as oportunidades ainda como

Leads.

Figura 40: Tela de Pipeline com As Oportunidades Novas Fonte: Autoria Própria.

Teste 4 – Avanço de uma Oportunidade por um Vendedor

Neste caso de teste, o vendedor “Seth” deve avançar a oportunidade que cadastrou no teste anterior até o estágio “Em Negociação”. Pode-se acompanhar o processo de avanço de oportunidade nas Figura 41 e Figura 42.

Figura 41: Teste de Avanço de Oportunidade na Tela de Pipeline - Estágio Inicial Fonte: Autoria Própria.

Figura 42: Teste de Avanço de Oportunidade na Tela de Pipeline - Estágio Final Fonte: Autoria Própria.

É necessário conferir no BD se as atualizaçõe foram feitas com sucesso, tanto na tabela “Pipeline” quanto na tabela “Pipeline_Log”, que armazena as mudanças feitas em “Pipeline” e é utilizada para calcular as métricas. Os registros dessas ações no BD são ilustrados pelas Figura 43 e Figura 44.

Figura 43: Registro da Oportunidade Cadastrada no Pipeline por "Seth" Fonte: Autoria Própria.

Figura 44: Registros na tabela Pipeline_Log Fonte: Autoria Própria.

Pode-se notar que a tabela Pipeline_Log registrou todas as mudanças de progresso da oportunidade. Percebe-se, também, o avanço dos estágios, como Updates, desde a inserção no sistema, até o avanço para o estágio 5 “Em Negociação”.

4. ESTUDO DE CASO

Nesse capítulo será feito um estudo de caso com dados reais de uma pequena empresa, porém, ofuscados, com o objetivo de manter as informações e a estratégia comercial da empresa em sigilo. A empresa em questão utiliza um sistema de Pipeline comercial por planilha para acompanhar suas oportunidades e o progresso das mesmas. Foram fornecidos registros de oportunidades de 39 clientes diferentes, os quais tiveram seus nomes ofuscados por motivo de sigilo. O Quadro 3 é uma ilustração do Pipeline da empresa, com todos os clientes, suas oportunidades e seus respectivos dados.

Quadro 3: Representação do Pipeline Comercial da Empresa Analisada Fonte: Autoria Própria.

Ao importar os dados no protótipo houve a perda de algumas informações originais, porém, nada que não pudesse ser contornado. A empresa em questão possui dois tipos de itens que fornece: licenças e serviços. Ao importar os dados, optou-se por criar uma oportunidade sem uma venda associada, porém, buscou-se colocar o valor total da venda original na oportunidade. Foi escolhido embaralhar os dados no sistema, ao invés manter as datas originais de cadastro. A maneira como o protótipo calcula as métricas do Pipeline é via a tabela de log do Pipeline, que armazena qualquer ação tomada pela tabela de Pipeline. Cadastrar todas as ações para os dados obtidos da empresa seria muito custoso, e o resultado final seria similar. Pode-se observar na Figura 45 a disposição das oportunidades obtidas do Pipeline Comercial da empresa em questão.

Figura 45: Disposição das oportunidades obtidas da empresa Fonte: Autoria Própria.

Uma diferença perceptível, quando se compara o protótipo à planilha de dados, é de que na planilha se tem oportunidades com dados faltantes. Por exemplo, a data de mudança de estágio nem sempre é inserida pelos usuários do sistema da empresa em questão e isso deixa impossível a obtenção de métricas precisas sobre as oportunidades. O protótipo possui mecanismos embutidos para que isso não aconteça. Por exemplo, as datas de mudança de estagio em uma oportunidade não são dados que o usuário insere, mas sim que o sistema armazena na hora que as ações acontecem.

métricas de usuários. As métricas são exibidas em uma tela dedicada, com a possibilidade de compará-las com métricas de outro usuário. Como pode-se observar na Figura 46, as métricas dos usuários são apresentadas de maneira objetiva. Ter os dados de cada usuário disponíveis para consulta em um único lugar é importante para que se tenha uma visão clara das oportunidade que foram alteradas por este.

Figura 46: Tela de Métricas com Comparação de Dados Fonte: Autoria Própria.

Na Figura 46 nota-se também que as métricas entre o usuário “Ewerton” e “Pedro” foram comparadas de maneira clara e objetiva. Como pode-se observar, o usuário “Ewerton” teve uma performance pior do que o usuário “Pedro”, tendo conseguido apenas 33% do número de Leads de “Pedro”, 50% do número de clientes interessados e 63% a menos do total negociado por “Pedro”. Essas métricas fazem diferença quando se analisa uma equipe comercial e seus rendimentos. Por esse meio, tem-se as informações necessárias para fazer alterações significativas na estratégia comercial da empresa.

Finalmente, lança-se um comparativo entre o sistema de controle de Pipeline utilizado pela empresa e o protótipo de Pipeline Comercial desenvolvido ao longo desse

trabalho. O Quadro 4 faz um comparativo entre as funcionalidades existentes no sistema utilizado pela empresa e as funcionalidades que o protótipo de Pipeline Comercial proporciona ao usuário.

Funcionalidade Sistema da Empresa Protótipo Criado

Disponibiliza dados detalhados de clientes Não Sim Disponibiliza os detalhes de cada venda Sim Sim Disponibiliza as informações de maneira intuitiva Não Sim Permite definir uma chance à oportunidade Sim Não Permite que mais de um usuário utilize o sistema Não Sim Calcula e disponibiliza as métricas dos usuários Não Sim Compara as métricas de usuários por um período Não Sim Controla a inserção de novos dados Não Sim Controla o acesso dos usuários aos dados Não Sim Mantém registro de todas as ações tomadas pelos

usuários

Não Sim

Quadro 4: Comparativo de Funcionalidades dos Sistemas Analisados Fonte: Autoria Própria

Como podemos observar, o protótipo desenvolvido se adequaria ao ambiente dessa empresa. A maior diferença que se nota entre os dois sistemas é que o protótipo desenvolvido consegue calcular métricas a partir das ações tomadas pelos usuários no sistema. É necessário notar que o sistema utilizado pela empresa possui a funcionalidade de definir uma chance para a conclusão do negócio, que não está presente no sistema desenvolvido. Porém, com apenas algumas modificações, o software criado conseguiria suprir todas as necessidades que a empresa possui atualmente e também entregar funcionalidades novas para melhorar a tomada de decisão da empresa.