Systèmes legacy : Un voyage de l’extinction à la mise hors service !

La mise hors service d’un système consiste à maintenir l’application existante en lecture seule, tandis que la mise hors service d’un système consiste à la retirer complètement. En termes simples, l’extinction est la phase qui précède le décommissionnement, mais elle peut être source de confusion pour de nombreuses personnes. Voici donc un blog qui dissipera vos doutes. Lire la suite !

Introduction

L’évolution des systèmes informatiques est un élément inévitable dans un environnement d’entreprise. Cela signifie que, de temps à autre, les applications d’entreprise doivent être migrées ou remplacées par de nouvelles. Qu’il s’agisse d’un système SAP ou d’un autre système ERP, il est essentiel de se débarrasser des anciens systèmes et d’en adapter de nouveaux pour améliorer les opérations commerciales et les rendre plus efficaces. Nous comprenons que les termes « sunsetting », « decommissioning » et autres peuvent sembler intrigants, ce qui peut susciter une plus grande curiosité pour en savoir plus, n’est-ce pas ?

C’est pourquoi nous avons créé un blog pour vous aider à comprendre le processus qui va de l’extinction à la mise hors service d’un système existant.

Qu’est-ce que la mise en veilleuse d’un système ?

L’expression « temporisation d’un système » a plusieurs définitions. Dans le domaine financier, il s’agit souvent de la cessation ou de l’abandon progressif de quelque chose – qu’il s’agisse de marques, de partenariats, de matériel et de logiciels, d’accords, etc. En termes simples, le terme « sunsetting » peut être synonyme d’expressions telles que « phase out », « discontinue », « terminate », etc. Toutefois, dans le domaine des technologies de l’information, la mise en veilleuse d’un système a une toute autre signification.

En termes informatiques, la mise en veilleuse d’un système consiste à faire passer un système existant d’un état productif (état d’utilisation) à un état non productif ou en lecture seule. Cela signifie que le système reste accessible pour les informations importantes, mais qu’il ne peut pas être utilisé pour les opérations quotidiennes.

Qu’est-ce que le décommissionnement de systèmes ?

Bien que le processus de suppression du système soit relativement ancien, il crée souvent la confusion parmi les utilisateurs, principalement en raison de ses différentes définitions selon les secteurs d’activité. Souvent, les lecteurs ont tendance à penser que l’extinction d’un système et le décommissionnement sont identiques – en réalité, la mise hors service va bien au-delà de l’extinction.

Le démantèlement des systèmes comprend le retrait et l’arrêt complet des anciens systèmes ou de l’infrastructure informatique devenue obsolète. Parfois, les données patrimoniales sont également extraites et sauvegardées dans des fichiers plats en tant qu’archives fiscales. Ces données peuvent être réévaluées en cas de besoin à l’aide d’applications de systèmes patrimoniaux (LSA).

Le démantèlement des systèmes existants est un élément essentiel du processus de gestion du cycle de vie des technologies de l’information. Elle peut également aider les organisations à optimiser leurs ressources informatiques, à réduire les coûts de maintenance et à garantir la conformité future avec les lois sur la confidentialité des données, tout en éliminant les risques de sécurité associés aux systèmes obsolètes. En outre, le décommissionnement aide les organisations à rester en phase avec l’évolution de leurs besoins technologiques.

Pourquoi voulons-nous conserver l’accès aux anciennes données ?

Maintenant que vous connaissez la différence entre la mise hors service d’un système et le décommissionnement d’un système, abordons la question la plus importante : pourquoi est-il nécessaire de conserver l’accès à d’anciennes données ?

Au fil du temps, de nombreuses organisations maintiennent des systèmes ERP et non-ERP obsolètes, bien que cela épuise les ressources informatiques. Malgré cela, il est nécessaire de conserver l’accès aux anciennes données pour les raisons suivantes –

• La première chose à faire est de se conformer aux règles.
• Deuxièmement, les anciennes données sont nécessaires pour répondre aux demandes d’audit ou de taxation.
• Troisièmement, si des documents ou des données historiques doivent être consultés pour les besoins de l’entreprise.

LSA is often required as legal and data privacy requirements might not be enforced on older systems

Les défis liés à la gestion des systèmes legacy

Toute bonne chose s’accompagne de défis qu’il faut relever – et il en va de même pour le système legacy. Voici quelques-uns des défis auxquels les entreprises sont confrontées avec des systèmes ERP et non-ERP obsolètes.

Coûts élevés

Le coût de la maintenance est l’un des principaux défis posés par les systèmes existants. Pour chaque système existant, il y a environ 49 implications financières différentes, les dépenses les plus importantes étant les frais de maintenance des logiciels et des applications. Ensuite, il y a l’impact sur les opérations, c’est-à-dire le fait que les ressources informatiques soient accaparées par la gestion de systèmes obsolètes alors qu’elles pourraient travailler sur de nouvelles technologies. En outre, les organisations peuvent supporter ces coûts pour plusieurs systèmes existants, comme SAP ECC mis en œuvre dans plusieurs divisions, etc.

L’image ci-dessous représente les 49 tâches associées à la maintenance d’un système ou d’une application patrimoniale :

Toutes ces tâches doivent être prises en compte lors de l’affectation des ressources informatiques, ce qui représente une charge de travail considérable.

Cela dit, le coût de la licence du système d’exploitation (OS), de la base de données (DB) et des licences SAP devra également être renouvelé, ce qui entraînera des coûts de maintenance plus élevés. Ce montant peut être considérable ! Même si les organisations n’utilisent pas de systèmes patrimoniaux, la maintenance de leurs applications est nécessaire, ce qui augmente non seulement les coûts de maintenance mais aussi la pression sur les équipes techniques.

Dette technique

La dette technique constitue un défi majeur pour les organisations. En termes simples, la dette technique est le coût implicite du remaniement d’une solution causé par le choix d’une solution facile mais limitée plutôt que d’une approche meilleure mais plus longue. Elle est analogue à une dette monétaire et, si elle n’est pas remboursée, la dette technique accumule des intérêts, ce qui entraîne des difficultés dans la mise en œuvre des changements. Les dettes techniques non traitées augmentent l’entropie du logiciel et le coût des retouches ultérieures. La dette technique entrave également la capacité de l’entreprise à innover et à s’adapter aux changements les plus récents.

Il existe plusieurs raisons pour lesquelles de telles dettes se produisent, telles que le manque de documentation, le manque de suites de tests, des composants étroitement couplés à des fonctions non modulaires, et ainsi de suite. Par conséquent, s’il existe des dettes techniques, l’abandon d’un système existant peut s’avérer difficile – c’est pourquoi il est nécessaire de garantir des dettes minimales ou de disposer d’une preuve de concept (POC) pour aller de l’avant avec le projet.

Garantir une performance sans perturbation

Le risque de défaillance du système est un facteur de préoccupation. De nombreuses organisations, en particulier celles impliquées dans la production industrielle, les soins de santé, etc. ne peuvent pas se permettre que leurs systèmes soient perturbés. La défaillance d’un système productif entraîne des pertes de revenus considérables. Cela dit, la perte d’un système existant peut également entraîner des pénalités financières (liées à des contrôles fiscaux). Il est donc essentiel d’assurer une performance non perturbatrice (réduite) tout en supprimant les systèmes existants. Les organisations doivent veiller à ce que le processus soit le plus fluide possible.

Impact sur l’environnement

Outre les incidences financières, les systèmes existants contribuent aux incidences environnementales liées aux technologies de l’information. L’archivage des données et la mise hors service des systèmes sont donc la meilleure façon de procéder, car ils contribuent de manière significative à réduire la nécessité de remplacer les appareils (oui, cela se produit aussi dans les nuages !).

Migrer vers un paysage plus récent et plus efficace

Pour en venir au paysage SAP, il est annoncé que SAP ECC et les anciennes versions doivent être remplacées par SAP S/4HANA d’ici 2027 et probablement après. Mais qu’en est-il après la migration ?

Une fois la migration terminée, il y aura deux systèmes : l’ancien et le nouveau.

• The new system (S/4HANA) – productive status:

The new system is the one where the old applications have been migrated, which in this case is S/4HANA systems. Il est accessible quotidiennement par les utilisateurs professionnels pour gérer les activités de l’entreprise, où les utilisateurs se connectent au système tous les jours et y travaillent. En termes simples, le nouveau système fait référence au système de production dans lequel les activités quotidiennes sont réalisées.

• The old system (SAP ECC or older) – on read-only status:

The old system, or the SAP ECC or older systems, are accessible to users in read-only mode, where they can access any important information required for tasks. Cela permet de réduire l’accès des utilisateurs à quelques personnes seulement. La plupart du temps, les autorisations de l’utilisateur sont modifiées de manière à ce que le statut de lecture seule soit possible.

Étapes du projet de décommissionnement des systèmes legacy

Planifier la mise hors service

La première et principale étape de tout projet est l’élaboration d’un plan solide. La décision de démanteler les systèmes existants peut avoir un impact sur plusieurs départements et, par conséquent, une analyse complète de cet impact est toujours une bonne idée. Le décommissionnement n’a pas seulement un impact organisationnel, mais aussi un impact financier. Il est essentiel de disposer d’une stratégie de planification solide.

Voici quelques questions courantes qui peuvent être posées

• Où iront les informations après le décommissionnement du système ?
• Une nouvelle application remplacera-t-elle les services du système existant mis hors service ?
• Combien de temps durera le projet de démantèlement du système, etc.

Il est donc essentiel de planifier le projet de démantèlement étape par étape.

Choisir l’architecture la mieux adaptée à votre paysage informatique.

Il s’agit ensuite de choisir l’architecture qui convient à votre paysage informatique. En d’autres termes, un projet de mise hors service d’un système comprend la réarchitecture, la reconstruction ou le remplacement de l’ancien paysage. La réarchitecture consiste à modifier le code pour passer à une nouvelle architecture d’application afin d’obtenir de nouvelles capacités. Bien que ce processus permette d’obtenir les meilleurs résultats, il peut s’accompagner d’un coût et de risques plus élevés. Cela dit, une analyse minutieuse peut également suggérer l’adoption d’une architecture entièrement nouvelle qui conviendra le mieux à votre paysage informatique. Que vous choisissiez une nouvelle architecture ou que vous restructuriez l’architecture existante, veillez à la cartographier en fonction de la technologie, de la fonctionnalité, du coût et du risque. L’essentiel est donc de peser toutes les options disponibles afin d’identifier le processus qui nécessitera un minimum d’efforts mais aura un impact positif maximal.

Extraction des données du système legacy

Une fois le plan mis en place, la troisième étape consiste à extraire les données des systèmes legacy. L’extraction des données consiste à collecter et à extraire un large éventail de données du système que vous envisagez de mettre hors service, dont beaucoup peuvent être mal organisées. L’extraction est une étape nécessaire car elle permet de consolider, de traiter et d’auditer les données qui seront stockées dans un emplacement centralisé – cet emplacement peut être basé sur le cloud, sur site, ou même un hybride des deux.

Téléchargement des données dans l’application du système legacy

Après l’étape d’extraction des données, vient celle du téléchargement des données dans le système de stockage. Comme indiqué ci-dessus, l’emplacement de stockage peut être sur site, dans le nuage ou un hybride des deux. Il peut s’agir du stockage de données ou d’applications d’un emplacement sur site vers le nuage ou d’un environnement de nuage à un autre. Cela dit, on s’attend à ce que la majorité des entreprises fonctionnent entièrement sur le cloud d’ici quelques années, car l’augmentation du stockage et de la migration sur le cloud est impressionnante.

Comment le groupe TJC peut-il vous aider dans le cadre de la mise hors service d’un système ?

Application Enterprise Legacy System Application by TJC Group

Pour simplifier et rationaliser le décommissionnement des systèmes, le groupe TJC a mis au point une Enterprise Legacy System Application – ELSA. Il s’agit d’une application, construite et certifiée sur la SAP Business Technology Platform (BTP), qui fonctionne également sur site ou avec n’importe quel hyperscaler. Grâce à cette application, il est possible de s’assurer que toutes les données existantes sont stockées en toute sécurité et qu’il est possible d’y accéder à nouveau avant et après la migration vers les nouveaux systèmes ERP ou S/4HANA. Il permet non seulement d’accéder à toutes les données extraites, mais aussi d’éviter les dépenses liées à la conservation du système existant.

Comment ELSA se distingue-t-elle des autres ?

La migration des données d’anciens systèmes ERP vers S/4HANA ne garantit pas que les données legacy resteront complètes ou inchangées – mais ELSA le fait ! ELSA de TJC Group protège et pérennise toutes les données patrimoniales tout en les rendant facilement accessibles à partir de S/4HANA, d’une application web UI5 ou de toute autre application technologique actuelle. Il est important de noter qu’ELSA est conçu pour répondre à toutes les exigences futures des entreprises et à la plupart des lois internationales sur la confidentialité des données.

ELSA by TJC Group convertit les données existantes en fichiers plats (format AIS), qui restent inchangés. Il est entièrement compatible avec d’autres solutions SAP spécifiques à l’industrie – utilisées dans les secteurs de la santé, de la finance, de la fabrication et du secteur public.

Étapes suivies par l’ELSA du groupe TJC pour le décommissionnement des systèmes

1. La première étape consiste à extraire 100 % des données du système existant sous forme d’archives fiscales.
2. Une fois les données extraites, nous stockons les fichiers AIS extraits dans le stockage en nuage AWS / Azure / GCS ou dans le système de fichiers sur site, selon votre préférence.
3. Après le stockage, les données pertinentes sont importées des fichiers AIS dans la base de données ELSA de votre choix. Vous pouvez choisir les bases de données suivantes en fonction de vos besoins – MySQL / HANA / HANA Cloud / PostgreSQL / Oracle Heatwave.
4. Enfin, les utilisateurs finaux, tels que l’équipe chargée de la fiscalité et de l’audit, peuvent accéder à toutes les données via ELSA ou S/4 HANA FIORI App, des solutions « low code – no code » ou la technologie la plus récente, tout en arrêtant en toute sécurité le système existant.

Compte tenu du niveau d’investissement financier nécessaire pour S/4 HANA, il est impératif de sélectionner des applications partenaires à l’épreuve du temps et offrant un accès ouvert. ELSA rassemble des données provenant de différents systèmes et sources – données anciennes, archivées ou en direct – et les maintient accessibles, d’un simple clic. Au sein de SAP BTP, ELSA est déployé dans l’environnement open source Cloud Foundry, protégeant ainsi votre investissement et minimisant le coût futur de la propriété.

Conclusion

Le décommissionnement d’un système est le processus de mise hors service d’un système legacy qui a été mis en veilleuse ou en lecture seule il y a un certain temps. Les systèmes existants posent plusieurs problèmes, notamment –

• L’exploitation des systèmes legacy est coûteuse.
• Ils augmentent la « dette technique ».
• Ils ont un impact significatif sur l’environnement.

Le projet de d’arrêt de systèmes est donc la seule option plausible. Cela dit, cela permet également de s’assurer que les exigences de conformité seront respectées à l’avenir. Et avec ELSA de TJC Group, vous pouvez simplifier encore plus l’ensemble du processus de décommissionnement grâce à notre méthodologie éprouvée. Pour démanteler votre ancien système ou pour en savoir plus sur ELSA, contactez-nous dès aujourd’hui !