Desmistificando tipos de tarefas em BPMN: Tarefas automáticas

No artigo anterior (Desmistificando tipos de tarefas em BPMN: Tarefa Abstrata, Tarefa de Usuário e Tarefa Manual) iniciamos uma série de três artigos sobre os tipos de tarefas em BPMN. Para facilitar o entendimento, estamos discutindo os os tipos de tarefa de acordo com seu propósito (essa divisão não é oficial):

Tarefas de execução de rotinas automáticas

Para representar situações em que rotinas que são executadas automaticamente no processo (em que seu acionamento é determinado pelo andamento do fluxo do processo, sem que haja uma pessoa para acioná-lo), BPMN sugere três tipos de tarefa: tarefa de serviço, tarefa de script e tarefa de regra de negócio:

Os tipos de tarefa automáticas: tarefa de serviço (service task), tarefa de script (script task) e tarefa de regra de negócio (business rule task)

De acordo com a especificação:

“Uma Service Task (tarefa de serviço) é uma tarefa que usa algum tipo de serviço, que pode ser um Web Service ou uma aplicação automatizada.” (pág 156)

“Uma Script Task (tarefa de script) é executada pelo motor de processos de negócio (business process engine). O modelador ou implementador define um script em uma linguagem que o motor de processos consegue interpretar. Quando a tarefa estiver pronta para iniciar, o motor de processos executará o script. Quando o script for concluído, a tarefa também será concluída.” (pag 162)

“Uma Business Rule Task (tarefa de regra de negócio) propicia um mecanismo para o processo para enviar informações a um Business Rules Engine (motor de regras de negócio) e obter o resultado do cálculo que o motor de regras pode prover. ” (pag 161)

 

Todas as três são utilizadas na modelagem quando temos um processo que está sendo automatizado (se o processo é executado manualmente, fora de um BPMS ou workflow, é necessário que haja uma atividade manual em que uma pessoa acione a execução de uma funcionalidade; portanto a tarefa em si é de uma pessoa).

 A diferença entre elas é que a tarefa de serviço (service task) aciona a operação de um sistema de informação externo com o qual o motor de processo se comunica (process engine) – que pode ser implementado através de tecnologias como webservices, RMI (Remote Method Invocation), EJB (Enterprise Java Beans), etc. Já a tarefa de script (script task) executa um trecho de código que a própria aplicação de motor de processos interpreta e executa (e cada fornecedor de produto pode definir sua linguagem de script própria). Por exemplo, a transformação de um tipo de dado em outro ou a realização de cálculos com os dados da instância do processo, são exemplos de tarefas de script.

A tarefa de regra de negócio (business rule task) comporta-se da mesma forma que a tarefa de serviço, porém possui o propósito específico de obter resultado da aplicação de uma determinada regra de negócio no processo (leia mais sobre regras de negócio e Business Rules Management no artigo Business Rules e a Dinâmica do Negócio).

Um exemplo de processo com tarefas automáticas de serviço, de tarefa e regra de negócio

No processo hipotético acima temos exemplos aplicados dos três tipos de tarefas automáticas.

  • A tarefa “Identificar prioridade do atendimento” é uma tarefa de regra de negócio, pois executa uma regra da organização (por exemplo: chamados de clientes com contas premium ou chamados que já tiveram uma visita técnica mas o problema não foi solucionado são tratadas como prioridade “emergência”, enquanto as demais são prioridade “normal”. Se a organização quiser mudar esta regra e incluir outros planos no atendimento de prioridade emergencial, pode modificar a regra de negócio sem impactar no processo).
  • Neste processo em que todos os chamados são originados com prioridade “normal”, a tarefa “Elevar prioridade do atendimento” é uma tarefa de script pois muda de “normal” para “emergência” uma informação do próprio processo, elevando a prioridade dos processos que passam por ela (sem precisar acessar outros sistemas).
  • A tarefa “Identificar técnico responsável” é uma tarefa de serviço pois acessa o sistema de localização da empresa identificando que técnico está mais próximo do endereço do cliente. Ela aciona um serviço deste sistema, e recebe como retorno a informação do técnico disponível.
  • A tarefa de serviço a seguir “Sinalizar sistema de chamados”, aciona um serviço do sistema usado pela empresa para enviar ao comunicador do técnico a nova chamada prioritária.
  • A tarefa de serviço “Agendar visita técnica” registra o chamado no sistema que libera a lista de clientes a serem visitados no dia pelos técnicos. Como é uma visita normal, ela é registrada de acordo com o agendamento realizado com o cliente na criação da ficha de atendimento.

Aprenda a dominar a notação BPMN utilizando as melhores práticas com nossos instrutores, em um curso repleto de exercícios e um laboratório prático de modelagem de um processo de negócio de ponta a ponta!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br/ipe04

Desmistificando tipos de tarefas em BPMN: Tarefa Abstrata, Tarefa de Usuário e Tarefa Manual

Em sua riqueza de elementos para a representação de processos de negócio, a notação BPMN traz uma classificação de tipos de tarefas.

Elas ajudam a identificar a forma como a tarefa deve ser executada:

Estes elementos e seus comportamentos esperados estão descritos na especificação BPMN (disponível em http://www.omg.org/spec/BPMN/Current). Apesar disto, a identificação de quando usar cada tipo de tarefa ainda é alvo de alguma ambiguidade.

Em uma série de três artigos, trataremos estes tipos de tarefas com mais detalhes para esclarecer as dúvidas comuns. Para facilitar o entendimento, trataremos os tipos de tarefa de acordo com seu propósito (essa divisão não é oficial):

Tarefa abstrata

A tarefa abstrata (abstract task) é a tarefa sem tipo específico.

Tarefa abstrata (abstract task)

Sobre ela, a especificação diz:

“Uma tarefa sem nenhum tipo de especificação é chamada tarefa abstrata (Abstract Task) (ela era referenciada como None Task em BPMN 1.2).” (pag. 154)

Ou seja, a tarefa abstrata (abstract task) pode ser utilizada em modelagens cujo tipo de tarefa ainda não está definido ou em casos onde a tipificação da tarefa simplesmente não se faz necessária. É o caso dos processos executados manualmente.

Um processo de negócio modelado com tarefas abstratas.

Tarefas de interação humana

Para representar tarefas cuja execução envolve a atuação de pessoas em um processo, BPMN sugere dois tipos de tarefa: a user task (tarefa de usuário) e a manual task (tarefa manual).

Tarefa manual (manual task) e Tarefa de usuário (user task)

O que a especificação diz sobre estes tipos de tarefa:

“Uma Tarefa de Usuário (User Task) é uma tarefa típica de “workflow” onde um ator humano desempenha a tarefa com a assistência de uma aplicação de software e é disponibilizada através de uma lista de de trabalho ou outra forma de gerenciamento semelhante. ” (pág 160)

“Uma Tarefa Manual (Manual Task) é uma tarefa que é esperada que seja executada sem o suporte de nenhuma aplicação de execução de processos de negócio ou outra aplicação. Um exemplo disso pode ser um técnico de telefonia instalando um telefone no endereço de um cliente.” (pág 161)

“10.3.4.1 Tarefas com o envolvimento humano
Em muitos fluxos de trabalho, o envolvimento humano é necessário para executar certas tarefas especificadas no modelo de fluxo de trabalho. BPMN especifica dois tipos de tarefas com o envolvimento humano, a Tarefa Manual (Manual Task) e a Tarefa de Usuário (User Task).
A tarefa de usuário é executada e gerenciada por um motor de execução de processos de negócio. Atributos relativos ao envolvimento humano, como as pessoas envolvidas e a renderização de interfaces de usuário (UI) podem ser especificados em grande detalhe.(…)
Uma tarefa manual é uma tarefa que não é gerenciada por qualquer mecanismo de processo de negócio. Ela pode ser considerada como uma tarefa não gerenciada, não gerenciada no sentido de que o motor de processos de negócio não acompanha o início e o fim de tal tarefa.
Um exemplo disso poderia ser uma instrução de papel como base para um técnico de telefonia instalar um telefone em um local do cliente.” (pág 165)

 

Ou seja, uma user task (tarefa de usuário) é a tarefa que é executada através de uma aplicação e gerenciada por uma lista de trabalho(1). Em outras palavras, é a tarefa realizada através de uma aplicação, como um BPMS (Business Process Management Suite), uma aplicação de workflow, uma ferramenta de gestão de cronograma ou qualquer outro sistema que apoie o controle do processo.

Já as tarefas manuais (manual task) são aquelas executadas no mundo físico, sem o controle por parte de uma aplicação.

Aqui há uma confusão comum na interpretação do “uso de uma aplicação”, inclusive replicada em literatura. Para entender claramente a diferença entre elas, é preciso compreender que o que define se uma tarefa é user ou manual task não é se usamos alguma ferramenta para executá-la, e sim se há um sistema controlando a sua execução.

Isto quer dizer que, se temos por exemplo um processo de venda de produtos que é todo executado manualmente, mas em uma determinada atividade uma planilha eletrônica é usada para calcular o valor a ser cobrado do cliente, e um e-mail é enviado ao cliente com o orçamento do produto, ainda assim (apesar de usar uma aplicação de planilha e o software de e-mail para o trabalho) esta será uma tarefa manual, pois não há controle nem gestão sobre quem faz, quando iniciou e quando concluiu a tarefa.

Mesmo utilizando ferramentas como planilha eletrônica e email, ainda assim a tarefa "Apresentar orçamento" neste processo é manual.

Numa modelagem de processo que não será automatizado, e que portanto são pessoas que lerão e interpretarão o modelo, não faz muito sentido essa diferenciação, já que as pessoas, ao lerem a documentação do processo, têm condições de interpretar o modelo mesmo que os tipos de tarefas não estejam esclarecidos.

Na modelagem para automatização, entretanto, isso é muito importante. A tarefa de usuário é aquela em que o processo deve aguardar que um usuário informe o resultado do trabalho, registrando que a mesma foi concluída para então dar seguimento ao fluxo do processo. Já sobre a tarefa manual o sistema não tem nenhum controle, então mesmo que ela seja incluída no modelo, ele “passará batido” por ela.

Por exemplo:
Considere novamente o processo de atendimento de chamado, no qual há uma atividade para um técnico de telefonia para realizar uma visita técnica ao cliente, e que este processo terá sua execução controlada por uma aplicação (por exemplo um BPMS).

Neste processo, podemos ter dois cenários:

Cenário 1: O Técnico acessa uma lista de tarefas, com todos os chamados a realizar, identifica o chamado que está executando e finaliza a tarefa. Com isso, o sistema identifica que a mesma foi concluída e segue o fluxo disponibilizando a próxima tarefa ao respectivo ator responsável. Neste caso, a tarefa está sendo controlada pelo sistema (seu início e fechamento), portanto é modelada como uma tarefa de usuário.

Cenário 2: O Técnico não acessa o sistema. Ele pode, por exemplo, receber ao início do dia uma lista impressa com todos os clientes a visitar. A cada visita, o cliente assina o papel confirmando que o atendimento foi realizado. Ao fim do dia, quando o técnico retorna para a empresa, ele entrega a lista ao Atendente, que então verifica se o atendimento foi realizado e registra no sistema o resultado do atendimento. Neste caso, a tarefa do técnico é modelada como uma tarefa manual, para que fique visível aos que olham o modelo em que momento o mesmo realiza seu trabalho (e que, do ponto de vista do processo de negócio, existe uma dependência da tarefa de "Verificar resultado do serviço" em relação à "Realizar visita técnica", mas o sistema não controla o início nem o fim do trabalho realizado.

Assim, concluímos que, na modelagem com a notação BPMN, o tipo de tarefa não é definido pelo uso de sistemas para realizá-la, e sim se há alguma aplicação sendo utilizada para controlá-la.

_______

(1) Processos podem ser controlados por aplicações de diferentes tipos. Isto já foi tema deste blog no artigo Gerenciando a execução de processos com (ou sem) um BPMS.

 


Aprenda a dominar a notação BPMN utilizando as melhores práticas com nossos instrutores, em um curso repleto de exercícios e um laboratório prático de modelagem de um processo de negócio de ponta a ponta!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br/ipe04

Desmistificando o uso de gateways em BPMN

Existem duas questões relacionadas a BPMN que precisam ser consideradas na utilização da notação: as regras da especificação e a lógica do processo.

As regras da especificação são relativamente fáceis de aplicar já que são bastante claras. Elas definem como são os símbolos, como podem se conectar e o que significam. As dúvidas mais frequentes geralmente estão relacionadas a como aplicá-las para representar as particularidades da lógica do processo de negócio que estamos mapeando.

Recentemente recebemos algumas dúvidas de um leitor do nosso blog sobre a aplicação de gateways, cujas respostas compartilharemos aqui, guiados por esses dois aspectos e mais alguns cuidados de boas práticas.

1) Existe alguma restrição em começar um processo com um evento de inicio e logo depois um gateway?

Um diagrama BPMN de processo em que o primeiro elemento do processo após o início é um gateway.

Pela especificação não. O uso do gateway paralelo após o evento de início neste processo de exemplo enviado pelo leitor é perfeitamente aplicável. Qual seria a razão de se criar um impedimento a  tarefas realizadas em paralelo quando um processo inicie - o que na verdade pode representar um excelente ganho de desempenho no processo ao se reduzir a sua duração?

Entretantopode haver restrição no caso do uso de gateway baseado em dados, como o Inclusivo ou o Exclusivo. Mas é uma restrição lógica: como esses gateways testam um dado para determinar o roteamento do processo, a informação precisa ter sido gerada antes. Assim, na maior parte das vezes, antes do gateway será necessário uma atividade que forneça essa informação. Mas nem sempre. Por exemplo: se o processo começar com um evento de mensagem, pode-se presumir que a informação seja obtida da mensagem recebida ao iniciar o processo. Quando estamos modelando, precisamos pensar nisso.

Portanto, a restrição não é de regra de uso do elemento, mas está associada à lógica do processo mapeado.

 

2. Como fazer quando se deparar com vários gateways em sequência? É correto encadear gateway?

Um diagrama de processo em BPMN com gateways encadeados.

Também não há nenhuma regra restringindo o encadeamento de gateways, mas fazer isso pode tornar a leitura do diagrama mais complexa, além de serem mais elementos agregados no diagrama (quando ele começar a ficar grande, qualquer elemento a menos pode significar uma bela economia !)

A única observação que faço sobre este tipo de diagrama é lembrar que gateways não precisam ser binários (com apenas duas saídas). As melhores práticas de uso da notação recomendam inclusive que se evite utilizar perguntas na definição de gateways porque elas tendem a gerar resultados do tipo “Sim”/”Não”. Em vez disso, recomendamos usar uma regra avaliativa.

Por exemplo: digamos que uma tarefa de avaliação possa resultar em: aprovação, aprovação com restrições ou reprovação, e que cada resultado leve a uma sequência de ações diferentes no fluxo.

Em vez de usar um gateway “Aprovado?” que levaria a resultados “Sim” e “Não“, e então no caso de “Sim” incluir outro gateway que verifica se “Possui restrições?” (ou seja, dois gateways encadeados), poderíamos simplificar em um único gateway, que cuja regra poderia ser testar o “Resultado da avaliação“, com três saídas: “Aprovado“, “Aprovado com restrições” e “Reprovado“, cada uma direcionando ao fluxo de ações que devem se seguir. O exemplo abaixo ilustra os dois casos.

A mesma orientação poderia se aplicar ao exemplo enviado pelo leitor, mas como essa é uma questão associada à lógica do processo e as sequências que saem dos gateways não estão nomeadas, seria necessário avaliar o caso com mais cuidado.

BPMN 2.0 – Novos Diagramas e Elementos: Coreografia no detalhe

No artigo anterior (BPMN 2.0 – Novos Diagramas e Elementos: Introdução a Coreografia) introduzimos o assunto a respeito do Diagrama de Coreografia. Neste artigo nossa proposta é detalhar a coreografia, apresentando os principais elementos BPMN utilizados para uma modelagem completa do diagrama em questão.

O diagrama de coreografia abaixo apresenta os detalhes do comportamento da coreografia, descreveremos logo abaixo cada um dos elementos. 

Elementos do diagrama de coreografia

1. Evento (Event)
Os eventos são elementos comuns a ambos diagramas de coreografia e de orquestração. Representam algo que acontece durante o curso do processo e podem ser de três tipos distintos: Inicio, intermediário e fim.

Dos eventos utilizados no diagrama de orquestração, aplica-se na coreografia os eventos:

Início: simples (none), tempo (timer), condicional (conditional), sinal (signal), múltiplo (multiple).
Intermediário: simples (none), condicional (conditional), ligação (link) e múltiplo (multiple). Atachados a atividade: cancelamento (cancel), compensação (compensation), condicional (conditional), sinal (signal) e múltiplo (multiple).
Fim:  simples (none) e terminate.

Para uma leitura mais detalhada sobre eventos veja os artigos sobre eventos de início e fim e eventos intermediários.

2. Atividade (Activity)
especificação da OMG BPMN versão 2.0, descreve interações entre processos como sendo Message Exchange Patterns (MEPs) ou padrões de troca de mensagens.  A MEP é a Atividade (Activity) de uma coreografia, chamada também de Tarefa de Coreografia (Choreography Task).

Atividade - Interação entre os participantes

3. Desvio (Gateway)
Nos processos de orquestração, os gateways são usados para criar caminhos alternativos ou paralelos para o processo. Da mesma forma acontece na coreografia: as interações entre os participantes pode acontecer em seqüência, em paralelo, ou por meio de seleção exclusiva.

4. Participante (Participant)
Os participantes fazem parte da Atividade de coreografia e corresponde a uma piscina (pool) do diagrama de orquestração.

O participante que inicia a troca de mensagens (parte ativa) é representado pelo fundo branco, já o participante que recebe o primeiro comunicado (parte passiva) está representado com o fundo preenchido (aqui em cinza). O participante que inicia a comunicação pode ser representado na extremidade superior ou inferior da atividade, como demostrado na imagem abaixo:

As atividades de coreografia da esquerda e direita são equivalentes

5. Fluxo de Sequência (Sequence Flow)
É utilizado para demostrar a sequência das atividades de coreografia e só pode se conectar a outros objetos do fluxo como os eventos, gateways  e atividades de coreografia.

6. Mensagem (Message)
Representa a informação contida  na comunicação entre duas entidades ou processos. No caso da coreografia, representa a informação transmitida na comunicação entre os participantes.

A mensagem de início, transmitida pelo participante inicial, é representada pelo envelope de fundo branco e a mensagem de retorno (quando houver) é representada pelo envelope de fundo preenchido.

Mensagem - Elemento que representa a informação contida na comunicação entre os participantes.

Interação entre participantes  e atividade multi-instance
No exemplo abaixo, os participantes Cliente e Concessionária interagem na atividade Compra de automóvel e os participantes Concessionária e Fornecedores de Peças interagem na atividade Solicitação de Orçamento.

Atividade de Coreografia - Representa uma interação entre dois participantes (pools)

A atividade da esquerda, representa a comunicação entre o participante Cliente (que inicia a comunicação) e o participante Concessionária. Nesta atividade o Cliente comunica seu interesse na compra de um automóvel. Já a atividade da direita demostra que um dos participantes pode ser multi-instance: o participante Fornecedores de Peças representa um papel atribuído a mais de um participante (a concessionária solicita orçamento para vários fornecedores de peças).

Atividade de subcoreografia (Sub-choreography task)
Uma atividade de subcoreografia agrega a identificação de todos os participantes envolvidos em um subconjunto de atividades de coreografia, e representa uma coregrafia refinada em interações (várias trocas de mensagens). Pode ser declarado mais de um destinatário, mas apenas uma iniciação pode ser realizada. Graficamente, a atividade pode ser demostrada de forma contraída (collapsed), representado pelo símbolo “+” indicando a existência de outro nível de detalhe. A mesma Atividade de subcoreografia pode ser representada de forma expandida (expanded) apresentando o seu conjunto de detalhes na própria coreografia.

A Imagem acima demostra a atividade de subcoreografia contraída(collapsed), representada pelo símbolo “+” indicando a existência de outro nível de detalhe, e sua representação expandida (expanded).

Com estes elementos, BPMN 2.0 possibilita a criação de um diagrama focado em documentar uma visão objetiva do processo, que pode ser compartilhada entre os participantes sem revelar os pormenores do negócio de cada organização envolvida.

BPMN 2.0 – Novos Diagramas e Elementos: Introdução a Coreografia

Com frequência a notação BPMN tem sido tema de nossos artigos no blog, em geral relacionados aos elementos do diagrama de orquestração. Entretanto, desde 2011 a notação agregou, em sua última revisão, dois novos diagramas à especificação, o diagrama de conversação e o diagrama de coreografia.

Iniciaremos neste artigo o assunto a respeito das novidades relacionadas aos novos diagramas, começando pelo diagrama de coreografia, então vamos lá!

Diagrama de Coreografia (Coreography Diagram)

Para BPMN a Coreografia  é um tipo de diagrama que difere em propósito e comportamento da representação de um processo de negócio padrão (diagrama de orquestração).

O diagrama de orquestração é o mais conhecido e utilizado pela maioria das ferramentas de modelagem e define o fluxo das atividades do processo de  uma organização. Em contraste, a coreografia  define como processos interagem uns com os outros.

Na coreografia o foco não está na orquestração do trabalho realizado entre os participantes, mas sim na orquestração da troca de informações (mensagens) entre os processos da organização e de outros agentes externos (processos de fornecedores, clientes, etc), demostrando a dinâmica da comunicação entre eles.

As atividades de coreografia são conectadas em um fluxo lógico que representa toda a troca de informações e suas interações que acontece naquele processo de negócio.

Diagrama de Coreografia - foco está na troca de mensagens entre os processos (participantes)

Diagramas de coreografia podem ser vistos também como um contrato de negócio entre os participantes, onde o foco está na troca de informações (mensagens), implica no envio ou recebimento de algum tipo de documento, como é o caso do diagrama acima, onde o contrato de negócio está na forma de uma ordem de compra. Este diagrama representa o Processo de Ordem de Compra, o fluxo demostra a comunicação entre os três participantes (Varejista, Fornecedor e Fornecedor Externo).

Agora veja o mesmo processo representado pelo diagrama de orquestração, evidenciando a orquestração do trabalho realizado entre os participantes e  a sequência das atividades do processo de negócio.

Diagrama de Orquestração - foco na orquestração do trabalho realizado entre os participantes.

Cada participante representa uma piscina (pool) do diagrama de orquestração, raias (lanes) não são representadas no diagrama de coreografia e conectores de fluxos de atividades (message flow) viram atividades na coreografia. Veja este outro exemplo abaixo.

Os participantes representam a piscinas do diagrama de orquestração e os fluxos de atividades viram atividades na coreografia.

Resumindo, podemos dizer que Diagrama de Coreografia:

  • Focaliza a forma como os participantes trocam mensagens, demonstrando a comunicação entre os eles;
  • É a representação dos processos e suas interações;
  • Demonstra o comportamento esperado entre os participantes;
  • É o contrato de negócio de interação entre os participantes.

No artigo seguinte desta série: BPMN 2.0 – Novos Diagramas e Elementos: Coreografia no detalhe, nos aprofundamos um pouco mais no assunto, apresentando os principais elementos BPMN que contribuem para uma modelagem completa. Um descrição detalhada de cada elemento, suas características e como eles são usados em uma coreografia.

Esperamos que tenham gostado desta introdução ao assunto, fiquem a vontade para fazer seus comentários, tirar dúvidas, críticas e sugestões são sempre bem vindas.