Porque falham as implementações de CRM nas PME

Uma implementação de CRM raramente falha por razões técnicas. Falha porque alguém contava que o software tomasse uma decisão que a empresa tinha deixado em aberto — e o software não decide nada. Configura-se aquilo que já foi decidido; o resto fica à espera, e o que fica à espera acaba por ser inventado por cada equipa à sua maneira.

A falha começa antes de haver software

Quando uma empresa compra um CRM para «organizar as vendas», falta perguntar o que significa organizadas. Que etapas existem entre um primeiro contacto e uma venda? O que obriga uma oportunidade a avançar? Quem é o responsável em cada etapa? O que acontece a uma proposta sem resposta há três semanas?

Estas respostas não vêm com o produto. Se a empresa não as tem, a configuração vai ser feita por quem estiver a configurar: um fornecedor a adivinhar, ou cada equipa a decidir por si. Ao terceiro mês há três formas diferentes de registar a mesma coisa, os relatórios não fecham e tira-se uma conclusão fácil e errada — «o sistema não serve». O sistema fez o que lhe pediram: espelhou uma indecisão.

Quando a plataforma reproduz a desordem que já existia

O pedido mais comum numa configuração é «queremos que funcione como já funciona». É compreensível, e é uma armadilha. Se o processo atual escreve a mesma informação em quatro sítios, copiá-lo para dentro do CRM dá quatro campos onde a mesma informação é escrita, agora com o custo de uma plataforma por cima.

Uma implementação é uma das raras ocasiões em que se pode simplificar um processo sem que ninguém leve a coisa a peito, porque a justificação já está dada: o sistema é novo, é a altura de rever. Quem não aproveita essa janela fecha-a, e a partir daí qualquer proposta de mudança volta a parecer uma crítica ao trabalho de alguém.

Isto não significa desenhar um processo ideal de raiz. Significa distinguir, em cada passo, o que existe por ser necessário e o que existe por ter sido a solução de um problema que já não há.

O arranque perfeito que nunca chega

A segunda causa é de ambição. Decide-se arrancar com tudo — todas as equipas, todos os módulos, o histórico completo, as ligações a outros sistemas — e a data vai escorregando, porque falta sempre uma peça para o conjunto estar pronto.

Cada adiamento custa mais do que tempo: custa credibilidade. Meses sem ver nada a funcionar transformam o projeto em «aquela coisa do CRM», e quando finalmente abre, abre contra a expectativa de que não vai pegar.

O contrário funciona melhor e é menos confortável, porque obriga a deixar áreas de fora durante algum tempo: uma equipa, um processo, um prazo curto, algo a funcionar de verdade e a ser usado todos os dias. Quem vê o próprio trabalho a correr melhor torna-se defensor do projeto, e é essa adesão — não o plano — que faz a fase seguinte custar menos.

Ninguém tem tempo para o projeto, e isso também é uma decisão

Um projeto sem dono é um projeto feito ao fim do dia, por quem já cumpriu o resto das suas obrigações.

Imagine uma agência com doze pessoas onde a responsabilidade do CRM fica com quem tem mais jeito para informática. Essa pessoa tem o seu trabalho por fazer, não tem autoridade para decidir que o processo comercial muda, e vai resolver aquilo que consegue resolver — os ecrãs, os campos, o que é visível — deixando em aberto o que não lhe compete: as regras. O projeto não falha por incompetência. Falha por falta de mandato, e sobre isso vale a pena ler quem deve liderar a escolha.

Dar tempo a alguém é uma decisão com custo visível, e por isso costuma ser evitada. O custo de não a tomar é invisível até ao dia em que se conclui que a plataforma não serviu.

O sinal de que está a falhar, quando ainda dá para corrigir

Há um indicador que aparece muito antes de qualquer relatório de utilização: a folha de cálculo paralela regressa. Alguém volta a manter a sua lista à parte, «só para ter à mão». Depois são dois. Depois é a lista em que a equipa confia, e o sistema passa a ser o sítio onde se copia a informação no fim do dia, quando sobra tempo — e não sobra.

Quando isso acontece, a pergunta certa não é quem está a desobedecer. É o que aquela folha tem que o sistema não dá. Quase sempre a resposta é pequena e concreta: um campo que falta, um ecrã com demasiados passos para a tarefa mais repetida do dia, um estado que existe na realidade e não existe na configuração. Corrigir isso é meio dia de trabalho. Ignorá-lo é perder a plataforma devagar, sem que ninguém decida perdê-la.

O mesmo vale para o histórico: se a equipa continua a abrir o sistema antigo para saber o que aconteceu, a migração ficou por terminar — e isso resolve-se se for tratado enquanto ainda é um hábito e não uma rotina instalada.

O que fazer se já houve uma tentativa que não pegou

Não recomece por escolher outro fornecedor. A segunda tentativa com a mesma preparação da primeira dá o mesmo resultado, com menos paciência da equipa.

Comece por escrever numa página as decisões de operação que ficaram em aberto: etapas, responsáveis, o que obriga a avançar, o que fica deliberadamente fora do sistema. Essa página vale mais do que qualquer caderno de requisitos, porque é a única parte que nenhuma plataforma pode escrever em seu lugar — e é também a parte que se aproveita toda, seja qual for o fornecedor que venha depois.

Depois escolha um processo só, com um responsável com autoridade e um prazo contado em semanas. É esta a ordem do nosso modelo de trabalho: a consultoria à operação vem antes da configuração, e o acompanhamento continua depois do arranque — porque é depois do arranque que aparecem as correções pequenas que decidem se a plataforma fica ou se volta a nascer uma folha de cálculo ao lado.