DMN: uma notação para modelagem de decisões de negócios

Nos treinamentos sobre BPMN (Business Process Model and Notation) que temos ministrado na iProcess Education ensinamos que, diferentemente dos losangos utilizados nos fluxogramas, os gateways da BPMN não contêm em si mesmos a semântica de uma decisão. Eles servem, comparativamente, para desviar o fluxo dos processos de acordo com condições previamente estabelecidas ou identificadas, isto é, possuem a semântica de um desvio condicional no fluxo dos processos com base em uma decisão de negócio tomada anteriormente.

Decisões: fundamentais nos processos de negócios

Quando se trata de tarefas humanas (tarefas manuais ou tarefas de usuário) há a compreensão imediata de que uma ação ou decisão realizada por uma pessoa (através da conclusão de uma tarefa, do clique em um botão de um formulário eletrônico, etc) determinará o caminho a ser seguido pelo processo. Porém, quando nos referimos a tarefas automáticas, e em especial a tarefas de regras de negócio, essa compreensão não é tão óbvia.

BPMN disponibiliza uma atividade do tipo regra de negócio (Business Rule Task) para representar a comunicação de um processo automatizado com um motor de regras de negócios ou um BRMS (Business Rules Management System). Falando desta forma, pode-se ter a ideia de que a formalização de regras de negócio em um  BRMS é algo trivial ou de menor importância, que basta preencher um formulário ou cadastro de regras quando, na verdade, se trata de um aspecto essencial para os negócios.

Decisões de negócio: manuais ou automáticas?

As regras de negócio carregam as decisões do negócio, que são tomadas de acordo com modelos mentais e estratégias organizacionais e implementam uma lógica de negócios que orientam essas decisões. Por isso regras de negócio declaradas clara e corretamente, bem conectadas à lógica e à estratégia dos negócios e sendo compreensíveis por todos os interessados é de extrema relevância para o sucesso das organizações.

Durante muito tempo a definição das regras de negócio e sua lógica de decisão permaneceu sem o suporte de uma notação para modelagem que permitisse sua padronização, sua formalização e o gerenciamento dos modelos de decisão das organizações.

Modelo e Notação de Decisões – DMN

Devido ao crescimento das discussões sobre a necessidade das organizações dominarem a gestão de decisões de negócio, a Object Management Group (OMG) criou uma subcomissão com o objetivo de desenvolver esse campo de estudo e dessa iniciativa surgiu a especificação DMN (Decision Model and Notation). A especificação tem por objetivo fornecer uma notação para decisões compreensível para todos os públicos, incluindo o pessoal de negócios e técnicos, e é composta de cinco componentes principais:

  • uma notação no nível dos requisitos, que permite aos analistas de negócio identificarem requisitos iniciais de decisão;
  • uma notação no nível da lógica das decisões, que permite detalhar como as decisões serão tomadas;
  • uma linguagem de expressões chamada FEEL (Friendly Enough Expression Language – Linguagem de Expressões Suficientemente Amigável), que permite a expressão das diferentes lógicas de decisão de negócios;
  • níveis específicos de conformidade, que permitem a validação automática de modelos de decisão; e
  • um metamodelo de suporte, que permite a automatização de modelos de decisão e o intercâmbio desses modelos entre diferentes sistemas.

Um aspecto digno de nota sobre a DMN é que esta nova notação se conecta naturalmente aos modelos de processos de negócio, permitindo que sejam desenhados processos de negócio conscientes de decisão, ou seja, processos em que é feita a distinção entre as tarefas que executam o trabalho e aquelas que chegam a conclusões baseadas na lógica. Na figura abaixo, baseada do exemplo da própria especificação da DMN, a imagem da esquerda representa um diagrama de processo (modelado na notação BPMN) enquanto que na direita há diagramas de um modelo DMN relacionado.

Imagem com a relação entre diagramas DMN com diagramas BPMN

Relação entre DMN e BPMN

Ainda não há muitas ferramentas de DMN disponíveis (O diagrama e tabela da imagem foram criados usando um editor de textos), mas o artigo de Larry Goldberg e Barbara von Halle publicado no site ModernAnalyst.com aponta a participação de de importantes fabricantes de software na força tarefa para definição da notação. São citadas as empresas como IBM, Oracle e TIBCO, entre outras, e sua participação nesta iniciativa indica, segundo os autores do artigo, sua intenção em produzir software relacionado à DMN.

A notação DMN é um assunto que fará parte de nossas discussões nos próximos artigos, onde pretendemos apresentá-la em detalhes, e gostaríamos de convidá-lo a participar, desde já, dessas discussões através de seus comentários. A organização da qual você faz parte já utiliza modelos de decisão? Que notação é utilizada para representar esses modelos?

Regras de negócio em projetos de automação de processos

Em muitos projetos de automação de processos é comum que nos deparemos com uma confusão conceitual que pode atrapalhar o trabalho desde a documentação até a implementação dos processos: a definição das regras de negócio e requisitos de software como sendo a mesma coisa.

Como em muitas organizações a iniciativa de BPM tem origem na área de TI, é comum que templates de documentação de processos agrupem todas estas definições em um único documento ou seção onde tradicionalmente se definem os requisitos de software, apenas utilizando a nomenclatura “regras de negócio”.

Se por um lado essa simplificação pode fazer sentido na medida em que todos os requisitos e restrições deverão ser considerados pela equipe de desenvolvimento na implementação dos processos automatizados de forma coesa, por outro inviabiliza a manutenção compartimentada, por equipes diferentes e em momentos distintos. Mas se na arquitetura de software costuma-se utilizar camadas de abstração para criar domínios de responsabilidade e interdependência de forma flexível, por que não fazer algo similar em nossos projetos de automação de processos?

Assim como dividimos os elementos de um website em conteúdo, estilo e  comportamento, devemos utilizar uma especificação de processos que considere de modo similar o que são os requisitos do processo separadamente dos requisitos de software e das regras de negócio aplicáveis. Dessa forma, estaremos possibilitando uma validação separada entre a área de negócios (regras de negócio) o escritório de processos (desenho de processo) e a área de TI (requisitos de software).

Regras de negócio são ativos empresariais

Obviamente, a integração das necessidades destas diferentes áreas deve ser considerada pelos analistas de processos, mas ao tratá-las de forma distinta viabilizamos a gestão funcional, utilizando as competências específicas de cada área, facilitando a manutenção e proporcionando agilidade nas mudanças necessárias.

A ABPMP chama a atenção para esse importante requisito do processo, ao recomendar a consideração de aspectos importantes relacionados às regras de negócio no capítulo do BPM CBOK que trata da análise de processos. Devemos considerar porém que as regras de negócio podem referir-se a regras atômicas, comuns a diferentes tipos ou linhas de negócios de uma organização, sendo altamente recomendável seu tratamento como um ativo empresarial.

Considere o exemplo da extinta CPMF (Contribuição Provisória sobre Movimentações Financeiras),  que era uma regra aplicável a diversos processos bancários entre 1997 e 2007. O que aconteceria se em cada um desses processos fosse definida uma regra de negócio para tratar daquela contribuição? Certamente haveria desalinhamento, cobranças indevidas, cobranças de valores incorretos, entre outros problemas. Agora imagine a dificuldade e a demora de realizar a manutenção em todos os processos quando essa regra de negócio era alterada ou quando foi ela extinta?

BRMS, o repositório para as regras de negócio

Armário para ferramentas
BRMS, o repositório para as regras de negócio

Como já foi dito em nosso artigo Business Rules e a Dinâmica do Negócio, o ideal é que se tenha as regras de negócio centralizadas em um BRMS (Business Rules Management System) e, na especificação de um processo de negócio, apenas se referenciem as regras aplicáveis que deverão ser consideradas pelos desenvolvedores na automatização. Devemos pensar nas regras de negócio como ferramentas que podem ser utilizadas em diversos projetos, mas que ficam em um repositório centralizado, uma coleção organizada, onde cada item possui uma funcionalidade específica e que será utilizado sob demanda.

Um fato que apoia essas recomendações é a existência, no BPMN, de um tipo de tarefa automática chamada Business Rule Task (leia nosso artigo sobre esse assunto), que permite tratar de forma um pouco mais autônoma a camada de negócio da aplicação que irá automatizar o processo.

E na sua organização, como são gerenciadas as regras de negócio utilizadas nos processos? Individualmente em cada processo? Utilizam um BRMS? Ou possuem formas híbridas para gerenciá-las? Compartilhe sua experiência e enriqueça a discussão desse importante tema.

Business Rules e a Dinâmica do Negócio

No âmbito da Gestão por Processos de Negócio, o termo Business Rules refere-se às Regras do Negócio.

A OMG (Object Management Group) em seu documento SVBR (Semantics of Vocabulary and Business Process) apresenta as seguintes definições (p.160).

“Uma RULE (regra) é uma proposição que reivindica obrigação ou necessidade.

Uma BUSINESS RULE (regra de negócio) é uma regra que está sob a jurisdição do negócio.”

Diz ainda:

“Leis da física podem ser relevantes para uma empresa; legislação e regulamentos podem ser impostas a ela; padrões externos e melhores práticas podem ser adotadas. Essas coisas não são regras de negócio do ponto de vista da empresa, uma vez que não tem autoridade para alterá-las. Entretanto, a empresa vai decidir como reagir a leis e regulamentos, e criar suas regras de negócio para assegurar o seu cumprimento. Da mesma forma, ele irá criar regras de negócios para garantir que os padrões ou melhores práticas sejam implementadas como pretendido.”

Na literatura menos formal, encontramos definições mais pragmáticas e fáceis de compreender, como:

“Uma business rule é uma regra que define ou restringe algum aspecto do negócio. Sua declaração é resolvida como verdadeira ou falsa. Business rules buscam determinar a estrutura de negócio ou para controlar ou influenciar o comportamento do negócio. ”
[traduzido de en.wikipedia.org/wiki/Business_rule]

“Uma business rule é uma declaração afirmativa compacta, atômica, bem-formada de um aspecto do negócio que pode ser expressada em termos que possam ser diretamente relacionadas ao negócio e seus colaboradores, usando linguagem simples e não-ambígua, que seja acessível a todas as partes interessadas: business owner (dono do negócio), business analyst (analista de negócio), technical architect (arquiteto técnico) e cliente entre outros.”
[traduzido de GRAHAM, Ian. Business Rules Management and Service Oriented Architecture, 2006]

Por exemplo, uma regra de negócio pode afirmar que “não deve ser realizada verificação de crédito para clientes que retornam para nova compra”, ou “aquisições com valores superiores ao orçamento do centro de custo devem ser aprovadas pelo superintendente”.
Regras de negócio podem ser informais ou até mesmo podem nem estar escritas. Entretanto, a sua formalização, publicação e gerenciamento garantem clareza na operação e a redução de problemas por conflitos de regras.

Em uma iniciativa de Gestão por Processos de Negócio, as business rules, como são definidas e como serão mantidas, são um aspecto importante para fornecer a dinâmica e adaptabilidade requerida pelo negócio.

Uma vez identificadas e definidas com o negócio durante a análise e redesenho de processos, as business rules precisam ser documentadas e disponibilizadas para conhecimento da organização.

Tecnologia em favor da gestão das regras de negócio

O cenário geral das organizações, que possuem sistemas distribuídos para apoiar a diferentes aspectos de negócio, é que muitas das regras estão implícitas na lógica das aplicações que as consomem, dificultando seu gerenciamento pelo negócio. Qualquer necessidade de alteração ou modificação de parâmetros para adequação da regra a uma mudança no negócio requer alteração em sistemas.

Uma das principais ferramentas de tecnologia disponibilizadas atualmente no mercado para suportar a manutenção de regras de negócio são soluções de BRM (ou BRMS, Business Rules Management Systems) que quando combinadas à adoção de um BPMS e de uma arquitetura orientada a serviços (SOA), pode fornecer infraestrutura de negócio muito mais ágil às mudanças do mercado.

BPMS + BRMS: Processos automatizados em BPMS acionam o BRMS para consultar uma regra durante a execução do processo através componentes de invocação de regras (no caso de soluções integradas) ou de chamadas de serviço. Assim, garante que o mesmo seja executado de acordo com as definições do negócio, e, ao mesmo tempo, que o negócio possa modificar uma regra de forma a atingir imediatamente os processos que em breve deverão consumí-la.

SOA + BRMS: Uma arquitetura SOA viabiliza a utilização das regras do BRM por qualquer sistema da organização, tornando possível que as regras mantidas no BRMS sejam consumidas como se fossem serviços, melhorando a governança sobre a utilização das regras pelos sistemas e eliminando-as da lógica interna das aplicações.

Existem no mercado diversas ferramentas de BRM, oferecidas por diferentes fornecedores. A decisão pela melhor solução para cada organização passa por uma avaliação criteriosa não apenas de questões funcionais, mas também culturais, econômicas, políticas e de planejamento da infraestrutura tecnológica da organização. Em geral, a escolha deste tipo de produto requer uma análise combinada à seleção de um BPMS ou seguindo critérios semelhantes (leia mais no artigo A difícil tarefa de escolher uma plataforma BPM para uma organização).

Desafios

Embora conceitualmente seja fácil de se perceber os benefícios da adoção de um BRMS para a manutenção e gerenciamento das regras de negócio da organização, naturalmente a mudança não é tão simples.
Não basta apenas adquirir o produto e cadastrar nele as regras do negócio se os sistemas não as utilizarem. Lógicas de programas, interfaces e integrações precisam ser revistas. Sistemas e processos precisam ser adaptados para consumirem as informações mantidas no BRM. Portanto, não espere resultados imediatos, mas confie que benefícios poderão ser identificados progressivamente à medida que ocorra sua integração com os demais sistemas da organização.

Existe também uma barreira cultural, relacionada à maturidade do negócio e da organização. Muitas vezes a Gestão de TI se opõe à adoção de um BRMS porque isto implica em transferir ao negócio o poder de fazer alterações no comportamento de sistemas sem o envolvimento da TI. Em outras palavras, usuários de negócio podem modificar informações que levem a resultados diferentes na operação. Mas se algo der errado, devido uma regra mal definida ou mal gerenciada, o resultado pode ser desastroso para o negócio, e quem precisará gerenciar e resolver o problema é a TI. Assim, a utilização do BRM precisa ser bem alinhada com o negócio, que deve estar plenamente ciente das implicações e responsabilidades inerentes à alteração das regras. Controles de acesso que restrinjam a alteração de regras a usuários com real responsabilidade sobre elas precisam ser realizados, e políticas claras de alteração de regras organizacionais precisam ser estabelecidas.