Boas práticas de modelagem de processos com notação BPMN

Este artigo apresenta a adesão a um conjunto de boas práticas na modelagem de processos que é essencial para padronizar um modelo de processo de negócio

A modelagem de processos de negócio pode atuar como uma grande aliada na compreensão dos processos de uma empresa. Através dela, a necessidade de melhorias de um processo se torna mais evidente, facilitando a comunicação entre os vários envolvidos no processo.

Modelos de processos de negócio que apresentam erros podem influenciar negativamente na compreensão e execução desses processos, esses erros podem estar relacionados a uma falta de entendimento do processo, mas também podem ocorrer devido à falta de conhecimento da notação utilizada para fazer a modelagem.

O padrão Business Process Modeling Notation (BPMN) oferece às organizações a capacidade de compreender os seus processos internos de negócio em uma notação gráfica com a capacidade de comunicar seus procedimentos de forma padrão.

Os resultados esperados deste artigo é possibilitar a construção de um catálogo de orientações e padrões básicos e ajudar no aprendizado na notação BPMN, além de servir de guia para a avaliação de modelos BPMN.

As boas práticas em questão é uma construção coletiva que foi realizado pelos consultores da Memora Processos Inovadores e os servidores do Escritório de Processos da Receita Federal do Brasil, tendo como referência o Livro BPMN Method e Style, 2° Edição de Bruce Silver e Manual Oficial de Business Process Model and Notation da OMG, brsilver.com e camunda.org.

Boas práticas de modelagem de processos

Um diagrama de Processos de Negócios é uma poderosa ferramenta de comunicação e
de análise. Seguem alguns objetivos da modelagem de processos:
1. Facilitar o entendimento de um processo;
2. Padronizar a execução das atividades;
3. Documentar e dar publicidade aos trabalhos desenvolvidos na organização;
4. Apoiar a elaboração de manuais e de atos normativos;
5. Proporcionar maior agilidade na tomada de decisões;
6. Auxiliar a capacitação de novos servidores;
7. Facilitar a especificação de sistemas;
8. Facilitar a definição de competências e de capacitações necessárias aos executores do processo;
9. Viabilizar a gestão dos riscos associados aos processos de trabalho.

Eventos

1. Evite utilizar mais de um evento de início no processo;

2. Inícios de processo em alto nível podem ser iniciados com qualquer tipo de evento, a depender do “gatilho” que dê início ao processo;

3. Subprocessos somente devem ser iniciados com evento do tipo None;

4. Quando houver várias possibilidades de início do processo utilizar o objeto evento de início múltiplo, da seguinte forma:

4.1. Até duas entradas: cada possibilidade de início será representado por um fluxo de
mensagem originado na(s) conjunto(s) devidamente nomeado de forma a identificar a(s) entrada(s);
4.2. Acima de duas entradas: Todas as possibilidades de início serão representadas por um objeto anotação contendo as informações de origem e entrada de cada possibilidade.

5. Em um diagrama de processo, todos os eventos devem ser nomeados com um verbo no particípio passado;

6. Use eventos de início e fim de cada processo e sub-processo para representar o seu início e conclusão;

7. Utilize eventos intermediários de link no reuso de chamada de atividade para melhor visualização do processo. Os eventos de link de pegar e rejeitar devem ter o mesmo nome;

8. Eventos intermediários de link só podem ser utilizados dentro de um mesmo processo;

9. Um processo pode ter um ou mais eventos FINAIS. Recomenda-se o uso de nomes diferentes, correspondentes ao seu estado final;

10. Subprocessos somente podem ser terminados por eventos do tipo None. Caso o término do subprocesso gere uma mensagem, o fluxo deverá subir para o processo “alto nível”;

11. Eventos do tipo Terminate somente devem ser utilizados para interromper processos/subprocessos em que haja fluxos ocorrendo em paralelo;

12. Quando utilizamos o evento do tipo timer na borda de uma tarefa, estamos indicando o tempo para finalização da execução desta tarefa. Caso não ocorra a finalização da tarefa no tempo indicado deve ser criado fluxo de exceção para representar esta situação. Já quando utilizamos o evento do tipo timer entre duas tarefas indicamos que há uma interrupção entre a execução das duas tarefas.

Atividades

1. Cada atividade deve ser nomeada usando uma frase iniciando com verbo no infinitivo curto e significativo para o negócio

2. Não use abreviaturas incomuns;

3. Evite artigos e pronomes.

Gateway

1. Utilize um gateway de convergência antecedendo uma atividade quando a mesma tiver 2 ou mais entradas quando a lógica de convergência não é óbvia, uma anotação de texto deve ser associado ao Gateway;

2. Devem ser utilizados apenas para representar a lógica de roteamento do processo. Você tem que determinar fatos e necessidades antes de chegar a um gateway;

3. Use sempre o mesmo tipo de gateway que divergiu para convergir;

4. Os fluxos de mensagens deverão ser nomeados de maneira que fique clara a informação de entrada e de saída;

5. Fluxos sequência padrão não deve ser nomeado. Este tipo de fluxo ocorre quando utilizamos gatewatys do tipo inclusivo. Ele é ativado quando todas as condições de fluxo de saída não forem cumpridas;

6. Evite linhas cruzadas (conectores), mantenha uma sequência de tempo e direção consistente de fluxo. A leitura diagrama será mais fácil e sua comunicação eficiente;

7. Use o evento intermediário de link para tentar evitar o cruzamentos de linhas.

Pools(conjunto) e Lane (pista)

1. Toda interface com processos/participantes externos deve ser realizada por meio fluxos de mensagem que ligue o conjunto ao subprocesso/tarefa em questão;

2. Interfaces previstas nos subprocessos devem ser refletidas no processo de alto nível ou nos níveis superiores.

3. O conjunto representa um participante em um diagrama de colaboração. Portanto nomear sempre usando o nome do participante externo ou Processo da Cadeia de Valor que interaja;

4. As pistas devem ser preenchidas de acordo com seu executor podendo ser, Unidades organizacionais, Nomes de Cargos de Gestão (Subsecretário, Coordenador-geral, etc);Equipes (Equipe de despacho, equipe de atendimento, etc) e, eventualmente e, se necessário, nomes de sistemas informatizados;

5. Criar pistas somente se pelo menos uma tarefa for realizada na mesma;

6. Não crie pistas para representar a área ou entidade que realiza gateways ou tarefas
automáticas.

Considerações Finais

Grandes diagramas não permitem dar uma perspectiva de ponta a ponta para os eleitores. Eles são difíceis de ler e comunicar claramente o objetivo do processo.

Definir escopo correto de tarefas e nível de detalhe dos processos é a chave para
reduzir a sobrecarga de informações. As dicas a seguir irão ajudá-lo:

1. Reduzir o número de tarefas redundantes

2. O nível de detalhe em um processo às vezes é um verdadeiro desafio. Em muitos casos, você pode enfrentar dificuldades para definir o escopo de uma única tarefa. Leve em conta que: Um conjunto de atividades consecutivas na mesma pista pode indicar falta detalhes do participante, muito detalhe, ou um desalinhamento no escopo, reveja esses padrões para identificar oportunidades de integração atividade.

3. É útil imaginar que você é um usuário final. Se um conjunto de atividades consecutivos pode ser realizada pela mesma pessoa, ao mesmo tempo, em seguida, estas atividades poderiam ser integrados numa única atividade?

4. Deixe os detalhes para a documentação. Não inclua todas as informações no diagrama. Informações adicionais devem ser documentados no Formulário Descritivo (artefato desenvolvido para disponibilizar informações gerais do processo).