Systèmes legacy : passer de la mise hors service au décommissionnement

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

Introduction

L’évolution des systèmes informatiques est un phénomène inévitable dans la vie d’une entreprise. Cela signifie que, de temps à autre, les applications de la structure doivent être migrées ou remplacées par de nouvelles solutions. 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 mettre en place de nouveaux, plus adaptés, afin d’améliorer les opérations business et de les rendre plus efficaces. Nous comprenons que les termes «mise hors service » et « décommissionenment » peuvent sembler intrigants. Vous avez envie d’en savoir plus, n’est-ce pas ?

Nous avons justement rédigé cet article pour vous aider à comprendre le processus qui va de la mise hors service au décommissionnement d’un système existant.

Qu’est-ce que la mise hors service d’un système ?

L’expression « mise hors service 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 ou d’accords, par exemple. En d’autres termes, on peut y associer les expressions anglophones « phase out », « discontinue » ou encore « terminate ». Mais, dans le domaine des technologies de l’information, la mise hors service d’un système a une toute autre signification.

Dans le domaine informatique, la mise hors service 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 ?

Le décommissionnement 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 legacy 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 de systèmes patrimoniaux (LSA).

Le décommissionnement 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éclassement 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, 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é tout, il est nécessaire de conserver l’accès aux anciennes données pour les raisons suivantes :

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

Une application de type LSA est souvent requise car les exigences légales et de confidentialité des données peuvent ne pas être appliquées sur les systèmes les plus anciens.

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

Tout processus constructif s’accompagne de défis qu’il s’agit de relever – et il en va de même pour le traitement des systèmes existants. Voici quelques-uns des défis auxquels les entreprises sont confrontées face à des systèmes ERP et non-ERP obsolètes.

Un coût d’entretien élevé

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 avoir à supporter ces coûts pour plusieurs systèmes existants, comme SAP ECC, qui est généralement mis en œuvre au sein de plusieurs départements.

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

L’ensemble de 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.

Précisons que 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 legacy, 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.

La question de la dette technique

La dette technique constitue un défi majeur pour les organisations. À quoi correspond-elle ? La dette technique est le coût qu’implique l’adaptation d’une solution, après avoir choisi dans un premier temps une solution simple mais limitée, plutôt que de privilégier une meilleure approche, bien que plus longue. Elle est similaire à 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, elles freinent également l’innovation au sein de l’entreprise.

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 bien d’autres éléments encore. Par conséquent, s’il existe des dettes techniques, l’abandon d’un système existant peut s’avérer difficile. C’est pour cette raison qu’il est nécessaire de garantir des dettes minimales ou de disposer d’une preuve de concept (POC) pour faire progresser le projet.

Garantir une performance sans perturbation

Le risque de défaillance du système est un sujet de préoccupation. De nombreuses organisations, en particulier celles impliquées dans la production industrielle ou les soins de santé, parmi tant d’autres exemples, ne peuvent pas se permettre de voir leurs systèmes perturbés. La défaillance d’un système productif entraîne des pertes de revenus considérables. De fait, 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 ont des conséquences environnementales directement liées aux technologies de l’information. L’archivage des données et le décommissionnement 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 avec le cloud !).

Migrer vers un paysage plus récent et plus efficace

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

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

• Le nouveau système (S/4HANA) – en mode production :

Le nouveau système est celui dans lequel les anciennes applications ont été migrées, en l’occurrence les systèmes S/4HANA. Il est accessible quotidiennement aux utilisateurs professionnels pour la gestion des activités de l’entreprise, où ces derniers se connectent et travaillent chaque jour. En termes simples, le nouveau système correspond au système de production dans lequel les activités quotidiennes sont effectuées. Les utilisateurs de l’entreprise peuvent s’y connecter quotidiennement pour accomplir leur travail et gérer les opérations de l’organisation. En résumé, le nouveau système désigne le système de production où se déroulent les activités quotidiennes.

• L’ancien système (SAP ECC ou plus ancien) – en mode lecture seule :

L’ancien système, à savoir SAP ECC ou des systèmes plus anciens, sont accessibles aux utilisateurs en mode « lecture seule ». Ils peuvent accéder à toutes les informations importantes requises pour les tâches qu’ils ont à gérer. Cela permet de réduire l’accès utilisateur à quelques personnes seulement. La plupart du temps, les autorisations 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écommissionner 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 des conséquences organisationnelles, 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 décommissionné ?
• Combien de temps durera le projet de décommissionnement du système ?

Il est donc essentiel de planifier le projet de décommissionnement étape par étape.sentiel 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 décommissionnement 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. C’est pourquoi une analyse minutieuse peut également aller dans le sens de l’adoption d’une architecture entièrement nouvelle qui conviendra davantage à 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 existants. Cette étape consiste à collecter et à extraire un large éventail de données du système que vous envisagez de décommissionner, 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 au sein d’un emplacement centralisé – cet emplacement peut être basé sur le cloud, sur site ou en mode hybride

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é auparavant, l’emplacement de stockage peut être sur site, sur le cloud ou en mode hybdride. Il peut s’agir du stockage de données ou d’applications d’un emplacement sur site vers le cloud ou d’un environnement cloud à un autre. Dès lors, 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 du décommissionnement d’un système ?

L’application ELSA du Groupe TJC

Pour simplifier et rationaliser le décommissionnement des systèmes, le Groupe TJC a mis au point une application de système legacy d’entreprise – ELSA, pour Enterprise Legacy System Application. 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. Elle 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.

En quoi ELSA se démarque-t-elle des autres applications ?

La migration des données d’anciens systèmes ERP vers S/4HANA ne garantit pas que les données existantes resteront complètes ou inchangées – mais ELSA corrige ce risque ! ELSA de TJC Group protège et pérennise toutes les données legacy 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çue pour répondre à toutes les exigences futures des entreprises et à la plupart des réglementations internationales sur la confidentialité des données.

L’application ELSA du Groupe TJC convertit les données existantes en fichiers plats (format AIS), qui restent inchangés. Elle est parfaitement compatible avec d’autres solutions SAP spécifiques à différents secteurs, comme ceux de la santé, de la finance, de la fabrication ou du secteur public.

Étapes suivies par ELSA by TJC Group 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 des 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, en 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 !