Eu gostaria de ter mais tempo para escrever sobre isso. Mas o tempo urge e ultimamente tenho recebido muitas dúvidas sobre isso.
Se você se questiona se deve ou não utilizar BPMN para representar os seus processos, então pode parar por aqui. Se você continuar a ler este texto, vou inferir que você é daqueles que já entendeu a importância de ter uma notação padrão para representar as coisas, e BPMN, mesmo não sendo perfeita, é o padrão para descrever processos. Caso você deseje aprofundar-se no assunto, sugiro ir direto à especificação da notação, que considero bastante clara. No site da OMG ela está livremente disponível. Outro documento muito útil é o BPMN 2.0 by Example, também disponível no site da OMG. Existem alguns livros, mas se você está começando não recomendo nenhum.
A grande dúvida de muitos usuários da notação é sobre como e quando utilizar as pools e swimlanes. Vou direto ao ponto. Pool NÃO é para identificar processo. Podemos ter diversas pools em um mesmo diagrama e mesmo assim ali só teremos UM processo. Pool é para identificar participantes. Só lembrando que um participante pode ser um papel ou até mesmo uma unidade organizacional, tal como um departamento. Já o uso da swimlane é livre. Você pode utilizar swimlanes apenas para organizar melhor as atividades de um mesmo participante. Ou pode utilizar swimlanes para representar diferentes participantes dentro de uma mesma unidade organizacional (pool). A questão é quando usar mais de um pool ou usar swimlanes. A resposta é simples. Utilize swimlanes dentro da mesma pool para representar os participantes que REALMENTE fazem parte do processo. Se o participante não faz parte do processo, represente ele em uma pool separada, ou seja, utilizando um diagrama de colaboração. Pode ser um pool black-box, por exemplo. A resposta, como acabamos de ver, é simples. O problema é que a maioria esmagadora das pessoas tem uma enorme dificuldade em perceber quem realmente faz parte do processo e quem não faz [apesar de estarem relacionados].
Bom, saber quem realmente faz parte do processo não é simples mas é fácil. Os participantes que realmente fazem parte do processo só podem ser de dois tipos. O primeiro tipo são aqueles que executam atividades nas quais se produz alguma saída que será utilizada em outra atividade do processo, ou no próprio encerramento (no caso de produtos finais), ou que vai servir de insumo (entrada) para a transformação que será realizada em outra atividade posterior. O segundo tipo são aqueles participantes que executam atividades de transformação, com base em insumos recebidos de uma atividade anterior, mas cuja saída não necessariamente vai ser usada como insumo em uma atividade posterior (no caso de subprodutos, ou produtos não principais). Se o participante não executa nenhuma atividade de transformação baseada em um insumo recebido, nem é responsável pela produção de algo que servirá insumo para uma atividade seguinte, então ele NÃO participa realmente do processo. Esse participante pode até ter algum tipo de relação (colaboração) com o processo, mas ele definitivamente não contribui de forma significativa para o produto final DAQUELE processo. É o que podemos chamar para fins didáticos de "participante coadjuvante". É como se aquele participante apenas "comendo pelas beiradas" do processo.
Um exemplo típico é o processo "Entregar pizza" de uma pizzaria qualquer. Vamos definir as fronteiras deste processo: Ele começa com o pedido do cliente e termina com a pizza entregue. O cliente que pede a pizza, por mais que seja importante para o processo, não é responsável sequer por um grão de farinha de trigo da pizza entregue. Não há nada fornecido pelo cliente que tenha sido LITERALMENTE transformado para fazer parte da pizza finalmente entregue. Você pode até dizer que o dinheiro do cliente foi usado para comprar os ingredientes da pizza. Mas a realidade não é exatamente assim. Note que o processo é instanciado para CADA pedido. E em cada pedido o dinheiro do cliente só é recebido ao final do processo. Logo não há que se falar que o dinheiro dele foi "transformado" na pizza, pois isso de fato não ocorreu naquela instância do processo. Na verdade o dinheiro do cliente foi guardado para ser usado em outro processo, talvez um processo "Realizar compras da pizzaria". Note que o processo nada mais é do que uma representação da vida real (a dificuldade das pessoas é justamente perceber a realidade; bons analistas de processos conseguem perceber bem a realidade). Feitos esses esclarecimentos, a melhor forma de representar o cliente, no caso do processo "Entregar pizza", é em uma pool separada, em um diagrama de colaboração, no qual o cliente interage com os participantes da pool principal apenas por meio de comunicação. Essa é a forma mais adequada de representar o processo. E isso tem que ser assim para o seu próprio bem. Ao incluir o cliente como participante REAL do processo, você perceberá que terá que fazer uma série de gambiarras na notação para representar corretamente o processo. Vão aparecer gateways, inícios e fins desnecessários. O artifício da comunicação, muito bem previsto pela notação, nos ajuda justamente a representar o processo como eles realmente são, de forma simples, muitas vezes apenas utilizando simples comunicação entre participantes de diferentes pools. Simples assim. O processo é um só, mas colocar o participante em uma pool diferente significa dizer que o papel dele, DO PONTO DE VISTA DAQUELE PROCESSO, é assessório, ou seja, ele é um participante coadjuvante. Eu poderia dar aqui mil e um exemplos desse tipo de situação. É claro que se você estiver modelando um processo chamado "Fazer-tudo-dentro-da-organização-e-mais-um-pouco", praticamente todos os seus participantes estarão na mesma pool (garanto que você terá problemas com fornecedores e clientes). Mas não é esse o caso quando trabalhamos com modelagem de processos dentro de uma organização. Geralmente os processos são modelados um a um. Até porque, em uma empresa, várias coisas acontecem ao mesmo tempo e, portanto, deve ser possível instanciar diversos processos ao mesmo. E foco em um processo é vital para a correta modelagem.
Vale ressaltar que, apesar do que eu acabei de dizer aqui, não existe certo ou errado desde que você esteja utilizando corretamente a notação. Então, se você prefere inserir um participante coadjuvante dentro da pool principal, a decisão é sua. Mas você vai perceber que não é a forma mais adequada e que o diagrama vai ficar muito mais complexo (para não dizer sujo). Linha e seta é para representar movimentação de entradas e saídas entre atividades interdependentes. Comunicação precisa ser representada pela notação de comunicação (ora bolas, é para isso que ela serve), ou seja, a linha tracejada [e seta] (fluxo de mensagens, não de insumos reais que serão transformadas naquele processo em foco). Uma coisa é uma coisa, outra coisa é outra coisa. Processo é uma sequência de atividades para transformar entradas em saídas. O objetivo de todo processo são as saídas finais (aquelas que não são mais transformadas). Se qualquer participante não colabora de forma direta para esse objetivo (nem que seja com um "grão de farinha"), então ele NÃO faz parte realmente do processo. Coloque-o onde ele realmente merece: OUTRA POOL!
Comentários