La mise en place du système ERP détermine le calendrier de toutes les autres étapes

En bref

C'est le calendrier de séparation de l'ERP qui détermine en réalité le rythme d'une scission d'entreprise. Le service financier ne peut pas clôturer un grand livre autonome. Le service des achats ne peut pas émettre ses propres bons de commande. Le service logistique ne peut pas expédier de marchandises aux clients tant que le calendrier de séparation de l'ERP n'est pas achevé. Les équipes chargées de la transaction évaluent souvent le contrat de services de transition en se basant sur des hypothèses relatives à la finance et aux ressources humaines. Elles considèrent alors le calendrier de séparation de l’ERP comme un détail technique qu’un intégrateur peut finaliser sur simple demande. Lorsque le choix de la solution informatique est pris tardivement, c’est généralement le calendrier de séparation de l’ERP qui détermine la date de sortie effective, et non le contrat.

Pourquoi le calendrier de scission de l'ERP entre en conflit avec les accords de services de transition (TSA)

L'acquisition est désormais finalisée. La société a signé l'accord de services de transition, qui prévoit un délai de douze mois pour sortir des services partagés. Sur le papier, le calendrier de séparation semble bien organisé. Les axes de travail relatifs aux ressources humaines, aux aspects commerciaux, aux entités juridiques et à la chaîne d'approvisionnement comportent chacun leurs propres étapes clés.

Au bout des soixante premiers jours, la situation prend une toute autre tournure. Le service financier n’arrive pas à finaliser le plan comptable autonome. Personne n’a configuré le grand livre. Le service des opérations ne peut pas émettre de bons de commande autonomes tant que la base de données de gestion des stocks n’est pas dissociée de celle de la société mère. Le service logistique ne peut pas expédier les composants finis. L’équipe n’a pas rétabli la liaison d’échange de données informatisé avec l’usine du client.

Le calendrier de la scission de l'ERP n'est pas un axe de travail parmi d'autres. Il donne le rythme à tous les autres axes de travail de la scission. Rares sont les équipes chargées de la transaction qui en tiennent compte dans leur estimation lors de la signature.

Défis transfrontaliers liés à la mise en œuvre d'une scission d'activités SAP

Le calendrier de scission de l'ERP devient véritablement complexe dès lors que les sites de production sont situés dans un pays différent de celui de la maison mère. Un cas de figure courant : le vendeur héberge une instance SAP ou Oracle depuis son siège social en Allemagne, en France ou en Suisse. Les usines qui assurent la production sont quant à elles situées en Pologne, en Tchéquie, en Hongrie ou en Roumanie.

Gestion des données de référence partagées et risques liés à la séparation dans le cadre d'un « carve-out » SAP

Dans un système intégré, les données relatives aux matériaux, aux fournisseurs et aux clients sont stockées dans des tables partagées entre plusieurs divisions. L’extraction d’une unité opérationnelle ne se résume pas à une simple exportation. Un fournisseur et une unité cédée partagent souvent des références de pièces moulées, des spécifications d’alliages ou des comptes clients. Il faut que quelqu’un sépare les données commerciales confidentielles sans altérer les nomenclatures historiques. Cela nécessite des personnes qui comprennent l’installation physique, et pas seulement la base de données. C’est précisément pour cette raison que le calendrier de scission de l’ERP subit ici un premier ralentissement, avant que tout autre volet du projet n’en subisse les conséquences.

Respect des règles locales en matière de conformité réglementaire et fiscale dès le premier jour de la séparation

Une entité autonome en Europe centrale ne peut pas se contenter d'adopter un modèle global unique en espérant que la conformité s'ensuivra d'elle-même. Les activités polonaises ont besoin d'un module de reporting SAF-T conforme. Les entités tchèques ont leurs propres règles d'amortissement légales et leurs propres déclarations de contrôle de la TVA. Les filiales roumaines ont besoin d'une facturation électronique certifiée. Si le nouvel ERP n'est pas en mesure de générer ces documents le jour de la migration, la filiale ne pourra légalement ni facturer ni expédier de marchandises.

Prévention des défaillances liées à l'échange de données informatisé (EDI) et aux interfaces client

Les clients des secteurs automobile et aérospatial imposent des protocoles de livraison stricts, tels que les normes allemandes VDA et européennes Odette. Le nouveau système risque de ne pas envoyer un avis d’expédition préalable correct. Il peut générer une étiquette d’emballage comportant un numéro de série erroné. Chacune de ces erreurs peut amener un client de premier rang à refuser la livraison dès son arrivée. Le client peut alors facturer les coûts liés à l’arrêt de la chaîne de production au fournisseur.

Identifier les signes avant-coureurs d’un dérapage du calendrier de la scission des services ERP

Les conseils d'administration ne se rendent que rarement compte des problèmes liés au calendrier de scission d'une activité ERP lorsqu'une étape n'est pas franchie. Ce dérapage se manifeste plus tôt, à travers des signes spécifiques observables au cours des quatre premiers mois.

Retards des partenaires chargés de la mise en œuvre du système et décalage de la date de mise en service

Le partenaire externe chargé de la mise en œuvre demande à plusieurs reprises que le calendrier de scission du système ERP soit repoussé. La date de mise en service passe de neuf mois à quinze, voire dix-huit.

Restrictions informatiques imposées par la société mère et retards dans l'accès aux bases de données

L'ancienne société mère retarde l'accès direct à la base de données. Elle invoque la protection des données et la confidentialité des comptes clients partagés qu'elle souhaite préserver.

Échec des tests EDI et escalade vers la chaîne logistique du client

Les tests d'échange de données informatisées (EDI) effectués avant le lancement donnent lieu à des étiquettes corrompues ou à des transmissions rejetées. L'équipe logistique du client fait remonter le problème à ses supérieurs.

Solutions de contournement manuelles et hausse des majorations de coûts liées aux contrats de services de transition (TSA)

Les responsables d'usine et les responsables logistiques créent des tableurs manuellement. Personne ne les a formés au nouveau système, et personne ne se fie aux données. Pendant ce temps, le délai prévu par le contrat de services de transition continue de s'écouler. Les frais liés à sa prolongation augmentent selon un calendrier fixe, quel que soit l'avancement réel du processus de séparation de l'ERP.

Dès que plusieurs de ces symptômes apparaissent simultanément, le schéma est sans équivoque. Un retard technique dans la migration d’une base de données se transforme en quelques semaines en un problème physique au niveau du quai de chargement.

Cadre stratégique visant à accélérer la séparation des systèmes informatiques et la migration vers le nouveau système

Pour rattraper le retard pris dans le calendrier de scission d'une activité ERP, il faut un cadre supérieur désigné disposant d'un pouvoir opérationnel. Un comité de pilotage qui se réunit chaque mois ne suffit pas.

Choisir la bonne stratégie de migration ERP : migration ou développement « greenfield »

Lorsqu'il s'agit de déterminer comment intégrer la scission dans un calendrier serré, la direction examine généralement trois options architecturales distinctes :

• Cloner et diviser
• Migration sélective des données
• Construction sur site vierge

Dans un délai de neuf à douze mois, la mise en place d'une solution entièrement nouvelle s'inscrit rarement dans le calendrier prévu. Une migration ciblée et sélective ou un modèle cloud préconfiguré permet de limiter la personnalisation et de reproduire les processus existants de l'usine, préservant ainsi les routines déjà bien connues du personnel de production.

Dissocier la mise en œuvre des installations de la gouvernance du basculement informatique

Un directeur d'usine ne peut pas à la fois gérer trois équipes de travail et tester des milliers d'opérations ERP. Lui demander de mener de front ces deux tâches le condamne à l'échec dans chacune d'elles. C'est plutôt à un responsable de projet indépendant qu'il revient de piloter la phase de basculement, en assurant directement la coordination entre le service informatique de l'entreprise, l'intégrateur et les opérations de l'usine.

Mise en place de marges de sécurité opérationnelles avant la migration du système

Afin de se prémunir contre les défaillances de la chaîne d'approvisionnement, le conseil d'administration devrait approuver à l'avance des mesures d'urgence spécifiques. Trois éléments sont particulièrement importants pour le calendrier de scission du système ERP :

• Stock tampon de produits finis : constituer des stocks dans les entrepôts des principaux clients.
• Procédure sur support papier : conserver une procédure d'expédition manuelle vérifiée comme solution de secours.
• Gel des modifications : mettre en place un gel des modifications non essentielles du système avant le début de la fenêtre de basculement.

Les rapports peuvent rester imparfaits pendant quelques jours. Une livraison manquée à un client, en revanche, ne peut pas l'être.

Gestion de la gouvernance et des opérations dans le cadre d'un démêlage informatique impliquant plusieurs juridictions

Le bureau chargé de la mise en œuvre chez l’acheteur est généralement situé dans un pays. Le bureau chargé de la séparation chez le vendeur se trouve dans un autre. Ces deux entités relèvent souvent de responsables différents, animés par des motivations différentes. La mise en place d’une base factuelle commune entre eux permet de respecter le calendrier de la scission de l’ERP. Ce n’est pas le cas avec deux plans de projet concurrents. Certaines usines cédées sont situées dans des zones où ni l’équipe technique de l’acheteur ni le service informatique du vendeur n’interviennent au quotidien. Dans ce contexte, un seul responsable exécutif est souvent la seule personne à assurer la cohérence du calendrier de séparation et de cession de l’ERP.

Données du secteur concernant les risques liés à la dissociation des systèmes ERP et aux contrats de services de transition

Selon Gartner, recherche montre que 55 à 75 % des projets ERP ne parviennent pas à atteindre les objectifs opérationnels prévus. Dans le secteur de la fabrication discrète et les chaînes d’approvisionnement multisites, les défaillances survenant après la mise en service au niveau de l’expédition depuis les entrepôts et de la planification de la production constituent les principales sources de difficultés. Ce sont précisément ces défaillances que le calendrier de scission d’un projet ERP met en péril.

Transaction transfrontalière de Roland Berger études parviennent à une conclusion similaire. Ils citent la dissociation des services informatiques et des ressources humaines comme les deux principaux écueils à l’origine de plus d’un tiers des cas où les scissions ne respectent pas leurs objectifs en matière de coûts, de délais ou de qualité. Une autre enquête menée par Roland Berger auprès de près de quatre cents experts met en avant ces deux mêmes domaines. C’est dans la dissociation des services informatiques et des ressources humaines que se concentrent principalement les dépassements de coûts et les retards. Les deux causes profondes récurrentes sont le manque d’expérience préalable en matière de séparation au sein de l’équipe chargée du programme et une planification irréaliste au moment de la signature.

BCG's recherche indique que la séparation de l'ERP et de l'architecture informatique constitue le volet le plus long des cessions d'entreprises. Les acquéreurs de capital-investissement et les entreprises vendeuses omettent parfois de préparer et d'isoler les dépendances informatiques avant la conclusion de la transaction. Lorsque cela se produit, les prolongations des contrats de services de transition et les déssynergies opérationnelles grignotent rapidement la valeur de la transaction.

McKinsey's analyse souligne que la dissociation informatique est souvent plus complexe que l'intégration du côté acheteur. L'interface technique entre le service chargé de la mise en œuvre chez l'acheteur et le service chargé de la dissociation chez le vendeur nécessite une gouvernance opérationnelle rigoureuse, celle-là même qu'un contrat de services de transition pour la dissociation informatique est censé garantir. Sans cela, les basculements de systèmes commencent à entraîner des litiges commerciaux et des défaillances dans la prestation de services aux clients.

Les recommandations d'EY concernant les programmes de séparation placent le calendrier de dissociation des systèmes ERP au même rang. La règle est la suivante : consacrer 80 % des efforts de séparation aux systèmes ERP, à la gestion de la paie et à la gestion de la performance d'entreprise. Ces systèmes figurent généralement parmi les derniers services à être désactivés dans le cadre d'un accord de transition.

Prises dans leur ensemble, ces cinq sources vont dans le même sens. Le calendrier de la scission de l'ERP mérite que la direction y accorde la même attention que celle que l'équipe chargée de la transaction réserve habituellement à la due diligence financière. Or, on ne lui accorde généralement guère plus d'attention qu'à une simple dépendance technique.

Étude de cas : gestion d'une scission SAP d'une durée de 10 mois dans le secteur de la construction automobile

Le mandat suivant illustre comment une intervention rigoureuse de la direction a permis de mener à bien la scission d'une activité SAP dans le délai fixé par l'accord de transition.

La mission : stratégie de scission des activités de construction automobile transfrontalières

Ce mandat de 85 millions d'euros illustre concrètement le calendrier de scission d'une division ERP. Un investisseur européen en capital-investissement a acquis une division spécialisée dans les composants de précision pour groupes motopropulseurs automobiles auprès d’un conglomérat industriel allemand de premier rang. L’entité issue de la scission exploitait deux usines. Un site d’usinage de précision situé en Saxe, en Allemagne, employait 320 personnes. Une usine d’assemblage située à Plzeň, en Tchéquie, employait 200 opérateurs techniques.

Aux termes du contrat d’achat, l’ancienne société mère hébergeait l’infrastructure informatique, la messagerie électronique et le système SAP ECC 6.0 central. Elle le faisait dans le cadre d’un contrat de services de transition strict d’une durée de douze mois. Ce contrat prévoyait des primes de prolongation élevées : 25 % pour les mois 13 à 15, et 50 % au-delà. Le non-respect d’une échéance exposait l’acquéreur à des coûts supplémentaires pouvant atteindre 600 000 euros.

À quel moment le calendrier de scission de l'ERP a-t-il déraillé ?

Au bout de quatre mois, le programme accusait un retard considérable. L’intégrateur choisi par le commanditaire a proposé de migrer directement vers une solution SAP S/4HANA sur le cloud, personnalisée. Il s’agissait là d’un projet ambitieux de scission des activités SAP, qui semblait parfait sur une diapositive. Son calendrier de dix-huit mois aurait entraîné un dépassement de six mois par rapport à l’accord de transition.

L'extraction des données de référence a également été bloquée. L'équipe informatique de la société mère allemande a refusé de fournir l'intégralité des extraits de base de données. Ses tables historiques de données de référence clients contenaient des données confidentielles sur les tarifs des gammes de produits que la société mère avait conservées.

À Plzeň, l'équipe a constaté que le système cible proposé ne respectait aucune obligation légale tchèque en matière de déclaration fiscale ou douanière. Le projet a ensuite procédé à ses premiers tests d'échange de données informatisé avec les usines d'assemblage de Wolfsburg et de Leipzig. Les messages d'expédition ont échoué en raison d'une sérialisation des codes-barres non conforme. Des clients clés ont émis des avertissements formels concernant le risque que cela représentait pour leurs calendriers de livraison.

Direction provisoire du programme ERP et intervention d'urgence

Le partenaire opérationnel a fait appel à CE Interim pour piloter le calendrier de scission du projet ERP. Dans les 72 heures qui ont suivi la finalisation du cahier des charges, un directeur de programme ERP intérimaire, ayant fait ses preuves et dont le profil correspondait parfaitement à la mission, a pris ses fonctions. Ce cadre apportait avec lui plus de vingt ans d'expérience dans le secteur de la fabrication industrielle et du redressement d'entreprises.

Pour rattraper le retard accumulé, la direction a pris quatre décisions successives :

• Nous avons mis fin au projet de développement sur mesure, qui durait depuis dix-huit mois, et avons réorienté le programme vers une extraction sélective des données sur un modèle cloud standardisé, reproduisant ainsi les flux de travail existants et réduisant de cinq mois la durée prévue du projet.
• Mise en place d'une équipe dédiée et bilingue (tchèque-allemand) chargée de la correction des données, directement sur le site de production, afin de vérifier et de nettoyer 1 800 nomenclatures, gammes opératoires et profils d'emballage client actifs, ce qui a permis de résoudre les problèmes liés à la confidentialité des données en collaboration avec le service juridique de la société mère.
• J'ai collaboré avec les directeurs logistiques des clients afin de reconfigurer les transactions d'échange de données informatisé (EDI) sortantes conformément aux normes VDA 4905 et 4913, et j'ai obtenu leur validation officielle dans un délai de 30 jours.
• Nous avons mis au point un plan de basculement structuré sur 72 heures, s'étalant sur un week-end férié prolongé, s'appuyant sur une réserve de produits finis couvrant cinq jours et sur une procédure de secours sur support papier.

Résultat : sortie rapide de la TSA et aucune interruption d'activité

L'usine a achevé la migration complète de la base de données pendant le week-end férié. Cela n'a entraîné aucune heure d'arrêt imprévu. Dès mardi matin, le système autonome était déjà opérationnel. Les listes de prélèvement automatisées, les plannings d'acheminement des machines et les déclarations douanières étaient traités sans encombre.

Au bout de dix mois, l’entreprise s’était totalement déconnectée de l’infrastructure informatique de son ancienne société mère. Cette étape a été franchie avec deux mois d’avance, ce qui a permis d’éviter entièrement le paiement des 600 000 euros de frais de prolongation prévus. Dans les trente jours suivant la mise en service, la précision des stocks a atteint 99,2 %. Le taux de livraisons «à temps et complètes» a atteint 98,7 %. L'équipe a supprimé toutes les solutions de contournement manuelles. Le dirigeant a ensuite procédé à un transfert structuré de la plateforme opérationnelle, auditée et indépendante, vers l'équipe informatique permanente. Voilà à quoi ressemble un calendrier rigoureux de scission d'un système ERP : géré de bout en bout par un seul dirigeant responsable.

Foire aux questions : calendriers de scission des systèmes ERP d'entreprise et stratégies de sortie du TSA

Pourquoi le calendrier de la scission de l'ERP détermine-t-il le reste du processus de scission ?

Le système ERP est à la base de la comptabilité générale, de la facturation, de la gestion des stocks, des achats et des expéditions aux clients. Toutes les autres fonctions en dépendent. Aucun autre volet du projet ne peut être mené à bien de manière indépendante tant que le calendrier de scission de l'ERP n'aura pas permis de dissocier la base de données de l'ancienne société mère.

Quelle est la méthode de migration ERP la plus rapide dans le cadre d'une scission d'entreprise ?

Une migration sélective des données, ou un modèle cloud standardisé et préconfiguré, constitue généralement la solution la plus rapide. Elle permet de conserver les schémas de fabrication qui ont fait leurs preuves. Une implémentation « greenfield », c'est-à-dire une séparation complète de SAP partant de zéro, nécessite plusieurs mois supplémentaires de configuration et de formation.

Que se passe-t-il si la mise en service du progiciel de gestion intégré (ERP) ne respecte pas la date limite prévue dans l'accord de transition ?

Le non-respect du calendrier prévu pour la séparation et l'externalisation du système ERP entraîne l'application de pénalités de prolongation contractuelle. Cela met à rude épreuve la relation commerciale avec le vendeur. Cela risque également d'entraîner des perturbations si le vendeur met à niveau ou met hors service l'infrastructure dont l'acheteur dépend encore.

Comment une usine évite-t-elle les arrêts de production liés à la file d'attente des clients lors d'une migration de système ?

Les usines qui évitent les arrêts de production constituent un stock tampon temporaire de produits finis dans les entrepôts régionaux. Elles gèlent les modifications non essentielles du système avant la période de basculement. Elles préparent une procédure d'expédition manuelle, sur support papier et validée par un audit, à titre de solution de secours.

Quand le conseil d'administration doit-il nommer un directeur de programme ERP par intérim ?

La désignation d'un mandataire s'impose dans trois situations. L'activité cédée fait partie d'une seule et même entité mère aux structures profondément imbriquées. Les équipes internes manquent d'expérience en matière de séparation transfrontalière. Ou bien le calendrier proposé par l'intégrateur entre déjà en conflit avec l'accord de transition.

Le calendrier de scission du système ERP peut-il être mis en œuvre après la finalisation plutôt qu'avant ?

C'est possible, et cela arrive souvent. Il est moins coûteux de corriger le tracé du tracé et la carte des dépendances avant l'achèvement du projet. Un enchevêtrement d'instances partagées découvert après la signature a tendance à allonger de plusieurs mois un projet dont le coût a déjà été chiffré dans l'accord de transition.

Connaissances connexes et prochaine étape

Certaines entités cédées fonctionnent déjà sur une instance isolée dotée de leurs propres licences. Dans ce cas, une équipe informatique interne peut généralement mettre en œuvre seule le calendrier de séparation de l’ERP. La situation change lorsque l’entreprise partage des tables de base de données, des nomenclatures et des licences avec la société mère dans plusieurs pays. Elle change également lorsque la feuille de route de l’intégrateur dépasse déjà le délai prévu par l’accord de transition.

Un DSI par intérim ou un responsable de la scission informatique est un profil véritablement rare. Les cas justifiant son recrutement restent limités. Cela s'applique à un projet de scission d'un système ERP à instance unique, extrêmement complexe, dont l'équipe interne n'a jamais eu à s'occuper auparavant. Dans ce cas précis, la solution proposée par CE Interim consiste à mettre à disposition un cadre expérimenté, dont les compétences correspondent parfaitement au mandat, et prêt à prendre ses fonctions dans les 72 heures suivant la finalisation du cahier des charges.

Lectures complémentaires

• Crise et restructuration
• Redressement opérationnel
• Intégration post-fusion

Il faut répondre à la question du périmètre avant que quiconque ne se penche sur le calendrier de scission lié à la séparation de l'ERP. Pour discuter en toute confidentialité d'un calendrier concret de scission lié à la séparation de l'ERP, contactez un Associé par intérim chez CE.