mar 27 2015

Boas práticas de notação BPMN

Published by at 10:02 under BPMN,Processos

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:

  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.

Figura 1 – Uso do evento inicial múltiplo

Figura 1 – Uso do evento inicial múltiplo

 

  1. Em um diagrama de processo, todos os eventos devem ser nomeados com um verbo no particípio passado;
  2. Use eventos de início e fim de cada processo e sub-processo para representar o seu início e conclusão;
  3. 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;
  4. Eventos intermediários de link só podem ser utilizados dentro de um mesmo processo;

Figura 2 – Uso do evento intermediário link

Figura 2 – Uso do evento intermediário link

 

  1. 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

Figura 3 – Uso do evento final

 

  1. 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”;
  2. 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

Figura 4 – Uso do evento final terminate

 

 

  1. 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

Figura 5 – Uso do evento intermediário timer

 

ATIVIDADES

 

  1. 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;
  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;

Figura 6 – Uso do Gateway

Figura 6 – Uso do Gateway

 

  1. 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;
  2. Use sempre o mesmo tipo de gateway que divergiu para convergir; 

FLUXOS DE SEQUENCIA 

  1. 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;
  2. 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

Figura 7 – Uso fluxo de sequência

 

  1. 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

Figura 8 – Uso fluxo de mensagem

 

  1. 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;
  2. 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

Figura 9 – Uso fluxo sequência padrão 

  1. 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;
  2. Use o evento intermediário de link para tentar evitar o cruzamentos de linhas.

 

POOLS (CONJUNTO) E LANE (PISTAS)

 

  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. 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

Figura 10 – Interface de processos

 

  1. Interfaces previstas nos subprocessos devem ser refletidas no processo de alto nível ou nos níveis superiores.
  2. 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;
  3. 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;
  4. Criar pistas somente se pelo menos uma tarefa for realizada na mesma.
  5. 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:

 

  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).

No responses yet

Trackback URI | Comments RSS

Leave a Reply