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.

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.

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 elaboramos um nível um pouco mais alto de abstração do processo, que 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:

Neste cenário, os diagramas dos processos orquestrados não precisam preocupar-se com as 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:

Note que neste caso, os eventos de início e fim dos processos orquestrados 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.

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.