De SAP ECC à S/4HANA : quelles données faut-il migrer ?

: Satya Prasad, responsable senior de la mise en œuvre SAP ILM chez TJC Group

Le déplacement de chaque enregistrement de SAP ECC vers S/4HANA peut augmenter les exigences de dimensionnement de HANA, l’effort de migration et les coûts d’exploitation à long terme. Une évaluation structurée des données aide les organisations à décider ce qui doit être migré, archivé, supprimé ou conservé en dehors de l’ERP central. Cet article explique comment ces décisions peuvent créer un environnement S/4HANA plus léger tout en préservant les informations historiques nécessaires à la conformité, aux rapports, à l’analyse et aux futurs cas d’utilisation de l’IA.

Introduction

Passer de SAP ECC à SAP S/4HANA n’est pas simplement un transfert technique de données d’un système à un autre. C’est une opportunité de décider quelles données, processus et informations historiques le futur paysage SAP devrait contenir.

Migrer chaque enregistrement historique peut sembler l’option la plus sûre. Cependant, cela peut augmenter les exigences de dimensionnement de HANA, prolonger les fenêtres de migration et de test, et transporter d’anciens problèmes de données dans le nouvel environnement. D’un autre côté, supprimer trop de données présente un risque différent. Les informations historiques peuvent toujours être nécessaires pour les audits, les rapports, les litiges, la conformité fiscale ou les analyses futures. L’objectif n’est donc pas de tout déplacer ou de tout supprimer. Il s’agit de placer chaque catégorie de données dans l’environnement où elle peut apporter de la valeur à un coût et un niveau de risque appropriés.

Avant de migrer vers S/4HANA, examinez les exigences de rapports commerciaux. Posez-vous la question suivante : si j’archive mes données de comptabilité financière avant la migration/conversion, pourrai-je réconcilier mes comptes après la migration/conversion ?

Voici un exemple illustratif : chez TJC Group, nous avons vu des cas où des clients SAP passent d’une solution basée sur les comptes dans leur environnement legacy à une solution basée sur les grands livres dans leur environnement S/4HANA. Le problème survient lorsque le client souhaite afficher tous les documents pour une période donnée, y compris l’« Ancien monde (ERP) » et le « Nouveau monde (sFin) » avant et après la migration (y compris les grands livres principaux et non principaux/d’extension), et que l’organisation souhaite également inclure les éléments archivés et en ligne au sein d’UNE SEULE transaction. SAP ne fournit pas de solution standard prête à l’emploi pour de tels cas.

Pour la plupart des entreprises, cela signifie diviser les données SAP ECC en quatre groupes :

Décision concernant les données	Objectif typique
Migrer vers S/4HANA	Soutenir les processus métier en cours, les activités opérationnelles et les rapports actuels.
Archiver avant la migration	Supprimer les données terminées ou rarement consultées de la base de données active tout en les conservant pour un accès futur, la conformité ou les audits.
Conserver en dehors de S/4HANA	Préserver les informations commerciales historiques après le retrait des systèmes legacy SAP ou non-SAP, tout en les gardant accessibles si nécessaire.
Supprimer les données	Supprimer définitivement les données qui n’ont plus d’objectif commercial, légal, réglementaire ou opérationnel valide. Par exemple, les codes d’entreprise obsolètes, les données de test, les journaux système ou les données ayant dépassé leur période de conservation.

Le périmètre final doit toujours être défini pour le propre paysage SAP de l’organisation. Une implémentation greenfield, une conversion brownfield et une transition sélective des données créeront chacune des options et des contraintes différentes pour ce qui peut être migré, archivé, supprimé ou conservé en dehors de l’ERP central. La bonne décision dépend également des besoins de rapports commerciaux, des obligations de conformité, des dépendances système, de la qualité des données et de la quantité d’informations historiques qui doivent rester disponibles après la mise en service.

Prendre ces décisions tôt peut créer un système S/4HANA plus léger tout en préservant les informations historiques que les futurs cas d’utilisation commerciaux, de conformité, d’analyse et d’IA peuvent nécessiter.

Pourquoi la migration de toutes les données ECC peut créer une complexité inutile

Migrer de SAP ECC vers SAP S/4HANA est plus qu’une simple mise à niveau technique. C’est une opportunité de simplifier le système et d’améliorer les performances à long terme. Une idée fausse courante est que chaque élément de données du système ECC doit être migré. En réalité, la migration de toutes les données historiques augmente souvent les coûts, la complexité et les risques du projet sans apporter de valeur commerciale significative.

Besoins en mémoire HANA et coûts associés

Le volume de données influence les exigences de mémoire et de stockage de HANA, les durées de copie du système, les temps de sauvegarde et de récupération, la planification de la reprise après sinistre, l’effort de test, les temps d’exécution de la migration et le coût de maintenance des environnements de développement, d’assurance qualité et de production.

Besoins en mémoire de HANA et coûts associés

Les grands volumes de données peuvent également augmenter la complexité de l’administration quotidienne du système. Les rapports financiers et les activités de clôture de période peuvent nécessiter le traitement d’années d’enregistrements historiques qui ne sont plus pertinents pour les opérations commerciales actuelles. Les sauvegardes prennent plus de temps, les actualisations du système nécessitent plus de temps et de ressources, et les futures mises à niveau doivent traiter une base de données plus importante.

L’impact devient encore plus important lorsque plusieurs systèmes SAP ECC sont consolidés dans un seul environnement SAP S/4HANA. Par exemple, différents systèmes peuvent contenir :

• Doublons d’enregistrements de base clients et fournisseurs
• Différents plans comptables
• Codes d’entreprise inactifs
• Données historiques d’entreprises acquises ou cédées
• Tables personnalisées et objets personnalisés qui ne sont plus utilisés
• Enregistrements legacy avec une propriété commerciale peu claire
• Données ayant dépassé leur période de conservation requise

Le déplacement de toutes ces informations ne crée pas automatiquement un système S/4HANA plus complet ou plus utile. Il peut simplement transférer la complexité existante dans un environnement plus coûteux.

BT Group a ressenti l’impact pratique des volumes élevés de données SAP lors de sa transformation. À un moment donné, son volume de données avait atteint 12,5 To et affectait les performances du système. Grâce à l’archivage et au tiering des données, ce volume a été réduit à 8 To tout en soutenant la transition de l’organisation de plusieurs bases de données SAP ECC vers SAP S/4HANA.

Carlsberg Group a suivi un programme de gestion du volume de données à long terme tout en consolidant plusieurs systèmes ERP et en se préparant à la migration vers le cloud. Son programme a réduit la taille de la base de données de 62,5 % et a introduit des contrôles continus pour empêcher le retour d’une croissance incontrôlée.

Ces exemples illustrent pourquoi la préparation des données devrait commencer avant l’exécution de la migration. L’archivage ne doit pas être traité comme un exercice de nettoyage ajouté à la fin d’un programme S/4HANA. Il doit faire partie de la conception de la migration.

Comment décider quelles données doivent être migrées vers S/4HANA ?

La migration vers SAP S/4HANA offre l’opportunité de revoir les données existantes et de déterminer si elles continuent de soutenir les opérations commerciales. Plutôt que de déplacer toutes les données du système SAP ECC, les organisations devraient classer les informations en fonction de leur valeur commerciale, de leurs obligations légales et de leurs besoins opérationnels.

Les questions suivantes peuvent aider à guider la décision :

• Les données sont-elles nécessaires aux processus métier en cours ? Les données nécessaires aux opérations quotidiennes, à la planification, aux rapports ou au service client doivent normalement être migrées.
• Les données sont-elles toujours activement utilisées ? Les données transactionnelles et de base fréquemment consultées appartiennent généralement à SAP S/4HANA, tandis que les données historiques rarement consultées peuvent être mieux adaptées à l’archivage.
• Les données sont-elles requises à des fins légales, réglementaires ou d’audit ? Si les informations historiques doivent être conservées mais ne sont plus pertinentes sur le plan opérationnel, elles peuvent souvent être archivées ou stockées dans une solution de conservation conforme au lieu d’être migrées.
• Les données soutiennent-elles les futurs besoins de l’entreprise ? Déterminez si les informations apporteront de la valeur pour l’analyse, l’analyse des tendances ou les futures décisions commerciales.
• Les données sont-elles exactes et pertinentes ? Les données obsolètes, dupliquées, incohérentes ou de mauvaise qualité doivent être nettoyées ou supprimées avant la migration.
• Les données ont-elles dépassé leur période de conservation ? Les informations qui n’ont plus d’objectif commercial, légal ou réglementaire doivent être supprimées en toute sécurité conformément aux politiques de l’organisation.

Un cadre de décision pratique

Une approche simple consiste à classer les données en quatre catégories :

Catégorie de données	Action recommandée
Données opérationnelles actives	Migrer vers SAP S/4HANA
Données historiques requises à des fins légales ou d’audit	Archiver et conserver en dehors de la base de données active
Données historiques qui peuvent être nécessaires occasionnellement	Archiver avant la migration et fournir un accès si nécessaire
Données obsolètes, dupliquées ou expirées	Supprimer après les approbations appropriées

L’objectif n’est pas de migrer la quantité maximale de données, mais de migrer les bonnes données. Une stratégie de sélection des données bien planifiée réduit l’effort de migration, diminue les coûts d’infrastructure et de maintenance, améliore les performances du système et aboutit à un paysage SAP S/4HANA plus propre et plus gérable.

Il n’y a pas de nombre universel d’années de données historiques que chaque organisation devrait migrer. Le périmètre correct dépend de la méthode de migration, des processus actuels, des besoins en rapports, des obligations réglementaires, des dépendances des données et de la faisabilité technique de séparer les enregistrements de manière cohérente.

Un bon point de départ est de poser trois questions :

• Les données sont-elles nécessaires pour achever un processus métier actif ?
• Doivent-elles être disponibles directement dans S/4HANA pour une utilisation opérationnelle fréquente ?
• Le fait de les conserver en dehors de l’ERP actif répondrait-il toujours aux exigences commerciales et de conformité ?

Ces questions ne doivent pas être appliquées comme un modèle fixe. La réponse variera en fonction de l’approche de migration de l’organisation. Dans un projet greenfield, l’entreprise peut avoir plus de liberté pour redéfinir les processus et ne transférer que des données sélectionnées. Dans une conversion brownfield, davantage de structures et de dépendances existantes peuvent rester en place. Dans une transition sélective des données, l’organisation peut définir un périmètre plus adapté par code d’entreprise, exercice fiscal, processus ou unité organisationnelle. C’est pourquoi le périmètre de migration doit être convenu par les parties prenantes du métier, de l’informatique, des données, de la conformité et de l’audit avant le début de l’exécution.

Données nécessaires aux processus métier actifs

Les données commerciales ouvertes et actives doivent généralement être déplacées vers S/4HANA. Cela peut inclure :

• Postes clients et fournisseurs ouverts
• Commandes d’achat et de vente actives
• Contrats en cours
• Ordres de fabrication ouverts
• Projets et actifs actifs
• Documents financiers non soldés
• Inventaire et positions de stock actuels
• Enregistrements de service, de garantie ou de maintenance en cours

La sélection doit tenir compte des dépendances entre les objets. Une commande client ouverte, par exemple, peut dépendre de données de base client associées, de conditions de prix, d’enregistrements de matériel, de livraisons, de factures et de documents comptables. La migration de seulement certaines parties de cette chaîne peut affecter la continuité du processus ou rendre l’information difficile à interpréter.

Pour cette raison, le périmètre de migration doit être convenu conjointement par les propriétaires de processus métier, les spécialistes des données, les équipes de conformité et le programme de migration. Il ne doit pas être décidé uniquement en fonction de l’ancienneté des enregistrements.

Données historiques récentes nécessaires pour les rapports

Certaines transactions terminées peuvent encore être fréquemment utilisées pour la comparaison et les rapports. Par exemple :

• Les équipes financières peuvent avoir besoin des chiffres de l’année précédente pendant la clôture.
• Les équipes d’approvisionnement peuvent comparer les performances actuelles des fournisseurs avec les périodes récentes.
• Les équipes de vente peuvent avoir besoin d’accéder à l’historique des commandes clients, aux retours et aux tendances de prix.

Cela ne signifie pas que chaque transaction historique doit rester dans S/4HANA. Les décideurs doivent définir la quantité d’historique récent requise dans le système actif pour les comparaisons d’une année sur l’autre, les rapports financiers, l’analyse opérationnelle, le service client, les réclamations de garantie, la planification et les prévisions, les rapports réglementaires et les projets à long terme.

Une transition sélective des données peut utiliser les exercices fiscaux, les unités organisationnelles ou une combinaison des deux pour définir quels enregistrements sont déplacés. La bonne période doit refléter l’utilisation réelle plutôt que l’hypothèse qu’un historique plus long est toujours préférable.

Données de base et personnalisées toujours utilisées par l’entreprise

Les données de base pertinentes doivent être déplacées avec les processus qui en dépendent. Cela peut inclure les partenaires commerciaux actifs, les clients et les fournisseurs, les matériaux, les actifs, les centres de coûts et de profit, les usines et les lieux de stockage, les plans comptables, les structures organisationnelles et les données de classification.

La migration S/4HANA est également une opportunité de traiter les enregistrements de base dupliqués, incomplets ou inactifs. Le travail sur la qualité des données doit établir quelle version d’un enregistrement fait autorité, si elle a un propriétaire valide et si elle prend toujours en charge un processus actif. Le transfert de données de base dupliquées vers S/4HANA peut affaiblir les rapports et créer des problèmes pour l’automatisation future.

Les données personnalisées nécessitent une évaluation distincte. Une table personnalisée ne doit pas être migrée simplement parce qu’elle existe dans SAP ECC. L’organisation doit confirmer que le processus, le rapport, l’interface ou l’application associés continueront dans S/4HANA. Lorsque la fonctionnalité personnalisée est retirée, ses données peuvent être plus adaptées à l’archivage ou à la conservation en dehors du système central.

Quelles données doivent être archivées avant la migration

L’archivage des données SAP supprime les informations éligibles des tables de base de données actives et les écrit dans des fichiers d’archive tout en préservant un accès contrôlé. Il peut réduire le volume transféré dans S/4HANA sans traiter les informations conservées comme jetables.

Cependant, l’archivage des données dans SAP nécessite plus que la simple sélection des enregistrements les plus anciens. Les données doivent répondre aux prérequis commerciaux et techniques pertinents, y compris les dépendances vis-à-vis des objets connexes et des processus ouverts.

Données transactionnelles terminées

Les transactions clôturées qui ne sont plus nécessaires aux opérations quotidiennes sont souvent de bons candidats à l’archivage. Les exemples peuvent inclure :

• Documents financiers compensés
• Documents de vente et d’achat terminés
• Ordres de fabrication clôturés
• Documents matériels historiques
• Enregistrements de maintenance terminés
• Anciens journaux d’application et données techniques
• Projets entièrement réglés

L’éligibilité dépend de l’objet d’archivage SAP et des règles de l’organisation. Un document ne peut pas être archivé en toute sécurité s’il reste connecté à un processus incomplet. Les évaluations d’archivage doivent donc identifier les postes ouverts, les dépendances, les périodes de résidence et les exigences d’accès avant le début de l’exécution.

Données des unités organisationnelles inactives

Les données historiques peuvent concerner des codes d’entreprise, des usines, des organisations commerciales ou des unités commerciales qui ne sont plus actives. Cela peut se produire après une restructuration d’entreprise, des fusions et acquisitions, des cessions, des sorties de marché, des fermetures d’usines ou la consolidation d’entités juridiques.

Lorsque les données doivent encore être conservées, l’archivage ou le décommissionnement des systèmes legacy peut être plus approprié que de les déplacer dans l’environnement S/4HANA actif. L’évaluation doit également prendre en compte la propriété. Les données historiques liées à une entreprise cédée peuvent être soumises à des règles contractuelles, légales ou réglementaires définissant quelle organisation peut les conserver et pendant combien de temps.

Données qui doivent être conservées à des fins légales ou fiscales

Les informations qui ne sont plus opérationnelles peuvent toujours devoir être conservées pour des raisons fiscales, d’audit, de responsabilité du fait des produits ou d’autres raisons réglementaires. L’archivage peut aider à séparer ces données de la charge de travail transactionnelle active tout en maintenant l’accès pour les utilisateurs autorisés.

Les périodes de conservation peuvent différer selon le pays, l’entité juridique, le type de document, le processus métier, l’industrie et l’autorité réglementaire. Une organisation multinationale ne peut donc pas se fier à une seule période de conservation pour l’ensemble de son paysage SAP.

Le programme de gestion des données de Carlsberg Group, par exemple, a dû tenir compte des exigences fiscales, d’audit et du RGPD dans plusieurs juridictions européennes. Le programme a combiné l’archivage des données, les politiques de conservation, le blocage des données et la destruction contrôlée des données au lieu de traiter la réduction du volume de données et la conformité comme des projets distincts.

Quelles données peuvent être supprimées avant la migration

L’archivage et la suppression des données servent des objectifs différents. Les données archivées sont conservées et restent accessibles. Les données supprimées sont définitivement détruites.

La suppression ne doit donc avoir lieu qu’après que l’organisation a validé la décision par rapport aux exigences légales de conservation, aux obligations fiscales et d’audit, aux obligations contractuelles, aux gels juridiques actifs, aux litiges et aux dépendances opérationnelles. Même lorsque les données semblent obsolètes, la destruction ne doit être effectuée que lorsque les approbations et les exigences de preuve pertinentes ont été examinées et documentées.

En règle générale, vérifiez que :

• La période de conservation requise a expiré
• Aucun gel juridique ne s’applique
• Les informations ne sont pas nécessaires à un processus actif
• Les données n’ont aucune valeur fiscale, d’audit, contractuelle ou réglementaire continue
• L’objectif de traitement initial ne s’applique plus
• Les dépendances avec d’autres enregistrements ont été traitées
• La destruction est autorisée et documentée

Données qui doivent être supprimées pour la confidentialité et conformité des données

Les règles de confidentialité des données peuvent exiger des organisations qu’elles suppriment les données personnelles lorsqu’il n’y a plus de raison légitime de les conserver. Conserver des informations indéfiniment parce qu’elles pourraient être utiles un jour n’est pas une politique de gestion des données défendable.

Dans le même temps, les obligations de confidentialité doivent être équilibrées avec les exigences légales de conservation, de litige, fiscales et d’audit. Les données personnelles ne doivent pas être détruites si une autre obligation légale valide exige qu’elles restent disponibles. SAP Information Lifecycle Management peut soutenir cet équilibre grâce aux règles de conservation, au blocage, aux gels juridiques et à la destruction contrôlée.

Trouvez plus d’informations sur les exigences en matière de confidentialité des données dans différents pays et régions dans la série sur la confidentialité des données de TJC Group.

Données qui ne servent plus un objectif valide

Les enregistrements obsolètes, non pertinents et dupliqués peuvent affaiblir la gouvernance des données et augmenter la quantité d’informations qui doivent être protégées, gérées et examinées. Les exemples typiques incluent les données techniques obsolètes, les enregistrements de base dupliqués, les données de test ou les informations relatives à des structures organisationnelles qui n’existent plus.

Scission d’entreprise : Une organisation vend une filiale. Après les périodes de conservation contractuelles et légales pertinentes, certaines données relatives à l’ancienne entité peuvent ne plus servir un objectif commercial. L’organisation doit déterminer quels enregistrements doivent être transférés à l’acheteur, lesquels elle est autorisée ou tenue de conserver, et lesquels peuvent éventuellement être détruits.

Arrêt de produit : Une entreprise de télécommunications a cessé de vendre plusieurs modèles de téléphones. Les numéros d’article, les spécifications, les enregistrements d’inventaire et l’historique des transactions associés peuvent encore devoir être conservés pour les garanties, les taxes, la responsabilité du fait des produits ou les rapports. Une fois ces exigences expirées, les enregistrements sans objectif restant peuvent devenir éligibles à la destruction.

Dans les deux scénarios, l’âge seul ne suffit pas. L’organisation a besoin d’une décision basée sur une politique, soutenue par la propriété commerciale, les règles de conservation et une approbation documentée.

Quelles données doivent rester accessibles en dehors de S/4HANA

Toutes les données historiques utiles n’ont pas besoin de se trouver dans la base de données S/4HANA active. Certaines informations peuvent être rarement consultées mais avoir toujours une valeur commerciale ou légale significative. Les conserver en dehors de l’ERP central peut préserver cette valeur tout en évitant le coût de maintien de l’environnement legacy complet en fonctionnement.

Informations historiques nécessaires pour les audits et les rapports

Les équipes financières, fiscales, d’audit interne et commerciales peuvent avoir besoin d’accéder aux factures et écritures comptables historiques, aux rapports financiers originaux, aux documents justificatifs, aux transactions passées, aux enregistrements clients et fournisseurs, aux données des entités juridiques clôturées, aux informations des entreprises acquises et aux enregistrements des applications non-SAP.

Les exigences d’accès doivent être définies avant l’arrêt du système source. Les informations conservées doivent rester compréhensibles. Un extrait de base de données brut peut ne pas fournir suffisamment de contexte à un auditeur ou à un utilisateur métier pour interpréter les enregistrements plusieurs années plus tard. Une approche de conservation appropriée doit préserver les relations, les rapports, les documents, les métadonnées et la traçabilité pertinents.

Données soumises à un gel juridique

Un gel juridique est différent d’une période de conservation ordinaire. Une règle de conservation définit la durée normale de conservation d’une catégorie de données. Un gel juridique suspend la suppression ou la destruction prévue d’informations liées à un litige, une enquête, un audit ou une autre affaire juridique.

Dans SAP ILM, un gel juridique peut empêcher la destruction des données pertinentes même lorsque la période de conservation normale a expiré. Il peut s’appliquer aux informations toujours détenues dans la base de données ainsi qu’aux informations stockées dans un magasin ILM. Cela signifie que les gels juridiques doivent être vérifiés avant le début de tout programme de suppression pré-migration.

Le processus doit établir quelle affaire nécessite le gel, quels enregistrements et objets de données sont affectés, qui l’a autorisé, quand il a été appliqué, s’il couvre les informations archivées ainsi que les informations actives, qui peut lever le gel et comment la destruction reprend une fois le gel terminé. Un gel juridique doit préserver les preuves pertinentes sans devenir une raison de conserver indéfiniment des données non liées.

Données des systèmes SAP et non-SAP décommissionnés

Après la mise en service de S/4HANA, certaines organisations continuent de payer pour d’anciens systèmes parce que les utilisateurs ont occasionnellement besoin d’informations historiques. Cela crée un deuxième patrimoine ERP qui doit toujours être hébergé, sécurisé, patché, pris en charge et surveillé.

Le décommissionnement des systèmes legacy offre une autre option. Les données, documents, rapports et contextes requis peuvent être extraits dans un environnement gouverné. L’application d’origine peut alors être retirée tandis que les utilisateurs autorisés conservent l’accès aux informations dont ils ont besoin. Ceci est particulièrement important lorsque le paysage plus large comprend plusieurs systèmes SAP et non-SAP.

Comment de meilleures décisions en matière de données soutiennent les futurs cas d’utilisation de l’IA

Un environnement S/4HANA prêt pour l’IA n’a pas besoin de chaque enregistrement historique dans la base de données active. Il a besoin de données fiables, bien gouvernées, traçables et accessibles qui peuvent soutenir un objectif commercial défini. Pour de nombreux futurs cas d’utilisation de l’IA, la qualité des données, la gouvernance des données, la lignée des données et le contexte importeront plus que le volume total de données disponibles.

La préparation des données concerne la qualité et la pertinence des informations utilisées dans l’environnement actif. L’archivage des enregistrements terminés et inactifs peut réduire le volume inutile tout en améliorant la focalisation de l’ensemble de données actives.

La disponibilité des données concerne la possibilité de trouver, de comprendre et de fournir des informations historiques utiles aux plateformes d’analyse ou d’IA lorsque cela est nécessaire.

Les données historiques peuvent soutenir de futurs cas d’utilisation tels que l’analyse des risques fournisseurs, la prédiction des retards de paiement, l’analyse du comportement client, la prévision de la demande, la détection des fraudes, la détection des anomalies et la planification de la maintenance. Cependant, conserver plus d’historique ne rend pas automatiquement un système plus prêt pour l’IA. Les données doivent rester compréhensibles, traçables, gouvernées et accessibles sous les bonnes autorisations. Sinon, de grands volumes de données historiques peuvent simplement ajouter du bruit, des risques et de la complexité.

L’organisation doit toujours appliquer les règles de conservation et de suppression, les contrôles de confidentialité des données, les autorisations des utilisateurs, le masquage des données, l’accès basé sur l’objectif, la traçabilité, les contrôles de qualité et les gels juridiques.

La préparation à l’IA n’est donc pas seulement une question de quantité de données. Elle dépend de la capacité de l’organisation à savoir quelles données elle détient, pourquoi elles sont conservées, d’où elles proviennent, qui peut y accéder et si elles sont suffisamment fiables pour l’objectif visé.

Comment TJC Group prend en charge l’évaluation des données, l’archivage et l’accès aux systèmes legacy

TJC Group aide les organisations à décider ce qui doit être déplacé vers S/4HANA, ce qui peut être archivé, ce qui doit être supprimé et ce qui doit rester accessible après le retrait des systèmes legacy.

L’archivage des données et le décommissionnement des systèmes legacy sont des éléments importants de la préparation à S/4HANA, mais ils ne constituent pas l’intégralité du programme de transformation. Les organisations doivent également aborder le nettoyage des données, l’harmonisation, la gouvernance des données de base, la refonte des processus et la propriété des objets de données critiques. L’archivage des données dans SAP aide à réduire le volume de données actives inutile et à préserver l’accès aux enregistrements terminés, tandis que le nettoyage et la gouvernance aident à garantir que les données transférées vers S/4HANA sont exactes, cohérentes et adaptées aux futurs cas d’utilisation commerciaux et d’IA.

Le processus commence par une évaluation du paysage SAP existant. Cela peut inclure :

• Analyse de la taille actuelle de la base de données
• Identification des tables volumineuses et à croissance rapide
• Examen des postes ouverts et des dépendances des données
• Estimation de la croissance future des données
• Cartographie des exigences de conservation commerciales et réglementaires
• Identification des unités organisationnelles inactives
• Quantification des opportunités d’archivage potentielles
• Priorisation des gains rapides
• Planification de la gestion du volume de données continue

Dans un projet pour un fournisseur mondial de solutions de nettoyage commercial, d’hygiène et de prévention des infections, une phase d’archivage initiale a supprimé 27,6 To de données. L’organisation est ensuite passée d’un nettoyage ponctuel à un archivage automatisé continu pour maîtriser la croissance future.

Automatisation de l’archivage des données SAP avec Archiving Sessions Cockpit

L’Archiving Sessions Cockpit, ou ASC, est un logiciel certifié SAP développé par TJC Group pour automatiser l’archivage des données SAP et les processus SAP ILM. Il prend en charge le flux de travail complet d’archivage, y compris la création et la gestion des fichiers d’archivage, la suppression des tables actives, la surveillance des sessions et l’exécution récurrente. ASC est disponible en deux versions : ASC Standard et ASC for ILM.

ASC Standard pour l’archivage de données classique

Cette édition se concentre sur l’archivage de données SAP traditionnel et la réduction du volume de données. Elle aide les organisations à automatiser les tâches d’archivage récurrentes et à maintenir le contrôle de la croissance de la base de données avant et après la migration S/4HANA.

ASC for ILM pour la suppression des données

Cette édition combine l’automatisation de l’archivage avec les processus SAP ILM. Elle prend en charge la gestion de la conservation et la destruction contrôlée des données conformément aux politiques telles que les exigences du RGPD.

L’automatisation est essentielle car les avantages d’un projet d’archivage initial peuvent disparaître si la croissance des données est autorisée à reprendre. L’exécution régulière aide à maintenir la réduction de la base de données obtenue lors de la préparation à la migration. Cependant, l’automatisation de l’archivage doit s’inscrire dans une stratégie de gestion des données plus large qui inclut également la qualité des données, la gouvernance des données de base, les politiques de conservation et la propriété claire de la croissance future des données.

Conserver l’accès aux informations legacy avec ELSA

Lorsque les informations historiques doivent rester accessibles en dehors de S/4HANA, l’Enterprise Legacy System Application, ou ELSA, de TJC Group prend en charge le décommissionnement des systèmes SAP et non-SAP. ELSA est construit sur SAP Business Technology Platform et peut préserver l’accès aux données, documents, rapports et transactions legacy après le retrait de l’application d’origine.

Il prend également en charge des fonctionnalités telles que l’accès centralisé à plusieurs systèmes legacy, la gestion des utilisateurs et de la sécurité, la traçabilité, le masquage des données, les requêtes prédéfinies et personnalisées, l’accès depuis les applications actuelles, et les contrôles de confidentialité et conformité des données.

Ensemble, ASC et ELSA abordent différentes parties de la décision de migration. ASC aide à maintenir un environnement SAP léger et contrôlé grâce à l’automatisation de l’archivage et de SAP ILM. ELSA aide les organisations à retirer les systèmes legacy tout en préservant un accès gouverné aux informations historiques qui restent précieuses.

Le résultat n’est pas un système S/4HANA vide, ni un système transportant des décennies de données inutiles. C’est un environnement ERP contenant les informations nécessaires aux opérations actuelles, soutenu par une couche de données historiques gouvernée pour les rapports, la conformité, l’analyse et les futurs cas d’utilisation de l’IA.