Como modelar Processos de Negócio Matadores com a Notação BPMN 2.0 – Série elementos avançados II (Atividades de Múltiplas Instâncias)

Este é o segundo artigo da série “Como modelar Processos de Negócio Matadores com a Notação BPMN 2.0”, dedicada ao estudo de elementos avançados de BPMN.

No artigo anterior artigo 1 iniciamos o estudo dos marcadores de atividades, vimos que cada marcador tem uma função específica que determina o comportamento de uma atividade durante sua execução.

Neste segundo artigo da série darei andamento ao estudo dos marcadores de atividades abordando atividades de múltiplas instâncias, subprocesso ad-hoc, tarefa de compensação e subprocesso de transação.

Atividades de Múltiplas Instâncias (Multi-Instace Activity)

Representado por um marcador de 3 barras paralelas verticais presente na parte inferior central da atividade, dispara múltiplas instâncias da mesma atividade.

Lembrando que o marcador de múltiplas instâncias pode ser aplicado a uma tarefa ou subprocesso.

O atributo de múltiplas instâncias permite que uma atividade tenha “N” repetições, podendo ser instanciada em paralelo diversas vezes.

No exemplo acima é demostrado o fluxo do processo “Cadastro de Orçamentos”, iniciado pela tarefa “Cadastrar orçamento”, onde a tarefa de cadastro de orçamento deve ser realizada “N” vezes.

Com a aplicação do marcador de múltiplas instâncias, definimos que será realizado o cadastro de diversos orçamentos.

Regras de uso do marcador de atividades de múltipla instância

• Deverá ser previsto antes do disparo (da tarefa ou subprocesso) o número de instâncias que serão realizadas.
• O número de repetições pode ser estático ou dinâmico ( ou se preferir podemos dizer fixo ou variável).
• O número de repetições não tem a ver com a funcionalidade do marcador mas com a exigência do negócio.
• Este tipo de informação normalmente é definida por regras de negócio e informada na entrada da tarefa ou subprocesso.
• No exemplo acima poderia ser definido que é necessário o cadastro de 3 orçamentos (regra normalmente usada no mercado), com isso a tarefa seria executada 3 vezes.

Confusão quando a aplicação do marcador de múltipla instância

A forma como o marcador múltiplo está representado (3 barras na vertical), define que os cadastros serão realizados TODOS em paralelo.
O que isso quer dizer?
Ai está uma das maiores dúvidas e confusões na hora de aplicar e entender o conceito deste marcador.
Você pode estar se perguntando como diversas tarefas iguais poderiam ser executadas ao mesmo tempo – conhecido também como paralelismo de atividades.

Isso é possível através da automatização das tarefas de interação humana, típicas de  sistemas de um workflow, que controlam e disponibilizam as tarefas através de uma lista de trabalho.

Na prática (de forma manual) não há como controlar e executar múltiplas tarefas sem um controle tecnológico.

Com o controle tecnológico é possível a execução em paralelo destas atividades, através do disparo para membros diferentes da equipe ou grupo de trabalho responsável pelo trabalho.
O sistema identifica o grupo responsável pela atividade.
Identifica os membros com menor carga de trabalho e na sequência dispara para estes as próximas atividades.

Porque utilizar o marcador?

O principal benefício do uso do marcador é o ganho de performance no negócio, ou seja, TEMPO!
Importante: Este ganho só é possível, como disse, com o apoio e uso de sistemas que controle o fluxo do processo e entradas e saídas das atividades.
Geralmente este ganho é identificado através da análise do AS IS do processo e na sequência um redesenho de negócio somado a uma aplicação tecnológica (costumamos chamar de TO BE de negócio ou TO DO).

Quando utilizar o marcador?

Quando dispomos de uma equipe com o número mínimo de pessoas para atender de forma paralela as mesmas atividades.

Um exemplo típico: Processo de Call Center

Já passei diversas vezes por estas situações ao realizar o AS IS dos processos de meus clientes.
Processos que precisam contatar seus clientes para informar ou cobrar alguma coisa.
Normalmente é identificado nestes processos muitas rupturas e restrições que interferem no desempenho do processo.
Questões como handoffs, gargalos, variações, número de iterações com o cliente, tempo e custo destas atividades são analisadas.

Em uma das minhas analises, o processo AS IS consistia em entrar em contato com seus clientes de tempo em tempo para oferecer novos planos e serviços.
O processo consistia basicamente em contatar seus clientes de 3 formas: Telefone, email e SMS.
O email e SMS eram alternativas para os casos de clientes que não eram encontrados.

O trabalho era atendido por um Call Center que recebia diariamente uma lista de clientes (planilha com telefone, dados cadastrais e planos).
Quando não era possível o contato, era sinalizado pelo atendente nesta mesma planilha.

Ao final do dia esta planilha era utilizada pela TI com a identificação do clientes não contatados.
Através de ferramentas especializadas era feito o disparo dos emails e SMS.

Com a realização do TO BE tecnológico e implantação do processo, tudo começou a ser controlado e gerenciado por um sistema BPMS, que  disparava de forma proativa as tarefas para os atendentes do call center, identificava as ligações não realizadas e na sequência, através de integrações com web services, disparava automaticamente os emails e SMS para os clientes não contatados por telefone.
Todo este trabalho passou a fazer parte de um processo de múltiplas instâncias.

Subprocesso Ad-Hoc

Um subprocesso ad-hoc indica um conjunto de atividades desempenhadas sem uma sequência pré-definida pois suas tarefas (tasks) não são conectadas pelo fluxo de sequência (sequence flow).

É importante ressaltar que não existe uma obrigatoriedade na execução de todas as tarefas de um processo ad-hoc.

Estas atividades estão relacionadas, geralmente, a atividades humanas onde a quantidade de vezes e a ordem são definidas pelo executor.

Características do processo ad-hoc

• Tem execução imprevisível (O detalhamento e contexto de cada situação é o que definirá o fluxo a executar)
• Requer a execução aleatória de tarefas, sem ordem pré-definida
• Não existe obrigatoriedade na execução de todas as tarefas
• Não possuem fluxo de sequência em seu fluxo
• O conhecimento necessário para os encaminhamentos está no ator, e este conhecimento não pode ser replicado facilmente em regras ou fluxos pré-definidos.

São exemplos típicos de Processos ad-hoc: Organização de documentos para financiamento, solicitação de seguro de carro, escrever um novo livro.

Tarefa de Compensação (Compensation)

A tarefa de compensação é uma tarefa particular e não faz parte do fluxo normal de um processo. Em alguns momentos na modelagem de processos de negócios, precisamos “desfazer” uma atividade ou processo e em alguns casos, quando desfeito, precisamos gravar esta operação, o que requer uma etapa exclusiva representada por uma tarefa de compensação (compensation).
Este “desfazer” o processo poderia ser representado por um subprocesso, gerando um fluxo muitas vezes complexo.
A tarefa de compensação resolve este problema com apenas uma tarefa.

A tarefa de compensação é representada como uma tarefa normal, mas com um pequeno símbolo que se parece com o botão de “rebobinamento” como um leitor de áudio (dois pequenos triângulos apontando para a esquerda).

Sua conexão é realizada através da associação de compensação (compensation association) e ligado ao evento anexado a atividade já realizada. Este evento é conhecido como catch compensation.

No exemplo abaixo, por uma determinada condição do processo, a atividade “Reservar van”, já realizada, deverá ser compensada, levando ao seu cancelamento.

Tarefa típica de processos de contratação de serviços, processos de TI e processo bancários onde por muitas vezes é necessário realizar a compensação, desfazer a transação ou realizar o rollback.

Subprocesso de Transação (Transiction)

Transação é um tipo de subprocesso que contém um conjunto de atividades, logicamente relacionadas, e pode seguir um protocolo transacional específico. Ele faz com que todas as suas atividades sejam completadas com sucesso ou canceladas (compensadas).

O subprocesso de transação é representado por um retângulo de bordas arredondadas e linha dupla e pode ser representado tanto na forma contraída (collapsed) como na forma expandida (expanded).
A fronteira da atividade será uma linha dupla que indicará que trata-se de uma transação.

Para que o subprocesso de transação seja finalizado com sucesso todas as suas atividades devem ser completadas.
Veja o exemplo abaixo que demostra a representação do subprocesso de transação.

O exemplo acima demostra que é necessário que a reserva da van e do parque sejam concluídos para que o processo de reservas seja concluído com sucesso, levando a atividade de faturar comprador. Caso a reserva da van seja concluída e do passeio não, a reserva da van é cancelada (e vice-versa).

No caso de cancelamento, um evento intermediário de cancelamento (cancel), mostrará o caminho que o fluxo irá seguir (fracasso), levando a execução da atividade “Avisar da indisponibilidade”.

Erro (error): quando isto ocorrer significa que nenhuma conclusão bem sucedida como também nenhuma conclusão fracassada ocorreu. Neste caso usa-se a exceção para mostrar o perigo. Quando um perigo é detectado, a atividade é interrompida (sem compensação) e o fluxo prossegue pelo evento intermediário de exceção (erro).

Dando continuidade nesta série, no próximo artigo abordarei um dos elementos mais utilizados no fluxo de um processo de negócio: Gateways.
Não perca! Trata-se de um dos elementos mais importantes para a modelagem de processos de negócio. Apresentarei as regras e situações utilizadas nos gateways avançados,  pouco conhecidos e utilizados de forma correta pelos profissionais da modelagem.

Perdeu os artigos anteriores da série?
Então confere ai!

Como modelar Processos de Negócio com a Notação BPMN 2.0 (Série elementos avançados I)
Como modelar Processos de Negócio com a Notação BPMN 2.0 (Série elementos avançados III)
Como modelar Processos de Negócio com a Notação BPMN 2.0 (Série elementos avançados IV)