Introdução

A representação de processos de negócio traz inúmeros benefícios para as organizações, podendo ser desde o melhor conhecimento de sua operação à capacidade de disseminação e otimização (melhoria) deste conhecimento. Neste sentido, várias formas de representação de processos foram propostas como Petri Nets ou 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 que todas tentam prescrever explicitamente o fluxo de execução de um processo. Sendo assim, um processo descrito em BPMN, por exemplo, “tenta” antever todas os caminhos possíveis que podem ser percorridos do início ao fim de um processo.

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… Why not?

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. 

É 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

CMMN é o acrônimo para Case Management Model and Notation, cuja especificação se encontra na Versão 1.1 (OMG, 2016). Resumidamente, 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. 

Indo direto ao ponto, a flexibilidade de um modelo descrito em CMMN está centrada na possibilidade de alguns elementos do modelo serem discricionários, ou seja, o usuário que executa o processo decide, em tempo de execução, se vai ou não executar um “elemento”. Fica mais fácil entender voltando ao exemplo do Planejamento de Viagem. A Fig. 4 traz o processo de Planejamento de Viagem representado com CMMN. Reparem que a atividade Reservar Seguro está representada com uma linha tracejada. Esta é a forma usada pela CMMN para indicar que uma atividade é discricionária. Sendo assim o usuário pode simplesmente não executar tal atividade. 

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

Elementos da CMMN

Os elementos que podem ser representados em um modelo CMMN são diversos e não irei apresentar todos. Também gostaria de dizer que 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 é composto por um elemento do tipo Plan Model que contém vários elementos do Plan Item, como descrito na Tabela 1.

Tabela 1 – Elementos da CMMN

Elemento / Ícone	Descrição
Plan Model	Representa o comportamento de um Caso e 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 for satisfeito, o elemento associado poderá ser habilitado. Quando o critério de saída for satisfeito, o elemento associado é “finalizado” (ex: o processo de planejamento de viagem só termina após o pagamento).
Tasks / Discretionary Task	Representa uma parte do trabalho a ser executado. Uma tarefa discricionária indica que o usuário pode decidir se irá acioná-la em tempo de execução (ex: a tarefa de Reservar Seguro).
Milestones	Indica que um objetivo/alvo importante para o domínio do processo foi atingido. (ex: quando o usuário decide fazer o 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). Por favor, 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. Por favor, veja a especificação da OMG para detalhes.

Exemplo – Processo Planejar Viagem

O processo Planejar Viagem visa auxiliar usuários em tarefas de reservas relacionadas com uma viagem. O processo modelado em CMMN e apresentado na Fig. 5 é composto por um elemento Stage denominado Reserva e dentro deste Stage existem várias Discretionary Human Tasks, uma para cada tipo de reserva a ser efetuada. Repare que a as Tasks fazem uso do Decorator #, indicando que estas tarefas podem ser executadas várias vezes (ex: minha viagem pode ter vários trechos com várias pessoas…). 

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

O processo Planejar Viagem pode ser finalizado (habilitando o critério de saída do Plano) de três formas: o usuário cancela a qualquer tempo (User EventListener Cancelar Plano Viagem), o processo fica 15 minutos inativo (Timer EventListener – 15 min), ou o processo de Pagar Viagem é finalizado.

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 as tarefas serão executadas, 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.

A escolha entre utilizar BPMN ou a CMMN deve ser feita de maneira criteriosa e em última análise, estas duas notações devem ser usadas em conjunto. Tipicamente temos um modelo BPMN “chama” um modelo CMMN através de uma call activity e neste caso estaríamos nos beneficiando do que as duas notações têm de melhor, a previsibilidade da BPMN e a flexibilidade a CMMN. Experimente CMMN e mande um feedback para nós.

Ah….É importante ainda ressaltar que sua solução BPMS precisa ser capaz de executar um modelo CMMN em sua plenitude, principalmente os elementos discricionários.

Cheers!!!!!

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.