La stratégie nécessite une approche hybride combinant SAP Information Lifecycle Management (ILM) pour l'extraction des données historiques, une couche d'intégration temporaire MuleSoft pour maintenir la continuité des commandes pendant la période TSA, et une mise en œuvre phasée de Salesforce priorisant les processus orientés client avant les capacités de clôture financière. Cette architecture répond à la contrainte de zéro temps d'arrêt en maintenant un pont temporaire entre les modules de fabrication SAP de la société mère et la nouvelle instance CRM Salesforce. Le cahier des charges doit documenter les frontières de propriété des données, les protocoles de synchronisation en temps réel pour les transactions en cours, et les mécanismes de préservation des pistes de vérification indépendantes pour satisfaire aux exigences des Contrôles Généraux IT (ITGC) de SOX.
Description du problème
Un conglomérat industriel mondial cédait sa division de produits chimiques spécialisés à une société de capital-investissement. La division avait fonctionné au sein de l'instance SAP S/4HANA de la société mère pendant 15 ans, partageant clients, fournisseurs et comptes de grand livre général avec cinq autres divisions. Les ventes interentreprises représentaient 40 % des revenus de la division, les transactions passant par la fonction de trésorerie centralisée de la société mère. L'accord de services de transition n'autorisait que 90 jours pour une séparation opérationnelle complète, pourtant la division avait 2 500 commandes clients actives en cours, et l'acheteur nécessitait une capacité de conformité SOX immédiate pour soutenir leur introduction en bourse prévue dans 18 mois. La société mère a refusé de fournir un accès continu au système au-delà de la période TSA, et l'instance Salesforce de l'acheteur devait gérer à la fois les processus CRM et les processus de commande à encaissement sans les modules de fabrication approfondis disponibles dans SAP.
Solution 1 : Coupure Big Bang avec Migration Complète de Données
Une approche considérée consistait à effectuer une coupure durant un week-end où l'ensemble des 15 ans de données historiques serait extrait, purgé des transactions interentreprises, et chargé dans Salesforce avec un modèle de données personnalisé imitant les structures SAP. Cela impliquerait de geler toutes les transactions pendant 72 heures pendant que les outils LDS SAP extrayaient les objets de données de la division.
Avantages : Séparation claire, aucune complexité d'intégration continue, indépendance immédiate des systèmes de la société mère.
Inconvénients : Violait le mandat de zéro temps d'arrêt du TSA ; Salesforce n'a pas de support natif pour les nomenclatures de fabrication complexes et la comptabilité analytique, nécessitant un développement massif personnalisé qui ne pourrait pas être complété en 90 jours ; le risque de corruption des données pendant la transformation de l'histoire de 15 ans était inacceptable compte tenu des exigences d'audit pour l'IPO.
Solution 2 : TSA Prolongée avec Migration Phasée
Une autre option était de négocier une prolongation de TSA de 12 mois où la division continuerait d'utiliser SAP pour la clôture financière tout en migrant progressivement les clients vers Salesforce uniquement pour les nouvelles commandes.
Avantages : Risque technique réduit, temps accordé pour construire les personnalisations appropriées de Salesforce pour les processus de fabrication, maintien de l'accessibilité des données historiques dans SAP pendant la transition.
Inconvénients : Les soutiens en capital-investissement de l'acheteur ont refusé d'accepter les coûts de responsabilité des frais de prolongation de TSA (500 000 $ par mois) ; les auditeurs SOX exigeaient que la division démontre des environnements de contrôle indépendants dans les 90 jours, ce qui ne pouvait être réalisé tout en utilisant encore l'instance SAP de la société mère ; les transactions interentreprises historiques nécessitaient une reclassification en tant que ventes externes, ce qui ne pouvait pas être différé.
Solution choisie et résultat
L'équipe a sélectionné une architecture à double fonctionnement utilisant MuleSoft comme bus d'intégration intermédiaire. Pendant les 60 premiers jours, les nouvelles commandes clients étaient saisies dans Salesforce mais passaient via MuleSoft dans le SAP de la société mère pour le traitement, tandis que l'extraction de données historiques se déroulait en parallèle en utilisant SAP Information Lifecycle Management (ILM) avec des règles personnalisées pour bifurquer les transactions interentreprises. Aux jours 61-90, le traitement des commandes a été transféré vers une instance temporaire de Microsoft Dynamics 365 (déjà certifiée SOX) pour les opérations de fabrication, tandis que Salesforce gérait le CRM et les devis. Les données historiques ont été archivées dans AWS S3 avec Snowflake fournissant des pistes de vérification consultables pour l'exigence de 7 ans, plutôt que d'essayer de migrer toute l'historique dans des objets opérationnels Salesforce.
Cette approche a satisfait aux contraintes du TSA en maintenant la continuité des commandes, a atteint la préparation SOX d'ici le 85e jour grâce au cadre de contrôle Dynamics 365, et coûtait 2 millions de dollars de moins que la construction de modules de fabrication natifs Salesforce. La société de capital-investissement a réussi à terminer son IPO 14 mois après la clôture.
Comment gérez-vous l'ambiguïté légale et technique lorsque l'accord d'achat définit le "Business" vendu différemment de la structure technique du client SAP, entraînant des clients partagés qui achètent à la fois de la division cédée et des divisions conservées ?
Beaucoup de candidats supposent que les données clients peuvent simplement être copiées. L'approche correcte consiste à créer une stratégie de Golden Record où les clients partagés sont répliqués dans le nouvel environnement avec des données historiques masquées, tout en mettant en place un hub de Master Data Management (MDM) utilisant Informatica ou Talend pour maintenir la synchronisation pendant la période TSA sans violer les clauses de confidentialité des données. Le BA doit rédiger des exigences pour des algorithmes de correspondance des clients qui identifient des entités partagées en fonction du numéro d'identification fiscale et d'une correspondance d'adresses floues, puis mettre en œuvre des règles de masquage des données garantissant que l'entité cédée ne voit que son historique de transactions tandis que la société mère conserve des dossiers complets.
Quelles exigences de contrôle SOX spécifiques doivent être documentées pour l'état intérimaire lorsque l'entité cédée utilise le système SAP de la société mère mais est techniquement une entité juridique distincte ?
Les candidats se concentrent souvent uniquement sur l'état cible. Pendant le TSA, le BA doit documenter les exigences des Contrôles Généraux IT (ITGC) spécifiant que la société mère maintient les contrôles d'accès SAP GRC (Gouvernance, Risque et Conformité) tout en fournissant aux auditeurs de l'entité cédée un accès en lecture seule aux journaux système. Les exigences doivent stipuler que toutes les écritures comptables publiées par l'entité cédée pendant le TSA portent des codes de société et des identifiants de publication distincts pour assurer la séparation des fonctions, et que l'équipe SAP Basis de la société mère fournisse des extractions automatisées quotidiennes de toutes les transactions affectant le bilan de l'entité cédée vers un dépôt SQL Server autonome pour la préservation de la piste d'audit indépendante.
Comment modélisez-vous les exigences concernant la décomposition des transactions interentreprises qui étaient auparavant des transferts internes mais doivent devenir des ventes/achats externes après la cession ?
Cela nécessite des modèles de processus BPMN montrant la transformation des écritures de centres de profit internes SAP en transactions EDI externes. Le BA doit spécifier les exigences pour de nouvelles données maîtresses de prix (les prix de transfert deviennent des prix externes), des moteurs de calcul des taxes (la TVA s'applique désormais là où elle ne s'appliquait pas auparavant) et la création de données permanentes de créances/dettes. De manière critique, les exigences doivent inclure un mécanisme de "Jour 1" de reclassification où les 12 derniers mois de transactions interentreprises sont reclassées rétrospectivement dans l'entrepôt de données Snowflake pour montrer l'entité cédée en tant que partie externe, garantissant que les états financiers comparatifs pour l'IPO ne montrent pas des transactions internes impossibles avec elle-même.