Diagramas BPMN com ou sem raias: 3 abordagens em que o foco da modelagem faz a diferença

Usar ou não usar pools e lanes (piscinas e raias) na modelagem de processos é uma discussão de longa data e persistente ainda nos dias de hoje.

A especificação da notação BPMN apresenta e explica a utilização destes componentes mas declara que o seu uso é opcional, o que dificulta ainda mais o entendimento por algumas equipes sobre quando e como usá-los.

Modelar com swimlanes pode trazer clareza visual sobre as entidades organizacionais envolvidas no processo, porém tende a deixar o diagrama mais carregado visualmente, já que haverá mais linhas para se cruzarem e em alguns casos conectores mais longos para unir atividades em raias distantes.

Não utilizar swimlanes, por outro lado, permite aproximar as atividades e elementos do fluxo criando um diagrama teoricamente mais enxuto, mas torna implícito a identificação das áreas e papéis resolvidos – o que até poderia ser resolvido por outros artifícios como o uso de anotações ou complementação na descrição das tarefas (forçando a ter caixas maiores para cada elemento do fluxo e igualmente carregando visualmente o diagrama do processo).

Entre os prós e contras de cada abordagem, há um aspecto muito mais relevante a ser considerado: para quê o modelo de processo está sendo criado.

Exploramos aqui três focos de modelagem que podem ajudá-lo nessa avaliação.

Para ilustrar cada abordagem, vamos utilizar como exemplo um fluxo inspirado no clássico processo de tele-entrega de pizza, traduzido livremente do modelo “5.2 The Pizza Collaboration” em BPMN 2.0 by Example (já usamos este exemplo em um outro artigo sobre modelagem de processos no blog da iProcess – aqui).

1. Quando o foco é analisar como as atividades adicionam valor ao processo 

Neste caso, a melhor abordagem de modelagem pode ser sem lanes, desenhando o processo como um fluxo linear em que todas as atividades essenciais estão em uma mesma linha, e tudo o que é contorno/alternativa é mapeado para cima ou para baixo do fluxo.

Esta é uma abordagem de uso da notação BPMN inspirada em Lean, no qual o Value Stream Mapping (VSM) busca mapear o fluxo de adição de valor do processo.

Esta abordagem foca na fluidez das atividades essenciais à produção do resultado do processo, que são as que devem ser priorizadas em ações de melhoria do processo visando a sua otimização.

 

2. Quando o foco é compreender as responsabilidades dos envolvidos na execução do processo

Aplicar a abordagem de raias para representar os papéis envolvidos no processo é interessante para deixar mais claro visualmente as responsabilidades de cada participante.

Isto possibilita identificar que atividades são executadas por cada papel, e a partir disso identificar quais são as habilidades, competências e nível de autoridade requerido na execução de cada etapa do trabalho.

 

3. Quando o foco é tornar explícitas as interações do cliente com a organização através do processo 

Neste caso, o uso de pools e lanes traz uma camada de informação visual adicional importante, que é a da comunicação entre o processo da organização e o processo do cliente. É possível não apenas identificar onde estão os “momentos da verdade” em que o cliente interage com a organização, mas também com quem e por quê ele faz essas interações.

Esta abordagem é ideal em projetos de transformação que têm como objetivo alinhar o negócio ao foco do cliente, possibilitando compreender a sua experiência atual.

 

Todas essas abordagens são possíveis dentro da utilização da notação BPMN conforme as suas regras – portanto não existe certo e errado.

O melhor caminho é, em primeiro lugar, ter claro qual o propósito da modelagem que estamos realizando e então definir a melhor estratégia de uso da notação!


Problemas comuns na modelagem de processos em BPMN III – Uso de tarefas para sinalizar o resultado de gateways

Continuando a série sobre problemas comuns na modelagem de processos em BPMN (veja os artigos anteriores aqui e aqui), hoje iremos falar de uma situação bastante recorrente que constatamos nos nossos treinamentos, que é o uso de tarefas para sinalizar o resultado de gateways no processo.

Para explicar melhor o que queremos dizer, veja o exemplo abaixo:

Perceba que a pessoa que modelou o processo, para demonstrar os resultados do gateway relativo à atividade “Avaliar Reembolso”, optou por criar duas tarefas em cada um dos fluxos de sequencia ligados ao gateway, nomeando-as como “Aprovado” e “Reprovado”.

O elemento Tarefa (Task) de BPMN se refere a um trabalho que é efetivamente realizado dentro de um processo. Uma tarefa deve, essencialmente, indicar uma ação a ser realizada, que consuma algum recurso (como a tarefa “Avaliar Reembolso” no exemplo acima).

Logo, concluímos que não faz sentido utilizar uma tarefa apenas para indicar uma mudança de status ou sinalizar os resultados de um gateway.

Qual então seria a forma correta de modelar este caso? Veja no exemplo atualizado abaixo:

A abordagem correta (e mais simples!) é simplesmente nomear os fluxos de sequencia ligados ao gateway. No caso acima, cada fluxo de sequência foi nomeado com os resultados possíveis da tarefa de Avaliar reembolso, ou seja, “Aprovado” ou “Reprovado”.

Com isto, o desenho do processo fica mais limpo e fácil de interpretar. Simples e prático! :-)

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! ;-)

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!

 

 

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