Talvez você não precise trocar o seu CRM

Existe uma cena que se repete com frequência em projetos de tecnologia: a empresa chega à conclusão de que precisa trocar o CRM.

A plataforma ficou cara. A operação reclama. Há dificuldade para extrair informações. Algumas áreas criaram processos paralelos.

Surgiram ferramentas para resolver aquilo que o sistema principal já não resolvia tão bem. As integrações se multiplicaram e mudanças aparentemente simples passaram a exigir discussões cada vez maiores.

O diagnóstico parece evidente: o CRM chegou ao limite.

Nem sempre chegou.

Depois de acompanhar projetos de transformação em empresas de diferentes portes e setores, aprendi a desconfiar desse diagnóstico inicial. Muitas vezes, o problema que aparece no CRM começou em outro lugar.

Problema pode estar na arquitetura

Um CRM raramente permanece apenas um CRM. Ao longo dos anos, ele passa a conversar com atendimento, marketing, vendas, financeiro, ERP, analytics e uma série de aplicações específicas. Recebe customizações, ganha integrações e precisa responder a uma empresa muito diferente daquela que originalmente escolheu a plataforma.

Cada decisão pode ter feito sentido isoladamente.

O problema aparece quando olhamos o conjunto.

É nesse momento que a organização descobre que não possui propriamente uma plataforma cara. Possui uma arquitetura cara.

E essa diferença importa.

A conta que a licença não mostra

Quando se discute custo de tecnologia, ainda existe uma tendência de olhar primeiro para contratos, licenças, infraestrutura e fornecedores.

Mas o custo real de uma arquitetura fragmentada vai muito além.

Ele está nas horas de desenvolvimento dedicadas à manutenção de integrações, no retrabalho provocado por dados inconsistentes, nos processos duplicados, nas customizações que perderam a razão de existir e no tempo necessário para implementar qualquer mudança.

É por isso que considero particularmente interessante levar a lógica de FinOps para além da discussão tradicional sobre cloud.

A pergunta relevante não deveria ser apenas quanto determinada tecnologia custa.

Deveria ser: quanto custa para a empresa continuar operando dessa maneira?

Uma plataforma pode ter um preço competitivo e, ainda assim, fazer parte de uma arquitetura extremamente cara. Da mesma forma, uma tecnologia aparentemente mais cara pode reduzir significativamente o custo total da operação se eliminar redundâncias, integrações desnecessárias e retrabalho.

Olhar apenas para licença significa medir aquilo que é mais fácil de enxergar — não necessariamente aquilo que mais pesa.

Trocar tudo também pode preservar o problema.

Quando a empresa atribui toda essa complexidade à plataforma principal, a substituição do sistema parece uma solução natural.

Escolhe-se uma tecnologia mais moderna, inicia-se uma grande migração e transfere-se para o novo ambiente boa parte daquilo que já existia.

Inclusive os problemas.

A tecnologia é diferente, o problema segue o mesmo

Dados ruins continuam ruins em uma plataforma nova. Processos desnecessariamente complexos continuam complexos depois da migração. Uma arquitetura mal desenhada pode ganhar APIs melhores, interfaces mais modernas e mais capacidade de processamento sem deixar de ser uma arquitetura mal desenhada.

Por isso, antes de discutir qual CRM deveria substituir o atual, considero mais importante fazer outra pergunta:

Se pudéssemos redesenhar essa operação hoje, quantas das decisões tecnológicas tomadas nos últimos anos tomaríamos novamente?

A resposta costuma ser reveladora.

Algumas integrações desapareceriam. Aplicações poderiam ser consolidadas. Processos seriam simplificados. Bases precisariam ser saneadas. E funcionalidades contratadas separadamente talvez já estivessem disponíveis em plataformas que a empresa possui.

Só depois desse exercício a discussão sobre substituição de tecnologia deveria começar.

E, algumas vezes, a conclusão será justamente trocar o CRM.

Em outras, não.

O legado também está nas decisões

Quando falamos em sistemas legados, normalmente pensamos em tecnologias antigas. Mas existe outro legado menos visível: o das decisões acumuladas.

Empresas crescem. Áreas ganham autonomia. Gestores mudam. Fornecedores entram e saem. Aquisições acontecem. Novos canais aparecem.

A arquitetura tecnológica registra cada uma dessas fases.

O resultado pode ser um ambiente formado por decisões perfeitamente justificáveis no momento em que foram tomadas, mas que já não fazem sentido quando observadas em conjunto.

Isso explica por que algumas arquiteturas problemáticas não são necessariamente antigas. Elas apenas acumularam decisões demais.

Durante anos, transformação digital foi praticamente sinônimo de adicionar: sistemas, canais, dados, automação, integrações.

A próxima etapa de maturidade tecnológica talvez dependa também da capacidade de fazer o movimento contrário.

Consolidar. Simplificar. Eliminar.

Arquitetura também é uma decisão econômica

É aqui que CRM e FinOps se encontram de maneira mais interessante.

Não porque o CRM precise ser tratado como infraestrutura em nuvem, mas porque a disciplina econômica aplicada à tecnologia deveria alcançar a arquitetura inteira.

Qual é o custo total desse ambiente? Quanto daquilo que pagamos efetivamente gera valor? Quantas aplicações diferentes participam de uma mesma jornada? Quantas integrações precisam funcionar para que um processo aparentemente simples aconteça?

E talvez a pergunta mais desconfortável:

Se desligássemos algumas dessas camadas amanhã, alguém perceberia?

Para uma liderança de tecnologia, essas questões já não são operacionais.

Arquitetura define velocidade, custo, capacidade de integração e qualidade dos dados. E, cada vez mais, define até onde uma empresa conseguirá avançar em automação e inteligência artificial sem ampliar problemas que já possui.

Antes de colocar mais tecnologia sobre uma operação, portanto, talvez seja necessário entender quanto da tecnologia existente ainda deveria estar ali.

Em alguns casos, a melhor decisão será uma grande migração. Em outros, será redesenhar integrações, sanear dados ou consolidar aplicações.

E haverá situações em que a conclusão mais inteligente será manter o CRM.

Para uma indústria acostumada a oferecer a próxima tecnologia como resposta para os problemas criados pela anterior, essa pode ser uma conclusão pouco conveniente.

Mas a arquitetura digital não deveria começar pela ferramenta que queremos implementar.

Deveria começar pela complexidade que precisamos eliminar.