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

Modelagem de Processos de Negócio: Diferenças entre diagrama, mapa e modelo de processos

Quantas vezes você já se referiu ou ouviu pessoas se referirem a um mesmo desenho de processo como sendo um diagrama de processo ou mapa de processo ou ainda, como um modelo de processo?

Este é um assunto controverso, principalmente para pessoas que estão começando em projetos que envolvem iniciativas de processos de negócio ou iniciando o estudo de BPM.

Dúvida comum que é esclarecida em nosso curso de Modelagem de Processos de Negócio (iPE01). Constatamos que os termos diagrama, mapa e modelo de processos são utilizados, por muitas vezes, de forma errônea, como sinônimos, porém eles na verdade tem diferentes propósitos e aplicações.

Falaremos neste artigo sobre os três níveis de modelagem (diagrama, mapa e modelo), as diferenças em seus desenhos, no nível de detalhamento e utilidade de cada um.

Diagrama, mapa e modelo são três níveis de “representação” de processos.

Estes três níveis de representação de processos diferem-se em níveis de abstração, informação, utilidade, precisão, complexidade, padronização de elementos do fluxo, evolução e amadurecimento do desenho proposto.

diagrama, mapa e modelo de processos

Fazendo uma analogia com mapa geográfico, podemos dizer que o diagrama de processo demonstra a rota que é realizada em uma visão simplificada, com o trajeto percorrido, evidenciando os principais pontos de referência, o local de origem e destino. O mapa do processo apresenta a rota de forma mais detalhada, com elementos como nome de avenidas, ruas, principais pontos de referências, opções de rotas alternativas, trajeto e tempo estimado para cada rota. O modelo de processo apresenta a rota de forma mais completa e precisa, descrevendo a situação atual do trânsito, rota de transporte público, clima na região da rota, além de fotos das avenidas e ruas.

O Diagrama é uma representação inicial do processo. Ele demonstra o fluxo básico focando as principais atividades. Não trata exceções ou falhas no processo.

Utilizado para capturas rápidas no processo, por isto não é muito preciso.
Ajuda a obter entendimento rápido das principais atividades, representando ideias simples em um contexto alto nível.

Esta representação inicial do processo pode significar várias coisas. O diagrama pode representar um macroprocesso organizacional, por exemplo, como também se tratar de apenas um esboço (versão inicial do processo) de uma primeira avaliação.

diagrama de processo

Em um primeiro momento busca-se conhecer os processos identificando as atividades chave. Esta é uma das técnicas mais utilizadas para conhecer os processos organizacionais, conhecida como abordagem top-down, em uma visão de macroprocessos (visão interfuncional) até chegar aos processos operacionais.

Em uma primeira versão, o processo muitas vezes não recebe as informações necessárias para partir diretamente para um nível de mapa ou modelo. Fatores como a precisão e nível de detalhamento influenciam a forma como o processo é modelado. A precisão varia de acordo com a profundidade em que se avalia cada aspecto do processo e suas atividades, e aumenta de acordo com o número de pessoas entrevistadas das áreas que fazem parte dos processos.

O nível de detalhe define o quanto cada processo, sub-processo, atividades, tarefas, procedimentos, atributo ou aspecto é descrito.

O mapa é uma evolução do diagrama, acrescentado de atores, eventos, regras, resultados e um detalhamento do processo. Ampliada para uma visão mais detalhada, o mapa fornece informações de maior precisão do desenho do processo.

Neste nível as atividades do processo e seus objetivos estão mais claros. Foram identificadas as responsabilidades atribuídas ao longo do processo. Isto se deve aos métodos de levantamento de informações utilizadas pela equipe envolvida na iniciativa de BPM.

Através de pesquisas a equipe obteve um entendimento inicial, e segue para as entrevistas com os envolvidos no processo (donos de processos, clientes, fornecedores, pessoas que trabalham no processo, etc). Esta etapa é de grande importância para identificação das regras, validações, caminhos de exceções, papéis e detalhamento de atividades.

Existem diversos métodos para levantamento de informações, como workshops, conferências, observações diretas, etc. Abordaremos este assunto em um próximo post.

A escolha do nível de representação de processos dependerá do propósito da modelagem, em muitos casos, o diagrama ou mapa já são suficientes para representar o processo.

O modelo é a versão final da evolução do processo. Esta representação traz um alto grau de precisão e detalhamento do processo.

Uma grande vantagem é a capacidade de execução do processo através de simulações. Estas simulações geram informações que acercam o desempenho do processo, úteis para analisar/validar a execução do processo.

Este nível de execução requer uma descrição detalhada dos atributos do processo, descrevendo propriedades e características das entradas/saídas, procedimentos/passos, recursos, custos, alocação, simulação, parâmetros de duração, etc. Estes atributos podem ser classificados em categorias e sua documentação varia de acordo com o objetivo da modelagem realizada.

A partir do modelo é possível executar as próximas etapas do ciclo de gestão por processos, como a análise, redesenho, reengenharia, melhoria continua e medição do processo.

Você se interessou pelo assunto?

A área de conhecimento de modelagem de processos fornece o entendimento dos propósitos, benefícios, habilidades e técnicas e é muito utilizada pelas organizações para conhecer, documentar e melhorar processos.
Este tema é explorado com mais profundidade em nosso curso de Modelagem de Processos de Negócio, onde abordamos de forma mais abrangente o tema. http://www.iprocesseducation.com.br/ipe01.html, oferecido pela iProcess Education.

 

A diferença entre “desenhar” e “modelar” processos

Não basta saber usar um editor de textos para ser um bom escritor.
O mesmo se dá na relação entre uma ferramenta de modelagem e o designer de processos(1).

Pode parecer estranho começar um artigo com uma afirmativa como essa. Mas o fato é que muitas vezes já nos encontramos em conversas com pessoas envolvidas em iniciativas de processos com a expectativa que, se treinassem pessoas da empresa para usar alguma ferramenta para desenhar de processos (como o Bizagi, por exemplo), isso bastaria para que essas pessoas pudessem documentar os processos das suas áreas (e assim teriam modelados os processos da organização).

Mas criar um bom modelo de processo é como escrever um bom texto. Não basta apenas dominar o editor de textos e saber escrever as palavras, é preciso preocupar-se com a clareza do conteúdo – em como ele será interpretado por quem o lerá.

Designer de processos em ação.

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.

As definições da especificação BPMN funcionam como as regras gramaticais de um idioma. Se forem bem conhecidas por quem as usa podem ser 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.

Conhecer as regras de uso de um idioma ou de uma notação são apenas o primeiro passo para comunicar-se bem com quem lerá o produto do trabalho. As dúvidas mais frequentes geralmente estão relacionadas a como aplicá-las ao conteúdo que queremos transmitir.

Em uma história bem contada, a sequência de fatos, determinada pelo enredo, é fundamental para o seu entendimento. Em algumas situações, fatos podem ser contados em paralelo, em outros casos eles têm uma sequência que se for quebrada pode dificultar a compreensão ou mesmo gerar interpretações equivocadas.

Na modelagem de processos, a lógica do processo é o enredo. Ela se define tendo um evento que sinaliza o início da estrutura de precedência entre as atividades e regras de roteamento do fluxo, que podem apresentar cenários com sequências de atividades paralelas ou alternativas, até atingir o seu fim. É ela que determina como os elementos da notação devem ser usados para criar o diagrama do fluxo do processo. Toda a modelagem deve ter em vista garantir a integridade da lógica do processo.

Assim como a boa escrita, isto é fruto de uma habilidade desenvolvida com a prática. Esta habilidade se constrói:

  • desenhando processos,
  • tendo a sensibilidade de lê-lo sob a perspectiva do leitor,
  • validando – não apenas gramaticalmente mas também a lógica representada junto com as outras pessoas envolvidas
  • e discutindo a modelagem proposta com outros analistas, avaliando até mesmo outras alternativas de transmitir mais claramente a ideia do processo.

Esse trabalho envolve alguns cuidados que o designer de processos deve observar em suas modelagens se quiser apresentar resultados claros, objetivos e precisos na representação de processos:

  • Criar modelos limpos. Diagramas de processos devem primar pela interpretação fácil com olhar simples. Isto se obtém evitando-se desenhar linhas sobre linhas, cruzar linhas sobre as outras ou traçar conexões entre elementos muito distantes. Isso pode ser resolvido com o uso de elementos de links (mas use com parcimônia!) e alguma reorganização (avalie se as lanes onde os elementos que devem se conectar não podem ser aproximadas). Usar nomes breves e objetivos para eventos, gateways e atividades também ajudam a manter o diagrama limpo.
  • Aplicar boas práticas. Existem diversas práticas, que foram sendo agregadas por profissionais com experiência na modelagem de processos e que são recomendadas no uso da notação. Confiar nessas práticas pode facilitar o trabalho e ajudar na elaboração de diagramas eficazes na comunicação.
  • Usar a notação de forma padronizada. Padronizar a forma como usa a notação dá harmonia ao conteúdo representado, gerando conforto a quem lê e confiança de que o processo está bem modelado.
  • Modelar no grau de detalhamento apropriado. De acordo com o propósito da modelagem do processo, o diagrama requer uma representação em maior ou menor nível de detalhe. Algumas situações requerem um processo desenhado numa perspectiva superficial, suficiente para dar entendimento ao negócio, enquanto outras requerem detalhamento no nível de atividade da operação, ou mais além, em que todas as exceções do processo sejam previstas e tratadas. Compreender o grau de detalhamento esperado – e mantê-lo no decorrer de todo o fluxo modelado -, é um cuidado fundamental.

Encontre uma pessoa com habilidades de compreensão gramatical e boa escrita e você terá nela um excelente profissional para modelar seus processos. Desenvolva estas habilidades e você será esta pessoa.

_____
(1) De acordo com BPM CBOK v3 em português, “Designer de Processos” é o papel realizado por um membro da equipe de modelagem de processos cujo trabalho é desenhar novos processos e transformar processos de negócio. Tipicamente possui habilidades analíticas, criativas e de descrição visual e lógica dos passos de processos e na forma de organização do trabalho. Não é uma função, mas um papel, que pode ser realizado por um profissional específico ou mesmo pelo analista de processos ou de negócios.

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.

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.

Respondendo a dúvidas: vale usar evento de erro em BPMN para tratar exceção de negócio?

Como já comentamos em diversos artigos deste blog, é possível representar uma mesma situação de negócio de formas diferentes com BPMN.

A seguinte questão foi levantada esta semana por um de nossos leitores, que acompanhou o diagrama logo abaixo:

“Qual a maneira correta de representar uma decisão binária (sim ou não)?
É correto utilizar o evento de erro na atividade para representar o ‘não’?
Para os 3 casos, as notificações acontecem caso o ‘caminho feliz’ não seja satisfeito. O que você me diz disso sobre a notação?
Tenho que utilizar 3 gateways?”

Este exemplo foi enviado pelo leitor para ilustrar a dúvida sobre eventos de erro na borda da tarefa.

No livro “BPMN Method & Style” 2a ed, Bruce SIlver fala o seguinte (pág 104):

“Um evento de Erro na borda de uma tarefa simplesmente representa o estado final de exceção da tarefa. O fluxo normal, a sequência de saída da tarefa, representa o seu término quando a tarefa é concluída com sucesso, e o fluxo de exceção, a sequência de saída através do evento de Erro, representa o término quando o resultado não é bem sucedido. Ele representa exatamente a mesma coisa que um gateway XOR (Exclusive data based) seguido do resultado da tarefa com fluxos de sucesso e exceção.”

De fato, ao analisarmos a especificação da notação (http://www.omg.org/spec/BPMN/2.0/), não há nenhuma restrição que indique que não seja correto utilizar este evento com esta conotação. Alguns profissionais preferem utilizar outro evento, o de Escallation, que possui semântica semelhante à do evento de Error, porém mais relacionada a uma percepção de falha relacionada ao negócio (e permite tratamento non-interrupting), reservando para o evento de erro as falhas relacionadas a exceções técnicas.

Em geral, nas modelagens que realizamos em nossos projetos, damos preferência pelo uso de gateways para verificar o resultado da tarefa (que pode ser mais do que simplesmente uma decisão binária de sim ou não). Deixamos o evento de erro na borda para tratar casos que representem efetivamente uma exceção. Um dos argumentos para esta escolha está no fato de que muitas vezes estes processos serão posteriormente automatizados em um BPMS, e para os motores de execução de processos é mais fácil realizar a validação de resultados da tarefa através desta composição.

Do ponto de vista estritamente relacionado ao uso da notação BPMN, todas as abordagens acima são permitidas.

A segunda parte da dúvida do leitor é “Tenho que utilizar 3 gateways?”

Bem, talvez não para este caso. Quem sabe podemos propor uma outra perspectiva? Uma análise do diagrama um pouco mais observadora nos faz pensar que talvez nesta modelagem as operações estejam sendo representadas em um nível de granularidade muito baixo. Será que podemos considerar que “Verificar se há período sem lançamento”, “Verificar se há RATs abertos” e “Analisar despesas” poderiam na verdade ser procedimentos de uma única tarefa? É como se a tarefa fosse “Analisar pendências e despesas” na qual a ferramenta do usuário fosse uma checklist com estas três questões.

Não seria melhor que todas as análises fossem realizadas e o colaborador recebesse como resultado não uma notificação relatando resultado apenas da primeira divergência identificada, mas uma única que já contivesse tudo o que ele precisa resolver para que sua requisição possa ser atendida? Com essa consolidação de procedimentos em uma única tarefa, não haveria mais a necessidade de três gateways, mas um. E ele poderia resolver mais do que o resultado “sim” e “não”. Que tal se os resultados fossem “aceito”, “aceito com restrições” (em que as divergências não bloqueiam a continuidade do processo) e “rejeitado”? Vale a reflexão :)

De qualquer forma, independente da opção, recomendamos sempre que a organização defina um estilo de modelagem com diretrizes de utilização da notação, que guiarão os modeladores a representarem os processos de uma forma padronizada.

 


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

 

Respondendo a dúvidas: como representar email, planilha ou sistema em BPMN?

Frequentemente, em cursos e consultorias, nos deparamos com questões como a abaixo, encaminhada por um de nossos leitores:

“Estou modelando processos e a determinação que recebemos é sempre usar na atividade o ícone que representa o tipo de tarefa.
Há dúvidas e opiniões diferentes em o que aplicar quando:
- E-mail escrito e enviado por uma pessoa.
- Uso de planilha Excel ou outras ferramentas que não são aplicação do negócio
- Utilização de ferramentas externas como site de banco, ou sistema cuja administração é exclusiva do fornecedor.
Como recomendam a representação desses itens?”

Na verdade não existem elementos no BPMN para representar especificamente estes itens, porque o objetivo da notação é disponibilizar componentes para a representação da sequência lógica da execução de um processo, e não os meios utilizados. Quando representamos uma tarefa em um processo, indicamos que ali acontece uma ação, um trabalho que precisa ser realizado para que o processo siga adiante no fluxo. Planilhas, software, sites, documentos e emails são meios através do qual as tarefas podem ser realizadas – mas não o trabalho em si.

A notação permite representar entradas e saídas de informações através do elemento “data object” ou “message”. Entretanto, eles são apenas elementos acessórios no diagrama e não especificam o tipo de tecnologia usada (planilha, documento, formulário, email, telefonema…). Assim, se para a análise do processo é muito relevante apontar visualmente que meios são usados em uma atividade, utilize este elemento e use sua descrição para esclarecer se é um documento, um formulário ou planilha.

Neste exemplo de processo com implantação manual, alguns exemplos de "meios" como planilhas e formulários representados junto ao processo. Tanto o formulário TR3 quanto o TR3.1 são formulários que transitam entre tarefas (sai de uma e vai para a outra), embora esteja associado implicitamente através do que chamamos "visual shortcut". A planilha de controle de estoque é consultada e eventualmente atualizada durante a tarefa "Verificar estoque". Nesta perspectiva, o email que comunica o solicitante sobre a falta de itens seria produzido na tarefa "Verificar estoque", e provavelmente documentado como um dos procedimentos a serem realizados durante esta tarefa no caso de faltarem itens.

Em relação ao envio de emails, esta é em geral uma questão bastante controversa, e a sua representação depende da perspectiva sob a qual o processo está mapeado. O fato é que é diferente mapear um processo de negócio para análise e documentação ou para execução por um BPMS.

Quando mapeamos um processo de análise e documentação, representamos o processo de negócio sob a perspectiva das pessoas que realizarão o trabalho. Em geral, o envio do email é parte do trabalho de uma tarefa, como por exemplo avaliar alguma coisa (e um dos procedimentos da tarefa é enviar um email notificando a parte interessada). Assim, o envio do email não é representado no fluxo, mas é descrito como um procedimento da atividade.

Em um processo que está sendo mapeado para ser automatizado, a perspectiva muda discretamente. Ela tem a ótica do BPMS, o motor de processos – que é quem realmente executará a atividade do envio do email. Nestes casos, não há uma atividade humana em si. O envio será realizado pelo sistema, automaticamente, e alguém receberá a mensagem (mas nem sempre fará algo com ela – muitas vezes é apenas uma notificação do estado do processo). Para estes casos, costumamos representá-la através de uma atividade de serviço, já que é um serviço de email que será acionado para enviar a informação. Esta tarefa de serviço acaba sendo posicionada na lane da pessoa que receberá a mensagem, e muitas vezes as nomeamos como uma tarefa passiva como “Receber aviso de aprovação”. Para esta situação, muitas ferramentas de automatização de processos customizaram ou estenderam a notação, criando elementos específicos para representar este tipo de atividade (o que é permitido pela especificação BPMN 2.0).

Este exemplo representa um processo mapeado sob a perspectiva da automação, em que o processo será executado e controlado através de um BPMS. O envio do email para o solicitante é enviado automaticamente pelo sistema, a exemplo da sugestão de uso da notação acima para este cenário.

Vale lembrar que as dicas acima não são exatamente definições da notação  (pois a especificação BPMN não entra neste mérito), mas algo que consideramos boas práticas para utilizá-la corretamente.

BPMN: Modelando processos de negócio com elementos avançados (Parte IV)

Neste quarto e último artigo da série “BPMN: Modelando processos de negócio com elementos avançados”, abordaremos de forma especial o subprocesso de eventos, levando em conta as definições de notação.

Subprocesso Eventual (Event-Subprocess)

O subprocesso eventual é parte opcional do processo e é utilizado para tratar com eventos excepcionais que ocorrem no processo pai.

Subprocessos eventuais são acionados pela ocorrência de um evento previsto durante a execução do processo principal. Assemelham-se a outros tipos de subprocessos contidos dentro de um processo pai (e não são reutilizáveis), mas dintinguem-se de outros subprocessos, pois não são ligados ao  fluxo de sequência do processo principal, uma vez que só serão iniciados quando a trigger do evento de início for acionada.

O Subprocesso eventual é representado graficamente por um retângulo com bordas arredondadas e linha tracejada. Na forma contraída, apresenta um símbolo [+] na base inferior implicando no entendimento que esta atividade contém um conjunto de tarefas. Também pode ser representado na forma expandida, demostrando assim seu fluxo no processo pai.

Subprocesso eventual (ou subprocesso de eventos) - Representado pela imagem da esquerda na forma contraída e na imagem a direita na forma expandida.

Um subprocesso de eventos pode ter somente um evento de início e este evento deverá ser necessariamente disparado por algum fato específico que gere seu início (catch). Em outra palavras, o subprocesso eventual não pode ser representado pelo evento de início “none”.

Este fato específico (que gera o início do subprocesso de evento) pode significar as mais diferentes informações. Vejamos as mais comuns:

  • Um fato temporal: uma data (Ex. 01 de março) – Simbolizado por um relógio.

  • Por uma mensagem: Com a chegada de uma informação (Ex. Um documento, um e-mail, um telefonema) – Simbolizado pelo envelope branco.

  • Uma condição: Ex. Estoque menor que 10 unidades – Simbolizado por formulário.

  • Um sinal: Quando algo estiver errado (Ex. Sistema do cumprimento do pedido não respondido) – Simbolizado por um triângulo vazado.

Para mais informações sobre eventos confira os artigos Um guia para iniciar estudos em BPMN (III): Eventos de Início e Fim e Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários.

Event-Subprocess Interrupting e Event-Subprocess Non-Interrupting

Falando um pouco mais sobre o evento de início de um subprocesso eventual, apontamos dois tipos que definem qual o impacto que o subprocesso causará no processo pai. São eles:

Event-Subprocess Interrupting – Evento que interrompe o fluxo do processo principal (pai). Representado por um círculo com linha contínua.

Event-Subprocess Non-Interrupting – Evento que não interrompe o fluxo do processo pai. O processo ocorre em paralelo. Representado por um círculo com linha tracejada.

O exemplo a seguir demonstra o uso de subprocessos eventuais, em um processo muito comum de “Pedido de Reservas”, envolvendo reservas de voo e hotel.

Durante a execução deste processo, podem ocorrer o disparo de qualquer um dos dois subprocessos eventuais:

1 – Pode ocorrer o cancelamento do processo de reservas, interrompendo o processo de negócio e com isso finalizando a solicitação de reservas. Veja que o evento que inicializa o subprocesso eventual de cancelamento é representado graficamente com uma borda de linha contínua (Event-Subprocess Interrupting). Isso significa que ele interromperá a execução do processo principal, e executará este subprocesso.

Event-Subprocess Interrupting

2- Caso o processo não seja cancelado, o cliente pode enviar um pedido de “Status”, retornando a informação da situação do pedido das reservas. Como o evento que inicializa este subprocesso é representado com uma borda com linha tracejada (Event-Subprocess Non-Interrupting), o processo principal não é interrompido, com isso subprocesso eventual é executado em paralelo ao processo principal, fazendo com que o pedido de status seja atendido paralelamente às atividades do processo pai.

Event-Subprocess Non-Interrupting

 

Importante:
- O subprocesso eventual non-interrupting pode ser executado várias vezes durante a execução de um processo, e pode ter várias instâncias em execução em paralelo.

- Uma vez que o processo principal tenha sido concluído, mesmo que o fato gerador do evento ocorra, o subprocesso eventual não será acionado, pois seu ciclo de vida depende do processo principal. Por exemplo, o cliente solicita o pedido de status do pedido porém o processo principal já foi finalizado, este pedido não será processado.


Confira todos os artigos deste guia de BPMN: Modelando processos de negócio com elementos avançados: