MODELAGEM DE PROCESSOS COM

BIZAGI MODELER
 PADRONIZAO DO DESENHO DE PROCESSOS UTILIZANDO A
FERRAMENTA BIZAGI MODELER
1. OBJETIVO

a) Ser capaz de compreender os conceitos fundamentais de BPM.

b) Conhecer os principais conceitos da notao BPMN (Business Process Management
Notation) em sua verso;
c) Ser capaz de identificar os principais elementos que compem a notao BPMN;
d) Conhecer a interface do Bizagi e suas principais configuraes;
e) Estar habilitados a modelar processos de negcio na notao BPMN utilizando a ferramenta de
modelagem Bizagi Modeler;
f) Conhecer os recursos de documentao dos fluxos modelados no Bizagi, permitindo um maior
detalhamento das atividades inerentes aos processos, contemplando procedimentos,
formulrios, legislaes, anexos, etc;
g) Conhecer os recursos que permitem a publicao e exportao dos fluxos modelados no
Bizagi;
h) Conhecer os recursos de simulao que subsidiam a capacidade de anlise de tempo e custo
dos processos a fim buscar melhorias para os mesmos;

2. BIBLIOGRAFIA UTILIZADA
a) BPM CBOK 3.0 ABPMP Association of Business Process Managment
Professionals;
b) Handbook on Business Process Management 1 J. Vom Brocke, M. Rosemann,
Ed. Springer, 2010;
c) Handbook on Business Process Management 2 J. Vom Brocke, M. Rosemann,
Ed. Springer, 2010;
d) Business Process Model and Notation (BPMN) verso 2.0 site da OMG
(www.omg.org/bpmn/);
e) Padronizao do desenho de Fluxogramas no Bizagi verso 2.0 - Escritrio de
Processos SEGPLAN 2013. Disponvel no site da Segplan (www.segplan.go.gov.br);
f) Bizagi Process Modeler User Guide site do Bizagi
(http://help.bizagi.com/processmodeler/en/);
g) Guia para Formao de Analistas de Processos Gart Capote, Volume 1, 2011;
h) Modelagem de Processos com BPMN Andr L. N. Campos, Ed. Brasport, 2013;
i) Medio de Valor de Processos para BPM Gart Capote, 2013;

3. PBLICO ALVO
Este documento visa atingir o pblico interessado em trabalhar com modelagem de
processos de negcio. Em especial, um pblico que no tenha muita experincia com a
diagramao de fluxos de trabalho utilizando a notao BPMN associada ferramenta Bizagi
Modeler, haja vista que esta no uma notao muito simples. Buscamos aqui reduzir os

2
elementos utilizados dentro da notao, comprovando que possvel realizar a modelagem
de fluxos de trabalho orientado ao negcio, sem necessariamente utilizar todos os elementos
presentes na notao.

4. O BIZAGI MODELER
1
Bizagi Modeler um software gratuito, desenvolvido pela empresa BIZAGI, para
modelagem descritiva, analtica e de execuo, de processos de negcio utilizando a notao
BPMN em consonncia com toda a disciplina de BPM. Alm de permitir a modelagem dos
fluxos de trabalho, suporta a elaborao de uma documentao bastante rica em relao ao
processo e permite a publicao de toda esta documentao em alguns formatos diferentes
de arquivo, inclusive no formato Web, visando dar maior publicidade s atividades praticadas
pelas organizaes que prezam pela gesto do conhecimento, bem como as organizaes
publicas que, alm disso, tm que prezar pela transparncia dos servios prestados.
Por fim, o Bizagi Modeler permite a simulao dos fluxos de trabalhos a fim de facilitar a
anlise de melhorias tanto em relao ao tempo quanto em relao ao custo das atividades
desenvolvidas.

5. NOTAO
A notao adotada para a padronizao da diagramao dos fluxos de trabalho ser a
Business Process Management Notation (BPMN) Notao de Gerenciamento de Processos de
Negcio.
BPMN atua com uma linguagem comum, que permite s organizaes descrever seus
fluxos de trabalho de forma a operacionalizar suas tarefas entre todos os stakeholders.
Esta notao foi adotada pela 2Object Management Group (OMG) que um consrcio
internacional aberto, sem fins lucrativos, voltado para a padronizao de tecnologias. Foi este
consrcio que norteou, por vrios anos, a padronizao do Business Process Management
(BPM).

6. CONFIGURANDO A FERRAMENTA
5.1. Idioma para alterar o idioma da ferramenta, acesse o menu Idioma localizado no
canto superior direito do aplicativo e selecione o idioma desejado. Para que a

1 Bizagi www.bizagi.com

2 OMG www.omg.org

3
 seleo tenha efeito necessrio fechar todas as janelas do Bizagi e abrir o
aplicativo novamente.
5.2. Modo para que todos os elementos de fluxo, dados, artefatos, raias e conectores se
tornem visveis na palheta, necessrio selecionar o modo de operao
Estendido. Caso no seja feita esta seleo, s estaro visveis na palheta de
seleo os elementos principais.
5.3. Gradiente e Sombra para atender aos padres definidos neste manual,
necessrio desmarcar as opes de gradiente e sombra existentes na guia
Visualizar, grupo Mostrar.

5.4. 3Tamanho dos elementos optamos tambm por definir um tamanho padro para os
elementos da notao BPMN, conforme descrito abaixo:
Evento largura (40 px) e altura (40 px);
Gateway largura (60 px) e altura (60 px);
Atividade largura (90 px) e altura (60 px);
Subprocesso largura (90 px) e altura (60 px);
Objeto de Dados largura (40 px) e altura (50 px);

3 Caso a padronizao dos tamanhos dos elementos no seja seguida, sugerimos pelo menos
que os tamanhos definidos pelo modelador sejam utilizados em todo o diagrama, evitando
que no mesmo diagrama tenhamos elementos de mesmo tipo com tamanhos diferentes.

4
7. GLOSSRIO
7.1. Processo: descreve uma sequncia ou fluxo de atividades em uma organizao com
o objetivo de realizar um trabalho. Em BPMN os processos so retratados como um
grfico de fluxo de elementos, os quais so atividades, eventos, gateways e fluxos
de sequncia (conectores) que definem uma semntica finita de execuo. Os
processos podem ser definidos em qualquer nvel da organizao, sendo que
processos de mais baixo nvel podem ser agrupados para juntos alcanarem um
objetivo maior.
O uso dos termos Colaborao e Coreografia so usados quando existe a
modelagem da interao entre processos. Este assunto no ser abordado neste
manual.
7.2. Processo privado: so processos de negcio internos e especficos de uma
organizao. Existem dois tipos deste processo:
7.2.1. No executvel: processo que modelado para ser documentado, permitindo
o descobrimento da maneira de trabalhar da organizao. Alm disso, permite
a publicao dos modelos produzidos, apoiando a gesto do conhecimento. Por
fim, permite tambm a simulao e anlise de tempo e custo com vistas a
fomentar possveis melhorias. No possui informaes ou mecanismos
suficientes para serem executveis.
7.2.2. Executvel: processo que est sendo modelado com uma riqueza de detalhes
e um propsito de ser executado de acordo com uma semntica definida. So
os processos produtos de automao.

5
7.3. Processo pblico: representa a interao entre um processo privado e outro processo
ou participante. Somente as atividades usadas para comunicar com outros
participantes, mais a ordem destas atividades so includas em um processo
pblico. Os outros detalhes no so mostrados, logo, o processo pblico mostra ao
mundo externo as mensagens e a ordem destas mensagens necessrias para a
interao entre processos/participantes.
Os processos pblicos podem ser modelados separadamente ou dentro de uma
colaborao que mostra um fluxo de mensagens entre processos e outros
participantes. Tambm podem ser chamados de processos abstratos.
7.4. Processo descritivo: o diagrama abstrato, de mais alto nvel, orientado ao negcio,
com uma documentao resumida do fluxo de trabalho. Omite alguns ou todos os
caminhos de exceo. Seus principais consumidores so os gestores das
organizaes.

7.5. Processo analtico: o diagrama detalhado, tambm orientado ao negcio, no

entanto, mostrando uma descrio precisa do fluxo de atividades, incluindo os
caminhos de exceo. Neste nvel de modelagem existe uma maior diversidade dos
elementos utilizados na composio do diagrama. Os principais consumidores so
os profissionais de nvel tcnico e operacional, em especial o dono do processo.

6
7. ELEMENTOS UTILIZADOS NA PADRONIZAO
Visando simplificar o trabalho de modelagem de fluxos de trabalho e aumentar a adoo
desta prtica na administrao pblica do poder executivo estadual, procurou-se usar apenas
os elementos fundamentais da notao neste documento de padronizao.
Logo abaixo sero descritos todos os elementos sugeridos para tal padronizao:

7.1. PISCINA/POOL
Container que a representao grfica de um participante de um processo.
Geralmente um processo de negcio est contido dentro de uma nica piscina, mas isso
no uma regra. Ou seja, uma piscina pode se referir a um processo.
Em determinadas circunstncias, uma piscina pode representar um caixa preta
(black box), ou seja, a representao de um processo participante/colaborador de outro
processo, cuja modelagem no representada.

7.2. RAIA/LANE
uma sub-partio dentro de um processo usada para organizar e categorizar
atividades dentro do mesmo. BPMN no especifica o uso de raias, mas elas so
frequentemente utilizadas para identificar coisas como, papis internos, sistemas e
departamentos internos.

7
 7.3. CONECTORES
So elementos utilizados para mostrar a ordem de sequenciamento das atividades
e eventos que ocorrem dentro de um fluxo de trabalho.
Cada conector tem apenas uma fonte e um alvo. Os conectores podem ser
utilizados para definir o caminho feliz de execuo de um processo.
Os conectores destacados em negrito so os adotados na padronizao.
1 Fluxo de sequncia usado apenas para mostrar a ordem
em que as atividades sero executadas em um processo.

2 Fluxo de mensagem usado para mostrar o fluxo de

mensagens entre dois participantes que esto preparados para
enviar e receber mensagens. Obs: em BPMN, duas piscinas
separadas em um diagrama de colaborao representam os
dois participantes.

3 Associao usada para ligar informaes em artefatos com

elementos grficos do BPMN. Anotaes e outros artefatos
podem ser associados com um elemento grfico por meio deste
conector.

7.4. ATIVIDADES
As atividades representam pontos no processo onde algum trabalho executado.
Uma atividade pode ter mltiplas entradas, no entanto, se no tiver nenhuma
entrada, dever ser instanciada quando o processo for instanciado.
Se uma instncia tem mltiplas entradas, isso considerado um fluxo
descontrolado. Isso significa que quando um dos tokens chega de um dos caminhos, a
atividade ser instanciada e no aguardar a chegada de outros tokens de outros
caminhos. Se outro token chegar, do mesmo ou outro caminho, uma instncia separada
da atividade ser criada. Se o fluxo precisa ser controlado, ento ele dever convergir
para um gateway que precede a atividade.
Uma atividade poder ter mltiplas sadas e se isso acontecer, significa que um
separador de caminhos paralelos est sendo criado para cada fluxo. Se uma atividade
no tem nenhuma sada, ela marca o fim de um ou mais caminhos de um processo.
Quando uma atividade o fim e no existem caminhos paralelos ento o processo deve
ser completado.
Uma atividade pode ser o alvo ou a fonte de um fluxo de mensagem, podendo ter
uma ou mais entradas e sadas de fluxos de mensagens.
Executor/Performer: define o recurso que ser responsvel ou executar a
atividade. Pode ser uma pessoa, um grupo, uma posio ou papel de uma organizao
ou uma organizao.

Tarefa
uma atividade atmica dentro do fluxo do processo. usada quando o trabalho
realizado no pode ser decomposto em um nvel mais fino de detalhamento. Geralmente
so os usurios finais ou aplicaes, os responsveis por executar as tarefas.
A identificao das atividades dever ser feita no interior do retngulo e iniciada
com um verbo na terceira pessoa do singular.

8
 As tarefas destacadas em negrito so as adotadas na padronizao.

1 - None - tarefa que no tem nenhuma especificidade. Pode tambm ser chamada
de tarefa abstrata;

2 - Servio - tarefas que usam algum tipo de servio, como Web Services ou
aplicaes automatizadas;

3 - Envio - tarefa designada para enviar uma mensagem para um participantes

externo. Uma vez a mensagem enviada, a tarefa estar completa.

4 - Recebimento - tarefa designada para aguardar por uma mensagem que

chegar de um participante externo. Uma vez a mensagem recebida, a tarefa
estar completa. frequentemente utilizada para iniciar um processo;

5 - Humana - tarefa executada por por pessoas com o apoio de um software e

programado por um gerenciador de lista de tarefas;

6 - Manual - tarefa executada sem a ajuda de qualquer mecanismo ou aplicao.

Um exemplo poderia ser a instalao de um telefone no cliente.

7 - Business Rule - tarefa que prov um mecanismo de entrada de uma regra de

negcio para obter a sada de um clculo ao qual o processo depende.

8 - Script - tarefa onde o modelador define um script em uma linguagem que pode
ser interpretada. Quando a tarefa a alcanada, inicia a execuo do script.
Completada a execuo, a tarefa tambm estar completa.

7.5. SUB-PROCESSOS
uma atividade que tem em seu interior a modelagem de outras atividades,
gateways, eventos e fluxos de sequncia. Tambm um objeto grfico dentro de um
processo, mas pode ser aberto para que enxerguemos seu interior. Tarefas que em
conjunto possuem um propsito especfico dentro de um processo de negcio e podem
ser abstradas em uma outra unidade de processo e representadas em um processo
maior por um nico objeto.
Os sub-processos definem um escopo contextual que pode ser usado para dar
visibilidade, tratamento de excees e at mesmo um escopo transacional.
Tambm podem ser teis para reunir partes de fluxos que podem ser repetidas em
momentos distintos do processo, caracterizando o reuso.

9
 Contrado Expandido

Tipos de Sub-processos:
1. Embutido - pode estar em uma viso contrada, onde os detalhes ficam ocultos,
ou pode estar em uma viso expandida que mostra os detalhes dentro da viso do processo
em que ele est contido. Eles so frequentemente usados em um contexto de tratamento de
exceo que se aplica a um grupo de atividades.
2. Reusvel - na verso 2.0 do BPMN conhecido como Call Activity conforme
descrito em seo posterior. Para a padronizao da modelagem, sugerimos a utilizao
apenas dos sub-processos reusveis.
3. Evento - um sub-processo especializado, usado dentro de um processo ou outro
sub-processo. No parte de um fluxo normal do processo pai, alm de no ter entradas nem
sadas do fluxo de trabalho.
Este tipo de sub-processo pode ou no ocorrer enquanto o processo pai est ativo,
mas possvel que isso acontea vrias vezes. Diferente do sub-processo padro, que
usa o fluxo do processo pai para acion-lo, este tipo de sub-processo tem um evento de
incio com um gatilho. Toda vez que o evento de incio acionado enquando o processo
pai est ativo, este sub-processo iniciado.
Este tipo de sub-processo no suportado pelo Bizagi.

7.6. CALL ACTIVITY / REUSVEL

Representa um ponto no processo onde um processo independente e inteiro ou
uma tarefa inteira usada, agindo como um invlucro dentro da execuo. A ativao de
um sub-processo reusvel resulta na transferncia do controle para uma chamada ao
processo/tarefa independente.
A diferena visual entre um sub-processo reusvel e um sub-processo embutido
a borda do reusvel que mais grossa que a borda do sub-processo embutido, nada
mais do que isso.
A principal diferena de um sub-processo reusvel para um sub-processo
embutido, que o reusvel permite a criao de raias, uma vez que representa um
processo ou atividade independente do processo pai.

10
 Tarefa Inteira/Global Task - a definio de uma tarefa atmica e reusvel que
pode ser chamada de dentro de qualquer processo por meio de um Call Activity.

7.7. EVENTOS
Um evento algo que acontece durante o curso do processo afetando o fluxo do
mesmo. Usualmente tm uma causa ou um impacto e em geral requer ou permite uma
reao. O incio de uma atividade, o fim de uma atividade, a mudana de estado de um
documento, uma mensagem que chega, etc, todos podem ser considerados eventos.
Os eventos so divididos em eventos de incio, intermedirios e final e cada um
ser tratado individualmente.

Eventos de incio
1. No so obrigatrios, mas altamente indicados, principalmente em casos complexos ou onde
a condio de incio do processo no bvia.
2. Recomendamos a identificao dos eventos de incio com um substantivo. Ex: Solicitao de
Cotao.
3. Caso exista um evento de final, dever haver pelo menos um evento de incio.
4. Regra geral: todos os elementos que no tm um fluxo de entrada so instanciados junto com
o processo;
5. Podem haver vrios eventos de incio para um dado processo;
6. Podem ser usados em:
a. Processos de alto nvel;
b. Sub-processos embutidos (embedded);
c. Processo inteiro / Call Activity;
7. Evento Sub-processo4 deve ter um evento de incio.
8. Tipos de eventos de incio utilizados na padronizao esto destacados em
negrito:

1 - None - no tem nenhum gatilho definido (5.1, 5.2);

2 - Message - uma mensagem chega de um participante e aciona o incio do processo

(5.1);

3 - Timer - um momento ou ciclo especfico podem ser definidos para iniciar o processo
(5.1);

4 - Conditional - um condio pode ser definida para acionar o incio de um processo

(ex. temperatura acima de 300C) (5.1);

5 - Signal - um sinal chega de uma transmisso de um processo para iniciar outro

processo (5.1). No um message uma vez que este tem um alvo especfico. Vrios
processos podem ser iniciados de uma mesma transmisso de um nico sinal;

4 No suportado pelo Bizagi.

11
 6 - Multiple - h mltiplas formas para acionar um processo sendo que apenas uma
delas requerida (5.1);

7 - Parallel Multiple - h mltiplas formas para acionar um processo sendo que todas
elas so requerida antes de iniciar o processo (5.1);

Eventos de final
1. Indicam o final do processo;
2. Recomendamos a identificao dos eventos de final com um substantivo. Ex: Cotao Final,
Cancelamento, etc.
3. No tem qualquer fluxo de sada, ou seja, nenhum fluxo de sada pode se conectar a ele;
4. Responsvel por consumir um token que foi gerado por um evento de incio dentro do mesmo
nvel do processo.
5. Todos os tokens que foram gerados dentro de um processo devem ser consumidos por um
evento final antes do processo ser terminado.
6. Um processo pode ter vrios eventos de final apesar de este ser OPCIONAL;
7. Se existir um evento de incio deve haver ao menos um evento de final;
8. Se o evento de final no for utilizado, todos os elementos do fluxo que no tm sada marcam
o fim de um caminho do fluxo. No entanto, o processo dever finalizar quando todos os
caminhos paralelos forem completados;
9. Tipos de eventos de final utilizados na padronizao esto destacados em
negrito:

1 - None - no tem um resultado definido;

2 - Message - indica que uma mensagem enviando para um participante na

concluso do processo;

3 - Error - indica que um Erro deveria ser gerado. Todas as threads do procesos ou sub-
processo sero finalizados;

4 - Escalation - indica que uma Escalation deveria ser acionada. As outras threads
ativas no sero afetadas e continuaro a execuo. (Escalation um evento que
quando acontece, faz com que o prximo nvel mais alto de responsabilidade dever
ser envolvido). Ex: http://en.bpmn-community.org/tutorials/32/.

5 - Cancel - usado dentro de um Transaction Sub-Process indicando que a transao

deveria ser cancelada e acionar um Cancel Intermediate Event atachado borda do
Sub-Process.

6 - Compensation - indica que uma Compensation necessria. Compensation est

preocupado com as etapas de desfazer que j estavam concludos com xito, porque

12
 os seus resultados e efeitos colaterais possivelmente no so mais desejados e
precisa ser revertida. Se uma atividade ainda est ativa, ela no pode ser
compensada mas precisa ser cancelada.

7 - Signal - indica que um sinal ser transmitido quando o final tiver sido alcanado.
Lembre-se de que no uma mensagem pois esta tem um alvo especfico;

8 - Terminate - indica que todas as atividades no processo devero ser imediatamente

finalizadas;

9 - Multiple - significa que havero mltiplas consequncia de finalizao do processo.

Eventos intermedirios
1. Indicam que algo aconteceu entre o incio e final do processo;
2. So usados para:
i. Mostrar onde as mensagens so esperadas ou enviadas dentro do
processo;
ii. Mostrar atrasos que so esperados dentro do processo;
iii. Quebrar o fluxo normal por meio de manipulao de excees ou
iv. Mostrar os trabalhos extra necessrios para a Compensation;
3. Pode ser atachado em qualquer lugar da borda de uma atividade e o fluxo de sada pode fluir
para qualquer direo;
4. Existem duas formas de utilizar os 12 eventos intermedirios no BPMN:
i. Dentro do fluxo normal com um de dois propsitos:
1. responde captura de um gatilho de um evento;
2. pode ser usado para desligar o lanamento do gatilho de um evento;
ii. Atachado na borda de uma atividade:
1. usado para capturar o gatilho de um evento;
5. Para os eventos intermedirios colocados em fluxo normal, quando um token chega neste
evento, uma das duas coisas acontecem:
i. Se o evento usado para acionar um gatilho, este gatilho ocorrer
imediatamente e o token ser movido para a sada da sequncia do fluxo;
ii. Se o evento usado para capturar um gatilho, ento o token
permanecer no evento at o gatilho ocorrer. Em seguida, o token ser
movido para a sada da sequncia do fluxo;
6. Tipos de eventos intermedirios utilizados no fluxo normal e utilizados na
padronizao esto destacados em negrito:

1 - None - S vlido em fluxo normal e no pode ser colocado na borda de uma

atividade. Embora no exista especificado um gatilho para o evento, definido como

um evento de lanamento. So usados para modelar metodologias que usam eventos

para indicar alguma mudana de estado no processo.

13
 2 - Message - podem ser usados para enviar e receber mensagens. Quando usado
para lanar cartinha preenchida e quando usado para capturar, a cartinha no
preenchida;

3 - Timer - age como um mecanismo de atraso baseado em um date-time especfico ou

um ciclo especfico.

4 - Escalation - levanta uma Escalation

5 - Compensation - indica que uma Compensation necessria;

6 - Conditional - evento acionado quando uma condio retorna true;

7 Link
vlido somente em fluxo normal;
Eles no pode ser usados na borda de uma atiividade;
Um link um mecanismo responsvel por conectar duas sees de um processo;

8 - Signal - Usado para enviar e recener sinal;

Poder enviar e receber um Signal de um evento parte de um fluxo normal;
O evento s pode receber um signal quando atachado borda de uma atividade;
Quando usado para capturar o Signal o evento ter tringulo vazio e quando
usado para acionar um sinal, o tringulo ser um tringulo preenchido;

9 - Multiple - Significa que existem vrios gatilhos assinados para o evento. Se usado
dentro do fluxo normal, pode capturar ou lanar gatilhos. Quando atachado na borda
de um atividade, pode apenas capturar gatilhos. Quando usado para capturar gatilhos
apenas um dos gatilhos assinados REQUERIDO e o evento tem a marca de vazio.
Quando usado para acionar gatilhos, todos os gatilhos assinados devero ser
acionados e a marca preenchida.

10 - Parallel Multiple - Significa que existem vrios gatilhos assinados para o evento.
Se usado dentro do fluxo normal, pode apenas capturar gatilhos. Quando atachado na
borda de um atividade, pode apenas capturar gatilhos. Diferentemente do Multiple,
todos os gatilhos assinados so REQUERIDOS para o evento ser acionado.

7. Tipos de eventos intermedirios utilizados atachados s atividades e utilizados

na padronizao esto destacados em negrito:

14
Message - uma mensagem chega de um participante e aciona o evento. Se um
evento de mensagem atachada a borda da atividade, isso mudar o fluxo normal
para um fluxo de exceo que est sendo acionado. Para um evento de mensagem
que interrompe a atividade, a borda slida. Se no interrompe a atividade, a borda
e pontilhada.

Timer - um date-time especfico ou um ciclo podem ser definidos para acionar uma
evento. Se um evento de timer atachada a borda da atividade, isso mudar o fluxo
normal para um fluxo de exceo que est sendo acionado. Para um evento de timer
que interrompe a atividade, a borda slida. Se no interrompe a atividade, a borda
e pontilhada.

Escalation - evento usado para manusear uma Escalation. Se atachada na borda a

atividade, captura uma Escalation. Diferente de uma Error, por padro no aborta a
atividade a qual est atachada. No entanto, o modelador pode decidir alterar essa
definio:
Se interrompe a atividade, tem a borda slida;
Se no interrompe a atividade, tem a borda pontilhada;

Error - sempre interrompe a atividade a qual est atachado;

Cancel - usado dentro de um sub-processo Transaction atachado a borda do mesmo.

Sempre interrompe a atividade a qual est atachado.

Compensation - quando usada na borda de uma atividade, utilizada para capturar

um evento Compansation. Pode ser acionada depois que a atividade completada.
Assim, ela no pode interromper a atividade.

Conditional - evento acionado quando a condio (expresso) verdadeira. Se um

evento condicional atachada a borda da atividade, isso mudar o fluxo normal para
um fluxo de exceo que est sendo acionado. Para um evento condicional que
interrompe a atividade, a borda slida. Se no interrompe a atividade, a borda e
pontilhada.

Signal - pode receber um sinal quando atachado a borda de uma atividade. Se um

evento signal atachada a borda da atividade, isso mudar o fluxo normal para um
fluxo de exceo que est sendo acionado. Para um evento signal que interrompe a
atividade, a borda slida. Se no interrompe a atividade, a borda e pontilhada.

Multiple - indica que tem mltiplos gatilhos assinados ao evento. Quando atachado a
borda de uma atividade o evento pode apenas captura o gatilho. Neste caso apenas
um dos gatilhos assinados precisa ser REQUERIDO e o evento ser acionado,
mudando o fluxo normal para um fluxo de exceo. Para um evento multiple que
interrompe a atividade, a borda slida. Se no interrompe a atividade, a borda e
pontilhada.

15
Parallel Multiple - indica que tem mltiplos gatilhos assinados ao evento. Quando
atachado a borda de uma atividade o evento pode apenas captura o gatilho.
Diferente do Multiple, todos os gatilhos assinados so REQUERIDOS para o evento
ser acionado. Para um evento parallel multiple que interrompe a atividade, a borda
slida. Se no interrompe a atividade, a borda e pontilhada.

7.8. GATEWAYS
So usados para controlar como o fluxo de sequncia seguir seu caminho
(convergncias e devergncias). Se no h a necessidade de controlar o fluxo, nenhum
gateway necessrio. Ele funciona como um mecanismo de porta que permite ou no a
passagem do token por um determinado caminho.
Os gateways, como as atividades, so capazes de consumir ou gerar tokens
adicionais, efetivamente controlando a execuo semntica de um dado processo. A
principal diferena que os gateways no representam trabalho sendo feito e devem ser
considerados como no tendo nenhuma influncia sobre as medidas operacionais do
processo (tempo, custo, etc).
Gateways podem definir todos os tipos de comportamento do fluxo de trabalho,
decises/ramificaes (exclusivas, inclusivas e complexas) e fuses/junes.
Embora a forma do Gateway seja um lozango, no h obrigatoriedade de que as
entradas e sadas sejam em seus cantos, apesar do Bizagi Modeler obrigar.
Eles podem ter 0, 1 ou mais entradas do fluxo de trabalho. Se um gateway no
possui entrada e no existe um evento de incio para o processo, ele deve ser executado
quando o processo for instanciado. Alm disso, eles podem ter 0, 1 ou mais sadas. No
entanto, um gateway deve ter ou mltiplas entradas ou mltiplas sadas.
Tipos de gateways utilizados na padronizao esto destacados em negrito:

Exclusivo - usado para criar caminhos alternativos exclusivos

dentro do fluxo de trabalho. Neste instante, apenas um caminho poder ser
seguido. o que chamamos de um momento de deciso.
Uma deciso pode ser evidenciada quando h um questionamento em um
ponto do processo. Cada resposta associada a este questionamento poder ser
uma sada para o fluxo de trabalho.
O gateway exclusivo tem duas formas, no entanto, recomenda-se
que quando se opta por uma, esta dever ser utilizada at o final, no podendo
haver variaes.
Um caminho padro poder, opcionalmente, ser identificado para que,
caso nenhuma das condies seja verdadeira, o processo possa seguir esse
caminho ou haver um erro de execuo.

Inclusivo - usado para criar caminhos alternativos que podem ser paralelos
dentro do fluxo de trabalho. As condies de evoluo no so excludentes, logo,
todas as condies verdadeiras sero atravessadas pelo token. Assim todos os
caminhos so considerados independentes e todas as combinaes podero
existir, de zero a todas.

16
 Um caminho padro poder, opcionalmente, ser identificado para que, caso
nenhuma das condies seja verdadeira, o processo possa seguir esse caminho ou
haver um erro de execuo.

Paralelo - usado para combinar e criar fluxos paralelos. Os caminhos

paralelos so criados sem checar qualquer condio e cada sada recebe um
token. Para o fluxo de entrada, o gateway aguardar por todos os tokens de
entrada, antes de acionar a continuao do fluxo de trabalho.

Complexo - usado para modelar o sincronismo de comportamentos

complexos. Uma expresso usada para descrever o comportamento preciso. Ex:
a expresso pode definir que de cinco entradas do gateway, so necessrias pelo
menos trs para que seja acionado o fluxo de sada do gateway.

Baseado em evento - representa um ponto de ramificao no processo

onde os caminhos alternativos que seguem o gateway so baseados em eventos
que ocorrem.
Um evento especfico, usualmente o receptor de uma mensagem,
determina o caminho que ser seguido. Basicamente, a deciso feita por um
outro participante, baseado em dados no visveis ao processo.
Por exemplo, uma companhia que est aguardando a resposta de um
cliente e executar um grupo de atividades se a resposta for sim e outro grupo
de atividades for no. Vale ressaltar que neste caso, no a mesma mensagem
com diferentes valores, mas mensagens distintas. Neste caso, a resposta do
cliente determina o caminho a ser seguido.

7.9. ITEMS E DADOS

Uma necessidade normal da modelagem de processos a representao dos itens
(fsicos e informaes) que so criados, manipulados e usados durante a execuo do
processo.

Objetos de dados
a representao de documentos e formulrios que so usados e atualizados
durante a execuo do processo. Podem ser referncias a documentos fsicos ou
eletrnicos.
Podem estar contidos em processos e sub-processos.

Elemento nico Coleo de Elementos

O ciclo de vida de um objeto de dados est amarrado ao ciclo de vida do processo
ou sub-processo. Quando um processo ou sub-processo instanciado, todos os objetos
de dados contidos dentro dele tambm so instanciados. Quando uma instncia de um
processo ou sub-processo eliminada, todos os objetos de dados contidos nele tambm
so eliminados. Nesse ponto os dados dentro da instncia no esto disponveis.

17
 A acessibilidade dos objetos de dados dirigida pelo ciclo de vida do processo ou
sub-processo e os dados dentro do objeto de dados s podem ser acessados quando
existe a garantia da instncia do objeto de dados.

Armazenamento de dados
Prov um mecanismo para as atividades recuperarem ou atualizarem informaes
armazenadas que persistiro alm do escopo do processo.

8. REGRAS DE MODELAGEM

11.1. Processo Completo

11.1.1. Segue abaixo, ilustrao de um processo completo:

11.1.2. uma modelagem analtica do processo que proporciona uma viso de todo
o fluxo de trabalho do incio ao fim.
11.1.3. O processo dever estar contido em uma nica piscina e esta piscina ter
como ttulo o nome do processo, em caixa alta.
11.1.4. Aps a titulao do processo, agora devemos identificar todos os
participantes do processo. Para cada participante, inserir uma raia na piscina,
se possvel, seguindo a ordem cronolgica das atividades dentro do processo.

18
 Vale ressaltar que para cada participante haver somente uma raia.
11.1.5. Cada raia tambm dever ser identificada com um papel, sistema,
departamento, etc. A raia no pode ser identificada com o nome prprio de
uma pessoa.
11.1.6. Os ttulos das raias devero seguir a seguinte regra:
a) Caso tenha apenas uma linha, a linha ter a primeira letra em caixa alta (maisculo) e o
restante em caixa baixa (minsculo);
b) Caso tenha mais de uma linha:
1 linha ficar em caixa alta (maisculo);
2 linha ter a primeira letra em caixa alta (maisculo) e o restante em
caixa baixa (minsculo);
11.1.7. Identificadas as raias, agora o momento de inserir o evento de incio em
todas as raias onde o processo poder ser iniciado e comear a modelagem.
11.1.8. Formatao do fluxo de atividades:
a) Sempre desenhar os fluxos em sentido temporal, da esquerda para a direita. Em casos
excepcionais, como exemplo, o retorno de algumas atividades para reviso, admite-se o fluxo
da direita para a esquerda.

SENTIDOTEMPORAL
b) Evento de incio e final:
Incio: a esquerda da atividade.

Final: a direita da ltima atividade.

c) Objetos de conexo entre atividades

Sada: a seta sair do lado direito da atividade. Em casos excepcionais,
para maior harmonia do desenho, pode sair das outras extremidades.
Entrada: a seta entrar pela lateral esquerda da atividade. Em casos
excepcionais, para maior harmonia do desenho, pode entrar pelas
outras extremidades.

19
d) Objetos de conexo nas decises
Entrada: sempre que possvel entrar pelo vrtice esquerdo da deciso.
Sada: sempre que possvel, sair do vrtice inferior e superior da
deciso. Em caso de trs decises, sair tambm pelo vrtice direito da
deciso. Alm de trs decises, fica a critrio do modelador decidir.

e) Alinhamento dos elementos

Sempre que possvel, alinhar os elementos horizontalmente, tendo
como referencial o centro da raia.

Sempre que possvel, as atividades que saem das decises devem

estar dispostas paralelamente e alinhadas verticalmente.

20
 11.1.9. Existem situaes em que necessrio representar uma atividade ou
subprocesso externo ao processo que est sendo modelado. Para estes casos,
o elemento que representa a atividade ou sub-processo externo deve ser
colorido com a cor preta e o texto com a cor branca, conforme representado
abaixo:

importante salientar que esta atividade ou sub-processo externo

representado desta forma, uma vez que no so conhecidos e nem mesmo
analisados para a realizao da modelagem. Enfim, no faz parte do escopo
da modelagem em questo.

11.1.10. Sugestes de particionamento do diagrama completo

a) Concluda a modelagem, caso o processo seja muito extenso, sugerese separar atividades
sequenciais que esto dentro de um mesmo contexto/assunto, distinguindo-as com cores e
chamando-as de etapas do processo.
b) Sempre que possvel, sugere-se iniciar e finalizar cada etapa apenas com atividades,
evitando que ela inicie ou finalize em uma tomada de deciso (gateway).
c) As etapas que compem o diagrama completo devero seguir a sequncia de cores,
conforme paleta de opes do Bizagi. Sempre ser selecionada a tonalidade mais clara de
cada cor, iniciando pela 3 (terceira) coluna de cores, ignorando a quinta coluna pela
similaridade com a quarta, e indo at a ltima coluna de cores, no caso dos processos com
at sete etapas.
d) Cada diagrama completo dever conter no mximo sete etapas. Conforme j mencionado,
importante que cada etapa contenha atividades de mesmo contexto, para facilitar o
entendimento sequencial e lgico do processo como um todo.

21
e) Todos os outros elementos (eventos e gateways) contidos no diagrama completo mantero
suas cores padro.
11.1.11. A definio do caminho feliz uma prtica que pode ser realizada durante
a modelagem do fluxo de trabalho ou aps a concluso do mesmo. O caminho
feliz a rota dentro do fluxo de trabalho que dever ser percorrida quando no
ocorre nenhuma exceo e o objetivo principal do processo atingida;
11.1.12. Cadastre os executores/performers.

11.2. Macroprocesso
11.2.1. Segue abaixo, ilustrao de um macroprocesso que possui sete
subprocessos (etapas):

11.2.2. O macroprocesso uma modelagem descritiva do processo, que proporciona

uma viso resumida do diagrama completo.
11.2.3. O macroprocesso dever estar contido em uma nica piscina sem raias e
esta piscina ter como ttulo o nome do processo, em caixa alta.

22
 11.2.4. Assim como em uma modelagem analtica, o macroprocesso tambm ter
os eventos de incio e final.
11.2.5. Cada sub-processo contido no macroprocesso representar uma etapa
definida no diagrama completo, inclusive recebendo a mesma cor definida
para a etapa.
11.2.6. Cada macroprocesso dever conter um sub-processo isolado na parte
superior direita da piscina, representando o diagrama analtico completo do
processo em questo.
11.2.7. O sub-processo que representa o diagrama analtico completo ter a cor
mais clara da primeira coluna da paleta de cores do Bizagi.
11.2.8. Todos os sub-processos do macroprocesso devem ser configurados para o
tipo reutilizvel, Reusable Subprocess. Somente com esta configurao,
possvel desenhar o detalhamento do sub-processo contendo piscinas e raias,
caso absolutamente necessrio a esta padronizao.

11.3. Sub-processo
11.3.1. Segue abaixo, exemplo ilustrativo do detalhamento de um sub-processo:

11.3.2. O nome do sub-processo comear sempre com um substantivo. Ex:

Autuao, Identificao, Homologao, etc.
11.3.3. O detalhamento de um sub-processo a modelagem analtica de uma etapa
do processo completo.
11.3.4. Todas as atividades do detalhamento de um sub-processo tero a mesma
cor do sub-processo em questo.

23
 11.3.5. Assim como no diagrama completo, os gateways, eventos e objetos de
conexo permanecero com a cor padro definida pelo Bizagi.
11.3.6. Os artefatos (objetos de dados, grupos e anotaes) no sero desenhados
nos diagramas analticos. Tais informaes sero inseridas nas propriedades
dos elementos, no intuito de deixar o desenho menos poludo e
consequentemente, facilitar a leitura do mesmo.
11.3.7. O ttulo da piscina que conter o sub-processo ter o seguinte formato:
a) 1 linha ter o nome do processo em caixa alta (maisculo);
b) 2 linha ter o nome do sub-processo, sendo a primeira letra em caixa alta
(maisculo) e o restante em caixa baixa (minsculo); 11.3.8.
Os ttulos das raias devero seguir a seguinte regra:
a) Caso tenha apenas uma linha:
a linha ter a primeira letra em caixa alta (maisculo) e o restante em caixa
baixa (minsculo);
b) Caso tenha mais de uma linha:
1 linha ficar em caixa alta (maisculo);
2 linha ter a primeira letra em caixa alta (maisculo) e o restante em caixa
baixa (minsculo);
11.3.9. Cada sub-processo detalhado conter apenas as raias que efetivamente
tiverem alguma atividade participante no mesmo, alm das raias onde estaro
representados os sub-processos resumidos (contrados).
11.3.10. Todos os diagramas de detalhamento de sub-processos tero os eventos de
incio e final.
11.3.11. Para cada detalhamento de um sub-processo, todos os outros subprocessos
devero ser representados de resumida (contrada), conforme o
macroprocesso, inclusive respeitando a sequncia lgica, bem como as cores,
para que se tenha uma ideia do contexto geral e tambm da parte que est
sendo representada.
11.3.12. Todos os sub-processos resumidos desenhados dentro de um subprocesso
detalhado devero ser do tipo reutilizvel, Reusable Subprocess, permitindo
assim, que se navegue entre os sub-processos.
11.3.13. Na modelagem do sub-processo detalhados, o sub-processo resumido deve
estar localizado na raia onde sua primeira atividade estiver localizada. Por esse
motivo, existe a recomendao do item 8.1.10.b, para evitar que um sub-
processo resumido tenha que ser representado mais de uma vez em um sub-
processo detalhado.

24
6. REGRAS DE DOCUMENTAO
A modelagem de um diagrama, mesmo que utilizando a notao BPMN, normalmente
no suficiente para descrever todos os detalhes que envolvem uma sequncia de
tarefas que compem um processo.
Por isso, alm dos recursos de modelagem do fluxo de trabalho, o Bizagi disponibiliza
uma srie de recursos teis para a documentao de um processo. Logo, poderemos
representar documentos envolvidos nas atividades, tabelas de regras de negcio,
controle de tempo de execuo, alm de vrios outros recursos documentais.
Na parte inferior da interface do Bizagi Modeler existe o painel de Propriedade dos
Elementos. Este painel utilizado para otimizar o trabalho de documentao de todos
os elementos constantes em um diagrama, bem como o fluxo como um todo. Para se
ter acesso s propriedades de um elemento, basta clicar com o boto direito do mouse
sobre o elemento e selecionar a opo Propriedades. Para acessar as propriedades de
um diagrama, basta clicar com o boto direito em qualquer espao vazio do mesmo e
selecionar a opo Propriedades do diagrama.
O painel de propriedade dos elementos dividido em guias conforme descrio abaixo:

12.1. Documentao Bsica

Contm informaes bsicas referentes a cada elemento do diagrama.
6.1.1. Nome e Descrio: so as duas propriedades comuns a todos os elementos
que compem um diagrama. O nome refere-se ao texto explcito em cada
elemento, j a descrio um campo disponvel para a insero de
informaes detalhadas e outras consideraes.
Em nvel de diagrama, recomenda-se colocar uma descrio resumida, at 125
caracteres, preferencialmente, o escopo daquela modelagem. Isso refletir na
interface onde so visualizados todos os diagramas do modelo, para se ter
uma descrio resumida de cada perspectiva.
Em nvel de sub-processo, recomenda-se utilizar o campo de descrio para
detalhar o escopo envolvido.
Em nvel de atividade, recomenda-se elaborar uma descrio mais sucinta
abordando detalhes a serem considerados.
6.1.2. Performances: permite documentar todos os participantes de uma atividade
ou sub-processo;
6.1.3. Processo: propriedade disponvel apenas para os sub-processos e permite
configurar qual diagrama tal sub-processo est representando;

25
 6.1.4. Verso: propriedade disponvel apenas para os diagramas e permite realizar
um controle de verso da evoluo dos diagramas dentro de um modelo;
6.1.5. Autor: propriedade disponvel apenas para os diagramas e permite fazer uma
referncia ao autor do diagrama dentro de um modelo;
6.1.6. Temporizador: propriedade disponvel apenas para os eventos de timer e
permite configurar o(s) momento(s) em que o evento ser acionado;

12.2. Documentao Estendida

Conforme necessrio, cria uma variedade de atributos adicionais para cada
elemento do processo, para produzir uma documentao mais detalhada.
importante ressaltar que, uma vez criado um atributo estendido para um
elemento, este mesmo atributo estar disponvel para todos os elementos de
mesmo tipo. Por exemplo: Caso seja inserida uma propriedade de data para uma
atividade do diagrama, todas as outras atividades de mesmo tipo tero esta mesma
propriedade.
Apesar dessa propriedade ser replicada para todos os elementos de mesmo
tipo, tanto no modo de apresentao do Bizagi quanto em qualquer formato de
publicao, este atributo somente ser demonstrado caso seja utilizado
(preenchido) durante o trabalho de documentao de um processo.
Em nvel de diagrama, estas informaes no aparecero na publicao feita para a
Web, apenas em arquivos DOC ou PDF.
Abaixo esto descritos todos os tipos de propriedades estendidas que podero
ser atribudas aos elementos:
9.2.1. rea de texto: armazena aproximadamente 32.000 caracteres e
apresenta textos longos com quebra de linhas.
Adotaremos este atributo como o campo ideal para inserir observaes, outras
consideraes relevantes para um elemento, regras, check-lists, produtos de
trabalho e competncias necessrias para executar uma atividade.
9.2.2. Caixa de texto: armazena aproximadamente 32.000 caracteres e apresenta
textos curtos sem quebra de linhas;
9.2.3. Nmero: armazena nmero. Deve ser definida uma faixa de mnimo e
mximo permitido.
Adotaremos este atributo como o campo ideal para indicar a durao de uma
atividade.
9.2.4. Data: armazena data;
Uma das sugestes feitas na documentao do Bizagi utilizar este atributo
para registrar a ltima atualizao realizada em uma atividade.

26
 9.2.5. Imagem: armazena imagens com extenso jpg, bmp, png e gif;
9.2.6. Opo de seleo nica (kit): permite definir vrias opes a serem
escolhidas, mas apenas uma das opes da lista pode ser selecionada;
9.2.7. Opo de seleo nica (rdio): permite definir vrias opes a serem
escolhidas, mas apenas uma das opes de checagem pode ser selecionada;
9.2.8. Opes de mltipla escolha: permite definir vrias opes de escolha e
permite selecionar uma ou mais caixas destas opes;
9.2.9. Integrado: permite anexar arquivos nos elementos a fim de ficarem disponvel
no modelo. O arquivo copiado para um diretrio do modelo;
9.2.10. Linkado: permite incluir um link ou caminho para um arquivo. O modelo
armazena um link para o arquivo, no o arquivo em si.
Pode ser utilizado tanto o caminho relativo quanto o caminho absoluto para
arquivo linkado;
9.2.11. URL: armazena um link para um recurso da internet;
Adotaremos este atributo como o campo ideal para criar um hiperlink com
algum site que tenha estreita relao com a execuo da atividade que est
sendo documentada.
9.2.12. Table: permite construir uma tabela, incluindo qualquer recurso mencionado
acima;
Adotaremos este atributo como o recurso ideal para demonstrar, de forma
matricial, as opes que compem uma regra de negcio.

12.3. Documentao Avanada

Aplica atributos da notao BPMN especficos para cada elemento do fluxo.
No utilizaremos este recurso para a padronizao da documentao presente nos
fluxos de trabalho

12.4. Documentao Acionada na Apresentao

Define o que ser mostrado no modo de Apresentao do Bizagi.
Neste manual de padronizao, sugere-se o uso deste recurso apenas em nvel de
atividade dentro de um processo ou sub-processo, para realizar a abertura de um
arquivo, uma imagem ou uma URL que tenha alguma relao com a atividade em
questo.

27
10. PUBLICAR OU EXPORTAR?
Em muitas situaes surge a dvida entre publicar ou exportar um processo que foi
modelado no Bizagi Modeler. Logo, existe uma distino muito grande entre as duas
opes, conforme ser descrito abaixo:
Publicar esta opo deve ser utilizada quando h o interesse em compartilhar com
toda a organizao e os clientes externos, o fluxo de trabalho, bem como toda a
documentao inerente aos elementos que compem tal fluxo.
Exportar esta opo deve ser utilizada quando h o interesse em migrar o fluxo do
processo para outra ferramenta de modelagem como o Visio. Alm disso, possvel
exportar atributos customizados para serem reutilizados em outro Bizagi Modeler.
Por fim, possvel exportar o fluxo para um formato de imagem. Neste caso,
diferentemente da publicao, apenas o desenho do fluxo est sendo gerado, logo,
nenhuma documentao estar vinculada ao arquivo de imagem.

11. REGRAS DE PUBLICAO

Depois de concluda a modelagem e documentao de um processo, pode haver a
necessidade de tornar todo este trabalho pblico.
Para isso, o Bizagi possui alguns recursos de publicao que viabilizam gerar toda a
modelagem e documentao em formato de texto editvel (DOC), em formato de texto
no editvel (PDF), em formato de ferramenta de colaborao (Wiki), em formato Web e
por fim, para o Sharepoint, ferramenta de compartilhamento de informaes da
Microsoft.
O foco deste manual padronizar as publicaes em formato DOC, PDF e Web.
importante esclarecer que, com relao publicao nos formatos DOC e PDF, ser
gerado apenas um arquivo no padro Word e Acrobat Reader respectivamente. No
entanto, para o formato Web ser gerada uma pasta contendo toda a estrutura de
arquivos necessria para a perfeita execuo no ambiente Web. Esta estrutura no
poder ser alterada.

14.1. Publicao DOC/PDF

Etapa1
Na guia Publicar, selecione o boto correspondente ao formato que se deseja gerar a
publicao.

28
Conforme ilustrao abaixo, primeiramente envie para a caixa da direita todos os
diagramas que se deseja publicar. Em seguida, usando as setas na vertical, organize os
diagramas para que sejam publicados conforme a ordem desejada. Por fim, clique no
boto Seguinte.

Etapa 2
Na prxima janela, conforme ilustrao abaixo, existe uma lista retrtil (combo)
localizada na parte superior da janela. Neste campo esto contidos todos os diagramas
que sero publicados. Selecione um por vez e na parte inferior da janela, envie para a
caixa da direita todos os elementos que se deseja publicar do diagrama em questo.
Neste manual de padronizao, sugere-se publicar apenas as atividades de cada
diagrama, uma vez que a documentao dos fluxos normalmente est associada s
atividades. Caso haja alguma documentao associada a algum outro elemento,
sugerese a publicao deste elemento tambm.
No caso do diagrama do macroprocesso, sugere-se publicar todos os sub-processos. Caso
exista a necessidade de publicar todos os elementos de todos os diagramas, basta clicar
no boto apontado no passo 3. Caso seja uma publicao personalizada onde nem todos
os elementos sero publicados, basta executar o passo 1 e passo 2 para cada diagrama
e por fim, clicar no boto Seguinte.

29
Etapa 3
Na janela seguinte, basta selecionar o modelo do documento que ser gerado. Neste
manual de padronizao sugerimos a opo ModelerTemplate.dot. A partir de ento,
clique no boto Seguinte.

Etapa 4
Na ltima janela do passo-a-passo para a publicao, selecione a orientao do papel
onde sero gerados os diagramas. Neste manual sugerimos a orientao retrato. Por fim,
selecione o diretrio onde ser gerado o documento da publicao e clique no boto
Concluir.
Vale ressaltar que o resultado da publicao, tanto para DOC quanto para PDF, ser o
mesmo. O que diferencia neste caso apenas o formato do arquivo.

14.2. Publicao Web

30
 Na guia Publicar do Bizagi Modeler, selecione o boto corresponde ao formato que se
deseja gerar a publicao.
Em seguida, basta seguir as etapas 1 e 2 das regras de publicao para o formato
DOC/PDF. A nica diferena que, na publicao para o formato Web, na etapa 2, basta

clicar no boto Selecionar todos os diagramas e seus elementos para exportar,

uma vez que todos os elementos de todos os diagramas sero publicados. A ltima
etapa do trabalho de publicao para o formato Web solicita o diretrio onde ser salva a
pasta a ser publicada.
Informe o diretrio e por fim, basta clicar no boto Concluir para efetivar a publicao.
Conforme j mencionado anteriormente neste manual, o diretrio gerado aps a
concluso da publicao Web no poder ser alterado, uma vez que existe uma srie de
dependncias entre os objetos contidos nele.

12. REGRAS DE EXPORTAO

Para este manual, explicaremos apenas a opes de exportao para um arquivo de

imagem.
Logo, no guia Exportar/Importar do Bizagi Modeler, selecione o boto correspondente
ao formato que se deseja gerar a exportao.
Por fim, selecione o diretrio onde ser gerado o arquivo de imagem, d um nome para o
arquivo e selecione o tipo da imagem que ser gerada, podendo ser PNG, JPG, BMP e
SGV. Clique no boto Salvar para concluir a operao.

13. SIMULAO
Simulao uma ferramenta que avalia a execuo de um modelo, sob vrias
configuraes e baseado em um longo perodo de tempo real, para reduzir as chances de
falha diante das especificaes, eliminando gargalos imprevistos, prevendo sub ou sobre
utilizao de recursos (incluindo pessoas e dinheiro), alm de otimizar a performance de
aplicaes.
Simulao requer um claro objetivo para obter o mximo de esforo desejado. Esse
objetivo influencia fortemente o nvel de detalhes nos dados requeridos.

31
 Simulao no Bizagi permite o aprimoramento dos modelos do processo de negcio
construdos no BPMN e suporta rigorosos mtodos de anlises.
O que simulao:
a aleatoriedade simulada atravs da utilizao de probabilidades para os fluxos
de sequncia e de encaminhamento de token e tambm pela utilizao de distribuies
estatsticas para refletir a variabilidade nos tempos de processo das atividades. Para
garantir que os resultados sejam vlidos, necessrio que as simulaes sejam
executadas por um tempo suficiente para produzir um comportamento aleatrio, com a
mnima possibilidade de erros. Comparaes
Simulaes so muito conhecidas por prover a capacidade de anlise What-if; uma
simples simulao executada poder prover uma variedade de conhecimento na
execuo de um cenrio particular. A simulao de vrios cenrios e a possibilidade de
comparar sadas chave, agrega valor e suporte tomada de deciso.
16.1. Simulao no Bizagi

Para criar um cenrio ideal para o procedimento de simulaes no Bizagi,

importante que o diagrama do processo j esteja completo, caso contrrio, a
sada poder no ser confivel.
Recomenda-se seguir os quatro nveis de simulao, um aps o outro. Casa
subsequente nvel incorpora informaes adicionais que adicionaro mais
complexidade, provendo uma anlise coerente do processo. Os nveis no so
interdependentes, isso significa que possvel iniciar a simulao em qualquer
nvel, bastando ter em mos os dados requeridos.
Para cada nvel de simulao siga os seguintes passos:
- Colete os dados do processo para a simulao;
- Adicione os dados ao diagrama;
- Execute a simulao;
- Interprete e apresente as sadas;

16.2. Definindo as propriedades do cenrio

Depois e clicar no boto Simulation View, o diagrama ser apresentado em
modo somente leitura. Para cada nvel de simulao, os elementos que requerem
informaes sero destacados.

O primeiro passo definir as propriedades do cenrio. As principais informaes

a serem definidas so: nome, durao, a unidade de medida do tempo, a unidade

32
 monetria e o nmero de replicaes. Recomenda-se o nmero de 30 replicaes
para garantir que a simulao alcanar um estado estvel.
Depois de inseridos os dados solicitados, salve as informaes da simulao e em
seguida basta executar a simulao.

Na janela seguinte, inicie a execuo da simulao.

16.3. Nveis de simulao

a. Nvel 1 (Validao) o primeiro e mais bsico nvel de simulao avalia a estrutura do
diagrama do processo;
Dados solicitados: a quantidade de instncias a serem analisadas e o
percentual estimado em cada caminho de deciso (gateway);
Resultado: mostra todos os caminhos ativos durante a execuo, e se todos os
tokens iniciados foram finalizados. Alm disso, avalia quantos tokens
passsaram atravs de cada fluxo de sequncia, atividade e evento.
- Mostra se os gateways esto sincronizados;
- Mensagens esto sincronizadas;
- Probabilidades das decises esto corretamente atribudas;
- Comportamento da rota o esperado;

33
b. Nvel 2 (Tempo) o segundo nvel mede o tempo do processo fim-a-fim; Dados solicitados:
alm dos dados do nvel 1, solicita o intervalo de tempo para a gerao de cada token e o
tempo estimado para cada atividade. Esses dados podem ser constantes ou representados
por meio de distribuio estatstica;
Resultado: mostra o tempo de execuo do processo, apresentando o tempo
mnimo, mximo, mdio e a soma total de todo o processo. O resultado
apresentado para cada atividade individualmente tambm.
Obs: como houve a definio da durao do processo nas propriedades do
cenrio, a simulao ser concluda para a situao que ocorrer primeiro:
quando alcanar o nmero de instncias definidas ou quando atingir o tempo
de durao da simulao.

34
c. Nvel 3 (Recurso) o terceiro nvel prev como o processo ser executado com diferentes
nveis de recurso, provendo uma estimativa confivel de como o processo se comportar em
operao. Vale ressaltar que os recursos podero ser pessoas, equipamentos, materiais,
espaos para a execuo de uma tarefa especfica, etc.
Dados solicitados: alm dos dados dos dois primeiros nveis, neste nvel
necessrio o cadastramento dos recursos e/ou papis: quantos estaro
disponveis e onde sero utilizados. Devido a incluso dos recursos, talvez o
tempo da atividade dever ser ajustado para representar o tempo de trabalho
atual. Atrasos devido a indisponibilidade de pessoal sero explicitamente
indicado. Os custos de cada recurso tambm so inseridos neste nvel.
Resultado: mostra o tempo de cada recurso gasto ocupado e ocioso bem como
o custo de cada recurso e do processo como um todo.
- Mostra sub ou sobre utilizao de recursos;
- Mostra o custo total dos recursos;
- Mostra custo total das atividades;
- Mostra atrasos (tempo que uma atividade aguarda por um recurso);
- Mostra o ciclo de execuo mais preciso;

35
i. Cadastrando os recursos

1 - cadastramento dos recursos;

2 - definio da quantidade de recursos disponveis;
3 - definio do custo de cada recurso. Os custos dos recursos podero
ser definidos como custos fixos ou por hora trabalhada.

36
 ii. Associando os recursos s atividades

Obs: as opes AND e OR definem se os recursos sero requeridos pela

atividade ao mesmo tempo ou um de cada vez.

iii. Definind o o custo da atividade

d. Nvel 4 (Calendrio) o quarto nvel inclui informaes do calendrio que

refletem a execuo do processo sobre perodos dinmicos de tempo, tais
como mudanas, dias e semanas programas, feriados e outros tempos de

37
restrio. Por padro o Bizagi inclui um calendrio que trabalha 24/7. Se
nenhum calendrio for definido, o Bizagi assumir este calendrio.
Dados solicitados: alm dos j informados, inclui a definio do recurso de
calendrio.
Resultados: similar a anlise de recursos.
i. Cadastrando os calendrios

Para cada calendrio criado dever ser definido o nome, o horrio de

incio e a durao. Tambm ser definido o padro de trabalho e a faixa de
recorrncia. ii. Atribuindo calendrios aos recursos

38
16.4. Criando novos cenrios
O Bizagi permite criar vrios cenrios para seu processo, permitindo
analisar diferentes combinaes de entradas e sadas de dados possveis. Os
cenrios so completamente independentes um do outro. Vale ressaltar que o
Bizagi j trs um cenrio padro que poder ser customizado, conforme
demonstrado anteriormente.

Os novos cenrios podero ser criados a partir de um cenrio j existente ou

criados do zero, sem nenhuma referncia.

39
 16.5. Anlis e What fI

uma poderosa ferramenta para melhoria de processos que avalia como

mudanas operacionais e tticas podero impactar no negcio. Por meio de
vrios cenrios voc estar apto a realizar anlises de seus processos sem
colocar a operao do negcio em risco.
Bizagi permite executar facilmente a anlise What If nos processo para
avaliar, entender e prever os efeitos de uma deciso em uma determinada
situao.
Logo, ser possvel responder:
Qual ser o decrscimo de tempo se o nmero de recursos disponveis dobrar?
Qual ser o custo/benefcio se for reduzido o tempo de execuo de uma atividade especfica?

40
 Qual seria o efeito de alterar a configurao do turno de trabalho no custo operacional e nvel
de servio?
O relatrio gerado pela anlise mostrar o resultado de todos os cenrios
para serem facilmente comparados.
Recomenda-se comparar dois cenrios por vez para evitar anlises muito
complexas.

41