BPMN 2.0 – Novos Diagramas e Elementos: Introdução a Coreografia

Com frequência a notação BPMN tem sido tema de nossos artigos no blog, em geral relacionados aos elementos do diagrama de orquestração. Entretanto, desde 2011 a notação agregou, em sua última revisão, dois novos diagramas à especificação, o diagrama de conversação e o diagrama de coreografia.

Iniciaremos neste artigo o assunto a respeito das novidades relacionadas aos novos diagramas, começando pelo diagrama de coreografia, então vamos lá!

Diagrama de Coreografia (Coreography Diagram)

Para BPMN a Coreografia  é um tipo de diagrama que difere em propósito e comportamento da representação de um processo de negócio padrão (diagrama de orquestração).

O diagrama de orquestração é o mais conhecido e utilizado pela maioria das ferramentas de modelagem e define o fluxo das atividades do processo de  uma organização. Em contraste, a coreografia  define como processos interagem uns com os outros.

Na coreografia o foco não está na orquestração do trabalho realizado entre os participantes, mas sim na orquestração da troca de informações (mensagens) entre os processos da organização e de outros agentes externos (processos de fornecedores, clientes, etc), demostrando a dinâmica da comunicação entre eles.

As atividades de coreografia são conectadas em um fluxo lógico que representa toda a troca de informações e suas interações que acontece naquele processo de negócio.

Diagrama de Coreografia - foco está na troca de mensagens entre os processos (participantes)

Diagramas de coreografia podem ser vistos também como um contrato de negócio entre os participantes, onde o foco está na troca de informações (mensagens), implica no envio ou recebimento de algum tipo de documento, como é o caso do diagrama acima, onde o contrato de negócio está na forma de uma ordem de compra. Este diagrama representa o Processo de Ordem de Compra, o fluxo demostra a comunicação entre os três participantes (Varejista, Fornecedor e Fornecedor Externo).

Agora veja o mesmo processo representado pelo diagrama de orquestração, evidenciando a orquestração do trabalho realizado entre os participantes e  a sequência das atividades do processo de negócio.

Diagrama de Orquestração - foco na orquestração do trabalho realizado entre os participantes.

Cada participante representa uma piscina (pool) do diagrama de orquestração, raias (lanes) não são representadas no diagrama de coreografia e conectores de fluxos de atividades (message flow) viram atividades na coreografia. Veja este outro exemplo abaixo.

Os participantes representam a piscinas do diagrama de orquestração e os fluxos de atividades viram atividades na coreografia.

Resumindo, podemos dizer que Diagrama de Coreografia:

  • Focaliza a forma como os participantes trocam mensagens, demonstrando a comunicação entre os eles;
  • É a representação dos processos e suas interações;
  • Demonstra o comportamento esperado entre os participantes;
  • É o contrato de negócio de interação entre os participantes.

No artigo seguinte desta série: BPMN 2.0 – Novos Diagramas e Elementos: Coreografia no detalhe, nos aprofundamos um pouco mais no assunto, apresentando os principais elementos BPMN que contribuem para uma modelagem completa. Um descrição detalhada de cada elemento, suas características e como eles são usados em uma coreografia.

Esperamos que tenham gostado desta introdução ao assunto, fiquem a vontade para fazer seus comentários, tirar dúvidas, críticas e sugestões são sempre bem vindas.

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

 

Respondendo a dúvidas: como representar email, planilha ou sistema em BPMN?

Frequentemente, em cursos e consultorias, nos deparamos com questões como a abaixo, encaminhada por um de nossos leitores:

“Estou modelando processos e a determinação que recebemos é sempre usar na atividade o ícone que representa o tipo de tarefa.
Há dúvidas e opiniões diferentes em o que aplicar quando:
– E-mail escrito e enviado por uma pessoa.
– Uso de planilha Excel ou outras ferramentas que não são aplicação do negócio
– Utilização de ferramentas externas como site de banco, ou sistema cuja administração é exclusiva do fornecedor.
Como recomendam a representação desses itens?”

Na verdade não existem elementos no BPMN para representar especificamente estes itens, porque o objetivo da notação é disponibilizar componentes para a representação da sequência lógica da execução de um processo, e não os meios utilizados. Quando representamos uma tarefa em um processo, indicamos que ali acontece uma ação, um trabalho que precisa ser realizado para que o processo siga adiante no fluxo. Planilhas, software, sites, documentos e emails são meios através do qual as tarefas podem ser realizadas – mas não o trabalho em si.

A notação permite representar entradas e saídas de informações através do elemento “data object” ou “message”. Entretanto, eles são apenas elementos acessórios no diagrama e não especificam o tipo de tecnologia usada (planilha, documento, formulário, email, telefonema…). Assim, se para a análise do processo é muito relevante apontar visualmente que meios são usados em uma atividade, utilize este elemento e use sua descrição para esclarecer se é um documento, um formulário ou planilha.

Neste exemplo de processo com implantação manual, alguns exemplos de "meios" como planilhas e formulários representados junto ao processo. Tanto o formulário TR3 quanto o TR3.1 são formulários que transitam entre tarefas (sai de uma e vai para a outra), embora esteja associado implicitamente através do que chamamos "visual shortcut". A planilha de controle de estoque é consultada e eventualmente atualizada durante a tarefa "Verificar estoque". Nesta perspectiva, o email que comunica o solicitante sobre a falta de itens seria produzido na tarefa "Verificar estoque", e provavelmente documentado como um dos procedimentos a serem realizados durante esta tarefa no caso de faltarem itens.

Em relação ao envio de emails, esta é em geral uma questão bastante controversa, e a sua representação depende da perspectiva sob a qual o processo está mapeado. O fato é que é diferente mapear um processo de negócio para análise e documentação ou para execução por um BPMS.

Quando mapeamos um processo de análise e documentação, representamos o processo de negócio sob a perspectiva das pessoas que realizarão o trabalho. Em geral, o envio do email é parte do trabalho de uma tarefa, como por exemplo avaliar alguma coisa (e um dos procedimentos da tarefa é enviar um email notificando a parte interessada). Assim, o envio do email não é representado no fluxo, mas é descrito como um procedimento da atividade.

Em um processo que está sendo mapeado para ser automatizado, a perspectiva muda discretamente. Ela tem a ótica do BPMS, o motor de processos – que é quem realmente executará a atividade do envio do email. Nestes casos, não há uma atividade humana em si. O envio será realizado pelo sistema, automaticamente, e alguém receberá a mensagem (mas nem sempre fará algo com ela – muitas vezes é apenas uma notificação do estado do processo). Para estes casos, costumamos representá-la através de uma atividade de serviço, já que é um serviço de email que será acionado para enviar a informação. Esta tarefa de serviço acaba sendo posicionada na lane da pessoa que receberá a mensagem, e muitas vezes as nomeamos como uma tarefa passiva como “Receber aviso de aprovação”. Para esta situação, muitas ferramentas de automatização de processos customizaram ou estenderam a notação, criando elementos específicos para representar este tipo de atividade (o que é permitido pela especificação BPMN 2.0).

Este exemplo representa um processo mapeado sob a perspectiva da automação, em que o processo será executado e controlado através de um BPMS. O envio do email para o solicitante é enviado automaticamente pelo sistema, a exemplo da sugestão de uso da notação acima para este cenário.

Vale lembrar que as dicas acima não são exatamente definições da notação  (pois a especificação BPMN não entra neste mérito), mas algo que consideramos boas práticas para utilizá-la corretamente.

BPMN: Modelando processos de negócio com elementos avançados (Parte IV)

Neste quarto e último artigo da série “BPMN: Modelando processos de negócio com elementos avançados”, abordaremos de forma especial o subprocesso de eventos, levando em conta as definições de notação.

Subprocesso Eventual (Event-Subprocess)

O subprocesso eventual é parte opcional do processo e é utilizado para tratar com eventos excepcionais que ocorrem no processo pai.

Subprocessos eventuais são acionados pela ocorrência de um evento previsto durante a execução do processo principal. Assemelham-se a outros tipos de subprocessos contidos dentro de um processo pai (e não são reutilizáveis), mas dintinguem-se de outros subprocessos, pois não são ligados ao  fluxo de sequência do processo principal, uma vez que só serão iniciados quando a trigger do evento de início for acionada.

O Subprocesso eventual é representado graficamente por um retângulo com bordas arredondadas e linha tracejada. Na forma contraída, apresenta um símbolo [+] na base inferior implicando no entendimento que esta atividade contém um conjunto de tarefas. Também pode ser representado na forma expandida, demostrando assim seu fluxo no processo pai.

Subprocesso eventual (ou subprocesso de eventos) - Representado pela imagem da esquerda na forma contraída e na imagem a direita na forma expandida.

Um subprocesso de eventos pode ter somente um evento de início e este evento deverá ser necessariamente disparado por algum fato específico que gere seu início (catch). Em outra palavras, o subprocesso eventual não pode ser representado pelo evento de início “none”.

Este fato específico (que gera o início do subprocesso de evento) pode significar as mais diferentes informações. Vejamos as mais comuns:

  • Um fato temporal: uma data (Ex. 01 de março) – Simbolizado por um relógio.

  • Por uma mensagem: Com a chegada de uma informação (Ex. Um documento, um e-mail, um telefonema) – Simbolizado pelo envelope branco.

  • Uma condição: Ex. Estoque menor que 10 unidades – Simbolizado por formulário.

  • Um sinal: Quando algo estiver errado (Ex. Sistema do cumprimento do pedido não respondido) – Simbolizado por um triângulo vazado.

Para mais informações sobre eventos confira os artigos Um guia para iniciar estudos em BPMN (III): Eventos de Início e Fim e Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários.

Event-Subprocess Interrupting e Event-Subprocess Non-Interrupting

Falando um pouco mais sobre o evento de início de um subprocesso eventual, apontamos dois tipos que definem qual o impacto que o subprocesso causará no processo pai. São eles:

Event-Subprocess Interrupting – Evento que interrompe o fluxo do processo principal (pai). Representado por um círculo com linha contínua.

Event-Subprocess Non-Interrupting – Evento que não interrompe o fluxo do processo pai. O processo ocorre em paralelo. Representado por um círculo com linha tracejada.

O exemplo a seguir demonstra o uso de subprocessos eventuais, em um processo muito comum de “Pedido de Reservas”, envolvendo reservas de voo e hotel.

Durante a execução deste processo, podem ocorrer o disparo de qualquer um dos dois subprocessos eventuais:

1 – Pode ocorrer o cancelamento do processo de reservas, interrompendo o processo de negócio e com isso finalizando a solicitação de reservas. Veja que o evento que inicializa o subprocesso eventual de cancelamento é representado graficamente com uma borda de linha contínua (Event-Subprocess Interrupting). Isso significa que ele interromperá a execução do processo principal, e executará este subprocesso.

Event-Subprocess Interrupting

2- Caso o processo não seja cancelado, o cliente pode enviar um pedido de “Status”, retornando a informação da situação do pedido das reservas. Como o evento que inicializa este subprocesso é representado com uma borda com linha tracejada (Event-Subprocess Non-Interrupting), o processo principal não é interrompido, com isso subprocesso eventual é executado em paralelo ao processo principal, fazendo com que o pedido de status seja atendido paralelamente às atividades do processo pai.

Event-Subprocess Non-Interrupting

 

Importante:
– O subprocesso eventual non-interrupting pode ser executado várias vezes durante a execução de um processo, e pode ter várias instâncias em execução em paralelo.

– Uma vez que o processo principal tenha sido concluído, mesmo que o fato gerador do evento ocorra, o subprocesso eventual não será acionado, pois seu ciclo de vida depende do processo principal. Por exemplo, o cliente solicita o pedido de status do pedido porém o processo principal já foi finalizado, este pedido não será processado.


Confira todos os artigos deste guia de BPMN: Modelando processos de negócio com elementos avançados:

BPMN: Modelando processos de negócio com elementos avançados (Parte III)

Prosseguindo com nosso estudo de elementos avançados, neste terceiro artigo da série abordaremos um dos elementos mais utilizados no fluxo de um processo de negócio: os Gateways.

Gateways

Gateways são os elementos de BPMN responsáveis por controlar iterações do fluxo, criando caminhos alternativos ou paralelos no mapeamento do processo ou unificando fluxos para continuação em uma mesma sequência de atividades.

No artigo Um guia para iniciar estudos em BPMN (II): Gateways, vimos também que o gateway é conectado ao fluxo através de setas de fluxo de sequência e é representado visualmente por um losango. O símbolo interno do losango identifica a interpretação lógica representada. Para um estudo completo sobre os gateways indicamos a leitura deste artigo.

Com foco em elementos avançados falaremos sobre dois dos cinco diferentes gateways.

Exclusive Event-Based Gateway

O desvio condicionado por evento é semelhante ao Gateway exclusivo (Databased Exclusive Gateway): indica pontos do processo em que o gateway exclusivo não se baseia em dados de processo, mas sim sobre as mensagens ou eventos externos. Esta forma é usada para exercer controle sobre a execução de determinadas atividades que ficam disponíveis até que um dos eventos sejam executados.

Gateway exclusivo condicionado por eventos – decisão depende do resultado dos eventos imediatamente posteriores a ele.

No gateway condicionado por um evento específico, normalmente o recebimento de uma mensagem determina o caminho que será tomado. Basicamente a decisão é tomada por um outro participante, com base em dados que não são visíveis ao processo e, assim, exigindo o uso do gateway baseada em eventos.

Podemos imaginar: quando nosso processo chegou ao evento baseado em gateway, vamos esperar até que algo aconteça. O evento geralmente é disparado por terceiros (por exemplo, o nosso cliente envia o pagamento para nós). Abaixo é a porta baseada em eventos típicos. Enviamos uma cotação para o cliente, aguardando o cliente confirmar o pedido. Se o cliente envia a confirmação, vamos preparar as mercadorias para o cliente. Se não receber qualquer confirmação do cliente após 15 dias, o pedido é cancelado. Veja o processo abaixo.

Gateway exclusivo condicionado por eventos – O primeiro evento disparado cancela os demais eventos. No exemplo acima, ou o processo recebe a confirmação do pagamento e envia o pedido, ou o processo é cancelado pelo pelo cliente por não ter confirmado em até 15 dias.

Complex

Gateway complexo é usado para modelar o comportamento de sincronização complexa. É sempre indicado que antes de utilizar o gateway complexo, tente usar a combinação de tipos diferentes de gateways.

Gateway Complexo – Criado para dar maior flexibilidade ao BPMN.

Uma Activation Condition Expression (Expressão de ativação de condição) é usada para descrever o comportamento preciso do gateway complexo.

Por exemplo, essa expressão poderia especificar que os tokens em três dos cinco fluxos de sequência de entrada são necessários para ativar o gateway do processo abaixo.

Gateway Complexo – Quando a combinação do fluxo não pode ser utilizada por nenhum outro gateway utiliza-se o gateway complexo.

Obrigado a todos e até nosso próximo artigo!


Confira todos os artigos deste guia de BPMN: Modelando processos de negócio com elementos avançados:

BPMN: Modelando processos de negócio com elementos avançados (Parte II)

Este é o segundo artigo de uma série dedicada ao estudo de elementos avançados de BPMN.

No artigo anterior iniciamos o estudo dos marcadores de atividades, vimos que cada marcador tem uma função específica que determina o comportamento de uma atividade durante sua execução. Neste artigo daremos andamento a este estudo finalizando a explicação ao que diz respeito a estes atributos.

Atividades de Múltiplas Instâncias (Multi-Instace Activity)

Representado por um marcador de 3 barras paralelas verticais presente na parte inferior central da atividade, dispara múltiplas instâncias da mesma atividade.

O marcador de múltiplas instâncias pode ser aplicado a uma tarefa como em um subprocesso.

O atributo de múltiplas instâncias permite que uma atividade tenha “N” repetições, podendo ser instanciada em paralelo diversas vezes.

Neste exemplo, o processo demostra o fluxo do processo de “Cadastro de Orçamentos”, no qual há uma tarefa para cadastrar orçamento. Esta tarefa permite que um ou mais orçamentos sejam cadastrados ao mesmo tempo. Quando a tarefa de cadastro dos orçamentos finalizar, o processo enviará estes cadastros para a tarefa que avaliará os orçamentos para escolher o vencedor.

Subprocesso ad-hoc

Um subprocesso ad-hoc indica um conjunto de atividades desempenhadas sem uma sequência pré-definida pois suas tarefas (tasks) não são conectadas pelo fluxo de sequência (sequence flow).

Subprocesso ad-hoc

É importante ressaltar que não existe uma obrigatoriedade na execução de todas as tarefas de um processo ad-hoc.

Estas atividades estão relacionadas, geralmente, a atividades humanas onde a quantidade de vezes e a ordem são definidas pelo executor.

O exemplo acima trata de um subprocesso ad-hoc. Como o subprocesso não possui um fluxo de sequência, suas atividades podem ser executadas sem sequência ou obrigatoriedade.

Tarefa de Compensação (Compensation)

A tarefa de compensação é uma tarefa particular e não faz parte do fluxo normal de um processo. Em alguns momentos na modelagem de processos de negócios, precisamos “desfazer” uma atividade ou processo e em alguns casos, quando desfeito, precisamos gravar esta operação, o que requer uma etapa exclusiva representada por uma tarefa de compensação (compensation).
Este “desfazer” o processo poderia ser representado por um subprocesso, gerando um fluxo muitas vezes complexo. A tarefa de compensação resolve este problema com apenas uma tarefa.

A tarefa de compensação é representada como uma tarefa normal, mas com um pequeno símbolo que se parece com o botão de rebobinamento num leitor de áudio (dois pequenos triângulos apontando para a esquerda).

A tarefa de compensação é utilizada exclusivamente para executar a compensação de uma atividade já realizada no processo.

Sua conexão é realizada através da associação de compensação (compensation association) e ligado ao evento anexado a atividade já realizada. Este evento é conhecido como catch compensation.

No exemplo acima, por uma determinada condição do processo, a atividade “Reservar van”, já realizada, deverá ser compensada, levando ao seu cancelamento.

Subprocesso de Transação (Transiction)

Transação é um tipo de subprocesso que contém um conjunto de atividades, logicamente relacionadas, e pode seguir um protocolo transacional específico. Ele faz com que todas as suas atividades sejam completadas com sucesso ou canceladas (compensadas).

O subprocesso de transação é representado por um retângulo de bordas arredondadas e linha dupla e pode ser representado tanto na forma contraída (collapsed) como na forma expandida (expanded).
A fronteira da atividade será uma linha dupla que indicará que trata-se de uma transação.

Subprocesso de Transação (Transiction)

Para que o subprocesso de transação seja finalizado com sucesso todas as suas atividades devem ser completadas. Veja o exemplo abaixo que demostra a representação do subprocesso de transação.

O exemplo acima demostra que é necessário que a reserva da van e do passeio no parque sejam concluídos para que o processo de reservas seja concluído com sucesso, levando a atividade de faturar comprador. Caso a reserva da van seja concluída e do passeio não, a reserva da van é cancelada (e vice-versa). No caso de cancelamento, um evento intermediário de cancelamento (cancel), mostrará o caminho que o fluxo irá seguir (fracasso), levando a execução da atividade “Avisar da indisponibilidade”. Erro (error): quando isto ocorrer significa que nenhuma conclusão bem sucedida como também nenhuma conclusão fracassada ocorreu. Neste caso usa-se a exceção para mostrar o perigo. Quando um perigo é detectado, a atividade é interrompida (sem compensação) e o fluxo prossegue pelo evento intermediário de exceção (erro).

Obrigado a todos e até nosso próximo artigo!


Confira todos os artigos deste guia de BPMN: Modelando processos de negócio com elementos avançados:

BPMN: Modelando processos de negócio com elementos avançados (Parte I)

A notação BPMN (Business Process Model and Notation), atualmente na versão 2.0, reúne um conjunto de elementos intuitivos e robustos, que auxiliam usuários técnicos e de negócio na documentação de seus processos em diferentes níveis de detalhes, de maneira que possam mapear, de maneira padrão, todos os processos de negócios de sua organização.

A lista de elementos gráficos de BPMN apresenta desde elementos essenciais para a modelagem dos processos, utilizados em uma documentação simples, até elementos avançados, requeridos para desenhar modelos de processos complexos.

Dedicaremos os artigos semanais de janeiro para contribuir com o estudo dos elementos avançados, requeridos para a compreensão de uma modelagem complexa.

Marcadores de Atividades

Abordaremos neste primeiro artigo os marcadores de atividades, conhecidos também como atributos especiais.

Os marcadores de atividades ou atributos especiais tem o objetivo de indicar o comportamento específico de uma atividade durante sua execução.

Marcadores de Atividades

Marcadores de Atividades

No artigo “Um guia para iniciar estudos em BPMN”, vimos que atividades (activities) representam um trabalho realizado em uma etapa do processo de negócio e podem ser do tipo “Tarefa” (task) ou “Subprocesso” (subprocess).

Subprocesso

Um subprocesso representa um conjunto de atividades realizadas dentro de um processo de negócio. São representados graficamente de duas formas, contraído ou expandido.

A Imagem acima demostra o subprocesso contraído (collapsed), representado pelo símbolo “+” indicando a existência de outro nível de detalhe, que pode ser expandido (expanded).

Subprocesso contraído

subprocesso contraído

Subprocesso contraído (Busca de informações): No exemplo acima o processo inicia-se com a execução da tarefa de solicitação de reembolso, após sua execução o fluxo segue dando início ao subprocesso que buscará as informações das despesas. Após a análise destas informações, o subprocesso é finalizado voltando ao fluxo do processo principal da solicitação de reembolso e partindo para a tarefa da aprovação do gestor.

Subprocesso Expandido

O mesmo subprocesso pode ser representado de forma expandida (expanded), apresentando o seu conjunto de detalhes no próprio processo “pai”.

Subprocesso Expandido

Exemplo de subprocesso expandido: O mesmo fluxo do subprocesso contraído é executado, porém o subprocesso de busca de informações apresenta o detalhamento de suas atividades visíveis no processo “pai”.

Atenção: O fluxo do processo “pai” não pode atravessar de forma alguma a fronteira do subprocesso.

subprocesso Expandido fronteira atravessada

Uma regra importante no BPMN é que um subprocesso nunca pode ter sua fronteira cruzada pelo fluxo de sequência. O fluxo de sequência apresenta a ordem de execuções das atividades em um processo e nunca entre processos. Os fluxos de sequência de entrada e saída devem ser ligados no limite do subprocesso (sua borda), e não deve iniciar e terminar os eventos no nível de expansão dentro do retângulo arredondado (subprocesso expandido), conforme mostra a figura acima.

Loop – Atividade cíclica

Representado por uma linha circular com seta (conforme imagem abaixo), atributo em atividades que simula a operação “do-while”, uma atividade pode ser executada várias vezes em ciclo.

Utilizada quando o número de repetições não é conhecido;
A atividade de repetição será repetida enquanto a condição do loop for atendida.

Loop

Loop – Atividade cíclica

Uma atividade de loop terá uma expressão booleana que é avaliada para cada ciclo. Se a expressão for verdadeira, então irá continuar. O loop irá avaliar a expressão após a realização da atividade, isto significa que atividade será realizada pelo menos uma vez.

Loop subprocesso

No exemplo acima, o subprocesso “Seleção de Candidato” avalia candidatos a serem selecionados para entrevista. A expressão booleana para este loop poderia ser “O candidato não passou na seleção?” se a resposta for “verdadeira” então a atividade será realizada novamente e se for “falsa” o processo seguirá seu fluxo.

Em nosso próximo artigo:
Continuaremos o estudo sobre os Marcadores de Atividades, iniciado neste primeiro artigo.


Confira todos os artigos deste guia de BPMN: Modelando processos de negócio com elementos avançados:

Um guia para iniciar estudos em BPMN (VI): Swimlanes e Artefatos

Este é o último artigo de uma série de seis postagens sobre a utilização dos elementos básicos da notação BPMN.

Neste artigo, tratamos alguns elementos utilizados a nível de organização do diagrama do processo: swimlanes para atribuir visualmente responsabilidades sobre as atividades, e artefatos para agregar informações adicionais que possam contribuir com a compreensão da lógica do processo de negócio.

Swimlanes

Swimlanes são os elementos de BPMN utilizados para organizar os processos de um diagrama, definindo o escopo de cada processo e possibilitando identificar os papéis responsáveis pela execução de cada atividade do processo.

Estes elementos são definidos em uma estrutura semelhante a uma piscina (pool) e suas raias (lanes).

Uma pool pode conter apenas um processo de negócio. Processos de negócio distintos devem estar contidos, cada um, em uma pool específica.

Uma pool pode conter tantas lanes quantas forem necessárias para caracterizar os participantes envolvidos na realização das atividades do processo.

A prática comum é desenhar as pools e suas lanes horizontalmente, mas a notação permite a representação vertical.

No exemplo acima, a pool contém todo o processo para conceder crédito. O nome do processo está na borda da pool, que é o retângulo inteiro contendo todo o “Processo de Concessão de Crédito”. Este processo contém atividades que envolvem dois papéis: o Gerente da Conta e o Gerente do Produto. Cada é representado no processo através de uma lane da pool. O diagrama de processos utilizando pools e lanes facilita a identificação visual da troca de mãos da responsabilidade de agir em cada etapa do processo.

As pools são nomeadas com a identificação do Processo (quando o processo modelado está em nível de detalhe operacional) ou com a identificação do Participante (por exemplo, uma entidade externa que se envolve de alguma forma com o processo de negócio modelado em outra pool).

No exemplo acima temos o exemplo de dois processos que se comunicam através de message flow. Observe que cada processo está contido em uma pool. Uma pool pode conter apenas um processo de negócio. Processos de negócio distintos devem estar contidos, cada um, em uma pool específica. A interação entre processos se dá por comunicação, utilizando-se o conector de message flow.

Em alguns casos, pools podem não detalhar o seu conteúdo, mas figurar em um diagrama apenas como um apontamento visual de que aquele processo existe no contexto de negócio no qual um processo comunica-se com outros processos ou entidades. Nestes casos, chamamos as pools não detalhadas de collapsed ou black box (caixa preta).

No exemplo acima, o mesmo processo agora é apresentado em um diagrama que demonstra a comunicação do Processo de Concessão de Crédito com os participantes externos Cliente e SERASA. Estes participantes também possuem seus processos, porém o detalhamento das atividades realizadas em cada um é transparente para o Processo de Concessão de Crédito. Por este motivo, estes participantes são representados no processo como pools black box. Observe que a comunicação entre os processos (ou do processo modelado com os outros processos/participantes) é sempre representada através do conector de message flow.

Artefatos (Artifacts)

Além dos elementos de fluxo (atividades, gateways e eventos), dos elementos conectores (fluxo de sequência e fluxo de mensagem) e dos elementos organizacionais (swimlanes), BPMN oferece elementos adicionais para sinalização visual do processo mas que não influenciam no fluxo do processo. São elementos de anotações, que podem ser utilizados para adicionar informações complementares ao processo.

O objeto de dados (data object) é um elemento que representa um conjunto de informações no contexto do processo, de uma atividade ou de uma troca de mãos (através do fluxo de sequência). É representado por uma página com a ponta dobrada.
No exemplo, “Lista de alunos” é um objeto de dados que transita da tarefa “Verificar inscrições pagas” para “Providenciar impressão dos certificados”.

O artefato de anotação de texto (annotation) é um elemento que pode ser utilizado para agregar comentários ao processo ou a um elemento. É representado por uma área de texto marcada com a borda lateral, e pode ou não estar conectado a elementos do diagrama.
No exemplo, há uma anotação na tarefa “Preparar cadeiras e mesas” que complementa o entendimento da tarefa.

O artefato de grupo (group) é um elemento de anotação visual que pode ser utilizado para sinalizar grupos de atividades dando-lhes algum destaque. O grupo é uma simples anotação e não influencia no fluxo do processo, podendo inclusive ser desenhado cruzando lanes e pools. É representado por um retângulo com bordas arredondadas e linha tracejada.
No exemplo, há um grupo denominado “Controle das Inscrições” destacando um grupo de elementos relacionados a este controle. Procure abstrair a existência do grupo e note que o fluxo do processo não se altera se este elemento for ou não utilizado.

O conector de associação (association) é um conector específico para conectar os elementos de artefatos ao diagrama, e é representado por uma linha pontilhada, podendo ou não apresentar setas em “v” (ele é distinto do message flow, que tem a linha tracejada e ponta de triângulo).
No exemplo, os artefatos de objeto de dados e anotação estão ligados ao fluxo do processo através de conectores de associação.
Com este artigo, finalizamos nosso guia para iniciar estudos em BPMN.


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

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:

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.