Énoncé des travaux SAP (SOW) : ce qu'il doit contenir

Un énoncé des travaux SAP (statement of work, SOW) est le document contractuel qui dit ce que le partenaire livrera, avec quel effort, par qui et comment cela peut changer. Il doit couvrir le périmètre, des hypothèses et exclusions détaillées, l'effort par phase et par rôle, les livrables avec leurs critères de réception, les ressources nommées et la gestion des modifications.

La plupart des SOW couvrent assez bien le périmètre. Ce que les clients omettent souvent, ce sont les hypothèses et exclusions détaillées, et c'est la section qui décide de ce que vous paierez au final.

Cet article fait partie de mon guide sur comment choisir un intégrateur SAP. Le SOW est la dernière étape de ce processus, après l'appel d'offres SAP et les soutenances. Pour un exemple concret de revue d'un SOW avant signature, lisez mon étude de cas sur la négociation d'un contrat ERP.

Un bon SOW SAP se lit comme le mode d'emploi du programme. N'importe qui de votre côté doit pouvoir l'ouvrir et répondre à trois questions : qu'obtenons-nous, de quoi cela dépend-il, et que se passe-t-il quand quelque chose change.

Voici les sections nécessaires, et ce qui tourne mal quand l'une manque :

Section	Ce qu'elle doit dire	Ce qui se passe si elle est maigre
Périmètre	Processus, modules, sociétés, sites, pays et utilisateurs inclus	Chaque atelier rouvre la question de ce qui était inclus
Hypothèses	Les conditions dont dépend le prix, chacune avec une conséquence si elle se révèle fausse	Le partenaire émet des demandes de modification que vous ne pouvez pas contester
Exclusions	Ce que le partenaire ne fera pas, et qui le fait à sa place	Le travail tombe entre vous et le partenaire, et personne ne s'en charge
Approche et phases	La méthode, le plan par phase et les quality gates	Aucun point convenu auquel une phase est terminée
Effort	L'effort estimé par phase et par rôle	Vous ne pouvez pas savoir si le rythme de consommation est conforme au plan
Livrables et réception	Documents et produits nommés, critères de réception, délai de validation	Des factures sont payées pour un travail partiel
Ressources	Personnes clés nommées, rôles, taux d'affectation et règles de remplacement	L'équipe rencontrée en soutenance n'est pas celle qui est sur site
Responsabilités du client	Ce que vos équipes doivent fournir, et quand	Les retards causés de votre côté deviennent des demandes de modification du partenaire
Gestion des modifications	Comment une modification est soumise, évaluée, chiffrée et approuvée	Les demandes de modification deviennent une seconde source de revenus
Gouvernance	Comité de pilotage, reporting, escalade	Les problèmes apparaissent tard, quand ils coûtent cher

Rédigez vous-même le périmètre avant de demander des prix, pour que les partenaires chiffrent votre périmètre plutôt que le leur.

C'est la section que les clients omettent souvent. Sans elle, le prix repose sur des conditions que personne de votre côté n'a lues ni acceptées.

Une hypothèse est une condition sur laquelle le partenaire a construit son prix. Une exclusion est un travail que le partenaire n'a pas chiffré du tout. Les deux doivent être assez précises pour qu'un tiers puisse vérifier si elles ont tenu.

Les types d'hypothèses à écrire

Chaque hypothèse a besoin d'une conséquence. « Si cette hypothèse se révèle fausse, la modification passe par la gestion des modifications avec une analyse d'impact » transforme une hypothèse décorative en contrôle.

Voici les catégories qu'un SOW SAP doit couvrir :

1. Périmètre organisationnel. Le nombre de sociétés, de sites, d'organisations commerciales, de pays et d'entités juridiques que couvre le prix.
2. Périmètre des processus. Les processus métier inclus, nommés, et les processus standard SAP que le partenaire s'attend à vous voir adopter.
3. Volume WRICEF. Le nombre de workflows, états, interfaces, conversions, améliorations et formulaires, par niveau de complexité. Les budgets sont touchés en phase Explore à mesure que cette liste s'allonge, le décompte de référence a donc sa place dans le contrat.
4. Données. Les objets de données à migrer, le volume d'historique, le nombre de chargements à blanc, et qui nettoie les données.
5. Intégrations. Chaque interface nommée, avec le système en face et qui modifie ce système.
6. Tests. Le nombre de cycles de tests, qui rédige les scripts, qui les exécute et qui corrige les anomalies.
7. Disponibilité du client. Lesquelles de vos personnes sont nécessaires, pour quelle part de leur temps, et à quelle vitesse les décisions doivent être prises.
8. Environnements et licences. Qui fournit les systèmes, les outils et les accès, et pour quand.
9. Lieu et langue. Où travaille l'équipe, la répartition onshore et offshore, les déplacements, et les langues des documents et de la formation.
10. Formation et hypercare. Le modèle de formation, le nombre de formateurs formés, ainsi que la durée et les critères de sortie de l'hypercare.

Le décompte WRICEF de référence est ce qui compte le plus pour le budget. Les supports de formation de SAP décrivent la phase Explore comme une analyse fit-to-standard, où les exigences d'écart approuvées sont ajoutées au backlog produit pour la phase Realize (SAP Learning). Chaque écart approuvé peut devenir un nouvel effort WRICEF, il vous faut donc le décompte de départ pour mesurer la croissance.

Les types d'exclusions à écrire

Les exclusions doivent nommer qui fait le travail à la place. « Exclu » sans responsable, c'est un trou qui attend d'être découvert pendant la bascule.

Voici les catégories habituelles :

1. Nettoyage et enrichissement des données dans les systèmes existants, souvent une tâche du client.
2. Modifications des systèmes tiers et existants de l'autre côté d'une interface.
3. Licences et abonnements logiciels, qui relèvent de votre contrat avec SAP, pas du SOW.
4. Infrastructure et hébergement, sauf si le partenaire les opère explicitement.
5. Formation des utilisateurs finaux, quand le partenaire ne forme que vos formateurs.
6. Conduite du changement au-delà de ce qui est listé.
7. Conception de la sécurité, des rôles et des autorisations, si une autre partie en est responsable.
8. Tests de performance, d'intrusion et de non-régression en dehors des cycles nommés.
9. Pays, entités ou localisations hors du périmètre organisationnel.
10. Support applicatif après l'hypercare, qui fait l'objet d'un contrat distinct.

Lisez les deux listes côte à côte avec votre directeur de programme. Tout ce qui n'apparaît dans aucune des deux est l'endroit d'où viendra une demande de modification.

Le modèle commercial que je recommande pour une mise en œuvre SAP est la régie (time and materials), avec un effort chiffré. Cela signifie que l'effort estimé par phase et par rôle est inscrit dans le contrat, pour que vous puissiez suivre chaque mois l'effort réel par rapport à cette estimation.

Le forfait paraît plus sûr à un conseil d'administration. En pratique, le prix n'est fixe que tant que chaque hypothèse tient, et un programme SAP met la plupart d'entre elles à l'épreuve d'ici la fin d'Explore. Mes notes sur le coût d'une mise en œuvre SAP indiquent quand une phase au forfait peut quand même avoir du sens.

Voici comment les deux modèles se comparent dans le SOW :

Point de comparaison	Forfait	Régie avec effort chiffré
Ce que le contrat fixe	Le prix, tant que les hypothèses tiennent	Les taux, et l'effort estimé par phase et par rôle
Où se situe le risque	Le partenaire l'intègre dans son prix sous forme de provision	Chez vous, mais visible chaque mois
Quand le périmètre bouge	Chaque modification devient une négociation	L'effort évolue, et vous le voyez par rapport à l'estimation
Ce que vous pouvez suivre	Les jalons et les demandes de modification	L'effort réel par rapport au plan, par phase et par rôle
Ce qui vous protège	Des hypothèses et exclusions serrées	Des hypothèses, des exclusions et un reporting d'effort serrés

L'effort chiffré fait passer la régie d'un chèque en blanc à un budget maîtrisé. Demandez l'estimation sous forme de tableau croisant phases et rôles, en jours-homme, et faites du reporting mensuel sur ce tableau une obligation contractuelle.

Ne laissez pas les taux se cacher dans l'effort. Vérifiez la répartition des rôles par rapport aux taux du marché avec mon guide sur la planification des ressources pour les projets SAP.

Un plan chargé en jours seniors au début et en jours juniors ensuite est courant. L'inverse appelle une explication.

Un livrable est un produit nommé avec une définition de ce qui est terminé. « Support à la conception » n'est pas un livrable. Un document de conception de solution signé pour le processus record to report, revu selon des critères convenus, en est un.

Lier la réception aux quality gates

SAP Activate se déroule en six phases : Discover, Prepare, Explore, Realize, Deploy et Run. SAP décrit des quality gates formels après chaque phase, qui vérifient que les livrables de la phase sont complets avant que le projet passe à la suite (SAP Learning).

Utilisez ces quality gates dans le SOW. Listez les livrables attendus à chaque quality gate, les critères de réception et le nombre de jours dont vous disposez pour la revue. Liez le paiement aux livrables acceptés, pas au calendrier.

Quelqu'un de votre côté doit être capable de juger ces documents. C'est l'un des trois moments où je recommande de faire intervenir un consultant indépendant : pendant la contractualisation, pour la conception, et pour évaluer les livrables du partenaire. Mon article partenaire SAP ou consultant indépendant explique comment les deux rôles travaillent ensemble.

Nommer les personnes, et les vérifier

La faible qualité des ressources proposées est l'une des deux choses qui me font renoncer à une offre. L'autre est un partenaire incapable d'expliquer l'architecture et le plan.

Le SOW doit nommer l'architecte solution, le directeur de programme et chaque responsable fonctionnel et technique. Inscrivez leur taux d'affectation, votre droit de rencontrer les remplaçants en entretien et votre approbation pour chaque remplacement. L'étude de cas sur la négociation d'un contrat ERP montre la clause de ressources nommées en pratique.

Vérifiez les certifications plutôt que de croire un CV sur parole. SAP délivre ses badges de certification via Credly, qui permet une vérification en temps réel (SAP Learning). Dans le cadre du processus stay certified de SAP, une certification expire si son titulaire manque l'évaluation obligatoire (SAP Learning).

Cette clause compte plus qu'il n'y paraît. J'ai changé de partenaire en cours de programme, et le déclencheur était que le partenaire ne parvenait pas à fournir des ressources de qualité. Mon guide pour changer d'intégrateur SAP en cours de projet détaille ce qu'il faut sécuriser avant d'en arriver là.

La gestion des modifications est l'endroit où un SOW maigre coûte cher. Si les hypothèses sont vagues, presque tout peut être présenté comme une modification.

Une section de gestion des modifications qui fonctionne comporte ces éléments :

1. Un déclencheur. Une modification n'existe que lorsqu'une hypothèse tombe, qu'une exclusion entre dans le périmètre ou que vous demandez quelque chose de nouveau.
2. Une analyse d'impact. Périmètre, effort par rôle, calendrier et coût, par écrit, avant le début du travail.
3. Une grille tarifaire. Les modifications sont chiffrées aux taux du contrat, sans majoration pour urgence sauf accord.
4. Un niveau d'approbation. Qui, de votre côté, peut approuver des modifications jusqu'à quel montant, avec le directeur financier au-delà d'un seuil défini.
5. Un registre. Chaque modification, approuvée ou rejetée, présentée au comité de pilotage avec le total cumulé.
6. Un lien avec la référence. Les nouveaux objets WRICEF sont mesurés par rapport au décompte inscrit dans les hypothèses.

Le partenaire soumettra des modifications légitimes. Les programmes SAP découvrent des choses que personne ne savait à la signature du contrat. L'objectif est que chaque modification soit visible, chiffrée et approuvée avant que quiconque dépense l'argent.

Sur les 21 programmes SAP que j'ai dirigés ou redressés, l'erreur la plus fréquente que je constate est de ne pas planifier correctement au départ. Le SOW est l'endroit où cette planification devient contraignante, et le temps passé dessus coûte peu à côté de demandes de modification contestées.

L'étape concrète suivante : prenez le SOW que vous avez sous les yeux et listez chaque hypothèse et chaque exclusion sur une page. En face de chacune, écrivez ce qui se passe si elle se révèle fausse et qui paie. Si vous ne pouvez pas remplir cette colonne, le SOW n'est pas prêt à être signé.

Si vous souhaitez une lecture indépendante d'un énoncé des travaux SAP avant signature, j'accompagne des clients sur ce point pendant la contractualisation. Vous pouvez me contacter ici.

Que doit contenir un énoncé des travaux SAP ?

Le périmètre, des hypothèses détaillées, les exclusions, l'approche et les phases, l'effort estimé par phase et par rôle, les livrables avec critères de réception, les ressources nommées, les responsabilités du client, la gestion des modifications et la gouvernance. La partie le plus souvent laissée maigre, ce sont les hypothèses et exclusions, et c'est la partie qui décide du coût final.

Quelle est la différence entre hypothèses et exclusions dans un SOW SAP ?

Une hypothèse est une condition sur laquelle le partenaire a construit son prix, comme le nombre de sociétés ou d'objets WRICEF. Une exclusion est un travail que le partenaire n'a pas chiffré du tout, comme le nettoyage des données existantes. Chaque hypothèse doit dire ce qui se passe si elle se révèle fausse, et chaque exclusion doit nommer qui fait le travail à la place.

Forfait ou régie : lequel est préférable pour une mise en œuvre SAP ?

Je recommande la régie avec un effort chiffré : l'effort estimé par phase et par rôle inscrit dans le contrat et suivi chaque mois. Un forfait ne tient que tant que chaque hypothèse tient, et un programme SAP met la plupart des hypothèses à l'épreuve pendant la phase Explore.

Comment définir les critères de réception des livrables SAP ?

Nommez chaque livrable, décrivez à quoi ressemble un livrable complet et fixez un délai de revue pour votre équipe. Liez-les aux quality gates de SAP Activate en fin de phase, et ne libérez le paiement que lorsque le livrable est accepté.

Le SOW SAP doit-il nommer les consultants ?

Oui, pour les rôles clés : architecte solution, directeur de programme et responsables fonctionnels et techniques. Ajoutez leur taux d'affectation, votre droit de rencontrer les remplaçants et votre approbation pour tout remplacement. Vérifiez les certifications via les badges SAP sur Credly plutôt que de vous fier au CV.

Qui doit rédiger l'énoncé des travaux SAP ?

Le partenaire en rédige le projet, mais le périmètre et les hypothèses doivent venir de vous. Rédigez votre périmètre avant de consulter le marché, et faites examiner les hypothèses, les exclusions et les livrables par quelqu'un d'indépendant du partenaire avant la signature.