RFP de implementação SAP: o que pedir e como pontuar

Uma RFP de implementação SAP deve pedir aos parceiros evidências, não promessas: referências de projetos semelhantes, currículos das pessoas que vão alocar e uma arquitetura e um plano para o seu escopo. Pontue as propostas com pesos que você fixa antes que elas cheguem e depois use as apresentações orais para verificar se a equipe de entrega sabe explicar o plano.

Resposta curta: a RFP é um teste das pessoas e do plano, não dos slides de metodologia.

Este artigo trata apenas da etapa de solicitação de proposta (RFP, request for proposal) da decisão. O processo completo de seleção, da lista longa ao contrato, está no meu guia sobre como escolher um parceiro de implementação SAP.

Nos 21 programas SAP que liderei ou resgatei, o maior erro que vejo é não planejar direito no início. Uma RFP SAP enviada antes de você conhecer o seu próprio escopo convida cada parceiro a preencher as lacunas com as próprias premissas. Aí você não consegue comparar as propostas, porque cada uma precifica um programa diferente.

Por isso a ordem importa. Defina o seu escopo, os processos dentro e fora, as entidades e os países, as integrações e os dados, e depois escreva a RFP em torno disso.

O escopo também protege o orçamento mais adiante. Os orçamentos estouram na fase Explore do SAP Activate, onde o método da SAP conduz workshops de fit-to-standard e registra as lacunas no backlog.

É ali que a lista WRICEF (workflows, relatórios, interfaces, conversões, ampliações e formulários) cresce, e cada objeto novo é custo. Uma RFP construída sobre o seu escopo dá a você uma linha de base para medir esse crescimento.

Envie a RFP a uma lista final de pelo menos três parceiros.

Monte a lista longa no SAP Partner Finder, onde a SAP mostra as competências que os parceiros têm no SAP PartnerEdge, cada uma em três níveis: essential, advanced e expert. Um selo garante um lugar na lista. Ele não garante o contrato.

A seleção inteira leva cerca de 12 semanas do início ao fim.

Como funciona a etapa de RFP SAP

1. 01

   Escopo

   Escreva você mesmo o escopo, os processos, as entidades, as integrações e os dados antes que qualquer parceiro os veja.

2. 02

   RFP

   Envie um único pacote a uma lista final de pelo menos três parceiros, com os pesos de pontuação já fixados.

3. 03

   Propostas escritas

   Pontue cada proposta com base nos pesos e sinalize qualquer resposta genérica.

4. 04

   Apresentações orais

   Peça à equipe de entrega proposta que explique pessoalmente a arquitetura e o plano.

5. 05

   Referências

   Ligue para referências de projetos como o seu e pergunte sobre a experiência do parceiro neles.

6. 06

   Contrato

   Leve o esforço, as pessoas nomeadas e as premissas da proposta vencedora para a declaração de trabalho.

Uma RFP SAP tem duas metades: o que você entrega aos parceiros e o que você pede que eles devolvam.

O que você entrega aos parceiros

Entregue a todos os parceiros o mesmo pacote, ao mesmo tempo. Quanto melhor o pacote, mais específicas as respostas:

1. Contexto e objetivos. Por que você está implementando SAP, o que o negócio precisa conseguir fazer depois e as datas que importam.
2. Escopo. Processos dentro e fora, entidades, países, usuários por grupo e os produtos SAP que você espera usar.
3. Integrações e dados. Os sistemas aos quais o SAP precisa se conectar, os objetos de dados a migrar e o que você sabe sobre a qualidade deles.
4. A sua própria equipe. Quem você pode colocar no programa, com quanto do tempo dessas pessoas, e quais funções você espera que o parceiro preencha.
5. O formato da resposta. Uma estrutura fixa e um limite de páginas, para que você compare em pé de igualdade.
6. Os critérios e pesos de avaliação. Diga aos parceiros como eles serão pontuados. Isso os faz responder às perguntas que contam.
7. O cronograma. Prazo para perguntas, prazo para propostas, as datas das apresentações orais e a data da decisão.

O que você pede aos parceiros

A maioria das RFPs SAP pede aos parceiros que descrevam a si mesmos, e os parceiros são muito bons nisso. Peça, em vez disso, coisas que você possa verificar:

1. Referências de projetos semelhantes. Os mesmos produtos SAP, porte semelhante, setor semelhante, com um contato para quem você possa ligar.
2. A equipe de entrega nomeada. Currículos, a função que cada pessoa vai exercer, a parcela do tempo dela no seu programa e a disponibilidade para as suas datas.
3. Certificações que você possa verificar. A SAP emite certificações como selos digitais que permitem verificação em tempo real. Peça os links dos selos das pessoas nomeadas, não uma contagem de certificados da empresa.
4. A arquitetura e o plano. Um desenho de alto nível para o seu escopo e um plano por fase do SAP Activate, com os marcos e as dependências.
5. Esforço por fase e por função. Dias estimados para cada função em cada fase, não apenas um preço total.
6. Premissas e exclusões em detalhe. Tudo aquilo de que o preço depende e tudo o que ele não cobre.
7. O modelo comercial e a tabela de valores. Diárias por função e local de entrega, viagens e despesas, e como as mudanças serão precificadas.
8. Como vão controlar o crescimento do escopo na fase Explore. O método deles para tratar novos objetos WRICEF e quem os aprova.

Sobre o modelo comercial, recomendo tempo e materiais com o esforço quantificado. O esforço estimado por fase e por função entra no contrato, para que você possa acompanhar todo mês o esforço real em relação a ele. É pedir isso na RFP que torna esse acompanhamento possível mais tarde.

Sobre as diárias, não ancore os parceiros com um número. Peça a tabela de valores deles e compare com as faixas do meu guia sobre planejamento de alocação de recursos em projetos SAP.

Premissas e exclusões são o que os clientes mais deixam de fora de uma declaração de trabalho. Se a RFP as pedir em detalhe, você as terá antes de negociar. O meu guia sobre a declaração de trabalho SAP mostra como elas passam para o contrato.

Fixe os pesos antes da chegada das propostas e não os altere depois de ler as respostas. Mudar os pesos depois é a forma de escolher um favorito e justificá-lo a posteriori.

Quando ajudo um cliente a escolher um parceiro, as referências de clientes têm o maior peso. Duas coisas me fazem descartar uma proposta, seja qual for a pontuação total: a baixa qualidade dos recursos propostos e um parceiro que não consegue explicar a arquitetura e o plano. A pontuação deve refletir as duas.

A tabela abaixo é um exemplo de ponderação construída sobre essas prioridades. Ajuste os percentuais ao seu programa, mas mantenha as referências em primeiro lugar e mantenha os dois testes eliminatórios.

Critério	Peso de exemplo	Como é uma nota alta	Sinal para descartar
Referências	30%	Projetos semelhantes, contatos acessíveis, referências que confirmam o papel do parceiro	Nenhuma referência em projeto comparável, ou referências para as quais o parceiro não deixa você ligar
Qualidade dos recursos	25%	Pessoas nomeadas com currículos relevantes, certificações verificáveis e disponibilidade confirmada	Funções sem nome, currículos fracos ou pessoas-chave "sujeitas a disponibilidade"
Arquitetura e plano	25%	Um desenho para o seu escopo e um plano por fase com marcos, dependências e riscos	Um plano genérico, ou um desenho que eles não conseguem explicar nas apresentações orais
Comercial	10%	Esforço por fase e por função, diárias claras, premissas e exclusões detalhadas	Um único preço total sem esforço por trás
Abordagem	10%	Um método claro para controle de escopo, testes, dados e transferência de conhecimento	Slides de metodologia sem nada específico para você

Pontue cada critério em uma escala simples, por exemplo de 1 a 5, com uma justificativa por escrito. Cada avaliador pontua sozinho primeiro, depois o comitê compara.

Trate os dois sinais eliminatórios como barreiras, não como pontos. Uma proposta com condições comerciais fortes não compensa uma equipe fraca. O critério comercial tem peso baixo de propósito: a diária é uma variável pequena perto do esforço e do retrabalho.

A proposta escrita mostra o que a equipe de vendas sabe escrever. As apresentações orais mostram se as pessoas que vão fazer o trabalho o entendem.

Peça, pelo nome, as pessoas que de fato vão compor a equipe do seu programa. O arquiteto de soluções, o gerente do programa e os líderes das suas maiores frentes de trabalho devem estar na sala. Se o parceiro trouxer outra equipe, registre isso na pontuação.

Depois, peça que expliquem a arquitetura e o plano para o seu escopo, sem slides se possível. Boas perguntas para usar:

1. Mostrem o desenho dos nossos dois processos mais complexos. Preste atenção aos nomes dos seus processos, das suas entidades e dos seus sistemas.
2. O que acontece na fase Explore se a lista WRICEF crescer um terço? Preste atenção a um método, a um fórum de decisão e a uma conversa sobre custo.
3. Quais premissas da proposta de vocês carregam mais risco? Um parceiro que conhece o próprio plano consegue citá-las na hora.
4. Quem desta equipe já fez isso antes, e onde? Depois confira a resposta nas ligações para referências.
5. O que vocês precisam da nossa equipe, e quando? Um plano real tem dependências do cliente com datas.

Um parceiro que não consegue explicar a sua arquitetura e o seu plano na sala não vai entregá-los no projeto. Esse é o segundo motivo pelo qual descarto uma proposta.

Já troquei de parceiro no meio de um programa porque ele não conseguia fornecer recursos de qualidade. A disponibilidade de boas pessoas é o que você deve testar com mais rigor antes de assinar.

Ligações para referências

As ligações para referências são importantes e muitas vezes são feitas como mera formalidade. Faça-as direito. O que pergunto às referências é a experiência delas com o parceiro em projetos semelhantes ao seu.

Antes da ligação, compare a referência com o seu próprio programa: mesmos produtos, porte semelhante, setor semelhante. Se a correspondência for fraca, peça outra ao parceiro.

Na ligação, pergunte quem do parceiro liderou o trabalho, o que fez bem e onde teve dificuldades. Depois pergunte se essas pessoas estão na sua proposta.

Como identificar respostas genéricas

Respostas genéricas são o sinal de alerta em qualquer RFP SAP. Uma resposta que poderia ser enviada a qualquer empresa foi escrita para qualquer empresa.

O teste mais rápido é trocar o nome da sua empresa em uma resposta pelo de um concorrente. Se a resposta continuar fazendo sentido, ela não foi escrita para você. O meu guia sobre como escolher um parceiro de migração S/4HANA trata desse teste para migrações com mais detalhe.

Em uma resposta de RFP, as respostas genéricas costumam aparecer nestes pontos:

1. A seção de escopo repete a sua RFP de volta para você. Não acrescenta nenhuma visão sobre o que é difícil no seu programa.
2. O plano usa durações redondas para todas as fases. Nada nele depende das suas entidades, dados ou integrações.
3. Perguntas sobre os seus processos recebem respostas sobre aceleradores. A ferramenta é citada, o uso dela para você não.
4. Os riscos valem para o setor inteiro. Aparecem "qualidade dos dados" e "resistência à mudança", e nada específico dos seus sistemas.
5. A seção da equipe lista funções, não pessoas. Em geral é o mesmo problema dos recursos fracos, com outras palavras.

Dê nota baixa a uma resposta genérica mesmo quando ela for bem escrita.

Avaliar os documentos do parceiro também é onde uma visão independente ajuda. Um consultor que não está concorrendo pode testar o desenho e as estimativas de esforço e, mais tarde, os entregáveis. Os prós e contras estão na minha comparação entre parceiro SAP e consultor independente.

Antes de qualquer outra coisa, escreva o seu escopo. Uma página por área de processo, listando o que está dentro, o que está fora, as entidades e os sistemas envolvidos. Sem isso, cada número das propostas se apoia nas premissas do parceiro.

Para nomes de parceiros por nível, veja o meu guia sobre parceiros de implementação SAP nos EUA por nível.

Se você quiser uma visão independente sobre uma RFP, a pontuação ou as propostas que recebeu, eu ajudo organizações com isso. Você pode falar comigo aqui.

O que uma RFP de implementação SAP deve incluir?

Entregue aos parceiros o seu contexto e objetivos, o seu escopo, as suas integrações e dados, a equipe que você pode fornecer, um formato de resposta fixo, os critérios de avaliação e o cronograma. Peça referências em projetos semelhantes e a equipe de entrega nomeada, com currículos. Peça uma arquitetura e um plano por fase do SAP Activate, o esforço por fase e por função e premissas e exclusões detalhadas.

Como pontuar as propostas de parceiros de implementação SAP?

Fixe critérios ponderados antes da chegada das propostas: referências, qualidade dos recursos, arquitetura e plano, comercial e abordagem. Cada avaliador pontua sozinho em uma escala simples, com uma justificativa por escrito, e depois o comitê compara. Trate recursos fracos e um plano que o parceiro não consegue explicar como motivos para rejeitar uma proposta, seja qual for a pontuação total.

Quantos parceiros devem receber uma RFP SAP?

Pelo menos três. Monte a lista longa no SAP Partner Finder e nos níveis de competência da SAP e depois leve para a lista final os parceiros com referências relevantes.

Quanto tempo leva a seleção de um parceiro SAP?

Cerca de 12 semanas do início ao fim, da lista longa ao contrato. A RFP em si é só uma parte disso. As apresentações orais, as ligações para referências e a transformação da proposta vencedora em declaração de trabalho tomam a maior parte do tempo.

Uma RFP SAP deve pedir preço fixo ou tempo e materiais?

Recomendo tempo e materiais com o esforço quantificado. Peça a cada parceiro o esforço estimado por fase e por função e escreva-o no contrato, para que você possa acompanhar o esforço real em relação a ele. Um único preço total sem esforço por trás não pode ser comparado nem acompanhado.

Quais são os sinais de alerta em uma proposta de parceiro SAP?

Respostas genéricas que poderiam valer para qualquer empresa, uma seção de equipe com funções mas sem pessoas nomeadas, um plano com as mesmas durações que você viu em outras propostas e uma arquitetura que o parceiro não consegue explicar nas apresentações orais. Um parceiro que não deixa você ligar para as referências dele é outro sinal de alerta.