Embed Size (px)
Citation preview
SISTEMA DE GERENCIAMENTO DE
MICRONEGÓCIO ESPECIFICAÇÕES DE REQUISITOS E VALIDAÇÃO DE SISTEMAS
Ailson da Cruz Gonçalves Tavares Danilo Vasconcelos de Freitas Emanuel Felipe Inácio da Silva Nara Souza de Andrade Professor: Jaelson Freire B. de Castro
Recife, 03 de Maio de 2019
Índice
Índice 2
Introdução 3 Sobre o empreendimento 3 Descrição do problema 3 Stakeholders 3
Raphael (Vendedor): 3 Compradores (Cliente): 3 Mãe e Esposa de Raphael (Produtor): 4
Sistema proposto 4
Modelagem de Processo de Negócio (BPMN) 5 AS IS: 5 TO BE: 8
Modelagem Organizacional (iStar) 11 AS IS: 11 TO BE: 13
Apêndice 16
Conclusão 20
Formulário do Relatório da Equipe 21
Introdução
Sobre o empreendimento
Raphael é um funcionário do projeto CIn/Motorola, sediado no Centro de Informática da Universidade Federal de Pernambuco. O projeto CIn/Motorola possui mais de 150 funcionários, que circulam em suas dependências incluindo a copa, e tem contato com os doces vendidos por Raphael. Cada doce tem um valor e nem todos estão disponíveis todos os dias. São eles: Bombons, Trufas, Brownies, Brownies Recheados, Cones de Chocolate e Cupcakes.
Descrição do problema
Para complementar sua renda, Raphael vende doces diversos na copa da empresa, num modelo onde ele disponibiliza os doces no começo do dia, e recolhe o dinheiro no final do dia. Para isso, ele disponibiliza os doces numa caixa, onde cada comprador pode abrir e retirar o que deseja. Ele disponibiliza também uma caixinha de moedas para que os compradores possam deixar o pagamento, e usar o dinheiro contido na caixa para retirar troco. Além disso, compradores podem optar pela opção de pagar online, realizando transferências para as contas (NuBank, Banco do Brasil e PicPay) de Raphael, cujos dados ele disponibiliza num cartão próximo a caixa de doces.
Há também o cenário de um comprador resolver pegar os doces e pagar depois, anotando o nome num caderno para que Raphael saiba quem falta pagar. O principal problema de Raphael consiste em controlar a lista de devedores, principalmente devido ao fato de pessoas pegarem doces e não anotarem o nome no caderno. Nesses casos Raphael não consegue fazer o controle de quem deve, e foi observado que geralmente, o balanço diário e semanal é negativo levando em conta a quantidade de mercadoria disponibilizada de manhã e a quantidade em caixa no fim do dia.
Para controlar e gerenciar seu negócio, Raphael conta com uma planilha [apêndice A] atualizada diariamente, preenchida manualmente, onde ele controla informações como o status do pagamento, a quantidade de dinheiro recebido, o nome das pessoas que estão devendo e qual tipo de doce foi vendido. A atualização dessa planilha é cansativa e dá margem a erros. Assim como o processo de cobrança se torna intrusivo e dificulta a boa relação de Raphael com seus clientes.
Stakeholders
Raphael (Vendedor):
Raphael tem uma série de problemas de gerenciamento que atrapalham sua efetividade e seus lucros com o negócio.
Compradores (Cliente):
Os clientes de Raphael tem a vontade de comprar doces, e buscam fazê-lo de forma rápida e objetiva, sem complicações.
Mãe e Esposa de Raphael (Produtor):
A produção dos doces vendidos por Raphael é feita por sua mãe, e sua esposa.
Sistema proposto
Após realizadas entrevistas com Raphael, e de diária observação do processo de compras dos doces, foi possível observar com a ajuda da modelagem BPMN e i*, a necessidade de automatização de processos no gerenciamento do negócio de Raphael.
Visando minimizar os problemas com pagamentos não realizados, e o controle da lista de pessoas com pagamentos à realizar, bem como diminuir o esforço manual de preenchimento e atualização da planilha de controle, propomos um sistema de gerenciamento do negócio, combinado com a utilização de uma Vending Box, idealizada com base no padrão de Vending Machines existentes, porém com especificidades destinadas à atender o processo de negócios de Raphael.
O sistema disponibilizado em plataforma Mobile consiste em um aplicativo com interface de vendedor, para que Raphael possa acompanhar as movimentações de vendas de doces e registros de novos compradores com pagamento ainda não realizado, assim como informá-lo disso através de notificações. O sistema será também disponibilizado com interface de cliente, para que os compradores dos doces de Raphael tenham acesso à Vending Box que contém os doces.
A Vending Box é uma caixa que possui compartimentos para os doces, com trava eletrônica para cada compartimento. A manipulação da vending box é realizada pelo cliente através do aplicativo, com o qual interage visualizando a lista de doces disponíveis, realizando o processo de pagamento e por fim a liberação do(s) compartimento(s) contendo o(s) doce(s) comprado(s). O sistema então atualiza a planilha de controle de caixa diário, e notifica o vendedor sobre a compra com pagamento realizado, ou da inclusão de um novo cliente na lista de devedores.
Modelagem de Processo de Negócio (BPMN)
AS IS:
O processo AS IS completo está disponível no [Apêndice A]. Abaixo (Figura 1.1), apresentamos o processo que engloba os atores Produtor e Vendedor. O processo inicia com a solicitação de doces realizada pelo Vendedor ao Produtor.
Figura 1.1: Processo de Venda (Produtor vs. Vendedor)
Após receber os doces do Produtor, o Vendedor faz a contagem de cada tipo de doce (bombons, trufas, brownies, cone de chocolate, brownies recheados e cupcakes) e calcula o valor total dos produtos que serão comercializados no dia. Para cada dia, é criada uma planilha de controle de caixa, atualizada ao final do dia pelo Vendedor. O Vendedor leva os doces para a copa, juntamente com as informações para pagamento online e a caixinha de moedas para pagamento em dinheiro, além do caderno de inadimplentes. Ao final do expediente, a caixa de doces e a caixa de moedas são recolhidas, junto com o caderno de inadimplentes. Todas as atividades são realizadas de forma manual.
Analisando o processo sob a visão do Cliente, apresentada abaixo (Figura 1.2), verificamos que ele se inicia com a ida do Cliente à copa. O Cliente seleciona o(s) doce(s) que deseja comprar e escolhe um dos métodos de pagamento. Estes podem ser: pagamento em dinheiro, pagamento online (PicPay, Banco do Brasil ou NuBank), ou ainda, se o cliente desejar, poderá pagar depois e escrever seu nome no caderno de inadimplentes, junto com o(s) doce(s) coletado(s) e o valor pendente.
Figura 1.2: Processo de Venda (Cliente)
O processo de cobrança (Figura 1.3) expõe as tarefas diárias que Raphael executa a fim de reduzir seu prejuízo devido a inadimplência de compradores.
O processo se inicia com a checagem no caderno dos nomes de pessoas que ainda não pagaram o que consumiram. É realizado então um contato via chat lembrando da dívida. Uma vez que o cliente realize o pagamento, e notifique Raphael confirmando que pagou, ele atualiza o caderno de inadimplentes e o processo é finalizado.
Figura 1.3: Processo de cobrança
TO BE: O processo TO BE completo está disponível no [Apêndice B]. Abaixo (Figura 2.1),
apresentamos o processo que engloba os atores Produtor e Vendedor. O processo inicia com a solicitação de doces realizada pelo Vendedor ao Produtor.
Figura 2.1: Processo de Venda (Produtor vs. Vendedor)
Após receber os doces do Produtor, o Vendedor leva a Vending Box para a copa e
organiza os doces nos compartimentos (slots), enfileirados de acordo com o tipo. A Vending Box
realiza a contagem dos doces e calcula o valor total dos produtos que serão comercializados no dia. Automaticamente, é gerada a planilha de controle de caixa, que será atualizada a cada transação. O Vendedor então inicia a operação da Vending Box (que irá travar todos os slots) e esta começa a aguardar um pedido. Assim que recebe um pedido de um Cliente (processo detalhado mais adiante), a Vending Box destrava os slots correspondentes aos doces solicitados pelo Cliente e aguarda que os doces sejam retirados. Após 1 minuto, todos os compartimentos são travados novamente e o Vendedor é notificado em seu aplicativo sobre a finalização de uma compra ou sobre uma atualização na lista de inadimplentes. Ao final do expediente, o Vendedor recolhe a Vending Box.
O processo de venda sob a visão do cliente (Figura 2.2) se inicia com a tarefa de ir à copa. Através do aplicativo, o cliente verifica os doces disponíveis para compra, realiza a sua escolha de quais e quantos doces vai querer e prossegue com o processo de compra até confirmar o pedido.
Ocorre então o subprocesso de selecionar o método de pagamento. Com a opção de registrar o nome na lista de inadimplentes para pagamento posterior, ou de selecionar um canal de pagamento e realizá-lo no momento. A compra é então finalizada, e após aguardar a Vending Box liberar os doces, o cliente retira os doces comprados e o processo é então finalizado.
Figura 2.2: Processo de Venda (Cliente)
O modelo TO BE de cobrança busca facilitar a relação do vendedor com o cliente. O
processo inicia quando o vendedor checa a lista de inadimplentes no aplicativo, e envia o lembrete de pagamento para essas pessoas.
Figura 2.3: Modelo BPMN cobrança
Ao receber o lembrete de pagamento, os clientes seguem para realizar o pagamento
escolhendo o método de pagamento. Após escolher o canal desejado e confirmar o pagamento, é realizada a confirmação de resolução de pendência através do aplicativo, e uma notificação é enviada ao Vendedor, que checa a lista atualizada na sua visão do aplicativo, e assim o processo é encerrado.
Modelagem Organizacional (iStar)
AS IS: O processo AS IS completo está disponível no [Apêndice C]. Abaixo (Figura 3.1),
apresentamos o processo que engloba os atores Produtor e Vendedor.
Figura 3.1: Modelo iStar Produtor vs. Vendedor
No diagrama, destacamos os principais anseios do Vendedor sobre seu negócio: Ter
lucro e Reduzir possíveis prejuízos. Apoiando esses desejos, temos como objetivos Gerenciar
Negócio e Realizar Cobrança de Inadimplentes. Este último é baseado nas tarefas de checar os nomes do caderno de inadimplentes e realizar a cobrança diretamente pelo Hangouts da empresa. A forma como esse processo é realizado acaba atrapalhando um pouco a relação de Raphael com seus clientes.
Com relação ao objetivo Gerenciar Negócio, vemos que sua base está no objetivo Vender Doces que, por sua vez, é apoiado pelas tarefas Contar doces a serem comercializados no dia (dependente do recurso Doces disponibilizado pelo Produtor), Calcular valor total dos produtos do dia, Criar planilha diária de controle de caixa, Levar doces para a copa, Colocar caderno de inadimplentes na copa, Colocar caixinha de moedas na copa, Colocar dados bancários para pagamento online na copa, Recolher os doces que sobraram ao final do dia, Recolher a caixinha de moedas, Recolher o caderno de inadimplentes e Atualizar a planilha de acordo com as informações coletadas pelo Vendedor.
Para o ator Cliente, destacamos o anseio de Comer doces. Os dois principais objetivos que possuem uma relação de “ajudar” o ator a realizar esse anseio são Comprar doces e Pegar doces e pagar depois. Esses objetivos diferem justamente no ato de consumar todo o processo de compra, ou de realizar o objetivo e pagar posteriormente.
Figura 3.2: Modelo iStar Cliente
Tarefas que buscam realizar o objetivo “Comprar doces” são listadas como “Ir até a
copa”, “Escolher doce(s)”, “Pegar doce(s)” e “Escolher método de pagamento”. Para o objetivo de “Pegar doces e pagar depois”, o Cliente tem as tarefas alternativas
de “Registrar dívida” ou “Não registrar dívida”. As principais relações destacáveis das tarefas dos objetivos citados acima, são entre a
tarefa de “Voltar para pagar” que é definida pela tarefa “Escolher método de pagamento”. A tarefa “Pegar doce(s)” que participa tanto das tarefas de “Registrar dívida” quanto de “Não registrar dívida”.
TO BE: O processo TO BE completo está disponível no [Apêndice D]. Abaixo (Figura 4.1),
apresentamos o processo que engloba os atores Produtor e Vendedor.
Figura 4.1: Modelo iStar Produtor vs. Vendedor
Com relação ao ator Vendedor, temos como principais anseios Ter lucro, Reduzir
prejuízos e Atrair clientes, estes dois últimos dando suporte ao primeiro. Quanto ao desejo de Atrair clientes, o objetivo de Simplificar processo de compra (suportado pelo sistema) ajuda em sua execução. Contudo, esse anseio ainda pode ser prejudicado pelo objetivo de Realizar cobranças, o qual dá apoio ao anseio de Reduzir prejuízos. Sobre o objetivo de Realizar cobranças, sua execução é feita pelas tarefas de Enviar lembrete de pagamento (que se relaciona com a visão de Cliente do sistema) e Receber notificações de novos inadimplentes.
Quanto ao objetivo de Gerenciar negócio, temos este baseado no objetivo de Vender doces e na tarefa Receber notificações de compras (dependente da notificação emitida ao final de cada transação). Vender doces tem sua execução baseada nas tarefas: Organizar doces na box (dependente do recurso Doces disponibilizado pelo Produtor), Levar box para a copa, Iniciar a box e Recolher a box.
O modelo iStar Cliente (Figura 4.2), destaca os anseios de “Comprar doces de forma objetiva e rápida” como uma relação de ajudar o principal anseio de “Comer doces”.
Temos então o objetivo de “Comprar doces” que realiza o anseio de comprar doces de forma rápida e objetiva. As tarefas que o executam são “Ir até a copa”, “Verificar doces disponíveis no aplicativo”, “Selecionar doce(s)” e “Pegar doces”.
Figura 4.2: Modelo iStar Cliente
Para o modelo da Vending Box (Figura 4.3), temos o principal anseio de “Tornar processo de compra mais seguro”, e o anseio de “Automatizar compra” que ajuda a realizar o anterior.
As tarefas de “Contabilizar doces”, “Calcular valor total dos produtos do dia”, “Gerar planilha de controle de caixa”, “Destravar compartimento(s) adequado(s)”, “Travar compartimentos” e “Atualizar planilha” são realizadas pela Vending Box para realizar o objetivo de “Gerenciar pedidos”, que ajuda a realização do anseio de “Automatizar compra”.
Figura 4.3: Modelo iStar Vending Box
Para a Visão Cliente (Figura 4.4), a fim de ajudar a realização do anseio de “Simplificar processo de compra” temos o anseio de “Automatizar compra”. O objetivo “Gerenciar pedido” ajuda na sua realização.
Esse objetivo tem como tarefas necessárias para sua realização “Adicionar doces ao carrinho de compras”, “Confirmar pedido”, “Confirmar pagamento”, “Finalizar compra” e “Escolher método de pagamento” que é composta das duas tarefas alternativas de “Selecionar canal de pagamento” e “Registrar pendência na lista de inadimplentes”.
Figura 4.4: Modelo iStar Visão Cliente
O modelo de Visão Vendedor (Figura 4.5), busca mostrar como o anseio do vendedor de “Gerenciar bem o negócio” é realizado através do sistema na visão do vendedor. Os dois objetivos que ajudam a realização do anseio principal são “Acompanhar lista de inadimplentes” e “Acompanhar transações”.
Figura 4.5: Modelo iStar Visão Vendedor
Apêndice
[Apêndice A]: Modelo BPMN AS IS
[Apêndice B]: Modelo BPMN TO BE
[Apêndice C]: Modelo iStar AS IS
[Apêndice D]: Modelo iStar TO BE
[Apêndice E]: Copa onde Raphael deixa os doces a venda
[Apêndice F]: Estrutura de venda dos doces (contidos nos depósitos), uma lista para anotar inadimplência, a
caixinha de moedas, e o papel contendo as informações bancárias para pagamento.
Conclusão Diante do problema encontrado pela equipe, foi proposta uma solução inovadora que
conta com o auxílio de um dispositivo de hardware o qual chamamos Vending Box. O uso de tal dispositivo se fez necessário devido à carência de um modo de automaticamente controlar o acesso aos doces para usuários não identificados. Tal solução é apoiada pelo uso de um sistema mobile que busca automatizar o processo de gerenciamento do negócio de venda de doces.
Sob orientação do professor, foram realizadas as modelagens BPMN e iStar do estado atual do processo (AS IS), o que nos ajudou a ter a visão mais clara do fluxo de atividades, bem como das relações de dependência entre os atores do modelo. Em seguida, ao realizar a modelagem do processo “TO BE” propondo nossa solução, foi possível identificar a efetividade da solução proposta sob o cenário de problemas relatados pelo principal stakeholder do sistema, Raphael.
Do ponto de vista acadêmico, a equipe reconhece um significativo avanço e ganho de conhecimento de forma prática, reforçando a teoria apresentada em sala de aula. A habilidade de reconhecer e analisar requisitos organizacionais, e a experiência prática nos modelos BPMN e iStar.
Formulário do Relatório da Equipe
Nome Papel Esforço Assinatura
Ailson da Cruz
- Modelagem BPMN “AS IS”
15%
- Revisão modelagem iStar “AS IS”
- Revisão modelagem BPMN “TO BE”
- Revisão relatório
Danilo Vasconcelos
- Revisão modelagem iStar “AS IS”
15% - Revisão modelagem iStar “TO BE”
- Revisão relatório
Emanuel Silva
- Contato com os stakeholders
35%
- Revisão modelagem BPMN “AS IS”
- Revisão modelagem iStar “AS IS”
- Modelagem BPMN “TO BE”
- Revisão modelagem iStar “TO BE”
- Relatório
Nara Souza
- Modelagem BPMN “AS IS”
35%
- Modelagem iStar “AS IS”
- Modelagem BPMN “TO BE”
- Modelagem iStar “TO BE”
- Relatório
