Blog da iProcess - Compartilhando conhecimento em BPM e RPA

Respondendo dúvidas em BPMN: Desenhar processo na vertical ou horizontal?

A definição sobre a orientação vertical ou horizontal para diagramas na notação BPMN, sempre foi, desde sua criação, um dos aspectos mais questionados pelos analistas e modeladores de processos.

Um de nossos leitores recentemente enviou a seguinte questão:

“Sei que a boa prática é desenhar o processo da esquerda para a direita, correto?
Porém estou me deparando com alguns processos longos que vão dar muito trabalho fazer nesta ordem e acredito que ficará mais fácil visualizar de cima para baixo.
O que vocês acham sobre isso? Há alguma regra? O que vocês orientam?”

Embora não seja obrigatório em BPMN, swimlanes (pools e lanes) são muito utilizadas pois possibilitam a estruturação visual do fluxo, de forma a apoiar a interpretação do mesmo. Através delas, é possível identificar facilmente quem é responsável por executar cada tarefa, quem são os atores do processo e que participantes externos colaboram com o processo.

Em nosso blog, já falamos sobre pools e lanes em postagens como:

A especificação da notação (https://www.omg.org/spec/BPMN/2.0/PDF/) define o uso de swimlanes como não obrigatório, e que estes elementos podem ser usados para organizar o processo visualmente tanto na horizontal quanto na vertical.

Muitas vezes, o analista que realiza a modelagem de processo já utilizou alguma outra notação ou metodologia com elementos semelhantes às pools e lanes de BPMN, como eEPC e fluxogramas. Nestas duas notações, o processo é comumente representado na vertical. Assim, é mais natural para estes profissionais elaborar o processo nesta visão.

Entretanto, a maior parte dos exemplos que encontramos na bibliografia e na web sobre BPMN utiliza a representação na horizontal. Isto se dá porque na cultura ocidental temos o reflexo da leitura da esquerda para a direita. É uma percepção ligada à compreensão da sequência de ações. Assim, a distribuição do processo em uma estrutura de pool e lanes horizontal permite uma melhor distribuição das tarefas nesta visão

Um exemplo bastante simples de processo modelado com swimlanes na horizontal. À medida que se agreguem novas atividades ao processo, há a uma tendência de aumento do diagrama para a esquerda. Em um diagrama com colaboração, outras pools podem ser adicionadas, geralmente abaixo e acima da pool que contém o processo.
O mesmo processo do exemplo acima, representado com swimlanes verticais. A leitura do fluxo navega para a esquerda mas em alguns momentos precisa ir na “contra-mão” da leitura normal. A tendência de aumento é para baixo, mas novas lanes podem ser agregadas aumentando sua largura. Em um diagrama com colaboração, outras pools podem ser agregadas, geralmente nas laterais da pool que contém o processo.

Existe ainda uma abordagem de fluxo limpo do processo, em que pools e lanes não são utilizadas. Essa abordagem é mais usual quando o processo é modelado com visão de orquestração, por exemplo, em que suas atividades são na verdade uma sequência de processos, ou sub-processos. Neste nível de visão sobre o processo de negócio, é mais relevante identificar os processos e como estão relacionados do que quem são os envolvidos nestas tarefas, já que os atores já estarão claros nos diagramas dos respectivos processos.

Apesar da flexibilidade oferecida pela especificação oficial da notação, em geral recomenda-se a documentação do processo com pool e lanes na horizontal, seja pelo aspecto do conforto natural da leitura do fluxo ou mesmo por restrições de ferramentas (alguns produtos amplamente utilizados no mercado para representar diagramas de processos não permitem desenhar pools e lanes verticais, apenas horizontais).

Se o diagrama do processo tende a se tornar grande, a resposta não está na definição vertical ou horizontal do diagrama, mas na capacidade de abstrair tarefas em conjuntos através de subprocessos. Com isso, o modelo talvez acabará ganhando um ou dois níveis a mais, mas ao mesmo tempo temos com isso um diagrama com visão mais objetiva sobre o processo de negócio (veja mais sobre esta abordagem neste artigo, em orquestração de processos).

Independente da escolha, nossa principal recomendação é que esta definição deve fazer parte do guia de estilos de modelagem da organização, ou seja: vertical ou horizontal – o importante é manter um padrão a ser adotado em todos os diagramas de processos  de negócio documentados para a empresa.

 


Aprenda a utilizar todo o potencial da notação BPMN em exercícios práticos e avançados com nossos instrutores!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br

17 respostas

    1. Gabriella, não há nenhuma regra para isso. Você pode desenhar os fluxos de sequência na direção que for mais conveniente para o fluxo do seu processo. O importante é que o conector deve necessariamente ligar dois elementos de fluxo (atividades, gateways ou eventos) e que ponta de origem esteja conectada no elemento precedente e a de destino (com a seta) no elemento que dará sequência ao fluxo.
      Algumas equipes podem definir padrões organizacionais específicos para manter um estilo comum de modelagem, mas na especificação não há nenhuma restrição em relação à direção das setas dos conectores.

    1. Olá Janos, nas nossas exper, acredito que não seja plano da Bizagi incluir a pool vertical no seu kit.
      Existem algumas ferramentas que permitem este tipo de modelagem, como Visio e Yaoqiang, mas a habilidade de converter modelos de uma ferramenta para outra precisa ser estudada com cuidado.

  1. Olá, estava modelando um processo pelo Bizagi quando deparei com o limite do tamanho do diagrama, ou seja, o processo não acabou e o Bizagi parou de expandir o diagrama para a direita. Fui negativamente surpreendida. Procurei na internet algo que me esclarecesse e li o tópico (no fórum do Bizagi) de alguém que teve o mesmo problema cinco anos atrás. A resposta à dúvida da pessoa dizia que futuras versões do Bizagi permitiriam o usuário expandir o diagrama conforme a necessidade do mesmo, mas que naquela versão, de cinco anos atrás, isso ainda não era possível (o Bizagi). Reproduzo aqui a resposta obtida pela usuária: “The pool currently has a fixed size of 6000px of width and height. Our recommendation for these cases is to create sub-processes, which help to understand slightly better model. For future versions, the size may be managed by the user”. No entanto, cinco anos depois dessa resposta, a limitação não foi corrigida. Completamente frustante! Só não me sinto pior graças a eu ter feito o tutorial gratuito, mas se tivesse apostado em um curso pago, nem quero imaginar a raiva que estaria sentindo. Perdi meu tempo em acreditar nessa ferramenta. Ela parece ser boa e se propõe a isso, mas não é bem assim.

    1. Olá Giovana!
      Obrigada por acompanhar nossas publicações do blog da iProcess.
      Se você está com um processo que precisa realmente de uma pool tão grande, possivelmente é porque seu diagrama de processo realmente está muito grande.
      Mesmo que fosse possível ampliar o tamanho da pool no diagrama, nós não recomendaríamos. Diagramas com fluxo de processos muito grandes são difíceis de se interpretar e facilmente se tornam ilegíveis por ter muitas raias e linhas cruzadas.
      Diagramas muito grandes geralmente são sinal de que ou o diagrama está representando mais de um processo no mesmo fluxo, ou o processo de negócio está sendo modelado em um nível de detalhamento muito baixo (passos ou procedimentos).
      Algumas metodologias, como por exemplo a aplicada pela IBM, recomendam que o fluxo do processo tenha no máximo 7 atividades (“Regra do 7”). Mais do que isso, a recomendação é a mesma da Bizagi – abstrair conjuntos de tarefas em subprocessos.
      Nós trabalhamos com um pouco mais de flexibilidade, mas evitamos diagramas com mais de 20 elementos. Confira algumas dicas de como desdobrar seu processo em múltiplos diagramas neste artigo: BPMN: demonstrando a continuidade de processos
      Ou neste webinar: Webinares iProcess 2015 – BPMN: Modelando a comunicação entre processos.

    1. Oi Stela, se o texto não cabe dentro do elemento, então é porque ele está muito longo mesmo. Procure ser mais objetiva, usando duas, três, no máximo quatro palavras. Utilize o campo “descrição” nas propriedades do elemento para colocar o texto completo.

  2. Olá Kelly!

    Recentemente assisti a um vídeo, aonde o professor diz que ao passar de uma atividade para a outra em raias diferentes, uma atividade não pode ficar exatamente abaixo da outra, pois dá uma ideia de atividades paralelas (igual a figura 1 desse artigo), que o correto é sempre colocar uma atividade mais a direita em relação a anterior. Esta informação procede?

    1. Oi Lorena! Sinto mas terei que discordar do seu professor. Pelas regras da notação BPMN, não há nada que determine como deve ser o posicionamento de elementos nos diagramas. O que determina se algo é feito antes ou depois ou em paralelo é a lógica definida pelos fluxos de sequência (conectores do tipo sequence flow) e os gateways. Uma atividade só é considerada que pode ser feita em paralelo com outra(s) se elas forem antecedidas por um gateway do tipo paralelo (parallel gateway).
      Dentro das boas práticas conhecidas oferecidas por diversos autores, nunca vi uma recomendação como essa. Então você pode considerar isso como um estilo de modelagem recomendado por ele, mas não como uma forma certa ou errada de modelar o processo. Espero ter esclarecido sua dúvida!

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

MAIS VISTOS

Como transformar as ideias de mudança para um processo TO BE em ações efetivas, controladas... (continuar lendo)
Veja agora as ações que foram realizadas através das doações de todos os participantes deste... (continuar lendo)
Participe deste evento exclusive e gratuIto e se prepare para as transformações que IA irá... (continuar lendo)

Inscreva-se na nossa Newsletter

seers cmp badge