Bom pessoal, estamos chegando no fim dessa série sobre Gerenciamento de Processos de Negócio, mas antes iremos abordar algumas das diversas notações desenvolvidas ao longo dos anos e algumas ferramentas para modelar processos.
(TESSARI, 2008). Algumas das notações existentes são:
UML 2.0 Activity Diagram ou Diagrama de Atividades (AD): foi projetado para modelar processos de negócio e fluxos em sistemas de software. Tem a sua origem baseada no desenvolvimento de software.
Business Process Definition Metamodel (BPDM): desenvolvida pelo Object Management Group (OMG) fornece um metamodelo genérico para processos de negócio. Ela não provê uma notação gráfica própria, pois o intuito é definir um metamodelo genérico para apoio do mapeamento de diferentes ferramentas.
Business Process Modeling Notation (BPMN): criada especificamente para projetar e modelar processos de negócio bem como as suas transformações na linguagem de execução, denominada Process Modeling Language (BPML).
Event Driven Process Chain (EPC): desenvolvida para modelagem de processos de negócio. Possui basicamente funções e eventos.
Integrated DEFinition Method 3 (IDEF3): projetada para modelar processos de negócio e sequências de sistemas sob duas perspectivas, o esquema do processo e o esquema dos objetos.
Petri Net ou Redes de Petri: projetada para modelagem, análise e simulação de sistemas dinâmicos. Elas são muito utilizadas para modelar workflows, que foi o precursor do BPM.
Diversas ferramentas podem ser encontradas para modelar processos, porém cito 3. Bizzagi Studio – Oracle BPM Studio – BPMN Modeler.
Bizzagi Studio, é uma ferramenta excelente para desenvolver fluxos e modelar processos de negócio, tem uma variedade de opções que podem ser utilizadas, iremos utiliza-la para modelar nosso processo de negócio.
A famosa Oracle também está nessa e tem a ferramenta Oracle BPM Studio, segundo a Oracle é um conjunto completo de ferramentas para criar, executar e otimizar processos de negócios. A suíte permite a colaboração sem precedentes entre negócios e TI para automatizar e otimizar processos de negócios.
BPMN Modeler é uma ferramenta que também apresenta uma infinidades de opções para modelar seus processos, seu modo de usar é parecido com o Bizzagi, porém é uma versão paga.
Tanto a ferramenta da Oracle e a Modeler nunca utilizei, mas com certeza lhe trará uma grande experiência.
Para fechar com chave de ouro, iremos modelar um processo que provavelmente alguns de vocês vivenciaram, ou seja, vamos modelar o processo de um atendimento de reparo de rede (internet), realizado por uma empresa de telefonia a seus clientes. Porém não vamos entrar em detalhes minuciosos como seria em um projeto real.
Segue abaixo a modelagem do processo e após o detalhamento sobre o fluxo do processo.
Para ampliar e navegar no processo, clique na Imagem abaixo.
Reparem que criei uma Pool chamada cliente, contém as atividade que serão realizadas no momento em que percebemos que estamos sem internet.
Temos nessa lane o evento inicial que faz o disparo para iniciarmos o processo Ligar para operadora, ao ligarmos esperamos ser atendido caso não formos continuaremos ligando até ser atendido, esse desvio se dá através do gateway exclusivo, caso formos atendido relatamos o problema. Vejam que na pool (Empresa de telecomunicação) temos a lane Call-center que irá nos atender através do evento inicial simbolizado pela círculo verde com carta.
Se voltarmos ao processo do cliente fica visível que após relatarmos nosso problema um evento que representa uma mensagem é acessado e ficamos aguardando uma resposta ao telefone até que nosso problema venha ser resolvido. Não é exatamente isso que ocorre nessas situações?
Enquanto aguardamos uma solução, o call-center já passou pelo processo Identificar Tipo de Solicitação, analisando se tem condição de resolver esse pro b blema. Reparem que temos outro gateway exclusivo que irá determinar se ele sabe resolver ou se irá repassar para outro nível a solicitação. Se o call-center souber resolver, irá nos passar um feedback do problema e finalizar o seu processo. Logo, nós clientes damos como resolvido e finalizamos felizes o processo por ter sido solucionado. Reparem que é exatamente como acontece na realidade.
Mas se nosso problema for um pouco mais sério, como isso será resolvido?
Bom suponhamos que o call-center não sabe resolver ou não é de sua competência o problema que aconteceu, então através do getway exclusivo (Pode ser resolvido?) será desviado o fluxo do processo iniciando o processo Transferir para suporte nível 1. Nesse caso temos um evento do tipo final que ocorre através de uma mensagem, ou seja, irá passar o problema relatado para o nível 1 (pode ser através de mensagem no sistema ou telefone – fica a critério da empresa). Essa parte realizada o processo do call-center se dá por encerrado e inicia o processo do nivel1.
Percebam que na lane suporte nível 1 o processo é muito similar ao do call-center com um detalhe diferente, que irei explicar.
Após o nível 1 receber as informações relatadas, é hora de iniciar o processo Resolver problema, caso o problema venha ser solucionado nesse nível, é iniciado o processo Prover feedback cliente e informamos ao cliente a solução, logo o processo se encerra.
Mas se nosso problema é complicado demais e não cabe a seu nível resolve-lo, então o suporte nível 1 através do gateway exclusivo desvia seu fluxo para o processo Acionar suporte nível 2, disparando o evento de solicitação do suporte nível 1 (na lane nível 2), mas repare um detalhe ao realizar o processo acionar o suporte nível 2, o setor suporte nível 1 aguarda uma resposta do nível 2 para prosseguir com o fluxo do processo, vejam que, o processo lane nível 1 fica parado até que receba a resposta de solução que será enviada pelo nível 2.
Com a lane suporte nível 1 parada é hora do suporte nível 2 correr e averiguar a situação, para solucionar o problema o mais rápido possível, afinal o cliente está esperando.
Então o suporte nível 2 parte para o processo Resolver o problema, ele averígua e encontra a solução, portanto o fluxo chega ao gateway exclusivo com a informação positiva, mais a frente a informação é levada para outro gateway exclusivo, a qual irá solicitar a necessidade de visita ou não. Caso houver necessidade de visita, o fluxo aciona o processo Agendar visita, passando a data e dia para o cliente aguardar a solução, consequentemente o processo Prover feedback suporte nível 1 é acionado através de mensagem ou sistema, passando a solução para lane suporte nível 1 encerrando o processo no nivel 2 . Nesse caso o nível 1 continuará o processo.
Se não for necessário visita, somente será realizado o processo Prover feedback suporte nível 1, finalizando o processo do setor suporte nível 2.
Como foi finalizado o suporte no nível 2 automaticamente é disparado um evento de resposta recebida (na lane suporte nível 1), através da conclusão do processo Prover feedback suporte nível 1, consequentemente temos o fluxo partindo do evento e iniciando o processo Prover feedback cliente, onde o suporte nível 1 irá relatar para o cliente o problema e a solução.
Espero que estejam conseguindo entender caso contrário analisem melhor o fluxo da modelagem que ficará mais fácil.
Até agora falamos que o nível 2 conseguiu resolver o problema, mas supomos que é mais sério do que ele pensa, então voltando a lane suporte nível 2 temos o getaway (resolveu problema?), que irá desviar o fluxo. Simulamos que o problema não foi solucionado, então o getaway vai desviar o fluxo par ao processo Acionar analista nível 3. Agora a bronca ficou séria rsrsrs. Logo o nível 2 fica aguardado uma resposta para poder dar continuidade no fluxo.
O processo Acionar analista nível 3 dispara o evento na lane suporte nivel 3 Analista de implementação, que irá dar início ao processo Verificar problema. Com seu grande conhecimento e expertise ele acha a solução e o evento (problema solucionado) é disparado, levando as informações para o processo Prover feedback ao suporte nível 2. O mesmo dispara o evento resposta recebida (nível 2), logo se encerra sua tarefa e o processo na lane do analista é finalizado.
Bom pessoa ainda não acabou o fluxo, a informação saiu da lane do analista e chegou ao evento resposta recebida, que se encontra no nível 2. Automaticamente o fluxo chega no gateway exclusivo (marcar visita), se não for necessário agendar visita o fluxo chega ao processo Prover feedback suporte nível 1, senão o fluxo vai ao processo Agendar visita. Percebam que, mesmo tendo a necessidade de agendar visita o processo Prover feedback suporte nível 1 sempre irá ocorrer, pois é ele que irá levar a informação detalhada para o nível 1 e após ele que se encerra o fluxo no nível 2.
Chegando a informação no suporte nível 1. O fluxo segue igual ao que foi explicado lá encima, o processo Prove feedback cliente irá ocorrer e contatar o cliente explicando a solução para o problema, se tudo foi resolvido ou se será necessário agendar a visita. Automaticamente o fluxo volta para o cliente através do evento aguardando solução e como vimos o cliente irá ficar feliz se não precisar agendar visita.
Fica nítido que o processo e a informação ocorre de forma sistemática até que o processo venha ser encerrado.
Tentei explicar da melhor maneira como o fluxo percorre todo processo saindo de um setor (lane) e interagindo com outro, levando a informação para cada etapa do processo até que tudo venha ser resolvido. É possível detalhar muito mais esse processo, remodelar e melhorar, criar sub processos, gerar dados, objetos, detalhar grupos entre outras funções mais avançadas, mas eu quis trazer algo simples para que fique de fácil compreensão.
Alguns detalhes podem ser observados na modelagem, como os conectors, são as linhas que ligam um processo, evento ou fluxo a outro também podem ligar uma pool a outra pool. Porém vejam que as linhas pontilhadas somente ligam um processo a outra pool, pois não é permitido usar linha continua de uma pool para outra. Outro ponto importante, um evento de início (círculo verde sem simbologia), somente pode conter um por pool senão temos erro (fora do padrão), já o evento de fim do processo (circulo vermelho), pode conter mais de um por pool.
Você que está iniciando nos negócios e sua empresa não tem uma visão baseada em processos, procure modificar esse ponto de vista, tente aos poucos inserir as técnicas mencionadas durante nossas quatro matérias. Modele seus processos invista nesse conhecimento, pois irá agregar maior valor a seus negócios, aumentando sua percepção sobre os processos que os cercam.
Bom pessoal eu trouce um pouco do meu conhecimento nesse assunto, lembrando não sou especialista em processo de negócio e não é minha área de atuação, é um assunto a qual acho interessante e importante conhecer, então quis compartilhar com vocês. Espero que gostem da matéria e se você estiver iniciando nos negócios e sua empresa não tem uma visão baseada em processos, procure modificar esse ponto de vista, tente aos poucos inserir as técnicas mencionadas durante nossas quatro matérias. Modele seus processos invista nesse conhecimento, pois irá agregar maior valor a seus negócios, aumentando sua percepção sobre os processos que os cercam.
Divirtam-se em executar as técnicas de Gerenciamento e modelagem de processos de negócio.
Um grande abraço.
Perdeu alguma matéria sobre Gerenciamento de Processos de Negócio? Então acesse os links abaixo.
Gerenciamento de Processos de Negócio – parte 1
Gerenciamento de Processos de Negócio – parte 2
Gerenciamento de Processos de Negócio – parte 3
