Mise en œuvre SAP ou déploiement : différences et choix

Une mise en œuvre SAP construit le système là où il n'en existe pas. Un déploiement (rollout) prend un système SAP qui tourne déjà quelque part dans le groupe et l'étend à un nouveau pays, une nouvelle entité ou une nouvelle unité métier. La plupart des gens pensent qu'un déploiement n'est qu'une mise en œuvre en plus petit. Cette hypothèse provoque plus de reprises sur ces programmes que n'importe quelle décision technique.

J'ai laissé un jour un directeur financier croire qu'un déploiement SAP régional serait plug-and-play. J'avais expliqué les risques, mais je n'ai pas insisté. Nous utilisions un template global, et il pensait que chaque site s'alignerait sans trop d'efforts. Ça ne s'est pas passé comme ça. Une région exigeait un traitement fiscal supplémentaire. Une autre imposait des champs obligatoires sur les données des salariés en raison de lois locales. Ce qui ressemblait à un simple copier-coller a demandé une vraie personnalisation.

Le choix change donc la façon de doter l'équipe, de budgéter et de piloter le travail. Si vous vous trompez, le système peut quand même passer en production, mais pas comme vous l'aviez prévu.

Une mise en œuvre part de zéro. Vous définissez le périmètre, cartographiez les processus, configurez, migrez les données et construisez les intégrations. Elle s'applique quand une organisation n'a pas SAP, ou remplace purement et simplement un système historique.

Un déploiement réutilise une conception qui fonctionne déjà : processus, configuration, standards de données de base. Le travail, c'est l'écart entre ce template et ce dont le nouveau site a besoin. Fiscalité, reporting réglementaire, devises, langues, intégrations locales et les personnes qui vont l'utiliser.

1. 05Utilisateurs locauxFormation adaptée au processus local, dans la langue locale
2. 04Intégrations localesBanques, déclarations fiscales et systèmes logistiques du nouveau pays
3. 03Données localesDonnées clients, fournisseurs et articles alignées sur les standards globaux
4. 02Exigences localesFiscalité, reporting réglementaire et champs obligatoires. Des exigences uniquement, pas des préférences
5. 01Template globalProcessus, configuration et standards de données de base qui fonctionnent déjà

Voici comment les deux se comparent en pratique :

Domaine	Mise en œuvre SAP	Déploiement SAP
Point de départ	Pas de SAP, ou un système historique à remplacer	SAP déjà en production au siège ou dans une autre entité
Conception	Nouvelle conception, fit-to-standard	Template global avec écarts locaux maîtrisés
Durée typique	De 12 à 24 mois, davantage pour les grands groupes	De 6 à 12 mois par site
Risque principal	Des inconnues dans chaque chantier	Localisation et préparation locale
Données	Chargement complet depuis les systèmes historiques	Données locales alignées sur les standards globaux de données de base
Tests	Cycle complet : tests unitaires, d'intégration, UAT, de performance	Localisation, interfaces locales, UAT
Conduite du changement	Programme complet à partir de zéro	Supports existants adaptés aux équipes locales

Une mise en œuvre convient quand :

1. L'organisation n'a jamais utilisé SAP.
2. Le système actuel est défaillant et doit être remplacé dans son ensemble.
3. Une fusion, une acquisition ou un nouveau modèle opérationnel rend l'ancienne conception inadaptée.
4. Une solution sectorielle arrive pour la première fois, comme SAP for Utilities ou SAP for Public Sector.
5. Aucun template existant ne couvre le périmètre dont vous avez besoin.

Les mises en œuvre sont plus longues et coûtent plus cher au départ. Vous obtenez une conception qui correspond à votre activité et une équipe qui comprend chaque choix qui la sous-tend. Les entreprises qui bâclent les exigences finissent par dépenser de 30 à 50 % de plus pour corriger leurs erreurs. Je l'ai vu se produire encore et encore.

Un déploiement convient quand SAP fonctionne déjà bien quelque part dans le groupe, que les processus clés sont stables et que le template est assez souple pour accueillir des exigences locales sans casser. Si l'une de ces trois conditions est fragile, corrigez le template avant de le déployer où que ce soit.

Le volet technique se termine généralement dans les délais. Les retards viennent des personnes et d'hypothèses qui ne tiennent pas dans le nouveau pays.

Un template imposé aux équipes locales

Ce qui marchait bien pour l'Amérique du Nord peut ne pas suffire en Asie ou au Moyen-Orient. Les structures fiscales, les workflows d'approbation et les règles de saisie des données diffèrent. J'ai travaillé un jour avec une entreprise qui pensait que son template européen fonctionnerait au Moyen-Orient. Cela a causé des retards, des réécritures et beaucoup de tensions. Les processus métier étaient simplement trop différents.

La solution consiste à donner au nouveau site un responsable métier doté du pouvoir de décision. Quand les équipes du siège décident des processus pour des endroits qu'elles ne comprennent pas, elles produisent des conceptions qui échouent dès le premier contact avec les utilisateurs locaux.

La localisation découverte pendant les tests

Le traitement fiscal, les états réglementaires et les champs de données obligatoires doivent être confirmés avant le début de la conception. J'ai accompagné un jour un client dont le go-live a été retardé de plus d'un mois à cause d'une simple différence de configuration fiscale. Ce n'était pas une question de technologie. Personne n'avait validé les besoins locaux assez tôt.

Des données de base qui ne s'alignent pas

Les codes produit, les numéros de clients et les classifications de fournisseurs doivent respecter les standards globaux. Les écarts découverts après le go-live coûtent cher à corriger et cassent le reporting consolidé. Alignez les données locales sur le modèle global pendant la conception, pas pendant l'UAT.

Une formation qui explique le système global, pas le système local

Les déploiements ont tendance à réutiliser la formation de la mise en œuvre initiale. Ces supports expliquent comment le système fonctionne au siège. Ils n'expliquent pas les adaptations locales. Des utilisateurs qui ne comprennent pas pourquoi leur version diffère construiront des contournements.

Le cadre ci-dessus reste valable. Le modèle de déploiement du template modifie une partie de l'économie du projet et les règles d'extension.

Sur RISE with SAP (Private Edition), chaque nouveau pays ajoute des utilisateurs à un abonnement tarifé en équivalents utilisateur complet (FUE). Vous obtenez un coût prévisible et moins de travail d'infrastructure. Le coût continue aussi de courir après le go-live : comparez donc les options sur plusieurs années, pas seulement sur la première.

Sur GROW with SAP (Public Edition), vérifiez d'abord si SAP livre une version locale pour le pays. SAP recensait des versions locales pour 59 pays et régions en février 2024. Pour les autres pays, le programme de localisation en libre-service de SAP permet aux partenaires de construire une version locale client avec le Configuration Localization Tool, actuellement via une voie réservée aux premiers adoptants (SAP Learning). Si aucun des deux cas ne s'applique, vous avez un problème de cadrage, pas un déploiement.

Le clean core s'applique à chaque écart local. La Public Edition n'accepte les extensions que par des interfaces publiées. Sur la Private Edition, c'est un choix de gouvernance, mais chaque modification locale que vous autorisez est un objet de plus à retester à chaque mise à niveau, multiplié par le nombre de pays. La discipline que je défends est simple : les lois fiscales, le reporting réglementaire et les obligations réglementaires justifient un écart. Les préférences locales, non.

Avant de vous engager sur une date pour le pays suivant, obtenez un oui sur chacun de ces points. Chacun a un responsable.

1. Responsable métier local (nouveau pays) : nommé, avec le pouvoir de valider la conception locale.
2. Conseiller fiscal et juridique : fiscalité, reporting réglementaire et champs de données obligatoires documentés avant le début de la conception.
3. Propriétaire du template (siège) : liste des écarts proposés, chacun marqué comme exigence ou préférence.
4. Responsable des données : données locales de clients, fournisseurs et articles alignées sur les standards globaux.
5. Responsable de l'intégration : systèmes locaux à connecter, tels que les banques, les déclarations fiscales ou la logistique, identifiés et cadrés.
6. Responsable du changement : formation adaptée au processus local, dans la langue locale, avec des exemples locaux.
7. Directeur de programme : un site à la fois, en réinjectant dans le suivant les enseignements du dernier go-live.

Mon guide du modèle de périmètre aide pour le point 3, et le guide de la charte de projet explique comment consigner par écrit les droits de décision.

Une mise en œuvre greenfield en Égypte. Une entreprise industrielle régionale basée en Égypte était coincée avec de vieux systèmes déconnectés et beaucoup de travail manuel. La supply chain, le suivi de production et le reporting financier ne communiquaient pas entre eux. Elle a mis en œuvre SAP S/4HANA à partir de zéro et relié la finance, les achats et la production dans un seul système. Elle a mis en place une planification automatisée de la supply chain et formé plus de 5 000 salariés dans quatre pays avant le go-live. Elle ne s'est pas précipitée. Elle a réduit ses coûts d'exploitation de 25 % et ses erreurs de prévision de 35 %.

Un déploiement sur 15 marchés. Une entreprise de distribution avait déjà SAP S/4HANA en production à son siège et en avait besoin sur 15 nouveaux marchés. Chacun avait ses propres règles fiscales, ses devises et ses pratiques commerciales. Elle est partie d'un template global, l'a ajusté pour chaque site, a déployé par phases sur deux ans plutôt que d'un seul coup et a construit une formation pour chaque région. Résultat : une consolidation financière plus rapide, un suivi des stocks en temps réel dans l'ensemble des magasins et un reporting au niveau du groupe plus précis de 20 %.

L'une construisait quelque chose qui n'existait pas. L'autre étendait quelque chose qui fonctionnait. Aucune n'était plug-and-play. Si vous en êtes au début de la première, mon guide sur la bonne façon de démarrer une mise en œuvre SAP est le point de départ.

Quelle est la différence entre une mise en œuvre SAP et un déploiement SAP ?

Une mise en œuvre construit SAP à partir de zéro : exigences, conception des processus, configuration, migration des données, intégration, tests et go-live. Un déploiement étend un système SAP existant et son template global à un nouveau pays, une nouvelle entité ou une nouvelle unité métier. Le travail de déploiement, c'est l'écart entre le template et les besoins locaux : fiscalité, reporting réglementaire, langue, intégrations locales et formation.

Quand une entreprise doit-elle choisir une mise en œuvre plutôt qu'un déploiement ?

Choisissez une mise en œuvre quand il n'y a pas de SAP à étendre ou qu'un système historique est remplacé dans son ensemble. C'est aussi la meilleure voie quand le modèle économique a assez changé pour que la conception existante ne convienne plus, ou quand aucun template ne couvre le périmètre requis. Forcer le déploiement d'un mauvais template crée plus de reprises qu'une conception propre.

Combien de temps dure un déploiement SAP par rapport à une mise en œuvre ?

Une mise en œuvre dure généralement de 12 à 24 mois, davantage pour les grands groupes. Un déploiement dure généralement de 6 à 12 mois par site, selon la localisation, les intégrations et les données. La plus grande variable est la qualité de la validation des exigences locales avant le début de la conception.

Quels sont les plus grands défis d'un déploiement SAP multi-pays ?

Quatre reviennent sans cesse. Des templates imposés aux équipes locales sans leur avis. Des exigences de localisation découvertes pendant les tests. Des données de base qui ne respectent pas les standards globaux. Une formation qui explique le système global au lieu du système local. Ce sont pour la plupart des problèmes de personnes et de planification plutôt que des problèmes techniques.

Un déploiement SAP est-il toujours moins cher qu'une mise en œuvre complète ?

Généralement, parce que la conception existe déjà et a fait ses preuves. L'économie diminue quand un pays a des règles fiscales ou de paie complexes, demande plusieurs intégrations locales ou a des données de mauvaise qualité. Avec RISE with SAP, l'abonnement de chaque nouveau pays continue après le go-live : comparez donc les coûts sur plusieurs années.

Comment fonctionne un template global dans un déploiement SAP ?

Le template global est la conception SAP documentée et configurée pour les processus standard du groupe. Chaque déploiement part de lui et n'ajoute que les changements locaux réellement nécessaires. Chaque écart crée une obligation de maintenance à chaque mise à niveau : gouvernez-les donc. Des exigences comme la loi fiscale justifient un écart, les préférences non.