Existe um problema silencioso que corrói a agilidade de quase toda empresa brasileira de médio e grande porte. Ele não aparece nos relatórios financeiros, não gera alerta no ERP e raramente chega à pauta do conselho. Mas está lá, presente em cada chamado aberto para o time de tecnologia pedindo para mudar uma alíquota, ajustar um critério de elegibilidade ou corrigir o cálculo de uma comissão. O problema tem nome: A ausência de um dono claro para as regras de negócio.

Regra de negócio não é código. Regra de negócio é decisão. É a política que define quando um cliente merece desconto, qual o limite de crédito que cada perfil pode receber, como o frete é calculado por região, quem pode aprovar uma devolução acima de determinado valor. Essas decisões existem muito antes de qualquer linha de código ser escrita. E, quando a empresa madura entende isso, ela percebe que o código é apenas o recipiente. A política em si pertence ao negócio.

Por que a TI acabou virando o dono do que não deveria ser dela

A história tem uma lógica perversa e compreensível. No começo, a empresa era pequena, as regras eram poucas, e o desenvolvedor que as implementou também as entendia bem. Com o tempo, o sistema cresceu, as regras se multiplicaram e ficaram cada vez mais embutidas no código. Ninguém documentou direito. Ninguém designou um responsável do lado do negócio. E aí veio o resultado natural: Quando algo precisa mudar, quem sabe onde mudar é a TI.

O problema é que a TI não deveria precisar saber por que a regra existe. Ela deveria apenas implementar o que o negócio decidiu. Quando esses dois papéis se misturam, a consequência é dupla: A TI fica sobrecarregada com demandas operacionais que deveriam ser autonomia do negócio, e o negócio perde velocidade porque depende de um ciclo de desenvolvimento para qualquer ajuste.

"A regra de negócio que ninguém se responsabiliza vira patrimônio da TI por padrão. E patrimônio da TI significa fila de chamados, prazo incerto e custo de oportunidade alto." - Daniel Nakamura, CRO & Co-founder

Os sinais de que sua empresa tem esse problema

• O time de negócio precisa abrir chamado ou enviar e-mail para TI sempre que quer mudar um parâmetro operacional, como prazo, percentual ou critério de aprovação.
• Ninguém consegue listar todas as regras ativas sem consultar documentação técnica ou o próprio código-fonte do sistema.
• Mudanças regulatórias ou estratégicas demoram semanas para serem refletidas nos sistemas, mesmo quando a decisão já está tomada.
• Há regras diferentes rodando em sistemas diferentes para o mesmo processo, porque cada ajuste foi feito em um ponto diferente da arquitetura.
• Quando um colaborador chave sai, parte do conhecimento sobre como certas regras funcionam vai junto.

Esses sinais apontam todos para a mesma raiz: As regras de negócio foram tratadas como problema técnico quando são, na verdade, problema de governança.

O que significa ter um "dono" de regra de negócio

Ter um dono de regra de negócio não é criar mais uma função burocrática. É estabelecer que existe uma pessoa, ou uma área, que responde pela validade, pela atualização e pelo entendimento de cada política que governa o funcionamento da empresa. Essa pessoa não precisa saber programar. Ela precisa entender o negócio, conhecer as implicações regulatórias e ter autoridade para decidir quando uma regra precisa mudar.

Na prática, isso significa que o responsável pela política de crédito é alguém da área financeira ou de risco. O dono das regras de frete é alguém da área comercial ou de logística. O guardião das políticas de compliance é da área jurídica ou de governança. A TI entra para implementar, não para decidir.

O que o dono de regra de negócio faz:

• Mantém um inventário atualizado das regras sob sua responsabilidade, com histórico de versões e justificativas para cada mudança.
• Valida periodicamente se as regras ainda refletem a estratégia e a realidade operacional da empresa, sem esperar que algo quebre para agir.
• Comunica à TI e às demais áreas quando uma mudança é necessária, com antecedência e especificação clara do que deve mudar e por quê.
• Responde por inconsistências entre o que a regra deveria fazer e o que o sistema está executando, atuando como ponto de contato único para dúvidas sobre aquela política.
• Participa da homologação de qualquer alteração antes que ela vá para produção, garantindo que o que foi implementado corresponde ao que foi decidido.

Por que essa ausência custa mais do que parece

É comum que empresas subestimem o custo de não ter essa governança estruturada. Afinal, as coisas funcionam, os sistemas rodam, os clientes são atendidos. O problema é que esse custo está escondido em lugares menos óbvios: No tempo que o analista de negócio passa aguardando a TI para testar um novo cenário de desconto; na oportunidade de receita perdida porque uma mudança de política demorou três sprints para chegar ao sistema; nos erros de cálculo que passam despercebidos porque ninguém do negócio tem como auditar o que está rodando sem depender de alguém técnico.

Quando nenhuma área se sente dona de uma regra, ela se torna território de ninguém. E território de ninguém é território de risco, porque a regra pode estar desatualizada, inconsistente com a legislação vigente ou simplesmente errada há meses sem que ninguém perceba.

Há ainda um custo estratégico relevante. Empresas que dependem de ciclos longos de TI para ajustar suas políticas operacionais respondem mais lentamente a movimentos de mercado, mudanças regulatórias e decisões comerciais. Em um ambiente onde a agilidade é diferencial competitivo, essa lentidão tem preço.

Como estruturar a governança das regras de negócio na prática

Não existe uma fórmula única, mas há um caminho com consistência comprovada. O primeiro passo é o inventário: Mapear todas as regras que governam os processos críticos da empresa, identificar onde elas estão implementadas e quem, atualmente, as conhece. O segundo passo é atribuição: Designar formalmente um dono para cada bloco de regras, com escopo claro de responsabilidade. O terceiro é processo: estabelecer como mudanças de regras são solicitadas, aprovadas, implementadas e auditadas, com papéis definidos para negócio e TI em cada etapa.

À medida que essa maturidade cresce, muitas organizações chegam naturalmente a uma pergunta estratégica: Existe alguma tecnologia que ajude o próprio negócio a gerir suas regras com mais autonomia, sem depender tanto de desenvolvimento para cada ajuste? A resposta é sim, e ela leva ao universo dos sistemas de gerenciamento de regras de negócio.

Quando a tecnologia amplifica a governança, não a substitui

A Abaccus trabalha com empresas que já entenderam que ter um dono de regra de negócio é condição necessária, mas não suficiente. O próximo passo é dar a esse dono as ferramentas para exercer sua responsabilidade com autonomia real. É aqui que entra a discussão sobre BRMS (Business Rules Management System), sistemas projetados especificamente para que o negócio possa visualizar, validar e, em muitos casos, atualizar suas próprias regras sem precisar acionar a TI a cada ajuste.

A lógica é simples: Quando o responsável por uma política tem acesso a uma interface onde pode ver as regras ativas, simular cenários e propor alterações de forma auditável, o ciclo de mudança encurta drasticamente. A TI continua presente para garantir integridade técnica e integração com os demais sistemas. Mas o poder de decisão e o conhecimento sobre as políticas ficam onde sempre deveriam ter ficado: No negócio.

O que muda fundamentalmente não é a tecnologia. É a cultura de responsabilidade que a tecnologia torna sustentável.