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

Transcrição

1 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

2 Índice 1. Introdução Descrição do problema encontrado Descrição da modelagem em BPMN Descrição da modelagem em i* Conclusão Apêndices

3 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

4 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

5 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 Cliente (Modelo do cliente na modelagem) 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 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 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

6 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

7 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

8 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

9 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

10 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 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

11 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

12 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

13 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

14 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 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

15 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

16 6. Apêndice 6.1 EV (Estudo de Viabilidade) (Primeira página do EV). 16

17 (Segunda Página do EV) 17

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

19 6.3 Modelo BPMN (Modelo BPMN completo) 19

20 6.4 Entrevistas Entrevistado 1: Ismael Santos, analista N1 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

21 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