O que é Notação e Modelo de Gerenciamento de Caso (CMMN)

Processo Ad Hoc

Processos ad-hoc são conjuntos de atividades de negócios e artefatos correspondentes (por exemplo, informações, decisões e produtos) que só podem ser padronizados em um alto nível de agregação. Os tipos reais de atividades e sua ordenação são diferentes de caso para caso.

Aqui estão as características do Processo Ad-hoc:

• Embora certas atividades possam ser previstas, grande parte do processo não pode ser totalmente especificada no início, pois requer informações que só se tornam disponíveis de alguma forma no projeto.
• Se assumirmos que no contexto de processos ad-hoc o próximo passo nunca é determinado, sua execução não pode ser controlada por sistemas de informação baseados em processos clássicos, na maioria dos casos, os trabalhadores do conhecimento estão no controle do processo.
• Parece impossível pensar em todas as possibilidades para um processo ad-hoc em tempo de design, tal modelo de processo se tornaria complexo e difícil de gerenciar

BPMN vs CMMN

Nas últimas décadas, tem havido um foco em modelar e automatizar processos bem estruturados e rotineiros. O BPMN é melhor usado para trabalho bem estruturado e altamente previsível, onde os trabalhadores do conhecimento executam principalmente tarefas, enquanto o CMMN cobre a seção de processos menos previsíveis com o envolvimento ativo dos trabalhadores do conhecimento que tomam decisões e planejam durante o tempo de execução

O gerenciamento de casos (CM) foi introduzido como uma ferramenta para trabalhadores do conhecimento por van der Aalst em 2005. Em maio de 2014, a OMG publicou um  padrão para gerenciamento de casos chamado Case Management Model and Notation (CMMN) . Seu foco é apoiar processos imprevisíveis, intensivos em conhecimento e fracamente estruturados. O gerenciamento de casos é um tipo de tecnologia de processo de negócios que não usa fluxo de controle para descrever o processo.

O gerenciamento de caso é sobre capacitar os trabalhadores do conhecimento, fornecendo-lhes acesso a todas as informações sobre o caso e dando-lhes discrição e controle sobre como um caso evolui. Gestão de casos não é sobre o processo, é sobre os trabalhadores. Ao contrário dos processos clássicos, um determinado objetivo e oferecer possibilidades de escolha são mais importantes do que a maneira de atingir o objetivo em si.

Aqui listamos as diferenças entre BPMN e CMMN:

A Notação Declarativa  não tenta modelar o fluxo de um problema; eles estabelecem os resultados desejados, ou seja, especificando o que eles querem que aconteça, mas não como isso deve acontecer. SQL é um exemplo de programação declarativa porque não tenta controlar o fluxo de um programa; ele simplesmente indica o que gostaria que aparecesse, mas não como é feito.

A Notação Imperativa , por outro lado, tenta modelar o fluxo de um problema; por exemplo, linguagens de programação imperativas como Java ou C++, eles estabelecem comandos que dirão ao compilador como eles desejam que o código seja executado, mas não explicitamente o que eles querem que aconteça.

Processo Estruturado x Caso x Processo Ad-Hoc

Tempo de design vs tempo de execução

Não há modelo de fluxo de sequência no CMMN. A execução de uma tarefa depende de eventos e condições chamadas sentinelas Uma sentinela captura a ocorrência de um determinado evento ocorrendo ou uma condição sendo cumprida dentro de um caso. As sentinelas são usadas como critérios de entrada e saída. Observe que os diamantes preto e branco representam os critérios.

Um Caso tem duas fases distintas que são tempo de design e tempo de execução, conforme descrito a seguir:

Tempo de projeto

Durante a fase de tempo de design, os analistas de negócios se envolvem na modelagem, que inclui a definição das Tarefas (itens de plano) que sempre fazem parte de segmentos predefinidos no modelo de Caso e as Tarefas “discricionárias” que estão disponíveis para o responsável pelo caso que a ser aplicado opcionalmente com base em seu critério.

Tempo de execução

Na fase de tempo de execução, os responsáveis ​​pelo caso executam o plano executando Tarefas conforme planejado e, opcionalmente, adicionando Tarefas discricionárias à instância do plano de caso em tempo de execução.

Resumo do diagrama CMMN

Este exemplo ilustra o processo de escrita em papel modelado com CMMN. Suponha que a redação do papel seja um trabalho de conhecimento intensivo e possa ser tratado de diferentes maneiras. Vamos investigar este exemplo um pouco mais a seguir:

1. O processo tem dois marcos que devem ser alcançados:

• Rascunho concluído
• Documento concluído

1. Várias tarefas (por exemplo,  Criar TOC ) são deixadas a critério do autor.
2. O estágio Preparar Rascunho  com  Escrever texto  e  a tarefa Integrar Gráficos  são obrigatórios.
3. Esta etapa definiu a regra de repetição que é simbolizada pelo decorador de repetição (ou seja,  hash ).
4. Embora  o tópico de pesquisa  seja uma tarefa obrigatória, a tarefa de  organizar as referências  deve ser decidida em tempo de execução. É semelhante a  criar gráficos  e  gerar lista de figuras .
5. O processo será concluído quando  o documento for criado  ou o  prazo for atingido .

* Extraído da especificação OMG Case Management Model and Notation

Observação

• Um modelo de plano de caso é representado usando uma forma de “pasta”
• O nome do Case pode ser colocado no retângulo superior esquerdo.
• Os vários elementos de um Modelo de Plano de caso são representados dentro do limite da forma do Modelo de Plano de caso.
• O diagrama mostra um exemplo de um modelo de plano de caso.

Conceitos básicos do CMMN

O modelo de comportamento completo de um Caso é capturado em um  Modelo de Plano de Caso . Para um modelo de Caso específico, um modelo de Plano de caso compreende todos os elementos que representam o plano inicial do caso e todos os elementos que suportam a evolução posterior do plano por meio do planejamento em tempo de execução pelos responsáveis ​​pelo caso. Existem quatro tipos de itens de plano:

Tarefas

Uma tarefa é uma unidade de trabalho. Existem três tipos de tarefas:

Tarefas (Tarefa Discricionária)

As tarefas sempre fazem parte de segmentos pré-definidos no modelo Case. Além das tarefas, existem Tarefas Discricionárias que estão disponíveis para o Responsável pelo Caso, para serem aplicadas opcionalmente com base em seu critério. Uma tarefa discricionária é representada por uma forma de retângulo com linhas tracejadas e cantos arredondados/ Observe que, qualquer tipo de tarefa pode ser discricionária:

Ouvintes de eventos

Um evento é algo que acontece durante o curso de um Caso. Por exemplo, a habilitação, ativação e encerramento de Etapas e Tarefas ou a realização de Marcos.

Marco

Um Marco representa uma meta alcançável, definida para permitir a avaliação do andamento do caso. Nenhum trabalho está diretamente associado a um Marco, mas a conclusão de um conjunto de Tarefas ou a disponibilidade de entregas-chave (informações no Arquivo de Caso) normalmente levam ao cumprimento de um Marco. Um Marco pode ter zero ou mais critérios de entrada, que definem a condição quando um Marco é atingido.

Por exemplo, temos um acordo de nível de serviço (SLA) no processo compatível que pode ser modelado usando um ouvinte de evento de timer e um marco, conforme a seguir.

Palco e Palco Discricionário

• O estágio pode ser considerado uma ‘fase’ em um caso e normalmente agrupa várias tarefas.
• É um recipiente de elementos a partir do qual o plano do caso é construído e pode evoluir ainda mais.
• Etapas podem ser consideradas “episódios” de um Caso. Eles podem ser considerados como subcasos (semelhantes aos subprocessos em BPMN) e também são executados em paralelo.
• O palco é representado por uma forma de retângulo com cantos angulares e um marcador na forma de um sinal “-” em uma pequena caixa no centro inferior (“-” designa estágios expandidos).
• O estágio discricionário pode ser adicionado ‘opcionalmente’, ‘ad-hoc’, ao plano a critério do usuário.

A figura abaixo mostra um Estágio expandido com um sub Estágio e três Tarefas.

Critério

O critério nos permite descrever quando uma tarefa, estágio ou marco deve estar disponível para execução (critérios de entrada) ou quando um caso (plano de caso), estágio ou tarefa deve terminar de forma anormal (critérios de saída). Critérios tem as duas partes opcionais a seguir:

• Um ou mais eventos de disparo (chamados onParts). Estes são eventos que irão satisfazer a avaliação dos critérios de entrada ou de saída

Podemos pensar nos critérios que formam uma sentença da seguinte forma:

([ on < Event 1 >[, on < Event 2 >[, . . .]] ]) AND ([ if < Boolean condition > ])

Observe que:

• Onde colchetes ([ ]) indicam partes opcionais da frase e colchetes angulares (< >) são espaços reservados a serem substituídos.
• tanto a onPart quanto a ifPart são opcionais  na frase, mas para que ela faça sentido, pelo menos uma delas deve estar presente.

Critério de entrada

Um critério de entrada descreve a condição que deve ser satisfeita para que o estágio, tarefa ou marco esteja disponível para execução. Estágio, tarefa ou marcos sem critérios de entrada estarão disponíveis para execução assim que forem criados. Os critérios de entrada podem ser colocados em qualquer lugar na borda do estágio, tarefa ou marco.

Exemplo

No exemplo abaixo, ambas as etapas de reclamações de produtos e reclamações de serviços precisam de um critério de entrada, pois só podem ser executadas se a reclamação for do seu tipo. Na maioria dos casos, apenas uma das duas etapas será executada, embora em algumas situações as reclamações possam envolver ambas as etapas.

Sair do critério

Um critério de saída é semelhante a um critério de entrada, mas é usado para interromper o trabalho no estágio, tarefa ou caso (plano de caso) quando for satisfeito. No processo de reclamações, adicionaremos um critério de saída para o caso. Na situação o cliente liga e cancela a reclamação, então precisamos parar de trabalhar no caso. Modelamos esse cenário com um item de arquivo de caso de cancelamento, que pode ser uma gravação de voz de uma chamada de cliente ou uma carta do cliente.

Ficheiro

No CMMN, cada instância de caso contém um único  arquivo de caso  (também chamado de  pasta de caso , ou apenas  caso ), e os responsáveis ​​pelo caso têm acesso a todos os dados nesse arquivo de caso. Os responsáveis ​​pelo caso podem adicionar, remover e modificar dados no arquivo de caso, mesmo que não estejam executando nenhuma tarefa no caso, desde que tenham privilégios suficientes. Os dados no arquivo de caso são chamados de itens de arquivo de caso.

Todos os dados e estruturas de dados são chamados  de itens de arquivo de caso . Todos os itens do arquivo de caso são armazenados no arquivo de caso. Os itens do arquivo de caso são usados ​​para representar todos os tipos de dados, incluindo um valor de dados em um banco de dados, uma linha em um banco de dados, um documento, uma planilha, uma imagem, um vídeo, uma gravação de voz etc. Os itens do arquivo case também podem representar contêineres, incluindo um diretório, uma pasta, um conjunto, uma pilha, uma lista, etc.

Exemplo

Tabela de planejamento

Um Estágio ou uma Tarefa Humana pode ter uma Tabela de Planejamento indicando se os itens discricionários são visualizados (-) ou não (+). Quando um usuário ‘expande’ uma Tabela de Planejamento, seus itens discricionários contidos tornam-se visíveis dentro do Palco ou fora da Tarefa Humana. Para itens discricionários associados a uma Tarefa Humana, o planejamento está disponível apenas no estado ativo da Tarefa.