Modelagem de Processos de Negócios

Aula 04

Juliano Yugoshi
Sumário
• Modelagem Básica de Processos (Capítulo 3)
− Primeiros passos com BPMN
– Decisões exclusivas no BPMN
Capítulo 3 – Modelagem de Processos
Essenciais
Objetivo do capítulo é a familiarização com os
ingredientes básicos da modelagem de
processos usando a linguagem BPMN.
Por que modelar processos de
Negócio?
• Entender o processo e compartilhar nossa
compreensão do processo.
– Passo essencial para futura análise,
redesenho e automação do processo.
Primeiros passos com BPMN

• O BPMN tem mais de 100 símbolos.

• Mas com um conjunto relativamente
pequeno de símbolos é possível fazer a
maioria dos modelos que precisaremos
produzir.
• Iniciaremos nosso estudo com um conjunto
básico de símbolos.
Elementos básicos do BPMN

• Evento: coisas que acontecem

instantaneamente (círculos).
•Atividade: unidades de trabalho que têm
uma duração (retângulos arredondados).
• Fluxo de sequência (ou arco): indica relação
entre eventos e atividades (seta ou flecha).
Exemplo 1

• Uma sequência simples de atividades para o

modelo de um processo de atendimento de pedido.
– Esse processo é iniciado sempre que um pedido de
compra tiver sido recebido de um cliente.
– A primeira atividade a ser realizada é confirmar o pedido.
– Em seguida, o endereço de remessa é recebido para que
o produto possa ser enviado ao cliente.
– Depois, a fatura é emitida e uma vez que o pagamento é
recebido o pedido é arquivado, completando assim o
processo.
Exemplo 1
Exemplo 1

Exercício:
- Reproduzir a figura acima usando Bizagi Modeler
ou bpmn.io
Exemplo 1

• Usamos diferentes representações para eventos

iniciais (borda fina) e finais (borda grossa).
• O evento de início indica quando as instâncias do
processo são iniciadas.
• O evento final indica quando as instâncias são
concluídas.
Exemplo 1

• Uma vez que uma instância de processo foi

gerada, podemos usar o conceito de token para
identificar o progresso (ou estado) dessa instância.
• Tokens são criados em um evento de início, fluem
por todo o modelo de processo até serem
destruídos em um evento final.
• Os tokens são representados por pontos coloridos
no modelo de processo.
Exemplo 1

• A figura a seguir mostra o estado de três instâncias

do processo de atendimento de pedidos:
• uma instância acaba de iniciar (token preto no evento de
início),
• outra está enviando o produto (token vermelho na
atividade "Enviar produto") e
• a terceira recebeu o pagamento e está prestes a começar
a arquivar o pedido (token verde no fluxo de sequência
entre "Receber pagamento" e "Arquivar pedido").
Exemplo 1
Nomes (Rótulos) para Eventos

• É recomendado dar nomes para os eventos.

• O nome do evento inicial indica o que desencadeia
a execução do processo.
• O nome do evento final indica quais as condições
para finalização do processo e qual o resultado do
mesmo.
Convenções para Nomes de Eventos
• Deve começar com um substantivo (tipicamente um objeto
de negócios) e terminar com um verbo no particípio
passado (ex: "Fatura emitida").

• O verbo no particípio passado indica algo que acabou de

acontecer.

• O substantivo pode ser acompanhado de um adjetivo (ex:

“Pedido urgente enviado").
Convenções para Nomes (Rótulos) de
Atividades
• Deve começar com um verbo no infinitivo seguido de um
substantivo (ex: "Aprovar pedido").
• O substantivo pode ser acompanhado de um adjetivo (ex:
"Emitir carteira de motorista").
• Pode ser usado um complemento para explicar como a
ação está sendo feita (ex: "Renovar carteira de motorista via
agências on-line").
• Mas deve-se evitar rótulos muito longos (com mais de
cinco palavras, excluindo preposições e conjunções).
• Devemos evitar artigos.
Convenções para Nomes de Processos

• Para nomear um modelo de processo, devemos

usar um substantivo, acompanhado de um
complemento (ex: "atendimento de pedido" ou
"processamento de solicitações").
• Este rótulo pode ser obtido do verbo que descreve
a ação principal do processo (ex: "Atender o
pedido", a ação principal, torna-se "atendimento de
pedido").
Ramificação e Fusão OU Divisão e
Junção (Branching and Merging)
• Atividades e eventos não precisam necessariamente ser
executados de forma sequencial.
• Situação 1:
– Em um processo de tratamento de solicitação, a
aprovação e a rejeição de uma solicitação são duas
atividades que se excluem.
– Portanto, essas atividades não podem ser executadas em
sequência.
– Quando duas ou mais atividades são alternativas,
dizemos que elas são mutuamente exclusivas.
Ramificação e Fusão OU Divisão e
Junção (Branching and Merging)
• Situação 2:
– No processo de solicitação de crédito, uma vez que o
pedido foi aprovado, o requerente é notificado e o
desembolso é feito.
– A notificação e o desembolso são atividades realizadas
por duas unidades de negócio diferentes, por isso são
independentes uma da outra e, assim, não precisam ser
executadas em sequência, podendo ser realizadas em
paralelo, isto é, ao mesmo tempo.
– Quando duas ou mais atividades não são
interdependentes, elas são concorrentes.
Ramificação e Fusão OU Divisão e
Junção (Branching and Merging)
• Esses comportamentos são modelados no BPMN com o
uso de gateway.
• O termo gateway implica na existência de um mecanismo
de bloqueio que permite ou não a passagem de tokens
através do gateway.
• À medida que os tokens chegam a um gateway, eles podem
ser divididos ou mesclados (fundidos) dependendo do tipo
de gateway.
• Representamos os gateways através de losangos e os
distinguimos entre ramificações (divisões) e junções.
Ramificação e Fusão OU Divisão e
Junção (Branching and Merging)
• Um gateway de divisão representa um ponto em que o
fluxo de processo diverge enquanto um gateway de junção
representa um ponto em que o fluxo de processo converge.

• As divisões têm um fluxo de sequência de entrada e vários

fluxos de sequência de saída.

• As junções têm múltiplos fluxos de sequência de entrada

(representando os ramos a serem unidos) e um fluxo de
sequência de saída.
Decisões Exclusivas
• Para modelar a relação entre duas ou mais atividades
alternativas usamos uma divisão exclusiva (XOR).

• Usamos uma junção-XOR para mesclar dois ou mais ramos

alternativos que podem ter sido previamente divididos com
uma divisão-XOR.

• Um gateway XOR é indicado com um losango vazio ou

marcado com um "X".
Exemplo: processo de verificação de
faturas
• Assim que uma fatura é recebida de um cliente ela precisa
passar por uma verificação de erros. A verificação pode
resultar em uma destas três opções:
i. não há erros, neste caso a fatura é enviada para o
arquivamento;
ii. existem erros, mas estes podem ser corrigidos, neste
caso a fatura deve ser reenviada para o cliente;
iii. existem erros e estes não podem ser corrigidos, neste
caso a fatura é bloqueada.
• Após a realização de uma dessas três atividades, a fatura é
arquivada e o processo é concluído.
Exemplo: processo de verificação de
faturas
Decisões Exclusivas
• Uma divisão-XOR encaminha o token proveniente de sua
entrada para um dos seus ramos de saída.
• Ao usar uma divisão-XOR, verifique se cada fluxo de
sequência de saída é anotado com um rótulo que captura a
condição em que esse ramo específico é obtido.
• Além disso, utilize sempre condições mutuamente
exclusivas, isto é, apenas uma delas pode ser verdadeira
sempre que a divisão XOR é atingida por um token.
• Essa é a característica do gateway de divisão-XOR.
Decisões Exclusivas
• Na figura o fluxo rotulado “Existem erros mas não podem
ser corrigidos" é marcado com um corte oblíquo. Essa
notação é opcional e é usada para indicar o fluxo padrão, ou
seja, o fluxo que será tomado pelo token proveniente da
divisão-XOR, caso as condições associadas a todos os outros
fluxos de saída sejam avaliadas como falsas.
• Uma vez que este arco tem o significado de “caso
contrário”, ele pode ser deixado sem rótulo. No entanto, é
recomendável rotular este arco com uma condição para fins
de legibilidade.
Execução Paralela
• Quando duas ou mais atividades não têm
dependências de ordem entre si (ou seja,
uma atividade não precisa seguir a outra,
nem exclui a outra), elas podem ser
executadas simultaneamente ou em paralelo.
• O gateway paralelo (AND) é usado para
modelar essa relação particular.
Execução Paralela
• Especificamente, usamos uma divisão-AND
para modelar a execução paralela de dois ou
mais ramos e uma junção-AND para
sincronizar a execução de dois ou mais ramos
paralelos.
• Um gateway AND é representado como um
losango com o símbolo "+".
Exemplo de processo de verificação
de segurança no aeroporto
• Uma vez recebido o cartão de embarque, os
passageiros se encaminham para verificação de
segurança. Aqui eles precisam passar pela inspeção
pessoal e inspeção de bagagem. Depois, eles podem
ir para o embarque.
Exemplo de processo de verificação
de segurança no aeroporto
Extensão ao exemplo de pedido de
compra
• Vamos assumir que um pedido de compra só é
confirmado se o produto estiver em estoque, caso
contrário, o processo será concluído rejeitando o
pedido.
• Além disso, se o pedido for confirmado, o
endereço de entrega é recebido e o produto é
enviado ao mesmo tempo em que a fatura é emitida
e o pagamento é recebido.
• Depois, o pedido é arquivado e o processo é
concluído.
Exemplo anterior: Processo de
atendimento de pedido
Extensão ao exemplo de pedido de
compra
Extensão ao exemplo de pedido de
compra - Observações
• Atividades mutuamente exclusivas, como "Recuperar
produto do estoque" e "Rejeitar pedido“, devem ser
precedidas de uma divisão-XOR.
• As sequências "Obter endereço de entrega" – "Enviar
produto" e "Emitir fatura" – "Receber pagamento" podem ser
realizadas independentemente uma da outra, ou seja, entre
uma divisão-AND e uma junção-AND.
• Existem dois eventos finais neste exemplo.
Omissão de Gateway-XOR
• Uma junção-XOR pode ser omitida antes de uma atividade
ou evento. Neste caso, os arcos de entrada para a
junção-XOR são diretamente conectados à atividade/evento.
Omissão de Gateway-AND
• Uma divisão-AND também pode ser omitida quando segue
uma atividade ou evento. Nesse caso, os arcos de saída da
divisão-AND emanam diretamente da atividade/evento.
Omissão de Gateway

• Neste momento não vou permitir as

omissões de gateway.
Exercício 4
Modelar usando o Bizagi Modeler, Camunda Modeler ou bpmn.io, 
o seguinte fragmento de um processo de negócios para avaliar
pedido de empréstimo.
Um pedido de empréstimo é aprovado se passar por duas
verificações que são realizadas de forma concorrente:
(i) a avaliação de risco, feita automaticamente por um sistema, e
(ii) a avaliação do imóvel para o qual o empréstimo foi solicitado,
realizada por um avaliador de imóveis. 
A avaliação de risco precisa de uma verificação de histórico de
crédito do requerente, que é realizada por um analista financeiro. Uma
vez que a avaliação de risco e a avaliação do imóvel foram realizadas,
um analista de empréstimo pode avaliar a elegibilidade do
requerente. Se o requerente não é elegível, o pedido é rejeitado, caso
contrário, o pacote de aceitação é preparado e enviado ao
requerente.
Observações: vocês ainda não precisam representar os diferentes
atores do processo.

postar no AVA a resposta da atividade no formato de imagem.