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.

Um guia para iniciar estudos em BPMN (V): Subprocessos

Retornando ao tema Atividades (Activities), em nossa série de artigos dedicados ao BPMN Nível 1, há um segundo tipo deste elemento além das tarefas (tasks): são os subprocessos.

Tarefas que em conjunto possuam um propósito específico dentro de um processo de negócio podem ser abstraídas em uma outra unidade de processo e representadas no processo maior por um único objeto do tipo atividade, denominado Subprocesso.

Subprocessos são representados visualmente como retângulos com bordas arredondadas (como as tarefas), porém apresentam um símbolo [+] na base inferior implicando no entendimento que esta atividade contém um conjunto de tarefas. Subprocessos são conectados ao fluxo do processo da mesma forma que as outras atividades, através de conectores de fluxo de sequência.

No exemplo acima, a atividade “Aprovação de exceções de negócio” é um subprocesso, que abstrai um conjunto de atividades cujo propósito é avaliar uma exceção de negócio (por exemplo, crédito para um cliente antigo mesmo que tenha situação financeira negativa) para então dar continuidade à concessão do crédito se esta exceção for autorizada. Abaixo tem-se um exemplo de detalhamento das atividades deste subprocesso.

Em geral, o fluxo que compõe o subprocesso é mapeado em um diagrama separado. Algumas ferramentas permitem criar vínculo entre o diagrama do processo principal e o subprocesso, possibilitando a navegação de um para outro com um ou dois cliques de mouse.

Se o processo que está sendo modelado possui muitas atividades e conexões, tornando-o difícil para a interpretação dos leitores, a utilização de subprocessos pode ser um excelente artificio para organizar o fluxo sem interferir diretamente na execução do mesmo, possibilitando criar uma visão mais abstrata e objetiva das atividades que ocorrem no processo.

Subprocessos também podem ser úteis para reunir partes de fluxos que podem ser repetidas em momentos distintos do processo, caracterizando reuso.

Continue acompanhando! No sexto e último artigo deste guia básico, swimlanes e artefatos para apoiar na organização do diagrama do processo.


Confira todos os artigos deste guia de BPMN Nível 1: