BPMN: demonstrando a continuidade de processos

Uma das principais vantagens de BPMN pode também ser o seu calcanhar de aquiles: embora robusta e flexível, Business Process Modeling Notation, como diz o nome, é apenas uma notação para representar de forma padronizada aspectos lógicos de um processo de negócio. Seu objetivo não é propor uma metodologia de análise ou de documentação de processos, mas uma linguagem comum que possa ser interpretada igualmente por todos os envolvidos.

A flexibilidade da notação em permitir que um mesmo cenário de negócio possa ser modelado de formas diferentes – com alguma eventual sutil diferença em sua interpretação, possibilita que o seu uso possa ser implementado conforme for mais conveniente para a organização. Por outro lado, implica em um problema comum a todos que iniciam a sua utilização: a ausência de uma metodologia ou padrão de uso.

Por isso, é comum que profissionais que utilizam o padrão eEPC da metodologia ARIS encontrem alguma dificuldade em traçar um paralelo claro de uso entre as duas notações.

Uma das dúvidas mais comuns relacionadas à especificação de processos com uma ou outra notação está na forma como se representa a conexão entre processos.

BPMN oferece diferentes formas de se representar a continuidade de processos. Cabe aos analistas identificar qual a forma mais apropriada para atender as necessidades de documentação do seu processo – que pode (ou deve!) ser guiada por uma abordagem padrão da organização.

Neste artigo, exploramos duas formas de representar a continuidade de processos com BPMN.

 I. Acionamento por comunicação explícita entre processos

Uma das formas de se demonstrar a comunicação entre processos com BPMN é através de acionamento explícito, em que o término de um fluxo invoca diretamente o fluxo de um outro processo. Isto é feito através da diagramação em pools. Nesta notação, cada processo é disposto em uma pool. Como já vimos em artigo anterior, a comunicação entre pools acontece sempre através de message flow. Por isso, quando um processo em uma pool termina já planejando iniciar outro processo, isto precisa ser feito com eventos do tipo message.

O exemplo abaixo é o que permite um paralelo mais próximo desse comportamento com um modelo eEPC. Quando o Processo de Inscrição em Eventos termina com a identificação de que precisa iniciar o Processo de Viagens Corporativas, o evento de fim é representado como um evento de end message event, e um conector de message flow realiza a transição para a pool daquele processo. O diagrama abaixo apresenta essa representação usando uma pool black box para representar o processo de Viagens.

Neste diagrama, a continuidade do processo de Inscrição em Eventos rumo ao Processo de Viagens Corporativas é explícito através da comunicação entre os dois processos, representada pelo conector de message flow. O Processo de Viagens Corporativas está representado como uma pool black box. A sua lógica poderia estar representada em detalhes em um outro diagrama.

Se for interesse do processo visualizar mais claramente a interação entre os dois fluxos, pode-se usar a representação abaixo, que demonstra como um fluxo inicia o outro e quais atividades se seguem depois que a participação no evento foi autorizada. A diferença entre o modelo acima e o abaixo é que na representação acima o Processo de Viagens Corporativas está em uma pool black box, enquanto no diagrama abaixo está em uma pool white box.

Neste diagrama, a continuidade do processo de Inscrição em Eventos rumo ao Processo de Viagens Corporativas é explícito através da comunicação entre os dois processos, representada pelo conector de message flow. O Processo de Viagens Corporativas está representado como uma pool white box, possibilitando uma visão completa da sequênia de atividades em nível operacional.

A principal vantagem desta abordagem é que fica explícito no diagrama que um processo de negócio maior tem continuidade através dos seus processos, porém causa um certo nível de dependência entre os processos.

 II.Orquestração de Processos

Uma segunda abordagem é utilizar um diagrama de orquestração, que em um nível um pouco mais alto, fica responsável por controlar o término de um determinado processo e identificar que outro deve ser iniciado na sequência. Esta abordagem baseia-se no conceito amplo de subprocessos em BPMN.

Para BPMN, não existe uma definição de arquitetura de processos, ou de estruturação de níveis. Cada organização deve orientar como vê a empresa e definir seu próprio mapa de processos. Para BPMN, as coisas são bem mais simples. Uma atividade, em um fluxo de trabalho, pode ser:

  • Uma tarefa (um conjunto de procedimentos que compoem uma atividade realizada por uma pessoa ou grupo de pessoas, em seu menor nível de granularidade);
    ou
  • Um subprocesso, que nada mais é do que uma abstração de que naquela etapa, um conjunto definido de atividades representadas em um fluxo (um processo!) acontecerão. Quando este fluxo é concluído, então a atividade de subprocesso é encerrada e o fluxo no qual ela se encontra dá seguimento.

Assim, uma forma de demonstrar que o término de um processo dará início a um outro processo, é representá-los como subprocessos de um processo orquestrador, que dá a sequência entre eles, desta forma:

Processo de Participação em Eventos visto fim-a-fim, através da orquestração sequenciada de processos da organização.

Neste cenário, os diagramas dos processos orquestdados não precisam preocupar-se com regras que influenciarão no próximo processo (como identificar se há ou não viagem para a participação no evento). Esta lógica pode ser atribuída ao processo que faz a orquestração:

Processo de Participação em Eventos fim a fim, agora com alguma lógica de roteamento dos processos envolvidos.

Note que neste caso, os eventos de início e fim são do tipo none. Isto porque no caso de processo de Viagens, não é mais um evento de comunicação entre processos que definirá o seu início, e sim o processo orquestrador.

Nesta abordagem o processo de inscrição de eventos pode ser simplificado.

Nesta abordagem o Processo de Viagens Corporativas também pode ser simplificado, tornando-o otimizado para reuso por outros processos de negócio.

As vantagens desta abordagem são:

  • O diagrama orquestrador permite uma visão simples e clara de um processo de negócio orquestrado fim-a-fim. Isto torna-se um pouco mais difícil no cenário de acionamento por comunicação explícita, uma vez que torna-se necessário navegar de um processo para outro para chegar-se ao fim e compreender o contexto geral do processo de negócio.
  • Os processos são independentes da lógica de roteamento da orquestração, tornando-os reusáveis por outros processos de negócio (por exemplo: o processo de viagens corporativas poderia também ser usado em um processo de Execução de Projeto, Apresentação de Treinamentos, etc)
  • É possível criar condições diferentes que levem a orquestração a executar ou não um processo após a realização de outro (como foi feito para definir a execução do processo de viagens e de reembolso), e estas regras podem ser mudadas sem impactar na lógica dos processos adjacentes.

Existem também outras formas de possibilitar a representação de sequência, como uso de eventos de signal, por exemplo. Estas duas entretanto são as mais comuns e que tornam mais visível esta comunicação. O critério de definição de qual abordagem utilizar passa por uma avaliação da organização sobre como manterá todos os seus diagramas de processos reunidos e organizados, através do estabelecimento de uma arquitetura de processos.

10 ideias sobre “BPMN: demonstrando a continuidade de processos

  1. O proposito da especificação é definir um linguagem padrão para modelagem de processos. A interpretação da especificação, pode, gerar diagramas de difícil comunicação, inelegíveis e até equivocados, para evitar isto, no meu ponto de vista, temos duas formas, a primeira ter uma equipe experiente a segunda estabelecer uma metodologia.

  2. Olá Kelly, parabéns pelo artigo; muito oportuno por sinal. Penso que valeu a pena a sua reflexão e decisão de escrever sobre o assunto.

    Vejo também que o Rildo, está continua atento às novidades, Sendo o primeiro a opinar sobre o artigo.
    Muito bom encontrá-los aqui.
    Abraços
    Saulo

  3. Kelly,

    pensando em uma possível implementação, um ponto negativo na segunda opção é que se faz necessário um controle interno para identificar se o processo vai ser acionado ou não. Na primeira opção, isso não é preciso.

    O impacto pode ser visto na quantidade de variáveis do processo e isto pode ser relevante para o desempenho.

  4. Edson, já automatizamos processos utilizando estas duas estratégias e não identificamos impactos significativos no desempenho por conta de alguns atributos adicionais de controle. Basta que eles sejam bem planejados e, se possível, que o roteamento possa ser feito com base nos próprios dados de processo em vez de criar-se atributos apenas para controle do fluxo.
    O segundo cenário tem o benefício de possibilitar que uma consulta ao histórico do processo possibilite ver todo o seu ciclo de vida, do início até o momento em que encontra-se, tanto no nível da orquestração quanto dos processos em andamento, o que seria um pouco mais complicado sem a orquestração (é claro que isto pode variar de produto para produto).

  5. Olá , bom dia!

    Ótimo material , parabens!

    Fiquei com uma duvida: Como posso representar um fluxo que é chamado por vários processos diferentes, e estes processos esperam um retorno de aceite deste fluxo?

    Obrigado.
    abs.

  6. Wellington, vejo que é possível modelar este processo de formas diferentes. Você pode fazer este fluxo como um processo reusável, e utilizá-lo como subprocesso nos diferentes processos dos quais você mencionou. Ou então fazê-lo iniciar e terminar com eventos de mensagem, e fazer com que os processos que precisem executá-lo use as mesmas mensagens para iniciá-lo e receber seu retorno.
    As necessidades do negócio e as diretrizes de modelagem da organização é que darão o direcionamento de uso na escolha de uma ou de outra abordagem.

  7. Pingback: BPMN: Desenhar processos na verdical ou horizontal? | Blog da iProcess

  8. Boa noite, parabéns! Muito interessante o texto e o comentário do nosso colega Rildo, que sempre contribui conosco com o seu conhecimento… Eu concordo com ele que é preciso definir uma linguagem padrão e gostaria de acrescentar que quando fazemos um fluxograma, precisamos verificar se uma pessoa que não conhece o processo irá compreendê-lo totalmente. Abs.

  9. Muito imteressante, tirou várias dúvidas, mais como você comentou a instituição deve criar padrões é um modelo de governança para modelagem .

    Parabens
    RGS

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

*

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>