Especificação de Requisitos & Validação de Sistemas   

 Projeto I: Modelagem em BPMN e iStar sobre processo da Total 

Combustíveis S/A   

Alunos:  

Bruno Ferys Ferreira da Silva  

Danilo Matheus de Oliveira Pedrosa  

Julio Alexandre Pedrosa de Melo  

Moiseis Fabien Gauthier  

Data: 29/04/16 

 Professor: 

 Jaelson Freire Brelaz de Castro 

    

  

 

 

 Índice 

 1. Introdução....................................................................................................3  2. Descrição do problema encontrado.............................................................4  3. Descrição da modelagem em BPMN...........................................................5  4. Descrição da modelagem em i*...................................................................9  5. Conclusão....................................................................................................15  6. Apêndices....................................................................................................16     

2 

 

1. Introdução  Este projeto tem como objetivo modelar um processo de negócio utilizando a                       

notação BPMN e Istar. O processo (real) a ser modelado pertence a empresa Total                           Combustíveis S/A, empresa do ramo de combustíveis que atua no mercado desde                       1996 e hoje assume a 5º posição no ranking das maiores distribuidoras de                         combustíveis líquidos do Brasil. O processo a ser avaliado é o de gerenciamento de                           demandas à equipe de sistemas. 

A modelação do processo faz parte (principalmente) da equipe de sistemas da                       empresa, que é formada por aproximadamente 6 colaboradores mais servidores                   terceirizados. A equipe é reponsável pelo suporte, manutenção e desenvolvimento do                     ERP Protheus, que possui uma média de 250 usuários internos/externos, todos                     colaboradores da empresa. O sistema utilizado para o gerenciamento das demandas é                       o OTRS, um software open source de incidentes livre que também é utilizado como um                             canal de comunicação com o cliente. A equipe possui 3 níveis hierárquicos de                         desenvolvedores, são eles: N1, N2, N3. Tendo como N1 responsável apenas por                       chamados de suporte, o N2 dando apoio quando necessário aos suporte e realizando                         pequenos desenvolvimentos do sistema e o N3 sendo utilizado apenas para                     desenvolvimentos mais complexos e duradouros. Todos os clientes da área de                     sistemas são os próprios colaboradores da empresa de diversas áreas (Transportes,                     RH, Controladoria, Marketing, Operação, etc…) onde todos são usuários do ERP                     Protheus e que utilizam do OTRS para a abertura das demandas. Os servidores                         terceirizados são gestionados de maneira distinta e no nosso caso não serão                       considerados, tanto como uma pequena equipe de sistemas que é responsável pela                       área do BI (Business Intelligence). 

     

3 

 

2. Descrição do problema encontrado  

O processo atualmente utilizado pela equipe de sistemas nas soluções de                     demandas não possui modelagem implementada, ele segue as boas práticas da                     empresa. É utilizado uma versão do OTRS pouco customizada e de um documento de                           Estudo de Viabilidade (em anexo no apêndice 6.1), nos casos de demandas que                         requerem um desenvolvimento mais complexo. O EV foi criado basicamente pelas                     boas práticas de gestores e com acordos estabelecidos entre as partes interessadas.                       Como já descrito anteriormente, o canal de comunicação utilizado entre o cliente e a                           equipe de sistema é um sistema de gerenciamento de incidentes open source,                       chamado OTRS. Apesar de ser um sistema open source, ele é muito pouco                         customizado para atender as necessidades e será uma das partes modificadas durante                       o processo de modelamento. 

Após uma análise do processo, foram identificadas diversas falhas e tarefas                     burocraticas e desnecessárias. Esses problemas foram relatados tanto do lado dos                     clientes como do lado da equipe de sistemas. Um dos principais problemas relatados                         pela equipe de sistemas (através das entrevistas, apêndice 6.4) foi a divisão de tarefas                           desordenada, onde no momento que é aberto um chamado para solução/análise de um                         problema, a escolha de quem será o responsável pelo atendimento da demanda é                         praticamente aleatória. Resultando em casos em que um analista N1, não tendo                       capacidade de atender aquele chamado por motivos diversos (de conhecimento, por                     exemplo) perde muito tempo tentando resolver o problema até concluir que necessita                       de apoio para realizar a atividade (ou até mesmo repassá­la), no caso de um analista                             N2.  

Outro problema é a burocracia relatada tanto por parte dos desenvolvedores                     quanto dos clientes, quando se trata de uma solução que requer desenvolvimento.                       Para se autorizar o início do desenvolvimento de uma atividade, é necessário uma                         série de assinaturas e avaliações por parte dos altos gestores, que muitas vezes não                           se encontram acessíveis, ocasionando um atraso no início das atividades. Atraso que                       reflete nos índices de avaliação da equipe, pois ambos os lados possuem o critério de                             “cumprimentos de prazos” na avaliação interna.         

4 

 

3. Descrição modelagem BPMN  Como explanado anteriormente, não existe modelagem para o processo AS­IS, sendo                     apresentado em partes abaixo o processo TO­BE, construído pela equipe. Serão                     explanados os processos à partir de uma visão de atores. O processo completo                         encontra­se em anexo no apêndice 6.1.    3.1. Cliente 

   (Modelo do cliente na modelagem)  

3.1.1. O processo é iniciado pela solicitação de demanda por parte do cliente, que é                             feita prioritariamente através do sistema OTRS. Há casos em que é feita uma pré                           demanda por outros meios de comunicação (como correio eletrônico, por exemplo),                     mas é orientado a abertura de demanda via chamado OTRS, para o processo seguir                           corretamente.  3.1.2. Em um segundo momento, o cliente recebe uma mensagem do sistema com o                           parecer do EV por parte do P.O. que fez um estudo de viabilidade da demanda e                               retornou, caso a viabilidade foi positiva, todas as características da solução da                       demanda, como por exemplo o prazo para desenvolvimento. O cliente agora terá que                         avaliar o EV e retornar ao P.O. um sinal positivo para se iniciar o projeto ou um sinal                                   negativo, discordando do EV. Caso a viabilidade tenha sido negativa pelo P.O, o EV é                             descartado e é necessário a abertura de um novo para uma nova demanda.  3.1.3. Em um terceiro momento, o Cliente recebe a solução da demanda, para começar                           a realizar a homologação da solução, retornando um sinal positivo ou negativo da                         solução para o analista. 

5 

 

  3.2 Dispatcher 

 (Modelagem do dispatcher dentro do modelo TO­BE)  

 O Dispatcher recebe a solicitação de demanda do cliente através de uma mensagem                         do sistema e prontamente inicia a tarefa de classificar a demanda recebida dentro do                           OTRS, após esses acontecimentos o Dispatcher encaminha a solicitação da Demanda                     para dois caminhos possiveis, definidos por um gateway baseado em eventos,                     dependendo da resposta obtida a solicitação será enviada ao analista ou o PO.                    

6 

 

3.3 Analista  

(Modelagem do Analista no BPMN)    O fluxo do analista é apenas um. Diferentemente de como era o processo (AS­IS), o                             analista agora tem apenas uma função, a de desenvolver a solução. No máximo ele vai                             estudar a solução que já está descrita no EV. Após receber uma mensagem do sistema                             com uma demanda (3.3.1), caso seja uma solução conhecida (advinda diretamente do                       Dispatcher) ele simplesmente estuda a solução já existente e a replica, sem                       necessidade de desenvolvimento. Já nos casos de soluções desconhecidas, se ela                     veio pelo P.O. ele terá o auxílio do EV, entretanto, caso tenha vindo diretamente do                             Dispatcher ele a desenvolve de maneira autônoma. Terminada a fase de                     desenvolvimento, o analista realiza testes e envia a solução para o cliente homologa­la. Ao término da homologação por parte do cliente, o analista recebe uma mensagem do                           sistema com o resultado da homologação (3.3.2). Em caso de homologação positiva,                       ele aplica a solução e fecha a demanda no sistema. Em caso de homologação                           negativa, ela volta para a análise da demanda e recomeça o fluxo.           

7 

 

3.4 PO  

    (Modelagem do PO no BPMN) 

 O P.O. (Project Owner) é o responsável por demandas mais complexas que                       necessitam de um tempo de desenvolvimento maior. As demandas são enviadas                     diretamente pelo Dispatcher, através do OTRS. O papel do P.O. é avaliar a demanda e                             criar um EV (Estudo de Viabilidade) informando a possibilidade do desenvolvimento                     dessa demanda e prazo para desenvolvimento. Após essa análise, ele envia o EV para                           o cliente que, em caso de viabilidade positiva, deve concordar ou não com as                           especificações do P.O. Em um segundo momento, o P.O recebe o retorno do cliente concordando ou não com                             o EV construindo pelo P.O. Em caso positivo, o P.O cria as Histories de                           desenvolvimento (fragmentos de atividades) e as envia para os analistas, iniciando­se                     assim o desenvolvimento. Caso o cliente tenha dado um parecer negativo, a demanda                         retorna para análise para se tentar ajustar o que ocasionou a negação do EV.               

8 

 

4. Descrição da modelagem em i*  4.1 ModelagemSD

  

               (Modelo SD completo)  Após a modelagem do processo no BPMN, foi iniciado a modelagem dos objetivos na                           linguagem i*. Primeiramente o modelo SD foi abordado, com os relacionamentos de                       objetivos entre os atores bem definidos, de acordo com o que foi apurado durante o                             projeto. Há um total de cinco atores nesta modelagem, os mesmo que foram abordados                           durante o BPMN. Fica visível o destaque do OTRS, sistema que permeia todo o                           processo, e é indispensável para o sucesso do mesmo. 

       

9 

 

  4.2 Modelagem SR  Passada a fase de modelagem SD, o próximo passo foi modelar cada agente de forma                             mais incisiva para criação do modelo SR.  4.2.1 Cliente

    (Modelo SD do Cliente) 

  O cliente solicita demanda para ser armazenada pelo sistema, analisada e solucionada                       pelos responsáveis. E após a análise, ele irá receber um EV para ser aprovada por ele                               e enviar seu parecer para que possa receber uma solução de qualidade.   

10 

 

4.2.2 PO

  

                    (Modelo SD do PO)  Recebe demanda classificada, analisa ela para criar um EV e enviar para o cliente para                             que haja aprovação. Se o EV for aprovado, o PO irá enviar para o sistema que se                                 encarregará de enviar para ser desenvolvida a solução necessária.          

11 

 

  4.2.3 Analista 

                     (Modelo SD do Analista) 

  O analista depende do OTRS para receber uma demanda que veio do Dispatcher, ao                           qual ele ira estudar se há uma solução já conhecida para aplicá­la ou desenvolver uma                             solução nova. Caso não haja, ele irá desenvolver uma possível solução, testá­la,                       aplicá­la e enviar para o sistema a solução para que haja a homologação da mesma.     

12 

 

  4.2.4 OTRS 

      (Modelo SD do OTRS) 

   Seu objetivo principal é ter a comunicação gerenciada e armazenar a solicitação. Para                         atingir o objetivo, o OTRS começa com o recurso para uma solicitação de demanda do                             Cliente, seguido pela tarefa de armazenamento. Recebe classificação da demanda do                     Dispatcher, armazena e envia ou para o analista ou para o dispatcher (depende da                           

13 

 

classificação). O P.O. recebe o EV (Estudo de Viabilidade) e armazena para o cliente                           para uma avaliação. Depois da avaliação aprovada ela é encaminhada para o P.O..    4.2.5 Dispatcher  

          (Modelo SD do OTRS) 

  O Dispatcher recebe demandas e em seguida, tem a tarefa de classifica­lás, e alcança                           seu objetivo para poder enviá­las para o sistema,além disso ele tem um softgoal que                           almeja uma demanda classificada corretamente,para facilitar as tarefas em outros                   atores.       

14 

 

5. Conclusão  Após o término da modelagem do BPMN e do iStar, conseguimos criar documentos                         que, caso a equipe adote essa modelagem, renderiam alguns benefícios para a                       mesma. Problemas identificados nas entrevistas realizadas como desordem no                 alocamento de tarefas e de assinaturas desnecessárias que atrasavam o andamento                     do processo foram solucionadas com a figura do DISPATCHER e com a aprovação de                           um P.O., respectivamente.  O uso mais eficiente do sistema de comunicação entre cliente e a equipe de sistemas,                             OTRS, foi um importante critério para o andamento do processo. Podemos destacar                       também o papel do analista que no processo AS­IS (que não existia de fato) tinha um                               papel maior do que o desenvolvimento, atrasando o processo. Na modelagem TO­BE                       ele adquire o único papel de desenvolvedor, alocando todo o seu tempo para essa                           tarefa. Além de todo o conhecimento adquirido sobre o assunto que será aplicado mais                           adiante.                         

15 

 

6. Apêndice 6.1 EV (Estudo de Viabilidade)   

                                     . 

(Primeira página do EV) 

16 

 

 (Segunda Página do EV) 

            

17 

 

6.2. Estrutura organizacional da Total Combustíveis (resumida) descrita  

                      

18 

 

6.3 Modelo BPMN  

(Modelo BPMN completo)    

19 

 

6.4 Entrevistas  Entrevistado 1: Ismael Santos, analista N1 ­  isantos@totalcombustiveis.com.br  Qual principal problema você enfrenta nas soluções das demandas dos clientes?  “O principal problema é a falta de clareza do que o cliente quer, fazendo com que fique                                 difícil saber se o sistema nos possibilita implementar o que o cliente quer. E ainda                             saber se eu com minha experiência consigo desenvolver isso. Com isso perco um bom                           tempo analisando o problema e muitas vezes tenho que pedir apoio de outro analista. Depois de conseguirmos avaliar se é possível desenvolver a demanda solicitada e                       quem será o desenvolvedor, outro problema que enfrentamos é a burocracia no                       processo de aprovação da demanda. O EV (estudo de viabilidade) já está tudo                         construído mas necessita de 5 assinaturas para se começar a desenvolver. Acho muita                         burocracia, pois dentro dessas 5 assinaturas tem assinatura de pessoas que não tem a                           mínima ideia do que se trata, e que muitos são gestores e diretores, que ficam dias                               com os EV’s em suas mesas para serem aprovados. Totalmente desnecessário, atrasa                       muito o processo.”   Entrevistado 2: Guilherme Queiroz ­ Coordenador de Sistemas ­ gqueiroz@totalcombustiveis.com.br  Qual é o processo para a solução de uma demanda?  “O cliente abre uma demanda através de um chamado OTRS para nós. Muitas vezes                           esses chamados são feitos informalmente, por telefone, e­mail, etc… Dificultando                   nosso trabalho. Após esse chamado, os analistas vão analisando e os respondendo.                       Caso seja uma demanda de suporte, o analista atende sem a necessidade de algum                           procedimento mais definido. Caso seja uma demanda de desenvolvimento, ele                   necessita de um EV (estudo de viabilidade). O analista analisa o EV e responde um                             parecer técnico informando se é possível, como vai ser e em quanto tempo de                           desenvolvimento é necessário. Esse EV precisa de 5 assinaturas para aprovação. Do                       solicitante responsável, do gerente da área solicitante, do Gerente de TIC, do                       Coordenador de gestão de processos e do diretor. Basicamente é assim, não temos                         um processo bem definido, tudo isso foi construído com boas práticas. Claro que tem                           algumas exceções, como demandas de urgência que afetam a cadeia de valor”.  

20 

 

Qual principal problema você enfrenta nas soluções das demandas dos clientes?  “De um ponto de vista de coordenação, o recolhimento das assinaturas do EV para o                             inínio do desenvolver de uma demanda é um processo muito burocrático. Hoje                       necessitamos de 5 assinaturas para a aprovação do EV, onde já houve caso de passar                             mais de 2 semanas parados por conta de uma assinatura. Isso resulta num atraso                           muito grande que prejudica muito as partes interessadas no projeto. Ao meu ver,                         bastaria aprovação do analista por questões de viabilidade, e dos coordenadores das                       áreas interessadas. Seria muito mais rápido. Além do que, todo esse atraso no fim                           acaba refletindo numa imagem ruim para área de sistemas, que fica vista como “lenta”.”    6.5 Nivel de Esforço  

Nome do Membro  Esforço% 

Danilo Pedrosa  25% 

Julio Melo  25% 

Bruno Ferys  25% 

Moises FAbian  25%  

21