Arthur Guttilla Head of Product Marketing, Strattum Com passagens na Amazon Web Services e no Google, Guttilla trabalhou diretamente com fundadores de startups e empresas de capital de risco, compreendendo as necessidades de empresas tecnológicas em estágio inicial na interseção entre tecnologia e negócios.
Em qualquer empresa com mais de um sistema, há informações que aparecem em dois lugares com valores diferentes. O CRM registra um valor de contrato, o ERP registra outro e a planilha de fechamento registra um terceiro. Um agente de IA que consulta as três fontes precisa decidir qual delas vale, e essa decisão costuma ser tomada sem que ninguém perceba. O Company Brain, a camada que conhece a empresa (quais dados existem, onde vivem, como se relacionam e quem pode ver o quê), torna essa decisão explícita e verificável.
Divergência não indica, necessariamente, erro de cadastro. Cada sistema registra a informação no momento e com o propósito que lhe cabem. O CRM guarda o valor negociado no fechamento da oportunidade. O ERP guarda o valor efetivamente faturado, depois de ajustes, impostos e aditivos. Os dois estão corretos dentro do próprio contexto e respondem a perguntas diferentes.
O problema surge quando a pergunta não informa qual contexto importa. Diante da pergunta sobre o valor do contrato de um cliente, uma busca por similaridade devolve os dois registros como igualmente relevantes, e o modelo escolhe um deles sem indicar que havia outro. Um Company Brain parte do reconhecimento de que ambos os valores podem estar corretos.
A solução começa pela definição, atributo por atributo, de qual sistema tem autoridade sobre cada informação. O cliente, como entidade, existe em vários sistemas. O valor faturado pertence ao ERP, o estágio da negociação pertence ao CRM e o SLA vigente pertence à gestão de contratos.
Essa atribuição é registrada na ontologia do negócio. Quando uma pergunta envolve o valor do contrato, a ontologia indica qual definição a pergunta pediu e qual sistema responde por ela. Se a pergunta for ambígua, o Company Brain devolve os dois valores, com a origem de cada um, e deixa a escolha com quem perguntou.
Em algumas situações, a própria divergência é a informação que interessa. A diferença entre o valor contratado e o valor faturado pode indicar um erro de faturamento, um desconto não registrado ou um aditivo que não chegou ao ERP.
O grafo de conhecimento mantém os dois registros ligados à mesma entidade, cada um com o sistema de origem e a data de atualização. Uma consulta de conciliação percorre essas ligações e lista as divergências com os documentos que sustentam cada valor. A controladoria decide, então, se corrige a nota, cobra a diferença ou ajusta o contrato.
Além da origem, a data importa. Um contrato renegociado na semana anterior pode ainda não estar refletido no ERP, e um cadastro atualizado no CRM pode conter informação mais recente que a do sistema de faturamento. Sem saber quando cada valor foi registrado, não é possível aplicar uma regra de prevalência por atualidade.
O Company Brain mantém, para cada informação, o sistema de origem e o momento da última atualização. Uma pergunta sobre o estado atual de um contrato considera a versão mais recente registrada no sistema com autoridade sobre aquele atributo, e uma pergunta histórica considera o valor vigente na data consultada. A mesma estrutura permite reconstruir, meses depois, qual informação estava disponível quando uma decisão foi tomada.
Algumas divergências podem ser resolvidas por regra, como a prevalência da informação mais recente ou do sistema com autoridade sobre o atributo. Outras exigem decisão humana, porque envolvem interpretação comercial ou contratual.
Em ambos os casos, a regra precisa de um responsável. Quem define que o valor do ERP prevalece sobre o do CRM nos relatórios de receita toma uma decisão de negócio, que deve estar registrada e acessível a quem consulta o resultado. No Company Brain, essas regras ficam registradas na ontologia, junto da definição de cada atributo. Sem esse registro, cada ferramenta aplica o critério configurado por seu fornecedor, e dois relatórios sobre a mesma receita chegam a números diferentes.
A coexistência de informações de origens diferentes também afeta o controle de acesso. Um mesmo cliente pode ter dados de acesso amplo, como o estágio da negociação, e dados restritos, como a margem do contrato. Uma permissão definida por documento ou pela entidade inteira é ampla demais para esse caso.
No Company Brain, cada informação carrega a permissão do sistema de onde veio. O vendedor enxerga o estágio da negociação que já enxerga no CRM, e o analista financeiro enxerga o valor faturado que já enxerga no ERP. O contexto é servido aos modelos por meio do MCP, um protocolo aberto que conecta modelos a fontes de dados, e cada resposta chega ao modelo filtrada pela permissão de quem perguntou.
O Company Brain não corrige a fonte. Se o ERP registra um valor errado, a camada de contexto aponta a divergência, e a correção precisa acontecer no sistema de origem, pelo time responsável. Usar a camada de contexto como lugar de correção cria uma terceira versão da informação e agrava o problema original.
A definição de autoridade por atributo também exige trabalho inicial das áreas de negócio. Como ponto de partida, recomenda-se escolher um atributo que gera discussão recorrente nas reuniões de resultado, como o valor de contrato ou a data de renovação, e registrar qual sistema responde por ele e em quais perguntas. Esse registro é a primeira entrada da ontologia do Company Brain.
Fale com um especialista da Strattum sobre Company Brain, ontologia do negócio e as regras que decidem qual valor prevalece.