BPMN: Uma atividade para mais de um participante do processo

Há uma questão recorrente na modelagem de processos relacionada à distribuição de atividades nas lanes de processo: como representar um trabalho sendo realizado por mais de uma pessoa?

Por exemplo:
Digamos que em um processo há uma reunião realizada entre o Diretor de Planejamento e o Diretor Financeiro, que recebem uma proposta de um analista e realizam uma reunião para avaliar sobre o investimento. A seguir, eles atuam na priorização das ações relacionadas ao investimento, e a partir desta priorização são realizadas outras ações.

Para essa situação em que há dois participantes envolvidos na realização de uma mesma tarefa, já vimos diagramas que tentam representar isso de algumas formas peculiares:

"Tentei demonstrar que as atividades são realizadas pelos dois usuários posicionando-as sobre o limite entre as duas lanes."

A abordagem acima é inadequada sob o ponto de vista de uso da notação BPMN e poderá gerar interpretações diferentes. Para a notação, uma atividade só pode estar associada a uma raia (lane), e mesmo que a ferramenta de criação do diagrama não aponte o problema na validação do processo, o fato é que internamente as atividades estão vinculadas a apenas uma lane. Isto está estabelecido na própria especificação da notação. Se a ferramenta utilizada dispõe de geração de relatório que lista quais tarefas estão relacionadas a quais lanes, essas tarefas só estarão associadas a um único participante.
Tem um outro problema ao se praticar o mapeamento desta forma: e se os investimentos tivessem que envolver também o Diretor de Tecnologia – como colocar as tarefas compartilhando pessoas de três raias?

Outra tentativa comum é a refletida no exemplo abaixo:

"Coloquei as tarefas em paralelo porque eles fazem a reunião ao mesmo tempo."

No diagrama acima, as regras de validação lógica do uso da notação também não apontariam problema, mas o processo ainda não estaria corretamente representado.

A interpretação que se deve ter no uso do gateway paralelo não é de que as atividades paralelizadas serão realizadas ao mesmo tempo, e sim que elas podem ser feitas em paralelo porque não há restrição de dependência entre elas. Assim, apesar de serem iguais no exemplo acima, cada tarefa tem sua execução própria, levando ao entendimento que cada um fará as atividades quando tiver disponibilidade. Por exemplo: digamos que o Diretor de Investimentos faça “Avaliar investimento” pela manhã e já siga para a próxima tarefa, enquanto o Diretor Financeiro só consiga iniciar a tarefa “Avaliar investimento” à tarde. O processo mapeado acima permite essa interpretação.

Se a ideia é de que os dois realizem juntos a tarefa “Avaliar investimento” e “Priorizar etapas do investimento”, recomendamos uma forma de mapear isto um pouco diferente:

Uma raia com um papel em grupo que abstrai os participantes e garante que as tarefas sejam realizadas em conjunto pelos envolvidos.

Nesta abordagem, criamos uma raia para um papel que abstrai um grupo (o  ”Comitê de Avaliação de Investimentos”), e atribuímos as atividades a ela. Na descrição da raia, ficam estabelecidas as regras usadas para definir quem são os participantes do comitê – que neste caso será formado pelos Diretores de Investimentos e Financeiro. Esta abordagem ainda possibilita que outros diretores possam se juntar ao comitê sem impactar no diagrama do processo, bastando apenas ajustar a descrição dos participantes do grupo.

14 ideias sobre “BPMN: Uma atividade para mais de um participante do processo

  1. Abordagem interessante de um problema recorrente. As proposições apresentadas direcionam a estruturação de um “novo papel”: seja um comitê, equipe, ou outros, mas isto nem sempre é possível, contrariando em vezes até regras internas. O estabelecimento de um gateway paralelo direciona a execução de duas atividades, embora idênticas, executadas separadamente. Assim, tenho praticado a exposição e negociação de processos mapeados na condição “As Is” mantendo as atividades idênticas realizadas por papéis diferentes no limite das raias, sugerindo que no “To Be” ocorra definição mais clara de papéis decisórios.

  2. Obrigada por seu comentário Alfredo, é sempre interessante conhecer mais sobre como as pessoas têm buscado utilizar a notação.
    Em nossas modelagens, mesmo no AS IS, temos evitado usar abordagens alternativas como as que indicamos no artigo. Entendemos que a especificação BPMN existe justamente para garantir que todos modelem e interpretem a notação da mesma forma, eliminando o risco de situações dúbidas que se pode obter ao se tentar flexibilizar o uso dos elementos.
    Além disso, praticar o posicionamento de atividades sobre o limite das raias pode ter um problema adicional – como resolver quando a atividade é realizada não apenas por dois papéis, mas de três ou mais?
    Acredito que a criação de uma lane para representar um grupo não necessariamente precisa ser algo formal. É possível inclusive explicitar no nome da lane, caso não encontre um nome apropriado para o grupo, os nomes dos papéis envolvidos (por exemplo “Diretores Financeiro e de Planejamento”).
    De qualquer forma, sempre recomendamos que se a organização entende que alguma flexibilização é realmente necessária, isto deve estar claramente estabelecido em um guia que oriente toda a equipe a utilizar a notação de maneira uniforme e definindo o estilo de mapeamento de processos da organização =)

  3. Kelly . acredito que a alternativa da criação de uma lane para representar um grupo é a mais aconselhável por representar mais claramente o processo . Realmente , concordo que devemos buscar que todos modelem e interpretem a notação de forma mais padronizada ´pssivel , porem , sempre defendi que a clareza na interpretação dos processos devem ser o objetivo maior a ser perseguido

  4. Ricardo, concordo com você sobre a clareza na interpretação dos processos como o objetivo maior a se buscar na atividade de modelagem.

    Penso que modelar processos de forma clara é como escrever um bom texto. Não basta apenas saber escrever, é preciso preocupar-se com a clareza do conteúdo – em como ele será compreendido por quem o lerá. Mas o primeiro passo para uma boa escrita é conhecer e aplicar bem as regras gramaticais da linguagem usada. Uma vírgula fora do lugar pode mudar completamente o sentido de uma frase.
    Da mesma forma, um elemento BPMN aplicado sem a preocupação com as regras da sua especificação também pode levar a interpretações distintas dos leitores em relação à expectativa de quem fez a modelagem – como vemos nos exemplos acima.

    Em nome de toda a equipe da iProcess, obrigada por sua contribuição!

  5. Muito interessante a abordagem sobre a questão; no meu caso, quase sempre eu mapeio conforme o exemplo exposto na 2ª figura (“…tarefas em paralelo porque eles fazem a reunião ao mesmo tempo”.).

    Uma vez ou outra eu mapeio conforme o terceiro exemplo (“Uma raia com um papel em grupo que abstrai os participantes e garante que as tarefas sejam realizadas em conjunto pelos envolvidos”).

    Mas nunca tinha visto mapeamento igual o feito na primeira figura.

  6. Parabéns pela abordagem Kelly!
    Compartilho do método apresentado, acreditando que seja aquele que apresente maior clareza para o leitor.

    OBS: Estou conhecendo o blog agora e gostando muito! Continuem assim!

  7. Kelly, como vai?
    Tive uma situação parecida com esse tópico:
    No caso, dois personagens preenchem um formulário de orçamento. A solução que usei foi por um comentário explicitando que a tarefa é feita em conjunto e depois levei o fluxo com a tarefa para a outra lane. Em seguida, usei uma gateway paralela para retornar ao fluxo principal e encerrar a ação. O que acha de usar o comentário para este fim?

  8. A sugestão é uma boa opção quando há um evento ao longo do fluxo. A questão é quando há vários eventos em que diversas áreas participam. Haveriam diversos “lane” para essa finalidade. Em fluxos mais complexos, onde ocorrem muitos eventos compartilhados, fica difícil essa abordagem.

  9. Boa tarde, no fluxo do processo de aquisição, tem a etapa de solicitar aquisição onde será elaborado o TR, havendo necessidade de especialista deve-se encaminhar o TR para o especialista elaborá-lo, caso contrário o próprio solicitante deve elaborá-lo. Minha dúvida pode haver duas tarefas iguais, mas com atores diferente. Ressaltando que são momento diferentes. Obrigado!

  10. Pode sim André. Existe inclusive um recurso no BPMN chamado Call activity, quando você define uma tarefa e quer reaproveitá-la em outro ponto do processo. Em vez de criar uma dupla definição (e ter que fazer múltiplas manutenções) você usa a Call activity no segundo ponto em que ocorreria no processo. Funciona tipo um subprocesso reusable, só que para tarefas. Nem todas as ferramentas implementam esse recurso para tarefa, é bom avaliar se ele existe no modelador que você está utilizando. Se não existir, também não há nada contra ter duas tarefas com o mesmo nome.

  11. Olá Daniel,
    Tenho modelado processos com essa notação há muitos anos (desde ainda a versão 1.1) e em todas as situações nas quais tive necessidade de representar esse cenário, em que ocorre a participação de mais de um participante na mesma tarefa, esta forma de representar tem funcionado. Se são tarefas diferentes, sim, precisaremos de lanes diferentes. Mas se o trabalho é colaborativo para gerar um resultado único, então o trabalho é um, contando com mais de um colaborador, que é o caso para o qual a sugestão se propoe :)

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>