Comment changer d'intégrateur SAP en cours de projet

Pour changer d'intégrateur SAP en cours de projet, confirmez d'abord que le partenaire est bien le problème, puis sécurisez chaque document, chaque élément de conception, chaque partie du code et chaque accès aux systèmes avant de le lui annoncer. Ensuite seulement, sélectionnez le remplaçant et menez une passation planifiée avec une période de chevauchement.

En bref : changez quand le partenaire ne peut pas vous fournir des personnes de qualité et ne parvient pas à y remédier. Ne changez pas pour fuir des problèmes qui se trouvent de votre côté, car un nouveau partenaire en hérite.

Cet article fait partie de mon guide sur comment choisir un intégrateur SAP. Ce guide couvre le choix d'un partenaire au départ. Celui-ci couvre ce qu'il faut faire quand le partenaire choisi ne donne pas satisfaction.

J'ai changé de partenaire en cours de programme. Le déclencheur était la qualité des ressources : le partenaire ne parvenait pas à fournir des personnes de qualité quand le programme en avait besoin.

C'est le signe que je placerais en premier. Un programme peut se remettre d'une mauvaise phase, d'une date manquée ou d'une conception faible. Il a du mal à se remettre d'un partenaire incapable de mettre des personnes compétentes sur le travail.

Voici les signaux qui justifient d'agir, à peu près dans l'ordre où je les pèserais :

1. Faible qualité des personnes sur site. Les consultants qui font le travail ne sont pas ceux qu'on vous a présentés, ou ils ne savent pas répondre à des questions de base sur leur propre domaine.
2. Échecs répétés pour remplacer les personnes. Quelqu'un part et le remplaçant met des semaines à arriver, ou arrive avec moins d'expérience.
3. Personne ne sait expliquer l'architecture et le plan. Demandez au responsable du partenaire de vous présenter la conception cible et le chemin jusqu'au go-live. S'il n'y parvient pas, personne ne pilote la livraison.
4. Des livrables qui ne résistent pas à la revue. Conceptions, scripts de test et documents de réalisation minces, copiés d'un autre client ou absents.
5. Des réponses génériques à des problèmes précis. Le même signal d'alerte qu'à la sélection : des réponses qui pourraient s'appliquer à n'importe quelle entreprise.

Une phase en retard, un dépassement en phase Explore ou un comité de pilotage tendu ne sont pas, à eux seuls, des raisons de changer.

Avant de remplacer qui que ce soit, déterminez si le partenaire est vraiment la cause. Mon guide sur le redressement d'un programme SAP présente les trois vérifications que je fais en premier : l'état du programme, la conception et ce qui est réellement déployé dans le système.

Ce diagnostic montre souvent que le problème est partagé. Les budgets sont touchés en phase Explore à mesure que la liste WRICEF (workflows, états, interfaces, conversions, améliorations et formulaires) s'allonge. Si vous avez laissé le partenaire maîtriser le périmètre, ou si vos utilisateurs clés n'ont jamais été libérés pour le programme, un nouveau partenaire tombe dans le même trou.

Posez-vous donc honnêtement deux questions :

1. Une équipe solide chez ce partenaire réglerait-elle le problème ? Si oui, et si le partenaire peut fournir cette équipe rapidement, un changement de personnes peut suffire.
2. Un autre partenaire rencontrerait-il les mêmes problèmes ? Si oui, réglez d'abord le périmètre, les décisions et la gouvernance de votre côté.

Si la réponse à la première question est non, parce que le partenaire ne trouve pas les personnes, vous avez votre réponse. La disponibilité de personnes de qualité ne se règle pas par un avenant au contrat.

C'est la partie que la plupart des clients ratent. Ils annoncent la décision, et leur pouvoir de négociation disparaît avec elle.

Le partenaire sortant détient le savoir dont vous avez besoin pour le remplacer. Tant que ce savoir n'est pas entre vos mains, gardez la décision au sein d'un petit groupe : le sponsor, le directeur financier, le directeur de programme et votre responsable juridique ou achats.

Commencez par votre contrat actuel. Lisez la clause de résiliation, le préavis, la propriété des livrables et tout ce qui concerne le transfert de connaissances ou l'assistance à la sortie. Si votre énoncé des travaux ne dit rien de la sortie, mon article sur ce que doit contenir un énoncé des travaux SAP détaille ce qu'il faut inscrire dans le suivant.

Voici ce qu'il faut sécuriser, et où cela se trouve en général :

Ce qu'il faut sécuriser	Pourquoi c'est important	Où cela doit se trouver	Comment le protéger
Conceptions et décisions signées	Le nouveau partenaire s'appuie dessus au lieu de tout recommencer	Votre référentiel documentaire ou SAP Cloud ALM	Copiez dès maintenant les dernières versions approuvées, avec les preuves de validation
Liste WRICEF et spécifications	La référence de périmètre et le backlog de réalisation	SAP Cloud ALM ou votre propre référentiel	Exportez la liste avec le statut de chaque objet
Code spécifique et paramétrage	Le vrai travail accompli jusqu'ici	Vos systèmes de développement et de test	Confirmez que tout est dans vos systèmes, pas sur les machines du partenaire
Scripts et résultats de tests	La preuve de ce qui fonctionne réellement	Votre outil de test ou SAP Cloud ALM	Exportez les scripts, les résultats et les anomalies ouvertes
Travaux de migration des données	Mappings, règles de nettoyage, programmes de chargement	Lecteurs partagés et vos systèmes	Récupérez les documents de mapping et les programmes de chargement auprès de l'équipe données
Accès aux systèmes et au support SAP	La maîtrise de votre paysage et de votre compte de support SAP	Vos systèmes et SAP for Me	Listez chaque utilisateur du partenaire, prêt à être supprimé le jour J
Points ouverts et risques	Ce que l'équipe suivante doit reprendre en premier	Registre RAID et rapports d'avancement	Faites une copie datée du registre RAID

Garder le contenu du projet dans vos propres outils

La protection la plus nette est structurelle. Gardez les documents, les exigences et les preuves de test du programme dans des outils qui vous appartiennent, dès le premier jour de tout programme.

SAP Cloud ALM aide ici. Les clients sous SAP Enterprise Support, ou sous RISE with SAP, peuvent demander leur propre tenant sans frais supplémentaires, un par numéro client, selon la FAQ SAP Cloud ALM. Si la documentation du projet se trouve dans votre tenant, elle reste chez vous quand un partenaire part.

Planifier le changement d'accès pour le jour de l'annonce

Les consultants du partenaire détiennent souvent des S-user IDs sur votre compte de support SAP, en plus de comptes utilisateurs dans vos systèmes. Ce sont vos propres administrateurs qui gèrent les S-user IDs dans SAP for Me.

L'aide de SAP sur la gestion des utilisateurs indique que les administrateurs côté client sont responsables de la suppression des IDs des utilisateurs partis. Elle précise aussi que les IDs ayant des fonctions particulières, comme destinataire des logiciels ou contact technique, ne peuvent pas être supprimés tant que SAP n'a pas transféré cette fonction à quelqu'un d'autre. Identifiez dès maintenant les utilisateurs du partenaire qui détiennent ces fonctions, et transférez-les d'abord à vos propres équipes.

Une fois les éléments sécurisés et le remplaçant choisi, prévenez le partenaire sortant. Faites-le par écrit, conformément au contrat, et convenez du plan de sortie lors de la même réunion.

Une passation se déroule au mieux dans cet ordre :

Changer de partenaire SAP en cours de programme

1. 01

   Sécuriser

   Documents, conception, code, accès et registre RAID entre vos mains avant que quiconque soit prévenu.

2. 02

   Sélectionner

   Références sur des projets comparables et la vraie équipe en soutenance, avec un effort chiffré.

3. 03

   Chevauchement

   Les responsables sortants et entrants travaillent côte à côte sur un transfert de connaissances structuré.

4. 04

   Revalider

   Le nouveau partenaire revoit la conception, la réalisation et les tests au regard de ce qui est déployé.

5. 05

   Recaler la référence

   Un nouveau plan unique fondé sur les faits, validé avant le début de la phase suivante.

Sélectionner correctement le remplaçant

La tentation est d'aller vite, parce que le programme brûle de l'argent pendant que vous choisissez. Une sélection complète prend environ 12 semaines d'après mon expérience, avec au moins trois partenaires sur la liste restreinte. Un remplacement sous pression peut aller plus vite, mais ne sautez pas les étapes qui vous protègent.

Quand je choisis un partenaire pour un client, ce sont les références clients qui pèsent le plus. Lors des appels de références, j'interroge sur l'expérience du partenaire sur des projets comparables à celui de l'acheteur. En cours de programme, cela veut dire interroger les références sur la reprise d'un travail commencé par une autre entreprise.

Deux choses me font renoncer à une offre : la faible qualité des ressources proposées, et un partenaire incapable d'expliquer l'architecture et le plan. Après un changement provoqué par la qualité des ressources, appliquez ces deux tests plus durement, pas plus mollement.

Demandez aux candidats les badges de certification des personnes qu'ils proposent. SAP délivre ses badges de certification sur Credly, comme l'explique sa page d'aide sur les badges numériques. Un badge confirme la réussite d'un examen, vérifiez donc aussi l'expérience par les références.

Mes guides pour rédiger un appel d'offres SAP et sur les partenaires d'intégration SAP par catégorie couvrent le reste de la sélection.

Contractualiser autrement avec le nouveau partenaire

Le modèle commercial que je recommande est la régie (time and materials), avec un effort chiffré. Le contrat indique l'effort estimé par phase et par rôle, pour que vous puissiez suivre chaque mois l'effort réel par rapport à cette estimation.

L'énoncé des travaux (SOW) a aussi besoin d'hypothèses et d'exclusions détaillées. Les clients les omettent souvent, et dans une reprise elles comptent encore plus, car le nouveau partenaire voudra exclure les problèmes dont il hérite.

Nommez aussi les personnes clés dans le contrat. Mes notes sur la négociation d'un contrat ERP expliquent la clause de ressources nommées et pourquoi elle empêche les profils seniors de disparaître après la signature.

Chevauchement, puis revalidation

Prévoyez une période pendant laquelle les responsables sortants et entrants travaillent ensemble. L'équipe sortante passe en revue chaque domaine de conception, chaque anomalie ouverte et chaque objet à moitié réalisé, pendant que l'équipe entrante pose ses questions.

Laissez ensuite le nouveau partenaire revalider l'existant. Attendez-vous à ce qu'il trouve des manques, et à ce qu'une partie de ces constats serve de position de négociation pour obtenir plus d'effort. C'est là qu'un regard indépendant sur les livrables du partenaire sortant vaut la peine.

Situez la reprise dans la phase SAP Activate où vous êtes. SAP décrit six phases : Discover, Prepare, Explore, Realize, Deploy et Run (SAP Activate).

Un changement pendant Explore coûte surtout des reprises de conception. Un changement pendant Realize coûte aussi des reprises de réalisation et de tests, car le code doit être compris avant de pouvoir être terminé.

Aucun changement n'est gratuit. Je ne donnerai pas de chiffre, car cela dépend de la phase, de la qualité de ce qui a été livré et du degré de coopération du partenaire sortant.

Voici les coûts à budgéter :

1. Chevauchement. Vous payez deux équipes pendant la passation.
2. Revalidation et reprises. Le nouveau partenaire vérifie la conception, le paramétrage et le code, et une partie est refaite.
3. Sortie du contrat. Préavis, conditions de résiliation et tout paiement pour les travaux en cours, selon ce que prévoit votre contrat.
4. Effort de sélection. Le temps de votre propre équipe sur l'appel d'offres, les soutenances et les appels de références.
5. Le temps de vos équipes. Les utilisateurs clés refont des ateliers et des tests qu'ils croyaient terminés.
6. Retard. Chaque semaine de retard prolonge le fonctionnement des anciens systèmes, et de votre équipe interne.

Mettez-les en balance avec le coût de rester. Un partenaire incapable de staffer le programme ne devient pas moins cher à mesure que le programme se complique, et Realize, les tests et la bascule sont plus difficiles que ce qui a précédé.

Je conseille aux clients de faire intervenir un consultant indépendant à trois moments : la contractualisation, la conception, et l'évaluation des documents et livrables du partenaire. Un changement de partenaire touche les trois à la fois.

Un examinateur indépendant peut vous dire ce que valent réellement les livrables du partenaire sortant avant que le nouveau partenaire chiffre les reprises. Il peut aussi vérifier le contrat du partenaire entrant et sa lecture de la conception. Mon article partenaire SAP ou consultant indépendant précise qui fait quoi.

Cette semaine, déterminez où se trouvent réellement vos conceptions signées, votre liste WRICEF, vos preuves de test et votre code spécifique, et qui contrôle l'accès à chacun. Faites-le que vous prévoyiez de changer ou non. Si une partie ne se trouve que chez votre partenaire, mettez-en une copie dans des systèmes qui vous appartiennent.

Si vous envisagez un changement de partenaire et souhaitez un regard indépendant sur les livrables ou le contrat, vous pouvez m'en parler ici.

Peut-on changer d'intégrateur SAP en plein projet ?

Oui. Vérifiez d'abord les clauses de votre contrat sur la résiliation, le préavis et la propriété des livrables. Sécurisez la conception, le code, les preuves de test et les accès aux systèmes avant d'annoncer la décision, puis menez une passation planifiée avec une période de chevauchement.

Quand faut-il changer d'intégrateur SAP ?

Changez quand le partenaire ne peut pas fournir des personnes de qualité et ne parvient pas à y remédier, ou quand ses responsables ne savent pas expliquer l'architecture et le plan. Ne changez pas seulement parce qu'une phase a pris du retard. Diagnostiquez d'abord, car les problèmes de maîtrise du périmètre ou de vos propres décisions vous suivront chez un nouveau partenaire.

Que faut-il récupérer auprès de son partenaire SAP avant de résilier le contrat ?

Les conceptions signées et les relevés de décision, et la liste WRICEF avec le statut de chaque objet. Le code spécifique et le paramétrage dans vos propres systèmes, les scripts et résultats de tests, les mappings de migration des données et le registre RAID. Listez aussi chaque utilisateur du partenaire dans vos systèmes et sur votre compte de support SAP, pour pouvoir supprimer les accès le jour J.

Combien coûte un changement de partenaire SAP en cours de projet ?

Il n'existe pas de chiffre standard. Budgétez le chevauchement entre les deux équipes, la revalidation et les reprises, les conditions de sortie du contrat, votre propre effort de sélection et le retard. Plus la phase est avancée, plus il y a de reprises, car le code et les tests doivent être compris avant de pouvoir être terminés.

Combien de temps faut-il pour remplacer un intégrateur SAP ?

Une sélection complète de partenaire prend environ 12 semaines d'après mon expérience, avec au moins trois partenaires sur la liste restreinte. Un remplacement sous pression peut aller plus vite, mais conservez les appels de références et les soutenances avec la vraie équipe.

À qui appartiennent les documents et le code d'une mise en œuvre SAP ?

C'est votre contrat qui le décide, vérifiez donc la clause de propriété des livrables. En pratique, protégez-vous en gardant les documents dans votre propre référentiel ou votre tenant SAP Cloud ALM, et le code et le paramétrage dans vos propres systèmes SAP plutôt que sur les serveurs du partenaire.