mar 27 2015
Boas práticas de notação BPMN
BOAS PRÁTICAS DE MODELAGEM DE PROCESSOS – BPMN
por André Rabelo, CBPP
Resumo
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.
Palavras-chave: Boas Práticas.Business Process Modeling Notation . BPMN. Modelagem de Processos.Notação.
Introdução
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 em 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 BPMN oferece às organizações a capacidade de compreender os seus processos internos do negócio em uma notação gráfica e a capacidade de comunicar seus procedimentos de forma padrão.
Dessa forma, este artigo de Boas Práticas de Business Process Modeling Notation (BPMN) visa construir um catálogo de orientações e padrões adotados pelo projeto em questão como melhor forma de representar e/ou apresentar seu entendimento com relação ao tema.
Os resultados esperados deste artigo é ajudar no aprendizado na notação BPMN, além de servir de guia para a avaliação de modelos BPMN.
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:
- Facilitar o entendimento de um processo;
- Padronizar a execução das atividades;
- Documentar e dar publicidade aos trabalhos desenvolvidos na organização;
- Apoiar a elaboração de manuais e de atos normativos;
- Proporcionar maior agilidade na tomada de decisões;
- Auxiliar a capacitação de novos servidores;
- Facilitar a especificação de sistemas;
- Facilitar a definição de competências e de capacitações necessárias aos executores do processo;
- Viabilizar a gestão dos riscos associados aos processos de trabalho.
EVENTOS
- Evite utilizar mais de um evento de início no processo;
- 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;
- Subprocessos somente devem ser iniciados com evento do tipo None;
- 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.
Figura 1 – Uso do evento inicial múltiplo
- Em um diagrama de processo, todos os eventos devem ser nomeados com um verbo no particípio passado;
- Use eventos de início e fim de cada processo e sub-processo para representar o seu início e conclusão;
- 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;
- Eventos intermediários de link só podem ser utilizados dentro de um mesmo processo;
Figura 2 – Uso do evento intermediário link
- Um processo pode ter um ou mais eventos FINAIS. Recomenda-se o uso de nomes diferentes, correspondentes ao seu estado final. Esses eventos devem ser refletidos, com a mesma denominação utilizada no diagrama, no Formulário de Contextualização (artefato desenvolvido para disponibilizar informações gerais do processo) no respectivo campo;
Figura 3 – Uso do evento final
- 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”;
- Eventos do tipo Terminate somente devem ser utilizados para interromper processos/subprocessos em que haja fluxos ocorrendo em paralelo;
Figura 4 – Uso do evento final terminate
- 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.
Figura 5 – Uso do evento intermediário timer
ATIVIDADES
- Cada atividade deve ser nomeada usando uma frase iniciando com verbo no infinitivo curto e significativo para o negócio respeitando o tamanho do objeto definido nos padrões de modelagem, máximo de 70 caracteres por atividade, aproximadamente 4 linhas dentro do objeto atividade, demais informações poderão ser inseridas no Formulário Descritivo (artefato desenvolvido para disponibilizar informações gerais do processo)ou se a área de negócio julgar de extrema importância para o processo que as demais informações fiquem expostas no diagrama deve-se usar o objeto de anotação;
- Não use abreviaturas incomuns;
- Evite artigos e pronomes.
GATEWAY
- 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;
Figura 6 – Uso do Gateway
- 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;
- Use sempre o mesmo tipo de gateway que divergiu para convergir;
FLUXOS DE SEQUENCIA
- Deve-se utilizar o fluxo de sequência de atividades da iniciando pela esquerda saída para direita, pois os leitores dos diagramas poderão entender a lógica do processo de forma mais clara;
- Sequências de fluxos saindo de gateways divergentes do tipo exclusivo ou inclusivo devem ter suas condições representadas nos respectivos caminhos;
Figura 7 – Uso fluxo de sequência
- Os fluxos de mensagens deverão ser nomeados de maneira que fique clara a informação de entrada e de saída; Estas informações representadas nos fluxos de mensagens devem ser transcritas no Formulário de Contextualização (artefato desenvolvido para disponibilizar informações gerais do processo) com o mesmo nome que foi inserido no diagrama.
Figura 8 – Uso fluxo de mensagem
- Maiores detalhes do fluxo de mensagem deverão ser registrados no Formulário Descritivo (artefato desenvolvido para disponibilizar informações gerais do processo) como atributos (insumos/produtos) das atividades envolvidas;
- 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, ou seja, quando todas as condições são “falsas”;
Figura 9 – Uso fluxo sequência padrão
- 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;
- Use o evento intermediário de link para tentar evitar o cruzamentos de linhas.
POOLS (CONJUNTO) E LANE (PISTAS)
- Toda interface com processos/participantes externos deve ser realizada por meio fluxos de mensagem que ligue o conjunto ao subprocesso/tarefa em questão;
- A interface entre conjuntos pode ser feita excepcionalmente em suas “bordas”, quando a entrada em questão interagir em qualquer ponto dentro do processo.
Figura 10 – Interface de processos
- Interfaces previstas nos subprocessos devem ser refletidas no processo de alto nível ou nos níveis superiores.
- 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;
- 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;
- Criar pistas somente se pelo menos uma tarefa for realizada na mesma.
- 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 leitores. 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:
- Reduzir o número de tarefas redundantes
- 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.
- É ú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?
- 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).