Como representar na prática as regras de negócio nos modelos de processos com qualidade? Considerando que a modelagem de processos é um assunto muito vasto, com diversas possibilidades, tais como objetos, notações e objetivos, todos já sabemos disso…
Muitas vezes, enfrentamos dificuldades para representar tudo aquilo que coletamos no levantamento de processos em modelos aderentes à realidade, mas também claros e compreensíveis. Boa parte das informações complementares consiste em regras de negócio, o que pode ser um desafio para modeladores de processos iniciantes e até mesmo intermediários!
Portanto, vamos resolver de vez esse problema de como representar regras de negócio na modelagem de processos? Para isso, vamos analisar a diferença entre ambos, as dificuldades de como modelar regras de negócio e, por fim, algumas boas soluções para nos ajudar a manter nossos modelos de processo enxutos e aderentes à realidade. Vamos lá?
Diferença entre processos e regras de negócio
Durante as etapas de levantamento e modelagem de processos, treinamos nossa percepção para capturar os principais elementos do funcionamento do processo: atividades, eventos e participantes. Estamos habituados a pensar no modelo “quem faz o quê e como?” (DUMAS et al., 2018).
Por exemplo, em um processo produtivo, podemos ter a sequência: “Auxiliar de produção – montar produto”, “Analista de qualidade – inspecionar produto”, “Analista de qualidade – registrar produto no sistema de falhas” e “Almoxarife – armazenar produto”.
Este é um modelo que foca no trabalho realizado para identificarmos o caminho do processo. Porém, existem outros elementos do processo que não necessariamente atendem às perguntas: “o quê”, “quem” ou “como”.
Um desses elementos é a regra de negócio. Uma regra de negócio corresponde às condições estabelecidas, políticas implementadas ou decisões tomadas pela organização. Muitas vezes as regras são voláteis, mudando frequentemente por conta de condições internas ou externas ao negócio.
Todo tempo nos deparamos com regras de negócio. Imagine um restaurante a quilo comum, daqueles que ficam cheios durante o horário de almoço. Algumas atividades deste restaurante são:
- Recepcionar clientes
- Receber pagamento
- Repor comida
Já algumas regras de negócio são:
- Pagamento obrigatoriamente em dinheiro, cartão de débito ou crédito
- Aniversariantes do dia possuem 20% de desconto no pagamento
- Desconto de 10% no horário do almoço
- As comidas devem ser repostas a cada trinta minutos
- As sobremesas somente são repostas quando acabarem
Uma forma de percebermos as regras de negócio é tentando identificar padrões baseados em condições. Durante o levantamento dos processos, busque termos como somente, quando, requer, se, obrigatório, sempre, entre outros. Isso vai te ajudar a diferenciar se o que o entrevistado disse foi uma atividade do processo ou uma regra de negócio.
Como representar regras de negócio?
Uma das principais dúvidas dos profissionais de processos é como modelar regras de negócio. Para isso vamos utilizar como guia a BPMN (Business Process Model and Notation), uma das principais notações do mercado para modelagem de processos. Existem algumas formas diferentes de representar as regras de negócio usando a notação BPMN – vamos começar com a mais comum, utilizada pela grande maioria das empresas: a representação a partir dos gateways.
Imagine que desejamos modelar o subprocesso “Receber pagamento”, pertencente ao processo principal do nosso restaurante a quilo. As atividades que compõem este subprocesso são “Receber comanda”, “Calcular valor total”, “Cobrar pagamento” e “Entregar comprovante de pagamento”, realizadas pelo Atendente de caixa; e o cliente deve “Pagar comanda”. Simples, não?
A Figura 1 ilustra este subprocesso (vamos ignorar os objetos de dados e bases de dados para simplificar o modelo).
Agora queremos incluir as regras de negócio existentes.
Na situação atual, há duas regras de negócio válidas: (1) Pagamento obrigatoriamente em dinheiro, cartão de débito ou crédito; e (2) Desconto de 10% no horário de almoço, aplicado automaticamente pelo Sistema de Pagamento.
Para representarmos a primeira regra, podemos utilizar um objeto de anotação conectado à atividade “Cobrar Pagamento”. Já para a segunda regra, podemos utilizar um gateway do tipo XOR – Ou exclusivo, conforme a Figura 2:
Por conta da queda das vendas, o gerente decidiu inserir uma nova regra de negócio: os aniversariantes do dia possuem 20% de desconto no pagamento. Neste caso, o Atendente de Caixa deve verificar com o cliente se ele é ou não aniversariante do dia. Se sim, deve aplicar manualmente o desconto. Esse desconto é composto e cumulativo em relação ao desconto do horário do almoço. Logo, podemos utilizar mais operadores XOR para representar o novo fluxo – a Figura 3 apresenta uma possibilidade de modelagem com quatro possibilidades de caminho!
Pouco tempo depois, o gerente percebeu que muitas pessoas passaram a preferir levar a comida para viagem em vez de comer no próprio restaurante. Descobriu que uma parcela significativa levava apenas proteínas para viagem, o que reduz significativamente sua margem de lucro.
Para reduzir este problema, inseriu uma terceira regra de negócio relacionada à atividade “Calcular Valor Total”: “Quentinhas somente com proteína terão acréscimo de 20% sobre o peso”. Imagina como ficará o novo fluxo? (Deixamos como desafio você modelá-lo – uma dica: há 8 caminhos possíveis!). Podemos perceber que, à medida que a quantidade de regras de negócio aumenta em relação a um conjunto de atividades, o fluxo passa a ser exponencialmente mais complexo.
Isso traz dois problemas principais:
- Reduz a clareza do modelo de processo, sua legibilidade e sua compreensão pelos executores do processo;
- Aumenta a necessidade de alterar o modelo de processos sempre que uma das regras mudar – imagine que o gerente altere o desconto do horário do almoço para 15%, pense em como isso impactaria no modelo do processo.
Ou seja, mesmo em situações simples, representar regras de negócio pode dificultar a leitura e o entendimento do processo. Então, como resolver esse problema?
Aperfeiçoando a modelagem das regras de negócio
Há algumas formas de resolver esses problemas para tornar o modelo de processos mais simples.
Uma primeira solução seria passar a utilizar o gateway OR (ou inclusivo) em vez do XOR. Isso já reduziria razoavelmente a complexidade do modelo, conforme a Figura 4:
No entanto, existem outras boas possibilidades de otimizar esse modelo. Se considerarmos as regras de negócio como decisões, podemos utilizar um artifício complementar chamado tabela de decisão.Por exemplo, para a primeira regra de negócio (desconto de 10% na hora do almoço), temos a seguinte tabela de decisão:
Já para a primeira e a segunda regra combinadas, temos a tabela de decisão abaixo:
E como representar isso na modelagem de processos?
A notação BPMN traz a tarefa “regra de negócio” (do inglês, business rule). Essa tarefa indica que há uma decisão sendo tomada a partir de uma regra de negócio (RECKER, 2010). A Figura 5 mostra o processo redesenhado utilizando a tarefa de regra de negócio:
A dúvida que provavelmente você deve estar se perguntando é: como eu indico quais são as regras de negócio referentes a este processo?
Para isso, sugerimos que você use arquivos complementares ao modelo de processos para representar somente as regras de negócio. Ao utilizar BPMS (Business Process Management System) é possível anexar a tabela de decisão à atividade para que a automação possa realizar a alteração na instância do processo a partir dos inputs da atividade.
Há ainda outras várias formas de lidarmos com as regras de negócio dentro da modelagem de processos. Para aqueles modeladores mais avançados, experts em BPMN, podemos utilizar eventos condicionais ou até mesmo diagramas de conversação (KOEHLER, 2011).
Conclusão: Simplifique seus modelos de processo!
As visões de processos de negócio e regras de negócio são complementares e de grande relevância para compreender como funciona uma organização. Enquanto a notação BPMN não atende 100% as necessidades para representar as regras de negócio (já que é uma notação com foco em processos de negócio), há formas de representar utilizando gateways, anotações ou tarefas de regra de negócio.
Existem ainda outras soluções para os casos mais avançados ou mais complexos. Um exemplo são as ferramentas BRMS (Business Rule Management System): ferramentas dedicadas a identificar, definir e aplicar as regras de negócio nos processos organizacionais.
Para os especialistas de processo, o mais relevante é garantir que o modelo de processo respeite os bons princípios de modelagem: seja aderente à realidade e seja claro o suficiente para compreensão de todos. Portanto, mantenha sempre um padrão de modelagem e represente apenas aquilo que for relevante para manter a qualidade dos seus projetos de BPM.
Referências Bibliográficas
DUMAS, M. et al. Fundamentals of business process management. Heidelberg: Springer, 2018.
KOEHLER, J. The process-rule continuum-Can bpmn & sbvr cope with the challenge?. In: 13th Conference on Commerce and Enterprise Computing. IEEE, 2011. p. 302-309.
RECKER, J. Opportunities and constraints: the current struggle with BPMN. Business Process Management Journal, v. 16, n. 1, p. 181-201, 2010.
Publicado por: Thiago Machado thiago.machado@dheka.com.br
Mestre em Engenharia de Produção, com foco em Gestão e Inovação, pela COPPE/UFRJ; especialista em Engenharia e Gestão de Processos de Negócios pela Poli/UFRJ.
Possui experiência com consultoria de gestão e de BPM. Realizou projetos em organizações como o INCA (Instituto Nacional do Câncer), CICC (Centro Integrado de Comando e Controle do RJ) e Parque Tecnológico da UFRJ.
Atuou como professor substituto na área de Gestão da Produção, no Departamento de Engenharia Industrial da Poli/UFRJ. Orientou projetos de BPM da empresa Júnior Fluxo Consultoria. Ministra aulas e orientação de trabalhos em MBAs relacionados à BPM e áreas correlatas.