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.