Universidade Federal de Pernambuco Centro de Informática RELATÓRIO PROJETO 1

Transcrição

1 Universidade Federal de Pernambuco Centro de Informática RELATÓRIO PROJETO 1 istar e BPMN Professor: Jaelson Freire Brelaz de Castro Alunos: Allan Araújo (ala6) Bruno Sampaio (bcgs) Diogo Wellyngton (dwsb) Franclin Cabral (fcmo) Recife, 22 de maio de 2018

2 Sumário 1. Introdução 2 2. Motivação 2 3. Sobre a organização 2 4. do problema 3 5. Modelo proposto 3 6. Metodologia 4 7. Stakeholders 4 8. Requisitos Organizacionais Requisitos Funcionais Requisitos Não-Funcionais 7 9. Modelagem Organizacional com istar Dependência Estratégica (AS-IS) Raciocínio Estratégico (AS-IS) Dependência Estratégica (TO-BE) Raciocínio Estratégico (TO-BE) Modelagem de processos e negócios com BPMN AS-IS TO-BE Conclusão 19 1

3 1. Introdução Esse projeto tem como objetivo mostrar os requisitos levantados para o desenvolvimento de um sistema de auxílio a vendas de produtos, o sistema será usado no apoio de um vendedor autônomo para facilitar suas negociações. Neste projeto será abordado os aspectos da forma como o vendedor realiza suas negociações e vendas atualmente, será descrito problemas e dificuldades que existem no modelo atual do negócio, também será abordada propostas para a melhoria do processo através da análise dos problemas e dos requisitos e especificações levantadas. Foram utilizados como auxílio para a elaboração do sistema a modelagem de seus processos utilizando BPMN (Modelo e notação de processos de negócios), e para a modelagem de suas dependências e raciocínios estratégicos foi utilizado a linguagem I*(IStar). 2. Motivação Visto que no cenário atual do país existe um grande aumento no número de pessoas que estão migrando para o mercado informal, seja pelo crescimento do desemprego no mercado formal ou também pela vontade das pessoas empreenderem e investirem em algum negócio próprio, isso fez com que a equipe olhasse para um possibilidade de trabalhar em cima desse cenário. Para esse projeto foram feitas algumas pesquisas sobre alguns tipos de negócios informais, e o que mais interessou foi o de vendas de roupas que vem crescendo principalmente pelas redes sociais como instagram e facebook onde as pessoas se utilizam dos recursos gratuitos dessas redes para divulgarem seus produtos, sendo que essas aplicações não são feitas com esse intuito e que muitas das vezes são difíceis para gerenciar a comunicação e as vendas. Nosso objetivo é ajudar comerciantes informais a gerenciarem seus negócios de uma forma melhor, trabalhando sobre a comunicação entre o cliente e o vendedor e também a ajudar o vendedor ter um controle maior sobre a entrada das suas mercadorias, divulgação dos seus produtos e recebimento dos seus pagamentos. 3. Sobre a organização Como se trata de um negócio informal quem está no foco do projeto é uma vendedora de roupas, o nome dela é Gilvaneide Maria, 43 anos, ela trabalha com comércio a cerca de 27 anos, atualmente ela trabalha tanto com suas vendas em seu negócio próprio, quanto no mercado formal sendo gerente de uma loja de bijuterias e semi-joias. Atualmente suas vendas de roupas servem como complemento de renda, ela começou com esse tipo de negócio quando ficou por um 2

4 período desempregada mas continua até hoje vendendo e tem a perspectiva de abrir um negócio formal. Ela trabalha vendendo roupas de marca que são compradas em distribuidoras que vendem em atacado diretamente da fábrica, hoje ela já tem uma cartela de clientes que são fidelizados mas ela tem o desejo de expandir seu negócio chegando a outras pessoas que estão mais distantes dela. Hoje todas as suas vendas e controle do negócios são registrados na mão, a comunicação de encomendas são feitas através de ligação, whatsapp e pessoalmente. 4. do problema A vendedora possui problemas quanto a oferta de produtos, otimização de recursos, gestão de finanças e comunicação com cliente. No modelo atual o cliente não tem um catálogo prévio, sendo necessário solicitar produto ao vendedor que se deslocará e buscará no estoque o(s) item(ns) solicitado(s). Em seguida, todo o processo de obtenção do produto é feito pelo vendedor até que o cliente o receba em mãos, e caso o cliente não receba o produto em tempo pré-determinado, todo o processo deverá ser cancelado. O vendedor deve manualmente gerenciar toda sua finança, anotando dívidas, checando pagamentos, gerenciando descontos, etc. Em todos esses processos, os seguintes problemas foram encontrados: Por não possuir um catálogo prévio os clientes acabam por perder mais tempo na busca de um produto, já que é necessário atendimento do vendedor e consequentemente a busca do item; Por não possuir um canal fácil de comunicação, as ofertas de produtos só atingem os clientes quando há um contato com o vendedor; O vendedor fica responsável por analisar o tempo de recebimento das encomendas dos clientes e cancelar as que passarem do tempo preestabelecido; Todo o processo de venda, recebimento de pagamento, cobrança de dívida, abatimento de dívida, é feito de forma manual pelo vendedor, estando este responsável por qualquer erro cometido nas anotações. 5. Modelo proposto Com a análise das dores dos stakeholders ajustamos o nosso sistema para reduzir parcialmente ou por completo os problemas listados no item anterior. A proposta do sistema é disponibilizar ao cliente uma busca personalizada e rápida dos produtos sem a necessidade de um atendimento pessoal do vendedor e um sistema de notificação automática que enviará ofertas periodicamente. Além disso, o sistema conta com verificador periódico de encomendas em trânsito com a finalidade de gerenciar os cancelamentos automaticamente. Todo o processo de venda, 3

5 recebimento de pagamentos, cobranças de dívidas e notificações será realizado pelo sistema, o que trará mais confiabilidade na contabilidade, segurança dos dados e mais controle. Para uma melhor estatística no gerenciamento das vendas, o vendedor terá a disposição feedbacks coletados pelo sistema, enviados pelos clientes ao fim do processo de compras. Com esse modelo de sistema o vendedor terá um possível aumento de lucro no fim do mês, já que os processos mais trabalhosos serão inteligentemente automatizados, além disso o sistema também oferecerá uma forma de fidelizar o cliente utilizando-se de mecanismo de gamificação, pois o cliente acumulará pontos ao comprar produtos e esses pontos poderão ser trocados por outros produtos. 6. Metodologia O problema foi identificado por um dos integrantes (Diogo), conversando com sua mãe (Gilvaneide Maria), dona de um negócio informal de vendas de roupas. O problema foi discutido, identificando as peculiaridades do negócio, a fim de identificar as dores dos stakeholders a fim de propor um sistema que melhorasse a experiência tanto dos clientes quanto da vendedora. Com as entrevistas, nos podemos utilizar do conhecimento de modelagem istar e BPMN através do pistar e Bizagi respectivamente, onde podemos modelar as dependências entre os atores do negócio e modelar os processos. 7. Stakeholders Foram identificados os stakeholders abaixo que seriam mais impactados com o sistema proposto para auxílio em todo processo de vendas: Stakeholders Vendedor Cliente O vendedor, que deseja vender produtos. O consumidor, que deseja fazer compras. 8. Requisitos Organizacionais Nesta seção estão listados os requisitos funcionais e não funcionais do sistema, que foram levantados através das entrevistas feitas com os stakeholders, cada requisito contém sua descrição e sua prioridade no projeto, criamos três tipos de prioridades para cada um dos requisitos, são elas: Alta : São os requisitos essenciais para todo o sistema funcionar, eles servem de base para outros e a falta deles tem um impacto muito grande; Média : São os requisitos que não são essenciais para o funcionamento do sistema mas a falta deles causa um desempenho menor do sistema. 4

6 Baixo : São requisitos adicionais do sistema que não são essenciais e as suas faltas não causam impactos no sistemas mas sua adição pode acrescentar mais ao sistema. 8.1 Requisitos Funcionais RF001 - Mostrar Produtos do Catálogo O sistema deve exibir outras opções de produtos listados no catálogo de vendas. Alta RF002 - Recomendar produtos O sistema deve recomendar produtos para o cliente, baseado na Análise de Histórico de compras. Baixa RF003 - Analisar histórico de compras do cliente O sistema deve analisar o histórico de compras dos usuários, comparar com com quem comprou produtos similares para fornecer sugestão. Baixa RF004 - Abater Pontos do Cliente Ao efetuar uma compra com pontos, o sistema deve garantir que os pontos desse usuário serão abatidos. Média RF005 - Registrar Vendas Ao efetuar uma venda, o sistema deve registrar a venda com os dados de qual usuário comprou, qual produto, a quantidade e o valor da compra efetuada. Alta RF006 - Gerar Boletos Ao efetuar uma venda, onde uma dívida é registrada, o sistema deve gerar o boleto para o cliente com a devida data de pagamento e o valor correto. Média RF007 - Notificar Clientes de Descontos Ao ter o estoque reposto, o sistema deve enviar atualizar os clientes por meio de notificação por da chegada de novos produtos. 5

7 Baixa RF008 - Gerar Ordem de Venda Ao receber pagamento do cliente, o sistema deve gerar uma ordem de venda, que será necessário para o envio do produto pelo vendedor. Alta RF009 - Gerar Ordem de Troca Ao receber solicitação de troca, o sistema deve gerar uma ordem de troca com a descrição do produto e sua avaria, caso exista alguma, e o motivo da troca, para que a mesma possa ser executado pelo vendedor com o intuito de enviar o novo produto para o cliente. Média RF010 - Abater Dívida Ao ser pago a dívida gerada pelo boleto, o sistema deve automaticamente abater a dívida do cliente, subtraindo o valor pago do montante devedor. Média RF011 - Cadastrar Cliente O sistema deve prover uma interface para que o próprio usuário se cadastre no sistema e possa acessar o mesmo a fim de visualizar os produtos disponíveis para venda. Alta RF012 - Fazer Login O sistema deve ser capaz de efetuar login por meio de e senha particulares do usuário para permitir o acesso ao mesmo. Alta RF013 - Enviar Feedback O sistema coleta feedback do usuário. Média RF014 - Receber Pagamento O sistema deve ser capaz de se conectar com sistemas de cartões (Visa/Master/PayPal) ou identificar pagamentos por meio de boletos com acesso às transações bancárias da empresa a fim de identificar o pagamento feito pelo cliente. 6

8 Alta 8.2 Requisitos Não-Funcionais RNF001 - Segurança O sistema deve fornecer segurança para os dados dos usuários. As informações de cada usuário não devem ser acessadas por outras pessoas. Alta RNF002 - Desempenho O sistema deverá possuir um tempo de resposta baixo. Evitando pedir informações desnecessária ao usuário. Média RNF003 - Usabilidade O sistema deverá ser fácil de utilizar de forma intuitiva, o usuário não deve perder muito tempo procurando as funcionalidades da aplicação. Média RNF004 - Compatibilidade O usuário deve ser capaz de acessar o sistema por meio de qualquer interface web compatível com Chrome, Firefox, Safari e Edge. Baixa RNF005 - Disponibilidade O usuário deve ser capaz de acessar o sistema a qualquer momento e com acesso a internet. Alta 7

9 9. Modelagem Organizacional com istar Todas as versões dos modelos istar As Is SD e SR, To Be SD e SR se encontram em anexo abaixo. 9.1 Dependência Estratégica (AS-IS) A Figura 1 Strategic Dependency mostra as dependências entre os atores identificados. 8

10 9

11 9.2 Raciocínio Estratégico (AS-IS) 10

12 11

13 9.3 Dependência Estratégica (TO-BE) 12

14 13

15 9.4 Raciocínio Estratégico (TO-BE) 14

16 15

17 16

18 9.5 Modelagem de processos e negócios com BPMN AS-IS 17

19 9.5.2 TO-BE 18

20 10. Conclusão Durante a implementação do projeto, com os conhecimentos adquiridos em sala de aula, foi possível analisar um problema do mundo real e elaborar uma possível solução na qual permitiu melhorar os processos encontrados em uma organização, com isso, conhecermos realmente uma aplicação do conteúdo abordado em sala, logo, a equipe pode aprender mais sobre o conteúdo. É importante ressaltar, que o desenvolvimento dos modelos, usando BPMN e i* para os processos e para a representação da organização, fez a equipe entender melhor como funciona o processo de modelagem, além de tornar mais fácil o entendimento do funcionamento dos processos, dado que a abordagem visual dos recursos usados traz uma melhor perspectiva ao analisar as relações entre os atores, com isso, a equipe conseguiu adquirir conhecimento prático na área. É notório observar que este projeto fez a equipe entender mais sobre modelagem de processos, que contribuiu para fornecer uma visão maior das necessidades que afetam a organização. 19

21 Formulário de participação Nomes Esforço (%) Assinatura Allan Araújo (ala6) 25% Bruno Sampaio (bcgs) 25% Diogo Wellyngton (dwsb) 25% Franclin Cabral (fcmo) 25% 20