Problemas comuns na modelagem de processos em BPMN II – Uso de eventos de mensagens para comunicação dentro do processo

Continuando a série de artigos que falam de erros, problemas e inconsistências básicas de modelagem (veja artigo já publicado aqui), vamos falar hoje de outra situação bem comum, que é a utilização de eventos de mensagem para comunicação entre papéis/raias dentro de um mesmo processo.

Vamos imaginar um processo ponta a ponta de uma organização, como por exemplo um processo de compras, onde em determinado trecho temos uma comunicação entre dois papéis ou áreas diferentes que atuam neste processo, no caso uma comunicação para o solicitante da compra de que a mercadoria foi recebida. Se olharmos apenas uma definição genérica do evento do tipo message, temos que um evento deste tipo trata de “uma comunicação entre 2 participantes do processo”.

Partindo deste pressuposto inicial, alguém poderia imaginar uma modelagem como esta:

Perceba que foram utilizados dois eventos do tipo message, um de envio (throw) na raia de Compras e outro de recebimento (catch) na raia do Solicitante.

Qual o problema desta abordagem? Basta nos aprofundarmos um pouco mais na especificação oficial de BPMN (link), para encontramos o seguinte trecho na seção “10.4.1 Concepts“:

“Messages are triggers, which are generated OUTSIDE of the Pool they are published in. They typically describe B2B communication between different Processes in different Pools.”

Em tradução literal: mensagens são gatilhos gerados fora da pool onde estão publicados, descrevendo tipicamente a comunicação B2B entre diferentes processos em diferentes pools.

Assim, o evento do tipo message só deve ser usado para comunicação com participantes EXTERNOS ao processo, não devendo ser utilizado para comunicar com um participante que já faz parte (ou seja, já é uma raia) do processo.

Partindo deste novo conhecimento adquirido, como ficaria então o processo descrito acima? Para isto, precisaríamos saber um pouco mais sobre de que forma é feita a comunicação entre a área de compras e o solicitante. Supondo, por exemplo, que a comunicação fosse realizada como um email disparado automaticamente pelo sistema (ou pelo processo automatizado), poderíamos ter então este desenho:

Neste caso, em vez do par de eventos do tipo message de envio e recebimento, teríamos apenas uma service task indicando o envio de email de forma automática. Perceba que o recebimento de email pelo solicitante não é uma atividade que envolva trabalho (consumo de recurso) de fato. Assim, receber um email é uma situação passiva e consequência direta do envio do email, portanto não é necessário uma tarefa para receber o email na raia do solicitante.

Problemas comuns na modelagem de processos em BPMN – I – Atividades de transferência do processo

Vamos iniciar hoje uma série de artigos que pretendemos publicar ao longo dos próximos meses, falando especificamente de erros, problemas e inconsistências básicas de modelagem, comuns de ocorrer quando começamos a modelar processos e ainda não conhecemos muito bem a notação BPMN.

Pra começar, vamos falar de uma questão muito frequente, que se refere ao encaminhamento de um papel do processo para outro. Vamos imaginar um processo de Viagens, que foi descrito pela área de negócio da seguinte forma:

  1. Um colaborador solicita a viagem
  2. Solicitação de viagem é encaminhada (atenção especial ao uso desta palavra) para uma área interna chamada “Administrativo”, que tem a responsabilidade de pesquisar e mandar cotações da viagem para o solicitante
  3. Cotações são então encaminhadas de volta para o Solicitante avaliar
  4. Se a cotação for aprovada, processo é direcionado novamente para setor Administrativo comprar os tickets, do contrário processo é direcionado de volta para o setor Administrativo refazer as cotações

Agora veja como o modelador decidiu, inicialmente, representar este processo:

Note que no caso da primeira transferência do processo, do papel “Solicitante” para o papel “Administrativo”, foram criadas 2 atividades:

  • Uma atividade na raia do “Solicitante”, chamada “Encaminhar Viagem para Cotação para Administrativo”
  • Uma atividade na raia do “Administrativo”, chamada “Receber Viagem para Cotação do Solicitante”

O mesmo comportamento foi modelado posteriormente, na transferência do papel “Administrativo” para o papel “Solicitante”, com as atividades “Encaminhar Cotações para Solicitante” e “Receber Cotações do Administrativo”, respectivamente.

Este trecho do processo não está errado do ponto de vista da notação BPMN. Mas o que temos aqui, no entanto, são atividades que na prática não precisariam existir. O modelador optou por explicitar a passagem de bastão de um papel a outro através de atividades de transferência do processo, mas isso não é necessário: em BPMN, o próprio fluxo de sequencia já tem o papel de representar/realizar esta transferência de responsabilidade dentro do processo. Neste caso, como ficaria o desenho do processo ajustado? Veja a seguir:
Perceba que com esta mudança, deixamos o processo mais simples e limpo, ao mesmo tempo mantemos o comportamento esperado.

O conceito de utilizar apenas fluxos de sequência para representar a transferência de atividades dentro do processo costuma se aplicar mesmo que exista, de fato, um encaminhamento físico sendo realizado. Por exemplo, este processo de viagens poderia ser realizado em papel, implicando que o solicitante tivesse que levar fisicamente a solicitação impressa e assinada para o setor Administrativo. Mas mesmo neste caso não seria necessário modelar as atividades de transferência. Caso fosse necessário ressaltar este aspecto de encaminhamento físico de algo, poderiam ser utilizados outros recursos para representar, como adicionar uma anotação ao processo ou documentar esta característica do processo nos procedimentos das atividades.

Um cenário em que poderia ser necessária uma atividade para encaminhar ou receber o processo seria num caso em que as atividades são reconhecidamente manuais, realizadas no plano físico, e que possuem procedimentos adicionais, como protocolar a chamada do documento esperado, carimbar, etc. Por exemplo, num processo logístico poderíamos ter uma atividade da área de “Recebimento” chamada “Enviar material para Estoque”, onde “Estoque” é uma área da organização:

Note que, em linhas gerais, continuamos falando do mesmo exemplo citado no Processo de Viagens: a passagem de bastão de uma área para outra. Se o ato de encaminhamento físico do material de um lugar para outro envolve procedimentos adicionais e tem um tempo de execução relevante (vamos imaginar neste caso uma grande planta industrial, em que seria necessário percorrer a distância entre um setor para outro), ou seja, a atividade consome efetivamente recursos, então neste caso faria mais sentido criar uma atividade de transferência.

Fique ligado para outros artigos desta série no futuro! ;-)

Em que nível devo modelar meu processo?

Uma das principais atividades na transformação de um processo é a sua modelagem. Seja no princípio do projeto, para representar a sua situação atual (AS IS), a criação de modelos para simulação ou comparação de variações, a definição da sua visão de futuro (TO BE) ou o fluxo a ser implementado para automação, a modelagem é importante na representação do processo que está sendo detalhado ou melhorado.

A representação visual do modelo utilizando uma notação gráfica como BPMN é um dos seus aspectos chave da modelagem. O nível de detalhe das atividades no diagrama de processos, entretanto, é frequentemente tema de debate entre os profissionais de Processos.

A notação BPMN, apesar de poderosa e de ter uma gramática bem definida quanto ao uso dos seus elementos, não estabelece qual seria o nível ideal de modelagem do processo. Ela define formalmente que “uma atividade representa um trabalho”. Mas devemos ir por uma abordagem mais alto nível do significado de trabalho (o “trabalho” é aquilo feito por uma área inteira?) ou mais baixo nível (o “trabalho” é cada ação realizada por alguém para atender ao resultado objetivo do processo?).

Não há uma regra para isso, e na verdade cada tipo de modelo pode requerer um nível de detalhe diferente no mapeamento do processo, de acordo com o propósito para que serve aquele modelo.

Por exemplo, em uma reunião no qual estamos buscando um entendimento amplo sobre o processo, com uma visão ponta a ponta em que possamos identificar suas principais etapas, um nível alto seria o mais apropriado.
Mas e quando vamos mapear um processo que será usado como material de treinamento, num manual de processos ou para descrever o trabalho de uma determinada etapa?

Existem alguns critérios que podem ser interessantes de serem questionados pela equipe ao definir o nível de modelagem do processo que estamos criando.

Como oportunidade de reflexão, um de nossos leitores contribuiu recentemente com dois exemplos de processos. Vamos tomar por base então o seguinte exemplo:

1) Nesse fluxo, podemos perceber que o mapeamento está em nível de procedimento, não de trabalho. O trabalho seria, por exemplo, “Avaliar baixa”, que envolve esta sequência de procedimentos: Consultar arrecadações, selecionar arrecadação, …, até confirmar baixa manual. Embora exista uma sequência entre eles, pode ser uma sequência flexível, em que a ordem dos itens pode eventualmente mudar na operação da pessoa no sistema. Esse nível de detalhe é bem comum de ver em processos modelados por profissionais de TI. Cuidado para não confundir o fluxo de trabalho com o fluxo de interação com sistema. Para esse segundo, devemos utilizar UML (Diagrama de sequência ou diagrama de atividades ou até mesmo passos de um Caso de Uso).

2) Pensando no por quê modelamos processos no nível de operação, geralmente fazemos isso para entender o processo e ter um parâmetro para avaliar o seu desempenho, certo? Assim, normalmente as tarefas são utilizadas para determinar o trabalho do processo, onde podemos medir o tempo e custo da sua realização. Neste sentido, será que realmente interessaria para a organização mensurar detalhadamente quanto tempo leva para executar cada um desses passos? Ou é mais importante entender quanto tempo, dentro da dinâmica do processo, um profissional leva para realizar a análise e a baixa, de uma forma consolidada?

3) Geralmente quando mapeamos nesse baixo nível, fica mais difícil representar as exceções. Por exemplo, no caso em que qualquer um desses passos seja possível o ator voltar atrás em alguma ação. Nesse fluxo, teríamos que desenhar também todas as possibilidades de voltar e refazer algum passo. Ou seja, após ele selecionar o ingresso, ele terá que selecionar uma parcela. Mas se ao selecionar a parcela ele se der conta que escolheu o lançamento errado, ele poderia voltar pra selecionar outro lançamento?

4) Um outro fator a considerar é a manutenibilidade do processo. Queremos dizer com isso que qualquer mínima alteração nas ferramentas podem fazer com que você tenha que criar uma nova versão do seu diagrama de processo, tornando a manutenibilidade da documentação mais custosa e também dando mais chance para ela se tornar rapidamente obsoleta.
Se você tem uma tarefa “Avaliar baixa” e nela descreve os procedimentos, e a sua organização mudar do sistema XPTO para o sistema MEGAXPTO, o trabalho feito pela organização continuará sendo o mesmo, que é avaliar a baixa. O processo não mudou, o que mudou foi a ferramenta. Assim, no nível de mapeamento do trabalho, a manutenção fica mais fácil porque não precisará mudar o fluxo, apenas atualizar o procedimento (passos realizados naquela atividade, que podem ser descritivos complementares ao desenho do fluxo).

Se o plano for automatizar o processo, esses critérios podem ser ainda mais relevantes, porque o motor de processos é muito literal na interpretação do modelo. Confira uma outra reflexão semelhante que já fizemos sobre o assunto aqui no Blog da iProcess no artigo: Estudo de Caso: Automatizar o processo (ou não)? Eis a questão!

 

Como representar exceções no fluxo do processo em BPMN?

Com alguns anos de experiência participando de projetos e treinamentos envolvendo processos de negócio, percebemos situações recorrentes quanto à aplicação de exceções na lógica do fluxo do processo de negócio que está sendo desenhado e documentado. A boa modelagem de processos de negócio em BPMN é o resultado do domínio da notação (estudo e compreensão dos elementos), mas para uma modelagem que represente corretamente uma situação de negócio, não basta saber aplicar as regras da notação BPMN, conhecer seus símbolos e o que cada um significa. É preciso também entender os detalhes da lógica do processo de negócio em questão.

Vou aproveitar o tema para repassar as regras da notação BPMN relacionadas à representação de exceções durante a execução de atividades, apresentar algumas ilustrações, de forma a esclarecer algumas dúvidas e confusões comuns quanto à representação da lógica do negócio.  

Como já tratado em outros artigos, atividades retratam o comportamento ou trabalho realizado em um contexto do processo, gerando uma transformação (resultado) ao final deste trabalho. Atividades que podem gerar mais de um resultado normalmente são testadas, pois levam o fluxo por caminhos diferentes (alternativos ou paralelos). Para contextualizar, usarei como exemplo um processo fictício de liberação de crédito, representado abaixo. 

No exemplo, o Processo de Liberação de Crédito realiza dois trabalhos para identificar se o crédito pode ou não ser aprovado. O Processo consiste em analisar se comprador possui restrições de crédito e limite para liberação de crédito.

O processo possui duas tarefas que analisam se o solicitante pode receber o crédito solicitado. A primeira tarefa Consultar situação de crédito (Tarefa de Usuário) analisa se solicitante está em situação de inadimplência ou sem débitos. Caso a tarefa resulte por situação de crédito por inadimplência, o processo é automaticamente finalizado por solicitação reprovada. Se não houver débito(s) o processo segue para verificação do limite. A segunda tarefa Verificar limite de crédito (Tarefa de Serviço) analisa se o solicitante possui limite para liberação de crédito solicitado. Caso o limite de crédito esteja dentro do limite solicitado, o processo é finalizado por solicitação aprovada. Se o limite de crédito estiver abaixo do solicitado, o processo é automaticamente finalizado por solicitação reprovada.

Mapeando exceções nas atividades do fluxo do processo

Descrevi acima um fluxo típico de processo de liberação de crédito, onde a situação de negócio está bem explícita em cada uma de suas tarefas, tanto no que consiste o trabalho realizado, quanto suas saídas (possíveis resultados). Porém algumas situações fora do comum, que não se espera que aconteçam (mas que podem acontecer) foram ignoradas. Estas situações são conhecidas também por exceções. Vejamos algumas situações que deverão ser representadas no fluxo do processo de liberação de crédito.

Situação 1

A tarefa Consultar situação de crédito deve conter um prazo para execução e, caso o prazo seja excedido, uma notificação deverá ser disparada para o responsável.

Situação 2

Caso uma informação de referência da tarefa Consultar situação de crédito estiver incorreta (ex. cpf inválido) e não for possível finalizar a tarefa, deverá ser realizado um tratamento para correção da informação.

Situação 3

Caso o serviço utilizado na tarefa Verificar limite de crédito estiver indisponível ou apresentar erro na sua execução impossibilitando a finalização da tarefa, uma notificação deverá ser disparada para o responsável, finalizando o processo por indisponibilidade no sistema.

Imagine que em nível de negócio todas estas situações devem ser previstas e representadas no fluxo do processo. Como representar estas situações? Qual seria a forma mais adequada de representá-las, levando em conta a lógica do processo e as regras da especificação BPMN 2.0?

Começaremos avaliando, neste artigo, apenas a Situação 1.

Antes de apresentar a solução, mostraremos uma confusão na hora de desenhar esta situação. Um erro bastante comum que presenciamos ao corrigir os exercícios dos alunos nos nossos cursos e por vezes também identificado em processos de melhoria, é a forma como é aplicado o controle de prazos nas tarefas, que geralmente é representado com um evento intermediário diretamente no fluxo do processo, posicionado logo após a tarefa que deveria ser controlada (já vimos casos que o prazo também havia sido posicionado antes da tarefa).

Aqui começa a primeira confusão: o evento que controla o prazo deve ser representado como uma exceção à saída da tarefa. Veremos mais abaixo, nas regras de especificação da notação, que este tipo de situação deve ser representado por um evento anexado a borda da tarefa a ser controlada, e não diretamente no fluxo do processo. Neste caso o evento de tempo deve ser acionado somente se a tarefa não tiver sido executada dentro do prazo e nunca obrigar, como modelado no exemplo abaixo, que o fluxo aguarde sempre por um período de tempo, desta forma paralisando o fluxo. Outro erro, também demonstrado na imagem abaixo, está no gateway que testa a situação de crédito. Veja que foi incluída uma nova saída Em atraso que deverá ser acionada caso a tarefa seja executada após o prazo. Da forma como o fluxo acima foi modelado, a tarefa Consultar situação de crédito não possui, de fato, um controle de tempo. Ela deve ser necessariamente executada para que o fluxo prossiga. Após a conclusão da tarefa é apresentado um controle de tempo contido diretamente no fluxo do processo, que obriga ao processo uma parada no fluxo, por dois (2) dias.

Vejam que o processo acima é válido do ponto de vista da notação BPM. Porém ele não representa corretamente a situação do negócio proposto na situação 1, pois não deveria obrigar a parada do fluxo, e sim controlar o tempo da tarefa Consultar situação de crédito.

Solução proposta para Situação 1:

  1. A tarefa deverá possuir uma condição de tempo associada à sua execução.
  2. A tarefa, mesmo em atraso, poderá ser executada (não deverá ser cancelada).
  3. A tarefa, caindo em atraso, deverá executar um fluxo de exceção para disparo de uma notificação de atraso para o responsável.

Regras da especificação BPMN 2.0:

  • Segundo a especificação oficial da notação BPMN 2.0, quando uma atividade possui prazo para execução, deve ser representado através do elemento Evento Intermediário do tipo Tempo (Timer), conectado à borda da atividade.
  • No momento que a atividade for iniciada, o evento será monitorado e controlado seu tempo.
  • Se o evento for disparado, o fluxo mapeado a partir do evento é executado.
  • A interrupção da tarefa é representada através do desenho da borda do evento. Neste caso, deve conter a borda tracejada, que demonstra que a tarefa, mesmo em atraso, poderá ser executada. A borda contínua representa que, ao ser disparado o evento de tempo, a tarefa seria cancelada.

Levando em conta a lógica desejada para o processo e as regras da especificação BPMN, apresentamos abaixo a solução mais adequada para a situação 1:  O controle do prazo para execução da tarefa está representado corretamente pela exceção – neste caso o evento intermediário de tempo anexado a borda da tarefa. Como já dito, assim que a tarefa é iniciada, o evento passa a controlar seu tempo e caso a tarefa não seja executada e finalizada em até dois (2) dias, o evento de tempo é disparado e o fluxo segue para o próximo ponto onde dispara uma notificação de atraso ao responsável.

Continuaremos em um próximo artigo o assunto, falando a respeito da segunda e terceira situações, bem como as confusões mais comuns na hora de desenhá-las. Fique ligado!

 

 

Webinar – Do Modelo TO BE para a Automação – o que é preciso repensar sobre o processo

Neste webinar, apresentado por Kelly Sganderla em 25/08/16, compartilhamos nosso expertise e experiência sobre a importância de realizar um redesenho tecnológico do TO BE, considerando aspectos importantes sobre a visão de processo e visão sistêmica da Solução.

Aos que participaram da transmissão ao vivo, um muito obrigado em nome do time da iProcess!

Os slides utilizados na apresentação também estão disponíveis no SlideShare:
http://www.slideshare.net/iProcessBPMeSOA/webinar-iprocess-do-modelo-to-be-para-a-automao-um-repensar-sobre-o-processo

Confira abaixo as respostas para perguntas enviadas por nossos participantes durante o evento:

Pergunta: Para automatizar processos e adotarmos um BPMS, temos uma etapa que é a escolha da ferramenta BPMS. Devemos ter ações paralelas para definir junto ao cliente qual BPMS a ser adotado, caso o cliente não tenha definido qual a ferramenta a utilizar? Que dificuldades afetam o projeto (redesenho e automação) na escolha da ferramenta?
Certamente uma etapa importante na automatização de processos é a escolha de uma da suíte de BPM (BPMS). Dificilmente, porém, a organização irá adquirir um BPMS para automatizar um processo específico, pois este tipo de ferramenta é uma plataforma para automação e controle dos processos da organização. A escolha da plataforma para a gestão de processos é uma decisão corporativa. Cada solução disponível no mercado tem seus pontos fortes e fracos, e seus recursos precisam ser avaliados em relação às necessidades da organização, como sua estrutura, cultura organizacional e planos atuais e futuros para os processos da empresa. A escolha da ferramenta pode impactar diretamente no projeto de automação, pois de acordo com os recursos e funcionalidades disponiveis no produto, o redesenho tecnológico do processo pode mudar.
A iProcess Education lançou recentemente um Kit de Avaliação de plataformas de BPM com vídeo aulas e planilhas de templates para comparação e avaliação de aderência de produtos a centenas de requisitos que precisam ser considerados nesta avaliação, entre as quais os recursos que o produto disponibiliza para o desenvolvimento da automatização do processo.
Para saber mais, visite a página: www.iprocesseducation.com.br/avaliacao_plataformas_BPM

 

Pergunta: Trabalhar o TO-BE significa custo, para empresa como o todo, ainda mais como o TO-Be tecnologico que aparentemente gera mais custo. Tem algum valor de beneficio entre o TO-BE e o TO-BE tecnologico?
A melhoria de processos não deve ser vista como um custo, mas como um investimento. Assim, não devemos avaliar o valor e os benefícios do redesenho de processos pelo custo deste trabalho, e sim pelo seu potencial de retorno do investimento. O redesenho tecnológico possibilita criar uma nova visão de futuro (TO BE) que ao ser comparada com a situação atual nos apresentará que ganhos teremos no processo em termos de redução de custos da sua execução, redução da duração do processo e melhoria na qualidade e produtividade. Isto é fundamental para o cálculo do ROI do projeto – um tema que trabalhamos muito fortemente nos nossos treinamentos do Ciclo BPM.

 

Pergunta: Se a TI não conhece a ferramenta a empresa auxilia neste trabalho a 4 mãos?
Se a equipe que fará o desenvolvimento para a automação do processo não conhece a ferramenta, há um risco bastante elevado de definições sobre o processo não serem viáveis de automação com o produto escolhido, ocasionando necessidades de mudança do processo e do escopo de trabalho durante o projeto – o que no final das contas poderá aumentar o seu custo de implementação. Neste caso, o ideal é contar com um apoio do fabricante ou de consultoria especializada que conheça bem o produto, para realizar este redesenho tecnológico do TO BE.

 

Pergunta: Eu gostaria de rever os slides que falam sobre analista de negócio e de TI agora do final da apresentação.
Os slides utilizados na apresentação estão disponíveis no link do slideshare acima e você também pode rever esta parte da apresentação no vídeo gravado!

Desmistificando o uso de eventos em BPMN

A boa modelagem de processos de negócio em BPMN é resultado do domínio da notação, fruto de estudo e compreensão dos elementos. Esse aprendizado se faz de diversas formas, principalmente através da aplicação prática e também com exemplos (bons e ruins). Coletamos algumas dúvidas comuns de iniciantes na notação BPMN, participantes dos nossos cursos e leitores do blog da iProcess, sobre a aplicação dos eventos, cujas respostas compartilhamos aqui.

1) É típico das ferramentas de modelagem de processos representarem elementos BPMN por cores, estas cores muitas vezes variam de ferramenta para ferramenta. Oficialmente que cor possui cada evento (Início, intermediário e fim)?

Ferramentas de modelagem como Bizagi, por exemplo, costumam diferenciar os elementos BPMN por cores

Os elementos BPMN não são representados por cores, mesmo que muitas vezes ferramentas de modelagem representem estes e outros elementos com cores, a especificação não define uma cor para o elemento, pelo contrário, representa na forma preto e branco.

Na grande maioria, estas ferramentas de modelagem possuem em suas configurações a opção para apresentar o desenho do processo em preto e branco.

O objeto evento é representado graficamente, na sua especificação, por um círculo. Eventos que marcam o início do processo são representados por uma borda de linha simples, já eventos intermediários são representados por duas linhas circulares concêntricas e eventos de fim são representados por uma linha simples com uma borda mais espessa.

A notação deixa o uso de cores livre e  podem ser usados tanto para identificar visualmente os tipos de elementos quanto com outros propósitos, como por exemplo: sinalizar com uma cor os elementos que estão mudando de uma versão para outra em uma revisão do processo, ou destacar eventos críticos para o processo.

2) O uso do evento de início e evento de fim são obrigatórios?

Obrigatoriedade do evento de início e evento de fim

Não são obrigatórios, porém seu uso é altamente recomendado por se tratar de uma boa prática, pois com estes elementos definimos e identificamos visualmente o ponto inicial e final do processo.

Regra: se um evento de início é definido, obrigatoriamente, um evento de fim também deve ser (e vice-versa).

3) Se o evento de início e evento de fim não são obrigatórios, como como identificamos o início e fim do processo quando estes eventos não estão definidos?

Neste exemplo, a tarefa "Escolher produtos" é o primeiro elemento do fluxo, portanto o processo inicia-se por ele. O fluxo segue até a tarefa "Realizar entrega da mercadoria", que por não apresentar um fluxo definido após sua ocorrência, é considerada o ponto final do processo.

Quando o processo segue um fluxo definido pelo fluxo de sequência (sequence flow), identificamos o início (ponto de partida) e fim do processo (ponto final) pelo primeiro e último elemento do fluxo.

4) Caso seja necessário, posso voltar ao início do processo ligando o fluxo de sequência ao evento de Início?

Emprego indevido da notação BPMN! A saída do gateway está retornando ao evento de início.

De forma alguma! A especificação deixa claro que o evento de início não pode ter nenhum fluxo de sequência apontando para ele. Além disto, o evento de início só pode ser executado/inicializado uma única vez para cada instância de processo.

No exemplo, o fluxo retornou de forma correta a tarefa "Solicitar Férias".

Se realmente for necessário que o processo volte ao seu início, o fluxo de sequência deverá ser ligado ao elemento que vem logo após o evento de início.

5) É obrigatório o uso de rótulo (nomenclatura) nos eventos? Como devo utilizar?

Exemplo de rótulo nos eventos do processo, seu uso é altamente indicado para compreensão correta do processo.

Não é obrigatório, porém o uso é considerado uma boa prática pois impacta diretamente na clareza e compreensão do processo. O rótulo deve apontar o motivo daquele processo ocorrer (evento de início), motivo para dar andamento (evento intermediário) ou motivo de chegar ao fim (evento de fim).

6) Um processo que conter mais de um evento de início é considerado sintaticamente incorreto (emprego indevido da notação)?

Pela especificação não! Porém a própria especificação deixa claro que a compreensão do processo pode ser prejudicada se houver vários eventos de início e que o modelador deve estar ciente que os leitores do processo podem ter dificuldades na interpretação do diagrama, por isto recomenda-se usar este recurso com moderação.

A boa prática nos indica o uso de tipos de eventos que abstraem a ocorrência de mais de um evento em um único objeto. É o caso do Evento Múltiplo e o Evento Paralelo.

Processo utilizando evento de início múltiplo.

No exemplo acima, o processo pode iniciar com uma ligação do 0800 ou por envio de SMS ou ainda por um e-mail. Basta que um destes gatilhos seja disparado para que o processo inicie. Importante destacar que o gatilho acionado cancela os demais.

Diferente do evento de início múltiplo, o evento de início paralelo requer que todos os tipos de eventos, abstraídos no objeto, sejam realizados para que o processo inicie.

Processo utilizando evento de início paralelo.

Para que o processo acima inicie, contendo o evento de início paralelo, deverá ser aprovado o investimento e confirmado o orçamento pelo financeiro. Necessariamente todas as condições devem ocorrer para que o processo inicie. Este é mais um motivo para abstrair diversos eventos em um único objeto (possibilidade de aplicar condições para o processo iniciar).

Existe ainda uma terceira forma de modelarmos o cenário de múltiplos eventos de início. É utilizando o Gateway de Início Baseado em Evento Exclusivo, outra indicação de boa prática para substituirmos pelos diversos eventos iniciais.

Processo utilizando gateway de início baseado em evento exclusivo.

O gateway de início baseado em evento exclusivo depende do resultado dos eventos imediatamente posteriores a ele. O primeiro evento que for disparado cancela os demais.

7 ) Vários eventos de fim (sempre que necessário) é considerado uma boa prática de modelagem?

Eventos de fim para cada estado em que o processo pode encerrar.

Sem dúvida, sim! Utilizar eventos de fim dá maior visibilidade e clareza das situações em que o processo pode terminar.

Em alguns casos, deixam de ser apenas boas práticas e se tornam vitais para o perfeito funcionamento do fluxo. É o caso do exemplo abaixo, em que as saídas do subprocesso de aprovação de compras são replicadas no processo de compras para informar o caminho que o fluxo deverá seguir.

O gateway que vem logo a seguir do subprocesso de aprovação de compras replica exatamente as mesmas saídas apresentadas dentro do subprocesso.

Você se interessou pelo assunto?

Este tema é explorado com mais profundidade em nosso curso “Dominando o Mapeamento de Processos utilizando BPMN2.0 Prático e Avançado“ oferecido pela iProcess Education, onde abordamos de forma mais abrangente o tema.

 

 

DMN: uma notação para modelagem de decisões de negócios

Nos treinamentos sobre BPMN (Business Process Model and Notation) que temos ministrado na iProcess Education ensinamos que, diferentemente dos losangos utilizados nos fluxogramas, os gateways da BPMN não contêm em si mesmos a semântica de uma decisão. Eles servem, comparativamente, para desviar o fluxo dos processos de acordo com condições previamente estabelecidas ou identificadas, isto é, possuem a semântica de um desvio condicional no fluxo dos processos com base em uma decisão de negócio tomada anteriormente.

Decisões: fundamentais nos processos de negócios

Quando se trata de tarefas humanas (tarefas manuais ou tarefas de usuário) há a compreensão imediata de que uma ação ou decisão realizada por uma pessoa (através da conclusão de uma tarefa, do clique em um botão de um formulário eletrônico, etc) determinará o caminho a ser seguido pelo processo. Porém, quando nos referimos a tarefas automáticas, e em especial a tarefas de regras de negócio, essa compreensão não é tão óbvia.

BPMN disponibiliza uma atividade do tipo regra de negócio (Business Rule Task) para representar a comunicação de um processo automatizado com um motor de regras de negócios ou um BRMS (Business Rules Management System). Falando desta forma, pode-se ter a ideia de que a formalização de regras de negócio em um  BRMS é algo trivial ou de menor importância, que basta preencher um formulário ou cadastro de regras quando, na verdade, se trata de um aspecto essencial para os negócios.

Decisões de negócio: manuais ou automáticas?

As regras de negócio carregam as decisões do negócio, que são tomadas de acordo com modelos mentais e estratégias organizacionais e implementam uma lógica de negócios que orientam essas decisões. Por isso regras de negócio declaradas clara e corretamente, bem conectadas à lógica e à estratégia dos negócios e sendo compreensíveis por todos os interessados é de extrema relevância para o sucesso das organizações.

Durante muito tempo a definição das regras de negócio e sua lógica de decisão permaneceu sem o suporte de uma notação para modelagem que permitisse sua padronização, sua formalização e o gerenciamento dos modelos de decisão das organizações.

Modelo e Notação de Decisões – DMN

Devido ao crescimento das discussões sobre a necessidade das organizações dominarem a gestão de decisões de negócio, a Object Management Group (OMG) criou uma subcomissão com o objetivo de desenvolver esse campo de estudo e dessa iniciativa surgiu a especificação DMN (Decision Model and Notation). A especificação tem por objetivo fornecer uma notação para decisões compreensível para todos os públicos, incluindo o pessoal de negócios e técnicos, e é composta de cinco componentes principais:

  • uma notação no nível dos requisitos, que permite aos analistas de negócio identificarem requisitos iniciais de decisão;
  • uma notação no nível da lógica das decisões, que permite detalhar como as decisões serão tomadas;
  • uma linguagem de expressões chamada FEEL (Friendly Enough Expression Language – Linguagem de Expressões Suficientemente Amigável), que permite a expressão das diferentes lógicas de decisão de negócios;
  • níveis específicos de conformidade, que permitem a validação automática de modelos de decisão; e
  • um metamodelo de suporte, que permite a automatização de modelos de decisão e o intercâmbio desses modelos entre diferentes sistemas.

Um aspecto digno de nota sobre a DMN é que esta nova notação se conecta naturalmente aos modelos de processos de negócio, permitindo que sejam desenhados processos de negócio conscientes de decisão, ou seja, processos em que é feita a distinção entre as tarefas que executam o trabalho e aquelas que chegam a conclusões baseadas na lógica. Na figura abaixo, baseada do exemplo da própria especificação da DMN, a imagem da esquerda representa um diagrama de processo (modelado na notação BPMN) enquanto que na direita há diagramas de um modelo DMN relacionado.

Imagem com a relação entre diagramas DMN com diagramas BPMN

Relação entre DMN e BPMN

Ainda não há muitas ferramentas de DMN disponíveis (O diagrama e tabela da imagem foram criados usando um editor de textos), mas o artigo de Larry Goldberg e Barbara von Halle publicado no site ModernAnalyst.com aponta a participação de de importantes fabricantes de software na força tarefa para definição da notação. São citadas as empresas como IBM, Oracle e TIBCO, entre outras, e sua participação nesta iniciativa indica, segundo os autores do artigo, sua intenção em produzir software relacionado à DMN.

A notação DMN é um assunto que fará parte de nossas discussões nos próximos artigos, onde pretendemos apresentá-la em detalhes, e gostaríamos de convidá-lo a participar, desde já, dessas discussões através de seus comentários. A organização da qual você faz parte já utiliza modelos de decisão? Que notação é utilizada para representar esses modelos?

Webinares iProcess 2014 – Introdução à notação BPMN

Aos que participaram do nosso webinar ao vivo, um muito obrigado em nome do time da iProcess!

Aos que não puderam participar, esta é a oportunidade para conferir a gravação de nosso webinar de introdução a BPMN, apresentado pela Kelly Sganderla em 28/8/2014.

 

A apresentação também está disponível no slideshare:
http://pt.slideshare.net/iProcessBPMeSOA/webinares-iprocess-2014-introduo-a-notao-bpmn

Inscrições encerradas (evento finalizado).

PERGUNTAS & RESPOSTAS DO WEBINAR DE INTRODUÇÃO A BPMN

Confira abaixo as respostas para perguntas enviadas por nossos participantes durante o evento:

Pergunta: “Tenho dúvida quanto a utilizar os gatilhos de eventos no fluxo, conforme representado no exemplo, ou utilizá-los na borda das atividades. Os dois estão corretos?”
Resposta: Os dois tipos de eventos intermediários que você citou estão corretos, mas eles têm propósitos de uso diferentes. No artigo Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários do nosso blog, falamos desses dois tipos de evento intermediário inclusive ilustrados com exemplos explicando o uso de cada um.

Pergunta: “Esses eventos de mensagem, como o caso do “Aviso de multa e novo prazo” é um simples envio de e-mail ou tem alguma interação direta com usuário?”
Resposta: O meio de comunicação usado para enviar a mensagem não é definido por BPMN. Pode ser um e-mail, mas pode ser também um SMS, pode ser um telefonema, um telegrama… a forma como essa comunicação acontece não é representado em BPMN. O que muitas vezes causa esta confusão é o símbolo do envelope, não é? Mas não implica em mensagem escrita nem em e-mail.
O que esse evento quer dizer é simplesmente que neste ponto do processo é realizada esta comunicação.

Pergunta: “O Repositório de dados pode ser a base de dados de um sistema que não seja de um BPMS?” 
Resposta: Pode ser sim. Pode ser também um arquivo, desses de metal com pastas. Não precisa ser necessariamente uma base de dados de sistema. Pode ser uma fonte de informações de qualquer forma física.

Pergunta: Posso usar os eventos de mensagem sem necessariamente ter que trocar mensagem com outras pools?
Resposta: Nós respondemos esta no webinar, mas só para ficar registrado: sim, os eventos de mensagem podem ser usados sem necessariamente demonstrar a outra pool para a qual a mensagem é enviada (ou de onde é recebida). Para BPMN isso não é obrigatório.

Pergunta: “Necessariamente o BPMN utiiliza raias para criação dos processos?”
Resposta: Não, o uso das raias não é obrigatório. A notação dá o poder de escolha a quem modela. Em geral, elas são adotadas como uma boa prática pois ajudam a identificar responsabilidades pela realização das atividades, mas um diagrama pode ser criado sem usar pools e lanes, e ainda assim será considerado um modelo válido.

Pergunta: “Já ouvi várias dúvidas quanto a um gateway seguido de outro gateway. Alguns dizem que tem que ter uma atividade entra cada gateway.”
Resposta: Um gateway seguido de outro gateway é um cenário que costumamos chamar informalmente de “gateways encadeados”. Em geral não é uma boa prática pois dificulta a leitura do diagrama. Mas em alguns casos, se você precisa verificar coisas diferentes, não tem problema nenhum.
Mas na notação BPMN não existe nenhuma regra explícita para isso.
Sobre ter atividades entre eles, também é um mito. O que acontece é que, quando o processo for executado e chegar ao gateway, para se decidir qual rota vai ser seguida, essa definição é feita com base em uma informação, então essa informação precisa existir anteriormente no processo. Mas não precisa ser necessariamente uma atividade imediatamente anterior ao gateway.
Alguns artigos do nosso blog que podem ser interessantes para ajudar a esclarecer dúvidas sobre gateways:
- Um guia para iniciar estudos em BPMN (II): Gateways
- BPMN: Modelando processos de negócio com elementos avançados (Parte III)
- Desmistificando o uso de gateways em BPMN.

Pergunta:  ”As raias sempre devem representar atores do processo, ou podem representar instâncias, como financeiro, expedição, etc?”
Resposta: A especificação não define como as raias devem ser nomeadas. Pela prática, o cenário que você citou é possível sim, mas deixa a responsabilidade sobre as atividades muito “aberta”. Dependendo do nível de detalhamento que você está dando ao processo, pode ser suficiente, em outros casos, pode ser necessário definir papéis mais específicos.

Pergunta: “Sempre que utilizado um gateway divergente, ao utilizar um convergente DEVE-SE utilizar o mesmo ou vai segundo a necessidade da sequência processo? Existe uma “regra” para esta ocasião?”
Resposta: Respondemos esta dúvida durante o webinar, mas para deixar registrado: em geral é uma boa prática usar o mesmo tipo de gateway para controlar o fluxo, mas não há uma regra específica para isso. Dependendo da necessidade de sequência do processo pode ser usada uma combinação diferente.

Pergunta: Qual a relação do BPMN com o CBOK?
Resposta: BPMN é apenas uma das notações existentes para se representar processos de negócio.
O BPM CBOK é um corpo comum de conhecimento sobre gestão de negócios, que aborda diversos aspectos desta  prática de gestão, como as atividades envolvidas no ciclo de melhoria contínua de processos, a governança de processos, tecnologia para suportar a gestão por processos entre outros aspectos. Na seção desta obra que fala sobre a modelagem de processos, as notações são citadas, entre elas o BPMN.
Esta é a relação entre eles :)

Pergunta: “Tenho algumas duvidas na utilização do evento intermediário, você poderia dar uma ênfase nele?”
Resposta: Infelizmente o tempo do webinar não nos permitiu falar muito profundamente sobre diversos elementos, já que o propósito era mesmo a introdução à notação. No blog temos alguns artigos que podem ajudar a esclarecer algumas de suas dúvidas sobre eventos intermediários, como os artigos Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários e BPMN: Diferenças entre eventos de Link, Message e Signal.

Pergunta: “No gateway paralelo só posso ter 2 atividades/processos e não 3 como o exclusivo?”
Resposta: Respondemos esta dúvida durante o webinar, mas para deixar registrado: a notação BPMN permite criar tantos fluxos paralelos ou alternativos saindo de um gateway quantos sejam necessários – não há limitação.

Pergunta: “Objetos de dados na versão 2.0 são executáveis ou são como os elementos de artefatos?”
Resposta:  A princípio eles são como os elementos de artefatos, mas pode haver alguma solução de automação de processos que aproveite este elemento para torná-los executáveis. Até o momento, entretanto, das ferramentas que já avaliei, não vi nenhuma que implementasse esses elementos como executáveis.

Pergunta: “Em que casos o evento de timer fica localizado no objeto da atividade?”
Resposta: Diversos eventos intermediários podem ser usados no fluxo do processo ou na borda da atividade. O artigo Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários apresenta alguns exemplos que podem esclarecer esta dúvida.

Pergunta: “Na hora de desenhar o processo, é correto já sinalizar alguma falha do processo para posterior correção?”
Resposta: Embora não exista na notação símbolos específicos para isto (lembra que comentei que BPMN não é uma metodologia?), esta pode ser uma boa prática a ser adotada na metodologia de trabalho de modelagem e análise dos processos da organização. Para isso, podem ser usadas as anotações, ou, dependendo da ferramenta utilizada, é possível adicionar símbolos específicos definidos pelo time de processos da organização para isto.

Pergunta: “Evento de mensagem: comunicação entre os processos: não uma ação entre eles, correto?”
Resposta: O evento de mensagem é uma forma de um processo comunicar a outro processo que ele deve realizar alguma ação, mas de fato as ações são modeladas como tarefas, e não como eventos.

Pergunta: “No exemplo de Elementos do diagrama de Processo, no final do fluxo existe um loop sobre a entrega da obra. Pode ser definido um X vezes que pode ser feito o loop para não ficarmos presos nesta etapa.”
Resposta: É possível sim, mas para isso precisaríamos modificar um pouco o diagrama. Poderíamos adicionar um gateway para verificar quantas vezes já foram repetidas estas ações ou colocar esse subconjunto de tarefa e eventos em um subprocesso com loop (mas daí já começamos a falar de um conhecimento mais avançado em BPMN que não abordamos neste webinar).

Pergunta:  ”Referente ao Gateway exclusivo: está ali ‘decisão exclusiva. Apenas uma opção é válida’. Significa que o processo só pode ter um caminho válido a seguir, porém temos que considerar as demais, correto? Pois a necessidade do cliente é esta. Corrija-me se estiver errado.”
Resposta:  Sim, essa é a ideia do gateway. Mapeamos nele todas as possibilidades que o negócio prevê. Por exemplo: se geralmente 80% dos casos segue por um caminho, ainda assim há 20% de casos que podem seguir o(s) outro(s) caminhos mapeados a partir do gateway, o que torna necessário prever isto no nosso diagrama.

Pergunta: “Qual o nome do autor e do livro?”
Resposta: Durante o webinar citei o livro BPMN Method & Style, do Bruce Silver.

Pergunta: “Sabes informar se o Bizagi tem os elementos de coreografia?”
Resposta: O Bizagi só possui os elementos para modelagem do diagrama de processo (diagrama de orquestração).

 

PERGUNTAS & RESPOSTAS SOBRE OS CURSOS

Pergunta: “Para fazer o “Dominando” há necessidade de fazer o introdutório?”
Resposta: O curso de Introdução a BPM e BPMN com Bizagi da iProcess {Education} não é pré-requisito para o curso Dominando o Mapeamento de Processos com BPMN 2.0, porém se você já tiver algum conhecimento prévio sobre a notação, tende a ter maior aproveitamento neste segundo curso.

Pergunta: “Vi que existe um curso para Mapeamento e outro para Modelagem. Qual a diferença prática entre o Mapeamento e a Modelagem?”
Resposta: O treinamento de Mapeamento de Processos tem foco na utilização da notação para criação de diagramas usando a notação BPMN. Já o curso de Modelagem de Processos de Negócio tem  como foco a atividade de modelagem no ciclo de melhoria de processos: técnicas, ferramentas e métodos de levantamento de informações para modelar o processo, documentação (que vai além do diagrama) do processo, como desdobrar a estratégia da organização na cadeia de valor de processos da organização e priorizar os processos para modelagem, análise e redesenho.

Pergunta: “No curso modelagem de processo inclui a notação?”
Resposta: Sim, no curso de Modelagem de Processos de Negócio temos algumas horas dedicadas ao estudo da notação, mas apenas do nível introdutório (nível de modelagem descritivo).

BPMN: Introdução ao Diagrama de Conversação

Com sua versão 2.0, oficialmente lançada em 2011, BPMN não apenas adicionou novos elementos ao diagrama de processo, mas também propôs dois tipos de diagramas complementares, que possibilitam obter perspectivas diferenciadas sobre o processo: o Diagrama de Coreografia e o Diagrama de Conversação.

O Diagrama de Coreografia apresenta uma visão bastante interessante da interação entre processos, especialmente em processos business-to-business, onde há diversas partes interessadas envolvidas. Ele abstrai as particularidades da lógica do processo mapeado no diagrama de orquestração (aquele que já conhecemos bem) e foca na sequência e as dependências envolvidas na troca de informações do processo com agentes externos. Esse diagrama já foi apresentado em nosso blog nos artigos: BPMN 2.0 – Novos Diagramas e Elementos: Introdução a Coreografia e Coreografia no detalhe.

Neste artigo, vamos falar sobre o Diagrama de Conversação.

Diagrama de Conversação (Conversation Diagram)

O Diagrama de Conversação tem o propósito de dar visibilidade sobre os participantes do domínio do processo. Neste diagrama, o foco não é a lógica do processo, mas a comunicação: quem são os participantes e sobre o quê eles “conversam”.

O Diagrama de Conversação pode ser facilmente extraído de um Diagrama de Processo.

Neste diagrama, os participantes são as pools. Todas elas são representadas como “black pools” (o fluxo do processo dentro delas não é visualizado), colocando o foco da atenção da modelagem na troca de mensagens entre elas.

As mensagens podem ser agrupadas por assunto, criando os nodos de conversação (conversation nodes).

Por exemplo:
Em nosso processo “Vender Livros via Web” (que está no nosso Guia de referência rápida BPMN 2.0), temos a Loja (que é quem executa este processo) e que se comunica com o Cliente e com a Editora.

Diagrama de Orquestração: Processo de Negócio "Vender Livros via Web"

Então neste processo, temos claramente três participantes: a Loja, o Cliente e a Editora (que pode ser mais de uma, já que o subprocesso “Encomendar obra” ocorre múltiplas vezes, enviando listas de títulos às diferentes editoras envolvidas no pedido com obras faltando em estoque).

Diagrama de Conversação: os participantes do processo do exemplo Vender Livros via Web

Com o Cliente, a Loja conversa sobre o pedido de livros, o pagamento do pedido de livros (envio do título de cobrança e confirmação de pagamento) e a entrega do pedido de livros (envio dos livros vendidos e confirmação de recebimento).

Com a(s) Editora(s), a Loja conversa sobre encomenda de títulos (lista de títulos e entrega da encomenda).

Essas “conversas” podem ser descritas detalhadamente, apresentando a troca de mensagens entre os participantes:

Ou agrupadas, reunindo as “conversas” por assunto usando os elementos de nó de conversação (conversation node), estes símbolos em formato de hexágono. Os nós de convesação são conectados aos participantes através de ligações de conversação (conversation link), que são linhas duplas conectando o nodo aos participantes da conversa.

Querendo-se, é possível subir mais ainda o nível da abstração da conversa, reunindo os nodos com temas em comum com um nó de sub-conversação (sub-conversation node), que possui um marcador [+] na base. No exemplo, podemos reunir as conversas entre cliente e livraria em um nó de sub-conversação de “Venda de livros”.

Cada um dos três diagramas acima são um mesmo Diagrama de Conversação, porém visualizado em níveis de detalhamento diferentes.

Para um processo tão simples como este, o Diagrama de Conversação pode não parecer uma ferramenta muito relevante. Mas considere um processo mais complexo, como por exemplo a aquisição de um imóvel, onde temos: o cliente, a construtora, o banco, as lojas de material para construção:

Diagrama de Conversação para o processo de negócio de construir e vender imóveis de uma construtora.

Este diagrama pode ser uma ótima ferramenta para alinhar entre os participantes que tipo de informação será trocada com quem no decorrer do processo.


Aprenda a utilizar todo o potencial da notação BPMN e seus três tipos de diagrama 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: 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