Principais lições aprendidas em implementações de CRM (o que gostaria de ter sabido mais cedo)

1. Os requisitos nunca estão realmente fechados

No início de um projeto, os requisitos costumam parecer bastante claros. Realizam-se workshops, recolhe-se toda a informação possível, documenta-se tudo cuidadosamente e acredita-se que existe uma visão sólida do que precisa de ser desenvolvido.

Mas a realidade é que os requisitos evoluem sempre. No momento em que os utilizadores começam a ver algo a funcionar, passam a compreender melhor os seus próprios processos e é aí que surgem as conversas do tipo: “já agora, também conseguimos fazer isto?” ou “e se fizéssemos desta forma?”.

Ao trabalhar com o Microsoft Dynamics 365, aprendi que isto não é um problema a evitar — faz simplesmente parte da forma como os projetos de CRM funcionam. Não se trata de congelar requisitos e seguir em frente. Trata-se de construir com base no melhor entendimento disponível naquele momento, sabendo que tudo irá evoluir à medida que as pessoas interagem com o sistema.

O que gostava de ter percebido mais cedo é que assumir a mudança como algo inevitável desde o início torna tudo mais simples. Deixamos de encarar a primeira versão dos requisitos como algo definitivo e passamos a vê-la como algo que será refinado ao longo do projeto.

2. A adoção pelos utilizadores é mais importante do que a perfeição técnica

Quando estamos a desenvolver soluções, especialmente enquanto consultores, é fácil ficarmos focados em fazer tudo da forma “correta” do ponto de vista técnico. Uma estrutura limpa, um bom modelo de dados, automações bem desenhadas e uma arquitetura organizada.

Mas nada disso tem grande valor se os utilizadores não utilizarem efetivamente o sistema.

Já vi soluções tecnicamente muito sólidas que quase não eram utilizadas porque eram demasiado complexas ou porque não se enquadravam naturalmente no dia a dia das equipas. Por outro lado, também vi soluções mais simples, longe de serem perfeitas, mas que eram utilizadas de forma consistente porque tornavam o trabalho das pessoas mais fácil.

A diferença está quase sempre em saber se o sistema é intuitivo, se apoia verdadeiramente as tarefas diárias dos utilizadores e se estes foram envolvidos suficientemente cedo para se sentirem confortáveis com a solução.

O que gostava de ter percebido mais cedo é que a adoção não é algo que se acrescenta no final do projeto. Tem de fazer parte do desenho da solução desde o primeiro momento. Caso contrário, até o sistema mais bem construído pode acabar por ficar sem utilização.

3. A personalização excessiva cria problemas a longo prazo

Esta é uma lição que aprendi claramente com a experiência.

Quando trabalhamos com uma plataforma flexível, é muito tentador personalizar tudo para responder exatamente a cada requisito. É possível desenvolver plug-ins, criar lógica personalizada e adaptar o sistema ao detalhe para que corresponda perfeitamente ao negócio.

Mas quanto mais seguimos esse caminho, mais complexidade introduzimos. E essa complexidade não desaparece após a entrada em produção.

Personalizações extensivas costumam traduzir-se em manutenção mais difícil, maior dependência de pessoas específicas que conhecem profundamente o sistema e mais complicações em futuras atualizações ou alterações. O que começou por ser uma solução rápida para um requisito pode transformar-se gradualmente em dívida técnica.

Com plataformas como o Microsoft Power Platform, existem frequentemente formas mais simples de alcançar o mesmo resultado através de configurações ou funcionalidades low-code, que tendem a ser muito mais fáceis de suportar a longo prazo.

O que gostava de ter percebido mais cedo é que flexibilidade não significa personalizar tudo. As melhores soluções a longo prazo são normalmente aquelas que permanecem o mais próximas possível das funcionalidades standard durante o máximo de tempo possível.

4. A qualidade dos dados determina o sucesso ou o fracasso de tudo

Independentemente da qualidade do desenho de um sistema CRM, ele só funciona corretamente se os dados que contém forem fiáveis.

Isto parece óbvio, mas na prática é frequentemente subestimado.

Quando a qualidade dos dados é baixa, os relatórios tornam-se pouco fiáveis, as automações podem comportar-se de forma inesperada e os utilizadores perdem rapidamente confiança no sistema. Quando essa confiança desaparece, as pessoas tendem a regressar às folhas de cálculo ou a métodos paralelos de gestão da informação, anulando o propósito de ter um CRM.

Também aprendi que a qualidade dos dados não é algo que se corrige uma vez e fica resolvido para sempre. Exige atenção contínua, regras claras e responsabilidades bem definidas. Caso contrário, degrada-se gradualmente ao longo do tempo.

O que gostava de ter percebido mais cedo é que trabalhar os dados não é uma tarefa secundária. É uma das componentes centrais de qualquer implementação CRM e merece atenção desde o primeiro dia.

5. A gestão da mudança é tão importante quanto o próprio sistema

Uma das maiores mudanças de perspetiva que tive foi perceber que os projetos CRM não são apenas projetos tecnológicos. São projetos de transformação organizacional.

É possível desenvolver um excelente sistema, mas se as pessoas não estiverem preparadas para a mudança, não compreenderem porque ela está a acontecer ou não se sentirem apoiadas durante a transição, o projeto terá dificuldades independentemente da qualidade da tecnologia.

A gestão da mudança passa pela comunicação, pela formação e pelo suporte contínuo. Trata-se de garantir que os utilizadores compreendem o que está a mudar, porque está a mudar e de que forma isso os ajuda no seu trabalho diário. Também implica estar presente após o go-live, porque é normalmente nessa fase que surgem os feedbacks mais relevantes.

O que gostava de ter percebido mais cedo é que a entrega técnica representa apenas uma parte do sucesso. A componente humana é igualmente importante — ou talvez ainda mais.

Considerações finais

Quando olho para todas estas lições, percebo que apontam para a mesma conclusão: uma implementação CRM nunca é apenas sobre configurar um sistema.

Trabalhar com o Microsoft Dynamics 365 é, acima de tudo, ajudar as organizações a melhorar a forma como trabalham. E isso só acontece verdadeiramente quando pessoas, processos e tecnologia estão devidamente alinhados.

Se tivesse de resumir tudo numa frase simples, seria esta: Não procure criar um sistema perfeito. Procure criar um sistema que as pessoas utilizem, compreendam e em que confiem ao ponto de depender dele todos os dias.

por Pedro Gonçalo, Dynamics 365 Support Engineer na Luza