BPMN: Uma atividade para mais de um participante do processo

Há uma questão recorrente na modelagem de processos relacionada à distribuição de atividades nas lanes de processo: como representar um trabalho sendo realizado por mais de uma pessoa?

Por exemplo:
Digamos que em um processo há uma reunião realizada entre o Diretor de Planejamento e o Diretor Financeiro, que recebem uma proposta de um analista e realizam uma reunião para avaliar sobre o investimento. A seguir, eles atuam na priorização das ações relacionadas ao investimento, e a partir desta priorização são realizadas outras ações.

Para essa situação em que há dois participantes envolvidos na realização de uma mesma tarefa, já vimos diagramas que tentam representar isso de algumas formas peculiares:

"Tentei demonstrar que as atividades são realizadas pelos dois usuários posicionando-as sobre o limite entre as duas lanes."

A abordagem acima é inadequada sob o ponto de vista de uso da notação BPMN e poderá gerar interpretações diferentes. Para a notação, uma atividade só pode estar associada a uma raia (lane), e mesmo que a ferramenta de criação do diagrama não aponte o problema na validação do processo, o fato é que internamente as atividades estão vinculadas a apenas uma lane. Isto está estabelecido na própria especificação da notação. Se a ferramenta utilizada dispõe de geração de relatório que lista quais tarefas estão relacionadas a quais lanes, essas tarefas só estarão associadas a um único participante.
Tem um outro problema ao se praticar o mapeamento desta forma: e se os investimentos tivessem que envolver também o Diretor de Tecnologia – como colocar as tarefas compartilhando pessoas de três raias?

Outra tentativa comum é a refletida no exemplo abaixo:

"Coloquei as tarefas em paralelo porque eles fazem a reunião ao mesmo tempo."

No diagrama acima, as regras de validação lógica do uso da notação também não apontariam problema, mas o processo ainda não estaria corretamente representado.

A interpretação que se deve ter no uso do gateway paralelo não é de que as atividades paralelizadas serão realizadas ao mesmo tempo, e sim que elas podem ser feitas em paralelo porque não há restrição de dependência entre elas. Assim, apesar de serem iguais no exemplo acima, cada tarefa tem sua execução própria, levando ao entendimento que cada um fará as atividades quando tiver disponibilidade. Por exemplo: digamos que o Diretor de Investimentos faça “Avaliar investimento” pela manhã e já siga para a próxima tarefa, enquanto o Diretor Financeiro só consiga iniciar a tarefa “Avaliar investimento” à tarde. O processo mapeado acima permite essa interpretação.

Se a ideia é de que os dois realizem juntos a tarefa “Avaliar investimento” e “Priorizar etapas do investimento”, recomendamos uma forma de mapear isto um pouco diferente:

Uma raia com um papel em grupo que abstrai os participantes e garante que as tarefas sejam realizadas em conjunto pelos envolvidos.

Nesta abordagem, criamos uma raia para um papel que abstrai um grupo (o  “Comitê de Avaliação de Investimentos”), e atribuímos as atividades a ela. Na descrição da raia, ficam estabelecidas as regras usadas para definir quem são os participantes do comitê – que neste caso será formado pelos Diretores de Investimentos e Financeiro. Esta abordagem ainda possibilita que outros diretores possam se juntar ao comitê sem impactar no diagrama do processo, bastando apenas ajustar a descrição dos participantes do grupo.

Definindo o Escopo de Modelagem de um Processo de negócio

Uma definição essencial no início de um projeto de modelagem é o escopo do processo que será modelado. A definição clara dos limites em que será trabalhado o processo é um fator chave para a realização de qualquer projeto de modelagem.

Tomando como exemplo um processo de venda de uma fábrica de móveis: num primeiro momento, poderíamos imaginar que o escopo de um processo desta natureza  inicia com a chegada do cliente na loja e termina com o pagamento:

Contudo, extrapolando um pouco as atividades que se seguem ao pagamento, poderíamos questionar se não deveriam também estar contempladas as etapas de:

  • Entrega dos móveis;
  • Montagem, quando necessário;
  • Acompanhamento dos pagamentos parcelados; ou
  • Acompanhamento da garantia.

Onde efetivamente deveria começar e finalizar este processo?
Não existe uma resposta certa para esta pergunta, pois o escopo de um projeto de modelagem depende de diversos fatores, estando entre eles:

1. Os Resultados esperados do projeto: A motivação inicial pela realização do projeto é um fator primordial na definição do seu escopo. No exemplo acima, a modelagem pode ter sido demandada pela equipe comercial que tem como meta abrir mais 50 lojas nos próximos 12 meses e que precisa, portanto, unificar o processo de atendimento. Ou por uma necessidade desta mesma equipe em unificar o atendimento das suas lojas, tendo em vista que algumas unidades possuem um desempenho espetacular e em outras deixam muito a desejar. Nestes casos, a primeira versão do processo atende as expectativas.
Porém, digamos que a motivação seja garantir a melhor experiência de atendimento ao cliente. Neste caso, a empresa pode estar preocupada com o fato que o atendimento fora da loja, nas etapas de transporte e montagem, são os momentos em que ela menos tem condições de garantir a sua qualidade, criando assim uma necessidade de maior gestão e controle.

2. A Equipe envolvida no projeto: A modelagem de processos é uma atividade de natureza interfuncional que necessita para o seu sucesso da cooperação de todas as áreas envolvidas no processo. Desta forma, a amplitude do escopo da modelagem deve ser norteada também pelas áreas que estão engajadas no projeto de modelagem. A ampliação do escopo exigirá a sensibilização das novas áreas de negócio que serão afetadas.

3. As Expectativas de Prazo e Custos do Projeto: As variáveis clássicas de custo, prazo e escopo estão interligadas desde a concepção do projeto, e a mudança em uma delas tende a gerar reflexos nas demais. Desta forma, a reflexão sobre o escopo do processo deve levar em conta as expectativas de prazos e custos previstos para o projeto, de modo a garantir que a alteração não impactará a sua viabilidade.

Respeitando estes quesitos, podemos avaliar se determinadas partes do processo, devido às suas características, não poderiam ser modeladas separadamente. São exemplos destas situações as etapas de um processo que:

  • Aparentam ser mais independentes em relação a outras. Etapas com estas características costumam tem um bom nível de desacoplamento do restante. Por exemplo, uma etapa final de pesquisa de satisfação do cliente tende a ser a menos acoplada ao processo do que a etapa de pagamento, e poderia ser analisada separadamente.
  • Se repetem em outros processos. Por exemplo, o serviço de transportes pode ser necessário tanto num processo de venda como num processo de manutenção ou devolução do móvel adquirido.
  • São claramente de apoio, sem visibilidade para o cliente final.
  • Não podem retroagir a um ponto anterior do mesmo processo. Por exemplo, no nosso processo de vendas, não é razoável pensarmos que no momento em que o cliente está recebendo o montador do seu móvel ele possa voltar para a etapa de cadastro realizada antes da compra. Isso demonstra que a etapa de montagem e a etapa de cadastro possuem uma certa independência que permite que elas sejam analisadas separadamente.

Neste momento, algumas perguntas chaves muito comuns no início de um projeto de modelagem também podem ser fundamentais para definirmos o escopo mínimo e máximo de um processo, tais como:

  • Quem é o cliente do processo? Ele será atendido com o escopo que está sendo proposto?
  • Quem são os seus fornecedores? No escopo proposto eles interagirão com o processo?
  • Quais são as entradas e saídas do processo? As entradas previstas serão utilizadas no escopo proposto? Este escopo entregará as saídas esperadas?
  • Quais são os indicadores principais? No escopo proposto estes indicadores poderão ser medidos?

Finalmente, é importante que o escopo previsto para o projeto contemple alguns cuidados de modo a evitar que o mesmo não se limite a um escopo tão pequeno que não seja contributivo ou tão grande que se torne inviável. Desta forma, sugerimos sempre uma dose de atenção para que:

  • O processo não se limite a uma só área ou departamento, ou seja, preserve suas características interfuncionais. Processos departamentais tendem a não apresentar todos os benefícios da gestão por processos como aqueles transversais à organização.
  • Se evitem projetos que exigem 6, 10 ou 12 meses de trabalho. Projetos desta amplitude tende a já ter o seu resultado desatualizado ao seu final, além de gerar desmotivação devido a demora na entrega dos seus resultados.
  • No caso do processo ser muito extenso, seja verificada a possibilidade de que o seu escopo seja dividido em dois ou mais projetos, de modo a garantir entregas frequentes.
  • Se lembre que, quanto maior o escopo, mais complexa a sua gestão.
  • Se esteja, contudo, sempre atento para evitar que uma divisão excessiva que sacrifique a visão ponta a ponta do processo.

Finalizando, não podemos deixar de ressaltar que, tão importante quanto à definição do escopo é que estes limites fiquem sempre muito claros para os stakeholders e para as áreas de negócio. A falta de clareza sobre o escopo a ser trabalhado tende a gerar desmotivação e retrabalho nas reuniões de levantamento do processo.

Se você quiser saber um pouco mais sobre este assunto, conheça o nosso curso de modelagem de processo, http://www.iprocesseducation.com.br/ipe01.html, oferecido pela iProcess Education.

Respondendo dúvidas em BPMN: Desenhar processo na vertical ou horizontal?

A definição sobre a orientação vertical ou horizontal para diagramas na notação BPMN, sempre foi, desde sua criação, um dos aspectos mais questionados pelos analistas e modeladores de processos.

Um de nossos leitores recentemente enviou a seguinte questão:

“Sei que a boa prática é desenhar o processo da esquerda para a direita, correto?
Porém estou me deparando com alguns processos longos que vão dar muito trabalho fazer nesta ordem e acredito que ficará mais fácil visualizar de cima para baixo.
O que vocês acham sobre isso? Há alguma regra? O que vocês orientam?”

Embora não seja obrigatório em BPMN, swimlanes (pools e lanes) são muito utilizadas pois possibilitam a estruturação visual do fluxo, de forma a apoiar a interpretação do mesmo. Através delas, é possível identificar facilmente quem é responsável por executar cada tarefa, quem são os atores do processo e que participantes externos colaboram com o processo.

Em nosso blog, já falamos sobre pools e lanes em postagens como:

A especificação da notação (http://www.omg.org/spec/BPMN/2.0/PDF/) define o uso de swimlanes como não obrigatório, e que estes elementos podem ser usados para organizar o processo visualmente tanto na horizontal quanto na vertical.

Muitas vezes, o analista que realiza a modelagem de processo já utilizou alguma outra notação ou metodologia com elementos semelhantes às pools e lanes de BPMN, como eEPC e fluxogramas. Nestas duas notações, o processo é comumente representado na vertical. Assim, é mais natural para estes profissionais elaborar o processo nesta visão.

Entretanto, a maior parte dos exemplos que encontramos na bibliografia e na web sobre BPMN utiliza a representação na horizontal. Isto se dá porque na cultura ocidental temos o reflexo da leitura da esquerda para a direita. É uma percepção ligada à compreensão da sequência de ações. Assim, a distribuição do processo em uma estrutura de pool e lanes horizontal permite uma melhor distribuição das tarefas nesta visão

Um exemplo bastante simples de processo modelado com swimlanes na horizontal. À medida que se agreguem novas atividades ao processo, há a uma tendência de aumento do diagrama para a esquerda. Em um diagrama com colaboração, outras pools podem ser adicionadas, geralmente abaixo e acima da pool que contém o processo.

O mesmo processo do exemplo acima, representado com swimlanes verticais. A leitura do fluxo navega para a esquerda mas em alguns momentos precisa ir na "contra-mão" da leitura normal. A tendência de aumento é para baixo, mas novas lanes podem ser agregadas aumentando sua largura. Em um diagrama com colaboração, outras pools podem ser agregadas, geralmente nas laterais da pool que contém o processo.

Existe ainda uma abordagem de fluxo limpo do processo, em que pools e lanes não são utilizadas. Essa abordagem é mais usual quando o processo é modelado com visão de orquestração, por exemplo, em que suas atividades são na verdade uma sequência de processos, ou sub-processos. Neste nível de visão sobre o processo de negócio, é mais relevante identificar os processos e como estão relacionados do que quem são os envolvidos nestas tarefas, já que os atores já estarão claros nos diagramas dos respectivos processos.

Apesar da flexibilidade oferecida pela especificação oficial da notação, em geral recomenda-se a documentação do processo com pool e lanes na horizontal, seja pelo aspecto do conforto natural da leitura do fluxo ou mesmo por restrições de ferramentas (alguns produtos amplamente utilizados no mercado para representar diagramas de processos não permitem desenhar pools e lanes verticais, apenas horizontais).

Se o diagrama do processo tende a se tornar grande, a resposta não está na definição vertical ou horizontal do diagrama, mas na capacidade de abstrair tarefas em conjuntos através de subprocessos. Com isso, o modelo talvez acabará ganhando um ou dois níveis a mais, mas ao mesmo tempo temos com isso um diagrama com visão mais objetiva sobre o processo de negócio (veja mais sobre esta abordagem neste artigo, em orquestração de processos).

Independente da escolha, nossa principal recomendação é que esta definição deve fazer parte do guia de estilos de modelagem da organização, ou seja: vertical ou horizontal – o importante é manter um padrão a ser adotado em todos os diagramas de processos  de negócio documentados para a empresa.

 


Aprenda a utilizar todo o potencial da notação BPMN em exercícios práticos e avançados com nossos instrutores!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br

Vale a Pena Mapear Todos os Processos da Organização?

Um dos temas mais polêmicos quando falamos em projetos de modelagem de processos são os projetos cujo objetivo é mapear todos os processos da organização. Projetos desta natureza exigem um envolvimento global de toda a organização, pois dada a natureza dos processos de negócio, toda as áreas e papéis existentes terão que contribuir para o sucesso deste trabalho.

As empresas possuem dentro da sua operação algumas centenas de processos de negócio relevantes. O esforço para mapear tantos processos é enorme, exigindo via de regra algumas milhares de horas de trabalho.

Este esforço não se deve tanto à complexidade técnica do trabalho que tem a ser realizado, mas sim ao volume de processos que devem ser tratados. Como consequência, o projeto acaba envolvendo um número elevado de analistas de processos, muitas vezes até um número maior do que a empresa possui nos seus quadros, fazendo assim da terceirização um meio para viabilizar o trabalho.

Apesar deste número elevado de horas, este tipo de trabalho traz como resultado uma descrição em alto nível destes processos de negócio. Isso porque, se estes consultores precisassem detalhar a nível de procedimento em cada um dos processos, o esforço cresceria exponencialmente, tornando o projeto impraticável. Desta forma, o resultado de tamanho esforço é uma documentação ampla e organizada que mostra a estrutura e hierarquia de cada processo, mas sem entrar em detalhes sobre como são executados os procedimentos de suas atividades.

Com tantas pessoas envolvidas e tanto trabalho a cumprir, projetos desta natureza acabam sendo projetos caros. Não só pelas milhares de horas dos analistas de processos, mas também (e principalmente) pelo tempo demandado das áreas de negócio e por toda mobilização que acaba se fazendo necessária.

Tal mobilização acaba gerando enorme expectativa dentro da empresa: todos esperam que, ao final deste trabalho, a empresa terá um repositório com todos os seus processos e suas respectivas atividades. E é justamente na viabilidade em atender estas expectativas que está o maior desafio.

Processos de negócio são elementos vivos dentro das organizações: diariamente, surgem novas necessidades ou requisitos que exigem a sua adaptação. Quando os processos são modelados ou redesenhados de forma gradativa e planejada, a implantação de uma política de governança que garanta a atualização desta base torna-se natural. Os envolvidos nestes processos possivelmente participaram de toda uma estratégia de mobilização e discussão sobre os processos, sendo assim mais fácil obter o seu comprometimento. Contudo, quando todos os processos da organização são mapeados em poucos meses numa estratégia de documentação em série, a manutenção desta governança e a criação deste comprometimento torna-se muito mais difícil.

Desta forma, a pergunta que fica é: “Como fazer para garantir que, ao final do projeto, toda e qualquer MUDANÇA em QUALQUER PROCESSO será corretamente identificada, analisada e documentada no repositório de processos?

A viabilidade da organização em oferecer esta garantia acaba se tornando o ponto mais crítico de sucesso, uma vez que:

  1. Se a empresa não conseguir manter a base de processos atualizada, em pouco tempo existirão inúmeros processos desatualizados;
  2. Se houverem processos desatualizados, as áreas de negócio começarão a perceber que o repositório de processos não serve como base de consulta;
  3. Se o repositório não servir como repositório de consultas, ele deixará de ser utilizado.
  4. Se ele deixar de ser utilizado, toda a iniciativa cairá em descrédito.

É claro que projetos desta natureza podem trazer inúmeros benefícios, e que as empresas terminando estes projetos se conhecem muito melhor do que quando começaram. Contudo, é importante que as organizações tenham em mente que existe um limite de detalhamento que é passível de manutenção, e que elas não devem investir na criação de uma documentação que elas não conseguirão manter.

 


Conheça mais sobre o Ciclo de Vida de Processos e Projetos de BPM e desenvolva seus conhecimentos nas atividades de mapeamento, análise e redesenho de processos com nossos instrutores!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br

Respondendo a dúvidas: vale usar evento de erro em BPMN para tratar exceção de negócio?

Como já comentamos em diversos artigos deste blog, é possível representar uma mesma situação de negócio de formas diferentes com BPMN.

A seguinte questão foi levantada esta semana por um de nossos leitores, que acompanhou o diagrama logo abaixo:

“Qual a maneira correta de representar uma decisão binária (sim ou não)?
É correto utilizar o evento de erro na atividade para representar o ‘não’?
Para os 3 casos, as notificações acontecem caso o ‘caminho feliz’ não seja satisfeito. O que você me diz disso sobre a notação?
Tenho que utilizar 3 gateways?”

Este exemplo foi enviado pelo leitor para ilustrar a dúvida sobre eventos de erro na borda da tarefa.

No livro “BPMN Method & Style” 2a ed, Bruce SIlver fala o seguinte (pág 104):

“Um evento de Erro na borda de uma tarefa simplesmente representa o estado final de exceção da tarefa. O fluxo normal, a sequência de saída da tarefa, representa o seu término quando a tarefa é concluída com sucesso, e o fluxo de exceção, a sequência de saída através do evento de Erro, representa o término quando o resultado não é bem sucedido. Ele representa exatamente a mesma coisa que um gateway XOR (Exclusive data based) seguido do resultado da tarefa com fluxos de sucesso e exceção.”

De fato, ao analisarmos a especificação da notação (http://www.omg.org/spec/BPMN/2.0/), não há nenhuma restrição que indique que não seja correto utilizar este evento com esta conotação. Alguns profissionais preferem utilizar outro evento, o de Escallation, que possui semântica semelhante à do evento de Error, porém mais relacionada a uma percepção de falha relacionada ao negócio (e permite tratamento non-interrupting), reservando para o evento de erro as falhas relacionadas a exceções técnicas.

Em geral, nas modelagens que realizamos em nossos projetos, damos preferência pelo uso de gateways para verificar o resultado da tarefa (que pode ser mais do que simplesmente uma decisão binária de sim ou não). Deixamos o evento de erro na borda para tratar casos que representem efetivamente uma exceção. Um dos argumentos para esta escolha está no fato de que muitas vezes estes processos serão posteriormente automatizados em um BPMS, e para os motores de execução de processos é mais fácil realizar a validação de resultados da tarefa através desta composição.

Do ponto de vista estritamente relacionado ao uso da notação BPMN, todas as abordagens acima são permitidas.

A segunda parte da dúvida do leitor é “Tenho que utilizar 3 gateways?”

Bem, talvez não para este caso. Quem sabe podemos propor uma outra perspectiva? Uma análise do diagrama um pouco mais observadora nos faz pensar que talvez nesta modelagem as operações estejam sendo representadas em um nível de granularidade muito baixo. Será que podemos considerar que “Verificar se há período sem lançamento”, “Verificar se há RATs abertos” e “Analisar despesas” poderiam na verdade ser procedimentos de uma única tarefa? É como se a tarefa fosse “Analisar pendências e despesas” na qual a ferramenta do usuário fosse uma checklist com estas três questões.

Não seria melhor que todas as análises fossem realizadas e o colaborador recebesse como resultado não uma notificação relatando resultado apenas da primeira divergência identificada, mas uma única que já contivesse tudo o que ele precisa resolver para que sua requisição possa ser atendida? Com essa consolidação de procedimentos em uma única tarefa, não haveria mais a necessidade de três gateways, mas um. E ele poderia resolver mais do que o resultado “sim” e “não”. Que tal se os resultados fossem “aceito”, “aceito com restrições” (em que as divergências não bloqueiam a continuidade do processo) e “rejeitado”? Vale a reflexão 🙂

De qualquer forma, independente da opção, recomendamos sempre que a organização defina um estilo de modelagem com diretrizes de utilização da notação, que guiarão os modeladores a representarem os processos de uma forma padronizada.

 


Aprenda a utilizar todo o potencial da notação BPMN em exercícios práticos e avançados com nossos instrutores!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br

 

BPMN: demonstrando a continuidade de processos

Uma das principais vantagens de BPMN pode também ser o seu calcanhar de aquiles: embora robusta e flexível, Business Process Modeling Notation, como diz o nome, é apenas uma notação para representar de forma padronizada aspectos lógicos de um processo de negócio. Seu objetivo não é propor uma metodologia de análise ou de documentação de processos, mas uma linguagem comum que possa ser interpretada igualmente por todos os envolvidos.

A flexibilidade da notação em permitir que um mesmo cenário de negócio possa ser modelado de formas diferentes – com alguma eventual sutil diferença em sua interpretação, possibilita que o seu uso possa ser implementado conforme for mais conveniente para a organização. Por outro lado, implica em um problema comum a todos que iniciam a sua utilização: a ausência de uma metodologia ou padrão de uso.

Por isso, é comum que profissionais que utilizam o padrão eEPC da metodologia ARIS encontrem alguma dificuldade em traçar um paralelo claro de uso entre as duas notações.

Uma das dúvidas mais comuns relacionadas à especificação de processos com uma ou outra notação está na forma como se representa a conexão entre processos.

BPMN oferece diferentes formas de se representar a continuidade de processos. Cabe aos analistas identificar qual a forma mais apropriada para atender as necessidades de documentação do seu processo – que pode (ou deve!) ser guiada por uma abordagem padrão da organização.

Neste artigo, exploramos duas formas de representar a continuidade de processos com BPMN.

 I. Acionamento por comunicação explícita entre processos

Uma das formas de se demonstrar a comunicação entre processos com BPMN é através de acionamento explícito, em que o término de um fluxo invoca diretamente o fluxo de um outro processo. Isto é feito através da diagramação em pools. Nesta notação, cada processo é disposto em uma pool. Como já vimos em artigo anterior, a comunicação entre pools acontece sempre através de message flow. Por isso, quando um processo em uma pool termina já planejando iniciar outro processo, isto precisa ser feito com eventos do tipo message.

O exemplo abaixo é o que permite um paralelo mais próximo desse comportamento com um modelo eEPC. Quando o Processo de Inscrição em Eventos termina com a identificação de que precisa iniciar o Processo de Viagens Corporativas, o evento de fim é representado como um evento de end message event, e um conector de message flow realiza a transição para a pool daquele processo. O diagrama abaixo apresenta essa representação usando uma pool black box para representar o processo de Viagens.

Neste diagrama, a continuidade do processo de Inscrição em Eventos rumo ao Processo de Viagens Corporativas é explícito através da comunicação entre os dois processos, representada pelo conector de message flow. O Processo de Viagens Corporativas está representado como uma pool black box. A sua lógica poderia estar representada em detalhes em um outro diagrama.

Se for interesse do processo visualizar mais claramente a interação entre os dois fluxos, pode-se usar a representação abaixo, que demonstra como um fluxo inicia o outro e quais atividades se seguem depois que a participação no evento foi autorizada. A diferença entre o modelo acima e o abaixo é que na representação acima o Processo de Viagens Corporativas está em uma pool black box, enquanto no diagrama abaixo está em uma pool white box.

Neste diagrama, a continuidade do processo de Inscrição em Eventos rumo ao Processo de Viagens Corporativas é explícito através da comunicação entre os dois processos, representada pelo conector de message flow. O Processo de Viagens Corporativas está representado como uma pool white box, possibilitando uma visão completa da sequênia de atividades em nível operacional.

A principal vantagem desta abordagem é que fica explícito no diagrama que um processo de negócio maior tem continuidade através dos seus processos, porém causa um certo nível de dependência entre os processos.

 II.Orquestração de Processos

Uma segunda abordagem é utilizar um diagrama de orquestração, que em um nível um pouco mais alto, fica responsável por controlar o término de um determinado processo e identificar que outro deve ser iniciado na sequência. Esta abordagem baseia-se no conceito amplo de subprocessos em BPMN.

Para BPMN, não existe uma definição de arquitetura de processos, ou de estruturação de níveis. Cada organização deve orientar como vê a empresa e definir seu próprio mapa de processos. Para BPMN, as coisas são bem mais simples. Uma atividade, em um fluxo de trabalho, pode ser:

  • Uma tarefa (um conjunto de procedimentos que compoem uma atividade realizada por uma pessoa ou grupo de pessoas, em seu menor nível de granularidade);
    ou
  • Um subprocesso, que nada mais é do que uma abstração de que naquela etapa, um conjunto definido de atividades representadas em um fluxo (um processo!) acontecerão. Quando este fluxo é concluído, então a atividade de subprocesso é encerrada e o fluxo no qual ela se encontra dá seguimento.

Assim, uma forma de demonstrar que o término de um processo dará início a um outro processo, é representá-los como subprocessos de um processo orquestrador, que dá a sequência entre eles, desta forma:

Processo de Participação em Eventos visto fim-a-fim, através da orquestração sequenciada de processos da organização.

Neste cenário, os diagramas dos processos orquestdados não precisam preocupar-se com regras que influenciarão no próximo processo (como identificar se há ou não viagem para a participação no evento). Esta lógica pode ser atribuída ao processo que faz a orquestração:

Processo de Participação em Eventos fim a fim, agora com alguma lógica de roteamento dos processos envolvidos.

Note que neste caso, os eventos de início e fim são do tipo none. Isto porque no caso de processo de Viagens, não é mais um evento de comunicação entre processos que definirá o seu início, e sim o processo orquestrador.

Nesta abordagem o processo de inscrição de eventos pode ser simplificado.

Nesta abordagem o Processo de Viagens Corporativas também pode ser simplificado, tornando-o otimizado para reuso por outros processos de negócio.

As vantagens desta abordagem são:

  • O diagrama orquestrador permite uma visão simples e clara de um processo de negócio orquestrado fim-a-fim. Isto torna-se um pouco mais difícil no cenário de acionamento por comunicação explícita, uma vez que torna-se necessário navegar de um processo para outro para chegar-se ao fim e compreender o contexto geral do processo de negócio.
  • Os processos são independentes da lógica de roteamento da orquestração, tornando-os reusáveis por outros processos de negócio (por exemplo: o processo de viagens corporativas poderia também ser usado em um processo de Execução de Projeto, Apresentação de Treinamentos, etc)
  • É possível criar condições diferentes que levem a orquestração a executar ou não um processo após a realização de outro (como foi feito para definir a execução do processo de viagens e de reembolso), e estas regras podem ser mudadas sem impactar na lógica dos processos adjacentes.

Existem também outras formas de possibilitar a representação de sequência, como uso de eventos de signal, por exemplo. Estas duas entretanto são as mais comuns e que tornam mais visível esta comunicação. O critério de definição de qual abordagem utilizar passa por uma avaliação da organização sobre como manterá todos os seus diagramas de processos reunidos e organizados, através do estabelecimento de uma arquitetura de processos.

Um guia para iniciar estudos em BPMN (V): Subprocessos

Retornando ao tema Atividades (Activities), em nossa série de artigos dedicados ao BPMN Nível 1, há um segundo tipo deste elemento além das tarefas (tasks): são os subprocessos.

Tarefas que em conjunto possuam um propósito específico dentro de um processo de negócio podem ser abstraídas em uma outra unidade de processo e representadas no processo maior por um único objeto do tipo atividade, denominado Subprocesso.

Subprocessos são representados visualmente como retângulos com bordas arredondadas (como as tarefas), porém apresentam um símbolo [+] na base inferior implicando no entendimento que esta atividade contém um conjunto de tarefas. Subprocessos são conectados ao fluxo do processo da mesma forma que as outras atividades, através de conectores de fluxo de sequência.

No exemplo acima, a atividade “Aprovação de exceções de negócio” é um subprocesso, que abstrai um conjunto de atividades cujo propósito é avaliar uma exceção de negócio (por exemplo, crédito para um cliente antigo mesmo que tenha situação financeira negativa) para então dar continuidade à concessão do crédito se esta exceção for autorizada. Abaixo tem-se um exemplo de detalhamento das atividades deste subprocesso.

Em geral, o fluxo que compõe o subprocesso é mapeado em um diagrama separado. Algumas ferramentas permitem criar vínculo entre o diagrama do processo principal e o subprocesso, possibilitando a navegação de um para outro com um ou dois cliques de mouse.

Se o processo que está sendo modelado possui muitas atividades e conexões, tornando-o difícil para a interpretação dos leitores, a utilização de subprocessos pode ser um excelente artificio para organizar o fluxo sem interferir diretamente na execução do mesmo, possibilitando criar uma visão mais abstrata e objetiva das atividades que ocorrem no processo.

Subprocessos também podem ser úteis para reunir partes de fluxos que podem ser repetidas em momentos distintos do processo, caracterizando reuso.

Continue acompanhando! No sexto e último artigo deste guia básico, swimlanes e artefatos para apoiar na organização do diagrama do processo.


Confira todos os artigos deste guia de BPMN Nível 1:

Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários

No artigo anterior iniciamos o estudo dos eventos, detalhando os principais tipos de gatilhos para eventos de início e fim de processo.

O evento intermediário (Intermediate event) sinaliza um ponto no decorrer do processo no qual é previsto que um fato irá ocorrer.

Eventos intermediários podem ser tanto do tipo catch (aguardam a ocorrência do fato para que o processo continue) quando do tipo throw (geram a ocorrência do fato e dão continuidade ao processo).

Em geral os eventos intermediários são conectados ao processo através de conectores de fluxo de sequência, dando o contexto de que ocorrem durante o processo. Entretanto, um evento intermediário também pode ser definido para ocorrer durante uma tarefa tarefa específica. Neste caso, o evento intermediário é anexado à borda da atividade, como mostrado em alguns exemplos abaixo.

Os tipos de evento intermediário mais comuns são:

Tempo ou Prazo (Timer)
Utilizado para representar um fato relacionado a uma condição temporal, como uma data específica (ex. 01 de janeiro), uma data relativa (próxima terça-feira), um intervalo de tempo (em sete dias) ou uma situação de espera de tempo.

O evento de timer é simbolizado por um relógio.

Quando utilizado no fluxo do processo, o evento intermediário de timer representa que o processo deverá parar naquele ponto do processo e aguardar que a condição de tempo se torne verdadeira.

Neste exemplo, quando a tarefa “Preparar viagem” for finalizada, o processo realizará uma pausa aguardando a data de início da viagem. Só então o processo continuará, iniciando a tarefa “Realizar viagem”.

Quando utilizado na borda de uma atividade, o evento intermediário de timer representa que que, enquanto a atividade estiver em execução, o evento poderá acontecer, e neste caso, o fluxo desenhado a partir do evento será executado. Neste caso, o evento intermediário poderá ser de dois tipos:

Timer interrupting
Se o evento ocorrer enquanto a atividade estava sendo executada, ela será interrompida, e o fluxo seguirá pelo conector que se origina no evento.
A borda do evento é dupla e lisa.
No exemplo ao lado, se a atividade “Confirmar recebimento de mercadorias” for concluída  antes da data de entrega prevista, o processo seguirá sua execução pelo fluxo normal do processo. Entretanto, se a data de entrega prevista for atingida e o recebimento das mercadorias não tiver sido confirmado, a tarefa é automaticamente cancelada e o fluxo que sai do evento de timer é disparado, dando início à atividade “Cancelar o pedido”. A atividade de “Confirmar recebimento de mercadorias” não poderá mais ser realizada pois foi interrompida.

 

Timer non-interrupting
Se o evento ocorrer enquanto a atividade estava sendo executada, um fluxo paralelo será iniciado a partir do conector que se origina no evento, mas a tarefa permanece aguardando a sua execução.
A borda do evento é dupla e tracejada.
No exemplo ao lado, se o após dois dias úteis a tarefa “Avaliar pedido” ainda não tiver sido finalizada, o fluxo iniciado no evento é disparado, iniciando a tarefa “Receber aviso de atraso na avaliação”. A atividade de avaliar pedido, entretanto, poderá ser realizada normalmente, dando sequência ao fluxo normal do processo. Se a tarefa “Avaliar pedido” for finalizada antes da ocorrência dos dois dias úteis, então a atividade “Receber aviso de atraso na avaliação” não acontecerá.

 

Condicional (Conditional)
Utilizado para representar um fato relacionado a uma condição de negócio, pausando o processo até que ela se torne verdadeira.

No exemplo ao lado, ações são compradas e então o processo aguarda até que a condição “Valor de venda atingido” se torne verdadeira, dando continuidade ao processo e iniciando a tarefa “Vender ações”.

O evento do tipo conditional também pode ser conectado à borda de atividades como demonstrado anteriormente no tipo timer, podendo ser interrupting ou non-interrupting. Neste caso, o evento será acionado quando a condição de negócio associada se torne verdadeira.

 

Mensagem (Message)
Eventos intermediários de tipo message são utilizados para demonstrar um ponto do processo onde ocorre uma comunicação com um outro processo ou agente externo.

O evento de “throw message” tem como símbolo um envelope preto e sinaliza o envio da comunicação, enquanto o evento do tipo “catch message” tem como símbolo um envelope branco e sinaliza o recebimento da mesma.

No exemplo acima, o Processo de Logística de Treinamentos prevê uma atividade para “Alugar sala de treinamento”. Após alugar a sala, o processo aguarda uma “Comunicação do número de Participantes”. Quando esta comunicação for recebida, a próxima atividade poderá ser iniciada, providenciando cadeiras e mesas para os participantes do treinamento cujas inscrições foram confirmadas.

Este exemplo apresenta o Processo de Inscrições de Treinamento, no qual há uma tarefa para receber as fichas de inscrição e então uma atividade para “Verificar inscrições pagas”. Quando as inscrições pagas forem verificadas, o processo poderá comunicar o número de participantes que estão inscritos, enviando uma mensagem (que será recebida no processo demonstrado anteriormente, no evento com o mesmo nome). Após, o processo segue, iniciando a tarefa de “Providenciar impressão dos certificados”.

A identificação de que a mensagem enviada por um processo é a mesma recebida em outro processo deve ser explicitada utilizando-se a mesma descrição para o elemento.

É possível ainda demonstrar visualmente esta comunicação, colocando-se os dois processos em um mesmo diagrama BPMN e apresentando como esta mensagem flui de um processo para o outro. Neste caso, utiliza-se um conector especial para demonstrar essa ligação entre processos através da troca de mensagens (envio e recebimento): o conector de fluxo de mensagem (message flow).

O conector de fluxo de mensagem pode ser usado apenas para conectar elementos de envio e recebimento de mensagem, e caracteriza-se por uma linha tracejada com uma seta vazada apontando para o destino da mensagem.

É importante ressaltar que para o BPMN, uma comunicação é realizada sempre para fora do processo, nunca entre eventos de mensagem de um mesmo processo.

O evento do tipo mensagem também pode ser utilizado à borda de atividades como demonstrado anteriormente no tipo timer, podendo ser interrupting ou non-interrupting. Neste caso, o evento será sempre “catch”, aguardando a chegada de uma mensagem, e será acionado se a mensagem for recebida enquanto a atividade estiver sendo executada.

Ligação (Link)
Eventos intermediários de link representam uma ligação entre pontos distantes de um mesmo do processo.

Este elemento é utilizado frequentemente em processos cujo número de atividades é muito grande e há pontos do processo que estão visualmente distantes ou bloqueados. Assim, para evitar a sobreposição de conectores de fluxo de sequência, pode-se utilizar este evento, criando uma “ponte virtual” entre pontas do fluxo do processo.

O evento de “throw” link tem como símbolo uma seta preta e sinaliza a ponta de origem da ligação, enquando o evento do tipo “catch” tem como símbolo uma seta branca e sinaliza o destino da mesma.

O exemplo acima apresenta um exemplo de uso de eventos de ligação (link). Observe que há dois eventos de ligação com o mesmo nome: “Continuar negociação”. O primeiro tem a seta preta, indicando a origem da ligação, e o segundo a seta branca, indicando o destino da ligação. Com isso, a leitura que se faz deste diagrama é de que após a realização da atividade “Verificar condições de férias” o processo dá sequência ao fluxo iniciando a tarefa “Avaliar solicitação de férias”.

Para entender melhor o uso de eventos de mensagem e link, leia também estes artigos:

No próximo artigo, um elemento fundamental para a abstação de conjuntos de tarefas na estruturação de diagramas de processos com níveis de profundidade e granularidade diferentes: os subprocessos.


Confira todos os artigos deste guia de BPMN Nível 1:

Caso de Sucesso – Aumento da produtividade e efetividade nos negócios do SICREDI com a adoção de SOA e BPM

Marcio Lermen, gerente de tecnologia do Sicredi

Durante o Oracle Open World 2012 em São Paulo, Marcio Lermen, gerente de tecnologia do Sicredi, apresentou como caso de sucesso a adoção da suíte de SOA e BPM da Oracle para a automação dos processos da organização e o uso do Oracle Exalogic como plataforma de hardware e software para dar alta performance a esta suíte.

De acordo com Marcio, a escolha destas tecnologias foi feita dado o desafio que o Sicredi tinha quanto a decisões e processos manuais em um cenário de negócio complexo, em que os processos estão distribuídos entre as cooperativas do sistema. A adoção destas tecnologias viabilizou o redesenho e automação dos processos, apresentando excelentes ganhos no controle da execução dos processos.

Dentre os benefícios obtidos com esta adoção, foi mencionado o ganho de tempo na execução de um processo. Em alguns casos, a automação de um processo (que antes era ad-hoc e feito via envio de e-mails e trocas de telefonemas) fez com que o ciclo de vida do mesmo, que costumava levar vários dias, pudesse ser realizado no mesmo dia. Além disto, foi mencionado o ganho de desempenho com o uso do Oracle Exalogic, que chegou na ordem de 4 a 6 vezes. Segundo Márcio, para conseguir esta performance foi preciso que todos os serviços envolvidos estivessem dentro do Exalogic.

Como pontos importantes apresentados por ele, foram citados os seguintes fatores:

  • o mapeamento e desenho do processo as-is e to-be antes da automação do mesmo;
  • a definição dos pontos onde serão gerados indicadores (que serão enviados ao BAM na execução) durante a definição do processo;
  • a quebra do processo principal em subprocessos menores, inclusive para facilitar o controle de versão e o desenvolvimento;
  • governança SOA, contendo uma arquitetura bem definida, além da necessidade de uma garantia de que a mesma será utilizada dentro dos projetos.

Foram mostrados alguns exemplos de processos criados utilizando Oracle BPM, sendo que muitos deles foram mapeados e criados em parceria com a iProcess.

É um orgulho para nós poder fazer parte de cases de sucesso em BPM do sicredi.

BPMN: Diferenças entre eventos de Link, Message e Signal

Um dos componentes mais poderosos, e mais difíceis de aprender em BPMN, são os eventos e seus gatilhos (triggers). A especificação BPMN descreve diversos tipos de gatilhos para os eventos, mas não esclarece como ou quando devem ser utilizados.

De forma especial, uma dúvida comum são as diferenças entre estes três gatilhos de eventos de BPMN: link, message e signal.

Link é um elemento de ligação que ajuda a abstrair conexões de sequência em um mesmo processo. Alguns profissionais sugerem que o link seja usado para dar seguimento do desenho do processo em outra página, como em uma documentação, por exemplo. Este é um uso possível, mas dado que a maioria das ferramentas de modelagem atualmente não faz paginação (o diagrama é desenhado em uma única área de trabalho) esta não é a única situação de utilização.

Uma das principais utilidades do evento de link, ao meu ver, é a de abstrair a sequência entre atividades que estão distantes no mapeamento, evitando conectores de fluxo de sequência longos que cruzem inúmeros outros.

No exemplo, os eventos de link com o mesmo nome conectam "virtualmente" pontos distantes do processo, fazendo com que após a atividade 'Verificar condições de férias' o processo siga em sua execução, iniciando a atividade 'Avaliar solicitação de férias'. Com isso, a sobreposição de sequence flows foi evitada, deixando o processo mais legível.

O link só é usado como evento intermediário, e por significar uma sequência implícita não pode ser usado para ligar processos diferentes. Isto significa que, no caso de processos desenhados utilizando pools, não podemos usar eventos de link para fazer com que um processo em uma pool dê continuidade à execução de um outro processo, em outra pool.

Assim, a principal diferença entre o evento de link e para os de message e signal reside no fato de que o primeiro é usado para conectar a sequência de um mesmo processo, enquanto os dois outros tratam da comunicação entre processos.

Entre estes dois eventos – message e signal -, a diferença é um pouco mais discreta. Ambos podem ser utilizados para a comunicação entre processos distintos.

O evento de message é usado para a transmissão/recebimento de informações entre processos. Esta troca de informações, de acordo com a especificação BPMN, pode ocorrer por qualquer meio: verbal, escrita, via email, ou até mesmo sistemática. O foco está no aspecto de que há um emitente (demonstrado através do evento throw message) e um destinatário (demonstrado através do evento catch message). O emitente conhece o destinatário, assim como o destinatário sabe de quem receberá a mensagem (mesmo que os dois processos que se comunicam não estejam desenhados no mesmo diagrama).

Neste exemplo, há uma transmissão de informação de um processo para o outro, representado através da Comunicação do número de participantes do Processo de Inscrições para o Processo de Logística de Treinamentos.

Para mais dicas sobre como modelar corretamente diagramas com comunicação entre processos, veja a postagem BPMN: Modelando corretamente o fluxo de sequência de atividades.

Signal também pode ser utilizado para a comunicação intra e entre processos. A diferença é que enquanto a mensagem tem um destinatário específico, o sinal pode ter um emitente e inúmeros destinatários – e eles não necessariamente se conhecem. O funcionamento do signal é como um broadcast: o throw signal emitirá o sinal (como um apito) e todos os processos que estão aguardando aquele sinal (catch signal) o captarão, dando sequência aos seus fluxos.

Além disso, não há transmissão de informações no envio de sinal. Ele é realmente apenas como um apito, alertando que o evento ocorreu, e que quem estivesse aguardando por ele, agora pode prosseguir com seu processo.

Os diagramas acima demonstram um conjunto de processos sincronizados através de Signals para apoiar o Processo de Monitoramento das Linhas de Comunicação de uma operadora de crédito, que disponibliza as "maquininhas" de cartão nas lojas. O Processo de "Monitoramento da Comunicação" possui uma atividade recorrente que monitora, constantemente, se as linhas telefônicas utilizadas estão todas disponíveis. Se for identificada falha em uma linha de comunicação, o processo dispara um evento de sinal "Erros em linhas de comunicação". Esse sinal é o gatilho de disparo para dois processos: "Processo de Restabelecimento da Comunicação" e "Processo de Contingência da Comunicação". O Processo de restabelecimento inicia um conjunto de atividades para buscar o restabelecimento do serviço. Enquanto isso, o Processo de contingência aguarda algum tempo para verificar novamente se as linhas foram restabelecidas antes de iniciar as ações de contingência (possivelmente porque a contingência tem um custo mais elevado, de forma que a esperar algum tempo para o restabelecimento das linhas pode ainda ser mais viável para a empresa). Depois que as linhas forem restabelecidas pelo "Processo de Restabelecimento da Comunicação", este processo emite o sinal "Linhas de comunicação restabelecidas" e dá seguimento para o cálculo da multa com a operadora de telefonia. O sinal emitido faz com que o Processo de Contingência dê seguimento ao seu fluxo para desligar a contingência (já que a operação voltou ao normal), e também dispara o processo de "Avaliação de SLA do Cliente", no qual são analisados os clientes impactados pela falha no serviço e realiza-se a negociação de possíveis multas pela quebra do nível de serviço.

Signal também pode ser utilizado para a sincronização de um processo com múltiplas instâncias de um outro processo. É o caso do excelente exemplo apresentado no artigo A case for BPMN Signal, por Anatoly Belychook no blog Process is the Main Thing.

Resumindo:

  • Link events são usados para abstrair sequência de atividades em um mesmo diagrama de processo, e por isso só podem conectar uma ponta de um processo a outra de um mesmo processo.
  • Message events são usados para abstrair a comunicação entre processos, e portanto não devem ser utilizados para demonstrar sequência de atividades. Os eventos de message possuem emitente e destinatário conhecidos.
  • Signal events são usados para realizar broadcast de sinal, onde o emitente envia o sinal sem conhecer seus destinatários.