Como trocar o seu parceiro de implementação SAP no meio do projeto

Para trocar o seu parceiro de implementação SAP no meio do projeto, primeiro confirme que o parceiro é o problema e depois garanta cada documento, desenho, trecho de código e acesso aos sistemas antes de avisá-lo. Só então selecione o substituto e conduza uma passagem de bastão planejada, com sobreposição.

Resposta curta: troque quando o parceiro não consegue lhe dar pessoas de qualidade e não consegue resolver isso. Não troque para fugir de problemas que estão do seu lado, porque um novo parceiro os herda.

Este artigo faz parte do meu guia sobre como escolher um parceiro de implementação SAP. Aquele guia trata da escolha de um parceiro no início. Este trata do que fazer quando o parceiro escolhido não está dando certo.

Já troquei de parceiro no meio de um programa. O gatilho foi a qualidade dos recursos: o parceiro não conseguia fornecer pessoas de qualidade quando o programa precisava delas.

Esse é o sinal que eu colocaria em primeiro lugar. Um programa consegue se recuperar de uma fase ruim, de uma data perdida ou de um desenho fraco. Tem dificuldade para se recuperar de um parceiro que não consegue colocar pessoas capazes no trabalho.

Estes são os sinais que justificam agir, mais ou menos na ordem em que eu os pesaria:

1. Baixa qualidade das pessoas no projeto. Os consultores que fazem o trabalho não são as pessoas que lhe apresentaram, ou não conseguem responder a perguntas básicas sobre a própria área.
2. Falhas repetidas na reposição de pessoas. Alguém sai e o substituto leva semanas para chegar, ou chega com menos experiência.
3. Ninguém consegue explicar a arquitetura e o plano. Peça ao líder do parceiro que mostre o desenho-alvo e o caminho até o go-live. Se ele não conseguir, ninguém está conduzindo a entrega.
4. Entregáveis que não resistem a uma revisão. Desenhos, roteiros de teste e documentos de construção rasos, copiados de outro cliente ou ausentes.
5. Respostas genéricas para problemas específicos. O mesmo sinal de alerta da seleção: respostas que poderiam valer para qualquer empresa.

Uma fase atrasada, um estouro na fase Explore ou um comitê de direção tenso não são, por si sós, motivos para trocar.

Antes de substituir alguém, descubra se o parceiro é mesmo a causa. O meu guia sobre recuperação de programas SAP apresenta as três verificações que faço primeiro: o status do programa, o desenho e o que de fato está implantado no sistema.

Esse diagnóstico muitas vezes mostra que o problema é compartilhado. Os orçamentos estouram na fase Explore conforme a lista WRICEF (workflows, relatórios, interfaces, conversões, ampliações e formulários) cresce. Se você deixou o parceiro controlar o escopo, ou se os seus usuários-chave nunca foram liberados para o programa, um novo parceiro cai no mesmo buraco.

Por isso, faça duas perguntas com honestidade:

1. Uma equipe forte deste parceiro resolveria? Se sim, e se o parceiro conseguir fornecer essa equipe rapidamente, uma troca de pessoas pode bastar.
2. Um parceiro diferente enfrentaria os mesmos problemas? Se sim, resolva primeiro o escopo, as decisões e a governança do seu lado.

Se a resposta à primeira pergunta for não, porque o parceiro não consegue encontrar as pessoas, você tem a sua resposta. A disponibilidade de pessoas de qualidade não é algo que um aditivo contratual resolva.

Esta é a parte que a maioria dos clientes erra. Eles anunciam a decisão, e o poder de negociação desaparece junto.

O parceiro que sai detém o conhecimento de que você precisa para substituí-lo. Até esse conhecimento estar nas suas mãos, mantenha a decisão dentro de um grupo pequeno: o patrocinador, o CFO, o diretor do programa e o seu responsável jurídico ou de compras.

Comece pelo contrato atual. Leia a cláusula de rescisão, o prazo de aviso prévio, a titularidade dos entregáveis e qualquer disposição sobre transferência de conhecimento ou assistência na saída. Se a sua declaração de trabalho não diz nada sobre a saída, o meu artigo sobre o que uma declaração de trabalho SAP precisa conter mostra o que escrever na próxima.

Isto é o que garantir, e onde costuma estar:

O que garantir	Por que importa	Onde deve estar	Como proteger
Desenhos e decisões assinados	O novo parceiro constrói sobre eles em vez de recomeçar	O seu repositório de documentos ou o SAP Cloud ALM	Copie agora as últimas versões aprovadas, com os registros de aprovação
Lista WRICEF e especificações	A linha de base do escopo e o backlog de construção	SAP Cloud ALM ou o seu próprio repositório	Exporte a lista com o status de cada objeto
Código customizado e configuração	O trabalho real feito até agora	Os seus sistemas de desenvolvimento e de teste	Confirme que tudo está nos seus sistemas, não em máquinas do parceiro
Roteiros e resultados de teste	Evidência do que de fato funciona	A sua ferramenta de testes ou o SAP Cloud ALM	Exporte roteiros, resultados e defeitos em aberto
Trabalho de migração de dados	Mapeamentos, regras de saneamento, programas de carga	Drives compartilhados e os seus sistemas	Reúna com a equipe de dados os documentos de mapeamento e os programas de carga
Acesso aos sistemas e ao suporte SAP	Controle do seu ambiente e da sua conta de suporte SAP	Os seus sistemas e o SAP for Me	Liste cada usuário do parceiro, pronto para ser removido no dia
Questões e riscos em aberto	O que a próxima equipe precisa assumir primeiro	Registro RAID e relatórios de status	Faça uma cópia datada do registro RAID

Mantenha o conteúdo do projeto nas suas próprias ferramentas

A proteção mais limpa é estrutural. Mantenha os documentos, os requisitos e as evidências de teste do programa em ferramentas que sejam suas, desde o primeiro dia de qualquer programa.

O SAP Cloud ALM ajuda aqui. Clientes com SAP Enterprise Support, ou com RISE with SAP, podem solicitar o próprio tenant sem custo adicional, um por número de cliente, segundo o FAQ do Cloud ALM da SAP. Se a documentação do projeto estiver no seu tenant, ela fica com você quando um parceiro sai.

Planeje a mudança de acessos para o dia do anúncio

Os consultores do parceiro muitas vezes têm S-user IDs na sua conta de suporte SAP, além de contas de usuário nos seus sistemas. Os seus próprios administradores controlam os S-user IDs no SAP for Me.

A ajuda de gestão de usuários da SAP diz que os administradores do cliente são responsáveis por excluir os IDs dos usuários que saíram. Também diz que IDs com funções especiais, como destinatário de software ou contato técnico, não podem ser excluídos até que a SAP transfira essa função para outra pessoa. Descubra agora quais usuários do parceiro têm essas funções e passe-as primeiro para as suas próprias pessoas.

Depois que o material estiver garantido e o substituto escolhido, avise o parceiro que sai. Faça isso por escrito, de acordo com o contrato, e acorde o plano de saída na mesma reunião.

Uma passagem de bastão funciona melhor nesta ordem:

Trocar de parceiro SAP no meio do programa

1. 01

   Garantir

   Documentos, desenhos, código, acessos e o registro RAID nas suas mãos antes que alguém seja avisado.

2. 02

   Selecionar

   Referências em projetos semelhantes e a equipe real nas apresentações orais, com o esforço quantificado.

3. 03

   Sobrepor

   Os líderes que saem e os que entram trabalham lado a lado em uma transferência de conhecimento estruturada.

4. 04

   Revalidar

   O novo parceiro revisa desenhos, construção e testes em relação ao que está implantado.

5. 05

   Replanejar

   Um único plano novo a partir das evidências, aprovado antes do início da próxima fase.

Selecione o substituto direito

A tentação é correr, porque o programa está queimando dinheiro enquanto você escolhe. Uma seleção completa leva cerca de 12 semanas na minha experiência, com pelo menos três parceiros na lista final. Uma substituição sob pressão pode andar mais rápido, mas não pule as etapas que protegem você.

Quando escolho um parceiro para um cliente, o que mais pesa são as referências de clientes. Nas ligações para referências, pergunto sobre a experiência do parceiro em projetos como o do comprador. No meio de um programa, isso significa perguntar às referências sobre a experiência de assumir um trabalho iniciado por outra empresa.

Duas coisas me fazem descartar uma proposta: a baixa qualidade dos recursos propostos e um parceiro que não consegue explicar a arquitetura e o plano. Depois de uma troca causada pela qualidade dos recursos, aplique os dois testes com mais rigor, não com menos.

Peça aos candidatos os selos de certificação das pessoas que propõem. A SAP emite os seus selos de certificação na Credly, como explica a sua página de ajuda sobre selos digitais. Um selo confirma que uma prova foi aprovada, então verifique também a experiência por meio das referências.

Os meus guias sobre como escrever uma RFP de implementação SAP e sobre os parceiros de implementação SAP por nível tratam do restante da seleção.

Contrate o novo parceiro de outra forma

O modelo comercial que recomendo é tempo e materiais, com o esforço quantificado. O contrato informa o esforço estimado por fase e por função, para que você possa acompanhar todo mês o esforço real em relação a ele.

A declaração de trabalho também precisa de premissas e exclusões detalhadas. Os clientes costumam deixá-las de fora, e em uma substituição elas importam ainda mais, porque o novo parceiro vai querer excluir os problemas que herdou.

Nomeie também as pessoas-chave no contrato. As minhas notas sobre negociação de contratos de ERP explicam a cláusula de recursos nomeados e por que ela impede que os profissionais seniores desapareçam depois da assinatura.

Sobreponha e depois revalide

Planeje um período em que os líderes que saem e os que entram trabalhem juntos. A equipe que sai percorre cada área de desenho, cada defeito em aberto e cada objeto construído pela metade, com a equipe que entra fazendo perguntas.

Depois, deixe o novo parceiro revalidar o que existe. Espere que ele encontre lacunas, e espere que algumas dessas constatações sejam uma posição de negociação para mais esforço. É aqui que vale a pena ter uma visão independente dos entregáveis do parceiro que sai.

Relacione a substituição com a fase do SAP Activate em que você está. A SAP descreve seis fases: Discover, Prepare, Explore, Realize, Deploy e Run (SAP Activate).

Uma troca durante a fase Explore custa principalmente retrabalho de desenho. Uma troca durante a fase Realize custa também retrabalho de construção e de testes, porque o código precisa ser entendido antes de poder ser terminado.

Não existe troca gratuita. Não vou dar um número, porque depende da fase, da qualidade do que foi entregue e de quanto o parceiro que sai coopera.

Estes são os custos para os quais você deve reservar orçamento:

1. Sobreposição. Você paga duas equipes durante a passagem de bastão.
2. Revalidação e retrabalho. O novo parceiro verifica desenhos, configuração e código, e parte disso é refeita.
3. Saída do contrato. Prazos de aviso prévio, condições de rescisão e qualquer pagamento por trabalho em andamento, conforme o seu contrato estabelece.
4. Esforço de seleção. O tempo da sua própria equipe com a RFP, as apresentações orais e as ligações para referências.
5. O tempo das suas pessoas. Os usuários-chave repetem workshops e testes que achavam concluídos.
6. Atraso. Cada semana de atraso mantém os sistemas antigos, e a sua equipe interna, funcionando por mais tempo.

Compare esses custos com o custo de ficar. Um parceiro que não consegue compor a equipe do programa não fica mais barato à medida que o programa fica mais difícil, e a fase Realize, os testes e o cutover são mais difíceis do que o que veio antes.

Aconselho os clientes a trazer um consultor independente em três momentos: a etapa de contratação, o desenho e a avaliação dos documentos e entregáveis do parceiro. Uma troca de parceiro envolve os três ao mesmo tempo.

Um revisor independente pode dizer quanto de fato valem os entregáveis do parceiro que sai antes que o novo parceiro precifique o retrabalho. Ele também pode verificar o contrato do parceiro que entra e a visão dele sobre o desenho. O meu artigo sobre parceiro SAP ou consultor independente mostra quem faz o quê.

Nesta semana, descubra onde estão de fato os seus desenhos assinados, a lista WRICEF, as evidências de teste e o código customizado, e quem controla o acesso a cada um. Faça isso planejando ou não uma troca. Se alguma parte estiver só com o seu parceiro, mova uma cópia para sistemas que sejam seus.

Se você está avaliando uma troca de parceiro e quer uma visão independente dos entregáveis ou do contrato, pode falar comigo aqui.

É possível trocar de parceiro de implementação SAP no meio de um projeto?

Sim. Primeiro verifique no contrato as condições de rescisão, aviso prévio e titularidade dos entregáveis. Garanta os desenhos, o código, as evidências de teste e o acesso aos sistemas antes de anunciar a decisão e depois conduza uma passagem de bastão planejada, com um período de sobreposição.

Quando trocar de parceiro de implementação SAP?

Troque quando o parceiro não consegue fornecer pessoas de qualidade e não consegue resolver isso, ou quando os líderes dele não conseguem explicar a arquitetura e o plano. Não troque só porque uma fase atrasou. Diagnostique primeiro, porque problemas de controle do escopo ou das suas próprias decisões vão acompanhar você até um novo parceiro.

O que obter do parceiro SAP antes de rescindir o contrato?

Desenhos assinados e registros de decisão, e a lista WRICEF com o status de cada objeto. Código customizado e configuração nos seus próprios sistemas, roteiros e resultados de teste, mapeamentos da migração de dados e o registro RAID. Liste também cada usuário do parceiro nos seus sistemas e na sua conta de suporte SAP, para que os acessos possam ser removidos no dia.

Quanto custa trocar de parceiro SAP no meio do projeto?

Não existe um valor padrão. Reserve orçamento para a sobreposição entre as duas equipes, a revalidação e o retrabalho, as condições de saída do contrato, o seu próprio esforço de seleção e o atraso. Quanto mais avançada a fase, mais retrabalho existe, porque código e testes precisam ser entendidos antes de poderem ser terminados.

Quanto tempo leva para substituir um parceiro de implementação SAP?

Uma seleção completa de parceiro leva cerca de 12 semanas na minha experiência, com pelo menos três parceiros na lista final. Uma substituição sob pressão pode andar mais rápido, mas mantenha as ligações para referências e as apresentações orais com a equipe real.

A quem pertencem os documentos e o código de uma implementação SAP?

O seu contrato define isso, então verifique a cláusula de titularidade dos entregáveis. Na prática, proteja-se mantendo os documentos no seu próprio repositório ou tenant do SAP Cloud ALM, e o código e a configuração nos seus próprios sistemas SAP, e não em servidores do parceiro.