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:

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.

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.

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

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

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.

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

Dar nomes de tarefas no infinitivo

Uma boa prática universalmente conhecida é definir o nome de atividades e eventos no infinitivo.

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

Adaptando seus títulos, ficaria assim:

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.

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.

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:

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, tarefas de regras de negócio, tarefas de serviços de eventos de mensagem.

Utilizar fins diferentes para situações diferentes

Algumas abordagens de modelagem pregam utilizar somente um evento de fim total 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.

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.

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

Resumo

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