Um RFP de tecnologia pode conter dezenas de requisitos, SLAs detalhados e um processo formal de avaliação — e, mesmo assim, terminar com propostas que não são verdadeiramente comparáveis. O problema raramente surge na fase de decisão. Normalmente, começou muito antes.
Há um momento recorrente em muitos processos de sourcing tecnológico.
As propostas chegam.
Todas parecem responder ao RFP.
Todas cumprem grande parte dos requisitos.
Todas apresentam uma solução aparentemente sólida.
E, ainda assim, a comparação torna-se difícil.
Uma proposta inclui serviços que outra apresenta como opção. Um fornecedor assume determinado volume de utilização; outro utiliza pressupostos diferentes. Os modelos de licenciamento não são diretamente comparáveis. Os SLAs têm definições distintas. Os custos de implementação, migração, suporte ou evolução aparecem distribuídos de formas diferentes.
No final, a organização tem várias propostas tecnicamente válidas — mas não tem uma base suficientemente sólida para decidir.
Isto não é apenas um problema de avaliação.
É, muitas vezes, um problema de desenho do próprio RFP.
Um RFP completo não é necessariamente um RFP comparável
É fácil associar qualidade a detalhe.
Mais requisitos.
Mais páginas.
Mais perguntas.
Mais anexos.
Mas um RFP extenso pode continuar a deixar em aberto precisamente aquilo que será necessário comparar depois.
Por exemplo:
- Que requisitos são realmente críticos e quais são apenas desejáveis?
- Como deve ser tratada uma resposta parcial?
- Que pressupostos económicos devem ser comuns a todos os fornecedores?
- Que custos têm de ser apresentados separadamente?
- Como serão avaliados risco, dependência tecnológica e capacidade de evolução?
- Que peso terá cada dimensão da decisão?
Se estas regras não forem claras antes da consulta ao mercado, cada fornecedor tenderá a responder segundo a sua própria lógica comercial e técnica.
E quanto maior for a liberdade de interpretação, menor será a comparabilidade.
A decisão começa antes da shortlist
Um dos erros mais frequentes num processo de seleção é tratar o modelo de avaliação como uma etapa posterior.
Primeiro define-se o RFP.
Depois recebem-se as propostas.
Só então se decide como compará-las.
A sequência deveria ser praticamente a inversa.
Antes de enviar o RFP, a organização deve conseguir responder:
Essa pergunta obriga a estruturar antecipadamente o modelo de decisão.
Não significa escolher o fornecedor antes do processo começar.
Significa definir, com transparência, aquilo que irá distinguir uma proposta adequada de uma proposta menos adequada.
Sem isso, a avaliação tende a tornar-se uma combinação de interpretações, negociações tardias e ponderações ajustadas depois de as propostas serem conhecidas.
É precisamente aí que se perde independência.
Cinco dimensões que determinam se as propostas serão realmente comparáveis
1. Requisitos: nem tudo pode ter o mesmo peso
Uma lista extensa de requisitos não é, por si só, um bom modelo de decisão.
Se todos os requisitos forem tratados como igualmente importantes, o processo pode favorecer a solução que apresenta mais funcionalidades — e não necessariamente aquela que melhor responde ao problema de negócio.
É necessário distinguir:
- requisitos obrigatórios;
- requisitos críticos para diferenciação;
- requisitos desejáveis;
- capacidades futuras;
- elementos fora de âmbito.
A questão não é apenas saber se uma solução “tem” determinada funcionalidade.
É perceber quanto essa capacidade importa para a decisão.
2. Critérios de avaliação: a imparcialidade começa antes da pontuação
Um modelo de avaliação deve ser definido antes da receção das propostas.
Funcionalidade, arquitetura, implementação, segurança, operação, experiência, custo, risco e capacidade de evolução podem ter pesos diferentes dependendo do contexto.
A ponderação deve refletir a estratégia da organização — não a estrutura da proposta de um fornecedor específico.
Quando os critérios só são refinados depois de conhecidas as respostas, aumenta o risco de a avaliação se adaptar às soluções em vez de avaliar as soluções face à necessidade.
3. SLAs: o mesmo indicador pode significar coisas diferentes
“Disponibilidade de 99,9%” parece comparável.
Nem sempre é.
É necessário perceber:
- qual o período de medição;
- que exclusões são consideradas;
- como são tratadas intervenções programadas;
- qual a definição de indisponibilidade;
- como são calculadas penalizações;
- que serviços estão realmente abrangidos.
Sem definições comuns, dois fornecedores podem apresentar o mesmo número e assumir compromissos materialmente diferentes.
O princípio aplica-se também a tempos de resposta, tempos de resolução, continuidade, suporte e capacidade.
4. TCO: preço não é custo total
Comparar apenas o valor apresentado na primeira página financeira pode conduzir a uma decisão errada.
O custo real pode incluir:
- licenciamento;
- implementação;
- migração;
- integração;
- infraestrutura;
- serviços profissionais;
- formação;
- suporte;
- evolução;
- aumento de volumes;
- saída ou transição futura.
Além disso, os fornecedores podem apresentar horizontes temporais e pressupostos de crescimento diferentes.
Para comparar propostas de forma economicamente sustentada, é necessário normalizar esses pressupostos.
A pergunta relevante não é apenas: Quanto custa esta solução?
É: Quanto custará esta decisão ao longo do ciclo de vida relevante para a organização?
5. Risco e dependências: o que não aparece no preço também conta
Duas propostas podem parecer semelhantes do ponto de vista funcional e financeiro e criar níveis de risco muito diferentes.
Uma pode depender fortemente de componentes proprietários.
Outra pode exigir competências que a organização não possui.
Uma pode criar elevada dependência do fornecedor.
Outra pode introduzir complexidade relevante de integração.
Por isso, a avaliação deve incluir fatores como:
- dependências tecnológicas;
- capacidade interna necessária;
- risco de implementação;
- flexibilidade contratual;
- capacidade de evolução;
- facilidade de transição;
- concentração no fornecedor.
Sem esta dimensão, o processo pode otimizar o preço inicial e aumentar o risco futuro.
Normalizar não significa eliminar diferenças
O objetivo de um bom RFP não é obrigar todos os fornecedores a apresentar propostas idênticas.
Isso seria contraproducente.
A inovação, a experiência e as diferentes abordagens dos fornecedores fazem parte do valor de uma consulta ao mercado.
Normalizar significa criar uma estrutura comum suficiente para distinguir diferenças reais de simples diferenças de apresentação.
Por exemplo:
| Sem normalização | Com base comparável |
|---|---|
| Cada fornecedor apresenta o preço segundo a sua estrutura | Todos respondem a pressupostos económicos comuns |
| SLAs com definições próprias | Métricas e regras de medição pré-definidas |
| Requisitos tratados como lista única | Criticidade e prioridade explicitadas |
| Avaliação sobretudo qualitativa | Critérios e ponderações definidos antecipadamente |
| Risco discutido no final | Risco integrado no modelo de avaliação |
O objetivo não é reduzir a riqueza das propostas.
É garantir que a diferença entre elas é visível e relevante para a decisão.
Quando a comparação é difícil, a negociação também perde qualidade
Um RFP pouco comparável não prejudica apenas a seleção.
Também reduz a qualidade da negociação.
Se a organização não consegue explicar claramente porque uma proposta é superior noutras dimensões, o preço tende a ganhar peso excessivo.
E quando as propostas têm estruturas financeiras ou contratuais muito diferentes, a negociação torna-se mais difícil de conduzir com disciplina.
Uma base comparável permite negociar melhor porque torna mais claros:
- os pontos fortes e fracos de cada solução;
- os elementos críticos a proteger;
- os desvios face ao modelo esperado;
- as concessões aceitáveis;
- o impacto económico de cada alteração.
A organização passa a negociar com critérios, e não apenas com posições.
Um processo defensável deixa um rasto de decisão
A qualidade de uma seleção tecnológica não se mede apenas no momento da escolha.
Meses ou anos depois, alguém pode perguntar:
Uma decisão robusta deve poder ser explicada.
Que critérios foram utilizados?
Que alternativas foram consideradas?
Que riscos foram identificados?
Que trade-offs foram aceites?
Que pressupostos económicos sustentaram a decisão?
Que exceções foram aprovadas?
Esta rastreabilidade é particularmente importante quando a decisão envolve investimento relevante, múltiplas áreas internas, risco tecnológico ou exposição executiva.
Um bom processo de RFP não deve apenas chegar a uma escolha.
Deve permitir explicar porque essa escolha foi racional e defensável.
Antes de lançar o próximo RFP, cinco perguntas
Antes de enviar o documento ao mercado, vale a pena testar se a organização consegue responder a estas perguntas:
- Sabemos quais os critérios que realmente irão decidir a seleção?
- Todos os fornecedores irão responder aos mesmos pressupostos económicos e operacionais?
- Os SLAs e requisitos estão definidos de forma suficientemente objetiva para serem comparados?
- Risco, dependências e capacidade de evolução fazem parte da avaliação?
- Conseguiremos justificar a decisão final sem reconstruir o racional depois?
Se alguma destas respostas for “não”, é provável que o problema da avaliação já esteja a ser criado antes de as propostas chegarem.
O melhor RFP não é o que gera mais respostas. É o que permite decidir melhor.
Um processo de sourcing tecnológico não deve ser avaliado apenas pela qualidade do documento ou pelo número de propostas recebidas.
O verdadeiro teste surge quando chega o momento de comparar.
As alternativas são comparáveis?
Os trade-offs são visíveis?
Os custos são economicamente equivalentes?
Os riscos estão explícitos?
A decisão consegue ser explicada e defendida?
Quando estas condições existem, a escolha torna-se mais clara e a negociação mais disciplinada.
Quando não existem, a organização pode terminar com um RFP tecnicamente completo — e uma decisão pouco robusta.
Na aiteris, o RFP Drive estrutura processos de sourcing e seleção com critérios claros, comparabilidade, imparcialidade e rastreabilidade, ajudando a acelerar a decisão sem reduzir rigor.
Perguntas frequentes
O que torna duas propostas de RFP verdadeiramente comparáveis?
Não basta que respondam aos mesmos requisitos. É necessário que utilizem pressupostos económicos, definições de serviço, critérios de avaliação e regras de apresentação suficientemente consistentes para permitir uma comparação objetiva.
Quando deve ser definido o modelo de avaliação de um RFP?
Antes de o RFP ser enviado ao mercado. Definir critérios e ponderações depois de receber as propostas aumenta o risco de a avaliação ser influenciada pelas respostas dos fornecedores.
O preço mais baixo é necessariamente a melhor proposta?
Não. O preço deve ser analisado no contexto do TCO, risco, capacidade de implementação, dependências, flexibilidade e valor esperado para o negócio.
Porque é importante incluir risco no modelo de avaliação?
Porque duas soluções semelhantes em funcionalidade e preço podem criar níveis muito diferentes de dependência, complexidade operacional, risco de implementação e capacidade de evolução futura.
Como tornar uma decisão de sourcing defensável?
Definindo antecipadamente requisitos, critérios, ponderações e pressupostos; documentando a avaliação; tornando explícitos os trade-offs; e mantendo rastreabilidade sobre a razão pela qual uma alternativa foi escolhida.
DA PROPOSTA À DECISÃO DEFENSÁVEL
Estruture o próximo RFP de tecnologia com o RFP Drive
O RFP Drive ajuda a estruturar requisitos, SLAs e modelos de avaliação para melhorar comparabilidade, imparcialidade e valor económico em processos de sourcing tecnológico.
accelerating what matters.
