Sim! Um motor de decisões te traz muitos benefícios, mas a razão central para sua empresa PRECISAR de um é simples: regras transacionais do negócio pertencem às áreas de negócio, e não às áreas de tecnologia. As áreas de negócio são responsáveis pela melhoria das regras, e pelos resultados bons ou ruins gerados por elas. Vou contar uma história para ilustrar este ponto, e ao final vou contar um pouco da minha motivação em construir um business em torno desta ideia.
Um pouco de contexto
Há alguns anos, assumi a operação de um grande provedor de serviços que lidava com mais de 2 milhões de acionamentos efetivos por ano, enviados para cerca de 5 mil municípios deste grande país (temos cerca de 5.600 no Brasil) e realizando mais de 15 milhões de tentativas de acionamento nas cerca de 25 mil empresas de serviço parceiras.
Alguns anos antes, liderei um projeto de consultoria grandioso para esta mesma empresa, resultando em recomendações de eficiência e qualidade que foram diligentemente implementadas e entregaram resultados acima do esperado.
No entanto, algumas das recomendações mais difíceis, especialmente aquelas que propunham alterações no sistema de acionamento da companhia, não foram implementadas. Isso aconteceu apesar do amplo apoio da alta liderança, que investiu, tomou decisões difíceis e empoderou as equipes para colocar essas recomendações em prática. Ainda assim, houve resistência considerável a mudanças no sistema nervoso transacional central da empresa, o temido legado. Os argumentos não faltaram:
Especificações feitas entre equipes da consultoria, de negócios e de tecnologia cheias de mal-entendidos e falhas conceituais;
Ausência de documentação ou registro do “algoritmo” em vigor;
Conhecimento pulverizado sobre as diferentes partes do sistema entre diversos desenvolvedores, muitos dos quais já não estavam na companhia;
Medo de mudar o sistema de acionamentos, sistema core da empresa, sob risco de penalizar contratos B2B relevantes;
Vício das áreas operacionais em “manobrar” o sistema usando sempre o mesmo conjunto limitado de variáveis e dados;
Obsessão das áreas de tecnologia por confiabilidade, impedindo a implementação de certas funcionalidades mais complexas.
Problema
Estavam ali, no sistema core da companhia, as próximas e mais relevantes alavancas de eficiência operacional do negócio. Havia um problema existencial: a área de operações, responsável por melhorar a qualidade e reduzir os custos, não tinha todas as alavancas internas para fazê-lo e era especialmente frágil naquilo que dependia dos sistemas.
Entendo o dilema que as áreas de tecnologia enfrentam. De um lado, arriscar deploys complexos, sujeitos a rollbacks que consomem valiosas horas de descanso, paz de espírito e, em alguns casos, podem gerar desagradáveis conflitos ou até mesmo decapitações corporativas. De outro lado, serem acusadas de lentidão, conservadorismo ou de serem gargalos para a melhoria dos resultados. A grande maioria dos líderes opta por ficar no meio desse espectro, evitando os riscos que pairam sobre os extremos.
Solução
Mas e ai, Rafa? Tem solução?
Sim! A solução passa por colocar os domínios corretos nas mãos dos especialistas corretos. Regras de negócio são responsabilidade das áreas de negócio. Somente com esse conceito-solução, comecei a perceber o quanto o problema é pervasivo no mundo corporativo. Arrisco dizer que todas as empresas com algum volume transacional significativo já enfrentaram esse problema em algum ponto de suas histórias, e a grande maioria delas está enfrentando esse problema hoje.
Mas como colocar o domínio das regras de negócio nas mãos dos especialistas em negócio? Através de um sistema chamado motor de decisões, que permite:
Criação de regras de negócio sem o uso de código ou programação (ainda que seja possível fazê-lo se o usuário assim o desejar);
Execução das regras em nível transacional feita através de chamada a uma API de alta performance, confiabilidade e disponibilidade;
Acesso a dados da organização e dados externos (por exemplo, score de crédito, geolocalização e trânsito em tempo real, dados de open banking, etc);
Documentação das regras em formato amigável e intuitivo, normalmente usando fluxos de trabalho juntamente com expressões, dados externos e tabelas de decisão;
Segmentação das decisões conforme critérios objetivos, permitindo regras diferentes para segmentos de clientes ou transações diferentes;
Maior governança sobre as regras de negócio, com clara visualização e auditoria do que foi executado, versionamento das regras, sistema de permissões para usuários e verificação transparente da atuação da gestão;
Realização de experimentos em subgrupos amostrais do todo para validar hipóteses antes de aplicar essas hipóteses no conjunto completo.
Este último ponto é a cereja do bolo. Veja, assim como as áreas de tecnologia têm medo de causar transtornos com a evolução dos sistemas, também o têm as áreas de negócio. A realização de testes A/B controlados dá o poder à organização de errar de forma controlada e, no processo, buscar os acertos que vão elevar a maior eficiência e competitividade da empresa.
Muitos argumentam que a implementação desses sistemas é muito difícil, pois envolve o mapeamento detalhado das regras vigentes, para então configurar essas regras dentro do motor de decisões. É verdade, mas também é verdade que as empresas aprendem muito ao longo desse processo e já capturam benefícios diretos desse exercício.
Outros dizem que essas regras fazem parte do core da empresa e não deveriam ser colocadas em um sistema terceiro. Aqui faço uma analogia com ERPs ou CRMs. Será que as regras são de fato mais core que os clientes ou as finanças da empresa?
Acompanhe a discussão também no LinkedIn