Introdução

A representação de processos de negócio traz inúmeros benefícios para as organizações. Além disso, pode proporcionar desde o melhor conhecimento de sua operação até a capacidade de disseminação e otimização (melhoria) deste conhecimento. Nesse contexto, várias formas de representação de processos foram propostas, tais como Petri Nets, Workflow Nets, Event-Driven Process Chain (EPC) e Business Process Management Notation (BPMN). Um fator em comum presente nestas formas de representação de processos é o fato de que todas tentam prescrever explicitamente o fluxo de execução de um processo. Portanto, um processo descrito em BPMN, por exemplo, “tenta” antever todos os caminhos possíveis que podem ser percorridos do início ao fim de um processo.

Exemplo de processo prescritivo em BPMN

Um exemplo de um processo prescritivo em BPMN seria um modelo com objetivo de descrever os possíveis fluxos a serem executados no planejamento de uma viagem (Fig. 1). Idealmente podemos dizer que um fluxo que segue o caminho Reservar Passagem -> Reservar Hotel -> Reservar Seguro -> Reservar Carro, parece ser evidente para a maioria dos cenários. Entretanto, não podemos esquecer que quem “pilota” este processo é um ser humano! E que este ser, muda de opinião por motivos conhecidos ou obscuros… Neste caso, o piloto do processo poderia, por exemplo, optar por não Reservar Seguro. Claro que a modelagem do processo neste caso teria que levar em consideração que esta parte do fluxo é opcional (Fig. 2). 

Há casos em que o piloto do processo é bem excêntrico (meu caso!) e além de escolher qual parte do fluxo quer executar, também quer escolher a ordem.  Afinal, se aquele hotel 5 estrelas estiver com uma super promoção em uma data alternativa, por que não?

Claramente, representar um processo que dá tal autonomia para os “pilotos” pode levar a um modelo que chamamos de espaguete (Fig.3  é apenas o início…) e embora estes modelos possam ser sound (WESKE, 2016) e ser executado por um Business Process Management System (BPMS) (DUMAS, 2018), ele perde uma grande utilidade – a de ser compreendido por humanos. 

Lembre-se

É importante perceber que embora existam processos normativos (DUMAS, 2018), onde seguir o processo prescrito é mandatório, há um apelo crescente para os chamados Processos Intensivos em Conhecimento  (Knowledge Intensive Processes) (DI CICCIO, MARRELLA, RUSSO, 2012) que tentam conferir um grau de liberdade aos Trabalhadores do Conhecimento (Knowledge Workers).  Um exemplo clássico de PIC é o processo de triagem em hospitais. São tantas variáveis envolvidas (paciente, grau do problema, lotação do hospital, ocupação do staff, etc.) que construir um modelo normativo pode ser difícil.

É importante também verificar que a própria OMG, entidade que normatiza a BPMN, prevê a possibilidade de se modelar subprocessos ad-hoc em BPMN (OMG, 2014). Estes subprocessos permitem a representação de atividades sem relacionamentos de ordem, ou seja, a ordem só é definida pelo usuário (“piloto do processo”) no momento da execução. Ocorre que subprocessos ad-hoc não permitem o controle das atividades como a CMMN permite, ou seja, por que não experimentar CMMN para esta parte do processo? 

CMMN (Case Management Model and Notation)

CMMN é o acrônimo para Case Management Model and Notation, cuja especificação se encontra na Versão 1.1 (OMG, 2016). Em resumo, a CMMN é uma notação gráfica que permite a representação de casos complexos de processo flexíveis que requerem um certo grau de não-determinismo. Além disso, a flexibilidade do modelo CMMN permite que certos elementos sejam discricionários, ou seja, o usuário decide em tempo de execução se executará ou não um elemento.

A Fig. 4 traz o processo de Planejamento de Viagem representado com CMMN. Vale ressaltar que a atividade Reservar Seguro está representada com uma linha tracejada, usada pela CMMN para indicar que uma atividade é discricionária. Portanto, o usuário pode simplesmente não executar a atividade.

Analisando um pouco mais a Fig. 4, vemos que não há dependência de ordem entre as atividades (não há relacionamentos). Portanto, o usuário também define, em tempo de execução, em que ordem irá executar as atividades. É importante observar as combinações válidas para execução (Fig. 4 lado direito).

Elementos da CMMN

Embora existam várias fontes que descrevem os elementos da CMMN, as mais importantes são: a especificação da OMG, que é a fonte oficial; e o manual da sua solução BPMS (Camunda, Flowable, Signavio, etc), que interpreta a especificação e a expõe na sua infraestrutura. Resumidamente, um modelo descrito em CMMN compõe-se de um elemento do tipo Plan Model que contém vários elementos do tipo Plan Item, conforme descrito na Tabela 1.

Tabela 1:

Tabela 1 – Elementos da CMMN

Elemento / Ícone	Descrição
Plan Model	É o comportamento de um Caso. Pode conter vários Plan Items como Stages, Tasks, Milestones etc. (ex: o processo de planejamento de viagem).
Stage / Discretionary Stage	Representa uma etapa ou estágio do processo, podendo conter itens como Stages, Tasks, Milestones etc. Um estágio pode ser discricionário, ou seja, o usuário decide se irá acioná-lo em tempo de execução (ex: um subprocesso de pagamento complexo).
Case File	Indica a utilização de um agregado de informações (ex: um arquivo).
Sentries	Definem critérios de entrada ou saída para certos elementos do modelo como Plan Models, Stages e Tasks. Quando o critério de entrada é satisfeito, o elemento associado é habilitado; quando o critério de saída é satisfeito, o elemento associado é “finalizado” (ex: o processo de planejamento de viagem só termina após o pagamento).
Tasks / Discretionary Task	Uma tarefa representa parte do trabalho a ser feito, sendo discricionária, o usuário pode decidir acioná-la em tempo de execução (ex: Reservar Seguro).
Milestones	Indica a realização de um objetivo crucial para o processo (ex: pagamento da viagem).
Events	Indica algo que acontece ao longo da execução do processo, podendo, por exemplo, habilitar a execução de uma tarefa ou o fim de um estágio. (ex: interromper o processo de compra caso não haja atividade por 15 minutos).
Decorators	Os Elementos de modelagem acima podem ser melhor detalhados com certos símbolos. Por exemplo: um Estágio pode ser obrigatório (Required Stage) ou um Evento pode ser um temporizador (Timer Event).  Existem várias combinações válidas para o uso de Decoradores (uma Tarefa é Humana e Obrigatória). Veja a especificação da OMG para detalhes.
Associations	Os Elementos de modelagem acima podem estar relacionados a outros elementos através de associações. Por exemplo quando uma ocorrência de um evento pode habilitar um sentry e, portanto, estes elementos devem estar associados. Como Decorators, existem vários tipos de associações. Veja a especificação da OMG para detalhes.

Exemplo – Processo Planejar Viagem

O processo de Planejar Viagem visa auxiliar os usuários em tarefas de reservas relacionadas com uma viagem. Além disso, o processo modelado em CMMN, apresentado na Fig. 5, compõe-se de um elemento Stage denominado Reserva. Dentro deste Stage, várias Discretionary Human Tasks existem, uma para cada tipo de reserva a ser efetuada. É importante observar que as Tasks utilizam o Decorator #, indicando que essas tarefas podem ser executadas várias vezes (por exemplo, minha viagem pode ter vários trechos com várias pessoas).

O Stage Reserva ainda contém um User EventListener, indicando que a qualquer momento da reserva, o usuário pode decidir finalizá-la. Isso habilita assim o critério de saída (Sentrie), o milestone (Reserva Finalizada) e o Processo de Pagar Viagem. É notável que estes quatro últimos elementos estão encadeados utilizando associações do tipo occur, como se fossem um fluxo em um modelo BPMN. Em outras palavras, quando o evento “ocorre”, ele habilita o critério de saída do estágio, que por sua vez habilita o milestone etc.

O usuário pode finalizar o processo Planejar Viagem de três formas diferentes. Primeiramente, pode fazê-lo cancelando a qualquer momento, utilizando o User EventListener Cancelar Plano Viagem. Além disso, outra opção é deixando o processo inativo por 15 minutos, utilizando o Timer EventListener – 15 min. Por último, o usuário pode concluir o processo de Pagar Viagem para finalizá-lo.

Conclusão

Embora este tenha sido um pequeno exemplo de um modelo em CMMN, as vantagens e desvantagens são claras. A primeira grande vantagem para o uso da CMMN é o grau de flexibilidade dado ao usuário do processo. Em última análise, este usuário decide quando e em que ordem executar as tarefas, permitindo o planejamento da execução e evitando o uso de um processo normativo e inflexível. Uma outra vantagem está no fato em que o modelo que permite esta flexibilidade é relativamente simples, ou seja, sem a combinação de vários gateways. 

Porém, o uso da CMMN traz também algumas desvantagens.  Primeiro, o entendimento de como o processo funciona não é tão imediato quando se compara com um fluxo BPMN. Notem que o modelo Planejar Viagem não traz um Start Event, ou seja as tarefas são habilitadas e desabilitadas de acordo com um conjunto de critérios.  Por exemplo, quando o processo Planejar Viagem é instanciado, o usuário deverá ter acesso a 6 funcionalidades – Reservar Passagem, Reservar Hotel, Reservar Carro, Reservar Seguro, Finalizar Compra e Cancelar Plano de Viagem. Um outro ponto a ser percebido é que a CMMN não permite a modelagem de raias e isto impede a descrição de processos com comunicação.

Os usuários devem fazer a escolha entre usar BPMN ou a CMMN de maneira criteriosa. Além disso, em última análise, eles devem usar essas duas notações em conjunto. Tipicamente, temos um modelo BPMN “chama” um modelo CMMN através de uma call activity. Nesse caso, estaríamos nos beneficiando do que as duas notações têm de melhor: a previsibilidade da BPMN e a flexibilidade da CMMN. Portanto, experimente CMMN e mande um feedback para nós. É importante ainda ressaltar que sua solução BPMS precisa ser capaz de executar um modelo CMMN em sua plenitude, principalmente os elementos discricionários.

Referências Bibliográficas

DI CICCIO, C.; MARRELLA, A.; RUSSO, A.  Knowledge-intensive processes: characteristics, requirements and analysis of contemporary approaches. Journal on Data Semantics, 4(1): pp. 29–57, 2015.

DUMAS, M.; LA ROSA, M.; MENDLING, J.; REIJERS, H. A. Fundamentals of Business Process Management, 2ª edição. Springer, 2018. OMG | Object Management Group. Disponível em: <https://www.omg.org/>. Acesso em: 5 maio 2020.

OMG. Business Process Model & Notation (BPMN) | Object Management Group, 2014. Disponível em: <https://www.omg.org/bpmn/index.htm>. Acesso em: 5 maio 2020.

OMG. Case Management Model and Notation Specification | Object Management Group, 2016. Disponível em: <https://www.omg.org/spec/CMMN>. Acesso em: 5 maio 2020.

WESKE, M. BPMN Meets DMN: Business Process and Decision Modeling, 2016. Curso Online Disponível em: <https://open.hpi.de/courses/bpm2016/items/4CUDfxDyzBPfaxugw3z7to>. Acesso em: 5 maio 2020.