Usando a modelagem de decisão para enriquecer modelos de processos

No último post comentei como a modelagem de processos de negócio pode ser complementada usando a notação CMMN (Case Management Model and Notation) para tratar situações que são melhor modeladas aplicando conceitos de gestão de casos. Dessa forma, pode-se criar modelos de processos usando em conjunto as notações CMMN e BPMN (Business Process Model and Notation).

Hoje, comento sobre outro padrão OMG (Object Management Group) que também pode ser utilizado na modelagem de processos de negócio de modo a produzir modelos mais eficazes e robustos. Esse padrão é o DMN (Decision Model and Notation) desenvolvido para representar as regras de negócio que devem ser seguidas na execução dos processos.

De forma semelhante à BPMN, o principal objetivo da OMG com o DMN é prover uma notação padrão para modelagem de regras de negócio que possa ser usada pelas diversas equipes do negócio, sejam eles gerentes e executantes dos processos, analistas responsáveis pela definição das regras, ou desenvolvedores responsáveis pela aplicação delas na automação de decisões. Como o padrão DMN define a lógica das regras de negócio através de uma linguagem própria de modelagem, e não a forma como elas são aplicadas nos processos de negócio, o modelo DMN é independente de como as regras são efetivamente implementadas nos processos de negócio, seja manualmente ou através de automação. Assim, o DMN promove o intercâmbio de modelos entre organizações e a possibilidade de que esses modelos possam ser executados em qualquer máquina de regras compatível com o padrão.

Dado que o objetivo de uma regra de negócio é direcionar uma tomada de decisão durante a execução de um processo de negócio, o principal elemento DMN é definido como a "Decisão", responsável por determinar um valor de saída (a decisão) como resultado da aplicação de uma lógica de decisão (definida com base em regras e conhecimentos de negócio) a um conjunto de dados de entrada. Um modelo DMN pode ser composto por múltiplos elementos interligados em um diagrama chamado DRD (Decision Requirements Diagram), como no exemplo da figura abaixo, onde a “Decisão A” é consequencia de uma determinada lógica de negócio aplicada aos valores dos parâmetros de entrada Dados A1, Dados A2 e Decisão B: 

A formulação da lógica de decisão pode ser feita de diversas formas, sendo que o mais comum é através de tabelas de decisão, onde os valores possíveis de decisão são definidos pelo mapeamento das regras de negócios nos valores possíveis nas entradas. No exemplo abaixo, o valor atribuído ao fator de risco é 0.5 sempre que o risco for classificado como alto, ou 0.7 quando for classificado como médio:

O padrão DMN prevê também a utilização de expressões lógicas compostas por linguagem própria denominada FEEL (Friendly Enough Expression Language). Mas uma descrição detalhada do padrão DMN não cabe neste curto post, inclusive porque o Antonio Plais, nosso colega de blog, já discorreu muito bem sobre o assunto aqui e nesta série. Assim, vou apenas tentar mostrar como o DMN pode ser usado para enriquecer modelos BPMN.

Como exemplo, escolhi um trecho de um processo fictício onde a atribuição da atividade “Tratar Item” é determinada segundo uma regra de negócios pré-definida. Conforme mostra o diagrama BPMN, o centro funcional responsável pela atividade é definido com base no valor de 3 propriedades do processo: Produto, Local e Nível. Por exemplo, caso o produto seja do tipo “X” e o local igual a “Z”, a atividade deverá ser executada pelo centro funcional “X-A1”, enquanto que para produtos do tipo “Y” e Nível igual a “2”, independentemente do local a atividade deverá ser executada pelo centro funcional “Y-A2”.

O problema dessa modelagem é que a complexidade do diagrama cresce muito rapidamente a medida que aumenta o número de combinações possíveis dos valores de entrada e/ou o número de centros funcionais que podem ser atribuídos. Além disso, frequentemente o mapeamento entre as variáveis de entrada e o centro funcional desejado não é estático na linha do tempo. Ou seja, após a primeira mudança no mapeamento “entradas x centro funcional“ o modelo representado no diagrama fica desatualizado.

O DMN nos permite modelar em um diagrama separado a atribuição do centro funcional e explicitar as regras de negócio que compõem a lógica dessa decisão. No exemplo, o diagrama de requisitos da decisão (DRD) mostra que a decisão “Centro Responsável” depende das propriedades Produto, Local e Nível.

Além disso, o mapeamento entre os valores das propriedades e os centros funcionais é determinado pela tabela de decisão:

O modelo DMN pode ser incluído como elemento do modelo BPMN substituindo a lógica de decisão anteriormente desenhada no diagrama. No exemplo abaixo, o modelo DMN é representado pela atividade “Centro Responsável”, marcada como atividade DMN, a ser executada automaticamente para atribuição do centro funcional, enquanto que a raia “Centro Virtual” corresponde a uma raia virtual cuja atribuição é resolvida no momento de execução do processo: 

É importante notar que, a integração entre as notações mostrada acima não está prevista na especificação BPMN atual porque o padrão DMN é posterior a ela, mas quase certamente será incluída em uma próxima versão. Mesmo porque já existem ferramentas de modelagem BPMN que possibilitam a inclusão de modelos DMN, como o Camunda Modeler usado neste post.

Finalmente, o valor que o padrão DMN traz para a modelagem de processo pode ser resumido nos itens seguintes:

• Aumento da qualidade do modelo - o diagrama de decisão reduz a ambiguidade do diagrama BPMN explicitando as decisões a serem tomadas nas atividades do processo, os requisitos para que elas aconteçam, e a lógica que determina como a decisão é tomada com nível de detalhamento suficiente para que ela possa ser validada;
• Separação do modelo de decisão do restante do modelo do processo, possibilitando frequências de atualizações independentes que aumentam a confiabilidade dos modelos como referências do processo de negócio;
• Simplificação no modelo de processo ao substituir a modelagem de regras de negócio complexas através apenas dos elementos BPMN originais;

Com este post encerramos nossos encontros este ano, boas festas a todos e até um próximo encontro.