O que um bom documento de RFP deve gerar
O objetivo de uma RFP (Request for Proposal) não é obter apenas um preço, mas sim receber propostas comparáveis que permitam identificar qual fornecedor compreendeu verdadeiramente o problema. Um documento que lista cem requisitos e solicita marcações de "suporta / não suporta" atinge o efeito oposto: todos os fornecedores marcam "suporta", e a decisão se resume ao preço.
Uma diferença prática: em vez de escrever "o sistema deve permitir o gerenciamento de oportunidades", descreva que a empresa gerencia cerca de quatrocentas transações por mês, que cada transação passa por uma aprovação de precificação, e que essa aprovação é atualmente feita por e-mail. Os fornecedores apresentarão respostas muito distintas – e é exatamente isso que se busca.
As nove seções de um documento de RFP para Salesforce
1. Contexto e Objetivo de Negócio. O que a organização faz, qual é o problema e o que será considerado sucesso em um ano. Uma seção de um parágrafo a uma página.
2. Situação Atual. Sistemas em uso, número de usuários, o que funciona hoje e o que não funciona. Se já existe um ambiente Salesforce, especifique a edição, tempo de uso e nível de personalização.
3. Processos Essenciais no Escopo. Três a sete processos, cada um em um parágrafo: quem executa, quais são os pontos de decisão, o que acontece quando algo foge do padrão.
4. Volumes e Dados. Número de registros para cada entidade principal, taxa de criação mensal, anos de histórico a serem mantidos e o estado conhecido da qualidade dos dados. Esta é a seção que mais impacta a precisão da precificação e que, com frequência, é ignorada.
5. Integrações. Para cada sistema: nome, tipo de interface (se conhecido), direção, frequência requerida e quem é o proprietário na organização.
6. Restrições. Regulamentação, segurança da informação, localização do armazenamento, idiomas, acessibilidade, prazos inegociáveis.
7. O que é Requerido do Proponente. Abordagem proposta, plano de ondas, composição da equipe com nomes e funções, premissas, riscos e precificação em uma estrutura padronizada.
8. Método de Avaliação. Critérios e pesos, divulgados antecipadamente. Isso gera propostas mais focadas e reduz discussões após a seleção.
9. Cronograma da Solicitação. Prazo para perguntas, prazo para respostas, prazo para submissão, prazo para demonstrações, prazo para decisão.
Dados Essenciais a Revelar para Ter uma Precificação Realista
| Dado | Por que é crítico | O que acontece sem ele |
|---|---|---|
| Número de usuários por tipo | Define licenciamento, treinamento e permissões | Propostas com um intervalo de preços muito amplo |
| Volume de registros e histórico | Define o esforço de migração | A migração é precificada com uma estimativa grosseira |
| Número de sistemas de origem | Define a complexidade e a integração | Surpresas após a assinatura do contrato |
| Nível de documentação existente | Define o nível de descoberta necessário | Fornecedores presumem documentação existente |
| Disponibilidade dos proprietários de processo | Define o ritmo das decisões | Um cronograma irreal é acordado por ambas as partes |
| Orçamento ou faixa de valores | Foca a solução | Propostas incomparáveis |
Perguntas que Distinguem Fornecedores
As perguntas a seguir recebem respostas muito diferentes de diversos fornecedores, e por isso são úteis. Uma pergunta à qual todos respondem de forma idêntica não vale a pena ser incluída no documento.
- Quais são as três principais premissas nas quais esta proposta se baseia, e qual o impacto se uma delas estiver incorreta?
- Em quais casos você recomendaria configuração, mesmo que desenvolvimento funcionasse melhor, e vice-versa?
- Descreva um projeto no qual vocês excederam o cronograma. O que causou isso e o que mudaram desde então?
- Quem serão os membros reais da equipe, e qual a porcentagem do tempo que cada um dedicará a este projeto?
- O que vocês precisam de nós para ter sucesso, e o que farão se não receberem isso?
- Como vocês nos transferirão a capacidade de manter o sistema sem a sua dependência?
A última pergunta é um bom teste para a natureza do engajamento. Um fornecedor que a evita planeja criar dependência.
O Que Exigir Como Entregáveis na Proposta
- Um diagrama de arquitetura inicial em nível de blocos, incluindo fontes de verdade.
- Um plano de ondas com o conteúdo de cada onda, e não apenas datas.
- Uma detalhamento de precificação em estrutura unificada que você definir, por fase e por função.
- Uma lista explícita de premissas.
- Um mapa de riscos com estratégias de mitigação.
- Um exemplo de entregável real de um projeto anterior, com nomes omitidos — por exemplo, um documento de decisões ou um plano de testes.
O último item é talvez o mais distintivo, pois mostra um padrão de trabalho e não apenas uma promessa.
Estrutura de Precificação Unificada — A Ferramenta que Impede a Comparação de "Maçãs com Laranjas"
Defina você mesmo a tabela que todo proponente deve preencher:
| Fase | Horas Sênior | Horas Júnior | Custo | O que é considerado concluído |
|---|---|---|---|---|
| Levantamento | ||||
| Configuração e Desenvolvimento para a Onda 1 | ||||
| Integrações | ||||
| Migração de Dados | ||||
| Testes e UAT | ||||
| Treinamento e Adoção | ||||
| Estabilização Pós-Go-Live | ||||
| Gerenciamento de Projetos |
Um fornecedor que se recusa a detalhar o preço de acordo com esta estrutura não é necessariamente mais caro, mas não pode ser comparado, e essa é uma razão suficiente para exigir essa informação.
Exemplo Ilustrativo: Fundo de Previdência Médio Porte
O cenário é hipotético e serve para ilustração. Uma instituição financeira emitiu uma RFP que incluía oitenta requisitos funcionais em uma tabela. Os quatro proponentes marcaram "suporta" em quase todas as linhas, e as propostas diferiam apenas no preço e no número de horas.
Em uma segunda rodada, o documento foi alterado: em vez da tabela de requisitos, foram incluídos três processos detalhadamente descritos, dados de volume reais e uma solicitação para resolver um cenário específico em uma demonstração. As propostas recebidas diferiram substancialmente — uma propôs um modelo de dados completamente diferente, outra identificou uma dependência de aprovação regulatória que ninguém havia considerado.
O comitê não optou pela proposta mais barata e não a questionou. Escolheu aquela que conseguiu explicar por que o sétimo requisito no documento original não era necessário de forma alguma.
Erros Comuns na Redação de RFPs
- Copiar um documento de outro projeto sem ajustar volumes e processos.
- Exigir uma lista de clientes em vez de exemplos de entregáveis.
- Critérios de avaliação formulados após o recebimento das propostas.
- Um cronograma que não deixa tempo para perguntas e respostas.
- Uma preferência oculta por um fornecedor existente, o que faz com que outros invistam em vão e prejudica a qualidade das propostas futuras.
O Que Acontece Após a Submissão
Um bom documento é apenas metade do trabalho. A próxima etapa é a normalização e comparação das propostas em uma base comum, conforme detalhado no Guia de Comparação de Propostas Salesforce, e então a pontuação estruturada de acordo com pesos predefinidos, conforme detalhado no Guia de Scorecard para Seleção de Fornecedores.
A base de informações para a redação do documento geralmente provém de um breve processo de consultoria, como descrito no Guia de Consultoria Salesforce, e os critérios para a avaliação da empresa estão agrupados no Guia para Escolher uma Empresa de Implementação Salesforce.
Próximo Passo
Antes de enviar o documento, faça um teste: peça a alguém na organização que não esteja envolvido no projeto para lê-lo e explicar em uma frase qual é o problema que você está tentando resolver. Se essa pessoa não conseguir, os fornecedores também não conseguirão — e eles simplesmente apresentarão o que estão acostumados a vender.