Quem deve liderar a escolha de um CRM na empresa

A escolha de um CRM costuma cair sobre quem tem menos condições para a fazer: a pessoa com mais jeito para informática, o diretor que tem o orçamento mas não conhece o dia a dia, ou o departamento que se queixou mais alto na última reunião. Nenhum destes está mal-intencionado, e nenhum deles tem, sozinho, o que a decisão exige.

Quem escolhe não é quem paga nem quem instala

São três funções distintas, e confundi-las é a origem de quase todos os projetos que ficam a meio. Quem paga aprova o investimento. Quem instala garante que aquilo funciona e se liga ao resto.

Mas escolher um CRM é decidir como a empresa vai trabalhar: que etapas existem, quem vê o quê, o que é obrigatório registar, o que acontece quando alguém não cumpre um prazo. É uma decisão de operação antes de ser de software, e só a pode tomar quem tem autoridade para mudar o processo. Quando essa autoridade não está na mesa, decide-se pelo que é mais fácil de aprovar e a operação fica por decidir — que é uma das causas mais frequentes de uma implementação que não pega.

Três papéis, e o que falha quando falta um

• Quem decide. Uma pessoa, com autoridade sobre o processo e não apenas sobre o orçamento. Sem ela, o projeto paralisa no primeiro desacordo entre departamentos — e há sempre um primeiro desacordo.
• Quem representa a operação. Um responsável por cada área que vai usar o sistema, escolhido por conhecer o trabalho real e não por posição na hierarquia. Sem estas pessoas, a configuração assenta no processo que está escrito, que raramente é o processo que se pratica.
• Quem valida a viabilidade. Informática, interna ou externa, para dizer o que é possível, o que é arriscado e o que implica trabalho que ninguém contou. Sem esta voz aprovam-se promessas; com ela a decidir sozinha, escolhe-se o que é mais cómodo de manter.

Falta muitas vezes um quarto contributo, que não decide mas devia ser ouvido: quem vai ter aquilo aberto à frente enquanto fala com um cliente. É essa pessoa que descobre, numa demonstração, que a tarefa mais repetida do dia leva sete passos — e é esse detalhe, e não a lista de funcionalidades, que determina se o sistema vai ser usado.

O erro de dar veto a todos

Por prudência, envolve-se todo o mundo e trata-se cada objeção como um bloqueio. O resultado é conhecido: procura-se a plataforma que não desagrada a ninguém e acaba-se com a que ninguém quer defender.

Consultar e decidir são coisas diferentes, e é preciso dizê-lo em voz alta no início, antes da primeira demonstração. Todos os envolvidos dão a sua opinião e apontam riscos; uma pessoa decide; a decisão é comunicada com as razões, incluindo as objeções que não foram aceites e porquê. Uma equipa aceita melhor uma escolha que não era a sua, explicada, do que um consenso morno que ninguém assume.

Há um caso em que a objeção é mesmo um bloqueio: quando uma área diz que aquele desenho a obriga a trabalhar de forma que não cumpre uma obrigação legal ou um compromisso assumido com clientes. Aí não é preferência, é requisito. Distinguir as duas coisas é, ela própria, uma das perguntas mais úteis que o grupo pode aprender a fazer.

Porque é que a informática não deve decidir sozinha — nem ficar de fora

Se a decisão for entregue ao critério técnico, os critérios serão técnicos: o que se liga melhor ao que já existe, o que a equipa domina, o que dá menos trabalho a manter. São critérios legítimos e insuficientes, porque nenhum deles responde se a empresa vai vender melhor, responder mais depressa ou perder menos contexto entre equipas.

Deixá-la de fora é o erro simétrico e sai mais caro. Decide-se, promete-se à equipa uma data, e depois descobre-se que a informação que se queria aproveitar não existe em formato utilizável, ou que aquilo obriga a um trabalho de manutenção que ninguém orçamentou. A informática deve entrar cedo, e a pergunta certa a fazer-lhe não é «gostas?». É «o que é que isto nos obriga a fazer que não está no plano?»

Como montar o grupo antes da primeira demonstração

Não precisa de um comité nem de um regulamento. Precisa de uma página com nomes: quem decide, quem representa cada área, quem valida a viabilidade, e quem é o dono do projeto no dia a dia — que pode ser a mesma pessoa que decide, se tiver tempo, e quase nunca tem.

Ao lado de cada nome, escreva a pergunta a que aquela pessoa responde. E escreva a data em que a decisão vai ser tomada: um processo de escolha sem data acaba empatado por comparação infinita, porque haverá sempre uma plataforma que ainda não foi vista.

Depois, traga essas pessoas à mesma sessão, em vez de as ouvir uma a uma. É para isso que o diagnóstico de quarenta e cinco minutos do nosso modelo de trabalho é feito: a maior parte das perguntas que aparecem ali não são sobre software, são sobre a empresa, e é muito mais barato descobrir um desacordo entre duas áreas nessa hora do que três meses depois, com a configuração já feita. Se quiser saber com quem vai estar do outro lado da mesa, está descrito em quem somos; se já tem o grupo formado, marque a sessão e traga o processo que mais dói, não o mais bonito.