Boas práticas no uso de gateways em BPMN

Estudo de caso: 

Boas práticas no uso de gateways em BPMN

Kelly Sganderla - iProcess

BPMN é a melhor notação para representar a lógica da execução de um processo de negócio, mas um processo bem mapeado na notação passa pela escolha certa no uso dos elementos da notação. Muitas vezes, não há uma forma única de representar um processo, mas com certeza o contexto do processo poderá nos ajudar a definir a forma de criar o diagrama de forma mais clara.

As ferramentas de mapeamento aderentes à notação BPMN nos ajudam a nos certificar se o diagrama que criamos está correto, mas ele consegue apenas validar se os elementos estão conectados da forma correta.

Por exemplo, no processo abaixo, inspirado no caso de um leitor que recentemente nos encaminhou esta dúvida:

No processo, a lógica que estamos tentando mapear é de que, depois da tarefa "Verificar documentos", pode ou não necessitar "Digitalizar documentos" e pode ou não necessitar "Confirmar se documentos são válidos". Ou seja, há casos em que realiza só uma dessas tarefas, as duas, ou em algumas situações nenhuma, indo direto para "Analisar documentação".

Você identificou algum problema no uso da notação? Mas tem, e a ferramenta (no caso o Bizagi) avisou:

Mensagem de erro na validação de diagrama do Bizagi: "Um gateway deve ser usado para dividir em fluxos distintos ou unificá-los em um único; os dois comportamentos no mesmo gateway não é suportado."

Olhe novamente. O gateway exclusivo “Precisa verificar a autenticiade?” tem duas entradas e duas saídas. Pela notação BPMN, o gateway exclusivo pode ser de divisão (split) ou de unificação (merge) do fluxo. Usar um mesmo gateway para representar as duas coisas pode gerar confusão tanto na interpretação humana quanto se o processo for ser automatizado.

A solução para isso seria separá-lo em dois – um para unificar os fluxos que vêm do gateway anterior e outro para verificar a condição para dar seguimento ao fluxo, assim:

Desta forma, garantimos que a lógica do processo esteja íntegra na sua representação. Entretanto, isso faz com que o processo tenha três gateways encadeados, o que não é muito legal. Neste caso, o que podemos recomendar?

Se a lógica implica em uma combinação de execução de atividades “e-ou”, podemos usar o gateway inclusivo. Este tipo de gateway tem o propósito de gerenciar a divisão/unificação do fluxo de acordo com uma combinação de possibilidades. Como resultado, teríamos o processo modelado assim:

O gateway "Providências especiais" identifica se o processo precisa ser digitalizado, se precisa de verificação de autenticidade, de ambas as tarefas ou de nenhuma delas.

Veja que algumas boas práticas foram agregadas para dar ainda mais legibilidade ao processo:

• Nomear os conectores que saem do gateway de acordo com a condição que leva àquela transição: Por exemplo, a seta de cima implica na necessidade de digitalização, e a de baixo na verificação de autenticidade. Evite usar verbos no infinitivo pois as setas não representam uma ação a ser realizada, e sim uma condição que deve existir para que o fluxo siga aquele caminho.
• Transformar a transição do meio em “default” (ou padrão), que tem uma linha cruzada na origem do conector. Esta é a forma de se dizer em BPMN que, se o gateway não identificar nenhuma condição, então ele segue pela default.

Para entender mais sobre os diferentes tipos de gateways básicos da notação BPMN, confira também este artigo:
http://blog.iprocess.com.br/2012/11/um-guia-para-iniciar-estudos-em-bpmn-ii-gateways/

Um BPMN para cada propósito de modelagem de processos

Compartilhando informações de sites Amigos.
Parabéns..a Todos da IPROCESS

Kelly Sganderla

Há alguns anos, quando a Business Process Modelling Notation (BPMN) ainda estava na versão 1.1, os pesquisadores Michael zur Muehlen e Jan Recker escreveram o artigo “How Much Language is Enough? Theoretical and Practical Use of the Business Process Management Notation?“, analisando processos de negócio modelados com esta notação e questionando o quanto alguns elementos eram realmente necessários.

De lá pra cá, milhares de novos processos de negócios foram desenhados com BPMN, e a notação aumentou seu toolkit com muitos novos elementos, em especial com a chegada da versão BPMN 2.0 (veja especificação publicada em jan/2011 aqui).

Você olha para as páginas e páginas da especificação BPMN e se pergunta “mas afinal, preciso usar todos esses elementos?”. A resposta está no propósito para o qual você está desenhando o processo.

 Um dos aspectos que mais me agrada no BPMN é o de que ela oferece uma ampla gama de elementos para a modelagem de processos de negócio que varia de acordo com a etapa do ciclo de vida de um projeto BPM, e que permitem que um processo possa ter a sua documentação progressiva, agregando informações ao fluxo à medida que um processo passa pelas etapas do projeto.

Ciclo de vida BPM - Extraido do material de treinamento da iProcess - Direitos reservados.

Para cada etapa do ciclo de vida de um projeto BPM, um conjunto diferente de componentes de modelagem de processo BPMN devem ser utilizados:

1. Identificação e Mapeamento de Processos

Nesta etapa é gerado o modelo do processo chamado AS IS.

O objetivo da modelagem AS IS é obter uma formalização sobre o fluxo do processo de negócio como é realizado na situação atual em que é executado na organização. Os aspectos a serem priorizados nesta documentação de processo são: que atividades são realizadas (tarefas), a sequencia entre estas tarefas, o caso feliz do processo e as condições que levem a cenários de negócio alternativos.

Para esta modelagem, os elementos de BPMN mais relevantes são: Pools, Lanes, Activities,  gateways do tipo parallel e exclusive data-based, eventos de início e fim. Podem ser utilizados componentes de annotations para apoiar no entendimento do modelo.

Este modelo de processo em geral tem dois propósitos: A) servir de documentação para conhecimento do processo atual; B) servir como insumo para a próxima etapa do ciclo de vida de um projeto BPM.

Por isso, esses modelos tendem a possuir uma vida curta. Minha recomendação nesta etapa é: não invista muito tempo na documentação AS IS se sua organização construiu este modelo especialmente como insumo para a próxima etapa. No decorrer das minhas atividades em consultorias já vi muitas organizações investirem  uma energia muito grande em um processo AS IS, quando o objetivo real do projeto era buscar a melhoria do processo através do redesenho TO BE.

2. Redesenho de Processos

Nesta etapa é gerado o modelo do processo chamado TO BE.

Ele é uma evolução do modelo anterior (AS IS), no qual são reavaliadas as questões de negócio envolvidas buscando-se, através de melhorias culturais e organizacionais, maior eficiência na execução do processo.

O modelo de processo TO BE também possui um foco sobre o processo de negócio, e por isso os mesmos tipos de elementos BPMN podem ser utilizados nesta etapa:  pools, lanes, activities,  gateways do tipo parallel, inclusive e exclusive data-based, eventos de início e fim. O processo começa a ser melhor detalhado em procedimentos, e mais atividades podem surgir para apoiar a realização de algumas tarefas, notificações de atraso, etc. Assim, convém considerar utilizar subprocess para agrupar tarefas com objetivos específicos e possível reuso. Eventualmente, alguns tipos de eventos como timer, link e message podem ser interessantes de serem incorporados no modelo se forem beneficiar o seu entendimento.

Alguns projetos de BPM  partem diretamente para a implantação do processo TO BE, com a realização de ações de gestão de mudanças em nível organizacional e cultural para beneficiar-se das  melhorias sugeridas. Outros projetos seguem para a etapa seguinte do ciclo, no qual ao redesenho de negócio são agregadas melhorias tecnológicas.

3. Modelagem Técnica

A modelagem técnica busca proporcionar um olhar da análise de sistemas sobre o processo, de forma a identificar como agregar maior valor ao processo com uso de recursos de tecnologia. Pode ser  a aquisição de produtos que apóiem em atividades específicas do processo, soluções que possibilitem a integração de diferentes sistemas para prover melhores informações e eliminem tarefas humanas que não agreguem valor ao processo, customização de ferramentas existentes para melhorar a realização das tarefas, até mesmo a adaptação do processo para a automação através de um BPMS.

Esta modelagem técnica é a transformação do processo TO BE no modelo TO DO.

Porque há mais informações a serem atribuídas ao modelo do processo, os elementos de BPMN utilizados podem ser mais específicos, usando-se, além dos já citados, também eventos do tipo signal, conditional, exception, escalation, gateways do tipo event-based, componentes do tipo data objects, e a especificação dos tipos de tarefas (manuais, humanas, automáticas…).

4. Implementação

Se um processo de negócio for ser implementado através de utilização de um BPMS, o modelo TO DO irá requerer um detalhamento técnico ainda mais refinado, possibilitando agregar ao processo informações específicas para a interpretação do motor de processo. Este modelo de processo, que será interpretado pelo sistema, é chamado informalmente de TO RUN. O modelo TO RUN utilizará muitos elementos que a maior parte dos usuários da notação BPMN sequer virá a usar em seu trabalho, mas que serão requeridos para fornecer ao sistema detalhes relevantes para a sua execução automatizada, tais como controles de transação, compensação e tratamentos de erros.

Como se pode ver, existe um grupo de elementos de BPMN apropriado para cada etapa do ciclo de vida de projetos BPM.

Conhecer o potencial desta notação é o primeiro passo para se construir diagramas de processos claros, legíveis para todos os participantes e eficazes na representação do fluxo de atividades de acordo com o propósito do modelo.