A RFx tradicional não funciona para compras de software
Comprador, ainda é quarta-feira #44
Nos últimos 06 anos que passei tocando a Linkana, já perdi as contas da quantidade de RFI/RFPs que recebi ou participei.
Concorrências de compras em vários tipos e formatos, com longas planilhas de requisitos técnicos, prazos rígidos para envio de propostas e materiais de apoio, além de reuniões de apresentações, demonstrações e sessões de dúvidas.
Mesmo nas concorrências que venci, me parece que este modelo tradicional não é nem de longe a melhor forma para se escolher algo complexo como um software.
E hoje vou compartilhar algumas dessas reflexões com você.
O que é e para que serve uma RFx?
Uma RFx é o conjunto formal de solicitações comumente utilizadas por grandes empresas para solicitar informações, orçamentos e propostas de fornecedores.
Cada tipo específico pode ser utilizado em diferentes etapas de processos de concorrência de compras:
RFI (Request for Information) → Solicitação inicial de informações técnicas para entender melhor as ofertas e opções de fornecedores no mercado;
RFQ (Request for Quotation) → Solicitação do orçamento de valores previstos para a contratação ou aquisição de materiais da concorrência;
RFP (Request for Proposal) - Solicitação da proposta formalizando os requerimentos técnicos atendidos e as condições comerciais oferecidas pelo concorrente.
A ideia de fazer solicitações via RFx surgiu ainda no final do século XIX, a partir da padronização da produção de bens e insumos trazida pela Revolução Industrial. Na época, as empresas compradoras passaram a solicitar ofertas de fornecedores com publicações em jornais e anúncios comerciais, onde já existia a prática de fazer perguntas técnicas para ajudar o comprador a comparar e avaliar as ofertas de cada fornecedor.
Há quase 150 anos, a RFx se consolidou como uma ótima ferramenta para avaliar requisitos e preços de materiais e serviços mais padronizados e commoditizados, como serviços de facilities, material de escritório ou matérias-primas. Para estas categorias, é um processo que normalmente reduz custos e incentiva a inovação entre fornecedores, pela facilidade de comparação entre diferentes concorrentes.
Por outro lado, para contratação de produtos mais complexos, como software, requisitos técnicos são bem mais difíceis de serem avaliados, o que torna a comparação entre concorrentes uma tarefa bem mais difícil. Neste contexto, uma RFx não funciona tão bem e pode acabar tendo o efeito inverso do desejado pelo time de Procurement da sua empresa.
O dilema do prisioneiro na RFx
Gostei muito da forma como o Joël Collin-Demers defendeu este ponto, fazendo uma analogia entre a RFx e o clássico dilema do prisioneiro.
O dilema do prisioneiro é um cenário hipotético onde indivíduos enfrentam uma escolha que pode levar à cooperação ou à traição.
Cada jogador deve decidir se coopera com o outro e permanece em silêncio sobre um crime cometido juntos, resultando em um resultado favorável para os dois, ou se trai o outro, ganhando uma vantagem pessoal enquanto causa dano ao outro jogador.
Trazendo para o nosso contexto, quando sua empresa envia uma RFx para fornecedores, ela está assumindo o papel do policial do dilema. Em vez de ameaçar prender os fornecedores, você está pressionando para que eles ofereçam as melhores condições técnicas e comerciais possíveis para terem uma chance de vencer a concorrência.
O problema é que isso só funciona bem quando os requisitos técnicos da RFx são de fácil definição e quando o escopo não muda.
E por que a RFx tradicional não funciona para compras mais complexas?
Não menos que 92% dos megaprojetos acabam ultrapassando o orçamento ou o cronograma, ou ambos.
- Bent Flyvbjerg em seu livro How big things get done (2023).
Quando você usa uma RFx para bens ou serviços complexos, como softwares, da mesma maneira que faria para bens ou serviços commoditizados, a mensagem principal para os fornecedores envolvidos é que sua empresa vai otimizar para que:
se atenda o máximo de requerimentos técnicos possíveis;
ao menor preço possível.
O problema é que sua empresa está realizando uma concorrência em um assunto que não é a maior especialidade dela. Por mais experiente que seja o comprador de um software de Procurement, por exemplo, os detalhes e necessidades técnicas são extremamente difíceis de padronizar numa planilha de requerimentos.
Quando você quer que uma planilha como esta seja respondida em uma RFx para aquisição de um software, é natural que você tenha dificuldade para avaliar se o fornecedor está falando a verdade nas respostas. Por sua vez, isso cria um incentivo para que os fornecedores respondam os requisitos da planilha para maximizar as chances de vitória, e não de maneira realista.
Mesmo que uma resposta não seja verdade, o fornecedor ganha uma vantagem competitiva sobre seus outros concorrentes, imaginando que eles provavelmente estão fazendo a mesma coisa. Assim como no caso dos prisioneiros, independentemente do os outros concorrentes fizerem, traí-los sempre oferece um retorno individual maior do que a cooperação mútua.
Se sua empresa busca o melhor software possível, você quer o cenário em verde. Mas se RFx é feita a partir das premissas que mencionei, você vai acabar com o cenário vermelho, que de acordo com Bent Flyvbjerg, acontece em 92% dos projetos complexos realizados.
O motivo é simples: os concorrentes podem até começar oferecendo projetos sensatos e realistas, mas logo vão perceber que não ganham nenhuma concorrência, ou são rapidamente pressionados pelo comprador para reduzir preços ou aumentar o escopo “para não perder para o outro concorrente”.
Com isso, a postura muda. Os fornecedores de software passam a oferecer condições fora da realidade para vencer a concorrência a qualquer custo. Uma vez que ele está “dentro”, eles percebem que é mais fácil solicitar mudanças de escopo, extensão de prazo e até aumento de custos.
É o famoso “isso a gente resolve depois de vencer a RFx”.
Qual é a alternativa, então?
Se o sucesso de um software realmente é importante para sua empresa, você precisa aplicar um método de busca de soluções verdadeiramente colaborativo.
Isso significa pautar a mudança o seu processo de concorrência para não incentivar propostas sem sentido e fora da realidade, a partir de:
definição dos problemas (ex.: lentidão, falta de engajamento do usuário, baixa satisfação) a serem resolvidos pela solução;
valor esperado (ex.: redução de lead-time, maior engajamento, saving) com a implementação da solução.
provas de conceito para testar na prática o software do fornecedor em provas de conceito com casos de uso reais, antecipando problemas e requisitos não mapeados;
feedbacks e opiniões técnicas de usuários diretos e indiretos da solução;
benchmarks para entender as capacidades técnicas do fornecedor em cenários similares em outras empresas;
comunicação e troca transparente com os fornecedores quanto problemas internos da sua empresa, mudanças de escopo e de processo;
avaliação individualizada da proposta do fornecedor em relação ao valor esperado com a implementação da solução.
E como disse Joël, se sua política de compras for rígida demais e não permitir esse tipo de processo ágil e colaborativo, é hora de mudá-la, ou fazer campanha por reformas e mudanças.
E se não for possível mudar, e o jeito for mandar uma RFx tradicional, ao menos tente ao máximo incorporar as sugestões acima ao seu processo de concorrência.
Isso se você não quiser continuar como parte dos 92% das empresas que implementam softwares estourando o cronograma e o custo previsto.
Você sabe muito bem do eu que estou falando.
leo c.