> For the complete documentation index, see [llms.txt](https://kb.stoque.com.br/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kb.stoque.com.br/zeev/como-construir-processos/como-desenhar-processos/boas-praticas-de-desenho.md).

# Boas práticas de desenho

Compartilhamos aqui algumas boas práticas de desenho de processos, aprendidas ao longo de alguns anos com os clientes da Zeev, e também compartilhadas pelo mercado em geral.

## Manter espaçamento adequado

Em algumas situações modeladores buscam reduzir ao máximo o espaçamento entre os elementos, tentando que o processo teoricamente caiba em uma única folha A4 quando impresso, ou que caiba no monitor sem nenhum tipo de *scroll*. 

Esses possíveis benefícios são superados pelos problemas que podem causar. No Zeev, o objetivo principal é a automação do processo, é transformar o processo em uma aplicação. No longo prazo, para que uma aplicação se sustente, é preciso evoluir e dar manutenção no processo. E, para isso, facilita e ajuda muito um desenho claro, espaçado e que permita a leitura fácil e a inclusão de novos elementos de maneira prática.

Veja o exemplo abaixo de um processo com pouco ou nenhum espaçamento entre os elementos:

![](/files/S5Nm2yM342AncCRAQG1Q)

A dica é usar e abusar dos espaços, pois o ambiente de desenho cresce indefinidamente e não existe limite para o tamanho do processo. Quanto mais espaço você der, mas fácil será a leitura e entendimento do processo, por você ou por um colega, no futuro.

![](/files/t3GrLAcDf129w2jGcjKx)

## Utilizar eventos de link para retornos

Em muitas abordagens de modelagens, usa-se como boa prática, toda a vez que for representar uma volta a um passo anterior do processo, usar um [evento de link](/zeev/como-construir-processos/como-desenhar-processos/como-usar-eventos/como-configurar-links.md).  

Veja o exemplo abaixo. Após a tarefa "Revisar", existe uma conexão com a tarefa "Aprovar".

![](/files/dyriAfN5LbedzMr6JErk)

Essa conexão poderia ser substituída por eventos de link.

![](/files/xqYPJ6nH7pNPogItyam1)

Utilizar eventos de link evita um resultado final conhecido como "processo macarrônico" ou "*spaghetti process*", processo onde o número de conexões entre os elementos é tão grande que torna impossível interpretar o desenho. Veja um exemplo abaixo.

![https://www.researchgate.net/figure/Excerpt-of-a-typical-Spaghetti-process-model-ca-20-of-complete-model\_fig1\_221586306](/files/geSZPMFohqSzTeL4eEJe)

## Padrões de nomenclatura

As nomenclaturas dos elementos do processo devem ser bem definidas porque elas serão interpretadas por outras pessoas, podendo facilitar ou complicar o dia a dia dos atores do seu processo. Por isso, sua padronização é extremamente importante, podendo gerar os seguintes benefícios:

* Garante uma boa forma de criar um processo;
* Não engessa, mas contribui definindo um ponto de partida e alcançando melhores resultados;
* Facilita o entendimento dos processos do seu início ao fim;
* Padroniza o uso dos elementos garantindo resultados planejados;
* Gera serviços e produtos com alta qualidade;
* Promove economia de tempo e produtividade na reanalise da modelagem.

### Padrão de codificação dos elementos

{% tabs %}
{% tab title="Eventos" %}

<table><thead><tr><th width="124.33333333333334">Elemento</th><th width="122">Sigla</th><th>Exemplo</th></tr></thead><tbody><tr><td><img src="/files/MVwzhHl6BMRG4H1P64cz" alt=""></td><td>Sem sigla</td><td>Ex: Solicitar cadastro de Pessoas</td></tr><tr><td><img src="/files/FeOyc53zOFldhIoY1p4f" alt=""></td><td>MSG01</td><td>Ex: MSG001 – Comunicar exceção ao gerente</td></tr><tr><td><img src="/files/SlnZwpi0H6KQQmMJ2Ugv" alt=""></td><td>LS01</td><td>Ex: LS01 – Sem descrição (Link de saída)</td></tr><tr><td><img src="/files/dQartVKxvSzlRZVQyOPg" alt=""></td><td>LC01</td><td><p>Ex: LC01, LC02 - Sem descrição (Link de chegada)​</p><p> </p><p>Obs: Podemos vincular mais de um link de saída ao mesmo link de entrada, apenas ajuste a descrição do link de entrada conforme exemplo acima.</p></td></tr><tr><td><img src="/files/Dt62Rp0rxvPkLEeMYeng" alt=""></td><td>R01</td><td>Ex: R01 – aguardar x dias</td></tr><tr><td><img src="/files/NBZlNVlPZxx7IojI8WrJ" alt=""></td><td>FP01</td><td>Ex: FP01 - Descrição</td></tr><tr><td><img src="/files/9z5OHKuXBkqusw3JPldB" alt=""></td><td>FT01</td><td>Ex: FT01 - Cadastro Concluído, FT02 – Cancelado pelo Solicitante.</td></tr><tr><td><img src="/files/XLF1ph1nN4RcI9RpvtTv" alt=""></td><td>MC01</td><td>Ex: MC01 – Em aprovação</td></tr></tbody></table>
{% endtab %}

{% tab title="Atividades" %}

<table data-header-hidden><thead><tr><th width="145.66666666666666">Elemento</th><th width="126">Sigla</th><th>Exemplo</th></tr></thead><tbody><tr><td><img src="/files/uQwypRzft9dMAS5Of0tN" alt="" data-size="original"></td><td><p> </p><p>T01 </p></td><td><p> </p><p>Ex: T01 - Realizar análise</p></td></tr><tr><td><img src="/files/uIbBNQ32h21xTSKJDHlJ" alt=""></td><td><p> </p><p>RF01</p></td><td> Ex: RF01 – Realizar aprovação</td></tr><tr><td><img src="/files/ZIdDnhrdBV4goskbHljz" alt=""></td><td><p> </p><p>SP01</p></td><td> Ex: SP01 – Nome do Processo</td></tr><tr><td><img src="/files/CrMkSnMeYz3UQQIud7NZ" alt=""></td><td>RN01</td><td>Ex: RN01 – Definir responsáveis</td></tr><tr><td><img src="/files/zKknglLehTI1QykgsJ0a" alt=""></td><td><p> </p><p>TS01</p></td><td> Ex: TS01 – Integrar dados ao ERP</td></tr><tr><td><img src="/files/Jt0gNtsOmEyciEMnMoyc" alt=""></td><td><p> </p><p>TSC01</p></td><td><p> </p><p>Ex: TSC01 – Definir conta financeira​ ​</p><p> </p><p>Obs: Disponível somente no plano Zeev Enterprise.</p></td></tr></tbody></table>
{% endtab %}

{% tab title="Gateways" %}

<table data-header-hidden><thead><tr><th width="147.66666666666666">Elemento</th><th>Sigla</th><th>Exemplo</th></tr></thead><tbody><tr><td><img src="/files/UzeWbGeqA0afbR7Wgy3k" alt=""></td><td> GP01</td><td>Ex: GP01</td></tr><tr><td> <img src="/files/jV6bY60FKpGbrfZ1hp0n" alt=""></td><td>GI01</td><td><p>Utilizar sigla sem descrição no elemento e as setas/conexões com descrição) ​</p><p> </p><p>EX: GI01, GI02        ​</p><p> </p><p>Setas/conexões:     </p><p><img src="/files/ZIf42xYmJTYFlRKI2jHE" alt="">                                                   </p></td></tr><tr><td> <img src="/files/bCTaCwQSIEYYyUPzy48a" alt=""></td><td>GE01</td><td><p>Utilizar sigla sem descrição no elemento e as setas/conexões com descrição) ​</p><p> </p><p>EX: GE01, GE02​</p><p> </p><p>Setas/conexões: ​</p><p><img src="/files/eUOKsMi863TIOKK8ivTv" alt=""></p></td></tr></tbody></table>
{% endtab %}
{% endtabs %}

### Dar nomes de tarefas no infinitivo

Uma boa prática universalmente conhecida é definir o nome de [atividades ](/zeev/como-construir-processos/como-desenhar-processos/o-que-sao-atividades.md)e [eventos ](/zeev/como-construir-processos/como-desenhar-processos/como-usar-eventos.md)no infinitivo.

No exemplo abaixo temos um processo teoricamente correto, porém que não utiliza esse padrão.

![](/files/jDn8ufpZtdGEGKBSmT09)

Adaptando seus títulos, ficaria assim:

![](/files/I9dSSdi9Z2cl29EItDwf)

## Utilizar raias para identificar o responsável

No exemplo anterior, ao modificar o tempo verbal do nome das atividades, retiramos o sujeito que realiza a atividade.  Essa informação, entretanto, é importante e relevante para a compreensão do desenho. A maneira correta de indicar o sujeito responsável pelo evento ou pela atividade é pela utilização de [raias](/zeev/como-construir-processos/como-desenhar-processos/como-usar-swinlanes/raias.md).

![](/files/dfLLezMg4cO5h5GftocL)

## Numerar as atividades

Observe o desenho abaixo. Está tudo correto com ele. Entretanto, observe que ele tem duas tarefas de aprovação, uma do Diretor e outra do CEO. Ambas possuem o mesmo nome.&#x20;

![](/files/IhSomP5V5u3ObbUg20Wp)

Não há problema teórico em duas atividades terem o mesmo nome. Porém, na prática, após esse processo ser automatizado e começar a ser usado, você poderá se deparar com algumas dificuldades no dia-a-dia. Digamos que você é o responsável pelo processo e alguém entre em contato com você informando que está ocorrendo um erro ou problema "na atividade de aprovação" (confie, é assim que você receberá a informação).  Qual das duas tarefas? E se o seu processo possui 50 elementos e 6 tarefas de aprovação? A comunicação pode começar a ficar difícil e o suporte ao processo comprometido. Por isso, recomendamos sempre que seja utilizado algum padrão de codificação dos nomes das atividades. Veja exemplo abaixo:

![](/files/ModyJXgkOv16DGCEMmf8)

Pronto! Se existir uma dificuldade na tarefa do CEO, agora com certeza a comunicação dentro da empresa irá se referir a "T02". Utilize algum padrão de codificação em todos os elementos do seu processo, principalmente em [tarefas humanas](/zeev/como-construir-processos/como-desenhar-processos/o-que-sao-atividades/como-configurar-atividades-humanas.md), [tarefas de regras de negócio](/zeev/como-construir-processos/como-desenhar-processos/o-que-sao-atividades/o-que-e-atividade-de-regra-de-negocio.md), [tarefas de serviços](/zeev/como-construir-processos/como-desenhar-processos/o-que-sao-atividades/o-que-e-atividade-de-regra-de-negocio.md) de [eventos de mensagem](/zeev/como-construir-processos/como-desenhar-processos/como-usar-eventos/como-configurar-eventos-de-mensagens.md).&#x20;

## Utilizar fins diferentes para situações diferentes

Algumas abordagens de modelagem pregam utilizar somente um evento de[ fim total](/zeev/como-construir-processos/como-desenhar-processos/como-usar-eventos/evento-de-fim-total.md) por processo. A especificação BPMN nada fala sobre isso. Além disso, no Zeev, estimulamos o uso de mais um evento de fim total quando for útil especificar o status final da solicitação. Ocorre que dentro da configuração do elemento de fim total é possível determinar o status de resultado final do fluxo.  Esse status comumente é definido para verbos como "Aprovado", "Rejeitado", "Comprado", "Solicitado", "Atendido", etc.  Essa informação, depois, será mostrada em relatórios e contadores de indicadores.&#x20;

Veja o processo abaixo, por exemplo. Reutilizando o mesmo elemento de fim para representar tanto os status de "Aprovado" quanto de "Rejeitado", o sistema não conseguirá emitir relatórios ricos posteriormente sobre os status finais das solicitações.

![](/files/rN6CxQuayeYugVFittJA)

Esse mesmo processo seria melhor representado e configurado usando mais de um fim total:

![](/files/LqzwNsToXYcijVqGQLNO)

## Resumo

Confira no vídeo a seguir cinco boas práticas em desenho BPMN.

{% embed url="<https://youtu.be/M3l958Q3D2A>" %}